Create FUNDING.yml

Lordevss123-patch-1

Why:

What's being changed:

Check off the following:

[ ] All of the tests are passing.
[ ] I have reviewed my changes in staging. (look for the deploy-to-heroku link in your pull request, then click View deployment)
[ ] For content changes, I have reviewed the localization checklist
[ ] For content changes, I have reviewed the Content style guide for GitHub Docs.

👋 We're not looking to add open source funding to this repository, as its part of GitHub. Thanks!


Support UTF-8 BOM during csv saving

The exported csv is opened by excel as ANSI encoded by default, So the non latin characters is not shown directly. The workaround for this is to set BOM bytes before the content as follow
https://github.com/eligrey/FileSaver.js/issues/28#issue-15333709

#63

#63


Env instructions in interpreter

This PR implements the remaining environment instructions on the interpreter side.

I'm not too sure for some of them, still familiarizing myself with this section. I also noticed SELFBALANCE was missing from the opcode list, is there any reason for that?


Fix code splitting

What it does?
Fixes code splitting of shared vendor dependencies.
file sizes before in dev environment:
main.js - 4.0MB
common.js.js - 23.6KB
0.chunk.js -  619KB
1.chunk.js - 518KB
2.chunk.js - 80.5KB
4.chunk.js - 5.3KB

file sizes after in dev environment:
vendor.js - 3.7MB
app.js - 375KB (main.js)
1.chunk.js -  614KB
2.chunk.js - 518KB
4.chunk.js - 19KB
5.chunk.js - 5.3KB

Why this still sucks? If you inspect the chunks and search for unique patterns, for example props.handleRoute from components/Buttons/index.js you will see the CommonChunks plugin didn't extract this. (This is also an issue with the current solution.)
What i think we should do to make code splitting work is to create another file container (f.e.: common.js) and put all shared codebase related stuff there like this:
// Shared Components
import 'components/A';
import 'components/Button';
import 'components/Footer';
import 'components/H1';
import 'components/H2';
import 'components/H3';
import 'components/Img';
import 'components/LoadingIndicator';

Pros:

this way the chunk size will be very small

Cons:

the browser needs to download this file whenever a shared component gets modified (This is also an issue now with chunks, because if the Button component gets modified all chunks will change. So it wouldn't say this is a very big problem)

cc @mxstbr

This looks really promising @tsm91!

What i think we should do to make code splitting work is to create another file container (f.e.: common.js) and put all shared codebase related stuff there like this:

What about creating components/index.js which imports all the components. The component generator could then be modified to add to that long list of components?

@mxstbr

What about creating components/index.js which imports all the components. The component generator could then be modified to add to that long list of components?

Yeah the place could be app/components/index.js.
What still bugs me is why is this happening? CommonChunks plugin should be responsible for just that we are doing now manually. I wonder if this has anything to do with on demand code loading (the router) or the beta version of webpack.
I am not a webpack expert, but maybe we should ask somebody who is.

@jantimon @sokra do you by chance have any input to the above? We must be running against some webpack CommonsChunkPlugin limitations.

i had a feeling that CommonsChunkPlugin plugin wont trace on demand file load dependency graph
and we need to tell webpack about our pages, on this way it might work.
So i tried to include all page as a separate entry point:
  entry: {
    vendor: path.join(process.cwd(), 'app/vendor.js'),
    app: path.join(process.cwd(), 'app/app.js'),
    homePage: path.join(process.cwd(), 'app/containers/HomePage/index.js'),
    featurePage: path.join(process.cwd(), 'app/containers/FeaturePage/index.js'),
    notFoundPage: path.join(process.cwd(), 'app/containers/NotFoundPage/index.js'),
  },

Didn't work, that unique pattern in the Button component is still redundant in the chunks.
So either v2 of webpack, or something with CommonsChunkPlugin.
Maybe this module resolution thing also matters resolve: { modules: ['app', 'node_modules'] }, no idea.

note if we are going to be creating DLLs, common chunks plugin will not be necessary for vendor deps in dev... from what i'm seeing in #470, it should address this issue

As far as I can tell in development, we won't need to use CommonsChunk plugin at all.  I am in the process of writing up a more detailed explanation of what is going on with the DLL in #470 , but I definitely see no reason to prefer CommonsChunk over DLL.
In Production though, I still use it.
I think to really get the most value out of The CommonsChunk plugin you will want to have a configuration with multiple entry points.  For example when you split out each of your pages into their own entries, instead of just having a single entry for main or app like we do.
In these cases specifying a minChunks value of 3 for example, and explicitly listing the dependencies will give you the desired effect
{
  entry: {
    adminApp: 'containers/AdminApp',
    bozosApp: 'containers/BozosApp',
    vendor: [
      'react',
      'react-dom',
      'react-router',
      'redux',
      'react-redux',
    ],
  },
  plugins: [
    new webpack.CommonsChunkPlugin({
      minChunks: 3,
      name: 'vendor'
    })
  ]
}

I am not quite sure how the current way containers are being lazy loaded in this project effects the CommonsChunk behavior.  I'm guessing it just works? but I still need  to look into it more
Below are some blog posts I learned a few things from, but TBH it is all still magic to me

http://jonathancreamer.com/advanced-webpack-part-1-the-commonschunk-plugin/

http://henleyedition.com/implicit-code-splitting-with-react-router-and-webpack/

i had a feeling that CommonsChunkPlugin plugin wont trace on demand file load dependency graph

yes that's true, by default the CommonsChunkPlugin will only process entry chunk.
But there is an async mode for the CommonsChunkPlugin which use on-demand chunks: http://webpack.github.io/docs/list-of-plugins.html#4-extra-async-commons-chunk
new CommonsChunkPlugin({
  name: "app",
  async: "async-commons"
});

It'll load on-demand when any on-demand chunk is requested. (Both load parallel)

@sokra by on demand chunk do you mean chunks that get generated by require.ensure ?

Coverage increased (+0.04%) to 98.329% when pulling e56927dc43b790e47f1f95b5a22fa5c60ad4a4fb on tsm91:fix-code-splitting into b068b2167e6aa494e30939751430f2021610273f on mxstbr:master.

@sokra thx, next time we should read the fucking manual :F
Basically this options hash to CommonsChunkPlugin solves everything:
    new webpack.optimize.CommonsChunkPlugin({
      name: 'app', // will extracts common chunks of code to app.js
      children: true,
      async: true, // follow on demand require (this is the important bit)
      minChunks: 3,
    }),

We don't need to specify every page to the entry point, which is very good.
  entry: {
    // ...
    // the below code to manually keep track of pages is not needed
    homePage: path.join(process.cwd(), 'app/containers/HomePage/index.js'),
    featurePage: path.join(process.cwd(), 'app/containers/FeaturePage/index.js'),
    notFoundPage: path.join(process.cwd(), 'app/containers/NotFoundPage/index.js'),
  },

cc @datapimp actually i have a modified fork of this boilerplate and i use CommonsChunkPlugin, i might check out this DLL solution.
You are right about the dev environment, it just slows down recompilation time.

Coverage increased (+0.04%) to 98.329% when pulling 413fc5d4609e8a25dd1e8bd63ab003816af5eaf6 on tsm91:fix-code-splitting into b068b2167e6aa494e30939751430f2021610273f on mxstbr:master.

Basically this options hash to CommonsChunkPlugin solves everything:

If I understand that correctly, the only thing we need to do to fix chunking would be to add async: true to the CommonsChunkPlugin options? And then the optimal solution would be to use DLL in development and the above in production?

@mxstbr nope, i guess @datapimp plans to do this ddl stuff for prod. But i haven't read anything about the dll solution yet.
We don't need CommonsChunkPlugin for dev, only to prod builds.

hey @tsm91 sorry for the confusion, I added the proper CommonsChunkPlugin config here:
https://github.com/mxstbr/react-boilerplate/pull/470/commits/c02ea4095a468f60356c547f73bc1b88dc20ed0c
I think we should use that in production. DLL is a development only config.

@datapimp ahh okay, cool
so we can discard this pr and merge the dll one?
also you could add the vendor entry 8e1f273, the 1st commit of this pr

DLL is a development only config.

while this implementation may be for dev only, i would just point out that DLLs can also be extremely useful for breaking large apps into "sub-apps" (ie with different dev teams, repos) as well as many other production use cases, ie targeting caching (tracking asset hashes in linked manifests) or a/b testing

@justingreenberg thanks - I suspected as much I just haven't had a chance to dig deeper into it and the js file that gets generated seems too big and I didn't wanna be responsible for putting that on people's production sites
Would love to learn more from you about this

@tsm91 is it necessary? i was hoping Webpack automatically handled that for us

@datapimp hmm, i guess you are right

I'm not sure I'm following the discussion here, I think we can close this PR?

These config changes have been made in the DLL PR.  Safe to close.

Thanks for kicking this off @tsm91, even though it didn't get merged!


Terminal is flooded with warnings when running tests

When running tests, e.g. using yarn test:unit the terminal is flooded with warnings like:
  Warning: An update to $Component inside a test was not wrapped in act(...).

      When testing, code that causes React state updates should be wrapped into act(...):

      act(() => {
        /* fire events that update state */
      });
      /* assert on the output */

Some of these warnings can be fixed by wrapping the testStore.dispatch(...) into an act(...) in the tests. However, not all of these warnings are fixable by this approach.
The goal of the current ticket is to get rid of the warnings.
Note: this might be related to our upgrade to React 18.

Superceded by #1273


Auth::user() returns null in Folio pages

Folio Version
1.1
Laravel Version
10.10
PHP Version
8.1.23
Description
Hello, I am encountering an issue when using Auth::user() or auth()->user() in Blade templates with Laravel Folio. Even though I have applied the auth middleware to all routes in FolioServiceProvider, the authenticated user is not being passed correctly to the Blade templates, and Auth::user() returns null.
Steps To Reproduce

Apply the auth middleware in FolioServiceProvider.
Attempt to access the authenticated user in a Folio page.
The Auth::user() or auth()->user() call returns null, even though the user is authenticated.

how exactly are you applying the auth middleware? are you including a guard, i.e auth:sanctum or auth:web? have you also applied the web middleware?

@inmanturbo No, I did not include any guard.
I applied the auth middleware as follows:
// FolioServiceProvider.php

Folio::path(resource_path('views/pages'))->middleware([
    '*' => ['auth'],
]);

... And when I tried to access the authenticated user in a Folio page like this I got the issue:
// resources/views/pages/users.blade.php
<?php
use function Laravel\Folio\name;

name('users.index');

dd(auth()->user()); // <--- returns null
?>

I am the users page

Am I using Folio wrong?

Hi, I found my error. I should have used the render function to access the authenticated user.


Visualize resnet50

Is it possible to visualize resnet50 models?

The best way to check would be to try but I see no reason why it wouldn't work

Yep I think it will work! Let us know :)


Behavior "Polymorphism" almost working but behavior list points to same package.

I have different behavior ROS packages for different robot types like this:

robotA_flexbe_behaviors
robotB_flexbe_behaviors
robotC_flexbe_behaviors

in each of this packages there is a behavior that has the same name e.g. "Docking Behavior". This behavior is implemented in different ways in each of the packages. It has the same name, because our user interface doesn't care about the type of robot, but only cares about the task to be executed.
In each of the robots, only the package corresponding to that robot is installed, that means, there is only one behavior called "Docking Behavior" per robot.
Until this point all seems to work on the onboard side of things.
However, in the FlexBe App, even though the "Select Behavior" list shows the same behavior three times, when trying to open them, all of the three behaviors point to the same package
The "Example Behavior" created by the "create_repo" script is actually a good way to reproduce this. After creating two new repos, the "Select Behavior" list will show it two times, but clicking on any of them will always open the same behavior from the same package, like this:

Example Behavior -> opens the one from robotA_flexbe_behaviors
Example Behavior -> opens the one from robotA_flexbe_behaviors

But I would expect it to be working like this:

Example Behavior -> opens the one from robotA_flexbe_behaviors
Example Behavior -> opens the one from robotB_flexbe_behaviors

Do you have any comments/suggestions/ or hopefully fixes =) on this?
ROS melodic
Flexbe App Version 2.3.0

Curious the status of this and related tickets? Did you find a work around?  I don't expect to spend time on this with ROS 1, but will look into this for the ROS 2 versions later this summer

There is a new version of ROS 2 that does not address this issue, but does "dump" the list of behaviors and their "key" (changed name to avoid confusion with "behavior_id" being used for check sum.  I need to modify the way the keys are being defined.  The issue is not fixed yet, but it is fixable.

This issue is now fixed on the latest ros2-devel branches of flexbe_app and flexbe_behavior_engine as of 30-June-23.
The solution was to pre-pend the behavior name with "package/".   For example, "test_flexbe_behaviors/Example Behavior".
Works for behavior launcher or new flexbe app.    Launcher also accepts just the name as old style, but will return some behavior with same name from the first package it encounters when processing the behavior library dictionary.
Note, the first slash delineates the package, so if your name includes a slash (e.g., "Hello World/Universe") then you MUST use the package name with launcher.

Awesome, @dcconner! Thanks for the fix. We will definitely use it once we move to ROS2!

@romayiii It's a straightforward set of changes if you want to submit a similar PR for ROS 1 on the noetic branch!
flexbe_app 4004a2a
flexbe_behavior_engine a63ef26


Fixes Against Latest BB Submodule

Description
This PR updates the bb submodule to point to the latest aztec3 branch. As a result, this PR turns on UltraPlonk for aztec3-circuits. Hence, I needed to fix some Pedersen hash calls to use the correct hash functions that takes care of the composer conditions.
⚠ Some of the rollup tests fail locally because the IV table in Pedersen lookup hash isn't initiated correctly while running local tests. This doesn't happen in circleci though. Need to dig deeper into this.
Checklist:

[x] I have reviewed my diff in github, line by line.
[x] Every change is related to the PR description.
[ ] I have linked this pull request to the issue(s) that it resolves.
[x] There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
[x] There are no circuit changes, OR specifications in /specs have been updated.
[x] There are no circuit changes, OR a cryptographer has been assigned for review.
[x] I've updated any terraform that needs updating (e.g. environment variables) for deployment.
[x] The branch has been rebased against the head of its merge target.
[x] I'm happy for the PR to be merged at the reviewer's next convenience.
[x] New functions, classes, etc. have been documented according to the doxygen comment format. Classes and structs must have @brief describing the intended functionality.
[x] If existing code has been modified, such documentation has been added or updated.

Note
If you are updating the submodule, please make sure you do it in its own special PR and avoid making changes to the submodule as a part of other PRs.
To update a submodule, you can run the following commands:
$ git submodule update --recursive

Alternatively, you can select a particular commit in barretenberg/aztec3 that you wish to point to:
$ cd barretenberg
$ git pull origin aztec3        # This will point to the latest commit in `barretenberg/aztec3`
$ git checkout <commit_hash>    # Use this if you wish to point to a particular commit.
$ cd ..
$ git add . && git commit -m <commit_msg>
$ git push

Some of the native circuit implementations always call the turbo pedersen hash, because native code doesn't have an understanding of turbo vs ultra, so those hashes will be failing.
Rahul's recent PR introduces a (very basic) DummyComposer, which is now being passed through all the circuits. You could add a proof system type to that composer, so that we can do if / else checks to select the correct pedersen hash.

@suyash67 I wonder if we should have kept all our circuits code calling turboplonk, for now, for some 'stability', until we complete milestone 1.5.
This commit has broken things for the aztec3-packages repo. It breaks if people point to this commit, presumably because of hashing discrepencies.


Registration of bar is moved to afterCompile, removed short array syntax

It moved due to circual reference.

Rebase pls because of merging https://github.com/stekycz/Cronner/pull/49


Facilitate the removal of externs/olx.js

This distributes things in the externs/olx.js file to places where they belong.
The @typedef annotations for the compiler will get added to the relevant module.  For example, a FooOptions type will go in the ol/Foo module.  The other @type annotations will get distributed as @param annotations in the modules where they belong.  For example, FooOptions.prototype.bar will become options.bar in for the constructor in ol/Foo.
Note that for 5.x, we assume applications being built together with the library, so no externs like the ones in externs/olx.js are needed any more. Since the full build will not be built with Closure Compiler any more, we do not need the externs there either (previously they helped us avoid renaming of properties in object literals passed from the application to the library).

@fredj and @ahocevar - I think we should merge this to facilitate the work outlined in #7947.
If you agree, the instructions on that pull request can be updated to be something like this:

distribute comments from externs/xol.js to other parts of the library
remove the corresponding parts from externs/olx.js
run node tasks/t.js
create a pull request

This will keep us from having to update this branch when working on removing things from externs/olx.js.  It will also let others contribute to the effort even if they cannot edit this branch.  When we are done we can remove tasks/t.js.

Merging to make it easier to work on olx redistribution.


[FIX] List trial types

merge master in dev
fixes https://github.com/cpp-lln-lab/bidspm/issues/800

https://github.com/all-contributors please add @JeanLucAnton for bug

@all-contributors please add @JeanLucAnton for bug


Parent macros are not available when rendering individual blocks

It would be a super cool feature if, in case of block-rendering, parent level macro imports were available for the blocks. For now, we either cannot use macros within blocks, which is very restricting, or need to import the macros in the blocks as well, which is uncomfortable and unintuitive. The worst part of it, is that one can never now for sure, without testing, if all block-rendering would work even if the complete template renders.
Desired syntax:
{% from 'macro.j2' import func %}

{{ func(global_variable) }}

{% block block_one %}
  {{ func(variable_1) }}
{% endblock %}

{% block block_two %}
  {{ func(variable_2) }}
{% endblock %}

Current workaround:
{% from 'macro.j2' import func %}

{{ func(global_variable) }}

{% block block_one %}
  {% from 'macro.j2' import func %}
  {{ func(variable_1) }}
{% endblock %}

{% block block_two %}
  {% from 'macro.j2' import func %}
  {{ func(variable_2) }}
{% endblock %}

Fixed by #30 .

Hi @sponsfreixes - after doing more work on my own application, I'm discovering that the initial solution for this may in fact break a lot of other things. At this point, I'm not entirely sure what the path forward is, but I'm still researching.
I was very excited to get this part working since I had an immediate use for it, but now I'm finding that both of these PRs I made probably need to be reverted. (#30 & #33)
While this works for the simple template cases, more complex templates cause grief because (afaict) the only way to get jinja2 to generate the macros is to call make_template() and that call attempts to render the entire template file. The issue with that is, not all variables are available during the single block rendering. So variables outside of the block context also need to exist in order to have the entire template processed. For simple variables {{ thing }} it's not really an issue. But more complex components will raise Undefined errors.
More concretely:
<!DOCTYPE html>

    <meta charset="UTF-8">
    <title>{{ mydict["title"] }}</title>{# undefined #}
    {% for k, v in mydict.items() %}{# undefined #}
        {{ k }} = {{ v }}
    {% endfor %}
    {{ obj.property }}{# undefined #}

This is a header

    {% block content %}

This is the content. Hello {{ name }}!

This is the bottom paragraph. Lucky number: {{ lucky_number }}

    {% endblock %}

calling render_block for content will now fail because make_module() will try to render the entire template to extract any macros. In doing so, it will fail on mydict["title"], mydict.items(), and obj.property, for example.
Prior to my PR, that would have rendered the content block just fine.
I've spent several hours trying to figure out a way around this new discovery and haven't gotten anywhere meaningful. I apologize for not finding this earlier and wasting everyone's time.
I believe getting macros to work will be very beneficial, but not at the expense of what should be basic/original functionality.

Well that's unfortunate. Than you very for all the work and time you have
put into it!
I'd say the plan is for me to revert these changes and publish a stable
version to PyPI. After that, I will definitely extend the test suite to
cover more complex cases like the ones you describe. And after that, with
whatever time we need, we try to figure out the macros.
Unfortunately , I won't have access to my development PC until Saturday, so
we will have to wait until then.
On Thu, Jul 4, 2024, 9:16 AM gconklin @.***> wrote:

Hi @sponsfreixes https://github.com/sponsfreixes - after doing more
work on my own application, I'm discovering that the initial solution for
this may in fact break a lot of other things. At this point, I'm not
entirely sure what the path forward is, but I'm still researching.
I was very excited to get this part working since I had an immediate use
for it, but now I'm finding that both of these PRs I made probably need to
be reverted. (#30
https://github.com/sponsfreixes/jinja2-fragments/pull/30 & #33
https://github.com/sponsfreixes/jinja2-fragments/pull/33)
While this works for the simple template cases, more complex templates
cause grief because (afaict) the only way to get jinja2 to generate the
macros is to call make_template() and that call attempts to render the
entire template file. The issue with that is, not all variables are
available during the single block rendering. So variables outside of the
block context also need to exist in order to have the entire template
processed. For simple variables {{ thing }} it's not really an issue. But
more complex components will raise Undefined errors.
More concretely:

{{ mydict["title"] }}{# undefined #}
    {% for k, v in mydict.items() %}{# undefined #}
        {{ k }} = {{ v }}
    {% endfor %}
    {{ obj.property }}{# undefined #}

This is a header
    {% block content %}
        This is the content. Hello {{ name }}!
This is the bottom paragraph. Lucky number: {{ lucky_number }}
    {% endblock %}

calling render_block for content will now fail because make_module() will
try to render the entire template to extract any macros. In doing so, it
will fail on mydict["title"], mydict.items(), and obj.property, for
example.
Prior to my PR, that would have rendered the content block just fine.
I've spent several hours trying to figure out a way around this new
discovery and haven't gotten anywhere meaningful. I apologize for not
finding this earlier and wasting everyone's time.
I believe getting macros to work will be very beneficial, but not at the
expense of what should be basic/original functionality.
—
Reply to this email directly, view it on GitHub
https://github.com/sponsfreixes/jinja2-fragments/issues/21#issuecomment-2209301475,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAINXBNZZ3PFU6EJY5LT6KTZKVYNXAVCNFSM6AAAAABKERA2FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBZGMYDCNBXGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

I definitely agree with reverting.
I've been playing some more and have come up with a thought, but requires a modification to the render_block* calls by adding 1 or 2 default parms.
render_block calls template.new_context() - and new_context takes 2 additional params of shared and locals - I propose that we make those available to the user by adding them to render_block() such as:
 def render_block(
     environment: Environment,
     template_name: str,
     block_name: str,
     shared: bool = False,                              # added for completeness [1]
     locals: typing.Optional[list[typing.Any]] = None,  # added for usefulness [1]
     *args: typing.Any,
     **kwargs: typing.Any,
 ) -> str:

same for render_block_async
and then later:
ctx = template.new_context(vars=dict(*args, **kwargs), shared=shared, locals=locals)
With that mechanism in place, the user is free to inject whatever they want into the locals, including macros. Which puts the onus on them to properly load the macros.
An example can be documented and also state that the template should only have macros in it and not other template content.
def get_jinja_macros(template_name):
    template = current_app.jinja_env.get_or_select_template(template_name) # flask specific
    template_module = template.module
    macros = {
        m: getattr(template_module, m)
        for m in dir(template_module)
        if isinstance(getattr(template_module, m), Macro)
    }
    return macros

[1] - it's possible if a user has existing code with variables named shared or locals, this will cause problems for them.

A new version (1.5.0) has been pushed reverting the changes. I'll give some thought to your proposal, I'm OK with being a feature where the users need to know that there are some caveats associated with it.

I'll work up a PR based off of 1.5.0 for what I've put together that is working for me and we can move implementation discussion there. I think at the least, those jinja2 variables (shared/locals) should be exposed to the user when rendering fragments.

Welp, I have made a discovery that I should have realized earlier. This works (for flask):
macros = get_jinja_macros("macros.html.jinj2")
return render_block("template.html.jinja2", "content", **macros, var1="thing", var2=2, ...)

In this case, the loaded macros are passed as variables, and because vars and locals wind up in the same dict (parent), the macros are found.
https://github.com/pallets/jinja/blob/f8323cf4042ab058ac5b11743614c63308798541/src/jinja2/runtime.py#L108

This is a great finding! Something similar will probably be possible for other frameworks. What's get_jinja_macros exactly doing?

get_jinja_macros() is in an above comment, but basically it's just loading a (macro-only) template (aka, no other templating in there) and then tells jinja to parse it and extract the macro "functions" and finally returns a dict(symbol->function) which is then expanded to keyword args when passed to render_block
def get_jinja_macros(template_name):
    template = current_app.jinja_env.get_or_select_template(template_name) # flask specific
    template_module = template.module
    macros = {
        m: getattr(template_module, m)
        for m in dir(template_module)
        if isinstance(getattr(template_module, m), Macro)
    }
    return macros

Is anyone using macros in the same file just for readability?
{% macro func(a) %}

...long verbose body, but specific to this template only...

{% endmacro %}

{{ func(global_variable) }}

{% block block_one %}
  {{ func(variable_1) }}
{% endblock %}

{% block block_two %}
  {{ func(variable_2) }}
{% endblock %}


Can I also apply these EFI settings on N550JV?

Specifications

Component
Model

CPU
i7  4700HQ  Processor

iGPU
HD 4600

dGPU
NVIDIA GT 750M

RAM
8 GB DDR3L 1600 MHz

STORAGE
PLEXTOR M6S

WLAN CHIPSET
BCM94352

LAN CHIPSET
RTL8168

BLUETOOTH
4.0

AUDIO CHIPSET
ALC668

Thanks~

Yes, but you should create a CPUFriendDataProvider kext for your processor using this guide.

Yes, but you should create a CPUFriendDataProvider kext for your processor using this guide.

Thanks~
Will have a try

Which mac os version you are using? 10.15.x or 11.x?

11.5.1

I noticed that your Wi-Fi card is different. So you also need to remove all Wi-Fi and Bluetooth kexts from kext folder and config.plist and add BCM kexts.

I noticed that your Wi-Fi card is different. So you also need to remove all Wi-Fi and Bluetooth kexts from Kexts folder and config.plist and add BCM kexts.

Yes, and also the dGPU part.

Yes, and also the dGPU part.
Yes, but it doesn't matter. Because it will not work and should be disabled to save power.

Yes, and also the dGPU part.

Yes, but it doesn't matter. Because it will not work and should be disabled to save power.

Seems the latest version of UEFITool can not replace the body for below step?
"Search for CsmVideo and replace the body with HermitCsmVideo.fbd and save."

The latest version is an alpha release, use version 0.28.0.


non-containerised ueransim deployment

This deployment will help in deploying non-containerized ueransim.

See the comment in Slack. I've created a separate "docker" branch to save the effort to deploy UERANSIM as a container, so we can delete references to docker in master --> ending up with a "clean" install playbook (as-a-process).
The second ask is write an playbook to do the install on the second server (rather than directly calling ssh). Without having to work around the docker-related playbooks, this should result in a fairly clean install, uninstall, and config-and-run playbooks.

This looks to be pretty close, but I don't understand the purpose of simulator.yml given the playbooks in roles/simulator/*.yml.
One other question (possible suggestion): Would it work to copy the ue and gnb config files to the target location as part of the "run" playbook instead of the install playbook? I would think this would make it possible to re-run the simulator multiple times with potential edits to the config files in between each run (as is possible in the gnbsim playbooks).


Support simplifying expressions like str ~ '^foo$'

Is your feature request related to a problem or challenge?
It would be nice if predicates that look like
str ~ '^foo$'

could be rewritten as
str = 'foo'

And likewise,
str !~ '^foo$'

could be rewritten as
str != 'foo'

Describe the solution you'd like
It would be straightforward to extend the expression simplifier to do this.
Describe alternatives you've considered
This seems pretty uncontroversial so I haven't considered any alternatives.
Additional context
This is relevant to InfluxQL support in IOx: https://github.com/influxdata/influxdb_iox/issues/6902

I am currently working on this.


Transaction popup window should be large like pay or request window.

Hi,
I think the transaction popup window, like this one:

Should be large like Pay or Request window, but, of course, with transaction information.

Going to close this as this is a design request. To chime in on design details please join our slack


bug: auto-update errors

Some users have reported errors with auto-updating ipfs-desktop.
This issue is intended to track them all and work to resolution.
related countly errors (permissioned URL)

[updater] Error: ENOENT: no such file or directory, open '/opt/IPFS Desktop/resources/app-update.yml'

related issues

https://github.com/ipfs/ipfs-desktop/issues/2626

I attached my logs: biglep-2023-09-18-ipfsDesktopLogs.zip

I didn't see anything obvious in steve's logs.
I just downloaded an old version of IPFS-desktop https://github.com/ipfs/ipfs-desktop/releases/tag/v0.26.1, blocked access to ipfs.io, ran ipfs-desktop v0.26.1, and then selected "check for updates" and it did not update successfully. I am investigating this in addition to https://github.com/ipfs/ipfs-desktop/issues/2632

going to download v0.28.0 manually and then try auto-update.

v0.28.0 auto update failed. I saw the new app open and then close, and then v0.28.0 re-opened. nothing useful in logs.

v0.29.0 manual update also failed. no useful log output other than 2023-09-19T18:48:10.578Z info: [beforeQuitCleanup] stopIpfs had finished with status: 5

manual immediate update also failed for ipfs-desktopv0.30.0, so, i decided to try to "install later" and see if that worked. It did for ipfs-desktopv0.30.0. here are the steps:

click "check for updates" in the systray
click "install later" on the popup
make sure combined.log includes a line saying 2023-09-19T18:53:00.202Z info: [updater] update to 0.30.2 downloaded
quit ipfs-desktop
run ipfs-desktop from applications after a few minutes (let electron-updater do it's install stuff during shutdown, ala https://github.com/ipfs/ipfs-desktop/blob/b097be6f06ab1fa325681c67cb9fb67d83e84a2e/src/auto-updater/index.js#L24).

@BigLep can you try this on your version to see if that fixes things?

I was also able to successfully update v0.26.1 to v0.30.2 by choosing to "install later". seems like we have a bug with using quitAndInstall(), which may also impact auto-update outside of application restarts.

@SgtPooki : earlier this morning I quit IPFS Desktop.  I then just relaunched it, and during the relaunch it appeared to be updating and then I confirmed that I had indeed been updated.  I have attached my combined.log.


Page dies with "Error: timeout" on OS X

I tried installing the latest release, and building from source. In both cases, when I pipe anything to page I get the text "Error: Timeout" and neovim exits.

Ok. Compiled neovim from source and that seems to fix it.

Nope. I was wrong. Compiling neovim from source did NOT fix this issue.

Sorry, for delayed response.
I don't have access to any OS X machine, so I cannot debug it by myself.
Could you redirect to page with RUST_LOG=trace RUST_BACKTRACE=1 and provide output?

[INFO][page] options: Options {
address: None,
arguments: None,
config: None,
command: None,
command_post: None,
instance: None,
instance_append: None,
instance_close: None,
name: None,
filetype: "pager",
sink_open: false,
sink_print: false,
back: false,
back_restore: false,
follow: false,
follow_all: false,
query_lines: 0,
page_no_protect: false,
command_auto: false,
split_right: 0,
split_left: 0,
split_above: 0,
split_below: 0,
split_right_cols: None,
split_left_cols: None,
split_above_rows: None,
split_below_rows: None,
files: []
}
[TRACE][new nvim process] args: --cmd 'set shortmess+=I' --listen /var/folders/h9/m5lk4kcn5s11qg9yw6gllb2r0000gn/T/neovim-page/socket-SZQBTeszf634YTp2lmORjIzynhwyxf1Z

Does it work with TMPDIR=/tmp when redirecting to page ?

nope. Same error

I've got the same error, also on macOS. Not sure what's happening though, but wanted to corroborate what @s1341 is saying.

Here is a new release v2.0.0 where all MacOS problems are fixed (at least for me - tested it on MacOS run in VirtualBox).
Thank you for reporting this!

Confirmed working. Thanks for the prompt fix!

Works for me as well. Awesome, and thank you 👍

The latest release gives me the same bug again, Error: timeout. v2.3.5 still works for me though.


Added support for file output.

Allows the specification of a file to which the output would be written from the CLI instead of just printing to standard output. Makes API doc easier to share.

Sure, nice suggestion! Will merge it later. I will probably change the CLI parameters to options with minus signs (like Unix style - without a strict ordering), so something like -b swagger -o file -v 0.1 as there are already too much options :-)

That's nice. I'm also thinking that since there are many options already, and backends list could also be growing, perhaps (just perhaps) you can make the option and backend selection a bit more robust (instead of if/else that suffices for not so many options). Just an enhancement though.


fix(WebView): Guarantee WCAG AAA color contrast ratios

With this, we are fixing the webview to guarantee that the color
contrast is following the WCAG AAA standard.
(https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html)

Noice. Can you clean up the conflicts?


exec the commands from Alfred in a new open tab , but not the same tab  ,same session

exec the commands from Alfred in a new open tab , but not the same tab  , same session.
People （may just me .....）may not like to be  interrupted  at  the current job( like  change the now DIR  in Iterm). It is better for me to open a new tab.

Hello,
Stuart no longer has the time to maintain these scripts, and as such has been kind enough to transfer the repository to me. I’ve shortened the code, made it always open a command in a new iTerm tab, and removed support for older iTerm version.
You might know me as vitor from the Alfred Forums or if you’ve ever contributed to Homebrew Cask.
I’m reviewing issues and pull requests right now. I’m closing the latter as I’ve revamped all the files in the repo.
The new version always opens in a new tab.
Try the new script.


Add named arguments for commands

Make it possible to use named arguments for bot commands.

Closing this as it's parser work that requires fundamental changes to the parser in order to work correctly, rather than just tacking on new code. It'd be a nice to have but the amount of effort does not meet the perceived gain, especially since this would mean there is a good chance of a lot of other code breaking.


Save Error when Sync is used as NSOperation

Hi Florian, would you mind sharing a bit of what's this trying to solve? Would be nice to get some perspective in order to see if we can provide a better alternative.

When using Sync by creating an instance of Sync instead of directly calling Sync.changes(), which is necessary in some cases, the error that can appear when Sync.start() calls changes is not accessible anywhere.
That's why I I'm saving it to a variable in the Sync class that can be accessed through a property.

@thestr4ng3r That makes total sense! Damn, I get what you mean now.


Add custom invoice dialog

Working for "add credits" as of https://github.com/macterra/artx-market/commit/10aef77115760ead52a8669e11294702352e8ecc

Working for purchasing NFTs now


Add y86 tools for CS 261

This installs y86ref, yas, and ysim. Additionally, a man page is
installed for y86ref.
Resolves #128

You can see the man page with man y86ref, but to make it easier to read, the formatted version is below. Rendered with groff -man -Tascii roles/y86/files/y86ref.1
Y86REF(1)                        User Manuals                        Y86REF(1)

NAME
       y86ref - y86 mini-elf file interactions reference solution

SYNOPSIS
       y86ref [OPTION]...  file

DESCRIPTION
       y86ref  reads  .o  files made for the imaginary y86 processor architec-
       ture, and prints information based on flags given. This is a  reference
       solution to the PAs assigned over the course of the semester.

OPTIONS
       -h     display usage information

       -H     show the Mini-ELF header

       -a     show all information about the program with brief virtual memory
              output

       -f     show all information about the program with full virtual  memory
              output

       -m     briefly display virtual memory

       -M     display all contents of the virtual memory

       -s     show the program headers in the file

       -d     display  the  assembly operations contained in all code segments
              of the file

       -D     display the data segments contained in any  read  only  or  read
              write segment in the file.

       -e     execute the y86 program

       -E     execute the y86 program in debug trace mode

NOTES
       Specific  questions about y86ref or your programming assignments should
       be directed to your CS261 professor.

SEE ALSO
       gdb(1), hexdump(1), objdump(1), readelf(1), elf(5)

Linux                             AUGUST 2018                        Y86REF(1)


add amortization time

Description of the issue
Simple addition of amortization time.
I would be grateful if someone from @OpenEnergyPlatform/oeo-domain-expert-economy could provide a more profound definition than I did below.
Also, is there a difference between amortization time and economic life time or are they synonyms?
Ideas of solution
amortization time: The amortization time is the time span it takes for an investment to pay off.
Synonym: economic life time ?
Workflow checklist

[ ] I discussed the issue with someone else than me before working on a solution
[ ] I already read the latest version of the workflow for this repository
[ ] The goal of this ontology is clear to me

I am aware that

[ ] every entry in the ontology should have a definition
[ ] classes should arise from concepts rather than from words

@han-f can you support?

How about making this a bit more specific: The period in which the acquisition costs are refinanced from the annual profits and depreciation of the investment.
Derived from: https://de.wikipedia.org/wiki/Amortisationsrechnung
Economic lifetime is how long something can be used while generating more income than costs: Economic life refers to the length of time an asset is expected to be useful to the owner. It is also called useful life or depreciable life. The measure of an asset’s usefulness is how profitable it is to keep – in other words, how long an asset generates more income than it costs to maintain and operate.
https://corporatefinanceinstitute.com/resources/accounting/economic-life/

Thanks for the input!
I tried to put it into definitions. What do you think about these?
amortization time: An amortization time is the time span in which the investment costs are refinanced from the annual profits and depreciation of the investment.
economic life time: An economic life time is the operational life time during which an object is profitable to the owner.


Problems with go get.

I have go version 1.2.1 linux/amd64 from the 14.04 Ubuntu repositories. This version matches the version in the example at the top of the readme. A few search results on the errors suggested using a newer version of go. Was something changed that broke this for the repo version?
Here are the errors after running go get github.com/sselph/scraper
# github.com/sselph/scraper
.go/src/github.com/sselph/scraper/scraper.go:738: unknown net.Dialer field 'KeepAlive' in struct literal
.go/src/github.com/sselph/scraper/scraper.go:740: unknown http.Transport field 'TLSHandshakeTimeout' in struct literal

Sorry I moved my version of go to 1.4.2 and didn't test if I was backward compatible. I am thinking of adding some build testing to catch this in the future. I'll investigate if I can implement this same functionality without requiring newer versions of Go.

Let me know if that fixes things. I merged in a bunch of changes one which should take care of the build issues in go1.2

That was a fast response! Yes, the fixes seem to have worked. It compiles with stock go from the repos now. I will close the issue. Thanks you!


Drop assigning cheapest shipping method in checkout

If a shipping method becomes invalid in checkout, we should clear it and let the user pick a different one. This PR changes checkout behavior to clear the shipping method in this case.
Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Task linked: SALEOR-4140 Drop assigning cheapest shipping method in checkout when previous method becomes invalid


Fix release builds

Description
Fixed some release builds

x86_64-apple-darwin
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl (statically linked)
aarch64-unknown-linux-gnu

Added documentation
TODO: (most likely in another PR)

aarch64-unknown-linux-musl (a must)
armv7-unknown-linux-gnueabihf (nice to have)
armv7-unknown-linux-musleabihf (nice to have)

@evanxg852000 I think you nailed the problem. We could also use this https://docs.rs/openssl-probe/0.1.4/openssl_probe/
to sniff the right path for OpenSSL cert.


assigning this to late attribute in the same class should be illegal

As it turns out, it's really easy to exploit the fact that it isn't illegal:
class A()
{
    late A self;
    self = this;
    print(self.a);
    String a = "";
}

Thanks @Zambonifofex, but this is a dup of #4273.


Update flannel migration doc

Description

Update flannel migration doc
Related issues/PRs

Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

None required

Deploy preview for calico ready!
Built with commit 4f4e637f617e4d40b1491a56e2dcd484002582dd
https://deploy-preview-2839--calico.netlify.com


Update site-recovery-limits.md

Can we please use the full official term here? The Japanese translation for "Azure vault" has come through as something completely unrelated, which I imagine is due to false positives in translation memory. I'm hoping fixing the source will eventually trigger a retranslation into the correct term (Recovery Services コンテナー) in Japanese.

@dcbrown16 : Thanks for your contribution! The author(s) have been notified to review your proposed change. @csilauraa

Actually I just noticed a second issue as well. Per doc below, 100 servers can be added to a plan.

Up to 100 protected instances can be added to one recovery plan.
https://docs.microsoft.com/en-us/azure/site-recovery/recovery-plan-overview

I'm guessing that the "100 servers" info is more up to date. As far as I can see that was added in the other doc in Oct 2019:
https://github.com/MicrosoftDocs/azure-docs/blob/e477c496f205092e497a699d3f4ab1384807f39d/articles/site-recovery/recovery-plan-overview.md
Whereas the "50" figure has been unchanged here (limits insert) since 2015.

@jwhit - Could you review this pull request? I don't turn up a GitHub account for csilauraa. Thanks!

@LauraWi might be the csilauraa we are looking for? Also, looks like last notification went to the wrong account, should be @jwhit-MSFT.
I sent an internal email to the ASR PG as well to see if I can just get someone to comment here.

@MaggiePucciEvans - Can you help review this PR in the public repo?

@dcbrown16 Is there a specific reason you submit updates through the public repo? I see that you have permissions to work in the private repo, and most vendors do work in the private repo. If you open a PR in the private repo and want the content team or someone else to review it before you sign off, you can request a review in a comment in the PR before sign-off, or use the Reviews functionality in the GitHub UI to request a review before you sign off.

Hi folks, I'm not the Laura you're looking for and I don't have perms for this repo. I will forward the email notification to a Content Publishing Manager who can help.

I hadn't ever figured out how to post in the private repo, but I guess I just add -pr to the repo name? I'll attempt to do that next time.
Internal DL asked @rayne-wiselman to review this change. @sideeksh agreed with my assessment of the content.

@sideeksh, please confirm that the number of servers per recovery plan is correct.
@dcbrown16 Please use the internal repo to make changes. That will provide a smoother path for you, and allow us to audit changes more simply.

Sure, I'll try to do that going forward.
Posting Siddharth's comment from the email below, you should be CCed on that as well @rayne-wiselman

The limit for Recovery Plans is 100 and not 50. Agree with you that the nomenclature should be ‘Recovery Services Vault’

verified with Dillon #sign-off

@rayne-wiselman: I'm sorry - only the author of this article, @csilauraa, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

@ktoliver Can we get an exception for sign-off. The assigned owner is no longer at the company. Thx!


Provide sync instructions

What does this PR do?
Now that tests run async by default, this provides instructions on how to wait for test results. Also updates help docs to reflect the change to async by default.
I originally used some oclif flag relationships to enforce this suggestion, but a lot of these flags are tightly coupled and it caused other issues. I think this quick fix is sufficient for now.
Another semi-related change: For some reason, if you passed --synchronous and --json it would immediately return with the testRunId. That made no sense to me, so I changed it. Let me know if you can think of a reason that this was the case.
QA Suggestions

Run with sf apex test run

Confirm get command is logged as well as sync suggestion

Run with sf apex test run --json

Confirm the testRunId exist in json
Thought: We could push the "sync instructions" to the warnings array 🤷♂

Run sf apex test run -w 1

Confirm results are printed to stdout

Run sf apex test run -w 1 --json

Confirm results are printed as json to stdout

Run sf apex test run -y

Confirm results are printed to stdout

Run sf apex test run -y --json

Confirm results are printed as json to stdout
NOTE: This is the other change listed above, this used to immediately return.

What issues does this PR fix or reference?
https://github.com/forcedotcom/cli/issues/2162
@W-13486954@

QA notes:
run and get a test
✅ shows the get command and the --synchronous suggestion
📓 I'm ok without more warnings in the json.
test with --wait 1 on 1 test (-t)
✅ shows test results
test with --wait 1 with all tests
✅ shows test results  (tried to make it time out but that pesky Salesforce is just too fas!)
test with --wait 0 with all tests
✅ async, shows new message
✅ shows testrunId if --json
❓  -w 0 -y What should happen here?  Is it asynchronous or not?  Or should we throw a warning/error from validateFlags to help the user fix that conflict?
-y --json
✅ good results to stdout.

That made no sense to me, so I changed it
about 500 executions/week use --json with --synchronous , out of the 2900/week that have --json on it.  About half of the coincidence is CI.

I agree that this is a better UX.  I think if you really want to change the json behavior, we should put a warning on that coincidence of flags, and give people the full 4 months to adjust.  ex:

WARNING: using --json and --synchronous currently [describe current] .  After [date] we will change it to [new behavior]
if you want to continue getting the testRunId in json, use [various ways to get that]
if you want the new behavior now, you can [ -w --json ? ]

you could even put a date-based gate(s) on the behavior and a to-do to remove it later if you want.

-w 0 -y What should happen here? Is it asynchronous or not? Or should we throw a warning/error from validateFlags to help the user fix that conflict?

I think that the current functionality is what I would expect since the default is async tests and -w 0 is essentially the same. Passing -y would overwrite the default to run sync.


Offical docs about create native ui component may be something wrong.

I want to create a native android component, so i exetend SimpleViewManager , but the src property setting method in offical docs show this way:
@ReactProp(name = "src")     public void setSrc(ReactImageView view, @Nullable String src) {         view.setSource(src);     }
but the setSource method by  ReactImageView need another parameter ResourceDrawableIdHelper Like this below:
@ReactProp(name = "src")     public void setSrc(ReactImageView view, @Nullable String src) {         view.setSource(src, new ResourceDrawableIdHelper());     }
Problem is the class ResourceDrawableIdHelper has package access, i can't construct it.
Is the framework update but the docs  or the docs with something wrong.
I am new to reactive , so i don't know how to do with the problem docs.

same question~
So, how to set the source of Image in custom view？

No idea...maybe you can see fresco's source code.
发自我的 iPhone

在 2016年6月7日，12:24，Liang Jianbin<EMAIL_ADDRESS>写道：
same question~
So, how to set the source of Image in custom view？
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

So, are there any news?  Any suggestions?

ResourceDrawableIdHelper has a getInstance() method.

Closing this issue because it has been inactive for a while. If you think it should still be opened let us know why.


Fix TypeError when JSDoc.tags is undefined

This fixes 'TypeError: Object is not iterable' errors in fourslash tests when the compiler is built with '--target=es2015'.
The errors occur because the preexisting code depends on the current '--target=es5' transformation of the spread into a call to .apply(), which is more permissive.  (See issue see #14362 for more details.)

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot


How to get file name after upload?

Hello.
Some question here... so how to get file name after upload?
I want it to save in my DB (using Django as backend for my API).
Thanks!

Same question


First pass edit of create-new.

Hello HDOCS team,
Please review the change from 'individual' to 'internal' Subject Matter Experts. (line 39, may be missed under the other changes made there).
Left that occurrence of Subject Matter Experts capitalized because (I believe - see above) it refers to in-company terminology. The following reference to 'external subject matter experts' was left uncapitalized because they are not within the company.
Kind regards,
Paul

Hi Paul,
the change from individual to internal SME is fine.
Subject Matter Expert is a generic term so it probably does not need capitalizing, I think it works either way.
Thanks
Gerry


Add API to query leaderboard rank and return nearby records

Additions to the leaderboard API would allow a user to query their rank and neighbouring scores.
The API would need to return:

The player's numeric rank in the leaderboard
Player's record in leaderboard
Records above rank
Records below rank

Suggested additional API parameters:

Reference to User
Count of records above player rank
Count of records below player rank

This is commonly used in titles such as Golf Clash and PSN leaderboards (screenshot below)

I'm wishing this feature too !

This feature has now landed in master (841307ec142cd7ce7451eb4ffba43750d3b4ff01) and will be available in the upcoming Nakama 2.1 release.
As part of this changeset:

Ranks are calculated and cached on the server. This means that you can get not only the top X players, but also specific players' ranks and surrounding players (haystack query).

A new tournaments API is available - where you can define a tournament (backed by a leaderboard), join, submit records, and list records. Tournaments can have a start time, end time, a duration and a reset schedule. When the tournament duration elapses or tournament resets, the server emits events that you can match on in the Runtime to execute custom functions, for instance to distribute rewards to the top 10% of the players who participated in the tournament.

I think the combination of these two features satisfies the request in this issue. Feel free to reopen if you'd like to add more info/requests.


Back button doesn't work if not on tab 1 when implementing tabs in a subcomponent

When tabs are implemented in a subcomponent of the main router, the Back button in the TabView screen only works if you're on Tab 1. Once you switch to a different tab, clicking Back triggers the error: Cannot pop navigator with less than 1 screens. Example code is here

The problem that View as parent container doesn't pass 'navigator' property to his children, so navigator's hierarchy is lost. I'm not sure how to fix it, maybe we need to declare it as not bug, but 'feature' - i.e. require to avoiding inner Routers inside React Views...
However I will try to fix it using react 'context' by passing router instance as 'current' router, maybe it will work.

From other point of view, context is not good idea to use (like 'global' vars), so maybe it will be more correct to do deep parsing of routers/routes, i will think.

Okey, it doesn't have any sense to built some 'smart' here, just by-pass props to children to make it work
          <Router footer={TabBar} showNavigationBar={false} navigator={this.props.navigator} schemas={this.props.schemas}>

This works. Thanks. Any reason why <Router> couldn't automatically pass its props?
Also, perhaps I need to file another issue but when the tabs are in a subcomponent and tabs are switched, they don't really switch, they are pushed. A back button appears in the Title bar and by clicking it you can backtrack through the tabs you pushed. This doesn't happen when the tabs are part of the main component, as in your example: Each tab replaces the previous one, and I believe that is the expected behaviour for tabs.

@chetstone What do you mean - Router couldn't automatically pass its props? It already does - but View will not pass everything to its child and Router is not able to check all children (including children of children) without instantiation of all 'component' during launch recursively. It will slow down performance significantly - all UI screens have to be created during startup.

I hope later we will be able to replace it within your customized UI screen:
          <Router footer={TabBar} showNavigationBar={false} parent={this.props.route}>

What do you mean - Router couldn't automatically pass its props?

Ah, I see where I was confused. I have
<Route name="tabbar" component={TabContainer} />

and in another file <TabContainer/> has:
return (  <Router footer={TabBar}> ... )

The problem we need to work around is that TabContainer doesn't pass its props to Router. Gotcha.
I'm not sure if I understand this comment though:

I hope later we will be able to replace it within your customized UI screen:

Are you talking about a contemplated change to react-native-router-flux or are you suggesting another way for users to work around this issue?

Never mind. I was the thinking about some refactoring
Pavel.

15 дек. 2015 г., в 19:50, Chester Wood<EMAIL_ADDRESS>написал(а):
What do you mean - Router couldn't automatically pass its props?
Ah, I see where I was confused. I have

and in another file  has:
return (   ... )
The problem we need to work around is that TabContainer doesn't pass its props to Router. Gotcha.
I'm not sure if I understand this comment though:
I hope later we will be able to replace it within your customized UI screen:
Are you talking about a contemplated change to react-native-router-flux or are you suggesting another way for users to work around this issue?
—
Reply to this email directly or view it on GitHub.


Update dependsOn list with Smaller Providers

Description of your changes
This PR is an example usage of smaller providers in a configuration.

Fixes #
I have:

[ ] Read and followed Upbound's contribution process.
[ ] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR, as appropriate.

How has this code been tested
Built and push the configuration and created cluster-claim.

/test-examples

We will need uptest setup script changes at https://github.com/upbound/platform-ref-gcp/blob/main/test/setup.sh#L15-L16 before merging this PR

/test-examples

/test-examples

/test-examples

/test-examples

/test-examples


Ripping Reddit users is not ripping all of their stuff.

Ripme version: 1.5.15
Java version (output of java -version): (build 1.8.0_151-b12)
Java HotSpot(TM) Client VM (build 25.151-b12, mixed mode, sharing)
Operating system: Win 10 64bit
Exact URL you were trying to rip when the problem occurred: https://www.reddit.com/user/kawaiiikitty
Please include any additional information about how to reproduce the problem:
A lot of users aren't having their non reddit/imgur sources ripped properly.

Expected Behavior
To rip all links submitted
Actual Behavior
Misses a lot of links.

Hey, this is the old (And basically abandoned) repo. You should resubmit this over at https://github.com/ripmeapp/ripme
On the issue itself the ripper only rips from a few select sites, if you can give me the sites that the ripper doesn't rip from I can see if I can add support for them

https://github.com/RipMeApp/ripme/issues/174

https://github.com/RipMeApp/ripme/issues/90


Fix to open folder containing the log file rather than roaming folder

PR Checklist
Please check all that apply to this PR using "x":

[ x ] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[ x ] I have checked that this PR does not introduce a breaking change
[ ] This PR introduces breaking changes and I have provided a detailed explanation below

PR Type
What kind of change does this PR introduce?

[ x ] Bugfix
[ ] Feature
[ ] Breaking changes (bugfix or feature that introduces breaking changes)
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] Documentation changes
[ ] Other - Please describe:

Fixes
Issue Number: #1600
What is the current behavior?
Clicking "Open Log Folder" will open the "lbry" folder with "lbrynet" highlighted, rather than opening the "lbrynet" folder which contains the log file.
What is the new behavior?
Clicking "Open Log Folder" will open the "lbrynet" folder that contains the log file.
Other information

hey @dyllper, thanks for submitting this PR! We'll have someone review it shortly. Can you also add a changelog entry for this (see previous entries for format).
Make sure to check out our contributing document.
Once this is merged, can we send you some LBC as appreciation?

@tzarebczan Updated the Changelog! Sorry about that. Missed that section when I was reading through the CONTRIBUTING.md file.
Thank you for the offer of LBC, but that won't be necessary. Just happy to be able to help out!

@dyllper how about a Hacktoberfest t-shirt from LBRY? Just reach out to us at the same address :)

Tested and working good! Thanks @dyllper 🙂


add a tab with default extensions to extension manager

Adds a new tab that allows disabling/enabling default extensions (this functionality is already available, so this PR is mostly about displaying the list of default extensions).
Maybe we could use a different icon but I'm not capable of producing one and this can be replaced in a separate PR after this is merged.
Tagging @swmitra @redmunds to review as per discussion in #13108 but others feel free to chime in.

I like how things come back https://github.com/adobe/brackets/pull/11618
I gave a try and seems I cannot disable the default Dark theme or JSLint.

Interesting, did you try it on Mac or Windows @ficristo ?

The thing it came back again probably means we should finish it this time 😄

Nice @ficristo! I remembered that PR but couldn't find it myself.
👍 for the idea from me. Adding descriptions for the default extensions that don't have them would be nice.

I think disabling the Default Theme should not be allowed. Isn't that what gets used when you Restart Without Extensions ?
Also, JSLint extension is enabled by default. Maybe code needs to verify existence of linting module before trying to use it?

Disabling themes (as it makes little sense) has been forbidden in https://github.com/adobe/brackets/pull/13136/commits/2d197fba7fcaf1281eba73146459efcbef78592d

Ok guys, did a few changes, please have a look. I've tested disabling/enabling JSLint and it works fine.
I've also tested disabling all the default extensions (except themes which now can't be disabled) and Brackets did startup just fine. I've added a warning to the console logs about the default extension being disabled. As it might help with bug reports.

@zaggino Built code, did minimal testing, and seems to work as advertised. Made a pass through code -- looks good. Awesome!

I tryed again and JSLint is disabled by default and I cannot enabled. Is it normal or it is maybe related to my system?
In the preferences I have: "extensions.default.disabled": []

@ficristo if you have tried previous version, look at JSLint's directory if there's not a .disabled filename present and delete it or run git clean -fdx && npm install ... I had the same issue and this fixed it.

Running git clean fixed it.
I wanted to disable JSLint only for Brackets so I added the preference to disable it in .brackets.json.
But JSLint is still available. Is this configuration not supported?

I don't think this could work per project @ficristo if that's what you're trying to do. The place where the extensions are being loaded does not consider which project you're in and neither does this get executed when you switch projects. While it wouldn't be hard to enable an extension when you switch to other project, it would be very difficult to disable one when you switch to a project which has it disabled in .brackets.json because disabling an extension basically means reloading whole editor. Now I know VSCode does that, maybe even Atom (reload whole editor when switching projects) but we currently don't and that'd be potentially huge change how Brackets work.

Any more comments @adobe/brackets-committers ?

@swmitra can anyone in your team review this please?

With PR #13245 merged, the @extension-manager-min-width may need adjusting

Very nice @zaggino 👍.
Tested this branch just now and everything seems to be working fine. I just have one small comment (But that would not block me to merge this PR now :smile), If we can cook some description for the default extensions to provide some meaningful info to the user based on which they can decide whether to disable any default extension!

@zaggino Can you please increase the min-width of the EM Dialog to ~760px?

@swmitra where's this min-width set?
I can see that EM has the width hard set to 760px here: https://github.com/adobe/brackets/blob/master/src/styles/brackets_patterns_override.less#L1026-L1029

I'll add descriptions to the default extensions in another PR, to prevent ongoing discussions what it should be :)

ah, found it @swmitra @justinrusso please check if https://github.com/adobe/brackets/pull/13136/commits/d6cf7c07241fd5e39dc7fe0cc09a1bec7db954b8 is correct

@zaggino Yes that's the place. I was about to reply but you are fast 😄 I have tested this feature and works as expected. Merging ...


Sphinx does not document special methods by default

I was looking for the docs we have on Context.__init__, and couldn't find them in the rendered documentation. Turns out, Sphinx does not render docs for "special" methods, including the constructor, by default. A couple different routes to resolving this:

(A) Move any __init__ docs up to the class level. Example in sphinx docs
(B) Alternatively, tell sphinx we want to document special methods, too. SO
(A+B) Or both: I think documenting constructor params at the top makes a lot of sense... but if we've got any special behavior on magic methods, we could document them, too.

I would lean towards just (A).

Agree with (A). Nice catch!


Letters in signatures always get incremented. Results in running out of letters quickly.

This test script:
from __future__ import print_function

from hask import H, sig, _t

for x in range(10):
    @sig(H / 'a' >> 'b')
    def f1(a):
       return a

    @sig(H / 'a' >> 'b')
    def f2(a):
       return a

    print('f1:', _t(f1))
    print('f2:', _t(f2))

Produces this output (Note:  _t has been modified to return instead of printing.) :
f1: (a -> b)
f2: (c -> d)
f1: (e -> f)
f2: (g -> h)
f1: (i -> j)
f2: (k -> l)
f1: (m -> n)
f2: (o -> p)
f1: (q -> r)
f2: (s -> t)
f1: (u -> v)
f2: (w -> x)
f1: (y -> z)
f2: ({ -> |)
f1: (} -> ~)
f2: ( -> ?)
f1: (? -> ?)
f2: (? -> ?)
f1: (? -> ?)
f2: (? -> ?)

Wouldn't it be better start afresh with a for each function? There are two cases were this really matters:

Defining many functions.
Working interactively, for example in an IPython Notebook, and redefining a function again and again.

Both scenarios can lead to a running out of printable characters.

I agree; it might also help to use numbers (e.g. a1), which ghci also does.

I should add--letters are not actually "used" until the type signature is printed. The type variables themselves have unique (integer) identifiers within the type system; these are mapped to letters lazily, at time of printing.
As a quick fix, _t could be modified so that it resets the pool of letters when it is called. However, I think a larger revamp of the type printing system makes more sense, because of the problem highlighted in #15.


Allow specs to be nested, for mappers that use other mappers

This is supported in the current grammar and construction logic.


Add command line option to print URL/path/link to generated documentation

I use cargo doc --open to generate/update docs and open them in a browser, but often I want to view them in a non-default browser.   Sometimes I want to use the viewer built into my IDE, sometimes I'm testing out a new browser, etc.
It would be nice if either cargo doc printed the URL/path/link to the newly generated docs when it was done (similar to how cargo test prints "Running target/debug/deps/foo"), or if a new option like cargo doc --link, cargo doc --url, etc could be added to do this.
If either of these sounds like a reasonable idea I could take a crack at putting a pull request together?

Sounds like a reasonable idea to me!

@cpick I wasn't sure if you were working on this, so I've submitted #5592, which print the path to the generated docs. I hope I didn't step on your toes, if you already have started working on this I'm happy to withdraw my PR.

@esteve no I hadn't gotten to it, this is great!

Any update on this? A --path like rustup doc --path would be very nice for people who use WSL, where none of the default browser commands work. --open will print the URL as part of the error message, but that only helps if you don't have something installed which might accept the command despite not actually showing a browser window. (e.g. I had to add a www-browser no-op script to get something else to work; luckily, it's no longer on my $PATH, so it didn't cause issues)

As someone who uses Windows/WSL2, it would be nice to have rustup doc work.  I can export BROWSER=firefox.exe, and then rustup doc --std opens firefox, but the browser is empty; no error, nothing in the URL bar.
From a bash window, if I run this:
firefox.exe file://///wsl$/Ubuntu/home/name_redacted/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html

... Firefox opens to the Rust documentation I want.  Could rustup doc potentially figure out that path and for WSL?

Simple workaround: BROWSER=echo cargo doc --open

@janpaul123 Clever! Although to be clear I'd still like to have proper support; this is a wonderful hack but still a hack haha


fix(common): justify intervals before hashing

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
PLEASE DO NOT LEAVE THIS EMPTY !!!
fix https://github.com/singularity-data/risingwave/pull/4575#issuecomment-1211628595
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)
Fixes #3873

Could you please add the test case to e2e_test/streaming to prevent regression?

Could you please add the test case being fixed to e2e_test/streaming to prevent regression?

Could you please add the test case being fixed to e2e_test/streaming to prevent regression?

added

Could you please add the test case being fixed to e2e_test/streaming to prevent regression?

added


Never hardcode the path for Homebrew

Having issues running dinghy when using a non-standard homebrew install path (/opt/boxen/homebrew in my case).

Thanks, I had to tweak this a bit since travis builds aren't OS X based https://github.com/codekitchen/dinghy/commit/cd3cadc2df5788ef4c3d8fe0ed0074fc6c9e6d09
Not that the travis build can do a whole lot anyway, but there it is.


Resource interchange problem when using x:Shared="False"

I think the problem with x:Shared="False" is a .NET problem. I have reported the issue in Microsoft Connect
This item is to not forget about the issue and have reference to Microsoft Connect site.
@punker76

@xxMUROxx There is now a new MahApps.Metro.Resources 0.6.0 which includes a new resource IconsNonShared.xaml. It contains the Icons with the x:Shared="False", so all other users who doesn't need this and had the same issue with the exception can now sleep again :-D

-> https://github.com/MahApps/MahApps.Metro.Resources/issues/1


Live: clean up root checkpoint injection to mapper

Currently, we use a Loader to load the root checkpoint. We should get rid of that component, or at least move it to a stand-alone initializer package, like the protocol state initializer. Then, we should simply provide the root trie to the mapper as an optional parameter. When resuming state (see #79), we will not need a root checkpoint, as we can read the root ledger registers from the index database, just like the others.

@awfm9 Could you elaborate? What is the problem, what are potential solutions?

Doing as part of #79.


Deploy local-setup on virtual machine using Packer & Vagrant

Refs #8
Here we introduce some provisioning scripts and Packer & Vagrant configs which can be used to run the local-setup repo on a separate virtual machine and avoid all the problems which occur when doing this manually on local development machines.
Provisioning scripts are divided into two directories:

local-setup-environment: those scripts are responsible to prepare the environment containing all prerequisites needed to install local-setup and run the E2E test scripts. Additionally, this directory contains a packerfile.json which can be used by Packer to build the environment as a reusable Vagrant box or Docker image (this one has limited functionality)
local-setup-instance: those scripts are responsible to run all auxiliary software and the local-setup installation script itself. Their outcome should be properly configured and ready to work local-setup instance. Additionally, this directory contains a Vagrantfile which can be used by Vagrant to run a provisioned VM automatically.

🤔 why vagrant and docker-compose rather than reusing the kube work we've already done with a local kube setup? Are we expecting better performance?

We can ignore the CI build here because this branch doesn't contain a CircleCI config.

If possible, we should do something about node-gyp errors. They are not failing end-to-end test but they are polluting logs and we may skip some important warning/error because we'll get used to ignoring the red ERR!.

and avoid all the problems which occur when doing this manually on local development machines.

Can you please summarize for future-us what those problems are in the PR description?

The problem with node-gyp is closely coupled with #14. I've found and article about it. We use node 11.15.0 as our main version so an old version of node-gyp is installed at the beginning. Then, when we switch to node 14.3.0 for e2e tests, such an old version of node-gyp is probably not fully compatible with the newer node version. I'll add a point about node-gyp to #14.

Some closing thoughts:

We don't need vagrant for end-to-end test implemented in https://github.com/keep-network/local-setup/pull/13. Docker is sufficient and that's how the test is implemented in that PR.
Vagrant is useful for local system testing and should be especially useful when working on integrations, not modifying the code of tBTC or Keep. I can imagine this type of local deployment to be especially useful for tBTC dApp developers (cc @ironng, @r-czajkowski)
Having vagrant setup, it's very easy to develop and test provisioning scripts for #13.

I was able to run the end-to-end test using local deployment and vagrant deployment a couple of times 👍

Pro-tip. If you ever encounter the problem like:
Monitoring Bitcoin for transaction to address bcrt1qfzqd4j9s6dn4458n6fsuyeguzpxw5hzlq4gu74...
Connecting to electrum server...
onError: [[object Object]]
(node:14472) UnhandledPromiseRejectionWarning: Error: failed to connect: [Error: failed to connect to electrum server: [Error: websocket connection closed: code: [1006], reason: [connection failed]]]
    at file:///home/vagrant/local-setup/tbtc.js/src/lib/ElectrumClient.js:41:13
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at Client.connect (file:///home/vagrant/local-setup/tbtc.js/src/lib/ElectrumClient.js:40:5)
    at Object.withElectrumClient (file:///home/vagrant/local-setup/tbtc.js/src/BitcoinHelpers.js:217:5)
    at Object.findOrWaitFor (file:///home/vagrant/local-setup/tbtc.js/src/BitcoinHelpers.js:286:14)

Make sure Electrum is running: sudo docker ps -a,
If not, kill the container sudo systemctl kill bitcoin, and wait for a moment until it boots again,
Run ./local-setup/deployments/local-setup-instance/provisioning/run-bitcoin.sh,
Start end-to-end test one more time.

It happened to me that Electrum shut down with no explanation 🤷


net-cf target framework breaks upgrade tool

[x] Include the log file upgrade-assistant.clef that is produced in the working directory
upgrade-assistant.zip

Describe the bug
The tool apparently cannot handle the net-cf target framework. I'm not even quite sure where it gets the problematic string from, since net-cf doesn't appear anywhere in the repo. Maybe in a nuget package dependency?
To Reproduce
git clone<EMAIL_ADDRESS>cd ProjectServices
upgrade-assistant .\src\Microsoft.VisualStudio.ProjectServices.sln

Select "src\Microsoft.VisualStudio.ProjectServices.Tests\Microsoft.VisualStudio.ProjectServices.Tests.csproj" as the entrypoint. After upgrading it to SDK style, the tool exits with an exception as specified below.
Exceptions (if any)
[10:29:36 ERR] Unexpected error
System.ArgumentException: Invalid portable frameworks 'net+win+wpa+wp+sl+net-cf+netmf+MonoAndroid+MonoTouch+Xamarin.iOS'. A hyphen may not be in any of the portable framework names.
   at NuGet.Frameworks.FrameworkNameProvider.TryGetPortableFrameworks(String shortPortableProfiles, IEnumerable`1& frameworks)
   at NuGet.Frameworks.NuGetFramework.ParseFolder(String folderName, IFrameworkNameProvider mappings)
   at NuGet.Client.ManagedCodeConventions.TargetFrameworkName_ParserCore(String name)
   at NuGet.Client.ManagedCodeConventions.TargetFrameworkName_Parser(String name, PatternTable table)
   at NuGet.ContentModel.ContentPropertyDefinition.TryLookup(String name, PatternTable table, Object& value)
   at NuGet.ContentModel.Infrastructure.PatternExpression.TokenSegment.TryMatch(ContentItem& item, String path, IReadOnlyDictionary`2 propertyDefinitions, Int32 startIndex, Int32& endIndex)
   at NuGet.ContentModel.Infrastructure.PatternExpression.Match(String path, IReadOnlyDictionary`2 propertyDefinitions)
   at NuGet.ContentModel.ContentItemCollection.FindItemGroups(PatternSet definition)+MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at NuGet.ContentModel.ContentItemCollection.FindBestItemGroup(SelectionCriteria criteria, PatternSet[] definitions)
   at NuGet.Commands.LockFileUtils.GetLockFileItems(IReadOnlyList`1 criteria, ContentItemCollection items, Action`1 additionalAction, MaccatalystFallback maccatalystFallback, PatternSet[] patterns)+MoveNext()
   at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source)
   at NuGet.Commands.LockFileUtils.GetBuildItemsForPackageId(IEnumerable`1 items, String packageId)+MoveNext()
   at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   at NuGet.Packaging.CollectionExtensions.AddRange[T](ICollection`1 collection, IEnumerable`1 items)
   at NuGet.Commands.LockFileUtils.AddMSBuildAssets(LockFileLibrary library, RestoreTargetGraph targetGraph, LockFileTargetLibrary lockFileLib, IReadOnlyList`1 orderedCriteria, ContentItemCollection contentItems, MaccatalystFallback maccatalystFallback)
   at NuGet.Commands.LockFileUtils.AddAssets(String aliases, LockFileLibrary library, LocalPackageInfo package, RestoreTargetGraph targetGraph, LibraryIncludeFlags dependencyType, LockFileTargetLibrary lockFileLib, NuGetFramework framework, String runtimeIdentifier, ContentItemCollection contentItems, NuspecReader nuspec, IReadOnlyList`1 orderedCriteria, MaccatalystFallback maccatalystFallback)
   at NuGet.Commands.LockFileUtils.<>c__DisplayClass2_0.<CreateLockFileTargetLibrary>b__0()
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
   at System.Lazy`1.CreateValue()
   at NuGet.Commands.LockFileBuilderCache.GetLockFileTargetLibrary(RestoreTargetGraph graph, NuGetFramework framework, LocalPackageInfo localPackageInfo, String aliases, LibraryIncludeFlags libraryIncludeFlags, Func`1 valueFactory)
   at NuGet.Commands.LockFileBuilder.CreateLockFile(LockFile previousLockFile, PackageSpec project, IEnumerable`1 targetGraphs, IReadOnlyList`1 localRepositories, RemoteWalkContext context, LockFileBuilderCache lockFileBuilderCache)
   at NuGet.Commands.RestoreCommand.BuildAssetsFile(LockFile existingLockFile, PackageSpec project, IEnumerable`1 graphs, IReadOnlyList`1 localRepositories, RemoteWalkContext contextForProject)
   at NuGet.Commands.RestoreCommand.ExecuteAsync(CancellationToken token)
   at NuGet.Commands.RestoreRunner.ExecuteAsync(RestoreSummaryRequest summaryRequest, CancellationToken token)
   at NuGet.Commands.RestoreRunner.CompleteTaskAsync(List`1 restoreTasks)
   at NuGet.Commands.RestoreRunner.RunWithoutCommit(IEnumerable`1 restoreRequests, RestoreArgs restoreContext)
   at Microsoft.DotNet.UpgradeAssistant.Extensions.NuGet.NuGetTransitiveDependencyIdentifier.RestoreProjectAsync(IEnumerable`1 packages, IEnumerable`1 tfms, CancellationToken token)
   at Microsoft.DotNet.UpgradeAssistant.Extensions.NuGet.NuGetTransitiveDependencyIdentifier.GetTransitiveDependenciesAsync(IEnumerable`1 packages, IEnumerable`1 tfms, CancellationToken token)
   at Microsoft.DotNet.UpgradeAssistant.Dependencies.TransitiveDependencyExtensions.IsTransitiveDependencyAsync(ITransitiveDependencyIdentifier identifier, String packageName, IEnumerable`1 packages, IEnumerable`1 tfms, CancellationToken token) in /_/src/common/Microsoft.DotNet.UpgradeAssistant.Abstractions/Dependencies/TransitiveDependencyExtensions.cs:line 110
   at Microsoft.DotNet.UpgradeAssistant.Extensions.Windows.WindowsComponentIdentifier.IsWinRt(IProject project, CancellationToken token)
   at Microsoft.DotNet.UpgradeAssistant.Extensions.Windows.WindowsComponentIdentifier.GetComponentsAsync(IProject project, CancellationToken token)
   at Microsoft.DotNet.UpgradeAssistant.MSBuild.MSBuildProject.GetComponentsAsync(CancellationToken token) in /_/src/components/Microsoft.DotNet.UpgradeAssistant.MSBuild/MSBuildProject.cs:line 128
   at Microsoft.DotNet.UpgradeAssistant.Extensions.Maui.MauiPlatformTargetFrameworkUpgradeStep.IsApplicableImplAsync(IUpgradeContext context, CancellationToken token)
   at Microsoft.DotNet.UpgradeAssistant.UpgradeStep.IsApplicableAsync(IUpgradeContext context, CancellationToken token) in /_/src/common/Microsoft.DotNet.UpgradeAssistant.Abstractions/UpgradeStep.cs:line 233
   at Microsoft.DotNet.UpgradeAssistant.UpgraderManager.<>c__DisplayClass9_0.<<GetStepsForContextAsync>b__0>d.MoveNext() in /_/src/components/Microsoft.DotNet.UpgradeAssistant/UpgraderManager.cs:line 168
--- End of stack trace from previous location ---
   at System.Linq.AsyncEnumerable.WhereEnumerableAsyncIteratorWithTaskAndCancellation`1.MoveNextCore() in /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/Where.cs:line 339
   at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 77
   at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 77
   at System.Linq.AsyncEnumerable.<AllAsync>g__Core|207_0[TSource](IAsyncEnumerable`1 source, Func`2 predicate, CancellationToken cancellationToken) in /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/All.cs:line 34
   at System.Linq.AsyncEnumerable.<AllAsync>g__Core|207_0[TSource](IAsyncEnumerable`1 source, Func`2 predicate, CancellationToken cancellationToken) in /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/All.cs:line 34
   at Microsoft.DotNet.UpgradeAssistant.UpgraderManager.GetNextStepAsync(IUpgradeContext context, CancellationToken token) in /_/src/components/Microsoft.DotNet.UpgradeAssistant/UpgraderManager.cs:line 76
   at Microsoft.DotNet.UpgradeAssistant.Cli.ConsoleUpgrade.RunAsync(CancellationToken token) in /_/src/cli/Microsoft.DotNet.UpgradeAssistant.Cli/Commands/Upgrade/ConsoleUpgrade.cs:line 70
   at Microsoft.DotNet.UpgradeAssistant.Cli.ConsoleUpgrade.RunAsync(CancellationToken token) in /_/src/cli/Microsoft.DotNet.UpgradeAssistant.Cli/Commands/Upgrade/ConsoleUpgrade.cs:line 78
   at Microsoft.DotNet.UpgradeAssistant.Cli.ConsoleRunner.StartAsync(CancellationToken token) in /_/src/cli/Microsoft.DotNet.UpgradeAssistant.Cli/ConsoleRunner.cs:line 61

Further technical details

Include the output of dotnet --list-sdks

dotnet --list-sdks
6.0.106 [C:\Program Files\dotnet\sdk]
6.0.203 [C:\Program Files\dotnet\sdk]
6.0.301 [C:\Program Files\dotnet\sdk]
6.0.400-preview.22316.6 [C:\Program Files\dotnet\sdk]
7.0.100-preview.5.22307.18 [C:\Program Files\dotnet\sdk]

Include the output of upgrade-assistant --version

upgrade-assistant --version
0.3.332101+9c357a4cb20b94a136feb6a9a7cdaf4fe400c7d1

Confirmed repro on main as of 750da0c1701f69cf0345f0eb95db4750727eb7b1
csproj has only been changed to SDK style w/ a Target Framework of net472 at the point of the exception. Debugging now.

@AArnott appears to be coming from Nerdbank.GitVersioning. I had to decompile & get sourcelink PDBs to follow it down, but eventually landed at this parsing:

is it possible we could simply update the version of this dependency and get rid of this issue? I'm betting the targets are incompatible with new Nuget.Versioning schemes as of 6.x and that's what we're hitting.

Running with -v option gives us this; looks like the problem is actually ReadOnlySourceTree nupkg:
[12:20:31 DBG] [NuGet] Unable to find a stable package ReadOnlySourceTree with version
  - Found 9 version(s) in nuget.org [ Nearest version: 0.1.37-beta ]
[12:20:48 INF] Saving upgrade progress file at C:\s\DevDiv\ProjectServices\src\.upgrade-assistant
[12:20:49 ERR] Unexpected error
System.ArgumentException: Invalid portable frameworks 'net+win+wpa+wp+sl+net-cf+netmf+MonoAndroid+MonoTouch+Xamarin.iOS'. A hyphen may not be in any of the portable framework names.

@mjrousos, @twsouthwick, @sunandabalu any suggestions here?

ReadOnlySourceTree is very old and deprecated. Removing our use of it is part of the overall upgrade plan for this repo as well. But I wonder how net-cf is considered invalid. AFAIK it was a legit and existing TFM at the time I wrote that package.

If I had to bet, Nuget.Frameworks evolved and at some point stopped supporting it outright; since it's the pkg that's throwing the exception.

Ok. It sounds like 'fixing' this would be complex, and can be avoided by removing this old dependency instead. Thanks for investigating.


Removed server glitch in domain servers directory

I am running using WDT for OSB domain installation.
In the model file I am removing default server by using the exclamation mark notation:
    Server:
        # Delete the osb server, which is created by default
        '!osb_server1':

This gets interpreted properly that this server is removed.
However, in domain's home servers directory I can find a catalog with "!osb_server" name:
-bash-4.2$ ls -al servers
total 8
drwxr-x---.  8 ninjainst ninjainst  143 May 25 12:29 .
drwxr-x---. 36 ninjainst ninjainst 4096 May 25 12:30 ..
drwxr-x---.  9 ninjainst ninjainst   95 May 25 12:28 AdminServer
-rw-r-----.  1 ninjainst ninjainst   14 May 25 12:29 AdminServerTag
drwxr-x---. 10 ninjainst ninjainst  108 May 25 12:31 OsbServer01
drwxr-x---. 10 ninjainst ninjainst  108 May 25 12:32 OsbServer02
drwxr-x---.  3 ninjainst ninjainst   22 May 25 12:27 OsbServer03
drwxr-x---.  3 ninjainst ninjainst   22 May 25 12:27 OsbServer04
drwxr-x---.  3 ninjainst ninjainst   22 May 25 12:27 !osb_server1

It contains security and boot.properties file:
-bash-4.2$ ls -lR servers/\!osb_server1/
servers/!osb_server1/:
total 0
drwxr-x---. 2 ninjainst ninjainst 29 May 25 12:27 security

servers/!osb_server1/security:
total 4
-rw-r-----. 1 ninjainst ninjainst 157 May 25 12:27 boot.properties

I think that at some point WDT ignores the exclamation mark and treats this entry as something to be created.
I am using WDT 1.9.11 version.

It turns out that this code part of domain_creator.py doesn't consider if the server name is "is_delete_name" (from model_helper.py):
        server_nodes = dictionary_utils.get_dictionary_element(self._topology, SERVER)
        servers = [self._admin_server_name]

        for model_name in server_nodes:
            name = self.wlst_helper.get_quoted_name_for_wlst(model_name)
            servers.append(name)

        admin_username = self.aliases.decrypt_password(admin_username)
        admin_password = self.aliases.decrypt_password(admin_password)
        encrypted_username = encryptionService.encrypt(admin_username)
        encrypted_password = encryptionService.encrypt(admin_password)
        for server in servers:
            properties = Properties()
            properties.put("username", encrypted_username)
            properties.put("password", encrypted_password)
            file_directory = self._domain_home + "/servers/" + server + "/security"
            file_location = file_directory + "/boot.properties"

@rakillen Hi! I can confirm that original issue is fixed (in 1.9.14 version), but I am not sure if in the right way. The reason is that if I have two machines with some OsbServers, then after domain installation I can see folders for all OsbServers in the AdminServer machine. Those that are targetted for other machines have only security/boot.properties file which is "redundant".

Please attach details about what you are seeing in the folder along with the correct model file.

Attaching the ls result of domain_home/servers and topology part of the WDT model:
wdt-issue-903-domain-servers.txt
wdt-issue-903-topology.txt

WDT does not create boot.properties on machines other than the admin server. this can be expected if you started your managed server, WLS pushes the boot.properties

If i understand you correctly.   This is the expected behavior.

creating the boot.properies are really targeted for developer environment.  If you specify production mode in the model, we do not generate boot.properties

Machine in WDT/WLS is just a construct.   This is not a directly pointing to any particular physical machine.  So, it's not like we have a directory structure machine-A:.../servera|serverb/...

When WDT created a domain it creates the entire domain structure in local disk,   just like any on premise domain $domain/...   So if you zip up the domain structure, you will always have $domain/servers//....  for every sever.

You can always manually remove the unwanted $domain/servers/  directory from each machine or use production mode in the model.

I can confirm that in production mode it works as you wrote and it is acceptable. Thanks!


Fix XFAIL/REQUIRES test lines to parse after llvm r293535.

@swift-ci please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 8c17fc5af4eca88d33e1112a47f65747739c4003
Test requested by - @bob-wilson

I don't know why the smoke tests didn't run yet. The one failure on macOS (ClangImporter/MixedSource/broken-modules.swift) is unrelated to my change. I'm going to merge this.


handlers/integration: fix(missing imports) & refactor(use camelize function)

Add all of the missing imports in one single PR


Inquiry Regarding Usage of SAM-Med3D Pretrained 3D Image Encoder for CT/MRI Datasets

Dear Author,
I hope this message finds you well. I am writing to you as a research with a keen interest in your groundbreaking work on the SAM-Med3D model. Your research has garnered significant attention in our community, and we are particularly impressed with the capabilities of your pretrained 3D image encoder.
My team and I are currently working on a project that involves analyzing CT and MRI datasets. We believe that the SAM-Med3D model could greatly enhance our research, specifically in terms of feature extraction from these 3D medical images. However, we are uncertain about the best approach to utilize your pretrained model for our specific datasets.
Could you kindly provide some guidance or instructions on how to effectively use the SAM-Med3D pretrained 3D image encoder with our own CT/MRI datasets? Any insights into preprocessing steps, model integration, or optimal usage practices would be immensely helpful.
We are eager to explore the potential of SAM-Med3D in our research and look forward to potentially contributing to the field with the insights gained from its application.
Thank you very much for your time and consideration. We understand the demands on your schedule and appreciate any assistance you can provide.

Hi, Littlequ, thank you for your recognition 😄
I conducted my fine-tuning experiments with nnU-Net settings, because nnU-Net can achieve SOTA performance for many tasks.
As for the optimal/effective usage of our pre-trained weights, based on the fine-tuning experience with SAM-Med3D and STU-Net, I would like to offer some suggestions for reference. The specific patterns for tasks still need to be further validated through experiments:

For preprocessing (e.g. target spacing), you can keep the optimal settings validated in training from scratch on downstream tasks. BTW, adjusting the learning rate can be helpful.
The same for data augmentation, using the optimal settings for specific tasks. For instance, for CT, you can clamp the window width and window level for specific targets, referring to nnUNet. If you need to process multiple modalities simultaneously, direct joint training usually also yields good results.


Tutorial on how to retrieve population numbers

Follow structure in https://oscovida.github.io/tutorial-accessing-cases-and-deaths.nbdata.html
tools/pelican/content/ipynb/tutorial...ipynb


Getting warning message: Prop className did not match with Next.js

Getting this warning in browser console:

Warning: Prop className did not match. Server: "tgui-6a12827a138e8827" Client: "tgui-6a12827a138e8827 tgui-865b921add8ee075"
at div
at eval (webpack-internal:///(app-pages-browser)/../node_modules/.pnpm/@xelene+tgui@2.1.1_@types+react-dom@18.2.25_@types+react@18.2.79_react-dom@18.2.0_react@18.2.0/node_modules/@xelene/tgui/dist/components/Service/AppRoot/AppRoot.js:33:21)

Minimal Next.js app with layout.tsx:
import<EMAIL_ADDRESS>
import { AppRoot, Placeholder } from "@xelene/tgui";

export default function Home() {
  console.log("Home");
  return (
    <AppRoot>
      <Placeholder header="Title" description="Description">
        <img
          alt="Telegram sticker"
          src="https://xelene.me/telegram.gif"
          style={{ display: "block", width: "144px", height: "144px" }}
        />
      </Placeholder>
    </AppRoot>
  );
}

Dependencies:
@tma.js/sdk 1.5.3
@tma.js/sdk-react 2.0.3
@xelene/tgui 2.1.1
next 14.2.1
react 18.2.0
react-dom 18.2.0

the same error with the same environment

Same here with this configuration:
  "dependencies": {
    "@telegram-apps/telegram-ui": "^2.1.4",
<EMAIL_ADDRESS>"^2.2.4",
    "next": "14.2.4",
    "react": "^18",
    "react-dom": "^18"
  }

Same issue

The same, but with Remix. No updates? How to handle this issue?


Delete sometimes initiated when I click on a tab to the left of the X

Describe the bug
Sometimes when I click on a tab, I receive the message "The following circuits are depending on ...Delete subcircuits of ... before trying to delete ...". See video.
Expected behavior
I expected to switch to the tab I clicked on.
Device Information [optional]:

OS: Windows 10
Browser: Firefox
Version: 77.0.1

Additional context
While I don't think it's project-specific, the video is of this project.
Are you working on this issue? (Yes/No)
No

the close button hover css property has been given a left padding of 1em in UI.css and that is the reason for this closing
as it is only given in the :hover property and not in the the class it is observed after hovering on it
this issue can be solved by changing the padding-left to margin-left
i will make those changes