Pull vernacular and analysis language from flex project data

this would be similar to the entries count data. We would store it in the flex metadata table, and we want to make it searchable/queryable in some way.
Tasks:

[ ] pull language data from xml files in hg
[ ] display language data on project page
[ ] allow filtering projects by language data via graphql

Non tasks:

define UI in admin page to filter based on vernacular.

Related (dupe?): https://github.com/sillsdev/languageforge-lexbox/issues/844

Summary of discussion from #844:

Writing system data for FLEx projects is stored in the General/LanguageProject.langproj file.
We could get that without checking out the repo by doing hg cat -r tip General/LanguageProject.langproj
We could just grab the whole XML file (it's not that large) and parse it in .NET, ...
... Or we could extract just the parts we want so that we don't have to send too much data over the network by doing the following:

hg cat -r tip General/LanguageProject.langproj | sed -n -e '/<AnalysisWss>/,/<\/AnalysisWss>/p' -e '/<VernWss>/,/<\/VernWss>/p' -e '/<CurAnalysisWss>/,/<\/CurAnalysisWss>/p' -e '/<CurVernWss>/,/<\/CurVernWss>/p' -e '/<CurPronunWss>/,/<\/CurPronunWss>/p'

Then slap an opening and closing tag around that and parse it.
Either way, the writing system tags for each category are a space-separated list of strings.
Anything in CurPronunWss is also found in CurVernWss, so if you want only the non-pronunciation vernaculars then you'd take CurVernWss and subtract CurPronunWss.
It's unclear to me (yet) whether the CurVernWss vs. VernWss distinction is all that important. We could check against multiple current projects and find out.

One example of this data from a project I had lying around because I was debugging a Send/Receive issue:
<AnalysisWss>
    <Uni>en</Uni>
</AnalysisWss>
<CurAnalysisWss>
    <Uni>en</Uni>
</CurAnalysisWss>
<CurPronunWss>
    <Uni>qaa-fonipa</Uni>
</CurPronunWss>
<CurVernWss>
    <Uni>qaa-fonipa qaa</Uni>
</CurVernWss>
<VernWss>
    <Uni>qaa-fonipa qaa</Uni>
</VernWss>

So as you can see, CurVernWss - CurPronunWss would have left just qaa, which is the "Unknown" language. Which goes to illustrate that we won't always be able to extract the language from a FLEx project...

In #844 Tim said he thought we'd want to output the entire XML file and parse it in C#. That's feasible; I just checked on staging and found that most LanguageProject.langproj files were about 70 kilobytes in size, nearly all of that from the Anthropology Categories list that's included in most FLEx projects. (A FLEx project where that list has been omitted has a .langproj file of less than 2 kilobytes). If the project had lots of media files (whose filenames are listed in the .langproj file) then it was larger: I saw 100KB, 160KB, and one 200KB file.
Since it's a simple Unix one-liner (which also takes VERY little CPU time as it's not parsing XML, just doing simple string comparisons) to focus on just the writing system data and not transmit (or XML-parse) the rest of the file, thereby turning 70KB (or up to 200KB) into less than 1KB, I decided to go with the sed command to return only the XML elements we're interested in.

Oh, and one large project I looked at also proves that you don't always want "CurVernWss - CurPronunWss". It has CurPronunWss being just one writing system which I'll call xyz. The CurVernWss has xyz xyz-Latn-x-majority xyz-Zxxx-x-majority-audio xyz-Latn-x-minority1 xyz-Zxxx-x-minority1-audio xyz-Latn-x-minority2 xyz-Zxxx-x-minority2-audio. But the language code for that project should indeed be xyz.
So the logic we'll want is to just look at CurVernWss and find the language that is shared between all the tags. If there are more than one, we'll want to flag that somehow. Perhaps I'll write a one-time script that goes through every project on the database, throttled to do just one per second or something, and grabs just the CurVernWss list. Then I'll be able to find out how many of them, if any, have more than one writing system in the vernacular list. Hopefully that number will be zero, but let's find out.

Preliminary results from that research (all actual language codes except en and qaa have been replaced with xyz or aaa or bbb or similar in the list below):

Most projects do indeed have just one language code, and that language code usually matches the name of the project (e.g. a project named xyz-flex probably has xyz, xyz-Latn, and xyz-fonipa as vernacular writing systems).
Some projects have muiltiple writing systems in the vernacular list; one of them, for example, was named xyz-flex but had writing systems xyz xyz-fonipa xyz-Latn aaa bbb ccc en ddd-Latn and so on. But xyz was the majority and matched the language identified by the project code.
Some projects had analysis languages included in the vernacular list; one had en xyz qaa-fonipa-x-xyz-etic but the analysis languages list was just en. For that one, xyz would be the better choice, although in fact I could tell that this project was not about the xyz language and that would have been misidentified. But in this particular case there was nothing in the data that would have identified the language correctly. Another had aaa xyz as vernacular tags, and en aaa as analysis tags. (Also, aaa was listed in CurPronunWss, and it turned out that indeed, aaa was being used as the language tag to record, in the lexeme field, how the word was pronounced.)
Some projects had language tags that did not match the project code, e.g. one language tag xxy had a project code named xyy-flex. The name made it clear that xxy was the correct tag, and it turns out that there was already an xxy-flex project which is likely why the xyy-flex project was created, with a project code that was close but not quite correct. The language tag in the CurVernWss list was correct, though. I've also seen xy in the vern list with xyz in the project code, and when I looked it up, xy was the correct two-letter tag for xyz. So if comparing tags to project code segments to confirm a guess, normalizing 2-to-3 segments might be a good idea first.
There are a number of xyz1-flex-gial, xyz2-flex-gial, ..., xyz11-flex-gial projects. It seems likely that any project code ending in flex-gial or flex-diu is a training project. When we do project cleanup, we may want to archive those in a deep-freeze type of backup (so they can be restored if anyone actually wants them) and then delete them from the live server. That's unrelated to the language-identifying task, but it's worth noting.
Some projects named xyz-flex had only qaa-x-xyz and qaa-x-xyz-Latn as vernacular tags. If the vernacular language gets identified as qaa (the official "Unknown language" tag), but there's a qaa-x-xyz where there are exactly three letters after the x- and those three letters match the project code, it's worth guessing with medium confidence that that's the language. (I've also seen qaa-Latn-US-x-xyz and xyz would turn out to be the correct language tag even though it wasn't in the project code.
Some projects had project code aaa-bbb-flex and it turned out that bbb was the vernacular.

But all those problems were rare. By far the vast majority had vernacular lists that were either a single xyz, or a short list like xyz-fonipa-x-emic xyz-x-variatio xyz qaa-fonipa-x-enIPA.

Conclusions:

If there's just one language in the list, there's no need to guess. If there are multiple, we might need to guess.
We may want to strip analysis langs out of the vernacular list before guessing the language
We may want to assign confidence levels to langauge determinations: High, Medium, and Low, for example.

High could be for "just one language in the list", Medium for "one language left after stripping analysis languages out", Low for "more than one language in the list and stripping analysis languages out didn't help, so we guessed based on which one was first".

We may want to split the project code into hyphen-delimited segments, discarding a -flex part at the end, and assign higher confidence to any tag also located in part of the project code.

Decision made at design meeting today: language data that we'll display will be the raw list of tags, with the default vernacular (and default analysis, if we display that) highlighted or bolded.
We've decided to add an isDefault boolean to the object we store in JSON, following the rules of the FLEx data: the first one in the vernacular/analysis list is the default one for that list. The frontend will then be able to apply styles based on whether isDefault is truthy.

GraphQL queries for writing systems on projects will get a little verbose, but they work:
query Example {
    projects(where: {flexProjectMetadata: {writingSystems: {analysisWss: {some: {tag: {eq: "en"}}}}}}) {
        id
        code
        flexProjectMetadata {
            writingSystems {
                analysisWss {
                    tag
                    isActive
                    isDefault
                }
            }
        }
    }
}


Add to_dict method for Template.

The change itself appears to an elegant way to get a dictionary output, but there is a problem.
I took a stab at creating a test for the to_dict() method. It is a simplistic hack of the test_exclusive test in test_dict.py. What I was going for is "dict_in -> troposphere.objects -> dict_out, assertDictEquals(dict_in, dict_out)".
Here is the code:
    def test_exclusive_dict(self):
        d = {
            "Cpu": 1,
            "Environment": [
                {
                    "Name": "REGISTRY_STORAGE",
                    "Value": "s3"
                },
                {
                    "Name": "REGISTRY_STORAGE_S3_REGION",
                    "Value": "eu-west-1"
                }
            ],
            "Essential": True,
            "Image": "registry:2",
            "Memory": 500,
            "Name": "registry",
            "PortMappings": [
                {
                    "ContainerPort": 5000,
                    "HostPort": 5000
                },
                {
                    "ContainerPort": 5001,
                    "HostPort": 5001
                }
            ]
        }

        t = Template()
        cd = ecs.ContainerDefinition.from_dict("mycontainer", d)
        td = ecs.TaskDefinition(
                "taskdef",
                ContainerDefinitions=[cd],
                Volumes=[ecs.Volume(Name="myvol")],
        )
        t.add_resource(td)
        d_out = t.to_dict()
        self.assertDictEqual(d, d_out)

And here is the failed output:
FAIL: test_exclusive_dict (tests.test_dict.TestDict)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/raulcuza/dev/rac/troposphere/tests/test_dict.py", line 84, in test_exclusive_dict
    self.assertDictEqual(d, d_out)
