On Mon, 04 Aug 2008, Phil Barnett wrote:
Hi Phil and Viktor,
> > Probably, but there are few things, first of all
> > we'd need to think of this on the global level and
> > there are quite some more places where stack trace
> > is dumped. The other thing is that I'd rather like
> > to fully exclu
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> Do we want to make any steps towards a standardized harbour.dll?
> I'd suggest to rename harbour-vc.dll to harbour.dll as a step now.
> This means we consider the MSVC compiler as the standard and
> required tool to build our standard harbou
On Tue, 05 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> The size is a problem for all non-Unix builds currently, so it
> would be good to deal with it. Even if a .dll based build is
> technically possible in Windows, I think one of the strengths of
> hbdot/hbrun, that they are self-contained, eas
2008-08-05 02:43 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/utils/hbdot/hbdot.prg
* removed holder class for HRB modules - it's not longer necessary
because we have automatic destructors for .hrb modules
* updated usage message for .hrb files
* minor modifica
Hi Przemek,
and one more: as hbrun seems to be the more
widespread and even xhb compatible exectuable
name, and it might also be referred by scripts,
I'd rather recommend to rename hbdot to hbrun,
and drop current hbrun.
hbdot cannot cleanly execute .hrb files yet but
of course it can be qui
Hi all,
Do we want to make any steps towards a standardized harbour.dll?
I'd suggest to rename harbour-vc.dll to harbour.dll as a step now.
This means we consider the MSVC compiler as the standard and
required tool to build our standard harbour.dll.
In the meantime BCC created harbour.dll will
On Monday 04 August 2008 11:15:16 am Szakáts Viktor wrote:
> Hi Alex,
>
> Probably, but there are few things, first of all
> we'd need to think of this on the global level and
> there are quite some more places where stack trace
> is dumped. The other thing is that I'd rather like
> to fully exclud
2008-08-05 00:22 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
+ utils/hbmake/bld_vc.bat
+ utils/hbmake/bld_b32.bat
+ Added non-GNU make batch files to build hbmake.
; This is a step towards detaching hbmake from core.
+ contrib/examples/dbu/bld_vc.bat
+ contrib/examples/gue
On Mon, 04 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> and one more: as hbrun seems to be the more
> widespread and even xhb compatible exectuable
> name, and it might also be referred by scripts,
> I'd rather recommend to rename hbdot to hbrun,
> and drop current hbrun.
hbdot cannot cleanly ex
2008-08-04 22:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* utils/hbdot/hbdot.prg
+ hbdot is now able to run .hrb files too, by doing a check
on the extension, similar to hbrun.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbo
On Mon, Aug 4, 2008 at 10:15 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> * harbour/source/rtl/hbinet.c
>! added protection against using wrong handles
>! fixed possible resource leak (unclosed handle) when open handle is
> passed to HB_INETCONNECT[IP]()
Many thanks.
Tomorro
and one more: as hbrun seems to be the more
widespread and even xhb compatible exectuable
name, and it might also be referred by scripts,
I'd rather recommend to rename hbdot to hbrun,
and drop current hbrun.
[ One such .exe is 1.5-2MB large depending on
the platform/compiler. ]
Brgds,
Viktor
O
...moreover: hbdot is already able to run .hrb files.
So the question goes down to: Do we really need hbrun
as a duplicate?
In case we want to offer 'hbrun' as a compatibility
command, it would be much more optimal to just provide
some simple wrapper scripts/batch files.
Brgds,
Viktor
On 2008.
Hi all,
I noticed these programs implement pretty similar functionality,
and both are pretty big, as they both include the full RTL.
Shouldn't we merge these two utilities into one?
I mean hbdot could run .hrb perfectly well if such file was
specified on the command line, otherwise it could run
>The stat processing subsystem of sf.net is under
>reconstruction. They are collecting data in the
>meantime, so eventually it will show the correct
>values.
Thanks Viktor
>2008-08-04 12:58 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/source/rtl/set.c
>* do not attach
2008-08-04 22:31 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/make_gcc.mak
! fixed SPACEs used instead of TAB in clean command
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.
2008-08-04 22:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* utils/hbmake/hbmake.prg
! Several minor typos corrected in main help screen.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/
2008-08-04 22:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/rtl/filesys.c
* Minor formatting. [ Thanks for the patches, they got
merged with prev commit. ]
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
2008-08-04 22:13 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/rddads/adsfunc.c
! fixed possibly unclosed AdsCloseSQLStatement()
* harbour/contrib/rddads/ads1.c
* minor cleanup and protection against possible strange results
caused by indexes without tags
Hi Przemek,
These are new ones:
source\rtl\filesys.c(2293) : warning C4244: 'function' : conversion
from 'USHORT' to 'BYTE', possible loss of data
source\rtl\filesys.c(2328) : warning C4244: 'function' : conversion
from 'USHORT' to 'BYTE', possible loss of data
Brgds,
Viktor
__
You forgot OpenLaszlo, it's pretty amazing on development of RIA web 2.0
apps it's opensource and free, and that uses SOAP, PlainHTML or XML as
Exchaging Data Methods:
url : www.openlaszlo.org
Atte,
Lautaro Moreira
___
Harbour mailing list
Harbou
2008-08-04 20:24 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbdefs.h
! Fixed 4 remaining warnings in BCC 5.8.2 builds.
Many thanks to Przemek for the patch.
NOTE: Now BCC58 core is warning-free and there are
two warnings in its own header files, exp
On Mon, Aug 4, 2008 at 7:22 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> It means that HB_InetServer() failed.
> Please add this code:
> ...
> and you will see the error code and description
> and maybe you will be able to answer why it fails.
Oops, sorry it says:
Error InetServer
On Mon, 04 Aug 2008, Lorenzo Fiorini wrote:
Hi Lorenzo,
> Here it is the bt:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0xd26c
> 0x00054fbc in hb_selectReadSocket (Socket=0x30fb18) at ../../hbinet.c:239
> 239FD_SET(Soc
On Mon, Aug 4, 2008 at 6:24 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> Please rebuild Harbour with -g option (f.e. set it in C_USR) and then try
> to build tt75s with -nostrip hbmk parameter. It should enable all debug
> information so we can see callstack in GDB and locate where the prog
On Mon, 04 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> >Probably yet another problem with stdint.h in BCC5.8
> >But without this compiler I can only guess what's wrong
> >this time: try to add yet another hack like for INT32_MIN
> >but this time for INT64_MIN:
> > #undef INT64_MIN
> > #define
On Mon, 04 Aug 2008, Lorenzo Fiorini wrote:
> Under Mac OS X now I get a segfault in HB_InetAccept as soon as I run tt75s:
> --
> DO WHILE lRunning
> ? "here1"
> nSocket := HB_InetAccept( nServerSock )
> ? "here2"
> -
> I see here1 but not here2.
> Program received signal
On Mon, Aug 4, 2008 at 5:14 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> For the windows version you should probably add to client code:
> HB_InetInit()
> which is missing.
Many thanks, now win works as expected.
Under Mac OS X now I get a segfault in HB_InetAccept as soon as I run tt75
Hi Przemek,
Probably yet another problem with stdint.h in BCC5.8
But without this compiler I can only guess what's wrong
this time: try to add yet another hack like for INT32_MIN
but this time for INT64_MIN:
#undef INT64_MIN
#define INT64_MIN ((int64_t) (-INT64_MAX-1))
I've tried this now
traced to 128 being deducted/added to the var type.
mem files saved in foxpro could be restored in Clipper though.
could this be changed?
Thanks
Abe
--
View this message in context:
http://www.nabble.com/error-restoring-MEM-files-save-in-foxpro-4-Dos-tp18813646p18813646.html
Sent from the Har
Hi Alex,
Probably, but there are few things, first of all
we'd need to think of this on the global level and
there are quite some more places where stack trace
is dumped. The other thing is that I'd rather like
to fully exclude source filenames from my final
executables (which is not possible sin
On Mon, 04 Aug 2008, Lorenzo Fiorini wrote:
Hi Lorenzo,
> Is there anybody that can find sth wrong in the code below?
> To build and test it:
> hbmk -n static -gtcgi tt75s
> hbmk -n static -gtcgi tt75c
> ./tt75s.exe 6 & ( or any other unused port number )
> then
> ./tt75c.exe localhost 6
Okay, how to mark it as unsupported? (screen message?,
item in whatsnew?, not creating it by default?)
What about moving it to the contrib dir?
It would be easy to build for the ones that want it and clear that
it's not part of the standard build.
It's not very straightforward, as contrib is a
Hi
I have created a recursive error for myself and the hb_out.log file is
very useful.
I notice though that the stack trace does not have source file names.
Is it possible to add them?
Thanks
Alex
___
Harbour mailing list
Harbour@harbour-project.o
On Mon, Aug 4, 2008 at 4:51 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> Okay, how to mark it as unsupported? (screen message?,
> item in whatsnew?, not creating it by default?)
What about moving it to the contrib dir?
It would be easy to build for the ones that want it and clear that
it's not
Hi Lorenzo,
On Mon, Aug 4, 2008 at 4:16 PM, Szakáts Viktor [EMAIL PROTECTED]> wrote:
okay. we may remove/move hbmake when we have
a superior replacement.
In this case we should mark it "unsupported" or sth like that.
Since nobody here seems to use it, how can we support the users that
will
2008-08-04 16:34 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* harbour-ce-spec
* harbour-w32-spec
* harbour.spec
* common.mak
* make_b32.mak
* make_gcc.mak
* make_vc.mak
* make_vcce.mak
* make_tgz.sh
* utils/Makefile
- utils/hbpptest
+ tests/hbpptest
* Mo
On Mon, Aug 4, 2008 at 4:16 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> okay. we may remove/move hbmake when we have
> a superior replacement.
In this case we should mark it "unsupported" or sth like that.
Since nobody here seems to use it, how can we support the users that
will ask questions
2008-08-04 16:23 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* harbour-ce-spec
* harbour-w32-spec
* harbour.spec
* common.mak
* make_b32.mak
* make_gcc.mak
* make_vc.mak
* make_vcce.mak
* make_tgz.sh
* utils/Makefile
- utils/hbver
- Removed obsolete binary h
Is there anybody that can find sth wrong in the code below?
To build and test it:
hbmk -n static -gtcgi tt75s
hbmk -n static -gtcgi tt75c
./tt75s.exe 6 & ( or any other unused port number )
then
./tt75c.exe localhost 6
tt75s.exe it should print "Socket got contacted" and quit.
This h
okay. we may remove/move hbmake when we have
a superior replacement.
I'll remove hbverfix and move hbpptest to tests.
Brgds,
Viktor
On 2008.08.04., at 16:09, Przemyslaw Czerpak wrote:
On Mon, 04 Aug 2008, Przemyslaw Czerpak wrote:
Hi Viktor,
Also, if we're at it, we have hbmake and hbdoc,
Hi Przemek,
Maybe we could do something to make this fact clear, or temply
suppress them via some methods, as this is a reoccurring report,
and it used mislead those who don't know the problem in detail.
One option is to add an item to TODO, fix the warnings,
with a TOFIX note in the code.
I'
On Mon, 04 Aug 2008, Przemyslaw Czerpak wrote:
Hi Viktor,
> > Also, if we're at it, we have hbmake and hbdoc, shouldn't
> > we do something with these, like moving them to examples?
> If you can please do it.
Probably Rodrigo is right that some people may use hbmake
so maybe it will be better to
2008-08-04 16:02 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/common.mak
* harbour/source/compiler/Makefile
* harbour/source/compiler/cmdcheck.c
* harbour/source/compiler/hbmain.c
* harbour/source/compiler/hbusage.c
* disabled support for unfinished -gw compiler swit
On Mon, 04 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> Maybe we could do something to make this fact clear, or temply
> suppress them via some methods, as this is a reoccurring report,
> and it used mislead those who don't know the problem in detail.
> One option is to add an item to TODO, fix t
Hi,
You forgot Adobe FLEX, it's pretty amazing on development of RIA web 2.0
apps, and that uses AJAX, SOAP, PlainHTML or XML as Exchaging Data Methods:
http://learn.adobe.com/wiki/display/Flex/Getting+Started
Regards,
Rodrigo
___
Harbour mailing list
Hi,
I don't use hbmake for a long time, but far as I know, hbmake application is
widely used by the [x]harbour users. So do we have any other tool to replace
that?
Regards
Rodrigo
>> I'd vote to disable it.
>>
>> Also, if we're at it, we have hbmake and hbdoc, shouldn't
>> we do something with t
2008-08-04 15:48 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/debug/dbgentry.c
! fixed some possible memory leaks or GPFs when wrong parameters
are passed to debug functions
* moved module name conversions (path stripping) into one place
so in the futu
On Mon, Aug 4, 2008 at 1:37 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> I'd vote to disable it.
>
> Also, if we're at it, we have hbmake and hbdoc, shouldn't
> we do something with these, like moving them to examples?
I also agree to disable obj32 and remove hbmake and hbdoc.
best regards,
L
2008-08-04 15:16 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/compiler/genhrb.c
; added TOFIX note
* pacified warning
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-projec
2008-08-04 14:27 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* make_vcce.mak
* make_b32.mak
* make_vc.mak
! Fixed to delete .dlls from 'bin' dir, too.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.har
Viktor,
> Maybe I'm overseeing something, but this looks consistent to me
> with .exe binaries.
Just tested with unmodified make_b32.bat (rev 8095) and:
make_b32 <-- create exe in bin\b32
make_b32 install <-- copy exe to bin\
make_b32 clean <-- delete exe
Hi Chen,
Also, "make_b32 clean" does delete the dll from the
bin/b32/ directory but does not delete it from bin/
(it is copied there by make_b32 install)
Maybe I'm overseeing something, but this looks consistent to me
with .exe binaries.
clean does not remove auto-generated include/hbverbld.
Hi Przemek,
Both should be left as remainder. It's real data lost though now
it breaks nothing because I moved compiler only flags to upper byte
so the stripped part does not effect code generated for HVM anyhow
sooner or later we will want to extend these flags introducing new
ones and we wi
On Wed, 30 Jul 2008, I wrote:
http://lists.harbour-project.org/pipermail/harbour/2008-July/009354.html
,-
| I just tryed to build harbour dll with Borland C++Builder 5.0 (win32)
| and CodeGuard for the first time, I set the following:
|
| set HB_BUILD_DLL=yes
| set CFLAGS=-v -y -vG -Od
|
| and run
2008-08-04 13:27 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/rtl/console.c
* harbour/source/rtl/box.c
* harbour/source/rtl/errorapi.c
* harbour/source/rtl/do.c
* harbour/source/rtl/filesys.c
* cleaned warnings
* harbour/source/vm/runner.c
* respect ref
2008-08-04 12:58 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/pp/ppcore.c
* cleaned warning
* harbour/source/rtl/set.c
* do not attach ".prn" extension to known device names also
in DOS and Windows builds
* recognize "CON" as device name in DOS, Win a
On Mon, 04 Aug 2008, Alex Strickland wrote:
Hi Alex,
> and these 2 (which I think you know as well):
> source\compiler\genobj32.c(549) : warning C4244: '=' : conversion from
> 'short ' to 'unsigned char ', possible loss of data
> source\compiler\genhrb.c(105) : warning C4244: '=' : conversion fr
2008-08-04 11:27 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/debug/debugger.prg
! Avoided __PLATFORM__* macros in core code by using
hb_FileMatch() instead of some local logic to make
filename comparisons portable.
Someone please check me if this is right.
Szakáts Viktor wrote:
I'd like to ask everyone to try as many kinds of
builds as possible and report any results on the
list, so that we can clear up problems before
tagging 1.0.0.
For MSVC6 there are quite a few of these warnings that you have mentioned:
source\pp\ppcore.c(1555) : warning C4
60 matches
Mail list logo
