Allow to specify a key for private registries

Tried to build a crate for private repo and it works fine. The fixes actually looks really awkward due to weird git2 interface, would love to hear any comments how to make it more readable.
Related PR in rustwide: https://github.com/rust-lang/rustwide/pull/65
And a version update for crates-index-diff: https://github.com/Byron/crates-index-diff-rs/pull/11

Raising here as in https://github.com/rust-lang/rustwide/pull/65, cloudsmith.io requires .git-credentials and won't support SSH keys.

@l4l what private repo are you using?

I've been using self-hosted meuse quite some time ago. Current version of rustdoc supports only http auth (e.g http://login:password@my-server). Git credentials could be added separately and perhaps unrelated to this PR.

Although the blocked-by PR has been merged to rustwide I missed time slot for finishing this one before the git crate for crates-index-diff has been changed: https://github.com/Byron/crates-index-diff-rs/commit/4cedf27d510ff9031bf9f142ecbb3788a6337f8c. Currently it is using gix which if (I understand correctly)[https://github.com/Byron/gitoxide/issues/106) makes this patch obsolete because now keys in ~/.ssh could be used.


Feature Request: regional setup for monitoring

Describe the solution you'd like
Many scenarios, e.g. regulatory or data compliance requirements, require a more finegranular approach to logging. For instance, logs from EU should be stored in europe, while logs from US should be stored in US. It would be great, if enterprise scale would support such scenarios. A big milestone was added lately, where the diagnostic logs initiative now has a parameter resourceLocationList to specify which logs should go to the log analytics workspace.
This concept should be extended to Azure Monitor (using datacollection rules) and azure activity logs.
Activity logs are often most critical, as they contain PII. Is it possible to configure activity logs to stream to a specific LAW depending on the region the resource is in? Would you then set the activity log setting on each resource rather than on subscription level? What are the downsides from this?
Best regards,
Stephanie

Thanks @steph409! Great feedback. Will discuss on our next leads call and let you know the outcome, as it looks like this will need some validation and updates to guidance.

Hi @steph409. There isn't a pretty or easy way to implement this, however it is possible.
The easiest way to implement this would be to have management groups per regulated region and change the policies for each regions management groups. That way you can have all diag settings and activity logs go to a specific LAW using policy (Corp-EU mgmt group - assign all the diag/activity log policies to this management group pointing to a LAW in EU, etc.).
Otherwise, you would have to configure where for example activity logs get sent on a per subscription basis (which would be a nightmare in large organizations), of course this assumes that all resources in a subscription are bound to a specific region. I would not recommend going down to resource group level, way too easy to make mistakes, and impossible to automate.

Hi @Springstone,
thank you for taking the time to come up with a solution.
I don't think it is possible to have one management group, in which only the resources of one region are. Let's say we have a connectivity subscription, where we deploy a vWAN. vWAN typically has hubs, which are in different regions. As far as I am aware, it is not possible to create the vWAN in one subscription, but the Hubs in other subscriptions and associate them to the vWAN. Now if my users connect to Azure using vWAN P2S. Let's say I want to write those logs to regional workspaces - would this be possible with your solution? If yes how?

which are in different regions. As far as I am aware, it is not possible to create the vWAN in one subscription, but the Hubs in other subscriptions and associate them to the vWAN

vWAN HUBs are kept within the same RG/Sub as  the vWAN.
But you can have different diagnostic logs per vHUB - so you can send your Region A to Log Analytics A and Region B to Log Analytics B - See this article:
https://learn.microsoft.com/en-us/azure/virtual-wan/monitor-virtual-wan

Resource Selectors on assignments are a good fit here https://learn.microsoft.com/en-us/azure/governance/policy/concepts/assignment-structure#resource-selectors

@steph409 do the workarounds provided help you? Doing this at scale in ALZ would be very challenging, as we do this will policy assigned at management group scopes. However, customizing assignments with resource selectors would allow you to be more specific when logging.
Kindly advise if we can close.


Implementing a Windows UWP toolchain

Lately I'm digging around referring Windows 10 Apps and how to build/deploy them. The cross platform Solution from Microsoft is the UWP (https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide)
UWP has restricted API call access, thus it's required to compile all required components and patch the use of restricted API calls if necessary.
SDL2 already supports UWP, and angle as backend is supported too (https://github.com/Microsoft/angle)
@tito implemented angle support a while ago, thus it would be interesting to know whether any of this restrictions - https://github.com/Microsoft/angle/wiki/known-issues - apply to kivy inside UWP. And whether this effort was towards UWP ;) (@tito?)
So the required (maybe incomplete) list of tasks to get a kivy app working as UWP app would include:

Creating a UWP project in Visual Studio
Compile angle and SDL for UWP
Compile python for UWP
Compile kivy for UWP
Write a wrapping view similar as in p4a and kivy-ios
Once the prototype works create a dedicated toolchain, e.g. as kivy-uwp package or similar

Some resources about building from c/c++ for UWP:

https://msdn.microsoft.com/en-us/library/mt186164.aspx
https://msdn.microsoft.com/en-us/library/mt186162.aspx

Now i'm wondering whether:

Anyone is interested in working on this?
Anyone already has build kivy for UWP and is willing to give some guidance / code samples
Anyone knows pitfalls about the above written
Any complaints about the overall planned procedure?

Regards, Robert

I think you have your work cut out for you ;) It does seem it'd require something like py4a (py4uwp?), given that we'd need to compile python and all the project requisites using msvc with that target (UWP).
Your steps seems reasonable, although I'd say rather than solving how to compile kivy for UWP you'd just need to figure out how to compile cython code for UWP. But the amount of work required to get there, including building python and all the deps make it unlikely that kivy would be interested, especially since we're already over-extended and there hasn't been much interest in this before by any devs.

I'd be willing to aid in helping build it on Windows, but I'm not interested in a UWP toolchain; I would rather see a WinForms and/or WPF toolchain (I also don't and won't have a Windows 10 machine to test on).

@FluxIX I already build on windows using pyinstaller and wixtools for creating msi installer. This works great.
Now it would be cool getting kivy apps to the windows app store, windows rt and maybe even xbox.
I am not interested in XAML or build-in MS UI widgets, etc. UWP is interesting due to it's application and runtime infrastructure.
So what's your purpose on using WinForms/WPF over UWP?

@rnixx I don't target Windows 10 because I don't and won't own a Windows 10 machine (for privacy reasons I won't personally use Windows 10 and it seems to be designed for mobile applications instead of the embedded-interfacing applications I work on) and at work the desired target is Windows 7.

@FluxIX Well, my personal machine runs Linux, anyway, the whole thing is not about my personal preferences.
Like it or not, Windows 7 + 8 is supposed to retire in favour of win 10+, forced by MS aggressively. And the MS counterpart to Android Playstore and iOS AppStore is Windows AppStore - which works with UWP. And UWP is not about mobile devices only.
Since this issue is about a long term undertaking I'd prefer to stick to future proof technology here.
BTW - referring to embedded - UWP supports Windows IoT Core as well

I don't simply work with IoT devices; I also work with traditional embedded devices with no IoT components. I also don't write for the Windows AppStore -- clients prefer sideloading as deployment.


AttributeError: 'DataFrame' object has no attribute 'sort'

I am facing this problem when I tried to run python file:
Traceback (most recent call last):
File "C:\Users\12055\Desktop\TCA\Mywork\TCA_2_3_3\TCA2.py", line 168, in
main()
File "C:\Users\12055\Desktop\TCA\Mywork\TCA_2_3_3\TCA2.py", line 143, in main
Algorithm.BSM.Write(clear_buffer=True)
File "C:\Users\12055\Desktop\TCA\Mywork\TCA_2_3_3\TCABSM.py", line 159, in Write
df = df.sort(['transtime', 'Vehicle_ID'])
File "C:\Python27\lib\site-packages\pandas\core\generic.py", line 4372, in getattr
return object.getattribute(self, name)
AttributeError: 'DataFrame' object has no attribute 'sort'
Any one can help regarding this issue. I will be highly obliged.

It comes from this line: df = df.sort(['transtime', 'Vehicle_ID']) which is in your file, not pygridtools.

Thanks. How can I fix this issue?

http://pandas.pydata.org/pandas-docs/stable/search.html?q=sort&check_keywords=yes&area=default


Clean up messages

Hello, I need to clear the history of sent test messages while we test this solution. I thought about deleting data from "SendNotification Data" and "Notification Data", but I’m afraid to creating inconsistencies… Is there a procedure for that?
Thanks.

@pablolimainfo ,
Could you please update us on the status of the issue?

Hi @pablolimainfo, Ideally when you upgrade to our latest version it should show the delete option. Can you please share the screenshot of Deployment center and logs for all function apps (*-function)and web app (of type app service)
To navigate to deployment center.

Go to Resource group in which this instance of CC is deployed.
Select from resource
Under Deployments - > Deployment center.
Send this screenshot.
On this screen only you will get logs option click on it.
Sent the screenshot.

Hello,
Just to give you some context, let me share the background I have. The company started using the app as early as 5.5.2.
There was no git version upgrade, but the business area asked to make small changes to the look and feel of the app application (nothing related to the area where this missing button is located).
In short, the official version 5.5.2 was deployed first and then a new customized version 5.5.2 was uploaded via FTPS. We are currently using this customized version.
App Service:

Function Apps:

Thanks.

@pablolimainfo ,
If an entry has been added to the field - AuthorizedDeleteUpns, please re-sync the app service. For re-sycning the app service please follow the below steps -

Go to portal.azure.com. Navigate to resource group where all CC resources are deployed.
Click on App Service.
Go to the deployment center.
Click on Sync

Once the status turns to Success(active) in the Logs section, please open the Teams app in a webbrowser and check the CC author app.
Note: After adding any entry in the AuthorizedDeleteUpns field, we need to perform the sync for the changes to get reflected for the added user.

@v-jaygupta on click on "Sync" button, will the Deployment Center pull the code from Repository and override our customized version?

Yes It might override the customized version. But we can not certainly comment on this. Just to keep you informed that our support scope is also very much limited to Official version of Company Communicator according to support policy.


Bugfix/home page typo

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Dheer-Rajpoot sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

not neeeded


Fix syntax example

The command in the syntax example does not wrap,
which causes a runtime error.

Why:
Closes ISSUE
Issue: #22820

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[x] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

@Dunky-Z Thanks for catching this! However, we don't accept changes to our translated files as we use an internal automated solution for translations. :yellow_heart:
I'll flag this in our internal system and someone will take a look at it soon. 👀
Closing this PR now. Thank you for your interest in improving GitHub Docs! :sparkling_heart:


