[Jetcaster]: Podcast screen

Changes:

Added podcast details screen.
Added external models PodcastInfo, EpisodeInfo and CategoryInfo so that composables don't depend on database entities (Podcast, Episode and `Category) directly.

Note that design is not final yet but will address that in another PR.

Now that there are models for the UI, I'd update PreviewData to use those directly. For example, it's a little weird to have
val PreviewEpisodeToPodcasts = listOf(
    EpisodeToPodcast().apply {
        episode = PreviewEpisodes.first()
        _podcasts = PreviewPodcasts
    }
)

and then in the preview itself, it uses asPodcastCategoryEpisode to convert everything. I think PreviewData shouldn't need com.example.jetcaster.core.data.database.* imports anymore.

Done in 1c94c881

This is ready for review again. PTAL @IanGClifton when you have a moment.


Response defined as Record is converted to 204

When response type is Record<unknown>, typespec automatically converts it to 204 (even if I specify a 200)
Playground

Closing this issue since this is a duplicate. https://github.com/microsoft/typespec/issues/2542


PR patch fail in action from yesterday

salamon alaykom fawaz ,
my uploaded videos from yesterday have hardsub caption & video title in english but older than this time all videos have persian hard sub caption & title. please check what commit branch or any other reason doing this problem .
mychannel url is : https://youtube.com/channel/UCwwA2OJytVk8mtkv3JoAkfw
waiting for your response
finest regards

you can delete the english videos, I have stopped the program
the work is complete as all the persian quran videos are uploaded in your youtube channel 👍

hello again fawaz ,
please don't stop the upload session ,
i can archive all others then please don't stop upload other languages.
waiting for your response
finesr regards


add information about local platform independent builds

Summary
from #89 I added the actual information to the readme how to build the exporter locally for different platforms
Checklist

[x] Update documentation.
[x] Link this PR to related issues.

Thanks @mabunixda !


Better support for crawling and dynamic pooling

I want to create some kind of crawler with a dynamic pool size. It all starts with a single url, which is analyzed and more urls become available... Well, you get the point of crawling.
For this I use a generator function. Sometimes, the generator is unable to fill all the places in the pool and it returns null. On null, the pool decides the generator has ended and won't look for new urls anymore.
I've created a very dirty hack, which is working:
$urls = \ArrayObject(['http://test']);
$maxPoolSize = 8;
$self = $this;
$urlGenerator = function () use ($urls, $maxPoolSize, $self) {
	for ($i=0; $i<count($urls); $i++) {
		if ($maxPoolSize > count($urls) - $i) {
			$size = count($urls) - $i;
			if ($size > 1) {
				$size--; // Make sure not to set the pool smaller, so not all urls will be requested
			}
                        // getEach was hacked in by me, also set concurrency
			$self->pool->getEach()->setConcurrency($size);
		} else {
                        // getEach was hacked in by me, also set concurrency
			$self->pool->getEach()->setConcurrency($maxPoolSize);
		}

		yield new \GuzzleHttp\Psr7\Request('GET', $urls[$i]);
		// A hack to provide a request, null would be nicer, but stops the bool
		if ($i===0 && count($urls)-$i === 1) {
			yield new \GuzzleHttp\Psr7\Request('GET', $urls[$i]);
		}
	}
};

$this->pool = new \GuzzleHttp\Pool($client, $urlGenerator(), [
	'concurrency'=>$poolSize,
	'fulfilled' => function ($response, $index) use ($self) {
		$self->processResult($response);
	},
	'rejected' => function ($reason, $index) {

	}
]);

$this->pool->promise()->wait(false);

I have to add, the dynamic pool size should not be necessary if a null return value from a generator was accepted, but I think this is a nicer solution then returning null.

On null, the pool decides the generator has ended and won't look for new urls anymore.

Kind of... Really the generator determines that null is not a request or callable, so it rejects the entire pool: https://github.com/guzzle/guzzle/blob/master/src/Pool.php#L58

I have to add, the dynamic pool size should not be necessary if a null return value from a generator was accepted, but I think this is a nicer solution then returning null.

Can you make a concrete suggestion on what you'd like this to do? I think it works pretty well... I imagine you could implement a crawler as follows:

The pool size function returns 1 on the first call because it's the entry URI.
The pool fills up the list of concurrent requests, gets the response, and places all the URIs to crawl into a queue. This logic could be in the 'fulfilled' method of the pool.
The pool size function now returns the min of your max pool size and the size of the queue (this ensures that you are never sending more requests than your maximum pool size and you are not having to try to hack around the fact that you cannot yield null in the generator).
While there are items in the queue, go to step 2.

I'm trying to follow you, I think the example below illustrates what you mean, but it also illustrates my problem. If there is one item in the queue and this is yielded, the pool just stops. (if you add two urls to the start array, it will keep running, which is what we want.
Working snippiet:
$client = new \GuzzleHttp\Client();

$urls = ['http://google.com/'];
$urlGenerator = function () use (&$urls) {
    for ($i=0; $i<count($urls); $i++) {
        $url = $urls[$i];
        yield new \GuzzleHttp\Psr7\Request('GET', $url);
        echo 'Yielded ' . $url . PHP_EOL;
    }
};

$pool = new \GuzzleHttp\Pool($client, $urlGenerator(), [
    'concurrency' => function () {
        return 1;
    },
    'fulfilled' => function ($response, $index) use (&$urls) {
        $urls[] = 'http://nu.nl';
        $urls[] = 'http://tweakers.net';
    },
    'rejected' => function ($reason, $index) {}
]);
$pool->promise()->wait();

I just really dug into the generators in PHP. I wasn't sure if the code above should work as i expected. I did some more experimenting and I think it should work. I created some very similar structures on the command line, and those scripts kept running. I'll now dive into Guzzle to see what I can find out.

I found out that the fulfilled function is called later than the next value is yielded from the generator.

You're right. I've been trying to find a way to update EachPromise to work around this, but I'm still not sure how to fix this. See https://github.com/guzzle/promises/blob/master/src/EachPromise.php
Basically the calls to valid on the iterator advance the iterator before new URLs can be added.

I may have a solution actually. Here's the pull request I opened: https://github.com/guzzle/promises/pull/5
And here's some code that works with it:
<?php
require 'vendor/autoload.php';

use GuzzleHttp\Client;
use GuzzleHttp\Psr7\Request;

$client = new Client(['http_errors' => false]);

$urls = ['http://mtdowling.com/start'];

$urlGenerator = function () use (&$urls) {
    while ($url = array_pop($urls)) {
        echo "Yielding: $url\n";
        yield new Request('GET', $url);
    }
    echo "Exiting...\n";
};

$remaining = 20;

$pool = new \GuzzleHttp\Pool($client, $urlGenerator(), [
    'concurrency' => function () use (&$urls) {
        // Yield at most 3 URIs, and at minimum 1 URI.
        return max(1, min(count($urls), 3));
    },
    'fulfilled' => function ($response) use (&$urls, &$remaining) {
        // Parse the URIs and add them to the queue... Or fake it :)
        if ($remaining > 0) {
            $urls[] = 'http://mtdowling.com/' . $remaining--;
            $urls[] = 'http://mtdowling.com/' . $remaining--;
            $urls[] = 'http://mtdowling.com/' . $remaining--;
        }
    },
    'rejected' => function ($reason, $index) {
        echo "Error: {$reason}\n\n";
    }
]);

$pool->promise()->wait();

https://github.com/guzzle/promises/pull/5 was merged. Can you try this out and let me know if this solves your use case?

Great. This indeed solved my issue. Great work!

Awesome. I'll close this and get a release of the promises library tagged soon.


update maintainers

The current list of maintainers is quite outdated, and we plan to integrate libnetwork into the main Moby repository.
Before doing this, we may still need to review and merge fixes that are pending in this repository (as well as maintain a branch for the 20.10 release until it reaches EOL).
This patch adds some of the (currently) active maintainers of the moby project to the maintainers list.

@AkihiroSuda @arkodg @cpuguy83 @mavenugo @tonistiigi @tianon PTAL
FWIW; I don't expect massive redesign/refactors to be done in this repository, but having more people to allow us to review/merge pending fixes / low-hanging fruit / safe-to-merge PRs at least allows us to move things if needed.

What's current status?

+1 to this
since its been years since Ive contributed on this project and spend cycles on it, prefer if I was removed (and moved into a emeritus), can raise a separate PR to do so

Thanks @arkodg! I considered asking the old maintainers to step down, but also considered that this repository will be archived once 20.10 fully reaches end of the line (I know Mirantis still continues support for their LTS runtime, and perhaps Azure (@cpuguy83 would probably know)).
With that in mind, I didn't want to spend too much time on that. (In short: I'm fine with the old maintainers to continue to be listed, but of course also happy to accept PRs for those that want to step down!).
(Should I mention the 3rd option? pst: we're hiring, and I'd be happy to have you on my team ❤ 🤗 )

I'll be going ahead and bring this PR in; we discussed this in our maintainers call, and this change is mostly to allow us to backport changes from moby/moby (where the libnetwork code was moved to).
I'll send out an invite to those who were added (@akihirosuda @tianon @tonistiigi @vvoland @neersighted @rumpl @corhere @cpuguy83)


Wizard naming

The current naming convention for the functions wizard places the name of the fixture at the end. This makes it hard to find all the scences that relate to a certain fixture

I find it much better to see all the scenes for the same fixure grouped together like this

https://qlcplus.org/forum/viewtopic.php?t=16337

Just found an issue, the name widget in the solo frame has changed to match the scene name, not the shorter form. Not sure why

This would save me so much time!

Coverage: 28.084% (+0.002%) from 28.082% when pulling e96979c1f2771c3abbf0255b3e515e690479745f on netmindz:wizard-naming into 84886d3466f08099a157ed6abda2998eb74a60e7 on mcallegari:master.

The only downside I spotted while testing @mcallegari was that when you see the scene name in the cluelist, you can't really see what is what unless you scroll horizontally, but if you do so, then the scroll resets back on the next cue. Not a huge issue as generally you don't need to know the name of the scene at all time


grunt drush:liteinstall fails

grunt drush:liteinstall

fails with message
Cannot use GuzzleHttp\Ring\Client\Middleware as Middleware because the name is already in use in /Library/WebServer/Documents/drupal/grunt-test/d8-test/vendor/guzzlehttp/guzzle/src/Utils.php on line 7

anyone have any ideas about how to fix this? :palm_tree:

Do you still get this if you run the latest (Beta15) Drupal 8 and Behat Drupal Extension (3.1.1)? Guzzle was updated which temporarily caused compatibility issues between Drupal 8 and the Behat Drupal Extension.

