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/3961Pike should support static class members like C++ and Java do.2024-02-17T17:30:19ZPeter BortasPike should support static class members like C++ and Java do.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3961
Reported by Hermann Kruud, <hermannkruud@yahoo.co.uk>
Pike should support static class members like C++ and Java do. It would be
cleaner and quicker to write static ...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3961
Reported by Hermann Kruud, <hermannkruud@yahoo.co.uk>
Pike should support static class members like C++ and Java do. It would be
cleaner and quicker to write static members inside classes instead of
emulating this behaviour by nesting modules and classes. Static keyword is
reserved in Pike, so something else should be used. I suggest "shared".Pike NextHenrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10143Update the COM module to use the *W()-APIs.2024-01-24T09:57:48ZHenrik (Grubba) GrubbströmUpdate the COM module to use the *W()-APIs.The `COM` module appears to currently use the LP-string wrapper functions, and does not support wide strings.
Update the module to instead use the *W-functions and add support for wide strings.The `COM` module appears to currently use the LP-string wrapper functions, and does not support wide strings.
Update the module to instead use the *W-functions and add support for wide strings.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10142Add support for RFC 8785 to Standards.JSON.2024-01-17T09:40:00ZHenrik (Grubba) GrubbströmAdd support for RFC 8785 to Standards.JSON.[RFC 8785](http://pike.lysator.liu.se/rfc8785) describes a canonicalization scheme for JSON.[RFC 8785](http://pike.lysator.liu.se/rfc8785) describes a canonicalization scheme for JSON.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10141Add support for fftw 3.x (Math.Transforms.FFT)2024-01-14T14:40:40ZHenrik (Grubba) GrubbströmAdd support for fftw 3.x (Math.Transforms.FFT)The API in fftw 3.x seems to have changed drastically.
Superficial changes:
* There is now only a single header-file named `<fftw3.h>`.
* There is now only a single library named `fftw3`.
* Many of the API functions have been renamed or...The API in fftw 3.x seems to have changed drastically.
Superficial changes:
* There is now only a single header-file named `<fftw3.h>`.
* There is now only a single library named `fftw3`.
* Many of the API functions have been renamed or restructured.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10140Unify the APIs for ADT.Queue, Thread.Fifo and Thread.Queue.2023-12-21T09:35:09ZHenrik (Grubba) GrubbströmUnify the APIs for ADT.Queue, Thread.Fifo and Thread.Queue.Currently it is a bit cumbersome to eg switch between using `ADT.Queue` and `Thread.Queue`, since the former uses `get()` & `put()` while the latter uses `read()` & `write()`.
Note also that there are two implementations each for `Threa...Currently it is a bit cumbersome to eg switch between using `ADT.Queue` and `Thread.Queue`, since the former uses `get()` & `put()` while the latter uses `read()` & `write()`.
Note also that there are two implementations each for `Thread.Fifo` and `Thread.Queue`.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10136Private getter not marked as used.2023-11-16T12:02:24ZHenrik (Grubba) GrubbströmPrivate getter not marked as used.Reported by Pontus Östlund:
```
$ cat bug-private-getter.pike
class Test {
private string `property_accessor() {
return "I'm private";
}
private string `unused_getter() {
return "Unused private getter";
}
public void...Reported by Pontus Östlund:
```
$ cat bug-private-getter.pike
class Test {
private string `property_accessor() {
return "I'm private";
}
private string `unused_getter() {
return "Unused private getter";
}
public void log() {
werror("Log: %s\n", property_accessor);
}
}
int main() {
Test t = Test();
t->log();
}
```
In current Pike 8.0:
```
$ ./pike bug-private-getter.pike
bug-private-getter.pike:2: Warning: Modifier mismatch for variable property_accessor.
bug-private-getter.pike:6: Warning: Modifier mismatch for variable unused_getter.
bug-private-getter.pike:13: Warning: `property_accessor is private but not used anywhere.
bug-private-getter.pike:13: Warning: unused_getter is private but not used anywhere.
bug-private-getter.pike:13: Warning: `unused_getter is private but not used anywhere.
Log: I'm private
```
In current Pike master:
```
$ ./pike bug-private-getter.pike
bug-private-getter.pike:13: Warning: `property_accessor is private but not used anywhere.
bug-private-getter.pike:13: Warning: unused_getter is private but not used anywhere.
bug-private-getter.pike:13: Warning: `unused_getter is private but not used anywhere.
Log: I'm private
```Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10125Consider using a mapping lookup in F_SWITCH when case ranges are not in use.2023-06-28T13:06:04ZHenrik (Grubba) GrubbströmConsider using a mapping lookup in F_SWITCH when case ranges are not in use.`array.c:switch_lookup()` currently uses binary search to perform the lookup. In the common case where no `F_CASE_RANGE`s are used it would be possible to just use a mapping lookup instead.
This would require a slight API change for `sw...`array.c:switch_lookup()` currently uses binary search to perform the lookup. In the common case where no `F_CASE_RANGE`s are used it would be possible to just use a mapping lookup instead.
This would require a slight API change for `switch_lookup()` in that the first argument would need to be a `struct svalue *` (instead of the current `struct array *`).Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10126Optimize switch case ranges to use mapping lookup where all ranges are integers.2023-06-26T08:55:56ZHenrik (Grubba) GrubbströmOptimize switch case ranges to use mapping lookup where all ranges are integers.Consider the code:
```
switch(expr) {
case 0..3:
/* Foo */
break;
default:
/* Bar */
break;
}
```
If all ranges are integers, the above can be converted into:
```
case 0: case 1: case 2: case 3:
/* Foo */
b...Consider the code:
```
switch(expr) {
case 0..3:
/* Foo */
break;
default:
/* Bar */
break;
}
```
If all ranges are integers, the above can be converted into:
```
case 0: case 1: case 2: case 3:
/* Foo */
break;
default:
/* Bar */
break;
```
Which will cause it to use mapping lookup tables (cf #10125).Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10118Support "cwd" and "chroot" being Stdio.File objects in Process.create_process...2023-05-14T07:54:14ZHenrik (Grubba) GrubbströmSupport "cwd" and "chroot" being Stdio.File objects in Process.create_process() et al on plaforms that have fchdir(2).It would be useful to be able to avoid filesystem-races in `Process.create_process()` by having it support stuff like:
```
Stdio.File dirfd = Stdio.File(some_workdir, "r");
...
Process.Process proc = Process.Process(({ "some", "com...It would be useful to be able to avoid filesystem-races in `Process.create_process()` by having it support stuff like:
```
Stdio.File dirfd = Stdio.File(some_workdir, "r");
...
Process.Process proc = Process.Process(({ "some", "command" }), ([ "cwd": dirfd ]));
```Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10119Add Stdio.File()->cd() on platforms that have fchdir(2)2023-05-13T11:24:14ZHenrik (Grubba) GrubbströmAdd Stdio.File()->cd() on platforms that have fchdir(2)Example:
```
Stdio.File dir_fd = Stdio.File(some_dir, "r");
dir_fd->cd(); // cd(some_dir);
dir_fd->cd("foo"); // cd(combine_path(some_dir, "foo"));
```Example:
```
Stdio.File dir_fd = Stdio.File(some_dir, "r");
dir_fd->cd(); // cd(some_dir);
dir_fd->cd("foo"); // cd(combine_path(some_dir, "foo"));
```Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10120Move the getcwd cache to C-code.2023-05-12T08:49:17ZHenrik (Grubba) GrubbströmMove the getcwd cache to C-code.The `getcwd()` cache is currently implemented in the default master object. This necessitates a dedicated API in the master object (`zap_getcwd_cache()`) in order for `Stdio.Fd()->cd()` to be able to clear the cache.
The cache would be ...The `getcwd()` cache is currently implemented in the default master object. This necessitates a dedicated API in the master object (`zap_getcwd_cache()`) in order for `Stdio.Fd()->cd()` to be able to clear the cache.
The cache would be trivial to implement in C.
* [ ] Move the cache from the master to C/CMOD code.
* [ ] Remove the `GETCWD_CACHE` code from the default master.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10108Implement error callbacks in Stdio.Fd et al.2023-05-09T08:47:08ZHenrik (Grubba) GrubbströmImplement error callbacks in Stdio.Fd et al.In April 2004 the backend(s) got support for signalling error conditions on a dedicated callback `PIKE_FD_ERROR`, but no way to add such a callback was added to `Stdio.Fd`, so everything uses the "temporary compat stuff".
Add analogous ...In April 2004 the backend(s) got support for signalling error conditions on a dedicated callback `PIKE_FD_ERROR`, but no way to add such a callback was added to `Stdio.Fd`, so everything uses the "temporary compat stuff".
Add analogous functions to `set_read_callback()` et al for handling the error callback.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10100Support default arguments in multi-assign2023-05-06T14:07:20ZTobias S. JosefowitzSupport default arguments in multi-assignIt would be nice if `[int a, int b = 4] = ({ 1 });` as well as `[int a, int b = 4] = ({ 1, UNDEFINED });` would result in `a == 1` and `b == 4`.It would be nice if `[int a, int b = 4] = ({ 1 });` as well as `[int a, int b = 4] = ({ 1, UNDEFINED });` would result in `a == 1` and `b == 4`.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10113Add API(s) for converting pike (wide-) strings to NUL-terminated UTF16-strings.2023-05-06T10:37:09ZHenrik (Grubba) GrubbströmAdd API(s) for converting pike (wide-) strings to NUL-terminated UTF16-strings.Currently this is achieved via calling of `string_to_unicode(..., 2)` and having a special case that ensures that all byte-strings of even length have a double NUL-termination.
Eg:
```
get_all_args(NULL, args, "%t%T%T.%d%d",
...Currently this is achieved via calling of `string_to_unicode(..., 2)` and having a special case that ensures that all byte-strings of even length have a double NUL-termination.
Eg:
```
get_all_args(NULL, args, "%t%T%T.%d%d",
&username_str, &domain_str, &pw_str,
&logontype, &logonprovider);
ref_push_string(username_str);
push_int(2);
f_string_to_unicode(2);
username = (LPCWSTR)STR0(sp[-1].u.string);
args++;
if (domain_str) {
ref_push_string(domain_str);
push_int(2);
f_string_to_unicode(2);
domain = (LPCWSTR)STR0(sp[-1].u.string);
args++;
}
```
It would be nice to have:
* A function for converting a `struct pike_string *` to a `malloc()`ed NUL-terminated UTF16 `p_wchar *` (eg analogous to `fdlib.c:pike_dwim_utf8_to_utf16()`).
* A format (`%W`?) for `get_args()`/`get_all_args()` that returns the above.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10105Update various WIN32-API functions to be wide-string aware.2023-05-04T11:02:59ZHenrik (Grubba) GrubbströmUpdate various WIN32-API functions to be wide-string aware.Several NT API functions in Pike currently use the `*A` variants rather than the `*W` variants of functions. Eg `_system.LookupAccountName()` uses `LookupAccountNameA()` rather than `LookupAccountNameW()`.
Non-exhaustive list of used NT...Several NT API functions in Pike currently use the `*A` variants rather than the `*W` variants of functions. Eg `_system.LookupAccountName()` uses `LookupAccountNameA()` rather than `LookupAccountNameW()`.
Non-exhaustive list of used NT functions:
* [x] `AcquireCredentialsHandleA`
* [~] `CreateFileA`
* [x] `ExpandEnvironmentStringsA`
* [x] `GetNamedSecurityInfoA`
* [~] `InetNtopA`
* [x] `LogonUserA`
* [x] `LookupAccountNameA`
* [x] `LookupAccountSidA`
* [x] `MoveFileExA`
* [x] `QueryContextAttributesA`
* [~] `QueryDosDeviceA`
* [x] `QuerySecurityPackageInfoA`
* [x] `RegEnumKeyExA`
* [x] `RegEnumValueA`
* [x] `RegOpenKeyExA`
* [x] `RegQueryValueExA`
* [x] `SetNamedSecurityInfoA`
Update the code to be wide-string aware.
**NB**: Some of the above are currently accessed via aliases that look at `UNICODE` (and thus do not have an explicit `A`-suffix in the code).Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10117System.RegGetValue{,s} does not handle DWORD entries correctly.2023-05-03T09:33:46ZHenrik (Grubba) GrubbströmSystem.RegGetValue{,s} does not handle DWORD entries correctly.`src/modules/system/nt.c:push_regvalue()` uses the wrong shifts for bytes other than the LSB:
```
case REG_DWORD_LITTLE_ENDIAN:
push_int(EXTRACT_UCHAR(buffer)+
(EXTRACT_UCHAR(buffer+1)<<1)+
(EXTRAC...`src/modules/system/nt.c:push_regvalue()` uses the wrong shifts for bytes other than the LSB:
```
case REG_DWORD_LITTLE_ENDIAN:
push_int(EXTRACT_UCHAR(buffer)+
(EXTRACT_UCHAR(buffer+1)<<1)+
(EXTRACT_UCHAR(buffer+2)<<2)+
(EXTRACT_UCHAR(buffer+3)<<3));
break;
case REG_DWORD_BIG_ENDIAN:
push_int(EXTRACT_UCHAR(buffer+3)+
(EXTRACT_UCHAR(buffer+2)<<1)+
(EXTRACT_UCHAR(buffer+1)<<2)+
(EXTRACT_UCHAR(buffer)<<3));
break;
```
Fortunately it seems like the most common DWORD entries in the registry are <= 255.
This bug has been there since the original implementation of `System.RegGetValues()` et al in commit 53bdc644af4c8f3def29230b0dc38b7640561708 (`src/modules/system/nt.c:1.18`) in Pike 7.1.5.
Note that the bug is also present in Pike 7.0.318 and later due to a backport in commit 9481e19ee7753e06292231699f04c21841a2b6a1 (`src/modules/system/nt.c:1.19`).
The bug should be fixed in all relevant versions of Pike.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10116Implement System.RegSetValue() and/or System.RegSetKeyValue() on NT2023-05-02T12:46:44ZHenrik (Grubba) GrubbströmImplement System.RegSetValue() and/or System.RegSetKeyValue() on NTIt is currently possible to traverse the registry (using eg `System.RegGetKeyNames()` and `System.RegGetValues()`), but not to alter it.
Implement `System.RegSetValue()` and/or `System.RegSetKeyValue()`.It is currently possible to traverse the registry (using eg `System.RegGetKeyNames()` and `System.RegGetValues()`), but not to alter it.
Implement `System.RegSetValue()` and/or `System.RegSetKeyValue()`.Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10115Add autodoc markup for tagging OS-specific symbols.2023-05-01T12:32:01ZHenrik (Grubba) GrubbströmAdd autodoc markup for tagging OS-specific symbols.There are several symbols (eg `System.RegGetValue()` or `System.getpwent()`) that are OS-specific.
Add support for a semantic markup that can indicate that the former is **WIN32** and the latter is **POSIX**.
It is likely that an hierarc...There are several symbols (eg `System.RegGetValue()` or `System.getpwent()`) that are OS-specific.
Add support for a semantic markup that can indicate that the former is **WIN32** and the latter is **POSIX**.
It is likely that an hierarchy of OSes may be needed in case the presentation wants to support filtering (eg **MacOS X** is a **BSD** which in turn is a subset of **POSIX**).
Having a dedicated markup makes for a consistent formatting of the information.
The initial implementation needs to:
* Document the markup.
* Parse the markup.
* Save the information in the generated `*.xml` files.
* Render the information.
NB: There might be a similar issue with respect to CPU/architecture dependent symbols so consider having a markup that supports both (or generic) restrictions. Eg:
```
@requires __OS__.POSIX
@requires __CPU__.IA64
@requires Nettle.GCM
```Pike Next