Add in insureiq.jar release URL to UG

Once settled with v1.4, update the UG to direct the user to the v1.4 jar release for insureiq.jar

Added link, but have to check at the very end before closing this!

Closes since it's working!


MSISDN being used as both ObjectProperty and DatatypeProperty

The Oresteia example has incorrect usage of observable:MSISDN.  The usage as of UCO 0.7.0 is for this to be a Datatype property, referring to a Literal value with datatype xsd:string.
There was some question on where this incorrect usage originated (Oresteia, or the mobile device and SIM card example), but after a git blame dive, the incorrectly-typed line was found to have originated in this commit.
It's unclear why the example tries to use this property as an object-reference to a MobileAccount object.
This needs to be corrected, first in Oresteia, in a manner that preserves original intent, which unfortunately was only documented in the Git history as "Updated mobile account representation."
Once Oresteia's corrected, other places where this error propagated (several of which are on the website) can be revised.

@cyberinvestigationexpress , you were the author of the originating commit, so it would be helpful if you could advise on how to fix this.

Representation of IMSI and MSISDN were under discussion. The outcome is that IMSI and MSISDN are represented as strings in MobileAccountFacets.


Radiatus build process

Setting up initial build process.
Gets to the point where the UI loads, but further progress is blocked on
https://github.com/uProxy/uproxy/issues/710
https://github.com/uProxy/uproxy/issues/713

Hello!
I'm hoping to make master the default branch later this week, replacing dev. To help with that, I'll try to close all outstanding pull requests on dev, including this one. I don't need to delete this branch or anything else destructive, so please re-open this pull request once master has become the default branch.
Thanks!

Please re-open, on dev.


Update init.py

My Cool PR

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Yay!


Feature Request: Extract specific arm-template type and not only  api

Scenario
Some time as part of the devops process we want only to deploy "products","policyFragments" , ext... and not an api .
Crrently it is not possible to extract any arm template without extract a full api with all its dependencies
Proposal
Give an option to extract single type only by giving as input both the type and name.
For example
Type: "Microsoft.ApiManagement/service/products"
Name:"Myproduct"
Describe alternatives you've considered
No response
Additional context
No response
Contact Details
<EMAIL_ADDRESS>

While I appreciate that this is a requirement for you, it's not something that is in the charter for this tool.  I'd expect this sort of thing to easily be done with Azure PowerShell or Azure CLI scripts, however.  Most things (notable exception: Policy Fragments, which isn't in a GA ARM API version yet) can be done today with Azure PowerShell.

I can vouch for the efficacy of @adrianhall's suggestion.  We use this tool to extract an API's definition, and we post-process the results.  Basically, we remove the non-API-specific items, such as products, global API policy, etc., that we deploy as part of our infrastructure pipeline.  This leaves the API developers to not have to worry about what to do with all of these "extras".


map , and search taking long time to open ,sometimes double click

Description
map , and search taking long time to open ,sometimes double click
https://linkfree.eddiehub.io/
Screenshots

Additional information
can someone please check that  ,this could be frustrating to others

These pages are loading all the users before displaying, we have an issues already open this https://github.com/EddieHubCommunity/LinkFree/issues/2815

thanks , I didn't knew about that .


Redo Documentation

I lost access to the readthedocs.io interface for Bernard repositories.

I don't have access to it either, I think I never even had it.
I can see it under your profile: https://readthedocs.org/profiles/henrikbjorn/

Yeah but i can't login. I'll shoot them an email tomorrow
man. 25. jun. 2018 kl. 19.49 skrev Márk Sági-Kazár<EMAIL_ADDRESS>
:

I don't have access to it either, I think I never even had it.
I can see it under your profile:
https://readthedocs.org/profiles/henrikbjorn/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bernardphp/bernard/issues/385#issuecomment-400037752,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABNDXt1nqaIFHqyvY_E_YwRZomgsx36ks5uASKNgaJpZM4U1jKs
.

Ah, okay.

Haven't heard back from them yet.

I have regained access.
I have fixed the issue on bernardphp-com project.
I think i fixed the docs for bernard also.

Personally i vote for something like GitBook to do better documentation.


Location of tslint.json

Thanks for making this linter. I am running into some issues when trying to configure my tslint.json. Unless I have the tslint.json file in the same directory as the file I am running it against, I get no errors. The only other location that appears to give errors is when I configure a global tslint.json at the root of my home directory.
Is there now way to have a tslint.json configured on a per-project basis? I would prefer to have project-level linting configuration, if that is at all possible.
Thank you.

are you using the CLI? there's a command line flag to point to a specific tslint.json filepath

I'm not running it from the CLI but rather from inside a Vim buffer. The errors are showing up with Syntastic. I originally had the tslint.json file in src/ts/tslint.json while my files were in src/modules/app/, which was not working at all. If I move the tslint.json into the root directory of the project (same level as /src/) then it works. This is better, and makes sense to me. The thing is, the project is not just mine, and I would prefer to not have to move the tslint.json file away from where it is now, because it seems to be working for other people on the team who are using. However, if the only solution is to get it in the root directory of the project, that is good enough.

Yeah I can't imagine how we would auto-detect a config file at src/ts/tslint.json if tslint is run with cwd src/modules/app/. So I'm going to close this with the answer "use the config option in the CLI or Node API".

@adidahiya, my apologies. Apparently the file wasn't working in that location for other people, they had just thought it was so it looked like it was only me having the issue. It works fine in the project root and has since been moved there. Thanks for your time.


PR: Allow for wdir = '' in run_python_script_in_terminal()

Fixes #3155: Executing a python script in external terminal without
specifying a working directory leads to wdir = '', which is not handled
correctly.
In the previous version, the working directory was passed as an option
to the script if xterm is used. This did not make sense to me, so I
removed that.

@jitseniesen thanks for working on this. Could we add some tests :-) for this function.

Also since we are now dealing with wdir possibly being empty, should not we make it a kwargs?, Would this change be too disruptive (many places where this function is called?)
@nodd, @ccordoba12 ?

@goanpeca I thought about adding tests, but I found it too hard :-) What this function does, depends on the OS and on whether certain programs are installed. Furthermore, the function actually runs a script. Should we depend on properties of the testing environment? Should we hide all external dependencies behind mocks?
Regarding making wdir a kwarg, I had a quick look and I think that's a good idea in principle. This function seems to be only called once, in MainWindow.open_external_console() in spyder.py. That function just forwards the wdir it is passed, so probably wdir should also be made a kwarg there. The function open_external_console() is used in two places, in Explorer and Editor, so just changing wdir to be a kwarg should be not too hard.
But if you start rewriting, where do you stop, and do we want to do this? I'm not familiar with the code, I don't find it very easy to read, it needs to handle Python2 and Python3 and different OSes so it needs to be careful with string encodings which I don't really know about, it's hard to test, and we are (as I understand it) close to releasing Spyder 3.0. All arguments (for me) to change the code as little as possible.
On having a further look, I wonder whether the windows branch has the same bug. And if we do decide to rewrite, it seems to me that as you suggested, other arguments should be given default values (all except fname, in fact). I also find it odd that WindowsError is caught in this function and displays a dialog box, but NotImplementedError (unsupported OS) is to be caught in the calling function, where it displays a dialog box; to me, this should be done in the same place.

Hi @jitseniesen yes it might be tricky to make changes right now, so caution at this point would be a good idea :-). Now for testing, in principle the tests folder could include some test script, either as an actual _script_func_test.py file, or as a text string inside the test_***.py
Basically it should be a simple script that has a verifiable output, so I think such script should just write something to a given location that the user provides via arguments and we should assert that that was the case. Since we run tests on appveyor and travis, we are testing on 2 OSs for now, eventually we will add OSX via travis (or split travis for OSX and circle CI for linux like conda-forge does).
The test script could receive a tmpfile and the content to check it worked, something like
script_test_external_console.py <tmpfile> <content>
where tmpfile is a pytest fixture and content is just whatever you want to write to check it worked :-)
What do you think?

Thanks. I'll try to write a test.

I think this looks good, thanks!


Is there a way to skip one particular question/test?

There isn't currently, but we could probably add in a UI button to skip when running locally 🤔

@kostasx this is implemented now :tada:
sorry for taking so long


CP Solver section in the RCPSP-5 Constraint Programming notebook giving a blank outout

The CP Solver section in the RCPSP-5 Constraint Programming.ipynb notebook  is not working but simply giving a empty output (len(results) is empty) when the following is run. The Knapsack Constraint Programming section also suffers from this issue.
solver = CpRcpspSolver(problem=rcpsp_problem, cp_solver_name=CpSolverName.CHUFFED)
solver.init_model()
parameters_cp = ParametersCp.default()
results = solver.solve(parameters_cp=parameters_cp, time_limit=20)

In addition the following warning is displayed
WARNING:discrete_optimization.generic_tools.cp_tools:local variable 'proc' referenced before assignment
Using latest master branch (394926e59bc40086affc1c700015f92bea7bf043), windows 10, minizinc-python 0.9.0 and minizinc  version 2.8.7
Likely an error with the minizinc-python bindings or possibly an update in minizinc itself

I was not able to reproduce with debian 12, minizinc-python 0.9.0 and minizinc version 2.8.7.
I will try on windows but I have access only to a windows 11 laptop...

This adress the questions, thanks, will close this issue


GH connector 2.5.2 - cannot find entry point in dll

Connector was working fine before update... Now send / Receive nodes are throwing up errors saying cannot find entry point in dll:

Can you please confirm if you have the following dll in your machine:
%appdata%\Grasshopper\Libraries\SpeckleGrasshopper2\x64\SQLite.Interop.dll ?

Have you installed any other GH plugin using SQLite?

yes:

and no not aware of any other GH plugin using SQLite

Did some googling and it could be an issue in the updated version of SQlite...! https://stackoverflow.com/a/70152956
We'll downgrade and make a beta release for you to test if that's fine?

sure, that'll be great!

Thanks @weitingkong ! You can get the pre-release called 2.5.3-sqlite from manager or our release page

thanks, I think that's done the trick! 😃

Great! Will ship the fix in the next stable release :)


Window zoom decreases text sharpness

With Excalidraw installed as PWA (Chrome), text elemnts loose sharpness when the window (web view) is zoomed in. Or is it just a feeling?
Shouldn't text be vectorized so that zooming doesn't decrease text sharpness/definition?
100%

125%

In-app rendering is subject to various issues such as sub-pixel rendering and other things that may result in blurriness, mostly out of our control. It shouldn't affect exported output (PNG) though.

