[9.x] Do not instantiate the controller just for fetching the middleware

This PR is a result of my comment on @stancl PR -> https://github.com/laravel/framework/pull/40165#issuecomment-1001806578
This PR wants to solve the problem of having to instantiate the controller just to get the defined middleware on it which in turn has all the problems described in that comment (it's not possible to fully and reliably rely on controller constructor dependency injection etc.).
Instead of completely removing this feature (as I originally suggested in my comment) I've opted to preserve that feature in order to minimize the breaking change while still fixing the problems described in that comment.
This is how the middleware definition would look after this PR (the example contains a string and Closure based middleware):

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Routing\Controller;

class UserController extends Controller
{
-     public function __construct()
-     {
-        $this->middleware('auth')->except('fooMethod');
-
-        $this->middleware(function (Request $request): RedirectResponse {
-            return new RedirectResponse('https://www.foo.com');
-        });
-     }

+     public static function getMiddleware(): array
+     {
+        static::middleware('auth')->except('fooMethod');
+
+        static::middleware(function (Request $request): RedirectResponse {
+            return new RedirectResponse('https://www.foo.com');
+        });
+
+        return parent::getMiddleware();
+     }
}

I believe such a small breaking change is definitively worth it in order to decouple the middleware and controller layer (all the pros are described in my linked comment).
The only other purely technical breaking changes (which I don't expect to realistically impact anyone) are:

the controller dispatcher getMiddleware method no longer receives the controller object instance, it now receives the controller class name (string), I've added the typehints there to ensure that which in itself is a tiny BC
\Illuminate\Routing\Route::isControllerAction method was changed from protected to public visibility
The middleware related properties and methods in Illuminate/Routing/Controller are now static.

I think this change would also allow specifying middleware using attributes as I suggested.
The userland implementation would look like this:
class MyMiddleware
{
    public function handle($request, $next)
    {
        return $next($request);
    }
}

#[Attribute(Attribute::TARGET_CLASS)]
class Middleware
{
    public function __construct(
        protected array|string $middleware,
        protected array|string $only = [],
        protected array|string $except = [],
    ) {}

    public function toArray(): array
    {
        $options = [
            ... $this->only ? ['only' => $this->only] : [],
            ... $this->except ? ['except' => $this->except] : [],
        ];

        return [
            'middleware' => $this->middleware,
            'options' => $options,
        ];
    }
}

#[Middleware(MyMiddleware::class, except: 'index')]
class MyController
{
    public static function getMiddleware()
    {
        $reflection = new ReflectionClass(static::class);
	$attributes = $reflection->getAttributes(Middleware::class);

        if ($attributes) {
            return $attributes[0]->newInstance()->toArray();
        }

        return [];
    }
}

// ['middleware' => 'MyMiddleware', 'options' => ['except' => 'index']]
MyController::getMiddleware();

And if Laravel wanted to extend the support for PHP 8 attributes, it could use this code as the default for getMiddleware() in Illuminate\Routing\Controller. Perhaps default to this if static::$middleware is empty.
That would allow using both the standard syntax and attributes out of the box.
Also, I'd personally change the userland syntax you proposed. This:
class MyController
{
    public static function middleware()
    {
        return ['foo', 'bar'];
    }
}

is a lot better than getMiddleware() which does return parent::... at the end. Since middleware() isn't something you call anymore, it makes sense to change it into a "declarative" method that you return stuff from.
It could default to returning static::$middleware, which would let users specify middleware using 1) public array $middleware = [...]; 2) static::$middleware = [...] called from other static methods (that happen to get called at some point). So the class would retain a lot of flexibility, while still having very clean syntax.

No plans to do this at this time - don't want to put the breaking change on people because for 99% of Laravel devs it's most definitely not worth it IMO. They don't care about some edge case we need to make easier for a specific package.

@taylorotwell This is IMO not an edge case (not even close) nor is it related to any specific package. The example I gave was just the most recent instance of when this came to bit me in the ass. There's a lot of other examples of this problem which do not require any 3rd party specific package that I've personally ran into.
Problematic use case 1 (with just Laravel + Laravel Passport):

Route::get('foo', ApiController::class)->middleware('auth:api'); // where the `api` Guard is the Passport guard

use Illuminate\Contracts\Auth\Guard;

class ApiController
{
    public function __construct(private Guard $guard)
    {
    }

    public function __invoke(Guard $methodInjectionGuard)
    {
        dd($this->guard, $this->guard->user()); // unexpected behavior -> you get the 'web' guard, and null for the user instead of the 'api' guard and the User object instance
        dd($methodInjectionGuard, $methodInjectionGuard->user()); // you get the 'api' guard and the User object instance as expected
    }
}

