Discussion:
Pike 8.0 RC1
Per Hedbor () @ Pike (-) importmöte för mailinglistan
2014-10-22 15:45:01 UTC
Permalink
The first release candidate for Pike 8.0 has been uploaded to the pike
site: Pike 8.0.10,

http://pike.lysator.liu.se/pub/pike/all/8.0.10/Pike-v8.0.10.tar.gz or
ftp://pike.lysator.liu.se/pub/pike/all/8.0.10/Pike-v8.0.10.tar.gz

It would be nice if you could test compile it, especially if you have
systems that do not already have pike installed. You can also feel
free to run the testsuite.

Also, if you have anything you really want to fix in pike 8.0, please
say something about it, or commit a fix soon.
--
Per Hedbor
Arne Goedeke
2014-10-22 17:17:18 UTC
Permalink
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
The first release candidate for Pike 8.0 has been uploaded to the pike
site: Pike 8.0.10,
http://pike.lysator.liu.se/pub/pike/all/8.0.10/Pike-v8.0.10.tar.gz or
ftp://pike.lysator.liu.se/pub/pike/all/8.0.10/Pike-v8.0.10.tar.gz
It would be nice if you could test compile it, especially if you have
systems that do not already have pike installed. You can also feel
free to run the testsuite.
Also, if you have anything you really want to fix in pike 8.0, please
say something about it, or commit a fix soon.
We are currently not completely compatible with nettle 2.7, which is
what gentoo is still shipping. The problem, which has already been
discussed here, is that at some point nettle changed the signatures for
random functions. Should that be fixed?

arne
Henrik Grubbström
2014-10-22 18:15:13 UTC
Permalink
Post by Arne Goedeke
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
Also, if you have anything you really want to fix in pike 8.0, please
say something about it, or commit a fix soon.
We are currently not completely compatible with nettle 2.7, which is
what gentoo is still shipping. The problem, which has already been
discussed here, is that at some point nettle changed the signatures for
random functions. Should that be fixed?
I've never noticed. In what way does the problem manifest?

BTW: I've just added an ebuild for Pike 8.0.10 to the pike gentoo overlay,
and it seems to install fine on at least on of my machines.
--
Henrik Grubbström ***@roxen.com
Roxen Internet Software AB
Arne Goedeke
2014-10-22 18:21:08 UTC
Permalink
Post by Henrik Grubbström
Post by Arne Goedeke
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
Also, if you have anything you really want to fix in pike 8.0, please
say something about it, or commit a fix soon.
We are currently not completely compatible with nettle 2.7, which is
what gentoo is still shipping. The problem, which has already been
discussed here, is that at some point nettle changed the signatures for
random functions. Should that be fixed?
I've never noticed. In what way does the problem manifest?
BTW: I've just added an ebuild for Pike 8.0.10 to the pike gentoo overlay,
and it seems to install fine on at least on of my machines.
The second argument of the random function was changed from unsigned int to size_t at some point (I guess in nettle 3 or so).

