ERR_STREAM_WRITE_AFTER_END on subscription creation (/listen)

Sorry - still hitting an issue, and the subscription does not actually get created.
I see it posting back now (in ngrok)
POST /listen?validationToken=Validation%3a+Testing+client+application+reachability+for+subscription+Request-Id%3a+70d77e72-0725-bd6c-2ec5-e8a03f84257a HTTP/1.1
Host: localhost:3000
Content-Length: 0
Accept-Encoding: gzip
Content-Type: text/plain; charset=utf-8
X-Forwarded-For: <IP_ADDRESS>
X-Forwarded-Proto: https
X-Original-Host: 6666d37d425c.ngrok.io
but then NPM dies
Express server listening on port 3000
GET / 304 3.022 ms - -
POST /listen?validationToken=Validation%3a+Testing+client+application+reachability+for+subscription+Request-Id%3a+38ef101b-fa0f-ca42-b0d8-498fdee9aa15 200 9.538 ms - 117
events.js:292
throw er; // Unhandled 'error' event
^
Error [ERR_STREAM_WRITE_AFTER_END]: write after end
at writeAfterEnd (_http_outgoing.js:668:15)
at ServerResponse.end (_http_outgoing.js:788:7)
at _callee$ (C:\temp\dotnet\webhook\routes/listen.js:83:22)
at tryCatch (C:\temp\dotnet\webhook\node_modules@azure\msal-node\node_modules\regenerator-runtime\runtime.js:63:40)
at Generator.invoke [as _invoke] (C:\temp\dotnet\webhook\node_modules@azure\msal-node\node_modules\regenerator-runtime\runtime.js:293:22)
at Generator.next (C:\temp\dotnet\webhook\node_modules@azure\msal-node\node_modules\regenerator-runtime\runtime.js:118:21)
at asyncGeneratorStep (C:\temp\dotnet\webhook\routes\listen.js:28:103)
at _next (C:\temp\dotnet\webhook\routes\listen.js:30:194)
at C:\temp\dotnet\webhook\routes\listen.js:30:364
at new Promise ()
Emitted 'error' event on ServerResponse instance at:
at writeAfterEndNT (_http_outgoing.js:727:7)
at processTicksAndRejections (internal/process/task_queues.js:81:21) {
code: 'ERR_STREAM_WRITE_AFTER_END'
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: mocha ./tests/confTest.js && babel-node --config-file ./babel.config.json ./index
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR!      C:\Users\jrosen\AppData\Roaming\npm-cache_logs\2020-12-09T16_37_32_060Z-debug.log

This stack trace indicates an error with msal node (the authentication library). I would encourage you to double check your application registration and your settings (in the constants). If you still run into the issue, you might want to cross-pross in their repo instead https://github.com/AzureAD/microsoft-authentication-library-for-js

Closing due to inactivity.

@baywet it's caused by this line:
https://github.com/microsoftgraph/nodejs-webhooks-rest-sample/blob/main/routes/listen.js#L83
changing it to just res.status(status); fixed this exact issue for me.

@philjones88
thanks for sharing this information. I recently ran into a similar issue and just authored a pull request to fix that. see #233
Not calling the end method leaves the http stream open, which makes the notification service wait, time out and eventually retry. You don't want that in production.
Calling it with an http status code however, forcibly closes the stream, which makes any interception which hasn't completed (azure-identity) throw.
Calling end without a status code, closes the stream when the interceptors are completed, which solves both issues.


New Data Source from ADS - Network Share

New network share data source.

same point on discussion of feasibility of enum (vice command), but looks good 👍


Introducing Else if Statements has inconsistent spacing

In all the other exercises I've seen, there's a space between the 'if' and the opening '(', but not in the starting code for this one:
My code:
function myTest(val) {
  if(val > 10) {
    return "Greater than 10";
  }

  if(val < 5) {
    return "Smaller than 5";
  }

  return "Between 5 and 10";
}

// Change this value to test
myTest(7);

Are you asking for help @kkrugler? Or is the Waypoint formatting different to other Waypoints?


Latest version updated ??

Hi,
I had installed supertest 1.0.1 (released May 2015). However, I see in the repo that the dependencies have been updated, which is what I am interested in (express 4). I wonder if a version update has been forgotten or they are just release candidate changes?

Hello, I was working a little while back on the next release of supertest but got a little sidetracked. I am planning to get jump back in the next couple of days and get the next release out. It will bump the version to a 1.1.0 based on a few PRs that are ready to be merged in.


Seemingly random failure on CI for macOS debug

We have a seemingly random failure in CI happening on macOS in debug mode. I think here is the first occurrence: https://github.com/hylo-lang/hylo/actions/runs/6909351716/job/18800508667
I merged this PR because re-running the CI job passed. So I think I had just observed a cosmic bug like the ones that sometimes happen on Windows. But since then we've been observing more consistent failures, always on macOS in debug mode:

https://github.com/hylo-lang/hylo/actions/runs/6936813952/job/18869693667
https://github.com/hylo-lang/hylo/actions/runs/6954943177/job/18979251777
https://github.com/hylo-lang/hylo/actions/runs/6967854155/job/18960557859
https://github.com/hylo-lang/hylo/actions/runs/6971167030/job/18970599927
https://github.com/hylo-lang/hylo/actions/runs/6973308191/job/18978898066

@lucteo recently surfaced what's likely a data race (see https://github.com/hylo-lang/hylo/actions/runs/6973902095/job/18978712899) and I wonder if we're not observing the same problem, just at a smaller scale. To confirm I have disabled parallel type checking on a PR and tests passed on the first run (see https://github.com/hylo-lang/hylo/actions/runs/6977697662).
We should investigate this issue more thoroughly.

Further evidence of a data race: https://github.com/hylo-lang/hylo/pull/1161/commits/ece4a3bc247dab0edcaf65fb18946c925265aab7
Rather than completely disabling parallel type checking, this patch only disables updates of the shared cache while the concurrent type checkers are running.

Do we think this is a bug in Dispatch?  Surely it can't be in my code! ;-)

I guess another possibility is that it's not a data race but a logical one because different computations of the "same" value in the cache are producing different results. Do we have an assertion checking for that?

We discussed it with @lucteo yesterday and concluded that we needed your lights. The source of the problem might be here: https://github.com/hylo-lang/hylo/blob/8bf17efac9a11722b29899726b9f4c0b42b95861/Sources/Utils/SharedMutable.swift#L20-L32
@lucteo suspects that it is possible to get the shared value using the subscript and then cause a race when modify(applying:) is called. I'm skeptical because I think Swift should guarantee exclusive access to the CoW data structures that we got from the get subscript but maybe I'm overly confident in the safety guarantee we get in a concurrent context.

I guess another possibility is that it's not a data race but a logical one because different computations of the "same" value in the cache are producing different results. Do we have an assertion checking for that?

Yes, we have assertions for every update. That is the point of my Monotonic protocol. I would be surprised if the bug was due to an inconsistent update, but we never now. I'll double-check.

suspects that it is possible to get the shared value using the subscript and then cause a race when modify(applying:) is called.

Any mutable state shared across threads is subject to logical races if used incorrectly, but there's clearly no data race in this code.  mutex is a dispatch queue and every access to the state is synchronized.  Getting the value with with the subscript copies the value.  You might look for uses of the subscript for read-modify-write (perhaps just remove the setter) and make sure those uses use modify.  Any writes during the "modify" part of a r-m-w using the subscript will be discarded.  It's also going to be very inefficient if the shared value is a large CoW structure.  In fact that's likely enough that perhaps I have created an efficiency pitfall by allowing any access at all via subscript.  The user should be encouraged to do all reads of the stored value entirely inside a call just like modify (except without mutation).  But even if you fell into that efficiency trap, if your code is truly monotonic it should never have racy semantics.

Note that if we get rid of the subscript and never let the shared value escape from a modify (or corresponding read) accessor it would also eliminate any possibility of a data race due to a buggy CoW implementation.  I don't believe such a bug exists, but as you're ruling out causes it might be helpful to know that.

Any mutable state shared across threads is subject to logical races if used incorrectly

Am I correct to assume that even if we had a logical race, it could not possibly create undefined behavior?
That's what I think we've observed here. We have bus errors coming out of different places every time we run the compiler and it seems like the call stack gets corrupted.

Note that if we get rid of the subscript and never let the shared value escape from a modify (or corresponding read) accessor it would also eliminate any possibility of a data race due to a buggy CoW implementation. I don't believe such a bug exists, but as you're ruling out causes it might be helpful to know that.

Completely encapsulating read access to the contents of the shared value seems difficult to implement just to test an unlikely bug. The type checkers need to copy parts out a modify (or corresponding read) and use these values to run their logic.
For information, our code has roughly this pattern:
struct Cache {
  var local: TypedProgram
  var shared: SharedMutable<TypedProgram>?
}

struct TypeChecker {

  var cache: Cache

  // ...

  mutating func someProperty(d: AnyDeclID) -> T {
    if let t = local.someMap[d] {
      return t
    } else if let t = shared?[].someMap[d] {
      local.someMap[d] = t
      return t
    }

    let t = computeSomeProperty(d)

    local.someMap[d] = t
    shared?.modify { (p) in
      p.someMap[d].updateMonotonically(t)
    }
    return t
  }

}

We're actually batching write backs to the shared program instance, but that doesn't change the general pattern. At each call to someProperty(_:) we have to assume that we can get into a critical section once to read someMap and a second time to update it. No update occurs outside of these critical sections. updateMonotonically traps if the update is not monotonic, ruling out logical races (but those should not be able to trigger UB anyway, I think).
We have to make the value we read from shared escape at the top of the function so that we can copy it to local and we can't encapsulate computeSomeProperty in a read method because it may try to re-enter a critical section. T can be any type, including a CoW type.
Note that we're never using the set variant of the subscript.

The fact that the problem only occurs on macOS in debug mode is suspicious, to the point I'm even starting to think that there might be a bug in Dispatch 😅.
I have disabled parallel type checking only on macOS-debug so that we can have a functioning CI and see whether the bug eventually impacts other configurations as we move forward (see https://github.com/hylo-lang/hylo/pull/1161).

This is entirely explained by the presence of ___chkstk_darwin at the top of the stack trace: the type checker is blowing the stack, and the stacks allotted to dispatch queues are smaller than the main thread gets.

The problem could be addressed by breaking type checking up into smaller tasks with their dependencies recorded, for which OperationQueue is well-suited, or by using async/await everywhere, or by using continuation-passing style, any of which could turn out to be a performance improvement as well.
(As long as you're not taking advantage of OperationQueue's special capabilities, probably something like this would be more efficient… but by itself I doubt it solves the blowing-the-stack problem)

Great work! And those are very interesting leads for improvements.
Refactoring the type checker is no small work. That is certainly the most sophisticated part of the compiler at the moment. While the big picture is pretty easy to understand, the implementation details are a true nightmare to get right. We'll need to think about the design of the while thing very carefully.


Make --auto-gen-config faster if Metrics/LineLength is disabled

When using the --auto-gen-config flag, RuboCop runs through all files twice:
» rubocop --auto-gen-config
Phase 1 of 2: run Metrics/LineLength cop
Created .rubocop_todo.yml.
Phase 2 of 2: run all cops
Created .rubocop_todo.yml.

In .rubocop.yml, I have the Metrics/LineLength cop disabled, so couldn’t that first step be skipped?

Related to #5228 / #5246 /cc @jonas054


Roadmap/Potential Additions

Allow for html as an input - recipe-scrapers scrape_html
Return dictionary or set of compatible sites - {‘allrecipes’: ‘www.allrecipes.com’}

It might be nice to know what sites are covered without having to check the README

Proxy and header arguments
Consider if there a way around hardcoded unwanted_patterns

These are some short term plans for moving forward, but I'm very open to ideas/suggestions! @jknndy

[ ] Consider switching to requests for site retrieval
[ ] Expand testing base, related to adding html as an input.


Add class dcat:DatasetSeries

Problem statement
Following DCAT 3. DCAT-AP 3 introduces a new class dcat:DatasetSeries.
This class corresponds to the ISO 19115 / INSPIRE notion of "data set series":
https://inspire.ec.europa.eu/glossary/DataSetSeries
Until GeoDCAT-AP 2, dataset series were typed (rdf:type) as dcat:Dataset's.
For more details, see the GeoDCAT-AP 2 specification (in particular, §B.6.3).
Proposal
To be aligned with DCAT-AP 3 and DCAT 3, GeoDCAT-AP 3 should deprecate the use of class dcat:Dataset for dataset series, and replace it with class dcat:DatasetSeries.

dcat:DatasetSeries will be included as part of DCAT-AP 3.0.0 alignment.


chore(backend): Organization takes precedence over personal account in organization sync options

What changed?
This change makes organization URL patterns take precedence over personal account patterns in the new OrganizationSync handshake options.
Why now?
Initially, we didn't have a strong argument for which option should have precedence. Now, a use-case has become clear! If a fixed prefix is going to be present in a URL, we think it's more likely that it will be in org-indicating URLs and not personal-account-indicating URLs.
E.g. the following pattern:
/orgs/myorg/settings <- Fixed prefix "orgs" implies "mygreatorg" is active
/settings <- Absence of prefix implies that the personal account is active
Will occur more often than:
/me/settings <- Fixed prefix "me" indicates that the personal account is active
/mygreatorg/settings <- Absence of fixed prefix implies an organization is active
This is relevant because it's easiest to have the activatible entity type (org or personal account) with a fixed prefix take presedence, so that the other can wildcard match all routes.
For example, for an app using the first pattern, they could use the following middleware options:
{
  personalAccountPatterns: [
    '/',
    '/(.*)'
  ],
  organizationPatterns: [
    '/orgs/:slug',
    '/orgs/:slug/(.*)'
  ]
}

E.g. letting the personal account match everything that does not have the org prefix.
Is this a breaking change?
Technically yes, but this feature was introduced early this week, and has not yet been documented or formally announced, so I don't expect it to be in use yet, much less for anyone to be depending on this nuance yet.

Checklist

[x] npm test runs as expected.
[x] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

@izaaklauer I think this is more like a bug fix than an chore, cause if there was a case like the following:
{
  personalAccountPatterns: [
    '/',
    '/(.*)'
  ],
  organizationPatterns: [
    '/orgs/:slug',
    '/orgs/:slug/(.*)'
  ]
}

then it wouldn't apply the organization patterns even if the route was matching correctly.

@izaaklauer I think this is more like a bug fix than an chore, cause if there was a case like the following:
{
  personalAccountPatterns: [
    '/',
    '/(.*)'
  ],
  organizationPatterns: [
    '/orgs/:slug',
    '/orgs/:slug/(.*)'
  ]
}

then it wouldn't apply the organization patterns even if the route was matching correctly.

You're right that those settings today will always activate the personal workspace, but today's jsdoc comments also specify that the personal workspace takes prescience! This change only switches which pattern matcher is applied first. It used to be personal workspace, but now it's organization, because organization is more likely to be prefixed.


[WIP] Port to cabal-helper-1.0 (git)

I'm working on fleshing out the cabal-helper-1.0 API, figured I should see how bad I broke things using the old API so I decided to give porting this project a go. I had to tweak a few things but not too bad overall.
I also fixed compileVersion being too slow (see the discussion here). It only depends on the setup-config header for V1 projects now.

Thank you Daniel!
It would be great to use the new version of cabal-helper.
I guess I should think about how to index multiple packages at once:
https://github.com/alexwl/haskell-code-explorer/blob/63ad1f682e64cb6b854e399ed12af3a9986241f8/src/HaskellCodeExplorer/PackageInfo.hs#L162-L164
Also, thank you for the fixed compilerVersion query.

Yeah, indexing multiple packages would also make things easier for users because you can just let the indexer loose on a whole cabal/stack project rather than just one package :)


Initial implementation of the frizbee action

Initial implementation of the Frizbee Action.
Details:

Supports GitHub Actions, Dockerfiles and all yaml/yml files containing known container image references, i.e. docker-compose files, Kubernetes files, etc.
Supports opening PRs suggesting repository owners to pin their actions or container images

Todo:

[ ] The default GITHUB_TOKEN granted from the action run does not have the workflows permissions which limits the action to open PRs against the workflow files. To resolve this, the user would have to create a new token with the correct permissions and assign it to the action.
[x] Support re-running the action if there's previous PR created
[ ] Test it from another repo when it's published -<EMAIL_ADDRESS>[ ] There's a test.yml workflow and a tests folder with a bunch of example files. Let me know if you want these deleted now or we can keep them until we are okay with the functionality of the initial version.
[ ] Add support for checking the content of the PR instead of the whole repository

Fixes: https://github.com/stacklok/frizbee/issues/149

The Trivy scan failure is because of an indirect dependency.

if the dep can't be updated, then we need to add a trivy ignore (let me know if you want me to do that)

Let's merge this so we can get it rolling and I'll file separate issues for the comments @lukehinds and @jhrozek made so we keep and address their feedback 👍 Thank you both!


Why does dada2 re-run even when it doesn't have to?

If I run the pipeline with the nextflow -resume flag, it shouldn't rerun steps unless necessary.  It always reruns the dada2 part (process run_dada_on_trimmed) even if it shouldn't need to.  Can I avoid this?

Addressing this could be done in conjunction with converting the pipeline to an nf-core/ampliseq style DSL2 solution.  See these workflows:
https://github.com/nf-core/ampliseq/blob/master/subworkflows/local/dada2_preprocessing.nf
https://github.com/nf-core/ampliseq/blob/master/workflows/ampliseq.nf

In the meantime, this seems to be the issue, in run_dada_on_trimmed.R
# This will place dada-filtered files in dada_filtered/ subdirectory
filtFs <- file.path(trimmed_path, "dada_filtered", paste0(sample.names, "_F_filt.fastq.gz"))
filtRs <- file.path(trimmed_path, "dada_filtered", paste0(sample.names, "_R_filt.fastq.gz"))

The fastq files containing dada filtered reads get put in a sub-directory of the original directory containing the primer-trimmed fastq.  This original directory of trimmed reads is an input to run_dada_on_trimmed, so running this process changes one of its own inputs, making it so that it always has to re-run.
Change to putting the dada2 filtered files in their own directory in the pwd (so will be in work directory).  If want to output these, can use publishDir to link to them.

Will close when next merge dev into main


NW5_Manchester_M.Barry_Full-Stack-Project-Assessment

Maybe you could add a .gitignore files to remove node_modules from changes


Testing Matrix (node and EventStore)

Hi All,
Right now, the test are running the latest node version is 0.10.x and EventStore v3.0.5. We have to expand out our test coverage, but I am not sure how to prioritize. What versions of node and/or EventStore are people targeting?
B

3.2.0 is about to be released. Don't worry it doesn't break anything just
adds competing consumers..
On Sat, Sep 5, 2015 at 12:09 AM, Brian Mavity<EMAIL_ADDRESS>wrote:

Hi All,
Right now, the test are running the latest node version is 0.10.x and
EventStore v3.0.5. We have to expand out our test coverage, but I am not
sure how to prioritize. What versions of node and/or EventStore are people
targeting?
B
—
Reply to this email directly or view it on GitHub
https://github.com/bmavity/ges-client/issues/48.

--
Studying for the Turing test

Testing different event store versions is not that big of a deal, it's just that the test helper right now is looking for clusternode and I think that got moved with v3.1.0. Have to make another update to it.

Only in the apt-get/etc packages. In .tar.gz its still there
On Sat, Sep 5, 2015 at 12:25 AM, Brian Mavity<EMAIL_ADDRESS>wrote:

Testing different event store versions is not that big of a deal, it's
just that the test helper right now is looking for clusternode and I think
that got moved with v3.1.0. Have to make another update to it.
—
Reply to this email directly or view it on GitHub
https://github.com/bmavity/ges-client/issues/48#issuecomment-137870895.

--
Studying for the Turing test

I hadn't explored it, but it looks like it's now called eventstored? Either way, my travis build that works for 3.0.0-3.0.5 will not work for 3.1.0, so I will need to figure out what the problem is. :)

in ubuntu packages yes. try .tar.gz
On Sat, Sep 5, 2015 at 12:41 AM, Brian Mavity<EMAIL_ADDRESS>wrote:

I hadn't explored it, but it looks like it's now called eventstored?
Either way, my travis build that works for 3.0.0-3.0.5 will not work for
3.1.0, so I will need to figure out what the problem is. :)
—
Reply to this email directly or view it on GitHub
https://github.com/bmavity/ges-client/issues/48#issuecomment-137872934.

