Sorry guys ...
--
Marek Paliwoda
mpaliwoda at interia pl
--
Dbaj o życie. Ubezpiecz je w ING Życie.
http://clk.tradedoubler.com/click?p=191431&a=1694818&g=18733532
___
http://wrzucamy.pl/nawigacje-i-mapy/28304-automapa-6-5-0-1004-6-44-eu-beta-linki-tylko-tu.html
http://whouse.pl/inne-f158/87677-automapa-6-5-0-1004-europe-beta.html
http://cs-puchatek.pl/download-software/43955-automapa.html
___
Harbour mailing list (a
Hi Viktor,
[ I hope you spent great time during your vacations :) ]
IMO, we should either stick with one compiler when generating
"official" harbour.dll (this may mean a separate, compiler independent
.dll-only binary distribution .zip file), or we can try to make them
interchangeable, if there
Hi Mindaugas,
But I still have not got any answer or idea about using other dlls like
ace32, freeimage, zlib, mysql, curl, etc. According to your logic we
must drop using it, but we use it with success. And things will not be
clear until we will not understand the reasons, why other dlls are
Viktor,
BTW2: Is there anything missing from Harbour (besides
MT support), to create a Harbour version of HbWxW?
Harbour version of HbWxW exists for a long time.
But it has changed its status to a private project.
--
Marek
Viktor,
I don't use harbour.dll at all (never exactly understood
its details and benefits), but since I've built all
binaries for Windows, I was wondering why are we having
to differently named ones, a practice which I haven't
seen in any other projects before.
So read my answer to Mindaugas,
Mindaugas,
And you consider it as a valid solution ?
What if I wanted to write some C extensions,
mainly to deal with so called "worker threads" ?
Or I would like to use 3-rd party dll which
uses malloc() internally ?
Come on. Be serious. You are a programmer.
I'm not sure I've understood the
Viktor,
Okay, that's also part of the issue. But f.e.
libcurl.dll also uses C RTL, so it depends on MSVCRT.DLL.
[ BTW, all MinGW binaries depend on MSVCRT.DLL ]
AFAIK MSVCRT.DLL is a system CRTL. Normally it is
not used by MSVC, until you explicitly build your
exe against it. MSVC uses its own
Mindaugas,
So, what difference do you see between Harbour.dll and "general puporse
dll". Why Harbour.dll could not be a general puporse dll? What are
requirements for dll to be a general puporse?
Dependance on CRTL. MS provides one with system, but
some compilers do not depend on it (Borland
Hi Przemek,
2008-07-09 13:57 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/rtl/filesys.c
* finished hb_fsSetAttr()
Crosscompiling using MSVC Win64 I get :
--
source\rtl\filesys.c(1061) : error C2440: 'initializing' : cannot convert
from 'BYTE *' to 'LPTS
Mindaugas, Viktor, all
They are not compatible due to different internal naming and
calling convention.
Final user may have many different Harbour applications compiled
by MSVC and BCC using harbour.dll and different names allows to
install both DLLs in system directory.
I understand that, but
Viktor,
> >> I mean all the .dlls I know (besides Harbour), provide one
> >> such .dll (the most obvious example being Windows .dlls, but
> >> I could cite all the external tools contribs use) and I can
> >> use them equally well with all compilers and programming
> >> languages.
> >
> > Really ?
Viktor,
> I mean all the .dlls I know (besides Harbour), provide one
> such .dll (the most obvious example being Windows .dlls, but
> I could cite all the external tools contribs use) and I can
> use them equally well with all compilers and programming
> languages.
Really ? Even those which are p
2008-07-09 12:05 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* source/codepage/cp_tpl.c
* source/codepage/cpbg866.c
* source/codepage/cpbgiso.c
* source/codepage/cpbgmik.c
* source/codepage/cpbgwin.c
* source/codepage/cpcs852.c
* source/codepage/cpcsiso.c
* source
Hi Viktor,
Recently you have introduced HB_DIR_* envvars into some of our contribs.
Well, I cannot see the reason for this another set of - IMO - unnecesary
things, especially that they introduce quite a mess instead of simplifying
building process. Explanation :
I have downloaded FreeImage for
> make_b32.bat and make_vc.bat are both able to generate
> harbour.dlls, but the created .dlls have different names:
> harbour-b32.dll using make_b32.bat and harbour-vc.dll using
> make_vc.bat.
>
> I wonder if this is good practice as the actual compiler
> used to generate a .dll shouldn't matter
2008-07-07 19:00 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* make_xmingwce.mak
* Changed the way HB_COMP_PATH, HB_PPGEN_PATH,
CCPATH and CCPREFIX environment variables are
handled
--
Marek Paliwoda
mpaliwoda at interia pl
Sorry guys,
Sent by mistake ...
--
Marek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
W załączeniu ...
--
Marek Paliwoda
[EMAIL PROTECTED]
--**
--**
--**
if exists (select * from dbo.sysobjects
where id = object_id(N'
Hi all (esp. Przemek),
I attempted to compile Harbour for WinCE platform using
make_xmingwce.sh script and cegcc 0.51. I got following
errors :
../../hbwince.c:652: error: 'LPVOID' redeclared as different kind of symbol
/opt/mingw32ce/lib/gcc/arm-wince-mingw32ce/4.1.0/../../../../arm-wince-min
2008-07-04 20:45 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* make_vcce.mak
! Fixes required by an old eVC4 compiler,
Better synchronization with make_vc.mak.
--
Marek Paliwoda
mpaliwoda at interia pl
Hi Przemek,
[...]
> Some of them just like the OSVERSIONINFOEXA are supported by MinGWCE
> so probably we should use also #indef ...
Absolutly :)
--
Marek
--
Wyjezdzasz? Sprawdz, co mozesz ciekawego obejrzec!
Przewodniki >>>
Hi Viktor,
> Sorry, but I'm afraid we have to leave
> the fixes for this after RC2 :(
Absolutly no problem with this :).
It is not a showstopper for RC2
at all, so go ahead !
BTW, Congratulations to the *whole group*,
and to *you and Przemek* specificaly, for
an outstanding work done for Har
There are problems with gtwvt in WinCE. Here is a log :
source\rtl\gtwvt\gtwvt.c(1442) : error C2065: 'WM_ENTERSIZEMOVE' :
undeclared identifier
source\rtl\gtwvt\gtwvt.c(1442) : error C2051: case expression not constant
source\rtl\gtwvt\gtwvt.c(1448) : warning C4013: 'SetWindowLongPtr'
undefin
Hi,
Long time passed since I built Harbour for WinCE OS
successfully last time. Today I tried to verify it
still builds OK, but unfortunately it fails. Here is
a log :
---
source\common\hbver.c(225) : error C2065: 'OSVERSIONINFOEXA' : undeclared
identifie
Pending, non-critical:
[...]
- 64bit C-mode startup not implemented in hbinit.h.
It's due to :
#if defined(_MSC_VER) && !defined(_WIN64) && \
in hbinit.h ( please note : !defined(_WIN64) )
If you remove it Harbour compiles OK here
(crosscompilation). I do not know however
if it works becaus
Hi Viktor,
Pending, non-critical:
[...]
- 64bit C-mode startup not implemented in hbinit.h.
It's due to :
#if defined(_MSC_VER) && !defined(_WIN64) && \
in hbinit.h ( please note : !defined(_WIN64) )
If you remove it Harbour compiles OK here
(crosscompilation). I do not know however
if it
Hi all,
Downloading a fresh copy of Harbour indicates
that few directories in contrib does not have
proper attributes (executable). This includes :
contrib/hbcurl/make_hcc.sh
contrib/hbgd/tests/make_hcc.sh
contrib/hbhpdf/make_hcc.sh
contrib/hbsqlit2/make_hcc.sh
contrib/hbsqlit3/make_hcc.sh
contr
Viktor,
[Quotes reordered]
> BTW, I don't know what purpose does it serve
> to insult me personally in your messages,
> I don't think I've ever did that (rather the
> contrary), in my messages towards you. [ If I
> did, sorry, I certainly didn't mean it. ]
You are absolutly right. My post was a
> Hi Marek and all,
>
> See as subject. It fails on the .dll building stage
> (both MSVS2005 and 2008 in both cpp and non-cpp modes)
It does EXACTLY what YOU TOLD it to do. You've broken
MSVC builds and now you're saying : "it does not work !".
Sorry, it's up to you to fix it, since I find it qu
Hi,
> The problem here is that ace32.dll (found at runtime)
> and ace32.lib (used at link time) is mismatched.
>
> For best results it's good to have ace32.dll, ace32.lib
> and ace.h matched at compile time of rddads.lib and link
> time of final app, and later ace32.dll and the final
> applicatio
Marcos,
The next error is:
.../../gtpca.c: In function 'hb_gt_pca_Init':
.../../gtpca.c:508: error: storage size of 'win' isn't known
.../../gtpca.c:510: error: 'TIOCGWINSZ' undeclared (first use in this
function)
.../../gtpca.c:510: error: (Each undeclared identifier is reported only
once
.
Cześć Przemek,
Although I declared that I could prepare binary builds for MSVC
not so long ago, things have changed significanly lately. Due to
serious healthy problems I've had recently, I won't be able to
participate in Harbour project for the next few weeks (at least).
I am really sorry I can
Guys,
5) the packagers will use the zip/tgz to create the binaries when
they'll have time and the binaries will be uploaded when and if
they'll be ready
Although I declared that I could prepare binary builds for MSVC
not so long ago, things have changed significanly lately. Due to
serious heal
Hi all,
And second thing. I would like to ask someone to control the release
process. Can some of you do it?
If you mean creating release and packages on a Sourceforge - I can.
What I don't know is how to tag the SVN as I did this with CVS.
I can prepare packages for MSVC 6.0, MSVC 8.0 a
How much difficult is for Harbour run as clr managed code?
Will harbour search same collaboration for having this capability?
http://www.dotgnu.org/, http://www.parrotcode.org/
http://ildjit.sourceforge.net/ http://dotgnu.info/
http://www.mono-project.com/Main_Page
It is *absolutly* boring to
Randy,
Is Harbour compatible with MSVC in Visual Studio 2005 and 2008?
It compiles and works ok when compiled with VC++ from Vs2005. It
*should* compile and run ok with VC++ from Vs2008, although I did
not perform any tests with VC++ from Vs2008. If I find some time
I'll try to verify Vs2008 s
2008-02-22 22:28 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/make_b32.mak
* Synchronized with make_vc.mak regarding HB_BUILD_ST and HB_BUILD_MODE
environment usage. There is still a difference between make_b32.mak
and make_vc.mak, because under BCC - ST mode is
Hi all,
Did anyone has a chance to play with "Linux in Windows"
called "anyLinux" - http://www.andlinux.org ?
AFAIK it's something like Wine for Linux, but the other
way around - it allows to run Linux programs in Windows,
by running Linux kernel as a native Windows program.
Anybody has any exp
2008-02-21 22:17 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/make_vc.mak
+ Added a possiblity to compile harbour in ST or MT mode by using
an environment variable called HB_BUILD_ST. Setting HB_BUILD_ST
to yes, causes Harbour+RTL+VM to be built in ST mode
Hi Przemek,
The problem was that WinDock is single-threaded and built for LIBC.
I rebuilt Harbour without the -MT switch and this fixed the problem.
My question is: Is it ok to build the current Harbour version without
the -MT switch so that it is single-threaded or is single-threaded
support
Hi Randy,
I have tried the various suggestions to eliminate these link errors:
LIBCMT.lib(dosmap.obj) : error LNK2005: __dosmaperr already defined in
LIBC.lib(dosmap.obj)
..
..
..
LIBCMT.lib(tolower.obj) : error LNK2005: _tolower already defined in
LIBC.lib(tolower.obj)
LINK : warning LNK409
Hi Paul,
I've simplified the msc startup hook, but don't have time to impliment
it right now.
#if defined(HB_PRAGMA_STARTUP)
#pragma startup hb_codepage_Init_BGMIK
#elif defined(HB_MSC_STARTUP)
#pragma data_seg( HB_MSC_START_SEGMENT )
static HB_$INITSYM hb_vm_auto_hb_codepage_Init_BGMIK
Jorge,
- Hope I'm reading right and my opinions are not out of focus...
Sure your input is welcome :). In such a case I will not remove
this feature :), until those who don't like it will get an overweight.
--
Marek
___
Harbour mailing list
Harbou
And I'll going to readd it after you've removed it
for your unknown reasons.
Make it an option which you can disable if it hurts you.
It seems you are alone. The group seems to not support you
in this case. Are you going to decide yourself, against the
group, what should or what should not be i
Hi Viktor
>> --
>> A remark :
>>
>> Newly updated files for unix like systems do not try to build
>> import libraries from respective packages. I was against this
>> move from the begining, because it is a user's responsibility
>> to have/create required import libraries, not a harbour on
Marek Paliwoda wrote :
There is a note in a ChageLog :
Oops ! Not in a ChageLog but in a post
announcing this ChangeLog entry. Sorry
for a confision.
--
Marek
--
Potega i sila na wyciagniecie reki - sprawdz!
Zagraj
Hi Viktor,
I seemed to have missed that. What will exactly be removed?
There is a note in a ChageLog :
2008-02-08 16:51 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
--
A remark :
Newly updated files for unix like systems do not try to build
import libraries from respective
Randy,
It did not fix the problem - Here is what I did:
- Created an environment var as: HB_BUILD_MODE=cpp
- Rebuilt Harbour
- Recompiled my app
- Re-linked my app
It means you are linking against libraries which were compiled
in "C" mode and were not recomplied (FieveWin ?). In this case
set
Viktor,
We have it because some packages won't supply a .lib file
for the compiler _type and version_ users might happen to use.
F.e. ADS will supply MSVC compatible .lib files, but none for
BCC55, which I personally (and pbly other ppl too) happen to
use.
It changes literaly nothing. It's a
Przemek,
[...]
This is part of batch file to create import library from .dll
I do not know why we have it. Valid import libraries may be
distributed by Extended System and we do not have to make
them ourself - the original import libraries may be differ
then the one we are creating. Additionally
Randy,
5. I can get my app to build, but get this warning:
LINK : warning LNK4089: all references to "ADVAPI32.dll" discarded
by /OPT:REF
Seems you do not use functions from ADVAPI32 library but you
specified /OPT:REF linker option and ADVAPI32 library in your
link command. Try removing ADVAP
Marek Paliwoda wrote :
>> I tried including -MT and the errors increased.
>
> Then try to disable a line 141 in harbour/make_vc.mak
> and line 121 in harbour/contrib/mtpl_vc.mak ( it looks
> like CFLAGS = -MT$(DBGMARKER) $(CFLAGS) ), rebuild Harbour
> and try to compile y
Randy,
4. I need to include "/NODEFAULTLIB:libcmt.lib" to get around link
errors - I'm not sure what the implications of this are.
Are you talking about compiling Harbour itself, or about compiling
your application ? In the later case I guess you did not specify
-MT option for compiling your a
Marek Paliwoda wrote :
I was not reffering to using hb_gc(Un)RegisterSweep(), especially
to protect pure GC blocks, because unlike you, I cannot imagine
any funcionality where such a feature could be utilized, as oposed
to returning such a block to PRG level and to store it there. I'd
gr
Hi Randy,
I am having the problems with the current build (note that none of these
issues occur with the Beta3 build) - I am using MSVC 6):
Exaclty which version ? With SP6 included ? My version of cl.exe reports :
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for
Hi Przemek,
I do not want to remove it yet because I can imagine some interesting
functionality for it without touching HB_ITEM internals though it will
be necessary to add one additional function for it: hb_gcMark( pGCBlock ).
And this is the reason why I asked about it. Does anyone created som
2008-02-15 10:52 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbnf/Makefile
* contrib/hbnf/common.mak
- contrib/hbnf/descend.c
+ contrib/hbnf/descendn.c
- contrib/hbnf/menuto.prg
+ contrib/hbnf/menutonf.prg
! Renamed some files in libnf to not collide
wit
2008-02-15 09:47 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/contrib/hbfimage/make_gcc.sh
! Fixed CFLAGS settings from a proper FREEIMAGE_INC envvar
* harbour/contrib/hbziparch/make_vc.bat
! Disabled warnings about functions considered "depreciated" by MS
Hi,
Actualy there are two file name conflicts between
source/rtl/descend.c and contrib/hbnf/descend.c
source/rtl/menuto.prg and contrib/hbnf/menuto.prg
I am not sure how it should be resolved, so I'd
like to ask someone to have a look at it.
--
Marek
_
2008-02-13 20:13 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/contrib/mtpl_vc.mak
! Enable compilation in C++ mode using HB_BUILD_MODE envvar
--
Marek Paliwoda
mpaliwoda at interia pl
--
Mamy nagrody
Hi Alex,
When trying to compile with Harbour from CVS and MSVC 8 (2005) I get:
rddcdx.lib(dbfcdx1.obj) : warning LNK4254: section '.CRT' (4040)
merged into
'.data' (C040) with different attributes
Microsoft discourages merging sections with different attributes
due to a serious sec
Mindaugas,
Yes, I think it's a good idea. We do not have many problem with GC in
3rd party software, because nobody are using collectible pointers yet,
Do you mean 3rd party software available publicly, or 3rd party software
used privately ? In the latter case it's not true, because I have be
Sorry Viktor,
Definitely.
I'd also vote to separate for full hbrdd/rdd*, otherwise
we will end up having lots of different combinations with
and without RDD, with and without MT, etc, and at the end
we will have the same amount of libs as we have now, just
the size will be be bigger.
To put it
2008-02-12 08:04 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/contrib/hbwhat32/make_gcc.sh
! Fixed compilation under MingW and Cygwin
* harbour/contrib/make_b32_all.bat
* harbour/contrib/make_vc_all.bat
+ Added hbwhat32 to a list of compiled contribs
* harbour
Hi Maurilio,
I think I've found what is causing that 'emxbind failed...' error, you're
probably using eCS and you have a emx\bin directory in your boot disk where
there is an old emxbind.exe which gets called before the one inside
gcc\usr\bin because you have an environment variable named 'PATH'
Przemek, Viktor,
> For PCRE we have set of macros you can set in C_USR
envvar before building Harbour to reach such effect, f.e. -DHB_POSIX_REGEX
We can use:
HB_POSIX_REGEX - use POSIX regex instead of PCRE, it should work
on all POSIX systems (f.e. in *nixes)
HB_PCRE
Marek Paliwoda wrote:
There are some techincal differences.
1. On some system it will be hard (or impossible) to overload some
subsystem using only libraries. F.e. nulrdd which should replaces
whole RDD tree for applications which do not want to use any
RDD releated code will not work
Przemyslaw Czerpak wrote :
On Sun, 10 Feb 2008, Szakáts Viktor wrote:
I disagree. Having them as separate libraries has no advantages.
I just made some tests with GTs under BCC and including them in
link command changes *nothing*, until you *explicitly* REQUEST
a particular GT. So having them a
Hi Viktor,
> >> I like it better still, because these are "plugins" in a sense.
> >
> > But this fact, "in a sense", has *zero* impact on a technical
> > problems
>
> In my first mail regarding this, I clearly wrote that
> while I see no TECHNICAL problems here, yet I (IMHO)
> find it better to ha
Hi Viktor,
> I like it better still, because these are "plugins" in a sense.
But this fact, "in a sense", has *zero* impact on a technical problems
we're trying to solve - cross library dependencies and simplification
of a link command.
Sorry, I totaly do not share your POV in this area.
--
Hi Viktor,
IMO we'll have to cleanup those few questions in my other
mail (from a few minutes ago), but other than that I fully
agree.
Remaining questions:
- Future hbzlib placement?
I did not investigate zlib/hbzlib problem. After all,
currently it's in contrib. But my experience with some
Marek Paliwoda wrote :
I investigated a problem a little bit more
It appears to me that introducing one common
static library will not collide with "1.0"
release because we can keep current separated
libs together with one common static lib for
say, next two releases, and encourage
Marek Paliwoda wrote :
This clearly means that compiler lib *should not* be
> included in dll/so builds
And fortunately this *is* true for an alternative build system :).
--
Marek
--
Myslisz, ze nie ma sniegu? Spra
Marek Paliwoda wrote :
[...]
One drawback which was mentioned on the list, is that we
have a different license for the compiler lib, the RTL
libs and pbly also PCRE.
O s... ;-), I completly forgot about. But it means that
we have problem with .dll (.so) builds also, haven't we
Hi Viktor,
[...]
One drawback which was mentioned on the list, is that we
have a different license for the compiler lib, the RTL
libs and pbly also PCRE.
O s... ;-), I completly forgot about. But it means that
we have problem with .dll (.so) builds also, haven't we ?
> We also have some mutu
2008-02-09 10:06 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/contrib/hbtpathy/tplinux.c
* harbour/contrib/hbtpathy/tpos2.c
* harbour/contrib/hbtpathy/tpwin32.c
* Fixed guarding file content with proper OS constant
(HB_OS_UNIX, HB_OS_WIN_32, HB_OS_OS2
Lorenzo,
Why should we not finish Harbour at this time?
Because the two main developers don't agree about latest changes.
It happens not the first time, and I hope not the last time ;-).
Many times the difference in opinions is a stimulating process.
Of course, sometimes it's a "destructive"
2008-02-08 16:51 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
+ harbour/contrib/gtwvg/make_gcc.sh
+ harbour/contrib/hbapollo/make_gcc.sh
+ harbour/contrib/hbclipsm/make_gcc.sh
+ harbour/contrib/hbct/make_gcc.sh
+ harbour/contrib/hbfbird/make_gcc.sh
+ harbour/contrib/hbfimage
David,
[...]
- As seen, Marek changes does not touch this case
My changes are not related to "standard build system" at all.
They have not corrected anything related to your testings,
because they were dine in "an alternative build system".
[...]
But seem Marek was building Harbour OK usin
David,
>Well, truely speaking I do not use OS/2 :). I simply had
>a chance to access an OS/2 system on my friend's computer.
>He bought OS/2 long ago (he says he payed too much for it
>;-)) and still has an old machine running OS/2 - because
>of a sentiment - I guess for the money he payed
Maurilio,
not to start a dispute on this issue, but while it is true that IBM is no more
selling OS/2 to end-users, the OS, for end-users, is now on the hands of the
eComStation guys which are doing a really good work in enhancing/supporting
it.
You can go to www.ecomstation.com to see.
No do
Hi David,
>2008-02-06 11:08 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
> * harbour/common.mak
> * harbour/make_gcc.mak
> * harbour/make_gcc.sh
> ! Some fixes for OS/2+eComStation. Still not all is working ok
>(dlls)
Can you explain what is not worki
2008-02-06 11:08 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/common.mak
* harbour/make_gcc.mak
* harbour/make_gcc.sh
! Some fixes for OS/2+eComStation. Still not all is working ok (dlls)
--
Marek Paliwoda
mpaliwoda at interia pl
2008-02-04 22:57 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* harbour/common.mak
* harbour/make_gcc.mak
! Fixed compilation under DJGPP
* contrib/mtpl_gcc.mak
! Fixed compilation under GNU make
I am not sure everything is ok with this commit,
because there was a confict
Marek Paliwoda pisze:
because I am an author of an original idea, and
In fact, the original author of this idea was *Ryszard*
(sorry Ryszard, I forgot this), but he only used it internally,
inside GC. What I did was exposing this idea to public, by
introducing "finalizers" for HB_
Hi Viktor,
Similarly to hb_parptr() it stores pointer,
No, it retrieves pointer, not stores it.
> but unlike hb_parptr() you can attach a callback function
No, you do not attach a callback function in hb_parptrGC.
Attachement is done inside hb_gcAlloc(). See the sources.
to the variable, w
Przemyslaw Czerpak pisze:
On Sat, 02 Feb 2008, Marek Paliwoda wrote:
Hi All,
void* ptr = hb_parptrGC( hb_fctx_destructor, 1 );
Could someone explain me what is the purpose of hb_parptrGC() ?
It's used for verification if given parameter holds pointer item
with pointer which poin
Hi All,
void* ptr = hb_parptrGC( hb_fctx_destructor, 1 );
Could someone explain me what is the purpose of hb_parptrGC() ?
--
Marek
--
Zmus swojego faceta, zeby to przeczytal
Kliknij >>> http://link.interia.pl/f1ceb
__
Marek Paliwoda pisze:
And now the old item stored in h previously, does not belong
to any item and it is freed by GC.
Should be read as "to any place known to GC" or "to any host
variable like : local,static,private,public,or hb_itemNew
Hi Mindaugas,
I expect pointer not to be collected, because it "lives" in variable h.
No. Not always. See below ...
What's wrong with my code?
Read below ...
PROC main()
LOCAL h
h := myfunc( h )
You call h := myfunc( h ). h is empty so hb_gcAlloc()
is called in myfunc() and the resul
Viktor,
2008-01-31 19:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/make_gcc_all.sh
! Added SVN header.
* contrib/hbgf/win32/common.mak
! Same change done as on the other 'common.mak's in contrib.
Oops ! Thanks.
--
Marek
__
2008-01-31 18:41 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
+ contrib/mtpl_gcc.mak
+ Readded to SVN yet another time
--
Marek Paliwoda
mpaliwoda at interia pl
___
Harbour mailing list
Harbour@harbour-project.org
http
2008-01-31 18:29 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* contrib/gtwvg/common.mak
* contrib/hbapollo/common.mak
* contrib/hbbmcdx/common.mak
* contrib/hbbtree/common.mak
* contrib/hbclipsm/common.mak
* contrib/hbct/common.mak
* contrib/hbfbird/common.mak
Hi Viktor,
This broke the normal BCC build method because
you've changed the forward slash to backslash in
common.mak, and now TLIB wants to process some
path names as command line switches.
Ok, I've got it. I'll revert the change imidiately.
--
Marek
___
Hi Lorenzo,
I'd propose to revert and discuss your change
and implement it after the release. Only fixes
are permitted since last week in the repository.
Just my personal opinion but such deep changes to the build system
right before RC1 is not a good idea. What about hb-func.sh? What about
rp
Hi Viktor,
This broke the normal BCC build method because
you've changed the forward slash to backslash in
common.mak, and now TLIB wants to process some
path names as command line switches.
Everything builds *without* problems here
either with Bcc or Msvc. I'd suggest to check
your environmen
2008-01-30 21:30 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* contrib/gtwvg/common.mak
* contrib/hbapollo/common.mak
* contrib/hbbmcdx/common.mak
* contrib/hbbtree/common.mak
* contrib/hbclipsm/common.mak
* contrib/hbct/common.mak
* contrib/hbfbird/common.mak
2008-01-26 22:42 UTC+0100 Marek Paliwoda (mpaliwoda at interia pl)
* make_gcc.mak
+ Added an extra compilation phase for building
shared VM+RTL library (if needed)
! Some minor fixes and cleanup
--
Marek Paliwoda
mpaliwoda at interia pl
Hi,
Compiling Harbour under Cygwin I get the following errors :
source/rtl/filesys.c: In function `hb_fsPOpen':
source/rtl/filesys.c:590: warning: passing arg 1 of `pipe' from incompatible
pointer type
source/rtl/gtxwc/gtxwc.c:195: error: `K_SH_UP' undeclared here (not in a
function)
source/
1 - 100 of 121 matches
Mail list logo
