Glassmorphic Signup page

I want to add glassmorphic sign-up under the DevIncept program. Can you please assign me this issue under DCP 21

please assign this issue to me.

@shivaprasadyanala i have to assign it to @KeerthanaPravallika due to first come first serve rule i will assign it you if its not completed on time

@KeerthanaPravallika any updates ??

@KeerthanaPravallika any updates ??

Yeah, it is almost done, will do PR today, busy with few exams these days


Fenix v.<IP_ADDRESS> & Fenix2GSX v.0.4.10

Does Fenix2GSX v.0.4.10 compatible with the new version <IP_ADDRESS> of Fenix A320?

Try it, heard nothing of the Contrary


More CI

adding some more helpful checks to CI builds
go fmt
go vet
-race command is something I learned about at gopherfest, it detects potential race conditions in code.  A friend was telling me they find this really helpful and use it on their CI builds.
More info on -race

[Current coverage][cc-pull] is 65.57%

Merging [#8][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master         #8   diff @@
==========================================
  Files             3          3
  Lines            61         61
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits             40         40
  Misses           21         21
  Partials          0          0

Powered by Codecov. Last updated by [fadd691...7fa85df][cc-compare]
[cc-base-branch]: https://codecov.io/gh/scootdev/scoot/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/scootdev/scoot/compare/fadd691f1306f7e42970c42b8e9be946bfe8d05e...7fa85df8d4a1cba986d45fef64d00d26f34a8676
[cc-pull]: https://codecov.io/gh/scootdev/scoot/pull/8?src=pr


fix Rsyslog-Error 2077

We are receiving Error-Messages regarding the Service-Fabrik.
Could not create tcp listener, ignoring port 514 bind-address (null). [v8.1901.0 try https://www.rsyslog.com/e/2077 ]

The syslog configuration currently will attempt to create a TCP-Listener for Port 514.
https://github.com/cloudfoundry-incubator/service-fabrik-boshrelease/blob/master/jobs/service-fabrik-broker/templates/config/syslog_forwarding.conf.erb#L6
However, this port 514 is located in the privileged area for which higher privileges are needed.
For safety reasons, the new version of Rsyslog will drop the privileges to a standard User.
See changelog Rsyslog 4.1.1

Dropping Privileges
Starting with 4.1.1, rsyslogd provides the ability to drop privileges by impersonating as another user and/or group after startup.
Please note that due to POSIX standards, rsyslogd always needs to start up as root if there is a listener who must bind to a network port below 1024. For example, the UDP listener usually needs to listen to 514 and as such rsyslogd needs to start up as root.
If you do not need this functionality, you can start rsyslog directly as an ordinary user. That is probably the safest way of operations. However, if a startup as root is required, you can use the $PrivDropToGroup and $PrivDropToUser config directives to specify a group and/or user that rsyslogd should drop to after initialization. Once this happend, the daemon runs without high privileges (depending, of course, on the permissions of the user account you specified).

It works at the moment, because the port is already created in the master configuration (/etc/Rsyslog.conf) before the permissions are dropped.
See:
https://github.com/rsyslog/rsyslog/blob/69f8e1d1f7fe62fd2c5f38a81d4102a9a62d1722/grammar/debian.conf#L21
This PR will reallocate the Listening-Port from 514 to 1514.
NOTE: Two-part PR
Please only merge this PR if the second PR ( https://github.com/cloudfoundry-incubator/service-fabrik-boshrelease/pull/159 ) can also be merged.

Pull Request Test Coverage Report for Build 2708

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.008%) to 89.966%

Files with Coverage Reduction
New Missed Lines
%

data-access-layer/cf/TokenIssuer.js
1
98.57%

Totals

Change from base Build 2703:
0.008%

Covered Lines:
8763

Relevant Lines:
9419

💛  - Coveralls


fix(send-all): Fixed race condition when working with testnet

:tada: This PR is included in version 2.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


on mobile: https://maps.googleapis.com/.... 404 Not found

With your example it works fine on desktop chrome but run as either virtual or physical Android apps I get: 404 Not found. For this url:
https://maps.googleapis.com/maps/api/js?v=3.exp&callback=GoogleMaps.initialize
If I manually load that address in a mobile browser it opens without a problem.
Using Meteor 1.0.4

That's unusual, would appreciate it if you can look into it further

Still looking, but doesn't appear to be your library.
Seems to be an issue with loading external libraries when on mobile device. If I manually add the head script tag for the google maps and lodash I get the same outcome (lodash = 404):
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/3.5.0/lodash.js"></script>
<script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?v=3.exp&callback=GoogleMaps.initialize"></script>

Above loads in libs for desktop but not mobile. Is there something different on mobile preventing loading libraries?

Not sure, maybe it's a platform restriction with external assets? Android development is not something I'm too familiar with.

We got it, woot!
<access origin='*' />

was removed from config.xml in Meteor version 1.0.4 see here
To add a more appropriate rule create a file in the parent level called mobile-config.js and add the following for you map library to work:
App.accessRule('https://*.googleapis.com/*');
App.accessRule('https://*.google.com/*');
App.accessRule('https://*.gstatic.com/*');

Oh good find, I actually think now that these two issues are related: https://github.com/dburles/meteor-google-maps/issues/15 https://github.com/dburles/meteor-google-maps/issues/12

Hi,
Can you tell me where should this config.js file be added if you are using the maps in a package?
I get Uncaught ReferenceError: App is not defined both on client and on server side.
Thanks.

@boboci9 have a look here http://docs.meteor.com/#/full/mobileconfigjs

Sorry I didn't know this was only for mobile apps, I am trying to find out why this package is not working in my project but it is a regular app in my case, and I have this same error.
I think I will repost the question in a new issue in this case, I thought it could be the same solution.
Thanks.

@boboci9 see if you can run the demo app https://github.com/dburles/meteor-google-maps-demo it may help with any problem you may have in your own app


Save running configuration

Hi! Thanks for reporting this feature/bug/question!
Please keep / fill in the relevant info from this template so that we can help you as best as possible.
For .NET Core users, please check the platform support: https://github.com/NLog/NLog/wiki/platform-support
Type (choose one):

Question
Is there a way to (re)configure programmatically and save the new resulting configuration to nlog.config or another file?  Any way to save it and reload it would be sufficient.

NLog version: 4.3.6
Platform:  .Net 4.5
Current NLog config both??
<nlog>
  <targets>
  </targets>
  <rules>
  </rules>
</nlog>

In case of a BUG:

What is the current result?
What is the expected result?
Did you checked the Internal log?
Please post full exception details (message, stacktrace, inner exceptions)
Are there any work arrounds? yes/no
Is there a version in which it did worked?
Can you help us by writing an unit test?

in case of a FEATURE REQUEST:

Why do we need it?
An example of the XML config, if relevant.

Hi @msanchez71,

Question Is there a way to (re)configure programmatically and save the new resulting configuration to nlog.config or another file? Any way to save it and reload it would be sufficient.

Yes, you can reload the configuration file by autoReload option.
Actually your question is not clear.

What do you mean by programmatically?
What do you mean by save?

When your configuration file changes?

Hello,
I am sorry I was not clear.  I want to make changes to the NLog config at runtime using the NLog.Config Namespace classes.  Then I need persist those changes to a file, preferably to the NLog.config file but any file would be OK.
Thanks in advance,
Mike
From: Uğur Aldanmaz
Sent: Wednesday, October 19, 2016 3:27 AM
To: NLog/NLog
Cc: msanchez71 ; Mention
Subject: Re: [NLog/NLog] Save running configuration (#1715)
Hi @msanchez71,
Question Is there a way to (re)configure programmatically and save the new resulting configuration to nlog.config or another file? Any way to save it and reload it would be sufficient.
Yes, you can reload the configuration file by autoReload option.
Actually your question is not clear.
a.. What do you mean by programmatically?
b.. What do you mean by save?
When your configuration file changes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Ok, I get it now. Unfortunately it is not possible yet. But it would be useful feature.
If you want, you can try to develop this feature and make a pull request to us.

I assume your question has been answered, if not, let us know!

Are there any updates on this?

@TsakiDev please open a new issue, or if it's a question, preferable on stackoverlfow.


Completion capability is ignored

With the following response to the initialize request, Sublime Text does not use my language server (textDocument/completion is not sent to my language server from ST when I press CTRL+SPACE).
LSP:  --> initialize
...
LSP:      {'capabilities': {'renameProvider': True, 'textDocumentSync': 2, 'implementationProvider': False, 'callHierarchyProvider': False, 'typeHierarchyProvider': False, 'documentHighlightProvider': True, 'documentFormattingProvider': True, 'documentRangeFormattingProvider': True, 'hoverProvider': True, 'workspaceSymbolProvider': True, 'typeDefinitionProvider': False, 'codeActionProvider': False, 'workspace': {'workspaceFolders': {'changeNotifications': True, 'supported': True}}, 'definitionProvider': True, 'referencesProvider': True, 'completionProvider': {}, 'documentSymbolProvider': True}}

Note that completionProvider is present but the sub-capabilities are all absent. As far as I can tell from the LSP specification the presence (non-nullness) of the completionProvider member should tell the client (ST) that the server supports textDocument/completion.
If a triggerCharacters member is added to the value of completionProvider, the completion requests are sent to my language server and everything works as expected. I.e. if my language server instead replies as follows:
LSP:  --> initialize
...
LSP:      {'capabilities': {'documentRangeFormattingProvider': True, 'workspace': {'workspaceFolders': {'changeNotifications': True, 'supported': True}}, 'callHierarchyProvider': False, 'workspaceSymbolProvider': True, 'definitionProvider': True, 'implementationProvider': False, 'documentSymbolProvider': True, 'completionProvider': {'triggerCharacters': ['(']}, 'renameProvider': True, 'typeDefinitionProvider': False, 'documentHighlightProvider': True, 'codeActionProvider': False, 'referencesProvider': True, 'hoverProvider': True, 'typeHierarchyProvider': False, 'textDocumentSync': 2, 'documentFormattingProvider': True}}

(Not everything works as expected even in this case, I had expected left parenthesis to trigger completion but it does not. CTRL+SPACE does work though.)

This was fixed a few days ago: https://github.com/tomv564/LSP/pull/652
You can try fetching the git master branch instead of a version from Package Control.

Fix is now released, closing this duplicate!


2.0.0

Coverage decreased (-1.3%) to 96.448% when pulling d13d3a47b07f650433f0129736857b80f3223543 on 2.0.0 into 1c427864a919ec141f07d9c2c49b6ce23cbed122 on master.


Images are not cropped/shrunk on party page or on district page

http://<IP_ADDRESS>/district/1060 W Addison St, Chicago, IL 60613

Is this a CSS caching issue?

Jesus christ.


Fix PUT of multipart/related attachments support for Transfer-Encoding: chunked

Overview
Transfer-Encoding: chunked causes the server to wait indefinitely, then issue a a 500 error when the client finally hangs up, when PUTing a multipart/related document + attachments.  To reproduce:
To reproduce (testing against CouchDB 2.3.0 official docker image):
curl -v -X PUT http://admin:abc123@localhost:6005/foo/oink \
    -H 'Content-Type: multipart/related;boundary="25d2c8595dc6d17e2c59cc97ad3db535428bf940ac8cd646d002171f2147"' \
    -H 'Transfer-Encoding: chunked' \
    --data "$(echo LS0yNWQyYzg1OTVkYzZkMTdlMmM1OWNjOTdhZDNkYjUzNTQyOGJmOTQwYWM4Y2Q2NDZkMDAyMTcxZjIxNDcNCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbg0KDQp7Il9hdHRhY2htZW50cyI6eyJmb28udHh0Ijp7ImNvbnRlbnRfdHlwZSI6InRleHQvcGxhaW4iLCJsZW5ndGgiOjEzLCJmb2xsb3dzIjp0cnVlfX0KLCJmZWV0Ijo0fQoNCi0tMjVkMmM4NTk1ZGM2ZDE3ZTJjNTljYzk3YWQzZGI1MzU0MjhiZjk0MGFjOGNkNjQ2ZDAwMjE3MWYyMTQ3DQoNCnRlc3QgY29udGVudAoNCi0tMjVkMmM4NTk1ZGM2ZDE3ZTJjNTljYzk3YWQzZGI1MzU0MjhiZjk0MGFjOGNkNjQ2ZDAwMjE3MWYyMTQ3LS0NCg== | base64 -d)"

Testing recommendations

make eunit apps=chttpd suites=chttpd_db_attachment_size_tests
Related Issues or Pull Requests
This fixes #1943 .
Checklist

[x] Code is written and works correctly
[x] Changes are covered by tests
[ ] Any new configurable parameters are documented in rel/overlay/etc/default.ini - N/A
[ ] A PR for documentation changes has been made in https://github.com/apache/couchdb-documentation - N/A

Thank you for the review, @nickva ! I'm about to merge this.

Don't forget to squash and rebase :-)

An perhaps we'd want to issue the PR for main as well

I thought main doesn't do attachments. Has that changed?

I thought main doesn't do attachments. Has that changed?

Attachments can added, retrieved and replicated still. Pretty sure we have tests for that too. Their size would be limited by the maximum transaction size and that may not be exposed properly as a 413 and would just emit a 500 response but smaller sizes < 10Mb should work.

Attachments can be added, retrieved and replicated still. Pretty sure we have tests for that too. Their size would be limited by the maximum transaction size and that may not be exposed properly as a 413 and would just emit a 500 response but smaller sizes < 10Mb should work.

Gotcha. I'll open a PR to backport this to main after merge.


v3 doesn't use the right Python version (2)?

See https://github.com/pawamoy/git-changelog/actions/runs/3331169228/jobs/5510586720
Run pdm-project/setup-pdm@v3
  with:
    python-version: 3.7
    cache: true
    cache-dependency-path: pyproject.toml
    token: ***
    prerelease: false
    enable-pep582: true
  env:
    LANG: en_US.utf-8
    LC_ALL: en_US.utf-8
    PYTHONIOENCODING: UTF-8
/usr/local/bin/python - -o install-output.json
  File "<stdin>", line 40
    def _call_subprocess(args: list[str]) -> int:
                             ^
SyntaxError: invalid syntax

Maybe only on MacOS builds, Ubuntu seems fine: https://github.com/pawamoy/git-changelog/actions/runs/3331169228/jobs/5510642791

Would you please try pdm-project/setup-pdm@main to verify the fix?

It worked with the main branch, though it also worked with v3 in another pipe, see https://github.com/pawamoy/mkdocs-spellcheck/actions/runs/3379789869/jobs/5611803822, so maybe the issue was fixed by GitHub somehow?

It worked with the main branch, though it also worked with v3 in another pipe, see https://github.com/pawamoy/mkdocs-spellcheck/actions/runs/3379789869/jobs/5611803822, so maybe the issue was fixed by GitHub somehow?

No, the release strategy is to override the major tag, while still keeping minor versions if necessary.


"pow3" received signal SIGSEGV , Segmentation fault.

I've compiled the pow3 test (.tests_downloaded/CoreCLR/Regressions/common/pow3) for ARM and x86_64. The test works fine at x86_64 and fails at ARM with SIGSEGV signal:
(gdb) bt
#0  EEType::get_IsValueType (this=0x1080000) at /dotnet/corert/src/Native/Runtime/inc/eetype.h:412
#1  0x00024984 in RhpBox (pObj=0x54aed8, pData=0xbefff1b0) at /dotnet/corert/src/Native/Runtime/gcrhenv.cpp:768
#2  0x00255d50 in S_P_CoreLib_System_Runtime_RuntimeExports__RhBox (pEEType=..., data=@0xbefff1b0: 86 'V') at /dotnet/corert/src/Runtime.Base/src/System/Runtime/RuntimeExports.cs:110
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The  InternalCalls.RhpNewFast(ptrEEType) at RuntimeExports.cs:108 returns
(gdb) p result
$1 = (Object &) @0x54aed8: {m_pEEType = 0x1080000}
and
m_pEEType is used as pointer in S_P_CoreLib_System_Runtime_RuntimeExports__RhBox in gcrhenv.cpp:768
and leads to SIGSEGV.
Could you help me to debug the issue?

This looks like a GC heap corruption. @BredPet Do this work on Tizen?

Yes, We are working in one project at this moment.
I tried to compile and execute all of the CoreCLR tests for CoreRT.
271 out of 1973 finished with SIGSEGV signal.
Is it possible to rebuild the CoreRT with AddressSanitizer to detect such issues automatically?

AddressSanitizer is unlikely going to help you to trace this down. AddressSanitizer is for C/C++ programs. The .NET garbage collector is too level for AddressSanitizer.

The InternalCalls.RhpNewFast(ptrEEType) at RuntimeExports.cs:108 returns
(gdb) p result
$1 = (Object &) @0x54aed8: {m_pEEType = 0x1080000}

m_pEEType of this object should be same as pEEType argument passed in RhpNewFast. What is the argument of RhpNewFast when this happens? You should be able to tell by looking at the disassembly. If the argument is 0x1080000, it means there is codegen bug. If the argument is not 0x1080000, it means something went wrong inside RhpNewFast.

cc @dotnet/arm32-contrib
cc @CarolEidt

https://github.com/dotnet/corert/pull/5866


Make snippets AST aware

Environment data

VS Code version: 1.29.1
Extension version (available under the Extensions sidebar): 2019.1.0
OS and version: macOS 10.14.4
Python version (& distribution if applicable, e.g. Anaconda): 2.7.10
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Relevant/affected Python packages and their versions: N/A

Expected behaviour
When triggering completions, I would expect snippets that are not relevant for the current AST context to not be shown.
Actual behaviour
Snippets are shown in cases where the insertion of the snippet would result in invalid code.
Steps to reproduce:
Consider this piece of code, where $ denotes current cursor position.
numer = 1000
denom = 10

quotient = numer / de$

This results in snippets for def being shown:

Is it possible to hide irrelevant snippets in cases like this?

I am not sure if that's feasible or not. Moving this issue to double-check.

Issue moved to microsoft/python-language-server #1080 via ZenHub

Please note, this isn't possible today with the API provide in VSCode. Someone's do not have much access to the scope of the current code.

@DonJayamanne Could you use Jedi to look up the AST context?

At that point it turns into a feature that's going to require analysis of the code, and such a feature request would have to go into the Language Server repo https://github.com/microsoft/python-language-server.
Note: The Language Server repo is where we the AST information is generated, etc.

Snippets are controlled by VS Code, so unfortunately our only options are either have snippets or not have any snippets. And the latter is not an option as our users have them useful, so I'm closing this issue.

Ok I think I understand the technical limitations a bit more.
I personally think it would make sense to pull snippets into a separate experience (e.g. invoked by keyboard shortcut) if they can't be context sensitive, but I understand they may not be as discoverable that way.
Thanks for the consideration!


[WIP] Support for Flash Channels

Started to work on Flash Channels :)

Hey @jinnerbichler I see this PR is still tagged with WIP — is there anything that I can do to help?


Standalone bundle, no need for package.json?

I'm trying to bundle my code using webpack to run standalone, such that I don't need node_modules and the package.json. However after compiling my bundle, when I change package.json with a syntax error, my bundled code will no longer run!? For some reason my bundled code still revers to package.json, why is this?

Can you describe it in more detail?

Please use discussions for questions, it is bug tracker, thanks


polars dataframe support

Jupyter data viewer to support polars dataframes. In particular, column names.

/extJupyter

It looks like this is caused by the Jupyter extension. Please file the issue to the Jupyter extension repository. Make sure to check their issue reporting template and provide them relevant information such as the extension version you're using. See also our issue reporting guidelines for more information.
Happy Coding!


MudProgressCircular: Add option to render percentage in determinate version

Description
Added option to show progress percentage of the determinate version of the circular progress. Also, I added an option to choose Typo for the value -> will be mainly used for larger sizes.
Resolves #2520
Resolves #6437
How Has This Been Tested?
Tests will be provided.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[ ] I've added relevant tests.

Here is an image of the implemeted version

A goo starting point, but feels like it's missing customization capabilities.
For example, what if I don't want the percentage, but make it 1/100, 2/100. etc
Wouldn't it better to have something like: RenderFragment<PrecentageContext> PrecentageContent where the context would have the information of total and current value?
This is just for a topic for discussion

Wouldn't it better to have something like: RenderFragment<PrecentageContext> PrecentageContent where the context would have the information of total and current value?

So if ShowPercentage is true, and if the RenderFragment is not supplied it renders the percentage otherwise the fragment?

So if ShowPercentage is true, and if the RenderFragment is not supplied it renders the percentage otherwise the fragment?

Yeah

Ok, let's do it like that. I also need to create a CSS class for the div, I forgot to do that. Or should I use the CSS util classes for that? @ScarletKuro

I've added the render fragment, updated CSS and docs.

LGTM! I'll await feedback from others @henon and @Mr-Technician.
Also, I'd like to gather opinions on the idea of using a RenderFragment<class> instead of RenderFragment<int>. In that case if there will be need to add something it won't be breaking, or it's over engineering at this point and unlikely to happen?

Could you elaborate? @ScarletKuro Do you mean that the RenderFragment T would be a string rather than an int?

Could you elaborate? @ScarletKuro Do you mean that the RenderFragment T would be a string rather than an int?

Not a string, a class that contains the fields
RenderFragment<ProgressContext> Progress content { get; set; }

public class Progress context
{
    int Progress { get; set; }
    //... Future fields related to context
}

LGTM! I'll await feedback from others @henon and @Mr-Technician. Also, I'd like to gather opinions on the idea of using a RenderFragment<class> instead of RenderFragment<int>. In that case if there will be need to add something it won't be breaking, or it's over engineering at this point and unlikely to happen?

I think that even a plain RenderFragment would have done here. The percentage/fraction comes from the user so they could easily make their own content without a parameter. I would say in this case the component is so simple, I can't think of anything that needs to be passed to the fragment that the users don't know or can't calculate themselves.

Also, I'd like to gather opinions on the idea of using a RenderFragment instead of RenderFragment.

I'm not completely against the idea, it's a small change, but I don't know what else could be added latter on.

And for instance, if they would want one decimals like 88,5% they would have to do their own calculation anyway, so I guess the int parameter is of limited utility.

I am pretty sure that we are gonna get issues requesting to show the absolute value instead of a percentage etc. Maybe we should forestall this by adding another example that demonstrates custom content.

I wanted to show the render fragment in the indeterminate mode, but it spins.

I wanted to show the render fragment in the indeterminate mode, but it spins.

Oops :D ok, then let's leave it like it is.

Yeah, we would need to envelope it in one more div.

Yeah, we would need to envelope it in one more div.

If that is easy to do then I'd go for that. If you think this could break user's own styling we can also do it later in v7.

And for instance, if they would want decimals like 88,5% they would have to do their own calculation anyway, so I guess the int parameter is of limited utility.

I think that even a plain RenderFragment would have done here. The percentage/fraction comes from the user so they could easily make their own content without a parameter. I would say in this case the component is so simple, I can't think of anything that needs to be passed to the fragment that the users don't know or can't calculate themselves.

You are right

I'd say plain RenderFragment, then.

Actually, what do you guys think of just going with the render fragment and just showing in an example how to use it for showing percentage?

Actually, what do you guys think of just going with the render fragment and just showing in an example how to use it for showing percentage?

Also good idea, less unnecessary properties and more clean logic

Yes, I think good examples are our friend here. If someone needs to reuse the percentage example they can make their own wrapper component that implements it.

The int as a percentage in the render-fragment will be enough to cover at least 90 % of the use cases for the progress. Mostly, because:

It is the ideal use case for the fragment
This is the whole number is the only thing that fits there
Users can still render anything else there if they want to.

I just disagree with putting there only the option to render empty fragment when so many users will want to put there the percentage. That's also the ticket I was basing on this update.

I see that showing percentage is a popular request. What about indeterminate state though? Currently not even a label or icon is possible because the render fragment is only visible in determinate mode.
As a user I'd expect the render fragment to work in both modes, so if it is not extremely difficult to implement this, then I'd prefer that. If we have that then the int parameter doesn't make sense any more. It is not needed for this feature anyway, because the implementation can access the progress directly from the component.

I see no further progress on this since end August. Can the reviewers maybe provide an ETA?

I'll try to get to it as soon as I have time. Although I'm more concerned right now with the MudStepper #7414

For the record, the plan is a RenderFragment<int?> that can be used for both determinate and indeterminate progress. The nullable int parameter will hold the percentage in the determinate case.

I think it would be nice to revive this if anyone got some spare time
@danielchalmers do you want this? Can also remove the old API.

I like the idea

MUI

It needs to scale with content and with respect to Size property.

<MudProgressCircular Color="Color.Primary" Value="@Value" ShowPercentage="true" />
<MudProgressCircular Color="Color.Primary" Value="@Value" ShowPercentage="true" Size="Size.Small" PercentageTypo="Typo.h1" />
<MudProgressCircular Color="Color.Primary" Value="@Value" ShowPercentage="true" Size="Size.Large">
    <PercentageContent>
        <MudText Typo="Typo.h6">@context</MudText>
    </PercentageContent>
</MudProgressCircular>
<MudProgressCircular Color="Color.Primary" Value="@Value" ShowPercentage="true" Size="Size.Medium">
    <PercentageContent>
        <MudText Typo="Typo.h1">@context</MudText>
    </PercentageContent>
</MudProgressCircular>

There also shouldn't be a Typo property, it should work that out itself based on the Size property. (not sure how exactly)
I say keep  ShowPercentage because it will actually bring value as long as the above is taken care of. Two new properties is fine and this dynamic has been done plenty of times in the library.

RenderFragment should accept double not `int`` to match the Value property. User can round it themselves.

In the docs, "Determinate with percentage" is cut off


Not loading using packer and v3

Problem
The plugin v3 is not being loaded using packer config:
Steps to reproduce
Packer config:
use({ "lukas-reineke/indent-blankline.nvim", module = "ibl" })

The setup:
local config = {
	indent = {
		char = "|",
	},
	scope = {
		enabled = true,
		show_start = false,
		show_end = false,
	},
}

require("indent_blankline").setup(config)

Expected behavior
I expected the plugin to be loaded. Ex I can call :IBLEnable
Neovim version (nvim -v)
NVIM v0.9.4 Build type: Release LuaJIT 2.1.1696795921

It doesn't work either.
Do you think that module="ibl" is right in packer?

After I removed the module="ibl"from packer and used require("ibl").setup(config) it works!
Thanks!

Do you think that module="ibl" is right in packer?

Yeah, that's correct.
If it still doesn't work then there is something else wrong in your config. Do you get any errors?


Security: Restrict Arbitrary File Reading Part 2

Background
It is known that previous versions of typst allowed for reading arbitrary files as discussed in issue #219, revealing potentially sensitive data in the filesystem. Below is the code snippet used to illustrate this.
# adjust for the right amount of ..
echo '#read("../../../etc/passwd")' >repro.typ
typst repro.typ

This issue was closed after @laurmaedje commented that doing so was now forbidden.

I'm closing this as for now as reading outside of the directory the Typst file resides in is forbidden now.

The Bypass
There is a way to circumvent this protection in Typst version 0.12.0 through the use of symlinks. Creating a file passwd that symlinks to /etc/passwd and reading it from the project directory /tmp will result in reading /etc/passwd, despite it not being within the project root.
As a proof of concept, I have created passwd and main.typ in the /tmp directory, which will be the project root for this example.
virusspec@4eff4abe169b:/tmp$ ls -l
lrwxrwxrwx 1 virusspec virusspec     9 Nov 22 21:23 passwd -> /etc/passwd
-rw-rw-r-- 1 virusspec virusspec    41 Nov 22 21:26 main.typ

The contents of main.typ are below.
#let text = read("passwd")
#raw(text)

Executing typst compile --root /tmp main.typ results in a PDF file that contains the contents of /etc/passwd.
It can be verified that this was not intentional by changing main.typ to read from /etc/passwd directly and observing the subsequent error message asserting that reading outside of the project root is prohibited.
virusspec@4eff4abe169b:/tmp$ typst compile --root /tmp test.typ
error: failed to load file (access denied)
  ┌─ test.typ:1:17
  │
1 │ #let text = read("../etc/passwd")
  │                  ^^^^^^^^^^^^^^^
  │
  = hint: cannot read file outside of project root
  = hint: you can adjust the project root with the --root argument

Remediation
This vulnerability can be mitigated by checking that the resolved symlink path is within the project root rather than relying entirely on the filename supplied by the user.
In bash, this can be done with readlink and it appears that there is a Rust equivalent std::fs::read_link.
Additional Notes
I would also like to note that it is highly likely that I am not the first to discover this issue since I found it during a CTF challenge on Typst that is solved by reading a file outside of the project root, which implies that at a minimum, the challenge author and those who solved it are also aware of the issue.
Reproduction URL
No response
Operating system
Linux
Typst version

[X] I am using the latest version of Typst

Right now, symlinks are the only way to expose something outside the root without over-exposing things. For example, if you want to expose /var/file.txt while compiling from /home/user/documents/typst-project, you'd need to set the root folder to / (the closest common ancestor), which would expose much more than just that file. So a symlink from /home/user/documents/typst-project to /var/file.txt works nicely to that end. This is why we have also been recommending this route in support channels.
But I can see how it can be a problem: others can push symlinks to their repositories, so you could clone someone else's code containing a symlink to /etc/passwd (which is broken in a vaccuum / in GitHub, but works in your machine) and their code would be able to read it during compilation, not because you added the symlink in your machine, but because someone else did, inadvertently. (@tingerrr noted that this would be less of a problem with hard links since you can't push that, but it's still something to consider.)
So we could investigate some way to make things more air-gapped, but we also have to make sure we don't make everything too inconvenient for users. The typical use case is just that the user wants to read files from some folder without duplication; symlinks were made for this, so an alternative solution should, ideally, be just as convenient. Just let the user do what they want to do, basically. But how can we satisfy both requirements?
One potential idea could be inspired by containers: similar to how you can bind container volumes - specific paths visible only to programs inside the container - to folders outside the container, giving them a "namespace" inside the container without exposing other folders, we could have namespaced paths within Typst, e.g<EMAIL_ADDRESS>would read a file from the folder with the assets namespace. Then, when compiling, you'd specify typst compile --path assets=~/myassets main.typ. For editors, you'd specify this in your editor settings, although editor settings can also be pushed to repositories (at least for VSCode, Zed etc.), so that'd potentially lead us back to the same problem, but it might still be an improvement over the status quo if you're careful enough (and either way VSCode warns you before accepting settings from third-party repositories).
I'd love to hear more potential ideas on this.

And just to give readers some context why this comes up now, this was part of a CTF challenge by https://ecomaikgolf.com/ in https://play.glacierctf.com/.
Might also just be nice to see software you made/helped make used in a CTF :P

so an alternative solution should, ideally, be just as convenient. Just let the
user do what they want to do, basically. But how can we satisfy both
requirements?

What about --unconfined for now? Users can run --unconfined if they have
a workflow that requires symlinks outside --root. Default would be confined to
protect against threats like a rogue git clone. Users would (should) unconfine
only documents they really trust, or their own. It would also be clear for them
that its a dangerous operation (maybe a warning).
Maybe there's a better solution as you stated, but this would be a small fix
that would fix symlink escaping and wouldn't break user convenience.

Might also just be nice to see software you made/helped make used in a CTF :P

Thanks for your work folks, I discovered typst and now most of the CTF team already switched to it :)

so an alternative solution should, ideally, be just as convenient. Just let the
user do what they want to do, basically. But how can we satisfy both
requirements?

What about --unconfined for now? Users can run --unconfined if they have a workflow that requires symlinks outside --root. Default would be confined to protect against threats like a rogue git clone. Users would (should) unconfine only documents they really trust, or their own. It would also be clear for them that its a dangerous operation (maybe a warning).

As long as --unconfined is restricted to allowing symlinks, that could work, but I'd guess that we've already used a good chunk of our "annoyingness budget" by requiring --root. Having to set both --root and --unconfined each time sounds like it could be two times as annoying. Also, --unconfined could still, in theory, potentially be exploited by packages (local or otherwise) using symlinks in their own subdirectories... although we could just restrict those separately.
Still, I'm open to hearing further ideas, maybe there is something even better than both suggestions. Though I do think that we'll eventually converge towards something similar to the namespaces idea.

This vulnerability can be mitigated by checking that the resolved symlink path is within the project root rather than relying entirely on the filename supplied by the user.

it's not. using fs::read_link results in toctou, which opens the door for Restrict Arbitrary File Reading Part 3.

IMHO it is not a bug but a feature. specific to the case mentioned in issue's description, I don't believe people would intentionally put the passwd link in their typst workspace. If they want to compile typst document in /tmp, they could create a sub directory containing only necessary source files for the compiler, i.e. typst compile --root /tmp/deadbeef/ /tmp/deadbeef/main.typ

others can push symlinks to their repositories, so you could clone someone else's code containing a symlink to /etc/passwd (which is broken in a vaccuum / in GitHub

@PgBiel this sounds like a good point. at least typst/packages must detect and reject packaging symlinked files. when we untar a package bundle we should also skip symlinks in the bundle. But I think we have already made them, just to confirm it.

Namespace solution seems nice but maybe also overcomplicated. Why not just have a command line option for whitelisted paths outside the root? Like:
typst compile main.typ --external "~/Documents/Academia/my_publications.bib" --external "~/assets/data/*"

This will:

allow to use symlinks (within the root directory) that point to these files
why not also allow to use those files directly from Typst

And all other symlinks are blocked. (Basically just treat a requesting a symlink as requesting the file that it points to directly.)

As long as --unconfined is restricted to allowing symlinks, that could work, but I'd guess that we've already used a good chunk of our "annoyingness budget" by requiring --root. Having to set both --root and --unconfined each time sounds like it could be two times as annoying. Also, --unconfined could still, in theory, potentially be exploited by packages (local or otherwise) using symlinks in their own subdirectories... although we could just restrict those separately.

Perhaps the Typst compiler starts getting complicated enough to require some form of build system. Very large documents or corporate environments with plenty of network mounts and global/user wide resources may simply lend themselves to this. Not saying this is up to use to solve, but I don't think it should sop us from implementing features users deem necessary.

when we untar a package bundle we should also skip symlinks in the bundle. But I think we have already made them, just to confirm it.

We do. At least I'm fairly sure I checked that at the time.

I would also like to note that it is highly likely that I am not the first to discover this issue since I found it during a CTF challenge on Typst that is solved by reading a file outside of the project root, which implies that at a minimum, the challenge author and those who solved it are also aware of the issue.

It's definitely a known thing and also was at the time (see my comment right above the linked one). I think the attack surface is fairly small as transmitting a symlink to someone is much harder than a file (a git repo can do it, but not just a mailed file). If we arrive at a better permission system, I'd be open to restricting symlinks as well, but in the meantime I wouldn't want to remove it, so I'll remove the bug label.
I think mounting might be okay. @assets would conflict with package syntax. In theory, it could just be a path without an @ (like a normal mount). So if you mount~/Pictures:assets, you'd get an assets folder mounted into the project root.

Namespace solution seems nice but maybe also overcomplicated. Why not just have a command line option for whitelisted paths outside the root? Like:
typst compile main.typ --use "~/Documents/Academia/my_publications.bib" --use "~/assets/data/*"

(...)
* why not also allow to use those files directly from Typst

This would only make sense if the project root is at /, otherwise / in Typst refers to your project root, and in theory nothing outside / can be referred to, so /home/user/assets is not a real path because there is no /home/user/documents/project-name/home/user/assets path, leading me to my point below.

I think mounting might be okay. @assets would conflict with package syntax. In theory, it could just be a path without an @ (like a normal mount). So if you mount~/Pictures:assets, you'd get an assets folder mounted into the project root.

I'm personally not a fan of this, since it necessarily removes the possibility of naming files in a certain way in your project root. For mounts, it's usually fine because the mounts are either at specific directories (e.g. /run/media) or at the root of the system's filesystem (e.g. /shared), where you usually don't have permissions to modify anyway. However, the project root is somewhere to store files and folders of all kinds, making it easy for mounts to conflict. That's not to mention the potential of confusion since /assets now might not refer to a file that is actually there in your folder that you may check or refer to.
That's why I think a separate syntax for mounts would be ideal. And I'm ok with conflicting with package syntax, as we can distinguish between the two types of paths internally (and, besides, package syntax is fairly unique with its usage of semicolon). There's even some intersection of purpose here: we've discussed (not to a full extent yet) the possibility of creating custom namespaces for packages through flags like --namespace @org=/org/path, so as to not have to rely on searching through multiple --package-path directories, and I think this same idea would work for regular paths (not just package paths), so it could be reused for this purpose, having the semantics of a normal path if declared as such.


[Discussion] Node.js 12.13.0 and Npm 6.12.0

Discussion for deployment of Node.js 12.13.0 and Npm 6.12.0

Fantastic!
When will it land?


required named arguments support in dart2js

[ ] Compiler model

[ ] FunctionType has new map for required named arguments.
[ ] Compile-time subtype test incorporates required named arguments.
[ ] FunctionType is properly serialized.

[ ] Runtime support

[ ] The call selector for required arguments is the same as optional arguments (a subclass can override with a required argument 'promoted' to optional, so it needs to be consistent).
[ ] Recipe parsing should interpret two 'bags' as specifying the required followed by optional named parameters.  Example: "int(int,{req:int}{opt:int})", "int({req:int}{})".
[ ] Subtype check modified.
[ ] Function.apply metadata needs to be emitted to specify which parameters are required. This can be similar to the default values.
[ ] Function.apply needs to be modified to use the required parameter metadata to reject missing required arguments.

[ ] Filter stubs so that stubs are generated only for selectors that 'expect' the required arguments (i.e. omit stubs that would 'default' a missing required argument).

[ ] On methods.
[ ] On closure call methods.
[ ] On tear-off call-to-selector mapping.

@Markzipan is currently looking into this.

FYI - @Markzipan  - I adjusted the list above with edits suggested by @rakudrama
I initially thought we needed to modify CallStructure under universe, but @rakudrama corrects me that this is likely not needed.

No problem - but shouldn't we do a check in signatureApplies to ensure that all required named parameters in the ParameterStructure actually appears at the call site? The current check only ensures that the arguments are a subset of of the parameters.

Yes, signatureApplies probably does need modifying. I misunderstood the original work item to be an extension to the 'language' of CallStructure.

Any update on this?  Do we need this for un-forking?

No progress here, however, this item is not needed to unfork. It is necessary for the full support of NNBD, but not for weak-mode (default when we unfork). Because of that we have prioritized other work first.

Should we move this under #40106 since this is not blocking the unfork?

Good point - I just moved it to a new epic, rather than #40106, I'm using a new sub-epic that is specific to dart2js in #40762


Add to_dict function to *Meta and Block classes

Coverage decreased (-0.8%) to 99.213% when pulling<PHONE_NUMBER>af3048f1bce657787a7c5d31c5e599 on dev-gary into a92220ac28ef44cf76c484839a588c9c464f71b1 on master.


withCredentials is not working

withCredentials is xhr option, so axios has:
axios.defaults.withCredentials = true;

However, xior uses fetch, fetch has different option credentials for the same functionality:
xior.defaults.credentials = 'include';

This makes xior ignoring withCredentials.

Thanks feedback, fix in v0.5.1.
Now if xior.defaults.withCredentials = true;, xior will set credentials='include'

Awesome!


Update minikube.md to cover use behind a web proxy

In a corporate environment you need to pass proxy information, and just setting the appropriate environment variables does not work.
The code snippet here works for me

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

Open doc issue (pretty small) and please accept the CLA.

@gavinB-orange , please fix the merge conflict and the open docs comment, and I can merge.

re. CLA  I am covered by my employer Hewlett Packard Enterprise

Having problems resolving the conflict - pressing the "Resolve conflicts" button just leads to a spinning GitHub wait icon ...

Huh, can you try again?  Pressing "resolve conflicts" seems to work for me.


Fix how volumes are identified on the client for mount..

Modified approach to identifying device to mount:
a. The server sends the PCI slot number at which the PVSCSI controller is attached, to the client.

On Linux /sys/bus/pci/slot/<slot-num/address has the name of the device at that slot. we use this to create the name of the device to mount on the client.

Are you planning to use the CI system for testing? Not sure what "not for review" means here.. is it WIP?

Thanks for doing this. LGTM subject to CI passing. Can you please update PR with "testing done" and enumerate which linux distros you have tested.

LGTM

I just skimmed the code without going deep and it looks good for the. However , please do add test matrix (Linux/ ESX versions) of  at you have  checked; LGTM contingent on this and CI passing

Do we plan to expand the list of distros supported as part of this (then documentation and CI needs updating) else LGTM

The fix looks good - please DO ADD some info on testing (automation may be better but here a description of what you did manually, with cut-n-paste of the  results, will be good enough)l LGTM after that

Testing matrix:
Vsphere versions - 6.0U3 and 6.5
Linux - Ubuntu 14.04.1 LTS and Photon
Centos and Redhat testing is still underway pending availability.
As discussed will merge these changes and continue to test.


TwoDimensionalScrollView lag for small-many grid

Steps to reproduce
You can checkout dartpad
Code sample
Code sample
import 'package:flutter/material.dart';

import 'package:flutter/gestures.dart';
import 'package:flutter/rendering.dart';
import 'dart:math' as math;

///*I was playing with 2D gridView and my use-case is to render thousands of grids,
/// it is good <k and large grid size(>100px).
/// but it keeps lagging once I have small grids(<20px)
/// idk if it is for heavy computation on layoutChildSequence,
/// I am wondering is there anyway of optimizing RenderTwoDimensionalViewport for small many grid.
/// !https://github.com/yeasin50/game_of_life/blob/master/lib/src/presentation/widgets/two_dimensional_gridview.dart
///
/// Create a grid view on TwoDimensionalScrollView
///
/// ```dart
///  TwoDimensionalGridView(
///   gridDimension: 20,
///   diagonalDragBehavior: DiagonalDragBehavior.free,
///   cacheExtent: 500,
///   delegate: TwoDimensionalChildBuilderDelegate(
///     maxXIndex: 130,
///     maxYIndex: 130,
///     builder: (context, vicinity) {
///       return Container(
///         height: 20,
///         width: 20,
///         color: Colors.primaries[(vicinity.xIndex + vicinity.yIndex) % Colors.primaries.length],
///         alignment: Alignment.center,
///         child: Text(
///           vicinity.toString(),
///         ),
///       );
///     },
///   ),
/// ),
/// ```
///
@Deprecated("Not usable for large items, use [TwoDimensionalCustomPaintGridView] instead")
class TwoDimensionalGridView extends TwoDimensionalScrollView {
  const TwoDimensionalGridView({
    super.key,
    required super.delegate,
    required this.gridDimension,
    super.primary,
    super.mainAxis = Axis.vertical,
    super.verticalDetails = const ScrollableDetails.vertical(),
    super.horizontalDetails = const ScrollableDetails.horizontal(),
    super.cacheExtent,
    super.diagonalDragBehavior = DiagonalDragBehavior.none,
    super.dragStartBehavior = DragStartBehavior.start,
    super.keyboardDismissBehavior = ScrollViewKeyboardDismissBehavior.manual,
    super.clipBehavior = Clip.hardEdge,
  });

  /// size of the grid
  final double gridDimension;

  @override
  Widget buildViewport(
    BuildContext context,
    ViewportOffset verticalOffset,
    ViewportOffset horizontalOffset,
  ) {
    return TwoDimensionalGridViewPort(
      gridDimension: gridDimension,
      cacheExtent: cacheExtent,
      clipBehavior: clipBehavior,
      verticalOffset: verticalOffset,
      verticalAxisDirection: AxisDirection.down,
      horizontalAxisDirection: AxisDirection.right,
      horizontalOffset: horizontalOffset,
      delegate: delegate,
      mainAxis: mainAxis,
    );
  }
}

class TwoDimensionalGridViewPort extends TwoDimensionalViewport {
  const TwoDimensionalGridViewPort({
    super.key,
    required super.verticalOffset,
    required super.verticalAxisDirection,
    required super.horizontalOffset,
    required super.horizontalAxisDirection,
    required super.delegate,
    required super.mainAxis,
    super.cacheExtent,
    super.clipBehavior = Clip.hardEdge,
    required this.gridDimension,
  });

  final double gridDimension;

  @override
  RenderTwoDimensionalViewport createRenderObject(BuildContext context) {
    return RenderTreeViewPostT(
      gridDimension: gridDimension,
      horizontalOffset: horizontalOffset,
      horizontalAxisDirection: horizontalAxisDirection,
      verticalOffset: verticalOffset,
      verticalAxisDirection: verticalAxisDirection,
      delegate: delegate,
      mainAxis: mainAxis,
      childManager: context as TwoDimensionalChildManager,
    );
  }

  @override
  void updateRenderObject(BuildContext context, covariant RenderTwoDimensionalViewport renderObject) {
    super.updateRenderObject(context, renderObject);
  }
}

class RenderTreeViewPostT extends RenderTwoDimensionalViewport {
  RenderTreeViewPostT({
    required super.horizontalOffset,
    required super.horizontalAxisDirection,
    required super.verticalOffset,
    required super.verticalAxisDirection,
    required super.delegate,
    required super.mainAxis,
    required super.childManager,
    required this.gridDimension,
  });

  ///ig there should be way to get from child instead, while I will have same size grid, so ignoring
  final double gridDimension;

  @override
  void layoutChildSequence() {
    // FIXME:   The laggy ui
    final double horizontalPixels = horizontalOffset.pixels;
    final double verticalPixels = verticalOffset.pixels;

    final viewPortWidth = viewportDimension.width + cacheExtent;
    final viewPortHeight = viewportDimension.height + cacheExtent;

    final TwoDimensionalChildBuilderDelegate builderDelegate = delegate as TwoDimensionalChildBuilderDelegate;

    final int maxRowIndex = builderDelegate.maxYIndex!;
    final int maxColIndex = builderDelegate.maxXIndex!;

    final int leadingColumn = math.max((horizontalPixels / gridDimension).floor(), 0);
    final int leadingRow = math.max((verticalPixels / gridDimension).floor(), 0);

    final int trailingColumn = math.min(((horizontalPixels + viewPortWidth) / gridDimension).ceil(), maxColIndex);
    final int trailingRow = math.min(((verticalPixels + viewPortHeight) / gridDimension).ceil(), maxRowIndex);

    double xLayoutOffset = (leadingColumn * gridDimension) - horizontalPixels;
    for (int x = leadingColumn; x < trailingColumn; x++) {
      double yLayoutOffset = (leadingRow * gridDimension) - verticalPixels;
      for (int y = leadingRow; y < trailingRow; y++) {
        final ChildVicinity childVicinity = ChildVicinity(xIndex: x, yIndex: y);
        final RenderBox child = buildOrObtainChildFor(childVicinity)!;
        child.layout(constraints.loosen());

        parentDataOf(child).layoutOffset = Offset(xLayoutOffset, yLayoutOffset);
        yLayoutOffset += gridDimension;
      }
      xLayoutOffset += gridDimension;
    }

    final double verticalExtent = gridDimension * (maxRowIndex + 1.0);
    verticalOffset.applyContentDimensions(0, (verticalExtent - viewportDimension.height));

    final double horizontalExtent = gridDimension * (maxColIndex + 1);
    horizontalOffset.applyContentDimensions(0, (horizontalExtent - viewportDimension.width));
  }
}

void main() {
  runApp(MaterialApp(
    debugShowCheckedModeBanner: false,
    home: MyApp(),
    scrollBehavior: MaterialScrollBehavior().copyWith(
      dragDevices: {
        PointerDeviceKind.mouse,
        PointerDeviceKind.touch,
        PointerDeviceKind.stylus,
        PointerDeviceKind.unknown
      },
    ),
  ));
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: TwoDimensionalGridView(
        gridDimension: 20,
        diagonalDragBehavior: DiagonalDragBehavior.free,
        cacheExtent: 500,
        delegate: TwoDimensionalChildBuilderDelegate(
          maxXIndex: 200,
          maxYIndex: 100,
          builder: (context, vicinity) {
            return SizedBox.expand(
              child: ColoredBox(
                key: ValueKey(vicinity),
                color: Colors.primaries[(vicinity.xIndex + vicinity.yIndex) % Colors.primaries.length ~/ 2],
              ),
            );
          },
        ),
      ),
    );
  }
}

