Protocol error/socket hang up when trying to login

I've installed and configured aws-azure-login, but when trying to run it (without any options) I get:
Logging in with profile 'default'...
Using AWS SAML endpoint https://signin.aws.amazon.com/saml
Error: Protocol error (Target.activateTarget): Session closed. Most likely the page has been closed.
    at CDPSession.send (/home/trygve/.npm-global/lib/node_modules/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Connection.js:208:35)
    at Page._screenshotTask (/home/trygve/.npm-global/lib/node_modules/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Page.js:1927:28)
    at /home/trygve/.npm-global/lib/node_modules/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Page.js:1924:62

If I run it with --mode gui it prints an ErrorEvent with the message socket hang up.

Full output
Logging in with profile 'default'...
Using AWS SAML endpoint https://signin.aws.amazon.com/saml
ErrorEvent {
  target: WebSocket {
    _events: [Object: null prototype] { open: [Function], error: [Function] },
    _eventsCount: 2,
    _maxListeners: undefined,
    _binaryType: 'nodebuffer',
    _closeCode: 1006,
    _closeFrameReceived: false,
    _closeFrameSent: false,
    _closeMessage: '',
    _closeTimer: null,
    _extensions: {},
    _protocol: '',
    _readyState: 3,
    _receiver: null,
    _sender: null,
    _socket: null,
    _bufferedAmount: 0,
    _isServer: false,
    _redirects: 0,
    _url: 'ws://<IP_ADDRESS>:41805/devtools/browser/ff657660-58f3-4c7f-bb5e-10f7fa7757c4',
    _req: null,
    [Symbol(kCapture)]: false
  },
  type: 'error',
  message: 'socket hang up',
  error: Error: socket hang up
      at connResetException (internal/errors.js:639:14)
      at Socket.socketOnEnd (_http_client.js:499:23)
      at Socket.emit (events.js:412:35)
      at Socket.emit (domain.js:475:12)
      at endReadableNT (internal/streams/readable.js:1334:12)
      at processTicksAndRejections (internal/process/task_queues.js:82:21) {
    code: 'ECONNRESET'
  }
}

I'm running an up to date Arch Linux with nodejs-lts-fermium (so node v14.18.1, but I also tried node v16.11.1 and get the same) and I have configured kernel.unprivileged_userns_clone=1.

I see that I get this issue with puppeteer outside aws-azure-login too, so I'll close this. It seems to be this issue: https://github.com/puppeteer/puppeteer/issues/7455

hey @trygveaa were you able to solve this?

@luismramirezr: Yes, as mentioned here it works with puppeteer >= 12.0.0.


compilation issue Fabric SDK Go at the Test Step

Hi ,
I followed the tutorial, and I installed Version Go 1.10, but I have some problem of compilation, in my opinion because of a missing library , despite I have succeeded in all precedent steps .
here is the echo when launching build
cd $GOPATH/src/github.com/chainHero/heroes-service && go build
main.go:6:2: cannot find package "github.com/chainHero/heroes-service/web" in any of:
	/home/m-amairi/go/src/github.com/chainHero/heroes-service/vendor/github.com/chainHero/heroes-service/web (vendor tree)
	/usr/local/go/src/github.com/chainHero/heroes-service/web (from $GOROOT)
	/home/m-amairi/go/src/github.com/chainHero/heroes-service/web (from $GOPATH)
main.go:7:2: cannot find package "github.com/chainHero/heroes-service/web/controllers" in any of:
	/home/m-amairi/go/src/github.com/chainHero/heroes-service/vendor/github.com/chainHero/heroes-service/web/controllers (vendor tree)
	/usr/local/go/src/github.com/chainHero/heroes-service/web/controllers (from $GOROOT)
	/home/m-amairi/go/src/github.com/chainHero/heroes-service/web/controllers (from $GOPATH)

can someone help me please ,
thanks ,
Moatez

Hi @M-AMAIRI !
It's not a problem of dependencies but a problem with your files. The error is saying that you don't have the web files in your directories.
Can you tell me where did this issue came ? At which point of the tutorial ?

@M-AMAIRI ,
You must have copied the Gopkg.lock file in addition to the Gopkg.toml. Remove the Gopkg.lock file, run the dependency manager and compile again:
cd $GOPATH/src/github.com/chainHero/heroes-service
rm -f Gopkg.lock
dep ensure
go build

I close this issue as there was no update.

Hi @antitoine  , thank you for help , Sorry for the Late Reply I have been sick since last week , I followed the steps that you mentioned, and currently it works for me , and as @MaximeAubanel  said , this type of errors can be also by the lack of  web/controllers files .
Thanks ,
Moatez ,


Review scrollbar position in CodeWithResult component

@mhwelander is this hiding any content?

Current behaviour:

Solution can stem from #1023


Additional note.

Added the information that the NDI is activated per session only. On next login user must activate it before using NDI.
Product Group information based on ICM https://portal.microsofticm.com/imp/v3/incidents/details/230031375/home

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@cichur PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

@jasonluiscruz - please commit my suggested changes. Thanks.

@jasonluiscruz - please commit my suggested changes. Thanks.

@jasonluiscruz - you need to reopen this PR so that it can be merged, unless there is a reason that you closed it? please advise.

@jasonluiscruz - you need to reopen this PR so that it can be merged, unless there is a reason that you closed it? Please advise.

I've reopened it, not sure how the PR got closed. My bad.


Solved multiple motion issues

Closes #1256
Solves:

A user who can create submitters and users should can create directly a user and assign them as submitter in the MotionManageSubmitterComponent
Motion setting: The pre-selected linenumbering should be outside
Show the forwarding button for a motion only if at least one committee is selected, which can be the target for a forwarding

Creation of new user (in motion submitter form) failed with: {"success": false, "message": "Response from datastore contains invalid 'meta_position'."}

Forward button still visible in motion detail (no forward committee selected in committe edit view)

I think the forward button should work now, I couldn't reproduce your error with user creation though.
How are you getting it?


Update .NET SDK + Runtime

Description

Update .NET SDK and Runtime
Fix typo breaking build
Remove package reference for client

Related issues
N/A
Testing
Pipeline

There's also a dockerfile for the uploader tool


OpRun exit code not correct when docker-compose errors on build

when docker-compose errors on building a service, the OpRun's exit code is not correct.

no repro. closing for now


cvc-complex-type.3.2.2: Attribute 'access-denied-page' is not allowed to appear in element 'http'.

I'm using spring-jpa project without any customization yet and trying to compile the code, but its giving following error:
Could you please address to this issue?
cvc-complex-type.3.2.2: Attribute 'access-denied-page' is not allowed to appear in element 'http'.

Not sure why you're running into that issue - I'm able to fully build the project with no errors. However, just to be on the safe side, I removed the file that was likely leading you to that problem - because it wasn't in use anyways.
If you still have issues building the project, let me know. Cheers,
Eugen.


remove duplicate text in how-to-build-agent-code.md

remove duplicate text in how-to-build-agent-code.md under the 'How To Build The Device Update Agent' section

The text has changed


[BUG] Search bar overflowing

Description
As you can see, the border of the search bar is cut off slightly at the top-right side. That is because of the overflow of an element. Kindly assign me this issue to that I can fix it.
Screenshots

Any additional information?
No response
What browser are you seeing the problem on?
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I have read the discussion tab thoroughly and got the project idea
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

@rohansx @k-deepak04 Kindly assign this issue to me

Kindly assign this issue to me

@Pranav-Rustagi go for it
make sure it's responsive :)

@k-deepak04 Done. I have opened up a PR.


Implement a simple HUD

health bar
kill count
death count
ammo
weapon name

Health bar and ammo counter work, more will come in time I guess.


Update index.js

Now it will respond correctly when the connection get closed by the server-side.

Thank you for the add-on, I am using it a lot. ^^


Link to article not valid

There are references to URL https://www.microsoft.com/CloudandHosting/licensing_sca.aspx, which is no longer valid.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ad3ecbc1-9c02-5681-7214-356be22ac7e8
Version Independent ID: 73af82f6-079b-6c37-55c4-cb59e921457a
Content: Deploy Windows 10 Enterprise licenses - Windows Deployment
Content Source: windows/deployment/deploy-enterprise-licenses.md
Product: w10
Technology: windows
GitHub Login: @greg-lindsay
Microsoft Alias: greglin

The sentence in question is the following one:
Virtual Desktop Access (VDA)
Subscriptions to Windows 10 Enterprise are also available for virtualized clients. Windows 10 Enterprise E3 and E5 are available for Virtual Desktop Access (VDA) in Windows Azure or in another qualified multitenant hoster.

Closing via #9245
Thank you


Git source control: "Stage Selected Ranges" creates a "Staged Changes" file of type UTF-8 when the orginal file is ANSI (Windows 1252)

Issue Type: Bug

Create a file of type ANSI (Windows 1252). In Notepoad++ (Encoding-ANSI, Encoding-Character sets-Western  European-Windows 1252).
Add the scandinavian letters: ØÆÅ to the file. (hex D8 C6 C5)
Add the file to a git repo
--
Edit the file and add "\r\n-" (hex 0D 0A 2D)
Git source control: "Stage Selected Ranges"  for the one line containing "-" (hex 2D)
Commit the file from "Staged Changes"
Delete the file on disk
Git source control:  Select the file and "Discard changes" (to restore the file from git)
--
The file have the content: C3 98 C3 86 C3 85 0D 0A 2D
Expected content: D8 C6 C5  0D 0A 2D

The file have been changed from ANSI to UTF-8 in git.
In C++ using "Use Multi-Byte Character Set" this is a fatal bug
VS Code version: Code 1.51.1 (e5a624b788d92b8d34d1392e4c4d9789406efe8f, 2020-11-10T23:34:32.027Z)
OS version: Windows_NT x64 10.0.19041

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz (8 x 3602)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.98GB (4.12GB free)

Process Argv
--crash-reporter-id 48361099-29ee-4112-bdbe-983a488188b4

Screen Reader
no

VM
0%

Extensions (9)

Extension
Author (truncated)
Version

xml
Dot
2.5.1

gc-excelviewer
Gra
3.0.40

csharp
ms-
1.23.6

cpptools
ms-
1.1.3

hexeditor
ms-
1.3.0

powershell
ms-
2020.6.0

vetur
oct
0.30.3

vscode-zipexplorer
sle
0.3.1

pdf
tom
1.1.0

Is this the problem?
\extensions\git\src\git.ts

Value if specified in settings should be used

@jekitf I think that utf8 is ok, but the one 2 lines above it might be the issue. But not sure. I won't really be able to look at this this iteration at least, so any testing/PR that you can provide would be greatly appreciated.

@jekitf I think that utf8 is ok, but the one 2 lines above it might be the issue. But not sure. I won't really be able to look at this this iteration at least, so any testing/PR that you can provide would be greatly appreciated.

Facing a similar issue. Related to #36219?

This problem also occurs with Shift-JIS files.

VSCode Version 1.54.3
Windows 10 Pro x64 Version 1909

Steps to Reproduce:

Setup user settings according to this:

{
    "files.encoding": "shiftjis"
}

Initialize a git repository
Create a file which is encoded by Shift-JIS
Open the diff of the created file
Select some lines and run "Stage Selected Ranges"

I'm facing the same problem with Shift-JIS.
Therefore, I tried to verify it.
As eamodio says, this line seems to be the cause of the bug.
child.stdin!.end(data, 'utf8');

Verification Code
\extensions\git\src\git.ts

Verification Process

Create a non-UTF-8 file (Shift-JIS in this case), add some text and commit it.
Set the workspace encoding setting to Shift-JIS.
Add new line.
In source control view, select the new line and execute "Stage Selected Ranges".

Current Stable
The Shift-JIS file is converted to UTF-8 by "Stage Selected Ranges".

Verification code result
Shift-JIS files are staged as is.

This verification code is an ad hoc fix and I'm not sure if it's the right way to fix the bug.

Isn't this one supposed to have already been fixed by #84130 (as reported on #55110 --> #36219)?
Maybe that fix is the root cause?

https://github.com/microsoft/vscode/pull/84130 has addressed the problem related to encoding when files are being shown in the diff editor. Unfortunately it did not address the encoding related issue when it comes to the "Stage Selected Ranges" command. Fixing the "Stage Selected Ranges" command is currently blocked on https://github.com/microsoft/vscode/issues/824 as at the moment extensions do not have access to the encoding of the text document.