In-app rendering is subject to various issues such as sub-pixel rendering and other things that may result in blurriness, mostly out of our control. It shouldn't affect exported output (PNG) though.


Fixed: Issue #138 (Build Fail: Unable to parse configuration of mojo …

This draft PR collects several bug fixes prepared for JAXB-API. :construction_worker_man:
Feel free to review and comment, but please do not merge yet, as this still is work-in-progress. :construction:

EE4J_8 branch is "dead", master is where updates are being made

EE4J_8 branch is "dead", master is where updates are being made

Actually I wanted to target master. Strange. Must be a typo of mine.

Closing as fix already exists in master. Sorry for the confusion!


Clean up CritAncestor tests with hasCondition()

This commit cleans up CritAncestor tests with the factored out hasCondition() func.

\lgtm
\approved
Simple PR so I'll just approve it

Could anyone help with approving the PR? It's still pending. Thanks!

\approve

/lgtm
/approved

Whoops got my slashes mixed up

/approve


Click puzzle rating takes me to my profile

When going to the profile of someone else and clicking on their puzzle rating it takes me back to MY profile

This should be logged at https://github.com/lichess-org/lila/, it's not something LiChess Tools does.

This should be logged at https://github.com/lichess-org/lila/, it's not something LiChess Tools does.

OK will do

This was not the right place to put the bug report

Here is the appropriate bug report https://github.com/lichess-org/lila/issues/16511


Pass the environment variables to the test env, for example CI

When tests are run by vscode-test-web, process.env is empty.
This is inconvenient, for example, when the CI envvar is checked in the test files to detect the GitHub Actions environment.
It would be nice if there is an option to pass all or some of the environment variables from the parent env to the browser env launched by this library, or an option to set arbitrary envvars in the test env.

Thanks, and you are right. Looks like process.env is not the right way but I want to pass values from the command line to the test environment.

microsoft/vscode-test-web#62 - similar but reverse ask, solvable using IPC.


[WIP] Copr: Implements take_scanned_range for BatchExecutorRunner

What have you changed?
This is a sub pr for #5361 . This pr:

[x] Implements take_scanned_range for BatchExecutorRunner
[ ] Add correspond unit tests for it.

What is the type of the changes?
Pick one of the following and delete the others:
Implements take_scanned_range for BatchExecutorRunner .
How is the PR tested?
Updated integration test.
Does this PR affect documentation (docs) or should it be mentioned in the release notes?
No.
Does this PR affect tidb-ansible?
No.
Refer to a related PR or issue link (optional)
#5361

The rest LGTM. BTW why is this PR WIP?

See the description, he want to construct some unit tests.

Any update? Is this PR still WIP?

/run-all-tests

/merge


Running build.cmd produces errors

When building the solution according to the wiki guide, I encounter several errors relating to missing references:
C:\www\msbuild>build.cmd
** MSBuild Path: MSBuild.exe
** Building all sources
** "MSBuild.exe" "C:\www\msbuild\build.proj" /maxcpucount /verbosity:minimal /no
deReuse:false /fileloggerparameters:Verbosity=diag;LogFile="C:\www\msbuild\msbui
ld.log"
Microsoft (R) Build Engine version 14.0.23107.0
Copyright (C) Microsoft Corporation. All rights reserved.

  Microsoft.Build.Framework -> C:\www\msbuild\bin\BWS\Windows_NT\Debug\Microsof
  t.Build.Framework.dll
  XmlFileLogger -> C:\www\msbuild\bin\Samples\Debug\XmlFileLogger\XmlFileLogger
  .dll
  Microsoft.Build.Utilities -> C:\www\msbuild\bin\BWS\Windows_NT\Debug\Microsof
  t.Build.Utilities.Core.dll
  Microsoft.Build.Tasks -> C:\www\msbuild\bin\BWS\Windows_NT\Debug\Microsoft.Bu
  ild.Tasks.Core.dll
  TaskUsageLogger -> C:\www\msbuild\bin\Samples\Debug\TaskUsageLogger\TaskUsage
  Logger.dll
BackEnd\Components\RequestBuilder\IntrinsicTasks\CallTarget.cs(148,16): error C
S0246: The type or namespace name 'TaskLoggingHelper' could not be found (are y
ou missing a using directive or an assembly reference?) [C:\www\msbuild\src\XMa
keBuildEngine\Microsoft.Build.csproj]
BackEnd\Components\RequestBuilder\IntrinsicTasks\CallTarget.cs(27,17): error CS
0246: The type or namespace name 'TaskLoggingHelper' could not be found (are yo
u missing a using directive or an assembly reference?) [C:\www\msbuild\src\XMak
eBuildEngine\Microsoft.Build.csproj]
BackEnd\Components\RequestBuilder\IntrinsicTasks\MSBuild.cs(117,16): error CS02
46: The type or namespace name 'TaskLoggingHelper' could not be found (are you
missing a using directive or an assembly reference?) [C:\www\msbuild\src\XMakeB
uildEngine\Microsoft.Build.csproj]
BackEnd\Components\RequestBuilder\IntrinsicTasks\MSBuild.cs(724,13): error CS02
46: The type or namespace name 'TaskLoggingHelper' could not be found (are you
missing a using directive or an assembly reference?) [C:\www\msbuild\src\XMakeB
uildEngine\Microsoft.Build.csproj]
BackEnd\Components\RequestBuilder\IntrinsicTasks\MSBuild.cs(96,17): error CS024
6: The type or namespace name 'TaskLoggingHelper' could not be found (are you m
issing a using directive or an assembly reference?) [C:\www\msbuild\src\XMakeBu
ildEngine\Microsoft.Build.csproj]
BackEnd\Shared\BuildRequestConfiguration.cs(934,105): error CS0234: The type or
 namespace name 'GetToolset' does not exist in the namespace 'Microsoft.Build.U
tilities' (are you missing an assembly reference?) [C:\www\msbuild\src\XMakeBui
ldEngine\Microsoft.Build.csproj]
BackEnd\Shared\BuildRequestConfiguration.cs(149,105): error CS0234: The type or
 namespace name 'GetToolset' does not exist in the namespace 'Microsoft.Build.U
tilities' (are you missing an assembly reference?) [C:\www\msbuild\src\XMakeBui
ldEngine\Microsoft.Build.csproj]
BackEnd\Shared\BuildRequestConfiguration.cs(163,119): error CS0234: The type or
 namespace name 'GetToolset' does not exist in the namespace 'Microsoft.Build.U
tilities' (are you missing an assembly reference?) [C:\www\msbuild\src\XMakeBui
ldEngine\Microsoft.Build.csproj]
  Microsoft.Build.Framework.UnitTests -> C:\www\msbuild\bin\BWS\Windows_NT\Debu
  g\Microsoft.Build.Framework.UnitTests.dll

    0 Warning(s)
    8 Error(s)
Time Elapsed 00:00:01.92
** Build completed. Exit code: 1

This is using the VS2015 command prompt, on the master branch of this repo

