TypeScript: Workaround to npm link

RxJS version:
N/A
Code to reproduce:
npm link one project that is using rxjs with another project.
Expected behavior:
TypeScript Compiler should not throw errors
Actual behavior:
TypeScript Compiler does throw errors
Additional information:
There are problems when using rxjs with tools like npm link that cause the compiler to fail to resolve types properly and create lots of compiler errors, as it sees two copies of the same class, and they are not compatible.
Workaround
I've found a workaround when using TS 2.0+ that appears to solve this problem, and it's fairly easy to configure.
Based on this information, we can use the new path based mapping to solve the problem.
Adding the following to your tsconfig will make the issue go away, assuming your using the new TS 2.0 beta or the nightlys.
    "compilerOptions": {
        "baseUrl": "",
        "paths": {
            "rxjs": ["node_modules/rxjs"]
        }
    }

Related Issues
https://github.com/Microsoft/TypeScript/issues/6496
https://github.com/Microsoft/TypeScript/issues/7755
https://github.com/ReactiveX/rxjs/issues/1744
cc @blesh @robwormald @kwonoj @staltz
cc @mhegazy @ahejlsberg - maybe this can be fixed easily in the compiler?  :pray:
While this work around works, it's fairly painful that we have to make these changes, and post these work arounds.
Are there other simpler fixes?  Can the compiler emit an identifier in the .d.ts files that so that it knows "hey this module is equal to this other module"?

Is this something we should add to https://github.com/ReactiveX/rxjs/blob/897fe3b16a957b8808089379dfabdfd80b00509a/doc/installation.md or something else?

I'm not sure this is an issue with RxJS. Sounds like a TypeScript issue from the description

as expressed my opinion on #1744, I also think this is mostly compiler behavior and not to be handled in RxJS code implementation (or documentation). Someone might use those as tips but wouldn't to be included in repo. what do you think, @david-driscoll ?

npm link should work in TS 2.0.3 (see the change in https://github.com/Microsoft/TypeScript/pull/8486). there are other issues with symlinks in general that we plan on addressing for TS 2.1 namely (https://github.com/Microsoft/TypeScript/issues/11613, https://github.com/Microsoft/TypeScript/issues/11107, https://github.com/Microsoft/TypeScript/issues/10364, https://github.com/Microsoft/TypeScript/issues/9552, and https://github.com/Microsoft/TypeScript/issues/9091).
Can you share some repro steps to get to the issue described above, these are probably bugs that need to be fixed.
https://github.com/Microsoft/TypeScript/issues/6496 (and its predecessor https://github.com/Microsoft/TypeScript/issues/7755) are not about sym links, they are about treating diffrent versions of the same library as the same for assignment compat purposed for privarte/protected properties. i do not think there is an argument when they are exactly the same file on disk.

@mhegazy I'm still having problems with TS 2.0.3.  Where I used to get this error, now the compiler hangs for a long time and then crashes with a CALL_AND_RETRY_LAST Allocation failed error.  Does TS 2.0.3 resolve this issue for anybody else?  Maybe there is some other issue with my  environment.

@david-driscoll, your fix seems to have addressed the issue I'm having.  Thanks!  I'll need to try more things to be sure, but for sure it solves the crash I described in my previous comment to @mhegazy.

@xogeny can you share a project i can look at?

@mhegazy I tried to create a simple case.  So far, no luck.  It builds just fine for the simple case.  I understand that without a reproducible case, there isn't much you can do.  I wonder if @david-driscoll might have one?
Given my experience with the simple case, I'll try to figure out what is different between that case and the case that shows the issue.  But I'll have to work it into my other work.  But I'm 100% sure that with 2.0.3, the compiler crashed but then worked if I did the fix above.

yeah, i could not get this to repro locally, so i assumed it is working :)
if you can not share a sample, a directory structure + tsc --diagnostics output might be helpful. also try running tsc --listFiles and see if there are files that should not be there, then we can work backwards from there and see how/why they were including using tsc --traceResolution.

@mhegazy So I tried these suggestions.  The --diagnostics and --listFiles simply do not work because the compiler goes into some kind of infinite recursion or something and crashes before generating any output.  However, the advantage of --traceResolution is that it provides continuous output (before crashing).
I did a --traceResolution with and without the paths fix above.  There is a lot of output to sift through there, but I did a diff of the output across both cases.  As you might expect, the one with the paths setting in tsconfig.json doesn't do much "searching" for rxjs.  The other includes lots of additional output about searching for rxjs related files.
Apart from resolving the rxjs stuff differently (and they both do resolve it), they seem to be identical.  But one thing to note is that the "crash" of the compiler does not occur during this resolution phase, but later (no output during that phase, so I'm not sure what the compiler is doing then).
One thing to note.  If I use npm link EXTERNAL_MODULE, I see this issue.  If, however, I do an npm install PATH_TO/EXTERNAL_MODULE, everything works fine (no crash). One thing I cannot help but notice is that with npm link, there exists a node_modules/EXTERNAL_MODULE/node_modules/rxjs directory.  But with npm install, it isn't there.  Furthermore, I can see that with --traceResolution, it is crawling through those files.
So the workaround works for me for now.  I may even switch to npm install in the future (not sure) just to avoid the workaround.  If you ever want to have a Skype session to explore this case more thoroughly and try and track it down further, just let me know.

@xogeny can you share a repro project?

@mhegazy Unfortunately, I cannot. This is work for a client, not an open source project. As I mentioned above, I tried to recreate the issue by creating other projects to mimic the structure of the repo that is showing this issue.  But that doesn't reproduce the problem.  After trying these CLI options, I still don't understand what it is that is special about this project.  I'm keeping my eyes open for things that might allow me to reproduce this in a simpler case.  But so far, no luck.

I'm closing this for now, as shared I don't feel this need to be handled in plain use case documentation scenario.


[FEAT]: UX: Set focus on new resource modal name input field

When a new workflow, model or code resource is created, the input field to name the resource needs to be in focus so that the user can name the resource without first clicking in the field.
The code to adjust is in **tera-save-asset-modal.vue**
I tried to fix this myself, but after tinkering with a number of potential solutions from searching on Google (and ChatGPT), nothing seems to work.

Was able to fix this issue, closing.


The real "value"

hi.
I want to know if there is a way to get the real value? "a"="s" -> a s
What we get now is  "a"="s" ->a "s"，we know that '""' is not part of the value.

hey, not sure exactly what you mean, but for values that are string you can use as_str() to remove the decoration part
https://docs.rs/toml_edit/0.2.0/toml_edit/enum.Value.html

hey, not sure exactly what you mean, but for values that are string you can use as_str() to remove the decoration part
https://docs.rs/toml_edit/0.2.0/toml_edit/enum.Value.html

I'm very sorry, I didn't notice the "as_str()" method, I just used "to_string()".

No worries :) I hope that answered your question. The documentation is definitely needs to be improved and examples to be added.
I'll close the issue, but feel free to reopen if you disagree.


Broken Connection on successive calls using add_bytes

I am attempting to debug an issue wherein I am pushing the binary image data represented in Python byte string into IPFS using ipfshttpclient.
I have been able to distill this down to an example with two successive calls of add_bytes with large byte strings:
import ipfshttpclient
import os

bytes = bytearray(os.urandom(100000))

IPFS_API = ipfshttpclient.Client(f"/dns/localhost/tcp/5001/http")
res1 = IPFS_API.add_bytes(bytes)
res2 = IPFS_API.add_bytes(bytes)