I also run into this today. Why does this issue exist yet?

The viciousness of this bug is that the corrupted files manifest themselves very late in git history, when eg bisecting old commits and discovering differences in irrelevant  but huge ranges of text due to EOLs.
I've been bitten by this bug, and discovered it roughly after a year!

Is working-tree-encoding of .gitattributes are workaround? Using that GIT is expected to store UTF-8 internally, while converting to some different encoding locally. In that case it might be OK if VSCode forwards UTF-8 at some point.
*			text=auto
*.bat		text eol=crlf	working-tree-encoding=cp850
*.c			text eol=crlf	working-tree-encoding=windows-1252

I tried to create an extension to add a "Stage Selected Range (ANSI)" command for ANSI to work around this problem, but it was not possible because the registerDiffInformationCommand is still in the proposed stage. (#84899)
We hope this will be corrected as soon as possible.

This issue requires an API for encoding, but the issue of adding this API(#824) has remained open for 6 years. Also, adding such a core API would be difficult for the average contributor.
Until the API is added, how about getting the encoding from the config and staging based on that encoding instead of the actual encoding?

It is true that GIT always stores files in UTF-8 encoding on a remote server.
With the setting in comments given a year ago the Github Desktop works fine. But the vscode doesn't use the setting when comparing commits. The solution was not very obvious.
https://code.visualstudio.com/updates/v1_48#_browser-support
https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding#configuring-vs-code

It is true that GIT always stores files in UTF-8 encoding on a remote server.

Don't be misleading, that's not the case "always", but depends on settings in .gitattributes. Git itself is fine to store files in arbitrary encoding as-is, depends on various different settings of the client. Remember that it's able to store binary files as well.

Is there an update to this issue? I also opened an issue on VSCodium's GitHub: https://github.com/VSCodium/vscodium/issues/1418
I have reproduced and documented the current problem in two examples. The difference between the two use cases is the use of a .gitattributes. The post has become a little longer than planned.
Case 1

mkdir .\test-repo
cd test-repo
git init
git config --local --list

core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true

Create script.vbs with content

# Test file
Msg "Hello"

commit script.vbs in VSCode with Stage Changes
edit the script.vbs and add some umlauts

# Test file
Msg "Hello"
Msg "Änderungen"

commit script.vbs in VSCode with Stage Changes
edit the script.vbs and add some umlauts

# Test file
Msg "Hello"
Msg "Überlegung"
Msg "Änderungen"

commit script.vbs in VSCode with Stage Changes
edit the script.vbs and add some umlauts

# Test file
Msg "Hello"
Msg "ÄÖ first commit"
Msg "Überlegung"
Msg "ÜÖ later commit"
Msg "Änderungen"

in VSCode under Source Control highlight the row with Msg "ÄÖ first commit" and select "Stage selected Ranges".
Commit the Staged Change
After that:

Source Control shows the following state:

The explorer shows the following state (just ignore the file name). Note the lines marked in blue.:

Case 2

mkdir .\test-repo2
cd test-repo2
git init
git config --local --list

core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true

Create script.vbs with content

# Test file
Msg "Hello"

Create .gitattributes with content

*			text=auto
*.vbs		text eol=crlf	working-tree-encoding=windows-1252

commit  .gitattributes in VSCode with Stage Changes
commit script.vbs in VSCode with Stage Changes
edit the script.vbs and add some umlauts

# Test file
Msg "Hello"
Msg "Änderungen"

commit script.vbs in VSCode with Stage Changes

from now on, the explorer shows a change in line three, even if Source Control shows no changes:

edit the script.vbs and add some umlauts

# Test file
Msg "Hello"
Msg "Überlegung"
Msg "Änderungen"

commit script.vbs in VSCode with Stage Changes
the explorer shows a change in line three, even if Source Control shows no changes. Interestingly the text shows "1 of 1 change":

edit the script.vbs and add some umlauts

# Test file
Msg "Hello"
Msg "ÄÖ first commit"
Msg "Überlegung"
Msg "ÜÖ later commit"
Msg "Änderungen"

in VSCode under Source Control highlight the row with Msg "ÄÖ first commit" and select "Stage selected Ranges".
Commit the Staged Change
After that:

Source Control shows the following state:

The explorer shows the following state (just ignore the file name). Note the lines marked in blue.:

Summary
settings.json
"files.autoGuessEncoding": false,
"[vbs]": {
        "files.encoding": "windows1252"
    }

I had this problem today. Running version 1.85.1. Thought I'd make a comment to give this issue a kick, since this issue is three years old. :)

Can this bug be prioritized higher? Silently changing files is a significant bug. Many users are likely running into this bug without realizing it. If it breaks something later, they might not find the original cause.

Is there any update on this? I think it is very important for a text editor to not silently make unwanted changes to files.

Apologies for not getting back to you on this until now. Thanks @jekitf, and @Dub1shu for tracking down the root cause of this issue and for proposing a fix. I have pushed a changes for this issue today and it should be available in tomorrow's VS Code Insiders release. I would really appreciate if you could download that and verify that the fix is working as expected. Thanks!

really thanks

Wuhuu, finally!


Create two instances of ecctrl for online

Hello,
I am setting up a project in which I make the movement of the main character with ecctrl. The problem is that if I load another ecctrl for a second player, the movement that I apply to the main one also applies to the second, even if they are different references. I have tried creating two separate components, with different ecctrl and group references and it remains the same. Does anyone have any ideas on how to use it?
Thanks a lot.

@algoritcom have you found a solution for this?


Upgrade from 1.16 to 2.8 and the Concatenate feature is not visible

I updated from 1.16 to 2.8 and I don't see the Concatenate in the aggregate operation picklist from the new tab. I also don't see any of the old LRS under the new tab "manage lookup rollup summaries." did I miss a step?

You need to perform some post install steps, take a read through the release history in the readme file for more info. 👍


Add fork support functions

Refer: https://github.com/RustPython/RustPython/issues/4971

s it about _PyThread_at_fork_reinit or lock__at_fork_reinit?
_PyThread_at_fork_reinit seems like internal API. (not exposed to Python API)
But lock__at_fork_reinit does.

Yes, it is about it. I am getting used to making distinction between python api and internal api.
I am doubtful if Rust type system regards fork. This will be limited by system API of platforms.

Yes, I agree to this. I will check this  if forked child has parent's locks or not. If child process doesn't has it, shouldn't this function be dummy then?
My suggestion is casting &self.mu from &RawMutex to &AtomicCell<RawMutex> using unsafe. And replace mutex under atomic cell context.
It will be as safe as the CPython one.

Done this change although doing it inside unsafe throws warnings that unsafe is un-needed. Should I suppress this?
@youknowone

Couple of things on test cases:

Linux tests are green because all these fork related functions are based on Unix but,
Mac is showing failures in fcntl.
UNEXPECTED SUCCESS in windows for test_httpservers test cases (which fails elsewhere).

Now current change (including fork and related functions) is based on Unix system so I didn't expect anything to change for windows but it did because some tests which were skipped earlier, are now being run (as fork re-init is not platform specific even though fork is). Maybe we need to add cfg[unix] in fork-reinit? Or let it be and look for fix in now visible functions (which couldn't work before due to missing dependency) ?

Though I didn't check the actual reason of window failure yet, in general, if it was AttributeError and never actually used, it can be fixed by adding it.

Though I didn't check the actual reason of window failure yet, in general, if it was AttributeError and never actually used, it can be fixed by adding it.

Issue is that test cases in test_httpservers is actually working on windows (who has no business in these fork functions)


feat: create and serealize gateway config

This change is

#138
#137  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ArniStarkware and the rest of your teammates on  Graphite

Codecov Report
Attention: Patch coverage is 61.29032% with 12 lines in your changes are missing coverage. Please review.

Project coverage is 44.94%. Comparing base (f5821cf) to head (ecb99a8).

Files
Patch %
Lines

crates/gateway/src/config.rs
61.29%
12 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #137      +/-   ##
==========================================
+ Coverage   44.11%   44.94%   +0.82%
==========================================
  Files          17       17
  Lines         612      643      +31
  Branches      612      643      +31
==========================================
+ Hits          270      289      +19
- Misses        333      345      +12
  Partials        9        9

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

crates/gateway/src/config_test.rs line 104 at r1 (raw file):

    let fix = false;
    test_valid_config_body(expected_config, file_path, fix)
}

There is code dup here. Solved in #127.
Code quote:
#[test]
/// Read the gateway config and validate its content.
fn test_validate_gateway_config() {
    let expected_config = GatewayConfig::create_for_testing();
    let file_path = get_config_file_path(GATEWAY_CONFIG_FILE);
    let fix = false;
    test_valid_config_body(expected_config, file_path, fix)
}

#[test]
#[ignore]
/// Fix the config file for test_valid_gateway_config.
/// Run with 'cargo test -- --ignored'.
fn fix_test_validate_gateway_config() {
    let expected_config = GatewayConfig::create_for_testing();
    let file_path = get_config_file_path(GATEWAY_CONFIG_FILE);
    let fix = false;
    test_valid_config_body(expected_config, file_path, fix)
}


Tracer - Option to not add method/handler response as metadata

Is your feature request related to a problem? Please describe.

Customers like @michaelbrewer would like the ability to override Tracer default behaviour by not adding Lambda handler, or a method's response as X-Ray subsegment metadata - While X-Ray metadata isn't indexed or searchable, it might contain sensitive information that can violate one's compliance.
Describe the solution you'd like

A new keyword argument for both capture_method and capture_lambda_handler:
@tracer.capture_lambda_handler(capture_response=False)
def handler(event, context):
    ...

@tracer.capture_method(capture_response=False)
def a_function():
    ...

Describe alternatives you've considered

Encrypt or mask sensitive information from response

Additional context

This was released in 1.4.0


Version 1.1.1 of the api missing on docker hub

Hi,
It seems 1.1.1 is missing on docker hub, could you put it there?
Thanks.

Thanks for letting me know. Built v1.1.1 images and pushed them to docker hub.


Consider distributing other format books among the mdbook format books

Rather than putting them out of order in their own chapter, perhaps we should use some other way of indicating non-mdbook books which could then be listed in the appropriate chapters.
@kw-fn WDYT?

I hadn't looked that closely to notice whether indexing the different formats makes a difference in information retrieval. I think that several shorter lists are better than long lists though that might also contribute to information hiding.

Actually, I might even consider finessing the distinction between mdbook format and other (similar) formats as that is really a detail from the readers' perspective. We just need to avoid including print books and completely non-book formats, I think.


Fix voc4cat_0000048: remove repeated alternateLabel

Closes #24