Well, that's interesting.  It's working for me, and the CI server seems happy.  Can you look in (or share out) the verbose MSBuild log (for the snippet you posted it's C:\www\msbuild\msbuild.log) for this failure?  Something's clearly going wrong somewhere.

Just tested the latest master and it works for me as well. VS2015 on Win10.
In regular cmd with git in PATH:
mkdir \test && cd \test

git clone https://github.com/microsoft/msbuild && cd msbuild

"%ProgramFiles(x86)%\Microsoft Visual Studio 14.0\VC\vcvarsall"

build

::     0 Warning(s)
::     0 Error(s)
:: Time Elapsed 00:00:22.04
:: ** Build completed. Exit code: 0

If you don't have git installed, then download master zip https://github.com/Microsoft/msbuild/archive/master.zip, extract, cd into extracted folder in cmd (file explorer > file > command prompt) and run:
"%ProgramFiles(x86)%\Microsoft Visual Studio 14.0\VC\vcvarsall" && build

If you are a PowerShell guy:
mkdir /test; cd /test

git clone https://github.com/microsoft/msbuild; cd msbuild

# can't run vcvarsall in a sane way? so:
&"${env:ProgramFiles(x86)}/MSBuild/14.0/Bin/MSBuild"

# Build succeeded.
#     0 Warning(s)
#     0 Error(s)
#
# Time Elapsed 00:00:17.89

From cmd, without vcvarsasll, it will become "%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild"

@rainersigwald here's the log - it's pretty huge! https://gist.githubusercontent.com/alexfoxgill/3ecf00b25a2b9f749873/raw/ab926078ba9bed8ed529dd2bd687752d437f5995/msbuild.log

It looks like you're missing the BUILD_ENGINE preprocessor definition.  I see that this is the Microsoft.Build output location:
/out:C:\www\msbuild\bin\obj\Microsoft.Build\BWS\Windows_NT\Debug\Microsoft.Build.dll

On my machine it's
/out:O:\msbuild\bin\obj\Microsoft.Build\Windows_NT\Debug\Microsoft.Build.dll

Where does the additional BWS part come from?  Are you adding a new configuration or making other changes to the build process?
I agree with @jasonwilliams200OK that starting from a clean clone is the best next troubleshooting step.
(and yes, when MSBuild is verbose it's very verbose)

That BWS comes from an environment variable:
Platform = BWS
platformcode = 5X

Looks like something specific to @alexfoxgill's machine that then gets mistakenly used in the build process (as Platform is normally used for specifying AnyCPU, x64 etc.)

Good catch, @akoeplinger!  @alexfoxgill can you unset that, then try again?
set Platform=
build.cmd

That worked :smiley:


university official website: https://www.usam.edu.sv/   URL of a page…

university official website: https://www.usam.edu.sv/   URL of a page on the official website where a long-term (>1 year) IT:  https://nuevoingreso.usam.edu.sv/carreras/ingenieria-ciencias-computacion - adding img evidence

@chori503 lib/domains/sv/edu/liveusam: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.


UI: Implement Delete API Call

As the ECMPS system, I need a call made to the QA/Cert Data Maintenance API to delete a record
Given a user has selected one or more records and clicks the delete button
When the user enters the relevant information in the extend pop-up and clicks save/close
Then the information will be saved on the backend and the record(s) information updated in the view table

Confirmed that records can be successfully deleted from UI.


icons hidden in wishlist or compare page for pt_BR locale

Bug report
Title
icons hidden in wishlist or compare page for pt_BR locale
Issue Description
icons hidden in wishlist or compare page for pt_BR locale
Preconditions
1. framework Version- master

Steps to reproduce
1. step1- add pt_BR locale for shop
2. step2- add the product to wishlist by customer login
3. step3- go to the wishlist page

Expected result

Actual result
Wishlist page

compare page

fixed


Add test fixture files for onoff switch

Added fixture files for on-off switch. The change adds one test which is passing on my system.
Note, the device type in the node file is set to 266 (0x010A), which maps to OnOffPlugUnit. This matches what is setup in matter_experimental/switch.py.

I just noticed that the serverList in the OnOffPlugUnit cluster is incorrect. I'll wait to see if there is another other feedback before fixing this.

Thanks!

No problem.


"Ambiguous type" error when a Koin library is exported to Intel & ARM architectures

On our projects we export Koin library to shared framework so iOS app and Swift code can contribute to Koin dependencies tree.
When SKIE is introduced to such a project the XCode build fails on:
Ambiguous type name 'Timer' in module 'shared'
where Timer seems to be org.koin.core.time.Timer.
Interesting is that this happens only when iosX64() is added as target. When only iosArm64() & iosSimulatorArm64() targets are present, the XCode build runs just fine.
Tested on Kotlin 1.9.10 & SKIE 0.5.2
The issue is reproducible on koin branch of this repo: https://github.com/Cleverlance/kotlin-multiplatform-playground/tree/koin/try-skie
Introduction of Koin library is isolated in this commit: https://github.com/Cleverlance/kotlin-multiplatform-playground/commit/eb8319a76622fc8994db694bba72ed29004db835
Full XCode log: Build skie_2023-11-02T13-32-50.txt

Thank you for providing the sample. Thanks to that, I verified this is a different bug. Thankfully, I know what's causing the ambiguity. It's because one of the modulemap files still contains transitive re-export that SKIE removes to avoid the ambiguity.

Fixed in 0.5.4 (but use 0.5.5 as the previous two versions had a critical bug.)

Works fine on the above test project, thanks!


Images don't open on exiting the image slideshow by browser back button

Here is how the issue looks like.

A page refresh can make it work again.

Interesting, going to look into this issue.

@zulipbot claim

@zulipbot claim

@zulipbot abort

I would like to contribute on this issue

I'll like to work on this issue


Can't use call_group() with StringNames

Godot version
ac878ed
System information
Windows 10 x64
Issue description
func _ready() -> void:
	get_tree().call_group(&"test", &"test")

Fails with
E 0:00:01:0877   _ready: Method/function failed.
  <C++ Source>   C:\godot_source\core/object/method_bind.h:176 @ MethodBindVarArgBase<class MethodBindVarArgT<class SceneTree>,class SceneTree,void,0>::ptrcall()
  <Stack Trace>  0D.tscn::GDScript_npyyq:6 @ _ready()

Even though the function takes StringNames as arguments. Using String works fine.
EDIT:
After further testing, seems like this only happens when both arguments are StringName. If either of them is String, the method is called correctly. 🤯
EDIT2:
Also passing any argument makes it work too. So in the above code:
func _ready() -> void:
	get_tree().call_group(&"test", &"test", 1)

fixes the issue (assuming the method takes 1 argument).
Steps to reproduce

Add node to group
Try call_group() with StringNames as arguments (as things should be)

Minimal reproduction project
No response

Closing in favor of #65689


readable code without Ramda-style currying

Sanctuary is defined in part by what it does not support. We have done a good job of managing complexity and entropy, and we must continue to do so if Sanctuary is to live a long, healthy life.
Ramda-style currying—the ability to write both f(x)(y) and f(x, y)—is a source of complexity. I've seen this complexity as necessary to prevent code written with Sanctuary from looking strange to newcomers, which would limit the library's initial appeal and thus limit the library's adoption.
Last night it occurred to me that we could possibly solve (or at least mitigate) the ")(" problem by tweaking the way in which we format function applications.
The ")(" problem
In JavaScript, this reads very naturally:
f(x, y, z)

This, on the other hand, seems unnatural:
f(x)(y)(z)

A day ago my impression was that the only aesthetic problem was having opening parens follow closing parens. I now see a second aesthetic problem, as I hope this example demonstrates:
f(g(x)(y))(h(z))

There's no space. There's a significant difference visually between x)(y and x, y. The nesting of subexpressions above is not immediately clear to a human reader. When we include space between arguments—as is common practice in JavaScript—the nesting is clear:
f(g(x, y), h(z))

This clarity is the primary benefit of Ramda-style currying. I consider S.concat(x)(y) bad style not because of the )( but because if used consistently this style results in expressions which are less clear than their more spacious equivalents.
It's worth noting that multiline function applications are also natural with the comma style:
f(x,
  y,
  z)

x, y, and z are obviously placeholders for longer expressions in this case.
Here's the )(-style equivalent:
f(x)
 (y)
 (z)

My concern is that visually the x is more tightly bound to f than it is to y and z, making the first argument feel privileged in some way.
Learning from Haskell
Sanctuary brings many good ideas from Haskell to JavaScript. Perhaps most important is the combination of curried functions and partial application. We might be able to learn from Haskell's approach to function application.
In Haskell, function application is considered so important that a space is all it requires syntactically: f x in Haskell is equivalent to f(x) in JavaScript. The associativity of function application is such that f x y is equivalent to (f x) y, which is to say that what we write as f(x)(y) in JavaScript could simply be written f x y in Haskell.
Let's consider how the previous examples would look in Haskell:
f x y z

f (g x y) (h z)

f x
  y
  z

All three Haskell expressions are less noisy than both of their JavaScript equivalents. Note that in the second expression it's necessary to use parens. We'll return to this idea shortly.
A small change can make a big difference
The proposal:
When applying a function, include a space before the opening paren.
This means we'd write f (x) rather than f(x), and f (x) (y) rather than f(x)(y). This gives expressions breathing room they lack when formatted in the )( style.
Let's revisit the examples from earlier to see the formatting tweak in action.
f (x) (y) (z)

This looks odd to me now, but I think it could become natural. The key is to see the spaces as the indicators of function application (as in Haskell) and the parens merely as grouping syntax for the subexpressions. It's interesting to note that the code above is valid Haskell.
f (g (x) (y)) (h (z))

Again, this is valid Haskell with "unnecessary" grouping around x, y, and z. The spaces make it easier for me to determine that f is being applied to two arguments (one at a time). This would be even clearer if the arguments were written on separate lines:
f (g (x) (y))
  (h (z))

One could even go a step further:
f (g (x)
     (y))
  (h (z))

This leads quite naturally to the original multiline example:
f (x)
  (y)
  (z)

The space is advantageous in this case too, separating x from f so x binds more tightly, visually, with the other arguments than with the function identifier.
Realistic example
Here's a function from sanctuary-site, as currently written:
//    version :: String -> Either String String
const version =
def('version',
    {},
    [$.String, Either($.String, $.String)],
    pipe([flip_(path.join, 'package.json'),
          readFile,
          chain(encaseEither(prop('message'), JSON.parse)),
          map(get(is(String), 'version')),
          chain(maybeToEither('Invalid "version"'))]));

Here's the function rewritten using the proposed convention:
//    version :: String -> Either String String
const version =
def ('version')
    ({})
    ([$.String, Either ($.String) ($.String)])
    (pipe ([flip_ (path.join) ('package.json'),
            readFile,
            chain (encaseEither (prop ('message')) (JSON.parse)),
            map (get (is (String)) ('version')),
            chain (maybeToEither ('Invalid "version"'))]));

Here's a Lispy alternative which makes the nesting clearer:
//    version :: String -> Either String String
const version =
def ('version')
    ({})
    ([$.String, Either ($.String) ($.String)])
    (pipe ([flip_ (path.join)
                  ('package.json'),
            readFile,
            chain (encaseEither (prop ('message'))
                                (JSON.parse)),
            map (get (is (String))
                     ('version')),
            chain (maybeToEither ('Invalid "version"'))]));

I like the comma style best, although I can imagine growing to like the proposed convention. Even if we decide that the proposed convention makes code slightly less easy to read we should consider adopting it in order to reap the benefits outlined below.
Benefits of replacing Ramda-style currying with regular currying
Although this proposal is focused on an optional formatting convention, it is motivated by the desire to simplify. If we decide that the proposed convention addresses the readability problems associated with )( style, we can replace Ramda-style currying with regular currying. This would have several benefits:

Simpler mental model. When learning Sanctuary or teaching it to others one would not need to read or explain the interchangeability of f(x)(y) and f(x, y) for Sanctuary functions.

One and only one. There would be a single way to express function application (the Haskell way). When writing code one would no longer be distracted by wondering whether f(x, y) is more efficient than f(x)(y). Teams would not need to choose one style or the other (although there may still be f(x) versus f (x) debates).

Agreement between code examples and type signatures. Our type signatures indicate that Sanctuary functions take their arguments one at a time, but our examples currently use comma style which could be leading readers to believe that our type signatures are inaccurate.

Simpler implementation. The currying code in sanctuary-def would become significantly simpler if it only needed to account for f(x)(y)(z).

Poll
I'd love to know where you stand on this.

Reaction
Meaning

:heart:
I already use f(x)(y) or f (x) (y) exclusively.

:thumbsup:
I currently use f(x, y) but this proposal has encouraged me to adopt f(x)(y) or f (x) (y).

:confused:
I prefer f(x, y) but find the arguments for dropping Ramda-style currying compelling. I would adopt f(x)(y) or f (x) (y) if necessary.

:thumbsdown:
I prefer f(x, y) and want Sanctuary to continue to use Ramda-style currying.

Feel free to vote based on your first impressions but to change your vote if you change your mind.

love the rationale @davidchambers
I've taken to real/manual currying in my own code base.  My reasons were static analysis by the editor, a better debugging experience, and (assumed) performance.
But I've never thought of changing the whitespace to avoid the )( "butts" 😄
I'm for it, even if it feels foreign to me right now.  In your final example I like the "proposed" syntax more than the lispy version.
note: I voted  ❤  even though I don't use manual currying exclusively, I do use it in a lot of contexts, and it was the best fitting option there for me.

Consider me a highly enthusiastic supporter of this proposal.
I began switching to a very similar style a few months after I started incorporating Ramda in my toolbox, and as @JAForbes does, I also, increasingly, curry my functions explicitly and manually.
I find this style to be an excellent fit for functional code. The rest of my style is a variation on that of the npm team.
Here's snippet lifted right out of some code I'm working on (ifte is my version of Ramda's ifElse, in this case):
const getValue =
  ifte( isConstructed )
      ( prop( 'value' ) )
      ( id )

I've been thinking about what changes might go in a Ramda 2.0 if we ever get Ramda 1.0 out the door, and one of the best simplifications  I can imagine is to drop all support for polyadic functions.  This of course would make it more Haskell-like, and I think would gel well with this Sanctuary proposal.
But I'm stuck on one thing.  Keeping Fantasy-land compliance would seem to necessitate being able to support certain binary functions, for Foldable, Bifunctor, and Profunctor, and perhaps others.
So I like this proposal, and could see doing something similar with Ramda one day, I'm not quite sure how that could play out.

When I first read this, my thinking was 👎  and here is why:
I am working on a large codebase that dates back to 2013 (maybe older in places)…it has been through 3 distinct teams, none of the original authors are around anymore.
I've slowly been introducing new concepts to clean it up (started with Ramda, then Fluture and recently Sanctuary)…and it's been a slow process. Because of the changes over the years we have a very clear lava layer effect happening.
So my initial thought was… If I now decide to change the way we call our functions then that would be yet another lava layer on top of what I've already introduced…another debt to pay.
Introducing new libraries and concepts such as currying has something that I've done very deliberately and with much forethought regarding my future peers (until recently I've been the sole front end developer on this project).
But, reading the proposal again (and taking more time to do so), I decided to look at the places where I'm using currying and I don't see a large impact (if any) with this new style. It turns out most of the functions I use have an arity of 2 or 3.
I agree with the rationale. The examples look nice, I prefer the first proposal.
I've officially voted 👍 , however I am concerned a little concerned about enforcing it my current project.

Keeping Fantasy-land compliance would seem to necessitate being able to support certain binary functions, for Foldable, Bifunctor, and Profunctor, and perhaps others.

The methods of the Sanctuary data types will need to remain uncurried, but there's no reason that Sanctuary's function-based API must follow suit.
Perhaps, Scott, you're imagining wanting to pass S.mult as an argument to S.reduce, and you're worried that you need an uncurried binary function because fantasy-land/reduce methods expect such a function. In fact, S.reduce requires a curried function, so there's no mismatch.
As often seems to be the case, decisions in the Ramda world involve more complicating factors than decisions in the Sanctuary world. In this case, since R.reduce takes an uncurried binary function one would not be able to provide R.multiply as an argument to R.reduce unless we were to change the type of R.reduce at the same time as we removed Ramda-style currying.

Terrific feedback, @miwillhite. I particularly appreciate the link to the Lava Layer post as I've been making a similar argument at work and I now have a catchy name for this idea:

Sometimes it is better to favour consistent legacy technology over fragmentation.

Upgrading to a version of Sanctuary which no longer provided Ramda-style currying would not be trivial, but there are a couple of things that could assist with the transition:

Sanctuary's run-time type checking would highlight call sites with multiple arguments; and
we could write a source-to-source transpiler for replacing occurrences of S.<name>(x, y) with S.<name>(x)(y) or S.<name> (x) (y) based on the user's preference.

I decided to look at the places where I'm using currying and I don't see a large impact (if any) with this new style. It turns out most of the functions I use have an arity of 2 or 3.

I'm confused by this. Sanctuary functions of arity 2 or 3 would be affected by the change unless you're already using the f(x)(y) style. Could you clarify this comment?

An example:
// fn1 :: a → b → c
// fn2 :: a → b → c → d

// Where currently I'd have something like this:
pipe([
  f1(a),
  f2(a, b),
])(foo);

// With the change, (spacing arguments aside) I wouldn't need to change the way I call f1
// and f2 would only have a slight difference:
pipe([
  f1(a),
  f2(a)(b),
])(foo);

// With spacing adjustments I see a lot more impact…something like
pipe ([
        f1 (a),
        f2 (a) (b),
     ])
     (foo);

As often seems to be the case, decisions in the Ramda world involve more complicating factors than decisions in the Sanctuary world.

Yes, and I'm not worried about transitional issues.  If Ramda went all the way to unary-only functions, we'd muddle through the transition.  But I would worry about, say, delegating a Foldable f a :: (b -> a -> b) -> b -> f a -> b to Fantasy-land's Foldable f => f a ~> ((b, a) -> b, b) -> b.  For b -> a -> b and ``((b, a) -> b` would then require some translation before delegating, and that sounds confusing.

@miwillhite:
To my mind, the LISP-style indentation is not the key.  This would still be compatible:
pipe([
  f1 (a),
  f2 (a) (b),
]) (foo);

But maybe I'm misunderstanding David's suggestion.

@CrossEye you are correct…I took some liberties in my response to play around with what it might look like in the "ideal" state ;)

Seems like I'm in minority here but I'm a :-1: on this, Sanctuary is opinionated enough without now telling me how to format my code. I reckon I'd have a mutiny on my hands if I tried to introduce this to my team because I couldn't defend a library imposing something as subjective code style.
I'm also not convinced by the points in the benefits section: 1 and 3 are complete non-issues imo because if they were real problems we'd have had at least one person mention them in Gitter or file a bug report but they never have. 2 is just a matter of personal preference, for instance, I've no problem with there being more than one way to do things in programming: it strikes me as an utterly natural consequence of the variety of cognitive models different human beings possess and yet people have written whole books arguing the opposite. Who's to say who's right? The only compelling argument for me is the simpler implementation of sanctuary-def's currying code but that seems to be around making our lives easier, i.e., the maintainers, rather than our users.

But I would worry about, say, delegating a Foldable f a :: (b -> a -> b) -> b -> f a -> b to Fantasy-land's Foldable f => f a ~> ((b, a) -> b, b) -> b. For b -> a -> b and ((b, a) -> b would then require some translation before delegating, and that sounds confusing.

We do need to transform b -> a -> b into (b, a) -> b, but this is straightforward:
function reduce(f, initial, foldable) {
  return Z.reduce(uncurry2(f), initial, foldable);
}

For people unfamiliar with the Fantasy Land spec there's no confusion. I can imagine authors of Fantasy Land -compliant data types assuming that S.reduce simply forwards its arguments to the underlying method, but I don't consider the use of uncurry2 surprising. I see the fantasy-land/-prefixed methods as the messy machinery with which we can build a beautiful API. The type of S.chainRec, for example, differs significantly from the type of the underlying function:
S.chainRec :: ChainRec m => TypeRep m -> (a -> m (Either a b)) -> a -> m b

chainRec :: ChainRec m => ((a -> c, b -> c, a) -> m c, a) -> m b

Thanks for the example, @miwillhite. That's very helpful. I see the point you're making. Given that you're often writing pipelines, one argument is often provided later. This means you're only providing two arguments at once to functions which take at least three arguments, which are not common.

Thank you for sharing your thoughts, @svozza. Dissenting viewpoints are particularly valuable. Out of interest my vote is :confused: (I selected all four options initially to make voting easier for others). I've been surprised by the enthusiasm with which this issue has been greeted overall.

Sanctuary is opinionated enough without now telling me how to format my code. I reckon I'd have a mutiny on my hands if I tried to introduce this to my team because I couldn't defend a library imposing something as subjective code style.

To be clear, I'm not suggesting that we dictate how anyone format their code (aside from Sanctuary contributors, of course :stuck_out_tongue_winking_eye:).
As Sanctuary grows it will naturally become incrementally more complex; I'm keen to find ways to offset this. Removing Ramda-style currying would reduce complexity, but I've considered the costs to be too high. Since I have reservations about giving up my beloved commas, it's easy imagine others being surprised or upset if S.concat(x, y) were to become a type error.
This issue is about exploring the possibility of embracing the simpler currying that @JAForbes and @kurtmilam now use in their projects. It's as much about seeing whether I can convince myself that I could live happily in a comma-free world as it as about me convincing others. Furthermore, our comma-free worlds needn't look the same. Mine may involve f (x) (y) and a mental trick to help me sleep at night whereas yours may simply involve f(x)(y). If every member of the community could find some way to be happy in a comma-free world I'd be happy to make the breaking change.
Stefano, could a mutiny be prevented if S.concat(x, y) were to become S.concat(x)(y) and there were a command-line script to automate the translation?

Another potential point in favor of the simpler style of currying is simplifying TypeScript typings.
I'm a TypeScript noob, but my cursory research suggests that it's not yet trivial to type a variadic curry function like Ramda's, although @tycho01 is actively working to simplify things in this regard.
It seems, on the other hand, that creating typings for manually curried functions is already trivial:
function add(x: number): (y: number) => number {
    return function(y: number): number {
        return x + y;
    }
}

To be clear, I'm not suggesting that we dictate how anyone format their code

Sorry, I was being hyperbolic but I find the )( way so ugly that I think I'd be compelled to use some variant of the proposed style just to keep the code readable. I don't feel like I should have to make that choice in order to use Sanctuary.
Regarding the script, I guess that could be a good compromise but it also means that I then have to introduce a build step and one of the things that Sanctuary has taught me to appreciate is how nice it is  to be able to eschew all that. It was only when I saw the contortions others (just look at the ES6 PR in Ramda for example, for example) on the frontend have to go through with Babel etc that I realised how easy my life was having only ever used Node.js for backend development. I would be reticent give that up.

@kurtmilam: yeah, that sounds accurate.
In fact, in your manually curried example I think the type would just be inferred already:
function add(x: number) {
    return (y: number) => x + y;
}

Then again, the inference would break down with e.g. iteration.
fwiw on this proposal I'd have a slight preference toward pro-choice for user-friendliness. anecdotally, my current style had been fn(a, b)(c), separating only the values, which may look funny but meant values were clearly identified while remaining composition-proof (unlike fn(a, b, c)).

Regarding the script, I guess that could be a good compromise but it also means that I then have to introduce a build step and one of the things that Sanctuary has taught me to appreciate is how nice it is to be able to eschew all that.

I wasn't clear. I'm proposing a script to be run once per project to update files in place:
$ sanctuary-migrate index.js lib/**/*.js

It would save each of us from performing the :%s/, /)(/gc replacements manually.

Ah sorry, I thought you meant we'd provide a script for people to run as part of their build that allows them to use the old style, like a Babel transform. Yeah, for the Sanctuary project I just assumed we'd script it, it would be such a pain to do manually.

I voted 👍  not necessarily because of the specific arguments, but more from a general point about clarity and the learning process. I say this as a relative newbie who still struggles with the basics.
Most of the friction I've experienced in switching to more functional-programming inspired code is due to mixing new ideas with old habits. I look forward to breaking those old habits and learning new ways of writing (and hence thinking). Really, if I could hit a button and make that transition now I would. The reality is though that I kindof need to be forced into it, otherwise I'll naturally follow the path of least resistance, at least some of the time.
If (a)(b) or (a) (b) is more accurate in terms of what currying should look like, then that's what it should be - old habits be damned! :) Learning to adapt a clearer approach will pay off in the long run. Those who don't put in the investment it takes to change this habit are unlikely to put in the investment it takes to change plenty of other habits relevant to this space (avoiding mutation, passing monads around, writing things more declaratively, etc.). Maybe that can't apply to everything (e.g. if you could enforce writing type signatures for every function, which I'd actually appreciate), but I think for something as fundamental as this it's a fair ask.

