Is it possible to intergrate this into QVtkOPenglNativeWidget?

I found this amazing project and wonder how i can intergrate it into my person qt5.9-vtk9.2.5 based project,Could you giving me some instructions for doing so?

Did you try replicating what's done in test_imgui_vtk.cxx?

oh , i have figure it out, thanks for replying.


DRAFT: attempt to resolve issues with blocked well refinement

This request is for changes needed to improve the intersection of simulation trajectories with a refined grid (LGR).

commented out a couple of debug statements in base.py

Codecov Report

Merging #143 (ac73d40) into master (8a1acfa) will decrease coverage by 0.00%.
The diff coverage is n/a.

:exclamation: Current head ac73d40 differs from pull request most recent head 704f500. Consider uploading reports for the commit 704f500 to get more accurate results

@@            Coverage Diff             @@
##           master     #143      +/-   ##
==========================================
- Coverage   41.77%   41.77%   -0.01%
==========================================
  Files          51       51
  Lines       21493    21491       -2
==========================================
- Hits         8979     8977       -2
  Misses      12514    12514

Impacted Files
Coverage Δ

resqpy/olio/base.py
94.94% <ø> (-0.11%)
:arrow_down:

resqpy/model.py
62.61% <0.00%> (ø)

Continue to review full report at Codecov.

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

I'm merging these changes even though the basic issue is not resolved and cannot be without use of original trajectory data.


squid:S1217 - Thread.run() and Runnable.run() should not be called directly

This pull request is focused on resolving occurrence of Sonar rule
squid:S1217 - Thread.run() and Runnable.run() should not be called directly.
You can find more information about the issue here:
https://dev.eclipse.org/sonar/rules/show/squid:S1217
Please let me know if you have any questions.
George Kankava

Hi George, are you sure about this? because in Android all graphical changes have to be executed on main Thread.

No in this case it may affect the graphics. Let me close this pull request.


Fix/flexible cors2

Pull Request
Description
Add env variable for cors address
Fixes #
How Has This Been Tested?
no, but very small change

[ ] Yes

If your changes affect data processing, have you plotted any changes? i.e. have you done a quick sanity check?

[ ] Yes

Checklist:

[x] My code follows OCF's coding style guidelines
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my code and corrected any misspellings

Codecov Report

Merging #60 (ad8629f) into main (8ce913c) will not change coverage.
The diff coverage is 100.00%.

:exclamation: Current head ad8629f differs from pull request most recent head 5dab1ac. Consider uploading reports for the commit 5dab1ac to get more accurate results

@@            Coverage Diff            @@
##              main       #60   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            7         7
  Lines          148       149    +1
=========================================
+ Hits           148       149    +1

Impacted Files
Coverage Δ

src/main.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Change in the Matrix table for VoiceMail Supportability

I've added "Not Supported" to the blank tables in the supportability Matrix, to make it more clear for everyone that Voice Mail with Skype for Business Server 2015 and Lync Server 2013 is not supported if mailbox is homed in Exchange Server 2019.

@CarolynRowe Hi Carolyn, changes look correct. Could you please check and merge? Thanks!


Weapon: multitool

The idea is to have a multitool that can switch modes at the top, by having 8 directional "petals" that can be shown/hidden.

https://user-images.githubusercontent.com/6926057/124647497-095b3400-de64-11eb-9074-0e1cba22221a.mp4

https://www.pinterest.ca/pin/685321268300152650/

This is still ongoing, but it might be worth waiting on the concept for the character that actually uses (created?) the weapon before iterating on the style massively - the rigging aspect is time consuming to redo.
Do we have a pet / creature that the blades could be made from?
I'm also considering basilisk plumes for theming. Correct shape, fits the adventure:

Apparently this character is not actually related to the basilisk (the existence of which is doubtful itself) and this weapon is self created.
However that is worth rewriting if it strengthens themes.
It seems it would be cool for the self creation of the multitool to be a lie — and all of the main weapons are actually basilisk tied.
Here are some suggestions for putting basilisk parts in all of the weapons:
heart of the sword (this has already been suggested)
bones of the scissor
jaw of the scissor
spine of the leash
fang of the leash
crest of the multitool

I don’t think it needs to be too tied to the character. Just the fact that it is a multitool would be a reflection of personality.
I’m down for refactoring the lore to fit the above idea if it works visually.

It seems it would be cool for the self creation of the multitool to be a lie — and all of the main weapons are actually basilisk tied.

This would serve as a good introductory piece for the animal tamer character, presuming the MC meets them in 1-4 order - they could recognize that everyone else has basilisk parts in their weapons, etc
I think leaning in this direction might be a good idea for the weapons.
It gives them all a common theme in the Basilisk, which is the common reasoning for our characters to be together in the first place, but all with their unique flair / personality... like the party itself.
I think it works well for a thematic and narrative standpoint.

The narrative seems to like a more gradual reveal. The trailer has everyone meeting immediately, but without recognizing the significance.
In some variations there is a later event in which other characters (besides MC + 2) acquire their weapons.
I'm not 100% on this though, because it seems to detract from the "normality" of 3 and really doesn't jive with anything 4 cares about.

I would suggest maybe having a color, palette, or shape language that is tied specifically to the Basilisk design, which can then be used in the weapons.
It'll tie them together thematically but won't be as obvious as just literal basilisk bones. It'll also be something that 'clicks' upon the first reveal of the Basilisk to the audience, seeing the similar shapes and colors that are shared between it and the weapons without needing any explanation up-front.
I'm planning on tackling the open weapon designs later this week, so let me know any thoughts on this - otherwise I'll just do a range from literal bones to subtle shape.
Also, if these weapons are needing to be tied to the Lisk for narrative reasons, then we should probably nail down at least a preliminary design for the Lisk first, since the weapons are derivative from that

I think multitool and the leash don't need to be tied to Lisk, but sword and scissors do.
It would be fine if they all evoked it in some way, but I wouldn't let that get in the way of a workable multitool.

What we should do though is follow color coding for the characters. Engineer is red, so weapon should be reddish.


Changing workspaces at BSPWM

When changing workspace in bspwm (Super + Number), the editor adds a number to the open file. I will add that when I am for example on workspace 6 and I click Super + 6, the editor does not capture the number.
Version: v0.1.0
The video has a strange resolution because I have a 21:9 monitor and the video is recorded in 16:9
video

I think this is a duplicate of https://github.com/lapce/lapce/issues/250


Unsigned Int in RV64

Starting new issue with first part of question from Alibaba.
"1. Normally, RV64 treats 32-bit data as signed data. This means that when 32 bits are involved in the arithmetic, MSBs are always sign extended to 64 bits. However, this is a disaster for programs such as coremark that use unsigned int as an array index. The array index needs to be zero extended to 64 bits by slli and srli, and then the base address is added to execute the load operation.
A well-known trick is to change the definition of unsigned int to signed int, which is not explicitly prohibited in earlier versions of coremark. With this trick, the coremark performance of the high-performance RV64 processor can be improved by more than 14%.
However, last month EEMBC updated the coremark requirements to make sure that unsigned data type must be treated as an unsigned number:
eembc/coremark@7663f78
That is, EEMBC believes that 64-bit architecture should provide adequate support for unsigned int types. This is a realistic need in real world.
By adding indexed load and unsigned offset, you can compensate for 14% of coremark performance loss. Thanks to indexed load and store, the total performance improvement can reach more than 20%.
Does RV64's base ISA have a plan to solve this problem?"

The base ISA itself (RV64I ) won't be changed to support this, as this has been frozen for a long time and a change would be disruptive.  Unsigned 32-bit arithmetic support could be proposed as part of an ISA extension.  For systems supporting only base ISA, one approach is to work on compiler analysis to determine where the zero-extension can be elided for array indices.
For the specific Coremark case, using an unsigned int as an array index is poor C coding practice, as size_t is explicitly defined in C standard to be used for this purpose in portable code.   While I agree with argument that a system should run poorly written code well, I've seen int used as array index far more often than unsigned int.  While Coremark is obviously important commercially as an embedded performance benchmark for marketing, I don't believe this particular use of unsigned 32-bit value is common in real-world code.
I don't want to speculate on why EEMBC chose to enforce the unsigned rule as opposed to fixing the source code to follow C standards, or changing the variable to signed int to provide a more representative example of poor coding style.

as size_t is explicitly defined in C standard to be used for this purpose in portable code

Many code actually use int for array indices not size_t, so I speculate that there might be some cases where unsigned int variable is also occasionally used for indexing. But that should be pretty rare.
I think for non-byte arrays this isn't a big issue - we only change the sequence from 'slli' to 'slli, srli', so only 1 extra instruction. For compiler analysis part, I did a quick check with GCC, and it looks like that it cannot yet use range information to elide zero extension.
char test(char* num, unsigned v) {
    if (v>1000)return 0;
    return num[v];
}

will produce
test(char*, unsigned int):
  li a5,1000
  bgtu a1,a5,.L3
  slli a1,a1,32
  srli a1,a1,32
  add a1,a0,a1
  lbu a0,0(a1)
  ret
.L3:
  li a0,0
  ret

where the two shifts can actually be elided.

Register offset store would be the only instruction requiring 3 read ports.
Presumably something like ARMs uxta* (+explicit offset scaling) in B extension could replace that slli,srli,add sequence with a single instruction.

The base ISA itself (RV64I ) won't be changed to support this, as this has been frozen for a long time and a change would be disruptive.  Unsigned 32-bit arithmetic support could be proposed as part of an ISA extension.  For systems supporting only base ISA, one approach is to work on compiler analysis to determine where the zero-extension can be elided for array indices.
For the specific Coremark case, using an unsigned int as an array index is poor C coding practice, as size_t is explicitly defined in C standard to be used for this purpose in portable code.   While I agree with argument that a system should run poorly written code well, I've seen int used as array index far more often than unsigned int.  While Coremark is obviously important commercially as an embedded performance benchmark for marketing, I don't believe this particular use of unsigned 32-bit value is common in real-world code.
I don't want to speculate on why EEMBC chose to enforce the unsigned rule as opposed to fixing the source code to follow C standards, or changing the variable to signed int to provide a more representative example of poor coding style.

