License is not specified for the project

Hello,
thank you for the promising utility! (Though, I haven't tried that in action yet... :) )
I want my own project to be as clean as possible from licensing point of view thus checking the license of the library before trying that in the project.
I see that original article and files were published at https://www.codeproject.com/Articles/374386/Simple-image-comparison-in-NET under The Code Project Open License (CPOL) https://www.codeproject.com/info/cpol10.aspx
What's the license of this derivative project?
An additional note:
I believe, absence of the explicit license mention in this repository provokes original license violation by all, who created forks of the repository. Because the license for the original project requires "You must include a copy of, or the Uniform Resource Identifier for, this License with every copy of the Executable Files or Source Code You distribute and ensure that anyone receiving such Executable Files and Source Code agrees that the terms of this License apply to such Executable Files and/or Source Code." On my opinion, all, who forked and modified something this repository without including the link to the SPOL, violated the SPOL.
--
So, I'd say that explicit specifying license in this project would really help.
Thank you.

Hi and thank you for your comment.
I have added the MIT license to this newer version of the code, and hope that clarifies things 😊
https://github.com/xnafan/Simple-image-comparison/blob/master/LICENSE.md
Kind regards - Jakob


Unresponsive Radio Button

How do you hook up the radio button to respond to the user's click? I understand that you would use 'onPress' and connect it to a function that would manipulate the selected property. However, I am finding that the radio button does not respond to onPress. How can I make it responsive? Thank you!

Hi, this has been fixed in master. Can you point your package.json to master and check if the error persists. Don't forget to reinstall native-base if you change the dependency in package.json

Thank you so much, the error is gone!


It possible to specify topics between cloud and iot device (not core device)? thanks.

Take a look at GGD test which references the discovery GGD example and the discovery with shadow GGD example.
Those contain examples of how to build virtual Greengrass devices (Python scripts) and set up topics for them. This needs some modification for external devices though. Are you looking at devices like these Python scripts or true external devices?


Unexpected keyBoardNav in case column with duplicated "dataField" values

Description
We have data
[
{
    title: 'somevalue',
    desciption: 'somevalue',
    price: 'somevalue',
  }
]

and for exampe we want create table with 4 columns where we want display "price" for differend currencies. So when we create 2 columns with dataField 'price' and enable keyBoardNav we can't move for 4-th column by keyboard.
Example
https://codepen.io/anon/pen/jaLQve

@bigunaleksej this is a known issue, react-bootstrap-table use dataField as unique key to find all the columns. Which means we are not encourage people to use same column in a table. This problems will be fixed in react-bootstrap-table2.
Sorry about that, I'll recommend to predfined 4th column for different currencies. Let me know if you have any questions, thank


Update the ERROR frame

The ERROR frame now includes an error code indicating the type of error.
I don't have a strong preference between this solution or adding a new frame PROTOCOL_ERROR.
I'm waiting for your opinions.

Error codes incorporated in other PR.


Setting up Mali drivers from Minimal

I started with xenial-minimal-rock64-0.6.22-188-arm64.img.xz on my Rock64 and installed MATE and lightdm with apt. I also installed a bunch of random packages from Synaptic with "ayufan" in the version strings, which I think are from https://launchpad.net/~ayufan/+archive/ubuntu/rock64-ppa/
I now have a functional desktop, but glxgears -info still reports using llvmpipe instead of the real GPU.
What exctly do I need to install on the minimal images to set up the GPU drivers? Do I need to do something in particular with the X11 config to use them?

This is supported if you do install_desktop.sh <something>.


Feature: Support git commit prefixes

Hi, I'm happy to contribute to this. My work requires that the ticket be referenced in all commit messages e.g. foo-1243-feature-button-component. I'm wondering if it is viable to make the commits reference the ticket number from the branch name e.g. feat/foo-1234-button would result in commit messages being prefixed with foo-1234: blah blah?

hi hi
would be cool to have this configurable via oc config set branch=true

I just came to ask the same question, it would be great a feature like this, for now without this configuration I can't use oc.
Is there any way to get the output of the commit with a command?
For example, to do my own command setup, I have an alias as a function that does this job of getting the ticket name automatically for me. For example:
#  Commit everything
function commit() {
    commitMessage="$1"

    if [ "$commitMessage" = "" ]; then
        commitMessage="wip"
    fi

    # check if getIssueName returns a value and if it does, then prepend it to the commit message
    if [ -n "$(getIssueName)" ]; then
        commitMessage="$(getIssueName): $commitMessage"
    fi

    git add .
    git status

    eval "git commit -a -m \"${commitMessage}\" $2"
}

I have another function getIssueName that extracts the ticket name depending on my branch name.
Taking the example of @adrianrivers feat/foo-1234-button the function getIssueName would extract foo-1234 and put it at the beginning of the commit, so when doing
commit "Changes in the user module"

The final message would be: foo-1234: Changes in the user module.
Now, if there was a way to extract the output suggested by opencommit, a function like this could be done automatically.
#  Commit everything
function commit() {
    commitMessage="$1"

    if [ "$commitMessage" = "" ]; then
        commitMessage="wip"
    fi

    generatedMessage="oc --raw" #or sometinhg like that

    # check if getIssueName returns a value and if it does, then prepend it to the commit message
    if [ -n "$(getIssueName)" ]; then
        commitMessage="$(getIssueName): $generatedMessage"
    fi

    git add .
    git status

    eval "git commit -a -m \"${commitMessage}\" $2"
}

I would like to have config options like below:
oc config set prefix="xxx"
oc config set suffix="xxx"

I believe oc config set scope=true which automatically extracts ticket number and pastes as a prefix is best UX. WDYT?
anybody wants to make a PR?


Hostile Mobs

Pretty self-explanatory, this PR will be updated soon with the rest of the hostile mobs.
Also, when I add the bosses (Ender Dragon and the Wither), should a create a new package (net.glowstone.entity.bosses) or should I just put them in the net.glowstone.entity.hostile package?
Hostile Mobs:

[x] Blaze
[ ] Chicken Jockey
[x] Creeper
[ ] Elder Guardian
[ ] Endermite
[x] Ghast
[ ] Guardian
[x] Killer Bunny (Already added in net.glowstone.entity.passive.GlowRabbit)
[ ] Magma Cube
[x] Silverfish
[x] Skeleton
[ ] Slime
[ ] Spider Jockey
[x] Witch
[x] Wither Skeleton
[x] Zombie
[x] Zombie Villager

Boss Mobs:

[ ] Ender Dragon
[ ] Wither

It's already been tested and they work? and also CircleCI is not liking it I will take a look at its error i guess

@TheMCPEGamer Could you pull request it to my Glowstone++ Repo too? I want to do something

@TekkitCommando It's because I put the curly braces for functions on the next line and for some reason CircleCl doesn't like it.
ex:
public static void foo(String[] args)
{ //Right here
    bar(args);
}

oh yeah i knew that i guess it doesnt matter the style im just ocd lol

yeah i merge i guess it just wont look like all the other code

i just dont know how ocd @mastercoms is about the code style :P

This is an open open source project, if you want to do small things, push to master, but big things like this need to be reviewed more thoroughly.

@mastercoms sorry

@TekkitCommando It's fine, mistakes happen, no biggie.

This will not be accepted, in favor of https://github.com/gabizou/Glowstone/tree/entities-ecs and https://github.com/gabizou/Glowstone/tree/entity-storage-refactor


fix(src/prime.go): refactor go codes, optimaze it

It's seem that go version code is slower than python and js and it didn't make sense for me, so I looked at the code and for some reason if statement inside a loop make the code slower so I rewrite it and move the if statement to for conventional statement. here is the benchmark result I've got for before and after the change:
before:
BenchmarkPrime-8   	311378482	         3.755 ns/op	       0 B/op	       0 allocs/op
after:
BenchmarkPrime-8<PHONE_NUMBER>	         0.3114 ns/op	       0 B/op	       0 allocs/op
it's like the updated code is 10x faster than the old one.

The answer is wrong because execution will exit the loop when first non-prime number found.
❯ go run prime.go
0
0ms%

But "Pashmam Rikht" for a second.

Me too. :))))
Sorry, I know. I forget running this script. that's why I closed this pull request. still working on it.


RZ: Add PSATD

With BLAS++ and LAPACK++ added to conda-forge, we can now build PSATD in RZ geometry.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@conda-forge/help-c-cpp the last commit looks like I need some kind of .lib dependency propagation in https://github.com/conda-forge/lapackpp-feedstock and I am only patching this here. I am not too familiar why this lapack dependency is not fully forwarded... Is this an issue in lapackpp or in the underlying lapack feedstocks for Windows?

@conda-forge-admin, please rerender


Mgdstrm 8476

Description
Returns a new field maturity_status from the supported instance types endpoint.
Verification Steps

Compile and run the fleet manager locally: make binary && ./kas-fleet-manager serve
Run the OpenAPI server: make run/docs
Query the /api/kafkas_mgmt/v1/instance_types/{cloud_provider}/{cloud_region} endpoint using aws and us-east-1.
Make sure that all sizes have a field maturity_status, but only standard.x1 is stable. The others should be preview.

Checklist (Definition of Done)

[x] All acceptance criteria specified in JIRA have been completed
[x] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[x] JIRA has been created for changes required on the client side

This will need changes in appInterface

@pb82 I created a needs-app-interface-changes label and added it to this PR. Do you think this might be useful?

Is this backwards compatible, will something break if this isn't set?

@daveconde it will break, but we will make sure that is in app-interface before merging this.

Maybe we could push some default values likes these into KFM Makefile or an env script so the updates flow all the way down.

We try to best make sure that the default values are updated i.e the one maintained in the service template as commented in https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/1029#discussion_r874789255 or the one we have in Makefile.
The issue is more if the user has overridden these values to something else. When the underlying struct is modified, it may come with an update penalty to the user since they'll have to update the value as well.
in my opinion, KFM can still strive to make the change less breaking change by either ignoring validation when the value is not set etc and default to some values in the code but that also comes with a pain in maintaining the temporary code for the time until all users have migrated to using the new OpenShift parameter  - which we do not know yet . So at the moment, we rely on giving users a heads up, until we've a clear policy around these parameters changes.

@machi1990 won't that re-introduce the conflicts? I've specifically removed those changes now.


⚠ Samsung has degraded performance

In 2e44894, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 3144 ms

Resolved: Samsung performance has improved in 02552de.


Fixed #29253 -- Made method_decorator(list) copy attributes.

This resolves the following ticket: https://code.djangoproject.com/ticket/29253

You mean method instead of meth? I could do that.
I'm happy to add something to the release notes, too, though I didn't see anything in the contributing guidelines that said to do so in the case of bug fixes:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches

then that is nit needed

Okay, but I do see bug fixes mentioned in the release notes, e.g.
https://docs.djangoproject.com/en/2.0/releases/2.0.1/
So someone is adding them :), it just doesn't seem to be stated to do so in the docs.

I documented our practices about release notes in https://github.com/django/django/pull/9857.

I documented our practices about release notes in https://github.com/django/django/pull/9857.

please remove mentioning my id on the commit as it floods me with notification, and better to squash commits to a single one

Chris, can you check if https://github.com/encode/django-rest-framework/pull/6043 is a regression? Before this commit, it seems that decorating class-based view methods with either  @transaction.non_atomic_requests or @method_decorator(transaction.non_atomic_requests) had the same effect but now the latter crashes.

Yes, I can look.
On Fri, Jun 22, 2018 at 6:12 AM Tim Graham<EMAIL_ADDRESS>wrote:

