Mod Request: Thaumic Tinkerer

Hey, I want to suggest that you add the mod Thaumic Tinkerer I know a lot of people (Including me) on a server that upset because it's not in the pack so that's why I'm asking you to add it.

I'm Sorry. I will mostly be doing bug fixes for this pack and trying to focus more of my time toward the newer 1.10.2 Abridged pack. that will hopefully turn into the newer 1.11 Unabridged pack. Mod additions are now closed for unabridged.


Handle extra object literal properties (Part II)

This is part of sweep of work to address https://github.com/Microsoft/TypeScript/issues/4081.
See Part I: #5151.

:+1: so many bugs fixed

:+1:


Vera/ENG-440 Remove .unwraps and .expects from WASM calls

Description

Removed unwraps and excepts from the banyan-cli wasm submodule in all functions that already return a Result.
wrote custom error mapping helper function to reduce code clutter.
converted existing calls to use this helper.

Link to issue
https://linear.app/banyan/issue/ENG-440/remove-unwraps-and-expects-from-wasm-calls
Type of change

[x] Bug fix (non-breaking change that fixes an issue)
[x] Refactor (non-breaking change that updates existing functionality)

Yay! Better error handling


Add OctoAI LLM endpoint wrapper and embedding endpoint wrapper

This pull request introduces support for OctoAI's Compute Service embedding endpoints and large language model endpoints into the LangChain project. The changes encompass additions to various files to accommodate OctoAI's API integration.
Details of the changes:
langchain/init.py and langchain/llms/init.py: Updates to these initialization files allow OctoAI's services to be utilized in the LangChain's workflow. The changes add 'OctoAIEndpoint' as an additional language model option.
langchain/embeddings/octoai_embeddings.py: This new file creates a wrapper for OctoAI embedding endpoints. This addition allows users to compute embeddings of documents and queries using OctoAI's service.
langchain/llms/octoai_endpoint.py: This file introduces a new class, 'OctoAIEndpoint', which serves as a wrapper for OctoAI's large language model endpoints. It includes methods for interacting with OctoAI's API and getting responses from it.
tests/integration_tests/embeddings/test_octoai_embeddings.py: This file introduces tests to ensure the correct functioning of the OctoAI embedding endpoint using the Instructor-Large model endpoint. It includes tests for document and query embedding functionalities.
tests/integration_tests/llms/test_octoai_endpoint.py: This file includes tests for OctoAI's LLM wrapper for MPT-7B model endpoint. It covers various scenarios including valid API calls, calls that result in errors, and the saving/loading of language model endpoints.
docs/modules/models/llms/integrations/octoai.ipynb: This notebook shows how to use LangChain to interact with OctoAI LLM endpoints
Please note that to use the newly added OctoAI's services, users should have the octoai python package installed pip install octoai, and the environment variables OCTOAI_API_TOKEN set with the API token and ENDPOINT_URL set with endpoint_url. The API token and endpoint URL can be obtained by cloning a template and creating an API token at https://octoai.cloud.
Thanks in advance for your review!
@hwchase17 @agola11

I fixed the lint errors but Vercel seems to still be failing. I can't see what the error is with Vercel. Can you please let me know what needs to be fixed?

conflicts resolved. lint and test errors fixed. Vercel deployment now succeeding.


Add support for custom protocols with the allowCustomProtocols option

We have been having problems with app protocols like "my.app://path/to/something".
A quick looks shows that valid protocols can have periods, hyphens and pluses in them and remain valid.
This PR keeps existing behavior unless the allowCustomProtocols option is provided, in which case more complex protocols aren't mangled.
Changes at a glance
Before:
normalizeUrl('my.mobile.app://sindresorhus.com');
//=> 'http://my.mobile.app/sindresorhus.com' ???

After:
normalizeUrl('my.mobile.app://sindresorhus.com', {
	allowCustomProtocols: true
});
//=> 'my.mobile.app://sindresorhus.com'

As you can see the before example doesn't make much sense. I feel like this would probably be a sane default to have enabled, but I don't want to break compatibility, so I'll leave that up to you.

but I don't want to break compatibility

What kind of compatibility would it break? I would like to make it on by default. Just trying to think about the repercussions.

Thinking out loud, do we even need an option for this? It kinda feels like a bug-fix. The existing behavior is clearly incorrect.
It's correctly handled by new URL, for example:
new URL('custom+with+plusses://sindresorhus.com')
//=> URL {origin: "null", protocol: "custom+with+plusses:", username: "", password: "", host: "", …}

