Some Payment Methods don't work with LIVE API key, but do with TEST API key

While implementing a Donation page for our client, we ran into an issue.
While using the test-api-key, we were able to create a payment checkout process that brought us to a Mollie page where we could choose on of the two configured payment methods (configured in Mollie dashboard, "Bancontact" and "Visa").
But when using the live-api-key, the mollie checkout url skips the payment selection, and directly goes to the payment form for "Visa".
This happens for the one-time payments, as well as for the subscriptions:
    private function handleSubscription(Donation $donation)
    {
        $plan = Plan::firstOrCreate(
            ['amount' => $this->amount],
            [
                'working_title' => $this->amount,
                'description' => "ITG Donation {$this->amount}",
                'interval' => 1,
                'period' => 'month',
                'active' => false,
            ]
        );

        $result = $donation->newSubscriptionViaMollieCheckout("subscription {$this->amount}", $plan->working_title)->create();

        return redirect($result->getTargetUrl()); // Redirect to Mollie checkout
    }

    private function handleOneTimePayment(Donation $donation)
    {
        $tax = $this->vat_number ? 0 : 21;

        $item = new \Laravel\Cashier\Charge\ChargeItemBuilder($donation);
        $item->unitPrice(money($this->amount * 100, 'EUR'));
        $item->taxPercentage($tax);
        $item->description('One Time Donation');
        $chargeItem = $item->make();

        $result = $donation->newCharge()
            ->addItem($chargeItem)
            ->create();

        return redirect($result->getTargetUrl()); // Redirect to Mollie checkout
    }

Is there a problem with our code, with the package? We are clueless as Mollie support assures us that the Web Profile and Payments configuration is set up correctly.
Thanks in advance.

Hi @SimonBroekaert ,
Can you check with the following snippet if the payment methods you are expecting to see are fully enabled:
$mollie->methods->allActive();

Make sure to use the right live/test key matching the Mollie profile you have enabled the payment methods on.

Thanks @sandervanhooft for the fast answer!
I've dumped the results of that method and attached it below:

So the two payment methods look to be enabled, but when I redirect to the checkoutUrl, we see this:

And with the test-api-key, we see the following:

Hope this information helps.

Interesting!

Can you check the value of $plan->firstPaymentMethod()?

$plan->firstPaymentMethod() is set to null

Is this happening when creating a subscription, or when performing a single charge?

(handleSubscription vs handleOneTimePayment in your code)

Let's also try to perform a payment without Cashier, to rule out that the problem is at Mollie's side/your Mollie account:
$payment = mollie()->payments->create([
  'description' => 'Cashier method test',
  'redirectUrl' => 'https://mollie.com',
  'amount' => [
    'value' => '60.00',
    'currency' => 'EUR',
  ],
]);

$payment->getCheckoutUrl(); // TODO redirect here

In both methods, bancontact is not showing up in the checkout url
When i do a manual mollie()->payments()->create([...]);, Bancontact is showing up:

That helps narrow it down a bit. Can you share (redacted) your cashier configs here?

Can you also try this?
$payment = mollie()->payments->create([
  'description' => 'Cashier method test',
  'redirectUrl' => 'https://mollie.com',
  'amount' => [
    'value' => '60.00',
    'currency' => 'EUR',
  ],
  'sequenceType' => 'first', // <--- Add this
]);

config/cashier.php:
<?php

return [

    /**
     * The default webhook url is called by Mollie on payment status updates. You can use either a relative or
     * absolute url.
     */
    'webhook_url' => 'webhooks/mollie',

    /**
     * The default aftercare webhook url is called by Mollie on refunds and chargebacks. You can use either a relative or
     * absolute url.
     */
    'aftercare_webhook_url' => 'webhooks/mollie/aftercare',

    /**
     * The default locale passed to Mollie for configuring the checkout screen. Set to null to let Mollie handle it for
     * you.
     * @link https://docs.mollie.com/reference/v2/payments-api/create-payment#parameters
     * @example 'nl_NL'
     */
    'locale' => null,

    /**
     * Used for generating Order numbers, used in Orders and related Invoices.
     */
    'order_number_generator' => [

        /**
         * The model used for Order Numbers. You can extend and override it here to implement your own logic.
         */
        'model' => \Laravel\Cashier\Order\OrderNumberGenerator::class,

        /**
         * The offset used by the Order Number Generator.
         */
        'offset' => 0,
    ],

    /**
     * A first payment requires a customer to go through the Mollie checkout screen in order to create a Mandate for
     * future recurring payments.
     * @link https://docs.mollie.com/payments/recurring#payments-recurring-first-payment
     */
    'first_payment' => [

        /**
         * The first payment webhook url is called by Mollie on first payment status updates. Can be overridden per
         * Plan. You can use either a relative or absolute url.
         */
        'webhook_url' => '/webhooks/mollie/first-payment',

        /**
         * Array of allowed Mollie payment methods for the first payment. Make sure the methods are
         * enabled in the Mollie dashboard. Set to [] to let Mollie handle this for you. Can be overridden per plan.
         * @example ['ideal', 'creditcard']
         */
        'method' => [],

        /**
         * The default url the customer is redirected to after the Mollie first payment checkout screen. Can be
         * overridden per Plan. You can use a `{payment_id}` placeholder here to easily retrieve the Mollie payment in
         * your controller. Make sure you have set up a matching route.
         */
        'redirect_url' => "/donation/callback/{payment_id}",

        /**
         * The default amount for a first payment. Can be overridden per Plan.
         */
        'amount' => [

            /**
             * A string containing the exact amount you want to charge for the first payment, in the given currency.
             * Make sure to set the right amount of decimals. Non-string values are not accepted by Mollie.
             */
            'value' => '1.00',

            /**
             * An ISO 4217 currency code. The currencies supported depend on the payment methods that are enabled on
             * your Mollie account.
             */
            'currency' => 'EUR',
        ],

        /**
         * The default description for the first payment, visible on both the invoice and the customer bank records.
         */
        'description' => 'Welcome to ' . config('app.name'),
    ],

    /**
     * Updating the payment method requires a customer to go through the hosted Mollie checkout to add a new Mandate for
     * future recurring payments.
     * @link https://docs.mollie.com/payments/recurring#payments-recurring-first-payment
     */
    'update_payment_method' => [

        /**
         * The default url the customer is redirected to after the Mollie payment method is changed in payment checkout screen. Can be
         * overridden per Plan. You can use a `{payment_id}` placeholder here to easily retrieve the Mollie payment in
         * your controller. Make sure you have set up a matching route.
         */
        'redirect_url' => config('app.url'),

        /**
         * The default amount for change payment method. Can be overridden per Plan and is added to user balance.
         */
        'amount' => [

            /**
             * A string containing the exact amount you want to charge for change the payment method, in the given currency.
             * Make sure to set the right amount of decimals. Non-string values are not accepted by Mollie.
             */
            'value' => '1.00',

            /**
             * An ISO 4217 currency code. The currencies supported depend on the payment methods that are enabled on
             * your Mollie account.
             */
            'currency' => 'EUR',
        ],

        /**
         * The default description for the update payment method, visible on both the invoice and the customer bank records.
         */
        'description' => 'Update payment method for ' . config('app.name'),
    ],

];

config/cashier_plans.php:
<?php

use Laravel\Cashier\Coupon\CouponOrderItemPreprocessor as ProcessCoupons;
use Laravel\Cashier\Order\PersistOrderItemsPreprocessor as PersistOrderItems;
use Laravel\Cashier\Plan\AdvancedIntervalGenerator;

return [

    /**
     * Plan defaults. Can be overridden per Plan.
     */
    'defaults' => [

        /**
         * A first payment requires a customer to go through the Mollie checkout screen in order to create a Mandate for
         * future recurring payments.
         * @link https://docs.mollie.com/payments/recurring#payments-recurring-first-payment
         */
        'first_payment' => config('cashier.first_payment'),

        /**
         * The default chain of subscription OrderItem preprocessors. These are called right before the Subscription's
         * OrderItem is processed into an OrderItem. You can use this for calculating variable costs a.k.a. metered billing.
         * Can be overridden per subscription plan. Make sure the preprocessors implement the PreprocessesOrderItems
         * interface.
         */
         'order_item_preprocessors' => [
             ProcessCoupons::class,
             PersistOrderItems::class,
         ],
    ],

    /**
     * The subscription plans.
     */
    'plans' => [

        /**
         * The plan reference.
         */
        'plan-1' => [

            /**
             * The amount to be billed each billing cycle.
             */
            'amount' => [

                /**
                 * A string containing the exact amount you want to charge each billing cycle, in the given currency.
                 * Make sure to set the right amount of decimals. Non-string values are not accepted by Mollie.
                 */
                'value' => '60.00',

                /**
                 * An ISO 4217 currency code. The currencies supported depend on the payment methods that are enabled on
                 * your Mollie account.
                 */
                'currency' => 'EUR',
            ],

            /**
             * The length of the billing cycle.
             */
            // 'interval' => '1 month' or
            'interval' => [
                'generator' => AdvancedIntervalGenerator::class,
                'value' => 1,
                'period' => 'month', /* day, month or year*/
                'monthOverflow' => true,
            ],

            /**
             * The text to appear on the invoice.
             */
            'description' => 'Monthly payment',

            /**
             * The chain of subscription OrderItem preprocessors. These are called right before the Subscription's
             * OrderItem is processed into an OrderItem. You can use this for calculating variable costs a.k.a. metered
             * billing. Make sure the preprocessors extend the BaseOrderItemProcessor.
             */
            // 'order_item_preprocessors' => [
            //    ProcessCoupons::class,
            //    PersistOrderItems::class,
            // ],
        ],
    ],
];