In a real HTTP request (when we send the appropriate access token to this endpoint) the user is gonna be null, because the guard is actually gonna be the web guard which is the default guard in the Laravel skeleton. The expected result here was to get the Passport api guard because the auth middleware was supposed to set it as the default guard - unfortunately the controller is currently being instantiated too early just to get the middleware list so it got the wrong guard. This guard example is just one example into which I've run into multiple times in the past and is probably just one of many such cases.
This also unfortunately cannot be caught by tests because Passport::actingAs method would call app('auth')->shouldUse($guard); which sets the correct guard in the tests even before the test kernel handles the request (the same problem is in the  the InteractsWithAuthentication trait actingAs method). So while the tests would be green and $this->guard->user() would return the configured user in the tests the code in a real world HTTP request would return null instead. Tests behaving differently than the app would actually behave with a real HTTP request is IMO a major problem which makes tests unreliable. This PR would fix the problem of getting different guards when doing constructor vs method injection, even though ideally the ->shouldUse($guard) method call would also be deleted from both methods to solve the problem of tests not behaving like a real world app.
Problematic use case 2:
Middleware can define container bindings (example from https://github.com/laravel-json-api/laravel/blob/v1.1.0/src/Http/Middleware/BootJsonApi.php#L70):
    public function __construct(Container $container, Repository $servers)
    {
        $this->container = $container;
        $this->servers = $servers;
    }

    public function handle($request, Closure $next, string $name)
    {
        $this->container->instance(
            Server::class,
            $server = $this->servers->server($name)
        );

        $this->container->instance(
            RouteContract::class,
            $route = new Route($this->container, $server, $request->route())
        );

        return $next($request);
    }

Due to the controller being instantiated before this middleware runs and registers these bindings I cannot typehint them in the controller constructor because I'd get a \Illuminate\Contracts\Container\BindingResolutionException exception when the container would try to instantiate the controller which I definitively wouldn't expect to happen.
In short I don't believe this to be an edge case as there's a lot of use cases that are affected by this problem (here are two more problematic scenarios, plus the one from the previous comment makes that three scenarios), some which cannot be detected even by tests so I definitively think that this needs to be fixed.

Yeah, I think this would be a good general change of the routing internals. Just to be clear, we've found that this isn't needed at all for my package now, it'd just make the code significantly simpler.
However, there are many other cases when the current logic is confusing. For instance, even sessions are a bit weird with the current implementation. They're started using middleware, which means that Laravel views interacting with the SC in middleware as a correct practice. But when devs try to do it, they encounter edge cases often. Therefore, it'd make sense to support this well for other middleware as well.
@taylorotwell Please re-consider the change. Even if my package doesn't need this, I still think this would be a good change. The current behavior really is pretty confusing for anyone who doesn't source dive the internals to see why the logic is limited the way it is. And I think for 99.999% of people, it's a syntax change at most. The PR doesn't remove any behavior, the only time it'd lead to real changes being needed is when people do $this->middleware($this->somethingDynamicFromTheControllerInstance()) which sounds like a very bad code practice anyway.
I think the correct understanding of middleware is that it's something that prepares the app before the route action is executed. And currently, the route action (controller) is half-executed. It just seems wrong that it's instantiated at all before the all middleware gets executed.

@taylorotwell @driesvints Any feedback on the last two comments (which went into greater detail as to why this is needed) would be greatly appreciated.
The amount of positive feedback (13 thumbs up reactions and zero thumbs down so far) that this PR got shows that the rest of the community would also like to get this merged and that it's not just some edge case.

I'm sorry guys but following Taylor's reply we won't be spending more time on this.

@driesvints I must admit it's somewhat demoralizing in terms of contributing to the framework when you spend time on a PR (especially on its long description/answers where you describe a behavior that is very weird at best, and a bug at worst) and it gets closed for weird/misunderstood reasons (as the problem that this PR fixes is not an edge case nor is it related to any specific package which was the reason given for its closure) so I definitively expected some feedback from Taylor after further describing the problems/bugs that occur due to the current behavior.
Maybe I could've done a better job of describing the problem in my original post but it was long enough already IMO. But at least thanks for the reply.

@driesvints If more time won't be spent on this PR, would more time be spent on a bug report? See the first code example in this comment: https://github.com/laravel/framework/pull/40306#issuecomment-1008126705
I think Taylor is viewing this as something related to a feature in my package, but @X-Coder264 brought up good points about where this looks like a real bug. The behavior is very confusing to anyone who doesn't source dive the routing codebase to find that things don't work like one would expect them to.
The change is very minor and non-breaking for 99.9% of apps. However, it's breaking enough to be impossible to address post-RC1. So it's just my opinion that it'd be worth taking a look at what @X-Coder264 wrote, to avoid having what's basically a bug in the routing codebase stuck for years.
Again, the only impact of this change is that a minority of users would change their syntax of defining middleware in controllers. That's it. And middleware would actually work like it's expected to.

@driesvints I agree with all of the statements above and can confirm I also git bitten by this "quirk" of the framework in the past.
I'm a constructor injection "type of guy" usually, but I always avoid it in controllers due to the exact reasons described in the comments.

If the constructor behavior is fixed, I'd like a simpler userland API similar to Eloquent methods booting()/booted() that don't require calling parent::boot().
Without return parent::getMiddleware() and a hard typehint:
public static function bootMiddleware()
{
    static::middleware('auth')->except('fooMethod');

    static::middleware(fn () => redirect()->to('https://www.foo.com'));
}

which is about equal to the simplicity of just calling middleware() in the constructor.

I'll open this up so I can read up on the discussion about it tomorrow - but we have to be clear we are talking about breaking behavior that has existed for many years and for many people without issue. Therefore, forcing thousands of developers around the world to change their controllers for this is a very big deal and something we must take very seriously.

I've looked into this a few times but withheld from creating a PR as i'd expect it wouldn't pass as there's a super small edge case that could possibly be breaking.
In my opinion the best way to fix this is to prevent controller instantiation when middlewares are collected and the given controller does not have a getMiddleware() method.
You could probably just rewrite the Route@controllerMiddleware() method to include this method_exists check and this issue would probably be fixed.
Edge case:
It could be breaking when someone has overridden the ControllerDispatcher and has decided to return something else then an empty array in the ControllerDispatcher@getMiddlewares() method or rename the getMiddlewares() method on their controllers (why though?), but what's the chance of anyone doing that? Doesn't really sound like a real scenario to me.
(feel free to enlighten me on why i'm wrong here).

I think this would get more consideration if an alternate way to define controller middleware without instantiating the controller could be introduced without breaking the old syntax. Then, we would only document the new way so that apps can gradually transition over time.

@taylorotwell Thank you for reopening/reconsidering the PR.

I think this would get more consideration if an alternate way to define controller middleware without instantiating the controller could be introduced without breaking the old syntax.

I'm not sure what you mean, can you explain this a bit more? The old syntax requires the controller to be instantiated as the instance method $this->middleware() is being called so whatever syntax gets proposed in which the controller is not instantiated will be a breaking change.

@taylorotwell You could instantiate the controller just to grab its middleware and then throw away the instance. It'd then get re-instantiated when it's actually executed to serve the response.
This could still cause issues if some people were e.g. setting properties in the constructor based on the injected dependencies. But it'd add backwards compatibility for the 99% of people who only do simple $this->middleware('foo'). With Laravel 10 fully dropping the old syntax.
That said, I think there's not much point in adding "transitional" BC.
With Laravel 9 being a major version (and especially an LTS version), forcing people to adopt this small change is fine imo. There's no difference between L9 and L10 in this context, so if some change is appropriate in a major version, it'd be appropriate in both. Adding temporary BC to let people transition easier makes sense with frequent major versions, but since Laravel's release schedule is one major version per year, I'd just do a full switch to static syntax.

You could instantiate the controller just to grab its middleware and then throw away the instance. It'd then get re-instantiated when it's actually executed to serve the response.

Yeah, I was actually looking into that yesterday so that there's no breaking change for end users. The controller instance is currently cached on the route object. If that caching were to be killed it would mostly solve these problems, but we would then be instantiating the controller twice on every request which is suboptimal so that's why I haven't decided to PR that if there's a chance to get this PR merged instead.

Well, it may makes sense to backwards compatibility to you because you don't have to hear the complaints of the thousands of developers affected. 😅

I think if there is no transitional path forward I'm not willing to break applications for this. Sorry all.

@taylorotwell I recently came into this problem and the PR #44192 explains the situation very well, if we can fix this I think it would make the middleware setup a lot more logical.
From what I understand after stepping through the code, is that the router middleware and controller middleware are gathered and executed. But to do this the controller needs to be instantiated and inside the controller constructor any controller middleware are inserted, so afterwards they can be gathered into one final list to execute.
But I think this is a mistake. If you have router middleware, they are not related to the controller. It means I can't adjust the container before the controller is instantiated. So my constructor dependencies are now broken with the incorrect configuration.
I think the correct solution is:

gather router middleware
trigger all router middleware
construct the controller
gather all controller middleware
trigger all controller middleware

That way router middleware execute at the expected point in the request lifecycle. I am not sure whether it was for historical reasons that the router middleware were gathered and triggered in the same stage as the controller, but it does expose this problem.

@christhomas it's because in your suggestion algorithm the middleware priority is not respected.


Refactor manual install docs

Use the term namespace which is a bit more precise in the context of
deploying singletenant
Clarify prerequisites for deploying to a single namespace
Fix references to manual steps so that Kubernetes and OpenShift steps
are aligned
Delete unused old doc files

@ncbaratta @jenmalloy I've updated the PR with the changes I believe are not interferring with the use of context anymore. Please have another look.
The 'problem' here is that we have things like the 'manual install' documentation which is included twice, once for Kubernetes and once for OpenShift. The assemblies and procedures that make up the manual install docs need to have the id's and links parameterized by something. This is to avoid having to write them twice. I've changed the docs to use a 'manual-install-context' variable to achieve the same thing without messing with the 'context' parameter.
I've went through the Strimzi docs on master and I didn't actually find  a similar pattern of reuse between Kubernetes and OpenShift docs. Please point me to it in case I've overlooked it so that I can learn from the example.

@jenmalloy Pushed an update with fixes.


Update "select a storage driver" page to recommend overlay2 for CentOS

File: storage/storagedriver/select-storage-driver.md
Under Docker CE, there is a table mapping from Linux distro to recommended storage drivers. Here it lists the recommended storage drivers for CentOS to be devicemapper and vfs. However, on the docs page for installing docker on CentOS, it recommends using the overlay2 driver. Note also that the EE compatibility matrix recommends overlay2 for CentOS.
I asked in the IRC, and the answer I got was that overlay2 support should be in the CentOS kernels for CentOS >= 7.4. And that I should (probably) be using the overlay2 driver.
Is this the case? If so, the documentation should probably be updated to put overlay2 in the table of recommended storage drivers, and the minimum version of CentOS required to be specified in the installing docker docs. If not, or if overlay2 is only supported for Docker EE installs and not Docker CE, then that line should be removed from the CentOS install instructions.
I'd be happy to put together a PR as appropriate, if you'd like.

Looks like this was changed at some point to recommending overlay2 for CentOS, closing.


[Enhancement]: Whack a Mole

Is your enhancement request related to a problem? Please describe.➕
The UI/UX of the game could be improved. Additionally, it would be helpful to have a sound effect and a different image when the mole is hit to indicate that the player has scored.
Describe the solution you'd like

Improve the color scheme of the web page to make it more visually appealing.
Enhance the mole containers to make them more interactive and engaging.
Add sound effects and change the image when the mole is hit to provide better feedback to the player.

Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @ManavMalhotra !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hello @ManavMalhotra, Time's Uppp!⏰
Sorry for closing your issue!
But it's more than a week since we haven't received anything from your side 😢 .
Come up with new ideas, create a new issue and make sure you finish it within a week! 🔥
All the best! 🚀
Happy Hacking! 💗

Hey @ManavMalhotra ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Website home page should not mention Ambassador

The website home page mentions Ambassador, but I think Kubeflow v0.7 onwards no longer uses Ambassador:
https://www.kubeflow.org/

@jlewi Is it correct to say we should remove Ambassador from the home page? If yes, I can get this done during an upcoming doc fixit this week.

The mention I see as "We also integrate with Istio and Ambassador for ingress,"
We still use Ambassador in some cases as part of external authentication so its not entirely untrue.
It would be good to have a way of crediting all the technologies and projects we build upon without getting into the specifics.

Thanks Jeremy, that's good enough for now. I'll close this issue.
/close


BlazorWebView StartPath property

BlazorWebView gains a StartPath property in .NET 8, which gets/sets the path for initial navigation within the Blazor navigation context when the Blazor component is finished loading.
https://github.com/dotnet/maui/pull/11942

FYI @guardrex


feat!: console usage controllable by the caller

Motivation
NAJ-64
Description
Simple customisable logger added and all the internal logging of api should be done by it and have exposed the configureLogging so the end user can control logging accordingly.
Checklist

[x] Read the contributing guidelines
[x] Commit messages follow the conventional commits spec
[x] Performed a self-review of the PR
[x] Added automated tests
[x] Manually tested the change

@AbdulBaseerKhan is this a breaking change btw? I see the PR title but I'm not sure how it's a breaking change 🙂

@AbdulBaseerKhan Could you please respond to Osman's comments? Thank you.

the idea of having an extendable logger was implemented in https://github.com/near/near-api-js/pull/1215
I'd suggest closing this one so we don't leave it out of date


List options are not announcing as selected.

Description:
Windows + Mozilla:
List items are not reading as selected when user is selecting them.
Mac + Safari:
when navigating through 'Control + option + right/left arrow keys', it is reading as list box Collapse .
When moving one to another list item. It has extra blank navigation.
Here is the live example at Clarity site https://v4.clarity.design/documentation/tree-view#examples.
Tester Notes:
the web page should provide sufficient notification and description about any changes to the content on the web page that occur as a result of interaction with a link or button.
WCAG 2.1 Success Criterion
4.1.2
WCAG Conformance Level
A

@gnomeontherun, yes, we're tracking this. Please let me know if you want the specific issue numbers.

Yes, Please provide me.  @scroniser


Fix the MinRoot link

Fix the link to MinRoot, it's going to the wrong page.  (It's going to the general requirements page, https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/hyper-v-requirements, which says nothing about min root, it should be going to https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-minroot-2016, like it says in the link).

Thanks for fixing this! You'll see the change live today (6/19).


Support for RTL layout testing with Xcode 11 test plans

This PR adds support for SNAPSHOT_CONFIGURATION_NAME environment variable which can be used in Test Plans configurations. When aforementioned variable exists, another level of directory nesting is added to store separate snapshots for each configuration.
Additionally, to fully support RTL layout testing, .leftToRight traits have been removed from base trait sets for each snapshotting device. This trait override caused RTL UIs to not be correctly rendered (see http://www.openradar.me/radar?id=5044259694575616).
See #168 for more background for this PR.

@mbrandonw @stephencelis Hi! Over a month passed since I opened this PR. Is there any chance to merge it or give any pointers / suggestions
:)?

Hey @SebastianOsinski! It'd definitely be nice to add an environment component to test names to distinguish things like Xcode 11 test plans! @mbrandonw and I will thing things over and bike-shed the variable name and where it renders in the filename soon.

Do we have any update on this PR? My team is working on a test project and we highly anticipate this feature. Thanks all for the help!

bump on this PR


Is it planned to offer other backends than dropbox?

Maybe something, that I can be self hosted?

Yes. For the initial beta release I'm intending to only promote the Dropbox backend because it is well tested but Passcards is designed to allow easy addition of other storage services. The command-line version already uses this facility to work with the local file system instead of Dropbox for example.
As for self hosting, I'm currently doing some work on a simple HTTP server backend which can be run locally. This is mainly for automated testing and offline development but with the addition of SSL support and a login page it could be turned into a feature for advanced users to be able to self-host their storage.
Implementing a new backend is done by implementing the VFS API, which is a simple file system access abstraction.

I've just landed much of the work to make this possible. Initially this enables multiple stores associated with different Dropbox accounts, which you can use for basic password sharing for example.
For a self-hosted option what I'd ideally like is an open source file server that exposes a REST API and supports OAuth authentication. Open to other suggestions though.

Not sure if this fullfills the needs, but it might be a good starting point
https://www.npmjs.com/package/accountdown


Main - Add mntl

Add AssetMantle MNTL
add to Assets page (chain infos was already there)
add to trade router (690 OSMO/MNTL)
add altCoinId

Deployment LGTM.


ci: opensuse outage workaround

Signed-off-by: Lizan Zhou<EMAIL_ADDRESS>

seems opensuse.org is back, let's close this for now.


[docs] simplicity commander link broken

https://github.com/openthread/ot-efr32/pull/56/checks?check_run_id=2640309338

@lmnotran can you take care of this?  Thanks

@lmnotran @romacdon , the submodule update PRs are currently blocked on this CI check. If you prefer, I can continue to merge the PRs with the understanding that the markdown check is expected to fail. What do you prefer?

@jwhui Sorry about the delay. Somehow I missed the notification saying I was assigned this issue. I'm working on a fix, but you can go ahead and merge the submodule update PRs even with the failing markdown check. Thanks!


In the drop-down to select the variable for an adaptive marking replacement, sort the variables alphabetically

Hello, I will love to work on this issue, could you assign it to me?

Hi @diegoherrer4, thanks for offering to help! I won't assign this issue to you, but I'll gladly look at any pull request you make.
Please have a look at our guidelines on contributing to Numbas.


Cb 9806 - Add icon to project defaults

An icon is required for packaging an Ubuntu application. The project defaults should declare an icon in config.xml to avoid an unnecessary error.
This pull request works in conjunction with a cordova-lib pull request that applies the value to a config.xml with a missing icon parameter.

LGTM!


TFLite Demo mobilenet_ssd

How are mobilenet_ssd.tflite and detect.tflite  converted  in the newest TFLite Demo ?
Previously, I converted that model by following this instructions,  but now,  I see that there are 4 outputs in TFLiteObjectDetectionAPIModel in the source code TFLiteObjectDetectionAPIModel.java, the previously converted model can't be used.
I tried the following instructions, but the error occurred.
bazel run --config=opt \   //tensorflow/contrib/lite/toco:toco -- \   --input_file=${MODEL_PATH}/frozen_inference_graph_stripped.pb \   --output_file=${MODEL_PATH}/ssd_mobilenet_v1_float.tflite \   --input_format=TENSORFLOW_GRAPHDEF \   --output_format=TFLITE \   --inference_type=FLOAT \   --input_shapes=1,300,300,3 \   --input_arrays=Preprocessor/sub \   --output_arrays=detection_boxes,detection_scores,detection_classes,num_detections \   --dump_graphviz=${MODEL_PATH}
.......
2018-07-03 19:35:14.798049: I tensorflow/contrib/lite/toco/import_tensorflow.cc:1090] Converting unsupported operation: TensorArrayGatherV3
2018-07-03 19:35:14.798066: I tensorflow/contrib/lite/toco/import_tensorflow.cc:1090] Converting unsupported operation: TensorArrayGatherV3
2018-07-03 19:35:14.798080: I tensorflow/contrib/lite/toco/import_tensorflow.cc:1090] Converting unsupported operation: TensorArrayGatherV3
2018-07-03 19:35:15.248275: I tensorflow/contrib/lite/toco/graph_transformations/graph_transformations.cc:39] Before Removing unused ops: 4096 operators, 6814 arrays (0 quantized)
2018-07-03 19:35:15.563598: I tensorflow/contrib/lite/toco/graph_transformations/graph_transformations.cc:39] After Removing unused ops pass 1: 4053 operators, 6719 arrays (0 quantized)
2018-07-03 19:35:15.977287: I tensorflow/contrib/lite/toco/graph_transformations/graph_transformations.cc:39] Before general graph transformations: 4053 operators, 6719 arrays (0 quantized)
2018-07-03 19:35:16.225122: F tensorflow/contrib/lite/toco/graph_transformations/resolve_tensorflow_switch.cc:95] Check failed: other_op->type == OperatorType::kMerge
Aborted (core dumped)
Who can help ?
Thanks!

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Have I written custom code
OS Platform and Distribution
TensorFlow installed from
TensorFlow version
Bazel version
CUDA/cuDNN version
GPU model and memory
Exact command to reproduce