AssertionError: {'PortMappings': [{'ContainerPort': 5000, 'HostPort': 5000}, {'ContainerPort': 5 [truncated]... != {'Resources': {'taskdef': <troposphere.ecs.TaskDefinition object at 0x10f40bbd0> [truncated]...
+ {'Resources': {'taskdef': <troposphere.ecs.TaskDefinition object at 0x10f40bbd0>}}
- {'Cpu': 1,
-  'Environment': [{'Name': 'REGISTRY_STORAGE', 'Value': 's3'},
-                  {'Name': 'REGISTRY_STORAGE_S3_REGION', 'Value': 'eu-west-1'}],
-  'Essential': True,
-  'Image': 'registry:2',
-  'Memory': 500,
-  'Name': 'registry',
-  'PortMappings': [{'ContainerPort': 5000, 'HostPort': 5000},
-                   {'ContainerPort': 5001, 'HostPort': 5001}]}

----------------------------------------------------------------------
Ran 194 tests in 0.267s

FAILED (failures=1)

If my test is correct, and I am not sure that it is correct, then it appears to be saying this change wont work. The troposphere objects deeper in the template object are not getting translated to dictionary objects.

As is, this doesn't look good to me. 👎

You could cheat by doing this:
def to_dict(self):
    return json.loads(self.to_json())

but that's kind of dirty :)

@wt Any chance you've gotten to look @ @rcuza 's comments?  It also appears that this now has conflicts with other more recent changes.


Gmail SMTP is not working on Laravel 8.12 (Swift_TransportException)

Laravel Version: 8.12
PHP Version: 8.0.0
Database Driver & Version: MySql 8.0

Description:
I have deployed an app using gmail smtp details but getting this error Expected response code 250 but got code "555", with message "555 5.5.2 Syntax error. 60sm7783050qth.14 - gsmtp. I really don't know if this is a bug or not.
Steps To Reproduce:
.env
MAIL_MAILER=smtp
MAIL_HOST=smtp.googlemail.com OR  smtp.gmail.com
MAIL_PORT=465
<EMAIL_ADDRESS>MAIL_PASSWORD=<GeneratedAppCode>
MAIL_ENCRYPTION=ssl
<EMAIL_ADDRESS>MAIL_FROM_NAME="${APP_NAME}"

app/Http/Controllers/ContactController.php
<?php

namespace App\Http\Controllers;

use App\Mail\ContactUs;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Mail;

class ContactController extends Controller
{

    public function contact()
    {
        Mail::to('********@gmail.com')->send(new ContactUs(\request()->all()));

        if (\request()->wantsJson()) return \response()->json(['success' => Mail::failures()]);
    }
}

app/Mail/ContactUs.php
<?php

namespace App\Mail;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Mail\Mailable;
use Illuminate\Queue\SerializesModels;

class ContactUs extends Mailable
{
    use Queueable, SerializesModels;

    protected $data;

    /**
     * Create a new message instance.
     *
     * @return void
     */
    public function __construct($data)
    {
        $this->data = $data;
    }

    /**
     * Build the message.
     *
     * @return $this
     */
    public function build()
    {
        $name = \join(' ', [$this->data['first_name'], $this->data['last_name']]);
        return $this
            ->withSwiftMessage(function ($message) use ($name) {
                $headers = $message->getHeaders();
                $headers->addTextHeader('Reply-To', $name . " <{$this->data['email']}>");
                $headers->addTextHeader('Return-Path', 'App Name <no-reply@*********.com>');
                $headers->addTextHeader('Organization', 'App Name');
            })
            ->subject("{$this->data['first_name']} want's to know something")->markdown('emails.contact')->with($this->data);
    }
}

Request Exception

{
    "message": "Expected response code 250 but got code \"555\", with message \"555 5.5.2 Syntax error. 60sm7783050qth.14 - gsmtp\r\n\"",
    "exception": "Swift_TransportException",
    "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php",
    "line": 460,
    "trace": [
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php",
            "line": 345,
            "function": "assertResponseCode",
            "class": "Swift_Transport_AbstractSmtpTransport",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/EsmtpTransport.php",
            "line": 305,
            "function": "executeCommand",
            "class": "Swift_Transport_AbstractSmtpTransport",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php",
            "line": 393,
            "function": "executeCommand",
            "class": "Swift_Transport_EsmtpTransport",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php",
            "line": 500,
            "function": "doDataCommand",
            "class": "Swift_Transport_AbstractSmtpTransport",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php",
            "line": 519,
            "function": "doMailTransaction",
            "class": "Swift_Transport_AbstractSmtpTransport",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php",
            "line": 206,
            "function": "sendTo",
            "class": "Swift_Transport_AbstractSmtpTransport",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Mailer.php",
            "line": 71,
            "function": "send",
            "class": "Swift_Transport_AbstractSmtpTransport",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Mail/Mailer.php",
            "line": 521,
            "function": "send",
            "class": "Swift_Mailer",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Mail/Mailer.php",
            "line": 288,
            "function": "sendSwiftMessage",
            "class": "Illuminate\\Mail\\Mailer",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Mail/Mailable.php",
            "line": 186,
            "function": "send",
            "class": "Illuminate\\Mail\\Mailer",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Support/Traits/Localizable.php",
            "line": 19,
            "function": "Illuminate\\Mail\\{closure}",
            "class": "Illuminate\\Mail\\Mailable",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Mail/Mailable.php",
            "line": 187,
            "function": "withLocale",
            "class": "Illuminate\\Mail\\Mailable",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Mail/Mailer.php",
            "line": 304,
            "function": "send",
            "class": "Illuminate\\Mail\\Mailable",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Mail/Mailer.php",
            "line": 258,
            "function": "sendMailable",
            "class": "Illuminate\\Mail\\Mailer",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Mail/PendingMail.php",
            "line": 121,
            "function": "send",
            "class": "Illuminate\\Mail\\Mailer",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/app/Http/Controllers/ContactController.php",
            "line": 14,
            "function": "send",
            "class": "Illuminate\\Mail\\PendingMail",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Controller.php",
            "line": 54,
            "function": "contact",
            "class": "App\\Http\\Controllers\\ContactController",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/ControllerDispatcher.php",
            "line": 45,
            "function": "callAction",
            "class": "Illuminate\\Routing\\Controller",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Route.php",
            "line": 254,
            "function": "dispatch",
            "class": "Illuminate\\Routing\\ControllerDispatcher",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Route.php",
            "line": 197,
            "function": "runController",
            "class": "Illuminate\\Routing\\Route",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
            "line": 692,
            "function": "run",
            "class": "Illuminate\\Routing\\Route",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 128,
            "function": "Illuminate\\Routing\\{closure}",
            "class": "Illuminate\\Routing\\Router",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Middleware/SubstituteBindings.php",
            "line": 41,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Routing\\Middleware\\SubstituteBindings",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php",
            "line": 78,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Foundation\\Http\\Middleware\\VerifyCsrfToken",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/View/Middleware/ShareErrorsFromSession.php",
            "line": 49,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\View\\Middleware\\ShareErrorsFromSession",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php",
            "line": 121,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php",
            "line": 63,
            "function": "handleStatefulRequest",
            "class": "Illuminate\\Session\\Middleware\\StartSession",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Session\\Middleware\\StartSession",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/AddQueuedCookiesToResponse.php",
            "line": 37,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Cookie\\Middleware\\AddQueuedCookiesToResponse",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php",
            "line": 67,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Cookie\\Middleware\\EncryptCookies",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 103,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
            "line": 694,
            "function": "then",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
            "line": 669,
            "function": "runRouteWithinStack",
            "class": "Illuminate\\Routing\\Router",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
            "line": 635,
            "function": "runRoute",
            "class": "Illuminate\\Routing\\Router",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
            "line": 624,
            "function": "dispatchToRoute",
            "class": "Illuminate\\Routing\\Router",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php",
            "line": 166,
            "function": "dispatch",
            "class": "Illuminate\\Routing\\Router",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 128,
            "function": "Illuminate\\Foundation\\Http\\{closure}",
            "class": "Illuminate\\Foundation\\Http\\Kernel",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TransformsRequest.php",
            "line": 21,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Foundation\\Http\\Middleware\\TransformsRequest",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TransformsRequest.php",
            "line": 21,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Foundation\\Http\\Middleware\\TransformsRequest",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/ValidatePostSize.php",
            "line": 27,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Foundation\\Http\\Middleware\\ValidatePostSize",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/PreventRequestsDuringMaintenance.php",
            "line": 86,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Illuminate\\Foundation\\Http\\Middleware\\PreventRequestsDuringMaintenance",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/fruitcake/laravel-cors/src/HandleCors.php",
            "line": 37,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Fruitcake\\Cors\\HandleCors",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/fideloper/proxy/src/TrustProxies.php",
            "line": 57,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 167,
            "function": "handle",
            "class": "Fideloper\\Proxy\\TrustProxies",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
            "line": 103,
            "function": "Illuminate\\Pipeline\\{closure}",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php",
            "line": 141,
            "function": "then",
            "class": "Illuminate\\Pipeline\\Pipeline",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php",
            "line": 110,
            "function": "sendRequestThroughRouter",
            "class": "Illuminate\\Foundation\\Http\\Kernel",
            "type": "->"
        },
        {
            "file": "/home/theresumeologist/dev.theresumeologist.com/public/index.php",
            "line": 52,
            "function": "handle",
            "class": "Illuminate\\Foundation\\Http\\Kernel",
            "type": "->"
        }
    ]
}

Mail Working fine with swiftmailer
composer.json

{
    "require": {
        "swiftmailer/swiftmailer": "^6.0"
    }
}

index.php

<?php
require_once 'vendor/autoload.php';

try {
    // Create the Transport
    $transport = (new Swift_SmtpTransport('smtp.googlemail.com', 465, 'ssl'))
<EMAIL_ADDRESS>      ->setPassword('<AppGeneratedPassword>');

    // Create the Mailer using your created Transport
    $mailer = new Swift_Mailer($transport);

    // Create a message
    $body = 'Hello, <p>Email sent through <span style="color:red;">Swift Mailer</span>.</p>';

    $message = (new Swift_Message('Email Through Swift Mailer'))
<EMAIL_ADDRESS>=> '<Sender Name>'])
<EMAIL_ADDRESS>      ->setBody($body)
      ->setContentType('text/html');

    // Send the message
    $mailer->send($message);

    echo 'Email has been sent.';
} catch(Exception $e) {
    echo $e->getMessage();
}

You need to configure your Google account to allow "Less Secure Access"

You need to configure your Google account to allow "Less Secure Access"

Check this out:
https://stackoverflow.com/questions/4321346/555-5-5-2-syntax-error-gmails-smtp
Check if your $name ends up being filled up. Maybe it is empty then the Reply-To ends up invalid to GMail.
Also your simplified script using only SwiftMailer is missing these headers:
$headers->addTextHeader('Reply-To', $name . " <{$this->data['email']}>");
$headers->addTextHeader('Return-Path', 'App Name <no-reply@*********.com>');
$headers->addTextHeader('Organization', 'App Name');

Check this out:
https://stackoverflow.com/questions/4321346/555-5-5-2-syntax-error-gmails-smtp
Check if your $name ends up being filled up. Maybe it is empty then the Reply-To ends up invalid to GMail.
Also your simplified script using only SwiftMailer is missing these headers:
$headers->addTextHeader('Reply-To', $name . " <{$this->data['email']}>");
$headers->addTextHeader('Return-Path', 'App Name <no-reply@*********.com>');
$headers->addTextHeader('Organization', 'App Name');

Hi there,
Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!
Thanks.

Hi there,
Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!
Thanks.


Make the app responsive

So that we can access the app on mobile

Make the tabs responsive
(Settings are already responsive)

change mui to headless ui for the tabs if migration to tailwind done


Jetpants sharded_tables example in configuration needs further nesting.

https://github.com/tumblr/jetpants/blob/master/etc/jetpants.yaml.sample#L46-L59
The example results in errors  when doing a shard cutover, digging reveals it should probably be:
sharded_tables:
    shardname:
        tablename:
            sharding_key: user_id
            chunks: 200

Good catch. The example is just out-of-date. Looks like it wasn't updated to reflect support for multiple shard pools. ("shardname" in your example should be more like "shard_pool_name")

I thought that might be the case, but wasn't so sure :)


[output] Adding support to add notes to incidents

to: @ryandeivert or @jacknagz
cc: @airbnb/streamalert-maintainers
size: small
Background
When creating incidents it may be helpful to add a note with a bit of context of what has happened or an action taken. This adds support for creating a note to a given incident.
Changes

Added ability to create a text note given an incident id.
Added unit tests for the code.

Testing
$ rm .coverage && ./tests/scripts/unit_tests.sh
...
----------------------------------------------------------------------
Ran 533 tests in 9.331s

OK

$ ./tests/scripts/pylint.sh

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

$ python manage.py lambda test --processor rule all
...
StreamAlertCLI [INFO]: (60/60) Successful Tests
StreamAlertCLI [INFO]: (93/93) Alert Tests Passed
StreamAlertCLI [INFO]: Completed

Coverage increased (+0.02%) to 95.42% when pulling f625372fdd276232b04234ba02e45da00e324f58 on javier-streamalert-pagerduty-note into 0bb9ae2b75f0ce9791180eb15b73fd20bf4157e3 on master.


Auto-Update to version 0.12.1

This is an automated issue created by the auto-update workflow following up a new Release of CLIc.
Release Information

Release Tag: 0.12.1
Changelog: View Changelog

Please review the changes and update the dependencies accordingly.

This is an automated issue created by the auto-update workflow following up a new Release of CLIc.
Release Information

Release Tag: 0.12.1
Changelog: View Changelog

Please review the changes and update the dependencies accordingly.


feat(config): add pprof global config support

Implements #705
I've tested both port and host as working on my cluster against a custom docker image with these changes.

Single comment about the code logic. Don't you think it could be cool to expose this port in the containers and in the service too ? It would make it easier to reach the pprof endpoint.

Let me take a look at what's involved. Since the temporal-config config map is used by the frontend, matching, history, and worker pods, are you proposing that it to be exposed as a containerPort on those pods?

@alexandrevilain added auto containerPort creation. I've tested it locally against the dev cluster. The pprof port is automatically created for the service pod deployments, I can port-forward and connect :+1:
One thing I couldn't figure out was how to prevent a nil host from appearing in the ConfigMap when only a port is specified in the 02-...yaml config. It generates ConfigMap yaml with host: "" despite the host being a *string and optional json parameter. Do you know if I'm doing something wrong there? The system correctly assigns a host of "localhost" in that situation (the default in Temporal).

One thing I couldn't figure out was how to prevent a nil host from appearing in the ConfigMap

I figured it out. It's because the Temporal PProf struct that I'm instantiating does not consider Host optional. This is expected behavior.

Thanks! I'll take a look and turn this around ASAP.

you can set default values
I was trying to avoid setting default values since Temporal sets them itself. That way if they ever decide to change the defaults, no code change would be required.

Hi @clayzermk1 !
Do you need any help ?

Hi @alexandrevilain,
Sorry for the slow turn, I've been reassigned to a different project. I'm not sure when I'll get back around to this.

I received permission to work on this. I should be able to pick it up in a week or so :+1:

Still on the radar.


Logs out every time app is quit

Logs out every time app is quit

Just tick the settings to remember me when logging in.
Please try our latest beta. See https://github.com/Aluxian/Facebook-Messenger-Desktop/issues/458


Using environment variable to customize env

Hi @stakach,
The actual way to customize environment (change hostname or port for example) is don e by the command line (adding an option)
https://github.com/spider-gazelle/spider-gazelle/blob/8d37f5ecedaf181ad114d72c54f9c8933c542772/Dockerfile#L23
It could be accurate to use environment variable for that, this is a kind of standard usage for frameworks (across many language)
What do you think ?
Regards,

Yeah I could add environment variable support for those.
Command line options are nice for development.

fixed in e24e068cdd9ebebd081eb5ce84881e93b17dfebf

@stakach I see SG_SERVER_PORT and SG_SERVER_HOST in https://github.com/spider-gazelle/spider-gazelle/commit/e24e068cdd9ebebd081eb5ce84881e93b17dfebf, but what about -w in https://github.com/the-benchmarker/web-frameworks/blob/master/crystal/spider-gazelle/Dockerfile#L11 ?

Ahh sorry, I've added that too: SG_PROCESS_COUNT

Thanks :tada:


lack of resending in part6

in part6 (dst address in our table, so we will forward the packet according to the table, and install a new flow entry to the switch).
However, you only install a new flow entry to the switch and did not resend this packet which fire the event to the cooresponding destination. :)

I think this is incorrect, and we actually do resend the packet.  Resending the packet is given as step 6a, and line 173/181 is commented with "6a".  This line sets the ofp_flow_mod's .data attribute to the incoming ofp_packet_in.  If you look at the OpenFlow spec, you'll see that this isn't actually part of OpenFlow.  This is a POXism.
ofp_flow_mod allows one to instruct the switch to apply a buffered packet to a new table entry by referring to the packet by its buffer_id in an ofp_flow_mod.  In other words, if the packet has been buffered on the switch, setting an ofp_flow_mod's buffer_id to the packet's ID should resend the packet when the new table entry is installed.
However, if the packet isn't buffered at the switch, the above doesn't work.  In that case, you have to resend the packet via an ofp_packet_out, if and only if the switch had actually sent you the whole packet and not a truncated packet.
It's annoying having to deal with the three different cases, so POX's ofp_flow_mod can actually handle it for you, and l2_learning uses this.  If you set an ofp_flow_mod's .data to an ofp_packet_in which has a buffer_id, then the ofp_flow_mod will use that to resend the packet.  If it doesn't have a buffer_id, but it has a complete packet payload, it will actually also magically pack an ofp_packet_out to resend the packet data.  Otherwise, it won't resend the packet, because it can't (the code in your patch would actually fail an assertion in this case... it should actually probably just log a warning, but that didn't used to be possible... this is now fixable, actually...).
In an older version of POX, it didn't do this.  Originally, l2_learning could only resend the packet if it was buffered, which is the behavior NOX had.  You can see the changes in e2f5975f38ecb1a20c4427a56b43c7cba31cfbb5 and  dd0907e3c8b85671b6a157a4f07f0559db9baec2.
So unless there's a bug, I think the behavior in the existing code should be correct, and this patch is unnecessary, has unhandled edge cases, and will potentially cause problems due to POX's magic ofp_flow_mod.data.
So I'm going to close this PR.  If you have empirical evidence that the existing code doesn't actually work right, please provide it in a new issue or reopen the PR!
(On the other hand, the magic ofp_flow_mod.data might not actually appear in the POX manual, which would certainly be a documentation bug!)

Thanks , got it


[REGISTRAR] update inter-account domain move instructions

Summary
This PR updates the inter-account domain registration move instructions to include a description of the self-serve option.
Documentation checklist

[X] The documentation style guide has been adhered to.

@dcpena thank you for your review -- I just made all changes you requested, if you'd like to have another look


Is there a way to handle post requests?

I did not see an example on generating code for post requests. Is that not implemented yet?

the answer is yes.
@Require.post("/routename")

Feel free to make a PR with an update to the example/main.dart, if you have a hard time figuring it out maybe others do too..


append comma when necessary to the EtcdNodes range

Fixes #1303

Codecov Report

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

@@           Coverage Diff           @@
##           master    #1305   +/-   ##
=======================================
  Coverage   37.79%   37.79%
=======================================
  Files          67       67
  Lines        4231     4231
=======================================
  Hits         1599     1599
  Misses       2408     2408
  Partials      224      224

Continue to review full report at Codecov.

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

LGTM, as I commented in the original issue. Thank you so much for your effort!


Nightly does not bundle wasi-libc.a

When building wasm platforms, we link in wasi-libc.a. This currently only works if you built the compiler from source. We should make this also just work when compiling with nightlies.
Should be a matter of include wasi-libc.a in the nightlies and then setting WASI_LIBC_PATH correctly. I believe it currently comes from an environment variable or default path.

https://github.com/roc-lang/roc/issues/6029

Completed by #6834


[r] [RFC] Build against shared library libtiledbsoma

Issue and/or context:

Top-level issue: #1277
Split-out for Mac/CI issues: #1293
This PR is a continuation of #1280

Changes:
Here is my understanding of how TileDB-SOMA-R install with libtiledbsoma works, on Linux and Mac, before and after this PR.
Before
All relative to the apis/r directory. (Some minor details omitted for brevity.)

Install R: CI tools/r-ci.sh bootstrap
Install this package's R dependencies: CI tools/r-ci.sh install_all

That includes the TileDB-R package which will in turn depends on TileDB core

copy_source.sh:

Copy ../../libtiledbsoma to ./src/libtiledbsoma

R build/install

Invoked by:

R CMD build --no-build-vignettes --no-manual
R CMD check --no-vignettes --no-manual tiledbsoma_*.tar.gz
R CMD INSTALL --no-test-load --no-docs --no-html tiledbsoma_*.gz

Callback files into our package include configure and src/Makevars.in

See also https://cran.r-project.org/doc/manuals/R-exts.html for reference

Note that we need core with include/tiledb/tiledb et al., and lib/libtiledb.so or lib/libtiledb.dylib
Note that we need libtiledbsoma with include/tiledbsoma/tiledbsoma et al., and lib/libtiledbsoma.so or lib/libtiledbsoma.dylib
Our configure is called

It uses pkg-config to see if the core library exists (nominally in /usr/local)
If not it uses the tools/get_tarball.R script to put core into ./inst/include and ./inst/lib
It checks for copy_source.sh having copied ../../libtiledbsoma source into src/libtiledbsoma
It runs cmake with -DTILEDBSOMA_BUILD_R=ON to install a static libtiledbsoma.a into the current directory
It runs a sed on our src/Makevars.in to create src/Makevars with the discovered path to the core library

Our src/Makevars (which is a Makefile) is invoked

Its job is to create a tiledbsoma.so which is created and managed by the R build infrastructure
Its -I and -L were just computed above
It invokes install_name_tool to set an rpath if the core library is at inst/tiledb/lib/libtiledb.dylib, updating the R-infra's tiledbsoma.so

After

Install R: same
Install this package's R dependencies: same
There is no more copy_source.sh
Instead, from ../.., scripts/bld --prefix=/usr/local

This means libtiledbsoma.so or libtiledbsoma.dylib is now found in /usr/local/lib and not relative to the current directory as it was before

R build/install

Note that we still need core with include/tiledb/tiledb et al., and lib/libtiledb.so or lib/libtiledb.dylib
Note that we still need libtiledbsoma with include/tiledbsoma/tiledbsoma et al., and lib/libtiledbsoma.so or lib/libtiledbsoma.dylib
Our configure is called

It uses pkg-config to see if the core library exists (nominally in /usr/local)
If not it uses the tools/get_tarball.R script to put core into ./inst/include and ./inst/lib
It doesn't do anything about libtiledbsoma which was already installed to /usr/local

Our src/Makevars (which is a Makefile) is invoked

It invokes install_name_tool to set an rpath for /usr/local/lib/libtiledylib.so (or .dylib) updating the R-infra's tiledbsoma.so

Notes for reviewer:

The install prefix /usr/local/ for libtiledbsoma is hard-coded src/Makevars.in because it is hard-coded in scripts/bld --prefix=/usr/local. This could be made programmable in both places.
Also note what we do in Python:

The paths to the core libtiledb and the libtiledbsoma can, either or both, be passed in to setup.py
https://github.com/single-cell-data/TileDB-SOMA/blob/1.2.2/apis/python/setup.py#L43-L72

We can probably turn all other CI yaml files off til the R file behaves.  I have been musing about this but have no good ideas yet ... but does the create libtiledbsoma.so look right on your local machine?   If the link failed it can either have been made wrong (but we trust cmake) or is use wrong (but it is a standard R build).  Or maybe the macOS build env?
Very annoying problem and thanks for digging!

@eddelbuettel I'm just debugging, some outside of CI and some (here) inside of CI. Nothing to announce yet.
I don't get a usable install on my Mac.

@eddelbuettel CI does need to pass. This is just temporary debug. An issue I'm seeing with #1280 is R Mac CI fails, and R Linux CI gets cancelled. What I'm testing right now is if we skip R Mac CI, will R Linux CI succeed or fail.

@johnkerl It should not surprise you but I am aware as it after first failed in my branch and PR.  I just tried to help, given that you continue to work on very public branches everybody can see.  And comment on.

@eddelbuettel I understand and appreciate it! Just trying to figure some things out, as I can, and to help out as requested. No clear answers yet ...

I just had to be on my bicycle for a bit to run an errand and the best I idea I had was that we may need an install_name_tool statement for the SOMA library just as we do for tiledb.  In src/Makevars{,.in} we have
	if [ "$(OS)" != "Windows_NT" ] && [ `uname -s` = 'Darwin' ] && [ -f ../inst/tiledb/lib/libtiledb.dylib ] && [ -f tiledbsoma.so ]; then install_name_tool -change libz.1.dylib @rpath/libz.1.dylib ../inst/tiledb/lib/libtiledb.dylib; install_name_tool -add_rpath @loader_path/../tiledb/lib tiledbsoma.so; fi

Here the final part is
install_name_tool -add_rpath @loader_path/../tiledb/lib tiledbsoma.so

which AFAIK tells the tiledbsoma.so (which was just built by R invoking R CMD COMPILE and R CMD SHLIB behind the scenes for us) to respect the path ../tiledb/lib as a dynamic linker load path.  Maybe we have to do the same for the location of libtiledbsoma.so which (currently) gets copied into /usr/local/lib.
But that is mere speculation on my part. I never use macOS and honestly do not know the ins and outs.  We need a macHead to look at this.

But that is mere speculation on my part. I never use macOS and honestly do not know the ins and outs. We need a macHead to look at this.

@eddelbuettel I have a Mac (more than one) & am looking into this yesterday & today as my first (although not only) priority. I'm doing cross-compares between a bare EC2 Linux instance (no tiledb-dev anything), and my personal/non-work Mac which also has no tiledb-dev anything.
I've gotten as much signal out of CI as I'm willing to -- having side-by-side repros on two systems which I can actually log into is proving to be slow, but fruitful.
This PR isn't ready for review -- it's a trial balloon which has served its job -- but progress is being made.

I'll just keep it here because we have to keep it somewhere.
What may help is the equivalent of
 ldconfig -p

which on Linix tells us what the dynamic linker knows, and it knows libtiledbsoma (after sudo ldconfig):
edd@rob:~$ sudo ldconfig -p|grep "tiledb.*\.so"$
        libtiledbsoma.so (libc6,x86-64) => /usr/local/lib/libtiledbsoma.so
        libtiledb.so (libc6,x86-64) => /usr/local/lib/libtiledb.so
edd@rob:~$

and on the other end to ask the shared library created by R about what it needs:
edd@rob:~/git/tiledb-soma/apis/r(de/sc-28200/shared_soma_lib)$ ldd src/tiledbsoma.so | grep tiledb
        libtiledbsoma.so => /usr/local/lib/libtiledbsoma.so (0x00007f69b1279000)
        libtiledb.so.2.16 => /usr/local/lib/libtiledb.so.2.16 (0x00007f69afe00000)
edd@rob:~/git/tiledb-soma/apis/r(de/sc-28200/shared_soma_lib)$

This happens to match here, so it builds.  We probably need some macOS help to get to the same two steps (?) in order to get to the build.

I see no R build under CI.  Am I looking in the wrong place?

Solved; re-opening as RFC with @ihnorton

Solved late last night as noted in this PR's (now-updated) description field; re-opening as RFC with @ihnorton

Sorry, I am dense. What is solved, and where, and by which change?

@eddelbuettel what is solved is that this now installs on Mac
The reason for altering the existing line is detailed in the now-upated description field at the top of this PR
This PR is an RFC -- if we need another install_rpath line for the core library, that's feedback I'd like to get from you or @ihnorton

I believed I had clean R CI last night.
My apologies; back into draft for the moment.

(And I certainly had green Ubuntu CI before my rebase, so I'll start by fixing my rebase.)

I believed I had clean R CI last night.

It was late, and I may have been mistaken.
I'll fix my recent issues and circle back.
Sorry to disrupt.

No worries!  It is frustrating when the tools get in the way and I really appreciate you are digging at this and have some hopeful smoke signals from the local deployment.

@nguyenv @eddelbuettel after rebasing on #1301 here is the error I'm now seeing in CI
https://github.com/single-cell-data/TileDB-SOMA/actions/runs/4831511064/jobs/8609059765?pr=1302
which I can also reproduce on an EC2 Linux instance.
Recall from the description section of this PR that the distillation of the build validation, with the changes on this PR, is simply:
scripts/bld --prefix=/usr/local/tiledbsoma
cd apis/r
R CMD build --no-build-vignettes --no-manual .
# Also R CMD check ... and R CMD INSTALL ... but this R CMD build step is where we see fails

As noted at https://github.com/single-cell-data/TileDB-SOMA/pull/1301#issuecomment-1527776132 we no longer have span/span.hpp included in the libtiledbsoma install output.
This means that the R CMD build --no-build-vignettes --no-manual . promptly fails with
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG -I. -I../inst/include/ -I/usr/local/tiledbsoma/include -I../inst/tiledb/include -I -DR_BUILD  -Iinclude -I'/usr/lib/R/site-library/Rcpp/include' -I'/usr/lib/R/site-library/RcppSpdlog/include'     -fpic  -Wno-deprecated-declarations -Wno-deprecated -c RcppExports.cpp -o RcppExports.o
In file included from /usr/local/tiledbsoma/include/cli/arrow_adapter.h:5,
                 from /usr/local/tiledbsoma/include/tiledbsoma/tiledbsoma:45,
                 from ../inst/include/tiledbsoma_types.h:7,
                 from RcppExports.cpp:4:
/usr/local/tiledbsoma/include/cli/../utils/column_buffer.h:38:10: fatal error: span/span.hpp: No such file or directory
   38 | #include <span/span.hpp>
      |          ^~~~~~~~~~~~~~~

which is entirely reasonable since span/span.hpp is quite simply not available.

@eddelbuettel now I'm getting an R CI fail on Ubuntu.
Can you take a look?

Can you take a look?

Hm.  Build no longer likes or finds the library:
libtiledbsoma.so: cannot open shared object file: No such file or directory

Not sure why.

I took a bit of a (in hindsight: pointless as failed) detour trying the 'let me compile a quick cmdline program in CI' (which failed over tiledb core not being installed right / pkg-config failing) but with that removed I seem to now be back in good graces.  This run just passed tests.  It still fails in coverage but it did that earlier and I am just going to 'park' that too.
The macOS side still has blood in the water:
ld: warning: object file (RcppExports.o) was built for newer macOS version (12.0) than being linked (10.14)
ld: warning: object file (rinterface.o) was built for newer macOS version (12.0) than being linked (10.14)
ld: warning: object file (nanoarrow.o) was built for newer macOS version (12.0) than being linked (10.14)
ld: warning: object file (riterator.o) was built for newer macOS version (12.0) than being linked (10.14)
ld: warning: object file (rutilities.o) was built for newer macOS version (12.0) than being linked (10.14)
ld: warning: object file (stats.o) was built for newer macOS version (12.0) than being linked (10.14)
ld: warning: object file (version.o) was built for newer macOS version (12.0) than being linked (10.14)
ld: warning: dylib (/Library/Frameworks/R.framework/R) was built for newer macOS version (11.0) than being linked (10.14)
ld: warning: dylib (/usr/local/lib/libtiledbsoma.dylib) was built for newer macOS version (12.6) than being linked (10.14)
if [ "" != "Windows_NT" ] && [ `uname -s` = 'Darwin' ] && [ -f ../inst/tiledb/lib/libtiledb.dylib ] && [ -f tiledbsoma.so ]; then install_name_tool -change libz.1.dylib @rpath/libz.1.dylib ../inst/tiledb/lib/libtiledb.dylib; install_name_tool -add_rpath @loader_path/../tiledb/lib tiledbsoma.so; fi
installing to /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/Rtmp6QC0jY/Rinst536f281a3550/00LOCK-tiledbsoma/00new/tiledbsoma/libs

May be missing a flag as we set for the R package.

So I am back to where I was a few days ago.  'ubuntu-latest' is green, 'macos-latest' not so much. See this run.

In the tiledb-r package we do this for macOS on x86_64 (it's autconf but you get the idea):
## Take care of 10.14 requirement for Intel macOS
if test x"${uname}" = x"Darwin" -a x"${machine}" = x"x86_64"; then
    AC_MSG_CHECKING([for Darwin x86_64 use minimum version override])
    CXX17_MACOS="-mmacosx-version-min=10.14"
    AC_MSG_RESULT([${CXX17_MACOS}])
fi

We may have to add the -mmacosx-version-min=10.14 to CMake if on macOS and using x86_64.

So I am back to where I was a few days ago. 'ubuntu-latest' is green, 'macos-latest' not so much.

I did have a successful Mac build before #1301. I think we can get back to success.

I've tried this six ways:

My main Mac which has core pre-installed (important developer workflow)
My personal Mac which does not have core pre-installed (normal user workflow)
An EC2 Ubuntu instance which has core pre-installed (important developer workflow)
An EC2 Ubuntu instance which does not have core pre-installed (normal user workflow)
Linux CI on this repo
Mac CI on this repo

All are workinig with my most recent commit, except for my main Mac where I am seeing what (I believe is an) unrelated segfault.

This currently runs only Linux

as the macOS line is commented-out:
https://github.com/single-cell-data/TileDB-SOMA/blob/440bd4651bc20cda5852c86e05575e517764068d/.github/workflows/r-ci.yml#L21

Looks like the line
https://github.com/single-cell-data/TileDB-SOMA/blob/cc5cb716ed8b38c3346ca6838558a94bc740a8a5/apis/r/src/Makevars.in#L28
was the winner!   Very nice as that uncorks us for now.
Longer-term we need to adjust this to possible artifact downloads as we do for the tiledb build on macOS.

Thanks @eddelbuettel -- OK, now even more green. 😎


Bug: view displays sessions based on case used during grade

If we have a session s/Lab1 and we grade a student with grade 1 s/laB1 g/100, the result from view will display the session name as s/laB1 instead of s/Lab1.

Perhaps we should capitalize the names in the parse* methods? That would prevent bad capitalized name to ever exist in the program!
Currently the equal method of ModuleClass and Session is also breaking strong equality.


observe('*.*') fails if function at top level

It works fine w/ up-to-date Chrome, but for older versions of Chrome, Firefox, and IE11 the following fails: http://jsfiddle.net/va6jU/97/
Basically: if you use a function at the top level of data Ractive tries calling Object.keys on it, but functions aren't allowed to use Object.keys in the aforementioned browsers.

To make things worse, Ractive swallows the error, because it's during init, and it winds up being very hard to track down.

As a final note, I'm aware that I can avoid this by either namespacing the functions, or being more specific w/ my observe (which is how I fixed the issue), but the error should have a better error message and handling, or be fixed to work identically with all browsers.

Eek. I had no idea that Object.keys behaved like that in older browsers. Is that documented anywhere? The only sensible solution I can think of is having an internal keys helper that knows whether it's safe to defer to Object.keys or does the for...in...hasOwnProperty dance instead.

Ractive swallows the error, because it's during init

Can you elaborate? It shouldn't be swallowing errors - e.g. if you deliberately throw an error inside oninit you get the expected result: http://jsfiddle.net/rich_harris/vqqp2385/

but the error should have a better error message and handling, or be fixed to work identically with all browsers

The second of those, definitely.
Something else I spotted - the *.* observer is being fired for each character of the string. I consider that a bug:

I was going to suggest you look at _.keys for inspiration, but from the look of it they (underscore and lodash) don't make the behavior consistent.

Something else I spotted - the *.* observer is being fired for each character of the string. I consider that a bug:

Here's the issue post for that bug: https://github.com/ractivejs/ractive/issues/1923.

Documentation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/keys#notes
If I'm reading this correctly it's actually the "correct" way for ES5. ES6, however, coerces the argument to an object first.  Not fantastic either way.  With one you get a TypeError, with the other you get keys for strings and functions.

As far as I can tell this is now working in all browsers (and probably has been a while), so I'll close this. Shout if otherwise

:+1: I lost track of this request. Can't confirm because I no longer have access to the code that was triggering it.


Release from development

:tada: This PR is included in version 4.0.9 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Use stable toolchain in coverage.yml

Fixes #377

Oh, we actually use a lot of nightly features by now. Closing this and the issue.


Different braces in grammar

I found inconsistency between canonical phi-calculus grammar (on the pic) and grammar in https://github.com/objectionary/normalizer/blob/master/eo-phi-normalizer/grammar/EO/Phi/Syntax.cf.
Rules program, formation and application must have different braces

Just to confirm: Program should remain {}, Formation should use ⟦⟧, and Application should use (), correct?
I'm only asking because Program in the screenshot above has no brackets around <Object>, but in Phi.g4 it specifies {}


Image branding

Hey, just wanna know if there is wayt to brand the QR code generated, like colors and logo.

It is not supported at present. You are welcome to contribute. @sergiomeneses


Please invite me to the GitHub Community Organization

Please invite me to the GitHub Community Organisation.

Name: Jai Kumar Dewani

Discord Username(if exists): JaiD#5360

Additional Context: Got to know about this community from @smv1999 :)

:nerd_face:

Invitation sent for the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see, you can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/EddieJaoudeCommunity/people
Tips for practising:
Customise your GitHub profile, here is a live stream on it https://www.youtube.com/watch?v=cT6GXCuS0Zo
Practice repo, instructions on how to add your name to the README in the README https://github.com/EddieJaoudeCommunity/hacktoberfest-practice
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps

Invitation sent for the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see, you can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/EddieJaoudeCommunity/people
Tips for practising:
Customise your GitHub profile, here is a live stream on it https://www.youtube.com/watch?v=cT6GXCuS0Zo
Practice repo, instructions on how to add your name to the README in the README https://github.com/EddieJaoudeCommunity/hacktoberfest-practice
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps


Create release script.

To ensure a consistent release process, add a script that creates all the right commits and tags. Update the procedure on the README to reflect this.

Resolve via https://github.com/r2dbc/r2dbc-h2/commit/853fe1a8e0439511e7b1b6c2d4ef262e3dd3fd6c.


Support code coverage reports on Jenkins for PHP.

Following the example of the node, https://github.com/grpc/grpc/blob/master/tools/run_tests/run_node.sh, the coverage report needs to be an index.html file in a subdirectory of reports.

PHP extension coverage report is now running on Jenkins: https://grpc-testing.appspot.com/view/Pull requests/job/gRPC_pull_requests/config=gcov,language=php,platform=linux/


[folding] Show tooltip on hovering collapse markers

It would be nice to be able to hover the ⊞ and ⊟ symbols in the left gutter of the editor and see a tooltip saying what will happen if they're clicked*, and showing which keyboard shortcut (if any) is assigned to the action, thus making the UI behavior more discoverable.
* This may sound superfluous, but IMO it would help with promoting consistent nomenclature throughout the interface, e.g. "collapse"/"expand" vs. "fold"/"unfold" vs. "hide"/"show", etc.

Hi @waldyrious, can you provide a screenshot of where these are?

@dbeigi actually the icons have been changed in 1.37: instead of ⊟ and ⊞, they are now arrowheads, looking like v and >, respectively. Here's a screenshot showing the new icons, taken using the latest release, 1.40:


Named Views: ng-model properties in template are not visible inside the respective controller.

index.html
1)

My template for view 'hello'
2)<input type="text" ng-model="testModel"/>
testModel is not visible inside helloCtrl on the $scope if we declare controller using 'ng-controller' as shown in step1.
It work's fine if we declare controller in the $stateProvider.state() as named view.

What you're trying to do is simply not the right way.  The controller can't be defined on the ui-view.  Putting the controller in the state definition is the correct way.
I recommend avoiding ng-controller altogether.


feat: esm.sh support, add Fresh example

esm.sh uses the User-Agent to determine the required target. Let's emulate deno's User-Agent to ensure that we get the same sources that deno receives, and the hashes align.
I'm trying to package an app that uses fresh and relies quite heavily on esm.sh.
This PR fixes the hash mismatch, but another error pops up that I can't intuit how to resolve. Any ideas?
$ nix flake check
error: builder for '/nix/store/hcfgbjicrk308hx1c1lpskhzfpg8qjwg-esm-simple.drv' failed with exit code 1;
       last 10 log lines:
       > Executing denoRestoreCacheHook
       > Finished denoRestoreCacheHook
       > Running phase: patchPhase
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > no configure script, doing nothing
       > Running phase: buildPhase
       > error: Expected a JavaScript or TypeScript module, but identified a Unknown module. Importing these types of modules is currently not supported.
       >   Specifier<EMAIL_ADDRESS>       >     at file:///build/esm-simple/main.ts:1:19
       For full logs, run 'nix log /nix/store/hcfgbjicrk308hx1c1lpskhzfpg8qjwg-esm-simple.drv'.

As a side-note, the timing of this repo couldn't have been better, I was banging my head agains the wall a few days ago trying to get deno2nix to work. I really appreciate it, glad to help out in any way possible. 😁

Ah, looks like Deno preserves the headers in the .metadata.json file, and uses content-type to determine the module type. Gotta figure out how to do that with nix machinery, the x-typescript-types header could be useful as well.

Hey, thanks for contributing so early!
I'm also still playing around and learning more about Deno internals as I'm playing around with this repo.
I quite naively assumed that esm.sh dependencies would work the same as deno.land 😅
Bit surprised that it will probably need a separate fetcher, looks like we'll have to write one from scratch, as I dont see a way in https://github.com/NixOS/nixpkgs/blob/4c501306af1ab6c19491fdafebb30fd097eb42c5/pkgs/build-support/fetchurl/builder.sh to pipe the header response to $out, passthru, or similar.
I'll try to have a look at this tomorrow, it's getting late here. 🙂

I can get fetchurl to output just the headers with a -I curl flag. Including the headers with the request with -D - doesn't work, as fetchurl saves the request body with --output, and not just the stdout.
We can call fetchurl twice, once for the header and once for the body. A better option would do just one HTTP request. Maybe that would be a custom fetcher perhaps using deno internals for robustness? Maybe getting a patch into nixpkgs' fetchurl with some backwards compatibility considerations?
I'll think on it and make another attempt when I'm back at the keyboard.

I think we're possibly pretty stuck here, if we want to solve this cleanly. 😓

We can call fetchurl twice, once for the header and once for the body.

Storing the header data would change the output, so the sha256sum in deno.lock would differ from the output; the shasum only validates the actual dependency download, not any headers that are sent along with it.
We could make a special exception for esm.sh since it's so widely used in the Deno ecosystem, and try to assume response types in some cases. I've pushed some changes onto this branch to play around with this, the basic esm-simple check passes. I had to push the fresh check onto GitHub because my local nix on darwin runs into the old
sandbox-exec: pattern serialization length 69665 exceeds maximum (65535)

😅

Glad it seems to work for you. 😄

I've got some ideas to improve packaging Fresh, but I'll open a separate issue.

Please do open that issue, I'd love to get input to make these builders as useful as possible! I'm looking at the nixpkgs NPM/Rust/Flutter builders for inspiration, in addition to Deno specific stuff like the bin wrappers:
https://github.com/nekowinston/nix-deno/blob/bb2771a3f0c0b51422bcb3a7d929c2cf29308e24/nix/hooks/deno-install-hook.sh#L13-L21


feat: change how the response handle streams

The Response.stream in the latest version of Serinus is not behaving as a Stream but more like a facade on top of the Response.text. This must be changed in the view of a more organic approach to how things are handled in the whole framework.
For this reason the Response.stream must undergo to a refactor with all the changes that it requires to work.
The idea is:

The Response.stream closes the request only when the stream associated with it has ended or when the handler has returned;
The Response.stream accepts a stream of whatever data the user wants but it will all be converted to Uint8List when sent.

First try


proposal: Add Networked Plugin Rules

Adds a proposal for restrictions/guidance around networked plugins.

I think this is ready for @goatcorp/plugin-approval to review and add any final feedback.

This is not being included in this proposal due to the fact that it will devolve into endless debate, but I do want to add a section on data that may not be collected by mainline plugins. I may turn this into a secondary proposal in the future, but I'm also putting it here just so it exists.

Certain types of data may not be collected by plugins.

Any information on other installed plugins or utilities.
Any information about the user's device, such as hardware or software configurations.

Collection of OS and graphics driver versions are permissible for diagnostics purposes.

Information about other players, including customize data.

Client-side aggregation of information may be permissible depending on use case, design, and intent.

Other data types may be excluded based on PAC's discretion. The above list is non-exhaustive.

This seems entirely reasonable to me; apologies for the significant delay on the review. The only thing I'd change is the use of the word "curios"; it's unlikely that most will be familiar with that.
Other notes:

Do we grandfather existing plugins or ensure they meet these requirements?
Is it worth including examples of plugins that would or would not pass these restrictions?

Otherwise, I'll hand it over to @goaaats .

Will change the use of curios on my next lint pass.

Do we grandfather existing plugins or ensure they meet these requirements?

My intent with this proposal was to codify (more or less) our existing rules and various opinions in a single clear format. As such, I don't think there are any plugins that need to be grandfathered, at least in terms of general data collection compliance.
Plugins that currently use HTTP-only communication or IP addresses for connections should not be grandfathered, however.

Is it worth including examples of plugins that would or would not pass these restrictions?

See above - it's somewhat difficult to create a list of non-compliant plugins at the moment since there aren't really any in the official reposet. We could create such a theoretical list as an addendum, if that would be beneficial?

Makes sense. As always, we should encourage people to ask about their plugin idea before they implement it, but I don't think that's exclusive to this PR. Nice work!

@goaaats reminder


consul_install_dnsmasq: false

because I tried out this role a few days ago and today a couple of my Ops guys were asking me why dnsmasq is installed on our test servers :-)
It's safer to not install extra packages.