Chris, can you check if encode/django-rest-framework#6043
https://github.com/encode/django-rest-framework/pull/6043 is a
regression? Before this commit, it seems that decorating class-based view
methods with either @transaction.non_atomic_requests or
@method_decorator(transaction.non_atomic_requests) had the same effect
but now the latter crashes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/django/django/pull/9819#issuecomment-399437486, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVt7uu5DH9-QW0BKab815h6P8D6BYkwks5t_O02gaJpZM4S5nMV
.

FYI, I posted a fix here: https://github.com/django/django/pull/10091


Make --hostname a shortcut to --host for url create

/kind feature

Which functionality do you think we should add?
Switching between multiple CLI tools I find myself using --hostname a lot in odo by mistake, which results in an error.
Why is this needed?
I think we should add a simple shortcut that when you use --hostname it's a shortcut to --host as well, since the names are often mixed / used in other similar tools.

--host used because the field that this roughly corresponds to in ingress and route is also called host. I think that it is worth having an alias for it.

oc uses --hostname for creating a route:
▶ oc create route edge --help
Create a route that uses edge TLS termination

Specify the service (either just its name or using type/name syntax) that the generated route should expose via the
--service flag.

Usage:
  oc create route edge [NAME] --service=SERVICE [flags]

Examples:
  # Create an edge route named "my-route" that exposes frontend service.
  oc create route edge my-route --service=frontend

  # Create an edge route that exposes the frontend service and specify a path.
  # If the route name is omitted, the service name will be re-used.
  oc create route edge --service=frontend --path /assets

Options:
      --allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in
the template. Only applies to golang and jsonpath output formats.
      --ca-cert='': Path to a CA certificate file.
      --cert='': Path to a certificate file.
      --dry-run=false: If true, only print the object that would be sent, without sending it.
      --hostname='': Set a hostname for the new route

I think we should have the same for odo as an alias just so when you're swapping between tools you don't make the mistake of forgetting it's --host not --hostname.


Possibility to build images for pushed tags

Hi,
this action is very useful! Lately (given some github specialities about Releases and CI, which in turn prevent this from building tagged containers for Julia packages released by the official TagBot tooling) we decided that we'd like to build docker images for pushed tags instead of the published releases.
Would it be possible to have support for tags, basically in the same way as for releases?
I assume that for supporting tags, we'd only need to make the condition here (https://github.com/macbre/push-to-ghcr/blob/master/action.yml#L73) a little more generous towards the tag pushing, but I'm no github actions expert so maybe there's a hidden problem.
Thanks for any hints/comments here. If I get some free time I'll try a PR.
Best!
-mk

I assume that for supporting tags, we'd only need to make the condition here (https://github.com/macbre/push-to-ghcr/blob/master/action.yml#L73) a little more generous towards the tag pushing, but I'm no github actions expert so maybe there's a hidden problem.

Or you can just hook to the tag event in your GitHub Action and pass the desired container tag via the image_tag action input. Something along:
on:
  # https://stackoverflow.com/a/63646054/5446110
  push:
    tags:
      - '*'

ah ok, so I assume I would simply push in a "dynamic" image_tag, as in
 image_tag: ${{ github.ref }}

...plusminus a bit of iffage around to make sure weird refs don't reach this. Does that sound right?

Does that sound right?

Correct :-) Closing then.


[June 30] Update the web app to work with the new App Sync schema

Updates:

[ ] questions fields

going to split this up


Add support to call configure method of serializer/deserializers

Currently when the serializers and deserializers are passed into KafkaProducer and KafkaConsumer, the configure method of Serializer interface is not called on them automatically as opposed to the case when they are passed in as config parameters. Since the Scala wrapper in this library requires you to instantiate the serializers and deserializers, this puts the onus the client to do this. The most known example of this is the KafkaAvroSerializer/Deserializers where configure is required to setup the schema registry server. But if you try to call the configure method before passing into KafkaProducer/Consumer, the client needs to copy&paste TypeSafeConfigExtensions which is a private object in this library to their own project.
This pull request proposes to simply call the configure method (hopefully idempotent for all serializer/deserializer implementations) in the KafkaProducer/Consumer implementation.
Another option could be making the TypeSafeConfigExtensions public, if this pull-request is not preferred.

Codecov Report

Merging #133 into master will increase coverage by 0.82%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #133      +/-   ##
==========================================
+ Coverage    64.4%   65.23%   +0.82%
==========================================
  Files          16       16
  Lines         531      535       +4
  Branches       30       34       +4
==========================================
+ Hits          342      349       +7
+ Misses        189      186       -3

Impacted Files
Coverage Δ

...main/scala/cakesolutions/kafka/KafkaProducer.scala
76.31% <100%> (+1.31%)
:arrow_up:

...main/scala/cakesolutions/kafka/KafkaConsumer.scala
77.27% <100%> (+2.27%)
:arrow_up:

.../cakesolutions/kafka/akka/KafkaConsumerActor.scala
58.48% <0%> (+0.44%)
:arrow_up:

...scala/cakesolutions/kafka/KafkaSerialization.scala
100% <0%> (+25%)
:arrow_up:

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 04db6a6...caa5dd0. Read the comment docs.

👍 This approach seems fine


Undefined payment index

[30-Nov-2016 13:37:00 Europe/Budapest] PHP Notice:  Undefined index: cod in /includes/functions/general.php on line 1039
Installed Paypal and COD payment modules PayPal standard selected on checkout_payment page.
Error place: checkout_confirmation.php

https://github.com/Gergely/oscommerce2/commit/0bceb057144d40602426bc0339e74def35495d96


Fix pydantic_scim2 intersphinx

Links from the httpx-scim-client documentation to pydantic_scim2 are broken now.

It was needed to install autodoc_pydantic.


Refactor Tapestry class constructor to accept Input

The Tapestry/Tapestry class constructor should accept an instance of Symfony\Component\Console\Input\Input rather than an array to remove the implicit usage of Symfony\Component\Console\Input\ArgvInput within its constructor.

This is solved by 728841ebad638ee3c49242b8e66d767280eaca15


KAFKA-13739: Sliding window with no grace period not working

Fix upperbound for sliding window, making it compatible with no grace period (kafka-13739)
Added unit test for early sliding window and "normal" sliding window for both events within one time difference (small input) and above window time difference (large input).
Fixing this window interval may slightly change stream behavior but probability to happen is extremely slow and may not have a huge impact on the result given.
Committer Checklist (excluded from commit message)

[x] Verify design and implementation
[x] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@cadonna this fixes a tricky bug - I was planning on cherry-picking to 3.2 WDYT?

@bbejeck Yes, please cherry-pick it to 3.2.

\cc @lct45

@tombentley I'd like to get this into 3.1.1 as well

Failures unrelated
Build / JDK 8 and Scala 2.12 / testThrottledProducerConsumer() – kafka.api.ClientIdQuotaTest
Build / JDK 8 and Scala 2.12 / shouldRestoreState – org.apache.kafka.streams.integration.PurgeRepartitionTopicIntegrationTest

Merged #11928 into trunk

Merged to 3.2
\cc @cadonna

@tiboun I tried to cherry-pick this to 3.1 but I can't due to a compiler issue:
/src/test/java/org/apache/kafka/streams/kstream/internals/KStreamSlidingWindowAggregateTest.java:720: error: cannot find symbol
        final MockApiProcessorSupplier<Windowed<String>, String, Void, Void> supplier = new MockApiProcessorSupplier<>();

Can you do another PR targeted towards the 3.1 branch that does not use the MockApiProcessorSupplier or add it to your patch?
Thanks

Here it is : https://github.com/apache/kafka/pull/11980


Being infected mutes you for as long as you are paralyzed

About the PR

When you get infected, you now also get muted for as long as you are blinded/paralyzed.
Why / Balance

Feature parity with cm13, prevents marines from instantly disclosing the nest sometimes.
Fixes #2878
Technical details

TryAddStatusEffect
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

https://github.com/RMC-14/RMC-14/assets/32827189/cbc8fb5a-d511-4c40-985a-eafaad31c092
Breaking changes

nope
Changelog

:cl:

add: Getting infected now also mutes you (in addition to paralyzing and blinding you)

can you still use emotes?

Yes, since muted still allows them, but you won't make a sound. (and you have to do them from the wheel or by typing, the scream action will fail)
(It's that way because when you're muted you can still gesture stuff basically)
I don't think there's a thing that completely stops all attempts at emotes, but could be wrong.


change: use Blakley to improve security

Utilize Blakley algorithm to achieve a better security remedy after secrets leak out.

首先需要指出的是，“improve security” 的说法不当，因为 Shamir's Secret Sharing 和 Blakley's Secret Sharing 都是在密码学上安全的算法。
至于你所认为的，Shamir 算法在重组秘密后可以反推出其他人所持有的密钥的说法也有失准确，因为 Shamir 算法基于多项式插值，密钥保管员持有的密钥对为 (x，f(x)) 的形式，重组秘密后只能获取多项式 f 的系数向量 a，但不知道其他密钥保管员所拥有的 x，所以无法反推。
退一步说，“重组秘密后可以反推出其他人所持有的密钥” 并不意味着可以找出重组秘密的人是谁，因为他们完全可以只公开秘密本身，而无需公开自己所持有的密钥分割。
其次，这个PR中加密算法的性能较低。简单地使用 encrypt() 加密一个较短字符串，Blakley 算法耗时约 0.25 ms，而 Shamir 算法耗时约 0.015 ms，二者拥有数量级上的性能差距。性能问题的原因可能是多样的，可能是算法本身的问题、实现时的纰漏或是第三方库的问题。
综上所述，我认为使用该算法替代原有的加密算法并无裨益，因此不批准此次提交，但欢迎对加密问题的持续关注以及更优算法的改进。

I later read the implementation of Blakley and Shamir again.
I should apologize that I do not realize randomness appears in both algorithms. So, it is impossible to recall the exact keys for either method. I was wrongly guided by some cryptographical introductions (one of them available at here) before.
Also, it has been proven that Blakley's will reduce to a generalized Shamir's algorithm under certain conditions.
That is the reason why they should have no difference in security and performance. The poor performance may be attributable to the unoptimized implementation. As the PR does no good, I will close it then.
p.s. However, both methods lack verifiability, which requires the algorithm able to discriminate the liars (or attackers) who provide wrong shares purposely in order to alter the secret or pretend a database corruption (the latter is more practical and remarkable).  This and this essay give two different improvements on Multi-Secret Sharing Scheme. PTAL.


Remove numpy dependency

Surely we don't need to depend on numpy just for this one calculation?
https://github.com/pyedifice/pyedifice/blob/1e55aa5e06e1740078b883a3470b4387734fbc1a/edifice/base_components.py#L85

Removed numpy dependency.


Invisible selection for blank lines

monaco-editor version: 0.8.3
Browser: Safari Version 10.1 (126<IP_ADDRESS>.34)
OS: macOS Sierra 10.12.4 (16E195)
Selecting one or more blank lines in Safari shows no selection (but it does in Chrome) and instead looks very confusing. Screenshots from playground

A consequence is that clicking on line numbers for empty lines puts the cursor on the next line without any visible selection:

Running the editor from source as described here on HEAD I can't reproduce the error so possible this has already been fixed.

:+1: I also cannot reproduce on master so I think this got fixed in the meantime:


il8n and Missing translation

