vim-lsc crashes ElixirLS on method shutdown

Description
When exiting Neovim using vim-lsc, message "[lsc:Error] ElixirLS has crashed. See Output panel." is shown.  Upon investigation, ElixirLS is throwing an exception (below).
Related from root:
https://github.com/JakeBecker/elixir-ls/issues/207
Steps to Reproduce

Open an Elixir file in a (Neo)vim instance using vim-lsc.
Ensure the ElixirLS is running.
Close the file.

Expected Behavior
The language server should exit cleanly.
Actual Behavior
ElixirLS crashes with the following:
21:16:59.997 [error] GenServer ElixirLS.LanguageServer.Server terminating
** (FunctionClauseError) no function clause matching in ElixirLS.LanguageServer.Server.handle_notification/2
    (language_server) lib/language_server/server.ex:216: ElixirLS.LanguageServer.Server.handle_notification(%{"id" => 2, "jsonrpc" => "2.0", "method" => "shutdown"}, %ElixirLS.LanguageServer.Server{analysis_ready?: false, awaiting_contracts: [], build_diagnostics: [], build_ref: nil, build_running?: false, client_capabilities: %{"textDocument" => %{"codeAction" => %{"codeActionLiteralSupport" => %{"codeActionKind" => %{"valueSet" => ["quickfix", "refactor", "source"]}}}, "completion" => %{"completionItem" => %{"snippetSupport" => false}}, "definition" => %{"dynamicRegistration" => false}, "signatureHelp" => %{"dynamicRegistration" => false}, "synchronization" => %{"didSave" => false, "willSave" => false, "willSaveWaitUntil" => false}}, "workspace" => %{"applyEdit" => true}}, dialyzer_diagnostics: [], dialyzer_sup: nil, needs_build?: false, project_dir: nil, received_shutdown?: false, requests: %{}, root_uri: "file:///Users/[redacted]/[project]" settings: nil, source_files: %{}})
    (language_server) lib/language_server/server.ex:144: ElixirLS.LanguageServer.Server.handle_cast/2
    (stdlib) gen_server.erl:637: :gen_server.try_dispatch/4
    (stdlib) gen_server.erl:711: :gen_server.handle_msg/6
    (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
Last message: {:"$gen_cast", {:receive_packet, %{"id" => 2, "jsonrpc" => "2.0", "method" => "shutdown"}}}
State: %ElixirLS.LanguageServer.Server{analysis_ready?: false, awaiting_contracts: [], build_diagnostics: [], build_ref: nil, build_running?: false, client_capabilities: %{"textDocument" => %{"codeAction" => %{"codeActionLiteralSupport" => %{"codeActionKind" => %{"valueSet" => ["quickfix", "refactor", "source"]}}}, "completion" => %{"completionItem" => %{"snippetSupport" => false}}, "definition" => %{"dynamicRegistration" => false}, "signatureHelp" => %{"dynamicRegistration" => false}, "synchronization" => %{"didSave" => false, "willSave" => false, "willSaveWaitUntil" => false}}, "workspace" => %{"applyEdit" => true}}, dialyzer_diagnostics: [], dialyzer_sup: nil, needs_build?: false, project_dir: nil, received_shutdown?: false, requests: %{}, root_uri: "file:///Users/[redacted]/[project]", settings: nil, source_files: %{}}

Environment
Elixir & Erlang versions (elixir --version):
Erlang/OTP 22 [erts-10.5.6] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe] [dtrace]

Elixir 1.9.4 (compiled with Erlang/OTP 22)

Operating system:
MacOS Catalina - 10.15.3 (19D76)
Client (editor or IDE):
vim-lsc 0.4.0

NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/tmp/neovim-20191107-85913-1wbgqz6/neovim-0.4.3/build/config -I/tmp/neovim-20191107-85913-1wbgqz6/neovim-0.4.3/src -I/usr/local/include -I/tmp/neovim-20191107-85913-1wbgqz6/neovim-0.4.3/deps-build/include -I/usr/local/opt/gettext/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include -I/tmp/neovim-20191107-85913-1wbgqz6/neovim-0.4.3/build/src/nvim/auto -I/tmp/neovim-20191107-85913-1wbgqz6/neovim-0.4.3/build/include
Compiled by<EMAIL_ADDRESS>
Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/Cellar/neovim/0.4.3/share/nvim"

Run :checkhealth for more info

How do you get vim-lsc to print out the error message?

According to the recent discussion in https://github.com/elixir-lsp/elixir-ls/pull/130 - it looks like there's a newer spec that ElixirLS properly follows.  Will post a ticket in vim-lsc.

How do you get vim-lsc to print out the error message?

I believe it shows this with:
let g:lsc_enable_diagnostics = v:true
However, to get the Elixir stack trace I wrote a wrapper script that calls tee to pipe stdin/stdout to a log.


Fix configuration example

Description
The configuration example in the documentation provides keys different from what the code at train_onpolicy.py, causing a KeyError
Motivation and Context
Documentation fixing
How Has This Been Tested?
KeyError no longer raised if the keys are changed in the configuration
Types of changes

[ ] Fix bugs
[ ] Add new feature
[x] Update documentation

@microsoft-github-policy-service agree
On Tue, Mar 7, 2023 at 1:51 AM microsoft-github-policy-service[bot] <
@.***> wrote:

@ammar-elsabe https://github.com/ammar-elsabe please read the following
Contributor License Agreement(CLA). If you agree with the CLA, please reply
with the following information.
@microsoft-github-policy-service agree [company="{your company}"]
Options:

(default - no company specified) I have sole ownership of
intellectual property rights to my Submissions and I am not making
Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work
for my employer (or my employer has intellectual property rights in my
Submissions by contract or applicable law). I have permission from my
employer to make Submissions and enter into this Agreement on behalf of my
employer. By signing below, the defined term “You” includes me and my
employer.

@microsoft-github-policy-service agree company="Microsoft"
Contributor License Agreement Contribution License Agreement
This Contribution License Agreement (“Agreement”) is agreed to by the
party signing below (“You”),
and conveys certain license rights to Microsoft Corporation and its
affiliates (“Microsoft”) for Your
contributions to Microsoft open source projects. This Agreement is
effective as of the latest signature
date below.

Definitions.
“Code” means the computer software code, whether in human-readable
or machine-executable form,
that is delivered by You to Microsoft under this Agreement.
“Project” means any of the projects owned or managed by Microsoft
and offered under a license
approved by the Open Source Initiative (www.opensource.org).
“Submit” is the act of uploading, submitting, transmitting, or
distributing code or other content to any
Project, including but not limited to communication on electronic
mailing lists, source code control
systems, and issue tracking systems that are managed by, or on behalf
of, the Project for the purpose of
discussing and improving that Project, but excluding communication
that is conspicuously marked or
otherwise designated in writing by You as “Not a Submission.”
“Submission” means the Code and any other copyrightable material
Submitted by You, including any
associated comments and documentation.
Your Submission. You must agree to the terms of this Agreement
before making a Submission to any
Project. This Agreement covers any and all Submissions that You, now
or in the future (except as
described in Section 4 below), Submit to any Project.
Originality of Work. You represent that each of Your Submissions
is entirely Your original work.
Should You wish to Submit materials that are not Your original work,
You may Submit them separately
to the Project if You (a) retain all copyright and license information
that was in the materials as You
received them, (b) in the description accompanying Your Submission,
include the phrase “Submission
containing materials of a third party:” followed by the names of the
third party and any licenses or other
restrictions of which You are aware, and (c) follow any other
instructions in the Project’s written
guidelines concerning Submissions.
Your Employer. References to “employer” in this Agreement include
Your employer or anyone else
for whom You are acting in making Your Submission, e.g. as a
contractor, vendor, or agent. If Your
Submission is made in the course of Your work for an employer or Your
employer has intellectual
property rights in Your Submission by contract or applicable law, You
must secure permission from Your
employer to make the Submission before signing this Agreement. In that
case, the term “You” in this
Agreement will refer to You and the employer collectively. If You
change employers in the future and
desire to Submit additional Submissions for the new employer, then You
agree to sign a new Agreement
and secure permission from the new employer before Submitting those
Submissions.
Licenses.

Copyright License. You grant Microsoft, and those who receive the
Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive,
royalty-free, irrevocable license in the
Submission to reproduce, prepare derivative works of, publicly
display, publicly perform, and distribute
the Submission and such derivative works, and to sublicense any or all
of the foregoing rights to third
parties.
Patent License. You grant Microsoft, and those who receive the
Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive,
royalty-free, irrevocable license under
Your patent claims that are necessarily infringed by the Submission or
the combination of the
Submission with the Project to which it was Submitted to make, have
made, use, offer to sell, sell and
import or otherwise dispose of the Submission alone or with the
Project.
Other Rights Reserved. Each party reserves all rights not
expressly granted in this Agreement.
No additional licenses or rights whatsoever (including, without
limitation, any implied licenses) are
granted by implication, exhaustion, estoppel or otherwise.

Representations and Warranties. You represent that You are
legally entitled to grant the above
licenses. You represent that each of Your Submissions is entirely Your
original work (except as You may
have disclosed under Section 3). You represent that You have secured
permission from Your employer to
make the Submission in cases where Your Submission is made in the
course of Your work for Your
employer or Your employer has intellectual property rights in Your
Submission by contract or applicable
law. If You are signing this Agreement on behalf of Your employer, You
represent and warrant that You
have the necessary authority to bind the listed employer to the
obligations contained in this Agreement.
You are not expected to provide support for Your Submission, unless
You choose to do so. UNLESS
REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE
WARRANTIES
EXPRESSLY STATED IN SECTIONS 3, 4, AND 6, THE SUBMISSION PROVIDED
UNDER THIS AGREEMENT IS
PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO,
ANY WARRANTY OF
NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
Notice to Microsoft. You agree to notify Microsoft in writing of
any facts or circumstances of which
You later become aware that would make Your representations in this
Agreement inaccurate in any
respect.
Information about Submissions. You agree that contributions to
Projects and information about
contributions may be maintained indefinitely and disclosed publicly,
including Your name and other
information that You submit with Your Submission.
Governing Law/Jurisdiction. This Agreement is governed by the
laws of the State of Washington, and
the parties consent to exclusive jurisdiction and venue in the federal
courts sitting in King County,
Washington, unless no federal subject matter jurisdiction exists, in
which case the parties consent to
exclusive jurisdiction and venue in the Superior Court of King County,
Washington. The parties waive all
defenses of lack of personal jurisdiction and forum non-conveniens.
Entire Agreement/Assignment. This Agreement is the entire
agreement between the parties, and
supersedes any and all prior agreements, understandings or
communications, written or oral, between
the parties relating to the subject matter hereof. This Agreement may
be assigned by Microsoft.