(Note: Our plans can be created via our CMS dynamicly, that's why there is only 1 in here)

When adding 'sequenceType' => 'first' to the mollie payment create method, (and also adding a customerId, because otherwise, I got a validation error). The "select payment method" screen is skipped again

That means that somehow, bancontact is not regarded by Mollie as a valid payment method for recurring payments, on your live profile. Because only the creditcard option remains, the payment method selection is skipped in the checkout.
I'll loop in someone from Mollie support.

When I do the same thing while using the test-api key as above: (making a payment manually, with the sequenceType => first)
I get the "select payment method" option.
So there is a disparity in suitable payment methods between the test and live keys.
Thanks @sandervanhooft for all the help till now! Hopefully Mollie support will have more information then

Hi @SimonBroekaert ,
Can you check if bancontact SDD is fully enabled as well? If not, give that a try. Looks like bancontact is required on first payments for the normal bancontact to work

Thanks for looking further into this @sandervanhooft !
Could you tell me where I (or the client) can activate this?
Thanks!

Hi @SimonBroekaert, I can see that SDD is not activated on the dashboard.
You can request the payment method via: Settings > profile > payment methods > SEPA-domiciliëring (and not the SEPA bank transfer).
Please keep in mind our team needs to review the approval for this payment method, this could take a few days.

Hi @Robert4mollie !
Thanks alot! I'll let our client know that he should enable this. (as it is their account).
I'll keep you posted here if it has resolved our issue.
Thanks both for the support!

Sorry for the late answer.. I forgot to post a response here to let you know that the issue was resolved with the suggested solution!
Thanks all


Create automatically generated table of contents

When creating a new piece of content, it should be added to an automatically generated table of contents.
I'm imagining something like this:
Handle.GET("/content/partials/table-of-content", () =>
{
    // Gets all the content items that has been marked as "show in table in contents"
    // sets them as the data object of a view-model
    // returns the view-model
}

{
    "html": "/your/path.html",
    "content": [ { } ]
}

<template>
  <template is="dom-repeat">

{{model.content}}

  </template>
</template>

So there can be set point in the website app where the table of contents is displayed. When a new item is created, it's also added if the user doesn't explicitly ask to exclude it.
Please ask if you need a clarification.

I don't think I can add a new db column in Simplified.Ring6.WebContent from Content app .
Didn't really knew what style to apply tot he page. This pretty much depends of what the user wants. Kept it as simple as possible for the moment.

Closing as done.


libupnp: 1.6.20 -> 1.6.21

Motivation for this change
I'm not super familiar with sourceforge, I hope this is not a temporary url.
/cc @grahamc
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
x ] Fits CONTRIBUTING.md.

Wouldn't it be better to fetch via git? I think that is supported by nix?

That will pull in the entire history, we generally prefer an url. But I can switch if this doesn't work properly.

Fetching with git is far slower than fetching prebundled archives, since it's O(all of repo history) rather O(requested revision). Having said that, I don't know if the sourceforge link is stable so we might be stuck with it.

The sha in the url does match the commit of the release-1.6.21 tag  [07c03d]

Looks like it might be available via github: https://github.com/mrjimenez/pupnp/issues/14

Graham Christensen<EMAIL_ADDRESS>writes:
I've merged this in to my roundup-14 branch, to be merged soon.

Thank you!


Use with AngularJS

Have you a solution to use it with AngularJS ?
I can't initiate mapster on an image in a controller... Maybe with a directive but i don't know how to do it.

Angular is not my thing, more of a ReactJS person. Think you best ask this on stack overflow.


Deploy Storybook on a sub-domain

Let's try and deploy Storybook on a sub-domain: > storybook.frontend.ro
It should auto-deploy on pushes on Master

Done! It's live on https://storybook.frontend.ro ^^^


.cirrus: bump python to 3.11 slim from 3.6 slim

3.11 brings lots of optimizations that would slightly increase the speed from 3.6. This also bumps deps used in requirements
(Please ensure you have read SUPPORT.md and docs/contributing.md before submitting the Pull Request)

Which issue should this PR solve?

Which problem should this PR solve?

No problem solved, just updating python and the requirements

Well CI doesn't exactly pass, so it adds a problem


293- Add Banner to recruit for ScPCA-nf

Issue Number
#293
Purpose/Implementation Notes
Added the banner to top of the portal for the ScPCA-nf recruitment.
Types of changes

New feature (non-breaking change which adds functionality)

Checklist

[x] Lint and unit tests pass locally with my changes

Tested on Chrome & FF.
Screenshots
N/A
Note
Introduced a new component Banner for a banner to make it more descriptive. Please let me know any suggestions, thank you.

I've tested the UI against Chrome and Firefox.
Any other browsers that should be included in the cross browser testing, please let me know. Thank you!

Could you test for the fixed navigation? I noticed the header looks misplaced when scrolling down on larger pages.

Adjusted, thank you!

(update)

Added the BannerContext and its hook to control the state of Banner and height of the parent container of fixed elements.
Adjusted Banner component accordingly.

Thank you!

Completed, thank you!

@davidsmejia  Reviewed your update and push some changes. Pls review and let me know if any questions(great update on Icon/Link components - now nicely optimized), thank you David!


chore(starknet_integration_tests): inherit sequencer node's stdout

This change is

#2427  👈 (View in Graphite)
main

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


How to track that a pdf file has been downloaded to a laptop?

Hi! How to track that a pdf file has been downloaded to a laptop?
I tried to put a function into .then(), but the function is triggered before the file is downloaded
const status = await html2pdf()
.set(opt)
.from(element)
.save()
.then(
console.log('ff')
);

.then() takes a function as an argument, to execute that function when the previous promise resolves, so you need to do this:
const status = await html2pdf()
.set(opt)
.from(element)
.save()
.then( () => {
    console.log('ff')
});


missing function append

in:
class VBucketAwareCouchbaseClient(object):

http://review.membase.org/#change,11170

hello,
maybe another commit: replacement of yours crc32.py to much, much faster
version:
import zlib
def crc32_hash(key):
return (zlib.crc32(key)>>16)&0x7fff
:-)
On Sat, Nov 26, 2011 at 6:37 PM, Farshid Ghods <
<EMAIL_ADDRESS>
wrote:

http://review.membase.org/#change,11170

Reply to this email directly or view it on GitHub:
https://github.com/couchbase/couchbase-python-client/issues/1#issuecomment-2882753


Translation of the README.md file.

Made this translation with an average English-speaking person in mind, while also correcting some minor grammar mistakes.

Thanks for your contribution, but we ended up using an internal translation. :+1:

That's fair, I can understand using a hired translator. However, I don't get it why you added the invalid label on this (and everyone else's) pull request. Now, because of that, the people who submitted a valid pull request won't have it counted towards Hacktoberfest. Really yikes move on your part.

You are totally right. I messed it up while cleaning the repo issues/PR. Thanks for pointing it out. :+1:


How to dump model formula ?

Is there a way to dump the model formula ?

I have done a little work to provide access to model coefficients, but got bogged down in trying to decide a good data structure to put them in.  model.coef_ should return an array, but in this case it is dependent on where in the feature space you are asking.Perhaps model.coef_(x)?  Or maybe model.coef_ returns a dictionary or arrays?  Or there will be a separate array describing the boundaries of each row from model.coef_?

I should add that the relevant commit is here:
https://github.com/ColCarroll/py-earth/commit/9640b593008d7db48c00aedee3552de3e2a679fd
and it gives a method labeled_coef_, whose output looks something like this (this is time series data, using the xlabels argument when fitting the model):
[{'(Intercept)': 23.331373525526406},
{'h(Date-899)': 0.039051102948551353},
{'h(Date-1186)': -1.4419994444986672},
{'h(Date-996)': 0.79201279381621625},
{'h(996-Date)': -0.80098522842398767},
{'h(Date-1254)': 0.98487709201589901},
{'h(Date-1547)': -1.2262192178089002},
{'h(1010-Date)': 0.78886444153185165}]

@ColCarroll Yes, it will help me. But in my case, instead of having usual hinge function 'h(x-constant)', I get 'C(x0|s=+1,200,350,525)'... And I don't know how to interpret this term...

I understand : it's due to "smooth=True".

And by formula, I expected something like model = 23.331373525526406 + 0.039051102948551353 * max(0, Date-899) -1.4419994444986672 * max(0, Date-1186) ... (My purpose is to reuse the model in a software code)

Your best bet for that specific output might be to either use that fork, or turn the method into a function, and use string formatting.  If @jcrudy has any suggestions for what he thinks the model parameters should look like, I'd be happy to submit a pull request (as this addresses issue #4).

@ColCarroll @fcoiffie Thanks for the input and code.  Here are some ideas for output formats.  There's no reason there can't be more than one of these:

Valid Python code
A sympy expression
A Python function
A PMML object (see augustus)
An ElementTree representing a PMML model
A human readable string
Valid code in languages other than Python (Java, C, etc.)

I'd appreciate feedback on these or any additional suggestions.  I'd also welcome implementations, but let's talk more before if you're going to spend significant time on it.  I have to think about how exactly the interface should work.  Probably just a method for each output format.  Something like to_py_code(), to_sympy(), to_py_func(), that sort of thing.  I should look at whether scikit-learn has something similar and whether this would impact compatibility.

@ColCarroll @jcrudy For my personal need, my request was inspired by this package : https://orange-multitarget.readthedocs.org/en/0.9.2/Orange.regression.earth.html
(I copy/paste the formula in my C code and I implement the max() with a macro but I agree this is not a generic need but it should work with many languages like Python, C, C++, Java, etc... I like earth algorithm because it fits well for embedded software as it requires only additions, multiplications and tests)

@fcoiffie That makes sense to me.  Would an option for right now be to write a new macro for the hinge function h(x)?

@jcrudy Yes, I can define a h(x) macro. But, the hinge function definition must be known by the user (or can be added in the py-earth doc). Even the Wikipedia page uses the max() notation in these examples : https://en.wikipedia.org/wiki/Multivariate_adaptive_regression_splines#The_basics

@fcoiffie Oh, yes, I absolutely agree.  Just wanted to make sure you have an option to move forward until I get my act together.  Py-earth is currently undergoing some changes related to scikit-learn compatibility, so it might be a while before I start adding new methods for exporting models.  I will start thinking about it, though.  And pull requests are definitely welcome. @ColCarroll
@mehdidc Do you have any comment on how model export methods discussed in this thread would impact sklearn compatibility?

@jcrudy sorry for late answer. To my knowledge, it's preferable to make all the methods private except the standard API methods. I would say one way to do this is to add functions export_* in earth.py like it is done in sklearn.tree.export_graphviz : http://scikit-learn.org/stable/modules/generated/sklearn.tree.export_graphviz.html

@mehdidc Thanks, that's a helpful example.  So, if I am understanding correctly, the sklearn compliant way to have this functionality would be to have the public interface be a separate function rather than a method of the Earth class itself.

I'm also interested in this issue - I'm struggling to figure out exactly how to extract the knot positions an linear segment gradients from the model result.
Also, from the scikit doc there isn't really a pattern for what you describe since there is just the one function. That said it would be logical for the model conversion function to be external to the model itself, that way you can implement any number of representations (as text, as parameters lists, etc) without clogging up the Model class with every kind of converter...

Just merged pull request #72 by @ColCarroll, which addresses this issue.  There are still plenty of other formats that could be exported into, but for now I think I will consider this issue closed.  If anyone has suggestions for other formats to export to, please feel free to open a new issue or pull request.
@mangecoeur Does @ColCarroll's work cover your use case?


Default GridFieldFilterHeader to MappedLink and Add Misdirection Permissions

In SilverStripe 4.4 the new GridFieldFilterHeader uses the first searchable_field as the default search column (for better or worst) so this makes the default something that will return some results.

+1 for this feature, we have content editors that are trusted enough to deal with redirects in the CMS.

@nglasl any update on this PR?

Bump.

This has now been merged into https://github.com/symbiote/silverstripe-misdirection, which will be considered the source of truth for packagist moving forward. Thanks heaps for the PR :)

This has now been merged into https://github.com/symbiote/silverstripe-misdirection, which will be considered the source of truth for packagist moving forward. Thanks heaps for the PR :)


Release update

Update release-package to allow for pull requesting the version bump against main since pushing to protected branch in GH does not have good support using actions.


Deprecated: allowed_block_types is deprecated since version 5.8.0! Use allowed_block_types_all instead.

Deprecated: allowed_block_types is deprecated since version 5.8.0! Use allowed_block_types_all instead.
l.11 includes/settings/acf.php

Updated!


BUG FIX: Game crashes as 'saves/endgameStats.json' does not exist

Integrate Stat Saving
Fixed a bug, when you first run the game it crashes, StatManager seems to be throwing a java.lang.NullPointerException upon loading into game, as it's trying to read from a file 'saves/endgameStats.json' which does not exist yet. Required to integrate saving of stats with the gamestate SaveHandler
To reproduce the error:

Delete endgameStats.json from /saves
Start game
Load into game

Seems like there are a few issues with compilation, please fix.

Got it


Visualizations in Instructor Course Dashboard

Describe the bug
As shown in the attached picture, there are two visualization (I guess) bugs in the Instructor View

A bullet point for nothing :)
A total number of -2 submissions that are not assessed