Hi. I actually have the prev model in quantized format as given in the instructions you just linked. Can you please tell me how you used it bcos I am trying to run it in the TFLITE Interpreter but it doesnt seem to work :sweat_smile:

@ abhi-rf,  @andrewharp, @karmel , The prev model by following this instructions  can not work in the latest TFLite Demo, Whether it is quantified or float,  because the tflite model in the latest TFLite demo  requires 4 outputs , but prev model only have 2 outputs( concat, concat1).
Please help , Thanks!

@WenguoLi  Hi. Yea I got that. However, I wanted to compare the models in terms of their results for my internship purposes. I am using the python API but I do not know how can I interpret the results from the concat and concat_1. I need help for that. I am using something similar to this code.
`import numpy as np
import tensorflow as tf

interpreter = tf.contrib.lite.Interpreter(model_path="converted_model.tflite")
interpreter.allocate_tensors()

input_details = interpreter.get_input_details()
output_details = interpreter.get_output_details()

input_shape = input_details[0]['shape']
input_data = my_image_array
interpreter.set_tensor(input_details[0]['index'], input_data)

interpreter.invoke()
output_data = interpreter.get_tensor(output_details[0]['index'])
print(output_data)`

And the new detect.tflite, what output corresponds to what actually ?
Any help would be greatly appreciated. Thanks!

Hi
Please specify how you obtain detect.tflite model from Tensorflow graph. We will be able to help with subsequent instructions on this

Downloaded it from here
Link
I found this link in the repo only
Here

Hi Abhishek
The downloaded model on the link (detect.tflite) you provided should work in the app - it is a quantized model that gives the four outputs as detected_boxes, detected_classes, detected_scores, num_boxes.
The earlier model mobilenet_ssd did have two outputs - if you specifically need earlier version of the app. Please sync to the github code in history.
The instructions to generate the new tflite file with four outputs are coming soon (within next week)

Thanks @achowdhery

Here is the blog post showing Tensorflow Lite detailed instructions
https://medium.com/tensorflow/training-and-serving-a-realtime-mobile-object-detector-in-30-minutes-with-cloud-tpus-b78971cf1193

@achowdhery , Thanks!


Allow the symbol 'cosec' for cosecant function

Problem Statement:
The Calculator app only allows the usage of the symbol 'csc' for referring to the cosecant trigonometric function. It would have been better if the symbol 'cosec' was also allowed.
Evidence or User Insights:
Many books and websites use the symbol 'cosec' for it. Here I have quoted some of them:
https://en.wiktionary.org/wiki/cosec
http://www.librow.com/articles/article-11/appendix-a-16
In fact in regions like India, the name 'cosec' is used much more than 'csc'.
Proposal:
I have a simple proposal. Please allow the usage of both 'csc' and 'cosec' in Scientific as well as graphing modes of the Calculator as both terms are synonymous.
Goals:
To have two symbols for referring to the cosecant trigonometric function: 'csc' and 'cosec', so that when we are entering cosec(x) in the graphing calculator it directly related to the cosecant trigonometric function.
Non Goals:
Low Fidelity Concept:
Requested Assignment:
I'm just suggesting this feature. I don't want to implement it.

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

Strongly agree on this point

@grochocki I would appreciate hearing your opinion on this.

Thanks for your submission! We should definitely support "cosec", but we believe this is actually a bug in the graphing engine. We'll need to resolve this internally, but we will keep this issue active to track and provide updates.


Speed components set hardcoded unit by default

Add simple unit converters for basic speed and length units.
Signed-off-by: Marcin Lawicki<EMAIL_ADDRESS>

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@25baec6). Click here to learn what that means.
The diff coverage is 90.34%.

@@           Coverage Diff            @@
##             master     #24   +/-   ##
========================================
  Coverage          ?   73.6%
  Complexity        ?     958
========================================
  Files             ?      68
  Lines             ?    3735
  Branches          ?     395
========================================
  Hits              ?    2749
  Misses            ?     759
  Partials          ?     227

Impacted Files
Coverage Δ
Complexity Δ

...m/here/msdkui/common/measurements/UnitSystems.java
100% <100%> (ø)
1 <1> (?)

...m/here/msdkui/common/measurements/Measurement.java
100% <100%> (ø)
6 <6> (?)

...ere/msdkui/common/measurements/SpeedConverter.java
69.23% <69.23%> (ø)
7 <7> (?)

...re/msdkui/common/measurements/LengthConverter.java
73.33% <73.33%> (ø)
11 <11> (?)

...re/msdkui/common/measurements/MeasurementUnit.java
76.92% <76.92%> (ø)
2 <2> (?)

...com/here/msdkui/common/measurements/Converter.java
90% <90%> (ø)
12 <12> (?)

.../com/here/msdkui/common/DistanceFormatterUtil.java
95.41% <95.91%> (ø)
48 <32> (?)

Continue to review full report at Codecov.

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


docs(readme): Huh? in the Wild section

Bubbletea had a 'in the Wild' section to show off production applications, it would be nice to have the same here

Thanks for the contribution @stefanlogue, meteor looks great!


keyboard shortcuts support

keyboard shortcuts support

Hi @istommao. Could you elaborate?
What keyboard shortcuts are you looking for?

start and stop
for now, i can see toolbar
 everytime in screen recorder
generate gif speed is slow
and i found save gif file broken, can't view

You can use cmd + 5 to bring up the cropper window and use enter to start the recording. Does this resolve your issue?
I fail to see how the time it takes to generate the gif is relevant though 🤔

ok I see, i think you can show keyboard shortcuts in preferences 😄
I found another  screen recorder sofaware LICEcap generate the gif very fast

Yes, keyboard shortcut configuration is a planned feature which will display all current shortcuts as well. 😄
Yes, I believe LICEcap and Kap use different methods to generate GIFs. We use the highest quality conversion method available to us. In turn, that makes the generation a bit slow. But you can speed this up by lowering the frame rate, or shrinking the size, of your GIF.