—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/qlib/pull/1454#issuecomment-1457056355, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AU4NO23FDIRS7W52YOI7HADW2ZL5XANCNFSM6AAAAAAVQ2XBGM
.
You are receiving this because you were mentioned.Message ID:
@.***>


Use name MSBuild project file

To use the same terminology that Microsoft used, and to distinguish between MS Build project files and other project files (config, resx, etc.) the term MSBuild project file should be used when applicable.

This can potentially be closed.


update ppocr for m85

I will delete readme & update later. meanwhile, for 310.ld file, will change relevant configuration description.


Class not found: wrong package

Class imports com.hp.autonomy.types.idol.QueryRespons which doesn't exist in com.hp.autonomy.types.idol in master. This breaks compilation after package version update.
Compare with: https://github.com/hpe-idol/java-idol-types/blob/master/src/main/java/com/hp/autonomy/types/idol/responses/QueryResponse.java where should be required class.

Hi, java-idol-types version > 1.00 has replaced this library, as noted on https://github.com/hpe-idol/java-idol-types/commit/e94ef2d5b3640f0ec1d49645b2bdba95644b46cd . Please use that instead.


AttributeError: 'module' object has no attribute 'gfile' in 0.7.0 [Fixed in source, will be in next binary release]

I'm on an Ubuntu machine, installed tensorflow and ran the image processing example as in the website but it failed complaining about gFile not found,
Here's the exception stack:
	Traceback (most recent call last):
	  File "classify_image.py", line 213, in <module>
	    tf.app.run()
	  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/platform/default/_app.py", line 30, in run
	    sys.exit(main(sys.argv))
	  File "classify_image.py", line 209, in main
	    run_inference_on_image(image)
	  File "classify_image.py", line 154, in run_inference_on_image
	    if not tf.gfile.Exists(image):
	AttributeError: 'module' object has no attribute 'gfile'

Same here, got this error when running cifar10_eval.py

My guess is that you are running source code from HEAD with a pip install from 0.6.0.  Either check out the code at the same branch / tag as the pip install, or compile from sources at HEAD to use code at head.

Let me check that, thanks for looking into it.

I had the same problem executing the file classify_image.py. Changing the branch to 0.6.0 solved this problem. Thanks!

@akhld @Kecksdose
Yes, using r0.7.0, and run
$ cd tensorflow/models/image/mnist
$ python convolutional.py
will have this problem.
When changing to 0.6.0, no this problem.

So the temporary fix for this is to use 0.6.0 for TensorFlow?

Try upgrading to 0.7.1
pip uninstall tensorflow
pip uninstall protobuf
pip install path/to/0.7.1.wheel

It works fine on 0.8

Was with this error to run ptb_word_lm.py in the old version.
Really, after upgrading worked properly
thanks! @vrv


Hook Overhaul

This changes a lot regarding hooks, namely:

Hooks are now mandatory, enableHooks no longer exists. Hooks now take a more low-level fundamental step that is always activated, because they are no longer to be used for API security and other high level functions. For that, one must use Shields. Shields protect the API, Hooks bind into the Datastore.
More hooks options: hooks added for afterQuery.
Few other breaking changes: since we are breaking the API, I took the opportunity to refactor some bits that were messy (typos, generics, etc).

It's a huge commit that introduces lots of breaking changes. Please review it carefully.

Coverage increased (+0.1%) to 64.189% when pulling 918dcec5fbd9a540c7c2cb692da4499f2b4944aa on new-hooks into 26c18a007dc026508e0bd5f45aa4ab35940f3b27 on master.

@luanpotter thanks for the great PR!
Just a note, wouldn't it be possible to have only on beforeQuery and afterQuery and have different methods in QueryBuilder<T> ?
For instance:
@Override
public void beforeQuery(QueryBuilder<Object> q) {
    q.forceId(id);
    q.forceList(list);
    q.forceObject(object);
}

Maybe with Response suffix?
For afterQuery:
@Override
public void afterQuery(QueryBuilder<Object> q) {
    q.id();
    q.list();
    q.first();
    q.only();
}

Since it is afterQuery it would return the value it just got from database.
Possibly, if you don't like that one, we could have something like this:
@Override
public void afterQuery(QueryBuilder<Object> q) {
    q.getIdResponse();
    q.getListResponse();
    q.getObjectResponse();
}

I added the BeforeQueryObject because I need to know the QueryType in the hook. I could add that as a property of QueryBuilder and then access it via q.getType(), I actually considered doing that but I thought it might pollute the QueryBuilder scope.
Regarding the afterQuery, if I have the getType() method available, it can be a single afterQuery hook, but I'll need three methods to fetch the three possible responses.
It could be these:
    @Override
    public void afterQuery(QueryBuilder<Object> q) {
        q.id();
        q.list();
        q.first();
        q.only();
    }

But that would cause problems because these already exist as query finalizers. Think like so: you called .list() somewhere to finish a query, it starts running the list method, runs the before hook, fetches the data and run the after hook, before ending. While it runs the after hook it's still in the list() method call chain. I could add a control to the start of the method to see if it's the second time it's called in the same chain, but I think it would be a bit convoluted.
I think the solution of adding distinct methods for this might be better than reusing list, ids, etc.
However, I do think it might be confusing for the regular user (that does not do hooks) to have these extra names polluting the scope; for example, you are building your pretty query in your action and go:
    yawp(Foo.class).where("bar", "=", bar).

And after this dot the option getListResponse is presented, but it won't do anything, as the only correct option in this place would be .list(). The other, equally tempting option will simply return null.
On that sense, reusing the method and applying some sort of state control to know the second call to a finalizer method might be better, but still seems unnatural, odd, convoluted and confusing to me (trying to think like a regular user).
Thoughts?

Think like so: you called .list() somewhere to finish a query, it starts running the list method, runs the before hook, fetches the data and run the after hook, before ending.

I think afterQuery is supposed to run after the query has finished. It is safe to do that. And I also think that a state control inside QueryBuilder is a good option..

On that sense, reusing the method and applying some sort of state control to know the second call to a finalizer method might be better, but still seems unnatural, odd, convoluted and confusing to me (trying to think like a regular user).

For me, since it is in afterQuery, it is natural to suppose that the query has already ran.

if I have the getType() method available, it can be a single afterQuery hook

QueryBuilder already has a:
protected Class<T> getClazz() {
      return clazz;
}

We can make it public...
What do you think?