You're right, there probably aren't any compatibility changes, I'm always just a bit cautious when I'm adding a new use case and I'm not the author, so there may be things I've missed.
I'll make this the default behavior then 👍

There's one possible ambiguity here. See: https://github.com/sindresorhus/prepend-http/issues/4 Not sure how to handle that. Either disallow auth or require the custom protocol to use //. Thoughts?

I don't think this library handles auth in the url does it? Or at least currently it strips it out.
eg:
<EMAIL_ADDRESS>// -> 'https://sindresorhus.com'

This PR shouldn't affect that, since like you say, it uses // as the delimiter.

I don't think this library handles auth in the url does it? Or at least currently it strips it out.

You're right. Then that's a non-issue.

Shall we keep // as the delimiter and just mention that custom protocols need to use it?

Not sure what you're asking, but we should preserve it if it's there. We cannot normalize it away as it changes the semantics.

Do you want to keep the error on the view-source protocol?

I think we could remove it.

Bump :)

Closing for lack of response. Happy to reopen if you ever get to this.
https://github.com/sindresorhus/normalize-url/issues/152


Phar package must include text file (required by minify)

Warning: file(phar:///usr/local/bin/phpoole/vendor/matthiasmullie/minify/src/../data/js/keywords_reserved.txt): failed to open stream: phar error: "vendor/matthiasmullie/minify/data/js/keywords_reserved.txt" is not a file in phar "/usr/local/bin/phpoole" in phar:///usr/local/bin/phpoole/vendor/matthiasmullie/minify/src/JS.php on line 122

Fixed with #62.


ci(autoupdate): enable workflow trigger on pull request

When using the default github.token, the created/updated pull-request doesn't run associated workflows due to the restriction of the github.token.
We need to use a personal access token override this restriction.

:tada: This PR is included in version 1.17.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


No Longer Able to Debug in WSL

Type: Bug
Prior to this last update I was able to run my debugger and everything would work when debugging my node app in WSL.
This is broken on two independent machines with two different projects. It was working before.
The log is saying that it can't find a module (the main.js file) that it used to be able to see before this last update.

What debugger are you using?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Atom always opens the chrome developer tools on startup.

As you can see down below, atom has opened the Chrome Developer Tools on startup and has caused atom to display a white screen. When I close the Developer Tools pane, the white screen still remains.
While I'm not confused as to why the Developer Tools may open within atom, I am confused as to why this pane would open every time at startup. Take a look;

Thanks. :)

Looks like there's an error on startup - can you click the error icon in the DevTools and paste the error you see here? Also, does this still happen if you quit Atom completely and then reopen it in safe mode? (atom --safe)

It happens in safe mode

A non-responding atom, that is. Let me get you that screen-shot. :)

http://pastebin.com/Mv2NiWDM
This is the error message.

Have you figured out what the problem is?

It cant find git-utils. When did you download atom? How did you install it?

Did this happen immediately after install? After some other event? Maybe after an update?

This happened immediately after install. I had not installed anything before, after, or while I had installed atom.

I’m having the same problem, however with a different error-message:

