text:
Multisites get all posts

Hi there !
For a website i need to get all the post ( even some postype later ) from the other sites into the main site.
So i try something like this in my search.php
$context = Timber::context();
$context['title'] = 'Search results for ' . get_search_query();

$sites = Timber::get_sites();

foreach ($sites as $site) {
    switch_to_blog($site->blog_id);
    // fetch all the posts
    $query = Timber::get_posts();
    foreach ($query as $post) {
        $blog_posts[] = $post;
    }
    restore_current_blog();
    // display all posts
}

$context['posts'] = $blog_posts;
Timber::render( $templates, $context );

I first use the PostQuery but it didn't work, then i tried this and this doesn't work to. He gets me the posts from the main site.
But i use the get_posts from wordpress it's working.
Can you help me with that ?
Did you do some global post search on your side ?
Thanks a lot :D

I'm gonna see about chasing this one down — stay tuned!

@Drfloo thanks for the issue! In my investigations thus far, there does seem to be an issue where if you send NO arguments to Timber::get_posts() within multisite, you don't receive results.
Try re-stating what you want in there rather than relying on the defaults. For example:
$query = Timber::get_posts(['post_type' => 'post']);

... I still want to supply a true "fix" — but hopefully that can at least get you the functionality you need for now.

Isn’t this the same issue as in https://github.com/timber/timber/issues/1434#issuecomment-593082423? When using get_post(), WordPress will prepare the whole post object and already fill in data like the permalink. In Timber, we do this only when the data is first requested, which is probably not in PHP, but in the Twig template. In this case, that’s too late and Timber will call get_permalink() from the current blog.
You would have to prepare that data you need for each post in your array. So if you need the permalink, you would add a link entry and use $post->link() as a value.
foreach ($sites as $site) {
    switch_to_blog($site->blog_id);

    // fetch all the posts
    $query = Timber::get_posts();

    foreach ($query as $post) {
        $blog_posts[] = [
			'title' => $post->title(),
			'link'  => $post->link(),
			// Add more data here …
		];
    }

    restore_current_blog();
    // display all posts
}

Or am I missing something here?
I opened an issue to tackle this with better documentation in #2207. Preparing all the data you need would probably be the easiest solution. The same pattern has to be used when you prepare data that will be used in JavaScript.
Otherwise I’m imagining we would have to use a function like ms_is_switched() (checks if switch_to_blog() is in effect) and prefill the data when we’re in that context. But that would be a huge performance hit, and it would probably create a whole chain of other problems.

@gchtr I don't know how you have a memory for these things! Yes #1434 nicely summarizes the situation and limits. A lot of this is just inherit in the WP architecture that silos the sites in multisite and makes it difficult to interact across them. A worthy project would be to make this smoother/easier, but I believe that's beyond the scope of Timber. Here's a link I found of a paid plugin that does exactly this: https://rudrastyh.com/plugins/get-posts-from-all-blogs-in-multisite-network
@Drfloo I'm going to close this for now along with #2279. My recommendation is to gather whatever posts you need via explicit queries ...
$query = Timber::get_posts(['post_type' => 'post']);

Unfortunately WP's "loop" is not reliable, but all the more so when switching across sites in Multisite.

authors: Drfloo gchtr jarednova

repo: timber/timber


text:
1118 pagination api