getType is not getClazz, it's to get the QueryType (it can be LIST, IDS, FETCH). On beforeQuery, I need to know which finalizer was called. Because otherwise that information is totally unavailable to the hook. I also need to know this on afterQuery if I'm supposed to know if I need to call ids(), list() or what to get the results.
Regarding the state control, how exactly would it work?
Some cases : if I call a finalizer on the beforeQuery, for instance, what happens? should throw an exception, invalid state? because I'm in the middle of running a finalizer and I'm calling it again.
if I call it in the after, it returns immediately with the result gotten previously.
Outside of hooks, the finalizers should work as is.
There are several finalizers: ids(), only(), onlyId(), list(), fetch(), executeQuery(), executeQueryIds() (that I can remember now from the top of my head).
The basal ones that the other use are three: LIST, FETCH and IDS (that's the query type).
 Return null or throw?

The current version exposes the following methods in the Query Builder:
QueryType getQueryType()
Object getExecutedResponse()

void forceResult(QueryType type, Object obj)
void clearForcedResult(Type tpye)
void clearForcedResults()
bool hasForcedResult(QueryType type)
bool hasForcedResult()

Also, beforeQuery and afterQuery hooks have each a single signature taking in only the QueryBuilder as a parameter.
A very naïve possible cache implementation is shown in a test.


[CELEBORN-1230] Check working directory read and write error without init delay

What changes were proposed in this pull request?
In this pr, when getting device disk info, we check the dir writable to make sure that the capacity reported to celeborn master are correct and does no include non-writable directories.
Why are the changes needed?
To ignore bad disk when initializing the worker.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing UT.

It seems to change the behavior.
Previously, it could tolerate temporary disk issues, e.g. some configured disks have no permission to write due to wrong setup, and the disk will be back once the permission issue gets fixed. But after this change, the issued disks will be excluded forever until restarting the process?

Previously, it could tolerate temporary disk issues, e.g. some configured disks have no permission to write due to wrong setup, and the disk will be back once the permission issue gets fixed. But after this change, the issued disks will be excluded forever until restarting the process?

Yes.
But previously, if only one disk is used and the disk is bad, the worker still serves traffic, but all the requests will fail.

... if only one disk is used and the disk is bad, the worker still serves traffic, but all the requests will fail.

I suppose the design of Celeborn can handle bad / run-out-of-space issues at runtime dynamically. Permanently excluding a bad disk at startup is too rough.

... if only one disk is used and the disk is bad, the worker still serves traffic, but all the requests will fail.

I suppose the design of Celeborn can handle bad / run-out-of-space issues at runtime dynamically. Permanently excluding a bad disk at startup is too rough.

Currently Celeborn will not retry creating base working directories if it fails to create when startup. It only manages inner directories inside the base working directories. So I think this PR is necessary. Maybe we can add check-and-retry for base working dirs in future.

Another alternative is to extract LocalDeviceMonitor#startCheck#run into a method, and explicitly call the method after base working directories are created, so it will be marked as READ_OR_WRITE_FAILURE, and no slots will be allocated on it.

Another alternative is to extract LocalDeviceMonitor#startCheck#run into a method, and explicitly call the method after base working directories are created, so it will be marked as READ_OR_WRITE_FAILURE in the initialization of StorageManager if the disk is not available, and no slots will be allocated on it. LocalDeviceMonitor#readWriteError will always try to create the directory, so even though the base working directory is not created in startup, whenever the disk goes back to healthy, the directory will be created.

checking

Another alternative is to extract LocalDeviceMonitor#startCheck#run into a method, and explicitly call the method after base working directories are created, so it will be marked as READ_OR_WRITE_FAILURE in the initialization of StorageManager if the disk is not available, and no slots will be allocated on it. LocalDeviceMonitor#readWriteError will always try to create the directory, so even though the base working directory is not created in startup, whenever the disk goes back to healthy, the directory will be created.

How about just set the init delay for LocalDeviceMonitor#startCheck task scheduling to 0? @waitinfuture

LocalDeviceMonitor

This is a good idea.

thanks @waitinfuture


NPM CLI is deprecating -global

:speaking_head: Foreword
Debated on this being "Feature request" or "Bug"
NPM has been talking about deprecating -global - this cookbook needs to account for that.
:person_frowning: Problem Statement
Recent releases of NPM CLI have fulfilled the deprecation - causing helper to fail since it prints the deprecation warning to stderr https://github.com/sous-chefs/nodejs/blob/main/libraries/nodejs_helper.rb#L25
Luckily NPM has reverted it, but not before some damage done : https://github.com/npm/cli/releases/tag/v8.12.1
:grey_question: Possible Solution
Update helper to use --location=global instead
:arrow_heading_up: Describe alternatives you've considered
Pinning to specific NPM CLI version, but that's short-sighted
:heavy_plus_sign: Additional context
https://github.com/npm/cli/commit/8898710220a3d84b0a9ea2a6d9cf880e50b94c9e

Another option is to pass environment along so the npm list can better/properly mimic what npm install will eventually do.


MeTTa libraries documentation

This is a subissue of #319 .
The goal is to introduce MeTTa code documentation machinery for MeTTa code in general, libraries in particular, and stdlib especially.
The proposal is to document MeTTa code in MeTTa itself. There are a few choices to be made:

In what format to place such pieces of documentation: doc-strings, doc-expressions with certain type structure, or something else?
Where exactly to place them: the library space itself, a global &doc space, a separate doc-space for each library?
Where MeTTa code for documentation is formed? Should register_token accept it as an additional argument? Should the space being imported just contain doc-expressions as stand-alone expressions similar to type definitions, or should these expressions be somehow places inside equalities like Python docstrings?
How should documentation (+type declarations) be automatically gathered and can missing documentation be automatically detected?

There are a few issues that may prevent us from answering all these questions atm:

we don’t have a notion of “known tokens” both for pure symbols and tokens for grounded atoms. Pure symbols don’t require obligatory definition to be used. While typing expressions can be used for “detecting” known symbols, even typing expressions can be tricky, e.g. (: ($t A) (B $t)) is a valid expression. All mentioned symbols can be extracted from an entire space, though. Tokens for grounded atoms are regular expressions. Apparently, we cannot document each concrete instance, e.g., each number. The situation may partly change if we introduce bindings as a part of spaces.
We have libraries, imports and py-extensions. We still don’t have a strict way to define new libraries. As for stdlib, we can either put doc-expressions in its space or do anything else we want. But will “anything else” work for custom libraries? For the case of importing pure MeTTa scripts, we have no choice but to put doc-expressions into scripts themselves, although it doesn’t necessarily mean that these expressions will remain in the same space. E.g., documenting can be done via import-time execution (that is, with something like ! (doc …)). Also, documentation for libraries and for pure MeTTa code may not necessarily be done identically.

Let’s consider some examples, of how it could look like.

Doc-expressions are mere expressions over strings put arbitrarily into spaces, e.g.

(: doc (-> Atom String Atom))
(doc doc “Document any atom or expression”)
(doc String “The type for grounded strings”)
(doc + “Grounded operation for summing two numbers”)

For stdlib, all docs are just put in stdlib.rs/metta_code(). Thus, all docs can be retrieved by matching against &self since &stdlib space is places into it. An option is to have doc as a function. Pros: no need for special implementation, uniformity over different use cases. Cons: definitions are detached from implementation of grounded functions. The main space is littered with doc-expressions. No formal structure amenable to automatic processing is provided.

Structured doc-expressions in a dedicated space.

(: doc (-> Atom DocEntry Atom Atom))
(: FnParam (-> Number DocEntry))
(: FnOut DocEntry)
(: DocModule DocEntry)
!(doc + (FnParam 0) “The first number to add”)
!(doc + FnOut “The sum of two numbers”)
!(doc + DocModule stdlib)

The structure can be different. Some doc-expressions (e.g. module) can be added automatically.
doc is a grounded function defined in stdlib, which puts its input to &doc space, that can be called from any script. Then (match &doc (doc …)) can be used to retrieve doc-expressions. We can move in the direction of even more complete formal specification of semantics and pragmatics of symbols and grounded atoms for self-programming. But maybe we just need to keep the possibility for future extensions with doc-expression types explicitly indicating whether the description provided as a string or a richer structure.
Pros: possible further automatization and additional formatting of the documentation with possible cross-references, etc. Cons: might be a little bit annoying to follow the structure of doc, but can be mitigated by providing syntactic sugar for loose doc-strings.

In-place documentation, e.g. doxygen-like

;;; \brief My first function
;;; \param[out] a random atom
;;; \param[in] src yet another random atom
(= (my-f $a) (…))

Such comments can be processed by the parser in a special way and turned into expressions. Pros: may look convenient and human-readable. Cons: we don’t have single definition per function; special processing may make this harder to extend in the future, etc.
These examples are not mutually exclusive and can be partly combined. There are more detailed to discuss and flesh out, of course.
We can proceed step-by-step and start with agreeing on embedding MeTTa-documentation in MeTTa itself with further automatic extraction to html or whatever.

Apparently, we cannot document each concrete instance, e.g., each number.

But we can add same documentation for each token (you probably meant it, just wanted to mention it explicitly). On the other hand for the grounded value tokens we probably need to document types instead of tokens themselves.

Doc-expressions are mere expressions over strings put arbitrarily into spaces, e.g.

Not sure I understand "cons" properly. We can define doc as a grounded function and get documentation string from a grounded atom or an atomspace depending on atom which is passed as an argument inside doc function.

Structured doc-expressions in a dedicated space.

Another downside of having separate &doc space is that we need to have one more global space. I wanted to eliminate global spaces inside grounded functions in "minimal MeTTa" as using them causes problems. In particular each imported space should have its own copy of the grounded symbol with &self space embedded.
I like the structured documentation approach from option (2). But I think we could keep documentation in the same atomspace where the code of the module lives. I very keen to idea of replacing current MeTTa runner by space which has ability to keep/run grounded functions. In this context docs and types of the grounded functions can be represented uniformly.
Before uniform representation is implemented we could divide ways of documenting grounded atoms and pure functions. providing uniform interface through MeTTa runner.

In what format to place such pieces of documentation: doc-strings,
doc-expressions with certain type structure, or something else?

To me the most convenient way is to keep documentation as expressions with a
specified structure. Thus separate doc formatting function can read data and
provide it to the user in a most convenient way.

Where exactly to place them: the library space itself, a global &doc space, a
separate doc-space for each library?

I would suggest keeping documentation in the same space where corresponding
atoms are kept. In this case documentation hierarchy is the same as hierarchy
of modules.

Where MeTTa code for documentation is formed? Should register_token accept it
as an additional argument? Should the space being imported just contain
doc-expressions as stand-alone expressions similar to type definitions, or
should these expressions be somehow places inside equalities like Python
docstrings?

As a first step we could provide documentation for the pure symbols explicitly
in an expression form. This allows using current parser without modifications.
For the tokens we don't have a simple solution. We can have multiple tokens
definitions which are effectively represent the same token. Thus adding
documentation to the register_token call will lead to the code duplication.
As tokens can be duplicated there is a question do we need to document each
registered token. May be it is enough to document the type of the value for the
tokens which produce values. And when token produces the grounded function we
could document the function itself. I would suggest keeping documentation of
the grounded tokens inside accompanying space. For stdlib it is the
metta_code for the 3rd party modules it should be a part of the module.

How should documentation (+type declarations) be automatically gathered and
can missing documentation be automatically detected?

I would say in general we should have each symbol and each grounded atom
documented. Thus when user is asking for a help for some symbol or grounded
atom name the help function can provide the documentation for this symbol.
Possible algorithm of the help function.
help function checks the meta-type of the atom. If atom's metatype is
Grounded then help gets the type of the atom. There are two options. If the
type is a function type then help searches documentation by the atom itself.
Otherwise help searches documentation for the type atom. In a case of the
Symbol metatype help could search for the documentation using symbol
itself. For the Expression metatype help can try to search documentation
for the whole expression or for the first atom of the expression also depending
on its type.
Proposed documentation format
Documentation of the function:
(function
  (description "Description of the function")
  (parameters
    ; name of the parameter is extracted from the function definition
    ; type of the parameter is extracted from the function type
    ; in/out effectively each parameter in MeTTa can input and output value
    ;        at the same time but it makes sense sometimes to restrict this
    ;        to only input or only output, it can be done using `sealed`
    (parameter "First parameter's description")
    [... (parameter "Second parameter's description")]
    ; type of the returned value is extracted from the function type
    (return "Description of the return result")
  ))

Documentation of the other atoms:
(atom (description "Description of the atom"))

There are different possibilities to link atom to the documentation:

define function (= (doc <atom>) ...) which returns a documentation of the
<atom>
add (name ...) to the documentation atom and use it as an anchor to search
documentation from the help function

I would try to implement help and documentation examples and finalize
decision after experimenting.

To me the most convenient way is to keep documentation as expressions with a
specified structure.

Yes

I would suggest keeping documentation in the same space where corresponding
atoms are kept.

OK

As a first step we could provide documentation for the pure symbols explicitly
in an expression form.

OK

Proposed documentation format

Looks good. The only concern I have is that tuples are not conveniently deconstructable. OTOH, providing descriptions of each parameter as a separate expression is also not convenient in terms of the parameter order specification.

There is an idea to mark functions as deterministic/non-deterministic. It is similar to in/out value passing direction. On the one hand we could mark it such in documentation. On the other hand it is a part of the function contract and should be available for the analysis by interpreter thus should be a part of the function definition.

Providing this info in docs in such a way that it looks formal but doesn't influence the interpreter and can be in contradiction with the function behavior (and the function contract if it will include it) looks like a possible source of confusion. OTOH, consistency of documentation and function contracts can be automatically checked (which is also a possible case for formal parameters). Maybe, we should just call it spec instead of doc and add any metadata there :)

https://github.com/trueagi-io/hyperon-experimental/pull/694 adds documentation for the standard library.


[HUDI-5301] Spark SQL queries support setting parameters through set

Change Logs
[HUDI-5301] Spark SQL queries support setting parameters through set
Impact
[HUDI-5301] Spark SQL queries support setting parameters through set
Risk level (write none, low medium or high below)
none
Documentation Update
Describe any necessary documentation update if there is any new feature, config, or user-facing change

The config description must be updated if new configs are added or the default value of the configs are changed
Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
ticket number here and follow the instruction to make
changes to the website.

Contributor's checklist

[x] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

@dongkelun I'm not a big fan of querying hudi table in other modes by setting spark conf.  Maybe TableValuedFunction  is a better way.


Docker slave provisioning fails

YADP 0.1.0-rc29

[root@365f17e65bac ~]# docker images | grep jenkins-slave
greenlancer/jenkins-slave                 latest              d442745d65e6        7 days ago          2.111 GB

[root@365f17e65bac ~]# docker version
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:
 OS/Arch:      linux/amd64

[root@365f17e65bac ~]# java -version
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-b15)
OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)