...produces:
Traceback (most recent call last):
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/requests/adapters.py", line 472, in send
    low_conn.send(i)
  File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 977, in send
    self.sock.sendall(data)
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/http.py", line 251, in _do_request
    return requests.request(*args, **kwargs)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/requests_wrapper.py", line 244, in request
    return session.request(method=method, url=url, **kwargs)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/requests_wrapper.py", line 223, in request
    return super(Session, self).request(method, url, *args, **kwargs)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/requests/adapters.py", line 498, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: [Errno 32] Broken pipe

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "pngpushtest.py", line 8, in <module>
    res2 = IPFS_API.add_bytes(bytes)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/utils.py", line 142, in wrapper
    res = cmd(*args, **kwargs)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/client/base.py", line 15, in wrapper
    result = func(*args, **kwargs)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/client/__init__.py", line 223, in add_bytes
    data=body, headers=headers, **kwargs)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/http.py", line 50, in wrapper
    return func(self, *args, **merged)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/http.py", line 370, in request
    files, headers, data, timeout=timeout)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/http.py", line 288, in _request
    timeout=timeout)
  File "/private/tmp/ipwb/ipwbve/lib/python3.7/site-packages/ipfshttpclient/http.py", line 255, in _do_request
    six.raise_from(exceptions.ConnectionError(error), error)
  File "<string>", line 3, in raise_from
ipfshttpclient.exceptions.ConnectionError: ConnectionError: [Errno 32] Broken pipe

Changing the above line to bytes = bytearray(os.urandom(10)), using 10 instead of 100000 does not produce this exception.

Python 3.7.2
ipfshttpclient 0.4.12

For completeness, before executing the above Python, I started the IPFS daemon locally:
$ ipfs daemon &
Initializing daemon...
go-ipfs version: 0.4.19-
Repo version: 7
System version: amd64/darwin
Golang version: go1.11.5
Swarm listening on /ip4/<IP_ADDRESS>/tcp/4001
Swarm listening on /ip4/<IP_ADDRESS>/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/<IP_ADDRESS>/tcp/4001
Swarm announcing /ip4/<IP_ADDRESS>/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/<IP_ADDRESS>/tcp/5001
WebUI: http://<IP_ADDRESS>:5001/webui
Gateway (readonly) server listening on /ip4/<IP_ADDRESS>/tcp/8080
Daemon is ready
$

This looks to have been introduced between ipfsapi 0.4.3 and 0.4.4.
With code (ipfsapitest.py):
import ipfsapi
import os

bytes1 = bytearray(os.urandom(100000))

IPFS_API = ipfsapi.Client('localhost', 5001)

res1 = IPFS_API.add_bytes(bytes1)
res2 = IPFS_API.add_bytes(bytes1)
print(res1)
print(res2)

❯ pip3 freeze
certifi==2019.3.9
chardet==3.0.4
idna==2.8
ipfsapi==0.4.3
requests==2.22.0
six==1.12.0
urllib3==1.25.3

❯ python3 ipfsapitest.py
QmQSC8UbweG16KBvvxVab526UP5wDuJsaZsTRPuFoHMdUF
QmQSC8UbweG16KBvvxVab526UP5wDuJsaZsTRPuFoHMdUF

...then updating to ipfsapi 0.4.4 with a fresh virtualenv (which seems to also install ipfshttpclient):
❯ pip3 freeze
base58==1.0.3
certifi==2019.3.9
chardet==3.0.4
idna==2.8
ipfsapi==0.4.4
ipfshttpclient==0.4.12
multiaddr==0.0.8
netaddr==0.7.19
requests==2.22.0
six==1.12.0
urllib3==1.25.3
varint==1.0.2

❯ python3 ipfsapitest.py
ipfsapitest.py:1: FutureWarning: The `ipfsapi` library is deprecated and will stop receiving updates on the 31.12.2019! If you are on Python 3.5+ please enable and fix all Python deprecation warnings (CPython flag `-Wd`) and switch to the new `ipfshttpclient` library name. Python 2.7 and 3.4 will not be supported by the new library, so please upgrade.
  import ipfsapi
