Increase coverage of conditional mutation rejection handling code.

Ample has code related to handling special cases related to conditional mutations that is usually not exercised under normal circumstances.   One way this code is exercised in test is by use of TestAmple like what ComprehensiveFlakyAmplIT does.   Need to increase the coverage of the Ample RejectionHandler lambdas by having more test code use FlakyAmpleManager and FlakyAmpleTserver.
Can use #4704 to determine what is covered and not covered.

Ran ComprehensiveFlakyAmpleIT w/ coverage and look at areas that were not covered.  Found the following high level areas so far

volume replacement
concurrent user compactions on same tablet -- USER_COMPACTION_REQUESTED
unload ondemand tablet in tablet server
walog recovery

While researching this noticed the volume replace condition update is checking the files it added are present on failure.  Because of race conditions they may have been added but not be present.  It should probably check the files it removed are not there to see if the update went through.  I plan to make this change when adding test for volume replacement, this is comment is a reminder to do that.
https://github.com/apache/accumulo/blob/3ad9198a86ae9f8b2b24831f6593d33362f8088a/server/manager/src/main/java/org/apache/accumulo/manager/TabletGroupWatcher.java#L1051-L1053

I wanted to reuse some code in the CompactionIT with FlakyAmple. I was looking into taking a different strategy for this rather than extending classes.  Looked in to using junit Tags and TestInfo, was hoping I could annotate a test method with @Tag(FLAKY_AMPLE), but I have not completely figured out how to do this in a way that is not disruptive.

Ran the following with code coverage.
mvn clean -PskipQA -DskipTests=false -DskipITs=false -Dit.test="*FlakyAmple*IT,ManagerRepoIT" -Dtest=nothing -DfailIfNoTests=false verify

and found the following.

Need to increase the coverage of unsplittable case by modifying ManagerRepoIT
Need to get coverage on CompactionCoordinator.compactionFailedForLevel
The following has no test at all CompactionDriver.cleanupTabletMetadata, will open an issue.

I can work on creating a test for CompactionCoordinator.compactionFailedForLevel so that we can close out this issue as CompactionDriver.cleanupTabletMetadata will be opened as a separate issue. I'll probably try and do something with TestAmple first as that has the interceptor to support the unknown status but FlakyAmpleManager is also an option depending on what is easiest when I take a look.

The following has no test at all CompactionDriver.cleanupTabletMetadata, will open an issue.

Opened #4795

I can work on creating a test for CompactionCoordinator.compactionFailedForLevel so that we can close out this issue as CompactionDriver.cleanupTabletMetadata will be opened as a separate issue. I'll probably try and do something with TestAmple first as that has the interceptor to support the unknown status but FlakyAmpleManager is also an option depending on what is easiest when I take a look.

I opened up #4797 and I went with using FlakyAmpleManager after all as that was by far the simplest way to test after having tried to use TestAmple. There were already good tests for cancellation that would exercise the failed compaction code so using Flaky ample exercises the rejection handler inside CompactionCoordinator.compactionFailedForLevel


Update the Mgmt. core lib with right category

Add background: This is to fix our sdk reference ToC in ms learn, Resource Manager should not be placed in Other category


Lambda layer does not compute masked values properly

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Windows 10
TensorFlow installed from (source or binary):
conda binary
TensorFlow version (use command below):
'2.1.0'
Python version:
3.7

Describe the current behavior
Output of the model with lambda subtracting 0.5 from input, and input as [1, -10], with -10 being masked value
<tf.Tensor: shape=(1, 2, 1), dtype=float32, numpy=
array([[[ 0.5],
        [-0.5]]], dtype=float32)

Describe the expected behavior
Output
<tf.Tensor: shape=(1, 2, 1), dtype=float32, numpy=
array([[[ 0.5],
        [ 0. ]]], dtype=float32)

or
<tf.Tensor: shape=(1, 2, 1), dtype=float32, numpy=
array([[[ 0.5],
        [ -10. ]]], dtype=float32)

Standalone code to reproduce the issue
import numpy as np
from tensorflow import keras
inputs_shape = (2, 1)
inputs = keras.layers.Input(shape=inputs_shape)
masked = keras.layers.Masking(mask_value=-10., input_shape=inputs_shape)(inputs)
output = keras.layers.Lambda(lambda x: x - 0.5)(masked)
model = keras.Model(inputs=inputs, outputs=output)
data = np.array([[1, -10]], dtype=np.float32).reshape(-1, 2, 1)
model(data)

I have tried in colab with TF version 2.1, 2.2, nightly version(2.3.0-dev20200602) and was able to reproduce the issue.Please, find the gist here.Thanks!

I ran the code shared and the issue still persist on tf-nightly[2.4.0-dev20201012], please find the gist here.

@Strateus I think this is intended behavior. If you look at the input to the lambda layer is [1,0] and during lambda x: x - 0.5 we are deducting 0.5 which results in [0.5,-0.5]. Please take a look at the gist here. Thanks!
model2 = keras.Model(inputs=inputs, outputs=masked)
model2(data)

Output is
<tf.Tensor: shape=(1, 2, 1), dtype=float32, numpy=
array([[[ 1.],
        [-0.]]], dtype=float32)>

Please verify once and let me know if I am missing anything. Please close the issue if this was resolved for you. Thanks

@jvishnuvardhan your interpretation of masking seems to be different from the official one: Masking is a way to tell sequence-processing layers that certain timesteps in an input are missing, and thus should be skipped when processing the data.
check here: https://www.tensorflow.org/guide/keras/masking_and_padding
Skipping means you return input value all the time, not matter what processing you have inside the layer. An alternative would be to return a value of a mask itself (but this is less common).
Lambda layer should not deduct anything for the masked values, but it currently does, which is incorrect.
Your gist shows something else: that lambda layer is working without mask. I was not claiming it is not working with masking. I was claiming masking inside Lambda layer is not working.

Hi There,
This is a stale issue. As you are using an older version of tensorflow, we are checking to see if you still need help on this issue. Please test the issue with the latest TensorFlow (TF2.7 and tf-nightly). If the issue still persists with the newer versions of TF, please feel free to open it in keras-team/keras repository by providing details about the issue and a standalone code to reproduce the issue. Thanks!
Please note that Keras development has moved to a separate Keras-team/keras repository to focus entirely on only Keras. Thanks!

Omg just fix it, it still persists in 2.7


Feature/5 create test pipeline

Added test pipeline
Issue 5
Checklist before requesting a review

[ x] I have performed a self-review of my code.

@kate-livinska the pipeline config looks good. But maven wrapper is missing.
Task 3 has just been merged into main so you can rebase your branch feature/5-create-test-pipeline onto main.
Please rebase onto main, add mvnw and push your changes into this branch.  Thanks :)

@ownerofglory done, thanks!
I added Maven wrapper from ticket 6 on a separate branch, based on the updated main, and then rebased the test-pipeline branch on it.


fix: pass --trust to frontend

During a discussion a few weeks ago on Lake issue #24, I discovered that the Lean shell doesn't actually pass its trust level to the frontend.  Since this appears to be a quick fix, I went ahead and made this PR.

cc @leodemoura


InGameInfoXML-1.8.9-<IP_ADDRESS>-universal error

Whenever I start my minecraft I get this error

And I have LunatriusCore-1.8.9-<IP_ADDRESS>-sources in my mods folder!
I need help :D

LunatriusCore-1.8.9-<IP_ADDRESS>-sources.jar would be the source code for the mod.  You want just LunatriusCore-1.8.9-<IP_ADDRESS>.jar (also, note that 1.8.9 is rather old)


training on my own dataset

Hi Dear Wang,
If I find out correctly,

Pretraining with SynthText section, train model using SynthText dataset.
In the Training section, we have 2 choises: a)training from scratch which train model with only TotalText dataset and b) training with pretrained model.

Is these correct?
My question is that: I have 100 images. How can I prepare them to training?
thanks

Hi, according to your description, your own training data are small, so the
best way is training based on SynthText or TotalText(the weight I uploaded
is based on SynthText pretrained model also) than you can try fixing some
layer of backbone network.
Preparation:

download the SynthText/total pretrained model
write your own dataset imitating dataset/total_text.py for file reading
and polygons points getting.
modify train_textsnake.py by adding your own datasets.

On Sun, Sep 15, 2019 at 7:48 PM johnSmith1990<EMAIL_ADDRESS>wrote:

Hi Dear Wang,
If I find out correctly,

Pretraining with SynthText section, train model using SynthText
dataset.
In the Training section, we have 2 choises: a)training from
scratch which train model with only TotalText dataset and b) training with
pretrained model.

Is these correct?
My question is that: I have 100 images. How can I prepare them to training?
thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/princewang1994/TextSnake.pytorch/issues/32?email_source=notifications&email_token=ADZMHI223YV6DJSGHIQBHKDQJYOHBA5CNFSM4IW2JT2KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLNWEWA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADZMHI6FZU22A7OTOHNE7U3QJYOHBANCNFSM4IW2JT2A
.

thanks. I labeled my data and split it to test and train and copied dataset/total_text.py for my own and edited it. but when i run train_textsnake.py it gives an error like this: link: https://file.io/9dTxb7
is it because of evaluation? other modification need? Do I use validation data?

Sorry that I always failed to access gofile.io, can you post error log on this issus directly? thx.

Ok I have saw it, that error is strange, seems that you write your own train_bullet1.py. For finding out the true error, you can print loss, tr_loss, tcl_loss, sin_loss cos_loss, radii_loss to show which one is of type float and we can further analyze what makes it.

Hi, No
I dont write my own train file.
I only rename yours. Ok I will screen shot your idea. this error not accur for SynthText and TotalText dataset.

I add print lines to code. here is output for 2 run :
https://pasteboard.co/IynKOKc.jpg
one for resume training with TotalText (right) and other for resume training with my dataset(left). in my dataset training tcl_loss, cos_loss, sin_loss and radii_loss was zero.

The most probable reason is that the dataset you create newly make unsuitble output, you should may sure tcl and tr mask is right by showing img, train_mask, tr_mask, tcl_mask, radius_map, sin_map, cos_map after this line. In  your case, these masks may be all blank, which cause the zero-loss error. If so, double check dataset you write produces right polygon.

yes, you right. those were blank.
but how do i correct it?
I used T3_v3.m file in https://github.com/cs-chan/Total-Text-Dataset/tree/master/Annotation_tools/T3/src
for produce .mat gt for each image. the result was a .mat file for each image(as was for TotalText dataset). How do i produce train_mask, tr_mask, tcl_mask, radius_map, sin_map, cos_map
? If i don't do a step for producing gt files?

