[Harbour] OpenSSl
not possovel use Openssl with BCC? I'm trying to generate binaries with Build 13000. -- View this message in context: http://old.nabble.com/OpenSSl-tp26490130p26490130.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13000] trunk/harbour
Revision: 13000 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13000&view=rev Author: vouchcac Date: 2009-11-24 02:08:19 + (Tue, 24 Nov 2009) Log Message: --- 2009-11-23 18:09 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg ! Few more additions. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12999] trunk/harbour
Revision: 12999 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12999&view=rev Author: druzus Date: 2009-11-24 01:51:43 + (Tue, 24 Nov 2009) Log Message: --- 2009-11-24 02:51 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/dlmalloc.c * harbour/src/vm/hvmall.c + added support for DLMALLOC in OS/2 builds. I would like to ask OS/2 users to make harbour OS/2 build tests using WATCOM and GCC with HB_USER_CFLAGS=-DHB_FM_DL_ALLOC to check if it works. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/vm/dlmalloc.c trunk/harbour/src/vm/hvmall.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12970] trunk/harbour
On Tue, 24 Nov 2009, Mindaugas Kavaliauskas wrote: Hi, > > * harbour/src/vm/fm.c > >* enabled HB_FM_DLMT_ALLOC by default in MT HVM if HB_FM_DL_ALLOC is > > also enabled > BTW, what is HB_FM_DLMT_ALLOC performance in comparison to native > Linux malloc() (in MT mode of cause)? It's not trivial to well compare performance of different memory allocators in MT mode. To give precise answer we should prepare some series of dedicated tests anyhow using speedtst.prg in different mode we can create basic tests and the performance seems to be quite good. In practice the same as with NEDMALLOC or PTMALLOC but this is nearly the same code so it's expected. DLMALLOC is compiled as part of Harbour core code with strong optimization switches and well optimized as part of hvmall.c so it's usually a little bit faster in all tests. SUSE Linux uses Hoard Memory Allocator which seems to be the best memory allocator for MT mode. In older SUSE builds I made some tests on x...@32 and it was always faster then DLMALLOC in ST and MT modes. Recently I've repeated test with SUSE 11.2 x...@64 and in ST mode DLMALLOC is faster but slower in MT mode. I guess that faster ST mode is mostly result of better optimizations when DLMALLOC is compiled as part of hvmall.c. In MT mode is slower but the difference is not very huge in concurrent access when HB_FM_DLMT_ALLOC is enabled, here are results you can compare: 1) ./speedtst DLMALLOC ST mode: [ total application time: ]15.47 [ total real time: ]...15.47 Hoard ST mode: [ total application time: ]16.76 [ total real time: ]...16.78 2) ./speedtst DLMT MT MODE: [ total application time: ]19.58 [ total real time: ]...19.59 Hoard ST mode: [ total application time: ]18.50 [ total real time: ]...18.50 3) ./speedtst --thread DLMT [ total application time: ]26.65 [ total real time: ]9.73 Hoard: [ total application time: ]24.37 [ total real time: ]8.68 4) ./speedtst --thread=3 --scale DLMT: [ TOTAL ]_ 59.95 29.64 -> 2.02 [ total application time: ]...147.05 [ total real time: ]...89.60 Hoard: [ TOTAL ]_ 57.93 32.01 -> 1.81 [ total application time: ]...149.78 [ total real time: ]...89.95 As you can see in the last test DLMT has even better scalability what allows to reduce the speed difference and DLMT was finally a little bit faster. Anyhow this test uses only 3 threads which very nicely play with DLMT and I expect that when much bigger number of threads is used on multi CPU hardware then Hoard will be more efficient i.e. in test (3) we have 56 threads and here Hoard is still faster. But of course it does not change the fact that DLMT results are really good. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Re: Re: Re: Re: Win_prn problem.
Itamar,
> But not is possible yet print draw box double horizontal for example. I get
> Í
This seems a conflict with charset.
http://msdn.microsoft.com/en-us/library/dd183499%28VS.85%29.aspx
Please read fdwCharSet parameter if it can help you.
oPrn:CharSet(OEM_CHARSET)
oPrn:Setfont('Lucida Console',,11) // oPrn:Setfont('Terminal',,12)
Please Viktor, is it possible to update hbwin.ch?
--
Xavi
Viktor Szakáts escribió:
Hi!
The return of command "oPrn:TextOut('Font Is: '+oPrn:FontName,.t.)" is
correct now.
Amen.
But not is possible yet print draw box double horizontal for example. I get
Í
I'll let someone else to solve this for you,
anyhow it's not a Harbour bug.
Brgds,
Viktor
/*
* $Id: hbwin.ch 12732 2009-10-19 21:17:04Z vszakats $
*/
/*
* Harbour Project source code:
* hbwin header
*
* Copyright 2008 Viktor Szakats (harbour.01 syenar.hu)
* Copyright 2004 Peter Rees
*Rees Software & Systems Ltd
* www - http://www.harbour-project.org
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2, or (at your option)
* any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this software; see the file COPYING. If not, write to
* the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
* Boston, MA 02111-1307 USA (or visit the web site http://www.gnu.org/).
*
* As a special exception, the Harbour Project gives permission for
* additional uses of the text contained in its release of Harbour.
*
* The exception is that, if you link the Harbour libraries with other
* files to produce an executable, this does not by itself cause the
* resulting executable to be covered by the GNU General Public License.
* Your use of that executable is in no way restricted on account of
* linking the Harbour library code into it.
*
* This exception does not however invalidate any other reasons why
* the executable file might be covered by the GNU General Public License.
*
* This exception applies only to the code released by the Harbour
* Project under the name Harbour. If you copy code from other
* Harbour Project or Free Software Foundation releases into a copy of
* Harbour, as the General Public License permits, the exception does
* not apply to the code that you add in this way. To avoid misleading
* anyone as to the status of such modified files, you must delete
* this exception notice from them.
*
* If you write modifications of your own for Harbour, it is your choice
* whether to permit this exception to apply to your modifications.
* If you do not wish that, delete this exception notice.
*
*/
#ifndef HBWIN_CH_
#define HBWIN_CH_
/* Registry related values */
#define HKEY_CLASSES_ROOT 0x8000
#define HKEY_CURRENT_USER 0x8001
#define HKEY_LOCAL_MACHINE 0x8002
#define HKEY_USERS 0x8003
#define HKEY_PERFORMANCE_DATA 0x8004
#define HKEY_CURRENT_CONFIG0x8005
#define HKEY_DYN_DATA 0x8006
/* win_Port() related values */
/* The following are from winbase.h */
#define CBR_110110
#define CBR_300300
#define CBR_600600
#define CBR_1200 1200
#define CBR_2400 2400
#define CBR_4800 4800
#define CBR_9600 9600
#define CBR_14400 14400
#define CBR_19200 19200
#define CBR_38400 38400
#define CBR_56000 56000
#define CBR_57600 57600
#define CBR_115200 115200
#define CBR_128000 128000
#define CBR_256000 256000
#define NOPARITY 0
#define ODDPARITY 1
#define EVENPARITY 2
#define MARKPARITY 3
#define SPACEPARITY4
#define ONESTOPBIT 0
#define ONE5STOPBITS 1
#define TWOSTOPBITS2
/* DTR Control Flow Values. */
#define DTR_CONTROL_DISABLE0x00
#define DTR_CONTROL_ENABLE 0x01
#define DTR_CONTROL_HANDSHAKE 0x02
/* RTS Control Flow Values */
#define RTS_CONTROL_DISABLE0x00
#define RTS_CONTROL_ENABLE 0x01
#define RTS_CONTROL_HANDSHAKE 0x02
#define RTS_CONTROL_TOGGLE 0x03
#define WIN_COM_DBGBASIC 0x01
#define WIN_COM_DBGFLOW0x02
#define WIN_COM_DBGXTRAFLOW0x04
#define WIN_COM_DBGOTHER 0x08
#define WIN_COM_DBGTIMEOUTS0x10
#define WIN_COM_DBGQUEUE 0x20
#define WIN_COM_DBGALL 0x3F
/* win_Prn() related values */
#define FORM_A49
#define PS_SOLID 0
#define RGB( nR, nG, nB )
[Harbour] SF.net SVN: harbour-project:[12998] trunk/harbour
Revision: 12998 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12998&view=rev Author: vouchcac Date: 2009-11-24 01:25:05 + (Tue, 24 Nov 2009) Log Message: --- 2009-11-23 17:21 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.hbp * contrib/hbide/hbide.prg + contrib/hbide/idemisc.prg ! Implemented to execute context sensitive popups. Right click on right-hand area. * contrib/hbxbp/xbpdialog.prg * contrib/hbxbp/xbplistbox.prg * contrib/hbxbp/xbptreeview.prg * contrib/hbxbp/xbpwindow.prg + Neccessary constructs to honour context menu requests. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.hbp trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbxbp/xbpdialog.prg trunk/harbour/contrib/hbxbp/xbplistbox.prg trunk/harbour/contrib/hbxbp/xbptreeview.prg trunk/harbour/contrib/hbxbp/xbpwindow.prg Added Paths: --- trunk/harbour/contrib/hbide/idemisc.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] how to build hbqt library under Windows?
Massimo Belgrano said: try SET HB_WITH_QT=c:\devl\qt\2009.04\qt\include set HB_DIR_QT=c:\devl\qt\2009.04\qt ok Massimo thank you Leandro ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] how to build hbqt library under Windows?
try
SET HB_WITH_QT=c:\devl\qt\2009.04\qt\include
set HB_DIR_QT=c:\devl\qt\2009.04\qt
2009/11/24 Leandro Damasio :
> I'm using WinxP SP3 + mingw32 + Qt 4.5
>
> Mingw32-make results on the following:
>
> C:\harbour\contrib\hbqt>mingw32-make -f makefile
> ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
> ! MAKE: mingw32-make 3.81 sh.exe
> ! HB_INSTALL_PREFIX: c:\harbour
> ! HB_LIB_INSTALL: c:\harbour\lib
> ! HB_INC_INSTALL: c:\harbour\include
> ! HB_HOST_PLAT: win (x86) HB_SHELL: nt
> ! HB_PLATFORM: win (x86) (autodetected)
> ! HB_COMPILER: mingw
> ! Component: 'zlib' found in C:/harbour/external/zlib (local)
> ! Component: 'pcre' found in C:/harbour/external/pcre (local)
> ! Component: 'openssl' not found
> ! Component: 'gpm' not supported on win platform
> ! Component: 'slang' not found
> ! Component: 'curses' not found
> ! Component: 'x11' not found
> ! Component: 'wattcp/watt-32' not supported on win platform
> ! 'hbqt' library skipped ('qt' not found)
>
> Is it necessary to install all this "not found" libs above to build hbqt?
>
> Thanks
> Leandro Damasio
--
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Singleton
Is there native support to singleton (design pattern) classes in harbour? Thanks Leandro Rocha ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] how to build hbqt library under Windows?
I'm using WinxP SP3 + mingw32 + Qt 4.5
Mingw32-make results on the following:
C:\harbour\contrib\hbqt>mingw32-make -f makefile
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: mingw32-make 3.81 sh.exe
! HB_INSTALL_PREFIX: c:\harbour
! HB_LIB_INSTALL: c:\harbour\lib
! HB_INC_INSTALL: c:\harbour\include
! HB_HOST_PLAT: win (x86) HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: mingw
! Component: 'zlib' found in C:/harbour/external/zlib (local)
! Component: 'pcre' found in C:/harbour/external/pcre (local)
! Component: 'openssl' not found
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found
! Component: 'curses' not found
! Component: 'x11' not found
! Component: 'wattcp/watt-32' not supported on win platform
! 'hbqt' library skipped ('qt' not found)
Is it necessary to install all this "not found" libs above to build hbqt?
Thanks
Leandro Damasio___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12970] trunk/harbour
Hi, * harbour/src/vm/fm.c * enabled HB_FM_DLMT_ALLOC by default in MT HVM if HB_FM_DL_ALLOC is also enabled BTW, what is HB_FM_DLMT_ALLOC performance in comparison to native Linux malloc() (in MT mode of cause)? Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Mon, 23 Nov 2009, Szak�ts Viktor wrote:
Hi,
> I made a test on the Windows llvm-gcc build, and there apparently
> a similar problem exist where llvm-gcc.exe tries to execute
> as.exe (which is not supplied) instead of llvm-as.exe (which is).
> This means I have to add MinGW bin dir to PATH in order to make
> llvm-gcc.exe work. If I rename supplied llvm-as.exe to as.exe,
> it chokes on incompatible cmdline handling, telling:
> "as: Unknown command line argument '-ohbver.o'. Try: 'as --help'"
> The linking problem is apparently the same as on Linux.
> ld.exe will be called instead of llvm-gc.exe, with same error.
> It's a little strange such problems are still in this software,
> or could be that we (I) miss the concept.
It's not wrong that llvm-gcc calls native linker or assembler.
In some cases it's expect behavior. The problem is that it does
not check when it can use native tools and when it has to use
its own ones because files generated by LLVM tools are not compatible
with platform native tools, i.e.:
/*** tst.c ***/
#include
int main( void )
{
printf( "Hello World !!!\n" );
return 0;
}
druzus:/tmp/3# llvm-gcc -O3 tst.c
works without any problems:
druzus:/tmp/3# file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.4, not stripped
but if you try to enable link time optimisations using -O4 then:
druzus:/tmp# llvm-gcc -O4 tst.c
/tmp/cc2wOHbI.o: file not recognized: File format not recognized
collect2: ld returned 1 exit status
so it generate .o file with meta code instead of machine code but it does
not switch to llvm-ld and internally still try to use native ld as linker
which of course cannot understand LLVM meta code. If you want to create final
application then you have to make it manually by:
druzus:/tmp/3# llvm-gcc -O4 tst.c -c
druzus:/tmp/3# llvm-ld tst.o -native
druzus:/tmp/3# file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.4, not stripped
Please note that llvm-ld is not real linker for native machine code but it
can generate ASM or C code from optimized meta code and then executes platform
native assembler or C compiler and linker. In current LLVM binaries the main
problem is caused by the fact that llvm-gcc does not automatically switch to
llvm-ld when it's necessary and seems that we do not have any llvm-gcc
switches to force using llvm-ld. In summary it seems to be minor problem
which should be easy to resolve by LLVM-GCC developers or even someone
else interested enough to look at LLVM-GCC code to fix it.
Anyhow I haven't looked at this code so all what I've wrote is only
result of short LLVM-GCC tests.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12997] trunk/harbour
Revision: 12997 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12997&view=rev Author: vszakats Date: 2009-11-23 21:50:47 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 22:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg ! Fixed to use '-ofilename' to spec C compiler object output, instead '-o filename'. Following linux/clang.mk. (There is utter chaos with this -o option) * config/darwin/clang.mk + Documented fact that '-ofilename' also works (just like in linux/clang). * config/linux/gcc.mk * config/linux/icc.mk * config/linux/clang.mk * config/linux/sunpro.mk * config/linux/global.mk % Moved strip configuration to global.mk. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/darwin/clang.mk trunk/harbour/config/linux/clang.mk trunk/harbour/config/linux/gcc.mk trunk/harbour/config/linux/global.mk trunk/harbour/config/linux/icc.mk trunk/harbour/config/linux/sunpro.mk trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12996] trunk/harbour
Revision: 12996 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12996&view=rev Author: vszakats Date: 2009-11-23 21:03:31 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 22:02 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg + Turn on detailed maps for bcc targets when -map option is used. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
> The situation is very simple. llvm-ar cannot work correctly with > llvm-gc and it's a bug in this tools. It doesn't matter what type > of object is generated. I.e. in ICC where 'xiar' is used instead > of 'ar' we can use archives which contains meta code for link time > IPO without any problems. In LLVM not and without any doubts it's > sth what should be fixed by LLVM compiler authors or packagers who > create binary packages for given distribution. That's all. [...] > BTW new version of GCC will also support IPO when -O4 optimization is > used and LLVM-GCC already accepts this switch which can be used to force > generating byte code instead of machine code in .o files. Anyhow it also > does not help to resolve the link time problem and even with -O4 and .o > files containing byte code still native 'ld' is used instead of llvm-ld :-( Thanks a lot. So, shortly the problem is that 'llvm-gcc' wrongly calls 'ld', instead of its own 'llvm-ld'. It would certainly be better if llvm-gcc could automatically (or via cmdline options?) call the correct ld tool. I made a test on the Windows llvm-gcc build, and there apparently a similar problem exist where llvm-gcc.exe tries to execute as.exe (which is not supplied) instead of llvm-as.exe (which is). This means I have to add MinGW bin dir to PATH in order to make llvm-gcc.exe work. If I rename supplied llvm-as.exe to as.exe, it chokes on incompatible cmdline handling, telling: "as: Unknown command line argument '-ohbver.o'. Try: 'as --help'" The linking problem is apparently the same as on Linux. ld.exe will be called instead of llvm-gc.exe, with same error. It's a little strange such problems are still in this software, or could be that we (I) miss the concept. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12947] trunk/harbour
Hi, Grigory Filatov wrote: We have a GPF in the sample arrayrdd.prg at the calling of the function DBCLOSEALL() after last changes in the hbrddsql contrib library. Thank, You. Should be fixed. BTW, it would be nice if hbmk2 -map switch will add -s option (detailed map) in BCC. Current map file contains only segment table and it is not useful to track down GPF place. I've tried to look at hbmk2 source, but I was unable to find a way to add it :) Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12995] trunk/harbour
Revision: 12995 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12995&view=rev Author: snaiperis Date: 2009-11-23 20:44:39 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 22:42 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) * harbour/contrib/rddsql/sqlbase.c ! fixed connection counter decrementation for not connected areas Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/rddsql/sqlbase.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Win_prn SetPen change.
Hi Xavi, On 2009 Nov 23, at 19:34, Xavi wrote: > Changes in WIN_SETPEN to do like WIN_CREATEFONT and adapt SetPen in WIN_PRN > class. > And Minor formatting. :( > Please Viktor, could you update the repository. Thank you very much, it's in SVN now. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12947] trunk/harbour
Hello Mindaugas, I have a small bugreport ;-( We have a GPF in the sample arrayrdd.prg at the calling of the function DBCLOSEALL() after last changes in the hbrddsql contrib library. Can somebody confirm this problem? -- Kind Regards, Grigory snaiperis wrote: > > Revision: 12947 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12947&view=rev > Author: snaiperis > Date: 2009-11-20 12:30:42 + (Fri, 20 Nov 2009) > > Log Message: > --- > 2009-11-20 14:28 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) > + harbour/contrib/rddsql/hbrddsql.ch > * harbour/contrib/rddsql/hbrddsql.h > * DBI_ and RDDI_ defines moved to .ch file > > * harbour/contrib/rddsql/sddmy/tests/test1.prg > * harbour/contrib/rddsql/sddodbc/tests/test1.prg > * harbour/contrib/rddsql/sddodbc/tests/test2.prg > * hbrddsql.ch include used > > * harbour/contrib/rddsql/sddodbc/tests/test2.prg > ! fixed small error in DSN > > * harbour/contrib/rddsql/sddodbc/odbcdd.c > * implemented error processing > > * harbour/contrib/rddsql/sddfb/fbirddd.c > * harbour/contrib/rddsql/sddmy/mysqldd.c > * harbour/contrib/rddsql/sddodbc/odbcdd.c > * harbour/contrib/rddsql/sddpg/pgsqldd.c > * harbour/contrib/rddsql/sqlbase.c > * harbour/contrib/rddsql/sqlmix.c > * source formatting > * changed error variables type to HB_ERRCODE > > * harbour/contrib/rddsql/sddfb/fbirddd.c > * harbour/contrib/rddsql/sddmy/mysqldd.c > * moved unsupported (by some compiler) compile time condition > check to RDD initialisation run-time condition check > > * harbour/contrib/rddsql/hbrddsql.h > * harbour/contrib/rddsql/sqlbase.c > * implemented connection area counter. Now connection can be > closed only after all its workareas are closed. > > * harbour/contrib/rddsql/hbrddsql.h > * harbour/contrib/rddsql/sqlbase.c > * SQL error text, error number, last query, etc. Moved from > connection to static variables, because I'm unable to return > errors for a failed connect otherwise. > ; TODO: MT support. Error text and code are stored in static > variable, it should be moved to thread static in the future. > But there is more problems in MT support. F.e., can we use > use the same connection for a few threads? > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/contrib/rddsql/hbrddsql.h > trunk/harbour/contrib/rddsql/sddfb/fbirddd.c > trunk/harbour/contrib/rddsql/sddmy/mysqldd.c > trunk/harbour/contrib/rddsql/sddmy/tests/test1.prg > trunk/harbour/contrib/rddsql/sddodbc/odbcdd.c > trunk/harbour/contrib/rddsql/sddodbc/tests/test1.prg > trunk/harbour/contrib/rddsql/sddodbc/tests/test2.prg > trunk/harbour/contrib/rddsql/sddpg/pgsqldd.c > trunk/harbour/contrib/rddsql/sqlbase.c > trunk/harbour/contrib/rddsql/sqlmix.c > > Added Paths: > --- > trunk/harbour/contrib/rddsql/hbrddsql.ch > > > -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12947--trunk-harbour-tp26442583p26484463.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12994] trunk/harbour
Revision: 12994 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12994&view=rev Author: vszakats Date: 2009-11-23 19:27:18 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 20:26 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_tprn.prg * contrib/hbwin/win_prn1.c ! Fixed ::SETPEN() and WIN_SETPEN() to not leak objects. Patch submitted by Xavi. * config/wce/poccarm.mk * config/win/pocc.mk % Removed some unnecessary logic, thus making it similar to all other compiler setups. * ChangeLog * TODO marked as DONE. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/wce/poccarm.mk trunk/harbour/config/win/pocc.mk trunk/harbour/contrib/hbwin/win_prn1.c trunk/harbour/contrib/hbwin/win_tprn.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
On Mon, 23 Nov 2009, Maurilio Longo wrote:
Hi,
> yes, DosAllocMem() and DosQueryMem() should be enough. I'm not sure about the
> coalescing thing, since DosQueryMem() gives you back size of a memory object
> in bytes and access control flags while the windows version seems to be giving
> back more infos.
It should not be a problem. VirtualQuery() is used to free continues memory
region allocated in more then one VirtualAlloc() calls and seems that we can
easy replicate all MS-Windows conditions using DosQueryMem()
Seems that the final version can look like the code below.
I'm only not sure about OBJ_TILE usage. In fact it's optional to reduce
fragmentation so we do not have to use it at all but if we can find sth
to for allocation virtual memory addresses from two different sides of
process virtual address space then it will be nice.
#define INCL_DOSMEMMGR
/* OS/2 MMAP via DosAllocMem */
static void* os2mmap(size_t size) {
void* ptr;
if (DosAllocMem(&ptr, size, PAG_COMMIT|PAG_READ|PAG_WRITE) != 0 )
return MFAIL;
return ptr;
}
/* For direct MMAP, use OBJ_TILE to minimize interference */
static void* os2direct_mmap(size_t size) {
void* ptr;
if (DosAllocMem(&ptr, size, PAG_COMMIT|PAG_READ|PAG_WRITE|OBJ_TILE) != 0 )
return MFAIL;
return ptr;
}
/* This function supports releasing coalesed segments */
static int os2munmap(void* ptr, size_t size) {
while (size) {
ULONG ulSize = size, ulFlags = 0;
if (DosQueryMem(ptr, &ulSize, &ulFlags) != 0)
return -1;
if ((ulFlags & PAG_BASE) == 0 ||(ulFlags & PAG_COMMIT) == 0 ||
ulSize > size)
return -1;
if (DosFreeMem(ptr) != 0)
return -1;
ptr = ( void * ) ( ( char * ) ptr + ulSize );
size -= ulSize;
}
return 0;
}
#define CALL_MMAP(s) os2mmap(s)
#define CALL_MUNMAP(a, s)os2munmap((a), (s))
#define DIRECT_MMAP(s) os2direct_mmap(s)
If you can confirm that it should work then I'll commit it to SVN and
I would like to ask you or David to make tests in real OS2 environment.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Mon, 23 Nov 2009, Szak�ts Viktor wrote: > Hi Przemek, Tamas and All, > After reading the conversion now I totally don't > understand what is the situation with LLVM-GCC. The situation is very simple. llvm-ar cannot work correctly with llvm-gc and it's a bug in this tools. It doesn't matter what type of object is generated. I.e. in ICC where 'xiar' is used instead of 'ar' we can use archives which contains meta code for link time IPO without any problems. In LLVM not and without any doubts it's sth what should be fixed by LLVM compiler authors or packagers who create binary packages for given distribution. That's all. As long as it will not be resolved then it's necessary to use different hacks which allows to link into final application binary compiled with and without meta code or using some new extensions. In general link time IPO is very simple idea. Instead of creating final machine code during compilation phase some meta code is generated which can be reused for farther optimizations during linking. In most of cases such optimization is simple autoinlining and then optimizing final function which contains inlined code. In general it's exactly the same job as done at compile time but allows to inline functions from different .o/.obj. Because we are compiling time critical part of HVM code as single hvmall.c file then it's fully optimized at compile time and using link time IPO does not improve overall performance in this code at all. It can only help in some external function calls but this is minor part of executed code so the difference is also very small. Returning to link time IPO. Compiler has to generate meta code and store it in object files. Sometimes it generates code in two versions as native machine code and meta code and store it in single file so linker can choose the preferred version, i.e. when link time optimizations are disabled then it uses directly machine code and ignores meta code. Library tools should understand extended object file formats and create valid libraries. They can be extended to create more complicated indexes in final libraries which can improve the performance of link time optimizations. Finally linker has to understand new object file formats and new library formats with extended information if any. So far this functionality is not present in LLVM-GCC. For some reasons llvm-gcc uses internally native 'ld' though as parameters it receives files in new format (i.e. libraries with new indexes or byte code files compiled with -O4 switch) which are not recognized by native 'ld' so as workaround we have to make some tricks to force using llvm-ld. I hope that in the future llvm-gc will recognize file format automatically so it can be used like ICC or other compilers which supports link time optimization using meta code store din object files. BTW new version of GCC will also support IPO when -O4 optimization is used and LLVM-GCC already accepts this switch which can be used to force generating byte code instead of machine code in .o files. Anyhow it also does not help to resolve the link time problem and even with -O4 and .o files containing byte code still native 'ld' is used instead of llvm-ld :-( best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
Przemyslaw,
yes, DosAllocMem() and DosQueryMem() should be enough. I'm not sure about the
coalescing thing, since DosQueryMem() gives you back size of a memory object
in bytes and access control flags while the windows version seems to be giving
back more infos.
Maurilio.
Przemysław Czerpak wrote:
> On Mon, 23 Nov 2009, Maurilio Longo wrote:
>> there is no MMAP api on OS/2.
>
> Just like in MS-Windows.
>
>> Long ago I write an emulation layer which is
>> still around to help porting miniSQL to OS/2. It worked ok, but it was an
>> hack
>> with several limitations (in particular for mmapping shared regions).
>> In my opinion dlmalloc should not be used on OS/2 if it does not work without
>> mmap().
>
> It works without MMAP.
> It does not need strict MMAPs but only access to functions which allocates
> and frees range of memory pages from system. See code below used in
> MS-Windows builds. I do not know details of OS2 API but seems that adding
> support for OS2 is only simple replacing Virtual*() WIN-API functions with
> Dos*Mem() OS2-API functions. If I'm right then above modification can be
> done in few minutes. What do you think about it?
>
> best regards,
> Przemek
>
>
>>> This code is used for WIN32 builds:
>>>
>>>/* Win32 MMAP via VirtualAlloc */
>>>static void* win32mmap(size_t size) {
>>> void* ptr = VirtualAlloc(0, size, MEM_RESERVE|MEM_COMMIT,
>>> PAGE_READWRITE);
>>> return (ptr != 0)? ptr: MFAIL;
>>>}
>>>
>>>/* For direct MMAP, use MEM_TOP_DOWN to minimize interference */
>>>static void* win32direct_mmap(size_t size) {
>>> void* ptr = VirtualAlloc(0, size, MEM_RESERVE|MEM_COMMIT|MEM_TOP_DOWN,
>>> PAGE_READWRITE);
>>> return (ptr != 0)? ptr: MFAIL;
>>>}
>>>
>>>/* This function supports releasing coalesed segments */
>>>static int win32munmap(void* ptr, size_t size) {
>>> MEMORY_BASIC_INFORMATION minfo;
>>> char* cptr = (char*)ptr; /* NOTE: Harbour fix for MSVC C++ mode
>>> compile error. Also fixed in dlmalloc 2.8.4b. [vszakats] */
>>> while (size) {
>>>if (VirtualQuery(cptr, &minfo, sizeof(minfo)) == 0)
>>> return -1;
>>>if (minfo.BaseAddress != cptr || minfo.AllocationBase != cptr ||
>>>minfo.State != MEM_COMMIT || minfo.RegionSize > size)
>>> return -1;
>>>if (VirtualFree(cptr, 0, MEM_RELEASE) == 0)
>>> return -1;
>>>cptr += minfo.RegionSize;
>>>size -= minfo.RegionSize;
>>> }
>>> return 0;
>>>}
>>>
>>>#define CALL_MMAP(s) win32mmap(s)
>>>#define CALL_MUNMAP(a, s)win32munmap((a), (s))
>>>#define DIRECT_MMAP(s) win32direct_mmap(s)
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
Hi Przemek, Tamas and All, After reading the conversion now I totally don't understand what is the situation with LLVM-GCC. [ Notice that I've committed patch for CPPFLAGS/CFLAGS issue today, so now we have only CFLAGS, and no leakage into linker flags. ] Looking at attached .mk file, it applies these settings: HB_CCPREFIX=llvm- HB_USER_CFLAGS=-emit-llvm HB_USER_LDFLAGS=-native Plus: It switches to call llvm-ld directly instead of using the compiler for bin and dyn linking. I'm insure what to do yet. I don't have much against new targets when it's justified, but on the other hand the number of them is growing in a rate when it can quickly become unmaintainable (I maintain them, so I know). Please also take into account that llvm-gcc isn't just meant to support Linux, and if we start to add support to all *nix targets, that means a lot of new files to maintain. (same goes to clang BTW). So: - What is the final status with llvm linking? why can't llvm-gcc do these tasks, when it claims gcc compatibility? - Is there any room to consolidate target .mk files, or any other method to make maintenance feasible? Finally: - Is llvm-gcc such a _mature_ target that we should add it to Harbour yet? - What extra does it offer over llvm/clang? Brgds, Viktor On 2009 Nov 23, at 15:57, Tamas TEVESZ wrote: > On Mon, 23 Nov 2009, Przemysław Czerpak wrote: > >>> they work together correctly, if they are configured to work together >>> correctly. my first stab, they were not. i'm much further now, and >>> almost have a complete compilation+link cycle without workarounds like >>> above (as i slowly start to understand how llvm + frontends work). >> >> So I hope that in next releases llvm-gcc will be configured to work >> correctly with .a files created by llvm-ar. I still do not see any >> reasons to touch Harbour. > > the end-user has to configure them to work together. i have to > configure to work them together. > > this is how this goes: > > you can have llvm-gcc emit elf objects, in which case the standard elf > binutils can work with whatever llvm-gcc emits. this is the case i > don't care about (and this is the case that probably can be pulled off > with just using HB_CCPREFIX). > > you can have llvm-gcc emit llvm bitcode, in which case the object > format is not elf, but a blob that the rest of the *llvm* toolchain > can work with (and consequently any *elf* toolchain can not). this is > the case i've been massaging for the past couple of days. > >> And we have HB_CCPREFIX because it's standard method of using different >> GCC based compilers in single system. > > *if* they use a similarly working toolchain, yes. but you can't > separate the compiler from the toolchain anyhow, and the toolchain > here is different enough to warrant a distinct target. > >> I.e. for Suse Linux we have over >> 30 different GCC based compilers which like LLVM can be used in such way >> and this list is systematically growing up. >> IMHO HB_CCPREFIX is very nice solution to not introduce explicit support >> for each of them into Harbour core code and then update them to keep such >> builds alive. Instead using HB_CCPREFIX user can easy compile Harbour using >> any GCC based compiler installed in his system when he need it. I still >> do not understand why you said: >> "HB_CCPREFIX seems absolutely not the way to go" >> For me it's prefect solution. Of course of some configuration switches are >> still missing to easy use different GCC based compilers using HB_CCPREFIX >> then we should add them. > > again, if they use a similarly working toolchain. HB_CCPREFIX is > perfectly ok what it is used for, but this is not that case. > > i am attaching a diff as to where i am at now. gcc.mk and llvmgcc.mk > are not *that* different (much more different than gcc.mk and > clang.mk, though), i'd be curious to see what additional knobs would > you add to the HB_CCPREFIX stuff to merge these two, without creating > spaghetti in gcc.mk. > > ifeq ($(HB_CCPREFIX),llvm-) > CFLAGS := -emit-llvm > else > CFLAGS := > endif > > ? this is just as explicit support as it is with a distinct target, > just worse, for it is "hidden" (inside another target, that is). > > add to that that in this case we are not in > let-the-compiler-do-the-linking-land anymore, and it gets even more > complicated. > > HB_CCPREFIX is not for this this case. (i most certainly didn't mean > HB_CCPREFIX to be a bad way *in general*, i only meant, and still mean > HB_CCPREFIX is a bad way *for llvm-gcc*.) > > now, as for the diff. > > i have removed leaking CFLAGS to the linker, and there is no ill > effect i see in my build tests (the two that used to fail before that > still fail, all the rest builds and install just as they used to). > i'm hazarding a guess that if (big if) it affects anything, that is > not the gnu toolchain, and it's apparently not watcom either. someone > should do tests with msvc and borl
[Harbour] Function or routine, in console mode, to select a file and get the file name and path
[SPA] ¿Habrá alguna función o rutina, en modo consola, para seleccionar un archivo y obtener el nombre de del archivo y su ruta? Algo similar a GetFile() del API de Windows. [ENG] By Google Is there any function or routine, in console mode, to select a file and get the file name and path? Something similar to GetFile () Windows API. TIA BestRegars GVS ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12993] trunk/harbour
Revision: 12993 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12993&view=rev Author: druzus Date: 2009-11-23 15:28:31 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 16:28 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/mpkg_rpm_win.sh + added yet another path for cross-mingw compiler detection Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/mpkg_rpm_win.sh This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Mon, 23 Nov 2009, Przemysław Czerpak wrote:
> > they work together correctly, if they are configured to work together
> > correctly. my first stab, they were not. i'm much further now, and
> > almost have a complete compilation+link cycle without workarounds like
> > above (as i slowly start to understand how llvm + frontends work).
>
> So I hope that in next releases llvm-gcc will be configured to work
> correctly with .a files created by llvm-ar. I still do not see any
> reasons to touch Harbour.
the end-user has to configure them to work together. i have to
configure to work them together.
this is how this goes:
you can have llvm-gcc emit elf objects, in which case the standard elf
binutils can work with whatever llvm-gcc emits. this is the case i
don't care about (and this is the case that probably can be pulled off
with just using HB_CCPREFIX).
you can have llvm-gcc emit llvm bitcode, in which case the object
format is not elf, but a blob that the rest of the *llvm* toolchain
can work with (and consequently any *elf* toolchain can not). this is
the case i've been massaging for the past couple of days.
> And we have HB_CCPREFIX because it's standard method of using different
> GCC based compilers in single system.
*if* they use a similarly working toolchain, yes. but you can't
separate the compiler from the toolchain anyhow, and the toolchain
here is different enough to warrant a distinct target.
> I.e. for Suse Linux we have over
> 30 different GCC based compilers which like LLVM can be used in such way
> and this list is systematically growing up.
> IMHO HB_CCPREFIX is very nice solution to not introduce explicit support
> for each of them into Harbour core code and then update them to keep such
> builds alive. Instead using HB_CCPREFIX user can easy compile Harbour using
> any GCC based compiler installed in his system when he need it. I still
> do not understand why you said:
>"HB_CCPREFIX seems absolutely not the way to go"
> For me it's prefect solution. Of course of some configuration switches are
> still missing to easy use different GCC based compilers using HB_CCPREFIX
> then we should add them.
again, if they use a similarly working toolchain. HB_CCPREFIX is
perfectly ok what it is used for, but this is not that case.
i am attaching a diff as to where i am at now. gcc.mk and llvmgcc.mk
are not *that* different (much more different than gcc.mk and
clang.mk, though), i'd be curious to see what additional knobs would
you add to the HB_CCPREFIX stuff to merge these two, without creating
spaghetti in gcc.mk.
ifeq ($(HB_CCPREFIX),llvm-)
CFLAGS := -emit-llvm
else
CFLAGS :=
endif
? this is just as explicit support as it is with a distinct target,
just worse, for it is "hidden" (inside another target, that is).
add to that that in this case we are not in
let-the-compiler-do-the-linking-land anymore, and it gets even more
complicated.
HB_CCPREFIX is not for this this case. (i most certainly didn't mean
HB_CCPREFIX to be a bad way *in general*, i only meant, and still mean
HB_CCPREFIX is a bad way *for llvm-gcc*.)
now, as for the diff.
i have removed leaking CFLAGS to the linker, and there is no ill
effect i see in my build tests (the two that used to fail before that
still fail, all the rest builds and install just as they used to).
i'm hazarding a guess that if (big if) it affects anything, that is
not the gnu toolchain, and it's apparently not watcom either. someone
should do tests with msvc and borland and the rest of the gang, but i
don't really think there will be any fallout.
the rest just adds an llvmgcc target, which, at this stage compiles
and installs mostly fine (both c and c++ modes). the only thing i'm
missing is the libharbour{,mt}.so -> libharbour{mt}-2.0.0.so symlinks
in the installed lib/ directory. what makes these?
also, viktor, could you please add this to hbmk2? probably not in the
tree first, but sending me (or the list) a diff to that end would be a
big step forward.
thanks,
--
[-]
mkdir /nonexistentIndex: config/linux/llvmgcc.mk
===
--- config/linux/llvmgcc.mk (revision 0)
+++ config/linux/llvmgcc.mk (revision 0)
@@ -0,0 +1,65 @@
+#
+# $Id: gcc.mk 12895 2009-11-16 08:52:59Z vszakats $
+#
+
+ifeq ($(HB_BUILD_MODE),cpp)
+ HB_CMP := llvm-g++
+else
+ HB_CMP := llvm-gcc
+endif
+
+OBJ_EXT := .o
+LIB_PREF := lib
+LIB_EXT := .a
+
+HB_DYN_COPT := -DHB_DYNLIB -fpic
+
+CC := $(HB_CCACHE) $(HB_CCPREFIX)$(HB_CMP)$(HB_CCPOSTFIX)
+CC_IN := -c
+CC_OUT := -o
+
+CPPFLAGS := -I. -I$(HB_INC_COMPILE)
+CFLAGS := -emit-llvm
+LDFLAGS := -native
+
+ifneq ($(HB_BUILD_WARN),no)
+ CFLAGS += -Wall -W
+endif
+
+ifneq ($(HB_BUILD_OPTIM),no)
+ CFLAGS += -O3
+endif
+
+ifeq ($(HB_BUILD_DEBUG),yes)
+ CFLAGS += -g
+endif
+
+ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
+ ARSTRIP = && strip -S $(LIB_DIR)/$@
+endif
+ifneq ($(filter $(HB_BUILD_STRIP),all bin)
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Mon, 23 Nov 2009, Tamas TEVESZ wrote: > > I still to think that it's good idea to encode workarounds for problems > > with other packages into harbour core code. IMHO much simpler temporary > > solution is: > >ln -sf /usr/bin/ar /usr/bin/llvm/ar > > from root account until someone will have not create llvm-gcc packages with > > llvm-gcc which can work with llvm-ar correctly. > they work together correctly, if they are configured to work together > correctly. my first stab, they were not. i'm much further now, and > almost have a complete compilation+link cycle without workarounds like > above (as i slowly start to understand how llvm + frontends work). So I hope that in next releases llvm-gcc will be configured to work correctly with .a files created by llvm-ar. I still do not see any reasons to touch Harbour. > > Can you explain the above. I do not understand it. > i do not really understand what is it you do not understand. > HB_CCPREFIX is just that, prepending some prefix to the compiler and > binutils and stuff names. in this llvmgcc case, modifying several > compiler options is also needed, so setting only prefix is not enough. And we have HB_CCPREFIX because it's standard method of using different GCC based compilers in single system. I.e. for Suse Linux we have over 30 different GCC based compilers which like LLVM can be used in such way and this list is systematically growing up. IMHO HB_CCPREFIX is very nice solution to not introduce explicit support for each of them into Harbour core code and then update them to keep such builds alive. Instead using HB_CCPREFIX user can easy compile Harbour using any GCC based compiler installed in his system when he need it. I still do not understand why you said: "HB_CCPREFIX seems absolutely not the way to go" For me it's prefect solution. Of course of some configuration switches are still missing to easy use different GCC based compilers using HB_CCPREFIX then we should add them. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] valtype and type
On Mon, 23 Nov 2009, vatzct wrote: Hi, > Valtype and type show differrent result (sample below). Who is wrong > me, valtype or type? VALTYPE() and TYPE() makes two different things so their results cannot be compatible. VALTYPE() returnes type of given item. TYPE() check type of expression passed as 1-st character item. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
On Mon, 23 Nov 2009, Maurilio Longo wrote:
> there is no MMAP api on OS/2.
Just like in MS-Windows.
> Long ago I write an emulation layer which is
> still around to help porting miniSQL to OS/2. It worked ok, but it was an hack
> with several limitations (in particular for mmapping shared regions).
> In my opinion dlmalloc should not be used on OS/2 if it does not work without
> mmap().
It works without MMAP.
It does not need strict MMAPs but only access to functions which allocates
and frees range of memory pages from system. See code below used in
MS-Windows builds. I do not know details of OS2 API but seems that adding
support for OS2 is only simple replacing Virtual*() WIN-API functions with
Dos*Mem() OS2-API functions. If I'm right then above modification can be
done in few minutes. What do you think about it?
best regards,
Przemek
> > This code is used for WIN32 builds:
> >
> >/* Win32 MMAP via VirtualAlloc */
> >static void* win32mmap(size_t size) {
> > void* ptr = VirtualAlloc(0, size, MEM_RESERVE|MEM_COMMIT,
> > PAGE_READWRITE);
> > return (ptr != 0)? ptr: MFAIL;
> >}
> >
> >/* For direct MMAP, use MEM_TOP_DOWN to minimize interference */
> >static void* win32direct_mmap(size_t size) {
> > void* ptr = VirtualAlloc(0, size, MEM_RESERVE|MEM_COMMIT|MEM_TOP_DOWN,
> > PAGE_READWRITE);
> > return (ptr != 0)? ptr: MFAIL;
> >}
> >
> >/* This function supports releasing coalesed segments */
> >static int win32munmap(void* ptr, size_t size) {
> > MEMORY_BASIC_INFORMATION minfo;
> > char* cptr = (char*)ptr; /* NOTE: Harbour fix for MSVC C++ mode
> > compile error. Also fixed in dlmalloc 2.8.4b. [vszakats] */
> > while (size) {
> >if (VirtualQuery(cptr, &minfo, sizeof(minfo)) == 0)
> > return -1;
> >if (minfo.BaseAddress != cptr || minfo.AllocationBase != cptr ||
> >minfo.State != MEM_COMMIT || minfo.RegionSize > size)
> > return -1;
> >if (VirtualFree(cptr, 0, MEM_RELEASE) == 0)
> > return -1;
> >cptr += minfo.RegionSize;
> >size -= minfo.RegionSize;
> > }
> > return 0;
> >}
> >
> >#define CALL_MMAP(s) win32mmap(s)
> >#define CALL_MUNMAP(a, s)win32munmap((a), (s))
> >#define DIRECT_MMAP(s) win32direct_mmap(s)
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] valtype and type
Valtype and type show differrent result (sample below). Who is wrong me,
valtype or type?
FUNCTION main( )
LOCAL str_sep := "()", yy_sep, xx_sep, xy
local str_arr:='("ID","C",1,0)("CVAR","C",20,0)("ZVAR","C",100,0)'
xx_sep := NumToken( str_arr, str_sep )
for ii := 1 TO xx_sep
ss := token( str_arr, str_sep, ii )
?ss
yy_sep := NumToken( ss, "," )
IF yy_sep == 4
for y := 1 TO yy_sep
xy := token(ss,",",y)
?y,xy,valtype(xy),type(xy)
next
ENDIF
next
RETURN nil
My result is
C:\hrb\test\token\>testtoken.exe
"ID","C",1,0
1 "ID" C C
2 "C" C C
3 1 C N
4 0 C N
"CVAR","C",20,0
1 "CVAR" C C
2 "C" C C
3 20 C N
4 0 C N
"ZVAR","C",100,0
1 "ZVAR" C C
2 "C" C C
3 100 C N
4 0 C N
Regards,
Alexey Myronenko
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Mon, 23 Nov 2009, Przemysław Czerpak wrote: > > that is exactly what's happening, and according to llvm bugzilla, this > > is what should be happening, see: > > http://www.mail-archive.com/llvmb...@cs.uiuc.edu/msg03238.html > > Please note that we are calling llvm-gcc to link final application > and it does not work. I haven't check if it does not call llvm-ld > but native ld or llvm-ld does not work correctly. It doesn't matter > for us. Important is only that calling llvm-gcc to create binaries > does not work with libraries created by llvm-ar what is a problem > which should be resolved by packager or llvm authors. It's not > out job to add workarounds for such things into core harbour code. > > > so it may be that the solution is not HB_CCPREFIX after all, but a > > separate llvmgcc target, which, for starters, only sets HB_CMP. > > I still to think that it's good idea to encode workarounds for problems > with other packages into harbour core code. IMHO much simpler temporary > solution is: >ln -sf /usr/bin/ar /usr/bin/llvm/ar > from root account until someone will have not create llvm-gcc packages with > llvm-gcc which can work with llvm-ar correctly. they work together correctly, if they are configured to work together correctly. my first stab, they were not. i'm much further now, and almost have a complete compilation+link cycle without workarounds like above (as i slowly start to understand how llvm + frontends work). > > it seems that the supposed improvements using llvm start pouring when > > it's also used for linking, see for example: > > http://www.nntp.perl.org/group/perl.perl5.porters/2008/06/msg137461.html > > this could be added as a next step, once an llvmgcc target is in > > there. > > It will not give any real improvement to Harbour HVM because we already > enabled inter procedural optimization in whole HVM code by introducing > hvmall.c so it works for compiler which do not have link time IPO. Few > months ago I tested using ICC that it gives in practice the same > improvement and introducing link time IPO does give farther speed > optimizations but strongly increase the size of final binaries. > So if LLVM/GCC does not disable some compile time IPO which exist in GCC > then at current state there is not chance that using LLVM or CLANG we will > have faster final code because we do not leave any time critical code > which can be improved yet by link time IPO. i wholeheartedly believe you, but i still do not see this as a futile excercise. if nothing else, *i* will learn something new. > > HB_CCPREFIX seems absolutely not the way to go. > > Can you explain the above. I do not understand it. i do not really understand what is it you do not understand. HB_CCPREFIX is just that, prepending some prefix to the compiler and binutils and stuff names. in this llvmgcc case, modifying several compiler options is also needed, so setting only prefix is not enough. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
Przemyslaw,
there is no MMAP api on OS/2. Long ago I write an emulation layer which is
still around to help porting miniSQL to OS/2. It worked ok, but it was an hack
with several limitations (in particular for mmapping shared regions).
In my opinion dlmalloc should not be used on OS/2 if it does not work without
mmap().
Best regards.
Maurilio.
Przemysław Czerpak wrote:
> On Mon, 23 Nov 2009, David Arturo Macias Corona wrote:
>
> Hi,
>
>>> * harbour/src/vm/dlmalloc.c
>>>* modifications for non MS-Windows WATCOM builds
>>> TOFIX: now it compiles in Linux and OS2 builds but it still does
>>> not work
>> Do you need some tests on OS/2 ?
>
> Yes but first we will have to add support for OS2 MMAP emulation
> just like in MS-Windows builds where VirtualAlloc() is used to
> emulate mmap().
>
> This code is used for WIN32 builds:
>
>/* Win32 MMAP via VirtualAlloc */
>static void* win32mmap(size_t size) {
> void* ptr = VirtualAlloc(0, size, MEM_RESERVE|MEM_COMMIT,
> PAGE_READWRITE);
> return (ptr != 0)? ptr: MFAIL;
>}
>
>/* For direct MMAP, use MEM_TOP_DOWN to minimize interference */
>static void* win32direct_mmap(size_t size) {
> void* ptr = VirtualAlloc(0, size, MEM_RESERVE|MEM_COMMIT|MEM_TOP_DOWN,
> PAGE_READWRITE);
> return (ptr != 0)? ptr: MFAIL;
>}
>
>/* This function supports releasing coalesed segments */
>static int win32munmap(void* ptr, size_t size) {
> MEMORY_BASIC_INFORMATION minfo;
> char* cptr = (char*)ptr; /* NOTE: Harbour fix for MSVC C++ mode compile
> error. Also fixed in dlmalloc 2.8.4b. [vszakats] */
> while (size) {
>if (VirtualQuery(cptr, &minfo, sizeof(minfo)) == 0)
> return -1;
>if (minfo.BaseAddress != cptr || minfo.AllocationBase != cptr ||
>minfo.State != MEM_COMMIT || minfo.RegionSize > size)
> return -1;
>if (VirtualFree(cptr, 0, MEM_RELEASE) == 0)
> return -1;
>cptr += minfo.RegionSize;
>size -= minfo.RegionSize;
> }
> return 0;
>}
>
>#define CALL_MMAP(s) win32mmap(s)
>#define CALL_MUNMAP(a, s)win32munmap((a), (s))
>#define DIRECT_MMAP(s) win32direct_mmap(s)
>
> and we have to translate it to OS2 API. Probably it's sth trivial for OS2
> users but I will have to look in the internet for OS2 API documentation
> to find corresponding functions giving similar functionality. If no one
> will help then I'll try to make it myself and I'll ask you to make some
> tests.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Unrecoverable error 9994: Harbour CP (UA866) initialization failure
Przemysław Czerpak написав(ла): On Mon, 23 Nov 2009, vatzct wrote: Hi, ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org ! MAKE: mingw32-make 3.81 sh.exe clean install ! HB_INSTALL_PREFIX: c:\dev\harbour\ ! HB_BUILD_DLL: no ! HB_BUILD_SHARED: no ! HB_HOST_PLAT: win (x86) HB_SHELL: nt ! HB_PLATFORM: win (x86) (autodetected) ! HB_COMPILER: mingw (autodetected: c:/mingw/bin/) ... ./bin/win/mingw/hbrun.exe --hb:gtcgi ./bin/postinst.prg Unrecoverable error 9994: Harbour CP (UA866) initialization failure mingw32-make: *** [install] Error 1 You are using modified cpua866.c which have wrongly defined letters strings. Now such wrongly defined strings are detected by CPD API code which refuse to register broken CPs generating above error. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour Thanks. I'm download original cpua866.c and now all ok. Regards, Alexey Myronenko ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12992] trunk/harbour
Revision: 12992 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12992&view=rev Author: druzus Date: 2009-11-23 13:06:05 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 14:05 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/filesys.c % eliminated memory allocation from hb_fsCurDirBuff() if non UNICODE WIN32 API is used Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rtl/filesys.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Unrecoverable error 9994: Harbour CP (UA866) initialization failure
On Mon, 23 Nov 2009, vatzct wrote: Hi, > ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org > ! MAKE: mingw32-make 3.81 sh.exe clean install > ! HB_INSTALL_PREFIX: c:\dev\harbour\ > ! HB_BUILD_DLL: no > ! HB_BUILD_SHARED: no > ! HB_HOST_PLAT: win (x86) HB_SHELL: nt > ! HB_PLATFORM: win (x86) (autodetected) > ! HB_COMPILER: mingw (autodetected: c:/mingw/bin/) > ... > ./bin/win/mingw/hbrun.exe --hb:gtcgi ./bin/postinst.prg > Unrecoverable error 9994: Harbour CP (UA866) initialization failure > mingw32-make: *** [install] Error 1 You are using modified cpua866.c which have wrongly defined letters strings. Now such wrongly defined strings are detected by CPD API code which refuse to register broken CPs generating above error. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
On Mon, 23 Nov 2009, David Arturo Macias Corona wrote:
Hi,
> > * harbour/src/vm/dlmalloc.c
> >* modifications for non MS-Windows WATCOM builds
> > TOFIX: now it compiles in Linux and OS2 builds but it still does
> >not work
> Do you need some tests on OS/2 ?
Yes but first we will have to add support for OS2 MMAP emulation
just like in MS-Windows builds where VirtualAlloc() is used to
emulate mmap().
This code is used for WIN32 builds:
/* Win32 MMAP via VirtualAlloc */
static void* win32mmap(size_t size) {
void* ptr = VirtualAlloc(0, size, MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE);
return (ptr != 0)? ptr: MFAIL;
}
/* For direct MMAP, use MEM_TOP_DOWN to minimize interference */
static void* win32direct_mmap(size_t size) {
void* ptr = VirtualAlloc(0, size, MEM_RESERVE|MEM_COMMIT|MEM_TOP_DOWN,
PAGE_READWRITE);
return (ptr != 0)? ptr: MFAIL;
}
/* This function supports releasing coalesed segments */
static int win32munmap(void* ptr, size_t size) {
MEMORY_BASIC_INFORMATION minfo;
char* cptr = (char*)ptr; /* NOTE: Harbour fix for MSVC C++ mode compile
error. Also fixed in dlmalloc 2.8.4b. [vszakats] */
while (size) {
if (VirtualQuery(cptr, &minfo, sizeof(minfo)) == 0)
return -1;
if (minfo.BaseAddress != cptr || minfo.AllocationBase != cptr ||
minfo.State != MEM_COMMIT || minfo.RegionSize > size)
return -1;
if (VirtualFree(cptr, 0, MEM_RELEASE) == 0)
return -1;
cptr += minfo.RegionSize;
size -= minfo.RegionSize;
}
return 0;
}
#define CALL_MMAP(s) win32mmap(s)
#define CALL_MUNMAP(a, s)win32munmap((a), (s))
#define DIRECT_MMAP(s) win32direct_mmap(s)
and we have to translate it to OS2 API. Probably it's sth trivial for OS2
users but I will have to look in the internet for OS2 API documentation
to find corresponding functions giving similar functionality. If no one
will help then I'll try to make it myself and I'll ask you to make some
tests.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Mon, 23 Nov 2009, Tamas TEVESZ wrote: Hi, > > You have quite precise error message here. > > I've just checked that also in Suse11.2 llvm-ranlib does not create index > > which can be recognized by llvm-gcc. It's probably bug which should be > > reported to LLVM developers. > > As workaround I used ranlib instead of llvm-ranlib to create indexes and > > created full harbour build using HB_CCPREFIX=llvm- without any problems. > that is exactly what's happening, and according to llvm bugzilla, this > is what should be happening, see: > http://www.mail-archive.com/llvmb...@cs.uiuc.edu/msg03238.html Please note that we are calling llvm-gcc to link final application and it does not work. I haven't check if it does not call llvm-ld but native ld or llvm-ld does not work correctly. It doesn't matter for us. Important is only that calling llvm-gcc to create binaries does not work with libraries created by llvm-ar what is a problem which should be resolved by packager or llvm authors. It's not out job to add workarounds for such things into core harbour code. > so it may be that the solution is not HB_CCPREFIX after all, but a > separate llvmgcc target, which, for starters, only sets HB_CMP. I still to think that it's good idea to encode workarounds for problems with other packages into harbour core code. IMHO much simpler temporary solution is: ln -sf /usr/bin/ar /usr/bin/llvm/ar from root account until someone will have not create llvm-gcc packages with llvm-gcc which can work with llvm-ar correctly. > it seems that the supposed improvements using llvm start pouring when > it's also used for linking, see for example: > http://www.nntp.perl.org/group/perl.perl5.porters/2008/06/msg137461.html > this could be added as a next step, once an llvmgcc target is in > there. It will not give any real improvement to Harbour HVM because we already enabled inter procedural optimization in whole HVM code by introducing hvmall.c so it works for compiler which do not have link time IPO. Few months ago I tested using ICC that it gives in practice the same improvement and introducing link time IPO does give farther speed optimizations but strongly increase the size of final binaries. So if LLVM/GCC does not disable some compile time IPO which exist in GCC then at current state there is not chance that using LLVM or CLANG we will have faster final code because we do not leave any time critical code which can be improved yet by link time IPO. > HB_CCPREFIX seems absolutely not the way to go. Can you explain the above. I do not understand it. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12991] trunk/harbour
Revision: 12991 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12991&view=rev Author: vszakats Date: 2009-11-23 12:17:30 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 13:15 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * config/beos/gcc.mk * config/bsd/gcc.mk * config/wce/mingwarm.mk * config/wce/poccarm.mk * config/wce/msvcarm.mk * config/darwin/gcc.mk * config/darwin/icc.mk * config/darwin/clang.mk * config/hpux/gcc.mk * config/dos/watcom.mk * config/dos/djgpp.mk * config/win/xcc.mk * config/win/mingw.mk * config/win/pocc.mk * config/win/bcc.mk * config/win/watcom.mk * config/win/icc.mk * config/win/pocc64.mk * config/win/cygwin.mk * config/win/msvc.mk * config/linux/watcom.mk * config/linux/gcc.mk * config/linux/icc.mk * config/linux/clang.mk * config/linux/sunpro.mk * config/os2/watcom.mk * config/os2/gcc.mk * config/sunos/gcc.mk * config/sunos/sunpro.mk + Uniformly using CFLAGS to store C compilation flags, instead of a previous mixture of CPPFLAGS and CFLAGS. * config/rules.mk - Deleted CPPFLAGS. * INSTALL * bin/postinst.bat ! Minor fixes in texts. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/bin/postinst.bat trunk/harbour/config/beos/gcc.mk trunk/harbour/config/bsd/gcc.mk trunk/harbour/config/darwin/clang.mk trunk/harbour/config/darwin/gcc.mk trunk/harbour/config/darwin/icc.mk trunk/harbour/config/dos/djgpp.mk trunk/harbour/config/dos/watcom.mk trunk/harbour/config/hpux/gcc.mk trunk/harbour/config/linux/clang.mk trunk/harbour/config/linux/gcc.mk trunk/harbour/config/linux/icc.mk trunk/harbour/config/linux/sunpro.mk trunk/harbour/config/linux/watcom.mk trunk/harbour/config/os2/gcc.mk trunk/harbour/config/os2/watcom.mk trunk/harbour/config/rules.mk trunk/harbour/config/sunos/gcc.mk trunk/harbour/config/sunos/sunpro.mk trunk/harbour/config/wce/mingwarm.mk trunk/harbour/config/wce/msvcarm.mk trunk/harbour/config/wce/poccarm.mk trunk/harbour/config/win/bcc.mk trunk/harbour/config/win/cygwin.mk trunk/harbour/config/win/icc.mk trunk/harbour/config/win/mingw.mk trunk/harbour/config/win/msvc.mk trunk/harbour/config/win/pocc.mk trunk/harbour/config/win/pocc64.mk trunk/harbour/config/win/watcom.mk trunk/harbour/config/win/xcc.mk This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
Przemek: > * harbour/src/vm/dlmalloc.c >* modifications for non MS-Windows WATCOM builds > TOFIX: now it compiles in Linux and OS2 builds but it still does >not work Do you need some tests on OS/2 ? David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Re: Re: Re: Re: Win_prn problem.
> Hi!
> The return of command "oPrn:TextOut('Font Is: '+oPrn:FontName,.t.)" is
> correct now.
Amen.
> But not is possible yet print draw box double horizontal for example. I get
> Í
I'll let someone else to solve this for you,
anyhow it's not a Harbour bug.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Re: Re: Re: Re: Win_prn problem.
Hi!
The return of command "oPrn:TextOut('Font Is: '+oPrn:FontName,.t.)" is
correct now.
But not is possible yet print draw box double horizontal for example. I get
Í
My test with pdfcreator print is.
Function Main
aPrn := GetPrinters()
If empty(aPrn)
MsgStop("Error")
return .f.
EndIf
oPrn := win_prn():New(GetDefaultPrinter())
oPrn :LandScape := .f.
oPrn :Copies:= 1
if !oPrn:Create()
MsgStop("error")
return nil
endif
if !oPrn:StartDoc("test")
MsgStop("Error")
return nil
EndIf
oPrn:CharSet(255)
oPrn:Setfont('Lucida Console',,11255)
oPrn:SetPrc(1,0) //Is necessary, because if I omit not print first line.
oPrn:TextOut('Charset is: '+str(oPrn:Charset(),5),.t.)
oPrn:TextOut('Font Is: '+oPrn:FontName,.t.)
For n := 1 to 255
oPrn:TextOut(chr(n),.t.)
if n == 60 .or. n == 120 .or. n == 180 .or. n == 240
oPrn:NewPage()
EndIf
Next
oPrn:EndDoc()
MSVC, windows XP
/*
* $Id: ChangeLog 12988 2009-11-23 08:14:24Z vszakats $
*/
Best regards,
Itamar M. Lins Jr.
"Viktor Szakáts"
escreveu na mensagem news:64d3e786-b3d3-475d-b309-dd1812b70...@syenar.hu...
Hi Itamar,
I've accidentally found the problem while
reviewing hbwin code, so if you try now it
should work. I've since realized that the
output looked indeed wrong, but I didn't know
what to look for.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12990] trunk/harbour/ChangeLog
Revision: 12990 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12990&view=rev Author: vszakats Date: 2009-11-23 09:29:34 + (Mon, 23 Nov 2009) Log Message: --- little typos in last entry Modified Paths: -- trunk/harbour/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12989] trunk/harbour
Revision: 12989 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12989&view=rev Author: vszakats Date: 2009-11-23 09:27:08 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 10:25 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_prn2.c ! Commented buggy code dealing with Chr( 256 ) strippage in PRINTFILERAW(). While I can imagine Chr( 26 ) may cause a little inconvenience when sent to printer, it will just be a small visual one, and it's very easy to overcome by using HB_MEMOWRIT() instead of MEMOWRIT() to create the disk file, if the file was created by other means, the Chr( 26 ) won't be there anyway. Anyhow I opted to have a clear cut behavior even if it's slightly incompatible because old implementation was buggy, and IMO such printing function shouldn't do behind-the-scenes alterations on the data to be printed. After all the function is called "RAW". INCOMPATIBLE for files which has an ending Chr( 26 ). * contrib/hbide/hbide.prg ! Removed CURDRIVE() and CURDIR() usage. Notice that on *nix platforms there is no such thing as drive letter, plus some platforms don't even have the concept of current dir. CURDRIVE() is also an XBase++ specific call, so it may not be available in Harbour core. ! Removed hard-wired Windows specific path from save dialog. (it was a template yet) * config/rules.mk ! Deleted CFLAGS from default link rule. After quick scan through the make files this shouldn't cause problems. Please test and if it does, we should add missing options to LDFLAGS. ; TODO: Clean CPPFLAGS vs. CFLAGS usage in all .mk files. They should all uniformly use CFLAGS now. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/rules.mk trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbwin/win_prn2.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
>>> i'm fighting with the attached llvmgcc target definition, but i got >>> stuck, and can't ffigure out where do cflags leak into ldflags. just >>> try building it, you'll see. >>> cluebat, please? >> >> For some reason CPPFLAGS is passed to linker >> (while CFLAGS isn't). This is so since the beginning, >> and no one has touched this remaining strangeness yet. > > it's actually CFLAGS, and is in rules.mk:66 > > is there any ill effect were it to be removed? i'm in a sort of a I suspect there is, anyhow it would be good to solve this. > hurry now, but without this, at least linux/gcc, linux/g++, > linux/sunpro and linux x os2/watcom c++ is still ok, whereas llvmgcc > definitely gets further on (and now blows up in what at cursory > eyeballing seems to be hb-mkdyn, which is understandable). hb-mkdyn is used only for some smaller tasks at postinst phase, the dynlibs are now created directly by the make system, so maybe the problem isn't that bad. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Unrecoverable error 9994: Harbour CP (UA866) initialization failure
Hi! ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org ! MAKE: mingw32-make 3.81 sh.exe clean install ! HB_INSTALL_PREFIX: c:\dev\harbour\ ! HB_BUILD_DLL: no ! HB_BUILD_SHARED: no ! HB_HOST_PLAT: win (x86) HB_SHELL: nt ! HB_PLATFORM: win (x86) (autodetected) ! HB_COMPILER: mingw (autodetected: c:/mingw/bin/) ... ./bin/win/mingw/hbrun.exe --hb:gtcgi ./bin/postinst.prg Unrecoverable error 9994: Harbour CP (UA866) initialization failure mingw32-make: *** [install] Error 1 Regards, Alexey Myronenko ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12988] trunk/harbour
Revision: 12988 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12988&view=rev Author: vszakats Date: 2009-11-23 08:14:24 + (Mon, 23 Nov 2009) Log Message: --- 2009-11-23 09:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/filesys.c ! Fixed leak in hb_fsCurDirBuff() report by Pritpal. Please test/review. * contrib/hbwin/win_prn2.c * Changed prefix of HB_SIZE type variables. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/src/rtl/filesys.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