I have installed version 2.0.0-alpha.14
After the clean install I made a page with a a simple form-for:
{{#form-for model.searchOptions as |f|}}

    {{f.text-field "name"}}
    {{f.text-field "phone"}}
    {{f.email-field "email"}}

    {{#f.reset}}
        <i class="fa fa-times"></i>
        Reset
    {{/f.reset}}

{{/form-for}}

Console started displaying that Attempting to inject an unknown injection: 'service:i18n' is missing.
It looks like form-for's template somehow depends on this service?

Tried this locally, I'm not able to reproduce this. Can you paste the complete error stack here?

How would I go about it?
 I am using canary, it's 2.12.0-alpha.1-canary+6eef3656

Does this error still occur if you revert to 2.10?

Yes, going to v2.10.2 seems to fix it ))

Ok, so there might be a bug in an upcoming ember release.
Installing ember-i18n should be completely optional.

Same issue here with Ember Engine. If run outside Engine, works!
Ember CLI: 2.12.0-beta.1
Ember Engines: 0.5.0-beta.9
Ember Source: 2.12.0-beta.2


Xamarin Forms

Good job.
I am trying to reproduce in Xamarin.Forms, but without success. It is something similar to a dependencyService in use, did you ever do anything in that context?

Minutes after writing this, everything worked :)


How to  disable hyperlink hops in preview mode

Summary
Screenshots

Version
3.1.0

@seanwang1998
We do not provide it.
You can control the anchor style by overriding css.


A restart after a sync can cause the node to panic due to a missing bundle instance

Describe the bug
After a sync and then a restart, the node paniced with not being able to find a bundle corresponding to a transaction it wanted to confirm:
2019/12/17 11:51:01 [ PANIC ] Tangle: confirmMilestone: Tx: XUNCAVRNAOHNJZID9SJ9XTGCTTQ9KPDTBBWHEMKWOCCNYK9RACCUZJTOEHDZDFZWUJLWKXCAZYZH99999, Bundle not found: VAJOHANFEOTRSIPCLG9MIPENDFPLQQUGSBLBHMKZ9XVCUSWIKJOOHSPWJAXVLPTAKMPURYAYD9ONODVOW
panic: [ PANIC ] Tangle: confirmMilestone: Tx: XUNCAVRNAOHNJZID9SJ9XTGCTTQ9KPDTBBWHEMKWOCCNYK9RACCUZJTOEHDZDFZWUJLWKXCAZYZH99999, Bundle not found: VAJOHANFEOTRSIPCLG9MIPENDFPLQQUGSBLBHMKZ9XVCUSWIKJOOHSPWJAXVLPTAKMPURYAYD9ONODVOW

goroutine 404241 [running]:
log.(*Logger).Panicln(0xc000144000, 0xc0083f78a8, 0x2, 0x2)
        /usr/local/go/src/log/log.go:226 +0xaa
github.com/gohornet/hornet/packages/logger.(*Logger).Panicf(0xc0002c53e0, 0xe983ce, 0x2e, 0xc0083f7a20, 0x2, 0x2)
        /__w/hornet/hornet/packages/logger/logger.go:100 +0x1cc
github.com/gohornet/hornet/plugins/tangle.confirmMilestone(0xc00013882b, 0xc0440a52d0)
        /__w/hornet/hornet/plugins/tangle/confirmation.go:73 +0x7ab
github.com/gohornet/hornet/plugins/tangle.solidifyMilestone(0xc000000000)
        /__w/hornet/hornet/plugins/tangle/solidifier.go:334 +0x5e6
github.com/gohornet/hornet/plugins/tangle.configureTangleProcessor.func3(0xc0433da100, 0x1, 0x1, 0xc04b3e7260)
        /__w/hornet/hornet/plugins/tangle/tangle_processor.go:52 +0x4d
github.com/gohornet/hornet/packages/workerpool.(*WorkerPool).startWorkers.func1(0xc000144c30)
        /__w/hornet/hornet/packages/workerpool/workerpool.go:159 +0x1ad
created by github.com/gohornet/hornet/packages/workerpool.(*WorkerPool).startWorkers
        /__w/hornet/hornet/packages/workerpool/workerpool.go:135 +0x5e

Theoretically this can happen because we're triggering a confirmation process for a given milestone, while we didn't yet complete the assignment of a transaction to its bundle.
Note that we:

store a transaction in the LRU cache
the submit an address persister task
only then map the transaction to its bundle bucket

To Reproduce
Steps to reproduce the behavior:

Sync up from LS
Restart
Maybe panics

Expected behavior
Shouldn't panic.
Environment information:

OS: Ubuntu 16.04
RAM: 64 GB
Cores: 8 Cores
Type: Hetzner dedicated server
HORNET version  0.2.7

This still happened after Merge pull request #62 2019/12/17 11:50:32 [ INFO ] Tangle: Run solidity check for Milestone (1280459)... 2019/12/17 11:50:32 [ INFO ] Tangle: Solidifier finished (9): passed: true, tx: 13, collect: 1.50931ms, total: 1.575247ms, entryTx: 0 2019/12/17 11:50:32 [ PANIC ] Tangle: confirmMilestone: Tx: YXVJAVJHCCWNSYETQHBYO9UZAOHNKIOTAJ9KOOFYYWIUKIDPTIAXQIPLOICV9LNSGXQJKRBKHGGLA9999, Bundle not valid: VAJOHANFEOTRSIPCLG9MIPENDFPLQQUGSBLBHMKZ9XVCUSWIKJOOHSPWJAXVLPTAKMPURYAYD9ON ODVOW panic: [ PANIC ] Tangle: confirmMilestone: Tx: YXVJAVJHCCWNSYETQHBYO9UZAOHNKIOTAJ9KOOFYYWIUKIDPTIAXQIPLOICV9LNSGXQJKRBKHGGLA9999, Bundle not valid: VAJOHANFEOTRSIPCLG9MIPENDFPLQQUGSBLBHMKZ9XVCUSWIKJOOHSPWJAXVLPTAKMPURYAYD9ONODVOW goroutine 373884 [running]: log.(*Logger).Panicln(0xc000124000, 0xc01963b8a8, 0x2, 0x2)         /usr/local/go/src/log/log.go:226 +0xaa github.com/gohornet/hornet/packages/logger.(*Logger).Panicf(0xc0002a2c00, 0xe9e376, 0x2e, 0xc01963ba20, 0x2, 0x2)         /home/plex/hornet/packages/logger/logger.go:100 +0x1cc github.com/gohornet/hornet/plugins/tangle.confirmMilestone(0xc0001389cb, 0xc00015ca10)         /home/plex/hornet/plugins/tangle/confirmation.go:77 +0x6d2 github.com/gohornet/hornet/plugins/tangle.solidifyMilestone(0xc000000000)         /home/plex/hornet/plugins/tangle/solidifier.go:334 +0x5e6 github.com/gohornet/hornet/plugins/tangle.configureTangleProcessor.func3(0xc04d230b20, 0x1, 0x1, 0xc02f0485a0)         /home/plex/hornet/plugins/tangle/tangle_processor.go:52 +0x4d github.com/gohornet/hornet/packages/workerpool.(*WorkerPool).startWorkers.func1(0xc000332370)         /home/plex/hornet/packages/workerpool/workerpool.go:159 +0x1ad created by github.com/gohornet/hornet/packages/workerpool.(*WorkerPool).startWorkers         /home/plex/hornet/packages/workerpool/workerpool.go:135 +0x5e plex@plexserver:~/hornet$

Should be solved with #199


OpenWeatherAPI is incorrect

Challenge Show the Local Weather has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
I would have liked to use OpenWeaterAPI to complete this challenge however the service isn't up to date and isn't working. When I make the api calls I am receiving data that is incorrect and out of range of anything I should be receiving. Is there another service that someone can recommend? I will continue my search for an alternative.

I have completed that project and I never got the forecast for my district , It was always the data for another city. The point is that the data is not what's important in the challenge but rather if you know how to call the API and how to interpret said data. Don't let the inaccuracy of the service stop you from completing this project.

You may be getting results in Kelvin, which is the default for that API unless you explicitly specify Fahrenheit or Celsius.
This API works "well enough" and is free, so that is what we recommend.  You can search google for other APIs, since there is no requirement that you use this specific one.
I encourage you to ask for help in HelpFrontEnd for more details.
Thanks and Happy Coding!


Add an option to open GitHub profiles from code pics

This is not in there on purpose to protect privacy, but I could see having this as an option if someone wanted to share

I do like this idea but I agree on the privacy thing. Perhaps an option in your profile to allow anyone to click it, or only matches.

Maybe by default, it doesn't share it, but in the settings, there could be an option to do that.

Notably, on the other side of this, because people are bad at making up names and their GitHub profile picture is visible.  It's currently not very hard to find their page.  This might be bad but unfixable. (It's probably also possible to watch the app make the profile's image request and get it from there.)

Wanted to note, from VS code itself, it's relative trivial to drag-drop the image onto your desktop or directly into the browser, which then exposes the URL of the avatar pic which contains the users GitHub NUMERIC id. Using that ID you can then query this API endpoint: "https://api.github.com/user/:id". The JSON results will then reveal the rest of the information that you need to know to find their GitHub home page. Here's mine for example: "https://api.github.com/user/15203217". So if the idea is to prevent this, then these profile pictures need to be copied into a CDN or other file storage mechanism. Or maybe some sort of URL proxy re-write mechanism? Either way, if either ID is known (either through packet sniffing or other means) then the home page can be discovered. I'd imagine that GitHub has some privacy settings on whether your profile is accessible publicly, but unconfirmed since I didn't dig that far. I think it would be a good idea to give the user the option whether to expose their GitHub profile home page, and maybe also their social media endpoints.

That's a good point


Quirky CSS icon

Describe the bug
CSS icon appears misaligned.
To Reproduce
Steps to reproduce the behavior:

Go to the Screenshot part of that repository.
Scroll down to 'Most Used Languages'.
Look at CSS icon which appears misaligned.

Hi @GitNinja-bcd are ou referring to this Stackoverflow project, we don't use CSS, could you check that again

@sanjay-kv  could you assign this to me ?

Can I solve this issue?
Kindly assign me I will definitely solve it.

@sanjay-kv  my issue is related to gitglance project.

@GitNinja-bcd I still didn't get you . if its related to some other repository you should ask here. i don't see its relevant to current repo. And gitglance project is not managed by me, so I wont be able to assign

@sanjay-kv  could you assign this to me ?

@sanjay-kv yes, this is related to another repository.
I accidentally raised the issue here. I can understand that you can't assign it. Thank you.


Migrate Site Google Analytics to GA4

Related to https://github.com/meltano/internal-data/issues/89
We need to migrate to the new GA4 property. This is my understanding of what we need to do:

It sounds like we click some buttons in the GA UI to create a new GA4 "property" (i.e. entity in GA, each one of our websites is currently its own property) for the thing we want to migrate, if we dont do this manually theyll soon do it for us automatically. Then to activate it and start sending our events to the new GA4 we need to update our javascript snippets that send the events and include a "tag" manually or use google tag manager (I'm not yet sure what that is). After that point we'll have events flowing to our new "property".

This is already completed.


[Bug][zentao] Collect data error with zentao v18.5

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
When collect bug data  , the task failed:
time="2023-09-15 17:13:22" level=warning msg=" [pipeline service] [pipeline #2] [task #7] [api async client] retry #0 calling /projects/575/bugs\n\tcaused by: Http DoAsync error calling [GET /projects/575/bugs]. Response: {"status":"success","data":"{\"locate\":\"http:\\\/\\\/<IP_ADDRESS>:8765http:\\\/\\\/<IP_ADDRESS>:8765\\\/user-deny-project-bug.json\"}","md5":"a833d1a5f58b294fbcd5c623d39eb433"}\n\t17:13:22 Uncaught Error: Call to undefined method helper::end() in module/common/model.php:413\n\tStack trace:\n\t#0 module/project/model.php(2867): commonModel->deny('project', 'bug', false)\n\t#1 module/project/control.php(1174): projectModel->setMenu('575')\n\t#2 api/v1/entries/projectbugs.php(27): project->bug('575', 0, 0, 'status,id_desc', 0, 'all', 0, 0, '100', '1')\n\t#3 framework/api/router.class.php(216): projectBugsEntry->get('575')\n\t#4 www/api.php(49): api->loadModule()\n\t#5 {main}\n\t  thrown in module/common/model.php on line 413 when visiting \n\t (403)"
What do you expect to happen
collect bug data into lake
How to reproduce
collect data from zentao v18.5
Anything else
where test the " /projects/575/bugs " with postman ,it have same error ,ant I can't find this api in zentao's apidoc
Version
release_v0.19
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Devlake is tested in zentao open source version 18.3. We need some time to upgrade to 18.5.
@mickey50


CI: Add additional project approvers

Add @dlespiau and @grahamwhaley as additional project approvers.
Fixes #44.
Signed-off-by: James O. D. Hunt<EMAIL_ADDRESS>

lgtm

I am okay with adding several approvers/reviewers but everybody needs to be careful about merging some patches on this repo because we don't have any CI right now and I don't want things to end up broken.
Other than that, you need to rebase your PR I think.
LGTM

added #55 to add ci for testing.

Hah, looks like @jcvenegas beat me to opening the 'add CI' Issue :-)
@jodh-intel this looks like it needs a rebase (hmm, actually, isn't there a github setting that @dlespiau chanced on the clearcontainers/tests repo recently to only block merges if they are not merge-able, rather than if they are just 'out of date' (but potentially still merge-able)... /me goes to look at the settings...


Final GUI Goal

The goal with the GUI is to make something very similar to this concept
For now, the GUI will look similar to the Switch settings menu

BTW, I'll make sure the GUI fits the Switch more


Deis Workflow v2.9.1 deis pull deis/example-go -a  Error

I'm trying to test Deis Workflow. My cluster is good and running fine, but when i try to do
deis pull deis/example-go -a  molten-electron
I'm getting error
Creating build... Error: Unknown Error (400): {"detail":"'NoneType' object is not iterable"}
When i look into the logs for deis-controller using
kubectl logs -f deis-controller-2092062600-xdd1g --namespace=deis
i get error
INFO Pulling Docker image deis/example-go:latest
INFO Tagging Docker image deis/example-go:latest as localhost:5555/molten-  electron:v2
INFO Pushing Docker image localhost:5555/molten-electron:v2
INFO Pulling Docker image localhost:5555/molten-electron:v2
INFO Pulling Docker image localhost:5555/molten-electron:v2
INFO [molten-electron]: adding 5s on to the original 120s timeout to account   for the initial delay specified in the liveness / readiness probe
INFO [molten-electron]: This deployments overall timeout is 125s - batch timout is 125s and there are 1 batches to deploy with a total of 1 pods
INFO [molten-electron]: waited 10s and 1 pods are in service
INFO [molten-electron]: waited 20s and 1 pods are in service
INFO [molten-electron]: waited 30s and 1 pods are in service
INFO [molten-electron]: waited 40s and 1 pods are in service
INFO [molten-electron]: waited 50s and 1 pods are in service
INFO [molten-electron]: waited 60s and 1 pods are in service
INFO [molten-electron]: waited 70s and 1 pods are in service
INFO [molten-electron]: waited 80s and 1 pods are in service
INFO [molten-electron]: waited 90s and 1 pods are in service
INFO [molten-electron]: waited 100s and 1 pods are in service
INFO [molten-electron]: waited 110s and 1 pods are in service
INFO [molten-electron]: waited 120s and 1 pods are in service
ERROR:root:'NoneType' object is not iterable
Traceback (most recent call last):
File "/app/api/models/build.py", line 65, in create self.app.deploy(new_release)
File "/app/api/models/app.py", line 545, in deploy
release.cleanup_old()
File "/app/api/models/release.py", line 267, in cleanup_old
for controller in controllers['items']:
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/rest_framework/views.py", line 474, in dispatch
response = handler(request, *args, **kwargs)
File "/app/api/views.py", line 185, in create
return super(AppResourceViewSet, self).create(request, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/rest_framework/mixins.py", line 21, in create
self.perform_create(serializer)
File "/app/api/viewsets.py", line 21, in perform_create
self.post_save(obj)
File "/app/api/views.py", line 268, in post_save
self.release = build.create(self.request.user)
File "/app/api/models/build.py", line 79, in create
raise DeisException(str(e)) from e
api.exceptions.DeisException: 'NoneType' object is not iterable
<IP_ADDRESS> "POST /v2/apps/molten-electron/builds/ HTTP/1.1" 400 46 "Deis Client v2.9.1"

Can you guys please help what went wrong?

This error occurs on kubernetes v1.5.1. Can you try this using Workflow v2.9.1? We explicitly rolled that out yesterday for 1.5.1 compatibility.

for reference: https://github.com/deis/controller/pull/1178

I'm using Deis v2.9.1 and
kubernetes version is
Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.6", GitCommit:"e569a27d02001e343cb68086bc06d47804f62af6", GitTreeState:"clean", BuildDate:"2016-11-12T05:22:15Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+coreos.0", GitCommit:"cc65f5321f9230bf9a3fa171155c1213d6e3480e", GitTreeState:"clean", BuildDate:"2016-12-14T04:08:28Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
But still getting the issue

Can you confirm with deis version --all? That exact code:
for controller in controller['items']:
Was what was fixed in v2.9.1.

when i did deis version --all i get

Workflow CLI Version:            v2.9.1
Workflow CLI API Version:        2.3
Workflow Controller API Version: 2.3

can you please tell me how to upgrade the version. do I need to update deis version or only Controller api version, Im already using deis v2.9.1

Your client is v2.9.1 but you need to upgrade the platform as well.
You'll need to follow the upgrading documentation to upgrade the platform. You'll want to upgrade to v2.8 or v2.9 via helm-classic, then use the workflow-migration project to migrate over to helm. From there you'll want to run helm upgrade to bring the platform up to v2.9.1.
Hope this helps!

Just an FYI that you might want to upgrade your kubectl client as well. Your kubernetes cluster is at v1.5.1 but your client is at v1.4.6.

i did
helm upgrade chucky-bucky  deis/workflow --version=v2.9.1
but i got
Fetched deis/workflow to workflow-v2.9.1.tgz
Error: UPGRADE FAILED: release: not found

That's why I said

You'll want to upgrade to v2.8 or v2.9 via helm-classic first, then use the workflow-migration project to migrate over to helm. From there you'll want to run helm upgrade to bring the platform up to v2.9.1.

I did
helm list
and got back

NAME          	REVISION	UPDATED                 	STATUS  	CHART
xrayed-unicorn	1       	Fri Dec 16 20:59:08 2016	DEPLOYED	workflow-migration-v1.0.0
yucky-gecko   	2       	Fri Dec 16 21:39:36 2016	DEPLOYED	workflow-v2.9.1

i guess i have updated deis :) . how to verify it

use deis version --all again.

its saying

Workflow CLI Version:            v2.9.1
Workflow CLI API Version:        2.3
Workflow Controller API Version: 2.3

but earlier

yucky-gecko 2 Fri Dec 16 21:39:36 2016	DEPLOYED	workflow-v2.9.1

was

yucky-gecko 2 Fri Dec 16 21:39:36 2016	DEPLOYED	workflow-v2.9.0

I'd check your client settings and ensure it's targeting the right endpoint. You might be hitting a different cluster then. Check the troubleshooting docs if you're having more trouble.
$ cat ~/.deis/client.json
$ deis login http://blahblah...

It worked I'm now able to deploy the application.
I setup coreos cluster in Virtual box and then Kubernetes and then deis, now everything is working fine,
Thanks a lot 👍.
Now i want to see the deis workflow dashboard for monitoring loging and cluster health, can you point me in right direction.
Thanks :)

https://deis.com/docs/workflow/managing-workflow/platform-monitoring/
https://deis.com/docs/workflow/managing-workflow/platform-logging/


Fix float parsing

Fixes #35, by avoiding floating point operations such as addition and multiplication, and using the Read Double instance instead.
I used @mrkkrp's tests from his old pull request and enabled them, they now pass.

Also, thanks for maintaining Parsec :) Please ask if there's any additional context I might be able to provide.

