headers
Akim Demaille | 1 Jul 10:03
Picon
Picon
Picon
Gravatar

Re: A bit more info about hanging bison on tru64 5.1b


Le 25 juin 09 à 20:54, Didier Godefroy a écrit :

> It's probably all linked. I had the problem with flex and gcc giving  
> me
> similar issues..

So I guess our problem is somewhere with lib/subpipe.[ch] or something  
like this.  I suppose we should replace it with something equivalent  
in gnulib, as it is better maintained (at a first glance pipe.[ch]  
seems to be what we need).  If someone wants to do it, please be our  
guest :)  I'll have a look at it, but probably not very soon.
Permalink | Reply | 2 comments |
headers
Didier Godefroy | 1 Jul 11:09

Re: A bit more info about hanging bison on tru64 5.1b

on 7/1/09 10:03 AM, Akim Demaille at akim <at> lrde.epita.fr uttered the
following:

>> It's probably all linked. I had the problem with flex and gcc giving
>> me
>> similar issues..
> 
> So I guess our problem is somewhere with lib/subpipe.[ch] or something
> like this.  I suppose we should replace it with something equivalent
> in gnulib, as it is better maintained (at a first glance pipe.[ch]
> seems to be what we need).  If someone wants to do it, please be our
> guest :)  I'll have a look at it, but probably not very soon.

One thing to remember, my system isn't gnulib based (tru64).

I was able to update m4 to the latest and it self tested fine.
How can I track exactly on what it's hanging???

Thanks,

--

-- 
Didier Godefroy
mailto:dg <at> ulysium.net
Support anti-Spam legislation.
Join the fight http://www.cauce.org/
Permalink | Reply | 1 comment |
headers
vivekanandan r | 6 Jul 12:12
Picon
Favicon

Bison Parser to create MT-safe code like Lemon Parser


Hi,

      I am
thankful towards all the GNU Bison developer team.  I have been
immensely   benefited by Bison and am very grateful for it. I have a
suggestion and would like to share it with you here. 

Parser generated by bison should be MT (MultiThread)-safe :

   Lemon Parser
 generated code is re-entrant and MT-Safe which attracts
 Bison   users like me to move to Lemon. ex: PHP.

  
