probably a small bug

[Yvan Vander Sanden]

Hi. I'm using the latest pike snapshot, and think i found a small error. While trying to install a module with:

sudo pike -x monger --install Public.Parser.JSON2

I stumbled across this error:

precompile: pike /usr/local/pike/7.8.359/include/pike/precompile.pike json.cmod
/usr/local/pike/7.8.359/include/pike/precompile.pike:2:Couldn't read include file "/usr/local/pike/7.8.359/include/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike".

obviously this precompile file includes an error:

#! /usr/bin/env pike
#include "../lib/modules/Tools.pmod/Standalone.pmod/precompile.pike"

and it should be like this:

#include "../../lib/modules/Tools.pmod/Standalone.pmod/precompile.pike"

Not exactly hard to figure out, but I tought I'd mention it anyway.

Regards,

yvan


--
Copyright only exists in the imagination of those who do not have any.

[Arne Goedeke]

Ive had that bug for ages now. I think it was mentioned on the list
before. I usually work around that by putting a link into the include
directory pointing to the lib/ dir. I think the link is correct in case pike
has not been installed yet. note sure.

arne

On Wed, 28 Oct 2009, Yvan Vander Sanden wrote:

> Hi. I'm using the latest pike snapshot, and think i found a small error. While trying to install a module with:
>
> sudo pike -x monger --install Public.Parser.JSON2
>
> I stumbled across this error:
>
> precompile: pike /usr/local/pike/7.8.359/include/pike/precompile.pike json.cmod
> /usr/local/pike/7.8.359/include/pike/precompile.pike:2:Couldn't read include file
> "/usr/local/pike/7.8.359/include/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike".
>
> obviously this precompile file includes an error:
>
> #! /usr/bin/env pike
> #include "../lib/modules/Tools.pmod/Standalone.pmod/precompile.pike"
>
> and it should be like this:
>
> #include "../../lib/modules/Tools.pmod/Standalone.pmod/precompile.pike"
>
> Not exactly hard to figure out, but I tought I'd mention it anyway.
>
> Regards,
>
> yvan
>
>
> --
> Copyright only exists in the imagination of those who do not have any.
>
>

[Bill Welliver]

Yes, that's been a long standing problem. Sometimes it happens,  
sometimes not. It's so unreliable, I wish someone would just revert  
it; it doesn't make sense to frustrate users in this way.

Bill

On Oct 29, 2009, at 10:34 AM, Arne Goedeke wrote:

> Ive had that bug for ages now. I think it was mentioned on the list  
> before. I usually work around that by putting a link into the  
> include directory pointing to the lib/ dir. I think the link is  
> correct in case pike
> has not been installed yet. note sure.
>
> arne
>
> On Wed, 28 Oct 2009, Yvan Vander Sanden wrote:
>
>> Hi. I'm using the latest pike snapshot, and think i found a small  
>> error. While trying to install a module with:
>> sudo pike -x monger --install Public.Parser.JSON2
>> I stumbled across this error:
>> precompile: pike /usr/local/pike/7.8.359/include/pike/
>> precompile.pike json.cmod
>> /usr/local/pike/7.8.359/include/pike/precompile.pike:2:Couldn't  
>> read include file
>> "/usr/local/pike/7.8.359/include/lib/modules/Tools.pmod/
>> Standalone.pmod/precompile.pike".
>> obviously this precompile file includes an error:
>> #! /usr/bin/env pike
>> #include "../lib/modules/Tools.pmod/Standalone.pmod/precompile.pike"
>> and it should be like this:
>> #include "../../lib/modules/Tools.pmod/Standalone.pmod/
>> precompile.pike"
>> Not exactly hard to figure out, but I tought I'd mention it anyway.
>> Regards,
>> yvan
>> --
>> Copyright only exists in the imagination of those who do not have  
>> any.
>>

[Martin Stjernholm]

Arne Goedeke <el@...> wrote:

> Ive had that bug for ages now. I think it was mentioned on the list
> before. I usually work around that by putting a link into the
> include directory pointing to the lib/ dir. I think the link is
> correct in case pike has not been installed yet. note sure.

Yes, the include path is correct when precompile.pike is in its
original place in the bin directory. It needs to work there, so the
problem is that the same file is copied to include/pike. It should use
another template there, maybe with an inherit instead of #include.

I'm not versed in the monger parts so I don't know how that should be
fixed in a proper way. I hope someone who is can come up with a patch.
The premise is that it leaves the original bin/precompile.pike
untouched.