Can you change the readme too?

Yep. Done in a72d093.

Thanks man :+1:


Can't handle requestBody defined by $ref

When attempting to use an endpoint defined as
    patch:
      summary: partial update user
      tags: [Users]
      operationId: updateUserPartial
      'x-type': 'passthru-patch'
      requestBody:
        $ref: '#/components/requestBodies/User'
      responses:
        '200':
          $ref: '#/components/responses/User'
        '403':
          $ref: '#/components/responses/Forbidden'
        '4XX':
          $ref: '#/components/responses/BadRequest'
        '5XX':
          $ref: '#/components/responses/ServerError'

throws the error:
(node:62889) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'application/json' of undefined
    at _default (.../node_modules/oa-client/dist/create-client/validate-request/validate-body.js:29:27)
    at _default (.../node_modules/oa-client/dist/create-client/validate-request/index.js:44:31)
    at Object.put (.../server/node_modules/oa-client/dist/create-client/index.js:36:34)
    at Object.updateUserComplete (.../handlers/users.js:72:44)

because requestBody does not contain a content field.

Ok! This should probably be documented in the README.

You're right, thx for the suggestion! https://github.com/ninofiliu/oa-client/commit/177d1ffca8bc8ba93764b0fcefe66d7346236fea


Comparison with hyperfine

