Hi Frank!
> Le 11 mai 2018 à 05:28, Frank Heckenbach a écrit :
>
>> I don't think the FSF cares about that as long as the main repo
>> remains hosted on a genuine free software platform (but IANArms).
>> I can see there are already several forks on Github.
>
> As I said, if you'd like to use on
Hi Akim!
> > Actually, where do you keep the current development sources?
>
> It is on Savannah, but I'm really using only as a simple git server.
> Since it's been quite a while since I last worked on the GNU project,
> I was wandering if Savannah had newer management features, like
> Merge Requ
Akim Demaille wrote:
> >> Your idea of letting Bison to keep track of the type does not work
> >> in mid-actions as it is needed to decide which copy constructor to
> >> use, unlike C then.
> >
> > And likewise for %destructor and %printer.
>
> This is something I have not studied yet, I'll have
Hi Frank!
> Le 9 mai 2018 à 05:00, Frank Heckenbach a écrit :
>
> I'm afraid I'm not overly involved with Savannah, either. I had an
> account there as I made some patches to GNU make some years ago, and
> I saw on https://www.gnu.org/software/bison/ that Savannah is (meant
> to be?) the officia
> Le 9 mai 2018 à 05:00, Frank Heckenbach a écrit :
>
> Hans Åberg wrote:
>
>>> On 8 May 2018, at 11:13, Akim Demaille wrote:
>>>
>>> I'm all rusted on Bison.
>>
>> Welcome back, though!
>
> Yes, nice to see you again!
Thanks :)
>> Your idea of letting Bison to keep track of the type do
Hans Åberg wrote:
> > On 8 May 2018, at 11:13, Akim Demaille wrote:
> >
> > I'm all rusted on Bison.
>
> Welcome back, though!
Yes, nice to see you again!
> >> I will apply this patch in my C++17 version, but since I'm not a
> >> Bison maintainer, I can't promise it will go in the C++98 parse
Akim Demaille wrote:
> > I will apply this patch in my C++17 version, but since I'm not a
> > Bison maintainer, I can't promise it will go in the C++98 parser, or
> > in the official Bison sources at all. For now, you can apply the
> > patch manually (your installation directory may vary).
>
> I
> On 8 May 2018, at 11:13, Akim Demaille wrote:
>
> I’m all rusted on Bison.
Welcome back, though!
>> I will apply this patch in my C++17 version, but since I'm not a
>> Bison maintainer, I can't promise it will go in the C++98 parser, or
>> in the official Bison sources at all. For now, you c
hi Frank,
> Le 14 mars 2018 à 04:03, Frank Heckenbach a écrit :
>
> I checked it and found that it's only put in the header if
>
> %define api.token.constructor
>
> is set. But that can only be set if
>
> %define api.value.type
>
> is also set. So this indeed seems to be wrong for non-vari
Hans Åberg wrote:
> > I don't particularly like those extra headers (see my mail in the
> > other thread "Generated headers"), but for now I don't want to
> > change more than necessary.
>
> They conflict if using multiple parsers with different namespaces.
Indeed (see my other mail).
> > But
> On 15 Mar 2018, at 07:41, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
It could be deliberate to avoid them being exported. But C++ now
has namespaces, which cann be used to avoid name conflicts.
>>>
>>> It's all in a namespace anyway (yy by default) and we're only
>>> talking
Hans Åberg wrote:
> >> It could be deliberate to avoid them being exported. But C++ now
> >> has namespaces, which cann be used to avoid name conflicts.
> >
> > It's all in a namespace anyway (yy by default) and we're only
> > talking about a constructor, so no name conflicts. I think it was a
>
> On 14 Mar 2018, at 23:04, Frank Heckenbach wrote:
>
>> It could be deliberate to avoid them being exported. But C++ now
>> has namespaces, which cann be used to avoid name conflicts.
>
> It's all in a namespace anyway (yy by default) and we're only
> talking about a constructor, so no name c
Hans Åberg wrote:
> It could be deliberate to avoid them being exported. But C++ now
> has namespaces, which cann be used to avoid name conflicts.
It's all in a namespace anyway (yy by default) and we're only
talking about a constructor, so no name conflicts. I think it was a
simple mistake.
> On 14 Mar 2018, at 19:22, Kaz Kylheku wrote:
>
> Here is a rule from a production Makefile to remove // comments in Lex code
> that prevent it from being C90
Flex is a separate project:
https://github.com/westes/flex
https://en.wikipedia.org/wiki/Flex_(lexical_analyser_generator)
Thank you for the workaround suggestions. I ended up using a sed rule to
specifically remove the offending keyword:
sed -i '/inline/{ N;
s/inline\s*\n\s*parser::syntax_error::syntax_error/parser::syntax_error::syntax_error/
}' parser.cpp
By keeping it specific, I hope the rule will simply have no
On 2018-03-13 13:31, Hans Åberg wrote:
On 12 Mar 2018, at 20:08, Vishal V wrote:
Bison 3.0.4 marks the constructor for the syntax_error class as
'inline'
when generating a C++ scanner, which results in undefined references
when
the exception is thrown from a separate scanner file. Since this
> On 14 Mar 2018, at 15:46, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>> It is sort of strange in C++ to not have a header, and having
>> inlines not in those.
>
> Sure, I think it was just a mistake. Bison puts inlines for some
> classes it uses internally (by_state, stack_symbol_type)
Hans Åberg wrote:
> It is sort of strange in C++ to not have a header, and having
> inlines not in those.
Sure, I think it was just a mistake. Bison puts inlines for some
classes it uses internally (by_state, stack_symbol_type) in the C++
file, that's OK (though they don't really need the "inline
> On 14 Mar 2018, at 04:03, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>>> On 13 Mar 2018, at 23:23, Frank Heckenbach wrote:
>>>
Bison 3.0.4 marks the constructor for the syntax_error class as 'inline'
when generating a C++ scanner, which results in undefined references when
>>
Hans Åberg wrote:
> > On 13 Mar 2018, at 23:23, Frank Heckenbach wrote:
> >
> >> Bison 3.0.4 marks the constructor for the syntax_error class as 'inline'
> >> when generating a C++ scanner, which results in undefined references when
> >> the exception is thrown from a separate scanner file. Sinc
> On 13 Mar 2018, at 23:23, Frank Heckenbach wrote:
>
>> Bison 3.0.4 marks the constructor for the syntax_error class as 'inline'
>> when generating a C++ scanner, which results in undefined references when
>> the exception is thrown from a separate scanner file. Since this is the
>> stated purp
Vishal V wrote:
> Bison 3.0.4 marks the constructor for the syntax_error class as 'inline'
> when generating a C++ scanner, which results in undefined references when
> the exception is thrown from a separate scanner file. Since this is the
> stated purpose of the syntax_error class (see
> http://
> On 12 Mar 2018, at 20:08, Vishal V wrote:
>
> Bison 3.0.4 marks the constructor for the syntax_error class as 'inline'
> when generating a C++ scanner, which results in undefined references when
> the exception is thrown from a separate scanner file. Since this is the
> stated purpose of the
Hello,
Bison 3.0.4 marks the constructor for the syntax_error class as 'inline'
when generating a C++ scanner, which results in undefined references when
the exception is thrown from a separate scanner file. Since this is the
stated purpose of the syntax_error class (see
http://lists.gnu.org/archi
25 matches
Mail list logo