check mime Version, use correct mime Function

Polymer 3 uses Yarn as Package-Manager and needs the --flat option set.
send has mime as dependency and there are some breaking changes between mime v1 and mime v2.
With the need for the yarn --flat option in Polymer 3, only one Version of mime can be installed for the project. So, if i have mime v2 installed (remember,yarn --flat allows only one Version per package), send calls mime.lookup and mime.charset wich are not available in mime v2.
The commit tests wich function is available in send (send v1 uses lookup(), send v2 uses getType()) and uses the recognized function.

Nope.

Sorry, that was a comment to a different issue.

Thanks for this. I've never heard of this before. This kind of seems like a weird restriction -- npm from my understanding allows us to declare the version of modules we need, for this very reason. I'm not sure doing this is really a sustainable way to move forward, though.
At the very least, we need tests added for the new logic branching added and documentation added about this, especially if this means the mime types this module returns will no longer be predictable (i.e. because we can no longer control them by the version of mime we depend on).

The mime library is directly part of our public API as require('send').mime, so swapping it out may break other modules that use send, especially if they are defining their own mime types. This issue and caveats likely needs to at least be documented in the README if this is something that is supported 👍

I will add tests.
Yes, npm will allow to install the module we need, but with yarn --flat (never used yarn before) you are able to install only version per package.
From the yarn docs:
Install all the dependencies, but only allow one version for each package. On the first run this will prompt you to choose a single version for each package that is depended on at multiple version ranges. These will be added to your package.json under a resolutions field.

Gotcha. Yea, never tested with yarn and even at the top of the readme for this module it is explicitly stated it is for npm. We probably want to test that too.

Also that polymer link you included seems to say you shouldn't be using flat with server side npm dependencies at all, which is probably why you're the first one ever reporting this? Is anyone else even havig this issue following that polymer setup instructions?

The Problem we encountered is in our case webpack-dev-server / webpack-dev-middleware. Webpack relies on mime v2.
Imho the Problem is that you can't really mix npm and yarn. There is no option or flag in yarn that package.json should be ignored (afaik). See [https://github.com/yarnpkg/yarn/issues/2550]
Sure, you can install package 'foo' with npm and package 'bar' with yarn, but each time you call yarn add bar, yarn also installs/parses all packages from package.json.
Otherwise i set up my project the wrong way - would be happy if this is the reason

So the link you provided has the following section:

If you have other npm dependencies, such as servers, dev tools, or compilers, installing all dependencies flat may cause version conflicts. In that case, you have several options:

Did any of those solutions work for you? It sounds like it describes your exact issue.

Hi @spacecowboy23 so what is the status on this pull request? I don't see any changes requested made, and never got an answer to my question in the previous comment.

Closing due to no response.


FR for breadcrumb view: include PROGRAM/FUNCTION

With the sample code from #112 we have a breadcrumb like
file -> PROCEDURE DIVISION -> SOME-PAR.
It would be nice to have also the defined program/function shown, some samples:
PROGRAM-ID. prog1.

PROGRAM-ID. "prog2".

PROGRAM-ID. prog3 as 'SOMEPROG'.

FUNCTION-ID. 'func.'

I suggest to leave both the literals and the case as it is, leading to the following possible breadcrumbs:
file -> PROGRAM prog1 -> PROCEDURE DIVISION -> SOME-PAR
file -> PROGRAM "prog2" -> PROCEDURE DIVISION -> SOME-PAR
file -> PROGRAM prog3 ('SOMEPROG') -> PROCEDURE DIVISION -> SOME-PAR or
file -> PROGRAM prog3 as 'SOMEPROG' -> PROCEDURE DIVISION -> SOME-PAR
file -> FUNCTION 'func' -> PROCEDURE DIVISION -> SOME-PAR
Especially when you have a file with multiple program/function definitions in this helps a lot, especially if the sub-content is moved to a sub, currently a multi-program source has the following breadcrumb options showing up when multiple programs/functions are defined in one source:

Changes already made


Merge v2.0.2

I'm sorry,

I sincerely apologize for accidentally sending my operations in my personal repository to your repository.


Explore: loading project repos using Github PAT

See docs about accessing remote content

A slight issue: trying to load_data during Netlify's build step returns a 403 Forbidden error. Must be some kind of connection error/refusal during the build step. There are two options:

See if Netlify's buildbots can be configured to allow HTTP requests (may not be possible)
Load GitHub repositories with javascript (can be done, must figure out the default if javascript is disabled)


ScenePicker is no longer created everytime we pick something

Addresses #2754
Apart from the other regular instantiations of TextureStore, it is only created once when we pick an object the first time in the scene or drag and drop a material the first time in the scene.
I've tested the code with all the test cases mentioned in the issue.
If you could think of a more elegant solution than what I've done in MainWindow::slot_open_cornellbox_builtin_project(), please let me know! :)

@oktomus Did you see the above conversation with @dictoon regarding this issue?

@achalpandeyy Yes I did. But by user should not be able to "pick" while its rendering. And if the user picks on an empty render and it doesn't find anything, that's ok.
If you leave the previous has_trace_context, do you ever get any errors ?

If you leave the previous has_trace_context, do you ever get any errors ?

@achalpandeyy Yes I did. But the user should not be able to "pick" while its rendering. And if the user picks on an empty render and it doesn't find anything, that's ok.
If you leave the previous has_trace_context, do you ever get any errors ?

You would get a Read Access Violation if you put has_trace_context there because you try to pick when AssemblyTree isn't created.

TextureStore is created only one time per Project, just before the rendering is started for the first time.
Rest of the system holds references to the TextureStore.

Thanks @achalpandeyy ! Looks great :)
There is one thing that I'm concerned about. Previously, we used to have multiple texture store (I saw one with 0 parameters and 1 with some paramters). And now, we have the same texture store everywhere and we are not sure which parameters are used. I think that's problematic but I don't know how TextureStore are used.
@dictoon Can you have a look on this ?

@oktomus, this is a vaild point. I'd love to test it.
Do you know of any test scenes which use the "texture_store" param? I couldn't find any.

Do you know of any test scenes which use the "texture_store" param? I couldn't find any.
Have you tried grep store or something inside the test scenes folder ?

Do you know of any test scenes which use the "texture_store" param? I couldn't find any.

Have you tried grep store or something inside the test scenes folder ?

I haven't tried running grep to find it.
Again, from my conversation with @dictoon on Discord, I've found that no scene is supposed to set these are params. They are characteristic of the machine and not the scene.
There is an option to force-set these params in appleseed.studio's "Rendering Settings". In the event someone actually does use this, a TextureStore would be properly initialized with these params just before rendering starts for the first time (in MainWindow::start_rendering), then the remaining system uses this TextureStore.

