Seg fault when calling .new_usertype

Sadly I cannot get simple test case to showcase this issue, and I've tried for a while to reproduce this bug, but it seems to be specific to something my code is doing.
When calling .new_usertype on an object I get the following error: http://pastebin.com/B9csA8Gm
The code is question is:
void LuaScript::defineObject(sol::state& lua) {
	lua.new_usertype<Object> (
		"Object", sol::constructors<
				sol::types<Map*, float, float, Stats, int>>(),
		"getX", &Object::getX,
		"getY", &Object::getY,
		// Object methods
		"contains", &Object::contains,
		"applyStat", &Object::applyStat,
		"setStats", &Object::setStats,
		"getSpeed", &Object::getSpeed,
		"getRange", &Object::getRange,
		"setRange", &Object::setRange
	);
}

LuaScript::defineObject(sol::state& lua) is called from LuaScript::defineClasses(sol::state& lua):
void LuaScript::defineClasses(sol::state& lua) {
	defineObject(lua);
	defineEnemy(lua);
	defineTarget(lua);
	defineMap(lua);
	defineStats(lua);
	definePerk(lua);
}

LuaScript::defineClasses is a static method called by the constructor of a Console:
Console::Console()
	: _cursorPos(0) {

	_lua.open_libraries(sol::lib::base, sol::lib::package, sol::lib::table);

	LuaScript::defineClasses(_lua);

	-- snip --
}

Commenting out LuaScript::defineClasses(_lua); in Console makes the seg fault go away, but LuaScript::defineClasses is still called from other locations, and doesn't cause a seg fault when its called from other places.
The program used to create this bug can be found here: https://github.com/hdt80/Augmentum/tree/bug.
This happens on both my Windows (using MinGW g++) and Linux machines (Using both g++ and clang++).
Other info
sol version: Most recent (2.15 - 010b6bb)
Windows compiler: g++ (x86_64-posix-seh, Built by MinGW-W64 project) 6.1.0
Linux compiler: g++ (GCC) 6.2.1 20160830 and clang++ clang version 3.9.0
Lua: 5.3.3 (Version number 503)
If there is any other information I could provide let me know and I'll get back to you as soon as possible.
Thanks for your help!

Because I have to essentially pull and figure out how to build Augmentum, this is going to take me a while to do and I probably won't get around to it in my usual 24-hour turn-around time.

Understandable, thank you for being willing to do that. If there's anything I can help with let me know.

I believe this happens due to the static initialization order fiasco. By refactoring my code to use the Construct on First Use Idiom I'm able to get rid of the seg fault happening. Thanks you for being willing to help me!


Carousel minimal example: images not showing up

Hello.
I'm trying the Carousel (copy & paste the minimal example from flowbite-react doc) and I cannot see any images...
I see the buttons and the slides getting triggered... Images are urls as in the doc and I tried with local ones two...
Any idea where that could come from ?
React, Vite setup, TailwindCSS and flowbite installed and configured without any deviation... (the rest is working)
I'm into that urgent deadline. And I would greatly appreciate it if anyone has any idea on that one... Thanks+++
PS: I'm refering to flowbite-react, but I'm hoping to find some help here with this regular issue.
I filed a bug on the correct GH just in case https://github.com/themesberg/flowbite-react/issues/799

Same here..

@tomaszgrabowski
I found a trick that worked for me and posted it there https://github.com/themesberg/flowbite-react/discussions/801. Hopefully this can help you too.
Yet I don't get why I'm having this issue and some people apparently don't (see discussion overthere, codepen exemple and so on... If you're facing the same issue, you can confirm it there too, maybe this will help to understand what's happening and what's not specific to me).
Marc

@tomaszgrabowski I found a trick that worked for me and posted it there themesberg/flowbite-react#801. Hopefully this can help you too. Yet I don't get why I'm having this issue and some people apparently don't (see discussion overthere, codepen exemple and so on... If you're facing the same issue, you can confirm it there too, maybe this will help to understand what's happening and what's not specific to me). Marc

It worked for me. Thank you very much!

try adding this to your tailwindcss config file content array: "./node_modules/flowbite/**/*.js"

@tomaszgrabowski I found a trick that worked for me and posted it there themesberg/flowbite-react#801. Hopefully this can help you too. Yet I don't get why I'm having this issue and some people apparently don't (see discussion overthere, codepen exemple and so on... If you're facing the same issue, you can confirm it there too, maybe this will help to understand what's happening and what's not specific to me). Marc

Wrapping the carousel in a div with height and width should have this fixed...


Possible edge case in decoder when very first OP is QOI_OP_RUN

There's an edge-case that currently is handled differently by various decoders. At a first glance it looks like this decoder may not be spec-conformant. The spec is not clearly worded in this case, but I have decided to interpret it in a particular way now. Sorry about that!
Please see the original issue here https://github.com/phoboslab/qoi/issues/258 for the details.

Hi, this shouldn't be hard to fix. Just add the starting pixel color to the index array.
I have a a question for @phoboslab though:
Does the spec allow the encoder to start with a run operation? You mentioned you never do that in the reference encoder, but other encoder may do.
@aldanor If that's an acceptable solution, I can open a PR in the coming days. Also, I have a few specific questions about the implementation of the encoder / decoder. How can I reach out?

Yes; should add the edgecase.qoi to the current test suite and see what happens. Should be an easy fix if it's misinterpreted.

I wrote a test that reads edgecase.qoi and decodes it and works as intended.
I still need to debug the decoding process though, I am not sure when it puts the initial opaque black pixel in the seen array.


add_epochs for large number of initial epochs

I need to add a large number of epochs (> 2,500) to a SpatiotemporalAnalysis object for the extraction of 4D objects-by-change. Adding them one by one takes too much time, due to rearranging of the array (known behavior): at the 500th epoch rearranging takes already 180 s.
As all epochs are already available (no online acquisition and analysis), I can add all epochs, by compiling a list of all generated epochs:
# loop over epochs and add (except the reference epoch)
epoch_batch = []
for idx, row in df_timeseries.iterrows():
    fname_cloud = row['fname_timestring']
    if fname_cloud == fname_reference_cloud:
        continue
    subdir_daystring = fname_reference_cloud.split('_')[0]
    f_cloud = f'{data_dir}/{subdir_daystring}/{fname_reference_cloud}.laz'

    trafomat = read_corresponding_trafofile(f_cloud)
    cloud = read_las(f_cloud, trafomat = trafomat)

    epoch = py4dgeo.epoch.as_epoch(cloud)
    epoch.timestamp = row['timestamp']

    epoch_batch.append(epoch)

    #if idx > 5:
    #    break

analysis.add_epochs(*epoch_batch)

The question/issue has become obsolete. I am here posting the result for documentation and potentially future considerations:
WORKING SOLUTION:

Not all 2,967 epochs can be loaded into working memory, so I am loading batches of 500 epochs (depends on available RAM and size of point cloud epochs)
Each batch of epochs is the added to the analysis object, leading in this example to six add_epochs operations, i.e. six times costly rearranging of the array

THE CODE:
# loop over epochs and add (except the reference epoch) [num_epochs = 2967]
batchsize = 500
b = 0
epoch_batch = []
num_epochs = len(df_timeseries)
for idx, row in df_timeseries.iterrows():
    print(f'Compiling epoch [{idx}/{num_epochs}]')
    fname_cloud = row['fname_timestring']
    if fname_cloud == fname_reference_cloud:
        continue
    subdir_daystring = fname_reference_cloud.split('_')[0]
    f_cloud = f'{data_dir}/{subdir_daystring}/{fname_reference_cloud}.laz'

    trafomat = read_corresponding_trafofile(f_cloud)
    cloud = read_las(f_cloud, trafomat = trafomat)

    epoch = py4dgeo.epoch.as_epoch(cloud)
    epoch.timestamp = row['timestamp']

    epoch_batch.append(epoch)

    b+=1

    if b%batchsize == 0:
        print('Adding batch of epochs...')
        analysis.add_epochs(*epoch_batch)
        epoch_batch = []

THE OUTPUT:

first batch: 146.0912s

[2022-06-18 10:39:57][INFO] Finished in 0.4481s: Adding epoch 500/500 to analysis object
[2022-06-18 10:39:57][INFO] Starting: Rearranging space-time array in memory
[2022-06-18 10:42:23][INFO] Finished in 146.0912s: Rearranging space-time array in memory
[2022-06-18 10:42:23][INFO] Starting: Updating disk-based analysis archive with new epochs

second batch: 343.0534s

[2022-06-18 10:47:31][INFO] Finished in 0.4425s: Adding epoch 500/500 to analysis object
[2022-06-18 10:47:31][INFO] Starting: Rearranging space-time array in memory
[2022-06-18 10:53:14][INFO] Finished in 343.0534s: Rearranging space-time array in memory
[2022-06-18 10:53:14][INFO] Starting: Updating disk-based analysis archive with new epochs

third batch: 583.9803s

[2022-06-18 10:58:44][INFO] Finished in 0.4561s: Adding epoch 500/500 to analysis object
[2022-06-18 10:58:44][INFO] Starting: Rearranging space-time array in memory
[2022-06-18 11:08:28][INFO] Finished in 583.9803s: Rearranging space-time array in memory
[2022-06-18 11:08:28][INFO] Starting: Updating disk-based analysis archive with new epochs
[2022-06-18 11:08:30][INFO] Finished in 1.2582s: Updating disk-based analysis archive with new epochs

fourth batch: 854.3708s

[2022-06-18 11:14:03][INFO] Finished in 0.4668s: Adding epoch 500/500 to analysis object
[2022-06-18 11:14:03][INFO] Starting: Rearranging space-time array in memory
[2022-06-18 11:28:18][INFO] Finished in 854.3708s: Rearranging space-time array in memory
[2022-06-18 11:28:18][INFO] Starting: Updating disk-based analysis archive with new epochs
[2022-06-18 11:28:20][INFO] Finished in 1.8058s: Updating disk-based analysis archive with new epochs

Fifth batch (>2000) epochs cannot be added:
File H:\conda_envs\py4dgeo_dev\lib\site-packages\py4dgeo\segmentation.py:384, in SpatiotemporalAnalysis.add_epochs(self, *epochs)
    380     # Load the uncertainty array and append new data
    381     uncertainty_file = os.path.join(tmp_dir, uncertainty_filename)
    382     write_func(
    383         uncertainty_file,
--> 384         np.concatenate(
    385             (self.uncertainties, np.column_stack(tuple(new_uncertainties))),
    386             axis=1,
    387         ),
    388     )
    390 # Dump the updated files into the archive
    391 with logger_context("Updating disk-based analysis archive with new epochs"):

File <__array_function__ internals>:180, in concatenate(*args, **kwargs)

MemoryError: Unable to allocate 66.4 GiB for an array with shape (709791, 2512) and data type [('lodetection', '<f8'), ('spread1', '<f8'), ('num_samples1', '<i8'), ('spread2', '<f8'), ('num_samples2', '<i8')]