When using the SSH launcher I receive
Nov 10, 2016 5:11:39 PM SEVERE com.github.kostyasha.yad.DockerCloud lambda$provision$0

Error in provisioning; template='DockerSlaveTemplate[id=3413aa87-f92e-43db-9d16-cf0d17aaa061,labelString=docker-slave,launcher=com.github.kostyasha.yad.launcher.DockerComputerSSHLauncher@461caf10,remoteFs=/home/jenkins,maxCapacity=10,mode=EXCLUSIVE,retentionStrategy=com.github.kostyasha.yad.strategy.DockerOnceRetentionStrategy@27f,numExecutors=1,dockerContainerLifecycle=com.github.kostyasha.yad.DockerContainerLifecycle@64c02363[image=greenlancer/jenkins-slave:latest,pullImage=com.github.kostyasha.yad.commons.DockerPullImage@1a93cb47,createContainer=DockerCreateContainer[command=/opt/entrypoint.sh,hostname=,dnsHosts=[],volumes=[/var/run/docker.sock:/var/run/docker.sock],volumesFrom=[],environment=[],bindPorts=,bindAllPorts=false,memoryLimit=1536,cpuShares=1024,privileged=false,tty=true,macAddress=<null>,extraHosts=[],networkMode=<null>,devices=[],cpusetCpus=,cpusetMems=,links=[]],stopContainer=com.github.kostyasha.yad.commons.DockerStopContainer@27f,removeContainer=com.github.kostyasha.yad.commons.DockerRemoveContainer@5b0f],nodeProperties=[]]' for cloud='Docker Slave'
java.lang.NullPointerException
	at com.github.kostyasha.yad_docker_java.com.google.common.base.Preconditions.checkNotNull(Preconditions.java:212)
	at com.github.kostyasha.yad_docker_java.com.google.common.net.HostAndPort.fromString(HostAndPort.java:168)
	at com.github.kostyasha.yad_docker_java.com.google.common.net.HostAndPort.fromParts(HostAndPort.java:135)
	at com.github.kostyasha.yad.launcher.DockerComputerSSHLauncher.getHostAndPort(DockerComputerSSHLauncher.java:151)
	at com.github.kostyasha.yad.launcher.DockerComputerSSHLauncher.waitUp(DockerComputerSSHLauncher.java:83)
	at com.github.kostyasha.yad.DockerCloud.provisionWithWait(DockerCloud.java:219)
	at com.github.kostyasha.yad.DockerCloud.lambda$provision$0(DockerCloud.java:120)
	at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

When using the JNLP launcher I receive
Nov 10, 2016 5:35:19 PM INFO com.github.kostyasha.yad.DockerCloud provision
Asked to provision load: '1', for: 'docker-slave' label

Nov 10, 2016 5:35:19 PM INFO com.github.kostyasha.yad.DockerCloud provision
Will provision 'greenlancer/jenkins-slave:latest', for label: 'docker-slave', in cloud: 'Docker Slave'

Nov 10, 2016 5:35:19 PM INFO com.github.kostyasha.yad.DockerCloud addProvisionedSlave
Not Provisioning 'greenlancer/jenkins-slave:latest'; Server 'Docker Slave' full with '5' container(s)

Nov 10, 2016 5:35:19 PM INFO com.github.kostyasha.yad.DockerCloud provision
Asked to provision load: '1', for: 'docker-slave' label

Nov 10, 2016 5:35:19 PM INFO com.github.kostyasha.yad.DockerCloud provision
Will provision 'greenlancer/jenkins-slave:latest', for label: 'docker-slave', in cloud: 'Docker Slave'

Nov 10, 2016 5:35:19 PM INFO com.github.kostyasha.yad.DockerCloud addProvisionedSlave
Not Provisioning 'greenlancer/jenkins-slave:latest'; Server 'Docker Slave' full with '5' container(s)

I would highly prefer to use the SSH launcher as it was working for me in the past when using Docker Plugin. It seems though that the upgrade from Docker 1.11.2 to Docker 1.12.3 has been problematic for many people when using either YADP or Docker Plugin. Let me know what other data you need.

JNLP is the best way imho.

Could you show docker ps - ensure that container was created
docker log for some failing container?

CONTAINER ID        IMAGE                              COMMAND                CREATED             STATUS              PORTS                                                      NAMES
aaa6d474da8c        greenlancer/jenkins-slave:latest   "/opt/entrypoint.sh"   31 minutes ago      Up 30 minutes       <IP_ADDRESS>:32772->22/tcp                                      evil_heisenberg
fbf3e9051104        greenlancer/jenkins-slave:latest   "/opt/entrypoint.sh"   31 minutes ago      Up 31 minutes       <IP_ADDRESS>:32771->22/tcp                                      jolly_dubinsky
8e322c0631c8        greenlancer/jenkins-slave:latest   "/opt/entrypoint.sh"   31 minutes ago      Up 31 minutes       <IP_ADDRESS>:32770->22/tcp                                      backstabbing_lamarr
078f8545ba09        greenlancer/jenkins-slave:latest   "/opt/entrypoint.sh"   31 minutes ago      Up 31 minutes       <IP_ADDRESS>:32769->22/tcp                                      trusting_brahmagupta
54200d513e78        greenlancer/jenkins-slave:latest   "/opt/entrypoint.sh"   32 minutes ago      Up 32 minutes       <IP_ADDRESS>:32768->22/tcp                                      kickass_agnesi

I guess because I'm not actually exposing port 50000 in my slaves...

with JNLP slave doesn't need expose any port, on docker master maybe...
This slaves created by SSH launcher. Did you set 30 min timeout manually?
Provide docker inspect on container this will show network configuration.

