Unable to build docs (was Re: break out of catch?)
2 views
Skip to first unread message
Chris Angelico
Jun 28, 2012, 12:41:36 PM6/28/12
to Henrik Grubbström
On Fri, Jun 29, 2012 at 1:58 AM, Henrik Grubbström <gru...@grubba.org> wrote:
> On Wed, 27 Jun 2012, Chris Angelico wrote:
>
>> Discovered something random about Pike today.
>>
>> Is it intentional that 'break' will terminate a catch block? The catch
>> returns 0 immediately (a zero_type 0, same as if it runs to
>> completion).
>
> Yes, this is an intentional feature. The implementation is also more
> efficient than the alternative of using throw(0) (hmm... potential
> treeopt.in optimization).
Fascinating! Since it's official, I'll make use of it.
>> I can't find anything in the docs about it. It's amusing, more than
>> anything else, and I discovered it only because I had a switch {catch
>> {break;}} construct and it fell through.
>
> It ought to be documented. Feel free to submit a patch to eg
> refdoc/chapters/special_functions.xml.
Sure. Having a little bit of trouble with 'make doc' though: the
command involving "-x assemble_autodoc structure/onepage.xml" is
crashing with a Parser.XML.Tree.RootNode failure 'Indexing the integer
8 with unknown method "get_attributes".' at
pike/lib/modules/Parser.pmod/XML.pmod/Tree.pmod:1153, which is a line
involving get_node_type. This is with the latest 7.9, freshly pulled.
No difference if I 'make clean' or 'make spotless' first.
Prior to that error is a complaint that
GTK2/refdoc/images/gtk2_toolbar.png cannot be read in ordrer to move
it into the build directory. I can't find an ultimate origin error
that would cause the GTK images to be unbuildable; is there a
verbosity option I could turn on?
ChrisA
> On Wed, 27 Jun 2012, Chris Angelico wrote:
>
>> Discovered something random about Pike today.
>>
>> Is it intentional that 'break' will terminate a catch block? The catch
>> returns 0 immediately (a zero_type 0, same as if it runs to
>> completion).
>
> Yes, this is an intentional feature. The implementation is also more
> efficient than the alternative of using throw(0) (hmm... potential
> treeopt.in optimization).
Fascinating! Since it's official, I'll make use of it.
>> I can't find anything in the docs about it. It's amusing, more than
>> anything else, and I discovered it only because I had a switch {catch
>> {break;}} construct and it fell through.
>
> It ought to be documented. Feel free to submit a patch to eg
> refdoc/chapters/special_functions.xml.
Sure. Having a little bit of trouble with 'make doc' though: the
command involving "-x assemble_autodoc structure/onepage.xml" is
crashing with a Parser.XML.Tree.RootNode failure 'Indexing the integer
8 with unknown method "get_attributes".' at
pike/lib/modules/Parser.pmod/XML.pmod/Tree.pmod:1153, which is a line
involving get_node_type. This is with the latest 7.9, freshly pulled.
No difference if I 'make clean' or 'make spotless' first.
Prior to that error is a complaint that
GTK2/refdoc/images/gtk2_toolbar.png cannot be read in ordrer to move
it into the build directory. I can't find an ultimate origin error
that would cause the GTK images to be unbuildable; is there a
verbosity option I could turn on?
ChrisA
Henrik Grubbström
Jun 29, 2012, 4:30:34 AM6/29/12
to Chris Angelico, Lance Dillon, Pike mailinglist
On Fri, 29 Jun 2012, Chris Angelico wrote:
> On Fri, Jun 29, 2012 at 1:58 AM, Henrik Grubbstr�m <gru...@grubba.org> wrote:
>> On Wed, 27 Jun 2012, Chris Angelico wrote:
>>
>>> Discovered something random about Pike today.
>>>
>>> Is it intentional that 'break' will terminate a catch block? The catch
>>> returns 0 immediately (a zero_type 0, same as if it runs to
>>> completion).
>>
>> Yes, this is an intentional feature. The implementation is also more
>> efficient than the alternative of using throw(0) (hmm... potential
>> treeopt.in optimization).
>
> Fascinating! Since it's official, I'll make use of it.
>
>>> I can't find anything in the docs about it. It's amusing, more than
>>> anything else, and I discovered it only because I had a switch {catch
>>> {break;}} construct and it fell through.
>>
>> It ought to be documented. Feel free to submit a patch to eg
>> refdoc/chapters/special_functions.xml.
>
> Sure. Having a little bit of trouble with 'make doc' though: the
> command involving "-x assemble_autodoc structure/onepage.xml" is
> crashing with a Parser.XML.Tree.RootNode failure 'Indexing the integer
> 8 with unknown method "get_attributes".' at
> pike/lib/modules/Parser.pmod/XML.pmod/Tree.pmod:1153, which is a line
> involving get_node_type. This is with the latest 7.9, freshly pulled.
> No difference if I 'make clean' or 'make spotless' first.
As I mentioned ~ a week ago, Pike 7.9 isn't really in a stable state at
the moment.
It seems however that the changes by Per last night fixes the problem with
assemble_autodoc (well at least for me).
> Prior to that error is a complaint that
> GTK2/refdoc/images/gtk2_toolbar.png cannot be read in ordrer to move
> it into the build directory. I can't find an ultimate origin error
> that would cause the GTK images to be unbuildable; is there a
> verbosity option I could turn on?
It seems that a few of the illustations for the GTK2 module are
missing and need to be (re-)generated. Lance: Are you up to the task?
> ChrisA
--
Henrik Grubbstr�m gru...@grubba.org
Roxen Internet Software AB gru...@roxen.com
> On Fri, Jun 29, 2012 at 1:58 AM, Henrik Grubbstr�m <gru...@grubba.org> wrote:
>> On Wed, 27 Jun 2012, Chris Angelico wrote:
>>
>>> Discovered something random about Pike today.
>>>
>>> Is it intentional that 'break' will terminate a catch block? The catch
>>> returns 0 immediately (a zero_type 0, same as if it runs to
>>> completion).
>>
>> Yes, this is an intentional feature. The implementation is also more
>> efficient than the alternative of using throw(0) (hmm... potential
>> treeopt.in optimization).
>
> Fascinating! Since it's official, I'll make use of it.
>
>>> I can't find anything in the docs about it. It's amusing, more than
>>> anything else, and I discovered it only because I had a switch {catch
>>> {break;}} construct and it fell through.
>>
>> It ought to be documented. Feel free to submit a patch to eg
>> refdoc/chapters/special_functions.xml.
>
> Sure. Having a little bit of trouble with 'make doc' though: the
> command involving "-x assemble_autodoc structure/onepage.xml" is
> crashing with a Parser.XML.Tree.RootNode failure 'Indexing the integer
> 8 with unknown method "get_attributes".' at
> pike/lib/modules/Parser.pmod/XML.pmod/Tree.pmod:1153, which is a line
> involving get_node_type. This is with the latest 7.9, freshly pulled.
> No difference if I 'make clean' or 'make spotless' first.
the moment.
It seems however that the changes by Per last night fixes the problem with
assemble_autodoc (well at least for me).
> Prior to that error is a complaint that
> GTK2/refdoc/images/gtk2_toolbar.png cannot be read in ordrer to move
> it into the build directory. I can't find an ultimate origin error
> that would cause the GTK images to be unbuildable; is there a
> verbosity option I could turn on?
missing and need to be (re-)generated. Lance: Are you up to the task?
> ChrisA
--
Henrik Grubbstr�m gru...@grubba.org
Roxen Internet Software AB gru...@roxen.com
Chris Angelico
Jun 29, 2012, 5:39:07 AM6/29/12
to Pike mailinglist
On Fri, Jun 29, 2012 at 6:30 PM, Henrik Grubbström <gru...@grubba.org> wrote:
> As I mentioned ~ a week ago, Pike 7.9 isn't really in a stable state at the
> moment.
Hehe. Aware of that. Not usually an issue, but I tend to try to make
> As I mentioned ~ a week ago, Pike 7.9 isn't really in a stable state at the
> moment.
patches against the latest to keep things simple. Checking out current
doesn't help, so I'll go back a bit and see if I can find a buildable
stable to add catch/break docs to.
> It seems however that the changes by Per last night fixes the problem with
> assemble_autodoc (well at least for me).
another version to build.
Thanks!
ChrisA
Reply all
Reply to author
Forward
0 new messages