User-defined record types, v3

User-defined record types, v3

[Lars Brinkhoff]

Third review round for user-defined record types, available from the
branch scratch/record.

- ChangeLog commit messages.
- EIEIO has been adapted to use records.
- Tests have been added.
- Documentation has been updated.
- No testsuite regressions.

From the manual:

      The purpose of records is to allow programmers to create objects
    with new types that are not built into Emacs.  They are used as the
    underlying representation of @code{cl-defstruct} and @code{defclass}
    instances.
      
      Internally, a record object is much like a vector; its slots can
    be accessed using @code{aref}.  However, the first slot is used to
    hold its type as returned by @code{type-of}.  Like arrays, records
    use zero-origin indexing: the first slot has index 0.

Re: User-defined record types, v3

[Lars Brinkhoff]

Lars Brinkhoff wrote:
> Third review round for user-defined record types, available from the
> branch scratch/record.

John Wiegley has okayed this, so I'm planning to merge this within 24
hours.

A full boostrap build (and testsuite run) works fine.  Incremental
builds can run into problems with .elc files.  To be on the safe side, I
usually rebuild from a clean repository, but just removing all .elc
files also seems to work.



> From the manual:
>
>       The purpose of records is to allow programmers to create objects
>     with new types that are not built into Emacs.  They are used as the
>     underlying representation of @code{cl-defstruct} and @code{defclass}
>     instances.
>       
>       Internally, a record object is much like a vector; its slots can
>     be accessed using @code{aref}.  However, the first slot is used to
>     hold its type as returned by @code{type-of}.  Like arrays, records
>     use zero-origin indexing: the first slot has index 0.

Re: User-defined record types, v3

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

>>>>> "LB" == Lars Brinkhoff <lars@nocrew.org> writes:

LB> John Wiegley has okayed this, so I'm planning to merge this within 24
LB> hours.

So it's on the official record, I'll confirm for the list that I did OK
this. :)

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: User-defined record types, v3

[Lars Brinkhoff]

John Wiegley wrote:
> LB> John Wiegley has okayed this, so I'm planning to merge this within
> LB> 24 hours.
> So it's on the official record, I'll confirm for the list that I did OK
> this. :)

It has been pushed.

I'll reiterate:

> A full boostrap build (and testsuite run) works fine.  Incremental
> builds can run into problems with .elc files.  To be on the safe side,
> I usually rebuild from a clean repository, but just removing all .elc
> files also seems to work.

Also, if some .elc file (outside the repository) compiled with the old
cl-defstruct breaks, there a backward compatibility mode that can be
enabled:

    (cl-old-struct-compat-mode 1)

If there's a need to go beoynd that, I have a patch to bump the version
of generated .elc files (the number after ;ELC), and enable backward
compatibility as soon as an old file is loaded.

Re: User-defined record types, v3

[Clément Pit-Claudel]

On 2017-04-04 03:40, Lars Brinkhoff wrote:
> John Wiegley wrote:
>> LB> John Wiegley has okayed this, so I'm planning to merge this within
>> LB> 24 hours.
>> So it's on the official record, I'll confirm for the list that I did OK
>> this. :)
> 
> It has been pushed.
> 
> I'll reiterate:
> 
>> A full boostrap build (and testsuite run) works fine.  Incremental
>> builds can run into problems with .elc files.  To be on the safe side,
>> I usually rebuild from a clean repository, but just removing all .elc
>> files also seems to work.
> 
> Also, if some .elc file (outside the repository) compiled with the old
> cl-defstruct breaks, there a backward compatibility mode that can be
> enabled:
> 
>     (cl-old-struct-compat-mode 1)
> 
> If there's a need to go beoynd that, I have a patch to bump the version
> of generated .elc files (the number after ;ELC), and enable backward
> compatibility as soon as an old file is loaded.

Is there a way for Lisp programs to read the version tag of an ELC file before loading it?

Clément.

Re: User-defined record types, v3

[Lars Brinkhoff]

Clément Pit-Claudel wrote:
> Is there a way for Lisp programs to read the version tag of an ELC
> file before loading it?

I haven't looked to see if there's a ready-made function for this.  The
code in src/lread.c just looks at the fourth byte of the first line.
Then it checks that a certain regexp is present near the beginning of
the file.

Checking the version of Emacs that an ELisp file was compiled with [WAS: Re: User-defined record types, v3]

[Clément Pit-Claudel]

On 2017-04-04 08:32, Lars Brinkhoff wrote:
> I haven't looked to see if there's a ready-made function for this.  The
> code in src/lread.c just looks at the fourth byte of the first line.
> Then it checks that a certain regexp is present near the beginning of
> the file.

Thanks! I can't find such a function on the ELisp side, indeed.  Maybe it would be nice to have one.
My current strategy is to have a "canary": an ELisp file that just records the Emacs version that compiled it (using eval-when-compile).  Loading that file then allows me to read that version and decides whether I need to recompile the other files.  It'd be nicer to be able to do away with that.

Clément.