Return value of ::createQueryBuilder does not resolve to correct type when phpstan-doctrine is used

So we have this case where we override the createQueryBuilder method in one of our entity repositories to provide a specialised QueryBuilder that has some helper methods to work with the entity in question.
Heres a small test case that represents what we do in way less code:
<?php /** namespaces and uses-statements ... */

/** @extends ServiceEntityRepository<TestEntity> */
class TestEntityRepository extends ServiceEntityRepository
{
    /** constructor... */

    public function createQueryBuilder($alias, $indexBy = null): TestQueryBuilder
    {
        return new TestQueryBuilder($this->_em);
    }

    public function queryAllWithMagic(): array
    {
        $qb = $this->createQueryBuilder('tst');
        \PHPStan\dumpType($qb);
        return $qb->addMySpecialMagic()->getQuery()->getResult();
    }
}

TestQueryBuilder is just simply class TestQueryBuilder extends QueryBuilder with a few methods like for example addMySpecialMagic(): self.
When the phpstan/phpstan-doctrine extension is not installed, it dumps the type I would expect it to:
 ------ ------------------------------------------------
  Line   Repository\TestEntityRepository.php
 ------ ------------------------------------------------
  26     Dumped type: App\QueryBuilder\TestQueryBuilder
 ------ ------------------------------------------------

But when it is installed, we get this instead:
 ------ ----------------------------------------
  Line   Repository\TestEntityRepository.php
 ------ ----------------------------------------
  33     Dumped type: Doctrine\ORM\QueryBuilder
 ------ ----------------------------------------

Interesting enough, it does not complain about addMySpecialMagic being an undefined method, which is what triggered the whole investation for us.
These are the versions used for this test:

phpstan/phpstan 1.9.12
phpstan/phpstan-doctrine 1.3.32  ( we also observed the same behaviour with v1.3.27)
doctrine/orm 2.14.1

Test project is based on<EMAIL_ADDRESS>not sure if that should make a difference.
I can share the sample project I created to reproduce this if you want me. I also tried to recreate it as a testcase in the tests for this project, but failed. Could be related to the repository being  ServiceEntityRepository instead of a classic EntityRepository, or maybe some other thing related to installed libraries, or maybe I am just not smart enough.
As a work around we add a /** @var TestQueryBuilder $qb */ type annotation to the code. It works, but the IDE complaints that its redudant and I would feel better if we knew why its required.
Oh, I hope this is not a duplicate. I tried to find if it has been already reported, but had no luck.

There's this extension: https://github.com/phpstan/phpstan-doctrine/blob/1.3.x/src/Type/Doctrine/QueryBuilder/EntityRepositoryCreateQueryBuilderDynamicReturnTypeExtension.php
What it does is that it translates any EntityRepository::createQueryBuilder() method call into:
$entityRepository->getEntityManager()->createQueryBuilder()->select(TestEntity::class)->from().
Presumably it's so that
That's why you're seeing what you're seeing.
Here's the PR that did that: https://github.com/phpstan/phpstan-doctrine/pull/140
And here's why: https://github.com/phpstan/phpstan-doctrine/issues/66
Arguably it could be refactored to support your use-case too.

Hey, thanks for the fast response. Since we seem to be the only one having this problem for now I guess its only fair that I'll try to solve it without causing some regresssion.
Thanks for the detailed information, that saves a lot of time!


[Backtracing][Linux] Support the DW_AT_specification attribute.

Support parsing the following format:
0x0000104b: DW_TAG_subprogram
              DW_AT_specification (0x00000d23 "$s8CrashOpt6level1yyF")
              DW_AT_inline (DW_INL_inlined)

After #67077, a DWARF in the following format may be generated:
0x00000d58:       DW_TAG_subprogram
                    DW_AT_linkage_name	("$s8CrashOpt0A0V5$mainyyFZ")
                    DW_AT_name	("$main")
                    DW_AT_type	(0x00000f65 "$sytD")
                    DW_AT_declaration	(true)
                    DW_AT_external	(true)
                    DW_AT_APPLE_optimized	(true)