[
    {
        "Id": "aaa6d474da8cd141c77644e19a6ffc1cb59b2699c1666347eda3a47f4f7a783e",
        "Created": "2016-11-10T22:12:09.450765169Z",
        "Path": "/opt/entrypoint.sh",
        "Args": [],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 32411,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2016-11-10T22:12:09.968436962Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
        "Image": "sha256:d442745d65e6f0765578ab2b41e138a4921da9707471efdea11cec24fae9c52d",
        "ResolvConfPath": "/var/lib/docker/containers/aaa6d474da8cd141c77644e19a6ffc1cb59b2699c1666347eda3a47f4f7a783e/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/aaa6d474da8cd141c77644e19a6ffc1cb59b2699c1666347eda3a47f4f7a783e/hostname",
        "HostsPath": "/var/lib/docker/containers/aaa6d474da8cd141c77644e19a6ffc1cb59b2699c1666347eda3a47f4f7a783e/hosts",
        "LogPath": "/var/lib/docker/containers/aaa6d474da8cd141c77644e19a6ffc1cb59b2699c1666347eda3a47f4f7a783e/aaa6d474da8cd141c77644e19a6ffc1cb59b2699c1666347eda3a47f4f7a783e-json.log",
        "Name": "/evil_heisenberg",
        "RestartCount": 0,
        "Driver": "devicemapper",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "",
        "ExecIDs": null,
        "HostConfig": {
            "Binds": [
                "/var/run/docker.sock:/var/run/docker.sock:rw"
            ],
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "json-file",
                "Config": {}
            },
            "NetworkMode": "default",
            "PortBindings": {
                "22/tcp": [
                    {
                        "HostIp": "<IP_ADDRESS>",
                        "HostPort": ""
                    }
                ]
            },
            "RestartPolicy": {
                "Name": "",
                "MaximumRetryCount": 0
            },
            "AutoRemove": false,
            "VolumeDriver": "",
            "VolumesFrom": null,
            "CapAdd": null,
            "CapDrop": null,
            "Dns": null,
            "DnsOptions": null,
            "DnsSearch": null,
            "ExtraHosts": null,
            "GroupAdd": null,
            "IpcMode": "",
            "Cgroup": "",
            "Links": null,
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": null,
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "ConsoleSize": [
                0,
                0
            ],
            "Isolation": "",
            "CpuShares": 1024,
            "Memory":<PHONE_NUMBER>,
            "CgroupParent": "",
            "BlkioWeight": 0,
            "BlkioWeightDevice": null,
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 0,
            "CpuQuota": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": null,
            "DiskQuota": 0,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap":<PHONE_NUMBER>,
            "MemorySwappiness": -1,
            "OomKillDisable": false,
            "PidsLimit": 0,
            "Ulimits": null,
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0
        },
        "GraphDriver": {
            "Name": "devicemapper",
            "Data": {
                "DeviceId": "530",
                "DeviceName": "docker-202:2-10846920-5c5d885fbe34766f1302a998ea67b23a36182c962f8ce9e735907929cde49363",
                "DeviceSize": "10737418240"
            }
        },
        "Mounts": [
            {
                "Source": "/var/run/docker.sock",
                "Destination": "/var/run/docker.sock",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],
        "Config": {
            "Hostname": "aaa6d474da8c",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "ExposedPorts": {
                "22/tcp": {}
            },
            "Tty": true,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "TFVERSION=0.7.8",
                "TINI_SHA=3cd94f0af6206c70f4639b3971d20d511e5dcd565a0424af2b522598de7227c7"
            ],
            "Cmd": [
                "/opt/entrypoint.sh"
            ],
            "Image": "greenlancer/jenkins-slave:latest",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {
                "build-date": "20161102",
                "cache": "3uij659ubDSGIJFB",
                "com.github.kostyasha.yad.DockerCloud": "Docker Slave",
                "com.github.kostyasha.yad.DockerSlave": "3413aa87-f92e-43db-9d16-cf0d17aaa061",
                "license": "GPLv2",
                "name": "CentOS Base Image",
                "vendor": "CentOS"
            }
        },
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "72c6f42301bdeddc62144d3bc9c0ce2c1e3ebacd4df2553fcd58333e4d6129a9",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {
                "22/tcp": [
                    {
                        "HostIp": "<IP_ADDRESS>",
                        "HostPort": "32772"
                    }
                ]
            },
            "SandboxKey": "/var/run/docker/netns/72c6f42301bd",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "d287b2fb30655b37a2b58da9440444f72895714e7cfbe267e8ae2f39dee99772",
            "Gateway": "<IP_ADDRESS>",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "<IP_ADDRESS>",
            "IPPrefixLen": 24,
            "IPv6Gateway": "",
            "MacAddress": "02:42:0a:14:ff:07",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "df502659b9393828358c9545c98cff3d819f72147b65cd463e5e5a5e9c22a909",
                    "EndpointID": "d287b2fb30655b37a2b58da9440444f72895714e7cfbe267e8ae2f39dee99772",
                    "Gateway": "<IP_ADDRESS>",
                    "IPAddress": "<IP_ADDRESS>",
                    "IPPrefixLen": 24,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:0a:14:ff:07"
                }
            }
        }
    }
]

And here we debugging SSH. :(
Could you cut all related ssh failure issue into source issue. And here all related JNLP?

Ah, I gotcha.
Do you have a location where I can see the Dockerfile for kostyasha/jenkins-slave

For ssh evarga/jenkins-slave should work as it simple expose SSH with preconfigured user.
For JNLP you may even use https://github.com/KostyaSha/yet-another-docker-plugin/blob/25d28c065f0928970eb8446ef092d435fe47e83c/yet-another-docker-its/src/test/java/com/github/kostyasha/it/tests/SimpleBuildTest.java#L79
In case of errors for jnlp launcher follow docker log of this container.

I'm going to call it a night for now. I will pick this fight with JNLP back up tomorrow. I can see the container launching which is a good thing. I believe I need to fiddle with the jenkins master host and the user.
Thanks for you time so far. I appreciate the help.

I can suggest to try jenkins/evarga-slave just to check that your container isn't built in some other way.

I am seeing this exact same issue when using yad plugin and ssh to connect.  I compared my log output and the docker inspect output etc.  A couple of things to note.  I am using the same docker image that I use for a container that I spin up by hand and connect to Jenkins (which works fine).  In addition, if I create a new new node and use the port of one of the docker containers spun up by yad, jenkins connects fine and all is good with that container.  Looking at the inspect and comparing against my hand created container, I see that in the HostConfig->PortBindings section the HostIP is "<IP_ADDRESS>" and HostPort is empty on the yad created one and HostIP is empty and HostPort has the port set on my hand run container.  That seems it could be related since the error indicates it fails on a checkNotNull call.  Anyway, any more info on this and can you help me out?


Change config precedence so env vars are king

fixes #399

After talking to @JonahSussman We may prefer config.toml taking precedence. If we do we just need to remove some of the defaults in config_example.toml to resolve the podman issues.

@shawn-hurley personally I would like to see this merged. I don't think that changing the example file is enough to resolve this the more I play with it. If I switch between dev env and the compose workflow this will still break with the database config values set.
I feel strongly that env vars taking highest precedence is the most common flow of configuration across languages. Am I wrong?

I'm down to make env variables king, but the PR currently works by overriding the init function of the class. Take, for example, this environment:
export KAI__LOG_LEVEL = INFO

and you did this in Python in a Python test case:
config = KaiConfig(log_level="DEBUG")
assert config.log_level == "DEBUG"

It will fail in some environments and succeed in others. Thus, I don't think we should mess with the precedence. Instead, I think we should:

Remove the build/config.toml file entirely
Ask users to configure their instance with a .env file, and pass it in to podman compose with --env-file   (pydantic-settings should support natively, but podman just might make it part of the environment so it doesn't matter. Haven't tested this)
(Optional) Somehow expose command line arguments to the user outside of podman compose up so the user can override things to their heart's content

Thoughts?

To clarify, the crux of the issue is that you need to have some way to pass in config through podman compose to the main program. Whether that's a build/config.toml, environment variables, or a .env file, there's no way to avoid it.
We would basically be swapping out the build/config.toml approach with a .env approach. So the config file:
[models]
provider = "ChatIBMGenAI"

[models.args]
model_id = "mistralai/mixtral-8x7b-instruct-v01"

would become:
KAI__MODELS__PROVIDER = "ChatIBMGenAI"
KAI__MODELS__ARGS__MODEL_ID = "mistralai/mixtral-8x7b-instruct-v01"

I don't know if I would want to remove a config file. Env vars in the Windows world are a lot harder to work, IIRC.
In Podman compose, can you not mount the configuration file?

Closing in favor of a different approach


Update k8s.io/ja/docs/home/supported-doc-versions/

This is a...

[x] Feature Request
[ ] Bug Report

Problem:
Outdated content content/ja/docs/home/supported-doc-versions.md.
content/en/docs/home/supported-doc-versions.md 4 insertion(+)

Proposed Solution:
Update content content/ja/docs/home/supported-doc-versions.md.
For details, please execute the following command.
git diff 551489f 7b07d19 -- content/en/docs/home/supported-doc-versions.md

Page to Update:
https://kubernetes.io/ja/docs/home/supported-doc-versions/

これやります

/close


tinymist Disconnection on nvim-lsp

Describe the bug
A clear and concise description of what the bug is.
Package/Software version:
VSCode version(Help -> About):
Version: 1.81.1
Commit: 6c3e3dba23e8fadc360aed75ce363ba185c49794
Date: 2023-08-09T22:18:39.991Z
Electron: 22.3.18
ElectronBuildId: 22689846
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.4.12-x64v4-xanmod1

tinymist extension version: v0.11.0. Get it by tinymist --version in terminal.
tinymist
Build Timestamp:     2024-03-22T02:18:18.207134800Z
Build Git Describe:  v0.11.1-rc2-5-gf0a96cb-dirty
Commit SHA:          f0a9...
Commit Date:         None
Commit Branch:       None
Cargo Target Triple: x86_64-pc-windows-msvc
Typst Version:       0.11.0

Logs:
tinymist server log(Output Panel -> tinymist):

tinymist client log(Help -> Toggle Developer Tools -> Console):

Additional context
Add any other context about the problem here.

Can you provide the Log for Tinymist, you can find it with the command LspLog or at ~/.local/state/nvim/lsp.log since you seems to be using Neovim.

The second screenshot hints that there is some misconfiguration happening, e.g. wrong position encoding handshaking.

The configuration bias is UTF-8

Possibly duplicate of #766. But whatever, for specific bug, it might be #766; to run tinymist in neovim, most users should be able to solve it by search solutions by google.


Persist placement and post records with flat structure

Placement and Posts should be persisted when received.
Use custom converters to allow the object data to be stored in a flat structure within mongo, rather than as a "data" sub-document of the placement/post.

I'll split this PR, since some of it is a bit opinionated.

I'll split this PR, since some of it is a bit opinionated.


Code highlight broken since sublime text 3 Build 3112 update

Do i am the only one ?

Same thing here.

Same here.

Oh, yea, it's not only me.

I reverted to 3111 until this issue is fixed.

@ivandoric link? i couldn't fit it on their site

https://download.sublimetext.com/Sublime Text Build 3111.dmg  -- But as I saw just now 3113 is out maybe that would fix things.

Thanks. No it's not fixing things the newest one.

@Jaspur Thanks. Good to know.

I'm using 3113 and it looks even worst, emmet is also broken on blade.

I'm also using 3114 and it is indeed completely broken

Issue still exists in 3114, single quotes inside text (eg. between

 tags) are also being parsed as PHP:

+1. It seems the plugin would parse anything as PHP code until it meet some punctuation sign like ' or .

same here! :(

the same 😞

Yup, same thing here for me (Sublime Text 3, Build 3114) on Mac OS X 10.10.5 (if it matters). Rolled back to build 3103 to make it work again.

@medalink, its still broken here...

rolling back doesn't seems to be a right way to fix this, did you tried to understand from where the issue came from ?

@medalink, seems to be fixed thx a lot !

fixed! thank you very much!

I'm still having a problem with this even after updating Line 43 in the blade.sublime-syntax


File handling modifications in tests

Hey, here is a tiny PR that opens files in the tests under 'with' statement (and there are some minor white space adjustments for flake8 happiness).
I tested this and it works on my local windows with multiprocessing off.

Note that in a lot of the "open()" statments there was an accompanying "close()", so those are just for aesthetics. But the "with open(stats_file) as csvfile:" was the one causing me problems.


User Flow

How are you expecting to interact with the user's wallet? Will the smart contract simply supply an address for the user to send dai to?

Hey, thanks for opening the first issue here  🤗
Users you mean the players right?
Basically yes. Though not all users need to have a wallet,  just the winners. So when a person is winning, he required to give his Ethereum address (if wasn't supplied before), and he'll get the reward. Until maybe we integrate with off-ramp providers like https://mooni.tech/.

Got it. I took a look at how you implemented the demo as well and now I understand. Maybe mooni.tech isn't necessary for this hackathon but it would be a great feature in the future. I'm implementing my chess tournament concept and hopefully I'll have a UI up by today. Are there any known issues so far with this repo that I can help with? Good work so far by the way

Sounds great :), yeah agree about Mooni.
I'm building now a more complicated demo as a showcase, and to understand the requirements better. Want to launch it this week.
As I deploy Genie, theoretically everyone can use it, though the registration of new user (game) is manually. Also I hesitate to run it on mainnet, IMO still not production ready.
So the most important thing is feedback. I want to have understand what game developers need to build it in a suitable way

I cant wait to see it. I'm close to having a working prototype on mine. First feedback would be to make a route for CreateGame where it can take care of game creation. Simple fix but it's way better than manually inputting game info.
Also what exactly is nextPrize() for?

Cool, please tell when it's ready!

First feedback would be to make a route for CreateGame where it can take care of game creation.

Exactly what I did today :). See the last commits.

Also what exactly is nextPrize() for?

nextPrize returns what's the prize now, meaning if someone  is winning right now that's gonna be his reward.. might be a bad name actually, better call it currentPrize..

@adrianv425 So closing this for now, feel free to open new issues and reach us :)