Author of hyperfine here, hi!

However, poop does report peak memory usage as well as 5 other hardware counters, which I personally find useful when doing performance testing. Hey, maybe it will inspire the Hyperfine maintainers to add the extra data points!

I only learned about this project today. I didn't know about the call to action — you should have told us :smile:. You might have seen this, but for reference, we have an open issue (https://github.com/sharkdp/hyperfine/issues/86) about this and even a early draft PR which I hopefully finish at some point. Having some competition is definitely a nice motivation, so thanks for creating this project. Adding even more performance counters is a very interesting idea (even if it might be a Linux-only feature).
I quickly wanted to comment on the rest of the "Comparison" paragraph:

Poop does not run the commands in a shell. This has the upside of not including shell spawning noise in the data points collected, and the downside of not supporting strings inside the commands.

Hyperfine supports both use cases via the --shell/-N options:
  -S, --shell <SHELL>
          Set the shell to use for executing benchmarked commands. This can be
          the name or the path to the shell executable, or a full command line
          like "bash --norc". It can also be set to "default" to explicitly
          select the default shell on this platform. Finally, this can also be
          set to "none" to disable the shell. In this case, commands will be
          executed directly. They can still have arguments, but more complex
          things like "sleep 0.1; sleep 0.2" are not possible without a shell.
  -N
          An alias for '--shell=none'.