I have done similar studies where I added constant size batches of epochs and observed dramatically increasing processing times due to the rearranging in memory. I will try to check whether np.concatenate/np.column_stack does something inefficient here by trying a C++ implementation of the rearranging step.

As far as the out-of-memory issue is concerned: Uncertainties take 5 times more memory than distances. As you did not store them in your previous code base, you might not be able to process the same datasets with py4dgeo (on the same machine). Not sure what can be done about that - unless storing the uncertainties is not a requirement.

That makes sense... but it is right to store the uncertainties, even if they are not always required for an analysis step.
(A) Maybe when the memory policy is set to "MINIMAL" the arrays can be loaded and extended separately? This increases the capacity - because for 4D-OBC extraction at the moment we only use the distances (in the future will be an option to include uncertainties).
(B) As a general issue of handling the huge 3D time series:
I guess we need an option to perform the analysis for a part of the data, e.g. by defining a timespan. Thinking on long-term monitoring, we will add evermore epochs but analyze looking back only a certain timespan (not always the full period since start).

I tried a C++ implementation of the rearranging step and it turns out to not be a significant improvement over the status quo. Closing this now.


feature request: Proof verifier in Solidity

perhaps non trivial :stuck_out_tongue_winking_eye:

Once we get this pr merged, we should just be able to generate a Solidity verification circuit from the circom! The issue is that its between 200-300k gas, but hopefully with things like SnarkPack/zk rollups, that can be made lower.


Remove link to blog from footer

The Digital Marketplace blog has been decommissioned.

 Remove blog link from footer template


Remix - No matching export for import "randomUUID"

Hi, I've run into trouble while trying to set up hello world example as a background job in Remix.
Whenever I try to run the server, it crashes with the following error:
No matching export in "../../node_modules/esbuild-plugin-polyfill-node/polyfills/empty.js" for import "randomUUID"
dev:
dev:     ../../node_modules/@defer/client/esm/index.js:2:9:
dev:       2 │ import { randomUUID } from "crypto";

Any idea why?
Thanks!

Hi @piotrkulpinski,
Thanks for reporting this problem!
It seems to be an issue related to Remix bundler: https://github.com/remix-run/remix/issues/6284
We'll watch the improvements closely on their side 👀

I've released the 1.5.0-alpha-20230615080921-44b91f9 canary version, which no longer relies on the native crypto NodeJS module. Can you confirm that it fixes the issue on your side?

Yup, 1.5.0 fixed the issue for me.

Thank you, @piotrkulpinski, for your feedback. I will conduct further tests to ensure that there are no issues. Once the testing is complete, I will release this version as stable.

This issue has been fixed in 1.5.0: https://github.com/defer-run/defer.client/releases/tag/v1.5.0


azure Key Vault:how do delete latest version of secret using Azure CLI

Azure Key Vault:how do delete latest version of secret using Azure CLI
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior.
Expected behavior
A clear and concise description of what you expected to happen.
Environment summary
Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)
Additional context
Add any other context about the problem here.

az keyvault secret delete -h
    az keyvault secret delete : Deletes a secret from a specified key vault.
        The DELETE operation applies to any secret stored in Azure Key Vault. DELETE cannot be
        applied to an individual version of a secret. This operation requires the secrets/delete
        permission.

any plans to give this functionality using Azure CLi.because we can delete specific versions using web interface?

@schaabs

@abhiramani-iptiq Key Vault does not support deleting specific versions of secrets by any means.  Even in the portal if you select a specific version and click delete, it will still prompt that it will delete all versions.

There are no plans to support deletion of individual versions of a secret at this time.

Can you explain why there are no plans to allow cleaning out old and no longer used secrets?

Keeping old versions of secrets stored can even be a security issue.

Looking forward to a concrete explanation and solution for it from 2021... It makes no sense why we cannot remove those deprecated secrets.

This seems like an obvious feature which has several useful applications -- for example, if credentials accidentally got entered into the wrong field where they are available to users who should not have access to them. Right now, the only workaround is to delete the entire secret (all versions) and then recreate it. I agree that the Azure team should provide a specific explanation for why they refuse to implement this request.

@schaabs Any update on this one. Are you guys re-considering this request?

Upvote. This feature seems obvious given that you can access different versions of a secret.
I planned a solution to sync KV secret rotation and deleting the last version would be very handy as a rollback operation in case the synchronization failed.

Almost 4 years later and this is still an issue.  WHY hasn't this been addressed yet?

Still an issue

Use import as a workaround. Download the previous version you wish to make "current", then import it.

Use import as a workaround. Download the previous version you wish to make "current", then import it.

That is not a work around.  You can't remove the old secrets unless you completely delete the cert entry and enter it again.

We need this feature to permanently delete the old version of the secret. Not sure, its been so long why it is not addressed yet ?

in my case, I accidentally created a new version using the wrong value and my only option now is to disable the wrong version or create a new version with the correct value.  Ideally I just want to delete the wrong version only.. but as I can see this is not possible.  Upvote to have this functionality.

mid 2023 and still not addressed

end 2023. we are still waiting

Honestly, Microsoft should be embarrassed at this point. Why even have versioning if it's just a means for cruft to collect? Honestly, who is making these decisions? Can we send them back to whatever non-technical role they came from?

nearly mid 2024 and still not addressed, this issue was raised 5½ years ago!

Based on my experience, setting a key to being disabled, removes the possibility of "Get"ting it nor recovering it, effectively purging the secret version. But, do correct me if I'm wrong.

Here is another major issue without the ability to delete certificates from the keyvault entry - There are times when a junior admin uploads a new certificate into the incorrect certificate listing in the keyvault, for example, they upload the certificate for example.com into the test.com keyvault entry.  Now when using things like Azure Front Door, AFD will automatically try to use the latest certificate and if that certificate that was incorrectly uploaded is the newest certificate, AFD will continue to try to use that cert if possible.  If you disable that cert, AFD will show that the keyvault is inaccessible.  Microsoft NEEDS to make a way to be able to delete these certificates besides having to delete the entire entry and recreate it.


Rename default names

I renamed default names so understanding code is a bit easier

Thanks for the contribution! :)


ORIGINAL EXCEPTION: Cannot read property 'filter' of undefined

it is not working in mdDialog box

Can you share snippet where you have imported the module as filter undefined error comes when you have either wrongly imported the module or have not imported.

I think your issue got resolved so i am closing this issue for now but you can reopen in future if required.


Default NIC model_type virtio is not being setted when attach new NIC to the VM

Description
When you instantiate a new VM with a given number of NICs or just one, and you dont specify the model type, Opennebula is configured to set by default to use virtio. This works when the VM is instantiated, but not when you add NICs after being instantiated, without specify the emulated model type of the NIC, which should relay on the default driver (virtio). Instead of this, the new NIC is configured for driver RTL-8100/8101L/8139 PCI fast Ethernet Adapter (rev 20), in other words, Realtek.
Issue confirmed for OpenNebula clusters running in 6.8.1 and 6.8.2.

To Reproduce
Create a new VM. After created, add a new NIC Verify the PCI devices on the VM with lspci.
Expected behavior
Added a new NIC using virtio driver, as configured by default.
Details

Affected Component: [Network]
Hypervisor: [KVM]
Version: [6.8.1,6.8.2]

Additional context
Add any other context about the problem here.

Progress Status

[ ] Code committed
[ ] Testing - QA
[ ] Documentation (Release notes - resolved issues, compatibility, known issues)

Hi @Franco-Sparrow ,
I have found something curious:
https://github.com/OpenNebula/one/blob/1e23efbd622fe2e61bc63e143898e5b12c9e773b/src/vmm_mad/remotes/kvm/attach_nic#L55-L66
In the line 61 of the previews code, the environment  loaded is the local one, but I assume that this action must run in the host, so I believe that the function that needs to called is the load_remote_env.
I will do some test and i will back to you!
PD: This is not commonly used because only apply for day2 operations!

Thanks @nachowork90 🥇
Hi @rsmontero, this is a confirmed issue that is present since 6.6.x. Please, give it a chance to this. We have verified on clusters using 6.6.3, 6.8.1 and 6.8.2.
Regards

I just encountered the same error related to model name of NIC on the same ON version as mentioned by the OP. In my case, the issue is intermittent. I encountered the error while instantiating Windows VM, where it would not boot with a NIC attached when NIC = "virtio" attribute is added to the template. The VM logs throws  Model name has invalid characters error causing BOOT_FAILURE state. Removing the attribute from template works and the VM boots fine.
I'll try out your fix @nachowork90 and give feedback here. Thanks
Also, thank you @Franco-Sparrow for the bug report and @rsmontero for adding fix to next release.

So @Franco-Sparrow, changing to load_remote_env fixed for you?

Hi Sir @rsmontero
Yes, in my case I havent faced the issue that @ibrahimkahn explained, only when adding new nics and @nachowork90 's patch fixed the problem.

Thanks, fix is now merge. In the meantime @ibrahimkahn you can apply the patch manually to /var/lib/one/remotes/vmm/kvm/attach_nic and do a onehost forceupdate to propagate the changes.


[FEATURE] Requesting release of version 2.3.2

Is your feature request related to a problem?
Yes. I ran into the problem described in this issue, which was apparently resolved by this pull request; however, that code has not yet been released.
What solution would you like?
I'd like for the team to schedule a release of opensearch-py (presumably version 2.3.2) which incorporates this fix.
What alternatives have you considered?
I'm not sure what my other options are, other than maybe installing from a patched version of the source?
Do you have any additional context?
N/A

Releasing 2.3.2 would help OpenSearch-Benchmark with the following CVE-Risk

https://github.com/opensearch-project/opensearch-benchmark/issues/378


Support remove -Verbose

It would be useful if remove supports -Verbose in order in order to print
messages about removing existing and skipping missing items specified by Path.
Suggested here: https://github.com/nightroman/Invoke-Build/issues/123#issuecomment-476188945

Maybe also add some protections there while you are at it ?
$protected = $Env:WinDir, $Env:ProgramFiles, $Env:SystemDrive, ${Env:ProgramFiles(x86)}, $Env:USERPROFILE
$path = Normalize-Path....
if ($path -in $protected) { throw "Protected directory not cleaned: $path"}

Its very easy to clean wrong things if you add variables in paths...

Hmm... I think it's too much and not a common practice (Remove-Item is happy to kill whatever). The most typical scenario is using relative paths, I added some sanity checks for it (bare dots, asterisks, slashes).

v5.4.6


Circuit result object

What is the expected behavior?
Currently the experiment data only takes metadata and count from the returned data field.
https://github.com/Qiskit/qiskit-experiments/blob/fbe19dd01fbc8e572a27b8d9a06d1bed5a58f7da/qiskit_experiments/experiment_data.py#L176-L180
However, it also contains other useful information such as creg_size, meas_level, meas_return, etc... and these information can be consumed by the data processor. This free-form dict should be formatted as a data class or some dict-wrapper class (i.e. CircuitResult) so that we can guarantee these fields are extracted from the returned data.

This was changed during the transition to DbExperimentData