键盘输入缩进怎么取消。之前是界面平铺的输入框正好能看到。现在点击输入界面缩进了。不使用这种自动缩进的。

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

(BOOL)isAutoHandleKeyboardEnabled{
return NO;
}

(BOOL)isAutoHandleKeyboardEnabled{
return NO;
}

这个没有效果吗？


When a bot using a token receives a friend request, it crashes discord.js

Error happens at /lib/Client/InternalClient.js at line 87 and causes a "cannot read property 'add' of null" TypeError.
This is annoying because it means that people can intentionally crash your bot by sending it a friend request.

Because you're not using a bot account and only logging in with a token I'd recommend you just login with the email/password associated with it, it should prevent that issue from happen.

I have two bots, one that does use a bot account, and one that doesn't. I experience this bug on both.
I can change the one that doesn't use a bot account to an email/password combination and that does remove the issue, but this still leaves the other one vulnerable to crashes at any time.

I'd suggest updating to the latest indev build because I believe that this was recently fixed.

@Gorialis What version of the library are you using? I reported this issue weeks ago and it was fixed.

Updating to the latest indev build seems to have fixed the issue, so it seems like the issue is only present on the master branch. Thanks for the help!


Update Use-local-resources-on-Hyper-V-virtual-machine-with-VMConnect.md

Added Windows 11 as supported OS for this feature.

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

#sign-off


[SE-0306] Require 'nonisolated' on lets for synchronous cross-actor access

@swift-ci please smoke test and merge


revert: use API local cluster URLs

Summary
Switch back to using the local Kubernetes cluster URL
for API access.  This impacts which API is used by services
like admin and the document-download-api.
The reason for this revert is that a few issues have been
discovered and fixed with admin using the Lambda API and
although all appears to be working as expected, we'd like to
eliminate variables for tonight's maintenance window.
Related

#1053

What are you changing?

[ ] Releasing a new version of Notify
[x] Changing kubernetes configuration

Provide some background on the changes

Give details ex. Security patching, content update, more API pods etc

If you are releasing a new version of Notify, what components are you updating

[ ] API
[ ] Admin
[ ] Documentation
[ ] Document download API
[ ] Document download frontend

Checklist if releasing new version:

[ ] I made sure that the changes are as expected in Notify staging
[ ] I have checked if the docker images I am referencing exist

[ ] api lambda (requires Notification-Production / AdministratorAccess login)
[ ] api k8s
[ ] admin
[ ] documentation
[ ] document download API
[ ] document download frontend

Checklist if making changes to Kubernetes:

[ ] I know how to get kubectl credentials in case it catches on fire

After merging this PR

[ ] I have verified that the tests / deployment actions succeeded
[ ] I have verified that any affected pods were restarted successfully
[ ] I have verified that I can still log into Notify production
[ ] I have verified that the smoke tests still pass on production
[ ] I have communicated the release in the #notify Slack channel.

Diff output for the .env changes:
make diff-staging
< API_HOST_NAME=https://api.staging.notification.cdssandbox.xyz
---
> API_HOST_NAME=http://api.notification-canada-ca.svc.cluster.local:6011

make diff-production
< API_HOST_NAME=https://api.notification.canada.ca
---
> API_HOST_NAME=http://api.notification-canada-ca.svc.cluster.local:6011


Update CODEOWNERS file

Hello,
Since you're now maintaining the project, you might want to change the CODEOWNERS file so you get review requests sent to you instead: https://github.com/iTrooz/efiboot-rs/blob/0caadaeb56d8fed5a452cebf97c51cdc18de4300/CODEOWNERS#L1
Best regards

Oops, I'm going to do that ASAP, thanks


addCheckConstraint fails for CockroachDB with java.lang.IllegalStateException

Environment
Liquibase Version: 4.10.0
Liquibase Integration & Version: CLI
Liquibase Extension(s) & Version: N/A
Database Vendor & Version: CockroachDB v21.2.10
Operating System Type & Version: Windows 10
Description
An error occurs when running update or update-sql for changeType addCheckConstraint against a CockroachDB target database
Steps To Reproduce
<changeSet  author="liquibase-docs"  id="addCheckConstraint-example">
    <pro:addCheckConstraint
            constraintName="id_in_range"
            disabled="true"
            schemaName="public"
            tableName="department"
            validate="true">id >= 100</pro:addCheckConstraint>
</changeSet>

CLI: update or update-sql
Actual Behavior
Following error is returned:
Unexpected error running Liquibase: Migration failed for change set myChangeLog.xml::addCheckConstraint-example::liquibase-docs:
Reason: java.lang.IllegalStateException: Cannot find generators for database class liquibase.database.core.CockroachDatabase, statement: com.datical.liquibase.ext.storedlogic.checkconstraint.change.DisableCheckConstraintStatement@a20b94b
Expected/Desired Behavior
Either:
(a) The command creates/runs the SQL to create a check constraint, or
(b) A clear error is printed explaining why the change cannot be deployed
Screenshots (if appropriate)
If applicable, add screenshots to help explain your problem.
Additional Context
Removing the property disabled="true" allows the update-sql or update to complete successfully, so the error message should be something like:   disabled attribute is not supported for CockroachDB

@nvoxland said this was related to a pro-feature; I will discuss with @mariochampion

Similar error is returned for PostgreSQL:
Unexpected error running Liquibase: Migration failed for change set myChangeLog.xml::addCheckConstraint-example::liquibase-docs:
Reason: java.lang.IllegalStateException: Cannot find generators for database class liquibase.database.core.PostgresDatabase, statement: com.datical.liquibase.ext.storedlogic.checkconstraint.change.DisableCheckConstraintStatement@3506d826


Pre-fill credentials on admin panel onboarding

It is hard to find the credentials in the page.
We could create an env variable (in .env) that tells the client that it has to suggest the default admin user in the login page fields
It is true on stackblitz demo but also on local install

@brunobuddy What about those who will create other accounts? Will they be prefilled with the admin credentials? It seems strange to me.

@SebConejo the seeder always create an<EMAIL_ADDRESS>user so every DB seeded in local/stackblitz/contribution will include the<EMAIL_ADDRESS>admin


Google API client is out-of-date and a security risk.

The included Google API client lib/Google is recently out-of-date and tripping a Dependabot security warning. The composer/composer included in this dist is v1.10.26 and the patch is included in v1.10.27.
https://github.com/advisories/GHSA-jm6m-4632-36hf
Downloading the currently available Google library brings this package up-to-date -- it's just not included in this released wp-stateless package.
Thank you :)

Same issue with another Google dependency: phpseclib/phpseclib is out of date in this download.
https://github.com/advisories/GHSA-jpr7-q523-hx25

Hello @doubleforte
It will be updated in next release.

Hello @doubleforte
Updated Google API client was released with version 3.3.0.

Closing the ticket.


Lab 3 Missing test

Not entirely sure if there is no point for a test.

Yep, there was supposed to be a test. I've added one in. Thanks for identifying this. 3 points


webpack issues a HTTP request with wrong chunk URL under certain circumstances

webpack version: 4.42.0
This is a very complex bug: when app has multiple entrypoints, has a separate runtime for each entrypoint, there is an async module that's also loaded statically by one of the entrypoints, and the splitChunks optimization decides to lay out shared chunks is a certain way, then the compiled app will:

issue a HTTP request for the async module although it already has it available statically
the HTTP request will have incorrect URL: it will use the numeric (natural) ID of the module instead of the chunk name

The result is a runtime error: 404 response from server and the import() returns a reject promise with Loading chunk { id } failed error.
The expected behavior is that the request is not issued at all.
This is extracted from a large app with thousands of modules (Calypso) and I don't have a minimalistic reproduction case that would really fail. The trouble with the example I'm presenting below is that I'm unable to trick webpack to split the shared chunks in exactly the way I need.
But I know enough about the bug, and can reason about what's wrong, to warrant a report and discussion:
Entrypoint 1:
import 'react';
import './async';
import './load-async';

