LoginManager.executeNativeAuthenticators returns nil error on iOS 13

Good Day!
I am having issues authorizing via rides sdk. The authorization issue came up with ios 13.
The difference in behaviour between iOS 12 and iOS 13 takes place in the executeNativeAuthenticators method in the LoginManager class:
private func executeNativeAuthenticators(authenticators: [UberAuthenticating], completion: @escaping ((_ fallback: Bool) -> Void)) {
        var fallback: Bool = false
        AsyncDispatcher.exec(for: authenticators.map({ return $0.authorizationURL }),
                             with: { (url: URL) in
                                self.authenticator = authenticators.first(where: { $0.authorizationURL == url })
                             },
                             asyncMethod: DeeplinkManager.shared.open(_:completion:),
                             continue: { (error: NSError?) -> Bool in
                                fallback = false

                                if error == nil {
                                    // don't try next native authenticator
                                    return false
                                }

                                // If the user rejected the attempt to call the Uber app, don't use fallback.
                                if self.loginType == .native, error?.code == DeeplinkErrorType.deeplinkNotFollowed.rawValue {
                                    self.loginCompletion(accessToken: nil, error: UberAuthenticationErrorFactory.errorForType(ridesAuthenticationErrorType: .unableToPresentLogin))

                                    // don't try next native authenticator
                                    return false
                                } else {
                                    fallback = true
                                }

                                // try next native authenticator
                                return true
                             },
                             finally: {
                                completion(fallback)
                             })
    }

My authenticator URL is uberauth://connect?third_party_app_name=[REDACTED]&callback_uri_string=[REDACTED]://oauth/consumer&client_id=[REDACTED]&scope=[scopes]&sdk=ios&sdk_version=0.12.0
On iOS 12, I’m seeing the closure passed to continue param returns true. The error given in the closure is non-nil, thus logic continues and authorizes my application.
However, on iOS 13 I’m seeing the error is nil so it returns false immediately, thus the authorization logic exists right away
Then I receive [REDACTED]/oauth/consumer?error=jwt_creation_failure  from AppDelagate application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey: Any] = [:])
And finally, I receive “The server was unable to understand your request” from loginButton(_ button: LoginButton, didCompleteLoginWithToken accessToken: AccessToken?, error: NSError?)
FYI, the authorization via web browser still works as expected.
The same issue reported on StackOverflow:
https://stackoverflow.com/questions/58868478/uber-sso-errors-with-jwt-creation-failture

+1 also receive the same issue starting from iOS 13.2

@Igorsnaki did you manage to find any workaround?


Feature/configurable controller activator

Added some first unit tests using xunit and Moq and Fluentassertions as this has been chosen by Ninject team
after having created some regression unit tests, allow to configure a custom controller activator type so that it's possible to use Endpoint Metadata from controllerContext to pass additional arguments to the Kernel.Get call (e.g. the name for resolving a named binding)

Note: running xunit tests is a little bit complicated. It can be run on the command line by first publishing the unit test: dotnet publish -c Release22 -f netstandard2.0 and then use the xunit.console from the nuget package restored:
dotnet packages\xunit.runner.console\2.4.1\tools\netcoreapp2.0\xunit.console.dll src\Ninject.Web.AspNetCore.Test\bin\Release22\netstandard2.0\publish\Ninject.Web.AspNetCore.Test.dll

Ah... the "funny" unit testing "integration" with command line tools. I can actually get this to work with dotnet test .\src\Ninject.Web.AspNetCore.sln - but you have to:

add the package reference <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.8.0" /> (that should always be there for .NET Core test projects - see https://github.com/ninject/Ninject/blob/master/src/Ninject.Test/Ninject.Test.csproj)
replace the console runner with the of course confusingly named <PackageReference Include="xunit.runner.visualstudio" Version="2.4.3">
fix the CreateKernel method to disable automatic extension loading or remove the manual loading of the Ninject.Web.AspNetCore assembly since in the context of the unit test project with a project reference, automatic loading actually works


include injection in get_consumption

When installation include solar panel, get_consumption remains to zero if injection > consumption.
In order to implement injection computation two choice :

Implement a dedicated get_injection
Integrate injection in existing get_consumption implementation, and ends with negative value.

While technically both choices make sense, I choose to go with the second one, which will also ensure injection AND consumption would always be computed together on same last and first frame.
This PR shouldn't impact installation without solar panel, and so without injection.
While other will start seeing negative consumption when sun is shining 🌻
Also I noticed enrich_frame wasn't used anymore

Sorry for the delay, I didn't get any notification for a reason I ignore 🤷
Great contribution ! I don't have solar panels yet but I plan to get some. so it will be super useful ! 👍


Mutliple monitor on the server -> display on multiple windows on the client

Not a feature request but I wanted to share something very useful that is (afaik) undocumented.
To display a specific server monitor on the freerdp client, one can use the domain option
For ex, I connect to a 5 monitor virtualbox like so:
xfreerdp /v:xxx.xxx.xxx.xxx  -grab-keyboard -f /d:\@1 to display server screen #1
xfreerdp /v:xxx.xxx.xxx.xxx  -grab-keyboard -f /d:\@2 to display server screen #2
etc..
Initially found this using rdesktop, but xfreerdp has the same option and works better with vbox as it does automatic screen resize better.

@mfauvain that is actually not a FreeRDP (or rdesktop) feature but one of VirtualBox ;)

Ah, thx!
How do we do then when there are physical displays (no virtualbox) on the server and want to have those in multiple windows on the client?

@mfauvain you don´t. RDP is not a mirroring mechanism (yes, there is shadow server, but that is not the main use case) and you have no relation to your physical monitors.
normally you have a single session (=client) with multimonitor support enabled (e.g. that tells the remote your desired monitor resolution, layout, dpi, ...) and the client displays that
by default these are fullscreen sessions, but if you want that in windows, you need to patch the client to show that in windows.

I see. I do use this functionality a lot and find it useful (remote working from a laptop on a multi display setup).
Thx for the help.
Regards


Error when handling **kwargs parameters

Describe the bug
I get the following error when I document **kwargs parameter in my docstring with the two **.
line 216, in read_parameters_section
    signature_param = self.signature.parameters[name]
KeyError: '**kwargs'

To Reproduce
def function(a, **kwargs):
    """
    Args:
        a: a parameter.
        **kwargs: kwarg parameters
    """
    return None

Information (please complete the following information):

OS: Debian
mkdocstrings version: [0.7.0]

Additional context
This seems to come from the inspect module as inspect.signature(function).parameters would return:
mappingproxy({'a': <Parameter "a">, 'kwargs': <Parameter "**kwargs">})

and the **kwargs key is not present but kwargs is.

Haha yes, I thought about this one this morning again. Indeed we should simply remove the * or ** from param names before searching them in the signature.
Moving the issue to pytkdocs.


VOC from AIC : requirements

[ ] Concat layer support for INI and test the concat layer in a model @zhoonit

input_layers = A + B (current support only for A, B)
update realizeMultiInputType()
Test in a model
Maybe add unittest as well

[x]  Model to simulate multiple inputs

Combine the inputs  in the dataset and split  the inputs in the models
corresponding unittests and app tests.

[ ]  Model to support multiple inputs and outputs

Update dataset to support this
Update model to pass multiple inputs to multiple input layers
Update graph to support multiple inputs and outputs

Update topological sort

Input order
Support multiple inputs and outputs for loss layer
Support multiple losses - make loss as a layer in ini interface

[dataset]
...
outputs = input_layer1,input_layer2, input_layer3
label = loss1, loss2 # This requires loss to be a layer as well

[input_layer1]
...

[input_layer2]
...

[input_layer3]
...

Related issue https://github.com/nnstreamer/nntrainer/issues/239

@zhoonit Is concat layer part done, including support of  input_layers=A,B will insert a concat layer with A,B?

@zhoonit Is concat layer part done, including support of input_layers=A,B will insert a concat layer with A,B?

Concat is verified and supported for their requirement.
There are number of things to be done to complete this, if we are not duck tapping it. I think, though, AIC requirement is satisfied, so can be dealt separately.

Please open a new issue listing out the things to be done then.

Closing issue as the current requirements are met. Can re-opened if some bugs arise or create new issue for further requirements.


Preview image not reactive to document change.