Initially the submitted Excel file did not have a modified date for the concept scheme. This revealed a bug in voc4cat-tool (https://github.com/nfdi4cat/voc4cat-tool/issues/174) that was fixed today. After updating the pipeline and submitting a corrected Excel file with a modified date for concept scheme the CI action for this PR finally succeeded.


README: mention RemoveCorruptedOutput with an example

Updated README to provide an example for the RemoveCorruptedOutputMixin.

I think we could also improve the tests of this feature a little bit. For example we could use pytest.raises here: https://github.com/BlueBrain/luigi-tools/blob/main/tests/test_task.py#L851

I think we could also improve the tests of this feature a little bit. For example we could use pytest.raises here: https://github.com/BlueBrain/luigi-tools/blob/main/tests/test_task.py#L851

Hmm, something fishy is happening with the tests. The tests work as excepted but the Luigi exception is no longer caught.

Ok, the exception gets handled by Luigi. I removed the try blocks and added extra assert statements that check the complete() method of the task instance.

Ok, the exception gets handled by Luigi. I removed the try blocks and added extra assert statements that check the complete() method of the task instance.

Ah yes ok. If you want to see an example on how to check the exception raised inside a task you can look here: https://github.com/BlueBrain/luigi-tools/blob/main/tests/test_task.py#L420
But it's not the main point of this feature so it's as you prefer.

Ok, the exception gets handled by Luigi. I removed the try blocks and added extra assert statements that check the complete() method of the task instance.

Ah yes ok. If you want to see an example on how to check the exception raised inside a task you can look here: https://github.com/BlueBrain/luigi-tools/blob/main/tests/test_task.py#L420
But it's not the main point of this feature so it's as you prefer.

Thanks!
I added it nonetheless to make sure no other exception but our intended exception that is thrown and caught.


Creating a time based indexing startegy in elastic search using mongo-connector

Hi All,
I have a quick question about the mongo-connector and how it creates indexes in elastic search.  I am currently writing a chat service, so there will be a lot of messages stored in a message collection in mongodb.
For searching I am using elasticsearch and the mongo connector will let me create an elastic index based on this collection.  But my question is is there any way to have the mongo connector create a new index in elastic search every say 2 weeks (for example).  This is so my searching can be done more efficiently as messages that are say 6 months old will have little relevance.
I cant delete the old messages as they are required to be kept for auditing purposes.
If not, can the mongo-connector create elasticsearch indexes for mongodb indexes (which will just have the _id and timestamp field in them) because this will most likely also give me the efficient search i am after.
Thanks in advance,
Bhavik

Mongo Connector creates a new index on Elasticsearch automatically only
when a new database is referenced or explicitly created in MongoDB.
There isn't any direct way of creating new ES indexes periodically as
you describe. If you were to create a new database or a new collection
every 2 days (or any arbitrary period of time) in MongoDB, then Mongo
Connector would create a new index or mapping type with the same name,
respectively, in Elasticsearch at those times as well. Is this what you
were intending to do?
On 05/19/2015 09:58 AM, BhavikTanna wrote:

Hi All,
I have a quick question about the mongo-connector and how it creates
indexes in elastic search. I am currently writing a chat service, so
there will be a lot of messages stored in a message collection in
mongodb.
For searching I am using elasticsearch and the mongo connector will
let me create an elastic index based on this collection. But my
question is is there any way to have the mongo connector create a new
index in elastic search every say 2 weeks (for example). This is so my
searching can be done more efficiently as messages that are say 6
months old will have little relevance.
I cant delete the old messages as they are required to be kept for
auditing purposes.
If not, can the mongo-connector create elasticsearch indexes for
mongodb indexes (which will just have the _id and timestamp field in
them) because this will most likely also give me the efficient search
i am after.
Thanks in advance,
Bhavik
—
Reply to this email directly or view it on GitHub
https://github.com/10gen-labs/mongo-connector/issues/254.

Closing this issue due to inactivity. Feel free to reopen or create a new issue if you think there's more to discuss.

I was looking for this functionality as well, but more for purging old documents from ES after an extended period of time (say: 60 days). With Elasticsearch curator, I can delete indexes older than X time units given a certain prefix.
I suppose I could set up a cron job to run every so often to update the index name argument, but I was hoping this had already existed in mongo-connector itself.


Randomspwan triggers on respawn but not first join

I'm absolutely sure it triggers and other players confirmed that


Confirm new name for NSX-SM adapter (Tanzu SM)?

Description
With the official naming of NSX Service Mesh now being Tanzu Service Mesh (I think), we should rename this repository and this adapter to suite.
Expected Behavior
This adapter and repository should be renamed to meshery-tanzu-sm.

@sergiopozoh @venilnoronha @chugtum, will you confirm the official product name?

It is Tanzu Service Mesh by VMware NSX.
El mié., 29 abr. 2020 a las 13:13, Lee Calcote<EMAIL_ADDRESS>escribió:

@sergiopozoh https://github.com/sergiopozoh @venilnoronha
https://github.com/venilnoronha @chugtum https://github.com/chugtum,
will you confirm the official product name?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/layer5io/meshery-nsx-sm/issues/18#issuecomment-621437755,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMO3ETGRPJTQ2FCXMTT2DQ3RPCC6RANCNFSM4MUA5PFQ
.

Thank you for this, @sergiopozoh. 👍  The repository name has been updated based on this. There may be other residual references in some of the docs...


Use namespaces and shorten the generated names

Currently, all the definitions generated by Aeneas are prefixed and suffixed to prevent name collisions. This generates very long names, which are cumbersome to work with when writing proofs (for instance, hash_map_new_with_capacity_fwd). It would be good to make those names shorter.
For instance, in backends like Coq and Lean it would be possible to use namespaces (HashMap.new_with_capacity_fwd, for instance), which would allow to use shorter names when possible (new_with_capacity_fwd) and disambiguate when needed. Lean seems especially suited for this, as it is extremely flexible; for instance, it accepts the following definitions, which belong to different namespaces that we declare on the fly (this would be useful for Rust, because groups of mutually recursive definitions can span across different modules):
mutual
def F.f (i : Nat) : Bool :=
  if i = 0 then true else G.f (i - 1)

def G.f (i : Nat) : Bool :=
  if i = 0 then false else F.f (i - 1)
end

Also, it is maybe not really useful to always add a suffix to definitions. In particular, we could omit the fwd, back, etc. suffixes when there is no backward function, or when we filter the forward function. For instance, hash_map_new_with_capacity_fwd would become HashMap.new_with_capacity. Generally speaking, it is safe to be a bit lax with regards to the name collisions: any name collision is detected by Aeneas at compile time: if there is such a collision, it is possible to rename the involved definition to avoid the collision.
In the future, it would also be good to allow the user to annotate the definitions with attributes so as to tweak the generated names.

Closing this because it was done for Lean.


JENKINS build automation failed with Alamofire

Hello,
I am trying to automate my build setup with JENKINS.
At the end of script build failed with error:
The following build commands failed:
CodeSign /Users/Shared/Jenkins/Home/jobs/********/workspace/build/Alamofire.framework
Could you please help!!

Looks like you've got a code signing issue. The occurrence of Alamofire in your error is merely because it's the first in the alphabetical list of dependencies which failed signing. There is a lot of help on this issue to be found elsewhere online, especially on StackOverflow. Good luck!


BLIP2 support for train_retrieval_coco.sh

Thank you so much for the code! It is pretty useful!
Could you please also open source the retrieval training based on BLIP2? Any help is greatly appreciated.

You can create a blip2_retrieval model by modifying blip2_qformer to take into account samples["image_id"] when computing ITC and ITM, as done in blip_retrieval.
Then, you can create a yaml file for training on coco retrieval by following the template of this file.
Related issue: #275

In the paper, you mentioned using in-batch negatives in BLIP2 instead of the momentum queue in BLIP. It would be great if you share modified code for retrieval using BLIP2.
Thanks in advance.

What might happen if I use ITC and ITM computed in blip2_qformer directly without any modifying about samples["image_id"]? Actually, I don't quiet understand how to use image_id to modify these two losses. Could you please give more details? Thanks in advance!

@yonatanbitton @shengyi4 You can now finetune for retrieval by running this script:
https://github.com/salesforce/LAVIS/blob/main/run_scripts/blip2/train/train_retrieval_coco.sh


Fix httpserver web5 dependency

I'm battling build issues

0.7.0-beta originally failed

error logs are reporting dependency issue, which is easily fixable (done here in this PR)
when I built locally I was getting a different build issue; issue related to the import statement fixes from this PR (cc @diehuxx)
that PR was already approved so decided to merge and cut a 0.7.1-beta

0.7.1-beta failed again, with same issue with respect to web5 dependency

from the logs I can see this is the build command: ./gradlew clean -Pgroup=com.github.TBD54566975 -Pversion=0.7.1-beta -xtest assemble publishToMavenLocal
tried to recreate that failure locally, but for whatever reason I can't seem to recreate it
somewhere I must have that 0.9.0-delta web5 JAR cached, but searching for it isn't yielding any results

So anyways, I think this should fix things, but can't confirm b/c can't recreate issue locally

I decided to add the following, to both the httpclient and httpserver (where the current issue is)...
  api("de.fxlae:typeid-java-jdk8:0.2.0")
  api("xyz.block:web5:0.0.9-delta")

...such that, it's consistent with what's in protocol (here). But, since both httpclient and httpserver depend on protocol and protocol exposes those dependencies with the api() method, we could just remove them altogether from httpclient and httpserver. But, that's a slightly different developer experience than what we have now... so idk, I just went with existing patterns.
What do we think? Should we remove those two dependency lines from httpclient and httpserver?

Ohhh okay, gradle stores dependency caches at ls ~/.gradle/caches/modules-2/files-2.1/, I was checking the ~/.m2/repository which is where maven does
yeah I recreated this locally, and this does indeed fix the issue

i think the first thing is to get the build to pass, and then see if removing the two lines still works when you test locally :)


When user hover the bubble the black bubble appear instead of the bubble of same color

SEVERITY:  Major
MODULE:

Bubble Chart
Bubble Map

PLATFORM:

Windows 7 / Chrome 49.0
Windows 7 / Firefox 44.0

STEPS TO REPRODUCE:

Navigate to the URL: http://www.gapminder.org/tools
Click on color dropdown
Select Economy -> Aid received -> Aid received per person
Select china and drag the slider to make trails
Click on color so color wheel should appear
Hover mouse on color bubbles and they turned to black

ACTUAL RESULTS:
The bubbles turned in to black color when user hover the bubbles
EXPECTED RESULTS:
The bubbles color should remain the same when user hover the bubbles
SCREENSHOT:

https://github.com/Gapminder/vizabi/pull/1813


Is it possible to build commonjs for server and amd for client?

I've been unable to figure out how to have different build recipes.
I use TypeScript on the server and in the browser, and I have several different builds:
commonjs modules

server: ouptut into ./commonjs directory
server tests: commonjs into ./test/commonjs directory

amd modules

browser: amd into ./amd directory
browser tests: amd into ./test/amd directory

code shared between server and browser

output into all four of the above locations

It appears that the value of typescript.base.options.module applies to all sources.
Is it possible to configure grunt-typescript to build my project?

You can be achieved by defining the tasks independent.
e.g.
typescript: {
    server: {
        src: "src/**/*.ts",
        dest: "bin/server",
        options: {
            basePath: "src",
            module: "commonjs"
        }
    },
    client: {
        src: "src/**/*.ts",
        dest: "bin/client",
        options: {
            basePath: "src",
            module: "amd"
        }
    },
    //serverTest ・・・・
    //clientTest・・・・
}

I don't understand english well.
If my understanding is wrong, please show me an example in detail.

Thanks, that worked.
For reference, here is the config that I'm now using:
        typescript: {
            server: {
                src: ['src/server/ts/*.ts'],
                dest: 'commonjs',
                options: {
                    module: 'commonjs',
                    target: 'es5',
                    basePath: 'src/server/ts',
                    declaration: false
                }
            },
            server_common: {
                src: ['src/common/ts/*.ts'],
                dest: 'commonjs',
                options: {
                    module: 'commonjs',
                    target: 'es5',
                    basePath: 'src/common/ts',
                    declaration: false
                }
            },
            client: {
                src: ['src/client/ts/*.ts'],
                dest: 'amd',
                options: {
                    module: 'amd',
                    target: 'es5',
                    basePath: 'src/client/ts',
                    declaration: false
                }
            }
            client_common: {
                src: ['src/common/ts/*.ts'],
                dest: 'amd',
                options: {
                    module: 'amd',
                    target: 'es5',
                    basePath: 'src/common/ts',
                    declaration: false
                }
            }
        },


Use dictionary unpacking instead of merge operator for python 3.8 compatibility

The dictionary merge operator was introduced in Python 3.9 and unfortunately PyTorch still supports 3.8. I think for this use case there is no downside to unpacking, other than that it's a bit ugly.

Thanks.


Add SpacyNERAnalyzer

Current NERAnalyzer is based on transformers pipeline, but in out community few people would like to use Spacy based NER analyzer hence let's add SpacyNERAnalyzer along with renaming existing NERAnalyzer to TransformersNERAnalyzer

Fixed by #171


Use releases

Hi,
I'll be planning on including BitMapperBS in a workflow and it would be great if releases were included to get an idea of the version that is used and new versions that come out.
Best,
Stefan

Hi,
I'll be planning on including BitMapperBS in a workflow and it would be great if releases were included to get an idea of the version that is used and new versions that come out.
Best,
Stefan

Hi Stefan,
May I ask what should I do exactly? Should I add an item on README to present the previous and future versions of BitMapperBS?

Hi,
there's a feature on GitHub to create releases here. It's pretty easy to implement and it helps users to keep track of different versions of the same tool. I hope this clarified my issue!
Stefan