Entrypoint 2:
import 'react';
import './load-async';

Entrypoint 3:
import './load-async';

async module:
import 'react';

Common load-async module that dynamically imports the async module:
import(/* webpackChunkName: "async" */ './async');

Now, let webpack produce five chunks from this:

entry-1: contains modules entry-1, load-async and async
entry-2: contains modules entry-2 and load-async
vendors~entry-1~entry-2: contains module react (shared vendors chunk)
entry-3: contains modules entry-3 and load-async
async: contains modules async and react

webpack decided to ship react twice: once in a shared chunk, and once in the async module. Depending on the various optimization thresholds (min/max size, max parallel requests, ...) this can certainly happen.
When building the chunk graph, webpack figures out that the chunk group entry-1 includes all modules from chunk group async (thanks to the static import of async), and therefore it doesn't connect these groups: entry-1 doesn't have async as child.
That means that the function jsonpScriptSrc generated in the runtime doesn't have a record for the async module that would map its numeric ID to the chunk name. If the async chunk has id=6, and the file name is async.js, then:
__webpack_require__.e(6)

will issue HTTP request for file 6.js, which doesn't exist. That can cause a runtime error: Loading chunk 6 failed.
Webpack has an optimization that should prevent this most of the time: the FlagIncludedChunksPlugin. That plugin should figure out that entry-1 is a superset of async and push the ID of async to chunk.ids of  entry-1. Then, when generating the runtime for entry-1, the installedChunks map would contain the ID of async from the very beginning, and __webpack_require__.e would always detect it as loaded and never issue an actual HTTP request.
Alas, that optimization fails here, because entry-1 chunk is not a superset of the async chunk: the react module is not in entry-1, but in the shared chunk!
If it compared the chunk groups instead, like buildChunkGraph does, then it would discover that chunk group entry-1 is a superset of chunk group async. Comparing chunk groups and chunks yields different results.
There are few necessary conditions to trigger this bug:

webpack must generate a custom runtime for each entrypoint. If we specified runtimeChunk: 'single', the ID -> name map in jsonpScriptSrc would have a record for async, because it would be forced by another entrypoint that doesn't import async statically.
the dynamic import must be done in a common module imported in multiple entrypoints. Otherwise, webpack would replace __webpack_require__.e(6) with a simple Promise.resolve()
the entry-1 entrypoint must also include another async module that's not statically available. Other wise, webpack would detect that the __webpack_require__.e code is not really used and the implementation would be a stub that returns Promise.resolve()

I understand the problem. The runtime knows that this chunk does need to be loaded, but the module code

/cc @jsnajdr Can we close?

This is still a huge problem, but I don't have a good idea to solve that yet.

Is this still a problem under Webpack 5

fixed by #11489


Add requirements file and check if this makes sense as an installable package

Added requirements file here https://github.com/JanEricNitschke/csgoml/commit/cad182d428132ed6f8d29290423ce4d7b93478a7 and restructured repo as package here https://github.com/JanEricNitschke/csgoml/commit/3b98b784f0d2535f5526c4a2c0ae8851089719a3


feat: [IDP-3402]: Added the docs on delegate proxy

Description

Please describe your changes: Added the docs on delegate proxy
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[x] Successful preview build.
[x] Code owner review.
[x] No merge conflicts.
[x] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66bb59faab60232594659a2f--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66bcbc2b9028aea1fa53729c--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66bcbe5a450da3b3db65c4f2--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66bcbe73450da3b40e65c42c--harness-developer.netlify.app

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: Debanitrkl:x: OrkoHunterYou have signed the CLA already but the status is still pending? Let us recheck it.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66c30b87d9e6ac8bd47390ec--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66c312cbac8fdbc81b807940--harness-developer.netlify.app


heroic: don't use the kdialog top-level alias

https://hydra.nixos.org/log/ygsis1s955063im3i37cqwb9grfjyfsz-nixpkgs-release-checks.drv
(this only expands the alias, nothing gets rebuilt)

Now I re-checked the whole tarball job locally, too.


API Call - 400 Bad Request on oauth/token

Hi,
I am using the java code to obtain the access token. When I use the configuration with a particular User ID, I am able to generate the access token and all remaining tasks work fine.
When I create a new User with same role, under same Account, I am receiving "400 Bad Request on oauth/token" error.
Both users have admin access, even the consent is provided. But no idea why for any new user, the API call fails.
On reverting to the old user, I get the expected results.
Any help would be appreciated.

Ok, the next step is for you to print out the entire response object when your call fails.
The response object will include both an error code and an error message.
Once we have the error code and message, we can figure out how to solve the problem.
Also, what OAuth flow are you using? JWT or Authorization Code grant?

I was using the JWT.
The issue got fixed after I revoked the consent and provided the consent again.
Regarding the message, point taken.
Thank You Larry.


Ydb Выблов Глеб P33202

Changelog entry
...
Changelog category

New feature
Experimental feature
Improvement
Performance improvement
Bugfix
Backward incompatible change
Documentation (changelog entry is not required)
Not for changelog (changelog entry is not required)

Additional information
...

lgtm


fix: ignore global flag on regexp topic

closes #1619

@Nevon @tulios I would appreciate it if you took a look at this whenever you have a free minute?


Simplify http.balancer.service configuration

The balancer config parsing currently enforces that every thing in the accept and connect url hostname of the accept and balance url.  However, the default behavior of the client redirect policy is to not load balance on different hostnames.
This enforcement was done because in the future we want load balancing to point to a direct url, i.e. gateway.example.com. And then individual nodes will be balanced via a prefix domain, such as node1.gateway.example.com.
Due to the issue in paragraph one we should remove the check and allow configuration of the balancer service has done in the past.  This should be a high priority story.
Next, we should add a feature to configure load balancing in the service directly.  More details to come in story, but high level is that this will deprecate the balancer service config.  Instead balancing will be implicit with an http accept options such as http.node.url (name to change, ping @robinzimmermann for link to design doc or better name).  That http.node.url will need to be the hostname that the service will directly reference.  I.E node1.gateway.example.com in the example above.  This new implementation would ideally, not use the balancer service.
The doc should deprecate the old way.

Make sure that the design for this will fix the following bug

This issue will no longer be solved. closing for now


Update README.md

This is my commit message
Signed-off-by: Vineeth Reddy<EMAIL_ADDRESS>Good to have a badge to the latest release for Prometheus docs

See #1285


Remove test:=true references

Currently our dockerfile setup_script has a number of aliases for our old way of testing. These should be updated to reflect current rostest usage. In general anything that mentions the rosparam test (usually test:=true) should be updated/fixed.
https://github.com/interaction-lab/HARMONI/blob/609f52a21000d0884ac1654464dbc525e34d0145/dockerfiles/config/setup_script.sh#L24

Also we appear to still have old references to test in the harmoni_decision package which need to be refactored. @micolspitale93 have you updated harmoni_decision in your fork to ensure the launcher.py works correctly with the new launch files?

@chrismbirmingham I promise to work on both this issue and the cordial face stuff asap.

I have addressed this issue in pull request #60


User Pool already has domain configured

I deployed the cdk app from the TS directory. Every stack completes until it gets to the FrontendStack which fails when it tries to addDomain to the existing user pool created in the AuthenticationStack.
If I look at the user pool in the AWS Cognito web console, it has the domain: https://serverless-chat-users.auth.ap-southeast-2.amazoncognito.com which wouldn't be globally unique, and also causes the FrontendStack to fail deployment. Have I missed something?

My mistake! It turns out I've actually deployed this sample once before, a long time ago and I must have used 'serverless-chat-users' as the prefix.


Update dhruv8433_pr.md

All merged pr you give me points
now only left unmerged 9 pr's
i will group it in 3-3
My unmerged pr

https://github.com/HimanshuNarware/Devlabs/pull/2897
https://github.com/HimanshuNarware/Devlabs/pull/2894
https://github.com/khushi-joshi-05/Food-ordering-website/pull/1587
https://github.com/Counselllor/Counsellor-Web/pull/1316
https://github.com/Counselllor/Counsellor-Web/pull/1296
https://github.com/pooranjoyb/popShop/pull/320
https://github.com/Rajan-Barnwal/jobproject/pull/360
https://github.com/JiyaGupta-cs/ShopNex/pull/353
https://github.com/omrajsharma/bigohhh.com/pull/87

@sanjay-kv
please review it


high CPU in envoy 1.16.0

After creating some listeners, we saw a spike in the CPU usage of envoy to 600% (8 cores), although there was no traffic.
The listeners we created were set to serve ports that were taken by another process (that eventually released them). Although we created 6 listeners, that serve 6 different ports, we only saw envoy listening to 3 ports.
We didn't have cpu profiling enabled and it's not reproducible, but we do have strace logs that show envoy's workers performing this in a loop, which we think causes the CPU spike:
epoll_wait(41, [{EPOLLHUP, {u32=57, u64=57}}, {EPOLLHUP, {u32=58, u64=58}}, {EPOLLHUP, {u32=59, u64=59}}], 32, 44) = 3
accept4(57, 0x7f458aad5070, 0x7f458aad5008, SOCK_NONBLOCK) = -1 EINVAL (Invalid argument)
accept(57, 0x7f458aad5070, 0x7f458aad5008) = -1 EINVAL (Invalid argument)
accept4(58, 0x7f458aad5070, 0x7f458aad5008, SOCK_NONBLOCK) = -1 EINVAL (Invalid argument)
accept(58, 0x7f458aad5070, 0x7f458aad5008) = -1 EINVAL (Invalid argument)
accept4(59, 0x7f458aad5070, 0x7f458aad5008, SOCK_NONBLOCK) = -1 EINVAL (Invalid argument)
accept(59, 0x7f458aad5070, 0x7f458aad5008) = -1 EINVAL (Invalid argument)
epoll_wait(41, [{EPOLLHUP, {u32=57, u64=57}}, {EPOLLHUP, {u32=58, u64=58}}, {EPOLLHUP, {u32=59, u64=59}}], 32, 44) = 3
accept4(57, 0x7f458aad5070, 0x7f458aad5008, SOCK_NONBLOCK) = -1 EINVAL (Invalid argument)
accept(57, 0x7f458aad5070, 0x7f458aad5008) = -1 EINVAL (Invalid argument)
accept4(58, 0x7f458aad5070, 0x7f458aad5008, SOCK_NONBLOCK) = -1 EINVAL (Invalid argument)
accept(58, 0x7f458aad5070, 0x7f458aad5008) = -1 EINVAL (Invalid argument)
accept4(59, 0x7f458aad5070, 0x7f458aad5008, SOCK_NONBLOCK) = -1 EINVAL (Invalid argument)
accept(59, 0x7f458aad5070, 0x7f458aad5008) = -1 EINVAL (Invalid argument)