dsa_generate_keypair(struct dsa_public_key *pub,
/usr/include/nettle/dsa.h:200:1: note: expected 'void (*)(void *, unsigned int, uint8_t *)' but argument is of type 'void (*)(void *, size_t, uint8_t *)'
dsa_generate_keypair(struct dsa_public_key *pub,

It builds and installs fine for me, too. The code also works; I guess it doesnt matter with x86-64 calling conventions.
Arne Goedeke
2014-10-24 07:54:52 UTC
Permalink
Post by Arne Goedeke
Post by Henrik Grubbström
Post by Arne Goedeke
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
Also, if you have anything you really want to fix in pike 8.0, please
say something about it, or commit a fix soon.
We are currently not completely compatible with nettle 2.7, which is
what gentoo is still shipping. The problem, which has already been
discussed here, is that at some point nettle changed the signatures for
random functions. Should that be fixed?
I've never noticed. In what way does the problem manifest?
BTW: I've just added an ebuild for Pike 8.0.10 to the pike gentoo overlay,
and it seems to install fine on at least on of my machines.
The second argument of the random function was changed from unsigned int
to size_t at some point (I guess in nettle 3 or so).
dsa_generate_keypair(struct dsa_public_key *pub,
/usr/include/nettle/dsa.h:200:1: note: expected 'void (*)(void *,
unsigned int, uint8_t *)' but argument is of type 'void (*)(void *,
size_t, uint8_t *)'
dsa_generate_keypair(struct dsa_public_key *pub,
It builds and installs fine for me, too. The code also works; I guess it
doesnt matter with x86-64 calling conventions.
On reading the nettle git history it seems like this was part of the
same changes that pike_nettle_size_t was introduced for.
郭雪松
2014-10-25 03:04:14 UTC
Permalink
$ pike80
Pike v8.0 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
Thread.Local()->set(([]));
(1) Result: ([ ])
Thread.Local()->get();
(2) Result: 0


From: ***@hotmail.com
To: ***@laramies.com
Subject: RE: Pike 8.0 RC1
Date: Sat, 25 Oct 2014 11:02:31 +0800




Bug report:

Pike v7.9 release 11 running Hilfe v3.5 (Incremental Pike Frontend)
Thread.Local()->set(([]));
(1) Result: ([ ])
Thread.Local()->get();
(2) Result: 0
Date: Fri, 24 Oct 2014 09:54:52 +0200
Subject: Re: Pike 8.0 RC1
Post by Arne Goedeke
Post by Henrik Grubbström
Post by Arne Goedeke
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
Also, if you have anything you really want to fix in pike 8.0, please
say something about it, or commit a fix soon.
We are currently not completely compatible with nettle 2.7, which is
what gentoo is still shipping. The problem, which has already been
discussed here, is that at some point nettle changed the signatures for
random functions. Should that be fixed?
I've never noticed. In what way does the problem manifest?
BTW: I've just added an ebuild for Pike 8.0.10 to the pike gentoo
overlay,
and it seems to install fine on at least on of my machines.
The second argument of the random function was changed from unsigned int
to size_t at some point (I guess in nettle 3 or so).
dsa_generate_keypair(struct dsa_public_key *pub,
/usr/include/nettle/dsa.h:200:1: note: expected 'void (*)(void *,
unsigned int, uint8_t *)' but argument is of type 'void (*)(void *,
size_t, uint8_t *)'
dsa_generate_keypair(struct dsa_public_key *pub,
It builds and installs fine for me, too. The code also works; I guess it
doesnt matter with x86-64 calling conventions.
On reading the nettle git history it seems like this was part of the
same changes that pike_nettle_size_t was introduced for.
Chris Angelico
2014-10-25 03:20:20 UTC
Permalink
Post by 郭雪松
$ pike80
Pike v8.0 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
Thread.Local()->set(([]));
(1) Result: ([ ])
Thread.Local()->get();
(2) Result: 0
Wouldn't these be two completely separate thread-local variables? This
looks correct to me.

ChrisA
郭雪松
2014-10-25 04:56:01 UTC
Permalink
You are right. I misunderstood.
Date: Sat, 25 Oct 2014 14:20:20 +1100
Subject: Re: Pike 8.0 RC1
Post by 郭雪松
$ pike80
Pike v8.0 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
Thread.Local()->set(([]));
(1) Result: ([ ])
Thread.Local()->get();
(2) Result: 0
Wouldn't these be two completely separate thread-local variables? This
looks correct to me.
ChrisA
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) importmöte för mailinglistan
2014-10-22 20:50:01 UTC
Permalink
Nettle generates quite a lot of warnings.
Tor Edvardsson @ Pike importmöte för mailinglistan
2014-10-22 20:15:02 UTC
Permalink
Backporting of latest GTK fixes :-)

Cheers, Tor
Matt Hardy
2014-10-22 20:37:34 UTC
Permalink
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
The first release candidate for Pike 8.0 has been uploaded to the pike
site: Pike 8.0.10,
http://pike.lysator.liu.se/pub/pike/all/8.0.10/Pike-v8.0.10.tar.gz or
ftp://pike.lysator.liu.se/pub/pike/all/8.0.10/Pike-v8.0.10.tar.gz
It would be nice if you could test compile it, especially if you have
systems that do not already have pike installed. You can also feel
free to run the testsuite.
Also, if you have anything you really want to fix in pike 8.0, please
say something about it, or commit a fix soon.
--
Per Hedbor
I’ve got this fresh Yosemite OS X.
No pike compiled…

Needed to get:
GMP, lzip to get that going, gmplib.org
Nettle from https://git.lysator.liu.se/nettle/nettle

Then used make install_interactive

pike
Pike v8.0 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
Tor Edvardsson @ Pike importmöte för mailinglistan
2014-10-22 20:15:02 UTC
Permalink
Backporting of latest GTK fixes :-)

Cheers, Tor
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) importmöte för mailinglistan
2014-10-22 20:50:01 UTC
Permalink
Nettle generates quite a lot of warnings.
Mirar @ Pike importmöte för mailinglistan
2014-10-25 08:35:03 UTC
Permalink
| Making all in build/linux-3.12.22+-armv6l
| test -d include/. || mkdir include
| ./precompile.sh --cache make_interpret_functions.pike >"/home/pi/Pike-v8.0.10/src/interpret_functions_fixed.h" "/home/pi/Pike-v8.0.10/src/interpret_functions.h" || { rm "/home/pi/Pike-v8.0.10/src/interpret_functions_fixed.h"; exit 1; }
| precompile: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/master.pike /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike /home/pi/Pike-v8.0.10/src/interpret_functions.h (method=Q)
| ./precompile.sh: 135: ./precompile.sh: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/pike: not found
| precompile: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/master.pike /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike /home/pi/Pike-v8.0.10/src/interpret_functions.h (method=QQ)
| ./precompile.sh: 135: ./precompile.sh: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/tpike: not found
| precompile: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/test-pike /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike /home/pi/Pike-v8.0.10/src/interpret_functions.h (method=QQQ)
| ./precompile.sh: 135: ./precompile.sh: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/test-pike: not found
| precompile: pike /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike /home/pi/Pike-v8.0.10/src/interpret_functions.h (method=QQQQQQ)
| ./precompile.sh: 135: ./precompile.sh: pike: not found
| precompile: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/master.pike /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike /home/pi/Pike-v8.0.10/src/interpret_functions.h (method=Q)
| ./precompile.sh: 135: ./precompile.sh: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/pike: not found
| precompile: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/master.pike /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike /home/pi/Pike-v8.0.10/src/interpret_functions.h (method=QQ)
| ./precompile.sh: 135: ./precompile.sh: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/tpike: not found
| precompile: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/test-pike /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike /home/pi/Pike-v8.0.10/src/interpret_functions.h (method=QQQ)
| ./precompile.sh: 135: ./precompile.sh: /home/pi/Pike-v8.0.10/build/linux-3.12.22+-armv6l/test-pike: not found
| precompile: pike /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike /home/pi/Pike-v8.0.10/src/interpret_functions.h (method=QQQQQQ)
| ./precompile.sh: 135: ./precompile.sh: pike: not found
| Failed to find a Pike executable that could run /home/pi/Pike-v8.0.10/bin/make_interpret_functions.pike.
| make[3]: *** [/home/pi/Pike-v8.0.10/src/interpret_functions_fixed.h] Error 1
| make[2]: *** [module_objects] Error 2
| make[1]: *** [_make_in_builddir] Error 2
| make: *** [compile] Error 2