When the doc parameter of the autoForm changes, child afQuickFields should update accordingly. However, the fileUpload preview image does not react. Clicking the Reset button seems to force a refresh and the expected preview image is displayed. Is this as intended?
In the following example, the title (text input) will correctly update when theactiveSlide helper changes, but the background (fileUpload) preview image does not change until the Reset button is clicked.
{{#autoForm id="form_editSlide" collection="Slides" doc=activeSlide}}
  {{> afQuickField name="title"}}
  {{> afQuickField name="background"}}
  <button type="submit" class="btn btn-primary">Submit</button>
  <button type="reset" class="btn btn-default">Reset</button>
{{/autoForm}}

+1
And I can say that this issue was not present in version 0.2.5.

This should be fixed in 0.3.0.

I still have the same problem on 0.4.0 even with the reset button. Any comment on this?

I'm using<EMAIL_ADDRESS>and still have this problem.  Anyone got a workaround?

+1, experienced just now.
Any workaround or ideas?


feat: support PHP 8.2

It's not currently possible to use this library with PHP < 8.3. While upgrading to PHP 8.3 is the obvious desirable solution, it's not an immediately available or feasible option for many PHP developers.
It would be nice to be able to use this library through PHP 8.2's official end-of-life: active support will continue through 8 Dec 2024 (a bit over 6 months from the date of this writing) and security support for another year after that.
It appears that supporting PHP 8.2 is currently possible with one small change (included in this PR) to code that causes a syntax error under PHP < 8.3. It's worth noting that the affected line does not presently appear to have all branches or paths covered by tests. However, with the change, all existing tests pass under PHP 8.2. If I understand the function of the affected line correctly, using constant() is an equivalent backward-compatible way of producing the same behavior.

Thanks for this!


feat(EMI-2159): Auction registration address autocomplete

The type of this PR is: FEAT

This PR solves EMI-2159
Description
This PR adds autocomplete for US addresses on auction registration and makes minor changes to the registration form layout to follow our latest specs for address forms.

After discussing, we'll probably split this into two separate PRs - one for the layout and another for the autocomplete input. I'm going to take a look at what we have so far here and see if it is worth using that or starting from scratch.


Property access

We should be able to use the reflection database from rbx_reflection to make accessing properties possible.

The first stab at this API (raw access in remodel.getRawProperty and remodel.setRawProperty) is a first step forward that opens the door to a lot of possibilities. It's in master!


Supabase not saving full_name when user signs up

Hi!
I was doing a project on my own and when trying to update the users table it gives a 404 supabase error.
I have seen that it happens to more people but I cannot see why, it seems that it is related to the policies of the table, but I have tried everything and nothing works.
Desperate I have created a new project in supabase, I have cloned this repo and executed the SQL schema, but it also gives the same error.

I also tried with Postman but returns the same error.
Maybe is a bug with supabase or something bad configured.
Update: I disabled Row Level Policy and it worked but that's not secure
Someone else happens?

By default the Supabase signUp function doesn't return a user session. Without a user session the Row Level Security will prevent any updates to the data. Supabase wants the user to confirm their email first - then it'll return a user session.
Quick fix
Go to your Supabase admin panel -> Authentication -> Settings and disable Enable email confirmations. Once disabled the signUp function returns a user session (with which you can update the data).
Read the signUp notes here

Oh, thank you. My bad... Is my first time with supabase and I didn't realize that


Print verification coverage only when -trace used

The -trackVerificationCoverage option enables tracking of verification coverage but the results are printed only when -trace is also provided. This makes it possible to see the results in text, but makes the output less noisy for clients of Boogie as a library (such as Dafny).

GC.bpl is timing out in one of the configurations. I have observed some flakiness in verification times for this example before.  I found that /vcsSplitOnEveryAssert helps.

I will look into the flakiness of GC.bpl later. Meanwhile, if you need to merge this PR now, is there a way to override the merge requirements?

It's not super urgent that I merge this PR. I'd like to do it by the end of next week, perhaps, but before then isn't critical. So if you fix it as part of a separate PR, this one should then go through after merging with master.

@atomb : I pushed a fix to GC.bpl. Looks good now.


Question about notification feature

Hi falahati, your class library appears to be quite sophisticated for managing the windows firewall rules - nice work!
However one feature which seems to be missing (or would be nice to have) in the library is a way to get notified when packages are dropped (or connection blocked) together with the information about which rule blocked a connection. Essentially what is shown in EventViewer > security > event 5157.
This would be very useful for troubleshooting and when implementing a firewall UI.
Is this something you would consider or is it maybe available but I haven't seen it?
Thx. harry

Up until this point; this library was only a wrapper around the Windows Firewall COM. However, your suggestion fits nicely with this library.
Meanwhile, I can use any information I can get about this. Do you know if there is a similar event for Windows XP? And if so, what is the event id? Is there a specific difference between the way that this event is generated and it's content under Windows XP, Vista, 7, 8 and 10? In other words I need any piece of information that might end up being helpful.
Events 2002, 2004, 2006, 2010 also seems promising.

Is there a specific difference between the way that this event is generated and it's content under Windows XP, Vista, 7, 8 and 10?

These events are controlled by "auditpol.exe" afaik. Think this link explains it quite well and is a good starting point for you:
https://superuser.com/a/1141671

similar event for Windows XP?

Don't know myself - auditpol Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows Server 2012, Windows 8
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731451(v=ws.11)

Doing some more research on this matter I think utilizing the Windows Filtering Platform (WFP)  would be much more promising instead of relying on auditpol.
Example: To find a blocking rule you can use the following netsh commands:

netsh wfp show netevents
creates "netevents.xml" containing dropped pakets within the last view minutes the xml includes all details including the filterId which triggered the filter (see  )
netsh wfp show filters
creates "filters.xml"containing all filters applied with their

In addition there are many more useful functions which are useful to monitor the operation of the filtering platform on windows.
Best of all, a C API is available with all the functionality  - but so far I haven't found a C# managed code API.
WFP API documentation:

Windows Filtering Platform API Reference: https://docs.microsoft.com/en-us/windows/win32/fwp/fwp-reference
Management Functions: https://docs.microsoft.com/en-us/windows/win32/fwp/fwp-mgmt-functions
Viewing current State: https://docs.microsoft.com/en-us/windows/win32/fwp/viewing-current-state
Displaying Net Event: https://docs.microsoft.com/en-us/windows/win32/fwp/displaying-net-events
Architecture: https://docs.microsoft.com/is-is//windows-hardware/drivers/network/windows-filtering-platform-architecture-overview

What do you think - would you be able to create a WFPHelper from that?

WFP has some messy API. And I thought NVAPI was overly convoluted. Structures having up to 3 different definitions and memory management is done on the library level is timeconsuming to successfully port to C#. But it is possible. I mean, as you can see I like to create wrapper and helper for native parts of the Windows or other software.
Thanks for providing detailed information. I take a look into it to see if it is possible to plan a clear path to an MVP since the whole library seems big enough to not be able to release a wrapper in one go due to the time it will consume.

Great! Thanks for looking into that - if it would be easy, somebody would have done it already ;)
Here is some additional information which may be useful:

Discussion about WFP type extraction: https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/a65bf197-937b-401e-b15f-0e1c3decdb14/windows-filtering-platform-and-net?forum=wfp

P/Invoke interop assistant on github - guess you know that tool already: https://github.com/jaredpar/pinvoke-interop-assistant


Make type literal delimiter semicolon by default

see comments in https://github.com/palantir/tslint/pull/2374

closed by #2787


Proposal: Add 'inputsecretopt' option

I propose to add 'inputsecretopt' option to improve the usability of inputsecret().
'inputsecretopt' ('iscopt') accepts the below one or both string values (or empty).

showlast: Show the last input character
reveal: Can toggle reveal/mask the input characters by Ctrl-X

I am wondering, do we need to special case the OptionSet autocommand to not trigger on this option? (for example it doesn't trigger on the 'key' option for obvious reasons). Or would it be generally okay, if one can react to changes on this option? I am unsure currently and just mentioning it so we do not introduce some kind of security issues here.

Ozaki Kiichi wrote:

I propose to add 'inputsecretopt' option to improve the usability of inputsecret().
'inputsecretopt' ('iscopt') accepts the below one or both string values (or empty).

showlast: Show the last input character
reveal: Can toggle reveal/mask the input characters by Ctrl-X

I'm not sure we should include this.  Perhaps showing the last entered
character is OK, but I don't think it helps much and it does lower the
security.  I don't think any other program does this, "sudo" does not
have an option for it.
--
What do you get when you cross a joke with a rehtorical question?
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Considering:

this is a small security risk
I haven't heard anybody asking for this, there is no thumbs-up on this pull request
No response on my comment of July 18
I think we should drop this pull request.


nvim starts with errors when gopls is not found

Hi @ray-x, thanks for all your work on go.nvim.
I'm running the latest (88a846b) version with a simple packer setup like
  use({
    "ray-x/go.nvim",
    config = function()
      require("go").setup()
    end,
  })

When I remove gopls or not have gopls in my path (which is how I discovered this issue; when editing my kitty terminal config on macOS with cmd-,) nvim starts with the following error:
Error detected while processing BufEnter Autocommands for "<buffer=1>":
E5108: Error executing lua Vim:E475: Invalid value for argument cmd: 'gopls' is not executable
stack traceback:
        [C]: in function 'jobstart'
        ...are/nvim/site/pack/packer/start/go.nvim/lua/go/gopls.lua:110: in function 'version'
        ...are/nvim/site/pack/packer/start/go.nvim/lua/go/gopls.lua:215: in function 'setups'
        ...share/nvim/site/pack/packer/start/go.nvim/lua/go/lsp.lua:58: in main chunk
        [C]: in function 'require'
        .../nvim/site/pack/packer/start/go.nvim/lua/go/codelens.lua:35: in function 'refresh'
        [string ":lua"]:1: in main chunk

Afterwards, while editing (also non-go files), I get errors like this when exiting insert mode:
Error detected while processing InsertLeave Autocommands for "<buffer=1>":
E5108: Error executing lua .../nvim/site/pack/packer/start/go.nvim/lua/go/codelens.lua:35: loop or previous error loading module 'go.lsp'
stack traceback:
        [C]: in function 'require'
        .../nvim/site/pack/packer/start/go.nvim/lua/go/codelens.lua:35: in function 'refresh'
        [string ":lua"]:1: in main chunk

Apart from gracefully handling not having gopls, why running this code when not working on go files/projects?

Thanks for the suggestion. Some checks were added for gopls.


Provide access to ExecOperations in a Settings plugin

Expected Behavior
ExecOperations is available to a Settings plugin.
Current Behavior
There's no equivalent of Project.exec(Action) on Settings. We can inject ProcessOperations but that's internal API.
Context
My goal is to use exec(Action<? super ExecSpec>) to invoke git to collect information that will be included in tags and custom values on a build scan. Doing this in a plugin will allow us to share common configuration across multiple projects built with Gradle.

This will be available in Gradle 6.2.

That was quick. Thanks very much!


Update Homebrew's ObjC plugin

CC: @tbetbetbe
Alternatively, make Cocoapods compile it and forget Homebrew.

Done.


Try to integrate redux-sagas into repo, initial commit for category

WHY

using redux-sagas to manage async network flow
redux-sagas can separate actions from async flow by moving async flows to sagas
request for reviewing and testing
make it easy to test async workflows compared to thunks

TODOs
1. update articles to sagas as well
2. add tests for sagas
Status
It should now be able to merged, still lacks more tests for sagas on failure branches.
Please review.

Thx！Amazing！I will review


[chip/scrap] implemented SW side for chip_lc_scrap

Signed-off-by: Dror Kabely<EMAIL_ADDRESS>Implementation of SW side for #16428
Additional changes:

Transition to SCRAP is randomized between {JTAG, SW} for relevant source states {Dev, Prod, ProdEnd, Rma, TestUnlocked*}
For all other states, transition is performed exclusively by JTAG.

Thanks @dkabely-ot and everyone for the reviews.
I took this over and addressed all comments so that we can get this into the nightlies today.

Ok I ran the random variant of this test with 16 seeds and all of them pass. We should be good to merge this then.
./util/dvsim/dvsim.py hw/top_earlgrey/dv/chip_sim_cfg.hjson -i chip_sw_lc_ctrl_rand_to_scrap --reseed 16


[Infra] Only compile core extension headers once

A custom module map was too difficult. I couldn't get CocoaPods to respect the custom module map and stopped when I started to spin on things. I switched to guarding the headers against being included twice. It seems promising so far. I also tried with using #pragma once but that didn't work because (my guess) is that the problem is not that the same header is being included twice, it's that two different headers with the same content are both being included (once in FirebaseCore and once in FirebaseCoreExtension).
Test cases and their results below:

Below Podfile uses the current state and fails when building docs.

platform :ios, '13.0'

source 'https://github.com/firebase/SpecsDev.git'
source 'https://github.com/firebase/SpecsStaging.git'
source 'https://cdn.cocoapods.org/'

target 'tempDoc' do
  use_frameworks!

  # Pods for tempDoc
  pod 'FirebaseCrashlytics', '11.5.0'
end

Below Podfile uses updated FirebaseCore spec but FirebaseCoreExtension @ main. The framework target builds but the docs target does not build because of the FirebaseCoreExtension @ main does not have guarded headers.

platform :ios, '13.0'

source 'https://github.com/firebase/SpecsDev.git'
source 'https://github.com/firebase/SpecsStaging.git'
source 'https://cdn.cocoapods.org/'

target 'tempDoc' do
  use_frameworks!

  # Pods for tempDoc
  pod 'FirebaseCore', :path => '/Users/nickcooke/Developer/firebase-3' # The branch is `nc/dup-decls`
  pod 'FirebaseCrashlytics', '11.5.0'
end

Below Podfile uses updated FirebaseCore spec AND updated FirebaseCoreExtension spec. The framework target builds AND the docs target builds.

platform :ios, '13.0'

source 'https://github.com/firebase/SpecsDev.git'
source 'https://github.com/firebase/SpecsStaging.git'
source 'https://cdn.cocoapods.org/'

target 'tempDoc' do
  use_frameworks!

  # Pods for tempDoc
  pod 'FirebaseCore', :path => '/Users/nickcooke/Developer/firebase-3' # The branch is `nc/dup-decls`
  pod 'FirebaseCoreExtension', :path => '/Users/nickcooke/Developer/firebase-3' # The branch is `nc/dup-decls`
  pod 'FirebaseCrashlytics', '11.5.0'
end

Below Podfile uses old product pod and floats to pick up updated FirebaseCore (the floating case). The framework target builds but the docs target does not build because of using the FirebaseCoreExtension @ main.

platform :ios, '13.0'

source 'https://github.com/firebase/SpecsDev.git'
source 'https://github.com/firebase/SpecsStaging.git'
source 'https://cdn.cocoapods.org/'

target 'tempDoc' do
  use_frameworks!

  # Pods for tempDoc
  pod 'FirebaseCore', :path => '/Users/nickcooke/Developer/firebase-3' # The branch is `nc/dup-decls`
  pod 'FirebaseCrashlytics', '11.4.0' # older pod!
end

Below Podfile uses old product pod and floats to pick up updated FirebaseCore (the floating case). In this example, it floats to pick up FirebaseCoreExtension as well. The framework target builds and the docs target builds.

platform :ios, '13.0'

source 'https://github.com/firebase/SpecsDev.git'
source 'https://github.com/firebase/SpecsStaging.git'
source 'https://cdn.cocoapods.org/'

target 'tempDoc' do
  use_frameworks!

  # Pods for tempDoc
  pod 'FirebaseCore', :path => '/Users/nickcooke/Developer/firebase-3' # The branch is `nc/dup-decls`
  pod 'FirebaseCoreExtension', :path => '/Users/nickcooke/Developer/firebase-3' # The branch is `nc/dup-decls`
  pod 'FirebaseCrashlytics', '11.4.0' # older pod!
end

Are the podspecs published at /Users/nickcooke/Developer/firebase-3 so they show up in the Pods folder instead of the Development Pods folder?

Are the podspecs published at /Users/nickcooke/Developer/firebase-3 so they show up in the Pods folder instead of the Development Pods folder?

No, is there a way I can do that locally? Or should I stage these to SpecsDev?

I'm not aware of how to do it locally. Staging to SpecsDev would be a good way to test

Hmm, I actually don't think SpecsDev is that helpful because the spec points the same source that staging does.

Should be fine to move the tags to the tip of your branch temporarily and use SpecsStaging

Or  CocoaPods-11.5.0 should be sufficient

I actually went with this:
 pod 'FirebaseCore', :git => 'https://github.com/firebase/firebase-ios-sdk.git', :branch => 'nc/dup-decls'
 pod 'FirebaseCoreExtension', :git => 'https://github.com/firebase/firebase-ios-sdk.git', :branch => 'nc/dup-decls'
 pod 'FirebaseCrashlytics', '11.4.0'

Merged and moving tags to get coverage in the nightlies.

Confirmed the repro in  #13756 now successfully builds docs when pointing at SpecsStaging.

Nice solution, @ncooke3!


Xnero: Watch icecubedigital.com

Xnero requests the watch of the watch_keyword icecubedigital\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

icecubedigital\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by double-beep in Charcoal HQ


Punishments: cap banword count cap before they can cause crashes

If an RO is especially trigger happy, they could cause a constructed
regex like in chat.js to crash each time a method of its is used when
the parametre it gets constructed with is greater than 2 << 14.

Ftr, RegExp overflows at 2 << 16 characters before overflowing. This crash seems to happen for unrelated reasons, since I can only find proof it happens in their unit tests since i'm guessing the real reasons why the crashes happen sooner have to do with other issues than what I was looking at. If you want, I can post the unit tests I based this from

... You're not implementing a cap for the banword list with this code.

Unless you MEAN to edit nameblacklist

Fuuckkkkkkkkkkk

Banword list was what I was aiming for, but if this has the same issue I'll fix both

Blacklists don't use regex at all

I noticed that while git grepping right when you replied...


zanshin: 2017-11-25 -> 2019-07-28

Motivation for this change
General update - needed for recent KDE frameworks update in staging.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

Cc @zraexy


Compilation error when compiling Matlab wrapper on Mac

I set up all the necessary matlab paths for cmake, and successfully generated the makefile.
But when I get to compile the Matlab wrapper, I get the following compilation error:
[ 10%] Building CXX object src/interfaces/matlab/opengm/mex-src/CMakeFiles/hasTruncatedAbsoluteDifferenceFactor.dir/model/hasTruncatedAbsoluteDifferenceFactor.cpp.o [ 10%] Linking CXX shared module hasTruncatedAbsoluteDifferenceFactor.mexmaci64 Undefined symbols for architecture x86_64:   "_mexErrMsgTxt", referenced from:       _mexFunction in hasTruncatedAbsoluteDifferenceFactor.cpp.o   "_mxCreateLogicalScalar", referenced from:       _mexFunction in hasTruncatedAbsoluteDifferenceFactor.cpp.o   "_mxGetClassID", referenced from:       _mexFunction in hasTruncatedAbsoluteDifferenceFactor.cpp.o   "_mxGetData", referenced from:       _mexFunction in hasTruncatedAbsoluteDifferenceFactor.cpp.o   "_mxGetM", referenced from:       _mexFunction in hasTruncatedAbsoluteDifferenceFactor.cpp.o   "_mxGetN", referenced from:       _mexFunction in hasTruncatedAbsoluteDifferenceFactor.cpp.o   "_mxIsComplex", referenced from:       _mexFunction in hasTruncatedAbsoluteDifferenceFactor.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [src/interfaces/matlab/opengm/mex-src/hasTruncatedAbsoluteDifferenceFactor.mexmaci64] Error 1 make[1]: *** [src/interfaces/matlab/opengm/mex-src/CMakeFiles/hasTruncatedAbsoluteDifferenceFactor.dir/all] Error 2 make: *** [all] Error 2
I had a guess about what the problem could be - there seem to be no linking with Matlab libraries in the makefiles produced by cmake. But this didn't solve it, and the error remains. Any help will be much appreciated.
UPDATE: I managed to solve this by manually adding MEX and MX libraries to link.txt files for all .mex files. For writer and loader, I also had to add hdf5 libraries. Still it would be nice to understand whether there is a simpler way.
Another thing: in matlab-examples, cmake disregards MAC mex file extension - .mexmaci64, provided in cmake definition file, and instead uses linux extension .mexa64. I changed these manually as well, in link.txt.
Thank you,
Anastasia

Have you fixed this?


Submit Homebrew formula to core

Would you mind if I submit this project to Homebrew core? That would provide at least three benefits:

(Biggest user-facing benefit) Auto upgrade. A formula installed via a remote .rb file won't be upgraded when brew upgrade --all is run. The only way to upgrade AFAIK is to manually reinstall, so for users who don't follow the project's releases closely, chances are good that it will never be upgraded.

Basic tests are run on Brew Test Bot to ensure a release works on OS X before distributing to users;

You could take this thing off your shoulder. I subscribe to translate-shell's release feed, so I (or anyone else interested) can update the core formula reasonably soon after each release. (I already keep several other core formulae updated, and so far I've been doing a decent job, typically updating the formula hours within a release.)

If you approve, I'll submit the following to core:
class TranslateShell < Formula
  desc "Command-line translator using Google Translate and more."
  homepage "https://www.soimort.org/translate-shell"
  url "https://github.com/soimort/translate-shell/archive/v<IP_ADDRESS>.tar.gz"
  sha256 "7b5a2404ead919570cfa4d741c521ed7e124bbf27d6f5de1a6a598e7e713c2a6"
  head "https://github.com/soimort/translate-shell.git", :branch => "develop"

  depends_on "fribidi"
  depends_on "gawk"
  depends_on "mplayer"
  depends_on "rlwrap"

  def install
    system "make", "PREFIX=#{prefix}"
    system "make", "test"
    bin.install "build/trans"
    man1.install "man/trans.1"
  end

  test do
    assert_equal shell_output("#{bin}/trans -b -s fr -t en bonjour"), "Hello\n"
  end
end

A few notes:

I shortened the description because desc + formula name should not exceed 80 characters in length;
I'm calling bin.install and man1.install to manually install the binary and man page because the install target doesn't work on OS X (OS X uses a very old version of install that doesn't have -D);
I'm making fribidi a dependency (contrary to https://www.soimort.org/translate-shell/translate-shell.rb where fribidi is marked as optional) because (1) fribidi is lightweight so it doesn't hurt; (2) I don't see how fribidi is more optional than the other dependencies.

On second thought, mplayer is actually a big dependency (27.5M), so the formula could be improved to let users choose their text-to-speech engine and utilize existing installations (e.g. I already have mpv installed so I don't need mplayer), if they care about text-to-speech functionality at all:
  option "with-espeak", "Use eSpeak for Text-to-Speech"
  option "with-mpg123", "Use mpg123 for Text-to-Speech"
  option "with-mplayer", "Use mplayer for Text-to-Speech"
  option "with-mpv", "Use mpv for Text-to-Speech"

  depends_on "fribidi"
  depends_on "gawk"
  depends_on "rlwrap"

  depends_on "espeak" => :optional
  depends_on "mpg123" => :optional
  depends_on "mplayer" => :optional
  depends_on "mpv" => :optional

The reason I have chosen not to submit the formula to Homebrew myself is simple: it seems they do not utilize an autonomous registry, other than the centralized GitHub repo. Package maintainers will need to fork the repo, send a pull request every time a new release is made. This process is so laborious that I chose not to do it (otherwise I could have just written a script to automate the task, but git pull / rebase and replying to comments will need extra human intervention). Of course, if someone volunteers to maintain the package, that would be very cool and I see no reason not to approve it.

It's ok to mark fribidi as a hard dependency. Marking mplayer as optional is also fine with me (I didn't put too much thought into this, since mplayer has been around on my system for quite a while thus it's more like a "legacy thing" to me).
Now it came to me that manually invoking make in the install target would be a neat idea (so that we can use GitHub archived releases directly);
make test isn't a must, though. (actually you should remove make test from the formula, it will fail on systems without emacs installed!)
It seems that you've removed the version field. I'm not sure about this, just asking: is this field necessary? (because it seems to me that there would be no other way for brew to reliably tell the version of a formula.)

While you can submit a different version of translate-shell.rb to Homebrew core (and hopefully, get accepted), preferably we should keep two formulae identical. Please let me know your final version when you're done, or even better, send me a patch to the gh-pages branch of the repository, to this file: translate-shell.rb.temp.
(As you may see, the formula is automatically generated from a template whenever I tag a release; I had build.awk to handle these tedious things, so I never had to touch translate-shell.rb myself. If we agree on one single formula, you may just wget the same thing and update it accordingly in the Homebrew core, for future releases.
Thanks for taking your time on this!

Of course, if someone volunteers to maintain the package, that would be very cool and I see no reason not to approve it.

Actually I already have this in my personal tap, and need to update it whenever a new release comes out, so submitting to core and updating there won't be much extra work for me either. And when submitted to core only one person need to do the work for each release, so it's good for everyone.

since mplayer has been around on my system for quite a while thus it's more like a "legacy thing" to me

MPlayer is also legacy to me, but I abandoned it a long time ago (used mplayer2 for a while, then switched to mpv when mplayer2 went dark), so now it feels kinda weird to have MPlayer around since I use it for absolutely nothing... Anyway, I'm not really sure if having a big list of optional dependencies for the same purpose is a good idea. Will ask for Homebrew maintainers' opinions.

make test isn't a must, though.

Yep, know that. The reason I'm invoking it in the install block is because test.awk is removed after installing, so if I want to run the builtin tests at all, I need to run them here.

you should remove make test from the formula, it will fail on systems without emacs installed!

Does it work with Emacs 22.1 which comes with all relatively recent versions of OS X? Anyway I probably should still remove it to accommodate Linuxbrew users.

It seems that you've removed the version field. I'm not sure about this, just asking: is this field necessary? (because it seems to me that there would be no other way for brew to reliably tell the version of a formula.)

Most (if not all) core formulae don't have a version field, because version is automatically deduced from download URLs (note that I'm using https://github.com/soimort/translate-shell/archive/v<IP_ADDRESS>.tar.gz, where the version is obviously <IP_ADDRESS>). These days, if core can't deduce the version from a URL, either another URL is used or the core is updated to accommodate a new URL scheme. A "latest" URL like http://www.soimort.org/translate-shell/translate-shell.tar.gz won't be accepted into core since the formula is bound to break whenever the remote file is updated, and you can't install an old version by checking out an earlier commit.

preferably we should keep two formulae identical.

Do you intend to keep https://www.soimort.org/translate-shell/translate-shell.rb even if accepted into core? IMHO you can just update the installation instructions to brew install translate-shell and be done with it? As I said installing via https://www.soimort.org/translate-shell/translate-shell.rb doesn't provide self-upgrade, so it's really bad user experience. Also, offloading to core also potentially reduces Homebrew-related support burden (although a quick search in the issue tracker indicates that this support burden is practically zero).

Does it work with Emacs 22.1 which comes with all relatively recent versions of OS X? Anyway I probably should still remove it to accommodate Linuxbrew users.

I really don't know, but GNU Emacs 22.1 seems very outdated to me (I'm on 24.5 and don't care about Emacs 22 or 23 support). You will not need make test anyway; I did those tests just to keep myself on track (because AWK programming engages a lot of pitfalls). It makes perfectly no sense for normal users (if they don't care about the code at all).

Most (if not all) core formulae don't have a version field, because version is automatically deduced from download URLs

That explains a lot, thanks!

Do you intend to keep https://www.soimort.org/translate-shell/translate-shell.rb even if accepted into core?

I'm inclined to keep it, since it'll be updated immediately (after each release) without any delay, although it won't take too long before the change lands on Homebrew core (I hope so). Another reason I'd keep this is because Linuxbrew has a 2-tier delay (other than the downstream delay of Homebrew core); sometimes I have to modify a formula manually to get the latest version of a package. Having a self-hosted formula would take the fuss out of it (in case the brew ecosystem doesn't have an ideal response time, impatient users might want to grab the new formula themselves; I myself used to do that quite often).
Of course, the instruction on the homepage will be changed to
$ brew install translate-shell

That's a sure thing, as long as it's in the official Homebrew core. (then probably a link to the self-hosted formula)

Submitted https://github.com/Homebrew/homebrew/pull/49646.

GNU Emacs 22.1 seems very outdated to me (I'm on 24.5 and don't care about Emacs 22 or 23 support).

It is extremely outdated (from 2007), but 22.1 isn't an accident, since it is the last GPLv2 release of Emacs. I just temporarily unlinked my 24.5.1 install, leaving 22.1.1 as the only version to be picked up, and the tests still passed, so it may well be compatible. Anyway, I've removed the make test line.

I'm inclined to keep it

Sure, makes sense.

Linuxbrew has a 2-tier delay

Yeah I can testify, been bitten several times personally. Actually, if memory serves, toward the end of the last year there was a one or two-month period when the maintainer was away and not a single commit was pulled from core... It was the worst.

in case the brew ecosystem doesn't have an ideal response time, impatient users might want to grab the new formula themselves

The ideal response in that scenario is to simply submit a PR; it pains me whenever I see a formula that's not updated in months (and somehow manage to break and block formulae I care about on the CI), and I (as well as maintainers) take that as a strong cue that no one really uses or cares about that formula. Of course I do realize that forking Homebrew and submitting PRs could be too much trouble for folks who don't intend to contribute regularly.

The ideal response in that scenario is to simply submit a PR; it pains me whenever I see a formula that's not updated in months (and somehow manage to break and block formulae I care about on the CI), and I (as well as maintainers) take that as a strong cue that no one really uses or cares about that formula. Of course I do realize that forking Homebrew and submitting PRs could be too much trouble for folks who don't intend to contribute regularly.

That's exactly the part I don't like about brew.
Having a hosting service in which users can upload packages (like PyPI, Hackage or AUR) other than relying on the GitHub's pull request workflow was something I hoped for, at least it would ease the life of package owners without having to do PRs; but that's another story.
Fingers crossed for it all goes well.

Having a hosting service in which users can upload packages (like PyPI, Hackage or AUR) other than relying on the GitHub's pull request workflow was something I hoped for, at least it would ease the life of package owners without having to do PRs; but that's another story.

I contest this with several arguments:

Only the software author and/or maintainer can submit to PyPI, Hackage, AUR or whatever popular package index, whereas anyone can submit any package to Homebrew core as long as it's somewhat notable (e.g., 20 stars on GitHub), and self-submission is actually discouraged, although once accepted maintainers could submit updates if they'd like to (there's no stopping you from having a tap or just a .rb file — those are sort of like PPAs). This community-driven nature is solely responsible for the inclusion  of (I suppose) most packages where the author and/or maintainer won't ever submit themselves. (Can you imagine FSF submitting coreutils to Homebrew? And most smallish Linux-oriented projects?)

Homebrew reviews all commits for dangerous hacks and pitfalls, and tests them for build failures and basic functionality problems against three most recent major OS releases before committing to master, which greatly reduces failures on users' part. Most smallish projects don't have this sort of testing resources (especially not on OS X), and meanwhile, there's no quality check whatsoever on most help-yourself package indices.

Homebrew provide binary packages (called bottles) for most packages on the three most recent major OS releases. This is not possible on many package indices, and even for package indices that support binary distributions, e.g. PyPI, those are usually self-uploaded, few and far between (because most people don't know how or don't bother or technically can't as they don't have access to the target OS) and generally less trustworthy.

Admittedly GitHub's PR workflow isn't the best, but a help-yourself package index is the last thing I would like to see in Homebrew's case.

Correction: My first bullet point might not precisely describe AUR, but still, having a fixed maintainer for each package may not be a great idea, especially not for Homebrew.

Just to clarify, I agree with you on that quality control is best with Homebrew. AUR is nothing like that (as a longterm Arch user: I actually doubt whether many Arch community packages have undergone sufficient quality reviews). So it's more like Debian on the quality side, but anyone has access to GitHub can submit and update packages via PRs.
By discouraging authors submitting their own projects, Homebrew prevents itself from gibberish packages and name squatting, and that is a good thing; but I can also imagine that some kinda useful tools (like this one) would not enter its ecosystem until someone enthusiastic (like you) comes up and is willing to maintain it. Meanwhile, if you authored a package on PyPI, npm, RubyGems, Hackage, you have the full control of it and any user will get immediate access to it - surely there's a risk they must take, but if they trust your code - they already did, and they won't need a 3rd party to prove that for you. (Homebrew doesn't review the actually source code of packages, afaik, so it's still based on some level of trust)
Another point is for the sake of software freedom and/or decentralization. Currently Homebrew totally relies on GitHub (almost every bit of it); self-hosting package archives do not. Of course, you and I are both on GitHub, so it might not matter that much. In the unlikely event of GitHub going down, everyone would lose access to Homebrew (Correct me if I'm wrong: I don't think there's any mirror of it, so you can't use the Homebrew core if you are unable to access GitHub.)

By discouraging authors submitting their own projects, ... but I can also imagine that some kinda useful tools (like this one) would not enter its ecosystem until someone enthusiastic (like you) comes up and is willing to maintain it.

To be fair, discouragement of self-submission applies more to projects that barely qualify (say, a GitHub project with exactly 20 stars); for a project with ~1000 stars (like this one) it's usually fine as long as you don't have a history of abuse.

Meanwhile, if you authored a package on PyPI, npm, RubyGems, Hackage, you have the full control of it and any user will get immediate access to it

That's a fair point. Anyway, there are trade-offs to make.

Homebrew doesn't review the actually source code of packages, afaik, so it's still based on some level of trust

Yep, upstreams are inherently trusted (and in fact, only upstreams are trusted — downstream patches won't be applied unless upstream is notified, and even then they go under strict scrutiny). Homebrew's review and testing are really security screens, they merely ensure there's no (good-faithed) mishandling and no obvious user-facing problems.

software freedom

I'm not sure if by this you're pointing to the fact that GitHub is closed source. In any case, I'm not a bit concerned about this (those GitHub vs GitLab debates are a waste of time IMO). As long as I have access and rights to the code I care about, I'll just pick the most convenient place to host it, and no one can stop me from migrating if the current platform goes rogue.

In the unlikely event of GitHub going down, everyone would lose access to Homebrew

Strictly speaking, yes, but I doubt if that's really an issue. Due to git's decentralized nature, as long as you run brew update reasonably frequently (say, stick it into a daily cron job), you'll always have a relatively up-to-date copy of the entire history (actually, if you use the supplied installation script you'll get a shallow copy, but let's ignore that detail). Since GitHub is down and development can't happen until either GitHub is restored or development is relocated, you copy will remain relatively up-to-date until development resumes. This is not so different from pypi.python.org going down and PyPI enters a read-only mode through mirrors until service is restored.
The more realistic concern for Homebrew is source packages going dark. Homebrew doesn't host source packages, so if a source package is unavailable then you can't install from source. This unfortunately happens far too often with SourceForge, where a large percent of packages are based.

I don't think there's any mirror of it

No official mirrors, that's right. A quick search yields a Chinese mirror of both homebrew.git and homebrew-bottles, updated hourly; I'm sure there are more unofficial mirrors. Of course, I bet homebrew.git can be found on every GitHub decentralization project, say, gittorrent.

By "software freedom" I meant preferably an open source project shouldn't rely on a single proprietary service, that is, if the service goes down or inaccessible for some reason, the community could just create another instance (from the open source code) that functions as well. But ehhhh. We all know that translate-shell has to take advantage of Google's closed source technology for now. So I'll just let that point slide.

Homebrew doesn't host source packages, so if a source package is unavailable then you can't install from source.

True. But hosting the source of every package would be way too much for a GitHub repository (even if with Git LFS support). I don't see how this problem can be resolved, unless Homebrew employs its own hosting service. Hopefully most packages are hosted on GitHub, too, so as long as Homebrew is available, they are available.

if the service goes down or inaccessible for some reason, the community could just create another instance (from the open source code) that functions as well.

Since everyone has a full copy of homebrew.git, that should be pretty easy. (To be fair, the issue tracker may not be easily reproduced in case GitHub goes down; I'm not sure if independent GitHub archival projects have all the data.)

But hosting the source of every package would be way too much for a GitHub repository

Homebrew uses Bintray to host bottles (binary distributions), so source archives at least could be mirrored on Bintray. I don't think it will be a whole lot of work (it will fit into the current publish and download schemes quite easily), but it's probably not worth it, and I'm not passionate about this idea.
In any case I'm not saying source packages occasionally becoming unavailable is a urgent problem. I'm just using it as an example of an actual issue, compared to losing access to GitHub which is almost a non-issue (at least in the short term, and in the long term if anything's wrong solutions could always be figured out).

Hopefully most packages are hosted on GitHub

As I said, quite some packages are unfortunately hosted on SF which has not only gone rogue in a certain sense but also had pretty disappointing uptime in the recent months.

The thread has gone far beyond the scope of this project, so I'll just stop here.
At this point, while we are having some juicy discussion here, the PR on Homebrew did not get a reply (yet). So you see, this model does not always have an ideal response time.

So you see, this model does not always have an ideal response time.

True. From my experience I would say that once accepted, minor updates are almost guaranteed to be merged within a day, but that's still less than ideal.

minor updates are almost guaranteed to be merged within a day,

One day isn't too bad, I suppose. I'd imagine that this timespan could be problematic when a bug-fix release becomes critical (i.e. as some serious security issue exposes), but it's not that much of our concern (for such a tiny tool like trans). We can just wait: )

Finally my PR has been merged. The formula ended up as https://github.com/Homebrew/homebrew/blob/96dadaa/Library/Formula/translate-shell.rb, where we dropped the list of optional dependencies and instead listed the choices in a caveat.
The template could be
class TranslateShell < Formula
  desc "Command-line translator using Google Translate and more"
  homepage "https://www.soimort.org/translate-shell"
  url "https://github.com/soimort/translate-shell/archive/v$Version$.tar.gz"
  sha256 "$sha256$"
  head "https://github.com/soimort/translate-shell.git", :branch => "develop"

  depends_on "fribidi"
  depends_on "gawk"
  depends_on "rlwrap"

  def install
    system "make"
    bin.install "build/trans"
    man1.install "man/trans.1"
  end

  def caveats; <<-EOS.undent
    By default, text-to-speech functionality is provided by OS X's builtin
    `say' command. This functionality may be improved in certain cases by
    installing one of mplayer, mpv, or mpg123, all of which are available
    through `brew install'.
    EOS
  end

  test do
    assert_equal "Hello\n", shell_output("#{bin}/trans -b -s fr -t en bonjour")
  end
end

Not sure if you would like to tweak it a bit for Linuxbrew, or just leave as is. Anyway, build.awk will need to be updated to calculate sha256sum instead of/in addition to sha1sum, which should be very easy.

Good to know. Thanks for contributing this, @zmwangx!

By default, text-to-speech functionality is provided by OS X's builtin
say command. This functionality may be improved in certain cases by
installing one of mplayer, mpv, or mpg123, all of which are available
through `brew install'.

The caveats make sense only to OS X users. say won't be as good as Google's speech engine, and since users can always (simply!) trans something | say if they want, I wouldn't say say is something interesting enough to emphasize here. However, there seems to be no way to implement the "Exactly-one" semantics for optional dependencies (mplayer, mpv, or mpg123) in Homebrew, so I'd keep those caveats as they're.
  assert_equal "Hello\n", shell_output("#{bin}/trans -b -s fr -t en bonjour")

A trivial but subtle issue: When running this line on a development machine, on which users have their own .trans configuration (probably with a theme), the test for equality may fail, because the output may involve some user-defined ANSI color codes. Adding either -no-init or -no-ansi option will fix that. That's not so relevant for running tests on the sandbox of CI, though.
I will update README to reflect the inclusion of trans as an offical Homebrew formula later on.

The caveats make sense only to OS X users.

Correct, that's why I said you might want to modify this for Linuxbrew users.

say won't be as good as Google's speech engine

Yes, and it's limited to certain languages; for instance, every single Chinese character is pronounced "CJK Unified Ideograph"... It could be better in certain ways when it works, though. At least it's more seamless. I have force-window in my mpv.conf to force windows for all audio playback (I want to have OSC at all times), and when trans uses mpv for text-to-speech, I get a series of windows popping up. So each option has potential drawbacks, at least for now.

I wouldn't say say is something interesting enough to emphasize here.

I just wanted to point out that even if you don't install any additional dependency, text-to-speech still works (on OS X).

A trivial but subtle issue

Tests are usually geared towards default install options and default configurations (I once tried to fix findutils's test for --default-names but was rejected), so I'd say it's a non-issue — tests are not designed to work for everyone in every situation. However, since it's easy to fix in this case, I'll incorporate the option in the next update to the formula.

I will update README to reflect the inclusion of trans as an offical Homebrew formula later on.

Done. I'm closing the issue.
Thanks again for taking your time!


Meshes created using exported .csv data (from Mesh Viewer) appear to be missing vertices.

I open the capture. I select a target in Event Browser.
I right click under the 'VS Output' file to export gl_Positions as a .csv file.
I use an application called 'csv2obj' (https://github.com/sergeyreznik/csv2obj) to convert the .csv into an obj file.
When inspecting the mesh in Blender and 3D Viewer, it appears to have holes caused by missing vertices.

Under the Mesh Viewer tab in RD, meshes do not have missing geometry. I would like to export all the meshes in this capture file, but am unsure how to solve this issue. I deleted vertices that had identical positions, which resulted in csv2obj not reading the data at all. In addition to this, I noticed that there is no vertex input data found in the captures.

I would be extremely grateful for any guidance you can give me.
Thank you :)

RenderDoc version: 1.8
Operating System: Windows 10 Home v1909
Graphics API: OpenGL

GPU: NVIDIA RTX 2060
CPU: AMD Ryzen 7, 3750H
RAM: 16GB
Application launched with RenderDoc: RPCS3 v0.010-524

Hi there, your issue has been closed due to not correctly following the issue template. Please read the documentation about filing issues and open a new issue which does follow the issue template. Do not reply to this issue with more information or with a correctly formatted issue, as that will only lead to confusion.
I try to address all github issues and fix bugs quickly, but badly formatted issues or poorly described bug reports especially are a significant drain on project resources. Taking a few minutes to file a good issue makes a huge difference and will get it addressed faster - everybody wins!
In github when you first create a new issue the form is pre-populated with a template which you should read over and follow. As linked above there is documentation going into more detail about what makes a good issue.


NCES not working

There was a bug introduced by the recent changes made by Demir but even when fixing that ( commit 8fe777b367d8efaae3c1cca08fe21532bcdb6448) there are still errors when trying to run NCES. I believe you understand it better @Jean-KOUAGOU, so could you please take a look on it.
These errors could also be because of the recent changes so I highly think we need to create some test cases for NCES so these kind of  things don't happen again in the future. I can do that but since you know the ins and outs of NCES better than me, it would be best that you do that.
To reproduce the error:

checkout general_adjustments branch.
execute the command:

python main.py --model nces --knowledge_base_path NCESData/family/family.owl

This goes without saying but make sure you have downloaded NCESData.

There was a bug introduced by the recent changes made by Demir but even when fixing that ( commit https://github.com/dice-group/Ontolearn/commit/8fe777b367d8efaae3c1cca08fe21532bcdb6448) there are still errors when trying to run NCES.

Could you please eleborate on the relationship between this commit and NCES ?

Very good catch! assertion_path_isfile() should not be returning None if a valid path is passed

Traceback (most recent call last):
  File "main.py", line 109, in <module>
    execute(get_default_arguments())
  File "/home/nkouagou/Documents/Ontolearn/ontolearn/model_adapter.py", line 392, in execute
    report = "Prediction: " + DLSyntaxObjectRenderer().render(hypothesis) + "Quality: " + \
TypeError: can only concatenate str (not "float") to str

It is not related to a package version. The TypeError indicates that one of the items intended to form report is float

I was earlier in the office and happen to meet Jean at the moment he was dealing with this. The error shown to Jean is a different one. In my case the error is related with NCES and not the results printing. We concluded that it must be caused by some package version because I have been install all kinds of libraries and probably the version of a package is overwritten. But that's just an assumption, I will have a better look on this.

So just for the record, after trying it, the script works perfectly fine on Linux which means the issue is related with the operating system. That make sense because the package that throws the error is multiprocessing which works differently depending on the OS. I'm using Windows 11 currently, on which I'm getting the error.

I guess we can close this issue. What do you think @Jean-KOUAGOU ?

Yes we can close it
On Sat, 27 Jan 2024, 12:19 Caglar Demir, @.***> wrote:

I guess we can close this issue. What do you think @Jean-KOUAGOU
https://github.com/Jean-KOUAGOU ?
—
Reply to this email directly, view it on GitHub
https://github.com/dice-group/Ontolearn/issues/322#issuecomment-1913122222,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK4X4EWFBRHPZTOO5FXDQIDYQTPFVAVCNFSM6AAAAABAGBVUP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGEZDEMRSGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Please close this issue


Add addition AWS Regions for DevOps Workshop

Add support for: us-west-2, eu-west-1, eu-central-1, ap-southeast-2

Closes #46


oci: fix runc kill usage

In later versions of runC, runc kill requires the signal parameter
to know what signal needs to be sent.
Signed-off-by: Aleksa Sarai<EMAIL_ADDRESS>

LGTM, @mrunalp PTAL and merge if it's ok for you as well

LGTM

LGTM


Fix deadlock possibility in threaded load of materials

_is_initialized() checks the initialization state of the material, which is only a concern of the thread that is creating or loading it. Therefore, no locking is needed. Splitting the creation or loading of a material among threads is not supported, also. What's more, locking can lead to deadlocks involving the main thread, as it tries to flush the update list, and loader threads. That's the hazard (seen in practice) this PR avoids.
Version of this PR for 4.3 submitted as #100364.

Thanks!


[Bug]: Wrong monitor listed with polybar -m

Checklist

[X] I have read the appropriate section in the contributing guidelines
[X] I believe this issue is a problem with polybar itself and not a misconfiguration on my part
[X] I have searched for other open and closed issues that may have already reported this problem
[X] I have checked the known issues page for this problem.
[X] I have followed the debugging guide to narrow down the problem to a minimal config.

Steps to reproduce

Connect two mirrored monitors
Start polybar with this scriptkillall -q polybar
for m in $(polybar -m | cut -d: -f1); do
  MONITOR=$m polybar --reload bar & disown
done

Minimal config
[bar/bar]
monitor = ${env:MONITOR:}
width = 100%
modules-left = i3

[module/i3]
type = internal/i3
pin-workspaces = true

Polybar log
No response
Expected behavior
The open workspaces are shown on the left side of the bar.
Actual behavior
Bar is empty.
$ polybar -M
eDP-1-1: 1920x1080+0+0
HDMI-1-2: 1920x1200+0+0

$ polybar -m
HDMI-1-2: 1920x1200+0+0

Starting polybar with MONITOR=eDP-1-1 or without, shows the bar as expected.
Window Manager and Version
i3 version 4.17.1 (2019-08-30)
Linux Distribution
Ubuntu 20.04
Polybar version
polybar debian/3.6.2-1-dev

Features: +alsa +curl +i3 +mpd +network(libnl) +pulseaudio +xkeyboard

X extensions: +randr (+monitors) +composite +xkb +xrm +xcursor

Debian package, build flags removed from output for build reproducibility
You can refer to the build logs of your package at:
https://buildd.debian.org/status/package.php?p=polybar

Additional Context / Screenshots
I compiled the Debian packages 3.5.5-1 and 3.6.2-1 for Ubuntu 20.04 by myself, both had the same problem. There is no Ubuntu 20.04 package available and the pre-build ones have newer dependencies.
After a quick look at the source code, I think the culprit is randr_util::get_monitors which removes the mirrored outputs.

Hi, this may be a duplicate of #499. Could you post the output of i3-msg -t get_workspaces  to confirm?
Since you are effectively using a single monitor (two physical monitors, but they display the same area), you can also just remove pin-workspaces = true, it is really only useful if you have monitors side-by-side.

I found a possible workaround. Query i3 for its output names.
i3-msg -t get_outputs | jq '.[] | select(.active).name'

I'm also affected by the same issue and I can confirm that your workaround from the last comment works for me just fine.
Output of i3-msg -t get_workspaces | jq
[   {     "id":<PHONE_NUMBER>4752,     "num": 2,     "name": "2",     "visible": true,     "focused": true,     "rect": {       "x": 1920,       "y": 35,       "width": 1920,       "height": 1045     },     "output": "HDMI-3",     "urgent": false   },   {     "id":<PHONE_NUMBER>1488,     "num": 1,     "name": "1",     "visible": true,     "focused": false,     "rect": {       "x": 0,       "y": 35,       "width": 1920,       "height": 1045     },     "output": "DP-1",     "urgent": false   } ]

what causes this regression?

 But if polybar fails to start it will print an error message. So if you redirect stderr in your script to some log file, you should be able to figure out why polybar didn't start.


fix(package): allow unknown CLI options

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] The changes are appropriately documented (if applicable).
[x] The changes have sufficient test coverage (if applicable).
[x] The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:
Ignores unknown options passed to electron-forge package - enables better upstream/downstream workflow compatibility.
Mirrors the behavior in make: https://github.com/electron-userland/electron-forge/blob/d65f33e73f5afe14597135755aa795edf6a818f2/packages/api/cli/src/electron-forge-make.ts#L21

Besides consistency, what's the use case for this?

@malept The use case in mind is passing command line arguments to a script that dynamically generates the forge config for packaging.

So your forge.config.js reads in process.argv somehow?

This is no longer needed and the branch has become out-of-date. Closing.


Bump fsevents to ^1.0.0

Bump fsevents to ^1.0.0

Not going to merge this for now, but will leave it open. Want to stabilize master (mainly, fix whatever is going on with unwatch), publish a new patch, then will merge this and release with a minor version bump.

I understand. Thanks!


Fix ios missing -lSystem

Change it to a draft request to make sure it is not merged.
Also if the only reason to create the request was to trigger the CI job, it is not needed. CI jobs can be triggered manually on any branch.

That was the main reason, I like having it trigger automatically but I can use manual triggers. @Kryptos-FR


包含webcache 字段被苹果审核拒了，有人遇见过吗

New Issue Checklist

[ ] I have read and understood the CONTRIBUTING guide
[ ] I have read the Documentation
[ ] I have searched for a similar issue in the project and found none

Issue Info

Info
Value

Platform Name
e.g. ios / tvos

Platform Version
e.g. 8.0

SDWebImage Version
e.g. 3.7.6

Integration Method
e.g. carthage / cocoapods / manually

Xcode Version
e.g. Xcode 7.3

Repro rate
e.g. all the time (100%) / sometimes x% / only once

Repro with our demo prj
e.g. does it happen with our demo project?

Demo project link
e.g. link to a demo project that highlights the issue

Issue Description and Steps
Please fill in the detailed description of the issue (full output of any stack trace, compiler error, ...) and the steps to reproduce the issue.

@Zhangyunjiang123 please fill in the info required by the issue template. English would be nice :) even though I think @dreampiggy speaks Chinese.

I've solved this problem! But thank you very much for your reply.
| |
张云江
<EMAIL_ADDRESS>|
签名由 网易邮箱大师 定制
在2018年04月24日 21:17，Bogdan Poplauschi 写道：
@Zhangyunjiang123 please fill in the info required by the issue template. English would be nice :) even though I think @dreampiggy speaks Chinese.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

😅 So...I just close this issue.
I can translate this for the non-Chinese speaker, this issue is about that:

The application which binary contains WebCache was rejected by Apple during App Store submitting.

But however, our company's application using SDWebImage very well. So I don't know anything about this. However, since it's soleved, just close it.


Project failed to compile because of lint errors

[X ] I've read, understood, and done my best to follow the Contributing guidelines before opening this issue.
What did you do?
Run carthage update on a projet referencing SwifterSwift
What did you expect to happen?
Project should compile
What happened instead?
Project failed to compile because of lint errors in the macOS test cases
I open the project checked-out by Carthage and failed to compile it because of lint related errors:
Variable name should only contain alphanumeric characters: e.g __allTests__CalendarExtensionTests
Variable name should only contain alphanumeric characters: '__allTests__DateExtensionsTests' (identifier_name)
etc...
33 errors in total, all in the test package
I'm not terribly familiar with swiftlint, but I understand that the .yml that is at the root of the checked-out project takes precedence over any other configuration so I don't really see how to make it compile out of the box because those lint parameters from the project will be used.
SwifterSwift Environment

SwifterSwift version: 5.2
Xcode version: 11.2
macOS version running Xcode: 10.14
Swift version: 5
Platform(s) running SwifterSwift: MacOS

Demo Project

Thanks for reporting, that's weird because all those files were removed in #808 ... So if you are using the latest version it shouldn't be a problem, anyways we can investigate that :)

hello,
Thanks for responding...and finding the solution.
For some reason, I had to delete the Carthage/ folder and redo the carthage update --platform macOS  --no-use-binaries to make it work. I was using 5.1 before the first attempt, and for some reason, the Carthage checkout was not reflecting the change you mention.
I should have tried to cleanup Carthage/ before asking but I never had to do it before.
Thanks anyway.
Matthieu

Right, maybe it is some Carthage caching/update problem, not really sure ... but glad you make it work :)
Closing 👍


Weird error with optional properties when interfaces are nested

Flow complains when optional object property is properly set to a string. If it's not set at all it works fine.
Please see the code example: https://flow.org/try/#0PTAEAEDMBsHsHcBQiCWBbADrATgF1AEoCmAhgMb6TaxqgBE2pFdA3MigHa5HaTlGgyAV2yMuAVQDOPACoBPDAIDeiUKA4k0RAFyhJubJwDmAGlWgh07AH10JI0QD8u-YY6nEAX3ZcefMgJksByQKEbyiqAqapY8usKiRBJWEURm3oi4CgIACtQYkqAAvFGqQSFh8cGh4dmgXsjl+qBocgDC1cWlMVa60WrqmjqgAOQA6gAWJNwAbjwjZgMWVrZo9sMjAEYk2AB0AFYYRgvm3t5q5pdN+ABisLBdABRK5TWeoLp5sAUAlMUAfKBHuYADwAExQM3+5gGNwA8nCBqDgBCoYgfmxENdQABBDAYJ5-IqA-pqRi4EQcIEwgYASBBdwerzCRSUrQ6IXewGhSwxDUQRAAHlg8KAwUQ+EJoPg8RgWEA
Using type instead of interfaces solves the problem, but I don't know how to export the rules then?

Even smaller example:
'use strict'
// @flow

interface RouteConfig {
  redirect?: string
}

interface RouterOptions {
  routes: RouteConfig
}

const router: RouterOptions = {
  routes: {
    redirect: 'projects'
  }
}
export default router

Ran into this problem as well with latest Flow (v0.101)

Just posting her to update that this is still happening for me, not only with optional properties though.
Cannot assign object literal to theme because inexact TypographyDescription [1] is incompatible with exact object
literal [2] in property typography.headingThree. [incompatible-exact]

flow-bin version:  0.145.0
I'm using create-react-app.
Example:

Successful workarounds:

Changing TypographyDescription from an interface to a type alias

Failed workarounds:

Making fontWeight required

The problem seems to be fixed a long time ago


Where is the TAR model checkpoints?

I remember you released the Llama3 checkpoints after TAR in Huggingface a few days ago (https://huggingface.co/lapisrocks/Llama-3-8B-Instruct-TAR-Bio) , but right now it has disappeared. Could you release them again?

I saw these checkpoints are on https://huggingface.co/lapisrocks/Llama-3-8B-Instruct-TAR-Bio again. However, when I download it and prompt it by read-teaming, I found the model seems to behave improperly. Is that the model checkpoint that is tamper resistant?


bug: this plugin makes the quitting of my neovim very slow

Did you check docs and existing issues?

[X] I have read all the persistence.nvim docs
[X] I have searched the existing issues of persistence.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
NVIM v0.9.5
Operating system/version
MacOS Version 14.3.1
Describe the bug
My neovim is quitting very slowly when I have at least 3 new windows and/or tabs
Steps To Reproduce
Open neovim
Open 2 splitted windows
Open a new tab
Quit
Expected Behavior
Quit almost instantly
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  "folke/persistence.nvim",
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

The issue is not about persistence.nvim, sorry for the inconvenience.

@cr4ftx , what was causing the delay for you? I'm seeing this right now, nvim hanging around 2-4s after quit command has been issued, with an incompletely redrawn screen. I haven't yet traced it down, but so far disabling persistence.nvim completely makes the problem go away :[

It was not persistence.nvim at all, it was cause by another plugin called nvim-tree, but only when you open it once, some folders are too heavy like node_modules.
I've just added this to my nvim-tree setup config :
      filesystem_watchers = {
        enable = true,
        debounce_delay = 50,
        ignore_dirs = { "node_modules", ".git", "build", "dist" },
      },


Connect admin database to endpoint

/cib connect-admin-database

Branch 34-connect-admin-database created!


Can "labels" also be continuous variables?

Thanks for this awesome package. As far as I could read them, both the package docs as well as the related research papers mostly speak of "labels" for X and Y. However, some of the examples also use continuous variables. Will this package work also for continous variables for both X, Y, Yhat, X_unlabeled etc.?

Hey Dominik! Nice to meet you! And thanks :)
X and X_unlabeled can be continuous in any example.
Y can be continuous in any example except for logistic regression, and Yhat can always be continuous.
Does this help? Thanks!

Excellent, thanks!


QuerySpecification post processors

Currently:
QuerySpecification supports map and transform and only in that order.
After:
new QuerySpecification(statement).transform(type).map(fn).reduce(fn)

Post processors run in the order they're added
Add reduce, filter, etc from Array.

Implemented in 2.0.17


[BUG] Compile fails for 6.0.1 on macOS / Darwin using Rust 1.57.0

When running a cargo install macchina on macOS 12.1 with Rust 1.57.0:
   Compiling color-to-tui v0.1.3
error[E0432]: unresolved import `libmacchina::dirs`
 --> /Users/dsully/.cargo/registry/src/github.com-1ecc6299db9ec823/macchina-6.0.1/src/config.rs:3:5
  |
3 | use libmacchina::dirs as _dirs;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `dirs` in the root

error[E0425]: cannot find function `list_dir_entries` in `libmacchina::extra`
   --> /Users/dsully/.cargo/registry/src/github.com-1ecc6299db9ec823/macchina-6.0.1/src/theme/base.rs:211:43
    |
211 |         let entries = libmacchina::extra::list_dir_entries(&dir.join("macchina/themes"));
    |                                           ^^^^^^^^^^^^^^^^ not found in `libmacchina::extra`

error[E0603]: module `extra` is private
   --> /Users/dsully/.cargo/registry/src/github.com-1ecc6299db9ec823/macchina-6.0.1/src/theme/base.rs:211:36
    |
211 |         let entries = libmacchina::extra::list_dir_entries(&dir.join("macchina/themes"));
    |                                    ^^^^^ private module
    |
note: the module `extra` is defined here
   --> /Users/dsully/.cargo/registry/src/github.com-1ecc6299db9ec823/libmacchina-4.1.0/src/lib.rs:28:9
    |
28  |         mod extra;
    |         ^^^^^^^^^^

error[E0603]: module `extra` is private
   --> /Users/dsully/.cargo/registry/src/github.com-1ecc6299db9ec823/macchina-6.0.1/src/theme/base.rs:213:45
    |
213 |             if let Some(ext) = libmacchina::extra::path_extension(x) {
    |                                             ^^^^^ private module
    |
note: the module `extra` is defined here
   --> /Users/dsully/.cargo/registry/src/github.com-1ecc6299db9ec823/libmacchina-4.1.0/src/lib.rs:28:9
    |
28  |         mod extra;
    |         ^^^^^^^^^^

Some errors have detailed explanations: E0425, E0432, E0603.
For more information about an error, try `rustc --explain E0425`.
error: failed to compile `macchina v6.0.1`, intermediate artifacts can be found at `/var/folders/5j/mr0j9xws5pl4yvmm38tt8lfh0003dm/T/cargo-installojdyED`

Caused by:
  could not compile `macchina` due to 4 previous errors

Updated 0 packages.
Failed to update macchina.

Hi!
I have no idea why it's not compiling, but I know this is the second time that we publish a working release only to get a report of build errors a little while later. If you've got Homebrew installed, can you please install it through there, and report back?

@uttarayan21 Any clue why is cargo behaving as if libmacchina's version is set to "4" and not the exact version that is "4.0.2"? This isn't the first time either.

IIRC bug fix releases or 0.0.x are considered non breaking changes by rust so the dependencies aren't pinned to the exact version.

Well I guess I'm not following semver as much as I believe I do, but I still think it's unintuitive that it does this by default.

I'm prepping a fix very soon, I'll try my best not to have this happen again.

I'm prepping a fix very soon, I'll try my best not to have this happen again.

A new release has just been published.


ERROR: error reading file sanity.json

After @ndmitchell 's patch to remove the embedded js-jquery and js-flot libraries, the tests fail for me (on one of two machines) with:
$ dist/build/sanity/sanity
benchmarking fib/fib 10
time                 2.858 μs   (2.854 μs .. 2.863 μs)
                     1.000 R²   (1.000 R² .. 1.000 R²)
mean                 2.861 μs   (2.856 μs .. 2.867 μs)
std dev              17.83 ns   (13.84 ns .. 23.61 ns)

benchmarking fib/fib 22
time                 2.034 ms   (2.028 ms .. 2.040 ms)
                     1.000 R²   (1.000 R² .. 1.000 R²)
mean                 2.050 ms   (2.045 ms .. 2.060 ms)
std dev              23.57 μs   (17.58 μs .. 35.98 μs)

benchmarking length . filter/string
time                 3.206 μs   (3.203 μs .. 3.210 μs)
                     1.000 R²   (1.000 R² .. 1.000 R²)
mean                 3.207 μs   (3.204 μs .. 3.211 μs)
std dev              12.23 ns   (9.303 ns .. 16.52 ns)

benchmarking length . filter/bytestring
time                 892.5 ns   (890.2 ns .. 896.1 ns)
                     1.000 R²   (1.000 R² .. 1.000 R²)
mean                 897.3 ns   (894.3 ns .. 902.2 ns)
std dev              13.40 ns   (7.963 ns .. 22.55 ns)
variance introduced by outliers: 15% (moderately inflated)

sanity: [Failed]
ERROR: error reading file sanity.json:
  "Error in $: endOfInput"

The two machines are pretty much identical, running Debian Testing on x86_64.

When you say pretty much identical, are there any Haskell library version differences between the two?  That would be a good hint at what might have gone wrong.

I did a cabal update and rebuilt on the machine that was working and now it fails like the other machine.

I can't reproduce. @erikd - can you try using something like https://www.stackage.org/nightly-2016-06-10/cabal.config which pins down absolutely all version ranges and see what happens? The Travis test suite seemingly passed with stack nightly.

I just did a completely fresh Windows VM, GHC 8.0.1, update, test and it worked perfectly.

I grabbed that cabal.config file, removed the criterion entry so I could build criterion's git HEAD and that failed too, just like before.

I just ran using stack nightly, on Travis, so a clean install plus Linux and the same versions as you, and it worked: https://travis-ci.org/ndmitchell/criterion/jobs/136701986.
I guess someone who really uses Linux for real should probably give it a go - my simulations might be just a little too weird.
@erikd Could you upload the sanity.json that results from your test? Mine is at https://gist.github.com/ndmitchell/2c5e4403361943e9812243a6fec3df24

Mine is at https://gist.github.com/erikd/a8039725d22e96a484e41d88e3370d90
One thing iI notice is that yours is a s single line while mine is on three lines.

Yours seems to have inserted a lot more whitespace, e.g. it starts [ "criterio" while mine starts ["criterio". Furthermore, while mine is valid JSON, yours, when pasted into Chrome, gives Uncaught SyntaxError: Unexpected token ].
I increasingly suspect this is nothing to do with my patch, merely version number differences that happened to show up simultaneously. Can you try a commit before my changes went in?

You are right. I checked out commit 0f59bcb7 (from 2014??) and that is indeed fine. I suspect this may be an issue with the JS libraries shipped with Debian.

The Debian versions of the relevant JS libraries are as follows:
$ dpkg -l | grep jquery
ii  libjs-jquery      1.12.3-1       all  JavaScript library for dynamic web applications
ii  libjs-jquery-flot 0.8.3+dfsg-1   all  plotting library for jQuery
ii  libjs-jquery-ui   1.10.1+dfsg-1  all  JavaScript UI library for dynamic web applications

I also tried reverting commits 80f78aaa97acc9e123 and 8995296ed52527ce4c7 and that also solves the problem.
I suspect the version of libjs-jquery (1.12.3) is too old. The version of the file you  removed in commit 80f78aaa97acc9e123fa8 was 2.1.1.

jquery 1.12.3 is actually newer than 2.1.1 - it's equivalent to 2.2.3. The 1.10 vs 2.0 difference indicates whether the jquery maintains IE6-8 compatibility, but otherwise they are equivalent. There are lots of weird things here:

Doesn't happen on my Linux or Windows tests.
The Haskell test, which writes a JSON output file, is impacted by jQuery stuff. I can't see why that code is even invoked. I can't even see how it could be invoked, without a Javascript interpreter.
You end up with invalid JSON. That's just weird. Tracing the code path it goes nowhere near the jquery files at all - it just slaps out as JSON encoded value.

OK, I can now reproduce it. Firstly, it's non-deterministic - I can currently get it happening about every other run. Secondly, it has nothing to do with js-jquery - completely removing those libraries still results in corruption. Current culprit is templating library or text builder.

OK, I can now reproduce it.

Yay!

Firstly, it's non-deterministic

I was suspecting that, but hadn't managed to confirm it yet.

OK, I think I've tracked it down... Should have it confirmed in 15 minutes or so.

Patch in #108. js-jquery was completely irrelevant, as were package versions. What was relevant was running the test multiple times, first producing a "longish" file then a "shortish" file. Pretty much guaranteed if you ran the test 5 times.
I had visions of buffer overflows, but nothing to do with that at all.

:+1: @ndmitchell !!!

Closing this. Fixed in #107 .


Got even more tests working

At this point, everything that's commented out is that way because it's testing stuff that just works differently in this package, or that I don't think is worth adding.
At this point, I'd be OK with putting out a first release if we can prove that it works for actual human beings on Windows, and not just in CI. The log statements should get cleaned up, of course, though I'll probably keep some in as console.debugs that log only when Atom is in dev mode.
Some things in here worth mentioning:

I’m skipping the test that ensures that a file that’s ignored in package.json will nonetheless be linted if it’s in the root and there’s also an .eslintignore file that doesn’t ignore it. I spent 90 minutes wading through ESLint internals trying and failing to figure out how the Rube Goldberg machine that determines its configuration was doing the expected thing from the command line, but not from the equivalent ESLint#lintText command. Finally, out of desperation, I switched our call from lintText to lintFiles, and suddenly it passed.
It’s always possible that I’ve just overlooked the world’s simplest typo somewhere in worker.js. But failing that, there’s no earthly reason why ESLint shouldn’t treat those paths exactly the same (provided I pass filePath when I call ESLint#lintText — which I do). Also, if someone is relying on this behavior, I’ll happily tell them to go use VSCode instead.

Most of what I thought I learned about cwd was wrong. If you set it to a file’s directory, it’ll happily traverse upward and assemble config options from a bunch of .eslintrcs, but it’ll only consume one .eslintignore, and it has to live in cwd. So I replicated the logic from getRelativePath, but with a tweak.
I think it’s fine to start at the file to be linted and then stop at the first .eslintignore you find, and treat that as cwd. But as far as I can tell, if you open a file in a project that has ESLint but is missing an .eslintignore file altogether, linter-eslint will happily keep traversing upward in search of one — all the way to the volume root if need be — before giving up and using the project path.
In trying to use the closest .eslintignore to the file, we’re already doing more than the eslint binary does, so there’s no specific behavior that we need to replicate here. I think it’s weird to try to lint a file inside a project only to discover that it won’t get linted because it matches an ignore pattern defined by a file that’s not even in the project. So I made the opinionated decision to stop at the project root.
I think that this is a good idea. The only people who I think could possibly have relied on the previous behavior are people who work in a monorepo and treat each package as a separate project but also delegate their .eslintignore-ing to a file at the repo root… and I’ll bet there are five people on Earth who fit that description, and four of them probably use WebStorm.

I changed one test fixture because it was relying on the no-semicolon rule that was present in linter-eslint that I have selfishly changed into a rule that requires semicolons in linter-eslint-node.

I got rid of the “Lint HTML Files” option and replaced it with extra description text for the “Scopes” option. Also got rid of “Path to local node_modules”; I can add this back if anyone requests it, but I doubt they will. Added a “Use cache” advanced option that bypasses the ESLint instance cache for diagnostic purposes.

My decision to go with a small post-fix-job message — outcome of the job in the message field, and no description field at all — is complicating the tests, which expect a certain fixed string to be the “subject” of the notification. If the fix job doesn’t fix the expected number of things, the message won’t be what we expect, and the notification promise will timeout instead of failing quickly. I still like the more compact success message, so I might try to have it both ways here by putting something predictable at the front of the message if we’re in spec mode.

The other thing that occurred to me: we have no tests for the node-resolution logic or for the ability to specify per-project options via .linter-eslint. I'll start writing tests for the latter tonight, but the former feels hard.
If someone wants to contribute to this package in the future, I don't think we should make them download various specific versions of node into known locations on their drive just so we can run some specs. This feels like a CI task. Is it possible to define specs that only run on CI?

I knew those new config specs were too good to be true; they felt too easy to write. I have no idea why the “if we rename .linter-eslint” test is failing in the way that it is; that promise should reject after five seconds, not 60.

The test runner is setup to give a ci a little bit more time. The default timeout for ci is 60 seconds.

We can use environment variables to only run tests in certain environments.

OK, it turns out to be a problem with async tests in general. I can't get any sort of async strategy to work, including either of these simple test cases:
'use babel';

function wait (ms) {
  return new Promise((resolve) => {
    setTimeout(resolve, ms);
  });
}

describe('Test file', () => {
  it('does something with setTimeout', (done) => {
    setTimeout(() => {
      expect(typeof 1).toBe('number');
      done();
    }, 100);
  });

  it('does something with async/await', async () => {
    await wait(1000);
    expect(typeof 1).toBe('number');
  });
});

They both timeout. Experiencing this on both Windows and macOS, so there's something happening in the Jasmine internals that I don't understand, or perhaps in the transpilation. This despite the fact that all the existing tests that use await are working.
I wonder if it's got to do with the clock being mocked? If I do jasmine.clock().install() in a test, it errors with Error: Jasmine Clock was unable to install over custom global timer functions. Is the clock already installed?

OK, I was ready to give up on this several times, but I've got this test passing locally now on Windows, at least via GUI.

The core issue on Windows is that when we set the project path, Atom starts an async job to set up a watcher on that path. We need to wait for that watcher to be ready before proceeding, or else it won't realize that we've renamed the file.
Jasmine does indeed wrap setTimeout with something; preserving the unwrapped version and exporting it from the helpers file seems to do the trick. I was confused about 5-seconds-versus-60 because my untilConfigChanges function explicitly waits for 5000 ms before giving up, regardless of environment, but that wasn't doing anything because it was calling the wrapped version of setTimeout. Should work just fine now.

And as I write this I notice that CI is still failing on Windows, but at least it's passing on Linux. My woes continue.

That one failing test on Windows passes for me locally, so I don't know what's going on. It seems weird for such a simple test to be flaky.

It doesn't seem to be just windows. It also seems like different tests are failing. I'm thinking we need to make the tests more granular so we aren't relying on atom as much.

The tests that claim to be failing are direct equivalents of tests in linter-eslint. I suspect the timeout errors are triggered by config-spec.js tests and just not getting matched up correctly, because I believe all those tests were passing before I started writing config tests.
But now that I've skipped the one test that was giving me trouble, it's still having sporadic timeout issues, so I'll try a couple more things. Having to diagnose test failures in CI that I can't reproduce on my machine might be my least favorite task in all of computer science.

OK, my nightmare is approaching an end. And yours, too, if you've been getting all these CI failure emails as well.
The new failures in linter-eslint-node-spec.js were caused by a Config.onConfigDidChange handler firing too early and making us think that nodeBin had changed when it hadn't. That caused the worker script to get killed and re-initialized with the “new” version of Node, which somehow was consistently happening inside of one particular test on Windows CI, and another particular test on Ubuntu CI. That caused a linting job to get orphaned and timeout.
Knowing now that those failures weren’t just weird side effects of config-spec.js specs, I took another look at those. Any failure that happened consistently in Windows CI is something that I could reproduce about one time out of ten locally. So, after a bunch of trial and error, I managed to isolate the flakiness to a race condition just after file modifications. await editor.save() triggers a file change modification, and those are not guaranteed to be synchronous. So whenever we save a file, or rename it, or something, we’ve got to cede control to be sure that those callbacks have run before we try to assert stuff.
In my experiments on my Windows machine, even await wait(0) was enough to get these tests passing consistently except maybe one time in a hundred. I made them all await wait(1000) just for safety. That got everything passing on all platforms.
I hate waiting for fixed amounts of time, and I’d be glad to find a different way to know when it’s safe for those tests to proceed, but the most obvious way to do that would be to use the same APIs that are part of what I’m testing in the first place. That feels icky, but if I have to revisit these tests, I will live with that icky feeling.
And, yes, it’s always an option to test Config in isolation. But the integration points between the main module and Config are important, too, because they’re the parts that save you from having to reload your project window whenever you make a change to your config. If these tests prove to be flaky no matter what I do, I'll rewrite them to call Config.rescan() and Config.update() manually.


Document chat controller

The requests are already autogenerated, we have to generate response body for the controller.
ref: https://docs.nestjs.com/openapi/operations

Hey @Abhishek-kumar09, I am new to edu-server and want to work on this issue, could you tell me how to get started with this issue?