Re: [Harbour] OT - E-Mail Address Verification
I use the next function:
//
// Function: tep_validate_email
//
// Arguments : email email address to be checked
//
// Return : true - valid email address
// false - invalid email address
//
// Description : function for validating email address that conforms to RFC
822 specs
//
// This function is converted from a JavaScript written by
// Sandeep V. Tamhankar ([EMAIL PROTECTED]). The original
JavaScript
// is available at http://javascript.internet.com
//
// Sample Valid Addresses:
//
//[EMAIL PROTECTED]
//[EMAIL PROTECTED]
//"first last"@host.com
//"[EMAIL PROTECTED]"@host.com
//[EMAIL PROTECTED]
//[EMAIL PROTECTED]
//
// Invalid Addresses:
//
//first [EMAIL PROTECTED]
//
//
function tep_validate_email($email) {
$valid_address = true;
$mail_pat = '^(.+)@(.+)$';
$valid_chars = "[^] \(\)<>@,;:\.\\\"\[]";
$atom = "$valid_chars+";
$quoted_user='(\"[^\"]*\")';
$word = "($atom|$quoted_user)";
$user_pat = "^$word(\.$word)*$";
$ip_domain_pat='^\[([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\]$';
$domain_pat = "^$atom(\.$atom)*$";
if (eregi($mail_pat, $email, $components)) {
$user = $components[1];
$domain = $components[2];
// validate user
if (eregi($user_pat, $user)) {
// validate domain
if (eregi($ip_domain_pat, $domain, $ip_components)) {
// this is an IP address
for ($i=1;$i<=4;$i++) {
if ($ip_components[$i] > 255) {
$valid_address = false;
break;
}
}
}
else {
// Domain is a name, not an IP
if (eregi($domain_pat, $domain)) {
/* domain name seems valid, but now make sure that it ends in a
valid TLD or ccTLD
and that there's a hostname preceding the domain or country. */
$domain_components = explode(".", $domain);
// Make sure there's a host name preceding the domain.
if (sizeof($domain_components) < 2) {
$valid_address = false;
} else {
$top_level_domain =
strtolower($domain_components[sizeof($domain_components)-1]);
// Allow all 2-letter TLDs (ccTLDs)
if (eregi('^[a-z][a-z]$', $top_level_domain) != 1) {
$tld_pattern = '';
// Get authorized TLDs from text file
$tlds = file(DIR_WS_INCLUDES . 'tld.txt');
while (list(,$line) = each($tlds)) {
// Get rid of comments
$words = explode('#', $line);
$tld = trim($words[0]);
// TLDs should be 3 letters or more
if (eregi('^[a-z]{3,}$', $tld) == 1) {
$tld_pattern .= '^' . $tld . '$|';
}
}
// Remove last '|'
$tld_pattern = substr($tld_pattern, 0, -1);
if (eregi("$tld_pattern", $top_level_domain) == 0) {
$valid_address = false;
}
}
}
}
else {
$valid_address = false;
}
}
}
else {
$valid_address = false;
}
}
else {
$valid_address = false;
}
if ($valid_address && ENTRY_EMAIL_ADDRESS_CHECK == 'true') {
if (!checkdnsrr($domain, "MX") && !checkdnsrr($domain, "A")) {
$valid_address = false;
}
}
return $valid_address;
}
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 10:08 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-06-30 10:08 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/gtwvg/Makefile * contrib/hbapollo/Makefile * contrib/hbbtree/Makefile * contrib/hbclipsm/Makefile * contrib/hbct/Makefile * contrib/hbfbird/Makefile * contrib/hbfimage/Makefile * contrib/hbgd/Makefile * contrib/hbhpdf/Makefile * contrib/hbmisc/Makefile * contrib/hbmsql/Makefile * contrib/hbmysql/Makefile * contrib/hbmzip/Makefile * contrib/hbnf/Makefile * contrib/hbodbc/Makefile * contrib/hbpgsql/Makefile * contrib/hbsqlit2/Makefile * contrib/hbsqlit3/Makefile * contrib/hbtip/Makefile * contrib/hbtpathy/Makefile * contrib/hbvpdf/Makefile * contrib/hbw32/Makefile * contrib/hbw32ddr/Makefile * contrib/hbwhat32/Makefile * contrib/rddado/Makefile * contrib/rddads/Makefile ! CFLAGS -> C_USR * var = var + x -> var += x ! Added header install rules for all places where such headers are defined. I wonder why isn't this the default in our GNU-make system. * few other minor cleanups. * contrib/rddads/Makefile * Experimenting with HB_INC_ADS implementation in GNU-make system. HB_INC_ADS can now used to enable to rddads builds. In GNU-make HB_INC_ADS can contain a list of possible places where headers may be found. GNU-make will validate these and if the headers were found in any of these places, rddads will be built. For Linux there are some default dirs which will always be checked. 'HB_WITHOUT_ADS' and 'ACE_DIRS' is not longer used. ; Please test. If this works out okay, we can use this method for the rest of 3rd party dependent contribs. * contrib/rddads/Makefile % Don't define WIN32 in GNU-makefiles for w32. * contrib/hbmisc/Makefile ! Don't include non-existing 'test' dir in make. * contrib/gtwvg/Makefile * contrib/gtwvg/common.mak ! Not installing private .h file to common include dir. * contrib/hbw32ddr/w32_ddrw.cpp ! Fixed one GCC warning. (Some remain) -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] 2008-06-30 10:08 UTC+0200 Viktor Szakats (harbour.01syenar hu)
He victor How are build all this makefile? Massimo Belgrano -Messaggio originale- Da: [EMAIL PROTECTED] per conto di Szakáts Viktor 2008-06-30 10:08 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/gtwvg/Makefile * contrib/hbapollo/Makefile * contrib/hbbtree/Makefile * contrib/hbclipsm/Makefile * contrib/hbct/Makefile * contrib/hbfbird/Makefile * contrib/hbfimage/Makefile * contrib/hbgd/Makefile * contrib/hbhpdf/Makefile * contrib/hbmisc/Makefile * contrib/hbmsql/Makefile * contrib/hbmysql/Makefile * contrib/hbmzip/Makefile * contrib/hbnf/Makefile * contrib/hbodbc/Makefile * contrib/hbpgsql/Makefile * contrib/hbsqlit2/Makefile * contrib/hbsqlit3/Makefile * contrib/hbtip/Makefile * contrib/hbtpathy/Makefile * contrib/hbvpdf/Makefile * contrib/hbw32/Makefile * contrib/hbw32ddr/Makefile * contrib/hbwhat32/Makefile * contrib/rddado/Makefile * contrib/rddads/Makefile * contrib/rddads/Makefile * contrib/rddads/Makefile * contrib/hbmisc/Makefile * contrib/gtwvg/Makefile Viktor <>___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 11:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-06-30 11:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbapi.h * source/rtl/set.c * source/vm/fm.c ! Fixed _SET_HBOUTLOG, _SET_HBOUTLOGINFO handling in fm.c. hb_setget*() functions cannot be used here as the set system is deinited at this point. So local buffers are holding the values. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Fure of MemoEdit is now?
Hi Pritpal In sample i read "you can expect cut/copy/past, search/replace in near future" so the question is have you ready this? Massimo Belgrano -Messaggio originale- Da: [EMAIL PROTECTED] per conto di Pritpal Bedi Inviato: lun 31/12/2007 5.23 A: harbour@harbour-project.org Oggetto: [Harbour] Multi-Window GT - III - MemoEdit() Hello Everybody Please review MemoEdit() implementation for Multi-Window GT. Executable : http://www.nabble.com/file/p14554190/MultiWVT.zip MultiWVT.zip Exe Source: http://www.nabble.com/file/p14554190/MultiWVT.prg MultiWVT.prg Memoedit.prg: http://www.nabble.com/file/p14554190/memoedit.prg memoedit.prg Teditor.prg: http://www.nabble.com/file/p14554190/teditor.prg teditor.prg MemoEdit() needs to be fixed a little to be exactly compatible with Clipper. Please note that for Multi-Window protocol I have to do away with Do While loop to process user input, instead I am returning fully configured MemoEdit object which is processed by window events. This is the only difference. For the time being I have kept out "user function" functionality and hopefully it will be ready by next weekend. Just play with the editor, click anywhere on memo text, resize, maximize, etc. Regards Pritpal Bedi, INDIA-USA -- View this message in context: http://www.nabble.com/Multi-Window-GT---III---MemoEdit%28%29-tp14554190p14554190.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour <>___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbint.c build error under Linux
After 2008-06-27 17:13 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]> * contrib/hbtip/client.prg * contrib/hbtip/ftpcln.prg * contrib/hbtip/httpcln.prg * contrib/hbtip/mail.prg * contrib/hbtip/sendmail.prg + Added methods setget to interrogate buffer size send/recive METHOD InetRcvBufSize( SocketCon, nSizeBuff ) METHOD InetSndBufSize( SocketCon, nSizeBuff ) + Added data members to assign default buffer sizes DATA nDefaultRcvBuffSize DATA nDefaultSndBuffSize + Asigned default buffer size to 64kb only for FTP transfer, previous to open sockets ::nDefaultSndBuffSize := 65536 ::nDefaultRcvBuffSize := 65536 * Fixed port ftp protocol. * source/rtl/hbinet.c * now works with default system buffer, for example 8kb at W2000. instead of harcoded 1400 I get: ../../hbinet.c: In function 'hb_socketConnect': ../../hbinet.c:475: error: 'SOCKET_ERROR' undeclared (first use in this function) ../../hbinet.c:475: error: (Each undeclared identifier is reported only once ../../hbinet.c:475: error: for each function it appears in.) Changes in inet* core functions should be done carefully and well tested. There are many smtp,pop,ftp,* servers outside. How many tests have been done on server/client platforms beside W2000. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: R: [Harbour] 2008-06-30 10:08 UTC+0200 Viktor Szakats (harbour.01syenar hu)
Hi Massimo, These belong to the GNU make system. Start make_gnu.bat to use it (under Windows). Brgds, Viktor On 2008.06.30., at 10:57, Massimo Belgrano wrote: He victor How are build all this makefile? Massimo Belgrano -Messaggio originale- Da: [EMAIL PROTECTED] per conto di Szakáts Viktor 2008-06-30 10:08 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/gtwvg/Makefile * contrib/hbapollo/Makefile * contrib/hbbtree/Makefile * contrib/hbclipsm/Makefile * contrib/hbct/Makefile * contrib/hbfbird/Makefile * contrib/hbfimage/Makefile * contrib/hbgd/Makefile * contrib/hbhpdf/Makefile * contrib/hbmisc/Makefile * contrib/hbmsql/Makefile * contrib/hbmysql/Makefile * contrib/hbmzip/Makefile * contrib/hbnf/Makefile * contrib/hbodbc/Makefile * contrib/hbpgsql/Makefile * contrib/hbsqlit2/Makefile * contrib/hbsqlit3/Makefile * contrib/hbtip/Makefile * contrib/hbtpathy/Makefile * contrib/hbvpdf/Makefile * contrib/hbw32/Makefile * contrib/hbw32ddr/Makefile * contrib/hbwhat32/Makefile * contrib/rddado/Makefile * contrib/rddads/Makefile * contrib/rddads/Makefile * contrib/rddads/Makefile * contrib/hbmisc/Makefile * contrib/gtwvg/Makefile Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 13:18 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-06-30 13:18 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/hbapollo/Makefile * contrib/hbcurl/Makefile * contrib/hbfbird/Makefile * contrib/hbfimage/Makefile * contrib/hbgd/Makefile * contrib/hbhpdf/Makefile * contrib/hbmysql/Makefile * contrib/hbpgsql/Makefile * contrib/rddads/Makefile + Now possible to specify external header location using the HB_INC_* envars (similar to the ones used in non-GNU makefiles). In GNU make, multiple dirs can be specified, and the make system will always autodetect whether the headers are really there. If not, the build process will be skipped for that contrib. Additionally in Linux, the HB_INC_* vars will be inited with a default, if not specified by the builder. These default should be verified by Linux users and extended/fixed accordingly. Most of them were already initialized for Linux, so there should be no big surprises here. * contrib/hbmysql/make_b32.bat * contrib/hbmysql/make_vc.bat + Synced C options with GNU make. (-DBIG_JOINS=1 added) * contrib/hbmysql/make_vc.bat - Removed -D__WIN32__. Now it seems to work without it. * contrib/hbcurl/make_gcc.sh ! Fixed example dir in comment. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 13:33 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-06-30 13:33 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/hbmysql/make_b32.bat * contrib/hbmysql/make_vc.bat * contrib/hbmysql/Makefile - Removed -DBIG_JOINS. If someone needs this, it can be specified via C_USR, but to me it seem this is a MySQL build-time switch, and it has no effect for interface code. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] WIN64: ULONG not equal to size_t
On Sat, 28 Jun 2008, Szakáts Viktor wrote: Hi VIktor, Sorry for late response, I was out of city during weekend. > What to do with hundreds of warnings like in subject, > when compiled in _WIN64 mode? Any practices to avoid it? >From the beginning Harbour uses ULONG as string and array indexes. In POSIX system 'long' should be big enough to store pointer so it's not a problem but WIN64 does not respect it and LONG is 32bit integer. It causes limitation on maximum string and array size in WIN64. Probably in the future we should intorduce separated type for indexes which will be platform dependent. It should be signed integer to avoid problems we have now with negative values in some string/array manipulation functions. Anyhow I do not think we should make this modifications now because it will affect too much of code. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-06-30 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbextern.ch + New inet functions added. * source/rtl/hbinet.c ! Blind fix for Linux compile error. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbint.c build error under Linux
Hi Lorenzo, Can you check now? Brgds, Viktor On 2008.06.30., at 12:37, Lorenzo Fiorini wrote: After 2008-06-27 17:13 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED] > * contrib/hbtip/client.prg * contrib/hbtip/ftpcln.prg * contrib/hbtip/httpcln.prg * contrib/hbtip/mail.prg * contrib/hbtip/sendmail.prg + Added methods setget to interrogate buffer size send/recive METHOD InetRcvBufSize( SocketCon, nSizeBuff ) METHOD InetSndBufSize( SocketCon, nSizeBuff ) + Added data members to assign default buffer sizes DATA nDefaultRcvBuffSize DATA nDefaultSndBuffSize + Asigned default buffer size to 64kb only for FTP transfer, previous to open sockets ::nDefaultSndBuffSize := 65536 ::nDefaultRcvBuffSize := 65536 * Fixed port ftp protocol. * source/rtl/hbinet.c * now works with default system buffer, for example 8kb at W2000. instead of harcoded 1400 I get: ../../hbinet.c: In function 'hb_socketConnect': ../../hbinet.c:475: error: 'SOCKET_ERROR' undeclared (first use in this function) ../../hbinet.c:475: error: (Each undeclared identifier is reported only once ../../hbinet.c:475: error: for each function it appears in.) Changes in inet* core functions should be done carefully and well tested. There are many smtp,pop,ftp,* servers outside. How many tests have been done on server/client platforms beside W2000. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] make_rpm.sh not successful
With current svn rpms doesn't build successfuly. Lp, Tomaž RPM build errors: File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbnf.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbbtree.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbmisc.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbmzip.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbct.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbtip.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libxhb.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbvpdf.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbgt.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbbmcdx.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/libhbclipsm.a ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] make_rpm.sh not successful
Any more pointers (like build std/err log)? I can't see any trends in this list, which could help trace these back to any recent modifications. libhbmisc.a is the simplest lib without any Makefile tricks, so I wonder how could it fail like this. Brgds, Viktor On 2008.06.30., at 15:09, Tomaž Zupan wrote: With current svn rpms doesn't build successfuly. Lp, Tomaž RPM build errors: File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbnf.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbbtree.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbmisc.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbmzip.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbct.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbtip.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libxhb.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbvpdf.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbgt.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbbmcdx.a File not found: /var/tmp/harbour-1.0.0-RC1mdv20080-buildroot/usr/lib/harbour/ libhbclipsm.a ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbint.c build error under Linux
On Mon, Jun 30, 2008 at 3:01 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote: > Can you check now? Of course it builds now, but I'm wondering if the changes have been tested enough. I'm using the tip tests that you've ported to check the various protocols and so far I've found that the ftp client is broken ( BTW there is a cFile[1] == "+" left in tiptest.prg ). The main problem I saw so far is that many RETURN NIL have been changed with RETURN .T. or .F. but in the caller still check of cData == NIL and so Len( cData ) fails with a RT. I'll do a full report at the end of the tests. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] WIN64: ULONG not equal to size_t
Thanks Przemek. I agree to leave this after 1.0. (although we could lay the ground anytime, by introducing the new necessary types) Brgds, Viktor On 2008.06.30., at 14:27, Przemyslaw Czerpak wrote: On Sat, 28 Jun 2008, Szakáts Viktor wrote: Hi VIktor, Sorry for late response, I was out of city during weekend. What to do with hundreds of warnings like in subject, when compiled in _WIN64 mode? Any practices to avoid it? From the beginning Harbour uses ULONG as string and array indexes. In POSIX system 'long' should be big enough to store pointer so it's not a problem but WIN64 does not respect it and LONG is 32bit integer. It causes limitation on maximum string and array size in WIN64. Probably in the future we should intorduce separated type for indexes which will be platform dependent. It should be signed integer to avoid problems we have now with negative values in some string/array manipulation functions. Anyhow I do not think we should make this modifications now because it will affect too much of code. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbint.c build error under Linux
Can you check now? Of course it builds now, but I'm wondering if the changes have been tested enough. I have no idea, but if you could do some tests it would be great. AFAICS behaviour shouldn't have changed if you don't mess with the new manual buffer settings. I'm using the tip tests that you've ported to check the various protocols and so far I've found that the ftp client is broken ( BTW there is a cFile[1] == "+" left in tiptest.prg ). Thanks, I'll change this. The main problem I saw so far is that many RETURN NIL have been changed with RETURN .T. or .F. but in the caller still check of cData == NIL and so Len( cData ) fails with a RT. Where and when did this happen? I'll do a full report at the end of the tests. Thanks. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] make_rpm.sh not successful
On Mon, 30 Jun 2008, Szakáts Viktor wrote: Hi Viktor, > Any more pointers (like build std/err log)? I can't > see any trends in this list, which could help trace > these back to any recent modifications. > libhbmisc.a is the simplest lib without any Makefile > tricks, so I wonder how could it fail like this. The modifications in contrib make files completely broke RPM creation process and now it has to be changed. I'll try to look at it and maybe I'll be able to fix it. Anyhow some of recent modifications will make this process harder. Please note that moving build conditions into separate Makefile(s) in contrib tree makes this process harder. It also seriously interacts with cross builds. Don't also forget that most of libraries which can be compiled in Linux can also be ported to other *nixes (BSD, MacOSX, SunOS, HPUX, AIX, ...) and most of statements like: ifeq ($(HB_ARCHITECTURE),linux) should be updated for this systems, too. These modification also make adding autoconf support much harder because now I will have to add support for it into each library. It will be much easier to check dependences and create contrib library list in one place instead of updating each library. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-30 13:18 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
On Mon, Jun 30, 2008 at 1:29 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote: > 2008-06-30 13:18 UTC+0200 Viktor Szakats (harbour.01 syenar hu) > * contrib/hbapollo/Makefile ... the "problem" I still see is that we need not only the INCLUDE path but also the LIB path expecially under Windows mingw. Under *nix all the libs are are in the /usr/lib but under Windows we cannot count on it. So if we take gnuwin32 as a reference, we would need to define the "prefix" sth like c:\gnu\pgsql and use c:\gnu\pgsql\include in C_USR += -I... and c:\gnu\pgsql\lib in the hb-func.sh so that hbmk can create an executable that uses pgsql. Also we have other architectures f.e. darwin so adding default paths only for linux inside the single Makefiles is not enough. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbint.c build error under Linux
It has more than 6 months running OK over windows platform. Increasing more than 50% speed. Now we are using half default system buffer size. We only use the half for security. at windows platforms this buffer is 8kb or lower then we use 4kb instead of 1kb. Some times when low memory system, the default can be lower than 1kb, then the old code simply crashes (GPF). The default transfer buffer is stablished to 64kb to increase speed, in the same way as work CuteFTP and other's. I can't test it over linux. Best regards, Miguel Angel Marchuet Lorenzo Fiorini escribió: After 2008-06-27 17:13 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]> * contrib/hbtip/client.prg * contrib/hbtip/ftpcln.prg * contrib/hbtip/httpcln.prg * contrib/hbtip/mail.prg * contrib/hbtip/sendmail.prg + Added methods setget to interrogate buffer size send/recive METHOD InetRcvBufSize( SocketCon, nSizeBuff ) METHOD InetSndBufSize( SocketCon, nSizeBuff ) + Added data members to assign default buffer sizes DATA nDefaultRcvBuffSize DATA nDefaultSndBuffSize + Asigned default buffer size to 64kb only for FTP transfer, previous to open sockets ::nDefaultSndBuffSize := 65536 ::nDefaultRcvBuffSize := 65536 * Fixed port ftp protocol. * source/rtl/hbinet.c * now works with default system buffer, for example 8kb at W2000. instead of harcoded 1400 I get: ../../hbinet.c: In function 'hb_socketConnect': ../../hbinet.c:475: error: 'SOCKET_ERROR' undeclared (first use in this function) ../../hbinet.c:475: error: (Each undeclared identifier is reported only once ../../hbinet.c:475: error: for each function it appears in.) Changes in inet* core functions should be done carefully and well tested. There are many smtp,pop,ftp,* servers outside. How many tests have been done on server/client platforms beside W2000. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] make_rpm.sh not successful
Hi Przemek, Any more pointers (like build std/err log)? I can't see any trends in this list, which could help trace these back to any recent modifications. libhbmisc.a is the simplest lib without any Makefile tricks, so I wonder how could it fail like this. The modifications in contrib make files completely broke RPM creation process and now it has to be changed. I'll try to look at it and maybe I'll be able to fix it. Anyhow some of recent modifications will make this process harder. Please note that moving build conditions into separate Makefile(s) in contrib tree makes this process harder. It also seriously interacts with cross builds. Don't also forget that most of libraries which can be compiled in Linux can also be ported to other *nixes I'd appreciate if you could help, as it's extremely difficult to oversee the .rpm creation. My changes seemed humble to me, most of them should have kept existing functionality (in regards to the include path stuff), the rest (header file installation) were clear bugs in previous revisions. I'm sorry if I'm messing up something, but this is exactly the part, where we need to work together. If you have any details to share, why it did fail now, I can give a shot to correct it. For cross-builds, we probably should have a way to detect it. But at this moment I have no idea how contrib cross-builds work in the GNU-make system. (BSD, MacOSX, SunOS, HPUX, AIX, ...) and most of statements like: ifeq ($(HB_ARCHITECTURE),linux) should be updated for this systems, too. These modification also make adding autoconf support much harder because now I will have to add support for it into each library. It will be much easier to check dependences and create contrib library list in one place instead of updating each library. I'd still insist on keeping the logic local. It must be possible to do and the benefits are clear. Before I started this, most contribs didn't even compile, and rules were fully chaotic. It might have worked for the "most important" contribs in Linux, but the goal would be to make this flexible and not let some contribs rot and to make them work on all OSes equally well. I'd also find it important to close the gap between GNU and non-GNU make. If we can make GNU flexible a properly working enough, we might even drop the non-GNU version, which would also make maintenance much easier and usage much clearer. Also notice that before today's changes, each externally dependent contrib was using a slightly unique technique to solve these problems, and I think it would be nice to generalize these, as the problem is the same, the solution should also be generic. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-30 13:18 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Thanks for these insights. I know about darwin, but first of all I don't know how to create more complicate 'if' expressions with GNU make. The other problem is that I don't know what would be the default for those other architecture. We're talking about 8 contribs where we have external dependencies. (Strange that even hbmisc failed for Tomas) As for the lib dir, I wonder why do we need the LIB path in Makefile for mingw? Do you mean we should also deal with .a files for .dlls? [ I did this (debated) thing for non-GNU make, which uses HB_DIR_* (instead of HB_INC_*) so that libs can also be found. ] Brgds, Viktor On 2008.06.30., at 15:55, Lorenzo Fiorini wrote: On Mon, Jun 30, 2008 at 1:29 PM, Szakáts Viktor [EMAIL PROTECTED]> wrote: 2008-06-30 13:18 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/hbapollo/Makefile ... the "problem" I still see is that we need not only the INCLUDE path but also the LIB path expecially under Windows mingw. Under *nix all the libs are are in the /usr/lib but under Windows we cannot count on it. So if we take gnuwin32 as a reference, we would need to define the "prefix" sth like c:\gnu\pgsql and use c:\gnu\pgsql\include in C_USR += -I... and c:\gnu\pgsql\lib in the hb-func.sh so that hbmk can create an executable that uses pgsql. Also we have other architectures f.e. darwin so adding default paths only for linux inside the single Makefiles is not enough. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 16:36 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-06-30 16:36 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/hbtip/tests/tiptest.prg ! Remove strings as arrays access. Thanks Lorenzo. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-30 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
please put this change better // some compilers has missing this define #ifndef SOCKET_ERROR #define SOCKET_ERROR(-1) #endif at the top of hbinet.c instead of substitute if ( getsockopt( Socket->com, SOL_SOCKET, SO_SNDBUF, (char *) &value, &len ) != SOCKET_ERROR ) for if( getsockopt( Socket->com, SOL_SOCKET, SO_SNDBUF, (char *) &value, &len ) == 0 ) The major part of compilers has defined SOCKET_ERROR. It's more clear to read and prevent for future different returns of getsockopt. Best regards, Miguel Angel Marchuet Szakáts Viktor escribió: 2008-06-30 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbextern.ch + New inet functions added. * source/rtl/hbinet.c ! Blind fix for Linux compile error. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-30 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Hi Miguel, Can you pls commit this? Brgds, Viktor On 2008.06.30., at 16:47, Miguel Angel Marchuet wrote: please put this change better // some compilers has missing this define #ifndef SOCKET_ERROR #define SOCKET_ERROR(-1) #endif at the top of hbinet.c instead of substitute if ( getsockopt( Socket->com, SOL_SOCKET, SO_SNDBUF, (char *) &value, &len ) != SOCKET_ERROR ) for if( getsockopt( Socket->com, SOL_SOCKET, SO_SNDBUF, (char *) &value, &len ) == 0 ) The major part of compilers has defined SOCKET_ERROR. It's more clear to read and prevent for future different returns of getsockopt. Best regards, Miguel Angel Marchuet Szakáts Viktor escribió: 2008-06-30 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbextern.ch + New inet functions added. * source/rtl/hbinet.c ! Blind fix for Linux compile error. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-30 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
yes of course. in 5 minutes ;) Szakáts Viktor escribió: Hi Miguel, Can you pls commit this? Brgds, Viktor On 2008.06.30., at 16:47, Miguel Angel Marchuet wrote: please put this change better // some compilers has missing this define #ifndef SOCKET_ERROR #define SOCKET_ERROR(-1) #endif at the top of hbinet.c instead of substitute if ( getsockopt( Socket->com, SOL_SOCKET, SO_SNDBUF, (char *) &value, &len ) != SOCKET_ERROR ) for if( getsockopt( Socket->com, SOL_SOCKET, SO_SNDBUF, (char *) &value, &len ) == 0 ) The major part of compilers has defined SOCKET_ERROR. It's more clear to read and prevent for future different returns of getsockopt. Best regards, Miguel Angel Marchuet Szakáts Viktor escribió: 2008-06-30 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbextern.ch + New inet functions added. * source/rtl/hbinet.c ! Blind fix for Linux compile error. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 17:00 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]>
2008-06-30 17:00 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]> * source/rtl/hbinet.c + Added define SOCKET_ERROR, that is missing in some compilers. Best regards, Miguel Angel marchuet ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbint.c build error under Linux
On Mon, 30 Jun 2008, Lorenzo Fiorini wrote: Hi Lorenzo, > Of course it builds now, but I'm wondering if the changes have been > tested enough. In general the send and receive loop in hbinet.c for mode == 1 is from the beginning technical nonsense and this modifications instead of fixing it added workaround which partially eliminates overhead introduced by data fragmentation. We should simply remove iRcvBufSize/iSndBufSize members from HB_SOCKET_STRUCT and always use iMaxLen/iSend number of bytes. The select() functions used before recv()/send() operation informs us the it will be unblocked operation and system will accept as much data as it will need choosing optimal value without blocking application. Of course we can keep new function to set internal buffer size (SO_RCVBUF/SO_SNDBUF) for users which will want to change it. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-30 17:00 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]>
Thanks! On 2008.06.30., at 17:02, Miguel Angel Marchuet wrote: 2008-06-30 17:00 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED] > * source/rtl/hbinet.c + Added define SOCKET_ERROR, that is missing in some compilers. Best regards, Miguel Angel marchuet ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 17:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-06-30 17:15 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * source/rtl/hbinet.c ! Fixed non-ANSI comment. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
Hola Somebody knows to use this commando Wvt_SetFont( 'Lucida Console',18, 11, 0 ) gtwvt.lib even gives error Me connecting the bookstore I perhaps connect it bad is for a mixed program hmg -ext + console -- Alguien sabe utilizar este comando Wvt_SetFont( 'Lucida Console',18, 11, 0 ) Me da error incluso enlazando la libreria gtwvt.lib quizas la enlazo mal, nose. Es para un programa mixto hmg ext + console Saludos Jose Miguel Ejemplos y programas para Harbour + MiniGUI Extended http://www.embalajesterra.com/misdoc/programas/programas.html ¡Buscá desde tu celular! Yahoo! oneSEARCH ahora está en Claro http://ar.mobile.yahoo.com/onesearch___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
[ I don't know the answer, but that's exactly the confusion I was referring to when dealing with WVT vs. WVG naming. ] Brgds, Viktor On 2008.06.30., at 17:36, Jose Miguel wrote: Hola Somebody knows to use this commando Wvt_SetFont( 'Lucida Console',18, 11, 0 ) gtwvt.lib even gives error Me connecting the bookstore I perhaps connect it bad is for a mixed program hmg -ext + console -- Alguien sabe utilizar este comando Wvt_SetFont( 'Lucida Console',18, 11, 0 ) Me da error incluso enlazando la libreria gtwvt.lib quizas la enlazo mal, nose. Es para un programa mixto hmg ext + console Saludos Jose Miguel Ejemplos y programas para Harbour + MiniGUI Extended http://www.embalajesterra.com/misdoc/programas/programas.html ¡Buscá desde tu celular! Yahoo! oneSEARCH ahora está en Claro http://ar.mobile.yahoo.com/onesearch___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
AFAIK WVT_SETFONT is not supported you can try with Hb_GtInfo( HB_GTI_FONTNAME,..) Hb_GtInfo( HB_GTI_FONTWIDTH, .. ) Hb_GtInfo( HB_GTI_FONTSIZE ,.. ) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szakáts Viktor Sent: Monday, June 30, 2008 5:42 PM To: [EMAIL PROTECTED]; Harbour Project Main Developer List. Subject: Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 ) [ I don't know the answer, but that's exactly the confusion I was referring to when dealing with WVT vs. WVG naming. ] Brgds, Viktor On 2008.06.30., at 17:36, Jose Miguel wrote: > Hola > > Somebody knows to use this commando > Wvt_SetFont( 'Lucida Console',18, 11, 0 ) > gtwvt.lib even gives error Me connecting the bookstore I perhaps > connect it bad > is for a mixed program hmg -ext + console > -- > Alguien sabe utilizar este comando > Wvt_SetFont( 'Lucida Console',18, 11, 0 ) > Me da error incluso enlazando la libreria gtwvt.lib > quizas la enlazo mal, nose. > Es para un programa mixto hmg ext + console > > Saludos > Jose Miguel > > > > Ejemplos y programas para Harbour + MiniGUI Extended > http://www.embalajesterra.com/misdoc/programas/programas.html > > > > ¡Buscá desde tu celular! Yahoo! oneSEARCH ahora está en Claro > http://ar.mobile.yahoo.com/onesearch___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
But if gtwvg use a include (suggested from you) for maintain same function name the problem remain same Is possible inherit gtwvg from gtwvt without rewriting Is possible create a structure for extend gtwvt with library like gtwvg without rewriting gtwvg? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szakáts Viktor Sent: Monday, June 30, 2008 5:42 PM To: [EMAIL PROTECTED]; Harbour Project Main Developer List. Subject: Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 ) [ I don't know the answer, but that's exactly the confusion I was referring to when dealing with WVT vs. WVG naming. ] Brgds, Viktor On 2008.06.30., at 17:36, Jose Miguel wrote: > Hola > > Somebody knows to use this commando > Wvt_SetFont( 'Lucida Console',18, 11, 0 ) > gtwvt.lib even gives error Me connecting the bookstore I perhaps > connect it bad > is for a mixed program hmg -ext + console > -- > Alguien sabe utilizar este comando > Wvt_SetFont( 'Lucida Console',18, 11, 0 ) > Me da error incluso enlazando la libreria gtwvt.lib > quizas la enlazo mal, nose. > Es para un programa mixto hmg ext + console > > Saludos > Jose Miguel > > > > Ejemplos y programas para Harbour + MiniGUI Extended > http://www.embalajesterra.com/misdoc/programas/programas.html > > > > ¡Buscá desde tu celular! Yahoo! oneSEARCH ahora está en Claro > http://ar.mobile.yahoo.com/onesearch___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
But if gtwvg use a include (suggested from you) for maintain same function name the problem remain same It's one step to the right direction. Is possible inherit gtwvg from gtwvt without rewriting Is possible create a structure for extend gtwvt with library like gtwvg without rewriting gtwvg? I'd think it's possible to inherit more GTWVT features rather than keeping a local copy of it in GTWVG. Other than that the current structure looks alright. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-30 19:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-06-30 19:20 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/hbapollo/Makefile * contrib/hbcurl/Makefile * contrib/hbfbird/Makefile * contrib/hbfimage/Makefile * contrib/hbgd/Makefile * contrib/hbhpdf/Makefile * contrib/hbmysql/Makefile * contrib/hbpgsql/Makefile * contrib/rddads/Makefile * Changed to use default for all architecture. Let's hope that checking existence for mixed platform paths won't create problems on any platforms. + Added include path detection logic to hbapollo, too. + Added Darwin path to hbgd include path list. + Added std Linux path to hbfbird include path list. ; TOFIX: Seems that 'ifneq ($(HB_INC_*_OK),)' doesn't really work if no path in the path list is valid. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
Hello Viktor Szakáts Viktor wrote: > > [ I don't know the answer, but that's exactly the > confusion I was referring to when dealing with WVT > vs. WVG naming. ] > I understand the problem. It is a matter of proper documentation. If we change to WVT->WVG then future merging and upgradation will be a tedius affair. Even then we must be having wrappers for old functions to avoid application crashes ( as I explained earier ). Ok, I will post a basic help .chm in probbaly next two weeks covering HB_GtInfo() in general and GTWVT/GTWVG in specific. Because I have HelpAndManual licensed with me, it will be faster to write and port to other formats. I invite everybody to put forth your suggessions on the design/contents/layout/etc of GT help manual. To make the process visible to everybody I intend to publish it also as an online help at http://harbour_gt.vouch.info/ besides .chm. .pdf formats. I will start this help project after I gather more information from all of you. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Wvt_SetFont%28-%27Lucida-Console%27%2C18%2C-11%2C-0-%29-tp18198327p18201852.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
Not exactly. Massimo Belgrano-3 wrote: > > AFAIK WVT_SETFONT is not supported you can try with > > Hb_GtInfo( HB_GTI_FONTNAME,..) > Hb_GtInfo( HB_GTI_FONTWIDTH, .. ) > Hb_GtInfo( HB_GTI_FONTSIZE ,.. ) > If above approach is to be followed, then Hb_GtInfo( HB_GTI_FONTSIZE ,.. ) call must be the last one. But still you may miss exat same behavior what Wvt_SetFont() accomplishes if you use font weight and quality different then the defaults. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Wvt_SetFont%28-%27Lucida-Console%27%2C18%2C-11%2C-0-%29-tp18198327p18201942.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
Hi Priptal, Szakáts Viktor wrote: [ I don't know the answer, but that's exactly the confusion I was referring to when dealing with WVT vs. WVG naming. ] I understand the problem. It is a matter of proper documentation. If we change to WVT->WVG then future merging and upgradation will be a tedius affair. Even then we must be having wrappers for old functions to avoid application crashes ( as I explained earier ). That's okay, but then we can say that "WVT_*() functions are deprecated, please use WVG_*() functions instead." This is very important. I can even create a small batch file which would do the conversion in a few seconds. If we don't correct mistakes like this early enough, Harbour will look like the Windows API... Ok, I will post a basic help .chm in probbaly next two weeks covering HB_GtInfo() in general and GTWVT/GTWVG in specific. That won't really help IMO (at least not to this problem). Code is best if self documenting, and unambiguous by itself. And the problem is with such posts as we got today: No one on the list can be sure what is the issue, and with what. With and without a documentation. I'd suggest to document the new names, and also do some steps to support those new names in the code. If you're documenting the easy-to-misunderstood ones, it will just add "insult to injury", and conserve the problem forever. Because I have HelpAndManual licensed with me, it will be faster to write and port to other formats. I invite everybody to put forth your suggessions on the design/contents/layout/etc of GT help manual. To make the process visible to everybody I intend to publish it also as an online help at http://harbour_gt.vouch.info/ besides .chm. .pdf formats. I will start this help project after I gather more information from all of you. That's good, but I think we should discuss the tools to use, before we jump into Harbour core documentation. If it's for GTWVG only, it's all good. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbint.c build error under Linux
In general the send and receive loop in hbinet.c for mode == 1 is from the beginning technical nonsense and this modifications instead of fixing it added workaround which partially eliminates overhead introduced by data fragmentation. We should simply remove iRcvBufSize/iSndBufSize members from HB_SOCKET_STRUCT and always use iMaxLen/iSend number of bytes. The select() functions used before recv()/send() operation informs us the it will be unblocked operation and system will accept as much data as it will need choosing optimal value without blocking application. Of course we can keep new function to set internal buffer size (SO_RCVBUF/SO_SNDBUF) for users which will want to change it. iRcvBufSize/oSndBufSize now contents the maximum buffer assigned by system, we need to know this value saved at iRcvBufSize/oSndBufSize, because we can use only half of this buffer for safe, almost meanwhile we work with synchronous buffers. IMPORTANT this buffers don't have a fix size almost at windows platform, it depends of the free memory system, by default 8kb. Normally we can try to increase it as necessary. for example we have good rates using 64kb bytes to transfer ftp and 16kb for http. for this reason we can't remove iRcvBufSize/oSndBufSize, we need to know this values to not use more than half buffer to save. Test using more size some time produce lost of data (windows platforms) is possible that linux works better and is possible to use full system buffer size. You can say to me what is the default system buffer size at linux platforms ? Best regards, Miguel Angel Marchuet ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
Sorry Viktor Szakáts Viktor wrote: > > That's okay, but then we can say that "WVT_*() functions > are deprecated, please use WVG_*() functions instead." > This is very important. I can even create a small batch > file which would do the conversion in a few seconds. > I am not geared up to change everything in my code. At least not as per now. I have to look into more details about my data-dictionaries and user base. Until I find a solution to it I cannot change the namespace. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Wvt_SetFont%28-%27Lucida-Console%27%2C18%2C-11%2C-0-%29-tp18198327p18203232.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
My suggestion for structure of gt help manual: What is a gt? What is common to all gt and what the differences between gt? How use multiple gt One Sample that using all gt At least one Screenshoot for each gt/platform How Ct3 function can be used ad Viagra for gt (open and close) What can do a gt: set font, codepage, size of windows,resize, ecc) History of gt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pritpal Bedi Sent: Monday, June 30, 2008 8:48 PM To: harbour@harbour-project.org Subject: Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 ) Because I have HelpAndManual licensed with me, it will be faster to write and port to other formats. I invite everybody to put forth your suggessions on the design/contents/layout/etc of GT help manual. To make the process visible to everybody I intend to publish it also as an online help at http://harbour_gt.vouch.info/ besides .chm. .pdf formats. I will start this help project after I gather more information from all of you. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Wvt_SetFont%28-%27Lucida-Console%27%2C18%2C-11%2C-0-%29-tp18198327p18201852.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
Okay, take your time. [ For possible methods to ease transition, you can have a look at xhb.lib, which contains most such ideas (hbcompat.ch). With some clever rearrangement, this can be made quite smooth. ] Brgds, Viktor On 2008.06.30., at 22:02, Pritpal Bedi wrote: Sorry Viktor Szakáts Viktor wrote: That's okay, but then we can say that "WVT_*() functions are deprecated, please use WVG_*() functions instead." This is very important. I can even create a small batch file which would do the conversion in a few seconds. I am not geared up to change everything in my code. At least not as per now. I have to look into more details about my data-dictionaries and user base. Until I find a solution to it I cannot change the namespace. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Wvt_SetFont%28-%27Lucida-Console%27%2C18%2C-11%2C-0-%29-tp18198327p18203232.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 )
What tools pritpal plan use? Doxygen seem a open source solution for extract documentation from source I think that good documentation can be write also with openoffice writer Imo as final format pdf is better than hlp. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szakáts Viktor Sent: Monday, June 30, 2008 8:58 PM To: Harbour Project Main Developer List. Subject: Re: [Harbour] Wvt_SetFont( 'Lucida Console',18, 11, 0 ) > > I will start this help project after I gather more information from > all of > you. That's good, but I think we should discuss the tools to use, before we jump into Harbour core documentation. If it's for GTWVG only, it's all good. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OT - E-Mail Address Verification
On Friday 27 June 2008 02:43:12 am gabor salai [intranet242] wrote: > you may check everything [address forming, mail servers, ...], but the > final test, is there a mail box named "alfa.beta" on domain "gama.delta", > is not possible. as i remember [maybe phil wrote few years ago] there *is* > a mail protocol query upon which the server should answer "yes, i have an > inbox for that mail address", but for security [anti-spam] reason mail > admins often [allways?] disable that response. > > so, sending coded message to tested address, and waiting for somebody > response is the only way to test that address is real The SMTP protocol REQUIRES that this exchange works, so it can't be disabled. Yes, a brute force can figure out which mailboxes are real, but so can a mail run, so it's never done with brute force. Simply because the run that validates the email address could have been the run that delivered the mail, so the spammers never take twice as long as they need to. The detection routine that I posted still works today. -- Waiting for sunspots. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] gnu Makefiles issue under Linux
On Friday 27 June 2008 08:17:12 am Szakáts Viktor wrote: > Any suggestions how to solve this in a way that all special > inclusion logic is self-contained in local contrib Makefiles > (contrib/*/Makefile), yet come out error-free from a 'make clean'? I like the way perl does it with cpan. Contribs are not built into the base. They query the environment, each library has a requirements list and if the requirements are met, it is compiled for that target. Its not an easy thing, but it sure works great. -- Waiting for sunspots. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