So, well...
郭雪松
2014-10-26 05:17:50 UTC
Permalink
About #( #[ #{. Supporting only three level nesting is not professional, and not likely pike-style.

If we want to support code in code in code things, we should create a plan to support infinite nesting.

About '?:' . Is it just equal to '||' ? if so, why should we added this? We cannot be compatible with every C-like languages. Why should we be compatible with a special one?

Just wish Pike to be better and better.
Chris Angelico
2014-10-26 05:32:46 UTC
Permalink
Post by 郭雪松
About #( #[ #{. Supporting only three level nesting is not professional, and
not likely pike-style.
Python has just two, ''' ''' and """ """. Pike goes one further. :)

ChrisA
Mirar @ Pike importmöte för mailinglistan
2014-10-26 14:20:01 UTC
Permalink
I've never seen #{ etc, where/when are those used?
Post by 郭雪松
About '?:' . Is it just equal to '||' ? if so, why should we added
this? We cannot be compatible with every C-like languages. Why
should we be compatible with a special one?
?: is not equal to || and it has been in Pike since µLPC (1993 or so).
郭雪松
2014-10-26 14:36:57 UTC
Permalink
The CHANGES file:

o Added new syntax for literal-string constants

#{, #( and #[ starts a literal string, and it is ended by the
corresponding end marker: #}, #) and #] respectively.

No character is modified at all inside the literal string, including
newlines, \ " and '.

So, the string #["\n\'##] will be equivalent to "\"\\n\\'#".

The main use-case is to write code in code:

| string code = #[
| void main(int c, array v) {
| string x = "";
| foreach( v[1..], string elm )
| x += reverse(elm)+",";
| write("Testing: %s\n", reverse( x ));
| #];

The three different start/end markers might be useful if you write
code in code in code, since there is no way to quote the start/end
markers.

o Added the '?:' operator for compatibility with other C-like
languages. It is identical to '||' in pike.
Post by 郭雪松
Subject: RE: Pike 8.0 RC1
Date: Sun, 26 Oct 2014 14:20:01 +0000
I've never seen #{ etc, where/when are those used?
Post by 郭雪松
About '?:' . Is it just equal to '||' ? if so, why should we added
this? We cannot be compatible with every C-like languages. Why
should we be compatible with a special one?
?: is not equal to || and it has been in Pike since µLPC (1993 or so).
I think it's not a same '?:' we talked about.
郭雪松
2014-10-26 14:49:48 UTC
Permalink
I am pretty sure that there is some bug in Process.run().

Sometimes, the returned value ->stdout is "", but it should not be.
I cannot yet reproduct this bug, buy I know it is there.

Process.pmod in Pike 7.8 is ok.

Just be ware of it.

From: ***@hotmail.com
To: ***@lyskom.lysator.liu.se; ***@roxen.com
Subject: RE: Pike 8.0 RC1
Date: Sun, 26 Oct 2014 22:36:57 +0800




The CHANGES file:

o Added new syntax for literal-string constants

#{, #( and #[ starts a literal string, and it is ended by the
corresponding end marker: #}, #) and #] respectively.

No character is modified at all inside the literal string, including
newlines, \ " and '.

So, the string #["\n\'##] will be equivalent to "\"\\n\\'#".

The main use-case is to write code in code:

| string code = #[
| void main(int c, array v) {
| string x = "";
| foreach( v[1..], string elm )
| x += reverse(elm)+",";
| write("Testing: %s\n", reverse( x ));
| #];

The three different start/end markers might be useful if you write
code in code in code, since there is no way to quote the start/end
markers.

o Added the '?:' operator for compatibility with other C-like
languages. It is identical to '||' in pike.
Post by 郭雪松
Subject: RE: Pike 8.0 RC1
Date: Sun, 26 Oct 2014 14:20:01 +0000
I've never seen #{ etc, where/when are those used?
Post by 郭雪松
About '?:' . Is it just equal to '||' ? if so, why should we added
this? We cannot be compatible with every C-like languages. Why
should we be compatible with a special one?
?: is not equal to || and it has been in Pike since µLPC (1993 or so).
I think it's not a same '?:' we talked about.
Stephen R. van den Berg
2014-10-28 08:18:24 UTC
Permalink
Post by 郭雪松
o Added new syntax for literal-string constants
#{, #( and #[ starts a literal string, and it is ended by the corresponding
end marker: #}, #) and #] respectively.
I agree that it's a pity that this way you only have three fixed ones.
SQL solved this differently.

I'd indeed suggest that the SQL way is more elegant. It would amount
to something like the following Pike equivalent:

#{ is terminated by #}
#abc{ is terminated by #abc}

etc. All other rules stay the same. It will support unlimited nesting.
Supporting #( and #[ as well is in a similar manner of course is possible.
Post by 郭雪松
o Added the '?:' operator for compatibility with other C-like languages. It
is identical to '||' in pike.
I guess a?:b is shorthand for a?a:b. I'm curious though, which languages
already have it? I tried to google for it, but that turnes out to be
difficult.
--
Stephen.
Chris Angelico
2014-10-28 08:28:24 UTC
Permalink
Post by Stephen R. van den Berg
Post by 郭雪松
o Added new syntax for literal-string constants
#{, #( and #[ starts a literal string, and it is ended by the corresponding
end marker: #}, #) and #] respectively.
I agree that it's a pity that this way you only have three fixed ones.
SQL solved this differently.
I'd indeed suggest that the SQL way is more elegant. It would amount
#{ is terminated by #}
#abc{ is terminated by #abc}
etc. All other rules stay the same. It will support unlimited nesting.
Supporting #( and #[ as well is in a similar manner of course is possible.
Presumably anything that's actually a preprocessor command would be
illegal for that - it'd be awkward if you go #string{ #string}.

The question is, do we actually need more than three? Is the
flexibility all that useful?
Post by Stephen R. van den Berg
Post by 郭雪松
o Added the '?:' operator for compatibility with other C-like languages. It
is identical to '||' in pike.
I guess a?:b is shorthand for a?a:b. I'm curious though, which languages
already have it? I tried to google for it, but that turnes out to be
difficult.
Yes, it is. It's a GCC extension:

http://scottmoonen.com/2008/05/27/gcc-binary-conditional/

Googled that as "binary question colon", not one of the most common
search terms I am sure!

ChrisA
Stephen R. van den Berg
2014-10-28 08:34:18 UTC
Permalink
Post by Chris Angelico
Post by Stephen R. van den Berg
#{ is terminated by #}
#abc{ is terminated by #abc}
etc. All other rules stay the same. It will support unlimited nesting.
Supporting #( and #[ as well is in a similar manner of course is possible.
Presumably anything that's actually a preprocessor command would be
illegal for that - it'd be awkward if you go #string{ #string}.
The question is, do we actually need more than three? Is the
flexibility all that useful?
I don't have a strong opinion here. I rarely need(ed) something like this.
So to avoid unnecessary code bloat, you might be right.
--
Stephen.
Chris Angelico
2014-10-28 08:53:34 UTC
Permalink
Post by Mirar @ Pike importmöte för mailinglistan
Post by Chris Angelico
Post by Stephen R. van den Berg
#{ is terminated by #}
#abc{ is terminated by #abc}
Presumably anything that's actually a preprocessor command would be
illegal for that - it'd be awkward if you go #string{ #string}.
I like this idea but I think #something{ is a bit tricky. Probably
better to have #[something]{ or similar to differentiate from
#preprocessor directives.
Yeah, for precisely the same ambiguity I was worrying about. But the
more verbiage is included, the less useful it'll be. I do like the
idea of a raw string literal - one that doesn't need all its
backslashes escaped - but I don't expect to be nesting them more than
three deep.

ChrisA
Stephen R. van den Berg
2014-10-28 09:00:01 UTC
Permalink
Post by Chris Angelico
Yeah, for precisely the same ambiguity I was worrying about. But the
more verbiage is included, the less useful it'll be. I do like the
idea of a raw string literal - one that doesn't need all its
backslashes escaped - but I don't expect to be nesting them more than
three deep.
I don't think that will detract from its usefulness. The requirement is that
the delimiter is unique, accomplishing that using delimiters that have to
adhere to a certain syntax does not limit that in any significant way.
--
Stephen.
Chris Angelico
2014-10-28 09:06:44 UTC
Permalink
Post by Stephen R. van den Berg
Post by Chris Angelico
Yeah, for precisely the same ambiguity I was worrying about. But the
more verbiage is included, the less useful it'll be. I do like the
idea of a raw string literal - one that doesn't need all its
backslashes escaped - but I don't expect to be nesting them more than
three deep.
I don't think that will detract from its usefulness. The requirement is that
the delimiter is unique, accomplishing that using delimiters that have to
adhere to a certain syntax does not limit that in any significant way.
Right, but I'm happy with #{ #[ #( triple nesting #) #] #} rather than
#[x]{ #[y]{ unlimited nesting #[y]} #[x]} - the former is sufficiently
clean to be useful, the latter feels noisy and heavy. The #x{ #y{
potentially-ambiguous syntax #y} #x} is somewhere in between.

ChrisA
Martin Bähr
2014-10-28 09:23:42 UTC
Permalink
for something not feeling heavy, how about this:
#" "
#"" ""
#""" """

#" first #"" second #""" third level """ level "" level "

allows for unlimited nesting,
makes nesting level visible (although presumably that would not be enforced
(#""" #" " """ should be ok))
#""" """ looks similar to pythons """ """

#"" "" could become a primary choice to avoid having to escape " inside.

greetings, martin.
--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
BLUG secretary beijinglug.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/
Chris Angelico
2014-10-28 09:26:12 UTC
Permalink
On Tue, Oct 28, 2014 at 8:23 PM, Martin Bähr
Post by Martin Bähr
#" "
#"" ""
#""" """
#"" is currently a legal (if pointless) way to write an empty string.
That would have to be special-cased away.

ChrisA
Martin Bähr
2014-10-28 09:32:34 UTC
Permalink
Post by Martin Bähr
#" first #"" second #""" third level """ level "" level "
for chris application of writing partial code snippets this example wouldn't
work, but reversing the nesting order should:

#""" outer #"" middle """
#""" #" inner """
#""" close inner" """
#""" close middle"" """

greetings, martin.
--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
BLUG secretary beijinglug.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/
Martin Bähr
2014-10-28 09:02:05 UTC
Permalink
Post by Chris Angelico
Post by 郭雪松
#{, #( and #[ starts a literal string, and it is ended by the corresponding
end marker: #}, #) and #] respectively.
The question is, do we actually need more than three? Is the
flexibility all that useful?
i can't even imagine how code that uses 3 levels would look like.
anyone with an example of why one would need/want to do that?

as for multilevel syntax, with a unique opening and closing tag,
isn't that enough to identify proper nesting?

#{ first #{ second #{ third level #} level #} level #}

alternatively what about
#{tag{ #}tag}
#{tag} #{/tag}
#<tag> #</tag> (ok, that one may cause problems quoting html)

greetings, martin.
--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
BLUG secretary beijinglug.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/
Chris Angelico
2014-10-28 09:17:28 UTC
Permalink
On Tue, Oct 28, 2014 at 8:02 PM, Martin Bähr
Post by Martin Bähr
as for multilevel syntax, with a unique opening and closing tag,
isn't that enough to identify proper nesting?
Only if you're embedding the entire thing in a single string. If
you're making a program that writes code in pieces, you might want to
have something like this:

file->write(#{
write(#[
blah blah
#});
// ...
file->write(#{
blah blah
#]);
#});

This should produce this in the output file:
write(#[
blah blah
blah blah
#]);

But it needs to write "mis-nested" quote characters, with their
nesting cleaned up by concatenation.

ChrisA
Chris Angelico
2014-10-28 09:27:29 UTC
Permalink
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
Well, that should work perfectly right now, since there is no nesting
of the same characters involved there.
Right, but Martin's proposal of #{ #{ #} #} wouldn't work with that.

ChrisA
郭雪松
2014-11-03 07:22:01 UTC
Permalink
Safe index is nice, but if adding a ?(), it would be more useful.
X?(ARGS) should be eauivalent to ((auto _ = X),(_ && _(ARGS)))

o "Safe" index

Copied from a popular extension to other C-like languages.

X[?ind] is equivalent to ((auto _ = X),(_ && _[ind]))
while X?->ind is equivalent to ((auto _ = X),(_ && _->ind))

The main use is 'deep indexing' where some elements can be 0:

| request_id?->user?->misc?->x

vs

| request_id && request_id->user && request_id->user->misc
| && request_id->user->misc->x
Mirar @ Pike importmöte för mailinglistan
2014-10-28 08:35:02 UTC
Permalink
Any new version that might work better around?
Mirar @ Pike importmöte för mailinglistan
2014-10-28 08:35:02 UTC
Permalink
It makes a lot more sense in C, but yes in Pike that would be
equivalent to ||. In C || gives 0 or 1. I'm for being
gcc-extension-compatible when it makes sense though.
Mirar @ Pike importmöte för mailinglistan
2014-10-28 08:40:02 UTC
Permalink
Post by Chris Angelico
Post by Stephen R. van den Berg
#{ is terminated by #}
#abc{ is terminated by #abc}
Presumably anything that's actually a preprocessor command would be
illegal for that - it'd be awkward if you go #string{ #string}.
I like this idea but I think #something{ is a bit tricky. Probably
better to have #[something]{ or similar to differentiate from
#preprocessor directives.
Per Hedbor () @ Pike (-) importmöte för mailinglistan
2014-10-28 09:25:02 UTC
Permalink
Post by Chris Angelico
file->write(#{
write(#[
blah blah
#});
// ...
file->write(#{
blah blah
#]);
#});
write(#[
blah blah
blah blah
#]);
But it needs to write "mis-nested" quote characters, with their
nesting cleaned up by concatenation.
Well, that should work perfectly right now, since there is no nesting
of the same characters involved there.

The entire implementation can be found in the preprocessor, it is
fairly trivial code if you want to extend it to support nesting.
--
Per Hedbor
Mirar @ Pike importmöte för mailinglistan
2014-10-28 09:50:02 UTC
Permalink
Post by Stephen R. van den Berg
I don't think that will detract from its usefulness. The requirement is that
the delimiter is unique, accomplishing that using delimiters that have to
adhere to a certain syntax does not limit that in any significant way.
MIME for mail markup have a similar scheme where a huge random number
is used.
Mirar @ Pike importmöte för mailinglistan
2014-10-28 09:55:02 UTC
Permalink
I presume all this is for some sort of auto-generated code anyway, or
it's easy enough to break up manually - or to use #string or #" - and
the solution we're looking for is encapsualting unknown code.

A #[auto-generated random string]{ would solve that problem.

I have never encountered the problem this is trying to solve, but I
like solutions that work for everything if you're going to work on
them anyway... :)
Per Hedbor () @ Pike (-) importmöte för mailinglistan
2014-10-28 13:25:01 UTC
Permalink
Post by Mirar @ Pike importmöte för mailinglistan
Any new version that might work better around?
Not really, no. The thing is, the files seems to have correct
timestamps, so there should be no need to re-generate the
interpret_functions file.

Ω leopard$ ls -l interpret_functions*
91 -rw-rw-r-- 1 per per 92635 okt 20 15:51 interpret_functions_fixed.h
89 -rw-rw-r-- 1 per per 90090 okt 20 14:44 interpret_functions.h

I really have no idea why it is regenerating them. :(
--
Per Hedbor
Per Hedbor () @ Pike (-) importmöte för mailinglistan
2014-10-28 13:35:01 UTC
Permalink
Post by Mirar @ Pike importmöte för mailinglistan
It makes a lot more sense in C, but yes in Pike that would be
equivalent to ||. In C || gives 0 or 1. I'm for being
gcc-extension-compatible when it makes sense though.
It is called the 'Elvis operator' for unclear reasons. Anyway,
searching for it gives some more details.

It is frequently used in PHP, which might be why it came up at Opera.

C#, perl6 and swift has ??, which works much like || (or ?:) in pike,
but only checks for null (not general false).

In lua and javascript you can, much like in pike, use the or operator.

(Perl6 has replaced A?B:C with A??B!!C for reasons that are not clear
to me.)

(I also found out that PHP, of course, is slightly different from all
other languages when it comes to ?:, it binds ?: as the /highest/
instead of the /lowest/ priority operator "due to an unfortunate error
in the grammar file").
--
Per Hedbor
Stephen R. van den Berg
2014-10-28 13:38:50 UTC
Permalink
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
(I also found out that PHP, of course, is slightly different from all
other languages when it comes to ?:, it binds ?: as the /highest/
instead of the /lowest/ priority operator "due to an unfortunate error
in the grammar file").
The entire PHP "language" strikes me as an unfortunate error; it merely
proves that PHP lives up to its reputation.
--
Stephen.
Martin Bähr
2014-10-28 16:14:00 UTC
Permalink
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
(Perl6 has replaced A?B:C with A??B!!C for reasons that are not clear
to me.)
i was curious, so i went to #perl6 and asked. straight from the horses mouth,
that is larry wall himself:

TimToady:#perl6: C wasted two perfectly good characters on a single operator that can
be better put to use composing other characters
TimToady:#perl6: er, operators
TimToady:#perl6: (or as themselves, like we use : for invocant separator)
TimToady:#perl6: that reduces the ambiguity
TimToady:#perl6: in addition, ? and : are almost invisible as control flow, ?? and !!
stand out much more visually
TimToady:#perl6: third, all the other "thunky" operatory like && and || and doubled,
so this one is too
PerlJam:#perl6: eMBee: plus !! is more evocative of "notness" for the false side of
the ternary
TimToady:#perl6: fourth, :: is used elsewhere, so we switched to !!
TimToady:#perl6: fifth, what PerlJam said
gtodd:#perl6: plus !! suggests to me something was not happening
gtodd:#perl6: oh yeah
TimToady:#perl6: we use ? and ! lots of places in Perl 6 for true/false, so this fits
right in

http://irclog.perlgeek.de/perl6/2014-10-28#i_9577219

greetings, martin.
--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
BLUG secretary beijinglug.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/
Per Hedbor () @ Pike (-) importmöte för mailinglistan
2014-10-28 13:40:02 UTC
Permalink
Post by Mirar @ Pike importmöte för mailinglistan
I like this idea but I think #something{ is a bit tricky. Probably
better to have #[something]{ or similar to differentiate from
#preprocessor directives.
I think it is not really needed, if we just allow nesting of the other
quotes.

That is, allow #{ #{#} #} (equal to " #{#} ").

Then it only matters if you have more than tree different unbalances
chunks of code to output nested in each other.

I thing that most likely will be a rather rare occurence.
--
Per Hedbor
郭雪松
2014-10-28 16:09:20 UTC
Permalink
I worked on something allow embedding C code in Pike several years ago.
So that, when I need calling a C lib, I don't need to write a CMOD.
Following is a example to call iconv, notic C{ and P{ :

$ cat iconv.pmod
#pike __REAL_VERSION__


//! Call iconv(3) to perform character set conversion
//! @param from
//! Encoding convert characters from.
//! @param to
//! Encoding cconvert characters to.
//! @param s
//! String to be converted.
//! @returns
//! String converted.
//!
//! @note
//! More info see iconv manpage.
string `()(string from,string to,string s,void|int ignore_error)
{
//werror("enter iconv %s %s %O\n",from,to,s);

if(s==0)
return 0;
if(!stringp(s))
throw(({"ERROR: bad input\n",backtrace()}));

Cross.CC("gcc -g -shared -fPIC");
Cross.INCLUDE(
"#include <iconv.h>\n"
"#include <errno.h>\n"
"#include <string.h>\n" );


string err;
string res="";
C{
iconv_t cd=iconv_open(STRING{to},STRING{from});
if(cd==(iconv_t)-1){
P{err=sprintf("iconv: Can't convert (iconv_open fail): %s (%s -> %s)",s,from,to);}
return;
}else{
size_t insize=strlen(STRING{s});
char* inbuf=STRING{s};
char buffer[1025];
while(insize){
char* outbuf=buffer;
size_t outsize=1024;
size_t n=iconv(cd,&inbuf,&insize,&outbuf,&outsize);
if(n==-1&&errno!=E2BIG){
iconv_close(cd);
P{err=sprintf("iconv: Can't convert (%s): %s (%s -> %s)",STRING{strerror(errno)},s,from,to);}
return;
}

*outbuf='\0';
char* p=buffer;
P{ res+=STRING{p}; }
}
iconv_close(cd);
}
}

if(!err)
return res;
else{
if(ignore_error)
return res;
throw(({sprintf("ERROR: %s\n",err),backtrace()}));
}
}

The codes inside C{ ... } is actually a literal-string, P{ ... } inside it,
and there maybe more C{ ... } inside P{ ... } and forever.

I hacked into Pike's cpp code to implement it, using Parser.Pike, take out the things
inside C{} or P{}, and reconstruct the code.
Post by Chris Angelico
The question is, do we actually need more than three? Is the
flexibility all that useful?
ChrisA
I don't, I hack into Pike, but if it exist, maybe help.
Post by Chris Angelico
Post by Martin Bähr
i can't even imagine how code that uses 3 levels would look like.
anyone with an example of why one would need/want to do that?
Martin BÀhr
Only if you're embedding the entire thing in a single string.
ChrisA
When you do code embedding like me, you will found that you don't like #( #{ #[ things.
Because we do copy-paste. A block quoted by #( ... #) may be copyed and pasted into a
block quoted by #( ... #) too, or by #( ... #[ ... #] ...#). If so, the inside #) terminated outter #( .
Post by Chris Angelico
Post by Martin Bähr
But it needs to write "mis-nested" quote characters, with their
nesting cleaned up by concatenation.
Well, that should work perfectly right now, since there is no nesting
of the same characters involved there.
Per Hedbor
I presume all this is for some sort of auto-generated code anyway, or
it's easy enough to break up manually - or to use #string or #" - and
the solution we're looking for is encapsualting unknown code.
Mirar
Don't worry about auto-generated code. If auto-generated, it's easy to auto-quoted.
Human writing matters.
Post by Chris Angelico
I think it is not really needed, if we just allow nesting of the other
quotes.
That is, allow #{ #{#} #} (equal to " #{#} ").
Then it only matters if you have more than tree different unbalances
chunks of code to output nested in each other.
I thing that most likely will be a rather rare occurence.
Per Hedbor
I like this idea.
Mirar @ Pike importmöte för mailinglistan
2014-10-28 13:50:01 UTC
Permalink
It immediately starts with:

| $ make 2>&1 | tee makelog2
|
| Configure arguments:
| Use `make CONFIGUREARGS="..." ...' to change them.
| They will be retained in the build directory.
|
| Making all in build/linux-3.12.22+-armv6l
| ./precompile.sh --cache make_interpret_functions.pike >"/home/pi/Pike-v8.0.10/src/interpret_functions_fixed.h" "/home/pi/Pike-v8.0.10/src/interpret_functions.h" || { rm "/home/pi/Pike-v8.0.10/src/interpret_functions_fixed.h"; exit 1; }
| /bin/sh: 1: cannot create /home/pi/Pike-v8.0.10/src/interpret_functions_fixed.h: Permission denied
| rm: remove write-protected regular file `/home/pi/Pike-v8.0.10/src/interpret_functions_fixed.h'?

(I put chattr +i on it.)
Mirar @ Pike importmöte för mailinglistan
2014-10-28 13:50:01 UTC
Permalink
$(SRCDIR)/interpret_functions_fixed.h: $(SRCDIR)/interpret_functions.h precompile.sh-stamp
./precompile.sh --cache make_interpret_functions.pike >"$@" "$(SRCDIR)/interpret_functions.h" || { rm "$@"; exit 1; }

maybe precompile-sh.stamp isn't in the archive?
Mirar @ Pike importmöte för mailinglistan
2014-10-28 13:55:02 UTC
Permalink
That seems to be the problem.
Magnus Holmgren, Millnet/Lysator/Debian/Mensa @ Pike importmöte för mailinglistan
2014-10-28 14:35:01 UTC
Permalink
It seems to be related to the issue I reported on 3 August: The touch
command on line 1360 (as of then) of src/Makefile.in uses an obsolete
syntax. Try this:

--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -1357,7 +1357,7 @@ precompile.sh: $(SRCDIR)/precompile.sh.i
# recursive use of make.
precompile.sh-stamp:
@if [ -f precompile.sh ]; then :; else $(MAKE) precompile.sh; fi
- @touch 0101010185 precompile.sh-stamp 2>/dev/null
+ @touch -t 198501010101 precompile.sh-stamp 2>/dev/null

$(SRCDIR)/machine.h.in: $(SRCDIR)/stamp-h.in
@if test -f $(SRCDIR)/machine.h.in; then :; else \
Magnus Holmgren, Millnet/Lysator/Debian/Mensa @ Pike importmöte för mailinglistan
2014-10-28 14:40:02 UTC
Permalink
(See if a file called "0101010185" has been created in src/.)
Mirar @ Pike importmöte för mailinglistan
2014-10-28 15:55:02 UTC
Permalink
Not in src, but:

$ find -name *0101*
./build/linux-3.12.22+-armv6l/0101010185
Mirar @ Pike importmöte för mailinglistan
2014-10-28 15:55:02 UTC
Permalink
Except that quirk, it built fine on a Pi.
Per Hedbor () @ Pike (-) importmöte för mailinglistan
2014-11-03 09:40:01 UTC
Permalink
Post by 郭雪松
Safe index is nice, but if adding a ?(), it would be more useful.
X?(ARGS) should be eauivalent to ((auto _ = X),(_ && _(ARGS)))
Yes, I agree. The major issue is that this conflicts (somewhat) with
the ?: syntax (this is also the reason for the lack of a .? operator).

As an example: a?(float)a:42.0
Martin Bähr
2014-11-28 08:10:12 UTC
Permalink
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
Post by 郭雪松
Safe index is nice, but if adding a ?(), it would be more useful.
X?(ARGS) should be eauivalent to ((auto _ = X),(_ && _(ARGS)))
Yes, I agree. The major issue is that this conflicts (somewhat) with
the ?: syntax (this is also the reason for the lack of a .? operator).
As an example: a?(float)a:42.0
i just discovered that coffeescript has this feature. pity about the conflict.

alternatives?

foo??(bar);
foo(?bar);

greetings, martin.
--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
BLUG secretary beijinglug.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/
Tor Edvardsson @ Pike importmöte för mailinglistan
2014-11-09 11:15:02 UTC
Permalink
Maybe this new syntax could be used for string templating. Does pike support HERE-doc like in bash or php?

/ Tor
Stephen R. van den Berg
2014-11-10 13:43:00 UTC
Permalink
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
The first release candidate for Pike 8.0 has been uploaded to the pike
site: Pike 8.0.10,
I noticed that the docs from Stdio.Buffer don't make it into the
standard generated list. I'm not quite sure how to fix that, so I'll
let someone more knowledgeable about the doc-generator step in :-).
--
Stephen.
Stephen R. van den Berg
2014-11-10 13:52:21 UTC
Permalink
Post by Stephen R. van den Berg
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
The first release candidate for Pike 8.0 has been uploaded to the pike
site: Pike 8.0.10,
I noticed that the docs from Stdio.Buffer don't make it into the
standard generated list. I'm not quite sure how to fix that, so I'll
let someone more knowledgeable about the doc-generator step in :-).
Ah well. Turns out I messed it up myself. Didn't know the parser
needs everything on a single line. Fixed. Sorry for the noise.
--
Stephen.
郭雪松
2014-11-15 23:50:20 UTC
Permalink
new operator feature sugest:

("cut left example"<<" ")=="left example"
("cut left example">>"ex")=="cut left "

Guo Xue Song
Stephen R. van den Berg
2014-11-26 12:53:44 UTC
Permalink
Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
The first release candidate for Pike 8.0 has been uploaded to the pike
site: Pike 8.0.10,
Well, I'm not sure where we are with the 8.0 release, but in case
you were waiting for me/pgsql, the driver has been blessed now :-).
As a reference point, I've been running Pike 8.0 in some production
Roxen systems since the past few weeks, and things seem to be running smoothly
by now (both on the Pike and the pgsql front).
--
Stephen.
Mirar @ Pike importmöte för mailinglistan
2014-11-28 09:05:01 UTC
Permalink
Didn't Pike (µlpc, LPC) originally allow 0() with a result of 0, so
that "/some/object"->do_something() didn't generate an error in case
the object didn't have the function?

(Sorry about the historic note.)
Henrik Grubbström (Lysator) @ Pike (-) importmöte för mailinglistan
2014-11-28 09:20:01 UTC
Permalink
Post by Mirar @ Pike importmöte för mailinglistan
Didn't Pike (µlpc, LPC) originally allow 0() with a result of 0, so
that "/some/object"->do_something() didn't generate an error in case
the object didn't have the function?
Correct in both cases. From µLPC 1.0E-30 src/interpret.c:

| void apply_shared(struct object *o,
| struct lpc_string *fun,
| int args)
| {
| int fun_number;
| fun_number = find_shared_string_identifier(fun, o->prog);
| if(fun_number < 0)
| {
| pop_n_elems(args);
| sp++;
| sp->u.integer=0;
| sp->type=T_INT;
| }else{
| apply_low(o, fun_number, args);
| }
| }
|
| void apply(struct object *o, char *fun, int args)
| {
| int fun_number;
|
| fun_number = find_identifier(fun, o->prog);
| if(fun_number < 0)
| {
| pop_n_elems(args);
| sp->u.integer=0;
| sp->type=T_INT;
| sp++;
| }else{
| apply_low(o, fun_number, args);
| }
| }
[...]
| void apply_svalue(struct svalue *s, INT32 args)
| {
| if(s->type==T_INT)
| {
| pop_n_elems(args);
| push_int(0);
| }else{
| strict_apply_svalue(s,args);
| }
| }
Post by Mirar @ Pike importmöte för mailinglistan
(Sorry about the historic note.)
No problem :-)
Mirar @ Pike importmöte för mailinglistan
2014-11-28 09:30:02 UTC
Permalink
When did that vanish?
Henrik Grubbström (Lysator) @ Pike (-) importmöte för mailinglistan
2014-11-28 10:30:02 UTC
Permalink
Post by Mirar @ Pike importmöte för mailinglistan
When did that vanish?
Calling of a nonexisting function was made an error in the following commit:

| commit 7b0d86091ab216956cf1002e733d75e17e519cd1
| Author: Martin Stjernholm <***@lysator.liu.se>
| Date: Wed Jul 30 20:50:10 2003 +0200
|
| Fixed misguided fault tolerance.

Interesting; the low level function apply_svalue() still exists and
allows calling of integers, but it is not used for Pike code, which
instead uses mega_apply(APPLY_SVALUE, ...), which seems to never have
allowed calling of integers.

Note also that f_call_function() in µLPC 1.0E-30 didn't allow
calling of integers, and generated the error "Call to non-function value.".
Stephen R. van den Berg
2014-11-28 12:49:31 UTC
Permalink
Post by Henrik Grubbström (Lysator) @ Pike (-) importmöte för mailinglistan
| commit 7b0d86091ab216956cf1002e733d75e17e519cd1
| Date: Wed Jul 30 20:50:10 2003 +0200
|
| Fixed misguided fault tolerance.
Talking about mast, what happened to him, did Google lock him up
in the dungeon of the London tower?
--
Stephen.
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) importmöte för mailinglistan
2014-11-28 13:50:01 UTC
Permalink
Post by Stephen R. van den Berg
Talking about mast, what happened to him, did Google lock him up
in the dungeon of the London tower?
Yes.
Marcus Agehall (nu med K-märkt fastighet och ny elcentral) @ Pike (-) importmöte för mailinglistan
2014-12-03 16:20:02 UTC
Permalink
He is still alive though. Occationally, he asks to meet up when he
visits Stockholm...

Loading...