Re: [Harbour] Viktor - where are you
Hello Marek and all, I'm alive and well (after breathing some fresh air outside this list), I was/am pretty busy with other things, amongst these some local large apps were by now converted to Harbour (Win/OSX, Linux to follow soon) for the most part (I've found conversion to be an indefinite process, so I cannot say "fully"). By now there is a pretty big (and probably useful) bunch of local patches which I'd like to submit sometimes in the future. The first half was committed by Przemek already (many thanks for the great job!). I can send the second half to the list, maybe you can all help them to be committed. Many of these changes were addressing codepage and hbct lib issues. Also, I have a local list of TOFIXes about issues found with Harbour. Weekend's news is line drawing support for GTWVT regardless of the codepage used (plus CP selection was fixed), this works in both Unicode and non-Unicode mode. This makes it possible to abandon DOS codepages without losing drawing chars. I've seen very nice Christmas presents contributed to Harbour, and I also have one, my CUI windowing layer is now ready to be committed, pls decide if it should make it into Harbour, and where. The layer is similar to CTWIN, but it allows to write to background windows and handles overlapping windows much better in general. BTW, Harbour in real life environments seems very-very stable. Keep up the good work folks, I'm trying to catch up with the list and contribute as soon as I can. Brgds and Happy New Year to you all, Viktor On Thu, Jan 8, 2009 at 4:46 PM, Horodyski Marek (PZUZ) < m.horody...@pzuzycie.com.pl> wrote: > ? > ___ > 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] 2009-01-13 14:07 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek,
I'd suggest to use following function names, to keep them in the same
"namespace":
HB_PROCESSOPEN()
HB_PROCESSVALUE() (unchanged)
HB_PROCESSCLOSE()
hb_fsProcessOpen()
hb_fsProcessValue() (unchanged)
hb_fsProcessClose()
[ Slightly related to this, I've a pending addition of WIN_RUNDETACHED() to
hbwin.lib. ]
Brgds,
Viktor
On Tue, Jan 13, 2009 at 2:07 PM, Przemyslaw Czerpak wrote:
> 2009-01-13 14:07 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/common.mak
> * harbour/source/rtl/Makefile
> * harbour/include/hbapifs.h
> * harbour/include/hbextern.ch
> + harbour/source/rtl/hbproces.c
> + harbour/source/rtl/hbprocfn.c
>+ added C functions hb_fsOpenProcess(), hb_fsProcessValue(),
> hb_fsCloseProcess()
>+ added .prg functions HB_OPENPROCESS(), HB_PROCESSVALUE(),
> HB_CLOSEPROCESS()
>Based on xHarbour code by Giancarlo Niccolai.
>Warning: it's possible that they will be changed in the future.
>Please test current implementation. Now few notes about it.
>Each handle returned by HB_OPENPROCESS() have to be closed
>by HB_PROCESSVALUE(). Even if process is killed by HB_CLOSEPROCESS()
>its handle is still open and HB_PROCESSVALUE() has to be executed.
>Type of handle depends on OS. In *nixes it's process PID. In MS-Windows
>it's HANDLE. HB_PROCESSVALUE() attach process exit result in *nixes
>cleaning zombie processes and in Windows closing the HANDLE. If you
>do not call this function then you will have resource leak.
>HB_CLOSEPROCESS() only sends quite request to the process but does
>not execute any cleanup code.
>All communication handles returned in parameters by reference by
>HB_OPENPROCESS() function have to be closed using FCLOSE() function.
>If hStdOut and hStdErr are references to the same variables then
>executing process stdout and stderr is redirected to the only one
>pipe. When handles for stdout, stderr and stdin are not given then
>executed process inherits them from parent process unless
>parameter is not given. In such case they are redirected to null
>device (/dev/null or NUL).
>The OS2 version is not tested. Please make tests.
>There is no support for DOS which is single process OS.
>In WinCE builds std{out,err,in} redirecting and process detaching does
>not work too.
>The parameters parsing should be updated. Now MS-Windows version uses
>native OS command line parsing and quoting by "" can be used for
>parameters with blank characters. I do not know any escape character
>which can be used to pass (") as parameter to MS-Windows application.
>In all other OS-es standard bourne shell rules are used. Parameters can
>be quoted by "" or '' and escape character is \. Quoting by '' disables
>special meaning of escape character. In OS2 where \ is path separator
>escaping and '' quoting is disabled so it works like in MS-Windows
>but I do not know if parameters divided by calling process are fully
>respected by low level API calls in this system.
>
> 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] Compiling harbour on PellesC for wince
Jose, I use these: --- set HB_CROSS_BIN_DIR=C:\!hb\_cross_compile set HB_BIN_COMPILE=%HB_CROSS_BIN_DIR% set HB_PPGEN_PATH=%HB_CROSS_BIN_DIR% set HB=%HB_CROSS_BIN_DIR%\harbour.exe set HBPP=%HB_CROSS_BIN_DIR%\hbpp.exe --- This should work for both GNU and non-GNU makes, unfortunately the cross compilation envvar names are not synced, but above will set them all. In your example, there is no 'HB' envvar, that's why it fails. [ also see my previous examples on this list ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-13 22:44 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Thanks a lot! Brgds, Viktor On Tue, Jan 13, 2009 at 10:44 PM, Przemyslaw Czerpak wrote: > 2009-01-13 22:44 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/bin/hb-func.sh >! restored GCC optimization flags in hb* scripts disabled > unintentionally > by some other modifications > > * harbour/include/hbapifs.h > * harbour/source/rtl/hbproces.c >* renamed hb_fsOpenProcess() and hb_fsCloseProcess() to > hb_fsProcessOpen(), hb_fsProcessClose() > > * harbour/include/hbextern.ch > * harbour/source/rtl/hbprocfn.c >* renamed hb_openProcess() and hb_closeProcess() to > hb_processOpen(), hb_processClose() > > * harbour/contrib/xhb/hbcompat.ch >* added xHarbour compatible translations > hb_openProcess() <-> hb_processOpen() > hb_closeProcess() <-> hb_processClose() > > 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
[Harbour] ChangeLog: 2009-01-14 16:15 UTC+0100 Viktor Szakats
Here is all my patches, pls test and comment. It's possible some mistakes crippled in, while applying/merging all these patches. Also don't forget to check the TOFIX section at the end. 2009-01-14 16:15 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/rtl/net.c * contrib/hbziparc/hbziparc.prg * contrib/hbct/files.c * Minor formatting. * source/rtl/gtxwc/gtxwc.c ! Fix to recent fix. An '!' was missing, Przemek pls check me. * source/rtl/philes.c + HB_PROGNAME() now returns absolute path in *NIX systems, too. (please test and refine) * source/lang/msgca.c ! Fixes from xhb. * contrib/hbziparc/hbziparc.prg * Minor correction ( = -> := ) * source/rtl/gtwin/gtwin.c + Added HB_GTI_CODEPAGE support. As per MS docs, this works only when non-raster font is used in the console window. Notice that the accepted CP values are different from the GTWVT ones (GTWIN being the more "logical" one, since it's a newer API). Currently, Harbour doesn't try to hide these interface details. ; TODO: UNICODE and BOX char support for GTWIN mode. * source/rtl/tbrowse.prg * Using HB_DISPOUTATBOX() to draw column/header/footer separators. ; NOTE: This may cause problems if someone wants to use native CP (accented or other special CP specific) chars to draw these screen elements. Maybe an option should be added, or some sort of markings in the separator strings to control that. Pls REVIEW. * include/hbextern.ch * source/rtl/console.c + Added HB_DISPOUTATBOX() which is similar to HB_DISPOUTAT(), but marks the text drawn as HB_GT_ATTR_BOX, so these chars can be properly displayed as drawing chars, regardless of the selected codepage. Another difference is that this function only supports strings to be printed. Other types don't print anything. ; NOTE: Maybe this function could use a better name, pls review and decide. * source/rtl/gtwvt/gtwvt.c * source/rtl/gtwvt/gtwvt.h ! Fixed not accepting zero as a HB_GTI_CODEPAGE value. ! Fixed HB_GTI_CODEPAGE to change the codepage. + Added box char support in Unicode mode. For chars marked as HB_GT_ATTR_BOX, chars will be mapped to Unicode according to CP437. + Added box char support in non-Unicode mode. For chars marked as HB_GT_ATTR_BOX, OEM_CHARSET will always be used. ; NOTE: This way it's possible to use ISO/WIN codepages with GTWVT, while still being able to use various drawing chars (lines, blocks, arrows). ; NOTE: The available set of drawing chars depends on the OS OEM_CHARSET mapping _for non-Unicode Harbour_. For Unicode Harbour, full CP437 codepage is always available. ; NOTE: This solution doesn't go as far as (GTWXC) to graphically draw / emulate these chars. ; TODO: Add HB_GTI_BOXCP support to change hard-wired "EN" CP. * include/hbapigt.h * include/hbgtcore.h ! Moved HB_GT_ATTR_* macros to public headers, because they are needed for public API functions. * contrib/hbwin/win_reg.prg + w32_regRead(): Added second parameter to specify the default value returned in case the reg entry doesn't exist. If not specified, NIL will be returned, just like before. + GetRegistry(): Added 4th parameter with same purpose as above. * source/rtl/hbregex.c * Minor opt. * contrib/hbwin/win_misc.c * Added command line option parameter to WIN_RUNDETACHED(). * include/hbapi.h + HB_ERRCODE (to replace ERRCODE) + HB_SUCCESS (to replace SUCCESS) + HB_FAILURE (to replace FAILURE) + contrib/hbwin/win_misc.c * contrib/hbwin/common.mak * contrib/hbwin/Makefile + WIN_SHELLEXECUTE() WIN_RUNDETACHED() WIN_LOADRESOURCE() Added some new Windows API wrappers. ; TODO: Add hb_osEncode() to them. * source/rtl/diskspac.c * source/rtl/disksphb.c ! Fixed DISKSPACE() and HB_DISKSPACE() for Darwin. Previously they had returned erroneous values. ; TOFIX: Probably HB_DISKSPACE() should be implemented for Watcom and CEGCC, just like DISKSPACE() is. * source/rtl/filesys.c ! hb_fsGetAttr() to set the returned attribute to zero in case of error. * include/hbextern.ch * source/rtl/philes.c + HB_FSETATTR( , @ ) -> + HB_FGETATTR( , ) -> + HB_FSETDATETIME( , [], [] ) -> * source/rtl/direct.c ! Fixed DIRECTORY() when called with "V" (label) parameter. Tested under Windows. Please test/correct for other platforms. On Windows, the dirspec should not contain a filemask in order to work. * contrib/hbtip/base64x.c % HB_BASE64(): Optimized, cleaned. ! HB_BASE64(): Removed second parameter allowing to pass the length of the string. This could cause GPF if passed incorrectly. Now length is s
[Harbour] 2009-01-14 17:51 UTC+0100 Viktor Szakats
(still one of the pending changes) 2009-01-14 17:51 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbmzip/hbmzip.c + Added .prg level functions: HB_ZIPSTOREFILEHANDLE(): To add a new file to a .zip via an already open handle (typically a temp file). Obviously, file date/time/attrib will not be set. HB_UNZIPEXTRACTCURRENTFILETOHANDLE(): To extract a file to an already open file handle. ; NOTE: I'm not sure if these new functions are useful enough to be added to official SVN. Except for Windows, there doesn't seem to be a trend that OSes would support native temp files, so that we can use this to avoid race conditions. Opinions are welcome. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] LOGCDX RDD
Hi Francesco, Surely it can be done, it's a matter of investing some time into it. I'd suggest 'udd*' as a lib name for them to make it clear these are hbusrrdd "plugins". For GNU-make it's actually pretty easy to do, for non-GNU, it needs some more manual work. Brgds, Viktor On Wed, Jan 14, 2009 at 9:48 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Przemek, > > Il 14/01/2009 2.25, Przemyslaw Czerpak ha scritto: > >> >> I do not see and CDX specific code and in above version it will >> be more general. Maybe you should also change function names from >> hb_LogCdx*() to hb_LogRdd*() and maybe RDD name or also used DEFINE >> like: >> #define LOGRDD_NAME LOGCDX >> >> If it can be useful I can upload to SVN. >>> >> >> Yes, please do that. I think that some people will find very useful. >> >> > Done, I hope that solution I have adopted, using a function call than a > fixed macro, it is a valid solution. > Tested locally with my xharbour version it works correctly. > > Please advise in case of errors. > > Any question, also to Viktor, there is a way to build also user rdd in SVN > as a standard lib ? I don't know if it will be a good solution to add them > to hbusrrdd, or not ? > > Best regards, > > Francesco > > > > ___ > 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] ChangeLog: 2009-01-14 16:15 UTC+0100 Viktor Szakats
Hi Mindaugas, I don't know it very deeply, just stumbled upon it accidentally while reading about Python 3.0. The end result looks very clean, just like the doc sources (even cleaner than MediaWiki, if such comparison makes any sense). So Harbour came instantly in mind. It doesn't seem like a source code scanner though, so the docs has to be converted from some format (like NG) or written from scratch. Since the format is simple, conversion may be feasible. I agree that neither Robodoc nor Doxygen is perfect for Harbour, so this one may still have a chance. hbmake is useless as is. We should dump it sooner or later, otherwise we will stay under the false impression we have a working documenter tool ;) Docs would indeed be important for Harbour. I wish we could somehow borrow the xhb one, or cooperate with xhb to make it apply for both projects. This way it's a proper waste of resources. BTW, Python is a beautifully crafted tool, and certain issues and development directions seem to fall in line with Harbour's. Brgds, Viktor On Wed, Jan 14, 2009 at 6:48 PM, Mindaugas Kavaliauskas wrote: > Hi, > > > http://sphinx.pocoo.org/ >>- Documentation format >> > > Viktor, can you add some comment about this documentation system. Does > Sphinx parses source files? Can it parse .prg code? > > I'm used to see to sources, but sometimes it would be more quick to look to > docs for function parameters, etc. I've looked to utils/hbdoc, but could not > make anything, because hbdoc.exe requires some Norton Guide link file, I was > not able to find one in SVN. > > > I've also tried to look at a few documentation systems: > 1) Robodoc creates manual using ugly "section/subsection" headings. > 2) Doxygen is oriented to object oriented programming style. It tries to > document classes, methods, etc., but no documentation for functions. Though, > I was able to manage documentation of functions by including it into > modules. > Doxygen analyses code itself (not only documentation inside comments), so, > it is unable to parse unsupported programming language (i.e. PRG code). > > > Writing a simple source parser (parses documentation tags inside comments), > it's a few hours job. I think we need one for function documentation. > > > > Best regards, > Mindaugas > ___ > 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] LOGCDX RDD
On Wed, Jan 14, 2009 at 11:42 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Viktor, > > Il 14/01/2009 23.34, Francesco Saverio Giudice ha scritto: > >> >> and what about a single hbusrdds.lib or hbudds.lib that contains all >> together, see that all are small prg files ? >> > For a kick start it's a good idea to create one monolithic lib. This makes it possible to clean, debug and use them instantly. On the longer run I'd personally prefer them separate. Otherwise it makes them look like one monolithic lib, which they really aren't. Similar logic is already implemented for rddsql, where we have sdd* libs as "plugins". For the monolithic name, I'd suggest 'hbuddall' (or 'hbudds, but the single 's' can mean 'static' and other things, so it's a bit ambigous), and later we can still move to 'udd*'. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2009-01-15 00:46 UTC+0100 Viktor Szakats
2009-01-15 00:46 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/pp/hbpp.c * utils/hbdoc/hbdoc.prg * utils/hbmake/hbmake.prg * utils/hbtest/hbtest.prg * utils/hbrun/hbrun.prg * More copyrights bumped to 2009. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-15 00:46 UTC+0100 Viktor Szakats
ops, corrected, forgot to 'svn update'. it's yours now. Brgds, Viktor On Thu, Jan 15, 2009 at 1:10 AM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Viktor, > > Il 15/01/2009 0.47, Viktor Szakáts ha scritto: > > 2009-01-15 00:46 UTC+0100 Viktor Szakats (harbour.01 syenar hu) >> * source/pp/hbpp.c >> * utils/hbdoc/hbdoc.prg >> * utils/hbmake/hbmake.prg >> * utils/hbtest/hbtest.prg >> * utils/hbrun/hbrun.prg >>* More copyrights bumped to 2009. >> -- >> > > I don't see this update on SVN. > I'm ready with hbuddall update. May I commit ? > > Best regards, > > Francesco > ___ > 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] 2009-01-15 23:08 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com)
Hi Francesco, I've just tested the non-GNU MSVC build, and it worked flawlessly. Thanks a lot! Brgds, Viktor On Thu, Jan 15, 2009 at 11:10 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > 2009-01-15 23:08 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com > ) > * harbour/common.mak > * harbour/config/global.cf > * harbour/harbour-wce-spec > * harbour/harbour-win-spec > * harbour/harbour.spec > * harbour/make_b32.bat > * harbour/make_b32.mak > * harbour/make_gcc.mak > * harbour/make_vc.mak >* Added hbuddall library to standard make files > ; NOTE: hbuddall contains all USR RDDS files in > harbour/source/rdd/usrrdd/rdds/* > Viktor pls check me. > > * harbour/source/rdd/usrrdd/rdds/arrayrdd.prg > * harbour/source/rdd/usrrdd/rdds/fcomma.prg > * harbour/source/rdd/usrrdd/rdds/hscdx.prg > * harbour/source/rdd/usrrdd/rdds/logrdd.prg >* fixed assigned but unused variable > > > Best regards > > Francesco > ___ > 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] Automatic SVN commit mails
Hi all, On sf.net there is support automatic commit e-mails for SVN. It's easy to setup on the sf.net admin page. There is a short mod and a long mode, where the diff is included. What do you guys think about enabling it, so that the ChangeLog e-mails are sent automatically by the system? This way there would be one less manual thing (or local script) to worry about. I'd vote to turn it on and experiment with it for a few days, so that we can see the format, and decide to keep it or not. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Automatic SVN commit mails
http://alexandria.wiki.sourceforge.net/Subversion+-+Version+Control+for+Source+Codeunder "Hook scripts" I assume it would include the commit message in the e-mail, and SVN users should make sure the commit message always contains the relevant ChangeLog entry. This is the good practice anyway, and this is how we've been doing it so far. Brgds, Viktor On Fri, Jan 16, 2009 at 11:03 AM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Viktor, > > Il 16/01/2009 1.49, Viktor Szakáts ha scritto: > >> There is a short mod and a long mode, where the diff is included. >> >> If it is possible to limit only to Changelog file, then ok in long mode > with diff. > Do you have a link to sf.net site where I can read something or see a > sample ? > > Best regards > > Francesco > > ___ > 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] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
This is how such e-mail looks like. It looks fine to me. Now, the problem is, the sender e-mail address is always the committer's sf.net e-mail alias, and our mailing list allows only members to post (rightly so), which means that we cannot set the mailing list address as recipient, since mails will be ignored. Unless committer happens to use the sf.net address to subscribe to the list, but that's currently no one. Any ideas how to resolve that the best way? Brgds, Viktor -- Forwarded message -- From: [vszakats users sourceforge net] Date: Fri, Jan 16, 2009 at 12:26 PM Subject: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog To: ***...@** Revision: 10057 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10057&view=rev Author: vszakats Date: 2009-01-16 11:26:53 + (Fri, 16 Jan 2009) Log Message: --- testing hook Modified Paths: -- trunk/harbour/ChangeLog Modified: trunk/harbour/ChangeLog === --- trunk/harbour/ChangeLog 2009-01-16 00:31:36 UTC (rev 10056) +++ trunk/harbour/ChangeLog 2009-01-16 11:26:53 UTC (rev 10057) @@ -7,7 +7,7 @@ For example: 2008-12-31 13:59 UTC+0100 Foo Bar (foo.bar foobar.org) */ - +TESTING 2009-01-16 01:30 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbct/video.c * contrib/hbct/pack.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
I'm not sure how svnnotify works, but if it's a client side solution, we haven't solved too much (the point would be to make this fully automatic for everyone), if it's server side, the choices are limited to the sf.net hosted notifier script, and with this, the only configuration option is a destination e-mail. Maybe some sort of forwarder e-mail address could do the job. Brgds, Viktor On Fri, Jan 16, 2009 at 2:31 PM, DB Topas wrote: > Viktor Szakáts wrote: > >> Any ideas how to resolve that the best way? >> > > > Hi, > > > svnnotify --from somewh...@example.com > > > Regards, > Mindaugas > ___ > 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] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
> > Maybe some sort of forwarder e-mail address could do the job. >> >> As I have seen in sf.net docs the only option is: > "we only support one user-provided option to this script, the email address > to send the notification to" > so email will be sent using sf login name. > This can be solved if Phil can add sf developers to ng list as valid > senders. Yes, if Phil can configure the list to allow mails coming from @users.sourceforge.net, that would solve the problem. > The other question is that, AFAIR and for description I have read, > svnnotify will send every commit made to any file on SVN and not only to > changelog file, as implemented on sf.net, and this I don't like. > So, if this is confirmed, even if I like idea my vote is no because, also > if there is more work to do, I continue to prefer a clean message reporting > that part of changelog regarding a single commit. I've just tested it with a real-life commit, and there is _one_ e-mail sent for one commit, regardless of the number of files involved. And this is completely normal. So what essentially is happening, is that it's enough for the committer to copy the relevant (uncommitted) ChangeLog entry into the SVN commit window (aka "log message") (this is unchanged compared to current practice). And a proper mail will be sent with the given ChangeLog entry. So with the new method we can save the manual e-mailing. Which is IMO very nice. This new mail format - while more cryptic at first - contain information about the trunk/branch committed, it contains the revision number, too, which also help avoiding mistakes and it's a pain to add manually. It's also very nice (but your mileage can vary), that the diff can be included. I most of the time watch the diffs manually using SVN or WinMerge, so this one can be also saved. It's a very good change to review mistakes, too. Here's the mail I've got from a proper commit: - Revision: 10059 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10059&view=rev Author: vszakats Date: 2009-01-16 15:01:58 + (Fri, 16 Jan 2009) Log Message: --- 2009-01-16 16:01 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/examples/misc/guess.prg * Formatting. (just to test SVN commit hook). Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/examples/misc/guess.prg Modified: trunk/harbour/ChangeLog === --- trunk/harbour/ChangeLog 2009-01-16 11:36:54 UTC (rev 10058) +++ trunk/harbour/ChangeLog 2009-01-16 15:01:58 UTC (rev 10059) @@ -8,6 +8,10 @@ 2008-12-31 13:59 UTC+0100 Foo Bar (foo.bar foobar.org) */ +2009-01-16 16:01 UTC+0100 Viktor Szakats (harbour.01 syenar hu) + * contrib/examples/misc/guess.prg +* Formatting. (just to test SVN commit hook). + 2009-01-16 01:30 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbct/video.c * contrib/hbct/pack.c Modified: trunk/harbour/contrib/examples/misc/guess.prg === --- trunk/harbour/contrib/examples/misc/guess.prg 2009-01-16 11:36:54 UTC (rev 10058) +++ trunk/harbour/contrib/examples/misc/guess.prg 2009-01-16 15:01:58 UTC (rev 10059) @@ -2,23 +2,23 @@ * $Id$ */ -// -// Guess a number -// -// Date : 1999/04/22 -// -// My first application (big word) written in Harbour -// -// Written by Eddie Runia -// www - http://www.harbour-project.org -// -// Placed in the public domain -// +/* + Guess a number -extern OutStd + Date : 1999/04/22 -function Main() + My first application (big word) written in Harbour + Written by Eddie Runia + www - http://www.harbour-project.org + + Placed in the public domain +*/ + +EXTERN OutStd + +PROCEDURE Main() + local flGuessed local CRLF := chr(13)+chr(10) local nSeed := 241 @@ -50,11 +50,8 @@ enddo enddo -return nil + RETURN -function Read( cPrompt )// Simple read function. - -return __Accept( cPrompt ) - - +FUNCTION Read( cPrompt )/* Simple read function */ + RETURN __Accept( cPrompt ) This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. - -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
There is option in sf.net to add multiple hooks, so there could be one hook with and another without the diffs. I personally wouldn't make it that complicated, as the main point of this list is development, so diffs shouldn't be something unorthodox or inappropriate here, at least IMO. Brgds, Viktor On Fri, Jan 16, 2009 at 4:38 PM, Mindaugas Kavaliauskas wrote: > The other question is that, AFAIR and for description I have read, >> svnnotify will send every commit made to any file on SVN and not only to >> changelog file, as implemented on sf.net, and this I don't like. >> > > Hi, > > > From: [vszakats users sourceforge net] >> Date: Fri, Jan 16, 2009 at 12:26 PM >> Subject: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog >> To: ***...@** >> >> >> Revision: 10057 >> >> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10057&view=rev >> Author: vszakats >> Date: 2009-01-16 11:26:53 + (Fri, 16 Jan 2009) >> >> Log Message: >> --- >> testing hook >> > > Log message is HERE , at the begining of email, so you don't have to > look all content of email. Sometimes, I use to see changes of other > developers, so diff output is usefull. Perhaps, the only bad reason could be > diff for harbour.yyc file. It is long and has no info about the change. > > Why do you want to avoid getting diff for every file? Limited mailbox size, > or...? > > > Best regards, > Mindaugas > > ___ > 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] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
> > Mmmm... Yes, perhaps. I'm nor shure if mailling list has possibility to > allow *...@sourceforge.net users. Otherwise every "sourceforge.net developer" > one by one should be added to list. > This can have also have some side effects, if someone uses redirection from > @sourceforge.net account, it will get two copies of message, because both > emails will be subscribed. True. One-by-one needs manual administration and possibility for mistake. Maybe committers could resubscribe using sf.net addresses, but that again would mean the commit posts would not be guaranteed to be complete. > If we can subscribe some: svncom...@harbour-project.org to mailing list, > and put .forward from svncom...@harbour-project.org to > harbour@harbour-project.org it could be a solution. We should also solve: > 1) "From:" changing on forward. > 2) Do not forward mails from harbour@harbour-project.org back to > harbour@harbour-project.org, to avoid loop. Yes, that looks like it. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
Well, we have option for both. It diff is problematic, we can easily have notifications without it. With diff, we also need to deal with maximum message sizes, which is 40K. Diff files can often be larger than that. We can raise the limit (maybe only for the forwarder mailbox), or omit the diffs. Or have a separate "full diff commit notification" list (in addition to the normal short commit notifications). Brgds, Viktor On Fri, Jan 16, 2009 at 4:57 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi, > > Il 16/01/2009 16.38, Mindaugas Kavaliauskas ha scritto: > >> >>> Log Message: >>> --- >>> testing hook >>> >> >> Log message is HERE , at the begining of email, so you don't have to >> look all content of email. Sometimes, I use to see changes of other >> developers, so diff output is usefull. Perhaps, the only bad reason could be >> diff for harbour.yyc file. It is long and has no info about the change. >> >> > ok, I missed it. > > Why do you want to avoid getting diff for every file? Limited mailbox >> size, or...? >> >> > Simply that I see on other lists that some people, because it is available > diff for every files, limit or avoid to write in changelog and in log > message. > But I'm sure we will continue to be diligent ;-) > > Ok, lets go on with test. > > Best regards > > Francesco > > ___ > 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] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
Hi Phil, > >> Yes, that looks like it. >> > I can build mailboxes on the domain and I can forward them. I can join > harbour@harbour-project.org with the nomail option set. > > Does that sound like it will work? nomail means don't send any list mail. Sounds okay, let's try it with svncom...@harbour-project.org I'm setting up a notification for this address. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
Phil, could you please also raise the message size limit to 150K? sf.net has a '--max-diff-length 10' option set, so 150K is enough, and it's also acceptable as a generic limit for all subscribers. (we're at 40K right now AFAIK). Brgds, Viktor On Sat, Jan 17, 2009 at 11:50 AM, Viktor Szakáts wrote: > Hi Phil, > >> >>> Yes, that looks like it. >>> >> I can build mailboxes on the domain and I can forward them. I can join >> harbour@harbour-project.org with the nomail option set. >> >> Does that sound like it will work? nomail means don't send any list mail. > > > Sounds okay, let's try it with svncom...@harbour-project.org > > I'm setting up a notification for this address. > > Brgds, > Viktor > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour SHA2 and SHA2-HMAC support
Hi all, Pls see a Harbour library which implements SHA2 related checksumming and SHA2 MAC creation, here: http://www.syenar.hu/harbour/hbsha2.zip Usage from .prg: HB_SHA224( ) -> HB_SHA256( ) -> HB_SHA384( ) -> HB_SHA512( ) -> HB_SHA224_HMAC( , ) -> HB_SHA256_HMAC( , ) -> HB_SHA384_HMAC( , ) -> HB_SHA512_HMAC( , ) -> This is a thin wrapper around this code: http://www.ouah.org/ogay/sha2/ http://www.ouah.org/ogay/hmac/ Above code has BSD license, the same as used in PCRE, so I assume it's also safe to include it in Harbour. You can unzip the attached code in the contrib dir, and build it just like any other contribs. If there are no objections and I've received feedback, I plan to add these functions to the core. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour SHA2 and SHA2-HMAC support
Hi Francesco, > A question: anyone has played with SSL support ? I'm interested about it > because I'm playing with Mindaugas uhttpd code (I've extended it a little). > Maybe we should upload it, and continue to extend the code online, it's a very important addition, and everyone could benefit from it. It could go to /contrib/examples/<...>/ as is. I've played with OpenSSL in context with hbcurl. Once getting through the burden of building it (or using the .dll version), it seemed pretty simple to add SSL support for example for SMTP. To use it with Harbour apps, either an OpenSSL API Harbour wrapper layer would be needed, or a C level Harbour inet API. At least that's how it seemed to me. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour SHA2 and SHA2-HMAC support
Hi Mindaugas, Many thanks for the feedback. 1) it would be nice to have C also interface and to have names compatible to > existing MD5 hasing; The C interface is there, a Harbour C namespace (and MD5 function) compatible layer can easily be added. > 2) SHA1 is also member of the family and often used (SHA224 is seldom); As far as I could see there is no big overhead in having all four versions bundled together. I guess 256 and 512 are the most often used versions, so if group thinks we can easily remove the rest. I didn't deal with SHA1 because it isn't considered safe anymore (just like MD5). It can easily be added, given we find an implementation with a Harbour compatible licence. Here's one: http://www.aarongifford.com/computers/hmac_sha1.tar.gz (HMAC support is BSD, the rest is PD) Personally, I'd also welcome AES in Harbour. > 3) HMAC calculation is algorithm independent from hasing. Maybe we can have > universal HB_HMAC() instead of HB_*_HMAC(), > I guess code is: > FUNC HB_HMAC(fHash, cMessage, cKey) > IF LEN(cKey) > 64; cKey := HB_HexToStr(EVAL(fHash, cKey)) > ENDIF > cKey := PADR(cKey, 64, CHR(0)) > RETURN EVAL(fHash, HB_STRXOR(cKey, 0x5C) + ; > EVAL(fHash, HB_STRXOR(cKey, 0x36) + cMessage)) Good idea, but I'm personally lost with the details here :) Maybe I should change the names to HB_HMAC_SHA*() from HB_SHA*_HMAC() as a small step, should I? > 4) If there are some licence problem, we can find public domain > implementations. I guess rfc or standarts implementation is also free by > some mean; A public domain one would be great, but couldn't find any. > 5) I'm starting to think about some generic HB_CRYPT*() library. I should > stop think :) Just go ahead :) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour SHA2 and SHA2-HMAC support
Hi Mindaugas,
> I didn't deal with SHA1 because it isn't considered safe anymore (just like
>> MD5). It can easily be added, given we find an implementation with a Harbour
>> compatible licence.
>>
>
> MD5 and SHA1 is still used in many standards. You can use stronger hashing
> in your application, but you'll need these for compatibility, ex. CRAM-MD5
> (using MD5 HMAC) is used in IMAP, see:
> http://www.isi.edu/in-notes/rfc2195.txt
Yes, I know. Well, let's rename the lib to hbcrypt, so all such can be
included, I've also added an SHA-1 implementation, but no Harbour
layer and tests. I'll leave that for the group.
>3) HMAC calculation is algorithm independent from hasing. Maybe we
>>can have universal HB_HMAC() instead of HB_*_HMAC(),
>>I guess code is:
>>FUNC HB_HMAC(fHash, cMessage, cKey)
>> IF LEN(cKey) > 64; cKey := HB_HexToStr(EVAL(fHash, cKey))
>> ENDIF
>> cKey := PADR(cKey, 64, CHR(0))
>>RETURN EVAL(fHash, HB_STRXOR(cKey, 0x5C) + ;
>> EVAL(fHash, HB_STRXOR(cKey, 0x36) + cMessage))
>>
>>
>> Good idea, but I'm personally lost with the details here :)
>>
>
> The proposed above HB_HMAC() is full implementation of HMAC. Just see:
> http://en.wikipedia.org/wiki/HMAC It is independent from hashing
> algorithm. It can calculate any HMAC:
> cSHA256HMAC := HB_HMAC(@HB_SHA256, cMessage, cKey)
> cMD5HMAC := HB_HMAC(@HB_MD5, cMessage, cKey)
> etc.
Great, I'll test this and replace current HMAC implementation with this,
thanks!
We will need an HB_STRXOR(). Does this seem okay (UCHAR vs. BYTE might be
wrong here):
---
#include "hbapi.h"
HB_FUNC( HB_STRXOR )
{
ULONG nStrSize = hb_parclen( 1 );
UCHAR * pbyDest = ( UCHAR * ) hb_xgrab( nStrSize + 1 );
const UCHAR * pbySource = ( UCHAR * ) hb_parcx( 1 );
const UCHAR * pbyXor = ( UCHAR * ) hb_parcx( 2 );
ULONG nXorSize = hb_parclen( 2 );
ULONG nRetValPos = 0;
ULONG nStrPos = 0;
ULONG nXorPos = 0;
while( nStrPos < nStrSize )
{
pbyDest[ nRetValPos++ ] = pbySource[ nStrPos++ ] ^ ( nXorSize ?
pbyXor[ nXorPos++ ] : 0 );
if( nXorPos == nXorSize )
nXorPos = 0;
}
hb_retclen_buffer( ( char * ) pbyDest, nStrSize );
}
---
> A public domain one would be great, but couldn't find any.
>>
>
> http://www.cryptopp.com/ source are public domain, but it's C++. I also
> think it is not difficult to implement using algorithm description.
Nice page. On first round these BSD sources will do, just
to have something to tackle (and use), later, the group can
rewrite and/or replace them with better licensed ones.
> Just go ahead :)
>>
>
> You've mentioned AES. Here I think we will need also some hb_crypt*()
> functions to separate block cipher mode (ECB, CBC, PCBC, CFB, OFB) from
> cipher itself (AES, DES, Blowfish, etc), just like I suggest to separate
> HMAC algorithm from hashing algorithm.
Definitely sounds very interesting (and also beyond my capabilities :).
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour SHA2 and SHA2-HMAC support
uhttpd seems good to me. Brgds, Viktor On Mon, Jan 19, 2009 at 2:31 AM, Mindaugas Kavaliauskas wrote: > Francesco Saverio Giudice wrote: > >> Ok, I'll do, if Mindaugas agree. Do you have a name proposal ? >> I think we can name it webserver (what fantasy ;-) ). >> One version I have is based on Mindaugas version with socket.c and it is >> fast and stable. Another is based on inet*() version, that offers actually >> multiplatform support and extensions, but it has some problems. >> So if it is ok I will upload first version. >> Both have one problem at end of application if using HRBs modules >> (Unrecoverable 9001 error) but only on exit and I have not found the cause, >> otherwise they works. >> > > Feel free to do anything with proposed uhttpd (also commit). I just have > some ideas how to extend it, but I'm not sure if these ideas will be similar > to SVN changes by other people. It can happen, that after some time I will > propose something completely different and incompatible from SVN. > > I do not remember if I've mentioned the initial idea of name "uhttpd". Here > "u" stands for "micro", since the first version was a tiny 300 prg lines > http server. > > > Best regards, > Mindaugas > > > ___ > 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] Harbour SHA2 and SHA2-HMAC support
Thanks Mindaugas.
For some reason I still cannot make pass your generic .prg HMAC function
on the validation tests. Probably some stupid mistakes on my part.
Brgds,
Viktor
On Mon, Jan 19, 2009 at 4:52 PM, Mindaugas Kavaliauskas
wrote:
> Hi,
>
>
> We will need an HB_STRXOR(). Does this seem okay (UCHAR vs. BYTE might be
>> wrong here):
>>
>
> Oh, yes, I forgot it's my function, not Harbour's. I use code:
>
> HB_FUNC( HB_STRXOR )
> {
> PHB_ITEMpItem, pItem2;
> ULONG ulLen1, ulLen2, ul, ul2;
> const char *pStr1, *pStr2;
> char* pRet;
>
> pItem = hb_param( 1, HB_IT_STRING );
> if( pItem )
> {
> pStr1 = hb_itemGetCPtr( pItem );
> ulLen1 = hb_itemGetCLen( pItem );
>
> if( ( pItem2 = hb_param( 2, HB_IT_STRING ) ) != NULL )
> {
> ulLen2 = hb_itemGetCLen( pItem2 );
> if( ulLen2 )
> {
>pStr2 = hb_itemGetCPtr( pItem2 );
>
>pRet = ( char* ) hb_xgrab( ulLen1 + 1 );
>memcpy( pRet, pStr1, ulLen1 + 1 );
>ul2 = 0;
>for( ul = 0; ul < ulLen1; ul++ )
>{
> pRet[ ul ] ^= pStr2[ ul2 ];
> if( ++ul2 == ulLen2 )
> ul2 = 0;
>}
>hb_retclen_buffer( pRet, ulLen1 );
> }
> else
>hb_itemReturn( pItem );
>
> return;
> }
> else if( ( pItem2 = hb_param( 2, HB_IT_NUMERIC ) ) != NULL )
> {
> char bChar = ( char ) hb_itemGetNI( pItem2 );
>
> if( bChar )
> {
>pRet = ( char* ) hb_xgrab( ulLen1 + 1 );
>memcpy( pRet, pStr1, ulLen1 + 1 );
>for( ul = 0; ul < ulLen1; ul++ )
> pRet[ ul ] ^= bChar;
>
>hb_retclen_buffer( pRet, ulLen1 );
> }
> else
>hb_itemReturn( pItem );
>
> return;
> }
> }
> hb_errRT_BASE_SubstR( EG_ARG, 3012, NULL, HB_ERR_FUNCNAME,
> HB_ERR_ARGS_BASEPARAMS );
> }
>
>
> It has syntax:
> HB_STRXOR( cString, cKey ) --> cXoredString
> or
> HB_STRXOR( cString, nByte ) --> cXoredString
>
> Some parameter error detection is done (I'm not sure that error subcode we
> should use, so, I've used 3012, just like in HB_STRTOHEX()). String is not
> reallocated if xor'ing to empty string or zero byte. Feel free to commit
> this code.
>
>
> Best regards,
>
> Mindaugas
>
> ___
> 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] MT questions
+1 for handling them separately. (reasons: more coherent/expected
behaviour, quicker and more compact code, since inline initialization can
be used without
concerns. It's a light reasoning after doing a quick scan on my source and
spotting
quite some places where current behaviour is a potential problem.)
Brgds,
VIktor
On Mon, Jan 19, 2009 at 7:58 PM, Przemyslaw Czerpak wrote:
> On Mon, 19 Jan 2009, Lorenzo Fiorini wrote:
>
> Hi Lorenzo,
>
> > For example I have a static array that keeps the menu prompts. At the
> > start the menus are correct since every "module" has its own own
> > prompts but if I choose an entry in one app I get that entry disabled
> > in another app or not disabled at all.
> > If I launch the same app with a parameter that start only one thread
> > at time it works as expected.
> > Surely I'm missing sth or I am misunderstood how the "thread static"
> works.
> > Any suggestion?
>
> Probably you are asking about the same thing as Pritpal was few weeks
> ago. Should we clone or simply copy thread static initial value.
> Now it's copied so the behavior is the same as for:
>
> proc main()
> local a:={}
> ? len(a)
> p(a)
> ? len(a)
> return
> proc p(x)
> aadd(x,0)
> return
>
> Please note that p() changes the body of 'a' because 'a' and 'x'
> local variables shares the same array body.
> The same happens now for thread static variables initial value.
> Each thread has its own thread static variable but they share
> initialization data when it's complex item (hash or array) so
> when you modify them in one thread in other modifications are
> visible. If you want to eliminate this behavior you should
> initialize the variable from source code, f.e.:
> if s_var == NIL
> s_var := {}
> endif
> anyhow it's still open the question about Harbour default behavior.
> I can change it and instead of copping initialization data to thread
> static variable I can clone it. In other words the original initialization
> value will be always kept in hidden HVM structures and cloned when each
> thread access it 1-st time. Such modification will effect only hashes
> and array values. All other types will be unchanged.
> Seems that you are the second person confused by current behavior and
> probably not the last one and this is important argument for me to
> think about changing it.
> What's the group opinion about it?
>
> 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] Harbour SHA2 and SHA2-HMAC support
hmmm, really strange. In this case I won't add any SHA2 functions to core in
this fashion. Rather I'll keep it in hbcrypt() in binary form.
Or, if group agrees, we break with the HB_MD5 "habit" and these
new ones will use binary data by default.
Am I living a different world, or is it true, that in the majority of cases
checksums are meant to be printed for _users_? I would think these
cryptic numbers are most of the time embedded in some streams,
and a machine is dealing with them. Except when it's travelling in
a text file (.xml, .ini, and oh well .sfv).
To me the latter seems by far the rarest, but again I may be wrong.
But even if so, it's just a function call to convert vice and versa.
Anyhow it'd be nice the know what led to the current MD5
implementation.
Brgds.
Viktor
On Mon, Jan 19, 2009 at 10:23 PM, Mindaugas Kavaliauskas wrote:
> Hi,
>
> In many cases (ex., communication protocol implementation) we need binary
>>> digest result, and hex format is used for human readable representation
>>> only.
>>>
>>
>> You are right. I'll add support for such parameter.
>> Maybe we should even return binary data by default.
>> What's group decision?
>>
>
> No, let's leave it default to hex format. Hackers will be clever enough to
> add .T., the other, ex., who just want to print md5 sum of a file, will be
> glad to do:
> ? hb_md5file("myfile.ext")
>
> Leaving lBinary = .F. for default will also make this change backward
> compatible.
>
> For example PHP uses also this convention:
> string md5( string str [, bool raw_output] )
> raw_output is false by default.
>
>
> Regards,
> Mindaugas
>
>
> ___
> 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] Harbour SHA2 and SHA2-HMAC support
I wasn't aware that HB_MD5 is returning a hexa string.
In my personaly opinion, but it's probably too late to modify
that, such functions should return a binary stream of bytes,
and if user wants, it can be easily converted to hex using
hb_strtohex(). This way it's properly modular and there's
no redundancy.
So instead of having an 'lbinary' option, I think this should
always return binary and no option is necessary.
At least I've been following that road with HB_SHA* functions.
Brgds,
Viktor
On Mon, Jan 19, 2009 at 10:17 PM, Przemyslaw Czerpak wrote:
> On Mon, 19 Jan 2009, Mindaugas Kavaliauskas wrote:
>
> Hi,
>
> > P.S. sometimes one more optional parameter would be really usefull
> > HB_{MD5|SHA1|...}( cMessage [, lBinary ] ), to avoid two unnecessary
> > Bin->Hex->Bin conversion in function like HB_HMAC:
> > FUNC HB_HMAC(fHash, cMessage, cKey, lBinary)
> > IF LEN(cKey) > 64; cKey := EVAL(fHash, cKey, .T.)
> > ENDIF
> > cKey := PADR(cKey, 64, CHR(0))
> > RETURN EVAL(fHash, HB_STRXOR(cKey, 0x5C) + ;
> >EVAL(fHash, HB_STRXOR(cKey, 0x36) + cMessage, .T.),
> > lBinary)
> > In many cases (ex., communication protocol implementation) we need binary
> > digest result, and hex format is used for human readable representation
> > only.
>
> You are right. I'll add support for such parameter.
> Maybe we should even return binary data by default.
> What's group decision?
>
> 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] MT questions
I agree with you. So is it true, that I now _have to_ initialize everything with NIL explicitly, if I want them to be inited to a known value for all threads? I was specifically avoiding this so far, because the NIL assignment would just take some extra time one startup (not much, but keeping startup time low is important, and this is just an extra cost for each STATIC variable around the app). Brgds, Viktor On Mon, Jan 19, 2009 at 10:36 PM, Mindaugas Kavaliauskas wrote: > Hi, > > > Same for me. It seem more 'intuitive' for me that each thread really has >> it's own initial value, even when the value by itself is the same. >> > > I agree, and I prefer even more strict behaviour here. Thread statics > should be initialized to NIL on thread startup. Because it's static of THAT > PARTICULAR thread, and its' value is not related to value of parent thread > statics. This also makes to leave cloning decision for programmer: he can > clone, or do not clone, or create new objects, typed pointers, since cloning > for them usually means nothing. > > I see Przemek is already committed the change. We can leave it. The above > opinion is more "theoretical", because I have we very few MT programming > skills and I do not have a strong feeling on that should be default in cases > like this. > > > Regards, > Mindaugas > > ___ > 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] Harbour SHA2 and SHA2-HMAC support
Well, Python ranks much higher on my language respect list than PHP, so +1
:)
Brgds,
Viktor
On Mon, Jan 19, 2009 at 10:42 PM, Mindaugas Kavaliauskas wrote:
> Viktor Szakáts wrote:
>
>> hmmm, really strange. In this case I won't add any SHA2 functions to core
>> in this fashion. Rather I'll keep it in hbcrypt() in binary form.
>> Or, if group agrees, we break with the HB_MD5 "habit" and these new ones
>> will use binary data by default.
>>
>> Am I living a different world, or is it true, that in the majority of
>> cases checksums are meant to be printed for _users_? I would think these
>> cryptic numbers are most of the time embedded in some streams, and a machine
>> is dealing with them. Except when it's travelling in a text file (.xml,
>> .ini, and oh well .sfv).
>>
>> To me the latter seems by far the rarest, but again I may be wrong. But
>> even if so, it's just a function call to convert vice and versa.
>>
>> Anyhow it'd be nice the know what led to the current MD5 implementation.
>>
>
>
> Hi,
>
>
> no problem for me. We can change it to binary (with or without lBinary)
> parameter. I can accept any implementation here, but we should use the same
> approach for all digest functions.
>
>
> Best regards,
> Mindaugas
>
>
> P.S. I can always find an argument :) Python returns binary string:
> md5.new("Nobody inspects the spammish repetition").digest()
>
>
> ___
> 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] Error in SVN automatic mail
Hi Francesco, Yes, the notification is already set up, but the mailbox is not yet existing. We should wait for Phil to set it up, so that we can test the redirection + notification. Until this matter gets settled, commiters pls ignore this error message. Brgds, Viktor On Mon, Jan 19, 2009 at 11:52 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi All, > > I'm receiving this mail from sf.net: > What I have to do ? > > Best regards, > > Francesco > > Hi. This is the qmail-send program at fiberhosting.net. > I'm afraid I wasn't able to deliver your message to the following > addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > : > This address no longer accepts mail. > > --- Below this line is a copy of the message. > > Return-Path: > Received: (qmail 14847 invoked from network); 19 Jan 2009 17:40:10 -0500 > Received-SPF: none (no valid SPF record) > Received: from ch3.sourceforge.net (HELO d5vjzd1.ch3.sourceforge.com) > (216.34.181.60) > by harbour-project.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Jan > 2009 17:40:09 -0500 > Received: from apache by d5vjzd1.ch3.sourceforge.com with local (Exim > 4.69) >(envelope-from ) > > [snip] > ___ > 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] Harbour SHA2 and SHA2-HMAC support
Hi Mindaugas,
Now it's better, but in order to make them give the right results with
SHA384 and SHA512, 64 has to be changed to 128. I'm
lost how to do this in a generic way.
Brgds,
Viktor
On Mon, Jan 19, 2009 at 10:03 PM, Mindaugas Kavaliauskas wrote:
> Hi,
>
>
> For some reason I still cannot make pass your generic .prg HMAC function
>> on the validation tests. Probably some stupid mistakes on my part.
>>
>
> No, on my one. I forgot one Hex->Bin conversion. It should be:
>
> FUNC HB_HMAC(fHash, cMessage, cKey)
> IF LEN(cKey) > 64; cKey := HB_HexToStr(EVAL(fHash, cKey))
> ENDIF
> cKey := PADR(cKey, 64, CHR(0))
> RETURN EVAL(fHash, HB_STRXOR(cKey, 0x5C) + ;
> HB_HexToStr(EVAL(fHash, HB_STRXOR(cKey, 0x36) +
> cMessage)))
>
> Now
> ? HB_HMAC(@HB_MD5(), "<1896.697170...@postoffice.reston.mci.net>",
> "tanstaaftanstaaf")
> prints "b913a602c7eda7a495b4e6e7334d3890" (this test data is used in
> http://www.isi.edu/in-notes/rfc2195.txt).
>
>
> Regards,
> Mindaugas
>
>
> P.S. sometimes one more optional parameter would be really usefull
> HB_{MD5|SHA1|...}( cMessage [, lBinary ] ), to avoid two unnecessary
> Bin->Hex->Bin conversion in function like HB_HMAC:
>
> FUNC HB_HMAC(fHash, cMessage, cKey, lBinary)
> IF LEN(cKey) > 64; cKey := EVAL(fHash, cKey, .T.)
> ENDIF
> cKey := PADR(cKey, 64, CHR(0))
> RETURN EVAL(fHash, HB_STRXOR(cKey, 0x5C) + ;
> EVAL(fHash, HB_STRXOR(cKey, 0x36) + cMessage, .T.),
> lBinary)
>
> In many cases (ex., communication protocol implementation) we need binary
> digest result, and hex format is used for human readable representation
> only.
>
> ___
> 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] Re: MT question #2
Hi Lorenzo, Did you try hb_FTempCreate()? hb_FTempCreate( cDir, cPrefix, FC_NORMAL, @cFileName ) ) -> fhnd Brgds, Viktor On Tue, Jan 20, 2009 at 12:48 PM, Lorenzo Fiorini wrote: > On Tue, Jan 20, 2009 at 12:39 PM, Przemyslaw Czerpak > wrote: > > > Harbour recognize that the same file is reopen using it's inode not > > name so even if you create hard or soft links to given file then > > it will be detected that the same file is open and existing open handle > > reused in new workarea. > > Many thanks, now it's clear. > > I'm getting some errors with temporary files used to sort or index ( > though in a stress test ). > What's the best way to get a unique temporay file in the same dir that > work in *nix, osx and win that work in a mt app? > > 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] 2009-01-20 17:29 UTC+0100 Viktor Szakats
2009-01-20 17:29 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbhpdf/harupdf.c ! HPDF_SETINFODATEATTR() fixed taking date/time from the wrong parameter. ! HPDF_SETINFODATEATTR() fixed to initialize the date structure passed to libharu. ; NOTE: I've changed my editor config to automatically clean line ending spaces. This may cause larger diffs even for small modifications until all these spaces are cleaned from the sources. FYI. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2009-01-20 20:47 UTC+0100 Viktor Szakats
2009-01-20 20:47 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/make_b32_all.bat * contrib/make_gcc_all.sh * contrib/make_vc_all.bat * contrib/Makefile + contrib/hbcrypt + contrib/hbcrypt/Makefile + contrib/hbcrypt/make_b32.bat + contrib/hbcrypt/make_vc.bat + contrib/hbcrypt/make_gcc.sh + contrib/hbcrypt/common.mak + contrib/hbcrypt/hbsha2.c + contrib/hbcrypt/hbsha2hm.c + contrib/hbcrypt/sha1.h + contrib/hbcrypt/sha1.c + contrib/hbcrypt/sha2.h + contrib/hbcrypt/sha2.c + contrib/hbcrypt/sha1hmac.h + contrib/hbcrypt/sha1hmac.c + contrib/hbcrypt/sha2hmac.h + contrib/hbcrypt/sha2hmac.c + contrib/hbcrypt/tests + contrib/hbcrypt/tests/testsha2.prg + contrib/hbcrypt/tests/hbmk_b32.bat + contrib/hbcrypt/tests/hbmk_vc.bat + Added hbcrypt library. Included .prg level functions: - HB_SHA224( ) -> - HB_SHA256( ) -> - HB_SHA384( ) -> - HB_SHA512( ) -> - HB_HMAC_SHA224( , ) -> - HB_HMAC_SHA256( , ) -> - HB_HMAC_SHA384( , ) -> - HB_HMAC_SHA512( , ) -> ; TODO: Add C level wrappers in Harbour namespace. ; TODO: Add .prg level wrappers for SHA1 functions + tests. ; TODO: Convert HB_MD5() work on binary data, rather than doing hexadecimal conversion accessible using standard Harbour functions anyway. ; TODO: Add other crypt functions (AES, ...). ; NOTE: I plan to move these functions to core, after they've matured here. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-20 20:47 UTC+0100 Viktor Szakats
Hi Francesco, Thanks I've committed these fixes: 2009-01-20 23:04 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbcrypt/sha1.c ! Fixed some BCC warnings. 2009-01-20 23:00 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbcrypt/sha1.c ! Added #include for mem*(). 2009-01-20 22:51 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbcrypt/tests/testsha2.prg ! Fixed typo in some last minute (and untested) modifications. As for the BCC error, I'd like to ask BCC users to find out what could be the problem. GCC and MSVC build cleanly, and tests show all '.T.'. Brgds, Viktor On Tue, Jan 20, 2009 at 10:32 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Viktor, > > Il 20/01/2009 20.56, Viktor Szakáts ha scritto: > >> 2009-01-20 20:47 UTC+0100 Viktor Szakats (harbour.01 syenar hu) >> > > with BCC55 hbcrypt won't build > - > MAKE Version 5.2 Copyright (c) 1987, 2000 Borland >bcc32.exe -c -q -d -Q -w -w-sig- -4 -O2 -OS -Ov -Oi -Oc > -I..\..\include -DHB_FM_STATISTICS_OFF -oobj\b32\hbsha2.obj .\hbsha2.c > .\hbsha2.c: > Error E2176 .\sha2.h 55: Too many types in declaration > + Full parser context > + .\hbsha2.c, line 55: #include .\sha2.h > *** 1 errors in Compile *** > > ** error 1 ** deleting obj\b32\hbsha2.obj > - > > > with BCC582 builds but with follow errors. > - > MAKE Version 5.2 Copyright (c) 1987, 2000 Borland >bcc32.exe -c -q -d -Q -w -w-sig- -4 -O2 -OS -Ov -Oi -Oc > -I..\..\include -DHB_FM_STATISTICS_OFF -oobj\b32\hbsha2.obj .\hbsha2.c > .\hbsha2.c: >bcc32.exe -c -q -d -Q -w -w-sig- -4 -O2 -OS -Ov -Oi -Oc > -I..\..\include -DHB_FM_STATISTICS_OFF -oobj\b32\hbsha2hm.obj .\hbsha2hm.c > .\hbsha2hm.c: >bcc32.exe -c -q -d -Q -w -w-sig- -4 -O2 -OS -Ov -Oi -Oc > -I..\..\include -DHB_FM_STATISTICS_OFF -oobj\b32\sha1.obj .\sha1.c > .\sha1.c: > Warning W8004 .\sha1.c 99: 'a' is assigned a value that is never used in > function SHA1_Transform > Warning W8065 .\sha1.c 122: Call to function 'memcpy' with no prototype in > function SHA1_Update > Warning W8065 .\sha1.c 130: Call to function 'memcpy' with no prototype in > function SHA1_Update > Warning W8065 .\sha1.c 155: Call to function 'memset' with no prototype in > function SHA1_Final > Warning W8065 .\sha1.c 156: Call to function 'memset' with no prototype in > function SHA1_Final > Warning W8065 .\sha1.c 157: Call to function 'memset' with no prototype in > function SHA1_Final > Warning W8065 .\sha1.c 158: Call to function 'memset' with no prototype in > function SHA1_Final > Warning W8004 .\sha1.c 159: 'j' is assigned a value that is never used in > function SHA1_Final > Warning W8004 .\sha1.c 154: 'i' is assigned a value that is never used in > function SHA1_Final >bcc32.exe -c -q -d -Q -w -w-sig- -4 -O2 -OS -Ov -Oi -Oc > -I..\..\include -DHB_FM_STATISTICS_OFF -oobj\b32\sha1hmac.obj .\sha1hmac.c > .\sha1hmac.c: >bcc32.exe -c -q -d -Q -w -w-sig- -4 -O2 -OS -Ov -Oi -Oc > -I..\..\include -DHB_FM_STATISTICS_OFF -oobj\b32\sha2.obj .\sha2.c > .\sha2.c: >bcc32.exe -c -q -d -Q -w -w-sig- -4 -O2 -OS -Ov -Oi -Oc > -I..\..\include -DHB_FM_STATISTICS_OFF -oobj\b32\sha2hmac.obj .\sha2hmac.c > .\sha2hmac.c: >tlib.exe "..\..\lib\b32\hbcrypt.lib" /P64 @MAKE.@@@ > TLIB 4.5 Copyright (c) 1987, 1998 Borland International > +obj\b32\hbsha2.obj & > +obj\b32\hbsha2hm.obj & > +obj\b32\sha1.obj & > +obj\b32\sha1hmac.obj & > +obj\b32\sha2.obj & > +obj\b32\sha2hmac.obj & > + > - > > after built I have tried with testsha2.prg in tests folder (after have > corrected a typo error at line 138) I get all test returning .F. > > > Best regards > > Francesco > ___ > 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] 2009-01-20 20:47 UTC+0100 Viktor Szakats
Yes, it's done already. Brgds, Viktor On Tue, Jan 20, 2009 at 11:09 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Mindaugas, > > Il 20/01/2009 22.54, Mindaugas Kavaliauskas ha scritto: > >> after built I have tried with testsha2.prg in tests folder (after have >>> corrected a typo error at line 138) I get all test returning .F. >>> >> >> Just an untested hint. Line 138 uses HB_HexToStr(), but function name is >> StrToHex(). Maybe here is one more error...? >> >> Right! Got it > Changing it to: > STATIC FUNCTION StrToHex( cMem ) > RETURN Lower( hb_StrToHex( cMem ) ) > > made it working. Thank you. > Viktor could you kindly update it ? > > Best regards > > Francesco > > ___ > 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] proper tar utility for Windows
Hi folks, Anyone knows a tar utility for Windows, which works properly? (it's a plus if it doesn't depend on Cyg and similar dlls) I use this one: UNTGZ/32bit Decompression Utility 0.95 freeware version Copyright (c) 1996,97 Tillmann Steinbrecher. Feb 17 1997 But it consistently messes up f.e. OpenSSL tars, like this one: http://www.openssl.org/source/openssl-0.9.8j.tar.gz Any tips? Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] proper tar utility for Windows
Thanks Francesco. I'd prefer something CLI, the gnuwin32 one doesn't handle -z option, so files have to be manually ungzipped first. It also fails to create the \include\openssl dir content properly. These are links in the tar, and it creates .lnk files (untgz32 creates zero byte files). Both make the build process file. [ I've tried the msys one, but it doesn't do anything. ] Brgds, Viktor On Tue, Jan 20, 2009 at 11:51 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Viktor, > > Il 20/01/2009 23.30, Viktor Szakáts ha scritto: > > Hi folks, >> >> Anyone knows a tar utility for Windows, which works properly? >> (it's a plus if it doesn't depend on Cyg and similar dlls) >> >> I use this one: >> UNTGZ/32bit Decompression Utility 0.95 freeware version >> Copyright (c) 1996,97 Tillmann Steinbrecher. Feb 17 1997 >> >> But it consistently messes up f.e. OpenSSL tars, like this one: >> http://www.openssl.org/source/openssl-0.9.8j.tar.gz >> >> Any tips? >> > > I use Total Commander (www.ghisler.com) as GUI file manager that fully > manage tar files. > Otherwise, as command line tools, tar from gnuwin32 ( > http://gnuwin32.sourceforge.net/packages/gtar.htm) that has 2 dependencies > dll ( > http://garr.dl.sourceforge.net/sourceforge/gnuwin32/tar-1.13-1-dep.zip) > > HTH > > Best regards, > Francesco > ___ > 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] proper tar utility for Windows
Hi Lost, Thanks for your suggestion. It seems it also doesn't create those files, but I've just retried, and the whole issue seems to be worked around by the OpenSSL build process, so this specific problem is now solved. 7z is a good choice for this job as I use it anyway (but I have to keep in mind it's also good for tar :). BTW, it would be great to see 7z support in Harbour. [ The slight problem with this is that ANSI C 7z encoder doesn't exist yet, but they seem to be working on it. ] Brgds, Viktor On Wed, Jan 21, 2009 at 1:00 AM, Lost wrote: > Hi Viktor, > > El día 20/01/2009 Viktor Szakáts escribió: > > > I'd prefer something CLI, the gnuwin32 one doesn't handle -z option, > > so files have to be manually ungzipped first. It also fails to create > > the \include\openssl dir content properly. These are links in the tar, > > and it creates .lnk files (untgz32 creates zero byte files). Both make > > the build process file. > > [ I've tried the msys one, but it doesn't do anything. ] > > Brgds, > > Viktor > > > > Maybe it's not quite what you're looking for, but have you tried 7-zip? > http://www.7-zip.org/ > There is a command line version in the download page. > > (BTW, it's great to see you back around!) > > HTH, > Lost > ___ > 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] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
IMO this is a developer list so such mails are expected, if we split the lists into two, it will be complicated (and error prone) to simply reply to those commit e-mails (this is very useful and also common practice), which kind of defeats the purpose, as the manual ChangeLog e-mails would still have to be created to keep this list informed. For those who are bothered by these mails, it's very easy to filter them out BTW. (not so easy for digest readers, though). Or, another option is to redirect the diff-less (thus short) commit messages to this list and create a new one for the verbose commit mails containing full diffs. (maybe rather named 'svn-dif...@harbour-project.org', or similar) Any further opinions on this? Brgds, Viktor On Wed, Jan 21, 2009 at 6:05 AM, Phil Barnett wrote: > Mindaugas Kavaliauskas wrote: > >> Viktor Szakáts wrote: >> >>> Maybe some sort of forwarder e-mail address could do the job. >>> >> >> >> Mmmm... Yes, perhaps. I'm nor shure if mailling list has possibility to >> allow *...@sourceforge.net users. Otherwise every "sourceforge.netdeveloper" >> one by one should be added to list. >> This can have also have some side effects, if someone uses redirection >> from @sourceforge.net account, it will get two copies of message, because >> both emails will be subscribed. >> >> If we can subscribe some: svncom...@harbour-project.org to mailing list, >> and put .forward from svncom...@harbour-project.org to >> harbour@harbour-project.org it could be a solution. We should also solve: >> 1) "From:" changing on forward. >> 2) Do not forward mails from harbour@harbour-project.org back to >> harbour@harbour-project.org, to avoid loop. >> >> I think it would be better to create a mailing list for these svn mails > that anyone can subscribe to and it will be read only except for the SVN > mailer. That way, it will not inflate the developer list with messages that > a lot of people will never read. > > I'm suggesting a list named s...@harbour-project.org > > On that list, I can create the above accounts. > > Would that be better than having these go to the main list, or do you all > want them on the existing list? > > ___ > 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] proper tar utility for Windows
Yes, this is the case. It seems there is no solution for this problem, besides making these packages not to rely on the affected links when used on Windows. In OpenSSL this is handled by the perl Configure script. (I've just tried it on an OpenSSL .tgz unpacked on Windows). Brgds, Viktor On Wed, Jan 21, 2009 at 9:58 AM, Przemyslaw Czerpak wrote: > On Wed, 21 Jan 2009, Szak�ts Viktor wrote: > > Hi Viktor, > > > Thanks for your suggestion. It seems it also doesn't create > > those files, but I've just retried, and the whole issue seems > > to be worked around by the OpenSSL build process, so this > > specific problem is now solved. 7z is a good choice for > > this job as I use it anyway (but I have to keep in mind it's > > also good for tar :). > > Maybe I'm wrong but isn't the file creating problems for you > softlinks which does not exists in MS-Windows file systems > so they simply cannot be created on this architecture and > your results with different tar decompressors are only > workarounds for it? > > 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] 2009-01-21 16:42 UTC+0100 Lorenzo Fiorini
Hi Lorenzo, Could you add OpenDocument files? (.ods, .odt) These are very nice file formats and even easy to generate directly from an app. Brgds, Viktor On Wed, Jan 21, 2009 at 4:58 PM, Lorenzo Fiorini wrote: > 2009-01-21 16:42 UTC+0100 Lorenzo Fiorini (lorenzo.fiorini/at/gmail.com) > * contrib/hbpgsql/tests/simple.prg > * contrib/hbpgsql/tests/async.prg > * contrib/hbpgsql/tests/cache.prg > * contrib/hbpgsql/tests/stress.prg > * contrib/hbpgsql/tests/dbf2pg.prg >* general cleanup for Harbour > * fix of function and method names, removed hard wired uid and pwd > * contrib/hbtip/utils.c >* added new mime types like flash files, rtf, csv > > 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] THREAD STATIC var naming
Hi all, I'd like to propose to mark all THREAD STATIC vars with the 't_' prefix, instead of 's_' to make the difference obvious when looking at the code. So: THREAD STATIC t_var STATIC s_var Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] THREAD STATIC var naming
Vars names align better visually if all prefixes are of equal length (one char). It's also easier to swap automatically without manual reformatting. We have 'g_', 's_', 't_', so it's a not a really busy list of prefixes, I'd prefer not to make it any more verbose than necessary. Brgds, Viktor On Wed, Jan 21, 2009 at 5:49 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Viktor, > > Il 21/01/2009 17.18, Viktor Szakáts ha scritto: > > Hi all, >> >> I'd like to propose to mark all THREAD STATIC vars with the 't_' prefix, >> instead of 's_' to make the difference obvious when looking at the code. >> >> So: >> THREAD STATIC t_var >> STATIC s_var >> >> > why not ts_ ? > > Best regards > > Francesco > ___ > 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] 2009-01-21 16:42 UTC+0100 Lorenzo Fiorini
I've implemented native .ods output just recently. No .odt yet, for docs I'm going the .pdf way. (hbhpdf + libharu are very nice). Most time spent was to inspect what is absolute minimum content required for an .ods file. I can send you such "stripped" sample file. From this point it's pretty easy to generate, one .xml file, a few small helper files, and all that hbmzip-ped together. Brgds, Viktor On Wed, Jan 21, 2009 at 5:58 PM, Lorenzo Fiorini wrote: > On Wed, Jan 21, 2009 at 5:13 PM, Viktor Szakáts > wrote: > > > Could you add OpenDocument files? (.ods, .odt) > > These are very nice file formats and even easy to generate > > directly from an app. > > O course. I've simply synced the "compatible" part of my local repo. > > BTW have you tried to generate ods or an odt from Harbour? > I've done some tests but the ODF doc was huge so I never find enough > time to continue. > > 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] 2009-01-21 16:42 UTC+0100 Lorenzo Fiorini
Here's the file:http://www.syenar.hu/harbour/sample.ods Brgds, Viktor On Wed, Jan 21, 2009 at 7:24 PM, Lorenzo Fiorini wrote: > On Wed, Jan 21, 2009 at 7:15 PM, Viktor Szakáts > wrote: > > > I've implemented native .ods output just recently. > > No .odt yet, for docs I'm going the .pdf way. (hbhpdf > > + libharu are very nice). > > I'm using hbvpdf for pdfs but I also need "editable" documents so I use > RTFs. > > > Most time spent was to inspect what is absolute > > minimum content required for an .ods file. I can > > send you such "stripped" sample file. From this > > point it's pretty easy to generate, one .xml file, > > a few small helper files, and all that hbmzip-ped > > together. > > Many thanks. It could be the begin of an odf lib for Harbour. > > 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] 2009-01-21 21:46 UTC+0100 Viktor Szakats
2009-01-21 21:46 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbhpdf/harupdf.ch * contrib/hbhpdf/harupdf.c + Added HPDF_VERSION_TEXT() function which returns the libharu version hbhpdf was linked against. - Removed #define HPDF_VERSION_TEXT with hard-wired libharu version. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SVN $id issue
You have to use these command to set the file properties after 'svn add'-ing
them:
.bat/.cmd:
svn propset svn:keywords "Author Date Id Revision" %*
svn propset svn:eol-style CRLF %*
.sh:
svn propset svn:keywords "Author Date Id Revision" %*
svn propset svn:eol-style LF %*
svn propset svn:executable ON %*
other text files (.prg, .ch, .c, .h, .txt, ...):
svn propset svn:keywords "Author Date Id Revision" %*
svn propset svn:eol-style native %*
('%*' is the filenames, I've copied these out from my
svn adder batch files)
Brgds,
Viktor
On Thu, Jan 22, 2009 at 1:18 AM, Francesco Saverio Giudice <
i...@fsgiudice.com> wrote:
> Hi folks,
>
> I'm experience a problem with
> /*
> * $Id: rlcdx.prg 9754 2008-10-27 22:40:04Z vszakats $
> */
> macro: any file I update still maintains first macro version (above comes
> from uhttpd.prg).
> Is it a normal behavior ?
>
> Best regards,
>
> Francesco
> ___
> 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] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
> > IMO this is a developer list so such mails are expected, if we split the >> lists into two, it will be complicated (and error prone) to simply reply to >> those commit e-mails (this is very useful and also common practice), which >> kind of defeats the purpose, as the manual ChangeLog e-mails would still >> have to be created to keep this list informed. >> > I guess that I don't understand the reason you would reply to a read only > list, but I'm willing to listen . The point is to make ChangeLog e-mails automatic. Currently, the manual ChangeLog e-mails are being regularly replied to on this very list. I think we shouldn't lose this "feature", even after moving to automated ChangeLog (aka commit) mails. > How about this: > > 1. Create s...@harbour-project.org > 2. Set the reply-to on that list to this list. > 3. You build a filter in your email client to combine the two lists into > one mailbox. > I think that would satisfy everyone. Not very good. Since you _must_ subscribe to and monitor yet another list, even if you just want to be informed about the changes, just like before. What is the problem with my proposal? Let's make it even more simple: - Add s...@harbour-project.org to current list, - I'll setup the commit notifications, to be brief (no diffs). This basically replaces the current manual ChangeLog mails with similar brief content, same amount of mail, at tha same time it saves every committer to manually send mails, and no subscriber has to do anything for it to work. [ I've already subscribed myself to full-diff mails, so I personally don't care if the full-diffs appear here also. But I have to tell, it's extremely useful, and it saves me lots of minutes for every commit done to the Harbour SVN (even if it's mine). ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-22 10:15 UTC+0100 Lorenzo Fiorini
Hi Lorenzo, > 2009-01-22 10:15 UTC+0100 Lorenzo Fiorini (lorenzo.fiorini/at/gmail.com) > * bin/hb-func.sh >* fix darwin detection > * make_gnu.sh >* fix darwin detection I've once did that but it turned out to be unnecessary, as 'uname' always returns 'darwin' and never ' darwin', so the extra match is just superfluous. For bsd it's needed because 'netbsd' and 'openbsd' can be the name, for dos it can be 'dr-dos', 'ms-dos', 'pc-dos'. You get the idea. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
Hi Phil, > What is the problem with my proposal? >> > You are creating a feed to the mail system that there is no way to opt out > of, thus giving regular subscribers no way to reduce their mail burden. Sure > you can filter i away, but only after you have downloaded it. And it's going > to have a size limit of 150k. That's a lot of downloading just to throw it > away. Wrong. The commit mails without diffs are just as small as current ChangeLog e-mails. Same thing. No need to raise size limits. Same amount of mails. It _replaces_ current ChangeLog e-mails, so total number of received mails are _unchanged_. What I am proposing is an opt in system. You only have to join it once, it > lasts indefinitely. You create a filter to put it in the correct mailbox, > that lasts indefinitely. This is a very minor burden to give choice to > others before the mail download instead of after the mail download. > > Your method reduces choice and increases mail burden. People with modems do > care about this stuff. I believe in efficiency whenever I can get it. Choice > is good when it's not excessive and burdensome, which this is not. Subscribe > once, add one rule and you get exactly what you want. Sorry to say, but I think you've totally misunderstood me. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Mindaugas,
If the function is fully C compatible, HB_SPRINTF() is okay,
but if it's not I'd rather use HB_STRFORMAT() to avoid any
confusion. Since Harbour programming and needs are somewhat
different from C I would think we cannot (and it's rather pointless to)
go for full compatibility, so it'd be better to just say the Harbour
formatting syntax is _inspired by_ the C syntax, but it's a slightly
different thing (and may have additional/incompatible extensions in
the future). Such extension in the future might be to support
regular Harbour picture strings: '%1$s{"!"}' (syntax glue is just a
quick example).
BTW, we need to reserve hb_sprintf() C level function name for
a real printf() compatible C level implementation to eventually
remove dependency on C RTL printf() functions.
So my vote overall is hb_StrFormat() for C level and HB_STRFORMAT()
for .prg level function name.
Brgds,
Viktor
On Fri, Jan 23, 2009 at 6:28 PM, Mindaugas Kavaliauskas
wrote:
>
>
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Normal SVN commit mail
Revision: 10092 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10092&view=rev Author: fsgiudice Date: 2009-01-25 11:31:40 + (Sun, 25 Jan 2009) Log Message: --- 2009-01-25 12:30 UTC+0100 Francesco Saverio Giudice * harbour/contrib/examples/uhttpd/uhttpd.prg + Added hb_Inet*() version * harbour/contrib/examples/uhttpd/hbmk_b32.bat + Added support for hb_Inet*() version ; NOTE: To use hb_Inet*() version build using hbmk_b32.bat --with-inet Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/examples/uhttpd/hbmk_b32.bat trunk/harbour/contrib/examples/uhttpd/uhttpd.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SSLWrap
Hi Francesco, We'd rather need something native, but this and stunnel can be a solution until Harbour apps don't have proper SSL support. By 'wrapper' I meant a .prg level layer to access the OpenSSL API. The most basic subset is just a few calls, so maybe it's not as bad as one would first think: http://www.ibm.com/developerworks/linux/library/l-openssl.html http://www.openssl.org/docs/ssl/ssl.html Here are the details of the Python wrapper, with similar issue we would face in Harbour: http://pyopenssl.sourceforge.net/pyOpenSSL.txt Otherwise not much update here, I've recompiled everything this week to update OpenSSL, libssh and libcurl to the latest versions. (talking about Windows only, I have these components missing for Linux and Darwin yet). Update: I've quickly hammered up a skeleton of an OpenSSL Harbour layer. Find it here: http://www.syenar.hu/harbour/hbopnssl.zip [ Only some basic SSL_CTX calls are implemented yet. ] Brgds, Viktor On Sun, Jan 25, 2009 at 12:38 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Viktor, > I have found an interesting SSL Wrapper that I'm trying to convert to > harbour. > http://www.rickk.com/sslwrap > Do you have any updates on SSL support ? > I have seen on previous messages that you are playing with OpenSSL. > > Best regards > > Francesco > ___ > 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] 2009-01-25 22:16 UTC+0100 Viktor Szakats
2009-01-25 22:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/rtl/philes.c ! FWRITE(): Fixed accessing past the string buffer (thus causing potential GPF and a huge security hole) when the passed length is greater than the length of the string. Very old bug. In fact CA-Cl*pper suffers from the same problem, and behaviour for such case is not documented. Harbour will ignore the length parameter (thus writing the whole passed string), if the length is invalid. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2009-01-26 00:52 UTC+0100 Viktor Szakats
2009-01-26 00:52 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/Makefile * contrib/make_b32_all.bat * contrib/make_gcc_all.sh * contrib/make_vc_all.bat + contrib/hbssl + contrib/hbssl/Makefile + contrib/hbssl/common.mak + contrib/hbssl/make_b32.bat + contrib/hbssl/make_vc.bat + contrib/hbssl/make_gcc.sh + contrib/hbssl/hbssl.h + contrib/hbssl/hbssl.ch + contrib/hbssl/ssl.c + contrib/hbssl/sslctx.c + contrib/hbssl/sslrand.c + contrib/hbssl/tests + contrib/hbssl/tests/hbmk_b32.bat + contrib/hbssl/tests/hbmk_vc.bat + contrib/hbssl/tests/test.prg + Added Harbour bindings to OpenSSL. Work in progress, but it's theoretically already functional. To build, set your HB_DIR_OPENSSL or HB_INC_OPENSSL envvar. ; TOFIX: Makefile openssl autodetection should be adjusted. * contrib/examples/uhttpd ! Fixed SVN attributes. (except for /home dir) ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2009-01-26 10:19 UTC+0100 Viktor Szakats
2009-01-26 10:19 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbssl/common.mak * contrib/hbssl/Makefile * contrib/hbssl/hbssl.h + contrib/hbssl/sslsess.c + contrib/hbssl/sslciph.c * contrib/hbssl/ssl.c * contrib/hbssl/sslctx.c * contrib/hbssl/tests/test.prg + More SSL API added. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] ChangeLogs
2009-01-26 11:34 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbssl/sslctx.c * contrib/hbssl/ssl.c + Added more SSL API. * TODO * Updated. 2009-01-26 10:35 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbssl/tests/test.prg * contrib/hbssl/ssl.c + More SSL API added. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Missing dependences linking hbuddall.a
Well, since these hbmisc functions are very low quality components (bugs, non-MT/reentrant, no 64-bit support), I'd suggest to remove this udd from core and place it somewhere under hbmisc or examples. Or, of course if someone takes the effort to replace this dependency with a working one, it's even better. Brgds, Viktor On Mon, Jan 26, 2009 at 12:33 PM, Lorenzo Fiorini wrote: > Including hbuddall.a in the lib list I get: > > Lines 58, Functions/Procedures 1 > Generating C source output to 'tsturdd.c'... Done. > /opt/harbour/lib/libharbour.so: undefined reference to `HB_FUN_HB_FLASTREC' > /opt/harbour/lib/libharbour.so: undefined reference to `HB_FUN_HB_FSKIP' > /opt/harbour/lib/libharbour.so: undefined reference to `HB_FUN_HB_FGOTO' > /opt/harbour/lib/libharbour.so: undefined reference to `HB_FUN_HB_FRECNO' > /opt/harbour/lib/libharbour.so: undefined reference to `HB_FUN_HB_FGOTOP' > /opt/harbour/lib/libharbour.so: undefined reference to `HB_FUN_HB_FREADLN' > /opt/harbour/lib/libharbour.so: undefined reference to > `HB_FUN_HB_LOGRDDINHERIT' > /opt/harbour/lib/libharbour.so: undefined reference to > `HB_FUN_HB_FGOBOTTOM' > /opt/harbour/lib/libharbour.so: undefined reference to > `HB_FUN_HB_UNUSED_VAR' > /opt/harbour/lib/libharbour.so: undefined reference to `HB_FUN_HB_FUSE' > /opt/harbour/lib/libharbour.so: undefined reference to `HB_FUN_HB_FSELECT' > > HB_F* functions are in contrib/hbmisc, HB_LOGRDDINHERIT is defined in > exlog and I can't find HB_UNUSED_VAR. > > Suggestions to clean it? > > 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] 2009-01-26 16:47 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com)
Hi Francesco, May I suggest to remove the xhb lib dependency in these examples? Core by definition should never depend on a contrib, it's an important rule we should stick with. Brgds, Viktor On Mon, Jan 26, 2009 at 4:47 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > 2009-01-26 16:47 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com > ) > * harbour/source/rdd/usrrdd/rdds/arrayrdd.prg >* fixed harbour version without using hbcompat.ch > ; TODO: USRRDD not supports dbCreate() extension params > + harbour/source/rdd/usrrdd/example/exarr.prg >+ ARRAYRDD example > + harbour/source/rdd/usrrdd/example/hbmk_b32.bat >+ BCC make file > > > Best regards > > Francesco > ___ > 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] 2009-01-26 17:10 UTC+0100 Viktor Szakats
2009-01-26 17:10 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * common.mak * include/hbextern.ch * source/rtl/Makefile + source/rtl/strxor.c + Added HB_STRXOR() (work of Mindaugas Kavaliauskas) * common.mak * source/common/Makefile + source/common/hbprintf.c + Added hb_snprintf_c() (temp name, untested) (work of Przemyslaw Czerpak) [ I've added a normal Harbour license, as per your permission on the list. Pls give me feedback is this is wrong. ] * source/rdd/usrrdd/example/exlog.prg ! Fixed missing #includes. * source/rdd/usrrdd/example/hbmk_b32.bat + source/rdd/usrrdd/example/hbmk_vc.bat + Added MSVC make file. ! Added EOL to the last line to hbmk_b32.bat. ! xhb.lib dependency removed. It was not needed anyway. ; TOFIX: When compiling exhsx.prg, this happens: exhsx.obj : error LNK2001: unresolved external symbol _HB_FUN_HSXRDD * contrib/hbssl/sslsess.c * contrib/hbssl/sslctx.c * contrib/hbssl/sslciph.c * Minor changes. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-26 16:47 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com)
Hi Francesco, Yes, removing it didn't cause any problem. AFAIR the only dependence is hb_ToOutDebug() that I have commented out > (maybe is it the time to move it outside from xhb ;-) ? ) and used only for > tests. Hm, I personally still strongly dislike this set of functions. The naming, the scope, the API, portability, none of these are in sync with our general core direction. We need something ligher, simpler. If we don't want to use logging in speed critical areas, this simple function could IMO easily add logging into core. Maybe if we add a way to setup the filename, it would have some point to have it in core (and maybe rewritten in C). Also FO_EXCL could be used here. #include "fileio.ch" PROCEDURE LogMsg( cString ) LOCAL nHandle IF (nHandle := iif(hb_FileExists( cFileName ), FOpen( cFileName, FO_WRITE + FO_DENYWRITE),; FCreate( cFileName, FC_NORMAL ) ) ) != F_ERROR FSeek( nHandle, 0, FS_END) FWrite( nHandle, cEvent + hb_osNewLine() ) FClose( nHandle ) ENDIF RETURN Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-26 17:10 UTC+0100 Viktor Szakats
Yes, it doesn't compile under MSVC either, so unless there is someone to tweak it, I'll disable the code. Until then I've made a few patches, but it's not enough. [ I see Przemek jumped in, so I'll just disable it for the time being. ] Brgds, Viktor On Mon, Jan 26, 2009 at 8:51 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Viktor, > > Il 26/01/2009 17.12, Viktor Szakáts ha scritto: > >> + source/common/hbprintf.c >> + Added hb_snprintf_c() (temp name, untested) (work of Przemyslaw >> Czerpak) >> [ I've added a normal Harbour license, as per your permission >> on the list. Pls give me feedback is this is wrong. ] >> > > building with BCC I got this error: > >bcc32.exe -c -q -d -Q -w -w-sig- -tWM -4 -O2 -OS -Ov -Oi -Oc > -Iinclude -Iobj\b32 -DHB_FM_STATISTICS_OFF -oobj\b32\hbprintf.obj > source\common\hbprintf.c > source\common\hbprintf.c: > Error E2141 source\common\hbprintf.c 114: Declaration syntax error > Warning W8065 source\common\hbprintf.c 492: Call to function 'signbit' with > no prototype in function put_dbl > Warning W8065 source\common\hbprintf.c 676: Call to function 'strnlen' with > no prototype in function put_str > Error E2188 source\common\hbprintf.c 803: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 827: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 902: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 904: Expression syntax in function > hb_snprintf_c > Warning W8065 source\common\hbprintf.c 905: Call to function 'isnan' with > no prototype in function hb_snprintf_c > Warning W8065 source\common\hbprintf.c 911: Call to function 'isinf' with > no prototype in function hb_snprintf_c > Warning W8065 source\common\hbprintf.c 917: Call to function 'isinf' with > no prototype in function hb_snprintf_c > Error E2188 source\common\hbprintf.c 929: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 931: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 933: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 935: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 937: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 939: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 941: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 943: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 954: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 956: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 958: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 960: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 962: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 964: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 966: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 968: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 982: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 997: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 1009: Expression syntax in function > hb_snprintf_c > Error E2188 source\common\hbprintf.c 1020: Expression syntax in function > hb_snprintf_c > Error E2228 source\common\hbprintf.c 1020: Too many error or warning > messages in function hb_snprintf_c > *** 26 errors in Compile *** > > ** error 1 ** deleting obj\b32\hbprintf.obj > > Best regards > > Francesco > > ___ > 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] 2009-01-26 22:57 UTC+0100 Viktor Szakats
2009-01-26 22:57 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/rdd/usrrdd/example/exhsx.prg ! Removed HSXRDD references. It seems to work without them. * contrib/hbssl/ssl.c * Comment changes. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2009-01-26 23:32 UTC+0100 Viktor Szakats
2009-01-26 23:32 UTC+0100 Viktor Szakats (harbour.01 syenar hu) + contrib/examples/uhttpd/hbmk_vc.bat + Added MSVC make file. * contrib/examples/uhttpd/socket.c ! Made it compile with MSVC. ! Added SVN header. * contrib/examples/uhttpd/uhttpd.prg + contrib/examples/uhttpd/uhttpdc.c + C level stuff moved to separate file. ; NOTE: I'm getting an "Argument error: +" when browse to http://localhost:8082 (using Chrome if that matters). ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: 2009-01-26 23:32 UTC+0100 Viktor Szakats
Aha, it does work when built with --with-inet, great. Previously, without it, I've also got this: Application Memory Allocation Report - ...\harbour\contrib\examples\uhttpd\uhttpd.exe Terminated at: 2009.01.26 23:53:18 Total memory allocated: 281977 bytes (3813 block(s)) Warning, memory allocated but not released: 132 bytes (3 block(s)) Block 1 00CE51B8 (size 40) SOCKET_ACCEPT(0), "707C0D0170860D0180D2510001000F00802C0D014F4752455353" Block 2 010D7C70 (size 40) SOCKET_GETPEERNAME(0), "70860D01B851CE0080D251000100C8FFCE00588A0D0158D7B800084CCE00" Block 3 010D8670 (size 40) SOCKET_GETSOCKNAME(0), "B851CE00707C0D0180D251000100C8FFCE00F08B0D0158D7B800084CCE00" Brgds, Viktor On Mon, Jan 26, 2009 at 11:35 PM, Viktor Szakáts wrote: > 2009-01-26 23:32 UTC+0100 Viktor Szakats (harbour.01 syenar hu) >+ contrib/examples/uhttpd/hbmk_vc.bat > + Added MSVC make file. > >* contrib/examples/uhttpd/socket.c > ! Made it compile with MSVC. > ! Added SVN header. > >* contrib/examples/uhttpd/uhttpd.prg >+ contrib/examples/uhttpd/uhttpdc.c > + C level stuff moved to separate file. > >; NOTE: I'm getting an "Argument error: +" when browse >to http://localhost:8082 (using Chrome if that matters). > > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-26 15:07 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
Hi Pritpal, > 2009-01-26 15:07 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * harbour/contrib/gtwvg/gtwvg.c > * harbour/contrib/gtwvg/gtwvg.h >! Synchronized with GTWVT per Viktor's changes for box characters. >! Commented out previous change per Przemek's "Layered Attributes". This was originally my addition, but Przemek was nice to commit it on my behalf. Anyway, I think you should look for some more information regarding "layered window" mode, because one of it's points is to reduce flickering and unnecessary redraw requests. You ask Windows to manage the bitmap and you only need to update it when a real update occurs (but not, when the window is just moved around or gets focus). So this isn't a magic switch, and you may need to tweak the way WVG windows are updated to exploit it's possibilities in a good way. This link is good for a start, but probably not enough to finish: http://msdn.microsoft.com/en-us/library/ms997507.aspx [ Surprisingly Vista removed support for layered windows, so it may also happen that we should tweak this feature when running under Vista. I've already turned it off for TS mode, because of bad performance. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2009-01-27 00:21 UTC+0100 Viktor Szakats
2009-01-27 00:21 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/examples/uhttpd/uhttpd.prg + Added callstack in RTE message (ugly but useful). ! Fixed RTE when displaying server status. (might have broken non-inet-mode) * contrib/examples/uhttpd/hbmk_b32.bat * contrib/examples/uhttpd/hbmk_vc.bat + Trying to shutdown server before build. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: 2009-01-26 23:32 UTC+0100 Viktor Szakats
Many thanks, this fixes it. I'll commit ASAP. Brgds, Viktor On Tue, Jan 27, 2009 at 12:25 AM, Mindaugas Kavaliauskas wrote: > Viktor Szakáts wrote: > >> Aha, it does work when built with --with-inet, great. >> >> Previously, without it, I've also got this: >> >> Application Memory Allocation Report - >> ...\harbour\contrib\examples\uhttpd\uhttpd.exe >> Terminated at: 2009.01.26 23:53:18 >> Total memory allocated: 281977 bytes (3813 block(s)) >> Warning, memory allocated but not released: 132 bytes (3 block(s)) >> Block 1 00CE51B8 (size 40) SOCKET_ACCEPT(0), >> "707C0D0170860D0180D2510001000F00802C0D014F4752455353" >> Block 2 010D7C70 (size 40) SOCKET_GETPEERNAME(0), >> "70860D01B851CE0080D251000100C8FFCE00588A0D0158D7B800084CCE00" >> Block 3 010D8670 (size 40) SOCKET_GETSOCKNAME(0), >> "B851CE00707C0D0180D251000100C8FFCE00F08B0D0158D7B800084CCE00" >> >> > > Line: > hb_itemParamStoreForward( 2, hb_itemPutSockaddr( NULL, &saddr ) ); > should be replaced by: > PHB_ITEM pItem; > ... > pItem = hb_itemPutSockaddr( NULL, &saddr ); > hb_itemParamStoreForward( 2, pItem ); > hb_itemRelease( pItem ); > > > Best regards, > Mindaugas > ___ > 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] 2009-01-27 00:39 UTC+0100 Viktor Szakats
2009-01-27 00:39 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/examples/uhttpd/uhttpd.prg ! Fixed RTE when in socket.c mode. * contrib/examples/uhttpd/socket.c ! Fixed leak. Thanks to Mindaugas. ; TOFIX: Ajax test (404 Not Found), Counter (image not found), cgi-bin (broken link), XML database (empty boxes in Chrome, empty boxes and error messagebox with IE8) doesn't work here. Shall I configure something? ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-27 04:30 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, * eliminated non portable GCC only C syntax. >* updated to compile with other C compilers. Thanks! > TOFIX: harbour/contrib/hbssl/ssl.c[631], sslctx.c[268], sslctx.c[281] > error: invalid conversion from 'void*' to 'const char*' > I do not know if SSL_get_ex_data()/SSL_CTX_get_app_data() > returns valid ASCIIZ string so I cannot decide if simple casting > is safe and to pacify above errors. > Viktor, can you look at it? It can return just about anything user passes (including binary data). [ docs wrongly show these as 'char *'. ] I'll remove these functions for the time being, as this feature needs some extra logic to be usable from the Harbour level. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
Hi Phil, > I've offered to give you: > > 1. If you reply to these messages, the reply goes to the developer list. > 2. By adding one rule in your email system, you can have them delivered to > the same developer folder that you already have. > > How is that not exactly what you want? I mean, if it's such a big deal that > you would have to subscribe, I can do that for you. > > I think you have totally misunderstood me. I offered not only a way to get > what you wanted, but I also offered the flexibility to opt out of this > automated mail for anyone who doesn't want it. > > I think I understood you perfectly. You don't want to subscribe to another > list and combine it with the one you already have. I want people to have > that capability and I offered you a way to have it your way too with one > simple step on your end. > > This is not rocket science. For your idea to have a point, we will need _two_ separate mailing lists, commit@ and commit-diffs@ (let's not use 'svn', as we may change to other versioning in the future), so that everyone can decide _which_ kind of notification he wants to have (simple or full with diffs). Without this option, the extra list is plain pointless, as again, it's just to _replace_ current ChangeLog e-mails with automated ones with _similar content and volume_. Anyhow I feel this will lead to a mess, where some ppl don't get informed about changes, because not being subscribed to the other list, and because of this, some developers will continue to send manual ChangeLogs, creating double notifications for those who subscribed. Honestly, I don't like this at all. In fact, one of the points is to not give opt-out option. This is a developers' list, the change e-mails are the _backbone_ of this list, and _all members are receiving this information since the beginning_. Why would we suddenly need to change that? Again, our other, much simpler and consistent option is to simply swap the manual mails to automated ones, with no change on any parties side. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-27 04:30 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, * harbour/source/common/hbprintf.c >* eliminated non portable GCC only C syntax. >* updated to compile with other C compilers. > Now only GNUC with C99 support and BORLAND C gives all > +inf/-inf/NaN values for [long] double conversions. Does this seem like something useful for MSVC: http://www.koders.com/c/fid81D328FDCF6D1084BC3BE9B1A1E04F50140EAF45.aspx Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-27 04:30 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Two links that may be useful sometimes: stdint.h implemented for MSVC compilers: http://msinttypes.googlecode.com/svn/trunk/stdint.h Portable stdint.h implementation: http://www.azillionmonkeys.com/qed/pstdint.h Brgds, Viktor On Tue, Jan 27, 2009 at 4:30 AM, Przemyslaw Czerpak wrote: > 2009-01-27 04:30 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/include/hbdefs.h >* added some C compilers which supports stdint.h > > * harbour/source/common/hbprintf.c >* eliminated non portable GCC only C syntax. >* updated to compile with other C compilers. > Now only GNUC with C99 support and BORLAND C gives all > +inf/-inf/NaN values for [long] double conversions. > Other compilers uses NaN also for infinite numbers or nothing. > Please add full support for them. See TODO notes I left. > For compilers which supports C99 floating point macros should > be enough to enable the same macros used for GNUC && _ISOC99_SOURCE. > > * harbour/contrib/hbcrypt/sha2.h > * harbour/contrib/hbcrypt/sha2.c >! fixed BCC5.5 compilation > > TOFIX: harbour/contrib/hbssl/ssl.c[631], sslctx.c[268], sslctx.c[281] > error: invalid conversion from 'void*' to 'const char*' > I do not know if SSL_get_ex_data()/SSL_CTX_get_app_data() > returns valid ASCIIZ string so I cannot decide if simple casting > is safe and to pacify above errors. > Viktor, can you look at it? > > 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] 2009-01-27 00:39 UTC+0100 Viktor Szakats
Hi Francesco, > Shall I configure something? >> >> > yes, as I wrote in readme.txt you have to build hrb modules that you find > in modules folder. Use bldhrb.bat to build them (it also copies hrb result > file in ../home/cgi-bin), then you can run tests. > Build all 4 files you find. Did that and now everything works great, except this one: http://localhost:8082/info info.hrb is in the cgi-bin dir. I will update index.html to display this warning message. Thanks, this will be great. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-27 00:39 UTC+0100 Viktor Szakats
Many thanks Francesco, now it's perfect. What do you think of making uhttpd a library? This way it could easily be embedded in other apps. This would need some generalizations here and there, plus detaching the UI. This way it could become an hbhttpd.lib, launchable from any apps using one function call, and probably some hooks to get feedback on what's going on. Brgds, Viktor On Tue, Jan 27, 2009 at 10:17 AM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Viktor, > > Il 27/01/2009 9.59, Francesco Saverio Giudice ha scritto: > >> Did that and now everything works great, except this one: >>> http://localhost:8082/info >>> info.hrb is in the cgi-bin dir. >>> >> >> just seen. >> > > > should be ok after > 2009-01-27 10:14 UTC+0100 Francesco Saverio Giudice > > > Best regards > > Francesco > ___ > 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] 2009-01-27 00:39 UTC+0100 Viktor Szakats
Hi Francesco, > What do you think of making uhttpd a library? This way it could easily be >> embedded in other apps. >> This would need some generalizations here and there, plus detaching the >> UI. This way it could become an hbhttpd.lib, launchable from any apps using >> one function call, and probably some hooks to get feedback on what's going >> on. >> >> What I'm need now is to have a complete web server (with SSL support, > sessions support, database sharing helper functions, cache support (?), ...) > and multiplatform (removing actual embedded WIN_* API calls or better moving > them into harbour core making them multiplatform, like SETENV or > SYSREFRESH). > After, or in the middle, we can think to move all inside a single function > call and move it in a library so can be embedded, that is not so difficult > (I will try, but it has a lower priority than finish web server). > Another thing is to create a final version of cgi lib to use with web > server and integrate it to uhttpd (actually I have a mine minicgi.lib that > I'm using and with I have built testcgi.exe) as definitive version to use in > harbour (now there are 2 or 3 around). > Tell me if it is ok as path. Looks perfect to me. We should also tidy up the source from xhb.lib and hbcompat.ch dependent parts, but it's just a few places. Proper CGI lib would be nice, we have one in hbtip, how's that one? > Do you have tested also testcgi.exe as I wrote in Changelog ? Yes, and it's working fine, too. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-27 10:14 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com)
I think the .hrb modules aren't loaded on a per thread basis, so it's not like several of them could be loaded in parallel. As far as I see from the sources, loading an .hrb from memory is already supported, if you pass the .hrb as a string to the HB_HRBLOAD() function. Maybe a separate HB_HRBLOADFROMMEMORY() would be more clear. [ BTW I'd recommend using HB_HRB*() names instead of the obsolete __HRB*() ones. ] Brgds, Viktor On Tue, Jan 27, 2009 at 6:45 PM, Francesco Saverio Giudice < i...@fsgiudice.com> wrote: > Hi Pritpal, > > Il 27/01/2009 16.58, Pritpal Bedi ha scritto: > >> Hi All >> >> After examining the uhttpd implimentation I am wondering if .hrb code can >> be loaded once and reused >> with every next request. That way this will come at par >> with Xbase++'s WAA (Web Application Adopter) protocol where program DLL >> (called package) is loaded only once. >> >> this is one point in my todo list, but I don't know if there are any > problems storing hrb modules in memory and reuse them. > > What happens to loaded symbol table ? because every modules will have > HRBMAIN() and could have same other function names. > And another: what is faster ? Load from file using __HRBLOAD() / > __HRBUNLOAD() or scanning and array / hash table every time ? I suppose the > second, but I have doubts on symbol table. > > Przemek, Viktor ? > > Best regards > > Francesco > > > ___ > 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] 2009-01-27 10:14 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com)
> > I think the .hrb modules aren't loaded on a per thread basis, so it's not >> like several of them could be loaded in parallel. >> >> > This should be Przemek to clear. What happens in this case ? Are they MT > safe ? In uhttpd they *can be loaded* in parallel in different threads. > One thing I may do is to serialize them to a single-specific thread that > can run hrb modules one after another and store them to avoid next file > load. Is this the way ? Yes, let's wait for Przemek. It was pretty much a guess from my side, I haven't yet started to use .hrbs, but they seem very useful. > [ BTW I'd recommend using HB_HRB*() names instead of the obsolete __HRB*() >> ones. ] >> > >> > Done, I will upload in next commit Thank you. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-27 04:30 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, > Now if possible and necessary then please update hbprintf.c for > MSVC. It's the last popular compiler I haven't tested. We should I've made and attempt, but it turned out Microsoft refuses to support C99 standard (they push ppl to use recent C++ standards instead). They don't support stdint.h either (probably because it would increase the chance to write more portable code). And there are no official functions to detect inf and nan. So, this doesn't look like a joyride for MSVC. I'm keeping this topic open, so maybe I'll stumble in some solutions in the future. [ I did just a quick check but looking at the CRL sources, it seems MSVC printf() implementation doesn't support nan/inf either. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
Hi Phil, > Again, our other, much simpler and consistent option is to simply swap the >> manual mails to automated ones, with no change on any parties side. >> > Ok, that was a very coherent discussion that adds meaning that you were not > conveying before. Thank you. > > Earlier, it was requested to increase the limit of file attachments on this > list to 150K. I was under the impression that change was to facilitate these > new emails. > > Is this not the case? If not, then why are we raising the limit? No we don't need to, I've written in my previous e-mail that increasing limit is not necessary, since we will be using short (without diffs) notifications, as this seems to be the preferred form here on the list. Short notifications are just a few lines longer than current ChangeLog mails. These short commit notifications are now being sent to svncom...@harbour-project.org [ For _diffed_ notifications, we may add a separate list if there will be enough demand for it in the future. I've set this up for myself, and I like it very much. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-27 04:30 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
type source\common\hbprintf.c(839) : error C2224: left of '.arglst' must have struct/union type source\common\hbprintf.c(840) : error C2224: left of '.repeat' must have struct/union type source\common\hbprintf.c(845) : error C2224: left of '.repeat' must have struct/union type source\common\hbprintf.c(847) : error C2224: left of '.repeat' must have struct/union type source\common\hbprintf.c(848) : error C2224: left of '.maxarg' must have struct/union type source\common\hbprintf.c(851) : warning C4013: 'va_arg_fill' undefined; assuming extern returning int source\common\hbprintf.c(870) : error C2146: syntax error : missing ';' before identifier 'argval' source\common\hbprintf.c(870) : error C2065: 'argval' : undeclared identifier source\common\hbprintf.c(871) : error C2143: syntax error : missing ';' before 'type' source\common\hbprintf.c(877) : error C2065: 'value' : undeclared identifier source\common\hbprintf.c(880) : error C2065: 'param' : undeclared identifier source\common\hbprintf.c(891) : error C2065: 'stop' : undeclared identifier source\common\hbprintf.c(894) : error C2065: 'flags' : undeclared identifier source\common\hbprintf.c(932) : error C2065: 'width' : undeclared identifier source\common\hbprintf.c(932) : warning C4013: 'va_arg_get' undefined; assuming extern returning int source\common\hbprintf.c(932) : error C2223: left of '->value' must point to struct/union source\common\hbprintf.c(932) : fatal error C1903: unable to recover from previous error(s); stopping Brgds, Viktor On Wed, Jan 28, 2009 at 9:04 AM, Viktor Szakáts wrote: > Hi Przemek, > > >> Now if possible and necessary then please update hbprintf.c for >> MSVC. It's the last popular compiler I haven't tested. We should > > > I've made and attempt, but it turned out Microsoft refuses to > support C99 standard (they push ppl to use recent C++ standards > instead). They don't support stdint.h either (probably because > it would increase the chance to write more portable code). > And there are no official functions to detect inf and nan. So, this > doesn't look like a joyride for MSVC. I'm keeping this topic open, > so maybe I'll stumble in some solutions in the future. > > [ I did just a quick check but looking at the CRL sources, it > seems MSVC printf() implementation doesn't support nan/inf > either. ] > > Brgds, > Viktor > > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-28 13:29 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Thanks a lot. Now, these are the only warnings remaining: source\common\hbprintf.c(1036) : warning C4013: '_finite' undefined; assuming extern returning int c:\work\harbour-new\harbour\source\common\hbprintf.c(1191) : warning C4701: potentially uninitialized local variable 'size' used Brgds, Viktor On Wed, Jan 28, 2009 at 1:29 PM, Przemyslaw Czerpak wrote: > 2009-01-28 13:29 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/source/common/hbprintf.c >* redefine [u]intmax_t as [U]LONGLONG in MSVC builds. > > 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] 2009-01-28 13:29 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, > > Now, these are the only warnings remaining: > > source\common\hbprintf.c(1036) : warning C4013: '_finite' undefined; > > assuming extern returning int > > In 99% this function have to be defined in float.h it's so it should > be enough to include this file. > I'll commit modifications but I only guessing what MSVC does. I think this is solved in source/rtl/math.c in some ways, maybe it helps. [ You're right, it's there in float.h in both MSVC 8 and 9, dunno why the warning still. ] > > c:\work\harbour-new\harbour\source\common\hbprintf.c(1191) : warning > C4701: > > potentially uninitialized local variable 'size' used > > It's not real problem but I'll pacify this warning. > > If possible then please try to update hbprintf.c for MSVC yourself. > I do not have any MSVC version which can be executed with WINE in > my Linux BOX so I cannot make any tests myself. I cannot even install > it. I used to do this, but this code is so complicated, I'd better not touch it myself, especially not now, being very busy with other things (there were two huge updates lately). Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2009-01-28 14:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Many thanks. Getting better, now this one remains: source\common\hbprintf.c(1035) : warning C4244: 'function' : conversion from 'long double' to 'double', possible loss of data I've checked line 1035, but I'd rather not touch it. Brgds,Viktor On Wed, Jan 28, 2009 at 2:25 PM, Przemyslaw Czerpak wrote: > 2009-01-28 14:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/source/common/hbprintf.c >! include float.h in MSVC builds >* changed code a little bit to pacify MSVC warning > > 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] 2009-01-28 14:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, I've found these in float.h: (no long double finite, but there's an isnan, plus fpclass() with some useful stuff) --- #ifndef _SIGN_DEFINED _CRTIMP __checkReturn double __cdecl _copysign (__in double _Number, __in double _Sign); _CRTIMP __checkReturn double __cdecl _chgsign (__in double _X); #define _SIGN_DEFINED #endif _CRTIMP __checkReturn double __cdecl _scalb(__in double _X, __in long _Y); _CRTIMP __checkReturn double __cdecl _logb(__in double _X); _CRTIMP __checkReturn double __cdecl _nextafter(__in double _X, __in double _Y); _CRTIMP __checkReturn int__cdecl _finite(__in double _X); _CRTIMP __checkReturn int__cdecl _isnan(__in double _X); _CRTIMP __checkReturn int__cdecl _fpclass(__in double _X); #ifdef _M_AMD64 _CRTIMP __checkReturn float __cdecl _scalbf(__in float _X, __in long _Y); #endif #define _FPCLASS_SNAN 0x0001 /* signaling NaN */ #define _FPCLASS_QNAN 0x0002 /* quiet NaN */ #define _FPCLASS_NINF 0x0004 /* negative infinity */ #define _FPCLASS_NN 0x0008 /* negative normal */ #define _FPCLASS_ND 0x0010 /* negative denormal */ #define _FPCLASS_NZ 0x0020 /* -0 */ #define _FPCLASS_PZ 0x0040 /* +0 */ #define _FPCLASS_PD 0x0080 /* positive denormal */ #define _FPCLASS_PN 0x0100 /* positive normal */ #define _FPCLASS_PINF 0x0200 /* positive infinity */ --- Brgds, Viktor On Wed, Jan 28, 2009 at 5:39 PM, Przemyslaw Czerpak wrote: > On Wed, 28 Jan 2009, Szak�ts Viktor wrote: > > Hi, > > > source\common\hbprintf.c(1035) : warning C4244: 'function' : conversion > from > > 'long double' to 'double', possible loss of data > > I've checked line 1035, but I'd rather not touch it. > > Please check if MSVC has _finite() function which can accept > 'long double' as parameter, f.e.: _finitel() > I'll enable using _finitel() in MSVC builds in next commit but > please confirm if it works. > > 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] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> > I've just check BCC5.5 and it's even worse. BCC *ignores* buffer size > in [v]snprintf() functions so there is not protection at all. It means > that also our hb_snprintf() which uses internally vsnprintf() does > not give any protection. It's _VERY_ serious bug and it means that > at least for this compiler we _MUST_ switch to hb_snprintf_c() or > we will have potential buffer overflows in core code. > It will be good to test also other C compilers. Heavy news. BCC looks unfit for production work in my view. I think we should switch to hb_snprintf_c() for all platforms. (by simply renaming it to hb_snprintf() and remove the #define tricks.) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Fwd: SF.net SVN: harbour-project:[10057] trunk/harbour/ChangeLog
Many thanks Phil. Let's wait for the first commit to appear. Brgds, Viktor On Thu, Jan 29, 2009 at 9:25 AM, Phil Barnett wrote: > Viktor Szakáts wrote: > >> Hi Phil, >> >> >>Yes, that looks like it. >> >>I can build mailboxes on the domain and I can forward them. I can >>join harbour@harbour-project.org >><mailto:harbour@harbour-project.org> with the nomail option set. >> >>Does that sound like it will work? nomail means don't send any >>list mail. >> >> >> Sounds okay, let's try it with svncom...@harbour-project.org > svncom...@harbour-project.org> >> >> I'm setting up a notification for this address. >> > Ok, svncommit is allowed to send mail to this list via a redirect. > > I'm now concerned that this will open a door into the list for spamming, > since we have a redirect with no restrictions that is allowed to post here. > > I now believe it would be best if the have the svn commit emails go > directly to the list, as soon as that happens, I'll get a notice that mail > was blocked and I can allow it through and set it to nomail, nodups. That > will close the hole. > > I'm sure nobody here wants to see spam start making its way in this nice > clean list. > > ___ > 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] (no subject)
Hi Marek, Just out of curiosity, which BCC version is this? Brgds, Viktor On Thu, Jan 29, 2009 at 1:48 PM, Horodyski Marek (PZUZ) < m.horody...@pzuzycie.com.pl> wrote: > I try build harbour from naightly.zip of 29.01.2009, and don't can > create GTWVT. > In make_b32.log have I : > > bcc32.exe -c -q -d -Q -w -w-sig- -tWM -4 -O2 -OS -Ov -Oi -Oc -Iinclude > -Iobj\b32 -DHB_FM_STATISTICS_OFF -oobj\b32\gtwvt.obj > source\rtl\gtwvt\gtwvt.c > source\rtl\gtwvt\gtwvt.c: > Warning W8017 source\rtl\gtwvt\gtwvt.c 87: Redefinition of > '_WIN32_WINNT' is not identical > Error E2451 source\rtl\gtwvt\gtwvt.c 1777: Undefined symbol > 'SM_REMOTESESSION' in function hb_gt_wvt_CreateConsoleWindow > *** 1 errors in Compile *** > > > Regards, > Marek Horodyski > ___ > 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: Previous message: [Harbour] (no subject)
Hm, strange nobody reported that yet, especially that hbwhat.lib has the same issue since years (in almost all of its files). I've committed a fix. Brgds, Viktor On Thu, Jan 29, 2009 at 2:46 PM, Horodyski Marek (PZUZ) < m.horody...@pzuzycie.com.pl> wrote: > > >-Original Message- > >From: Horodyski Marek (PZUZ) > >Sent: Thursday, January 29, 2009 1:48 PM > >To: 'Harbour Project Main Developer List.' > >Subject: > > > >I try build harbour from naightly.zip of 29.01.2009, and don't > > Sorry, it was 27.01.2009 > > Regards, > Marek Horodyski > ___ > 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] 2009-01-29 22:50 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, Worked here with Mingw and msys. I've just tested BCC16, and got this: --- echo. ../../../../lib/dos/bcc16/hbcommon.lib &> __lib__.tmp The syntax of the command is incorrect. --- [ plus, 'install' mode doesn't work at all. ] [ well, BCC16 is really just a portability exercise, isn't it :) ] Brgds, Viktor On Thu, Jan 29, 2009 at 10:51 PM, Przemyslaw Czerpak wrote: > 2009-01-29 22:50 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/config/rules.cf > * harbour/config/dos/bcc16.cf >! fixed wrong automatic macros $? was used instead of $< > > * harbour/config/dir.cf >* optional new DIR_RULE setting for easier testing > > * harbour/config/c.cf >+ added support for setting dependencies for files which needs > grammar header files generated by bison (YACC_DEPEND) > > * harbour/source/macro/Makefile >* marked macrolex.c as YACC_DEPEND dependent > > * harbour/source/compiler/Makefile >* marked complex.c as YACC_DEPEND dependent > > 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] 2009-01-29 22:50 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
I'd suggest to remove bcc16.cf. [ I wasn't expecting it to work either. ] What do you think? Brgds, Viktor On Fri, Jan 30, 2009 at 3:18 AM, Przemyslaw Czerpak wrote: > On Thu, 29 Jan 2009, Szak�ts Viktor wrote: > > Hi, > > > Worked here with Mingw and msys. > > I've just tested BCC16, and got this: > > --- > > echo. ../../../../lib/dos/bcc16/hbcommon.lib &> __lib__.tmp > > The syntax of the command is incorrect. > > --- > > [ plus, 'install' mode doesn't work at all. ] > > [ well, BCC16 is really just a portability exercise, isn't it :) ] > > Thanks for tests. > Looks that it works with *nixes and MS-Windows MSYS. > There are problems with DOS builds. I made some tests with > DOS (in DOSEMU) and DJGPP and it does not work. Looks like > a problems with recursive calls and -C flag. It stops to > work on second level. I'll try to make deeper tests tomorrow. > I would like to ask someone to make MinGW or other Win32 build > tests but without MSYS to check if it works. And if possible > OS2 build tests. For platforms which will not work I'll restore > previous version. For other ones I'd prefer to keep new version > which better utilize parallel processing. It greatly reduces the > compilation time. > > I've never tried to make BCC16 builds so I cannot say it was > ever working. And I'm talking only about make process. For sure > current HVM/RTL cannot work in 16bit environment due to memory > limitations. > > 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
[Harbour] Stripping accents from a string.
Hi all, Stripping accents from a string is often needed when dealing with external systems accepting only ASCII alphabet, and is useful to prepare strings for comparison (in case of names f.e.). original: "aááäbcdeéfghiííjklmnoóóöőőpqrstuúúüűűvwxyz" stripped: "bcdeefghiiijklmnoopqrstuuvwxyz" This functionality is missing from Harbour, yet it would be best integrated to the codepage subsystem. But before I do anything, I'd like to discuss it here. I was thinking adding two new strings to the HB_CODEPAGE structure, which would hold the necessary ASCII character equivalent of the current accented lowercase and uppercase char strings. Any comments? Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Automatic ChangeLog notification activated
Hi all, As may have noticed the first automatic commit notification e-mail has arrived to the list (many thanks to Phil). This means that committers no longer have to manually send an email to this list, containing the changelog entry. In fact, the best would be to never send these anymore to avoid duplicate notification. On the other hand, from now on it's required from all committers to fill the "log message" on commit with the ChangeLog entry belonging to the commit. This is good practice anyway, and most of us did this so far. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Stripping accents from a string.
2009/1/30 Alex Strickland > Viktor Szakáts wrote: > > Any comments? >> > > Are you thinking of catering for things like ß -> ss? Yes, this one could be solved also. This actually makes it much more complicated that I've planned, but fits into the picture and needs to be solved. Another interesting area is cyrillic/greek characters (if we leave out far-east languages for now). Something like this, but in C: --- FUNCTION hb_StrToASCII( cSource ) LOCAL cTarget := "", nChar, tmp FOR tmp := 1 TO Len( cSource ) nChar := Asc( SubStr( cSource, tmp, 1 ) ) IF nChar >= 32 .AND. mChar <= 127 cTarget += SubStr( cSource, tmp, 1 ) ELSEIF HAS_ASCII_EQUIVALENT( nChar ) cTarget += GET_ASCII_EQUIVALENT( nChar ) /* May add multiple chars */ /*ELSE // Strip whole char */ ENDIF NEXT RETURN cTarget --- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Stripping accents from a string.
> > This should be implemented in different way. > We will need global unicode fallback table which will work for any CP > looking for corresponding character replacement in the destination CP > so it will be enough to make translation between any used CP and ASCII > CP (we will have to introduce such unicode table where all characters > which are not in range 32 <= x < 127 will be mapped to 0). Such fall > back table will work also with multibyte translations or if necessary > will replace single byte by multibyte phonetic sequence. f.e. personally > I'm using such feature translation texts in Cyrillic to Latin characters. > > Meanwhile if you need such functionality then you can simply introduce > new CPs which will have only ASCII characters for given langauge with > some sufic like NONE or ASCII, f.e.: > "PLNONE" > [...] > "AABCCDEEFGHIJKLLMNNOOPQRSSTUVWXYZZZ", > "aabccdeefghijkllmnnoopqrsstuvwxyzzz", > [...] > > and then to strip accented characters you can make translations between > "PL*" -> "PLNONE" The same you can make for any other languages. I'm doing this locally in a slightly different way. It needs two simple functions and some minimal high level management. Good but not generic and torn off from core CP handling. The question is really how to implement this properly as part of Harbour. Adding cp??asc?.c (or cp??non?.c) file for all languages seems like not the most optimal solution, albeit indeed this would solve it in the less intrusive way as part of core. > The other solution is creating map from unicode table to Latin letters > and then using this map for translations. This can be done as separate > function and will also work for all langaues. > It could be table indexed by unicode U16 value with ASCII characters > or (if you want to introduce multibyte translations for languages which > do not have corresponding unaccented single characters in Latin alphabet) > with strings. Probably that U16 table will have to point to a structure which would hold all these information amongst the others. > It will be limited to ASCII conversions fallback table I want to introduce. Okay, I won't change anything then, what you say is obviously better, but needs revamping the whole CP code, which goes beyond my scope. Anyhow let's keep this feature in evidence when touching the CP subsystem, because this feature seems to fit here the best and its not very easy to replicate locally in a proper way, yet many developers could benefit from it. Thanks a lot for your feedback. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