In other words, I think this:

the library's initial appeal

Will be resolved by a larger movement of programmers who are using functional programming in javascript to deliver better code and meet managements expectations more thoroughly. Word will spread and the results will speak for themselves. To accomplish that, the library genuinely needs to be the best it can be to deliver results, and imho I think that should be the primary focus.
It's of course easier to say that when I have no ownership/responsibility of the library - but I genuinely think programmers are an adaptable bunch who will learn what they need to in order to be more productive. Javascript in general requires a frightening amount of adaptability to survive in the current ecosystem, much moreso than other languages imho or at least in different ways. Coming off of a background in Unity-c#/flash-as3/Go/C - the learning path was always about building on previous knowledge. Only in javascript am I finding that I have to keep going back and learning new fundamentals, like the rug is continually being pulled out from under me - and it seems like it's just part of the game here. To be an effective javascript programmer you kindof need to get used to that. That's my experience at least after moving to the browser around half a year or so ago.

Kindof going on a rant here so I'll stop soon - but one last point, while I think the focus of the library itself should be primarily based on the best technical decisions, I'd say the exact opposite for the documentation and tutorials.
A very clear explanation that assumes zero prior knowledge and gets people used to the "new" style would be far more powerful than supporting both styles. That's just my opinion though, take with a grain of salt :)
(fwiw this is already a known issue in general, e.g. https://github.com/sanctuary-js/sanctuary/issues/210 and https://github.com/sanctuary-js/sanctuary/issues/419)

I've created https://github.com/sanctuary-js/sanctuary-def/compare/master...davidchambers/simple-currying in order to see how much complexity we could remove from sanctuary-def's internals were we to abandon Ramda-style currying. It's beneficial (in my view) that a curried function would report its length as 1, in accordance with its type signature. One minor unanticipated benefit of this change is that we'd no longer be forced to impose an arbitrary limit on the number of arguments a function may accept.
It's worth having a look at the diff to see the f(x)(y) style in action (def itself is defined via def, so requires its arguments one at a time).

On TypeScript: Personally, rather than let the current limitations of TS influence the functionality of the library as a whole, I would opt to simply restrict the TS definitions to the subset of functionality they can easily express. Variadic interfaces already have no choice but to do this. Additionally, TS is moving fast and likely to be in a very different place 2-3 years from now. By then it may have expanded to support typing anything you would have dropped because of it.
Not to rag on TS on too much, but before even getting to currying it's already in fairly poor shape to safely handle higher order functions due to parameter bivariance. That plus inferred generics is a massive foot gun. Unless you're writing for TypeScript first, this has the same answer: Shape the types as best you can, then throw up your hands and wait for improvements.
On the readability of simply curried functions: Purely subjective, but as soon as I see a pointfree thing that's at all hard to read my first reaction is FP Extract Method rather than worrying about whitespace. I think the formatting alternatives above are all reasonable, but I'd use 3-5x the declarations myself.
If moving to simple currying, you might also consider keeping completely non-curried versions around. No opinion on whether it's the same function or not, but dealing with a single polyadic interface is pretty trivial. The net result would be (a)(b)(c) and (a, b, c) instead of every possible paren permutation plus placeholders. Two versions no matter how many arguments. Comma lovers could have their commas. Implementation of the non-curried version could be simply calling uncurry on the curried implementation. Even if this isn't appealing, users could always do the same thing.
There may be another middle path approach like the above that ends up being a win. I'm new to the library so grain of salt!

Shape the types as best you can, then throw up your hands and wait for improvements.

I like this approach. It suggests that regardless of what we eventually decide here we could provide curried type definitions only in #431. By simplifying our requirements we could release something sooner, then decide whether to take on the complexity of handling all the other combinations.

I'm new to the library so grain of salt!

Your perspective as someone new to the library is invaluable.

I'm fairly familiar with Ramda but haven't written anything major in it yet*, but haven't sat down and learned Sanctuary even though my vague impression is that it's type-strict Ramda and some companion Fantasy-Land libraries. I've got sort of lava layers in my own habits inasmuch as, like someone else here mentioned, I'm trying to learn to apply functional ideas but am still in the process of learning. I really like the idea of partial application since reading about the whole data-last thing and seeing examples of how much more composition Ramda enables, but it took me a while to get to where I feel like currying -- everything being partial application anyway -- is the "clean" way to do it (although it certainly helped that JavaScript's explicit partial application functions are all... clunky).
In my mind at this point in my developer growth, here's how I feel about syntax:

f(x, y, z) makes sense for non-curried functions (or (f x y z) if you feel the need to encode functions as linked lists of data, but I digress)
f(x)(y)(z) is hard to read even though it makes sense for curried functions
f (x) (y) (z) looks a little odd, but makes sense for curried functions and is easy to read (much like how (f x y z) is bizarre until you understand what it really means -- and how things like (+ 1 (* 2 3) 4) nest uniformly instead of requiring tons of operators chained toegher -- and then it actually becomes surprisingly clear)

My initial reaction to the recently suggested idea of providing both uncurried and simply curried versions of the functions, with one automatically derived from the other, is that it seems great; but, on the other hand, I don't happen to know whether there's a ton of advantage of Ramda or Sanctuary over, say, Lodash or Underscore with arguments switched around, when not taking advantage of the currying at all.
I do think using f(x, y) to mean "supply only the first two arguments to f(x, y, z)" is a lot less obvious than using f(x)(y) (or a more readably spaced variation) to mean that, or even than using f(x) to mean "supply the only first argument to f(x, y)". So the Ramda-style currying doesn't make a lot of sense to me to begin with -- in hindsight, the mixed way of thinking it encouraged exacerbated my initial wariness of currying because "how will I know whether this code is calling a regular function that returns a value or supplying the initial arguments to a curried function?" (now my answer would be "if it passes the arguments one at a time, it's obviously curried, if it passes multiple arguments, it should not be curried, and if it's only passing one argument you should be able to tell from whether the return value is named like an operation or is passed into something expecting a callback.")
* I was very tempted to write my current project in Ramda as much of it is just data transformation, but I felt at the time that if I went with Ramda I'd wind up trying to make everything point-free, and didn't know who I'd be partnering with to maintain it in the future, so I decided to look for some kind of compromise instead of counting on being able to teach a future colleague how to read point-free style in order to understand any of the codebase at all.

@ScottFreeCode:

I don't happen to know whether there's a ton of advantage of Ramda or Sanctuary over, say, Lodash or Underscore with arguments switched around, when not taking advantage of the currying at all.

Function composition, R.pipe and its variants. Don't need to name a variable per operation, and you get to read in a nicer order than h(g(f(x))). Lodash-FP exists but is an afterthought in terms of documentation.

Ha, can't believe I forgot about compose/pipe and things like add not being widely available outside of Ramda/Sanctuary. I knew I'd learned multiple great ideas from Ramda, but wow, the things I take for granted after I get used to them -- even if I'm not even using them day to day...
I guess that's pretty clear then -- there are at least some uses that might be worth exposing the functions in an entirely uncurried version in addition to a hypothetical simply curried version, regardless of whether Ramda-style currying is kept or dropped!

The great things about Ramda's style currying function is they it's readable, and f(x, y) seem more natural rather than f (x) (y).

The great things about Ramda's style currying function is it's readable, and f(x, y) seem more natural rather than f (x) (y).

I agree, @syaiful6. My poll response was :confused: for this reason. I'm starting to think, though, that the sacrifices we're making to support two styles outweigh the readability benefits of doing so.

If we want to drop Ramda style currying function, we maybe need to introduce partial function, so it's become Clojure-like.

If I'm understanding you correctly you're suggesting this change:

f(x)(y)(z)
f(x, y)(z)
f(x)(y, z)
f(x, y, z)

I'm suggesting this change:

f(x)(y)(z)
f(x, y)(z)
f(x)(y, z)
f(x, y, z)

I can't imagine ever giving up f(x)(y)(z) as it is central to the Sanctuary experience (and to the Ramda experience). S.partial(S.prepend, [x]) is awkward when compared with S.prepend(x).
I'm proposing that we take a step closer to Haskell rather than to Clojure. :)

@dakom:

If (a)(b) or (a) (b) is more accurate in terms of what currying should look like...

I think that's a fundamental "if".  Undoubtedly, that's closer to what Schönfinkel and Curry first noted: that functions of multiple parameters could always be stated in terms of nested functions of single ones.  (Mathematically, there's another way to accomplish this, with a domain simply being the crossproduct of each parameter's domain.  This can be useful in programming as well, as evidenced by Function.prototype.apply, but it's very different from our currying.)
Ramda's version of currying grew out of the same spirit as the rest of the early parts of the library: it was a learning experiment, focused on the question of how we could take the techniques that make functional programming so useful and port them into reasonably familiar Javascript.  My go-to example is often this one, expressed here in Haskell:
myTotal = foldl add 0 myLineItemTotals

which leads to this function:
invoiceTotal = foldr add 0

which, in turn, has the obvious abstraction
sum ::  Num a => [a] -> a
sum = foldr add 0

Porting this notion to Javascript had to us at the time an obvious version:
const sum = reduce(add, 0)

We weren't really porting over the specific Haskell syntax, just the notion of partially applying a function to get a new one with fewer parameters.  We did consider pure currying, but felt, especially before ES6 became so common, that this was too far from common JS practice:
const f = expr(a, b, c)
curry(f)(a) ~> function(b) {return function(c) {return expr(a, b, c)}}

Whereas this was more easily understandable:
const f = expr(a, b, c)
curry(f)(a) ~> function(b, c) {expr(a, b, c)}

Ramda opted for the flexibility that allowed either usage.
With ES6 arrow functions this no longer seems as big an issue:
const f = expr(a, b, c)
curry(f)(a) ~> b => c => expr(a, b, c)

and its no longer clear if the additional flexibility of Ramda's version is worth either the cognitive burden or the implementation complexity.  And if we were to pick one, the version closer to the Schönfinkel/Curry ideas would surely carry the day.
That's why I'm intrigued with the proposal for Sanctuary.  I don't share David's love for the comma, although I am certainly used to it.  There is a lot to be said for the clear simplicity of pure currying.  And the suggested spacing of
f (a) (b) (c)

makes it feel much more like the Haskell equivalent.
I'm not sure I love it, but I do think it very much worth considering.

@miangraham:

If moving to simple currying, you might also consider keeping completely non-curried versions around. [ ... ] The net result would be (a)(b)(cNo opinion on whether it's the same function or not, but dealing with a single polyadic interface is pretty trivial.) and (a, b, c) instead of every possible paren permutation plus placeholders.

:-1:
I see no reason to keep (a, b, c) and not (a)  (b, c) or (a, b)  (c).  I think it's either go whole-hog, and turn it into strictly (a) (b) (c) or don't bother.

@CrossEye - thanks, while I can't (yet) understand the Haskell examples entirely, the clear breakdown is awesome - it's great to understand the history here with greater clarity. Diving into all this before ES6 must have been a blast ;)

@CrossEye

I see no reason to keep (a, b, c) and not (a) (b, c) or (a, b) (c).

To clarify what I already wrote: The implementation (library complexity) and the interface (wrapper/user complexity) are significantly simpler when you stop supporting every possible combination of parenthesis and commas. Only supporting (a)(b)(c) means 1 version of the function no matter how many arguments. This is good. Supporting (a)(b)(c) and (a, b, c) is 2 versions no matter how many arguments. Not as good but not a big deal. Supporting all combinations is 2^(n-1) in the number of arguments (every space between arguments is either , or )().
That's a big difference, especially when you're currying functions with 5+ parameters. This is at least one reason why Ramda needs code generation to express its curried functions as TypeScript interfaces. Going from 2^(n-1) to 2 here would still be an enormous win.
I didn't want to weigh in on this specifically but so my motives aren't mistaken: FWIW I'm also completely in support of purely unary currying. I love Haskell's approach and think widespread arrow functions now make this work pretty well in JS. Pretty sure we agree on this.
My suggestion was spitballing to see if a simple addition could ease the transition. As I mentioned above, it's not a big deal--building the second interface is just a call to uncurry(). If the library doesn't want it and users do, adding it is trivial.

As for TS, we'll get past the codegen, hopefully sooner rather than later. I think the only relevant issue for which I don't have a PR up yet (be it WIP) is https://github.com/Microsoft/TypeScript/issues/17471.

Going from 2^(n-1) to 2 here would still be an enormous win.

I agree.
Another reason we might decide to support (a)(b)(c) and (a, b, c) in some fashion is that the underlying implementations are uncurried functions. def takes an uncurried function and returns a curried function which performs type checking. We may decide there's value in exposing the wrapped function. After defining const add = def('add')({})([…])(_add);, for example, add.impl could be a reference to _add. Sanctuary could then potentially expose this as S._add for convenience. I'd prefer to avoid even this degree of complexity, but it's worthy of consideration.

gotta run - but another tiny data point, one of the earlier pains I experienced as a newbie is reading type signatures which looked very foreign to me. It might seem like a small thing but the consistency of seeing a -> b -> c in the docs, writing code as a => b => c, and using Sanctuary as (a) (b) (c) helps it all click a little easier - one less hurdle to overcome for understanding how things fit together

ramda/ramda#2272 shows that Ramda-style currying, which seems natural to those of us who've "grown up" using it, is not natural to everyone. This is one more data point in favour of simplification.

+1 for simplifying to only one argument at a time for each function call. I've found myself always using f(a)(b)(c) when using Ramda and Sanctuary even though it's not enforced, because:

It's consistent with how currying works in other languages (Haskell, PureScript, etc.)

It's simpler to limit how the curried functions can be called to just one way. When you allow multiple ways, there will inevitably be members of a team who use g(b, c) and others who use g(b)(c), and you'll end up with apps with mixed, inconsistent codebases. While not the biggest problem in the world, it's definitely simpler to have all the code read the same way.

I think I'm with @CrossEye in that I'm used to & don't have any issues with using commas, but don't share the love for them.
Personally, even though some people find the )( style aesthetically displeasing, I think it's valuable in that immediately clues the reader into the fact that they're dealing with curried functions precisely because it looks different from standard, non-curried/non-functional JavaScript. I think that's helpful when working with teammates who are new to FP & currying in JS, because they might not realize where the g in g(b, c) comes from or that it is a curried function itself otherwise. So, I see it as a helpful visual cue.
As for the extra spacing of f (a) (b), I agree that it does look slightly nicer and more Haskell-like, but I don't have strong opinions about it vs f(a)(b). They're both doing the same thing, after all. Although the non-spaced version does looks slightly more noisey, I just see it as an artifact of the language. JS requires parens for function calls, unlike ML style languages. So, it has parens. ¯_(ツ)_/¯
Also, there might be trouble in getting the spaced convention adopted, because there are a lot of popular linting configs that disallow spaces between function names and parens when calling functions. I believe even StandardJS has this rule, despite requiring spaces between them in function definitions.

Thanks for your feedback, @joshburgess.

there might be trouble in getting the spaced convention adopted

My intention is not to get everyone to adopt one particular set of formatting rules. The impetus for creating this thread was the approach that occurred to me that I thought might make strict currying more palatable to some people (including me). Those already treating Sanctuary functions as if they were strictly curried are already aboard the train and will be unaffected if we switch to strict currying.

@davidchambers Personally, although it's foreign to idiomatic JS, I like the spaced style you presented. I would prefer to use that if given the choice.
I always thought it was slightly odd for StandardJS (the linting config I use for plain JS) to require spaces in definitions and require no spaces in calls. Although, I suppose people could just add an override to turn off that conflicting rule. Many already do that to allow trailing commas, etc. anyway.

So with the proposed drop of Ramda currying, function application would switch out a few commas for brackets, as demonstrated.
The effects on say function composition would be a bit bigger, fwiw. Given a previously Ramda-curried binary function, let's call it f1, an expression like f2(f1(a, b)) could previously have been rewritten as pipe(f1, f2)(a, b). With simple currying, one could still write pipe(f1(a), f2)(b) instead. pipe(f1, f2)(a)(b) on the other hand, would no longer be equivalent.
I was thinking the change might also affect places where previously we'd be expecting multi-ary callback/whatever functions, but so far no concrete examples have come to mind.

Given a previously Ramda-curried binary function, let's call it f1, an expression like f2(f1(a, b)) could previously have been rewritten as pipe(f1, f2)(a, b). With simple currying, one could still write pipe(f1(a), f2)(b) instead. pipe(f1, f2)(a)(b) on the other hand, would no longer be equivalent.

This is a problem for Ramda but not for Sanctuary. S.pipe takes an array of unary functions. ;)

@tycho01 I think your pipe example is a good example of the case for Ramda's o:
Written with o and simple currying (should work, haven't tested):
o( o( f2 ) )
 ( f1 )

Regarding R.pipe, I usually swap it out for a binary version in my projects:
const pipe = R.apply( R.pipe )
// this:
R.pipe( f1, f2 )( data )
// becomes this:
pipe( [ f1, f2 ] )( data )
// or just use Sanctuary's pipe, which works the same way:
S.pipe( [ f1, f2 ] )( data )

Honestly from my viewpoint (as a beginner), Sanctuary isn't for beginners into functional javascript anyway. Just going to https://sanctuary.js.org/ to learn more about the project scares me away from using it.
I think Ramda is more well known at outside fp community and serves as a good starting point for beginners. I've only looked into Sanctuary as a means for handling option types.
What I'm trying to say is there any data to support that Sanctuary is a destination for newcomers that would be scared away by the suggested change?

@dardub anecdotally, for me: a => b=> c => {...} is straightforward and easier to understand than curry((a,b,c) => {...}).
It does make it a bit harder to port old habits/code, but it's a native language thing and easier to grasp without having to read up on "currying" and other FP-specific things.
Personally, I don't think this issue is the obstacle for newcomers. ymmv

A hesitant +1 for this. The thing is, sometimes being forced to curry a long sequence of arguments ends up revealing a point-free representation using standard combinators, which pays for itself by deleting (a, b, c, ...) => at the beginning of the function.

I just changed my vote from :confused: to :+1:
I've adopted this style of function application in all of my experimental work and I've come to appreciate the reduced mental load a lot.
I'm becoming increasingly eager to use this style across an entire project, and I think that in my case, the kind of projects suitable for using this style greatly overlap with the kind of projects suited for using Sanctuary.

Aldwin, I too have just changed my vote from :confused: to :thumbsup:. I've come to appreciate having fewer commas in my code. I find f ([a, b]) ([c, d]) clearer than f([a, b], [c, d]). Only using , in [e, e, e] and {k: v, k: v, k: v} allows me to infer context: if I see 1, 2, 3 I know these are array elements rather than arguments even without seeing the surrounding square brackets.
Ramda-style currying is on the way out: sanctuary-js/sanctuary-def#179. Sanctuary functions will be “simply” curried from v0.15.0 onwards.

Re: commas, I find it also removes some friction in thinking where to place them for multi-line calls. One less thing to think about :)
One issue I've come up against though is for optional parameters. Is the idiomatic way to deal with it to always wrap in a Maybe? e.g.
  const foo = arg => maybeCallback => {
    //do stuff with arg, get result
    S.map (c => c(result)) (maybeCallback);
  }

  foo (bar) (S.Nothing);
  foo (baz) (S.Just(myCallback));

I hadn't seen maybe callbacks, but one approach is to put all arguments in
an object with some keys optional.
On Dec 18, 2017 10:47 AM, "David Komer"<EMAIL_ADDRESS>wrote:

Re: commas, I find it also removes some friction in thinking where to
place them for multi-line calls. One less thing to think about :)
One issue I've come up against though is for optional parameters. Is the
idiomatic way to deal with it to always wrap in a Maybe? e.g.
const foo = arg => maybeCallback => {
//do stuff with arg, get result
S.map (c => c(result)) (maybeCallback);
}
foo (bar) (S.Nothing);
foo (baz) (S.Just(myCallback));
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sanctuary-js/sanctuary/issues/438#issuecomment-352375928,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC6uxZAPtsNNBh-xBoz5xP86-F-r8-Heks5tBjSjgaJpZM4PKLTy
.

Tasks:

[ ] Remove placeholder (S.__)
[ ] Remove S.A
[ ] Remove flipped operator functions (S.lt_, S.lte_, S.gt_, S.gte_, S.sub_, S.div_, S.pow_)
[ ] Change types of operator functions from _ -> (_ -> _) to _ -> _ -> _
[ ] Reformat doctests
[ ] Upgrade sanctuary-def dependency

Is there a https://prettier.io configuration for this function application spacing style?
I think it goes against adoption if we help people to configure their automatic code formatters accordingly.
I'm just using the built-in IntelliJ settings, btw, but I would consider switching to prettier.

I just noticed https://github.com/joelnet/eslint-config-mojiscript which seems to achieve this style with eslint.

If you find a solution that works for you, @onetom, please share it here. We could then add it to the readme and website.

I can confirm that eslint-config-mojiscript allows for automatic reformatting of the parenthesis and some other helpful linting.
npm i -S eslint-config-mojiscript
.eslintrc.js
{
  ...,
  extends: 'mojiscript',
  ...
}

I have prettier configured to defer to eslint for formatting, but I'm not sure if prettier is necessary for the auto fix.
I'm not completely sold on simple curry vs. ramda style curry, but I definitely see the benefits. I'm currently weighing pros and cons for my project.
This conversation makes me wonder if it would be feasible to create a babel plugin to just allow for the Haskell style parens on top of the simple curry style. If anyone knows of any similar plugin or has a deep knowledge of babel, I would be interested to know if that's doable.

Thank you for sharing this information, @RichardForrester.

My curiosity got the better of me today and I decided to do some digging into Babel to see how much work would be involved to get a babel plugin to transpile:
map inc (filter isOdd [ 1, 2, 3 ])  //=> [ 2, 4 ]

to:
map (inc) (filter (isOdd) ([ 1, 2, 3 ]))  //=> [ 2, 4 ]

Or as @davidchambers put it, to solve the ")(" albeit from a different angle.
 Quite amazing really, sky is the limit -- in fact, it seems that sanctuary-def could be made entirely passive by converting it to a babel plugin, complete with production ready transpilation (just add a hindley-milner comment above your def). Or, really anything else you can dream up.
However, if you're starting with invalid javascript, you have to fork the internal babylon parser which is not supported by Babel. Looks like too much for a hobbyist like myself - but, still technically doable.

@RichardForrester did you figure out how to make this rule work with prettier?

@alexandermckay It’s been a while since I messed with this, but from memory you don’t really need the mojiscript to ise the function-call-spacing rule, and as far as working with prettier, I usually bind a command to first run prettier and then run eslint auto-fix.

@RichardForrester thank you for the tips! It was actually quite simple to get them to work together. I have created a repo which shows how to set this up for anyone else using a combination of prettier, eslint and VSCode.


Some suggestions to the documents

I just want to address some issues I met and hope it could help others.
The folder that stores the config
According https://pkg.go.dev/os#UserConfigDir, the folder is different in each OS.  it is ~/Library/Application Support/gh-dash on Mac.
Don't waste your time struggling with the ~/.config/gh-dash folder..
The icons on the UI
You may not see the icons correctly even though you already have installed and used a nerd font.
That is because some of the icons need to be rendered with the bold style. Make sure you have set the bold font correctly.

Fixed in #135


Return error codes for WebAssembly metadata operations.

Signed-off-by: John Plevyak<EMAIL_ADDRESS>For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
[Optional Fixes #Issue]
[Optional Deprecated:]

@mandarjog FYI


#1081 add '_' for duplicated column

Description
If there are duplicate column names in the result of the query, add a random number to avoid duplicate column names.
Add a separator('') before the random number.
ex) a4501 -> a_4501_
Related Issue :
#1081
How Has This Been Tested?

goto mysql workbench
execute query with duplicated column
ex) select 'a' as id, 'b' as id;
see changed column name;

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project. it will be added soon
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document. it will be added soon
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Additional Context