Yes I use 15 frame rate, by the way kap GUI is awesome, now i'll use kap Instead of LICEcap!

Yes, keyboard shortcut configuration is a planned feature which will display all current shortcuts as well. 😄

@CodeTheory any news on this feature? Right now it interferes with the shortcuts of CodePen and it's pretty annoying.

@CodeTheory

use enter to start the recording

Is there any way to stop the recording?

@OliverJAsh Press Command + Shift + 5 again to stop


can it use fetch robot?

I want  to sim2real in fetch robot, can the benchmark use the fetch robot?

Sorry for the late reply. Since we use PyRep as our backend, I think it is possible to add robot arms and new robots. Please check their repo for more details.


Rules: Add rule for derived phenocycler datasets

Following merged PR #604 for TEST
From @jpuerto-psc:

I think its going to take some time to test out that change fully. Seems like the PhenoCycler pipeline is broken so we will have to wait for that to be fixed to confirm that the vitessce-hints are correct.

Juan gave the greenlight to release to PROD even though there's no actual data to test.


TypeError: this.followed is not a function

https://github.com/imorland/follow-users/commit/cf6c26d6cee7cb42b46801f3c63a7852f6559c37#r53984926

You're totally right! That should be this.user.followed().
Will update and patch release ASAP.

@iPurpl3x Master branch should have a fix. If you could double check this solves the issue, that'd be great.
If not, I'll test it later this afternoon.

Released 1.0.2.


Funding Rate display

premium (in ETH) is calculated:
NOTE: premium can be positive with A and negative with B
$MaxPremiumRate = toDailyRate(PREMIUM_HL)$
$PremiumRate = |r_{A0}' - r_{B0}'| \times MaxPremiumRate$

if rA == rB: premium[*] = 0
if rA > rB:

premium[A] = PremiumRate / rA
premium[B] = premium[C] = - PremiumRate / (rB + rC)

if rB > rA:

premium[B] = PremiumRate / rB
premium[A] = premium[C] = - PremiumRate / (rA + rC)

display these 2 info instead of interest rate:

Max Funding Rate (for pool): interest + MaxPremiumRate
Funding Rate (for positions): interest + premium[side]
Funding Yield (for LP): interest - premium[C]

Negative Funding rates should have green text color.
Positive Funding rates should have gray (neutral) color

LP:

Interest => Min Funding Yield
Yield => Funding Yield


[AMBARI-24308] 'Changed properties' filter for configs is displayed even in non-compare mode

What changes were proposed in this pull request?
Filtering configs by changed properties should be available in versions comparison mode only, but as of now it's displayed always, not filtering out anything in regular mode.
How was this patch tested?
UI unit tests:
21825 passing (26s)
48 pending

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3160/
Test FAILed.
Test FAILured.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3169/
Test FAILed.
Test FAILured.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3179/
Test FAILed.
Test FAILured.

[INFO] Ambari Web ......................................... SUCCESS [03:19 min]


Luck of license

Hi can you please add software license ? Without it all rights are automatically deny.

Thanks for bringing this to our attention! @petersin0422 and I have decided we'll go with MIT for these modules and have added them in 12be0b66a21972f47eee415f51860b9a3bf759d1.


Return result from gfx_window_glutin::init

Motivation: https://github.com/amethyst/amethyst/issues/135#issuecomment-441402015

@torkleyy ping ^ CI fails

Thanks! I somehow missed this PR. Should work now!

Bors r+

On Dec 4, 2018, at 10:09, Thomas Schaller<EMAIL_ADDRESS>wrote:
Thanks! I somehow missed this PR. Should work now!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


Fixes issue #5

Scoped the variables when creating them, use streams.errors count rather than haderrors for PS2 compatibility.

btw, I would like to add pester tests to provide some confident. Maybe will do other the weekend.


Rework preview mechanism based on StackedContent implementation

#59
Had a go at this and the basics seem to be working so far.
PR'ing to get the discussion going :)

Moved the POST to the existing API controller.
Not sure if you have a general way of fixing culture for those calls.
Didn't see anything for that in StackedContent.
When does the redirect flow occur?

@kows Thank you for the pull request.
This has been on my to-do list for a long time, so good to see it being tackled. I'll schedule in a time to review it, (I've got some other DTGE PRs that I need to review, I'll bundle them all together 👍)

@kows Thank you for the PR. I'm going to merge it in to a temporary branch for now.
It's definitely the feature we want, but I want to discuss a few things with @mattbrailsford before merging in to the develop branch for the next release.

I'm not sure if you rather have me log this in a separate issue (just let me know).
We were trying out the 0.6.0 beta today to see if the fix for unpublished content previews works.
Unfortunately it looks like there is a different issue now to do with Vorto values in the DTGE doc type.
When in the new preview mode the GetVortoValue method always returns null, whereas if I view the same page on the frontend the same method call returns the right value.
I can see the property and value are there when in preview mode, it's just the conversion that fails.
I'm wondering whether it has something to do with the check for the preview mode in GetVortoValue no longer working (since you're bypassing the default Umbraco preview mode)

@tomvanenckevort If you open a separate ticket for this, that'd be great, thanks.


If __GNUC__, check if exceptions are enabled before using them

GCC and Clang both define __EXCEPTIONS when exceptions are enabled, and do not define it otherwise. They should also both define __GNUC__.
https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
Thus, this PR allows unordered_dense to compile with clang and gcc when using -fno-exceptions, which isn't currently supported.
It shouldn't change the behavior otherwise.
Not sure what the best way to test this is. Add -fno-excpetions to an arbitrary test that doesn't currently use exceptions and is compiled with clang or gcc?

Hi @chriselrod, thanks for the contribution! I had similar functionality in my older map, where I was doing it that way:
https://github.com/martinus/robin-hood-hashing/blob/master/src/include/robin_hood.h#L128-L133
and a generic doThrow() function that otherwise calls abort():
https://github.com/martinus/robin-hood-hashing/blob/master/src/include/robin_hood.h#L331-L344
I think it should be done in a similar way. I don't think assert() is a good solution because it might be disabled, so better call abort(). I'd just rename the function to from doThrow to throwOrAbort().
please clang-format everything :)

I've copied the check, I'll copy the doThrow later today.
When compiling without NDEBUG being defined, the assert will still print the message.
Only when defining NDEBUG (which cmake does on Release) does the message (and check) go away.
Correctly predicted branches are cheap, so if you want to keep them even in release builds, that's fine.

please clang-format everything :)

Just found a bug in my editor configuration where things going through "c or c++ mode" weren't enabling the language server or getting formatted...

My concern with the assert is that when compiling with NDEBUG the program just continues, but it shouldn't or else it runs into undefined behavior. Better to abort() to be sure the program really stops

Okay, I've copied the doThrow implementation, but I've only added noinline when exceptions are enabled, because abort generates hardly any code.
I also added likely/unlikely to each of these to indicate they're unlikely.
FWIW, c++20 adds likely/unlikely attributes.
If you want to check for c++20, you could let MSVC use them.

I think the macos doctest problem can be fixed by upgrading doctest, please run meson wrap update doctest and commit the updated doctest.wrap file

I'm getting this locally
    inlined from ‘void std::vector<_Tp, _Alloc>::_M_fill_initialize(size_type, const value_type&) [with _Tp = ankerl::unordered_dense::v3_0_2::detail::table<int, int, ankerl::unordered_dense::v3_0_2::hash<int>, std::equal_to<int>, std::allocator<std::pair<int, int> >, ankerl::unordered_dense::v3_0_2::bucket_type::standard>; _Alloc = std::allocator<ankerl::unordered_dense::v3_0_2::detail::table<int, int, ankerl::unordered_dense::v3_0_2::hash<int>, std::equal_to<int>, std::allocator<std::pair<int, int> >, ankerl::unordered_dense::v3_0_2::bucket_type::standard> >]’ at /usr/include/c++/12/bits/stl_vector.h:1702:33,
    inlined from ‘std::vector<_Tp, _Alloc>::vector(size_type, const value_type&, const allocator_type&) [with _Tp = ankerl::unordered_dense::v3_0_2::detail::table<int, int, ankerl::unordered_dense::v3_0_2::hash<int>, std::equal_to<int>, std::allocator<std::pair<int, int> >, ankerl::unordered_dense::v3_0_2::bucket_type::standard>; _Alloc = std::allocator<ankerl::unordered_dense::v3_0_2::detail::table<int, int, ankerl::unordered_dense::v3_0_2::hash<int>, std::equal_to<int>, std::allocator<std::pair<int, int> >, ankerl::unordered_dense::v3_0_2::bucket_type::standard> >]’ at /usr/include/c++/12/bits/stl_vector.h:567:27,
    inlined from ‘void DOCTEST_ANON_FUNC_2()’ at ../test/unit/copy_and_assign_maps.cpp:73:38:
../include/ankerl/unordered_dense.h:582:24: error: ‘void* memcpy(void*, const void*, size_t)’ forming offset [128,<PHONE_NUMBER>7] is out of the bounds [0, 128] [-Werror=array-bounds]
  582 |             std::memcpy(m_buckets, other.m_buckets, sizeof(Bucket) * bucket_count());
      |             ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

All checks passed, good to merge @martinus?

Merged it, thank you!


TCP/HTTP health checks not resistant to network partition

Current implementation of health checks does not perform optimally during a network partition. It marks task to be killed and once the network partition heals it kills all of the tasks on the far side of the partition. Can Marathon use TASK_LOST status from Mesos to pause health checks?

Marathon treats a TASK_LOST update as a task failure and will launch a new the task, so it wouldn't make sense to pause health checks.
The proper fix would be to add support for Mesos HTTP/TCP health checks once  https://issues.apache.org/jira/browse/MESOS-2533 is merged.

Fixed in v0.15.x by e8ace92168573927326f64963b73bb6df88dbdd3, we still have to port this fix to 1.x
cc/ @aquamatthias

@gkleiman In a perfect world, it seems like this and this are actually better. Doing it this way, would allow not having to have these sort of hacks in marathon proper, and everyone is better off!
What do you think?

Support for Mesos health checks is in marathon now.

What version will this be in?


Interface based API