We think that the missing 3 ports are those mentioned by this strace. By envoy's logs, these listeners were created successfully.
In our scenario, the other process stops serving these ports and envoy starts to - but these events are asynchronous so there's a period of time (several seconds) where envoy tries to bind the ports and gets refused by "address already used" - but we only saw it for the "good ports", and didn't saw it for the ports that it did not serve (for them we only saw a successful log for the creation of the listeners).
The question is - could envoy possibly create the listeners and think it binds the port although it's unsuccessful, that could lead to the above loop?
Running envoy 1.16.0 on ubuntu 16.04.

another important note I forgot to mention: when restarting envoy, everything worked correctly - we saw it serves all the ports, and the CPU usage dropped.

another important note I forgot to mention: when restarting envoy, everything worked correctly - we saw it serves all the ports, and the CPU usage dropped.

Port used by other process makes this messy. Envoy won't repeatedly try listen on the port. Also reuse_port determines Envoy create (then bind and listen) socket once, or create N server socket where N=number of workers.
What is the reuse_port value within your listener config?

Port used by other process makes this messy. Envoy won't repeatedly try listen on the port. Also reuse_port determines Envoy create (then bind and listen) socket once, or create N server socket where N=number of workers.
What is the reuse_port value within your listener config?

If a different process is listening on a port, I think Envoy should have failed either at startup or rejected config since port is not available to listen.
EPOLLHUP events on fds that we are later calling accept on doesn't sound healthy.  I think it explains the CPU spin behavior: epoll_wait immediately returns EPOLLHUP on the invalid listen sockets.  Envoy should at the very least close the listen sockets that failed during initialization, not register them with the event loop.
An strace that covers the listener creation failure may aid with debugging.

If a different process is listening on a port, I think Envoy should have failed either at startup or rejected config since port is not available to listen.
EPOLLHUP events on fds that we are later calling accept on doesn't sound healthy.  I think it explains the CPU spin behavior: epoll_wait immediately returns EPOLLHUP on the invalid listen sockets.  Envoy should at the very least close the listen sockets that failed during initialization, not register them with the event loop.
An strace that covers the listener creation failure may aid with debugging.

reuse_port is set to False. Since we cannot reproduce to issue, I don't have strace logs from the listener creation.
Until this issue is resolved, we will try to perform a cleaner transition between the other process and envoy, not making envoy to bind ports that are still in use.

I'm meeting the same.  It's can reproducible with following steps:

start envoy with listening port 80 and set reuse_port is true.
start new envoy with listening port 80 and set reuse_port is false.
then we can see high CPU in new envoy workers.

/reopen


Stop scanning home directory for projects

Summary:
Our philosophy around state persistence recently changed.
Before, we wanted to treat state as ephemeral; you could clear state whenever you wanted, and Guppy would try and rebuild itself magically.
Now, we realized a better state is just to make state-persistence more dependable, so that the user should never have to clear state. They still can if there's an issue, but it should be less common, and so it doesn't matter so much if it's slightly more inconvenient.
As a result, we no longer want to scan and automatically add projects found in the projects directory.
This change brings a few benefits:

No more weirdness with onboarding when clearing state
Deleting projects from guppy, but not from disk, will be possible now!
No weirdness around changing home directory
I believe this will fix #173, although I can't be sure.

Should I still lose all previous projects from Redux state when updating to this? The sidebar weirdness is mostly fixed, but my 2 previous test projects are just absent from the state. In addition, I'm still getting this error when clicking on a project icon in the Sidebar:

Should I still lose all previous projects from Redux state when updating to this? The sidebar weirdness is mostly fixed, but my 2 previous test projects are just absent from the state.

Yeah, so I think we'll have a single release that "forgets" about projects and people will have to re-import them. There might be a way around this, but I'm not confident we have the userbase at this point for it to be worth the trouble.
The good news is that after the next release, 0.3, we'll have migration strategies in place that it shouldn't ever happen again :)

What about the counterpart to your benefit, when a project is deleted from the disk but still present in Guppy? We'd probably need to check and notify the user if this is the case.

Ahh that's a good catch. Yeah, I'll update this to still filter out any projects no longer on disk.

So I'm back from vacation and tested your branch with-out scanning.
I haven't tested a lot but what I noticed is that if the user will create the same project if it is already existing in Guppy directory there is no notification and it will override the project. Maybe we should create a check that the directory already exists and make a notification something like There is already a project named ProjectName. Do you like to import it?
Also what do you think, we could make migration easier for existing users so they're getting an info about the existing projects (only on first load after installation) so they can decide if they want to import them. I think no info is a bad UX for existing users - not sure how large the user base is at the moment.
Or is any loading of projects from disk a problem? Then we should make importing multiple existing projects easier.
For new users there won't be any project scanning because Guppy directory is empty on start.
Beside this the app starting after creating & importing some projects is working as expected. I'll do a review of your code changes soon.

Also what do you think, we could make migration easier for existing users so they're getting an info about the existing projects (only on first load after installation) so they can decide if they want to import them. I think no info is a bad UX for existing users - not sure how large the user base is at the moment.

So I think as discussed in #178, I'm gonna try and preserve state for existing users. I don't actually think it'll be that tricky, now that I think about it.
I'm also not sure how large the userbase is! There isn't any sort of tracking at the moment. Do you think we should add some? I wonder if there are privacy implications to adding Google Analytics to a desktop app...

What about the counterpart to your benefit, when a project is deleted from the disk but still present in Guppy? We'd probably need to check and notify the user if this is the case.

@superhawk610 I just realized we're still checking for this :) that check is in loadGuppyProjects, which is still run.
It fails silently right now, though, by just omitting the project. It would be great to add an alert about it.

(merging this in so that @superhawk610 can be unblocked on #181. Let me know if any concerns weren't addressed)


grt: fix duplicated points on edges

Fixes OR-1652

Looks ok. Have you done a secure CI?

Public CI finished with these two failures:
asap7 aes (base)
 Flow reached last stage.
 Found 1 metrics failures.
     [ERROR] finish__timing__setup__ws fail test: -24.3564 >= -20.0

asap7 sha3 (base)
 Flow reached last stage.
 Found 2 metrics failures.
     [ERROR] finish__timing__setup__ws fail test: -127.984 >= -32.5
     [ERROR] finish__timing__wns_percent_delay fail test: -17.950438 >= -13.53

Waiting for the private ci now.

@maliberty After merging the latest master branch, public and secure ci are green.


Yellow Screen Freeze 11.10

After extracting all the files in the given FBI.zip file to the SD Card, whenever I would open up the Hombrew Launcher, it would freeze on a yellow screen. I then deleted the FBI.3dsx file from the 3ds folder and put it in the 3ds. When I opened up the Hombrew Launcher, it ran just fine.

Have you checked your SD card for file system issues? The FBI 3dsx has not been changed at all recently, so I fail to see how it would be bad in any way.
As a side note, I don't really activrly support running FBI as a 3DSX outside of Luma3DS anymore.

Hello, I am getting the same issue. and all I've done is take a plain old 3ds, add hombrew and the fbi folder with the file. I get the same issue.

If you're trying to launch FBI via a game exploit outside of CFW, I would strongly recommend you install Luma3DS instead and use its built-in homebrew launcher support. FBI isn't really capable of much outside of CFW, as it lacks a lot of system permissions and can't install unsigned CIAs.


Report routes

reports are now working, the routes will need to be improved, UI on report page also needs to be looked at

Your Pull Request code is being promoted!  Please follow the link below.
Main Merge Workflow


Unhelpful link

Link in "see Test Signing a Driver" goes to the top level document (https://docs.microsoft.com/en-us/windows-hardware/drivers/), which is not very useful, considering the written topic of the link. It is almost as useless as linking to "goole.com" to search for ore info about different types of fruit flies.

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

ID: f26b5537-027d-6253-2d92-cd0bb230bfd8
Version Independent ID: 6a7fdcc8-2c94-4aa2-94a7-8289946b63bf
Content: Release-Signing Driver Packages - Windows drivers
Content Source: windows-driver-docs-pr/install/release-signing-driver-packages.md
Product: windows-hardware
GitHub Login: @tedhudek
Microsoft Alias: tedhudek

Fixed in source. Should be live shortly.


[Quick Event] Extension doesn't create event

Extension
https://www.raycast.com/mblode/quick-event
Description
Error: Wrong (Incorrect) Index (-1719)
Steps To Reproduce

write event info
press enter
got error

Current Behaviour
raycast window closes, but event isn't created
Expected Behaviour
raycast window closes, but event is created

@raycastbot close this issue


while using async_execution=True in task

.Python.3.10_3.10.3056.0_x64__qbz5n2kfra8p0\lib\concurrent\futures\thread.py", line 169, in submit
raise RuntimeError('cannot schedule new futures after '
RuntimeError: cannot schedule new futures after interpreter shutdown

Hey @aman-vink can you share some of the code so we can try to replicate locally?