Thanks for the fix!


Crossplatform compatibility

Does the library work with .net core on mac or linux?

Yes! It's multi-targeted so it supports multiple target frameworks, one of them is .NET Standard 2.0.
I've successfully used this on Windows, macOS and Linux. You just need to ensure to use the right adb executable for the platform you're running on.

Yes! It's multi-targeted so it supports multiple target frameworks, one of them is .NET Standard 2.0.
I've successfully used this on Windows, macOS and Linux. You just need to ensure to use the right adb executable for the platform you're running on.

Awesome, I tried it and it works great. This is the only good crossplatform compatible ADB library I was able to find.

Awesome, I tried it and it works great. This is the only good crossplatform compatible ADB library I was able to find.


Creates the AUTHORS file.

Congrats on first PR!

Congrats on first PR!

Congrats on first PR!

Thank you!


fix(Dockerfile): update grpc_health_probe in second Dockerfile

Description

Updates the grpc_health_probe in the Dockerfile that is used to publish to Docker (unsure what the other Dockerfile is used for but the published image has CVE's active against it due to the older health probe)
References

https://github.com/orgs/openfga/discussions/290
https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.4.26
Review Checklist

[x] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[ ] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Hey @jakereps, thanks for opening this. As you pointed out in the discussion, we actually do have Snyk working for us and it detected that the version was old 😅 https://github.com/openfga/openfga/pull/1681.
I'm going to close this PR in favor of that one.
Thanks again!

Works for me! Almost bumped them both myself, but figured I'd start with just version parity and see if a version jump was desired. Thanks!


Is there linux alternative?

NIce questions

CopyQ supports most if not all the same features. It has some issues with Wayland, but there's a workaround in the FAQ if you use it.
I had partial success migrating my folders and named snippets from Clipy's exported xml into CopyQ using the bit of bash below. You'll need jq (probably available in your distro's package manager) and xq. xq comes in the pip3 package yq.
python3 -c '
import json, subprocess, sys
i = json.loads(sys.argv[1])
for item in i:
    for folder, snippets in item.items():
        for snippet in snippets:
            for note, content in snippet.items():
                subprocess.run(
                  [
                    "copyq", "eval", "--",
                    f"tab(\"{folder}\"); write(0, mimeItemNotes, \"{note}\", mimeText, \"{content}\");"
                  ]
                )

' "$(xq -r '[.folders[][] | {(.title): (.snippets[] | map({(.title): .content}))}]' .shared/snippets.xml)"

Keyword was "partial" success. Some of my Clipy snippets didn't quite translate well into CopyQ's DSL and I wound up with syntax errors on about a third--mostly snippets that contained long shell commands (so probably screwed with quoting). Luckily, it's a small enough number it won't be a problem to do the rest by hand.
Tbh, Clipy hits that sweet-spot of being feature-rich while staying simple and intuitive. CopyQ is arguably more powerful, but it's harder to use. Here's hoping for a Linux port!

yeah would love a linux port


[RTL] Add support for image dynamic updating, padding, tooltips and size in percent.

Adds method to update RTL images without changing the text.
Adds support for small image padding.
Adds support for image size in percent of control width.

RTL only part of https://github.com/godotengine/godot/pull/69751

There is some changes to be rebased @bruvzg

Thanks!


[Bug]: TagPicker item error state is not working

Contact Details
No response
What happened?
When I set hasError on a TagPicker selectedResults item, there's no red border :

Also, when the TagPicker with error prop set to true isFocused, the border is blue instead of red :

Component
TagPicker
Component Version
0.3.0
Which browsers are you seeing the problem on?
No response
Mobile Device
No response
Relevant log output
No response

We'll add this issue to our backlog and prioritize it.
As far as the focus behavior is concerned, this is what is expected during a focus. Our input components all work on the same principle.

Thanks!
Ok for the focus + error state. I've just found it weird to have a red error message but a blue border :P No problem if it is as designed!


Support when-like condition

Split from #5.
My current thinking on this is at https://github.com/VSpaceCode/vscode-which-key/issues/5#issuecomment-667554135

Just jotting here. We will likely need another context variable like whichKeyVisible so we the the shortcut hack won't be executing when if the command is long running like renaming a reference/variable.

could this enable major mode?

Can you elaborate a little bit more? I am not familiar with major mode.

In spacemacs you have major-modes, like "python", "markdown", and so on. So for example if you open a .md file spacemacs will use Markdown mode in that buffer.
When you are using a mode, key bindings under <spc> m or under , will be unique to that mode.
This means that when you are editing a markdown, <spc> m b could be assigned to "make bold", while in python <spc> m b could be assigned to "toggle breakpoint" (I am just inventing).

Thank you for the clear explanation. I think this work should take this into account and facilitate major mode as well if we are implementing a type called "conditional".

I have a working prototype on conditionals branch; however, as I am trying implement overrides (add/delete/modify) for conditional bindings. I realized that the condition in a conditional binding is basically the key in regular binding but instead of string, we defined it as object.
If a user wants to redefined the condition, the user can use the following example to override the whole conditional binding.
{
    "bindingOverrides": [
        {
            "keys": "m",
            "name": "Major",
            "conditional": [
                {
                    "type": "bindings",
                    "bindings": []
                },
                {
                    "type": "bindings",
                    "name": "JavaScript",
                    "bindings": [],
                    "condition": {
                        "langId": "javascript"
                    }
                }
            ]
        }
    ]
}

In order to implement the traversal of the conditional bindings, I have to re-use the keys in the current overrides format in the following example.
The example is an override for conditional binding with a key of m. In this case the last key will be read as condition for the command with the format of a query string. This will add/modify the conditionals depending if "languageId=typescript" exists. This is also powerful that it can traverse through the conditional bindings (examples keys: ["m", "languageId=typescript", "i"]). Note, this is possible because we do not implicitly any bindings if the part of the key sequence doesn't exist in the overrides.
"bindingOverrides": [
    {
        "keys": ["m", "languageId=typescript"],
        "name": "123",
        "type": "command",
        "command": "workbench.action.editor.changeLanguageMode"
    }
]

Although, this works for the most part, There are two things that bug me with the current implementation.

The asymmetry of bindings and overrides (one using object to present condition and other use a query string)
Working the issue backward, in order to unify them I think we can use query string to represent the condition as key, and then we can reuse the "bindings" key without introducing a new key. An example binding is as follow:

{
    "key": "m",
    "name": "Major mode",
    "type": "conditional",
    "bindings": [
        {
            "key": "",
            "type": "bindings",
            "bindings": [...],
        },
        {
            "key": "langId=javascript"
            "type": "bindings",
            "bindings": [...],
        }
    ],
}

Needs to escape query string for some character
This is especially prominent if we have a "when" condition that uses & (e.g. sideBarVisible && explorerViewletVisible) and it makes the config not humanly readable. The example override with escape characters.

"bindingOverrides": [
    {
        "keys": [
            "m",
            "when=sideBarVisible%20%26%26%20explorerViewletVisible"
        ],
        "name": "123",
        "type": "command",
        "command": "workbench.action.editor.changeLanguageMode"
    }
]

I am thinking

Use a custom query string that uses ; as separator instead of &
Use a custom query string as the key for conditional binding instead of condition like I mentioned above.
Instead of adding a new key conditionals, we can then reuse the key bindings
This has also the added benefit of reuse the same schema validation

Just implemented a custom query string, that cleaned up both the code and the config a bit :)

Released v0.8.0 with this :)