These masks are produced with existing code in dataset/dataload.py only
thing you should do is reading your data correctly, that is to say, create
new mydata.py in dataset/, read your own data, and call self.
get_training_data(image, polygons, image_id=image_id, image_path=image_path)
in your own dataset's getitem(self) function with image_id and
image_path. So you should check whether the variable image and polygons
contains right image and
coordinates.
On Sat, Sep 21, 2019 at 3:55 PM johnSmith1990<EMAIL_ADDRESS>wrote:

yes, you right. those were blank.
but how do i correct it?
I used T3_v3.m file in
https://github.com/cs-chan/Total-Text-Dataset/tree/master/Annotation_tools/T3/src
for produce .mat gt for each image. the result was a .mat file for each
image(as was for TotalText dataset). How do i produce train_mask, tr_mask,
tcl_mask, radius_map, sin_map, cos_map
? If i don't do a step for producing gt files?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/princewang1994/TextSnake.pytorch/issues/32?email_source=notifications&email_token=ADZMHI3GUH7JI5AAHCSD2YDQKXOP5A5CNFSM4IW2JT2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7IMZIA#issuecomment-533777568,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADZMHI6GGHECFJKU6XVM3DLQKXOP5ANCNFSM4IW2JT2A
.

Very Very thanks for your patience and helpness.
The problem was for .mat files. For TotalText dataset gt  .mat files name is poly_gt_img#.mat and it's variable is polygt that contain polygon and label, but T3_v3.m file that I used for labeling, saved gt's by name gt_img#.mat and it's matrix, gt. I renamed and re saved matrices and problem was solved.
(of course when I create mydb.py file in dataset folder I modified poly_gt to gt and so on but not solved).

It's so happy to hear that. Since the problems are solved, I will close this issue. If there are any other questions, it can be reopened.