Thanks for your work @achalpandeyy! I've thoroughly checked this PR, and overall it looks very good. I replaced a few #include by forward declarations where this had become possible.
My main issue now has to do with the new requirement (if I'm not mistaken) that the texture store must be manually initialized before starting a render. See my comment on that. We need to find a solution that doesn't require doing any manual initialization.

It seems that the unit tests don't pass, possibly for the same reason (texture store not initialized).


EMQX Helm Repository is stuck at 5.0.3

Details
What steps did you take and what happened:
I noticed that although new releases are out (5.0.10), the repo still only goes to 5.0.3
What did you expect to happen:
Normal upgrade
Anything else you would like to add:
Will be trying a gitrepo approach similar to kubegres. It's an actual use-case for the flux HelmChart so that's nice.
Additional Information:
emqx/emqx#9000 was closed but the problem is obviously still there

Looks like it was finally fixed as evidenced by #2321


Link with parenthesis does not get Active class

Hi so this is more of a question.
When a url contains a parenthesis such as: https://hydal.xyz/pricewatch/027357/intel-core-i7-7820x-(boxed)
A link element <NavLink to="/pricewatch/027357/intel-core-i7-7820x-(boxed)">link</NavLink> will not be active, when on this page.
Is there anyway to make it active? would you have to use the exact prop to do this?
FYI using versions:
"react-router": "^4.2.0",
"react-router-dom": "^4.2.2",

#5596 fixes this (but has not been released yet). If you need this in the short term, I would probably copy that code into it's own module in your project (you just need to fix the imports).


FancyZones high CPU usage

Microsoft PowerToys version
0.41.4
Running as admin

[ ] Yes

Area(s) with issue?
FancyZones
Steps to reproduce
To be honest I don't know how to trigger this bug. But my laptop was running pretty slowly so I looked at Task Manager, and PowerToys FancyZones is first on the list, taking up ~25% CPU!

I have two external monitors and I'm on a Windows 11 preview build.
✔ Expected Behavior
FancyZones not to be using any CPU.
❌ Actual Behavior
FancyZones is using a very large amount of CPU.
Other Software
No response

Hmm. It also seems to be completely non-functional: the shortcut key (Win+Shift+`) doesn't do anything, and neither does manually clicking "Launch layout editor". Sounds identical to #9853...

I think I grabbed some event traces, though I don't know anything about how to read them or if they're useful or not. Let me know how I should share them.

Same problem here with Lenovo Yoga i7 Slim (AMD version).

Happening top me as well even with latest update.

@50Wliu @gummipunkt @Achenar459 could you please check if the FancyZones is not outdated? You could find it in C:\Program Files\PowerToys\modules\FancyZones\PowerToys.FancyZones.exe. Does it have the right version?

Looks like it's updating properly, I have version <IP_ADDRESS>. I haven't enabled it since running into this issue though (if you want, I can, to see if it still repros).

Looks like it's updating properly, I have version <IP_ADDRESS>. I haven't enabled it since running into this issue though (if you want, I can, to see if it still repros).

It would be great if you check if the issue is still reproducible.

I had v41.4 installed. Just updated to 43.0. I haven't used it since I
posted this issue.
On Wed, Aug 4, 2021, 6:57 AM Seraphima Zykova @.***>
wrote:

@50Wliu https://github.com/50Wliu @gummipunkt
https://github.com/gummipunkt @Achenar459
https://github.com/Achenar459 could you please check if the FancyZones
is not outdated? You could find it in C:\Program
Files\PowerToys\modules\FancyZones\PowerToys.FancyZones.exe. Does it have
the right version?
[image: image]
https://user-images.githubusercontent.com/8949536/128193539-28a6f621-918a-4f5d-a3d5-d73db182a8b2.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/12244#issuecomment-892680753,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACXISC3XBG42IL6JU6YGH6DT3FBKXANCNFSM475HGAGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

@sawacrow can you provide more data here. possibly provide a "report bug" zip file
hi crutkas.
i installed current version (0.47) and i cant see problem. everything is ok. thank you!

I am still experiencing this issue with FancyZones not responding to its hotkey and having CPU usage above 20%. I attached a bug report to a comment on Issue #14234.

Still having the problem with 0.51.0. Downgraded to 0.37.2 and the problem disappeared (but PowerToys keeps nagging for update).

Yes, current version is using 27.6% for me, and I'm not moving windows of any kind right now...

@ukanuk, @Dr-Chronosphere, @yozi66, @jgcannon Tracked via #14234.
A dump might be helpful. :)

Try 0.59 and see if the issue is resolved. If not, please let’s create a new issue so we can be hyper targeted.

0.59.1 has solved the problem for me. Thanks!


missing example code in Concurrency:Sendable section

Location
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/concurrency
Description
At the end of the Sendable section, the following sentence appears:
"In the code above, the NonsendableTemperatureReading is a structure that meets the criteria to be implicitly sendable."
But there is no such code above.
Correction
No response

Thanks!  This was fixed by PR #228 and merged into 'main', and will be corrected in the next update of TSPL.


Fixed: Redis-backed queues do not consume further messages once a queue is empty

Redis LPop command does not wait for new messages.
Redis BLPop command is blocking version of LPop command and it blocks the connection when there are no elements to pop from the list.
Use BLPop for redis-http-connector instead of LPop.

Fixes https://github.com/fission/keda-connectors/issues/159

@soharab-ic can you confirm if we can reproduce https://github.com/fission/keda-connectors/issues/159 and have cross verified fix with the same ?

@soharab-ic can you confirm if we can reproduce #159 and have cross verified fix with the same ?

Yes @sanketsudake, I reproduced the issue #159 and then verified the fix with the same.


[Filestore] Multitablet filesystems

Right now one FS == one IndexTablet which is a bottleneck for:

fetching and updating block layer index info upon read and write requests - severely limits our read/write IOPS
fetching and updating byte layer data upon unaligned read and write requests
processing file metadata requests like open/close/stat/create/delete

It's also a limiting factor for max FS size because a single tablet needs to be able to store the whole block layer index - this index can't be too big. In fact handling a 100+TiB FS is a challenge already.
We need to be able to provide linear scalability for FS size and single file-level ops:

any kind of file IO
open/close/stat calls

The suggested solution is to make N + 1 tablets for a single FS where N will be determined based on the FS size upon FS creation. First versions may even require manual creation of the additional N tablets. 1 tablet would store the directory inodes and node refs. The refs which point to file inodes would point to other N tablets which would store all files directly under the root, the names of the node refs in their root directories may simply be guids.
Technically, file creation and deletion would cause a multi-tablet transaction, but it won't be hard to implement - we don't need a full 2PC here and we can also keep a cache of pre-created 0-size files to be able to serve creation requests without a multi-tablet transaction. Deletion can be served asynchronously - the client wouldn't be able to find a file which was deleted after we delete its last node ref (if there are no open file handles) - so there is no need for a real synchronous multi-tablet transaction here either. Again, the first version doesn't need to have those optimizations and can simply handle multi-tablet transactions in the following way:

in addition to modifying the node refs table we should also add an entry about the requested op (create/delete node) to a log table
as long as we have op entries in the log table we should repeatedly retry those ops - as soon as an op completes, it should be deleted from that table.
the client (TStorageServiceActor) should return proper error code if it sees a mismatch between a node ref and a node (e.g. a ref to a not-yet-created node should be treated as if the file doesn't exist - ENOENT)

What needs to be done in the first version:

support external node references - node refs may point to either node ids local to the tablet or pairs <tabletId, nodeName> for external node references
support external inodes in TStorageServiceActor - it should be ready to receive a node ref in the form of <tabletId, nodeName> in response to its requests which work with file inodes and perform a second request to tabletId - handleId -> <tabletId, nodeName (or nodeId)> cache should be implemented in the first version I suppose
support tablet relations configuration - there should be an ability to tell a tablet to create file inodes in a bunch of other tablets
support the ability to create/delete external inodes

We also need to properly track sessions in slave tablets. I think the easiest way do do that is creating the sessions in the slave tablets by the master tablet upon session creation in the master tablet. Master tablet is then responsible for pinging slave tablet sessions.

filestore containing 10+1 tablets
fio results for 60 clients x 32 numjobs x 1 iodepth
read: 128KiB x 560k IOPS = 70-75GB/s throughput
write: 1MiB x 20-25k IOPS = 20-25GB/s throughput (unstable, sometimes high vdisk latency percentiles for PutTabletLog spike and performance decreases)

Same configuration:

filestore containing 10+1 tablets
60 clients x 32 numjobs

mpi run+ior results:

mpirun --mca routed direct -H $NODES -np 1920 ior -o /root/mnt/ior_file_4 -t 1m -b 1G -F -C --posix.odirect

access    bw(MiB/s)  IOPS       Latency(s)  block(KiB) xfer(KiB)  open(s)    wr/rd(s)   close(s)   total(s)   iter
------    ---------  ----       ----------  ---------- ---------  --------   --------   --------   --------   ----
write     33223      33226      0.043396    1048576    1024.00    0.671776   59.17      24.18      59.18      0
read      68913      68937      0.026574    1048576    1024.00    0.136836   28.52      11.87      28.53      0

mpirun --mca routed direct -H $NODES -np 1920 ior -o /root/mnt/ior_file_5 -t 128k -b 1G  -F -C --posix.odirect

access    bw(MiB/s)  IOPS       Latency(s)  block(KiB) xfer(KiB)  open(s)    wr/rd(s)   close(s)   total(s)   iter
------    ---------  ----       ----------  ---------- ---------  --------   --------   --------   --------   ----
write     5919       47351      0.038011    1048576    128.00     0.693598   332.17     137.91     332.18     0
read      23958      191680     0.007246    1048576    128.00     0.097548   82.06      41.54      82.06      0

we reached up to 50GB/s write, 100GB/s read

60 clients, 32 iodepth per client, 30 tablets
40-45GB/s write

If a file is unlinked during listing we may get a ENOENT error upon GetNodeAttr in ListNodesActor and will return E_IO to the client: https://github.com/ydb-platform/nbs/blob/b4d83e4447bd186d83a7807560f209f58576a9e9/cloud/filestore/libs/vfs_fuse/fs_impl_list.cpp#L330
https://github.com/ydb-platform/nbs/blob/main/cloud/filestore/libs/storage/service/service_actor_listnodes.cpp#L337 - this needs to be done asap

Will implement automatic creation of the shards based on FS size and will close this issue after that. Everything else's done.

Will implement automatic creation of the shards based on FS size and will close this issue after that. Everything else's done.

Decided to move this to a separate issue: https://github.com/ydb-platform/nbs/issues/1932


Global variable destruction order

We have encounter a crash in program exiting, with coredump stacktrace like this:
#0  tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::FreeList*, unsigned int, int) () from /app/mipilot/lib/libtcmalloc.so
#1  tcmalloc::ThreadCache::Scavenge() () from /app/mipilot/lib/libtcmalloc.so
#2  ProcessContext() () from /app/mipilot/lib/libados_apprt.so
#3  NodeLaunch::~NodeLaunch() ()
#4  main ()

Is it possible that some global/static variable of tcmalloc have been destroyed, like Static::central_cache()?

We don't destroy anything (well, almost, we have couple places like in heap leak checker). It also Google-style policy (google-search for Google C++ style guide).
As for your crash, pretty much all crashes like this is some bug in user's code. That it crashes in tcmalloc bits doesn't really prove it is "us". (Of course we cannot 100% guarantee we have no crashing bugs, but it is super unlikely that we have)
As usual in such cases, consider running with various malloc debugging tools: asan, our "own" debugallocator, valgrind etc.


Rundeck 2.7.x

This PR is in work in progress

Closing this for now..Will open a separate PR once it is working in my local environment


Listing block headline should integrate with TOC

config.blocks.blocksConfig[block['@type']]?.tocEntry

https://github.com/plone/volto/pull/4436


Are there any examples about multiple concurrent builds (SSR) ?

This plugin looks really good for me. I just can't find how to config for multiple concurrent builds. Are there any examples? thanks.

This question is available on Nuxt.js community (#c8)

Nuxt is using webpackbar for SSR and CSR builds in its latest nuxt-edge releases.

@manniL Can you link to the code example in that project?

I couldn't find the code mentioned but my solution:
const configs = [
  {
    plugins: [
      new WebpackBar({ name: 'client' })
    ]
  },
  {
    plugins: [
      new WebpackBar({ name: 'server' })
    ]
  },
]

Adding different colours gives you the example in the readme.

@GriffinSauce Sorry for the late response!
Nuxt adds the plugin here. It'll be called twice (one time when the client-bundle is compiling, the other time for the server-bundle. This happenes here


chore: remove dart_code_metrics

dart_code_metrics has been deprecated and has therefore become obsolete. This PR removes it as a dev-dependency and removes its configuration in analysis_options.yaml.

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


Add --index

After

#64

the portal will be displaying these datasets correctly again... but vis-preview.py will fail for them. This addresses that by adding another commandline parameter. Another approach would be to add a interactive prompt, or to just pick one arbitrarily, but this approach seems like its enough.

Replaced by #66. Closing.


Broken documentation url in readme

returns

Hi @bu4ak, i have created a PR request for this issue. PR request is https://github.com/domnikl/DesignPatternsPHP/pull/408

Hi @bu4ak, i have created a PR request for this issue. PR request is https://github.com/domnikl/DesignPatternsPHP/pull/408


Add padding to Data Summary view and patch column type display

see #87. latest after new data summary view styles update:

patched up data summary view:


error during public submission of MQ data v<IP_ADDRESS>

Describe the bug
see screenshot below
To Reproduce
Steps to reproduce the behavior:

Upload MQ evidence file from v. <IP_ADDRESS>
Click on 'Parse and bench'
Scroll down to public submission
upload corresponding mqpar.xml
check parsed parameters and confirm that metadata is correct
press 'I really want to upload it'
error (see screenshot below)

Expected behavior
there should have been falling balloonsm, and a PR sent to proteobot
Screenshots

Desktop (please complete the following information):

OS: macOS Sonoma 14.2.1
Browser: Chrome Version 123.0.6312.122 (Official Build) (arm64)
done on the current server version

Additional context
I can send the two files (mqpar and evidence) to anyone interested

So the error specifies that it is param_loc is of type list. This is raised on the following line
https://github.com/Proteobench/ProteoBench/blob/f33006c666ed60d81658409c2c2fcf78364032d7/proteobench/modules/dda_quant_base/module.py#L204
param_loc is passed to the function. Going up the stack trace, I think the issue is that now the widget records a list of filenames instead of a single filename (which was needed to support FragPipe).
So the error is raised where the filename should be extracted. I think this will happen with any parameter file atm. I can try to give it a go.


Typo in generated workflow file ("Pull Reqest")

When creating a new workflow using this button:

You get the following code:
# Dependency Review Action
#
# This Action will scan dependency manifest files that change as part of a Pull Reqest, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
#
# Source repository: https://github.com/actions/dependency-review-action
# Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
name: 'Dependency Review'
on: [pull_request]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v3
      - name: 'Dependency Review'
        uses: actions/dependency-review-action@v1

Which contains this typo: where Pull Reqest should be pull request

I can't find the source of this text though

@caendesilva Thanks for the report! Can you provide a link to where you're seeing the button so I can reproduce locally? 😅

Yes of course! I think this link should work for you:
https://github.com/actions/dependency-review-action/actions/new?category=none&query=review
Otherwise, here is the steps I used to reproduce.

Go to any repository
Click actions tab, then new workflow (see image 1)
Search for the action and click configure (see image 2)
The configure button creates a new file containing the typo

@caendesilva I've opened a PR to fix the typo: https://github.com/actions/starter-workflows/pull/1572, once it's merged you should see the proper description. Thanks a ton!


Add Etcher

Add Etcher to built on atom.io section.
Etcher is a safe & easy way to burn images to SD cards and USB drives.

@craig-mulligan we just launched the new Electron 1.0 site in #238 and the icons are now managed in an apps.yml file.
See https://github.com/electron/electron.atom.io/blob/gh-pages/CONTRIBUTING.md#adding-an-app-or-project-to-the-site for more details, thanks!

Closing this out, please open a new pull request that follows the new contributing guidelines, thanks.


cmd/compile: internal compiler error: Type.Elem UNSAFEPTR

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
Version 1.10
doesn't happen on 1.9
Does this issue reproduce with the latest release?
I'm on the latest release.
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/saxon/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/saxon/go"
GORACE=""
GOROOT="/usr/lib/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.10/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build007043969=/tmp/go-build -gno-record-gcc-switches"
What did you do?
Tried 'go build' in av/rtmp on the repo: https://bitbucket.org/ausocean/av/src on the branch librtmpPorting.
What did you expect to see?
a clean build
What did you see instead?
bitbucket.org/ausocean/av/rtmp
:1:0: internal compiler error: Type.Elem UNSAFEPTR
Please file a bug report including a short program that triggers the error.
https://golang.org/issue/new

Note: I don't see this on go1.9

I checked out  https://bitbucket.org/ausocean/av, and ran git checkout librtmpPorting, but there is no src directory there.  Can you give precise directions for reproducing the problem starting from scratch?  Thanks.

/cc @randall77 @josharian
@gopherbot please open a backport issue as this might be a 1.10 regression.

@FiloSottile in the future, can we wait on backport setup until we can reproduce?

It seems like you hardcoded in a few places that the librtmp you are using with cgo can be found in /usr/local/lib. In fact, when I try to build the c dependencies of your project using make, it instructs me to run sudo make install-deps, which I have no intention to do.
Please provide a reproducer that can be compiled without the requirement of running a make command from root.

I'll amend the comment I wrote above since it sounds unnecessarily harsh.
What I wanted to say is that, in general, Go contributors and the Go Devs will be able to help much quicker if the reproducer attached to a bug is easy to build. In this case I downloaded your repository, looked into it, and I found out that building it -apparently- requires to run a make command from root, to move headers you depend on into a specific system folder. Since running arbitrary commands from root is something that may have harmful consequences, anyone investigating your report may be unwilling to do that, and this will slow down the investigation. For this reason, we usually ask the reporter to try to make the reproducer as small, simple, and easy to build as possible.

I ended up committing past the problem. I'm going to rebase and create a new branch. I'll also provide instructions for building the C stuff in the program dir rather than in /usr/local.

@Saxon1 is this still an issue? W/o a way to reproduce we cannot act on this. Please let us know if you can provide more detailed information, or close the issue.

I've closed the backport bug as well.


Cleo log improvements

Automatic adding separator line to .cleo.log if frame render occur since last log entry.
Removed outputting text formatting sequences like ~r~ to log file. Logging ~n~ as actual new line.
Logging last and previous opcodes as FFFF if no script was executed.
Deleting CLEO4 log file on start.

please undo

Done


only consider tests within testpaths pytest variable

As per https://docs.pytest.org/en/7.1.x/explanation/goodpractices.html#conventions-for-python-test-discovery

Not relevant as per second thoughts on #55


specific game

how i download a specific game? i tried to get help with chat gpt / gemini but both of them failed
gog-downloader download "d:\example" --game "Overcooked! 2" --language es --os windows --language-fallback-english
error i get: option does not exist.

Try this, it might work: gog-downloader update --search "Overcooked! 2" && gog-downloader download --language es --os windows --language-fallback-english.
What's your use case for this? You can simply download the game files using a browser if you're only after a single game.

on cmd, gettin no error, but it seems not working as intended

and the biggest reason for me, its about games with a lot of parts, its esier by gog downloader

What do you mean by not working as intended?

its says ¨ok ¨ but nothing download

Can you provide a screenshot or something? It's really hard to help you when I don't know what's going on.

powershell

Hmm, that looks like a mistake on GOG's side, searching for "Overcooked! 2" in your owned games list doesn't yield any results. Searching for "Overcooked!" does. I'll add a flag to the download command that let's you specify the games to download.

I just release v1.7.0 where you  can specify the --only flag to the download command. So the new command would look like:

do gog-downloader update as usual, if you don't plan on downloading other games, you can make it quicker by only searching for "overcooked": gog-downloader update --clear --search overcooked
do gog-downloader download --language es --os windows --language-fallback-english --only "overcooked! 2"


Normalize crate names when reading Cargo.toml

This seeks to address two problems.
- vs _
The Rust community tends to use - and _ as word separators in package/crate names. However, the allowance of both characters, and the fact that - is invalid in a crate name in Rust source, has created something of a messy situation. For some crates, users need to write - in their Cargo.toml and _ in their Rust source (tokio-core, rustc-serialize, num-traits). For others, _ is used in both places (lazy_static, serde_derive, symbolic_expressions). This creates a point of confusion and imposes additional cognitive overhead.
Proposal: teach Cargo to treat these characters as equivalent when reading crate names from Cargo.toml, normalizing them to _ (matching their representation in Rust source).
According to @Manishearth:

Crates.io considers them to be the same when uploading crates
Rustc will always see crate names with hyphens converted to underscores

(So there are no clashing crate names)

cAsE senSITIvIty
What was that one package called? inflector? Oh, no, it's Inflector. But crates.io will recognize any of inflector, Inflector, or even inFLeCtOr. And in Rust source, you're expected to write extern crate inflector.
Proposal: internally lowercase crate names read from Cargo.toml and treat case variations as equivalent. Since Rust only allows ASCII crate names, there's no need to deal with any of the oddities of Unicode case normalization.

Yeah, we've been historically lax about - vs _: https://github.com/rust-lang/cargo/blob/fe56d43b0afbe06709900b4dab4123655929a0e2/src/cargo/util/toml/targets.rs#L74-L77

Seems like a great idea to me! The actual implementation here though requires crates.io, the index, and Cargo to all agree on a canonicalization of a name. The index right now is keyed off the actual crate's name (e.g. what was uploaded to crates.io). This means there's no efficient mechanism of performing normalization right now in Cargo, and the format of the index would need to change to support this.
I also think that we shouldn't normalize case because rustc itself doesn't do that, just normalize - and _ which rustc does indeed do. For example extern crate Foo and extern crate foo I believe are considered unique items in the compiler. Cargo, however, for other technical reasons will likely continue to forbid two crates like Foo and foo existing.

Closing as a duplicate of #2775.


VLD Crash

When I run "php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 test.php", if the test.php it bigger(79.8 KB),  it will crash.   php is 7.3.9, vld is the newest version. how to solve it?

Program received signal SIGSEGV, Segmentation fault.
0x00007fffed0d0fb8 in zval_get_type (pz=0x5e850f0000000222) at /usr/include/php/Zend/zend_types.h:411
411             return pz->u1.v.type;
(gdb) p pz->u1.v.type
Cannot access memory at address 0x5e850f000000022a
(gdb) p *pz
Cannot access memory at address 0x5e850f0000000222
(gdb) bt
#0  0x00007fffed0d0fb8 in zval_get_type (pz=0x5e850f0000000222) at /usr/include/php/Zend/zend_types.h:411
#1  vld_find_jumps (opa=0x7ffff3813348, position=5, jump_count=0x7fffffffa860, jumps=0x7fffffffa7e0)
at /home/amber/vld-0.16.0/srm_oparray.c:936
#2  0x00007fffed0d1449 in vld_analyse_branch (opa=0x7ffff3813348, position=5, set=0x555555d9fb80, branch_info=0x555555d9fba0)
at /home/amber/vld-0.16.0/srm_oparray.c:1006
#3  0x00007fffed0d1158 in vld_analyse_oparray (opa=0x7ffff3813348, set=0x555555d9fb80, branch_info=0x555555d9fba0)
at /home/amber/vld-0.16.0/srm_oparray.c:965
#4  0x00007fffed0d070f in vld_dump_oparray (opa=0x7ffff3813348) at /home/amber/vld-0.16.0/srm_oparray.c:784
#5  0x00007fffed0ce8f0 in vld_dump_fe (fe=0x7ffff3813348, num_args=0, args=0x7fffffffa9f0, hash_key=0x7fffffffa9d0)
at /home/amber/vld-0.16.0/vld.c:242
#6  0x00007fffed0ce611 in vld_dump_fe_wrapper (el=0x7ffff38f6620, num_args=0, args=0x7fffffffa9f0, hash_key=0x7fffffffa9d0)
at /home/amber/vld-0.16.0/vld.c:183
#7  0x0000555555853aee in zend_hash_apply_with_arguments ()
#8  0x00007fffed0cea5f in vld_dump_cle (class_entry=0x7ffff380d018) at /home/amber/vld-0.16.0/vld.c:266
#9  0x00007fffed0ce62e in vld_dump_cle_wrapper (el=0x555555d2dcc0) at /home/amber/vld-0.16.0/vld.c:188
#10 0x00005555558535d2 in zend_hash_apply ()
#11 0x00007fffed0cee82 in vld_compile_file (file_handle=0x7fffffffd1e0, type=8) at /home/amber/vld-0.16.0/vld.c:310
#12 0x0000555555842c3b in zend_execute_scripts ()
#13 0x00005555557e2880 in php_execute_script ()
#14 0x00005555558d4762 in do_cli ()
#15 0x00005555556420cb in main ()
This is the crash information. Can anyone help?

Program received signal SIGSEGV, Segmentation fault.
0x00007fffed0d0fb8 in zval_get_type (pz=0x5e850f0000000222) at /usr/include/php/Zend/zend_types.h:411
411             return pz->u1.v.type;
(gdb) p pz->u1.v.type
Cannot access memory at address 0x5e850f000000022a
(gdb) p *pz
Cannot access memory at address 0x5e850f0000000222
(gdb) bt
#0  0x00007fffed0d0fb8 in zval_get_type (pz=0x5e850f0000000222) at /usr/include/php/Zend/zend_types.h:411
#1  vld_find_jumps (opa=0x7ffff3813348, position=5, jump_count=0x7fffffffa860, jumps=0x7fffffffa7e0)
at /home/amber/vld-0.16.0/srm_oparray.c:936
#2  0x00007fffed0d1449 in vld_analyse_branch (opa=0x7ffff3813348, position=5, set=0x555555d9fb80, branch_info=0x555555d9fba0)
at /home/amber/vld-0.16.0/srm_oparray.c:1006
#3  0x00007fffed0d1158 in vld_analyse_oparray (opa=0x7ffff3813348, set=0x555555d9fb80, branch_info=0x555555d9fba0)
at /home/amber/vld-0.16.0/srm_oparray.c:965
#4  0x00007fffed0d070f in vld_dump_oparray (opa=0x7ffff3813348) at /home/amber/vld-0.16.0/srm_oparray.c:784
#5  0x00007fffed0ce8f0 in vld_dump_fe (fe=0x7ffff3813348, num_args=0, args=0x7fffffffa9f0, hash_key=0x7fffffffa9d0)
at /home/amber/vld-0.16.0/vld.c:242
#6  0x00007fffed0ce611 in vld_dump_fe_wrapper (el=0x7ffff38f6620, num_args=0, args=0x7fffffffa9f0, hash_key=0x7fffffffa9d0)
at /home/amber/vld-0.16.0/vld.c:183
#7  0x0000555555853aee in zend_hash_apply_with_arguments ()
#8  0x00007fffed0cea5f in vld_dump_cle (class_entry=0x7ffff380d018) at /home/amber/vld-0.16.0/vld.c:266
#9  0x00007fffed0ce62e in vld_dump_cle_wrapper (el=0x555555d2dcc0) at /home/amber/vld-0.16.0/vld.c:188
#10 0x00005555558535d2 in zend_hash_apply ()
#11 0x00007fffed0cee82 in vld_compile_file (file_handle=0x7fffffffd1e0, type=8) at /home/amber/vld-0.16.0/vld.c:310
#12 0x0000555555842c3b in zend_execute_scripts ()
#13 0x00005555557e2880 in php_execute_script ()
#14 0x00005555558d4762 in do_cli ()
#15 0x00005555556420cb in main ()
(gdb) f 1
#1  vld_find_jumps (opa=0x7ffff3813348, position=5, jump_count=0x7fffffffa860, jumps=0x7fffffffa7e0)
at /home/amber/vld-0.16.0/srm_oparray.c:936
936                     ZEND_HASH_FOREACH_VAL_IND(myht, val) {
(gdb) info local
_z = 0x5e850f0000000222
__ht = 0x5555558cd860 <execute_ex+16480>
_p = 0x5e850f0000000222
_end = 0x5e850f0820000862
array_value = 0x7ffff38d61e0
myht = 0x5555558cd860 <execute_ex+16480>
val = 0x7fffffffa7d0
opcode = {handler = 0x5555558cb757 <execute_ex+8023>, op1 = {constant = 96, var = 96, num = 96, opline_num = 96, jmp_offset = 96}, op2 = {
constant = 656, var = 656, num = 656, opline_num = 656, jmp_offset = 656}, result = {constant = 0, var = 0, num = 0, opline_num = 0,
jmp_offset = 0}, extended_value = 416, lineno = 2049, opcode = 188 '\274', op1_type = 8 '\b', op2_type = 1 '\001', result_type = 0 '\000'}
(gdb) p *val
$1 = {value = {lval =<PHONE_NUMBER>7, dval = 1.2731963614986699e-313, counted = 0x5ffffa7ff, str = 0x5ffffa7ff, arr = 0x5ffffa7ff,
obj = 0x5ffffa7ff, res = 0x5ffffa7ff, ref = 0x5ffffa7ff, ast = 0x5ffffa7ff, zv = 0x5ffffa7ff, ptr = 0x5ffffa7ff, ce = 0x5ffffa7ff,
func = 0x5ffffa7ff, ww = {w1 =<PHONE_NUMBER>, w2 = 5}}, u1 = {v = {type = 72 'H', type_flags = 51 '3', u = {call_info = 62337,
extra = 62337}}, type_info =<PHONE_NUMBER>}, u2 = {next = 32767, cache_slot = 32767, opline_num = 32767, lineno = 32767,
num_args = 32767, fe_pos = 32767, fe_iter_idx = 32767, access_flags = 32767, property_guard = 32767, constant_flags = 32767,
extra = 32767}}
(gdb) p val->u1.v.type
$2 = 72 'H'
This is the crash informaiton. Can anyone help?

This the code:

This is the code:
function getForeignKeyReferentialActionSQL($action)
{
$upper = strtoupper($action);
switch ($upper) {
case 'CASCADE':
case 'SET NULL':
case 'NO ACTION':
case 'RESTRICT':
case 'SET DEFAULT':
return $upper;
default:
throw new \InvalidArgumentException('Invalid foreign key action: ' . $upper);
}
}
When I commented ths switch and related code, it works well.  It seems that vld has issue to handle switch. How to solve it ?

This is the code from https://www.php.net/manual/en/control-structures.switch.php
switch ($i) {
case "apple":
echo "i is apple";
break;
case "bar":
echo "i is bar";
break;
case "cake":
echo "i is cake";
break;
}
It seems that vld has issue to handle switch. How to solve it ?


Custom line-size warning

The component works fine with all defaults, and I can provide any custom props that are strings (such as "line-bg-color").  However, if I try to provide a custom line-size, it throws a console warning.
<spinner line-size="5" line-bg-color="#fff"></spinner>
Produces this warning:
[Vue warn]: Invalid prop: type check failed for prop "lineSize". Expected Number with value 5, got String with value "5".
It works, but the warning is not ideal.

Hi there!
Thanks for your interest in VueSimpleSpinner. The line-size prop needs to be a number since it is used for a number of internal calculations. If you add a : in front of the prop, you should be good to go -- this tells Vue.js to interpret the value as a number.
<spinner :line-size="5" line-bg-color="#fff"></spinner>
You can check the documentation for a list of available options.
Hope that helps!

Thanks Dave.  I am fairly new to Vue and I forgot about that.  But I was following your "live" JSFiddle examples and the colon is missing from those.  May want to update.


Publish Docker image

Is it possible to publish a Docker image so we can just docker run --gpus=all toverainc/willow-inference-server and have it work? That would make it trivial to launch our own server.

Definitely!
We're saving the push of official docker images for willow build as well as WIS for a 1.0 release. Both are currently under significant active development and we frequently have users test different branches, local fixes themselves, etc and in many cases it's not really possible if you're only running pulled docker images.
With 1.0 we'll have enough confidence in the testing, feedback, etc we've received from the community to publish docker images and provide a quality user experience with them.
If you look in the wisng branch you'll see a move towards docker compose, etc that will enable a more typical docker experience of "a docker run command" and/or "Clone repo, start".

Further to this, it would be awesome if this could be set up as a Home Assistant add-on so we can install it onto HA servers running HAOS.  My understanding is that HA add-ons are basically just Docker  containers.... but I have no experience or full knowledge of Docker.

We can certainly look at this but many of the Home Assistant integration aspects of Willow (WIS HAOS container, Home Assistant component for Willow, etc) are fairly significant efforts in their own right. @stintel and I are stretched pretty thin between Willow and WIS and this is an area where we think community contribution/collaboration would be very beneficial! It doesn't help that we have no experience with either and we'd have to get proficient first :).

@sparkydave1981 What functionality would you be looking to enable by providing Home Assistant integration?
If this were done, my hope would be that it would be decoupled from willow-inference-server.  Just as one doesn't typically run Frigate inference (NVR, video recording) directly on their Home Assistant box, I imagine people will want to run Willow on a different machine than the one running Home Assistant.
Going back to the topic of Docker Image - In my case, I'm running a NAS with Unraid and an Nvidia card.  This would be the natural place for me to install Willow as a 24/7 service, and I think Unraid's docker support does not support docker-compose, so it would be important to have a vanilla docker option available.  (I'm able to do this with stable-diffusion, for example).

I'm learning more and more that "one doesn't typically do XYZ" doesn't really apply. People have done, suggested, and asked for all kinds of wild things I would have never considered, think are terrible ideas, doomed to failure, etc. The deployment configurations are literally endless. There are people that talk about things like passing a GPU to a VM to run podman rootless nested inside of LXC unprivileged containers... It never ends!
docker-compose YAML files are not only handy when you actually have docker compose, they are (IMO) a much better way to represent container arguments and container dependencies when compared to a bunch of random shell scripts with a ton of docker command line options. With docker compose YAML many people can go anywhere from docker command line to helm charts for K8s.
So they serve a dual purpose - usable with docker compose and (more or less) directly referenceable documentation (of sorts) for what is required to run the container(s) however you intend to.

@sparkydave1981 What functionality would you be looking to enable by providing Home Assistant integration?
If this were done, my hope would be that it would be decoupled from willow-inference-server. Just as one doesn't typically run Frigate inference (NVR, video recording) directly on their Home Assistant box, I imagine people will want to run Willow on a different machine than the one running Home Assistant.
Going back to the topic of Docker Image - In my case, I'm running a NAS with Unraid and an Nvidia card. This would be the natural place for me to install Willow as a 24/7 service, and I think Unraid's docker support does not support docker-compose, so it would be important to have a vanilla docker option available. (I'm able to do this with stable-diffusion, for example).

I was referring to a HA add-on, not Integration. Just a way to run the WIS within Home Assistant OS.

For CPU only support this is pretty straightforward.
For GPU far from it.
The issue here will be that without GPU WIS is only slightly faster on CPU than the official HAOS faster-whisper container. Granted it has the protocol support for Willow so that's a big plus and "gets you there" but because of the fundamental performance differences of CPU vs GPU the end-user experience won't be much different in terms of response time, accuracy, etc. WIS on GPU can do Whisper large faster than most CPUs can do tiny and that is an incredible difference in terms of accuracy and end user experience (tiny is essentially useless).

You need both - Dockerfile is for building containers, not running them. Then it's either docker run or docker compose.
I'm not sure what you mean by "limited/no support for GPU pass-through". It's equivalent to the GPU arguments for docker albeit with different syntax of course. You can see both our Dockerfile and docker-compose.yml in the wisng branch.

is there any movement on pushing docker images? I use wis in a docker environment (unraid) and that pretty much means me building a local image and pushing it to my local registry to consume from. Would be nice to cut out that step if possible
Is there a problem if the main branch is continuously and automatically pushed to latest tag on docker hub for a start? that will have the benefit of users being able to test out the bleeding edge if they want to. can evolve to release tagged versions from there when you think its ready
Would you be interested in contributions to this effect?

+1, if this existed, I would run it on Unraid as well.

+1

Quick update on this: we had some challenges because we needed to extend the underlying engine of WIS (ctranslate2) to support CUDA 12 but now CUDA 12 is natively supported by ctranslate2 so building and publishing docker images is significantly more straightforward. We have some testing and validation to do but with this published docker images are coming soon!

Quick update on this: we had some challenges because we needed to extend the underlying engine of WIS (ctranslate2) to support CUDA 12 but now CUDA 12 is natively supported by ctranslate2 so building and publishing docker images is significantly more straightforward. We have some testing and validation to do but with this published docker images are coming soon!

Thanks for the feedback, great news!

Any updates on this? Would love to start fiddling around with this.

+1

Also looking for an update when the official docker image will be released.
Thanks!


Disable font ligatures

Some fonts like Roboto autmatically form ligatures but I think they make text harder to read and should be avoided.
Before:

After:

heh so this is where I would have to disagree. I much prefer ligatures in text.

I guess this will be a controversial one. I hate them 😉

@silverwind for me in github actually in your comment fl are shown with ligature :)

No ligature on GitHub here; are you using MacOS by any chance?

Android :)

Yeah, I think Roboto is the only system-level font that forms ligatures by default.
BTW, I'm now using a userstyle to disable ligatures on all sites 😉

Doesn't look like this will gain enough acceptance.


Investigate alternative backing data structures for buffers

At first I used ropey for the underlying buffer data structure but I've since swapped that out for a simple gap buffer implementation instead. That works fine for current purposes but isn't ideal for things like multiple cursors which would make parts of the exec engine more efficient. When moving away from ropey I took a look at a variety of data structures and settled on a gap buffer as the simplest to implement that achieved what I needed from it. One of the other data structures I looked at was a piece table which is worth revisiting now that things are a little easier to abstract / rework over the underlying buffer data structure.
This paper is a good introduction to piece tables.

Another alternative is to use the block / disk approach used by sam and acme that is described here: http://doc.cat-v.org/plan_9/4th_edition/papers/sam/
The source for this in the go implementation of acme is found here: https://github.com/9fans/go/blob/main/cmd/acme/internal/disk/disk.go

Closing for now until there is a need for a different data structure. The gap buffer impl is very simple but easily meets the current requirements of the project.


Update manifest for build-forc-test-project

Description

This PR updates the build-forc-test-project CI job to use a local sway-lib-std dependency

Testing Steps

[ ] CI should pass

@ra0x3 can you file an issue to add [workspace] to the test project's Cargo manifest as per https://github.com/FuelLabs/sway/runs/6275224635?check_suite_focus=true#step:10:18? (Do it in a separate PR since it's not blocking.)


Get version of python for installed library

I did another version of this in:
https://github.com/containers/ramalama/pull/60
I don't mind which one we go with

It iterates through sys.path until it finds the ramalama directory

There isn't really a way of determining guest container python version, which is tricky, I think ubi9 might be 3.9, but I don't know

Well you could figure it out by doing a quick "podman run --rm" but that starts to get messy and each podman run degrades start time

Each podman run is about 150ms from my timings... Maybe that's not too bad... GPU initialisation can take a seconds sometimes anyway

We could end up having a mix of Fedora/UBI/Stream containers also for some GPUs... But only if we really need to

Ok lets go with this one.


[Git watcher] ignore watchman cookies

This PR fixes #112293. Git ships with a watchman hook to speed things up on large repos. However, watchman creates temporary files whenever a query is run (see https://facebook.github.io/watchman/docs/cookies.html), and it hides these files in VCS subdirectories. These files trigger vscode's git watcher, which causes repository status to be refreshed. The git operations from this refresh then trigger additional watchman queries, which create more files, and we wind up in an infinite loop.
The solution is to filter these events out. Luckily, the files are created with a consistent prefix and we can filter by that.
I verified this fix by opening a repo configured to use the watchman fsmonitor, and watching the Git output tab.

@isidorn @eamodio could someone take a look at this?

Linked issue has been closed, but the perf issue with watchman (git status check look due to watchman cookies triggering watcher) remains. Would be worth creating a new ticket for this, if there isn't one already.


Sharing ViewComponents Between ASP.NET 5 Projects

I am attempting to model our current Web Forms Applications as ASP.NET 5 Visual Studio 2015 single Solutions/Projects - I want each application to be in a single ASP.NET 5 VS Solution/Project.  As part of this effort, I believe that I need to share a number of MVC6 View Components with each of the individual projects.  These will be used to construct common layouts.cshtml files and other shareable components.  (1) I have looked into "Shared Projects" and I cannot seem to access their content from ASP.NET 5 projects. (2) I have looked into the project.json "content/contentFiles" properties, and I cannot  get them to work.  (3) ASP.NET 5 projects do not have build events that I could use to copy content files.  So, basically, I am at a loss as to how to proceed with share content between ASP.NET 5 projects.  Please either directory me to a better place for this question or help be move forward.  Part of what I am trying to do is convert a large number of Web Form User Controls to layout.cshtml files and share them.
Thanks.

You can use a global.json file (all ASP.NET 5 projects/solutions have one by default) to share projects among multiple solutions. You can find more info here: http://docs.asp.net/en/latest/conceptual-overview/understanding-aspnet5-apps.html?highlight=global json#the-global-json-file
What you'll end up with is a file layout kind of like this:

/projects/sharedsolution/sharedproject/global.json
/projects/sharedsolution/sharedproject/project.json
/projects/solution1/global.json
/projects/solution1/project1/project.json
/projects/solution2/global.json
/projects/solution2/project2/project.json

And in the global.json files in solution1 and solution2 you'd set the projects node to point to something like "projects": [ "src", "test", "../sharedsolution" ]
This allows all the solutions to also references the projects in the shared solution (or each other, or whatever).

Thanks very much for a prompt answer.  I had hoped there was an easier way of sharing that I was finding.  I will test it out and submit another issues if I have any.  Just great!

After reviewing your response and my code, I realized that Visual Studio 2015 was already updating the global.json file when I added a shared project to another solution and referenced it.  Where I think I am having my real problem is trying to access View Components (.cshtml files) that are in the shared project from another main project.  I have tried extending the IViewLocationExpander interface to point to a directory in the shared project, but it looks like only directories inside the main project can be access by the extended class.  I have even tried added a full path to a View Component and the extending class could not find it.   Any idea how I can access View Components from a shared project?  This is what I think the mvc6 Shared Project functionality is suppose to provide, but it does not seem to work yet with ASP.NET 5 projects.
Thanks again.

@rynowak
There isn't a good way to do this right now. Your ViewComponent class can live in a separate project (just like Controllers can) but the views need to live in your current project.
Adding to backlog.

Thanks for your answer.  I will just have to wait.

@TLHamilton we'd like to keep this bug open so we can continue to track the scenario. Thanks!

With respect to creating sharable View Components that are self contained and encapsulate their own

You can keep your View Components and their views in the same assembly as resources and consume them from a website project using EmbededFileProvider. Please look into FileSystem repo for an example of EmbededFileProvider.

Fyi. I have taken the CompositeFileProvider and include two PhyiscalFileProviders in it, one for the main project and one for the shared project.  In this way the main projects views are located first and the shared views are found second. Everything is now working just fine with this approach.
Thanks.

Hi, so what is the suggested implemetation for this?
Thank you

@joaquin-corchero, if I understand this correctly, this bits were implemented for RC2 (not yet released). You will (eventually) be able to share view components between projects, but you will need to configure your file provider accordingly. In order to do that with the latest bits form myget, you can follow this blog post.

@Eilon,
would you care to comment on the state of this functionality? You mentioned you'd like to keep this open to track the scenario. Is there something we can expect for RC2/RTM? I've also talked about this scenario in Nuget issue 2262.

@rynowak has been working on some issues relating this scenario. @rynowak ?

@skyflyer - this is already possible in RC1 using the embedded files provider. https://github.com/aspnet/Mvc/tree/6.0.0-rc1/test/WebSites/RazorEmbeddedViewsWebSite
RC2 makes it a little easier. https://github.com/aspnet/Mvc/tree/dev/samples/EmbeddedViewSample.Web
We have some work in the pipe to make it more first class and potentially even automatic https://github.com/aspnet/Mvc/issues/4089 - assuming that this is all your code and you have a build-time reference to your shared project, it's fairly straightforward.
There are lots of challenges related to redistributable 3rd party components that we won't fully solve.

@rynowak,
thanks for the pointers. I'm aware of embedded file providers solution (I've pasted a link above a blog post outlining the steps) and I will give a look at RC2 solution tomorrow. Somehow, I was under the impression it is a temporary hack (I guess I was wrong). The #4089 looks interesting, albeit a bit over-engineered.
I'm working in an enterprise environment and am seeking a "future-proof" and MS endorsed solution to presented challenges, so that MS enterprise customers have a clear path forward, given that it is RC time already. If Microsoft.Extensions.FileProviders.Embedded is the official way to go (as an additional provider, of course), that's fine. Is it? Or are you planning on implementing 4089 for the RTM?
Just my $0.02 regarding this (and mostly 4089, but keeping this comment here, anyway) and I guess you're all aware of this already: Django's apps (and middleware) (as well as Ruby on Rails' gems) solve those issues in a very nice way. For instance, each "app" that gets registered, participates in finding the "templates" and acts as a part of the whole. Of course, there aren't just templates, but views (think controllers), tags (think view components) and other parts (template filters anyone?) that make up the ecosystem. The system is simple and works well and for different scenarios (how will the static files be solved with "embedded file provider" for instance?). This is something which could (perhaps?) be addressed with the proper structure of the nuget package and consumption of that package in a target project (either by leaving the files where they are, or by using something like Django's manage.py collectstatic).
A not too far-fetched scenario would be, for instance, providing a simple "blog app", consisting of: some models, controller, a couple of tag helpers and view components (think: latest blog posts, blog links...), a couple of razor templates and some styling assets (images, CSS file, ...). Embedded file provider solves the razor templates, while compiled assembly solves the controllers and tag helpers, which leaves static content assets in the cold (and I don't think creating two packages (NuGet & Bower) for one "add-on" is a good idea).
I hope I haven't been too broad with this discussion in this particular issue. If I have, I apologize.

@skyflyer - You're not being too broad, this is in line with our thinking.

@rynowak, excellent (and exciting) news! Would you mind commenting my two questions above? (4089 wrt/ RTM and embedded providers being a way forward for the forseeable future)?

@rynowak waiting to hear an answer for @skyflyer 's questions...

@skyflyer @Coolwayfarer - Sorry, I missed that you had asked another question!
We did #4089 for RC2 actually. There's a new application parts API that lets you add/configure assemblies that together represent your application. We've updated the controller / taghelper and view component discovery systems to use application parts, instead of some hidden other service.
The idea is that in the general case where you have a build-time reference to everything you want to include then it 'just works'. Is you want to exclude a project/assembly but still build against it that's possible now with 1-2 lines of startup code. If you want to include a project/assembly that you didn't reference at build time that's also 1-2 lines of startup code.
===============
Regarding Razor and views, the embedded file provider strategy is what we'd recommend right now. I only say right now, because if we find a way to make it work without embedding the files in the future that might be better. Regardless the embedded file approach is a safe bet.
Now what we haven't done here, we haven't done autodiscovery of Razor views via embedded providers, and we have some work to do around making this 'just work' with the references provided to your views at compilation time. For RC2 configuring the file providers and compilation references remains manual.
====================
/cc @javiercn - we need an announcement post for application parts.

we haven't done autodiscovery of Razor views via embedded providers, and we have some work to do around making this 'just work' with the references provided to your views at compilation time

https://github.com/aspnet/Mvc/issues/5144

We are also looking at precompilation of views in libraries: https://github.com/aspnet/Mvc/issues/3917

Closing since all outstanding items are tracked by other issues.

Sounds good for the future.  For now I am using a combination of gulp to copy views into target project's View folder at build time and access them with PhysicalFileProvider at run time.  I can send details if interested.


Yum Repo Add Task's proxy settings are wrong

Describe the issue
The Yum Repo addition task in roles/common/tasks/redhat.yml uses proxy.http_proxy rather than proxy.https_proxy. Ideally this should probably use a fall back chain from https->http->none. In order to allow support when the https proxy is different than the http proxy in envs.
Important to note, the confluent yum repos are TLS/SSL address, so a proxy supporting that type of traffic is needed.
To Reproduce
Steps to reproduce the behaviour:

Have 2 separate proxies configured in ansible for http_proxy and https_proxy
Ensure the http_proxy doesn't support TLS traffic.
Attempt to run play for kafka_broker install
Note yum clean all and other yum commands will fail due to the unsupported traffic type.

@nerdynick The fix has been merged. You can verify this on Recent patches.


updated supported python version range

Summary

changed minimum supported python version to 3.8
changed maximum supported python version to 3.11

How to test

Checklist

[ ] I have added unit tests to cover my changes.
[ ] I have added integration tests to cover my changes.
[ ] I have added the description of my changes into CHANGELOG.
[ ] I have updated the documentation accordingly

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[ ] I have updated the license header for each file (see an example below).

# Copyright (C) 2023 Intel Corporation
#
# SPDX-License-Identifier: MIT

updated


Unable to resolve .Release in ingress file

Output of helm version:
Client: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-07T09:55:27Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:25:46Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.): Docker-for-mac
Hi,
Tiller is not able to parse Release scope in ingress file. However, it is able to find it in all other kind of files.
Here's the file
{{- if .Values.ingress.enabled -}}
{{- $fullName := include "backend.fullname" . -}}
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ $fullName }}
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
    {{- range .Values.ingress.hosts }}
    - host: {{ .host | quote }}
      http:
        paths:
          - backend:
              serviceName: {{ $fullName }}
              servicePort: 8090
            path: "/{{ .Release.Namespace }}(/|$)(.*)"
    {{- end }}
{{- end }}

Inside the range, the . refers to every element in the array .Values.ingress.hosts, and looks like the array contains strings which are hostnames, so when you say .Release.Namespace it won't work, instead you can do this which I have seen my team mates do
{{- if .Values.ingress.enabled -}}
{{- $fullName := include "backend.fullname" . -}}
{{- $release := .Release }}
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ $fullName }}
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
    {{- range .Values.ingress.hosts }}
    - host: {{ .host | quote }}
      http:
        paths:
          - backend:
              serviceName: {{ $fullName }}
              servicePort: 8090
            path: "/{{ $release.Namespace }}(/|$)(.*)"
    {{- end }}
{{- end }}

and it will work

Worked like magic. Thanks a lot!!


Fix naming to match future direction with starting with k8s

What type of PR is this?

Uncomment only one  /kind line, and delete the rest.
For example, > /kind bug would simply become: /kind bug

/kind api-change
/kind bug
/kind cleanup
/kind deprecation
/kind design
/kind failing-test
/kind feature
/kind flake
/kind code-refactoring
Documentation changes: Please include [skip ci] in your commit message as well
/kind documentation
[skip ci]

What does does this PR do / why we need it:
Which issue(s) this PR fixes:
Fixes #?
How to test changes / Special notes to the reviewer:

@sspeiche 4 more places to change this -

https://github.com/openshift/odo/blob/493196b496d046179c92065b47606130420af435/cmd/cli-doc/cli-doc.go#L84
https://github.com/openshift/odo/blob/0a68b6a8404e712d22b9542a689d38909d59cb05/pkg/odo/cli/cli.go#L37
https://github.com/openshift/odo/blob/0a68b6a8404e712d22b9542a689d38909d59cb05/pkg/odo/cli/cli.go#L134
https://github.com/openshift/odo/blob/de26405161722b6ae735051c5963e97e2d1adbab/rpms/openshift-odo.spec#L29

And just in case (from an old docs script) -
https://github.com/openshift/odo/blob/6bd0d73dc67e014e34f7e92a35dab26734163afc/scripts/sync-docs.sh#L120

@sspeiche 4 more places to change this -

let's do this in separate PRs
/approve
/lgtm


[0.16]: Merge Preview Handlers in Master

Summary of the Pull Request
Merging Preview Handler for Svg and Markdown in master.
Merging the changes from dev/previewPane into master. Created another branch on my fork with rebasing the commits from dev/previewPane on master as the direct PR from dev/previewPane showing duplicate commits.

PR Checklist

[x] Applies to #914  and #963
[x] CLA signed. If not, go over here and sign the CLA
[x] Tests added/passed

Validation Steps Performed

[x] Validated the preview handlers from the rebased branch. This is required before completing the PR.

Re  add: src/runner/runner.rc
remove .snk files for Preview Handlers Assembly. As the dll's are not being added in GAC.  And assemblies are signed in CI as well.

@crutkas  and  @enricogior This is for moving Preview Handlers to master. Please add whoever you think should take a look at this. I have to update bunch of stuff that i mentioned above and the settings ui related stuff as well(.html files, .js files) will do it in morning with @laviusmotileng-ms

I tried to add @yuyoyuppe as a reviewer but github has something wrong today.
@udit3333 there is something wrong with the history, since it shows the commits form master as been committed by you.
You should try creating a new branch from the current master and cherry-pick your commits from your preview handlers working branch.

All same .net framework version please.

The FancyZones editor uses .Net 4.7.2

We should sync to that. Pretty sure everything recent on boarded was 4.7.2

Do we require .NET 4.8 or is it possible to use the same .NET version as FZ Editor?

Updated .Net Framework to 4.7.2 same as FZ Editor

I tried to add @yuyoyuppe as a reviewer but github has some problems today.
@udit3333 there is something wrong with the history, since it shows the commits from master as been committed by you.
You should try creating a new branch from the current master and cherry-pick your commits from your preview handlers working branch.

Hey Enricho fix the commits history for this branch. No more master commits

Re add: src/runner/runner.rc
remove .snk files for Preview Handlers Assembly. As the dll's are not being added in GAC. And assemblies are signed in CI as well.

Resolved.

I've left some initial comments/questions, but I couldn't compile the solution to test it due to many errors in settings_objects.h file etc. The branch probably needs some cherry-picking like @enricogior mentioned.
Also, while opening the solution I've got this dialog:

Do we require .NET 4.8 or is it possible to use the same .NET version as FZ Editor?

@yuyoyuppe  I have updated the Commit history and also the .net version. You can now build the solution to test the Preview Handlers.

 All the unit tests are working fine for me in both configuration. Maybe try clean and rebuild the solution.

@udit3333 thanks, looks like only rebooting has helped in my case. 🙂

@udit3333 thanks, looks like only rebooting has helped in my case. 🙂
@udit3333 :  Any idea why a reboot would be necessary?  I'd be curious how this behaves in a CI environment.  This might be motivation to run the unit tests in the ci pipeline @enricogior thoughts?

@ryanbodrug-microsoft I don't think a reboot is necessary. I didn't face any problem in running the tests on my machine. Visual Studio many times acts strange in building the project and running tests. Most of the time restarting the VS resolves the issue or clean rebuild. That's why I suggested to try that.

@ryanbodrug-microsoft

This might be motivation to run the unit tests in the ci pipeline @enricogior thoughts?

Actually we had it ready for some time, and I was planning to enable it this week, I'll try to do it tomorrow.


Added KCSIT consultant

Thanks @vitorlans!

Hey @vitorlans,
Do you know whether this company is or not using Nodejs?

https://github.com/ftonato/nodejs-in-portugal


[build] Missing linux arm precompiled libspirv-reflected

Quoting from commit df2099076b71dd3e5bebc8784eaeb4a2b5a5ef9f:

Remove SPIRV-Reflect submodule and include precompiled binaries

That commit added the following precompiled binaries:
./android/lib/arm64-v8a/libspirv-reflect-static.a
./android/lib/x86/libspirv-reflect-static.a
./android/lib/armeabi-v7a/libspirv-reflect-static.a
./android/lib/x86_64/libspirv-reflect-static.a
./linux/lib/x86/libspirv-reflect-static.a
./linux/lib/x86_64/libspirv-reflect-static.a

So for linux it only added x86 and x86_64. It is missing arm binaries (like aarch64) for linux. Without that, devices like the Raspberry Pi 5, that usually is used with the Raspberry Pi OS (based on Debian), fails with the following error:
[ 87%] Built target gfxrecon_application
/usr/bin/ld: skipping incompatible /home/pi/mesa/source/gfxreconstruct/external/precompiled/linux/lib/x86_64/libspirv-reflect-static.a when searching for -lspirv-reflect-static
/usr/bin/ld: cannot find -lspirv-reflect-static: No such file or directory

heej @infapi00,
we merged a change that replaces precompiled spirv-reflect with a submodule
and I confirmed compilation on pi5 works again.
thanks for reporting!


[HW]

Name: Gagan Suri
Email: Gagan Suri
Linkedin Profile: https://www.linkedin.com/in/gagansuri
Attach the homework step I screenshots below:

Attach the homework step II screenshots below:

what is the second screenshot?

what is the second screenshot?

From this exercise: https://www.datastax.com/dev/spring

Yes, the second screenshot is from the completed screen of the exercise link you posted.

Also, once you complete the scenario (shouldn't take too long) please update your email so we can get you a badge.


Implemented stack and queue in C#

What I don't like about this PR is that the dequeue operation doesn't return the dequeued object. Now that said neither does the cpp version. I would personally prefer what rust, java and ts do currently, because in most use cases you want to dequeue on object and then still work with it.


run_openr.sh uses unknown command line flags

Issue Description
When launching OpenR using run_openr.sh an error message is displayed and execution is stopped.
Environment

tag or commit hash on which this occured
master

OS version: <e.g. ubuntu-16.04>
ubuntu-16.04

Minimal test code / Steps to reproduce the issue
execute run_openr.sh
What's the actual result?
root@13e42c1e5c91:/install# run_openr.sh
Using OpenR config parameters from /etc/sysconfig/openr
openr[11]: Starting OpenR daemon.
openr[11]: Starting OpenR daemon.

Starting the openr process without errors.
.

I am unable to reproduce this. can you try building from latest and try running again? Also, are you using the docker build process or build/build_openr.sh?