Commit Graph

484 Commits

Author SHA1 Message Date
Ryszard Glab
4370282dd8 ChangeLog 2001-01-09 16:15 UTC+0100 2001-01-09 15:10:35 +00:00
Ron Pinkas
4a38c6c28a 2001-01-08 14:35 UTC-0800 Ron Pinkas <ron@profit-master.com>
* harbour/source/vm/estack.c
     * Corrected typo _HB_ITEM => HB_ITEM in type casting.
2001-01-08 22:27:54 +00:00
Jean-Francois Lefebvre
b7abfe9244 2001-01-08 22:18 GMT+0100 JFL (mafact) <jfl@mafact.com> 2001-01-08 21:24:17 +00:00
Alexander S.Kresin
3caa562d66 2001-01-06 9:18 GMT+3 Alexander Kresin <alex@belacy.belgorod.su> 2001-01-06 13:01:28 +00:00
Ron Pinkas
2a91e7a436 2000-12-28 20:50 UTC+0800 Ron Pinkas <ron@profit-master.com>
* source/vm/eval.c
     * Minor formatting.

   * source/vm/hvm.c
     * Added derefferncing of Block Vars in hb_vmPushLocal()
     /* Ryszard can you please review this change. */
2000-12-29 08:46:24 +00:00
Ron Pinkas
632860df4a 2000-12-14 17:00 UTC+0800 Ron Pinkas <ron@profit-master.com>
* source/vm/eval.c
     * Removed unneeded hb_stackItemFromBase(1), reverted to use pItem obtained by hb_param()
2000-12-15 00:59:23 +00:00
Maurilio Longo
cca631828b 2000-12-13 22:04 GMT+1 Maurilio Longo <maurilio.longo@libero.it>
* source/vm/estack.c
     + added missing semicolons (lines 374 and 416)
2000-12-13 21:08:55 +00:00
Ron Pinkas
4577f36e4b 2000-12-12 17:35 UTC+0800 Ron Pinkas <ron@profit-master.com>
* source/vm/eval.c
     + Corrected support for block passed by reference.

     /* Ryszard, is there any reason to use hb_stackItemFromBase(1) instead of pItem? */
2000-12-13 01:33:35 +00:00
Ryszard Glab
ccc567b1d0 ChangeLog 2000-12-12 21:25 UTC+0100 2000-12-12 20:22:23 +00:00
Ryszard Glab
cae8dad460 Initial revision 2000-12-12 20:16:33 +00:00
Ron Pinkas
0c2228a024 2000-11-30 18:25 UTC+0800 Ron Pinkas <ron@profit-master.com>
* include/hbmacro.h
   * source/macro/macro.y
   * source/vm/macro.c
     ! Renamed hb_compParse() to hb_macroYYParse(). We already have hb_macroParse() and hcompparse()

   * source/compiler/harbour.y
     * Added token GET (not used) just so that harboury.h is compatible with harbour.sly

   * source/rtl/tgetint.prg
     * Reverted to use _1 and == NIL to not break Clipper compatibility.

     /* Ryszard, if you want to re-introduce PCount() and HB_PVALUE(), I'll ask (since I wrote this original code)
        that you protect it with #ifdef FLEX etc. If you do I would suggest you further protect it with #ifdef STRICT...
	becuase this will defintly break strict compatability. */
2000-12-01 02:25:20 +00:00
Ron Pinkas
159793c2ce 2000-11-29 13:50 UTC+0800 Ron Pinkas <ron@profit-master.com>
* source/compiler/harbour.c
     * Exported: hb_compFieldGetPos() and hb_compMemvarGetPos()

   * source/compiler/harbour.sly
     ! Changed __GET() support to be parameter compatible with Clipper

   * include/hberrors.h
   * source/compiler/hbgenerr.c
     + Added Error: "GET contains complex macro"

   * source/pp/pptable.c
     - Removed bSetGet from rule of GET, PP output now Clipper compatible.

   * source/vm/memvars.c
     + Added HB_FUNC( __ISMV ) // Return .T. if passed string as a Memory Variable.

   * source/rtl/tgetint.prg
     ! Fixed __GET() to be 100% parameter compatible with Clipper.
     ! When 1st parameter (bSetGet) is NIL the bSetGet will be built internaly,
       not using macro in most cases, even if the Get Variable itslef is a macro :-)

   /* Ryszard, this will further break Flex support for GET, but makes __GET() 100% Clipper compatible as you suggested.
      Please note, that Clipper does *NOT* pass a bSetGet *only* when the Get Var is a *simple* *non* declared Variable.
      Declared Variables in this context are: MEMVAR, FIELD, LOCAL, and STATIC. For all of those, bSetGet *is* generated!
      Clipper also generates bSetGet for "Complex Variables", i.e. Aliased Variables, Object Data, etc.! */