DO NOT PUSH DIRECTLY TO THIS PR. All changes should be through other PRs.
This PR is an umbrella for making the API purely interface based
TODO

[ ] Split public classes into interface and implementation

[x] All Realm related - #376
[ ] List APIs - #396

[ ] Evaluate if we should also split data classes (currently LogConfiguration and VersionID)
[x] Commonize version and various lifecycle implementations - Separate PR in #383
[ ] Internalize public API - Should be in a separate PR #56
[ ] Enable explicit API mode - Should be in a separate PR #22
[ ] Consider interface options for RealmObject (Postponed for later as we don't have the ideal fix for this yet.)
- We cannot just add interface methods to RealmObject and implement them internally as IDE will consider these unimplemented due to the invisible RealmObject->RealmObjectInternal relationship injected by the compiler plugin.
- Adding methods with default implementation is an option, but cannot directly dispatch to internal RealmObjectInternal implementation as it generates recursive calls. Could just dispatch to the realmLifeCycle.version() instead of RealmObjectInternal.
[ ] Update CHANGLOG, README and other docs

I have targeted the comments in #442


Use ARG instead of ENV?

For some build-time variables, it would be good to use just ARG instead of ENV.

Unlike an ARG instruction, ENV values are always persisted in the built image.

For example, the variables like TOMCAT_MAJOR, TOMCAT_VERSION, TOMCAT_TGZ_URL, TOMCAT_ASC_URL.
Just a thought!

Are these variables causing problems somewhere?  IMO switching to "ARG"
implies that they're supposed to be user-serviceable via "--build-arg",
which really isn't the case here.

It did not cause any problem, but just feel like ARG would be more appropriate.

ARG is not great unless necessary, especially given that it makes the output of docker history unnecessarily difficult to parse for both for humans and for computers.
Related: https://github.com/docker-library/php/issues/698


client.devices() returns only first 100 devices

How would the user iterate rest of the devices?

@sn032p this is due to the paginated nature of the List Devices endpoint response, for more details: https://m2x.att.com/developer/documentation/v2/device#List-Devices
Here's a code sample that demonstrates how to iterate over the entire paginated list of Devices using the Python client:
https://github.com/attm2x/m2x-python/blob/master/examples/iterate_over_devices.py


Simplify generation of io_handler.get_output_directory().

This is a maintenance PR triggered by issue #760 .
The function io_handler.get_output_directory is used frequently throughout the code. The usage is slightly inconsistent, as only use_plain_path together with dir_type=simtools-result returns exactly the output_path as set through the command line configuration. This is not a naively expected behaviour.
This PR simplifies the generation of io_handler.get_output_directory():

removal of dir_type option. This was hardly used in the code (mostly with the test option to add 'test' to the output directory; once with simtools-results)
use_plain_path  is now always returning exactly the output_path as set through the command line configuration (anything else can be steered through the sub_dir option).
refactored the io_handler.get_output_directory() (removed some if statements by changing the logic) and completed the unit tests

For reviewing:

relevant code changes in io_handler.py and test_io_handler.py only
all other code changes are the removal of dir_type
all other changes are done by  using sed for unit and integration tests to adjust to the new behavior.
note that small change in retrieving the model directory in simtools/simtel/simulator_light_emission.py (link

Running the integration tests locally gives one failed test:
run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.log_hist gets stored in the base simtools directory, which leads to the following error:

================================================ FAILURES =================================================
_________ test_applications_from_config[simtools-simulate-prod_gamma_20_deg_pack_for_south_grid] __________
[gw2] linux -- Python 3.11.7 /workdir/env/bin/python3.11

tmp_test_directory = local('/tmp/pytest-of-root/pytest-0/popen-gw2/test-data10')
config = {'APPLICATION': 'simtools-simulate-prod', 'CONFIGURATION': {'ARRAY_LAYOUT_NAME': 'test_layout', 'AZIMUTH_ANGLE': 'Nort...zm000deg_South_test_layout_test-production-South-pack-for-grid.zst'}], 'TEST_NAME': 'gamma_20_deg_pack_for_south_grid'}
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0xffff6276fa10>
request = <FixtureRequest for <Function test_applications_from_config[simtools-simulate-prod_gamma_20_deg_pack_for_south_grid]>>
model_version = '6.0.0'

    @pytest.mark.parametrize(
        "config",
        get_list_of_test_configurations(),
        ids=get_list_of_test_configurations(get_test_names=True),
    )
    def test_applications_from_config(tmp_test_directory, config, monkeypatch, request, model_version):
        """
        Test all applications from config files found in the config directory.

        Parameters
        ----------
        tmp_test_directory: str
            Temporary directory, into which test configuration and output is written.
        config: dict
            Dictionary with the configuration parameters for the test.

        """

        # The db_add_file_to_db.py application requires a user confirmation.
        # With this line we mock the user confirmation to be y for the test
        # Notice this is done for all tests, so keep in mind if in the future we add tests with input.
        monkeypatch.setattr("sys.stdin", StringIO("y\n"))

        try:
            tmp_output_path = Path(tmp_test_directory).joinpath(
                config["APPLICATION"] + "-" + config["TEST_NAME"]
            )
        except KeyError as exc:
            logger.error(f"No application defined in config file {config}.")
            raise exc
        tmp_output_path.mkdir(parents=True, exist_ok=True)
        logger.info(f"Temporary output path: {tmp_output_path}")
        logger.info(f"Test configuration from config file: {config}")
        logger.info(f"Model version: {request.config.getoption('--model_version')}")
        if "CONFIGURATION" in config:
            model_version_requested = request.config.getoption("--model_version")
            if "MODEL_VERSION_USE_CURRENT" in config:
                model_version_config = config["CONFIGURATION"]["MODEL_VERSION"]
                if model_version_requested != model_version_config:
                    pytest.skip(
                        "Model version requested {model_version_requested} not supported for this test"
                    )
            config_file, config_string, config_file_model_version = prepare_configuration(
                config["CONFIGURATION"],
                output_path=tmp_output_path,
                model_version=model_version_requested,
            )
        else:
            config_file = None
            config_string = None
            config_file_model_version = None

        cmd = get_application_command(
            app=config.get("APPLICATION", None),
            config_file=config_file,
            config_string=config_string,
        )
        logger.info(f"Application configuration: {config}")

        logger.info(f"Running application: {cmd}")
>       assert os.system(cmd) == 0
E       AssertionError: assert 256 == 0
E        +  where 256 = <built-in function system>('simtools-simulate-prod --config /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/tmp_config.yml')
E        +    where <built-in function system> = os.system

tests/integration_tests/test_applications_from_config.py:379: AssertionError
------------------------------------------ Captured stderr call -------------------------------------------
INFO::test_applications_from_config(l350)::test_applications_from_config::Temporary output path: /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid
INFO::test_applications_from_config(l351)::test_applications_from_config::Test configuration from config file: {'APPLICATION': 'simtools-simulate-prod', 'TEST_NAME': 'gamma_20_deg_pack_for_south_grid', 'CONFIGURATION': {'SIMULATION_SOFTWARE': 'corsika_simtel', 'LABEL': 'test-production-South-pack-for-grid', 'MODEL_VERSION': '6.0.0', 'SITE': 'South', 'ARRAY_LAYOUT_NAME': 'test_layout', 'PRIMARY': 'gamma', 'RUN_NUMBER_START': 10, 'NUMBER_OF_RUNS': 1, 'AZIMUTH_ANGLE': 'North', 'ZENITH_ANGLE': 20, 'NSHOW': 5, 'ESLOPE': -2.0, 'VIEW_CONE': '0 deg 0 deg', 'ENERGY_RANGE': '100 GeV 1 TeV', 'CORE_SCATTER': '10 1400 m', 'DATA_DIRECTORY': 'simtools-output', 'OUTPUT_PATH': 'simtools-output', 'PACK_FOR_GRID_REGISTER': True}, 'INTEGRATION_TESTS': [{'OUTPUT_FILE': 'directory_for_grid_upload/run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.log_hist.tar.gz'}, {'OUTPUT_FILE': 'directory_for_grid_upload/run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.zst'}]}
INFO::test_applications_from_config(l352)::test_applications_from_config::Model version: None
INFO::test_applications_from_config(l312)::prepare_configuration::Writing config file: /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/tmp_config.yml
INFO::test_applications_from_config(l376)::test_applications_from_config::Application configuration: {'APPLICATION': 'simtools-simulate-prod', 'TEST_NAME': 'gamma_20_deg_pack_for_south_grid', 'CONFIGURATION': {'SIMULATION_SOFTWARE': 'corsika_simtel', 'LABEL': 'test-production-South-pack-for-grid', 'MODEL_VERSION': '6.0.0', 'SITE': 'South', 'ARRAY_LAYOUT_NAME': 'test_layout', 'PRIMARY': 'gamma', 'RUN_NUMBER_START': 10, 'NUMBER_OF_RUNS': 1, 'AZIMUTH_ANGLE': 'North', 'ZENITH_ANGLE': 20, 'NSHOW': 5, 'ESLOPE': -2.0, 'VIEW_CONE': '0 deg 0 deg', 'ENERGY_RANGE': '100 GeV 1 TeV', 'CORE_SCATTER': '10 1400 m', 'DATA_DIRECTORY': '/tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output', 'OUTPUT_PATH': '/tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output', 'PACK_FOR_GRID_REGISTER': True, 'USE_PLAIN_OUTPUT_PATH': True}, 'INTEGRATION_TESTS': [{'OUTPUT_FILE': 'directory_for_grid_upload/run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.log_hist.tar.gz'}, {'OUTPUT_FILE': 'directory_for_grid_upload/run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.zst'}]}
INFO::test_applications_from_config(l378)::test_applications_from_config::Running application: simtools-simulate-prod --config /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/tmp_config.yml
INFO::simulator(l198)::_validate_run_list_and_range::run_list: [10]
INFO::db_handler(l147)::_find_latest_simulation_model_db::Updated the DB simulation model to the latest version CTAO-Simulation-Model-v0-6-0
INFO::simulator(l262)::simulate::Submission command: local
INFO::simulator(l267)::simulate::Starting submission for 1 run
INFO::array_model(l206)::export_simtel_array_config_file::Writing array configuration file into /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output/CTA-test_layout-South-6.0.0_test-production-South-pack-for-grid.cfg
INFO::corsika_simtel_runner(l111)::_export_multipipe_script::Multipipe script: /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output/multi_cta-South-test_layout.cfg
INFO::corsika_config(l409)::generate_corsika_input_file::Exporting CORSIKA input file to /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output/corsika_config_gamma_South_test_layout_za020-azm000deg_test-production-South-pack-for-grid.input
INFO::job_manager(l107)::submit::Submitting script /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output/sub_scripts/sub_run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.sh
INFO::job_manager(l108)::submit::Job output stream /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output/sub_logs/sub_run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.out
INFO::job_manager(l109)::submit::Job error stream /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output/sub_logs/sub_run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.err
INFO::job_manager(l110)::submit::Job log stream /tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output/sub_logs/sub_run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.job
INFO::job_manager(l129)::_submit_local::Running script locally
INFO::simulate_prod(l177)::main::Production run is complete for primary gamma showers coming from 0.0 deg azimuth and zenith angle of 20.0 deg at the South site, using the 6.0.0 simulation model.
INFO::simulate_prod(l141)::pack_for_register::Packing the output files for registering on the grid
INFO::simulator(l444)::get_file_list::Getting list of output files
INFO::simulator(l444)::get_file_list::Getting list of log files
INFO::simulator(l444)::get_file_list::Getting list of hist files
Traceback (most recent call last):
  File "/workdir/env/bin/simtools-simulate-prod", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/workdir/external/simtools/simtools/applications/simulate_prod.py", line 185, in main
    pack_for_register(logger, simulator, args_dict)
  File "/workdir/external/simtools/simtools/applications/simulate_prod.py", line 150, in pack_for_register
    tar.add(file_to_tar, arcname=Path(file_to_tar).name)
  File "/usr/lib64/python3.11/tarfile.py", line 2171, in add
    tarinfo = self.gettarinfo(name, arcname)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/tarfile.py", line 2044, in gettarinfo
    statres = os.lstat(name)
              ^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pytest-of-root/pytest-0/popen-gw2/test-data10/simtools-simulate-prod-gamma_20_deg_pack_for_south_grid/simtools-output/simtel/logs/run000010_gamma_za20deg_azm000deg_South_test_layout_test-production-South-pack-for-grid.hdata.zst'

If I just would know what ctsim.hdata is. Seems to be nowhere specified.

From the sim_telarray documentation:
HISTOGRAM_FILE
(type: Text, items: 0, default: "ctsim.hdata")
File with histograms (use ’hdata2hbook’ to convert to hbook or ’hdata2root’ to con- vert to ROOT-format histogram files).

It seems that when the test fails while using the pack_for_grid option it still copies whatever files it finds into the base simtools directory. I will open a separate issue to ignore the packing step if the first step failed.

Weird thing is that there is no ctsims.dat when running
pytest --no-cov -n auto tests/integration_tests/

There is one when adding the model version (but 6.0.0 should be the default...):
pytest --model_version="6.0.0" --no-cov -n auto tests/integration_tests/

This is the reason why I didn't notice it before.

This required a bit of searching: the issue was with the simulate_light_emission tests, which did not have an explicit setting of -C HISTOGRAM_FILE. This generated the ctsim.hdata file.

I think there are two bugs and the one you mention above is weird. The full output is:
INFO::simulate_prod(l193)::main::Production run is complete for primary gamma showers coming from 180.0 deg azimuth and zenith angle of 20.0 deg at the South site, using the 6.0.0 simulat     ion model.
2128 INFO::simulate_prod(l157)::pack_for_register::Packing the output files for registering on the grid
2129 INFO::simulator(l450)::get_file_list::Getting list of output files
2130 INFO::simulator(l450)::get_file_list::Getting list of log files
2131 INFO::simulator(l450)::get_file_list::Getting list of hist files
2132 Traceback (most recent call last):
2133   File "/workdir/env/bin/simtools-simulate-prod", line 8, in <module>
2134     sys.exit(main())
2135              ^^^^^^
2136   File "/workdir/external/simtools/simtools/applications/simulate_prod.py", line 201, in main
2137     pack_for_register(logger, simulator, args_dict)
2138   File "/workdir/external/simtools/simtools/applications/simulate_prod.py", line 166, in pack_for_register
2139     tar.add(file_to_tar, arcname=Path(file_to_tar).name)
2140   File "/usr/lib64/python3.11/tarfile.py", line 2171, in add
2141     tarinfo = self.gettarinfo(name, arcname)
2142               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2143   File "/usr/lib64/python3.11/tarfile.py", line 2044, in gettarinfo
2144     statres = os.lstat(name)
2145               ^^^^^^^^^^^^^^
2146 FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pytest-of-root/pytest-4/popen-gw1/test-data22/simtools-simulate-prod-gamma_20_deg_south_check_output/simtools-output/simtel/logs/run000001_gamma_za20deg_azm180deg_South_alpha_check_output.hdata.zst'

Somehow the code searches in the log directory for a data file.
This file exists where it should be: /tmp/pytest-of-root/pytest-4/popen-gw1/test-data22/simtools-simulate-prod-gamma_20_deg_south_check_output/simtools-output/simtel/data/run000001/run000001_gamma_za20deg_azm180deg_South_alpha_check_output.zst

I think there are two bugs and the one you mention above is weird. The full output is:
INFO::simulate_prod(l193)::main::Production run is complete for primary gamma showers coming from 180.0 deg azimuth and zenith angle of 20.0 deg at the South site, using the 6.0.0 simulat     ion model.
2128 INFO::simulate_prod(l157)::pack_for_register::Packing the output files for registering on the grid
2129 INFO::simulator(l450)::get_file_list::Getting list of output files
2130 INFO::simulator(l450)::get_file_list::Getting list of log files
2131 INFO::simulator(l450)::get_file_list::Getting list of hist files
2132 Traceback (most recent call last):
2133   File "/workdir/env/bin/simtools-simulate-prod", line 8, in <module>
2134     sys.exit(main())
2135              ^^^^^^
2136   File "/workdir/external/simtools/simtools/applications/simulate_prod.py", line 201, in main
2137     pack_for_register(logger, simulator, args_dict)
2138   File "/workdir/external/simtools/simtools/applications/simulate_prod.py", line 166, in pack_for_register
2139     tar.add(file_to_tar, arcname=Path(file_to_tar).name)
2140   File "/usr/lib64/python3.11/tarfile.py", line 2171, in add
2141     tarinfo = self.gettarinfo(name, arcname)
2142               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2143   File "/usr/lib64/python3.11/tarfile.py", line 2044, in gettarinfo
2144     statres = os.lstat(name)
2145               ^^^^^^^^^^^^^^
2146 FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pytest-of-root/pytest-4/popen-gw1/test-data22/simtools-simulate-prod-gamma_20_deg_south_check_output/simtools-output/simtel/logs/run000001_gamma_za20deg_azm180deg_South_alpha_check_output.hdata.zst'

Somehow the code searches in the log directory for a data file.
This file exists where it should be: /tmp/pytest-of-root/pytest-4/popen-gw1/test-data22/simtools-simulate-prod-gamma_20_deg_south_check_output/simtools-output/simtel/data/run000001/run000001_gamma_za20deg_azm180deg_South_alpha_check_output.zst

Yes, can confirm that the file is in simtel/data/run000001/ directory and the file is searched wrongfully in the log directory.

I think there are two bugs and the one you mention above is weird. The full output is:
INFO::simulate_prod(l193)::main::Production run is complete for primary gamma showers coming from 180.0 deg azimuth and zenith angle of 20.0 deg at the South site, using the 6.0.0 simulat     ion model.
2128 INFO::simulate_prod(l157)::pack_for_register::Packing the output files for registering on the grid
2129 INFO::simulator(l450)::get_file_list::Getting list of output files
2130 INFO::simulator(l450)::get_file_list::Getting list of log files
2131 INFO::simulator(l450)::get_file_list::Getting list of hist files
2132 Traceback (most recent call last):
2133   File "/workdir/env/bin/simtools-simulate-prod", line 8, in <module>
2134     sys.exit(main())
2135              ^^^^^^
2136   File "/workdir/external/simtools/simtools/applications/simulate_prod.py", line 201, in main
2137     pack_for_register(logger, simulator, args_dict)
2138   File "/workdir/external/simtools/simtools/applications/simulate_prod.py", line 166, in pack_for_register
2139     tar.add(file_to_tar, arcname=Path(file_to_tar).name)
2140   File "/usr/lib64/python3.11/tarfile.py", line 2171, in add
2141     tarinfo = self.gettarinfo(name, arcname)
2142               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2143   File "/usr/lib64/python3.11/tarfile.py", line 2044, in gettarinfo
2144     statres = os.lstat(name)
2145               ^^^^^^^^^^^^^^
2146 FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pytest-of-root/pytest-4/popen-gw1/test-data22/simtools-simulate-prod-gamma_20_deg_south_check_output/simtools-output/simtel/logs/run000001_gamma_za20deg_azm180deg_South_alpha_check_output.hdata.zst'

Somehow the code searches in the log directory for a data file.
This file exists where it should be: /tmp/pytest-of-root/pytest-4/popen-gw1/test-data22/simtools-simulate-prod-gamma_20_deg_south_check_output/simtools-output/simtel/data/run000001/run000001_gamma_za20deg_azm180deg_South_alpha_check_output.zst

Wait, this is not a data file, this is the histogram file which is technically part of the log, so it is in the right location.

Good to know. Then the issue is that it this file is written into the data and not into the log directory.

I cannot reproduce the error when using this branch. Can you please provide detailed instructions on how to reproduce it?

This is what you do to reproduce the issue (it is hidden, this is why we did not notice it earlier):

replace line 65 in tests/integration_tests/test_applications_from_config.py with config_files = sorted(Path(__file__).parent.glob("config/*gamma_20_deg_*_check_output.yml")) - this will run the integration tests using only those files (I am pretty sure there is another trick to run only a subset of the tests)
run the integration tests with pytest --no-cov -n auto --count 5 --random-order tests/integration_tests/test_applications_from_config.py

This might be an effect due to

running jobs in parallel
jobs writing histogram files with the same name into the simtools directory (where we start tests)
the cleanup of one job removes the files from another one

I do think we should never write into the directory we are starting a job from (see also issue #1167 for a similar issue for the illuminator simulations)

This is what you do to reproduce the issue (it is hidden, this is why we did not notice it earlier):

replace line 65 in tests/integration_tests/test_applications_from_config.py with config_files = sorted(Path(__file__).parent.glob("config/*gamma_20_deg_*_check_output.yml")) - this will run the integration tests using only those files (I am pretty sure there is another trick to run only a subset of the tests)

You can do this instead by just running the command below:
pytest -n auto --count 5 --random-order --no-cov tests/integration_tests/ -k simtools-simulate-prod
It will run also the the other zenith angles, but that's not an issue.

I am pretty sure the issue comes from the directory_for_grid_upload option which creates a tarball for the grid which by definition is in a predefined, easy to find, directory. When running in parallel, somehow one job overwrites a different one and also the output path is not defined properly I think. I can take a look, but my schedule this week is a bit weird, so it might take a while.

I am not sure - each of those tests is running in its own directory.
When comparing successful and failed log files from sim_telarray, I am noticing that those failed have no log file entries from running sim_telarray, see attached screenshot.
Obviously no histogram files if sim_telarray is not running. Question is just what is going on. I still suspect that they are using a common tmp directory defined by sim_telarray and one is overwriting the other.

OK, I indeed see something strange which also affects the main. Do you want to wait for me to look into it or will you?

I am trying to look into it, but it is hard.
@tobiaskleiner - could you still review this PR? This problem is independent of this PR (I can reproduce the problem on main, so this is not an issue of this PR).

Thanks @tobiaskleiner !

Don't forget to approve by in the review field....


API call terminate when screen gets off (or app goes background) IOS

I have a login page which starts downloading base data for the app after user enters username and password, and its a long duration operation like 2 or 3 minutes
In IOS at the middle of downloading data if screen gets off and locked(generally when app goes background), the operations terminates.
Here is the code
LoginPage part:
var repository = GlobalRestRepository();
var db = BasicDB();
List<basicModel> notDownloaded = await db.selectByLoaded(false);
for (int i = 0; i < notDownloaded.length; i++) {
    await repository.getBasic(notDownloaded.elementAt(i));
}

GlobalRestRepository part:
class GlobalRestRepository {
  final HttpClient http = HttpClient();

Future<void> getBasic(basicModel model) async {
    String url = "${Variables.mainUrl + basicModelUrl}";

    var response = await http.postExtraToken(url);
    .
    .
    .
 }
}

HttpClient part:
import 'package:http/http.dart';
...
class HttpClient {

  static final HttpClient _instance = HttpClient._privateConstructor();

  factory HttpClient() {
    return _instance;
  }

  Future<dynamic> postExtraToken(String path) async {
    Response response;
    try {
      response = await post(Uri.parse(path),
              headers: {"extra": Variables.extra, "token": Variables.token});
      final statusCode = response.statusCode;
      if (statusCode >= 200 && statusCode < 299) {
        if (response.body.isEmpty) {
          return [];
        } else {
          return jsonDecode(utf8.decode(response.bodyBytes));
        }
      } else if (statusCode >= 400 && statusCode < 500) {
        throw ClientErrorException();
      } else if (statusCode >= 500 && statusCode < 600) {
        throw ServerErrorException();
      } else {
        throw UnknownException();
      }
    } on SocketException {
      throw ConnectionException();
    }
  }
}

Can anyone help me with this?

@AliEasy
Your question / issue is better suited to be reported on support channels like Stackoverflow, so please ask the same there.
Closing from here as this looks more like a code assistance rather than a bug report.


[Codegen] Avoid distributing unit-extent dimensions.

Existing distribution to workgroups has logic to avoid distributing
unit-trip dimensions. This is easily handled by using scf.forall
since a pattern can be used to drop the loop dimensions that are unit.
Signed-off-by: MaheshRavishankar<EMAIL_ADDRESS>

Only review the last commit. The first commit is part of #18266

@qedawkins wondering if you have thoughts about this. It essentially first does a distribution, and then retro-actively drops unit-extent distributed loops, and remaps the mapping attribute accordingly. In isolation I think this is a good thing to do, but wondering if you had thoughts.

I thought that this is already done with PartitionableLoopInterface?
https://github.com/iree-org/iree/blob/95d556227fe2df27a0337de2507b189ef855bbc6/compiler/src/iree/compiler/Codegen/Common/TileDispatchUsingForall.cpp#L86-L91
https://github.com/iree-org/iree/blob/95d556227fe2df27a0337de2507b189ef855bbc6/compiler/src/iree/compiler/Codegen/Interfaces/PartitionableLoopsInterface.cpp#L33-L51

Yes thats right, but with scf.forall usage we wont have to push this into the tiling logic (which is what the interface was a way to do). Now we can do it after the fact (you could also do it earlier, but it was too hard to modify the tiled + distributed IR to do it correctly). When this path is the default path I plan to delete the PartitionableLoopInterface.

Yes thats right, but with scf.forall usage we wont have to push this into the tiling logic (which is what the interface was a way to do). Now we can do it after the fact (you could also do it earlier, but it was too hard to modify the tiled + distributed IR to do it correctly). When this path is the default path I plan to delete the PartitionableLoopInterface.

I see, that's awesome! Then my next question is how do we manage the kNumMaxParallelDims? My understanding is that we only defined three iree.workgroup.* attribute so we can only distribute three dimensions. (IMO, this is not a hard constraint which can be relaxed.) Today, we use the interface to exclude unit dims when we decide the distribution tile sizes. Where do we handle the logic after we delete PartitionableLoopInterface? Are we going to allow distributing as much dimensions as possible, and prune the loops to three loops by dropping unit dims and doing some emulation in this path?
(I haven't looked at the implementation details yet, but overall the idea should be good to me.)

Yes thats right, but with scf.forall usage we wont have to push this into the tiling logic (which is what the interface was a way to do). Now we can do it after the fact (you could also do it earlier, but it was too hard to modify the tiled + distributed IR to do it correctly). When this path is the default path I plan to delete the PartitionableLoopInterface.

I see, that's awesome! Then my next question is how do we manage the kNumMaxParallelDims? My understanding is that we only defined three iree.workgroup.* attribute so we can only distribute three dimensions. (IMO, this is not a hard constraint which can be relaxed.) Today, we use the interface to exclude unit dims when we decide the distribution tile sizes. Where do we handle the logic after we delete PartitionableLoopInterface? Are we going to allow distributing as much dimensions as possible, and prune the loops to three loops by dropping unit dims and doing some emulation in this path?
(I haven't looked at the implementation details yet, but overall the idea should be good to me.)

I havent sent out that PR yet but when we resolve the scf.forall it will map to three dimensions. So for workgroup tiling we can drop the kNumMaxParallelDims.. lots of clean up to do here, but one step at a time.


Azure Cognitive Services

We need to add support for Azure Cognitive services referenced here

I will be working on this task: @arnaudlh.

Hello @arnaudlh, I have created the following PR.

Closing as integrated into 5.4.2


This operation is not allowed for non owners

Issue Type: Bug
I click the share button under the liveshare tab and I get a notification that says "This Operation is not allowed for non owners" instead of it letting use liveshare.
Extension version: 1.0.5449
VS Code version: Code 1.65.2 (c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1, 2022-03-10T14:33:55.248Z)
OS version: Windows_NT x64 10.0.19044
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 x 2208)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.86GB (6.75GB free)

Process Argv
--crash-reporter-id be46d244-bdea-4dc8-a850-3a9915cb2e0d

Screen Reader
no

VM
0%

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscorecescf:30445987
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
vsclayoutctrt:30451275
dsvsc009:30452663
pythonvsnew555:30457759
vscscmwlcmc:30438804
vscgsvid2:30447481
pynewfile477cf:30450039

@jramsay we looked at this last week, right? I think this was happening when I was using client file service when I shouldn't have been. I'm not sure how users could be getting into that state.

I am receiving this error as well. Had to move to a different collaborative service as this error kept popping up.

I have the very same problem. I tried to live code share an R console. It used to work with me, although VSC always was difficult as the live code share extension always had bugs. After termination a session, I could no longer live code share. I had to restart VSC many times until I was lucky and it worked again. To me the error message seems to pop up randomly.

Uninstalling and reinstalling got me running again

I could solve the problem for me. In the task bar I went to  went to: file>Add folder to workspace.... and added the folder with the R script. Then it worked. I could live-code share and all files in that folder would have been shared. The problem really occurred if I tried to share an R script that wasn't attached to the workspace. I could klick the R console and just share the console and that worked, but not the R-script. Whenever I tried that I got the error "This Operation is not allowed for non owners".
So attaching the folder wiht the R script to the workspace, worked for me.

@schneik3, your findings are correct; we have this issue with external files from outside of the workspace. We have a fix and it will be released with the next extension release. I'm closing the issue but feel free to reopen if you see the issue after updating to the new version when it is released. Thanks for your patience!


document functions using the """...""" markdown notation

How about using the preferred method for documenting functions?
https://docs.julialang.org/en/v1/manual/documentation/
e.g. "..." or """....multieline""" before the function?
https://github.com/sje30/catam-julia/blob/e07df284906dd9a7e6e1fd6b4e3d94a846fe51c9/casestudies/Permutations/Permutations.jl#L41

I've put up an alternative .jl file with documentation. In my opinion it's cluttery for this purpose and obscures the code, but if you think it's important to teach documentation, then I'm happy to keep it that way (obviously I'll change the name and overwrite the original if so)
https://github.com/sje30/catam-julia/blob/main/casestudies/Permutations/Permutationswithdocs.jl


Cubic Chunks Support

When going above or below a certain range, Dynamic Surroundings and Ore library both cause the client to crash. Any way to possibly fix this? If I have to choose between the two i'll pick this but it'd be pretty awesome to have infinite depth in my world alongside this.

A crash log would be helpful.

Yes, please attach a crash log.


data: NitishRawat123

Move NitishRawat123.json to data/NitishRawat123.json from root

@Pradumnasaraf  I was going to raise a PR for the same. Good I saw that you have already raised one 👍

@Pradumnasaraf I was going to raise a PR for the same. Good I saw that you have already raised one 👍

Ah,
Also would like to review #5120?


Include uploadType query in multipart insert object

According to the doc, the uploadType query parameter seems not optional even though multipart request. Official API does not complain about that, but emulator implementation could fail (my one fails).
I'd like to send a PR later, but let me know if my assumption is wrong.

Close as this is already implemented. I should did notice that. sorry for incovenience


Allow setting attributes based on context

Problem Statement
We would like to be able to set arbitrary span fields based on the context passed to query execution. For instance most queries will include an important foreign key similar to user_id that we would like to include in traces. Right now it seems like the only option is WithAttributes, which only helps for global attributes that are known at connection time.
Proposed Solution
Add a new configuration option similar to WithAttributes, but that accepts a function of type func(context.Context) []attribute.KeyValue. When executing queries with a context via e.g. QueryContext, generate span fields by passing the context to the function. These can be merged with the static attributes configured with WithAttributes.
I've opened a PR along these lines: https://github.com/XSAM/otelsql/pull/9
Alternatives
Open to alternatives, this was just the quickest way I could come up with to inject the fields we want. It's certainly possible I missed an already-supported way to achieve this.
Prior Art
Can't think of any at the moment! This feels like a pretty common pattern to me though.
Additional Context
None

@alexgenco Thanks for creating this issue.
IIUC, you can create a span with the user_id before the query, then pass the context with the prior span to QueryContext. The prior span will act as a parent span, and the query span will be the child span. Since the prior span is under your control, you can add arbitrary attributes to that span.
Any reason why a option like func(context.Context) []attribute.KeyValue is necessary?

Thanks @XSAM I'll give this approach a shot and let you know if I encounter any issues.

I don't think I'm going to get around to revisiting this, but it seems like my approach may have been misguided, so I'll close for now.


[Seeso] Add new extractor

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Bug fix
[ ] Improvement
[x] New extractor
[ ] New feature

Description of your pull request and other information
Explanation of your pull request in arbitrary form goes here. Please make sure the description explains the purpose and effect of your pull request and is worded well enough to be understood. Provide as much context and examples as possible.
This pull request is to add an extractor the videos from Seeso which has a ton of content. The test is passing 100% and I've run the PEP8 code inspector builtin to PyCharm. If the devs would like valid credentials to test with, feel free to contact me, otherwise you can sign up for a free month right now.
Thanks!

Hmm. Looks like I'll need to find a replacement for urlparse.

Read

adding new extractor tutorial and youtube-dl coding conventions sections

Fixed most of the issues, but I can't seem to get the thePlatform extractor to work. I've posted the markdown notes that I took while manually verifying the process. It's here: Seeso.md

@sa7mon I've got some Python experience and I'm interested in getting Seeso support working. Is there a good way I can help contribute to this PR?

@noahleigh I had it working just fine as of commit c8223f2. It didn't conform to the way the project maintainers want the code to be and I gave up trying to make it fit their rules. If you want to try to get it merged, by all means fork it and improve it.
My branch works just fine for me, so I'll keep using it.

Welp Seeso went under so I'll close this. RIP Seeso


Javascript Hooks Page Transition on Nuxt 3 does not work

Environment

Operating System: Windows_NT
Node Version:     v16.12.0
Nuxt Version:     3.6.0
Nitro Version:    2.5.1
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      devtools
Runtime Modules:  -
Build Modules:    -

Reproduction
StackBlitz Link
and
Github Link
Describe the bug
Hello,
I got an error with the nuxt page transition and the javascript Hooks, I have the exact same code that in the doc here : https://nuxt.com/docs/getting-started/transitions#javascript-hooks
I don't really know what I'm doing wrong, if anyone does I'd love to know.
I've tried with console.log in every event and also without console.log but in neither case does it work.
The error seems to be related to Javascript Hooks because with :
export default defineNuxtConfig({
  app: {
    pageTransition: { name: 'page', mode: 'out-in' }
  },
})

it works perfectly but not with the javascript
Additional context

Logs
[Vue warn]: Unhandled error during execution of transition hook

Uncaught ReferenceError: oo_oo is not defined
    NuxtJS 50

You need to add some CSS as well: see https://vuejs.org/guide/built-ins/transition.html#css-based-transitions.

Reopened - it would be good to add this (or at least a link/notice) to the docs.

I was silly I forgot about it.
But the error is still there, I can't see any console.log on the events

So the docs example is still not working

That error is not reproducible in the linked stackblitz.

If you try with the Github Links I have provided ?
Github Link

It is also working fine once updated to 3.6.0: https://stackblitz.com/github/Etidou/Nuxt-Transition?file=package.json,nuxt.config.ts

The error must therefore be linked to my local environment, as I always get the following error when I start the project on localhost
But yes it's working on the StackBlitz

I got the exact same error on my Second Windows 10 Computer
- Operating System: Windows_NT
- Node Version:     v16.19.1
- Nuxt Version:     3.6.0
- Nitro Version:    2.5.1
- Package Manager<EMAIL_ADDRESS>- Builder:          vite
- User Config:      devtools
- Runtime Modules:  -
- Build Modules:    -

How are you getting the error? What steps?

I get the error when I click the link

https://github.com/nuxt/nuxt/assets/45783736/f269b1f0-a084-4b84-91e7-77d2bead2171

The error is linked to my local dev env , because I have deployed with netlfify and the error disappeared.
So If you have some clue to avoid this on my dev env.

Do you have Console Ninja installed, or something else that would intercept your logs? You could also try disabling Nuxt devtools, just in case?

I don't know why, but the error was caused by the VScode Extension: Live Sass compiler, so it's been working perfectly ever since.
Thanks for your help!

Great work debugging this! Glad to get to the bottom of it.


FilteredBinding support

Allow the user to bind a list to collection specifying a filter expression so that bound items are filtered given the user expression

This issue was moved to RadicalFx/Radical.Windows#58


General Refactoring

Refactored routepage.js and recommendations.js to simplify a large, redundant request to the Directions API. Wrote helper functions to combine commonalities using promises instead of callbacks,  and to separate out different function calls.
Also placed css and js files into subfolders for better organization, so they show up as new files. Changes were made to routepage.js and recommendations.js only.

I did not use that command, I just manually coped them and then I did git rm on the old files. I just checked and it looks like they're still there. I'm working on some other changes so I will fix the issue of duplicates next week.

Refactoring is in another PR currently. File organization will be moved into another PR, as it interferes with merging. Will use git mv in the future to prevent this.


refactor(builder): extract some builder methods

Summary
Related Issue

Checklist

[ ] I have added changeset via pnpm run change.
[ ] I have updated the documentation.
[ ] I have added tests to cover my changes.

ref: https://github.com/web-infra-dev/rsbuild/discussions/239


Update DG - UI model diagram and information

Update developer guide model diagram for UI and information to fit Trackermon's classes.

Codecov Report

Merging #83 (edd6ce3) into master (d778eae) will decrease coverage by 45.50%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master      #83       +/-   ##
=============================================
- Coverage     72.15%   26.65%   -45.51%
+ Complexity      399      124      -275
=============================================
  Files            70       62        -8
  Lines          1232     1043      -189
  Branches        125       90       -35
=============================================
- Hits            889      278      -611
- Misses          311      754      +443
+ Partials         32       11       -21

Impacted Files
Coverage Δ

src/main/java/seedu/address/MainApp.java
0.00% <0.00%> (ø)

...main/java/seedu/address/commons/core/Messages.java
0.00% <ø> (ø)

...rc/main/java/seedu/address/logic/LogicManager.java
0.00% <0.00%> (-75.00%)
:arrow_down:

.../java/seedu/address/logic/commands/AddCommand.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...va/seedu/address/logic/commands/DeleteCommand.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...java/seedu/address/logic/commands/ExitCommand.java
0.00% <ø> (-100.00%)
:arrow_down:

...java/seedu/address/logic/commands/HelpCommand.java
0.00% <ø> (-100.00%)
:arrow_down:

...java/seedu/address/logic/commands/ListCommand.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...ss/logic/commands/exceptions/CommandException.java
0.00% <ø> (-100.00%)
:arrow_down:

...a/seedu/address/logic/parser/AddCommandParser.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 50 more

Continue to review full report at Codecov.

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


VST3 WpfExample not recognized in Cubase

I've cloned the AudioPlugSharp repository, build the vstsdk.sln and AudioPlugSharp.sln, moved the files to a folder which Cubase scans for plugins. But my Cubase 12 Elements does not recognize WpfExample plugin as a VST3 plugin, it thinks it's a VST2 plugin and adds comment "Unsupported Architecture". Am I doing something wrong ?

Those dlls aren't the plugin. "WPFExampleBridge.vst3" is the plugin.

Cubase just ignores the "WPFExampleBridge.vst3.

I've also tried another VST3 host named Element by Kushview and then I get this error when scanning the vst.

Not sure what the problem could be - I just tested in Element and it worked fine for me.
Try looking in the "AudioPlugSharp" folder in "%appdata%" and see if you have any log files with information in them.

I cant find any AudioPlugSharp folder in appdata.

Then likely whatever went wrong happened before the plugin got a chance to log anything.

Closed due to inactivity.


Update node images to newer k8s versions (We use ~1.22 now)

Duplicate of https://github.com/giantswarm/roadmap/issues/2338


version check on repl startup breaks when binary contains spaces

Tested with racket 6.1 on windows 7, NTEmacs using the cygwin bash, and current melpa geiser.
Quick fix: (shell-quote-argument binary) instead of plain binary in geiser-racket--version (and similarly for other implementations, I suppose).
Better fix: Do not use the shell at all, it is prone to quoting issues, let alone the configuration maze on windows.  This should work much more robustly using call-process wrapped in with-temp-buffer.
Sorry for the armchair feedback w/o pull request, it's lunch break here :)

@ilohmar, thanks for the report, and sorry for the late reply.  shell-quote-argument-binary is so simple a solution that i'm wondering what concrete issues do you have in mind to prefer the more complex solution?

In this concrete case, I do not have any further issues in mind, and with a little distance I think you're probably right.
My comment is based on previous experience, however.  I have fought quoting issues in magit for several months, and it's always worst on windows, where there are different versions of emacs, the shell, wrong line endings, different path separators etc.  So nowadays, I try to avoid shell commands entirely (inside emacs functions, of course) when it's not absolutely necessary.

okay, i've been lazy and used shell-quote-argument in my last commit to master... if that gives no immediate problems, let's call it a fix and close the issue, please.

Can only test the windows case after my christmas break, but I'll close it for now as I already checked that this works :)  Thanks!