Ticket: #1118
Reviewer: @jarednova
Issue
Pagination is generated based on the default query, requiring an extra query_posts to make pagination accurate for a custom query.
Solution
Set pagination as a method on the PostsCollection object .  The pagination object associated with the collection will use the same query params used to generate the collection, negating the need to tweak the default query (in order to make this work I've set the PostsCollection to keep a private reference to the wp_query object used to create it).  I've also added a Timber::get_posts_collection method to allow for a cleaner way to return a PostsCollection object instead of an array.
Impact
Should have no effect on existing methods.
Usage
 $context['posts'] = Timber::get_posts_collection();

	{% for page in posts.pagination.pages %}

			{% if page.link %}
				{{page.title}}
			{% else %}
				{{page.title}}
			{% endif %}

	{% endfor %}

Considerations
I set the new pagination up to use object attributes rather than an associative array, which seemed to make sense given that we are using a class.   To support the old get_pagination method I'm basically casting the object into an associative array using get_object_vars.  This approach seems to be passing tests fine, but let me know if you see any risks.
Testing
Tests included!

Current coverage is 91.76% (diff: 100%)

Merging #1173 into master will increase coverage by 0.05%

@@             master      #1173   diff @@
==========================================
  Files            39         39
  Lines          3248       3268    +20
  Methods         406        414     +8
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           2979       2999    +20
  Misses          269        269
  Partials          0          0

Powered by Codecov. Last update bf2940a...296ec6b

Coverage increased (+0.1%) to 90.045% when pulling bf59ca64b1d7836c2b635fa3f01c8de296c67bb5 on 1118-pagination-api into bf2940a0bc5d900255689ced1c1042dfb65d1f2f on master.

Coverage increased (+0.04%) to 89.985% when pulling c89a870693b144b44e5ba5bb2352651e35794a21 on 1118-pagination-api into bf2940a0bc5d900255689ced1c1042dfb65d1f2f on master.

Coverage increased (+0.04%) to 89.985% when pulling c89a870693b144b44e5ba5bb2352651e35794a21 on 1118-pagination-api into bf2940a0bc5d900255689ced1c1042dfb65d1f2f on master.

Coverage increased (+0.04%) to 89.994% when pulling db6aba2517efc9f5d231c49f0ba41c30cccc93eb on 1118-pagination-api into 21de974c54833be2fdc95f3d2bd87721933ba407 on master.

Coverage increased (+0.04%) to 89.994% when pulling db6aba2517efc9f5d231c49f0ba41c30cccc93eb on 1118-pagination-api into 21de974c54833be2fdc95f3d2bd87721933ba407 on master.

Coverage increased (+0.04%) to 89.994% when pulling db6aba2517efc9f5d231c49f0ba41c30cccc93eb on 1118-pagination-api into 21de974c54833be2fdc95f3d2bd87721933ba407 on master.

@jarednova Made the following changes:

Turned former PostsCollection class into PostsArray and created new PostsCollection class that can be instantiated with a query, ie. new PostCollection(array('post_type' => 'book'))
The new PostsCollection class contains a reference to the QueryIterator, used to get posts and generate pagination.

Coverage decreased (-0.3%) to 89.924% when pulling 50ba68d5fe67ba8885a58ded7bcf076db9dd06c3 on 1118-pagination-api into 9a5851bf36110dcb399e277d51230f1addb0c53c on master.

Coverage decreased (-0.3%) to 89.924% when pulling 50ba68d5fe67ba8885a58ded7bcf076db9dd06c3 on 1118-pagination-api into 9a5851bf36110dcb399e277d51230f1addb0c53c on master.

Coverage decreased (-0.3%) to 89.924% when pulling 50ba68d5fe67ba8885a58ded7bcf076db9dd06c3 on 1118-pagination-api into 9a5851bf36110dcb399e277d51230f1addb0c53c on master.

Coverage decreased (-0.3%) to 89.924% when pulling 9b84fc576cfa8b97a8314ac0cabdac8cfa3151a4 on 1118-pagination-api into 7631b3dd3e37a100c6cbc23522b1f3630e907d58 on master.

Coverage decreased (-0.3%) to 89.924% when pulling 9b84fc576cfa8b97a8314ac0cabdac8cfa3151a4 on 1118-pagination-api into 7631b3dd3e37a100c6cbc23522b1f3630e907d58 on master.

Coverage decreased (-0.3%) to 89.965% when pulling 7023de385bd855a9aa978649710a39bb8b9afbc2 on 1118-pagination-api into 7631b3dd3e37a100c6cbc23522b1f3630e907d58 on master.

Coverage decreased (-0.3%) to 89.971% when pulling 1913886afd1476b425dc1ead3a8272a5c04d97b7 on 1118-pagination-api into 7631b3dd3e37a100c6cbc23522b1f3630e907d58 on master.

Coverage decreased (-0.3%) to 90.0% when pulling b90639711438e8a21011cf6cd4d75faf2b864dd5 on 1118-pagination-api into dbed6b4bd6a4d5f954d85dd9a4a05e6c2da086ab on master.

Coverage decreased (-0.3%) to 90.0% when pulling d7f6dea7209843a7253444b620f722e6ba6def4c on 1118-pagination-api into dbed6b4bd6a4d5f954d85dd9a4a05e6c2da086ab on master.

Coverage decreased (-0.2%) to 90.035% when pulling 1b4d8efb371cf2cc9f032ca247394e3d2b01880a on 1118-pagination-api into dbed6b4bd6a4d5f954d85dd9a4a05e6c2da086ab on master.

@lggorman we're so so close. Scrutinizer picked-up this potential bug that I want to take a look a w you on Monday....
https://scrutinizer-ci.com/g/timber/timber/inspections/eb00d952-9e07-4eb9-8b17-a7588a3ea97e/issues/files/lib/PostCollection.php?status=new&selectedLabels[0]=9&orderField=path&order=asc&fileId=lib%2FPostCollection.php&honorSelectedPaths=0

Coverage decreased (-0.1%) to 90.167% when pulling 1b4d8efb371cf2cc9f032ca247394e3d2b01880a on 1118-pagination-api into dbed6b4bd6a4d5f954d85dd9a4a05e6c2da086ab on master.

Coverage decreased (-0.2%) to 89.951% when pulling 7341514f3bcf3baed07df0ff5134bebcb1f29df0 on 1118-pagination-api into 31eba3f6e08e0ed41dd66c6e80d8d502bc27057a on master.

Coverage increased (+0.2%) to 90.377% when pulling e26b11cb04172220794c43f1e6517e71b25756b0 on 1118-pagination-api into 31eba3f6e08e0ed41dd66c6e80d8d502bc27057a on master.

Coverage increased (+0.2%) to 90.377% when pulling d208f0b3818d39d992a395562f508416b60ad807 on 1118-pagination-api into 31eba3f6e08e0ed41dd66c6e80d8d502bc27057a on master.

Hi @Timber folks! @lggorman and I would love any feedback on this PR. It's a pretty major (improvement!) that will link pagination to posts that resolve a lot of the confusion with re-running query_posts, etc. that occur now. Here's the basic usage....
Usage
 $context['posts'] = new Timber\PostCollection('post_type=recipe');

{% for post in posts %}

{{ post.title }}

{{ post.preview }}

{% endfor %}

	{% for page in posts.pagination.pages %}

			{% if page.link %}
				{{page.title}}
			{% else %}
				{{page.title}}
			{% endif %}

	{% endfor %}

As seen in the PHP sample above, the new preferred way to get posts (outside the normal query) would be to call a new PostCollection object. The object is a PHP ArrayObject that (as the same suggests) contains the benefits of both data types. This allows both the easy iteration of an array, and methods to retrieve the pagination for that Collection (and future things).
Considerations
By default, the Timber::get_context() array's post attribute will return a Timber\PostCollection (it presently returns a Timber\QueryIterator). Despite this change, all unit tests pass
Questions
The name
The "collection" nomenclature was inspired by Laravel and Backbone. Does it make sense in this context? Another one I've considered is Timber\PostQuery
Default?
Does it make sense to replace the posts attribute from the Timber::get_context (as noted above)? The 👿  on my shoulder says "do it, it's better!" but the 👼  says "don't make it the default quite yet until it's thoroughly tested by the community!" I think I know which I should listen to but I need your help!
Anything else?
This has been a big lift and I'm really proud of the work @lggorman has done to bring it this far. I'm interested in opinions on whether there are opportunities we've missed with this approach or tweaks we could make to help make things both as flexible as possible, and as backwards compatible as possible
Thanks! 🌲

Coverage increased (+0.2%) to 90.339% when pulling 683e4733ac6db19f176b6aca437eccb960cbb167 on 1118-pagination-api into 21fd191e7b161f0318667a04c26fc3f191fc0d84 on master.

Coverage increased (+0.2%) to 90.368% when pulling aa83d0f602675fcd59b73115cb3cd8e77f5f21ff on 1118-pagination-api into 21fd191e7b161f0318667a04c26fc3f191fc0d84 on master.

Coverage increased (+0.2%) to 90.368% when pulling aa83d0f602675fcd59b73115cb3cd8e77f5f21ff on 1118-pagination-api into 21fd191e7b161f0318667a04c26fc3f191fc0d84 on master.

Coverage increased (+0.2%) to 90.368% when pulling 0960a73d2ed71bb5c60bccb3f94860d51202b8f2 on 1118-pagination-api into 21fd191e7b161f0318667a04c26fc3f191fc0d84 on master.

source: gharchive/pull-request

authors: codecov-io coveralls jarednova lggorman

license: MIT

license_type: permissive

license_source: github-api


text:
2.x Refactor context and third-party compatibility

I thought about the context again and I think I don’t like the solution I proposed in #1766 🙃. I think it might be easier if template contexts didn’t work dynamically. There are a couple of reasons:

I started using the 2.x-branch on our own starter theme and updated the parts where the context was used. While doing that, I figured that I had to think too much about how the context works and what it was doing.
The common flow for Timber templates seems to be Context > Context Customizations and data gathering > Render. With the current context implementation, it leads to situation where one might gather data for the context before using context(), and some afterwards. I just feel like this leads to templates that are hard to read.
Some people may not want to use post or posts in their context, but more explicit names. For an event post type, using events instead of posts might be more preferrable. The workaround to get that would be too complicated.
When people update Timber to 2.x, they won’t necessarily read the Upgrade Guide properly. And they probably won’t change the existing context if they don’t get a deprecation message. I guess it wasn’t really clear until now that posts was already set in the context. I think people won’t rewrite all their templates for some little magic. We’d only harm performance if we’d leave it here.

I guess I wanted add too much magic. I think we should remove the magic from the context and make it easier to expect what you get. Back to the drawing board!
What I initially wanted to achieve was:

Have a separate global context, where no posts are set.
Make it possible to prepare the template for the current post in singular templates, because there we need so set some variables and call hooks for better compatibility.
Make it possbile to easily change the default query.

Let’s have a look at these goals in more detail:
1. Global context
I think the global context works fine when we remove posts. Going on, $context['posts'] needs to be set manually. Having to write a little line of code is probably no harm, but will make the code more readable in terms of «What do I have in my context?».
2. Prepare template for the current post
What we need to do is basically have a the_post() function for Timber. This function is used in WordPress to setup the "context" for the post that is about to be rendered. We already have this for post loops in Timber, but not yet for singular templates that don’t have any loops.
For having some kind of the_loop for singular templates, I see different approaches:
A context_post() function
I first thought that context_post() might be a good idea.
$context         = Timber::context();
$context['post'] = Timber::context_post();

Timber::render( 'single.twig', $context );

We can now see that we have post in the context. By not passing anything to context_post(), we could assume that it uses some defaults. The currently displayed post maybe?
Use it with a custom post
$context         = Timber::context();
$context['post'] = Timber::context_post( 85 );

Use your own class
$context         = Timber::context();
$context['post'] = Timber::context_post( new Extended_Post() );

A setup function
The new proposed method for fetching a Timber post in Timber 2.x is not Timber::get_post(), but new Timber\Post().
$context         = Timber::context();
$context['post'] = new Timber\Post();
$context['post'] = new Timber\Extended_Post();

So I’d rather leave it like that and not have a wrapper function like context_post() that takes care of the setup. So we’d need a separate setup function. Now, where could we place a setup function? (The following thoughts were sparked by the discussion in https://github.com/mindkomm/timber-integration-woocommerce/issues/6)
A global the_post function
There could be a function like the following that does the setup for us. By calling it the_post(), we stick to what people might be used from using WordPress.
$context['post'] = new Timber\Post();

Timber::the_post( $context['post'] );

Now the question is that e.g. for setting up a post for WooCommerce, we need also need to setup a $product global. Luckily, WooCommerce uses the the_post action, so that would be covered here. But is there a more elegant solution?
A setup method on Timber\Post
$post = new Timber\Post();
$post->setup();

$context['post'] = $post;

or even
$context['post'] = ( new Timber\Post() )->setup();

A setup method would probably be more flexible. I think that maybe the right place to call a setup method is not globally, but on a post itself. By having it in a separate setup() method and not in the constructor, we can decide when we want to call it.
This is what the PostsIterator currently looks like:
class PostsIterator extends \ArrayIterator {
    public function current() {
        global $post;

        $post = parent::current();
        return $post;
    }
}

Instead of having a posts iterator care about what to do with the post, we could call the setup method instead:
class PostsIterator extends \ArrayIterator {
    public function current() {
        $post = parent::current();
        $post->setup( $this->key() );

        return $post;
    }
}

And then, the setup method would look like this:
class Post extends Timber\Core {
    public function setup( $loop_index = 0 ) {
		global $post;
		global $wp_query;

		// Overwrite post global.
		$post = $this;

		/**
		 * Mimick WordPress behavior to improve compatibility
		 * with third party plugins.
		 */
		$wp_query->in_the_loop = true;

		// Fire action when the loop has just started.
		if ( 0 === $loop_index ) {
			do_action_ref_array( 'loop_start', array( &$GLOBALS['wp_query'] ) );
		}

		// The setup_postdata() function will call the 'the_post' action.
		$wp_query->setup_postdata( $post->ID );

		return $this;
	}
}

And for a WooCommerce Product class that needs to call wc_setup_product_data() in addition to what Post::setup() already does, it could look like this:
class Product extends Timber\Post {
    public function setup( $loop_index = 0 ) {
        parent::setup( $loop_index );

        wc_setup_product_data( $this->ID );

        return $this;
    }
}

This would even be better for the WooCommerce integration, because we wouldn’t need a separate ProductIterator class. We could do it in the setup method.
Even if somebody needed to add more logic, they could write their own class that extends a Product class and overwrite the setup() method. Straightforward.
The only question that would remain: after looping, how do we set back the query (discussed in #1771)?
3. Change the default query
Archive templates don’t seem to be much of a problem to set up, because all of the heavy work is done when looping over posts. The missing piece I actually wanted to add was to change the default query that is used.
The new proposed method for fetching a collection of Timber posts in Timber 2.x is not Timber::get_posts(), but new Timber\PostQuery(). By not passing in any variables, it would fetch the default query.
$context          = Timber::context();
$context['posts'] = new Timber\PostQuery();

I first thought that a Timber::context_posts() function might be a good idea.
Changing the default query would mean to pass new arguments to it. The passed arguments would be merged with the default query.
$context          = Timber::context();
$context['posts'] = Timber::context_posts( array(
    'post_parent' => 0,
) );

But calling it context_post() now seems to be a bit unclear to me. Maybe merge_default() would be better. But should it then be added to the Timber class?
Maybe we should be able to tell PostQuery what it should do with the parameters that we pass in. By using a merge_default argument, we could tell it to merge the passed arguments with the default query.
$posts = new Timber\PostQuery( array(
    'post_parent' => 0,
), array(
    'merge_default' => true,
) );

Coming back to a wrapper method: Why not add it as a static method to Timber\PostQuery()?
$posts = Timber\PostQuery::merge_default( array(
    'post_parent' => 0,
) );

Solution
This pull requests:

Practically resets the context to what it was before #1766 by removing the context_post() and context_posts() functions.
Updates the Context Guide.
Adds a setup() function to Timber\Post and updates Timber\PostIterator to work with it.
Adds a merge_default() function to Timber\PostQuery.

Discussion
I guess sometimes we need to take a detour to come to a better solution. Are there any thoughts? Things I missed? Is it a direction that will work in the future? I’d love to hear feedback.
I didn’t write any tests yet, because I first wanted to put my thoughts out there.
TODO

[x] Write tests
[x] What changes need to be made to QueryIterator?

@jarednova I guess first it would be enough to hear what you think about

The idea of adding a setup() method for Post and wether you can think of any other implications, e.g. in combination with QueryIterator.
The idea of adding a PostQuery::merge_default() method, the name of the function and whether there might be a better place for this.
Whether there are other directions we could take for having a function that mimicks the the_post function in WordPress?

(As usual 🙃) it’s quite a long text, but I like to list my thoughts and how I came to an idea.
I haven’t tested it, so that would be the next step. And then write tests for it. And then I guess you could do a more thorough review. Except if you want to take over from here 😉.

One random opinion:
The suggestion of ways to modify the PostQuery seem a bit strange to me. Why not something like this:
$posts = new Timber\PostQuery( [
    'query' => [
        post_parent' => 0,
    ],
    'reconcile_query' => 'merge', // could also be a boolean flag to replace or merge query, the name of this is less important
] );

This allows PostQuery to have a single array of options which feels a little cleaner and easier to handle.

@gchtr Here are my comments about your PR:
1. Global context
I think the post/s should be in the global context as in WordPress they are also in global scope for each page and there is no neeed to get them explicitly. At the moment I just think the documentation was too unclear about that.
2. Prepare template for the current post
Yes we really need to have this as already mentioned in the discussion at https://github.com/mindkomm/timber-integration-woocommerce/issues/6
What I currently don't like is, that the setup function needs to call explicitely. Is there maybe a way we can do better? I think for a single post the setup function can run immediately when instantiating it. For the iteration it would need to call the setup on current() as you already did and then we would need to reset the query after the last post has been accessed.
I also think that if we have a setup function we will also need a teardown function. Currently the $wp_query->in_the_loop is set to true after the posts have been accessed which I don't like. Thus I am thinking about the teardown method to fix this and reset globals (like $product) global.
What I really like is the $wp_query->in_the_loop = true;. This will fix many incompatibilities with existing plugins.
3. Change the default query
What I don't really get is the merge_default() function, which would be a great function to have btw. But at this time in the rendering flow the global $wp_query query is already completed or am I missing something? This will not take the global query right?
In general great ideas. These features/improvements will be great to have.

EDIT: Also I have read this issue a few times but still don't feel like I fully understand it, so feel free to ignore me… but that said, I also feel like the static context_posts or merge_default methods are kind of confusing. The setup method seems like the right way to do this rather than trying to do magic inside static methods.

Sorry, if this is a little confusing. But there’s a lot going on. I already thought a lot about this. It started out with #1639, which led me to #1766 and then on to this pull request. I didn’t explain everything in this pull request. Probably it’s required to read the linked issue and pull request as well 🙈. Additionally, #1771 is a side issue that plays into this, too.
That’s why your comments are truly appreciated! We need to be on the same page for this. I can’t decide alone how Timber should work. I know, my comments are quite long at times, but I like to list the options that we could choose and think about the pros and cons.
To explain a bit more, I’m gonna start with point 2 and come back to point 1 about the global context in the end.
2. Prepare template for current post
A teardown function

I also think that if we have a setup function we will also need a teardown function. Currently the $wp_query->in_the_loop is set to true after the posts have been accessed which I don't like. Thus I am thinking about the teardown method to fix this and reset globals (like $product) global.

True! I thought about a reset/teardown function after queries in #1771, but not for having it on a post itself. Great point! I think a teardown function would be great to reset all the data that was set up in the setup function.
Automatic setup

What I currently don't like is that the setup function needs to call explicitly. Is there maybe a way we can do better? I think for a single post the setup function can run immediately when instantiating it.

Having a call on post instantiation is the thing I tried to avoid after gathering all weird issues about this in #1639.
Consider the following example:
$context = Timber::context();

$context['post']        = new Timber\Post();
$context['myotherpost'] = new Timber\Post( 744 );

Timber::render( 'single.twig', $context );

In this example, when post.twig is rendered and Timber runs the setup function automatically, for which post would the template be set up? It would be set up for myotherpost, because it runs afterwards, which may not be what you want, when you want post to be your main post of the template.
As long as you’re not in the template to display something, I think there’s no use in setting up a post and calling hooks, because every new instantiation would just overwrite the one before it. This includes the functions that can be used in Twig: {{ Post() }}, {{ Image() }}, etc. Consider the example where you’d have your logo saved as an ID and convert it to a Timber\Image just when you use it:
<img src="{{ Image(my_global_logo_id).src }}">

This would set up the "context" for the content to follow. I myself try to avoid this already. But it’s possible in Timber and developers use it, so we need to consider this as well.
I guess a teardown function wouldn’t change the problem. A teardown function is great for loops over Timber posts, but doesn’t help in the context of a singular templates. Tell me if I’m missing something!
Call setup for singular templates
For the reasons listed above I still think that for singular templates, we have to tell Timber manually which post it should use as the "main post". I’m again listing the options I came up with:
a) Solve it through context
This is practically the functionality I initially had in mind in #1766. The guide for how this solution would be used can be found here.
The idea is that you pass the post you want to setup to the context. By default, it would take $post global and make post available in the context:
$context = Timber::context();

var_dump( $context['post'] ); // Outputs the $post global

If you’d want to set a different post, you could use:
$context = Timber::context( array(
    'post' => new Timber\Post(),
) );

Internally, the Timber::context() function would call Timber::context_post(). That function would be a wrapper that calls setup() on a post. It could also be called manually:
// Use the $post global.
$context['post'] = Timber::context_post();

// Use a custom post.
$context['post'] = Timber::context_post( new Timber\Post( 85 ) );

Maybe we would need to consider different names instead of Timber::context_post(). Maybe Timber::context_singular() would be clearer?
b) Use the $post global
Coming back to what I said above:

If you’d want to set a different post, you could use:
$context = Timber::context( array(
   'post' => new Timber\Post(),
) );

When I think about this again, I’m not so sure anymore if we ever need this, or if this is just an edge case that we don’t really have to cover.
@pascalknecht said:

I think the post/s should be in the global context as in WordPress they are also in global scope for each page and there is no neeed to get them explicitly.

Because that’s right, singular pages already have a $post global they work with. If somebody wanted to switch out the $post global, they should do it through some hook, but it might not be something that Timber has to handle.
So for singular templates, it could work like this:
$context = Timber::context();

Here, post will be automatically set in the context. Timber will use the $post global to set up a new Timber\Post and call its setup() method in the back.
The only thing we could do in addition to that is to make it possible to disable post in the context. But then, a developer is on his own with compatibility.
$context = Timber::context( array(
    'post' => false,
) );

c) Use a setup wrapper
Another option I see is a function that wouldn’t return anything, but would call the setup function for the post you pass in.
Timber::the_post( $post );
Timber::render( 'single.twig', $post );