[#866] [Part-2] feat(tez): Add Tez Input class related orderedgrouped

What changes were proposed in this pull request?
Support tez read using Remote Shuffle Service related orderedgrouped .
Why are the changes needed?
Fix: https://github.com/apache/incubator-uniffle/issues/866
Does this PR introduce any user-facing change?
No.
How was this patch tested?
We will add test cases in a few days

Codecov Report

Merging #867 (44eda3d) into master (6bd8d13) will increase coverage by 1.41%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #867      +/-   ##
============================================
+ Coverage     56.58%   57.99%   +1.41%
+ Complexity     2174     2041     -133
============================================
  Files           327      290      -37
  Lines         15977    12661    -3316
  Branches       1262     1185      -77
============================================
- Hits           9040     7343    -1697
+ Misses         6429     4913    -1516
+ Partials        508      405     -103

see 42 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

This pr is a little large. A proper pr should be less than 1000 lines. It's best that the pr is 500 lines.

We can submit the file RssShuffle first. It's 500 lines file.


Issue with llamacpp version larger than 0.2.37

@noamgat I haven't fully looked into this but on version 0.2.38 of llamacpp with this library and outlines as well, the generation fails.
The change to llamacpp 0.2.37 does fix both libraries' generation problems while both does struggle with 0.2.38. The outlines devs seem to have a fix here

According to the llama-cpp-python changelog, they fixed an off-by-one error in version 0.2.42.
https://github.com/abetlen/llama-cpp-python/blob/main/CHANGELOG.md

Oh awesome I'll test out

Verified that new version is working. Closing.


Fix issues introduced with #304 PR

what
Fixed the issues found in templates/Makefile.build-harness and modules/terraform/Makefile

stat call needed -c option before %i
echo call needed $ replaced with space

why
Unmodified these caused unexpected errors as mentioned in #305
references
closes #305

Unfortunately stat -c is not portable, just as stat -f is not portable. We will fix this in #309 by using the POSIX standard ls -i.


INancyEngine should be disposable and be disposed when the boostrapper and container is disposed.

Main problem is here. When the middleware ( -> boostrapper -> container) is disposed, Nancy is still handling requests. Sometimes successfully.
INancyEngine should be IDisposable and here should be seeing an ObjectDisposedException.

Not sure I agree with this, using Dispose as a flag to "not accept requests" sounds smelly to me when we have no resources that need cleaning up. What issue does it actually cause?

NancyEngine holds a reference to a bunch of resourses https://github.com/NancyFx/Nancy/blob/master/src/Nancy/NancyEngine.cs#L26 (not sure if they're disposable or not).
Nonetheless, philosophically, if a middleware has been disposed, it shouldn't be able to handle requests. Pit of success, fail fast etc.

Did you guys ever reach a consensus on this? @grumpydev @damianh

No consensus. I still think it needs to be fixed.


about Exception return

in follow code, run it, should print:
throw a error
2
but ,i run it ,print many errors
[0x5892dd] main +18893
[0x7f64f89cb830] __libc_start_main +240
[0x5562e1] ???
module TestException
  extend self

  puts main

  def main
    begin
      test_ex(3)
    rescue ex
      puts ex.message
      return 0
    ensure
      puts "finally"
	  return 2
    end
    return 1
  end

  def test_ex(a)
    if (a > 1)
      raise Myex.new("throw a error")
    end
  end
end

class Myex < Exception
  def initialize(@message )
    super(@message)
  end
end

It's a compiler bug, the error you get is not at runtime, try crystal build program.cr.
Reduced:
def foo
  begin
    raise "throw a error"
  rescue ex
    return 0
  ensure
    return 2
  end
end

foo

Also:
def foo
  return 0
ensure
  return 2
end

foo

@asterite what should be the correct behavior?

I was going to say that I would find more intuitive what c# does in this case: not allowing return in ensure blocks. My first impression is to doubt about the semantics in this case.
I've never used that pattern.
@MakeNowJust is having fun with the compiler though.
Any insight where this pattern is particularly useful?
I'm fine keeping ruby semantics, but not just because of it.

I think it comes just natural: The ensure block follows after the begin and rescue blocks both lexical and in the execution sequence. So it would also be arguable to use the last expression of the ensure block as return value. Though this is probably not intended in most cases.
But it should at least be possible to change the return value explicitly from the ensure block. This can be necessary for example when you're returning error objects instead of exceptions. If an error is only detected in a cleanup task in the ensure block there would be no other direct way to communicate that.  An other use case would be enhancement of return values with for examples statistics (like time spent) in case of normal execution as well as when a rescue block was triggered.

My conflict comes from the premise that return finalize the execution of the current function. For sure surroundings ensures are executed.  But mixing them introduce the concept of overriding the returning value, whether otherwise once a return in reach the return value is determined.
@straight-shoota you mean something like this?:
def foo
  begin
    return :ok
  ensure
    begin
      clean_up_that_might_raise
    rescue
      return :err
    end
  end
end

I think the following could work also I think and it doesn't need the return in ensure.
def foo
  begin
    begin
      return :ok
    ensure
      clean_up_that_might_raise
    end
  rescue
    return :err
  end
end

But the first comes a bit cleaner maybe.

Yes, or even simpler:
def foo
  begin
    return :ok
  ensure
    return :err unless clean_up_that_might_detect_fail
  end
end

Of course, this could also be written in a different way, but that would sacrifice expressiveness and with some more complex rescue and ensure operations lead to unnecessary code duplication.
Even if the ensure block could not change the return value, it can always raise (and I don't assume you'd want to change that). Therefore the return value from the main body is not as determined as it might seem anyway, because it could still be surpassed by an exception.
If the ensure block raises, this also overwrites an uncatched exception from the main block. This might also be bad, because you loose the initial failure and catch one that might just be a result from that. And anyway, you should always keep the ensure block as simple as possible. Most of the time you will never need to change a return value or raise (and possibly overwrite) an exception, but I'd argue that it should be possible and helpful in some cases.

I've been thinking about this over the course of the past day, and my instinct is to disallow returns in ensure blocks. I'm not entirely sure why, but @bcardiff's point that return should finalize the execution of the function seems like a big part of it.
To @straight-shoota's point: when a method raises, I see it as essentially panicking up the stack, bypassing return entirely. With that, I wouldn't agree that the return value isn't "determined",  rather that the return value is not guaranteed to be present. I think that logic also holds with why having a return in a rescue block is valid. Whatever raise brought execution to the rescue did not set a return value, and so rescue has the authority to set one.
In the case of ensures that may raise, I had a quick thought of allowing rescues after an ensure, but I'm pretty skeptical of using it in practice:
def foo
  return :ok
ensure
  raise :not_ok
rescue
  return :err
end

While this looks very clean, I don't like that ensure is no longer always the final branch of a begin/rescue/else/ensure stack, so I wouldn't suggest it as a good solution. To that extent, I would almost argue that an un-rescued raise in an ensure should also be disallowed.

If ensure is allowed to explicitly override the return value of the function, I think it should necessarily take an argument that is the current return value. I think this would make it more obvious that the return value may be changed by the block. As an example:
def foo
  return :ok
ensure
  return :ensured # => invalid, `ensure` does not receive a return-value argument.
end

def foo
  return :ok
ensure result
  return :ensured # valid, `result` is the return value at time-of-entry.
end

To me, this syntax makes it clear that any return value may be modified, but also ensures that it will not be modified unless ensure specifies the argument (Note: ensure without an argument would still be valid, but would guarantee an unchanged return value. See examples below)
Going further, implicit return values would be more trustworthy. If an ensure does not take an argument, then any implicit return value will be ignored (and explicit returns are considered illegal). If the ensure does take an argument, then the return value will be whatever comes from the ensure block, be it implicitly or explicitly set. Another example:
def foo
  :ok
ensure
  :err
end

foo # => :ok

def foo
  return :ok
ensure
  return :err # invalid
end

def foo
  return :ok
ensure result
  :err
end

foo #=> :err

def foo
  return :ok
ensure result
  result
end

foo #=> :ok

I've thought about the argument, too. But I find a return statement is already explicit enough and I don't think that an ensure block should allow an implicit return value, even with such an argument.
I believe it would even encourage the use of ensure for return value modification (which is probably not the best thing to do in most cases), if it would take the return value of the main block as an argument and return implicitly.

To that extent, I would almost argue that an un-rescued raise in an ensure should also be disallowed.

Well, what would you do to ensure to run code that might raise? If you rescue it, can you raise from the rescue block? Or can you change the return value from there?

Well, what would you do to ensure to run code that might raise?

It would still allow raising in the ensure, but they would have to be rescued (as bcardiff's first example shows). This would then preserve any raise from the previous clauses, and would force users to handle those raises explicitly. If a cleanup raises and it is not recoverable, is there a case where the appropriate solution wouldn't be aborting execution in some way?
I'm really not sure of a good solution here, so I'm kind of just throwing out ideas for now.

If you rescue it, can you raise from the rescue block?

I believe (I know it is in Ruby, but can't test Crystal atm) that rescue is cascading, i.e., raising in a rescue is also rescuable by any following rescue clauses (hence the thought of having rescues after ensure, but I find that particular use more confusing than anything else).

This article ("Ensure With Explicit Return") by Les Hill has some interesting insights into how this works in Ruby. I recommend reading the whole thing, but here are the bits I found most important:

The second thing to note is that the explicit return statement acts as an implicit rescue clause, allowing the code to resume as if no exception had been raised.

Consider the following code:

def some_method
  thing.method_that_might_raise!
rescue Exception
  # we have rescued all possible exceptions
ensure
  return thing
end

Line 3 is a code smell. Rescuing all exceptions is not desirable. From our exploration of ensure we can see that this code is the equivalent of the original code [no rescue clause, just the explicit return].

Can we refactor it? Yes. Yes we can.

def some_method
  begin
    thing.method_that_might_raise!
  rescue SomeAppException => e
    # do something clever here
  end
  thing
end

And when we cannot recover from SomeAppException, we just let the exception propagate up the call stack:

def some_method
  thing.method_that_might_raise!
  thing
end

These refactors seem like the proper way to handle these situations. If cleaning up after thing could raise an error, it should be put in it's own begin...end block, rather than getting tucked into an ensure.

My gut feeling is with @bcardiff: we shouldn't return, neither implicitely or explicitely from ensure blocks.

I agree with @bcardiff and @ysbaddaden. We shouldn't use return inside ensure, also not use break and next. (break and next have same problem, do you know?)
In the last 2 days I surveyed ensure (or finally) semantics of some language. Conclusion:

Most languages (Ruby, Python, Java, JavaScript and more) allow to use return, break and next (or continue) inside ensure. However lint tools like rubocop and eslint have a rule to detect it, and this rule is turned on by default in many case.
Scala allow it, but the compiler make a warning when finally block has no side effect like: try { 1 } finally { 2 }.
C# disallow to use it.

I think most language implement return inside ensure conventionally (without considering, no reason, idolatrously), however it has no use case in fact. If we allow it, but later a lint tool disallow it anyhow. Thus, I think that.
Remaining problem of exception handling is that raising an exception from inside ensure, but it is independent from this issue (I may open a new issue for it). Thank you.

I run Java programe, found Java has implemeted return inside finally, then ,I am writing similar codes in Crystal at onece, Crystal throw some bugs. I think, most languages has implemented that has benefit, golang has defer implement as this function

Go expresses an error as returning value. In many cases, Go's modifying returning value inside defer is used to fix up returning value. It seems like re-raising a wrapped exception from rescue in Crystal. I think it is wrong manner to modify returning value not to mean an error in Go.

In Go return values are the only way to propagate errors. In Crystal we have exceptions, but there are still valid reasons to use errors as return values. With tuples and unpacking this can be done much like the way Go does. While I usually prefer exceptions, I still find it quite nice that Crystal allows both.
That is, even if your application uses return values, you'd still have to handle exceptions from stdlib.
The more I think about it, I find it more apealing to follow the reasoning that return values from ensure blocks are not really useful. All discussed use cases can be written without it and while that might mean a bit more characters, it's probably helpful to understand the code if ensure blocks are limited to the minimum that needs to be ensured. Return values don't need to be ensured to run, they are only valid if there has been no exception before.
@lgphp Java and Go and even Ruby are different languages from Crystal, you can't assume that similar concepts have exactly the same mechanics in different languages.

Is there any progress?

Why is this opened still? I think it is fixed by #4486.


ci: add auto labeling for PRs

This PR

adds the actions/labeler to this repo so that PRs get labeled depending on the content that they update

Fixes #927

labels are already created


Add copy button to code blocks

It would be nice to have a button to copy the entire content of code blocks, like the one supported in GitHub markdown:
pip install dvclive

the biggest question I had thinking about this - should be copy outputs as well:
$ dvc plots show
Plots file is ....

# Now run ...
$ dvc plots diff
Some output

what should we copy in this case?

what should we copy in this case?

We could leave this decision up to the writer, which can decide whether to split code and output into 2 separated blocks?

Would need to be applicable to some CLI blocks specifically indeed. Doesn't sound like an easy implementation. Triple mouse click does the trick too but I'm not sure how many people are aware.


Kafka consumer group fails to read data from one/more partitions

We are using 3 kafka consumers with same group id to read data.
Kafka topic with Replication factor:5, Partition: 5
Initially all works fine, but after some time (say after 1 week), consumer group fails to read data from one or more partitions. We don't see any error being logged.
We use kafka version = <IP_ADDRESS>
Any help here will be much appreciated.

@dineshkumars1985,
Is this a 'crouton' issue?
-DennisLfromGA


If possible, allow user to choose where to install DART

Some users at large organizations cannot install software on their own machines. However, they may be able to install to external drives. If DART remains a single binary executable, we should allow the user to install it wherever they please. This assumes we'll be building a signed or unsigned installation package.

+100
On Thu 4 Jan 2024 at 21:48, A. Diamond @.***> wrote:

Some users at large organizations cannot install software on their own
machines. However, they may be able to install to external drives. If DART
remains a single binary executable, we should allow the user to install it
wherever they please. This assumes we'll be building a signed or unsigned
installation package.
—
Reply to this email directly, view it on GitHub
https://github.com/APTrust/dart-runner/issues/11, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAITFPRIYT2OGAQPSMTFVEDYM4PTZAVCNFSM6AAAAABBNRZN5KVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3DMMZYGE3DIOI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


SageMaker DeepAR drop-in replacement

I think it would be good if customers could just use GluonTS based models on existing data they’ve created for the use with DeepAR.
Although both products are similar, there differences that make this currently not possible. Out of my head these are things we would need to implement:

[ ] Metrics
[ ] input data format (field names)
[ ] parquet support
[ ] hyper parameters

I think we can neglect hyper-parameters. Even if they are different, it should be easy to change for them for the job (In contrast for say the input-data).
Parquet support might not be needed (although it would be generally desirable). We support jsonlines, which should be good enough for now.
Metrics is something which would need some attention, but I think it's ok to have different formats.
Input data format should be adressed by #384.

Agreed, this is much more realistic once #384 is done


emgithub#28 serviceProvider value is wrong if served from a subdirectory

There may be other/better ways to go about this, but this one is working for me, and this is the branch I'll be deploying for my gh pages for the time being. But I wanted to contribute this back if it's helpful.
Fixes #28

Thanks for your work! I use custom domain instead of github.io so I missed the issue.
As for your solution, i.e., removing the last part of / splitting,  it should work well, since:

the sourceURL.href is in the format of {correct service provider}/embed(-v\d+)?\.js\?.+, which is ensured by https://github.com/yusanshi/emgithub/blob/master/404.html#L584-L585 and https://github.com/yusanshi/emgithub/blob/master/404.html#L461.
the / in query parameters after ? is encoded so the query parameters will not contain /.

Although there may exist other solutions, e.g., regex, I think this simple and effective solution is enough. However, I would prefer to also add the ending slash: sourceURL.href.split('/').slice(0,-1).join('/') + '/', which can also be easily done by new URL("./", sourceURL.href).href (as in https://github.com/yusanshi/emgithub/commit/58d29449b17182f03381634e82d58f8a625c0aaf, you haven't select Allow edits from maintainers so I made the change in other place). I have tested it in https://emgithub.yusanshi.com/ and https://emgithub.yusanshi.com/subdirectory/. You can check it and if that's OK you can either update the PR or allow edits from me.

I created the fork in an org, which github doesn't allow maintainer edits on PRs opened from an org fork so I can't enable maintainer edits.
I think your solution is much more elegant. I was looking at the URL() documentation, but it wasn't evident to me that that would be the behavior. At any rate, this way is much more you than me, so I don't need to claim credit via the commit. Referencing the issue via the commit is enough for me :-)
Either way, I'm happy that it works now.


Add support for Slather's JSON option

Feature Request
Motivation Behind Feature
Slather has support for a barebones JSON report option. Fastlane's Slather action should be updated so this option can be used so others who find this basic reporting option useful can use it.
Feature Description
This feature should add an option to Slather Action that allows to use the --json option of Slather command.
This wouldn't break anything for existing users, just adding a functionality.
Alternatives or Workarounds
The alternative is using the command line to call Slather with --json instead of using the Fastlane action.

Closing this issue as https://github.com/fastlane/fastlane/pull/16703 was already merged and released 🚀

Closing this issue as https://github.com/fastlane/fastlane/pull/16703 was already merged and released 🚀


bug fixed

intro ke color ko change nhi karo

Nhi kiye hai
On Mon, Aug 5, 2024, 9:52 AM Anand Mohan @.***> wrote:

intro ke color ko change nhi karo
—
Reply to this email directly, view it on GitHub
https://github.com/andmhn/climate-awareness/pull/16#issuecomment-2268144277,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BHRPUMWZU64VKV26HDKV2EDZP34ZLAVCNFSM6AAAAABL7PYG6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRYGE2DIMRXG4
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

#welcome id ka color white accha hoga

aur box ka corner round kar do

Kon sa box
On Mon, Aug 5, 2024, 10:00 AM Anand Mohan @.***> wrote:

aur box ka corner round kar do
—
Reply to this email directly, view it on GitHub
https://github.com/andmhn/climate-awareness/pull/16#issuecomment-2268150298,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BHRPUMXJR4E2262ADFW33R3ZP35VRAVCNFSM6AAAAABL7PYG6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRYGE2TAMRZHA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

#welcome wala
On Mon, Aug 5, 2024, 10:05 AM Praween Soni @.***> wrote:

Kon sa box
On Mon, Aug 5, 2024, 10:00 AM Anand Mohan @.***>
wrote:

aur box ka corner round kar do
—
Reply to this email directly, view it on GitHub
https://github.com/andmhn/climate-awareness/pull/16#issuecomment-2268150298,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BHRPUMXJR4E2262ADFW33R3ZP35VRAVCNFSM6AAAAABL7PYG6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRYGE2TAMRZHA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

ha

#welcome{
font-size: 50px;
color: #C3FA95;
box-shadow: 0px 0px 30px rgba(227, 228, 237, 0.37);
backdrop-filter: blur(10px);
border: 1.5px solid rgba(255, 255, 255, 0.18);
border-radius: 5px;
margin: 5px 30px;
font-size:60px;
padding: 15px;
font-family: Georgia, 'Times New Roman', Times, serif;
}

Round to kiye hai 5px dekho
On Mon, Aug 5, 2024, 10:07 AM Anand Mohan @.***> wrote:

#welcome{
font-size: 50px;
color: #C3FA95;
box-shadow: 0px 0px 30px rgba(227, 228, 237, 0.37);
backdrop-filter: blur(10px);
border: 1.5px solid rgba(255, 255, 255, 0.18);
border-radius: 5px;
margin: 5px 30px;
font-size:60px;
padding: 15px;
font-family: Georgia, 'Times New Roman', Times, serif;
}
—
Reply to this email directly, view it on GitHub
https://github.com/andmhn/climate-awareness/pull/16#issuecomment-2268156835,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BHRPUMXCFFKZH6P6VLYKI3DZP36SNAVCNFSM6AAAAABL7PYG6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRYGE2TMOBTGU
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


Thumbnail click point of reference breaks after zoom.

Bug report
Expected behaviour
Click should be related to the center or a corner of the thumbnail view box.
Actual behaviour
Click loses reference to the thumbnail view box
Steps to reproduce the behaviour

Open the thumbnail demo https://bumbu.me/svg-pan-zoom/demo/thumbnailViewer.html
Click somewhere on the thumbnail, the view box will snap its center to the mouse position (kinda, it already breaks towards the upper left corner)
Zoom in for more clarity, example:

Clicking anywhere on the thumbnail shows that the mouse is not aligned to the view box anymore, it snaps to other places.

Gif version of these steps:

Configuration

svg-pan-zoom version: demo
Browser(s): chrome
Operating system(s): win10
A relevant example URL: https://bumbu.me/svg-pan-zoom/demo/thumbnailViewer.html

I need the feature as well, can someone solve the issue?


Excluded folders are being scanned

Version: 2.8-SNAPSHOT - NIGHTLY
Build: 2016-05-10 23:10
OS: Linux 4.5.3-300.xps.x86_64
JDK: 1.8.0_91 amd64 Oracle Corporation
What is the actual behaviour?
A folder I have specified to be excluded from scans in the TV Shows settings is getting scanned.
What is the expected behaviour?
The folder should not be scanned.
Steps to reproduce:
Just update the media sources and it appears.
Delete listing, re-scan and it appears again.
Additional
tmm_logs.zip

should be fixed in the build tomorrow

I tried this just now, and the problem is partially fixed.
The items in the excluded folder are no longer scanned, but an entry for the excluded folder itself is still added to the list, showing 0 seasons - 0 episodes.

you are right - I've done a typo in the fix. The newest build should work

Just updated and it looks to be working as expected now, thank you for fixing!


combine MountF and MountConfig

data MountF f
  = View (f FilePath)
  | ..

data MountConfig
  = ViewConfig View.Config
  | ..

This ^ could be combined into:
data MountF f g
  = View (f FilePath)  (g View.Config)

then:
type MountConfig = MountF (Const Unit) Identity
type Mount = MountF Identity (Const Unit)
type MountType = MountF (Const Unit) (Const Unit)

This way CreateMount AbsPath MountConfig will change to CreateMount (MountF Identity Identity)

What's the benefit of more and more indirection?

This change would ensure that the path you use to create a mount is appropriate for the type of mount: currently you can try to mount a view on a directory path, a connection on a file path, etc.
Well, a change along these lines, I'm not sure on the specific implementation, but I mentioned about using the types to do this to Irakli which is why he commented on it again just now.

We would be able to express all this types with just one MountF:
type CreateMountConfig = MountF Identity Identity
type MountConfig = MountF (Const Unit) Identity
type Mount = MountF Identity (Const Unit)
type MountType = MountF (Const Unit) (Const Unit)

Related change https://github.com/slamdata/purescript-quasar/pull/104
We could change Resource to ResourceF (like for MountF) and have deleteResource and moveResource instead of moveData, MoveMount, etc.


Add coverage to CI?

The scikit-bio repo once had coverage as part of CI, and the coverage % is reported in a badge, powered by the code analysis service coveralls. However, the badge is not working any more. I would suggest that we update this. Meanwhile, I would suggest that we consider switching from coveralls to codecov. Many other open-source projects use this service. Some examples are scikit-learn, conda, matplotlib, and statsmodels. Currently, scikit-bio has an overall coverage of 99%, which is higher than many big names. This is something we can pride on and maintain. What do you think? @wasade @mortonjt @mataton

@qiyunzhu I like this idea. I can add this to my list of items to work on, if we all want to make this switch.

@mataton I can give it a try to see if there is a quick solution. I had experience with coveralls in the past.

With Matt's help we now have a coverage badge! Powered by Codecov.io. @mortonjt @wasade


TypeError: Error fixing biome minecraft:nether_wastes: i.forEach is not a function

An error occurred while upgrading a data pack.
Data Pack:
FlatWorld+ 1.0.1.zip
Was gonna update my pack to 1.19 but I guess not right now
TypeError: Error fixing biome minecraft:nether_wastes: i.forEach is not a function
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:41136) (src/fixes/1.19/Carver.ts:7:21)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4264) (src/Fix.ts:30:11)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4097) (src/Fix.ts:13:10)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4091) (src/Fix.ts:12:21)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4711) (src/Fix.ts:63:18)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4091) (src/Fix.ts:12:21)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4555) (src/Fix.ts:50:39)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4091) (src/Fix.ts:12:21)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4902) (src/Fix.ts:79:58)
    at (https://misode.github.io/upgrader/assets/index.931b7c1a.js:1:4091) (src/Fix.ts:12:21)

I fixed this specific problem, but while testing your data pack I discovered at least one other issue, working on that now

@u3ux After c2f8a7c17660508405bb23785b85f2d8c9d61780 your pack is able to validate in 1.19. Let me know if there are still problems with it.


Jeweler's Pack (Unique submission, needs rule review)

So this is a very different kind of pack - a Pure Support pack of all unplayable Gems which operate almost identically to Guardian's gem/socket mechanic (now using cardmods instead of Guardians' very jank system).
In testing the pack, Common gems proved a little difficult in the context of PM as they can too easily and reliably escalate other cards.  So, I'm proposing that this pack is 5 Uncommons and 5 Rares given its unique position and structure, an exception to the usual rule.
There is also a consideration that every card in the pack has the HEALING tag, which means this pack is exempted from all in-combat generation that is based on packs.  Booster Brew, Destiny Draw, etc. all have exception cases where they cannot pick the GemsPack due to its unique behaviors.
If these two exceptions are more than we're comfortable with, I'm happy to go back to the drawing board and shelve this pack for now, or implement some alternatives to get it back into the ruleset:
For the common issue, moving some gems to Common and increasing the gold cost to socket (to perhaps 25g) would probably be sufficient to make the commons not pickable simply due to gold availability.  Even if they appear strong, the limitations surrounding them would make them less draftable, though this wouldn't be easily apparent on first use of the pack.
The instant alternative to the second exception would be to make the Gems playable in combat, but I intended to have them be a draft pick that is a dead draw until it is socketed, so there is more inherent risk to picking a lot of them up - it adds a map strategy element to using the pack.