Traceback (most recent call last):
  File "/private/tmp/ttt/lib/python3.7/site-packages/requests/adapters.py", line 471, in send
    low_conn.send(b'\r\n')
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 977, in send
    self.sock.sendall(data)
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/http.py", line 251, in _do_request
    return requests.request(*args, **kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/requests_wrapper.py", line 244, in request
    return session.request(method=method, url=url, **kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/requests_wrapper.py", line 223, in request
    return super(Session, self).request(method, url, *args, **kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/requests/adapters.py", line 498, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: [Errno 32] Broken pipe

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "ipfsapitest.py", line 9, in <module>
    res2 = IPFS_API.add_bytes(bytes1)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfsapi/client/__init__.py", line 205, in wrapper
    return value(*args, **kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/utils.py", line 142, in wrapper
    res = cmd(*args, **kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/client/base.py", line 15, in wrapper
    result = func(*args, **kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/client/__init__.py", line 223, in add_bytes
    data=body, headers=headers, **kwargs)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/http.py", line 50, in wrapper
    return func(self, *args, **merged)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/http.py", line 370, in request
    files, headers, data, timeout=timeout)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/http.py", line 288, in _request
    timeout=timeout)
  File "/private/tmp/ttt/lib/python3.7/site-packages/ipfshttpclient/http.py", line 255, in _do_request
    six.raise_from(exceptions.ConnectionError(error), error)
  File "<string>", line 3, in raise_from
ipfshttpclient.exceptions.ConnectionError: ConnectionError: [Errno 32] Broken pipe

Thanks you for this detailed analysis of the problem, unfortunately ipfsapi v0.4.3 and ipfsapi v0.4.4 (which is now a wrapper around ipfshttpclient) are really two different libraries. The versioning is somewhat deceiving here unfortunately, ipfshttpclient actually started with version 0.4.11 which is a lot closer to the truth.
If you have the time and knowledge, could you do a git bisect between master and 1b5b1c0911d32f963689ac04c2557a5dde7a17d8 on this repository and check which is the first commit that introduced this is issue? It would likely go a long way towards fixing this, but I don't really have the time right now unfortunately.

Sorry, I just noticed again that your originally did use ipfshttpclient, which is of course the way to go here – one less potential error source. :+1:
Unfortunately all that I said above of course applied to ipfshttpclient anyways, so nothing I suggested will change in practice I fear.

@alexander255 Thanks for the acknowledgement. I encountered this issue in attempting to update https://github.com/oduwsdl/ipwb to the latest, refactored, renamed ipfsapi (ipfshttpclient). I iteratively tested every prior version of ipfshttpclient then onto ipfsapi until I encountered the release that contained the above behavior.
I am not familiar with git bisect usage but this might be a good opportunity to become so. Given we heavily use ipfsapi in ipwb, it will be critical for ipwb to use the newer ipfshttpclient before ipfsapi stops receiving updates at the end of the year.

Using git bisect, 9edc945088faf5df66cab1845bd2c87c5bc77ede appears to be the commit where the issue is first exhibited.

stream_bytes(), which add_bytes() calls, differs between 9edc945088faf5df66cab1845bd2c87c5bc77ede, where add_bytes() first exhibited the above issue, and its parent commit 1b5b1c0911d32f963689ac04c2557a5dde7a17d8.
1b5b1c0911d32f963689ac04c2557a5dde7a17d8
stream = BytesStream(data, chunk_size=chunk_size)
return stream.body(), stream.headers

9edc945088faf5df66cab1845bd2c87c5bc77ede
stream = BytesFileStream(data, chunk_size=chunk_size)
return stream.body(), stream.headers()

Another finding, the headers in 9edc945088faf5df66cab1845bd2c87c5bc77ede contain "Connection: close" when in 1b5b1c0911d32f963689ac04c2557a5dde7a17d8 they do not:
9edc945088faf5df66cab1845bd2c87c5bc77ede
{'Content-Disposition': 'form-data; filename="bytes"', 'Content-Type': 'multipart/form-data; boundary="5f4d03ef9cd94920b38fd0401375e214"', 'Connection': 'close'}
{'Content-Disposition': 'form-data; filename="bytes"', 'Content-Type': 'multipart/form-data; boundary="38984c57f12f49cbb79c405e5b5128e6"', 'Connection': 'close'}
1b5b1c0911d32f963689ac04c2557a5dde7a17d8
{'Content-Disposition': 'form-data; filename="bytes"', 'Content-Type': 'multipart/form-data; boundary="1ae72c313dec4aceb349e85414acdaf2"'}

https://github.com/ipfs/py-ipfs-api/blob/4891d7239d99d98a778873146f8cd27d10a7925b/ipfshttpclient/multipart.py#L141-L143
...seems to be the source of the header mentioned above. https://github.com/ipfs/go-ipfs/issues/5168 has since been closed. Removing this explicit Connection header specification fixes the problem on my initial testing.

An optimistic update: I updated my go-ipfs to 0.4.21 and the original BrokenPipeError: [Errno 32] Broken pipe issue has disappeared. This whole issue may be moot if go-ipfs 0.4.21 is supported.
The README states that 0.4.20 is blacklisted but was the issue that caused it to be so resolved in 0.4.21, @alexander255? If so, we can proceed with migrating to ipfshttpclient with the insistence of a go-ipfs installation from ipwb users.
/cc @ibnesayeed

Thanks @machawk1, if the new version of this library works well with the new version of the go-ipfs then we can move on.

@machawk1: Thanks for your tremendously valuable research here! While, as @ibnesayeed found out, adding the header should not be a problem anymore, it's still an unnecessary performance penalty and I'm glad to here that this can be removed with go-IPFS v0.4.19+.
I will create a patch that removes the Connection: close flag for v0.4.19+ and would welcome your feedback on this.
The problem with 0.4.20 was that several API methods had returned broken or incomplete responses making it basically useless if you relied on any of these. Hence I decided to blacklist it altogether, rather than dealing with support queries that I can do nothing about anyways. (As such I don't think it was related to this, but maybe played a part as well.)

@alexander255 What sort of testing would be required to ensure this module's full functionality with go-ipfs v0.4.21+? Do the issues that prevent the recommendation of v0.4.20 also exist in v0.4.21?
Given add_bytes() does not work reliably against v0.4.19, it might be good to move to a more current version of go-ipfs that has some bugs fixed, inclusive of the connection closing issue discussed above.

Damn! Looks like I forgot the upload the changes I'm planning to land, somehow I thought them to already being released.
@machawk1: Please see and comment on #189. Thank you!
The issues in v0.4.20 were of a different nature, iirc  the daemon sent incomplete responses to several calls. I can look it up if you want to know more.

Support for 0.4.19 and below was dropped, so this isn't an issue anymore.


Query

Title: Meaning of some terms in the codebase
Description:
Just need to understand the below code - is it a copy constructor of C++? - the Listener Config part or is it pass by reference

and for the below, is this move constructor for unique_ptr along with template declaration?

Network::ListenerConfig& is passing an object by reference.
std:unique_ptr<GenericUpstream>&& is an rvalue reference, which enables using std::move to efficiently transfer ownership of the std::unique_ptr<GenericUpstream> to the called function.
In the future, please seek out a C++ forum for C++ questions, rather than opening issues with generic C++ questions here.


Adding x-ms-enum extension to a parameter does not populate in the schema

This is essentially a duplicate of #368, but I can't reopen that issue since I didn't create it. The creator of that issue had an idea why this was happening, which may help.
Here is a minimal example project demonstrating this (with .NET Core 2.0 and Swashbuckle 2.4.0):
SwashbuckleEnumTest.zip
It's a single controller with a single action:
[HttpGet]
public Color Get(Color color) {
    return color;
}

Where Color is an enum. And it uses this schema filter:
public class EnumTypeSchemaFilter : ISchemaFilter {
    public void Apply(Schema schema, SchemaFilterContext context) {
        var typeInfo = context.SystemType.GetTypeInfo();

        if (typeInfo.IsEnum) {
            schema.Extensions.Add(
                "x-ms-enum",
                new {
                    name = typeInfo.Name,
                    modelAsString = false
                });
        }
    }
}

I included the generated swagger.json file in the zip file. You'll see that it includes x-ms-enum with the return type, but not for the parameter.
"parameters":[
   {
      "name":"color",
      "in":"query",
      "required":false,
      "type":"string",
      "enum":[
         "Red",
         "Green",
         "Blue"
      ]
   }
],
"responses":{
   "200":{
      "description":"Success",
      "schema":{
         "enum":[
            "Red",
            "Green",
            "Blue"
         ],
         "type":"string",
         "x-ms-enum":{
            "name":"Color",
            "modelAsString":false
         }
      }
   }
}

If you look closely at the AutoRest docs, you'll see that x-ms-enum needs to be applied to Parameter objects in addition to Schema objects. You'll need to dig a little deeper into the Swagger specification to understand why this is the case but in summary non-body parameters (i.e. query, header etc) don't have an associated Schema. They just have the structure metadata baked directly into the Parameter object.
Anyway, you can solve your issue by adding a Parameter filter in addition to your Schema filter:
public class AutoRestParameterFilter : IParameterFilter
{
    public void Apply(IParameter parameter, ParameterFilterContext context)
    {
        var type = context.ApiParameterDescription.Type;

        if (type.IsEnum)
            parameter.Extensions.Add( "x-ms-enum", new { name = type.Name, modelAsString = false });
    }
}

Ahh, ok. That makes sense I guess. I didn't realize that a Parameter filter was a different thing. That works.
Thank you.

This doesn't seem to work for a parameter that is an array of enums. Any ideas? @domaindrivendev


Inside f-partial-nav the server-side redirects do not work.

lets say I have:
  <Partial name="user-feedback">
  </Partial>
  <form
    method="post"
    class="flex flex-col space-y-2"
    f-partial="/routes/submit"
  >

Then in the submit route:
// routes/submit.tsx
...
  async POST(req, ctx) {
    if (something) {
      return ctx.render(); // some partial here
    }
	else {
	    const headers = new Headers();
	    headers.set("location", "/another-place");
	    return new Response(null, {
	      status: 301,
	      headers,
	    });
	}

...
export default function Page() {
  return (
    <Partial name="user_feedback">
	....
}

The problem here is that the 301 redirect does not render in the browser because the browser is expecting a Partial like the one in Page(), but the /another-place route is not a Partial's route, it should be full reload.

I imagine that the client never knows about the 301, it only sees the final result (HTML) from the /another-place resource, and the client treats it as the originally requested resource, so it tries to search for partials in that resource, which there are none in it so nothing "happens" even though it returned an entirely different webpage.

A way around the issue is to simply use client-side redirect by rendering an island that uses window.location.href = "location";, note that the island needs to be rendered from the partial route and it needs to be wrapped with the Partial JSX:
// routes/submit.tsx

import { Redirect } from "#islands/Redirect.tsx";

...
  async POST(req, ctx) {
    if (something) {
      return ctx.render({redirect: false});
    }
	else {
        return ctx.render({redirect: true});
	}

...
export default function Page(props) {
  const { redirect } = props.data
  if (redirect) {
    return (
      <Partial name="user_feedback">
        <Redirect location="/another-place" />
      </Partial>
    );
  } else {
  	return (
	    <Partial name="user_feedback">
			Invalid input!
	....
}

// #islands/Redirect.tsx
import { useEffect } from "preact/hooks";

interface Props {
  location: string;
}

export function Redirect(props: Props) {
  useEffect(() => {
    window.location.href = props.location;
  });
  return

;
}

This ... works. But it removes some of the benefit of code organization that Partials allows.

Would it be better if we can hook the partial on the client side and handle exceptions when they occur?
I have another issue when attempting to redirect to a different domain for authentication (e.g., using Google accounts). The partial throws an exception related to CORS policy. If we can intercept the partial when it encounters an exception or fails for any reasons, we can simply use window.location.href to navigate directly to that page in the browser without relying on the partial.

@cosmoswafer a CORS exception is not related to Partials, it means that you are trying to render an HTML response that does not come from your server.


dart_mappable is not able to correctly handle sets equality

Please consider the following simple class wrapping one Set field:
import 'package:dart_mappable/dart_mappable.dart';

part 'mappable_set.mapper.dart';

@MappableClass()
class MappableSet with MappableSetMappable{
  final Set<String> values;

  MappableSet(this.values);
}

The following simple test
test(
    'Two mappable sets with the same elements should equal',
    () {
      //this is how dart_mappable works with core expect() method
      final set1 = MappableSet({'UK - Solar', 'Italy PUN - Solar'});
      final set2 = MappableSet({'Italy PUN - Solar', 'UK - Solar'});
      expect(set1, set2, reason: 'sets should be considered as equal');
    },
  );

fails with output:
Expected: MappableSet:<MappableSet(values: (Italy PUN - Solar, UK - Solar))>
  Actual: MappableSet:<MappableSet(values: (UK - Solar, Italy PUN - Solar))>
sets should be considered as equal

And this simple test completes successfully:
test(
    'Two regular sets with the same elements should equal',
    () {
      //this is how regular sets work with core expect() method
      final regularSet1 = {'UK - Solar', 'Italy PUN - Solar'};
      final regularSet2 = {'Italy PUN - Solar', 'UK - Solar'};
      expect(regularSet1, regularSet2, reason: 'sets should be considered as equal');
    },
  );

I thought that dart_mappable is just about this, to make such things simply working. Could you explain how I can handle properly fields of type Set with dart_mappable?

Thats clearly a bug, let me fix this.

Fixed in v3.1.3


cppwinrt -optimized generates .g.cpp files with calls to make instead of winrt::make

Minor issue, but we don't do a "using winrt" in our project and so winrt::make and things like it need to be fully qualified namespaces. C++/WinRT's generated code is pretty good about sticking to fully qualified references, except for in the -optimize generated files. I am seeing naked make in there:
    AcrylicBrush::AcrylicBrush() :
        AcrylicBrush(make<Microsoft::UI::Xaml::Media::implementation::AcrylicBrush>())
    {
    }

I think the problem is here:
https://github.com/microsoft/cppwinrt/blob/d9862149abbeb9396808f0ea5d1f1c4510c861a2/cppwinrt/component_writers.h#L412
Please update this to be winrt::make? Thanks!

Why is that a problem? This code should be generated within the winrt namespace and thus not need to be fully qualified.

Ohhh ok. You're right. Sorry!


[REQUEST] Can "print" output object like json.dumps?

Use double quote ["] instead of single quote ['], and do not break line.
Is that any way to do it?

JSON doesn't support single quotes. I suspect you aren't printing json. Perhaps you can paste some code and I can offer suggestions.

To print JSON you have two options:
console.print(json.dumps(my_object))
Or
console.print_json(my_object)

To print JSON you have two options:
console.print(json.dumps(my_object))
Or
console.print_json(my_object)

Thanks for your advise, and I've tried "print_json", that looks good for printing json.
data = {'a': [123, 456], 'b': {'x': 1, 'y': 2, 'z': 3}, 'c': 'long text ' * 100}

from rich import print_json
print_json(data=data)

But there still some inconvenient point:

There are 2 diff func, "print" & "print_json", and the arg name "data=" is necessary.
I also use the syntax, like f-string, or some diff part combine with comma in one "print".

from rich import print
print('data: ', data)  # I wish write it like this
print(f'data: {data}')  # even use f-string

If I use "print_json" or "json.dumps":
# print json (2 lines)
print('data: ')
print_json(data=data)

# json.dumps (ensure_ascii for Asia characters, it's long.)
print(f'data: {json.dumps(data, ensure_ascii=False, indent=2)}')

I know I can define a function "dumps", but it still complex, because of some special object what json not supported directly, need print "repr". And I have wrote one, but I hope all "print" in "rich", instead of several different methods.

And back to why I have these needs,

"no break line", for count the lines number correct. My console can "auto break line", so is that a config/setting can turn break line off. And some  time I copy text from console, there's too many "\n" be created.
"double quote" for copy json from console to some other json "prettier" tools or copy json as config to other app, "break line" and "single quote" will make the json unreadable. And the problem of "print_json" or "dumps" as I mentioned earlier.

I am very appreciate and willing to use "rich" print, but is there any way to make the above two points easier?
Is there some setting/config/function/args I missed?

data = {'a': [123, 456], 'b': {'x': 1, 'y': 2, 'z': 3}, 'c': 'long text ' * 100}
print('data:', data)

> output
data: {
    "a": [
        123,
        456
    ],
    "b": {
        "x": 1,
        "y": 2,
        "z": 3
    },
    "c": "long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text long text "
}

Syntax simple, output can be copy (as json/txt), with line break originally, print with color, and indent 4 space.

Your data dict is not JSON, it's a dict. If you print it, you will get a representation of a Python dict which is also not JSON.
If you want to print JSON you will first have to encode your data as JSON. This is what the data argument of print_json does.
Rich won't help you product fragments of JSON that may be copied from the terminal. If that's what you need, you will probably have to implement that yourself.


SWDEV-451864 - Remove the hard coded path in MIGRAPHX_CXX_COMPILER

amdclang++/amdclang can be invoked without providing absolute path, since update-alternatives command has been run for these binaries This will also help to remove the hard coded paths in cmake target files for these compilers

This should still use the absolute path so we can be sure its using the same compiler the developer set migraphx to build with. I dont see any reason why this should be changed either as it doesnt affect any users.

It would be better to just disable adding the defines when using hiprtc to avoid the paths in the cmake targets file.

This should still use the absolute path so we can be sure its using the same compiler the developer set migraphx to build with. I dont see any reason why this should be changed either as it doesnt affect any users.

As part of our efforts to make ROCm relocatable , these hard coded paths need to be removed.


Supabase failing to build in Github Actions CI process

Describe the bug
There seems to be an issue requiring the local environment to either be logged in or the SUPABASE_ACCESS_TOKEN to be set locally. This specifically affects the tests ran on PRs using the "CI" github workflow as per the official configuration (link included in reproduction steps).
Having re-ran this against various versions it seems to work against 1.133.3 however fails on 1.134.0
Changes made between releases:
https://github.com/supabase/cli/compare/v1.133.3...v1.134.0
To Reproduce
When using the github actions defined in the follow configuration:
https://supabase.com/docs/guides/cli/managing-environments?environment=ci#configure-github-actions
Create a PR to the your CI process enabled repo and your github action will fail with the following error:
Access token not provided. Supply an access token by running supabase login or setting the SUPABASE_ACCESS_TOKEN environment variable.
Expected behavior
You should not need to have logged into supabase cli or provided an access token for running tests locally in the CI environment.
Screenshots
N/A
Desktop (please complete the following information):
N/A - uses a github action runner specs:

steps:
- uses: actions/checkout@v3
- uses: supabase/setup-cli@v1
with:
version: latest

Additional context
Workaround for those experiencing this issue is to update the jobs section of your .github/workflows/ci.yml file to start with:

steps:
- uses: actions/checkout@v3
- uses: supabase/setup-cli@v1
with:
version: 1.133.3

Do you have the SUPABASE_PROJECT_ID set as env var or have run supabase link before start?
Based on the linked commits, the failure could be due to cli picking up stale project id.
Let me know if removing the env var works for you, so at least we can confirm the problem before I push a fix.

Sorry, I'm not sure what you mean. From my understanding the Github CI action is setting up a machine to locally run supabase and the tests. As far as I know it should not be reaching to any other environment so would have no need for a project id or linking.
The step it fails on is:

- name: Start Supabase local development setup
run: supabase start

I have confirmed there is no environment set as part of the script so it should not get any environment configurations from github and there is no supabase link command ran as part of the CI.yml file. Not sure what the changes were between 1.33.3 and 1.134 but if it was an issue with an environment variable would it not fail on 1.133.3 as well or was there a change in how environments are handled?
The github action defines it's system as follows in case it is of any use:

runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3

Sorry if it wasn't clear. The new behaviour is to call our api to check the project's service versions only when a project id is provided. If you haven't linked a project, it should not be making this api call at all.
That's why I believe your CI workflow must be picking up the project id from somewhere unintentionally. Perhaps a stale file in supabase/.temp/project-ref or the env var.
That said, the cli should be handling such stale files more gracefully. So regardless of the root cause, I will make patch cli to not throw an error here.


Msvc fixes

Needed for compiling opengm on MS VC 2012

IsCompleteType did NOT compile on MSVC2012
solution provided uses
#include <type_traits>
in metaprogramming.hxx
this in turn requires flag -std=gnu++11
with this flag code builds on clang and gcc
and all the tests pass
Question is: can we add newer standard flag?

@ukoethe @chaubold
please review

ready to be merged into learning-experimental

std::unique_ptr is used without need and should be avoided. (if possible we would be compatible with c++98)
using long long instead of size_t in omp_parallel_for is only required for older omp-version (the only one supported by VS-compiler). I do not know if it is a good idea to ignore this cast warning everywhere because one single compiler is not up to date ...?!? I am open for suggestions and comments.
When external libs are broken, please report and we can try to fix this instead of comment these parts out.

Thanks for looking this over, @joergkappes

using long long instead of size_t in omp_parallel_for is only required for older omp-version (the only one supported by VS-compiler). I do not know if it is a good idea to ignore this cast warning everywhere because one single compiler is not up to date ...?!?

On Windows, this is not a warning but an error: Windows only supports signed index variables in omp_parallel_for. We think the proposed fix is the easiest solution.

std::unique_ptr is used without need and should be avoided. (if possible we would be compatible with c++98)

We use std::unique_ptr because code like
ValueType coeffs[numAssignments];

is illegal in all versions of C++ when numAssignments is not a compile-time constant -- it just happens to be supported as a gcc extension on some platforms. std::auto_ptr would work for C++98, but is considered deprecated in C++11 (and issues a warning). I don't think that any compiler we care about doesn't support std::unique_ptr.

When external libs are broken, please report and we can try to fix this instead of comment these parts out.

The problem with those libs is that they get downloaded and possibly compiled even if we don't need them for the present installation. If such a download or compilation fails, the entire build is stalled. Instead of asking not to comment out libraries that break our build, you might consider to provide a command-line mechanism to disable external libraries we don't need.

Hi,
a unsigned index variable in omp_parallel_for is valid since OpenMP 3.0. This is also true for the Windows platform, but VS-compiler supports only OpenMP 2.0. So its a fix to be compatible with OpenMP2.0 (and VS). If we agree to want to be compatible with OpenGM2.0 we should additionally fix the unsigned-signed comparison in the same line with an explicit cast, shouldn't we?
Concerning "std::unique_ptr" I would suggest to use "new" and "delete" explicit, than its 100% compatible.
I will try to find some time to make the external lib script more configurable, thanks for the suggestion.

Concerning "std::unique_ptr" I would suggest to use "new" and "delete" explicit, than its 100% compatible.

This is a very bad idea, because the code is no longer thread-safe. That is, when the function is terminated by an exception, delete[] gets never called -- memory leak. Avoiding this is the point of std::unique_ptr! If you insist to avoid std::unique_ptr, it is best to write a 5-line utility class which implements just the required functionality (i.e. calls delete[] in the destructor).

Hi,
know I get it, I was totally confused why this should not be thread-safe.
If the code should be exception-safe I would use a std::vector at this part of the code, because it maybe more intuitive. However, the problem exists at several other places in the code, too.

@ilastikdev : Can U please fix the changes in  src/external/patches/CMakeLists.txt .
Looks like a copy past error. U replaced ConicBundle by IBFS.
If U cannot build ConicBundle comment it out, if it is no problem just revert this change.
I will have a look at external libs next month.
If your done, please send me a mail and I will merge the PR

Superseded by PR https://github.com/opengm/opengm/pull/457

PR  #457  merged


"Does not exist" not very clear

Here we see in red the words "does not exist". But it's not very clear what it is trying to communicate.

Okay maybe it means to delete the whole record of this entrance.

Well it's a button when you press with the POI does not exist. I have plans for making a tutorial (see also #40), and there'll be a new video and maybe a documentation in the future, but the button will stay as it is.

Actually it seems down at the bottom of the image there could just be another button next to "save", called "delete".

Oh, I see, in amenities mode it pairs with "mark defunct".


RuntimeError: Input type (torch.cuda.FloatTensor) and weight type (torch.FloatTensor) should be the same

When I ran the demo code in your "Use Our Models" section:
raw_img = cv2.imread('your/image/path')
depth = model.infer_image(raw_img) # HxW raw depth map in numpy
I received the following error: RuntimeError: Input type (torch.cuda.FloatTensor) and weight type (torch.FloatTensor) should be the same
The complete error message is below. Any suggestions?
Your help is greatly appreciated.
RuntimeError                              Traceback (most recent call last)
Cell In[9], line 1
----> 1 depth = model.infer_image(raw_img)
File ~/workspace/anaconda3/envs/depth_anything_v2/lib/python3.10/site-packages/torch/utils/_contextlib.py:115, in context_decorator..decorate_context(*args, **kwargs)
112 @functools.wraps(func)
113 def decorate_context(*args, **kwargs):
114     with ctx_factory():
--> 115         return func(*args, **kwargs)
File /mnt/sda1/shenw/sandbox/depth_est/depth_anything_v2/Depth-Anything-V2/depth_anything_v2/dpt.py:190, in DepthAnythingV2.infer_image(self, raw_image, input_size)
186 @torch.no_grad()
187 def infer_image(self, raw_image, input_size=518):
188     image, (h, w) = self.image2tensor(raw_image, input_size)
--> 190     depth = self.forward(image)
192     depth = F.interpolate(depth[:, None], (h, w), mode="bilinear", align_corners=True)[0, 0]
194     return depth.cpu().numpy()
File /mnt/sda1/shenw/sandbox/depth_est/depth_anything_v2/Depth-Anything-V2/depth_anything_v2/dpt.py:179, in DepthAnythingV2.forward(self, x)
176 def forward(self, x):
177     patch_h, patch_w = x.shape[-2] // 14, x.shape[-1] // 14
--> 179     features = self.pretrained.get_intermediate_layers(x, self.intermediate_layer_idx[self.encoder], return_class_token=True)
181     depth = self.depth_head(features, patch_h, patch_w)
182     depth = F.relu(depth)
File /mnt/sda1/shenw/sandbox/depth_est/depth_anything_v2/Depth-Anything-V2/depth_anything_v2/dinov2.py:308, in DinoVisionTransformer.get_intermediate_layers(self, x, n, reshape, return_class_token, norm)
306     outputs = self._get_intermediate_layers_chunked(x, n)
307 else:
--> 308     outputs = self._get_intermediate_layers_not_chunked(x, n)
309 if norm:
310     outputs = [self.norm(out) for out in outputs]
File /mnt/sda1/shenw/sandbox/depth_est/depth_anything_v2/Depth-Anything-V2/depth_anything_v2/dinov2.py:272, in DinoVisionTransformer._get_intermediate_layers_not_chunked(self, x, n)
271 def _get_intermediate_layers_not_chunked(self, x, n=1):
--> 272     x = self.prepare_tokens_with_masks(x)
273     # If n is an int, take the n last blocks. If it's a list, take them
274     output, total_block_len = [], len(self.blocks)
File /mnt/sda1/shenw/sandbox/depth_est/depth_anything_v2/Depth-Anything-V2/depth_anything_v2/dinov2.py:214, in DinoVisionTransformer.prepare_tokens_with_masks(self, x, masks)
212 def prepare_tokens_with_masks(self, x, masks=None):
213     B, nc, w, h = x.shape
--> 214     x = self.patch_embed(x)
215     if masks is not None:
216         x = torch.where(masks.unsqueeze(-1), self.mask_token.to(x.dtype).unsqueeze(0), x)
File ~/workspace/anaconda3/envs/depth_anything_v2/lib/python3.10/site-packages/torch/nn/modules/module.py:1532, in Module._wrapped_call_impl(self, *args, **kwargs)
1530     return self._compiled_call_impl(*args, **kwargs)  # type: ignore[misc]
1531 else:
-> 1532     return self._call_impl(*args, **kwargs)
File ~/workspace/anaconda3/envs/depth_anything_v2/lib/python3.10/site-packages/torch/nn/modules/module.py:1541, in Module._call_impl(self, *args, **kwargs)
1536 # If we don't have any hooks, we want to skip the rest of the logic in
1537 # this function, and just call forward.
1538 if not (self._backward_hooks or self._backward_pre_hooks or self._forward_hooks or self._forward_pre_hooks
1539         or _global_backward_pre_hooks or _global_backward_hooks
1540         or _global_forward_hooks or _global_forward_pre_hooks):
-> 1541     return forward_call(*args, **kwargs)
1543 try:
1544     result = None
File /mnt/sda1/shenw/sandbox/depth_est/depth_anything_v2/Depth-Anything-V2/depth_anything_v2/dinov2_layers/patch_embed.py:76, in PatchEmbed.forward(self, x)
73 assert H % patch_H == 0, f"Input image height {H} is not a multiple of patch height {patch_H}"
74 assert W % patch_W == 0, f"Input image width {W} is not a multiple of patch width: {patch_W}"
---> 76 x = self.proj(x)  # B C H W
77 H, W = x.size(2), x.size(3)
78 x = x.flatten(2).transpose(1, 2)  # B HW C
File ~/workspace/anaconda3/envs/depth_anything_v2/lib/python3.10/site-packages/torch/nn/modules/module.py:1532, in Module._wrapped_call_impl(self, *args, **kwargs)
1530     return self._compiled_call_impl(*args, **kwargs)  # type: ignore[misc]
1531 else:
-> 1532     return self._call_impl(*args, **kwargs)
File ~/workspace/anaconda3/envs/depth_anything_v2/lib/python3.10/site-packages/torch/nn/modules/module.py:1541, in Module._call_impl(self, *args, **kwargs)
1536 # If we don't have any hooks, we want to skip the rest of the logic in
1537 # this function, and just call forward.
1538 if not (self._backward_hooks or self._backward_pre_hooks or self._forward_hooks or self._forward_pre_hooks
1539         or _global_backward_pre_hooks or _global_backward_hooks
1540         or _global_forward_hooks or _global_forward_pre_hooks):
-> 1541     return forward_call(*args, **kwargs)
1543 try:
1544     result = None
File ~/workspace/anaconda3/envs/depth_anything_v2/lib/python3.10/site-packages/torch/nn/modules/conv.py:460, in Conv2d.forward(self, input)
459 def forward(self, input: Tensor) -> Tensor:
--> 460     return self._conv_forward(input, self.weight, self.bias)
File ~/workspace/anaconda3/envs/depth_anything_v2/lib/python3.10/site-packages/torch/nn/modules/conv.py:456, in Conv2d._conv_forward(self, input, weight, bias)
452 if self.padding_mode != 'zeros':
453     return F.conv2d(F.pad(input, self._reversed_padding_repeated_twice, mode=self.padding_mode),
454                     weight, bias, self.stride,
455                     _pair(0), self.dilation, self.groups)
--> 456 return F.conv2d(input, weight, bias, self.stride,
457                 self.padding, self.dilation, self.groups)
RuntimeError: Input type (torch.cuda.FloatTensor) and weight type (torch.FloatTensor) should be the same

Hi, please refer to the updated doc: https://github.com/DepthAnything/Depth-Anything-V2#use-our-models

Hi, please refer to the updated doc: https://github.com/DepthAnything/Depth-Anything-V2#use-our-models

Thank you for the update! It works now.

Hi! Caught the same problem when set DEVICE = 'cpu'. The error shows that input preprocessed image on CUDA, but model not, so got different type of tensor (as i got it). Thanks for you link to README, but I do not found what to change to make it run correct on CPU. Could you please help with this?

There are two lines changed from "old" version of README:
DEVICE = 'cuda' if torch.cuda.is_available() else 'mps' if
torch.backends.mps.is_available() else 'cpu'
model = model.to(DEVICE).eval()
It works in my case...
On Fri, Jul 5, 2024 at 9:20 AM kafkaGen @.***> wrote:

Hi! Caught the same problem when set DEVICE = 'cpu'. The error shows that
input preprocessed image on CUDA, but model not, so got different type of
tensor (as i got it). Thanks for you link to README, but I do not found
what to change to make it run correct on CPU. Could you please help with
this?
—
Reply to this email directly, view it on GitHub
https://github.com/DepthAnything/Depth-Anything-V2/issues/45#issuecomment-2210868774,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACGTFGGKW7H5N2EISQC3R63ZK2MTJAVCNFSM6AAAAABKEQE436VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJQHA3DQNZXGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Added Azure AD - Web API - SharePoint Online integration using OAuth

Hi @RARomano, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

@RARomano, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, MSBOT;

Hi RARomano, thank you for your contribution.  Can you please submit a pull request to the dev branch. Here the guidance on contributing back to PnP https://github.com/OfficeDev/PnP/wiki/contributing-to-Office-365-developer-patterns-and-practices

closing this item please submit a pull request to the dev branch https://github.com/OfficeDev/PnP/wiki/contributing-to-Office-365-developer-patterns-and-practices

Hi Frank,
Sorry about that. I'll submit it to the dev branch later this weekend.
Thank you!
Regards,
Rodrigo Romano
Sent from my iPhone
On 16/06/2015, at 10:18, Frank Marasco <notifications<EMAIL_ADDRESS>wrote:
Hi RARomano, thank you for your contribution. Can you please submit a pull request to the dev branch. Here the guidance on contributing back to PnP https://github.com/OfficeDev/PnP/wiki/contributing-to-Office-365-developer-patterns-and-practices

Reply to this email directly or view it on GitHubhttps://github.com/OfficeDev/PnP/pull/935#issuecomment-112424916.

No worries my friend it happens to all of us :)
From: Rodrigo Romano
Reply-To: OfficeDev/PnP
Date: Thursday, June 18, 2015 at 8:18 AM
To: OfficeDev/PnP
Cc: Frank Marasco
Subject: Re: [PnP] Added Azure AD - Web API - SharePoint Online integration using OAuth (#935)
Hi Frank,
Sorry about that. I'll submit it to the dev branch later this weekend.
Thank you!
Regards,
Rodrigo Romano
Sent from my iPhone
On 16/06/2015, at 10:18, Frank Marasco <notifications@github.commailto:notifications<EMAIL_ADDRESS>wrote:
Hi RARomano, thank you for your contribution. Can you please submit a pull request to the dev branch. Here the guidance on contributing back to PnP https://github.com/OfficeDev/PnP/wiki/contributing-to-Office-365-developer-patterns-and-practices

Reply to this email directly or view it on GitHubhttps://github.com/OfficeDev/PnP/pull/935#issuecomment-112424916.
—
Reply to this email directly or view it on GitHubhttps://github.com/OfficeDev/PnP/pull/935#issuecomment-113152884.


Develop automated backup system

Thanks for creating an issue! Please fill out this form so we can be sure to have all the information we need, and to minimize back and forth.

What are we trying to do?
Twice a day, run a task that takes a db snapshot and securely stories it somewhere, encrypted.

What feature or behavior is this required for?
Me sleeping at night; data recovery in case of catastrophic failure. (I'm taking backups manually now.)

How could we solve this issue? (Not knowing is okay!)
No idea but I am highly suggestible!

Anything else?

I think we can leverage mLab backups for this.
PROS:

Uses our existing db provider
Stores backup to secure container they provide
Doesn't require much if any tribal knowledge to know how to mess with it

CONS:

Costs money (but not much, and this might be unavoidable)
Backup storage is with database provider

Cost looks to be around 2 dollars a month for weekly backups, which is likely a good place to start?
You can in theory do the backups yourself and send them to S3 but then you incur the cost of S3 storage, securing it, etc... plus a lot of configuration/tasks/etc... that may be less transparent in terms of how to work on.


Uninhabited != NoReturn

What's in this pull request?

Fix a case where we would fail to diagnose a missing return if an enum decl as the result of a function had no cases.
@slavapestov can you review?

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci please smoke test.

Why do we want this?

There's a clear difference between Never the type and any user-defined enumeration, regardless of whether it has cases or not.

There's not intended to be. We need to diagnose "falling off the end" in either case.

Right. To clarify, we want any uninhabited type to behave like Never, and mark a function as not returning.
Right now the isNever check is inaccurate because it doesn't realize that a strict with an uninhabited field is also uninhabited, but that didn't seem worth fixing.

@jrose-apple By definition we cannot fall off the end if the return type is Never, because the return is not reachable.

When dealing with user-defined types it's more likely that they meant to write up the cases for the enum later and would expect a diagnostic about the function not returning than they decided to exploit ex falso.  There is only one bottom type, and that is Never.  If the user wishes to explore alternate expressions of that fact, they can always reach for the classic
enum X {}

func explode() -> X {
  return explode()
}

@swift-ci please smoke test Linux platform.

If defer to @jckarter regarding this. It was his original suggestion to treat all empty enums as a 'Never' type.

Actually, the fact that this doesn't produce a diagnostic is the real bug:
enum E {}

func f() -> E {}

It happens for both 'E' and 'Never'. Mind if I take this?

That it happens for E is what this fixes.  For Never there shouldn't be a diagnostic, right?

@CodaFi That's the thing, we should get the diagnostic for Never too.
Remember, this was invalid before:
@noreturn func f() {}

A @noreturn function had to either end with a call to some other @noreturn function, or end with an infinite loop, essentially. You weren't allowed to fall through the end.
It looks like something is wrong in the SIL unreachable diagnostics pass wrt the Never type.

Sounds good.


update releases, create and maintain CHANGELOG.md

would be good to see latest release you published to VS marketplace also tagged in github here: https://github.com/tanhakabir/rest-book/releases
Also, good extensions typically provide a changelog to quickly view new features, enhancements and bug fixes, and both vscode and VS marketplace displays them nicely in the Changelog tab in their extension info views.
See my latest ext. changelog for example and format I use for my extensions: https://github.com/RandomFractals/vscode-snippets-viewer/blob/main/CHANGELOG.md
I know other ext. devs have more elaborate changelog doc formatting schemes and even welcome view updates that show changes after extension update. I can link you to those if you'd like, while we wait for the vscode dev team to finalize similar feature to display extension updates that will become standard when they release it.

Good call! I'll add a CHANGELOG

sounds good. see this repo if you want to add a fancy what's new view ;)
https://github.com/alefragnani/vscode-whats-new


WindowsAppSDK-VersionInfo.json: Release.MajorMinor.HexUInt32 is not hex value

Describe the bug
In microsoft.windowsappsdk.1.5.240404000.nuget/WindowsAppSDK-VersionInfo.json, Release.MajorMinor.HexUInt32 is 00010005.
Maybe it should be "0x00010005".
Steps to reproduce the bug
See nuget package.
Expected behavior
No response
Screenshots
No response
NuGet package version
Windows App SDK 1.5.2: 1.5.240404000
Packaging type
No response
Windows version
No response
IDE
No response
Additional context
No response

What scenario is this causing an issue? We are not doing any addition or other operations on it, so is there any effect of this?

I am writing a python projection for WindowsAppSDK https://github.com/ynkdir/py-win32more.  It uses version information to call mddbootstrap API.
I want to update the version information in my library to follow each WindowsAppSDK update.  I wrote script and python's json parser raised parse error for the value 00010005.
I can write my update script with avoiding the error any way.   I just thought that 00010005 is not intended value.

Thanks for the bug report! I've cooked  a fix in main for 1.6


DEP Remove unused league/flysystem requirement

A bug in Flysystem was breaking the prefer-lowest build of silverstripe/assets, which led us to discover that the package isn't even used in framework. I've introduced a direct dependency on it in https://github.com/silverstripe/silverstripe-assets/pull/424.

Why is it a dependency of this repo and not assets?

I can only find one reference to Flysystem in the source for Framework, and it's an unused use statement 😂
That said, would shifting the dependency be considered a breaking change? For 99.999% of projects it's probably a non-issue, so maybe it's not even worth debating (since any Framework-only project should be defining the Flysystem requirement directly anyway.)

I've changed this PR to instead drop Flysystem from Framework. The only risk I can see is that a project could update to silverstripe/framework 4.7.0 without also updating to silverstripe/assets 1.7.0, leaving them without Flysystem. Two options:

Introduce a conflict with silverstripe/assets <1.7
Add a note about it to the 4.7 release notes, and assume developers will be able to get themselves out of the situation very easily

I think we used the library once in a project code to handle something project-specific since it came with the framework, but a note in the release notes would make us re-test it and include the dependency separately as a solution, so "2. add a note to 4.7 changelog" would suffice from our perspective.

An upgrade note is probably since very few people will upgrade framework but not assets. If for some reason this use-case comes up I'd probably be more inclined to release another 1.6.x tag of assets with the composer dependency included there.

One thing to note, @Cheddam - ideally we could include that upgrade note with this PR. As it stands, we don't generate those docs until the next release. In other projects people will sometimes have an "unreleased" document/section where these things can be collated as we go.
Is it worth raising with the people on the tools for releases whether this would be a good idea?

The 'process' for this at the moment is that the first person wanting to add something to the changelog creates it by hand, (hopefully) copying the template that Cow would use itself. This could obviously be more consistent, and we run the risk of missing details in the changelog when we leave writing it until release.
So, I've just talked to the team, and we're going to tweak our process to start creating a provisional changelog for the next minor immediately following the stable release of the previous one, so that we can ensure the template is used correctly, and that it's always available for contributors to add to when they land a change.
I've raised a separate PR to add one for 4.7.0, and I'll update this PR with notes once that's merged.

Yeah it'll be added to 1.7 but if you install framework 1.7 and assets 1.6 it won't pull the dep in. Not impossible but a very strange setup. I'd wait until someone complains before patching assets 1.6 to support that case.

If assets can be patched in 1.6 line, adding the deps, why not do it and wait for 1.7? Why wait for a complain?

@michalkleiner It's overhead we're better off not incurring if possible, and we'd encourage developers to resolve the issue by updating the assets module to 1.7.x instead. Running inconsistent minors isn't a recommended practice.
@sminnee Changelog notes are up 👍

Weird edge case incoming ;)
{
    "name": "test/test",
    "require": {
        "silverstripe/framework": "^4.7"
    },
    "minimum-stability": "dev",
    "prefer-stable": true
}

composer --version
Composer version 2.0.7 2020-11-13 17:31:06

composer install

composer info | egrep '(assets|framework)'
silverstripe/assets                   1.6.1     SilverStripe Assets component
silverstripe/framework                4.7.0-rc1 The SilverStripe framework

composer why silverstripe/assets
silverstripe/framework  4.7.0-rc1  requires  silverstripe/assets (^1@dev)

Yep I saw a community member hit the same thing recently. The good news is that it will be resolved when we tag 4.7.0 stable in just a couple of weeks 🙂 Definitely lends some credence to making sure we keep core requirements in lock-step at the minor level, since if we'd bumped the assets requirement to ^1.7@dev this wouldn't be occurring.


comment.lua:65: attempt to call field 'get_lines' (a nil value)

Prerequsities

[X] I'm on the latest version of the plugin
[X] I've installed the required dependencies
[ ] I've run :h gitlab.nvim.troubleshooting and followed the steps there

Setup Configuration and Environment
Only difference from default I think is :
      diffview = {
        imply_local = true,
      },

Bug Description
A function seems to be missing in the reviewer/init.lua (get_lines)
E5108: Error executing lua: ...are/nvim/lazy/gitlab.nvim/lua/gitlab/actions/comment.lua:65: attempt to call field 'get_lines' (a nil value)
stack traceback:
        ...are/nvim/lazy/gitlab.nvim/lua/gitlab/actions/comment.lua:65: in function 'cb'
        .../.local/share/nvim/lazy/gitlab.nvim/lua/gitlab/async.lua:26: in function 'fetch'
        .../.local/share/nvim/lazy/gitlab.nvim/lua/gitlab/async.lua:34: in function 'fetch'
        .../.local/share/nvim/lazy/gitlab.nvim/lua/gitlab/async.lua:34: in function 'fetch'
        .../.local/share/nvim/lazy/gitlab.nvim/lua/gitlab/async.lua:60: in function <.../.local/share/nvim/lazy/gitlab.nvim/lua/gitlab/async.lua:47>

Reproduction Steps

Check out the feature branch
Open Neovim
Create multi-line comment

Thank you, this will be fixed in the next release, probably in the next couple of days. If you want this fixed immediately you can use the develop branch of the plugin which now has the fix.

Fixed by #227, fixed in v2.0.4, closing.


Feign's connectTimeout and readTimeout deactivates ribbon retries

In 2.2.2 RELEASE
When I configured the Feign readTimeout and connectTimeout, I found that the Ribbon retry didn't work,like this:
ribbon:
  MaxAutoRetries: 2
  MaxAutoRetriesNextServer: 2
  OkToRetryOnAllOperations: true
feign:
  client:
    config:
      default:
        connectTimeout: 2000
        readTimeout: 2000

And then I found in FeignRibbonClientAutoConfiguration through debugging such configuration:
	@Bean
	@ConditionalOnMissingBean
	public Request.Options feignRequestOptions() {
		return LoadBalancerFeignClient.DEFAULT_OPTIONS;
	}

And then the FeignClientFactoryBean#configureUsingConfiguration (), loading the Options:
Request.Options options = getOptional(context, Request.Options.class);
		if (options != null) {
			builder.options(options);
		}

And next in FeignClientFactoryBean#configureUsingProperties(), because I added the timeout configuration, the default Options is now overridden:
if (config.getConnectTimeout() != null && config.getReadTimeout() != null) {
			builder.options(new Request.Options(config.getConnectTimeout(),
					config.getReadTimeout()));
}

Finally, this directly causes me to fail to get the MaxAutoRetries and MaxAutoRetriesNextServer in the Ribbon in the following code:
LoadBalancerFeignClient#getClientConfig()

IClientConfig getClientConfig(Request.Options options, String clientName) {
		IClientConfig requestConfig;
		if (options == DEFAULT_OPTIONS) {
			requestConfig = this.clientFactory.getClientConfig(clientName);
		}
		else {
			requestConfig = new FeignOptionsClientConfig(options);
	   }
		return requestConfig;
}

Obviously, the object here is definitely not DEFAULT_OPTIONS
Was it designed that way?

@q398544597 will verify it.

The way it was being handled has been rearchitected and improved since and migrated to work with Spring Cloud LoadBalancer instead of Ribbon. It should have fixed the issue. If you're still experiencing a related issue on the currently supported versions of SC OpenFeign (3.1.6 or 4.0.1, please get back to us).

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


westonnelson/feature/001/backend provider for app

Added wagmi + RainbowKit for Mainnet, Optimism, Arbitrum.

for the name of the branch, could you change it to feature/wallet-connect?


bug: yank highlighting broke in v1.1.1, but works in v1.1.0

Did you check docs and existing issues?

[X] I have read all the vscode-neovim docs
[X] I have searched the existing issues of vscode-neovim
[X] I can reproduce the issue with an empty init.vim/init.lua and no other vscode extensions (when applicable)

Neovim version (nvim -v)
v0.9.4
Operating system/version
MacOS 14.0
Describe the bug
Thanks for the awesome integration, i'm new to vim so having an actual nvim instance integrated with the vscode is really helpful!
Yank highlighting broke after updating to v1.1.1, at first i thought that the issue was in the config files as i'm new to neovim and could brake something myself, tried different configs to get highlighting to work:
Vim script:
augroup highlight_yank
    autocmd!
    autocmd TextYankPost * silent! lua vim.highlight.on_yank { higroup="IncSearch", timeout=1000 }
augroup END

And also tried Lua:
local function augroup(name)
  return vim.api.nvim_create_augroup("lazyvim_" .. name, { clear = true })
end

vim.api.nvim_create_autocmd("TextYankPost", {
  group = augroup("highlight_yank"),
  callback = function()
    vim.highlight.on_yank()
  end,
})

Both configs worked just fine inside the nvim terminal, but not with vscode-extension, although i had it working in vscode too just today earlier. The configuration file does not contain anything else, I also tried on a fresh installation of VSCode Insiders without any other extensions - still no success. Downgrading to v1.1.0 fixed the problem.
Steps To Reproduce
Install the v1.1.1 version.
Enable yank highlighting in the config file.
Expected Behavior
Yank should be highlighted, just as it was in v1.1.0

Now, all custom highlight groups in vscode will be automatically cleared. It seems that nvim_buf_set_extmark will ignore empty highlight groups.


Add test-server to the aggreagate project file

This is in order to run ALL tests when using the test command in the top-level project

@stew Here is the code we just looked at. It compiles but there are verbose implicit values that are annoying.

It started out as just adding test-server to the master build, but then I realized that the tests in that sub-project were broken (and have been for a while) so I also pilled on the changes to fix these tests.

@jedesah I sent a PR to this branch, I have run into this problem before. Long story short: "variance can break inference in scala".  Short story long: https://github.com/scodec/scodec/pull/26 and https://issues.scala-lang.org/browse/SI-8877

@stew Thx! I merged the PR and did a little polishing. Would you do the honors?


Way to link to posts without using a permalink?

Forgive my ignorance if it exists, but it seems that there is no way to link to a post without using a hard link (that is, http://domain.name/style/of/permalink/name-of-file.html ).
Am I wrong?
In an ideal world, I think post links should be something like: "text to display as link":2009-06-30-name-of-file.textile, which would then be converted to permalinks.

Did anything like this make it in to Jekyll? Googling has failed me so far...

It did not.  If you take this file from #369 and put it in your _plugins directory, you can use the post_url as described in the pull request.

@thatguystone Thanks Andrew!

Closed by #369.