Fixed the behavior of validate_user function in validations.py

Added additional validation checks for '.', '_' special characters at the first index of the username argument.

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

Submitted CLA agreement.


No binary for arm64 when installing semantic-release-cargo

I did npm install --global @semantic-release-cargo/semantic-release-cargo on a linux/arm64 machine and I find modules for macOS/arm64, but not for linux/arm64
find / -name "semantic-*"
/usr/local/lib/node_modules/@semantic-release-cargo/semantic-release-cargo
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

Hi there -- thanks for the report. The three existing targets are hard-coded in this matrix:
https://github.com/semantic-release-cargo/semantic-release-cargo/blob/8aea855446cd678d779469dbf3e94136556eea88/.github/workflows/release.yml#L172-L199
To add support for aarch64 Linux, we'll need to extend that strategy, and make a few other trivial edits to the release workflow.
The main reason there is no aarch64-linux binary published is GitHub Actions does not offer an ARM Linux runner, which means we'd have to cross-compile. It may be possible to get something working, following this example: https://github.com/napi-rs/cross-build/blob/main/.github/workflows/pure-rust-build-on-linux.yml
However, it is currently a low priority. Contributions always welcome :slightly_smiling_face:

Likely these will be coming soon.
https://github.blog/changelog/2023-10-30-accelerate-your-ci-cd-with-arm-based-hosted-runners-in-github-actions/

Hey just following up, looks like these went GA. We might be able to proof of concept this.


[ci skip] adding user @gmarkall

Hi! This is the friendly automated conda-forge-webservice.
I've added user @gmarkall as instructed in #20.
Merge this PR to add the user. Please do not rerender this PR or change it in any way. It has [ci skip] in the commit message to avoid pushing a new build and so the build configuration in the feedstock should not be changed.
Please contact conda-forge/core to have this PR merged, if the maintainer is unresponsive.
Fixes #20

I'm not sure why CI didn't skip, but it looks like I have messed up the tags on the upstream repo.

ci-skip refers to skipping triggering the CI when merged into main, not in the PR.

I'm going to retry this now that the package tags have been fixed.


Regent: CUDA Error Misaligned Address

I have recently encountered an issue with CUDA code generation in Regent for my CFD solver.
When the kernel is run with GPU support, it fails with: [0 - 7f7682550780]    0.211192 {6}{gpu}: CUDA error reported on GPU 0: misaligned address (CUDA_ERROR_MISALIGNED_ADDRESS) terra: /home/legion/runtime/realm/cuda/cuda_module.cc:329: bool Realm::Cuda::GPUStream::reap_events(Realm::TimeLimit): Assertion 0' failed..
I have run this code with compute_sanitizer, which points to multiple global read errors.
compute_sanitizer.log). The code runs fine on CPU-only mode (with -fbounds-checks 1), and the issue only pops up for GPU mode.
I am unsure what is causing this issue, and to help debug, I have made a reasonably small reproducer. Please find it in this link: https://gist.github.com/ReadingSteiner122/4e469e90bd75162b76e0cbfe4619fc1a

I have replicated these results on Sapling with latest master (29ba5797bfb1d1512e25595e7d7e580dbcd89278). GPU code fails as described, CPU code with -fbounds-checks 1 passes.
I am currently swamped; does anyone else have time to look at this?
@ReadingSteiner122 one way you can help us would be to further minimize the reproducer. I appreciate that the current reproducer is already 171 lines, but the smaller it is, the easier it will be for one of us to diagnose the issue. Ideally, remove every single line that does not directly contribute to the issue. You can also replace the math with dummy values (e.g., temp[k] = 1.0), assuming that doing so does not cause the issue to go away. The issue appears to be deterministic, so it should hopefully be reasonable to cut it down more.

Upon @elliottslaughter's suggestion, I've shortened the reproducer further. It's now 94 lines, and the kernel causing the issue should be easier to understand. I'll keep trying to shorten the kernel in question. Please let me know if there's anything else I can do to help.

Okay so I have an update on this issue.
It doesn't appear if conn : int[27] is replaced with conn : regentlib.array(int, 27) in the declaration of the fspace. If I replace all the regentlib.arrays with their corresponding int or double arrays, the issue still persists.
I hope this helps with debugging. I am attaching a reproducer with the change made.
https://gist.github.com/ReadingSteiner122/cd3f413c1c67423cc44fa27f8fb93eff

Thanks for helping to minimize the reproducer.
Here's the shortest version I've been able to come up with (57 lines):
import "regent"

-- runs with -ll:gpu 1

local N=3
local M=1
local L=1
fspace point{
    conn : int[N], -- does NOT fail with regentlib.array(int, M)
    q : regentlib.array(double, M), -- also fails with double[M]
    dq : regentlib.array(double, L), -- also fails with double[L]
};

__demand(__cuda)
task cudaErrorTest(pe : region(ispace(int1d), point)) where
reads (pe.{conn, q, dq}),
writes (pe.{dq})
do
    for point in pe do
        var sum_delx_test : double = 0.0
        for r = 0, M do
            -- sum_delx_delq[r] += (pe[nbh].q[r] - ÷point.q[r]) -- throws error
            -- sum_delx_test += (pe[nbh].q[r] - point.q[r]) -- throws error
            -- sum_delx_test += point.q[r] -- throws error
            -- sum_delx_test += pe[nbh].q[r] -- throws error
            sum_delx_test += pe[point].q[r] -- throws error
            -- sum_delx_test += 10.0 -- no more error, so it's probably having issues accessing the q field(?)
        end
        for k = 0, L do
            point.dq[k] = sum_delx_test
        end
    end
end

task init_point(points : region(ispace(int1d), point)) where
reads writes (points)
do
    for point in points do
        for i = 0, N do
            point.conn[i] = 1
        end
        for i = 0, M do
            point.q[i] = 1.0
        end
        for i = 0, L do
            point.dq[i] = 0.0
        end
    end
end

task main()
    var points = region(ispace(int1d, 3), point)
    init_point(points)
    cudaErrorTest(points)
end
regentlib.start(main)

You're right that it seems to be sensitive to the data type in the fspace. It also seems to be sensitive to the size of the region (must be odd) and also the size of some of the arrays (but not all—some can be reduced down to 1 element). I haven't found any major element of the code that can be reduced from here.
I don't have time to look at this more today, but hopefully it's a matter of looking at the generated code to see what the issue is (or if the code seems fine, then producing a pure Terra reproducer that shows Terra is miscompiling something).

As for AOS layout, see this comment for an example of the syntax: https://github.com/StanfordLegion/legion/issues/1375#issuecomment-1382291350
(And note you need to use regentlib.array for this to work.)

I don't know why this didn't occur to me before, but it may be that the instance is literally misaligned (i.e., double data type aligned on a 4-byte boundary). I'll try to check for this when I get the time.

The fields are indeed misaligned:
base pointer for field 101 (type int32[3]) is 0x7f4c9e000000
  after adjustment: 0x7f4c9e000000
base pointer for field 102 (type double) is 0x7f4c9e000024
  after adjustment: 0x7f4c9e000024