2000-11-29 21:54:03 +00:00
Jean-Francois Lefebvre
a8d6337d7c 2000-11-23 23:11 UTC+0100 jfl (mafact) <jfl@mafact.com> 2000-11-23 21:17:23 +00:00
Jean-Francois Lefebvre
3a0cb6d7b4 2000-11-21 23:42 UTC-0100 JFL (mafact) <jfl@mafact.com> 2000-11-21 22:48:25 +00:00
Ryszard Glab
7df80dd709 ChangeLog 2000-11-17 20:50 UTC+0100 2000-11-17 19:44:48 +00:00
Ryszard Glab
dc01ccd135 ChangeLog 2000-11-12 15:20 UTC+0100 2000-11-12 13:10:12 +00:00
Jean-Francois Lefebvre
1529b30913 2000-11-10 22:40 UTC+0100 JFL (mafact) <jfl@mafact.com> 2000-11-10 22:36:05 +00:00
Brian Hays
0f85576404 2000-11-08 11:28 UTC+0800 Brian Hays <bhays@abacuslaw.com> 2000-11-08 19:31:27 +00:00
Ryszard Glab
9440d323b0 ChangeLog 2000-11-08 18:25 UTC+0100 2000-11-08 17:28:24 +00:00
Ryszard Glab
0598030751 ChangeLog 2000-11-08 15:40 UTC+0100 2000-11-08 14:29:26 +00:00
Jean-Francois Lefebvre
11ed9dc157 2000-11-06 22:43 UTC+0100 JFL (mafact) <jfl@mafact.com> 2000-11-06 21:40:12 +00:00
Maurilio Longo
73bfbd3208 2000-11-05 19:52 GMT+1 Maurilio Longo <maurilio.longo@libero.it> 2000-11-05 18:58:56 +00:00
Jean-Francois Lefebvre
41fe9b6ac9 2000-11-05 10:00 UTC+0100 JFL (mafact) <jfl@mafact.com> 2000-11-05 16:56:35 +00:00
Jean-Francois Lefebvre
0e65b01d2e 2000-11-05 10:00 UTC+0100 JFL (mafact) <jfl@mafact.com> 2000-11-05 08:59:01 +00:00
Ryszard Glab
92e1ff661f ChangeLog 2000-11-04 13:35 UTC+0100 2000-11-04 12:39:40 +00:00
Jean-Francois Lefebvre
f4f1bdab20 2000-10-31 20:56 GMT+1 JFL (Mafact) <jfl@mafact.com> 2000-10-31 19:52:16 +00:00
Maurilio Longo
82b8652beb 2000-10-21 23:02 GMT+2 Maurilio Longo <maurilio.longo@libero.it> 2000-10-21 21:07:29 +00:00
Ryszard Glab
68ec8e0c58 ChangeLog 2000-10-17 11:10 UTC+0100 2000-10-17 09:31:29 +00:00
Jean-Francois Lefebvre
04c647c9b2 2000-10-03 231:45 UTC+0100 JFL <jfl@mafact.com> (2 : missing files) 2000-10-04 19:48:05 +00:00
Jean-Francois Lefebvre
31c1024063 2000-09-20 23:36 UTC+0200 JFL (mafact) <jfl@mafact.com> 2000-09-20 21:38:38 +00:00
David G. Holm
ad3acaea71 See ChangeLog entry 2000-09-15 17:45 UTC-0400 David G. Holm <dholm@jsd-llc.com> 2000-09-15 21:52:46 +00:00
Viktor Szakats
0bf0970f51 2000-08-15 02:48 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-08-15 01:32:01 +00:00
Antonio Linares
5c1b1da3ab 20000813-06:55 GMT+1 2000-08-13 05:00:21 +00:00
Viktor Szakats
77e2ebbac6 2000-07-29 17:25 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-07-29 15:29:58 +00:00
Ryszard Glab
433ae6a7f3 ChangeLog 2000-07-28 18:15 UTC+0100 2000-07-28 16:10:49 +00:00
Jean-Francois Lefebvre
44432ddd56 2000-07-28 00:05 UTC+0200 JfL <jfl@mafact.com> & RaC <Rac@mafact.com> 2000-07-27 22:04:48 +00:00
Ryszard Glab
780d535f1f ChangeLog 2000-07-27 10:15 UTC+0100 2000-07-27 08:10:42 +00:00
David G. Holm
7cbf58961e See ChangeLog entry 2000-07-26 16:25 UTC-0400 David G. Holm <dholm@jsd-llc.com> 2000-07-26 20:29:12 +00:00
Ryszard Glab
512345997b ChangeLog 2000-07-25 19:00 UTC+0100 2000-07-25 17:20:21 +00:00
Viktor Szakats
f14fbd7510 2000-07-25 13:47 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-07-25 11:55:27 +00:00
Viktor Szakats
cec63780c5 2000-07-25 00:53 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-07-24 22:54:45 +00:00
Viktor Szakats
b30e1acf12 2000-07-25 00:33 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-07-24 22:33:29 +00:00
Viktor Szakats
09534028e0 2000-07-25 00:23 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-07-24 22:24:25 +00:00
Viktor Szakats
d407f71aa5 2000-07-24 22:28 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-07-24 20:30:05 +00:00
Viktor Szakats
a1e6f03ea0 2000-07-24 22:12 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-07-24 20:16:31 +00:00
Jean-Francois Lefebvre
2f5cb76a3b 2000-07-18 10:25 UTC+0200 JfL <jfl@mafact.com> & RaC <Rac@mafact.com> 2000-07-18 20:48:06 +00:00
Ryszard Glab
1337925fae ChangeLog 2000-07-16 19:00 UTC+0100 2000-07-16 16:55:37 +00:00
Ryszard Glab
f3fd7233db ChangeLog 2000-07-16 17:40 UTC+0100 2000-07-16 15:37:11 +00:00
Jean-Francois Lefebvre
e37a8eb1dd 2000-07-15 01:20 UTC+0200 JfL <jfl@mafact.com> & RaC <Rac@mafact.com> 2000-07-14 23:23:17 +00:00
Ryszard Glab
4317b0b71b ChangeLog 2000-07-14 20:25 UTC+0100 2000-07-14 18:20:21 +00:00