--
Studying for the Turing test


simple svg file improperly rendered

Godot version
4.1
System information
linux
Issue description
Godot doesn't render this file correctly.
<?xml version="1.0"?>
<svg width="110" height="110">
	<path fill-rule="evenodd" fill="#ffffffff" d="M 0 0 L 0 110 110 110 110 0 z M 50 50 L 60 50 60 60 50 60 z " />
	<path fill="none" stroke="#000000ff" stroke-width="8" d="M 46 46 L 60 46 60 60 46 60 z " />
</svg>

drawn by editsvgcode.com, vectr.com, gimp, my image viewer, etc.
imported in godot

It's a bit strange because krita doesn't import it properly either, but in a way different than godot :thinking: although that's of course totally unrelated.
Steps to reproduce

import the provided file in godot
notice how it differs from what  editsvgcode.com (or your image viewer) draws.

Minimal reproduction project
Paste above content in an svg, or download it:

It doesn't open correctly in my browser, so I think this file is broken and it's not an issue with the engine, possibly the engine not being lenient and accepting it


Constant buffer offset support on DX11.1 Windows 7

Constant buffer offsets seems pretty essential to have, and is available first in 11.1 through PSSetConstantBuffers1. Windows 7 SP1 introduces DX 11.1 but emphasizes that most features are unavailable since they require the newer driver model (WDDM 1.1 vs WDDM 1.2). Most documentation seems to point that it works on SP1, but not sure. Don't suppose there is a gpuinfo.org for DX?