To Reproduce
Unclear. That's the state on the production instance.
Expected behavior
just visualization - no functional bug (hopefully :) )
Screenshots

What browsers are you seeing the problem on?
Firefox
Additional context
No response
Relevant log output
No response

Now it's -6  .. currently only more feedback requests and complaints getting answered :D
@FrankeLukas is this really a feature and not a bug :) ?


Remove year from example LICENSE file

Follows https://github.com/whatwg/sg/pull/132.

If we merge https://github.com/whatwg/html/pull/5668 first this won't affect HTML.

This has been propagated everywhere now.


Fastboot compatibility

Does not load the mousetrap library into the fastboot build
Skips binding keys if running inside fastboot
Skips unbinding keys if running inside fastboot

Hi, Thank you for a nice patch.
With this fix, I think that Uncaught Error: Attempting to inject an unknown injection: 'service: fastboot' error will occur in applications that do not add fastboot to dependency. So, we should check the global variable FastBoot (like this).

Looks good. I have released a new version. Thank you!
https://github.com/idobata/ember-mousetrap/releases/tag/v0.3.2


Update Full Text Search - Contains Function

Adjusting the Contains function with the quotes in the correct places

Thanks for the feedback, @wolfffelipe!

#sign-off


window.casperlabsHelper is undefined and the extension is not injected to the website in production build of react project

Describe the bug

The issue is that window.casperlabsHelper is undefined in production build of react project.
It works quite well on localhost, but after build the react project on server, it returns below error.
Uncaught (in promise) Error: Content script not found - make sure you have the Signer installed and refresh the page before trying again.
I have even installed the chrome extension - casperlabs signer, but not sure why this injecting script error is happening now.
Can you please clarify what the reason of the issue is? Thanks in advance.

Its undefined because (as you mentioned) the content script is not being injected.
This is working as intended - the Signer has a list of approved (integrated) sites held in the 'public/manifest.json'. For development purposes we have localhost included however, your production URL won't be there. This would cause the behaviour you're seeing with it working locally but not on the server.
If you'd like to have your site added please give us some background on your project (access to your code is appreciated) and obviously we'll need the URL(s) it will use.
Hope this helps, any questions feel free to ask here or on Discord!
Cheers
George

Closed by #158


Please allow for restic to be used as a "Go library"

Output of restic version
restic 0.15.2 compiled with go1.20.3 on darwin/arm64

What should restic do differently? Which functionality do you think we should add?
Restic does not only do a good job as a backup utility, but is also written in Go just as many cloud-native and Kubernetes-based tools / operators are. Allowing restic to be used as part of another application instead of spawning a Go binary from another Go binary would not only be more resource-efficient, but would also allow to have a better control about the state and behavior.
Restic has most of its logic as an internal package, which prevents other libraries from importing.
Please be less restrictive when it comes to declaring parts of restic internal to allow other projects to use restic as a library.

What are you trying to do? What problem would this solve?
I'd like to use restic as part of a larger construct (Kubernetes Operator) to automate different DR scenarios. I'd like to provide detailed information about the status, which could be easily achieved by a custom StatusReporter if this wasn't internal.
Other use-cases exist (see for example restic-robot), where a Go application spawns restic as another process, introducing overhead and the binary as additional dependency.
Adding more flexibility and use-cases would increase the potential for people to contribute back to restic and increase its overall popularity.

Did restic help you today? Did it make you happy in any way?
The flexibility to use restic even on Windows due to its Go nature is just perfect and makes a big difference when comparing it with other utilities like borg.

The problem with exposing the internals of restic is that this would cause a lot of internal interfaces to essentially become an official API. Quite a few of these APIs expect to be called in the correct way to be safe. It is currently also not feasible to give any guarantees whatsoever regarding stability of these interfaces. Providing such guarantees even for some of these interfaces would require a massive refactoring as preparation. The cmd/restic package currently also contains a significant amount of logic, which would have to be refactored first.
I understand the appeal of an API, however, I currently don't see how we could get there anytime soon with a reasonable amount of work.

Any updates on this issue?
I agree with the point that many packages are internal due to the stability consideration.
But is it possible to refactor cmd/restic as a package not as a main package?
If it is not in the main package, it is possible to call with go:linkname as a hacking method.
I think this could be refactored easier and sooner at this moment.

Would you, in general, accept a first pull request targeting the movement of some of the logic in cmd/restic into a new pkg/restic package?

I'm rather skeptical about that. The only thing in there that's remotely stable is the interface of the run* functions. However, these expect to be run as a separate program. At that level of abstraction it would be easier (more maintainable, ...) to just call restic as external binary.
And everything that's lower level would immediately require a significant amount of interfaces from interfaces from internal/ to be of any use. A low-level abstraction would also mean that high-level stuff like "backup" aren't readily available.
Can you be a bit more precise on what you have in mind?

Can you be a bit more precise on what you have in mind?

Sure. I'd consider a short-term and a long-term refactoring.
Short-term refactoring
Most users interested in this topic will probably be just interested in using restic from withing Go, instead of extending or modifying it. As some kind of low-hanging fruit, I'd therefore propose to create a simplified interface (to be understood as API, not * Go interface*) to the functionality currently provided by the cmd/restic package: Each of the CLI (sub-) commands should be invokable from Go, so the full error handling and runtime control part (e.g. context-passing) is controllable from outside. This follows the idea of the Go standard project layout for the /cmd packages:

It's common to have a small main function that imports and invokes the code from the /internal and /pkg directories and nothing else.

Long story short: I'd create a small abstraction layer for the CLI invocation that contains all the current logic of the cmd package to be used by both, the cmd/restic package and some external programmers. It would not allow to extend restic in any way (except for runtime aspects like custom ProgressPrinter), but become a starting point from using restic in existing Go-based applications and services.
This approach has 2 advantages imo:

We get a way faster result than refactoring large parts of the restic codebase
We get a simple interface for the future, to be used by those who just require the basic restic functionality in their applications

Long-term refactoring
restic exposes a stable interface around the low-level constructs like the Repository struct. This allows not only only to control restic, but also to extend it in a dynamic way - for example to allow backing up non-filesystem sources or extending the supported backend types.
This will - as you already stated out - require lots of work, and will continue to be an ongoing process for some time.
@MichaelEischer What do you think of this approach?

This follows the idea of the Go standard project layout for the /cmd packages:

The line before that states:

If the code is not reusable or if you don't want others to reuse it, put that code in the /internal directory.

I'd therefore propose to create a simplified interface (to be understood as API, not * Go interface*) to the functionality currently provided by the cmd/restic package: Each of the CLI (sub-) commands should be invokable from Go, so the full error handling and runtime control part (e.g. context-passing) is controllable from outside.