Even when using --shell=none/-N, we support things like hyperfine -N 'echo "hello world"', i.e. we properly handle quoted arguments etc.

Poop treats the first command as a reference and the subsequent ones relative to it, giving the user the choice of the meaning of the coloring of the deltas. Hyperfine always prints the wall-clock-fastest command first.

Hyperfine also supports this using the --reference and --sort options.
      --reference <CMD>
          The reference command for the relative comparison of results. If this
          is unset, results are compared with the fastest command as reference.

      --sort <METHOD>
          Specify the sort order of the speed comparison summary and the
          exported tables for markup formats (Markdown, AsciiDoc, org-mode):
            * 'auto' (default): the speed comparison will be ordered by time and
              the markup tables will be ordered by command (input order).
            * 'command': order benchmarks in the way they were specified
            * 'mean-time': order benchmarks by mean runtime

In general, let us know if you think we should change our defaults, and I'm open to discussing this. For example, maybe --shell=none should be the default.
Also, feel free to close this ticket. I mainly wanted to say hi and make sure that we very much appreciate new ideas in the command-line-benchmarking world :+1:

Hello! Thanks for the friendly message :)
I've done my best to make the comparison in the readme fully accurate. Please feel free to suggest a rewording via pull request if you feel it is still missing something. I'll close the issue since there is no action item, but we can still continue the discussion here.
Happy hacking!