run build
deploy to 2


Removing white background

Currently, is there a way to remove, say, the white background of the drawing of a dog? In other words, make the background go from white to transparent without affecting the dog?

This is not something built directly into RIL since the implementation for removing backgrounds from images varies from user to user.
If your goal is to just turn all white pixels into transparent pixels, you can try something like:
let mut image = Image::<Rgba>::open("dog.png");
image.map_in_place(|_, _, pixel| {
    if pixel.as_rgb_tuple() == (255, 255, 255) {
        *pixel = Rgba::transparent()
    }
});


CNF-11561: fix non-vendor snyk errors

Fix remaining errors from https://github.com/openshift/release/pull/49688
The dot file was regenerated with the following
snyk ignore --file-path='vendor/**' --file-path-group='global'
snyk ignore --file-path='**/*_test.go' --file-path-group='global'
snyk ignore --file-path="utils/crypto_dir.go, line 16" --expiry='2031-01-20' --reason='a placeholder with fake value'

/test all

/uncc @romfreiman
/uncc @tsorya
/cc @browsell
/cc @donpenney

/hold waiting to see how/when to merge this PR (see slack)

/test ibu-e2e-flow

/test ibu-e2e-flow

/unhold
all issues should be fixed now

/lgtm


telemetry worker: flush data after stops