Is "simplified interface" intended to mean "a wrapper around the run* functions"? There are over 30 (!) such run* functions each accepting several unique options. That means a massive amount of wrapper code (even a pretty trivial wrapper would amount to 1k+ lines) which would have to be maintained. I don't have time for that; we're already barely able to keep the pile of PRs from growing.
There are also several parts of restic that work with global state such as the signal handlers used to handle SIGINT and SIGHUP or the way the lock refresh currently works. And don't forget the log output...
Neither wrapper function could provide a more structured output than right now, unless we start with a massive refactoring. All commands currently output text (or JSON if you're lucky) to stdout/stderr. In case of an error, restic exits with a non-zero exit code and prints a corresponding error message. And to cancel a restic operation just send it a SIGINT signal. Thus, the difference in functionality between the current CLI interface and a Go interface would be next to zero. The main difference would be that we as project end up having to maintain a Go interface that is actually a badly concealed CLI interface. Even worse, in contrast to independent restic child processes that interface won't be able to run multiple restic commands in parallel (that is, unless we massively refactor the code, once again).
So I really don't get what benefit this should provide. All I see is several months of work without any notable benefit.

(except for runtime aspects like custom ProgressPrinter)

Huh? That interface is tied to several internal data structures and is for sure not stable. It would also require some way to inject it.

@MichaelEischer I do see your points. As for the short-term, I do think to provide an interface to (most) CLI functions would provide a benefit for many, even if this means some abstractions / boilerplate code. Being able to control restic, maybe injecting a custom Context to abort an operation, would help to include it in other tools.
The whole discussion is just that I don't have too much time, either. I'm willing to start this, but only if you think that it has a real chance to get merged.

@MichaelEischer, for the short term, can restic provide a library for working with the repository?
Example of functionality:

Walk a snapshot: list files/directories
Find a file in the repository
Calculate the amount of Data deduplication
Calculate the amount of Index memory usage

Again, this is like asking for wrappers around snapshots, ls, and cat commands. But I think we will get some basic APIs to work with a restic repository.

@MichaelEischer, for the short term, can restic provide a library for working with the repository?
Example of functionality:
1. Walk a snapshot: list files/directories

2. Find a file in the repository

3. Calculate the amount of Data deduplication

4. Calculate the amount of Index memory usage

Again, this is like asking for wrappers around snapshots, ls, and cat commands. But I think we will get some basic APIs to work with a restic repository.

You can use the restic command and the JSON output format to get this information programmatically.

@MichaelEischer, for the short term, can restic provide a library for working with the repository?

Example of functionality:

1. Walk a snapshot: list files/directories

2. Find a file in the repository

3. Calculate the amount of Data deduplication

4. Calculate the amount of Index memory usage

Again, this is like asking for wrappers around snapshots, ls, and cat commands. But I think we will get some basic APIs to work with a restic repository.

You can use the restic command and the JSON output format to get this information programmatically.

This adds an overhead of add the restic binary as a dependency.
Also, quoting from the original issue:

Allowing restic to be used as part of another application instead of spawning a Go binary from another Go binary would not only be more resource-efficient, but would also allow to have a better control about the state and behavior.

This adds an overhead of add the restic binary as a dependency.

But it allows supporting only one interface (the CLI) as stable interface. The maintainers' bandwidth is limited.
What is the use case where adding the restic binary as dependency would be problematic?

The maintainers' bandwidth is limited.
Yes, agree. No debate on that.

What is the use case where adding the restic binary as a dependency would be problematic?
It's not problematic. It's an overhead.

From my experience, let's take the example of browsing a snapshot or multiple snapshots. Using the standard CLI interface with JSON is time-consuming and slow. This is because, every time we run a restic CLI command, it performs the following steps

Open the repository
Loads the index
List snapshots
Walk snapshot level
For each level of the tree, we would have to repeat steps 1 to 3, till we find our restic node

Now, if we have a simpler interface for the restic internals, we can do steps 1 to 3 and keep indexes, etc. ready for the intended operation.
As the number of snapshots increases in the repository and the indexes too, this operation becomes a more costly overhead. Do note, that even if the indexes are cached locally, they still have to be decrypted, decompressed, and deserialized. Also, consider scenarios, where caching is disabled, the indexes will have to be downloaded from a different location every time.
The only other proposal I have is to run the restic command as a server only for read operations, where commands like cat, snapshots, find etc. can be implemented and maintained simply.
I have seen some success in my personal experience. It's not too much overhead, I can share what I have done.

I see, you are right about the unnecessary steps.
I think that your second suggestion requires less work for the current status of the project, as it might be implemented as a dedicated command. Maybe together with #60 ? (e.g., a REST API that can be used directly or via an embedded web application). This interface will be available also to non-Go programs (in contrast to providing a Go library).
(don't get me wrong, I agree that the cleanest approach is to provide a Go library (and maybe a REST server over it). However, I don't see how to do that, except by doing a very slow and big refactoring)

This interface will be available also to non-Go programs (in contrast to providing a Go library).

This would be a good start. I will check out gh-60 and see if I can contribute in any way.

(don't get me wrong, I agree that the cleanest approach is to provide a Go library (and maybe a REST server over it). However, I don't see how to do that, except by doing a very slow and big refactoring)

Completely agree that it will take a long time. IMO it will provide a good base for long-term application use of restic. (it may also encourage new developers like myself to step forward and help maintain the project)

@Enrico204
Found this in the pull-requests
https://github.com/restic/restic/pull/4276
@ducalex  has already implemented something we discussed in this thread.

Just wanted to mention that if you don't rely on Go, there is rustic_core written in Rust. With a bit of work, it should be even possible to write a Go wrapper around that library, see e.g. https://words.filippo.io/rustgo/

@hellodword I don't understand at all what you're trying to achieve. Either way, that doesn't belong into this issue, either create a new issue or a forum post.

More on topic for this issue:
Would there be interest if we provided an UNSTABLE library interface for restic? (I'm serious about the unstable part, there will be incompatible changes in every restic version for the foreseeable future. So don't complain if your code breaks) It would at first be limited to several low-level interfaces like the backend and repository. I'm not sure yet whether the first iteration would provide write access or just read access.

More on topic for this issue:
Would there be interest if we provided an UNSTABLE library interface for restic? (I'm serious about the unstable part, there will be incompatible changes in every restic version for the foreseeable future. So don't complain if your code breaks) It would at first be limited to several low-level interfaces like the backend and repository. I'm not sure yet whether the first iteration would provide write access or just read access.

Why starting with low-level interfaces?
Shouldn't high-level interfaces (basically the cli commands with args passed as variables instead of strings) break less often? Or even more important, have the same breakage semantics as restic itself (major version bump if CLI interface changes in an incompatible way)?

Making the high-level interfaces available would require moving most code out of cmd/restic. And that unfortunately requires a lot of work (there are currently 16k lines of code in that folder, that might have to be touched).
There's also the question what a "high-level interface" is. Is it just a different way to call the CLI command or do we need a complete new set of interfaces? For example, prompting the user for a password doesn't make much sense when restic is used as library; but that could currently happen. And what about the CLI output? That definitely won't work for a library, so we'll need to restructure at least some of the code. (Although, one could argue that you can redirect stdout and just parse the output there, but then you can just as well call restic externally)

Can we start off with a simple HTTP API approach to provide repository read capabilities for common tasks; including listing snapshots, listing files (with some batching), listing tree and data blobs, find command etc.
Use a command like restic explore to start a simple HTTP server, which will load the index once and will have an API or an auto-refresh timeout, where it will find the missing indexes from memory and will load it. I've implemented this for one of my internal projects, but would be happy to share it with the community.
I've seen faster load times for things like listing snapshots and other simple read operations on the restic repository. The main issue I intended to solve with the simple HTTP server is the following point:

From my experience, let's take the example of browsing a snapshot or multiple snapshots. Using the standard CLI interface with JSON is time-consuming and slow. This is because, every time we run a restic CLI command, it performs the following steps

Open the repository
Loads the index
List snapshots
Walk snapshot level
For each level of the tree, we would have to repeat steps 1 to 3, till we find our restic node

Scripting operations for read operations on the repo have a significant overhead.
Example of proposed APIs:
LIST all snapshots
GET  /api/v1/repo/snapshots
Headers: X-RESTIC-PASSWORD: <repo-password>
Request Body: NA
Response Body:
[
  {
    "snapshotID": "ced56sds....",
  },
  {
    "snapshotID": "ad56sds....",
  }
]

LIST files in a snapshot
GET  /api/v1/repo/snapshot/files
Headers: X-RESTIC-PASSWORD: <repo-password>
Request Body:
{
"snapshotID":"<snapshot-id>",
"path":"path-to-filter:optional",
"skip": "<integer>",
"take": "<integer>"
}
Response Body:
[
{
"path": "/E/folder-1",
"name": "folder-1",
"mtime": "2023-02-21T19:24:58.4628969+05:30",
"type": "dir"
},
{
"path": "/E/folder-1/file-1",
"name": "file-1",
"mtime": "2023-02-21T19:24:58.4628969+05:30",
"type": "file"
}
]

Can we start off with a simple HTTP API approach to provide repository read capabilities for common tasks; including listing snapshots, listing files (with some batching), listing tree and data blobs, find command etc.

That looks rather similar to https://github.com/restic/restic/pull/4276 . For the use case you've cited, either the just mentioned PR or a WebDAV interface are the way to go.
Anything more than those interfaces adds yet another massive API surface to restic, which complicates everything. The previously mentioned refactoring of cmd/restic would still be necessary to not duplicate large amounts of code. Commands like find are also not particularly well suited for an HTTP API, as they are very long running.


Generate fragments as interfaces rather than classes

Is your feature request related to a problem? Please describe.
Given a query+fragment:
query GetUser {
   user {
      ...Profile
   }
}

fragment Profile on User {
   firstName
   lastName
   email
}

The (kotlin) generated types give data classes for all objects:
data class User {
   data class Fragments(val profile: Profile)
}
data class Profile

This makes accessing anything on the fragment very verbose: data().user.fragments.profile.firstName.
Describe the solution you'd like
If instead, the generated code were more like:
data class User: Profile

interface Profile

it would allow for the shorter: data().user.firstName

For what it's worth, I'm looking at something similar for the iOS codegen rewrite to represent fragments as protocols, although there's some crazy nonsense you can do with Swift protocols that I don't know will translate very well to Kotlin (or especially Java). Let me know if y'all wanna discuss at some point.

I believe there is a value of keeping the generated code closer in iOS and Android. This verbose behavior is the same on iOS, right?

Just to be clear, this feature is not really so simple to be implemented due to the nested subqueries. For instance:
query GetUser {
   user {
      id
      name
      ...Profile
      friend {
          name
      }
   }
}

fragment Profile on User {
   firstName
   lastName
   friend {
     name
   }
}

Should produce this:
  data class User(
     id,
     override firstName,
     override lastName
     override friend:Friend
 ): Profile {
    data class Friend: Profile.Friend(
      override name
    )
 }

And we can have very deep nested hierarchy tree. I'm not saying it's not feasible but it super complicated.
Another complication is when you have 2 fragments that will cause field merging:
query GetUser {
   user {
      id
      name
      ...Profile1
      ...Profile2
   }
}

Linking this issue to https://github.com/apollographql/apollo-android/pull/2478

We can close this issue as it was addressed in new 3.x version.

@sav007 Is the new 3.x version released?

Hi @gkylafas 👋
Version 3.0.0 is definitely not ready for showtime yet. It's missing a lot of features (on top of my head the Json stream parser and multiplatform cache but a bunch of others too). Polishing a new major release will take a bit of time as everything we add in there we will have to maintain in the long run. You can learn more in the Roadmap
That being said, we'd love to have your feedback! I'll setup snapshots on dev-3.x so it's easier to test until we make the cut for a 3.0.0.

@martinbonnin Indeed I would be interested in testing dev-3.x. We use 100% kotlin in our app and the whole .fragments. dance feels very ugly.
Thanks for keeping this issue open until 3.x is released.

Hi! I just merged https://github.com/apollographql/apollo-android/pull/2632. If everything goes well, SNAPSHOT should start appearing in ~40mins

Thanks for keeping this issue open until 3.x is released.

That's a tricky one! Historically, we've been closing issues when the corresponding pull request is merged. Also because this is what Github does by default when a PR mentions closes #XYZ or fixes #XYZ. I also understand the need to know when a fix is actually released. Is there a best practice there? I could add a comment on this ticket but that doesn't scale super well. We could try to automate it as well but that'll take some time. Any idea how to improve this workflow?

Snapshots are available: https://oss.sonatype.org/content/repositories/snapshots/com/apollographql/apollo/apollo-api/3.0.0-SNAPSHOT/
Use version 3.0.0-SNAPSHOT and:
repositories {
  maven {
    url = uri("https://oss.sonatype.org/content/repositories/snapshots/")
  }
}


IndexError: list index (0) out of range

Python version: 3.7
Source framework with version (like Tensorflow 1.4.1 with GPU): Tensorflow 1.15
Destination framework with version (like CNTK 2.3 with GPU): Pytorch
Pre-trained model path (webpath or webdisk path): http://www.mediafire.com/folder/hj7vo0v2afi3med,u54587g8g5vfs4g,fkn4s0i4u7m93iw,hvwac3wm1iiwi4a/shared
Hello, I have issues in converting this tensorflow model into pytorch model. I provide the checkpoint files in the link above. The error is the one of the title
Thank you in advance for the help

Hi @alex96295 , thank you for your feedback. I found that QueueDequeMany op in your model has an unknown output_shape which MMdnn cannot handle correctly. We will fix it in the future.

@XiaoXYe  thank you for your quick answer. I would have a couple of question, given the situation:

Do you know another method to convert a tensorflow model to pytorch? Would the conversion between tensorflow to ONNX be ok? So that I can read it using torch.onnx

About the model I gave you, do you know an easy-to-fix alternative that may work in my case using mmdnn? Because I am quite in a hurry to convert it, and I would need it asap

Nevertheless, still thank you for your effort

@alex96295 , our conversion has a intermediate IR form, so some special ops maynot be implemented in parser and emitter both currently.
Maybe you can try tf2onnx provided by onnx for conversion from tensorflow to onnx directly.

yes I am having a try, but I got some issues
Nevertheless, thank you :)


