Resuming a GroupChat

Why are these changes needed?
It's not possible to currently resume a group chat. This PR includes the ability to resume a group chat using a list of messages.
The group chat can be resumed as follows:

Agents, GroupChat, and GroupChatManager are created in line with the original group chat
A set of messages is available (mandatory)
run resume_chat on the manager object, passing in the set of messages as well as any other parameters (that will then be passed through to ConversableAgent's initiate_chat.

The resume function does the following:

If messages is passed in as a JSON string, converts to a List[Dict] messages object
Sends provided messages around to each agent
Remove any provided termination string from the last message (optional)
Checks if the last message in the provided messages will invoke termination, warning the user if so
Writes out a message noting the resumption, how many messages have been provided, and which was the last agent
Calls ConversableAgent's initiate_chat on the last speaker to kick-off the resuming conversation.
Note that the GroupChat's max_round property is still utilised and does not include the original messages (e.g. if max_round is 3 it will resume for 3 more rounds)

The changes include:

Updated autogen/agentchat/groupchat.py
Updated test/agentchat/test_groupchat.py
New documentation under topics/groupchat - User Guide > GroupChat > Resuming GroupChat

Why does it use ConversableAgent's initiate_chat instead of the manager's run_chat?
initiate_chat will call the manager's run_chat as part of the manager's attached reply functions. Additionally, initiate_chat provides the ability to set silent and supports summarisation.
Serialising state
The only state required is the messages. This in straightforward to serialise and persist. New functions on GroupChatManager, messages_to_string and messages_from_string will assist with the serialisation and deserialisation, respectively.
Validating the group chat
As we only use messages as input, it can provide basic validation that the name in each message aligns with the group chat's agents. This doesn't guarantee that the original group chat setup is the same as the one used for resuming.
Similarly, the developer will need to create the group chat objects themselves, rather than having it restored from state.
Future work can be done to increase the state to include all the group chat objects.
Testing in notebooks
I've run the resume functionality using the groupchat notebooks. I've saved these here.
Automated testing the group chat
I have not included testing the group chat resume in full in the test cases. I'd like to test this but I'm not sure how to test it effectively using LLMs/OpenAI - any help here is appreciated.
Notes:

As group chats vary considerably, it would be beneficial for others to test this in their own group chats. My testing has included the documentation notebooks and my debating scenario. This includes text-based chats including python code execution. I have not tested in non-text scenarios.

Related issue number
This PR has been created from the need identified in issue #2359 and is associated with the discussion #2301.
Aligned with Roadmap #2358.
Checks

[X] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[X] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[X] I've made sure all auto checks have passed.

Codecov Report
Attention: Patch coverage is 9.19540% with 79 lines in your changes are missing coverage. Please review.

Project coverage is 16.11%. Comparing base (372ac1e) to head (4e1eae4).
Report is 5 commits behind head on main.

Files
Patch %
Lines

autogen/agentchat/groupchat.py
9.19%
79 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #2627       +/-   ##
===========================================
- Coverage   33.11%   16.11%   -17.00%
===========================================
  Files          86       86
  Lines        9108     9196       +88
  Branches     1938     2118      +180
===========================================
- Hits         3016     1482     -1534
- Misses       5837     7637     +1800
+ Partials      255       77      -178

Flag
Coverage Δ

unittests
16.11% <9.19%> (-17.00%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

resume_chat is interesting though it is adding a new API method that is in parallel with initiate_chat. We can decouple "resume" from "chat", so we offer more flexibility. For example:
messages = load_history() # some user-defined code to load historical messages

# Resume to a state of group chat specified by the message history and other
# arguments similar to the `resume_chat` you have, except the summary method and args.
group_chat_manager.resume(messages=messages, ...)

# New the group chat is in a pre-configured state, start a new conversation with it
result = admin.initiate_chat(group_chat_manager, message="a new message to the group chat", summary_method="reflection_with_llm")

Generally, we can think of the resume method as a pre-configuration step for group chat -- it can be used to reload a previous chat, but user can also provide custom message history for different purposes (e.g., summarized chunks of messages, contextual information to be shared with all participants, etc.).

Thanks @ekzhu, okay, I'll try that setup and see if it still runs okay through initiate_chat.

For testing, I recommend not using LLM APIs but rather using agents with default_auto_reply setting, or a registered reply function that returns some random strings if content needs to be different across replies. This way the tests can run much faster, and the functionalities are tested rather than LLM response.

Okay, I've refactored to remove incorporation of initiate_chat. So the resume function is now a preparation step and it will return the last agent and last message so the user can use these to initiate the chat.
So resuming now looks like:
# Prepare the group chat for resuming
last_agent, last_message = manager.resume(messages=previous_state)

# Resume the chat using the last agent and message
result = last_agent.initiate_chat(recipient=manager, message=last_message, clear_history=False)

I've updated the documentation notebook and test cases.
I didn't add tests around the LLM because without the initiate_chat functionality, the LLM isn't called.


Add LinuxContainerExecutor to Wasmtime and WasmEdge shims

This PR adds a LinuxContainerExecutor to both the Wasmtime and Wasmedge shims. It enables the shims to be able to execute containers side by side with wasms.
Some notable changes

It adds a new libcontainer_instance module to containerd-shim-wasm which provides a linux container executor implementation that is shared by both wasmtime and wasmedge shims.
It adds this executor to both the shims.
It adds nginx image to integration tests.

It enables the wasmtime shim to be able to execute linux container if the wasm binary was not found on the rootfs.

We may need to revisit this since #147 would mean the wasm binary would definitely not be in the rootfs

It enables the wasmtime shim to be able to execute linux container if the wasm binary was not found on the rootfs.

We may need to revisit this since #147 would mean the wasm binary would definitely not be in the rootfs

Yeah we can revisit this once #147 is merged.

Could I please have some review comments on this PR? 🙏🙏

Sorry for getting back to your comments late. I am going to resolve them either tonight or Monday morning. Thanks for your reviews!

I tried to run container and wasm container in a pod, but the hello-world container crashed. I checked containerd log messages and I got
Aug 01 00:12:55 containerd-wasm-control-plane containerd[108]: time="2023-08-01T00:12:55.171882679Z" level=error msg="Failed to pipe stdout of container \"b0060fd6583b82000e6062e62f13a38a2d47d910fde1e338bf4f84d17c5107a0\"" error="read /proc/self/fd/146: file already closed"

It looks like there are some issues with how youki's DefaultExecutor pipe std I/O to containerd?

Even though I got the above error and the pod was not in READY state in k8s, I could still see pod logs
➜  runwasi git:(issue64) ✗ k logs wasi-demo-7cb6778b8f-gpd6p

Hello from Docker!
This message shows that your installation appears to be working correctly.
...

I've updated this PR to first use Default Executor and check the the executable if it's a linux binary. Then it falls to the wasm executor.

Okay, to fully verify that a path is executable in Linux, I need to verify a few things:

Check if the path containers "/", if is, then regard it as a full path. Otherwise, iterate through $PATH and prefix it to path.
Check if the path exists
Check if the path executable permission is set to 1
Check if the path contains shebang (#!), if it is, then it's a script.
Check if the path contains ELF magic number, if it is, then it's a Linux ELF file.
If both no, then path is not an executable.

Wasm binary also has magic number (00 61 73 6D), but the text format of the Wasm modules don't. For this PR, I will leave the verification logic for Wasm to be file extensions like .wasm and .wat.

🥳 integration tests passed!!

Looking through youki a bit, I think can_handle is not part of the executor interface and instead it is expected that we call can_handle from within exec() and return an appropriate error if it can't be used.

@cpuguy83, yes that was refactored lately. There is https://github.com/containerd/runwasi/issues/209 to adapt to the new interface.

I think can_handle is not part of the executor interface and instead it is expected that we call can_handle from within exec() and return an appropriate error if it can't be used.

Yeah, as @0xE282B0 mentioned, this was the latest breaking change post v0.1.0 of libcontainer and we are still depending on the released version so we will deal with the refactoring later at #209.

I've updated this PR to add linux container executors to both Wasmtime and WasmEdge shims.

Hey thanks everyone for reviewing this PR! I realized it's very difficult to squash commits before merge so I did a squash merge all together to make main branch clean. We can set a policy to only allow squash merge, wdyt? @jsturtevant


[Bug]: Error/outline not displayed when no option is selected (when “Required" is enabled)

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Error/red outline is not displayed when we do not select an option (when “Required" is enabled).

Steps To Reproduce

Go to https://ce-28848.dp.appsmith.com/ (this is an Anvil DP. The URL can change in the future).
DnD a SwitchGroup widget.
Enable the Required property.
Do not select any option.

Expected: We should see an error/red outline when no option is selected.
Actual: We do not see any error/outline
Public Sample App
No response
Environment
Deploy Preview
Issue video log
No response
Version
Cloud


upgrade rubocop to 1.41.1

Signed-off-by: Andrew Fader<EMAIL_ADDRESS>

Overall this looks great, thank you!
The big problem with it is that the CI fails. I haven't had time to track the problem down - is it trying to load a different version of Ruby? I don't think so, but that if that's not it, I'm not sure what the cause is. We generally only want to merge code if the CI passes. If the CI is busted, I'd like your help in figuring out the cause. Maybe we can isolate a few lines of change and see if it works.
Also: in general, we try to make much smaller changes than this, especially as you're just starting up. Big changes like this make it hard to debug any problems, because it's hard to separate process problems from any problems in the actual proposed change. I suggest starting with changes only a few lines long, and then once process problems are ironed out, we can expand things. E.g., make a few changes to make it ready for a new version of rubocop, without changing the version of rubocop, and just propose that as a pull request. That'll greatly ease debugging.
This makes a lot of changes so that the code takes > 80 characters. I have a minor preference for code to stay within 80 characters, but that is definitely not a hill to die on, so I figure we'll just accept these kinds of changes and move on.
I worry about changes in the location of the copyright statement, such as in test/application_system_test_case.rb. Obviously from code point of view it doesn't matter where the comments are, but I think from a legal point of view we want the copyright and license declarations as early as we can make it. We don't want anyone to be able to argue that they didn't see this information when they looked at the source files. This isn't really a serious problem, but we're trying to be exemplary. So I think these should be lines 2 and 3 at the latest, and certainly before any non-comment lines:
# Copyright the OpenSSF Best Practices badge contributors
# SPDX-License-Identifier: MIT

So: If it's not too much trouble, I'd like all code (including the "require" statements) AFTER the Copyright & License declarations.
Again, thanks so much for getting started on this! I'm looking forward to this and the next steps.

Overall this looks great, thank you!
Thank you!

the CI fails. I haven't had time to track the problem down
looks like this is the trace we're given, I think it's configuration and not code related. I'm happy to help debug it but will need some kind of access to the CI configuration to fix it. Although it could be obfuscating the real problem. The rake ran green locally.

 /action/lib/github_client.rb:36:in `request_http': Forbidden: {"message":"Resource not accessible by integration","documentation_url":"https://docs.github.com/rest/reference/checks#create-a-check-run"} (RuntimeError)
	from /action/lib/github_client.rb:16:in `post'
	from /action/lib/github_check_run_service.rb:14:in `run'
	from /action/lib/index.rb:29:in `<main>'

This makes a lot of changes so that the code takes > 80 characters. I have a minor preference for code to stay within 80 characters, but that is definitely not a hill to die on, so I figure we'll just accept these kinds of changes and move on.

I'm happy to ignore that rule or move those changes to another PR: let me know if you want to do that.

So: If it's not too much trouble, I'd like all code (including the "require" statements) AFTER the Copyright & License declarations.

Probably the best way to accomplish this is to ignore the rule that moves the require statements. That will also make this PR a little smaller.

looks like this is the trace we're given, I think it's configuration and not code related. I'm happy to help debug it but will need some kind of access to the CI configuration to fix it. Although it could be obfuscating the real problem. The rake ran green locally.

Ok. You've gained my trust through our interactions. I'm going to add you to the list of developers on the badge project. I don't know if that will give you the access you need. If not, me know specifically what access you need.

So: If it's not too much trouble, I'd like all code (including the "require" statements) AFTER the Copyright & License declarations.

Probably the best way to accomplish this is to ignore the rule that moves the require statements. That will also make this PR a little smaller.

That sounds good.


high poller interval problem

Hi, I noticed if I set POLLER_INTERVAL_MILLISECONDS=300000 or to a bigger value,
it will not create any secrets even after an hour and in logs I see successful status
{"level":30,"time":1566397148667,"pid":17,"hostname":"external-secrets-kubernetes-external-secrets-7d65747f56-5h5lw","msg":"spinning up poller {\"id\":\"7815d6df-c41c-11e9-a8dd-0622d2c58d44\",\"namespace\":\"default\",\"secretDescriptor\":{\"backendType\":\"secretsManager\",\"data\":[{\"key\":\"hello-service/password\",\"name\":\"password\"}],\"name\":\"hello-service2\"},\"ownerReference\":{\"apiVersion\":\"kubernetes-client.io/v1\",\"controller\":true,\"kind\":\"ExternalSecret\",\"name\":\"hello-service2\",\"uid\":\"7815d6df-c41c-11e9-a8dd-0622d2c58d44\"}}","v":1}
{"level":30,"time":1566397148668,"pid":17,"hostname":"external-secrets-kubernetes-external-secrets-7d65747f56-5h5lw","msg":"starting poller","v":1}

app version 1.3.1

#117 and #133 probably relevant :)
I'm guessing that the poller restarts to often and never actually polls, you could probably try downgrading to 1.3.0. Not that 5 minutes sound like a high interval to me :P

thanks for answer but tried old versions and same behavior(


Handle class properties

Problem
Input:
export default class C {
  x = 1;
}

Output:
export default class C {}

The class property has been ignored. new C().x on source is 1, on output it's undefined.
Not affected
This problem does not affect:

Static properties. static y = 2; output as export default Object.assign( class C {}, { y: 2 } ).
Class instances. new C() output as Object.assign( Object.create( class C {}.prototype ), { x: 1 } )

Side-effects
The problem is that there can be side effects when calling a class to extract its scope vars:
function f () {
  console.log('f called');
  return 1;
}

class C {
  x = f();
}

f() is called on instantiating the class with new C(). That call happens before the class constructor is called, so it's not possible to prevent f() being called by throwing an error in the tracker function in constructor (usual method Livepack uses to bail out before any side effects occur).
Solution
Need to pre-process with @babel/plugin-proposal-class-properties, or implement same logic in Livepack.
It would be even better if:

Babel plugin transformed code which runs at build time to move class property declarations inside class constructor (as @babel/plugin-proposal-class-properties does)
Serialized output restores original code with class property.

Would be easier to implement this after #65 is implemented.

Advantage of implementing own version of @babel/plugin-proposal-class-properties's transform would be to avoid transpiling private class fields, which that plugin also does.
But bear in mind that sometimes vars in constructor need to be renamed to allow access to external vars used in property initialization.
e.g.:
class C {
  constructor(f) {
    this.y = f;
  }

  x = f();
}

Babel transpiles this to:
class C {
  constructor(_f) {
    Object.defineProperty( this, 'x', f() );
    this.y = _f;
  }
}

(Babel REPL)
This would not work if class constructor contains eval() which can access f e.g.:
class C extends SuperC {
  x = f();

  constructor(f) {
    super();
    this.z = eval('f');
  }

  y = super.foo();
}

An alternative which:

doesn't require var renaming
supports use of this in initializations
support use of super in initializations
maintains order of code (so line numbers in transpiled output can be same as original)

function _extractClassInit(Klass, initSymbols, setInit) {
  const { prototype } = Klass;
  const initMethods = initSymbols.map( symbol => {
    const method = prototype[symbol];
    delete prototype[symbol];
    return method;
  } );

  setInit( instance => {
    initMethods.forEach( method => method.call(instance) };
    return instance;
  } );

  return Klass;
}

const _initSymbol1 = new Symbol(),
  _initSymbol2 = new Symbol();
let _init;
let C = _extractClassInit(
  class C extends SuperC {
    [_initSymbol1]() {
      this.x = f();
    }
    constructor(f) {
      _init( super() );
      this.z = eval('f');
    }
    [_initSymbol2]() {
      this.y = super.foo();
    }
  },
  [ _initSymbol1, _initSymbol2 ],
  init => _init = init
);

Another alternative: Avoid need to call class constructor at all when serializing classes:
const _classes = new WeakMap();
const _recordClass = (Klass, tracker) => {
  _classes.set(Klass, tracker);
  return Klass;
};

const livepack_scopeId_1 = livepack_getScopeId();
let C = _recordClass(
  class C {
    constructor() {
      this.x = x;
    }
  },
  () => /*livepack_track:{"id":2,"scopes":[{"blockId":1,"varNames":["x"]}]}*/ [[livepack_scopeId_1, x]]
)

The tracker function is recorded in _classes and, when serializing the class, tracker can be called directly rather than calling the class constructor.
This is a lot simpler!

There is a simpler solution to preventing side effects:
1. Classes with extends super class
Class constructor is called before field initializers. So tracker in constructor (same as at present) will be called and short circuit execution before class field values are evaluated.
2. Classes with no extends
Put tracker in first class field e.g.:
class X {
  x = f()
}

becomes:
class X {
  x = livepack_tracker() || f()
}

This will call tracker() before any other code executes, and so prevent side effects.

There is one tricky complication with class fields - dynamic field names.
e.g. Input:
let counter = 0;
const getFieldName = () => `x${counter++}`;

const getClass = () => {
  return class {
    [getFieldName()] = 1;
  };
};

export default [ getClass(), getClass() ];

getFieldName() is evaluated when the class is defined, not when it's constructed.
So output would need to be:
const createScope = _fieldName => class {
  [_fieldName] = 1
};
export default [ createScope('x0'), createScope('x1') ];

_fieldName can only be a string or a Symbol, so can't be a circular reference.
This would require Babel plugin to evaluate field key expressions before class declaration, and for them to be passed to serializer via the tracker.
// Babelized
function _conformToStringOrSymbol(value) {
  if (typeof value === 'symbol') return value;
  return value + '';
}

const getClass = () => {
  let livepack_temp_1;
  return class {
    [
      livepack_temp_1 = _conformToStringOrSymbol( getFieldName() )
    ] = livepack_tracker( () => [ /* ... */, [livepack_temp_1] ] ) || 1;
  };
};

Arrow functions defined in class properties need access to this:
// Input
class C {
  getThis = () => this
}
export default new C().getThis;

Solution 1
This requires Babel plugin to wrap field declarations in methods which inject in this and scope ID var for this:
// Babelized
function _extractClassFieldInitializers( klass, initializerSymbols, setInitializer ) {
  const proto = klass.prototype;
  const initializers = initializerSymbols.map( (initializerSymbol) => {
    const initializer = proto[initializerSymbol];
    delete proto[initializerSymbol];
    return initializer;
  } );
  setInitializer( (_this, scopeId) => {
    for (const initializer of initializers) {
      initializer.call(_this, scopeId);
    }
    return _this;
  } );
  return klass;
}

let livepack_temp_1, livepack_temp_2;
let C = _extractClassFieldInitializers(
  class /*livepack_track:5;c;*/ X {
    [ livepack_temp_1 = Symbol() ]( livepack_scopeId_8 ) {
      this.getThis = {
        getThis: () => /*livepack_track:9;f;*/ {
          livepack_tracker( livepack_getFnInfo_9, () => [ [livepack_scopeId_8, this] ] );
          return this;
        }
      }.getThis;
    }

    constructor() {
      livepack_tracker( livepack_getFnInfo_5, () => [] );
      const livepack_scopeId_8 = livepack_getScopeId();
      livepack_temp_2(this, livepack_scopeId_8);
    }
  },
  [livepack_temp_1],
  initalizer => livepack_temp_2 = initalizer
};
export default new C().getThis;

NB If class constructor has complex params, call to field initializer would need to be in constructor params to ensure side effects of class fields execute before side effects of function params. See https://github.com/overlookmotel/livepack/issues/108#issuecomment-1051408296.
Solution 2
Alternatively, could avoid nesting fields in methods by injecting scope ID var directly into any arrow functions:
// Input
class C {
  getThis = () => this;
  constructor() {
    this.getThis2 = () => this;
  }
}
const c = new C();
export default [ c.getThis, c.getThis2 ];

// Babelized
function _bindWithScopeId(fn, scopeId, name) {
  const boundFn = fn.bind(undefined, scopeId);
  Object.defineProperty(boundFn, 'name', {value: name || ''});
  return boundFn;
}

let livepack_temp_1;
class /*livepack_track:5;c;*/ C {
  getThis = (
    livepack_tracker( livepack_getFnInfo_5, () => [] ),
    livepack_temp_1 = livepack_getScopeId(),
    _bindWithScopeId(
      (livepack_scopeId_8) => /*livepack_track:10;f;*/ {
        livepack_tracker( livepack_getFnInfo_10, () => [ [ livepack_scopeId_8, this ] ] );
        return this;
      },
      livepack_temp_1,
      'getThis'
    )
  );

  constructor() {
    const livepack_scopeId_8 = livepack_temp_1;
    this.getThis2 = () => /*livepack_track:9;f;*/ {
      livepack_tracker( livepack_getFnInfo_9, () => [ [ livepack_scopeId_8, this ] ] );
      return this;
    };
  }
}
const c = new C();
export default [ c.getThis, c.getThis2 ];

This solution relies on class construction being synchronous. livepack_temp_1 holds the scope ID only during initial synchronous construction and it's transferred to long-lasting livepack_scopeId_8 vars. If the class is instantiated a 2nd time, livepack_temp_1 will be overwritten with a different scope ID for the 2nd class instance, but it doesn't matter as the tracker calls refer to livepack_scopeId_8 which has already captured the first scope ID and held it in local scope.
This solution has 2 advantages over the first:

Doesn't introducing an additional function wrapper so will not add an entry the stack trace if an error is thrown in the field initializer.
Will be more performant as no adding methods and then deleting them.

Disadvantage is that's it's a bit tricky to wrap the arrow functions. Only top level arrow functions should have scope ID injected. i.e. for class C { getGetThis = () => () => this }, only the outer arrow function would have scope ID injected. The inner arrow function can access it from the outer one.

Binding/block for this actually doesn't need to be shared between class constructor and prototype properties. this is not mutable, so each could have their own this block. This would simplify implementation.

There is a way to deal with arrow functions in class properties without closures or .bind() - private properties.
Modification of "Solution 2" example above:
let livepack_temp_1;
class /*livepack_track:5;c;*/ C {
  #livepack_scopeId_8 = livepack_tracker( livepack_getFnInfo_5, () => [] ) || livepack_getScopeId();
  getThis = () => /*livepack_track:10;f;*/ {
    livepack_tracker( livepack_getFnInfo_10, () => [ [ this.#livepack_scopeId_8, this ] ] );
    return this;
  }

  constructor() {
    this.getThis2 = () => /*livepack_track:9;f;*/ {
      livepack_tracker( livepack_getFnInfo_9, () => [ [ this.#livepack_scopeId_8, this ] ] );
      return this;
    };
  }
}
const c = new C();
export default [ c.getThis, c.getThis2 ];

It's not difficult to ensure no var name clashes for the private property used by Livepack.
However, this doesn't solve the problem for classes using super in class properties. They can't use private fields on outer class for temp vars, as this within the inner class is not the right this.

After closing #541, I think class properties are now supported.
Private properties are also now supported I believe (though they're pretty useless as they can't be accessed by class methods).
Side-effects when serializing classes (#549) is still an open issue, but solution is clear.
Once that's solved, will just need tests to make sure class properties work as intended.

Actually, support is not complete. Computed property keys aren't supported. e.g.:
const propName = 'x';
class X {
  [propName] = 123
}

Computed property keys are calculated at time class is defined, so would need to be saved in temp vars in instrumentation, and then passed to serializer so it can recreate them.
Complicated case:
function createClass(getPropName) {
  return class {
    ['_' + getPropName()] = 123;
  };
}
export default [
  createClass(() => 'x'),
  createClass(() => 'y')
];

'_' + getPropName() is evaluated at build time, and getPropName should not be included in output.
Would need to be serialized as:
const scope = prop => class { [prop] = 123; };
export default [scope('_x'), scope('_y')];

This is tricky as prop is a var that doesn't exist in the original source. There is no mechanism for handling this in Livepack at present.

To solve the problem of requiring a closure around classes defined inline in class fields, temp vars for class (super target) and associated scope ID could be avoided as follows:
Input:
const C = class {
  foo() {
    super.foo();
  }
};

Instrumented:
const _scopeIdsForClasses = new WeakMap();

const C = class livepack_temp_1 {
  static {
    _scopeIdsForClasses.set(this, livepack_get_scopeId());
    Object.defineProperty(this, 'name', {value: 'C'});
  }
  foo() {
    super.foo();
  }
};

Tracker in foo() method can access the super target as livepack_temp_1 and scope ID as _scopeIdsForClasses.get(livepack_temp_1).
NB: .name is set in a static block inserted at top of the class, in case it's later over written by a static field e.g. static name = 'foo' or code in another static block.
This would re-introduce some of the complexity in determining implicit class names which was removed in solution to #483. But it should work.

Solution 2 in comment above concerning binding scope IDs into arrow functions has one bug.
As I said above, it relies on the synchronous nature of class instance construction. But could be messed with if a class field creates an instance of same class:
class C {
  foo = new C();
  getThis = () => this;
}

If this was instrumented as
let livepack_temp_1;
class /*livepack_track:5;c;*/ C {
  foo = (
    livepack_tracker( livepack_getFnInfo_5, () => [] ),
    livepack_temp_1 = livepack_getScopeId(),
    new C()
  );
  getThis = _bindWithScopeId(
    (livepack_scopeId_8) => /*livepack_track:10;f;*/ {
      livepack_tracker( livepack_getFnInfo_10, () => [ [ livepack_scopeId_8, this ] ] );
      return this;
    },
    livepack_temp_1,
    'getThis'
  );
}

then new C() will overwrite livepack_temp_1.
Using a private field to contain scope ID (also suggested above) solves this. As would using a different block and scope ID for each class field.
Private field solution is simpler. Only disadvantage is that the private field could be accessed with an eval() somewhere in the class, and only way to name the private field to prevent this would be to rename any matching private field accesses when instrumenting the eval() code, which would introduce complexity again.

Actually, using a private field where there were no private fields previous will cause legal code to become illegal in this edge case:
const o = {x: 1};
class S {
  constructor() {
    return o;
  }
}

class C extends S {}

new C();
new C();

That executes OK, but if a private field #livepack_scopeId is added to C, then it fails with TypeError: Cannot initialize #livepack_scopeId twice on the same object.
For the same kind of reason, while it's tempting to think you could use a WeakMap to associate this values with scope IDs, it wouldn't work because this is not necessarily unique in each class instantiation.


Update aws-core, http-client-spi, ... to 2.19.5

Updates

software.amazon.awssdk:aws-core
software.amazon.awssdk:http-client-spi
software.amazon.awssdk:netty-nio-client

from 2.17.295 to 2.19.5.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #1086.


Update of Brazil CNEFE Census 2022 data (National&improved by AddressForAll)

IBGE data filtred by Addressforall

FYI, the treatment that was done with the national DB is the following: https://github.com/digital-guard/preserv-BR/blob/main/data/_pk0001.05/SRC_README.md .

Hello,
Please can you verify any problem with the data?

Looks like it's the same problem as the US National Address Database in #7253 – we're running out of disk space to process this source.
@ingalls if you have a chance can you give these workers more room again?


helm init error

error installing: Get https://<IP_ADDRESS>:8443/api: dial tcp <IP_ADDRESS>:8443: getsockopt: connection refused

Is this Helm 2.0.0-Alpha.5?
What kind of Kubernetes cluster? GKE? Minikube?

thank you ,I have success by change kube config to my own master server .thanks .


Removed AssociatePublicIpAddress setting from NodeLaunchCongig and ad…

…ded NodeSecurityGroup dependency to SG Ingress/Egress
Issue #, if available:
Description of changes:

Added NodeSecurityGroup dependency to SG Ingress/Egress.
We used to enforce public ip assignment for nodes in ASG. Now we are defaulting it to subnet setting

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

looks good to me


Ignore NotFound errors when deleting expired data.

When starting bkt in parallel, the multiple bkts race to clean up expired data. This opens the possibility that deletions will fail because the file has already been deleted... but that's okay, we wanted to do that anyway. So this change ignores NotFound errors on the deletion.
Currently, the result of this race is errors as follows:
bkt: Cache lookup failed: Failed to remove expired data: No such file or directory (os error 2)

Fixes #38

Thanks @eatnumber1!


[BUG] Error when running?

Describe the bug
I cant seem to run the Lolisafe service.
To Reproduce
Steps to reproduce the behavior:

Git clone the project
cd lolisafe
npm i
change config.sample.js to config.js (also changed domain)
node lolisafe.js
(Using node 7.10.x)

Expected behavior
Start the lolisafe service.
Screenshots

Additional context
I think it has to do with the SQL database.
My VPS runs:
30 gigs of ram
16 Vcores
300gb HDD
Ubuntu 20

Just for the sake of checking, could you try running it with a more recent version of node like 12 or 14?

I fixed the issue, i changed the version to 12 and reinstalled the whole thing, it's now up and running.
Also for the domain, i had to set it to ' '  if i wanted to run it from the ip, i know it's not intended.


update cip21 to expand specification

I tried to expand and update the CIP to clarify the implementation and expected behavior. Please review to ensure I got it right 👍

Force push was to rebase onto latest master


bilinear and quadratic forms

I don't know how to check to see if I made any typos.
I think this might be all we have.

Thanks!


Define strategy for implementing folds

Plan how folds will be stored, on which layers they'll have to be considered (i.e. for things like movement, edit actions, etc), and how they'll be communicated to the frontend layer as well as to plugins.

Possibly related to #26.


Feature request: Please handle "forever" appliances

We'd like to have a "forever" option for appliance lifetime. In this case, no scheduled deletion (i.e. no cronjob) should be created. Or, perhaps even better, a cronjob should be created but for some far off time, say the last day of 2037 to avoid the Y2K38 bug

I have just merged support for this, please test it out, and report back if this works now.

This seems to work. I created a "forever" appliance and no cronjob was created, as expected


[Help] ilastik batch process step cannot find pixel_classifier.ilp

After training in ilastik, I ran the following command:
steinbock classify ilastik run --ilp pixel_classifier.ilp

However, it raises an Error:
Error: Invalid value for '--ilp': File 'pixel_classifier.ilp' does not exist.

If I list the files in the directory, I can see the ilastik project file is there
> ls
ilastik_crops  ilastik_img  ilastik_probabilities  pixel_classifier.ilp

Hi @Mr-Milk, could you please post your steinbock alias here? Thanks

Oh! The path should be relative to the path I mount to it. I forget that this is an alias command.


Add region-processing of REMIND 2.1

This PR adds the region-processing to the openentrance workflow, using the REMIND 2.1 model as a prototype. See https://github.com/openENTRANCE/openentrance/issues/119#issue-1041347710 for the related request by @Renato-Rodrigues.
To-do for this PR:

[ ] add region-mapping (to be confirmed by @Renato-Rodrigues)
[ ] add region-processing to workflow
[ ] add method-attributes to variables in definitions that are not simple summation of subregions
(see #131)

@phackstock, there is a strange error message here as part of the validation:
mappings -> REMIND 2.1
31
  'mappings/remind_2.1.yaml' is not in the subpath of '/home/runner/work/openentrance/openentrance' OR one path is relative and the other is absolute. (type=value_error)

I tested it locally against the current status of https://github.com/IAMconsortium/nomenclature/pull/51 and it also fails. Can you please take a look?

@Renato-Rodrigues, can you please confirm the following:

do you want the renamed native regions of the scenario data to shown as "REMIND 2.1|United Kingdom and Ireland" or "REMIND 2.1|UKI"?
that the common-region-aggregation mapping is correct - in particular, should UKI be added to EU27 explicitly?

@Renato-Rodrigues, can you please confirm the following:

do you want the renamed native regions of the scenario data to shown as

REMIND 2.1|United Kingdom and Ireland
REMIND 2.1|UKI

I would be perfectly fine with either of above options or both. Whatever you find more consistent with the current naming convention on the db.

that the common-region-aggregation mapping is correct - in particular, should UKI be added to EU27 explicitly when computing EU27 & UK? Not sure whether that would double-count Ireland...

The only change I would make to the mappings/remind_2.1.yaml file is setting:
https://github.com/danielhuppmann/nomenclature/blob/abddbf0a0b24663e87ccf88fc04d072bd65c9d49/mappings/remind_2.1.yaml#L29
to
- EU27 & UK:
     - DEU
     - ECE
     - ENC
     - ECS
     - ESC
     - ESW
     - EWN
     - FRA
     - UKI

Just to explain better, it is more or less the opposite of what you inferred. Currently EU27 in REMIND does not include Ireland, as this country is not disaggregated from UK, that is why we provide an EU27 aggregation in the results we report. During the project course we will split Ireland from UK to be able to provide a perfect EU27 definition directly from the model native regions.

@danielhuppmann ah yes that error occurs when you try to get the relative path of an already relative path. I'll prepare a PR with the fix on nomenclature.

Updated IAMconsortium/nomenclature#51, should be taken care of with that PR.

Thanks for the review @Renato-Rodrigues. I kept the short-names for the renamed native regions for consistency with the REMIND docs.
I implemented the following changes:

Change components of "EU27 & UK" as per your comment
Remove "EUR" and "NEU" from the native regions saved to the database
Remove "NEU" from "R5OECD90+EU"

Open question (related to item 3 above): computing "World" during the scenario processing would be possible, but this would mean that "Price|Carbon" is not included at the global level. This is because pyam currently does not compute weighted averages if the weights are negative - see the discussion at https://github.com/IAMconsortium/pyam/issues/446. So I suggest that for the time being, you compute results at the global level on your side (including the carbon price) and include it in your uploads.

@phackstock, I noticed one design issue of the RegionProcessor - if we do renaming of the native-regions as part of the workflow, we have to apply the region-processing before the validation. On the other hand, doing the region-processing (which is the most time-intensive part of the processing) and only then doing the validation means that we do a lot of computation and only then raise an error if variables or units are incorrect.
Therefore, I split the validation here by dimensions:

Variable (and unit) validation
Region processing
Region validation

Open question (related to item 3 above): computing "World" during the scenario processing would be possible, but this would mean that "Price|Carbon" is not included at the global level. This is because pyam currently does not compute weighted averages if the weights are negative - see the discussion at IAMconsortium/pyam#446. So I suggest that for the time being, you compute results at the global level on your side (including the carbon price) and include it in your uploads.

@danielhuppmann Then, for now, I will upload World as one of the native REMIND regions. But this bring another request for a change.
Due to the same reason, I would request to add back EUR as one of the REMIND native regions, and remap the EU27 & UK region to it, so we can have also Carbon Price results in this regional aggregation level also:
- EU27 & UK:
      - EUR

I can also do these changes after you merge your pull request. Your choice.
PS: Unfortunately, or fortunately :-), I see the same issue of negative emissions in R5 region aggregations. As Carbon Price is a quite important variable for the global assessments, maybe we will need to focus soon on finding a good compromise about this for the project results.

@danielhuppmann Ah right, good point. I've thought about it for a minute and I think the easiest solution would be to generally limit the DataStrucutreDefinition.validate() function to variables (or in the future any other parameters that are not going to be changed in the renaming process). I think that the second validation of the regions is redundant as that is already covered when initializing the RegionProcessor under RegionProcessor.validate_mappings.

@Renato-Rodrigues, I added EUR to the list of native regions it is now directly renamed, so prices are being maintained. But I guess we will need a larger conversation on how to deal with this. The pyam package (which powers this feature) by default does not compute values for weighted average if any weight is negative. This can be overridden with drop_negative_weights=False (read the docs) and it can be passed via the variable-attributes in the definitions - but this can have strange effects, like having a weighted average of negative-infinite prices even if all prices are positive...

@Renato-Rodrigues, I merged as is - please feel free to give this a test-run on the ECEMF-internal Scenario Explorer.

@phackstock, the region-validation as part of RegionProcessor.apply() only occurs if a region-mapping exists - models with a region-mapping are not validated there. I'll open an issue in the nomenclature repo, let's continue this discussion over there...


Order of reactions' execution

I know that reaction callbacks are run asynchronously, but is the order of their execution kept?
Just found that connectedCallback is called before attributeChangedCallback if custom element is rendered by angular.
https://jsfiddle.net/36x4s44w/2/
I've been investigating this, but still have no idea what goes wrong

that's how native works too. The order in which attributeChangedCallback and connectecCallback are triggered is completely arbitrary. There's no rule whatsoever because these two methods are not correlated at all.

P.S. if what you need is an init event, you can use a very simple work around
class HTMLInitElement extends HTMLElement {
  static init() {}
  init() {
    // init should never happen more than once
    // so, make it a no-op from now on
    this.init = HTMLInitElement.init;
  }
  attributeChangedCallback(...args) {
    this.init();
  }
  connectedCallback() {
    this.init();
  }
}

class MyEl extends HTMLInitElement {
  static get observedAttributes() { return ['test']; }
  init() {
    super.init();
    console.log('init');
  }
  attributeChangedCallback(...args) {
    super.attributeChangedCallback(...args);
    console.log('attributeChangedCallback');
  }
  connectedCallback() {
    super.connectedCallback();
    console.log('connectedCallback');
  }
}

customElements.define('my-el', MyEl);

document.body.innerHTML = '<my-el></my-el><my-el test=123></my-el>';

@WebReflection thanks for explanation!


TypeError: device is undefined

https://thematthewhudson.com/current-device/
Demo is also not working.  There is a error in console "TypeError: device is undefined" after you had made the changes.

@kiran-gupta Great catch. Looks like the module definition is slightly different:
Recent stable release: v0.7.2
Current release: v0.7.7

@matthewhudson  hi is there a way to use the current release ?
the device variable is still undefined.  Uncaught TypeError: Cannot read property 'os' of undefined
thanks


Options config value accepts only scalar values

I was trying to set the options config key in the Symfony configuration but it accepts only scalar values while it should accept an array of key/values. Changing the prototype of the node from scalar to variable in the config tree builder works, although I think it would be better to have a full definition that checks all options available so that a user cannot add whatever he wants. Let me know what you think about this, I could submit a PR that fixes the issue

You are right! It should accept a full array, but maybe we should limit the amount possible stuff that can be passed in there?
PR is more than welcome!

but maybe we should limit the amount possible stuff that can be passed in there?

Indeed, but does it makes sense to invest time in doing it now when 2.0 version of the base library is being developed?

It should accept a full array

Indeed, at the moment noone can use the options because of this

I discovered the same issue when setting tags via options and took a look at the configuration tree of the bundle. There seems to be same issue multiple times (options, skip_capture, prefixes, excluded_app_paths, ...). The prototype is defined as scalar although the default is an array.
I thought about creating a PR to define the options that are also used by the Raven-Client but then again some values are set via setter injection and some via the configuration. I can think of three possible solutions:

A. Add all the options the client accepts to the options property of the configuration tree and get rid of those that would be duplicate like environment (BC break).
B. Create all the configuration options the client accepts at the same level as environment and pass the whole configuration on to the client (not that clean). options could then be removed.
C. Leave the existing configuration properties as they are and add the not existing ones to the options property (not very clean but would not cause a BC break).

What do you think? I would prefer solution A as it is the cleanest one but some feedback before starting on the PR would be appreciated.

Since options is not working in the current form, I wouldn't consider it a BC changing the way it works; I also like option A, but I would prefer to deprecate first and drop later (in next major) the duplicates; we can accept both and throw an exception when both are defined but with different values.
In fact this is a mixed A-C approach, but just as a deprecation path towards a full-A case. I think that would be better, since in next major we will probably rewrite the option part anyway, due to the v2 ov the Sentry client.

@Jean85 Do you know when the next major will be released? I am just wondering if it's even worth to change it or just move on to the next version...

The v2 of the Sentry client is currently being worked on, but it's still a long way to go, it will not be ready for months.

Issue solved! I will tag it next week.


New package: SnowflakeInc.SnowflakeODBCDriver64Bit version 3.1.1

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@microsoft-github-policy-service agree [company="The Information Lab"]
On Nov 9, 2023, 3:15 PM +0000, wingetbot @.***>, wrote:

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

@microsoft-github-policy-service agree
On Nov 9, 2023, 3:17 PM +0000, microsoft-github-policy-service[bot] @.***>, wrote:

@microsoft-github-policy-service agree


return explicit network thresholds

resolves https://github.com/VEuPathDB/EdaDataService/issues/340
are people ok w the revised api?

also i think there was another api change we talked about? something about stroke widths vs edge weights. do we have an issue for that? and do we want to handle that at the same time in this pr?

i think it looks good. Makes sense to keep the thresholds separate from the bipartite network.
Yes we were talking about another api change. let me go find that. I'd love to get that in before release. Doesn't have to be this PR if you're ready to merge.


How to run tests?

Maybe it's because of the difference in operating systems, but the straight forward way of running the tests did not work. I forked & cloned the repo, then
> npm install
> npm install -g mocha #not sure if it's necessary, did it anyways
> npm test

Now I can see in the log, that the build completes fast & without errors, but the tests don't even start:
E:\core-decorators.js>npm test

><EMAIL_ADDRESS>test E:\core-decorators.js
> npm run build && mocha --compilers js:babel/register --require babel/polyfill 'test/**/*.spec.js'

><EMAIL_ADDRESS>build E:\core-decorators.js
> babel --out-dir lib src

src\autobind.js -> lib\autobind.js
src\core-decorators.js -> lib\core-decorators.js
src\debounce.js -> lib\debounce.js
src\decorate.js -> lib\decorate.js
src\deprecate.js -> lib\deprecate.js
src\enumerable.js -> lib\enumerable.js
src\memoize.js -> lib\memoize.js
src\mixin.js -> lib\mixin.js
src\nonconfigurable.js -> lib\nonconfigurable.js
src\nonenumerable.js -> lib\nonenumerable.js
src\override.js -> lib\override.js
src\private\utils.js -> lib\private\utils.js
src\readonly.js -> lib\readonly.js
src\suppress-warnings.js -> lib\suppress-warnings.js
src\throttle.js -> lib\throttle.js
E:\core-decorators.js\node_modules\mocha\lib\utils.js:626
        throw new Error("cannot resolve path (or pattern) '" + path + "'");
        ^

Error: cannot resolve path (or pattern) ''test/**/*.spec.js''
    at Object.lookupFiles (E:\core-decorators.js\node_modules\mocha\lib\utils.js:626:15)
    at E:\core-decorators.js\node_modules\mocha\bin\_mocha:316:30
    at Array.forEach (native)
    at Object.<anonymous> (E:\core-decorators.js\node_modules\mocha\bin\_mocha:315:6)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Function.Module.runMain (module.js:467:10)
    at startup (node.js:134:18)
    at node.js:961:3
npm ERR! Test failed.  See above for more details.

E:\core-decorators.js>

Now If I run tests individually, like
mocha --compilers js:babel/register --require babel/polyfill test\unit\autobind.spec.js

I get errors like this:
  1) @autobind returns a bound instance for a method:
     TypeError: Cannot read property 'equal' of undefined
      at Context.<anonymous> (E:/core-decorators.js/test/unit/autobind.spec.js:48:20)
      at callFn (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runnable.js:286:21)
      at Test.Runnable.run (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runnable.js:279:7)
      at Runner.runTest (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runner.js:421:10)
      at C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runner.js:528:12
      at next (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runner.js:341:14)
      at C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runner.js:351:7
      at next (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runner.js:283:14)
      at C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runner.js:314:7
      at done (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runnable.js:247:5)
      at callFn (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runnable.js:301:7)
      at Hook.Runnable.run (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runnable.js:279:7)
      at next (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runner.js:297:10)
      at Immediate._onImmediate (C:\Users\a\AppData\Roaming\npm\node_modules\mocha\lib\runner.js:319:5)

...

Which is also super weird.
So, is there any specific thing I need to do before I can run the tests?
I'm on Windows 8.1 by the way using node 4.2.1, npm 2.14.7

Hmm guessing Windows related as well. I'll take a look as soon as I can.

Cool, thanks, are you working on a Mac or Linux?

@bali182 I do most of my dev on Mac but the test runner is on Linux. Checking things out on Windows, it appears simply an issue with the Unix-style paths I use and them not getting normalized for the Windows-style. It's been years since I've used a Windows command line though so I may be misdiagnosing.
After the holidays I'll have some time to dig deeper and find out what others do about this.

Ok, thanks, in the meanwhile I install a linux too. I shouldn't be using the windows command line anyways :smile:

@bali182 fyi, @kwonoj was kind enough to fix the Windows testing issue.


Azure Batch data plane C# SDK version 7.1

Description

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] I have read the contribution guidelines.
[x] The pull request does not introduce breaking changes.

General Guidelines

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

SDK Generation Guidelines

[x] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[x] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code.
[x] The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK.

Please do not merge until I have gotten signoff from some of my reviewers

I don't think the default build failure has anything to do with the changes I made... can somebody take a look?

@itowlson Thanks for looking. As for the hard to review PR, agree. This is a bit unfortunate, but what i would suggest is going commit by commit in order to dodge the one where we had a bunch of this.'s added.

@matthchr can you provide a link to the swagger PR for this change.

There were two Swagger merges that are included in this change:
https://github.com/Azure/azure-rest-api-specs/pull/1426
https://github.com/Azure/azure-rest-api-specs/pull/1288


Feature Support array_pushback function #17417

Proposed changes
Issue Number: close #17417
Problem summary
Implement array_pushback.
mysql> select array_pushback([1, 2], 3);
+--------------------------------+
| array_pushback(ARRAY(1, 2), 3) |
+--------------------------------+
| [1, 2, 3]                      |
+--------------------------------+
1 row in set (0.01 sec)

Checklist(Required)

[ ] Does it affect the original behavior
[x] Has unit tests been added
[x] Has document been added or modified
[ ] Does it need to update dependencies
[x] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run p0

run p0

run p0

run buildall

run buildall

run buildall

run p0

run build

run buildall

run p0

run p1

run buildall

This logic is almost the same as array_pushfront, and I think we can use templates to perform the parts that differ between them.

run buildall

run buildall

run p0

run buildall

run p1

LGTM

run buildall

run buildall

run buildall

run buildall

run beut

run beut


⚠ Catalog API Endpoint has degraded performance

In 860e9cf, Catalog API Endpoint (https://catalog.roblox.com/v1/bundles/details?bundleIds=192) experienced degraded performance:

HTTP code: 200
Response time: 4394 ms

Resolved: Catalog API Endpoint performance has improved in c8cc817.


ExceptionTelemetry clears all Context setting after setting ExceptionTelemetry.Exception

Verified using version 2.14.0 (with .NET 4.5) and 2.15.0 (with .NET 4.5.2)
Hosting environment is Windows

Describe the bug
A new context is created in an ExceptionTelemetry instance when using the Exception property setter. This unexpectedly clears any previously set Context values from the object.
To Reproduce
$ex = new-object Microsoft.ApplicationInsights.DataContracts.ExceptionTelemetry
$ex.Context.User.AccountId = "AccountId"
$ex.Context.User.AuthenticatedUserId = "AuthUserId"
$ex.Context.User.UserAgent = "ExceptionComponent"

Write-Host "Before"
Write-Host "-----------------------------------------------------"
$ex.Context.User | fl -Force

$ex.Exception = new-object System.Exception

Write-Host "After"
Write-Host "-----------------------------------------------------"
$ex.Context.User | fl -Force

Example output:

Observe that in the "Before", the Context.User object is populated with values, and in the "After" it has been cleared away. Looking at the code, it looks like a brand new TelemetryContext is created when the setter for the Exception property is used.
This seems like unexpected behavior and it is not specifically called out in the API documentation. Setting the exception value from outside of the .ctor should not clear the existing Context values.

+1. It was totally unexpected to me after I implemented a telemetry processor which analyzes and hides sensitive exception data. I had to copy data from original context into a new one created by ExceptionTelemetry.Exception setter.

It's still there. Double-checked on Microsoft.ApplicationInsight 2.21.


Revert gh-9619: "FIX: Sparse matrix addition/subtraction eliminates explicit zeros"

Reverts #9619.
It turns out some assumptions made were incorrect, and will need fixing. See scikit-learn/scikit-learn#13430 for more details.

All green, LGTM. Thanks @perimosocordiae


Fix method name in Random Sampling guide

Replaces usage of randomElements with randomSample in the Random Sampling guide.
Checklist

[ ] I've added at least one test that validates that my change is working, if appropriate
[x] I've followed the code style of the rest of the project
[x] I've read the Contribution Guidelines
[ ] I've updated the documentation if necessary

Thanks, @timvermeulen!


fix(package): update bunyan to version 1.8.8

Closes #244
https://greenkeeper.io/

Coverage remained the same at 98.969% when pulling 2b47633ae03cd8710f393413ba46120ea6aad88d on greenkeeper/bunyan-1.8.8 into c93f4e56805bdb7632552ea87315e978f874b003 on master.


LightTable 0.53 crashing on VirtualBox (with the Guest Additions?)

I'm running VirtualBox 4.2.16 (rev 86992) with LightTable running inside a Linux Mint 15 Olivia guest on a Windows 7 host and I get this error: The "LIGHT TABLE" screen appears but the menu is completely non-functional. I'm not sure if it has to do with the Guest Additions or if the fact that the computer recently updated GNOME (my desktop had changed). (It's not a GNOME problem as Firefox is fine).
Stack trace:
[2007:0917/230510:ERROR:browser_main_loop.cc(212)] Gdk: gdk_window_set_icon_list: icons too large
OpenGL Warning: glXChooseFBConfig returning NULL, due to attrib=0x2, next=0x20
[2032:0917/230512:ERROR:gl_surface_glx.cc(564)] glXChooseFBConfig failed.
[2032:0917/230512:ERROR:gpu_info_collector.cc(27)] gfx::GLContext::CreateOffscreenGLSurface failed
[2032:0917/230512:ERROR:sandbox_linux.cc(130)] InitializeSandbox() called with multiple threads in process gpu-process
[2007:0917/230517:INFO:CONSOLE(19199)] "Invalid behavior: :lt.objs.workspace/reconstitute-last-workspace", source:     app://lighttable/core/node_modules/lighttable/bootstrap.js (19199)
[2007:0917/230517:INFO:CONSOLE(19199)] "Error: EOF while reading", source: app://lighttable/core/node_modules/lighttable/bootstrap.js (19199)

Someone – please download the most recent version of LT and try to reproduce this.

Closing as we haven't heard back


No issue.... Just a big BRAVO !!

Dude, just to say, your module is amazing !!
Smart, light, and easy to use.
Congrats ! Sincerely :)

@parkerparker Wow, thanks man! I'm glad you appreciate the module :)
It's always great to get this kind of feedback.


Grim causes crash on latest git

Hyprland Version
 System/Version info

Hyprland, built from branch main at commit ef490965a23e043692584ae26dec4f863c88f2f6 dirty (screencopy: attempt binding framebuffer before gathering format).
Date: Wed Feb 14 16:59:06 2024
Tag: v0.35.0-32-gef490965

flags: (if any)

Bug or Regression?
Bug
Description
When I type grim or attempt to take a screenshot, hyprland crashes.
How to reproduce
Use latest hyprland while using an nvidia gpu and multiple monitors. Run grim. Observe the screen turn black and become unresponsive. Need to kill Hyprland from another tty.
Crash reports, logs, images, videos
log screenshot
I don't have any crash reports from this in ~/.hyprland, so I'm not sure if it's actually crashing (see above; I need to kill from another tty).

you're lying. You aren't on latest git where this has been fixed.


EUI-48 and "MAC"; the fate of macaddress.MAC

Should macaddress.MAC be provided by this library (it currently is)?
If so, should it be

a subclass of macaddress.EUI48 (like it is now),
just another reference to macaddress.EUI48,
some other option? (Feel free to voice any ideal-world or "would be nice" visions, even if you can't think of how to implement them within Python.)

So far, every time I think about this, I eventually come back to:
It should exist, and it should be a subclass of EUI48.
But this is a shaky position in my mind... there are enough compelling reasons for it to tentatively settle on it, but there are enough compelling reasons against it to occasionally jostle me into doubt.

Some prior discussion of this in #3 .

Real-world code which would break on an upgrade to 2.* if MAC was removed:

https://github.com/splunk-soar-connectors/lansweeper/blob/8fea67e018f6cf9919e4c84fdac3c1b336049597/lansweeper_connector.py#L47-L54
https://github.com/amickael/eero-adguard-sync/blob/85323b14197e685bc7049af507dc66f64211ee60/eero_adguard_sync/models/eero/client_device.py#L54-L55

The reasons I can remember for subclassing:

Nicer errors - you call MAC(foo) and get "could not parse as MAC" rather than "could not parse as EUI48".

Some uses of EUI-48 are not as addresses, not for "media access control" - so every MAC address is an EUI-48, but not every EUI-48 is a MAC address. (But this is a purely conceptual distinction - intent or purpose as interpreted or asserted by minds. It is good to express such "business logic" in the type system if it matters.)

Reasons I can remember for having MAC at all:

It is intuitive and discoverable to users. In the world right now, the vast majority of people who would want to work with MAC addresses think in concepts like "MAC address" and maybe "OUI". Of the people I personally know or worked with, I imagine all of them would start by searching for a "MAC address" library, and they would search or skim the description/README/documentation for the keyword "MAC" to see how to actually use the library.

So I think I three verdict is aliasing MAC = EUI48 in version 2.0.0.
Basically I seem to have convinced myself that the reasons for distinguishing MACs as a subset of all EUI-48s out there are not strong enough to accept the likely inevitable consequence of doing so if there are enough users.

In fact I see a more general principle in favor of not providing distinct subclasses for MAC vs EUI-48 in general in this library.
Languages and libraries should generally be in the business of providing functionality, not inflicting non-functional or irrelevant or incidental semantics and taxonomy.
Maybe there's exceptions to that, but I think that's pretty generally true.
Basically, what I'm saying is that the distinction between EUI-48 and MAC is like the distinction between "unsigned integer" and "number of cows": it is relevant in some code and that code should make the distinction as appropriate, but something that provides the former should not impose distinguishing the latter onto its users.


feat: support deprecated

Added support for deprecated methods, props, slots, events and css. Tried with red border but it was a bit too much.

closes #124

Great job! Just a small note, the component itself can also be deprecated.

Thank you bendera! Added deprecated also for components. Here is how it looks:


Add support for getting process memory and cpu usage information

[x] Add option to get memory for each process https://github.com/Microsoft/vscode-windows-process-tree/pull/11
[x] Add option to get CPU usage for each process https://github.com/Microsoft/vscode-windows-process-tree/pull/13
[x] Add option to get command line arguments for each process https://github.com/Microsoft/vscode-windows-process-tree/pull/17

@RMacfarlane @Tyriar I would like to use these features but the npm module is not yet available, correct?
It would be great if you could publish this as soon as possible (so that I can use this in the March release of node-debug).

@weinand master should be on the new v0.2.0 :+1:


Implement SecondaryMap for HashSet and HashMap

Closes #55
The changes are mostly filling the trait impls.
~I had to add the StaticDefault trait because SecondaryMap needs to always be able to return a reference to a default value.~ (Note: Replaced with ConstDefault from the const_default crate).

Moving to a draft while experimenting with more flexible ways to define the default value.

I'm dropping this PR now that we can use petgraph's algorithms on filtered graphs.
It may still be useful to revisit it in the future.


Multiple groups using same tests function

Is it possible to reuse a validation suite multiple times using groups.
The scenario I have is a company details model has 2 different addresses, the validation is the same for each address so rather than duplicating the tests I tried to reuse as below:
import { create, enforce, group, only, test } from 'vest';

export const companyValidationSuite = create(
  'companyValidationSuite',
  (model, field?) => {
    only(field); // if field defined, limit to tests of this field

    test('name', 'Name is required', () => {
      enforce(model.name).isNotEmpty();
    });

    group('billingAddress', () =>
      companyAddressValidations(model.billingAddress!)
    );

    group('officeAddress', () =>
      companyAddressValidations(model.officeAddress!)
    );
  }
);

export const companyAddressValidations = (model: any) => {
  test('line1', 'Line 1 is required', () => {
    enforce(model.line1).isNotEmpty();
  });

  test('city', 'City is required', () => {
    enforce(model.city).isNotEmpty();
  });

  test('postCode', 'Post Code is required', () => {
    enforce(model.postCode).isNotEmpty();
  });
};

If I then execute the suite as below, it only returns errors for the first group a total of 4 errors but there is 7 errors as both address groups have errors, it shows the field name and groupname in the errors array:
    const result = companyValidationSuite({});
    console.log(result);

If I then supply a value for one of the fields in one of the address (as below), the result is the same number of errors (4) but this time there are 2 errors for the billingAddress group and 1 error for the officeAddress group.
    const result = companyValidationSuite({ billingAddress: { line1: 'test' }});
    console.log(result);

I wouldn't make it behave differently just for groups by default as it would break the principle of least astonishment.
Two alternatives I can see:

We can possibly make the mode function work within a scope, similar to the 'skip' function. That would not solve your case specifically as these would be two different groups. To combat that, nothing stopping us from putting both named groups in one parent unnamed group.

We could make a new execution mode that would provide this behavior. Need to think what its full specification could be.


Bower

Hi, it's possible to post a compatible version for bower and no for nodeJS only ?
I use requireJS AMD system and your script return an error :
Uncaught Error: Module name "inherits" has not been loaded yet for context: _. Use require([])
Uncaught ReferenceError: module is not defined

I'm not a bower user, but I will accept a pull request fixing it.
Ref #1


⚠ ClamAV has degraded performance

In 839ba0c, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 100 ms

Resolved: ClamAV performance has improved in 6051397.


daemon: remove all the package installations

Packages installation should only happen in the base image.
Signed-off-by: Sébastien Han<EMAIL_ADDRESS>

Somehow Travis just started to complain about ARG in the Dockerfile. I don't think my change is rising the issue... Investigating.


[Help] npm create electron-vite behave weird

Describe the problem you confuse
The created vite.config.ts is not same as docs
For example:
the main process entry file, my vite.config.ts file finds it at 'electron/main.ts', but your docs says it should locate at 'electron/main/index.ts'
❯ npm create electron-vite
✔ Project name: … test
✔ Project template: › Vue

Scaffolding project in /Users/wangzhipeng/Desktop/Code/test...

Done. Now run:

  cd test
  npm install
  npm run dev

# vite.config.ts

import { defineConfig } from 'vite'
import electron from 'vite-plugin-electron'
import renderer from 'vite-plugin-electron-renderer'
import vue from '@vitejs/plugin-vue'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    electron([
      {
        // Main-Process entry file of the Electron App.
        entry: 'electron/main.ts',
      },
      {
        entry: 'electron/preload.ts',
        onstart(options) {
          // Notify the Renderer-Process to reload the page when the Preload-Scripts build is complete,
          // instead of restarting the entire Electron App.
          options.reload()
        },
      },
    ]),
    renderer(),
  ],
})

test/
├── README.md
├── electron
│   ├── electron-env.d.ts
│   ├── main.ts
│   └── preload.ts
├── electron-builder.json5
├── index.html
├── package.json
├── public
│   ├── electron-vite.animate.svg
│   ├── electron-vite.svg
│   └── vite.svg
├── src
│   ├── App.vue
│   ├── assets
│   │   └── vue.svg
│   ├── components
│   │   └── HelloWorld.vue
│   ├── main.ts
│   ├── style.css
│   └── vite-env.d.ts
├── tsconfig.json
├── tsconfig.node.json
└── vite.config.ts

You can submit a PR for fix it!

I am new to frontend developing, so I am not sure it's bug or not.  So It's a bug?

create electron-vite just provide a boilerplate, but it not limit waht entry path of a project.
You event use others likes electron/foo.ts, electron/bar/index.ts.

create electron-vite just provide a boilerplate, but it not limit waht entry path of a project. You even use other path, likes electron/foo.ts, electron/bar/index.ts.

Yeah, I know there is no limit on entry path. Actually, I mean the project created by command npm create electron-vite is not same as main branch of this repo.
For example
The tsconfig.node.json file in this repo is something like following
{
  "compilerOptions": {
    ...
  },
  "include": ["vite.config.ts", "package.json", "electron"]
}

But the actual tsconfig.node.json in project created by npm create electron-vite like following:
{
  "compilerOptions": {
    ...
  },
  "include": ["vite.config.ts"]
}

So what I mean is that it is clearly stated on the document that we can use 'npm create electron-vite' to create boilerplate , but the final creation is different from this repo. I wonder if this is a bug or something I made mistaken


Fix granularity problem in getHistoricalDateRange()

Fix granularity problem in getHistoricalDateRange()
Use granularity instead of self.getGranularity()  in getHistoricalDateRange() call
Fixes # (issue)
Type of change
Please make your selection.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] This change requires a new dependency
[ ] Code Maintainability / comments
[ ] Code Refactoring / future-proofing

How Has This Been Tested?
Works well on my PC
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added pytest unit tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have checked my code and corrected any misspellings

Looks good, thanks. I'll update the CHANGELOG.md for you.


MM Eval tests

Context
What is the purpose of this PR? Is it to

[ ] add a new feature
[ ] fix a bug
[x] update tests and/or documentation
[ ] other (please add here)

Please link to any issues this PR addresses.
Adds some tests for the eval recipe using dummy Llama3.2 Vision models.
Test plan
Please make sure to do each of the following if applicable to your PR. If you're unsure about any one of these just ask and we will happily help. We also have a contributing page for some guidance on contributing.

[ ] run pre-commit hooks and linters (make sure you've first installed via pre-commit install)
[ ] add unit tests for any new functionality
[ ] update docstrings for any new or updated methods or classes
[ ] run unit tests via pytest tests
[ ] run recipe tests via pytest tests -m integration_test
[ ] manually run any new or modified recipes with sufficient proof of correctness
[ ] include relevant commands and any other artifacts in this summary (pastes of loss curves, eval results, etc.)

UX
If your function changed a public API, please add a dummy example of what the user experience will look like when calling it.
Here is a docstring example
and a tutorial example

[ ] I did not change any public API
[ ] I have added an example to docs or docstrings

holy moly
 ============================= slowest 20 durations =============================
376.79s call     tests/recipes/test_eleuther_eval.py::TestEleutherEval::test_meta_eval_vision
342.01s call     tests/recipes/test_eleuther_eval.py::TestEleutherEval::test_hf_eval_vision

I fix

Codecov Report
Attention: Patch coverage is 32.30769% with 44 lines in your changes missing coverage. Please review.

Project coverage is 24.78%. Comparing base (9eced21) to head (ed3f02e).
Report is 19 commits behind head on main.

Files with missing lines
Patch %
Lines

tests/recipes/test_eleuther_eval.py
35.29%
33 Missing :warning:

tests/recipes/utils.py
21.42%
11 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1887       +/-   ##
===========================================
- Coverage   68.40%   24.78%   -43.62%
===========================================
  Files         311      318        +7
  Lines       16973    17649      +676
===========================================
- Hits        11610     4375     -7235
- Misses       5363    13274     +7911

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Missing avatar / broken url link after re-installation

Description
I have no idea what I did wrong, or how to work around this. ./gitea doctor shows all working paths OK.

app.ini
[1] Check paths and basic configuration

[I] Configuration File Path:    "/home/khan/gitea/custom/conf/app.ini"
[I] Repository Root Path:       "/home/khan/Documents/gitea-repositories"
[I] Data Root Path:             "/home/khan/gitea/data"
[I] Custom File Root Path:      "/home/khan/gitea/custom"
[I] Work directory:             "/home/khan/gitea"
[I] Log Root Path:              "/home/khan/gitea/log"

2024/05/25 13:46:24 ...s/graceful/server.go:50:NewServer() [I] Starting new Web server: tcp:<IP_ADDRESS>:3000 on PID: 16158
2024/05/25 13:47:18 ...eb/routing/logger.go:102:func1() [I] router: completed GET /khanumballz for <IP_ADDRESS>:58920, 200 OK in 20.4ms @ user/home.go:713(user.UsernameSubRoute)
2024/05/25 13:47:18 routers/web/base.go:80:func2() [W] Unable to find avatars d94438e78ed6e2a09b4d25eb9a20587e
2024/05/25 13:47:18 ...eb/routing/logger.go:102:func1() [I] router: completed GET /avatars/d94438e78ed6e2a09b4d25eb9a20587e?size=512 for <IP_ADDRESS>:58920, 404 Not Found in 0.1ms @ web/base.go:22(avatars)
2024/05/25 13:47:25 routers/web/base.go:80:func2() [W] Unable to find avatars d94438e78ed6e2a09b4d25eb9a20587e
2024/05/25 13:47:25 ...eb/routing/logger.go:102:func1() [I] router: completed GET /avatars/d94438e78ed6e2a09b4d25eb9a20587e?size=512 for <IP_ADDRESS>:58920, 404 Not Found in 0.2ms @ web/base.go:22(avatars)
2024/05/25 13:47:25 ...eb/routing/logger.go:102:func1() [I] router: completed GET /favicon.ico for <IP_ADDRESS>:58920, 301 Moved Permanently in 0.2ms @ misc/misc.go:46(web.Routes.StaticRedirect)
Gitea Version
Gitea version: 1.23.0+dev-125-gec771fdfcd built with GNU Make 4.3, go1.22.3 : bindata, sqlite, sqlite_unlock_notify
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Built from source Arm64
Database
SQLite

How did you re-install?

I appear to have the same issue after upgrading to 1.22.0 from 1.21.7.  data/avatar directory is empty and attempting to force the download does not appear to do anything.  Gitea is configured with default Gravatar source.

Some logs:
2024/05/29 16:22:21 routers/web/base.go:80:func2() [W] Unable to find avatars 9e61922cdffba0bcee9a3c5552ba7513
2024/05/29 16:22:21 routers/web/base.go:80:func2() [W] Unable to find avatars 9e61922cdffba0bcee9a3c5552ba7513
2024/05/29 16:22:21 ...eb/routing/logger.go:102:func1() [I] router: completed GET /avatars/9e61922cdffba0bcee9a3c5552ba7513?size=512 for [REMOVED]:0, 404 Not Found in 0.1ms @ web/base.go:22(avatars)
2024/05/29 16:22:21 ...eb/routing/logger.go:102:func1() [I] router: completed GET /avatars/9e61922cdffba0bcee9a3c5552ba7513?size=48 for [REMOVED:0, 404 Not Found in 0.2ms @ web/base.go:22(avatars)

Is it a custom avatar? or a generated avatar?

Both identicons and custom gravatar avatars aren't working.  Manually uploading a gif|jpg|png to my profile appears to work fine.

So you are using gravatar avatars, but it seems that all avatar URLs are accessing Gitea instance not gravatar server.
IIRC, the following settings will be cached in DB, maybe on/off it can update the settings. Not sure whether this will work.

Toggling it by itself didn't appear to actually help.  I managed to get my identicon to show up by doing the following:

Disable Gravatar in settings.
Go into my user profile settings
Noticed the "delete current avatar" button is enabled even though technically I don't have one.
Pressed "delete current avatar" and immediately my identicon avatar displayed as expected.
Re-enabled Gravatar in settings.

Actual Gravatar's don't appear to show up though.  I switched to another user that does have a custom Gravatar associated with the profile email address and Gitea displays an identicon instead of the avatar.

As @lunny asked above, we don't know how you reinstalled your Gitea instance, so it is hard to say this is a bug from Gitea.
Maybe reset the avatar email can be helpful?

Hi again.
The problem isn't the custom uploaded avatars, but the generic ones that get automatically generated.
I still haven't found the issue, because the avatar folder is empty by default, so it seems to be some kind of vector graphics code written somewhere in the js I suppose.

This is also broken for me immediately following upgrade to 1.22.0 -- gravatar no longer works. I didn't have any custom avatars, only gravatar. The disable slider is off (it was on following the upgrade), but it still doesn't work.
I am also being asked to reset my password after authenticating with my oidc provider, so there seems to be some account functionality broken after the upgrade though I doubt it's related.
Installed via helm chart gitea-10.2.0.

Per the 1.22 release notes, server.OFFLINE_MODE is now set to true by default. This seems to break gravatar functionality even if the disable slider is off. Setting server.OFFLINE_MODE=false in my k8s secret and rollout restarting the deployment restored gravatar functionaly for me.

Same here.  As soon as I changed the setting to false and restarted gitea my actually gravatar immediately appeared in place of the identicon.

This bit me too. I'm using the gitea/gitea container, and all our avatars were broken by the 1.22 update. We'd had nothing but the auto generated geometric patterns, so I went through and used the 'Delete Avatar' button on all the accounts to fix things.

I can image two cases which can cause this issue:

maybe from far before, there's some thing happened which made user.avatar != empty, even user is using gravatar avatar. Then after forcing offline mode, user.avatar is not exist in local, so the avatar is broken.
unexpected data deletion

But as many reports above are updating, so the first case is the most possible case I think.

For context I can add that my installation has been through various stages. It started out as gogs, running on a VM. It was upgraded in place to gitea. More recently it was converted to a container. The latest update was from container version 1.21.11 to container version 1.22.
I guess the gravatar setting might contribute - I never had it disabled - but as far as I could tell it wasn't contributing anything.

We close issues that need feedback from the author if there were no new comments for a month. :tea:


Add ToolsDB credentials

This will let Quarry run queries against the ToolsDB replica host.
Bug: T348407

The conf keys should be TOOLS_DB_* instead of TOOLSDB_*, to match the ones in default-config.yaml.
Otherwise, LGTM. Thanks!

Good catch, thanks. I also removed TOOLS_DB_HOST from the encrypted file and modified the hostname directly in default-config.yaml.


Keep track of scales practiced

Thank you for your neat work!
I am just having this idea of counting the number of times a scale/arpeggio has been practiced. I don't have much experience in React Native but can certainly take a look when I have more free time :)

@siwei-li Thanks for the idea! I think that would be a helpful feature, and something I might work on when I have the time in the next couple days. If you were interested, and would rather give it a try, I would be happy to accept a Pull Request!

This has been included in the latest release (v2.8.0) sent for review to the Google, Amazon, and Apple App Stores today!


A property and its inverse are defined in different ontologies

basedOn is defined in gistTop but its inverse (basisFor) is defined in gistIntention. Do we really want to separate a property and is inverse?

Dependent on decision on #292. Let's put on hold till then.

Closed as part of #292, demodularize gist. No longer applicable.


Service catalog: binding is not correctly created

Sometimes test common.catalog.ServiceCatalogWebTest#testSendMessageUsingBindingCert does not work because I cannot open console web page using created binding.
{"log":"\u001b[0m\u001b[33m10:40:02,250 WARN  [org.keycloak.events] (default task-29) type=LOGIN_ERROR, realmId=db5ea194-1e1f-4b32-83f3-0ab26ad0a7ad, clientId=enmasse-console, userId=68c37955-15f0-4162-871e-80481c628554, ipAddress=<IP_ADDRESS>, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=https://console-enmasse-master-562-test-cert-space.<IP_ADDRESS>.nip.io/?auth_callback=1, code_id=df857498-b595-4e70-aaef-3ac8c47df008, username=user-8dc31130-ace1-4cbe-a12d-e5fbf8e7c150\n","stream":"stdout","time":"2018-06-27T10:40:02.251900278Z"}

https://github.com/EnMasseProject/enmasse/pull/1407

@kornys with #1407, is this issue able to be closed or no ? ( just asking )

Fixed by moving to user api


Investigate Best Resume Ever project.

https://github.com/salomonelli/best-resume-ever looks interesting, perhaps as inspiration, and perhaps as a basis for getting started.

Thanks @humphd . This seems very similar to what we are going to do.

Let me do some research on this and see what I can find


Pagination: onClick don't work for ellipsisItem

Feature Request
Problem description
Pagination.Item type="ellipsisItem"s do not support the onClick handler.  This prevents me from easily using the ellipsis button as a "jump several pages" button.  An onClick handler can be attached to the content of the Pagination.Item, but this requires CSS overrides to have the entire button be clickable.
Proposed solutions

Pagination.Items fire their onClick handlers even if they are ellipsisItems.
Upsides: Maximum consistency and simplicity - onClick simply works as normal on everything inside a Pagination.
Downsides: This is a breaking change, in that anyone depending on the previous behavior (for instance, using a common props shorthand for custom ellipsisItem and  next/prevItem) will have to go change their code to not supply that handler for ellipsisItems.
Pagination.Items offer a second onEllipsisClick prop that is onClick for ellipsisItems only.
Upsides: Maintains backwards compatibility, nobody has to change any code.
Downsides: Less consistent, requires you to look at the docs to understand how to handle a click on an ellipsisItem.

MVP
For solution 1, replace handleClick in addons/Pagination/PaginationItem.js with this code:
handleClick = (e) => {
  _.invoke(this.props, 'onClick', e, this.props)
}

For solution 2, replace it with this code:
handleClick = (e) => {
  const { type } = this.props
  if (type === "ellipsisItem") {
    _.invoke(this.props, 'onEllipsisClick', e, this.props)
  } else {
    _.invoke(this.props, 'onClick', e, this.props)
  }
}

...update the propTypes to this:
static propTypes = {
  /** A pagination item can be active. */
  active: PropTypes.bool,

  /** A pagination item can be disabled. */
  disabled: PropTypes.bool,

  /**
   * Called on click for non-ellipsisItem items.
   *
   * @param {SyntheticEvent} event - React's original SyntheticEvent.
   * @param {object} data - All props.
   */
  onClick: PropTypes.func,

  /**
   * Called on on click if the type is "ellipsisItem".
   *
   * @param {SyntheticEvent} event - React's original SyntheticEvent.
   * @param {object} data - All props.
   */
  onEllipsisClick: PropTypes.func,

  /**
   * Called on key down.
   *
   * @param {SyntheticEvent} event - React's original SyntheticEvent.
   * @param {object} data - All props.
   */
  onKeyDown: PropTypes.func,

  /** A pagination should have a type. */
  type: PropTypes.oneOf([
    'ellipsisItem',
    'firstItem',
    'prevItem',
    'pageItem',
    'nextItem',
    'lastItem',
  ]),
}

...and replicate that new proptype into the type definition for PaginationItem.
I'll open a PR for whichever of these solutions the maintainers prefer, if they agree this is a worthwhile change :smile:

Actually, it's a design issue, the check for type === "ellipsisItem" should be placed inside Pagination component.
<Pagination
  defaultActivePage={5}
  ellipsisItem={{
    content: '...',
    onClick: () => console.log('ellipsisItem click'),
  }}
  totalPages={10}
/>

In this case you will be able to pass your own handler. PR is coming.


About Unifont.pkl

Thanks again for this great work.
I am very curious how unifont does its coding work.
Can unifont.pkl be customized?
Looking forward to your reply!

me too


Fix incorrect condition for send led status

uPendingLedCode initial value is 0xFF, which means invalid code, and uShortPendingLedValue initial value is 0.
Using "uShortPendingLedValue != 0xFF" as condition to send kbd led status, it will send invalid code 0xFF and value 0 to backend.

I have squashed the two commits and pushed it to master as https://github.com/virtio-win/kvm-guest-drivers-windows/commit/a582ed09aa29138f6bd85028b7f4ff0865c0bf26
Thanks!


change model folder

I suggest to use /res/ for splash and icon base images (like ionic cli)

Just set the imagespath argument like this:
$ splashicon-generator --ip='res' # also aliased as --imagespath='res'


R_GE_version is 16 on R >= 4.3

c.f. https://github.com/wch/r-source/blob/452e9b5ab5973af6e271b70dcad1505451acdd93/src/include/R_ext/GraphicsEngine.h#L88-L91
This makes the CI with R-devel failing.

This line needs to be updated.
https://github.com/extendr/libR-sys/blob/7f6701ca3f58e396179bba02f7429f95fbd34d5e/bindings/bindings-windows-x86_64-R4.3-devel.rs#L60


📃: Alarm Program

:red_circle: Title : Alarm Program
:red_circle: Aim : Create a alarm application to notify user on the ping or set up time.
:red_circle: Brief Explanation :

Take time inputs
take any message to flash on times up.
store any link or note
create a interactive user interface

Screenshots 📷

N/A

:white_check_mark: To be Mentioned while taking the issue :

Full name :
What is your participant role? (Mention the Open Source Program name. Eg. GSSOC, SSOC, JWOC, etc.)

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

Hello, I want to contribute to this under SSOC.
Thanks.

@Avdhesh-Varshney I'm Parshvi Jain, participating in SSOC and I’d like to add alarm functionality to the project. I'll create a new file alarm_app.py  in simple programs for this feature, including user input for setting alarms and notifications.

@parshvi1508 go ahead.


Allow adding TextInput Label styling

Use Case

I have a client design requirement to have labels like this inside the the TextInput.

please add this feature and mention the usage example yaml as well.

CC: @vinothvino42

@vusters PR - #868

@sibteali786 You can achieve it something like below once the PR got merged.
TextInput:
  id: emailId
  onDelayedKeyDuration: 0
  onDelayedKeyPress: |
    //@code
    emailId.value = emailId.value;
  styles:
    {
      enabled: true,
      labelText: '${emailId.value.length == 0 ? "" : "Name"}',
      hintText: Enter your name,
      enabledBorderColor: grey,
      focusedBorderColor: blue,
    }

@vusters @sibteali786  New PR - https://github.com/EnsembleUI/ensemble/pull/888
TextInput:
  id: emailId
  styles:
    {
      label: Email,
      floatLabel: true,
      variant: box,
      floatingLabelStyle:
        { fontWeight: semibold, fontSize: 34, color: green },
      hintText: Enter your email,
      focusedBorderColor: green,
      enabledBorderColor: gray,
    }


Expose fetch_and_sort_papers() parameters in literature_review()

I think it would be great to be able to configure the following in the literature_review() function:

keyword combinations
year_range
top_n papers

feel free to assign to me @eimenhmdt , though I'm sure you can handle that... :P

Thanks for the suggestions! What do you mean by keyword combinations?
Regarding the top_n papers, we need to be cautious to not create a context that's too large due to token limitations of GPT 3.5. What are your thoughts on this?

I was thinking that if users wanted to, they could pass their own keyword_combinations which would be passed to semanticScholar, avoiding the first call to the openAI API :)
Thats true! have you any idea what that context would look like atm in terms of number of papers?  We would probably want a limit anyway so a user doesn't accidentally choose 1000 top papers or something and burn through their tokens.

re keywords: I think that's a good idea. Many researchers probably already know very well which keyword combinations they would want to use. If you want, it would be really cool if you could build this. :)
re context: Depends on the model you use. Currently, AutoResearcher uses GPT-3.5 turbo by default. But, it's also possible to use GPT-4. I think if we want to extract useful & sufficient information from each paper, 20–25 papers (GPT-4 2x this number) should be max in the context. But, I could also think of a refined algorithm that circumvents these limitations, i.e. adding additional steps, using a vector store etc.

Interesting!
Sure - got my PhD viva in a few days though but will tackle after that.

Oh, cool. Best of luck for your viva!!


Checks status hub pr list

Fixes #2193

Add check status for pull requests list on the command of hub pr list
Add query.go for constructing the particular GraphQL query using graphb.
Screenshot attached below.

I am so sorry beforehand if I got the design wrong in any way. Looking forward to the review! :slightly_smiling_face:

Hi @mislav , truly sorry for a really late reply :disappointed: .
First of all, I just want to say that I am blown away and thank you very much for the really kind reply :slightly_smiling_face: .
Yeah, I noticed it before that there are 2 ways of getting status which the first is Status and the second is Check, which is represented in the GraphQL query that you mentioned in the issue before, right? Thus if it's okay with you, I have several questions on this.

Wouldn't all GitHub repositories with CI installed will always have Status value but not always have Checks status value from GitHub Apps installed? and,
I thought that if there are GitHub apps installed and it would return Checks value, the value of the Checks will always be the same and reflected by the Status value? So that it's sufficient to retrieve the Status value only.
And if we are going to retrieve both of the two values from Status and also Checks, which value are we going to use? In case it would return different value.

I am really sorry beforehand if it's because I have a wrong understanding on this Status and Checks. I will reply on the remaining reviews below. Looking forward to your reply and hope you have a great week ahead! :slightly_smiling_face:

I am really sorry beforehand if it's because I have a wrong understanding on this Status and Checks.

No need to apologize, this stuff isn't really easy, and our documentation doesn't explain the differences between Statuses and Checks very well. Our GraphQL documentation for Checks is also lacking since that API is in preview phase.
This is what it all comes down to:

Statuses were the original CI for GitHub
Checks are the new generation of Statuses and come from GitHub Apps
A repository can be configured with any combination of Checks and Statuses
Checks right now are complex to fetch over GraphQL.

For the simplicity of this PR, I would like you to focus on Statuses only, and I can then add Checks support as follow-up. 🙇

@joshuabezaleel For an example of how to perform GraphQL queries in hub, here is a PR that adds some simple queries in a way that doesn't require an external library https://github.com/github/hub/pull/2363

I have pushed some changes, mainly to:

compose GraphQL requests directly without the graphb library - this utilizes the Client.GraphQL function that is new in master
restore default --format to original - I feel like this feature is still premature to be enabled by default
avoid fetching statuses via GraphQL unless %cs/%cC were explicitly specified via --format
support --limit values > 100

@joshuabezaleel Please review! 🙇
I'm still not sure whether this feature is ready to merge, though:

It only fetches Statuses so far and not Checks (to reiterate: I will take on implementing Checks when I find time, so you don't have to worry about that);
It fetches pull requests double: once over REST (like before) and another time over GraphQL (to fetch Statuses). Ideally it would only fetch them once, so maybe we could switch to GraphQL entirely for the case when Statuses are needed.
--sort long-running is supported over REST API but not over GraphQL.

Will be this continued, since now the most attention will go to the CLI instead?

Are there any updates regarding this PR? It needs to be rebased.

@XVilka @joshuabezaleel The GitHub API in the meantime had some updates to make querying Checks + Statuses easier! I plan to update this PR incorporating those changes when I find time.

@dawsbot I haven't worked on it since my last comment, but since then there is a new GraphQL statusCheckRollup API that combines information about both Checks and Statuses and their resolution, so there's less work on the client to assemble this data. I plan to adopt it in this PR when I find time. Or, in the meantime, anyone is welcome to base their work off of my branch! 🙇

Comment on PR with title : Checks status hub pr list


(SP: 3) Implement loading and validation of the file on Add photo step

UserStory: #65 , #64
Blocked by: #163 , #164
Description
Implement loading and validation of the file on Add photo step
Design

Acceptance Criteria

[x] When file is loaded it should send file to server
[x] When file is not .png, .jpg or .jpeg it should validate and throw an error

[x] When file is not .png, .jpg or .jpeg it should validate and throw an error -> It was resolved in Issue #163 and implemented PR #177