Telemetry workers are functionally dead after a Stop lifecycle action, provided there's no intervening Start. While AddPoint actions are still processed, their data is never flushed, since the Stop action handler unschedules FlushMetrics and FlushData actions.
PHP sends a Stop action at the end of every request via ddog_sidecar_telemetry_end(), but a Start action is only generated just after a telemetry worker is spawned. With no more Start actions generated, no metrics can effectively be sent after the first Stop.
It is not clear to me whether the intention is to have a Start/Stop pair on every PHP request (where Stop flushes the metrics) or if the intention is to to have only such a pair in the first request, with the Stop event generated by ddog_sidecar_telemetry_end() effectively a noop. It would appear, judging by this
comment:

Also allow the telemetry worker to have a mode where it's continuing
execution after a start-stop cycle, otherwise it won't send any more metrics afterwards.

that the intention is to keep sending metrics after a Start/Stop pair. It also makes more sense, insofar as data is flushed only on the interval, rather than after every request via Stop. In that case:

The Stop action handler should not unschedule FlushData and FlushMetrics events and
FlushData, if called outside a Start-Stop pair, should not be a noop.

Finally: swap the order in which FlushData and FlushMetrics are scheduled so that FlushMetrics runs first and therefore its generated data can be sent by the next FlushData.

Codecov Report
Attention: Patch coverage is 83.33333% with 2 lines in your changes missing coverage. Please review.