Windows 8 introduced the WDDM 1.2 driver model, which provided improvements across the associated API surface for all feature levels. When reading the Direct3D11.1 documentation, understand that new drivers means WDDM 1.2 drivers. These updated driver versions, as well as most optional features exposed through CheckFeatureSupport, are unavailable on Windows 7. Since there is no guarantee that these optional features are available, make sure your applications have appropriate fallback behaviors in the event that the desired functionality is unavailable.

There’s one important exception. Several features, such as PSSetConstantBuffers1 with constant buffer offsets, require new drivers for feature level 10 and higher, but are actually emulated for feature level 9. This emulation is available on Windows 7 with the platform update. See D3D11_FEATURE_DATA_D3D11_OPTIONS for more info about which features are emulated.

https://docs.microsoft.com/en-us/windows/desktop/direct3darticles/platform-update-for-windows-7
This seems to suggest that PSSetConstantBuffers1 is available on W7 SP1 assuming the driver supports it. Driver docs confirm that it's a matter of driver model and not HW limitation:

This feature must be supported by all WDDM 1.2 drivers for Direct3D 10+ hardware. The Direct3D 11 runtime emulates the appropriate behavior for Feature Level 9_x.

https://docs.microsoft.com/en-us/windows-hardware/drivers/display/directx-feature-improvements-in-windows-8#buffers
Scary section from Nvidias blog:

Please note that the DirectX 11.1 implementation of XXSetConstantBuffers1() and of UpdateSubResource1() do not work on Windows 7 ™. You can really only rely on proper support on Windows 8 ™ and above.

https://developer.nvidia.com/content/constant-buffers-without-constant-pain-0

JFYI our data on this says that you can't rely on this feature. Specifically:

For FL11 users, only 85% can use CB offsetting
For FL10.1 users, only ~40% can use CB offsetting
No FL10.0 users can use CB offsetting

This is based on our (Roblox) data on our userbase, which is probably close to a typical browser audience.


New more mouseless-oriented controls

Looking at the controls on this video of SteamDeck UI, I notice popup selects that could be useful:
https://youtu.be/zXK1CXUyzXQ?t=29
There are probably others that don't neatly fit into what is already in raygui, but could use the same elements to make them work.
Another thing I notice from that video is things like sliders or just things that need more interaction have a kind of click-to-set functionality. So, like on a slider, you scroll to it, then hit activate button, and left/right now controls it. B or "back" is cancel, and A or "ok" is "set it to this".

Good research. Would need a toggle, or need to set the activeElement to NULL to indivate they're in a different GuiContainer context.


redux devtools import/export feature not working?

When I use the official redux devtools chrome extention, does the import/export store functionality work already?
I can save it to a json file, but when I try to import a store, nothing happens after I open it.
Is there any specific setting to make this work?
Thanks.

@Kiho do you know more about this?

I don't think import/export functionality was implemented.


Fix retina resolution icons

Currently the icons aren't shown in their retina version.
The retina resolution icons (they have an '@2x' appendix to their name) need to be added.
Here is a link to the files: https://drive.google.com/file/d/0B6ImQhe4L0zMdlp2WnFqRTFLRHM/view?usp=sharing

The retina icons are too big.

I guess... but maybe @brendror knows...

The retina icons should only be displayed on high-res screens (such as mac retinas).
On regular screens the non-retina icons should be displayed.
I think there's a lot of info online on how to work with retina/non-retina images.

Should not be difficult if you know what you're doing. Anyone?

@OmerSchechter  your script worked.. it looks for the correct ones. should just add icon to the path:
.../img/icons/

You are right, the script does work, but if you look closely you can see that it looks for the 'wrong' ones(i.e. not the marker icons that we have a retina version for, but other images on the page).
And there's no option to add the /icons/.
@danielhers I've managed to get the script 'working', so to speak.
The problem is, if our goal is to get the marker icons to switch to the retina version, the script doesn't do that. The script essentially works with document.getElementsByTagName('img') which finds all the 'img's on the page except for the googlemaps' icons.
I've looked at the "retina.js" code and it's not quite simple changing it to work with the marker icons as well.
What do you think about this solution?
I'm detecting Retina displays with a javascript script, and using RegEx to add the @2x prefix to the relevant images.
This solves the problem of the googlemaps icons, plus it won't double-load the images in case of a retina display(as I suspect "retina.js" will do), and the the urls are not hard coded.
var isRetina = (
    window.devicePixelRatio > 1 ||
    (window.matchMedia && window.matchMedia("(-webkit-min-device-pixel-ratio: 1.5),(-moz-min-device-pixel-ratio: 1.5),(min-device-pixel-ratio: 1.5)").matches)
);

if(isRetina){
    function addRetinaPrefix(url){
        return url.replace(/(^.*)(\.png)$/gi,function switchFunction(x,y1,y2){return y1+"@2x"+y2;});
    }

    for (var icon in ICONS){
        for (var i in ICONS[icon]){
            ICONS[icon][i] = addRetinaPrefix(ICONS[icon][i]);
        }
    }
    for (var icon in MULTIPLE_ICONS){
        MULTIPLE_ICONS[icon] = addRetinaPrefix(MULTIPLE_ICONS[icon]);
    }
    USER_LOCATION_ICON = addRetinaPrefix(USER_LOCATION_ICON);
    DISCUSSION_ICON = addRetinaPrefix(DISCUSSION_ICON);
}

Done?

Done.


'scaled down' version of TRE?

Hi ,
Please is there some 'scaled down' version of TRE available?  This repo is great, but there are an awful lot of resources deployed for this. I can imagine running terraform from ECS, and without all of the network resources deployed.  Even lambda can run terraform from an image (keeping in mind the 15 minute execution limit).
Thank you!
Tom

As you mentioned, it would be interesting for them to consider running EC2 with terraform installed within a VPC and subnet provided directly by the user at stack creation time (to avoid creation of some network resources like VPC, some subnets and 3 NAT gateways).
Maybe it can be implemented by creating a series of TRE templates with different usage scenarios.

Codebuild also works a great environment for executing Terraform, particularly longer running jobs.

Would be great to see this scaled down to run in an existing VPC. Many customers would immediately strike this down for attaching an EIP to an EC2 instance. And as others said, CodeBuild or ECS would be a better fit.

Hi all, have you all looked at alternative TRE: https://github.com/aws-ia/terraform-aws-sce-tf-community ? this is running serverless using CodeBuild.


Download Attachments from Drafts

Checklist

[X] I have used the search function to see if someone else has already submitted the same feature request.
[X] I will describe the problem with as much detail as possible.
[X] This issue only contains a request for one single feature, not multiple (related) features.

App version
6.200
Problem you are trying to solve
I use my drafts folder also as quick and safe method to store files that I need to access from anywhere. However, currently, I can't download attachments from Drafts. It's only letting me upload more attachments.
Suggested solution
Please make it possible to click on the attachment and download it anytime. Alternatively, place a small icon next to the "delete attachment button" (x).
Screenshots / Drawings / Technical details
No response

Rather than changing the compose screen to allow downloading/saving attachments, we will display drafts like regular messages and make editing drafts an additional button tap. See #4163.


Adjust OVN TransitSwitchIP initialization

We've observed E2E failures on route agent restart that was caused by the addition of the TransitSwitchIP refactoring. On code inspection, there's a potential timing issue related to initialization of the TransitSwitchIP. The Init method is called by NonGatewayRouteHandler.Init however the NewNonGatewayRouteController is started before that in Handler.Init so, depending on timing, nonGatewayRouteCreatedOrUpdated could get invoked prior to initialization of the TransitSwitchIP, in which case it would observe an empty IP.
To avoid this, move the TransitSwitchIP.Init call to Handler.Init prior to starting the NewNonGatewayRouteController.

@tpantelis Does this need to be backported to 0.18.0 as well?

@tpantelis Does this need to be backported to 0.18.0 as well?

No - it was added in 0.19


WebAssembly version using Emscripten?

Many C++ libraries have been converted to Javascript / WebAssembly using Emscripten, such as Bullet physics https://github.com/kripken/ammo.js/, Box2D, ect. Which has resulted in great performance boosts for JS versions.
Example: https://www.youtube.com/watch?v=ye_SClDZ4pA.
I think this library would be a great candidate for it, being that is seems to be the fastest ECS library available in C++, and I would very much appreciate a WebAssembly version to use in my projects.
Any thoughts on this?

It would be great. However, EnTT is mostly template based, therefore I don't think we can just port it as is. Am I wrong?
If you have any experience with emscripten, any help would be appreciated. Let's wait also for more experienced users that can share their knowledge.

You can close the issue, emscripten work fine with EnTT actually it's work in shiva

Can you make the compiled .wasm / .js files available somewhere? Such as under releases?

@Milerius I think the question is for you.

As @skypjack say it's an header only library you need to compile your program with emscripten compiler and everything will work

@Zentendo He's the second person that is saying we cannot compile the library as-is because of it's template nature. What did you have in mind exactly?

I think he wants to use Entt from within javascript, wich is not possible due to EnTT templates (easily) nor from other libraries of this kind. To use a library from javascript, it needs to be extern C, and then the implementation can be compiled down and functions exposed.
If you have a game engine like Milerius says, you can compile the whole thing to webasembly and run it.
But you are never going to be able to define a new component type or do  a join from javascript (for the joins, maybe, but you need to define the components in the compiled code so the templates get instanced)


Lazy iterator DML support for DML Options

Currently, the lazy iterator DML support only the all or nothing flag.
Can we add support to pass in Database.DMLOptions instead, please?
Database.DMLOptions dml = new Database.DMLOptions();
new nebc.LazySObjectIterator(newList)
.filterT(new nebc.IsSObjectFieldEqual(Payment__c.Create_Task__c, true))
.mapValuesT(new BuildPaymentTask(taskOwnerId))
.doInsert(dml);

Good shout...
Released in v0.76


Show new file as explicit entry in filer

This makes filer always shows an entry for the query itself in the file
list, which makes editing a new file more explicit.
Before, if the query didn't match anything "NO MATCHES FOUND" is shown
and if you press enter, clap opens a buffer named the current query.
It also wasn't possible to open a new buffer this way if the directory
was empty. A buffer with the name "Directory is empty" is opened no
matter what the input is.
Now, the current query is always shown as a file that can be opened,
which, at least for me, feels more intuitive and matches behavior of
similar interfaces (e.g. Helm find files in emacs).
This also works in empty directories. If you tab to an empty directory
and press enter with the empty query, the directory itself is opened.

It also wasn't possible to open a new buffer this way if the directory was empty.

To achieve this, only the sink function needs to be changed.

If you tab to an empty directory and press enter with the empty query, the directory itself is opened.

Ditto. Only sink needs to modified. I don't understand why the other changes are neccessary? Can you explain a bit?

It isn't possible to add the query as an entry in the list just changing sink, which was the main reason I made the change, along with the "Directory is empty" bug.
The behavior until now is (file is the query):
/home/mike/folder/[file                                          ]
>>file1
>>file2

and I am unable to create file because it matches an existing entry.
Now:
/home/mike/folder/[file                                          ]
>>file1
>>file2
>>file

where file doesn't exist.

Your current approach doesn't make much sense semantically as the query is not a candidate essentially, especially injecting it in the candidate list when filtering. Have you check about the action feature introduced since https://github.com/liuchengxu/vim-clap/pull/396? It's a better way to work with these cases, not only creating a new file, but deleting and moving, etc.

it seems like they operate on an entry in the list

That's incorrect. You can do basically anything as you can access all the information.
I can accept you also implement the same thing like helm, using a special mark for that mocked entry makes more sense.

@liuchengxu ok, I've added the prefix (I used + )
I also had to fix the entry appearing double if the file does exist, it's a bit little bit ugly, though. This was the easiest way, although it might be worth building into the rust crate.

To implement the helm like new file entry, a lot of details needs to be taken care of.

I've been using my changes on top of vim-clap for the past 2 months w/o issue, so I haven't bothered to update this. I'll take another look.


Add libWrapper wraps for Scene, SceneControls, and Token methods

Hi! This PR just adds some libWrapper wraps for your overrides of Scene, SceneControls, and Token methods. I noticed that in my PR version of Drag Ruler, libWrapper threw a warning about a potential conflict for the Token drag methods. I am sure other modules may have conflicts as well, so I just added wraps for all.
I just used a basic check for libWrapper and if present, used that instead of your existing code. I copied in your existing overwrite code (none are very complicated), as that seemed like the simplest approach. So the "changes" indicated here are mostly just moving existing code into an if clause and copying existing code to the libWrapper functions.
If it were me, I would just require libWrapper so I could get rid of legacy code, but I am mean like that...
I checked it in Foundry 0.8.9 and dnd5e 1.4.2. Appears to work w/ and w/o libWrapper. Libwrapper reports the wrapped functions, and the Drag Ruler conflict warning is no longer present.
Hope this helps!

I 100% appreciate this pull request.
But I'm closing it, only because the changes aren't how I've done libWrapper functions in my other modules, so I wanted to keep it consistent.  But I've been putting it off for awhile now, and it was good to have a little push to get it completed.


Problem with raw data: getRow(idx).data().asDouble()

Issue Description
When I try to get raw data from row vector (getRow(idx).data().asDouble()) I got double[] array with incorrect length. For more details let's consider following code:
Code:
int rows = 8;
int columns = 2;
INDArray array = Nd4j.zeros(rows, columns);
Log.e("array", array.toString());

INDArray firstRow = array.getRow(0);
Log.e("first row", firstRow.toString());

DataBuffer dataBuffer = firstRow.data();
Log.e("data buffer", dataBuffer.toString());

double[] rawData = dataBuffer.asDouble();
Log.e("raw data", Arrays.toString(rawData));

Output:
array: [[0.00, 0.00],
        [0.00, 0.00],
        [0.00, 0.00],
        [0.00, 0.00],
        [0.00, 0.00],
        [0.00, 0.00],
        [0.00, 0.00],
        [0.00, 0.00]]
first row: [0.00, 0.00]
data buffer: [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
raw data: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

In this case raw data array has sixteen elements. Is it correct?
Let's consider next piece of code (the same instructions on submatrix):
Code:
INDArray subarray = array.get(NDArrayIndex.interval(1, array.rows()), NDArrayIndex.all());
Log.e("subarray", subarray.toString());

firstRow = subarray.getRow(0);
Log.e("first row", firstRow.toString());

dataBuffer = firstRow.data();
Log.e("data buffer", dataBuffer.toString());

rawData = dataBuffer.asDouble();
Log.e("raw data", Arrays.toString(rawData));

Output:
subarray: [[0.00, 0.00],
           [0.00, 0.00],
           [0.00, 0.00],
           [0.00, 0.00],
           [0.00, 0.00],
           [0.00, 0.00],
           [0.00, 0.00]]
first row:: [0.00, 0.00]
buffer: [0.0,0.0]
raw data: [0.0, 0.0]

In this case raw data array has two elements. Which behavior is correct?
Version Information

Nd4j version: 0.8.0
Android 7.0

getRow(i) usually results in a view. So if you want to get just the data of that view, you will have to do it like that:
getRow(idx).dup().data().asDouble().
the .get -> .getRow case works only because of a special case handling, where it would have resulted in a view on a view, and you basically got the dup() done for you at some point.
Basically, if you want to get data as a double[] you shoul always use .dup(), as only that will guarantee you that the INDArray you are calling data().asDouble() on, will be pointing to just the data that you want.

Thanks :-)


Update supported Python versions

This PR also makes a few logical changes (mostly regarding test running) in order to get tests to pass under Python 3.12.

Remove Python 3.7 from the test matrix and list of supported versions in setup.py, as it reached end of life on 2023-06-27
Add Python 3.12 to the list of tested / supported versions as the current major version
Replace usage of python setup.py test and the PyTest test command with a more direct invocation of pytest in tox.ini
Replace usage of pkg_resources.get_distribution with importlib.metadata to get the installed version number for vladiate

@di does this seem reasonable? I'm sure there's more to be done to modernize the packaging config here, but my main goal was to get tests running for 3.12.


The constructor removed from TestRunner would stop Eclipse working.

TestNG Version
latest
Is the issue reproductible on runner?

[ ] Shell
[ ] Maven
[ ] Gradle
[ ] Ant
[ x] Eclipse
[ ] IntelliJ
[ ] NetBeans

@eyehwan , could you paste the exception stacktrace here


Adding implementation for EmpiricalDistribution

Implements EmpiricalDistribution based on comments and suggestions from @fritzo and @eb8680.
The goal was the following:

Have a generic EmpiricalDistribution implementation that can accept importance weights.
Supporting log_prob. However, supporting this should not result in a performance penalty for cases where we do not need to compute log_prob. Hence any heavy pre-processing (like tensor comparisons) required when adding samples to support log_prob is bypassed.
Supporting fast append operation, without too much overhead - we append to a buffer which is lazily concatenated to an internal tensor when needed.
Should be possible to re-use the same EmpiricalDistribution implementation. e.g. appending some value, computing the mean, appending some more values, re-computing the mean etc. There should be no assumption that the add operation precedes all statistical computation on the samples.

What is currently missing?

I have not figured out a way to support vectorized log_prob, i.e. the ability to score multiple samples at the same time. Doing so will likely require a different implementation that needs to pre-process samples as they are added, and will be slow. Currently, log_prob only accepts single values.

Addresses #942.
Related: #943 - Alternate sketch that does not support log_prob or importance_weights.

Will update with .enumerate_support.

@fritzo, @eb8680, @martinjankowiak - Thanks for reviewing this! There are a few things that I would like to change, and add another test, but that can wait for a subsequent PR. This should be good to merge otherwise.


Baidunetdisk: delete <IP_ADDRESS> & update to 7.5.0

[x] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Why always download failed?
It's works in my laptop.
##[error] Installer https://issuecdn.baidupcs.com/issue/netdisk/yunguanjia/BaiduNetdisk_<IP_ADDRESS>.exe
##[error] Result: Failed

Why always download failed？
It work's in my laptop.
##[error] Installer https://issuecdn.baidupcs.com/issue/netdisk/yunguanjia/BaiduNetdisk_<IP_ADDRESS>.exe
##[error] Result: Failed


Add CI configs

Currently, some imosCI test targets are running, but I'd like to stop them and add the following targets instead:

https://ci.preferred.jp/chainerrl.py3.gpu/
https://ci.preferred.jp/chainerrl.py3.cpu/
https://ci.preferred.jp/chainerrl.py3.chainer4/

The details for each test target should be written in .pfnci/config.pbtxt.

FYI, the commit's test results are available at:
https://ci.preferred.jp/p/dashboard_by_commit_id?commit_id=d9b6c21c09fa132073f8f8d664649009d4ae6831


Python models should have API where they can provide max_batch/inputs/outputs for auto-complete

To-Dos:

[x] Implement the auto-complete logic
[x] Update documentation
[x] Add test to cover the changes : https://github.com/triton-inference-server/server/pull/4322

@Tabrizian Addressed and left some comments, please review. Thanks Iman!

Will create another PR for the README.md for examples/auto_complete.

Only these two minor comments and the PR LGTM! Thank you for all the effort you put into finishing up auto_complete.


Is There This Pl For Pm4?

Hi, Is There Is This Plugin For Pm4 , If Yes Can I Get Link

Sorry, This plugin is only for PM5.

Can You Fix World Guard For PhP8 Pm4


Increase test coverage and fix parse bug

This pull request introduces 2 alerts when merging 1e8d5fd into cef46c0 - view on LGTM.com
new alerts:

1 for Expression has no effect
1 for Property access on null or undefined

有新问题

This pull request introduces 2 alerts when merging 1e8d5fd into cef46c0 - view on LGTM.com
new alerts:

1 for Expression has no effect
1 for Property access on null or undefined

有新问题

嗯 看到了，一并修改了


escape key press #2412

When modal is dismissed make callback with empty result (like when Close btn clicked)

:+1:

:+1:


Loading project forever

I always get stuck on this page. No way to really use your product!

Same problem.
Can not download either.

Folks, this is related to the huge flow of new users trying it out. I think devs will scale the servers at some point

We have improved the reliability of our servers over the last weeks. This includes loading projects, collaborating, and saving changes. Now, you should be able to load a project pretty quickly.
We also now back up your changes on the browser automatically to prevent data loss even if the connection is bad or if Typst becomes unavailable.
I am very sorry for the inconvenience and hope you'll try the app again!

I am also now experiencing this issue..

I get:
Errors while initializing: We could not connect to the server. Try again to continue.

I meet the same issue

@wenzhengzeng We had an outage. The service is back up.


Story to persist user scores to the scores table on the db

When a user submits scores via the scores endpoint, this method persists their scores into the scores table. The primary key is a UUID- I'm casting it to an int, which I think is wrong- the smaller size of int vs a UUID means that they will eventually collide. It should be ok for now, so I pushed the code, but if we use a real, in memory DB that should be able to generate a UUID for each entry and we can use that- or something else.

@biotom You might want to consider this as a future solution for the session-id. It seems UUID is not really secure.
https://stackoverflow.com/a/6092448/13489999

@biotom You might want to consider this as a future solution for the session-id. It seems UUID is not really secure.
https://stackoverflow.com/a/6092448/13489999

That's interesting! But do we mind that much in this case? We just want something that's not going to collide, but we're not really generating session IDs in a cryptographic sense. We should look at real session managment, though- for instance, rolling back DB commits if a session ends early et cetera.

@biotom You might want to consider this as a future solution for the session-id. It seems UUID is not really secure.
https://stackoverflow.com/a/6092448/13489999

That's interesting! But do we mind that much in this case? We just want something that's not going to collide, but we're not really generating session IDs in a cryptographic sense. We should look at real session managment, though- for instance, rolling back DB commits if a session ends early et cetera.
Maybe like: https://overiq.com/flask-101/sessions-in-flask/

It probably doesn't matter. That makes sense! I'll read this soon.

I think that's fine. As long as it's unique I can't think of any rules it
would violate
On Thu, Sep 24, 2020, 8:41 PM Tom Deadman<EMAIL_ADDRESS>wrote:

@biotom commented on this pull request.
In knowledge_graph/models.py
https://github.com/ClimateMind/climatemind-backend/pull/58#discussion_r494244816
:

@@ -38,6 +38,22 @@ def load_user(id):

class Scores(db.Model):

session_id = db.Column(

   db.Float, db.ForeignKey("user.id"), primary_key=True, unique=True

Yep, that makes sense- although maybe a string would be even better? I
don't think a UUID can really be represented as an int, and casting it into
one increases the chances of a collision, since int is smaller- it should
probably be a string. Would changing it to a string break anything that
uses the db?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/ClimateMind/climatemind-backend/pull/58#discussion_r494244816,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCZ6OTHQC3PQ2AUPPI5INTSHMV5RANCNFSM4RWIZGZQ
.


Is Taipy.io down?

What went wrong? 🤔
Taipy.io is not working in the normal window, but it's working sometimes in the Incognito window.
Here are some screenshots of the website in normal and incognito window
Normal Window

Incognito Window

I've tried this on 3 devices and same issue is there in all 3 of them.
Expected Behavior
Taipy.io should be working both in normal and incognito windows
Steps to Reproduce Issue
No response
Solution Proposed
No response
Screenshots
No response
Runtime Environment
Chrome Version: 126.0.6478.114
Browsers
Chrome
OS
Windows
Version of Taipy
No response
Additional Context
No response
Acceptance Criteria

[ ] Ensure new code is unit tested, and check code coverage is at least 90%.
[ ] Create related issue in taipy-doc for documentation and Release Notes.

Code of Conduct

[X] I have checked the existing issues.
[ ] I am willing to work on this issue (optional)

Really weird!

@FlorianJacta, is this issue on you side also or there might be a problem with my system?

It works fine for me. I have asked @RymMichaut

Yes, now it's working @jrobinAV 👍


feat: added maxzoomForRendering and minzoomForRendering

This will allow rendering with —maxzoom=6 while having zoom 6 rendered the same way as if —maxzoom=14.
maxzoomForRendering will be used for simplifly algorithms. The default is MAX_ZOOM(14) so by default whatever maxzoom is used you will get the same render as if maxzoom=14

Interesting that no tests break. Maybe you want to add some for the new behavior? Also, maybe this change could be somewhere reflected in the documentation?

@wipfli actually it is not normal for no test to break as the rendering is exactly the same as with maxzoom 14. About the doc yes. I am waiting on @msbarry to see first if he wants some refactoring

Interesting that no tests break. Maybe you want to add some for the new behavior? Also, maybe this change could be somewhere reflected in the documentation?

Good point, 1 new test in PlanetilerTest might make sense similar to the compact DB tests - basically run planetiler with --maxzoom=14 and --maxzoom=8 and --render_maxzoom=8 --maxzoom=8 and compare the number of features in some tile at z8 to make sure it's the same for first too, and larger for last one.
That kind of smoke test also ensures we don't throw an exception when someone uses this option.

@msbarry i am looking at writing the test. I get the idea of what you want to do but to be honest i am a bit lost on the features to add. what we need for the test is 2 have one feature only visible at zoom 8 and one visible at zoom 14.
That way:

--render_maxzoom=8 --maxzoom=8 should show on the zoom 8  feature at zoom 8
--maxzoom=14 : same thing
--maxzoom=8 is the failure as it will show both features.

The tricky part is that i cant do it with zoomRange it has to be "filtered" by minPixelSize. And that i am a bit lost with.
i can push the skeleton of the test if you want but i did not go much further :s really sorry

@msbarry i am looking at writing the test. I get the idea of what you want to do but to be honest i am a bit lost on the features to add. what we need for the test is 2 have one feature only visible at zoom 8 and one visible at zoom 14. That way:

--render_maxzoom=8 --maxzoom=8 should show on the zoom 8  feature at zoom 8
--maxzoom=14 : same thing
--maxzoom=8 is the failure as it will show both features.

The tricky part is that i cant do it with zoomRange it has to be "filtered" by minPixelSize. And that i am a bit lost with. i can push the skeleton of the test if you want but i did not go much further :s really sorry

No problem, I'll take a stab at adding one this week.

No problem, I'll take a look at adding a test for this.

Looks good, thanks for adding!

I think this logic is correct:
https://github.com/onthegomap/planetiler/blob/76c7880d6b4c5535157582416d8dedf648ed3f70/planetiler-core/src/test/java/com/onthegomap/planetiler/PlanetilerTests.java#L1789-L1792
We don't want --maxzoom=8 to cause small features to show up in the z8 unless you explicitly set --render-maxzoom=8

@msbarry I think you got this wrong (or this PR is not doing what i think it is). The point of render_maxzoom is to have zoom 8 tiles to be exactly like they are when you render with maxzoom=14 so the assert for baseResult should be the same as renderMaxzoomResult and should be false because the feature will be removed because of  simplification (in both cases).
while with maxzoomResult (maxzoom=8) the feature is not simplified at zoom 8 because 8 is the maxzoom and thus all simplifications are disabled.

I was interpreting render_maxzoom as the zoom level past which clients will overzoom, so it should set a lower simplification/size threshold at that zoom level.  This makes minzoom/maxzoom only control which tiles get generated and not affect the contents of those tiles which is likely what most users want.
The test verifies that the contents of z8 tiles is the same with maxzoom=8 or maxzoom=14, but only changes if you set render_maxzoom=8 (which clients would very rarely do).

@msbarry damin Mike i am sorry you are 100% right, it is me who got the test mixed up in my head  :( i am so so so sorry. Indeed in my case i use render_maxzoom=14 to get what i described before. But your test uses 8.
What i describe would be a test with render_maxzoom=14
Again so so sorry for wasting your time ...

Great feature. I have a few questions, because I'm not really sure if understand this correctly.

Should this work like Overzooming in tilelive-vector? If I generate mbtile to zoom level 8, currently I get on level 9-14 empty tiles and everything is rendered white (because they doesn't exists).
With overzooming it generate tiles with same details as of max zoom tile, so if I put render_maxzoom to 8 and maxzoom to 14, it will generate all tiles to z 14, but simplified, with details as of z 8 right?

I get a lot of errors ("Error processing OSM Way ..." and "Error processing OSM Relation ... java.lang.ArrayIndexOutOfBoundsException") if I set render_maxzoom to 8. Is that normal? (tested on currently latest commit in main branch)

Great feature. I have a few questions, because I'm not really sure if understand this correctly.

Should this work like Overzooming in tilelive-vector? If I generate mbtile to zoom level 8, currently I get on level 9-14 empty tiles and everything is rendered white (because they doesn't exists).

With overzooming it generate tiles with same details as of max zoom tile, so if I put render_maxzoom to 8 and maxzoom to 14, it will generate all tiles to z 14, but simplified, with details as of z 8 right?

I get a lot of errors ("Error processing OSM Way ..." and "Error processing OSM Relation ... java.lang.ArrayIndexOutOfBoundsException") if I set render_maxzoom to 8. Is that normal? (tested on currently latest commit in main branch)

Hello! Overzooming only happens in the client. Planetiler assists the client by including more detail at the max zoom level for rendering that it generates. This PR made it so that setting max zoom lower just omits zoom levels above that, without including more detail at the max zoom level. If you actually do want more detail at that max zoom level, then use the max zoom level for rendering flag instead.
Setting max zoom level for rendering less than max zoom results in undefined, I'll try adding an error message at startup that explains a little better.

Aha, now I get it, thanks. Client (at least mine) will overzoom if you say that generated map is to zoom 8 (source in style.json) and you want max zoom 14 (for example in mapbox map). But when you have merged map with some parts (planet) to level 8 and some region (country) to 14 will:

when set as maxzoom 8 in source inside style.json: overzoom everything even if tiles are generated higher than 8
when set as maxzoom 14 in source inside style.json: empty tiles for zoom level above 8 if zoomed outside generated region

I thought it's solving that problem. My mistake, sorry.


gudp uint test

gudp uint test

@flead No active for more than one month, close it. If you need further proceed, please submit new one.


Add convenience methods for appending parameters to query string.

Instead of specifying all of the query string parameters directly in the URL, you can now do
Request::get("http://api.flickr.com/services/rest/")
    ->param("api_key", $apiKey)
    ->param("format", "json")
    ->param("nojsoncallback", 1);
    ->param("photo_id", $photoId)
    ->param("method", "flickr.photos.getInfo")

which I would consider more elegant and concise than creating one, very long URL with all of the parameters embedded, and their values interpolated in the string.

http://php.net/manual/en/function.http-build-query.php
Just sayin'


Error with RPC response for setting GPIO

Hi,
The following code is from ESP32 Example
https://thingsboard.io/docs/samples/esp32/gpio-control-pico-kit-dht22-sensor/
RPC_Response processSetGpioState(const RPC_Data &data)
{
  Serial.println("Received the set GPIO RPC method");

  int pin = data["pin"];
  bool enabled = data["enabled"];

  if (pin < COUNT_OF(leds_control)) {
    Serial.print("Setting LED ");
    Serial.print(pin);
    Serial.print(" to state ");
    Serial.println(enabled);

    digitalWrite(leds_control[pin], enabled);
  }

  return RPC_Response(data["pin"], (bool)data["enabled"]);
}

When the GPIO control widget is used on the dashboard, it send the setGpioStatus RPC call, but the response contains the value for the pin switched only. This response cannot be interpreted by the widget and the pin control on the widget stays at the default position.
How to send the proper response which includes the status of all pins using ThingsBoard library?
This can help in implementing a getGpioStatus callback as well.
The following example for ESP8266 works perfectly because the response to the RPC call contains all the pins, however, this example does not use the the ThingsBoard library.
https://thingsboard.io/docs/samples/esp8266/gpio/
Thank you.
@forGGe @ferchinas

convert int to char
  char newChar[2];
  String temp_str = String(pin);
  temp_str.toCharArray(newChar,2);

  return RPC_Response(newChar, (bool)data["enabled"]);

@forGGe @ferchinas

Looks like a bug either in ThingsBoard.h or ArduinoJson.h. Thingsboard is ignoring the pin data which is supposed to be in const char type. An easy work around is to use array of const char and use pin data to select the item from array and pass to the RPC_Response.
const char  * pinarray[]={"0","1","2","3","4"}; // Numbers corresponds to GPIO pin number in ThingsBoard dashboard GPIO widget
RPC_Response processSetGpioState(const RPC_Data &data){
  int pin = data["pin"];
  bool enabled = data["enabled"];
  digitalWrite(leds_control[pin], enabled);
  return RPC_Response( pinarray[pin] ,(bool)data["enabled"]); //pinarray[pin] is a workaround to send const char key as telemetry
}

Tôi đã thay đổi loại RPC_Response từ Từ xa thành Chuỗi và thêm getGpioStatus. Vui lòng xem: https://wokwi.com/projects/328082930673910354

wow i find that bug when i try run you code
could not convert 'String(led_delay, 10)' from 'String' to 'RPC_Response {aka Telemetry}'

@imbeacon Can be marked as enhancement as well refers to the same underlying feature request as #79


Add select to bottom

Simply allows the user to select from a note to the bottom of the sheet, which can be useful for multi-transposition from certain points

Nice catch 👍, I have added as suggested

Perfect, thanks!


Ctrl + L shortcut makes WSL display strange

Windows10 set the default shell in terminus as WLS/Ubuntu
When using ctrl+L, it does clear the screen while the cursor will jump far away. But if I use clear command, everything goes on well.

@Hustcw I removed "CTRL+L" from hotkeys in settings menu and it worked for me. I'm using v1.0.77.

@mvineza Thanks for your reply. Actually I only find this strange display when I use terminus for wsl. I can run terminus well if I only use terminus for ssh. The most funny thing is I can use
clear

to make everything goes ok. So maybe there's some bugs in hot-key for wsl? I guess

@mvineza  It works for me ,thanks very much!

@mvineza  nice! It works. good job!

@mvineza great find! Terminus doesn't forward keys that are recognized as hotkeys to the shell, so while Ctrl-L would clear the TTY, the actual process isn't aware of this. I'll remove the default clear hotkey assignment on Windows and Linux.


Create stage environment

The app needs functionality testing in a live staging environment.

The stage environment should have a dedicated branch in the repo.


Closed channels do not get reset in sctp-proto

I'm using the direct API of str0m to open and close outbound data channels. The following code: https://github.com/algesten/str0m/blob/eb0fbe0e01d04e38b8b230a9995951d38447750f/src/channel.rs#L202-L225
allocates the next SCTP ID for an outbound data channel, trying to reuse an old ID when possible. Problem is that while it's trying to reuse an ID, the stream has not been unregistered from SCTP and the following issue happens:
<channel for stream 1 opened normally>
2024-03-03 13:50:36.259 str0m::sctp: Stream Open -> Closed
2024-03-03 13:50:36.259 str0m::sctp: Poll Close { id: 1 }
2024-03-03 13:50:36.259 str0m: ChannelClose(ChannelId(0))
...
2024-03-03 13:50:36.262 str0m::channel: Allocate channel id: ChannelId(7)
2024-03-03 13:50:36.262 str0m::channel: Associate stream id ChannelId(7) => 1
2024-03-03 13:50:36.262 str0m::channel: Open stream for: ChannelId(7)
2024-03-03 13:50:36.262 str0m::sctp: New stream 1 (AwaitOpen): open_stream
2024-03-03 13:50:36.262 str0m::sctp: Open stream 1
2024-03-03 13:50:36.262 str0m::sctp: Opening stream 1 failed: ErrStreamAlreadyExists with in-band

This happens because while the stream is marked for closing and later closed, it doesn't get unregistered from sctp-proto and when str0m tries to reuse the same SCTP ID for a new channel, it triggers an error.
I imagine there should be a function pub fn close_stream(StreamId) in sctp-proto's Association that would properly reset and destroy the stream so that the ID can be reused but wanted to open an issue before working on it in case there is an easier way of dealing with this issue. Any thoughts?

Hi @altonen!
I wonder if the problem is that we can reuse the id without opening it again? Either way the idea is that SctpEvent::Close would only happen when the id is free to reuse. Is there maybe additional logic we can put in sctp/mod.rs that ensures the id is definitely deallocated before we trigger SctpEvent::Close?

One fix for this was in #470 – there could be better solutions, but this will do for now.


Remove deprecated features for 1.17

Fixes #3086, #3090, #3092, #3097, #3099, and #3101.

Amazing.


Strange No such file error

Using yam repo, and running any of the following results in a weird error:
Inside the scripts folder run:
$ dapp test --fork-url "https://c2b849cff6a24e57beeac6bae21033b1.eth.rpc.rivet.cloud/" --verbosity 5 --match test_onchain_prop_18 --contracts=../contracts

changing the contracts directory to renamed as src:
dapp test --fork-url "https://c2b849cff6a24e57beeac6bae21033b1.eth.rpc.rivet.cloud/" --verbosity 5 --match test_onchain_prop_18

both result in this unhelpful error:
Oct 18 16:52:24.479 ERROR dapp: error=No such file or directory (os error 2)
Error: No such file or directory (os error 2)

Location:
    /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:1675:27

OK this is the new errror:
Oct 20 17:46:03.815 ERROR dapp: error=Failed to read directory `lib` for remappings
Error: Failed to read directory `lib` for remappings

Caused by:
    No such file or directory (os error 2)

Location:
    dapptools/src/utils.rs:87:45

@jparklev do you think we could make the error give the full path that was attempted?


Add Helm 2.8.2 support

Updated constraint to allow Helm 2.10.0.
This prevents
level=error msg="Loading current state failed" error=EOF
Error: EOF

messages.

Thanks for the help. According to travis:
# github.com/eneco/landscaper/vendor/k8s.io/helm/pkg/kube
vendor/k8s.io/helm/pkg/kube/client.go:208:37: not enough arguments in call to "github.com/eneco/landscaper/vendor/k8s.io/kubernetes/pkg/kubectl/cmd/util".PrinterForOptions
	have (*printers.PrintOptions)
	want (meta.RESTMapper, runtime.ObjectTyper, runtime.Encoder, []runtime.Decoder, *printers.PrintOptions)
FAIL	github.com/eneco/landscaper/pkg/landscaper [build failed]
make: *** [test] Error 2```

The readme points to kubernetes 1.9 and i think that the revision you are using is for 1.10.3


Context deadline exceeded when selector is a tag name

What versions are you running?

$ go list -m github.com/chromedp/chromedp
github.com/chromedp/chromedp v0.5.1

$ google-chrome --version
Google Chrome 78.0.3904.97

$ go version
go version go1.13.1 linux/amd64

What did you do? Include clear steps.
package main

import (
	"context"
	"fmt"
	"github.com/chromedp/chromedp"
	"log"
	"net/http"
	"time"
)

func handler(w http.ResponseWriter, r *http.Request) {
	w.Header().Add("Content-Type", "text/html")
	fmt.Fprint(w, `<!DOCTYPE html><meta charset="utf-8">

  Click me!

`)
}

func main() {
	http.HandleFunc("/", handler)
	go func() {
		log.Fatal(http.ListenAndServe(":3003", nil))
	}()
	ctx, cancel := chromedp.NewContext(
		context.Background(),
		//chromedp.WithDebugf(log.Printf),
	)
	defer cancel()
	ctx, cancel = context.WithTimeout(ctx, 10*time.Second)
	defer cancel()

	var html string
	err := chromedp.Run(ctx,
		chromedp.Navigate("http://localhost:3003"),
		chromedp.Evaluate("document.documentElement.innerHTML", &html),
		chromedp.WaitVisible("a"),
		chromedp.Click("a"),
	)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Println("HTML was:")
	fmt.Println(html)
}

What did you expect to see?
I expected no errors.
What did you see instead?
"context deadline exceeded".
When I use a CSS class (instead of an element tag) in WaitVisible and Click, there are no errors.

I also notice that the HTML I print back contains two extra blank lines:
<!DOCTYPE html><meta charset="utf-8">

  Click me!

Hi,
Chromedp provides different By* functions to specify how you want to look for an element. The default is chromedp.BySearch which wraps dom.performSearch.
What you need is document.querySelector which is wrapped by chromedp.ByQuery. If you add this option to your WaitVisible and Click calls, it'll work just fine :)
		chromedp.WaitVisible("a", chromedp.ByQuery), 		chromedp.Click("a", chromedp.ByQuery),
Source: I just tried ^^

Well, it certainly doesn't work for me even with chromedp.ByQuery. The error is the same.
And the docs say this:
// The BySearch (default) option enables querying for elements with a CSS or
// XPath selector, wrapping DOM.performSearch.
...
// The ByQuery option enables querying for a single element using a CSS
// selector, wrapping DOM.querySelector. ByQuery is similar to calling
// document.querySelector() from within the browser.

So I don't see why any of the options shouldn't work.

I agree that the differentiation between the two is a tiny bit confusing. My first guess is that BySearch will return an array of elements where ByQuery will return the first element that matches the selector, making BySearch improper for selecting specific nodes.
I am not proficient enough with the chrome devtools protocol to have a clear answer, but surely if both functions exist within it, then they perform differently. Maybe @mvdan has helpful knowledge on this ?
Anyways, glad it works for you now :)

I think @Ajod is right, in which case this issue is very similar to #440. I agree that the situation can seem confusing to new users, but I can guarantee the current design is on purpose. It could be documented better for sure, though.
I'm going to close this issue for now. If you take a look at the previous issue and you're convinced that it's not a duplicate, we can reopen.


Locked jQuery dependency doesn't work with Steal + NPM2

The fix for #476 to install a fixed version of jQuery does not work with Steal and NPM2. One of the jQuery package.json's errors (not with a 404 but an HTML error) because it is not installed.

I'll look into this, saw no problems with a fresh donejs init this morning with npm3.

Happens only with NPM2

I'm not seeing this, after a fresh donejs init it's working for me, anything in particular you did differently?

You are right. That may be something else. Still checking why it didn't give a 404.


Moved all providers to the same package

See

https://github.com/scalameta/language-server/pull/93#discussion_r154569956
https://github.com/scalameta/language-server/pull/93#discussion_r154802522

LGTM 👍


Upgrading from v2022.05.24 to v2023.04.10 results in heavy load on k8s apiserver

Audit logs shows every secret in the namespace where db are deployed is GET called.
User primarily has Postgres and Redis instances and some Elasticsearch servers.

https://discord.com/channels/439940043369349120/963813950196174940/1105885554987507832

[ ] Image digest check
[ ] Postgres external secret related changes

Fixed in v2023.06.19

Additional resource types are LIST-ed. Needs to fixed.


Automate new CDN uploads

We've reworked the CDN so that we can directly upload to Azure Storage. We want to automate this process in our pipeline. Extension of #893

Yes please! I'd love to rely on the new release notifications implying that the new version is available at the CDN link. I've seen it delayed weeks and it is annoying.

@keystroke Trust me, don't have to tell @jmckennon how annoying this has been :)

The first part of this is done (automating the upload process). Rest of the work is captured in internal PBIs, closing.


test_autograd_save_memory fails and breaks builds

test_autograd_save_memory fails sporadically and causes builds to fail.
The code that breaks was added in PR #7478
Links to build failures:
https://builds.apache.org/view/Incubator Projects/job/incubator-mxnet/view/change-requests/job/PR-8199/3/
https://builds.apache.org/view/Incubator Projects/job/incubator-mxnet/job/master/491/
https://builds.apache.org/view/Incubator Projects/job/incubator-mxnet/job/master/493/
Error log:
test_operator_gpu.test_autograd_save_memory ... [20:02:42] /workspace/dmlc-core/include/dmlc/logging.h:308: [20:02:42] src/storage/./pooled_storage_manager.h:102: cudaMalloc failed: out of memory

Stack trace returned 10 entries:
[bt] (0) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7ffaa471293c]
[bt] (1) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet7storage23GPUPooledStorageManager5AllocEm+0x1d8) [0x7ffaa5efd6a8]
[bt] (2) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet11StorageImpl5AllocEmNS_7ContextE+0x61) [0x7ffaa5f009f1]
[bt] (3) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNK5mxnet7NDArray13CheckAndAllocEv+0xf6) [0x7ffaa4a4ba06]
[bt] (4) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6common22SetupDefaultBlobsInOutERKSt6vectorINS_7NDArrayESaIS2_EES6_PS1_INS_5TBlobESaIS7_EESA_PS4_SB_SB_SB_PSt13unordered_mapIjjSt4hashIjESt8equal_toIjESaISt4pairIKjjEEERKS1_IjSaIjEE+0x38d) [0x7ffaa5a9143d]
[bt] (5) /workspace/python/mxnet/../../lib/libmxnet.so(_ZZN5mxnet10imperative12PushFComputeERKSt8functionIFvRKN4nnvm9NodeAttrsERKNS_9OpContextERKSt6vectorINS_5TBlobESaISA_EERKS9_INS_9OpReqTypeESaISF_EESE_EEPKNS2_2OpES5_RKNS_7ContextERKS9_IPNS_6engine3VarESaISW_EES10_RKS9_INS_8ResourceESaIS11_EERKS9_IPNS_7NDArrayESaIS17_EES1B_RKS9_IjSaIjEESJ_ENKUlNS_10RunContextENSU_18CallbackOnCompleteEE_clES1G_S1H_+0x1e8) [0x7ffaa5a91858]
[bt] (6) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x112) [0x7ffaa5a0f7a2]
[bt] (7) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7ffaa5a138d3]
[bt] (8) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5_+0x56) [0x7ffaa5a13ad6]
[bt] (9) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt6thread5_ImplISt12_Bind_simpleIFSt8functionIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEES8_EEE6_M_runEv+0x3b) [0x7ffaa5a10d3b]

[20:02:42] /workspace/dmlc-core/include/dmlc/logging.h:308: [20:02:42] src/engine/./threaded_engine.h:347: [20:02:42] src/storage/./pooled_storage_manager.h:102: cudaMalloc failed: out of memory

Stack trace returned 10 entries:
[bt] (0) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7ffaa471293c]
[bt] (1) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet7storage23GPUPooledStorageManager5AllocEm+0x1d8) [0x7ffaa5efd6a8]
[bt] (2) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet11StorageImpl5AllocEmNS_7ContextE+0x61) [0x7ffaa5f009f1]
[bt] (3) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNK5mxnet7NDArray13CheckAndAllocEv+0xf6) [0x7ffaa4a4ba06]
[bt] (4) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6common22SetupDefaultBlobsInOutERKSt6vectorINS_7NDArrayESaIS2_EES6_PS1_INS_5TBlobESaIS7_EESA_PS4_SB_SB_SB_PSt13unordered_mapIjjSt4hashIjESt8equal_toIjESaISt4pairIKjjEEERKS1_IjSaIjEE+0x38d) [0x7ffaa5a9143d]
[bt] (5) /workspace/python/mxnet/../../lib/libmxnet.so(_ZZN5mxnet10imperative12PushFComputeERKSt8functionIFvRKN4nnvm9NodeAttrsERKNS_9OpContextERKSt6vectorINS_5TBlobESaISA_EERKS9_INS_9OpReqTypeESaISF_EESE_EEPKNS2_2OpES5_RKNS_7ContextERKS9_IPNS_6engine3VarESaISW_EES10_RKS9_INS_8ResourceESaIS11_EERKS9_IPNS_7NDArrayESaIS17_EES1B_RKS9_IjSaIjEESJ_ENKUlNS_10RunContextENSU_18CallbackOnCompleteEE_clES1G_S1H_+0x1e8) [0x7ffaa5a91858]
[bt] (6) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x112) [0x7ffaa5a0f7a2]
[bt] (7) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7ffaa5a138d3]
[bt] (8) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5_+0x56) [0x7ffaa5a13ad6]
[bt] (9) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt6thread5_ImplISt12_Bind_simpleIFSt8functionIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEES8_EEE6_M_runEv+0x3b) [0x7ffaa5a10d3b]

A fatal error occurred in asynchronous engine operation. If you do not know what caused this error, you can try set environment variable MXNET_ENGINE_TYPE to NaiveEngine and run with debugger (i.e. gdb). This will force all operations to be synchronous and backtrace will give you the series of calls that lead to this error. Remember to set MXNET_ENGINE_TYPE back to empty after debugging.

Stack trace returned 8 entries:
[bt] (0) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7ffaa471293c]
[bt] (1) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x40f) [0x7ffaa5a0fa9f]
[bt] (2) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7ffaa5a138d3]
[bt] (3) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5_+0x56) [0x7ffaa5a13ad6]
[bt] (4) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt6thread5_ImplISt12_Bind_simpleIFSt8functionIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEES8_EEE6_M_runEv+0x3b) [0x7ffaa5a10d3b]
[bt] (5) /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb1a60) [0x7ffab1265a60]
[bt] (6) /lib/x86_64-linux-gnu/libpthread.so.0(+0x8184) [0x7ffab8b79184]
[bt] (7) /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ffab88a5ffd]

terminate called after throwing an instance of 'dmlc::Error'
  what():  [20:02:42] src/engine/./threaded_engine.h:347: [20:02:42] src/storage/./pooled_storage_manager.h:102: cudaMalloc failed: out of memory

Stack trace returned 10 entries:
[bt] (0) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7ffaa471293c]
[bt] (1) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet7storage23GPUPooledStorageManager5AllocEm+0x1d8) [0x7ffaa5efd6a8]
[bt] (2) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet11StorageImpl5AllocEmNS_7ContextE+0x61) [0x7ffaa5f009f1]
[bt] (3) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNK5mxnet7NDArray13CheckAndAllocEv+0xf6) [0x7ffaa4a4ba06]
[bt] (4) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6common22SetupDefaultBlobsInOutERKSt6vectorINS_7NDArrayESaIS2_EES6_PS1_INS_5TBlobESaIS7_EESA_PS4_SB_SB_SB_PSt13unordered_mapIjjSt4hashIjESt8equal_toIjESaISt4pairIKjjEEERKS1_IjSaIjEE+0x38d) [0x7ffaa5a9143d]
[bt] (5) /workspace/python/mxnet/../../lib/libmxnet.so(_ZZN5mxnet10imperative12PushFComputeERKSt8functionIFvRKN4nnvm9NodeAttrsERKNS_9OpContextERKSt6vectorINS_5TBlobESaISA_EERKS9_INS_9OpReqTypeESaISF_EESE_EEPKNS2_2OpES5_RKNS_7ContextERKS9_IPNS_6engine3VarESaISW_EES10_RKS9_INS_8ResourceESaIS11_EERKS9_IPNS_7NDArrayESaIS17_EES1B_RKS9_IjSaIjEESJ_ENKUlNS_10RunContextENSU_18CallbackOnCompleteEE_clES1G_S1H_+0x1e8) [0x7ffaa5a91858]
[bt] (6) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x112) [0x7ffaa5a0f7a2]
[bt] (7) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7ffaa5a138d3]
[bt] (8) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5_+0x56) [0x7ffaa5a13ad6]
[bt] (9) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt6thread5_ImplISt12_Bind_simpleIFSt8functionIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEES8_EEE6_M_runEv+0x3b) [0x7ffaa5a10d3b]

A fatal error occurred in asynchronous engine operation. If you do not know what caused this error, you can try set environment variable MXNET_ENGINE_TYPE to NaiveEngine and run with debugger (i.e. gdb). This will force all operations to be synchronous and backtrace will give you the series of calls that lead to this error. Remember to set MXNET_ENGINE_TYPE back to empty after debugging.

Stack trace returned 8 entries:
[bt] (0) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7ffaa471293c]
[bt] (1) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x40f) [0x7ffaa5a0fa9f]
[bt] (2) /workspace/python/mxnet/../../lib/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7ffaa5a138d3]
[bt] (3) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5_+0x56) [0x7ffaa5a13ad6]
[bt] (4) /workspace/python/mxnet/../../lib/libmxnet.so(_ZNSt6thread5_ImplISt12_Bind_simpleIFSt8functionIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEES8_EEE6_M_runEv+0x3b) [0x7ffaa5a10d3b]
[bt] (5) /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb1a60) [0x7ffab1265a60]
[bt] (6) /lib/x86_64-linux-gnu/libpthread.so.0(+0x8184) [0x7ffab8b79184]
[bt] (7) /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ffab88a5ffd]

Environment info
Operating System: Ubuntu
MXNet version:
Commit hashes for:
PR 8199 build that failed:
7771ee844939126d3f0d50aa254359d1325a8ae8
Build 491:
06806f542e0727c009a5cba0d3637d9eeaf5695f
Build 493:
63e5ed2041076f57ec5d45e940bbb5f8c3de090a
Minimum reproducible example
Build and run unit tests
Steps to reproduce
Build and run unit tests

One more build failure on master because of this bug. Check https://builds.apache.org/blue/organizations/jenkins/incubator-mxnet/detail/master/510/pipeline/
@piiswrong We either have to fix this or temporarily disable this test if this failure is not an indication of a big enough problem. It is not possible to have stable builds unless this and few other bugs like this are fixed.

This test has been disabled in the master branch now. No more builds will break because of this test.
We now need to discuss if the absence of this test if a blocker for cutting the release candidate for 0.12.0. Unless someone confirms in this ticket that it is not a blocker, I'll assume it is. Please let me know.

Ran this test 10k times and was not able reproduce the error. Will be opening PR for re-enabling this test.

PR - https://github.com/apache/incubator-mxnet/pull/11437


Cleanup DefaultCachedClasspathTransformer of instrumentation logic

Since we now do instrumentation with artifact transforms.
The only thing in DefaultCachedClasspathTransformer that gives some hint of instrumentation is InstrumentationTypeRegistry that is passed as a parameter to a transform factory. But this type registry should be  hidden with changes in https://github.com/gradle/gradle/pull/29959

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

Pull Request Feedback (Trigger) (Check)

So it looks like we're only using CachedClasspathTransformer to do copies and groovy script name rewrites, and everything else is done by the actual instrumentation transform? 🎉

Yes, that is the case. And this cleanup hopefully makes it clearer.
Note: For buildscript we use execution engine directly instead of artifact transforms.


Font too small in Windows

Thanks again for the great tool. While using it on a laptop, I have noticed that the small font size used in the interface is causing too much eye strain. I've compared, for example, the menu size to a few other apps, i.e.:

or

Could this be increased to a comfortable size, please?
I see in the screenshots that in Linux the size seems quite fine so it might be that the font in Windows is a bit weird.

I can't reproduce this with Windows 10 and Windows 11, all menu bars and font sizes are correct
You can however create a new theme from the current one and set a custom font size

Does this work for you?

Thanks for the feedback! I see what's going on now.
Since the laptop has a HD display, it is set to the recommended scaling of 125% (System > Display > Scale).
The other apps resize the fonts appropriately but Gittyup stays at the default value.

Does this work for you?

As a workaround, yes, this also works. Thank you!

I am experiencing the same but on Fedora.

@kaushalyap, that looks correct.

@kaushalyap, that looks correct. For comparison, what size should the text be?

Nope file menus and side bar fonts are small, font on those sections should be bit bigger at least to the size of font in center section.

@kaushalyap, you genuinely think that they should be as big as the center text...?

@kaushalyap, you genuinely think that they should be as big as the center text...?

Yes and then the center section should become bigger than that to make things correctly proportional.

Just to echo that on a 27" 4k monitor the text is really tiny in the commit history, recents, top panels too (at 125% scaling in W11).
In Rstudio IDE, zooming anywhere zooms the editor and the side panels/buttons/etc, but not the menu bar at the top. This seems to work pretty well, and I wonder if similar behaviour might strike a nice balance here?
For now, I will make a custom theme which meets my requirements. I copied the dark theme and then added the below to the bottom of the file, then restarted. this seems to work (thank you for the instructions above - I just picked a random font for now to make it work):
-- font size
theme["font"] = {
	family = "Arial",
	size = "18"
}

Just gave this a try. I like the concept, but the interface is way too small. Borderline unusable. Tested on Arch and Ubuntu. Please add a global UI scaling option for those of us who are using HiDPI monitors. Thanks!

It would probably better to open the new theme.lua file with the default text editor... or at least the add "Locate the file with the file manager" to the editor. Since the theme only applies when restarting the app, I have to keep re-open the options and switch to the Window tab and select "Edit current theme" again and again.

Just to echo that on a 27" 4k monitor the text is really tiny in the commit history, recents, top panels too (at 125% scaling in W11).

-- font size
theme["font"] = {
	family = "Arial",
	size = "18"
}

Is there any way to increase the item's height, too? I have set "20" for font, but it seems that item height doesn't grow enough. Lines look crammed.

It seems that the font size is incorrect (too small) if installed from Flatpak, but correct if installed from AUR (Arch User Repository).

https://github.com/Murmele/Gittyup/issues/311#issuecomment-2099379295

@HubKing, might be best to file that at https://github.com/flathub/com.github.Murmele.Gittyup/issues/new then.

https://github.com/Murmele/Gittyup/issues/311#issuecomment-2099323937

@HubKing, indeed, they should adapt to the text size. https://forum.qt.io/post/270367 might be relevant here.


New json interface

What was wrong?
Solidity has a new --standard-json interface. See: https://github.com/pipermerriam/py-solc/issues/22
How was it fixed?
This is in progress...
Cute Animal Picture

Let me know when this is ready for me to review/merge.

Alright, I am not going to fuss with this any more. I am fairly happy with this, and it is probably worthwhile to move on.


node: allow node modification after creation

After node creation, the user should be able to modify:

the RAM size
the number of CPUs
the IP address

To do: create a new command editnode and needed logic.

Final command version in 0471962b9200d764eaed91b7ed1fc5fbadae3eec.


Follow standard practice for modules with ArgumentParser

I'd rather keep the argparse part as a separated function, to make it testable independently from dpanonymize. See below for how the test has been separated in the test code.
https://github.com/AMP-SCZ/dpanonymize/blob/7928e687e649ae1fcf9e7e1c44530a97a2cb5c9d/tests/scripts/test_dpanon.py#L136-L147

That test fails! You haven't updated that test after removing argument from parse_args().

@tashrifbillah Thanks. I'll be working on it soon.

I'd rather keep the argparse part as a separated function

Undid my change, thanks.

That test fails! You haven't updated that test after removing argument from parse_args().

fixed


Added option for custom environment variables for PostgreSQL.

This commit enables the user to specify additional environment
variables in the stable/postgres chart.
What this PR does / why we need it:
This is especially important for custom Postgres images which might have different environment variables for different options or for enabling additional features.
Special notes for your reviewer:
Nothing special here, really, the same pattern for adding variables is also used in other charts.

@bokysan please bump the chart version

Version bumped.

Hello gentlemen,
There were some comments from @cpanato, which were resolved. We had a discussion about raising a postgres version with @desaintmartin, which I would leave as is (and maybe fix the commit message).
What do we do about this pull request now? Any possibility of merging it?

/lgtm

/lgtm cancel

@bokysan talking with @desaintmartin the bump the Postgres version will be good in another PR. it is just my opinion as re-thinking this bump. Since this is a bump to a major version of Postgres maybe will be good to have in another pr

I have rolled back the PostgreSQL version upgrade change.
I'll open a separate PR once this one gets merged.

@bokysan rebase and lets try to get this merged!

@bokysan rebase and lets try to get this merged!

I'm sorry, I don't follow -- this has been rebased into one commit from the start and with every change we did. Everything is in commit 19b6e55751a2c12fce08f9a3be9820211ab0f19d. Do you need me to do anything else?

@bokysan you need to rebase and then bump the chart version

@bokysan you need to rebase
I've rebased everything ontho charts:master.

and then bump the chart version
Version has already been bumped to 1.0.0 since Sep 6, 2018 at your request on that day.

Hi,
@desaintmartin, @cpanato. I've reverted the rebase onto master. As we apparently don't understand each other, could you kindly spell it out for me (or direct me to a web page) what exactly you need me to do to get this merged?
Thank you,
B

You should do a "rebase", i.e
git fetch upstream && git rebase upstream/master && git push -f origin master, upstream being this repository and origin your fork.
https://git-scm.com/book/en/v2/Git-Branching-Rebasing
The goal is for your branch to be up-to-date AND to have only your changes in this PR, nothing else.

yeah, you should do a rebase, usually I add the -i to make interactive git rebase -i upstream/master

Ok, done. I don't know how I was able to pull all the changes in the last time.

/ok-to-test

/lgtm


Which versions of node do you support?

Running with node 6.3 doesn't work.
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
npm ERR! Darwin 15.3.0
npm ERR! argv "/usr/local/bin/iojs" "/usr/local/bin/npm" "i"
npm ERR! node v6.3.0
npm ERR! npm  v3.10.3
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the ref package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs ref
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls ref
npm ERR! There is likely additional logging output above.

I noticed it also doesn't build with node LTS version 4.2. https://nodejs.org/en/blog/release/v4.2.0/

Looks like it's working now.


Don't insert extra newlines in highlight command

In line with output from other commands.

The output from the highlight command may have addtionial newlines inserted if the terminal has insufficient columns for the sake of pretty printing. As such the information for a single highlight group may span multiple lines depending on the size of the terminal, regardless if the output is being captured by redir or execute().
This not in line with the output from other commands and means extra care has to be taken when parsing the output of the highlight command.
The following showcases the descrepancy counting the lines in the output from the :highlight command with a low number of columns vs the number the currernt terminal actually has.
$ cat highlights.vim
echom len(split(execute('highlight'), '\n'))

let  columns = &columns
let &columns = 10

echom len(split(execute('highlight'), '\n'))

let &columns = columns

Without this patch.
$ vim -u NONE -S highlights.vim -c messages

Messages maintainer: Mike Williams<EMAIL_ADDRESS>53
183
Press ENTER or type command to continue

With this patch.
$ vim -u NONE -S highlights.vim -c messages

Messages maintainer: Bram Moolenaar<EMAIL_ADDRESS>51
51
Press ENTER or type command to continue

I see some tests failed due to having an extra space in the output. I didn't see these these on my machine as I wasn't building the GUI.
Removing the case I've modified entirely would likely make this pass however I found by doing that I triggered other failures. As an example with a terminal 80 columns wide the cursorline test fail as the capturing of the output seems to result in the item after the line wraps getting concatenated without spacing.
E.G. This output
CursorLineNr   xxx term=bold cterm=underline ctermfg=11 ctermbg=0 gui=bold guifg
=Yellow            guibg=Black

Gets captured as
CursorLineNr term=bold cterm=underline ctermfg=11 ctermbg=0 gui=bold guifg=Yello
wguibg=Black

The main use for the ":highlight" command is to list the values in a nice way.
Removing the NL messes this up.
You can use synIDattr() if you want to get specific highlight attribute values.
Or you can delete a newline followed by white space in the execute() output.
No need to remove the pretty printing.