async support for "Channel" object - aenter and aexit function

For #7

Can you add a simple test case (or modify an existing test) for the new context manager interfaces?

The file is "tests\testclient.py"?

@lsching17 yes.

PR updated

@lsching17 yes.

unit test added

Can you add a simple test case (or modify an existing test) for the new context manager interfaces?

unit test added


Add support for Kotlin builtin arrays of primitives

Resolves https://github.com/ExpediaDotCom/graphql-kotlin/issues/90

Codecov Report

Merging #94 into master will decrease coverage by 1.6%.
The diff coverage is 56.25%.

@@             Coverage Diff              @@
##             master      #94      +/-   ##
============================================
- Coverage     84.83%   83.22%   -1.61%
- Complexity      144      145       +1
============================================
  Files            40       40
  Lines           455      477      +22
  Branches         90      105      +15
============================================
+ Hits            386      397      +11
  Misses           20       20
- Partials         49       60      +11

Impacted Files
Coverage Δ
Complexity Δ

...om/expedia/graphql/schema/generator/TypeBuilder.kt
92.3% <100%> (+0.3%)
9 <0> (ø)
:arrow_down:

...edia/graphql/schema/extensions/kClassExtensions.kt
100% <100%> (ø)
0 <0> (ø)
:arrow_down:

...xpedia/graphql/schema/generator/SchemaGenerator.kt
100% <100%> (ø)
26 <1> (+1)
:arrow_up:

.../graphql/schema/generator/types/ListTypeBuilder.kt
100% <100%> (ø)
3 <1> (+1)
:arrow_up:

...pedia/graphql/schema/extensions/kTypeExtensions.kt
38.46% <41.66%> (+38.46%)
0 <0> (ø)
:arrow_down:

...com/expedia/graphql/schema/generator/TypesCache.kt
80.85% <50%> (-9.15%)
27 <6> (-1)

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 496160e...8f840dd. Read the comment docs.


afterDelete Cloud Code works on Parse.com but not Parse Server

Hello!
Sorry if this is in the wrong place, please delete if it is. Fairly new developer here. I'm developing an iOS app which hasn't been released yet. I started on Parse.com and created a Parse Server install on Heroku with MLabs. My issue is I have a afterDelete hook in Cloud Code which works on my Parse.com app, but doesn't do anything on the Parse Server code. I have other cloud code function that still work, so cloud code generally is still running. Can anyone see anything obvious I am doing wrong, or could anyone suggest something I need to check outside my Cloud Code to explain this behaviour?
Here is my code:
Parse.Cloud.afterDelete("Lists", function(request) {
    var query = new Parse.Query("Posts");
    query.equalTo("listObjectId", request.object.id);
    query.find({
        success: function(posts) {
            Parse.Object.destroyAll(posts, {
                success: function() {
                }
            })
        }
    })
});

Thanks so much in advance!
Dan

Ah-ha!
I seem to have solved this. It seems you need to call useMasterkey inside the destroyAll function now. This now closed issue was helpful.
I also defined my server URL at the top of my cloud code, but I haven't experimented to see if this was necessary yet. For anyone interested my working code is:
Parse.Cloud.afterDelete("Lists", function(request) {
    var query = new Parse.Query("Posts");
    query.equalTo("listObjectId", request.object.id);
    query.find({
        success: function(posts) {
          Parse.Cloud.useMasterKey();
            Parse.Object.destroyAll(posts, {
                success: function() {
                }
            })
        }
    })
});

Hope that helps someone!


cmd/go: version information is not structured enough for use by developer tools

Developer tools need to know what version of Go is in use for a variety of reasons. Two examples that have come up very recently:

Gogland needs to know what language features to enable, such as vendoring and type aliases.
Delve needs to know details of the runtime, such as where to find the G pointer in a thread's registers, as well as what flags it can pass to the build system to generate good debug information.

If you're using a released version, it's relatively straightforward to parse the output of go version:
go version go1.8.3 linux/amd64 means you're running 1.8.3. But we also do release candidates, which say go1.8rc1, and then sometimes we build off dev tags and get something like go1.8.3.typealias. And then for even more fun, devel builds:
go version devel +835dfef939 Wed Jul 26 13:29:59 2017 +0000 linux/amd64
which doesn't help at all.
I don't have a specific proposal, but there is a clear need for a structured way of determining at least the major/minor Go version in use, even for devel builds. More detailed information in some form could be valuable if, for example, we wanted Delve to be able to tell if a devel build contained a specific runtime change. That's probably overkill though.

One possibility would be to put the release tags as a space-seperated list printed by go env:
So perhaps:
$ go env
...
GOTAGS="go1.1 go1.2 go1.3 go1.4 go1.5 go1.6 go1.7 go1.8"

For special SDKs like App Engine, they would have the appengine tag in that list. This provides Gogland with the information they need to determine properties of the toolchain that they are working with.

I was curious what ActiveGo does and their toolchain has the following version string:
ActiveGo 1803 [403309] provided by ActiveState Software, Inc.
Built Sun Jun 18 17:37:35 PDT 2017

go version go1.8.3 linux/amd64

Which, I'm guessing Gogland would also choke on.

The tags could be extracted from this file: https://github.com/golang/go/blob/835dfef939879b284d4c0f4e1726491f27e4f1ee/src/go/build/build.go#L295 but for example Delve would need to know that in the binary somehow.
As for the editors, for example, you might want to know if it's go 1.8.0 or go 1.8.3, as users of editors could then test different versions of Go and still be able to tell the difference between versions. Same goes for different beta / RC versions of go 1.9 for example.
Another case is when go tip might mean go 1.9 for the build tag which is based on the master branch and go tip of the debug branch that is also tracking go 1.9 and hence has the go 1.9 build tag?

