How to refresh a fragment ?

The user can add or delete the pages himself. In these pages I have an edittext (in fact I have more but it is the same case for all) which is the name of the page. If the user creates a page that it calls "page 1", deletes it and creates another page immediately after it, which it calls "page 2", the fragment will display the data on page 1 ".
onCreate method
    viewPager = (ViewPager) findViewById(R.id.viewpager);
    viewPagerTab = (SmartTabLayout) findViewById(R.id.viewpagertab);
    pages = new FragmentPagerItems(this);
    // here page.add
    adapter = new FragmentPagerItemAdapter(getSupportFragmentManager(), pages){
        @Override
        public int getItemPosition(Object object) {
            return POSITION_NONE;
        }
    };
    viewPager.setAdapter(adapter);
    viewPagerTab.setViewPager(viewPager);

My method for create a new fragment
pages.add(FragmentPagerItem.of(
                                        Pref.getList_points().get(Pref.get_size() - 1).getName(),
                                        FragmentConfigurationPoints.class,
                                        new Bundler().putInt("param1", Pref.get_size() - 1).get()
                                ));
adapter.notifyDataSetChanged( );
viewPagerTab.setViewPager(viewPager);

same issue ,how to solve?

@filol   have you solved this issue?  please tell me .

@ogaclejapan

change FragmentPagerItemAdapter to FragmentStatePagerItemAdapter  solve my issue

@fWX228941  i am changing FragmentPagerItemAdapter to FragmentStatePagerItemAdapter i am still getting the same issue

I have the same issue, how to solve?

		mAdapter = new FragmentStatePagerItemAdapter(getSupportFragmentManager(), items){				@Override
			public int getItemPosition(Object object) {
				return POSITION_NONE;
			}

		};
		mViewpager.setAdapter(mAdapter);


Can you Defer Messages to be retried later?

Query/Question
When using the QueueClient RegisterMessageHandler pattern is there anyway to defer processing of a message to a later time.  The functionality does exist on the MessageReceiver class but It doesn't seem to be accessible.
Why is this not a Bug or a feature Request?
I think it might be  just a case of confusing documentation.
Setup (please complete the following information if applicable):

OS:Windows 10
IDE :Visual Studio 2019
4.1.1 runnning in full .net framework

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Query Added
[x] Setup information Added

/cc @binzywu

@BrettBailey ,
Once you defer a message, the way to get that message back is to use MessageReceiver.ReceiveDeferredMessage API. By design, QueueClient doesn't have this method, and there is no plan to support receiving a single message using QueueClient. Hence there is no need to support deferral of messages using QueueClient.
If you need advanced functionality like message deferral, we suggest you directly using the core pieces like MessageReceiver and perform the operation. You should be able to defer the message and also receive it there.

@BrettBailey
Thanks for raising this issue. When you defer a message, you need to store the sequence number on the receiver side so that you can selectively receive that message at a later time.
Due to this, it is a method on the MessageReceiver and not on each individual message.
Please let us know if there are any follow up questions.


Audit and improve component behavior on mobile

😯 Problem to Solve
The SLE LIMS app has a requirement that it "work on mobile" but we haven't designed Nimble components with this in mind. This issue is a starting point to track doing the work of auditing components and to track known issues.
Known issues

Can't access tabs if the screen width is too narrow to see all items. Should we allow horizontal scroll? Show some arrow affordances to indicate that tabs are overflowing?
Breadcrumb wraps its content if the screen width is too narrow to see all items. This looked odd to me: I think I expected it to clip, possibly with ... at the start or the middle.
Drawer has a fixed width which is often wider than a mobile screen

💁 Proposed Solution

The current plan is for @fredvisser to check with SLE POs on the priority of this and then put it on our designers' backlog as appropriate.

Related: #1436


Document Running Process

Create Documentation for the complete steps with screenshots on how to download the repository from GitHub, to building the apk, to uploading the apk to the quest.

Can be found in the Wiki


请问minicpm-llama3-v-2_5可以支持哪些量化措施，支持awq量化吗

是否已有关于该错误的issue或讨论？ | Is there an existing issue / discussion for this?

[X] 我已经搜索过已有的issues和讨论 | I have searched the existing issues / discussions

该问题是否在FAQ中有解答？ | Is there an existing answer for this in FAQ?

[X] 我已经搜索过FAQ | I have searched FAQ

当前行为 | Current Behavior
No response
期望行为 | Expected Behavior
No response
复现方法 | Steps To Reproduce
No response
运行环境 | Environment
No response
备注 | Anything else?
No response

awq的量化我们正在对接，积极跟autoawq沟通


Add landing pages for before and after the survey period

These would be variation of the HomePage component, with a different text before or after the survey's official date. There can be a possibility also to configure whether it is still possible to fill the survey or not. If not, the participant's login page should not be navigable either.

This would reduce the necessity for survey admins to be available to setup the survey on the very days of the beginning and end for surveys with firm dates.

Great idea. Can we make sure that an admin (a developer) can still test the survey? I like to go test the survey in production for some cases where it could break in production (for example, I want to make sure the Google Maps API is working).
Also, there were a few surveys that the survey date kept changing. We need to find an easy way of changing the date. Maybe in the admin platform?


[3rd Party Demo] A cool 'Space Computer' demo of Skia4Delphi by Ian Barker!

Need not to say Skia4Delphi  is a great project, but since it's new there are not much examples yet. And today I discovered one which is very cool with animated effects!
It's by Ian Barker who is a EMBT MVP.
checkdigits/spacecomputer

I think it's pretty cool - but then I'm biased! 😉

The official conference page is here: https://delphicon.embarcadero.com/talks/move-your-ui-to-the-23rd-century-building-a-data-dashboard-with-delphi-and-skia-engage/
I will try and make the original video available to the Skia4Delphi team at some point.
(I'm tagging @viniciusfbb, @paulocesarbot and @renanborgez on this message for visibility).

Ah - the YouTube replay video is here: https://www.youtube.com/watch?v=jWP5oeEHyh0

Fantastic presentation! It could not have been better. 👏🏻👏🏻👏🏻
I would like to add the link to the demo and the presentation in the next commit, if you allow me of course.
Again, congratulations Ian Barker(@checkdigits)! The best presentation of the conference 😉

Thanks, all I did is show the hard work you guys put in. 😃
I'm happy for you to add the links and use them any way which works for you. 👍

Added to documentation!


Merging in missing functionality from Cadair/jupyter_environment_kernels

There are currently two implementaiton of the functionality added with this package: this here and https://github.com/Cadair/jupyter_environment_kernels/tree/master/environment_kernels. I see it that this implementation will gain a lot of users because of the integration with anaconda and its installed default packages.
On the other hand, the "other" implementation has some features which I'm missing in this implementation.

Proper activating the envs (e.g. getting a proper PATH even when having activate.d scripts)
Only add kernel if the actual kernel functionality is in the env
virtualenv support

While I think that the first two will eventually be accepted/ added here, I would like to discuss / ask if you would consider adding virtualenv functionality.
I'm willing to add all three things by porting them from https://github.com/Cadair/jupyter_environment_kernels/
CC: @Cadair
[Just to make sure: I think this package also has a few things better than the other one: tests, an automatic installer, ... :-) ]