Hi,
there's a feature on GitHub to create releases here. It's pretty easy to implement and it helps users to keep track of different versions of the same tool. I hope this clarified my issue!
Stefan

Thanks in advance. I will create a release as soon as possible. : )

Hi,
there's a feature on GitHub to create releases here. It's pretty easy to implement and it helps users to keep track of different versions of the same tool. I hope this clarified my issue!
Stefan

Hi Stefan,
The releases have already included. Please let me know if you have any other problems.

Thank you for the help,
the issue can be closed.


Update disks-pools-deploy.md

Add in the complete resource provider name.

@MGodfrey50 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@roygara
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@MGodfrey50 Thanks for helping improve our docs, we appreciate it!
This change looks good, so:
#sign-off


Scene Tree Editor cache becomes invalid and crashes

Tested versions

Reproducible in:

0f95e9f8e665cedaa5aace5f6f86de2b4b5a8c60
4.4-dev.7

Not reproducible in:

4.4-dev.6

System information
Godot v4.4.dev (6cc375686) - Arch Linux #1 SMP PREEMPT_DYNAMIC Mon, 09 Dec 2024 14:31:57 +0000 on Wayland - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - dedicated Quadro T2000 (nvidia) - Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (12 threads)
Issue description
The engine crashes when trying to connect a signal on an instanced node after opening and closing the instanced scene.
It is unclear...

...whether it happens exclusively on instanced scene nodes
...whether some steps I do in the video are unnecessary
...what the exact conditions are that lead to the cache

CC: @hpvb because I have a strong suspicion that https://github.com/godotengine/godot/pull/99700 introduced this looking at the stack trace, although I haven't bisected it.
Steps to reproduce
https://github.com/user-attachments/assets/5c351514-b3fa-4c7b-835f-98fd828b4b22
Minimal reproduction project (MRP)
godot-test-project_signals_crash.zip

After watching the video I know what this is. PR will come soon! Thanks for the detailed report.


Rotation Lock in IOS9

What is the preferred method of locking the screen rotation in IOS9?

@dested You could use a plugin like https://github.com/apache/cordova-plugin-screen-orientation

My use case is not necessarily to manage orientation throughout the lifetime of the app, more to just lock the orientation initially. Is there any way to handle this from within the tabris or xcode configuration?

@dested Check out orientation section in https://cordova.apache.org/docs/pl/latest/config_ref/

@patrykmol Thanks, but unfortunately this is not honored by Tabris as far as I can tell

I have attempted to use https://github.com/apache/cordova-plugin-screen-orientation on IOS9 and it has no effect. Im not sure if there is something different about the way cordova is creating activities vs tabris that may cause this plugin not to work.

I will investigate this issue and let you know.

@dested Issue is now resolved in latest nightly. It works with the solution I have posted above.

I will give it a try, thanks for your help!


Add a copy of the MIT license to the repository

The asset submission says the asset's license is MIT. Please add a copy of the MIT license to the repository to confirm this :slightly_smiling_face:

yeah forgot that , thanks for reminding me

and its done

Thanks! The asset is now approved: https://godotengine.org/asset-library/asset/938


Fix #535 and combine #522, #518 and #533

This commit fixes #535 and combines #522, #518 and #533 as all three commits include the same files and potentially add merge conflicts with each other, so combining my contribution with changes made in previous commits for no merge conflicts.

Thank you for your help, but it looks like we've already fixed this.
If I'm wrong, please re-open this issue and we'll get it sorted out. Thanks!


Consider Removal of RawFile

As far as I can tell RawFile is simply a wrapper around VRawStream.
Is there any reason to keep it? @javierggt

Not really


fix: add new build for styleless

What kind of change does this pull request introduce?
We used try to remove the typeof process condition for default styles, but it bring a new issue for vite and a new PR https://github.com/codesandbox/sandpack/pull/795 add the condition back.
We need to understand that this kind of assert will always be undefinde for most of bundlers, vite/webpack etc, because there is no process in browser and all of them chose to directly replace process.env.xxx to the specify value, this means:
const a = process.env.xxx // source code

// after compile

const a = true // the value you specified on config

So without remove the typeof process condition the disable default style feature will never work on production (for some reason most of bundler actually provide a process object on dev mode).
It's not recommeded for client module to rely on procee.env.xxx env variables because it's not standard. Different bundle tools handle env with different ways, for example in vite the default supported way to get env is through import.meta.env.xxx, so there is no process.env unless you config it at vite.config.js.
What is the current behavior?
Disable default style will never work on production build.
What is the new behavior?
Add a new build to remove the default style, the remove action happend at build time which we can control. And we can do more with this to remove all the css({...}) code in this build to even reduce the final bundle size.
What steps did you take to test this? This is required before we can merge, make sure to test the flow you've updated.
Build with stitches

Build without stitches

Checklist

[ ] Documentation;
[ ] Storybook (if applicable);
[ ] Tests;
[ ] Ready to be merged;

Hey, @Jokcy! I loved this solution!
Could you update the documentation and create a sandbox showing how to use it?

@danilowoz That's great! I did want to do the same thing but I'm not sure if you will agree this solution so I just implement it in minimal effect.  Great job anyway.
I also want to remove the default css code for the unstyled bundle, for example:
// in Stack.tsx

export const stackClassName = css({
  display: "flex",
  flexDirection: "column",
  width: "100%",
  position: "relative",
  backgroundColor: "$colors$surface1",
  gap: 1, // border between components

  [`&:has(.${THEME_PREFIX}-stack)`]: {
    backgroundColor: "$colors$surface2",
  },
});

These code is useless for unstyled bundle, I want to figure out a easy way to remove all these code without a lot of change of our codebase.
Do you want this being include in this PR or another PR should be created?

Thanks! Yeah, let's try to remove these styles on this PR, feel free to give it a try.

I was wondering if, in the future, we can extract the CSS to static files. What do you think?

🤔 You mean like pre compile stitches to css files?

@danilowoz If we generate static css from stitches, I guess it may break the theme props usage?

yeah, it's not an easy issue to solve.
BTW, can you update this branch with main?

BTW, can you update this branch with main?

You mean rebase main to this branch?

@danilowoz done.

Hey @Jokcy. It seems that this PR introduces a regression on the Console component. I'm getting the following error only on the documentation (dev-mode works fine), which made me conclude that the bundler has been broken.
I spent quite some time trying to figure out what was going on, but with no success. Maybe you have some idea.

@danilowoz Got it, will check later. Do we have some unit/e2e tests to help us more confident about the changes? The unstyled bundle should pass all the cases.

No, we don't. But I'm not if a unit test could help in this case because it looks a like dependency or a bundler issue

@danilowoz Find the reason, it's because we output our es bundle to mjs, which seems being handled differently in typescript, change file to index.js and "import": "./dist/index.js" in packagejson fix this issue. Don't why though, need to do some research.

I fulgurate out and this is how webpack works. it doesn't apply export default interop to mjs files, breaking the "ansi-to-react" dependency. this is a modern module resolution algorithm from the nodejs and it is enabled only for mjs files

The easier way is to output filename like index.esm.js.

so a name with js extension will solve the problem.
here is repo with minimal reproduction https://github.com/jeetiss/mjs-commonjs-default


support R.__ placeholder in curry functions

See #817
Changes:

add internal _curryN function, similar to op but capable of currying functions of arbitrary arity;
define curryN as _curryN(2, _curryN);
update _checkForMethod to return a function with the appropriate arity;
replace occurrences of _curry2, _curry3, and op with curry; and
remove _curry2, _curry3, and op.

Reasons to like these changes:

it will put an end to ad hoc pull requests adding "op-style" currying to one or two functions at a time;
it improves consistency✝;
partial application is not only useful for binary functions;
it removes the distinction between "operator" functions and other functions, simplifying Ramda's mental model and making R.__ easier to explain; and
it further promotes partial application, Ramda's key feature.

Reasons to dislike these changes:

it's a breaking change✝✝; and
it increases the amount of work required to apply a curried function.

✝ Currently commutative functions do not support R.__, as it's not useful. For consistency, though, they should. One could then say that R.curry(f)(R.__, b)(a) is equivalent to f(a, b) for any binary function f, in the same way one can currently say that R.curry(f)(a)(b) is equivalent to f(a, b) for any binary function f. (All the discussion in Fantasy Land seems to have got me thinking in terms of laws and whatnot.)
✝✝ Currently R.divide(R.__) is equivalent to R.flip(R.divide), which has always seemed to me like too much magic. I doubt anyone is using this form, as the R.flip version is much clearer.

I talked about this a while ago as a good idea.  I saw #817, and agreed with it.
My only hesitation is whether this will do any significant damage to performance.  I know that's not your focus.  Nor is it mine.  And it's not my strong suit.  But the nastiness of the current Balkanized curries comes out of a need to improve performance.  I don't think you were participating then, but soon after we announced Ramda, the author of a popular JS library posted some performance tests of some of our key functions and tweeted that pre-currying is a huge performance killer.  Since we hadn't even looked at performance at that point, we took it to heart and went through two rounds of radical surgery to get versions that had APIs we could live with and performance that didn't disappoint.  (That author has now released a version of his library with an API that looks an awful lot like ours, including the pre-currying, so he must have had some change of heart.)
So, have you compared benchmarks before and after?  For the improved consistency and flexibility, I would not mind if we lost a little performance, but I would want to be sure it's not crippling.

jsPerf is currently offline. Do you have a test case in mind, @CrossEye?
To provide a (very) rough idea of the performance, running the test suite of a project which uses Ramda extensively took 2s before this change and 3s afterwards.

@davidchambers you should be able to run grunt benchmark in your branch and compare the output in bench/report to running it on master.

I was thinking about the difference between the outputs of grunt benchmark run in HEAD versus in this branch.

Damn, that @buzz guy is quick!

remove _curry2, _curry3

Why not create placeholder versions of these? I don't personally care much about speed but it is simple enough to write https://gist.github.com/kedashoe/e0184a5b91e63084299b. Since all internal ramda functions used to use these, maybe it is worthwhile?

@kedashoe let's see where we stand first. If δ < ε then there's no need for such optimizations. If δ > ε then it may be worth optimizing as suggested in that gist.

I don't know.  This whole conversation's Greek to me.

let's see where we stand first. If δ < ε then there's no need for such optimizations. If δ > ε then it may be worth optimizing as suggested in that gist.

Fair enough, although there is no trade-off, right? Placeholder currying is a trade-off in that you get more features at the cost of reduced speed. This is just better speed with no cost?
Also it looks like this curry passes along additional arguments, which the old curry2 and curry3 did not do, changing a bit all internal functions that used curry2 and curry3 (the gist also does not pass along arguments, but can be made to do so if that is the direction this is headed).

The results are in:
15:28 ~/github.com/ramda/ramda (placeholder)
$ grunt benchmark
Running "benchmark:all" (benchmark) task

Running suite concat [bench/concat.bench.js]...
>> _(s1).concat(s2) x 1,479,698 ops/sec ±0.49% (100 runs sampled)
>> concat(s1, s2) x 5,199,614 ops/sec ±1.68% (93 runs sampled)
>> concat(s1)(s2) x 655,832 ops/sec ±3.44% (78 runs sampled)
>> concatS1(s2) x 1,048,869 ops/sec ±3.85% (74 runs sampled)
Fastest test is concat(s1, s2) at 3.5x faster than _(s1).concat(s2)

Running suite curry [bench/curry.bench.js]...
>> _x4(100) x 10,902,394 ops/sec ±4.43% (82 runs sampled)
>> mult4(100) x 1,736,100 ops/sec ±0.62% (98 runs sampled)
>> manual(100) x 62,593,761 ops/sec ±2.22% (91 runs sampled)
Fastest test is manual(100) at 5.7x faster than _x4(100)

Running suite forEach [bench/each.bench.js]...
>> _.each(nums, x2) x 403,625 ops/sec ±3.19% (92 runs sampled)
>> forEach(x2, nums) x 409,807 ops/sec ±1.72% (95 runs sampled)
>> forEach(x2)(nums) x 263,345 ops/sec ±2.53% (91 runs sampled)
Fastest tests are forEach(x2, nums),_.each(nums, x2) at 1.02x faster than _.each(nums, x2)