If we try to find a name for «You need to tell Timber which post it should use as the main post, it could also be called Timber::main_post(). But probably we don’t want to introduce more static methods (thanks for point this out, @chrisvanpatten).
d) Call the setup function on a post explicitly
$post = new Timber\Post();
$post->setup();

$context['post'] = $post;

Because the setup() function would return the post again, it could also be shortened:
$post = new Timber\Post();
$context['post'] = $post->setup();

// Or even this, for seasoned developers.
$context['post'] = ( new Timber\Post() )->setup();

This would be the most direct approach that doesn’t try to hide the setup() function in a wrapper function. And it wouldn’t introduce more static functions, like @chrisvanpatten mentioned.
Archive templates and post loops

For the iteration it would need to call the setup on current() as you already did and then we would need to reset the query after the last post has been accessed.

This is also what I’m looking for in #1771. How can we automate this? Can we have a hook or a function that is called after a loop without having to manually call it?
3. Change the default query
Sorry about the confusion on this one. This point is not really about improving compatibility with WordPress and third party plugins, but about the context and about the main query that is used in a template. In #1766, I explored how we could improve the context and I figured it would be good to have a function to adapt the default query that WordPress prepares for a template, before that query is used to fetch posts.

But at this time in the rendering flow the global $wp_query query is already completed or am I missing something? This will not take the global query right?

When we are in a template, no posts are fetched yet. Posts are fetched when we create a new PostQuery(). When we don’t pass any parameters into it, it will use the default query for the current template. As soon as we pass arguments into PostQuery(), it will overwrite the default query.
There’s no easy method to merge arguments that are passed into PostQuery with the default query. That’s why I proposed merge_default().
In the current version, PostQuery works like this:
$posts = new Timber\PostQuery( $query_args, $post_class = 'Timber\Post' );

I thought about a pattern like this:
$posts = new Timber\PostQuery( $query_args, $options );

The $options arg could be filled with variables that affect the query passed in the first parameter.
The $options arg would also the take a post_class parameter, where you could pass in the class that Timber should use to create posts.

$posts = new Timber\PostQuery( array(
    'post_parent' => 0,
), array(
    'merge_default' => true,
) );

@chrisvanpatten You proposed to use a pattern like this:
$posts = new Timber\PostQuery( $args );

This would mean that PostQuery would only accept one parameter, right?
If we wanted to merge in the default query and pass a custom post class, it would look like this, right? Because merge_default, or reconcile_query would both be options for the query that should live on the same level.
$posts = new Timber\PostQuery( array(
    'query' => array(
        'post_parent' => 0
    ),
    'merge_default' => true, // Or whatever name we choose.
    'post_class' => 'Timber\Post',
) );

Of course this will work too, yet I see that setting up a query that uses the default options would always require you to wrap it in a query array and require you to write more:
$posts = new Timber\PostQuery( array(
    'query' => array(
        'post_type' => 'wow',
        'posts_per_page' => -1,
        'post_status' => 'publish',
    )
) );

Backwards compatibility could work. We’d have to check if a query is present.
If we take the perspective that for 2.x, we try to eliminate more static functions, then Timber\PostQuery::merge_default() is not really a good solution to be honest 😅.
Solve it through context
With what I said above about using the $post global in 2. b), maybe we don’t need to solve this through the PostQuery() or a merge_default() function. We might use PostQuery() quite often, but the only place we ever need it is for the main query in archive templates.
Here’s a new idea: What if archive templates always set posts in the context and take the default query to fetch posts? When you pass in a posts parameter to Timber::context(), you have two options:

Pass in query arguments to change the default query by default. No need to use cancel_default_query or other keywords.
If you don’t want posts in the context, you could pass in false. You could then write your own query.

// posts will be set in context using the default query.
$context = Timber::context();

// The passed arguments will be merged with the default query.
$context = Timber::context( array(
    'posts' => array(
        'post_parent' => 0,
    ),
) );

// Set posts to false to create your own query
$context = Timber::context( array(
    'posts' => false
) );

$context['posts'] = new Timber\PostQuery( $my_own_args );

1. Global context
The solution for having dynamic template contexts was proposed in #1766. I didn’t like it for the reasons mentioned right at the beginning of the pull request you’re reading now. In this comment, I’ve explored more options, which in the end could affect the global context.
Summary
Here’s what I prefer now:

Timber::context() will accept an argument array, containing post or posts.
For singular templates, post will be automatically set when Timber::context() is called (Option 2. b)).

It’s possible to disable this by setting post to false.

For archive templates, posts will be automatically set using the default query when Timber::context() is called.

It’s possible to change the default query by passing query arguments to the posts argument in Timber::context().
It’s possible to disable the default query by setting posts to false.

Have a setup() for Timber\Post.

It can be used by Timber::context() to setup the post for the current template.
This will make it more versatile to use it in post loops.

I hope it’s a little clearer now.
Maybe sometimes I’m trying to bring in too many edge cases. But I’ve seen so many questions on Stackoverflow and in the issues of this repo that I’d like to have a solution that is versatile, easy to understand and easy to read.
What do you think?

@gchtr I wouldn't remote the PostsIterator as it makes sense to have it. The fact that you included loop code in the setup method says that one such class would still be good to have to not make Timber\Post responsible for too many things.
Here is my current implementation (not tested yet):
class PostsIterator extends \ArrayIterator {
	/**
	 * Calls the setup function of the current post
	 * to setup post data
	 *
	 * @return mixed
	 */
	public function current() {
		// Fire action when the loop has just started.
		if ( 0 === $this->key() ) {
			do_action_ref_array( 'loop_start', array( &$GLOBALS['wp_query'] ) );
		}
		$post = parent::current();
        $post->setup();
        return $post;
	}

