Good morning Przemyslaw and Viktor,
first of all you have to answer a question I'm asking myself since a long
time: how are you able to avoid sleeping and still be able to write such good
code?? I see messages of yours during all night: 00.46, 01.17, 01.49, 02.53,
03.45, 04.17, 04.48, 08.50!!
Maurilio Longo wrote:
Good morning Przemyslaw and Viktor,
first of all you have to answer a question I'm asking myself since a long
time: how are you able to avoid sleeping and still be able to write such good
code?? I see messages of yours during all night: 00.46, 01.17, 01.49, 02.53,
03.45,
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
Hi,
[ BTW it's not fully compatible, as C5.3 returned the old
dev mode value. ]
Yes, I know. I think we should change:
BOOL hb_fsSetDevMode( HB_FHANDLE hFileHandle, USHORT uiDevMode )
to:
int hb_fsSetDevMode( HB_FHANDLE hFileHandle, int
Hi Przemek,
I've already made this modification then I also made some tests with
FSETDEVMOD() in C53 and before I'll commit it I have two questions:
1. CL53 returns only 1 or 2 and nothing more to indicate errors.
Should I replicate it?
2. In tests it looks that it has some logic to return
Przemyslaw,
hb_compile() emits '\n' instead of '\n\r' when it needs to go to the next line.
I think that on OS/2 and on DOS this is not enough to go to the next line
.AND. to column 0.
Shouldn't it use hb_OSNewLine() to fetch the correct EOL to use?
I see such problem on hbmk2 which has this
On Mon, 30 Nov 2009, Maurilio Longo wrote:
Hi,
hb_compile() emits '\n' instead of '\n\r' when it needs to go to the next
line.
I think that on OS/2 and on DOS this is not enough to go to the next line
.AND. to column 0.
Shouldn't it use hb_OSNewLine() to fetch the correct EOL to use?
\n
Przemyslaw,
could it be that OS/2 and DOS always require stdout/stderr to be in text mode?
Maurilio.
Przemysław Czerpak wrote:
On Mon, 30 Nov 2009, Maurilio Longo wrote:
Hi,
hb_compile() emits '\n' instead of '\n\r' when it needs to go to the next
line.
I think that on OS/2 and on DOS
\n is correct. Please note that using standalone compiler with
exactly the same code you do not have stairs effect problem.
Just simply by default \n in stdout and stderr streams are
automatically translated to \r\n if it's necessary.
I see such problem on hbmk2 which has this kinf of
BTW for me more important is removing space padding in hbmk2 output,
i.e. try to redirect any hbmk2 output to file to see it.
If you mean left padding, it's there to spit out
readable output. If you just dump all long lines to
terminal, it would look like an ugly mess. (that's
where I
On Mon, 30 Nov 2009, Szak�ts Viktor wrote:
Hi,
Then someone will have to teach me how to
produce adequate output for console apps in a
multiplatform way.
Please start looking for output for any C compiler we are
using or any other console tool.
harbour.exe output is also good example. It
Please start looking for output for any C compiler we are
using or any other console tool.
harbour.exe output is also good example. It does not use any
space padding.
Or someone solves it instead of me.
Again: Plain output looked almost unbearable. Maybe
this is normal for portable apps,
On Mon, 30 Nov 2009, Szak�ts Viktor wrote:
Hi,
If you can give me any sort of advice how to format
output so that it stays readable even on regular screens
like y*80, please do. I can't expect users to have screens
400 chars wide to fit some stuff.
The only one thing I'm asking you is
If you can give me any sort of advice how to format
output so that it stays readable even on regular screens
like y*80, please do. I can't expect users to have screens
400 chars wide to fit some stuff.
The only one thing I'm asking you is removing unnecessary _trailing_ spaces.
This
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
I'm also not a fun of breaking the line to 79 columns especially when
output is redirected because it makes output parsing much harder but I can
leave with it. It would be nice to make:
hbmk2 -info ... | grep ^hbmk2:
and catch only and _full_
In *nixes we can check if output is TTY device.
If not then we it's redirected to sth else, i.e. pipe, file, socket.
In filesys.c hb_fsIsDevice() function can be used for it and in *nixes
it will work as we want but I do not know how it will work in MS-Windows
with different shells (i.e.
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
If not then we it's redirected to sth else, i.e. pipe, file, socket.
In filesys.c hb_fsIsDevice() function can be used for it and in *nixes
it will work as we want but I do not know how it will work in MS-Windows
with different shells (i.e.
#pragma begindump
#include hbapifs.h
HB_FUNC( HB_FISDEVICE )
{
hb_retl( hb_fsIsDevice( hb_numToHandle( hb_parnint( 1 ) ) ) );
}
#pragma enddump
Looks good on win, I'm getting .F. on 1 and 2 if I
redirect output to a file.
Fine. Please also check
tst.exe | grep .
to check
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
Fine. Please also check
tst.exe | grep .
to check the results for pipes.
I've just check that in DOS OpenWatcom builds it works as we want.
Works fine with mingw + cmd.exe.
Also works fine with mingw + msys.
In DJGPP builds with COMMAND.COM
18 matches
Mail list logo