Trello X has been renamed to Xccello.

Seeing as url doesn’t point to a specific version, this cask should use version :latest and sha256 :no_check. See an example.
Also, please remove trello-x as well.

Fixed according to comment.

Thank you.

On another note, there must’ve been a PR template that auto-appeared when you opened the PR.
Next time, please fill it.


feat(payment): PI-1723 [KlarnaV2] Refactor the existing KlarnaV2 co…

…mponents in Checkout JS to use the new checkout payment integration JS API
What?
Move KlarnaV2 to a separate package
Why?
To use the new checkout payment integration API
Testing / Proof
Manually tested
Test coverage

@bigcommerce/team-checkout

Ideally, we should have e2e tests for all integration packages.
Could you please at least post a manual testing video for the payment method?

I added video from manual testing


313 - Release design system npm package version 1.1.0

What this PR does / why we need it:
This PR updates the package.json of the design system with the new version 1.1.0. @iqss/dataverse-design-system
Also I added some instructions to the README on how to publish a new version.
A part from that I added a preset to lerna so the CHANGELOG.md is automatically updated with the new commits since the last version. See Conventional Commits for commit guidelines.
Which issue(s) this PR closes:

Closes #313

Special notes for your reviewer:
The automation of the publishing will be developed in this other issue:

#140

The creation of a test registry will be developed in this other issue:

#144

Suggestions on how to test this:
To test the package:

Create a new React application. I'll go with the first option which is running npx create-next-app in your machine (ensure you have node installed in your machine)
In your app root folder run npm i to install all the packages of the demo app
Follow the instructions from the README of the package @iqss/dataverse-design-system
If you're using npx create-next-app then go to the src/app/page.tsx file
Place the imports at the top of the file with the other imports import { Col, Container, Form, Row} from "@iqss/dataverse-design-system";. If you are using next-js you'll need to set 'use client' at the top of the file since the design system components are client components
Now copy the example code in the usage section of the package README and paste it somewhere inside the  Home function of the src/app/page.tsx file
Run the application using npm run dev and go to http://localhost:3000 to see the application using the design system components

Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Is there a release notes update needed for this change?:
Published version 1.1.0 of the Dataverse Design System to the npm registry @iqss/dataverse-design-system
Additional documentation:
Lerna publishing

coverage: 97.179%. remained the same
when pulling 0552e737d07f0c2416f71c29613877f4e705a649 on 313-release-design-system-npm-package-version-120
into 0e902180f818928d3d578cecf2801c478d3c4592 on develop.


BUG: Pigeons complain couldn't broadcast signatures and process attestation

What is happening?

Section description
Provide as much context as you can. Provide relevant software versions, screenshots, copy & paste error messages and so on.
Give as much context as you can to make it easier for the developers to figure what is happening.

time="2022-08-29T16:41:03+02:00" level=error msg="couldn't broadcast signatures and process attestation" error="context canceled" message-ids="[56]" queue-name=EVM/eth-main/evm-turnstone-message signed-messages="[map[id:56 signature:[93 0 200 138 30 220 61 252 32 195 234 101 137 195 22 0 240 2 88 3 178 46 23 147 10 43 129 245 193 119 186 188 57 26 3 117 99 210 248 194 11 76 185 237 98 23 96 75 175 101 127 240 188 1 133 209 152 82 158 168 73 209 89 212 1]]]"
How to reproduce?

Section description
Please write detailed steps of what you were doing for this bug to appear.

Normal running pigeon
What is the expected behaviour?

Section description
If you know, please write down what is the expected behaviour. If you don't know, that's ok. We can have a discussion in comments.

signatures should broadcast without problems and valset updates should happen.

This is not a bug nor an error. The error is "context cancelled" which means that pigeon itself decided that it should stop processing its current context.

Thanks!


ADN-2170 hide button and show spinner while processing apple pay payment

The issue was fixed in another way. The code has been refactored.


[5.6] Add module kind enum to the package plugin API

SwfitPM 5.6 nomination of #4098.
Although the different basic kinds of targets were expressed through types, the module kind (executable, test, or regular) for a source module target was not expressed in the API.  This adds that property.
rdar://86786080
(cherry picked from commit b7c299105592451cde264b3965aa41f0bbc3c3fc)

@swift-ci please test

@swift-ci please test

@swift-ci please test


Hello ThalKod

Hello, The project has potential, I would like to test it mall. But I am still new in the "NodeJs", I have followed your instalation and get this here only

nodemon app.js

[nodemon] 1.18.9
[nodemon] to restart at any time, enter rs
[nodemon] watching: .
[nodemon] starting node app.js
(node:3015) DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect.
(node:3015) DeprecationWarning: collection.ensureIndex is deprecated. Use createIndexes instead.
listenning on 5000
Is that so ok? I can not see the page on my domain?
I'm sorry I'll take your time, and thanks in advance for your help :)

Are you trying it on port 5000?

Yes, it's normal, it should be running on http://localhost:5000

Oh okay, thanks. Work fine :)


tiltfile: swap order arguments to add()

also will open PRs to fix the syntax in all of our example apps.

Going to hold off on merging this until Monday.


Simplifying code on numpy_fast

Making if statement easier to read

This isn't really more readable, and the tests are failing.


Low accuracy of parameter estimation for SIR-FV and SEWIR-F model

Summary:
Accuracy of parameter optimization is high for SIR, SIR-D, SIR-F model (RMSLE scores are about 0.1), but that is low for SIR-FV and SEWIR-F model (RMSLE scores are about 30).
CovsirPhy version 2.2.1
Related classes:

covsirphy.SIRFV
covsirphy.SEWIRF

Codes:
Codes are in example/sirfv_model.py and example/sewirf_model.py
Environment:
Python 3.8, pipenv, WSL.

In SIR-FV model, S and V is not used for error calculation in parameter estimation. S + V should be used.

This solution failed.

This wil ne discussed in #275


add profile note

These are publically shown on info embeds on a server, can be used to leave important notes other mods that they really should see, or how awesome someone is, up to them

So, it can be private, only seen to some, but not everyone, or it can be open to everyone, correct?

that depends on the server, you'd require permissions to run !userinfo or !inf search to be able to see them
userinfo can be made public but isn't by default, so it would be up to the server to determine what they wana allow or not


applications on Windows

Can applications on Windows be updated to the latest version?

Hi @win10ogod, yes! Ollama on Windows supports automatic updates. A little blue icon will appear next to Ollama in the system status bar – just click on it and click "Restart" to update.


Entity: added mediaType/charset fields

The problem:
EntityDecoder interface is not consistent with EntityEncoder.
EntityEncoder returns an Entity, while EntityDecoder only accepts a Message[F].
This is problematic because it is not possible to decode arbitrary EntityBody using EntityDecoder even if you know its Media Type.
Also it is not possible to return different media types from one EntityEncoder.
Proposal:
Interface of Entity is changed - this change adds (optional) mediaType and charset fields, so now it is possible to specify what is inside the body.
EntityDecoder now accepts an Entity - however, there is overload for decode method that accepts a Message.
EntityEncoder doesn't have contentType and charset methods anymore - instead it returns an Entity with appropriate mediaType and charset.
P.S. Tests are not compiling now; I want to know what do you guys think about this change and then I'll fix it.

Thanks for this.  I'm too tired to give the code a review tonight, but I can give some kneejerk reactions.

I like the symmetry.

contentType and charset being static properties of the EntityEncoder help with static inference, and (I am pretty sure) is exploited by rho.  But keeping them static is bad for multipart, where the content type depends on the boundary in the value.  This is a longstanding trade-off.  It would be nice to find a solution that's better for multipart and not harmful to rho. /cc @zarthross