I just saw this error, but it was on an older install. Once I added this line to composer.json:
    "require-dev": {
        "guzzlehttp/guzzle" : "^6.0@dev"

and re-ran composer install, it went away (it was also still running beta14, which causes a different fatal error, so upgrading to beta 15 resolved that too).


[WIP] Add or Edit access role fails

WIP  - will add specs

@miq-bot add_label ui, bug, wip

thanks for all the help @lgalis


Make browser tests work again

Adding my Sauce Labs account with the hope to actually test in 11 browsers on Sauce Labs
I am uncertain if this is enough by itself, since the abandoned project had
credentials already (probably from @jharding)
Originally added to twitter/typeahead.js in July 2014
https://github.com/twitter/typeahead.js/commit/f5af04bebac5ffbbc1350c451504529826e31a0b
In case you want to revisit this in 5 years, my saucelab user account is 'jesperronn'
When this PR works, it will fix #20

hmm, https://github.com/jesperronn/typeahead.js/commit/42aabc6d9a3c74773e8f7f1201b48f91e15da543 didn't work. The browser tests still don't run since "$TRAVIS_SECURE_ENV_VARS" still evaluates to false
Will put this PR in WIP until I'm satisfied. Feel free to help :)

@jesperronn I think you might need to add
TRAVIS_SECURE_ENV_VARS = true

or
$TRAVIS_SECURE_ENV_VARS = true

to travis-ci.org:corejavascript/typeahead.js/settings.

Hmm https://github.com/jesperronn/typeahead.js/commit/cddcbbe733ea2d8911873cece70c53662b2ae4e6 did not work either. From the Travis configuration I read that

Encrypted environment variables are not available to pull requests from forks due to the security
risk of exposing such information to unknown code.

Which means that this Pull request will never run the saucelabs tests.

@jesperronn & @ApfelUser Due to the Travis environment var limitation on pull requests noted above, I suggest we just merge this PR and see what happens. It won't break anything in terms of actual functionality.

@jlbooker & @corejavascript/collaborators Even though this were merged, my preliminary findings show me that I cannot even run these locally... perhaps some package inconsistency. I would love to solve #26 so that we can actually verify the tests locally (just for Phantom or Chrome).
Preferably work on with this after a solution has been provided for #26

@jesperronn Thanks for the update! (Sorry for the late reply, didn't see the GH notification!)
Moving this to the next milestone so we can get this release out the door. Let's continue working on this.

We should really revive this before merging too many merge requests...

Closing this as it has been open for ages. Feel free to reopen if you feel this is still relevant.


App keeps crashing or freezes for a few minutes when I want to access the list of recordings

Once its loaded, it works fine. But to initially load the recordings tab always takes very long.
Desktop version, windows 10.

Could you try deleting a few of your past recordings? I'm currently working on #285 and hope to push a fix soon!
The lag is probably the browser attempting to load blob files for many audio files at once (I don't have lazy loading enabled)
An alternative fix could also be to use the dropdown to toggle the audio blob column (so it won't be displayed).

I'm experiencing the same freezing issue with the desktop version on a MacBook M1 Pro with 16 GB of RAM. On my MacBook, it freezes for only a few seconds, which is still quite annoying.
It's probably because suddenly many records are being loaded. I've already posted a feature request here suggesting that it should be possible to set a specific time period for which records are kept and then automatically deleted.
To prevent the freezing phenomenon, I always go into the recordings when I remember and delete everything manually. As mentioned, it would be desirable if this could happen automatically.

Okay, yeah, deleting fixed this.
I had 1667 recordings 😅
In that light, once again, THANK YOU, for building this cool app I use constantly, Braden. Especially in respect of your obvious workload at uni. Much appreciated.
I will close this issue, as you are already working on it via #285 .

Aww thank you Rick! Appreciate it :')
And yes, will be making progress this through #285 , thank you @rkhrkh again for the suggestions! Appreciate it a lot.


Error response in JSON format

UC: Implementing an async request.

while processing the request, an error condition occurs and it is necessary to inform client about the problem (preferably JSON)
when an error occurs in the service, there are 2 cases:

rejecting the returned promise => content type is set to: text/html
an exception is thrown => again, content type is set to: text/html

Desired behavior:

when an object is returned via reject(object), send back JSON (as for regular response)
when an exception is thrown, allow service to set content type and respond with JSON

Suggested workaround:
app.use((err: any, req: express.Request, res: express.Response, next: express.NextFunction) => {
if (err instanceof BadRequestError){
res.set("Content-Type", "application/json")
res.status(err.statusCode)
res.json({info : err.message, data: err.data});
} else {
next(err);
}
});
This works fine here:
@Path("dummy1")
@GET
dummy1(): Promise {
return new Promise(function (resolve, reject) {
throw new BadRequestError("Works fine, JSON is sent",{some:"data"});
});
}
But it does not work here:
@Path("dummy2")
@GET
dummy2(): Promise {
return new Promise(function (resolve, reject) {
setTimeout(()=>{
throw new BadRequestError("error handling not applied",{some:"data"});
},1000);
});
}

👍
For the moment I use your workaround.

Hi,
Express uses an error handler middleware that is called to process exceptions that are not handled by its routes.
It has a default error handler middleware (see this) that uses a module called finalhandler to process all uncaught errors.
As you can see in the finalhandler documentation, it will always send an HTML page containing the description of the error (the error message) and, if not running in a production environment, a stack trace.
This is not implemented by typescript-rest, but is the default behavior of expressjs itself. So, if we want to override this behavior, we need to provide our own error handler implementation, that would handle the error before it is raised to the express default middleware.
This can be done, as @mrslnv already posted previously, writing something like:
import { HttpError } from 'typescript-rest';
app.use((err: any, req: express.Request, res: express.Response, next: express.NextFunction) => {
  if (err instanceof HttpError){
    if (res.headersSent) { // important to close connection if headers already sent
      return next(err)
    }
    res.set("Content-Type", "application/json")
    res.status(err.statusCode)
    res.json({error : err.message, code: err.statusCode});
  } else {
    next(err);
  }
});

However, the last situation showed by @mrslnv will never work:
@path("dummy2")
@get
dummy2(): Promise {
  return new Promise(function (resolve, reject) {
    setTimeout(()=>{
      throw new BadRequestError("error handling not applied",{some:"data"});
    },1000);
  });
}

That code are not catching the exception and rejecting the promise. The exception will be lost and can not be sent to express error handling. To this code work, it needs to be refactored to something like:
@path("dummy2")
@get
dummy2(): Promise {
  return new Promise(function (resolve, reject) {
    setTimeout(()=>{
      try {
        throw new BadRequestError("error handling not applied",{some:"data"});
      catch(e) {
        return reject(e);
      }
    },1000);
  });
}

We could create an errorHandler like that one above and register it in typescript-rest library (maybe through some method like (Server.useJsonErrorHandler();)) or something like this. But I don't know if it is a good idea.
Some people will need to sent a json like:
{ "error": "my message"}

... while others will prefer:
{ "message": "my message", "status": 403}

And so on...
So I think that the most reasonable solution is to allow the developer to specify how he wants to sent his error.... And express already allow it through a custom error handler. So, do you think that it is already necessary to create another method for this?

Thanks for extensive explanation!
I agree that it would be enough if this case is discussed and described in the documentation (which is very good).

How about using JSON.stringify and JSON.parse?
app.use(
      (
        err: any,
        req: express.Request,
        res: express.Response,
        next: express.NextFunction
      ) => {
        if (err instanceof Errors.HttpError) {
          res.set("Content-Type", "application/json");
          res.status(err.statusCode);
          try {
            const parsed = JSON.parse(err.message);
            res.json(parsed);
            return;
          }
          catch (e) {
            res.json({ message: err.message });
            return;
          }
        } else {
          next(err);
        }
      }
    );

throw new Errors.ForbiddenError(JSON.stringify({ message: "Error msg", code: "error-code" }));


Still Crashing when using W+click

Pressing w + click an item into your portable crafting table casues a crash with the latest versions of this mod. It does not crash when doing so in a vanilla crafting bench.  http://pastebin.com/FkWFeNTg
I also lost some items when doing this but I cannot reproduce. I lost a resonant jet pack and some fluxducts. Luckily I'm in sp so I just spawned them back in

Did you update CraftingCraft as well?

Yes I did and also have the lastest trashslot 1.0.31 installed
http://i.imgur.com/SMVSORJ.png

Ah. There's a newer version for CraftingCraft but I forgot to upload it to CurseForge. It should be up in a bit (http://jenkins.blay09.net/job/CraftingCraft 1.7.10/lastSuccessfulBuild/).
TrashSlot never deletes items unless they're replaced by another item within the trash slot. So as long as you don't use the trash slot for storage or randomly click the delete key on items, there should be no problem.

That fixed the crashing. Thank!  I'll close this for now


Verified Twitter account icon

If an account is in the whitelist, display a "verified by ESL" icon next to their tweets.

https://github.com/409H/EtherSecurityLookup/pull/5


Game addition

Can you please add the Assassin's Creed games for the Switch:

Assassin's Creed: The Ezio Collection
Assassin's Creed III Remastered
Assassin's Creed: The Rebel Collection

I have added the game(s) you requested in the most recent release: https://github.com/hobby-grade/Nintendo-Switch-Discord-Status/releases/tag/<IP_ADDRESS>
Thank you for checking out the project, reach out if you have any more suggestions!


docs(auth): add usage docs

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/graycoreio/daffodil/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[x] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Fixes: N/A
What is the new behavior?
Does this PR introduce a breaking change?
[ ] Yes
[ ] No

Other information

@damienwebdev and I were talking about how providing custom drivers and transformers would work, and it turns out that the driver service almost never needs to be overridden. Usually the only thing an app dev will want that is custom is specific data from a backend platform, which means they need only custom models and custom transformers. So as long as there exists generic transformer interfaces and a generic interface and instance of a driver, the app dev should only need to override the transformer. I just mention this here, because it might make more sense for the readme to say that they usually only need to override the transformers and extend the daffodil models.

@lderrickable Should I mention the service customization as an optional step or omit it entirely?

TLDR: no just omit it.
I think we omit for now, because if they're overriding the driver service, they should have a really good idea what they're doing. If they override the service (presumably to make a completely different service call), then I'm not sure they'll even be able to use the redux state we provide as it exists now. Damien has been talking about possibly getting rid of the actions and effects layer in daffodil and allow the user to provide that for better action hygiene. And maybe there'll be a more refined process for providing a custom driver, but for now it doesn't really make sense to override it.

I don't think that this is sufficient docs to explain the use case.


Comparing image-text pairs

I'm exploring CLIP for similar product retrieval by combining a product's description and image as input. As I understand, CLIP excels at image-to-text and text-to-image retrieval tasks, but I'm curious about its capability to handle integrated text and image inputs. Is this possible with CLIP and does anyone have examples?

Please check this: https://github.com/openai/CLIP/issues/115.


Load cosmiconfig own options the same way it does for the other modules

Hi ! :)
Wouldn't it be nice to have cosmiconfig load its own options (a.k.a cosmiconfigOptions) in exactly the same way as it does for the modules ?
This way cosmiconfigOptions could be set via a :

.cosmiconfig
.cosmiconfigrc
.cosmiconfigrc.json
and so on...
Of course, looking at the implementation it appears that packageProp might not be a good candidate for overriding.
That would allow for all packages that upgrade cosmiconfig with this feature to allow their user to load their configuration by overriding searchFrom for example to look for their config in a sub-directory (instead of up the directory tree, which can be more convenient especially in a CI environment), instead of waiting that each modules which use cosmiconfig exposes a way to do so.
Thanks for your feedback on it, I quickly looked at the implementation I might have overlooked something, but it seems doable.

Hi @Roms1383. Interesting idea. I think, though, that the decision to do something like this should be in the hands of cosmiconfig's consumers, not cosmiconfig itself. If a program using cosmiconfig wants to do something like this, I believe they can with the interface cosmiconfig already exposes. But I think that cosmiconfig is not going to make those decisions for the consumer programs.

Thanks for the explanation.  I couldn't wrap my head around the use-case and so didn't know how to respond.


refactor: expose the DefaultReporter

I am trying to stop go-cmp from calling fmt.Stringer, as this in some
cases makes the output worse instead of better.
The DefaultReporter implementation is quite customizable, but this
functionality is not exposed to the user.
While users can register custom exporters, they would then need to
re-implement the entire DefaultExporter, even though changing a single
bool in it's config would suffice.
This PR exposes the DefaultReporter implementation so it can be
customized and used outside of this package

The philosophical position of this project is to give as little knobs as possible to tweak the output. If the output is subpar (e.g., calling String is unhelpful), it is better to understand why and adjust the heuristics in the reporter to do a better job. Can you provide some examples where the String method has worse output than otherwise?

Sure! I have a type that uses yaml.Marshal as it's string function.
Because this is called, the diff now contains yaml squished to a single line, where I can't really see what's going on:
        process_test.go:95:   manifest.List{
            - 	s"apiVersion: v1\nkind: Service\nmetadata:\n  name: grafana\nspec:\n  ports:\n  - name: grafana\n    port: 3000\n    targetPort: 3000\n  selector:\n    app: grafana\n",
            - 	s"apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: grafana\nspec:\n  replicas: 1\n  template:\n    containers:\n    - image: grafana/grafana\n      name: grafana\n    metadata:\n      labels:\n        app: grafana\n",
            + 	s"apiVersion: v1\nitems:\n- apiVersion: apps/v1\n  kind: Deployment\n  metadata:\n    name: grafana\n  spec:\n    replicas: 1\n    template:\n      containers:\n      - image: grafana/grafana\n        name: grafana\n      metadata:\n        labels:\n          app: grafana"...,
              }

With regular Go-style printing however, this would be perfectly usable.

Thanks for the example, can you also show what it would look like if it had used the regular Go-style printing (for comparison)?

Sure, sorry for that. Update above comment!

Thanks for the examples. I'm inclined to say that we should adjust the reporter to print multiline String output as multiline output (rather than a quoted string) if this is this for a added, removed, or modified element (i.e., we continue to use quoted string if the element is equal).
As a straw-man proposal, it might look something like:
  manifest.List{
- 	(
- 		s"""
- 		apiVersion: v1
- 		kind: Service
- 		metadata:
- 		  name: grafana
- 		spec:
- 		  ports:
- 		  - name: grafana
- 		    port: 3000
- 		    targetPort: 3000
- 		  selector:
- 		    app: grafana
- 		"""
- 	),
- 	(
- 		s"""
- 		apiVersion: apps/v1
- 		kind: Deployment
- 		metadata:
- 		  name: grafana
- 		spec:
- 		  replicas: 1
- 		  template:
- 		    containers:
- 		    - image: grafana/grafana
- 		      name: grafana
- 		    metadata:
- 		      labels:
- 		        app: grafana
- 		""",
- 	),
+ 	(
+ 		s"""
+ 		apiVersion: v1
+ 		items:
+ 		- apiVersion: apps/v1
+ 		  kind: Deployment
+ 		  metadata:
+ 		    name: grafana
+ 		  spec:
+ 		    replicas: 1
+ 		    template:
+ 		      containers:
+ 		      - image: grafana/grafana
+ 		        name: grafana
+ 		      metadata:
+ 		        labels:
+ 		          app: grafana
+ 		... // 5 additional lines
+ 		"""
+ 	),
  }

For this specific case, that would indeed solve the problem in an elegant way :+1:
In the general picture, I'd be a bit concerned about the Stringer use, because if I messed up my Stringer implementation to swallow data (ie. I could just omit a struct field), Diff would not detect that anymore and my test might pass while actually being invalid.

For this specific case, that would indeed solve the problem in an elegant way +1

Can you file an issue for this? Alternatively, you're welcome to try implementing this yourself. The logic for triple-quoted strings in a diff is here, you may need to refactor parts of it out so that you can share similar functionality from the logic to print the stringer.

if I messed up my Stringer implementation to swallow data (ie. I could just omit a struct field), Diff would not detect that anymore and my test might pass while actually being invalid.

The reporter has logic to continually printing with more verbosity if the printed output is identical between the added and removed element. Thus, if the String method left out information that was the semantic reason for a difference, the reporter should eventually figure out that the String method alone doesn't provide that information and fall back to formatting the values as pseudo-Go objects.
As much as possible, we'd like to push any notion of knobs for the reporter to be reasonable heuristics in the reporter such that it does a decent job a majority of  the time, so that users don't need to play the game of guessing the best set of reporter knobs to format the diff output.

#229 formats multiline strings within inequal nodes using the triple-quote syntax.

That's so cool! Imo that's sufficient, we can close this once merged :)

Closing in favor of #229


Module build failed: Error: ENAMETOOLONG: name too long, open

<EMAIL_ADDRESS>./src/webapp/{CENSORED_99_CHARACTERS}.js
Module build failed: Error: ENAMETOOLONG: name too long, open '/srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/.happypack/_srv_{CENSORED_12_CHARACTERS}_web_releases_2016_10_29_01_11_55_505_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0_src_webapp_{CENSORED_99_CHARACTERS}_js.map'
Error: ENAMETOOLONG: name too long, open '/srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/.happypack/_srv_{CENSORED_12_CHARACTERS}_web_releases_2016_10_29_01_11_55_505_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0_src_webapp_{CENSORED_99_CHARACTERS}_js.map'
    at Error (native)
    at Object.fs.openSync (fs.js:549:18)
    at Object.fs.writeFileSync (fs.js:1156:15)
    at /srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/HappyWorker.js:46:10
    at apply (/srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/applyLoaders.js:261:14)
    at /srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/applyLoaders.js:274:9
    at /srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/applyLoaders.js:330:17
    at Object.callback (/srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/fnOncePedantic.js:10:15)
    at Object.module.exports (/srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/babel-loader/index.js:132:8)
    at applySyncOrAsync (/srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/applyLoaders.js:341:21)
    at /srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/HappyLoader.js:46:23
    at Object.Thread::1:2:1 (/srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/HappyPlugin.js:321:7)
    at ChildProcess.acceptMessageFromWorker (/srv/{CENSORED_12_CHARACTERS}/web/releases/2016-10-29_<IP_ADDRESS>5_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0/node_modules/happypack/lib/HappyThread.js:66:32)
    at emitTwo (events.js:92:20)
    at ChildProcess.emit (events.js:172:7)
    at internal/child_process.js:696:12
    at nextTickCallbackWith0Args (node.js:420:9)
    at process._tickCallback (node.js:349:13)

The filename exceeds NAME_MAX of 255 characters, it gets 257 characters long.
_srv_{CENSORED_12_CHARACTERS}_web_releases_2016_10_29_01_11_55_505_{CENSORED_44_CHARACTERS}_c5e6be8abb76159b09943383ae75854c536ea3b0_src_webapp_{CENSORED_99_CHARACTERS}_js.map

I suggest hashing the path to make the happypack filename, e.g. with sha1.

Weird, I've scanned<EMAIL_ADDRESS>source code, .happypack is the default value of tempDir, the only thing it leads to is compiledPath, but compiledPath is built via hashing, not via string replacement.
compiledPath: path.resolve(this.config.tempDir, HappyUtils.generateCompiledPath(filePath)),

exports.generateCompiledPath = function(filePath) {
  return 's-' + hashString(filePath);
};

I've locally got a lot of files named like .happypack/s--21689102 and .happypack/s--21689102.map. But on the build server I get the paths described above... Any ideas how this might happen?

Hmm, that function was revisited after 2.2.1. At 2.2.1 it looks like this:
exports.generateCompiledPath = function(filePath) {
  if (process.env.DEBUG) {
    return filePath.replace(/\W+/g, '_');
  }
  else {
    return 's-' + hashString(filePath);
  }
};

Which leads me to believe your environment has DEBUG exported... Either unset that environment variable (you can do that for the one process if you like, e.g. when invoking webpack, if your build needs it) or wait for the next release in which it's removed.
Sorry you're seeing this!

Oh, looks like the 2.2.1 in package.json of the latest master confused me. Yes, I've actually scanned the latest master.
I'll keep this open until the release is live, if you don't mind. Please post an update here when this happens.
Thanks!

@amireh More details on the case below.
We use https://github.com/visionmedia/debug where

The DEBUG environment variable is then used to enable these based on space or comma-delimited names.

So, this does not trigger the happypack debug flag default value:
debug:                    { type: 'boolean', default: process.env.DEBUG === '1' },

but triggers the special behavior of generateCompiledPath pointed out in the comment which does not use the debug flag, rather it uses process.env.DEBUG directly:
exports.generateCompiledPath = function(filePath) {
  if (process.env.DEBUG) {
    return filePath.replace(/\W+/g, '_');
  }
  else {
    return 's-' + hashString(filePath);
  }
};

I've added a monkeypatch until this is fixed:
// WORKAROUND(sompylasar): Monkeypatch<EMAIL_ADDRESS>to fix `ENAMETOOLONG`. @see https://github.com/amireh/happypack/issues/100#issuecomment-257105154
// TODO(sompylasar): When the next version of `happypack` is released, remove this monkeypatch workaround.
const HappyUtils = require('happypack/lib/HappyUtils');
const HappyUtils_generateCompiledPath = HappyUtils.generateCompiledPath;  // eslint-disable-line camelcase
HappyUtils.generateCompiledPath = function (...args) {  // eslint-disable-line func-names
  // Store the original environment.
  const DEBUG_WAS_DEFINED = ('DEBUG' in process.env);
  const DEBUG = process.env.DEBUG;

  // `process.env.DEBUG` causes special long-filenames behavior in `generateCompiledPath` of<EMAIL_ADDRESS>  delete process.env.DEBUG;

  const ret = HappyUtils_generateCompiledPath(...args);  // eslint-disable-line new-cap

  // Restore the environment.
  if (DEBUG_WAS_DEFINED) {
    process.env.DEBUG = DEBUG;
  }

  return ret;
};

This was fixed in the 3.0.0 release by the way. Please confirm so that we can close it.

@amireh Reviewed the code, looks like the special behavior on DEBUG has gone. Didn't test in the real world though. Thanks!

Closing this.


Potentially Resolve Database Save Hang

This is only for consideration. If you feel my contributions are insufficient to some extent, feel free to suggest changes.

Both of those need to be constantly running on predefined interval, by your changes it would cycle only once


Add documentation with Jupyterlite demo

This adds a first documentation including a jupyterlite demo.
Wait for https://github.com/jupyterlite/jupyterlite-sphinx/pull/108 to be merged.
Fixes https://github.com/jupyterlite/litegitpuller/issues/6

Looks ready, but to try it in the built documentation of the PR, the src path of the iframe must be change from src=/lite/lab to src=lite/lab (removing the first slash).
I assume it only occurs on the PR documentation.
To test the git puller feature, this link can be used https://litegitpuller--8.org.readthedocs.build/en/8/?repo=https%3A%2F%2Fgithub.com%2Fbrichet%2Ftesting-repo&urlpath=tree%2Ftesting-repo%2Fnotebooks%2Fsimple.ipynb&branch=main, but the first slash of the iframe src need to be removed in the html source.

@jtpio does the RTD preview action is usually working on voici https://github.com/voila-dashboards/voici/blob/1587e7bfa2a87b71be568a20e385dd9d8da6e2ae/.github/workflows/rtd-preview.yml ?
It does not work on the current opened PR, neither on some closed I tried.

Yes, for example: https://github.com/voila-dashboards/voici/pull/89#issuecomment-1688518032
But the workflow would first have to be merged and available on main.

the src path of the iframe must be change from src=/lite/lab to src=lite/lab (removing the first slash)

This is caused by https://github.com/jupyterlite/jupyterlite-sphinx/pull/108.
I'll open a PR to fix it.

Yes, for example: voila-dashboards/voici#89 (comment)

The badge is visible but it leads me to a 404.

the src path of the iframe must be change from src=/lite/lab to src=lite/lab (removing the first slash)

This is caused by https://github.com/jupyterlite/jupyterlite-sphinx/pull/108.
I'll open a PR to fix it.

Fixed

We can double check the Check Links job passes correctly on CI once merged into main.


sse4.2: first attempt at implementing mm_crc32_u8

sse4.2: first attempt at implementing mm_crc32_u8
I tried implementing the function from IIG. I know it has too many problems, but I thought it would be better to get some hint regarding implementation of the function and its tests.

Thanks for review, I will go through all the comments and make changes accordingly.


feat: Add new OSCAL profile-to-osco-yaml transformer functionality.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] All commits are signed-off.

Description
Provide support for transforming an OSCAL profile.json into an OSCO profile.yaml.
The osco.py transform library is extended with new class ProfileToOscoTransformer with a transform method that consumes an OSCAL profile and produces a python dict.
Overview of changes:

new task profile-to-osco
new osco transformer
update transformer factory
add test cases for 100% code coverage

Uncertainties

should the result of the transform be a python dict?
should the file produced by the corresponding task be named profile.yaml?

My claim is that all complaints have been fixed.
The returned string is json. Seems right?
Also, need to understand what to do about rationale: not specified.


get_relation returns none in hook context

Describe the bug
The adapter.get_relation(...) method seems to return None within the post-hook context.
Why does this matter? Well, {{ this }} always has its type defined as None, and it's fairly common that a user would want to use get_relation (perform a cache lookup) to get its relational type for the purposes of templating a post hook:
alter {{ relation.type }} {{ relation }} ... do something ...

Steps To Reproduce
macros/say_hi.sql
{% macro say_hi(relation) %}

    {% set rel = adapter.get_relation(this.database, this.schema, this.name) %}

   select 'say hi to my two best friends: the {{ relation.type }} {{ relation }} and the {{ rel.type }} {{ rel }}'

{% endmacro %}

models/my_model.sql
{{ config(
    post_hook = say_hi(this)
) }}

{{ say_hi(this) }}

dbt.log
create view "jerco"."dbt_jcohen"."my_model__dbt_tmp" as (
    select 'say hi to my two best friends: the None "jerco"."dbt_jcohen"."my_model" and the view "jerco"."dbt_jcohen"."my_model"'
  );
...
        select 'say hi to my two best friends: the None "jerco"."dbt_jcohen"."my_model" and the  None'
...

Expected behavior
I expected the result of get_relation to be defined for both the model and post-hook contexts.
The output of dbt --version:
$ dbt --version
installed version: 0.18.1
   latest version: 0.18.1

Additional context
In the meantime, it's mostly possible to work around this by inferring the relational object type from the configuration of the model we're post-hooking:
{% set relation_type='view' if model.config.materialized == 'view' else 'table' %}

@jtcohen6 - Thanks for raising this. I'm seeing the same from +post-hook when attempting to apply permissions in Snowflake.
It seems this must have been working at some point - is it possible this is a recent regression, and would it be worthwhile for me to try this in a previous version of DBT?

It seems this must have been working at some point - is it possible this is a recent regression, and would it be worthwhile for me to try this in a previous version of DBT?

@aaronsteers Hm... I haven't looked into this, but I'd be curious to know if it works in older versions!

Do you know if the model.config.materialized == 'view' work with this? In other words, can I pass this in a macro and then apply that test within the macro?

During a model's execution, model reflects the node object of the current model, and this reflects the Relation object of the current model. So config is only stored on the node config, but they ultimately represent "the same thing."

This is super helpful - thank you! The expressing model.config.materlialized is correctly returning table or view.
Do you know if I can use the model object also to get the fully qualified object name that I would otherwise get from {{ this }}?

It's possible to do something like this (docs):
{% set rel = api.Relation.create(
    database = model.database,
    schema = model.schema,
    identifier = model.identifier,
    type = 'view' if model.config.materialized == 'view' else 'table'
) %}

Effectively, it's the same as this, but with the type defined. {{ rel }} and {{ this }} should render the same.

Thanks for sharing this - and for the link. I had checked that page but it doesn't say anything directly about the model object. I did also try {{ debug() }} but the command failed for some reason.
This might be unrelated, but is there a known reason why I wouldn't be able to access a macro attached to a specific model from a +post-hook in schema.yml which I'm otherwise able to access just fine in dbt_project.yml.
In schema.yml, I get either Could not render {{ data_platform_core.grant_select(this, 'PEOPLEDATA_RO') }}: 'data_platform_core' is undefined or Could not render {{ grant_select(this, 'PEOPLEDATA_RO') }}: 'grant_select' is undefined. Again, the confusing thing is that it works just fine in dbt_project.yml (without project name prefix).
Sample that throws the error:
version: 2
models:
  - name: dim_work_group
    +post-hook:
      - "{{ data_platform_core.grant_select(this, 'PEOPLEDATA_RO') }}"

Right, that docs link details how to instantiate Relation objects. There are some (admittedly) sparse docs on the model node object here.
As far as setting post-hook in schema.yml: Today there's a distinction between node configs and resource properties. Ultimately (before v1.0), I'd like to reconcile the two as much as possible (#2401). Today, because post-hook is a node config, it can only be set in dbt_project.yml or within a model file's config() block.
The specific error you're seeing is the result of another limitation that, in an ideal world, I'd like to make possible: You cannot call custom macros from .yml files, except in hooks, which are late-rendered. There was an issue about just this a few days ago (https://github.com/fishtown-analytics/dbt/issues/2942), which I closed only because there's some foundational work that lies between us and enabling that pattern.

That is super helpful context and I think it gives me my path forward. Thanks so much!

Coming back to this, and having revisited https://github.com/dbt-labs/dbt/issues/2370, I'm afraid to report that this does work if the hook is re-parsed at execute time, instead of set at parse time. Namely:
{{ config(
    post_hook = "{{ say_hi(this) }}"
) }}

{{ say_hi(this) }}

This is so not my favorite thing, but I'm going to close the issue. The real question is bigger than get_relation, and it's whether hooks should always be re-parsed at execute time, without the need to nest a macro in an extra set of curlies.


New reproducibility NIX_CFLAGS_COMPILE breaks ccache caching

Describe the bug
After https://github.com/NixOS/nixpkgs/pull/102251, a new -frandom-seed C compiler flag is inserted with a value that changes whenever the derivation hash has changed. This will change the ccache cmdline hash, completely defeating any use of ccacheWrapper etc.
Additional context
Arguably, ccache should probably ignore frandom-seed since caching modulo that value is no worse than caching a cmdline that did not contain the flag in the first place, which effectively sets it to a random value. But it would be great to be able to at least opt out of the new behavior until this is "fixed" upstream (if accepted at all).
Notify maintainers
@andir
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module: programs.ccache

The solution referenced by the lean4 package works to trim out the -frandom-seed.

Upstream has added support for the flag. https://github.com/ccache/ccache/pull/1168
You need explicitly enable it via sloppiness = random_seed in the ccache config file though.
Given that we enable it for all packages by default, perhaps ccacheStdenv should enable it by default too.

You can also enable that flag with an environment variable similar to how you set CCACHE_DIR according to https://nixos.wiki/wiki/CCache, by adding
export CCACHE_SLOPPINESS=random_seed

in extraConfig

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/really-low-ccache-hit-rates-when-overriding-a-package/47421/4


Clean up unit tests and set some configs to default

Background
As there are many major changes in DORA, the newest version of Alluxio, many tests are deprecated. For example, we should remove BlockStore related tests. Otherwise, it is easy to encounter test failure when we are going to submit a PR. Moreover, new tests for covering the new features are also required. Therefore, we need to have a clean up for the tests.
In addition, now there are too many configurations to be set in DORA. Some of them are unnecessary as we can set them as default. No doubt that removing redundant configurations will make us much easier to use. The reason why we don't set them as default for now is that once we do so, many deprecated tests fail. In order to remove the redundant configurations, we need to clean up the tests first.

This PR mainly do the following things:

set alluxio.dora.client.read.location.policy.enabled=true by default
set alluxio.master.worker.register.lease.enabled=false by default
set alluxio.user.netty.data.transmission.enabled=true by default

These changes make many tests fail since the architecture of DORA is quite different from that of the previous Alluxio 2.9.x version. That is why this PR changed more than a hundred files. Most of the failed tests refer to the following reasons:

Block Store is deprecated in DORA
Job master and job worker are deprecated in DORA
Master no longer manages metadate in DORA

Though I have marked the depreacated tests with @Ignore to avoid failures, we still have to review these tests and check whether we need to fix them or not. This could be future work done in another PR.
For easier retrieval of these tests, I have left a TODO comment with a <TEST_FIX> string in the tests that are marked as @Ignore. We can review them later convienently.

@Xenorith This test group takes too much time before testing leading to timeout error. However, actually all tests would be passed.

This PR mainly does the following things:

set alluxio.dora.client.read.location.policy.enabled=true by default
set alluxio.master.worker.register.lease.enabled=false by default
set alluxio.user.netty.data.transmission.enabled=true by default
set alluxio.user.short.circuit.enabled=false by default

These changes make many tests fail since the architecture of DORA is quite different from that of the previous Alluxio 2.9.x version. That is why this PR changed more than a hundred files. Most of them failed caused by the following reasons:

Block Store is deprecated in DORA
Job master and job worker are deprecated in DORA
Master no longer manages metadata in DORA

Though I have marked the deprecated tests with @Ignore to avoid failures, we still have to review these tests and check whether we need to fix them or not. This could be future work done in another PR.
For easier retrieval of these tests, I have left a TODO comment with a <TEST_FIX> string in the tests that are marked as @Ignore. We can review them later conveniently by searching the key word <TEST_FIX>.

Contents above is merged into the desc. And we invented a more structured way of tracking TODOs.

alluxio-bot, merge this please


🐛 [firebase_auth] .emailVerified never comes back to true after changing the email back

Bug report
FirebaseAuth.instance.currentUser!.emailVerified never comes back to true after changing the email and changing it back to the original one.
Description & Steps to reproduce

Your had an email linked to the account (let's say it's<EMAIL_ADDRESS>You change the email to another one (verynewemail@gmail.com). Email verification link is sent to the new one, "Your sign-in email was changed" email is sent to the old one, but I did not open the link in those emails
You change the email back to the original one (original@gmail.com). Email verification link is sent to<EMAIL_ADDRESS>and I open the link in the verification email, but FirebaseAuth.instance.currentUser!.emailVerified does not come back to true.
Even if I send more email verification link to<EMAIL_ADDRESS>and open the link in there, FirebaseAuth.instance.currentUser!.emailVerified would never come back to true.

Expected behavior
FirebaseAuth.instance.currentUser!.emailVerified should come back to true when I change the email back to the original one and verify it again.
Sample project
Too lazy for that
Additional context
Identity Platform: turned on
SMS Multi-factor Authentication: Disabled
Enabled Auth Providers: Email/Password, Apple, Google

Flutter doctor
Run flutter doctor and paste the output below:
Click To Expand
shawn@Shawns-MacBook-Pro atrablechat % flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.8, on macOS 13.0.1 22A400 darwin-arm, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 14.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.2)
[✓] VS Code (version 1.73.1)
[✓] Connected device (3 available)
[✓] HTTP Host Availability

• No issues found!

Flutter dependencies
Run flutter pub deps -- --style=compact and paste the output below:
Click To Expand

shawn@Shawns-MacBook-Pro atrablechat % flutter pub deps -- --style=compact
Dart SDK 2.18.4
Flutter SDK 3.3.8
atrable 1.2.1

dependencies:
- animated_segmented_tab_control 1.0.1 [flutter]
- audio_session 0.1.10 [flutter flutter_web_plugins rxdart meta]
- cached_network_image 3.2.2 [flutter flutter_cache_manager octo_image cached_network_image_platform_interface cached_network_image_web]
- camera 0.10.0+3 [camera_android camera_avfoundation camera_platform_interface camera_web flutter flutter_plugin_android_lifecycle quiver]
- cloud_firestore 4.0.4 [cloud_firestore_platform_interface cloud_firestore_web collection firebase_core firebase_core_platform_interface flutter meta]
- cupertino_icons 1.0.5
- emoji_picker_flutter 1.4.0 [flutter shared_preferences]
- eraser 2.0.1 [flutter]
- ffmpeg_kit_flutter 4.5.1 [ffmpeg_kit_flutter_platform_interface flutter]
- firebase_auth 4.1.1 [firebase_auth_platform_interface firebase_auth_web firebase_core firebase_core_platform_interface flutter meta]
- firebase_core 2.1.1 [firebase_core_platform_interface firebase_core_web flutter meta]
- firebase_messaging 14.0.4 [firebase_core firebase_core_platform_interface firebase_messaging_platform_interface firebase_messaging_web flutter meta]
- firebase_storage 11.0.4 [firebase_core firebase_core_platform_interface firebase_storage_platform_interface firebase_storage_web flutter]
- flutter 0.0.0 [characters collection material_color_utilities meta vector_math sky_engine]
- flutter_emoji 2.4.0 [characters http]
- flutter_svg 1.1.5 [flutter meta path_drawing vector_math xml]
- image_cropper 3.0.0 [flutter image_cropper_platform_interface image_cropper_for_web]
- image_picker 0.8.6 [flutter image_picker_android image_picker_for_web image_picker_ios image_picker_platform_interface]
- infinite_scroll_pagination 3.2.0 [flutter sliver_tools]
- overlay_support 2.0.1 [flutter async]
- path_provider 2.0.11 [flutter path_provider_android path_provider_ios path_provider_linux path_provider_macos path_provider_platform_interface path_provider_windows]
- permission_handler 10.1.0 [flutter meta permission_handler_android permission_handler_apple permission_handler_windows permission_handler_platform_interface]
- pinch_zoom_image_last 0.4.1 [flutter]
- provider 6.0.3 [collection flutter nested]
- qr_flutter 4.0.0 [flutter qr]
- record 4.4.1 [flutter record_platform_interface record_web record_windows record_macos record_linux]
- scrolls_to_top 1.1.1 [flutter]
- share_plus 6.2.0 [cross_file meta mime flutter flutter_web_plugins share_plus_platform_interface file url_launcher_web url_launcher_windows url_launcher_linux url_launcher_platform_interface ffi win32]
- shared_preferences 2.0.15 [flutter shared_preferences_android shared_preferences_ios shared_preferences_linux shared_preferences_macos shared_preferences_platform_interface shared_preferences_web shared_preferences_windows]
- shimmer 2.0.0 [flutter]
- sign_in_with_apple 4.1.0 [flutter meta sign_in_with_apple_platform_interface sign_in_with_apple_web]
- transparent_image 2.0.0
- uni_links 0.5.1 [flutter uni_links_platform_interface uni_links_web]
- url_launcher 6.1.6 [flutter url_launcher_android url_launcher_ios url_launcher_linux url_launcher_macos url_launcher_platform_interface url_launcher_web url_launcher_windows]
- video_player 2.4.7 [flutter html video_player_android video_player_avfoundation video_player_platform_interface video_player_web]
- wave 0.2.2 [flutter]

dev dependencies:
- flutter_test 0.0.0 [flutter test_api path fake_async clock stack_trace vector_math async boolean_selector characters collection matcher material_color_utilities meta source_span stream_channel string_scanner term_glyph]

transitive dependencies:
- _flutterfire_internals 1.0.7 [cloud_firestore_platform_interface cloud_firestore_web collection firebase_core firebase_core_platform_interface flutter meta]
- async 2.9.0 [collection meta]
- boolean_selector 2.1.0 [source_span string_scanner]
- cached_network_image_platform_interface 2.0.0 [flutter flutter_cache_manager]
- cached_network_image_web 1.0.2 [flutter flutter_cache_manager cached_network_image_platform_interface]
- camera_android 0.10.0+3 [camera_platform_interface flutter flutter_plugin_android_lifecycle stream_transform]
- camera_avfoundation 0.9.8+6 [camera_platform_interface flutter stream_transform]
- camera_platform_interface 2.2.2 [cross_file flutter plugin_platform_interface stream_transform]
- camera_web 0.3.0+1 [camera_platform_interface flutter flutter_web_plugins stream_transform]
- characters 1.2.1
- clock 1.1.1
- cloud_firestore_platform_interface 5.8.4 [_flutterfire_internals collection firebase_core flutter meta plugin_platform_interface]
- cloud_firestore_web 3.0.4 [_flutterfire_internals cloud_firestore_platform_interface collection firebase_core firebase_core_web flutter flutter_web_plugins js]
- collection 1.16.0
- cross_file 0.3.3+2 [js meta]
- crypto 3.0.2 [typed_data]
- csslib 0.17.2 [source_span]
- fake_async 1.3.1 [clock collection]
- ffi 2.0.1
- ffmpeg_kit_flutter_platform_interface 0.2.1 [flutter plugin_platform_interface]
- file 6.1.4 [meta path]
- firebase_auth_platform_interface 6.11.1 [_flutterfire_internals collection firebase_core flutter meta plugin_platform_interface]
- firebase_auth_web 5.1.1 [firebase_auth_platform_interface firebase_core firebase_core_web flutter flutter_web_plugins http_parser intl js meta]
- firebase_core_platform_interface 4.5.2 [collection flutter flutter_test meta plugin_platform_interface]
- firebase_core_web 2.0.1 [firebase_core_platform_interface flutter flutter_web_plugins js meta]
- firebase_messaging_platform_interface 4.2.5 [_flutterfire_internals firebase_core flutter meta plugin_platform_interface]
- firebase_messaging_web 3.2.5 [_flutterfire_internals firebase_core firebase_core_web firebase_messaging_platform_interface flutter flutter_web_plugins js meta]
- firebase_storage_platform_interface 4.1.22 [collection firebase_core flutter meta plugin_platform_interface]
- firebase_storage_web 3.3.14 [_flutterfire_internals async firebase_core firebase_core_web firebase_storage_platform_interface flutter flutter_web_plugins http js meta]
- flutter_blurhash 0.7.0 [flutter]
- flutter_cache_manager 3.3.0 [clock collection file flutter http path path_provider pedantic rxdart sqflite uuid]
- flutter_plugin_android_lifecycle 2.0.7 [flutter]
- flutter_web_plugins 0.0.0 [flutter js characters collection material_color_utilities meta vector_math]
- html 0.15.0 [csslib source_span]
- http 0.13.5 [async http_parser meta path]
- http_parser 4.0.1 [collection source_span string_scanner typed_data]
- image_cropper_for_web 1.0.2 [flutter flutter_web_plugins image_cropper_platform_interface js]
- image_cropper_platform_interface 3.0.2 [flutter plugin_platform_interface http]
- image_picker_android 0.8.5+3 [flutter flutter_plugin_android_lifecycle image_picker_platform_interface]
- image_picker_for_web 2.1.10 [flutter flutter_web_plugins image_picker_platform_interface]
- image_picker_ios 0.8.6+1 [flutter image_picker_platform_interface]
- image_picker_platform_interface 2.6.2 [cross_file flutter http plugin_platform_interface]
- intl 0.17.0 [clock path]
- js 0.6.4
- matcher 0.12.12 [stack_trace]
- material_color_utilities 0.1.5
- meta 1.8.0
- mime 1.0.2
- nested 1.0.0 [flutter]
- octo_image 1.0.2 [flutter flutter_blurhash]
- path 1.8.2
- path_drawing 1.0.1 [vector_math meta path_parsing flutter]
- path_parsing 1.0.1 [vector_math meta]
- path_provider_android 2.0.20 [flutter path_provider_platform_interface]
- path_provider_ios 2.0.11 [flutter path_provider_platform_interface]
- path_provider_linux 2.1.7 [ffi flutter path path_provider_platform_interface xdg_directories]
- path_provider_macos 2.0.6 [flutter path_provider_platform_interface]
- path_provider_platform_interface 2.0.5 [flutter platform plugin_platform_interface]
- path_provider_windows 2.1.3 [ffi flutter path path_provider_platform_interface win32]
- pedantic 1.11.1
- permission_handler_android 10.1.0 [flutter permission_handler_platform_interface]
- permission_handler_apple 9.0.6 [flutter permission_handler_platform_interface]
- permission_handler_platform_interface 3.9.0 [flutter meta plugin_platform_interface]
- permission_handler_windows 0.1.1 [flutter permission_handler_platform_interface]
- petitparser 5.0.0 [meta]
- platform 3.1.0
- plugin_platform_interface 2.1.3 [meta]
- process 4.2.4 [file path platform]
- qr 2.1.0 [meta]
- quiver 3.1.0 [matcher]
- record_linux 0.3.4 [flutter record_platform_interface path]
- record_macos 0.2.2 [flutter record_platform_interface]
- record_platform_interface 0.5.0 [flutter plugin_platform_interface]
- record_web 0.5.0 [flutter flutter_web_plugins record_platform_interface]
- record_windows 0.6.2 [flutter record_platform_interface path]
- rxdart 0.27.5
- share_plus_platform_interface 3.2.0 [cross_file flutter meta mime plugin_platform_interface path_provider uuid]
- shared_preferences_android 2.0.13 [flutter shared_preferences_platform_interface]
- shared_preferences_ios 2.1.1 [flutter shared_preferences_platform_interface]
- shared_preferences_linux 2.1.1 [file flutter path path_provider_linux path_provider_platform_interface shared_preferences_platform_interface]
- shared_preferences_macos 2.0.4 [flutter shared_preferences_platform_interface]
- shared_preferences_platform_interface 2.1.0 [flutter plugin_platform_interface]
- shared_preferences_web 2.0.4 [flutter flutter_web_plugins shared_preferences_platform_interface]
- shared_preferences_windows 2.1.1 [file flutter path path_provider_platform_interface path_provider_windows shared_preferences_platform_interface]
- sign_in_with_apple_platform_interface 1.0.0 [flutter plugin_platform_interface meta]
- sign_in_with_apple_web 1.0.1 [flutter flutter_web_plugins sign_in_with_apple_platform_interface js]
- sky_engine 0.0.99
- sliver_tools 0.2.8 [flutter]
- source_span 1.9.0 [collection path term_glyph]
- sqflite 2.1.0+1 [flutter sqflite_common path]
- sqflite_common 2.3.0 [synchronized path meta]
- stack_trace 1.10.0 [path]
- stream_channel 2.1.0 [async]
- stream_transform 2.0.1
- string_scanner 1.1.1 [source_span]
- synchronized 3.0.0+3
- term_glyph 1.2.1
- test_api 0.4.12 [async boolean_selector collection meta source_span stack_trace stream_channel string_scanner term_glyph matcher]
- typed_data 1.3.1 [collection]
- uni_links_platform_interface 1.0.0 [flutter plugin_platform_interface]
- uni_links_web 0.1.0 [flutter flutter_web_plugins uni_links_platform_interface]
- url_launcher_android 6.0.19 [flutter url_launcher_platform_interface]
- url_launcher_ios 6.0.17 [flutter url_launcher_platform_interface]
- url_launcher_linux 3.0.1 [flutter url_launcher_platform_interface]
- url_launcher_macos 3.0.1 [flutter url_launcher_platform_interface]
- url_launcher_platform_interface 2.1.1 [flutter plugin_platform_interface]
- url_launcher_web 2.0.13 [flutter flutter_web_plugins url_launcher_platform_interface]
- url_launcher_windows 3.0.1 [flutter url_launcher_platform_interface]
- uuid 3.0.6 [crypto]
- vector_math 2.1.2
- video_player_android 2.3.9 [flutter video_player_platform_interface]
- video_player_avfoundation 2.3.7 [flutter video_player_platform_interface]
- video_player_platform_interface 5.1.4 [flutter plugin_platform_interface]
- video_player_web 2.0.12 [flutter flutter_web_plugins video_player_platform_interface]
- win32 3.0.0 [ffi]
- xdg_directories 0.2.0+2 [meta path process]
- xml 6.1.0 [collection meta petitparser]

2. You change the email to another one (verynewemail@gmail.com). Email verification link is sent to the new one, "Your sign-in email was changed" email is sent to the old one, but I did not open the link in those emails

@Shawn-sudo If you open the link after changing email to another and then follow step 3, what's the behavior ? Do you see emailVerified coming back to true ?

@darshankawar Oh I found that .emailVerified does not come back to true even when I just create a new account and verify the email.
I successfully received the email verification link, and when I open the link, it says "Your email has been verified", but FirebaseAuth.instance.currentUser!.emailVerified doesn't switch back to true.
I'm not caching the value of FirebaseAuth.instance.currentUser!.emailVerified anywhere else in my code
My code
  Future<void> checkEmailVerified() async {
    bool usingEmailPassword = false;
    FirebaseAuth.instance.currentUser!.providerData.forEach((element) {
      print("auth provider id: ${element.providerId}");
      if (element.providerId == "password") {
        usingEmailPassword = true;
      }
    });
    if (usingEmailPassword &&
        !FirebaseAuth.instance.currentUser!.emailVerified) {
      await showModalBottomSheet(
          context: context,
          isScrollControlled: true,
          backgroundColor: Colors.transparent,
          builder: (context) => VerifyEmail());
    }
  }

Probably I should go to Firebase Support instead to get some help.

You may be required to do a reload before checking emailVerified.,,, This is needed every time to receive any updates, so consider  a Timer.periodic or similar....
FirebaseAuth.instance.currentUser!.reload();

@Terranic Yea reloading the state before checking .emailVerified solved it... Thanks


Upgrade to critical-section 1.0.0

In general, features should add functionality, not remove them. (https://doc.rust-lang.org/cargo/reference/features.html#feature-unification)
I wonder if we could argue that "no-default-critical-section-impl" (probably with a different name) in fact adds functionality, namely the ability to provide a custom critical section impl? We could even name this feature "custom-impl", in perfect analogy to the same feature in critical-section 0.2.x.

How about cs-allow-alternative-locks ?
We could even have a cs-disable-interrupt-only although I wouldn't be surprised if a dedicated crate already offered that :D

critical-section's docs seem to imply that the feature shouldn't be enabled by default which I think makes sense so you can use a different impl (like cortex-m's, in a single core app). cortex-m doesn't use a default feature either.

I suggests to gate the implementation behind a feature, which we do. I don't think that gives us advice on whether that feature should be enabled by default. rp2040-hal is only used for one chip, which is a multi-core one, so using a multi-core-safe critical section by default seems reasonable.
If it was easy to disable a default feature, I'd be convinced that enabling it by default would be the right thing to do. But unfortunately, as @ithinuel mentioned, disabling a default feature on a crate which is also used as a transitive dependency by other crates is not easily possible.
But without enabling the implementation by default, we would have a default which would not work without additional work by the user of the lib. Also not very user-friendly.
So providing the impl by default, and having a feature that can be set if the caller want's to provide its own custom implementation could be a good workaround. Would work by default (and the default impl would be the safe one), but on demand, a different impl could be provided. If one crate enables this feature and provides its own custom impl, it works as expected. If two different crates try this at the same time, one would get a conflict, which is probably the best we could do in such a situation. Overall, I think this is a good solution.

Forgive my lack of cargo knowledge- but wouldn't a no-critical-section-impl feature still have the transitive dependancy issue, but for libraries- so it'd have to be enabled in all library crates in order for things to work? I guess that could work, but I think it comes with the same "user friendly" problem, but for library authors, and instead of erroring when you try to use critical-section in your application, there's no error until the user tries to use c-s and there's conflicting impls. see here- but no library author is going to be reading those docs if they aren't using c-s. Also not sure what would happen if libraries had different versions of the hal- this seems to suggest there could be problems.
(cc @Dirbaio)

Yeah the problem with default features is that, it's too easy for one random lib to forget default-features = false and then make it impossible for the end user to disable the default feature. I guess you can add default-features=false to all crates and then hope (or send tons of PRs) that other authors don't forget it, but it's not quite nice...
In cortex-m 0.7.6, critical-section-single-core is not a default feature for this reason.
I sort of lean towards making it non-default. The case in rp-hal is less clear than in cortex-m though. In cortex-m it's somewhat likely a user might want to use another impl (using a multicore chip, using nrf softdevice, using a rtos..) but if you're using rp-hal it's because you're on a rp2040 so the correct critical section impl is rp-hal's. Can't think of many reasons you wouldn't want it. Perhaps if you're only using one core and want the faster perf?

The no-critical-section-impl feature would not have the same issues because features are additive: as soon as at least one crate depending on rp2040-hal activates that feature, the hal would stop providing the impl. The exact property of feature resolution that bites us with the default features is actually useful here.

I had a go at trying to make a feature that'd allow alternate custom cs impl but couldn't find a way to enable a feature on a dependency if a feature on the current crate is not enabled.
critical-section/restore-state-u8 is required by the impl but needs to go to allow custom impl to enable their own state storage.
The only way forward I can see is that we need the critical section enabled manually like we do with rt and like the cortex-m crate does with critical-section-single-core. (even if that makes sense for cortex-m not to enable it by default).

I opened this issue to discuss the possible approaches of optionally providing a critical-section implementation.

@ithinuel, this could be an option, basically as you suggested, but with the feature enabled by default from the board crates:
https://github.com/jannic/rp-hal/commit/280de7cb99be87f291b7b07c1c52cab8230a1a61
A rationale is given in the commit message.

This commit seems perfect to me, I'd be happy to merge as it is.

https://github.com/rp-rs/rp-hal/pull/444 opened with your suggestion :) (I didn't one could open a pr from someone else's repo :D)


Fix scroll restoration for sheet item summaries

I'll try to see how much of it I can convert to not-jquery when I look into conditions later (and see if I can't clean up the mess some), but since this is HTML from _renderInner(), I don't know if we can really do that.

Yeah don't struggle too much with it. Sometimes upstream jquery makes it a losing fight.


Separate Wintertodt Notification Options

I've separated the notification options for the different Wintertodt events, as well as making the damage event notifications a choice between always notifying, and only notifying on interrupts (which now check for idle as well as woodcutting).

Supersedes #10535

Why do none of these config items have descriptions?

My bad, added the descriptions now.


[Feature Request] Typeahead

It'd be great if the reference UI had typeahead. Maybe a config parameter with a list of fields queried for typeahead?

This has now be added.
There is a configuration in engine.json that lets you specify which fields to suggest on, querySuggestFields.
If accessing from the App Search Dashboard, it will automatically be configured to use all Text fields.


Mechesengol

From Halley Eriich's song "Olechau er a Dimes":  Bechesiil a telbiled el mei milil / Mechesengol mengiil a di klsuul.  Yoichi Rengiil tells me that mechesengol is the n.poss.3s from the noun mechesang

Yes
On Wed, Apr 24, 2024 at 13:17 JimGeselbracht @.***>
wrote:

From Halley Eriich's song "Olechau er a Dimes": Bechesiil a telbiled el
mei milil / Mechesengol mengiil a di klsuul. Yoichi Rengiil tells me that
mechesengol is the n.poss.3s from the noun mechesang
—
Reply to this email directly, view it on GitHub
https://github.com/tekinged/missing/issues/494, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF2DJJCITAOOVSAPKES4BGLY7AHOHAVCNFSM6AAAAABGXS4Q3WVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3DEMJRGI2TKNA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Yep. It's just "mechesengong el" but it becomes mechesengol.
On Thu, Apr 25, 2024, 6:37 AM Gnalu @.***> wrote:

Yes
On Wed, Apr 24, 2024 at 13:17 JimGeselbracht @.***>
wrote:

From Halley Eriich's song "Olechau er a Dimes": Bechesiil a telbiled el
mei milil / Mechesengol mengiil a di klsuul. Yoichi Rengiil tells me
that
mechesengol is the n.poss.3s from the noun mechesang
—
Reply to this email directly, view it on GitHub
https://github.com/tekinged/missing/issues/494, or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AF2DJJCITAOOVSAPKES4BGLY7AHOHAVCNFSM6AAAAABGXS4Q3WVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3DEMJRGI2TKNA>

.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub
https://github.com/tekinged/missing/issues/494#issuecomment-2075890243,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXYSPXXRGRGBAL7OU45JPZTY7AQYDAVCNFSM6AAAAABGXS4Q3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZVHA4TAMRUGM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Update Get-SafeLinksDetailReport.md

@chrisda

Docs Build status updates of commit dcc4741:
:clock10: Pending: waiting for processors (28 builds ahead of you)
:warning: Docs Build is busy, currently there are 28 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit dcc4741:
:clock10: Full build: the average full build time is 18 min(s) 3 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit dcc4741:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Get-SafeLinksDetailReport.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit fe7646d:
:clock10: Full build: the average full build time is 18 min(s) 3 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit fe7646d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Get-SafeLinksDetailReport.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Arbitrary properties

Is it possible to add arbitrary key value pairs to game objects in the property editor? That would be rather useful to hook into game specific logic.

Hi David,
We don't support this feature out of box, but it is relatively easy to implement.
Please look at ATF CircuitEditor sample for reference.
CircuitEditor allows user to add  dynamic properties to circuit elements.
Ideally the dynamic properties feature should be added to ATF this way all the ATF based applications can automatically acquire it. ( But there is no  immediate plan to add the feature to ATF framework).
Alan


FileIO

https://nerdyelectronics.com/esp8266-spiffs-file-system/
https://randomnerdtutorials.com/esp8266-web-server-spiffs-nodemcu/
https://medium.com/@gkadusumilli/spiffs-flash-file-system-in-nodemcu-356153383f3e#:~:text=In this article%2C you will,connected to ESP through SPI.
https://www.instructables.com/Using-ESP8266-SPIFFS/

https://tttapa.github.io/ESP8266/Chap11 - SPIFFS.html

https://www.youtube.com/watch?v=0jDD0XaDus4


⚠ Secret Website 2 has degraded performance

In 55baf7c, Secret Website 2 ($SECRET_WEBSITE_2) experienced degraded performance:

HTTP code: 200
Response time: 5327 ms

Resolved: Secret Website 2 performance has improved in bfe62e3.


[request]multiple watcher in config.js

Note: for support questions, please join our Discord server

I'm submitting a ...
[ ] bug report
[* ] feature request
[ ] question about the decisions made in the repository
============================================================
thanks guys for hard work but if possible to support multiple watcher in one config.js file

thanks

not now but you can run multiple instances of gekko


Make *Laplace respect the dtype of the base model

Closes #246

This seems to be a larger endeavor than expected: not only *Laplace classes but also all util functions and backends need to be checked.
Marking it as a draft for now.

@aleximmer could you please double check and merge?

Thanks @wiseodd, LGTM!


Package guzzle/parser is abandoned, you should avoid using it. Use guzzle/guzzle instead.

We'll get to this probably when PSR-7 drops. In the mean time composer is simply issuing a warning. Everything still works as intended.

Afaict this has been resolved in the meantime and can be closed :+1:


File structure

The file structure of the project is not right

Hey thanks for raising the issue you have been assigned this @AthulKkumar you can start working on it  😄

Hi @AthulKkumar , Could you kindly assign this issue, if you haven't working on this issue. I excited to work on this issue

@vaishnavi-3969 as I've noticed that no-one worked on their assigned issue. I am here to complete it can you please assign me because i assure you to complete this within 20 hours after assigning it to me .

Hey @code-bajju , I am working on this and I requested @AthulKkumar to the same

Hey Vaishnavi Can you please guide me and explain more about changing and fixing an issue. I didn't get that what to change in repository.


code issue

I utilized the open-source code you provided to run the MVSGaussian model and Unfortunately, under your experimental configuration, training on the DTU dataset for 300 epochs only achieved a performance of 27.58 dB. I noticed that in the code you released, the sampling points for both levels are the same（one sample）, and the rotation network of the Gaussian module has not been unlocked for training (you set it to a fixed value). I am not too sure if the issue lies with my environment or with the code you released. If you could address my questions, I would be extremely grateful.

Hi, thanks for your interest in our work. We trained our modol on 4 RTX3090 gpus with batchsize 1. If you train the model on a single gpu and the batchsize is 1, the performance may not as good as using 4 gpus. When using a single gpu, the batchsize should be changed to 4. However, the current code only supports 1 batchsize, and you can modify the code to support multiple batchsize. We'll also upload the updated code in the next few days after we finish our current stuff.

@chenll12345
Hello, we re-updated code which can support multi-batch training, a single 3090 GPU is sufficient to reproduce all of our experimental results.


Adding missing doctype Fixes #14

Hi @priyajeet, thanks for the pull request. Before we can merge it, we need you to sign our Contributor License Agreement. You can do so electronically here: http://opensource.box.com/cla
Once you have signed, just add a comment to this pull request saying, "CLA signed". Thanks!

CLA signed

Verified that @priyajeet has just signed the CLA. Thanks, and we look forward to your contribution.

Thanks!


Don't append to existing binary when assembling

If you keep building without cleaning the binary will keep growing. I just fixed protogram and percent.

Graci


Validate Geospatial Queries work in Data Commons environment

Need to verify that Trino and other OS-C components will support

Suggested initial approach is to look at leveraging TileDB and Trino connector as discussed with @joemoorhouse
Data format used: ZAR
https://zarr.readthedocs.io/en/stable/getting_started.html
https://pangeo-data.github.io/pangeo-cmip6-cloud/overview.html
Location of test data: Zarr data can be found in S3 bucket redhat-osc-physical-landing-647521352890, object keys starting hazard/hazard.zarr
TileDB:
https://github.com/TileDB-Inc/TileDB
@erikerlandson is the way forward having the TileDB libs into a PhysRisk developer image with all the tooling required?
TileDB Trino Connector:
https://github.com/TileDB-Inc/TileDB-Trino

As mentioned on Slack, TileDB is aiming to provide a major update in the March timeframe.  That should not slow us down in terms of evaluating connector/tooling readiness, but should inform resourcing so that when it is available, people have the best available version for most of the year.

I guess there are two approaches

Create a Trino connector for Zarr
Try out Trino connector for TileDB and check TileDB can be made to fit our use case https://github.com/TileDB-Inc/TileDB/issues/3076

In terms of common formats offering chunked, compressed storage there is also (Cloud Optimised) GeoTIFF and NetCDF - but both Zarr and TileDB split chunks into separate objects, which is desirable. Both seem good choices for us. Between the two, Zarr is an endorsed(?) community standard (https://latlong.blog/2022/07/ogc-endorses-zarr-2-0-community-standard.html) and seems more widely used (subjective). But then TileDB already has a Trino connector!
Support-wise, xarray has great support for Zarr, but on the other hand I see that TileDB has also added support https://github.com/TileDB-Inc/TileDB-CF-Py, so less of a difference there I think. They both play nicely with Dask/xarray.
There are Java libraries for Zarr reading/writing, but still a decent amount of work to wrap these into a Trino connector I would think.
https://github.com/zarr-developers/zarr_implementations

By the way, honourable mention for H3. RiskThinking showed that this works (and looks) great, certainly for moderately-sized data sets and I see folks working on approaches to optimise for high-resolution data sets:
https://medium.com/foursquare-direct/hex-tiles-building-a-new-data-tiling-system-with-h3-61eb33fed4cb
I personally prefer regular rectangular-grid rasters for the rather prosaic reason that our inputs tend to be in that form and we don't have to re-interpolate (no additional approximation needed).


Setup storybook

Run storybook with yarn storybook.
To add new story for a component X.tsx, place a file X.stories.tsx to the same directory and it will appear in the storybook.
Freedcamp Link

I had a slight problem while adding some components, so fixed the issue and pushed one more commit.


EC2 listInstances

Codecov Report

Merging #2 (39be340) into master (f625745) will decrease coverage by 0.12%.
The diff coverage is 94.33%.

@@            Coverage Diff             @@
##           master       #2      +/-   ##
==========================================
- Coverage   97.29%   97.17%   -0.13%
==========================================
  Files          53       58       +5
  Lines        1221     1274      +53
==========================================
+ Hits         1188     1238      +50
- Misses         33       36       +3

Impacted Files
Coverage Δ

EC2.js
85.71% <85.71%> (ø)

internal/AWSDescribeInstancesFilters.js
100.00% <100.00%> (ø)

internal/filterExists.js
100.00% <100.00%> (ø)

internal/filterExistsAndNotEmpty.js
100.00% <100.00%> (ø)

internal/objectFilterKeys.js
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f625745...39be340. Read the comment docs.


Format javascript code with shift+alt+f adds new blank lines

VSCode Version: Code 1.6.0 (e52fb0b, 2016-10-10T18:37:40.189Z)
OS Version: Windows_NT ia32 10.0.10586
Extensions: alefragnani.project-manager-0.10.0, dbaeumer.vscode-eslint-1.0.7, donjayamanne.githistory-0.1.0, DotJoshJohnson.xml-1.6.0, eg2.vscode-npm-script-0.0.20, HookyQR.beautify-0.4.0, humao.rest-client-0.8.5, ms-vscode.cpptools-0.9.2, msjsdiag.debugger-for-chrome-1.1.0, sandy081.todotasks-0.4.0, waderyan.gitblame-1.3.0
Steps to Reproduce:

Open vs code
Open javascript file
Press format code (shift+alt+f)

In my vs code editor each line (LF) will have additional blank line after pressing these buttons. If i have 10 lines before, i have 20 lines after
See issue https://github.com/Microsoft/vscode/issues/13591

@DennisAhaus: This is happening because of a mismatch of settings. The default setting for line endings on windows is CRLF, but you've set your file line ending to LF. beautify is using the default setting to format the code, and when the edit is applied, VS Code is changing the CRLF to LFLF, giving you double line endings. (It only does this on Windows)
If you're using a .jsbeautifyrc file, add "eol": "\n".
If you're using editorconfig, add end_of_line = lf.
If you're not using any of these, add a workspace (or user global) setting of "files.eol": "\n".

It would be beautiful if beautify automagically detects editorconfig. I'm on Windows, have LF lines also settings in VSCode and if I don't write "beautify.editorconfig": true it add double white lines each line. Such a mess!

@HookyQR thanks for the replay. I already have a .editorconfig file with the config end_of_line = lf

@DennisAhaus, you have to add "beautify.editorconfig": true in VSCode settings (user or workspace). My request is to automagically detect it.

Instead of automagically detect the presence of a editorconfig, why can't beautify just detect which line endings are used in a file and act accordingly. VS Code seems to do exactly that.
Setting "files.eol": "\n" obviously has the effect that all new files created will have now the none-standard line endings "\n" instead of "\r\n" on windows. If you have already a lot of files with that default line endings, you end with mixed line endings between the files in your project.

@hubbergit it does, kind of. The only time it won't 'automatically' select the editor's line ending is if there is a specific setting for the line ending. Any setting (from editorconfig, or jsbeautify) will override the line endings of the editor. In fact, if (as you say) VS Code was automatically determining the line endings, it should change its setting when a full file update happens, not change the line endings (incorrectly) afterwards.

@HookyQR: I'm not sure, if I am right, however having looked into the sources, it seems like the EOL option of the current editor is overwritten by the workspace option (assuming that there is no other setting in neither in editorconfig nor in jsbeautifyrc).
const optionsFromVSCode = (doc, formattingOptions, type) => {
const config = vscode.workspace.getConfiguration();
if (!formattingOptions) {
		formattingOptions = vscode.workspace.getConfiguration('editor');
		//if this document is open, use the settings from that window
		vscode.window.visibleTextEditors.some(editor => {
			if (editor.document && editor.document.fileName === doc.fileName) {
				return (formattingOptions = editor.options);
			}
		});
	}
	const options = {
		indent_with_tabs: formattingOptions.insertSpaces === undefined ? true : !formattingOptions.insertSpaces,
		indent_size: formattingOptions.tabSize,
		indent_char: ' '
	};
options.eol = config.files.eol;

The formattingOptions of the current editor doesn't have an eol field: https://code.visualstudio.com/docs/extensionAPI/vscode-api#_a-nameformattingoptionsaspan-classcodeitem-id702formattingoptionsspan
I guess that explains why it's not coming through from there. I'll have a look tonight.

Turns out I didn't get time, and I've dropped the ball a bit here. If the current editor exposed an eol setting, this would be doable.

After having read the docs (where the link you have provided points to), I agree that the eol setting does not seem to be part of the formatting options.
However it seems to be a property of the document itself.
Is it an option to take it from there?

I've logged an issue to hopefully get the problem resolved: https://github.com/Microsoft/vscode/issues/15385
Unfortunately, the eol property isn't on the document, it's set on the editor, and that isn't passed to the extension when using the DocumentFormattingEdits callbacks.
Until VS Code fixes the inconsistent behaviour, there's not much I can do. I suggest setting up a Keyboard Shortcut to use the HookyQR.beautifyFile command and using that instead.

@DennisAhaus, @johnunclesam, @hubbergit. Release 0.6.2 should solve this issue.


Implement :15011 spiffee cert listener for istiod

https://github.com/istio/istio/issues/20713

/cherrypick release-1.5

@howardjohn: new pull request created: #20800

In response to this:

/cherrypick release-1.5

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


mender-connect rename in the diagram.

ChangeLog:none
Signed-off-by: Peter Grzybowski<EMAIL_ADDRESS>(cherry picked from commit f612ea9cfe5997d4012bc245c86a7ad486072411)

Thanks for you attention to details

it was Eystein's attention!


Can the content of panel be a view?

It seem that the content of panel must be text only.
Can I insert some html code or render a view in the Panel?
Thanks.

The panels can load from a view file - see the examples here:
https://cornernote.github.io/yii2-dashboard/docs/panels/


Questions are not being updated to repository after new UI in leetcode coding interface.

Please review previous closed issues before filling out a new one! Duplicate issues will be closed without comment.
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

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

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

#366


Repeat phase throws error

RLException: [/home/uriah/catkin_ws/src/teach-repeat/launch/data_matching_jackal.launch] requires the 'odom_corruption_factor' arg to be set
Is this a true/false? Or is it a number? Is it contained in the data files saved by data_collection phase?
I see that the name of the proper date folder must be edited into the launch file. That is done.
This is on a real robot, not sim.

Does setting use_corrupted_odom fix the error for you? Otherwise setting odom_corruption_factor to 1.0 should also cause no corruption of odometry readings.

Will try that soon, thanks!

Same as #35


Add the eventing source label to indicate the source type

Describe the bug
All eventing sources should have a label to indicate the source type for all the released resources.
The similar label is networking.knative.dev/ingress-provider for all the serving ingresses.
I propose to add the label contrib.knative.dev/source-provider for all the available resources.
Since this repository is for eventing-natss, we will use contrib.knative.dev/source-provider: natss.
Expected behavior
Add the label contrib.knative.dev/source-provider: natss for all resources.
Knative release version
main
Additional context
Facilitate the support in knative operator

/close


bump mongoengine, motor, and pymongo

What changes are proposed in this pull request?
Pin to newer versions of mongoengine, motor, and pymongo - the use of new versions needs to be consistent as variations result in pickle issues, so pymongo has to fit with motor has to fit with mongoengine
This also enables MongoDB 8 support.
How is this patch tested? If it is not, please explain why.

Local testing, ran fiftyone connecting to existing database
local testing, ran fiftyone connecting to empty database

Release Notes
Is this a user-facing change that should be mentioned in the release notes?

[ ] No. You can skip the rest of this section.
[ ] Yes. Give a description of this change to be included in the release
notes for FiftyOne users.

(Details in 1-2 sentences. You can just refer to another PR with a description
if this PR is part of a larger change.)
What areas of FiftyOne does this PR affect?

[ ] App: FiftyOne application changes
[ ] Build: Build and test infrastructure changes
[ ] Core: Core fiftyone Python library changes
[ ] Documentation: FiftyOne documentation changes
[ ] Other

Summary by CodeRabbit

Chores

Updated dependency versions for improved compatibility and flexibility.

The use of ~= will pin each of these libraries to only allow for patch releases to be included
~= 0.29.1

and
>= 0.29.1, == 0.29.*

are equivalent
Let's hope that our upstream providers are better at semver than we are...

Necessary but insufficient information:
I looked through changelog of MongoDB 8.0, I don't see anything of concern.

@benjaminpkane did you thoroughly test this? You said you would not have time this week.

@benjaminpkane did you thoroughly test this? You said you would not have time this week.

I have not. To err on the side of caution, I propose we wait until after dev cut to merge

@benjaminpkane did you thoroughly test this? You said you would not have time this week.

I have not. To err on the side of caution, I propose we wait until after dev cut to merge

definitely agree

Release branches have been thrown, let the fun commence!


Fix for redbox on read message

@keybase/react-hackers
The old code had a section for handling non userInteraction (yet didnt' actually check that flag) then had a section for if userInteraction was true. Turns out its possible to get readmessage calls w/ userInteraction flag on, which this didn't expect so that flow would

Handle it in the first part of the code
Fail to return
Go into the if (payload.userInteraction) code and then have a type it doesn't expect and red box

Instead of adding the extra return I changed this to be a switch statement with more explicit bailouts
cc: @mmaxim

this diff is kinda hard to read so maybe better to look at the code side by side

i'm merging this monday morning