Do you mean by eliding zero extension based on the array index boundary check？That's a possible solution but currently no similar optimizations are seen in the compiler.

Register offset store would be the only instruction requiring 3 read ports.
Presumably something like ARMs uxta* (+explicit offset scaling) in B extension could replace that slli,srli,add sequence with a single instruction.

For those who don't want indexed load/store, adding addition of zero extended scaled offset is an effective attempt . We have tried that and saved about 10% of the performance loss.

On Mon, Mar 11, 2019 at 4:12 AM dennisyyz<EMAIL_ADDRESS>wrote:

The base ISA itself (RV64I ) won't be changed to support this, as this has
been frozen for a long time and a change would be disruptive. Unsigned
32-bit arithmetic support could be proposed as part of an ISA extension.
For systems supporting only base ISA, one approach is to work on compiler
analysis to determine where the zero-extension can be elided for array
indices.
For the specific Coremark case, using an unsigned int as an array index is
poor C coding practice, as size_t is explicitly defined in C standard to be
used for this purpose in portable code. While I agree with argument that a
system should run poorly written code well, I've seen int used as array
index far more often than unsigned int. While Coremark is obviously
important commercially as an embedded performance benchmark for marketing,
I don't believe this particular use of unsigned 32-bit value is common in
real-world code.
I don't want to speculate on why EEMBC chose to enforce the unsigned rule
as opposed to fixing the source code to follow C standards, or changing the
variable to signed int to provide a more representative example of poor
coding style.
Do you mean by eliding zero extension based on the array index boundary
check？That's a possible solution but currently no similar optimizations are
seen in the compiler.

Looking at our competition, I see that power64 and sparc64 store unsigned
32-bit values zero-extended in a 64-bit reg, and signed 32-bit values
sign-extended in a 64-bit reg.  So neither requires an extra zero extend
here after the compare.  These targets both have 32-bit and 64-bit compare
instructions though and RISC-V has only 64-bit compares.   Aarch64 has an
addressing mode that can add a sign/zero extended 32-bit value to a 64-bit
value, so no extra instruction here.  x86_64 requires an extra instruction
for the zero extend, but this is just one instruction.  It is really only
MIPS64 and RV64 that pay the penalty here, as both need two shifts for the
zero-extend.
GCC does have a value-range-propagation (VRP) pass, but this is on the high
level IL, where we have a 32-bit value whose range is computed to be
between 0 and 1000, then this value feeds into a zero-extend to 64-bits,
and the fact that we know the value range does not allow us to optimize
away the zero-extend.  It isn't until we lower to the target dependent IL
that we know that the value is stored sign-extended in a 64-bit reg, and we
can optimize away a zero-extension if the sign bit isn't set, but we don't
have the value-range info here; it has already been invalidated by other
optimization passes and thrown away.  Maybe if we used the value range info
to convert the zero-extend to a either-zero-or-sign-extend-is-ok operation,
then when we lower we could see that the extension could be optimized
away.  But I don't think we have a way to represent this in the high level
IL currently, and extending the high level IL would require modifying a lot
of optimization passes to be able to propagate through the new type of
extension to reach the lowering pass.  There may also be other better ways
to fix this.  Anyways, I think this is fixable if someone had enough time
to work on GCC to add the missing optimization.  We just don't have enough
people trying to optimize GCC RISC-V support yet, so it could be a while
before someone looks at this.
Jim

I would like to point out that there are programming languages (such as Rust) where array indices are always unsigned, and the programmer has no choice in the matter. However, in Rust, array indices are also always the same size as a pointer, so they wouldn't usually need to be extended.

If calling convention is a problem, compilers can provide an override and use, say, fastcall convention. Not sure if there's an overall good solution: if a system prefers some sort of integers, it's bad for other integers. But seriously, use of unsigned integers for positive numbers was a mistake. For example, unsigned integer overflow resulted in BlueBorne vulnerability and it can't be detected automatically, because unsigned integer overflow is legal in C, but overflow doesn't make sense for proper numbers like array indexes.

But seriously, use of unsigned integers for positive numbers was a mistake. For example, unsigned integer overflow resulted in BlueBorne vulnerability and it can't be detected automatically, because unsigned integer overflow is legal in C.

signed CVE's are also not uncommon:
https://nvd.nist.gov/vuln/detail/CVE-2018-19788
Having two possible overflows instead of one doesn't seem to increase security.

But seriously, use of unsigned integers for positive numbers was a mistake. For example, unsigned integer overflow resulted in BlueBorne vulnerability and it can't be detected automatically, because unsigned integer overflow is legal in C.

This argument makes little sense to me. Sure, unsigned overflow is legal in C, but signed overflow is undefined behaviour which is even worse. Sure, won't overflow by going below zero, but if you have an index that's less than zero and you access an array with it, you're still in for a very bad time.

Undefined behavior can unconditionally disallowed by tools. You're going to have negative indexes anyway as programs tend to use -1 as sentinel value.

Undefined behavior can unconditionally disallowed by tools.