I've been tempted to make Entity a first-class type on Message.  Doing so has pros and cons.
a. There could be an entity implementation that knows it is sourced directly from a file, which would allow optimizations on several backends.
b. There could be an entity implementation that knows it's pure, and optimize some cases in things like retry and follow-redirect middleware.
c. An entity that tracked its own content-length could be smarter about stream transformations and remove the header -- or maybe even smartly update it.  It's easy to transform the stream and forget to adjust the length.
d. Letting an Entity manage its own payload headers could clash with the header collection on the message.  Who wins if we set a Content-Length in Message and also on the Entity?  (Message#withEntity already hints at this problem.)
e. All of those optimizations are possible if we had a richer set of implementations of Request and Response, but it would double the number of implementations of Message.

If we proceed like this, and not the more ambitious approach above, I think Message#withEntity needs to be made aware of these.

2\. `contentType` and `charset` being static properties of the `EntityEncoder` help with static inference, and (I am pretty sure) is exploited by rho

Maybe we could add def produces: Set[MediaRange] to EntityEncoder (to be symmetric with EntityDecoder.consumes?

As an addition to headers?  That would help with symmetry and not hurt static analysis, but increases the two-sources-of-truth problem and does nothing for the multipart problem.

Letting an Entity manage its own payload headers could clash with the header collection on the message.  Who wins if we set a Content-Length in Message and also on the Entity?

It's even worse - someone could call withEntity twice and headers will be duplicated.
Maybe we should distinguish Message headers from Entity headers, storing it in a different (private) fields and only merge them on Message#headers call?

Another problem with this design is that it hard to preserve mediaType on parameterized EntityEncoder.
For example, EntityEncoder.streamEncoder can't add proper mediaType to Entity because it needs to run stream first.
Not sure what to do about that.

Ok, I'm giving up on this. WIll try simpler approach.


Feature api files

This PR adds the possibility to retrieve scanned files from their sha256, through /files/<sha256>.
The doc has been updated, but as I am not very familiar with technologies used, regression tests still need to be updated.
In addition, it seems that the version of the API (/opt/irma/irma-frontend/current, which is a symlink to releases/20150623...) in the VM remained at commit ec772e92

True, latest vm on website is still in version 1.2.0, master is now in 1.2.1. Thanks for your PR.

merge as part of #97


internal/olm/installer: prepend 'v' to semvers >= 0.17.0

Description of the change: prepend v to semver strings passed to olm subcommands
Motivation for the change: OLM versions now have a v prefix.
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[ ] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[ ] Add or update relevant sections of the docs website in website/content/en/docs

/cherry-pick v1.1.x

/cherry-pick v1.0.x


Add eq, ne, gt, ge, lt, le in DataFrame and Series

Codecov Report

Merging #476 into master will decrease coverage by 0.11%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #476      +/-   ##
==========================================
- Coverage   93.33%   93.21%   -0.12%
==========================================
  Files          29       29
  Lines        3780     3802      +22
==========================================
+ Hits         3528     3544      +16
- Misses        252      258       +6

Impacted Files
Coverage Δ

databricks/koalas/missing/frame.py
100% <ø> (ø)
:arrow_up:

databricks/koalas/missing/series.py
100% <ø> (ø)
:arrow_up:

databricks/koalas/series.py
92.26% <100%> (+0.26%)
:arrow_up:

databricks/koalas/generic.py
94.02% <100%> (ø)
:arrow_up:

databricks/koalas/frame.py
95.04% <100%> (+0.03%)
:arrow_up:

databricks/conftest.py
92.85% <0%> (-3.58%)
:arrow_down:

databricks/koalas/utils.py
97.29% <0%> (-2.71%)
:arrow_down:

databricks/koalas/namespace.py
88.46% <0%> (-1.29%)
:arrow_down:

Continue to review full report at Codecov.

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

Thanks, @ueshin


Fix c compiler warning

Everytime we build conmon we get the following warnings.
STDERR:
cmsg.c: In function ‘sendfd’:
cmsg.c:58:9: warning: missing braces around initializer [-Wmissing-braces]
struct iovec iov[1] = {0};
^
cmsg.c:58:9: warning: (near initialization for ‘iov[0]’) [-Wmissing-braces]
cmsg.c: In function ‘recvfd’:
cmsg.c:104:9: warning: missing braces around initializer [-Wmissing-braces]
struct iovec iov[1] = {0};
^
cmsg.c:104:9: warning: (near initialization for ‘iov[0]’) [-Wmissing-braces]
This patch fixes these warnings.
Signed-off-by: Daniel J Walsh<EMAIL_ADDRESS>
- What I did
- How I did it
- How to verify it
- Description for the changelog

is this GCC 8? btw, LGTM

/test all

LGTM


Can't see source of Native Stored Procedure in Db2 for z/OS

Description
Trying to see source of Db2 Native Stored procedure.  Getting back message "Source code is not available".
Exactly the same message when trying to use "Generate DDL".
DBeaver Version
Community Edition 24.0.2
Operating System
Windows 10
Database and driver
DB2 for z/OS V12.  Db2 Connect driver <IP_ADDRESS> .
Steps to reproduce

Click right mouse button on any Stored Procedure, then select "View Procedure". "Source" tab has an empty screen with "Source not available" message displayed.
Click "Generate SQL" -> DDL -  see the same error message.

Additional context
No response

@PavelDG We currently don't have any query to read DDLs of DB2 for zOS procedures. Could you please provide it, so we can try implementing it in DBeaver?

Here is a query that returns source of stored proc and various stored proc parms:
SCHEMA - schema name, NAME - proc name, BODY - source of StoredProc
SELECT
r.SCHEMA,
r.NAME,
r.SPECIFICNAME,
r.RESULT_SETS,
r.PARAMETER_CCSID,
r.EXTERNAL_NAME,
r.LANGUAGE,
r.SQL_DATA_ACCESS,
r.PARAMETER_STYLE,
r.DETERMINISTIC,
r.FENCED,
r.DBINFO,
r.COLLID,
r.WLM_ENVIRONMENT,
r.ASUTIME,
r.STAYRESIDENT,
r.PROGRAM_TYPE,
r.EXTERNAL_SECURITY,
r.MAX_FAILURE,
r.RUNOPTS,
r.COMMIT_ON_RETURN,
r.SPECIAL_REGS,
r.NULL_CALL,
IFNULL(IFNULL(s.CREATESTMT, r.TEXT),'') AS BODY FROM
SYSIBM.SYSROUTINES r
LEFT JOIN SYSIBM.SYSROUTINES_SRC s
ON r.SCHEMA = s.SCHEMA AND
r.NAME = s.ROUTINENAME WHERE
r.ROUTINETYPE = 'P' AND
UPPER(r.SCHEMA) = 'Schema_Name' AND
CAST(HEX(r.PARM_SIGNATURE) AS VARCHAR(180)) = UPPER('') AND
UPPER(r.NAME) = 'Proc_Name'

Thank you. It helps a lot


RAM Register for ESS Grid SetPoint

Hi Yves,
And thanks for your work. I am struggling to command the electricity injection with MK2 with the ESS mode activated on the inverter. On your soft, you write a setpoint on RAM ID 129, but on my side, after trying, it seems to be on ID 131. Where did you get the information about RAM ID description ?
FYI RAM ID 136 is the maximum PV Feed IN (in Watt).
Also, without Venus-OS device connected, the Ve.Bus device goes into "Pass-Thru" mode after 4 min. Any idea which register is needed to maintain the Inverter ON ?
Thanks a lot in advance
Best regards

Hi @Danakil23 !
Yes you're right, on some inverters it's 129 and on others 131, apparently. I also posted about it here: https://community.victronenergy.com/questions/129947/problem-implementing-the-example-364-from-the-ess.html?childToView=171312#comment-171312
I got the RAM ID from the Victron documentation and for the small multiplus it was correct.
In the code I made a change to first discover the ESS RAM Id before writing to it, haven't pushed it yet to github but I'll do soon.

mk2ess.go
type Mk2ESS struct {
	mk2            *Mk2
	assistantRamID uint16
}

// ESSInit searches for the ESS Assistent in RAM
// if not found returns with error.
func ESSInit(ctx context.Context, mk2 *Mk2) (*Mk2ESS, error) {
	// 200 is arbitrary chosen upper bound.
	// should be corrected if information is available.
	for i := 128; i < 200; i++ {
		log.Debug().Int("ramID", i).Msg("probing ramid")
		low, high, _, _, err := mk2.CommandReadRAMVar(ctx, byte(i), 0)
		if err != nil {
			return nil, fmt.Errorf("failed to enumerate ESS assistent ram records: %w", err)
		}
		if high == 0x0 && low == 0x0 {
			log.Debug().Msg("found end of ramIDs in use")
			break
		}

		assistantID := (uint16(high)<<8 | uint16(low)) >> 4
		log.Debug().Int("assistantID", int(assistantID)).Msg("id")
		if assistantID == 5 {
			return &Mk2ESS{
				mk2:            mk2,
				assistantRamID: uint16(i),
			}, nil
		}

		// this is not the ESS record, jump to next block
		i += int(low & 0xf)
	}

	return nil, fmt.Errorf("ESS RAM Record not found")
}

func (m *Mk2ESS) SetpointSet(ctx context.Context, value int16) error {
	log.Info().Int("value", int(value)).Int("record", int(m.assistantRamID)).Msg("write setpoint")
	return m.mk2.CommandWriteRAMVarDataSigned(ctx, m.assistantRamID+1, value)
}

I can't say anything about Venus-OS, so far I was operating the Multiplus just with my program directly. You probably know already that you have to keep sending to the ESS RAM-Register (something between 5-30s, don't know exactly). This is what the ess-static command is for.
Thanks for mentioning the PV Feed-IN. Generally interesting would be to document the RAM-Identifier (the length-and ID field before the fields). Maybe you could share all your RAM IDs values similiar to what I did in the forum?
Best regards, yves

Hi @yvesf,
What a nice piece of code to detect the grid setpoint RAM ID ! Thanks
About my problem, that the inverter goes into "Pass Thru" mode, i found out it was because of a "low battery voltage" alarm (even tho my voltage was above the cut-off voltage). It seems that the ESS assistant has a problem in a calculation of the sustain voltage + restart voltage without Venus OS running (I used a venus OS in parallel of the RS485, to check what RAM was used). For now, I just dropped the sustain voltage to a very low value and the problem disappear, but I'll investigate further later.
One last question: On what documentation did you find the setpoint RAM ID ? On my side I used the "Interfacing with VE.Bus products - MK2 protocol" and it describes RAM ID up to ID 19 only. Also I asked Victron directly about how to manage grid setpoint and they refuse to give me the solution, for them it's only allowed through Modbus-TCP.
Best regards

@Danakil23 https://www.victronenergy.com/live/ess:ess_mode_2_and_3

Writing the set point with +200 Watt:
We should write RAM ID 129 to +200. Writing requires 2 frames, one frame specifying the ID to write and one frame specifying the data to write.


fix logic when infinite = false

The current version will still loop from one end of the slideshow to the other, even when the infinite property is set to false.
This pull request fixes that :boom:

@mathisonian Which version did you observe the issue with ? Can you the settings with which I can reproduce this ?

I think this will happen with autoplay set to true.

Hey @vramana I was just using a basic setup like
      <Slider arrows={false} infinite={false}>
        <MySliderPage />
        <MySliderPage />
        <MySliderPage />
      </Slider>

I observed the behavior with<EMAIL_ADDRESS>from npm and the master branch on github

Anyway thanks for the PR! I'll take a look at it locally then merge it.


Better support for map printing

A user should be able to specify precise formatting for the tuple entries in the map (the aggregation) and also the aggregating function result as well. So, if we have a very simple example of a one element tuple with a count() function, e.g. if we were tracking pointers, then we should be able to specify that the tuple member is a pointer when we print it. We can do that with tuples and printf() but not with print(). For example:
# cat print-formatting.bt
BEGIN
{
  @[0xfeedface] = count();
  @[0xbaadcafe] = count();

  @x = (0xfeedface, 0xbaadcafe);
}

interval:s:1
{
  print(@);
  printf("%p %p\n", @x.0, @x.1);
}

# sudo bpftrace ./print-formatting.bt
Attaching 2 probes...
@[4277009102]: 1
@[3131951870]: 1
0xfeedface 0xbaadcafe

Using the simple example above we should, at a minimum be able to do the following to specify the first field of the aggregation should be printed as a pointer.:
print(“%p”, @);

Just to extend it further clarification,  if the tuple was @[void*, int, char] I should be able to do:
print(“%p %d %c”, @);

We should also be able to control the format modifier for the aggregating function result as well.

I'd prefer that we keep explicit formatting out of the print() function, but there are two other enhancements (both useful by themselves) that we could make to improve this type of map printing.
Approach 1
Allow declaring map types up front: #2954
let @[pointer_t] = count_t; // syntax TBD
BEGIN
{
  @[0xfeedface] = count();
  @[0xbaadcafe] = count();
  print(@);
}

Since we know that the map's key has a pointer type, print() could automatically print it as a pointer.
Approach 2
Provide better looping constructs to allow scripts to iterate over the keys of a map and print them out individually:
@[0xfeedface] = count();
@[0xbaadcafe] = count();
for ($key : @)
{
  printf("@[%p]: %d\n", $key, @[$key]);
}

Just detailing some inconsistencies:
sudo bpftrace -e 'BEGIN { @ = count(); print((@)); exit(); }'
Attaching 1 probe...
@: 1

@: 1

sudo bpftrace -e 'BEGIN { @ = count(); print((@, 1)); exit(); }'
Attaching 1 probe...
(1, 1)

@: 1

sudo bpftrace -e 'BEGIN { @[1] = 2; @[2] = 3; print((@)); exit(); }'
Attaching 1 probe...
@[1]: 2
@[2]: 3

@[1]: 2
@[2]: 3

sudo bpftrace -e 'BEGIN { @[1] = 2; @[2] = 3; print((@, 1)); exit(); }'
stdin:1:29-37: ERROR: Argument mismatch for @: trying to access with arguments: [] when map expects arguments: [unsigned int64]
BEGIN { @[1] = 2; @[2] = 3; print((@, 1)); exit(); }
                            ~~~~~~~~

Closing as resolved by #3003.
Something similar to the original example can now be implemented as:
$ sudo bpftrace -e '
    BEGIN
    {
      @[0xfeedface] = 1;
      @[0xbaadcafe] = 2;
      for ($kv : @)
      {
        printf("@[%p]: %d\n", $kv.0, $kv.1);
      }
    }'
Attaching 1 probe...
@[0xfeedface]: 1
@[0xbaadcafe]: 2
^C


Add organizations close_account feature

Codecov Report

Merging #5040 (8551894) into master (10bd677) will decrease coverage by 0.01%.
The diff coverage is 91.66%.

@@            Coverage Diff             @@
##           master    #5040      +/-   ##
==========================================
- Coverage   95.80%   95.78%   -0.02%
==========================================
  Files         663      663
  Lines       66414    66426      +12
==========================================
+ Hits        63626    63629       +3
- Misses       2788     2797       +9

Flag
Coverage Δ

servertests
36.59% <25.00%> (-0.01%)
:arrow_down:

unittests
95.73% <91.66%> (-0.01%)
:arrow_down:

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

Impacted Files
Coverage Δ

moto/organizations/models.py
99.38% <90.00%> (-0.20%)
:arrow_down:

moto/organizations/responses.py
98.03% <100.00%> (+0.03%)
:arrow_up:

moto/resourcegroupstaggingapi/models.py
83.18% <0.00%> (-0.59%)
:arrow_down:

moto/route53/responses.py
96.69% <0.00%> (-0.42%)
:arrow_down:

moto/sns/models.py
96.83% <0.00%> (-0.40%)
:arrow_down:

moto/sqs/models.py
96.76% <0.00%> (-0.18%)
:arrow_down:

moto/config/models.py
99.22% <0.00%> (-0.13%)
:arrow_down:

moto/ssm/models.py
94.42% <0.00%> (-0.11%)
:arrow_down:

Continue to review full report at Codecov.

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


add access origin * tag

add access origin * tag to allow the mobile app to communicate with the cluster it was built on.
regenerate shrinkwrap.

LGTM


Add DP.

DigitalPrice is migrating to this new assetchain.

it's better if you submit a pr to verus repo
same goes for desktop repos


avx512f: Add many mask, mask2 and maskz intrinsics

Add _mm512_mask{,z}_extract{f32x4_ps,f64x4_pd,i32x4_epi32,i64x4_epi64}
Add _mm512_mask{,z}_insert[fi]{32,64}x4
Add _mm512_mask{,z}permutexvar{epi32,epi64,pd,ps}
Add _mm512_mask{,2,z}permutex2var{epi32,epi64,pd,ps}
Redo tests for _mm512_inserti32x4 which had bad coverage (b always zero).

Strange: Travis CI succeeded for me, otherwise I wouldn't have issued the PR.
However it failed later.
I think the problem is probably in the fact that idx is used both as an integral type and a as floating point type in _mm512_mask2_permutex2var_p[ds].
Initially I generated an integral idx but it led to a silly floating point value.
Then I generated a floating point idx but I figure when this is read on different machines it gives a different bit pattern, hence (I guess) the failures.
Now I store the floating point bit pattern as an integral type.
I now see more failures which don't seem correlated with my modifications.
I don't know what is going on but it will have to wait till the morning.

NP.  Just let me know when you want me to take a look at it, or if you need a hand.
I haven't looked at the code, but…
The -DSIMDE_NO_SHUFFLE_VECTOR build uses the default version of GCC on Bionic, which is 7.  So both failures right now are GCC 7.  Sounds like a potential compiler bug to me.  I'd probably try to reproduce it in an Ubuntu 18.04 (bionic) VM, then use creduce to generate a reduced test case, and hopefully that would tell you what you need to ifdef around.
GCC 7 is know to have problems with optimizing 512-bit vectors; see #278.  It wouldn't exactly be shocking to see another bug here.

NP. Just let me know when you want me to take a look at it, or if you need a hand.
I haven't looked at the code, but…
The -DSIMDE_NO_SHUFFLE_VECTOR build uses the default version of GCC on Bionic, which is 7. So both failures right now are GCC 7. Sounds like a potential compiler bug to me. I'd probably try to reproduce it in an Ubuntu 18.04 (bionic) VM, then use creduce to generate a reduced test case, and hopefully that would tell you what you need to ifdef around.
GCC 7 is know to have problems with optimizing 512-bit vectors; see #278. It wouldn't exactly be shocking to see another bug here.

I have looked at this and this is what I found:

the failures are only on /x86/avx512f/mm512_mask{,z}_insert[fi]32x4/native
both the failures are identical: same functions, same results
the failures are always on data32[8] corresponding to a switch from the low to high 256 bits of 512

If the /native really means that it is running the native instruction, I fail to see why all platforms succeed except GCC 7. I think this indeed suggests a compiler bug.
AFAICS an "ifdef around" would mean completely suppressing these tests on GCC 7.
However I fail to understand why GCC 7 succeeded on my Travis CI build and failed on the one started by the PR. This could give a clue. What is different?

@nemequ or @mr-c Do you have any idea why the -DSIMDE_NO_SHUFFLE_VECTOR test on Travis CI which succeeded when I committed to my fork, failed when I subsequently issued a PR on exactly the same data set?
I haven't modified the configuration of Travis CI but I imagine that there must be a difference.

@nemequ or @mr-c Do you have any idea why the -DSIMDE_NO_SHUFFLE_VECTOR test on Travis CI which succeeded when I committed to my fork, failed when I subsequently issued a PR on exactly the same data set?
I haven't modified the configuration of Travis CI but I imagine that there must be a difference.

We have a cat /dev/cpuinfo step, try checking the output of that to see if there are differences.  Maybe one machine has AVX-512 support and the other doesn't?  I haven't seen a Travis machine w/o AVX-512 in a while, though…
It's possible that the issue only appears if the build is targeting AVX-512, and since we use -march=native on CI maybe one worked and one didn't.  It kind of sucks that we can't always use the same flags, but we don't get to choose the hardware :(

Both the one that failed and the one that succeeded have an identical processor with AVX512 (F, DQ, CD, BW, VL, and VNNI).

It is not clear to me which code paths are executed during the tests.
Wouldn't it be possible to introduce an (always successful) pseudo-test which indicates clearly the state of the different #defines determining the code paths for the current platform?
(Maybe this information is already present but it isn't explicit enough for me. I only see native and emu but obviously they do not always indicate the same code path.)
If the same code path is executed by several platforms, maybe some failures should be acceptable, especially if the platform is known to be suspect. (Apart from the current GCC 7 case I am thinking mainly of ICC.)
The only exceptions I can see are:

s390x must pass as AFAIK it is the only big-endian platform.
compilation failures: often warning-errors which seem to be mainly generated by MSVC.
However I see that recently you have encountered some incorrect warnings from ICC.

Wouldn't it be possible to introduce an (always successful) pseudo-test which indicates clearly the state of the different #defines determining the code paths for the current platform?

Yeah, we could do that.  Something like this?
void print_status(const char* property, int enabled) {
  printf("%20s: %s\n", property, enabled ? "enabled" : "disabled");
}

#if defined(SIMDE_X86_AVX_NATIVE)
print_status("AVX", 1);
#else
print_status("AVX", 0);
#endif

I never really thought about it, but it's probably a good idea.  Of course you'd need to run it 4 times (emul/native, c/c++).  The trouble is we have a lot of these macros, but we could probably just start with the ones we need to know most often, and just build up the list over time.  Obviously the NATIVE ones, and a few from simde-common.h (like OpenMP, SHUFFLE, CONVERT, etc.).

(Maybe this information is already present but it isn't explicit enough for me. I only see native and emu but obviously they do not always indicate the same code path.)

Not really, no.  Obviously it's encoded into the source code, but that's it, and a lot of the logic tends to get hidden away in macros.  That's basically what Hedley is, then there are a bunch more in simde-common.h, simde-features.h, etc.  It's definitely a bit of a mess.
Native basically means that we try to use SIMD functions when available, emul means we rely on the auto-vectorizer.  Beyond that there are still a large number of different configurations possible, and special cases for various compilers.

If the same code path is executed by several platforms, maybe some failures should be acceptable, especially if the platform is known to be suspect. (Apart from the current GCC 7 case I am thinking mainly of ICC.)

I'm not sure I'm understanding you correctly here.  It sounds like you're basically suggesting that sometimes we should just punt on issues since it's really a compiler bug not a SIMDe bug, and tell people that if they want that functionality to work they should use a different/newer compiler.  If that's not what you're suggesting, maybe you could be a little more explicit?  If it is…
As a rule I'd rather not do this.  If possible we should work around the issue by creating a special case in the code.  We already have tons of these scattered throughout the tree.  I try to use SIMDE_BUG_* macros to help document them, but TBH sometimes I'm lazy and don't bother, especially for older compiler releases where the issue has already been fixed in newer versions.
That said, there will be some exceptions for when it is impossible to work around a particular issue, but so far that is pretty rare.  We can deal with that by either not testing that particular configuration in CI, or if it's just a couple of functions we can disable those tests.
Unfortunately SIMDe seems to be really good at finding compiler bugs.  I think the only compiler we don't have any unresolved issues with right now is MSVC, and that's only because I don't bother reporting bugs to them… Emscripten is normally the exception because they have been extremely responsive to bug reports, but right now there is actually one (the patches are awaiting review before moving into clang).  It's not just ICC and an old version of GCC that's a problem, it's basically every compiler.

compilation failures: often warning-errors which seem to be mainly generated by MSVC.

To be fair, that is because we use /analyze /W4 /WX to get MSVC to emit all warnings possible, and treat them as errors.  We do -Weverything -Werror on clang, and that has been every bit as much of a headache for me.
If you haven't already, you should take a look at simde/simde-diagnostics.h.  I've started to add explanations to the warnings we disable, but there is still work to do there.

However I see that recently you have encountered some incorrect warnings from ICC.

And GCC, and clang.

I could be wrong but it seems to me that in the current case SIMDe is just redirecting to the native intrinsic. So if the compiler can't handle the native intrinsic correctly it seems to me that you aren't doing the user any favours by hiding the fact that his compiler is broken. If you workaround the breakage you should at least issue a remark (I would have said a warning but I don't want a warning-error) that his compiler may not handle the instruction correctly. Otherwise he will be very surprised when his code fails if he runs it without SIMDe.
I suppose all this depends on your use case for SIMDe. In my case it was initially to port my code to wider vectors and new instructions (e.g. GFNI) for which I don't yet have the hardware. SIMDe with its fallbacks enables me to test my software with reasonable performance which is not the case with e.g. the Intel SDE. Subsequently I have just been trying to help the project in my spare time.

I could be wrong but it seems to me that in the current case SIMDe is just redirecting to the native intrinsic. So if the compiler can't handle the native intrinsic correctly it seems to me that you aren't doing the user any favours by hiding the fact that his compiler is broken.

I don't think that's true.  I think the most common cases are running on non-x86 CPUs, and running on x86 CPUs that don't natively support the function in question.  In fact, these issues mostly only appear if we can't redirect to a native intrinsic and instead have to rely on autovectorization.
It seems to me that most people using SIMDe aren't using it to write new code (though as we add more AVX-512 and NEON functionality I hope to see more of that), but rather to port old code.  In that case, they already have a working (for example) AVX2 implementation that they want to run on a new platform which doesn't natively support AVX2.

I suppose all this depends on your use case for SIMDe. In my case it was initially to port my code to wider vectors and new instructions (e.g. GFNI) for which I don't yet have the hardware. SIMDe with its fallbacks enables me to test my software with reasonable performance which is not the case with e.g. the Intel SDE. Subsequently I have just been trying to help the project in my spare time.

Ah, okay this definitely makes a lot more sense to me now.  I'm actually really happy to hear that that is what you're interested in because it's one of the use cases I had in mind, but I don't think it's the norm.  It's a shame you had to actually implement GFNI in order to play with it, but I do really appreciate it (and all the other patches)!
This particular problem is also a bit of a special case as far as these types of issues go.  In the vast majority of cases (probably in the 90-95% range) the problems don't occur when we're using the native intrisics, they occur in the portable fallbacks.  Even for the remaining 5-10%, the problem is almost always just a missing intrinsic; if the compiler actually supports the intrinsic in question these types of errors are actually really uncommon, at least in GCC and clang.  And, among the "missing intrinsic" cases, the vast majority of those are actually for functions which are really just alternative APIs for another intrinsic which were added on after an initial release of the API, and we can just implement the relevant function using the original (likely ugly, but functional) API.
I think there have only been a handful of bugs like this so far, they're really not the norm.

If you workaround the breakage you should at least issue a remark (I would have said a warning but I don't want a warning-error) that his compiler may not handle the instruction correctly.

If there is a performance issue I'd be sympathetic to adding a remark.  Unfortunately there isn't really a good way of doing this portably (you might want to take a look at #310, I mention a few implementation details there, and some of the problems; GCC #95239 is particularly annoying).  I'm definitely open to suggestions about how to implement something like this, because TBH I can't really think of any good options.
If it's just a case of implementing one function using a slightly different API I don't think there is a need.

Otherwise he will be very surprised when his code fails if he runs it without SIMDe.

I see your point, but I don't think the current situation is unreasonable.  If you run the code without SIMDe you're running it without the portability layer, so it makes sense to me that there might be portability issues.
The only case where I think optionally using SIMDe makes sense is if you don't want to create a hard dependency on SIMDe.  In this case they should be maintaining the non-SIMDe path (in all likelihood the non-SIMDe path is probably the default); the important thing for SIMDe is that we don't want to decrease portability.
  If we warn about the native GCC 7 implementation on GCC 7 with SIMDe, why would we not warn also warn about it on GCC 10?  Or clang?  What about on ARM?  I think the most sensible line to draw is that is to only warn if we're currently falling back on a slow path because we can't access the faster path.

Okay, I've got creduce working on generating a reduced test case.  It looks like the issue was fixed in 8.0, and only occurs at -O0.
We can work around this by just using the _mm512_mask_mov_ps-based fallback.  This still works at -O0, and at -O1 it generates the exact same code, so performance shouldn't be effected if you enable optimization, and if you're at -O0 you don't care about performance anyways.
I think this was fixed with GCC r262566, but I'm not certain.
I'll push a commit soon to verify the fix.  Assuming it works I'll go ahead and merge this.

Looks like that did the trick.  Merged as 89ef7394d06e5aed541ff2a0789a932a85d4e35a, thanks!
I finally got the NEON stuff working, I'm merging it now, so if you're still interested in implementing NEON functions it's wide open :)

I could be wrong but it seems to me that in the current case SIMDe is just redirecting to the native intrinsic. So if the compiler can't handle the native intrinsic correctly it seems to me that you aren't doing the user any favours by hiding the fact that his compiler is broken.

I don't think that's true. I think the most common cases are running on non-x86 CPUs, and running on x86 CPUs that don't natively support the function in question. In fact, these issues mostly only appear if we can't redirect to a native intrinsic and instead have to rely on autovectorization.

I think that we are talking at cross-purposes here. By "in the current case" I meant the GCC 7 failures that are preventing my additions from being merged. It seems to me clear, although I could be wrong, that these failures occurred while running native code on an x86 CPU with adequate AVX512 support.

It seems to me that most people using SIMDe aren't using it to write new code (though as we add more AVX-512 and NEON functionality I hope to see more of that), but rather to port old code. In that case, they already have a working (for example) AVX2 implementation that they want to run on a new platform which doesn't natively support AVX2.

OK, I don't dispute that.

I suppose all this depends on your use case for SIMDe. In my case it was initially to port my code to wider vectors and new instructions (e.g. GFNI) for which I don't yet have the hardware. SIMDe with its fallbacks enables me to test my software with reasonable performance which is not the case with e.g. the Intel SDE. Subsequently I have just been trying to help the project in my spare time.

Ah, okay this definitely makes a lot more sense to me now. I'm actually really happy to hear that that is what you're interested in because it's one of the use cases I had in mind, but I don't think it's the norm. It's a shame you had to actually implement GFNI in order to play with it, but I do really appreciate it (and all the other patches)!
This particular problem is also a bit of a special case as far as these types of issues go. In the vast majority of cases (probably in the 90-95% range) the problems don't occur when we're using the native intrisics, they occur in the portable fallbacks. Even for the remaining 5-10%, the problem is almost always just a missing intrinsic; if the compiler actually supports the intrinsic in question these types of errors are actually really uncommon, at least in GCC and clang. And, among the "missing intrinsic" cases, the vast majority of those are actually for functions which are really just alternative APIs for another intrinsic which were added on after an initial release of the API, and we can just implement the relevant function using the original (likely ugly, but functional) API.
I think there have only been a handful of bugs like this so far, they're really not the norm.

OK, I Think we understand each other better here.

If you workaround the breakage you should at least issue a remark (I would have said a warning but I don't want a warning-error) that his compiler may not handle the instruction correctly.

If there is a performance issue I'd be sympathetic to adding a remark. Unfortunately there isn't really a good way of doing this portably (you might want to take a look at #310, I mention a few implementation details there, and some of the problems; GCC #95239 is particularly annoying). I'm definitely open to suggestions about how to implement something like this, because TBH I can't really think of any good options.
If it's just a case of implementing one function using a slightly different API I don't think there is a need.

Otherwise he will be very surprised when his code fails if he runs it without SIMDe.

I see your point, but I don't think the current situation is unreasonable. If you run the code without SIMDe you're running it without the portability layer, so it makes sense to me that there might be portability issues.
The only case where I think optionally using SIMDe makes sense is if you don't want to create a hard dependency on SIMDe. In this case they should be maintaining the non-SIMDe path (in all likelihood the non-SIMDe path is probably the default); the important thing for SIMDe is that we don't want to decrease portability.
 If we warn about the native GCC 7 implementation on GCC 7 with SIMDe, why would we not warn also warn about it on GCC 10? Or clang? What about on ARM? I think the most sensible line to draw is that is to only warn if we're currently falling back on a slow path because we can't access the faster path.

OK, it's your call.
But, concretely, what do you want me to do in the case of these GCC 7 failures?

I don't want to drop the 36 intrinsics I am adding because of what seems like 4 with very similar failures on a very old compiler.
I suppose that I could pull the 4 failing intrinsics and reissue the PR with just the 32 remaining.
I feel that it is a waste of time chasing what seems to me to be an old compiler incorrectly implementing these closely related intrinsics.

To sum up, at the risk of repeating myself, for the case of these GCC 7 failures:

The test code in avx512f.c could be wrong but this is highly unlikely as it succeeds on all the other platforms. The compiler could be incorrectly implementing avx512f.c. This also seems highly unlikely as the same simple intrinsics are used in the other tests which succeed.
The code in avx512f.h could be wrong. This is not impossible because some of my movm intrinsics have very counter-intuitive fallbacks due to missing 8-bit and 64-bit multiply and shift intrinsics in SSE and AVX. However AFAICS these failures occur when implementing the intrinsic natively, not in fallback or portable code. I don't see how the problem could be in the simple redirection in avx512f.h, especially as all other platforms are OK.

Hence my conclusion that the compiler is incorrectly implementing these closely related intrinsics.
It seems to me that all that can be done is to disable the native intrinsic for this compiler and IMHO (but we seem to differ on this) inform the user that this has been done.
If you agree with my diagnosis, could you please do this or should I just drop the 4 failing intrinsics?

Looks like that did the trick. Merged as 89ef739, thanks!

Sorry, I hadn't seen your last two comments when I wrote the above. I thought that I had done a Ctrl-F5 but they only just now refreshed in my window :-( Thank you.

I finally got the NEON stuff working, I'm merging it now, so if you're still interested in implementing

OK, cool. Thank you.

No worries.  Sorry I didn't get to this earlier; the NEON stuff was significantly more problematic than I'd hoped.  Largely because improving the code for the test cases revealed some rather nasty bugs; getting the NEON part to work was comparatively straightforward.
Even it's not really relevant for this issue anymore, this could come up again in the future.  So, for a theoretical function in the future where the compiler implementation of an intrinsic is buggy:

If it's possible to fall back on other intrinsics, that's preferable.  We got kind of lucky with this one because the work-around actually generates exactly the same code when optimization is enabled, but even if that weren't the case it would still probably be the fastest (and therefore preferred) option.  Once we have the performance warning code implemented I'd be willing to add a performance warning which is emitted when we fall back on the slow path.
If it's not possible to fall back on other intrinsics, fall back on the portable version.  Again, a performance warning here would be good.
If the portable version is still buggy, or if the problem was bad codegen from the portable version, try to find an alternate (possibly slower) implementation which does actually work as intended.
If we can't find any implementation that compiles to accurate code, disable that test case for that particular compiler, and we should probably seriously consider an error (not just a warning) for that compiler when calling that function.  Maybe that error would just be a missing function because it is ifdef'd out on that platform.

Does that sound reasonable to you?


Use Mock Service Worker to avoid networks calls to AO3 during tests

See: https://mswjs.io/
From the discord discussion:

ms boba — Today at 12:23 PM
so basically you would not change anything in the code really, but in the tests you would say "if there is a request for e.g. /works/1234 return test_data/works_1234.html"
it means the tests don't ever really use the network
then you can have a second test that we just run e.g. on PR submission/once a day that tries to actually fetch the real /works/1234 and checks that it's equal to test_data/works_1234.html.
this way running tests becomes much faster, but also we can still be notified of changes

I can take care of this at some point, but I am also very willing to guide someone in setting up MSW, and getting this to work.

Might fix #13

Added a PR for this at #19 :D


user agent for LUIS cli

Sets (or appends) the user-agent for LUIS as follows:
package-name/package-version (os-platform; node-platform)
for example on my machine running LUIS I get a full user-agent as follows:
'Node/v10.9.0 (x64-Windows_NT-10.0.17763) ms-rest-js/0.1.0 luis-apis/2.1.0 (x64-Windows_NT-10.0.17763; Node.js,Version=v10.9.0) azure-sdk-for-js'

fixes #742

Pull Request Test Coverage Report for Build 1988

7 of 7 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 68.465%

Totals

Change from base Build 1980:
0.0%

Covered Lines:
4052

Relevant Lines:
5611

💛  - Coveralls


Make log statements clean and consistent

Should have a policy for what gets logged, and at what level. E.g. are correlation ids included?
Should consistently use printf style
Message capitalization and working should be consistent

Correlation id is handled when using logger. This is part of the client.


BAEL-3817 - ThreadPoolTaskExecutor corePoolSize vs. maxPoolSize

[retest this please]
Note: this comment is for CI build. No action required from the author

[retest this build]
Note: this comment is for CI build. No action required from the author.

[retest this please]
Note: this comment is for CI build. No action required from the author.

[retest this please]
Note: this comment is for CI build. No action required from the author.

[retest this please]

Not sure what you mean, all the tests in my module pass.
On Fri, Feb 14, 2020 at 11:10 AM Muhammad Asif Anwar <
<EMAIL_ADDRESS>wrote:

[retest this please]
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/eugenp/tutorials/pull/8723?email_source=notifications&email_token=AADXIGDMRUWMQJOS4WMPVV3RC3F6VA5CNFSM4KVK5XBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELZXI3A#issuecomment-586380396,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADXIGHQJ3MC2GACXDOR7T3RC3F6VANCNFSM4KVK5XBA
.


node: command not found

Looks like this doesn't bundle Node.js and so relies on Node.js to be installed. Whilst this is understandable, it doesn't detect the Node.js I have installed and there's no way to configure the path to the node executable.
I think either node should be bundled (via something like this) , or there should be some configuration options to provide the path to your node executable.
My Node.js is installed via asdf and exists in my path. There is also a link inside /usr/local/bin/node, but that isn't found either.

I am also experiencing zsh: command not found: node. Thanks for bringing this up.

@whitfin Thanks, will try to think about an idea to solve it

@iamwillow @whitfin I believe I have found a solution.
on the first line in the editor specify the path to your node binary like that:
/* /usr/local/bin/node */

console.log("should work")

note The path must be written in the first line.
If you can clone the repo and try to build master to test it on your machine to see if it works for you it will be great. Let me know and I will deploy new release if it does.

I am closing it now, new release has been deployed. Please reopen if you still have issues with that.


discovery: use a more direct and less error-prone return value

Since err != nil has been judged before, nil is returned directly here, which is more obvious, readable and less error-prone.

We could remove the if instead

Good idea!
Modified. Please review again.

friendly ping~


Fix comments between headers (#447)

Background
Closes issue #447
Sometimes is nice to provide more information about a specific header, specially when sharing targets files. For this reason would be nice be able to put comments in the header section.
Checklist

[x] Git commit messages conform to community standards.
[x] Each Git commit represents meaningful milestones or atomic units of work.
[x] Changed or added code is covered by appropriate tests.

@tsenart Applied the suggestion, nice catch!
Also rebased with master in upstream. Please let me know if you need anything else.

One last request: Please update the relevant sections of the README with this added functionality.

Just removed the part about targets.
This should be enough since  my first usage I already expected to be able to use comments anywhere.

Hello @tsenart, thank you very much for your time.


devspace init, image repository causes panic

What happened?
cli crashed, panic: runtime error: invalid memory address or nil pointer dereference
What did you expect to happen instead?
Expected minimal devspace.yml to be generated
How can we reproduce the bug? (as minimally and precisely as possible)
Follow the getting started guide at devspace init selecting any one options except "Always skip image push...." results in the following error.
? How do you want to initialize this project?
 Use the Dockerfile in ./Dockerfile

? Which registry do you want to use for storing your Docker images?
 Use hub.docker.com
[wait] | Checking registry authentication (0s)panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x1 addr=0x58 pc=0x1654bb8]

goroutine 1 [running]:
github.com/devspace-cloud/devspace/pkg/devspace/docker.(*client).Login(0xc000f65450, 0x2194c12, 0xe, 0x0, 0x0, 0x0, 0x0, 0x1, 0x2b, 0x0, ...)
        /Users/runner/runners/2.169.0/work/devspace/devspace/pkg/devspace/docker/auth.go:43 +0xc8
github.com/devspace-cloud/devspace/pkg/devspace/configure.(*manager).getRegistryURL(0xc0006e5e90, 0x26489e0, 0xc000f65450, 0x212bcf2, 0x7, 0xc00112da28, 0x5, 0x0, 0x0, 0x0)
        /Users/runner/runners/2.169.0/work/devspace/devspace/pkg/devspace/configure/image.go:288 +0x52f
github.com/devspace-cloud/devspace/pkg/devspace/configure.(*manager).newImageConfigFromDockerfile(0xc0006e5e90, 0xc000f3f300, 0x10, 0x2170aa8, 0xc, 0x0, 0x0, 0xc00112db00, 0xa9e86a, 0xc000f2ca70)
        /Users/runner/runners/2.169.0/work/devspace/devspace/pkg/devspace/configure/image.go:103 +0x2a2
github.com/devspace-cloud/devspace/pkg/devspace/configure.(*manager).NewDockerfileComponentDeployment(0xc0006e5e90, 0xc000f3d530, 0xc000f21b80, 0x11, 0x0, 0x0, 0x2170aa8, 0xc, 0x0, 0x0, ...)
        /Users/runner/runners/2.169.0/work/devspace/devspace/pkg/devspace/configure/deployment.go:26 +0xea
github.com/devspace-cloud/devspace/cmd.(*InitCmd).Run(0xc0000d21e0, 0x2664400, 0x3a401d0, 0xc000e7d900, 0x3a401d0, 0x0, 0x0, 0x0, 0x0)
        /Users/runner/runners/2.169.0/work/devspace/devspace/cmd/init.go:239 +0xa1a
github.com/devspace-cloud/devspace/cmd.NewInitCmd.func1(0xc000e7d900, 0x3a401d0, 0x0, 0x0, 0x0, 0x0)
        /Users/runner/runners/2.169.0/work/devspace/devspace/cmd/init.go:80 +0x6b
github.com/spf13/cobra.(*Command).execute(0xc000e7d900, 0x3a401d0, 0x0, 0x0, 0xc000e7d900, 0x3a401d0)
        /Users/runner/runners/2.169.0/work/devspace/devspace/vendor/github.com/spf13/cobra/command.go:826 +0x467
github.com/spf13/cobra.(*Command).ExecuteC(0xc00055cc80, 0x3a401d0, 0xc00055cc80, 0xc00079bf90)
        /Users/runner/runners/2.169.0/work/devspace/devspace/vendor/github.com/spf13/cobra/command.go:914 +0x302
github.com/spf13/cobra.(*Command).Execute(...)
        /Users/runner/runners/2.169.0/work/devspace/devspace/vendor/github.com/spf13/cobra/command.go:864
github.com/devspace-cloud/devspace/cmd.Execute()
        /Users/runner/runners/2.169.0/work/devspace/devspace/cmd/root.go:99 +0xb5
main.main()
        /Users/runner/runners/2.169.0/work/devspace/devspace/main.go:17 +0x45

Local Environment:

DevSpace Version: 4.12.1
Operating System: windows
Docker 19.03.8
Powershell 7.0.0

Anything else we need to know?
I currently have not setup any authentication for dockerhub.
/kind bug

@SamuelColacchia thanks for reporting this issue! I'll fix this right away!

@FabianKramm I was doing some more testing to try and determine what exactly was causing this. The issue originated with my ~/.docker/config.json some how "credsStore":"desktop" which caused docker to error which then caused devspace init to panic. Here is the docker error I had. Alternatively ensuring that the system path variables are setup correctly fixes it to. In my case for some reason a few of my path variables where miss-configured.
docker.credentials.errors.StoreError:
Credentials store docker-credential-desktop exited with "error getting credentials - err:
exec: "docker-credential-wincred.exe": executable file not found in %PATH%, out: ``".

Once i applied either of these fixes the CLI worked as intended.
Potential Solution for devspace:
Since this error is caused by incorrect configurations maybe add some error handling for issues like this.

@SamuelColacchia thanks for investigating! With v4.12.2 devspace shouldn't throw a nil pointer exception anymore, however you are correct we could still improve the error handling in cases of wrong docker configuration, so I'll leave this issue open for now

Since this issue is about nil pointer exception and that's fixed, I'm closing this issue. If @SamuelColacchia still wants an improvement, please feel free to open a new issue for that enhancement request.


The implementation of the cluster_config‘s serialize/deserialize function  inconsistent

serialize : use the buffer method，default host-endian
deserialize: use buffer_serializer, default little-endian
problems may arise on big-endian machines

@guoxiangzhou
Buffer's get and put functions are little-endian, regardless of the host machine.
https://github.com/eBay/NuRaft/blob/2c7bdab8676534a570a39904cb28cab959023e41/src/buffer.cxx#L319-L322


Bug - Problem with xcconfig files

Currently there are xccofnig files in the root directory and also in the Steps directory and their values aren't used correctly.
This seems like a bug which should be fixed, so every developer can use their own bundle identifiers and so on.
Also add the used xcconfig file should be added to the .gitignore

Oh man! I've got xcconfig files ignored on my end (But I did that 2 days
ago, a bit too late). I look into this again today! Thanks for letting me
know!
On Thu, Oct 5, 2023 at 3:01 AM Thimo Bess @.***> wrote:

Currently there are xccofnig files in the root directory and also in the
Steps directory and their values aren't used correctly.
This seems like a bug which should be fixed, so every developer can use
their own bundle identifiers and so on.
Also add the used xcconfig file should be added to the .gitignore
—
Reply to this email directly, view it on GitHub
https://github.com/brittanyarima/Steps/issues/49, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASK4AA4XDDBMAFWIKK47IETX52AO7AVCNFSM6AAAAAA5T7QFPSVHI2DSMVQWIX3LMV43ASLTON2WKOZRHEZDOOBXG43TGNI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Working on it!

It is still not working for me :(

Are you making sure to name the new config file StepsConfig?
I just tried it & it worked for me!
Let me know if you still have issues!
On Thu, Oct 5, 2023 at 11:44 AM Thimo Bess @.***> wrote:

It is still not working for me :(
—
Reply to this email directly, view it on GitHub
https://github.com/brittanyarima/Steps/issues/49#issuecomment-1749455409,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASK4AAZXDKP2A4MTUUBKKIDX535Y3AVCNFSM6AAAAAA5T7QFPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBZGQ2TKNBQHE
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

@Drag0ndust I think I see the issue. Trying to fix it now!

@Drag0ndust Think I fixed it! Try it when you get a chance & let me know if you still have issues. I didn't factor in the Widget extension and that it needs a different BundleID 🤦♀ Updating the readMe with those instructions now!


service bindings are done poorly

The handling of specified keys in service was changed in a messy way which, among other things, breaks the message monitor. The Service class ignores both its exchange and its keys arguments. Classes which inherit appear to override the _bindings member after init of the base class.
A better design is for Service to use the arguments (possibly we need to change the signature so that the exchange and key are specified in pairs, probably a more explicit data structure for this would be nicer also) and for the derived classes to pass those to the actual init rather than modifiying the member later.
See lines near 62 and 250 of service.py

This item is no longer relevant, going forward this is handled in dripline-cpp and wrapped for python


Datastore query limits are silently truncated by the v1beta3 API

This bug manifests itself in a couple of "fun" ways:
len(list(client.query(kind="Foo").fetch(limit=300)))

Will yield 300, assuming there are 300 or more entities of that kind.
len(list(client.query(kind="Foo").fetch(limit=500)))

Assuming there are 500 entities of that kind, will yield 500. If there are n entities where n > 500, it will yield n.
This all seems to be caused by the v1beta3 api truncating the limits to 300:
entities, more, cursor = client.query(kind="Foo").fetch(limit=500).next_page()

len(entities) will be 300 and not 500 even if there are 500 or more entities of that kind.
We're currently using the following snippet to work around this issue:

def _all_entities(iterator):
    entities, cursor = [], None
    while iterator._limit > 0:
        xs, more, cursor = iterator.next_page()
        iterator._limit -= len(xs)
        entities.extend(xs)
        if not more:
            break

    return entities, cursor

@Bogdanp This is a "feature" not a bug. The API doesn't promise to return your fetch limit, it just promises not to exceed it. It typically times out on the backend after a pre-set amount of time. Is the more value not useful? (The actual value returned by the backend is a bit different.)
@pcostell Can say more, though I am pre-emptively closing this since there isn't anything we can do in the library.

it just promises not to exceed it

The library does exceed it in the second example I gave though.

Oh wow, my bad! Good thing I forgot to click the close button. Reproducing now on my end.

No worries! Regarding the "feature", is it possible to get that bumped up somehow or is that set in stone? The old API used to allow much higher values for limits.

The issue is with the way __iter__ works, btw: it naively calls next_page without modifying its limit based on the results it gets back so it eventually exceeds the limit if there are enough entities. This used to work fine because, like I mentioned above, the old API didn't truncate limits (if it did, it did so at a much higher number than 300). The fix would probably look a lot like my _all_entities function above.

OK this is totally a "bug" in our implementation, essentially identical to #1467. It occurs because limit=500 is set on every request, but doesn't take into account the results already returned. Bugs like this are a reasons we are hesitant when we implement a __iter__ that makes more than one API call.
As for 300 vs. 500, that's completely out of gcloud-python's control, though maybe @pcostell can weigh in. You could also file an issue on https://github.com/GoogleCloudPlatform/google-cloud-datastore

Jinx!

The Cloud Datastore API has to reserve the right not to return all the results -- we need to protect both our servers and other users on them. This is why we expose our API with support for batching -- but the client libraries need to take advantage of this in order to expose a nicer API to our users.
I think __iter__ needs to make more than one API call -- it should return exactly how many items the user asks for (or less if those items don't exist). Also, I think next_page should probably be implemented in terms of __iter__, not the other way around. This is very similar to gcloud-node#1260, I'm just going to quote in something I said from there:

The way I see it is that our desired behavior is a streaming API. If a user asks for a limit of N, we will give them a stream of up to N entities. We can then add some helpers on top of that to convert the stream to a list.

Cloud Datastore then offers a paging feature, which provides the user a cursor they can use to get extra pages. On top of that, Cloud Datastore has the feature of best effort end condition tracking (more_results). This is very useful for users who are showing pages to their users as they can get information about whether or not they should show a "Next Page" button (this is MORE_RESULTS_AFTER_LIMIT). This feature is conservative (MORE_RESULTS_AFTER_LIMIT may be returned even if the correct result is NO_MORE_RESULTS).

Importantly, Cloud Datastore's paging feature is completely separate from the batching API, which is really just an implementation detail because prior to gRPC we couldn't offer a streaming API.

Thanks @pcostell.

@dhermes can we get this bug assigned to someone? The Cloud Datastore batch size shouldn't be something client library users should have to worry about.

Hey.
So there is no way to get more than 300 results at once ?
I can see that this issue has been closed for a long time but it seems that this "problem" (or feature?) still exists.

@Rafff How do you mean? The API has limits based on payload size and there isn't anything we can do about it in the client. However, we do provide an iterator so that you don't have to worry about it.

Hi @dhermes ,
I have an issue and I believes that it somehow related to this issue my datastore have more that 8000 entities but when i am trying to use offset>350 and limit=2000 it return <1900 entities and if i increased my offset to 1000 it return 0 entities

@ibrahim-abuelalaa Would you mind sharing some code so we can try to reproduce?

client = datastore.Client()
query = client.query(kind = kind)
query.add_filter('projectKey', '=', projectKey)
len(list( query.fetch(limit=limit, offset=offset)))

So you have something like:
>>> query_iter1 = query.fetch()
>>> len(list(query_iter1))
8001
>>>
>>> query_iter2 = query.fetch(offset=351, limit=2000)
>>> len(list(query_iter2))
1899
>>>
>>> query_iter3 = query.fetch(offset=1000, limit=2000)
>>> len(list(query_iter3))
0

yes almost

@ibrahim-abuelalaa Is the distinction relevant? (I.e. is "almost" good enough?) I just want to be able to reproduce.

@dhermes yes it is exactly like that, sorry for confusion

Hello. Is there any way to work around the 300 entities limit? Is there any documentation about this 300 limit? I searched the library source code and nothing related to this 300 limit. Is it from the server side? To iterating all the entities, what is the best practice? Should we set the limit to None or use the cursor way?


Update Resource Limits

[x] refactor ResourcesTab.vue and make this tab component re-usable for both projects, accounts and domains
[x] iam/account: edit/update the resource count/limits (as root admin)
[x] iam/domain: edit/update the resource count/limits (as root admin)
[x] projects: edit/update the resource count/limits (as root admin)

@rhtyd cc @svenvogel
I've completed the components for edit/update the resource count/limit. Please review and let me your comment.

account:

domains:

projects:


[Flake]: Integration tests failing for storage client.

This seems to be a problem with the server returning wrongly formatted JSON objects:
https://source.cloud.google.com/results/invocations/64c28c56-2088-401c-8bc9-04c31ea30488/targets
I was able to get an improperly formatted response (using just curl). Note that the field should be event_types, not eventTypes.
while /bin/true; do curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" https://www.googleapis.com/storage/v1/b/[redacted]/notificationConfigs/25 >notification.txt; grep 'event_types' notification.txt || break; done; cat notification.txt

 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
 "event_types": [
{
  "id": "25",
  "topic": "//pubsub.googleapis.com/projects/[redacted]/topics/gcs-changes",
  "eventTypes": [
    "OBJECT_FINALIZE"
  ],
  "payloadFormat": "JSON_API_V1",
  "etag": "25",
  "selfLink": "https://www.googleapis.com/storage/v1/b/[redacted]/notificationConfigs/25",
  "kind": "storage#notification"
}

Blocked until the internal problem is fixed.

Inactive for 90 days, closing.


How to Change Sun,Mon...Sat titles with Custom Names?

I want to change Sun,Mon,Tue,Wen,Thu,Fri,Sat with my custom names Day1,Day2...
How can i change?Any one can guide me Your response will be appreciated.

It's easy. Use weekDayLabels:
<com.prolificinteractive.materialcalendarview.MaterialCalendarView
                   android:id="@+id/calendarView"
                    android:layout_width="match_parent"
                    android:layout_height="wrap_content"
                    app:mcv_weekDayLabels="@array/weekdays_cust"
                    />
and of course in strings.xml you need to have weekdays_cust array like:
<array name="weekdays_cust">
    <item>Day1</item>
    <item>Day2</item>
    <item>Day3</item>
    <item>Day4</item>
   <item>Day5</item>
    <item>Day6</item>
    <item>Day7</item>
</array>

Thank you so much,It is really helped for me.


ARROW-6933: [Java] Suppor linear dictionary encoder

For many scenarios, the distribution of dictionary entries is highly skewed. In other words, a few dictionary entries occurs much more frequently than others. If we can sort the dictionary by the non-increasing order of entry frequencies, and compare each value to encode from the beginning of the dictionary, we get the following benefits:

We need no extra memory space or data structure.
The search is extremely efficient, as we are likely to find a match in the first few entries of the dictionary.

This is the basic idea behind the linear dictionary encoder. When the scenario is right (highly skewed dictionary distribution), it outperforms both search based encoder and hash table based encoders.

@emkornfield This is almost the same as https://github.com/apache/arrow/pull/5058. Would you please take a look?

Codecov Report

Merging #5692 into master will increase coverage by 1.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5692      +/-   ##
==========================================
+ Coverage   88.93%   89.98%   +1.04%
==========================================
  Files         989      739     -250
  Lines      134508   114814   -19694
  Branches     1501        0    -1501
==========================================
- Hits       119627   103311   -16316
+ Misses      14516    11503    -3013
+ Partials      365        0     -365

Impacted Files
Coverage Δ

python/pyarrow/memory.pxi
62.79% <0%> (-3.07%)
:arrow_down:

python/pyarrow/plasma.py
56.16% <0%> (-2.74%)
:arrow_down:

cpp/src/arrow/sparse_tensor.cc
98.55% <0%> (-0.79%)
:arrow_down:

cpp/src/arrow/python/pyarrow.cc
28.88% <0%> (-0.66%)
:arrow_down:

python/pyarrow/tests/test_plasma.py
95.76% <0%> (-0.48%)
:arrow_down:

python/pyarrow/serialization.py
84.35% <0%> (-0.42%)
:arrow_down:

cpp/src/arrow/dataset/test_util.h
90.65% <0%> (-0.26%)
:arrow_down:

cpp/src/arrow/dataset/file_parquet.cc
95.89% <0%> (-0.06%)
:arrow_down:

cpp/src/arrow/python/numpy_convert.cc
95.02% <0%> (-0.05%)
:arrow_down:

python/pyarrow/tests/test_ipc.py
99.08% <0%> (-0.02%)
:arrow_down:

... and 296 more

Continue to review full report at Codecov.

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


Add a 'target' field for symlinkattributes.

This PR is based on the previous version by @hishamhm in #76, but uses a different strategy for 'dynamically' sizing the buffer.

Coverage increased (+0.5%) to 77.863% when pulling 32b355a9902e6ce7aae68926fc3f2d05856fc299 on n1tehawk:20160716_symlink-target into 080f74f785b2f30708ae797c15fca95a418b028a on keplerproject:master.

Thank you!!


Add a button to convert UUID to GitHub

(Also needs to handle the case where a user already has a GH->UUID link and there is existing data for a new UUID.)

From #21:

Note that there is not currently any support for automatically migrating data a user may have entered in Guest Mode to the new account linked to their GitHub username. This gets a bit tricky if a user tries to do this more than once, since then we have to decide which account "wins", but it might be worth allowing this to happen the first time and then just using the GitHub-linked data on subsequent logins.