base pointer for field 103 (type double) is 0x7f4c9e000040
  after adjustment: 0x7f4c9e000040
[0 - 7f4ced84c780]    0.383070 {6}{gpu}: CUDA error reported on GPU 0: misaligned address (CUDA_ERROR_MISALIGNED_ADDRESS)
terra: /scratch2/eslaught/legion_compute/runtime/realm/cuda/cuda_module.cc:329: bool Realm::Cuda::GPUStream::reap_events(Realm::TimeLimit): Assertion `0' failed.

Field 102 is type double and is aligned on a 4-byte boundary.
The following workaround is not general, but is sufficient to fix the reproducer (and provide that my diagnosis is correct):
diff --git a/language/src/regent/std.t b/language/src/regent/std.t
index 9a821eaa84..e48a935cde 100644
--- a/language/src/regent/std.t
+++ b/language/src/regent/std.t
@@ -3843,6 +3843,13 @@ local function make_normal_layout(dim)
     c.legion_layout_constraint_set_add_specialized_constraint(
       layout, c.NORMAL_SPECIALIZE, 0)

+    c.legion_layout_constraint_set_add_alignment_constraint(
+      layout, 101, c.LEGION_EQ_EK, 4)
+    c.legion_layout_constraint_set_add_alignment_constraint(
+      layout, 102, c.LEGION_EQ_EK, 8)
+    c.legion_layout_constraint_set_add_alignment_constraint(
+      layout, 103, c.LEGION_EQ_EK, 8)
+
     var [layout_id] = c.legion_layout_constraint_set_preregister(layout, "SOA")
     c.legion_layout_constraint_set_destroy(layout)
   end

@lightsighter This is not code that Regent can produce in general. Regent tasks can be called with any (potentially dynamic) field IDs. While we know the field type and its position in a region requirement, we can't name it like this statically. Can we either (a) improve the expressivity of field constraints to support this or (b) make smarter default assumptions in Legion so that we don't need to do this in the first place? (E.g., it seems reasonable to default-align an 8-byte field to 8 bytes.)

@elliottslaughter fwiw, we discussed option (a) in this issue, though the proposal hasn't been materialized into code yet.

fwiw, we discussed option (a) in https://github.com/StanfordLegion/legion/issues/855, though the proposal hasn't been materialized into code yet.

Right, I agree, this is a special case of #855. I think the thoughts that I express on that issue are all still accurate. I'm still in favor of doing it, but someone needs to go design the actual interface and describe it's semantics and then we can put it in the runtime.

I skimmed #855, though I have not read it in detail. To be honest, it seems like massive overkill. We could solve 99% of the issues described here with a simple set of rules that would work for almost everyone:
If no alignment constraint is specified by a task or mapper, and

field size <= 1 byte: align to 1 byte
2 <= field size <= 3 bytes: align to 2 bytes
4 <= field size <= 7 bytes: align to 4 bytes
8 <= field size <= 15 bytes: align to 8 bytes
16 <= field size <= 31 bytes: align to 16 bytes
32 <= field size: align to 32 bytes

(Obviously, if the task or mapper specifies an alignment constraint, use that in favor of these defaults.)
Sure, there are weird cases where you need different alignment constraints, but that's the 1% case. That's what alignment constraints are for. If someone needs that and polymorphic constraints, they can push on #855.
The wasted space by applying this by default will be trivial. @lightsighter will need to speak to the runtime costs, but I can't imagine them being more onerous than #855.

I added this to the agenda for the Legion meeting for this week.
We've had this discussion before with the LANL folks over a different alignment issue, and I'm going to continue asserting the same opinion here that I did with them. I don't believe that Legion should be in the business of prescribing any default constraints for instance layouts, especially not ones that are architecture specific and necessary for correctness like alignment ones are. If users need to add padding for correctness, that is something they need to communicate to the runtime via the layout constraints on the task variant, and not rely on implicit behavior inside the runtime, lest someone comes along and overrides the mapper to create instances with different layout constraints and implicitly break the correctness of the code.
Now if you want to make the default mapper apply these heuristics on all instance creations, then I would have no objections to that at all. I still think users should express correctness properties on the task variant constraints, but if they're not going to do that, then they accept the risk of understanding what the mapper(s) is/are doing. They should never need to look inside the runtime though to figure out what is happening.
As another pedantic example of what can go wrong: what happens when the user specifies an AOS layout of fields, now Legion would be in a position of solving an optimization problem (specifically ILP) with the constraints above and trying to find an order for the field creates the smallest struct while still abiding by the constraints. Or if we don't do that, we might introduce massive overhead (potentially >> 100%) overhead in the size of the instance. We don't want to be in that position.

especially not ones that are architecture specific and necessary for correctness like alignment ones are.

I don't find this compelling; it's easy to be conservative and the cost (except perhaps in non-SOA) is so low as to be trivial.

lest someone comes along and overrides the mapper to create instances with different layout constraints and implicitly break the correctness of the code.

I agree with this point. This is a legitimate risk.
One other workaround I could do is have Regent apply some default alignment, e.g., to 32 bytes, to all instances. It's a big, ugly hack but it's the best I can do without #855. It would apply to Regent's default SOA layout constraints only, so users would be able to override it by providing their own layout constraints. This would resolve the vast majority of issues we've seen related to this in practice.

Here's the default alignment algorithm I'm proposing, expressed as a Python 3 program:
def alignment(x):
    return min(1 << math.floor(math.log2(x)), 64)

Here's a table of what it produces for the first 200 values:
>>> {x: alignment(x) for x in range(1,200)}
{1: 1, 2: 2, 3: 2, 4: 4, 5: 4, 6: 4, 7: 4, 8: 8, 9: 8, 10: 8, 11: 8, 12: 8, 13: 8,
14: 8, 15: 8, 16: 16, 17: 16, 18: 16, 19: 16, 20: 16, 21: 16, 22: 16, 23: 16,
24: 16, 25: 16, 26: 16, 27: 16, 28: 16, 29: 16, 30: 16, 31: 16, 32: 32, 33: 32,
34: 32, 35: 32, 36: 32, 37: 32, 38: 32, 39: 32, 40: 32, 41: 32, 42: 32, 43: 32,
44: 32, 45: 32, 46: 32, 47: 32, 48: 32, 49: 32, 50: 32, 51: 32, 52: 32, 53: 32,
54: 32, 55: 32, 56: 32, 57: 32, 58: 32, 59: 32, 60: 32, 61: 32, 62: 32, 63: 32,
64: 64, 65: 64, 66: 64, 67: 64, 68: 64, 69: 64, 70: 64, 71: 64, 72: 64, 73: 64,
74: 64, 75: 64, 76: 64, 77: 64, 78: 64, 79: 64, 80: 64, 81: 64, 82: 64, 83: 64,
84: 64, 85: 64, 86: 64, 87: 64, 88: 64, 89: 64, 90: 64, 91: 64, 92: 64, 93: 64,
94: 64, 95: 64, 96: 64, 97: 64, 98: 64, 99: 64, 100: 64, 101: 64, 102: 64,
103: 64, 104: 64, 105: 64, 106: 64, 107: 64, 108: 64, 109: 64, 110: 64,
111: 64, 112: 64, 113: 64, 114: 64, 115: 64, 116: 64, 117: 64, 118: 64,
119: 64, 120: 64, 121: 64, 122: 64, 123: 64, 124: 64, 125: 64, 126: 64,
127: 64, 128: 64, 129: 64, 130: 64, 131: 64, 132: 64, 133: 64, 134: 64,
135: 64, 136: 64, 137: 64, 138: 64, 139: 64, 140: 64, 141: 64, 142: 64,
143: 64, 144: 64, 145: 64, 146: 64, 147: 64, 148: 64, 149: 64, 150: 64,
151: 64, 152: 64, 153: 64, 154: 64, 155: 64, 156: 64, 157: 64, 158: 64,
159: 64, 160: 64, 161: 64, 162: 64, 163: 64, 164: 64, 165: 64, 166: 64,
167: 64, 168: 64, 169: 64, 170: 64, 171: 64, 172: 64, 173: 64, 174: 64,
175: 64, 176: 64, 177: 64, 178: 64, 179: 64, 180: 64, 181: 64, 182: 64,
183: 64, 184: 64, 185: 64, 186: 64, 187: 64, 188: 64, 189: 64, 190: 64,
191: 64, 192: 64, 193: 64, 194: 64, 195: 64, 196: 64, 197: 64, 198: 64,
199: 64}

Sean convinced me that the original version is too conservative. In particular, if an object contains a field that must be aligned to N bytes, the compiler will round up the object's size to N bytes. Therefore, we need only align by the largest power of 2 that divides the total size.
In Python 3, where x is sizeof(T):
def alignment(x):
    return x & ~(x - 1)

Examples going up to 200 bytes:
{1: 1, 2: 2, 3: 1, 4: 4, 5: 1, 6: 2, 7: 1, 8: 8, 9: 1, 10: 2, 11: 1, 12: 4, 13: 1,
14: 2, 15: 1, 16: 16, 17: 1, 18: 2, 19: 1, 20: 4, 21: 1, 22: 2, 23: 1, 24: 8,
25: 1, 26: 2, 27: 1, 28: 4, 29: 1, 30: 2, 31: 1, 32: 32, 33: 1, 34: 2, 35: 1,
36: 4, 37: 1, 38: 2, 39: 1, 40: 8, 41: 1, 42: 2, 43: 1, 44: 4, 45: 1, 46: 2,
47: 1, 48: 16, 49: 1, 50: 2, 51: 1, 52: 4, 53: 1, 54: 2, 55: 1, 56: 8, 57: 1,
58: 2, 59: 1, 60: 4, 61: 1, 62: 2, 63: 1, 64: 64, 65: 1, 66: 2, 67: 1, 68: 4,
69: 1, 70: 2, 71: 1, 72: 8, 73: 1, 74: 2, 75: 1, 76: 4, 77: 1, 78: 2, 79: 1,
80: 16, 81: 1, 82: 2, 83: 1, 84: 4, 85: 1, 86: 2, 87: 1, 88: 8, 89: 1, 90: 2,
91: 1, 92: 4, 93: 1, 94: 2, 95: 1, 96: 32, 97: 1, 98: 2, 99: 1, 100: 4, 101: 1,
102: 2, 103: 1, 104: 8, 105: 1, 106: 2, 107: 1, 108: 4, 109: 1, 110: 2, 111: 1,
112: 16, 113: 1, 114: 2, 115: 1, 116: 4, 117: 1, 118: 2, 119: 1, 120: 8, 121: 1,
122: 2, 123: 1, 124: 4, 125: 1, 126: 2, 127: 1, 128: 128, 129: 1, 130: 2,
131: 1, 132: 4, 133: 1, 134: 2, 135: 1, 136: 8, 137: 1, 138: 2, 139: 1, 140: 4,
141: 1, 142: 2, 143: 1, 144: 16, 145: 1, 146: 2, 147: 1, 148: 4, 149: 1, 150: 2,
151: 1, 152: 8, 153: 1, 154: 2, 155: 1, 156: 4, 157: 1, 158: 2, 159: 1, 160: 32,
161: 1, 162: 2, 163: 1, 164: 4, 165: 1, 166: 2, 167: 1, 168: 8, 169: 1, 170: 2,
171: 1, 172: 4, 173: 1, 174: 2, 175: 1, 176: 16, 177: 1, 178: 2, 179: 1, 180: 4,
181: 1, 182: 2, 183: 1, 184: 8, 185: 1, 186: 2, 187: 1, 188: 4, 189: 1, 190: 2,
191: 1, 192: 64, 193: 1, 194: 2, 195: 1, 196: 4, 197: 1, 198: 2, 199: 1, 200: 8}

@elliottslaughter I modified Legion to automatically assign alignments using the function above to fields. Once I did that, then this test started failing deterministically:
https://gitlab.com/StanfordLegion/legion/-/blob/master/language/tests/regent/layout/layout_test5.rg
with the error stride does not match expected value. I don't know how Regent is computing an "expected" stride for the AOS layouts in that test, but it's definitely not using the algorithm above.

Another note, I also made the maximum alignment 128 bytes which can be a requirement for some GPU operations.

Is there a branch to test?

No I committed directly to master because it was such a simple change (just a single line of code). If you want I can back it out and put it in a branch.

Since it seems to be taking a while to fix, I backed the change out of master and put it in a branch:
https://gitlab.com/StanfordLegion/legion/-/merge_requests/676

Assigning @elliottslaughter to fix the remaining Regent failing test case.

I pushed a fix for Regent to https://gitlab.com/StanfordLegion/legion/-/merge_requests/676
However, there is a new failure mode (note this is non-deterministic so you have to run it in a loop):
$ i=0; while ./regent.py tests/regent/layout/layout_test5.rg; do let i++; echo $i; done
[0 - 7ff84bf79100]    0.000155 {4}{threads}: reservation ('utility proc 1d00000000000000') cannot be satisfied
[0 - 700009add000]    0.107508 {5}{runtime}: [error 67] LEGION ERROR: Invalid mapper output. Mapper Default Mapper on Processor 1d00000000000001 selected variant 1 for task foo (ID 3). But instance selected for region requirement 1 fails to satisfy the corresponding Field layout constraint. (from file /Users/elliott/Programming/Legion/legion/runtime/legion/legion_tasks.cc:1747)
For more information see:
http://legion.stanford.edu/messages/error_code.html#error_code_67

I think this is a default mapper bug not properly taking into account task layout constraints, or something to that effect.
At this point I believe that Regent is working correctly.

@elliottslaughter I cannot reproduce this failure mode. On c0004, I did 5K runs after using Regent to build a binary of that test and did not see a single failure (even when running with multiple utility processors, tried many different counts). I also can't get it to fail when running the slow way and asking Regent to compile the test every time (up to 500 of those iterations and counting). How did you build Regent to create that error? Which machine did you do it on?

This is on my MacBook Pro x86 laptop. I just did a fresh build with:
./install.py --debug

And ran with the command line from https://github.com/StanfordLegion/legion/issues/1384#issuecomment-2087701538
I hit the error after 15 runs this time, so it's a low-probability error, but it does reproduce.
I haven't tried to reproduce this anywhere else so I can't speak to whether it is platform specific or not.
Let me know how you want to proceed.

Ok, I've done 2K runs now on c0004 with recompiling every time and 10K runs with a prebuilt binary and still no failure so you're going to need to debug this manually. What is the backtrace for the crash?

Here's the backtrace.
(lldb) bt
* thread #4, stop reason = signal SIGABRT
  * frame #0: 0x00007ff80c2fe14a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007ff80c336ebd libsystem_pthread.dylib`pthread_kill + 262
    frame #2: 0x00007ff80c25ca39 libsystem_c.dylib`abort + 126
    frame #3: 0x0000000112c8dd8f libregent.dylib`Legion::Internal::Runtime::report_error_message(id=67, file_name="/Users/elliott/Programming/Legion/legion/runtime/legion/legion_tasks.cc", line=1747, message="Invalid mapper output. Mapper Default Mapper on Processor 1d00000000000001 selected variant 1 for task foo (ID 3). But instance selected for region requirement 1 fails to satisfy the corresponding Field layout constraint.") at runtime.cc:32133:7
    frame #4: 0x00000001124ee66a libregent.dylib`Legion::Internal::TaskOp::validate_variant_selection(this=0x00007f7983834600, local_mapper=0x00007f79749100d0, impl=0x00007f797490eb40, kind=LOC_PROC, physical_instances=size=0, mapper_call_name="map_task") const at legion_tasks.cc:1740:11
    frame #5: 0x00000001124f8d69 libregent.dylib`Legion::Internal::SingleTask::finalize_map_task_output(this=0x00007f7983834600, input=0x000070000a0b77a8, output=0x000070000a0b76b8, must_epoch_owner=0x0000000000000000) at legion_tasks.cc:3290:9
    frame #6: 0x00000001124fc200 libregent.dylib`Legion::Internal::SingleTask::invoke_mapper(this=0x00007f7983834600, must_epoch_owner=0x0000000000000000) at legion_tasks.cc:3691:7
    frame #7: 0x00000001124ffd65 libregent.dylib`Legion::Internal::SingleTask::map_all_regions(this=0x00007f7983834600, must_epoch_op=0x0000000000000000, defer_args=0x0000000000000000) at legion_tasks.cc:4167:11
    frame #8: 0x000000011250ddbc libregent.dylib`Legion::Internal::IndividualTask::perform_mapping(this=0x00007f7983834600, must_epoch_owner=0x0000000000000000, args=0x0000000000000000) at legion_tasks.cc:6298:32
    frame #9: 0x00000001124f43cb libregent.dylib`Legion::Internal::SingleTask::trigger_mapping(this=0x00007f7983834600) at legion_tasks.cc:2590:44
    frame #10: 0x0000000112d42012 libregent.dylib`Legion::Internal::Runtime::legion_runtime_task(args=0x00007f798370b3c8, arglen=12, userdata=0x00006000003400e0, userlen=8, p=(id =<PHONE_NUMBER>099910144)) at runtime.cc:32309:31
    frame #11: 0x0000000113c1fc98 libregent.dylib`Realm::LocalTaskProcessor::execute_task(this=0x00007f797490db50, func_id=4, task_args=0x000070000a0b88e0) at proc_impl.cc:1176:5
    frame #12: 0x000000011399a888 libregent.dylib`Realm::Task::execute_on_processor(this=0x00007f798370b290, p=(id =<PHONE_NUMBER>099910144)) at tasks.cc:326:40
    frame #13: 0x00000001139a16fc libregent.dylib`Realm::KernelThreadTaskScheduler::execute_task(this=0x00007f797490de60, task=0x00007f798370b290) at tasks.cc:1421:11
    frame #14: 0x000000011399fdb5 libregent.dylib`Realm::ThreadedTaskScheduler::scheduler_loop(this=0x00007f797490de60) at tasks.cc:1160:6
    frame #15: 0x00000001139a078a libregent.dylib`Realm::ThreadedTaskScheduler::scheduler_loop_wlock(this=0x00007f797490de60) at tasks.cc:1272:5
    frame #16: 0x00000001139b6cdc libregent.dylib`void Realm::Thread::thread_entry_wrapper<Realm::ThreadedTaskScheduler, &Realm::ThreadedTaskScheduler::scheduler_loop_wlock()>(obj=0x00007f797490de60) at threads.inl:97:5
    frame #17: 0x00000001139718d8 libregent.dylib`Realm::KernelThread::pthread_entry(data=0x00006000036dc160) at threads.cc:831:5
    frame #18: 0x00007ff80c33718b libsystem_pthread.dylib`_pthread_start + 99
    frame #19: 0x00007ff80c332ae3 libsystem_pthread.dylib`thread_start + 15

