Akim Demaille wrote:

> > To actually allow this, you could have the typed constructors all
> > accept the typeless tokens as well, but I don't consider that really
> > necessary. Unless you want to support that for backward (bugward?)
> > compatibility, I'll just change my code to make two separate
> > make_symbol calls.
> Yes, I prefer it this way.  The whole point of my work on C++'s
> symbols so far is really to be type safe(r).

OK, I've changed my code accordingly.

> See below, I have a working draft that completely replaces
> make_symbol by "merging" the assert-based type checking into
> the symbol_type constructors.  Since that makes the ctors safe,
> I'm fine with exposing them.

Sorry, now I seem to be the one to have trouble using your patch:

- It doesn't seem to be against 3.2.2, so I can't directly use

- I tried to manually apply it (like I did yesterday), but failed
  (maybe I made some mistake this time, or it requires other
  changes, but I don't think debugging this is worthwhile).

- I tried to get just c++.m4 and variant.hh from the branch and copy
  them over my installation, but that also failed.

- Then I tried "Download ZIP" to get the whole branch, but then
  running ./bootstrap gave these errors which I don't quite get
  (I thought not requiring a git repository is the point of this
  download function):

  ./bootstrap: Bootstrapping from checked-out bison sources...
  ./bootstrap: getting gnulib files...
  fatal: Not a git repository (or any parent up to mount point /tmp)
  Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

- I guess the right thing is to clone the repository, but
  unfortunately git is quite data hungry and I'm a bit short on data
  volume (no broadband in my new appartment yet, and mobile data is
  paid in gold here in Germany), so I could only do it on a server
  on which I have access (in the hope of running "make dist" or so
  to get it to my machine then), but after downloading >100 MB (like
  I feared), bootstrap failed with lots of warnings and errors (the
  server is still running jessie, which I can't change, guess that's
  too old to bootstrap bison).

I suppose I could ask you to send me a "dist" archive for testing
now, or if only "data" files need changes compared to 3.2.2, post
those, but for testing future changes, that's not a very nice
workflow. Is there any better way?


Reply via email to