As for the editors, for example, you might want to know if it's go 1.8.0 or go 1.8.3, as users of editors could then test different versions of Go and still be able to tell the difference between versions. Same goes for different beta / RC versions of go 1.9 for example.

Just checking if the version string doesn't match is sufficient to tell if they are different versions, right? In terms of feature sets, is there a case where you want to distinguish between go1.8.0 and go1.8.3? Typically the point releases changes nothing other than bugs.

While in theory 1.8.0 and 1.8.3 ought to be the same, in practice, who knows?  If we are going to introduce this kind of mechanism, it should probably have a way to report minor versions as well.

is there a case where you want to distinguish between go1.8.0 and go1.8.3

One use-case is when users are using currently Go 1.8.0 in their production servers and are testing Go 1.8.3 for upgrade. At that point there would be two Go releases which have the same Go 1.8 label but the user wouldn't know which is which.

@dsnet Technically Gogland parses zversion.go, so probably wouldn't be confused by the ActiveState banner, but hopefully we can agree that that is not a well-structured API. Delve might get confused if their parsing logic is overly specific; I haven't looked.
@dlsniper I'm not proposing we change go version itself, and tools could still use that to display the most descriptive version information to humans. This proposal is intended for the tools themselves to make decisions on, and I wouldn't expect its output to be shown directly to users. So, for Gogland, I would expect the text in the GOROOT dropdown to show the output of "go version", perhaps lightly interpreted, but vendoring to be enabled based on this structured information.
Possibly I should file a separate bug to expose the build tags, since that has some intrinsic value of its own entirely separate from this discussion.

I'm not proposing we change go version itself

@heschik sorry I was not clear about it, I don't propose this either. Also, see @zolotov's comment here: https://youtrack.jetbrains.com/issue/GO-4203#comment=27-2340685
Hope it helps :)

See alternative proposal over at #21209.

I interrupt this discussion to inform us that this issue is a duplicate of older issue https://github.com/golang/go/issues/11972 :) I'll mention that issue's author @griesemer so that he can chime in, as this issue seems to have more discussions going on.

I think build tags are the better solution to this.

On 29 Jul 2017, at 16:47, Emmanuel T Odeke<EMAIL_ADDRESS>wrote:
I interrupt this discussion to inform us that this issue is a duplicate of older issue #11972 :) I'll mention that issue's author @griesemer so that he can chime in, as this issue seems to have more discussions going on.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

As far as I am concerned this could be solved by just documenting the output format of go version and runtime.Version(). For delve the problem wasn't writing the parser, it was figuring out the syntax. And yes, delve will absolutely choke on ActiveGo version string because the version is at the end.
Proposal #21209 doesn't really help because it doesn't give the syntax used for tags, nor does it say where ActiveGo should put its banner.
Having a major.minor version for development build isn't as important, because there isn't almost any reason to support development version from before the latest major.minor release.

For better or worse, discussion seems to have moved to #21209.

The discussion on #21209 closed, and I think this one should close too. The examples in the original report are not something we should extract from the version strng. See the discussion on #21209 for more.

@rsc sorry, I do not fully understand, where required information should be extracted from then?

The discussion on #21209 closed, and I think this one should close too.

I find it strange that discussion #21209 was closed in favor of #21207 and #21207 is closing now because #21209 is closed.

Over in #21209, Chris wrote:

It seems that the takeaways from this thread are to focus on providing either build tags (go1.9) or capabilities (type-aliases, plugins) statically to allow tools to reliably toggle features. Closing this and moving discussion there.

Sorry, I thought that these more specific requests had been filed separately, but perhaps not. Certainly the title here - more structured version information in the version string - is not going to happen.
I was going to add a way to expose the build tags just now, but I realized that they are already accessible. To get build tags, you can use:
 go list -f '{{context.ReleaseTags}} {{context.BuildTags}}' runtime

or any other template walking over context (see go help list), such as
go list -f '{{join (context.ReleaseTags) ","}}' runtime

The package does not matter; you just have to list one, and runtime is as good as any.
So my suggestion would be to use that to get build tags and use knowledge of when a particular feature was released to decide to use it.

@rsc ReleaseTags will work for us, thank you. Although, as I mentioned in #21209 I'd prefer to get the same information in textual and easy to parse form, like in generated zversion.go, is this possible to put more structure version information or release tags information there?

Isn't the output of the go list commands above textual and easy to parse? I don't think IDEs should assume they know how the location of specific Go source code - gccgo doesn't even need to have standard library source code present, for example. But querying the go command is something we can keep working indefinitely.

Isn't the output of the go list commands above textual and easy to parse? I

It requires running an external binary. As I said in #21209, it's less predictable and harder to cache and to track changes.
Also, after indexing IDE actually knows the values of almost all constants in Go sources, running external tool for it looks like a double work.

I don't think IDEs should assume they know how the location of specific Go source code

This is what IDEs do, they assume locations of specific source code. For example, for navigation to anything or to infer type of an expression they need the knowledge where builtin types/vars/function are located. Or, where template helper-functions are defined (text/template/funcs.go#builtins) to suggest them in templates. The same is for version.

gccgo doesn't even need to have standard library source code present, for example.

The IDE requires sources at the moment. If someday we'll implement resolution algorithm against binaries, I think we will return to this question and likely will have to run the binary. Until then I would appreciate if at least major version of GOROOT or ReleaseTags would be easier to access.

For release builds you can of course read $GOROOT/VERSION. But for development trees I think the only thing that will be reliable is to use go list.


this.props.stop(): Is there a copilot function that stops the tutorial that we could use?

Is there a way to stop copilot without clicking the buttons from TooltipComponent (handleStop function)?
I would like to call handleStop or similar function and stop copilot before the app goes to the background/foreground.

Is this.props.stop in the wrapped component what you're looking for?

yes, it is. But how do I use it on the parent component like how we start copilot on the main screen using this.props.start()?
Calling this.props.stop() in the main component crashes the app. It does not have .stop() function when logging the props.
'PROPS', {      screenProps: undefined, 	navigation: {          dispatch: [Function],         state: { routeName: 'TasksAndGoals', key: 'id-1536975371061-1'      },         isFocused: [Function: isFocused],         addListener: [Function],         goBack: [Function: goBack],         navigate: [Function: navigate],         pop: [Function: pop],         popToTop: [Function: popToTop],         setParams: [Function: setParams],         getParam: [Function: getParam],         push: [Function: push],         replace: [Function: replace]      },     start: [Function: _callee4],     currentStep: null,     visible: false,     copilotEvents:{          on: [Function: on],         off: [Function: off],         emit: [Function: emit]      } }
Not sure how to use or retrieve this.state.stop.

Hi, any updates for .stop() on the main component?

Had to use it on my custom TooltipComponent and used handleStop function instead.
const TooltipComponent = ({ handleStop, currentStep }) => {     AppState.addEventListener('change', (nextAppState) => handleStop);     return(<View />); }

@mohebifar Does that sound like something we could easily integrate? Is it necessary?


CSS Bundle does not work when deployed to Vercel

What version of Remix are you using?
1.17.1
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
I've included a git repo where I have done the following:
https://github.com/dantman/remix-vercel-css-bundled-modules-bug

Run npx create-remix@latest
Select Just the basics, Vercel, TypeScript
Verify that root.tsx contains ...(cssBundleHref ? [{ rel: "stylesheet", href: cssBundleHref }] : []), (css-bundle is pre-configured in the default template)
Add CSS using an import that depends on the css-bundle
Verify your CSS works locally in npm run dev
Deploy to Vercel
Check that your CSS is working on the deployed Vercel site

Expected Behavior
Expected Vercel deployment to have same CSS as seen locally.
Actual Behavior
Bundled CSS and module CSS files that load when run in the dev server do not work when deployed to Vercel.

Local: Run npm run dev using https://github.com/dantman/remix-vercel-css-bundled-modules-bug
Vercel Deployment: https://remix-vercel-css-bundled-modules-bug-git-stock-dantman.vercel.app/

From what I can tell it seems like cssBundleHref is not defined when deployed to Vercel.

Looks like this is an issue on the Vercel side due to their Remix-specific build process. I'm currently reaching out to get it resolved. In the meantime I've verified that you should be able to fix this by rolling back to v1.17.0.

As noted above, this issue is currently fixed in the latest version.
Since this issue is caused by a version mismatch between @remix-run/css-bundle and Vercel's custom fork of @remix-run/dev which they only run in CI, I recently merged a PR that will go out in Remix v2 that decouples these two packages to avoid this issue re-emerging in the future: https://github.com/remix-run/remix/pull/6982.


All 3rd party deps should be optional

If a directive is used without the appropriate 3rd party lib throw an error with instructions.

dup #166


Make key type parameter in Flink's state request handler explicit

The key is always shipped as a ByteString, so we should get rid of the generic
parameter in the implementation.

Rebased to latest master.

Run Portable_Python PreCommit

Merging because this just makes the ByteString keys explicit, does not change any runtime logic.


Document Snyk Orchestration Features

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66ba63ab562461212faf04f2--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66cd5335310e997b1bbb98f2--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66ce0c31be29744bc4f95769--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66ce1377215411566bde0b11--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66cf104bba75084c1f9f3504--harness-developer.netlify.app


Invalid enc_request

Hi,
I tried your PS library for phpIpam and I get the following error:
New-PhpIpamSession : {"code":503,"success":0,"message":"Invalid enc_request","time":0.001}
In C:\Users\foo\Desktop\ipam\test.ps1:4 Zeichen:1
+ New-PhpIpamSession -useAppKeyAuth -PhpIpamApiUrl 'https://ipam ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,New-PhpIpamSession

The full url is https://ipam/api/?app_id=43543&enc_request=zLXkPGhy9VpOI2HpkZ8dpoZXDXtd60fbLRKk1z10R7c%3d

Check your appid and keys

From: Christoph<EMAIL_ADDRESS>Sent: Monday, November 19, 2018 6:59:38 PM
To: yoke88/PSPHPIPAM
Cc: Subscribed
Subject: [yoke88/PSPHPIPAM] Invalid enc_request (#4)
Hi,
I tried you PS library for phpIpam and I get the following error:
New-PhpIpamSession : {"code":503,"success":0,"message":"Invalid enc_request","time":0.001}
In C:\Users\foo\Desktop\ipam\test.ps1:4 Zeichen:1

New-PhpIpamSession -useAppKeyAuth -PhpIpamApiUrl 'https://ipam ...

  + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
  + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,New-PhpIpamSession

The full url is https://ipam/api/?app_id=43543&enc_request=zLXkPGhy9VpOI2HpkZ8dpoZXDXtd60fbLRKk1z10R7c%3D
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/yoke88/PSPHPIPAM/issues/4, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADAB8vzmlDgEtsmXspHNQMvGuCinSIjxks5uwo8agaJpZM4Yo3eN.

They are correct. It doesnt work because phpipam switched to openssl -> https://github.com/phpipam/phpipam/issues/2316#issuecomment-439944610
I've implemented the new auth mechanism already, so I'm closing this.


Database file is locked after close connection

First, create a new file and open it with Microsoft.Data.Sqlite.SqliteConnection
Then create tables and write records, and close the connection.
Finally try to delete the file, and it will fail.
This problem is not exists with System.Data.Sqlite.
OS is windows 8 64bit.

Could you share your repro code?

I try to reproduce this problem with a standalone project but it didn't happened.
The problem is releated to the other issue I opened about ReadCommited is unsupported, maybe I didn't close the connection when open transaction failed.
If I found the reason and if It need to be fix in Microsoft.Data.Sqlite I will reopen this issue.

I also have an issue with attempting to delete a sqlite database file after attempting to close the connection: https://github.com/aspnet/EntityFramework/issues/7021


[Toolkit feature]: A mod installer

Contact Details (Optional)
No response
What is the context of the feature/improvement?
...Could a finished mod have an installer option?
Please describe the feature/improvement?
...When a modder has completed their mod and is ready to share with end-users, could there be a "Installer/Setup.exe" option? For example, the Tomb Raider RTX mod came with an installer that simply asked for the end user to locate to their game directory. The mod would install of the mod assets into the game directory and make the appropriate folders. The installation process was seamless letting someone with no prior experience with Remix or the Runtime to download and play. Could remix have this option? An installer where the user just puts in their games directory and Remix gets the mods installed and the user plays as usual?
What would be your solution? (optional)
...
Version
2024.1.1

Hi @skurtyyskirts ,
Thanks for your feature. This feature is already planned ( REMIX-213 ).
We will keep you up to date.


Part disappear with controller when controller is disabled

For instance if a controller runs out of battery, three.js automatically removes it from the scene.
Since gripped parts are children of the controller, they get removed as well.
Whatever is done against this, it should happen here :
https://github.com/felixmariotto/art-salad/blob/8378c5fd47e80b26dcd9124ea6ee28136ece9cb7/src/controls/controls.js#L284-L295

done


Use FEMBeam.jl to analyze beam structures

Use FEMBeam.jl to solve beam problems. Added an example, where
natural frequencies of frequencies of 3d frame structure are
calculated. Some minor modifications to Modal analysis is done to make
Xdmf writing of 6 dof nodes work.

Coverage decreased (-0.5%) to 78.22% when pulling c66f2164ae38f3df8638a5be9d02fcbdb5ab1798 on FEMBeam/initial into 07adb1c58839e0cb2f498b6fcac177fbf4123efd on master.


Feature: DOM inspector "extras"

DOM inspector is great for development, but insufficient for test automation.
Test automation needs to allow setting extra dataset fields, typically to provide a testid and mark the focused element.

anything you set as a data field will be exposed as data- attribute by the inspector.
You can find it here:
https://github.com/lightning-js/renderer/blob/main/src/main-api/INode.ts#L423

Awesome @wouterlucas
It's mostly working: one issue is that it doesn't seem possible to clear a data attribute.
Our automation uses [data-focused] to identify the focused element. Setting data = { focused: '' } can set the value, but I can't "unset" it.

Also ideally it shouldn't set a field which has undefined value


feat: status check name

Fixes #12

@negebauer @mattallty Hey guys, thanks for this action! Is this check-name flag actually available to use? I see the latest release is v1.0.3, which does not appear to include this change
Also please add this option to the docs. Thanks!


Add there examples to the HBase book

It was exciting to hear about the new API. Unfortunately, the coverage of the new API in the document is far from 100%. It feels like failing to find out how to buy a new type of mobile phone after a great marketing campaign.

HBase project is always looking for documentation help. Better to take this issue over to https://issues.apache.org/jira/browse/HBASE


Remove return type from variant specification

The only reason we need to check this is that we allow you to write the "return type" for a variant. If we instead had:
#[flux::refined_by(b: bool)]
enum Option<T> {
    #[flux::variant([false])]
    None,
    #[flux::variant((T) -> [true])]
    Some(T)
}

then, this wouldn't cause any problems. Not in this PR, but we should consider changing the syntax.
Originally posted by @nilehmann in https://github.com/flux-rs/flux/pull/586#discussion_r1437115186

I'm assuming there are no GADT shenanigans possible?

Yes, there are no GADTs in Rust and I doubt it will ever be possible because of monomorphization. Although, in theory, you could change the type if it has the same layout. I guess you could change the refinement in each variant.
If we do remove the type from the syntax, I suppose it looks weird to specify the indices by position and maybe we should write the names.
#[flux::refined_by(is_some: bool)]
enum Option<T> {
    #[flux::variant([is_some: false])]
    None,
    #[flux::variant((T) -> [is_some: true])]
    Some(T)
}

This starts to look awfully close to the "external" index/measure notation with the difference that you write all the indices/measures at once.


Rename apache to hooks and prepare for release

I've renamed 'apache' to 'hooks' throughout (including reworking my plugin and including a very simple defaulting mechanism so a library of server/distro defaults can be built up over time), and prepared for release. My plugin tests are updated and passing, and the CLI has been working for me. So from my perspective, I'm happy to merge and  npm publish this, but I wanted to give you an opportunity to have a look first if you wanted to, so I made this PR.

I'm thinking to change these lines:
* `{{{cert}}}`: the path to the generated certificate: `hooks-path/token.crt`
* `{{{privkey}}}`: the path to the generated private key: `hooks-path/token.key`
* `{{{conf}}}`: the path to the generated config file: `hooks-path/token.conf`

to
* `{{{cert}}}`: the path to the generated certificate: `hooks-path/cert.pem`
* `{{{privkey}}}`: the path to the generated private key: `hooks-path/privkey.pem`
* `{{{conf}}}`: the path to the generated config file: `hooks-path/letsencrypt.conf`

I'd like to encourage the use of cert.pem, chain.pem, fullchain.pem, and privkey.pem as defacto standard naming conventions.
In the code are you outputting cert as certs.cert + certs.chain or are chain and fullchain missing?

That's probably doco error on my part. It should be hooks-path/{{{token}}}.crt etc., i.e. the token is substituted into the filename, the word token doesn't literally appear there. These are ephemeral files to meet the ACME challenge (a self-signed cert) and basically need to be stored keyed by token. They are created by set and deleted by remove. As the cert is self-signed, of course, there's no chain. (Actually, the private key is unnecessary in practice, too, because the server simply has to return the cert to satisfy the challenge; it doesn't actually have to perform any encrypted communication; but of course, server configuration requires a private key generally). We could use hooks-path/token/cert.pem etc. and make set and remove also create and remove the token directory I suppose. I didn't feel like it was worth it, though, since the files are temporary (unless a challenge is in progress, none of these files exist).

Makes sense. Agreed.


Is there a plan to add rbd csimigration controller in kubernetes?

Describe the feature you'd like to have
Add rbd csimigration controller in kubernetes.
What is the value to the end user? (why is it a priority?)
If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.
How will we know we have a good solution? (acceptance criteria)
This package contains a generic CSI migration controller that helps provider extensions that are still using the legacy in-tree volume provisioner plugins to migrate to CSI.
Additional context
Some in-tree storage plugins has already completed csimigration, and looks like there is no plan to add rbd csimigration controller in kubernetes's blog.

Currently, we don't have any plan to support migration.
@rootfs @gman0 any suggestion here?

No plans AFAIK, sorry.

just to add, here's the link to the issue. https://github.com/kubernetes/enhancements/issues/625
Is there a possibility of relooking into this in the future when all ceph csi functionality is stable?

just to add, here's the link to the issue. https://github.com/kubernetes/enhancements/issues/625
Is there a possibility of relooking into this in the future when all ceph csi functionality is stable?

Hello guys. I am the lead of CSI migration feature in Kubernetes. I think as long as you guys are sure that no current customers are still using the in-tree ceph rbd and cephfs volume plugin then it is fine.
Our plan moving forward is to remove the in-tree plugins. CSI migration is the feature in k8s that can support a smooth transition from in-tree usage to CSI usage for volume related operations. I dont think you guys need a csimigration controller running. But mainly a translation logic in the core k8s to get it work.
If any of you guys are interested doing migration for ceph fs and rbd driver. Please feel free to ping me on slack in k8s or attend the CSI migration meeting.
cc @humblec I heard about you are interested in doing migration for ceph fs and rbd. I am wondering if this is still the case?

Here is a kubernetes issue opened by humble and he seems to be working on it: https://github.com/kubernetes/kubernetes/issues/91246
Can you guys sync up to make sure what is the plan moving forward? Thanks a lot!

Migration cannot be supported due to  following reasons
With the new cephcsi design, the volumeHandle is the one unique to identify the backend volume, pool clusterID etc, AFAIK as with migration the  PV CSI volumeHandle is the rbd image/cephfs subvolume name. If we want to support we can support only mount/unmount and not even delete operation.
Below items are not supported if we migrate

Expand PVC
Create Snapshot
Create Clone
Delete Volume

cc @nixpanic @humblec

Migration cannot be supported due to following reasons
With the new cephcsi design, the volumeHandle is the one unique to identify the backend volume, pool clusterID etc, AFAIK as with migration the PV CSI volumeHandle is the rbd image/cephfs subvolume name. If we want to support we can support only mount/unmount and not even delete operation.

Just to summarize, these migrated volumes comes almost in the same state of static volumes support we provide here with CSI driver . Its one form and accepted mostly at times considering the origin of volumes/how its provisioned at very first stage.  In short thats the same case with static volumes today we offer. So, leaving advanced feature support on such volumes is fine .
Even we could think about further treatment on those volume support with an extra controller later. But, the main point of the discussion was that, is it a worth effort?
Due to the long existence of this CSI driver and  external provisioner for Ceph  drivers, many users are out of in tree plugins any way.
So, we are leaning towards mostly to mark the in tree driver for deprecation. but will double confirm it soon @Jiawei0227

With the community feedback and requirements this has been planned for kube v1.23 and kubernetes KEP is available here https://github.com/kubernetes/enhancements/issues/2923  .
Reopening this issue as this has been getting worked on which should allow all existing in tree users to have a smooth migration path... we need few changes in the CSI driver too.


Security issues

FYI I enabled Dependabot on my fork of the repo and it found some issues you may wish to address:

Hi,
By default, Dependabot will notify people with write, maintain, or admin permissions in the affected repositories about new Dependabot alerts. GitHub never publicly discloses insecure dependencies for any repository, since opening potentially critical security concerns as GitHub issues contradicts responsible disclosure. Essentially, code analysis tools that search for vulnerabilities can be used by attackers to identify attack vectors, and it's responsible to give the authors of community software a chance to address the vulnerability before potential attackers, usually by email.
Furthermore, each Dependabot alert should be individually examined to see if its affected usages intersects with the actual usage of the project. These four alerts belong to the Python packages certifi, urllib3, and requests.
For GHSA-g4mx-q9vg-27p4 , we're not submitting sensitive information in the HTTP request body.
For GHSA-j8r2-6x86-q33q, we're not proxying requests with credentials supplied in URL user information components.
For GHSA-v845-jxx5-vc9f, we're not using the Cookie header on requests.
For GHSA-xqr8-7jwr-rhp7, if the e-Tugra root certificate is compromised it still won't make it past Mastodon's own TLS host identification.
Finally, the most relevant aspect of any advisory is the patches, remediations and workarounds available. For these, the answer in every scenario is to update the Python packages in requirements.txt to a patched version (or the most recent compatible version, whenever possible). It can sometimes be helpful to update these packages on your fork, test the project to make sure it still works correctly, and then submit a PR with the patched versions in requirements.txt.
I don't think there's any breaking changes with these upgrades, so they'll probably be updated eventually, but until then these particular issues shouldn't pose any security hazards for users of this project.

Thanks @Teqed for the detailed write up.
I had a brief look at the screenshot @lnlyssg shared, and based on the titles didn't actually think that any of these sounded like issues that actually impacted this repo, so sort of mentally de-prioritised this issue.
I'm very happy to accept a PR with updated dependencies though, so if either of you want to file this, I'll be grateful.

Apologies for posting publicly, I wasn't really thinking about responsible disclosure when I made the post but that's no excuse.

I don't think you did anything wrong here, to be honest.

I have now enabled dependabot myself and merged all it's PRs so consider this fixed.


Newer release available antlr4_runtimes: 4.9.1 (current: 4.7.2)

        Package Name: {dep}
        Current Version: {metadata_version}@{release_date}
        Available Version: {tag_name}@{created_at}
        Upstream link: https://github.com/{package_repo.full_name}

New version is available for this package
New Version: 4.9.2@2021-03-11 22:18:16
Upstream Link: https://github.com/antlr/antlr4


[New Port Request] nyan

Library name
nyan
Library description
nyan is a data description language, It is a mixture of python, json, patch, wml, yaml and some new ideas.
Source repository URL
https://github.com/SFTtech/nyan
Project homepage (if different from the source repository)
No response
Anything else that is useful to know when adding (such as optional features the library may have that should be included)
No response

Updated PR


Missing Buffs/Debuffs/Objective Tracker

Description

The player buffs and debuffs are absent from my UI. The objectives window that's normally under the minimap is missing. They didn't disappear. Neither elements were present when I first installed the addon.
Version Number

1.2.58
Only DiabolicUI Enabled

The issue still exists when DiabolicUI is the only addon enabled.
Additional Information

The issue was present on both computers that I downloaded the addon to. I've tried reinstalling the addon a few times.

User here; haven't had this problem with git master which should be similar. I'll try to confirm with your specific version later!
Have you used a previous version of the addon? If so, it might be worth a shot to delete settings saved to your account in WTF/Account//SavedVariables/DiabolicUI.lua

I'll try this now thank you!

Unless something weird happens because of an error elsewhere, that code is there to help support various monitor layouts and resolutions and such. I am assuming it for some reason fails to get your screen resolution from the game client.
I'm not very familiar with the code, so it's probably best to wait for @goldpaw to get a proper solution. Posting the number of monitors you have and their resolution would be helpful though!
If you feel adventurous, I put up a branch with debugging prints and (possibly) a temporary solution here: https://github.com/dualcoding/DiabolicUI/tree/debugging

If you copy-paste this in the chat window, the output would likely be useful as well: "/run print(GetCurrentResolution(), GetScreenResolutions(), GetCVar("gxMonitor"))" (without quotes)
What this does is ask WoW to print the currently selected resolution number, the list of available resolutions, and (I think) the monitor index that the game is running on.

Never seen that code create a nil bug before, but I assume my aura module requests the information about pixel sizes too early in the loading process, and thus causing the bug for some. I'll look into it!
Having that said, that code is there to help with those using triple monitor setups in WoW. WoW doesn't support this, so it'll stretch the UI out across all the 3 screens. That script keeps the UI on the center screen instead, like everybody in their right mind would want it to! :D
The bug is unintentional, though. ;)

This will be fixed in the upcoming 1.3 release.

After reading your comments about the resolution messages, I switched both computers to Windowed Fullscreen instead of Windowed and the buffs/objectives appeared. Thank you very much.


Merging jack-sys

@wmedrano and myself have been added as owners of the jack-sys crate. We should publish a new version that lives in this repo and has updated bindings (including the fn -> unsafe fn changes that are currently keeping this repo pinned against mine own fork of jack-sys.

To clarify, jack-sys should remain its own crate, but the code should live in this repository.

Sounds good.

#27


Update ds3231.ino

I've just adjusted the comment to correctly and more clearly explain what TimeSpan() accepts and what the example values are doing.
There are no actual code-based changes but I think for a novice, the suggest comment change is less confusing than what's currently there.
Currently, the comment says it will add 7 days and 30 seconds to the time, but it actually add 7 days, 12 hours, 30 minutes and 6 seconds.
I probably actually should've adjusted line 62 Serial.print() to reflect the alteration.

Good catch, adjust line 62 as well and we can merge this.


Client rewrite

This PR is a complete rewrite of the Copycat client to address test issues mentioned in #97. Previously, the client took a naive approach to submitting and resubmitting commands to the cluster and recovering lost sessions. The client would resubmit commands across sessions with sequence numbers for the original session, thus leading effectively to a "live lock" wherein the cluster could not progress because of improper command sequencing. Additionally, the original client attempted to use time to expire its own session.
The improved client present in this PR is a complete rewrite of the CopycatClient. The client's internals were separated into multiple separate, testable classes and tests with mocking were written for each of the internal helper classes. The new client tracks and exposes client state information in a manner that allows users to react to the client's state. It adds a CopycatClient.State enum which indicates whether the client is CONNECTED, SUSPENDED, or CLOSED. The SUSPENDED state is the most notable state in that it indicates that the client is unable to contact the cluster, though its session may not necessarily be lost. While the client is in the SUSPENDED state, it will continue to attempt to contact the cluster and keep its session alive. Once the client reestablishes communication with the cluster, it will determine whether its session was expired and, if so, can recover its session via a RecoveryStrategy.
Additionally, this client handles resubmitting commands in the client's program order across sessions quite gracefully. In the event that the client's session expires and the client must reopen a new session, the first action taken once a new session is opened will be resubmission of the pending commands from the prior session.
This PR improved the reliability of Copycat's cluster tests significantly. The goal of this PR, of course, is to completely and reliably eliminate test failures. Thus far, it seems all remaining test failures are actually minor issues with how the test LocalTransport handles some failures.

There seems to be an issue with one remaining test, the leader kill test. But seeing as how this is a huge improvement over the current master branch, I'm merging this and will address remaining issues separately.


Integrate RoadMap component

This PR proposes the product map as a gatsbyjs compatible component. There are still issues/bugs with the implementation, but should be fixable by revising the way that the files call/integrate resources. I can provide more detail this week, but there are many moving parts to this, which is why I opted for a direct PR.

Update for @tuduun, @Ochirsaikhan, and @BillOchieng -- the work tree to merge from integrate-map to datajson.


Cannot launch unsigned Code anymore

➜  Downloads ./Visual\ Studio\ Code\ -\ Insiders.app/Contents/MacOS/Electron
Error: Could not get code signature for running application
    at Error (native)
    at t.initialize (/Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:8:910)
    at y (/Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:9:11731)
    at /Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:9:14216
    at Object.p [as _notify] (/Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:4:31912)
    at Object.__dirname.undefined.N.enter (/Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:5:3053)
    at __dirname.undefined.t.Class.define._run (/Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:5:4879)
    at __dirname.undefined.t.Class.define._completed (/Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:5:4320)
    at Object.p [as _notify] (/Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:4:31912)
    at Object.__dirname.undefined.N.enter (/Users/isidor/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/electron-main/main.js:5:3053)

Try catch this sucker.

@joaomoreno where can I put a try catch in order to catch this? The crash happens before vscode is even started

Rewrote my comment.