I think the hard point is the virtualenv support... one crazy thing coming to my mind is to make virtualenv support and "extension" over nb_conda_kernels... some kind of plugin that can be added to enable virtualenv if the user wants that... but otherwise keep the main package only with conda env support.
In any case, we can also discuss support in the nb_conda_kernels itself, my first reaction would be no... also we should change the name if we agree to do it :stuck_out_tongue:
@bollwyvl thoughts?

If support for "other" envs is added, the actual support for them is probably two more function (one to search for them, one to make the "activate" work)  and the config endpoint (where to look for them) in the end.
I would really appreciate it if there would only be one project with the combined feature set, so that work is not wasted to implement the features in the other project each time... I also wouldn't mind porting the features of this project over to the other one, but I guess it's better to use this here as this gets more exposure due to anaconda inclusion... :-)

If support for "other" envs is added, the actual support for them is probably two more function (one to search for them, one to make the "activate" work) and the config endpoint (where to look for them) in the end.

Well... if that is the case, I would probably migrate from "no" into "maybe"... :wink:
One of the things I wondering is which is the impact of a conda-scoped extensions for someone using virtualenvs (and then probably not using conda)? Also, if you bring virtualenv support I guess I can ask you to support it in the long term, am I right? :wink: (the real thing is that I don't want to fight again with virtualenv if I have something better like conda envs, jeje).

I would really appreciate it if there would only be one project with the combined feature set, so that work is not wasted to implement the features in the other project each time...

Yes, I agree.. if possible, we should end up with just one.

Sorry, late to the party!

Proper activating the envs (e.g. getting a proper PATH even when having activate.d scripts)

yeah, this is important! I considered the "generate me a fake shell command" approach, but do wonder if this is a thing that we want as a separate activity/package. In the days of yore, there was a conda run -n foo -- cmd, but I've seen some other approaches. Endgame would be to get this in conda itself, as it is such a common activity, and so fraught with peril, as we have seen with the 4.x line.

Only add kernel if the actual kernel functionality is in the env

Also yeah. I had tried this on a development branch, but found it even slower than looking for binaries. But it is the right way.

virtualenv support

I was a virtualenv user for many years, loved what it did for me. But Anaconda isn't going to support anything that touches virtualenvs, I'd wager.
Perhaps we should think about how to generalize the capability (potentially into something that doesn't do anything other than the super defaults) then extend for multiple implementations.
Today there is conda, virtualenv and then pyenv... but then the raft of things for other langs like nvm, rvm and who-knows-what-else.
Add to this the capability of something like remotekernel or rk, and we'll quickly end up where someone can't have what they want to get the work done on a project that needs multiple approaches without a lot of environment switching... which is exactly what we're trying to avoid.
It has been mentioned several times that at least in the near future, environment management isn't going to show up in Jupyter itself, so it is indeed up to us. And, as it is, one can only have one KernelSpecManager, so we have to get along.
So strawman, based on everyone's suggestions above:
nb_env_kernels (or whatever) would be the high-level package, and actually be a serverextension and nbextension, providing the UI for searching through kernels, refreshing the list of kernels, etc. (which is why all the caching noise now)
It would expose and read (at startup) an entry_point (i suppose we could use the config system, but I think this might be more appropriate here) that would use the key to build up the kernel string and any other things it might need.
All the default kernel names would get grandfathered in without fanciness, as we've learned we can't go messing with those for various reasons. It would handle all the caching, spawning, etc. so that it is done in a consistent way (and all the handles get closed properly on shutdown, etc. which is why i have shied away from it thus far).
Then, nb_conda_kernels (or whatever) would be a small entry_point that depended on nb_env_kernels... probably just one class, with some API that we define. Aside from discover, we'd probably want to add some stuff like an icon to pretty up and distinguish between a conda env and a virtualenv or whatever. If we can avoid them being nbextensions/serverextensions, that would be great. Anyhooo... nb_conda_kernels (and by extension, nb_env_kernels) would end up in the Anaconda distribution, and anybody would be free to build them their own selves elsewhere.
Thoughts?

If an plugin architecture is what gets this accepted into this project, I'm all for it...

Hey all, been meaning to get to this for a while...
I still haven't had a detailed look at the code in this repo, so if I misunderstand anything I do apologise. As far as I can tell there is a hunk of overlap between this and the implementation in my repo, mainly, it provides a kernelspecmanager and calls conda to find envs then generates the specs etc. In my repo there is much more configuration options and functionality, I actually started my project to just look for directories, I would point it at the conda env root and it would look inside /bin for all the envs, which is why adding virtualenv support was easy * . Also we have the full environment sourcing which @janschulz  added etc. This repo has much more robust tests and other important things.
I love the idea of one package to provide the KernelSpecManager and then an entry point to register ways of finding the kernels. This also seems much more like something that would get merged into Jupyter than something conda or virtualenv specific. I would suggest that if we want to go that way we make a new repo (probably a modification or fork of this one) which we aim to be completely platform (conda, virtualenv) independent and then re-write a plugin for that approach for conda and another one for virtualenv (This maybe better taken from my repo as we have the path sourcing stuff etc).

Aside, I actually use the directory finding functionality myself because I have Jupyter installed via my linux system python and then it finds the conda envs by looking for the paths as the system python doesn't have conda in the path, so from my perspective this is an important feature!!

@Cadair thanks for stopping by!
All good things. Glad you like the basic approach.
Perhaps what we are really pushing for is, in the name of reproducibility, provider-agnostic environment awareness across the different components that do kernel stuff with notebooks: at present, I think that means:

notebook (which we've now done two ways)
nbconvert (which would need some help)
kernel_gateway (haven't even read the code)
nbformat this name-based thing is for the birds...

initially, could be something something simple, URI-based (a la env://<entry_point>/<env_name>)

could be extended to include packages env://<entry_point>/<env_name>?<what you call things>=<a thing>,<another thing>

but really, having the option to capture the entire env as actual data would be better:

too bad all these package managers have their own, independently Turing-complete specifier patterns...

{"type": "<entry_point>",
 "<what you call things>": ["<a thing> <som version thingy>"],
  "<where you get things>": ["<some place>"]}

probably nbsomethingelse that I'm not thinking of right now

BONUS: I think the remote kernel case is very interesting as well... remains to be seen whether we try to lump that under this umbrella, but i feel like if we pushed for a real, non-metadata-wild-west addition to nbformat, we'd want to cleanly add all the "you ain't running in kansas anymore" stuff in one go. But now we're getting into binder/kapsel territory, but inverting it, as both of those think about a notebook that lives in some box, whereas this says the notebook actually can contain the box.
Perhaps the path is:

Demonstrate an extensible, user-friendly, pip/conda-packageable KernelSpecManager + serverextension + nbextension for empowering the user to make good, reproducible decisions around how they use kernels

don't try to install things in envs, though... whole other ball of wax

at least two implementations of entry_pointy KernelSpecFinders (or whatever we call them)

or config'd, but, buh, no official CLI-friendly API for anything but server/nb extensions at present, and really don't want to start this kind of work without conf.d support

run it through the incubator/JEP process, and perhaps get the behavior of the upstream KernelSpecManager changed, as well as support from nbconvert --execute.

I think we have a general agreement about this... I like the steps described by @bollwyvl, and if we can get some help from @janschulz  and @Cadair :wink:, I think we can start doing some work on this direction and have something working relatively quick.
Maybe we need to start with the incubator/JEP proposal as the first steps, thoughts?

The current implementation of the kernel manager class is probably much what you have in mind to submit upstream.

remove the virtualenv/conda related knobs
add an "extension point" for the additional functions which provide the additional kernel specs (what is now the ENV_SUPPLYER variable)
inline the code in the overwritten methods in the original KernelSpecManager to take these additional kernel specs into account
maybe add the blacklist/whitelist functionality (but this could also go to the conda/virtualenv classes itself)

Then a user could install the new "kernel spec provider" python package and add these function in the config instead of overwriting the KernelSpecManager itself.
Still doesn't solve the problem with nbconvert not using it...

I think prototyping up a base KernelSpecManager and showing that the plugin system can work would be a good start, then moving to a JEP.
As far as the plugins go, I could see a situation where config would be optional, if the base SpecManager auto loaded all plugins and ran with default settings we could make it so most people wouldn't need to do any config.

prototyping up a base KernelSpecManager

Here's a strawman (since i could test it easily) of using entrypoints in the current nb_conda_kernels code base:
https://github.com/bollwyvl/nb_conda_kernels/tree/feature/entry_points
Obviously we'd want to bring over much more of the jupyter_environment_kernels stuff...

make it so most people wouldn't need to do any config

Agreed.
As I had mentioned, as we talk about config, etc. the UI will definitely come up. @damianavila had pointed at the "nested submenu" approach, but this is generally regarded as a bad idea, and has been deprecated in bootstrap... not sure if jupyterlab has brought it over, but let's think a bit outside that, perhaps... here's a rehash of a concept I did earlier, but lost:

Though i'll have to see if we'd have to do too much crazy stuff by putting unexpected things in...

I like what I saw in https://github.com/bollwyvl/nb_conda_kernels/tree/feature/entry_points
So the entrypoint for a kernel spec provider is basically a provider.find_kernel_specs() which returns a dict <name> -> <kernelspec instance> which then gets "muched" into <spec-finder-name>-<name> -> <kernelspec instance>
So what's missing:

Make it a PR on the original kernel manager class
caching: IMO it should be done in the manager and done with threads so that there is no performance penalty when the stuff is expired
nameing: kernels from different entry point contributor should neverthless get similar names.
discuss with upstream how to display it in the UI

My preference would be that the manager would do the naming and would reset the kernel spec name to {provider}-{language}-{name} and the display in a similar way (I would prefer a config entry, so that I can name my env kernels with a ~ in front so that they are sorted last). Unfortunately this "renaming" makes only sense if e.g. in the conda case, the r and python finder would be two different entry point contributor as otherwise the names would overlap (if one env would supply two kernels).

In https://github.com/jupyter/nbformat/issues/81 upstream talks about some one pain point of environment kernel managers when used with nbconvert. It might be nice to chime in there (and get the proposal going again :-) ).

Thanks the ping! I was aware but I did not have time to chime in yet.

It might be nice to chime in there (and get this proposal going again :-) ).

I agree! :wink:

@jankatins, it looks like there is a bit of duplicated effort between your work and ours (as well as ample reason for yours to continue, e.g., virtualenv support). I do have a fix for some of the key issues in #80 that I'm hoping to see merged in.
I also took note of your work to update your package to the new Jupyter 6.0 format. I'm inclined to think that Anaconda—or more precisely, the maintainers of conda, no matter what the affiliation—ought to take a strong interest in maintaining conda environment support for jupyter, hence I'm inclined to favor keeping nb_conda_kernels around. But I could be swayed...
What I do know is that even if nb_conda_kernels were to be deprecated, it would be important to get these fixes in (in my view) beforehand.

I've merged https://github.com/Anaconda-Platform/nb_conda_kernels/pull/80 now, so environments are constructed directly from their native kernelspecs, and full activation is performed.


[AutoDiff] Teach AD to differentiate functions that capture mutable variables

Previously AD could not differentiate functions that capture mutable variables because of a bug in checkpointing (resolved here), and because end-scope instructions such as end_access are not correctly emitted in adjoint blocks.
This patch makes the rematerialization cloner record scope-marking instructions such as begin_access and alloc_stack after cloning, and the adjoint emitter will emit a corresponding end-scope instruction in the adjoint block of the parent block of the begin-scope instruction.
Resolves SR-9173.

@swift-ci please test tensorflow

@swift-ci please test tensorflow


fix: simplify field validator type

Adding StandardSchema removed type inference on validators with plan functions, the type might be simplified and seems to also fix the issue.
Note: type tests as the following were still passing on the repo, while the exact same configuration was failing on the examples in the docs, I still don't know why.

Superseded by #1076


Transactions Tab: UI Changes

[ ] Transactions tab: design: https://github.com/horizontalsystems/bank-wallet-ios/issues/188
[ ] send confirmation controller minor change (design attached)

[ ] pending transactions should standout.
[ ] reverse placements of crypto with base currency
[ ] use "sending" text with filled/empty bar icons on all pending transactions to indicate transaction confirmation status

on pending transactions: date and timestamp overlaps with pending icon and confirmation bars, respectively


fix: pass if table is already removed on upgrade

SUMMARY

Looks like if you try to run the migrations but the sl_ tables don't already exist the migrations will fail. This will just pass the upgrade check if the table doesn't already exist.

Added a has_table function to return a boolean if the table exist or not
Updated drop_fks_for_table to handle sqlite in the function

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[X] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

Not a breaking change since this handles the case where if migration has already been run gracefully.


Analysis cleaner

This is coming late and unfinished, its a bit of a mess right now.
I'm going to complete the outstanding ingestion tasks today and return to this later today. If either of you @MattWellie @illusional have time to take a look and provide any feedback that's much appreciated

Codecov Report
Base: 66.99% // Head: 66.99% // No change to project coverage :thumbsup:

Coverage data is based on head (d90f377) compared to base (fdc8cf1).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##              dev     #402   +/-   ##
=======================================
  Coverage   66.99%   66.99%
=======================================
  Files          72       72
  Lines        5793     5793
=======================================
  Hits         3881     3881
  Misses       1912     1912

Impacted Files
Coverage Δ

sample_metadata/parser/generic_parser.py
82.31% <ø> (ø)

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

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

Thanks a lot for the feedback both @illusional @MattWellie.
The script now seems to be working mostly as it should, with room for improvements. I think the outputs could be better than just printing/logging. Also not really sure how to implement deletion of objects from Metamist and honestly a bit scared to try :^)
A few key points:

20,977 analysis entries found with get_seqr_projects()

16,467 entries are duplicates

= 4,510 non-duplicate entries

Most duplicated path is in acute-care with 38 total entries pointing to it

2,658 "valid" entries that actually lead to a file in the gcp cloud

(I feel like something is going wrong here in validate_paths, since 4510-2658=1852 which is not the count of invalid paths)

Hey @EddieLF, are how many are entries for which the files don't exist anymore, and are any samples left without attached crams?

Hey @EddieLF, are how many are entries for which the files don't exist anymore, and are any samples left without attached crams?

@illusional of the 4,510 detected non-duplicate paths, only 2,875 are actually not duplicates once their cram output paths have been parsed by the json part. I will need to change the script to remove the duplicates after this step too.
Of these 2,875 entries, 217 have paths which lead to files that don't exist anymore. I also picked up 3 crams in the subdirectories searched which have no analysis entry pointing to them.
Not sure what you mean about samples without attached crams, are you suggesting to use the sample api to do a similar audit of sample entries?

@illusional just pushed a change which looks at the samples that don't have an attached cram, I'm seeing just 25 total samples where the cram from the analysis output is missing.
Thoughts on dumping some of this output into CSVs? We could have one for duplicate analysis paths, one for invalid analysis paths, one for duplicate samples, one for samples without attached crams, etc.
Would having those flat files created by running the code be useful for updating the Metamist entries?


Search Request validation

Where should the request get validated?

Lets make a sequence diagram!

An idea for validating user input: Since SearchRequest contains all of the user input, we could have a SearchRequestBuilder which will be in charge of validating user input, and either return a SearchRequest object or an error.

@rraub As for the sequence diagram, I made a diagram here. I'm just learning UML, so it's basic. But I think I put enough information in the models I made.

@kenprice looks good, these diagrams illustrate nicely the basic flow of the application. One of the nice features of these diagrams is the discussions they can bring out: For example when should the execution not follow this exact path? (validation errors)


unify ethereum revert/throw/etc error expectations

🎉 Description
We have a bunch of different error handlers for solidity-specific things. They should just be one assertion function that accepts a configuration options hash if and only if the caller needs to be more specific than just "it fails".
Maybe something like:
await expectFailure(
   myPromise,
   { onlyRevert: true }
)

We need to

write this assertion

update literally everywhere in the codebase that uses the other styles

[x] 📈 This is a feature request.

Bonus points for making it compatible with "should"-style assertions.

See #938, #917 for recent issues to keep in mind.

Also the current assertRevert doesn't work when the revert happens during the contract deployment.
Example: await assertRevert(Contract.new(args));


can aegis be configured to work on a non-kubernetes environment with reduced functionality maybe?

As long as you have SPIRE running it should not require Kubernetes that much.
The only thing I can think of is securing access to Aegis Sentinel will be harder in that case.

Not sure to keep this in scope.
Punting it to 1.x.

Yes, it can.
Created an issue about it.
Closing this one.

Though “yes, it can” does not necessarily mean “yes, it makes sense to implement it”, or “yes, we should prioritize this feature” :) — I still need to think about it.


[5.0] Fix reapplying scopes in whereHas callback

This fixes the problem of reapplying global scopes constraints if you try to remove them in the whereHas callback - take SoftDeletes as an example:
// Basic has call - 'deleted_at is null' applied by default
>>> User::has('posts')->toSql()
=> "select * from `users` where (select count(*) from `posts` where `posts`.`user_id` = `users`.`id` and `posts`.`deleted_at` is null) >= 1"

// Now let's remove the 'deleted_at is null' constraint in the callback
>>> User::whereHas('posts', function ($q) { $q->withTrashed(); })->toSql()
=> "select * from `users` where (select count(*) from `posts` where `posts`.`user_id` = `users`.`id`
and `posts`.`deleted_at` is null // it shouldn't be here anymore
) >= 1"
>>>

This happens because mergeWheresToHas is applied after user-provided callback.

5.0 is closed for non-security fixes, sorry.


Move llm-chatbot to generate api

CVS-142802

@sbalandi, last comment, can we add a reference on new notebook in llm-chatbot.ipynb?

added, also i have added link to the read.me


[Removal]:

Hotspot Name
colossal-mercurial-liger
Hotspot b58 Address
112CXSK5AoAGr4wFPFTV8CmVe1azw34WKjHumeubkbqSeXYuqedk
Discord Handle
No response
Hotspot Manufacturer
Heltec
Removal Reason
Real deployment
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information

We have taken into account this removal request in the next iteration of the denylist. It may take some time before it's processed. This is an automated comment due to the volume of addition and removal requests. A future tool is in the works to provide more insight into the analysis approach made by the Helium team and community members that maintain this list.


HADOOP-18408. ABFS: Setting correct value of requireRenameResilience for nonHNS configuration

This commit ignores the testResilienceAsExpected test in ITestAbfsRenameStageFailure.
ITestAbfsRenameStageFailure fails for the NonHNS SharedKey configuration -
[ERROR] ITestAbfsRenameStageFailure>TestRenameStageFailure.testResilienceAsExpected:126 [resilient commit support] expected:<[tru]e> but was:<[fals]e>
The check for whether ResilientCommits are possible depends on whether etags are preserved in rename or not. If not, an exception is thrown which leads the ResilientCommitByRename flag to remain set to null and ultimately causes the test failure.
In case of nonHNS accounts, as etags are not preserved in rename, the test run is not valid. Hence for this particular configuration the test has been ignored.

:::: AGGREGATED TEST RESULT ::::
HNS-OAuth
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   TestAbfsClientThrottlingAnalyzer.testManySuccessAndErrorsAndWaiting:171->fuzzyValidate:49 The actual value 11 is not within the expected range: [5.60, 8.40].
[INFO]
[ERROR] Tests run: 107, Failures: 1, Errors: 0, Skipped: 2
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   ITestAzureBlobFileSystemLease.testAcquireRetry:329 » TestTimedOut test timed o...
[INFO]
[ERROR] Tests run: 567, Failures: 0, Errors: 1, Skipped: 54
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ITestAbfsTerasort.test_110_teragen:244->executeStage:211->Assert.assertEquals:647->Assert.failNotEquals:835->Assert.fail:89 teragen(1000<EMAIL_ADDRESS>failed expected:<0> but was:<1>
[ERROR]   ITestAbfsFileSystemContractRename>AbstractContractRenameTest.testRenamePopulatesFileAncestors:278->AbstractContractRenameTest.validateAncestorsMoved:291->AbstractFSContractTestBase.assertPathDoesNotExist:330->Assert.fail:89 src path should not exist: unexpectedly found<EMAIL_ADDRESS>as<EMAIL_ADDRESS>isDirectory=false; length=256; replication=1; blocksize=268435456; modification_time=1660824124000; access_time=0; owner=sreeb; group=sreeb; permission=rw-r--r--; isSymlink=false; hasAcl=false; isEncrypted=false; isErasureCoded=false}; version='0x8DA81117795CD00'}
[INFO]
[ERROR] Tests run: 332, Failures: 2, Errors: 0, Skipped: 43
HNS-SharedKey
[INFO] Results:
[INFO]
[WARNING] Tests run: 107, Failures: 0, Errors: 0, Skipped: 2
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   ITestAzureBlobFileSystemLease.testAcquireRetry:329 » TestTimedOut test timed o...
[INFO]
[ERROR] Tests run: 567, Failures: 0, Errors: 1, Skipped: 54
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ITestAbfsTerasort.test_110_teragen:244->executeStage:211->Assert.assertEquals:647->Assert.failNotEquals:835->Assert.fail:89 teragen(1000<EMAIL_ADDRESS>failed expected:<0> but was:<1>
[INFO]
[ERROR] Tests run: 332, Failures: 1, Errors: 0, Skipped: 43
NonHNS-SharedKey
[INFO] Results:
[INFO]
[WARNING] Tests run: 107, Failures: 0, Errors: 0, Skipped: 2
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ITestAbfsRestOperationException.testCustomTokenFetchRetryCount:96->testWithDifferentCustomTokenFetchRetry:123->Assert.assertTrue:42->Assert.fail:89 Number of token fetch retries (9) done, does not match with fs.azure.custom.token.fetch.retry.count configured (5)
[INFO]
[ERROR] Tests run: 567, Failures: 1, Errors: 0, Skipped: 276
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ITestAbfsTerasort.test_110_teragen:244->executeStage:211->Assert.assertEquals:647->Assert.failNotEquals:835->Assert.fail:89 teragen(1000<EMAIL_ADDRESS>failed expected:<0> but was:<1>
[ERROR] Errors:
[ERROR]   ITestAbfsJobThroughManifestCommitter.test_0420_validateJob » OutputValidation ...
[ERROR]   ITestAbfsManifestCommitProtocol.testCommitLifecycle » OutputValidation abfs:/... [ERROR]   ITestAbfsManifestCommitProtocol.testCommitterWithDuplicatedCommit » OutputValidation [ERROR]   ITestAbfsManifestCommitProtocol.testConcurrentCommitTaskWithSubDir » OutputValidation [ERROR]   ITestAbfsManifestCommitProtocol.testMapFileOutputCommitter » OutputValidation ... [ERROR]   ITestAbfsManifestCommitProtocol.testOutputFormatIntegration » OutputValidation [ERROR]   ITestAbfsManifestCommitProtocol.testParallelJobsToAdjacentPaths » OutputValidation [ERROR]   ITestAbfsManifestCommitProtocol.testTwoTaskAttemptsCommit » OutputValidation ...
[INFO]
[ERROR] Tests run: 332, Failures: 1, Errors: 8, Skipped: 47
AppendBlob-HNS-OAuth
[INFO] Results:
[INFO]
[WARNING] Tests run: 107, Failures: 0, Errors: 0, Skipped: 2
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   ITestAzureBlobFileSystemLease.testAcquireRetry:329 » TestTimedOut test timed o...
[INFO]
[ERROR] Tests run: 567, Failures: 0, Errors: 1, Skipped: 54
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ITestAbfsTerasort.test_110_teragen:244->executeStage:211->Assert.assertEquals:647->Assert.failNotEquals:835->Assert.fail:89 teragen(1000<EMAIL_ADDRESS>failed expected:<0> but was:<1>
[INFO]
[ERROR] Tests run: 332, Failures: 1, Errors: 0, Skipped: 43
Time taken: 60 mins 59 secs.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 42s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 27s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
26m 19s

trunk passed

+1 :green_heart:
compile
24m  4s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
20m 45s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
4m 19s

trunk passed

+1 :green_heart:
mvnsite
3m  1s

trunk passed

+1 :green_heart:
javadoc
2m 41s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 30s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m  3s

trunk passed

+1 :green_heart:
shadedclient
22m 52s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 34s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 24s

the patch passed

+1 :green_heart:
compile
24m  5s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
24m  5s

the patch passed

+1 :green_heart:
compile
20m 40s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
20m 40s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m 13s

the patch passed

+1 :green_heart:
mvnsite
2m 59s

the patch passed

+1 :green_heart:
javadoc
2m 32s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 28s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m 16s

the patch passed

+1 :green_heart:
shadedclient
25m 20s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
7m 31s

hadoop-mapreduce-client-core in the patch passed.

+1 :green_heart:
unit
3m  5s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
1m 33s

The patch does not generate ASF License warnings.

232m 59s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4758

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux ae7be0d2f606 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk /<PHONE_NUMBER>533c90f7dab85d20ffb31497416587

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/1/testReport/

Max. process+thread count
1567 (vs. ulimit of 5500)

modules
C: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core hadoop-tools/hadoop-azure U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

The latest commit passes the testResilienceAsExpected test in ITestAbfsRenameStageFailure. The requireRenameResilience value is correctly set to False for a nonHNS account, instead of True. This is valid, as etags are not being preserved for nonHNS accounts, it is expected that resilient commits would not be possible. Hence, the requirement is changed to False.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 36s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 18s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
25m 12s

trunk passed

+1 :green_heart:
compile
23m  5s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
20m 45s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
4m 26s

trunk passed

+1 :green_heart:
mvnsite
3m  0s

trunk passed

+1 :green_heart:
javadoc
2m 41s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 30s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m  4s

trunk passed

+1 :green_heart:
shadedclient
22m 22s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 33s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 21s

the patch passed

+1 :green_heart:
compile
22m 20s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
22m 20s

the patch passed

+1 :green_heart:
compile
20m 37s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
20m 37s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m 14s

the patch passed

+1 :green_heart:
mvnsite
2m 58s

the patch passed

+1 :green_heart:
javadoc
2m 33s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 30s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m 14s

the patch passed

+1 :green_heart:
shadedclient
22m 33s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
7m 34s

hadoop-mapreduce-client-core in the patch passed.

+1 :green_heart:
unit
3m  5s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
1m 33s

The patch does not generate ASF License warnings.

225m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4758

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux c08412a67025 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / aa9db0257b6fa13ec8f7ad9c0695d53b28e1baf0

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/2/testReport/

Max. process+thread count
1322 (vs. ulimit of 5500)

modules
C: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core hadoop-tools/hadoop-azure U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 49s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m  3s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
29m 44s

trunk passed

+1 :green_heart:
compile
38m 25s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

-1 :x:
compile
21m 51s
/branch-compile-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root in trunk failed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.

-0 :warning:
checkstyle
1m 21s
/buildtool-branch-checkstyle-root.txt
The patch fails to run checkstyle in root

+1 :green_heart:
mvnsite
3m 44s

trunk passed

+1 :green_heart:
javadoc
2m 46s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 22s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m 35s

trunk passed

-1 :x:
shadedclient
26m 29s

branch has errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 32s

Maven dependency ordering for patch

-1 :x:
mvninstall
0m 31s
/patch-mvninstall-hadoop-mapreduce-project_hadoop-mapreduce-client_hadoop-mapreduce-client-core.txt
hadoop-mapreduce-client-core in the patch failed.

-1 :x:
compile
0m 39s
/patch-compile-root-jdkPrivateBuild-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>.txt
root in the patch failed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>.

-1 :x:
javac
0m 39s
/patch-compile-root-jdkPrivateBuild-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>.txt
root in the patch failed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>.

-1 :x:
compile
0m 31s
/patch-compile-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root in the patch failed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.

-1 :x:
javac
0m 31s
/patch-compile-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root in the patch failed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 29s
/buildtool-patch-checkstyle-root.txt
The patch fails to run checkstyle in root

-1 :x:
mvnsite
0m 31s
/patch-mvnsite-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

+1 :green_heart:
javadoc
1m  5s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
1m  9s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

-1 :x:
spotbugs
0m 30s
/patch-spotbugs-hadoop-mapreduce-project_hadoop-mapreduce-client_hadoop-mapreduce-client-core.txt
hadoop-mapreduce-client-core in the patch failed.

-1 :x:
spotbugs
0m 30s
/patch-spotbugs-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

+1 :green_heart:
shadedclient
33m 31s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
7m 35s

hadoop-mapreduce-client-core in the patch passed.

+1 :green_heart:
unit
2m 10s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 46s

The patch does not generate ASF License warnings.

194m 33s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4758

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux dffb019d964c 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 2eab3018ce63bb2776578046cf3c7405330f9cfd

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/3/testReport/

Max. process+thread count
1085 (vs. ulimit of 5500)

modules
C: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core hadoop-tools/hadoop-azure U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 49s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
11m 23s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
31m 16s

trunk passed

+1 :green_heart:
compile
25m 14s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
23m 14s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
4m 43s

trunk passed

+1 :green_heart:
mvnsite
2m 27s

trunk passed

+1 :green_heart:
javadoc
2m 11s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
1m 52s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m 35s

trunk passed

+1 :green_heart:
shadedclient
34m 56s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 46s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 15s

the patch passed

-1 :x:
compile
10m 14s
/patch-compile-root-jdkPrivateBuild-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>.txt
root in the patch failed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>.

-1 :x:
javac
10m 14s
/patch-compile-root-jdkPrivateBuild-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>.txt
root in the patch failed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>.

-1 :x:
compile
0m 45s
/patch-compile-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root in the patch failed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.

-1 :x:
javac
0m 45s
/patch-compile-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root in the patch failed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
5m 59s

the patch passed

+1 :green_heart:
mvnsite
2m 17s

the patch passed

+1 :green_heart:
javadoc
1m 26s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
1m 22s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 56s

the patch passed

-1 :x:
shadedclient
28m 54s

patch has errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 26s
/patch-unit-hadoop-mapreduce-project_hadoop-mapreduce-client_hadoop-mapreduce-client-core.txt
hadoop-mapreduce-client-core in the patch failed.

-1 :x:
unit
0m 41s
/patch-unit-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

+0 :ok:
asflicense
0m 38s

ASF License check generated no output?

205m  9s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4758

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux ea4c7b74ea42 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 977b4554da2184f40c3c913a6ed8218de539e792

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/4/testReport/

Max. process+thread count
611 (vs. ulimit of 5500)

modules
C: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core hadoop-tools/hadoop-azure U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/4/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 43s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 16s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
25m 32s

trunk passed

+1 :green_heart:
compile
23m 20s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
22m  4s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
4m 27s

trunk passed

+1 :green_heart:
mvnsite
2m 46s

trunk passed

+1 :green_heart:
javadoc
2m 33s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 23s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m  9s

trunk passed

+1 :green_heart:
shadedclient
22m 51s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 33s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 21s

the patch passed

+1 :green_heart:
compile
22m 26s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
22m 26s

the patch passed

+1 :green_heart:
compile
20m 51s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
20m 51s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m 13s

the patch passed

+1 :green_heart:
mvnsite
2m 58s

the patch passed

+1 :green_heart:
javadoc
2m 32s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 32s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m 16s

the patch passed

+1 :green_heart:
shadedclient
22m 29s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
7m 26s

hadoop-mapreduce-client-core in the patch passed.

+1 :green_heart:
unit
3m  7s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
1m 30s

The patch does not generate ASF License warnings.

227m 38s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4758

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux e78531d17bcd 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d2fdfaf2e186ac240e0a5d18ce34c76b89ba26f6

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/5/testReport/

Max. process+thread count
1561 (vs. ulimit of 5500)

modules
C: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core hadoop-tools/hadoop-azure U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/5/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@steveloughran can you please take a look at this PR? Here is the corresponding JIRA.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 50s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
41m 35s

trunk passed

+1 :green_heart:
compile
0m 46s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
0m 42s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 37s

trunk passed

+1 :green_heart:
mvnsite
0m 47s

trunk passed

+1 :green_heart:
javadoc
0m 45s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 37s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 21s

trunk passed

+1 :green_heart:
shadedclient
23m 34s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
23m 55s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 33s

the patch passed

+1 :green_heart:
compile
0m 37s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
0m 37s

the patch passed

+1 :green_heart:
compile
0m 31s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
0m 31s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 20s

the patch passed

+1 :green_heart:
mvnsite
0m 36s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 25s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m  8s

the patch passed

+1 :green_heart:
shadedclient
23m 37s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 10s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 40s

The patch does not generate ASF License warnings.

103m 25s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4758

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux c9039431d275 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / f0fd148248be1d498656277bdbe72300116fa65c

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/6/testReport/

Max. process+thread count
632 (vs. ulimit of 5500)

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/6/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

looks good. have you tested it with a hierachical fs to make sure all is good there?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  6s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 38s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
25m 29s

trunk passed

+1 :green_heart:
compile
23m 26s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
20m 37s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
4m 15s

trunk passed

+1 :green_heart:
mvnsite
2m 41s

trunk passed

+1 :green_heart:
javadoc
2m 21s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m  4s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 37s

trunk passed

+1 :green_heart:
shadedclient
21m 56s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
22m 24s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 35s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 15s

the patch passed

+1 :green_heart:
compile
22m 24s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
22m 24s

the patch passed

+1 :green_heart:
compile
20m 30s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
20m 30s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m  1s

the patch passed

+1 :green_heart:
mvnsite
2m 27s

the patch passed

+1 :green_heart:
javadoc
2m 20s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 17s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
4m  0s

the patch passed

+1 :green_heart:
shadedclient
21m 48s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
7m 35s

hadoop-mapreduce-client-core in the patch passed.

+1 :green_heart:
unit
2m 40s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
1m 22s

The patch does not generate ASF License warnings.

221m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4758

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux def1ab2e1537 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 69e8abc60010de226d4e6f4f0d54816f9db37462

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/7/testReport/

Max. process+thread count
1559 (vs. ulimit of 5500)

modules
C: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core hadoop-tools/hadoop-azure U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4758/7/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

looks good. have you tested it with a hierachical fs to make sure all is good there?

Yes, tested and it passes for HNS settings too.


Enable mass deactivation/activation/deletion of assessments

Delete works one at a time now. Need @harisibrahimkv inputs on how to make this work via a single endpoint.

Need @aksanoble 's input about editing student data in bulk for Haris to make a decision. Haris, I am thinking I will just send a list of assessment ids to the server endpoint along with active set to "1" or "0". Similarly, it'll just be a list of ids for delete. Let's discuss here further.


error in cv2.findContours

after little change:
speed-detector> diff mainRU.py main.py
52,53c52
<       #cap = cv2.VideoCapture ('../08.00.mp4')
<       cap = cv2.VideoCapture (0)
---
>       cap = cv2.VideoCapture (BASE_URL + 'playlist.m3u8')

/speed-detector> python3 mainRU.py
Traceback (most recent call last):
File "mainRU.py", line 76, in
_, contours, hierarchy = cv2.findContours(dilation, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)
ValueError: not enough values to unpack (expected 3, got 2)

Same here.

Yes, opencv has changed findContours so that it now only outputs two values. For example:
contours, hierarchy = cv2.findContours(mask, cv2.RETR_TREE, cv2.CHAIN_APPROX_SIMPLE)


test: add code coverage CI action

Add code coverage to CI builds, this probably needs a maintainer to create a codecov account with lapce org  and authorize the github app.

cargo test was replaced with cargo-llvm-cov which runs the test and produce code coverage.
Additionally we could use nextest as a test runner (see: https://nexte.st/book/test-coverage.html)
not sure if we want that.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@feb30c9). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master   #1385   +/-   ##
========================================
  Coverage          ?   5.31%
========================================
  Files             ?     123
  Lines             ?   48559
  Branches          ?       0
========================================
  Hits              ?    2580
  Misses            ?   45979
  Partials          ?       0

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


trying to obfuscate a included exe

let executable= obfbytes!(include_bytes!("../../target/release/main.exe"));
this wont compile maybe could you guys add another obfbytes type that can read a file and bundle it at compile time obfuscated?

This should work. Please provide the output of the Rust compiler including errors it is giving.

This should work. Please provide the output of the Rust compiler including errors it is giving.

it doesn't work, and im not home, is it okay if you try? sorry

@CasualX ?

I cannot help without an error sorry

I cannot help without an error sorry

fn main() {

	let f = obfstr::obfbytes!(include_bytes!("bytes.rs"));

}

(where the source file is named bytes.rs)
I even padded the file to 2 MiB and it worked just fine.

ye ill be on tommorow,also isn't that basically a "FuD cRyPtEr"? 🗿, which is not my intention (it's for a image manipulation tool that i want protection for, unrelated to the actual issue)

isn't that basically a "FuD cRyPtEr"? 🗿

Interesting, I hadn't heard of this terminology.
The goal of obfstr is to prevent automated tools from detecting blacklisted strings/bytes. Obfstr does not attempt to prevent dedicated reverse engineers from manually figuring out the contents and it does not try to avoid looking suspicious (the obfuscated content has high entropy).

@CasualX
//use obfstr::obfbytes;
use std::env;
use std::fs;
use std::path::Path;
use std::process::Command;
fn main() {
let file = obfstr::obfbytes!(include_bytes!("../../target/release/main.exe"));
let temp_dir = env::temp_dir();
let exe_path = Path::new(&temp_dir).join("main.exe");
fs::write(&exe_path, file).expect("Failed to write file to temp directory");
Command::new(exe_path).spawn().expect("Failed to execute file");
}
error msg
Compiling silencer_src v0.1.0 (C:\Users\fu3x1\Documents\src\viral\rust\main\silencer_src)
error[E0080]: evaluation of constant value failed
--> C:\Users\fu3x1.cargo\registry\src\github.com-1ecc6299db9ec823\obfstr-0.4.3\src\bytes.rs:125:15
|
125 |         round_key = next_round(round_key);
|                     ^^^^^^^^^^^^^^^^^^^^^ exceeded interpreter step limit (see #[const_eval_limit])
|
note: inside obfstr::bytes::keystream::<5144064>
--> C:\Users\fu3x1.cargo\registry\src\github.com-1ecc6299db9ec823\obfstr-0.4.3\src\bytes.rs:125:15
|
125 |         round_key = next_round(round_key);
|                     ^^^^^^^^^^^^^^^^^^^^^
note: inside _OBFBYTES_KEYSTREAM
--> src\main.rs:8:19
|
8   |     let payload = obfstr::obfbytes!(include_bytes!("../../target/release/main.exe"));
|                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: this error originates in the macro $crate::__obfbytes which comes from the expansion of the macro obfstr::obfbytes (in Nightly builds, run with -Z macro-backtrace for more info)
note: erroneous constant used
--> src\main.rs:8:19
|
8 |     let payload = obfstr::obfbytes!(include_bytes!("../../target/release/main.exe"));
|                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this note originates in the macro $crate::__obfbytes which comes from the expansion of the macro obfstr::obfbytes (in Nightly builds,
run with -Z macro-backtrace for more info)
For more information about this error, try rustc --explain E0080.

Ok, you're trying to include a file of size 135104112 (almost 129 MiB) and it looks like the obfuscation (which happens at compile time) does not succeed within the evaluation limit set by Rust (it hints at #[const_eval_limit] to configure this limit but this option is nightly only).
Also this obfuscation library deobfuscates the result to a stack variable. 129 MiB is going to blow out the stack and crash at runtime just allocating space.
Can you confirm the binary you're including is indeed 129 MiB? That seems huge for an executable. If you can't reduce its size (eg. make sure it's a release build and debuginfo isn't embedded or maybe it contains a bunch of resources?) you should be looking at a separate, custom build step as this library isn't made to support such huge files.

Ok, you're trying to include a file of size 135104112 bytes (almost 129 MiB) and it looks like the obfuscation (which happens at compile time) does not succeed within the evaluation limit set by Rust (it hints at #[const_eval_limit] to configure this limit but this option is nightly only).
Also this obfuscation library deobfuscates the result to a stack variable. 129 MiB is going to blow out the stack and crash at runtime just allocating space.
Can you confirm the binary you're including is indeed 129 MiB? That seems huge for an executable. If you can't reduce its size (eg. make sure it's a release build and debuginfo isn't embedded or maybe it contains a bunch of resources?) you should be looking at a separate, custom build step as this library isn't made to support such huge files.

no i believe it was 6MiB, also i tried this with some random text file and it had similar output

I'm going to close this as I don't think this library can help you, sorry.


Computed properties / mutators

Description of problem
I currently store all prices in cents without VAT for practical reasons. When the user is editing a record I would like them to just enter prices in EUR (VAT included) and Voyager transform the input to cents.
Proposed solution
Some way to define a mutation of a property or that Voyager could "read" Elqoeunt accessors or mutations like ordinary DB-field (maybe way to complicated ;-)).
Alternatives considered
I tried to solve this by a dummy field in DB (this was presented to the user, the actual price hidden) and Eloquent event listeners keeping the real field updated, but it felt hacky and not a clean way to do it.
The closest, I found, is maybe custom form fields together with BREAD accessors, but this does not solve the problem of transforming the input before storing it into the DB.
An other option is to create and hard code a entire custom view, but that will most likely break at next big update of Voyager.
I am aware the there are mutators in Eloquent and that you maybe can override a field, but the problem is the rest of the app is expecting in cents and without tax.
Additional context
Anyway, thanks for creating this awsome project. :-)
Is this something of interest somebody others, already solved, or has this been discussed?

See https://voyager-docs.devdojo.com/customization/bread-accessors
Also, the issue template is required, even for feature requests.

Bread accessors, how could I miss that? Sorry. Fixed the templating too.


🐛 [Bug report]: Content overflow of tag list

When there are more than 5 tags in the play page the content overflows in screens with width less than 435px
Steps to reproduce the behavior:

Go to https://www.reactplay.io/plays/expanding-cards
Open dev tools and minimize screen to 435 or less

The tags are expected to wrap up when content starts to overflow.
Screenshots

I would love to work on this bug. Thanks

Sure, you can take it up.


Define on-success callback globally

Great work!
I want to set a global on-success callback for all instances throughout the app.
Is this possible without changing the source code or adding another directive?

I implemented this feature and made a pull request


Include Github as a download mirror

Currently there are only 2 download site for boost. One is jfrog which is still unavailable at the time of current writing. Another one is sourceforge which is slow and I had faced reliability issues in the past.
I propose to utilize Github as another (backup) download site.
Boost is already putting release artifacts on github: https://github.com/boostorg/boost/releases
The script for creating those artifacts is here: https://github.com/boostorg/boost/blob/master/.github/workflows/release.yml
However those artifacts on github are not the same as from jfrog or sourceforge, they have different file tree layout and different hashes. Please consider fixing them or upload the official ones.
ps. nowadays Github Actions has non trivial amount of CI jobs running (for various projects) and those CI jobs would benefit (in download speed and reliability) if boost can be fetched over the same github domain.

The Boost libraries are incredibly popular, and are downloaded 1000s of times each day.
Before we put up any other mirrors, we need to discuss it with the providers to (at the very least) let them know what we are doing.
If you know someone who is willing to donate several 100 TB of bandwidth/month, we'd love to talk to them.
Hopefully, the JFrog links will be restored soon.

As an alternative, consider splitting archives:

just sources
just documentation
just tests
built binaries for specific platform (this seems already done)

Most users need just the first one. This will greatly decrease required bandwidth.

JFrog is down again...
Here is the relevant documentation from Github about bandwidth usage:

Storage and bandwidth quotas
Each file included in a release must be under 2 GiB. There is no limit on the total size of a release, nor bandwidth usage.

I would take it literally unless they say it isn't.

Or use jsdelivr?

I've never heard of any project afraid of mirroring small, by modern standards, tarballs on GitHub.


Print

Hi
I love this, so thanks for your work on it.
However, do you have a print stylesheet for this? Printing any magic checkbox or radio button fails to show if an item was checked/selected.
Thanks

Not exactly a fix, but just in case anyone else runs into this problem, I just wrapping the whole of the magic-check css in a:
@media not print {     /* styles here... */ }
block. Hope this helps.


Conversion to tsm fails with exceeds max index value

Hello, I have a 0.9.6 influxdb that I have upgraded to    0.10.1-1
When I try to upgrade the shard in a 30GB DB I get the following:
2016/02/29 11:50:16.988594 Still Working: Completed Shards: 8/29 Points read/written: 306704235/306704235
2016/02/29 11:50:17.510485 Failed to convert    /data/fusionio/fio01/apps/tpeng/influxdb_lab15/data/prism/default/2210: Conversion of /data/fusionio/fio01/apps/tpeng/influxdb_lab15/data/prism/default/2210 failed: key 'latency_micros,cgroups=both,env=perf,instance=ampstestlab8,stor=nonpersist#!~#value' exceeds max index entries: 218400 > 65535

Is there something that I can with the bz shard to shrink it?

@pbooth it sounds like the TSM writer needs to deal with this condition as part of the conversion. @joelegasse will likely need to take a look, I think.

@pbooth one thing you might try is to reduce the -sz parameter to the influx_tsm to some smaller value. provided you hit the file size limit before you hit the index entries limit, you should avoid the condition that causes the conversion to barf.

@pbooth Thank you for finding this. @jonseymour is right, we need to handle this in the conversion tool, and there's nothing you should need to do with your files.
This is the side effect of a design decision in TSM, specifically the tsm1 format's block index for a given key. Using the default values, it's limited to 65535 (a 16-bit index key) blocks of up to 1000 entries (values) per block, per TSM file. This means that over 65 million points would need to be stored for a single field in a single series in a single shard without going over the file limit for this to be an issue. As @jonseymour mentioned, usually the file-size limit is hit first, and even at the highest compaction, that index limit isn't hit.
I should have a fix merged shortly, and we're planning a 0.10.2 release in the near future that will also include some other fixes/optimizations for the conversion tool as well.