Running suite filter where [bench/filter-where.bench.js]...
>> _.filter(objs, {x: []}) x 109,200 ops/sec ±1.67% (94 runs sampled)
>> filter(where({x: isEmpty}), objs) x 366,834 ops/sec ±0.34% (98 runs sampled)
>> filter(where({x: isEmpty}))(objs) x 261,642 ops/sec ±0.40% (100 runs sampled)
>> filterEmptyX(objs) x 444,264 ops/sec ±2.56% (92 runs sampled)
>> _.filter(objs, {y: false}) x 804,155 ops/sec ±1.80% (93 runs sampled)
>> filter(where({y: false}), objs) x 419,495 ops/sec ±4.71% (89 runs sampled)
>> filter(where({y: false}))(objs) x 286,196 ops/sec ±2.81% (88 runs sampled)
>> filterFalseY(objs) x 835,425 ops/sec ±2.18% (98 runs sampled)
Fastest test is filterFalseY(objs) at 1.04x faster than _.filter(objs, {y: false})

Running suite filter [bench/filter.bench.js]...
>> _.filter(nums, isEven) x 2,550,538 ops/sec ±1.21% (98 runs sampled)
>> filter(isEven, nums) x 1,576,663 ops/sec ±4.66% (83 runs sampled)
>> filter(isEven)(nums) x 596,219 ops/sec ±2.60% (95 runs sampled)
>> filterEven(nums) x 834,764 ops/sec ±4.60% (85 runs sampled)
Fastest test is _.filter(nums, isEven) at 1.62x faster than filter(isEven, nums)

Running suite find where [bench/find-where.bench.js]...
>> _.find(objs, {x: []}) x 550,278 ops/sec ±2.96% (93 runs sampled)
>> find(where({x: isEmpty}), objs) x 630,666 ops/sec ±0.56% (100 runs sampled)
>> find(where({x: isEmpty}))(objs) x 371,520 ops/sec ±0.99% (99 runs sampled)
>> findEmptyX(objs) x 1,026,590 ops/sec ±0.44% (99 runs sampled)
>> _.find(objs, {y: false}) x 1,036,845 ops/sec ±0.64% (95 runs sampled)
>> find(where({y: false}), objs) x 606,358 ops/sec ±0.57% (99 runs sampled)
>> find(where({y: false}))(objs) x 368,350 ops/sec ±1.14% (93 runs sampled)
>> findFalseY(objs) x 1,437,240 ops/sec ±0.44% (101 runs sampled)
Fastest test is findFalseY(objs) at 1.39x faster than _.find(objs, {y: false})

Running suite find [bench/find.bench.js]...
>> _.find(nums, isZero) x 6,114,993 ops/sec ±2.17% (93 runs sampled)
>> find(isZero, nums) x 5,499,990 ops/sec ±2.33% (91 runs sampled)
>> find(isZero)(nums) x 752,739 ops/sec ±4.02% (87 runs sampled)
>> findZero(nums) x 1,521,845 ops/sec ±1.58% (95 runs sampled)
Fastest test is _.find(nums, isZero) at 1.11x faster than find(isZero, nums)

Running suite findIndex where [bench/findIndex-where.bench.js]...
>> _.findIndex(objs, {x: []}) x 549,158 ops/sec ±3.25% (91 runs sampled)
>> findIndex(where({x: isEmpty}), objs) x 526,845 ops/sec ±1.19% (91 runs sampled)
>> findIndex(where({x: isEmpty}))(objs) x 322,092 ops/sec ±1.01% (95 runs sampled)
>> findIndexEmptyX(objs) x 959,554 ops/sec ±0.97% (92 runs sampled)
>> _.findIndex(objs, {y: false}) x 1,002,230 ops/sec ±0.98% (95 runs sampled)
>> findIndex(where({y: false}), objs) x 532,559 ops/sec ±0.93% (95 runs sampled)
>> findIndex(where({y: false}))(objs) x 325,496 ops/sec ±1.78% (93 runs sampled)
>> findIndexFalseY(objs) x 1,300,121 ops/sec ±0.82% (97 runs sampled)
Fastest test is findIndexFalseY(objs) at 1.30x faster than _.findIndex(objs, {y: false})

Running suite findIndex [bench/findIndex.bench.js]...
>> _.findIndex(nums, isZero) x 6,327,050 ops/sec ±0.70% (94 runs sampled)
>> findIndex(isZero, nums) x 5,540,953 ops/sec ±1.17% (96 runs sampled)
>> findIndex(isZero)(nums) x 840,695 ops/sec ±0.94% (95 runs sampled)
>> findIndexZero(nums) x 1,461,396 ops/sec ±0.91% (94 runs sampled)
Fastest test is _.findIndex(nums, isZero) at 1.14x faster than findIndex(isZero, nums)

Running suite indexOf [bench/indexof.bench.js]...
>> _.indexOf x 26,331,145 ops/sec ±0.92% (95 runs sampled)
>> indexOf(sq, nums) x 7,799,251 ops/sec ±2.83% (96 runs sampled)
>> indexOf(sq)(nums) x 875,898 ops/sec ±0.84% (96 runs sampled)
>> idxOf23(nums) x 1,561,179 ops/sec ±0.95% (93 runs sampled)
Fastest test is _.indexOf at 3.4x faster than indexOf(sq, nums)

Running suite isSet [bench/isset.bench.js]...
>> isSet(unsortedBag) x 22,749,551 ops/sec ±0.83% (95 runs sampled)
>> isSet(unsortedSet) x 5,195,243 ops/sec ±0.92% (94 runs sampled)
>> isSet(sortedBag) x 22,698,991 ops/sec ±0.95% (95 runs sampled)
>> isSet(sortedSet) x 5,244,588 ops/sec ±0.63% (95 runs sampled)
Fastest tests are isSet(unsortedBag),isSet(sortedBag) at 1.00x faster than isSet(sortedBag)

Running suite map [bench/map.bench.js]...
>> _.map x 4,377,315 ops/sec ±2.19% (98 runs sampled)
>> map(sq, nums) x 2,827,935 ops/sec ±0.85% (98 runs sampled)
>> map(sq)(nums) x 733,203 ops/sec ±0.98% (97 runs sampled)
>> mapSq(nums) x 1,128,225 ops/sec ±1.25% (95 runs sampled)
Fastest test is _.map at 1.55x faster than map(sq, nums)

Running suite maxBy [bench/maxWith.bench.js]...
>> _.max x 136,799 ops/sec ±0.99% (97 runs sampled)
>> maxBy(computer, nums) x 374,261 ops/sec ±1.57% (90 runs sampled)
>> maxBy(computer)(vals) x 285,554 ops/sec ±0.52% (100 runs sampled)
>> maxVal(vals) x 328,076 ops/sec ±0.83% (98 runs sampled)
Fastest test is maxBy(computer, nums) at 1.14x faster than maxVal(vals)

Running suite reduce [bench/reduce.bench.js]...
>> _.reduce(nums, add, 0) x 4,389,485 ops/sec ±0.39% (101 runs sampled)
>> reduce(add, 0, nums) x 4,566,779 ops/sec ±1.01% (98 runs sampled)
>> reduce(add, 0)(nums) x 791,345 ops/sec ±0.92% (98 runs sampled)
>> reduceAdd(nums) x 1,312,063 ops/sec ±1.47% (91 runs sampled)
Fastest test is reduce(add, 0, nums) at 1.04x faster than _.reduce(nums, add, 0)

Done, without errors.

15:34 ~/github.com/ramda/ramda (placeholder)
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'upstream/master'.

15:35 ~/github.com/ramda/ramda (master)
$ grunt benchmark
Running "benchmark:all" (benchmark) task

Running suite concat [bench/concat.bench.js]...
>> _(s1).concat(s2) x 1,455,277 ops/sec ±0.74% (96 runs sampled)
>> concat(s1, s2) x 10,247,626 ops/sec ±1.03% (93 runs sampled)
>> concat(s1)(s2) x 1,710,294 ops/sec ±0.62% (99 runs sampled)
>> concatS1(s2) x 5,240,847 ops/sec ±0.80% (96 runs sampled)
Fastest test is concat(s1, s2) at 1.96x faster than concatS1(s2)

Running suite curry [bench/curry.bench.js]...
>> _x4(100) x 12,816,060 ops/sec ±1.14% (96 runs sampled)
>> mult4(100) x 9,011,486 ops/sec ±0.74% (99 runs sampled)
>> manual(100) x 57,655,896 ops/sec ±1.93% (82 runs sampled)
Fastest test is manual(100) at 4.5x faster than _x4(100)

Running suite forEach [bench/each.bench.js]...
>> _.each(nums, x2) x 418,570 ops/sec ±0.79% (98 runs sampled)
>> forEach(x2, nums) x 409,084 ops/sec ±1.05% (94 runs sampled)
>> forEach(x2)(nums) x 419,950 ops/sec ±0.78% (92 runs sampled)
Fastest tests are forEach(x2)(nums),_.each(nums, x2) at 1.00x faster than _.each(nums, x2)

Running suite filter where [bench/filter-where.bench.js]...
>> _.filter(objs, {x: []}) x 108,580 ops/sec ±1.45% (96 runs sampled)
>> filter(where({x: isEmpty}), objs) x 389,972 ops/sec ±1.50% (93 runs sampled)
>> filter(where({x: isEmpty}))(objs) x 400,189 ops/sec ±0.55% (97 runs sampled)
>> filterEmptyX(objs) x 754,202 ops/sec ±0.39% (96 runs sampled)
>> _.filter(objs, {y: false}) x 967,482 ops/sec ±1.49% (93 runs sampled)
>> filter(where({y: false}), objs) x 538,534 ops/sec ±1.26% (96 runs sampled)
>> filter(where({y: false}))(objs) x 544,556 ops/sec ±2.68% (88 runs sampled)
>> filterFalseY(objs) x 2,218,112 ops/sec ±1.10% (96 runs sampled)
Fastest test is filterFalseY(objs) at 2.3x faster than _.filter(objs, {y: false})

Running suite filter [bench/filter.bench.js]...
>> _.filter(nums, isEven) x 2,602,602 ops/sec ±1.40% (96 runs sampled)
>> filter(isEven, nums) x 3,290,560 ops/sec ±0.52% (96 runs sampled)
>> filter(isEven)(nums) x 2,487,173 ops/sec ±3.38% (88 runs sampled)
>> filterEven(nums) x 3,096,959 ops/sec ±1.69% (89 runs sampled)
Fastest test is filter(isEven, nums) at 1.06x faster than filterEven(nums)

Running suite find where [bench/find-where.bench.js]...
>> _.find(objs, {x: []}) x 605,732 ops/sec ±2.66% (91 runs sampled)
>> find(where({x: isEmpty}), objs) x 696,175 ops/sec ±0.50% (100 runs sampled)
>> find(where({x: isEmpty}))(objs) x 679,255 ops/sec ±0.39% (96 runs sampled)
>> findEmptyX(objs) x 2,470,353 ops/sec ±0.72% (100 runs sampled)
>> _.find(objs, {y: false}) x 1,356,893 ops/sec ±0.39% (98 runs sampled)
>> find(where({y: false}), objs) x 678,295 ops/sec ±2.31% (96 runs sampled)
>> find(where({y: false}))(objs) x 658,517 ops/sec ±4.61% (85 runs sampled)
>> findFalseY(objs) x 7,089,951 ops/sec ±1.94% (92 runs sampled)
Fastest test is findFalseY(objs) at 2.9x faster than findEmptyX(objs)

Running suite find [bench/find.bench.js]...
>> _.find(nums, isZero) x 6,249,362 ops/sec ±1.28% (94 runs sampled)
>> find(isZero, nums) x 11,189,786 ops/sec ±2.04% (90 runs sampled)
>> find(isZero)(nums) x 9,171,521 ops/sec ±1.64% (96 runs sampled)
>> findZero(nums) x 12,627,205 ops/sec ±1.39% (91 runs sampled)
Fastest test is findZero(nums) at 1.13x faster than find(isZero, nums)