...
0x00000d9d:         DW_TAG_inlined_subroutine
                      DW_AT_abstract_origin	(0x000011d2 "$s8CrashOpt0A0V5$mainyyFZ")
                      DW_AT_ranges	(0x00000210
                         [0x00000000000011e0, 0x00000000000012f3)
                         [0x00000000000012fb, 0x0000000000001307))
                      DW_AT_call_file	("/home/dianqk/Projects/swift-project/swift/test/Backtracing/Crash.swift")
                      DW_AT_call_line	(0)
...
0x000011d2:   DW_TAG_subprogram
                DW_AT_specification	(0x00000d58 "$s8CrashOpt0A0V5$mainyyFZ")
                DW_AT_inline	(DW_INL_inlined)

@swift-ci Please smoke test

@swift-ci Please smoke test

@al45tair Could you help me invoke swift-ci and merge changes again? Test case failures look like the CI instability?

@swift-ci Please smoke test linux platform


[stable/kafka-manager] Ensure manager job gets run on an amd64 node in hybrid clusters

zenko/kafka-manager docker image is only available for amd64 so ensure job doesn't get scheduled on unsupported architecture

Signed-off-by: Jon Stelly<EMAIL_ADDRESS>
What this PR does / why we need it:
The docker image used for the kafka manager bootstrap job is zenko/kafka-manager which is only available for the amd64 platform.  When deploying this chart to a hybrid kubernetes cluster, the job can end up trying to execute on a node that's the wrong architecture.
Which issue this PR fixes
None
Special notes for your reviewer:
@giacomoguiulfo, @ssalaues, I think this is a pretty low-risk change and I've verified that it works for me locally on a k3s v1.17.2+k3s1 cluster.  I also see on an Azure Kubernetes v1.14.8 node that it also has the kubernetes.io/arch: amd64 label so it looks like the label has been stable since at least 1.14.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

Please rebase

/ok-to-test

/lgtm


Add a preloader

Add a preloader that goes with the colour scheme of the website and can be seen on the screen while the rest of the page's content is still loading.
If you feel this is something we can add to the repo, please feel free to assign it to @SciencePotato  and me.

@grace-omotoso Please review #22 for this issue


update foo

What this PR does / why we need it
Which issue(s) this PR fixes

Fixes #
Describe testing done for PR

Release note

Additional information
Special notes for your reviewer

Failed to create cherry-pick PR, workflow failed (usually due to merge conflcits), please create the cherry-pick PR manually.


Render empty attributes as empty instead of "true"

Seems to resolve #32

Released in 2.1.1!

Very late here, but this is a pretty big breaking change.
Take the following component, from Preact's docs site:
<logo height="1.5em" title="Preact" text inverted>Preact</logo>