Hence we have to add custom option to generate lemon based parser code which
will be more useful for all. I have just implemented VCG Graph for the Lemon
Parser(code: http://www.gnudeveloper.com/software/lemon/lemon.c)..
And  I am now interested in implementing this feature in Bison.

Please
provide your valuable suggestions. 

 awaiting
your valuable response…

Vivekanandan.

 
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akim Demaille | 7 Jul 12:49
Picon
Picon
Picon
Gravatar

Re: Bison Parser to create MT-safe code like Lemon Parser


Le 6 juil. 09 à 12:12, vivekanandan r a écrit :

> Hi,

Hi,

>       I am
> thankful towards all the GNU Bison developer team.  I have been
> immensely   benefited by Bison and am very grateful for it.

Thanks for saying!

> I have a
> suggestion and would like to share it with you here.
>
> Parser generated by bison should be MT (MultiThread)-safe :
>
>    Lemon Parser
>  generated code is re-entrant and MT-Safe which attracts
>  Bison   users like me to move to Lemon. ex: PHP.

Can you tell me more about that?  What makes you think our parsers are  
not thread-safe?  Which parsers are you using?  Yacc-like parsers?   
Then of course, they are not, but if you use sane interface (look for  
"pure" in the documentation), I don't see why the parser would not be  
thread-safe.

> Hence we have to add custom option to generate lemon based parser  
> code which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akim Demaille | 15 Jul 16:03
Picon
Picon
Picon

Re: A bit more info about hanging bison on tru64 5.1b

>>> "DG" == Didier Godefroy <dg <at> ulysium.net> writes:

Hi Didier,

 > One thing to remember, my system isn't gnulib based (tru64).

You're probably confusing GNU Libc and gnulib, which is a different
kind of beast (an environment to protect the developers from
differences bw machines).

I tried, just to see, another way to call m4.  I'd be curious to know
if it addresses your problems.  Could you please try the following
experimental tarball?  Thanks in advance.

<URL:http://www.lrde.epita.fr/download/bison-2.4.347-46fa3-dirty.tar.gz>

If it does not work, I'm afraid you're a bit on your own to try to
understand what's going on.  For a start, it would be useful that you
run

        ./src/test-pipe

from this tarball's build tree.
Permalink | Reply | 0 comments |
headers
A Braunsdorf | 15 Jul 23:36
Picon
Favicon

Detecting (g)m4


Maybe not quite a bug, and maybe not your fault, but configure
apparently picks the first program called "gm4" in my path, >not<
the first appropriate m4 or gm4.

My problem is that Sun provides a "gm4" that is old and makes nearly
all the bison tests fail.  I have installed a much newer one as
"m4" (what it installs as by default, of course), which is much
earlier in my path and works fine.

Yes, I can tell it which m4 to use, but the canonical name >is<
"m4", so that seems wrong.  And yes, I can make (and have now made)
a link to my m4 called "gm4", but the program's name is "m4", and
I think the detection should be smarter, especially since it really
is version-sensitive.

Thoughts?

ab
Permalink | Reply | 9 comments |
headers
Akim Demaille | 16 Jul 09:20
Picon
Picon
Picon
Gravatar

Re: Detecting (g)m4


Le 15 juil. 09 à 23:36, A Braunsdorf a écrit :

>
> Maybe not quite a bug, and maybe not your fault, but configure
> apparently picks the first program called "gm4" in my path, >not<
> the first appropriate m4 or gm4.
>
> My problem is that Sun provides a "gm4" that is old and makes nearly
> all the bison tests fail.  I have installed a much newer one as
> "m4" (what it installs as by default, of course), which is much
> earlier in my path and works fine.
>
> Yes, I can tell it which m4 to use, but the canonical name >is<
> "m4", so that seems wrong.  And yes, I can make (and have now made)
> a link to my m4 called "gm4", but the program's name is "m4", and
> I think the detection should be smarter, especially since it really
> is version-sensitive.
>
> Thoughts?

You are right, of course.  But it's more efforts to look for the  
"best" m4 around, so improvements, unless contributed by some devoted  
user (read my mind ;), are unlikely to be made soon.  Especially  
because I see no existing Autoconf macro to address this issue.  Maybe  
Autoconf itself has one (after all it is probably the most demanding  
M4 application).
Permalink | Reply | 8 comments |
headers
Hans Aberg | 16 Jul 10:23
Picon
Picon

Re: Detecting (g)m4

On 16 Jul 2009, at 09:20, Akim Demaille wrote:

>> Maybe not quite a bug, and maybe not your fault, but configure
>> apparently picks the first program called "gm4" in my path, >not<
>> the first appropriate m4 or gm4.

> You are right, of course.  But it's more efforts to look for the  
> "best" m4 around, so improvements, unless contributed by some  
> devoted user (read my mind ;), are unlikely to be made soon.   
> Especially because I see no existing Autoconf macro to address this  
> issue.  Maybe Autoconf itself has one (after all it is probably the  
> most demanding M4 application).

This was discussed with a bug long time ago. It think may have been  
changed. So make sure that Autoconf is up-to-date.

   Hans
Permalink | Reply | 0 comments |
headers
Eric Blake | 16 Jul 19:27
Gravatar

Re: Detecting (g)m4

Akim Demaille <akim <at> lrde.epita.fr> writes:

> > Maybe not quite a bug, and maybe not your fault, but configure
> > apparently picks the first program called "gm4" in my path, >not<
> > the first appropriate m4 or gm4.
> 
> You are right, of course.  But it's more efforts to look for the  
> "best" m4 around, so improvements, unless contributed by some devoted  
> user (read my mind ;), are unlikely to be made soon.  Especially  

</me puts on ESP hat> Are you talking to me?

> because I see no existing Autoconf macro to address this issue.  Maybe  
> Autoconf itself has one (after all it is probably the most demanding  
> M4 application).

Which version of bison?  

I can confirm that the latest released version, bison 2.4, used m4/m4.m4 dating 
from 2000, which does indeed have severe limitations at detecting a good m4 
version.  You can work around them by calling './configure 
M4=/path/to/your/preferred/m4'.

Meanwhile, the latest git version uses serial 5 of autoconf's m4/m4.m4, which 
does a MUCH better job at picking m4 1.4.5 or newer, regardless of spelling.  
Autoconf itself has moved on to serial 6 (which now checks for the m4 -g flag 
added in m4 1.4.12 or newer), so maybe it's time to do another submodule update 
to pick that up.

--

--
(Continue reading)

Permalink | Reply | 6 comments |
headers
Akim Demaille | 17 Jul 09:54
Picon
Picon
Picon
Gravatar

Re: Detecting (g)m4


Le 16 juil. 09 à 19:27, Eric Blake a écrit :

Hi Eric!

> Akim Demaille <akim <at> lrde.epita.fr> writes:
>
>>> Maybe not quite a bug, and maybe not your fault, but configure
>>> apparently picks the first program called "gm4" in my path, >not<
>>> the first appropriate m4 or gm4.
>>
>> You are right, of course.  But it's more efforts to look for the
>> "best" m4 around, so improvements, unless contributed by some devoted
>> user (read my mind ;), are unlikely to be made soon.  Especially
>
> </me puts on ESP hat> Are you talking to me?

Well, I was more thinking about the original reporter (lost in the  
CC's btw).  But I'm fine with your reading of my mind :)

>> because I see no existing Autoconf macro to address this issue.   
>> Maybe
>> Autoconf itself has one (after all it is probably the most demanding
>> M4 application).
>
> Which version of bison?

I had forgotten the changes from Joel and you that moved to using  
Autoconf's macro.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane