Destructuring Assignment Error When Implementing sanity-plugin-cloudinary in a Next.js and Sanity Project

Describe the bug
I'm trying to implement the cloudinarySchemaPlugin from the sanity-plugin-cloudinary package in my Sanity project. However, I'm encountering an error:
Error: Right side of assignment cannot be destructured
responsiveStackSpaceStyle@
_e@
@
@
@
renderWithHooks@
updateForwardRef@
beginWork@
performUnitOfWork@
workLoopSync@
renderRootSync@
recoverFromConcurrentError@
performSyncWorkOnRoot@
flushSyncWorkAcrossRoots_impl@
flushSyncWorkOnAllRoots@
processRootScheduleInMicrotask@
@

This error occurs when navigating to the resource where the cloudinary.asset is defined.
To Reproduce
Steps to reproduce the behavior:

Install sanity-plugin-cloudinary using pnpm add sanity-plugin-cloudinary.
Import cloudinarySchemaPlugin in the Sanity configuration file and add it to the plugins array.
Declare a field to be cloudinary.asset in the schema.

const lesson = {
  name: 'lesson',
  title: 'Lesson',
  type: 'document',
  fields: [
    {
      name: 'title',
      title: 'Title',
      type: 'string',
    },
    {
      name: 'slug',
      title: 'Slug',
      type: 'slug',
      options: {source: 'title', maxLength: 96},
    },
    {
      name: 'url',
      title: 'URL',
      type: 'url',
    },
    {
      type: 'cloudinary.asset',
      name: 'image',
      description: 'This asset is served from Cloudinary',
    },
    {
      name: 'content',
      title: 'Content',
      type: 'array',
      of: [{type: 'block'}],
    },
  ],
}

export default lesson

Run the project.

Expected behavior
I expected the cloudinarySchemaPlugin to be implemented successfully without any errors.
Screenshots

Which versions of Sanity are you using?
'2023-11-08'

What operating system are you using?
Darwin laurosilvacom 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64

Which versions of Node.js / npm are you running?
9.2.0
v19.3.0

Additional context

Next.js: "next": "14.0.4"
React: "react": "^18.2.0"
Sanity: "sanity": "^3.21.3"

These are the versions of the packages that my project is currently using.

BTW: When these kind of issues arise (conflicts of dependencies), you can just make sure both are installed like this:
npm i  --legacy-peer-deps


Update yafw extension

Description

Screencast

Checklist

[ ] I read the extension guidelines
[ ] I read the documentation about publishing
[ ] I ran npm run build and tested this distribution build in Raycast
[ ] I checked that files in the assets folder are used by the extension itself
[ ] I checked that assets used by the README are placed outside of the metadata folder

Duplicate of https://github.com/raycast/extensions/pull/12201


Force None inputs/arguments/outputs to an empty dict

We run a lot of loops through parameters and artifacts when creating workflows with executors. It would be helpful, and make executor code cleaner, to be able to assume that inputs, arguments and outputs are never None but instead:
parameters: []
artifacts: []

Kill the Nones !:>


coredump lsquic_engine_process_conns's nested calls  are not supported.

When the server active sending data to client, using lsquic_engine_process_conns function.
#0  0x00007fc3e28da337 in raise () from /lib64/libc.so.6
#1  0x00007fc3e28dba28 in abort () from /lib64/libc.so.6
#2  0x00007fc3e28d3156 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007fc3e28d3202 in __assert_fail () from /lib64/libc.so.6
#4  0x0000000000444af3 in lsquic_engine_process_conns (engine=0x7fc3c4008680) at /home/wangweiwei/zxquic/quic/src/liblsquic/lsquic_engine.c:2012
#5  0x0000000000416899 in prog_process_conns (prog=0x7fc3c4000d20) at /home/zxin10/msghub/source/msgdis/src/prog.c:467
#6  0x0000000000416951 in prog_timer_handler (fd=-1, what=1, arg=0x7fc3c4000d20) at /home/zxin10/msghub/source/msgdis/src/prog.c:497
#7  0x00000000004355cc in event_process_active_single_queue (base=base@entry=0x7fc3c40083e0, activeq=0x7fc3c40083c0, max_to_process=max_to_process@entry=2147483647,
endtime=endtime@entry=0x0) at event.c:1697
#8  0x0000000000435e67 in event_process_active (base=0x7fc3c40083e0) at event.c:1789
#9  event_base_loop (base=0x7fc3c40083e0, flags=0) at event.c:2012
#10 0x0000000000416ade in prog_run (prog=0x7fc3c4000d20) at /home/zxin10/msghub/source/msgdis/src/prog.c:533

This is strange: the backtrace does not contain a nested call.
The assertion on line 2012 of lsquic_engine.c is not about nested calls:
1996 static void
1997 drop_all_mini_conns (lsquic_engine_t *engine)
1998 {
1999     struct lsquic_hash_elem *el;
2000     lsquic_conn_t *conn;
2001     struct cid_update_batch cub;
2002
2003     cub_init(&cub, engine->report_old_scids, engine->scids_ctx);
2004
2005     for (el = lsquic_hash_first(engine->conns_hash); el;
2006                                 el = lsquic_hash_next(engine->conns_hash))
2007     {
2008         conn = lsquic_hashelem_getdata(el);
2009         if (conn->cn_flags & LSCONN_MINI)
2010         {
2011             /* If promoted, why is it still in this hash? */
2012             assert(!(conn->cn_flags & LSCONN_PROMOTED));
2013             if (!(conn->cn_flags & LSCONN_PROMOTED))
2014                 cub_add_cids_from_cces(&cub, conn);
2015             remove_conn_from_hash(engine, conn);
2016         }
2017     }
2018
2019     cub_flush(&cub);
2020 }

Are you using a modified version of lsquic?

This is strange: the backtrace does not contain a nested call.
The assertion on line 2012 of lsquic_engine.c is not about nested calls:
1996 static void
1997 drop_all_mini_conns (lsquic_engine_t *engine)
1998 {
1999     struct lsquic_hash_elem *el;
2000     lsquic_conn_t *conn;
2001     struct cid_update_batch cub;
2002
2003     cub_init(&cub, engine->report_old_scids, engine->scids_ctx);
2004
2005     for (el = lsquic_hash_first(engine->conns_hash); el;
2006                                 el = lsquic_hash_next(engine->conns_hash))
2007     {
2008         conn = lsquic_hashelem_getdata(el);
2009         if (conn->cn_flags & LSCONN_MINI)
2010         {
2011             /* If promoted, why is it still in this hash? */
2012             assert(!(conn->cn_flags & LSCONN_PROMOTED));
2013             if (!(conn->cn_flags & LSCONN_PROMOTED))
2014                 cub_add_cids_from_cces(&cub, conn);
2015             remove_conn_from_hash(engine, conn);
2016         }
2017     }
2018
2019     cub_flush(&cub);
2020 }

Are you using a modified version of lsquic?
Oh, sorry, I didn't describe it clearly.Now I have two routine , one is:
prog_run, in prog_prep register prog_timer_handler--->prog_process_conns--->lsquic_engine_process_conns
and another one is:
lsquic_stream_wantwrite(st_h->stream, 1);
lsquic_engine_process_conns(st_h->client_ctx->prog->prog_engine);
the two routines conflict

My version is old, and the 2012 line in lsquic_engine.c is ENGINE_IN

How old is your version?  Can you try with the new version of lsquic?
What do you mean when you say that you have two routines?  Are you using the same engine object from multiple threads?

My version is old, and the 2012 line in lsquic_engine.c is ENGINE_IN

How old is your version? Can you try with the new version of lsquic?
What do you mean when you say that you have two routines? Are you using the same engine object from multiple threads?

Oh, I know the problem. I use the lsquic_engine_process_conns function if multiple threads. lsquic_engine_process_conns  can't be used in multiple threads.

The same lsquic engine instance should not be used concurrently from multiple threads.  To do so safely, you have to take a lock.


SAA-554 initial commit to introduce finer grained feature switching, particularly around sending and receiving events.

Codecov Report
Patch coverage: 75.00% and project coverage change: +2.77 :tada:

Comparison is base (33e6382) 78.10% compared to head (50fb0f9) 80.88%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #248      +/-   ##
============================================
+ Coverage     78.10%   80.88%   +2.77%
- Complexity     1343     1398      +55
============================================
  Files           235      236       +1
  Lines          6021     6031      +10
  Branches        199      199
============================================
+ Hits           4703     4878     +175
+ Misses         1210     1045     -165
  Partials        108      108

Impacted Files
Coverage Δ

...activitiesmanagementapi/service/EventsPublisher.kt
43.47% <60.00%> (+39.47%)
:arrow_up:

...psactivitiesmanagementapi/service/EventsService.kt
76.78% <60.00%> (+1.31%)
:arrow_up:

...sactivitiesmanagementapi/config/FeatureSwitches.kt
100.00% <100.00%> (ø)

... and 20 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


[BUG]: checkout task not pulling remote repo within same organization

Task name
checkout
Task version
latest
Environment type (Please select at least one enviroment where you face this issue)

[ ] Self-Hosted
[X] Microsoft Hosted
[ ] VMSS Pool
[ ] Container

Azure DevOps Server type
dev.azure.com (formerly visualstudio.com)
Azure DevOps Server Version (if applicable)
No response
Operation system
ubuntu-latest
Task log
Starting: Checkout my-repo@devops to app/frontend
==============================================================================
Task         : Get sources
Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
Version      : 1.0.0
Author       : Microsoft
Help         : [More Information](https://go.microsoft.com/fwlink/?LinkId=798199)
==============================================================================
Repository is current at '/home/vsts/work/1/s/my-repo', move to '/home/vsts/work/1/app/frontend'.
Repository will be located at '/home/vsts/work/1/app/frontend'.
Syncing repository: my-repo (git)
git version
git version 2.41.0
git lfs version
git-lfs/3.4.0 (GitHub; linux amd64; go 1.20.6)
git init "/home/vsts/work/1/app/frontend"
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
Initialized empty Git repository in /home/vsts/work/1/app/frontend/.git/
git remote add origin<EMAIL_ADDRESS>git config gc.auto 0
git config --get-all<EMAIL_ADDRESS>git config --get-all http.extraheader
git config --get-regexp .*extraheader
git config --get-all http.proxy
git config http.version HTTP/1.1
git --config-env=http.extraheader=env_var_http.extraheader fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1 +f3aa7164f112669fe0aae075787f0917b4287713:refs/remotes/origin/f3aa7164f112669fe0aae075787f0917b4287713
remote: TF401019: The Git repository with name or identifier my-repo does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'https://dev.azure.com/my-org/my-project/_git/my-repo/' not found

Relevant log output
remote: TF401019: The Git repository with name or identifier my-repo does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'https://dev.azure.com/my-org/my-project/_git/my-repo/' not found

Aditional info
The first time I ran my pipeline, I got the authorization request to access the remote repository. I authorized it with no issues.

The repo `my-repo` is hosted within the project `my-project`, which in turn is on the same organization (`my-org`) as the project/repo that is executing this pipeline

resources:
  repositories:
  - repository: frontend
    type: git
    name: my-project/my-repo

jobs:
  job:
  - checkout: frontend
    path: 'app/frontend'

Hi @peanutsguy, Seems like you don't have permission to read from the repository, could you check that the user who runs the pipeline has read access in the project settings?


Adding default hook and context configuration to the project and unit test code injection

Pull Request
Problem

It was not possible to define default hooks for unit tests. This is now possible and is useful when using multiple test suites.
It was not possible to inject code into the test itself, so it would run inside the unit test try/catch. This might be useful for some assert libraries that keep a record of multiple asset fails per unit test and throw them at the end of the unit test.

Solution
I created a couple global variables that can be set to the desired hook functions.
For code injection the respective functions are called before and after the call to the main test function.

Pull Request
Problem

It was not possible to define default hooks for unit tests. This is now possible and is useful when using multiple test suites.
It was not possible to inject code into the test itself, so it would run inside the unit test try/catch. This might be useful for some assert libraries that keep a record of multiple asset fails per unit test and throw them at the end of the unit test.

Solution
I created a couple global variables that can be set to the desired hook functions.
For code injection the respective functions are called before and after the call to the main test function.

Hey @DiasFranciscoA, thanks for the PR! I took a look at it and here are my thoughts:

Yep, a good idea to let users define the default hooks for unit tests. I can certainly merge that in.
For the code injection inside the try/catch, your current implementation only works if the test is a sync test with olympus_add_test(), but not for olympus_add_async_test() and olympus_add_async_test_with_user_feedback().

We could get around this issue for _start_code() by moving it up to the beginning of try/catch, but _end_code() is trickier to do for the async case. You mentioned that you want code injection to support the use case of other assert libraries. Can you provide some context and samples of those libraries, so that I can see how we can accommodate it?


Fix when connecting/disconnecting to/from default gw network

Restoring original behavior where on disconnect
from overlay network (only connected network), it also
disconnects from default gw network.
On sandbox delete, the leave and delete of each
endpoint is performed, regardless of whether the endpoint
is the gw network endpoint. This endpoint is already
automatically removed in endpoint.sbLeave()
Also do not let internal network dictate container does
not need external connectivity. Before this fix, if a container
was connected to an overlay and an internal network, it may not
get attached to the default gw network.

Signed-off-by: Alessandro Boch<EMAIL_ADDRESS>

LGTM


Block breaking not correctly handled server-side

Attempting to break blocks in survival mode with a tool in hand is not handled correctly by the server. The error message *packet.PlayerAuthInput: unknown value '9' for enum type 'stack request action type' is shown.

Updating dragonfly to the latest gophertunnel version should fix this.


Something More Than ReLU6

is it possible to set a parameter to change the max_value instead of setting it as a default vaue 6?

Hello, the problem has been received, we will arrange someone to analyze it

sorry, mindspore has only relu6 and relu.

is it possible to add max value as a parameter in relu?

I figure out a way by combining some mindspore's operator
a demo as following:
from mindspore import Tensor, ops
import numpy as np

def relu_num(input, num=6):
    up_bound = num
    input = ops.ReLU()(input)
    mask_down = ops.le(input, up_bound)
    mask_up = ops.gt(input, up_bound)
    output_down = input * mask_down
    output_up = up_bound * mask_up
    output = output_down + output_up
    return output

input = Tensor(np.arange(-10, 10))
output = relu_num(input)
print(f"input = {input}")
print(f"output = {output}")

you may find more elegant way to implement relu6 or relu10086 or relu_any_number,
but i kind of doubting (just doubting) the diff, because, with my intuition, the relu6's point is just
erasing the grad-variation out of the boundary (of upper side). And the network's parameters would
evolve by optimization so that erase the diff of the boundary.

The operator writing style:
class ReLUn(nn.Cell):
    def __init__(self, up_bound: int):
        super(ReLUn, self).__init__()
        self.up_bound = up_bound

    def construct(self, input_x):
        input_x = ops.ReLU()(input_x)
        mask_down = ops.le(input_x, self.up_bound)
        mask_up = ops.gt(input_x, self.up_bound)
        output_down = input_x * mask_down
        output_up = self.up_bound * mask_up
        output = output_down + output_up
        return output

input = Tensor(np.arange(-10, 10))
output = ReLUn(6)(input)
print(f"input = {input}")
print(f"output = {output}")

>>> input = [-10  -9  -8  -7  -6  -5  -4  -3  -2  -1   0   1   2   3   4   5   6   7
            8   9]
>>> output = [0 0 0 0 0 0 0 0 0 0 0 1 2 3 4 5 6 6 6 6]

I found that mindspore has already support clip_by_value.  So the most directly way i found so far is:
class ReLUn(nn.Cell):
    def __init__(self, up_bound: int):
        super(ReLUn, self).__init__()
        self.up_bound = up_bound

    def construct(self, input_x):
        return ops.clip_by_value(input_x, Tensor(0), Tensor(self.up_bound))


Add run_timestamp to TestRecord

This will be automatically set when the TestRecord is created, and is serialized in a human readable form.

This looks good. Is there a reason we prefer a local, TZ aware datetime to a GMT datetime?

This was entirely for human readability. To be unambiguously GMT I think we'd either need to write seconds since epoch or include the TZ for GMT. Making it local then makes the times intuitive.


Uncaught TypeError: Cannot read property 'prototype' of undefined

Is anyone else getting this error?
I am just trying to create a very simple web worker but I can't get past this error.
When I do some debugging, I see I am getting an initialization error with this reason...
message { target: Worker, isTrusted: true, data: "{}", origin: "", lastEventId: "", ports: MessagePortList, eventPhase: 0, bubbles: false, cancelable: false, defaultPrevented: false, timeStamp:<PHONE_NUMBER>434703 }
does anyone know what this is and why its an error?
Thanks in advance!

+1, also getting error in Chrome:
Uncaught TypeError: Cannot read property 'prototype' of undefined
At line 2930 column 33 of angular.js (v1.5.7 from Github) line starting with 'var jqLiteContains ='
// IE9-11 has no method "contains" in SVG element and in Node.prototype. Bug #10259.
var jqLiteContains = window.Node.prototype.contains || function(arg) {
  // jshint bitwise: false
  return !!(this.compareDocumentPosition(arg) & 16);
  // jshint bitwise: true
};

This has been stable for 6 months and broke the moment I upgraded to angular v1.5.7
The error appear to be generated inside the WorkerService BEFORE making the $http request (for comments) in code below
var workerPromise = WorkerService.createAngularWorker(['input', 'output', '$http',
                    function(input, output, $http ) {
                        var objectKey = input.objectKey;
                        var XSRFToken = input.XSRFToken;
                        var url = input.url;
                        var getComments = $http({
                            method: "get",
                            url: url,
                            headers : { 'X-XSRF-TOKEN' : XSRFToken }
                        });
                        getComments.then(function(response) {
                            output.resolve(response.data);
                        }, function(error) {
                            output.reject(error);
                        });
                    }
                ]); // End WorkerService.createAngularWorker()

+1

+1

+1

I solved the problem by adding the Node property in the mocked window object defined in the workerTemplate string, inside the function createAngularWorkerTemplate.
var workerTemplate = [
          '',
          '//try {',
          'var window = self;',
          'self.Node = {prototype:[]};', //patch for angular >1.5.7
          'self.history = {};',
          'var document = {',
          '      readyState: \'complete\',',
          '      cookie: \'\',',
          '      querySelector: function () {},',
          '      createElement: function () {',
          '          return {',
          '              pathname: \'\',',
          '              setAttribute: function () {}',
          '          };',
          '      }',
          '};',
          'importScripts(\'<URL_TO_ANGULAR>\');',
          '<CUSTOM_DEP_INCLUDES>',
          'angular = window.angular;',
          'var workerApp = angular.module(\'WorkerApp\', [<DEP_MODULES>]);',
          'workerApp.run([\'$q\'<STRING_DEP_NAMES>, function ($q<DEP_NAMES>) {',
          '  self.addEventListener(\'message\', function(e) {',
          '    var input = e.data;',
          '    var output = $q.defer();',
          '    var promise = output.promise;',
          '    promise.then(function(success) {',
          '      self.postMessage({event:\'success\', data : success});',
          '    }, function(reason) {',
          '      self.postMessage({event:\'failure\', data : reason});',
          '    }, function(update) {',
          '      self.postMessage({event:\'update\', data : update});',
          '    });',
          '    <WORKER_FUNCTION>;',
          '  });',
          '  self.postMessage({event:\'initDone\'});',
          '}]);',
          'angular.bootstrap(null, [\'WorkerApp\']);',
          '//} catch(e) {self.postMessage(JSON.stringify(e));}'
        ];`

Looks like the minified version is still giving this issue.

As far as I can see, that issue has been solved in angular pull 13492.
In order to not change angular versions due to the chance any other bug could arise (we were some versions behind) I manually applied the fix that was done in pull 13492. So far, I haven't experienced this issue again. Hope this helps.


Create a README.md for the tutorial outlined in issue 6

Create a README.md for the tutorial outlined in issue #6
AC

[x] readme.md with screenshots & code snippets
[x] links to different terminology, etc as appropriate.

I did tick second option as well, as we agreed that that part should be separate story on devportal


Cannot find module 'drizzle-cuid2/postgres' or its corresponding type declarations

Current Behavior
The package currently does not provide any types, which forces the use of any for the field across the project, killing the point of using drizzle.
Expected Behavior
It should properly provide types so that drizzle can be used the way it is meant to be used
Steps to Reproduce the Problem
Just install it in a TS project
Environment

Version:  "^1.0.5",
Platform: Ubuntu 22
Node.js Version: v20.17.0

Additional Information
I really loved the idea of this package, but without providing types, it doesn't offer all of the value it can.
Thanks!

The same issue occurs when using any of the other exports. It's so annoying. Guess I'll just be copying and pasting the source into my own project.


gcc experimenting

I tried adding gcc optimization support for the b extension.  This is one day of work, so I only added the easy ones, didn't verify the results with execution, and haven't tried to handle every case.  The assembler is missing support for the rev and zext aliases but I can emit the pack and grevi instructions for those.  The assembler is missing support for the addwu, subwu, addu.w, subu.w, and slliu.w instructions, so those are disabled though I am able to generate them.
This patch doesn't affect dhrystone, but for coremark I see a 280 byte reduction in size, which is about 1.5%, with 99 pack instructions and 3 max instructions.  Then I realized I had the signed ee_u32 hack in my tree, so I tried undoing that.  Now I see a 384 byte reduction in size, which is about 2%, with 190 pack instructions, 3 max instructions, and 1 maxu instruction.  We can perhaps get better results with support for the missing addwu etc instructions.
gcc-b-support.patch.txt
tmp.c.txt

The assembler is missing support for the addwu, subwu, addu.w, subu.w, and slliu.w instructions, so those are disabled though I am able to generate them.

slliu.w (and addiwu) was already implemented, but addwu, subwu, addu.w, and subu.w were not. That was an oversight/bug. I've now added them in 0dc2312.
There's spike support for those instructions, but they are one of the few yet untested instructions. (That's why I didn't catch that some of them were missing in binutils. :)

The assembler is missing support for the rev and zext aliases but I can emit the pack and grevi instructions for those.

Yes, I haven't implemented any of the aliases yet. They, and proper support for the log2(XLEN)-1 immediate (add missing error handling for too large values), are on my todo list for binutils.

I've now merged your gcc patch into mine, and un-commented the (define_insn ..) for addwu, subwu, addu.w, and subu.w, and even slliu.w (even though that doesn't seem to work yet), and added your test cases to gcc-demo.c, in bcb2e91.

You should be careful to keep track of authorship,  or maybe only accept patches from people known to have copyright assignments.  Otherwise, we might have trouble submitting upstream, as the FSF requires copyright assignments from all authors that contributed to a patch.  If a change is small enough and trivial enough we don't need a copyright assignment for it, but it is better to be careful up front to avoid a mess later.

or maybe only accept patches from people known to have copyright assignments.

That's the plan. (And I will have to get one as well.)
Btw, this is funny:
0000000000000048 <ctz>:
  48:	6015151b          	ctzw	a0,a0
  4c:	0005051b          	sext.w	a0,a0
  50:	00008067          	ret

but popcount doesn't have the extra sext.w:
0000000000000054 <popcount>:
  54:	6025151b          	pcntw	a0,a0
  58:	00008067          	ret

Also, just because I see it, I'm sure you already are aware, this andi shouldn't be needed:
00000000000000ac <rot>:
  ac:	01f5f593          	andi	a1,a1,31
  b0:	60b5153b          	rolw	a0,a0,a1
  b4:	0005051b          	sext.w	a0,a0
  b8:	00008067          	ret

I haven't tried to optimize anything yet.
The extra sext.w after ctzw is the same one we get for addw and other *w instructions.  I have an idea for how to fix it, but haven't had time to finish it.
popcount returns a value from 0 to 64, so the compiler can prove that no sign-extension is necessary when converting from 32-bit to 64-bit and optimizes away the sext.w.
clz/ctz on the other hand return an undefined (machine dependent) result if the input is zero, and this result may require sign-extension when converting it from a 32-bit to a 64-bit value.  I think some machines return -1 for instance in this case, and thus the machine independent optimizer needs to do a sign extension to convert a 32-bit -1 to a 64-bit -1.  This sign-extension should not be necessary for RISC-V, because an in-register 32-bit -1 is represented the same as an in-register 64-bti -1, but we have to feed that info back into the machine independent optimizer somehow, which we aren't doing yet.

TL;DR: Even on x86 handling of clz/ctz is far from optimal.

clz/ctz on the other hand return an undefined (machine dependent) result if the input is zero

jfyi, the RISC-V B extension clz/ctz instructions are defined to return XLEN if the input is zero.
I find it interesting that gcc seems to treat __builtin_clz(0) as unspecified value. I would have expected the language "If x is 0, the result is undefined" (from gcc manual) to mean UB, not unspecified value, and always wrote code using __builting_clz accordingly. And for UB there would be no obligation for gcc to do anything reasonable in the x=0 case.
At least on x86 the following function
int foo(int x) { return __builtin_clz(x); }

is compiled to bsr (gcc 9.1.0 -O1):
foo(int):
        bsr     eax, edi
        xor     eax, 31
        ret

And the x86 ISA leaves the result of bsr undefined for a zero source operand. There isn't even a guarantee that it will always return the same value.
Also interesting, with same compiler and options:
int bar(int x) { return __builtin_ctz(x); }

bar(int):
        xor     eax, eax
        rep bsf eax, edi
        ret

Where rep bsf is actually tzcnt from BMI1, which is identical to bsf except that it returns the operand size in bits when called with a zero operand, instead of leaving this case undefined. Arguably the rep (which is just an encoding hack, nothing is repeated here) is not necessary given the definition of __builtin_ctz().
Further, int foobar(long x) { return x ? __builtin_ctzl(x) : 64; } compiles to
foobar(long):
        xor     edx, edx
        mov     eax, 64
        rep bsf rdx, rdi
        test    rdi, rdi
        cmovne  eax, edx
        ret

(that's with -O3, with -Os you'll get a jump instead of the cmove), even though just rep bsf would be sufficient afaict. Or at least it could use the fact that BSF/TZCNT sets ZF=1 when the operand is zero. (The above code would literally just work as-is with the test instruction removed.) So, I guess what I'm saying is even on x86 gcc still leaves a lot on the table when it comes to clz/ctz.
Last one:
int boom(long x) { return __builtin_ffsl(x); }

This one is now using the zero flag set by BSF when the operand is zero (presumably that's just a hard-coded sequence):
boom(long):
        bsf     rax, rdi
        mov     rdx, -1
        cmove   rax, rdx
        add     rax, 1
        ret

https://gcc.gnu.org/onlinedocs/gccint/Misc.htm
Result of Clz/ctz with zero could be defined by following two marco:
Macro: CLZ_DEFINED_VALUE_AT_ZERO(mode, value)
Macro: CTZ_DEFINED_VALUE_AT_ZERO(mode, value)

@kito-cheng I did add the following to gcc/config/riscv/riscv.h and it seems to do the right thing for __builtin_ctzl() but not for __builtin_ctz(). Am I using mode in the correct way?
/* Configure CLZ/CTZ behavior. */

#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
  ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)
#define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
  ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)

gcc-b-support.patch.txt

@jim-wilson It looks like the changes for zero_extendsidi2 and zero_extendhi<GPR:mode>2 break zero-extend for non-B targets. I see the following ICE when building libgcc:
make[4]: Entering directory '/home/clifford/Work/riscv-bitmanip/patches/gcc-build/riscv64-unknown-elf/rv32i/ilp32/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/home/clifford/Work/riscv-bitmanip/patches/gcc-build/./gcc/xgcc -B/home/clifford/Work/riscv-bitmanip/patches/gcc-build/./gcc/ -B/opt/riscv64b/riscv64-unknown-elf/bin/ -B/opt/riscv64b/riscv64-unknown-elf/lib/ -isystem /opt/riscv64b/riscv64-unknown-elf/include -isystem /opt/riscv64b/riscv64-unknown-elf/sys-include    -g -O2 -march=rv32i -mabi=ilp32 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -I. -I. -I../../../.././gcc -I../../../../../gcc-9.1.0/libgcc -I../../../../../gcc-9.1.0/libgcc/. -I../../../../../gcc-9.1.0/libgcc/../gcc -I../../../../../gcc-9.1.0/libgcc/../include  -DHAVE_CC_TLS  -o _mulvdi3.o -MT _mulvdi3.o -MD -MP -MF _mulvdi3.dep -DL_mulvdi3 -c ../../../../../gcc-9.1.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../../gcc-9.1.0/libgcc/libgcc2.c: In function ‘__mulvdi3’:
../../../../../gcc-9.1.0/libgcc/libgcc2.c:396:1: error: unrecognizable insn:
  396 | }
      | ^
(insn 53 52 54 6 (set (reg:DI 169)
        (zero_extend:DI (reg:SI 90 [ _30 ]))) "../../../../../gcc-9.1.0/libgcc/libgcc2.c":298:6 -1
     (nil))
during RTL pass: vregs
../../../../../gcc-9.1.0/libgcc/libgcc2.c:396:1: internal compiler error: in extract_insn, at recog.c:2310
0x5518ab _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
	../../gcc-9.1.0/gcc/rtl-error.c:108
0x5518ca _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
	../../gcc-9.1.0/gcc/rtl-error.c:116
0x9a4c17 extract_insn(rtx_insn*)
	../../gcc-9.1.0/gcc/recog.c:2310
0x7b83a3 instantiate_virtual_regs_in_insn
	../../gcc-9.1.0/gcc/function.c:1605
0x7b83a3 instantiate_virtual_regs
	../../gcc-9.1.0/gcc/function.c:1975
0x7b83a3 execute
	../../gcc-9.1.0/gcc/function.c:2024
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Makefile:498: recipe for target '_mulvdi3.o' failed

I've now commented out those changes in gcc.diff.

I'm travelling this weekend, but may have some time to try to fix this next week.

Part 2 of my gcc experimenting.  The 32-bit libgcc failure was due to a missing TARGET_64BIT check and once I looked I found two more.  I got slliuw working.  Primarily by adding support to use addiwu to load constants, which allows me to load the mask I need in one instruction, which then lets the gcc combine optimization pass construct the slliuw instruction from the remaining instructions.
I added sb* support, though it is a little incomplete, as the sb*iw support might be wrong.  I didn't look too closely at that; I ran out of time.  I also added support to use sbseti to load constants.
I noticed that there is no sbextiw which looks like a bug on first glance, but the fact that the result is always 0 or 1 means there is no meaningful sign-extension to do here, so probably sbextiw was left out deliberately.  I would suggest a note explaining that it is deliberately missing.  We do have both sbext and sbextw, and the only apparent difference between them is that sbext uses 6-bits for a shift and sbextw uses 5 bits for a shift.  Not clear if this is useful enough to have both instructions.
The shift-ones instructions are in the basic bit manipulation set, but this is an instruction I haven't seen before, and gcc doesn't have support for it.  Meanwhile, rotate is not in the basic bit manipulation and this is a common instruction that gcc does have support for it.  I would put rotate into the basic bit manip chapter, and pull shift-ones out, but that is a minor point.  Maybe you have some other reason for doing things this way.  Maybe rotate is harder to implement for instance.
As before, this is minimally tested and minimally optimized and could use some cleanup work.  It may not build on a 32-bit host, some expressions need to be rewritten to fix that.
I'm travelling next weekend, so the next update is probably 2 weeks away.  I will probably try to get the shift ones instructions working next time.  They can also be used to load constants.
gcc-b-support.patch-2.txt
bitmanip-test-2.c.txt

@jim-wilson Sorry for the late reply. It's been pretty busy here the last two weeks.. I've now merged your patch-2, and the fix @mablinov posted in #36.

so probably sbextiw was left out deliberately. I would suggest a note explaining that it is deliberately missing.

Yes, that's exactly why it's missing. I will add a note to the spec.

the only apparent difference between them is that sbext uses 6-bits for a shift and sbextw uses 5 bits for a shift. Not clear if this is useful enough to have both instructions.

Yes, that's the only difference. I've only left out *W instructions when one can completely emulate them using the non-W instructions. I think sbextw is probably the most extreme case of that.

Meanwhile, rotate is not in the basic bit manipulation and this is a common instruction that gcc does have support for it.

That's a misunderstanding. Zbb includes rol/ror/rori (second last line):

The shift-ones instructions [..] They can also be used to load constants.

Yes, creating constant masks (usually with rs1=zero) is the main application for shift-ones.

Closing this one to keep things tidy. Please create a new issue for the next patch.

We now have a gcc branch to maintain our patch set. I've added the two patches from this issue in the following commits:

https://github.com/riscv/riscv-gcc/commit/1a61a1fa993c7245d30ca018fb6e6c13b8ff7188
https://github.com/riscv/riscv-gcc/commit/d7a6f6e016fb11c50d3ace2723e6ecd55ff02c0f

@jim-wilson Please check if the commit message and commit meta data is okay.


PackageId:CPython39.Exe.x64;PackageAction:Install;ReturnCode:1603;

This issue has been moved from a ticket on Developer Community.

在此处描述你的问题
===DO NOT EDIT BELOW THIS LINE===
PackageId:CPython39.Exe.x64;PackageAction:Install;ReturnCode:1603;

Original Comments
Feedback Bot on 11/16/2022, 00:06 AM:
(private comment, text removed)

Original Solutions
(no solutions)

duplicate of https://github.com/microsoft/PTVS/issues/7238


Add privileged permissions for serviceaccount to deploy OLM

Don't like it, but we spend too much time on it.


Separate fetch/save api into plugin or external module

It would be great if in the second version of the library the model and collection got rid of the built-in backend API.
In my opinion, the backend API should be an external module, although it is possible to provide a base implementation.
Today, you constantly have to look for workarounds if you want to destroy a model that does not imply synchronization, but has the specified Id.
And in general, if we are talking about the model-view concept, in my opinion it would be better if the library will be not aware of the backend
Besides, this separation will simplify the process of getting rid of jQuery if such an idea arises.

Hey @taburetkin, thanks for sharing your thoughts!

It would be great if in the second version of the library the model and collection got rid of the built-in backend API.
In my opinion, the backend API should be an external module, although it is possible to provide a base implementation.

If you mean the CRUD methods of Backbone.Collection and Backbone.Model, then I think it makes a ton of sense to have those on board by default, as base implementations as you put it. I don't think there are many serious stateful web applications that never talk to a backend. These methods already abstract over the means of synchronization thanks to Backbone.sync and Backbone.ajax. However, I somewhat agree that Backbone.ajax need not default to jQuery.ajax and that this could be deferred to a plugin instead, especially now that fetch is built into most browsers.

Today, you constantly have to look for workarounds if you want to destroy a model that does not imply synchronization, but has the specified Id.

I don't really see your point here. What's the difference from collection.remove(id)? If there is actually a difference, why doesn't overriding Backbone.sync suffice?

And in general, if we are talking about the model-view concept, in my opinion it would be better if the library will be not aware of the backend

What do you mean by that? I don't think Backbone in its current form is aware of anyone's particular backend.

Besides, this separation will simplify the process of getting rid of jQuery if such an idea arises.

Honestly, as far as synchronization is concerned, this is very easy to achieve now already because you only need to override Backbone.ajax. I don't see why "getting rid of jQuery" would ever be a goal in itself, though. A lot of people seem to hate jQuery nowadays, for no apparent reason other than the library being old. As I see it, old is gold.

Hey @taburetkin, thanks for sharing your thoughts!

It would be great if in the second version of the library the model and collection got rid of the built-in backend API.
In my opinion, the backend API should be an external module, although it is possible to provide a base implementation.

If you mean the CRUD methods of Backbone.Collection and Backbone.Model, then I think it makes a ton of sense to have those on board by default, as base implementations as you put it. I don't think there are many serious stateful web applications that never talk to a backend. These methods already abstract over the means of synchronization thanks to Backbone.sync and Backbone.ajax. However, I somewhat agree that Backbone.ajax need not default to jQuery.ajax and that this could be deferred to a plugin instead, especially now that fetch is built into most browsers.

Yes, i mean crud.
In my opinion there should be something else for crud operation, some kind of store with base implementation
Model and Collection should not have any crud related properties and methods like url, save and fetch,  the destroy method should not perform DELETE.
all this logic should be implemented in entity store.
I do not mean that there should not be CRUD at all
i mean that this sync logic should be extracted to some EntityStore and there should be one built-in by default

Today, you constantly have to look for workarounds if you want to destroy a model that does not imply synchronization, but has the specified Id.

I don't really see your point here. What's the difference from collection.remove(id)? If there is actually a difference, why doesn't overriding Backbone.sync suffice?

Just try this
let menuItemModel = new Model({ id: 'menuItem1', label: 'bla-bla-bla' });
menuItemModel.destroy();

link to codepen: https://codepen.io/dimatabu/pen/MWOqVGY

And in general, if we are talking about the model-view concept, in my opinion it would be better if the library will be not aware of the backend

What do you mean by that? I don't think Backbone in its current form is aware of anyone's particular backend.

oh, thats because of my pure eng, i was telling not about particular backend but about crud operations. i think we can skip this.

Besides, this separation will simplify the process of getting rid of jQuery if such an idea arises.

Honestly, as far as synchronization is concerned, this is very easy to achieve now already because you only need to override Backbone.ajax. I don't see why "getting rid of jQuery" would ever be a goal in itself, though. A lot of people seem to hate jQuery nowadays, for no apparent reason other than the library being old. As I see it, old is gold.

actualy any thing is very easy to achieve. and the talk here not about jquery itself.
just imagine that you want to use backbone in application where you communicate with the backend not through http and there is no need in jquery in application. still possible today, but its just not very comfortable.
dom manipulation is subject of user choice (there is a good try in marionette about this)
backend data manipulation is subject of user choice too
perfect minimum application setup should looks like
<head>
  <script src="cdn://backbone" />
</head>

okay, i can accept next one as semi-perfect
<head>
  <script src="cdn://underscore" />
  <script src="cdn://backbone" />
</head>

And I don't insist, I just share my thoughts

You quote the source code of the destroy method, which is 20 sloc, and then highlight 3 of those lines and declare that those are "the main thing". I hope you can agree that this is a rather subjective way of choosing "the main thing" about a method.
Let me suggest a more objective way of identifying the purpose of the destroy method. The first sentence of the doc comment that you quoted, as well as the first three sentences of the documentation on the website, clearly convey that the method is about deleting the model from the underlying datastore:

Destroys the model on the server by delegating an HTTP DELETE request to Backbone.sync. Returns a jqXHR object, or false if the model isNew. Accepts success and error callbacks in the options hash, which will be passed (model, response, options).

If cleaning up is all you need to do, you can do model.stopListening().trigger('destroy', model). It's a oneliner. If you do this a lot and you want to remove the repetition, you can also add your own method to Backbone.Model.prototype or a subclass. You could call it remove.
Is this type of cleaning up really helpful, by the way?  In that case, I wouldn't be against adding a remove method to Backbone.Model.

You quote the source code of the destroy method, which is 20 sloc, and then highlight 3 of those lines and declare that those are "the main thing". I hope you can agree that this is a rather subjective way of choosing "the main thing" about a method. ;-)
Let me suggest a more objective way of identifying the purpose of the destroy method. The first sentence of the doc comment that you quoted, as well as the first three sentences of the documentation on the website, clearly convey that the method is about deleting the model from the underlying datastore:

Destroys the model on the server by delegating an HTTP DELETE request to Backbone.sync. Returns a jqXHR object, or false if the model isNew. Accepts success and error callbacks in the options hash, which will be passed (model, response, options).

If cleaning up is all you need to do, you can do model.stopListening().trigger('destroy', model). It's a oneliner. If you do this a lot and you want to remove the repetition, you can also add your own method to Backbone.Model.prototype or a subclass. You could call it remove.
Is this type of cleaning up really helpful, by the way?  In that case, I wouldn't be against adding a remove method to Backbone.Model.

I must agree that backbone view has remove method in a view and implementation of this method looks like some kind of dispose pattern design.
I am not agree with the remove name of this method - destroy will be much better.
but lets discuss the main thing of model's destroy.
Imagine some abstract method:
function someMethod() {
   let action = () => {
     doThis();
     doThat();
   }

   if (conditionA) {
      callAnotherMethod();
      action();
   } else {
      doAsyncJob().then(() => action());
   }

}

in this method action will be definitely executed, and all other things will be executed only by condition
i think that the main thing of the method is thing which will be definitely executed, others are optional
the local destroy is such definitely executed thing and sending request to the backend is optional.
I belive that model.destroy and view.remove are examples of dispose pattern implementation, even if it was not originally intended that way.

By that reasoning, the local destroy is still not "the main thing", because it will not definitely be executed. Consider the case where model.isNew() is false, options.wait is true and the backend request fails. In fact, the destroy method as a whole has no single part that will always be executed, except for the overarching decision making logic.
I can agree that Model#destroy includes cleanup behavior, even if it is not its sole purpose. I can also agree that there is currently no other Model method that provides cleanup behavior, so I understand how you may have arrived at using destroy for cleanup purposes. Still, I think that backend deletion is very clearly also a purpose of destroy and that most users expect this behavior.
Now, I can think of three ways we could take this:

Reduce Model#destroy to a method that does cleanup only, as you're suggesting, and move backend deletion to a new, separate facility. This would be a very disruptive change and in my opinion, "destroy" implies more than just cleaning up.
Keep Model#destroy as is, but add a new Model#remove which does only the cleanup. I think remove is a good name because it is consistent both with Collection#remove and View#remove, but the new method could potentially also get a different name.
Do nothing. This would be defensible in my opinion, if we can determine that the cleanup by itself is not strictly necessary.

I think that any decision will be a decision.
i am here only to point some things.
and i suppose i have a success in delivering my thoughts about that, so we can stop at the moment.
ps.
about model's local destroy: the case you described is only valid for a model which explicitly must be synchronized.
and ofcourse if backend request fails then destroy should not happens.
the main thing of destroy (not in backbone but in general) is that after success destroy any use of instance must throw.

I guess to some extent this is a question of what the responsibility of Backbone.Model should be:

Is it supposed to be merely a data structure?
Is it's responsibility to facilitate some reactivity to changes to local data?
Is it's responsibility to facilitate communication with a persistence layer?
Is it's responsibility to be kind of a two-way binding with a remote copy of it's data?

I would say 'local data' in this context essentially comes down to application state, while 'remote data' refers to some storage layer. Whether this is a remote server or localStorage or whatever.
It seems to me what @taburetkin might be aiming for is to remove the responsibility of communicating with a persistence layer from the model entirely?
If the model is meant to be a sort of two-way binding with a remote copy of it's data, then it makes sense for communication with the persistence layer (even if indirectly through some layer of abstraction like "feel free to implement your own sync method") to be an inherent responsibility of the model.
When it comes to event listeners and such, there is a conceptual difference between 'the value of this attribute of the model changed' and 'a copy of the data contained in this model has just been persisted to/deleted a storage layer'.
With regards to remove/destroy. I would say there is at least potentially a difference between things like cleaning up event listeners, or telling a persistence layer to store or delete some data. Splitting this off into two separate methods might not necessarily be a bad idea, but it really kind of depends on what the model's responsibilities are.

@Rayraz

Edit:
We could actually treat some of these responsibilities as optional, and if all persistence is passed through sync (is it currently?)

Yes, it is.

then @ogonkov's suggestion of turning sync into a no-op might be good enough to nuke any interactions with a persistence layer.

Yes, this is something that is currently already possible.

I found some time to re-familiarize myself a little more and indeed, what @ogonkov suggested seems to be all that's needed to remove the responsibility of talking to a persistence layer entirely.
I can see there might maybe be one detail to possibly clean up. The method name 'destroy' might imply it's a counterpart to the constructor method. You could argue tearing down the class instance and removing some data from some storage layer should be separate responsibilities. Currently, calling Model.destroy() means both delete this data and tear down this class instance.
Of course it make sense to tear down the class instance once it's data has been deleted, but maybe it sometimes makes sense t tear it down without deleting the data from your storage layer?
Currently the only cleanup that's happening in a standard Backbone model is to call Model.stopListening(). So tearing down the model would come down to simply calling myModelInstance.stopListening(). However, if you extend the standard Model you might want to add some additional cleanup?
If I'm not mistaken, currently you can only do so by extending destroy and adding your own cleanup before calling a the original Model.destroy method:
var MyFancyModel = Backbone.Model.extend({
    destroy: function() {

        /* ... some additional cleanup code ... */

        Backbone.Model.prototype.destroy.apply(this, arguments);
    }
})

But this doesn't allow you to wait until after the data has been deleted. If you need to wait until after the data has been deleted, you'd need to listen for the destroy event and then do your cleanup, but then your cleanup has become external to the model itself.
Perhaps something as simple as spinning off a teardown method would solve this? It would clearly separate the two responsibilities, it'd allow you to execute your additional cleanup behavior after data has been deleted yet before the destroy event is triggered and it'd allow you to do all your cleanup at once with one function call, without deleting any data:
teardown: function() {
    this.stopListening();
},
destroy: function(options) {
      options = options ? _.clone(options) : {};
      var model = this;
      var success = options.success;
      var wait = options.wait;

      var destroy = function() {
        model.teardown();
        model.trigger('destroy', model, model.collection, options);
      };

      options.success = function(resp) {
        if (wait) destroy();
        if (success) success.call(options.context, model, resp, options);
        if (!model.isNew()) model.trigger('sync', model, resp, options);
      };

      var xhr = false;
      if (this.isNew()) {
        _.defer(options.success);
      } else {
        wrapError(this, options);
        xhr = this.sync('delete', this, options);
      }
      if (!wait) destroy();
      return xhr;
},

The only thing I'm not really sure about is if this is something you'd actually ever need or if I'm just overthinking...

Perhaps something as simple as spinning off a teardown method would solve this?

That's basically what I've been proposing above as "option 2", except that I called it remove instead of teardown and that I think this method should also imply removal from all collections that the model might be a member of.

The only thing I'm not really sure about is if this is something you'd actually ever need

That's exactly what I'm unsure about, too.

Hmm... yeah looking at it from that perspective it's kinda similar to what View.remove does.
The option 2 style remove method doesn't really do anything that would prevent you from re-using the model again and neither does View.remove keep you from re-using the view. It would simply make Model clean up after itself the way View does. From this perspective the name remove is actually better than teardown.
Meanwhile, Model.destroy and View.remove are very different things. The default behavior of destroy is much more permanent..
I also notice View doesn't do anything to notify other application components that it's has been detached from the DOM and by design it doesn't make any assumptions about how it'll be attached to the DOM. Simplicity and flexibility are clearly the main considerations here.
 It doesn't introduce much if any complexity in terms of understanding the code, but it could be argued it anticipates the fact that different people might want to use Model in very different ways.
All in all, it's still probably mostly bike-shedding, but at the same time it does feel nice and clean.

sorry for being absent in this discussion
i just put it here: https://en.wikipedia.org/wiki/Dispose_pattern
i just want to say that current naming convention makes me ill.
.net: (one of my backend languages is .net) dispose pattern is implemented via dispose method.
marionette: (my primary fe framework) dispose pattern is implemented via destroy method.
backbone: a dispose pattern implemented via 'remove' for a view and 'destroy' for a model.
i feel that method name should be the same for every instance within the framework.
but backbone view has natural dispose method - remove, which exactly disposes the view and model has some kind of hidden dispose inside of destroy method.
but there is a remove method as part of collection api which is definitely not about disposing.
so if we call our dispose method remove then we will end with situations when model.remove() and collection.remove() will means different things and and if you have to implement dispose pattern for a collection, this method WILL have to be called differently. - That's why I'm against remove.
btw, destroy - seems to me more natural.
model.destroy(), collection.destroy(), view.destroy()

teardown: function() {
    this.stopListening();
},
destroy: function(options) {
      options = options ? _.clone(options) : {};
      var model = this;
      var success = options.success;
      var wait = options.wait;

      var destroy = function() {
        model.teardown();
        model.trigger('destroy', model, model.collection, options);
      };

      options.success = function(resp) {
        if (wait) destroy();
        if (success) success.call(options.context, model, resp, options);
        if (!model.isNew()) model.trigger('sync', model, resp, options);
      };

      var xhr = false;
      if (this.isNew()) {
        _.defer(options.success);
      } else {
        wrapError(this, options);
        xhr = this.sync('delete', this, options);
      }
      if (!wait) destroy();
      return xhr;
},

actually stopListening is not the only thing. look at local destroy
there is model.trigger('destroy', model, model.collection, options);
which effectively removes destroyed model from every collection.
let collectionA = new Collection();
let collectionB = new Collection();
let model = new Model();
collactionA.add(model);
collactionB.add(model);
model.destroy();

https://github.com/jashkenas/backbone/blob/0d455df4e15d814ed9c3f24be1ab4ea23c5c630d/backbone.js#L1213


How could the model be exported as a jit model?

I would like to use my custom trained model in torch jit. Is this possible with model?

@thhart latest commit allows jit scripting of both the model and model wrapped in a bench (train or predict). However, it requires that the head is changed to a form that breaks weight compatibility.
If you have existing weights you want to use, or want to use pretrained weights usage would look like
bench = create_model(....)
stashed_config = model.confg # grab config if needed for your training/val script before JIT
load_checkpoint(model, ...) # must load checkpoint w/ old model format here (or pretrained via create_model)
bench.model.toggle_head_bn_level_first()  # switch BN ModuleList order in Head to be torcscript compatible
bench = torch.jit.script(bench)

after you've trained such a model, you can make a config in the model_config that always has head_bn_level_first set to True to load the weights (if you happened to train the model jit scripted). If you just want to use for inference it's easy, train normally, load weights, toggle head mode, script, save scripted model


rain sensor - no values

I've got a working enviro weather for wind speed, direction, temp etc. apart from rain. At present I'm simply logging the payload over http but can see the data just fine:

Also, when the bucket tips it is waking the device and triggering an upload - I can see the activity LED and a log entry appear a moment later., however (as above) the payload that is sent always says ...  "rain": 0....
I can see in the code where that is set, but what I'm not clear is what to do about it. For example, should/could I add the 'wake reason' to the payload? Then I can use the reason code to increment a rain total concept. I think I would then need to add a scenario to the function 'def get_wake_reason():' in board.py.
To my mind, this seems easier than adding to the pico the concept of rain today, and worrying about timezones, the 09:00UTC met definition etc..
If I'm on the right path, happy to write, test and create a PR....

Hi,
Same observation for me with this card.
In fact, in the code, the rain data are not currently managed:
in the file enviro/boards/weather.py, the function get_sensor_readings() always returns the value 0 for the rain sensor:
  return {
    "temperature": round(bme280_data[0], 2),
    "humidity": round(bme280_data[2], 2),
    "pressure": round(bme280_data[1] / 100.0, 2),
    "light": round(ltr_data[BreakoutLTR559.LUX], 2),
    "wind_speed": wind_speed(),
    "rain": 0,                                                              # Always 0 return
    "wind_direction": wind_direction()
  }

On the other hand I have not seen how the detection of the rain gauge is managed.
The GPIO pin connected to the rain gauge is declared
rain_pin = Pin(10, Pin.IN, Pin.PULL_DOWN)
but never used in the code, it seems

I've just discovered the same thing, just had the first bit of rain for weeks and nothing being logged. Looked at the source and noticed it's hard coded to 0.

I've managed to get it recording rain, however to do it I had to effectively rewrite the core of the firmware, sacrificing going into deep sleep as it requires an irq on rain_pin to record a rain drop but the reboot on timeout in the original firmware then wipes out that data, keeping the recorded rain as 0
For me what I've got working is fine as this sensor will  be mains/usb powered however they should get it working in the main firmware.
One I know what I've got is actually working I'll clean it up and put that up on github.

I was also thinking about modifying the code to use IRQs, but haven't started yet.
@peter-mount,  I will be very interested in your code.

@vdomos this is working, although it should really have a mutex to prevent a race condition between set_rain() and get_rain()
Also this doesn't work when the pico is rebooted via the timer as that then resets the counter.
It's working for me as I'm not rebooting it between samples.
# Rain PIN
rain_pin = Pin(10, Pin.IN, Pin.PULL_DOWN)
rain_count = 0.0
rain_hit = 0

# Maplin bucket sample size in ml https://forums.raspberrypi.com/viewtopic.php?t=263262
# 0.011" according to http://www.philpot.me/weatherinsider.html
rain_sample = 0.2794

# set_rain runs under an IRQ when the rain gauge tips.
# It has a simple anti-bounce routine which will work fine unless it's heavy rain
def set_rain(t):
    global rain_count, rain_hit
    now = time.time()
    if rain_hit == 0 or (now - rain_hit) > 0.3:
        rain_count = rain_count + rain_sample
        rain_hit = now

# IRQ to call set_rain when a drop arrives
rain_pin.irq(lambda pin: set_rain(pin), trigger=Pin.IRQ_FALLING)

# Get rain count and reset
def get_rain():
    global rain_count, rain_hit
    val = rain_count
    rain_count = 0
    return val

then replace "rain": 0, with "rain:" get_rain(), in get_sensor_readings()
I've had this running all day whilst we had some rare rain falling and it's been working pretty well.

thanks @peter-mount , I will test this

I found some suggested code on the Raspberry Pi project website.  It uses the same rain gauge as the one supplied in the Enviro Weather kit.
https://projects.raspberrypi.org/en/projects/build-your-own-weather-station/8

I've done some testing and am reasonably sure that whilst the rain tip will wake the device, there is currently no way to tell upon waking as to why - button, rtc, rain or other.
@lowfatcode - do you think this bug is something that is fixable in time? Understanding the underlying firmware of the enviro board (i.e. the pimoroni-pico cpp code) is currently beyond me, though once the trigger reason is accessible I'm very happy to contribute to the Python code in this repo.
To be clear, not asking for timescales, just if it is probably fixable. If it isn't I'll pursue use of solar and a battery to keep the board always on.

rain tip will wake the device

Hi @mrgfisher, I think the GPIO pin connected to the rain tipper will not wake the device on it's own (using the current script) as the pico is asleep.  The code has to somehow disrupt the RTC alarm, which in turn will wake the pico - but then again I might be wrong as I'm lacking knowledge on this topic.
This is where my coding is stuck.  If I was able to figure out how to disrupt the alarm, I would then be able to get the remaining part of the process to work as intended (incl the wake reason).  Hopefully this will be picked up in an official update in the near future.

Apologies all, this oversight is fixed in https://github.com/pimoroni/enviro/commit/048a044493842135ec3304111c0f8a1da0ddd5f7
The rainfall sensor has the ability to wake up Enviro Weather so that the time of the event can be logged and the device can go back to sleep. These log entries are stored in rain.txt which is then used to calculate the rainfall over the past hour in millimetres when taking a scheduled reading.
The feature will be included in our next release (v0.0.6).

@mrgfisher thank you for raising an issue for this - please see previous comment, this will be working in v0.0.6 and should be suitable for your solar setup. :-)

Great news - many thanks @lowfatcode !


Smart sorting

I'd like to contribute to improving the sorting of torrents.
Currently you can choose between balanced/resolution/seeds/size in the sorting options.
However I've come up with another sorting system which is based on "points".
High points

Torrent Name starting with correct title name and a little lower if it only contains the name. Even lower if partially matches.

Medium points

Codec (x265, x264 etc)
Resolution (4k, 1080p, 720 etc)
Bitrate (If you can only download 500KB, you shouldn't try to download 20GB movies. I can get bitrate of episode/movie if i have Size of torrent and duration of it. If it's a full season or many season torrent i'll get the season numbers and check how many episodes each season has and i'll divide the torrent size by that episode number.
Sound Codec (Some prefer surround)

Low points

Seeds

I've already got a working version of this on another similiar addon which is now outddated because of Kodi 19. It has worked really well! It's balancing the torrent list based upon factors that are important. The list i've made with high, medium, low points are abit simplistic, but it's for you to get the idea. I've made a lot of scoring levels which keeps the torrent list balanced. No more anime from nyaa which are at top sometimes :)
How i've understood this ecosystem so far is that first it get's the torrents from burst and sorts them in burst. It sends the payload over to elementum daemon which sorts it again. Then for the last task, it sends the payload over to plugin.video.elementum which shows the results in a dialog for you to see.
I'm contemplating which addon to make improvements in. Burst is unnecessary, since it sorts after in the daemon. Elementum daemon is written in Go and might be difficult to make the sorting system efficent enough there. Should I make the sorting in plugin.video.elementum. Or do you @elgatito have a better idea. I'd like to discuss this in further lengths with you, but could only contact you here.
Elgatito, feel free to contact g4nd41f with protonmail.ch

I'm contemplating which addon to make improvements in. Burst is unnecessary, since it sorts after in the daemon. Elementum daemon is written in Go and might be difficult to make the sorting system efficent enough there. Should I make the sorting in plugin.video.elementum.

plugin.video.elementum is used only for interacting between Go and Kodi.
All functionality is done in Go and should stay there.

@g4nd41fs hi. do you have plans to implement this? if not - maybe close this issue. thanks.


Fix resource aliasing test flake

Observed in https://app.shippable.com/builds/55b1f044bf65f60b0014e532
Creating a pod just before an rc and expecting only 1 pod at the end is racy, because the rc manager might see the rc via watch before it sees the pod (in fact it probably will because the apiserver has to filter through N entries before sending it down a watch, and N is much smaller for rcs than pods). To do this safely we should just allow the rc to create the pod, and check resource labels instead of names at the end.

LGTM


fixing

Yarn v3 now available. update yarn version for ccd and citizen-ui repos
We need to do this for  Civil for civil-ccd-definition repos.
JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/CIV-5708
Change description
Yarn v3 now available. update yarn version for ccd and citizen-ui repos
We need to do this for  Civil for civil-ccd-definition repos.
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

Please change the PR title as required. @indu2019


301 Moved Permanently Error

The bot sents the Discord chat to Minecraft but not the chat from Minecraft to Discord.
If I try this:
tail -F /var/lib/pufferd/servers/8d5caf9a-ccc2-4568-ac7f-34a104008199/logs/latest.log | grep --line-buffered ": <" | while read x ; do echo -ne $x | curl -X POST -d @- http://<IP_ADDRESS>/minecraft/hook/ ; done
I get this Error:

<title>301 Moved Permanently</title>

301 Moved Permanently

nginx/1.14.0 (Ubuntu)

Now I have add https. And the


unstable issue in the training process

Describe the bug
I have used nerfacto, nerfacto-big, and instant-ngp three models for my dataset. I found that the training process was unstable.  It looks this way
. Is there any implementation issue? does nerfstudio implement the early stopping?

The models are typically trained for fewer iterations, ie nerfacto is only set to train for 30k iters. There are some instabilities that emerge when training for a long time. We have tried to look into them but have so far been unsucessful.

Thanks for your explanation. I have found the possible reason. It might be some issues with the resume process. I found when I resumed the training, the learning rate would go back to the default (0.01). It does not load the final learning rate in the last step of the previous train. There is the picture:

I used the code to resume training:
ns-train nerfacto --experiment-name $exp_name --timestamp $timestamp --data $data  --load-dir $resume_dir --output-dir $output_dir --max-num-iterations $iterations --vis $vis
Note: resume_dir=$output_dir/$exp_name/$exp_name/$timestamp/nerfstudio_models
How can I resume the lr from the latest checkpoint?

The models are typically trained for fewer iterations, ie nerfacto is only set to train for 30k iters. There are some instabilities that emerge when training for a long time. We have tried to look into them but have so far been unsucessful.


Change "General settings" to "Feedback" on Settings screen

Please change title of second "General settings" block (where rate app and report a problem is) to "Feedback" on Settings screen

Irrelevant since we remade whole settings screen


[ECard Transactions] Update Admin Pay Button Copy in ReportPreview/MoneyReportHeader

Design Doc Section
https://docs.google.com/document/d/1iELOXPOAcnuIPZJ3XbO1S8_3qHaM31Ptf8dR4LRZMyE/edit#bookmark=kix.gq501xywgfmv
Overview
Goal:
Update the Pay Button depending on admin view, policy type, and types of transactions on the report.
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~019cd4005e678faab2
Upwork Job ID:<PHONE_NUMBER>256550912
Last Price Increase: 2023-10-04

Not overdue

Not overdue 👍

@grgia going through the wave 8 project, and saw this issue. Is this a critical part of the implementation, or more of a clean up issue?

@joekaufmanexpensify not critical, but I can get this done by tomorrow

Cool cool, ty! Just wanted to confirm whether to put it in the update. But I'll leave it out for now if not critical.

Any action needed from me @grgia? Thanks!

@CortneyOfstad not currently, just for C+ payment tracking when we do work on this PR

Will work on this tomorrow (Fri)

Holding on the auth command

Not overdue

Not overdue

@grgia any action needed? Thanks!


@slidy/svelte - immutable: true

Template needed working in full immutable: true mode

Now, with solved #38 (reworked svelte template API) it works with immutable mode as no props are passed as objects.


add import --recursive option for git submodules

Only used for git since e.g. hg and svn seem to pull in subrepos / externals automatically.

@dejanpan Please let me know if this patch works for your use case.

@dirk-thomas can you tell me if I am testing this correctly:
git clone https://github.com/dirk-thomas/vcstool.git
cd vcstool
git checkout git_import_recursive
source setup.sh
cd /tmp
wget https://gitlab.apex.ai/snippets/27/raw -O mxnet.repos
vcs-import . < mxnet.repos

After that there should be code inside  mxnet/mshadow/ but it is not. which vcs-import points to my cloned version of vcstool.

My bad, forgot about --recursive arg.  It works as expected, thx a lot.

@dirk-thomas will you release a new python3-vcstool version after the merge?

will you release a new python3-vcstool version after the merge?

Yes, the packages for both Python versions are released at the same time.

:ship: in 0.1.33.


Add did:web resolver

Originally noticed while thinking through this ticket https://github.com/TBD54566975/web5-go/issues/70
We don't currently have a resolver implemented for did:web, should be relatively straight forward https://w3c-ccg.github.io/did-method-web/#read-resolve

implementations exist in js, dart, and kotlin for reference!

Discovered while looking into this ticket
https://github.com/TBD54566975/web5-go/issues/91

The basics for this have been implemented in the above referenced PR
Follow up works tracked

https://github.com/TBD54566975/web5-go/issues/94
https://github.com/TBD54566975/web5-go/issues/95
https://github.com/TBD54566975/web5-go/issues/96


how to add chartmuseum repository to monocular

Here is my section
      - name: chartmuseum-charts
        url: http://chartmuseum-chartmuseum.chartmuseum.svc.cluster.local:8080/api/charts
        source: https://github.com/<org>/repo/master/helm/charts

which path should I have for the url section to make it works. I notice this one https://kubernetes-charts-incubator.storage.googleapis.com has xml response instead of json

@huydinhle the URL should be the path that has the index.yaml file. E.g. https://kubernetes-charts-incubator.storage.googleapis.com/index.yaml

thank you for answering it works


Restore all windows when closing them all at once

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.60.2
OS Version: Ubuntu 21.04 / Gnome

Steps to Reproduce:

Open two windows (optional : open folder/files, do some modifications and save them), then click on "Quit 2 Windows" to quit VS Code :

Open VS Code again : only the last active window is reopened (no matter what value is set in window.restoreWindows)

However, if VS Code is closed by another mean (like pkill code), on the second launch all windows are correctly restored.
What is causing this behaviour, and how to fix it ?

As far as I recall, that action on Linux literally closes each window one by one, leaving no choice for us to distinguish from a normal close of the window.

Is there any workaround ?

I don't think this is true, other applications do not have any trouble with that. For instance Firefox, Chrome and many other correctly restore all windows even if quitting this way.

Let me investigate, but it will probably require changes from Electron.

Looked into it and compared to Windows and macOS: this actually works fine on macOS because the command you trigger from the menu is "Quit" which is the same when using "File > Quit".
Here is what happens on Linux and Windows:

the command is not triggering the quit flow as "File > Exit" would do
instead, each window is being closed one by one
we go ahead and discard any UI state assuming the user discards a window
upon restart we only restore the most recent window

In order to change this we would somehow need to know that this is triggered:

@deepak1556 @rzhao271 maybe you are aware of an Electron event that is triggered when using any of the 2 commands on Windows and Linux.

Perhaps what we need is an option to make it so that when closing individual windows, they close immediately without prompting to save, and retain their state. That way, whether by using File > Exit or by closing windows one at a time, state will be restored. At least this way there won't be work lost due to unexpected behavior.
Closing windows one by one may lead to only one window being open the next time, but at least we would be able to open a folder, and all the state would be restored.

@bpasero would close event on the window help in this case ?

We listen on close and it is the starting point for shutting down a single window (as opposed to all windows where a quit event is fired):
https://github.com/microsoft/vscode/blob/b92894493e6f971a3c71912d823e699d3a05d643/src/vs/platform/lifecycle/electron-main/lifecycleMainService.ts#L395

Ah I see the issue, we need a new event or existing window-all-closed event to be emitted for the context menu quit action ? What event do we use on Windows and Linux to determine quit action from File > Exit ?

We just trigger our quit function manually then:
https://github.com/microsoft/vscode/blob/b92894493e6f971a3c71912d823e699d3a05d643/src/vs/platform/lifecycle/electron-main/lifecycleMainService.ts#L546
I think the issue here is that the action in Linux closes the windows one by one. If we had a new event to override this behaviour and call our quit method it would probably work for us.

So, how does VSCode know to restore all windows when it was killed from task manager or when computer restarted? Why couldn't the same method be applied to "Quit all" command?


Instrument WAL corruptions

This is one of the improvements described in #81. Not totally sure if this is the correct place where to add the metric though.

Thanks! This is the right place!
Basically, we stop after the first detected corruption so this value can only ever be 0 or 1 in the general case. We could just make it a true/false gauge. But given tsdb is a library, people may use it differently and a counter could actually be the better choice in some cases.
👍


Skill-AxeFaith

If the user is wielding an axe, it does not lose durability. In addition, hit rate is boosted by Luck * 1.5.

Since Skill info is plan to update, so this PR will be merged and then fixed

The effect of this skill has been completely edited compared to what it was originally. I'm not sure why?

Looks like that's more balanced? Berserker-like characters don't have a lot of luck, but are better suited for stacking power


option no-capabilities has no effect on userCapabilities

When cleaning up topics from older versions of API, I came across the new versions are showing a lot of userCapabilities despite I start weconnect-mqtt with --no-capabilities option.
E.g. this path gets successfully filtered by the option:
tswcc:tswc/vehicles/WVWirgendeineVIN!/capabilities/cubicNetwork/userDisablingAllowed:.* userDisablingAllowed
This path is not filtered out:
tswcc:tswc/vehicles/WVWirgendeineVIN!/userCapabilities/capabilitiesStatus/capabilities/access/id:.* id
...and there are a lot of them.
Is it by intention or somehow required for the tool to not filter the userCapabilities?
If no, might I request a new feature to filter those, too?    Thanks.

Ah yes, that bug was introduced with the latest version that fetches the data slightly different. Will be fixed in the next version.

This should be fixed in 0.23.0 can you check and report back?

Similar using 0.23.1 version docker image:
docker-compose up
Recreating weconnect-mqtt_weconnect-mqtt_1 ... done
Attaching to weconnect-mqtt_weconnect-mqtt_1
weconnect-mqtt_1  | Traceback (most recent call last):
weconnect-mqtt_1  |   File "/usr/local/lib/python3.9/site-packages/weconnect_mqtt/weconnect_mqtt_base.py", line 217, in main
weconnect-mqtt_1  |     mqttCLient.connectWeConnect(username=username, password=password, maxAgePictures=args.pictureCache)
weconnect-mqtt_1  |   File "/usr/local/lib/python3.9/site-packages/weconnect_mqtt/weconnect_mqtt_base.py", line 287, in connectWeConnect
weconnect-mqtt_1  |     self.weConnect = weconnect.WeConnect(username=username, password=password, updateAfterLogin=False, updateCapabilities=self.updateCapabilities,
weconnect-mqtt_1  |   File "/usr/local/lib/python3.9/site-packages/weconnect/weconnect.py", line 210, in init
weconnect-mqtt_1  |     if self.__token['expires'] is None or cast(datetime, self.__token['expires']) <=
weconnect-mqtt_1  | TypeError: can't compare offset-naive and offset-aware datetimes
weconnect-mqtt_1  |
weconnect-mqtt_1  | During handling of the above exception, another exception occurred:
weconnect-mqtt_1  |
weconnect-mqtt_1  | Traceback (most recent call last):
weconnect-mqtt_1  |   File "/usr/local/bin/weconnect-mqtt", line 8, in
weconnect-mqtt_1  |     sys.exit(main())
weconnect-mqtt_1  |   File "/usr/local/lib/python3.9/site-packages/weconnect_mqtt/weconnect_mqtt_base.py", line 254, in main
weconnect-mqtt_1  |     mqttCLient.disconnect()
weconnect-mqtt_1  |   File "/usr/local/lib/python3.9/site-packages/weconnect_mqtt/weconnect_mqtt_base.py", line 282, in disconnect
weconnect-mqtt_1  |     disconectPublish.wait_for_publish()
weconnect-mqtt_1  |   File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 362, in wait_for_publish
weconnect-mqtt_1  |     raise RuntimeError('Message publish failed: %s' % (error_string(self.rc)))
weconnect-mqtt_1  | RuntimeError: Message publish failed: The client is not currently connected.

yes, looks like I made a mess :( will need some time to fix that, sorry

v0.23.2 docker works fine, the userCapabilities are now gone with --no-capabilities.
Appreciate your quick fix, thank you. 👍


Natural Earth SQL query fix + max zoom level increase

Made edits to tegola_st_asmvt.toml to correct the SQL queries for the Natural Earth data. Those queries still assumed the NE data resided in a separate database. Also increased some max zoom levels to be consistent with tegola.toml.

@diehl this LGTM! Can you please squash into a single commit and then I will merge it in? Thanks again!

@ARolek Ok I think this is good to go!

Looks great!


Costs Projection

Basically calculating the costs-output table from the costs table. Given many different resources (Wind, Gas, Coal, PV-{Residential, Utility, Mixed-Use}), their prices, and a projection method (YoY, Linear, etc), calculate the costs for all relevant years (parameterized - not just 2050).

Folded into #1


Plutus core/type env

Fixes a lot of bugs.

This breaks @Cubesoup's negate.plc example. I'm not sure where the bug is so I will come back to this in the morning.

I don't think this meets our contributing guidelines. Please just write more about what you're doing and why, it really makes your colleagues' lives easier!

Maybe don't push until it's working and you want us to review it? Otherwise I keep getting notifications and I'm not sure whether I should be paying attention.

I've put two test cases back and tested them with the new normalization help: https://github.com/input-output-hk/plutus/pull/141
For the other two, I'm unclear that they work even with non-normalized annotations.


Update all pipelines with simple multi-stage variables, plus separate CI and CD pipelines; update readme.md

Replaced this with more current version


[SOLVED] uncaught exception / folder not accessible in linux

Hi,
in my logs I got a lot of this
2014-12-10 02:59:48,592 DEBUG Got 1 messages from SQS
2014-12-10 02:59:48,593 DEBUG process_message '["213ab7c6-9055-453e-9170-afcfc34a74e8", "upload", "/clienti/opportunity/IN/nominativi.xls"]'
2014-12-10 02:59:48,593 ERROR Uncaught Exception in Thread
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/yas3fs/init.py", line 2392, in run
super(TracebackLoggingThread, self).run()
File "/usr/lib64/python2.6/threading.py", line 484, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/lib/python2.6/site-packages/yas3fs/init.py", line 932, in listen_for_messages_over_sqs
self.process_message(message)
File "/usr/lib/python2.6/site-packages/yas3fs/init.py", line 972, in process_message
self.invalidate_cache(c[2], c[3])
IndexError: list index out of range
my scenario is the following
3 ec2 instances sharing a bucket and using SQS to process messages, on two of them during the night two folders which are heavily accessed by the third instance become inaccessible
if you try to ls them you got only questions mark (see https://dl.dropboxusercontent.com/u/36103215/yas3fs_error.png)
After  I send a reset messages thru SNS everything is OK... maybe the two instances are overwhelmed by the changes made by the third?
TIA for any idea
ps I have the whole log here http://www2.gianlucanigro.eu/yas3fs.log.gz

Actually it was a timing problem... the file got unlinked quite fast and the other nodes received messages from the SNS topic in the wrong order, first the unlink and after the upload
Just adding a pause of a few seconds between the creation and the deletion of file solved the problem


Despawn buttons missing from Vehicle and Cim info panels

In v11.1.1 the (x) despawn buttons are no longer appearing on the info panels of vehicles and cims.

Interesting

Seems to be side-effect of #656
Looking at the buttons on the TM:PE toolbar (eg. LaneArrowsButton.cs), they include definitions for .skin and some stuff about atlasKeys. That's missing from the despawn buttons on the info panels.
The info panel classes are:

https://github.com/CitiesSkylinesMods/TMPE/blob/master/TLM/TLM/UI/RemoveCitizenInstanceButtonExtender.cs
https://github.com/CitiesSkylinesMods/TMPE/blob/master/TLM/TLM/UI/RemoveVehicleButtonExtender.cs

I don't yet know enough about how the new UI system handles textures or button sizes. Maybe @kvakvs or @kianzarrin could take a look?

OK, I figured it out and generated new textures. I will create PR and we will see.

This will be fixed in 11.1.1-hotfix1


Fixes wrong generator reference

Hey there, seems like the last example in the noImplicitAny Errors Apply to Loose yield Expressions section of 4.2 release notes actually meant to refer to the g4 generator function, if I understood this snippet correctly.
I'll also use this tiny PR as an opportunity to express my gratitude to the TypeScript team. You rock!

👍🏻 yep, that fix is right -  thanks!


ci: add job execution logic

The popper check command takes as input a URL to a Jenkins instance, a username, a project name and optionally an experiment name. The logic that will be RESTfully implemented is to invoke a Jenkins job execution (a build) on the given experiment(s).

We are missing the CLI implementation of this


Removed code duplication in duplicate_and_reown().

Removed code duplication in duplicate_and_reown().
Fixes #11182

Sorry for the long delay reviewing this, it's not an easy change to proofread with all those similar but not 100% identical code chunks moving around. Looks like a pretty sane refactoring to me – I raised a few questions on points where I'm not sure if we're actually change the logic, but doing so we might as well be fixing unknown bugs than adding new ones.
Needs a quick look over from @reduz too before we can consider it safe to Test In Production™.

Moving to 3.2 milestone as we're about to enter the beta stage and release freeze for Godot 3.1. Only bug fixes against issues of the 3.1 milestone (or enhancements to core features of the 3.1 roadmap) will be considered until 3.1-stable is released.
Note: If it's merged after 3.1-stable is released, this change might be considered for cherry-picking into a later 3.1.x release.

Sorry for bumping to the next milestone again :/ It's pretty sensitive code and while I fully approve of refactoring this code duplication, I didn't find time to test it thoroughly to ensure that everything would work as intended. Let's try to better prioritize this for 4.0, and get it merged early on.

@DualMatrix Would you be able to address the above comments?

@Piet-G Is this still desired? If so, it needs to be rebased on the latest master branch.
If not, abandoned pull requests will be closed in the future as announced here.

This PR has not received any new commits for over a year and is abandoned, closing.


adds error message to +ticket

This is another frequent question on urbit-meta -- the current error message ("blocking not care: ~.a") is both wrong and unhelpful.

Request analogous patch for 0.5 if you have time


bug : notice type dropdown does not apply filter on the map

Bug Definition
When you choose the 3rd notice type on the left 3 filters on the map it does not apply any filter on the map.

** discord username: @meturhan#9926 **
## Bug environment
rc.afetharita.com
afetharita.com
Describe how you are producing the bug step by step

Go to 'afetharita.com'
Click 'notice dropdown filter'
Map is not updated
Bug appears

Expected Behaviour
The map should be updated depending on the filters.
Screen shots

Desktop Information

Operating System: macOS
Browser safari, chrome

The issues should opened in English i have translated your issue to English.

Have the same result

Currently it does not filter the results when "Verified" channel is selected. We are in the process of changing whole filter structure, it can be tested after that


Support Custom Response status code and headers on block action

The terraform resource supports it already, please update the module to support it as well.
https://github.com/hashicorp/terraform-provider-aws/issues/18754

Hello @aairey ! Just to make sure we understand, you want an input variable that will pass-through to the custom_response_body block described here. Is that right?

Correct!

Ok, got it. That seems like something we'd like to support. I'll add it to our roadmap for engineers not on client projects to take on; in the mean time, I'd be happy to review a PR :)

I'm not seeing support in this module for a custom_response field. I think that may have to be added as well.

@aairey We recognize the value of this, but it's not something we need at the moment. If you can send us a PR we'll be happy to take a look :)

hi @rpdelaney , would you be interested in accepting my PR. If this is something you can see being accepted, I am happy to refine it and complete this piece by adding support to JSON and HTTP response bodies , as well as adding support for multiple response bodies


Why Bittrex Not Implement GetOrder ??

I've found that a number of trading platform only implement part of the method？

Yes, that's true indeed. Not everything is 100% complete.

@nntaoli sometimes the exchanges just don't support the API methods exposed in this project.  Other times people just haven't implemented it.

Will it be okay for you if I fork XChange, implement getOrder method, and create a pull request?

of course!


removing psi, pagespeed, and doc references

Addresses #893

Coverage remained the same at 98.942% when pulling 6a94089d1d1917f28c4504adcb1b5644a563d663 on fisch0920:feature-remove-pagespeed into 7bae788cf344da09a2b67545ffc788216513a653 on mxstbr:dev.

@fisch0920 please describe why this change is needed? What problems does it solve?
Also see: CONTRIBUTING.md

Hey, would you mind rebasing this to remove merge conflicts? Then we can land this!

Closing since no response from the author. Feel free to reopen.

@fisch0920 Thanks for the PR! much appreciated! 🎉
This has been fixed and merged in #1352.

Mobile version doesn't show you this. I apologize! @fisch0920 Thanks for all the great work :)


fix: theme mixin RELEASE

Related Issues
Fixes <link_to_github_issue>
Related PRs

branch
PR

service a PR
Link to PR

service b PR
Link to PR

Description
A few sentences describing the overall goals of the pull request's commits.
Must

[ ] Tests
[ ] Documentation (if applicable)

@nirgur build fails, and I don't understand the problem and fix.

@nirgur build fails, and I don't understand the problem and fix.

The problem is that the dropdown in the modal stays open,
the submit button cannot be clicked, and it fails the test


Investigate test failures with "An operation is not legal in the current state."

Starting with https://github.com/aspnet/AspNetCore/pull/14425, we've been seeing lots of test failures of the following type:

System.IO.FileLoadException : Could not load file or assembly 'Microsoft.Net.Http.Headers, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=adb9793829ddae60'. An operation is not legal in the current state. (0x80131509)

We think this is related to the large number of Explicit references that we've added to the tests. We should investigate these failures as they may represent an issue with the runtime.
CC @aspnet/build @mmitche

Would like to first determine whether this is about flakiness in our eng\targets\ResolveReferences.targets versus in the .NET SDK. To that end, the initial task here might be to create a project with lots and lots of explicit <ProjectReference>s and <PackageReference>s but none of the AspNetCore <Reference> infrastructure, then build it over and over.

@wtgodbe this should move to a proper milestone. I think this milestone is already locked down, so we should close it.

We think this will be fixed by https://github.com/aspnet/AspNetCore/pull/17311 - if so I'll close when that's merged

Close once merge into 'release/3.1' is done

We stopped seeing these after https://github.com/aspnet/AspNetCore/pull/17311, closing


FIX : Update required dependency

I have added two dependancies:
*django
*django-core

This is due to the fact that after installing wagtail only and trying to start the project with wagtail start mysite you will get the following error:

Traceback (most recent call last):
File "/home/vagrant/wagdev/ve/bin/wagtail", line 7, in <module>
from wagtail.bin.wagtail import main
File "/home/vagrant/wagdev/ve/local/lib/python2.7/site-packages/wagtail/bin/wagtail.py", line 7, in <module>
from django.core.management import ManagementUtility
ImportError: No module named django.core.management

django-core on its own does not solve this and thus why django has been included here.
It may be better to have this in a dependency file but I though this may be a good first step.
Thanks for contributing to Wagtail! 🎉
Before submitting, please review the contributor guidelines http://docs.wagtail.io/en/latest/contributing/index.html and check the following:

Do the tests still pass? (http://docs.wagtail.io/en/latest/contributing/developing.html#testing)
Does the code comply with the style guide? (Run make lint from the Wagtail root)
For Python changes: Have you added tests to cover the new/fixed behaviour?
For new features: Has the documentation been updated accordingly?

Hi @Onuonga - thanks for the contribution!
Django is listed as a dependency of Wagtail, so it should get installed automatically when you run pip install wagtail - if that's not happening, something is going wrong with your installation of pip. (Also, the django-core package is a third-party add-on for Django which is not related to the django.core module, and isn't required for Wagtail.)

Hey ,
Thank you for the speedy review.
I was on the latest pip version.
It does not come as a dependency.
Also , note that a step or two after pip install wagtail you ask users to:
pip install -r requirements.txt
Looking at that file it has :
Django>=1.8,<1.9
django-modelcluster>=3.0,<4.0
django-taggit>=0.20,<1.0
django-treebeard==3.0
six>=1.7.0

which means it is not listed.
It may be something very specific to my setup but seeing as there are all these breadcrumbs I do not think it is.
You will not get to that step because the mystic setup stage will fail.
I can send screen shots to walk through the steps as I did if you would like to reproduce it on your end.
Again, thank you for your time.

It seems you're looking at the wrong requirements.txt - the one at https://github.com/wagtail/wagtail/blob/stable/1.12.x/docs/requirements.txt is only used for building the documentation. The one used on newly-created projects is https://github.com/wagtail/wagtail/blob/stable/1.12.x/wagtail/project_template/requirements.txt.
I'd be happy to look at the screenshots to see where it's going wrong. Please can you also show the output of pip freeze after running pip install wagtail?


Adding a comment to a node key not working properly

I am unable to do the following
# some comment
entity-activation-range {
   enabled=true
}

If I attempt to generate that, I end up with
entity-activation-range=null

However, setting comments to entries within a node is fine. For example, this works fine
entity-activation-range {
   # some comment
   enabled=true
}

What code are you using to generate this? I can't repro in my tests.

Fixed in a5dd815


Update README.md for vortex shedding example

Modulus Pull Request
Description
Adding warnings for tensorflow installation, as the latest tensorflow installation updates the numpy version inside the container causing a few other dependencies to fail. Flagged during internal QA here.
Checklist

[x] I am familiar with the Contributing Guidelines.
[x] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.
[x] The CHANGELOG.md is up to date with these changes.
[x] An issue is linked to this pull request.

Dependencies

/blossom-ci


Ellipses in Euler diagrams

Previously posted issue in "upsetjs/upsetjs_r"

It would be great if the Euler diagram functions supported ellipses (e.g.: eulerr package) as they allow for less error in the the set area representation (link includes explanation & example(s)).
e.g. Euler plot constructed with ellipses (pasted from link):

wontfix no time


Presto admin commands(set role, grant perms) not supported on Superset

Environment

superset version: 0.37.2 I upgraded to 1.0.0 and still saw this issue.
python version: 3.6
node.js version: 12

Is your feature request related to a problem? Please describe.
Superset does not support Presto's administrative commands such as SET ROLE, GRANT PERMS ON ROLE, CREATE ROLE, etc. These commands work on Presto CLI. Are there plans to support this feature in future releases?
Describe the solution you'd like
Running administrative commands should result in altering a user's data permissions for a user's session on Superset. This should be handled through SQLAlchemy and PyHive.
Describe alternatives you've considered
Potentially using Presto CLI to run administrative commands and grant admins another role for querying purposes since admin role cannot be assumed on Superset.

Please reopen in case you are still seeing the issue - as a bug, or if this is a question please use the "Discussions" section.