I'll keep the session open in lldb in case you want to see anything.

Can you print out the FieldConstraint shown in conflict_constraint in frame 4 as well as constraints.field_constraint?

(lldb) p constraints.field_constraint
(Legion::FieldConstraint) {
  field_set = size=5 {
    [0] = 101
    [1] = 102
    [2] = 103
    [3] = 104
    [4] = 106
  }
  contiguous = true
  inorder = true
}
(lldb) p *(Legion::FieldConstraint *)conflict_constraint
(Legion::FieldConstraint) {
  field_set = size=8 {
    [0] = 101
    [1] = 102
    [2] = 103
    [3] = 104
    [4] = 105
    [5] = 106
    [6] = 107
    [7] = 108
  }
  contiguous = true
  inorder = true
}

Can you print out this->get_task_name(), idx, and this->regions[idx].privilege_fields in frame 4 also?
The constraints.field_constraint looks pretty strange to me. Here is a Legion Spy picture of the event graph for this program:
event_graph_toplevel_2.pdf
It looks like Regent requested a layout constraint for one of the region requirements of the tasks that only has five of the fields, but as far as I can see all the region requirements in all of the tasks should have all eight fields, so it doesn't make sense to have a layout constraint set that only has a subset of the fields (and in this case a non-contiguous numbering of the fields).

I believe the problematic layout constraint is this one:
https://github.com/StanfordLegion/legion/blob/cd2055d3ab023c40c00dfc83456408f795a0302a/language/tests/regent/layout/layout_test5.rg#L151-L163
So yes, it is literally being requested by the user in this case. @magnatelee wrote the test case, so I don't remember the original intent, but most likely the idea was to stress the layout constraint infrastructure with some weird constraints.
As far as I can see, Regent is just translating this into the runtime interface, so there isn't really anything on the compiler side making choices here since we're just directly translating the specified user preference.

Here's what I've got from the debugger. It doesn't like idx for some reason so I just printed all the regions.
(lldb) p this->get_task_name()
(const char *) 0x0000600003a696b0 "foo"
(lldb) p idx
error: <user expression 6>:1:1: use of undeclared identifier 'idx'
idx
^
(lldb) p this->regions[idx].privilege_fields
error: <user expression 7>:1:15: use of undeclared identifier 'idx'
this->regions[idx].privilege_fields
              ^
(lldb) p this->regions
(std::vector<Legion::RegionRequirement>) size=2 {
  [0] = {
    region = {
      tree_id = 1
      index_space = (id = 1, tid = 1, type_tag = 514)
      field_space = (id = 1)
    }
    partition = {
      tree_id = 0
      index_partition = (id = 0, tid = 0, type_tag = 0)
      field_space = (id = 0)
    }
    privilege_fields = size=8 {
      [0] = 101
      [1] = 102
      [2] = 103
      [3] = 104
      [4] = 105
      [5] = 106
      [6] = 107
      [7] = 108
    }
    instance_fields = size=8 {
      [0] = 101
      [1] = 102
      [2] = 103
      [3] = 104
      [4] = 105
      [5] = 106
      [6] = 107
      [7] = 108
    }
    privilege = LEGION_READ_WRITE
    prop = LEGION_EXCLUSIVE
    parent = {
      tree_id = 1
      index_space = (id = 1, tid = 1, type_tag = 514)
      field_space = (id = 1)
    }
    redop = 0
    tag = 0
    flags = LEGION_NO_FLAG
    handle_type = LEGION_SINGULAR_PROJECTION
    projection = 0
    projection_args = 0x0000000000000000
    projection_args_size = 0
  }
  [1] = {
    region = {
      tree_id = 2
      index_space = (id = 1, tid = 1, type_tag = 514)
      field_space = (id = 2)
    }
    partition = {
      tree_id = 0
      index_partition = (id = 0, tid = 0, type_tag = 0)
      field_space = (id = 0)
    }
    privilege_fields = size=8 {
      [0] = 101
      [1] = 102
      [2] = 103
      [3] = 104
      [4] = 105
      [5] = 106
      [6] = 107
      [7] = 108
    }
    instance_fields = size=8 {
      [0] = 101
      [1] = 102
      [2] = 103
      [3] = 104
      [4] = 105
      [5] = 106
      [6] = 107
      [7] = 108
    }
    privilege = LEGION_READ_WRITE
    prop = LEGION_EXCLUSIVE
    parent = {
      tree_id = 2
      index_space = (id = 1, tid = 1, type_tag = 514)
      field_space = (id = 2)
    }
    redop = 0
    tag = 0
    flags = LEGION_NO_FLAG
    handle_type = LEGION_SINGULAR_PROJECTION
    projection = 0
    projection_args = 0x0000000000000000
    projection_args_size = 0
  }
}