Running suite findIndex where [bench/findIndex-where.bench.js]...
>> _.findIndex(objs, {x: []}) x 606,138 ops/sec ±2.74% (93 runs sampled)
>> findIndex(where({x: isEmpty}), objs) x 632,866 ops/sec ±2.62% (91 runs sampled)
>> findIndex(where({x: isEmpty}))(objs) x 675,371 ops/sec ±1.18% (99 runs sampled)
>> findIndexEmptyX(objs) x 2,319,351 ops/sec ±1.95% (92 runs sampled)
>> _.findIndex(objs, {y: false}) x 1,280,020 ops/sec ±2.49% (93 runs sampled)
>> findIndex(where({y: false}), objs) x 683,288 ops/sec ±2.23% (92 runs sampled)
>> findIndex(where({y: false}))(objs) x 693,749 ops/sec ±1.32% (98 runs sampled)
>> findIndexFalseY(objs) x 7,036,342 ops/sec ±2.22% (88 runs sampled)
Fastest test is findIndexFalseY(objs) at 3.0x faster than findIndexEmptyX(objs)

Running suite findIndex [bench/findIndex.bench.js]...
>> _.findIndex(nums, isZero) x 6,455,464 ops/sec ±0.93% (93 runs sampled)
>> findIndex(isZero, nums) x 11,671,966 ops/sec ±1.97% (89 runs sampled)
>> findIndex(isZero)(nums) x 8,274,996 ops/sec ±3.74% (85 runs sampled)
>> findIndexZero(nums) x 12,310,208 ops/sec ±2.57% (89 runs sampled)
Fastest test is findIndexZero(nums) at 1.05x faster than findIndex(isZero, nums)

Running suite indexOf [bench/indexof.bench.js]...
>> _.indexOf x 26,416,985 ops/sec ±1.52% (97 runs sampled)
>> indexOf(sq, nums) x 20,983,270 ops/sec ±3.25% (81 runs sampled)
>> indexOf(sq)(nums) x 15,066,367 ops/sec ±4.10% (84 runs sampled)
>> idxOf23(nums) x 25,420,953 ops/sec ±1.65% (94 runs sampled)
Fastest test is _.indexOf at 1.04x faster than idxOf23(nums)

Running suite isSet [bench/isset.bench.js]...
>> isSet(unsortedBag) x 21,041,270 ops/sec ±1.75% (93 runs sampled)
>> isSet(unsortedSet) x 5,489,477 ops/sec ±2.84% (90 runs sampled)
>> isSet(sortedBag) x 21,576,228 ops/sec ±1.72% (91 runs sampled)
>> isSet(sortedSet) x 5,523,591 ops/sec ±1.73% (92 runs sampled)
Fastest test is isSet(sortedBag) at 1.03x faster than isSet(unsortedBag)

Running suite map [bench/map.bench.js]...
>> _.map x 4,501,800 ops/sec ±1.35% (95 runs sampled)
>> map(sq, nums) x 5,414,969 ops/sec ±3.54% (94 runs sampled)
>> map(sq)(nums) x 4,569,274 ops/sec ±3.80% (86 runs sampled)
>> mapSq(nums) x 5,767,024 ops/sec ±2.00% (92 runs sampled)
Fastest test is mapSq(nums) at 1.07x faster than map(sq, nums)

Running suite maxBy [bench/maxWith.bench.js]...
>> _.max x 135,732 ops/sec ±0.67% (99 runs sampled)
>> maxBy(computer, nums) x 310,308 ops/sec ±8.15% (79 runs sampled)
>> maxBy(computer)(vals) x 359,903 ops/sec ±2.76% (88 runs sampled)
>> maxVal(vals) x 399,441 ops/sec ±0.90% (100 runs sampled)
Fastest test is maxVal(vals) at 1.29x faster than maxBy(computer, nums) and maxBy(computer)(vals)

Running suite reduce [bench/reduce.bench.js]...
>> _.reduce(nums, add, 0) x 4,421,035 ops/sec ±0.40% (102 runs sampled)
>> reduce(add, 0, nums) x 8,225,459 ops/sec ±1.90% (96 runs sampled)
>> reduce(add, 0)(nums) x 7,246,928 ops/sec ±3.88% (96 runs sampled)
>> reduceAdd(nums) x 9,092,632 ops/sec ±0.84% (98 runs sampled)
Fastest test is reduceAdd(nums) at 1.11x faster than reduce(add, 0, nums)

Done, without errors.

Now, what does this mean? :)

what it means is this ain't free :smile: e.g.
concat(s1, s2) x   10,247,626 --> 5,199,614
concat(s1)(s2) x  1,710,294 --> 655,832
concatS1(s2) x  5,240,847 --> 1,048,869

concat is an interesting case, since it is already op-curried, and still took a significant hit.

Could you explain the six numbers in the snippet you included in your comment, @buzzdecafe? I'm not sure how to read them.

May entabulating it will make it clearer:

testmaster ops/secplaceholder ops/sec
concat(s1, s2)10,247,6265,199,614
concat(s1)(s2)1,710,294655,832
concatS1(s2)5,240,8471,048,869

That's far less than an order of magnitude. I'm totally comfortable with these numbers. If others feel the same way, let's merge this as is. @kedashoe could follow up with an optimization PR if the numbers turn out to be favourable.

i disagree, i think the price is too high

i disagree, i think the price is too high

Okay. I'll investigate @kedashoe's approach this evening.

I'm afraid that "less than an order of magnitude" is not nearly a strong enough criteria.

I'm afraid that "less than an order of magnitude" is not nearly a strong enough criteria.

I'm yet to have my first experience of JavaScript performance being a bottleneck, so when someone says A is twice as fast as B I hear A and B have equivalent performance (just as we round O(2n) to O(n) in big O notation).
I know there are others who do different things with the language who are very sensitive to performance (though I doubt they're using Ramda).
What is considered acceptable performance for this project? If not 10x the running time of vanilla JavaScript with for loops and mutation, is it 5x? 2x? 1.5x? 1.1x? Give me a target. :)

A million times as fast is still the same in big-O.  :smile: So that can't be the only factor to consider.  With JSPerf down, I can't point you to some of the old examples, but  there were some cases where our performance was well over an order of magnitude off from other libraries.  One hellish week of reworking much of our internals got us to the point where our performance was comparable with the big boys.
We're not trying to compare against for loops, but you might be surprised to learn that functions like map, reduce, and filter are generally faster than their native counterparts.
Most of the test suites include a lodash test, which at the time was the best-of-breed for performance.  Ramda often surpasses it in spite of the auto-currying, mostly because of our simpler API.  That is never going to be our specific goal, but I think that we want to continue to play in the same sandbox.

I've updated this pull request to use @kedashoe's optimizations. Here are the updated numbers:

test
master ops/sec
placeholder ops/sec

concat(s1, s2)
10,247,626
9,428,834

concat(s1)(s2)
1,710,294
7,313,137

concatS1(s2)
5,240,847
10,860,689

Here's the full output:
20:34 ~/github.com/ramda/ramda (placeholder)
$ grunt benchmark
Running "benchmark:all" (benchmark) task

Running suite concat [lib/bench/concat.bench.js]...
>> _(s1).concat(s2) x 1,448,262 ops/sec ±2.42% (99 runs sampled)
>> concat(s1, s2) x 9,428,834 ops/sec ±3.12% (89 runs sampled)
>> concat(s1)(s2) x 7,313,137 ops/sec ±5.73% (81 runs sampled)
>> concatS1(s2) x 10,860,689 ops/sec ±3.11% (96 runs sampled)
Fastest test is concatS1(s2) at 1.15x faster than concat(s1, s2)

Running suite curry [lib/bench/curry.bench.js]...
>> _x4(100) x 11,949,741 ops/sec ±3.10% (91 runs sampled)
>> mult4(100) x 1,539,249 ops/sec ±2.98% (91 runs sampled)
>> manual(100) x 54,511,421 ops/sec ±2.72% (86 runs sampled)
Fastest test is manual(100) at 4.6x faster than _x4(100)

Running suite forEach [lib/bench/each.bench.js]...
>> _.each(nums, x2) x 393,624 ops/sec ±3.24% (89 runs sampled)
>> forEach(x2, nums) x 434,199 ops/sec ±0.76% (98 runs sampled)
>> forEach(x2)(nums) x 369,324 ops/sec ±5.60% (85 runs sampled)
Fastest test is forEach(x2, nums) at 1.18x faster than forEach(x2)(nums) and _.each(nums, x2)

Running suite filter where [lib/bench/filter-where.bench.js]...
>> _.filter(objs, {x: []}) x 105,438 ops/sec ±4.80% (90 runs sampled)
>> filter(where({x: isEmpty}), objs) x 272,448 ops/sec ±8.17% (72 runs sampled)
>> filter(where({x: isEmpty}))(objs) x 317,189 ops/sec ±6.36% (83 runs sampled)
>> filterEmptyX(objs) x 635,131 ops/sec ±2.76% (92 runs sampled)
>> _.filter(objs, {y: false}) x 945,481 ops/sec ±1.52% (93 runs sampled)
>> filter(where({y: false}), objs) x 460,322 ops/sec ±2.19% (89 runs sampled)
>> filter(where({y: false}))(objs) x 455,764 ops/sec ±3.97% (91 runs sampled)
>> filterFalseY(objs) x 1,632,214 ops/sec ±2.06% (90 runs sampled)
Fastest test is filterFalseY(objs) at 1.73x faster than _.filter(objs, {y: false})

Running suite filter [lib/bench/filter.bench.js]...
>> _.filter(nums, isEven) x 2,496,910 ops/sec ±1.89% (92 runs sampled)
>> filter(isEven, nums) x 2,415,417 ops/sec ±1.84% (92 runs sampled)
>> filter(isEven)(nums) x 2,137,426 ops/sec ±3.43% (93 runs sampled)
>> filterEven(nums) x 2,587,186 ops/sec ±2.06% (94 runs sampled)
Fastest test is filterEven(nums) at 1.04x faster than _.filter(nums, isEven)

Running suite find where [lib/bench/find-where.bench.js]...
>> _.find(objs, {x: []}) x 605,994 ops/sec ±4.49% (90 runs sampled)
>> find(where({x: isEmpty}), objs) x 518,733 ops/sec ±0.66% (93 runs sampled)
>> find(where({x: isEmpty}))(objs) x 513,727 ops/sec ±3.60% (88 runs sampled)
>> findEmptyX(objs) x 2,293,058 ops/sec ±1.16% (97 runs sampled)
>> _.find(objs, {y: false}) x 1,263,956 ops/sec ±3.98% (92 runs sampled)
>> find(where({y: false}), objs) x 641,623 ops/sec ±2.88% (94 runs sampled)
>> find(where({y: false}))(objs) x 604,415 ops/sec ±3.41% (92 runs sampled)
>> findFalseY(objs) x 6,681,018 ops/sec ±1.94% (97 runs sampled)
Fastest test is findFalseY(objs) at 2.9x faster than findEmptyX(objs)

Running suite find [lib/bench/find.bench.js]...
>> _.find(nums, isZero) x 6,521,106 ops/sec ±0.63% (98 runs sampled)
>> find(isZero, nums) x 11,210,923 ops/sec ±2.95% (94 runs sampled)
>> find(isZero)(nums) x 8,474,279 ops/sec ±2.35% (92 runs sampled)
>> findZero(nums) x 11,714,365 ops/sec ±3.01% (90 runs sampled)
Fastest test is findZero(nums) at 1.04x faster than find(isZero, nums)

Running suite findIndex where [lib/bench/findIndex-where.bench.js]...
>> _.findIndex(objs, {x: []}) x 602,254 ops/sec ±3.02% (88 runs sampled)
>> findIndex(where({x: isEmpty}), objs) x 540,340 ops/sec ±1.90% (94 runs sampled)
>> findIndex(where({x: isEmpty}))(objs) x 518,215 ops/sec ±2.51% (88 runs sampled)
>> findIndexEmptyX(objs) x 2,334,276 ops/sec ±1.46% (95 runs sampled)
>> _.findIndex(objs, {y: false}) x 1,370,551 ops/sec ±1.57% (97 runs sampled)
>> findIndex(where({y: false}), objs) x 818,761 ops/sec ±3.20% (94 runs sampled)
>> findIndex(where({y: false}))(objs) x 769,975 ops/sec ±1.47% (94 runs sampled)
>> findIndexFalseY(objs) x 5,791,335 ops/sec ±3.66% (89 runs sampled)
Fastest test is findIndexFalseY(objs) at 2.5x faster than findIndexEmptyX(objs)

