displaying transcript isoform-specific annotations

Now that we have a few real live "alternative" transcripts annotated, we ought to think about what the web (gene, publication, etc.) pages should do with annotations to them.
There are already examples where the transcripts have different annotated:

product descriptions (e.g. wtf4)
GO annotations (e.g. wtf13)
expression (e.g. tco1)
phenotype extensions (tco1 in sre1 phenotype)

At this point I'm mainly opening this for discussion and so it won't fall off the radar; I don't have well-formed ideas about what we should actually do. them. I've opened a Canto ticket for making isoform-specific annotations, ~Will we also need~ and a Chado ticket.

One aspect of the current behavior that we won't want long-term: it appears to be arbitrarily taking the product description for the longest transcript, and not using the other(s) at all (e.g. wtf4, tco1).

OK let's kick off with the product
We could duplicate the  header section for each transcript since the information for each will be different:

I don't have any good ideas for the annotation.
At the moment I'm thinking that  we default to  one and toggle over to an identical display for the other isoforms.

Here is my first idea as a starting point:

We could duplicate the header section for each transcript since the information for each will be different:

I think it would confuse things if we used the transcript Systematic ID in the header instead of the gene ID.
Perhaps we could split the header into two, one for gene stuff and a for information that can change per transcript:

transcript ID
location
weight

Here is my first idea as a starting point:

Do we have transcript specific annotation?  Maybe a filter on the annotation table would be OK?

Do we have transcript specific annotation?

A little bit, yes, mostly for some of the wtfs so far.

Maybe a filter on the annotation table would be OK?

I'd be willing to give it a try.

Perhaps we could split the header into two, one for gene stuff and a for information that can change per transcript:

I've made a mock-up which I think would be OK for a gene with couple of transcripts but we'd need something cleverer for genes with lots of transcripts (will those be a thing?).  Perhaps for many-transcript genes, a table would make sense with columns like "ID", "translation start", "UTR end" and "product size"?
Anyway:

Perhaps for many-transcript genes, a table would make sense

Mock-up:

I've made a mock-up which I think would be OK for a gene with couple of transcripts

That looks good.

genes with lots of transcripts (will those be a thing?)

I don't know. The most I've tried curating so far is 3, iirc.

... for many-transcript genes, a table ... mock-up

That looks good, but it also looks partly redundant with the Transcript section. Do we need a re-think about which details go in which section?
Also, would there be a table in every gene page header, or only for genes with more than X transcripts (for whatever value of X)? In the latter case, will inconsistency bother users?
Am I overthinking this?

I think above 4 will be very rare. We won't often annotate multiple transcripts , but 2 will be most common i.e. vegetative/meiotic  which are often very different lengths.

I think the redundancy is OK, it is only start and end that is repeated and that is really summary info. The 'transcript section' is more about "transcript structure.

I would be happy for this to only appear if multiple transcripts are annotated

we would still need to decide  how to represent products (and link to their respective transcript IDs)

Yep, I was thinking we'd only show a transcript table (or whatever) if there are multiple transcripts.  Although in the single transcript case we could put "This gene has one curated transcript" where the table would be, just for clarity.

I think the redundancy is OK, it is only start and end that is repeated

I don't understand this bit.  Can't each transcript potentially have different starts and ends?

I think the redundancy is OK, it is only start and end that is repeated

not clear sorry. I was saying that there isn't a total overlap between the "alternative transcript table" in the summary, and the transcript section. It's slightly redundant, but the only data that is in both sections is transcript  coordinates.

Ah, right.  Got it now.
Another option is to have less information about the transcripts at the top of the page and instead have a link to the Transcripts section:
Note: this gene has 2 annotated transcripts.  [Details...]

then we could collect all the transcript specific stats in one place.

have less information about the transcripts at the top of the page and instead have a link to the Transcripts section

ooh, I like that idea - it would make the top of the page a bit more streamlined

+1

instead have a link to the Transcripts section

I'll do that soon as it will probably help even without any other changes.

instead have a link to the Transcripts section

I've added that but only for multi-transcript genes for now.

I'm not sure but I don't think we necessarily want to display the longest by default. The default transcript and product used should be -1.
So for example tco1
https://www.pombase.org/gene/SPAC17G6.02c
would show the translated transcript.
Perhaps as long as we know there are multiple transcripts the length can be confined to the transcript section?

I've added that but only for multi-transcript genes for now.

This is good. Should we do:
Note: This gene has 2 transcripts [details] and 2 translations
to distinguish which have different products?

Should we do:
Note: This gene has 2 transcripts [details] and 2 translations
to distinguish which have different products?

Yep, that makes sense.  Although at the moment there are always the same number of transcripts and translations.

Although at the moment there are always the same number of transcripts and translations.