Misclicked when creating this PR, intended to click the arrow next to it to see if it could be saved for later.  But its here now so feel free to review and/or comment.


Human readable UUID logs

This PR is related to https://github.com/elixir-ecto/ecto/pull/3531
It improves logs output for Ecto.UUID values:
before:

after:

Edit: I'm not sure about this implementation because it leaks the adapter details. Feedback appreciated.

Hi @pawurb! Good call on adding a new callback.
Taking another look at the code, I wonder if there is another approach we can take here. When we receive the parameters, are they already all decoded? Because maybe we should just log parameters on their original format so we don't do the work of decoding them to binaries only to encode them again.

Hi @pawurb! Good call on adding a new callback.
Taking another look at the code, I wonder if there is another approach we can take here. When we receive the parameters, are they already all decoded? Because maybe we should just log parameters on their original format so we don't do the work of decoding them to binaries only to encode them again.

Unfortunatelly both entry and params contain only binary format of UUID values.
params
[<<117, 56, 16, 51, 192, 15, 73, 87, 183, 163, 61, 154, 175, 74, 251, 22>>]

entry
%DBConnection.LogEntry{
  call: :prepare_execute,
  connection_time: 9174000,
  decode_time: 4000,
  idle_time:<PHONE_NUMBER>,
  params: [
    <<117, 56, 16, 51, 192, 15, 73, 87, 183, 163, 61, 154, 175, 74, 251, 22>>
  ],
  pool_time: 3201000,
  query: %Postgrex.Query{
    cache: :reference,
    columns: nil,
    name: "ecto_4068",
    param_formats: nil,
    param_oids: nil,
    param_types: nil,
    ref: nil,
    result_formats: nil,
    result_oids: nil,
    result_types: nil,
    statement: "SELECT a0.\"id\", a0.\"identifier_name\", a0.\"state\", a0.\"inserted_at\", a0.\"updated_at\" FROM \"areas\" AS a0 WHERE (a0.\"id\" = $1)",
    types: nil
  },
  result: {:ok,
   %Postgrex.Query{
     cache: :reference,
     columns: ["id", "identifier_name", "state", "inserted_at", "updated_at"],
     name: "ecto_4068",
     param_formats: [:binary],
     param_oids: [2950],
     param_types: [Postgrex.Extensions.UUID],
     ref: #Reference<0.2910467834.535822341.226084>,
     result_formats: [:binary, :binary, :binary, :binary, :binary],
     result_oids: [2950, 1043, 1043, 1114, 1114],
     result_types: [Postgrex.Extensions.UUID, Postgrex.Extensions.Raw,
      Postgrex.Extensions.Raw, Postgrex.Extensions.Timestamp,
      Postgrex.Extensions.Timestamp],
     statement: "SELECT a0.\"id\", a0.\"identifier_name\", a0.\"state\", a0.\"inserted_at\", a0.\"updated_at\" FROM \"areas\" AS a0 WHERE (a0.\"id\" = $1)",
     types: {Postgrex.DefaultTypes, #Reference<0.2910467834.535953412.225919>}
   },
   %Postgrex.Result{
     columns: ["id", "identifier_name", "state", "inserted_at", "updated_at"],
     command: :select,
     connection_id: 94,
     messages: [],
     num_rows: 1,
     rows: [
       [
         <<117, 56, 16, 51, 192, 15, 73, 87, 183, 163, 61, 154, 175, 74, 251,
           22>>,
         "hello",
         "initial",
         ~N[2020-12-28 09:46:54.000000],
         ~N[2020-12-28 09:46:54.000000]
       ]
     ]
   }}
}

I'm also not sure if the change is worth it, but right now logs containing UUID values cannot be e.q. searched using human readable strings.

Unfortunatelly both entry and params contain only binary format of UUID values.
params
[<<117, 56, 16, 51, 192, 15, 73, 87, 183, 163, 61, 154, 175, 74, 251, 22>>]

entry
%DBConnection.LogEntry{
  call: :prepare_execute,
  connection_time: 9174000,
  decode_time: 4000,
  idle_time:<PHONE_NUMBER>,
  params: [
    <<117, 56, 16, 51, 192, 15, 73, 87, 183, 163, 61, 154, 175, 74, 251, 22>>
  ],
  pool_time: 3201000,
  query: %Postgrex.Query{
    cache: :reference,
    columns: nil,
    name: "ecto_4068",
    param_formats: nil,
    param_oids: nil,
    param_types: nil,
    ref: nil,
    result_formats: nil,
    result_oids: nil,
    result_types: nil,
    statement: "SELECT a0.\"id\", a0.\"identifier_name\", a0.\"state\", a0.\"inserted_at\", a0.\"updated_at\" FROM \"areas\" AS a0 WHERE (a0.\"id\" = $1)",
    types: nil
  },
  result: {:ok,
   %Postgrex.Query{
     cache: :reference,
     columns: ["id", "identifier_name", "state", "inserted_at", "updated_at"],
     name: "ecto_4068",
     param_formats: [:binary],
     param_oids: [2950],
     param_types: [Postgrex.Extensions.UUID],
     ref: #Reference<0.2910467834.535822341.226084>,
     result_formats: [:binary, :binary, :binary, :binary, :binary],
     result_oids: [2950, 1043, 1043, 1114, 1114],
     result_types: [Postgrex.Extensions.UUID, Postgrex.Extensions.Raw,
      Postgrex.Extensions.Raw, Postgrex.Extensions.Timestamp,
      Postgrex.Extensions.Timestamp],
     statement: "SELECT a0.\"id\", a0.\"identifier_name\", a0.\"state\", a0.\"inserted_at\", a0.\"updated_at\" FROM \"areas\" AS a0 WHERE (a0.\"id\" = $1)",
     types: {Postgrex.DefaultTypes, #Reference<0.2910467834.535953412.225919>}
   },
   %Postgrex.Result{
     columns: ["id", "identifier_name", "state", "inserted_at", "updated_at"],
     command: :select,
     connection_id: 94,
     messages: [],
     num_rows: 1,
     rows: [
       [
         <<117, 56, 16, 51, 192, 15, 73, 87, 183, 163, 61, 154, 175, 74, 251,
           22>>,
         "hello",
         "initial",
         ~N[2020-12-28 09:46:54.000000],
         ~N[2020-12-28 09:46:54.000000]
       ]
     ]
   }}
}

I'm also not sure if the change is worth it, but right now logs containing UUID values cannot be e.q. searched using human readable strings.

Is there anything that would prevent us from adding another entry in there, something like "pre-dump params"?

Is there anything that would prevent us from adding another entry in there, something like "pre-dump params"?

@michalmuskala you'd like to display predump values for all the data types? I'm afraid that UUID might be the only type where explicitly changing the displayed format makes some practical sense.
What is someone executes query like that?
Repo.all(from a in User, where: a.id == <<73, 220, 56, 179, 80, 74, 72, 7, 171, 234, 218, 31, 59, 95, 194, 249>>)

than the logged values format would be inconsistent.

@michalmuskala you'd like to display predump values for all the data types? I'm afraid that UUID might be the only type where explicitly changing the displayed format makes some practical sense.
What is someone executes query like that?
Repo.all(from a in User, where: a.id == <<73, 220, 56, 179, 80, 74, 72, 7, 171, 234, 218, 31, 59, 95, 194, 249>>)

than the logged values format would be inconsistent.

Maybe it make sense to add optional callback for Ecto.Type.inspect/1 that should return human readable value, then use this callback (if implemented) to render the value. Question is if this type is known in runtime at line that @pawurb changed in PR commit

Maybe it make sense to add optional callback for Ecto.Type.inspect/1 that should return human readable value, then use this callback (if implemented) to render the value. Question is if this type is known in runtime at line that @pawurb changed in PR commit

@mjaric check https://github.com/elixir-ecto/ecto_sql/pull/292#issuecomment-753610443, looks like the Ecto.Type is not available there.

@mjaric check https://github.com/elixir-ecto/ecto_sql/pull/292#issuecomment-753610443, looks like the Ecto.Type is not available there.

I believe for cases like this, the values first pass through cast callback that normalises them, only then they are dumped. So there should be a point where we have access to the value after casting, but without dumping. This means in case of UUIDs the format would be consistent.

I believe for cases like this, the values first pass through cast callback that normalises them, only then they are dumped. So there should be a point where we have access to the value after casting, but without dumping. This means in case of UUIDs the format would be consistent.

@michalmuskala what about other types? Do we want to display all the types in "predump" format or only UUID? If only UUID maybe we could call this one display_params?

@michalmuskala what about other types? Do we want to display all the types in "predump" format or only UUID? If only UUID maybe we could call this one display_params?

I don't really know TBH. I think all built-in types have trivial dump, so it's hard to say

I don't really know TBH. I think all built-in types have trivial dump, so it's hard to say

I've checked the param values flow and it looks like they are not the part of Postgrex.Query or Postgrex.Result, but rather extracted and passed as a separate value from the ecto package. I'm afraid that passing predumped values all the way as additional param could be more complex than the current solution of implementing an optional callback. I'm out of other ideas.

I've checked the param values flow and it looks like they are not the part of Postgrex.Query or Postgrex.Result, but rather extracted and passed as a separate value from the ecto package. I'm afraid that passing predumped values all the way as additional param could be more complex than the current solution of implementing an optional callback. I'm out of other ideas.

Is this going to be an opt in?

Is this going to be an opt in?
I ask because I am implementing the sqlite3 adapter for ecto.

I though that it will be an optional callback so that changes in other adapters will not be necessary.
But it's been quite a while and since there's been no more feedback on whether to move forward with it I think I'll wait a week more and close the PR.


[Bug] Key expired and removed on Linux after rebooting or long-term unused

Describe the bug
Key expired and removed on Linux after rebooting or long-term unused
Information (please complete the following information):
OS: Arch Linux

[x] caution in doc


Confused about content-type (application/json+fhir)

Hi,
Currently the HAPI-FHIR JPA server returns results as content-type "application/json+fhir".
This is also stated here:
https://www.hl7.org/fhir/json.html
https://www.hl7.org/fhir/valueset-content-type.json.html
however this site states "application/fhir+json" which I feel is actually more correct as general JSON parsers like Springs AbstractJackson2HttpMessageConverter are configured to work for "application/*+json".
Although it's not yet a real spec by my knowledge, I do believe more custom JSON based content types like HAL also conform to this pattern.
I'd like to get some info on if any switch to "application/fhir+json" is planned or if "application/json+fhir" is the definitive type.

Hi @Robbert1,
FHIR itself defines the content types we use as they have them spelled out as requirements in the specification.
One of the changes in the current STU3 ballot is that they've shifted from using application/json+fhir to using application/fhir+json (and same change for XML).
This change is reflected in HAPI's 2.0 release, but only in STU3 mode (i.e. DSTU3 contexts). You can see the updated content types in the request and response headers here for example: http://fhirtest.uhn.ca/conformance?serverId=home_21&pretty=true

...although I notice that the types are actually wrong in the conformance statement itself. Argh!
I'll keep this bug open to track that. :)

I'm actually using HAPI 2.0 with STU3. (my server response contains  X-Powered-By=[HAPI FHIR 2.0 REST Server (FHIR Server; FHIR 1.6.0/DSTU3)])

Is the client you're using sending the correct Accept header? In order to avoid breaking existing clients, HAPI tries to negotiate and will pick "the old or the new" depending on what the request looks like.

E.g. the following is required to get the new content type from our public server:
$ curl -H "Accept: application/fhir+json" --head "http://fhirtest.uhn.ca/baseDstu3/metadata"
HTTP/1.1 405 Method Not Allowed
Date: Tue, 13 Sep 2016 14:18:47 GMT
Server: Apache-Coyote/1.1
X-Powered-By: HAPI FHIR 2.1-SNAPSHOT REST Server (FHIR Server; FHIR 1.6.0/DSTU3)
Allow: GET
Content-Type: application/fhir+json;charset=UTF-8
Transfer-Encoding: chunked
Connection: close

The accept header is working like a charm thanks!

Closing this issue as it seems to be all good. :)


rootMargin can easily fail in the real-world use cases

Recently I'm trying to use the IntersectionObserver API to lazy load images/contents instead of the old LazyLoad plugin in our website (taobao.com), and I failed, twice, all because the rootMarin option didn't work in some cases. I made two demos to illustrate the problem:

http://a1.alicdn.com/oss/uploads/2016/09/10/98e653c0-771c-11e6-8e09-4d01d5ca328a.html
screencast: http://ossgw.alicdn.com/creatives-assets/oss/uploads/2016/09/10/94150ab0-771e-11e6-8856-b9afe8cc46f0.mp4

http://a1.alicdn.com/oss/uploads/2016/09/10/a11fbb20-7727-11e6-9b63-cf4449eeaa69.html

So I think the spec should change, but I don't know how.

This is a good test case. I think this might be a v2 feature. The current behavior optimizes for not lazy loading things that are clipped. Also, the current behavior is what you'd want if building an infinite scroller.
So, for v2, we could add something like "clipMargin" that expands all clip regions.


[TW#24914] First stage bootloader resets many times

Environment

Development Kit:      [none]
Core (if using chip or module): [ESP-WROOM32]
IDF version (git rev-parse --short HEAD to get the commit id.):
561884b6
Development Env:		[Make]
Operating System:		[Linux]
Power Supply:         [USB]

Problem Description
First stage bootloader keeps restarting many times until finally loads application.
This is the first time I noticed it and it is very hard to reproduce again (so providing source code does not probably help much).
I have disabled both interrupt and task watchdogs so I can setup them manually.
I setup TIMG0 watchdog like this
periph_module_enable(PERIPH_TIMG0_MODULE);
TIMERG0.wdt_wprotect=0x50d83aa1;
TIMERG0.wdt_config0.sys_reset_length=7;
TIMERG0.wdt_config0.cpu_reset_length=7;
TIMERG0.wdt_config0.level_int_en=0;
TIMERG0.wdt_config0.edge_int_en=0;
TIMERG0.wdt_config0.stg0=2;
TIMERG0.wdt_config0.stg1=0;
TIMERG0.wdt_config0.stg2=0;
TIMERG0.wdt_config0.stg3=0;
TIMERG0.wdt_config1.clk_prescale=80;
TIMERG0.wdt_config2=1000;
TIMERG0.wdt_config0.en=1;
TIMERG0.wdt_feed=1;
TIMERG0.wdt_wprotect=0;

and TIMG1 watchdog
periph_module_enable(PERIPH_TIMG1_MODULE);
TIMERG1.wdt_wprotect=0x50d83aa1;
TIMERG1.wdt_config0.sys_reset_length=7;
TIMERG1.wdt_config0.cpu_reset_length=7;
TIMERG1.wdt_config0.level_int_en=0;
TIMERG1.wdt_config0.edge_int_en=0;
TIMERG1.wdt_config0.stg0=3;
TIMERG1.wdt_config0.stg1=0;
TIMERG1.wdt_config0.stg2=0;
TIMERG1.wdt_config0.stg3=0;
TIMERG1.wdt_config1.clk_prescale=40000;
TIMERG1.wdt_config2=2000;
TIMERG1.wdt_config0.en=1;
TIMERG1.wdt_feed=1;
TIMERG1.wdt_wprotect=0;

From monitor log I conclude that TIMG0 has reset PRO CPU and that caused bootloader to reload app. This is OK but I don't think that ets Jun  8 2016ets Jun  8 2016ets Jun  8 201ets Jun  8 2016... messages are expected behavior.
I guess that I have been writing into flash using esp_partition_write when watchdog reset occured and it took a long time to bootloader to recover from this.
Is it possible?
Debug Logs
https://pastebin.com/kHBR4m9v
Other items if possible

[x] sdkconfig file (attach the sdkconfig file from your project folder)
[ ] elf file in the build folder (note this may contain all the code details and symbols of your project.)
[ ] coredump (This provides stacks of tasks.)

sdkconfig.txt
partitions.txt

Hi @michprev ,
Thanks for being patient while someone got back to you about this.
In this case, the ESP32 hardware is behaving as designed and documented (albeit configured in a non-useful way).
Timer group 0 WDT is configured with a Stage 0 timeout of 1ms period (12.5ns * 80 * 1000) to trigger a CPU reset (WDT_STG0 == 2).
Timer group 1 WDT is configured with a Stage 0 timeout of 1 second (12.5ns * 40000 * 2000) to trigger a full system reset (WDT_STG0 == 3).
(Details for these register values can be found in the ESP32 TRM "Timer Group" chapter.)
As described in the ESP32 TRM chapter 19 "Watchdog Timer" section <IP_ADDRESS> "Operating Procedure", the watchdogs will run through all configured stages and then loop back to the beginning.
As described in the ESP32 TRM Chapter 3 "Reset and Clock", a CPU reset doesn't reset all peripherals only the CPU.
So, 1ms after TG0 WDT is enabled, the CPU is reset by TG0 WDT which then loops back to the beginning. The CPU has just enough time to print "ets Jun  8 2016" (the first bytes printed by the mask ROM after a CPU reset) when TG0 WDT resets the CPU again.
This sequence repeats continuously until TG1 WDT expires after 1s, which triggers a full system reset. This also resets the WDT peripheral itself, so the system is able to restart normally.
Solutions to this situation are:

Use a system reset for TG0 WDT instead of a CPU reset
Set a longer timeout for TG0 WDT
Set at least one additional stage for TG0 WDT with a longer period, so the CPU has some time to start up again and reconfigure itself before the WDT state loops around.


All buttons should work whenever the user presses them, chatbot node.js

Bot Info

SDK Platform:
SDK Version:
Active Channels: <MS Teams,etc. -->
Deployment Environment: < local development with Emulator? -->

Issue Description
Whenever I click the button it is not returning to the same menu options, it is throwing the error as Error: Dialog[end] already exists in library[*].
Code Example
    let card = new builder.HeroCard(session)
		.title('Bot for Global service Desk')
		.text('Select any option')
		.buttons([
		builder.CardAction.dialogAction(session, 'Desktop', 'Desktop Support', 'Desktop Support'),
		builder.CardAction.dialogAction(session, 'Application', 'Application Support', 'Application Support'),
		builder.CardAction.dialogAction(session, 'Network ', 'Network Support', 'Network Support'),
	]);
    let message = new builder.Message(session)
       .addAttachment(card);
    session.send(message);

bot.dialog('Desktop Support', (session) => {
session.endConversation(The Desktop Dialog)
}).triggerAction( { matches: /desktop/ } );
bot.dialog('Application Support', (session) => {
session.endConversation(The Application Dialog)
}).triggerAction( { matches: /application/ } );
bot.dialog('Network Support', (session) => {
session.endConversation(The Network Dialog)
}).triggerAction ( { matches: /network/ } );
bot.beginDialogAction('Desktop', 'Desktop Support',{
onSelectAction: (session, args, next) => {
session.clearDialogStack();
next();
}
bot.beginDialogAction('Application', 'Application Support',{
{
onSelectAction: (session, args, next) => {
session.clearDialogStack();
next();
}
bot.beginDialogAction('Network', 'Network Support',{
onSelectAction: (session, args, next) => {
session.clearDialogStack();
next();
}
});
Reproduction Steps

Expected Behavior
All buttons should work whenever the user presses them, even if they scroll back in the conversation and press the same button again.
Actual Results
Error: Dialog[end] already exists in library[].
at UniversalBot.Library.dialog (D:\Bot\node_modules\botbuilder\lib\bots\Library.js:384:23)
at getName (D:\Bot\menu_modify.js:130:5)
at Array. (D:\Bot\menu_modify.js:51:9)
at D:\Bot\node_modules\botbuilder\lib\dialogs\WaterfallDialog.js:67:39
at next (D:\Bot\node_modules\botbuilder\lib\dialogs\WaterfallDialog.js:92:21)
at WaterfallDialog.beforeStep (D:\Bot\node_modules\botbuilder\lib\dialogs\WaterfallDialog.js:99:9)
at WaterfallDialog.doStep (D:\Bot\node_modules\botbuilder\lib\dialogs\WaterfallDialog.js:61:14)
at WaterfallDialog.begin (D:\Bot\node_modules\botbuilder\lib\dialogs\WaterfallDialog.js:29:14)
at Session.beginDialog (D:\Bot\node_modules\botbuilder\lib\Session.js:254:16)
at Session.routeToActiveDialog (D:\Bot\node_modules\botbuilder\lib\Session.js:528:22)
ERROR: Dialog[end] already exists in library[].
Session.endConversation()
Session.sendBatch() sending 2 message(s)
Session.sendBatch() sending 2 message(s)
The Bot State API is deprecated.  Please refer to https://aka.ms/I6swrh for details on how to replace with your own storage.

read the error Error: Dialog[end] already exists in library[].
you need have a dialog with the same name

hi @jwiley84 Thanks for your response, my requirement here is I have used ThumbnailCard for creating buttons using node.js and the conversation flow is working fine.
To ensure consistent throughout the usage of the bot, buttons should work whenever the user presses them, even if they scroll back in the conversation and press the same button again.I am completely new to Bot framework, Kindly help me with this.
Below the sample code.
bot.dialog('/', function (session, args) {
if (!session.userData.name)
{
console.log('Start conversation');
getName(session);
}
else if(!session.userData.option)
{
console.log('User selected option');
getOption(session);
}
else {
session.userData = null;
}
session.endDialog();
});
function getName(session) {
name = session.message.text;
session.userData.name = name;
session.send("Hello ,"+userName +"\nI can help you with the following")
const card = new builder.ThumbnailCard(session)
.buttons([
builder.CardAction.imBack(session, 'user Support','user Support'),
builder.CardAction.imBack(session, 'system Support','system Support'),
]);
const message = new builder.Message(session)
.addAttachment(card)
session.send(message);
}
function getOption(session){
option = session.message.text;
session.userData.option = option;
	 if(option == "user Support")
			{
					const card = new builder.ThumbnailCard(session)
					 .text("You have Selected User Support")
					.buttons([
						builder.CardAction.imBack(session, 'login issue', 'login issue'),
                                                   builder.CardAction.imBack(session, 'other issue', 'other issue'),
					]);
				const message = new builder.Message(session)
					.addAttachment(card);
				session.endConversation(message);
			}
			else if(option == "system Support"){
					  const card = new builder.ThumbnailCard(session)
					 .text("You have Selected "+option)
					.buttons([
						builder.CardAction.imBack(session, 'Clean Profile', 'Clean Profile'),
						builder.CardAction.imBack(session, 'Clean PST', 'Clean PST'),
						builder.CardAction.imBack(session, 'Clean Reminders', 'Clean),
				const message = new builder.Message(session)
				.addAttachment(card);
				session.endConversation(message);
						}

}

I was able to reproduce the error you were having by using your code. The problem seemed to be that you had your cards tucked into functions, and once the getName function was completed, the card was now essentially out of scope of the dialog. It was looking for one of the options given in the getOptions function, and by clicking on the earlier buttons, you were trying to pass an option from getName.
By removing the functions, and making them anonymous functions instead, it returned the ability to click repeatedly on the buttons as needed.
Here is a rough version of what I was able to get to work as you expected:
`bot.dialog('/', function (session, args) {
if (!session.userData.name) {
userName = session.message.text;
session.userData.name = userName;
}
session.send("Hello, " + userName + "\nI can help you with the following")
const card = new builder.ThumbnailCard(session)
.buttons([
builder.CardAction.dialogAction(session, '1', 'user support', 'User Support'),
builder.CardAction.dialogAction(session, '2','system support', 'System Support'),
]);
const message = new builder.Message(session)
.addAttachment(card)
session.send(message);
});
//bot dialogs actions
bot.beginDialogAction('1', 'user support', {
onSelectAction: (session, args, next) => {
const card = new builder.ThumbnailCard(session)
.text("You have selected User Support")
.buttons([
builder.CardAction.imBack(session, 'login issue', 'login issue'),
builder.CardAction.imBack(session, 'other issue', 'other issue'),
]);
const message = new builder.Message(session)
.addAttachment(card);
session.send(message);
}
});
bot.beginDialogAction('2', 'system support', {
onSelectAction: (session, args, next) => {
const card = new builder.ThumbnailCard(session)
.text("You have selected User Support")
.buttons([
builder.CardAction.imBack(session, 'Clean Profile', 'Clean Profile'),
builder.CardAction.imBack(session, 'Clean PST', 'Clean PST'),
builder.CardAction.imBack(session, 'Clean Reminders', 'Clean'),
]);
const message = new builder.Message(session)
.addAttachment(card);
session.send(message);
}
});`
And here is the screenshot:

@jwiley84 Appreciate your response, will modify my code accordingly and keep you posted with the status. Thank you.

@jwiley84 Good Morning Jesicca.. Could you please help me with the above issue.


Improve Check 074 fail message

>> com.google.fonts/test/074 with ((u'font[5]', '/Users/marc/Documents/googlefonts/fonts/ofl/sourceserifpro/SourceSerifPro-SemiBold.ttf'),)
   Are there non-ASCII characters in ASCII-only NAME table entries ?
 * FAIL: There are 2 strings containing non-ASCII characters in the ASCII-only NAME table entries.

   Result: FAIL

This is not a helpful fail message. There are 2 strings, great - but what are the strings? what are the non-ascii characters?
Also, I thought we agreed a long time ago that our "is this thing OK in the font file?" methods are named "checks" and our "is this code giving the expected results" methods are named "tests". Is that true? If so, then com.google.fonts/test/074 is named wrong.

I really question this test
What's wrong with including non ASCII characters in every name record apart from the Postscript name record and a few others which the MS spec mentions?
https://www.microsoft.com/typography/otspec/name.htm#langIDs_platID1
Here's the test
def com_google_fonts_test_074(ttFont):
  """Are there non-ASCII characters in ASCII-only NAME table entries ?"""
  bad_entries = []
  for name in ttFont["name"].names:
    # Items with NameID > 18 are expressly for localising
    # the ASCII-only IDs into Hindi / Arabic / etc.
    if name.nameID >= 0 and name.nameID <= 18:
      string = name.string.decode(name.getEncoding())
      try:
        string.encode('ascii')
      except:
        bad_entries.append(name)
  if len(bad_entries) > 0:
    yield FAIL, ("There are {} strings containing"
                 " non-ASCII characters in the ASCII-only"
                 " NAME table entries.").format(len(bad_entries))
  else:
    yield PASS, ("None of the ASCII-only NAME table entries"
                 " contain non-ASCII characteres.")

this checks all records 0-18 so in other words, our nametable cannot have any non ASCII characters.
There's no rational behind this test in the docstring either.
I'm guessing you've flagged this because of the Source Serif pr, https://github.com/google/fonts/pull/605?
The culprit in Source Serif Pro was Frank's full name, Frank Grießhammer

OK. So we have four tasks and one question here.
The question:

Dave seems to also dislike "test" on the test id. UUIDs are supposed to be forever, even though we already considered changing our naming criteria a few times. I don't think we should bother with this now, since at some point we'll make a big chunk of naming changes at once (or maybe we'll never change UUIDs at all). This is not critically important, though. So I don't see why we should worry much about it.

The tasks:

[ ] Actually output the offending strings when the check FAILs.
[ ] Figure out whether we actually can't have non-ASCII chars in any of the name strings, or just a few. And possibly change the check implementation accordingly.
[ ] Add rationale metadata
[ ] rename all of the fontbakery check functions to have the keyword "check"in their function name instead of
"test"

Why not mention the offending nameID record as well?

done :-)

Regarding @davelab6 's question on nomenclature, yes we've been using the terms check and codetest in our chat sessions and on the issue tracker because it seems clearer and easier than my original proposal of tests and self-tests (respectively).
But on the codebase we still use "test" for all our font file testing routines as seen below:

I think that's acceptable as we've never got confused about the meaning of it.

Only remaining task here is to figure out whether we actually can't have non-ASCII chars in any of the name strings, or whether just a few entries have this restriction. And possibly update metadata and implementation accordingly.

Semver takes care of the breaking of uid namespace. Please make the change.
The unidecode output produces lies.
I agree with Marc that requiring ascii everywhere is annoying. I believe
it's required by the OpenType spec for the ps nameID (6), and I believe I
requested it for copyirght nameID (0) because that string should be the
same in cff fonts which also has this requirement in the OpenType spec
On Dec 5, 2017 12:18 PM, "Felipe Corrêa da Silva Sanches" <
<EMAIL_ADDRESS>wrote:

Only remaining task here is to figure out whether we actually can't have
non-ASCII chars in any of the name strings, or whether just a few entries
have this restriction. And possibly update metadata and implementation
accordingly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/googlefonts/fontbakery/issues/1663#issuecomment-349374944,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP9y-pfsnKFuWnGG-Obh8usuDUZYRtCks5s9XrLgaJpZM4Q2eJ3
.

The unidecode output produces lies.

This is better, right?

This is better, right?

Yes, that's a little better, although

[ ] I would prefer hex to decimal, eg ß
[ ] nameID 9 isn't one that is restricted to ASCII, only 0 and 6

nameID 9 on that screenshot is from before a commit where I restricted non-ASCII checks to nameIDs 0 and 6 only, so that is good now. I checked and that font file PASSes the check.

About 2a8060b I dislike it a alot. It will cause me work to make the dashboard stuff compatible again and it ruins git blame. wtf, only for some cosmetic reason.

For a conceptual reason!
And @davelab6 was recurrently asking for it. And I agree that the new terminology makes sense.

But how deep has this to go :-/

Also, you don't do PRs anymore?

I would prefer hex to decimal, eg ß

well... that notation is what python gives us for free with:
string.encode("ascii", errors="xmlcharrefreplace")

Also, you don't do PRs anymore?

I do. All the time :-)
https://github.com/googlefonts/fontbakery/pull/1665

Also, you don't do PRs anymore?

Felipe makes PRs and IMMEDIATELY merges them, eg in this case  https://github.com/googlefonts/fontbakery/pull/1665, which is probably a bad thing.
We should have a .travis.yml that checks if its been 24 hours since the PR was opened and refuses to merge it until then ;)

that notation is what python gives us for free with

Okay, its a minor thing, in a GUI it can be changed and the raw results its good enough

I do. All the time :-)

I see, I was looking for the "merge" commit message in the history.

well... no immediately. I do wait for Travis do run all tests and after it is good I merge (if a bug has been fixed).

I see, I was looking for the "merge" commit message in the history.

I do use github's "rebase & merge" option on the PR UI.

IC

keeps the history cleaner.

well... not immediately

Sure, but still too far for anyone to comment and improve it before it goes in :)

I do use github's "rebase & merge" option on the PR UI.

Yes, I like that :)
Well, mybe we should revert 2a8060b and leave it in an open PR for @graphicore to merge when he is ready with the downstream dashboard changes, so that it can be done together.
Also above, I said,

Semver takes care of the breaking of uid namespace. Please make the change.

Indeed instead of "Please make the change" I should have said "Please prepare to make the change" - since the prior sentence indicates that I had in mind that this change should be made when we go to v1.0.0

@felipesanches If you haven't read www.semver.org it would be good to do so :)

keeps the history cleaner.

But it removes all reference to the PR (and thus the place to discuss issues with it)

yes, I know semver.

But it removes all reference to the PR (and thus the place to discuss issues with it)

Absolutely all my commits include an issue number identification so that the place for discussion is always traceable. The issues themselves also always have references to their related pull requests.

The issues themselves also always have references to their related pull requests.

lol, didn't work for me just now.

Well, mybe we should revert

Keep it! seems like it has not so much impact as thought it would have.

thanks, @graphicore :-)

lol, didn't work for me just now.

Maybe particular to this issue, in that its a bit noisy, but it look OK to me:

seems like it has not so much impact as thought it would have.

OK great :)

thanks, @davelab6
you're good with that decimal xml syntax?

Yep


change name from zancas_tmp to container_mailbox

@pjbreaux
When we reduced the permissions change with the targeted chown, we failed to permit Kevin's container runner to remove the "mailbox" the containers use to communicate.   This borked the tests at the ansible config step.
The fix is to add a chown directive that permits Kevin's runner to access the "mailbox".
Also the name "mailbox" fixes the known issue, that "zancas_tmp" wasn't a permanent name.

DO NOT MERGE!  CURRENTLY TESTING...

Here's the test of this code:
http://jenkins.pdbld.f5net.com/job/openstack/job/driver/job/mitaka/job/za_test_11.6.1_undercloud_vxlan/19/console


[ENUM-Request] TAB7004 Sales Line Discount.Type

Could the field "Type" have an enum in TAB7004 Sales Line Discount, please?

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


feat: Updating invite modal & app settings for SSO embedding to introduce private app embedding

Description
Updating invite modal and app settings for SSO embedding to introduce upgrade content for private apps. This is being done to introduce private embedding SSO in invite modal and app settings for Business Edition.
Fixes #20578
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Manual
Cypress

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=d53e5b2

/ok-to-test sha=7306008

/ok-to-test sha=17df568


Make progress flag global

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.006%) to 65.681%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

cmd/root.go
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.006%

Covered Lines:
3931

Relevant Lines:
5985

💛  - Coveralls


Generate link for persons with no tax id#3321

https://github.com/edenlabllc/ehealth.api/issues/3321

Coverage remained the same at 89.755% when pulling 8fa7b243c19c592e5d27c0ed19f2ec623a471fd9 on generate_link_for_persons_with_no_tax_id#3321 into 3dc5592b749291add82a2ea26f2bce3080e8ffd4 on develop.


Non-operators are listed under operators

There are operators listed in https://docs.perl6.org/language/operators#postfix_. that claim to be postfix operators, but in fact, the constructs are just syntax and aren't operators at all.
I suspect original writers documented it this way because in most cases it wouldn't matter if it were an operator or just a piece of syntax. However, built-in operators can be referred to as a noun (e.g. &infix:<,>) and used a a Callable. The same isn't the case with syntax.
Briefly scanning the page:

postfix .
postfix .&
postfix .=
postfix .^
postfix .?
postfix .+
postfix .*
postfix ». / postfix >>.

None of those are operators, I suspect there're more cases on that page with similar issue.

What do you suggest? Create a new "dot constructs" page? Off the top of my head, what do they have in common? The .?

Dunno, I call them "methodops" because they're parsed with methodop token in rakudo. But they're not real operators.
I also wouldn't list ». or .& the way they are listed, as it's really a combination of different things and things that can be combined are.

non-hyper / hyper (my @hyper = "", "»", ">>";)
plurality (don't know the proper name; just made this one up) (my @plurality = "", |<? + *>;)
method / method name (my @method-name = "foo", ｢"foo"()｣, ｢&foo｣, ｢$foo｣; the @foo was also speculated and is even parsed in Rakudo, but doesn't work; personally, I'd leave it out from the docs for now)

So you get a ton of combinations:
$ perl6 -e 'my @hyper = "", "»", ">>"; my @plurality = "", |<? + *>; my @method-name = "foo", ｢"foo"()｣, ｢&foo｣, ｢$foo｣; .join.say for @hyper X "." X @plurality X @method-name'
.foo
."foo"()
.&foo
.$foo
.?foo
.?"foo"()
.?&foo
.?$foo
.+foo
.+"foo"()
.+&foo
.+$foo
.*foo
.*"foo"()
.*&foo
.*$foo
».foo
»."foo"()
».&foo
».$foo
».?foo
».?"foo"()
».?&foo
».?$foo
».+foo
».+"foo"()
».+&foo
».+$foo
».*foo
».*"foo"()
».*&foo
».*$foo
>>.foo
>>."foo"()
>>.&foo
>>.$foo
>>.?foo
>>.?"foo"()
>>.?&foo
>>.?$foo
>>.+foo
>>.+"foo"()
>>.+&foo
>>.+$foo
>>.*foo
>>.*"foo"()
>>.*&foo
>>.*$foo

i talked with liz and we agreed the preferable resolvement is to include the ops in some internal hash so they can references as ops and we dont need to document them as something special, but on other hand at least mention it they are special might help someone with future issues

to include the ops in some internal hash

But... they're not ops. There are no Callables behind them that get called or can be referenced.

yes,
but there is an precedence level  asociated with them and I just wanted reference that

You can use an actual op on the same precedence level if all you want is a precedence level.
I don't understand why we have to make such a drastic change to the language and make fake ops for a large chunk of syntax. You can, for example, override other ops. You won't be able to override these. So we're not solving anything with "internal hashes". It's just adding hacks to the compiler and confusion to the user all because someone misdocumented a piece of syntax.
And this is in an area that's already convoluted and doesn't quite work right. You may want to fix that first before adding more stuff to make things even more hacking and convoluted.

I'm just outsider (related to p6 coding) and trusted Liz suggestion. There are no changes I demanded.

On Thu, Aug 16, 2018 at 01:51:07PM +0000, Zoffix Znet wrote:

to include the ops in some internal hash

But... they're not ops. There are no Callables behind them that get called or can be referenced.

I don't know why there's a seeming insistence that something has to have a Callable behind it to be considered an "operator".
These are operators.  They parse like operators.  In fact, the parsing rule used to do it is named "methodop" -- the name itself recognizes that these are "operators" that are implemented as methods instead of infix/postfix/etc. callable subs.
There can certainly be some "operators" in the language that cannot be overridden (except syntatically), or that cannot be easily passed as functions to other operators.  AFAIK there's nothing that says an "operator" can only be those things that translates into Subs.
If there needs to be a name that distinguishes this class of "method operators" from other operators, I humbly suggest they be referred to as "methodops", and as needed they can be noted as syntatic implementations that cannot be overridden via the same mechanisms used for other types of operators.
But the language designers have always referred to things like "postfix ." as "operators", even though they're implemented as syntactic constructs instead of the standard sub-call form of an operator.  That's the natural place they should be documented.
Pm

...indeed, in many classical languages the "operators" have been syntactic constructs identified by the language definition, with no "Callable" behind them available to the programmer.  This use of the term "operator" includes even sibling languages such as Perl 4 and Perl 5.
Pm

It's interesting to read up on these all discussions and I'm more than happy that I could agree with Patrick Michaud and disagree with Zoffix Znet for once. By the same logic, a whole lot of languages would have no right to speak about operators - and also, I wonder if the specs mandate that syntactic operators shan't be implemented as first-class routines. What if somebody manages to invent a super abstract model that can handle method calls as a first-order thing?


refactor: use config crate for service

This PR closes #402
Changes in this PR

Updated imports in indexer_service.rs & service/src/service.rs
Delete config.rs from common/indexer-service & service
Added a fn to get as SocketAddr from MetricsConfig

Hey @gusinacio ,
Thanks for the feedback. I've made necessary changes.
I've also refactored some lines in this commit.
Please let me know your thoughts.


Add configuration for release-bot

to be able to release on PyPi & Fedora (no Bodhi support yet)
I guess we also need to add https://src.fedoraproject.org/user/usercont commit rights to https://src.fedoraproject.org/rpms/conu don't we ?
(you can add jpopelka too BTW)

can do!


Bug try fix wrong _has_null_in_build_side setted (#27684)

try fix wrong _has_null_in_build_side setted
Proposed changes
pick from #27684
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Unsupported Options Argument in aquasec_integration_registry

Hi there,
Terraform Version
Provider versions: v0.8.25
Terraform version:
Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.
Affected Resource(s)
Please list the resources as a list, for example:

aquasec_integration_registry

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.
Terraform Configuration Files

 resource "aquasec_integration_registry" "integration_registry" {
    author                        =<EMAIL_ADDRESS>    auto_cleanup                  = false
    auto_pull                     = true
    auto_pull_interval            = 1
    auto_pull_max                 = 100
    auto_pull_rescan              = false
    auto_pull_time                = "08:00"
    description                   = "Automatically discovered registry"
    image_creation_date_condition = "image_count"
    name                          = "integration_registry"
    pull_image_age                = "0D"
    pull_image_count              = 3
    scanner_type                  = "specific"
    type                          = "AWS"
    options = [
            {
                option = "ARNRole"
                value    = "arn:aws:iam::000000000000:role/aqua-AAAAABBBBCCCDDD-EEEEFFFFGGGG"
            },
            {
                option = "TestImagePull"
            },
            {
                option = "sts:ExternalId"
                value    = "00000e2a-5353-4ddd-bbbb-ccc"
            }
    ]
}

### Debug Output
https://gist.github.com/MorganTAtkins/e93dc4a998796cbe2acdabd6be1a01a0

### Expected Behavior
Options should be supported as per the provided sample.

### Actual Behavior
Options is an  Unsupported argument and errors

### Steps to Reproduce
Using a valid provider and the HCL Above do a validate;
1. `terraform init`
1. `terraform validate`

### References
#220 makes reference to a sample with the option object included but doesn't verify its functionality explicitly.

@semyonmor i can raise an slk for this if it helps.


[BUG]: RuntimeError(f"Parameter model.lm.parameters failed at the gradient reduction. "  "Some unsupported torch function is operated upon this parameter.")

🐛 Describe the bug
strategy:colossal_gemini
print info:
chunk.tensors_info[p].state TensorState.HOLD
TensorState.HOLD_AFTER_BWD,
-->so raise error:
RuntimeError(f"Parameter model.lm.parameters failed at the gradient reduction. "  "Some unsupported torch function is operated upon this parameter.")
but I dont know how to solve it.What's wrong here?
Environment
No response

I also encountered the same error. Did you manage to resolve it later on?

邮件已收到~李巧艳

I also encountered the same error. Did you manage to resolve it later on?

I'm using version 0.3.0 of colossalai. I encountered a RuntimeError: Parameter "tor_bond_conv.batch_norm.bias" failed at the gradient reduction. Some unsupported torch function is operated upon this parameter. error. In the gemini_plugin.py file, I found a comment mentioning that the support for zero in colossalai is currently not optimal, along with the commented line model = nn.SyncBatchNorm.convert_sync_batchnorm(model, None). I suspected that the issue was caused by the Batch Normalization layers in the model. However, even after uncommenting that line, the error still persists and remains unchanged.


[BUG] Can't compile in React Native

Current Behavior
When I try to issue a credential in React Native with ethr-did, I get several errors:

ReferenceError: Can't find variable: TextEncoder
ReferenceError: Can't find variable: atob
Invariant Violation: "main" has not been registered

Expected Behavior
No errors.
Failure Information
Each error presented itself, I solved it and then the next error was shown. See the PR here for the errors and solutions (using polyfills).
Steps to Reproduce
See PR.
Environment Details

Nodejs: 16.4.1
OS Compiler Host Version: Linux Ubuntu 20.0.4
React Native expo compiler: 5.5.1
Device details: Android 11, Samsung A40

Failure Logs/Screenshots
See PR for error details and solutions
https://github.com/Tonomy-Foundation/Tonomy-ID/pull/129/files

Solutions to these three issues can be found in the following PR
https://github.com/Tonomy-Foundation/Tonomy-ID/pull/129/files


Add Xin, Alexa, Sukumar to reviewer

"Fixes #issue-number" or "Add description of the problem this PR solves"
Proposed Changes

Propose Xin to reviewer, previous contributions
https://github.com/kserve/website/pull/169
https://github.com/kserve/website/pull/174
https://github.com/kserve/website/pull/175
Propose Alexa to reviewer, previous contributions
https://github.com/kserve/website/pull/137

/verify-owners

@theofpa Are you good with adding my team to the reviewer list?

/lgtm


ES_JVM_OPTIONS is ignored with Elasticsearch 6

Continued from https://github.com/NixOS/nixpkgs/commit/3230645c5a6572697f23b4a89c43003774adac09#r28103786
I'll try to find out what the fix is and then PR it.
CC @basvandijk

Another insight: This line https://github.com/NixOS/nixpkgs/blob/3230645c5a6572697f23b4a89c43003774adac09/nixos/modules/services/search/elasticsearch.nix#L169-L171 sets ES_PATH_CONF which is still supported, and here https://github.com/elastic/elasticsearch/blob/v6.1.2/distribution/src/main/resources/bin/elasticsearch#L25-L27 the jvm.options under ES_PATH_CONF is added to ES_JVM_OPTIONS, however in parse_jvm_options that path is kicked out again if it doesn't exist, and on NixOS it doesn't exist: on NixOS the contents of that dir are like
# ls -lah /nix/store/l5h2ijhmcfg3rgq53n8879fp7cj15ixz-elasticsearch-config
total 92K
dr-xr-xr-x   3 root root   4.0K Jan  1  1970 .
drwxrwxr-t 559 root nixbld  72K Mar 15 12:00 ..
lrwxrwxrwx   1 root root     79 Jan  1  1970 elasticsearch.yml -> /nix/store/gbrv0mpvmmq16145kpdirbf98dbpsnqj-elasticsearch.yml/elasticsearch.yml
lrwxrwxrwx   1 root root     79 Jan  1  1970 log4j2.properties -> /nix/store/vamxp3gn7nw9xvyb6vzh1fvk1pdrlbfd-log4j2.properties/log4j2.properties
dr-xr-xr-x   2 root root   4.0K Jan  1  1970 scripts

so there's no jvm.options in there. Until now it was placed at a different path
ES_JVM_OPTIONS="/nix/store/7c06x54qs9ms85z86kkzl6dcxwx9i8lb-elasticsearch-6.1.2/config/jvm.options"

where ES_JVM_OPTIONS is the env var newly ignored in ES 6.

@basvandijk another question: In https://github.com/NixOS/nixpkgs/commit/3230645c5a6572697f23b4a89c43003774adac09#diff-2d12e9f116784c475c19d55f07fee064L8

   es5 = builtins.compareVersions (builtins.parseDrvName cfg.package.name).version "5" >= 0;
+  es6 = builtins.compareVersions (builtins.parseDrvName cfg.package.name).version "6" >= 0;

did you intend that for ES 6, both es5 = true and es6 = true? Because that is what happening.
So if in the current configs it says if es5 ..., that also applies to es5.
As a result, it's not clear to me what else branches like this one are for; are they for versions of Elasticsearch < 5?

did you intend that for ES 6, both es5 = true and es6 = true?

Yes I think I did. The variables could better be named something like esGE5 and esGE6 as in Greater or Equal to.

According to https://github.com/NixOS/nixpkgs/pull/36456#issuecomment-379507293, this was fixed in https://github.com/NixOS/nixpkgs/pull/36456/commits/ae94825b4a1aa3c5a8344beb91a139467352f53b.


It hides, but doesn't show.

As the title suggests, it works when I uncheck any of the "Show *" options, but the collisions don't show again when I check the options.

All the icon sprites in the image have collisions that are not being made visible

Hello, thank you for reporting this. Is the layer enabled on the visibility layer? This will only show if the layer on the settings is enabled and the collision is on the same layer.

This might be related to #3, since the error can lead into unexpected behaviour.


enhancemenntoptimize mem usage in join and set node

Proposed changes
In hash join node and set node, the keys maby be serialized multiple times in build and probe phase, which wastes lots of memory, this pr fix it and release memory ASAP.
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[x] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[x] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[x] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[x] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[x] No

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

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.17 seconds
load time: 489 seconds
storage size:<PHONE_NUMBER>8 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221125142006_clickbench_pr_53188.html