pike issueshttps://git.lysator.liu.se/pikelang/pike/-/issues2024-03-28T07:18:57Zhttps://git.lysator.liu.se/pikelang/pike/-/issues/10146Add support for generic types.2024-03-28T07:18:57ZHenrik (Grubba) GrubbströmAdd support for generic types.Suggested syntax:
```
class Foo (<protected __unknown__ T = mixed>) (T val)
{
...
}
```
**REJECTED**: Due to confusion about semantics the support for modifiers has been rejected, and the type restriction been inverted:
```
class F...Suggested syntax:
```
class Foo (<protected __unknown__ T = mixed>) (T val)
{
...
}
```
**REJECTED**: Due to confusion about semantics the support for modifiers has been rejected, and the type restriction been inverted:
```
class Foo (<mixed T = mixed>) (T val)
{
...
}
```
**IMPLEMENTED**
For top-level classes the following syntax should be sufficient:
```
inherit class (<protected __unknown__ T = mixed>) (T val) {};
```
**REJECTED**: The above complicates inherit semantics and implementation. It is also a syntax that `Tools.AutoDoc.PikeParser` does not like.
Alternative syntax (note that declaration order is significant, or that all generics must be specified in the same statement):
```
__generic__ mixed T = mixed;
```
**IMPLEMENTED**
Binding the generic type:
```
Foo(<string>) foo_string = Foo(<string>)("FOO");
```
**IMPLEMENTED**
Consider also:
```
// Inherit Foo with T set to string.
inherit Foo(<string>);
```
**IMPLEMENTED**
```
// Inherit Foo with T set to the default value (ie mixed).
inherit Foo(<>);
```
**IMPLEMENTED**
**NOTE**: This has identical semantics to:
```
// Inherit Foo with any generics set to their default values.
inherit Foo;
```
**IMPLEMENTED**Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10144Add language extensions for asynchronous functions.2024-03-25T10:21:11ZHenrik (Grubba) GrubbströmAdd language extensions for asynchronous functions.Co-routines are making a comeback in programming languages lately. We probably ought to follow the trend.
Suggestion:
* Change the behavior of calling a generator function concurrently:
* Register the generator argument and callback....Co-routines are making a comeback in programming languages lately. We probably ought to follow the trend.
Suggestion:
* Change the behavior of calling a generator function concurrently:
* Register the generator argument and callback.
* Have `yield()` complete with the above value(s) rather than suspending execution.
This solves issues where the generator callback gets called before `yield()` is reached.
* Add a new modifier `__async__` for functions:
```
__async__ int foo(mixed ...)
{
return 17;
}
```
Which would be similar to:
```
Concurrent.Future /*(int)*/ foo(mixed...)
{
Concurrent.Promise __async_promise__ = Concurrent.Promise();
__generator__ foo_generator()
{
__async_promise__->failure(catch {
__async_promise__->success(17);
return UNDEFINED;
});
return UNDEFINED;
}
foo_generator()();
return __async_promise__->future();
}
```
* Add special form `await(Concurrent.Future f)`:
```
__async__ int foo(Concurrent.Future f)
{
mixed q = await(f);
}
```
Which would be similar to:
```
__async__ int foo(Concurrent.Future f)
{
f->on_await(continue::this_function);
mixed q = yield(UNDEFINED);
}
```
Where `on_await` would be implemented similar to:
```
this_program on_await(function f)
{
return on_success(f)->on_failure(f, throw);
}
```Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10061Add Stdio.File()->accessat() and extend predef::access() to support EUID checks2021-03-12T11:50:37ZHenrik (Grubba) GrubbströmAdd Stdio.File()->accessat() and extend predef::access() to support EUID checks`predef::access()` performs access control with the *real* uid and gid.
Sometimes you want to perform the corresponding checks, but for the *effective* uid and gid.
The `predef::access()` euid checks may be implemented with `eaccess(2/...`predef::access()` performs access control with the *real* uid and gid.
Sometimes you want to perform the corresponding checks, but for the *effective* uid and gid.
The `predef::access()` euid checks may be implemented with `eaccess(2/3)`, `eiudaccess(3)` or `faccessat(2)`, or emulated via calling of `test(1)` with suitable arguments, and should be selected via a third argument containing the character `"e"`. A suitable detection flag should also be added.
`Stdio.File()->accessat()` should be implemented with `faccessat()`. An availability flag `Stdio.__HAVE_ACCESSAT__` with a value of `1` should also be added when `Stdio.File()->accessat()` is available. The symlinks mode of `faccessat(2)` should be selectable via the third argument containing the character `"l"`.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10060Add support for STARTTLS (RFC 3207) and Implicit TLS (RFC 8314) to Protocols....2021-03-05T16:22:12ZHenrik (Grubba) GrubbströmAdd support for STARTTLS (RFC 3207) and Implicit TLS (RFC 8314) to Protocols.SMTP.ClientSome MSA's require submitted messages to be over TLS.
Implement support for RFC 3207 and RFC 8314 to solve this.Some MSA's require submitted messages to be over TLS.
Implement support for RFC 3207 and RFC 8314 to solve this.Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10032Implement support for DTLS2020-04-16T14:41:08ZHenrik (Grubba) GrubbströmImplement support for DTLSDTLS is essentially TLS over UDP.
Extend the SSL module with a class analogous to `Stdio.UDP`.DTLS is essentially TLS over UDP.
Extend the SSL module with a class analogous to `Stdio.UDP`.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10031Implement support for TLS 1.32022-08-28T22:32:57ZHenrik (Grubba) GrubbströmImplement support for TLS 1.3TLS 1.3 has been released for some time now. Extend the SSL module to support it.TLS 1.3 has been released for some time now. Extend the SSL module to support it.Pike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/8016The Inotify accelerated filesystem monitor may lose acceleration in some cases.2020-03-08T13:54:07ZPeter BortasThe Inotify accelerated filesystem monitor may lose acceleration in some cases.Imported from https://youtrack.roxen.com/issue/PIKE-16
Reported by @grubba
The MacOS X Finder is apparently fond of the access pattern when copying files:
```mermaid
graph LR
C1[Create]==>Delete
Delete==>C2[Create]
```
The monito...Imported from https://youtrack.roxen.com/issue/PIKE-16
Reported by @grubba
The MacOS X Finder is apparently fond of the access pattern when copying files:
```mermaid
graph LR
C1[Create]==>Delete
Delete==>C2[Create]
```
The monitor for the resulting file may get lost if the second create comes before the parent directory has been scanned.