Where are the model checkpoints saved?

What do you mean by model checkpoints? The model is saved, by default, to your working directory. I always provide a full path.
If you mean the pre-trained models that we provide, then they are here: https://github.com/NVIDIA/retinanet-examples/releases/tag/19.04


Updated dom-crawler to match the latest version

Fixes: https://github.com/open-admin-org/open-admin/issues/100
Was brought up to deal with the symfony's dom-crawler component conflicting with the package's dom-crawler.
@open-admin-org please review.

thanks will merge soon

Hi, why was this PR closed?

?


Add a latest_finished symlink

This is to allow looking at the results of the last full build for comparisons rather than potentially viewing an in-progress build.

@ant1 this will be in the next package builds so you can use it rather than /latest for exp-run comparisons

As latest-finished

Actually going to use latest-done to match the status.


Issue 34 fixed

Summary of change
Derived Query by Genre
Related issue
Closes #34
Pull request checklist
Please keep this checklist in & ensure you have done the following:

[x] Read, understood and adhered to our contributing document.

[x] Ensure that you were first assigned to a relevant issue before creating this pull request
[x] Ensure code changes pass all tests

[x] Read, understood and adhered to our style guide. A lot of our code reviews are spent on ensuring compliance with our style guide, so it would save a lot of time if this was adhered to from the outset.