What target platforms are you seeing this bug on?
Android, Web, Windows
OS/Browser name and version | Device information
Any,  Windows10
Does the problem occur on emulator/simulator as well as on physical devices?
Yes
Logs
No response
Flutter Doctor output
Doctor output
[√] Flutter (Channel stable, 3.24.1, on Microsoft Windows [Version 10.0.19045.4780], locale en-US)
    • Flutter version 3.24.1 on channel stable at P:\symlinks_portal\fvm_cache\versions\3.24.1
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 5874a72aa4 (2 weeks ago), 2024-08-20 16:46:00 -0500
    • Engine revision c9b9d5780d
    • Dart version 3.5.1
    • DevTools version 2.37.2

[√] Windows Version (Installed version of Windows is version 10 or higher)

Thanks for the report. Below is the reported behavior. It lags upon trying to scroll at various directions and responds after few seconds. Verified on web and desktop platforms.
https://github.com/user-attachments/assets/5d7c438d-153c-479f-949d-4dd103dcf8c4
Stable : 3.24.2
Master: 3.25.0-1.0.pre.269


workfows not displayed when submodules are initalized

I have a repository with  git submodule. Submodules doesn't have github action.
If I clone only the main repository workflows are correctly displayed
I can close and reopen vscode workflows are always displayed
with vscode opened,  if I run  git submodule update --init --recursive on the main I have always worflows
If I close vscode and reopen it workflows stop working. No workflows are displayed