With the following handling of props:
render({ inverted = false, text = false }) {

Probably a "damned if you do, damned if you don't" situation, but thought I'd at least comment on it.


IndexError: list index out of range

I'm running the latest influx-backup.py from an up-to-date debian9.
The influxdb version is 0.12 on centos6:
The access is allowed without user/pass
python3 influx-backup.py --url http://IP:8086 --user "" --dump --dump-db data --dir backup/
I get:
>> 2019-02-06 16:00:59 UTC
Starting backup of "data" db to "backup/" dir

Measurements:
['TABLES]

Traceback (most recent call last):
  File "influx-backup.py", line 319, in <module>
    dump(args.dump_db, WHERE)
  File "influx-backup.py", line 128, in dump
    msfields[i['series'][0]['name']] = {x[0]: x[1] for x in i['series'][0]['values']}
  File "influx-backup.py", line 128, in <dictcomp>
    msfields[i['series'][0]['name']] = {x[0]: x[1] for x in i['series'][0]['values']}
IndexError: list index out of range```

influxdb 0.12 is very old one and not sure if it ever works there.

If you are not sure that it works with the very old, I'd suggest to add a check against the version of the server before do something


mouse clicks on gi3d embed2 seem to get lost

some kind of event coordination issue -- should be easy to track down.

main thing: needed tolerance for tiny vals on projection Z value, and also not block on IsRendering for event, just for view update..


[Refactor] move model.pretrained to model.backbone.init_cfg

This PR move model.pretrained to model.config.init_cfg can solve the warning while loading the pretrained model.
there are serval examples that we did in this PR:

We move model.pretrained=XX to model.backbone.init_cfg as:

backbone=dict(
     arg1=xxx,
     arg2=xxx,
     init_cfg=dict(type='Pretrained', checkpoint='XXXX'))

When the config file need set model.pretrained=None such as in config/cityscapes , we rewrite the config file as:

backbone=dict(
     arg1=xxx,
     arg2=xxx,
     init_cfg=None)

[Need to check]  In config/selfup_pretrain, while pretrained file is stored locally, we set backbone.init_cfg=dict(type='Pretrained', checkpoint='./XX.pth').

Resolves
#5318
#5345

ci reported an error, it is indicating that some codes were not changed correctly.

Have already merge the  master  branch and fix the errors in SSD-VGG backbone, I set the init_cfg priority > pretrained, using
if init_cfg is not None:
    self.init_cfg = init_cfg
else:
    if isinstance(pretrained, str):
        warnings.warn('DeprecationWarning: pretrained is deprecated, '
                              'please use "init_cfg" instead')
        self.init_cfg = [
                dict(type='Pretrained', checkpoint=pretrained)
          ]
    elif pretrained is None:
         self.init_cfg = [
              dict(type='Kaiming', layer='Conv2d'),
              dict(type='Constant', val=1, layer='BatchNorm2d'),
              dict(type='Normal', std=0.01, layer='Linear'),
         ]
    else:
           raise TypeError('pretrained must be a str or None')

Add codes to ensure init_cfg can only initialize module by loading a pretrained model.
assert isinstance(init_cfg, dict),
     f'init_cfg must be a dict, but got {type(init_cfg)}'
if 'type' in init_cfg:
     assert init_cfg.get('type') == 'Pretrained', \
            'Only can initialize module by loading a pretrained model'
else:
      raise KeyError('`init_cfg` must contain the key "type"')
self.pretrained = init_cfg.get('checkpoint')


A typo in ?immunarch::repSample

In ?immunarch::repSample one can read: "See "Description" for more details.".  But the referred section is called "Details".

Hi, @github-wow! Thank you for reporting this, I've fixed it on the site.
Best regards,
Aleksandr


nest: Device class is not exposed to package init.py

nest Device class is not exposed to the package init file, this may impact running the script in production, local import from git clone works OK for now if user updates the nest.init to expose the Device class.

emailed the project author today.  python-nest 5.x will need to be added to the requirements package once this issue is resolved.


OpenAL.dll doesn't load in the latest snapshot

Environment

LWJGL version: 3.2.4
LWJGL build #: SNAPSHOT build 4
Java version: 13
Platform: Windows
Module: OpenAL

I built lwjgl locally with my bullet changes rebased on top of the latest commit, but OpenAL.dll is downloaded anyway so I'm not sure if that makes a difference.
Description
Initializing the class ALC throws this error in the latest snapshot:
[LWJGL] Loading library: OpenAL
[LWJGL] 	Module: org.lwjgl.openal
java.lang.NoClassDefFoundError: Could not initialize class org.lwjgl.openal.ALC
at org.lwjgl.openal/org.lwjgl.openal.ALC10.nalcGetString(ALC10.java:426)
I stepped through the class initialization and found that it throws an UnsatisfiedLinkError in org.lwjgl.system.windows.WindowsLibrary.loadLibrary(String name) with the message
Failed to load library: C:\Users\Alex\Desktop\projects\lwjgl3\bin\libs\native\windows\x64\org\lwjgl\openal\OpenAL.dll (error code = 126)
If I replace the dll with a previous version then it works.

I tried on my other pc (also windows) and its working there, Just not on my laptop.

Using process monitor it looks like its trying to load VCRUNTIME140_1.dll after loading OpenAL.dll which is not found on my laptop.

It seems that OpenAL-Soft's CMake configuration for the static MSVC runtime is broken since the migration from C to C++. OpenAL.dll will not have external dependencies in the next 3.2.4 snapshot.
Thank you @Alex-----!


user define path for outputfile

Hi @Screetsec
It would be much better to add a switch to save output file on a custom / userdefined path without creating datewise folder.

Makes sense, make it more convenient.

enhancement done,  update to new version of sudomy ver 1.1.5#dev


Food Sharepoints

These are places where people can exchange food. Many foodsaving groups have this, sometimes as permanent places (public fridges), sometimes as pop-up events (e.g. Monday 10:00 regularly).
They should be per group, and publicly visible. A small to medium-sized backend task, and many people would like to have this feature.
Frontend: should show share points on the public map, enable group members to create and modify share points for their group.
Backend: design a share point model, serializers and endpoints
Should include the following features:

name, description, location
group it belongs to
optional: times of pop-up events

This is very similar to stores, so we could think of ways to reuse existing code. Maybe generalize stores as location & description and pickup dates as events? But that's just a very first idea.

This is very similar to stores, so we could think of ways to reuse existing code. Maybe generalize stores as location & description and pickup dates as events?

That sounds very reasonable to me and since I was just talking about this with Stefan from Taiwan I'll add my two cents:

The marker on the map should look differently from the store's marker, e.g. different color.
Pick-up dates are either not needed for the FSP or can be reinterpreted as cleaning times.
In the group view the FSPs should be displayed above or underneath the stores in the list on the right. They could be seperated by a horizontal line and introduced by a headline saying 'Stores:' and 'Food-share points:' respectively.

When there's communication possibilities:

In the detail view of an FSP the users should be able to post comments for when they brought food there.
In the group view a new tab called 'Food-share points' could be introduced, that leads to an overview page where the newest messages from all FSPs, as well as upcoming and still open cleaning shifts are displayed.

From foodsharing Poland

it would be very helpful to have an 'open fridge' pins on the map (i'm not sure about the english name, i'm talking about those places where we leave food for others to take). for now we will probably use blue pins, originally for 'negotiating' stores

This seems to become more relevant. There have been related ideas such as scheduling hangout locations on karrot (ask Bruno) and marking locations to drop off food (Essen für Alle?).

It's unclear whether we should generalize stores and pickups or add new data structures to handle locations and events.

Would be useful to collect the requirements from groups:

what should be publicly displayed and what should be internal?
do we need event management or is a simple description enough?
should there be a conversation feature attached (e.g. public wall)?

It would be good to write a post on the community forum about this and gather feedback.

I wrote a post. You find it here.

Great that you tackle this! Your plans seem reasonable, generalizing stores/pickups seems the way to go to reduce code duplication, but will probably increase complexity - it seems hard to avoid endless if-else switches.
Another way to go would be to have locations and events as abstract base models, and different actual models per type. Some common functionality should be shared, e.g. recurring event logic.
Some type of locations should be public (public fridges), others internal to the group (shops), other don't matter but are of less interest to the public (drop-off).
Public information might be more limited than internal information: some events should be public (public fridge opening times, distribution events), others internal (clean up, meetings).
There could be a follow/unfollow membership per user and location, to keep users up to date about new or changed events (using the work-in-progress on-site notifications).

I got quite put off the django model inheritance stuff before. That seems to complicate things quite a lot in an abstract way. Anyhow, I think the next step here would be playing around with the code a bit and see how various approaches feel.
My goal would be to avoid lots of if/else, possibly by abstracting behaviours into seperate classes that can handle different types - so instead of 5 methods each with if/elses for each type, have a handler for each type with 5 methods each. This is still sort of inheritance (as the handler classes would adhere to an interface), but avoiding some complexity by not coupling this with the database/model inheritance. But yeah, needs some research and play :)

... on the other hand, totally separate models for each type of thing are the simplest thing conceptually. It might be that it depends more on the UI approach more than I thought too, whether the different types are more or less seperate things.
(I also have in mind (more with dreaming hat on) that it nudges it closer to being more suitable as multisharing/general type of platform if it's possible to add types relatively easy)

Some UI ideas. Open questions

Although the discussion about the feature itself and the reflections about implementation that Nick brought up here are obviously connected, I think we should open a new issue about making generalizations and possibly refactoring the backend. This can be especially interesting when trying out Karrot for new purposes, like organizing Bike Kitchens, as we mentioned on another post. The broader classes of "location" (or "places", one might call it) and "event/activity" makes sense for this Bike Kitchen use case as well, whereas types would be something like "working shifts", "meetings" and "pickups", and that's a matter to be defined in the UI.
Being able to define locations and events as public or internal are applicable to different use cases, I believe. I can say that for Solikyl, having food-share points as public would be quite useful.

The broader classes of "location" (or "places", one might call it) and "event/activity" makes sense for this Bike Kitchen use case as well, whereas types would be something like "working shifts", "meetings" and "pickups", and that's a matter to be defined in the UI.

For me the question of where to define the types is more open than that, a few options/considerations:

could be defined in an instance configuration file on the server (so a whole instance has a certain set of types)
could be defined by a status field in the code/db (as we currently do for things that have multiple types)- 3. could be defined in the UI per group by anyone that has editing rights

My default would have been to go with option 2. On the basis that:

this is already our approach for managing different things that have the same representation in the code/db (e.g. conversation types, history types)
it's flexible enough to add more, but inflexible enough that we have to think about the specific needs of each type

My concern with exposing the generic-ness in the UI (option 3) would be that different types might have different needs in terms of notifications, emails, UI, etc. For example it's much more important to notify people that a pickup has no collectors than a public event has no attendees.
It could be possible to implement these things as options when creating types, but then it also starts to get very complicated for groups that need something simple without configuring lots of options. It also would make stats reporting less meaningful if different groups did not have the same types (I find it much more interesting/useful to know if pickups are happening than if general meetings are).
The other aspect is branding/clarity kind of perspective - having a tool/site focused on saving food is much much clearer than a general tool that can sort of do many things. This doesn't have to be singular at the software level, but maybe at the deployment level, e.g. karrot.world to stay food saving focused, but maybe bike.kitchen is all setup and branded for bike saving. It might be each use-case/purpose have very different community needs too.
So, in general I am all for generalness and flexibility, until it comes at the cost of clarity and purpose.

We also have https://github.com/yunity/karrot-frontend/issues/359 which maybe can be reopened :)

Good points, Nick. Let me see if I understand. The status field on the code that you refer to on option 2, is that the status of the store as "Cooperating", "Negotiating" or "Inactive"? If yes, then I see what you mean and I believe that's a good approach. It's kind of how I played with the Karrot when we first put it up as a test-piece. Our plan is to make our own deployment, branded for the bike kitchens (and then obviously we'd like you developers to get involved ;), but we discuss that anytime soon). The question of having a generic tool for team self-management, not branded for specific purposes, can still be interesting and relevant for the future so it'd be good to keep the discussion open elsewhere.

I experimented with public places in #1449, which allows to define a public description in a place. Then the place becomes a hybrid, it has a public part and an internal part, with the location and the name shared between them.
Some comments on this:

cooperation status seems useless, pickups too
a public fridge might need a public wall (which in turn might need moderation)

As this issue had a lot of semi-related discussion, this could use a new overview in a fresh issue.

This one I have a really hard time to let go of. hehe
But probably it's better like Tilmann wrote above, to start fresh? There's a lot of discussion that is not up-to-date anymore.

I think this has two clearly distinct aspect to it:

different place types - we have a good concept of how this can work now, based on how activity types are done
public places - this needs a lot more conceptualization to understand how the interaction should be with these outside users


[GSSOC'23]: PCM quiz- JS game

Describe the project you want to add with tech stack
A Physics, Chemisty, Maths MCQ quiz
Expected behavior
The player gets to choose the subject for which they would like to take the quiz , accordingly questions are displayed and score is incremented on correct ans.
Screenshots (optional)

Additional context (optional )

@MohitGupta121 @TusharKesarwani sir kindly assign me this issue


Don't generate expressions that need further simplification

Some simplifiers generate expressions that require a different simplifier. For instance, imaging a simplifier that takes x+x+y and turns it into 2x + 1y. I've tried to be careful to not generate such expressions, but due to #2, clearly I've failed somewhere.

Unfortunately there are some rewriters where this is unavoidable, e.g. rewriteLogMult. In fact, rewriteLogMult not only has to be after the other Mult rewriters, but also before the Add rewriters. I need to figure out the rewriter dependencies and express them in a type somehow. This also has to do with the concerns I had in #2.


Light title bar on Linux with dark gtk theme variant

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.78.0
OS Version: elementary OS 7, latest

Occurs since:
April's update, a.k.a 1.78.0
Steps to Reproduce:

Set GTK_THEME_VARIANT to dark
Launch vs code
The native title bar is light, while it did match the color of the menu below it previously (which still does respect the setting).

Screenshot:

Additional info:
See the comment here: https://github.com/hardpixel/dark-variant/issues/5#issuecomment-1523222389

/duplicate https://github.com/microsoft/vscode/issues/130974

@deepak1556 this isn't fixed in version 1.84.2 for me, title bar is still light despite the system (elementary OS 7.1 with all updates installed) being in dark mode.

Change in 1.86: the toolbar and the context menus no longer respect the gtk theme anymore at all. They do follow the freedesktop dark style setting though, which is nice!
Sadly the title bar's color is still not affected and is always light.


fix(changeset): lock shared package to the rest

should fix the failing workflow
will force a release of the react and solid pacakges needed in order to fix the declaration bug that the current changeset indicates

alternatively we can change the current changeset to manually bump these packages if we don't want them to always be locked to one another

I don't think the react and solid packages should be locked to each other, or am I misunderstanding?


hi iam using html2canvas image upload to php server problem

cannot upload 1mb < size images php server ,
html:-

function:-
function capture() {
$('#content-container,#popup_div').html2canvas({
onrendered: function (canvas) {
//Set hidden field's value to image data (base-64 string)
			$('#img_val').val(canvas.toDataURL("image/jpeg").replace("image/jpeg", "image/octet-stream"));
            //Submit the form manually
			document.getElementById("myForm").submit();
		}
	});
}

save_php file:-

please help me canot uploade to large image to php server .

Hi,
can you confirm, that you have appropriate settings in your php.ini?
See: http://stackoverflow.com/questions/7754133/php-post-max-size-overrides-upload-max-filesize


Snapshot tests fixes

In this PR ConnectView was fixed according to design, added Layout enum to be able to differentiate the screens where ConnectView is shown
Snapshot tests for Chat screen were fixed also by adding mocks.
Also fixed OperatorChatMessageView trailing constraint

MOB-1803

!squash


No aram builds

Can't seem to get the aram item build
Try using 2.4.5/2.4.2/2.4.1
Tried:
-Reset the app
-Empty the cache
-Reset the settings
Always leaves me with a oracle pot
Been happening since 2.4.1

Try using another provider, just disable METAsrc and Manaflux will try to use another one if available. The issue comes probably from the website, i'll see what I can do in the next days.

Will do boss

can confirm that removing METAsrc fixes the issue of oracle only build

Update sometimes (more often then not) this error appears

Update: It appears that my statement above is wrong all different website appart from METAscr don't work in aram
Will try reinstalling and clearing temp files

Okay, I'm in the middle of my exams so that's a bit complicated right now, but I'm going to look into it. This is probably because some websites got an update or something and I didn't have time to keep Manaflux in check.


Include link to Open Targets COVID-19 target prioritisation tool in Angular application

Given the work done on the Open Targets COVID-19 Target Prioritisation Tool, we should construct a link to it from the Platform so that users can conduct a more in-depth exploration about potential COVID-19 drug targets.
Further details on implementation in Angular app TBC

As noted by @d0choa, EFO is pulling a more granular characterisation of COVID-19 - see https://github.com/EBISPOT/efo/issues/803.

MONDO:0100139 asymptomatic COVID-19 infection
MONDO:0100140 mild COVID-19 infection
MONDO:0100141 moderate COVID-19 infection
MONDO:0100142 severe COVID-19 infection
MONDO:0100143 critical COVID-19 infection

As such, the link to should appear on all relevant COVID-19 profile pages.

In addition to child terms noted above, link should also appear on the COVID-19 infection page MONDO_0100096

Ticket closed - released as part of 20.09


Enhancement - Updating annotations should not happen on save, but when indexing is finished.

Hello
Sometimes I notice that annotations aren't immediately set correctly after a save. They suddenly correct themselves when you save again. I think this happens because the indexing is not always finished quickly enough, during which the refresh of annotations has already happened. We should look at attaching 'finished' handlers to the indexing process instead so we can refresh the annotations as soon as the indexing finishes.
(If #151 is implemented, we could run all the 'finished' handlers before hiding the progress bar again.)
Thanks in advance

It needs to trigger an event when indexing is finished so.

I think I had been interpreting the indexing code incorrectly. The only asynchronous indexing that happens is the class map refresh, which the scanning for annotations is bypassing, as it's directly requesting the methods from PHP by calling proxy.methods. In other words, I'll close this as it's not an actual problem.


add reproducible scripts on on convergence of samples from images, different conditions, include # of divergences

Closed by #43


Fix issue #5222: [Refactor]: Refactor the evaluation directory

This PR fixes #5222 by reorganizing the evaluation directory structure to improve clarity and maintainability.
Changes

Created evaluation/benchmarks/ directory to house all ML literature benchmarks
Kept utility directories (utils, integration_tests, regression, static) directly under evaluation/
Updated paths in documentation and GitHub workflows to reflect the new structure
Added missing benchmarks to evaluation/README.md:

Commit0 and DiscoveryBench under Software Engineering
Browsing Delegation under Web Browsing
ScienceAgentBench under Misc. Assistance

Testing

All pre-commit hooks pass (ruff, mypy, etc.)
All unit tests pass (377 tests)

Review Notes
Key files to review:

.github/workflows/eval-runner.yml - Updated paths for integration tests and benchmarks
evaluation/README.md - Added missing benchmarks and updated paths
Documentation files - Updated references to benchmark paths

To run this PR locally, use the following command:
docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:c6627f8-nikolaik   --name openhands-app-c6627f8   docker.all-hands.dev/all-hands-ai/openhands:c6627f8

Just noting that I have confirmed the code and it looks good to me, but I'd like a second review.

I'm trying to run 1 instance of swe-bench on this PR, and I get this error:

....venv/bin/python: can't open file '/Users/enyst/repos/odie/evaluation/swe_bench/run_infer.py': [Errno 2] No such file or directory

The shell scripts, every run_infer.sh in benchmarks directories, need updated, to run the right .py file:
e.g ./evaluation/benchmarks/swe-bench/scripts/run_infer.sh contains the line

COMMAND="poetry run python evaluation/swe_bench/run_infer.py \

New OpenHands update

@openhands-agent The previous comment was fixed for swe-bench.
For every other benchmark that was moved from ./evaluation directory to ./evaluation/benchmarks/, we need to verify if there are scripts that hard-coded the old structure when calling some other script. For example, in ./evaluation/benchmarks/webarena, we can search for .sh scripts, and we will find:

./evaluation/benchmarks/webarena/scripts/run_infer.sh

Read the script. We will find a line like:

COMMAND="poetry run python evaluation/webarena/run_infer.py \

This will fail because the new location is in evaluation/benchmarks/webarena/ directory.
 Same pattern is repeated for these benchmarks, give or take that some have more files than others. Verify each benchmark's shell scripts, and modify accordingly.

New OpenHands update

The previous comments were fixed for shell scripts.
After the refactoring of benchmarks from ./evaluation directory to ./evaluation/benchmarks/, it is important that human users are still able to run easily these benchmarks. In every benchmark directory, there should be a README.md file. For example, in ./evaluation/benchmarks/swe-bench, there is a README.md with instructions how to set up and run the swe-bench benchmark.
You can read it, and see it has, for example, a line like this:

./evaluation/swe_bench/scripts/run_infer.sh [model_config] [git-version] [agent] [eval_limit] [max_iter] [num_workers] [dataset] [dataset_split]

If the human user copies and pastes that line with their own data, it will fail to run the script, because of course the swe-bench run_infer.sh script has moved to ./evaluation/benchmarks/swe_bench/scripts/run_infer.sh.
 All these benchmarks are very similar and follow the same patterns for documentation for the human users. You can verify every .md file (not only README, check for more, maybe) in each benchmark and update for this particular move. Keep it minimal, only solve this particular issue.

New OpenHands update

Not all the README.md issue (or other .md) files discussed in the previous comment were updated for human users, after the move of the benchmarks.
Some were, some were not. So we need to fix the rest.
But we have a problem. You're good, but you were not allowed to use the "str_replace_editor" tool when "old_str" is not unique in the file, so many of your attempted replacements were not performed. You had to go back and include more context. Then they were performed, but you ran out of time.
You need to understand this very well, so that we do better this time. Remember, we are refactoring the ./evaluation directory to house every benchmark under ./evaluation/benchmarks. Remember the previous comment about documentation for human users: this is what we fix now.
Usually, there were more than one occurrence of the pattern in each file (such as "/evaluation/swe_bench" to be updated to the new location). It is possible there were two occurrences, or more, where one is the syntax of the command to run the benchmark, and another is a particular example of running the command.
First, think how to do this better this time. You have two options:

you can take more context every time you want to use the str_replace_editor tool. Not a lot more, just more than the patterned string itself.
use the bash tool instead, with a bash command to perform the replacements in each .md file all at once. In this case, you need to find them first, to know what you need to do.

Make a decision, then perform it. Do not ask me about it.

New OpenHands update

You're good! Your choice to run bash scripts was brilliant!
You fixed the rest of the documentation for human users in only 4 steps this time.
Now. You did very well, and I think all we have left is to double check that there are no leftover old paths. If there are, we need to fix them.
Leftovers could be in:

.py files. This is by far the most important! The module names can break everything. You did so well with the bash tool previously, that I suggest you try it again to verify all imports in .py files or any other occurrences of the patterns, in the benchmarks files.
.sh scripts. Verify them and fix if necessary.
You can skip .md files this time, you did a very good verification last time.
Other files.

Remember to first look at all benchmarks, as we moved them from ./evaluation to ./evaluation/benchmarks/, so that you know what you work with.
Check in order and update as needed.
FINALLY:
When you finish with all of them, I want you to make an extra check:

in the root directory this time, there is a file called CREDITS.md. Read it. It probably doesn't have paths to update, that's okay, but it does have a list of benchmarks and some other details about them. Update the file according to what you have learned about our current benchmarks.

 I had to revert your last attempt.
Be careful. We have only a couple things left to fix here:

In our new ./evaluation/benchmarks directory, find and read carefully:

from Gaia, run_infer.sh
from mint, README.md
from swe-bench, eval_infer.sh
You know how to find the exact files. Note that they may be in a subdirectory. Read those files and if they need fixes, fix them. I prefer you just take it easy with str_replace_editor tool this time. Just be precise! They're half-updated probably, so make sure you don't overwrite what is already up to date.

In the root directory, there is a file called CREDITS.md. Read it. It probably doesn't have paths to update, that's okay, but it does have a list of benchmarks and some other details about them. Update the file according to what you have learned about our current benchmarks. Do not duplicate references. Make sure you add missing ones.

Remember to list all benchmarks first, it helps you know what to work with.

New OpenHands update

Hey @enyst , thanks so much for cleaning this up!


Found a typo in Wiki page

In Home/Overview/Design Philosophy/Logic Half in Client, Half in Server:
"The servers understand how store and fetch items." => "The servers understand how to store and fetch items."

after a long delay, fixed :) thanks!