Project coverage is 70.42%. Comparing base (3142b2d) to head (251bafa).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #515   +/-   ##
=======================================
  Coverage   70.41%   70.42%
=======================================
  Files         204      204
  Lines       27890    27894    +4
=======================================
+ Hits        19639    19643    +4
  Misses       8251     8251

Components
Coverage Δ

crashtracker
16.72% <ø> (ø)

datadog-alloc
98.76% <ø> (ø)

data-pipeline
51.15% <ø> (ø)

data-pipeline-ffi
0.00% <ø> (ø)

ddcommon
86.58% <ø> (ø)

ddcommon-ffi
75.31% <ø> (ø)

ddtelemetry
59.39% <83.33%> (+0.05%)
:arrow_up:

ipc
84.66% <ø> (ø)

profiling
78.63% <ø> (ø)

profiling-ffi
58.19% <ø> (ø)

serverless
0.00% <ø> (ø)

sidecar
36.19% <ø> (ø)

sidecar-ffi
0.00% <ø> (ø)

spawn-worker
54.98% <ø> (ø)

trace-mini-agent
69.70% <ø> (ø)

trace-normalization
97.79% <ø> (ø)

trace-obfuscation
95.75% <ø> (ø)

trace-protobuf
77.16% <ø> (ø)

trace-utils
90.84% <ø> (ø)

@bwoebi Can you look at this? I need it for https://github.com/DataDog/dd-trace-php/pull/2735


Can't login into greeenlight

Describe the bug
I installed it using the setup.sh script. Only one parameter in the config was added: BBBSESValidated = true. Everything else was set to the default. Everything finished successfully and I can access the greenlight starting page (conference.mydomain.com)
On login on: conference.mydomain.com with my operator's email and the password from the secret manager ( BBBAdministratorlogin-VJ6JeHXX1Khj) it fails with the error: " The email and password you entered did not match our records. Try again or click Forgot Password to reset your password."
I also tried to SSH into the server but wasn't sure about which private-key file to use.
Help is much appreciated.
Expected behavior
I get logged in.

Hey,
sorry for the delay. try to restart the greenlight task at ECS. sometimes it starts too fast and does not handle the initial DB setup (incl. Admin user creation) well.
let me know if this helps!

Hi,
thanks for your reply!
I have run this command:
aws ecs update-service --force-new-deployment --service bbb-stack-BBBFontendAppsStack-1QSB8K3SN4HE4-BBBgreenlightService-wBRlbqsB40hZ --cluster bbb-stack-BBBECSStack-1SU2E1ZA65564-ECSCluster --profile PROFILE_NAME
And now I can log in without any problems!

Just a quick update after multiple deploys. For me, it never works to log in to greenlight after the setup. I always have to run the above-mentioned command. So I would still see this as a bug and not a rarely occurring race condition :D

need to think about a custom start script
https://github.com/bigbluebutton/greenlight/blob/v2/bin/start
at the moment we do some nasty hack here. which might need optimization:

/usr/local/bin/bundle exec rake db:migrate; /usr/local/bin/bundle exec rake user:create["bbbadmin","${ADMIN_LOGIN}","${ADMIN_PASSWORD}","admin"]; bin/start

I am facing the same issue, and it didn't work even after restarting greenlight task at ECS

Can you please share the logs of the Greenlight task?

I am also getting the same error. Can you help me from where and in which file I need to configure.
Thanks in advance.

The email and password you entered did not match our records. Try again or click Forgot Password to reset your password.
Is my error.

this is actually not creating the user, so I ssh into server and then added user manually, and it worked

this is actually not creating the user, so I ssh into server and then added user manually, and it worked

How to add manually can you please elaborate? Because I am not able to do that also

you can use rake command
/usr/local/bin/bundle exec rake user:create["bbbadmin","${ADMIN_LOGIN}","${ADMIN_PASSWORD}","admin"]

you can use rake command /usr/local/bin/bundle exec rake user:create["bbbadmin","${ADMIN_LOGIN}","${ADMIN_PASSWORD}","admin"]

here showing an error: rake aborted no rakefile found.
May I know in which directory the rake file is stored?

Can anyone help me how can access greenlight directory and .env file?


how should I check a string is valid JSON string ?

I read all examples, but I didnt find a way to check a string is valid JSON string.
Is there an API to achieve this ? or I have to use "try catch" to check exceptions ?
thanks ^_^

ok, I noticed my question is just the same as #458 , so there will be a validation function in Release 3.0.1 ?

This is planned for 3.0.0, but I need to decide on how to best expose all possible parser/validation/format combinations which I discussed in #623. Therefore, this may take a while.

Duplicate of #458.

@nlohmann any news ?

See https://json.nlohmann.me/api/basic_json/accept/

In python use type(string_name)

that is true