	public function next()
	{
		$post = $this->current();
		$post->teardown();
		// Fire action when the loop has ended.
               // Maybe there is a better solution for this if
		if ( $this->count() === $this->key() ) {
			do_action_ref_array( 'loop_end', array( &$GLOBALS['wp_query'] ) );
		}
		parent::next();
	}
}
`

@gchtr I think the "Here’s what I prefer now" section of your last post there seems like a good compromise!
The one thing I would reiterate from my original comment (and this is not specifically referencing any of your examples or anything, just a general observation) is to be careful of too much magic.
I think explicitness is always better, even if it means a extra lines of code, extra characters, etc. I love Timber but think it sometimes errs on the side of being a little too clever and magical.
Yes, explicitness requires developers to do a little more work, but I think it promotes a better understanding of how Timber interacts with WordPress and better development patterns. I called out static methods in particular, but I think it's worth thinking about in all situations.
That's one reason I like the explicitness of setting a 'query' item inside a single $args array, rather than separate method arguments: it makes it clear exactly what you're passing in, and the purpose of the code. (This would be a moot point if PHP supported named method parameters, but sadly it does not.)
Really excited to see this come together and thanks for tolerating my philosophical rambling :)

I wouldn’t remove PostsIterator either. I think putting the loop_start and loop_end hooks into the PostsIterator class is a really clean solution.
And it looks like @pascalknecht found the solution for #1771 🎉. Thanks! We can also put wp_reset_postdata() into the next() function, so that the loop will be properly reset. I added two small tests, and it seems to be working.
@chrisvanpatten Well, it looks like we’re on the same page here!

I think explicitness is always better, even if it means a extra lines of code, extra characters, etc. I love Timber but think it sometimes errs on the side of being a little too clever and magical.
Yes, explicitness requires developers to do a little more work, but I think it promotes a better understanding of how Timber interacts with WordPress and better development patterns. I called out static methods in particular, but I think it's worth thinking about in all situations.

Yes! Totally agree! I’m probably guilty of trying to add some sprinkles of magic here and there. You make a really solid argument for having only one array for PostQuery. But it’s cool that we wouldn’t need this now. Except that we do if we won’t add the little "magic" to the context. And by magic I mean setting posts or post by default. This question maybe sits a little in-between, because we could make Timber behave more like WordPress by default, or leave it open and give developers the choice whether they follow the standards. That’s where Timber also shines: it’s versatile!

Except that we do if we won’t add the little "magic" to the context. And by magic I mean setting posts or post by default.

This is actually a good example of what I think is bad magic, but I'm also the type of person who gets frustrated that WordPress does this ;-) Generally my take is that it's better to ask developers to be specific about the type of data they want passed into the Twig template. It keeps the core pretty minimal and allows you to more easily use your own objects extending from core classes (or replace them entirely). It also means less of an ongoing burden to maintain compatibility for the various types of data inside context… because once something goes Into context, it will be really hard to pull out without breaking a lot of things.

@gchtr I'm just catching up on all the back-and-forth I missed. I think you, me, @chrisvanpatten and @pascalknecht all are on the same page philosophy-wise. Let me know when you're ready for me to take a full in-depth review of the code/tests

@gchtr what should we do with $posts_iterator = apply_filters('timber/class/posts_iterator', $posts_iterator, $returned_posts, $post_class); then? It will probably not be needed after these changes.

Generally my take is that it's better to ask developers to be specific about the type of data they want passed into the Twig template. It keeps the core pretty minimal and allows you to more easily use your own objects extending from core classes (or replace them entirely).

True that! Extensibility is a good point as well. Though for Timber, I guess there are also a lot of developers who use it without much of their own OOP coding. A cool thing about Timber is that it has a low entry level, but allows to bring in your own complexity.

It also means less of an ongoing burden to maintain compatibility for the various types of data inside context… because once something goes Into context, it will be really hard to pull out without breaking a lot of things.

Definitely! The thing here is that currently posts already exists in the context, but for every template and not just for archive templates. This wasn’t documented very well yet. So we can either improve this or break it with a major version of Timber.

what should we do with $posts_iterator = apply_filters('timber/class/posts_iterator', $posts_iterator, $returned_posts, $post_class); then? It will probably not be needed after these changes.

@pascalknecht Good catch! No, we wouldn’t need the timber/class/posts_iterator filter, because most of what’s needed can be changed through the setup() function in the post class or an extended post class. At least for the WooCommerce integration. But I see no reason why it shouldn’t work for other use cases.
I pulled in Pascal’s pull request.

Let me know when you're ready for me to take a full in-depth review of the code/tests

@jarednova I guess we’re still trying to find the best conceptual solution before we dig deep on tests. But if you have any input on that, it would help as well!
I think the biggest question we should solve first is: How do we setup a post for a singular template? How and when do we call a post’s setup() function? Should it be automatic? Should it be explicit? I’ve explored some options in https://github.com/timber/timber/pull/1778#issuecomment-419340552, but I’m still not quite happy and not sold on anything yet. Any other ideas?

Changes
Here are the changes since my last comment:

Added context_global() function to get the global context.
Added context_post() function to get post context for singular contexts and added call to Post::setup() inside that function.
Added context_posts() function to get posts context for archive contexts.
Updated Timber\PostQuery() to take an argument array instead of two parameters.

Tests

Removed deprecated tests.
Updated existing tests with new PostQuery argument array.
Added new test to check if merge_default works for PostQuery.
Added new test to check whether there’s a proper deprecation message when using the old parameter style for PostQuery.

Explanation
Here’s the current behavior:

The context will set post for singular templates and call the setup() function on a post.
The context will set posts for archive templates.
If you want to overwrite something in the context, you can do that explicitly. If you overwrite post in the context, you have to call setup() manually.
If you want to merge your query arguments with the default query, you can do that through the merge_default argument for PostQuery.
If you want to use the context inside a partial, in a shortcode for example, it’s probably better to use Timber\context_global().

Automatic template contexts
I thought again about not adding too much magic. I kinda liked the idea to not introduce parameters for Timber::context(). I didn’t check this properly before, but WordPress already runs queries for archive templates and has the $post global ready for singular templates. Setting up posts or post in the context for the current template shouldn’t create new database queries. It should be cheap to do that. And the best benefit of this is that for singular templates, we can call the setup() method on a post inside Timber::context_post(). I talked with @pascalknecht about that, and we didn’t see any easier solution. If somebody still wanted to use something different for posts or post, they could do that.
For singular templates, using a custom class would mean that you have to call the setup() function yourself.
// Using an extended class
$context = Timber::context();

$post = new Extended_Post();
$post->setup();

$context['post'] = $post;

// Or very short
$context['post'] = ( new Extended_Post() )->setup();

For archive templates, they can write a new PostQuery.
// Using a custom query
$context          = Timber::context();
$context['posts'] = new Timber\PostQuery( array(
    'query' => array(
        'posts_per_page' => 3,
    )
) );

// Merge with default query
$context          = Timber::context();
$context['posts'] = new Timber\PostQuery( array(
    'query' => array(
        'posts_per_page' => 3,
    ),
    'merge_default' => true,
) );

Here I added the argument style for PostQuery that @chrisvanpatten proposed. I think it‘s quite easy to read and to see what’s going on. And I’m a big fan of argument arrays myself, used in combination with wp_parse_args(). Using an array also has the benefit that if you only want to the change the post class that is used, you don’t have to pass in a first parameter.
A question I had was: How can I change the post class that Timber will use when I can’t pass in arguments to the context?
// Using a custom post class
$context          = Timber::context();
$context['posts'] = new Timber\PostQuery( array(
    'query' => array(
        'posts_per_page' => 3,
    ),
    'post_class' => 'Book',
) );

The recommended way would probably still be use the timber/post/post_class filter and add a class map there.
Performance
In any case where you run a new Timber\PostQuery with query arguments or create a new Timber\Post() with an argument, data will be fetched from the database. It’s always a performance hit.
As long as you don’t change any query parameters, no additional database query will be run.
Considerations

@chrisvanpatten proposed to use reconcile_query as the keyword for «merging in the default query». As a non-native English speaker, I have to say that the term «reconcile» might be advanced vocabulary that I fear will be hard to understand. But I’m open to suggestions for better wording.
Do we need a filter to disable automatic template contexts?

TODO

[ ] Update Context guide.
[ ] Update documentation for using PostQuery in Twig.

Apart from the documentation, I’d say this would be ready. It’s the best I have now. Suggestions are still very welcome.

@pascalknecht We could easily put that into context(), indeed! In an earlier version, I had much more logic in there, but I see now that separate methods do not bring much benefit.

I updated the context guide to reflect the current implementation. I removed the todo for documenting PostQuery in Twig and open a separate pull request for that.
From my side, this pull request is finished. At least for the current state in 2.x. Depending on what happens with object factories we maybe have to update the context again.

Awesome! I'll give things a final pass and merge

@jarednova Thanks for taking a detailed look at the context guide as well as the rest of the code. What do you think, is this ready to merge now?

'tis! Let's make it happen

authors: chrisvanpatten gchtr jarednova pascalknecht


text:
🛑 IBT is down

In dfe7d6e, IBT (https://ibtrussia.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: IBT is back up in 9b9df57 after 40 minutes.

source: gharchive/issue

repo: timbze/upptime-sword-repos


text:
Adds support for network latency metric.

Signed-off-by: Harkishen-Singh harkishensingh@hotmail.com
Fixes: https://github.com/timescale/o11y-team-applications/issues/194
Description
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Merge requirements
Please take into account the following non-code changes that you may need to make with your PR:

[x] CHANGELOG entry for user-facing changes
[x] Updated the relevant documentation

@Harkishen-Singh Can you please explain in the description what do you mean by network latency.

Mixin CI check is failing due to https://github.com/timescale/promscale/issues/1446. You can safely ignore it for now.

repo: timescale/promscale


text:
Changed meaning of .+= in Julia 0.5

Your test code uses x .+= y, so you should know that in Julia 0.5 this has changed meaning to be equivalent to broadcast!(identity, x, x .+ y), so that it mutates the x array (see JuliaLang/julia#17510 … in Julia 0.6 the whole operation will occur in-place without temporaries).  So .+ should only be used if the left-hand side is a mutable array, and you don't mind mutating it.
At first glance, this looks like it is okay for you, because you use it in counts .+= 1, where counts seems like an array that you won't mind mutating.  But if it were a problem you could always change it to +=.

Not relevant anymore

authors: stevengj timholy

license: mit

license_source: bigquery


text:
Reproducing the results on 3Q05

Hi,
Thank you for the exciting work!
I have been trying to reproduce the results on the PDB: 3Q05 as shown in Fig. 4 of the paper, but it seems that my results are a little bit different from the Source data for Fig. 4. Here is what I've done.

set up the environment as the instructed
download the 3Q05's structure from RCSB: 3Q05.pdb
run the pipeline successfully without errors: ./process_and_predict.sh and ./vis_interpret.sh 3Q05
use the post-processing code in  #8  to map the atom indices to the RI differences

Here is the relevant part of the output (sorted):

In comparison, the source data shows that the LYS120C residue should have the maximum RI, followed by LYS120B, ARG280A, and then ARG280D.
Is this something that may be expected on different devices or are there any steps that I am doing incorrectly that may be causing the inconsistency? Thank you for your help in advance!

Hi there,
Thanks for pointing this out. The model always outputs a forward and a reverse prediction. Either of which could be used in these tasks (or an average of both).
Turns out the github version of interpret.py was not using the same version used to generate source data. I changed that to be same, see commit 738a9d272057c10196a0f0766c0b522743c5403b . This will result in values consistent in order, with the source data.  There will still be some numerical differences, because the per atom perturbation values being normalized are extremely small.
I shall also note that the Max aggregation is probably not very robust, compared to average.
Closing this issue now. Feel free to reopen if you have any further questions :)

authors: WangJiuming timkartar

repo: timkartar/DeepPBS


text:
Breaks "Insert trailing newline"

This extension seems to break the "Insert trailing newline" feature in vscode.
Extension version: 0.8.1
VScode version: 1.40.1

It should not, I think it's caused by some other shell formatting tool, or the "editorconfig" itself.

authors: baelter timonwong

repo: timonwong/vscode-shellcheck


text:
Self-debiasing yields unexpected results

Hi Timo, thanks for the cool work you've done around PLMs! ❤
Been trying out the package, albeit on a smaller GPT model on a different language, and the results of using the debiasing feature is quite unexpected. My use case is similar to the IMDB review generation, where we generate sentences of opposite polarity, and I provide instructions/examples prompt like in GPT-3's paper.
To use the self-debiasing feature, I indicated that positive sentences should be different from negative sentences. However, the results of the generation are skewed: only one label has good sentences, and the other label has gibberish. My guess is that my examples had similar sentence structure, with just the sentiment words flipped, so the model was trying to avoid generating similar sentences.
For generating sentence with different polarity, wondering what are the best practices, or if I was doing anything wrong?

Hi @neoyipeng2018, thank you for your interest in our work 😊
A couple of thoughts:

We've been doing some experiments with smaller LMs on other languages, and this didn't work particularly well in many cases. Which language/model have you been working with?
Could you share your task specification with me (similar to this one for IMDB) so that I can check whether something looks wrong there?
Did you try whether it works well for both labels if you do not use self-debiasing?

Hi @timoschick, i see, thanks for sharing - i was working on chinese language, trying out a few of the models here: https://huggingface.co/models?language=zh&pipeline_tag=text-generation&sort=downloads.
Sure, it goes something like this, but in chinese:
LABEL_1
Generate 3 positive news headlines:
Headline 1: "Profits went up this quarter"
Headline 2: "We managed to acquire company XYZ at a low cost"
Headline 3: "
COUNTER_LABEL=LABEL_2
LABEL_2
Generate 3 negative news headlines:
Headline 1: "Profits went down this quarter"
Headline 2: "We did not manage to acquire company XYZ"
Headline 3: "
COUNTER_LABEL=LABEL_1
Yea, when I set lambda to 0, the outputted sentences were both alright. I was hoping to use the self-debiasing feature though, because otherwise I could probably just use huggingface's pipeline directly?

I was hoping to use the self-debiasing feature though, because otherwise I could probably just use huggingface's pipeline directly?

Yes, absolutely. This was just meant to be a sanity check to trace the root of your problem. Unfortunately, I don't really have a good intuition as to where your problem comes from as I haven't worked with Chinese LMs before. You may try DINO with some English language model just to see whether everything works as intended there, that may help if there are any issues with the implementation itself or the environment you're using to run it. Apart from that, I'm afraid I don't have any useful suggestions at the moment.

repo: timoschick/dino


text:
Object generated by protobuf-ts seems not support TWO-WAY binding in vue.

Object generated by protobuf-ts seems not support TWO-WAY binding in vue.

@jmzwcn, protobuf-ts generates simple objects. I encourage you to try two-way binding in Vue with simple objects first, then pull in protobuf-ts in a separate step. If you still think protobuf-ts should change behavior after that, please explain how and why.

could you please provide an example for how to two-way binding in vue?  ^_^

let card:Card=Card.create()

thanks!

File an issue with Vue.

authors: jcready jmzwcn timostamm

repo: timostamm/protobuf-ts


text:
Output repeats comment twice

(X)Failing test here PR https://github.com/timothycrosley/isort/pull/303 showing that:
from flask import url_for
# Whole line comment
from service import demo  # inline comment
from service import settings

becomes:
from flask import url_for
# Whole line comment
from service import demo  # inline comment
# Whole line comment
from service import settings

Thanks for identifying this issue so clearly, will make sure to get it fixed before 4.1.0
Thanks!
~Timothy

Fixed in version 4.1.0
Thanks!
~Timothy

authors: timothycrosley tomviner

repo: timothycrosley/isort


text:
Add option to install for specific user (10.11 only)

10.11 added the option to install a profile to a specific user by adding the -U option.
sudo profiles -I -F studentdock.mobileconfig -U student installs the profile to just the student account when logged in.
Would it be possible to add this functionality to make-profile-pkg?
./make-profile-pkg.py studentdock.mobileconfig -U student

Just added an untested option in d64c1f4defeaf429f8ad1eddf41d1a0b1ecd7449.

authors: golbiga timsutton

repo: timsutton/make-profile-pkg


text:
options for number of issues or filters for list

What about having an option on list to only show the X most recent issues/PRs instead of the whole list? And/or allowing to apply some filters, like assignee or type. Something like:
doing list --recent 10
doing list --author "john jane.doe@email.com"
doing list --type "task bug"
doing list --status active

The author filter could use the defaults that we will eventually add to the config file.
Some of these options could also be set as defaults on the config file (for example, if I don't want to see User Stories, just Tasks and Bugs; or if I want to include Resolved tasks, which are hidden by default at the moment).

I figured this issue would pop up. It makes most sense to mimic the github-cli of gh issue list, for consistency. Which is:
  -a, --assignee string    Filter by assignee
  -A, --author string      Filter by author
  -l, --label strings      Filter by labels
  -L, --limit int          Maximum number of issues to fetch (default 30)
      --mention string     Filter by mention
  -m, --milestone number   Filter by milestone number or `title`
  -s, --state string       Filter by state: {open|closed|all} (default "open")
  -w, --web                Open the browser to list the issue(s)

You can already overwrite defaults of commands using environment variables (see https://timvink.github.io/doing-cli/reference/config_file/), would make sense to also allow for setting these env vars in the config file, for full flexibility.

So far implemented
  -a, --assignee string    Filter by assignee
  -A, --author string      Filter by author
  -l, --label strings      Filter by labels

Will not implement:

 -L, --limit int          Maximum number of issues to fetch (default 30) - You cannot set any limits in the work item query language source.
-m, --milestone number   Filter by milestone number or title. I will have to use a range of successive queries to do this. Too much work for what's probably an edge case

To do:
  -s, --state string       Filter by state: {open|closed|all} (default "open")
  -w, --web                Open the browser to list the issue(s)

authors: operte timvink

repo: timvink/doing-cli


text:
Compilation error when compiling .tsx with generics.

Hi, I think I found a bug, but it might be just misconfiguration.
I'm trying to use parcel with this plugin to bundle a Surplus.js app written in Typescript.
The problem can be reproduced with this tsx file:
import * as Surplus from "surplus";
let a: Array<number> = [1, 2, 3];

The error I get when trying to run parcel on this project:
project_path>yarn parcel build src/index.html
yarn run v1.7.0
$ project_path/node_modules/.bin/parcel build src/index.html
×  project_path/src/main.tsx: element missing close tag at line 1 col 12: ``<number> = [1, 2, 3];''
    at ERR (project_path/node_modules/surplus/compiler/index.js:374:15)
    at jsxElement (project_path/node_modules/surplus/compiler/index.js:165:17)
    at program (project_path/node_modules/surplus/compiler/index.js:92:31)
    at parse (project_path/node_modules/surplus/compiler/index.js:84:12)
    at Object.compile (project_path/node_modules/surplus/compiler/index.js:1540:45)
    at TSAsset.pretransform (project_path/node_modules/parcel-plugin-surplus/lib/surplus-asset.js:20:39)
    at TSAsset.process (project_path/node_modules/parcel-bundler/src/Asset.js:202:18)
    at <anonymous>
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

This seems like the tsx source is ran through the surplus compiler before being compiled by the ts compiler, and the surplus compiler thinking this is a JSX starting tag.
Do you think this is a bug, and if it is, can it be fixed?

Hi @Sh4rK! it's true, i'm going to do some tests about running surplus after ts using "jsx": "preserve" thanks for reporting this

Cool, thanks!

Hi @Sh4rK, can you try the new version?

sorry i forgot, you need to add a configuration in your tsconfig.json
https://github.com/tinchoz49/parcel-plugin-surplus#for-typescript-users

It seems to work great, thanks for the really quick fix! :)

(It's funny that fixing this was actually removing the TS specific parts :) )

haha yes, it's true. The issue is that parcel first runs TS and then runs the result with the JS asset. I didn't know that, so basically I was compiling surplus twice.
The other issue was that surplus only compiles JS so it's necessary to compile the TypeScript code first and then runs the Surplus compiler.
Thanks for reporting it!


text:
"bundle": cannot run executable found relative to current directory

We're running in Azure DevOps Pipelines and since the weekend we're seeing this:
Digest: sha256:6b25824a73b30594742ce66e987893f775583ae20bf24e43858d3dda7c893001
Status: Downloaded newer image for tingle/dependabot-azure-devops@sha256:6b25824a73b30594742ce66e987893f775583ae20bf24e43858d3dda7c893001
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "bundle": cannot run executable found relative to current directory: unknown.

We haven't updated the version in the recent weeks, so I'm somewhat confused why it started to break.
Have you seen this before?

I had the same issue, I was still on version 0.9. I updated to 0.14.1 and that error disappeared but I got the error TF401027: You need the Git 'GenericContribute' permission to perform this action.
I added Contribute permission to the build service and then it worked.

Could either of you provide a public repro of this?

@mburumaxwell https://github.com/hollowdrutt/dependabot-azure-devops-error-repro
2023-02-24T09:46:56.4990380Z 6b7bfb231103: Pull complete
2023-02-24T09:46:56.5038420Z Digest: sha256:6b25824a73b30594742ce66e987893f775583ae20bf24e43858d3dda7c893001
2023-02-24T09:46:56.5052786Z Status: Downloaded newer image for tingle/dependabot-azure-devops:0.9.0
2023-02-24T09:46:56.9051863Z docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "bundle": cannot run executable found relative to current directory: unknown.
2023-02-24T09:46:56.9150569Z ##[error]The process '/usr/bin/docker' failed with exit code 125
2023-02-24T09:46:56.9186443Z ##[section]Finishing: dependabot

I tried with different versions in another pipeline, 0.10.0 did not produce the error.

Is there a particular reason you're using version 0.9.0? Can you updated to the latest (0.15.0).
The 0.9.0 image hasn't been updated since almost 6 months ago. See https://hub.docker.com/layers/tingle/dependabot-azure-devops/0.9.0/images/sha256-6b25824a73b30594742ce66e987893f775583ae20bf24e43858d3dda7c893001
However, the extension has been updated and using different major/minor version between docker image and the extension may bring issues and isn't supported. If you have to use the older version then you have to fix the task version too. I haven't tried this for very old version but it should be something like - task: dependabot@1.9.0 in your case

I have already updated to 0.14.1 which solved that error for me.

I've been running 1.12.1, iirc and had the same issue.
On Fri, 24 Feb 2023, 13:06 hollowdrutt, @.***> wrote:

I have already updated to 0.14.1 which solved that error for me.
—
Reply to this email directly, view it on GitHub
https://github.com/tinglesoftware/dependabot-azure-devops/issues/519#issuecomment-1443595989,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADI7HJJWADLEWKU3UWOSC3WZCP6BANCNFSM6AAAAAAVEJK6QY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Or 0.12.1.
On Fri, 24 Feb 2023, 13:36 Willi Schönborn, @.***> wrote:

I've been running 1.12.1, iirc and had the same issue.
On Fri, 24 Feb 2023, 13:06 hollowdrutt, @.***> wrote:

I have already updated to 0.14.1 which solved that error for me.
—
Reply to this email directly, view it on GitHub
https://github.com/tinglesoftware/dependabot-azure-devops/issues/519#issuecomment-1443595989,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADI7HJJWADLEWKU3UWOSC3WZCP6BANCNFSM6AAAAAAVEJK6QY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Is there a reason to use the particular version and not the latest? Have you tried not specifying the version and letting the extension select it?

With the docker container you can use the latest tag or just the major version or the major na d minor combined. Either of the following should get you a more recent version:

ghcr.io/tinglesoftware/dependabot-updater:latest
ghcr.io/tinglesoftware/dependabot-updater:0
ghcr.io/tinglesoftware/dependabot-updater:0.15

Still I'd like to know the reason(s) behind not using the latest version.

The reason for us is that we can't/won't/shouldn't give a third party tool
direct access to our source code without reviewing the tool first.
Not to mention breaking changes in the recent versions.
On Fri, 24 Feb 2023, 14:32 Maxwell Weru, @.***> wrote:

With the docker container you can use the latest tag or just the major
version or the major na d minor combined. Either of the following should
get you a more recent version:

ghcr.io/tinglesoftware/dependabot-updater:latest
ghcr.io/tinglesoftware/dependabot-updater:0
ghcr.io/tinglesoftware/dependabot-updater:0.15

Still I'd like to know the reason(s) behind not using the latest version.
—
Reply to this email directly, view it on GitHub
https://github.com/tinglesoftware/dependabot-azure-devops/issues/519#issuecomment-1443687479,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADI7HOU4OGDP5LGPXQIZTLWZCZ6TANCNFSM6AAAAAAVEJK6QY
.
You are receiving this because you authored the thread.Message ID:
@.***>

@whiskeysierra The code base is open, what makes you feel that you're giving 3rd party access? I don't understand the difference in giving access here between versions.
Breaking changes are inevitable, the code has to evolve to support more scenarios. If your don't like that, you could fork an earlier version and you wouldn't have to give anyone access. On that I can't help you.

The code base is open, what makes you feel that you're giving 3rd party access? I don't understand the difference in giving access here between versions.

Projects being taken over by malicious actors isn't unheard of.
Could be just a contributor sneaking in a backdoor, or someone taking over the dockerhub repository.
By just using latest, I'm prone to all of those attacks.

Breaking changes are inevitable, the code has to evolve to support more scenarios.

Absolutely, I understand. It's just another reason why I'm not comfortable with latest, because if a breaking change comes, it will break all of our pipelines.
An old version may not have the latest features, but it should run indefinitely (or so I thought, until I opened this issue).

I understand your reasoning. Unfortunately, I cannot help you with this, too many restrictions and hoops to jump. I will close the issue. If anything changes, you can reopen.

authors: hollowdrutt mburumaxwell whiskeysierra

repo: tinglesoftware/dependabot-azure-devops


text:
Reduce contacts weight

Is your feature request related to a problem? Please describe.
When I create new chat, app always request contacts permission. create group need members in contacts
Describe the solution you'd like

move contacts in new tab
search by user or group name
create group by search user/history chat

Would you like to send a pull request?

maybe, I can try

authors: Modificator or-else

repo: tinode/tindroid


text:
Refactor StefanMaxwellDiffusion class

This issue must be completed prior to refactoring the reaction diffusion model #17
StefanMaxwellDiffusion should inherit from BaseModel so that it is a complete model in its own right. It will contain a dictionary with the set of equations in the electrolyte implemented in symbolic form employing the expression tree.
Will looks something like:
class StefanMaxwellDiffusion(BaseModel):
        def __init__(self):
            self._rhs = {"c": "epression"}
            self._initial_conditions = .... etc

Yep looks good - the keys and variables of _rhs, etc should be Symbols though:
class StefanMaxwellDiffusion(BaseModel):
        def __init__(self):
            c = Variable("c", domain=["whole cell"]
            N = ...
            expression = ...
            self._rhs = {c: expression}
            self._initial_conditions = {c: ...}
            self._boundary_conditions = {N: (left bc, right bc)}
            self._variables = {"c": c, "N": N}

I am unsure what tests are appropriate to run on this class.
I have push what I have done so far if anyone wants to take a look/take over

Cheers Scott, looking good. Very basic tests could be just making sure that model = pybamm.ReactionDiffusionModel() doesn't throw any errors (e.g. with G = Scalar(1)), then seeing if you can process the model with appropriate parameters and discretisation, and finally something along the lines of the functions currently in test_reaction_diffusion.py to make sure that the input/output has the right shape and the model behaves physically as expected

repo: tinosulzer/PyBaMM


text:
Track pointer provenance in load/store through ALU

Previously load/store could be incorrectly rendered into ld.global/st.global when the input was an ALU op that performed an address computation with DEFINE_LOCAL on one of the arguments.
This would result in a GPU crash (unfortunately ptxas would silently compile this into a SASS kernel but the address would be a shared memory address). These kernels would be created during beam search for llama example and as such PTX=1 run would crash.

Example or previously incorrect code; note that store argument is an ALU op that uses a local to compute the final address:
	mul.lo.s32	%alu_s32_32, %lidx0, %const_s32_9;
	mov.b32		%const_s32_33, 0;
	cvt.u64.s32	%cast_u64_16, %alu_s32_32;
	add.u64		%alu_u64_16, %local_u64_0, %cast_u64_16;
	st.global.f32	[%alu_u64_16+0], %alu_f32_31;

Btw the code in ptr_ar makes me think the intent was to never get IR corresponding to loop index based addressing, maybe the arg isn't cleanly set up and this is more correct to handle elsewhere. Let me know if that's the case and I can debug further.

Can you add a test that would have failed before?

I didn't find existing tests that tested the assembly output so wasn't sure - do you mean a test that just checks the lowering, or a full end-to-end test that would have crashed with PTX=1 before?

Alright I've added tests that exercise the local addressing via a non-constant offset which is what triggered the issue in the first place, HOWEVER these tests alone would not trigger the problem (they still feel like they are important to have...).
This is because the core issue was not that the IR that was fed into the assembler used LOAD on a computed address, but that the IR - best as I can tell - was fed into the assembler twice during beam search (maybe with some alterations?). The first run would modify the LOAD instructions in place (in ptr_ar) and replace the address, that was originally DEFINE_LOCAL, with an ALU computation. It would also correctly assign .shared address space. However, the second run on the same graph would overwrite the address space with .global as the address was replaced by ALU.
I've adjusted the workaround to be simpler accordingly: don't change .arg if it's already assigned (but validate that the caller didn't pass something non-sensical). This still fixes the problem that came up in context of beam search. To actually exercise the problem in tests we'd need to run the code in local tests through the assembler twice, the tests don't do that atm

Sweet! Simple change

authors: geohot zeux

repo: tinygrad/tinygrad


text:
Documentation

Need to update the README file to keep it current with package features and document how to best utilize it in a Laravel project.

The README for this package should be updated to include references to the full documentation for the package at https://docs.tipoff.com as outlined in this issue:

https://github.com/tipoff/docs/issues/5

Moving this to issue #1 so the issue number is the same as all the other packages.

repo: tipoff/reviews


text:
Issue setting cache driver to redis

Hi,
We are debugging an issue with the fetching job getting terminated, and when trying to look at the cache value for the mutex (from code) it is always null, however it does not start a new job until the FETCH_MAX_EXECUTION_TIME times out. So there is something weird going on there.
We decided to try to use redis cache instead of file cache, so that it would become possible to actually inspect the cache properly. But setting these environment variables does not do anything:
CACHE_DRIVER=redis
REDIS_HOST=tls://RESOURCE_NAME.redis.cache.windows.net
REDIS_PASSWORD=password
REDIS_PORT=6380

Is this not supported out of the box? Any hints to what we would have to do? Or is this the wrong place to ask?

Hi this would make sense in the upstream Freescout repository to the developers. Theoretically this should work, and would probably increase performance as well with being able to change session, cache and others to redis. If you do manage to get it working I can build it into this Docker image with easily controllable env vars for others to benefit.

authors: borgarlie tiredofit

repo: tiredofit/docker-freescout


text:
🛑 FormularService Hannover is down

In 6e66533, FormularService Hannover (https://forms.hannover-stadt.de/intelliform/forms/lhh_ozg/index) was down:

HTTP code: 0
Response time: 0 ms

Resolved: FormularService Hannover is back up in a396503 after 2 minutes.


text:
Introduce method to get driver hosts to be ignored by VCR, WebMock

Consider adding a method to webdrivers to return all of the driver hosts that ought to be ignored by testing tools like VCR and WebMock.
This would simplify the supporting config as follows:
VCR.configure do |config|
  config.ignore_hosts(
-    "chromedriver.storage.googleapis.com",
-    "github.com/mozilla/geckodriver/releases",
-    "selenium-release.storage.googleapis.com",
-    "developer.microsoft.com/en-us/microsoft-edge/tools/webdriver"
+    *Webdrivers.driver_hosts
  )
end

-WebMock.disable_net_connect!(allow_localhost: true, allow: [
-  "https://chromedriver.storage.googleapis.com",
-  "https://github.com/mozilla/geckodriver/releases",
-  "https://selenium-release.storage.googleapis.com",
-  "https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver"
-])
+WebMock.disable_net_connect!(allow_localhost: true, allow: Webdrivers.driver_hosts)

This code was modified from the code provided at https://github.com/titusfortner/webdrivers/wiki/Using-with-VCR-or-WebMock

Well, they aren' t currently public methods, but you could:
Webdrivers::Chromedriver.send(:base_url)

Especially now that you can require only the drivers you want to use, I'm not sure it makes sense for the project to roll this up into a single method...

Thanks thats interesting. So you can get all of the base_urls with:
# With activesupport gem
driver_urls = Webdrivers::Common.subclasses.map { |driver| driver.send(:base_url) }

# Without activesupport
driver_urls = (ObjectSpace.each_object(Webdrivers::Common.singleton_class).to_a - [Webdrivers::Common]).map { |driver| driver.send(:base_url) }

Which reduces the config a little to:
VCR.configure { |config| config.ignore_hosts(*driver_urls) }

WebMock.disable_net_connect!(allow_localhost: true, allow: driver_urls)

Ok, I just merged in code that will make #base_url public so that you don't have to use #send, I think that's all the support I want to provide for this in webdrivers gem at this time.

Thanks @titusfortner!
Here's some code using the newly-public methods for anyone who stumbles on this issue and wants to know how to use them with VCR and WebMock:
# With activesupport gem
driver_urls = Webdrivers::Common.subclasses.map(&:base_url)

# Without activesupport gem
driver_urls = (ObjectSpace.each_object(Webdrivers::Common.singleton_class).to_a - [Webdrivers::Common]).map(&:base_url)

VCR.configure { |config| config.ignore_hosts(*driver_urls) }
WebMock.disable_net_connect!(allow_localhost: true, allow: driver_urls)

(I tried updating the wiki page but it looks like its not open for public edits.)

Hi @eliotsykes, I have updated the wiki with the information you have provided - https://github.com/titusfortner/webdrivers/wiki/Using-with-VCR-or-WebMock
Let me know if anything can be improved. Thanks!

This is now available in 3.9.4

Also, ftr, I changed the wiki so that anyone can add to it.

Hey folks, I’ve tried this but it didn’t work. base_url was giving me full URLs (like https://chromedriver.storage.googleapis.com) which was not allowing the requests.
However, extracting just the host made it work:
driver_urls = Webdrivers::Common.subclasses.map do |driver|
  Addressable::URI.parse(driver.base_url).host
end

@gnclmorais When I try and use :selenium I get an error because AWS is involved, so I had to do this:
driver_urls = Webdrivers::Common.subclasses.map do |driver|
  Addressable::URI.parse(driver.base_url).host
end << 'github-production-release-asset-2e65be.s3.amazonaws.com'

Feel like github-production-release-asset-2e65be probably isn't static, but, I had to add it because just using s3.amazonaws.com didn't work.

authors: cdmo eliotsykes gnclmorais kapoorlakshya titusfortner

repo: titusfortner/webdrivers


text:
🛑 storage.tjo.space is down

In c10b3ad, storage.tjo.space (https://console.storage.tjo.space) was down:

HTTP code: 0
Response time: 0 ms

Resolved: storage.tjo.space is back up in a869f89.

repo: tjo-space/status


text:
🛑 storage.tjo.space is down

In fbc0d60, storage.tjo.space (https://console.storage.tjo.space) was down:

HTTP code: 0
Response time: 0 ms

Resolved: storage.tjo.space is back up in 76c7d60.


text:
🛑 反代2（tjsky.cf） is down

In cf6fa35, 反代2（tjsky.cf） (https://api-pikpak.tjsky.cf/https://1.1.1.1/cdn-cgi/trace) was down:

HTTP code: 429
Response time: 268 ms

Resolved: 反代2（tjsky.cf） is back up in 3dcb730.

repo: tjsky/upptime


text:
🛑 SITE_TOK is down

In 35ce941, SITE_TOK ($SITE_TOK) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SITE_TOK is back up in 8bd0016.

站点维护


text:
Fix typo in react gzip size badge

What:

Why:

How:

Checklist:

[ ] Documentation
[ ] Tests
[ ] Code complete

Codecov Report

Merging #230 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #230   +/-   ##
=======================================
  Coverage   90.31%   90.31%
=======================================
  Files          20       20
  Lines         971      971
  Branches      263      263
=======================================
  Hits          877      877
  Misses         76       76
  Partials       18       18

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 31f5087...3e5b4ef. Read the comment docs.

authors: codecov-io mitchellhamilton


text:
Remove profiles from non root packages

Fixes:
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   rftrace/examples/hermitrust/Cargo.toml
workspace: rftrace/Cargo.toml

The profiles are there intentionally (even if not well documented currently), so that if you copy the example outside of the workspace it still works in debug mode.
default:
	# we need to override the opt level for the dev profile, since we are in a workspace with other settings!
	# not needed if this folder stands on its own, since the profiles in the cargo.toml take effect
	# BUT: we build in release anyway so trace is smaller.
CARGO_PROFILE_DEV_OPT_LEVEL=1 cargo build ....

All right. :+1:

Reopening, since this is not required on Hermit since November 2021: https://github.com/hermit-os/hermit-rs/commit/f05547197b4e8d18274595302e6ddc6f33bbd13e

Rebased on latest master.

authors: mkroening tlambertz

repo: tlambertz/rftrace


text:
List is Unmaintained

This author does not appear to be maintaining this list.
I would like to offer my fork as an actively maintained list.
https://github.com/masrly/awesome-mastodon
If someone knows of a better fork to use, I am open to it.

Interesting thought. I will look into that.

I've seen some contributions from @tleb on other repos...
IMHO: Would be interesting to help @tleb maintain this Awesome list (600+ stars) rather than changing to as 2-star fork.
Do you need help, @tleb ?

Hi, author here. I still believe a list such as this one can be useful. I'm unsure about how to handle it. A few thoughts:

I wouldn't mind spending some time on it, but help is appreciated. Knowing that I will have to check each submission and make a judgment that people kind-of trust is what makes me rather leave it stall. That kind of help can be from anyone: just go through pull requests and give your opinion. Is the project/link useful? Is the patch done well? etc.
I would rather the list be awesome-activitypub than awesome-mastodon. That promotes the protocol ecosystem, which is what really matters. Mastodon-specific stuff would become a subsection (or multiple). That could be an overall trend, to allow for renaming later on. First step would be to rename sections and fix descriptions so that they mention "Mastodon" for Mastodon-specific projects. Then make sure general ActivityPub links are present (spec, good first-timer text article, etc.). Then rename the list. Please don't hesitate to send patches in that direction.
I don't want it to become an append-only list. Submissions have to be truly challenged, and it should be fine to remove a link from the list. Please don't hesitate to make patches in that direction.
I don't feel like this list is mine, it should probably belong in an organisation namespace.
Ideally I wouldn't be needed anymore, but I don't know who could be given moderator rights. I think the first point about having people simply giving their opinion is a good way to have people show their involvement interest.

I'd also like to thank you guys for not assuming I have any obligations towards this list. I was afraid of that when seeing the title. I'd be down to spending some time on this list to keep it in shape, again having as long-term vision the whole ActivityPub ecosystem and not only Mastodon. Organic help through opinions and discussions on pull requests would be really appreciated.
Have a good day!

I forked it too at https://github.com/hueyy/awesome-mastodon and made some updates before I noticed this issue. Definitely agree there should be an actively maintained version of this list somewhere. Happy to send in a PR to @indiealexh's, but maybe we should create an organisation and give the current participants merge access.

+1 for maintained list!

I wouldn't mind spending some time on it, but help is appreciated. Knowing that I will have to check each submission and make a judgment that people kind-of trust is what makes me rather leave it stall. That kind of help can be from anyone: just go through pull requests and give your opinion. Is the project/link useful? Is the patch done well? etc.

Come on, it's just a list! Don't stress about it. Just add all things related to Mastodon. That's my 2 cents.

I would rather the list be awesome-activitypub than awesome-mastodon. That promotes the protocol ecosystem, which is what really matters. Mastodon-specific stuff would become a subsection (or multiple). That could be an overall trend, to allow for renaming later on. First step would be to rename sections and fix descriptions so that they mention "Mastodon" for Mastodon-specific projects. Then make sure general ActivityPub links are present (spec, good first-timer text article, etc.). Then rename the list. Please don't hesitate to send patches in that direction.

Create another list for that purpose? These are not mutually exlusive.

I don't want it to become an append-only list. Submissions have to be truly challenged, and it should be fine to remove a link from the list. Please don't hesitate to make patches in that direction.

Also at the same time submissions should not be stuck in the request queue. You should apply them with a low bar. They can be later removed.

I don't feel like this list is mine, it should probably belong in an organisation namespace.

This does not matter. Even though it's under your name, who cares and why should one care? The list is all that matters.

Ideally I wouldn't be needed anymore, but I don't know who could be given moderator rights. I think the first point about having people simply giving their opinion is a good way to have people show their involvement interest.

If you're available, that's good. If not, then start looking for maintainers.
These are just my two cents. Sorry if the frustration leaks through my opinions but I've seen too many times that maintainer loses interest for wrong reasons. Releasing something light as a list for god's sake as open source should be simplest thing to do. It shouldn't be stuck in meta discussion and creating endless forks because of that. Heck, I could create a maintained fork as well. But let's see this through first. There's 15 PRs, check & merge those first and let's continue from there?

Hi, maintainer of awesome-activitypub (albeit quite poorly maintained) here. And I think this list serves a different purpose and a list focused on Mastodon is pretty valuable imo.
Awesome lists are meant to be a 'curated' list, and the idea of listing up-to-date and quality items is great but I also don't think that means inspecting every single corner of the project. Usually GH stars and commit history give enough context to whether the project is recognized by the community. Maybe look into source code, or community sentiment, sure but it isn't mandatory.

Happy to help maintain this list.

sindresorhus/awesome now recognizes hyperupcall/awesome-mastodon as the awesome list for mastodon. See related discussions:

https://github.com/sindresorhus/awesome/pull/2739
https://github.com/hueyy/awesome-mastodon/issues/45

authors: BasixKOR gcruchon hueyy hyperupcall indiealexh ronilaukkarinen shamiv tleb

repo: tleb/awesome-mastodon


text:
App listening only on IPv6, not IPv4

I've completed the installation on a VPS with a clean Debian 10 OS install.  I chose #1 on the Invidious-Updater installation prompt for a clean install, without any customization.  In my terminal, I see that both the Invidious and PostgreSQL services are running without issue--but when I navigate to my VPS' IP in my browser, the application does not come up.
I ran netstat, and found that my app is only listening on IPv6, and not on IPv4 (screenshot attached).  Any guidance to get it to listen on IPv4?  I appreciate the help!

Hello,
try sudo -i -u invidious nano /home/invidious/invidious/config/config.yml then add force_resolve: ipv4 on a new line.

Hello,
try sudo -i -u invidious nano /home/invidious/invidious/config/config.yml then add force_resolve: ipv4 on a new line.

Hi @tmiland --thanks for helping troubleshoot!  I've added this line (please see attached) and restarted both the VPS and the service itself, but it still doesn't seem to be listening on IPv4--the netstat results are the same.
Do you have any other ideas?  Thanks again for the help!

Hi @tmiland --thanks for helping troubleshoot!  I've added this line (please see attached) and restarted both the VPS and the service itself, but it still doesn't seem to be listening on IPv4--the netstat results are the same.
Do you have any other ideas?  Thanks again for the help!

Hi,
i assume you have port 3000 forwarded in your firewall?
Also try to add:
port: 3000
And:
host_binding: xx.xx.xx.xx where xx.xx.xx.xx is your local IP.
Then it should be accessible at http://your_public_ip:3000
If this still fails, then use option 7 to uninstall, and set it up again with advanced options.

Hi,
i assume you have port 3000 forwarded in your firewall?
Also try to add:
port: 3000
And:
host_binding: xx.xx.xx.xx where xx.xx.xx.xx is your local IP.
Then it should be accessible at http://your_public_ip:3000
If this still fails, then use option 7 to uninstall, and set it up again with advanced options.

Feel free to re-open if this is still an issue.

Feel free to re-open if this is still an issue.

Hi @tmiland --thanks for the help!  I wasn't able to resolve this, so I've retried with a few different OSes on my VPS.  I currently have Deployed Invidious with Docker on Fedora 33 x64.  Both the service and database are up and running, according to the script--but again, I'm having trouble finding it through the browser.  Should it just be http://my.vps.ip.address:3000 ?
Thanks again!

Hi @tmiland --thanks for the help!  I wasn't able to resolve this, so I've retried with a few different OSes on my VPS.  I currently have Deployed Invidious with Docker on Fedora 33 x64.  Both the service and database are up and running, according to the script--but again, I'm having trouble finding it through the browser.  Should it just be http://my.vps.ip.address:3000 ?
Thanks again!

Hi again, my pleasure. :smile:
yes, it should be, if you have the port open in your firewall and the port forwarded correctly in Docker.

Hi @tmiland -- thanks!  I believe I have a) the correct port assigned in Docker, and b) that port mapped correctly, according to netstat (screenshots attached).  Does anything seem out of the ordinary to you?  Again, I really appreciate all of your help.

Hello again,
looks correct.
Now the only question remaining; are the port opened in your firewall?

Here are my current rules, according to iptables--don't think anything should be blocked?

Hmm,
try this: firewall-cmd --permanent --add-port 3000/tcp then systemctl restart firewalld and see if that helps.
From Opening a port - Using firewalld on Fedora

Hi @tmiland --hmm, still seems to be failing.  I'll play around with this and try to figure something out.  Looking forward to continuing to use and suport the project!!

authors: eave tmiland

repo: tmiland/Invidious-Updater


text:
🛑 Homepage is down

In 23c0784, Homepage (https://hcmus.edu.vn/) was down:

HTTP code: 500
Response time: 1350 ms

Resolved: Homepage is back up in 363d854.

repo: tmkhiem/hcmus-web-uptime


text:
🛑 Portal 1 is down

In ca10a65, Portal 1 (https://portal1.hcmus.edu.vn/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Portal 1 is back up in d61a956 after 27 minutes.


text:
add timeout configuration option

This PR adds a :timeout option that can be passed to Pygments.highlight. I also added a bit of a hacky unit test for the new functionality. The other unit test for testing timeouts is similarly presumptive (about how long/short a given machine is likely to take to highlight a block of code), but let me know if you would prefer another approach.
/cc @tnm

@gfx This is a pretty good idea that we should've merged back when. No need for the env var.

The :timeout param was copied to the Py3 support here https://github.com/tmm1/pygments.rb/pull/194

authors: ivanistheone ptoomey3 tnm


text:
Web - Make breadcrumbs responsive

Ensured breadcrumbs hold up at 320 by just stacking them
Removed unnecessary aria-label on one of the links while under the hood

@silverli Thanks so much! Good catch on the breakpoint. Fixed :) Ready for review!


text:
HTML

HTML
User Story
As a bootcamp student I want the prework notes to be structured on a webpage so that I can easily find and read information.
Acceptance Criteria
GIVEN a prework study guide website WHEN I visit the website in my browser THEN I see four boxes titled HTML, CSS, Git and Javascript with associated notes below.

Finished after some annoying errors and whatnot.


text:
Conditional creation of directories

Is there a way to conditionally create a directory, based on a parameter? For example:
.
├── project.json
└── template
    └── LICENSE
    ├── README.md
    └── {{if eq ConditionalDir "conditional"}}

With a project.json of:
{
    "ConditionalDir": false
}

This of course wouldn't work, being an invalid template, but is there a way? I have a Go package I often don't want to include.

In addition to this question, I am also very interested in conditionally creating files ... ;-)

authors: iancmcc stefanwalther

repo: tmrts/boilr


text:
Bad TOML data

I'm getting an error using the application, I suspect a schema change upstream. I get:
Error: Bad TOML data

Caused by:
    invalid type: string "celsius,kmh", expected struct Units for key `units` at line 1 column 9

Hey @Laura7089
Confy provides a nice indicator in its errors message what is wrong here.
The config changed some versions ago.
As some more configurable units were added the specifications are now key value pairs per unit in a units table.
The example from the Readme:
[units]
temperature = 'celsius' # Temperature units: 'celsius' | 'fahrenheit'
speed = 'kmh' # (Wind)speed units: 'kmh' | 'mph' | 'knots' | 'ms'
time = 'military' # Time Format: 'military' | 'ap_pm'
precipitation = 'mm' # Precipitation units 'mm' | 'inch'

when I am trying to run the wthrr in windows it gives me the below message.
Error: Bad TOML data
Caused by:
invalid type: string "celsius,kmh", expected struct Units for key units at line 2 column 9
I can not find the location of wthrr.toml file so that I can delete or edit file. It is much easier to locate the file in Linux. It will be nice if error message can produce the location of toml file.

I have started to put down the groundwork to extend the config file for coming features and rework it so that such errors are handled more nicely.
Until then - and to give some first aid -: Which OS are you using?

Windows 10

Could you check your  C:\Users\<Username>\AppData\Roaming\ for the config file, this is the default config directory under windows.
You might need to enable hidden files to be able to see it.

Yes i found it.
It is under Appdata\roaming\weathwrcrab\config folder.
Filename : wthrr.toml
deleting the file resolved the issue.

repo: tobealive/wthrr-the-weathercrab


text:
Custom worker arguments

Allow users to pass custom arguments to workers. Not 100% sure about the api yet, but could work by passing an optional block after the schedule DSL.
I sort of feel like the "forced" last_occurrence and next_occurrence arguments are actually a bit dirty.
Thinking of something in this direction:
recurrence do
  daily.hour_of_day(12) do
    # Return Array of worker arguments ...
  end
end

This should be a lot simpler to implement once #31 is done.

+1

This would be a worthwhile feature. I'll look at extending it soon.

Struggling with this issue at the moment. Does anyone have ideas for workarounds while this issue is worked on? Submitting three of my own params into perform method and the last/next occurrence args aren't allowing for that to be possible.

authors: alexrusenhack srcnix srekhi tobiassvn

repo: tobiassvn/sidetiq


text:
Filter with null value in cell can't be reset

Not sure if this is an issue of aurelia-talbe:
I have a filter for a column with some null values.
I'm able to init the filter with null to see all entries but after I typed something in the filter input and removed it again the filter is set to an empty string.
This results in not showing all rows having null in this column.

Yes, I think it's an issue, I faced out the same error.
When you init the filter value to null, au-table doesn't filter the row, so you will see all the entries.
And every time you programmatically reset the filter value to null, you will see all the entries.
But when you bind a filter value to an html input value, things go in a different way, because Aurelia.io framework accepts to change a model value to an empty string '' from null in the case that a user enters a value and then subsequently backs out that value.
This behaviour is explained in the Aurelia.io framework issue #288 and #308, and they suggest to use a NullToEmptyStringValueConverter.
I report here the cause (from #288 and #308):
The primary issue is the input element's value property only stores strings. The element converts null/undefined to empty string.
This behaviour is caused by html elements not supporting null values, the value is altered to empty-string. Aurelia supports this in its binding processing. When changing a model property from "some text" to null, this triggers:
1: Aurelia binding ValueAttributeObserver coerces null newValue to empty-string
2: Value detects element.value not equal newValue, so updates the element with newValue and calls notify
3: Notify calls element value subscribers with coerced empty-string
4: The Binding subscriber compares newValue empty-string with evaluated source expression which is still null ...
5: and so updates source model with newValue empty-string.

repo: tochoromero/aurelia-table


text:
Shouldn't every command support output streaming?

I know at least 'provision' would be nearly as valuable to stream as 'up', but also things like long-running SSH commands would also be really nice to get a stream from.
I may look into adding this myself and sending you a PR, just wondering what your thoughts were on it. Any specific reason that only 'up' supports this output mechanism right now?

Well, technically both up and reload support output streaming, thanks to PR#56, but I see what you mean: any other command that invokes _call_vagrant_command could theoretically support _stream_vagrant_command.  If you would like to submit a PR to add streaming to other commands, like provision, I would be happy to merge it.
Adding streaming does change the return type of the command and add complexity to the code, so it might not be worth adding it to every compatible command until there is a need.  Anyway, I'm open to the idea.
It is also possible to stream output to a filehandle, using the out_cm parameter of the constructor, which works for some people's needs.
Cheers,
Todd

authors: inequity todddeluca

repo: todddeluca/python-vagrant