Possible regression with draper when updating from 1.12

Hi!
I'm using devise + cancancan along with draper gem, and until 1.12 the behavior was that calling can? on a decorated model used the decorated model for checking authorization instead of the decorator class. Maybe I can better explain myself with an example:
 # in my ability.rb
 can :read, User do |user|
   true
 end

 # in a view
 @user = User.last.decorate # instance of UserDecorator
 can? :show, @user
 #=> true, since the ability for User was used

After updating to 1.13, this is no longer the case, and calling can? :show, @user on a decorated user will not use User ability at all.
Is this intended behavior or is it a regression? If this is intended, how can I get that bahaviour back, maybe with an extension or configuration in my decorators / ability.rb?
Thanks!

@dgilperez Definitely not intended. Could you reproduce this using a SimpleDelegator from the ruby standard library? That should behave similarly to draper, if not it might be draper specific. It would be helpful if we had a regression for this with a delegator so this wouldn't happen in the future.

I would expect this might be related to https://github.com/drapergem/draper/blob/master/lib/draper/decorator.rb#L191-L204, not being checked with the new performance rule indexing stuff.

Yeah, let me play around and see if I can add a failing test to the suite.

BTW, yeah, that'd be the workaround, though that's really inconvenient in a large app (like mine :().

Test added (or so I think), please let me know.

I believe I've run into the same issue, using draper 2.1.0, cancancan 1.13.1, rails 4.2.4.
@redacted #=> #<RedactedDecorator:0x00..a0 @object=#<Redacted:0x00..18>>
can?(:update, @redacted) #=> false
can?(:update, @redacted.object) #=> true

Downgrading to cancancan 1.12.0 fixes the issue.

@jaredbeck @dgilperez I don't think this problem falls within CanCanCan's domain. The performance fix works with the ancestors of an object, which is a valid thing to check when asserting that something is something else.
If something like Draper is merely pretending to be something else, but doesn't satisfy this requirement completely, it isn't fair to add additional logic at the cost of performance to ensure we cover that edge case.
For example, after releasing 1.13, we thought after seeing this regression we'd have a problem with rspecs' mock_model method. E.g order = mock_model(Spree::Order, number: 'A Number'), we can still use cancancan with this method. This is because mock_model overrides the .class method, so cancan correctly checks against the Spree::Order rules. This can be done on Drapers' side if this an importance concern for them.
What I can do is possibly look at adding an extension point for custom rule checking logic in cancancan. That way a plugin can be developed specifically for use with draper, which would require more work, but would prevent adding things into cancancan to cover an edge case for a single gem.
Does this sound fair to you? Am I perhaps leaving something out?

If you're dropping support for draper, you're going to break a lot of apps.  Draper has two million downloads (https://rubygems.org/gems/draper). So, if you're dropping support for draper, maybe add a boot-time warning?
if defined?("Draper")
  warn "cancancan 1.13 dropped support for Draper. Checking abilities against decorated objects will no longer work. Please make sure to check against un-decorated objects"
end

@jaredbeck We never explicitly supported draper in the first place. The only thing I can find in the Wiki is a reference to https://github.com/anlek/draper-cancan. I took over the project a couple months ago, did cancan explicitly support draper before it was cancancan?

We never explicitly supported draper in the first place.

That's fine.  My question is about what you want your user's experience to be like when they upgrade to cancancan 1.13.  I'm just suggesting that you give them a happier experience by providing a warning.

Do you have any comments on the extension point I made earlier?

I don't know enough about draper to comment on that.  You should probably ask Jeff (@jcasimir).

I got the same problem after upgrading to 1.13. I would really like to see support for draper in cancancan. It currently breaks a lot of things within our application.

@jaredbeck while I understand your thinking - supporting draper not being part of cancan domain - and agree with everything you state, I also think that CanCan + Draper for sure will be a pretty common combination to be found in applications out there.
Thus, I think that a solution for that should be provided, regardless if it comes from an cancan_draper gem or from cancan itself. Unfortunately, I don't really have the time right now to do it myself :(
At the very least, I'd add a visible notice in the Changelog and upgrading instructions, maybe even in the bundle install output, and I'd probably consider this change introduced by 1.13 as a breaking change. It'll save some headaches.

@dgilperez I'll look into tackling this over the weekend and see if there's an amenable solution.

Stumbled over the same problem when upgrading to 1.13. Some warning (while bundle install) would be enough for now.
@dgilperez a workaround would be to use some wrapper method or monkey-patch like
def can_do?(action, object)
  if object.decorated?
     object = object.model
  end
  can? action, object
end

Then just replace every usage of can? with can_do?

@Skulli yeah, that seems like a feasible workaround ... but I think I'll wait for a gem or patch, since changing can? with can_do? would be kind of a big hit in my (large) codebase.

I'll look into tackling this over the weekend and see if there's an amenable solution.

Any news, Richard?

I think I'll wait for a gem or patch [instead of workaround]

David, my team has also decided not to upgrade to 1.13 yet.

@dgilperez Similar to the suggestion from @Skulli, could you add a single rule like this?
can do |action, object_class, object|
  if object_class < Draper::Decorator
    can? action, object.model
  end
end

Pretty clever workaround, @dgynn. It made my test suite fail though, but much less than a plain upgrade ... so it looks very promising. Not much time to look deeper into it until next week, I'll let you know.

And here I am in the same place ..

@jaredbeck Apologies, I was not able to get to it this past weekend. However, I'm on Vacation after tomorrow!
I'd like to propose two separate solutions here and get feedback on them both. First I want to state that:
This doesn't work because, while draper overrides kind_of?, the ancestors of a Draper::Decorator do not include the ancestors of MyDecoratedObject. We use ancestors to help with lookup performance, after that change was added, only the filtered objects would receive kind_of? calls. The fact being, a Draper::Decorator is not a kind_of? or is_a? of its decorated object, and this is why I'm hesitant to add specific code to address this.
Any methods added onto Draper::Decorator will actually interfere with any other methods you define on your own class. For example, object (which is a terrible name nonetheless) would be intercepted by Draper, you could not define this method on the class you were decorating.
That said, I understand the concern that people may want to use delgators (whether it be SimpleDelegator or Draper) in place of the objects they decorate and have everything magically work.
First suggestion:
Have decorators that wish to work with cancan implement a common interface. A method could be defined on any class wanting to operate this way with cancan, say cancan_delegated_class.
If the subject responds to this method, the result of that method would be used in place of the decorator. This would require a project like Draper to be willing to add this method, or someone to develop a plugin that extends Draper::Decorator, or do it in their own code base.
Second suggestion:
We add a configuration class to cancan. We would use some sort of SubjectResolution class to determine how exactly we resolve the the subject class. This could then be extended by something like:
CanCanCan.configure do |c|
  c.subject_resolution_class = DraperSubjectResolution
end

Which would allow for a composition based approach and would allow for a plugin, or functionality in your own application to configure what class is being used to resolve the subject.
All of these names are pending, and are just for example.
I personally prefer option #1, as it's the least invasive, and I believe that cancancan operates correctly. The issue lies with decorators that want to be 100% substitutes for their decorated class failing to cover all the basis required to do so.
With option 2, there are several other extension points within the system that a configuration class would be handy for. I think that adding a configuration will eventually be necessary at some point anyway.

@robmathews Also makes an excellent point in https://github.com/CanCanCommunity/cancancan/pull/257
You should have an @article, and a @decorated_article in your controllers. You should be using the real object when using it for real things. (e.g. not view decoration)

@Senjai Those two approaches seem like they would work. The first approach though would require all Draper users (or the Draper gem) to make a change and then CanCanCan needs to constantly check for subject.respond_to?(:cancan_delegated_class). The second approach of having a Draper (or other) adapter is good but I don't think that should be a global configuration.
What if Ability had a resolve_subject_class method. And a Draper user could include a DraperAdapter in their ability class that would override it.  Something like...
class Ability
  include CanCan::Ability
  include CanCan::DraperSubjectResolution
  # rules...
end

This basically does what you have in the second suggestion but makes the configuration ability-specific. Also the DraperSubjectResolution could more easily call super for non-Decorator objects and get the default CanCan::Ability logic.
And now that I look at it, we already have a alternative_subjects method so we don't need a new resolve_subject_class method. Maybe it could work something like this (I haven't tried this at all)...
module CanCan
  module DraperSubjectResolution
    def alternate_subjects(subject)
      if subject.class < Draper::Decorator
        super(subject.object_class)  # draper method for getting true class I believe
      else
        super(subject)
      end
    end
  end
end

@dgynn Yes, writing a module and prepending it to the ability class to override can? and cannot? would be my goto.
We dont need to override the alternate subjects method. We need to override can? and cannot?.
def can?
  if thing.instance_of?(Draper::Decorator)
    subject = thing.object
  else
    super
  end
end

Yes, I'll summarize:
Draper documention itself recommends that the decorator objects only be decorated in the views, not the controllers, and provides a helper method decorates_assigned for this purpose. They are very explicit about this, and really they are in agreement with @Senjai. Doesn't sound like they would be sympathetic to a PR that changed the "kind_of?" implementation.
However, that doesn't really help all of us poor souls who are maintaining large applications that reference @object everywhere. We still want it to just work, and we really don't want to wander through all of our views changing @object => object.
One change you can do I've noticed is not decorate your objects on load, but decorate them on way out of the controller action.
Another possibility would be examine the performance problem that prompt this change in the first place. I've never had a performance issue with CanCan checking abilities, but maybe that's just me, and I don't really all of the changes anyway.

@robmathews Most apps dont have many rules. Some apps have thousands of rules. The performance change took lookup from O(n) to O(1) which is -major-. See https://github.com/CanCanCommunity/cancancan/pull/178. Also the last two commens by @dgynn and I.

I'll give that a shot, and if it works, maybe create a gem called
'draper-cancancan' or something that mixes it in automatically.
On Thu, Nov 5, 2015 at 1:24 PM, Richard Wilson<EMAIL_ADDRESS>wrote:

@dgynn https://github.com/dgynn Yes, writing a module and prepending it
to the ability class to override can? and cannot? would be my goto.
We dont need to override the alternate subjects method. We need to
override can? and cannot?.
def can?
if thing.instance_of?(Draper::Decorator)
subject = thing.object
else
super
endend
—
Reply to this email directly or view it on GitHub
https://github.com/CanCanCommunity/cancancan/issues/255#issuecomment-154144650
.

@Senjai That PR convinces me, thanks.

@robmathews If you do come up with something that works for you as a gem, I'd be happy to fork it from you as part of the organization as well.

Not a problem. I've got it working in my little gem test right now, but
it's failing to actually prepend the can? method correctly in my real app.
Probably something trivial.
It's here if you want to take a look:
https://github.com/GoodMeasuresLLC/draper-cancan
Otherwise I'll poke you later if it works.
Rob.
On Thu, Nov 5, 2015 at 4:24 PM, Richard Wilson<EMAIL_ADDRESS>wrote:

@robmathews https://github.com/robmathews If you do come up with
something that works for you as a gem, I'd be happy to fork it from you as
part of the organization as well.
—
Reply to this email directly or view it on GitHub
https://github.com/CanCanCommunity/cancancan/issues/255#issuecomment-154197018
.

Turns out it works as written, but we were mocking too aggressively locally.
So I'll be taking out the puts and pushing tomorrow.
On Thu, Nov 5, 2015 at 4:36 PM, Robert Mathews <
<EMAIL_ADDRESS>wrote:

Not a problem. I've got it working in my little gem test right now, but
it's failing to actually prepend the can? method correctly in my real app.
Probably something trivial.
It's here if you want to take a look:
https://github.com/GoodMeasuresLLC/draper-cancan
Otherwise I'll poke you later if it works.
Rob.
On Thu, Nov 5, 2015 at 4:24 PM, Richard Wilson<EMAIL_ADDRESS>wrote:

@robmathews https://github.com/robmathews If you do come up with
something that works for you as a gem, I'd be happy to fork it from you as
part of the organization as well.
—
Reply to this email directly or view it on GitHub
https://github.com/CanCanCommunity/cancancan/issues/255#issuecomment-154197018
.

Ok, so it's actually https://github.com/GoodMeasuresLLC/draper-cancancan
b/c of a naming conflict.
On Thu, Nov 5, 2015 at 5:31 PM, Robert Mathews <
<EMAIL_ADDRESS>wrote:

Turns out it works as written, but we were mocking too aggressively
locally.
So I'll be taking out the puts and pushing tomorrow.
On Thu, Nov 5, 2015 at 4:36 PM, Robert Mathews <
<EMAIL_ADDRESS>wrote:

Not a problem. I've got it working in my little gem test right now, but
it's failing to actually prepend the can? method correctly in my real app.
Probably something trivial.
It's here if you want to take a look:
https://github.com/GoodMeasuresLLC/draper-cancan
Otherwise I'll poke you later if it works.
Rob.
On Thu, Nov 5, 2015 at 4:24 PM, Richard Wilson<EMAIL_ADDRESS>wrote:

@robmathews https://github.com/robmathews If you do come up with
something that works for you as a gem, I'd be happy to fork it from you as
part of the organization as well.
—
Reply to this email directly or view it on GitHub
https://github.com/CanCanCommunity/cancancan/issues/255#issuecomment-154197018
.

May I suggest to perform a Major Version change to better follow SemVer? "Dropping" Draper, even if it was a bug or whatever, is going to break a lot of apps, SemVer itself suggests that if a bug that a lot of apps relies on is fixed, it should be marked as a major change.
Considering drapern has a lot of downloads and activeadmin too. And cancancan is used in activeadmin, this is definitely a major version change.

Works like a charm @robmathews. Thanks!

I think this issue can be closed @Senjai
At least for me, it was beautifuly solved with @robmathews's draper-cancancan.
Thanks a bunch and 🍻  for you!

@dgilperez :beers:


purescript-arrays doesn't compile

➜  purescript-arrays git:(master) psc2 src/**/*.purs bower_components/purescript-*/src/**/*.purs
Expected RBrace, found LName ("in") at line 209, column 46

Largely irrelevant now.


Add KHR_materials_unlit support to importer

Following #211, the importer should set up a "background" node when it sees the KHR_materials_unlit extension.

Ah that's frustrating. 😞
If it's OK with everyone, I'll write up a summary of our questions and issues with importing and exporting unlit materials (this issue) and AO (#123), share that for your review, and then if agreed we can post in the Blender forums for suggestions on these issues.

@donmccurdy OK for me.
Waiting a better solution, I propose to implement path light setup for 2.80 too

Sure. Per https://github.com/KhronosGroup/glTF-Blender-IO/issues/220#issuecomment-455811913 I don't think that export should require the light path setup; just an emissive material that doesn't contain a Principled node. But if the importer sets the whole light path up that's fine.


Add leniency to received certificates

Motivation
This PR adds leniency for processing received certificates. Previously we were requiring the certificates come from the author, however if the author happens to unbond from the validator set, then other validators would be unable to fetch that particular certificate, which would block syncing and possibly halt block production.
The new rule is that validators can now process a certificate as long as it comes from a validator in the current committee set.

LGTM


Add PRINT-OBJECT for all classes

Closes #65

Yeah I think this is good for now. Ready to merge?

Yeah I think this is good for now. Ready to merge?

Go ahead. I forgot about the Draft feature as it's a newish feature, or at least pretty new to me.

Thanks!


adds Invocation

Adds Invocation class. Motivation of this PR:

We store request message in Invocation. Without storing this, it is not possible to add retry operation functionality when an error happens. Retry count and etc will be stored in Invocation.
Simplifies InvocationService code.

👍

please rebase and merge


How to detect previous path when navigating from one component to another in reactjs

This is a bug tracker, not a support system. For usage questions, please use Stack Overflow or Reactiflux where there are a lot more people ready to help you out. Thanks!


404 Not Found "Wrong path"

I am not able to push to bare repository
Create a bare repo
Cloned it to local repo
installed git-lfs on client
then
git lfs track *.rpm
git add "file.rpm"
git commit -m "test"
git lfs ls-files --> shows the file
editing .gitconfig to point to server url
from local repo
git push origin master
then entering credentials and keep uploading
at server
./lfs_server.sh -s ip address
2016-02-12 19:18:47.508593Z Listening for HTTP on ip_address:8080
2016-02-12 19:20:43.007939Z Error ip_address "POST /objects/batch HTTP/1.1" 404 Not Found "Wrong path
please help

Looks like the problem is in your server, not the git lfs client. Check your .gitconfig file.

I am using my home dir and its shared between client and server so .gitconfig is the same
could you please clarify as i understand all whats need from server side is
[root@git lfs_server]# ls -rlt
total 4
drwxrwxrwx. 2 owner owner  47 Aug 26 13:14 lib
-rwxrwxrwx. 1 owner owner 199 Aug 26 13:14 lfs_server.sh
drwxrwxrwx. 2 owner owner  23 Aug 26 13:14 bin
[user@git]# cd
[user@git]# ./lfs_server.sh -s ip_address

Also would you please advise which implementation best suites Enterprise usage for hosting large binary files


synchronize in user provided stream when readin data from D->H

Thanks Evghenii. This looks like a good first cut. I think we'll want to collapse the copy + synchronize code at the end of reduce().
There's already a Thrust primitive called get_value(). This is the function that detail::reference's conversion operator calls when it needs to convert a reference into a value. Since get_value() will suffer from the same problem as reduce() exposed, I suggest the following course of action:

call your synchronize() function at the end of get_value() to ensure that the result is ready
have reduce() call something like return thrust::detail::get_value(policy, partial_sums[0])

That way, all the required synchronization is located in one place and we don't need to duplicate so much code in reduce() and other functions where this problem will inevitably show up again.
What do you think?

Having taken a look at the implementation of get_value(), it looks like it is itself implemented with assign_value(). That might be the correct place to put the call to synchronize().

I attempted to replace parital_sum[0] with get_value(exec, &partial_sum[0]) but it terminates with
terminate called after throwing an instance of 'thrust::system::system_error'
  what():  an illegal memory access was encountered
Aborted (core dumped)

I don't understand what happens, exactly;  get_value calls assign_value https://github.com/thrust/thrust/blob/master/thrust/system/cuda/detail/get_value.h#L57
and this would be a good place to insert sync, e.g.
synchronize(stream(derived_cast(exec)), "kaboom")
but first I need to deal with segfault. Doesn't &partial_sum[0]  return device_ptr, and assign_value will dispatch the correct copy? If not, please advice on what is going on, thanks.

Update: seems there was some bug, which got fixed. Need still help in understanding the following:
replacing return partial_sums[0] with   return thrust::detail::get_value(exec, &partial_sums[0]) still copies in default stream. Why is that?

I think it is because trivial_copy_n, which this code will eventually call, is hard-coded to use the legacy stream:
https://github.com/thrust/thrust/blob/master/thrust/system/cuda/detail/trivial_copy.inl#L137
You should investigate what happens when you try relaxing that to use the stream inside the execution policy. If all tests pass, we should be good

All tests pass with the 2 known failures with this change.

It looks pretty good modulo the cosmetic changes.
I think we should avoid checking for a null reference in cuda_memcpy_stream().
I assume the reason we receive null execution policy references at that point in the code is due to these shenanigans here:
https://github.com/thrust/thrust/blob/master/thrust/detail/reference.inl#L114
Rather than continue to traffic in null pointers, I think we should see what happens if we just default-construct a system inside of reference's conversion to value operator and call get_value() directly.

I'll be investigating solutions to avoid checking for null references. Keep this PR open for now, if solution is simple I'll commit it with this PR.

The changes look good so far. I think the only thing left is to eliminate some of that code related to detail::reference which no longer has a purpose.

Can you verify that all the unnecessary code has been eliminated ? Thanks

It looks like  strip_const_assign_value  should be removable, but something strange is going on in attempt to remove the function:
Replacing
strip_const_assign_value(select_system(system1, system2), src);

in https://github.com/thrust/thrust/blob/1.8.3/thrust/detail/reference.inl#L139 with
using thrust::system::detail::generic::assign_value;
assign_value(thrust::detail::derived_cast(select_system(system1, system2)), m_ptr, src);

Generates ptxas linking error...
ptxas fatal   : Unresolved extern function '_ZN6thrust6system6detail7generic12assign_valueINS_7pointerINS_5tupleIblNS_9null_typeES6_S6_S6_S6_S6_S6_S6_EENS0_4cuda6detail17execute_on_streamENS_11use_defaultESB_EEPKS7_EEvNS2_3tagET_T0_'

Any idea what might be going on?

I don't know what's going on, but here is one clue:
When I plugged that name into c++filt it indicated that it's the system::detail::generic overload of assign_value
It seems like it should have chosen the CUDA-specific overload of this function.

I see, the generic overloads is better match for
assign_value(thrust::detail::derived_cast(select_system(system1, system2)), m_ptr, src);

because the first argument is rvalue, and CUDA-specific overload is for lvalue ref. It appears strip_const_assign_value from the beginning served a purpose of converting rvalue to lvalue ref, and  thus should be kept.

Nice analysis, I agree.


Enhancing Predictive Calc with Additional Models and Hyperparameter Tuning

To further improve the capabilities of Predictive Calc under GSSoC'24 Extd, I propose adding new machine learning algorithms in form of projects and implementing hyperparameter tuning techniques. By incorporating a wider range of models and optimizing their parameters, we can enhance the accuracy, flexibility, and overall performance of the tool. This will provide users with more options to choose the best model for their specific prediction tasks and ensure that the models are fine-tuned to achieve optimal results.
I wish to contribute this to your repository. Kindly assign me this.

Hi @murtaza-sadri-19, for now, please be more specific about your proposal.
Describe one problem you plan to tackle and the model you'd create for it. For example, the project currently includes a House Price Prediction model using regression. You could develop multiple models or document both successful and rejected models in a Jupyter notebook. Also, mention the estimated time that you will require.
Make sure to review the add new model template to follow the proper issue format.

Like I'm Planning to implement Hyperparameter tuning in a model which would classify Breast cancer tumor into two classes viz. Benign/Malignant. And I would also apply ensemble learning techniques over the dataset.
I would require approx 3-4 days to complete the same. And regarding the format I would make that I comply to that.

Ok, great, go ahead!

Updates @murtaza-sadri-19?

Updates @murtaza-sadri-19?

Closing this issue as a similar one has been created under #33 by you.


Task/issue #4 sqlite

Closes #4

Codecov Report

Merging #8 (2fcf2c6) into main (d644d28) will increase coverage by 0.30%.
The diff coverage is 99.24%.

@@            Coverage Diff             @@
##             main       #8      +/-   ##
==========================================
+ Coverage   98.90%   99.20%   +0.30%
==========================================
  Files          17       21       +4
  Lines         455      504      +49
==========================================
+ Hits          450      500      +50
+ Misses          5        4       -1

Impacted Files
Coverage Δ

tests/backend/postgres_test_sql.py
100.00% <ø> (ø)

tests/backend/test_util.py
100.00% <ø> (ø)

dinao/backend/base.py
98.52% <97.56%> (-1.48%)
:arrow_down:

dinao/__version__.py
100.00% <100.00%> (ø)

dinao/backend/__init__.py
100.00% <100.00%> (ø)

dinao/backend/postgres.py
100.00% <100.00%> (+2.56%)
:arrow_up:

dinao/backend/sqlite.py
100.00% <100.00%> (ø)

tests/backend/conftest.py
100.00% <100.00%> (ø)

tests/backend/sqlite_test_sql.py
100.00% <100.00%> (ø)

tests/backend/test_postgres_intg.py
100.00% <100.00%> (ø)

... and 8 more

Continue to review full report at Codecov.

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


hack/test: add upgrade test

I have set up a NIGHTLY jenkins job: https://jenkins-etcd.prod.coreos.systems/view/operator/job/etcd-operator-upgrade/
It will do upgrade test trying to upgrade from latest release to tip version of etcd operator.

Verified with a success: https://jenkins-etcd.prod.coreos.systems/view/operator/job/etcd-operator-upgrade/7/consoleText

@etcd-bot test this please

LGTM


Implement mid-page link redirects

Work in progress
Summary
An implementation of mid-page redirects

Hello @neflyte,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

/update-branch

Error trying to update the PR.
Please do it manually.

/update-branch

Error trying to update the PR.
Please do it manually.

/update-branch

Error trying to update the PR.
Please do it manually.

Preview environment is ready http://mattermost-docs-preview-pulls.s3-website-us-east-1.amazonaws.com/5868

I've made a change to allow redirects to work in a preview environment. The change requires an update to the command that builds the docs so we can specify the PR ID and add that to redirect target paths.
For example, in preview-env-fork.yml I modified the Build step to use the following command:
make SPHINXOPTS="-j auto -D mm_url_path_prefix=/${{ github.event.number }}" html
This makes the build prepend the PR ID path to redirect target URLs. A redirect target would look like /1234/messaging/organizing-conversations.html instead of /messaging/organizing-conversations.html.
@pfltdv Would this change be okay? I made a similar change to preview-env.yml for non-forked repos.

I've made a change to allow redirects to work in a preview environment. The change requires an update to the command that builds the docs so we can specify the PR ID and add that to redirect target paths.
For example, in preview-env-fork.yml I modified the Build step to use the following command: make SPHINXOPTS="-j auto -D mm_url_path_prefix=/${{ github.event.number }}" html
This makes the build prepend the PR ID path to redirect target URLs. A redirect target would look like /1234/messaging/organizing-conversations.html instead of /messaging/organizing-conversations.html.
@pfltdv Would this change be okay? I made a similar change to preview-env.yml for non-forked repos.

Thanks alot @neflyte for making the redirection work in the PR environment. Changes are definitely ok. Great work.

@pfltdv Is there anything else I need to do to get the pipeline changes I mentioned to work? The preview doesn't seem to be updated with the expected redirect pages.

@pfltdv Is there anything else I need to do to get the pipeline changes I mentioned to work? The preview doesn't seem to be updated with the expected redirect pages.

@neflyte For PR's from forked repositories we are using workflow run file from the master branch, since GitHub does not expose the secrets to the forked PRs. I will create a preview environment from cloned branch.

@neflyte PR environment is created with same commits at http://mattermost-docs-preview-pulls.s3-website-us-east-1.amazonaws.com/5874

@neflyte @cwarnermm Pipeline changes are merged into master. Is it possible to merge master into this branch so changes will be active.

@pfltdv - Yes. @neflyte needs to resolve the file conflict in this PR, and then we can merge master into this branch.

/update-branch

Error trying to update the PR.
Please do it manually.

@iyampaul - Adding you as a reviewer to share the fix we're applying to our mid-page redirects based on our recent troubleshooting conversation and your great idea for moving forward.


Add HubSpot, Facebook and LinkedIn Tracking to openapparel.org

Overview
We'd like to add tracking codes to openapparel.org for some of our marketing sites.
For Facebook:
This is the meta-tag that needs to be added: meta name="facebook-domain-verification" content="of7vm0cmuvg7rk7076ojpv7ith6qhm" / (removed carrots from the ends because code wasn't displaying in GitHub but you can see how it should look from the screenshot below)
These are the accompanying directions.

We can hit "Verify Domain" once done.
For LinkedIn:

| First, copy the code:

script type="text/javascript"> _linkedin_partner_id = "3366124"; window._linkedin_data_partner_ids = window._linkedin_data_partner_ids || []; window._linkedin_data_partner_ids.push(_linkedin_partner_id);    </noscript

| Next, paste the code into the global footer of your domain either before or after the  tag.

For HubSpot:

cc @katieashaw

Updated Google tag as well:
This is the Global Site Tag (gtag.js) tracking code for this property. Copy and paste this code as the first item into the  of every webpage you want to track. If you already have a Global Site Tag on your page, simply add the config line from the snippet below to your existing Global Site Tag.


Moisture bad reading

The moisture sensor reads bad values when the moisture is measured.

The reason for the bad reading was that the first design used an output-mode digital pin to feed with 5V the moisture probe, in order to minimise the power consumption feeding only when a reading had to be carried by the moisture probe.
The mentioned design proved wrong, so the current design feeds the moisture probe directly from the 5V source of the board.
With this design the moisture levels are within the following threshold:
240 -> Completely wet
865 -> Completely dry


[$500] IOU-In offline, green thumbnail is not displayed for distance request created.

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.12
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @
Action Performed:
Pre-conditions:

Create new workspace

Select and save 2 waypoints for making distance request

Go to https://staging.new.expensify.com/

Tap profile icon

Tap preferences

Toggle on forced offline

Navigate to LHN

Tap fab

Tap request money ---- Distance

Enter start and finish waypoints from suggestions

Tap next

Select a Workspace ( use new workspace)

Tap request

Expected Result:
In offline, green thumbnail must be displayed for distance request created.
Actual Result:
In offline, green thumbnail is not displayed for distance request created.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/115492554/8a274822-b214-4def-9ef5-26fe25ccb1ab

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0118764c639595457a
Upwork Job ID:<PHONE_NUMBER>191092736
Last Price Increase: 2023-12-14

Proposal
Please re-state the problem that we are trying to solve in this issue.
What is the root cause of that problem?
While creating an optimistic Distance request, we set transaction.reportID to the chat report.
What changes do you think we should make in order to solve the problem?
We should set transaction.reportID to the newly created IOU report.

What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
In offline, green thumbnail is not displayed for distance request created.
What is the root cause of that problem?
When creating a new distance request, we will initialize transactionDraft_1.reportID as the reportID of the root report. But when creating optimistic data for request money API, transaction.reportID is the reportID of IOU report
https://github.com/Expensify/App/blob/3a44f772e2c381b1cdb025f845551c5f0985bad5/src/libs/actions/IOU.js#L674-L679
So that, existingTransaction.reportID (It is reportID of the root report) will overwrite optimisticTransaction.reportID (it is reportID of IOU report)
What changes do you think we should make in order to solve the problem?
Note that, In our codebase, we are using transaction.reportID as reportID of the IOU report. So that we shouldn't save reportID of the root report to this field.
To clarify the meaning of the fields, I suggest when creating a new distance request we should save reportID of the root report to transactionDraft_1.parentReportID instead of transactionDraft_1.reportID and use
transactionDraft_1.parentReportID for the purpose of identifying participants of money request
What alternative solutions did you explore? (Optional)
NA

Please re-state the problem that we are trying to solve in this issue.
When creating a distance request offline, the green receipt placeholder is not displayed (in place of a map thumbnail) in the report preview.
What is the root cause of that problem?
When the user confirms a new distance request, the optimistic transaction is not being built correctly, probably because the code for building it is not as clear as is needed.
What changes do you think we should make in order to solve the problem?
I suggest writing a new function called buildOptimisticDistanceRequestTransaction in libs/TransactionUtils, and writing it so that it is easier to understand exactly how the transaction is built.
I also suggest fixing another problem while writing that same function. This problem is that the optimistic transaction includes pendingFields.waypoints:add, which is not correct. See issue 32263 for my (belated) proposed solution to this other problem.

I believe it's intentional for us to show a placeholder image when offline - https://expensify.slack.com/archives/C03TME82F/p1695781672838349?thread_ts=1695148441.990019&cid=C03TME82F. Closing this out.

@bfitzexpensify please re-check the issue description. We don't show any placeholder when offline atm. The issue's intended exactly to fix that.

Thanks for the heads up @paultsimura. I was looking at the placeholder once the distance request had been opened, which is as expected.
I think we can still leave this closed, however - I'm not sure this is a high-value issue to fix, and I'm not spotting an obvious wave or VIP project that we've identified internally to attach it to. It's an edge flow and the lack of a receipt placeholder image doesn't influence the experience at all. We'll eventually want to update that image to something map-specific rather than the receipt image, and I think that would be a more appropriate time to make sure it's appearing as we'd expect offline when a distance request is created.

Thanks @bfitzexpensify, I understand your point, however, the root cause here is still worth fixing, not for the sake of the preview placeholder alone:
Setting an incorrect transaction.reportID on the Distance request offline can result in other incorrect behaviors, as we use TransactionUtils.getAllReportTransactions in several other places.
For example, createWorkspaceFromIOUPayment:

This flow is used for bottom up flow converting IOU report to an expense report. When user takes this action,
we create a Collect type workspace when the person taking the action becomes an owner and an admin, while we
add a new member to the workspace as an employee and convert the IOU report passed as a param into an expense report.

It uses the same function TransactionUtils.getAllReportTransactions(iouReportID) to collect the transactions for building the new Collect type workspace, and if we do it with an offline-created Distance request in the IOU Report, this Distance request will be missed:
https://github.com/Expensify/App/blob/ca63857cc5da5537b42e227d91fe5f72552d0eb0/src/libs/actions/Policy.js#L1787-L1801

I agree with @paultsimura's point, The root cause relates to the new refactor on request money flow. We are having a confusion about the meaning of transactionDraft_1.reportID as expained in my proposal

Just reopening this so that I take action on it later on today.

Thanks for the extra detail @paultsimura. Just to clarify, what would happen right now with the conversion to a workspace made by changing an IOU to an expense report? Would the workspace still be created, but the distance request would be missing?

@bfitzexpensify
Yes, if we perform it offline (with the optimistic Distance request), the workspace will be created, but without that distance request

OK, we chatted about this internally - we don't support IOU distance requests as it stands, and this is being addressed via https://github.com/Expensify/App/issues/23291. So we will leave this closed.


sds: include cluster, node, and zone localInfo in request headers

Fixes https://github.com/lyft/envoy/issues/887

@bndw thanks for adding this. I'm fine with this approach as an interim solution but we need:

docs (https://lyft.github.io/envoy/docs/configuration/cluster_manager/sds_api.html)
Some test that verifies the headers are getting set.

@mattklein123 I've updated the docs and am working on getting a test around the addition, though it may take some time as I'm unfamiliar with the language/test suite 😄

Going to go ahead and close this. Please reopen when you have more time to work on it.


Integration of frontend with ionic

How can I use app.js of the frontend inside ionic?

Sorry I haven't used ionic, so cannot really help you on that issue. I might build another frontside app using ionic at somepoint (or you could build one). But I can't really say when I have time for this - too much work and other stuff to do :(
If you get ionic to work please provide some information about that so that everyone knows what to do with that.


[ADP-3272] Simplify handling of UTxOs in inner helper function of balanceTx.

Issue
ADP-3272
Description
This PR simplifies the handling of UTxOs within the inner helper function of balanceTransaction, so that it only has to handle two UTxO-related data structures, both supplied by the outer function:

utxoReference: the set of all UTxOs (formerly known as combinedUTxO).
utxoSelection: the set of all UTxOs that the transaction is allowed to spend, along with a pre-selected subset.

As a bonus, because this PR moves the computation of UTxO-related data structures from the inner helper function to the outer function, the above data structures should now be evaluated at most once, instead of multiple times (once per strategy).
Notes
The balanceTransaction function delegates the main portion of its work to an inner helper function that is parameterised by SelectionStrategy. It initially calls the inner helper function with SelectionStrategyOptimal, but if that strategy fails, then it (potentially) calls the inner helper function a second time with SelectionStrategyMinimal.
In the event that the inner helper function is evaluated more than once (with two different strategies), we ideally want to avoid recomputing potentially expensive data structures that should be constant across both evaluations.

@Anviking wrote:

One request (in addition to the comment): could we rename balanceTransactionWithSelectionStrategyAndNoZeroAdaAdjustment to something else?

Sure.
Would balanceTransactionInner work for you?
Or perhaps we could use the following even shorter names:

balanceTx
balanceTxInner

Or perhaps we could use the following even shorter names:
balanceTx
balanceTxInner

Sounds great to me, just note renaming Transaction -> Tx could cause some cascading breakage and changes (for instance BalanceSpec has a balanceTx helper)
(Though btw, long term, I'd wonder if we couldn't structure things to not have to call something inner, but that's not of too much concern now)


[RFC] Making R interface more idiomatic

I notice that there is a version 2.0 of xgboost in the plans, which among other things, is expected to include support for categorical features in the R interface.
Given that this is a major version release and as such is expected to introduce potentially breaking changes, I think this is a good opportunity to make the R interface more in line with base R and core/popular R modeling packages. Many people (including myself) find the R interface of xgboost to be inconvenient and unidiomatic, but changing the interface for xgboost() from its current state would be a rather big breaking change and would probably break lots of user scripts that depend on xgboost().
In short, xgboost() does not work with the most common data types used in R (data.frame) and does not follow R conventions in terms of e.g. function arguments. For people who are familiar with base R and with other R packages, there are many ways in which the R interface of xgboost could be improved for a better end-user experience, such as:

Offering an x/y interface as well as a formula interface.
Accepting data frames as inputs and handling categorical/factor variables from data frames.
Accepting factor variables as "y".
Accepting non-standard evaluation for column names (e.g. passing the weight variable as a column name without quotes).
Using base-1 numeration for integers as R does instead of base-0.
Controlling prediction types through a type argument.
Making the naming of function arguments more consistent with base R and core packages - for example, naming the weights as weights instead of weight, like base R does.
Changing default arguments by, for example, not dumping the model to a file in disk by default.

Among many others.
Would this project accept big breaking PRs for the R interface (particularly for xgboost() and predict.xgb.Booster()) for the 2.0 release that would make it more similar to base R and other R packages?

I don't think any current active maintainers are big R users so we welcome input. Could we just build a new interface behind a different namespace until it's ready? I don't think there's a need to immediate replace the old interface in a short space of time.

Would this project accept big breaking PRs for the R interface (particularly for xgboost() and predict.xgb.Booster()) for the 2.0 release that would make it more similar to base R and other R packages?

I would like to welcome these changes. The concern about breaking changes can be handled by running reverse dependency checks.

I suggest to keep xgboost() as it is and instead call the new function differently, e.g. xgboost2(), or use a slim method dispatch with xgboost.formula(). The former has the advantage to accompany it with a corresponding predict2() function. Otherwise, great work @david-cortes.


Add multi-hint functionality for buggy outputs, provided the student has changed their code.

Linted and three (count 'em) new tests added.
We should probably add a testing infrastructure, at some point ...

Oh, @eyurko, sorry -- the previous PR merge caused this to have a merge conflict. Would you mind fixing it, and merging after that? Thanks!


fix fix a problem with histogram statistics collection parameters

Proposed changes
CHANGES:

Fixed a problem with histogram statistics collection parameters.
Solved the problem that it takes a long time to collect histogram statistics.

TODO:

Optimize histogram statistics sampling method.
Make the sampling parameters effective.

Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

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

run buildall


A Massive pop-ups of: "failed to save project" (Pics are attached)

Describe the bug

Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-erx4sk
Steps to reproduce
..
Expected behavior

SAVE THE PROJECT!!!
HELP CHAT.. 24/7 FOR YOUR LOYAL CUSTOMERS!!!!

Screen Recording / Screenshot
Already uploaded
Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 130
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
performance.memory = {
  "totalJSHeapSize": 88649836,
  "usedJSHeapSize": 84507148,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Username = Gold-B
Chat ID = 92cc9e00c839

Additional context

SAVE THE PROJECT!!!
HELP CHAT.. 24/7 FOR YOUR LOYAL CUSTOMERS!!!!

Sorry to hear this! Are you able to save now? A number of database improvements have been made recently.

TLDR: download the project to ensure you don't lose your work
I had a similar experience thrice in the last 24 hours with a project I had previously started.
I downloaded the project and then went to Stackblitz to continue from wherever it had stopped -- and was shocked to see it had reverted to code from hours earlier in the day.  I was admittedly less panicky the second and third time. ;)
I have that code in the zip file I downloaded ... is my conversation history lost in this update then?  Do I just push the unzipped project to the stackblitz repo directly or via github or something? What's the easiest way to recover from this?  A zip file import tool would be helpful right now.  Thanks for your help!!

Appreciate the feedback! We are aware of this issue and are tracking is here: #2762.


podman should check for newer versions of images when starting a new container

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Description

Steps to reproduce the issue:

podman pull $image

podman run $opts $image

Describe the results you received:
podman will always use the locally available image without checking if there is a newer version
Describe the results you expected:
podman should (optionally) check for a newer version and (optionally) pull it if one is found
Bug 1684263

@QiWang19 Still working on this?

@QiWang19 needs an update.

podman run --pull=always can always pull the new image and solve this issue.

We should add the --pull default into contianers.conf


Improved probe implementation, error logging, documentation and naming of srf02_i2c driver.

Probe is now using the version register of the sensor
Removed/renamed many constants and strings that have been copied from the maxbotics driver origin
Improved error logging in case something is not working as expected

@cehberlin can you rebase to resolve the conflicts, then please CI output to see the minor build and formatting errors.

@dagar I thought you expected me to rebase to master, which I did. However, I am right now quite confused why the driver and my other do not exist anymore? How to mirgrate my changes if the driver was removed? Can you give me some background how this should be done?

@cehberlin all the distance sensors were moved to src/drivers/distance_sensor. This allows a board to include them all easily. Otherwise the actual code shouldn't have changed at all.


Add R to the list of supported languages

@look we also noticed these other two places probably need updating:
https://docs.github.com/en/repositories/working-with-files/using-files/navigating-code-on-github#about-navigating-code-on-github
https://docs.github.com/en/search-github/github-code-search/understanding-github-code-search-syntax#symbol-qualifier

Thanks!


[Git] folder support Accept All Incoming

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

I think this is a very useful feature when deal with many merge conflicts. I try to implements it by my self extension, but find it is hard. @KamilSzot


Menu not working with turbolinks

I am using metisMenu for menu, it works fine if without turbolinks but when I add turbolinks in application.js it works only once when i reload the page then after 1 click can't open menu. Help Needed
Thanks

After looking at metisMenu homepage, if you have code similar to the following:
$(function () {
    $('#menu2').metisMenu({ toggle: false });
});

then, it would explain the problem you've described:
it works only once when i reload the page

When you fully reload the page, the jQuery ready event will be emitted and your code will probably work, and no longer on subsequent page navigations.
... after 1 click...

Could you expand on what you meant by this? If you clicked on an <a> tag or somehow triggered a page navigation, then the jQuery ready event does not fire for those subsequent page visits. You may have to change your javascript to listen for the turbolinks:load event instead of using $() that is so prevalent in many jQuery plugins.
Their README covers what it takes to enhance your javascript to work well with turbo links. Specifically this section may help you.

Yes Running JavaScript When a Page Loads works for me
document.addEventListener("turbolinks:load", function() {
  $('#side-menu').metisMenu({toggle: false });
})

@alexspark Thanks for you comment

Closing as solved


Beam Search Decoder outputs -1 as prediction (how is this possible?)

When I implement Beam Search Decoder, its first prediction outputs -1 at multiple time steps.
I don't understand how this is possible, since the projection layer is passed a vocabulary size that is indexed from 0. With a Greedy Decoder, for example, this is clearly not possible since the output is the index of the best element in the array. Is this no longer true for Beam Search?
tf.set_random_seed(hparams.graph_seed)
source, target_in, target_out, weights, source_lengths, target_lengths = iterator.get_next()
true_batch_size = tf.size(source_lengths)

embedding_encoder = tf.get_variable("embedding_encoder", [hparams.src_vsize, hparams.src_emsize])
encoder_emb_inp = tf.nn.embedding_lookup(embedding_encoder, source)
embedding_decoder = tf.get_variable("embedding_decoder", [hparams.tgt_vsize, hparams.tgt_emsize])
decoder_emb_inp = tf.nn.embedding_lookup(embedding_decoder, target_in)

encoder_cell = tf.nn.rnn_cell.BasicLSTMCell(hparams.num_units)
encoder_outputs, encoder_state = tf.nn.dynamic_rnn(encoder_cell, encoder_emb_inp, sequence_length=source_lengths, dtype=tf.float32)

decoder_cell = tf.nn.rnn_cell.BasicLSTMCell(hparams.num_units)

encoder_outputs = tf.contrib.seq2seq.tile_batch(encoder_outputs, multiplier=hparams.beam_width)
source_lengths = tf.contrib.seq2seq.tile_batch(source_lengths, multiplier=hparams.beam_width)
                encoder_state = tf.contrib.seq2seq.tile_batch(encoder_state, multiplier=hparams.beam_width)

multiplier=hparams.beam_width)
batch_size = true_batch_size * hparams.beam_width
attention_mechanism = tf.contrib.seq2seq.LuongAttention(num_units=hparams.num_units,
                                                        memory=encoder_outputs,
                                                        memory_sequence_length=source_lengths,
                                                        scale=True)
decoder_cell = tf.contrib.seq2seq.AttentionWrapper(cell=decoder_cell,
                                                    attention_mechanism=attention_mechanism,
                                                    attention_layer_size=hparams.num_units)
decoder_initial_state = decoder_cell.zero_state(batch_size, tf.float32).clone(cell_state=encoder_state)

projection_layer = layers_core.Dense(units=hparams.tgt_vsize, use_bias=False)

decoder = tf.contrib.seq2seq.BeamSearchDecoder(cell=decoder_cell,
                                               embedding=embedding_decoder,
                                               start_tokens=tf.fill([true_batch_size], hparams.sos),
                                               end_token=hparams.eos,
                                               initial_state=decoder_initial_state,
                                               beam_width=hparams.beam_width,
                                               output_layer=projection_layer,
                                               length_penalty_weight=hparams.length_penalty_weight)

outputs, _, _ = tf.contrib.seq2seq.dynamic_decode(decoder, maximum_iterations=tf.reduce_max(target_lengths))
ids = outputs.predicted_ids

did you try using the FinalBeamSearchDecoderOutput instead of dynamic decode ? https://www.tensorflow.org/api_docs/python/tf/contrib/seq2seq/FinalBeamSearchDecoderOutput

Is there any update on this? I'm running into the same issue...

Is there any update on this? @nave01314 Did you figure out how to resolve the error? I'm running into the same issue...

It looks like dynamic_decode() pads the output with -1 outside of the valid length. The lengths are returned by dynamic_decode() as the third variable, so you can use that to mask the output or only use the valid parts of each decoded sequence.


[bug] indented paragraphs in comments (or elsewhere) taken as code

the code opening tokens should be disabled in a comment block, so it's an ordering thing mostly.

Ok actually it was fine, the issue is that blocks contained with other blocks are deactivated only if the outer block is MD_OCB_ESC but it should also be if it's a math block. Adding this should fix the problem.


switched labels on admin interface?

Are "Ignored if MMSI is set" and "Leave blank if there is no mmsi" labels in the right place?

Lol, this was the token error that checks if anybody is actually using the app & being awake!
In reality I noticed this but forgot to fix - thanks for the reminder!
Fixed in<EMAIL_ADDRESS>


Feature request : Icons empty state

Hello @BcRikko,
Can you please add a parameter to make the heart ❤and / or star ⭐empty / transparent inside ?
Like a "is-empty" class to the icon.
Using your "Reaction" design, I want to make a ratting interface.
I believe it's only adding some color code in the scss but I'm don't know how to do it 😭
Anyway, thank you very much for your work 👍

It's good 👍

@guidouil  What do you think of this? 🤔

I like it very much :)
Does it also work with is-medium and is-large (like a large empty star) ?

Yes, of course 👍

:tada: This issue has been resolved in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[LOCAL-44] Strings: reverse sweep (auto)

NOTE: String Sweep will be suspended for this repo until this PR is merged or closed!
/cc @zendesk/i18n @zendesk/i18n-dev
Risks
Low. English edits and title improvements.

@zendesk/vegemite - Please check out the failing test here. This will need to be merged before the repo will be included in the next sweep. Thanks!

@coreysf tl;dr it's fixed now.
ZAS requires a rake command (rake i18n:standardize) to be run after updating translations to make them compatible with the i18n gem (we can't use the Zendesk one because this is an open-source project). We have a test that makes sure the generated file was updated after the zendesk one. Now because @string-sweep only changed the zendesk one it failed. I had to make a manual change to the generated one to fix it.
Any way we can make @string-sweep do this automatically?

Took a look with the I18n-dev team. Running the rake task won't be possible (it's not feasible to clone repos when sweeping files), so was looking at ways of moving the logic somewhere else (without creating one-off solutions and making the string sweep more complex). But looking at the rake task, it basically copies the data to a new file, which isn't good at all, it just makes things more complex because now you need to sync both files.
I'd say the correct solution, Instead of maintaining the rake task plus keeping the file in sync, would be to just implement your own I18n backend (http://guides.rubyonrails.org/i18n.html#customize-your-i18n-setup) that knows how to consume zendesk_apps_support.yml (it's just a yaml file anyways, it isn't too complicated). Also an option, If your team would like, we can work together to extract that backend from our private i18n gem, so you can use it here directly. In the meantime, we'll need to ask that your team fixes the build for reverse sweep PRs, we deal with a lot of repos per week, even checking branches in each repo to fix the build (whether it be tests or running rake tasks) isn't feasible for us =\
If you'd like to discuss more, feel free to ping me or the team.

Hi @dadah89, thanks for looking into this! I'll look into these options. In the meantime we'll make sure to fix the build for reverse sweep PRs. Apologies for the trouble.

@danielbreves we're constantly thinking of ways to have less manual steps for us and for the dev teams, knowing better about the different use cases definitely help us, so send any feedback you have! We'd be pretty happy to work together on a fix too, don't be afraid of reaching out.


Move spec file for consistency

Move the spec file for the etcd class to a classes subdirectory for
consistency with the directory schema we use for our other modules.

Merge away.


Add list, datepicker and textfield component guides

[x] Information about isInvalid prop needs to be added. It's use is unclear as discussed here: https://github.com/mui/mui-toolpad/issues/2826
[ ] Clicking on datepicker and textfiled throws an error
[ ] Add demo for list component

Facing some webpack issue. @Janpot Can you take a look? Thanks

Facing some webpack issue. @Janpot Can you take a look? Thanks

There might be an extra space somewhere in the Datepicker.md file - this should go away if you remove it

There might be an extra space somewhere in the Datepicker.md file - this should go away if you remove it

Just checked, found none. It was working today when I was on yarn. The other two similar files datagrid.md, button.md are working fine.
The failing lint test also mention about some module issue: Unable to resolve path to module. Maybe these are related.

I pushed a fix

Date picker, text field still break:
https://github.com/mui/mui-toolpad/assets/92228082/dd39a412-799d-4900-8a2b-e26bed883787

Date picker, text field still break:

fix added

About the missing demo in the list component, I guess we can't add it. So I should just remove it?

I don't know what it would look like. @bharatkashyap if you have an idea, otherwise we can omit.

Can you add links to the PR preview
Can you address the vale comments

Should we remove isInvalid for now as discussed in https://github.com/mui/mui-toolpad/issues/2826? I can remove it if we agree.


c2670.bench, list index out of range

Hi there,
Thank you for your repo. It is a great help for my research. When I was using c2670.bench to measure the testability, it has an error saying that  "list index out of range". Do you have any idea about this? I changed the format based on the example.
Traceback (most recent call last):
  File "calculate_testability_measures.py", line 39, in <module>
    calculateTestabilityMeasures(InputFileName, OutputFileName)
  File "calculate_testability_measures.py", line 11, in calculateTestabilityMeasures
    levels = createLevelArrayFromCircuitDescription(circuitDescription)
  File "/home/x5zhang/ICCAD/SCOAP/python-circuit-testability-measures/src/create_level_array_from_circuit_description.py",line 11, in createLevelArrayFromCircuitDescription
    } for i in inputs
  File "/home/x5zhang/ICCAD/SCOAP/python-circuit-testability-measures/src/create_level_array_from_circuit_description.py",line 11, in <dictcomp>
    } for i in inputs
IndexError: list index out of range

Hi Joe,
I'm sorry but I made this many years ago as part of a university course project and uploaded it here for reference. I am not actively maintaining this

Hi sir,  I am not understanding how to run this code for benchmark circuits, can u suggest me


Prev focused app across displays or spaces

I've got a hotkey to open a certain app. It will take me to that app from whatever window, display or space I start on. I'd like to be able to quickly return to the place I was previously but am not sure how to do that.
I don't think #104 applies, since I'm not trying to follow any sort of ordering. I may need to jump back to a different display or space, but I don't know which.
It's almost like I need a way to mark a window before jumping with the hotkey to open the app, then I could just return to the marked window and delete the mark. I don't think that's a thing though.

Does the recent selector not apply here? It will bring you back to the previously active window, space, or display.

hey, thanks! I don't think that the recent selector is well explained, at least not in the man page. but it certainly works and I guess it's described in the wiki here.


WIP: test: add simple envtest cluster vulnerability scanning integration tests

Description
Introducing envtest cluster integration tests.
Related issues

Relates to #335, but does not close it

Remove this section if you don't have related PRs.
Checklist

[x] I've read the guidelines for contributing to this repository.
[x] I've added tests that prove my fix is effective or that my feature works.
[ ] I've updated the documentation with the relevant information (if needed).
[ ] I've added usage information (if the PR introduces new options)
[ ] I've included a "before" and "after" example to the description (if the PR is a user interface change).

@chen-keinan Maybe you can scan through this draft and tell me what you think before I add tests for more workload types. 🙏

@chen-keinan Maybe you can scan through this draft and tell me what you think before I add tests for more workload types. 🙏

the test case look ok , isn't the envtest nfra is the same we have today : envtest?

isn't the envtest nfra is the same we have today : envtest?

WDYM? The itests run with kind. Envtest spins up a simple envtest cluster (from within the test suite), with just etcd and api-server - nothing more, nothing less. Did you try it? It works very well IMO.

isn't the envtest nfra is the same we have today : envtest?

WDYM? The itests run with kind. Envtest spins up a simple envtest cluster (from within the test suite), with just etcd and api-server - nothing more, nothing less. Did you try it? It works very well IMO.

does it require Kubebuilder bin to run locally ?

isn't the envtest nfra is the same we have today : envtest?

WDYM? The itests run with kind. Envtest spins up a simple envtest cluster (from within the test suite), with just etcd and api-server - nothing more, nothing less. Did you try it? It works very well IMO.

does it require Kubebuilder bin to run locally ?
ERROR	controller-runtime.test-env	unable to start the controlplane	{"tries": 0, "error": "fork/exec /usr/local/kubebuilder/bin/etcd: no such file or directory"}

No requirement for the kubebuilder CLI, but you need to install envtest for running tests from a IDE or standalone: https://book.kubebuilder.io/reference/envtest.html#installation. The Makefile takes care of this to run tests in CI (or locally). Does make test work for you?

Does make test work for you?

yes it works and I like it.

couple of comments , need to check if the current tests in itests can be migrated and I assume you plan to put it under folder on the main project

I am not sure if I understand what you re writing here. 🤔 My suggested overall plan is described in https://github.com/aquasecurity/trivy-operator/issues/335 (last part).

LGTM , in term of folder structure I would suggest to move it one level up , to be in project level, so we could extent the itest for other scanners and reuse suite code

I see this almost as a controller unit tests with mocks, e2e would be more close to what we have currently on itests.

I do not agree with you here. 😉  Not using any mocks in these tests, so they are definitely integration tests (of the controller)! I'll probably mock out the logs reader in my next PR to add integration tests for the scan job controller. But that is because I have to, since api-server nor etcd can provide me with pod logs.
I would also like to fix https://github.com/aquasecurity/trivy-operator/issues/370 before adding integration tests for the scan job controller, but for now I'll just have to wait for your reviews and merge. What's holding this up? Just time to review/merge, or is there something else? Please tell me! 😺

in term of folder structure I would suggest to move it one level up , to be in project level, so we could extent the itest for other scanners and reuse suite code

If I don't misunderstand you, I am against this. We should ideally have one integration test per controller, each of them getting a separate envtest cluster. Reusing code is of course something we should do!

Not sure I follow , there is a lot of testdata/fixture and some of suite_test code that can be reused why duplicate ?

@josedonizetti I am not sure if I am able to figure out what causes the race, but this PR is introducing ansync testing, which is new in trivy-operator. So I suspect it to already be an issue in the code on main, and that this PR only detects it. But I have never seen this race, nor locally on my workstation or in CI - and I have rebased numberous times triggering a new CI run.
But looking at the stack-traces, I think this piece of code looks suspicious:
https://github.com/aquasecurity/trivy-operator/blob/main/pkg/vulnerabilityreport/controller.go#L79-L80
Setting up two watches against the same GR seems like a bad idea. It should be either v1.CronJob or v1beta1.CronJob right?

Not sure I follow , there is a lot of testdata/fixture and some of suite_test code that can be reused why duplicate ?

I suggest to reuse when we can reuse. The bootstrapping can be reused, but that should be part of the production code and not the test code. Not sure if we will/should reuse the resources.

Not sure I follow , there is a lot of testdata/fixture and some of suite_test code that can be reused why duplicate ?

I suggest to reuse when we can reuse. The bootstrapping can be reused, but that should be part of the production code and not the test code. Not sure if we will/should reuse the resources.

not sure I understand , most of code in suite_test can be reused , do you agree on it ?

No

Setting up two watches against the same GR seems like a bad idea. It should be either v1.CronJob or v1beta1.CronJob right?

Fixing this did the trick, no data races happening anymore. :D


Add tsd to better test type interfaces

What problem do you want to solve?
The way types are checked right now, they're almost like static assertions in the tests. This has a few problems:

went testing you just get typescript error before the test, instead of seeing them alongside other tests
A lot of them require assigning to an empty variable and then voiding it out, making the tests confusing
checking nuanced things like, A is assignable to expression, or A is exactly equal to expression are more cumbersome in the current format.

What do you think is the correct solution to problem?
tsd is a library MS recommends to checking typing of a project. The only downside is it's one more dev dependency.
Will you be able to implement it?
I can, in the short I imagine just migrating the current spec/type tests into their own jtd folder. But I want to make sure this is desirable. Something like this may make testing breaking changes like switching nullable behavior easier to test.

This comment is worrying:

These .test-d.ts files will not be executed, and not even compiled in the standard way. Instead, these files will be parsed for special constructs such as expectError(bar) and then statically analyzed against your type definitions.

Not concerned about the extra dependency, but it might be somewhat inconsistent with tsc in some edge cases (particularly that we push the boundaries here).
Also, is TSC a peer dependency of TSD so it will be locked until TSD is migrated?
I am not sure these extra variables worth the benefits, unless I am missing some benefits... The current way we still test it, even if it is reported not as a test failure, and its guaranteed to be consistent with what the users experience...

I think it's incredibly unlikely (although admittedly possible) to experience different errors from tsd vs typescript, because under the hood it's doing the same thing as typescript, at least from a checking perspective. tsc isn't executing the code, it's building an ast and the checking it to make sure it makes sense, the same thing that tsd is doing.
It doesn't have tsc as a peer dependency, it actually has its own forked version. That does have a slim possibility of producing unexpected results, but I think it's very unlikely. It only tests the compiled declaration files, not the internal typescript. The important distinction here is that typescript users of ajv can try to use any version of typescript anyway. They will run into strange errors if they try to use a version that's too early, e.g. before they added the complex conditional types that ajv currently uses, or if they use a version that has slightly different bugs as typescript doesn't follow semver, although again, it's unlikely.
Ultimately, I think I still think the ease of writing and testing types with tsd is probably worth the risk, but it's not strong, so am also very willing to accept your point that these potential issues and complexities aren't worth it.


Miscellaneous Fixes and Updates

Changes

Added Route 53 Domain Scanning
Updated seed/asset tracking logic
Updated GCP provider key
Updated gitignore
Added CI/CD for building, testing, and linting
Removed GitLab CI

Closing in favor of #15, #16, and #17


Add version history entries for user-facing changes

I found these while looking at the changeset since 0.4.6.

Oh sorry! I didn't realize this was a thing to be done. Thanks!

No problem, it is in the PR template here but we (reviewers/maintainers) should do a better job at actually checking for that.


Tracking Issue for Configuration Reference as per RFC

Description
This issue is created to track the progress of creating a new Configuration Reference according to the Configuration Overhaul RFC.
Context

https://github.com/hyperledger/iroha/issues/2585
https://github.com/hyperledger/iroha/pull/3795

Checklist

[ ] Structure the Configuration Reference main document
[ ] Consult with the team and rename configuration parameters
[ ] Document each configuration parameter
[ ] Document related configuration, such as CLI
[ ] Define Deprecation and Migration policies

Here is a bunch of questions/proposals I have now.
Use human-readable durations
There are plenty of configuration parameters (usually ended with _ms suffix) which defines some duration in milliseconds. It would be much more convenient for users to specify them in a human-readable form, like:

1 second
2 minutes
1 hour 5 minutes 3 seconds
300 ms

[sumeragi]
block_time = "5 seconds" # instead of 5_000

We could implement our own parser, or use something like humantime crate
Note: users might always opt-out and specify a number of milliseconds:
block_time = 5_000

Use human-readable byte sizes
Same as for durations:
[torii]
max_transaction_size = "32kb"

[wsv.wasm_runtime]
max_memory = "600 MiB"

See: humansize - Rust
network, sumeragi.network, p2p_addr etc
There is iroha_config::network::Configuration, which takes [network] namespace in the config. It has only actor_channel_capacity field, and according to my IDE, it is not used anywhere. I guess it was eventually moved to sumeragi.actor_channel_capacity and was not cleared.
I would like to move torii.p2p_addr and sumeragi.actor_channel_capacity into  network or sumeragi.network namespace.
[sumeragi.network] # or just [network]?
address = "localhost:1339"
actor_channel_capacity = 10

address or addr?
There is address in Peer Ids (iroha_data_model::peer::model::PeerId, used in sumeragi.trusted_peers):
[[sumeragi.trusted_peers]]
address = "..."

Should we rename it to addr or use address everywhere? I would choose address.
Split telemetry
Current fields are:

name
url
min_retry_period
max_retry_delay_exponent
file

According to the code, it seems that fields 1..4 are for "substrate" telemetry, and field 5 (file) is for "dev", "future" telemetry. There is no any conflict/dependency between them.
I propose to introduce substrate and file_output (or something like that) namespaces:
[telemetry.substrate]
name = "iroha"
url = "ws://localhost:8080"
min_retry_period = "5 seconds"
max_retry_delay_exponent = 4

[telemetry.file_output]
file = "~/iroha-dev-telemetry"

As for the time we could use pretty standard format like ISO 8601. Though I'm totally fine with that humanize if that's convenient and does not introduce any awkward confusions.
Agree with the byte size
Agree with the network
Agree with address
Agree with telemetry, though I'd suggest to reformat that to a configurable/pluggable telemetry,
I'd avoid
[telemetry.file_output]
enabled = true
file = "~/iroha-dev-telemetry"

or
[telemetry]
mode = "file_output"

[telemetry.file_output]
file = "~/iroha-dev-telemetry"

but we might consider addressing that. Alternatively the telemetry could be represented by a separate config file with other, more complicated structure.

Use human-readable durations
Use human-readable byte sizes

I can't agree more: that'll help users a lot.

I would like to move torii.p2p_addr and sumeragi.actor_channel_capacity into network or sumeragi.network namespace.

Just "network" sounds good to me.

address or addr?

address. People would copy and paste these configs, if those are not generated, and the parameters would be more readable.

I propose to introduce substrate and file_output (or something like that) namespaces

Sounds good

Though I'm totally fine with that humanize if that's convenient and does not introduce any awkward confusions.

In my opinion, it depends on the case that is handled. ISO is applicable if and when there are long intervals and parsing for some of them has the potential to be ambiguous, otherwise it may be more distracting.

We discussed *.actor-channel-capacity parameters with @Erigara. It turned out that they aren't actually used anywhere ATM, and were left in order to not overcomplicate DevOps' life for current deployments. There is a chance that these options will be returned in some future (https://github.com/hyperledger/iroha/issues/3364), but it is very unlikely to happen before Iroha 2.0 release. Thus, I will remove them from the config reference.

Here is a bunch of questions/proposals I have now.
Use human-readable durations
[sumeragi]
block_time = "5 seconds" # instead of 5_000

We could implement our own parser, or use something like humantime crate

I'm very much against this. I think config should be simple. Just using a suffix on the field name is the simplest thing and something everybody will know how to use. Otherwise, the user has to know what the proper format is and we have to implement our own parser for every field, etc. In this case I find that block_time_ms is a solution that gives us all the benefits and is the simplest possible

Note: users might always opt-out and specify a number of milliseconds:
block_time = 5_000

This is definitely a no. There should be no opting out because it's ambiguous. Config fields should be unambiguous

Use human-readable byte sizes
Same as for durations:
[torii]
max_transaction_size = "32kb"

[wsv.wasm_runtime]
max_memory = "600 MiB"

again the same, I would rather like to see max_transaction_size_bytes/max_transaction_size_b/max_transaction_size_b

network, sumeragi.network, p2p_addr etc
There is iroha_config::network::Configuration, which takes [network] namespace in the config. It has only actor_channel_capacity field, and according to my IDE, it is not used anywhere. I guess it was eventually moved to sumeragi.actor_channel_capacity and was not cleared.

remove actor_channel_capacity. We don't use actors anymore

I would like to move torii.p2p_addr and sumeragi.actor_channel_capacity into network or sumeragi.network namespace.
[sumeragi.network] # or just [network]?
address = "localhost:1339"
actor_channel_capacity = 10

just network is preferable

address or addr?
There is address in Peer Ids (iroha_data_model::peer::model::PeerId, used in sumeragi.trusted_peers):
[[sumeragi.trusted_peers]]
address = "..."

Should we rename it to addr or use address everywhere? I would choose address.

let's go with address, but preferably we should use {public_key}@@{address} format

Split telemetry
Current fields are:
1. `name`

2. `url`

3. `min_retry_period`

4. `max_retry_delay_exponent`

5. `file`

According to the code, it seems that fields 1..4 are for "substrate" telemetry, and field 5 (file) is for "dev", "future" telemetry. There is no any conflict/dependency between them.
I propose to introduce substrate and file_output (or something like that) namespaces:
[telemetry.substrate]
name = "iroha"
url = "ws://localhost:8080"
min_retry_period = "5 seconds"
max_retry_delay_exponent = 4

[telemetry.file_output]
file = "~/iroha-dev-telemetry"

I don't see a point


[v1alpha2] Generate CRD validation in Kubernetes 1.11

Ref https://github.com/kubeflow/tf-operator/issues/561#issuecomment-392491392

I wrote a tool to generate the validation from the OpenAPI specification: https://github.com/gaocegege/crd-validation. Generated CRD for tfjob v1alpha2 is https://github.com/gaocegege/crd-validation/blob/master/generated/tfjob-crd-v1alpha2.yaml
While we meet an issue from Kubernetes side: https://github.com/kubernetes/kubernetes/issues/59485#issuecomment-380032718. Kubernetes does not support addtionalproperties while it is needed for map type. Unfortunately, TFRelicaSpec is a map.
The upstream said it will be implemented in 1.11. Maybe we should wait for it. After 1.11 I think we are able to use the tool above to generate validations for all crds in kubeflow community.

This will limit the version of Kubernetes to 1.11.

/assign @codeflitting

what's the plan for crd validation, @codeflitting @gaocegege can anyone of you summarize here?  are we limiting user to only use kubernetes 1.11, or we follow @jessesuen 's suggestion?

@ddysher
We now follow jessesuen@'s suggestion to use the unstructured informer. While this is a WIP issue to use crd validation feature in Kubernetes to validate our CRD. If we do, we need to use k8s 1.11 because of https://github.com/kubernetes/kubernetes/issues/59485#issuecomment-380032718

Would it be possible to only enable CRD validation on K8s 1.11 and newer? So that we could continue to support older K8s? Would that be worth doing?

I think it is not in high priority. We definitely could enable it since it just needs some config in crd yaml file.

@johnugeorge @richardsliu should we try to do this in 0.5?

We should add this in 0.5.

@gaocegege I am not sure if we can do this actually. We are adding support for multiple CRD versions (https://github.com/kubeflow/tf-operator/issues/932), and version-specific schema validation is not yet supported. ETA is k8s 1.16.

Moving this out of 0.5.0.

@richardsliu Now Kubebuilder could generate openAPISchema for CRD, maybe we could take a look at the implementation of kubebuilder.

We have not decided if we are using kubebuilder yet. See discussion here: https://github.com/kubeflow/common/issues/7#issuecomment-481026289

maybe we could take a look at the implementation of kubebuilder.

It's hard to import it which is binding with kubebuilder; in kube-batch/volcano, I build a shadow project to generate CRD openAPISchema and copy back to my project :)

@richardsliu Yeah I saw the comments. We can use the function of validation generation to generate openAPISchema for all our CRDs. As for the other functions in Kubebuilder which requires re-implementation, we should discuss it carefully.

We can run
go run vendor/sigs.k8s.io/controller-tools/cmd/controller-gen/main.go crd --output-dir ./examples/crd/

to use https://github.com/kubernetes-sigs/controller-tools generate CRD with validation for tf-operator. But the group will be tensorflow.kubeflow.org, not kubeflow.org. I think I could maintain a fork or file an PR to controller-tool to avoid tensorflow prefix then use the fork to generate the CRD from our API.

@johnugeorge Should we fix this for v1.0?


Simplify Hello Blockstack tutorial

The Hello, Blockstack javascript tutorial requires installation of Yeoman:
npm install -g yo
yo blockstack

However, this extra installation step can be eliminated by directing npm to use yo during the blockstack app creation, simplifying the process:
npm create yo blockstack

@TerjeNorderhaug Thanks for the suggestion. I'm working on incorporating this.


fix: apply 'patches' after 'buildFromSdist'

Resolves #290

That's a bit surprising. I'd only use buildFromSdist on local packages, and then it doesn't make much sense to add patches.
I suppose it could happen when importing a haskell-flake module from a dependency?
I don't have an opinion on whether patches should be applied before or after sdist. When applied before, the patches can be used to fix the creation of the sdist, whereas if you apply them after the sdist, you can fix the effects of a broken sdist.
I suppose the latter matches what you would do with a package from hackage, so I guess that might be a reason to prefer that.

I'd only use buildFromSdist on local packages

Actually, that makes more sense.


FORTRAN kt3d code

Good day everyone and thanks to the authors for creating such a great program.
I'm trying to use this program in my study data but i can't replicate the demo lesson.  I have installed all the necessary libraries as described in the tutorial. The error occurs during estimation.
estimating in one block
estimate, debug, summary = pygslib.gslib.kt3d(kt3d_Parameters)
The error message i get is as follows:
Traceback (most recent call last):
File "/Users/markjuvert/opt/anaconda3/lib/python3.6/site-packages/pygslib/gslib/init.py", line 1328, in kt3d
output['outwmean']) =__gslib__kt3d.pykt3d(**parameters)
TypeError: 'bhidint' is an invalid keyword argument for this function
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/markjuvert/Desktop/Babbitt/Babbit.py", line 356, in
estimate, debug, summary = pygslib.gslib.kt3d(kt3d_Parameters)
File "/Users/markjuvert/opt/anaconda3/lib/python3.6/site-packages/pygslib/gslib/init.py", line 1332, in kt3d
raise NameError('unexpected error in FORTRAN kt3d code')
NameError: unexpected error in FORTRAN kt3d code

I've tried to trouble shoot the code in the best way i can but i'm stuck here.
Please if anyone can help, I'll be very grateful.
Thanks in advanced!

What version of PyGSLIB are you using? The last version (<IP_ADDRESS>) will require  'bhidint'  in the parameter dictionary. Older versions will use  'bhid'. The keyword changed. Please make sure you are using the right keyword in your code and the last pygslib version.
https://github.com/opengeostat/pygslib/blob/bc421f96bc46381d0ae2a6630acae5d760c2884d/pygslib/gslib/__init__.py#L1287

@markjuvert, I see what you mean now, and thank you for reporting this bug. There was a bug in the parameter dict of kt3d of the demo located in the wiki of pygslib. It is fixed now. Please download the last pygslib version <IP_ADDRESS> (conda package only available for python 3.8) and the demo located at https://github.com/opengeostat/pygslib/wiki/Demos/Demo1.7z and try again.
You can get the last version with conda install pygslib -c opengeostat -c conda-forge


Update set type definition

I noticed some TypeScript errors when pulling v3 into an existing test suite written in TypeScript. Currently, the API docs show passing a Date object or moment Object into set as valid arguments:
MockDate.set(new Date('2/20/2000'));

new Date().toString() // "Sun Feb 20 2000 00:00:00 GMT-0600 (CST)"

MockDate.set(moment('3/30/2000')); // using momentjs

new Date().toString() // "Thu Mar 30 2000 00:00:00 GMT-0600 (CST)"

This PR adds Date and moment.Moment as valid types for the argument to set, and updates how dateObj is being set. It adds an error in an else statement in case the if statement isn't comprehensive.
An alternative would be updating the docs to advise consumers of the library to call valueOf() on the Date and moment objects they pass in.

Thanks for the catch! I just updated the code to accept a Date object as a parameter to set, and I updated the documentation to be MockDate.set(moment().toDate()) to make it clear that the moment object needs to be casted to a Date object.
Published @3.0.2


TRANSACTION WITH MARK

Hello!
MS SQL Server 2019 (and all other versions except 2017) does not insert a row into logmarkhistory table when a marked transaction (BEGIN TRANSACTION WITH MARK) is carried out.

Regards,
Michael Firsov

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 20afbbca-5fed-b938-abf8-fca9f61c1850
Version Independent ID: 78528cda-05db-73c9-ed74-4f11002b9a4c
Content: Restore databases to marked transaction - SQL Server
Content Source: docs/relational-databases/backup-restore/use-marked-transactions-to-recover-related-databases-consistently.md
Product: sql
Technology: backup-restore
GitHub Login: @cawrites
Microsoft Alias: chadam

@MichaelFirsov -- Michael, thank you for your well-researched feedback.
@cawrites -- Cheryl, please look into this issue.

Oh, awfully sorry... it does work, but apparently the problem stems from the documentation: this  page says nothing about any prerequisites to marked transactions, namely, the presence of any backup BEFORE issuing BEGIN TRANSACTIOn WITH MARK statement (the example on that page starts from
"USE AdventureWorks
GO
BEGIN TRANSACTION ListPriceUpdate   ....  " and only after that the backup is taken.
In my case the test database was in the Full recovery mode, but no backups were taken yet.
Futhermore, that same page says

A typical scenario for using marked transactions includes the following steps:
Create a full or differential database backup of each of the related databases.
Mark a transaction block in all the databases.
Back up the transaction log for all the databases.

if the "Mark a transaction block in all the databases." means a user can issue a marked transaction - after ONLY a full or  differential database backup was taken - then it did not work in my environment either: only after the LOG database backup was taken I was able to insert a row into the logmarkhistory table.

Please excuse me once again!
Regards,
Michael Firsov

@MichaelFirsov -- thank you for clarifying, and no problem!

@MichaelFirsov Thank you for this additional information I appreciate you taking the additional time to add these insights.

@MichaelFirsov I reviewed the document you mentioned and it clearly states to make a backup of the transaction log.  The reported page
Typical Scenario for Using Marked Transactions
A typical scenario for using marked transactions includes the following steps:
Create a full or differential database backup of each of the related databases.
Mark a transaction block in all the databases.
Back up the transaction log for all the databases.
Restore database backups WITH NORECOVERY.
Restore logs WITH STOPATMARK.

@cawrites -- Cheryl, thank you for that information.

@please close


Secure Random methods in Java

Make a security folder and explain the secure Random methods in the form .md file and also embed relevant code and explain it properly.

I would like to try to do this :)

@kpencak, are you doing this? If not, i like to do.

@Metalshad0w Yeah, I'm currently finishing that. I would make a PR later today

@dubesar - issue should be closed as the requested document exists here


added shared connection option for worker group

@jondot @gabrieljoelc sharing a connection should be OK. Objections to this? better option names?

did the requested changes

@gabrieljoelc this generally LGTM.

@gabrieljoelc can we get your blessing to merge this? :)

Code looks good but is there a concern that existing applications using sneakers the have a larger number of consumers would have a sudden throughput drop? Here's a good thread discussing this. This answer talks about issues when using a cluster/load balancer and po
throughput dropping. The poster suggests using a connection pool as an alternative.
Should we consider leveraging the connection_pool gem and allowing users to configure the shared connection pool size? We could allow the default configuration to use a connection per worker by default to make it backwards compatible. This would mitigate users experiencing a possible sudden throughput drop in production.

@gabrieljoelc with this PR the default doesn't change: if :share_bunny_connection isn't set, each worker will open its own connection.
We have counterexamples where too many connections is a problem: #291.
Getting connection pooling right is much harder than it sounds so I'm deeply suspicious of pooling libraries by default. We can consider pooling but it's out of scope for this PR.

connection_pool seems to be from the author of Dalli, so it must be good and battle tested. Still, it's out of scope for this PR and we don't really know how well it works with Bunny and automatic connection recovery (in theory it should work OK).

@michaelklishin makes sense. I created #292 as a future alternative.

connection_pool seems to be from the author of Dalli, so it must be good and battle tested.

Also, Sidekiq documentation suggests using connection_pool.
:shipit:

Should we add something to the README or the wiki?

@gabrieljoelc I added https://github.com/jondot/sneakers/wiki/Configuration#rabbitmq-connections a few days ago.


Binding server to a specific IP address

The server may have multiple network interfaces or multiple IP addresses on a same network interface.
On the server configuration, by adding local $IP option, it specifies to bind on the IP address $IP.
Use case example:

the server has 2 public IPs
a web server is listening on the first IP address on TCP/443
an openvpn server is listening on the second IP address on TCP/443

Doesn't work for me:
RESOLVE: Cannot resolve host address: <IP>:1194 (Address family for hostname not supported)

I remember removing this option: https://github.com/angristan/openvpn-install/commit/a7a277e2dc5e6d77a355a4cb60bb85032d724c65


Issue with non-unix line endings

I spent some time trying to understand why I couldn't validate my commit message.
My editor had switched line endings to Windows \r so the regexp was not matched... and it was hard to find why :-)
We should tell what is going on or support other types of line endings.

I need to give you an apology. For some reason, I want watching this repository so I want getting notifications about issues and pull requests. I am so incredibly sorry. Please forgive me. I really feel awful. I hope my unresponsiveness doesn't hinder you contributing more in the future.
As for your specific pull request, I'll give it a closer look soon.

Thanks for the issue @cmalard! I would actually recommend that you configure your editor to use unix style line endings. It's better for everyone if we use the same style.
However, if you'd like to submit a PR to support both I'd be happy to accept it.

In fact I'm on Linux and my editor is configured to use Unix style so I don't figure what happened. Anyway :-)

Would you like to create a PR to fix this or are you ok closing it?

I do not commit myself on making a PR, maybe one day ^^
The issue will stay until then, so it's up to you to close it if you want 0 issue but I do not vote for that ;-)

This package has been deprecated. Please use https://github.com/marionebl/commitlint instead.


add Leet open command to open current question in browser

Closed #54.
Can you please check if the changes make sense? I'll update the docs in the meantime.
I've tested on macos, it works.

Logic should go inside the open function because it's not related to the console

Can you point me to a specific file?

@kawre  fixed all

Changed it back to os.execute since i didn't know that vim.cmd will log the command executed. Ideally it should use plenary jobs since they are non blocking, but for some reason they don't work well on windows.
Thank you for your contribution


Upload Taklimakan Network (TAN) Token

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

[x] Filename in the lowercase format
[x] Image size: 256 by 256 px
[x] Image format: png

Also, you can use these graphics to say that your ERC20 token fully compatible with Trust Wallet (https://trustwallet.com/logo-assets). Tokens will show up automatically once the user receives them.
Feel free to share this on social media and tag Trust Wallet:

Twitter: @trustwalletapp

Facebook: @trustwalletapp


Changes to make Spotify work

For the demo 9/3

Hello,
I'm trying to connect to Spotify but each time, I have a 400 error:
Sorry that did not work
Unexpected HTTP error 400 in request to https://accounts.spotify.com/api/token
HTTP request failed: {"error":"invalid_grant","error_description":"Invalid redirect URI"}
Error obtaining access token HTTPError: Unexpected HTTP error 400 in request to https://accounts.spotify.com/api/token
    at IncomingMessage.<anonymous> (/opt/genie-server/node_modules/thingpedia/dist/helpers/http.js:142:35)
    at IncomingMessage.emit (events.js:326:22)
    at endReadableNT (_stream_readable.js:1241:12)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  code: 400,
Error: Unexpected HTTP error 400 in request to https://accounts.spotify.com/api/token
    at oauthPart2 (/opt/genie-server/node_modules/thingpedia/dist/helpers/oauth2.js:196:19)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
  url: 'https://accounts.spotify.com/api/token',
  detail: '{"error":"invalid_grant","error_description":"Invalid redirect URI"}'
}

Thanks!

Hello, this is not really the right place to discuss it (this PR was long merged), but what version of Genie is this? How did you install?

Oh. sorry. I was writing here after click on an issue. I didn't pay attention. Sorry.
I used the lasted available on Home Assistant add-on repository since I wanted to use it with HA. So, the version use now is edge-3d0c903.

Thank you for the report, that was indeed a configuration issue on our end, it should be fixed now.


Aave v3

[x] Build Aave v3 connector on mainnet, polygon and avalanche
[ ] Deploy and comment Address
[ ] Add on SDK

Deployed on polygon:
Name: AAVE-V3-A
Addr 0x6756Ab45dD4fdFBcb1E19739AAf9cdaDf78ff98a