Not for tco1 (although there is currently a CDS, there shouldn't be). But that could be resolved by
https://github.com/pombase/pombase-chado/issues/822

We decided to add the product size to the "Transcript details" section.
Also if there are multiple transcripts we will say "Product size (of transcript 1)   123aa, 321 kDa" in the summary at the top of the page.

We decided to add the product size to the "Transcript details" section.
Also if there are multiple transcripts we will say "Product size (of transcript 1) 123aa, 321 kDa" in the summary at the top of the page.

I've done that and added per-transcript product sizes in the "Transcript details" section.
I suspect it will need tweaking when we have multi-transcript genes where only some transcripts are protein coding.

Looking through this issue it seems like there's still quite a bit to do here.  In particular we need to decide how to display transcript specific annotations.  I can't think of a nice way to do that.
I think a table for each transcript and each annotation type would be a mess.  Especially since I'm guessing that a lot of annotation won't be transcript specific so we'd need a table for each transcript and also one for annotations to the gene where the transcript isn't annotated (shared annotation).
We could add yet another filter on the annotation tables, but that seems quite hidden?
Or have an extra column in the annotation table show which transcript(s) or protein(s) the annotation applies to?  That also seems a bit hidden and makes the display busier.

Or have an extra column in the annotation table show which transcript(s) or protein(s) the annotation applies to? That also seems a bit hidden and makes the display busier.

Midori and I had a chat about this about and we think this plan might be OK.  The GO annotation tables aren't that busy and we would only show the extra column when it was needed.
It makes sense to have a new filter on the table too.
Other things to think about, which will need new issues at some point:

how should we record the isoform when making the annotation in Canto?  Would an extra (optional) extension be OK?
need to fix the Chado loading code to handle isoform specific annotation

the annotation is attached to the transcripts in Chado, but currently everything from Canto is attached to the first transcript
the contig loading works OK and it's possible to attach annotation to any transcript

need to handle GO annotation that applies to all transcripts

the straight forward way (in Chado) is to annotate both transcripts in that case
the website code will need to change to cope with this - we don't want to show the same annotation twice

the GO filtering code in the loader needs to cope with annotation on transcripts
the code that exports transcript and protein sequences as fasta needs to change

Thanks - that covers everything I remember.

how should we record the isoform when making the annotation in Canto? Would an extra (optional) extension be OK?

eh, probably

One other thing we talked about was the "Protein features" section of the gene pages, which mostly comes from Pfam and InterPro.
I looked up wtf4 in Pfam and it looks like they have only one isoform: http://pfam.xfam.org/protein/Q9P3V0
InterPro have both:

https://www.ebi.ac.uk/interpro/protein/reviewed/Q9P3V0/?isoform=Q9P3V0-1
https://www.ebi.ac.uk/interpro/protein/reviewed/Q9P3V0/?isoform=Q9P3V0-2

Some of the "Protein features" section is transcript specific so we might need a selector like:

I like this plan.
This ticket isn't very urgent in comparison to other things because there are so few annotated.
prp10 is a useful example of a gene which has multiple transcripts but should collapse because it only has one protein product:


MODMARCMIG-9: Implement Async Data Saving Endpoint for Mapped Records of Marc Migration Operation

Purpose
Implement Async Records Saving Mechanism for Mapped Records of MARC Migration Operation
Approach

Implement Data Saving PUT endpoint
Update Operation Status to DATA_SAVING and return response
Run Async process for saving operation chunks of the mapped records

Changes Checklist

[ ] API Changes: Document any API paths, methods, request or response bodies changed, added, or removed.
[ ] Database Schema Changes: Indicate any database schema changes and their impact. Confirm that migration scripts were created.
[ ] Interface Version Changes: Indicate any changes to interface versions.
[ ] Interface Dependencies: Document added or removed dependencies.
[ ] Permissions: Document any changes to permissions.
[ ] Logging: Confirm that logging is appropriately handled.
[x] Unit Testing: Confirm that changed classes were covered by unit tests.
[x] Integration Testing: Confirm that changed logic was covered by integration tests.
[ ] Manual Testing: Confirm that changes were tested on local or dev environment.
[x] NEWS: Confirm that the NEWS file is updated with relevant information about the changes made in this pull request.

Learning and Resources (if applicable)
MODMARCMIG-9

Could you also test full cycle (mapping+saving) with docker-compose?

Could you also test full cycle (mapping+saving) with docker-compose?

@viacheslavkol , I have updated the description with testing info


Access_accept but did not Console.WriteLink Accepted

Hi.
when Auth but did not console write Accept
also, when Auth fail then write Reject   hope.
Thanks

Do you have code that replicates the issue you are seeing?

my code is  this
using System;
using System.Collections.Generic;
using System.Linq;
using FP.Radius;
using System.Text;
using System.Threading.Tasks;
namespace ClientTest
{
internal class Program
{
private static void Main(string[] args)
{
//if (args.Length != 4)
//{
//	ShowUsage();
//	return;
//}
		Authenticate(args).ContinueWith(task =>
		{
			if (task.IsFaulted)
				Console.WriteLine("Error : " + task.Exception.Message);
		});

	}

	private async static Task Authenticate(string[] args)
	{

		RadiusClient rc = new RadiusClient(args[0], args[1]);
		RadiusPacket authPacket = rc.Authenticate(args[2], args[3]);
        authPacket.SetAttribute(new VendorSpecificAttribute(10135, 1, UTF8Encoding.UTF8.GetBytes("Testing")));
		authPacket.SetAttribute(new VendorSpecificAttribute(10135, 2, new[] { (byte)7 }));
		RadiusPacket receivedPacket = await rc.SendAndReceivePacket(authPacket);

        if (receivedPacket == null) throw new Exception("Can't contact remote radius server !");

        switch (receivedPacket.PacketType)
		{
			case RadiusCode.ACCESS_ACCEPT:
				Console.WriteLine("Accepted");
				foreach (var attr in receivedPacket.Attributes)
					Console.WriteLine(attr.Type.ToString() + " = " + attr.Value);
				break;
			case RadiusCode.ACCESS_CHALLENGE:
				Console.WriteLine("Challenged");
				break;
			default:
				Console.WriteLine("Rejected");
				break;
		}
	}

	private static void ShowUsage()
	{
		Console.WriteLine("Usage : ClientTest.exe hostname sharedsecret username password");
	}
}

}
Windows 7 32bit .net:4.5.1
Thanks

I ran your code which looks to be the same as the sample against our RADIUS server and everything is working as expected.  Make sure you have the proper secret configured or you will not receive a rejected message.  I have identified some things we could do to make it more obvious when the secret is wrong and will be looking into that.

We have the same issue with the example on two different machines. I have Windows 7 Enterprise SP 1 64 bit. I tried to debug, but it fails unexpectedly without any exception.

We found the problem. The example has a bug. The Main() method doesn't wait for finishing the Authenticate() call. It immediately exits and shuts down the worker threads too. There's missing something like:
var authTask=Authenticate(args);
authTask.Wait();
The library itself works correctly.

We just checked in some code that should resolve this issue.  The packet will now be returned regardless if the secret is correct or not.  We also added the .Wait() call to the example so it will not exit without allowing the other threads to finish.


Pd hierarchy

Rebased with PD hierarchy changes.

ill try upstream the pd hierarchy changes to mainline sel4cp soon, there is at least one bug with the change.

We can remove monitor/src/main.c from the commits

Nice, try dropping a7a335aaae5269af8ee92a426e33eda1c804ca99 when you can.


[BUG] Latest plugin version is not available as a docker container

With the release of 1.3.0, would be nice to have it available on https://hub.docker.com/r/opensearchproject/logstash-oss-with-opensearch-output-plugin image as well.

Probably this relates to https://github.com/opensearch-project/logstash-output-opensearch/issues/154

plugins are always a nightmore to track, it would be best to build a new container the with all the plugins you might need...
an example Dockerfile is the following
ARG logstash_version
FROM docker.elastic.co/logstash/logstash:${logstash_version}
RUN bin/logstash-plugin install logstash-filter-translate
RUN bin/logstash-plugin install logstash-input-snmp
RUN bin/logstash-plugin install --version 2.0.0 logstash-output-opensearch

and you can you this to build it
VERSION=8.4.3
REGISTRY=my-registry.com

docker build . --build-arg logstash_version=$VERSION -t $REGISTRY/logstash/logstash-plugin:$VERSION
docker push $REGISTRY/logstash/logstash-plugin:$VERSION

See https://github.com/opensearch-project/logstash-output-opensearch/issues/230.


Nested parameter not rendered when top parameter is optional

[X] I have checked issues with bug label and found no duplicates

Expected Behavior
This snippet should render the nested parameter value correctly in the HTML output:
/**
 * @param options RootParameter
 * @param options.under NestedParameter
 */
export function under(options?: {under: boolean}) {}

More Information
The bug is caused because in strict mode, this snippet get's rendered as an union type of the form { ... } | undefined. It seems typedoc will not render the nested parameters in this case.
This test case fails also even when strict: false:
/**
 * @param options RootParameter
 * @param options.under NestedParameter
 */
export function under(options: {under: boolean} | undefined) {}

Would you accept a PR that cover this cases (I would extend it to null/both cases also ... | null, ... | undefined, ... | null | undefined).
Actual Behavior
The nested parameter should be rendered.
Steps to reproduce the bug
See https://github.com/maoueh/typedoc-bug-1020-repro

Define the snippet above in a file.
Ensure strict: true (this generates a union type from the parser point of view)
Inspect HTML, output is not rendered correctly.

Environment

Typedoc version: 0.14.2

That makes a lot of sense why nested keys aren't rendered when an argument is optional.
I definitely think it makes sense to render nested keys when an argument is marked as optional with ?. When the argument is explicitly unioned with null or undefined it might also make sense but I'd like to hear @aciccarello's thoughts on that behavior.

@Gerrit0 Is it even possible to discriminate between options?: {} and options: {} | undefined, seems the former being a sugar syntax for the latter, at least the --json output.json seems to imply that as options?: {} is being seen as this from the parser, which is also the same output when undefined | {}:
type: union,
types: [
  {
    "type": "intrinsic",
    "name": "undefined"
  },
  {
    "type": "reflection",
    "declaration": {
        ...
    }
  }
]

Purely from the JSON output, I guess it isn't possible. This seems like an oversight to me. options?: {} isn't quite sugar for options: {} | undefined as the latter requires explicitly passing undefined if the argument is not used.

You are right indeed, did not think about this, they are not the same in this optic.
It's really a blocker for me and I would like to make the fix. For now, I've skim between converter code and default theme doing the final rendering, still looking for the place where an object parameter is being converted to nested field, I guess there might be a recursive call somewhere.
Do you have some hints where I should look for in my hunt for a fix?

I'm not very familiar with how the theme works, it's been on my list to read through for a while. Parameters are rendered here.

Any updates? Any fixes?

I suspect #1103 may fix this, but I haven't had the time to dig into it yet.

I suspect #1103 may fix this, but I haven't had the time to dig into it yet.

Yeah, It works now.

But seems like the descriptions of nested parameters are not showing up.

/**ts
 * @param array Array
 * @param search Search Elem
 * @param opts Options
 * @param opts.start Start Index of Array
 * @param opts.end End Index of Array
 * @param opts.greaterFn Compare if first value is greater than second value
 * @param opts.equalFn Compare if two values are equal
 */
export function binarySearch<T>(
    array: T[],
    search: T,
    {
      start,
      end,
      greaterFn,
      equalFn,
    }: {
      start?: number;
      end?: number;
      greaterFn?: (a: T, b: T) => boolean;
      equalFn?: (a: T, b: T) => boolean;
    } = {
      start: 0,
      end: array.length - 1,
      greaterFn: (a, b): boolean => a > b,
      equalFn: (a, b): boolean => a === b,
    }
): number {
    // ...
}

 * @param opts Options

TypeDoc doesn't know what to do with this ^
You don't have any parameters called opts. You should instead name the param according to what is used in the function, so
 * @param start Start Index of Array

But start is inside a Object right?

Yes, but since you destructed the parameters so that it is available as start (and not opts.start) within the function, that is the parameter name recognized by TypeDoc.

Unfortunately it seems to happen with classes and interfaces too. Trying with v0.16.1, this code:
/**
 * Lorem ipsum
 */
class Foo {
    /**
     * Lorem ipsum
     */
    public bar?: {
        /**
         * Lorem ipsum
         */
        foobar: string;
    };
}

produces the same bug and foobar is not rendered.

That's unfortunate :/ I thought the changes to exports would have fixed that.

Fixed in<EMAIL_ADDRESS>If you install without a lockfile it should be picked up, or v0.16.3 (out later today) will pull this in.
Turns out the information to render everything was already there (partially due to the changes done to exports), but the themes weren't updated to support it.
If you are using a custom theme that has changed the type.hbs helper, it will need to pull in changes from<EMAIL_ADDRESS>to get this.

Rendering is tricky. There are cases when dealing with unions/intersections, conditional types, and function types where you have to be very careful to avoid generating an invalid type. I think I've caught all the edge cases, but it's possible I missed one.


Change loading color per component

Is there any way to define the loading color by props? I would like to have several loading on same page with different color? Thanks

This is in the plan, you have to wait for version 3.
You can track updates here
https://github.com/ankurk91/vue-loading-overlay/pull/14


Publish for Scala 2.12

Hi,
I am trying to use this library as a backend for my akka app, which is based on Scala 2.12. Would it be possible to publish this repository for Scala 2.12?
Best,
Hyun Min

@nitrogenice Published v0.5.0 which supports Scala 2.12.
https://github.com/okumin/akka-persistence-sql-async/releases/tag/v0.5.0
Thanks!


instagram banned my account

I made a meme page generator, it just copies posts from my meme pages list but instagram banned my account and deleted all my posts.

I added phone number but my script stopped working for this account
Doesn't this repository use private api?
Why i got banned?
How can i pass this?
code:

from datetime import datetime
import instagrapi
import random
import time
import os

cl = instagrapi.Client()
cl.request_timeout = 5

cl.login('username', 'password')

history = []
copy_list = ['dugunteroru', 'editah4z', 'tassakshitpost', 'boreklipogaca', 'medraxhumor', 'jolithex', 'palanin_mekani', 'igcoplugu', 'the_.green._goblin', 'parttimeejderyaavcisi', 'wiptieyerli']

def clear_files():
    for i in os.listdir('./myfiles/'):
        os.remove(f'./myfiles/{i}')

def send_follow(id):
    for i in cl_2.user_following(cl_2.user_id, 10):
        try:
            cl_2.user_unfollow(i)

        except:
            break

    comments = cl_2.media_comments(id)

    for i in comments[:10]:
        try:
            id = cl_2.user_id_from_username(i.user.username)

            cl_2.user_follow(id)

        except:
            break

        #follow users from the post comments

def send_post():
    while True:
        page_name = random.choice(copy_list)
        copy_page = cl_2.user_id_from_username(page_name)

        post = random.choice(cl_2.user_medias(copy_page, 10))

        if post.code not in history:
            history.append(post.code)
            break

        #choose a random post from page, and save code to history

    send_follow(post.id)

    if post.media_type == 1:
        try:
            photo = cl_2.photo_download(cl_2.media_pk_from_code(post.code), './myfiles')

            cl_2.photo_upload(photo, post.caption_text)

            clear_files()

        except:
            pass

    elif post.media_type == 2 and post.product_type == 'feed':
        try:
            video = cl_2.video_download(cl_2.media_pk_from_code(post.code), './myfiles')

            cl_2.video_upload(video, post.caption_text)

            clear_files()

        except:
            pass

    elif post.media_type == 2 and post.product_type == 'igtv':
        try:
            igtv = cl_2.igtv_download(cl_2.media_pk_from_code(post.code), './myfiles')

            cl_2.igtv_upload(igtv, post.caption_text)

            clear_files()

        except:
            pass

    elif post.media_type == 2 and post.product_type == 'clips':
        try:
            clip = cl_2.clip_download(cl_2.media_pk_from_code(post.code), './myfiles')

            cl_2.clip_upload(clip, post.caption_text)

            clear_files()

        except:
            pass

    elif post.media_type == 8:
        try:
            album = cl_2.album_download(cl_2.media_pk_from_code(post.code), './myfiles')

            cl_2.album_upload(album, post.caption_text)

            clear_files()

        except:
            pass

def run():
    while True:
        time.sleep(60 * random.randint(20, 45))
        #sleep 20 ~ 45 minutes

        send_post()

run()

If you only post with your personal account and nothing else, I recommend using the official API, differences:

You will not be able to post Stories;
Must be a Business account;
You have to renew the Token every 3 months, more or less.

I have an account that generates images and I use the official API to post to the feed, and the instagrapi to post to Stories.
And it's been 8 months since everything is going well, maybe it's an alternative for you.

tell me today this method will help unlock your instagram account?

but using the official API requires facebook to verify/review the app right?

@Jmallone , how did you get past this step?

This could possibly be because instagrapi doesn't have an auto session management feature and you've logged in a lot of times.
You should try using ensta. While it uses the web api, it stores your previous session locally.


Investigate dapp tests failures

Signed-off-by: nikolay<EMAIL_ADDRESS>Description:

Related issue(s):
Fixes #796
Notes for reviewer:

Checklist

[x] Documented (Code comments, README, etc.)
[x] Tested (unit, integration, etc.)

Codecov Report
Base: 72.70% // Head: 72.70% // No change to project coverage :thumbsup:

Coverage data is based on head (d304ada) compared to base (51ff96b).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #809   +/-   ##
=======================================
  Coverage   72.70%   72.70%
=======================================
  Files          29       29
  Lines        1744     1744
  Branches      319      319
=======================================
  Hits         1268     1268
  Misses        385      385
  Partials       91       91

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Issue 46 - render weather for lat/long

use json lat/long in weather api call

closed- weather rendered


[FEATURE REQUEST] Add overview about notes+

It would be nice to have an overview in a calendar-like design where you can have an easy and quick look over your saved entries.
Another request from me is to add a time-stamp to your entries to make the ability to save several entries per day actually functional.
Like "12:00 😀 Had lunch with xy"; "16:00 😐 Sat on my couch, bored."

Hey there, thank you for using my app and your suggestions ❤. For the calendar like overview, i saw it on other mood tracking apps and i thought it would be good to add it and now that you have mentioned it, i have one more reason to do that 😀 as for the second request can you provide more context on what exactly you want to have? Because you can add more than one effect entry for every day so i assume that i did not fully understand what you mean.

Thank you for your fast and kind answer.
What I mean is that you can already add several entries per day, BUT you don't know what time you wrote them- which would be quite important for "moody" people like me to get a better understanding of it.
I'll try another, formatted example:
11:00: 😀 Breakfast with family
17:00: 😐 Got bored
23:00: ☹ Couldn't get to sleep
The only difference to the current design would be to add the time of every entry in front of the text.
I hope this helped you more, have a great day.

Yup i get it now 😀 i guess you described it pretty well in the first place. I just did not get it. So it already has date on it and for the time it does make sense to add a timestamp too. You are right that is what a moody app would absolutely need 😁i will have big changes for the next update and i won't forget about these features. Thank you again for using my app and helping it improve and ge better ❤

A shame the enhancement didn't make it into the latest update. I fact, I don't see any significant or "big" improvements.. 🫢 It's still on your radar anyway, right?

yeah the latest build i made was a maintenance build to test something on fdroid. as you can see on issues list the latest build on fdroid has failed the RB (reproducible build) which enables user to download the app from wherever they want without any problems. so yes all the updates and requests are still planned and will be implemented. on the other hand my work is getting slower until the problem is either fixed or at least we know the reason of the fails. thanks for your concern and thank you for your patience. :heart:

@HarriBuh hey did you change your mind on this request?

Hey no offense taken. Im sorry for the inconvenience of delays on app updates. I got into sone work and found a job recently so it took a little too much time. I am still going to add the feature and will try to maintain the app sooner. But with the amiunt of used apps on fdroid i have and the job it might take a little longer. Again i am sorry that this issue was ipen for so long. Feel free to open it again whenever you want knowing the fact that i will implement it.

Hey @HarriBuh, remember the big change i talked about and it did not happen for a long time?
just thought i would tell you sooner that the big change is coming. well not as big of a change. its just some ui enhancements, theme and overviews and guess what? the calendar view is going to make it in this update.
im still on R&D stage of the feature but the app with the requested feature will be out in 2 or 3 days.
thanks again for contributing, opening this issue and requesting the feature ❤

im gonna open this issue and properly close it this time if you dont mind.

yup and that requires a custom view which I am working on. i pushed it with a simple calendar overview so that we have a base of what we want and i will add the custom made view on next update


Linkedin pipe

name: pull request
about: submit changes to the project
title: "[pr] "
labels: ''
assignees: ''

description
brief description of the changes in this pr.
related issue: #
how to test
add a few steps to test the pr in the most time efficient way.

if relevant add screenshots or screen captures to prove that this PR works to save us time.
if you think it can take more than 30 mins for us to review, we will pay between $20 and $200 for someone to review it for us, just ask in the pr.

@m13v also can you make the stripe integration like i did for pipe-loom in the pipe-store


Show current debug line in overview ruler

I think it would be beneficial to show the current line the debugger is on in the overview ruler (For example, using an orange colour). Currently, when debug.showBreakpointsInOverviewRuler is enabled, it only shows the debug breakpoints.
Current behavoir

Requested behaviour

Yeah, not a bad idea.
Let's do the change start of next milestone so we have a full milestone to get feedback on this. Thus assigning to November.

I have pushed a change to tackle this. You can try it out with vscode insiders in 7 days and let me know how it goes.

@isidorn Amazing thanks a lot! I will test it out in 7 days.

@isidorn It works and looks amzing! Very minimalistic. Thanks a lot for implementing this.

Great, thanks for trying it out and for letting us know. Adding verified label.


wasm-bindgen & web-sys stack WebGL bindings

First of all, thanks for the effort to maintain gl-rs!
I've already used gl-rs with stdweb and it works great. But now I am developing a project using wasm-bindgen and web-sys. I can directly access WebGL bindings through web-sys, but I want to use an OpenGL abstraction make the project portable to other platforms.
With that said, I would like to know: What is the state of gl-rs with wasm-bindgen + web-sys? I couldn't find any resource on it.

Ahh that would be handy! I hear that the ecosystem is moving to wasm-bindgen and web-sys now? I might need some help if somebody was going to support this. Possibly we'd need a new binding generator 🤔.

There already might be another crate out there for webgl on wasm-bindgen, and if that's the case then maybe we should be directing people to that. Not sure though!

for making a cross-gl program, your best bet is glow


When I ran the command git clone /LibreTranslate-init.git, an error occurred.

When running the command git clone https://github.com/argosopentech/LibreTranslate-init.git ~/LibreTranslate-init, an error occurred.

How should I solve this problem?
My Ubuntu version: 24.04

See #24


Added a Picture-in-Picture button and a small bugfix/improvement

I was going to create a CR extension just for the PIP feature, but saw that this one existed, so decided to add the feature to an existing extension.
Also, fixed a bug where the extension's and CR's "SKIP TO" buttons show up together, overlapping. Made only the extension's button show and made it look exactly like CR's (basically replacing it).

I'll see if I can add subtitles to this stuff, but I'll merge it anyway 👍.
CR's skips aren't supposed to overlap, at least they won't once they stabilize their functionality (they have multiple APIs to get them and while it's supposed to use the one tagged production, they fall back on the others in case of error) but it's great to have the same style as CR's one anyway thx.

