2008-07-08 08:29 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* contrib/hbodbc/odbc.c
! Fixed compilation error with Pelles C 5.00.1.
* Some formatting.
* contrib/hbw32/dllcall.c
+ Two TOFIXes added for Win64 support.
! One Warning fixed under Win64.
* contrib/hbfim
2008-07-08 07:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* contrib/hbodbc/odbc.c
! Fixed all ODBC handles to be pointers. This way it's Win64
compatible. This is an INCOMPATIBLE change. Since normal
app code is using ODBC error values to check for error
condit
Sorry Przemek, I could not have read your changelog until after my post.
Tomorrow I see but... good work!. Thank you.
Best regards,
Xavi
Javier escribió:
Przemek,
IMHO: Yes, I think that it is better don't force the parameters to
string and more thinking of the HRB's power.
I also think that
Przemek,
IMHO: Yes, I think that it is better don't force the parameters to
string and more thinking of the HRB's power.
I also think that it is very good solution pHrb in collectible pointer:
very sure and avoid possibles memory leaks.
The only thing I dislike is having the new pHrbBodyGC of _
2008-07-08 02:27 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/runner.c
+ added support for passing non string parameters to .HRB INIT/
procedures/function
+ added automatic destructors for .HRB modules
; TOFIX: add protection against possible double e
2008-07-08 00:38 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbdefs.h
* disabled internal pointer handles I enabled by mistake for MS-WIN
builds
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.
2008-07-08 00:35 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapifs.h
* harbour/include/hbdefs.h
* harbour/source/rtl/console.c
* harbour/source/rtl/philes.c
* harbour/source/rtl/hbgtcore.c
* harbour/source/rtl/fstemp.c
* harbour/source/rtl/philes53.c
* h
Missed this change from the ChangeLog:
2008-07-07 17:41 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
...
* source/rtl/hbffind.c
! Added workaround for PellesC 5.00.1 compiler bug
(hang -> out of memory) when compiling a certain expression.
...
--
Brgds,
Viktor
__
2008-07-08 00:07 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/compiler/genhrb.c
* contrib/hbtip/utils.c
! Changed octal values in strings (and chars too) to make
these functions work with Pelles C 5.00.1.
--
Brgds,
Viktor
__
Hi Viktor,
IMO, it is a bug in Clipper - It should throw a runtime error - IOW,
the app thinks it wrote data but the data was never written (ie. was
lost) and therefore, that's a bug!
I see no practical reason why someone would want to do this AND I
can see that a developer would want to
Hi Przemek,
Ok, but I disagree with this one - IMO, it is a bug in Clipper which
should not be Harbour.
Regards,
Randy.
At 05:33 PM 7/7/2008, you wrote:
On Mon, 07 Jul 2008, Randy Portnoff wrote:
> Hi Przemek,
> I don't think you understand what I mean...
> In Clipper, if you attempt to upd
Hello All
Please visit:
http://www.vouch.info/harbour
and click on any function. It will exapand to show you the source
of that function. Click again and it is collapsed. Please be patient
if page loading time is more as every source folder is documented
in one file.
Still work-in-progress.
On Mon, 07 Jul 2008, Randy Portnoff wrote:
> Hi Przemek,
> I don't think you understand what I mean...
> In Clipper, if you attempt to update a record when at EOF (ie. by
> mistake), it does NOT cause a runtime error (which is bad!).
Yes, it is.
> Harbour,
> on the other hand, does generate a r
Hi Viktor,
IMO, it is a bug in Clipper - It should throw a runtime error - IOW,
the app thinks it wrote data but the data was never written (ie. was
lost) and therefore, that's a bug!
I see no practical reason why someone would want to do this AND I can
see that a developer would want to kno
Hi Randy and all,
I'd vote to make Harbour Clipper compatible, unless
we have a strong reason against this practice (like
the behaviour in Clipper is inconsistent or erroneous).
Brgds,
Viktor
On 2008.07.07., at 21:02, Randy Portnoff wrote:
Hi all,
When at EOF() and attempt to replace a field
Hi Przemek,
I don't think you understand what I mean...
In Clipper, if you attempt to update a record when at EOF (ie. by
mistake), it does NOT cause a runtime error (which is bad!). Harbour,
on the other hand, does generate a runtime error (which is good!).
However, what I am saying is that
On Mon, 07 Jul 2008, Szakáts Viktor wrote:
> Hi Przemek,
> Exactly the same as with Pelles C 4.50.
> Which is in turn exactly the same as BCC55.
Then it's probably caused by this conversion:
../../genhrb.c(88): warning #2223: Unable to convert character
'\u00c0' to codepage 1250; using default.
On Mon, 07 Jul 2008, Randy Portnoff wrote:
Hi Randy,
> When at EOF() and attempt to replace a field, get runtime error as
> "Variable does not exist" - This is better than Clipper which does
> not throw an error at all, but I think a more meaningful error
> message should be used like: "Attemp
On Mon, 07 Jul 2008, Javier wrote:
Hi Javier,
> If I have understood well I agree with best solution is automatic
> destructors for pHrb type pointer and them automatic call hb_hrbUnLoad()
> when release, in other words, do you plan to convert pHrb in collectible
> pointer?
> pHrb := __hrbLoad
Hi all,
When at EOF() and attempt to replace a field, get runtime error as
"Variable does not exist" - This is better than Clipper which does
not throw an error at all, but I think a more meaningful error
message should be used like: "Attempt to update record while at EOF".
Regards,
Randy.
Hi Przemek,
If I have understood well I agree with best solution is automatic
destructors for pHrb type pointer and them automatic call hb_hrbUnLoad()
when release, in other words, do you plan to convert pHrb in collectible
pointer?
pHrb := __hrbLoad( cHrb ) // pHrb it's the unique instan
Hi Przemek,
2008-07-07 19:32 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/vm/arrayshb.c
* contrib/xhb/xhbfunc.c
! Moved hb_ArrayID() Harbour level function to xhb.lib.
; NOTE: This function is not compatible with x64 architecture.
It can be updated for WIN64 (please re
2008-07-07 20:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* contrib/xhb/xhbfunc.c
! Changed hb_ArrayID() to be in sync with xhb, and at the
same time fixing the Win64 compatibility issue.
Thanks Przemek.
* ChangeLog
! Typo.
--
Brgds,
Viktor
___
On Mon, 07 Jul 2008, Szakáts Viktor wrote:
Hi Viktor,
> 2008-07-07 19:32 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
>* source/vm/arrayshb.c
>* contrib/xhb/xhbfunc.c
> ! Moved hb_ArrayID() Harbour level function to xhb.lib.
> ; NOTE: This function is not compatible with x64 a
2008-07-07 19:32 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/vm/arrayshb.c
* contrib/xhb/xhbfunc.c
! Moved hb_ArrayID() Harbour level function to xhb.lib.
; NOTE: This function is not compatible with x64 architecture.
--
Brgds,
Viktor
___
Hi Przemek,
I'd like to propose to either rename hb_ArrayID() function
to __ArrayID() and/or move it to contrib/xhb.
This is pretty much alien for a language, and it doesn't work
reliably in 64bit. (and cannot even be fixed without breaking
compatibility)
If you are talking about .prg functi
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
---
On Mon, 07 Jul 2008, Szakáts Viktor wrote:
Hi Viktor,
> I'd like to propose to either rename hb_ArrayID() function
> to __ArrayID() and/or move it to contrib/xhb.
> This is pretty much alien for a language, and it doesn't work
> reliably in 64bit. (and cannot even be fixed without breaking
> comp
../../atnum.c(254): fatal error: Internal error: reduce_tree().
../../odbc.c(402): error #2140: Type error in argument 4 to
'SQLExtendedFetch'; found 'unsigned long long int *', expected
'unsigned long int *'.
../../genhrb.c(88): warning #2223: Unable to convert character
'\u00c0' to codepag
2008-07-07 17:41 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/vm/extrap.c
! Warning fixed.
* contrib/hbmysql/mysql.c
* contrib/hbmysql/tmysql.prg
! sqlListF() return value changed to pointer from numeric.
Now compatible with Win64.
INCOMPATIBLE.
* co
Hi all,
I'd like to propose to either rename hb_ArrayID() function
to __ArrayID() and/or move it to contrib/xhb.
This is pretty much alien for a language, and it doesn't work
reliably in 64bit. (and cannot even be fixed without breaking
compatibility)
Opinions?
Brgds,
Viktor
_
Hi Przemek,
Exactly the same as with Pelles C 4.50.
Which is in turn exactly the same as BCC55.
Brgds,
Viktor
On 2008.07.07., at 17:03, Przemyslaw Czerpak wrote:
On Mon, 07 Jul 2008, Szakáts Viktor wrote:
Hi Viktor,
Yes.
And what are the results?
The same as in other builds?
best regard
On Mon, 07 Jul 2008, Szakáts Viktor wrote:
Hi Viktor,
> Yes.
And what are the results?
The same as in other builds?
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Yes, I am using the /u switch.
At 08:09 PM 7/4/2008, you wrote:
Hi Randy,
Okay, thanks I'll fix this. You seem to be using /u switch with
Harbour, which got broken lately in this respect.
Brgds,
Viktor
On 2008.07.04., at 22:37, Randy Portnoff wrote:
I seems I now have to define __HARBOUR__
Yes.
On 2008.07.07., at 15:26, Massimo Belgrano wrote:
Hbtest work fine?
-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] Per conto di Szakáts Viktor
Inviato: lunedì 7 luglio 2008 14.25
A: Harbour Project Main Developer List.
Oggetto: [Harbour] PellesC 5.00.1 a
Hbtest work fine?
-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Szakáts Viktor
Inviato: lunedì 7 luglio 2008 14.25
A: Harbour Project Main Developer List.
Oggetto: [Harbour] PellesC 5.00.1 and hbdot problem.
Hi all,
After a seemingly successful build
Hi all,
After a seemingly successful build (with latest revision),
with only a few warnings here and there, I'm getting the
attached screen if '? version()' is keyed into
hbdot.exe.
What could be the problem?
Brgds,
Viktor
<>
___
Harbour mailing li
I positive vote also
- Messaggio originale -
Da: Szakáts Viktor <[EMAIL PROTECTED]>
Inviato: lunedi 7 luglio 2008 14.03
A: Harbour Project Main Developer List.
Oggetto: Re: [Harbour] Change in runner.c __HRBLOAD()
>> The problem is that __hrbLoad() return the pointer of hrb in the
>> s
2008-07-07 13:50 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/rtl/hbffind.c
! Added workaround for PellesC 5.00.1 hang bug.
* config/w32/pocc.cf
% Removed unnecessary '-I' switches.
! Removed ws2.lib from liblist to make it link with PellesC 5.00.1
(where th
The problem is that __hrbLoad() return the pointer of hrb in the
stack
return not in the stack parameter frame.-
As you can see above it's not a problem but it forces that user have
to create additional hack. Storing pointers in parameters is also
such hack though done in different way inside
On Sun, 06 Jul 2008, Javier wrote:
Hi Javier,
> Sorry for my wrong explanation, my problem is that I costs less program it
> that write this post. :'(
> Please, see my Test() function if there is error in the init functions of
> hrb, __hrbLoad() returns a wrong pointer (normally nil) disabling
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'[dbo].[
2008-07-07 12:48 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/compiler/gencc.c
! fixed bud with wrong C code generated for doubly negated integer
values reported by Viktor.
best regards
Przemek
___
Harbour mailing lis
On Mon, 07 Jul 2008, Marek Paliwoda wrote:
Hi Marek,
> 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-mi
Hello Petr,
I apologize for the delay in my reply.
But I
can not send the prg to control. There are nearly 2000-line program and
then the programme integrates into a project more complex.
Looking at the programme I noticed that the PDF creation, with the
pdfcreator takes place using the li
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
47 matches
Mail list logo
