Sigbjorn Finne | 1 Feb 07:36 2003
Picon

cvs commit: hugs98/src storage.c storage.h static.c machdep.c connect.h

sof         2003/01/31 22:36:56 PST

  Modified files:
    src                  storage.c storage.h static.c machdep.c 
                         connect.h 
  Log:
  Backwards compatibility for IO primitives implemented using
  HugsAPI1-4. IO actions now take a single continuation rather
  than two, causing the stated arity of IO primitives built
  with these earlier versions of HugsAPI to be off by one. By
  keeping track of what IO representation an extension DLL
  assumes, we adjust the arity of IO primitives when they're
  added to the name table in storage.c:addPrims().

  ToDo: bump HugsAPI up to 5...no change in functionality,
  but if you implement HugsAPI5 you're assumed to be using
  new IO monad rep.

  Revision  Changes    Path
  1.61      +27 -6     hugs98/src/storage.c
  1.49      +3 -2      hugs98/src/storage.h
  1.136     +13 -4     hugs98/src/static.c
  1.75      +13 -4     hugs98/src/machdep.c
  1.65      +3 -2      hugs98/src/connect.h
Sigbjorn Finne | 2 Feb 03:23 2003
Picon

cvs commit: hugs98/src storage.c storage.h

sof         2003/02/01 18:23:31 PST

  Modified files:
    src                  storage.c storage.h 
  Log:
  added: List nubList(List) [non-destructive]

  Revision  Changes    Path
  1.62      +15 -2     hugs98/src/storage.c
  1.50      +3 -2      hugs98/src/storage.h
Sigbjorn Finne | 2 Feb 03:30 2003
Picon

cvs commit: hugs98/src module.c