> On Wed, 28 Oct 2009, Yvan Vander Sanden wrote:
>
>> Hi. I'm using the latest pike snapshot, and think i found a small
>> error. While trying to install a module with:
>>
>> sudo pike -x monger --install Public.Parser.JSON2
>>
>> I stumbled across this error:
>>
>> precompile: pike /usr/local/pike/7.8.359/include/pike/precompile.pike json.cmod
>> /usr/local/pike/7.8.359/include/pike/precompile.pike:2:Couldn't read include file
>> "/usr/local/pike/7.8.359/include/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike".

/.../

[Bill Welliver]

I don't think it has anything to do with monger per se, as the  
problem happens when you use pike -x module. It seems that when the  
change was made to use include, the implementor didn't consider the  
case where precompile would be run from an installed pike. It's not  
clear to me how best to solve the problem since the relative path to  
precompile.pike is different depending on whether you're working in  
the source tree or from within the installed pike.

Bill

On Oct 31, 2009, at 7:47 AM, Martin Stjernholm wrote:

> Arne Goedeke <el@...> wrote:
>
>> Ive had that bug for ages now. I think it was mentioned on the list
>> before. I usually work around that by putting a link into the
>> include directory pointing to the lib/ dir. I think the link is
>> correct in case pike has not been installed yet. note sure.
>
> Yes, the include path is correct when precompile.pike is in its
> original place in the bin directory. It needs to work there, so the
> problem is that the same file is copied to include/pike. It should use
> another template there, maybe with an inherit instead of #include.
>
> I'm not versed in the monger parts so I don't know how that should be
> fixed in a proper way. I hope someone who is can come up with a patch.
> The premise is that it leaves the original bin/precompile.pike
> untouched.
>
>

[Martin Stjernholm]

"H. William Welliver III" <hww3@...> wrote:

> I don't think it has anything to do with monger per se, as the problem
> happens when you use pike -x module.

Ok. Just goes to show that I don't know what I'm talking about in that
area.. ;)

> It seems that when the change was made to use include, the
> implementor didn't consider the case where precompile would be run
> from an installed pike. It's not clear to me how best to solve the
> problem since the relative path to precompile.pike is different
> depending on whether you're working in the source tree or from
> within the installed pike.

Put a different file in include/pike? It's only a couple of lines
afterall, and it doesn't _have_ to be a copy of bin/precompile.pike,
does it?

Besides, in the case of an installed pike, isn't it mainly a compat
measure for "pike -x precompile"? Not saying that it doesn't need to
be fixed, but I reckon the best way is to change to that invocation
method whereever possible.

However for the source tree case, that doesn't work. We want to use
the precompile tool from the pike version being compiled, also if the
pike binary in the path is an older version.

[Bill Welliver]

Yes, I think that's the simplest approach. You're right that you'd
definitely want to use the precompile.pike included with the source when
building in the source tree.

I'm not exactly sure what the rationale was for making the change, as I
was under the impression that things were working correctly before.

I will take a look and make the necessary fix, hopefully this evening.

Bill

On Mon, 2 Nov 2009, Martin Stjernholm wrote:

> Put a different file in include/pike? It's only a couple of lines
> afterall, and it doesn't _have_ to be a copy of bin/precompile.pike,
> does it?
>
> Besides, in the case of an installed pike, isn't it mainly a compat
> measure for "pike -x precompile"? Not saying that it doesn't need to
> be fixed, but I reckon the best way is to change to that invocation
> method whereever possible.
>
> However for the source tree case, that doesn't work. We want to use
> the precompile tool from the pike version being compiled, also if the
> pike binary in the path is an older version.
>

[Martin Stjernholm]

Bill Welliver <hww3@...> wrote:

> I'm not exactly sure what the rationale was for making the change, as
> I was under the impression that things were working correctly
> before.

Presumably someone thought it to be a good idea to make a "pike -x"
tool out of precompile.pike. Doesn't seem so strange to me.

> I will take a look and make the necessary fix, hopefully this evening.

That'd be most welcome!

[Michael Hartman-3]

I know you can easily get the indices of a mapping with indices( mapping
foo ).

Is there an east/fast way to get the second level of indices, or to just
count the number of indices of a nested mapping?

For example, assume the following:

mapping foo =
([
    "element a" :
    ([
        "foo" : 1,
        "bar" : 2
    ])

    "element b" :
    ([
        "stuff" : 1,
        "more stuff" : 2
    ])


    "element c" :
    ([
        "even more stuff" : 1,
        "mega stuff" : 2
    ])
])

Is there a fast/easy way to count up the second level of indices, where
the result would be 6.

 



--
Michael A. Hartman, J.D.
President and CEO, Frogdice, Inc.
http://www.frogdice.com

Apply sizeof() to each value of the top-level mapping and add the
result together:

  `+(0, @map(values(foo), sizeof))

(I've added the extra 0 to handle the case of foo being empty.)