SyntaxError: Unexpected end of input
    at Object.parse (native)
    at FileSystemBlobStore.load (/Applications/Atom.app/Contents/Resources/app.asar/src/file-system-blob-store.js:36:31)
    at Function.load (/Applications/Atom.app/Contents/Resources/app.asar/src/file-system-blob-store.js:10:14)
    at window.onload (file:///Applications/Atom.app/Contents/Resources/app.asar/static/index.js:18:39)

It happend after Atom crashed for no obvious reason. I reinstalled Atom, but it doesn’t help.

Hi @z3to, for your issue, please delete the ~/.atom/blob-store folder.

Thanks, @50Wliu! That indeed solved the issue for me.

Happened for me too. @50Wliu 's solution fixed it. But why did it happen in the first place? I guess due to a corrupted update?

I guess due to a corrupted update?

Kind of.  1.3.0 introduced a new cache to help speed up startup times, but there was a rare edge case when two very similar functions would get cached, and V8 couldn't tell the difference between the two, leading to this error.  I believe this has been fixed in 1.3.2, so you shouldn't experience this again.

@50Wliu Cool. Thanks for letting me know.

Thanks, @50Wliu!

Just had this happen too, as above @50Wliu's solution fixed it, thanks.

I have the same problem but many other errors. Anybody have solution?

Looks like one of your style files are corrupted.  An easy way to fix this is to remove ~/.atom/styles.less and ~/.atom/packages/, though that will remove your custom styles and all your installed packages.

I fixed error restoring a backup of yesterday. Idk, i not open the program since last week. Anyway, thanks.

After last update I'm also getting the dev tools on open. It seems like one on=f the module is missing: Error: Cannot find module '../build/Debug/nodegit.node'
at Module._resolveFilename (module.js:336:15)
at Function.Module._resolveFilename (/opt/atom/resources/app.asar/src/module-cache.js:383:52)
at Function.Module._load (module.js:286:25)
at Module.require (module.js:365:17)
at require (/opt/atom/resources/app.asar/src/native-compile-cache.js:50:27)
at Object. (/opt/atom/resources/app.asar/node_modules/nodegit/lib/nodegit.js:17:12)
at Module._compile (/opt/atom/resources/app.asar/src/native-compile-cache.js:103:30)
at Object.defineProperty.value [as .js] (/opt/atom/resources/app.asar/src/compile-cache.js:208:21)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (/opt/atom/resources/app.asar/src/native-compile-cache.js:50:27)
at Object. (/opt/atom/resources/app.asar/src/git-repository-async.js:25:16)
at Module._compile (/opt/atom/resources/app.asar/src/native-compile-cache.js:103:30)
at Object.defineProperty.value [as .js] (/opt/atom/resources/app.asar/src/compile-cache.js:208:21)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (/opt/atom/resources/app.asar/src/native-compile-cache.js:50:27)
at Object. (/opt/atom/resources/app.asar/src/git-repository.js:12:24)
at Object. (/opt/atom/resources/app.asar/src/git-repository.js:428:4)
at Module._compile (/opt/atom/resources/app.asar/src/native-compile-cache.js:103:30)
at Object.defineProperty.value [as .js] (/opt/atom/resources/app.asar/src/compile-cache.js:208:21)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (/opt/atom/resources/app.asar/src/native-compile-cache.js:50:27)
at Object. (/opt/atom/resources/app.asar/src/git-repository-provider.js:8:19)
at Object. (/opt/atom/resources/app.asar/src/git-repository-provider.js:83:4)
at Module._compile (/opt/atom/resources/app.asar/src/native-compile-cache.js:103:30)`
The problem is that even if I remove it with --purge and reinstall it again, I get the same problem.
I thought it's related to some saved config so I removed ~/.atom/ folder, but with no success, atom still loading dev tools on start.
Would be thankful for some suggestion to fix this.
Thank you

@dan-conachi Your issue is covered by #10819.

There doesn't appear to be anything left unresolved in this issue.
If you get are getting this problem check the error by hitting the red circle with white x) and then check to see if there is an issue for that specific error text.

Upgrading to atom 1.8.0-beta1 has fixed the issue for me. Working flawlessly now :)

Still happening:
index.js:62 TypeError: Cannot read property 'PWD' of undefined
    at updateProcessEnv (update-process-env.js:9)
    at module.exports (/usr/share/atom/resources/app.asar/src/initialize-application-window.js:11)
    at setupWindow (index.js:87)
    at window.onload (index.js:41)handleSetupError @ index.js:62

@airtonix Sorry to hear you're running into that! You can track that one at https://github.com/atom/atom/issues/12328
Since this is a very broad, non-actionable issue, I'm going to lock this to keep noise levels down. If anyone runs into a specific uncaught exception that causes the DevTools to pop up, take a look at the Contributing guide first, then feel free to open a new issue.


C++ Inference capability

C++ inference capability will allow for easy backward integration with other Kaldi-2009-2019 code, and create a softer transition pathway.

you mean type inference? Not sure how that would work, i.e. how it would
make things easier
y.
On Wed, Sep 23, 2020 at 7:57 PM Nagendra Goel<EMAIL_ADDRESS>wrote:

C++ inference capability will allow for easy backward integration with
other Kaldi-2009-2019 code, and create a softer transition pathway.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jtrmal/kaldi2020/issues/9, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACUKYX6HOZJ5TYP4RKQEYTLSHIZKFANCNFSM4RXKXTHQ
.

I think the question is about the run/decode time deployment with a C++ interface. Yes, there will certainly be a C++ interface underneath the Python layer. Even more so, I do not think there will be anything but real C++ production interface (possibly wrapped in Python, but C++ at the core).
See also https://github.com/jtrmal/kaldi2020/issues/32#issuecomment-702132424


byobu: add screen backend

Motivation for this change
Screen backend was missing.
[nix-shell:~/dev/nixpkgs/result]$ byobu-screen - -v
Screen version 4.08.00 (GNU) 05-Feb-20

Closure size:
before: /nix/store/44rqjxl15zqlizgkwnxjxl8428asjm57-byobu-5.133	 156.1M
after:  /nix/store/a2lzmr53zvjbg9d5jdcxsj4v1nfvmc0f-byobu-5.133	 226.6M

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
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)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

missing byobu-config seems like a bother (not a byobu user) ? would you feel like adding it as well ? it shouldn't increase closure size too much.

The missing dependency is part of the package newt.
The package includes a python library (a single python file snack.py) that is not available in the package output.
I'm not sure how to make this library available to byobu-config.

My understanding:

The newt derivation will have to be modified to compile the snack.so required by byobu-config. This snack.so is compiled against Python.h.
The snack.so along with libnewt.so will have to be available in byobus environment.
I don't know whether including newt is enough for the proper environment variables to be available to byobu-config.

I think I could just use the patches from: #22774

Thanks for the comments @FRidh.
I merged the patches from #22774.
The pythonEnv does not seem to have the newt snack package in it. I've looked at many python packages that exported a python library and I still don't understand why the snack package is not picked up.

I came back to work on this.
I had to hack around with makeWrapper since arg0 is NOT the one set with exec -a within the bash scripts.
For instance, calling byobu-screen calls .byobu-screen and arg0 within the script is the path to .byobu-screen.
Byobu reads the arg0 to know which backend (between tmux and screen) it should start which is why all packages had to be wrapped with the non-default name.

In 129ec72 I fixed byobu-config.
I now have byobu-screen, byobu-tmux and byobu-config working.
PR is ready for reviewer @jonringer

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/315

/marvin opt-in
/status needs_reviewer

@SuperSandro2000 @glittershark
Thanks for the reviews, I think it should be good to go?

/status needs_merger

@jonringer Thanks, all fixed!

/status needs_merger

byobu has po files but does not compile them? Looking at the .deb it doesn't have the po files either...
The rpm version has it though, so I will copy the logic from it


dcoument better how to create run spec configurations

It took me very long time and looking into the code to figure out how to create a run spec conf for:
"summarisation"
entries: [{description: "summarization_xsum:temperature=0.3,model=openai/text-davinci-003", priority: 1}]

Concrete missing docu is in my view:

this list is not mentioned: https://github.com/stanford-crfm/helm/blob/6791ae77930a43daf7dce224ad366343155f6c27/src/helm/benchmark/run_specs.py#L1806
in the scenario docu here:
https://crfm-helm.readthedocs.io/en/latest/scenarios/

So to figure out that the scenario_name is indeed "summarization_xsum" required reading the code

The run_spec requires at least one arguments, even though I do not want to change the temperature. "not passing any argument" does not work

The arguments of the class SummarizationScenario do not match (at all) with the arguments of function "get_xsum_summarization_spec"

Thanks for the feedback. Agreed that this is complicated. There are several improvements that I would like to have:

Add better documentation of how run_specs.py and run expanders work and how to construct these strings (I have a draft of this)
Put all documentation of the arguments for each function run_specs.py and run expanders to ReadTheDocs
Better error messages
Consider making the run_specs.py functions match the scenario names; this may break reverse compatibility though

hello, I was wondering if there was an update on this?


Downloading a chart as PNG should always capture the whole chart area

Sometimes the chart PNG-download does not capture the whole chart area. However, I cannot really figure out what triggers this. I first thought that it had to do with the size of my browser window, but it doesn't seem to correlate.
A few examples:

I encountered exactly this issue when developing the feature, but the charts would be offset vertically rather than horizontally.
It happens because your browser window is too narrow to fit the sidebar, slides, and chart, so you've scrolled to the right to see the whole chart. The result is that the chart is offset in the PNG by the same amount as your window was scrolled.

I encountered exactly this issue when developing the feature, but the charts would be offset vertically rather than horizontally.
It happens because your browser window is too narrow to fit the sidebar, slides, and chart, so you've scrolled to the right to see the whole chart. The result is that the chart is offset in the PNG by the same amount as your window was scrolled.

Okay, thanks for the explanation and quick fix!

Okay, thanks for the explanation and quick fix!


RET-5353

JIRA link
https://tools.hmcts.net/jira/browse/RET-5353

Change description
Updates for code quality

Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

@JustMehmet the micromatch CVE issue has been fixed in https://github.com/hmcts/et-syr-frontend/pull/91. Can your yarn-audit files be updated to reflect it? Thanks

@JustMehmet the micromatch CVE issue has been fixed in #91. Can your yarn-audit files be updated to reflect it? Thanks

@hsjhita Thank you so much Harpreet :)