sof         2003/02/01 18:30:19 PST

  Modified files:
    src                  module.c 
  Log:
  checkExport(): when re-exporting a TC or class using (..) and
  that entity isn't locally defined, correctly compute the
  constructors/methods that are in scope (and hence exported.)

  What was there previously was just too simple-minded -- it assumed
  that the module of the re-exported TC/class was directly imported
  (and if it wasn't, no constructors/methods ended up being re-exported.)

  Revision  Changes    Path
  1.4       +45 -33    hugs98/src/module.c
Sigbjorn Finne | 2 Feb 03:32 2003
Picon

cvs commit: hugs98/tests/static mod157.hs Mod157_A.hs Mod157_B.hs Mod157_C.hs Mod157_D.hs mod158.hs mod158.output mod159.hs Mod159_A.hs Mod159_B.hs Mod159_C.hs Mod159_D.hs mod160.hs mod160.output hugs98/tests testScript

sof         2003/02/01 18:32:06 PST

  Modified files:
    tests                testScript 
  Added files:
    tests/static         mod157.hs Mod157_A.hs Mod157_B.hs 
                         Mod157_C.hs Mod157_D.hs mod158.hs 
                         mod158.output mod159.hs Mod159_A.hs 
                         Mod159_B.hs Mod159_C.hs Mod159_D.hs 
                         mod160.hs mod160.output 
  Log:
  crafty re-exportation of methods/dcons

  Revision  Changes    Path
  1.45      +4 -0      hugs98/tests/testScript
Ross Paterson | 3 Feb 16:00 2003
Picon

Re: cvs commit: hugs98/src storage.c storage.h static.c machdep.c connect.h

On Fri, Jan 31, 2003 at 10:36:56PM -0800, Sigbjorn Finne wrote:
> sof         2003/01/31 22:36:56 PST
> 
>   Modified files:
>     src                  storage.c storage.h static.c machdep.c 
>                          connect.h 
>   Log:
>   Backwards compatibility for IO primitives implemented using
>   HugsAPI1-4. IO actions now take a single continuation rather
>   than two, causing the stated arity of IO primitives built
>   with these earlier versions of HugsAPI to be off by one. By
>   keeping track of what IO representation an extension DLL
>   assumes, we adjust the arity of IO primitives when they're
>   added to the name table in storage.c:addPrims().

I am sorry about causing this mess, and appreciate your flexibility.

But I don't understand how the API versioning works, when the version
is selected by the interpreter rather than the DLL.

Ross
Sigbjorn Finne | 3 Feb 16:23 2003

Re: cvs commit: hugs98/src storage.c storage.h static.c machdep.c connect.h

"Ross Paterson" <ross <at> soi.city.ac.uk> writes:
>
...
> 
> But I don't understand how the API versioning works, when the version
> is selected by the interpreter rather than the DLL.
> 

Modules that have 'primitive'-based extension DLLs associated with them
are required to use a 'needPrims_hugs <api version>' declaration to signal
its loading. That version number is all that's needed.

This doesn't deal with extension DLLs generated by the new FFI,
where the interpreter simply assumes a specific version number.
There aren't too many of those DLLs floating about (yet), which is
why I mentioned that these will simply have to be re-compiled for
now. The DLL external interface will have to be extended to also
convey what HugsAPI version number the exported primitives
assume.

---sigbjorn
Alastair Reid | 3 Feb 18:48 2003
Picon

Re: cvs commit: hugs98/src storage.c storage.h static.c machdep.c connect.h


"Ross Paterson" <ross <at> soi.city.ac.uk> writes:
>  But I don't understand how the API versioning works, when the
> version is selected by the interpreter rather than the DLL.

Sigbjorn's description of how it works describes the status quo but I
think we can/should look at changing it.

It is my intention that we should stop supporting code generated using
'greencard --target=hugs' since the --target=ffi code does at least as
much.  We should have a strategy to detect problems caused by dropping
support but no more.

So, looking at code generated using 'hugs +G', etc. what we're worried
about is people using code generated by old versions of Hugs where the
binary layout of the virtual table may be different.  The simplest way
to detect problems would be to have a simple consistency check.  For
example the 'API number' could be the release date for that Hugs
version (e.g. 03022003).  This should be inserted in the generated C
code.  Easy to maintain, works ok with binary packaging systems, will
require some recompilation sometimes.

We could get fancier (as Hugs was until a month or so ago) and maintain
the last few major versions of the binary API.  The only difference
here is thet the interpreter will accept one of several different API
versions.  More hassle to maintain for us, a bit easier for people
upgrading Hugs or maintaining binary packages.

My current feeling is that it's a good idea to check a version number
but that supporting more than one version of the binary API isn't
(Continue reading)

Sigbjorn Finne | 4 Feb 04:32 2003
Picon

cvs commit: hugs98/src module.c

sof         2003/02/03 19:32:21 PST

  Modified files:
    src                  module.c 
  Log:
  refactored checkExport()

  Revision  Changes    Path
  1.5       +69 -80    hugs98/src/module.c
Sigbjorn Finne | 4 Feb 06:07 2003
Picon

cvs commit: hugs98/src builtin.c ffi.c machdep.c plugin.c static.c HsFFI.h

sof         2003/02/03 21:07:51 PST

  Modified files:
    src                  builtin.c ffi.c machdep.c plugin.c 
                         static.c HsFFI.h 
  Log:
  Up HugsAPI version to 5 -- method table is unchanged from 4, but
  DLLs are now assumed to also export

      extern int HugsAPIVersion();

  indicating what HugsAPI the primitive stubs in that DLL is
  assuming. The other change is that with version 5, the new
  IO monad representation is assumed.

  Revision  Changes    Path
  1.46      +6 -2      hugs98/src/builtin.c
  1.24      +8 -6      hugs98/src/ffi.c
  1.76      +39 -7     hugs98/src/machdep.c
  1.7       +3 -3      hugs98/src/plugin.c
  1.137     +3 -3      hugs98/src/static.c
  1.11      +16 -0     hugs98/src/HsFFI.h
Sigbjorn Finne | 8 Feb 16:45 2003
Picon

cvs commit: hugs98/src bignums.c

sof         2003/02/08 07:45:55 PST

  Modified files:
    src                  bignums.c 
  Log:
  comment wibble

  Revision  Changes    Path
  1.8       +3 -3      hugs98/src/bignums.c

Gmane