Cool, actually I'd suggest removing the extension's skip button entirely cause it doesn't really provide much functionality, and as I've noticed it randomly pops up saying to skip random parts of an anime (like here https://imgur.com/a/FeCzXAi , popped up randomly in the middle of a fight scene), but it's probably a bug that just can be fixed. OR remove extension's button but replace the original CR button's text with the timestamps, that could also work.

Yep, they are subtitles based so it detects holes in fight scene subtitles as things to skip since intro/outro are either a time without subs or subs that are the same sequence as the last episode.
But as Crunchroll now begins to implement theirs, they will eventually disapear. In the meantime, they'r still hideable (the option hide only those of this extension even if the distinction is not yet apparent in the name of the option).


Licensing question

Hey,
can you clarify what "The Metric 3D code is under a 2-clause BSD License. For further commercial inquiries..." means?
Can we use it commercially or do we have to obtain a license?
Thank you!

If you need to use it commercially, please email me.


zeromq4-haskell fails tests, fails to install on 18.09

Issue description
Tried to install ihaskell, it reliably fails to build due to zeromq4-haskell failing tests.
I was able to install on a machine running 18.03, but on my 18.09 machine it fails.
Output from the attempt here
Steps to reproduce
nix-shell -p haskellPackages.zeromq4-haskell
Technical details
nix-info results:

system: "x86_64-linux"
host os: Linux 4.14.74, NixOS, 18.09.809.de37b4c18c0 (Jellyfish)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.1.1
channels(jack): ""
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Closing this issue - build succeeds after nix-channel --update

I am getting this error with the latest unstable channel.

I'm getting it on latest 18.09 too.

Resolved upstream.


Release notes don't properly categorize / surface some changes

Description
How can the docs be improved?

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

I'm not familiar with how the release notes are generated. But here's an example to illustrate the problem:
0.34.0 introduced disruption budgets as a new feature (at least, that's what I would consider it, since new fields are added to the configs). But if you look at the release notes it's not mentioned under Features, yet is mentioned in various other places like Documentation (because the upgrade guide does mention it).
It's possible I just happened to run into the one case where something was missed. If so feel free to close this issue. Or maybe this wasn't classified as a feature but just a modification of how disruption works in Karpenter. In that case, maybe another section like Important Changes and some info similar to what's in the upgrade guide would be useful.

I think this is largely a consequence of our release notes being split between two repositories: the upstream library (kubernetes-sigs/karpenter and the AWS provider (this repo). These release versions are currently coupled, so to get a full picture you'd want to check out the releases in both versions. For example, in the upstream v0.34.0 release disruption budgets is listed as a feature.
It would be nice to have a unified changelog, since the provider is the product that users interact with at the end of the day. I think this is especially true as we move to decouple the library and provider release versions post v1.

Thanks, that makes a lot of sense. I didn't realize there was a separate repo.


can not access camera on web view for IOS

I can not access camera on web view for IOS

Finally it works on my app with simple code like this image

@anhvoduy did you need to change the Info.plist file?


Chrome Extension to find meaning of words.

Is your feature request related to a problem? Please describe.
Whenever I am reading an article online and encounter some tough word, I have to switch tabs and find the meaning of it which break my concentration and also becomes annoying sometimes.
Describe the solution you'd like
What I will do is make a Chrome extension such that whenever a person selects a word, right-click, and select the extension, he will instantly get the meaning of the word.
How do we know when the feature is complete?
I will submit a PR with the code for the chrome extension in it.

Please assign this issue to me under gssoc'24


feat: implement sync::Barrier

Based on the implementation in https://github.com/tokio-rs/tokio/pull/1571
Based on the implementation in the std lib
Things to discuss

async or std Arc in examples and tests
async or std Mutex in the implementation can't use std, as it needs to be shared
use of broadcaster dependency to implement, well broadcast

To fix

[x] missing debug implementation, once broadcaster has it, or it is dropped

Docs

It looks like it's Cargo that's failing CI on MacOS. All other tests' pass, so I think this should be fine. Let's see if Bors accepts this.
bors r+

bors r+

Looks like on this nightly cargo doc broke. Think this is okay to merge manually.


error on workflow form for manual register makes no reference galaxy

Describe the bug
When creating a workflow through manual register, the regex error for the workflow field doesn't include a reference to the galaxy file extension.
To Reproduce
Steps to reproduce the behavior:

Go to my workflows
Click on + and then register custom workflows
fill out workflow path with something invalide like asdf
See that the warning that appears doesn't mention .ga

Expected behavior
should include .ga
Additional context
API - 1.9.0-alpha.9-SNAPSHOT
UI - 2.5.1-rc.1-46-g37f122a0
dev.dockstore.net
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Sprint: Backlog
┆Issue Number: DOCK-1312

Error message is getting long enough that it should really just have a different error message for each descriptor type.


Add palette command to edit syncLocalSettings.json

Visual Studio Code Version : 1.9
Code Settings Sync Version : 2.4.4
There's syncLocalSettings.json since 2.4.4, see https://github.com/shanalikhan/code-settings-sync/issues/100. It would be nice if there was something like Sync: edit local settings palette command to open it quickly.

Yes, it will be added on advance options.

Fixed on v2.5.0
Update ! 😄


[DealabsBride] Fix for the new site

Dealabs changed his page structure

New Website structure handled
Loss of functionnality (no more category, expired deal or local deal
filter)

This fixes the issue #594 !
The new website is a nightmare to parse, but I did what I could.
This leads to a loss of functionality which is almost the same as on the original website

I tried both way : one full string, or string on different lines concatenated : travis does not allow it.
I do not figured how do you like I change my code using antislash : this will add some new line, and the find function would fail.
I think I need some example or advice :cold_sweat: !

If you build the selector with the implode() function it splits into multiple lines that are actually more readable in my opinion.
Have a look at FB2Bridge for reference: https://github.com/RSS-Bridge/rss-bridge/blob/7939bffcdd4a07fe4e015e35c9e33d20e208421b/bridges/FB2Bridge.php#L168-L178
In your case this
$deal->find('img[class=thread-image width--all-auto height--all-auto imgFrame-img cept-thread-img img--dummy js-lazy-img]', 0)

could convert into this:
$selector = implode(
    ' ', /* Notice this is a space! */
    array(
        "thread-image",
        "width--all-auto",
        "height--all-auto",
        "imgFrame-img",
        "cept-thread-img",
        "img--dummy",
        "js-lazy-img"
    )
);

$deal->find('img[class=' . $selector . ']', 0);
/* I had to use spaces for indentation, make sure to
replace them with tabs if you copy this code */

Does that work for you?

I finally got it !
Thank you @LogMANOriginal !

Merged, thanks !


fix(engine): include modules w/o labware in motion planning

Overview
This PR fixes a bug in ProtocolEngine's motion planning. Modules loaded into the engine without a labware would not be taken into account when calculating the safe travel height for arc movements. This could potentially lead to collisions during LPC if a protocol loaded modules in such a way.
Videos
In this setup, I placed a blue piece of paper over a magnetic module so you can see the travel height of the pipette as it arcs
release_6.0.0 / edge
https://user-images.githubusercontent.com/2963448/175611290-a3eb22af-413d-4f09-9cfb-9d2555d20090.MOV
This branch
https://user-images.githubusercontent.com/2963448/175611337-35ee418e-5aa3-4783-98f8-4af4278a4b71.MOV
Changelog

When getting the tallest item on the deck, check all labware and all modules

Review requests
Reproduction procedure below. Compare this logic to the PAPIv2 motion planning logic in src/opentrons/protocols/geometry/planning.py
Risk assessment
My main question is if I've misunderstood something about thermocyclers. If I have, this could lead to spurious errors during. However, I'm not seeing any differences in max-Z calculations.
Steps to reproduce
I reproduced the buggy behavior using an HTTP protocol, since this mirrors what LPC will be doing.

P300 single pipette on the right mount
Tip rack loaded in slot 4
Well plate loaded in slot 3
Magnetic module loaded in slot 2 (but not physically placed there, because we're testing for collisions)

Procedure:

Create run
Home
Load P300 single onto the right mount
Load well plate into slot 3
Load tip rack into slot 4
Load magnetic module into slot 2
Pick up a tip (with a little offset because that's what I need on my robot)
Move to well A1 of well plate
Move back to well A1 of the tip rack

POST /runs
{"data": {}}

POST /runs/:run_id/commands?waitUntilComplete=true
{
    "data": {
        "commandType": "home",
        "params": {}
    }
}

POST /runs/:run_id/commands?waitUntilComplete=true
{
    "data": {
        "commandType": "loadPipette",
        "params": {
            "pipetteName": "p300_single",
            "mount": "right",
            "pipetteId": "pipette-id"
        }
    }
}

POST /runs/:run_id/commands?waitUntilComplete=true
{
    "data": {
        "commandType": "loadLabware",
        "params": {
            "loadName": "corning_96_wellplate_360ul_flat",
            "version": 1,
            "namespace": "opentrons",
            "location": {"slotName": "3"},
            "labwareId": "well-plate-id"
        }
    }
}

POST /runs/:run_id/commands?waitUntilComplete=true
{
    "data": {
        "commandType": "loadLabware",
        "params": {
            "loadName": "opentrons_96_tiprack_300ul",
            "version": 1,
            "namespace": "opentrons",
            "location": {"slotName": "4"},
            "labwareId": "tip-rack-id"
        }
    }
}

POST /runs/:run_id/commands?waitUntilComplete=true
{
    "data": {
        "commandType": "loadModule",
        "params": {
            "model": "magneticModuleV2",
            "location": {"slotName": "2"},
            "moduleId": "module-id"
        }
    }
}

POST /runs/:run_id/commands?waitUntilComplete=true
{
    "data": {
        "commandType": "pickUpTip",
        "params": {
            "labwareId": "tip-rack-id",
            "pipetteId": "pipette-id",
            "wellName": "A1",
            "wellLocation": {
                "offset": { "x": 1, "y": 1, "z": 0 }
            }
        }
    }
}

POST /runs/:run_id/commands?waitUntilComplete=true
{
    "data": {
        "commandType": "moveToWell",
        "params": {
            "labwareId": "well-plate-id",
            "pipetteId": "pipette-id",
            "wellName": "A1"
        }
    }
}

POST /runs/:run_id/commands?waitUntilComplete=true
{
    "data": {
        "commandType": "moveToWell",
        "params": {
            "labwareId": "tip-rack-id",
            "pipetteId": "pipette-id",
            "wellName": "A1"
        }
    }
}

There's a # TODO on ModuleView.get_overall_height() about it not being tested or used. We should probably update that and ideally also add the tests.

Done and done.

The meaning of bareOverallHeight with respect to a Thermocycler is a bit unclear to me. I suppose it could either cover:

The distance from the deck to the top of the bottom half of the "clamshell."
The distance from the deck to the top of a closed lid.

I think we need to make sure it's (1), not (2)

I agree. It's value is 98.0 mm, which is less that the height of a magnetic module. Could someone with a TC handy measure it and confirm?

I think another way to test this, if you don't feel like issuing HTTP requests manually, is to run through LPC with this protocol:
metadata = {"apiLevel": "2.12"}

def run(protocol):
    tip_rack = protocol.load_labware("opentrons_96_tiprack_300ul", 5)
    plate_1 = protocol.load_labware("biorad_96_wellplate_200ul_pcr", 1)
    plate_2 = protocol.load_labware("biorad_96_wellplate_200ul_pcr", 3)

    # Try commenting out each one, one at a time.
    thermocycler = protocol.load_module("thermocycler")
    # magnetic_module = protocol.load_module("magnetic module gen2", 6)

    pipette = protocol.load_instrument("p300_single_gen2", mount="left", tip_racks=[tip_rack])
    pipette.transfer(300, plate_1.wells_by_name()["A1"], plate_2.wells_by_name()["A12"])

There's a # TODO on ModuleView.get_overall_height() about it not being tested or used. We should probably update that and ideally also add the tests.

Done and done.

The meaning of bareOverallHeight with respect to a Thermocycler is a bit unclear to me. I suppose it could either cover:

The distance from the deck to the top of the bottom half of the "clamshell."
The distance from the deck to the top of a closed lid.

I think we need to make sure it's (1), not (2)

I agree. It's value is 98.0 mm, which is less that the height of a magnetic module. Could someone with a TC handy measure it and confirm?

The answer is 1.
The module definition includes a labwareOffset's z value of 97.8 mm and the bottom of "the clam shell"'s surface is slightly higher than the top of a loaded well plate in the block (98mm).  The when the lid itself is closed, the thermocycler's height exceeds the maximum z travel of many pipette+tip combinations.  So Max's thought is exactly right, that is why we avoid the closed TC for all move commands regardless of pipette+tip combination out of caution.


better way to handle subinplace with variables in different models

I think we need an easier way to do something like this
        for i in range(Nclimb):
            for atmvar, climbvar in [("\\rho", "\\rhoClimb"), ("T_{atm}", "TClimb"), ("h", "hftClimb")]:
                descr = dict(atmvec[i][atmvar].key.descr)
                model = climb if atmvar != "h" else cmc
                climbkey = model[climbvar][i]
                climbdescr = dict(climbkey.key.descr)
                # new variable is same as atmvar but with extended models, modelnums
                descr["models"].extend(climbdescr["models"])
                descr["modelnums"].extend(climbdescr["modelnums"])
                subs[climbkey] = Variable(**descr)

@bqpd that linking does not appear to be working...running the file with the code form above I get this table output

note that both "T_{atm}" and `"T_{climb}"' are still alive...
the code is at commit e39690cf2eb8f5195b73bb186b4e941e894c894d on gpkit-models

so I want linking to work like I have it set up in this commit https://github.com/hoburg/gpkit-models/pull/89/commits/703af956dc127f2e706d806853318a6de625d409...this method of linking works on master until this commit https://github.com/hoburg/gpkit/commit/ba9c35fd06c2c0649bbf0b827c787f647d794508 so I think that somehow fast subinplace messed up linking
@mjburton11 just in case this is relevant to the 82 plane

@bqpd is there a quick local fix for this?

Going back to ba9c35f (or the feasmodtest branch, if that works?)

feasmodtest works!...I tried checking out
https://github.com/hoburg/gpkit/commit/ba9c35fd06c2c0649bbf0b827c787f647d794508
yesterday but the engine model wouldn't run on it

nope just kidding, linking doesn't work on feasmodtest either...

Did this linking...ever work?

yeah up to commit ba9c35f on master...the problem is that after the fast subs merge I had to modify the engine model to run it on master, and I want to link the flight profile with the same engine model I'm using for validation

@mayork what's the status of this?

aborted, I thought the game plan was to use vectorize and performance models now

Sounds good to me. I'll close this, then.


[feat] in-app update check

Tell us about the task you want to perform and are unable to do so because the feature is not available
Implement feature to automate checking for app updates on launch as mentioned below.
Describe the solution/feature you'd like us to add
On launch, we can check if a new version of API Dash is available by matching it with GitHub repository. This can be done by

Maintaining a version file in the root directory
By using GitHub API to find latest release.

Then an user prompt can be made to notify user that a new version is available for download. User may have an option to download now, or skip this update.

If user skips,

Save this action in shared preferences and not alert user for current stable version update.

If user updates,

Scenario 1 (Automatic Update)

Use GitHub API to download latest artifact according to user's platform
Perform an update (Approach to be discussed)

Scenario 2 (Manual Update)

Redirect user to API Dash's release tab (https://github.com/foss42/apidash/releases)
Let user perform the update

Any other feedback you would like to provide regarding the site
This feature isn't a priority but a good to have, and may be merged after GSoC contribution period to avoid any conflicts.

Hi, I'm Sathsara. New here... More than happy to contribute.
We can use a plugin like "updat" and it'll definitely simplify the update mechanism, but if we require a more customised approach, we can implement a solution to check for updates and handle the installation process accordingly.
For Windows environments, we can execute system-specific commands to update the application. For instance:
apidash-windows-x86_64.exe /SILENT or /VERYSILENT
Using /SILENT will display progress during the update, while /VERYSILENT will perform the update silently without any visible progress indicators. Additionally, this command will prompt the application to close any running instances before updating and show the windows UAC window asking permission.

Windows UAC

Closing Application

/SILENT Update progress indicator

In Debian-based Linux distributions, we can use the following command to install the update:
sudo dpkg -i apidash-linux-amd64.deb
However, it's important to note that in Linux, obtaining the user's password may be necessary for installation. On the upside, updating the application in Linux shouldn't require closing any running instances, the update can be performed in the background, and the new version will be applied upon the next launch of the application.
I might need some input on macOS since I don't have a device that's compatible.

@sathsarabandaraj probably not a good idea to install the debian package, also since packages are installed using sudo perms, We'll need to implement a password input handler as well.
Better approach for linux would be to simply give a popup like discord does:

One the user clicks on the download button a browser window opens that simply downloads the .deb file, users can simply install it themselves.

Rather than taking in the password within API Dash, we can have a popup to let user know that they'll have to manually run the command, and show the command itself?

Usually, that isn't necessary since that is how they would've installed apidash in the first place.
Also in the future when we can finalize the packaging process we can simply create packages for the distro repositories, so we don't have to worry about linux updates.
The user can get the updates from their package manager. (We'll can still show the user a popup if the system hasn't been updated and user is using a stale package).
However, if we feel like it, we can add it. Though, The commands will increase with the number of distros we support.

please add the labels here like Gssoc, level1

@EswarPesala we will add it after assessing the effort made made in PR.

Thank you u can contact me on WhatsApp<PHONE_NUMBER>
On Tue, May 14, 2024, 12:24 deepanshu garg @.***> wrote:

@opxdelwin https://github.com/opxdelwin thanks for creating the issue i
want to work on this type of feature I have same in my mind thanks for
creating this
I try my best to make this this is first time on open source
—
Reply to this email directly, view it on GitHub
https://github.com/foss42/apidash/issues/373#issuecomment-2109418623,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BHHMKGKJE5SUAWFOOXYGCFLZCGYKXAVCNFSM6AAAAABFQNU4GKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZGQYTQNRSGM
.
You are receiving this because you were mentioned.Message ID:
@.***>


feat(shim): added slight shim

The main thing for this PR is adding a slight implementation of containerd shim. The implementation is very much similar to spin shim implementation. I have also modified build pipelines for it.

@devigned fantastic - it works for me


Broken link on package card for users

Thanks in advance for your bug report!

[X] Have you reproduced issue in safe mode?
[X] Have you used the debugging guide to try to resolve the issue?
[X] Have you checked our FAQs to make sure your question isn't answered there?
[X] Does your issue already exist?
[X] Have you checked you are on the latest release of Pulsar?

What happened?
Clicking on the package card author/user takes you to a non-existent page.
e.g. for atom-clock - https://pulsar-edit.dev/users/b3by
As I understand it we don't currently have a user filter/api/thingy which is why I'm not thinking of a PR to fix this yet, just to track it.
Either this will be fixed by new front end website functionality or this line will need to change.
https://github.com/pulsar-edit/settings-view/blob/21040603b83ed6f4086594111288908a3cfd56e1/lib/package-card.js#L251
Ideally it should also be able to use the branding API rather than having the website address directly.
Which OS does this happen on?
🐧 Debian based (Linux Mint, Ubuntu, etc.)
OS details
LM 21
Which CPU architecture are you running this on?
64-bit(x86_64)
What steps are needed to reproduce this?
Click on a package card author/user link.
Additional Information:
No response

I love that you keep finding all these undocumented API's that the backend has.
The only user endpoint we have is /api/users/:userName/stars so this will have to be implemented

An update, while it is in progress and this link doesn't yet exist, this will be the valid link: https://web.pulsar-edit.dev/users/:login
This endpoint is still in progress on the backend, and once complete would then be mirror onto the frontend as well, that is unless someone beats me there

Well now that this package is being added to the Pulsar repo we can look at using the branding API too. So we could add:
"urlPkgSite": "https://web.pulsar-edit.dev/"

And the actual link would be something like:
{atom.branding.urlPkgSite + "users/:login"}


(GH-1427) Use environment variable for puppetdb config path in Windows

This updates how Bolt locates the puppetdb config file on Windows.
Previously, the path was hardcoded as C:\ProgramData\, which could
cause issues if the user redirected the folder or had a different system
drive. Bolt will now use the environment variable
%CSIDL_COMMON_APPDATA% to get the known folder.
Fixes #1427

CLA signed by all contributors.

If I just try this File.expand_path in irb on a Windows host, it doesn't seem to expand anything. Is there some other setup I need to do (which I assume Bolt is doing)?

I also just tried it through Bolt and it doesn't seem to work for me.

Annoyingly, this doesn't show a merge conflict but it probably ought to. This needs to be rebased for the CHANGELOG update (merging it now will put the entry under 1.40.0).

Updated CHANGELOG.md


add basic python support for protobuf and thrift

Add basic Python support for both Protobuf and Thrift code generation.
This does not include gRPC yet. The sample code is also provided as tests and not regular source code.

Fine to punt on, but it would be cool to demonstrate MyPy integration with Protobuf: https://www.pantsbuild.org/docs/protobuf#step-1-activate-the-protobuf-python-backend

Going to punt on MyPy integration for a future PR.

Fine in a followup, but it would be good to add CI with GitHub actions to run ./pants test on the code.

Yup, that's my plan.


Billy switch network

Network change requires password input again
Not persistent across storage sessions

Do we really want to have a switch to use the main network?
other than that I'm fine with this PR

@muxe mainnet removed.
ok to merge?


dont ping cluster after tearing down

#1497  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

ya seems to be ok, just doesnt add any data to the resource status info collection, which is fine since its for a "terminated" record


Fix public cloud provider installation tests to use the epinio chart

LGTM. I saw that you removed skipCertManager=true, but is CertManager still installed by default if not present? Or we have to add this in all tests?

cert-manager became an external dependency, it has to be installed before Epinio. I had a look on one test and it was installing cert-manager, I though all of them did (after all they were skipping the installation)

cert-manager became an external dependency, it has to be installed before Epinio. I had a look on one test and it was installing cert-manager, I though all of them did (after all they were skipping the installation)

No some of them use the default installation, but I can do this if you want, and add it to this PR.

I saw some small issues that can be fixed later (not related to CI): https://github.com/epinio/epinio/issues/1240


Do not pad highest dimension of memory

Padding is only needed to keep bank/ofs resolution consistent when higher dimensions increment.  Having padding on the most significant dimension is pointless and confusing

Actually this was a bad idea because it throws off the padding calculator that tries to minimize area.  For example, a mem my have N = 21, dims = 7,25, alpha = 1,7.  Two of its P options are 21,1 and 7,3.  It SHOULD choose 7,3 since it results in a pad of 0,2 and therefore there are ceil(7 * (25+2)/21) = 9 elements per bank.  But if we force no-pad for the highest dim, the P option of 21,1 results in each bank having ceil(7*25/21)=9 elements per bank, but address 0,24 of this memory should have ofs=24, which wasn't accounted for because we ignored the padding.
TLDR padding the highest dimension seems unnecessary from the point of view of the bank/ofs calculation arithmetic, but is actually required when sizing the physical BRAMs and assigning the correct number of address bits to them


#601 resource policies

References
Edit Item - Manage Resource Policies / Roles
Description
This is an initial PR to implement manage of resource policies. The unit tests are not yet done.
Instructions for Reviewers

Added a link to the item policies page to the item status tab
Created the policies page component
Show the current policies for the Item, and each bundle and bitstream within the item
Added the ability to edit or remove each exiting policy
added a link to their edit group page
Added the ability to add a new policy for the item and each bundle and bitstream within the item
Added methods to the ResourcePolicyService to retrieve all policies for a resource and to support CRUD for policies

Known problems due to https://github.com/DSpace/dspace-angular/issues/644 :

In the resource policy page eperson/group related to the policy should disappear from view

In the resource policy create page the list of eperson/group should be empty after the first time you access the page

editing fields for policyType and action are disabled because replace operations are not yet implemented https://jira.lyrasis.org/browse/DS-4477

Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[ ] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes TSLint validation using yarn run lint
[x] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[x] My PR passes all specs/tests and includes new/updated specs for any bug fixes, improvements or new features. A few reminders about what constitutes good tests:

Include tests for different user types (if behavior differs), including: (1) Anonymous user, (2) Logged in user (non-admin), and (3) Administrator.
Include tests for error scenarios, e.g. when errors/warnings should appear (or buttons should be disabled).
For bug fixes, include a test that reproduces the bug and proves it is fixed. For clarity, it may be useful to provide the test in a separate commit from the bug fix.

[ ] If my PR includes new, third-party dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.

test are completed now, PR is ready to be reviewed

Hi @atarix83
I saw two bugs,
when you are adding policy sometimes it does not show the users, nor the groups

when you try to edit a group send 404 message

@jtimal
thanks for reviewing. First issue is due to https://github.com/DSpace/dspace-angular/issues/644 and I already mentioned on the PR description.
I'll check the edit group link

Hi @atarix83, tests are successful.

Thanks @atarix83!
Overall it works well. A few comments though:

It seems that you can only browse for epersons and groups to grant a permission to. In xmlui in DSpace 6, you used to be able to search. That seems more convenient. It should also be possible with the existing rest endpoints.
You can also no longer change the eperson, group that gets the perission in the edit view, or the policy or action type. You could in DSpace 6. That may be due to a rest restriction though.
After you delete a policy it still shows up in the overview. To prevent this you should call requestService.removeByHrefSubstring to remove calls to resourcepolicies/search/resource?uuid=${current uuid} after a delete request succeeds
The edit policy page should set its own trail. Currently it depends on how you got there. If you come from the edit page, it uses that trail, if you go straight there it simply says "Home"
The policy overview page looks a bit sloppy

There's no space between the delete and add buttons up top

perhaps move them somewhere they'll always fit on a single line, or perhaps just shorten the labels to "Delete selected" and "Add"
I'd also use the same style buttons as on other pages: btn-success with a plus icon for add btn-danger with a trash can for delete

The edit links aren't aligned

in other places (e.g. the edit item metadata or bitstream tabs) we tend to have a column labeled actions at the back, with icons representing the actions. I think for consistency it would be better to use the same aproach here

It seems that you can only browse for epersons and groups to grant a permission to. In xmlui in DSpace 6, you used to be able to search. That seems more convenient. It should also be possible with the existing rest endpoints.

I'll add a search field

You can also no longer change the eperson, group that gets the perission in the edit view, or the policy or action type. You could in DSpace 6. That may be due to a rest restriction though.

Yes this is due to a rest restriction https://github.com/DSpace/Rest7Contract/blob/master/resourcepolicies.md#linked-entities

After you delete a policy it still shows up in the overview. To prevent this you should call requestService.removeByHrefSubstring to remove calls to resourcepolicies/search/resource?uuid=${current uuid} after a delete request succeeds

Yes I'm aware of this, i forgot to list with the known issues. I've already tried to remove calls here https://github.com/4Science/dspace-angular/blob/863520995975694157ba259db6e9b02d161a7d99/src/app/shared/resource-policies/resource-policies.component.ts#L248 but it doesn't work anyway. Is it the right way to remove previous calls?

The edit policy page should set its own trail. Currently it depends on how you got there. If you come from the edit page, it uses that trail, if you go straight there it simply says "Home"

I also noticed, but it seems an issue with breadcrumbs change detection because after the first triggered change detection the right trail appears

There's no space between the delete and add buttons up top
perhaps move them somewhere they'll always fit on a single line, or perhaps just shorten the labels to "Delete selected" and "Add"
I'd also use the same style buttons as on other pages: btn-success with a plus icon for add btn-danger with a trash can for delete
The edit links aren't aligned
in other places (e.g. the edit item metadata or bitstream tabs) we tend to have a column labeled actions at the back, with icons representing the actions. I think for consistency it would be better to use the same aproach here

I'll work on these

@artlowel I should have implemented your suggestions

I've already tried to remove calls here https://github.com/4Science/dspace-angular/blob/863520995975694157ba259db6e9b02d161a7d99/src/app/shared/resource-policies/resource-policies.component.ts#L248 but it doesn't work anyway. Is it the right way to remove previous calls?

No, I meant that you should remove it after you receive a successful response from a DELETE request.
Removing it right before each request can be problematic because both removeByHrefSubstring() and searchByResource() work asynchronously. So the possibility exists that searchByResource's new request gets configured and sent out before the remove is executed, this causes the request to be removed before the server can respond, and when the server response comes in it creates an invalid entry in the requestCache: a response without a request.
I've seen that happen before and it causes issues that are very hard to diagnose.
So I wouldn't clear the cache every time just to make sure. Instead, clear it when you know you've made changes and the cache is outdated. That's better for performance anyway.

I also noticed, but it seems an issue with breadcrumbs change detection because after the first triggered change detection the right trail appears

You're right. I see why as well. I'll create a small PR to fix it.
Thanks for taking my other suggestions in to account. I think the page already looks a lot better.
I'd perhaps remove the padding classes on the edit button, and instead use btn-sm, that's what's used in other places.
And perhaps also move the group edit link to a button in the last column as well (you could use this icon to differentiate from the existing button)
I also noticed that you can't use this page on a phone screen. You can't reach the right side of the tables. I appreciate it's a complicated page, and I don't expect it to look perfect on small screens, but you should be able to use it. Perhaps simply switching to responsive-tables can solve this issue?
I also think the search is a big improvement. Thanks!

@artlowel @tdonohue
now all feedback should be addressed.

issue occurred after policy delete should be resolved.
issue with eperson/group related to the policy due to cache problem is still present
travis build fails because of some e2e tests don't pass. Do you have any idea why?

@artlowel @tdonohue
build is successful again, could you review this PR again ?


Other Stronghold reimplementations...

I think that these authors need to cooperate with the Unofficial patch.
And then it will bring greater success ...
I wrote to them. We wait...
1 https://github.com/fabian-arnold/stronghold-js
2 https://github.com/leidav/CastlekeepNew
3 https://github.com/Dwillnio/openStronghold
@Sh0wdown What do you think ?

Maybe you could give a brief summary on what they were working on?

The UCP and Stronghold reimplementations are two completely different and not combinable things. Only thing that could happen is that I join/participate one of those projects. Except for CastlekeepNew they seem kind of inactive though.
Here is another one, even with recent activity:
https://github.com/metalvoidzz/Sourcehold

@Sh0wdown ok
Topic is closed


Each time I try I have this message :
Graph node "http://<IP_ADDRESS>:8020" is invalid: URL is not defined
It seems that validateNodeUrl fires this exception (https://github.com/graphprotocol/graph-cli/blob/master/src/commands/deploy.js#L99)
But I can't figure out why.
Any help ?

Hi @anthonymq , I came across your post after encountering the same issue. My issue was attributed to me running node 8, I believe using node v10 may help here (the information was gathered from a search of the graph's discord)

@akeem It worked ! Thank you !


add topic tags

I suggest adding the topics embedded, firmware in the About section

Seems reasonable - added.


Inconsistent zoom behavior between browsers?

Hello,
First of all - thanks for this awesome library!
In a project we're working on recently, we've encountered a problem with how different browsers handle zoom scale, as the mousewheel delta is not normalized in d3.
As a solution we plan on overriding d3_behavior_zoomWheel.
I'd appreciate your output on this matter.
Thanks in advance.

Possibly related #2589.

Duplicate of #2589.


FR: Whisparr Integration

Description
Please integrate Whisparr (radarr but for adult movies). https://github.com/Whisparr/Whisparr
Priority
Low (Nice-to-have)
Please tick the boxes

[X] You've read the docs
[X] You've checked for duplicate issues

Does it have a calendar ? Are you actually using it ? Where do I put the notification bubble (all 4 corners are taken)
Maybe later but not really atm


Add CompletionItemKind.Folder

Fixes #17435
Adds a new completion item kind for folder/directories. This is useful for path intellisense

For the icons, I copied the icons for folders into the suggestion icon set. Let me know if new ones are needed instead.

I like


Faster path for onehotbatch(::CUArray{Int}, ::UnitRange)

Follow-up to #27, moves the inbounds check:
julia> inds100 = rand(1:100, 100); inds100cu = inds100 |> cu;

julia> @btime onehotbatch($inds100, 1:100);
  348.811 ns (1 allocation: 496 bytes)

julia> @btime onehotbatch($inds100cu, 1:100);  # with #27, minimum + maximum sync twice
  70.267 μs (86 allocations: 4.02 KiB)

julia> @btime unsafe_onehotbatch($inds100, 1:100);
  231.916 ns (1 allocation: 496 bytes)

julia> @btime unsafe_onehotbatch($inds100cu, 1:100);  # version with no checks
  8.889 μs (28 allocations: 1.11 KiB)

julia> function fused_onehotbatch(data::AbstractArray{<:Integer}, labels::AbstractUnitRange{<:Integer})
         offset = 1 - first(labels)
         indices = map(data) do datum
                    i = UInt32(datum + offset)
                    checkbounds(labels, i)  # like this PR
                    i
                  end
         return OneHotArray(indices, length(labels))
       end
fused_onehotbatch (generic function with 1 method)

julia> @btime fused_onehotbatch($inds100cu, 1:100);
  10.708 μs (31 allocations: 1.20 KiB)

julia> bad100 = copy(inds100); bad100[33] = 101; bad100cu = bad100 |> cu;

julia> fused_onehotbatch(bad100cu, 1:100)
ERROR: Out-of-bounds array access.
ERROR: a exception was thrown during kernel execution.
       Run Julia on debug level 2 for device stack traces.
ERROR: KernelException: exception thrown during kernel execution on device Tesla V100-PCIE-16GB
Stacktrace:
 [1] check_exceptions()
   @ CUDA ~/.julia/packages/CUDA/DfvRa/src/compiler/exceptions.jl:34
 [2] nonblocking_synchronize
   @ ~/.julia/packages/CUDA/DfvRa/lib/cudadrv/context.jl:331 [inlined]
 [3] device_synchronize()
   @ CUDA ~/.julia/packages/CUDA/DfvRa/lib/cudadrv/context.jl:319

julia> cu(ones(100))[bad100cu]  # getindex does much the same check, inside the kernel
ERROR: Out-of-bounds array access.
ERROR: a exception was thrown during kernel execution.
       Run Julia on debug level 2 for device stack traces.
ERROR: KernelException: exception thrown during kernel execution on device Tesla V100-PCIE-16GB
Stacktrace:
 [1] check_exceptions()
   @ CUDA ~/.julia/packages/CUDA/DfvRa/src/compiler/exceptions.jl:34
 [2] nonblocking_synchronize
   @ ~/.julia/packages/CUDA/DfvRa/lib/cudadrv/context.jl:331 [inlined]
 [3] device_synchronize()
   @ CUDA ~/.julia/packages/CUDA/DfvRa/lib/cudadrv/context.jl:319

Codecov Report
Base: 96.21% // Head: 96.37% // Increases project coverage by +0.16% :tada:

Coverage data is based on head (11b3feb) compared to base (32e06c8).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #29      +/-   ##
==========================================
+ Coverage   96.21%   96.37%   +0.16%
==========================================
  Files           4        3       -1
  Lines         132      138       +6
==========================================
+ Hits          127      133       +6
  Misses          5        5

Impacted Files
Coverage Δ

src/onehot.jl
96.61% <100.00%> (+0.45%)
:arrow_up:

src/OneHotArrays.jl

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Support for multiple accounts

Hello, is there any existing support (or plan to support) having multiple accounts for one application? I am building an app which uses two separate sets of credentials for Programmable SMS—some features are in a staging environment and should be using our Test SID / Test Auth Token.
Thanks for all your work on this package, it has made integrating with Twilio a breeze!

I came here in search for this and after looking at the code, it looks like you can just pass in a custom account: and token: into your API call and it'll pick that up.
For example: ExTwilio.Message.create(account: account_sid, token: token)
This has worked well for us, since we have a multi-tenant system and each customer can have a separate twilio account.

@atonse has the correct solution for now. In the future, we could revisit this.


Non blocking matchers & matching timeout

This is a better version of #72 that actually works 😄
Instead of the wrapped route chain routing/matching is now done in a loop until a timeout is reached. Each connection is prefetched without blocking. Then all routes and their matchers are tried on the available data. If nothing matched more data is prefetched and all routes are tried again. This is done until the timeout is reached. The timeout can be configured per layer4 server and defaults to 3s. I first had it set to 500ms but since the matching phase may contain tls handshakes that was too short. I saw some failed connections from far away servers where tls handshaking apparently takes about 1000ms.
If you want to test or compare both prefetching branches you can use this caddy config:

prefetch.json
{
  "admin": {
    "disabled": true
  },
  "logging": {
    "logs": {
      "default": {"level":"DEBUG", "encoder": {"format":"console"}}
    }
  },
  "apps": {
    "tls": {
      "certificates": {
        "automate": ["localhost"]
      },
      "automation": {
        "policies": [{
          "subjects": ["localhost"],
          "issuers": [{
            "module": "internal"
          }]
        }]
      }
    },
    "layer4": {
      "servers": {
        "https": {
          "listen": ["<IP_ADDRESS>:10443"],
          "routes": [
            {
              "match": [
                {"proxy_protocol": {}}
              ],
              "handle": [
                {
                  "handler": "proxy_protocol",
                  "timeout": "2s",
                  "allow": ["<IP_ADDRESS>/32"]
                }
              ]
            },
            {
              "match": [
                {"tls": {"sni": ["localhost"]}}
              ],
              "handle": [
                {"handler": "tls"}
              ]
            },
            {
              "match": [
                {"http": [{"host": ["localhost"]}]}
              ],
              "handle": [
                {
                  "handler": "proxy",
                  "upstreams": [{"dial": ["<IP_ADDRESS>:10080"]}]
                }
              ]
            }
          ]
        }
      }
    },
    "http": {
      "servers": {
        "backend": {
          "protocols": ["h1","h2","h2c"],
          "listen": ["<IP_ADDRESS>:10080"],
          "routes": [
            {
              "handle": [{
                "handler": "static_response",
                "status_code": "200",
                "body": "Hello World\n",
                "headers": {
                  "Content-Type": ["text/plain"]
                }
              }]
            }
          ]
        }
      }
    }
  }
}

The following curl commands should all work with this branch while some do not work with the old version:
curl -v -k --http2 https://localhost:10443
curl -v -k --http2-prior-knowledge https://localhost:10443
curl -v -k http://localhost:10443
curl -v -k --haproxy-protocol https://localhost:10443

I hope this is not a too big rewrite and you are still interested in merging it. I currently also test it with real browser traffic and until now it works fine.

I still need to fully grok the "freeze/unfreeze" stuff (as opposed to recording?)

I renamed them because "record" felt wrong since there is no recording happening during matching anymore. Instead the connection is frozen and can only read data from the prefetched buffer. Technically a matcher could still write but that would very likely result in an invalid state. We could return an error if writes are attempted during matching to prevent misuse.

Yes I can help bug fixing it, especially as long as I use it myself 😄

Awesome, thanks!!

This PR breaks our configuration.
A TLS connection is never established successfully with the module on this PR and Caddy 2.7.6. It works fine on c5d815daed3cf7c9be6f199b324aeae8b3c865f0 with Caddy 2.7.6.
We use caddy-l4 to forward to a Unix socket depending on the TLS Handshake, then have a secondary listened on a UNIX socket with on-demand TLS provisioning. (We are doing it this way , to be able to use different TLS provisioning policies, and others)
Setting the new timeout parameters to something like '15m' does not help.
The config:
{
  "logging": {
    "logs": {
      "default": {
        "level": "info",
        "writer": {
          "output": "stdout"
        },
        "encoder": {
          "format": "json"
        }
      }
    }
  },
  "apps": {
    "layer4": {
      "servers": {
        "http": {
          "listen": [
            ":80"
          ],
          "routes": [
            {
              "match": [
                {
                  "http": [
                    {
                      "host": [
                        "gitlab.REDACTED"
                      ]
                    }
                  ]
                }
              ],
              "handle": [
                {
                  "handler": "proxy",
                  "proxy_protocol": "v2",
                  "upstreams": [
                    {
                      "dial": [
                        "unix//var/opt/caddy/caddy.gitlab"
                      ]
                    }
                  ]
                }
              ]
            },
            {
              "match": [
                {
                  "http": [
                    {
                      "host": [
                        "registry.REDACTED"
                      ]
                    }
                  ]
                }
              ],
              "handle": [
                {
                  "handler": "proxy",
                  "proxy_protocol": "v2",
                  "upstreams": [
                    {
                      "dial": [
                        "unix//var/opt/caddy/caddy.registry"
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        },
        "https": {
          "listen": [
            ":443"
          ],
          "routes": [
            {
              "match": [
                {
                  "tls": {}
                }
              ],
              "handle": [
                {
                  "handler": "subroute",
                  "routes": [
                    {
                      "match": [
                        {
                          "tls": {
                            "sni": [
                              "gitlab.REDACTED"
                            ]
                          }
                        }
                      ],
                      "handle": [
                        {
                          "handler": "proxy",
                          "proxy_protocol": "v2",
                          "upstreams": [
                            {
                              "dial": [
                                "unix//var/opt/caddy/caddy.gitlab"
                              ]
                            }
                          ]
                        }
                      ]
                    },
                    {
                      "match": [
                        {
                          "tls": {
                            "sni": [
                              "registry.REDACTED"
                            ]
                          }
                        }
                      ],
                      "handle": [
                        {
                          "handler": "proxy",
                          "proxy_protocol": "v2",
                          "upstreams": [
                            {
                              "dial": [
                                "unix//var/opt/caddy/caddy.registry"
                              ]
                            }
                          ]
                        }
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        },
        "ssh": {
          "listen": [
            ":22"
          ],
          "routes": [
            {
              "handle": [
                {
                  "handler": "proxy",
                  "proxy_protocol": "v2",
                  "upstreams": [
                    {
                      "dial": [
                        "<IP_ADDRESS>:2022"
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      }
    },
    "http": {
      "http_port": 80,
      "https_port": 443,
      "servers": {
        "gitlab": {
          "strict_sni_host": true,
          "listen": [
            "unix//var/opt/caddy/caddy.gitlab"
          ],
          "listener_wrappers": [
            {
              "wrapper": "proxy_protocol",
              "timeout": 0
            },
            {
              "wrapper": "http_redirect"
            },
            {
              "wrapper": "tls"
            }
          ],
          "metrics": {},
          "routes": [
            {
              "match": [
                {
                  "host": [
                    "gitlab.REDACTED"
                  ]
                }
              ],
              "handle": [
                {
                  "handler": "headers",
                  "response": {
                    "set": {
                      "Server": [
                        "REDACTED"
                      ]
                    }
                  }
                },
                {
                  "encodings": {
                    "gzip": {},
                    "zstd": {}
                  },
                  "handler": "encode",
                  "prefer": [
                    "zstd",
                    "gzip"
                  ]
                },
                {
                  "handler": "reverse_proxy",
                  "load_balancing": {
                    "selection_policy": {
                      "policy": "round_robin"
                    }
                  },
                  "upstreams": [
                    {
                      "dial": "<IP_ADDRESS>:8081"
                    }
                  ]
                }
              ],
              "terminal": true
            }
          ]
        },
        "registry": {
          "strict_sni_host": true,
          "listen": [
            "unix//var/opt/caddy/caddy.registry"
          ],
          "listener_wrappers": [
            {
              "wrapper": "proxy_protocol",
              "timeout": 0
            },
            {
              "wrapper": "http_redirect"
            },
            {
              "wrapper": "tls"
            }
          ],
          "metrics": {},
          "routes": [
            {
              "match": [
                {
                  "host": [
                    "registry.REDACTED"
                  ]
                }
              ],
              "handle": [
                {
                  "handler": "headers",
                  "response": {
                    "set": {
                      "Server": [
                        "REDACTED"
                      ]
                    }
                  }
                },
                {
                  "encodings": {
                    "gzip": {},
                    "zstd": {}
                  },
                  "handler": "encode",
                  "prefer": [
                    "zstd",
                    "gzip"
                  ]
                },
                {
                  "handler": "reverse_proxy",
                  "load_balancing": {
                    "selection_policy": {
                      "policy": "round_robin"
                    }
                  },
                  "upstreams": [
                    {
                      "dial": "<IP_ADDRESS>:18081"
                    }
                  ]
                }
              ],
              "terminal": true
            }
          ]
        }
      }
    },
    "tls": {
      "certificates": {
        "load_folders": [
          "/var/opt/caddy/certificates"
        ]
      },
      "automation": {
        "policies": [
          {
            "on_demand": true,
            "issuers": [
              {
                "email": "REDACTED",
                "module": "acme"
              },
              {
                "email": "REDACTED",
                "module": "zerossl"
              }
            ]
          }
        ],
        "on_demand": {
          "ask": "http://<IP_ADDRESS>:2223"
        }
      }
    }
  }
}

@T4cC0re Is there any particular error message? "A TLS connection is never established successfully" is not a lot to go on...

I think I know what's happening. The subroute is blocking on its prefetch call because the root route already fetched all bytes from the client. The compiled route in the subroute handler should probably not call prefetch if there is already some data available (at least not for the first matcher loop iteration). Sorry I overlooked this, I never actually tested the subroute handler.
@T4cC0re You can work around this by not using the subroute handler. You should be able to just copy your subroute "routes" to the root "routes".

The subroute is blocking on its prefetch call because the root route already fetched all bytes from the client.

This is exactly what happens. https://github.com/mholt/caddy-l4/pull/194 fixes it.

This is exactly what happens. #194 fixes it.

Can confirm. It works now :) Thanks for the quick turnaround!

Really appreciate your help @ydylla -- thank you!

@ydylla One more potential bug with this commit: have you considered the case where a TLS connection is wrapped? i.e.:
{
	"apps": {
		"layer4": {
			"servers": {
				"signal_proxy": {
					"listen": [
						":443"
					],
					"routes": [
						{
							"handle": [
								{
									"handler": "tls"
								}
							]
						},
						{
							"match": [
								{
									"tls": {
										"sni": [
											"chat.signal.org",
											"ud-chat.signal.org"
										]
									}
								}
							],
							"handle": [
								{
									"handler": "proxy",
									"upstreams": [
										{
											"dial": [
												"chat.signal.org:443"
											]
										}
									]
								}
							]
						},
						{
							"match": [
								{
									"tls": {
										"sni": [
											"storage.signal.org",
											"cdn.signal.org",
											"cdn2.signal.org",
											"cdn3.signal.org",
											"cdsi.signal.org",
											"contentproxy.signal.org",
											"uptime.signal.org",
											"sfu.voip.signal.org",
											"svr2.signal.org",
											"updates.signal.org",
											"updates2.signal.org",
											"backend1.svr3.signal.org",
											"backend2.svr3.signal.org",
											"backend3.svr3.signal.org"
										]
									}
								}
							],
							"handle": [
								{
									"handler": "proxy",
									"upstreams": [
										{
											"dial": [
												"{l4.tls.server_name}:443"
											]
										}
									]
								}
							]
						}
					]
				}
			}
		},
		"tls": {
			"certificates": {
				"automate": [
					"test-1.finerpixels.com"
				]
			}
		}
	}
}

A Signal proxy first terminates the "outer" layer of TLS, then with that encrypted tunnel, it sends an inner TLS connection. This config used to be able to match the ServerName (SNI) of the inner TLS connection without terminating it, but I noticed that with this change, it seems to try to terminate the inner connection.
Do you think you could help fix this? It appears to be a regression. (Sorry!)

@mholt I don't think the wrapping is the problem. It's likely my rather arbitrary choice of jumping back to the first route after a match instead of continuing. It was easier to code and seamed reasonable. If you add an "example.com" sni matcher to the first route with the tls handler it should work.
I will try to reproduce and fix it, should be possible. And don't worry I also want the stuff I write to work 😄

Oh you're good! I super appreciate your contributions (I've been stretched a bit thin lately.) Let me know if I can help at all. Thanks so much :sweat_smile:

@mholt #196 recreates the old matching behavior.
I spend the most time trying to come up with a command line that does TLS in TLS with curl, echo and openssl s_client but eventually I gave up. Turns out writing it in go was way easier 😅 . In case anyone also needs this:
package main

import (
	"crypto/tls"
	"log"
)

func main() {
	outerConn, err := tls.Dial("tcp", "<IP_ADDRESS>:10443", &tls.Config{
		ServerName:         "outer",
		InsecureSkipVerify: false,
	})
	if err != nil {
		log.Fatal(err)
	}

	innerConn := tls.Client(outerConn, &tls.Config{
		ServerName:         "inner",
		InsecureSkipVerify: false,
	})

	_, err = innerConn.Write([]byte("GET / HTTP/1.0\r\nHost: localhost\r\n\r\n"))
	if err != nil {
		log.Fatal(err)
	}
	buf := make([]byte, 1024)
	n, err := innerConn.Read(buf)
	if err != nil {
		log.Fatal(err)
	}
	println(string(buf[:n]))
}

Ah :sweat_smile: Thanks for working on that and posting your test program. I will review the patch soon!! Thank you!


Lineages should be directly added to plots, not saved as SVG

See information on how to do so here: https://stackoverflow.com/questions/17458580/embedding-small-plots-inside-subplots-in-matplotlib

I did it for figure 1, but I can't find a way to rotate the tree plots by 90 degrees like what we have right now. I had done it with the overlay_cartoon function. Any function I found that could rotate, needed an image. Would it be alright to keep the tree plots (cartoons) for figure 4 as it is right now? @aarmey


The three-dot menu on all cards is not findable by Katalon

v0.9.0 build c1bb71c. Three-dot menu has id for all the cards.


Add job updates helpers

Adding future components for job filtering.

These changes are not integrated into Moneo's workflow:

update job script: manages interactions with shared memory on the compute nodes
lock helper script: provides concurrency protection
Modified shared memory to support job update interactions
Updated test for shared memory module to make code cleaner
Created test for job update script

Custom.sh install file modified to install filelock package

addressing failed test


Make almost_eq return false if a and/or b is NaN

I feel like this might have been a typo because the docs say that almost_eq always returns false if either number is NaN. It also seems correct that almost_eq(NaN, x) is always false.

This is certainly more correct. However, I notice that there's some inconsistency with using prec::almost_eq and things coming from approx:: despite a type constraint to impl ::approx::RelativeEq<f64>
Would you be willing to write this method as simply a wrapper to appropriate call in approx? Perhaps,
a.abs_diff_eq(b, other)

A bigger ask would be to drop the requirement on approx which seems feasible.

I implemented the abs_diff_eq wrapper for now.

A bigger ask would be to drop the requirement on approx which seems feasible.

I agree, it seems feasible. Is there a particular reason for dropping the approx dependency though? It seems to be a widely-used crate and is pretty lightweight.

I see two areas needing fix, but the first would solve both issues

no handling of infinity, works if handled in
verifying that d.ln_pdf(x).abs_diff_approx_eq(d.pdf(x).ln(), prec) in internal::test_continuous which should be verifying that the relationship between cdf and pdf via integration from min domain to max domain.

I pushed the first here to fix, but perhaps it makes more sense to test ln_pdf accuracy elsewhere

Doesn't this code now return true for almost_eq(f64::INFINITY, f64::NEG_INFINITY, /* anything */)?

🤦🏼, thanks for catching.
I think I'm just getting antsy for the release and quickly merged the changes I pushed. I shouldn't be skipping the chance for peer review.
On a related note, do you mind if I push (no force) on your fork's branches that have open PRs? I didn't think to ask before, but it seems like a courtesy to request that permission.

perhaps
a == b || a.abs_diff_eq(&b, acc)

would be more appropriate.

I think I'm just getting antsy for the release and quickly merged the changes I pushed. I shouldn't be skipping the chance for peer review.

It's a small change which doesn't usually warrant a full review. It's just a mistake, and mistakes happen. No big deal.

On a related note, do you mind if I push (no force) on your fork's branches that have open PRs? I didn't think to ask before, but it seems like a courtesy to request that permission.

Thank you for asking, but I don't mind at all. I would've disabled it via GitHub if it did bother me.

a == b || a.abs_diff_eq(&b, acc)

Sure, that should work. Might read better as
if a.is_infinite() && b.is_infinite() {
  return a == b;
}

though.

It's just a mistake, and mistakes happen. No big deal.

Appreciate you saying that.

Might read better as
...

Ah, the intent is more explicit.