Align license with other MIT licensed repos

Codecov Report

Merging #63 (b0f9d36) into main (770d981) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head b0f9d36 differs from pull request most recent head e1a6369. Consider uploading reports for the commit e1a6369 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff            @@
##              main       #63   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines            8         8
=========================================
  Hits             8         8

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


chore: release 1.13.0

:robot: I have created a release beep boop
1.13.0 (2024-11-01)
Features

redshift: bump github.com/aws/aws-sdk-go-v2/service/redshiftdata from 1.29.4 to 1.30.1 (#216) (efefea6)
trino: bump github.com/trinodb/trino-go-client from 0.316.0 to 0.317.0 (#214) (f11118d)

Miscellaneous

deps: bump cloud.google.com/go from 0.115.1 to 0.116.0 (#222) (c5c3025)
deps: bump github.com/aws/aws-sdk-go-v2/config from 1.27.40 to 1.27.41 (#211) (1a35100)
deps: bump github.com/aws/aws-sdk-go-v2/config from 1.27.41 to 1.28.1 (#227) (9f34b6f)
deps: bump github.com/rudderlabs/rudder-go-kit from 0.42.0 to 0.43.0 (#213) (1bfe41d)
deps: bump google.golang.org/api from 0.199.0 to 0.204.0 (#226) (c7e8b62)
deps: bump rudderlabs/pr-description-enforcer from 1.0.0 to 1.1.0 (#209) (4349e7f)
redshift: retry schema does not exist errors in list schemas (#208) (78a6d0a)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/rudderlabs/sqlconnect-go/releases/tag/v1.13.0 :sunflower:


[Feature]: retrieveLaunchParams return error, instead of throwing

Is your feature request related to a problem? Please describe.
retrieveLaunchParams errors, breaking Next.js build process.
So in Next.js we should do this
let initData = "";
try {
  const { initDataRaw } = retrieveLaunchParams();
  initData = initDataRaw ?? "";
} catch {
    //
}

Approach above fixes the situation, but this is a lot of code for the data that we use very often.
Describe the solution you'd like
Maybe it could return errors instead of throwing, so using a hook will look something like this?
const {launchParams, errors, isError} = useLaunchParams(true);

if (isError) {
  return <p>{JSON.stringify(errors)}</p>;
}

Describe alternatives you've considered
No response
Additional context
No response

I see that errors array being created, but not returned. This feature was planned already?
https://github.com/Telegram-Mini-Apps/tma.js/blob/c50df6da158925897768dfa65347142cd1c0dcd3/packages/sdk/src/launch-params/retrieveLaunchParams.ts#L12

Could you explain how does it break Next.js build process?

You will never have launch parameters on the build stage. How do you expect it working properly?

You will never have launch parameters on the build stage. How do you expect it working properly?

not throwing errors, just returning them

now i need to block the whole app on server (like you did in next-template), and render only on client. but what's the point in using Next.js when your whole app is now client side

but what's the point in using Next.js when your whole app is now client side

There is no point at all. Telegram Mini Apps ismostly a client side technology. You can use useLaunchParams(true) in case, you are using SSR.


Skopt fails on Keras tuning

I am having an issue with Scikit Optimize.
I am using it to optimize a Keras neural network.
I'm not using BayesSearchCV, just gp/forest/gbrt_minimize.
Everything runs but Skopt fails to perform better than a simple grid search because sometimes Keras fails and produce a huge error.
I think this is an initialization problem, sometimes Keras does just that, but it does that quite often so Skopt (be it gp minimize, forest minimize or gprt minimize) is 'confused' because of this huge error : for a given set of parameters, Keras SHOULD have a low error, but sometimes as I say, it doesn't.
(If we could re-launch Keras with the same parameters but a different initialization, it would work and give a small error as expected.)
But of course Skopt doesn't 'know' that, so it assumes this parameter set is just not good so it goes to look elsewhere.
Skopt ends up with a surrogate model of the error that doesn't make any sense so it cannot find its way do the optimum.
I'm quite sure of it because I monitor the error as a function of the parameters, and I can see that maybe 20% of the time this problem arises. When I delete these points set from the database and run a machine learning model on this 'cleaned' database, I can build a reliable surrogate model of the error.. When I keep these points it's not possible to build a reliable surrogate model so I'm pretty sure that's why Skopt fails.
So I'm stuck because I can't find a way to 'tell' Skopt to just dismiss these points.
My question is then : is there a way to 'tell' Skopt to 'forget' a point for, say, any error over some threshold?

Hi,
In your particular case, it is worth to try ask-and-tell interface. There you start a loop of n_iter, and ask for a point, evaluate the point, and tell the result to the optimizer. So you have full control of whether you want to tell the result or not. But be sure not stuck in an infinite loop - if you don't update the optimizer, it probably will always predict the same point.


Added support for loading DBs and Designs using a directory tree structure

Added similar DB loading to mysql except instead of a mysql dump file its a directory tree of json files for the designs.

I prefer to keep the image as small as possible. This also keeps it as simple as possible. @klaemo is already looking for maintainers and adding more and more features would make maintenance much harder.
I also do not see any advantages by placing this script inside the image. The couch-per-user workflow would not work, because we cannot know our users (and therefor the "folders") in advance.

I hear ya, you could check for the couch-per-user and just not run that
code.
We just needed a way to populate our DB and designs.  I figured I'd commit
back what I did in case you wanted to use it.
Most other DB containers support this feature.  This is basically what
mysql and others do.  Not sure who wouldn't want this as its a very common
feature.  It creates your DBs and designs for you.
On Mon, Nov 14, 2016 at 9:52 AM, Mirco Zeiss<EMAIL_ADDRESS>wrote:

I prefer to keep the image as small as possible. This also keeps it as
simple as possible. @klaemo https://github.com/klaemo is already
looking for maintainers and adding more and more features would make
maintenance much harder.
I also do not see any advantages by placing this script inside the image.
The couch-per-user workflow would not work, because we cannot know our
users (and therefor the "folders") in advance.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/klaemo/docker-couchdb/pull/96#issuecomment-260354958,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFA3yjEwRgQS0T1gBMPP0rsfpiXInXRsks5q-HWggaJpZM4Ku_LC
.

I can see where you're coming from, @craig2017. Other DB images do indeed have this feature.
But for the reasons @zemirco mentioned, I'm not sure if we would want to add this.
There are also the lovely couchdb bootstrap projects by the eHealthAfrica  team: https://github.com/eHealthAfrica/couchdb-bootstrap
I'm going to leave this PR open for a bit, to see if others are interested in this functionality and what the other maintainers might say about this.
Anyways, thank you for your work on this!

Sounds good.  Thanks
On Nov 18, 2016 3:59 AM, "Clemens Stolle"<EMAIL_ADDRESS>wrote:

I can see where you're coming from, @craig2017
https://github.com/craig2017. Other DB images do indeed have this
feature.
But for the reasons @zemirco https://github.com/zemirco mentioned, I'm
not sure if we would want to add this.
There are also the lovely couchdb bootstrap projects by the eHealthAfrica
team: https://github.com/eHealthAfrica/couchdb-bootstrap
I'm going to leave this PR open for a bit, to see if others are interested
in this functionality and what the other maintainers might say about this.
Anyways, thank you for your work on this!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/klaemo/docker-couchdb/pull/96#issuecomment-261515884,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFA3ykA4QWANiaXcFD9dzLMMd5JnI5WYks5q_ZMXgaJpZM4Ku_LC
.

I'm going to close this. Since we are not supporting it.


2D-UNet training notebook doesn't work for Colab

For code in https://colab.research.google.com/github/constantinpape/torch-em/blob/main/experiments/2D-UNet-Training.ipynb
!nvidia-smi

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

!conda install -c conda-forge torch_em "pyyaml<5.0"

Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: /
The environment is inconsistent, please check the package plan carefully
The following packages are causing the inconsistency:

conda-forge/linux-64::mamba==0.8.0=py37h7f483ca_failed with initial frozen solve. Retrying with flexible solve.
Solving environment: /
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abortfailed

UnsatisfiableError: The following specifications were found
to be incompatible with the existing python installation in your environment:
Specifications:

pyyaml[version='<5.0'] -> python[version='>=3.10,<3.11.0a0|>=3.9,<3.10.0a0']

Your python: python=3.7
If python is on the left-most side of the chain, that's the version you've asked for.
When python appears to the right, that indicates that the thing on the left is somehow
not available for the python version you are constrained to. Note that conda will not
change your python version to a different minor version unless you explicitly specify
that.
The following specifications were found to be incompatible with each other:
Output in format: Requested package -> Available versions
Package setuptools conflicts for:
python=3.7 -> pip -> setuptools
torch_em -> pytorch -> setuptools[version='<59.6|>=41.0.0']
Package pypy3.6 conflicts for:
torch_em -> python[version='>=3.6'] -> pypy3.6[version='7.3.0.|7.3.1.|7.3.2.|7.3.3.']
pyyaml[version='<5.0'] -> python[version='>=3.6,<3.7.0a0'] -> pypy3.6[version='7.3.0.|7.3.1.|7.3.2.|7.3.3.|>=7.3.3|>=7.3.2|>=7.3.1']
Package _libgcc_mutex conflicts for:
python=3.7 -> libgcc-ng[version='>=9.4.0'] -> _libgcc_mutex[version='|0.1',build='conda_forge|main']
pyyaml[version='<5.0'] -> libgcc-ng[version='>=7.3.0'] -> _libgcc_mutex[version='|0.1',build='conda_forge|main']The following specifications were found to be incompatible with your system:

feature:/linux-64::__glibc==2.27=0
torch_em -> pytorch -> __cuda
torch_em -> pytorch -> __glibc[version='>=2.17|>=2.17,<3.0.a0']

Your installed version is: 2.27

!nvidia-smi

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

This is probably caused because you don't have a colab session with gpu support and should be fixed if you change this.

!conda install -c conda-forge torch_em "pyyaml<5.0"

The failure seems to be caused by the pyyaml dependency not being available for python 3.7 anymore (this used to  work....).
You can try to remove the pyyaml dependency, i.e. just run

!conda install -c conda-forge torch_em

Hopefully this fixes the error. (Pinning the pyyaml version was necessary at some point due to issues with the bioimageio libraries; I hope these are fixed now and it should just work).
Please give it a try and let me know if this fixes the error.

I have updated the notebooks now in order to use the pre-installed pytorch version. It's working for me, so I am closing this. Feel free to reopen if you run into any other issues with colab.


Add ability to describe tool parameters via #[ToolParameter] attribute

Todo
validate, that this is not allowed:
#[ToolParameter(const: 'my-string')]
int $number

i guess i would prefer PhpLlm\LlmChain\Attribute\ToolParameter 🤔
and i think it would be great to consider all the standardized cases:

see https://json-schema.org/draft/2019-09/json-schema-validation#rfc.section.6

and i think it would be great to consider all the standardized cases:

In this case it would be good to a) map the type, so that pattern can only be used if it is a string or define the type, but that would double the noise.

Nice one :muscle:

Nice one 💪

Tough one


[th2-2689] adaptation to new cradleapi

Related to store-common PR 12

https://github.com/th2-net/th2-store-common/pull/12

Let's create a common branch related to book page changes and increase the version in its.

@Nikita-Smirnov-Exactpro I created a new branch th2-2150-books-pages from last master and use it in this PR. Also I added 4.0.0 version to README and properties.
Can I merge it to th2-2150-books-pages?


Add eth_signer in addition to the default signer

We will soon have Eth signature based accounts in Starknet (WIP by OpenZeppelin). They’re basically the same as the standard accounts with starkcurve based ECDSA replaced by secpk256k1 based ECDSA.
The request is about  adding eth_signer in addition to the default signer, allowing devs who rely on eth accounts to test directly with starknet-js. noble-curves has the curve definition here, so IIUC the signer code is very similar (as .sign comes from the curve object

Under progress...


Heuristic solver for tsp

Codecov Report

Merging #35 into master will decrease coverage by 2.20%.
The diff coverage is 58.20%.

@@            Coverage Diff             @@
##           master      #35      +/-   ##
==========================================
- Coverage   80.06%   77.86%   -2.21%
==========================================
  Files          24       25       +1
  Lines         597      664      +67
==========================================
+ Hits          478      517      +39
- Misses        119      147      +28

Impacted Files
Coverage Δ

...htheory/nearest-neighbor-tsp/NearestNeighborTSP.py
58.20% <58.20%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5109cca...ca8067a. Read the comment docs.


If I can train out the performance in the paper with the default configuration?

Hello! I have tried the default config with swin_tiny_224 to train without any pre-training model. And in the 65-th epoches, the top1 get to 71.3. I wonder whether I can get the performance like 81.5 as the paper say ? After all, it really takes too long time to train.

Hi, you can refer to the training log in this issue #29 . Note the log used 16GPUs with total batch-size of 1024 and got 81.3 acc.

中科大有和亚研院有合作项目？

感谢老哥

中科大有和亚研院有合作项目？
Yes, there are joint ph.D programs between USTC and MSRA.


feat: Configurable timeouts for tasks

Added [timeouts] section to config file.  The task running code checks to see if the currently running task is listed in the config and if so uses that timeout instead of the default.

need to update the tests

is it preferred to squash the test fix into the refactored commit?

A separate commit is fine.

You should rebase. Also, please update the relevant docs regarding these changes.
At quick glance I don't see the difference between TIMEOUT and  TASK_TIMEOUT. Maybe one of the variable may need renaming so it makes more sense, especially since it's exposed to the user/admin.

I think this looks good. Existing functionality seems to remain unchanged. Have you been able to test this locally and it works?

Its all good. 👍
Nice job!


drivers: apds9960: Use dts generated I2C name for binding

This commit removes old Kconfig dependency on I2C name and
replaced with new dts generated I2C name.
Fixes #7804
This issue was produced because of
9ddd8d1e4d7daa9b1d37af0e8a23de1c1900d7d5
Signed-off-by: Punit Vara<EMAIL_ADDRESS>

Codecov Report

Merging #7967 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #7967   +/-   ##
=======================================
  Coverage   55.03%   55.03%
=======================================
  Files         481      481
  Lines       53943    53943
  Branches    10474    10474
=======================================
  Hits        29690    29690
  Misses      19984    19984
  Partials     4269     4269

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8c8ddb8...b1e9741. Read the comment docs.


Public Slack

I posted in the collaborators slack channel but I'm not sure if anyone is really checking that?
@nfarina  There doesn't appear to be a public slack channel even though it is referenced in the readme.  Was it the intention to have a public channel so people can discuss things?

Nevermind, found the #homebridge channel to join.


[Text Field] Text overflows textfield compounds

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
With a long label, the text field overflows out of the bounds.
Also for some reason the theme provider is overriding the label even though there's no theme parent.
Expected Behavior 🤔
The text should stay in or under the outlined input.
(as with overflow: hidden)
Steps to Reproduce 🕹
https://codesandbox.io/s/dazzling-burnell-484sc
Steps:

Make a textbox
Put in a long label
????
Profit

Context 🔦
We have an issue where on mobile devices the text is too large and sticks out of the margins.
Here's an example

Your Environment 🌎
What we are using:

Tech
Version

Material-UI
4.9.5

React
^16.13.0

Browser
Chrome

TypeScript
~3.8.3

although the issues is present as seen in the sandbox above

Duplicate of #12255


ARROW-15743: [R] skip not connected up to skip_rows on open_dataset despite error messages indicating otherwise

The primary purpose of PR is to allow users to specify the number of rows to skip when opening a dataset via the skip argument as well as via skip_rows (as they are functionally identical).
It also relocates the checking that the passed arguments are valid to a standalone function (check_csv_file_format_args()) instead of being inside csv_file_format_parse_options() (as we are not just interested in the arguments to be passed to CsvParseOptions, we also want to check validity of the arguments passed to CsvReadOptions and CsvConvertOptions).


Amend Volontulo description in readme

 Issue by w1stler
Thursday Aug 11, 2016 at 18:09 GMT
Originally opened as https://github.com/stxnext-csr/volontulo/issues/573

As a new participant,
I want to read project description,
In order to easily understand the purpose of application

Closing


[Додати гурток. Додати центр. Додати локацію] The 'Назва' field accepts the 'space' as a valid symbol

Environment: Windows 10, Google Chrome Version 91.0.4472.124 (Official Build) (64-bit).
Reproducible: always
Build found: last commit
Preconditions

Go to https://speak-ukrainian.org.ua/dev
Log in as an Administrator<EMAIL_ADDRESS>'Password'="admin")
Go to the User's private office
Сlick the ‘Додати гурток’ in the drop-down list

Steps to reproduce

Enter 'проВ' and space into the 'Назва' field

Actual result
The 'Назва' field accepts the 'space' as a valid symbol

Expected result
The 'Назва' field should accept letters of the Ukrainian and English alphabet, numbers and special symbols.
User story
https://github.com/ita-social-projects/TeachUA/issues/70
https://github.com/ita-social-projects/TeachUA/issues/71
https://github.com/ita-social-projects/TeachUA/issues/291

The same bug is valid for the 'Назва' field of Додати центр pop-up, and the 'Назва' field of Додати локацію pop-up.

Not a bug


Update xdebug 2.9.6 to 3.0.3

Breaking changes, see https://xdebug.org/docs/upgrade_guide

I guess I'll add a way to build xdebug 3 for PHP 8, and leave xdebug 2 in place for the lower versions, at least for now.


Building Catch2 without Its Tests

I'm trying to add the Catch2 to my project, and it seems that everything is going smoothly until my build fails. I see that the issue occurs when Catch2 tries to build some of its tests, and I would like to turn those off but for some reason I cannot. I'm using the OPTIONS command like below but Catch2 still tries to build the tests! I'm wondering if anyone have ran into this issue, or have any ideas how to solve it.
CPMAddPackage(
  NAME Catch2
  GITHUB_REPOSITORY catchorg/Catch2
  VERSION 2.13.6
  OPTIONS
    "CATCH_BUILD_TESTING OFF"
    "CATCH_BUILD_EXAMPLES OFF"
    "CATCH_BUILD_EXTRA_TESTS OFF"
    "CATCH_BUILD_FUZZERS OFF")

Catch2 flags are listed here.

Never mind! That was my bad! A subdirectory had an old version of the Catch2 downloaded by CPM, and was causing issue. After removing that, everything runs correctly!


Implement naryFun

naryFun is like unaryFun/binaryFun, but for an arbitrary number of args.
Motivated by #3837

While it does seem like 26 parameters ought to be enough for anybody , this arbitrary limitation is not necessary. Fix:
/**
Transforms a string representing an expression into a n-ary function.
$(UL
    $(LI The number of parameters is given by $(D argc). If no explicit
        $(D argc) is given, it is inferred to be $(D parmNames.length).)
    $(LI Explicit names for the function parameters may instead be given as
        $(D parmNames). If more than $(D argc) names are supplied, the
        extras will be ignored.)
    $(LI If no $(D parmNames) are given, the letters ($(D a) through $(D z))
        are used to name up to the first 26 function parameters.)
    $(LI $(D args[index]) can always be used to access any parameter by index,
        regardless of whether it has been given a name.)
)
*/
template naryFun(alias fun, size_t argc, parmNames...)
    if (parmNames.length == 0 || allSatisfy!(isSomeString, typeof(parmNames)))
{
    static if (is(typeof(fun) : string))
    {
        /* Create a string containing "alias <name> = args[0];", for each arg.
         * Save it as an enum outside the function, to avoid regenerating the string
         * for every permutation of ElementTypes.
         */
        private enum aliases = function() {
            import std.algorithm.comparison : min;
            import std.conv : to;

            string result;

            static if(parmNames.length > 0)
            {
                foreach(i, name; parmNames[0 .. min(argc, parmNames.length)])
                    result ~= "alias " ~ name ~ " = args[" ~ i.to!string ~ "];";
            }
            else
            {
                foreach(i; 0 .. min(argc, 'z' - 'a'))
                    result ~= "alias " ~ cast(char)('a' + i) ~ " = args[" ~ i.to!string ~ "];";
            }

            return result;
        }();

        static if (!fun._ctfeMatchNary(parmNames))
        {
            import std.traits, std.typecons, std.typetuple;
            import std.algorithm, std.conv, std.exception, std.math, std.range, std.string;
        }

        auto naryFun(ElementTypes...)(auto ref ElementTypes args)
            if (ElementTypes.length == argc)
        {
            mixin(aliases);
            return mixin(fun);
        }
    }
    else static if (needOpCallAlias!fun)
    {
        // Issue 9906
        alias naryFun = fun.opCall;
    }
    else
    {
        alias naryFun = fun;
    }
}
template naryFun(alias fun, parmNames...)
    if (allSatisfy!(isSomeString, typeof(parmNames)))
{
    alias naryFun = naryFun!(fun, parmNames.length, parmNames);
}

Two other problems solved by the above are:

Your naryFun isn't actually required to be "n-ary". I added the constraint if (ElementTypes.length == argc) to fix this.
Your code potentially re-evaluates aliases() for every ElementTypes permutation, even though its result depends only upon the outer template arguments. This slows down compilation and leaks memory. Save aliases as an enum outside the inner template to fix this.
aliases should be private; it is just an implementation detail.

@rcorre I have updated my previous comment; please read the latest version on Github rather than the original email notification.

@tsbockman I don't think I need to re-add argc as a parameter to the custom-names overload, I could just check if (ElementTypes.length == parmNames.length). Unless you want to support something like naryFun!("x + y + args[2]", 3, "x", "y").
Interesting point about re-evaluating aliases() though -- I had no idea. I'll make it private too.

Never mind, I see why you did it like that now.

@rcorre

Unless you want to support something like naryFun!("x + y + args[2]", 3, "x", "y").

I do want to support that, as a generalized solution to the "cannot generate > 26 parameters" default naming problem.
Will anyone ever use this feature? Who knows!
It costs nothing to expose args[], though, since it's going to be there either way. Perhaps some generic code generator will benefit.

Interesting point about re-evaluating aliases() though -- I had no idea.

Some of the generic code I've been working on recently accepts hundreds of different template argument permutations.
Compilation of my exhaustive tests is annoyingly slow - as in C++ slow. The compiler's memory use is kind of disturbing at times, as well. This has got me into the habit of considering the compile-time costs of my CTFE and template use.
It takes some getting used to, but ultimately the only really big differences compared to runtime optimization, are that the CTFE environment is about 100x slower, and leaks like a sieve.

@tsbockman I basically took your suggestion line-for-line. Counting semicolons in the ends part seemed a bit ugly but I didn't come up with a nicer approach.

This has got me into the habit of considering the compile-time costs of my CTFE and template use.

My (naive) mindset so far has been 'if it doesn't happen at runtime, I can ignore performance' :)

@rcorre

Counting semicolons in the ends part seemed a bit ugly but I didn't come up with a nicer approach.

Yes that was a bit of a hack on my part. I thought about cobbling together some things from std.algorithm, but ultimately decided it would complicate things unnecessarily.

My (naive) mindset so far has been 'if it doesn't happen at runtime, I can ignore performance' :)

If the program never finishes compiling, then nothing happens at runtime. Best performance possible! :wink:

I thought about cobbling together some things from std.algorithm, but ultimately decided it would complicate things unnecessarily

The problem with that, as I found out in my earlier attempts, is that this code path is hit by so many other functions. I would have preferred format to that messy string concatenation, but format calls startsWith, which uses a string lambda as a default predicate, and before you know it the compiler is screaming about circular dependencies.

The problem with that, as I found out in my earlier attempts, is that this code path is hit by so many other functions. I would have preferred format to that messy string concatenation, but format calls startsWith, which uses a string lambda as a default predicate, and before you know it the compiler is screaming about circular dependencies.

I hadn't thought that far ahead, but it makes sense that circular dependencies would be an issue here.

Counting semicolons in the ends part seemed a bit ugly but I didn't come up with a nicer approach.

Fixed now:
// Generate naryFun parameter aliases mixin string.
string naryFunAliases(size_t argc, string[] parmNames...) pure
{
    import std.array : appender;
    import std.algorithm : min;
    import std.conv : to;

    if(parmNames.length > 0)
    {
        auto ret = appender!string();
        foreach(i, name; parmNames[0 .. min(argc, parmNames.length)])
            ret ~= "alias " ~ name ~ " = args[" ~ i.to!string ~ "];";
        return ret.data;
    }
    else
    {
        // The default a-z aliases are always the same, so cache them at global scope.
        enum size_t az = ('z' - 'a') + 1;
        enum cache = function()
        {
            static struct R
            {
                string all;
                size_t[az + 1] ends;
            }
            R ret;

            auto buff = appender!string();
            foreach(i; 0 .. az)
            {
                buff ~= "alias " ~ cast(char)('a' + i) ~ " = args[" ~ i.to!string ~ "];";
                ret.ends[i + 1] = buff.data.length;
            }

            ret.all = buff.data;
            return ret;
        }();

        // Uses slices to minimize CT allocations.
        return cache.all[0 .. cache.ends[argc > az? az : argc]];
    }
}

Very clever! I've integrated that now.

Re-added private. Also, I replaced argc > az? az : argc with min(az,argc), as you're already importing min for use earlier.

I do slightly prefer the original signatures. unaryFun(alias fun, parmName = "a") is more clear than unaryFun(alias fun, parmName...) if (parmName.length <= 1).

It's a little repetitive, but perhaps this is more to your liking?
alias unaryFun(alias fun) = naryFun!(fun, 1);
alias unaryFun(alias fun, string parmName) = naryFun!(fun, 1, parmName);

alias binaryFun(alias fun) = naryFun!(fun, 2);
alias binaryFun(alias fun, string parm1Name) = naryFun!(fun, 2, parm1Name);
alias binaryFun(alias fun, string parm1Name, string parm2Name) = naryFun!(fun, 2, parm1Name, parm2Name);

The point is really just to avoid the parmName = "a" stuff.

On lines 278 and 300, I should have written .data.idup, rather than just .data.
The .idup seems to be required to prevent the slicing from triggering a copy - at least at runtime. (Why? I have no idea. You'd think that sticking the value into an enum would make it idup automatically...)
However, this may be moot, as from my testing it looks suspiciously like a copy always occurs if the slicing is performed at compile time. Does DMD not do compile-time string interning (de-duplication)? This seems like low-hanging fruit to cut down on executable size and working set a bit.

Anyway, we're splitting hairs at this point; just pick any of the three different fixes we discussed for the unaryFun and binaryFun aliases. (I still prefer my original suggestion, but I don't think it matters much.)
After that, I'd say this is ready to pull.

Rebased, squashed, and ready to go. I went with the first option you suggested. Thanks for all the insight!

Rebased, squashed, and ready to go.

LGTM. :+1: @JakobOvrum ?

@JakobOvrum That would change the semantics, as parmNames.length <= 2, not parmNames == 2.
An alternative we considered earlier would be this:
alias unaryFun(alias fun) = naryFun!(fun, 1);
alias unaryFun(alias fun, string parmName) = naryFun!(fun, 1, parmName);

alias binaryFun(alias fun) = naryFun!(fun, 2);
alias binaryFun(alias fun, string parm1Name) = naryFun!(fun, 2, parm1Name);
alias binaryFun(alias fun, string parm1Name, string parm2Name) = naryFun!(fun, 2, parm1Name, parm2Name);

Is that acceptable?

How about the old signatures using default arguments?

@JakobOvrum Specifying the default arguments in that way defeats the caching of the naryFunAliases() string mixin on line 291. This would make compilation slower and more memory hungry for programs which instantiate binaryFun or unaryFun many times.

@JakobOvrum it is possible to keep the original signature and leverage the cached strings by making naryFunAliases a template, but it involves un-nesting some private enums so they aren't re-evaluated for each template instantiation.

How about the commit I just added? Making `naryFunAliases

Oops, forgot to actually change the signatures of unaryFun/binaryFun back. Fixed now.
You can stick a pragma(msg, ...) in the template to see that it only instantiates once for ("a") and once for ("a","b").

Works for me.

This is a good opportunity to name it something sensible like stringLambda.

something sensible like stringLambda.

I agree that, in isolation, is a better name.
However, naryFun has the advantage of making the connection to unaryFun and binaryFun more obvious. I would advocate sticking with naryFun unless you want to deprecate the unaryFun and binaryFun names in the long run.
Standard library artifacts are more discoverable when related items have similar names.

naryFun has been proposed a number of times and deprecation of unaryFun and binaryFun has come up as well. Regardless of whether we do that, or the degree we do it (hiding them in the docs has been proposed), we want to espouse naryFun going forward. unaryFun and binaryFun are obsolete relics with this.

That's the thing though, the proposed naryFun does not support that.

Oops - right you are. Fix:
// Generate naryFun parameter aliases mixin string.
private template naryFunAliases(size_t argc, parmNames...)
{
    import std.array : appender;
    import std.algorithm : min;
    import std.conv : to;

    enum naryFunAliases = function()
    {
        auto ret = appender!string();
        foreach(i, name; parmNames)
            ret ~= "alias " ~ parmNames[i] ~ " = args[" ~ i.to!string ~ "];";
        for(size_t i = parmNames.length; i < argc; ++i)
            ret ~= "alias " ~ cast(char)('a' + i) ~ " = args[" ~ i.to!string ~ "];";

        return ret.data;
    }();
}

The naryFun documentation needs to be fixed, also:
/**
Transforms a string representing an expression into a n-ary function.
$(UL
    $(LI The number of parameters is given by $(D argc). If no explicit
        $(D argc) is given, it is inferred to be $(D parmNames.length).)
    $(LI Explicit names for the function parameters may be given as
        $(D parmNames). If more than $(D argc) names are supplied, the
        extras will be ignored.)
    $(LI The letters ($(D a) through $(D z)) are used as default names
        for up to the first 26 function parameters.)
    $(LI $(D args[index]) can always be used to access any parameter by index,
        regardless of whether it has been given a name.)
)
*/

naryFun has been proposed a number of times and deprecation of unaryFun and binaryFun has come up as well. Regardless of whether we do that, or the degree we do it (hiding them from the docs has been proposed), we want to espouse naryFun going forward. unaryFun and binaryFun are obsolete relics with this.

OK. Then I agree that stringLambda (maybe shorten it to strLambda?) is better.

@tsbockman, note that you can submit pull requests to @rcorre's PR if you'd like things to go smoother.

Yes, that would streamline things :)
Or just push fixes to a branch somewhere and I can cherry-pick them over.
Also, the auto-tester fail seems unrelated, I think. Some issue with allocators on Windows?

@JakobOvrum Yeah I should really start doing that. (I'm fairly new to GitHub, so tips are welcome.)
@rcorre Yeah, the auto-tester failing is not your fault; somebody else broke the build again.

So I think I've run out of things to complain about now. How about you @JakobOvrum ?

LGTM. Please squash the commits.

Wait a minute. This is slow CTFE code with a lot of bloat. I will post additional changes soon.

enum stringLambdaAliases = function() is huge template bloat.
Just add normal function, which do not import other phobos:
string _ctfeStringLambdaAliases(size_t argc, string[] paramNames...)
{
    // NO IMPORTS

    if (!__ctfe) assert(false);
    assert(argc <= 100);
    assert(argc >= paramNames.length);

    // use a letter for each unspecified param, stopping at 'z'
    enum an = 'z' - 'a' + 1;
    immutable numLetters = argc > an ? an : argc;

    enum len = "alias abra = args[99];\n".length;
    auto ret = new char[argc * len];
    ret = ret[0..0];

    // first create aliases from the specified param names
    foreach(i, name; paramNames)
        _ctfeAddName(ret, name, i);

    // fill in remaining aliases with letters
    foreach (i; paramNames.length .. numLetters)
    {
        char[1] name = void;
        name[0] = cast(char)('a' + i);
        _ctfeAddName(ret, name, i);
    }
    return cast(string) ret;
}

void _ctfeAddName(ref char[] str, in char[] name, size_t i)
{
    if (!__ctfe) assert(false);
    str.assumeSafeAppend ~= "alias ";
    str.assumeSafeAppend ~= name;
    str.assumeSafeAppend ~= " = args[";
    if (i >= 10)
    {
        str.assumeSafeAppend ~= cast(char)('0' + i / 10);
        i %= 10;
    }
    str.assumeSafeAppend ~= cast(char)('0' + i);
    str.assumeSafeAppend ~= "];\n";
}

@9il

enum stringLambdaAliases = function() is huge template bloat.

We made it a template deliberately, to memoize the alias list because it is exactly the same for 99% of all instantiations of stringLambda.
Surely stringLambdaAliases instantiations aren't actually finding their way into the generated binary, since they are never referenced by anything at runtime?

enum stringLambdaAliases = function() is huge template bloat.
We made it a template deliberately, to memoize the alias list because it is exactly the same for 99% of all instantiations of stringLambda.

OK, template looks good. But implementation should be updated with content of _ctfeStringLambdaAliases. _ctfeAddName can be duplicated.

Surely stringLambdaAliases instantiations aren't actually finding their way into the generated binary, since they are never referenced by anything at runtime?

Yes

Also, all that assumeSafeAppend stuff

Does not compile:
Error: _d_arrayshrinkfit cannot be interpreted at compile time, because it has no available source code
And would segfault the compiler or something if it did, since you are making the dubious assumption that no one will ever pass a parameter name that is no more than 4 characters.

Also, all that assumeSafeAppend stuff does not compile:
Error: _d_arrayshrinkfit cannot be interpreted at compile time, because it has no available source code

Updated:
string _ctfeStringLambdaAliases(size_t argc, string[] paramNames...)
{
    // NO IMPORTS

    if (!__ctfe) assert(false);
    assert(argc <= 100);
    assert(argc >= paramNames.length);

    // use a letter for each unspecified param, stopping at 'z'
    enum an = 'z' - 'a' + 1;
    immutable numLetters = argc > an ? an : argc;

    size_t namesLength = argc - paramNames.length;
    foreach(name; paramNames)
        namesLength += name.length;

    enum len = "alias  = args[99];\n".length;
    auto ret = new char[argc * len + namesLength];
    auto save = ret;

    // first create aliases from the specified param names
    foreach (i, name; paramNames)
        _ctfeAddName(ret, name, i);

    // fill in remaining aliases with letters
    foreach (i; paramNames.length .. numLetters)
    {
        char[1] name = void;
        name[0] = cast(char)('a' + i);
        _ctfeAddName(ret, name, i);
    }
    return cast(string) save[0..$-ret.length];
}

void _ctfeAddName(ref char[] str, in char[] name, size_t i)
{
    if (!__ctfe) assert(false);
    str._ctfePut("alias ");
    str._ctfePut(name);
    str._ctfePut(" = args[");
    if (i >= 10)
    {
        str._ctfePut(cast(char)('0' + i / 10));
        i %= 10;
    }
    str._ctfePut(cast(char)('0' + i));
    str._ctfePut("];\n");
}

void _ctfePut(ref char[] str, in char[] name)
{
    str[0 .. name.length] = name;
    str = str[name.length .. $];
}

void _ctfePut(ref char[] str, in char name)
{
    str[0] = name;
    str = str[1..$];
}

enum stringLambdaAliases = function() is huge template bloat.
We made it a template deliberately, to memoize the alias list because it is exactly the same for 99% of all instantiations of stringLambda.
OK, template looks good. But implementation should be updated with content of _ctfeStringLambdaAliases. _ctfeAddName can be duplicated (EDIT: ... twice in the body of template ).

After thinking a little bit I considered that access to memoized template would be slower than generate new string. Direct mixin of _ctfeStringLambdaAliases seems faster.

After thinking a little bit I considered that access to memoized template would be slower than generate new string. Direct mixin of _ctfeStringLambdaAliases seems faster.

If that is so, then DMD must have a super inefficient template lookup method.

If that is so, then DMD must have a super inefficient template lookup method.

I don't think so. I just wrote very fast _ctfeStringLambdaAliases  ;)

This version is compatible with the current argc constraints. I suspect it is also faster:
string _ctfeStringLambdaAliases(size_t argc, string[] paramNames...)
{
    // NO IMPORTS
    if (!__ctfe) assert(false);

    char[20] iStr_buff;
    void incIdx(ref char[] iStr)
    {
        ptrdiff_t x = iStr.length - 1;
        while(true)
        {
            ++(iStr[x]);
            if(iStr[x] <= '9')
                return;

            iStr[x] = '0';
            --x;

            if(x < 0)
            {
                iStr = iStr_buff[($ - (iStr.length + 1)) .. $];
                iStr[0] = '1';
                return;
            }
        }
    }
    auto iStr = iStr_buff[($-1) .. $];
    iStr[0] = '0';

    static void addName(ref char[] str, in char[] name, in char[] i)
    {
        str ~= "alias ";
        str ~= name;
        str ~= " = args[";
        str ~= i;
        str ~= "];\n";
    }

    enum len = "alias abra = args[99];\n".length;
    auto ret = new char[argc * len];
    ret = ret[0 .. 0];

    // first create aliases from the specified param names
    foreach(i, name; paramNames[0 .. (argc <= $? argc : $)])
    {
        addName(ret, name, iStr);
        incIdx(iStr);
    }
    size_t i = paramNames.length;

    // use a letter for each unspecified param, stopping at 'z'
    enum az = 'z' - 'a' + 1;
    immutable numLetters = argc > az ? az : argc;
    while(i < numLetters)
    {
        char[1] name = void;
        name[0] = cast(char)('a' + i);
        addName(ret, name, iStr);

        ++i;
        incIdx(iStr);
    }
    return cast(string) ret;
}

I don't think so. I just wrote very fast _ctfeStringLambdaAliases ;)

Shouldn't this kind of template lookup basically just be an associative array access or something?

Shouldn't this kind of template lookup basically just be an associative array access or something?

Yes, but finally you need to make multiple full string comparisons. Plus another additional overhead.

This version is compatible with the current argc constraints. I suspect it is also faster:

It is slow because makes multiple memory allocations

It is slow because makes multiple memory allocations

? In most cases, it has exactly the same number as yours: one.
Unless you're saying that it's not reusing the memory I allocate at the beginning...

? In most cases, it has exactly the same number as yours: one.
Unless you're saying that it's not reusing the memory I allocate at the beginning...

Exactly. In addition, incIdx is slow.

Exactly. In addition, incIdx is slow.

I'm writing an actual benchmark, so we'll find out.

This will allocate:
    static void addName(ref char[] str, in char[] name, in char[] i)
    {
        str ~= "alias ";
        str ~= name;
        str ~= " = args[";
        str ~= i;
        str ~= "];\n";
    }

@9il Benchmark:
import std.conv, std.datetime, std.math, std.stdio;

size_t instantiateMany(size_t count) {
    size_t ret = 0;
    foreach(argc; 0 .. count) {
        const str = _ctfeStringLambdaAliases(argc + 27, "alice", "bob", "charlie");
        foreach(ch; str)
            ret += ch;
    }
    return ret;
}

void main() {
    enum count = 20_000;

    enum ctfed = instantiateMany(count);
    writeln(ctfed);

    // This part was just to satisfy my curiosity about how much slower CTFE is than runtime:
    static size_t rted = 0;
    static void rt() {
        rted = instantiateMany(count);
    }
    writefln("%s", to!Duration(benchmark!(rt)(1)[0]));
    writeln(rted);
}

Yours is slightly slower than mine (51s vs 46s) in CTFE, and (not that it matters) about twice as fast at runtime in optimized release mode (0.161s vs 0.297s).
The memory usage of both is essentially the same (an absolutely appalling 10 Gigabytes - if I hadn't just upgraded my RAM a couple of weeks ago it would have locked up my computer...).
So, either I screwed up the benchmark setup somehow, or, for practical purposes, you're wrong.

Note that is testing the function approach only - I haven't figured out the right way to compare that to the template memoization approach yet.

Benchmarking the template memoization is more akward. count has to be kept quite low, otherwise the compiler errors out complaining about recursive template expansions.
Here's what I came up with:
enum memoize = false;
void main() {
    enum size_t count = 450;

    static if(memoize)
    {
        enum ctfed = instantiateMany!count;
        writeln("memoize");
    }
    else
    {
        enum ctfed = instantiateMany(count);
        writeln("ctfe");
    }
    writeln(ctfed);
}

static if(memoize)
{
    template instantiateMany(size_t count)
    {
        static if(count > 1)
            enum recurse = instantiateMany!(count - 1);
        else
            enum size_t recurse = 0;

        enum instantiateMany = function()
        {
            const str = stringLambdaAliases!(count + 27, "alice", "bob", "charlie");

            size_t ret = recurse;
            foreach(ch; str)
                ret += ch;
            return ret;
        }();
    }

    template stringLambdaAliases(size_t argc, paramNames...)
    {
        private enum alphas = ('z' - 'a') + 1;
        static if(argc > paramNames.length && argc > alphas)
            enum stringLambdaAliases = stringLambdaAliases!(alphas > paramNames.length? alphas : paramNames.length, paramNames);
        else
        {
            enum stringLambdaAliases = function()
            {
                // NO IMPORTS
                if (!__ctfe) assert(false);

                char[20] iStr_buff;
                void incIdx(ref char[] iStr)
                {
                    ptrdiff_t x = iStr.length - 1;
                    while(true)
                    {
                        ++(iStr[x]);
                        if(iStr[x] <= '9')
                            return;

                        iStr[x] = '0';
                        --x;

                        if(x < 0)
                        {
                            iStr = iStr_buff[($ - (iStr.length + 1)) .. $];
                            iStr[0] = '1';
                            return;
                        }
                    }
                }
                auto iStr = iStr_buff[($-1) .. $];
                iStr[0] = '0';

                static void addName(ref char[] str, in char[] name, in char[] i)
                {
                    str ~= "alias ";
                    str ~= name;
                    str ~= " = args[";
                    str ~= i;
                    str ~= "];\n";
                }

                enum len = "alias abra = args[99];\n".length;
                auto ret = new char[argc * len];
                ret = ret[0 .. 0];

                // first create aliases from the specified param names
                foreach(i, name; paramNames[0 .. (argc <= $? argc : $)])
                {
                    addName(ret, name, iStr);
                    incIdx(iStr);
                }
                size_t i = paramNames.length;

                // use a letter for each unspecified param, stopping at 'z'
                while(i < alphas)
                {
                    char[1] name = void;
                    name[0] = cast(char)('a' + i);
                    addName(ret, name, iStr);

                    ++i;
                    incIdx(iStr);
                }
                return cast(string) ret;
            }();
        }
    }
}
else
{
    size_t instantiateMany(size_t count)
    {
        size_t ret = 0;
        foreach(argc; 0 .. count)
        {
            const str = _ctfeStringLambdaAliases(argc + 27, "alice", "bob", "charlie");
            foreach(ch; str)
                ret += ch;
        }
        return ret;
    }

    string _ctfeStringLambdaAliases(size_t argc, string[] paramNames...)
    {
        // NO IMPORTS
        //if (!__ctfe) assert(false);

        char[20] iStr_buff;
        void incIdx(ref char[] iStr)
        {
            ptrdiff_t x = iStr.length - 1;
            while(true)
            {
                ++(iStr[x]);
                if(iStr[x] <= '9')
                    return;

                iStr[x] = '0';
                --x;

                if(x < 0)
                {
                    iStr = iStr_buff[($ - (iStr.length + 1)) .. $];
                    iStr[0] = '1';
                    return;
                }
            }
        }
        auto iStr = iStr_buff[($-1) .. $];
        iStr[0] = '0';

        static void addName(ref char[] str, in char[] name, in char[] i)
        {
            str ~= "alias ";
            str ~= name;
            str ~= " = args[";
            str ~= i;
            str ~= "];\n";
        }

        enum len = "alias abra = args[99];\n".length;
        auto ret = new char[argc * len];
        ret = ret[0 .. 0];

        // first create aliases from the specified param names
        foreach(i, name; paramNames[0 .. (argc <= $? argc : $)])
        {
            addName(ret, name, iStr);
            incIdx(iStr);
        }
        size_t i = paramNames.length;

        // use a letter for each unspecified param, stopping at 'z'
        enum az = 'z' - 'a' + 1;
        immutable numLetters = argc > az ? az : argc;
        while(i < numLetters)
        {
            char[1] name = void;
            name[0] = cast(char)('a' + i);
            addName(ret, name, iStr);

            ++i;
            incIdx(iStr);
        }
        return cast(string) ret;
    }
}

It's somewhat faster with memoization than without: 1.268 vs 1.38s. I can't really tell about memory usage, because I can't push count high enough.

Version that doesn't depend upon the string concatenation operator ~:
template stringLambdaAliases(size_t argc, paramNames...)
{
    private enum alphas = ('z' - 'a') + 1;
    static if(argc > paramNames.length && argc > alphas)
    {
        enum stringLambdaAliases = stringLambdaAliases!(
            alphas > paramNames.length? alphas : paramNames.length,
            paramNames);
    }
    else
    {
        enum stringLambdaAliases = function()
        {
            // NO IMPORTS
            if (!__ctfe) assert(false);

            char[20] iStr_buff;
            auto iStr = iStr_buff[($-1) .. $];
            iStr[0] = '0';
            void incIdx(ref char[] iStr)
            {
                ptrdiff_t x = iStr.length - 1;
                while(true)
                {
                    ++(iStr[x]);
                    if(iStr[x] <= '9')
                        return;

                    iStr[x] = '0';
                    --x;

                    if(x < 0)
                    {
                        iStr = iStr_buff[($ - (iStr.length + 1)) .. $];
                        iStr[0] = '1';
                        return;
                    }
                }
            }

            enum line = "alias  = args[];\n".length;
            auto ret_buff = new char[argc * (line + 8)];
            auto ret = ret_buff[0 .. 0];
            void put(in char[] append)
            {
                ret = ret_buff[0 .. (ret.length + append.length)];
                ret[($ - append.length) .. $] = append;
            }
            void addName(in char[] name, in char[] i)
            {
                if(ret_buff.length < (ret.length + line + name.length + i.length))
                    ret_buff.length *= 2;

                put("alias ");
                put(name);
                put(" = args[");
                put(i);
                put("];\n");
            }

            // first create aliases from the specified param names
            foreach(i, name; paramNames[0 .. (argc <= $? argc : $)])
            {
                addName(name, iStr);
                incIdx(iStr);
            }
            size_t i = paramNames.length;

            // use a letter for each unspecified param, stopping at 'z'
            while(i < alphas)
            {
                char[1] name = void;
                name[0] = cast(char)('a' + i);
                addName(name, iStr);

                ++i;
                incIdx(iStr);
            }
            return cast(string) ret;
        }();
    }
}

It's a tiny bit faster, and may theoretically leak less memory at compile time.

@tsbockman The last implementation looks broken for long names. You may want to use the last my and optimise it.

The last implementation looks broken for long names.

Can we please stop with the vague "looks broken" kind of comments? My code looked "slow" too, but it wasn't.
Give me a failing test case, or at least point me to what specifically, concerns you.

You may want to use the last my and optimise it.

I did - that's what I ended up with. (I'm sure it can be improved further, of course.)

auto ret_buff = new char[argc * (line + 8)]; - the length does not depend on paramNames.

I did - that's what I ended up with. (I'm sure it can be improved further, of course.)

From me example
    size_t namesLength = argc - paramNames.length;
    foreach(name; paramNames)
        namesLength += name.length;

    enum len = "alias  = args[99];\n".length;
    auto ret = new char[argc * len + namesLength];
    auto save = ret;

auto ret_buff = new char[argc * (line + 8)]; - the length does not depend on paramNames.

Thank you for being specific.
In the rare case that someone chose a whole bunch of really long names, this part:
if(ret_buff.length < (ret.length + line + name.length + i.length))
    ret_buff.length *= 2;

Should reallocate as needed. It is guaranteed to do so no more than log2(maxParamNameLength) times, and in real world code is pretty much guaranteed to do so either zero or one time.
My guess is that this is faster, on average, than dealing with the complexity of preallocating the exact amount required. (I might be wrong, but see no way to directly test this belief.)

I tested, and this works fine with my last version:
writeln(stringLambdaAliases!(3,
    "alicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealicealice",
    "bobbobbobbobbobbobbobbobbobbobbobbobbobbobbobbobbobbobbob",
    "charliecharliecharliecharliecharliecharliecharliecharliecharliecharlie"));

I don't know if performance is totally optimal for such a case, but:

It should still be quite good, and
Is this really the case we should be optimizing for?

Is this really the case we should be optimizing for?

No more optimisations, thx ))

No more optimisations, thx ))

One tunable parameter in my code I'd be interested in you take a guess at the optimal value for:
auto ret_buff = new char[argc * (line + 8)];

For most code, the 8 means that no reallocation is required for an average (not maximum) name length <= 7. One allocation is required for an average length up to around 32.
Does that sound about right, or do you think I should increase the default buffer size a little?

8 is OK

OK. Should I send it off as a pull request to @rcorre then?

OK. Should I send it off as a pull request to @rcorre then?

Of course, plus unittests

plus unittests

Yes, I suppose I should add some.

Of course, plus unittests

Done.
@9il Note that I removed your argc <= 100 constraint from stringLambdaAliases since, by itself, it has no scaling issues. But, you could potentially still apply that constraint directly to stringLambda if we never get around to fixing the O(N^2) complexity of __ctfeMatchNary.

@tsbockman's changes pass the tests, but the newly added _ctfeMatchNaryTest fails

the newly added _ctfeMatchNaryTest fails

That's probably because you need to pass "args.length" and "args" to _ctfeMatchNary on line 233, like @9il said earlier.

Probable fix (untested): https://github.com/rcorre/phobos/pull/2

ah yes. I'll get to that tomorrow

@9il What is _ctfeMatchNary actually supposed to do? Just what is a "trivial n-ary function"?
It looks like it's just scanning to see if there are any symbols in fun that aren't parameter names, but if so I don't understand why it's so complicated.

@tsbockman I applied all of your patches and ran through the full phobos test suite.
I tweaked the commit messages a bit to make it more clear what each change is, but the content is the same.

@tsbockman @9il -- anything more to do here? If we do want this in phobos, lets get it in before it diverges to far. #3837 has been waiting on this.

@rcorre

anything more to do here?

There are two issues remaining that I am aware of:

Earlier @9il requested changes to the template constraint for stringLambda. I believe I talked him out of the additional argc constraints, but that still leaves the other part, which amounts to replacing this:

    if (paramNames.length == 0 || allSatisfy!(isSomeString, typeof(paramNames)))

With this:
private alias isStringValue(T) = is (typeof(T) : string);
// ...
    if (allSatisfy!(isStringValue, paramNames))

I don't personally see a need for this change, but I have no objection to it either, beyond mild distaste at introducing yet another private symbol at module scope. (Anonymous template literals would be a cool language addition to streamline stuff like this.)

Replacing the O(N^2) _ctfeMatchNary with the O(N log(N)) strLambdaNeedsImports is a big change. I'd really like for @JakobOvrum or @9il to review my work there before this gets merged.

I don't understand why isStringValue is preferable to the current approach.

I don't understand why isStringValue is preferable to the current approach.

@9il never really explained why he wanted this change, but as far as I can see it has two practical effects:

isStringValue only accepts immutable(char[]); it rejects other string types like char[], wstring, or dstring. I doubt this was deliberate on his part, though.

isSomeString is an external dependency, which we have been trying to eliminate to the extent reasonably possible.

Effect (2) is nice in theory. But having looked at the definition of isSomeString, I don't think depending on it is going to cause any problems; it's doesn't import half of Phobos or anything like that.

Effect (2) is nice in theory. But having looked at the definition of isSomeString, I don't think depending on it is going to cause any problems; it doesn't import half of Phobos or anything like that.

Exactly. Dependencies on things in std.algorithm were problematic because many of those use unaryFun/binaryFun internally. For something like isSomeString, I don't see the problem -- its a pretty simple template. That's what its there for. But if it really is problematic I'll take it out.

Ping @JakobOvrum and @9il . Anyone want to review my work on strLambdaNeedsImport()?
I think that's all we're missing before we can merge this.

Anyone want to review my work on strLambdaNeedsImport()

I like it, but I am not sure whether it handles UTF-8 names correctly though, how about adding some tests with some weird chinese characters that take more than one char?
(In any case I am not sure whether there is a real need for it)

@greenify

I like it, but I am not sure whether it handles UTF-8 names correctly though, how about adding some tests with some weird chinese characters that take more than one char?

The ё used in some of the current test cases is a two-byte code point under UTF-8. Is that sufficient?
Given the way that my algorithm works, and the fact that multi-byte UTF-8 code points always set the high bit of each byte, there shouldn't be any difference between the handling of two-byte versus three- or four-byte code points.

The ё used in some of the current test cases is a two-byte code point under UTF-8. Is that sufficient?

Oh I remembered it wrongly to be in the first byte. Yep that's sufficient for me :)

Ping @JakobOvrum @9il @andralex .
Can we move forward with this? It's blocking another PR by @rcorre .

Any updates here? Waiting on this to improve #3837.

I've hinted at this before, but I think the argc parameter is overengineering. Does stringLambda!(foo, 26) offer any advantage over stringLambda!(foo, aliasSeqOf!(std.ascii.lowercase[]))? stringLambda!(foo, 4, "x", "y") over stringLambda!(foo, "x", "y", aliasSeqOf!(lowercase[0 .. 2]))? The rules for argc are quite complex and it adds a certain amount of complexity to the implementation as well.

@JakobOvrum I'd say no. It was imitating the use of default names for unaryFun and binaryFun, but I don't see a problem with having to explicitly specify names if you're parsing a string lambda with > 2 params. Actually, that might be preferable. I'll see how it looks without it.

@JakobOvrum : see those two commits for what it looks like without argc. Reasonably simpler implementation, without losing much value (IMHO). Actually I think eliminating the automatic usage of a..z makes the use clearer.
This does miss the case where someone wants a 50-param function and doesn't want to pass in 50 param names (they just want to use args[n]). But I think that's an edge case and its reasonable to ask them to generate parameters.
Your aliasSeqOf!(lowercase[]) doesn't quite work as we expect string param names. We could either complicate the implementation or just suggest using aliasSeqOf!(lowercase[].map!(x => x.to!string)). I went with the latter.

I've hinted at this before, but I think the argc parameter is overengineering.

This PR is complete overengineering and I would like to close it with related PRs.

I'm ok with that. I don't feel particularly strongly about this and have other PRs I'd rather focus on. Any other opinions on closing this and possibly #3837?

This PR is complete overengineering and I would like to close it with related PRs.

@9il, please, this is not a productive comment. The motivations here have been clearly stated. What are the authors supposed to do when presented with a comment like this?
Please don't close pull requests (or threaten to) simply because you don't like them. If you think something is a bad idea, please elaborate on why - there's a chance your comment will guide the work in a good direction.

@rcorre, I think the current proposal makes a lot of sense, but I hope to hear from @9il about his considerations.

@9il, please, this is not a productive comment. The motivations here have been clearly stated. What are the authors supposed to do when presented with a comment like this?

I contributed to this PR too, because I was afraid that this PR can be merged into Phobos and I wanted to reduce issues of this PR. So, I tried to improve it. Later, when I was included to Phobos core team I decide to do not spend time on it. This PR wanted to be improvement of my import workaround for string lambdas. I will not describe why I don't like it to be merged because this is about style/time/architecture and not about algorithms and clear reasons. This is just my opinion.

This PR is complete overengineering and I would like to close it with related PRs.
...
This PR wanted to be improvement of my import workaround for string lambdas. I will not describe why I don't like it...

While there are probably other legitimate criticisms that could be made of my work on strLambdaNeedsImports(), I really don't understand how it, specifically, can be dismissed as "overengineered".
That's a term usually used to attack excessively complex solutions, but strLambdaNeedsImports() is actually simpler than the _ctfeMatch system it replaces: it's about 30 or 40 lines shorter, has four fewer module-level symbols, eliminates a duplicated unit test block, and is (in my opinion) much easier to understand.

That's true, I think there was a fair bit of duplicate code between unaryFun and binaryFun that was consolidated.
@tsbockman could you double-check me on that last commit? I think the buffer length guess was off by 1.

@rcorre

could you double-check me on that last commit? I think the buffer length guess was off by 1.

That commit is not helping anything. The buffer was already large enough for typical usage, and in the rare case that someone is using long variable names, this bit will grow it as needed:
while(ret_buff.length < (ret.length + line + name.length + i.length))
    ret_buff.length *= 2;

What problem are you trying to solve?

I think the buffer length guess was off by 1.

The initial size of that buffer has no significance, other than as a performance optimization. The code should still work as long as the initial size is greater than zero and not too ridiculously large.

@rcorre Looking at this again (it's been a while since I wrote this stuff)...
You need to undo that change; it messes up the (formerly) perfect length calculation in the while loop I quoted above. If for some reason you really need to change the initial buffer size, the correct way to do so is to modify this part:
auto ret_buff = new char[paramNames.length * (line + 8)];

In particular, the + 8 is the adjustable parameter.

I assumed it was guessing the length of a single variable name as an optimization, and it looked wrong based on the string it was generating. I didn't read carefully enough. Undoing it now.

That's true, I think there was a fair bit of duplicate code between unaryFun and binaryFun that was consolidated.

I do agree with @tsbockman and @rcorre that this is pretty useful.

unaryFun and binaryFun were added at a time when there was no short lambda syntax. Lately that has rendered them all but unnecessary - short lambdas are better integrated with the language and cleaner.
So this adds a considerable amount of sophistication to an approach that is already being obsoleted. There's also a sort of decline in usefulness - string lambdas are best when the body is very short, but the more arguments functions have the more bulky body they also tend to have.
I might be missing something, e.g. uses of the imports analysis or other ancillary functions. But if the sole purpose of this is to generalize unaryFun and binaryFun to multiple arguments, it gets my veto.
I'll close this; feel free to reopen or redo if it seems I'm mistaken.


Compiler should fallback to globally installed qooxdoo-sdk if no library defines the "qx" namespace

Say I have a contrib to which I do not want to add the whole NPM metadata/packages overhead, but instead I have all necessary npm packages (qxcompiler, qooxdoo-sdk) installed globally via NVM and NPM. Since the path to the qooxdoo-sdk framework folder will depend on the node version used and other factors, it cannot be hardcoded. The location of the framework folder can be resolved from within a running node script via let pathToFramework = require.resolve('qooxdoo-sdk') + "/framework";
Therefore, it seems to be a good idea to implement a fallback mechanism by which the compiler falls back on this path if none of the libraries in compile.json provides the qx namespace.

Alternative: use npm link qooxdoo-sdk in my project and put the path node_modules/qooxdoo-sdk/framework into compile.json's libraries section. So the fallback is not necessary. Closing.


Unable to some project build-depends "Could not load module ... It is a member of the hidden package"

I've got a toy project where I'm trying to get better at Haskell by doing some exercises:
https://github.com/willbush/exercises/tree/master/haskell-exercises
latest commit at the time of this writing:
https://github.com/willbush/exercises/tree/077ff0bc9768c520b69be9bf8a863d18b041254c
When using ghcide I'm getting errors on 3 files that don't seem right to me:
λ ~/code/exercises/haskell-exercises/ master* ghcide
ghcide version: 0.1.0 (GHC: 8.8.3) (PATH: /nix/store/48ajx48f59s0yqd6qb34zj7xzhgn3vc9-ghcide-0.1.0/bin/ghcide)
Ghcide setup tester in /home/will/code/exercises/haskell-exercises.
Report bugs at https://github.com/digital-asset/ghcide/issues

Step 1/6: Finding files to test in /home/will/code/exercises/haskell-exercises
Found 17 files

Step 2/6: Looking for hie.yaml files that control setup
Found 1 cradle

Step 3/6, Cradle 1/1: Loading /home/will/code/exercises/haskell-exercises/hie.yaml

Step 4/6, Cradle 1/1: Loading GHC Session

Step 5/6: Initializing the IDE

Step 6/6: Type checking the files
File:     /home/will/code/exercises/haskell-exercises/Setup.hs
Hidden:   no
Range:    1:7-1:26
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Distribution.Simple’
  It is a member of the hidden package ‘Cabal-<IP_ADDRESS>’.
  Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
File:     /home/will/code/exercises/haskell-exercises/bench/BenchAll.hs
Hidden:   no
Range:    3:17-3:31
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Criterion.Main’
  It is a member of the hidden package ‘criterion-<IP_ADDRESS>’.
  Perhaps you need to add ‘criterion’ to the build-depends in your .cabal file.
File:     /home/will/code/exercises/haskell-exercises/src/AdventOfCode/Day5.hs
Hidden:   no
Range:    8:17-8:30
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Data.Array.ST’
  It is a member of the hidden package ‘array-<IP_ADDRESS>’.
  Perhaps you need to add ‘array’ to the build-depends in your .cabal file.
File:     /home/will/code/exercises/haskell-exercises/src/AdventOfCode/Day2.hs
Hidden:   no
Range:    13:17-13:30
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Data.Array.ST’
  It is a member of the hidden package ‘array-<IP_ADDRESS>’.
  Perhaps you need to add ‘array’ to the build-depends in your .cabal file.
File:     /home/will/code/exercises/haskell-exercises/src/AdventOfCode/Day2.hs
Hidden:   no
Range:    14:17-14:35
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Data.Array.Unboxed’
  It is a member of the hidden package ‘array-<IP_ADDRESS>’.
  Perhaps you need to add ‘array’ to the build-depends in your .cabal file.
File:     /home/will/code/exercises/haskell-exercises/src/AdventOfCode/Day3.hs
Hidden:   no
Range:    32:17-32:32
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Data.List.Index’
  It is a member of the hidden package ‘ilist-<IP_ADDRESS>’.
  Perhaps you need to add ‘ilist’ to the build-depends in your .cabal file.
File:     /home/will/code/exercises/haskell-exercises/src/AdventOfCode/Day3.hs
Hidden:   no
Range:    33:17-33:32
Source:   not found
Severity: DsError
Message:
  Could not load module ‘Data.List.Extra’
  It is a member of the hidden package ‘extra-1.6.21’.
  Perhaps you need to add ‘extra’ to the build-depends in your .cabal file.
Files that failed:
 * /home/will/code/exercises/haskell-exercises/Setup.hs
 * /home/will/code/exercises/haskell-exercises/bench/BenchAll.hs
 * /home/will/code/exercises/haskell-exercises/src/AdventOfCode/Day2.hs
 * /home/will/code/exercises/haskell-exercises/src/AdventOfCode/Day3.hs
 * /home/will/code/exercises/haskell-exercises/src/AdventOfCode/Day5.hs

Completed (12 files worked, 5 files failed)

I get that Setup.hs isn't going to work and BenchAll.hs won't work until multi-component support lands in ghcide. However, the other three Day*.hs files seem like they should work to me because they load fine with cabal new-repl.
If desired, one should be able to clone my exercises repository and nix-shell --pure to get the exact same environment I'm using (assuming https://nixos.org/nix/ is installed).
I'm not sure if this is a ghcide issue or hie-bios. I'm posting this here because the issue looks the same as 470 and the latest comment mentions reporting it here.
Note that the hie.yaml I'm using is:
cradle:
  cabal:
    component: "test:haskell-exercises-test"

If I instead do:
cradle:
  cabal:
    component: "lib:haskell-exercises"

Then those files in question will load fine, but none of the tests will work. This goes for having no hie.yaml as well. The output ends up looking a lot like 514, but I think that's expected.
Version Info
λ ~/code/exercises/haskell-exercises/ master* ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.8.3
λ ~/code/exercises/haskell-exercises/ master* hie-bios version
hie-bios version 0.4.0 compiled by GHC 8.8.3
λ ~/code/exercises/haskell-exercises/ master* ghcide --version
ghcide version: 0.1.0 (GHC: 8.8.3) (PATH: /nix/store/48ajx48f59s0yqd6qb34zj7xzhgn3vc9-ghcide-0.1.0/bin/ghcide)
λ ~/code/exercises/haskell-exercises/ master*

hie-bios check and flags
The check sub-command produces no output. I guess that's a good thing. I modified the flags output below by inserting line breaks after the commas. One thing to note is that the mentioned hidden packages are missing from the output.
λ ~/code/exercises/haskell-exercises/ master* hie-bios check test/Main.hs
λ ~/code/exercises/haskell-exercises/ master* hie-bios flags test/Main.hs

Options:
["-fbuilding-cabal-package",
"-O0",
"-outputdir",
"/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp",
"-odir",
"/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp",
"-hidir",
"/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp",
"-stubdir",
"/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp",
"-i",
"-i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp",
"-i/home/will/code/exercises/haskell-exercises/test",
"-i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen",
"-i/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/global-autogen",
"-I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen",
"-I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/global-autogen",
"-I/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/haskell-exercises-test-tmp",
"-optP-include",
"-optP/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/build/haskell-exercises-test/autogen/cabal_macros.h",
"-hide-all-packages",
"-Wmissing-home-modules",
"-no-user-package-db",
"-package-db",
"/home/will/.cabal/store/ghc-8.8.3/package.db",
"-package-db",
"/home/will/code/exercises/haskell-exercises/dist-newstyle/packagedb/ghc-8.8.3",
"-package-db",
"/home/will/code/exercises/haskell-exercises/dist-newstyle/build/x86_64-linux/ghc-8.8.3/haskell-exercises-<IP_ADDRESS>/t/haskell-exercises-test/package.conf.inplace",
"-package-id",
"base-<IP_ADDRESS>",
"-package-id",
"bytestring-<IP_ADDRESS>",
"-package-id",
"containers-<IP_ADDRESS>",
"-package-id",
"haskell-exercises-<IP_ADDRESS>-inplace",
"-package-id",
"hspec-2.7.1-DTGDYPmkrDq5rk3zcuroRh",
"-package-id",
"safe-0.3.18-F31ek1WnrA3UJF2AhicNf",
"-package-id",
"utility-ht-0.0.15-1zMKpkUjWvmL5idQFPrnB1",
"-XHaskell2010",
"test/Main.hs",
"CommonSpec",
"ProjectEuler.ProblemsSpec",
"AdventOfCode.Day1Spec",
"AdventOfCode.Day2Spec",
"AdventOfCode.Day3Spec",
"AdventOfCode.Day4Spec",
"AdventOfCode.Day5Spec",
"-Wall",
"-Wcompat",
"-Widentities",
"-Wincomplete-record-updates",
"-Wincomplete-uni-patterns",
"-Wpartial-fields",
"-Wredundant-constraints",
"-hide-all-packages"]

Dependencies: ["haskell-exercises.cabal","cabal.project"]

Work Around
The issue goes away by adding the packages mentioned in the error to the test suite build-depends (commented out lines below need to be uncommented).
test-suite haskell-exercises-test
  default-language:    Haskell2010
  type:                exitcode-stdio-1.0
  hs-source-dirs:      test
  main-is:             Main.hs
  ghc-options:
    -Wall
    -Wcompat
    -Widentities
    -Wincomplete-record-updates
    -Wincomplete-uni-patterns
    -Wpartial-fields
    -Wredundant-constraints
  build-depends:
      base ^>=<IP_ADDRESS>
    , bytestring
    , containers
    , haskell-exercises
    -- , extra
    -- , ilist
    -- , array
    , hspec
    , safe
    , utility-ht
  other-modules:
      CommonSpec
    , ProjectEuler.ProblemsSpec
    , AdventOfCode.Day1Spec
    , AdventOfCode.Day2Spec
    , AdventOfCode.Day3Spec
    , AdventOfCode.Day4Spec
    , AdventOfCode.Day5Spec

Hi! Thank you for your detailed bug report!
I think the relevant bit is this:

Note that the hie.yaml I'm using is:
  cradle:
    cabal:
      component: "test:haskell-exercises-test"

It is the same reason why the benchmarks cant be loaded: They are part of different components.
In this case you are trying to load the test-suite. The test-suite has no array dependency, that is why the ghc session in ghcide will not have it in scope and you cant load your library modules.
Afaict, this should be fixed once multi-component support is merged and you can already try it by using the fork of mpickering: https://github.com/mpickering/ghcide/ if you are brave :)
And modifying your hie.yaml to:
cradle:
  cabal:
    - path: ./src
      component: "lib:haskell-exercieses"
    - path: ./test
      component: "test:haskell-exercieses-test"

I thought this might be fixed by specifying each component. In fact, I didn't realize ghcide doesn't support it until I tried. I decided to report this anyway because I couldn't tell if this is expected behavior or not since it was working with ghci via cabal new-repl (ghcide readme mentions if something works with ghci it should work with ghcide).
Feel free to close if everything looks good. I'll probably just do the work around until multi-component support gets merged and makes it's way into the nixpkgs repo.

You can load each of the components individually assuming you specified the component in hie.yaml, right? That is what is meant with, if it works with cabal new-repl it will work.
However, loading multiple components, e.g. opening files from the library and the testsuite is not supported at the moment and expected behaviour!
Feel free to re-open if I got something wrong!


Accessibility testing of blue bar and creator search UI updates

Screen reader testing to confirm accessibility of recent/upcoming ui changes to blue bar, version nav and creator search:

#1065
#1080
#945
#893
#891

Accessibility testing instructions for screen reader testing.
SS testing - 1.24.docx

Accessibility testing: https://psu.mediaspace.kaltura.com/media/1_apj74i9w

Recording for issues identified above: https://psu.mediaspace.kaltura.com/media/1_apj74i9w

Thanks! I'll check it out

Regarding consistency across the bottom, there is a way to do it with all buttons, but it would be a lot refactoring. Essentially, the Rails' button_to creates a form...but in this case, we're already within a form and html ignores the inner one. This leads to the call going to the incorrect resource.
A way around this: by using button_tag instead, you can assign it to a form, a la `<%= button_tag, form: 'some_form'%> Then, outside of the other form, you can define "some_form", with the logic that it needs. But because of the way we've broken everything into little components and partials, there's a surprising amount of refactoring that this entails. Given that usability isn't currently a problem, I don't feel like this is worth it at the moment.


BGO Positioning from macro file

Now you can tune the position of the BGO in the tank. AmBeGen primaries vertex position automatically adjust to keep being launched from BGO's centre.

Thanks for this @DiegoCostas97
For more discussion on this PR see #465
FYI you didn't need to close your previous PR & open a new one after a git pull. It actually creates more work for me (needing to re-review the code changes). Please feel free to ask git related questions in the future 🙂

Sorry for that Tom, Next time I'll ask.DiegoEl 24 jul 2024, a las 18:18, Tom Dealtry @.***> escribió:
Thanks for this @DiegoCostas97
For more discussion on this PR see #465
FYI you didn't need to close your previous PR & open a new one after a git pull. It actually creates more work for me (needing to re-review the code changes). Please feel free to ask git related questions in the future 🙂
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


On focus loss in Windows 7, app regains Windows border.

When the TrueFramelessWindow app loses focus, it gains it's borders back. This only occurs on Windows 7.

The window parent have not the correct rect.


fixes #3 - old file extension being left in the name

Fixes the issue I opened and hopefully makes the code easier to reason about

Coverage remained the same at 100.0% when pulling ee0ed44ce395e9b7752de1129b1c5e71d25bcec8 on Etherian:Etherian-patch-1 into 971fab050820391cd33ec637e1a7276dd11455a9 on caseyWebb:master.

I have no idea how this went unnoticed for so long. My apologies.
I added a testcase, rearranged a bit, and merged.
This has been migrated to a taskr — the successor to fly — plugin, and will shortly be published. As of now, taskr is a drop in replacement for fly.


[feat]: Better developer tooling to improve the health check experience for users

Prerequisites

[X] I have searched for existing issues that already suggest this feature.

Describe the Feature Request
Namely, timeliness - for example, a UI may be available long before the health check indicates that this is the case
Describe the Use Case
Improved UX
Describe Preferred Solution
No response
Describe Alternatives
No response
Anything else?
No response

@Blu-J's filebrowser and syncthing healthchecks were designed to solve this i believe.

Should this ticket be moved to https://github.com/Start9Labs/embassy-sdk-ts/ ??


Remove unused names in component mapping

Summary:

react-native-slider use RNCSlider not RCTSlider: https://github.com/callstack/react-native-slider/blob/166ec7f3e7c853ab3be3da132c726dd8442b3874/package/ios/RNCSliderManager.m#L15-L20
react-native-video doesn't support Fabric on stable release: https://github.com/react-native-video/react-native-video/issues/2650
react-native-maps use AIRMap not RCTMap: https://github.com/react-native-maps/react-native-maps/blob/fca4ad7b2eb53a81814bdcd69d80f81620ea1a2a/ios/AirMaps/AIRMapManager.m#L36-L46
react-native-webview use RNCWebView not RCTWebView: https://github.com/react-native-webview/react-native-webview/blob/4197bb42ce79406ff20c7e5637f78e44ca45474c/apple/RNCWebViewManager.mm#L44
Shimmer is deprecated: https://github.com/facebookarchive/Shimmer

TemplateView, AxialGradientView, Keyframes and ImpressionTrackingView seem to be internal only and Google found nothing
Changelog:
[GENERAL] [REMOVED] - Remove unused names in component mapping
Test Plan:
none

Thanks for this. I'll import it for now, but we may need some internal refactoring to make sure we don't depend on this for our internal dependencies.


[SSE] Connect to database hangs

When I want to connect to SQL Server 2012 Express, in to Event Log is logged this event:
Faulting application name: SSE.exe, version: <IP_ADDRESS>, time stamp: 0x5745fd23
Faulting module name: ODBC32.dll, version: 6.1.7601.17514, time stamp: 0x4ce7b964
Exception code: 0xc0000005
Fault offset: 0x0002a65b
Faulting process id: 0x9e0
Faulting application start time: 0x01d61244b99beb12
Faulting application path: C:\Program Files (x86)\NetworkDLS\Simple Scripting Engine\SSE.exe
Faulting module path: C:\Windows\system32\ODBC32.dll

@nototbol what operating system are you using? This should work regardless, but might help me pinpoint an issue.

Windows Server 2008 R2 and Windows Server 2012 R2.


database/sql: Documetation: Connection Pool with reverse proxy

I have created a connection pool for the purposes of multiple read replicas.
I have HAProxy being used as a reverse proxy which provides a host url which links to multiple host urls (randomly allocated).
When I create the connection pool, If I type in the host name to be the HAProxys host name, will there be any weird side-effects in how the connection pool works.
In common connetion pools such as in Java, this approach works fine.

I don't think there will be a problem. If it works in Java it will probably work here.


Appstudio update hacbs-test-project-vgn2

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI has failed.There was an error creating the PipelineRun: hacbs-test-project-vgn2-on-pull-request-
creating pipelinerun hacbs-test-project-vgn2-on-pull-request- in namespace rhtap-demo-aojt-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request


Need better way to enter diacritics and special characters

Currently in Sinopia, there is no good way to enter the diacritics used in multiple Latin script languages as well as in transliterating non-Latin script. The method of using the alt key with 4-digit codes is extremely difficult and slow. In addition this method only support characters used in West European languages; the combinations for diacritics used in some East European languages, etc. lack an alt key combination. For people working with multiple languages picking and using the various foreign keyboards in Windows is not realistic. There needs to be a way to enter diacritics and special characters in Sinopia a manner similar to the way catalogers now do this in OCLC Connexion Client (and in ILSs). In Connexion Client, catalogers can use the Enter Diacritics and Special Characters table or they can use keyboard shortcuts (e.g.  will enter an acute accent over a letter).

Related https://github.com/LD4P/sinopia_editor/issues/1240

moving this to general requirements repository as this is out of scope for current grant


Add Alembic in CI

Preparing CI for https://github.com/f3d-app/f3d/pull/179

@nyue taking care of building Alembic in this PR. It's still a WIP. I'll let you know when it's done.

Ok, it was easy! Can you take a look @mwestphal?
@nyue I'm building Imath 3.1.3 and Alembic 1.8.3, is it fine?

Ok, it was easy! Can you take a look @mwestphal? @nyue I'm building Imath 3.1.3 and Alembic 1.8.3, is it fine?

Yes, I have tested Imath 3.1.3 and Alembic 1.8.3 locally on my Ubuntu Box.

update third party licenses.md

update third party licenses

@nyue is adding it in his PR. I don't think it is necessary for this particular PR because I'm only building it.

update third party licenses

@nyue is adding it in his PR. I don't think it is necessary for this particular PR because I'm only building it.

Indeed, not necessary until static link with f3d is present.


x/oauth2: ExampleJWTConfig refers to unknown identifier: JWTConfig

Go version
83d9afefead685d9da8e993e064cbe695111110c
Output of go env in your module/workspace:
"sources": [
    {
      "gitilesCommit": {
        "host": "go.googlesource.com",
        "id": "83d9afefead685d9da8e993e064cbe695111110c",
        "project": "go",
        "ref": "refs/heads/master"
      }
    },
    {
      "gitilesCommit": {
        "host": "go.googlesource.com",
        "id": "b52af7d5b4e39d5bb1ee067d8aa110fcce9e4cc7",
        "project": "oauth2",
        "ref": "refs/heads/master"
      }
    }

What did you do?
I found this error during inspection on riscv64 builder failure.
https://logs.chromium.org/logs/golang/buildbucket/cr-buildbucket/8739983205269594385/+/u/step/17/log/2
What did you see happen?
[I2024-08-10T15:53:48.314465Z 3482694 0 sink.go:276] SinkServer: warm-up started
[I2024-08-10T15:53:48.314693Z 3482694 0 sink.go:346] SinkServer: starting HTTP server...
[I2024-08-10T15:53:48.317957Z 3482694 0 sink.go:281] SinkServer: warm-up ended
[I2024-08-10T15:53:48.318864Z 3482694 0 cmd_stream.go:492] rdb-stream: starting the test command - ["/home/swarming/.swarming/w/ir/cache/tools/bin/result_adapter" "go" "-v=false" "-dump-json" "/home/swarming/.swarming/w/ir/x/w/go.testjson" "--" "/home/swarming/.swarming/w/ir/x/w/goroot/bin/go" "test" "-json" "-short" "-timeout=20m0s" "./..."]
# golang.org/x/oauth2/jwt_test
# [golang.org/x/oauth2/jwt_test]
jwt/example_test.go:13:1: ExampleJWTConfig refers to unknown identifier: JWTConfig
ok  	golang.org/x/oauth2	0.091s
ok  	golang.org/x/oauth2/authhandler	0.029s
ok  	golang.org/x/oauth2/clientcredentials	0.033s
ok  	golang.org/x/oauth2/endpoints	0.015s
ok  	golang.org/x/oauth2/google	3.014s
ok  	golang.org/x/oauth2/google/downscope	0.022s
ok  	golang.org/x/oauth2/google/externalaccount	0.147s
ok  	golang.org/x/oauth2/google/internal/externalaccountauthorizeduser	0.026s
ok  	golang.org/x/oauth2/google/internal/stsexchange	0.038s
ok  	golang.org/x/oauth2/internal	0.053s
ok  	golang.org/x/oauth2/jira	0.043s
ok  	golang.org/x/oauth2/jws	4.091s
FAIL	golang.org/x/oauth2/jwt [build failed]
Warning: no '=' in invocation-link-artifacts pair: "", ignoring
[I2024-08-10T15:55:34.623922Z 3482694 0 cmd_stream.go:488] rdb-stream: the test process terminated
[I2024-08-10T15:55:34.624356Z 3482694 0 sink.go:371] SinkServer: shutdown started
[I2024-08-10T15:55:34.624546Z 3482694 0 sink.go:349] SinkServer: HTTP server stopped with "http: Server closed"
[I2024-08-10T15:55:34.624652Z 3482694 0 sink_server.go:96] SinkServer: draining TestResult channel started
[I2024-08-10T15:55:36.200549Z 3482694 0 sink_server.go:98] SinkServer: draining TestResult channel ended
[I2024-08-10T15:55:36.200729Z 3482694 0 sink_server.go:100] SinkServer: draining Artifact channel started
[I2024-08-10T15:55:36.629527Z 3482694 0 sink_server.go:102] SinkServer: draining Artifact channel ended
[I2024-08-10T15:55:36.629702Z 3482694 0 sink.go:374] SinkServer: shutdown completed successfully
[I2024-08-10T15:55:36.629800Z 3482694 0 cmd_stream.go:420] rdb-stream: exiting with 1

What did you expect to see?
Test pass

Related Issues and Documentation

build: build failure on gotip-linux-amd64-newinliner #65977
build: build failure on x_telemetry-gotip-linux-amd64-misccompile #68012 (closed)
build: build failure on x_telemetry-gotip-linux-amd64-misccompile #67480 (closed)
build: build failure on x_tools-go1.23-openbsd-riscv64 #68231
build: build failure on gotip-linux-amd64-longtest-race #66485 (closed)
x/build: build and test failures on openbsd-amd64 builders #66474
x/build: status for test is missing on LUCI gotip-netbsd-arm64 builder #65488
build: build failure on x_vulndb-gotip-linux-amd64-misccompile #66982
build: build failure on gotip-darwin-amd64_12 #65822
build: build failure on gotip-linux-amd64-misccompile #68016 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

This is a vet error, triggered by the declaration of function ExampleJWTConfig which is contrary to the convention (documented in go help testfunc) that
Godoc displays the body of ExampleXxx to demonstrate the use of the function, constant, or variable Xxx.

So when vet sees a function named ExampleJWTConfig, it expects to see a symbol JWTConfig declared by the package x/oauth2/jwt, which is not the case. The error message is a bit of misdirection because ExampleJWTConfig does not actually "refer to" the undefined symbol, it's just an inference being made by vet.
A simple fix would be to rename ExampleJWTConfig to ExampleConfig, which may have been the original intention: the example function does show the use of the Config type declared in the package.

Fixed by https://go.dev/cl/606878.  Apologies: I forgot about this issue when I sent that CL.


Start using N2 instances for SLES import.

Some SLES tests have started failing since the end of July because of timeouts. SLES import uses E2 instances that can be not optimal for the import processes. The idea is to stay consistent with other Linux distributions and to use N1 instances.
On the other side, as N2 instances provide better performance than N1 we can update the import for SLES to start using N2 and check how it goes. It will be a good starting point before updating machine types for other distributions and tools.

/assign @MahmoudNada0

/lgtm


Sliding panel "jumps" when expanding and using SlidePanelListener

I am using SlidingUpPanel in my layout.  The sliding panel contains a TextView that is set to wrap content.  While the panel is collapsed the textview is set to maxLines = 2, and while the panel is expanded this should be changed to maxLines = 10 (this is because the text needs to be displayed with an ellipsis at the end if the panel is collapsed).  I have the code to do this in the onPanelStateChanged method of a SlidePanelListener.  However, when doing this, the panel "jumps" from its collapsed state to its expanded state without animating smoothly.  Bizarrely, the other way around (going from expanded to collapsed) it works as it should and animates smoothly.
Can anyone explain to me why this is and if there is any way around it?

I think I've figured out what the problem is, but still not sure how to solve it.  I think what is happening is that when I click on the panel while in its collapsed state, it does expand to the size of the textview's content.  However, at this point, the textview is still set to maxLines = 2, so the expanded size is identical to the collapsed size (so essentially, the panel does not move at all).  Once it has done this, only then does the panel state listener fire, the textview changes to maxLines = 10, and so the panel immediately resizes to wrap the content of its new size.
What I need is some way to tell the textview to change to maxLines = 10 before the panel starts expanding.


Update load config logic

Codecov Report

Merging #261 into release-rc3 will not change coverage.
The diff coverage is 0.00%.

@@              Coverage Diff               @@
##             release-rc3     #261   +/-   ##
==============================================
  Coverage          25.05%   25.05%
  Complexity           335      335
==============================================
  Files                127      127
  Lines               4270     4270
  Branches             313      313
==============================================
  Hits                1070     1070
  Misses              3121     3121
  Partials              79       79

Impacted Files
Coverage Δ
Complexity Δ

.../com/webank/wecross/config/ConfigReaderConfig.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...ebank/wecross/config/ResourceThreadPoolConfig.java
36.00% <0.00%> (ø)
0.00 <0.00> (ø)


SAK-32046: Change text 'My Workspace' which still appears

in My Home > Resources

The patch should refer to "Home" and not "My Home" which is the Oxford specific term

@bjones86 apparently the spaces are because the replacement DB entry must have the same number of bytes as the original (so Matt J says)

Yeah there's a checksum on the BINARY_ENTITY field so it has to be equals. I'm thinking of changing it to something like Workspace->cont.work and doing the translation through the regular system.

Some languages for sure are longer than the 9 characters so it will be a problem to change this directly. Like it looks like PT has Área Pessoal.
This unfortunately may be a complex fix since i18n will still be involved.

This issue should be resolved in a more i18n fashion, see the JIRA for more info.


Exporting NAV Data not supported with installed extensions

How can I export the NAV Data from a DB with an extension?

Unfortunately, exporting data from the DB with V2 extensions installed has not be supported until very recently. You will see support for this functionality for the Tenerife Release. (NAV 12.0 OnPrem)

Oh pitty ...
Thank you for the information.
Any possible ideas for a work-around?
Can we export data via sql?
Would the export data work if we uninstalled the extension?

I apologize for the massive delay and hope you were able to find workarounds for your issue.
To answer them now, the export of data should work if the extension is uninstalled from the tenant, however, be sure not to include application data in the export. Similarly importing data will also work so long as the same set of extensions on the 'old' services are on the 'new' one and application data is not included in the import.
Additionally, if using cmdlets, you must use the -ServerInstance parameter set and NOT the ones that use the -*Database parameters.
And again, the new 'NAV 12.0 OnPrem' release has support for export/import with V2 extensions installed so I would recommend using that if this is a hard requirement and you are capable of moving.

Rather have a late answer than no answer :)
Thank you for the solution. I will try it out.
NAV 12.0 OnPrem will become available in November/December? So that's still a long wait ...


unused = meta_task((self.support_x[0], self.query_x[0], self.support_y[0], self.query_y[0]), False)

Hi, I'm working on the source code of MAML, Thanks for your sharing.

when I try to understand

# to initialize the batch norm variables, might want to combine this, and not run idx 0 twice.
unused = meta_task((self.support_x[0], self.query_x[0], self.support_y[0], self.query_y[0]), False)

I don't know why need this line since it's unused??

and

task_outputa = self.forward(inputa, weights, reuse=reuse)  # only reuse on the first iter

This seems to be the only line not reusing variable, I don't understand why this line need NOT reuse??
Thanks.

It is needed when using batch norm, to initialize the batch norm variables -- reuse is set to False here to initialize the batch norm variables that haven't been created yet. After that, the batch norm variables are reused.
The reuse flag is only for the batch norm variables. All other parameters are handled separately.
See the tensorflow documentation for details on how reuse works.