Re: [Harbour] Rename .cf files to .mk
Hi, On Sun, Aug 16, 2009 at 5:38 AM, Viktor Szakáts wrote: > I'd like to rename .cf files to .mk. > > .mk is listed as official extension for GNU Make files, > while .cf is just some sort Harbour speciality. While I think it's no much sense, it feels harmless to me. > [ I may also rename /config dir to /gnumake. I'm against it. > Plus some > support scripts would also better be moved there eventually, > since they belong together for the most part. ] Which scripts? > If you have better suggestion or any opinion pls speak up. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HB_INSTALL_PREFIX=/opt/harbour issue
On Sat, Aug 15, 2009 at 8:02 PM, Viktor Szakáts wrote: >> Just to report that using the prefix in the subj the libs are put in >> /opt/harbour/lib/harbour. I think it's perfect. >> I think that set correctly HB_INSTALL_PREFIX should be an user's >> responsibility and a safe >> default could be $HOME/harbour-ver. >> Here the main goal seem to respect HB_INSTALL_PREFIX and protect >> casual user from running "make install" >> without knowing well what's he doing. > > I couldn't agree more. The safest place to install files > is the source tree itself. This is is how it's done already > on non-*nix OSes and such installed Harbour is perfectly usable. > > If this is acceptable for Linux users, it's very easy to > make this change. The traditional default prefix for Linux for install from source is /usr/local. Please don't. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Rename .cf files to .mk
On Sun, Aug 16, 2009 at 1:09 PM, Viktor Szakáts wrote: > Hi Phil, > >> On Sun, Aug 16, 2009 at 5:38 AM, Viktor Szakáts >> wrote: >>> >>> I'd like to rename .cf files to .mk. >>> >>> .mk is listed as official extension for GNU Make files, >>> while .cf is just some sort Harbour speciality. >> >> While I think it's no much sense, it feels harmless to me. > > It may make some sense because some tools may turn > on syntax highlighting for example, or do some other > associated features to such known extension. It's > always better to use standard extensions if there is > one. .mk is also used in GNU Make documentation > examples. The tools I use provide makefile syntax highlighting for .cf out of the box. As well as for .mk. So .cf extension seems to be traditional, to. >>> [ I may also rename /config dir to /gnumake. >> >> I'm against it. > > Any reasons? > > [ for me 'config' doesn't seem like a common name for > similar purpose in other projects, nor does it really > describe the content, which is pure gnu make > logic/files/script. ] It is a traditional name for GNU build environments. Also, it's mnemonic while "gnumake" is very hard to remember. >>> Plus some >>> support scripts would also better be moved there eventually, >>> since they belong together for the most part. ] >> >> Which scripts? > > The ones in /bin and maybe /package. postinst.* in the first > round. Currently the make logic and varnames are scattered > in these files and dirs, which makes them more difficult to > keep in sync. Most /bin scripts are now executed from postinst > scripts. I know some of them are also valid as stdalone > scripts (hb-mkdyn.sh and hb-mkimp.bat), plus I'd also wait > until we drop hbmk script before doing more changes here. Ok. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] typo in make_gnu_xmingw.sh?
On Tue, Aug 18, 2009 at 4:35 AM, Viktor Szakáts wrote: >> On Tue, 18 Aug 2009, Szak�ts Viktor wrote: >>> >>> In line 47 TARGET is set to 'i386-mingw32msvc', but the >>> check is made for 'i386-mingw32-gcc' before. This >>> is so since very long, but I wonder if 'msvc' ending in >>> line 47 is just a (copy-past) typo? I committed it unintentionally. the correct default should be i386-mingw32. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] typo in make_gnu_xmingw.sh?
On Tue, Aug 18, 2009 at 10:29 AM, Phil Krylov wrote: > On Tue, Aug 18, 2009 at 4:35 AM, Viktor Szakáts wrote: >>> On Tue, 18 Aug 2009, Szak�ts Viktor wrote: >>>> >>>> In line 47 TARGET is set to 'i386-mingw32msvc', but the >>>> check is made for 'i386-mingw32-gcc' before. This >>>> is so since very long, but I wonder if 'msvc' ending in >>>> line 47 is just a (copy-past) typo? > > I committed it unintentionally. the correct default should be i386-mingw32. Sorry. The check is wrong, the default is right. Committed. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12436] trunk/harbour
Hi, On Tue, Sep 8, 2009 at 12:30 AM, wrote: > 2009-09-07 22:29 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/source/vm/thread.c > + added HB_MT() PRG function which exists only in MT HVM version and > can be REQUESTed from .prg code to force linking MT HVM. I think it misses a HB_STACK_TLS_PRELOAD: gcc -I. -I../../../../../../include -no-cpp-precomp -fno-common -Wall -W -O3 -DHB_MT_VM -o hvmall.o -c ../../../../hvmall.c In file included from ../../../../hvmall.c:89: ../../../../thread.c: In function ‘HB_FUN_HB_MT’: ../../../../thread.c:2512: error: ‘_hb_stack_ptr_’ undeclared (first use in this function) ../../../../thread.c:2512: error: (Each undeclared identifier is reported only once ../../../../thread.c:2512: error: for each function it appears in.) -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 xhb support
On Thu, Sep 24, 2009 at 3:44 PM, Viktor Szakáts wrote: >> In this particular case I suggest to pase -undef:.ARCH. to >> xHarbour compiler and maybe in the future one of xHarbour >> developers (maybe Phil) will add support for this switch >> so it will not be ignored. Of course I can do it and will do it when I have time, I only would like to see that it has established in Harbour. Basically, I don't like the syntax, why was .ARCH. chosen, what do these dots mean, are they somehow related to xBase syntax for logical values and operators? ;) Are there any other samples of usage of such syntax? Does someone else feel it like me? > Let's hope so. The other annoying bit is __PLATFORM__Windows > and __PLATFORM__Linux. Hopefully someone will fix them there. I think we ([x]Harbour) should define both versions in the current situation. It was of course a bad choice to make them mixed-case initially, but I think that it should be kept for compatibility. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] MEMIO - Some Clarifications
On Wed, Sep 30, 2009 at 9:40 PM, Pritpal Bedi wrote: > It means DbDrop() only removes file entry from the directory > but does nothing with file contents. Am I right ? > OR if DbCloseArea() is issued prior to calling DbDrop(), it > removes the file entry as well as file contents. > > To me it appears logical that DbDrop() must never be succeeded > unless file is closed, just like a disk file. What you describe is Windows-only behavior. Under Unix you can unlink any file from a directory you have write permissions on, even if the file is open. When the file is actually closed, the number of references to it becomes 0 and the file content is reclaimed. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Snow Leopard; How to build an 32-bit Harbour
On Sun, Oct 4, 2009 at 10:10 PM, Teo Fonrouge wrote: > On Oct 4, 2009, at 12:13 PM, Viktor Szakáts wrote: >> export HB_USER_LDFLAGS=-arch i386 export HB_USER_LDFLAGS="-arch i386" > -L../../../../../lib/darwin/gcc -arch -lhbnortl -lhbcommon -lm > gcc-4.2: Invalid arch name : -lhbnortl You just need to quote the variable containing spaces, like shown above. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FreeDOS in VMWare VM
On Mon, Oct 12, 2009 at 6:10 PM, Przemyslaw Czerpak wrote: > None of pure DOS application can work because WINE does not have > code necessary to execute them. Sorry, you're wrong. It's been long since I tried to run any 16-bit DOS apps using Wine (BTW it's written like this, not WINE), but they (not all but some) did work. Now I'm on 64-bit which needs some additional hacks to run 16-bit DOS code, but the code in Wine is still there: http://source.winehq.org/source/dlls/winedos/ It's a kind of ntvdm emulation. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FreeDOS in VMWare VM
On Tue, Oct 13, 2009 at 12:28 AM, Przemyslaw Czerpak wrote: > On Mon, 12 Oct 2009, Bruno Luciani wrote: >> You are right Przemyslaw my mistake >> The console aplication that I test was compiled using Harbour >> Talking with a friend of mine , make me notes that diference >> and trying a real 16 bit binary , not work > > Looks that I was wrong and WINE has some own VDM code though for some > reasons it does not work for me. > I'm interesting if it's working for anyone else. > This is an Ubuntu 9.04 on an Athlon 1800+ PC with all updates and Wine taken from WineHQ repository: 1.1.20~winehq~ubuntu~8.04-0ubuntu1. Hmmm the Wine repository refers to 8.04, probably i did not update the address. Anyway, it works: http://tuffnatty.dialup.corbina.ru/~phil/nc.png -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Edit Compile Debug in visual cycle
On Tue, Nov 17, 2009 at 11:14 PM, Viktor Szakáts wrote: >>> Esc + a/A works, Ctrl+J doesn't, Ctrl+Enter does something >>> else, but can't see what exactly. Use M-Enter (that is, ESC ENTER or ALT-ENTER) >>> Shift+F3 doesn't work on OS X, but F13, which is Print Scrn/SysRq on >>> my PC keyboard, does. (it's little bit bad that cursor can't go >>> past last char in line, so there is some flickering around.) Use Learn Keys in MC menu to teach it better key bindings for your terminal. BTW in OS X Terminal.app you can also configure the escape sequences sent by your keys, using Terminal - Preferences - Keyboard. > Eclipse as far programming goes. For file management, > there are nice alternatives, like muCommander or > ForkLift. They don't work for remote SSH sessions. MC is the lowest common denominator, and what works best with MC is using the lowest common set of key combinations that works everywhere, that is, use ESC instead of Alt / function keys, use Ctrl-T instead of Ins on MacBooks, etc. MC has been long stagnating, but now there is a new dev team which really tries to make users' life better. Try the current MC from GIT, or at least 4.7.0-pre4 version. BTW it now has configurable keybindings. The dev team is very responsive to all kinds of feature requests and bug reports. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12921] trunk/harbour
2009/11/18 Przemysław Czerpak : > The 1-st and most important is common sorting algorithm. > If you have three different languages and each of them uses > different national sorting rules then migrating to unicode > you will have to chose some sorting method used for all unicode > strings what means that for at least two languages you will not > be able to replicate exact national sorting conditions. If you > are creating database for phone book and exact national sorting > is a must then you cannot use any language which replaces strict > national sorting with some common for different languages universal > collation algorithm which are used for sorting unicode string and > if support for unicode is not optional then you have to change the > language to some more flexible one which do not force using Unicode. Here's a quite detailed document on that matter: http://unicode.org/reports/tr10/ -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Edit Compile Debug in visual cycle
On Wed, Nov 18, 2009 at 4:27 PM, Viktor Szakáts wrote: > my PC keyboard, does. (it's little bit bad that cursor can't go > past last char in line, so there is some flickering around.) I think you mean odd Terminal.app problem when in bash or mc when you press right on an end of line, cursor moves to the last char. I can remember solving it by backspace press at that moment. >> Use Learn Keys in MC menu to teach it better key bindings for your terminal. >> BTW in OS X Terminal.app you can also configure the escape sequences >> sent by your keys, using Terminal - Preferences - Keyboard. > > Hmm, that would need me to sync these setting with keymaps, > plus key teaching inside MC options. That means at least 2-3 > moving points in this matter, which means it would take a > lot of trial and error, or long time to figure everything > on the matter :( Actually I never modified Terminal.app keybindings, because Learn Keys were enough for me > While Far just works as is. but just on a single platform ;) > Storing settings in .ini (or .xml) files as opposed to > registry. Author Eugene Roshal insisted on registry > (while I insisted that this is a mistake - this was in > 1996), so finally some .bat files have born to save/restore > reg content, but I miss "portability" to this very date, > at least as an option. F.e. I store Far executables on > a VMWare virtual disk (or network share, or host drive), > and access it from multiple VMs. Now keeping in sync my > Far preferences between VMs is practically impossible. > > If you agree, you could ask for this feature on russian > Far Manager forums :) Do you mean they ignore English messages? ;) I am not such a power user of Far as you, I don't have any favorite configuration sets that I would want to preserve across prophylactic Windows reinstalls. And if I did, the bat files work. Well, years ago when I was a primarily Windows user, this Far behaviour irritated me, (the only settings i wanted to save were sane archiver command lines instead of the ones supplied with Far) but now I use Windows only episodically. > Thank you. I figured these two, now I have to get used to > them. But I'll for sure miss things like Alt+<+>, > and to make selections in a more sophisticated > way. + and - when typed on an empty command line start the select mask dialog. As for Shift-Cursor, it's not A True NC-Way ;) I guess it initially appeared in GUI-based NC clones like Windows Commander. Alt+<+> is indeed an interesting feature if you mean "select all files with the same name and different extension". But I usually switch to sorting by name for such operations, it's also safer when you see files you are selecting. Of course if there are tens of such files it's faster to type rm filemask.* ENTER, or if you prefer CUI, type + filemask.* ENTER F8 ENTER. Although I don't need these two features, I suppose that if someone would create corresponding tickets on midnight-commander.com, they'll be reviewed in a short period of time. Even without patches attached. I'd rather support a feature that would add support for M-Enter and % macros in the group select dialog. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Edit Compile Debug in visual cycle
On Wed, Nov 18, 2009 at 5:19 PM, Phil Krylov wrote: >> Storing settings in .ini (or .xml) files as opposed to >> registry. Author Eugene Roshal insisted on registry >> (while I insisted that this is a mistake - this was in >> 1996), so finally some .bat files have born to save/restore >> reg content, but I miss "portability" to this very date, >> at least as an option. F.e. I store Far executables on >> a VMWare virtual disk (or network share, or host drive), >> and access it from multiple VMs. Now keeping in sync my >> Far preferences between VMs is practically impossible. >> >> If you agree, you could ask for this feature on russian >> Far Manager forums :) > > Do you mean they ignore English messages? ;) Ok I got a user account on their bugzilla, there is bug 183: Registry2INI, which proposes to add a cmdline parameter /ini[:filename.ini] to use ini for reading and writing configuration registry entries. Last message on that bug dated 2007. I guess if you write a patch and post it there it might work... -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Edit Compile Debug in visual cycle
On Wed, Nov 18, 2009 at 5:35 PM, Horodyski Marek (PZUZ) wrote: > All these possibilities and much more is in NDN (too on Linux > version). I never liked Turbo Vision. Have you tried running NDN on linux? It compiles. It runs. But it does not work. Also its sources are full of x86 assembly code, so it's non-portable. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Edit Compile Debug in visual cycle
On Wed, Nov 18, 2009 at 5:41 PM, Viktor Szakáts wrote: > [ but why PgUp/PgDn doesn't, it escapes me, I've even > thought it the keys, but it scrolls the whole terminal > buffer instead. ] It''s Terminal.app's feature. Use Shift-PgUp/PgDn -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Edit Compile Debug in visual cycle
On Wed, Nov 18, 2009 at 5:46 PM, Viktor Szakáts wrote: > Patch would be difficult to write for me, by now they > use lots of lists and special stuff inside the registry, > so probably some registry-emulated-in-disk-file solution > would be the most transparent way to make this. But this > would need some more .c skill than I have, and possibly > some sort of basic xml "engine". I have not looked in detail but they write there it's enough to patch registry.cpp to use a file instead of registry. As for the format, there's standard .ini type format used by regedit. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
I had fixed this locally by changing -install_name "harbour$(DYN_EXT)" to -install_name "libharbour$(DYN_EXT)" in DY_RULE (should probably fix also mkdyn). Anyhow, this is a hack as install_name should (usually) be set to the full installation path. --Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 11:08 PM, Viktor Szakáts wrote: > of dylibs. Plus such requirement makes it not possible > to move around .dylib once it's created (but maybe this > how it's meant to be done on OS X). > > What to do? > > 1) Use whatever HB_INSTALL_PREFIX we may have at build pass. > 2) Reapply this parameter on install? (if that's possible) probably it can be done using otool. > 3) Else? I think that on OS X, one is supposed to produce application bundles which include all libraries not installed by Apple. If you want dylibs for including into app bundles, you should use @executable_path token instead of full path in install_name and have no problems. If install_name (copied to executable from dylib at link time) does not have a correct full path to dylib or @executable_path, one has to set DYLD_LIBRARY_PATH envvar for app to locate it. It seems that these are the only two dylib relocation options offered. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx harbour.dylib not found issue
On Sat, Nov 21, 2009 at 11:53 PM, Phil Krylov wrote: > On Sat, Nov 21, 2009 at 11:08 PM, Viktor Szakáts wrote: >> 2) Reapply this parameter on install? (if that's possible) > > probably it can be done using otool. there seems to be a specific tool for this - install_name_tool. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13074] trunk/harbour
Hi, On Mon, Nov 30, 2009 at 10:33 PM, wrote: > ; TODO: I've implemted not all functions of Cairo. Actually, the > minority, but it's enough to do some fancy things. You may use this code, although also not complete: http://xbgtk.cvs.sf.net/viewvc/xbgtk/xbgtk/source/xbcairo.prg?view=markup Although as I see you used pure function-based API, while xbcairo implements OOP API, I suppose everything can be solved using search&replace. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OT: is there an Ubuntu expert who can help me?
On Mon, Jan 25, 2010 at 4:41 AM, April White wrote: > My Ubuntu PC has been flakey lately. > > I booted it up after maybe two months and I only got a grey screen after the > system started. > > So I reinstalled everything, it worked, it confirmed to upgrade to 9.10 and > I accepted. > > Now it does not boot at all. Well it boots but then ABEND's. > > I saw a message about video flash by, so I searched the Web for info on my > monitor got a suggestion about adding "i915.modeset=0" to the kernel line of > the boot up process and within the grub menu list file. > > When I rebooted the video message was replaced by one about waiting for a > device. I remember fixing it, also after a 9.10 upgrade, by removing the "search ..." statement (or something like this) from the grub config on bootup and in the menu.lst. -- Ph. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Build xhgtk inside harbour
On Thu, Mar 12, 2009 at 4:13 PM, Przemyslaw Czerpak wrote: > On Thu, 12 Mar 2009, Ernad Husremovic wrote: > > Hi, > >> Is it implemented similar to the qtRuby, qtPython ? >> They are generating bindings automatically all the classes from the >> framework with some tools (cpp2xml, kalyptus, qtsmoke ..) ? >> Maybe you have wrote that on your blog, but I don't understand spanish >> language :). >> Great effort, thank you for sharing this. > > There is XBGTK project by Phil Krylov (see on sf.net) which > generates [x]Harbour wrapper library for GTK automatically. > The code generator is based on pygtk adopted for [x]Harbour. > Anyhow seems that Phil does not have time to update it in > last years. > Such method of generating wrapper library seems to be the > best choice in long terms. > Maybe we should ask Phil about his plans to this library? > > Phil? I plan to evolve xbgtk as needed. It's currently just enough for a couple of my projects. However, I always welcome any fixes and additions. Well it's really cool when you feed a .spec from new GTK+ version to the code generator, and it builds 85% of API wrappers automatically and you only have to provide some extra overrides you really need. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Build xhgtk inside harbour
Hi, On Fri, Mar 13, 2009 at 6:55 PM, Przemyslaw Czerpak wrote: > I have a patch for Harbour builds and some small cleanups to > the version in CVS. > Can I sent it to you? Yes of course, probably the xbgtk mailing list is a better place, AFAIR you were subscribed to it, but you can send the patch directly to me. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] compiler error
Hi, On Wed, Mar 18, 2009 at 6:15 PM, WenSheng wrote: > >> Thank you, so I understand this is the _only_ such error while building >> complete Harbour? > > No!! is BCC5. > >> >> Can you make tests using MSVC or MinGW compiler? (both free) > > I just test MinGW(gcc 4.3.3) and can compiler lang & codepage *.c > > ps. don't ask me to change MingW from BCC55. I'd try to enforce single-byte codepage in BCC by compiling with HB_USER_CFLAGS=-CP437 Although docs say this only affects the preprocessor, I'd check it. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_objSendMsg fail with GPF
Hi, On Fri, Mar 27, 2009 at 5:13 PM, Viktor Szakáts wrote: >hb_objSendMsg( pSelf,"EVENT", 1, ( long ) lMsg ); // HERE GPF AFAIR hb_objSendMsg() needs not a long, but a PHB_ITEM. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harboude latest nigthy builld. Compile error!
Hi, On Tue, Apr 14, 2009 at 9:18 PM, Ranier Vilela wrote: > config/dir.cf:55: ***missing 'endif'. Stop. Use GNU Make 3.81 or later. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Some xhb developers giving no credit when copying work from Harbour
Hi, On Fri, Apr 24, 2009 at 4:34 PM, Viktor Szakáts wrote: > I wanted to raise this topic for some time, it's a quite sad one > (especially on such a nice sunny Friday as today) so > I was holding it off, but lately Miguel Angel Marchuet again copied > work from Harbour without giving any credit whatsoever to original > authors. Around last month I've also found copy/pasted text from my > own Harbour Changelog entry on the commercial version of xhb > changes pags. Related e-mails thanked above changes to all those > wonderful *xhb* developers. I'm not one of them (still banned), not > wanting to be one, but all this doesn't mean they are not making > benefit of these works, and even earning money out of it. So, IMO > the least thing is to mention Harbour's or authors' name (even if it > happens to be me) name (spelled correctly) when advertising such things. > Current practice is more than misleading for both paying or non-paying > users of these products and quite insulting for those developers who > actually spend months with features and see them like this. Since this > is simply an unmanly thing and probably doesn't break any legal license, > I'm considering changing all my licensed files with a new item requiring > mention of my name when using my work, but before I do I'd like > to sync my views with others. IMHO this is your right to do that but see below. > [ I don't even mention that among all the Harbour developers names > on xhb developer page, mine is accidentally left out. Quite strange > if we consider that 30% of all commits were done by me (vszakats/vszel). ] IMHO you can just report it to Enrico Maria Giordano who manages the page, and he will add your name. > To make it clear I have no problem xhb copying my work or even > selling it (as far as they comply to license), but I'd like to see my > name appearing when appropriate. +1 > Worth mentioning that I've asked this from Miguel and Patrick, so > far without any results (besides Miguel correcting one entry with > my misspelled name, which isn't very polite). IMHO this lack of results is a sad accident. > If you have any opinion on this, please add it here, before doing such > action it'd be also nice to hear some xhb opinions. IMHO every such case can be easily resolved by communicating with the person who forgot to mention your name. Adding a requirement to mention your name won't change anything by itself. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[11614] trunk/harbour
On Fri, Jul 3, 2009 at 10:29 AM, wrote: > Of course it does not mean that Harbour adds in some magic way > thread support to OS-es which does not support threads like DOS. Did you ever experiment with pthread-compatible and non-compatible threading libs in DJGPP contribs? There are some, although I haven't tried any. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error E0047 Code block contains both macro and declared symbol references
Hi,
This code:
PRIVATE l1, l2, d, s
REPLACE &L2 WITH d FOR LANGUAGE = L1
REPLACE &L1 WITH s FOR LANGUAGE = L2
does not compile with the error message in subject. It compiles and
works ok in xHarbour. Why? The preprocessed code is the same,
DBEval( {|| _FIELD->&L2 := d}, {|| LANGUAGE = L1} .F. )
DBEval( {|| _FIELD->&L1 := s}, {|| LANGUAGE = L2} .F. )
-- Ph.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error E0047 Code block contains both macro and declared symbol references
Hi,
On Sat, Jul 18, 2009 at 2:23 PM, Przemyslaw Czerpak wrote:
> On Sat, 18 Jul 2009, Phil Krylov wrote:
>
> Hi,
>
>> This code:
>> PRIVATE l1, l2, d, s
>> REPLACE &L2 WITH d FOR LANGUAGE = L1
>> REPLACE &L1 WITH s FOR LANGUAGE = L2
>> does not compile with the error message in subject. It compiles and
>> works ok in xHarbour. Why? The preprocessed code is the same,
>>DBEval( {|| _FIELD->&L2 := d}, {|| LANGUAGE = L1} .F. )
>>DBEval( {|| _FIELD->&L1 := s}, {|| LANGUAGE = L2} .F. )
>
> Harbour behavior is exactly the same as Clipper.
> Just try to compile this results with Clipper.
> BTW you have to use -a compiler switch to reach such effect.
>
> The error message is correct. To understand it please look at this
> reduce example of the above problem:
>
> memvar l
> local cb
> cb := {|| &m->v + l }
>
> Please look at generate code:
>
>HB_P_PUSHSTRSHORT, 12, /* 12 */
>'{', '|', '|', '&', 'm', '-', '>', 'v', '+', 'l', '}', 0,
>HB_P_MACROTEXT,
>HB_P_MACROPUSH, 11,
>
> Though block is declared explicitly then it's passed as string
> and macrocompiled at runtime. It means that all variable scope
> declaration stop to work. Though we declared l as memvar in our
> code then we have nothing to force memvar access in macrocompiled
> block. If during evaluation there is field caled 'l' in current
> workarea then it will have higher priority then memvar variable.
> Please note that user correctly declared variable in the code
> and does not expect that declaration can be dropped in hidden
> way so it's extremely important to inform him about such situation
> at compile time. Otherwise it may cause unexpected behavior
> at runtime very hard to locate and debug. Compiler error allows
> user to modify the code immediately and add explicit casting,
> f.e. in this case it's enough to change codeblock and add
> explicit memvar aliasing to l variable: m->
> cb := {|| &m->v + m->l }
Thanks, now I understand. At first it seemed strange to me that
something fixed just by MEMVAR-> aliasing is an error instead of a
warning.
> ps. I looked at some contrib thread support in DJGPP and I was not able
>to find any PTHREAD compatible library but I've found two ones:
>jtlwp20s.zip and pdmlwp03.zip. The second one is based on the 1-st
>one so both uses the same mechanism to task switching which is
>done in the interrupt what creates some problems. Because neither
>DOS nor DJGPP CRTL is reentrant safe to use such threads is necessary
>to encapsulate all CRTL/OS function calls in code which disable task
>switching and then enable it when function returns. For such big
>projects like Harbour with possible 3-rd party libraries it's very
>hard to pass such condition so it will be hard for us to use them.
Actually what I meant was:
ftp://ftp.chg.ru/pub/pc/djgpp/beta/v2gnu/pth207b.zip
However, I also don't know how they deal with non-thread-safeness of CRT/DOS.
-- Ph.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-03-26 16:54 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi, On 27/03/2008, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote: > Thank you for information. There is quite big number of different PPC > processors. The ones I was working with were big endian machines but > I do not know if all. Anyhow it's good to always keep the whole code > endian clean to eliminate stupid mistakes when someone will copy few > lines to other file, f.e. working on new GT. (OFFTOPIC) PowerPCs can switch endianness programmatically so it usually depends on OS; e.g. Mac OS Classic / Mac OS X use big-endian mode, and Windows NT/powerpc used litlle-endian. Also I know that Microsoft Virtual PC used to run a little-endian virtual machine with Windows within Mac OS (big endian) using that feature. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Debugger and class hidden scope
Hi, On 17/04/2008, Lorenzo Fiorini <[EMAIL PROTECTED]> wrote: > We told about this time ago. > > This is what we get inspecting a tbrowse object: > Error BASE/41 Scope violation (hidden): TBROWSE:ACELLCOLORS > Called from TBROWSE:ACELLCOLORS(0) > Called from __OBJSENDMSG(0) > Called from __OBJGETVALUELIST(170) > Called from HBDBOBJECT:NEW(84) > ... > > Any workaround? In xHarbour, this is solved using __SetClassScope() function which temporarily disables class message scopes while in debugger. In Harbour, it's #ifdef'ed out in debugger.prg because there's no such function in Harbour. I don't know if it can be easily solved in current Harbour's class engine. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] PCRE update 6.3 -> 7.6
Hi, On 30/04/2008, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote: > Yes, it's for DOS builds. For some compilers which can support > long filenames like DJGPP as workaround it will be possible > to create binaries on platforms which supports long filenames > but it will not work for all compilers. Straange. For me, DJGPP always understood long filenames in Windows DOS boxes and in pure DOS with LFN TSR resident. -- Ph. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
