Update fails and breaks "user" install

VSCode Version: ?
OS Version: Window 10

Steps to Reproduce:

Install previous version of VS Code user install.
Try update to current version of VS Code as non-admin user.

Does this issue occur when all extensions are disabled?: Yes
Attempting to update to the current version of VS Code "user" install, a permissions error was shown and the update aborts. Now the application will not open and attempting to re-install produces similar permissions errors. Example below.

Does it reproduce if you restart your machine?

Yes.
A successful workaround is to apply local admin rights to the user. This is not an great solution for many.

From: João Moreno<EMAIL_ADDRESS>Sent: Thursday, July 16, 2020 1:45:10 AM
To: microsoft/vscode<EMAIL_ADDRESS>Cc: Dan Kellett<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [microsoft/vscode] Update fails and breaks "user" install (#102608)
Does it reproduce if you restart your machine?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode%2Fissues%2F102608%23issuecomment-659256120&data=02|01||09e8a2ed53924202d6dd08d829648ce4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637304859113009099&sdata=J954mJzVkv3QQpq3d8ldKfUz5M5nUku9eyURY0NYzCE%3D&reserved=0, or unsubscribehttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAOPU2TUCHKHL4H7GMD74RLR324ZNANCNFSM4O2VBYRA&data=02|01||09e8a2ed53924202d6dd08d829648ce4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637304859113019093&sdata=Gg9ctCr69lBoYxb7bfclraGoWn5b7nSEUEUj9ZJE%2F%2Bo%3D&reserved=0.

If you want to run incremental updates as the user, you should install it initially as that user, instead of installing it as an Administrator. Did you originally install it as an Administrator?

I had originally installed as a non-admin. If it's not a widespread issue, I suspect it's likely caused by system hardening policies on this side.
Thanks for your attention.

From: João Moreno<EMAIL_ADDRESS>Sent: Thursday, July 16, 2020 7:32 AM
To: microsoft/vscode<EMAIL_ADDRESS>Cc: Dan Kellett<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [microsoft/vscode] Update fails and breaks "user" install (#102608)
If you want to run incremental updates as the user, you should install it initially as that user, instead of installing it as an Administrator. Did you originally install it as an Administrator?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode%2Fissues%2F102608%23issuecomment-659451601&data=02|01||8107bbb2ee7c423ea98808d829950a8a|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637305067382845058&sdata=mjhRpTeeHyZ1s%2BOtdL7UKCwozH5zfY4s%2FlD6s7Us0O8%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAOPU2V5N537XFKWFVQ5ME3R34FO7ANCNFSM4O2VBYRA&data=02|01||8107bbb2ee7c423ea98808d829950a8a|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637305067382855055&sdata=XsN6TGBOWIETv8tJg%2BAfU0kjZGqfN4fVfTuR7a7NLRU%3D&reserved=0.


adaptive adjacency matrix

How to build an adaptive adjacency matrix by pyg, so as to complete the adaptive graph convolution

Can you be a bit more precise? You can generally create a fully-connected graph with edge weights set to 1, and backprop through edge weights to find only meaningful edges.

Such like that. The problem is that i don‘t know how to make the Adjacency Matrix (NN) to the Edge Index (2E), so i encounter error.
import torch
import torch.nn as nn
import torch.nn.functional as F
from torch_geometric.nn import TAGConv
class pygTAGLayer(nn.Module):
def init(self, in_c, out_c, num_nodes, device):
super(pygTAGLayer, self).init()
self.TAG = TAGConv(in_c, out_c, K=3)
self.nodevec1 = nn.Parameter(torch.randn(num_nodes, 10).to(device), requires_grad=True).to(device)
self.nodevec2 = nn.Parameter(torch.randn(10, num_nodes).to(device), requires_grad=True).to(device)
def forward(self, x2):
    adp = F.softmax(F.relu(torch.mm(self.nodevec1, self.nodevec2)), dim=1)
    batch_size, num_vertices, features, time_stamps = x2.shape
    gx = []
    for i in range(batch_size):
        x = x2[i, :, :, :]
        x = x.squeeze(0)
        for t in range(time_stamps):
            y = x[:, :, t]
            y = y.squeeze(-1)
            out = self.TAG(y, adp)
            gx.append(out.unsqueeze(0))
    gx = torch.cat(gx, dim=0)  # (batch*time,N,F)
    gx = gx.reshape(batch_size, time_stamps, num_vertices, -1)  # B,T,N,F
    gx = gx.permute(0, 2, 3, 1)  # B,N,F,T
    gx = F.leaky_relu(gx, negative_slope=0.1)
    return gx

x = torch.FloatTensor(32, 307, 64, 12)
model = pygTAGLayer(64, 12, 307, 'cpu')
y = model(x)

import torch
import torch.nn as nn
import torch.nn.functional as F
from torch_geometric.nn import TAGConv

class pygTAGLayer(nn.Module):
    def __init__(self, in_c, out_c, num_nodes, device):
        super(pygTAGLayer, self).__init__()
        self.TAG = TAGConv(in_c, out_c, K=3)
        self.nodevec1 = nn.Parameter(torch.randn(num_nodes, 10).to(device), requires_grad=True).to(device)
        self.nodevec2 = nn.Parameter(torch.randn(10, num_nodes).to(device), requires_grad=True).to(device)

    def forward(self, x2):
        adp = F.softmax(F.relu(torch.mm(self.nodevec1, self.nodevec2)), dim=1)
        batch_size, num_vertices, features, time_stamps = x2.shape
        gx = []
        for i in range(batch_size):
            x = x2[i, :, :, :]
            x = x.squeeze(0)
            for t in range(time_stamps):
                y = x[:, :, t]
                y = y.squeeze(-1)
                out = self.TAG(y, adp)
                gx.append(out.unsqueeze(0))
        gx = torch.cat(gx, dim=0)  # (batch*time,N,heads,F)
        gx = gx.reshape(batch_size, time_stamps, num_vertices, -1)  # B,T,N,F
        gx = gx.permute(0, 2, 3, 1)  # B,N,F,T
        gx = F.leaky_relu(gx, negative_slope=0.1)
        return gx
x = torch.FloatTensor(32, 307, 64, 12)
model = pygTAGLayer(64, 12, 307, 'cpu')
y = model(x)

You can convert a N times N adjacency matrix to the required format via:
edge_index = adp.nonzero(as_tuple=False).t()
edge_weight = adp[edge_index[0], edge_index[1]]

I hope this helps!

Thanks for your help! Great help!


[PATCH v2] Fix race condition between task creation and removal

This commit fixes a race condition between task creation and removal
which could causes orphan containers. It happens when a agent task is
handling creation event and is creating a container, a removal event
comes in and cancels the task's context, causing both the creation and
removal fail, but the container is still created by the docker daemon.
The removal fails because when the DELETE request arrives the docker
daemon, the container is still being created.
goroutine (creation)                   task (removal)
---------                              ----

...                                    ...
ctlr.Prepare(ctx)
  r.adapter.createNetworks(ctx)
  ...                                  case <-shutdown
  r.adapter.create(ctx)                  cancel()
  //failed due to context cancelled      tm.ctlr.Remove(ctx)
  //container still createdby daemon     //failed due to "No such
                                         //container" error because
                                         //the container not created
                                         //yet
  ...
  //the container created by docker
  //daemon but becomes orphan

This patch fixes it by delaying the cancel option until the ongoing
operation is finished if the task is in the preparing state, in
which state a container will be created for the task. This way,
the removal operation would never race with the creation operation.
Signed-off-by: Jin Xu<EMAIL_ADDRESS>

[Current coverage][cc-pull] is 55.20%

Merging [#1154][cc-pull] into [master][cc-base-branch] will decrease coverage by 0.08%

@@             master      #1154   diff @@
==========================================
  Files            77         77
  Lines         12079      12083     +4
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           6678       6670     -8
- Misses         4491       4501    +10
- Partials        910        912     +2

[][cc-pull]

Powered by Codecov. Last updated by [6478bc1...4abca88][cc-compare]
[cc-base-branch]: https://codecov.io/gh/docker/swarmkit/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/docker/swarmkit/compare/6478bc19cf4bc1d7ba2d6f04ccaacf099508f4a0...4abca880a844e7338c5ba144732173cd7fbc90b9?src=pr
[cc-pull]: https://codecov.io/gh/docker/swarmkit/pull/1154?src=pr

LGTM

LGTM
/cc @aluzzardi @stevvooe

Unfortunately, this fix will reintroduce bugs that this code prevents. Please do not merge this.
The actual bug is that Remove is returning an error when the container is already removed or never existed at all.
In general, no two methods on exec.Controller should ever be called at the same time. This makes concurrency in the controller implementation easier, but it also ensures that we get consistent information when returning from a method. In this case, we can't really wait for Prepare to exit, so we may have to impose some requirements on the implementers of exec.Controller.
We may have to make Remove concurrent and cancelling for this to work properly. Or, just read the comment I made above the call to Remove (you read it, right?) and handle this with a reaper.

Thanks for your review. @stevvooe

The actual bug is that Remove is returning an error when the container is already removed or never existed at all.

Based on my debugging, the Remove did fail and it's due to the latter reason as you pointed out. The docker daemon reported "No such container" error but it already received the creation request and was creating the container.

In general, no two methods on exec.Controller should ever be called at the same time. This makes concurrency in the controller implementation easier, but it also ensures that we get consistent information when returning from a method.

I agree. But currently, the shutdown is handled concurrently in a separate branch against other operations.

In this case, we can't really wait for Prepare to exit, so we may have to impose some requirements on the implementers of exec.Controller.

I couldn't understand why we can't wait for Prepare to exit except the preparing may takes some time if it's pulling a image. Could you explain what's your concern?
By the way, the #1152 proposed a solution which fixes the race in the exec.Controller level. Could you please take a look if you think that's a potentially better solution?

We may have to make Remove concurrent and cancelling for this to work properly.

As I observed, the Remove is called only once. Do you mean making Remove and Create operations concurrent safe?

Or, just read the comment I made above the call to Remove (you read it, right?) and handle this with a reaper.

I read the comment you mentioned and it looks like the reaper is a long term solution. But I don't know how to implement it. I would be interested in the reaper feature.

Unfortunately, this fix will reintroduce bugs that this code prevents.

BTW, I am curious about what bug do you mean which could be reintroduced by this change?

To debug the issue, I added some prints in Prepare and Remove functions. Following
logs are extracted out to see what happened for an orphan container.
swarmkit log:
[Prepare] Creating container frontend-13.1.6b8ctzc40cyvyp0ww15m5afam
[Remove] Removing container frontend-13.1.6b8ctzc40cyvyp0ww15m5afam
[Prepare] Failed to create container frontend-13.1.6b8ctzc40cyvyp0ww15m5afam with error
An error occurred trying to connect: context canceled
daemon log:
ERRO[2006] Handler for POST /containers/frontend-13.1.6b8ctzc40cyvyp0ww15m5afam
/stop returned error: No such container: frontend-13.1.6b8ctzc40cyvyp0ww15m5afam
ERRO[2006] Handler for DELETE /containers/frontend-13.1.6b8ctzc40cyvyp0ww15m5afam
returned error: No such container: frontend-13.1.6b8ctzc40cyvyp0ww15m5afam

I read the comment you mentioned and it looks like the reaper is a long term solution. But I don't know how to implement it. I would be interested in the reaper feature.

We aren't implementing this now because it will hide these kinds of bugs.

Could you explain what's your concern?

This fix is too narrow and blocks the manager on a potentially unbounded operation. What if the container is in any other method? The race condition still exists. This needs to be handled by the

Could you please take a look if you think that's a potentially better solution?

https://github.com/docker/swarmkit/pull/1152 suffers from being too narrow, as well. And it adds state, which it doesn't need at all. exec.Controller is supposed to be stateless but well-ordered.
Careful removal of the "does not exist" error and granular locking (and maybe a closed channel) is all that is needed to resolve this.
Could you file a bug with the description of the problem? We need to be careful with a solution here.

This fix is too narrow and blocks the manager on a potentially unbounded operation. What if the container is in any other method? The race condition still exists.

Based on current design, the removal operation is disruptive and will race not only with Prepare but also Start and potentially other methods. I think the design itself is not bad because it can remove the task without waiting too long by cancelling ongoing activities. So following the current design, we need to make sure it doesn't bring harmful results. As I noticed so far, only the race between remove and prepare will result in annoying result, orphan containers. Of course, we would need a more general approach if we have larger range of problems.

Could you file a bug with the description of the problem? We need to be careful with a solution here.

No problem.

Filed issue #1159.

Superseded by #1192. Closing it.


Where is the  button[type="submit"]?

I check the component http://www.material-ui.com/#/components/
I found button is base on span, so how do I get the effect of button[type="submit"] ?
Maybe span[type="submit"] can work in chrome, but other browser?

Button isn't based on span.

seems like <FlatButton type="submit" ... will just do the trick, but the documentation doesn't include this property.

@neekey It doesn't work with <IconButton /> though. :|

@neekey I just saw that I may have been mistakenly mentioned in this thread (3 years later :D)

If you're like me that just skims around when reading the docs and didn't find a type prop in the IconButton docs . . . there is this message at the end of the Props list:

Any other properties supplied will be provided to the root element (ButtonBase).

ButtonBase accepts the type prop, so just add type=submit to the IconButton component like so: <IconButton type="submit">
Posting this here for anyone coming from Google.

Sorry, but I'm trying to add this attribute to a Button component and I'm getting a TypeScript error. I checked the ButtonBase API docs but I can't find any reference to the "type" attribute:
https://material-ui.com/api/button-base/
Seems like a pretty common use case so I'd find odd if it's not supported, unless I'm missing something.

@amypellegrini The reason type isn't documented for the ButtonBase is that we don't cover the native HTML attributes.

@oliviertassinari  it would be great to use the material-ui Button styles, and being able to have button submit types and so on. Is there any plan to support that?

I would say that it's probably at document.querySelector('button[type="submit"]')


MPI P2P Communication Protocol

Dear All-
Is there any way to use point 2 point communication protocol of MPI?  I mean like. MPI.Send and MPI.Recv and MPI.Isend or MPI.Irecv.
Thanks!
Regards
Raj

For what purposes you wanna to do this? Better to ask directly in MPI project.

@tlikhomanenko As mentioned in distributed training computing section, there are api for allreduce and broadcast and I wondered if there are APIs for MPI.Isend  and MPI.Irecv for tensor in FLashlight.

cc @jacobkahn

@raj-brown we don't have p2p API components in Flashlight's distributed API, but you can easily add those MPI functions yourself — if you've built Flashlight with distributed functionality, you can include <mpi.h>, call those functions yourself, and and go from there.


sql: add copy-based migrations and VACUUM INTO

Motivation
Currently, when vacuuming is required after database migration (according to the configured db-vacuum-state value), simple SQL VACUUM command is used. According to the description in the SQLite docs, VACUUM requires as much as twice the size of the original database file in free disk space, as first it makes a copy of the database in the temporary directory, and then it copies the vacuumed database back to the original database utilizing WAL file which grows to the size of the database itself before changes are committed.
According to the remark in the SQLite source
** Only 1x temporary space and only 1x writes would be required if
** the copy of step (3) were replaced by deleting the original database
** and renaming the transient database as the original.  But that will
** not work if other processes are attached to the original database.
** And a power loss in between deleting the original and renaming the
** transient would cause the database file to appear to be deleted
** following reboot.

In case of go-spacemesh, we don't need concurrent access to the database from multiple processes, so we can optimize the vacuuming step to use only 1x space of the original database for vacuuming, given that VACUUM INTO makes a vacuumed copy of the database with no space requirements besides the size of the copy. Moreover, we can use the temporary copy of the database to run migrations faster as we can use PRAGMA journal_mode=OFF and PRAGMA synchronous=OFF for the temporary database safely, just dropping it if something goes wrong during migration.
On top of requiring 2x space, normal VACUUM (without INTO) has another problem: very slow last step in which the original database is replaced.
Another problem described in #6069 is that on Linux systems, $TMP directory is utilized during normal VACUUM, and in case if it's a RAM disk the vacuuming process may run out of space.
Description
The process below applies to both state and local database.
When no vacuum is required, the migration process is unchanged, with migrations done in-place and each one wrapped in a transaction.
When vacuuming is needed according to db-vacuum-state, the following steps are performed. Marker files which are DBNAME_done are used to indicate that the temporary database is complete and synced and can be used to replace the source database. The temporary database is named DBNAME_migrate.

The database is opened, so that it is locked and any concurrent go-spacemesh processes will fail to open it at the same time.
A temporary copy of the database is created in the go-spacemesh data directory by means of VACUUM INTO. As it can be seen from above "benchmark", VACUUM INTO is relatively fast; also, this way we may hold the lock on the database by simply having it open during the copying. In addition to that, if the source database became bloated somehow due to unused (free) pages, the copy will require less disk space.
The migrations are run on the temporary copy with PRAGMA journal_mode=OFF and PRAGMA synchronous=OFF.
The temporary database is synced to disk after setting PRAGMA journal_mode=WAL and PRAGMA synchronous=NORMAL.
The marker file is created and synced to disk.
The temporary database is copied over the source database by means of VACUUM INTO.
The marker file and the temporary database are deleted.

Additionally, before opening a database no matter what its schema version is, the following steps are performed:

If the temporary database exists along with the "..._done" marker file, this means that a previous migration was interrupted when replacing the source database, or immediately preceding that; in this case, the temporary database is opened, copied over the source database by means of VACUUM INTO, after which the marker file and the temporary database are deleted.
If the temporary database exists but there's no marker file, this means that previous migration has failed and in this case the temporary database is deleted.

In addition to the above, this PR adds logging of parts of migration SQL statements (first lines) when debug logging is set for stateDb in the logging section of the config. This makes it easier to see what parts of a migration are taking long time to execute.
Closes #6069
Test Plan
Tested on a mainnet node.

bors try

bors try

CI rerun due:
hare_test.go:653: eligibility can't be sent, waited: 10s, stacktraces:

Likely unrelated

bors merge

bors merge

I think @acud needs to give approval for bors accepting the merge

bors merge

Systests timed out, trying again

bors try

bors cancel

bors merge


R-T5.4-10 Support Google BigQuery data warehouse as a data source when deploying data pipelines.

ID
R-T5.4-10

Section
WP5: Runtime environment

Type
FUNCTIONAL_SUITABILITY

User Story
As a Operations Engineer, I want to be able to design and deploy data pipelines which send or recieve data from Google BigQuery data warehouse.

Requirement
Support Google BigQuery data warehouse as a data source when deploying data pipelines.

Extended Description
The goal is support designing and deploying data pipeline applications which to use Google BigQuery data warehouse as a data source and data flow should be possible in both directions (consuming and producing into BigQuery).

Priority
Should have

Affected Tools
ORCHESTRATOR

Means of Verification
Tests with data pipeline  service template which includes Google BigQuery input and output data sources to verify that the data pipeline is deployed correctly.

New requirement. Please verify for approval @gcasale .

Approved/

@cankarm , Can you please add "Data Pipeline" label to this issue?


add Stream.skip

Add the following method to Stream:
def skip(self, n: int) -> None:
    assert n >= 0
    ...

The method should iterate over data without incrementing .iteration. This can be useful for continuing loop after loading state_dict. For example, if a stream is restored at the point where iteration == 100, user may want to skip 100 iterations (or 100 % len(stream.loader) iterations) before continuing the loop.

Looks like the motivation is too theoretic:

If epoch_size == len(loader) then there is no need for such a method.
Else, there is no way to reproduce the epoch data in the middle of which training is resumed.


Documentation: Integration Testing section should explicitly requires spring-modulith-starter-test dependency

https://docs.spring.io/spring-modulith/reference/testing.html is missing the indication that dependency spring-modulith-starter-test should be added.
In the Overview, it is said that "The individual sections describing Spring Modulith features will refer to the individual artifacts that are needed to make use of the feature."
It's true for most sections, but not this one.

Good catch, thanks for reporting! 🙇


DSD-326: heading display sizes

Fixes DSD-326
This PR does the following:

Adds displaySize prop to Heading for overriding default heading styles

Front End Review:

[ ] View the example in Storybook

Can you add a story section to display all of the DisplaySizes options?

Done.

Not necessary for this PR but eventually the documentation for the Headings with Links section should be clearer that the url prop will create an anchor element for you when it renders.

I added some more details to the url prop and to the Headings with Links story.


Documenting the intention of altsrc

Speaking as someone who is now partially responsible for helping with this project (along with everyone else) - it would be nice if there was a canonical document describing altsrc. Is it:

intended to be merged into the "main" package eventually?
do people think of it as a separate package, or an extension?
should every PR we create be updating both "main" and altsrc?

Personally i would like to see altsrc as an "extension" (interface) which can be used by developers to add more config sources. I have a common use case to retrieve parameters first in AWS SSM and then continue with environment vars and flags.
For creating an own altsrc package (i guess you mean a split to a new repo?) wouldn't this mean some kind of API stability?

Personally i would like to see altsrc as an "extension" (interface) which can be used by developers to add more config sources. I have a common use case to retrieve parameters first in AWS SSM and then continue with environment vars and flags.

I also understand it as an extensions interface, yeah. I think it we renamed the functionality to revolve around extensions, it would help with understanding and adoption.

For creating an own altsrc package (i guess you mean a split to a new repo?) wouldn't this mean some kind of API stability?

I'm not sure what this means 🙂

I think I'm going to bucket this into #833


Create modifier apply as a complement to fn

The apply modifier should behave like fn, but calling std::apply() instead of std::invoke().
Maybe this begs the question of whether fn should be renamed invoke, but I want to keep fn for now.

I didn't think I needed a whole new kind of parser. I could just use a Transform parser to achieve the same thing.
template <Parser P>
requires [something]
consteval auto operator()(P) const
{
    constexpr auto impl = [](typename P::result_type&& arg) { return std::apply(function, std::move(arg)); };
    return Transform<P, impl>{};
}

This is definitely true, I could just use a regular transform parser. But I could use that same argument for other parsers like Defaulted, Into, etc, which all got their own parser types. So I think I'll make a whole new parser, called ApplyTransform.


Add rv 3032 c7 support

This pull request adds support for Micro Crystal AG RV-3032-C7, a new accurate I²C RTC with integrated crystal and digital temperature compensation.
The RV-3032-C7 can be used in a similar way to the the DS3231 in most applications where the RTClib would be used. This is especially interesting because the DS3231 is very difficult to source right now. As of this writing, Digikey has 10K RV-3032-C7 in stock, and the next shipment is scheduled in "just" 3 months.
As can be expected from a new chip, the RV-3032-C7 bests the DS3231 in a number of ways:

Wider operating voltage range: 1.3 V to 5.5 V

 Backup can be as low as 1.2 V with temperature compensation

 Timekeeping down to 1V (but no temperature compensation)

 Ultra low power consumption: 160 nA @ 3 V

 Time accuracy: -40°C to +85°C, ±2.5 ppm

 Charge pumps for trickle charge of backup capacitor/battery

 12 bit temp. resolution (new reading every second)

 Very compact 8-WCDFN package  (3.2 x 1.5 x 0.8 mm)

See Data sheet summary for more information: https://www.microcrystal.com/fileadmin/Media/Products/RTC/Datasheet/RV-3032-C7.pdf
Product page for the full application manual and more: https://www.microcrystal.com/en/products/real-time-clock-rtc-modules/rv-3032-c7/
This is an initial release of the RV-3032-C7 support for RTClib. It includes setting time, alarm and enabling/disabling the CLKOUT pin.
I tried to keep the API as close as possible to the DS3231 behaviour except where it would be misleading. Feedback and suggestions are of course welcomed.
Assuming the idea of including this chip in RTClib is approved, I intend to add more features, in particular:

readme file specific to RV-3032-C7 with more usage details
controlling the CLKOUT frequency
support for periodic timers
support for time stamping external events (works even when the chip is on backup power)
support for read/write the user RAM and EEPROM

I can add other features if there is interest.
Some features like trickle charge may be unsafe for beginners, so I am not currently planning to provide direct support for activation (they are off by default). I may provide an example if there is an interest (and then the library would work).
Tested with Arduino Uno, Arduino MKR1000, Adafruit Adafruit QT Py - SAMD21. More testing will follow.
For full disclosure, I have developed this library with an eval board provided free of charge by Micro Crystal AG, but I have no other affiliation with the company and I will not receive any form of compensation for this work.

I have a few suggestions regarding the documentation of this new class:

List the class in the comment block at the top of RTClib.h. This ensures that it appears in the list of available classes in the library's reference page.
diff --git a/src/RTClib.cpp b/src/RTClib.cpp
index 8f1f4ea..4719480 100644
--- a/src/RTClib.cpp
+++ b/src/RTClib.cpp
@@ -29,6 +29,7 @@
     - RTC_DS3231
     - RTC_PCF8523
     - RTC_PCF8563
+    - RTC_RV3032C7
   - RTC emulated in software; do not expect much accuracy out of these:
     - RTC_Millis is based on `millis()`
     - RTC_Micros is based on `micros()`; its drift rate can be tuned by

Use the correct name RV3032C7EventType (with a final ‘e’) in the documentation of both setAlarm() and enableCountdownTimer(). The former could also be turned into a link:
diff --git a/src/RTC_RV3032C7.cpp b/src/RTC_RV3032C7.cpp
index 30b0f65..459ae9c 100644
--- a/src/RTC_RV3032C7.cpp
+++ b/src/RTC_RV3032C7.cpp
@@ -194,7 +194,7 @@ float RTC_RV3032C7::getTemperature() {
    disableAlarm().
         @param         dt DateTime object
         @param         alarm_mode Desired mode, see RV3032C7AlarmMode enum
-        @param   event_type Desired event type, see RV3032C7EventTyp enum
+        @param   event_type Desired event type, see #RV3032C7EventType enum
     @return False if alarm registers are not set, otherwise true
 */
 /**************************************************************************/
@@ -361,7 +361,7 @@ bool RTC_RV3032C7::alarmFired(void) {
         @param clkFreq One of the RV3032C7's Periodic Countdown Timer Clock Frequencies.
          See the #RV3032C7TimerClockFreq enum for options and associated time ranges.
         @param numPeriods The number of clkFreq periods (1-4095) to count down.
-        @param   event_type Desired event type, see #RV3032C7EventTyp enum
+        @param   event_type Desired event type, see #RV3032C7EventType enum
 */
 /**************************************************************************/
 void RTC_RV3032C7::enableCountdownTimer(RV3032C7TimerClockFreq clkFreq, uint8_t numPeriods, RV3032C7EventType event_type) {

Doxygen complains that the macro RV3032C7InvalidDate is not documented, and that the following methods also lack documentation:

getCountdownTimerEventType()
disableCountdownTimer(void)
clearCountdownTimer(void)
CountdownTimerFired(void)

It appears that none of these methods have been defined (getCountdownTimerEventType() has been defined as a plain function, which is likely a mistake).


Implement User Input for Municipality Code

Title: Implement User Input for Municipality Code
Description: Create a form that allows users to input a municipality code and fetch data for that specific area.
Acceptance Criteria:

Add an input field for the municipality code with id="input-area".
Implement functionality to update the POST request based on user input.
The search function should be case-insensitive.

Additional Notes:
Retrieve municipality codes from the specified GET request.

#3


Fix exclusion directory and file matching and add support for reading a top level gitignore file

Closes https://github.com/apache/incubator-openwhisk-utilities/issues/39.
This patch bundles source code from pathspec https://pypi.org/project/pathspec/ and updates the LICENSE accordingly. This is to avoid a pip install in all downstream clients.
The pathspec library is Mozilla Public License 2.0 [1]. My reading of the Mozilla License, their FAQ [2] and the Apache 3rd Party License Policy [3] leads me to conclude the bundling is acceptable.
[1] https://www.mozilla.org/en-US/MPL/2.0/
[2] https://www.mozilla.org/en-US/MPL/2.0/FAQ
[3] https://apache.org/legal/resolved.html

@rabbah -- are we ready to merge this or do we need fixups in some of the scanned repos to fix problems in files that we had previously been erroneously ignoring?

Ready to merge as long as someone has sanity checked my understanding of the licenses and the inclusion of the library. The patch will not require downstream changes as is.

Thanks @mrutkows and @dgrove-oss for the review.


Added support for image slide with text content

Wanted to use the gem to create a gallery of pictures with some description in each one. So I updated a new type of slide (textpic) which has image and text together, not only one-based. You can also specify the coordinates of the text and the picture independently.

Thanks @Kalunia for your contribution. Sorry for the delay, I have been out for a while.
Can you please resolve the conflicts with master branch and resubmit your pull request?


[Bug Report] Debounce in multiple select

Element UI version
2.4.5
OS/Browsers version
any
Vue version
2.5.17-beta.0
Reproduction Link
https://jsfiddle.net/mmx38qxw/4194/
Steps to reproduce
Just typing something in select
What is Expected?
Expected debounced method cals
What is actually happening?
Actually, remote method function calling on every keyup event

Why is "debounced" function call expected? How could we know the ideal calling frequency for every user?

So why in single select remote method always calling with debounce - 300?
https://github.com/ElemeFE/element/blob/dev/packages/select/src/select.vue#L208
https://github.com/ElemeFE/element/blob/dev/packages/select/src/select.vue#L848


RFC: Consolidate Info Loading

Attempt to use the same code for info loading in the BaseLinker and the Refiner.
Pros:

Less duplicate code.
Method level caching even for loading from files.
Infos move closer to the Analyzer.

Cons:

Version semantics get confusing (better naming can probably fix this).
We're forced to map over a Future in the Refiner now.
Unclear whether the additional caching is actually beneficial.

Note that this currently fails org.scalajs.linker.BasicLinkerBackendTest.linkNoSecondAttemptInEmitter I wanted to get an opinion first, before debugging that.

Rebased onto main and addressed comments.
TBC: Not necessary for 1.13.1.


Toggle k-th bit of a number

Have you read the Contributing Guidelines on Pull Requests?
Yes
Description
Resolved issue #4303
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
(Write your answer here.)

@ankitaggarwal23 actually I was toggling all bits of a number only once but now i will change it to generalise it for k times.

Yes, actually I was busy in semester exam, I will be working it by tomorrow


Correctly create custom http.Transport in http_batch_store.go

For the longest time, there's been a 'go vet' warning telling us that
when we build a custom http.Client in http_batch_store.go, we were
copying a Mutex down in there. That seems like not what you want to do.
Turns out we should be creating our own http.Transport object and
sharing that, instead of copying the default one every time we build
a new httpBatchStore.

PTAL


Version 2.x vs 1.x

Looking at the releases, I noticed a v2.0.0 and a more recent v1.1.2. What is the difference between the two? Is v2.0.0 for use with the newly released dash.js 2.0.0?

v2.0.0 of this project is for use with video.js 5.0 and is not related to the dash.js version.

Oh OK. So there is only one current release compatible with Video.js 5.x. That's good to know.
Is the development of this project closely tied with the dash.js project? I saw a version of this project is included in the dash.js project, but it's outdated and incompatible with Video.js 5.x. Is there a reason for this? Or are the two projects totally out of sync at the moment?

The dash.js copy of this plugin is very old (1.1.0 from July). This repo should be the destination for the latest code.
@imbcmdth should we keep the dash.js copy of this plugin up to date with this project or just have the readme direct users here?

I'll open a PR against dash.js and update the plugin found there.

I'll close this when it's merged into dash.js.

See https://github.com/Dash-Industry-Forum/dash.js/pull/1378

The plugin code has been updated in dash.js, closing.


Error Source for HTTP Headers

Error sources as currently defined do not provide a mechanism to specify errors resulting from invalid HTTP headers. Adding a header field would satisfy this use case:

source: an object containing references to the source of the error,
optionally including any of the following members:

pointer: a JSON Pointer [RFC6901]
to the value in the request document that caused the error [e.g. "/data"
for a primary data object, or "/data/attributes/title" for a specific
attribute]. This MUST point to a value in the request document that
exists; if it doesn't, the client SHOULD simply ignore the pointer.
parameter: a string indicating which URI query parameter caused
the error.
header: a string indicating which HTTP header caused
the error.

Hi! Thanks for the suggestion. Can you provide an example/use case?
My gut reaction is that this makes sense. However, let me play devil's advocate.
My first, less important concern: Aren't error objects already too complicated to process? By adding this, we add yet another object member which may or may not be there and we therefore increase the complexity of client implementations.
The more concrete concern: The spec only uses three headers: accept, content-type and location, but clients only send the acceptandcontent-typeheaders. There are already dedicated HTTP status codes for errors in those headers:406 Not Acceptableand415 Unsupported Media Type`. Why do we need an affordance for headers not already covered by these status codes?

Thanks for the push back: it's always interesting to consider alternative views.

The spec only uses three headers

Query parameters outside of the spec, for example, can be referenced properly, and there's no restriction on referencing errors for out-of-spec query parameters. Say I require a "lang" param. Easy to encode as en error. Now say I require "Accept-Language". I send a 422 and point to what exactly?

I do think there's another issue lurking here that your concern surfaces.  Should errors on accept, content-type or location have sources? This seems cumbersome.
Here is another concrete use case. Say I require an authentication token  (Authentication Bearer) and XSRF token for each request.
Now say I want to tell the client that the XSRF token is wrong, expired, or requires a refresh. I want to send them an error with details, but based on the current spec, I can't point that header as the issue. Is this a 401 because of the authentication token or the XSRF token? Currently, I use an error code specific to that error as the distinction. Say there are other errors in the request too. Why should all the other errors have a source and not this error?
I know that use case is rather niche. The most common outside use case I can think of would be similar issues which cause a single 401 or 403 error. Do we just assume the code itself is suffices as a reference? I'll admit my case is somewhat pathological, however, it is real.
Work arounds do exist, though: there is meta after all.
Anyway, I'll ponder this more. Would be great to hear other thoughts too. In my heart, I just want to be able to reference all the things.

I hear your point about being able to point to query parameters but not headers. It's a fair point.

In my heart, I just want to be able to reference all the things.

Makes sense!

I want to send them an error with details, but based on the current spec, I can't point that header as the issue. Is this a 401 because of the authentication token or the XSRF token?

This is beside the point, but I personally wouldn't send a 401 for an invalid XSRF token because a) that token isn't really a credential and b) 401 responses comes with other, unrelated responsibilities.
XSRF tokens are more of a request "validation" and in that sense, the 400 language seems more appropriate.
However, 400 is an even more ambiguous status and so I think that it actually bolsters the case for a header member.

I think I'm now more in support of this addition than against it.  I'm curious what @dgeb thinks.

My take, FWIW:
When a request is received and the endpoint is identified using the URL from the request, content negotiation is used to determine the appropriate response format.  When an error occurs, that changes what is being returned to the error information, and content negotiation should then be applied to determine the appropriate format.  At this point, JSON:API (or RFC 78-7, or ...) may be selected, even though the request is not a JSON:API request.
At this point, it's entirely reasonable to support indicating that the error content comes from a header.  Some applications may require or support non-standard headers as well (especially for legacy pre-JSON:API endpoints), making it reasonable to report bad headers.

OpenAPI defines query, header, path, and cookie all as types of parameters. Instead of adding a new member for each would we want to add a location member? It could also have body as a valid value.

Consolidating in location would then require a way to provide both the location name and location type.  The current structure allows more than one to be involved; it might make more sense to think about whether that makes sense for a single error.  Aside from that, which way to arrange it feels like a six-of-one v. half-dozen-of-the-other comparison; which is more convenient depends more on your implementation language & frameworks.

To clarify I was envisioning both the location and either parameter or pointer members to be used at the same time. Something like this:

source: an object containing references to the source of the error, optionally including any of the following members:

pointer: a JSON Pointer [RFC6901] to the value in the request document that caused the error [e.g. "/data" for a primary data object, or "/data/attributes/title" for a specific attribute]. This MUST point to a value in the request document that exists; if it doesn’t, the client SHOULD simply ignore the pointer.
parameter: a string indicating which request parameter caused the error.
location: A string indicating which part of the request contained the error. The recommended values are query, header, path, cookie, and body. When not provided a location of query can be assumed if the parameter member is populated or body if the pointer member is populated.

The current format discourages an error from having multiple sources. If there are two query params that are not compatible the service would need to respond with an error for each param. Similarly, if the validation of a member in the body is affected by the value of another member you can only point to one of the body members per error.
An oddity of the current format is it allows you to specify both a point in the body and a query param as the source of the error. I'm not sure of a justification for that which would not also justify multiple query params.
We could extend @fny's proposal with one member per location with the addition that only a single member of the source should be set. Which option is more convenient would indeed be a matter of opinion.

@richard-rance: It sounds like we're largely in agreement.  Whether the location is provided as a separate property or implied by the name of the property holding the reference isn't particularly important to me.
Clarifying that the source object can contain at most one member (or two, if location is added), would be an improvement.  Requiring it to contain exactly one (or two, with location) would be even better.  There could be backward compatibility issues if location were required, though.

Thanks for the great discussion here! :)
I agree with @freddrake about clarifying the contents of the source member, but I'm not sure if the rule should be >0, =1, or <2. Let's reason through it...
An empty source member would be pointless. In that case, the source member should be omitted altogether. I think that eliminates <2.
The current text doesn't prevent one from using custom members, nor from having multiple members. That means it could be a BC break to specify =1 for some implementations. Therefore, we're left with >0.
So, I think we should clarify that the source member, if present, MUST contain at least one member.
There's one last thing I think we could also clarify in a relatively BC way... I think we could make the optional members mutually exclusive. In other words, say that you can't have pointer && parameter at the same time.

@richard-rance, I like your thinking :)
I think you're bringing up two important questions:
1. Do we want to consolidate to something like OpenAPI's in member so that we don't have to have a unique member for each location?
I think the advantage of the in/location idea is that it is a little more future-friendly because you can add new allowed values for the location member. It feels like a smaller change to add new allowed values to an existing member than it does to add new members entirely. In practice, client implementations will be hardcoded to expect whatever is allowed, in either case though, so it's really a matter of taste and if we didn't already have pointer and parameter I would probably have preferred location too.
Since we didn't start with something like location, let's just add a header member as a sibling of parameter instead of a new member that duplicates some of what we already have.
Still, what about OpenAPI's query, header, path, and cookie? Should we have equivalents for every one of them? I don't think so.

query: this is the same as parameter IMO
header: yes, let's add this one.
path: I think a 404 and a detail are enough here. Also, I'd rather not encourage APIs to use complex path parameters.
cookie: This is a little redundant, isn't it? Implementation can specify "header": "cookie"
body: this is the same as pointer. Unlike OpenAPI, we know the format of the request body will always be JSON and so we can use the more capable JSON pointer spec.

2. What to do about errors caused by the interaction of different fields/parameters?
I think our errors objects were probably designed for form submissions (I'm not sure, wasn't there), maybe not explicitly, but it was probably on everyone's mind. If that was the case, I think pointer was really about helping the client put the error message in the "right" place in the form. If the error was specific to a particular form field, the pointer told the client to render a red box over a particular form field.
If two fields interact, I think you wouldn't want to show the same error twice. So, you'd either put the error at the top of the form (IOW, omit source entirely) or use the pointer to point to the most appropriate field for the error to be displayed.
That's an Ember/React/Angular specific reasoning, but I think it applies generally... You can think about it like this: if the first query parameter restricts the use of a second query parameter, the error is that the second parameter was added despite the fact it was no longer permitted. Thus, the source of the error is the second, restricted parameter instead of the source of the error being both parameters.

Whoops, probably should add a tl;dr...
tl;dr: Let's add a header member. Also, let's specify that source MUST contain at least one member and that it MUST NOT contain more than one of the following members: pointer, parameter, header

So, I think we should clarify that the source member, if present, MUST contain at least one member.

I'd generally prefer this for any sub-objects that have optional members.
Unfortunately, this is backward incompatible, since a JSON:API 1.0 response could legally return "source": {}, even though it would be useless.  For 1.1, we strengthened the status member to SHOULD; perhaps we could do the same here, stating that an empty source SHOULD be omitted.

There's one last thing I think we could also clarify in a relatively BC way... I think we could make the optional members mutually exclusive. In other words, say that you can't have pointer && parameter at the same time.

Again, I like this, but... the backward compatibility issue is a question.  It's hard to imagine anyone using these together in practice, but it would have been legal in 1.0.  The compatibility promise in the first paragraph of 1.0 is quite strong.

Still, what about OpenAPI's query, header, path, and cookie? Should we have equivalents for every one of them? I don't think so.

query: this is the same as parameter IMO
header: yes, let's add this one.
path: I think a 404 and a detail are enough here. Also, I'd rather not encourage APIs to use complex path parameters.

JSON:API also explicitly stays away from the URL structure.  If URLs are always handed to the client, the client should not be generating URLs anyway.  So this doesn't seem useful w/r/t JSON:API.

cookie: This is a little redundant, isn't it? Implementations can specify "header": "cookie"

Maybe, but {"cookie": "some-cookie-name"} is much more specific than {"header": "cookie"}.  It's unlikely to make a difference for display to a user, but much better when debugging.

body: this is the same as pointer. Unlike OpenAPI, we know the format of the request body will always be JSON and so we can use the more capable JSON pointer spec.

@gabesullice: Did you see my comments on content negotiation in https://github.com/json-api/json-api/issues/1514#issuecomment-700128091?  Are you expecting JSON:API errors to only be generated from JSON:API requests?

Fair points wrt to BC, so, I'm not opposed to SHOULD  and SHOULD NOT.
Re. cookie: good catch. I was not thinking about specific cookie names... I'm skeptical about its usefulness. Isn't a developer going to read the detail in the end? If we added cookie-name why would we not add parameter-index?
I kind of wish we took an approach more like RFC 7807. I like that it is very generic and allows implementors to add their own members for their own purposes.

Did you see my comments on content negotiation in #1514 (comment)? Are you expecting JSON:API errors to only be generated from JSON:API requests?

I did, but I didn't make this connection.  I don't think we can prevent someone for using JSON:API for responses to non-JSON:API requests, but our introduction reads:

JSON:API is a specification for how a client should request that resources be fetched or modified, and how a server should respond to those requests.

I think our focus should be on the conversation between JSON:API clients and servers, not on providing a universal JSON media type.

Re. cookie: good catch. I was not thinking about specific cookie names... I'm skeptical about its usefulness. Isn't a developer going to read the detail in the end? If we added cookie-name why would we not add parameter-index for parameters that accept multiple values (e.g. include=foo,bar,unknown => parameter: include; parameter-index: 2)?

I used to think people would read... but I've dealt with more of them now.
While I don't want to hold a developer's hands when reporting an error to them, making an error report easy to consume is a good way to help them find their error.  If it requires deciphering text in a natural language they may not be proficient at, it will eventually become a support request.  Possibly in a natural language I'm not proficient at.

I kind of wish we took an approach more like RFC 7807. I like that it is very generic and allows implementors to add their own members for their own purposes.

There are definitely some good things there.  What I do like about the JSON:API error object is that there's a defined place for implementation-specific fields in meta.

I think our focus should be on the conversation between JSON:API clients and servers, not on providing a universal JSON media type.

Yes, but.  In a world where content negotiation is a part of every interaction, I'd still rather get error messages in something better suited to debugging than anything else.

If we added cookie-name why would we not add parameter-index for parameters that accept multiple values (e.g. include=foo,bar,unknown => parameter: include; parameter-index: 2)?

A cookie name is generally displayed by browsers and most frameworks as a separate key/value pair from the headers. The index in a list of values is interesting. It is more like a pointer within the parameter. Having just an index would not work for query params that are more complex such as an SQL-like filter. Possibly a value member might be a way to state what is wrong but even that feels implementation-specific.
For myself building an error for your example the details would be The value "unknown" is not a valid relationship to be included. I would then put any of the dynamic parts of the string into the meta object so they can be worked on programmatically and are not affected by translations.

JSON:API also explicitly stays away from the URL structure. If URLs are always handed to the client, the client should not be generating URLs anyway. So this doesn't seem useful w/r/t JSON:API.

The server supporting HATEOAS and the client actually using it are two different things. Often clients want to jump directly to fetching their record without the discovery step. Telling them that they got a 404 because the 2nd path parameter is not valid could be useful.

The notion of "cookie" as an error location, regardless of how it's encoded, suggests that both "cookie": "<name>" and "header": "cookie" could reasonably co-exist.  This isn't a concern as long as "cookie" is not a defined property for "source".
@gabesullice: Do you plan on proposing a specific change to the specification language, or would you prefer I create a PR?

@gabesullice: PR #1533 makes the specific changes you outlined above.

@gabesullice: PR #1533 makes the specific changes you outlined above.

Should be closed now that PR #1533 has landed.

Should be closed now that PR #1533 has landed.


Http refactoring, chunked transfer support

There's still work to be done, but this PR is getting pretty big and basically everything pre-existing works.
A whole bunch of changes are made here to better work with chunked transfer encoding in streaming http.  In particular we're beginning to address the issue that sometimes you want the body of a chunked request to be "dechunked" into just the raw data while other times (such as in a proxy) you want to leave the body totally untouched.  As the proxy situation is more relevant to our immediate needs, I focused on that use case for now, though getting the dechunking streams to work should not be much more work.

Moved a whole bunch of stuff around to better organize things.  In particular there's now a proper HttpResponseHead similar to the HttpHead (soon to be renamed) for HttpRequest.  Also we had mixed up transfer-encodings with content-encodings, so those are now properly separated.
There's now more of a separation between the Http and Streaming http codecs.  There's probably room to merge some stuff together, but right now it's much easier to iterate if we keep everything separated for now.
DataBuffer has a new peek method which allows you to read from the buffer inside a closure, and afterwards the buffer is reset to the state before the closure began.  This is primarily needed for the next point...
By default now, a streaming HttpClient will not dechunk the body.  This is enabled with the new ChunkPassThroughPipe which is able to parse the chunk headers to keep track of when the stream ends, but doesn't actually consume any data.

things that still need to be done (I'll move these into one or more issues) :

Implement the pipe that that will dechunk the http body.
Possibly indicate -- either as a new field in HttpResponse or possibly as a wrapper ADT around DataBuffer -- whether the attached Source is being dechunked or not.
Probably move the Transfer-Encoding, Content-Length, and Content-Encoding headers into some kind of first-class value on HttpResponseHead.  This will make it easier (and probably faster) to figure out exactly what the body of the Response looks like.
Generalize all the above to work for HttpRequest as well.

Phew..that took a good amount of time up.  All in all, looks pretty good..I didn't see anything glaring or incorrect.  The http classes are looking cleaned up..which, having a clean base will allow us to build on it some more(first class headers, etc)
:100:


Update to swift-transformers

Hi @davidkoski @awni !
Is it possible to upgrade the dependencies?
The latest version of swift-transformers supports chat-template. https://github.com/huggingface/swift-transformers/pull/104
ChatMLX depends on mlx-libraries and the latest version of swift-transformers, but mlx-libraries uses an older swift-transformers version. Looking forward to an upgrade.
https://github.com/ml-explore/mlx-swift-examples/blob/9266a6282fc56e1be03292cde6e665b765fb977b/Package.swift#L19
After upgrading, you can also modify Libraries/LLM/Models.swift. https://github.com/ml-explore/mlx-swift-examples/blob/9266a6282fc56e1be03292cde6e665b765fb977b/Libraries/LLM/Models.swift#L115-L237

Yes of course!  If you want to submit a PR that is the fastest way, otherwise I will try to get to this in the coming week.

Okay, thank you very much @davidkoski!
I can only modify mlx-swift-examples/Package.swift on my end.
As for modifying mlx-swift-examples/Libraries/LLM/Models.swift, I might not have time for that at the moment.
Hi @pcuenca, could you please tag a new release for https://github.com/huggingface/swift-transformers?

I think we are all set here


1.17.0-Beta4 - Syntax highlighting fails on large flies

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Large files do not show syntax highlighting, I have tried multiple files with more than 150,000 lines and no matter what I do it will not highlight the text correctly. I have found if you cut all the text out of the file, then past it into a new file, scroll to the top, it will highlight correctly (but not once you save and open the file again). The only way I can get the highlight to work consistently is when I physically shrink the file to ~50k lines.
Steps to Reproduce

[First Step]
Open a large C, Java, XML, or some other syntax aware file (150,000 lines or more)
[Second Step]
Note that the text has no syntax highlighting even though the correct language is detected

Expected behavior: [What you expect to happen]
When opening a large text files (150k+ lines) the text is highlighted correctly based on the selected syntax.
Actual behavior: [What actually happens]
All text has no highlighting, only when shrinking the file to ~50k lines did highlighting start to function again.
Reproduces how often: [What percentage of the time does it reproduce?]
100%
Versions
1.17.0-Beta4 c64
Windows 7 x64
Additional Information

Does the file have any long lines?

Here is a dummy XML file I created, it has the same issues as the files I have been working with. On a side note I had to create the file in Notepad++ as Atom crashed trying to save it.
GenericXML2.zip

This already happens for me with Atom 1.16. I just open a large XML File as mentioned and it won't be highlighted. Small files however are working. Maybe this helps.

Atom treats all "large" files, anything over 2048K, as plain text.

Thanks @chrisvio.


docs: add basic governance files

Adds a GOVERNANCE-template, a Swedish version of the template and a project.
It is really a low key GOVERNANCE-file, as a general reminder that governance is considered rather than a full blown example for a major project.
Checklist

[x] My contributions and commit messages follows the style guidelines of this project
[x] I have made corresponding changes to the documentation
[x] New and existing unit tests pass locally with my changes
[x] The Pull Request has an informative and human-readable title
[x] Changes are limited to a single goal (avoid scope creep)
[x] Code can be automatically merged (no conflicts)
[x] I confirm that I have read any Contribution guidelines (CONTRIBUTING)
[x] I confirm that I wrote and/or have the right to submit the contents of my PR, by agreeing to the Developer Certificate of Origin, by adding a 'sign-off' to my commits

@danneleaf I think you would need to add your digg-email to your github-user account if you want to get any creds as co-author for this and a few earlier ones.

@janderssonse Thanks for pointing that out, I have added my digg mail now! :)

@janderssonse Thanks for pointing that out, I have added my digg mail now! :)

And,, I can see you got cred now!


Gravity Falls api not working

Hi! Your gravity falls API is great, but it isn't working now. It sends {"err":"Something went wrong!"} on each request. I hope it will work soon :(

Hi! Thanks for your interest. I wasn't contributing mine API project for a while then abandoned it due to having lack of interest. It's an error having that problem because I was using Planetscale as a database in a so called "hobby program". So, database sleeps after 1 month of inactivity :). I now activated the database again and hope you can see the requests without a problem. But, thanks to your interest now I have plans to refactor the project again :d
And heard that Planetscale is removing their hobby program. So it means that I need to move out to a better option :)
https://planetscale.com/blog/planetscale-forever

Thank you very much! About database: you can transfer db to neon (https://neon.tech/). They give 0.5GB for free, I think that's enough

Thank you very much! About database: you can transfer db to neon (https://neon.tech/). They give 0.5GB for free, I think that's enough

I would like to transfer to MongoDB or AWS for now thanks for noticing!

It is not working again 🥲

It is not working again 🥲

It's because database goes to sleep mode every 24hrs. Now, I had tried to awake the database but Planetscale tells me to buy their plan instead of using the hobby plan.
So, it's better to wait till I switch the database. In the meantime I will notice you that I had switched the database.
Thanks!

Hello @dogukan6durukan , i came across this API and liked it very much for my project, at a time it does not works, any updates?


Rails routing using devise and subdomain constraint

Looked at 5 Google search pages before asking it here. Excuse me if this is a repeated Q.
I am trying to route root to devise sign in path under a subdomain constraint.
My config/routes.rb look something like this
Rails.application.routes.draw
  constraints subdomain: 'admin' do
    devise_scope :admin do
      root to: 'devise/sessions#new'

      # here I override devise routes
    end
  end

  root to: 'pages#homepage'

  # rest of the routes
end

I am getting the error Could not find devise mapping for path "/".
Any suggestions as to how I route to root path in a subdomain with devise scope?
Thanks

I have the same problem - if I remove the constraint then it works.

Hi @pradyumna2905, thank you for your report.
Can you provide us a sample application that reproduces the issue in isolation?
That would help us find the issue.
Thank you!

Hi @tegon - is Rails 3.2 still supported by Devise? I've checked and the issue I had was with a 3.2 app (3-2-stable). If it is then I can try and reproduce the issue. Thanks.

@richhollis only for security issues. This doesn't happen on the latest version?


React.NET fails when using Docker

I'm using these library versions:

ReactJS.NET: 5.2.12
JavaScriptEngineSwitcher: Chakra 3.16.0
react and react-dom: (bundled)
docker: v20.10.6

Runtime environment:

OS: Windows 10 (64bit)
.NET Framework or .NET Core Version: .NET core 3.1

Steps to reproduce

Install the "QuickStart" template

dotnet new -i React.Template
dotnet new reactnet-vanilla

Add the following files:
Dockerfile

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-alpine AS base

ARG BUILDCONFIG=RELEASE

RUN apk update && apk add libgdiplus libgdiplus-dev --update-cache --repository http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted
# copy csproj and restore as distinct layers
COPY ./tutorial-code.csproj ./ReactDotNetProject/
RUN dotnet restore ReactDotNetProject/tutorial-code.csproj

# copy everything else and build
COPY ./ ./ReactDotNetProject/
RUN dotnet publish ReactDotNetProject/tutorial-code.csproj --runtime linux-musl-x64 -c $BUILDCONFIG -o out

# build runtime image
FROM mcr.microsoft.com/dotnet/core/runtime-deps:3.1-alpine

RUN apk update && apk add terminus-font libgdiplus libgdiplus-dev --update-cache --repository http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted
ENV ASPNETCORE_URL=http//+:5000
ENV ASPNETCORE_ENVIRONMENT Production

# Expose port 5000 on the container
COPY . /app
WORKDIR /app

COPY --from=base /out ./

EXPOSE 5000
ENTRYPOINT ["./tutorial-code"]

docker-compose.yml
reactdotnet:
    build: .
    ports:
        - "5000:5000"

Change Program.cs to the following:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;

namespace ReactDemo
{
    public class Program
    {
         public static void Main(string[] args)
        {
            CreateHostBuilder(args)
            .Build()
            .Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>().UseUrls(new[] { "http://<IP_ADDRESS>:5000" });  // used for docker connection, will be on localhost on own machine
                });
    }
}

Run docker-compose up --build

Visit localhost:5000 in browser.

Expected Error:
reactdotnet_1  | warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
reactdotnet_1  |       Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
reactdotnet_1  | info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
reactdotnet_1  |       User profile is available. Using '/root/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
reactdotnet_1  | info: Microsoft.Hosting.Lifetime[0]
reactdotnet_1  |       Now listening on: http://<IP_ADDRESS>:5000
reactdotnet_1  | info: Microsoft.Hosting.Lifetime[0]
reactdotnet_1  |       Application started. Press Ctrl+C to shut down.
reactdotnet_1  | info: Microsoft.Hosting.Lifetime[0]
reactdotnet_1  |       Hosting environment: Production
reactdotnet_1  | info: Microsoft.Hosting.Lifetime[0]
reactdotnet_1  |       Content root path: /app
reactdotnet_1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
reactdotnet_1  |       Request starting HTTP/1.1 GET http://localhost:5000/
reactdotnet_1  | info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
reactdotnet_1  |       Executing endpoint 'ReactDemo.Controllers.HomeController.Index (tutorial-code)'
reactdotnet_1  | info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3]
reactdotnet_1  |       Route matched with {action = "Index", controller = "Home"}. Executing controller action with signature Microsoft.AspNetCore.Mvc.ActionResult Index() on controller ReactDemo.Controllers.HomeController (tutorial-code).
reactdotnet_1  | info: Microsoft.AspNetCore.Mvc.ViewFeatures.ViewResultExecutor[1]
reactdotnet_1  |       Executing ViewResult, running view Index.
reactdotnet_1  | info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2]
reactdotnet_1  |       Executed action ReactDemo.Controllers.HomeController.Index (tutorial-code) in 121.9638ms
reactdotnet_1  | info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
reactdotnet_1  |       Executed endpoint 'ReactDemo.Controllers.HomeController.Index (tutorial-code)'
reactdotnet_1  | fail: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[1]
reactdotnet_1  |       An unhandled exception has occurred while executing the request.
reactdotnet_1  | React.Exceptions.ReactNotInitialisedException: ReactJS.NET has not been initialised correctly. Please ensure you have called services.AddReact() and app.UseReact() in your Startup.cs file.
reactdotnet_1  |  ---> React.TinyIoC.TinyIoCResolutionException: Unable to resolve type: React.ReactEnvironment
reactdotnet_1  |  ---> React.TinyIoC.TinyIoCResolutionException: Unable to resolve type: React.JavaScriptEngineFactory
reactdotnet_1  |  ---> JavaScriptEngineSwitcher.Core.JsEngineLoadException: Failed to create instance of the ChakraCoreJsEngine. Most likely it happened, because the 'libChakraCore.so' assembly or one of its dependencies was not found. Try to install the JavaScriptEngineSwitcher.ChakraCore.Native.linux-x64 package via NuGet.
reactdotnet_1  |
reactdotnet_1  | Engine name: ChakraCoreJsEngine
reactdotnet_1  | Engine version: 1.11.13
reactdotnet_1  | Category: Engine load error
reactdotnet_1  | Description: Most likely it happened, because the 'libChakraCore.so' assembly or one of its dependencies was not found. Try to install the JavaScriptEngineSwitcher.ChakraCore.Native.linux-x64 package via NuGet. ---> System.DllNotFoundException: Unable to load shared library 'ChakraCore' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libChakraCore: No such file or directory
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.JsRt.NativeMethods.JsCreateRuntime(JsRuntimeAttributes attributes, JsThreadServiceCallback threadService, JsRuntime& runtime)
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.JsRt.JsRuntime.Create(JsRuntimeAttributes attributes, JsThreadServiceCallback threadServiceCallback)
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ChakraCoreJsEngine.<>c__DisplayClass10_1.<.ctor>b__0()
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ScriptDispatcher.<>c__DisplayClass11_0.<Invoke>b__0()
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ScriptDispatcher.StartThread()
reactdotnet_1  | --- End of stack trace from previous location where exception was thrown ---
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ScriptDispatcher.InnnerInvoke(Func`1 del)
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ScriptDispatcher.Invoke(Action action)
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ChakraCoreJsEngine..ctor(ChakraCoreSettings settings)
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ChakraCoreJsEngine..ctor(ChakraCoreSettings settings)
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ChakraCoreJsEngineFactory.CreateEngine()
reactdotnet_1  |    at JSPool.JsPool`2.CreateEngine()
reactdotnet_1  |    at JSPool.JsPool`2.PopulateEngines()
reactdotnet_1  |    at JSPool.JsPool`2..ctor(JsPoolConfig`1 config)
reactdotnet_1  |    at JSPool.JsPool..ctor(JsPoolConfig config)
reactdotnet_1  |    at React.JavaScriptEngineFactory.CreatePool()
reactdotnet_1  |    at React.JavaScriptEngineFactory..ctor(IJsEngineSwitcher jsEngineSwitcher, IReactSiteConfiguration config, ICache cache, IFileSystem fileSystem)
reactdotnet_1  |    at lambda_method(Closure , Object[] )
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options)
reactdotnet_1  |
reactdotnet_1  |    --- End of inner exception stack trace ---
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, ResolveOptions options)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.SingletonFactory.GetObject(Type requestedType, TinyIoCContainer container, NamedParameterOverloads parameters, ResolveOptions options)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ResolveInternal(TypeRegistration registration, NamedParameterOverloads parameters, ResolveOptions options)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options)
reactdotnet_1  |    --- End of inner exception stack trace ---
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, ResolveOptions options)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.CustomObjectLifetimeFactory.GetObject(Type requestedType, TinyIoCContainer container, NamedParameterOverloads parameters, ResolveOptions options)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ResolveInternal(TypeRegistration registration, NamedParameterOverloads parameters, ResolveOptions options)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.Resolve(Type resolveType)
reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.Resolve[ResolveType]()
reactdotnet_1  |    at React.ReactEnvironment.get_Current()
reactdotnet_1  |    at React.ReactEnvironment.get_GetCurrentOrThrow()
reactdotnet_1  |    --- End of inner exception stack trace ---
reactdotnet_1  |    at React.ReactEnvironment.get_GetCurrentOrThrow()
reactdotnet_1  |    at React.AspNet.HtmlHelperExtensions.get_Environment()
reactdotnet_1  |    at React.AspNet.HtmlHelperExtensions.React[T](IHtmlHelper htmlHelper, String componentName, T props, String htmlTag, String containerId, Boolean clientOnly, Boolean serverOnly, String containerClass, Action`3 exceptionHandler, IRenderFunctions renderFunctions)
reactdotnet_1  |    at AspNetCore.Views_Home_Index.<ExecuteAsync>b__8_1() in /ReactDotNetProject/Views/Home/Index.cshtml:line 10
reactdotnet_1  |    at Microsoft.AspNetCore.Razor.Runtime.TagHelpers.TagHelperExecutionContext.SetOutputContentAsync()
reactdotnet_1  |    at AspNetCore.Views_Home_Index.ExecuteAsync() in /ReactDotNetProject/Views/Home/Index.cshtml:line 3
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderPageCoreAsync(IRazorPage page, ViewContext context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderPageAsync(IRazorPage page, ViewContext context, Boolean invokeViewStarts)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderAsync(ViewContext context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.ViewFeatures.ViewExecutor.ExecuteAsync(ViewContext viewContext, String contentType, Nullable`1 statusCode)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.ViewFeatures.ViewExecutor.ExecuteAsync(ActionContext actionContext, IView view, ViewDataDictionary viewData, ITempDataDictionary tempData, String contentType, Nullable`1 statusCode)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.ViewFeatures.ViewResultExecutor.ExecuteAsync(ActionContext context, ViewResult result)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.ViewResult.ExecuteResultAsync(ActionContext context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResultFilterAsync>g__Awaited|29_0[TFilter,TFilterAsync](ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResultExecutedContextSealed context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.ResultNext[TFilter,TFilterAsync](State& next, Scope& scope, Object& state, Boolean& isCompleted)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeResultFilters()
reactdotnet_1  | --- End of stack trace from previous location where exception was thrown ---
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
reactdotnet_1  | --- End of stack trace from previous location where exception was thrown ---
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
reactdotnet_1  |    at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
reactdotnet_1  |    at React.AspNet.BabelFileMiddleware.Invoke(HttpContext context)
reactdotnet_1  |    at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
reactdotnet_1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
reactdotnet_1  |       Request finished in<PHONE_NUMBER>0000002ms 404
reactdotnet_1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
reactdotnet_1  |       Request starting HTTP/1.1 GET http://localhost:5000/favicon.ico
reactdotnet_1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
reactdotnet_1  |       Request finished in 6.6058ms 404

This is a surprising error since the tutorial-code.csproj file has the JavascriptEngineSwitcher.ChakraCore.native.linux-x64 package.
When I run dotnet run and visit localhost:5000 (on Windows), the program works as expected.
When I shell into the docker container it also seems to be installing the JavascriptEngineSwitcher.ChakraCore.native.linux-x64 package.
What can be done to fix this? All help is appreciated

Weird. My first thought is to try it in a non container environment (Ubuntu
WSL) and see if it crashes there too. I can’t think of a Docker specific
limitation that would prevent the native lib from loading..
On Sun, Dec 12, 2021 at 16:42, Atli Gíslason @.***>
wrote:

I'm using these library versions:

ReactJS.NET: 5.2.12
JavaScriptEngineSwitcher: Chakra 3.16.0
react and react-dom: (bundled)
docker: v20.10.6

Runtime environment:

OS: Windows 10 (64bit)
.NET Framework or .NET Core Version: .NET core 3.1

Steps to reproduce

Install the "QuickStart" template

dotnet new -i React.Template
dotnet new reactnet-vanilla

Add the following files:
Dockerfile

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-alpine AS base
ARG BUILDCONFIG=RELEASE
RUN apk update && apk add libgdiplus libgdiplus-dev --update-cache --repository http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted
copy csproj and restore as distinct layers
COPY ./tutorial-code.csproj ./ReactDotNetProject/
RUN dotnet restore ReactDotNetProject/tutorial-code.csproj
copy everything else and build
COPY ./ ./ReactDotNetProject/
RUN dotnet publish ReactDotNetProject/tutorial-code.csproj --runtime linux-musl-x64 -c $BUILDCONFIG -o out
build runtime image
FROM mcr.microsoft.com/dotnet/core/runtime-deps:3.1-alpine
RUN apk update && apk add terminus-font libgdiplus libgdiplus-dev --update-cache --repository http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted
ENV ASPNETCORE_URL=http//+:5000
ENV ASPNETCORE_ENVIRONMENT Production
Expose port 5000 on the container
COPY . /app
WORKDIR /app
COPY --from=base /out ./
EXPOSE 5000
ENTRYPOINT ["./tutorial-code"]
docker-compose.yml
reactdotnet:
build: .
ports:
- "5000:5000"

Change Program.cs to the following:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;
namespace ReactDemo
{
public class Program
{
public static void Main(string[] args)
{
CreateHostBuilder(args)
.Build()
.Run();
}
    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>().UseUrls(new[] { "http://<IP_ADDRESS>:5000" });  // used for docker connection, will be on localhost on own machine
            });
}

}

Run docker-compose up --build
2.
Visit localhost:5000 in browser.
Expected Error:
reactdotnet_1  | warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
reactdotnet_1  |       Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
reactdotnet_1  | info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
reactdotnet_1  |       User profile is available. Using '/root/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
reactdotnet_1  | info: Microsoft.Hosting.Lifetime[0]
reactdotnet_1  |       Now listening on: http://<IP_ADDRESS>:5000
reactdotnet_1  | info: Microsoft.Hosting.Lifetime[0]
reactdotnet_1  |       Application started. Press Ctrl+C to shut down.
reactdotnet_1  | info: Microsoft.Hosting.Lifetime[0]
reactdotnet_1  |       Hosting environment: Production
reactdotnet_1  | info: Microsoft.Hosting.Lifetime[0]
reactdotnet_1  |       Content root path: /app
reactdotnet_1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
reactdotnet_1  |       Request starting HTTP/1.1 GET http://localhost:5000/
reactdotnet_1 http://localhost:5000/reactdotnet_1  | info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
reactdotnet_1  |       Executing endpoint 'ReactDemo.Controllers.HomeController.Index (tutorial-code)'
reactdotnet_1  | info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3]
reactdotnet_1  |       Route matched with {action = "Index", controller = "Home"}. Executing controller action with signature Microsoft.AspNetCore.Mvc.ActionResult Index() on controller ReactDemo.Controllers.HomeController (tutorial-code).
reactdotnet_1  | info: Microsoft.AspNetCore.Mvc.ViewFeatures.ViewResultExecutor[1]
reactdotnet_1  |       Executing ViewResult, running view Index.
reactdotnet_1  | info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2]
reactdotnet_1  |       Executed action ReactDemo.Controllers.HomeController.Index (tutorial-code) in 121.9638ms
reactdotnet_1  | info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
reactdotnet_1  |       Executed endpoint 'ReactDemo.Controllers.HomeController.Index (tutorial-code)'
reactdotnet_1  | fail: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[1]
reactdotnet_1  |       An unhandled exception has occurred while executing the request.
reactdotnet_1  | React.Exceptions.ReactNotInitialisedException: ReactJS.NET has not been initialised correctly. Please ensure you have called services.AddReact() and app.UseReact() in your Startup.cs file.
reactdotnet_1  |  ---> React.TinyIoC.TinyIoCResolutionException: Unable to resolve type: React.ReactEnvironment
reactdotnet_1  |  ---> React.TinyIoC.TinyIoCResolutionException: Unable to resolve type: React.JavaScriptEngineFactory
reactdotnet_1  |  ---> JavaScriptEngineSwitcher.Core.JsEngineLoadException: Failed to create instance of the ChakraCoreJsEngine. Most likely it happened, because the 'libChakraCore.so' assembly or one of its dependencies was not found. Try to install the JavaScriptEngineSwitcher.ChakraCore.Native.linux-x64 package via NuGet.
reactdotnet_1  |
reactdotnet_1  | Engine name: ChakraCoreJsEngine
reactdotnet_1  | Engine version: 1.11.13
reactdotnet_1  | Category: Engine load error
reactdotnet_1  | Description: Most likely it happened, because the 'libChakraCore.so' assembly or one of its dependencies was not found. Try to install the JavaScriptEngineSwitcher.ChakraCore.Native.linux-x64 package via NuGet. ---> System.DllNotFoundException: Unable to load shared library 'ChakraCore' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libChakraCore: No such file or directory
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.JsRt.NativeMethods.JsCreateRuntime(JsRuntimeAttributes attributes, JsThreadServiceCallback threadService, JsRuntime& runtime)
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.JsRt.JsRuntime.Create(JsRuntimeAttributes attributes, JsThreadServiceCallback threadServiceCallback)
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ChakraCoreJsEngine.<>c__DisplayClass10_1.<.ctor>b__0()
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ScriptDispatcher.<>c__DisplayClass11_0.b__0()
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ScriptDispatcher.StartThread()
reactdotnet_1  | --- End of stack trace from previous location where exception was thrown ---
reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ScriptDispatcher.InnnerInvoke(Func1 del) reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ScriptDispatcher.Invoke(Action action) reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ChakraCoreJsEngine..ctor(ChakraCoreSettings settings) reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ChakraCoreJsEngine..ctor(ChakraCoreSettings settings) reactdotnet_1  |    at JavaScriptEngineSwitcher.ChakraCore.ChakraCoreJsEngineFactory.CreateEngine() reactdotnet_1  |    at JSPool.JsPool2.CreateEngine()
reactdotnet_1  |    at JSPool.JsPool2.PopulateEngines() reactdotnet_1  |    at JSPool.JsPool2..ctor(JsPoolConfig1 config) reactdotnet_1  |    at JSPool.JsPool..ctor(JsPoolConfig config) reactdotnet_1  |    at React.JavaScriptEngineFactory.CreatePool() reactdotnet_1  |    at React.JavaScriptEngineFactory..ctor(IJsEngineSwitcher jsEngineSwitcher, IReactSiteConfiguration config, ICache cache, IFileSystem fileSystem) reactdotnet_1  |    at lambda_method(Closure , Object[] ) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options) reactdotnet_1  | reactdotnet_1  |    --- End of inner exception stack trace --- reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, ResolveOptions options) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.SingletonFactory.GetObject(Type requestedType, TinyIoCContainer container, NamedParameterOverloads parameters, ResolveOptions options) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ResolveInternal(TypeRegistration registration, NamedParameterOverloads parameters, ResolveOptions options) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options) reactdotnet_1  |    --- End of inner exception stack trace --- reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, NamedParameterOverloads parameters, ResolveOptions options) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ConstructType(Type requestedType, Type implementationType, ConstructorInfo constructor, ResolveOptions options) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.CustomObjectLifetimeFactory.GetObject(Type requestedType, TinyIoCContainer container, NamedParameterOverloads parameters, ResolveOptions options) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.ResolveInternal(TypeRegistration registration, NamedParameterOverloads parameters, ResolveOptions options) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.Resolve(Type resolveType) reactdotnet_1  |    at React.TinyIoC.TinyIoCContainer.Resolve[ResolveType]() reactdotnet_1  |    at React.ReactEnvironment.get_Current() reactdotnet_1  |    at React.ReactEnvironment.get_GetCurrentOrThrow() reactdotnet_1  |    --- End of inner exception stack trace --- reactdotnet_1  |    at React.ReactEnvironment.get_GetCurrentOrThrow() reactdotnet_1  |    at React.AspNet.HtmlHelperExtensions.get_Environment() reactdotnet_1  |    at React.AspNet.HtmlHelperExtensions.React[T](IHtmlHelper htmlHelper, String componentName, T props, String htmlTag, String containerId, Boolean clientOnly, Boolean serverOnly, String containerClass, Action3 exceptionHandler, IRenderFunctions renderFunctions)
reactdotnet_1  |    at AspNetCore.Views_Home_Index.b__8_1() in /ReactDotNetProject/Views/Home/Index.cshtml:line 10
reactdotnet_1  |    at Microsoft.AspNetCore.Razor.Runtime.TagHelpers.TagHelperExecutionContext.SetOutputContentAsync()
reactdotnet_1  |    at AspNetCore.Views_Home_Index.ExecuteAsync() in /ReactDotNetProject/Views/Home/Index.cshtml:line 3
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderPageCoreAsync(IRazorPage page, ViewContext context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderPageAsync(IRazorPage page, ViewContext context, Boolean invokeViewStarts)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderAsync(ViewContext context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.ViewFeatures.ViewExecutor.ExecuteAsync(ViewContext viewContext, String contentType, Nullable1 statusCode) reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.ViewFeatures.ViewExecutor.ExecuteAsync(ActionContext actionContext, IView view, ViewDataDictionary viewData, ITempDataDictionary tempData, String contentType, Nullable1 statusCode)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.ViewFeatures.ViewResultExecutor.ExecuteAsync(ActionContext context, ViewResult result)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.ViewResult.ExecuteResultAsync(ActionContext context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|29_0[TFilter,TFilterAsync](ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResultExecutedContextSealed context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.ResultNext[TFilter,TFilterAsync](State& next, Scope& scope, Object& state, Boolean& isCompleted)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeResultFilters()
reactdotnet_1  | --- End of stack trace from previous location where exception was thrown ---
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
reactdotnet_1  | --- End of stack trace from previous location where exception was thrown ---
reactdotnet_1  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|17_1(ResourceInvoker invoker)
reactdotnet_1  |    at Microsoft.AspNetCore.Routing.EndpointMiddleware.g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
reactdotnet_1  |    at React.AspNet.BabelFileMiddleware.Invoke(HttpContext context)
reactdotnet_1  |    at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
reactdotnet_1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
reactdotnet_1  |       Request finished in<PHONE_NUMBER>0000002ms 404
reactdotnet_1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
reactdotnet_1  |       Request starting HTTP/1.1 GET http://localhost:5000/favicon.ico
reactdotnet_1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
reactdotnet_1  |       Request finished in 6.6058ms 404

This is a surprising error since the tutorial-code.csproj file has the
JavascriptEngineSwitcher.ChakraCore.native.linux-x64 package.
When I run dotnet run and visit localhost:5000 (on Windows), the program
works as expected.
When I shell into the docker container it also seems to be installing the
JavascriptEngineSwitcher.ChakraCore.native.linux-x64 package.
What can be done to fix this? All help is appreciated
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/reactjs/React.NET/issues/1274, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHGCFSY7NA4NOD2AQW23KDUQUJM5ANCNFSM5J4W3KVQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Since the stack trace is in JavaScriptEngineSwitcher, you could try asking @Taritsyn over in the project's repo: https://github.com/Taritsyn/JavaScriptEngineSwitcher/issues

I'll try that. Thanks!


Update Python file headers

Currently,
#
# This file is part of khmer, http://github.com/ged-lab/khmer/, and is
# Copyright (C) Michigan State University, 2014. It is licensed under
# the three-clause BSD license; see doc/LICENSE.txt.
# Contact<EMAIL_ADDRESS>
#

We should update copyright year to 2014 in all files; point to 'LICENSE' instead of doc/LICENSE.txt; and make sure that each file has this, and that they're not docstrings.

Working on this.

Is this still open? Looks like it might be resolved.

Ditto -- looks resolved but still open.

Hello, looks like some of the copyright headers are still out of date. I'm working on fixing them.

I fixed most of them in PR #928... I almost have the merge complete but finish this IPython project first.

Hi Scott, it looks like you changed the license but not the end date on the
copyright line. I'm just doing the latter which is changing the date ranges
20??-2014 to 20??-2015 if there was a commit in 2015.
On Mon, Apr 13, 2015 at 4:02 PM, Scott S<EMAIL_ADDRESS>wrote:

I fixed most of them in PR #928
https://github.com/ged-lab/khmer/pull/928... I almost have the merge
complete but finish this IPython project first.
—
Reply to this email directly or view it on GitHub
https://github.com/ged-lab/khmer/issues/482#issuecomment-92481283.

Cool! So are you/have you managed the issues with LICENSE as well?

I've been leaving that alone, hoping my stuff will merge nicely with yours.
On Mon, Apr 13, 2015 at 4:51 PM, Scott S<EMAIL_ADDRESS>wrote:

Cool! So are you/have you managed the issues with LICENSE as well?
—
Reply to this email directly or view it on GitHub
https://github.com/ged-lab/khmer/issues/482#issuecomment-92494478.

Fixed by #928