This is exactly the kind of bug that should be fixed by:
https://gitlab.com/StanfordLegion/legion/-/merge_requests/1156
Can you try merging that code and seeing if it fixes the issue. @seemamirch for visibility.

(lldb) p it->first
(const unsigned int) 1

I pushed a branch here which is the merge of fixalignment with sm/mapper_custom_inst
https://gitlab.com/StanfordLegion/legion/-/commits/fixalignment-sm/mapper_custom_inst
With this combined branch I still hit the failure after about 8 iterations.
Let me know if there is anything else you want me to test (and in which branch).

@seemamirch gave me the following patch on top of my combined branch:
diff --git a/runtime/mappers/default_mapper.cc b/runtime/mappers/default_mapper.cc
index dd5203993..b0bdeaa03 100644
--- a/runtime/mappers/default_mapper.cc
+++ b/runtime/mappers/default_mapper.cc
@@ -2533,15 +2533,15 @@ namespace Legion {
                                     std::vector<FieldID> &fields)
     //--------------------------------------------------------------------------
     {
-      if (total_nodes == 1)
-      {
-        FieldSpace handle = req.region.get_field_space();
-        runtime->get_field_space_fields(ctx, handle, fields);
-      }
-      else
-      {
+      // if (total_nodes == 1)
+      // {
+      //   FieldSpace handle = req.region.get_field_space();
+      //   runtime->get_field_space_fields(ctx, handle, fields);
+      // }
+      // else
+      // {
         fields.insert(fields.end(), needed_fields.begin(), needed_fields.end());
-      }
+      // }
     }

With this patch, I am unable to repro on my Mac after 500 iterations.

@seemamirch committed the fix into https://gitlab.com/StanfordLegion/legion/-/merge_requests/1156, so that is now a prerequisite for https://gitlab.com/StanfordLegion/legion/-/merge_requests/676.

I remade the merged branch. CI has passed (https://gitlab.com/StanfordLegion/legion/-/pipelines/1291185447) and I locally ran 1,000 iterations without any issue.

Do we actually want that patch though? It's effectively fixing the same problem as what occurs in #1666 and we decided we didn't want to get rid of that code because it could cause performance issues for a lot of existing applications that rely on this particular functionality of the default mapper.

I find it hard to believe that we've used that optimization only when total_nodes == 1, which if you read the code above is clearly what the old version was doing.
If you grep the new mapper code there is a call to get_field_space_fields here: https://gitlab.com/StanfordLegion/legion/-/blob/sm/mapper_custom_inst/runtime/mappers/default_mapper.cc?ref_type=heads#L2416
Which gets invoked along with a comment that we are making instances with all fields: https://gitlab.com/StanfordLegion/legion/-/blob/sm/mapper_custom_inst/runtime/mappers/default_mapper.cc?ref_type=heads#L2370

The event graph with the new version
http://sapling.stanford.edu/~seemah/layout5_new/event_graph_toplevel_2.pdf

Ok, so we're still getting all the fields as long as there are no fields in the existing layout constraints, but if there are specific fields in the layout constraints, then we don't bother adding the additional fields? Did I interpret that correctly?

It will only add 'needed_fields' in the new branch. In master it may have added all the fields in the field space but only if total_nodes=1.
I'll now add all the fields in the field space only if there are no fields in the existing layout constraints (regardless of total_nodes)

Ok, that seems like a reasonable implementation.

What's our disposition on this issue? Is Seema's change ready to go, and if so can it be merged?

It's not obvious to me that we're doing the right thing for performance, but if you guys are both satisfied then let's go ahead and merge it. The default mapper is always something that can be easily modified later and we generally discourage users from using it for performance testing, so as long as it's correct that is good enough for me.

https://gitlab.com/StanfordLegion/legion/-/merge_requests/676 has been merged. I think this is resolved now, but if anyone has any new or different issues, you can reopen or open a new comment.


Provide RAII wrapper for managing workspace memory

The code uses WORKSPACE_ALLOC() (and related) to allocate memory, relying on calling WORKSPACE_FREE() to deallocate that memory. This is error-prone, especially while handling errors. It would be preferable to provide an RAII wrapper (e.g. std::unique_ptr) to manage that memory automatically.

+1, especially if it can be done in a way that it would allow pmr-style memory allocation strategy choices to be made.

The upcoming numpy 1.22 release will include support for custom, pluggable memory allocators. That means the array-pooling being done with WORKSPACE_ALLOC() and WORKSPACE_FREE() could be refactored into a numpy-1.22-compatible allocator API; then that allocator can be installed/uninstalled by the riptide_cpp.SetRecycleMode function. At that point, you can rip out all of the WORKSPACE_ALLOC() and WORKSPACE_FREE() calls and just use the regular numpy C APIs for it, because you'd still be effectively using them (just through the installed numpy allocator). Then, your RAII wrapper can just wrap the regular numpy APIs too, which'll help to keep it relatively simple and fast.


Step 8 Converse and Refine

On Step 8 Converse & Refine - Completing the conversation naturally
the index.js file on Step 6 already has the solution code in it
There is no // TODO codelab-2

https://github.com/firebase/assistant-codelab/commit/21adfebd8bcae596db20a189ed03510e99e32e60


Events box on homepage

@ChenProm-USDA
I am requesting your help with something small (or at least I hope it is small).  I am working on the branch named add-meetings-09-11-24 and I am trying to get the date after the hyperlink to be on the next line.
Currently the date and link on the same line. see screen shot

What I would prefer and I think easier to read is having the date right under (or the next line) after the link. see screen shot:

Layout is controlled by _theme/jekyll-theme-legumeinfo/_includes/card-items.html.
To fix:
Make a copy of this component in the root _includes folder and update with code below.

{{ include.title }}
    {% if include.meta %} {{ include.meta }}{% endif %}

@jd-campbell  I pushed some changes to the branch please pull down and review.


[BI-1164] Refresh materialized view after trial and OU save

To test:

Create a BreedBase program (through local Breeding Insight Platform is probably easiest)
In the multiple trial upload, upload this file:
BI-1164-studies.xls
Check BrAPI observation units endpoint for data (http://localhost:7080/brapi/v2/observationunits)
If the data isn't there, give it a couple of minutes before requesting changes on this PR, the materialized view might be refreshing still. I didn't make it wait for the refresh to finish to lower chances of something breaking on the front end.

Do we need to do something similar when writing trial data through the brapi endpoints or is that already good?

@nickpalladino The brapi studies endpoints already have the refresh.


Markdown column type: Provide a link to markdown syntax or other online markdown editor

We decided that instead of extending the comments to contain markdown, a tooltip to the markdown syntax or online editor can be shown by record-edit.

Issue moved to informatics-isi-edu/chaise #664 via ZenHub


Move to pillarjs org?

/cc @tj @jonathanong

ask @tj to move it but yes, i agree

I cc'd him here, just in case :) Apparently I cannot connect AppVeyor to this repo since I don't have enough privileges.

...why appveyor?

Mainly, because this module does a lot of file system path manipulation. At least, I work on Windows, so I catch issues that slip by where a change works on Linux but fails on Windows. I'd like to just have the tests include Windows, so PRs can have the same insight.

does it completely replace travis or whatever or does it augment it?

You can think of it as "Travis CI for Windows"; since it doesn't so Linux, it's a supplement :)


Click select for Start symbol

According to Markus, Prof. Prähofer briefly mentioned a feature request that allows for selecting the start symbol by R-Clicking on an NTS. The idea from Prof. Prähofer apparently was to open a new tab. Markus also adjusted that request to use CTRL+L-Click instead, and to perform the action in the same tab.
However, this was just briefly mentioned during a walk at the campus. I'll talk to him to solidify the request

Added in #81


Unable to send long message which  is greater than 255 chars  using cloudhopper

Hi All,
When we are trying to push a longer message which is more than 255 characters length, i am getting the below error message from cloud hopper. But in our case, the SMSC element is handling the split of longer messages. We are  requested not to split at our end.
com.cloudhopper.smpp.type.SmppInvalidArgumentException: A short message in a PDU can only be a max of 255 bytes [actual=535]; use optional parameter message_payload as an alternative
How can we make the cloud hopper API by pass this validation and push the message directly to SMSC element so that SMSC takes care of split logic.
Thanks

can any one share, how to set the optional parameters (TLV) to use message_Payload to send the message more than 255 characters.
and one more is if use use message_payload do we need to set the sm_length as 0.??
if yes how can we set it to 0 because in submit_sm it is set to private like this.
// setSmLength() is private as it's set to length of the message
private void setSmLength(short value) {
smLength = value;
}

if (textBytes != null && textBytes.length > 255) {
submitMsg.addOptionalParameter(new Tlv(SmppConstants.TAG_MESSAGE_PAYLOAD, textBytes, "message_payload"));
}else{
submitMsg.setShortMessage(textBytes);
}


Added no-ip tag for GCP instances

Codecov Report

Merging #56 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #56   +/-   ##
=======================================
  Coverage   25.54%   25.54%
=======================================
  Files          14       14
  Lines         274      274
=======================================
  Hits           70       70
  Misses        204      204

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 5ae2a03...d931436. Read the comment docs.


Disable printing of #ifs from the AST

The option to print #ifs defaulted to "on", but was disabled in most of the actual compiler inputs that mattered, and the results weren't ever actually used. Remove the option so we never print #ifs.

@swift-ci please smoke test


Go to Definition sometimes opens a temporary window for the same file

Here's a screen grab:

The definition is in the same file, but F12 still opens a new window to show it instead of just moving the cursor.
Repro steps

Put the cursor on a call to a function defined in the same file

Press F12

Expected behavior
The cursor moves within the window to the definition.
Actual behavior
A temporary window is opened with the same file contents and the cursor at the definition.
Known workarounds
None, but I've seen the correct behavior happen. Right now I have 2 solutions open, one with the correct behavior one with the wrong behavior; I haven't been able to figure out in what conditions either case happens.
Related information
VS 2017, VFT Nightly <IP_ADDRESS>51601 (but also happens with the pre-installed VFT)

@Tarmil We will need a reliable step-by-step repro for this, I haven't been able to repro it
Please reopen if you get an exact repro


[BUG][AWS Lambda] Timeout limits are not correctly set

When deploying a function in AWS lambda timeouts are not correctly read from .lithops_config file, this behavior results in a wrongfully generated Lambda function with a wrong timeout.
I believe this issue starts from a typo in cli.py, where runtime_timeout is defined as runtime_memory instead of runtime_timeout.
runtime_timeout = runtime_info['runtime_memory']

should be
runtime_timeout = runtime_info['runtime_timeout']

@felipecaon Thanks for reporting that issue.
However, this is only called if you run lithops runtime update command. are you using this command? or did you experience this issue without this command? Can you provide more context information? lithops version, python version?

Hey @JosepSampe
Sorry for the lack of information, I wrote that issue in a hurry.
I was having a hard time setting up a lambda function with a proper runtime timeout. It turns out I was forgetting to add runtime_timeout into my lithops config file, my mistake and no bug whatsoever.
While trying to file the issue that caused my problem to arise, I found this unrelated bug.