Running suite findIndex [lib/bench/findIndex.bench.js]...
>> _.findIndex(nums, isZero) x 5,268,609 ops/sec ±5.69% (79 runs sampled)
>> findIndex(isZero, nums) x 10,135,591 ops/sec ±5.12% (84 runs sampled)
>> findIndex(isZero)(nums) x 8,533,386 ops/sec ±3.62% (87 runs sampled)
>> findIndexZero(nums) x 12,397,905 ops/sec ±2.45% (91 runs sampled)
Fastest test is findIndexZero(nums) at 1.22x faster than findIndex(isZero, nums)

Running suite indexOf [lib/bench/indexof.bench.js]...
>> _.indexOf x 25,674,999 ops/sec ±0.48% (95 runs sampled)
>> indexOf(sq, nums) x 20,509,740 ops/sec ±1.90% (91 runs sampled)
>> indexOf(sq)(nums) x 15,760,174 ops/sec ±3.19% (95 runs sampled)
>> idxOf23(nums) x 24,409,933 ops/sec ±2.06% (91 runs sampled)
Fastest tests are _.indexOf,idxOf23(nums) at 1.05x faster than idxOf23(nums)

Running suite isSet [lib/bench/isset.bench.js]...
>> isSet(unsortedBag) x 23,518,856 ops/sec ±0.72% (96 runs sampled)
>> isSet(unsortedSet) x 5,962,096 ops/sec ±1.13% (100 runs sampled)
>> isSet(sortedBag) x 22,310,952 ops/sec ±2.09% (94 runs sampled)
>> isSet(sortedSet) x 6,006,676 ops/sec ±0.66% (97 runs sampled)
Fastest test is isSet(unsortedBag) at 1.05x faster than isSet(sortedBag)

Running suite map [lib/bench/map.bench.js]...
>> _.map x 4,448,616 ops/sec ±0.87% (99 runs sampled)
>> map(sq, nums) x 4,157,810 ops/sec ±1.32% (95 runs sampled)
>> map(sq)(nums) x 4,006,617 ops/sec ±0.83% (99 runs sampled)
>> mapSq(nums) x 4,345,454 ops/sec ±1.59% (96 runs sampled)
Fastest tests are _.map,mapSq(nums) at 1.02x faster than mapSq(nums)

Running suite maxBy [lib/bench/maxWith.bench.js]...
>> _.max x 149,081 ops/sec ±0.63% (101 runs sampled)
>> maxBy(computer, nums) x 412,335 ops/sec ±0.59% (100 runs sampled)
>> maxBy(computer)(vals) x 395,273 ops/sec ±1.30% (96 runs sampled)
>> maxVal(vals) x 405,991 ops/sec ±1.49% (98 runs sampled)
Fastest tests are maxBy(computer, nums),maxVal(vals) at 1.02x faster than maxVal(vals)

Running suite reduce [lib/bench/reduce.bench.js]...
>> _.reduce(nums, add, 0) x 4,279,931 ops/sec ±1.18% (98 runs sampled)
>> reduce(add, 0, nums) x 7,603,141 ops/sec ±1.67% (96 runs sampled)
>> reduce(add, 0)(nums) x 7,014,637 ops/sec ±0.95% (96 runs sampled)
>> reduceAdd(nums) x 9,120,461 ops/sec ±0.59% (99 runs sampled)
Fastest test is reduceAdd(nums) at 1.20x faster than reduce(add, 0, nums)

Done, without errors.

at a glance, this looks like a better bargain.

That's what I was thinking as well.  This at least is pretty close to acceptable.  It would be nice to look around to see if we can squeeze out additional optimizations, but I think we're on the right path now.
Has the new implementation changed the list of pros and cons?

It would be nice to look around to see if we can squeeze out additional optimizations, but I think we're on the right path now.

I doubt the implementations of _curry2 and _curry3 can be optimized. There may well be changes we can make to curryN to improve its performance. Could we leave this to @megawac for a follow-up pull request? :smile:

Has the new implementation changed the list of pros and cons?

It adds two inconsistencies.
First, it's not valid to use "trailing" placeholders with functions curried by _curry2 or _curry3. Prior to the optimization, g(_, 2, _) and g(_, 2) were equivalent for a curried ternary function g. Trailing placeholders are not necessary, of course, but it's a shame to lose the symmetry between g(_, 2, 3) and g(1, 2, _).
Secondly, curryN and the internal _curry2 and _curry3 functions disagree as to whether extra arguments should be forwarded to the wrapped function. What is the desired behaviour?

First, it's not valid to use "trailing" placeholders with functions curried by _curry2 or _curry3

Good.

Trailing placeholders are not necessary, of course, but it's a shame to lose the symmetry between g(_, 2, 3) and g(1, 2, _).

I disagree. Trailing placeholder on a curried function is pointless. So for symmetry we would have to have a placeholder in first position that is also pointless.

Secondly, curryN and the internal _curry2 and _curry3 functions disagree as to whether extra arguments should be forwarded to the wrapped function. What is the desired behaviour?

I think we should consistently pass additional args in.
The other difference is that curryN applies in this context, but the internal ones do not.

Trailing placeholder on a curried function is pointless.

I value consistency irrespective of usefulness. R.add(R.__, 1) is a "pointless" construct in that it's equivalent to R.add(1), but it would be a surprise were it not equivalent. This would confuse the mental model.
I find this behaviour similarly surprising:
R.concat(R.__, 'bar')('foo');  // => 'foobar'
R.concat('foo', R.__)('bar');  // => TypeError: string is not a function

In my mental model R.__ leaves a gap for an argument to be provided later. This is simple to reason about and explain. The current approach requires us to say R.__ acts as a placeholder for an argument to be provided later, unless it is in last position is which case R.__ itself is partially applied in that position. :\

I value consistency irrespective of usefulness. R.add(R.__, 1) is a "pointless" construct in that it's equivalent to R.add(1), but it would be a surprise were it not equivalent. This would confuse the mental model.

What if we put the "pointless" cases at the end of the if..elses, maybe not such a speed hit then? if (a === __ && b === __ && c === __) { can be last ;)

I think we should consistently pass additional args in.

The other difference is that curryN applies in this context, but the internal ones do not.

Will be interesting to see the speed ramifications of passing along all arguments/using apply. This is an interesting trade off however, as if you use apply you can pass along context and you can have curryN call curry2 and curry3 for fn.length < 4, which I would think is the vast majority of cases where users use curry

What if we put the "pointless" cases at the end of the if..elses, maybe not such a speed hit then? if (a === __ && b === __ && c === __) { can be last ;)

I don't think that works. Consider _curry2, which currently has two code paths for the arguments.length >= 2 case:
if (a === __) {
  return function(a) { return fn(a, b); };
} else {
  return fn(a, b);
}

If we were to handle all four combinations—(a, b), (a, _), (_, b), and (_, _)—we'd need to check for (_, _) first:
if (a === __ && b === __) {
  return _curry2(fn);
} else if (a === __) {
  return function(a) { return fn(a, b); };
} else if (b === __) {
  return function(b) { return fn(a, b); };
} else {
  return fn(a, b);
}

Will be interesting to see the speed ramifications of passing along all arguments/using apply. This is an interesting trade off however, as if you use apply you can pass along context and you can have curryN call curry2 and curry3 for fn.length < 4, which I would think is the vast majority of cases where users use curry

Great point. I imagine apply will hurt performance, but it'll be nice if curried third-party functions get a speed boost.

I doubt the implementations of _curry2 and _curry3 can be optimized. There may well be changes we can make to curryN to improve its performance. Could we leave this to @megawac for a follow-up pull request? :smile:

Fine by me.  @megawac, any interest in some more optimization work here?

Trailing placeholders are not necessary, of course, but it's a shame to lose the symmetry between g(_, 2, 3) and g(1, 2, _).

I agree.  I would also like to be able to state rules for such things as simple invariants.  I disagree with @buzzdecafe's concerns regarding pointlessness.  We shouldn't care about whether the user is doing something meaningful or not, just whether it fits within easily described and easily implemented rules.  (I've lost this fight before, though, and will probably lose it again.  If I had my way curry((a, b) => a + b)(42)() :: b => 42 + b instead of throwing an error.)

Secondly, curryN and the internal _curry2 and _curry3 functions disagree as to whether extra arguments should be forwarded to the wrapped function. What is the desired behaviour?

I think we should consistently pass additional args in.

The other difference is that curryN applies in this context, but the internal ones do not.

Agree with @buzzdecafe on both points.  But so long as _curry2 and _curry3 remain internal, we don't have to change their implementations to match _curryN.  We don't use the extra arguments or the thisArg internally.

But so long as _curry2 and _curry3 remain internal, we don't have to change their implementations to match _curryN. We don't use the extra arguments or the thisArg internally.

Good point. The various curry functions need to agree on the handling of R.__, but not on the handling of extra arguments and context.

R.add(R.__, 1) is a "pointless" construct in that it's equivalent to R.add(1)

Yes. See my prior objection to generalizing the prefix/infix conversion into a placeholder concept.
I have softened on that point; I see that we may be able to use a "placeholder" generally at not too bad of a price. However, i strongly object to the pointless cases getting covered. That is exactly the type of hand-holding i think the lib should not be doing.

Yes, that was the argument I lost! :smiling_imp:
I still haven't acquiesced.  I think consistent laws are much more important, and don't feel it's  hand-holding to enforce such laws.  Instead, I feel like by making exceptions to the laws, we're just setting ourselves up to be the ones who got it wrong for some oddball cases.
And I'd much rather document systems with consistent laws than ones with exceptions.

If we were to handle all four combinations—(a, b), (a, ), (, b), and (_, )—we'd need to check for (, _) first:

ah good point. Maybe something like this?
if (a !== __ && b !== __) {
    return fn(a, b);
} else if (a !== __) {
    return function(b) { return fn(a, b); };
} else if (b !== __) {
    return function(a) { return fn(a, b); };
} else {
    return _curry2(fn);
}

Anyway, enough napkin coding before you all even decide which way you want to go :)

I've updated this pull request. We now allow trailing placeholders and forward extra arguments. What else needs to happen in order to be awarded an emoji?

Did you check that there was no significant further performance degradation from these changes?  If so, I'm willing to give it an ":herb:.",

Here are the latest results:
10:59 ~/github.com/ramda/ramda (placeholder)
$ grunt benchmark
Running "benchmark:all" (benchmark) task

Running suite concat [lib/bench/concat.bench.js]...
>> _(s1).concat(s2) x 1,332,097 ops/sec ±3.25% (89 runs sampled)
>> concat(s1, s2) x 9,677,772 ops/sec ±1.05% (97 runs sampled)
>> concat(s1)(s2) x 8,285,454 ops/sec ±1.05% (97 runs sampled)
>> concatS1(s2) x 10,531,996 ops/sec ±3.44% (88 runs sampled)
Fastest test is concatS1(s2) at 1.09x faster than concat(s1, s2)

Running suite curry [lib/bench/curry.bench.js]...
>> _x4(100) x 12,182,760 ops/sec ±2.65% (92 runs sampled)
>> mult4(100) x 1,644,102 ops/sec ±0.95% (95 runs sampled)
>> manual(100) x 57,094,471 ops/sec ±1.79% (85 runs sampled)
Fastest test is manual(100) at 4.7x faster than _x4(100)

Running suite forEach [lib/bench/each.bench.js]...
>> _.each(nums, x2) x 361,723 ops/sec ±3.69% (87 runs sampled)
>> forEach(x2, nums) x 344,304 ops/sec ±5.46% (79 runs sampled)
>> forEach(x2)(nums) x 364,424 ops/sec ±3.94% (86 runs sampled)
Fastest tests are forEach(x2)(nums),forEach(x2, nums) at 1.06x faster than forEach(x2, nums)