[x] Filled in the summary, context (if applicable) and related issue section. Replace the square brackets and its placeholder content with your contents. For an example, see any merged in pull request

[x] Created a branch that has a descriptive name (what your branch is for in a few words and includes the issue number at the end, e.g. test-reading-goal-123

[x] Set this pull request to 'draft' if you are still working on it

[x] Resolved any merge conflicts

For any of the optional checkboxes (e.g. the screenshots one), still check it if it does not apply.
If in doubt, get in touch with us via our Slack workspace

I noticed you linked to #34 and included that in your branch name. Please note that #34 was your previous PR, not the issue number. Could you please rename your branch?

I noticed you linked to #34 and included that in your branch name. Please note that #34 was your previous PR, not the issue number. Could you please rename your branch?


GD-57: Await on C# executor throws error on non-existing signal ExecutionCompleted

The used GdUnit4 version
4.2.1 (Pre Release/Master branch)
The used Godot version
v4.2.1.stable.mono.official [b09f793f5]
Operating System
macOS Ventura
Describe the bug
When running a long set of C# test suites, after ~50% of them complete and pass I hit the following error. Once this fires, the tests no longer run as the runner has crashed.
E 0:00:11:0413   GdUnitRunner.gd:83 @ _process(): In Object of type 'RefCounted': Attempt to connect nonexistent signal '' to callable 'GDScriptFunctionState::_signal_callback'.   <C++ Error>    Condition "!signal_is_valid" is true. Returning: ERR_INVALID_PARAMETER   <C++ Source>   core/object/object.cpp:1344 @ connect()   <Stack Trace>  GdUnitRunner.gd:83 @ _process()
Some context showing where the error was triggered is in the screenshot below:

Steps to Reproduce
Very difficult to nail this down to a smaller test case. I only saw this begin after accumulating test suites after some time. Attempting to disable certain test suites only makes the problem happen on the next test suite after the disabled one.
Minimal reproduction project
No response

It looks like it could be fixed by https://github.com/godotengine/godot/issues/84254

I'm not able to reproduce with GdUnit4 v4.2.4 and GdUnit4Net v4.2.2
Godot Engine v4.2.1.stable.mono.official (c) 2007-present Juan Linietsky, Ariel Manzur & Godot Contributors.
  modules/gltf/register_types.cpp:63 - Der Blend-Dateiimport ist in den Projekteinstellungen aktiviert, aber es wurde kein Blender-Pfad in den Editoreinstellungen festgelegt. Es werden keine Blend-Dateien importiert.
--- Debug adapter server started ---
--- GDScript language server started on port 6005 ---
Loading GdUnit4 Plugin success
GdUnit4Net version '<IP_ADDRESS>' loaded.
GdUnit4: Test server successfully started checked port: 31002

cs project file
<Project Sdk="Godot.NET.Sdk/4.2.1">
  <PropertyGroup>
    <TargetFrameworks>net8.0</TargetFrameworks>
    <LangVersion>11.0</LangVersion>
    <!--Force nullable warnings, you can disable if you want-->
    <Nullable>enable</Nullable>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
    <!--Disable warning of invalid/incompatible GodotSharp version-->
    <NoWarn>NU1605</NoWarn>
  </PropertyGroup>
  <ItemGroup>
    <!--Required for GdUnit4-->
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.9.0" />
    <PackageReference Include="gdUnit4.api" Version="4.2.*-*" />
    <PackageReference Include="gdUnit4.test.adapter" Version="1.*" />
  </ItemGroup>
</Project>

Test template:
// GdUnit generated TestSuite
using Godot;
using GdUnit4;
using System;
using System.Threading.Tasks;

namespace GdUnit4
{
	using static Assertions;
	using static Utils;

	[TestSuite]
	public partial class ExampleTestSuite9
	{
		[TestCase]
		public async Task IsFooAsync()
		{
			await ISceneRunner.SyncPhysicsFrame;
			AssertThat("Foo").IsEqual("Foo");
		}

		[TestCase]
		public async Task IsBarAsync()
		{
			await ISceneRunner.SyncPhysicsFrame;
			AssertThat("Foo").IsEqual("Foo");
		}
	}
}


Default double_quotes flag should be chars

https://github.com/ichiban/prolog/issues/176#issuecomment-1075505151
The current default is codes, which follows GNU Prolog.
https://github.com/ichiban/prolog/blob/f2029460f9a56e751e3d1e27f06a68448012460e/engine/parser.go#L628

The ISO standard says the default value is implementation defined.

<IP_ADDRESS> Flag: double-quotes
Possible values: chars, codes, atom
Default value: implementation defined
Changeable: Yes

I like chars as a default. @triska's lesson on DCGs outlines a good argument for using it. Alignment with Scryer and Tau is also nice.
https://www.metalevel.at/prolog/dcg


ETARGET for TypeScript 3.3

Currently all our CI jobs fails, because dtslint tries to install<EMAIL_ADDRESS>which is not released yet. This is because it has been added to TypeScriptVersion.all in definitelytyped-header-parser.
export namespace TypeScriptVersion {
	export const all: ReadonlyArray<TypeScriptVersion> =
		["2.0", "2.1", "2.2", "2.3", "2.4", "2.5", "2.6", "2.7", "2.8", "2.9", "3.0", "3.1", "3.2", "3.3"];
	// ...
}

This causes installAll to choke on L13.
https://github.com/Microsoft/dtslint/blob/c26894e43837919306878ecb0562f491e3a9cf24/src/installer.ts#L9-L16
lerna ERR! npm ERR! Linux 4.4.0-101-generic
lerna ERR! npm ERR! argv "/home/travis/.nvm/versions/node/v6.15.1/bin/node" "/home/travis/.nvm/versions/node/v6.15.1/bin/npm" "install" "--ignore-scripts" "--no-shrinkwrap" "--no-package-lock" "--no-bin-links"
lerna ERR! npm ERR! node v6.15.1
lerna ERR! npm ERR! npm  v3.10.10
lerna ERR! npm ERR! code ETARGET
lerna ERR!
lerna ERR! npm ERR! notarget No compatible version found<EMAIL_ADDRESS>lerna ERR! npm ERR! notarget Valid install targets:
lerna ERR! npm ERR! notarget 3.3.0-dev.20181211, 3.3.0-dev.20181208, 3.3.0-dev.20181207, ...

Full log on Travis CI.

If you are using yarn, you can circumvent this issue by forcing a resolution for the latest compatible version of definitelytyped-header-parser.
You can find an exemplary PR here: https://github.com/ember-decorators/ember-decorators/pull/338

Hold on one second. L12 is supposed to prevent this from happening in the first place. 🤔

OMG. 🤦♂
We were using an outdated version of dtslint, that didn't have the check yet. Sorry for the noise.
It's a bit annoying though, that his was possible to happen in the first place. 😅


[Question] Stringify before sending

Insomnia Version: 6.3.2
Operating System: Win 10

Details
I need to send a json string containing a json inside to a rest endpoint.
Currently I write it like this:
"{` \"person\": { \"name\": \"Name of the person.\" } }"

but it's difficult to write it and hard to read. I'd like to write it somehow like:
return JSON.stringify(
  {
    person: {
      name: "Name of the person.\"
    }
  }
);

so I can clearly see the data to be sent and wouldn't have to escape characters.
I believe it's not possible now, so I'm marking this as a feature request.

Is your use case to encode some json inside a json property?
Many APIs are "envelope" APIs, that is they have a JSON model and are used to carry a client-defined payload. Most clients would use JSON for the payload so we end up needing to write JSON as a string value for a JSON property.
I wrote a plugin for this use case: https://github.com/senoctar/insomnia-plugin-inception
Let me know if it works for you.

Woah, that plugin is very cool @senoctar!

One other thing that might be useful:
If you have an object as an environment variable like this:
{
  "myEnvVar": {
    "foo": "bar"
  }
}

you can stringify it using Insomnia's template language (Nunjucks) by applying a filter like this:
{{ myEnvVar | dump }}

https://mozilla.github.io/nunjucks/templating.html#dump
I'm going to close this issue as it seems like the question has been answered but feel free to follow up if it's still unclear.

It was non obvious for me (😴) but remember you can take any helper and use that in an environment variable. So I used Response -> Body Attribute in an environment variable and then put that where I wanted with dump so that the value from the response was re-stringified (escaped){{ myVar | dump }}.


[Usability Bug] Last breadcrumb is to grayed out

Bug Report

We should probably make the grayed out breadcrumb a bit more solid since when used in practice it doesnt look proper in a toolbar the way it is right now.

@emoralesb05 Can you clarify this bug for me? Are you saying that the last breadcrumb is too light? If so does the attached image work better for you. Also, is the 'HTTP' that appears first part of the issue? If so, can you advise where and how to replicate?

The text opacity has been changed from 0.38 to 0.54

The main "issue" is how light the last breadcrumb is.
When actually using this, it looks like its disabled instead of "selected"

I put together some options and examples from google to review.
https://covalent-breadcrumbs.stackblitz.io

Let's go with Example #2

PR merged already.


version 1.1.0+1 build failed

update to v1.1.0+1, build the app, it happened:
FAILURE: Build failed with an exception.

What went wrong:
Could not determine the dependencies of task ':app:lintVitalRelease'.

Could not resolve all artifacts for configuration ':app:debugRuntimeClasspath'.
Could not resolve org.jfrog.cardinalcommerce.gradle:cardinalmobilesdk:2.2.4-1.
Required by:
project :app > project :flutter_braintree > com.braintreepayments.api:drop-in:5.0.1 > com.braintreepayments.api:three-d-s
ecure:3.14.2
Could not resolve org.jfrog.cardinalcommerce.gradle:cardinalmobilesdk:2.2.4-1.
Could not get resource 'https://maven.google.com/org/jfrog/cardinalcommerce/gradle/cardinalmobilesdk/2.2.4-1/cardinalmo
bilesdk-2.2.4-1.pom'.
Could not HEAD 'https://maven.google.com/org/jfrog/cardinalcommerce/gradle/cardinalmobilesdk/2.2.4-1/cardinalmobiles
dk-2.2.4-1.pom'.
Connect to maven.google.com:443 [maven.google.com/<IP_ADDRESS>] failed: Connection timed out: connect
Could not resolve org.jfrog.cardinalcommerce.gradle:cardinalmobilesdk:2.2.4-1.
Could not get resource 'https://storage.googleapis.com/download.flutter.io/org/jfrog/cardinalcommerce/gradle/cardinalmo
bilesdk/2.2.4-1/cardinalmobilesdk-2.2.4-1.pom'.
Could not HEAD 'https://storage.googleapis.com/download.flutter.io/org/jfrog/cardinalcommerce/gradle/cardinalmobiles
dk/2.2.4-1/cardinalmobilesdk-2.2.4-1.pom'.
Connection reset

I am facing same issue. Any update?

I'm also facing same issue. Any Update....?

I'm also facing same issue. Any Update....?

same here, my builds failing. @pikaju any ideas?

same here, my builds failing. @pikaju any ideas?

Me too please.

Me too please.

same here. any fix yet?

same here. any fix yet?

sane here, any update?

sane here, any update?

With using below code found working.
you just have to add to your app level build.gradle the depenency like so:
dependencies {
.....
implementation ('com.braintreepayments.api:drop-in:5.0.1')
}
and to you android level build.gradle the mave repository like so:
allprojects {
repositories {
google()
jcenter()
maven {
url "https://cardinalcommerce.bintray.com/android"
credentials {
username 'braintree-team-sdk@cardinalcommerce'
password '220cc9476025679c4e5c843666c27d97cfb0f951'
}
}
}
}

With using below code found working.
you just have to add to your app level build.gradle the depenency like so:
dependencies {
.....
implementation ('com.braintreepayments.api:drop-in:5.0.1')
}
and to you android level build.gradle the mave repository like so:
allprojects {
repositories {
google()
jcenter()
maven {
url "https://cardinalcommerce.bintray.com/android"
credentials {
username 'braintree-team-sdk@cardinalcommerce'
password '220cc9476025679c4e5c843666c27d97cfb0f951'
}
}
}
}

I fixed it by adding this:
android {
        lintOptions {
        // ...
        checkReleaseBuilds false // Insert this line
    }
}

to app level buid.gradle file

I fixed it by adding this:
android {
        lintOptions {
        // ...
        checkReleaseBuilds false // Insert this line
    }
}

to app level buid.gradle file

Any update on this?

Sorry for the wait guys, this should hopefully be fixed in version 1.2.1 of flutter_braintree.


"Do not evict" only for running pods

Tell us about your request
We configure all of our helm hooks and other important pods with the do not evict flag. Some pods might not move to the running state because of having errors like CreateContainerError, CreateContainerConfigError or others.
Therefore we would like to have a better karpenter behaviour, only consider the do not evict flag if a given pod is in state creating or running...
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Right now a single pod can keep a single node running for unlimited time. After some time this is very costly... Imagine having dozens of nodes in a left behind state.
Are you currently working around this issue?
 Which does not work if you have dozens of teams and projects running on a given cluster...
Additional Context
No response
Attachments
No response
Community Note

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 think in general it makes sense if the pod is in an errored state and is clearly not running, that disruption like this should be allowed.
One thing I can think of is that this has the potential to race and put clusters in a half-state if they have jobs that are stateful:

Pod errors and enters a Failed state
do-not-evict is ignored and Karpenter begins to execute deprovisioning
Pod starts running
Node is deprovisioned which leaves the job half-done

Any thoughts to add to this @njtran?

This race conditions would only occur if a given pod is the only reason why the cluster scaled up in the first place

Not neccesarily. Consolidation or expiration could occur on a node with do-not-evict pods and there would still be other workloads that would be scheduled on that node.
I think general guidance is that jobs should be able to be disrupted and non-stateful since there's any number of reasons why they could fail or get rescheduled.

There won’t be other new workloads because once karpenter decides to remove it the node is set to no schedule anyway.

So I believe that we already check if a pod is terminal (succeeded or failed) when considering the do-not-evict pod.
https://github.com/aws/karpenter-core/blob/main/pkg/controllers/deprovisioning/helpers.go#L328-L334
https://github.com/aws/karpenter-core/blob/main/pkg/utils/pod/scheduling.go#L50-L52
Is there something I'm missing here? are you not seeing this happening in your cluster? In the case of only considering running or creating pods, I'm not sure if we should ignore the do-not-evict in the case of Unknown or Terminating, as those map to many different scenarios as well. If I understand correctly, a pod being terminal (succeeded or failed) should be sufficient.

After poking around, I think I understand your request now. Looks like you want to bypass the annotation in the case that any of the containers have a problem that you deem a "terminal" state, resulting in the pod staying in the pending phase. If we wanted to try this, I think we'd have to check all the containers on the pod and allow a set of container statuses to bypass the annotation.
Specifically checking the go struct used for this, it doesn't seem like there's a normal set of enum values for this: https://pkg.go.dev/k8s.io/api/core/v1#ContainerStateWaiting
So this means "Waiting" could happen for any number of reasons that may remediate itself, or not, tough to know.
I'd be happy to support this though, if we can construct a specific set of container status reasons that we can deem to satisfy @jonathan-innis's condition.

pod is in an errored state and is clearly not running

Yes I would like to ignore pods which have containers wich will never recover from a terminal state but I would also like to simple ignore pods which are in these states:

Failed
Succeeded/Completed (this could already be implemented?)

Maybe for pods in a pending state we could ignore them after some "timeout"?

The pod is in pending state and the container is in waiting state, here is a similar example

Is it possible to get this at the source and remediate the containers that are hanging in this state so that you don't get hung nodes? Is it possible to create some sort of alerting around how long a Pod sits in a Pending phase so that if one sits there for too long, you get an alarm and then can go to the dev team to ask them to remediate their image/container?

We have alerting in place, but if you have a lot of teams using the cluster it is a pain to manually take care of these issues.