You can't have a lint for all undefined behaviour in C, as that would require solving the halting problem. Even if that weren't the case, whether or not overflow occurs can be determined by user input that isn't known at compile-time. The only way to statically verify that undefined behaviour doesn't occur is with a different language design, such as what Rust does (and even then sometimes you need to write code in unsafe blocks that the compiler can't statically verify for you).

You're going to have negative indexes anyway as programs tend to use -1 as sentinel value.

That's traditional, yes, but many languages these days are going with option types as the idiomatic way to indicate such things instead.
Also, I would like to point out the great convenience there is in having array indices and pointers have the same range of possible values. It means that there are no artificial limitations on the sizes of things other than the size of the address space itself.

The only way to statically verify that undefined behaviour doesn't occur

You can't even try, because unsigned integer overflow is legal by design and has legitimate uses like bit manipulation. And rust does absolutely nothing there of course.

It means that there are no artificial limitations on the sizes of things other than the size of the address space itself.

It's of little utility if at all. And even if you can come up with a use case, you can trivially address it with software design much like the option type.

If I may: when compiled in debug mode rust panics on unsinged integer overflow.

What you're saying still makes no sense. You're talking about how unsigned overflow being legal is dangerous and can lead to bugs, and therefore most numbers should be stored as signed instead. But signed overflow is undefined behaviour in C, which means that there are even more opportunities for bugs when you use them, as the standard allows pretty much anything to happen.

You can't even try, because unsigned integer overflow is legal by design and has legitimate uses like bit manipulation. And rust does absolutely nothing there of course.

It seems like you interpreted what I said as ensuring that overflow doesn't occur. That's not what I meant. I said undefined behaviour, and that's what I meant. Rust does indeed 100% guarantee that you can not cause undefined behaviour through overflow, and it does that by defining what happens when integers overflow. The legitimate uses that you speak of such as bit fiddling benefit from this, as in C such code often relies on undefined behaviour.


Serialization API

Is your feature request related to a problem? Please describe.
Some Julia types cannot be directly represented in SearchLight. One example is enums. These can however be converted to a DB safe type like ints or strings. However, This would imply that the Julia type needs to be changed to reflect this.
Describe the solution you'd like
A transformation should be applied from Julia to DB and DB to Julia. This can be simply done by writing a function transform_to_db(<:AbstractModel) = identity and transform_from_db(<:AbstractModel) = identity. The user can then overload these functions for their Types if necessary.
Describe alternatives you've considered
Workaround:
Save the julia types as db safe types, and write call functions which transform the type as necessary to get the required type.

Or you could add a column specific transformations too, but I'm not sure how that is implemented

Hallo Dhruva
Because I'm write some code to extent SearchLight for my needs I can imagine what you are trying to accomplish. There are so many different types which haven't a possible datatype in databases that makes it near impossible to implement all besides the possibility to create custom structs.
I've made forks of SearchLight, SearchLightPostgeSQL and SearchLightMySQL where I implemented the possibility to note the fields which will be stored in the database. This leads to the possibility to have intern fields which are not stored in the database. But this is only possible in the branch savingWithoutInterns. Be warned. This is not an official release and under development. I want discuss the implementation with Adrian (owner of SearchLight). If he decides to integrate the work in his repository it will be offical if not I will integrate the branch in my master branch.
In the tests of the SearchLightPostgreSQL.jl you can read the test_models.jl and test_posrgresql.jl. They show, how these things are meant to be.
If you will go further with the official brach a possibility could be to implement another struct with the fields you want, create a  AbstractModel struct with the fields you want store and use the event :before_save the transfer the informations from one one struct to the AbstractModel struct with the logic you want.
Feel free to ask any questions anytime.
Best Frank

But in my way Package maintainers wouldn't need to implement the transformations. There will be absolutely no change in the way things are stored either. All that needs to be done is for the user to overload/specialize a transformation function which the package applies. If the user hasn't implemented this, then it will fall back to the default identity transformation and Multiple Dispatch will handle the rest.
For example, while retrieving from the db, all calls finally lead to this function https://github.com/GenieFramework/SearchLight.jl/blob/d6984180f0bea94dfdde83dc2d4092c88139fa7c/src/SearchLight.jl#L344
Now we just add a line
transformed_row = transform_from_db(_m, row)

And just use transformed_row instead of row everywhere. Further, add a function definition
transform_for_model(model::AbstractModel, df::DataFrame) = df

And everything JustWorks(TM)
When the user wants to transform the df, they specialize to
function transform_for_model(model::MyConcreteModel, df::DataFrame)
    # Some transformations of df
    df[:num] = -df[:num] # not sure if this works, but I'm trying to negate the column
    df
end

Note that I'm sending an object, and not the type, because Julia can specialize on type, not on value, and I don't know if there is anyway to specialize on value.

It would be possible to do so but in my humble opinion this is much to deep in the internals of SearchLight. If somebody use this technic and an error occur hunting this down to the user function would be very difficult. Also I wouldn't mention to deal with Dataframes on the user side of the framework. I would prefer to deal with the objects and this is possible if you look in my fork in the branch I mentioned above.
In the final instance, Adrian should decide how he wants to handle it.
Just my 2 cents.

SearchLight provides the Serializable module especially for this and the default implementation is the JSON serializer. It used to work in the older API (where we were using special _fields) but needs to be reimplemented to work with the new API. I'm thinking something in the line of a Serializable wrapper type plus serialize and deserialize methods. And the users can define custom/additional serializers.

The new Serializable API has been implemented for a while, closing this (API needs to be documented).


Python not seeing the example files, even though they do exist at the expected location

(d4p-py310) mayday@8afbe9b7:~/Coding/Projects/dispel4py/repos/dispel4py> dispel4py hybrid_redis dispel4py.examples.graph_testing.split_merge.py -i 100 -n 10
Failed to load graph from "dispel4py.examples.graph_testing.split_merge.py":
No module "dispel4py.examples.graph_testing.split_merge.py"
No file "dispel4py.examples.graph_testing.split_merge.py"

run dispel4py hybrid_redis dispel4py.examples.graph_testing.split_merge -i 100 -n 10 instead


Fixed validations.py behaviour

Closes #1
Fixes #<issue_number_goes_here>

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

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

@googlebot I signed it!


Tutorial request for hybrid model (word+character)

The implementation done in the paper:
http://aclweb.org/anthology/P/P16/P16-1100.pdf
is a hybrid seq2seq model with advancements where the encoder is fed with inputs based on following two cases:
1.Normal vector representation of a word (Embedding vector) - when the word input is present in the vocabulary
2.Output of another LSTM network - when the word is out of vocabulary and a separate character based LSTM is used to generate an embedding on the fly
Consider the following example sentence:
"The brown fox jumped over the lazy dog"
Assume these are the words present in the vocabulary: The, brown, jumped, over, dog - These words are fed to the seq2seq encoder as such
out of vocabulary(OOV) words are: fox, lazy - These words are passed to a character LSTM and the output of the same is passed to the seq2seq model along with the above words
These both word level and character level encoder needs to be trained end to end simultaneously.
Since the implementation is a bit different from the normal seq2seq can a tutorial or example of such case be added in TensorFlow?

@Raghava14  I am looking for the same. Is there any reference/implementation of this other than the official matlab one?

@Rj7 , Is the  tutorial for hybrid available in TensorFlow NMT? For the model create using TensorFlow NMT is there any way we can change it to Hybrid attention implementation?


fix: removing nic after vm creation fails

Fixes #67
Description
When we issue a VM.Create call, and the vm fails to create (happens frequently at the beginning of karpenter when its trying to find unavailable offerings), we don't delete the Network Interface.
We also do not delete Nic on the InstanceProvider.Delete() call. We should also be attempting to delete nics on the Delete of the Nodeclaim. Since we will get into a scenario where we return ICE errors, then the launch reconciler will delete the nodeclaim. In the case of an ICE Error for TotalRegionalCoresQuota, we will only create the nic for that nodeclaim. Then if we delete that nodeclaim, our provider will only attempt to delete the VM.
This PR adds a new cleanup function p.cleanupAzureResources that we will use to delete all associated azure resources.
How was this change tested?

make az-all, paired with a scale up that hit quota errors.

TODO

Explore async deletion
Does this change impact docs?
[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

Release Note

fix: removing nic after vm creation fails

@rakechill  i did a scale to 750 nodes, and a scale down, and nics were mostly cleaned up. We do see 4 nics that were not and all of them failed due to the same error NicReservedForAnotherVm. I have a doc i am working on for this. Its a bit complex because we need to consider retires, non blocking deletion/creation etc.
So wanted to cut in this pr first.

Did another run, scaled to 300 or so then deleted all the nodes, we are left with one nic that remains due to NicReservedForAnotherVm


Separator in typeahead menu?

I am not sure if we already have a way of displaying a seprator in the typeahead menu using a single data source. I tried multiple combinations, tried searching around for a solution, but cannot get any.
More like in the screenshot below, I have this data from single source as:
['US: channel1', 'US: channel2',  'US: channel3', 'US: channel4', 'US: channel5', 'CA: channel1', 'CA: channel2']

I can update the data source to multi-dimenational array or any other customization, if required for showing a separator. Or, any other way outside the scope of typeaheadjs.
Please help me find one working solution.

I did something as explained here: http://stackoverflow.com/a/39143557/2469928. Not sure, if this is the only way, but it worked for me.
Folks with similar problem can try something similar.


Can edge_index format data derivable？

From now on, we recommend using our discussion forum (https://github.com/rusty1s/pytorch_geometric/discussions) for general questions.
❓ Questions & Help
Thanks for your sharing and you have helped us a lot!
I have a question that when I trying to sample subgraphs with NeighborSampler, the subgraph is represented as the data structure "adjs", and it has edge_index to store the structure information.
My problem is that does "adjs" derivable? If not, does edge_index derivable? I have tried to modify the required_grad attribute but the error said the dtype of edge_index is int instead of float. However, when I tried to change its type from int to float, an error occurs saying that can not set attributes. Does it mean I can't change its type manually?
I will appreciate it if you can give me some advice! Thanks!

Index tensors are not differentiable, as they are not continuous. If you want to differentiate trough graph structures, you have to do that via additional edge features such as edge_weight.


Celo:

I transferred CELO and never received them. Below you can find a copy of my transaction
0xe7c3a7d1d17f21eae3873a0f143d0a8cbb5819650c2a50ce443ba0b1d38a64ab
0xe7c3a7d1d17f21eae3873a0f143d0a8cbb5819650c2a50ce443ba0b1d38a64ab
0xA203bbF51A5bC4a8A82F8e145D01D0333471D411 → 0xd489c5f58D3dFb16569c93AC21EF27b44C173721
Token Transfer
Success
2 days ago (April-17-2021 06:14:22 AM +-4 UTC)
Block Number
6215617
Block Confirmations
39,490
Nonce
5618
TX Fee
0.0000105 CELO
Fee Recipient
None
Gateway Fee
0
Transaction Speed
2.1 seconds

I never received my tokens

I’m having the same issue. Did you ever get it??

Hi. I found a solution and here’s how I got my celo back into my coinbase. Visit https://docs.celo.org/celo-owner-guide/eth-recovery. It’ll tell you how to retrieve it/find urs. Input the recovery code of the wallet that u sent it to, not the one u sent it FROM. That’s how I got mine. Lmk if you have any questions!


CentOS 7: something wrong with flag 'logtostderr' in file '/root/glog/src/logging.cc'

I followed the instructions in https://caffe2.ai/docs/getting-started.html?platform=centos&configuration=cloud to build and install caffe2. However after the build was successful and I set the PYTHONPATH I get:
`python -c 'from caffe2.python import core'
ERROR: something wrong with flag 'logtostderr' in file '/root/glog/src/logging.cc'.  One possibility: file '/root/glog/src/logging.cc' is being linked both statically and dynamically into this executable.`
This is an up-to-date CentOS Linux release 7.3.1611 (Core) with CUDA 8 (which is needed by other applications on this server)
Any hints on where to debug this?

Solved this by
a) removing the file /usr/local/lib/libglog.a which was installed by "make install" in the glob repository and
b) installing the distributions glob-devel files with yum -y install glob-devel
This installed:

Installing : gflags-2.1.1-6.el7.x86_64                                                                              1/3
Installing : glog-0.3.3-8.el7.x86_64                                                                                2/3
Installing : glog-devel-0.3.3-8.el7.x86_64


CVEs against latest helm version related to the Go version in which helm is built

Hello,
There are a number of CVEs that are getting flagged in Twistlock Security scanning reports related to the version the helm binary is built in.
One of them is Critical and others marked as High

CVE
CVSS
Description
Severity
Status
Package Name
Package Version
Link

CVE-2023-24538
9.8
Templates do not properly consider backticks (`) as   Javascript string delimiters, and do not escape them as expected. Backticks   are used, since ES6, for JS template literals. If a template contains a Go   template action within a Javascript template literal, the contents of the   action can be used to terminate the literal, injecting arbitrary Javascript   code into the Go template. As ES6 template literals are rather complex, and   themselves can do string interpolation, the decision was made to simply   disallow Go template actions from being used inside of them (e.g. "var   a = {{.}}"), since there is no obviously safe way to allow this   behavior. This takes the same approach as github.com/google/safehtml. With   fix, Template.Parse returns an Error when it encounters templates like this,   with an ErrorCode of value 12. This ErrorCode is currently unexported, but   will be exported in the release of Go 1.21. Users who rely on the previous   behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the   caveat that backticks will now be escaped. This should be used with caution.
critical
fixed in 1.20.3, 1.19.8
go
1.18.10
https://nvd.nist.gov/vuln/detail/CVE-2023-24538

CVE-2023-24534
7.5
HTTP and MIME header parsing can allocate large amounts of   memory, even when parsing small inputs, potentially leading to a denial of   service. Certain unusual patterns of input data can cause the common function   used to parse HTTP and MIME headers to allocate substantially more memory   than required to hold the parsed headers. An attacker can exploit this   behavior to cause an HTTP server to allocate large amounts of memory from a   small request, potentially leading to memory exhaustion and a denial of service.   With fix, header parsing now correctly allocates only the memory required to   hold parsed headers.
high
fixed in 1.20.3, 1.19.8
go
1.18.10
https://nvd.nist.gov/vuln/detail/CVE-2023-24534

CVE-2022-41725
7.5
A denial of service is possible from excessive resource   consumption in net/http and mime/multipart. Multipart form parsing with   mime/multipart.Reader.ReadForm can consume largely unlimited amounts of   memory and disk files. This also affects form parsing in the net/http package   with the Request methods FormFile, FormValue, ParseMultipartForm, and   PostFormValue. ReadForm takes a maxMemory parameter, and is documented as   storing "up to maxMemory bytes +10MB (reserved for non-file parts) in   memory". File parts which cannot be stored in memory are stored on disk   in temporary files. The unconfigurable 10MB reserved for non-file parts is   excessively large and can potentially open a denial of service vector on its   own. However, ReadForm did not properly account for all memory consumed by a   parsed form, such as map entry overhead, part names, and MIME headers,   permitting a maliciously crafted form to consume well over 10MB. In addition,   ReadForm contained no limit on the number of disk files created, permitting a   relatively small request body to create a large number of disk temporary   files. With fix, ReadForm now properly accounts for various forms of memory   overhead, and should now stay within its documented limit of 10MB + maxMemory   bytes of memory consumption. Users should still be aware that this limit is   high and may still be hazardous. In addition, ReadForm now creates at most on
high
fixed in 1.19.6
go
1.18.10
https://nvd.nist.gov/vuln/detail/CVE-2022-41725

CVE-2022-41723
7.5
A maliciously crafted HTTP/2 stream could cause excessive   CPU consumption in the HPACK decoder, sufficient to cause a denial of service   from a small number of small requests.
high
fixed in 1.19.6
go
1.18.10
https://nvd.nist.gov/vuln/detail/CVE-2022-41723

CVE-2022-41724
7.5
Large handshake records may cause panics in crypto/tls. Both   clients and servers may send large TLS handshake records which cause servers   and clients, respectively, to panic when attempting to construct responses.   This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable   session resumption (by setting Config.ClientSessionCache to a non-nil value),   and TLS 1.3 servers which request client certificates (by setting   Config.ClientAuth >= RequestClientCert).
high
fixed in 1.19.6
go
1.18.10
https://nvd.nist.gov/vuln/detail/CVE-2022-41724

CVE-2023-24537
7.5
Calling any of the Parse functions on Go source code which   contains //line directives with very large line numbers can cause an infinite   loop due to integer overflow.
high
fixed in 1.20.3, 1.19.8
go
1.18.10
https://nvd.nist.gov/vuln/detail/CVE-2023-24537

CVE-2023-24536
7.5
Multipart form parsing can consume large amounts of CPU and   memory when processing form inputs containing very large numbers of parts.   This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the   total memory a parsed multipart form can consume. ReadForm can undercount the   amount of memory consumed, leading it to accept larger inputs than intended.   2. Limiting total memory does not account for increased pressure on the   garbage collector from large numbers of small allocations in forms with many   parts. 3. ReadForm can allocate a large number of short-lived buffers,   further increasing pressure on the garbage collector. The combination of   these factors can permit an attacker to cause an program that parses   multipart forms to consume large amounts of CPU and memory, potentially   resulting in a denial of service. This affects programs that use   mime/multipart.Reader.ReadForm, as well as form parsing in the net/http   package with the Request methods FormFile, FormValue, ParseMultipartForm, and   PostFormValue. With fix, ReadForm now does a better job of estimating the   memory consumption of parsed forms, and performs many fewer short-lived   allocations. In addition, the fixed mime/multipart.Reader imposes the   following limits on the size of parsed forms: 1. Forms parsed with ReadForm   may contain no more than 1000 parts. This limit may be adjusted with the   environment variabl
high
fixed in 1.20.3, 1.19.8
go
1.18.10
https://nvd.nist.gov/vuln/detail/CVE-2023-24536

CVE-2023-24532
5.3
The ScalarMult and ScalarBaseMult methods of the P256 Curve   may return an incorrect result if called with some specific unreduced scalars   (a scalar larger than the order of the curve). This does not impact usages of   crypto/ecdsa or crypto/ecdh.
medium
fixed in 1.20.2, 1.19.7
go
1.18.10
https://nvd.nist.gov/vuln/detail/CVE-2023-24532

CVE-2023-26125
4
Versions of the package github.com/gin-gonic/gin before   1.9.0 are vulnerable to Improper Input Validation by allowing an attacker to   use a specially crafted request via the X-Forwarded-Prefix header,   potentially leading to cache poisoning.\r\rNote: Although this issue does   not pose a significant threat on its own it can serve as an input vector for   other more impactful vulnerabilities. However, successful exploitation may   depend on the server configuration and whether the header is used in the   application logic.
moderate
fixed in 1.9.0
github.com/gin-gonic/gin
v1.8.1
https://nvd.nist.gov/vuln/detail/CVE-2023-26125

I also see another somewhat related issue https://github.com/helm/helm/issues/11807
Is this something in the roadmap and we can hope to see in near future?

If you look in the security tab, you'll see the actual security issues that are tracked. Results from several commercial scanners produce a lot of false positives and are not valuable.
If you're concerned, run govulncheck to see if there are any legitimate concerns.
I'm going to close this as the security tab is the source of truth for this project.


Agg rename refactor

We were creating an unnecessary wrapping when computing aggregation features. Removing that now

Codecov Report

Merging #210 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #210      +/-   ##
==========================================
- Coverage   93.46%   93.45%   -0.01%
==========================================
  Files          71       71
  Lines        7785     7775      -10
==========================================
- Hits         7276     7266      -10
  Misses        509      509

Impacted Files
Coverage Δ

...turetools/primitives/aggregation_primitive_base.py
95.6% <100%> (+0.04%)
:arrow_up:

featuretools/primitives/transform_primitive.py
97.78% <100%> (ø)
:arrow_up:

...turetools/computational_backends/pandas_backend.py
90.93% <100%> (-0.36%)
:arrow_down:

Continue to review full report at Codecov.

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

closing because this will be addressed in #215


bash completion example should not call brew if brew doesn't exist

In the section "Configuring Completions in bash", there's a line of code that sets HOMEBREW_PREFIX by calling brew --prefix, but it's done before calling type brew to see if brew exists.  This gives a "-bash: brew: command not found" if you don't have brew installed. That line should be moved inside the if.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Thanks so much for your first contribution!  You rock, @petdance!


Twilio SDK request

Please provide information about the SDK
Name:
Uses:
Owner:
Links to the SDK:
Please tell us about the platforms for which the SDK exists
[ ] Android
[ ] iOS

Started a support request.

Twilio
Sentry


Tag 1.1 release?

Would it be possible to tag an 1.1 release?
This is because versions before 1.0.4 throw an error with PHP 7.2 because of assert('is_string($url) || is_array($url)'); in ParsedUrl.php. Currently only way of ignoring everything below 1.0.4 would be to manually list all the minor releases.
"neomerx/cors-psr7": "1.0.4|1.0.5|1.0.6|1.0.7|1.0.8|1.0.9|1.0.11|1.0.12|1.0.13",

This not optimal and requires manually updating composer.json on my side always when neomerx/cors-psr7 has a new release.

Hi,
Sorry, but I don't get it. The line you're referring to was removed more than 2 years ago on Mar 18, 2016
.
As far as I understand you're using PHP 7.2 (as I do btw) and keep using very old version which was not tested on PHP 7.2 due to it didn't existed at that time (7.2 was released on Nov 30 2017).
Why just not upgrade to the latest version which was actually tested on 7.2? Have you got any issues with that?

Can you please try the latest version? I expect it should work just fine.

Yes, latest version works ok, that was not the issue. In any case I can do some workaround this.

As far as I understand lowest from 1.0.4|1.0.5|1.0.6|1.0.7|1.0.8|1.0.9|1.0.11|1.0.12|1.0.13 would be 1.0.4 so the whole line can be replaced with 1.0.4 (or any other version you need).
Anyways, if I can help you please don't hesitate to ask.

Read the composer docs again. You are correct ^1.0.4 allows >=1.0.4 <2.0.0. Thanks!


Make Diagnostics->Symbols more prominent in the iOS Symbolication guide

Describe the solution you'd like
The iOS Symbolication guide mentions that you can upload symbols manually by navigating to the Diagnostics->Symbols page, but it would be nice if the other sections mention that you can use that page to verify that you've successfully uploaded symbols.
Describe alternatives you've considered
You could also make the Diagnostics->Symbols page more prominent in the page's navigation. It's currently only visible once you've already clicked on Diagnostics, if you then mouse over Diagnostics again, which makes it less than easily discoverable.
Additional context
I missed the existence of that page when I was first writing a script to upload symbols using the REST API, since I skipped right to that section. It would have been very helpful if that part of the guide advised that I could see the symbols list there. I imagine this may also be a helpful suggestion in the App Center CLI section.
(Dupe of closed issue #2051)

Hi @abbeycode, thank you for opening this issue and giving us your feedback. While redesigning our portal and make this improvement is one thing, we'd love to learn from your experience and start with something small like documentation improvements. If so, could you share more with us what you'd like to see? What do you think?


Get LOOPBACK test working

This test involves sending random bits through the link while recovering them directly from the ADC output.  Prerequisites: StanfordVLSI/dragonphy#58, StanfordVLSI/dragonphy#59, StanfordVLSI/dragonphy#60.

This was fixed in cpu_system_tests/loopback_sram.


Python how to printf Live Metrics? I use is sdk it show Not available: your app is offline or using an older SDK!!!!

I use  python sdk to use Azure monitor ,beside  live monitor others show ok. I click Live metrics model  it show "Not available: your app is offline or using an older SDK" but I use SDK opencensus-ext-azure==1.1.0.  python sdk Can't print this live monitor Info???
Can you give me some help？

@Liubaituo This azure-docs repository deals about feedback related to particular Azure document page (like correcting doc bugs, doc enhancements, product issues related to wrong doc instructions, etc.) so if issue is intended to update / correct / enhance anything in an Azure document then please share Azure document link / URL and share the feedback related to it.
If issue is not intended to Azure document and if it's related to Azure SDK for python then you may ask the question here or here


typescript issue

The command ""C:\Program Files (x86)\Microsoft SDKs\TypeScript\2.0\tsc.exe" -project "C:...\F_Serene\F_Serene.Web\tsconfig.json"" exited with code 3.
i think that code 3 means path issue. The warning has to do with the line that i am declaring the UserPermissionRow. Any ideas how to fix this?

Have you installed TypeScript?

yes

Any Ideas?

Do you know that there is an output window in Visual Studio?

Also check that you have tsc.exe at that location. You probably installed 2.1 not 2.0,

i have installed 1.8 but demo RolePermission are working. Can i define with version is going to be used?
Sorry if i am being irritating

Install 2.0. If you have to use 1.8, then change TypescriptToolsVersion in csproj.


Calculate vascular liver segments based on user input

Implement processing/extraction of vascular liver segments based on user input from widget #115.

[x] Use the logic class from the VMTK module
[x] Create endpoint lists
[x] Calculate centerlines from endpoint lists and create MRML nodes
[x] Create "unique" names for the centerlines, linked to endpoint list. Overwrite previous when recalculating from updated endpoint list
[x] Remove endpoint markdown after creating centerline

First implementation finished, in PR #110


[GOBBLIN-1947] Send workUnitChange event when helix task consistently fail

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[ ] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-1947] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-1947

Description

[ ] Here are some details about my PR, including screenshots (if applicable):
When YarnAutoScalingManager detect helix task consistently fail, give an option to send WorkUnitChangeEvent to let GobblinHelixJobLauncher handle the event and split the work unit during runtime. This can help resolving consistent failing containers issue(like OOM) during runtime instead of relying on replaner to restart the whole pipeline

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:
Updated test cases and tested in cluster

Commits

[ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (dd17bed) 47.53% compared to head (46145fb) 53.55%.
Report is 5 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #3832      +/-   ##
============================================
+ Coverage     47.53%   53.55%   +6.02%
+ Complexity    11035     1399    -9636
============================================
  Files          2156      281    -1875
  Lines         85377    10357   -75020
  Branches       9491     1110    -8381
============================================
- Hits          40581     5547   -35034
+ Misses        41099     4289   -36810
+ Partials       3697      521    -3176

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Name conflict

Hello,
I think there is a name conflict between your and @seanmonstar warp project (https://github.com/seanmonstar/warp) and to avoid confusion one of you should rename. I am not suggesting one or another to follow with the rename but not doing so will cause confusion in future.

renaming would also make it easier to publish on crates.io


Add owner LMS key sign and verify

I think we could merge this in and create new work items and PRs to handle a few new things that need to be added.
Integration Tests:

LMS Revocation Tests
Tests to optionally require LMS

Verifier changes:
-Changes to optionally require LMS.
-Need to increase the bundle of LMS vendor keys from 4 to 32 to match what was agreed to.


Touch/Face ID popup occasionally disappears and app reverts to Password Auth

Reported by Devar from slack (/u/Devar0 o reddit):

"Found another bug. When you unlock the phone and electon cash was the last task (so it goes back to it) it falls back to password entry to unlock wallet, not using f/tID."

So apparently it happens when the app was in foreground and you unlock the phone with it coming up immediately.
It's apparently hard to reproduce, but I have some theories as to what in the codepath is questionable.
I will investigate this.

I think this has been fixed some time ago. Closing.


Replaced Bootstrap Tour with IntroJs for Stopwatch activity

I have migrated the Stopwatch activity tutorial from bootstrap-tour to IntroJs and also fixed the unwanted spacing, which was the issue in the previous PR. I hope you review and merge the same.
Issue: https://github.com/llaske/sugarizer/pull/1159
Issue: https://github.com/llaske/sugarizer/issues/1090

Nice. Thanks @saakxshi


feat: add worker library

Add the worker library according to the challenge requirements and design doc.
Additionally, include the generated stubs from the proto files.
Note that one of the major tradeoffs I've made is that each instance of the io.ReadCloser returned by JobOutput() keeps a full copy of the job output and continues to append all new incoming data to it. Once data has been read by clients of the reader, it does not need to be retained any longer. Therefore, as presently implemented, the readers are quite inefficient and can use quite a lot of memory, especially if many readers are created for a job.

I've updated the output buffer so that it no longer copies data to each reader
The output buffer is now implemented with an immutable linked list
The output buffer does need a RWMutex, but it is held very briefly and never when walking the linked list


When there is a duplicate migration file (e.g. Callback), in the location list,  Flyway  gives an error. It would help if later version in list was used.

Which version and edition of Flyway are you using?
Team Edition 9.14.1
If this is not the latest version, can you reproduce the issue with the latest one as well? (Many bugs are fixed in newer releases and upgrading will often resolve the issue)
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
Command-line
Which database are you using? (Type & version)
SQL Server/Postgres/MySQL/,SQLite/Oracle
Which operating system are you using?
Windows
What did you do? (Please include the content causing the issue, any relevant configuration settings, the SQL statement(s) that failed (if any), and the command you ran)
I deliberately gave a location list that included several locations, hoping that Flyway would treat the files that it finds the same way as config entries and over-write the old file location with the new one (this should be the behaviour, I reckon. It would be very useful for variants of a particular version)) Instead, it gave a duplicate error
What did you expect to see?
Flyway would treat files the same way as config entries and over-write the old file location with the new one later in the list -this should be the behaviour,
What did you see instead?
Flyway : ERROR: Found more than 1 SQL callback script called afterMigrate__ApplyTableDescriptions!
At line:1 char:1
+ Flyway info
+ ~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (ERROR: Found mo...leDescriptions!:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

Offenders:
-> S:\work\Github\FlywayTeamwork\Pubs\Branches\Develop\Variants\Feedback\..\..\migrations\Callbacks\afterMigrate__ApplyTable
Descriptions.sql
->
S:\work\Github\FlywayTeamwork\Pubs\Branches\Develop\Variants\Feedback\.\migrations\afterMigrate__ApplyTableDescriptions.sql

I weas wondering whether Flyway's behavior when it finds a duplicate could change according to a config item. I can see that an accidental duplicate could be an alarming thing if not detected. What I'd like to achieve is an easier way of doing a variant of a version, usually the current one, as when you have to release a database in five different languages (It has happened to me) or different financial regulations.


Fix folding over transactions

The brod:fold/8 did not work correctly when the last message in the message set a transaction commit.
The output looked like this:
%%% brod_consumer_SUITE ==> t_fold_transactions: FAILED
%%% brod_consumer_SUITE ==> {function_clause,
    [{lists,last,[[]],[{file,"lists.erl"},{line,228}]},
     {brod_utils,handle_fetch_rsp,7,
         [{file,"/home/indrek/gems/brod/src/brod_utils.erl"},{line,661}]},
     {brod_consumer_SUITE,t_fold_transactions,1,
         [{file,"/home/indrek/gems/brod/test/brod_consumer_SUITE.erl"},
          {line,443}]},
     {test_server,ts_tc,3,[{file,"test_server.erl"},{line,1783}]},
     {test_server,run_test_case_eval1,6,
         [{file,"test_server.erl"},{line,1292}]},
     {test_server,run_test_case_eval,9,
         [{file,"test_server.erl"},{line,1224}]}]}

The issue was that #kafka_message{offset = LastOffset} = lists:last(Msgs), was used, when the Msgs list was empty.
Now instead of trying to infer next offset from the kafka_message, we pass the NextFetchOffset from the brod_utils:fetch/4 function.
Fixes #588

Hi @indrekj
Thank you for the PR.
make_fetch_fun is exported, this change is technically breaking the compatibility for this function.
maybe it makes sense to export a make_fetch_fun2 and a fetch/5
fetch/5 is a higher order of fetch/4 which tries to fetch a non-empty batch.

@zmstone I pushed the changes. I'm unsure if I understood everything, but if you want any other changes, please let me know.

thank you. published 4.1.0


Generate unit tests

I know that this issue is a little out of the scope of this project. I've seen https://github.com/cezarypiatek/MappingGenerator/issues/131.
I wanted to change AutoMapper to MappingGenerator but I have one blocker. I have many profiles in my program (the same situation is in many other projects in my company) and I have one unit test that checks the validation of mapping
           foreach (var profile in profiles)
            {
                var mapperConfig = new MapperConfiguration(cfg => { cfg.AddProfile(profile); });
                try
                {
                    mapperConfig.AssertConfigurationIsValid();
                }
                catch (AutoMapperConfigurationException ex)
                {
                    // I know that there is a problem
                }
            }

If someone adds a property to an object, the test will show him an error. I can't reproduce this behavior with MappingGenerator without creating a unit test for each mapping. But it requires a lot of work and the reviewer have to check if the test is added.
So if I have junior devs in my team I prefer to stay with AutoMapper with its disadvantages (I know it is slow, it is hard to debug, IDE doesn't show references of property) but I know that mappings are ok (or it is highly probable)
Any ideas on how to automate it?

I'm not familiar with the profiles (or I don't remember it, because  it's been round 6 years since I used AutoMapper the last time). If you want to track unmapped fields then I would recommend trying to use /*FullInitRequired:recursive*/ marker with my other analyzer described here https://cezarypiatek.github.io/post/immutable-types-with-roslyn/ This should solve the problem at least from the target object perspective.

@WojciechNagorski  does it answer your question?

Yes, We can close this issue. But I'm not sure if this solution is enough. I need to try it.


Add encryption support for importer

What have you changed? (mandatory)
Add encryption support for importer.
What are the type of the changes? (mandatory)

New feature

How has this PR been tested? (mandatory)
unit test
Does this PR affect documentation (docs) update? (mandatory)
No
Does this PR affect tidb-ansible update? (mandatory)
No
Refer to a related PR or issue link (optional)
Benchmark result if necessary (optional)
Add a few positive/negative examples (optional)

@DorianZheng CI failed
test import::engine::tests::test_sst_writer ... thread 'import::engine::tests::test_sst_writer' panicked at 'called Result::unwrap() on an Err value: "failed to load cipher file: Os { code: 2, kind: NotFound, message: "No such file or directory" }"', src/libcore/result.rs:1009:5

@zhangjinpeng1987 PTAL


Cannot read property 'getLayers' of undefined

I have been trying to get the time dimension working using a geojson file but not been very lucky. Is there no other way to set the default time without reading the values from a geojson file?
  $.getJSON("data/polygon.geojson",function(polygonData){
        polygonMap = L.geoJson( polygonData,{
            style: polygonStyle
        });
    });
    var testLayer = L.timeDimension.layer.geoJson(polygonMap, {
    updateTimeDimension: true,
    addlastPoint: true,
    waitForReady: true
});

got this working :)


Question - Vue-Router :id

Maybe, I'm using this completely wrong... but here's what I am trying to do...
From the applications index (I can click an application and goto /applications/:id) and it loads from the VuexORM Application Model (This works great)
computed: {
   application () {
      return Application.query().withAll().whereId(this.$route.params.id).first()
   }
}

What I would like to do though, is allow this to work when refreshing the page directly on the route...
So...
created()
{
     this.FetchApplication()
}

methods: {

   FetchApplication()
   {
     if (!this.application)
       this.$api.applications.include('location', 'user').read(1)
           .then(response => Application.insert({ data: response.data })
   }
}

I added a console.log() to the .then() of my Fetch and to the computed property...
On Load, it attempts the computed property and obviously can't find anything... so it fires off the fetch, the item is correctly added to the store... the computed property then fires again... but it's still NULL after this point?
Is there a way to get around this without loading ALL the applications into the store...

Are your primary keys declared as numbers? If so, you'll need to cast your route param e.g. Number(this.$route.params.id) since param values are strings.

That doesnt make since why it works when pre loaded from index and not when loaded on refresh... but I will try
Sent via the Samsung Galaxy S9, an AT&T 5G Evolution capable smartphone
Get Outlook for Androidhttps://aka.ms/ghei36

From: Cue @.>
Sent: Wednesday, April 6, 2022 6:04:56 PM
To: vuex-orm/vuex-orm @.>
Cc: Software @.>; Author @.>
Subject: [EXTERNAL]:Re: [vuex-orm/vuex-orm] Question - Vue-Router :id (Issue #773)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Are your primary keys declared as numbers? If so, you'll need to cast your route param e.g. Number(this.$route.params.id) since param values are strings.
—
Reply to this email directly, view it on GitHubhttps://github.com/vuex-orm/vuex-orm/issues/773#issuecomment-1090899435, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUH5FSIFIRIKF3OJEDBIVTLVDYKBRANCNFSM5SXNE54A.
You are receiving this because you authored the thread.Message ID: @.***>

OK! Please explain to me why that worked?
When I go from Index (Loaded 6 Applications) -> View Page (it shows fine with the original code)
When I refresh, it doesn't... But when I changed it to use Number() it does...
Why did it work from Index -> View, and not from Refresh to View? Both were using this.$route.params.id
Is it the way that Vue-Router passed the param?

When you navigate through router-link or programmatic navigation you're providing the param as a number.
When you refresh, the params are parsed from the URL (string) therefore the value will be a string.
Alternatively, if the component is a route component, consider using props and cast at the point of route configuration to avoid casting within components.

Worked like a charm!
props: ({params}) => ({ id: Number.parseInt(params.id) || 0 })


Interceptor additions

This PR adds several features to the interceptor:

The ability to change the onion blob, outgoing amount and the outgoing channel when resuming the payment. This feature is used when the interceptor needs to create a channel on the fly.
The ability to fail with FailIncorrectDetails in order to let probing work before the new channel is created.

The ability to change the onion blob

How can you change the onion blob? As you don't know who's beyond your immediate hop, so you'd just cause the route to fail entirely? Do you have a concrete example use-case?

The ability to change the onion blob

How can you change the onion blob? As you don't know who's beyond your immediate hop, so you'd just cause the route to fail entirely? Do you have a concrete example use-case?

We are already use this in production in our LSP when the penultimate node in the route creates a channel on the fly to the payee and pays her using the new channel. The onion is changed because the amount is lower than the amount the LSP received in order to cover the cost of the new channel. Of course the payee agreed to that before the payment and sent the payment_hash and payment_secret and the amounts to the LSP.

A forwarding node shouldn't return INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS, that should be returned by the final node right?

A forwarding node shouldn't return INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS, that should be returned by the final node right?

This error was indeed returned only by the final node, but this error is used for probing before the payment (works only for non-mpp payment). An interceptor which is supposed to create a channel on the fly can now send back this error to the payer to let her know that the payment would be successful.

This error was indeed returned only by the final node, but this error is used for probing before the payment (works only for non-mpp payment). An interceptor which is supposed to create a channel on the fly can now send back this error to the payer to let her know that the payment would be successful.

If this code is interpreted as meaning the details are actually incorrect, this could introduce an attack where an arbitrary node could halt further payment retries by returning a phony incorrect payment details

This error was indeed returned only by the final node, but this error is used for probing before the payment (works only for non-mpp payment). An interceptor which is supposed to create a channel on the fly can now send back this error to the payer to let her know that the payment would be successful.

If this code is interpreted as meaning the details are actually incorrect, this could introduce an attack where an arbitrary node could halt further payment retries by returning a phony incorrect payment details

I am not sure to understand fully what you mean, but this error is accepted by a payer when coming from a node other than the payee if 1) it's from the penultimate node in the path and 2) it's a "probing" payment with the payer using a "wrong" payment hash.

This error was indeed returned only by the final node, but this error is used for probing before the payment (works only for non-mpp payment). An interceptor which is supposed to create a channel on the fly can now send back this error to the payer to let her know that the payment would be successful.

If this code is interpreted as meaning the details are actually incorrect, this could introduce an attack where an arbitrary node could halt further payment retries by returning a phony incorrect payment details

I am not sure to understand fully what you mean, but this error is accepted by a payer when coming from a node other than the payee if 1) it's from the penultimate node in the path and 2) it's a "probing" payment with the payer using a "wrong" payment hash.

To know if a probe is successful, you should check if the payee has signed this error not the penultimate node. Otherwise some other error code should be used since the meaning of the error code is altered when it is not returned by the destination. No channel needs to exist for things to "just work" from the payer perspective, you only need a way to contact the payee and get them to sign the error, and return that error in the failure.

it i

This error was indeed returned only by the final node, but this error is used for probing before the payment (works only for non-mpp payment). An interceptor which is supposed to create a channel on the fly can now send back this error to the payer to let her know that the payment would be successful.

If this code is interpreted as meaning the details are actually incorrect, this could introduce an attack where an arbitrary node could halt further payment retries by returning a phony incorrect payment details

I am not sure to understand fully what you mean, but this error is accepted by a payer when coming from a node other than the payee if 1) it's from the penultimate node in the path and 2) it's a "probing" payment with the payer using a "wrong" payment hash.

To know if a probe is successful, you should check if the payee has signed this error not the penultimate node. Otherwise some other error code should be used since the meaning of the error code is altered when it is not returned by the destination. No channel needs to exist for things to "just work" from the payer perspective, you only need a way to contact the payee and get them to sign the error, and return that error in the failure.

What do you mean by "the meaning of the error code is altered"? In this case, the payer knows that it's a probe payment, knows that the error comes from the penultimate node and knows that the meaning of this error in this case is that the route and the fees are ok.

it i

This error was indeed returned only by the final node, but this error is used for probing before the payment (works only for non-mpp payment). An interceptor which is supposed to create a channel on the fly can now send back this error to the payer to let her know that the payment would be successful.

If this code is interpreted as meaning the details are actually incorrect, this could introduce an attack where an arbitrary node could halt further payment retries by returning a phony incorrect payment details

I am not sure to understand fully what you mean, but this error is accepted by a payer when coming from a node other than the payee if 1) it's from the penultimate node in the path and 2) it's a "probing" payment with the payer using a "wrong" payment hash.

To know if a probe is successful, you should check if the payee has signed this error not the penultimate node. Otherwise some other error code should be used since the meaning of the error code is altered when it is not returned by the destination. No channel needs to exist for things to "just work" from the payer perspective, you only need a way to contact the payee and get them to sign the error, and return that error in the failure.

What do you mean by "the meaning of the error code is altered"? In this case, the payer knows that it's a probe payment, knows that the error comes from the penultimate node and knows that the meaning of this error is that the route and the fees are ok.

The error code that they payment details are incorrect normally comes from the final node, not the penultimate node. Really for privacy reasons, no one should even know what the penultimate node is

it i

This error was indeed returned only by the final node, but this error is used for probing before the payment (works only for non-mpp payment). An interceptor which is supposed to create a channel on the fly can now send back this error to the payer to let her know that the payment would be successful.

If this code is interpreted as meaning the details are actually incorrect, this could introduce an attack where an arbitrary node could halt further payment retries by returning a phony incorrect payment details

I am not sure to understand fully what you mean, but this error is accepted by a payer when coming from a node other than the payee if 1) it's from the penultimate node in the path and 2) it's a "probing" payment with the payer using a "wrong" payment hash.

To know if a probe is successful, you should check if the payee has signed this error not the penultimate node. Otherwise some other error code should be used since the meaning of the error code is altered when it is not returned by the destination. No channel needs to exist for things to "just work" from the payer perspective, you only need a way to contact the payee and get them to sign the error, and return that error in the failure.

What do you mean by "the meaning of the error code is altered"? In this case, the payer knows that it's a probe payment, knows that the error comes from the penultimate node and knows that the meaning of this error is that the route and the fees are ok.

The error code that they payment details are incorrect normally comes from the final node, not the penultimate node. Really for privacy reasons, no one should even know what the penultimate node is

But the payer knows the penultimate node because she creates (at least currently) the full path to the payee. And the payee knows also because she registered herself to the LSP in order to "receive" a channel on the fly. This specific payment details are already known by the triplet (payer, lsp, payee), consequently this kind of error is not a privacy leak because there is no new information leaked. Do I miss something here?

But the payer knows the penultimate node because she creates (at least currently) the full path to the payee. And the payee knows also because she registered herself to the LSP in order to "receive" a channel on the fly. This specific payment details are already known by the triplet (payer, lsp, payee), consequently this kind of error is not a privacy leak because there is no new information leaked. Do I miss something here?

In this scenario maybe the penultimate forwarding node knows they are the penultimate forwarding node and that is the original privacy issue, normally they wouldn't know they were sending to the final destination. It seems incorrect to me to assume knowledge of this specific non-standard scenario but also want to use standard errors that would just confuse normal clients, if it's a custom scenario why not use a custom error?

But the payer knows the penultimate node because she creates (at least currently) the full path to the payee. And the payee knows also because she registered herself to the LSP in order to "receive" a channel on the fly. This specific payment details are already known by the triplet (payer, lsp, payee), consequently this kind of error is not a privacy leak because there is no new information leaked. Do I miss something here?

In this scenario maybe the penultimate forwarding node knows they are the penultimate forwarding node and that is the original privacy issue, normally they wouldn't know they were sending to the final destination. It seems incorrect to me to assume knowledge of this specific non-standard scenario but also want to use standard errors that would just confuse normal clients, if it's a custom scenario why not use a custom error?

The argument to use this standard error is that the meaning of the error is that the payment is ok but one detail is wrong (in the case of regular probing it's the payment_hash). When probing using the lsp, it's exactly the same meaning. And it cannot confuse any client because right now clients don't accept this error if not coming from the last node. lnd itself blacklists in the mission control any intermediate node sending back this error. So only a specific client which knows the "extended" meaning of the error will use it. See https://github.com/LN-Zap/zap-desktop/pull/3689

But the payer knows the penultimate node because she creates (at least currently) the full path to the payee. And the payee knows also because she registered herself to the LSP in order to "receive" a channel on the fly. This specific payment details are already known by the triplet (payer, lsp, payee), consequently this kind of error is not a privacy leak because there is no new information leaked. Do I miss something here?

In this scenario maybe the penultimate forwarding node knows they are the penultimate forwarding node and that is the original privacy issue, normally they wouldn't know they were sending to the final destination. It seems incorrect to me to assume knowledge of this specific non-standard scenario but also want to use standard errors that would just confuse normal clients, if it's a custom scenario why not use a custom error?

The argument to use this standard error is that the meaning of the error is that the payment is ok but one detail is wrong (in the case of regular probing it's the payment_hash). When probing using the lsp, it's exactly the same meaning. And it cannot confuse any client because right now clients don't accept this error if not coming from the last node. lnd itself blacklists in the mission control any intermediate node sending back this error. So only a specific client which knows the "extended" meaning of the error will use it. See LN-Zap/zap-desktop#3689

The thing that confuses me the most is that why not support probing from any client that isn't custom coded for this specific case by just returning the error from the final hop as normal?

But the payer knows the penultimate node because she creates (at least currently) the full path to the payee. And the payee knows also because she registered herself to the LSP in order to "receive" a channel on the fly. This specific payment details are already known by the triplet (payer, lsp, payee), consequently this kind of error is not a privacy leak because there is no new information leaked. Do I miss something here?

In this scenario maybe the penultimate forwarding node knows they are the penultimate forwarding node and that is the original privacy issue, normally they wouldn't know they were sending to the final destination. It seems incorrect to me to assume knowledge of this specific non-standard scenario but also want to use standard errors that would just confuse normal clients, if it's a custom scenario why not use a custom error?

The argument to use this standard error is that the meaning of the error is that the payment is ok but one detail is wrong (in the case of regular probing it's the payment_hash). When probing using the lsp, it's exactly the same meaning. And it cannot confuse any client because right now clients don't accept this error if not coming from the last node. lnd itself blacklists in the mission control any intermediate node sending back this error. So only a specific client which knows the "extended" meaning of the error will use it. See LN-Zap/zap-desktop#3689

The thing that confuses me the most is that why not support probing from any client that isn't custom coded for this specific case by just returning the error from the final hop as normal?

I agree with you that's it a little bit convoluted and you are right in theory. But that mean that the lsp/interceptor needs to be able to initiate the communication with the payee (which is a mobile phone) and right now the only connection between them are: 1) they are peers from ln point of view and 2) the payee can make api calls to the lsp. If we wanted to be able to do what you propose, we need to use the current connection between them initiated by lnd and to "inject" the new protocol asking to sign the error, or to create a new bidirectional channel to do that. It's a lot more complicated than simply enhancing the meaning of the error which is in fact a true meaning.

But the payer knows the penultimate node because she creates (at least currently) the full path to the payee. And the payee knows also because she registered herself to the LSP in order to "receive" a channel on the fly. This specific payment details are already known by the triplet (payer, lsp, payee), consequently this kind of error is not a privacy leak because there is no new information leaked. Do I miss something here?

In this scenario maybe the penultimate forwarding node knows they are the penultimate forwarding node and that is the original privacy issue, normally they wouldn't know they were sending to the final destination. It seems incorrect to me to assume knowledge of this specific non-standard scenario but also want to use standard errors that would just confuse normal clients, if it's a custom scenario why not use a custom error?

The argument to use this standard error is that the meaning of the error is that the payment is ok but one detail is wrong (in the case of regular probing it's the payment_hash). When probing using the lsp, it's exactly the same meaning. And it cannot confuse any client because right now clients don't accept this error if not coming from the last node. lnd itself blacklists in the mission control any intermediate node sending back this error. So only a specific client which knows the "extended" meaning of the error will use it. See LN-Zap/zap-desktop#3689

The thing that confuses me the most is that why not support probing from any client that isn't custom coded for this specific case by just returning the error from the final hop as normal?

I agree with you that's it a little bit convoluted and you are right in theory. But that mean that the lsp/interceptor needs to be able to initiate the communication with the payee (which is a mobile phone) and right now the only connection between them are: 1) they are peers from ln point of view and 2) the payee can make api calls to the lsp. If we wanted to be able to do what you propose, we need to use the current connection between them initiated by lnd and to "inject" the new protocol asking to sign the error, or to create a new bidirectional channel to do that. It's a lot more complicated than simply enhancing the meaning of the error which is in fact a true meaning.

I can see that, do you not need to connect to them already to see if they are really around to accept the payment? I can think of one workaround for your scenario which is for the receiver to create a shared key with their forward provider. When they make an invoice, they use this shared key. The forward provider doesn't know the preimage though, so when the real payment comes through they forward an HTLC to the real final node to get the preimage. I'd personally prefer a more generic solution that follows along the standard error case because it would allow for custodial wallets to support this same flow, plus we could extend this to submarine swaps, and it would allow for any payer to do the probe not just a custom client.

But the payer knows the penultimate node because she creates (at least currently) the full path to the payee. And the payee knows also because she registered herself to the LSP in order to "receive" a channel on the fly. This specific payment details are already known by the triplet (payer, lsp, payee), consequently this kind of error is not a privacy leak because there is no new information leaked. Do I miss something here?

In this scenario maybe the penultimate forwarding node knows they are the penultimate forwarding node and that is the original privacy issue, normally they wouldn't know they were sending to the final destination. It seems incorrect to me to assume knowledge of this specific non-standard scenario but also want to use standard errors that would just confuse normal clients, if it's a custom scenario why not use a custom error?

The argument to use this standard error is that the meaning of the error is that the payment is ok but one detail is wrong (in the case of regular probing it's the payment_hash). When probing using the lsp, it's exactly the same meaning. And it cannot confuse any client because right now clients don't accept this error if not coming from the last node. lnd itself blacklists in the mission control any intermediate node sending back this error. So only a specific client which knows the "extended" meaning of the error will use it. See LN-Zap/zap-desktop#3689

The thing that confuses me the most is that why not support probing from any client that isn't custom coded for this specific case by just returning the error from the final hop as normal?

I agree with you that's it a little bit convoluted and you are right in theory. But that mean that the lsp/interceptor needs to be able to initiate the communication with the payee (which is a mobile phone) and right now the only connection between them are: 1) they are peers from ln point of view and 2) the payee can make api calls to the lsp. If we wanted to be able to do what you propose, we need to use the current connection between them initiated by lnd and to "inject" the new protocol asking to sign the error, or to create a new bidirectional channel to do that. It's a lot more complicated than simply enhancing the meaning of the error which is in fact a true meaning.

I can see that, do you not need to connect to them already to see if they are really around to accept the payment? I can think of one workaround for your scenario which is for the receiver to create a shared key with their forward provider. When they make an invoice, they use this shared key. The forward provider doesn't know the preimage though, so when the real payment comes through they forward an HTLC to the real final node to get the preimage. I'd personally prefer a more generic solution that follows along the standard error case because it would allow for custodial wallets to support this same flow, plus we could extend this to submarine swaps, and it would allow for any payer to do the probe not just a custom client.

The lsp checks only that the final payee is currently a connected peer and that means that the lsp is able to create a channel. I quite don't follow your proposition because the lsp needs to know the payment hash that the payee sent to the payer in order to detect the payment and create a channel before paying to the payee the original amount minus a fee for the channel creation. btw, right now probing needs a custom client only because it's not standardized.

The lsp checks only that the final payee is currently a connected peer and that means that the lsp is able to create a channel. I quite don't follow your proposition because the lsp needs to know the payment hash that the payee sent to the payer in order to detect the payment and create a channel before paying to the payee the original amount minus a fee for the channel creation. btw, right now probing needs a custom client only because it's not standardized.

The payee could register the hash with the penultimate forwarder, the idea is that the payer wouldn't realize that there is this extra hop

The lsp checks only that the final payee is currently a connected peer and that means that the lsp is able to create a channel. I quite don't follow your proposition because the lsp needs to know the payment hash that the payee sent to the payer in order to detect the payment and create a channel before paying to the payee the original amount minus a fee for the channel creation. btw, right now probing needs a custom client only because it's not standardized.

The payee could register the hash with the penultimate forwarder, the idea is that the payer wouldn't realize that there is this extra hop

The payer needs to realize that there is an extra hop because the channel between the lsp and the payee is generally private, and the info concerning this channel is in the routing hints.

custodia

it would allow for custodial wallets to support this same flow

I don't think that custodial wallets need to be taken into account.

@cfromknecht: review reminder

@cfromknecht: review reminder

@cfromknecht: review reminder

@cfromknecht: review reminder

@cfromknecht: review reminder

@cfromknecht: review reminder

@cfromknecht: review reminder

@cfromknecht: review reminder

Does this PR encompass the changes proposed here?

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity


Feature Request: Automatic rate limiting for multiple entries of the same domain

Type

[ ] General question or discussion
[x] Propose a brand new feature
[ ] Request modification of existing behavior or design

What is the problem that your feature request solves
When submitting multiple pages of the same website (domain) it may trigger a captcha or other limiting factor.
Describe the ideal specific solution you'd want, and whether it fits into any broader scope of changes
The tool should self- limit processing entries of the same domain. Optionally the delay should be configurable.
What hacks or alternative solutions have you tried to solve the problem?
Nothing. On the other hand I discovered too late that many pages weren't archived and now they aren't available anymore on any platform.
How badly do you want this new feature?

[ ] It's an urgent deal-breaker, I can't live without it
[ ] It's important to add it in the near-mid term future
[x] It would be nice to have eventually

[x] I'm willing to contribute dev time / money to fix this issue maybe 5 bucks. Ain't much I know.
[x] I like ArchiveBox so far / would recommend it to a friend
[ ] I've had a lot of difficulty getting ArchiveBox set up

We discussed this as a sub-requirement of recursive archiving (https://github.com/ArchiveBox/ArchiveBox/issues/191) but I agree it deserves a separate issue.
The (currently closed-source) tooling I provide on top of ArchiveBox for paying clients does implement fairly advanced rate-limiting on a per-local-host, per-remote-IP, per-domain, and per-chrome-profile basis, but it's not yet public.


consolidate retry into retry wrapped lambda

Codecov Report

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

@@            Coverage Diff             @@
##           master     #353      +/-   ##
==========================================
+ Coverage   75.28%   75.67%   +0.38%
==========================================
  Files           5        5
  Lines         777      777
  Branches      226      226
==========================================
+ Hits          585      588       +3
+ Misses        137      136       -1
+ Partials       55       53       -2

Impacted Files
Coverage Δ

tmuxp/workspacebuilder.py
90.9% <0%> (+1.81%)
:arrow_up:

Continue to review full report at Codecov.

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


Launching a script from this for volume down/UP

Hello, Is it possible to launch a script when pressing the volume up/down buttons? I can't seem to get this to work.

Closing this. Something happened with my homeassistant setup where i could no longer call scripts by script.scriptName, but instead script.SomeUniqueScriptNumber. This issue just happened to occur near the time I was messing with this card.


fix(installer): Skip or fix broken unit tests

What does this PR do?
Fix unit tests on methods that hardcoded /opt/datadog-packages (installer preinst), skip tests that require root for all distros
Motivation
No failures
Additional Notes
Possible Drawbacks / Trade-offs
Describe how to test/QA your changes

/merge

/merge

/merge -c


Update npm.rb with higher max_nesting value

npm list was failing after hitting the default PSON max nesting of 20.  Increasing to 50 solved issues on all of my systems.

Seems very similar to #101, which I opened a while ago, but is not merged yet

Whoops, didn't see the other one. Thanks!

On Jan 18, 2015, at 11:34 PM, rangoy<EMAIL_ADDRESS>wrote:
Seems very similar to #101, which I opened a while ago, but is not merged yet
—
Reply to this email directly or view it on GitHub.

@jvogt I just merged #101 so I'm going to close this PR! Thanks for the contribution though!


[8.x] Split Collections Into A Separate Package

This PR splits collections into a separate package while remaining backward compatible with older releases of Laravel.
This also necessitated the creation of a new illuminate/macroable package.
The Illuminate\Support collection classes were left in place and simply extend the new Illuminate\Collections classes where appropriate and override a few construction methods that use the self keyword. The Illuminate\Support\Arr class was treated the same way.
No existing tests needed to be changed.

Yesssssssssss I am so happy!

YYOOOOOUUUUHHOOOUUU! 🎉
thx @regiszanandrea for the ping!
(After several years trying to push that, it only needed one tweet to @driesvints to got it! 🤣)

Nice

Is the plan to remove the extended classes in the future? So there is no duplicate Collection and Macroable classes?

@olivernybroe https://github.com/laravel/framework/pull/32481

@olivernybroe while technically yes I think it could be a year or two away. There is no maintenance overhead for us keeping them and it only inflicts pain on users by removing them.

Nice! Any chance that pagination could be added in now? A lot of love for this out there still: https://gist.github.com/simonhamp/549e8821946e2c40a617c85d2cf5af5e


Document the use of cloudshell_working_dir

The support for working dir from https://github.com/GoogleCloudPlatform/cloud-run-button/pull/26 needs documentation.

If the directory does not exist, this error comes up:
Error: sub-directory doesn't exist in the cloned repository: [your configured subdir]

I ran into this because the default branch did not have my sub-directory, so I was able to delete the cloned repository and re-run the displayed cloud_shell command with the --git_branch flag.

I think it's expected?

This is a troubleshooting note for the future documentation.


[6.x] Add Filesystem presignedUrl() method

Storage::disk('s3')->presignedUrl('path/to/upload/file', Carbon::now()->addMinutes(10));

Why?
In a serverless environment as Vapor, it is advised to upload files directly to a cloud storage system as AWS S3. The laravel/vapor-core package adds a route to your project that creates such a presigned url, but the creation of those urls is linked to vapor env settings. You might want to allow uploads to a different (AWS S3) storage system. It also does not allow you to create a presigned url without a request to that vapor route.
This PR adds a method that makes it easy to create a presigned url, on any storage system you want, using any settings you want.
How?
I used the same code structure as the existing temporaryUrl() / getAwsTemporaryUrl() methods. This allows the presignedUrl() method to be added on other (third-party) storage adapters as well.
Remarks

I did not add any tests for this PR, as there seem to be none present for the existing temporaryUrl() / getAwsTemporaryUrl() methods.
If this PR gets accepted, I will create a PR to update the documentation.

I appreciate the sentiment here but I think I will hold off for now since this is a pretty AWS specific feature I believe? Regardless, we would sometimes need to return the headers, not just the URI.

@taylorotwell  It seems to be present in google cloud storage as well.
Regarding the headers, those are not needed to upload files in my experience. I also didn't find any info about it in the AWS S3 docs. In what situations do you need those headers?


Add files via upload

university official website URL : https://www.du.ac.kr/main.do
IT related course :  https://dept.du.ac.kr/computer/CMS/Board/Board.do?mCode=MN005

@j-ine Thank you for your patience while waiting for a review and processing your request. Pull request merged. Please start applying for JetBrains educational subscription at https://www.jetbrains.com/shop/eform/students in an hour, to allow the changes to propagate through JetBrains systems.


Support for newer versions of PowerShell?

Hi there, you label this as compatible with the legacy Windows PowerShell (Desktop) and CloudShell, but do you officialy support PowerShell Core (6 and later) on Windows 10? I was hit by issue #11 when testing so I could not confirm but I did spot a few things that prevent use as is.
Firstly, function checkAzCli() uses Get-InstalledModule to test for the existence of the ImportExcel. From PowerShell Core, the cmdlet can not detect ImportExcel if it is installed in a Windows PowerShell folder, mine is installed to:
C:\Program Files\WindowsPowerShell\Modules\ImportExcel
I install modules that are compatible with both Desktop and Core in Desktop folders so I only have one set of modules to manage and Desktop can't import modules from a Core folder.
Changing line 73 as follows would work:
$VarExcel = Get-Module -Name ImportExcel -ListAvailable -ErrorAction SilentlyContinue
Secondly, checkAzCli() attempts to install ImportExcel if not found but does so using default settings. This attempts to install the module using the CurrentUser scope which does not work so well for my situation (which can't be unique). With folder redirection enabled, PowerShell attempts to install the module to a network drive which slows things down, but as said network drive is at the other end of a slow VPN it is pretty much unusable. I'm forced to set the scope to AllUsers so I would rather the script did not attempt to install at all.
Lastly, function checkPS() tests $PSVersionTable.PSEdition for 'Desktop' and but does not test for 'Core' so defaults to 'CloudShell' when running on 'Core'. The $Global:PSEnvironment variable is never used in the script so not sure what purpose that function serves?
Here is my PS config:
Name                                   Value

PSVersion                              7.1.3
PSEdition                               Core
GitCommitId                          7.1.3
OS                                          Microsoft Windows 10.0.17763
Platform                                 Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion  2.3
SerializationVersion               <IP_ADDRESS>
WSManStackVersion              3.0
Thanks!
Mike

Having downgraded the resource group extension to the preview version (1.1.0) the script will now run through so with a couple of tweaks this would work just fine on PowerShell Core on Windows 10.
I also modified checkPS() to test for 'Core' so that LoginSession was executed:

Hi Mike,
wow, thanks for the troubleshooting and feedback. I updated the script with your suggestions and I believe it should work now.
Can you try it and give us a feedback?
Thanks