Running suite filter where [lib/bench/filter-where.bench.js]...
>> _.filter(objs, {x: []}) x 100,312 ops/sec ±2.92% (87 runs sampled)
>> filter(where({x: isEmpty}), objs) x 354,801 ops/sec ±5.37% (88 runs sampled)
>> filter(where({x: isEmpty}))(objs) x 335,298 ops/sec ±4.25% (85 runs sampled)
>> filterEmptyX(objs) x 604,654 ops/sec ±2.18% (88 runs sampled)
>> _.filter(objs, {y: false}) x 910,607 ops/sec ±1.76% (91 runs sampled)
>> filter(where({y: false}), objs) x 449,428 ops/sec ±6.65% (76 runs sampled)
>> filter(where({y: false}))(objs) x 481,706 ops/sec ±2.38% (88 runs sampled)
>> filterFalseY(objs) x 1,731,338 ops/sec ±4.13% (83 runs sampled)
Fastest test is filterFalseY(objs) at 1.90x faster than _.filter(objs, {y: false})

Running suite filter [lib/bench/filter.bench.js]...
>> _.filter(nums, isEven) x 2,292,002 ops/sec ±4.76% (87 runs sampled)
>> filter(isEven, nums) x 2,353,271 ops/sec ±2.36% (90 runs sampled)
>> filter(isEven)(nums) x 2,094,612 ops/sec ±2.64% (91 runs sampled)
>> filterEven(nums) x 2,615,841 ops/sec ±0.59% (98 runs sampled)
Fastest test is filterEven(nums) at 1.14x faster than _.filter(nums, isEven) and filter(isEven, nums)

Running suite find where [lib/bench/find-where.bench.js]...
>> _.find(objs, {x: []}) x 655,028 ops/sec ±1.15% (97 runs sampled)
>> find(where({x: isEmpty}), objs) x 575,390 ops/sec ±4.18% (93 runs sampled)
>> find(where({x: isEmpty}))(objs) x 630,704 ops/sec ±3.90% (90 runs sampled)
>> findEmptyX(objs) x 2,062,005 ops/sec ±2.92% (85 runs sampled)
>> _.find(objs, {y: false}) x 1,194,466 ops/sec ±2.65% (92 runs sampled)
>> find(where({y: false}), objs) x 611,564 ops/sec ±1.13% (96 runs sampled)
>> find(where({y: false}))(objs) x 577,268 ops/sec ±1.28% (94 runs sampled)
>> findFalseY(objs) x 6,597,649 ops/sec ±5.78% (91 runs sampled)
Fastest test is findFalseY(objs) at 3.2x faster than findEmptyX(objs)

Running suite find [lib/bench/find.bench.js]...
>> _.find(nums, isZero) x 6,266,766 ops/sec ±1.17% (96 runs sampled)
>> find(isZero, nums) x 10,158,687 ops/sec ±2.51% (93 runs sampled)
>> find(isZero)(nums) x 8,381,480 ops/sec ±1.34% (95 runs sampled)
>> findZero(nums) x 12,511,820 ops/sec ±1.22% (96 runs sampled)
Fastest test is findZero(nums) at 1.23x faster than find(isZero, nums)

Running suite findIndex where [lib/bench/findIndex-where.bench.js]...
>> _.findIndex(objs, {x: []}) x 585,945 ops/sec ±2.57% (89 runs sampled)
>> findIndex(where({x: isEmpty}), objs) x 483,290 ops/sec ±4.78% (83 runs sampled)
>> findIndex(where({x: isEmpty}))(objs) x 466,634 ops/sec ±5.22% (80 runs sampled)
>> findIndexEmptyX(objs) x 2,228,960 ops/sec ±0.81% (95 runs sampled)
>> _.findIndex(objs, {y: false}) x 1,153,848 ops/sec ±4.66% (86 runs sampled)
>> findIndex(where({y: false}), objs) x 846,775 ops/sec ±3.06% (87 runs sampled)
>> findIndex(where({y: false}))(objs) x 827,752 ops/sec ±1.50% (92 runs sampled)
>> findIndexFalseY(objs) x 6,287,252 ops/sec ±1.69% (92 runs sampled)
Fastest test is findIndexFalseY(objs) at 2.8x faster than findIndexEmptyX(objs)

Running suite findIndex [lib/bench/findIndex.bench.js]...
>> _.findIndex(nums, isZero) x 6,290,793 ops/sec ±0.88% (93 runs sampled)
>> findIndex(isZero, nums) x 10,641,627 ops/sec ±1.30% (92 runs sampled)
>> findIndex(isZero)(nums) x 8,155,004 ops/sec ±2.67% (90 runs sampled)
>> findIndexZero(nums) x 12,447,788 ops/sec ±1.43% (95 runs sampled)
Fastest test is findIndexZero(nums) at 1.17x faster than findIndex(isZero, nums)

Running suite indexOf [lib/bench/indexof.bench.js]...
>> _.indexOf x 26,068,758 ops/sec ±0.82% (93 runs sampled)
>> indexOf(sq, nums) x 18,102,930 ops/sec ±1.14% (95 runs sampled)
>> indexOf(sq)(nums) x 12,936,389 ops/sec ±3.15% (86 runs sampled)
>> idxOf23(nums) x 24,095,052 ops/sec ±0.60% (95 runs sampled)
Fastest test is _.indexOf at 1.08x faster than idxOf23(nums)

Running suite isSet [lib/bench/isset.bench.js]...
>> isSet(unsortedBag) x 23,769,585 ops/sec ±0.95% (96 runs sampled)
>> isSet(unsortedSet) x 5,377,459 ops/sec ±2.45% (90 runs sampled)
>> isSet(sortedBag) x 22,278,258 ops/sec ±2.03% (94 runs sampled)
>> isSet(sortedSet) x 5,214,462 ops/sec ±3.45% (87 runs sampled)
Fastest test is isSet(unsortedBag) at 1.07x faster than isSet(sortedBag)

Running suite map [lib/bench/map.bench.js]...
>> _.map x 3,929,751 ops/sec ±3.68% (90 runs sampled)
>> map(sq, nums) x 3,603,134 ops/sec ±3.26% (87 runs sampled)
>> map(sq)(nums) x 3,472,753 ops/sec ±2.78% (91 runs sampled)
>> mapSq(nums) x 3,894,440 ops/sec ±3.28% (87 runs sampled)
Fastest test is _.map at 1.01x faster than mapSq(nums)

Running suite maxBy [lib/bench/maxWith.bench.js]...
>> _.max x 114,872 ops/sec ±3.47% (87 runs sampled)
>> maxBy(computer, nums) x 362,694 ops/sec ±2.71% (90 runs sampled)
>> maxBy(computer)(vals) x 346,969 ops/sec ±2.81% (90 runs sampled)
>> maxVal(vals) x 352,276 ops/sec ±2.53% (89 runs sampled)
Fastest test is maxBy(computer, nums) at 1.05x faster than maxBy(computer)(vals) and maxVal(vals)

Running suite reduce [lib/bench/reduce.bench.js]...
>> _.reduce(nums, add, 0) x 3,660,738 ops/sec ±3.22% (86 runs sampled)
>> reduce(add, 0, nums) x 5,832,549 ops/sec ±5.83% (85 runs sampled)
>> reduce(add, 0)(nums) x 6,098,419 ops/sec ±2.58% (88 runs sampled)
>> reduceAdd(nums) x 8,510,021 ops/sec ±1.09% (95 runs sampled)
Fastest test is reduceAdd(nums) at 1.46x faster than reduce(add, 0, nums) and reduce(add, 0)(nums)

Done, without errors.

Let me know whether these numbers are acceptable. I'm excited by the prospect of merging this as there are several follow-up pull requests I'd like to open to:

remove R.propOf;
remove R.appendTo and R.prependTo; and
curry the few remaining uncurried functions (e.g. R.arity).

I think I have lost this one, and this is going to happen. I want to register my concerns before we proceed.
We are now mucking about with the most fundamental feature of the library. We should be especially careful about this. We have changed the definition of curry from the simple "it will partially apply arguments until it gets all it needs" to the more complex yet, dare i say, easy "it will partially apply arguments until it gets all it needs, unless you provide the magic placeholder in which case it will partially apply the arguments that are not the placeholder until it gets all the real arguments it needs."
I'm please we can get this at minimal cost in terms of perf. But even then, handling "pointless" cases strikes me as paying for something useless. This would not stick in my craw if it were not such a fundamental function that we are decorating.
I do see the advantages of reducing the library footprint and unifying op and curry. That always felt awkward.
However, I'm not convinced the trade-off is worth it. But I am willing to wait and see. Now that I have said my piece, I will not stand in the way.

I agree there is reason for caution.  And honestly, performance is only the smallest of my reasons for this.  You're right.  It is a major API change, and we do need to think pretty carefully about all the implications.
For me, though, it is a change I've thought about for a while.  I really haven't liked the op/curry dichotomy, and wanted to do precisely this unification.  Moreover, I really would like a one-curry-to-rule-them-all if possible.  I really like the possibility of partially applying, say the second argument to reduce without doing some nasty flip.
So I've been mostly looking at the numbers, although they're hard to see in this format.  But I agree that this is not one to hurry.  Let's kick the tires just a bit more.

 But nobody uses those .... :grimacing:

You are probably aware of the difficulties in interpreting (micro) benchmarks. The JIT compiler tries to optimize the code by for example in-lining functions. This can result in major 'performance improvements' that won't occur in 'real' applications. Egorov is opposing these benchmarks because of their limited use and interpretation difficulties, see e.g. https://www.youtube.com/watch?v=65-RbBwZQdU. I would be very reluctant to change Ramda because of the numbers above solely.

@donnut good point, we should not fetishize these numbers. I take it you are on-board with this change?

While there are some numbers in there that distress me slightly and some that impress me, overall this does not scare me.  @donnut is right that these are only of limited use.  But benchmarks do help us tell if our functions are getting quicker or slower over the various releases.  This would definitely be one of the times of slow-down.

On balance I'm :+1: on this change.
I do appreciate the concerns that @buzzdecafe expressed; most especially the additional difficulty entailed in simply describing what curry does.  But in unifying our APIs, it gives us a chance to give nice clean descriptions for how all our other functions work.
:herb:

I'm not comfortable merging my own pull request in this case as it's been contentious.


Title correction.

Please make corrections on the title Smart_Contacts.
It should be Smart_Contract.

Please make corrections on the title Smart_Contacts.
It should be Smart_Contract.

@Bhaney44 @Arch222


Poor handling of code blocks in the built-in renderer

- Do you want to request a feature or report a bug?
bug
- What is the current behavior?
when editing, the "rendered" version of the page on the right side live updates.  Some code blocks are interpreted as HTML despite being saved appropriately.
- If the current behavior is a bug, please provide the steps to reproduce.
put this in a code block:

GitHub Auth Demo:

Authenticate

and observe that it is parsed instead of being rendered as code.
- What is the expected behavior?
code looks like code in the preview :)
- Please mention your node.js, and operating system version.
built on netlify's installation (https://www.netlify.com/#/admin) on 23 Feb, so whatever version is there.  Built on linux/ubuntu 14.04 via netlify's build system

Closing in favor of #246.


fix inconsistency in brownboost and svm

make test

make test

Could you clarify why Batch class in kdtree_knn_classification_training_batch.h was not extended by similar constructor?

make test

make test

Could you clarify why Batch class in kdtree_knn_classification_training_batch.h was not extended by similar constructor?

In general, I can add such a constructor, but kdtree-knn counts the number of classes within itself. Therefore, adding this constructor will not change anything.
Adding nClasses parameter specifically to kdtree-knnis is a bit more difficult process and will require more detailed consideration.


Update CI to test supported python version

Closes #8
This updates CI to run tests on Python versions 3.8 - 3.10

Closing in order to re-push to try to get tests to start.


Xcode Install Fails

During the install process, the command to install Xcode from the command line seems to fail.

Upon further investigation, my test instance already had the tools installed...
Testers-MacBook-Pro:~ tester$ xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

Will need to revert to a fresh install to see if it still fails or not.

Still fails with a fresh install. However, MacOS gives you the option to install the tools when you try to clone the repo. Just make sure you have all the patches and security updates done prior to cloning the repo.


Add an option to skip toot hashtags

When exporting to markdown to copy to a blog or other media, the hashtags of each toot get in the way, it would be nice to have an option that enables the user to ignore them.
And, maybe, list them at the end if some people want to copy them to another tool (mindmap, note taking application, blog, etc.)

I think they should be grouped and displayed in the header / footer unconditionally - that would improve the readibility

I agree. +1 for footer.