On Fri, Jun 13, 2008 at 10:39:48AM -0400, Alvaro Herrera wrote:
> What happens when a non-Michael developer changes the original gram.y?
> Is he expected to run the script before committing too? That sounds
> brittle to me.
The situation used to be that this only caused ecpg to be out-of-sync.
No
On Fri, Jun 13, 2008 at 02:57:54PM +0100, Mike Aubury wrote:
> based installation. I personally would stongly favour the script being a tool
> for ecpg tool developers and not used as part of a normal installation.
Why?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at M
Mike Aubury <[EMAIL PROTECTED]> writes:
>> What happens when a non-Michael developer changes the original gram.y?
> The same as happens at the moment - nothing...
Wrong answer. The entire point of this work is to get rid of manual
work in updating the ecpg grammar when the main changes. The abo
Mike Aubury <[EMAIL PROTECTED]> writes:
> I was thinking about the copy on/copy off for more the header info (before
> the %%) - so we can have a really dumb script that just gets told what blocks
> to copy - and what to ignore..
I think you'll find that doesn't work very well; the script will ne
The same as happens at the moment - nothing...
The grammer for the ecpg needs to be re-generated when the grammer in the main
parser is changed - whether its a manual or (mostly) automatic task is
largely irrelevant.
The only downside is that if its not regenerated then the change to gram.y
s
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Mike Aubury wrote:
>> Theres also another thing that needs to be decided, which is if the
>> generated
>> ecpg grammer should be developer generated (ie. Michael Meskes runs a script
>> and commits the output), or should be generated for each and ever
Mike Aubury wrote:
> Theres also another thing that needs to be decided, which is if the generated
> ecpg grammer should be developer generated (ie. Michael Meskes runs a script
> and commits the output), or should be generated for each and every source
> based installation. I personally would
> We're almost certainly going to need some kluges of that sort, so as
> long as they're not all over the place I won't object.
>
> But ... I've seen no evidence that those specific examples are needed.
> Why wouldn't we copy all the backend rules? And based on Michael's last
> comment it's unclea
Mike Aubury <[EMAIL PROTECTED]> writes:
> I took a quick look at this - would it be ok to add some small amounts
> of 'markup' to the gram.y ?
> eg :
> /* ECPGCOPYON */
>
> /* ECPGCOPYOFF */
> /* ECPGMODE=NOSPACE */
> ...
> /* ECPGMODE=USESPACE */
We're almost certainly going to need some
I took a quick look at this - would it be ok to add some small amounts
of 'markup' to the gram.y ?
eg :
/* ECPGCOPYON */
/* ECPGCOPYOFF */
/* ECPGMODE=NOSPACE */
...
/* ECPGMODE=USESPACE */
etc ?
On Friday 13 June 2008 10:47:55 Michael Meskes wrote:
> [Sorry, just noticed that I
[Sorry, just noticed that I didn't answer this email. ]
On Wed, Jun 04, 2008 at 05:06:41PM +0100, Mike Aubury wrote:
> It might depend on the tokens..
> Are ">=", "++" etc single tokens ?
> ...
> > Wouldn't it work to just always insert a space between tokens, no matter
> > whether there was one
It might depend on the tokens..
Are ">=", "++" etc single tokens ?
On Wednesday 04 June 2008 17:06:44 Tom Lane wrote:
> Mike Aubury <[EMAIL PROTECTED]> writes:
> > On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
> >> There is some small magic to know when to have blanks in between and
Mike Aubury <[EMAIL PROTECTED]> writes:
> On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
>> There is some small magic to know when to have blanks in between and
>> when not, but that should be doable.
> I wouldn't mind having a stab at this if you can expand on the 'magic'
> required.
I wouldn't mind having a stab at this if you can expand on the 'magic'
required.
(I'm interested because I might be able to use the same logic to roll a third
version of the .y for Aubit4GL outside of the Postgresql tree)
On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
> On Wed, Jun
On Wed, Jun 04, 2008 at 10:21:19AM -0400, Tom Lane wrote:
> Ugh :-(.
This is why I didn't want to go that route. :-)
> I have not spent much time looking at the ecpg grammar, so feel free to
> laugh this off, but I had the impression that all the rules derived from
> the backend grammar have boil
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Tue, May 27, 2008 at 09:44:02AM -0400, Tom Lane wrote:
>> If we were going to do that, I'd want it to go all the way and somehow
>> generate the common parts of the two .y files from a single source.
> Any idea how to make this happen? We could of co
On Tue, May 27, 2008 at 09:44:02AM -0400, Tom Lane wrote:
> If we were going to do that, I'd want it to go all the way and somehow
> generate the common parts of the two .y files from a single source.
> That'd be enough of a step forward that it would be worth whatever
> ugliness is needed to make
Hi,
I recently (on my flight to Ottawa) changed ecpg to use the keyword list
of the backend instead of its own. This means that there is one less
file to sync manually. However, it also means that an additional keyword
defined in the backend will break compilation as ecpg doesn't have this
definit
18 matches
Mail list logo
