Worker Based Task Review

To include worker based task review the following might be needed:
Projects should have a boolean property about if they are reviewable or not.
If they are reviewable, we should store the task prompt and the work the worker contributes.
With some controllable periodicity, a recent task completed by a worker will be randomly selected and turned into a review task. Review tasks are added to the task feed of some specific group of different workers and show the task prompt as well as what the original worker contributed. The reviewing worker will be able to review these and then will have to enter 3 points of data:

a rating between 1 and 4 stars
a boolean about perceived acceptability of the evaluated work
an optional textual comment with no special formatting

This data is then connected to the original workers task history so they may view it at a later point and so that calculations for other purposes can be conducted on it.
This review process is double blind, so neither the reviewer nor the reviewed know each other's identity.

@markwhiting: could you also add interface for Task Review?  We will need to define the system components based on three states: before the review, during the review, and post review.
For instance consider following cases:

Before the review:  Can a worker (reviewer) see the task status (returned/accepted) by a requester?Whether the review is voluntary or paid? If it is paid what the right amount? If it is voluntary whats the benefit, we will need to convey that via the interface (The interface should clearly communicate the incentives)
During the review: The interface should communicate to the worker that his review is in progress (This information should reflect on either the worker's dashboard or on a separate review section).
Post review: On the workers dashboard, we will need to communicate final results about his performance. We need to add right metaphors to communicate this information (e.g., returned over rejected)  On other hand, the worker's (reviewers) dashboard will need to highlight the review statistics (e.g., how many reviews were completed, percentage of acceptance/rejections, ratings provided, etc.). This data should be open to the guild community.

Above are the examples to getting started with how the system will look like during each state of the review process. There is more to this -- over to slack

Post review is something that has been touched upon before. This is at
minimum a table with task name, status changes that differ for the
following user groups (requester, level 1 worker, > level 1 worker who is a
reviewer), and anonymous feedback.
Prior to this, there is an additional review of the review tasks that seeks
to eliminate poor reviews. This can be partial automation that creates
elimination through the introduction of character minimums greater than 10.
This eliminates "good", "none" type responses. This should be done after
review submission though.
On Tuesday, April 26, 2016, neilthemathguy<EMAIL_ADDRESS>wrote:

@markwhiting https://github.com/markwhiting: could you also add
interface for Task Review? We will need to define the system components
based on three states: before the review, during the review, and post
review.
For instance consider following cases:

Before the review: Can a worker (reviewer) see the task status
(returned/accepted) by a requester?Whether the review is voluntary or paid?
If it is paid what the right amount? If it is voluntary whats the benefit,
we will need to convey that via the interface (The interface should
clearly communicate the incentives)
During the review: The interface should communicate to the worker that
his review is in progress (This information should reflect on either the
worker's dashboard or on a separate review section).
Post review: On the workers dashboard, we will need to communicate
final results about his performance. We need to add right metaphors to
communicate this information (e.g., returned over rejected) On other hand,
the worker's (reviewers) dashboard will need to highlight the review
statistics (e.g., how many reviews were completed, percentage of
acceptance/rejections, ratings provided, etc.). This data should be open to
the guild community.

Above are the examples to getting started with how the system will look
like during each state of the review process. There is more to this -- over
to slack
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/crowdresearch/crowdsource-platform/issues/676#issuecomment-214585728

http://2dfyag.axshare.com/task_review.html  a lot of work has been done by @alipta

Before the review:
Can a worker (reviewer) see the task status (returned/accepted) by a requester? No
Whether the review is voluntary or paid? Paid
If it is paid what the right amount? The hourly average pay for the reviewer's level

During the review:
The interface should communicate to the worker that his review is in progress (This information should reflect on either the worker's dashboard or on a separate review section). We down't show this. Reviews happen quickly, so progress is not so relevant, and randomly, so it is better if we give the worker as little prior knowledge of what is being reviewed as possible.

Post review:
On the workers dashboard, we will need to communicate final results about his performance. **Yes, we have mockups for this. Basically:

star review will be shown on the completed task list for task that have been reviewed.

on click the review data, including rating and the optional comment will be shown

the last 10 reviews will be used for leveling with a moving average. I think it will be easier if I write a separate issue for leveling.
**

We need to add right metaphors to communicate this information (e.g., returned over rejected) On other hand, the worker's (reviewers) dashboard will need to highlight the review statistics (e.g., how many reviews were completed, percentage of acceptance/rejections, ratings provided, etc.). This data should be open to the guild community.
Yes. We can talk more about this with designs etc.

For context, the experimental context for task review is something like the following:

Do workers choose to do review tasks when they are paid commensurate to the average hourly wage of the worker?

Do the simplified reviews they do correlate well with actual quality as measured by rubrics for several task types? (we have preliminary data on this from pilot 1)
2.1. Are there types of tasks that work better or worse for review?
2.2. How does worker level correlate with review accuracy?

Needed constraint in Feedback/Comment Box: Minimum character limit >10 if and after the box is ever made active by typing. AngularJS can do this.

@neilthemathguy and @markwhiting
Can we include some social aspect to the reviwing system, like giving badgets to reviewers plus paying them for sure.
The idea behind this is that our envision is building a sustainable system, open governance is a bout partcipation and engagement as well. The incentive structure should follow this vision.

@MHSSuliman Answered on Slack.

Here is the explanation of how review of a task submission works, below is the task feed view of an L4 worker

In the task feed the top one is the review task (highlighted in purple band), The reviewer clicks on details and lands to this page

The reviewer then rates the task by clicking on the stars

The the reviewer click submit and then get a success message

I assume in order to reuse template some changes were suggested by the #research-engineering The following mock up is recommended for Task Review
Wireframe

Visual Mock up

Please let the design team know if the above designs are good to go. The rating components are horizontally oriented to avoid vertical scroll bar and keep the maximum content above the fold.

I've made a few minor updates in this issue, particularly around boomerang and treatment of the guild as a requester.

The Slack Channels were given more than 24 hours to respond to this. Please let know how this can be improved if you run into any problems.

![guild co-creation space 1]
(https://cloud.githubusercontent.com/assets/6076358/14938861/99ad4996-0f32-11e6-86de-78a4a5ddb973.jpg)

closing guilds issues


runZoned does not pass zoneValues to async* functions

Consider:
Stream<void> example() async* {
  print('${Zone.current['foo']} ${Zone.current['bar']});
}

final stream = runZoned(example, zoneValues: {'foo': 42});

runZoned(() => stream.listen((_) {}), zoneValues: {'bar': 21});

My expectation is that this would print 42 21
But it actually prints null 21

That's correct behavior.
The two runZoned calls are not nested, they are both run in the root zone, so there is no zone where both foo and bar is set. So, you're going to get either 42 null or null 21 depending on which zone the print runs in.
The stream variable is bound to a stream, and streams do not live in any particular zone.  Stream subscriptions is where the action is.
The body of the async function is run in the zone where listen is called. That's why you are seeing null 21.


Create website index file

This adds an index file to create the homepage for the website.

looks good


Set up automatic formatting/fixing in a commit hook

Right now we check for lint on PRs, but we don't automatically format on commit.  That may be nice.  A lot of people use husky for this:
https://typicode.github.io/husky/get-started.html

Fixed in #23


Menu Keyboard Focus Order

Keyboard focus on small/mobile screens follows same order of items as on desktop/larger screens. UX wise, I thought it was broken till i tabbed past the end of the menu.

The design needs to change to make it work on both viewports (or else we are adding two different forms which isn't best practices either).


Allow not updating .gitignore

I have added /.gtm/ to ~/.config/git/ignore, so I'd like to tell gtm to not update .gitignore so I don't have to clutter up every repo with it.

Good idea.  We can add an option on init for that.


fix: keep query string params from wallet callback

fixes #175
also fixes: https://github.com/near/neardevhub-widgets/issues/199

@evgenykuzyakov Yes it works now as expected and as you can see in this video here: https://youtu.be/yxrGCC5vyxQ


try to make github actions CI script work

currently we are only running github actions on push, but that does not include outside forks.


[screencastomatic] Add support for protected videos

IMPORTANT: PRs without the template will be CLOSED
Description of your pull request and other information

Adds support for password-protected videos to the ScreencastOMatic extractor.

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[x] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Fix or improvement to an extractor (Make sure to add/update tests)

In future, pls avoid force-pushing in the middle of review


Fix externals in rollup config

Reviewer: Please check the generated bundles. Now all the listed peer deps and deps should show up as require/import statements

Looks sane, cant wait to see the results


[WIP]feat: add DN

Signed-off-by: wanglei4687<EMAIL_ADDRESS>What type of PR is this?

[ ] API-change
[ ] BUG
[ ] Improvement
[ ] Documentation
[x] Feature
[ ] Test and CI
[ ] Code Refactoring

Which issue(s) this PR fixes:
Fixes #137
What this PR does / why we need it:
Not Available
Special notes for your reviewer:
Check List

[ ] DN api/types
[ ] DN Controller
[ ] docs
[ ] unittest

Additional documentation (e.g. design docs, usage docs, etc.):
Not Available

@mergify update

@mergify update

@mergify squash


'rev_sig' has changed after UAA client is updated with the same set or parameters

Hi, i noticed that after update of already existing UAA client with the same set of parameters and, same secret as before, the client starts to generate JWT tokes with different 'rev_sig' value. I was wandering is this correct?
Regards.

Thanks @fhanik, This pretty much answer my question.
Regards.


new field: google address autocomplete

Github: https://github.com/gocanto/google-autocomplete
Demo: https://gocanto.github.io/google-autocomplete/

This lib is not available as a simple js file. It seem like it will need to be added to the devDependency, no ?

This is not a big lib. ~150 lines. So I think it will be a "built-in" field.
https://gist.github.com/gocanto/0a99d0d9f3e0a15594c272887b07c8d1


Multiple headers do not align properly if default or auto widths

Allowing multiple columns to default or setting multiple columns to "auto" will still cause an undesired outcome of headers not aligning properly.
Reported via https://github.com/softlayer/sl-ember-components/pull/956

will be resolved by #1217


Tensorflow Lite Support for Raspberry PI

Describe the problem
Are you planning to support Tensorflow Lite on Raspberry Pi? Specifically Raspberry Pi 3.

Yes, this is something we plan to do.

It has been 14 days with no activity and this issue has an assignee.Please update the label and/or status accordingly.

How's everything going?

@sarahs1 is there an eta? for this?

Hi, is there an ETA for this? And more: will it likely work... or are the drawbacks of low memory so bad, that it would make no fun?

Nagging Assignee: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

any updates?

via https://news.ycombinator.com/item?id=16302881 in the comments i found a solution in https://pastebin.com/LDEGyG46, but i havent tried it yet.
Anyone got some benchmark-fps from a mobilenet for a PI3?

looks like something was merged up yesterday: https://github.com/tensorflow/tensorflow/pull/16431

This is now merged, so closing.


Store Price in cents?

Hey there, I saw this package and was wondering if it's possible to store prices/amounts in cents instead of decimal?

+1 for storing in cents!


Make generate-book.sh work on macOS.

The macOS ln command does not support the -r or -t flags.  This changes it so that it should work on all platforms.

Closing per #3215.


start on complex numbers support

address issue https://github.com/scikit-hep/awkward-1.0/issues/392
However, I'm not sure what the status of @sjperkins work is: https://github.com/scikit-hep/awkward-1.0/pull/421
@jpivarski - I'll be happy to close this PR if it's a duplicate.
The main reason why I'm submitting it as a draft is to ask a question about complex numbers representation in JSON. It has been suggested here to use {"real: #, "imag": #}. Is that what we want?
def test_complex_numbers():
    array = ak.layout.NumpyArray(np.array([(1.+2.j), (3.+4.j)],dtype=np.complex_))
    assert ak.to_list(array) == [(1.+2.j), (3.+4.j)]
    assert (
        ak.to_json(array)
        == '[{"real":1.0,"imag":2.0},{"real":3.0,"imag":4.0}]'
    )

I've already talked with @sjperkins (in GitHub or email? I can't remember), and he's not actively working on this: you won't collide. However, it's good to ping him here to be sure that the work isn't being duplicated.

I've already talked with @sjperkins (in GitHub or email? I can't remember), and he's not actively working on this: you won't collide. However, it's good to ping him here to be sure that the work isn't being duplicated.

@jpivarski @ianna Yep, I'm not working on it at present. Note that the snippet in https://github.com/scikit-hep/awkward-1.0/issues/392#issuecomment-752348789 may be useful for stamping out C/C++ templates.

@jpivarski @ianna Yep, I'm not working on it at present. Note that the snippet in https://github.com/scikit-hep/awkward-1.0/issues/392#issuecomment-752348789 may be useful for stamping out C/C++ templates.

Note to myself: it seems to me, the minimum amount that is necessary and sufficient to recreate a complex object is the real and imaginary part, plus the metadata:
{
    "__complex__": true,
    "real": 42,
    "imag": 36
}

Here is an example in Python:
>>> import json
>>> z = 3 + 8j
>>> type(z)
<class 'complex'>
>>> json.dumps(z)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/yana/anaconda3/lib/python3.8/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
  File "/Users/yana/anaconda3/lib/python3.8/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/Users/yana/anaconda3/lib/python3.8/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/Users/yana/anaconda3/lib/python3.8/json/encoder.py", line 179, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type complex is not JSON serializable

>>> def encode_complex(z):
...     if isinstance(z, complex):
...         return (z.real, z.imag)
...     else:
...         type_name = z.__class__.__name__
...         raise TypeError(f"Object of type '{type_name}' is not JSON serializable")
...
>>> json.dumps(9 + 5j, default=encode_complex)
'[9.0, 5.0]'
>>> json.dumps(z, default=encode_complex)
'[3.0, 8.0]'
>>> s = """
... {
...     "__complex__": true,
...     "real": 42,
...     "imag": 36
... }
... """
>>> def decode_complex(dct):
...     if "__complex__" in dct:
...         return complex(dct["real"], dct["imag"])
...     return dct
...
>>> x = json.loads(s, object_hook=decode_complex)
>>> type(x)
<class 'complex'>
>>> x
(42+36j)
>>>

Note to myself: it seems to me, the minimum amount that is necessary and sufficient to recreate a complex object is the real and imaginary part, plus the metadata:
{
    "__complex__": true,
    "real": 42,
    "imag": 36
}

Here is an example in Python:
>>> import json
>>> z = 3 + 8j
>>> type(z)
<class 'complex'>
>>> json.dumps(z)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/yana/anaconda3/lib/python3.8/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
  File "/Users/yana/anaconda3/lib/python3.8/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/Users/yana/anaconda3/lib/python3.8/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/Users/yana/anaconda3/lib/python3.8/json/encoder.py", line 179, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type complex is not JSON serializable

>>> def encode_complex(z):
...     if isinstance(z, complex):
...         return (z.real, z.imag)
...     else:
...         type_name = z.__class__.__name__
...         raise TypeError(f"Object of type '{type_name}' is not JSON serializable")
...
>>> json.dumps(9 + 5j, default=encode_complex)
'[9.0, 5.0]'
>>> json.dumps(z, default=encode_complex)
'[3.0, 8.0]'
>>> s = """
... {
...     "__complex__": true,
...     "real": 42,
...     "imag": 36
... }
... """
>>> def decode_complex(dct):
...     if "__complex__" in dct:
...         return complex(dct["real"], dct["imag"])
...     return dct
...
>>> x = json.loads(s, object_hook=decode_complex)
>>> type(x)
<class 'complex'>
>>> x
(42+36j)
>>>

Note to myself: it seems to me, the minimum amount that is necessary and sufficient to recreate a complex object is the real and imaginary part, plus the metadata:
{
    "__complex__": true,
    "real": 42,
    "imag": 36
}

The reason I think complex numbers will be more straightforward than datatimes is that no new metadata will be needed for them. The NumpyArray class already passes data around as a std::shared_ptr<void>, util::dtype (enum), format (string), and itemsize. Arrays of complex numbers fit into this scheme just as easily as any other numbers. NumPy sets a convention that the real and imaginary parts are interleaved in the same buffer with the real part first.
>>> import numpy as np
>>> array = np.array([1, 1j, 1 + 1j], np.complex64)
>>> array
array([1.+0.j, 0.+1.j, 1.+1.j], dtype=complex64)
>>> array.view(np.uint8)
array([  0,   0, 128,  63,   0,   0,   0,   0,   0,   0,   0,   0,   0,
         0, 128,  63,   0,   0, 128,  63,   0,   0, 128,  63], dtype=uint8)
>>> array.view(np.float32)
array([1., 0., 0., 1., 1., 1.], dtype=float32)

The two dtypes that are relevant here are complex64 (two float32 numbers) and complex128 (two float64 numbers) because of the built-in float and double in C++. Any others can be indefinitely postponed (like float16 and float128, which only have stubs).
When such arrays come into Awkward Array, they go through Python's buffer interface, which assigns a format string. The string for complex64 is Zf and the string for complex128 is Zd.
>>> memoryview(np.array([1, 1j, 1 + 1j], np.complex64)).format
'Zf'
>>> memoryview(np.array([1, 1j, 1 + 1j], np.complex128)).format
'Zd'

So, just in case you thought you would need to add attributes to classes or something, the project is simpler than that. All the places where complex numbers could be relevant are already in the code (commented out, I believe). They can be searched with a multifile grep.

Note to myself: it seems to me, the minimum amount that is necessary and sufficient to recreate a complex object is the real and imaginary part, plus the metadata:
{
    "__complex__": true,
    "real": 42,
    "imag": 36
}

The reason I think complex numbers will be more straightforward than datatimes is that no new metadata will be needed for them. The NumpyArray class already passes data around as a std::shared_ptr<void>, util::dtype (enum), format (string), and itemsize. Arrays of complex numbers fit into this scheme just as easily as any other numbers. NumPy sets a convention that the real and imaginary parts are interleaved in the same buffer with the real part first.
>>> import numpy as np
>>> array = np.array([1, 1j, 1 + 1j], np.complex64)
>>> array
array([1.+0.j, 0.+1.j, 1.+1.j], dtype=complex64)
>>> array.view(np.uint8)
array([  0,   0, 128,  63,   0,   0,   0,   0,   0,   0,   0,   0,   0,
         0, 128,  63,   0,   0, 128,  63,   0,   0, 128,  63], dtype=uint8)
>>> array.view(np.float32)
array([1., 0., 0., 1., 1., 1.], dtype=float32)

The two dtypes that are relevant here are complex64 (two float32 numbers) and complex128 (two float64 numbers) because of the built-in float and double in C++. Any others can be indefinitely postponed (like float16 and float128, which only have stubs).
When such arrays come into Awkward Array, they go through Python's buffer interface, which assigns a format string. The string for complex64 is Zf and the string for complex128 is Zd.
>>> memoryview(np.array([1, 1j, 1 + 1j], np.complex64)).format
'Zf'
>>> memoryview(np.array([1, 1j, 1 + 1j], np.complex128)).format
'Zd'

So, just in case you thought you would need to add attributes to classes or something, the project is simpler than that. All the places where complex numbers could be relevant are already in the code (commented out, I believe). They can be searched with a multifile grep.

Note to myself: it seems to me, the minimum amount that is necessary and sufficient to recreate a complex object is the real and imaginary part, plus the metadata:
{
    "__complex__": true,
    "real": 42,
    "imag": 36
}

The reason I think complex numbers will be more straightforward than datatimes is that no new metadata will be needed for them. The NumpyArray class already passes data around as a std::shared_ptr<void>, util::dtype (enum), format (string), and itemsize. Arrays of complex numbers fit into this scheme just as easily as any other numbers. NumPy sets a convention that the real and imaginary parts are interleaved in the same buffer with the real part first.
>>> import numpy as np
>>> array = np.array([1, 1j, 1 + 1j], np.complex64)
>>> array
array([1.+0.j, 0.+1.j, 1.+1.j], dtype=complex64)
>>> array.view(np.uint8)
array([  0,   0, 128,  63,   0,   0,   0,   0,   0,   0,   0,   0,   0,
         0, 128,  63,   0,   0, 128,  63,   0,   0, 128,  63], dtype=uint8)
>>> array.view(np.float32)
array([1., 0., 0., 1., 1., 1.], dtype=float32)

The two dtypes that are relevant here are complex64 (two float32 numbers) and complex128 (two float64 numbers) because of the built-in float and double in C++. Any others can be indefinitely postponed (like float16 and float128, which only have stubs).
When such arrays come into Awkward Array, they go through Python's buffer interface, which assigns a format string. The string for complex64 is Zf and the string for complex128 is Zd.
>>> memoryview(np.array([1, 1j, 1 + 1j], np.complex64)).format
'Zf'
>>> memoryview(np.array([1, 1j, 1 + 1j], np.complex128)).format
'Zd'

So, just in case you thought you would need to add attributes to classes or something, the project is simpler than that. All the places where complex numbers could be relevant are already in the code (commented out, I believe). They can be searched with a multifile grep.

Thanks, @jpivarski ! I've been thinking the metadata is needed to represent complex type in to_ and from_json because the json module expects all custom types to be expressed as objects in the JSON standard.

Note to myself: it seems to me, the minimum amount that is necessary and sufficient to recreate a complex object is the real and imaginary part, plus the metadata:
{
    "__complex__": true,
    "real": 42,
    "imag": 36
}

The reason I think complex numbers will be more straightforward than datatimes is that no new metadata will be needed for them. The NumpyArray class already passes data around as a std::shared_ptr<void>, util::dtype (enum), format (string), and itemsize. Arrays of complex numbers fit into this scheme just as easily as any other numbers. NumPy sets a convention that the real and imaginary parts are interleaved in the same buffer with the real part first.
>>> import numpy as np
>>> array = np.array([1, 1j, 1 + 1j], np.complex64)
>>> array
array([1.+0.j, 0.+1.j, 1.+1.j], dtype=complex64)
>>> array.view(np.uint8)
array([  0,   0, 128,  63,   0,   0,   0,   0,   0,   0,   0,   0,   0,
         0, 128,  63,   0,   0, 128,  63,   0,   0, 128,  63], dtype=uint8)
>>> array.view(np.float32)
array([1., 0., 0., 1., 1., 1.], dtype=float32)

The two dtypes that are relevant here are complex64 (two float32 numbers) and complex128 (two float64 numbers) because of the built-in float and double in C++. Any others can be indefinitely postponed (like float16 and float128, which only have stubs).
When such arrays come into Awkward Array, they go through Python's buffer interface, which assigns a format string. The string for complex64 is Zf and the string for complex128 is Zd.
>>> memoryview(np.array([1, 1j, 1 + 1j], np.complex64)).format
'Zf'
>>> memoryview(np.array([1, 1j, 1 + 1j], np.complex128)).format
'Zd'

So, just in case you thought you would need to add attributes to classes or something, the project is simpler than that. All the places where complex numbers could be relevant are already in the code (commented out, I believe). They can be searched with a multifile grep.

Thanks, @jpivarski ! I've been thinking the metadata is needed to represent complex type in to_ and from_json because the json module expects all custom types to be expressed as objects in the JSON standard.

Thanks, @jpivarski ! I've been thinking the metadata is needed to represent complex type in to_ and from_json because the json module expects all custom types to be expressed as objects in the JSON standard.

Oh, that's right: the JSON methods would need to handle this type in a special way. Unfortunately, there's no standard way to encode complex numbers in JSON. If you were to make:
{"real": 1, "imag": 0.5}

mean 1+0.5j, then there could be cases where someone actually wanted a record with these two fields, and they would not want complex numbers. Even embedding some tag like __complex__: true in the JSON (I'm not talking about Awkward properties) wouldn't guarantee that someone doesn't actually have and want data like that. The default parsing of JSON must be vanilla.
This situation is similar to the one where we wanted to encode floating point NaN and infinity as strings. The default parsing of a string "infinity" is the string "infinity", but we let the user pass arguments to from_json that changed how this is parsed. We could do the same thing with complex numbers. Assuming that we'll always want complex numbers to go to or from a record, all that must be established is what those field names are. Unfortunately, not only is there not a standard, but everybody's solution differs: "r"/"i", "R"/"I", "re"/"im", "Re"/"Im", "RE"/"IM", "real"/"imag", "Real"/"Imag", "REAL"/"IMAG", "real"/"imaginary", etc. Here's one that hopes to become standardized that chose "re"/"im" with an extra type field.
A pretty good rule would be to take complex_fields as a 2-tuple of strings in ak.from_json and if any JSON object in the data have at least these two fields, interpret it as a complex number. By default, complex_fields would be None. By asking for "at least these two fields," we allow the records to have a tag. The same complex_fields argument should exist in ak.to_json as well.
But I would think of JSON reading/writing as one of the last things to worry about in adding complex types. The very first thing that would be needed is to pass these data from NumPy arrays into Awkward Arrays and back into NumPy arrays. Then there are reducers, which have to be handled carefully because a construct like std::complex<float> can only exist below and above the extern "C" layer. In between, it has to be a void* or maybe a float* and double*, depending. The name of the function determines that those numbers are to be reduced as complex numbers, rather than twice as many real numbers.

Thanks, @jpivarski ! I've been thinking the metadata is needed to represent complex type in to_ and from_json because the json module expects all custom types to be expressed as objects in the JSON standard.

Oh, that's right: the JSON methods would need to handle this type in a special way. Unfortunately, there's no standard way to encode complex numbers in JSON. If you were to make:
{"real": 1, "imag": 0.5}

mean 1+0.5j, then there could be cases where someone actually wanted a record with these two fields, and they would not want complex numbers. Even embedding some tag like __complex__: true in the JSON (I'm not talking about Awkward properties) wouldn't guarantee that someone doesn't actually have and want data like that. The default parsing of JSON must be vanilla.
This situation is similar to the one where we wanted to encode floating point NaN and infinity as strings. The default parsing of a string "infinity" is the string "infinity", but we let the user pass arguments to from_json that changed how this is parsed. We could do the same thing with complex numbers. Assuming that we'll always want complex numbers to go to or from a record, all that must be established is what those field names are. Unfortunately, not only is there not a standard, but everybody's solution differs: "r"/"i", "R"/"I", "re"/"im", "Re"/"Im", "RE"/"IM", "real"/"imag", "Real"/"Imag", "REAL"/"IMAG", "real"/"imaginary", etc. Here's one that hopes to become standardized that chose "re"/"im" with an extra type field.
A pretty good rule would be to take complex_fields as a 2-tuple of strings in ak.from_json and if any JSON object in the data have at least these two fields, interpret it as a complex number. By default, complex_fields would be None. By asking for "at least these two fields," we allow the records to have a tag. The same complex_fields argument should exist in ak.to_json as well.
But I would think of JSON reading/writing as one of the last things to worry about in adding complex types. The very first thing that would be needed is to pass these data from NumPy arrays into Awkward Arrays and back into NumPy arrays. Then there are reducers, which have to be handled carefully because a construct like std::complex<float> can only exist below and above the extern "C" layer. In between, it has to be a void* or maybe a float* and double*, depending. The name of the function determines that those numbers are to be reduced as complex numbers, rather than twice as many real numbers.

oh, "Kernel specializations not sorted in specification" :-(

oh, "Kernel specializations not sorted in specification" :-(

Note (affects all open PRs, of which this is the only one): #645 added a new submodule, which might require special handling in merging. Since I'm not comfortable with advanced git, I just cloned a new copy of the repo with --recursive to get everything and now I'm merging it into my PR.

Note (affects all open PRs, of which this is the only one): #645 added a new submodule, which might require special handling in merging. Since I'm not comfortable with advanced git, I just cloned a new copy of the repo with --recursive to get everything and now I'm merging it into my PR.

I think you need to include something in Builder.h for Windows to find "complex in namespace std".

I think you need to include something in Builder.h for Windows to find "complex in namespace std".

@jpivarski - here is a very simple solution :-)
    array = ak.from_json(
        '[{"r": 1.1, "i": 1.0}, {"r": 2.2, "i": 2.0}]', complex_record_fields=("r", "i")
    )
    assert (array["r"] + array["i"]*1j).tolist() == [(1.1 + 1j), (2.2 + 2j)]

The rest is done.

@jpivarski - here is a very simple solution :-)
    array = ak.from_json(
        '[{"r": 1.1, "i": 1.0}, {"r": 2.2, "i": 2.0}]', complex_record_fields=("r", "i")
    )
    assert (array["r"] + array["i"]*1j).tolist() == [(1.1 + 1j), (2.2 + 2j)]

The rest is done.

@jpivarski - got it! it looks like assert treats [(0.25+0j), (0.5+0j), (3.5+0j), (4.5+0j), (5.5+0j)] as equal to [0.25, 0.5, 3.5, 4.5, 5.5]
Here is the real ak.to_list output:
>>> import numpy as np
>>> import awkward as ak
>>> content_float64 = ak.layout.NumpyArray(
... np.array([0.25, 0.5, 3.5, 4.5, 5.5], dtype=np.float64)
... )
>>> content_float64
<NumpyArray format="d" shape="5" data="0.25 0.5 3.5 4.5 5.5" at="0x7f8ef843e820"/>
>>> content_complex64 = ak.values_astype(content_float64, "complex64", highlevel=False)
>>> content_complex64
<NumpyArray format="Zf" shape="5" data="0.25+0j 0.5+0j 3.5+0j 4.5+0j 5.5+0j" at="0x7f8f18404180"/>
>>> array_complex64 = ak.layout.UnmaskedArray(content_complex64)
>>> array_complex64
<UnmaskedArray>
    <content><NumpyArray format="Zf" shape="5" data="0.25+0j 0.5+0j 3.5+0j 4.5+0j 5.5+0j" at="0x7f8f18404180"/></content>
</UnmaskedArray>
>>> ak.to_list(content_complex64)
[(0.25+0j), (0.5+0j), (3.5+0j), (4.5+0j), (5.5+0j)]
>>>

@jpivarski - got it! it looks like assert treats [(0.25+0j), (0.5+0j), (3.5+0j), (4.5+0j), (5.5+0j)] as equal to [0.25, 0.5, 3.5, 4.5, 5.5]
Here is the real ak.to_list output:
>>> import numpy as np
>>> import awkward as ak
>>> content_float64 = ak.layout.NumpyArray(
... np.array([0.25, 0.5, 3.5, 4.5, 5.5], dtype=np.float64)
... )
>>> content_float64
<NumpyArray format="d" shape="5" data="0.25 0.5 3.5 4.5 5.5" at="0x7f8ef843e820"/>
>>> content_complex64 = ak.values_astype(content_float64, "complex64", highlevel=False)
>>> content_complex64
<NumpyArray format="Zf" shape="5" data="0.25+0j 0.5+0j 3.5+0j 4.5+0j 5.5+0j" at="0x7f8f18404180"/>
>>> array_complex64 = ak.layout.UnmaskedArray(content_complex64)
>>> array_complex64
<UnmaskedArray>
    <content><NumpyArray format="Zf" shape="5" data="0.25+0j 0.5+0j 3.5+0j 4.5+0j 5.5+0j" at="0x7f8f18404180"/></content>
</UnmaskedArray>
>>> ak.to_list(content_complex64)
[(0.25+0j), (0.5+0j), (3.5+0j), (4.5+0j), (5.5+0j)]
>>>

Remaining to-do:

[x] getting all the tests to work: I re-read the testing suite and it's correctly checking all the things I wanted it to check
[ ] https://github.com/scikit-hep/awkward-1.0/pull/652#pullrequestreview-577105992 is described as incomplete (the builtins.complex vs __builtin__.complex thing), but I don't see how the tests could pass if this were not complete. Is there anything left to do on this item?
pretty-print NumpyArrays with complex numbers There's no need to do this.

So it sounds like everything might be done. Let me know if that one item above is incomplete. If not, I'll merge this PR.

Remaining to-do:

[x] getting all the tests to work: I re-read the testing suite and it's correctly checking all the things I wanted it to check
[ ] https://github.com/scikit-hep/awkward-1.0/pull/652#pullrequestreview-577105992 is described as incomplete (the builtins.complex vs __builtin__.complex thing), but I don't see how the tests could pass if this were not complete. Is there anything left to do on this item?
pretty-print NumpyArrays with complex numbers There's no need to do this.

So it sounds like everything might be done. Let me know if that one item above is incomplete. If not, I'll merge this PR.

Yes, there is an open question if the following comparison though it works, could be done better obj.attr("__class__").attr("__name__").cast<std::string>() == "complex"
It looks from the builds that like both Python 2 and 3 are happy with it.

I kept wavering on the necessity of this one: it works without it, but if a class happens to be named "complex" while not being the built-in Python complex type, then this would pass when it shouldn't. I just did the fix and will be pushing it soon.
It looks like a significant merge will also be needed, so that might be another commit from me. Once those two commits go through and pass tests, I'll merge it.
Thanks!

Yes, there is an open question if the following comparison though it works, could be done better obj.attr("__class__").attr("__name__").cast<std::string>() == "complex"
It looks from the builds that like both Python 2 and 3 are happy with it.

I kept wavering on the necessity of this one: it works without it, but if a class happens to be named "complex" while not being the built-in Python complex type, then this would pass when it shouldn't. I just did the fix and will be pushing it soon.
It looks like a significant merge will also be needed, so that might be another commit from me. Once those two commits go through and pass tests, I'll merge it.
Thanks!

The merge to main turned out to be no big deal (something must have been bad in my local git, so I've refreshed it).
@ianna When the tests pass on this, I'll merge it, or you can do the honors!

The merge to main turned out to be no big deal (something must have been bad in my local git, so I've refreshed it).
@ianna When the tests pass on this, I'll merge it, or you can do the honors!

Both 3.8 and 2.7 worked in my local tests. Once it works in Azure, it can be merged.

Both 3.8 and 2.7 worked in my local tests. Once it works in Azure, it can be merged.

The merge to main turned out to be no big deal (something must have been bad in my local git, so I've refreshed it).
@ianna When the tests pass on this, I'll merge it, or you can do the honors!

Thanks @jpivarski ! Please, go ahead and merge it. I'll be in a meeting for an hour or so :-) Thanks!

The merge to main turned out to be no big deal (something must have been bad in my local git, so I've refreshed it).
@ianna When the tests pass on this, I'll merge it, or you can do the honors!

Thanks @jpivarski ! Please, go ahead and merge it. I'll be in a meeting for an hour or so :-) Thanks!


Fix CI failing tests

https://nltk.ci.cloudbees.com/job/nltk/lastCompletedBuild/testReport/

It looks like the corpora are not being downloaded to the CI server.

Hi @stevenbird,
Why do you think the corpora are not being downloaded ? It said
[nltk_data]  Done downloading collection all from the console output
https://nltk.ci.cloudbees.com/job/nltk/TOXENV=py26-jenkins,jdk=jdk8latestOnlineInstall/251/console

Only because a previous test result gave an error for every corpus access. However, these errors have gone now.

@copper-head – there are some errors in probability.py reported by our CI server, that might have arisen since I merged your work (see https://github.com/nltk/nltk/commit/8dcae605a91a9f18fc02b75eda0b95fde4e71820#diff-100d02c6ef23dc5d864fec05084fe72d). I haven't checked to confirm this. But since you were most recently in the code, would you mind taking a look at these errors please?

Resolved by https://github.com/nltk/nltk/commit/89a08d4e295e953aad3d4efd195cc739dc5b52bc


Getting a NoneType Error when using pass_context

I wanted to test following code from Tutorial but I get a TypeError: 'NoneType' object does not support item assignment
@click.group()
@click.option('--debug/--no-debug', default=False)
@click.pass_context
def cli(ctx, debug):
    ctx.obj['DEBUG'] = debug

@cli.command()
@click.pass_context
def sync(ctx):
    click.echo('Debug is %s' % (ctx.obj['DEBUG'] and 'on' or 'off'))

if __name__ == '__main__':
    cli(obj={})

Where is the Error? Please fix tutorial? :8ball:

The code works. I just verified it.

You're right. Sorry. Somehow I can't reproduce the error.

@mitsuhiko: Unfortunately the code really does not work. I'm getting the same error on Fedora 22 as @OnionNinja:
[para@sanitarium clicktest]$ sudo python setup.py develop
[para@sanitarium clicktest]$ python clicktest.py test
(<click.core.Context object at 0x7f85bdaa0210>, {})
False
[para@sanitarium clicktest]$ clicktest test
(<click.core.Context object at 0x7f3a6556a390>, None)
Traceback (most recent call last):
  File "/usr/bin/clicktest", line 9, in <module>
    load_entry_point('clicktest==0.0.1', 'console_scripts', 'clicktest')()
  File "/usr/lib/python2.7/site-packages/click/core.py", line 700, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/click/core.py", line 680, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python2.7/site-packages/click/core.py", line 1024, in invoke
    Command.invoke(self, ctx)
  File "/usr/lib/python2.7/site-packages/click/core.py", line 873, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python2.7/site-packages/click/core.py", line 508, in invoke
    return callback(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/click/decorators.py", line 16, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "build/bdist.linux-x86_64/egg/clicktest.py", line 16, in entry
TypeError: 'NoneType' object does not support item assignment
[para@sanitarium clicktest]$

I tried using Click4 and Click5 from Fedora RPMs. First I was blaming packaging, so I switched to pip version, but it did not help. Even switching from Python2.7 to Python3.4  didn't help. Code generating the exception can be seen here.

That's because you are using entry points and the entry point points to cli and that one is not passed the object.  Only your __main__ is.
You will have to do something like this:
def main():
    return entry(obj={})

And then point your setuptools entry point to main and not entry.

A better idea is to use make_pass_decorator however which can automatically create this object on first use.

Thanks for help.

The example code from @paramite isn't there anymore, so it's kind of hard to tell what @mitsuhiko was referencing. I'm running into this currently.

I had this problem unit testing my CLI using click's CLI runner and eventually figured out it was because I wasn't passing the dict I was trying to use to the context in the invoke method.  If this is your issue, make sure you add the necessary kwarg to invoke like so (assuming you want your context to contain a dict called obj):  runner.invoke(main, ['command'], obj={})


Questions about the training data set

The input data needed for this model training should be the original image and the Masks of the corresponding image.
But I only have the original image and the Lable for the images
How can I input the Label information into the model for training? or do i have to convert the Label to the masks?
Thank you

Hi, please read the instructions when opening a Question/Help/Support issue.


train on multi-GPU

is it possible to train with multigpu?

I want to train this network with my own dataset. could you provide some idea of how can I train with my own dataset?

Hi, lerndeep,
This code runs only on single GPU. I think it is entirely possible to run it on multigpu but currently we may not release new version to deal with it. For your own dataset, you can adapt the dataloader to your own data structure.


ConcurrentModificationException On Radar Scan

Hello!
Does the Radar Block detect item entities and projectile entities as well?
This suddenly showed up when my guns were firing (all 16 of them):

I think the radar had a hard time scanning all of the projectiles and dropped empty shell casings. The computercraft thread lagged a bit too when it happened. By "lag" I mean right-clicking on the terminal didn't take effect after a few minutes later...
maybe adding a filter mode for the radar.scan() function might help?
Found this in the logs too:
[24Nov2023 11:09:04.208] [ComputerCraft-Coroutine-3/ERROR] [computercraft/]: Error calling call on dan200.computercraft.core.apis.PeripheralAPI@3c97066a
java.util.ConcurrentModificationException: null
	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1013) ~[?:?]
	at java.util.ArrayList$Itr.next(ArrayList.java:967) ~[?:?]
	at com.google.common.collect.Iterators$1.next(Iterators.java:146) ~[guava-31.0.1-jre.jar%2330!/:?]
	at net.minecraft.world.level.entity.EntitySection.m_188352_(EntitySection.java:33) ~[client-1.18.2-20220404.173914-srg.jar%23132!/:?]
	at net.minecraft.world.level.entity.EntitySectionStorage.m_188365_(EntitySectionStorage.java:118) ~[client-1.18.2-20220404.173914-srg.jar%23132!/:?]
	at net.minecraft.world.level.entity.EntitySectionStorage.m_188362_(EntitySectionStorage.java:63) ~[client-1.18.2-20220404.173914-srg.jar%23132!/:?]
	at net.minecraft.world.level.entity.EntitySectionStorage.m_156890_(EntitySectionStorage.java:118) ~[client-1.18.2-20220404.173914-srg.jar%23132!/:?]
	at net.minecraft.world.level.entity.LevelEntityGetterAdapter.m_142232_(LevelEntityGetterAdapter.java:42) ~[client-1.18.2-20220404.173914-srg.jar%23132!/:?]
	at net.minecraft.world.level.Level.m_6249_(Level.java:601) ~[client-1.18.2-20220404.173914-srg.jar%23132!/:?]
	at net.minecraft.world.level.EntityGetter.m_45933_(EntityGetter.java:33) ~[client-1.18.2-20220404.173914-srg.jar%23132!/:?]
	at net.spaceeye.someperipherals.utils.radar.ScanInRadiusKt.scanForEntities(ScanInRadiusKt.java:33) ~[Some-Peripherals-0.0.8.jar%23119!/:?]
	at net.spaceeye.someperipherals.utils.radar.ScanInRadiusKt.scanInRadius(ScanInRadiusKt.java:74) ~[Some-Peripherals-0.0.8.jar%23119!/:?]
	at net.spaceeye.someperipherals.integrations.cc.peripherals.RadarPeripheral.scan(RadarPeripheral.java:16) ~[Some-Peripherals-0.0.8.jar%23119!/:?]
	at net.spaceeye.someperipherals.integrations.cc.peripherals.RadarPeripheral$cc$scan138.apply(CC generated method) ~[?:?]
	at dan200.computercraft.shared.peripheral.modem.wired.WiredModemPeripheral$RemotePeripheralWrapper.callMethod(WiredModemPeripheral.java:409) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at dan200.computercraft.shared.peripheral.modem.wired.WiredModemPeripheral.callRemote(WiredModemPeripheral.java:212) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at dan200.computercraft.shared.peripheral.modem.wired.WiredModemPeripheral$cc$callRemote24.apply(CC generated method) ~[?:?]
	at dan200.computercraft.core.apis.PeripheralAPI$PeripheralWrapper.call(PeripheralAPI.java:112) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at dan200.computercraft.core.apis.PeripheralAPI.call(PeripheralAPI.java:361) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at dan200.computercraft.core.apis.PeripheralAPI$cc$call102.apply(CC generated method) ~[?:?]
	at dan200.computercraft.core.lua.ResultInterpreterFunction.invoke(ResultInterpreterFunction.java:61) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at cc.tweaked.internal.cobalt.function.ResumableVarArgFunction.invoke(ResumableVarArgFunction.java:77) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at cc.tweaked.internal.cobalt.function.LuaInterpreter.execute(LuaInterpreter.java:506) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at cc.tweaked.internal.cobalt.function.LuaInterpretedFunction.resume(LuaInterpretedFunction.java:196) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at cc.tweaked.internal.cobalt.debug.DebugFrame.resume(DebugFrame.java:243) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at cc.tweaked.internal.cobalt.LuaThread.loop(LuaThread.java:570) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at cc.tweaked.internal.cobalt.LuaThread$1.run(LuaThread.java:466) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at dan200.computercraft.core.lua.CobaltLuaMachine.lambda$new$1(CobaltLuaMachine.java:80) ~[cc-tweaked-1.18.2-1.101.3.jar%2365!/:1.101.3]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:833) [?:?]

Ok i think i know why this happens, but i will need to test it. How big was the radius?

I'm not sure i can do anything about the speed though :skull:

Range was 500. It might help keep the scan table small if the scan function had a way to filter out projectiles and dropped items. Maybe even a way to filter out players and ships as well?
Tbh, I usually just need player and ship data for my stuff... AdvancedPeripheral had a separate block for scanning non player entities and that had a cooldown timer per scan...
Maybe having a separate scanning function for players, ships and entities might help minimize lag?

Hmmm... Alr I've looked at how AP looks for players, and I can implement something like that

Added timeout for entity scanning to prevent "lag", added 3 peripheral methods for separately scanning for ships, entities and players. Will be added in the next release.


[iOS] Fabric: Adjusts the weight according to the font name

Summary:
Fixes another font weight issue mentioned in https://github.com/facebook/react-native/issues/47656#issuecomment-2486282496. We can get the weight from font name if user not specify weight.
@esbenvb Is this work for you ?
Changelog:
[IOS] [FIXED] - Fabric: Adjusts the weight according to the font name
Test Plan:
Demo in https://github.com/facebook/react-native/issues/47656#issuecomment-2486282496.

We should look at how we can share this code with the old architecture and the new one. This seems like the right change for backwards compat since it's what paper does, but the duplication isn't great.

@zhongwuzw to address @javache, you can just expose the weightOfFont function from the RCTFont.mm file in the RCTFont.h header and then import the RCTFont.h into the RCTFontUtils.mm file.

@javache @cipolleschi Done! :)


The search is broken

On localhost it seems there is no problem, but after I deploy to Cloudflare Pages, the search function doesn't work. The parameters in URL changed but search results do not appear and say 0.
https://arizky.pages.dev/search
https://arizky.pages.dev/search/?q=Zero
See video: https://files.getimiskon.xyz/f/jwa2i/x22r4.mp4

looks like it can't load the json file for the search, i'll look in to this and see what needs changing

I just realized hopefully it will be fixed soon

This should be ok now


feat: Add label support for the

🙋 Feature Request
Would like the option to add a label to the  component. I can see it is a form of wrapper to the  component so would be nice if you could add a label just by adding the text inside the component.
🤔 Expected Behavior
You should be able to to someting like:
<FluentAutocomplete ...>
   Search tags
</FluentAutocomplete>

😯 Current Behavior
It's just ignoring  and there is not label attribute.
💁 Possible Solution
The  already have this feature, so are imagining that the  could used a  to pass on the label text to the 's ...
🔦 Context
My issue is the styling, I cant reuse the  styling by applying the class .label to my own label. Since its styled via the JS some how. And then I feel like it would make sense that I could use the same approach as on a normal input field.

Thank you for this request. It makes sense to have the same logic used by FluentTextField.
I'll add it in the next version.

Thank you for this request. It makes sense to have the same logic used by FluentTextField. I'll add it in the next version.

We'll add a Label attribute (of type string) to manage this information. Not only on this Autocomplete component, but also on the other "Input" components. This will enable us to correctly manage the label to be displayed, but also to make it compatible with the Accessibility rules.

We'll add a Label attribute (of type string) to manage this information. Not only on this Autocomplete component, but also on the other "Input" components. This will enable us to correctly manage the label to be displayed, but also to make it compatible with the Accessibility rules.

Will this mean that we can not add html element like icons and span to the ? If so that would be sad, that was one of my favoured features with Fluent UI compared to MudBlazor...

Good question.
I could add a Label attribute for most cases.
And a LabelTemplate property (RenderFragment) for special cases.
But then you'd have to use Title to define the aria-label content of the Accessibility.

Good question. I could add a Label attribute for most cases. And a LabelTemplate property (RenderFragment) for special cases. But then you'd have to use Title to define the aria-label content of the Accessibility.

Really like the idea of a LabelTemplate, but all cool that you would only need Label in most cases.

Fixed in #822


Make it possible to retrieve only the most recently logged event

As per title.
The getLogText(...) method is useful for debugging, but it is clunky when only the most recent event is of interest.

Fixed in #54.


Added Groovvy Music Player

Description 📜
I've Added Groovy Music Player Folder Please review it
Fixes #385

Type of change 📝
Please delete options that are not relevant.And in order to tick the check box just but x inside them for example [x] like this

[ ] Add a new project

Domain of Contribution 📊
Please delete options that are not relevant.And in order to tick the check box just but x inside them for example [x] like this

[x ] Project using only HTML & CSS
[ x] Project using HTML, CSS & JS

Checklist ✅
Please delete options that are not relevant.And in order to tick the check box just but x inside them for example [x] like this

[ x] I have performed a self-review of my own code or work.
[ x] My changes generates no new warnings.
[ x] I'm GSSoC'22 contributor

Screenshots / Gif (Optional) 📸
Add the screenshot of the changes you have made

Files are not pushed properly, please push all the files


fix: default port numbers for the datasources

Description
This PR covers arango, elasticSearch, mongo, mssql, mysql, oracle, postgres, redis, redshift, smtp datasources for setting the default port values for each. This adds a test case that tests the default port values for all
Fixes #32136
or
Fixes Issue URL

[!WARNING]
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.

Automation
/ok-to-test<EMAIL_ADDRESS>:mag: Cypress test results

[!CAUTION]
If you modify the content in this section, you are likely to disrupt the CI result for your PR.

/build-deploy-preview skip-tests=true

@AmanAgarwal041 since we have hard-coded default ports now on the backend and frontend, as an improvement we should plan(in this or another issue) to centralize this hard-coding to the backend and retrieve it to the frontend. Better for future maintainability.

@AmanAgarwal041 since we have hard-coded default ports now on the backend and frontend, as an improvement we should plan(in this or another issue) to centralize this hard-coding to the backend and retrieve it to the frontend. Better for future maintainability.

@rohan-arthur I don't think we need another file to keep the ports, already form.json for each plugins have their own configs which has the default ports, not anywhere else.

/build-deploy-preview skip-tests=true recreate=true


InputFlows form values getters RELEASE

Related Issues
Fixes <link_to_github_issue>
Related PRs

branch
PR

service a PR
Link to PR

service b PR
Link to PR

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

[ ] Tests
[ ] Documentation (if applicable)

FYI @chris4490


pg:diagnose errors

heroku pg:diagnose --app flight record results in the following.  Also, as of this morning no pg commands work in the terminal...
sh: psql: command not found
!    Heroku client internal error.
!    Search for help at: https://help.heroku.com
!    Or report a bug at: https://github.com/heroku/heroku/issues/new
Error:       psql failed. exit status 32512, output: "" (RuntimeError)
Command:     heroku pg:diagnose --app flightrecord
Plugins:     heroku-pg-extras
Version:     heroku-toolbelt/3.30.3 (x86_64-darwin10.8.0) ruby/1.9.3
Error ID:    7f1bba3bcd2643efb1d25a881bae0550

sorry.  one day I didn't need a path to postgres...the next I did.


Fixes possible KeyError in _report_compliance_information

What does this PR do?
Fixes possible KeyError in _report_compliance_information
Motivation
1724-twistlock-error
Additional Notes

added additional logging if err is found in response.

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached

We should probably avoid using reserved keyword type as a variable name, but that's for a separate PR since it happens in a few places in this file.

Thanks for that. I'll create PR for that.


Menhir support - first pass

Here's something basic that seems to work in most of the simple menhir
projects I've encountered.
Some things to note:

I'm not sure if it's a good idea to support simple menhir and --base in the
same stanza. For example omake supports a separate MenhirMulti function
and ocamlbuild has mlypack just for modular menhir

I'm pretty sure my flags handling is wrong. But there has to be something
in place to pass extra flags to menhir

All the ocamlc/ocamldep stuff is avoided for now. This PR seems to be
sufficient for most (simple) uses of menhir out there. So perhaps this can
be marked as experimental an improved eventually.

I don't whether I should add stuff to vjs, as I'm guessing you want to have
tight control over that at JST.

Flags handling looks fine. We could also use the set language if we want to pass default flags to menhir and want the user to be able to remove them.
For vjs, yeah he idea is that we might need to modify it as we work with the public release of JS packages.
Supporting both scenario in the same stanza seems fine. However, IMO (base ...) doesn't convey the intent best. What about something more explicit like (merge_into ...), (concat_as ...), ...?

Flags handling looks fine. We could also use the set language if we want to pass default flags to menhir and want the user to be able to remove them.

Makes sense. Although I don't have any suggestions here at this point, so we can hold this off.

Supporting both scenario in the same stanza seems fine. However, IMO (base ...) doesn't convey the intent best. What about something more explicit like...

Although those names are more descriptive, base has the advantage of being easily discoverable for people reading the menhir docs. The thought process would go as follows, "I know menhir has this --base flag, how do I use it with jbuilder?". Let me think about this.

I've fixed the flags type btw. So unless you're insisting on a name change,
this is ready.
On Wed, Mar 29, 2017, 12:45 AM Jérémie Dimino<EMAIL_ADDRESS>wrote:

@diml commented on this pull request.
In src/jbuild_types.ml
https://github.com/janestreet/jbuilder/pull/42#discussion_r108590875:

@@ -678,6 +678,60 @@ module Rule = struct
let ocamlyacc_vjs = ocamlyacc_v1
end

+module Menhir = struct

type t =
{ base : string option
; flags : string list
; modules: string list
}

let v1 =
record

 (field_o "base" string >>= fun base ->

  field "flags" (list string) ~default:[] >>= fun flags ->

hmm, no indeed. I might be missing something, but it seems to me that here
flags is a string list and at the beginning of v1_to_rule we convert it
to a String_with_vars.t list. We should be able to parse it immediately
as a String_with_vars.t list?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/janestreet/jbuilder/pull/42#discussion_r108590875,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIe-1OSBdYGg0YvceHUaz2L0t0sOGlBks5rqeHjgaJpZM4MrIdz
.

Ok, the code looks good. I see your point about base, but I still find it weird that adding (base ...) changes the behavior in this way. For instance, I assume that if you pass several files to menhir without a --base argument, it is an error?
If we keep the (base ...) field as it, I think we should indeed have a separate stanza (menhir_multi ...). BTW, the new stanza need to be documented

For instance, I assume that if you pass several files to menhir without
a --base argument, it is an error?

I'm not sure but note that we are never doing that. We process the files
individually without base.
I will add menhir_multi and then some docs if everything is alright
On Wed, Mar 29, 2017, 9:53 AM Jérémie Dimino<EMAIL_ADDRESS>wrote:

Ok, the code looks good. I see your point about base, but I still find it
weird that adding (base ...) changes the behavior in this way. For
instance, I assume that if you pass several files to menhir without a
--base argument, it is an error?
If we keep the (base ...) field as it, I think we should indeed have a
separate stanza (menhir_multi ...). BTW, the new stanza need to be
documented
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/janestreet/jbuilder/pull/42#issuecomment-290096931,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIe-9cpQ3sGuJ-QulDl83Iayd2Y4jBCks5rqmJxgaJpZM4MrIdz
.

I'm not sure but note that we are never doing that. We process the files
individually without base.

Indeed. What I meant is that if we try to match menhir command line arguments to the stanza, then  it seems natural to match things this way:
(menhir
  ((base foo)
   (modules (a b)))

-->
$ menhir --base foo a.mly b.mly

and:
(menhir
  ((modules (a b)))

-->
$ menhir a.mly b.mly

I think it's not natural that adding a (base ...) field changes the number of OCaml modules produced by the stanza. I think it would be OK if (base ...) was more explicit. Alternatively having a separate stanza for the multi mode with a (base ...) field seems OK as well.

I will add menhir_multi and then some docs if everything is alright

Seems good to me

merge_into_base is perhaps a compromise? Keep it to 1 stanza but use a more suggestive name?

Well, I don't think it's really important to keep it one stanza. I think it's more important to keep it clear and intuitive. How important do you think it is to keep the field names similar to the command line options? In the end this will be documented. If someone knows menhir and doesn't read the jbuilder doc, they'll probably end up writing their own rule anyway.
merge_into_base looks odd to me. Although I'm not a native English speaker. I still prefer (merge_into ...) or two separate stanzas.

@diml ok let's just call it merge_into. I don't have a strong opinion on a feature I've never used until now.
I'll add some docs.

@diml updated the docs

Thanks @diml . Fixed.

Thanks for the feature! I changed option to field in the doc, to match the description of the other stanzas


Add a feature toggle for the new search panel

Test plan
Minor config change affecting experimental feature

(will need to update the test files too)


Fix docs

Fixes documentation building by using subdirectories.
New links are:

https://tyler-keith-thompson.github.io/Afluent/Afluent/documentation/afluent/
https://tyler-keith-thompson.github.io/Afluent/AfluentTesting/documentation/afluenttesting/

Ok, I'm not exactly sure why the pages are missing again after pushing the "revert" commit. I'm re-running the release job from commit 27d28ba6f7025b92f992f82d5aa8ee2598672a0a. I'm pretty sure I'm not crazy and the published docs were available when that job was run.

sigh looks like there's still an issue. I'm not sure why they had look successfully published yesterday but now they're 404-ing today. Putting this back in draft.

Ok, I had to take a closer look at the peaceiris/actions-gh-pages source code but I understand how the directory variables should be set now. Looks good to me, taking out of draft again.


Parametrize ESO caProvider fields

This will allow users to disable using the default kube-root-ca.crt
configmap and/or customize things fully.
So, for example, an environment which uses letsencrypt for the ingress
certs, but does not have that CA included in kube-root-ca.crt, can
simply override things with a /values-IBMCloud.yaml file with:
caProvider:
enabled: false
Which will just use the CA System bundle to authenticate connections
from ESO to vault.

/lgtm as far as it goes - maybe with this merged we can put this into the MCGO with the explicit override mechanism?

/lgtm as far as it goes - maybe with this merged we can put this into the MCGO with the explicit override mechanism?

Aye, that is the plan. So we showcase the cloud overrides a bit better.


Support x509 certificates

This pull request would require the removal of support for node 0.8 due to its dependency on ursa which supports old and new node versions, but only if you install with engine-strict set to true. Unfortunately, even without this pull, node-soap will not work with node 0.8 and engine checking. strip-bom is the first library to fail to support 0.8 but is probably not alone...

@ctarrington looks like something is wrong with the commit history.  Can you take a look?

Sorry about that - I accidentally added them when rebasing to squash my commits down to one.
Looks better to me.

Looks OK to me.  Thoughts @herom ?

I removed the BEGIN check and fixed the case of the fields.
Thanks for the quick responses

Thanks a lot @ctarrington :+1:

Props to @darful for doing the real lift on the certificates!
And many thanks to @herom and @jsdevel for making the process quick and painless!

Please consider to unmerge this commit. It brings heavy dependancy upon ursa and really x509 support not needed, as anyone can easily convert x509 to key/crt
Ursa installing on windows is really pain and requires to install binary packages, what is unacceptable.

On which machine (OS, node.js, npm ... versions) are you running your code @CageFox ?

Windows 10 x64, Node 5, npm 3.7.3

I'm very new to certificates and all that, but if I have received a certificate file (with a password) from the vendor to whose service I am trying to connect, how do I use this package then?
The .WSSecurityCert function seems to ask for private and public keys, and I'm not sure if I should just call it like this, i.e. setting the private key to null:
new soap.WSSecurityCert(null, publicKey, password, 'utf8');
(I am currently trying to make ursa work, due to the usual node-gyp issues on Windows, so I haven't been able to try the above yet.)


cool

Really, your slides inspire me a lot and I should learn from you.

Really, your slides inspire me a lot and I should learn from you.
Thank you for your recognition, I will continue to do better.


Fix connectSome test util

Motivation
In connectSome() function, it does not check for duplicate, a peer may connect to less than the specified "num" peers
Description
Maintain candidatePeers array and do the random on its key.
Close #240

Codecov Report

Merging #241 (da7d51a) into master (dc29113) will decrease coverage by 0.16%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #241      +/-   ##
==========================================
- Coverage   80.31%   80.14%   -0.17%
==========================================
  Files          24       24
  Lines        7661     7661
  Branches      818      812       -6
==========================================
- Hits         6153     6140      -13
- Misses       1508     1521      +13

Impacted Files
Coverage Δ

ts/score/peer-score.ts
91.76% <0.00%> (-0.83%)
:arrow_down:

ts/index.ts
87.11% <0.00%> (-0.32%)
:arrow_down:

Continue to review full report at Codecov.

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


module-includes Swift compiler warning

Hello. Why i get these warnings and how to fix it?

Please provide more information about install method and software versions. Also, did this use to work for you?

Really strange, but it has disappeared itself.
I had a cocoapods swift project with bridging header.
Sorry for disturbing)


ignore calls to refresh while panning

possibly even internal calls?

Only ignoring external calls to refresh for now.


Update documentation for host/fileset/fileset template cmdlets

Is your feature request related to a problem? Please describe.

Review the Help and Examples for New-RubrikHost to offer more information on how this cmdlet works and more context as to what IDs are being consumed / leveraged by the cmdlet.
Review the Help and Examples for all Fileset related functions (this confuses people frequently)

Describe the solution you'd like
A clear and concise description of how to use Fileset Templates and Hosts to generate new, unique Filesets for those hosts.
More Examples on generating different Fileset Templates, perhaps with platform specific use cases (Windows, *nix).
Additional context
A brand new admin that has never before used Filesets / Fileset Templates / Hosts should be able to easily understand how these functions work and how to get started with them.

Fixed in #590


Annu kumari msft patch 2

@Winslohw - It looks like you're trying to sync content here, but we generally don't do tasks like this in the public repos. Because this PR provides no explanation about the purpose of the PR, we'll close it now.


Add template for pull requests to encourage better PR structure

What
Add a pull request template to the repository to guide people when raising a PR with hints about information that would be useful to provide (eg. screenshots, future works, questions that need answering), as well as reminders for code changes that might have been skipped (macro options, tests, CHANGELOG...)
Why
Consistent PR structure would help with review, especially if we nudge towards better description of what's in the PR.
Reminders about tests, doc changes... would help ensure the PRs contain everything that's needed for them to be merged (and avoid extra PRs to add them).
Who needs to work on this
Developers, Tech writers
Who needs to review this
Developers, Tech writers
Done when

[ ] We've decided on the content for such template
[ ] It has been added to the repository

Quickly browsing through recent PRs (especially those of @querkmachine which are always pretty thorough and well written), here's a base structure for discussion:

Logistics (optional): warning if the PR needs to wait before being merged of similar importance
Intro: high level description of the problem solved by the PR. Can be enough for small PRs
Background/Context (optional): if some context is needed to better understand the changes (eg. PR history)
Changes (optional): List of the changes that the PR brings
Thoughts (optional): Explain choices that were made in the PR and are not already described by the changes, or code/PR comments
Screenshots (optional): Screenshots that would help understand the changes
Todo (optional): If more work is needed to fully form the PR or as future work like:
- questions to answer before merge
- updates to make
- issues to create for future work once merged
This PR contains

[ ] Tests for the changes
[ ] Accessibility review
[ ] Documentation updates (macro options, Design System guidance, Frontend docs)
[ ] A CHANGELOG entry

Closes <ISSUE_NUMBER> (optional)


[Feature]: More "Show event time as" options

Requirements

[X] I did a search to see if there is a similar issue or if a pull request is open.

Is your feature request related to a problem?
No.
Describe the solution you'd like
It would be nice to have additional "Show event time as" options Such as the Day then date only, rather than the month and year as well, that can also be further reduced by using the 3 letter day format.
Describe alternatives you've considered
No response
Additional context
I like to show my next 2 collections, coz I have alternating trash type weeks, so it would be general waste, paper recycling, general waste, plastics & metals, repeat. With 2 events side by side, and full dates they don't fit on 1 row. I've used "days to" option instead, but I would prefer to see the day, as on public holidays the collection gets pushed back 1 day the following week, and it would be more helpful to see the day rather than "days to".

OK, update, since I've found a workaround that works for me, after playing around a bit more., I figured out if Horizontal Layout is selected and 2+ columns is entered, I can achieve the layout/look I was after, and the date just gets trimmed. But still might be nice for additional formats if it's achievable.

Great Card and I am happy to have it!! Thanks.
I would appreciate a show event time with weekday + remaining days. eg:
Monday in 3 days
Mon in 3 days
Tue tomorrow


Request WeatherAPI

Discussed in https://github.com/daledavies/jump/discussions/63

Originally posted by Tataukee October  3, 2022
Can you add weatherapi ? The openweather has never been working for me ?

And this works without the API key? The errors in your logs seem unrelated to problems with the weather API.
I'm reading this on my phone so can't quite see it properly but it looks like the site status function is caching a URL that is at the end of a redirect from one of your site's, it is complaining about the filename of the cache file created. This might be a bug but it isn't in any way related to the weather API.
Could you try with the API key in place and the CACHEBYPASS option set to true?

This is the only logs I could see unfortunately and the issue is happening from different browsers and different machines in my LAN including from my other iDevice, however when removing the OWAPI key the page just works .
This is by the way docker running in Synology and my browser is Safari I do not have any special setup or caching issues when running other containers . Tried both variables none of them seems resolving the issue .
I have the OWAPI Key working in other project , tested this morning and it's working . The app is launched from the same browser with the same machine and showing my weather correctly .

Thanks, can you test as I asked above with cachebypass and then checkstatus?

Just to confirm with you, those variables do you want me to include them on the docker compose environnement .
something like this in the screenshot ?

p/s: I have done one by one by the way , following your instructions

Yes as docker environment variables, thanks

None of the above seems to work . ( tried different browsers )

Can you forward the logs with each of these in place?

CACHEBYPASS = true logs :

 ██ ██    ██ ███    ███ ██████
 ██ ██    ██ ████  ████ ██   ██
 ██ ██    ██ ██ ████ ██ ██████

██   ██ ██    ██ ██  ██  ██ ██
█████   ██████  ██      ██ ██
https://github.com/daledavies/jump

Repopulating web root with application files.
You are using Jump v1.3.0<PHONE_NUMBER>)

Checking if backgrounds, favicon, search or sites volumes have been mounted.

Backgrounds directory is mapped... symlinking.
Favicon directory is mapped... symlinking.
Sites directory is mapped... symlinking.
Search directory is mapped... symlinking.

All done!  -
CHECKSTATUS = false logs :

 ██ ██    ██ ███    ███ ██████
 ██ ██    ██ ████  ████ ██   ██
 ██ ██    ██ ██ ████ ██ ██████

██   ██ ██    ██ ██  ██  ██ ██
█████   ██████  ██      ██ ██
https://github.com/daledavies/jump

Repopulating web root with application files.
You are using Jump v1.3.0<PHONE_NUMBER>)

Checking if backgrounds, favicon, search or sites volumes have been mounted.

Backgrounds directory is mapped... symlinking.
Favicon directory is mapped... symlinking.
Sites directory is mapped... symlinking.
Search directory is mapped... symlinking.

All done!  -

Hi There , Any feedback on this ?

The most recent error logs you forwarded don't actually show any errors, I'm afraid there isn't much for me to work with.
If you manage to capture any errors in the console or the docker error logs please forward them with detail of the configuration options in place at the time.

I was having the same 400 response issue from the weather API too.
I added a container name to the docker compose block, and also changed the environment variables mappings from the example to suite what my other docker image blocks looked like:
From:
landing-page:
  image: daledavies/jump
  ports:
    - 8123:8080
  volumes:
    - /opt/jump/backgrounds:/backgrounds
    - /opt/jump/favicon:/favicon
    - /opt/jump/search:/search
    - /opt/jump/sites:/sites
  environment:
    - SITENAME: 'Home'
    - OWMAPIKEY: 'myApiKeyWasHere'
    - LATLONG: '-34.083260,150.689774'
    - AMPMCLOCK: 'true'
    - SHOWSEARCH: 'false'
    - ALTBGPROVIDER: 'https://source.unsplash.com/random'
    - METRICTEMP: 'true'
    - CHECKSTATUS: 'false'

To:
landing-page:
    container_name: landing-page
    image: daledavies/jump
    ports:
      - 8462:8080
    volumes:
      - /opt/jump/backgrounds:/backgrounds
      - /opt/jump/favicon:/favicon
      - /opt/jump/search:/search
      - /opt/jump/sites:/sites
    environment:
      - SITENAME=Home
      - OWMAPIKEY=c249362bbe942c167cf2834a1920ea8a
      - LATLONG=-34.083260,150.689774
      - AMPMCLOCK=true
      - SHOWSEARCH=false
      - ALTBGPROVIDER=https://source.unsplash.com/random
      - METRICTEMP=true
      - CHECKSTATUS=false

Weather API works fine now 🤷

I was having the same 400 response issue from the weather API too.
I added a container name to the docker compose block, and also changed the environment variables mappings from the example to suite what my other docker image blocks looked like:
From:
landing-page:
  image: daledavies/jump
  ports:
    - 8123:8080
  volumes:
    - /opt/jump/backgrounds:/backgrounds
    - /opt/jump/favicon:/favicon
    - /opt/jump/search:/search
    - /opt/jump/sites:/sites
  environment:
    - SITENAME: 'Home'
    - OWMAPIKEY: 'myApiKeyWasHere'
    - LATLONG: 'mylat,mylong'
    - AMPMCLOCK: 'true'
    - SHOWSEARCH: 'false'
    - ALTBGPROVIDER: 'https://source.unsplash.com/random'
    - METRICTEMP: 'true'
    - CHECKSTATUS: 'false'

To:
landing-page:
    container_name: landing-page
    image: daledavies/jump
    ports:
      - 8462:8080
    volumes:
      - /opt/jump/backgrounds:/backgrounds
      - /opt/jump/favicon:/favicon
      - /opt/jump/search:/search
      - /opt/jump/sites:/sites
    environment:
      - SITENAME=Home
      - OWMAPIKEY=myApiKeyWasHere
      - LATLONG=mylat,mylong
      - AMPMCLOCK=true
      - SHOWSEARCH=false
      - ALTBGPROVIDER=https://source.unsplash.com/random
      - METRICTEMP=true
      - CHECKSTATUS=false

Weather API works fine now 🤷

As there is no workable information in the error logs and I can't recreate the problem I'm closing this issue. If you do manage to capture any errors relating to this in your logs please reopen.


[DebugInfo] Salvage all stores

Salvage all stores and store_borrow in salvageDebugInfo. Instead of having a special case in Mem2Reg, we can have a more generic implementation which replaces stores with the expected debug info.
Now that Mem2Reg doesn't drop as much info (75% less variables dropped by the pass), this also removes the special case in GenericSpecializer (debug values would otherwise be duplicated)
Also, when salvaging stores, we now use the VarInfo's Loc and Scope properties to indicate the declaration of the variable, and use the location of the store for the location where the debug value is set, instead of using a hacky workaround for arguments only.
This PR also adds special support for salvaging copy_addr in the CopyForwarding pass, using the same system for salvaging stores.
This decreases the number of lost variables in the standard library at the SIL level by 1.3%, and doesn't change significantly the amount of variables at the DWARF level.

@swift-ci please test

Looks like the number of lost variables has actually regressed with the last changes. Needs more work

@swift-ci please test

@swift-ci please test

@swift-ci please test source compatibility

I dropped the commit about uninhabited types, it was causing an infinite loop, and it isn't that impactful

@swift-ci please test

@swift-ci please test source compatibility


BGP: Support MD5 Authentication

Cilium Feature Proposal
Is your feature request related to a problem?
For most production environment configuring BGP MD5 authentication is considered a must and a best practice
Describe the feature you'd like
This feature was already discussed in this comment: https://github.com/cilium/cilium/issues/19376#issuecomment-1099904483
however I do not think was ever implemented, since goBGP already support Password Authentication this should be easy to implement. Something like this would work great:
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPPeeringPolicy
metadata:
  name: rack2
  namespace: kube-system
spec:
 nodeSelector:
   matchLabels:
     rack_id: "2"
 virtualRouters: # []CiliumBGPVirtualRouter
 - localASN: 65003
   exportPodCIDR: true
   neighbors: # []CiliumBGPNeighbor
    - peerAddress: "<IP_ADDRESS>/32"
      peerASN: 65002
      peerPassword:
        secretKeyRef:
          name: bgp-password
          key: password

/cc @dylandreimerink

👋🏻 We're so waiting for this feature to land, was happy to see some activity here! 🙂
We've solved this temporarily, and the other part of our setup with dynamic neighbors, by using BIRD alongside Cilium. This is sub-optimal and we would much rather use the Cilium BGP support via gobgp.
If we can help out in any way let me know!

For ref:
PR that adds this feature: https://github.com/cilium/cilium/pull/23759 👏🏻

We'd love to switch to cilium for a plethora of reasons, but until this feature is implemented, we'll have to stick to the stale setup with metallb (deprecated).

We'd love to switch to cilium for a plethora of reasons, but until this feature is implemented, we'll have to stick to the stale setup with metallb (deprecated).

Things are slowly but surely progressing in this PR: https://github.com/cilium/cilium/pull/23759

Now that https://github.com/cilium/cilium/pull/23759 merged, I believe this issue can be closed. @YutaroHayakawa @rastislavs @harsimran-pabla can you confirm?

Thanks for the heads up! I'll close this.

Thank you for this! I just tested 1.15.0-pre.2 and it works perfectly fine!


flink write carbon file to hdfs when file size is less than 1M,can't write

write carbon file less than 1M , less than configured minimum value (dfs.namenode.fs-limits.min-block-size) 1M ;can't write hdfs file
the default block size is set  1024 byte and compare with  file size;when file size big than 1KB but less than 1M ,can not write file to hdfs ;so set default block size to 2M
Does this PR introduce any user interface change?

No

Is any new testcase added?

No

Can one of the admins verify this patch?

Add to whitelist

retest this please

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3741/

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2001/

@yutaoChina : Thanks for working on this.
a) please handle the compilation error
b) please create a jira issue and add it in the issue header

@yutaoChina : Thanks for working on this.
a) please handle the compilation error
b) please create a jira issue and add it in the issue header
this is jira issues
https://issues.apache.org/jira/browse/CARBONDATA-3925

retest this please

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3805/

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2064/

@yutaoChina : Thanks for working on this.
a) please handle the compilation error
b) please create a jira issue and add it in the issue header

my jira id is yutaochina

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2068/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3809/

@yutaoChina : you can run
mvn clean install -Pspark-2.3 -Pbuild-with-format -DskipTests in your IDE to find all findbugs, checkstyle, scalastyle issues.
Now also it has some check style issue

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2080/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3821/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2086/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3827/

LGTM. Thanks for the contribution!
Spark 2.3.4 build failure is a known random issue, we are working on it. So, merging this PR.


relocate temp files to /var/tmp

Changed /private/tmp to /var/tmp due to issues experienced with the former returning older versions of the file if recently updated (why? no idea) which could cause the OS Compatibility Check to fail.
Also added in a validation check to make sure we have a model name. This wasn't directly an issue but it could potentially be so adding it in for completeness.
Each script has been tested (N=1).
Additionally macOSCompatibilityCheck-EA.sh has been tested in a Jamf Pro environment where the issue was first noticed

context for the issue in this thread on the macadmins slack https://macadmins.slack.com/archives/C0224B1QUSK/p1726531830871869


Release 0.4.7

Codecov Report
Base: 73.62% // Head: 94.16% // Increases project coverage by +20.53% :tada:

Coverage data is based on head (cc5ca14) compared to base (59cf765).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #301       +/-   ##
===========================================
+ Coverage   73.62%   94.16%   +20.53%
===========================================
  Files         190      114       -76
  Lines        9270     3049     -6221
  Branches      767      353      -414
===========================================
- Hits         6825     2871     -3954
+ Misses       2037      178     -1859
+ Partials      408        0      -408

Flag
Coverage Δ

backend
94.16% <ø> (ø)

frontend
?

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

Impacted Files
Coverage Δ

...nt/src/components/InputsModal/InputsRadioGroup.tsx

...tails/TestGroupListItem/NestedDescriptionPanel.tsx

client/src/store/app.ts

client/src/models/testSuiteModels.ts

...nts/RequestDetailModal/__mocked_data__/mockData.ts

...mponents/TestSuite/TestSuiteTree/TreeItemLabel.tsx

...TestSuiteDetails/TestListItem/InputOutputsList.tsx

...nfigMessagesDetails/ConfigMessagesDetailsPanel.tsx

...s/TestSuite/TestSuiteDetails/TestSuiteMessages.tsx

client/src/components/Footer/Footer.tsx

... and 66 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Pods go to evicted state after import an image multiple times

We deploy a cluster of nodes after creating a k3d cluster (k3d create --api-port 6550 --publish 31215:80  --server-arg "--no-deploy=traefik"). In our cluster, we need to make some changes in an image and load the image into the cluster to deploy it again. I observed when I repeat the k3d import-images command multiple times, the pods go to evicted state and the cluster become unstable. I have not seen this behavior with other tools like kind.
P.S. I just noticed that it is not dependent to import-images command. It happens anyway.
P.S. I pruned a little bit the images and it looks normal now but the question is why under the same conditions "kind" cluster doesn't  lead us to evicted state.

Hi, thanks for opening this issue.
Can you give us a few more details please?
e.g.

version of k3d (and k3s)
version of docker
operating system
docker logs of the server container when this happened
a kubectl describe of at least one of the evicted pods

Beware, that k3d is fairly different from kind, so comparisons on this level are quite tough, because we're using different approaches and Kubernetes distros.

k3d version v1.3.2
Docker version 18.09.2, build 62479
Mac OS
I don't have any logs at this moment to report because when that happened because I pruned my images and then it looks normal now.  Whatever the reason is, it is related to lack of resources for deployments. I will try to reproduce it If can but I am not sure that is going to happen soon. I am trying to convince myself if k3d is a better solution when compared with kind since it supports ingress stuff. If you can give me more info about the approach that you are using that would be great.
Thanks

That looks good to me. Logs would be very interesting though, so it would be great if you could fetch them in case this happens again.
k3d is not setting any limits on the containers, in fact, they're even running in privileged mode.
k3s which is running inside the k3d nodes, is also not setting any limits as far as I know.
The only thing that I could imagine is happening would be, that the VM that Docker for Mac is running in has some kind of restriction/limits, but I really don't know this.
Personally I'm using k3d on Linux and my co-workers on MacOS and we never experienced such a problem. You might want to consider starting the cluster with at least one worker node (--workers 1), so you don't drop everything on the master node (which might keep the cluster stable, in case there's really some container limit).

So I experienced the same issue when I created a 4 node cluster on my dev laptop.
I deployed the elastic-cloud operator and created a 3 node ElasticSearch cluster bound to a single node.
Then, when I deployed Kibana, all pods (also on other nodes) were evicted because of NodeHasDiskPressure.
df -h inside the nodes and on my laptop revealed 95% usage on /.
I deleted some stuff from my device and ended up with around 70% disk usage on my laptop.
Afterwards, I didn't have anymore problems with evicted nodes because of DiskPressure.
So I guess, that it's really just caused by the device disk usage... :thinking:

@iwilltry42
Under the same conditions, kind cluster was working fine for my case and also I ended up removing some of the images from my laptop.

@adibrastegarnia are you by chance running Docker for Mac?

@iwilltry42
Yep. I am using Mac.

What does df -h output on your local machine, inside the Docker VM and inside the k3d node containers for you?
I should've noted, that I'm running on Linux, so things might be a bit different for me regarding docker.

At this moment, I don't have that problem anymore that I can share the
output with you. df -h looks normal at this moment.
Filesystem      Size   Used  Avail Capacity iused      ifree %iused
Mounted on
/dev/disk1     233Gi  126Gi  106Gi    55% 2070217<PHONE_NUMBER>    0%   /
devfs          187Ki  187Ki    0Bi   100%     648          0  100%   /dev
map -hosts       0Bi    0Bi    0Bi   100%       0          0  100%   /net
map auto_home    0Bi    0Bi    0Bi   100%       0          0  100%   /home
On Sun, Oct 20, 2019 at 3:39 PM Thorsten Klein<EMAIL_ADDRESS>wrote:

What does df -h output on your local machine, inside the Docker VM and
inside the k3d node containers for you?
I should've noted, that I'm running on Linux, so things might be a bit
different for me regarding docker.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rancher/k3d/issues/119?email_source=notifications&email_token=ACPCVXAVP7VTSECLNOFFTDTQPSXU5A5CNFSM4I56ZKV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYSBKY#issuecomment-544284843,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPCVXAIOSLCWYZ7RQUZ5F3QPSXU5ANCNFSM4I56ZKVQ
.

I will research a bit more tomorrow, but I have a feeling, that it's not directly related to k3d or k3s, but rather to the execution environment (Docker and Host FS).
The VM that docker for Mac runs in has a different disk size, so that's why I was interested in the  other df outputs :+1:

I had the same issue on docker for mac but it resolved once I updated to the latest version of docker for mac.

Closing this in favor of https://github.com/rancher/k3d/issues/133


run-tests error

Environment:
macOS Sierra:10.12.6
Xcode: 9.0
Swift: 4.0
xctool: 0.3.3
to use command line to test:
xctool -workspace myProject.xcworkspace -scheme myProjectTests -destination 'platform=iOS Simulator,name=iPhone X,OS=11.0' run-tests -only myProjectTests -sdk iphonesimulator
Error info:
*** Assertion failure in -[SimulatorInfo init], /tmp/xctool-20170901-19829-1s5ox9o/xctool-0.3.3/xctool/xctool/SimulatorWrapper/SimulatorInfo.m:70
Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Failed to inialize simulated service context with error: (null)'
*** First throw call stack:
(
0   CoreFoundation                      0x00007fff8d2f42cb __exceptionPreprocess + 171
1   libobjc.A.dylib                     0x00007fffa210448d objc_exception_throw + 48
2   CoreFoundation                      0x00007fff8d2f9042 +[NSException raise:format:arguments:] + 98
3   Foundation                          0x00007fff8ed41be0 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 195
4   xctool                              0x0000000108d7a6b0 -[SimulatorInfo init] + 398
5   xctool                              0x0000000108d622d2 -[Options _validateDestinationWithErrorMessage:] + 65
6   xctool                              0x0000000108d60ea2 -[Options validateAndReturnXcodeSubjectInfo:errorMessage:] + 104
7   xctool                              0x0000000108d52a76 -[XCTool run] + 2663
8   xctool                              0x0000000108d515ce main + 1208
9   xctool                              0x0000000108d4c6a4 start + 52
10  ???                                 0x000000000000000c 0x0 + 12
I can run tests fine with Xcode8.3.But upgrade Xcode9 ,run-tests is error.

the same Failed to inialize simulated service context with error: (null)

Same error to me.

I also have the same problem with guys :(

Thanks iainmcgin!,
It's works for now :)

I can't find a way to repro this.
Whoever is experiencing this issue can you try opening simulator app before running xctool. Does it solve the problem?
open /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app```

In addition, when you encounter this issue, can you run ps -eo 'tty,pid,comm' | grep -i simulator and post output here?

Please open new issue if anyone hits this again. Thanks!


ReactiveState: add hooks

Added here: https://github.com/worona/meteorflux/commit/4769f153eafe77d29ff6cb4bde3993018f86ca7d


Do I need a config.json file somewhere?

I get a client side popup with
Error: You must configure your OpenAI API Key in the config.json to use the "Respond with AI" feature.
on  the server side I see this
ERROR MESG Could not send. Connection not open.

Hey @timsears, we are working on updating this code.
You need to set an environment variable, see the relevant code here: https://github.com/deepgram/real-time-voice-bot/blob/main/server.js#L88


Able to make a portal that goes to 0,0,0 very easily, and could be done by mistake making the player loose all their items to the void

To reproduce:
Shoot any color portal on any surface that fits it
Shoot another portal of the same color on top of that portal
That portal's destination is now 0,0,0

This isn't THAT high of a priority for me as let's be real who's gonna shoot the same color portal and go through it without placing the other color