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
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
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
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
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
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
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 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
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
Hi Randy,
Thanks a lot. Some of these warnings are known ones, most of them
is complaining about integer size differences, which we have a lot.
I've committed a fix.
Brgds,
Viktor
On 2008.07.30., at 17:24, Randy Portnoff wrote:
Hi Viktor,
Attached are two logs (one for HARBOUR and one for R
Hi Viktor,
Attached are two logs (one for HARBOUR and one for RDDADS) which
contain some warnings when built using MSVC 12.00.8804.
Regards,
Randy.
At 09:57 AM 7/30/2008, you wrote:
Hi all,
I'd like to ask everyone to try as many kinds of
builds as possible and report any results on the
li
On Wed, 30 Jul 2008, Szakáts Viktor wrote:
> [ It's a problem though that for some reason hbmzip's
> encryption is not even compatible with info-zip. ]
It's PKZIP compatible and info-zip should understand it.
I've just check that it doesn't but because hbmzip can
decompress encrypted PKZIP archive
On Wed, Jul 30, 2008 at 3:57 PM, Szakáts Viktor <[EMAIL PROTECTED]> 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.
At changelog 2008-07-30 16:30 UTC+0200 Przemyslaw Czerp
Hi Miguel,
We're going on with the release, if these problems get
fixed in the meantime the better, but these are not
showstoppers (I'm not even sure they are needed for
a portable .zip implementation and/or are easy fixes,
but rather new features). Also we should be careful
about WinZip specific
Please you can wait for release
mzip needs to solve large names under windows platforms
and compatible passwords with winzip password length need 10 char.
Best regards,
Miguel Angel Marchuet
Szakáts Viktor escribió:
Hi all,
I'd like to ask everyone to try as many kinds of
builds as possible a
Hi Ciro,
make_gnu.bat. You'll need the GNU make.exe (f.e. the MinGW one)
to be in the path.
Brgds,
Viktor
On 2008.07.30., at 16:29, Ciro Vargas Clemow wrote:
Szakáts Viktor escribió:
Hi Victor:
Wich Batch file must be use to build harbour for pelles C ?
best regards
Ciro
Hi all,
I'd li
Szakáts Viktor escribió:
Hi Victor:
Wich Batch file must be use to build harbour for pelles C ?
best regards
Ciro
Hi all,
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.
Passed:
Hi all,
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.
Passed:
- Windows
BCC55
BCC58
MinGW 4.12
MSVS 2005
MSVS 2005 C++,
MSVS 2008
21 matches
Mail list logo