heasoftpy installation error

I have successfully installed and initialized HEAsoft, and now I try to install heasoftpy in a Python environment,
I created the virtual environment using conda and then installed the dependencies in that environment, and used python setup.py build to get an error
/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/installer.py:27: SetuptoolsDeprecationWarning: setuptools.installer is deprecated. Requirements should be satisfied by a PEP 517 installer.
 warnings.warn(
running build
running build_py
2022-06-26 12:04:12 -  INFO - ------------------------------------------------------------
------------------------------------------------------------
2022-06-26 12:04:12 -  INFO - Starting heasoftpy installation ...
Starting heasoftpy installation ...
2022-06-26 12:04:12 -  INFO - ------------------------------
------------------------------
2022-06-26 12:04:12 -  INFO - Creating python wrappers ...
Creating python wrappers ...
2022-06-26 12:04:12 -  INFO - Installying python wrappers. There are 747 tasks!
Installying python wrappers. There are 747 tasks!
2022-06-26 12:04:12 -  INFO - .. 1/747 install uvottfc ...
.. 1/747 install uvottfc ...
2022-06-26 12:04:12 - ERROR - Failed in generating python wrappers
Failed in generating python wrappers
Traceback (most recent call last):
  File "setup.py", line 79, in <module>
    setup(
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/__init__.py", line 87, in setup
    return distutils.core.setup(**attrs)
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/_distutils/core.py", line 148, in setup
    return run_commands(dist)
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/_distutils/core.py", line 163, in run_commands
    dist.run_commands()
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 967, in run_commands
    self.run_command(cmd)
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/dist.py", line 1214, in run_command
    super().run_command(command)
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 986, in run_command
    cmd_obj.run()
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/_distutils/command/build.py", line 135, in run
    self.run_command(cmd_name)
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/_distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/dist.py", line 1214, in run_command
    super().run_command(command)
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 986, in run_command
    cmd_obj.run()
  File "setup.py", line 19, in run
    hspinstall._do_install()
  File "/home/jason/HEAsoft-6.30/heasoftpy/install.py", line 248, in _do_install
    _create_py_wrappers()
  File "/home/jason/HEAsoft-6.30/heasoftpy/install.py", line 67, in _create_py_wrappers
    generate_py_code()
  File "/home/jason/HEAsoft-6.30/heasoftpy/heasoftpy/utils.py", line 91, in generate_py_code
    hsp = HSPTask(task_name)
  File "/home/jason/HEAsoft-6.30/heasoftpy/heasoftpy/core.py", line 49, in __init__
    pfile  = HSPTask.find_pfile(name)
  File "/home/jason/HEAsoft-6.30/heasoftpy/heasoftpy/core.py", line 525, in find_pfile
    pfiles = re.split(';|:', os.environ['PFILES'])
  File "/home/jason/miniconda3/envs/heasoft/lib/python3.8/os.py", line 675, in __getitem__
    raise KeyError(key) from None
KeyError: 'PFILES'```

Yes, I initialized it @zoghbi-a
I can use xspec,I want to use the python interface of heasofpy. Heasofpy is used in notebook, but I haven't configured it yet. The system I use is windows subsystem for Linux. I hope these messages I give will help you solve this complete problem. Thank you!

what do you get when doing echo $PFILES in the same terminal that runs xspec?

That is strange. The error occurs because the PFILES is not defined as an environment variable. One thing I can suggest, is to make sure the install script is run from the same terminal window where you did the echo $PFILES command. Does that give the same error?

Do you need to initialize heasoft first when the terminal executes echo $PFILES? I list the results after the terminal executes initialization and uninitialization respectively
uninitialized:

initialization:

Xspec terminal after initialization:

I hope this information can help you solve this problem. Thank you very much!

Thank you. Can you print back what you get by doing the following on the terminal (outside xspec). Please run in the folder that contains the setup.py of heasoftpy.
echo $PFILES
python setup.py build

Hello!
I have setup.py in heasoftpy. When I use python setup.py build, the following error is reported
In this [err.txt] file (https://github.com/HEASARC/heasoftpy/files/9151907/err.txt)

@zoghbi-a I used conda to create a virtual environment and successfully installed the heasoftpy module in this environment. Thank you very much for your help !


fix(functions): Allow both partial and full resource names to enqueue tasks in emulator

The docstring for getFunctions.taskQueue() advertises that task queues can be referenced by both fully and partially qualified resource names, but a user reported that fully qualified resource names was not working. This PR updates the resource resolution logic to properly resolve to the corresponding task queue in the new Cloud Tasks emulator.
Fixes https://github.com/firebase/firebase-admin-node/issues/2725.

LGTM!
Question: does this issue only apply to the emulator url?

Yes, it should only apply to the new Cloud Tasks emulator!


feat: implement 0x9A - SWAP11 Opcode

Kakarot v0 implementation: https://github.com/kkrt-labs/kakarot/blob/main/src/kakarot/instructions/exchange_operations.cairo
Kakarot v0 tests: https://github.com/kkrt-labs/kakarot/blob/44dabfcab05a87f85bcfe0a457809059d11d83fb/tests/src/kakarot/instructions/test_exchange_operations.cairo#L107
EELS Implementation: https://github.com/ethereum/execution-specs/blob/fade6e95726c9c0b47b779fd8873b5737fbea3b3/src/ethereum/paris/vm/instructions/stack.py#L108
SinceGroupFrontierExchange OperationsIndex 1 is top of the stack. See PUSH.Stack inputa: value to swap.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.b: value to swap.Stack outputb: swapped value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.ignored value.a: swapped value.ExampleInputOutput112200300400500600700800900100011001221Reproduce in playground.Error casesThe state changes done by the current context are reverted in those cases:Not enough gas.Not enough values on the stack.

Important update: we are gathering some bugs in the Kakarot v0 codebase, we need to make sure each issue and each PR in Kakarot-ssj is aware of the lists of known bugs. Look at this link everytime you take an issue and check your issue isn't targeted by a known bug.

Important update: we are gathering some bugs in the Kakarot v0 codebase, we need to make sure each issue and each PR in Kakarot-ssj is aware of the lists of known bugs. Look at this tracking issue everytime you take an issue and check your issue isn't targeted by a known bug.


Suggest a GCC/LLVM compatible compile option for RVV auto-vectorization

Is it possible that we can have a GCC/LLVM compatible compile option to specifiy LMUL in auto-vectorization?
For example, -mriscv-vector-lmul or -mrvv-vector-lmul ?
Thanks.

@kito-cheng Can you help me with that ?

LLVM has an option to specify that -mllvm -riscv-v-register-bit-width-lmul=N, but I guess we need to figure out and define the semantic for the option, especially for the loop contains more than one element width, e.g. one loop contain with i64 and i32, so which LMUL should be used for i64 and i32 IF we specify the  -mrvv-vector-lmul=m2? i32 use m2, i64 use m4 or i32 use m1, i64 use m2?
We'll need to clarify those case if we want to define a common option.

Tag some LLVM developer here to get some feedback about this idea: @topperc @asb @rofirrim @preames
@zhongjuzhe is the major contributor of the vector support for RISC-V GCC, including intrinsic and vectorizer, he already finish first version of auto vectorization on their downstream GCC, and we are planing to support vectorizer on GCC trunk in the second half of 2023,

I, strongly, think we're too early in having this discussion.  If you have specific examples where you think the default code generation is sub-optimal, please file bugs.  Only once we've implemented reasonable code quality in both compilers does it start making sense to provide compatible forcing options.
Also, any option prefixed with -mllvm is explicitly internal, and is not stable.  Use at your own risk, you will get no support if that breaks.

I'm guessing we can restart this conversation. cfr: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112651
TL/DR: in gcc we currently use --param to convey lmul, but that is more of a hint to the optimizer and not really a mandate for it. For latter the preferred way is to use a -mXX toggle.


Add cURL request method

This implements a version of RequestMethod utilizing cURL (intended for those servers that don't allow use of fsockopen—or even file_get_contents—to communicate with remote servers). Completes #38.
This is sort of a WIP, as I will need a bit of guidance in writing the appropriate tests for this, and possibly some changes to my code style to fit better with the rest of the project.
Thanks!

Good stuff, thanks!

A little late, but I signed it! :)

Ha! Well spotted and thank you for catching that!


Add Ionic to the list of supported frameworks in Angular

Adds Ionic to the list of frameworks Apollo works great with (in Angular apps)

Thanks!


.msi Installer fails to provide libbpf includes

Describe the bug
libbpf includes were provided by the 0.5.0 .msi installer, inside include/libbpf.
However, on building the latest commit of the ebpf-for-windows repo and using the installer from x64/Debug/ebpf-for-windows.msi, the include folder from the newer installer does not have a libbpf folder. Hence, compiling an eBPF program with the newer include folder fails due to the compiler not finding libbpf/src/bpf_helpers.h included in include bpf_helpers.h
OS information
Windows 11
Steps taken to reproduce bug

Build this repo.
Use the new installer at x64/Debug/ebpf-for-windows.msi to install eBPF development files.
Missing libbpf includes inside the include folder.

Expected behavior
libbpf includes should be placed by the installer in the include folder.
Actual outcome
The libbpf includes were missing from the include directory.
Additional details
No response

Please reopen this issue. The entirety of the root/include/libbpf folder was missing. This folder is supposed to have root/include/libbpf/src and root/include/libbpf/include folders.
This is how it was in the 0.5.0 release.
The above commit puts the contents of the root/include/libbpf/include folder inside root/include/libbpf.
As such, files like libbpf/src/bpf_helpers.h mentioned in the first post of this issue are still missing in the 0.6.0 release and userspace programs which have #include <bpf/libpf.h> will fail to build.

@H0mTanks, please note the linked PR is not released in 0.6.0, it should be pulled from the build artifacts for the moment.

RE: missing root/include/ebpf_base.h: I see it is not included in 0.5.0 as well, will eventually add it in an additional PR.
RE: missing root/include/libbpf directory tree: the 0.5.0 directory structure should match what the PR has fixed. Can you please confirm you are using the latest MSI?

Directory structure for v0.5.0:

Directory structure of the latest MSI output (i.e. from the build artifact in main):

Okay, this is curious. You're correct that the 0.5.0 .msi release has the same directory structure.
However, my understanding that the 0.5.0 release provided a different directory structure was because I found this eBPF-for-Windows.0.5.0 folder on my filesystem.
As you can see the src folder is present inside root/libbpf/include.

My bad about 0.5.0 release .msi, but I don't quite remember how I got the above folder. Maybe it wasn't from an .msi installation.
Regardless, if you examine bpf_helpers.h in the root/include directory. You'll see:
// If we're compiling an actual eBPF program, then include
// libbpf's bpf_helpers.h for the rest of the platform-agnostic
// defines.
#ifndef _MSC_VER
#include "libbpf/src/bpf_helpers.h" <-----------------------------
#define bpf_map_def _ebpf_map_definition_in_file
#include "ebpf_nethooks.h"
#endif

Therefore, I believe the src folder being in the root/include/libbpf folder is the correct project structure.

Without these files, userspace applications just won't compile because the header files in root/include seem to be expecting them.
Some random further info if it helps: The 0.5.0 folder in my filesystem that I showed above seemed to be created last month at 09/01/2023.

@H0mTanks Thanks for the clarification.
The MSI was rebuilt from its ashes, and yes it should provide the same files that nuget provides, although, the nuget packager currently just xcopy-s with wildcards from directories, and btw on the other end it looks like it's missing other files and uses inconsistent directories:
  <files>
    <file src="Convert-BpfToNative.ps1"                       target="build\native\bin"                    />
    <file src="bpf2c.exe"                                     target="build\native\bin"                    />
    <file src="export_program_info.exe"                       target="build\native\bin"                    />
    <file src="ebpfapi.dll"                                   target="build\native\bin"                    />
    <file src="ebpfapi.lib"                                   target="build\native\lib"                    />
    <file src="..\..\include\**\*.*"                          target="build\native\include"                />
    <file src="..\..\external\bpftool\libbpf\include\**\*.*"  target="build\native\include\libbpf\include" />
    <file src="..\..\external\bpftool\libbpf\src\**\*.h"      target="build\native\include\libbpf\src"     />
    <file src="..\..\external\ebpf-verifier\src\ebpf_base.h"  target="build\native\include"                />
    <file src="..\..\tools\nuget\README.md"                   target="."                                   />
    <file src="..\..\tools\nuget\ebpf-for-windows.props"      target="build\native"                        />
  </files

RE: I'm quite unsure at this point what the correct structure is supposed to be: just to lay out the rationals, the MSI by design tracks each file/action as an individual component, and therefore implements transactional, repeatable and deterministic releases, whereas nuget packaging - done as currently done through wildcards - is not a best practice for release purposes, in order to achieve precise tracking of what is being shipped... especially when wildcards are applied to external projects.
Therefore, the right solution requires a fix to both: integrating the MSI with the just the required files, refining the nuget packager to punctually source files, over lazy wildcard-copying.

Make sense, the ideal experience I'm looking for is to install the .msi and have the includes work themselves out. I'll stick to the nuget package until then I guess.

Yes please, and thanks from bringing this up. As we get close to release, it is important to shave off typical development shortcuts/overlooks that have been taken so far.


Use custom operators

I love the idea of stating a constraint as an equation. However, using the bare equality and comparison operators for this purpose seems semantically incorrect and is bound to make the code harder to understand than it should be. I would suggest that we surround the equality and comparison operators with vertical bars to indicate "constraint". For example:
   view.topAnchor |>=| container.topAnchor + 5

This also lets us change the operator precedence if we need to.
In order to preserve backward compatibility, we could make the adorned operators the default, but allow bare operators via conditional compilation.
If you are interested in this, I could put a PR together.

Thanks for the feedback, but at this time we are going to stick with the ==, <= and >= operators because they are familiar to most users, and show clear intent especially with regards to the inequalities.


black-duck-sigma-plugin

Repository URL
https://github.com/sboyd-synopsys/black-duck-sigma-plugin
New Repository Name
black-duck-sigma-plugin
Description
I have a plugin already hosted at https://github.com/jenkinsci/synopsys-sigma-plugin . However, my company is undergoing rebranding so I want to change the repo and it's ID from synopsys-sigma-plugin (ID = synopsys-sigma) to black-duck-sigma-plugin (ID = black-duck-sigma). I have made some minor rebranding updates to the new repo I want to host. After this ticket is resolved (or perhaps as part of this ticket), we can remove the old https://github.com/jenkinsci/synopsys-sigma-plugin .
GitHub users to have commit permission
@sboyd-synopsys
Jenkins project users to have release permission
sboyd
Issue tracker
GitHub issues

/hosting re-check

The Jenkins Security Scan discovered 1 finding(s) :mag:.
For every identified issue, please do one of the following:

Implement the recommended fix to address the issue.
If you think it's a false positive, suppress the warning directly within the code.
Alternative, you write an explanation here about why you think it's irrelevant. That will require a manual review, leading to a slower process.

After addressing the findings through one of the above methods:

If all modifications have been made to the code, please initiate a new security scan by triggering the /request-security-scan command.
If there are any unresolved findings (those not corrected or suppressed), request a review from the Jenkins security team by using the /audit-review command.

Stapler: Missing POST/RequirePOST annotation
You can find detailed information about this finding here.
SigmaBinaryStep.java#219
Potential CSRF vulnerability: If DescriptorImpl#doFillSigmaToolNameItems connects to user-specified URLs, modifies state, or is expensive to run, it should be annotated with @POST or @RequirePOST

/hosting re-check

/request-security-scan

/request-security-scan

Hmm, can't seem to get the security scan from https://github.com/jenkins-infra/repository-permissions-updater/issues/4123#issuecomment-2404049761 to rerun, but I've fixed this issue and are ready for things to be checked over.

cc @Wadeck ^^
I also tried on another request earlier and I got no response

/audit-review

The Jenkins Security Scan did not find anything dangerous with your plugin, congratulations! :tada:

:bulb: The Security team recommends that you are setting up the scan in your repository by following our guide.

/hosting host

I also tried on another request earlier and I got no response

Thanks for the information, I will see what happened. (I was off end of last week, I hope to see alerts ;) )

Thanks it started working about 3 hours later.

I think the Google infra was down for the GMail events flow. Once I have time I will add some webhook support and ask for webhook registration on the repo.
💡 Possible to get admin access on the repo in advance and I will remove myself once working? :)

💡 Possible to get admin access on the repo in advance and I will remove myself once working? :)

Done


Beacon Node Request Failed

Getting Request failed: http://<IP_ADDRESS>:5052/eth/v2/beacon/blocks/5850051 when running, but curl -s http://<IP_ADDRESS>:5052/eth/v2/beacon/blocks/5850051 yields
{"code":500,"message":"UNHANDLED_ERROR: BlockHashMissingFromExecutionLayer(0x2681d8e6148d52e244b7b84f0335306d7185f16ffcb9e22d08ce48c442999dd1)","stacktraces":[]}
IMHO this is not a failed request: there was a reply, just not a satisfactory/usable one. Best to label it as Request Response Error or similar.
BTW the error is bc geth was behind/out of sync.
This is only feedback. feel free to close w/o comment. thanks again!

I've changed the wording of the error message in the latest release. When getting slots, in case of an error, we started including the error returned by the endpoint, so that it is clearer for the user why the request failed, or why it did not return the response expected. Will be closing issue.


Add support for Generator and AsyncGenerator

Hi @lxsmnsyc I see this already implemented in code but is that not flagged ready to use?
Try to use it with solid start but seem like doesn't work
export const logHello = async function (message: string) {
  'use server'
  console.log(message)

  return {
    title: 'Hello World',
    async* [Symbol.asyncIterator](): AsyncIterator<number> {
      await Promise.resolve()
      yield 1
      await new Promise((resolve) => setTimeout(resolve, 1000))
      yield 2
      await new Promise((resolve) => setTimeout(resolve, 5000))
      yield 3
    },
  }
}

export const logHello = async function * (message: string) {
  "use server";
  console.log(message);

  yield { a: true }
  await new Promise((resolve) => setTimeout(resolve, 5000))

  yield { b: true }
};

@ducan-ne Last time I've tested this this should work. Please provide more info.

@lxsmnsyc
The lastest version should happens
https://github.com/ducan-ne/solid-async-generator-reproduction/blob/main/src/actions.tsx
https://github.com/ducan-ne/solid-async-generator-reproduction/blob/main/src/components/Counter.tsx
for await (const value of logHello('Hello')) { not work either
Error
Uncaught (in promise) TypeError: logHello(...) is not a function or its return value is not async iterable

Or

Counter.tsx:20  Uncaught (in promise) {a: true}

Okay I've tested this one, this isn't a Seroval problem. Please create an issue in SolidStart.

Okay, thank for your infromation

@theturtle32 are we talking about the last comment or the entire concept

The entire concept works fine for me.

I use server functions with async generators to return chunks of streaming chat-bot responses from the server to the client via seroval.

And it appears that the related bug in SolidStart was closed as completed on May 20th.

@theturtle32 yep it's been resolved. This topic is originally for the fully support of Generators and AsyncGenerators (this also includes the yield) but got sidetracked


Remove most string allocations when reading file line by line

This is a follow-up of #267. With both PR, reading line-oriented formats is roughly 2x faster 🎉
Before
$ hyperfine --warmup 3 ./xyz ./lammps-data
Benchmark #1: ./xyz
  Time (mean ± σ):      72.1 ms ±   2.0 ms    [User: 64.2 ms, System: 4.9 ms]
  Range (min … max):    69.5 ms …  77.3 ms    40 runs

Benchmark #2: ./lammps-data
  Time (mean ± σ):      92.0 ms ±   2.7 ms    [User: 82.9 ms, System: 5.6 ms]
  Range (min … max):    87.2 ms …  98.2 ms    31 runs

PR #267
$ hyperfine --warmup 3 ./xyz ./lammps-data
Benchmark #1: ./xyz
  Time (mean ± σ):      56.2 ms ±   1.5 ms    [User: 48.5 ms, System: 4.6 ms]
  Range (min … max):    53.4 ms …  60.4 ms    51 runs

Benchmark #2: ./lammps-data
  Time (mean ± σ):      74.8 ms ±   1.9 ms    [User: 65.8 ms, System: 5.2 ms]
  Range (min … max):    72.0 ms …  79.2 ms    38 runs

Now
$ hyperfine --warmup 3 ./xyz ./lammps-data
Benchmark #1: ./xyz
  Time (mean ± σ):      26.4 ms ±   1.2 ms    [User: 22.0 ms, System: 3.0 ms]
  Range (min … max):    24.7 ms …  29.8 ms    103 runs

Benchmark #2: ./lammps-data
  Time (mean ± σ):      51.7 ms ±   2.8 ms    [User: 45.2 ms, System: 4.3 ms]
  Range (min … max):    47.8 ms …  60.5 ms    58 runs

The initial idea is from @richardjgowers: instead of allocating a new string for each line, use buffering to read a big block from the file, and return string_view inside this buffer for the line.
If a  line is too long to fit in the buffer (8192 characters by default), the buffer is automatically grown to fit bigger lines.

Finally manage to make all compilers happy \o/

This is a large PR, I'll try to get to it when I can.

@frodofine, do you think you will have time to review this in the next days? If you don't, that's completely fine, I'll do a review round myself :smiley:

Probably not! Sorry!

No problem, don't worry!

I added a few improvements if you want to look at them @ezavod. Else I'll merge this tomorrow =)


ARTEMIS-2933 Upgrade com.sun.winsw to 2.7.0-net4

The only executable included in the broker bin package that depends on .NET Framework 3.5 is artemis-service.exe/winsw. Using winsw for .NET Framework 4 we should remove any dependency on .NET Framework 3.5.
This would simplify the installation on Windows because .NET Framework 4 is installed by default on the last versions of Windows.

Is this backwards compatible with 3.5? For example, if a user had .NET Framework 3.5 installed would the new winsw still work?

It will require .NET Framework 4 is installed by default on the last versions of Windows while .NET Framework 3.5 not.

If my understanding is correct this may break users running .NET Framework 3.5. If so I don't think we can do this in a minor release. I think we'd want to ship versions that work with either 3.5 or 4.

Perhaps the pom.xml could be modified so that 2 different versions of artemis-service.exe are created. The new one could have a new name to reflect its usage (e.g. artemis-service-net4.exe or perhaps with the same name but in a new net4 directory) and the documentation could be updated accordingly (including deprecating the old one).

@jbertram artemis-service-net4.exe LGTM, I'll update the PR.

I would maybe avoid adding simply '-net4' in the name/patch at this point given 6 is already in RC phase?
The support pages https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies suggest all versions of windows back to 8/server2012 have some .Net 4 framework version installed by default, and all versions back to 7/server2008 can get one if not installed.
Given that it doesnt seem unreasonable to require it at this point, so what about the reverse possibility? Make an alternative 'new' "-net3" version that ships for a limited time as a fallback option if we think it necessary (given above, I probably wouldnt), and then anyone actually affected by the change can use it instead if they dont want to use one of the many 4+ versions already available to them.
I wouldn't say dropping support of a .Net version in a minor release is all that different than dropping support of a Java version in a minor release, which has been done before and is about to be done again.

Given that last bit of my previous comment, maybe changing to requiring .Net 4 [by default, if also adding the fallback option] in the same release as changing to requiring Java 11 would be a nice alignment of support changes.

@gemmellr I'm investigating on the possibility to run executable built for .NET 2 on .NET 4 using the App.config file
https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-configure-an-app-to-support-net-framework-4-or-4-5

If thats possible, great. I dont see a great need at this point personally. We are about to require a 4 year old JVM to run the broker...it doesnt seem unreasonable to require a ~10? year old version of .Net thats only optionally used to start/stop it.

@jbertram @gemmellr thanks for your feedback


DOC: Clarify range of allowed values values.

Coverage decreased (-0.06%) to 87.48% when pulling d05717870a73c720934d052d32d5dc37e217bc1b on update-sb-docs into b5eaec6bf91b52f6ed2c860a48b20eaf28e97f97 on master.


Does VSC really need to be added as a game?

On my copy of Discord VSC is not added and yet the rich presence shows.

You're right, Visual Studio Code doesn't need to be added in "Games" on discord. Such a thing is just to show a simple "Playing Visual StudioCode " when the process is running.

In the newest Discord, you don't need to make VSCode as a game. It works automatically (at least on my PC)

See https://github.com/maxerbox/vscode-discord/issues/7

VSCode seems to have been automatically added as a game by Discord now.  Maybe they added it to their server-side database? Of note is that the 'game' has been given no name.  I have not added this manually.

That's due to the Windows Registering, see
https://github.com/maxerbox/vscode-discord/issues/15
2017-11-26 14:28 GMT+01:00 Matthew Wolffsohn<EMAIL_ADDRESS>
[image: image]
https://user-images.githubusercontent.com/12937964/33240422-a44c076c-d2ad-11e7-8608-c3aef18630f5.png
VSCode seems to have been automatically added as a game by Discord now.
Maybe they added it to their server-side database? Of note is that the
'game' has been given no name. I have not added this manually.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/maxerbox/vscode-discord/issues/6#issuecomment-347008733,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMLKs0hGihIiqMFYcAHv21giqs1dvmWVks5s6WePgaJpZM4QmSAF
.

Why did it get removed if it was a useful feature?  As I understand it, removing the game from Discord's list breaks the removal of 'Playing vscode' from Discord.

Well, I followed the reviews on the markplace:
https://marketplace.visualstudio.com/items?itemName=maxerbox.vscode-discord#review-details
2017-11-26 17:14 GMT+01:00 Matthew Wolffsohn<EMAIL_ADDRESS>
Why did it get removed if it was a useful feature? As I understand it,
removing the game from Discord's list breaks the removal of 'Playing
vscode' from Discord.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/maxerbox/vscode-discord/issues/6#issuecomment-347019627,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMLKszCicJSrZNfnus_2L72q5cwMSp6oks5s6Y5ngaJpZM4QmSAF
.


Delete/Deprecate ContemporaneousEvent or change name

Spin-off of issue #174. See comment thread there. We could either change the name as proposed, or remove the term.

DECISION: change name to ContemporaryEvent, Was included in releases 11.0.0


Failed training for test_data: macro_tiles_10x10 and sample_clustered

We have trouble running these two testing data:  macro_tiles_10x10 and sample_clustered, although we succeeded in executing the training job for Ariane. The problem is that the tmux session for collect_job is stuck at model_id 0/step 0 and does not progress, which is show in the following figure.

For these two testing data, we typed the same commands as we tested Ariane except the following changes:
$  export NETLIST_FILE=./circuit_training/environment/test_data/sample_clustered/netlist.pb.txt
$  export INIT_PLACEMENT=./circuit_training/environment/test_data/sample_clustered/initial.plc

Are we required to make other changes to the commands?
Shall we modify the hyperparameters to fit each testing data, such as learning_rate, batch_size, etc?

I also got stuck with model_id 0/step 0 when i trained for Ariane example AFTER changing the sizes of the macros randomly to bigger numbers. Can you compare the dimensions of macros in your netlist with those in Ariane?
May be it is the limitation on macro size in comparison to grid cell size.

We haven't found the clue between macro size and grid cell size yet. However, we found that model_id/step will stuck at 0 after we only modify the grid size from 35x33 to 35x32 in Ariane.
We are still looking for the reasons.

I also wasn't able to run these 2 tests. Training stuck at iteration 0. And nothing is happening.

macro_tiles_10x10 has 100 macros. So you have to update the "sequence_length" to 101 in train_ppo.py and "max_sequence_length" to 101 in ppo_collect.py before starting the training.
"sequence_length" and "max_sequence_length" should be set to (TOTAL_NUMBER_OF_MACRO + 1) for training. The default value is 134 because the ariane test case has 133 macros.

You may check out our MacroPlacement repo.
We provide a script to write out the protobuf netlist from the Innovus tool which can be used as input to the CircuitTraining grouping code to generate the clustered netlist.
Also, you can train circuit training using the testcases available in MacroPlacement/Flows/<Enablement>/<Design>/netlist/output_CT_Grouping/.
If you are interested to learn more about proxy cost computation, you can visit this link.
You can find here the progress we have made till August 26.


For Atlas proxy, use entity ID (guid) instead of table uri

Summary of Changes

Use entity id instead of table uri. In Atlas part, use the guid for table_id and column_id.

Tests

Update test_atlas_proxy to test using of entity id.

Documentation

Works by default with Atlas.

CheckList
Make sure you have checked all steps below to ensure a timely review.

[ ] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[ ] PR includes a summary of changes.
[ ] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does

[ ] PR passes make test
[ ] I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message"

@L-KID
This seems like a backward incompatible change.
I know there's an open issue about this but we haven't reached into conclusion.
https://github.com/lyft/amundsenmetadatalibrary/issues/22
Do you want to continue discussion over there?

@L-KID
This seems like a backward incompatible change.
I know there's an open issue about this but we haven't reached into conclusion.
#22
Do you want to continue discussion over there?

@jinhyukchang
Sure, we could continue the discussion at #22.


Fix the docker file to have the correct mount of the local system for development in the container

Sort out the file volumes in the docker file

Complete system developed that each container connects to


feat(kafka): Support cross account access

Description of your changes
Adds cluster policy and connectivity properties that allow configuring cross account accessibility of a broker.
It is mostly copy-paste from the specialized bucket policy types into a generic ResourcePolicy struct and a bunch of late initialization and conversion methods.
It also fixes a bug that spec.forProvider.encryptionInfo was not late initialized properly which led to an error during updates.
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
Using the existing example.

I see lint due to k8 utils pointer just "fails green" due to other issues in other builds, while this PR the linter ran to completion and reported the error.


OS 2970825: Spread should throw a syntax error with unary operators

This is a bug is around from an early spec draft. Spread should throw a syntax error when it is not immediately preceeded by a comma, LParen, or LBrack. This fixes an assert that happens when we try to do codegen. There is no fre impact as it gets caught by assignment to rvalue.

@ianwjhalliday In the bug for this you mentioned that we should refactor the code by extracting out the ParseExpr handling of the ... operator, since it's not a real expression operator. Instead, we would explicitly scan ... in ParseArgList and ParseArrayLiteral.
This would be nice, but it requires more refactoring than that. The problem is the following case:
(...args) => blah
When we first scan the ..., we are treating the current context as a comma separated expression list. We mark the ... as a potential error and defer emitting it. When we see a =>, the error is no longer valid as it is now a rest parameter. At that point, we rewind and start reparsing the arg list as a lambda arg list. Because of this ambiguity it is not sufficient to handle ... just in ParseArgList and ParseArrayLiteral.
@pleath suggested that we could work around this by extracting out the parsing of the paren comma separated expression lists. We could then check for the ... explicitly before parsing every potential expression. Unfortunately this is a little invasive for refactoring, because of the flow of parsing the expressions in ParseExpr recursively.
Because of the complexity of handling the deferred (...a) error case, I am going to skip the refactoring for now. This might be a good issue to accept pull requests for as you mentioned.
As for getting rid of fAllowEllipsis, I would like to change that to be a member variable that we save and restore the state on the frame that requires the change. I also decided not to do this because we have several fAllowWhatever parameters around the parser that I think we could also do this with. I would also like to file an issue to fix these and reduce the amount of parameters we have to keep passing true/false to.

@abchatra please review (or anyone else who sees this :))

@Microsoft/chakra-es please review (trying out the new team mention!)

This fix looks good to me.

:+1: Please run test262 and make sure you haven't regressed any tests.

Sorry I am a little late to this party :)
Good write up about what happened, @tcare, much appreciated.
I am thinking about the ambiguity with ... in a parenthesized list.  If I am not mistaken the ... only can appear in a parameter list, so seeing it during parenthesized list parsing implies that either 1) the list is actually a parameter list for an arrow function, or 2) it is a syntax error.  That means we could stop parsing as a parameter list when encountering a tkEllipis token (specifically after a tkLParen or tkComma) and rewind back to the tkLParen and begin parsing as an arrow function, just like we do when we see the tkDArrow at the end the parenthesized list.
If it were in fact a syntax error because there was no tkDArrow afterward, then we would error out there and all is well.  Then we can do the refactoring I'd like to see.  The deferred potential error would also no longer be necessary.
No need to do this now for 1.2 release of course.  Just thoughts for simplifying the parsing code in the future.

If we stop parsing as a parenthetical expression immediately on seeing … , does that not mean that we’ll report errors specific to parameter lists, even when we really do have a parenthetical expression, and the … is a syntax error?
--Paul
From: Ian Halliday<EMAIL_ADDRESS>Sent: Thursday, April 28, 2016 2:31 PM
To: Microsoft/ChakraCore<EMAIL_ADDRESS>Cc: Paul Leathers<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Microsoft/ChakraCore] OS 2970825: Spread should throw a syntax error with unary operators (#856)
Sorry I am a little late to this party :)
Good write up about what happened, @tcarehttps://github.com/tcare, much appreciated.
I am thinking about the ambiguity with ... in a parenthesized list. If I am not mistaken the ... only can appear in a parameter list, so seeing it during parenthesized list parsing implies that either 1) the list is actually a parameter list for an arrow function, or 2) it is a syntax error. That means we could stop parsing as a parameter list when encountering a tkEllipis token (specifically after a tkLParen or tkComma) and rewind back to the tkLParen and begin parsing as an arrow function, just like we do when we see the tkDArrow at the end the parenthesized list.
If it were in fact a syntax error because there was no tkDArrow afterward, then we would error out there and all is well. Then we can do the refactoring I'd like to see. The deferred potential error would also no longer be necessary.
No need to do this now for 1.2 release of course. Just thoughts for simplifying the parsing code in the future.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Microsoft/ChakraCore/pull/856#issuecomment-215569024

@pleath I don't follow.  What would be an example?


perses app that uses any MultiStateSampler (including ReplicaExchangeSampler and subclasses) should minimize before simulation

Right now, none of the perses apps that useReplicaExchangeSampler and friends call sampler.minmize() before they start simulation. We should change this, since it is essential for ensuring stability of the resulting simulations.
Minimization should occur by default, but should be something we can override via the API or YAML.
Note that we should not re-minimize while resuming, however.

Should the default parameters be sane enough for this purpose? Considering that by default there is not limit on the number of iterations.

Yes, the defaults should be fine!
In the future API overhaul, our approach should be to have either the YAML,
CLI, or API delegate kwargs to the appropriate method automatically, like
sampler.minimization = True
sampler.minimization.options.max_iterations = 20
This isn't exactly what we would do, but hopefully communicates how we
would like to automatically delegate options rather than having to
explicitly handle each one. In future, adding a new optional argument or
class field should not require any changes to the API, CLI, of YAML
handling code to be able to accept overrides for these options.


Upstreaming some archive / coff short import writing code?

Howdy!
I've got some code for writing Windows dll import libraries in a PR over here: https://github.com/rust-lang/rustc_codegen_cranelift/pull/1414 - some of it seems like it would be useful to upstream here, with some work to improve the UX, testing, and polishing.
In particular, it has:

GNU-flavor archive writing with some pretty raw code for both GNU and MSVC symbol tables.

I think it's probably in spitting distance of being byte-for-byte with MSVC lib.exe?
I've taken a look at the other flavors, and they don't seem too bad to add support for?
UX is something of a concern to get right, but I think I can make it a bit nicer than ar or ar_archive_writer's current public API.
Using ar_archive_writer might be a better path, given the much more heavily tested code.

Pointless reproduction of the write::coff code that I missed the existence of 😅 - though maybe there's still something salvageable there
Short import objects, even though they are pretty straightforward.

And even the overall goal of writing DLL import libs seems like it might be in scope?
I'd be happy to work to get these up to your standard if you're interested.

Unless @bjorn3 wants ar_archive_writer to be replaced by code in object, I think it's better add the archive writing there since it already exists. And if so, I don't think DLL import library support belongs in object, since we don't want to add a dependency on ar_archive_writer.
write::coff isn't directly public code, but you can still access it via write::Object, and from a quick look it should be suitable for what you need, and I don't expect any significant changes to be needed there.
Short import object write support would be fine, since we have a parser for it already.

Sounds good. I've got plenty of stuff left in that PR to go, but I can look at getting a short import writing PR opened here in the meantime, which I assume should basically try to look like Object write?

So the code for the short import is just this:
https://github.com/rust-lang/rustc_codegen_cranelift/blob/a38d47146c0536f7526ded3b138afc945f160891/src/dll_import_lib/coff.rs#L92-L111
pub(crate) fn write_short_import(
    data: &mut DataWriter,
    dll_name: &str,
    name: &&str,
    ordinal_or_hint: Option<std::primitive::u16>,
) {
    data.write_pod(&ImportObjectHeaderUnaligned {
        sig1: u16(IMAGE_FILE_MACHINE_UNKNOWN),
        sig2: u16(IMPORT_OBJECT_HDR_SIG2),
        version: u16(0),
        machine: u16(IMAGE_FILE_MACHINE_AMD64),
        time_date_stamp: u32(0),
        size_of_data: u32((name.len() + 1 + dll_name.len() + 1) as u32),
        ordinal_or_hint: u16(ordinal_or_hint.unwrap_or_default()),
        name_type: u16(IMPORT_OBJECT_CODE << IMPORT_OBJECT_TYPE_SHIFT
            | IMPORT_OBJECT_NAME << IMPORT_OBJECT_NAME_SHIFT),
    });
    data.write_c_str(name);
    data.write_c_str(dll_name);
}

I'm actually not sure how useful it is really going to be to add a small function like this to object. You could add a function in object::write::coff that does that, but then you would need to use the data writing abstractions provided by object instead of your DataWriter, which may not fit well with the rest of your code. Unless you have a strong opinion on what this should look like, can I suggest delaying this until you've finished the rest of your PR, and reevaluate the usefulness then.

I was thinking mostly for consistency wrt the machine name type etc., moving to write::Object, but yeah, putting it onto Object in some way would probably make sense - maybe the public API is just .allow_short_import(bool) or something.
DataWriter will be pretty vestigial after replacing my ar and coff file writing, so I have no problem dumping it for this repo, I already assumed it would be, and I've already dumped a bunch of code in that PR. (I have a habit of writing a bunch of code then cleaning up when figuring out a new thing)
If I feel particularly sad about all the code in that PR I can always make my own crate (with classy ladies and Uno) 😊

(Possibly should be a new issue, but I'm still happy to PR any changes you think are appropriate to get this working with object)
Hmm. Took a stab at using write::Object but I don't think I can implement write_import_descriptor() with that?
dumpbin shows the following symbols for the valid member:
COFF SYMBOL TABLE
000 00000000 SECT1  notype       External     | __IMPORT_DESCRIPTOR_user32
001 00000000 SECT1  notype       Section      | .idata$2
002 00000000 SECT2  notype       Static       | .idata$6
003 00000000 UNDEF  notype       Section      | .idata$4
004 00000000 UNDEF  notype       Section      | .idata$5
005 00000000 UNDEF  notype       External     | __NULL_IMPORT_DESCRIPTOR
006 00000000 UNDEF  notype       External     | user32_NULL_THUNK_DATA

Which if I dump it using read::coff::CoffFile looks like:
  - Ok("__IMPORT_DESCRIPTOR_user32"): Data => Section(SectionIndex(1))
  - Ok(".idata$2"): Section => Section(SectionIndex(1))
  - Ok(".idata$6"): Data => Section(SectionIndex(2))
  - Ok(".idata$4"): Section => Common
  - Ok(".idata$5"): Section => Common
  - Ok("__NULL_IMPORT_DESCRIPTOR"): Data => Undefined
  - Ok("\u{7f}user32_NULL_THUNK_DATA"): Data => Undefined

But Object::add_symbol() doesn't let me emit with SymbolKind::Section and SymbolSection::Common for .idata$4 and .idata$5 (it assumes SymbolSection::Section()).
write_null_thunk_data creates a separate object with those sections:
  sections:
  - .idata$5: 8 bytes
    0 relocations:
  - .idata$4: 8 bytes
    0 relocations:
  symbols:
  - Ok("\u{7f}user32_NULL_THUNK_DATA"): Data => Section(SectionIndex(1))

Not sure why that's what MSVC does, but I blindly copied the structure, and it works. so 🤷
(To clarify, this is so the linker will build a valid import directory entry for the DLL, using the $n suffixes to order, and relocations to link up the imports)
I tried a few different approaches, but nothing seems to successfully link: using values like Data / Undefined the linker complains about missing .idata$4/5 symbols, as you might expect, or Object::write() panics etc.
I tried inlining the section definitions:
  sections:
  - .idata$2: 20 bytes
    3 relocations:
    - 0: Relocation { kind: ImageOffset, encoding: Generic, size: 32, target: Symbol(SymbolIndex(0)), addend: 0, implicit_addend: true }
    - 12: Relocation { kind: ImageOffset, encoding: Generic, size: 32, target: Symbol(SymbolIndex(4)), addend: 0, implicit_addend: true }
    - 16: Relocation { kind: ImageOffset, encoding: Generic, size: 32, target: Symbol(SymbolIndex(2)), addend: 0, implicit_addend: true }
  - .idata$4: 8 bytes
    0 relocations:
  - .idata$5: 8 bytes
    0 relocations:
  - .idata$6: 11 bytes
    0 relocations:
  symbols:
  - Ok(".idata$4"): Section => Section(SectionIndex(2))
  - Ok(".idata$5"): Section => Section(SectionIndex(3))
  - Ok(".idata$6"): Section => Section(SectionIndex(4))
  - Ok("__IMPORT_DESCRIPTOR_user32"): Data => Section(SectionIndex(1))
  - Ok("__NULL_IMPORT_DESCRIPTOR"): Data => Undefined
  - Ok("\u{7f}user32_NULL_THUNK_DATA"): Data => Section(SectionIndex(3))

but that just crashes on link and dumpbin shows an empty import section for user32.dll 😔
Am I missing something?

Yeah that looks like a combination of fields that we don't support yet. Don't expect read::coff::CoffFile to give meaningful results for this. Do you know of any documentation that describes these symbols?

One option may be to add a SymbolFlags::Coff variant to let you override these fields (at least storage_class and maybe typ too), similar to what is already possible for other file formats.

The best documentation I could find is just the idata description at https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-idata-section.
I'm now thinking that write::Object is too complicated for what this needs to do, and maybe we should add write::coff::Writer (similar to write::elf::Writer).
This would also be a good place to add higher level helpers for creating the complete objects, as well as the short imports (so the equivalent of things like your coff::write_import_descriptor and coff::write_short_import).
If you want, I can do the work to create write::coff::Writer, and let you do the higher level helpers.

Yeah, theres' some GNU code out there, etc., but that seems to be only only official documentation for linkers. I've been mostly just trying to match what MSVC does.
I'm not sure that write_import_descriptor by itself makes sense as a public API - not without better experience figuring out what MSVC is even doing there at least. The combined import descriptor / null thunk entries together should work as a "import directory entry" but I'm not sure exactly why it's not a single COFF file already: probably something to do with merging multiple import libraries for the same DLL? I'm more confident about a higher-level "write import library" / "add imports to an archive" type API, but that seems like it's probably out of scope for this crate.

Which if I dump it using read::coff::CoffFile looks like:

Ok(".idata$4"): Section => Common
Ok(".idata$5"): Section => Common

These are a bug; they aren't actually common symbols. Instead, they are section symbols for sections that are defined in another member of the archive. #592 improves the read side of this.
write::Object still isn't going to handle these correctly, but we could easily add support for the combination of SymbolKind::Section + SymbolSection::Undefined to handle .idata$4 and .idata$5 (so both of those would be IMAGE_SYM_CLASS_SECTION).
However, I don't know why .idata$2 uses IMAGE_SYM_CLASS_SECTION and .idata$6 uses IMAGE_SYM_CLASS_STATIC, or what values the API should use to let the user choose between these. Are you able to test if this matters? e.g. is it okay to change one or the other to be the same?

Yeah, I was planning to poke around to see what works before defining a public API. I'm particularly curious why MSVC has the null thunks and null directory entry in a separate member: my understanding was that linkers operate on the section level so I can't figure out why they would have it be that complicated, $4 and $5 seem like they should be fine to be defined in the same never. Something about ordering or merging, perhaps? (But there's no COMDATs...)

So: $6 being SECTION instead of STATIC makes the executable fail on load with: exit code: 0xc0000135, STATUS_DLL_NOT_FOUND which is interesting, the DLL name gets completely dropped from dumpbin /exports on the executable:
File Type: EXECUTABLE IMAGE

  Section contains the following imports:

<-- No DLL name here! -->
             14001E2B0 Import Address Table
             140027C50 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                           0 GetWindowTextA
                           1 EnumWindows

    KERNEL32.dll
             14001E000 Import Address Table
             1400279A0 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                          89 CloseHandle
                         4B8 ReleaseSRWLockExclusive
                         4B6 ReleaseMutex
                         4B9 ReleaseSRWLockShared
                         26A GetLastError

$6 is the DLL name, so that makes some sense... but not why it would just disappear when the others don't (everything is still in the emitted .lib and parses fine, to be clear)
On the other hand, changing $2 to STATIC seems to work fine.
The docs are shockingly worthless - less than worthless even - here:

Constant
Value
Description/interpretation of the Value field

IMAGE_SYM_CLASS_STATIC
3
The offset of the symbol within the section. If the Value field is zero, then the symbol represents a section name.

IMAGE_SYM_CLASS_SECTION
104
A definition of a section (Microsoft tools use STATIC storage class instead).

🤦♂
Interestingly, moving the thunk sections $4 and $5 into the main directory member and removing the UNDEF references work fine ... but only when you drop the EXTERNAL (I guess the directory entry is magic to support both a SECTION/STATIC symbol and an EXTERNAL symbol?). No such luck on the NULL_DIRECTORY_ENTRY.
Presumably this is because this is the only library defining imports for the dll_name, but not the only import library, so the linker can't only pick the one.
That sort of answers why there needs to be three members too: so that they can be referenced by EXTERNAL symbols and duplicates null thunk members or null directory entries can be dropped when merging libraries?

Now for the fun bit downstream of figuring out all this again, but for windows-gnu target 😅

I think each DLL has its own null thunk (shouldn't ever be duplicates), but there is only one null directory (duplicates are dropped). So it makes sense that there might be a reason why it needs to be separate, but I still don't know why exactly.

I've started implementing write::coff::Writer and I think it'll be useful for this. Might be a few days though.

Thanks, yeah!
Sorry I wasn't clearer about your earlier suggestion to do so: I don't want to step on any toes if you have a preferred API.
I've been focusing on figuring out what else needs to be done to get my PR over the line, and while it's a bit ugly, the current code doesn't block that.
I'm now a lot more confident about what the import library API using this would ideally look like though: if you have an API surface you expect to implement I can get that up in it's own repo (and maybe crate?) so you can end to end of you like.

The code I'm writing won't know anything about import libraries. I'll modify write::Object to use it, so that'll be a decent amount of test coverage. I'll also experiment with converting bits of your cf_clif PR to ensure that API is usable for you. I think there's still room for an import library API to be layered above this, but that doesn't need to be done yet.

#595 adds a COFF writer, and I've partially converted your PR in https://github.com/philipc/rustc_codegen_cranelift/commit/a8e58042fe0af2c7678e50e3c693e1b65eeb1a91 (untested). The main difference from your writer is that it supports streaming the output, so it needs to reserve file ranges up front instead of mutating headers later. Review is welcome.

Cool, I'll take a look this weekend.

it should probably be both read + write, more object::Object::write than object::coff::write, if that makes sense.

Heh, nah I'm missing something there. How is that code related to read or object::Object? I can understand it being separate from object::write::coff::Writer, but I would still expect it to be in object::write::coff. And if we include write_short_import, I think we should include the rest of the file as well, since it's not really useful by itself.

I've got a very little bit of reading it back in get_symbols, just for reference.

Ideally you should be able to use object::read::coff::ImportFile for that.

This doesn't use object::pe::ImportObjectHeader as that asserts 4-byte alignment

That sounds like something we should fix. Technically it's a breaking change though...

type NtCoffFile<'data> = object::read::coff::CoffFile<'data, &'data [u8], object::pe::ImageFileHeader>;

You should be able to use CoffFile<'data> instead, since the other two type parameters have defaults.

In theory a short import is just shorthand for a coff file with a symbol export mapped to an .idata import table thunk, so it should be representable as an object::Object even, but it's a bit of an odd case.

Yeah that makes sense. We can consider doing that if it's useful.

it should probably be both read + write, more object::Object::write than object::coff::write, if that makes sense.

Heh, nah I'm missing something there. How is that code related to read or object::Object? I can understand it being separate from object::write::coff::Writer, but I would still expect it to be in object::write::coff. And if we include write_short_import, I think we should include the rest of the file as well, since it's not really useful by itself.

I simply mean in terms of being a structure that you can read and write, rather than the low level read/write. But that would probably just be the impl Object stuff I referred to at the end.

I've got a very little bit of reading it back in get_symbols, just for reference.

Ideally you should be able to use object::read::coff::ImportFile for that.

Oh, is that for short imports? Damn.

This doesn't use object::pe::ImportObjectHeader as that asserts 4-byte alignment

That sounds like something we should fix. Technically it's a breaking change though...

Yeah. Honestly the whole unaligned feature is a bit confusing to me: I can see optimizing aligned access, but ideally that would be something you could pick at use-site (eg read and read_unaligned?)

type NtCoffFile<'data> = object::read::coff::CoffFile<'data, &'data [u8], object::pe::ImageFileHeader>;

You should be able to use CoffFile<'data> instead, since the other two type parameters have defaults.

That's what I thought, but it was yelling at me. I might have just been screwing it up though? Probably just missing the lifetime parameter and misreading the error.

I simply mean in terms of being a structure that you can read and write, rather than the low level read/write. But that would probably just be the impl Object stuff I referred to at the end.

Ah I see. So basically add write capability to read::coff::ImportFile, except that I don't think that is a suitable structure for writing. I think adding something new in write::coff is better.

Honestly the whole unaligned feature is a bit confusing to me: I can see optimizing aligned access, but ideally that would be something you could pick at use-site (eg read and read_unaligned?)

We're not copying anything, just pointing at it. Alignment is a property of the type and rust doesn't allow unaligned pointers. So the only way I can see to allow you to pick at use-site is to use different types, and I don't want that.
The goal was that you shouldn't ever need to enable the unaligned feature for normal files, because we should have set the alignment of the types to whatever is used in practice. The unaligned feature is an escape hatch for unusual cases (e.g. the files are embedded in something else that isn't aligned).
In hindsight, I'm not sure that the performance benefit is worth the complexity cost. For now, you can enable the unaligned feature to avoid the errors. It's what would happen anyway if I removed the feature.

I see! You could have the unaligned read method return a copy, without the ref it would be automatically aligned. Probably more expensive and uglier to use than unconditionally using unaligned access.
The bigger issue with aligned access is the data is probably being read from a Vec<u8>, which you can't technically guarantee the alignment of (but it's probably going to be at least usize alignment, which should be enough)
In my case, I didn't feel it appropriate to add the unaligned feature to rustc_backend_cranelift in my first PR, especially since it seems like they deliberately disabled it, but who knows 🤷

The unaligned feature is not intentionally disabled. Wasm support is though. Note that ar_archive_writer already enables the unaligned feature anyway.

FYI, ar_archive_writer can now create import libraries: https://github.com/rust-lang/ar_archive_writer/pull/15

In that case I expect there's nothing more to be done here.


No attribute needed to create .travis file

Describe the bug
The creation of the .travis file reads the attribute ''use_pypi_deployment_with_travis", that was removed in commit 'Remove use_pypi_deployments_with_travis prompt'.
To Reproduce
Steps to reproduce the behavior:

Just install and answer all questions.

Expected behavior
Clear creation with no errors.

I got the same issue

I have the same issue. For me this issue is causing the cookiecutter script to fail. Does this mean that nobody has been able to use this cookiecutter for 2 years now?

I managed to correct, but I don't remember how because it was a long time ago. I have a cookiecutter repository, I think it is still working, i can check.

I have same problem but it seems there is no solution here!


📚 Documentation: Aadd AWS Lambda example for self hosted copilotkitRuntime

💬 Let us know how we can improve our documentation.
Provide an example to make a copilotKitRuntime into an aws lambda behind an aws apigateway.

Hey @ClementVanPeuter, thanks for the request.
I'd like to understand more because I will create a customer need ticket.
What is the level of impact without this example?

Hi @NathanTarbert.
We love CopilotKit, and we already deploy a self hosted copilot runtime in the form of a node js express endpoint, successfully.
But it's not great, all of our services are in AWS ( in Lambda to be precise, EC2 instances are a no go for us, for politicals reasons).
Today I struggle to adapt my node js express code to a lambda code.
I've used  the serverless-http package to make my code "compatible". And it's works fine until the handler code.
My lambda is behind an API GAteway like https://jhrtic3eh.execute-api.us-east-2.amazonaws.com/default/copilotkit-endpoint, and the copilotRuntimeNodeHttpEndpoint require an endpoint.
`app.use('*', async (req, res, next) => {
console.log('Handling request post');
const handler = copilotRuntimeNodeHttpEndpoint({
    endpoint: '/copilotkit-endpoint',   <- THIS URL
    runtime,
    serviceAdapter: serviceAdapter,
});

console.log('Handler created');
const response = await handler(req, res, next);
console.log('Response received');
console.log("RESPONSE:",response);
return handler(req, res, next);

});
export const handler = serverless(app);`
So in my logs i see the console logs but response is undefined.
And I  strongly believe it's due to the fact the handler endpoint it's not correct and colide in a way with the API GATEWAY settings.
So it's possible to have an AWS lambda ( with api gateway) example in the doc section in addition with the others ?
This greatly slows down adoption of copilotKit in our teams and in our products :/

Hey I am new to open-source, @ClementVanPeuter can you tell me which files should I be looking into, then I can take this up, thanks!

@ClementVanPeuter, I'd like to connect you 1:1 with Graham, our Dev Evangelist. Could you set a time on his calendar?
https://go.copilotkit.ai/grahams-calendar


[Feature Request] weighted pearson correlation

Description
If heteroscedasticity in the data is assumed, it would be beneficial if a weighted pearson correlation could be calculated in which points of high importance receive a higher impact.
Note: test if switching of x-, and y-data has an impact on correlation value!
Related information
weighted pearson

closed by e03123933ee2bc3b3dd2e6da54892f2b9254ee27


Create a Basic Backend Pipeline

I've never used Github Actions before but I want a pipeline to do the following:

Run go vet ./...
Run golangci-lint on the project
Run go test ./...

Note: There may or may not actually be any tests, but this shouldn't fail the pipeline.

This is a low priority for the time being, as useful as it would be


Email source cors cache

New PR as discussed in https://github.com/KartikTalwar/gmail.js/pull/333

As already noticed by @josteink in the merged PR #329 there is a CORS problem when the browser caches the first redirect.
Although it seems that the location of the redirect is the same when requested 'fresh' but Google only supplies the Access-Control-Allow-Origin header for the latter. Strangely!!! Btw, this might also happen in other places so if you see CORS related errors check that the cache is not used. And of course to learn from this... do not disable cache in devtools when testing gmail.js! ;)
jQuery's {cache: false} adds something like this to the url _=76348726487 which might not be OK for all GET calls so I've added the flag on make_request and make_request_async.

LGTM.  Thanks for contributing!


Can't compile a local working bundle

I cloned the repo and I tried to npm run build but the bundle produced doesn't seem to work when linked to cosmos. I locked the versions of all packages in package.json to ensure I use the same vendor code, but it still throws
Uncaught Error: Invariant Violation: addComponentAsRefTo(...): Only a ReactOwner can have refs. This usually means that you're trying to add a ref to a component that doesn't have an owner (that is, was not created inside of another component's `render` method). Try rendering this component inside of a new top-level component which will hold the ref.

when I run cosmos in browser. When used with the bundle from npm everything works fine. Any ideas?

the bundle produced doesn't seem to work when linked to cosmos

Not sure what "linked to cosmos" means. This repo just bundles a React component, Cosmos is the built-in solution. The only case when you want to use this repo is if you don't want to use Cosmos and you want to integrate ComponentPlayground differently.

Uncaught Error: Invariant Violation: addComponentAsRefTo(...): Only a ReactOwner can have refs. This usually means that you're trying to add a ref to a component that doesn't have an owner (that is, was not created inside of another component's render method). Try rendering this component inside of a new top-level component which will hold the ref.

I can tell you from experience this probably means you bundled React more than once in your build (check out the bundle file to see for yourself). You can search the internet to see that React doesn't work with another React instance alongside.

By linked to Cosmos I mean npm linking this package (repo) to cosmos. I spent some more time and it seems that if I just make some changes to files in a clone of this repo, run npm run build and copy bundle.js file to node_modules/react-component-playground/build folder in Cosmos it works... so it's the linking part that causes this Invariant Violation error.

I can only assume you were trying to test some changes to ComponentPlayground inside Cosmos. I had the same problem since this is how I test ComponentPlayground changes: by linking the react-component-playground dependency from the cosmos-js dependency in the cosmos-example repo (or other repo using cosmos-js like Flatris).
If this is what you're interested in, here is my flow:
I tried linking /path/to/cosmos-example/node_modules/cosmos-js/node_modules/react-component-playground/build/bundle.js to /path/to/react-component-playground/build/bundle.js using ln -s, and I got the same result as you. The linking somehow messed up the webpack build and got two instances of React side by side, yielding the Invariant Violation error above.
My current workaround is to temporarily edit output.path in ComponentPlayground's webpack config from ./build/bundle.js to /path/to/cosmos-example/node_modules/cosmos-js/node_modules/component-playground/build/bundle.js
This way I can keep two terminals with both node_modules/.bin/component-playground running inside the cosmos-example repo and webpack --watch in the react-cosmos-playground repo, while I perform changes to the ComponentPlayground component.

Thanks for clarification. The problem is most probably related to this issue: https://github.com/webpack/webpack/issues/554 But it seems that it should already be resolved in the version of Webpack used here... I'll look into this in more detail.


Random seed

Hey there!
This library looks amazing and I'm about to implement it into a project now. Any chance you'd be interested in having an avatar generated given a seed phrase? It could look something like this:
<Avatar seed="[some-random-string]" />

Any time Avatar received that seed string it would output the same avatar, similar to the way you can replicate Minecraft worlds by providing it with the same seed phrase upon generation.
Awesome work and thanks for building this!!

Hey @stevenleeg, thanks for the feedback, I think that's a good idea. However, unfortunately I don't have bandwidth to do this for now. If you can open a new PR for it, I am happy to review it.

Hey,
I needed something like this.
Here's my implementation:
import React from 'react'
import Avatar from 'avataaars'

const Avataaar = props => (
  <Avatar
    avatarStyle='Circle'
    {...props}
  />
)

export const SeededAvataaar = ({seed}) => {
  const items = seed.match(/.{1,2}/g).map(e => parseInt(e, 16))
  const options = { }
  const keys = [...configsKeys]

  keys.map((e, i) => Object.assign(options, {[e]: configs[e][items[i] % configs[e].length]}))

  return (
    <Avataaar {...options} />
  )
}

const configs = {
  topType: [
    'NoHair',
    'Eyepatch',
    'Hat',
    'Hijab',
    'Turban',
    'WinterHat1',
    'WinterHat2',
    'WinterHat3',
    'WinterHat4',
    'LongHairBigHair',
    'LongHairBob',
    'LongHairBun',
    'LongHairCurly',
    'LongHairCurvy',
    'LongHairDreads',
    'LongHairFrida',
    'LongHairFro',
    'LongHairFroBand',
    'LongHairNotTooLong',
    'LongHairShavedSides',
    'LongHairMiaWallace',
    'LongHairStraight',
    'LongHairStraight2',
    'LongHairStraightStrand',
    'ShortHairDreads01',
    'ShortHairDreads02'
  ],
  accessoriesType: [
    'Blank',
    'Kurt',
    'Prescription01',
    'Prescription02',
    'Round',
    'Sunglasses',
    'Wayfarers'
  ],
  hatColor: [
    'Black',
    'Blue01',
    'Blue02',
    'Blue03',
    'Gray01',
    'Gray02',
    'Heather',
    'PastelBlue',
    'PastelGreen',
    'PastelOrange',
    'PastelRed',
    'PastelYellow',
    'Pink',
    'Red',
    'White'
  ],
  hairColor: [
    'Auburn',
    'Black',
    'Blonde',
    'BlondeGolden',
    'Brown',
    'BrownDark',
    'PastelPink',
    'Platinum',
    'Red',
    'SilverGray'
  ],
  facialHairType: [
    'Blank',
    'BeardMedium',
    'BeardLight',
    'BeardMajestic',
    'MoustacheFancy',
    'MoustacheMagnum'
  ],
  facialHairColor: [
    'Auburn',
    'Black',
    'Blonde',
    'BlondeGolden',
    'Brown',
    'BrownDark',
    'Platinum',
    'Red'
  ],
  clotheType: [
    'BlazerShirt',
    'BlazerSweater',
    'CollarSweater',
    'GraphicShirt',
    'Hoodie',
    'Overall',
    'ShirtCrewNeck',
    'ShirtScoopNeck',
    'ShirtVNeck'
  ],
  clotheColor: [
    'Black',
    'Blue01',
    'Blue02',
    'Blue03',
    'Gray01',
    'Gray02',
    'Heather',
    'PastelBlue',
    'PastelGreen',
    'PastelOrange',
    'PastelRed',
    'PastelYellow',
    'Pink',
    'Red',
    'White'
  ],
  graphicType: [
    'Bat',
    'Cumbia',
    'Deer',
    'Diamond',
    'Hola',
    'Pizza',
    'Resist',
    'Selena',
    'Bear',
    'SkullOutline',
    'Skull'
  ],
  eyeType: [
    'Close',
    'Cry',
    'Default',
    'Dizzy',
    'EyeRoll',
    'Happy',
    'Hearts',
    'Side',
    'Squint',
    'Surprised',
    'Wink',
    'WinkWacky'
  ],
  eyebrowType: [
    'Angry',
    'AngryNatural',
    'Default',
    'DefaultNatural',
    'FlatNatural',
    'RaisedExcited',
    'RaisedExcitedNatural',
    'SadConcerned',
    'SadConcernedNatural',
    'UnibrowNatural',
    'UpDown',
    'UpDownNatural'
  ],
  mouthType: [
    'Concerned',
    'Default',
    'Disbelief',
    'Eating',
    'Grimace',
    'Sad',
    'ScreamOpen',
    'Serious',
    'Smile',
    'Tongue',
    'Twinkle',
    'Vomit'
  ],
  skinColor: [
    'Tanned',
    'Yellow',
    'Pale',
    'Light',
    'Brown',
    'DarkBrown',
    'Black'
  ]
}

const configsKeys = Object.keys(configs)

Note that the seed is expected to be a large hexadecimal string - by large I mean at least 12 pairs of hex characters (see seeded avataaat implementation as to why or how it's used).

@elis your implementation looks good.
What is exactly your mapping 1 bytes => 1 attribute? I think it would be interesting if empty/blank attributes would show up when a byte is 0x00. What do you think would be the right distribution of the different items. Show every item the same number of times?
PS: Your current implementation shows styles at the beginning of the list more often than the ones at the end, because how you use the modulo "%".

@FlorianKoerner @fangpenlin @elis
I'd love to have a way to generate an avatar deterministically based on arbitrary id. The problem I see with https://avatars.dicebear.com is that it requires a web request. If I'm rendering 100s of avatars on the same screen, this is really costly.
Is there still interest in a PR to do something like this? (In a client-only fashion).

@jay-khatri
You can also use DiceBear avatars without HTTP API. You just have to install the NPM packages.
See: https://github.com/DiceBear/avatars/tree/v4/packages/avatars-avataaars-sprites#npm

Didn't know that, thanks 🙏 .


PARQUET-2089: [C++] Align RowGroup file_offset with specification

CC @sunchao

Rebased to hopefully get green CI.


Not working in IE 9

webcamjs is installed via bower: "webcamjs": "*",
Internet Explorer version is 9.0.8112.16421 (http://joxi.ru/BA0MMepfjWK8ry)
adobe flash player version is: <IP_ADDRESS> (http://joxi.ru/DmBnneNsobBRmP)
upon initialization we have the following: http://joxi.ru/5md00p7FBXZ4m1

in all other browsers there is no such problem

Have you tried using any other flash webcam apps on that computer? Do you have the same issue with them? Try this: http://webcamtoy.com/app/
Are you running on a native machine, or on a virtual machine?

Not yet tried the others, I'll do it today.
It's running on a native machine.

on one machine with IE 11 everything is ok, on another one with IE 9 - the same issue.

When using the Webcam.upload() method IE9 does not support:
Blob, Uint8Array, FormData
Polyfills required for all of those functions.

@jasondecamp Sorry for the confusion.  The IE 9 limitation is covered in the docs here:
https://github.com/jhuckaby/webcamjs#including-in-an-existing-form
"This alternate upload technique is also shown here because it's probably the only way it'll ever work in IE 7, 8, and 9. Those older IE versions do not support binary AJAX and blobs, so the standard Webcam.upload() function will not work, and you'll have to use a form trick like this..."


AIP-121: require re-using proto message across CRUDL

AIP-121 states:

If the request to or the response from a standard method (or a custom method in the same service) is the resource or contains the resource, the resource schema for that resource across all methods must be the same.

this one is implicitly supported today, since all the AIP rules require that the method URI matches pattern annotation of the google.api.resource.
Also as outlined in 1103 it's difficult to do checks that span multiple RPCs.
I think in practice this isn't an issue so I'll remove it from the milestone, but keep in the backlog for a future milestone.

As we prepare for CS-2312, I'm triaging the associated milestone list. Moving this to the backlog milestone for the same reasons mentioned above.

For practical purposes I think this is enforced: a Create* needs to follow a specific pattern, and it fails if it can't find a resource and if the path doesn't match.
The only exception is for custom methods, and as we've discussed offline it's impossible to tell if a custom method operates on a single resource, or multiple resources (therein lies the term custom).
So I'm pretty confident we can close this as is.


Suggested change to Boo III velocity dispersion

Carlin and Sand (2018) update the velocity dispersion of Boo III from 14.0 --> 10.7.
See here: https://arxiv.org/abs/1805.11624

Updated in this commit https://github.com/apace7/local_volume_database/commit/b6388e6d4821334b409170599264dfce52015e44#diff-87c14deba6ce87c5bad5512d2ea18aea5d1f003f8124ca03410c9fdac8735e58


Can't delete temp file on Windows

parseBody() creates a temporary file when the size is larger than some limit. This goes in the OS's temp folder and eventually gets mapped to java.nio.* classes via randomAccessFile.getChannel().map(). At this point the finally { safeClose( randomAccessFile ); } is unable to delete the file on the Windows platform and it looks like this is due to JDK bug 4715154 (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154). An exception is thrown by DefaultTempFile.delete() after the session is done.
Temporary workaround: increase MEMORY_STORE_LIMIT to avoid temporary files.
NanoHTTPD v2.2.0
Platform: Windows 7
Java JRE 1.8.0_71

there is a better solution, if you keep a specific order of the commands to close a memory mapped file it will work also under windows. I will have to dig this out....

This bug doesn't really hurt because everything still works. Only the log is polluted and the files will never be deleted. MEMORY_STORE_LIMIT is quite low with 1024 bytes.
According to http://stackoverflow.com/questions/2972986/how-to-unmap-a-file-from-memory-mapped-using-filechannel-in-java the call of System.gc() will solve the problem. But garbage collection cannot be forced. So instead of throwing an exception if delete fails the file should be kept in a collection of not-yet-deleted files. A timer tries regularly to delete the files.
I did an implementation and it works.  So before I create a pull request: Are you sure that it is a good idea at all to have a temporary file and then map it to the memory? Does this really use less memory than just keep the data in memory?

@ritchieGitHub did you get any breakthrough on this yet?
I'm pushing this and a few others to 3.1.0 anyways.

@BrunoEberhard did the workaround in your fork work out?

Right now I'm too far away from the topic. I think it will work but I don't know how we could test or proof it.


Refreshing your results page changes header and sharing options

When the user's results page is refreshed, the share buttons disappear, he is invited to take the survey himself, and the header does not indicate it is his results page. The page should be shareable and show that the results are those of the user.
The bug was found when the gif loaded incorrectly due to a connectivity issue (wifi), so users might run into this issue naturally as well.

That is inevitable
when they refresh we loose all their data (unless we invest time in
building local storage)
So a refresh is identical to someone coming in from a share
On Tue, Sep 29, 2015 at 4:40 PM, DarkSymmetry<EMAIL_ADDRESS>wrote:

When the user's results page is refreshed, the share buttons disappear, he
is invited to take the survey himself, and the header does not indicate it
is his results page. The page should be shareable and show that the results
are those of the user.
The bug was found when the gif loaded incorrectly due to a connectivity
issue (wifi), so users might run into this issue naturally as well.
—
Reply to this email directly or view it on GitHub
https://github.com/HumanDynamics/MassScaleSocialSystems/issues/99.

okay


Publish doesn't send messages

Hi,
I don't think the publish is working correctly.
const nknWallet = require('nkn-wallet')
const nkn = require('nkn-client')
const wallet = nknWallet.newWallet('pwd')
const client = nkn({
  privateKey: wallet.getPrivateKey(),
  indentifier: 'client'
})
const receivingClientWallet = nknWallet.newWallet('pwd')
receivingClientWallet.subscribe(
	'topic',
	0,
	10,
	'pwd',
	'identifier'
)
client.on('connect' , () =>
setTimeout(() => {
	client.publish(
	'topic',
	0,
	'hello world'
	)
}, 1000)
)

This makes a request where it gets a result like {"id":"1","jsonrpc":"2.0","result":{"identifier.02c988e6a672fd6b8cf42e68682362ee152a8afb5176b9206c558b4cb89daba47d":"","identifier.0352304707e0af0187b435ea5f3ec8f3a0fbac71e3e801dbc34b3cf8d4000d1128":"","identifier.03c7575885c10f141576d817fa5fbca5144e74e3fd85838530ec8a8027d587aa5a":""}}
But then nothing gets sent to them afterwards.

Yes your understanding is correct, but subscribe takes some time (usually less than one block interval, i.e. 20s) to be effective because it is an on-chain operation (that's why it's in wallet). publish is an off-chain operation, so once subscriber info is recorded on-chain, publish will be instant

I don't see any messages getting sent even when the response result field has entries, though. I.e. if I change to a 30sec timeout in my example there, although it does find the subscriber in the response, it still never sends any messages.
On a related note, could you please set the publish method to return the response object, instead of nothing.

You are right, recently metadata is added to subscriber info so it's not parsing correctly. It's fixed in #47 now. Here is a working example:
const nknWallet = require('nkn-wallet')
const nknClient = require('nkn-client')

const sendingClient = nknClient()

const receivingWallet = nknWallet.newWallet('pwd');
const receivingClient = nknClient({
  privateKey: receivingWallet.getPrivateKey(),
  identifier: 'client'
})

receivingWallet.subscribe('topic', 0, 10, 'pwd', receivingClient.identifier).then(r => {
  console.log('subscribe success:', r)
})

receivingClient.on('message', (src, payload) => {
  console.log('reveive message:', payload)
})

sendingClient.on('connect', () => {
  setTimeout(() => {
    console.log('publish');
    sendingClient.publish('topic', 0, 'hello world')
  }, 60 * 1000);
})

60s is usually enough, but in some cases it may take longer because the txn may be packed in a later block, plus block interval can be increased from 20s to 60s in some cases.
Publish is a one-to-many message and thus does not support reply, otherwise it may be used to perform DDoS attack. It may throw error though.

Yeah, it works now, but it also has a bug. The rpcCall function doesn't seem to always throw errors, instead it returns them.
// rpc.js
module.exports = rpcCall;

async function rpcCall(addr, method, params = {}) {
  let response = await fetch(addr, {
    method: 'POST',
    body: JSON.stringify({
      jsonrpc: "2.0",
      method: method,
      params: params,
    }),
  })
  let data = await response.json();
  return data;
}

So sometimes it returns
{
  error: { code: -42002, message: "INVALID PARAMS" },
  id: "1",
  jsonrpc: "2.0",
}

And then I get TypeError: "can't convert undefined to object" because it calls Object.keys on res.result which is obviously undefined.

Fixed in #49 (in ed25519 branch instead of master though)


Fixing Syntax Error on Persistent Menu Example

This fixed the syntax error caused by a single quote on the persistent menu example.

Whoops! Thanks!


feat(keys): add an optional name support for keys:add

This arg can be used interchangably with the key arg to keep backwards compatibility
That allows a user to do deis keys:add ~/.ssh/secret.pub and the name is detected or keys:add magic ~/.ssh/magic.pub or deis keys:add travis and then get the choice list to pick from
Closes #256

Current coverage is 72.23% (diff: 61.53%)

Merging #257 into master will decrease coverage by 0.05%

@@             master       #257   diff @@
==========================================
  Files            57         57
  Lines          3905       3915    +10
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           2823       2828     +5
- Misses          773        777     +4
- Partials        309        310     +1

Powered by Codecov. Last update 1fb144c...0fbef1a


Working Vagrant setup additions

Updated the gitignore to exclude (Vagrant stuff & logs)
Added 'therubyracer' to the gemfile

LGTM! :+1:


add support for SSL credentials reloading on server

update C-core library to allow the user server application to optionally configure the server such that the C-core library will call back into the user application on every new client TCP connection (to the secure port) so that the user server application can (optionally) specify new TLS credentials to use for that client.
fix issue #10528

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

fyi @justinburke i've merged with your https://github.com/grpc/grpc/pull/12359/ before creating this PR

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

fyi @justinburke i've merged with your https://github.com/grpc/grpc/pull/12359/ before creating this PR

hmm i guess i didn't do a clean merge? looks like my 6 original commits were duplicated. i should do a squash? also, @justinburke you have commit access to my repo so feel free to make any changes or let me know what changes to make :) thanks!

closing this one as @justinburke will be creating a separate PR


[SPARK-40884][BUILD] Upgrade fabric8io - kubernetes-client to 6.2.0

What changes were proposed in this pull request?
Upgrade fabric8io - kubernetes-client from 6.1.1 to 6.2.0
Why are the changes needed?
Release notes
Snakeyaml version should be updated to mitigate CVE-2022-28857
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass GA

@dongjoon-hyun

Can one of the admins verify this patch?

ok to test

Can one of the admins verify this patch?

Merged to master


Trust Apple's status for validity check

Resolves #6137 if using --skip_certificate_verification
This PR moves the certificate_valid? check to after the check for skip_certificate_verification.

Why does moving the method call solve the problem?

It doesn't solve the problem entirely, however it does more accurately follow the flag --skip_certificate_verification, by not verifying the certificates if the flag is true.

Closing as the original issue was fixed

Yeah 👍


Upgrade to camel-kamelets 0.5.0

@davsclaus  Could not find camel-kamelets-catalog 0.5.0 in maven repo https://repo.maven.apache.org/maven2/org/apache/camel/kamelets/camel-kamelets-catalog

Ah it will come when camel-k 1.7.0 is released

0.5.0 has been released

Fixed in https://github.com/apache/camel-karavan/pull/93


Update QueryBuilder.php

This fix update issue with  ArrayExpression. If you did update record, ArrayExpression was not populated as array but like ArrayExpression.
Issue was with postgresSql and array column.

Q
A

Is bugfix?
yes

Duplicates 15732


devstack: added option to unstack helping in cleaning up after execution

https://review.openstack.org/#/c/450207/
https://review.openstack.org/#/c/23689/1/lib/swift

It takes around 70 secs to unstack on my local setup. So I am not sure we are increasing the loads on the system.

alternative fix: https://github.com/SUSE-Cloud/automation/pull/2048

closing in favor of https://github.com/SUSE-Cloud/automation/pull/2048
But please feel free to reopen if you prefer this PR.


Add that Blobfuse is not supported on Ubuntu 22.04

@jaypatel-37 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

IMPORTANT: When this content is ready to merge, the reviewer must add #sign-off in a comment or the approval may get overlooked.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

I moved to different team. Please reach out to Rob Futrick for Document review/approval.

@JnHs - can you take a look?  I can't assign @rfutrick
#assign: @JnHs

@JnHs - can you take a look? I can't assign @rfutrick
#assign: @JnHs

I'm no longer working on Batch - @lauradolan should review this one!

#assign:Padmalathas

@Padmalathas - please confirm with @harperche that this update is accurate.

#un-assign @prkannap
#assign @harperche
Harper Cheng is the new PM and Preetha has moved to a new team.

@Padmalathas @harperche - I will merge this. Can you follow up with a PR in the private repo that adds 2 lines to the metadata - an author and an ms.author with accurate values.
Example:
author: harperche
ms.author: harpercheng

cc: @lauradolan


Install util-linux to have lsblk binary

This addresses #420

/cla-signed

/lgtm
/approval

/approve

/ok-to-test

@xueweiz any estimates when there is a new release of NPD ?

@Random-Liu Do we have plan to release NPD any time soon?

By the way, if the release is blocking you from picking up the fix, you could consider build a docker image on top of the released NPD image, and install lsblk in it. Please let me know if this still cannot unblock you.

Yes of course i will do if a release of NPD will take several weeks, but if its in the foreseeable future i will wait.

I guess we might wait for a while before doing the next NPD release, because there are not many major features/fixes recently.


the code is hard to edit without getting conflicts

People should be aware that we're using prettier to format the code now.
I am getting several conflicts every time i try to merge some changes, therefore the code should be cleaned and everyone else should run yarn precommit or equivalent before pushing code.
I suggest we don't accept pull requests that don't come in formatted

keeping this open for a while so that people can see it

ill start doing this now 👍

Does this affect code changes being pushed through github's web interface?


BackgroundMode plugin is not installed with cordova v9 (& ionic 4/5)

After upgrading from cordova v8.1.2<EMAIL_ADDRESS>→ v9.0.0<EMAIL_ADDRESS>log shows following warnings when i use the plugin:
console.warn: Ionic Native: tried calling BackgroundMode.isEnabled, but the BackgroundMode plugin is not installed.
console.warn: Install the BackgroundMode plugin: 'ionic cordova plugin add cordova-plugin-background-mode'
console.warn: Ionic Native: tried calling BackgroundMode.isActive, but the BackgroundMode plugin is not installed.
console.warn: Install the BackgroundMode plugin: 'ionic cordova plugin add cordova-plugin-background-mode'
console.warn: Ionic Native: tried calling BackgroundMode.on, but the BackgroundMode plugin is not installed.
Seems like plugin is not 'detected' anymore.
I use ionic-cli v4.12.0 & v5.0.1 with node.js v8.11.4 (on mac OSX 10.14.5). The project itself is a ionic v3 project. Actually i use cordova-plugin-background-mode version: 4c157f450983f44e42edcb4cdcb7a57a301c19b4 (= commit of Feb 3, 2019). If i use the latest version i do not get errors, but background mode never gets activated.
If i downgrade cordova to v8.1.2 and reinstall packages everything works again.

I have the same problem

+1

same issue

I manager to make it work. cordova platform remove android then cordova platform add android


add msCrypto, Map, Set, WeakMap declaration

Create additional declaration for msCrypto, also add declaration for collections to avoid compilation error

Also, I have already signify CLA

:+1:


isort gives different results when executed twice

Hey,
First of all thanks for the excellent tool!
Consider this file:
'''
See README.md for usage.
'''
import os

#===============================
# Ask
#===============================
import io

def Ask(question, answers):
    pass

Executing isort the first time, this diff is produced:
$ isort foo.py

diff --git a/foo.py b/foo.py
index eb0e13a..c6fd800 100644
--- a/foo.py
+++ b/foo.py
@@ -1,12 +1,11 @@
 '''
 See README.md for usage.
 '''
-import os
-
 #===============================
 # Ask
 #===============================
 import io
+import os

Which looks good.
However, isort produces a different diff when executed again:
diff --git a/foo.py b/foo.py
index c6fd800..17f208f 100644
--- a/foo.py
+++ b/foo.py
@@ -1,10 +1,11 @@
 '''
 See README.md for usage.
 '''
-#===============================
+
 # Ask
 #===============================
 import io
+#===============================
 import os

Executing it more times after that no longer produces a difference.
Is this a bug? Perhaps I'm missing some config option?

odd, it looks like if there are more than 2 commented out lines above an import statement they are being moved down.

Yes, seems like it.

The bug is on this line:
https://github.com/timothycrosley/isort/blob/develop/isort/isort.py#L842
I strongly suspect that changing  "greater than " to "greater than 0" would fix this issue
However this line was added in this commit: f157b06c61e6b77cc2c0d38710ab974d044cec02 and I do not understand why.

Thanks for the investigation. Perhaps @timothycrosley would like to comment?

I have sent a pull request with a comment - We will let tim decide.

Cool, thanks! :grin:

Closing as this as had a pull request, that fixes this issue, thanks!
~Timothy


change has_key deprecated function to in operator

dict.has_key('key') is deprecated in favour of in operator. This pull request changes those instances.

Thanks for you commiting for the depency of Kaldi.


WebcamActiveSensor always True (Logitech C920 / Win 10 19042.804)

Just fired up HASS Workstation Service for the first time hoping to utilize the webcam/microphone sensors.
The MicrophoneActiveSensor seems to work.  It's false, then I open OBS Studio, and it goes to true.
However, the WebcamActiveSensor is true no matter what.  Windows camera settings confirms that nothing is using the camera.
Not sure what I should try.
If this worked I was going to slowly switch over from IoTLink but I'm stuck on the webcam sensor.
Thanks!

Hi!
The same thing happened to another user a while back and this worked for them:
A registry key may be incorrectly set. Try removing the keys under Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\webcam and Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\webcam one by one.

Right on!  That worked!  Thanks for the quick reply, and sorry I failed to find that on my own if it's already been asked.
This is great!

No worries. The answer could only be found on the Discord and that doesn't really make sense. Enjoy!