Based on the debug it seems that the submodules are provisionned first and the last element is the main repos.
based on that instead to retrieve the index 0 in
export async function getGitHead(): Promise<string | undefined> {
const git = await getGitExtension();
if (git && git.repositories.length > 0) {
const head = git.repositories[0].state.HEAD;
if (head && head.name && head.type === RefType.Head) {
return refs/heads/${head.name};
}
}
}
and in
export async function getGitHubUrl(): Promise<string | null> {
const git = await getGitExtension();
if (git && git.repositories.length > 0) {
// To keep it very simple for now, look for the first remote in the current workspace that is a
// github.com remote. This will be the repository for the workflow explorer.
const originRemotes = flatten(
git.repositories.map((r) =>
r.state.remotes.filter((remote) => remote.name === "origin")
)
);
const githubRemotes = originRemotes.filter(
  (x) => x.pushUrl?.indexOf("github.com") !== -1
);
if (githubRemotes.length > 0) {
  return githubRemotes[0].pushUrl!;
}

}
return null;
}
another solution will be to have a settings parameter in this case to set the github action repository to managed.

Any update about this issue ?

Would you happen to have a repository that repros this?


Prepare for v0.12.5 release

Signed-off-by: Michi Mutsuzaki<EMAIL_ADDRESS>

alright i'm going for it


Does not display a specific gif file

I used the simplest mode in a simple project to display the gif file, but all the photos of this project except the submitted photo are displayed in the attachment
Sample code is used
    <Image gif:AnimationBehavior.SourceUri="Search.gif"  Width="500"  Height="300"  x:Name="imgTest" ></Image>

@HosseinTaarofi based on your code, it looks like you're using XamlAnimatedGif, not WpfAnimatedGif. They have a similar name and live under the same Github organization, but they're different projects.
Please open an issue in the correct project.

Anyway, this GIF file is broken... It causes an end-of-stream error, because the file ends when more data is expected.
The "GIF explorer" here agrees there's something wrong with it...

(ok, maybe not really broken, since browsers manage to display it, but there must be something weird in the LZW compression... I haven't been able to pinpoint the problem yet)


How to add header to rest api requests

Hi.
Thanks for the great packages. :)
I have little issue with rest api. I am trying to read the theme.liquid file and update it later. So I have the following route.
`
Route::get('/update', function () {
$myShop = ShopifyApp::shop();
$themes = $myShop->api()->rest('GET', '/admin/api/2019-04/themes.json');

$activeThemeId = "";
// get active theme id
foreach($themes->body->themes as $theme){
  if($theme->role == "main"){
      $activeThemeId = $theme->id;
  }
}

// get theme assets
$activeTheme = $myShop->api()->rest('GET', '/admin/api/2019-04/themes/'.$activeThemeId.'/assets.json?asset[key]=layout/theme.liquid&theme_id='.$activeThemeId);

return response()->json($activeTheme);

})->middleware(['auth.shop'])->name('config');
`
When I visit /update page. the request return no error with body = null.
I followed this api instruction
Also, I have the permission on theme_read and theme write
If i send the quest to admin/api/2019-04/themes/2334114/assets.json
It returns all assets as object.
How to add header to rest api requests
My question is how to set header for my rest request. I am not sure if that's right, but we have that feature on laravel
 ->header('Content-Type', $type);
Is there any way to fix this issue or set header?
Thanks

Instead of searching the active theme, you can retrieve it with this call:
/admin/themes/current.json
Then you should be able to retrieve any asset file with this call:
/admin/themes/'.$activeThemeId.'/assets.json?asset[key]=layout/theme.liquid
Not sur you need to set the header to get a correct response.

Hi @bnzo
Thanks for the help. it worked. :)

same problem!
You have found a solution?


Panic when leaving unused :in variable unbound

When leaving an :in variable unbound, like in:
[:find
 ?e
 :in
 ?f ?unused
 :where
 (= e f)
]

After binding only ?f, we panic at https://github.com/mozilla/mentat/blob/0c31fc7875294fdf80f4caf253590999a9214e0d/query-algebrizer/src/clauses/mod.rs#L147
That code is trying to be careful, but the issue is that the subtraction underflows in the above circumstance, since we're subtracting usize instances.

This is a good first bug.  You'll need to add tests to the query algebrizer and then cast to a reasonable numeric type.  Alternately, compare the lengths manually and do the right thing in the different cases.

If you rewrite that to be something that parses (= isn't a function):
mentat=> .q [:find ?e
mentat.>     :in ?f ?unused
mentat.>     :where [?e _ ?f]]
Error(MentatError(UnboundVariables({"?f", "?unused"})), State { next_error: None, backtrace: None }).

We specifically test for unbound variables in algebrize_query and q_prepare. How did you get to that point without passing through those guards?

We specifically test for unbound variables in algebrize_query and q_prepare. How did you get to that point without passing through those guards?

Hmm.  I guess I built this with QueryBuilder, plus some custom hacks to splice strings into the query (that I don't think are relevant).  Then I bound only some values before executing.

It sounds like this line:
    let unbound = algebrized.unbound_variables();

in algebrize_query is not correctly returning the unbound variables in your execution flow. QueryBuilder calls through InProgressRead::q_once, which ends up in fn q_once, which calls algebrize_query{,str}. So that implies there's something in your particular query that's tripping it up.

I've seen this again, this time with a lightly-modified tree (that might be relevant) and the code:
    let query = r#"[:find ?v
                    :in ?e ?a ?vx
                    :where
                    [?e ?a ?v]
                    [(< ?v ?vx)]]"#;

    let mut prepared = store.q_prepare(query, QueryInputs::with_type_sequence(vec![
        (Variable::from_valid_name("?vx"), ValueType::Long),
    ])).expect("prepared");


limactl: start: introduce --set <stringArray> flag to pin static config values instead of creating custom config file

Description
Since limactl already supports passing custom configuration files, sometimes it decreases the overall UX. It enforces us to create custom config files each time even we want to set just a single variable, such as localPort. Here is an example use-case:
So that we can also override the values in a file by using the '--set' flag and pass configuration from the command line as follows:
$ limactl start foo -f my_defauly.yaml --set ssh.localPort=15555 --set arch=x86_64

We can specify the --set flag multiple times. The priority will be given to the last (right-most) set specified.
--set stringArray:
set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)

/cc @developer-guy

This has been on plan, and will be implemented after merging https://github.com/lima-vm/lima/pull/1069

See also https://github.com/lima-vm/lima/issues/971#issuecomment-1258833707


fix(ContextModuleFactory): RangeError: Maximum call stack size exceeded

Bug report

What is the current behavior?
Crashes with a stack trace of
$ npm run webpack:dev

> @hyperledger/cactus@ webpack:dev *REDACTED_PATH*
> node --max-old-space-size=8192 node_modules/webpack/bin/webpack.js --display-error-details --env env-csv=dev --env target-csv=node

*REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:371
                                                        if (item) flattenedResult.push(...item);
                                                                                ^

RangeError: Maximum call stack size exceeded
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:371:34
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)
    at *REDACTED_PATH*/node_modules/webpack/lib/ContextModuleFactory.js:374:7
    at done (*REDACTED_PATH*/node_modules/neo-async/async.js:2931:13)

If the current behavior is a bug, please provide the steps to reproduce.

Clone the repo where the failure can be reproduced: https://github.com/petermetz/blockchain-integration-framework/tree/build/webpack-optimization-139
Check out the branch called build/webpack-optimization-139
Execute npm run configure which will produce the crash logs stated above.
You can observe the effective webpack config file after the build has run at least once at ./webpack.config.json

What is the expected behavior?
Build succeeds without RangeError.
Other relevant information:
webpack version:  v5.4.0
Node.js version: v12.16.3
Operating System: Ubuntu 20.04 LTS
Additional tools: Lerna, Typescript, ts-loader

same error when use module federation

@shaodahong this is not the same problem. Please report a separate issue.

After updating to the latest version no original problem, but I found other problem here - TypeError: Cannot read property 'availableChildren' of undefined (duplicate https://github.com/webpack/webpack/issues/11740), why it happens? Due cactus/examples/cactus-example-supply-chain-frontend/src/main/typescript/index.ts doesn't exists. How I debug it? Just remove dependOn from the each entry. Also you can find "./examples/cactus-example-supply-chain-frontend/undefined", in webpack.config.json, i.e. you get this problem when webpack can't resolve something in dependOn. Let's close in favor https://github.com/webpack/webpack/issues/11740. We need improve the error.


the open-sora can Image condition?

In future, the project will support  Image condition, even video condition??

yes, we will add control as soon as the training of the base T2V model is finished.

yes, we will add control as soon as the training of the base T2V model is finished.

controlnet or GLIGEN? like this https://zhuanlan.zhihu.com/p/684356955

Any more news?


Proxy isn't functioning.

// config/index.js
proxyTable: {
      '/api': {
        target: 'http://localhost:9090',
        changeOrigin: true,
        pathRewrite: {
          '^/api': ''
        }
      },
    },

$ npm start

><EMAIL_ADDRESS>start C:\Users\eugen\Projects\symphogear
> node build/dev-server.js

[HPM] Proxy created: /api  ->  http://localhost:9090
[HPM] Proxy rewrite rule created: "^/api" ~> ""
> Starting dev server...
 DONE  Compiled successfully in 5175ms01:19:15

> Listening at http://localhost:8080

I'm using Axios to send requests from localhost:8080. I want them to be proxied to localhost:9090. This was working with webpack-simple. It's not working with the webpack template.
Similar issue: #465

I got it working.
proxyTable: {
      '/api': {
        target: 'http://localhost:9090',
        changeOrigin: true
      }
    },

I tried the same but It didnt work, whats the difference between the two options?

@Oscarz90 check your config/index.js  dev.host. Is it localhost


Fix conform type to 'Hashable' Warning

These changes fix the following swift compiler warning's every time the project is built.
/Swift.RawRepresentable:2:27: 'Hashable.hashValue' is deprecated as a protocol requirement; conform type 'PlaybackSpeed' to 'Hashable' by implementing 'hash(into:)' instead
/Swift.RawRepresentable:2:27: 'Hashable.hashValue' is deprecated as a protocol requirement; conform type 'Attachment.Kind' to 'Hashable' by implementing 'hash(into:)' instead

I don't understand why this is necessary. Surely the default implementation should be included from SettingsSelectable:
https://github.com/razeware/emitron-iOS/blob/development/Emitron/Emitron/Settings/SettingsSelectable.swift#L34-L38
I've always assumed that this is some kind of compiler bug, but maybe I'm misunderstanding it? If it is a compiler bug, then the changes should (at the least) have a comment explaining why they're there. Ideally they'd also have a bug report number too, but that's quite a lot to ask for in this instance.

Hmm yeah I would have thought that anything conforming to SettingsSelectable would get it for free. It does sound like a compiler bug to me.
Another thing to note is that for PlaybackSpeed we override the property we're using for the hash, so that's probably worth a comment as well

Found a bug report SR-12445 of a similar case, he logged it as random but if you read his code its a replica of the same situation.  so decided to file my own SR-13851 bug report to clearly demonstrate the bug.


Decrypt keylogger files

How can you decrypt the keylogger files stored on the client?

What version are you using?

Version <IP_ADDRESS>

Weird, it shouldn't do that. Try uninstalling and reinstalling

I think issue #673 addresses my problem. Maxxor wrote the following solution:

@kosta14 The log files on the client are stored encrypted. :) You can make it readable by decrypting it using this function and setting the right key here before.

But i can't seem to make it work...


Workflow Extension is not loading

@milanvarady
Just created a test build. For some reason, workflow extension is not loading.

Hope we can address  this soon. Is it Xcode 16 related?

It should be fixed now. I deleted something I shouldn't have a few months ago.

Thank you! Just tested. It is working now.


percona-xtrabackup: 2.4.20 -> 2.4.26, 8.0.13 -> 8.0.29-22

Description of changes
Package update.
I have not tested the executables and the build for the 2.4 emits many warnings (but no errors).
There was a build issue in newer versions where the wrong event.h is picked up, depending on the order of libevent and libev in buildInputs.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
Result of nixpkgs-review run on x86_64-linux 1
2 packages built:

percona-xtrabackup
percona-xtrabackup_2_4

[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1325


Remove dask-sql

Since dask-sql does not have a lead maintainer, we are dropping it from our containers.
User who wish to continue using dask-sql in the containers can install it manually or use the EXTRA_CONDA_PACKAGES environment variable to install it on startup.
See: https://github.com/dask-contrib/dask-sql/issues/1344

The test failures are unrelated since I see the same ones in the nightly builds and cuspatial doesn't use dask-sql. I've asked the cuspatial team to take a look.

/merge


Tailing WAL failed

This is specifically not working on the 0.5.1 release (so far tested), 0.4.1 is working.
I believe there's an issue relating to how the path for the checkpoint file is being resolved. The culprit is the following:
https://github.com/Stackdriver/stackdriver-prometheus-sidecar/blob/3e6c59f370d26797abbcbb36d9684270c72a0e3b/tail/tail.go#L65
Why are we joining dir and cpdir.
as we set something like --prometheus.wal-directory=/prometheus/wal which is set for dir and cpdir is returned from tsdb.LastCheckpoint(dir), which will return the full path of the checkpoint found. So we end up concatenating to the following:
/prometheus/wal + /prometheus/wal/checkpoint.002016
I'm getting the following errors in this scenario:
level=info ts=2019-09-02T21:52:23.197Z caller=main.go:303 msg="Starting Stackdriver Prometheus sidecar" version="(version=, branch=, revision=)"
level=info ts=2019-09-02T21:52:23.197Z caller=main.go:304 build_context="(go=go1.12, user=, date=)"
level=info ts=2019-09-02T21:52:23.197Z caller=main.go:305 host_details="(Linux 4.14.127+ #1 SMP Tue Jun 18 23:08:40 PDT 2019 x86_64 prometheus-777fd6c946-hrchs (none))"
level=info ts=2019-09-02T21:52:23.197Z caller=main.go:306 fd_limits="(soft=1048576, hard=1048576)"
level=error ts=2019-09-02T21:52:23.211Z caller=main.go:394 msg="Tailing WAL failed" err="open checkpoint: list segment in dir:/prometheus/wal/prometheus/wal/checkpoint.002016: open /prometheus/wal/prometheus/wal/checkpoint.002016: no such file or directory"

Can someone advise if I'm just configuring this incorrectly or not?
The configuration i'm using for the sidecar is as follows
- name: sidecar
    image: gcr.io/xxx-xxx-xxx/stackdriver-prometheus/stackdriver-prometheus-sidecar:0.5.1
    imagePullPolicy: Always
    args:
    - "--stackdriver.project-id=xxx-xxx-xxx"
    - "--prometheus.wal-directory=/prometheus/wal"
    - "--stackdriver.kubernetes.location=x-xxx1"
    - "--stackdriver.kubernetes.cluster-name=xxx-xxx-xxx"
    - "--stackdriver.generic.location=xxx-xxx-xxx"
    ports:
    - name: sidecar
      containerPort: 9091
    volumeMounts:
    - name: storage-volume
      mountPath: /prometheus

I've just encountered the same issue:
 kubectl logs -n stackdriver  gke-01-prometheus-server-6f87676b88-2mkbp -c sidecar
level=info ts=2019-09-03T10:22:10.885Z caller=main.go:303 msg="Starting Stackdriver Prometheus sidecar" version="(version=, branch=, revision=)"
level=info ts=2019-09-03T10:22:10.885Z caller=main.go:304 build_context="(go=go1.12.9, user=, date=)"
level=info ts=2019-09-03T10:22:10.885Z caller=main.go:305 host_details="(Linux 4.14.127+ #1 SMP Tue Jun 18 18:32:10 PDT 2019 x86_64 gke-01-prometheus-server-6f87676b88-2mkbp (none))"
level=info ts=2019-09-03T10:22:10.885Z caller=main.go:306 fd_limits="(soft=1048576, hard=1048576)"
level=error ts=2019-09-03T10:22:10.890Z caller=main.go:394 msg="Tailing WAL failed" err="open checkpoint: list segment in dir:/data/wal/data/wal/checkpoint.000041: open /data/wal/data/wal/checkpoint.000041: no such file or directory"

Config:
  - args:
    - --stackdriver.project-id=xxx-xxx-xxx
    - --prometheus.wal-directory=/data/wal
    - --include={__name__=~".+",job="kubernetes-pods"}
    - --include={__name__=~".+",job="gcp-clsi"}
    imagePullPolicy: Always
    name: sidecar
    ports:
    - containerPort: 9091
      name: sidecar
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /data
      name: storage-volume
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: gke-01-prometheus-server-token-hdt4z
      readOnly: true

Looks like it was changed in this commit: https://github.com/Stackdriver/stackdriver-prometheus-sidecar/commit/d8e80a47d54eb2fdd95e51c0ac65066cf1471350#diff-ebda32def4aa9fd929c691ab34ebcc47R62


Cover simple cases by unittests

Split SSHAuth and SSHClient tests

Pull Request Test Coverage Report for Build 42

0 of 0 (NaN%) changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+2.4%) to 98.0%

Files with Coverage Reduction
New Missed Lines
%

exec_helpers/proc_enums.py
1
98.13%

Totals

Change from base Build 41:
2.4%

Covered Lines:
833

Relevant Lines:
850

💛  - Coveralls


Investigate the dataset-lifecycle-framework project

Describe your problem
The dataset-lifecycle-framework project abstracts data sources on S3 and NFS as CRD Dataset. By mapping the dataset into PersistentVolumeClaims and ConfigMaps, the dataset could be refered in Pods.
The dataset-lifecycle-framework project also has an operator, and use "labels" to indicate the dataset requirements in Pod. The operator is responsible for mounting the dataset properly. Just like we do in vineyard.
Vineyard use a similar syntax in "labels" of Pods to let the controller know which object the pod will require. Beyond that, vineyard operator considers the data locality and works as a scheduler plugin.
Additional context
N/A

Closed as staled, as its scope differs from vineyard.


INSERT INTO "elixir_migrations" line in structure.sql file targets incorrect schema

Environment

Elixir version (elixir -v): Elixir 1.6.0 (compiled with OTP 20)
Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.): PostgreSQL 10.1
Ecto version (mix deps): 2.1.6
Database adapter and version (mix deps): postgrex 0.13.4
Operating system: macOS 10.13.2

Current behavior
We make extensive use of Postgresql schemas for grouping data sets from different sources. For example, all tables that we use from Australia Post are stored in a schema named "auspost".
When we run mix echo.dump, the lines preceding the INSERT INTO statement are targeting another schema (in this case, the "auspost" schema).
Here is a snippet of the relevant part of our structure.sql file:
--
-- PostgreSQL database dump
--

-- Dumped from database version 10.1
-- Dumped by pg_dump version 10.1

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET row_security = off;

--
-- Name: auspost; Type: SCHEMA; Schema: -; Owner: -
--

CREATE SCHEMA auspost;

--
-- lots of create/alter table statements here
--

SET search_path = auspost, pg_catalog;

--
-- lots of create/alter table statements relating to Australia Post here
--

--
-- PostgreSQL database dump complete
--

INSERT INTO "elixir_migrations" (version) VALUES<PHONE_NUMBER>2613),<PHONE_NUMBER>0709),<PHONE_NUMBER>2030),<PHONE_NUMBER>2636),<PHONE_NUMBER>1143),<PHONE_NUMBER>4531),<PHONE_NUMBER>4157),<PHONE_NUMBER>4224),<PHONE_NUMBER>3942),<PHONE_NUMBER>1618),<PHONE_NUMBER>0956),<PHONE_NUMBER>3939),<PHONE_NUMBER>1207),<PHONE_NUMBER>0334),<PHONE_NUMBER>3531),<PHONE_NUMBER>4202),<PHONE_NUMBER>1419),<PHONE_NUMBER>3137),<PHONE_NUMBER>3140),<PHONE_NUMBER>4855),<PHONE_NUMBER>5830),<PHONE_NUMBER>0000),<PHONE_NUMBER>0100),<PHONE_NUMBER>0036),<PHONE_NUMBER>5512),<PHONE_NUMBER>0507),<PHONE_NUMBER>4329),<PHONE_NUMBER>2149),<PHONE_NUMBER>4648);

So, when we run mix ecto.load, we get the following error message in the PostgreSQL logs:
2018-02-08 22:22:27.204 UTC [168] ERROR:  relation "elixir_migrations" does not exist at character 13
postgresql_1     | 2018-02-08 22:22:27.204 UTC [168] STATEMENT:  INSERT INTO "elixir_migrations" (version) VALUES<PHONE_NUMBER>2613),<PHONE_NUMBER>0709),<PHONE_NUMBER>2030),<PHONE_NUMBER>2636),<PHONE_NUMBER>1143),<PHONE_NUMBER>4531),<PHONE_NUMBER>4157),<PHONE_NUMBER>4224),<PHONE_NUMBER>3942),<PHONE_NUMBER>1618),<PHONE_NUMBER>0956),<PHONE_NUMBER>3939),<PHONE_NUMBER>1207),<PHONE_NUMBER>0334),<PHONE_NUMBER>3531),<PHONE_NUMBER>4202),<PHONE_NUMBER>1419),<PHONE_NUMBER>3137),<PHONE_NUMBER>3140),<PHONE_NUMBER>4855),<PHONE_NUMBER>5830),<PHONE_NUMBER>0000),<PHONE_NUMBER>0100),<PHONE_NUMBER>0036),<PHONE_NUMBER>5512),<PHONE_NUMBER>0507),<PHONE_NUMBER>4329),<PHONE_NUMBER>2149),<PHONE_NUMBER>4648);

This is because psql is using the most recent search_path of auspost to locate the elixir_migrations table.
We have confirmed this by manually creating an identical elixir_migrations table in the auspost schema, and this indeed has the migration versions inserted into it.
Our temporary workaround
After each mix ecto.dump, we then manually edit the structure.sql file, adding the following to just before the insert statement:
SET search_path = public, pg_catalog;

This now ensures that the correct public schema is targeted.
Expected behavior
The generated structure.sql file has a statement setting the search_path just before declaring the INSERT INTO "elixir_migrations statement.

I would be happy to submit a PR that updates Ecto.Adapters.Postgres.append_versions/3 to prefix the INSERT statement with SET search_path = public, pg_catalog;
Also would be happy to implement a different solution if required.

I can see two solutions:

always prepending the SET search_path part,
always writing to public.<table> instead of just just <table>

I'm not really sure which one would be better.

Both options do seem viable. I had tried adding the following to config.exs:

I would be happy to submit a PR that updates Ecto.Adapters.Postgres.append_versions/3

Please send a PR to append_versions/3 but let's change this line and this line to always include the public prefix.

Could be an option to scan the output of pg_dump to extract SET search_path directives, aggregate all the schemas and prepend SET search_path = <schemas>; before the INSERT INTO schema_migrations?

@fertapric I would go with the simplest solution until somebody has a different case.

I'll go ahead and make the changes that @josevalim indicated, and send through the PR early next week.

I'm adding this comment here, I'm more than happy to raise a more detailed issue and/or PR, I just figured it would make sense to check with people who had worked on this recently on a similar issue before doing so; just let me know what's the best approach :smiley:
Problem
We've hit a similar problem recently, thanks to a change in the way that Postgres handles a default search_path in both 10.3 and 9.6.8
We're having issues because our pg_dump output changes all the schema definitions to be prefixed with public. Consequently, our structure.sql has changed:
-CREATE TABLE events (
+CREATE TABLE public.events (

The problem is that because the append_versions/3 manually constructs an INSERT INTO statement, the migrations aren't actually inserted into the correct place, so our migrations don't get inserted into the right place and we are essentially unable to run migrations.
The change in #2415 fixes that, but is not necessarily backwards with older versions of pg_dump which don't prefix the search_path.
Potential solution
A better solution may be to change the append_versions/3 function to actually use pg_dump to get the contents of the table, rather than constructing an INSERT INTO string. That way the schema versions will always be consistent with whatever version of pg_dump is being used. It should also be more future-proof.
I've tested this locally and it appears to work fine, would you be open to me opening a PR up about this?

@seddy Thank you for the report!
Unfortunately I don't quite understand why #2415 is not enough. Would you mind expanding on that a bit?

Thanks for the quick response @josevalim! Apologies that my description isn't too clear, I'll try and clarify it. I suppose ultimately what I'm suggesting is an enhancement to #2415.
Currently, Ecto.Adapters.Postgres.structure_dump does two things:

Use pg_dump to unload the current schema to a file
Constructs an INSERT INTO statement to insert all the versions which is then appended to the structure file

The problem I'm experiencing is that with 10.3 and 9.6.8, postgres have removed public from the default search_path (I think!). Consequently, when trying to load my current structure.sql, the task blows up because it can't find my schema_migrations table. This is very similar to the issue raised here.
#2415 does fix that by enforcing we always look in the public namespace, but it just seems odd to me that we're manually constructing the statement to insert versions, rather than pg_dump.
If we had been using pg_dump, then we wouldn't have hit this problem on upgrading to 10.3, because pg_dump would have correctly prepended the public namespace to schema_migrations. It also would have avoided the issue that was originally raised here, so I think this might be a more future-proof solution.
Does that make more sense? I'm happy to open up a PR to show the change as I think it should be fairly straightforward to do.

@seddy it makes sense now, thank you.
However, it seems there isn't any gain in moving to pg_dump, since master works correctly. Sure, if we used pg_dump since the beginning it would always work, but that's also true if we had included public. since the beginning. :)

Heh, true @josevalim ;)!
I'd still be keen to change this to use pg_dump instead of having to manually build up an INSERT INTO statement. It seems like the right tool for the job, and the issues raised here are just examples of where it can go wrong; I think it's entirely possible that similar problems could happen again in the future.
If you don't think it's worth it then that's fine, I won't worry about it :).
However, although #2415 is on master, there hasn't been a patch release yet for it; so consequently ecto is currently incompatible with postgres 10.3 or 9.6.8 (to be fair, they were only released a week ago!), any idea when we'll get a new release please?

@seddy I will release a new version of the stable release with this backported. :)


Upgrade to Hugo 0.120.4, which include security patch

No change to the generated site files (except for the site info):
$ (cd public && git diff -bw --ignore-blank-lines -I "Hugo 0.1")
diff --git a/site/index.html b/site/index.html

Superseded by:

#3519

Since Docsy 0.7.2 requires Hugo 0.120.4.


Update Composer dependencies (2021-11-25-00-12)

Visual regression test passed!
View the visual regression test report


All repositories should required DCO verification on pull requests

Recently DCO check was added to the .github template for OpenSearch-Project, this should be rolled out into all of the existing repositories to ensure that DCO checks are done on any incoming pull requests.
Repository issues:

https://github.com/opensearch-project/project-meta/issues/21
https://github.com/opensearch-project/alerting/issues/190
https://github.com/opensearch-project/alerting-dashboards-plugin/issues/120
https://github.com/opensearch-project/anomaly-detection/issues/256
https://github.com/opensearch-project/anomaly-detection-dashboards-plugin/issues/98
https://github.com/opensearch-project/asynchronous-search/issues/47
https://github.com/opensearch-project/common-utils/issues/76
https://github.com/opensearch-project/dashboards-notebooks/issues/86
https://github.com/opensearch-project/dashboards-reports/issues/169
https://github.com/opensearch-project/dashboards-visualizations/issues/28
https://github.com/opensearch-project/data-prepper/issues/326
https://github.com/opensearch-project/documentation-website/issues/190
https://github.com/opensearch-project/index-management/issues/156
https://github.com/opensearch-project/index-management-dashboards-plugin/issues/99
https://github.com/opensearch-project/job-scheduler/issues/67
https://github.com/opensearch-project/k-NN/issues/107
https://github.com/opensearch-project/logstash-output-opensearch/issues/85
https://github.com/opensearch-project/notifications/issues/333
https://github.com/opensearch-project/OpenSearch/issues/1318
https://github.com/opensearch-project/opensearch-build/issues/658
https://github.com/opensearch-project/opensearch-cli/issues/28
https://github.com/opensearch-project/OpenSearch-Dashboards/issues/834
https://github.com/opensearch-project/opensearch-devops/issues/74
https://github.com/opensearch-project/opensearch-plugins/issues/88
https://github.com/opensearch-project/performance-analyzer/issues/68
https://github.com/opensearch-project/performance-analyzer-rca/issues/78
https://github.com/opensearch-project/perftop/issues/21
https://github.com/opensearch-project/piped-processing-language/issues/8
https://github.com/opensearch-project/project-website/issues/334
https://github.com/opensearch-project/security/issues/1463
https://github.com/opensearch-project/security-dashboards-plugin/issues/835
https://github.com/opensearch-project/sql/issues/223
https://github.com/opensearch-project/trace-analytics/issues/121
https://github.com/opensearch-project/opensearch-plugin-template-java/issues/14
https://github.com/opensearch-project/project-meta/issues/22
https://github.com/opensearch-project/geospatial/issues/6
https://github.com/opensearch-project/cross-cluster-replication/issues/201
https://github.com/opensearch-project/opensearch-go/issues/71
https://github.com/opensearch-project/opensearch-java/issues/39
https://github.com/opensearch-project/opensearch-py/issues/80
https://github.com/opensearch-project/opensearch-js/issues/180
https://github.com/opensearch-project/helm-charts/issues/76
https://github.com/opensearch-project/ansible-playbook/issues/4
https://github.com/opensearch-project/opensearch-dashboards-functional-test/issues/6
https://github.com/opensearch-project/opensearch-dashboards-test-library/issues/3
https://github.com/opensearch-project/opensearch-ci/issues/19

To fan this issue out to all repos, this is the command:
meta exec "gh issue create --label enhancement --title 'Ensure DCO Check' --body-file ./issue.md"
issue.md:

A Developer Certificate of Origin is required on commits in the OpenSearch-Project, not all repositories are checking for this requirement.
This can be done via a GitHub Action and has already been implemented in the default project template, doc.yml.  Copy this file into workflow/doc.yml and the workflow will be enabled on pull requests.
Make sure to update CONTRIBUTING.md to have a section on the DCO per the project template.

[ ] DCO Check Workflow
[ ] CONTRIBUTING.md DCO Section

@dblock mind reviewing this before I pull the trigger?

You'll want the child issue linked to this one (or another parent) that can be updated easily in case instructions need to evolve, and be a little more prescriptive scoped for the repo in which the issue is opened. Plus DCO.yml should not be DOC.yml ;)
Coming from https://github.com/opensearch-project/project-meta/issues/17.

A Developer Certificate ... (I would drop not all repositories ...).

See [dco.yml](https://github.com/opensearch-project/.github/blob/main/workflow/dco.yml) for an example. Ensure that CONTRIBUTING has a section ...

- [ ] ...

When you run meta it will execute in a subdirectory of the project, so you'll need to make issue.md and reference it as ../issue.md.

coming from https://github.com/opensearch-project/opensearch-py/issues/80#issuecomment-931543356
in short, the dco bot can be configured at the organization level and it doesn't need any github action workflows.
I just wanted to comment about the other options available. Please feel free to proceed with whatever option the organisation maintainers prefer.
Thanks.

Initially we considered using that DCO bot and choose not to due to its requirement to access private repositories.
This option seems like the best path forward to stop the manually inspection ever commit in a pull requests

@peternied Instead of having everyone go and create duplicate github workflows across all the repositories, do you want to create workflow template in the .github repository and then all repos can reuse that workflow without having to duplicate?
https://docs.github.com/en/actions/learn-github-actions/creating-workflow-templates
https://docs.github.com/en/actions/learn-github-actions/reusing-workflows

@dbbaughe Looking atcalling-a-reusable-workflow would look something like this with already checked in version of this workflow:
jobs:
  dco-check:
    uses: opensearch-project/.github/workflows/doc.yml@main

Could you try that out and see if we should change the instructions on the issues?

@peternied Based on the creating-workflow-templates part it seems the reusable templates must be in a directory called workflow-templates along w/ some json properties file before they can be used.

I'll drill in more next week, great suggestion

@dbbaughe I've attempted to follow the instructions with my own organization, but haven't been able to get it to work.  If you can get it to work I would be happy to update the instructions on all the issues.
In either case, each team will still need to create a workflow and update its CONTRIBUTING.md


sndev profiles

fixes #928 by using docker compose profiles.
By default all will be run. If you only want to run specific services for specific features, set COMPOSE_PROFILES to use one or more of minimal|images|search|payments. To only run mininal services without images, search, or payments:
$ COMPOSE_PROFILES=minimal ./sndev start

To run with images and payments services:
$ COMPOSE_PROFILES=images,payments ./sndev start

Summary by CodeRabbit

New Features

Enhanced the development environment setup by introducing the ability to run specific services (minimal, images, search, payments) using COMPOSE_PROFILES.

I was also going to say that I thought it would be nice to bake this support into sndev natively, but I think using the COMPOSE_PROFILES env var which is already natively supported by docker compose provides a cleaner, more scalable solution long term, so I am good with it. I guess the alternative would be to supply the same string e.g. payments,images to ./sndev start as an arg e.g. ./sndev start payments,images. It just depends on whether you want to go with ENV VARs or CLI args for ./sndev long-term, I suppose.

Looking at the commits, I see you first explored making this an argument-driven config, and opted for the env var approach for simplicity. All good then!

Looking at the commits, I see you first explored making this an argument-driven config, and opted for the env var approach for simplicity. All good then!

It was a bit of a nightmare trying to manipulate command line args in a posix way. This setting also doesn't seem like something anyone would want to type out every time they called start/stop/status/etc.
If I were to use this I'd probably just export it.
export COMPOSE_PROFILES=minimal
./sndev start
./sndev stop

Thanks for the review!


PLAT-11223 bump version to prepare new release

Ticket
PLAT-11223
Description
bump version to prepare new release

do we want a major version upgrade? (vs just 1.7.x) as we did not change much in the generator itself

PR closed in favor of https://github.com/SymphonyPlatformSolutions/generator-symphony/pull/131


Submitted update hangs in mempool + makes refresh tx rejected (due to spending the same pool box)

The update tx was accepted by the node and was good for another five blocks (until the refresh tx decreases reward tokens in the pool box).
The update tx has hung in the mempool for 15 hours already. This makes the node reject new refresh tx (probably due to double spending), rendering the pool frozen.

To overcome double spending error submit the tx with increased tx fee.

Although blindly increasing tx fee might not be a good idea.
Cons:

Almost every tx submitted to a node hang a few cycles in the mempool until the next block is mined. In the meantime, the node rejects with a double spending error. So we must ensure a significant time has passed since the last submitted tx.
We need to set a limit so that we would not raise the tx fee to sky-high values.

Resolved it by increasing base_fee in the config and restarted the oracle.

Closed in favor of #176


Can not retrieve source from org

Issue Type: Feature Request
I am unable to retrieve source from org but I am able to deploy source to org.
Also I am not able to retrieve source in manifest from org
VS Code version: Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523, 2020-12-16T16:34:46.910Z)
OS version: Windows_NT x64 10.0.18363

Are you using a Salesforce extension? If yes, please report the issue to the extension repository and close this one.

Are you using a Salesforce extension? If yes, please report the issue to the extension repository and close this one.

thanks

thanks


This was fixed in https://github.com/drizzle-team/drizzle-orm-docs/commit/c268f0cd15d84ae850cc1983a5b5c85e96ba39d6

@heysanil Thanks for pointing it out. Closing.