What about DNS from a Windows DC?

Whilst BIND is commonly used in cloud compute environments and on the wider internet, within many corporate environments, the DNS function is built into the Windows Domain Controller. Is it worth extending the implementation guide to demonstrate how a converged network implementation could be deployed?

Yes and these implementation guides are intended to be living documents so more info can be added later.
See also #8 -- the wiki gives examples for four different DNS servers including Windows.

My feeling is no.  Let's keep this simple and not add information about Windows DC, Tiny DNS, etc.  As a system administrator who has worked with Linux systems for a while, it's my feeling that you need to show me how to do something in BIND (or Windows DC, or Tiny DNS, etc.).  All I need is one worked example.  How I enter TXT records, etc. may be different on my specific system, but I know that.  What I need is a clear example that shows me a working DNS-SD example, because I probably have not had to do much with that before.  I need a sort of a 'hello world' example.  I can take it from there.
Mike, you have a good point about a corporate environment, but what I am concerned about is that some people are using a Windows DC.  Others are using clustered Linux servers, others are using [insert corporate solution here].  If we think it is important to have a Windows DC example, I would say create another how-to.  Keep this one simple, easy to follow, and without any branches that distract someone who is just trying to get something (anything at all?) working.
I think these how-to guides need to be bare bones.  Step-by-step, do these things, and you get this result.  That's it.  My two cents.  (I know - said with my usual American bull-in-a-china-shop approach.)  Do you guys disagree?  Okay to close this issue?

Whatever is decided on this it would be good to have the examples from the wiki somewhere (#8) -- we don't want to keep maintaining the wiki definitely. Hence suggestion for appendices.

That is a good point Pete.  Yes, if we can lift that stuff and put it into appendices in this document, that would be useful.

See #8


Consistent treatment of coordinates

We make implicit assumptions about the coordinate frame, in particular for source centers. When no WCS is set in the observed frame, they must be in pixel coordinates, but if a WCS is set, they may be in pixel coordinates or in sky coordinates. We assume it's the latter, but that may not be true and lead to confusions, e.g. this:
Originally posted by @charlotteaward in https://github.com/pmelchior/scarlet2/issues/47#issuecomment-2103497628
As we already depend on astropy for the WCS transformation, it would make sense to allow positions to be given as SkyCoord (in which case it will be transformed according to a WCS) or a jnp.array (in which case we assume it to be in pixel coordinates).

Quick note that we also need to adjust plot.py, which assumes pixel coordinates for sources when adding labels!

After more conversation about this, we should also make sure that all operations involving the user can be made in either all WCS or all pixel coordinates. This is particularly important for multi-observation cases.
I suggest that we define all model coordinates in the frame of the sky. That means that center coordinates would be in RA/Dec, with step sizes in, say, arcsec; same for sizes of radial profiles. We can make use of the astropy.units framework to automate conversions.
This will provide one important advantage: when a user defines the model frame, they can now simply say it's an abstract  piece of sky, with a center and a size. From that perspective, it's not an image that is tacked onto the sky, which has routinely led to difficulties with new users. We, internally, compute images, but they represent that sky, so it makes sense to assume the coordinates of the sky, not of an image of the sky.
For this to work, we need to allow for two modes:

Everything is in pixels: A trivial WCS that implements the identity mapping will suffice for that.
Everything is in sky: our method Frame.from_observations already supports that mode. I'd like to add a method that constructs a WCS from center, size, and pixel scale.

To further clarify our approach, I think we should allow the definition of model properties and parameters in sky coordinates, e.g.:
import astropy.units as u

center = astropy.coordinates.SkyCoord(ra, dec)
size = 1*u.arcsec
morph = GaussianMorphology(center, size)

# using the parameter framework from PR #56
parameters += Parameter(morph.center, stepsize=0.01*u.arcsec)

For fitting/sampling we now have two choices:

Convert sky to pixels, optimize in pixels, and then convert back. This could look like Scene._constraint_replace, run only at the beginning or the end of the optimization. This is straightforward, and we're doing this already in parts in the initialization code, but we have to catch instances like Parameter(morph.center, prior=numpyro.dist.Normal(morph.center, 1*u.arcsec), i.e. when the constraints or priors are specified in sky.
Optimize in sky coordinates. Doing so would keep parameter values and constraint/priors aligned, but we have to make coordinates and their transformations differentiable.

Option 2 is much more work for very little gain. It might even be worse (try to optimize at both sides of RA=360). So, the trick will be to catch all instances of sky coordinates, convert them consistently to get into pixels for the optimizer/sampler, and then go back to present sky coordinates to the user.
There's a wrinkle. While Numpyro does not check arguments when declaring distributions, so you can create numpyro.dist.Normal(loc=SkyCoord(ra=10, dec=0, unit='deg'), scale=1*u.arcsec), it can't evaluate these distributions because it expects simple scalars or jnp.arrays. This may not be a problem because we convert these into pixel-based values before, right? Yes, but we have to find all occurrences. So, I suggest that when doing the coordinate transformations of Parameter fields, we should check all attributes for astropy units or coordinates, e.g.
for attrib in dir(parameter.prior):
   if isinstance(attrib, (u.Quantity, astropy.coordinates.SkyCoord)):
      # do some conversion, remember the name and hopefully recreate a numpyro dist with these converted args
       ...

And some more clarification on how we can best do this: As we will always compute models and their gradients in the pixel space, it's easiest to convert coordinates and distances at init time.
That means, a user can write:
center = SkyCoord(ra, dec)
PointSource(center, spectrum)

as long as we do the coordinate conversion to pixel of the model frame in PointSource.__init__ (or the method that is being called in __init__ to set the centers).
This means that we create an interface for the user to specify sky coordinates, and we'll immediately translate to pixels. Doing that just takes a menial task off the user, and ensures that the transformation is correctly applied (it's very easy to do that wrong, we've all done it...)
I think this provides a clear model definition: scarlet models describe a cube on the sky, whose location is specified by the model frame WCS. We simply make it easier for the user to define the model.
Leaves the Parameters. We can exploit that there is a custom __iadd__ for adding a Parameter instance to the Parameters list. At this point, we can modify the Parameter instance so that all fields holding sky coordinates and astropy units are converted to model pixels (with the code sketched above).


perf(item): improves performance of sliding item

This PR should improves dramatically the performance in low end devices:
BEFORE:

AFTER:

Fixes: #

Using new NativeRafDebouncer
Events are not zone wrapped unless strictly necessary

Further information:
BEFORE:

AFTER:

LGTM 👍


Normalize type references before relating them

This PR changes isRelatedTo to normalize type references before relating. This in particular means that deferred type references are be turned into equivalent non-deferred type references before being compared.
Fixes #33872.

@typescript-bot test this
@typescript-bot user test this
@typescript-bot run dt
@typescript-bot perf test this

RWC tests have a few error baseline changes that I think are fine. Community tests suite changes are preexisting conditions. DT tests suites are clean. No changes in performance. Overall, I think this one is good to do.

@typescript-bot test this
@typescript-bot user test this
@typescript-bot run dt
@typescript-bot perf test this

Looking at RWC, it looks like tuple aliases still aren't preserved in errors - is there an elaboration codepath the most recent change missed? (The elaboration in property relations, maybe?)

Actually, we're preserving type aliases in more situations than we did previously.


filtering messages per map

knAllEdgeRealTimeService must:

enhance broadcaasted messages with mapId
check in filterBroadcasting if the map is same as ours

we introduced sessionID for filtering that will support in the future several sessions over the same map

solve problem with backend deepassign module, how to integrate it and our fix in it for null values

@mprinc : When you finish this backend ingetration on server, close this issue

@mprinc : Have you integrated deep-assign on server so that this can be closed?

not-sure anymore, i guess I did but better resend me zip by email again

not-sure anymore, i guess I did but better resend me zip by email again

sent to email. Confirm and close.
can be tested by creation of new map and seeing if it is created and accessible with visible rootNode and without crash of server

Reupdated, restarted server, tested, works fine with creation without crashing and shows node in the map


ES/Redis AWS Services - Service version in binding

Modify the binding credentials provided by customers so that it reflects the last know version of the service at the time of binding.  Since the service/plans no longer contain the version, this is the most direct way for a customer to know what version their service instance is on.
Acceptance Criteria

[ ] Making sure that service instance engine versions are included in binding credentials so customers can easily find what version of the service they are running for Redis

Security considerations
n/a
Implementation sketch

[ ] Make changes to the broker to include the version of the service in the binding credentials.

https://github.com/cloud-gov/aws-broker/pull/126


Remove the option run tasks every time

It doesn't make much sense to "migrate" a task more than once. Fixes issue #2

:+1:


Run sim tests on self hosted runner

Motivation
Github runners are not powerful enough to handle sim tests reliably. We want to be sure that sim tests are run with enough resources
Description
Run sim tests on self hosted runner

Putting as draft after some experiments:
Self hosted runners operate differently: they don't start from a clean slate but just run on bare metal and do not clean up. Instead Github self hosted runners run on fresh VMs that are destroyed after the fact.
From an offline exchange with Pari:

L: When using Github self hosted runners, every registered runner can run exactly 1 job at a time? Do you know if that can be customized? In your usage of it with kurtosis is there any issue with clean-up after the fact? Being used to Github own runners where you get a fresh environment every time that is destroyed after the fact, using self hosted has some challenges
P: yeah so you can't customize it - we had the same issue on our system. So the fix is to register multiple runners on the same physical host so you "hack" it in. When no jobs are running, nothing changes about the usage anyway. The correct way to do it would be to use something like:

Actuated: https://blog.alexellis.io/blazing-fast-ci-with-microvms/
Kubernetes with the autoscaling option to spin up more runners when there are pending jobs
Amazon's free autoscaling service for github runners
But in practice, Github makes this hard so incentivize using their runner services. I have an explicit job that cleans up kurtosis post run irrespective of fail/success - so i haven't had any stale file issues there.

IMO we should not run every sim test on the self hosted runner, but instead do:

Run on Github runners on commit a light version of the sim tests that are okay with low power machines. Sim tests have shown to be very stable with correct business logic
Run on self hosted runners only on demand for key commits on key PRs + on merge to master + before release. This less frequent tests could do much longer runs with more nodes.

This approach makes sense because the workflow must be different:

Requires more setup phase
Must assume another test is running in the background, so ports, paths must not conflict
Requires a tear-down phase

Closing for https://github.com/ChainSafe/lodestar/issues/4758

There's another option, running sim tests on AWS Codebuild runners.  I have implemented AWS Codebuild runners for Github action in the past just to solve this issue of having more resources for Jobs.
With AWS Codebuild we get clean environments every time, logs streamed straight to Github actions and machines:
up to 72 x86_64 vCPUs
up to 255 GB RAM
up to 8 ARM64 vCPUs
GPU hardware devices
With this setup, we'll only use Github managed runners to stream the logs and orchestrate the process, Codebuild containers will do the heavy lifting.

@Faithtosin The thing is we don't have evidence yet that the current simulation tests fail due to resource exhaustion. From what I've seen it's business logic errors.


feat: implement new hook - useScreenOrientation

What new hook does?
Checks if screen is in portrait or landscape orientation and automatically re-renders on orientation change.
Checklist

[x] Have you read contribution guideline?
[x] Does the code have comments in hard-to-understand areas?
[x] Is there an existing issue for this PR?

#33

[x] Have the files been linted and formatted?
[x] Have the docs been updated?
[x] Have the tests been added to cover new hook?
[x] Have you run the tests locally to confirm they pass?

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Refresh documentation

Coverage remained the same at 93.812% when pulling d9aec35841aedd150dc94436ee5f5b1bba3e7a4b on mprimi:GENIE-446-v4-documentation into 28d5ce969e4ef83bf468da08efe356345ba6fec2 on Netflix:master.


Text to SQL microservice

Description
This microservice introduces text to SQL features in OPEA. Users can use natural language to do QnA/Conversations with the SQL-based database. (Currently, PostgreSQL is supported).
Issues
List the issue or RFC link this PR is working on. If there is no such link, please mark it as n/a.
630
Type of change
List the type of change like below. Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would break existing design and interface)
[ ] Others (enhancement, documentation, validation, etc.)

Dependencies
List the newly introduced 3rd party dependency if exists.

sqlalchemy

Tests
Describe the tests that you ran to verify your changes.
Created a new test case for end-to-end testing of the microservices.

@yogeshmpandey,
please add the following words into code spell ignore file.

Add skip format here,
https://github.com/opea-project/GenAIComps/blob/2159f9ad000211cf44546c65f019b074df248a7e/pyproject.toml#L12


2-pass Rate Control from Tim

I did a preliminary review while this was on pastebin.
More comments welcome.
crav1e will need to be updated.

Coverage decreased (-1.9%) to 80.917% when pulling fa1bc69f32540b1458246b257de9460ffeee3836 on dwbuiten:2pass into 7439600e3cd4e27d74799c220c4475e63cb3d701 on xiph:master.

It seems '--first-pass' and '--second-pass' require arguments (seems 'true' worked), but I was expecting them to be switches (like '--low_latency').  What is the expected behavior for these?

I'm at the meetup, I'll try to see if there something we can do that is better than this +__+

We turn clippy on and off per lint, so if there's something that's really dumb we can just turn it off.

Most of its suggestions are kinda OK. Putting a _ in the magic and e.g. 0x7FFFFFFF -> 0x7FFF_FFFF seems real silly.

Looks OK. We already have bit serialization code used for the uncompressed header, it might be nice to use that. But meh.

Which parts?

I think potentially the idea of the two options is to allow x many passes, by both having a pass input and output file at the same time.

Merging as-is right now then with a go-ahead from IRC. The CLI options aren't API, so we can revisit them if need be.


[Backoffice] Update in page pagination UIs vs functionalities

Enhance pagination UI in Location page

Use 'Enter' click to submit the page change
https://github.com/user-attachments/assets/b8ad93a4-4fbe-4ea7-9f28-4e6a0dab1540

Hi @HnKnA, I’ve been reading through your implementation, and I think it's coming along well. I have a suggestion regarding the pagination controls that you might want to consider:
Currently, there are a few states and their corresponding handlers (like itemsPerPage with onItemsPerPageChange, and goToPage with onGoToPageChange/onGoToPageSubmit). These seem to be tightly coupled and should always be used together.
To reduce the risk of mismatches, I suggest grouping related states and handlers into a single prop, such as a paginationControls object. This would ensure that the states and handlers are always passed together, improving consistency.
For example:
paginationControls: {
  itemsPerPage: {
    value: itemsPerPage,
    onChange: onItemsPerPageChange,
  },
  goToPage: {
    value: goToPage,
    onChange: onGoToPageChange,
    onSubmit: onGoToPageSubmit,
  }
}

Alternatively, if we need to keep itemsPerPage and goToPage separate, we could consider structuring them as distinct control props (itemsPerPageControl and goToPageControl). How do you think?

Hi @HnKnA, I’ve been reading through your implementation, and I think it's coming along well. I have a suggestion regarding the pagination controls that you might want to consider:
Currently, we have states and their handlers (e.g., itemsPerPage with onItemsPerPageChange, and goToPage with onGoToPageChange/onGoToPageSubmit) that seem tightly coupled and are often used together. To ensure consistency and reduce the risk of mismatches, I suggest grouping related states and handlers into a single prop, such as a paginationControls object. This would make it clear that these values should always be passed together.
For example:
paginationControls?: {
  itemsPerPage: {
    value: itemsPerPage,
    onChange: onItemsPerPageChange,
  },
  goToPage: {
    value: goToPage,
    onChange: onGoToPageChange,
    onSubmit: onGoToPageSubmit,
  }
}

Alternatively, if we need to keep itemsPerPage and goToPage separate, we could consider structuring them as distinct control props (itemsPerPageControl and goToPageControl). How do you think?

I prefer the approach of grouping necessary variables, and I will configure them today.


App seems to "stop" when device sleeps even with BG mode enabled.

We've been testing our app and have noticed something odd. If the app is running and the device is left to go into sleep mode, the app continues to work for an indeterminate period of time but then just "stops". When we wake the device the app continues where it left off.
We have logging in the application that shows background-mode being activated when the device sleeps and then being deactivated when the device wakes.
This problem only affects Android, iOS works fine.

Closing this issue as after extensive investigation, the problem was actually caused by a bug in Android whereby if the device goes to sleep and the wifi connection drops, the device will not pick up the wifi connection again until is it brought out of sleep mode.


Deploying to AWS errors

I'm trying to get the Apollo example to run on AWS and its failing.
My package.json
{
"name": "apollo",
"version": "1.0.0",
"scripts": {
"dev": "next",
"build": "next build",
"start": "next start -p 8081"
},
"cacheDirectories": [
"nextjs/node_modules"
],
"dependencies": {
"apollo-client": "^0.8.1",
"es6-promise": "^4.0.5",
"graphql": "^0.9.1",
"graphql-tag": "^1.2.3",
"isomorphic-fetch": "^2.2.1",
"next": "^2.0.0-beta.20",
"react-apollo": "^0.9.0",
"react-redux": "^5.0.2",
"redux": "^3.6.0",
"redux-thunk": "^2.1.0"
},
"author": "",
"license": "ISC"
}
In the above I changed the following:

Added isomorphic-fetch and es6-promise packages (even though it worked locally) or it would fail. Seemed to fix that error.
Added cacheDirectories (from deployment Heroku repo). Didn't see any other advice that aplpied to this case.
Changed the port in the start to run on 8081 (AWS Beanstalk uses this)
Use https://codeship.com to run npm install and npm run build before hand so it should be built correctly.

Everything runs perfectly on my local box but fails when trying to run on AWS :(
AWS Container options:
Proxy server: nginx
Node version: 6.9.1
Node command: npm start
AWS Environment variables:
NODE_ENV: production
PORT: 8081
Here is the AWS error log:

/var/log/nodejs/nodejs.log
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/var/app/current/.next/dist/pages/_error.js:7:23)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3) code: 'MODULE_NOT_FOUND' }

{ Error: Cannot find module '/home/rof/src/github.com/abelovic/apollo/node_modules/next/node_modules/babel-runtime/core-js/object/get-prototype-of'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (/var/app/current/.next/dist/pages/_error.js:7:23)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3) code: 'MODULE_NOT_FOUND' }

<EMAIL_ADDRESS>start /var/app/current
next start -p 8081

Ready on http://localhost:8081

<EMAIL_ADDRESS>start /var/app/current
next start -p 8081

Ready on http://localhost:8081
{ Error: Cannot find module '/home/rof/src/github.com/abelovic/apollo/node_modules/next/node_modules/react/react.js'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (/var/app/current/.next/dist/pages/index.js:7:14)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3) code: 'MODULE_NOT_FOUND' }
{ Error: Cannot find module '/home/rof/src/github.com/abelovic/apollo/node_modules/next/node_modules/babel-runtime/core-js/object/get-prototype-of'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (/var/app/current/.next/dist/pages/_error.js:7:23)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3) code: 'MODULE_NOT_FOUND' }
{ Error: Cannot find module '/home/rof/src/github.com/abelovic/apollo/node_modules/next/node_modules/babel-runtime/core-js/object/get-prototype-of'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (/var/app/current/.next/dist/pages/_error.js:7:23)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3) code: 'MODULE_NOT_FOUND' }

I get an internal server error when trying to run the site...
Any help/suggestions would be greatly appreciated!

Seems like you don't have node_modules available when the Next.js app is started.

@arunoda Thanks for your response - I think you were on the right track. To test this, I downloaded the zip from S3 and ran it locally and I get the following error:
"next" is not recognized as an internal or external command, operable program or batch file.
What is interesting is that next is in my node_modules folder and the .next folder exists as you would expect it. If I run "npm install next" again it works correctly (only installing next and nothing else).
What I am doing is running npm install and then npm run build in (codeship) and then copying everything over to AWS. Can you think of a reason why only the next module does not install correctly? Every other module works fine and I only have to reinstall next for it to work :/
I guess I could try to do the npm install/next build with ebextensions config file in AWS but I would rather do it in codeship so I can catch errors (with my continuous deploys) before trying to move it out to AWS
Thanks again for your help!

Yeah. I have set the following in the container options in the AWS console configuration:
Node command:
npm run start
Command to start the Node.js application. If an empty string is specified, app.js is used, then server.js, then "npm start" in that order.
...and from my json package above I specify the port (because that's what nginx is configured to listen on in EB):
...
"start": "npm run start -p 8081"
....
Other AWS settings I have:
Container options:
Proxy server: nginx (default)
Node version: 6.9.1 (latest AWS supports which I match in my build)
Gzip Compression: true (default)
Environment Properties (not sure if I needed these but set them anyways):
NODE_ENV: production
PORT: 8081

Possible dupe of #198 and by extension #360?
The build path /var/app/current doesn't match the runtime path /home/rof/src/github.com/abelovic/apollo, so the output of absolute paths by webpack may cause it to fail. Rebuilding on AWS would fix up the absolute paths to match - I guess that's why you're seeing that behaviour. :)

@abelovic I am getting the same error and it was working find a few days ago. Have you found the issue why this is happening?


DRILL-5822: The query with "SELECT *" with "ORDER BY" clause and `planner.slice_t…

…arget`=1 doesn't preserve column order
Issue: Columns ordering doesn't preserve for the star query with sorting when this is planned into multiple fragments.
Solution: The commit for DRILL-847 is oudated. There is no need to canonicalize the batch or container since RecordBatchLoader swallows the "schema change" for now if two batches have different column ordering.

@paul-rogers Could you please review this PR? You can find a short description here or more detailed - in the jira ticket DRILL-5822.


Running the fastlane tests will cause one of the fixture Xcode projects to be modified

Run
bundle exec rspec

and run
git diff

This should be fixed by either not changing the project, or reverting those changes

@KrauseFx Can you see if the fix above would be okay?

Awesome, thanks @pav1790


Export PDF example extent corrections

Fixes #9460 and #9665
Replace calculateExtent and fit with getResolution and setResolution as the former do not produce the desired result when the view is rotated.
Export the viewport instead of the map div (which doesn't resize) and specify the width and height in the export options
This is a minimal fix for the two issues.  Further enhancement including a fallback to export layer canvases where the browser doesn't support html-to-image could be done separately if necessary.

As far as I can tell, the dpi are not correct any more after your changes. Compare the generated PDF from https://openlayers.org/en/master/examples/export-pdf.html and https://1808-4723248-gh.circle-artifacts.com/0/examples/export-pdf.html, without changing the center, zoom or rotation.

As far as I can tell, the dpi are not correct any more after your changes. Compare the generated PDF from https://openlayers.org/en/master/examples/export-pdf.html and https://1808-4723248-gh.circle-artifacts.com/0/examples/export-pdf.html, without changing the center, zoom or rotation.

Compare also with https://openlayers.org/en/latest/examples/export-pdf.html and set dpi to 300 in all three examples to make the different behaviours more obvious (but make other changes).
The OL5 example prints slightly more than the initial view area in both dimensions (due to the .fit not specifying constrainResolution: false) - slightly wrong and subsequently fixed but never made a full release before becoming obsolete.
The current master prints much less than the initial view area (due to #9665) - at 72dpi it might not be obvious but at 300dpi it's very wrong.   I initially though #9665 might be a browser issue but I get the same result with Chrome and Edge.
My version prints either the exact height (if the view aspect ratio is narrower than the paper) or width (if view aspect raio is wider than paper) of the initial view area plus whatever extra of the other dimension is needed to fill the paper - equivalent to an unconstrained fit but done using setResolution as fit doesn't work as desired when there is rotation).

Thanks for the explanation!


Unable to use strip profile in cargo

Hi,
Is there any plan to upgrade rust to 1.59?
I was trying to use strip profile in a project, but srtool gave a error like this:
║ 🧰 Substrate Runtime Toolbox - srtool v0.9.19 🧰
  ║ - by Chevdor -
  info: using existing install for '1.57.0-x86_64-unknown-linux-gnu'
  info: override toolchain for '/build' set to '1.57.0-x86_64-unknown-linux-gnu'
  ║
  ║ 1.57.0-x86_64-unknown-linux-gnu unchanged - rustc 1.57.0 (f1edd0429 2021-11-29)
  ║
  ║ 🏗 Building calamari-runtime as release using rustc 1.57.0 (f1edd0429 2021-11-29)
  ║ ⏳ That can take a little while, be patient... subsequent builds will be faster.
  ║ Since you have to wait a little, you may want to learn more about Substrate runtimes:
  ║ https://docs.substrate.io/v3/getting-started/architecture/
  ║ error: failed to parse manifest at `/build/Cargo.toml`
  ║
  ║ Caused by:
  ║ feature `strip` is required
  ║
  ║ The package requires the Cargo feature called `strip`, but that feature is not stabilized in this version of Cargo (1.57.0 (b2e52d7ca 2021-10-21)).
  ║ Consider adding `cargo-features = ["strip"]` to the top of Cargo.toml (above the [package] table) to tell Cargo you are opting in to use this unstable feature.

strip has been stabilized in rust .159.

Hello @Dengjianping,
I am now closing this issue as it should be fixed by the new release 0.9.19. That would be great if you could confirm with a short note here.
If you still run into issues however, feel free to re-open.


Handle cases where Steam game could have multiple appid possibilities.

Some games can have multiple Steam appids, can probably just assign (symlink?) to every appid reported by the API.
People who bought games before an appid is retired can still have the older app in their library instead of the new one, assets are usually blank too.
Some examples:

Arma II [33900, 33910]
Battlefleet Gothic: Armada [317000, 363680, 450770]
Dragon Age II [47900, 99809, 1238040]
Aion [29640, 29660, 373680]

This can now be done via 30d634ab7c654609ca42be156b64161856caba59.


Keep the data type consistent in dgl graphs to be float32 and int32.

This is way too much overengineering. There doesn't need to be a class called DataType. If you look at how the numpy or torch does it, it is just a module.  E.g., np.float32. They don't do np.DataType.float32.

I implemented a solution and pushed it. I suggest you look at it


[Feature] Super jumbo frame support

Required information

Distribution: Arch Linux
Distribution version: stream
The output of "lxc info" or if that fails:

Kernel version:  5.4.24-rt15-2-rt
LXC version: 4.0.4
LXD version: 4.6
Storage backend in use: 5.7

Issue description
A brief description of the problem. Should include what you were
attempting to do, what you did, what happened and what you expected to
see happen.
Steps to reproduce

Create and set mtu for interface >9202

Information to attach

[ ] Any relevant kernel output (dmesg)
[ ] Container log (lxc info NAME --show-log)
[ ] Container configuration (lxc config show NAME --expanded)
[ ] Main daemon log (at /var/log/lxd/lxd.log or /var/snap/lxd/common/lxd/logs/lxd.log)
[ ] Output of the client with --debug
[ ] Output of the daemon with --debug (alternatively output of lxc monitor while reproducing the issue)

#> lxc config device add frr-test eth0 nic nictype=p2p host_name=cnt-frr-test.0 name=eth0 mtu=9216
Error: Invalid devices: Device validation failed for "eth0": Invalid value for device option "mtu": Out of MTU range (1280-9202) "9216"
Please add support super jumbo frame support, as with old versions.

This seems like a fine change to make, but I'd like to understand more about what your application is here, as this setting will set the MTU of the veth interfaces at the network layer, rather than setting the MTU at the link layer (where link layer MTUs of 9216 are commonly seen when the network layer's MTU is 9000).
Are you tunnelling another protocol over the veth that needs MTU of 9000?
Thanks

You using mtu = 16384 in internal lxd container server between virtal
machines. External network inside hypervisor using mtu = 16384 bytes.

Are you tunnelling another protocol over the veth that needs MTU of 9000?

So what is the maximum mtu you're looking to set, the original post suggested you were trying to set an MTU of 9216, but are you trying to set something higher than that (16384?). Thanks

So what is the maximum mtu you're looking to set, the original post suggested you were trying to set an MTU of 9216, but are you trying to set something higher than that (16384?). Thanks

I used mtu = 16384 for local lxd cluster. mtu = 9216 i instelled in test lxd server.


mailutils: 3.16 -> 3.17

Description of changes
https://git.savannah.gnu.org/cgit/mailutils.git/tree/NEWS
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 284210 run on x86_64-linux 1

3 packages built:

automysqlbackup
mailutils
mailutils.debug

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


Expand API Tests and SDK for Commands Endpoint

Expected Behavior
API SDK included coverage of the command endpoint.
Actual Behavior
No command endpoint available
Potential Solution
Document and include the command endpoint
Checklist

[x] I have completely filled out this template
[x] I have confirmed that this issue exists on the current master branch
[x] I have confirmed that this is not a duplicate issue by searching [issues](https://github.com/QuantConnect/Lean/issues

Live liquidate & stop endpoints are implemented & documented atm. Missing Add security, place order, cancel order


development mode scripts

This pr has a set of scripts and configurations that help with using this repository with your own cluster.
Once you bootstrap, the root ArgoCD "app-of-apps", each of the component applications will each point to the upstream repository.  To enable development  test changes on your own cluster using the same gitops used to create staging, you replace the references to https://github.com/redhat-appstudio/infra-deployments.git with references to your own fork. The use of gitops means you can also easily share your config with others using the same bootstrap mechanism as staging.
This PR includes a set of scripts that help with this, and minimize the changes needed in a fork.
See the main README for usage instructions.
The usage of this PR required yq to update manifests see https://github.com/mikefarah/yq
The PR

enables use of forks to test via gitops in dev environments
A script hack/development-mode.sh will update a single file in your fork to redirect gitops to that fork. This file must be committed to your fork. This uses kustomize overlays to map the repositories per component to your fork. You can also just replace a reference to your own component and keep the rest from upstream. As this file is committed back to your fork so care is needed not to include it in pull requests upstream however it accidentally included upstream, it will be "harmless" (default forks of upstream will use your fork until replace in dev mode)
users can switch from dev mode back to upstream mode
Use of a separate overlay directory is intended to minimize the risk of a PR including accidental mods to staging and only one file is modified.

I see that Jonathan beat me to it. :-)


mint was successful but did not arrive in the account

https://mempool.space/tx/223d5ddc15ed5ecb7489e81fd0d4e70e0d8e286404720a9f9ded7d3d4ed88b26

no quark？why?

huogai

I encountered the same problem:
https://mempool.space/zh/address/bc1puety2642tn5upy6e6wj6cwj0tzlrkrs0v0vxeedvrkahggffh57qfuct80

i got same problem  sad :(

0.1.64 fixed -_-||

how to find the lost ones?anybody know?

 0.1.64 fixed -_-||

So the latest version is good, right?

how to find the lost ones?anybody know?

got the same issue

same to me. so sad

i will try to debug...wait for me


Add nested call and new expressions as potential intra expression inference sites

Sometimes nested generic functions are skipped during inference in the first pass:
https://github.dev/microsoft/TypeScript/blob/04d4580f4eedc036b014ef4329cffe9979da3af9/src/compiler/checker.ts#L33619-L33634
However, those calls are resolved from within checkExpressionWithContextualType and by the time we have a chance to call addIntraExpressionInferenceSite they are already resolved. So it, imho, makes sense to actually use them as intra expression inference sites.
fixes https://github.com/microsoft/TypeScript/issues/54184

@typescript-bot test this
@typescript-bot run dt
@typescript-bot test top100
@typescript-bot perf test this

only change I think I'd want is a deprecated isContextSensitive in the public API (which can just call the new function), so this isn't a hard API break.

is this relevant for a function that is annotated with /** @internal */?

@typescript-bot run dt
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot pack this

@typescript-bot test top800

@typescript-bot perf test this

Extracted repro (still depending on 3rd party libs) from the reported failure above: TS playground

I'm probably not the best one to review the code specifics, but what happens if we consider all calls and new expressions to be context-sensitive?

It would definitely impact some inferences negatively. Context-sensitive functions are replaced with anyFunctionType in the first inference pass and containing objects are thus marked as non-inferrable. So I'd expect things to break with such a change even if only because the order of candidates' collection would change in certain situations. On top of that, you'd always require the second inference pass when such function expressions would be present in the arguments list - whereas right now the second pass might get skipped if all of them are annotated. So it could also affect performance in some situations.

@Andarist maybe there's been a miscommunication - I was asking about all call/construct invocation expressions like
foo()
new Bar()

In https://github.com/microsoft/TypeScript/pull/54183#issuecomment-2015690919, it seems you're talking about all function expressions like
((x) => x))
((x: number) => x)
(<T>(x: T) => x)

Ah, sorry - I misread it. But isn't this what this PR is effectively doing?
    function containsContextSensitiveOrCallOrNewExpression(node: Expression | MethodDeclaration | ObjectLiteralElementLike | JsxAttributeLike | JsxChild): boolean {
        return containsContextRelatedNode(node, n => isContextSensitiveFunctionOrObjectLiteralMethod(n) || isCallOrNewExpression(n));
    }

This check doesn't have any extra checks combined with isCallOrNewExpression.

The reported failures here are addressed by https://github.com/microsoft/TypeScript/pull/57909 . I believe this isn't a new issue here - it just surfaced here by the fact that more inference sites are considered. One could rewrite those call sites slightly to end up with the same broken results today.

https://github.com/microsoft/TypeScript/pull/57909 was merged so the issue above is resolved now. @jakebailey could you re-run top800 and other important tests here? @DanielRosenwasser @weswigham could I ask for another review? :)

@typescript-bot perf test this
@typescript-bot test top800
@typescript-bot user test this
@typescript-bot run dt


Update the documentation to install the hooks

What does this PR do?

Update the documentation to install the hooks
Motivation

That's outdated.
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

#26485  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @FlorentClarret and the rest of your teammates on  Graphite

/merge


Standalone minipaint in Gradio 4

Good day, I am hoping that you can release a standalone version of minipaint on gradio 4 (not a plugin for a1111/forge) as I want to study the integration of it with gradio framework.
Thanks!

As the original miniPaint is a standalone web app, you might want to take a look at it, as the Gradio integration on this extension is limited to showing an iframe embedding this application and making the number of available controlnets acessible. The only python file in this repository is this one. I hope you find what you are trying to study


Engineering release requirements

We have a few things to get the repo ready for a GA release. This ticket holds the necessary things to call it ready
Check list:

[x] Show out of credit error like a test result failure and not just a console.error
[x] Remove console.* from everywhere in the code base except for commands and add an eslint rule
[ ] Cleanup project schemas for resources, remove stripUnknown from them to get 404 immediately

@umutuzgur I'm taking an initial look at the out-of-credit error handling.
We'll already mark the check as failed when the account is out of credit: https://github.com/checkly/checkly-cli/blob/afe1483e9dc6f6d530973301705a6fc547969abb/package/src/services/check-runner.ts#L80-L88
I'll mark this as done.
For the TODO in the code - "Find a way to abort. The latest version supports this but doesn't work with TS " - is there anything to do there? It seems like it was added back when the code was structured differently - I'm not sure if this is still relevant.


Mre doc edits

Just some basic grammar edits for — most of the docs… still to process
now that effects is being broken into sep. files @raulraja

Codecov Report

Merging #220 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #220   +/-   ##
=======================================
  Coverage   72.42%   72.42%
=======================================
  Files          39       39
  Lines         330      330
  Branches        3        3
=======================================
  Hits          239      239
  Misses         91       91

Thanks @MaureenElsberry I'm gonna merge this so you can continue with the latest from master


suggested urlMapper api

urlMapper.parse('/bar?bar=baz#hash', '/:foo'); // => { params: { foo: 'bar' }, query: { bar: 'baz' }, hash: 'hash' }
urlMapper.stringify('/:foo', { params: { foo: 'bar' }, query: { bar: 'baz' }, hash: 'hash' }); // => '/bar?bar=baz#hash'
urlMapper.map('/bar?bar=baz#hash', routes, function(match, values){
  match({ route: values })
  return 'some return value';
}); // => 'some return value'
urlMapper.map('/bar?bar=baz#hash', routes); // => { match, values }

I have plans to implement this api for next version of lib. Any suggestions?

/cc @itaylor @christianalfoni

So in the above, on the third line, values is an object that is the output of urlMapper.parse, containing three properties:
{ params: { foo: 'bar' }, query: { bar: 'baz' }, hash: 'hash' } }
and match is whatever the right hand side of the matched route from routes was, correct?
If so, then I'm understanding it right and it looks good to me.

Yes, you are completely right.

wip here: https://github.com/christianalfoni/url-mapper/tree/next

I think this looks really good! I still think we should remove the callback version. I think it adds confusion like: "What is the difference on the callback version and the other version? Is the callback version async? Where is the error?". Yeah,
urlMapper.parse('/bar?bar=baz#hash', '/:foo'); // => { params: { foo: 'bar' }, query: { bar: 'baz' }, hash: 'hash' }
urlMapper.stringify('/:foo', { params: { foo: 'bar' }, query: { bar: 'baz' }, hash: 'hash' }); // => '/bar?bar=baz#hash'
urlMapper.map('/bar?bar=baz#hash', routes); // => { match, params, query, hash }

This is sooooo clean :-)  "route, target, value, match"... I like route, though I acknowledge people look at it differently. Match is nice too :)

Guys I thought a lot about api again.
And I have new proposal which is slight different.
I was bothered a lot on query/hash parts and how we would map it to/from signal parameters.
In fact all we need is stringifying/parsing back from/to any object, like:
var values = {foo: 'bar', bar: { baz: 'foo', foo: ['foo', 'bar', 'baz'] }};
test.deepEqual(urlMapper.parse('/:foo', urlMapper.stringify('/:foo', values)), values);

There is no params, queries and hashes. In cerebral-router (or any other lib) we'll just provide route and signal inputs and will get back url or restore signal inputs from url.
It will also allow keep signal clean without any chance to affect signal execution:
// action to inject
function setUrl (input, state, output, services) {
  state.set(urlStorePath, services.router.getUrl(input));
}

About stringifying. I plan to stick next scheme by default:

substitute keys defined in path from object using path-to-regexp's compile method. Allow only string values for such keys (so we can gurantee that parsed value will remain the same type)
stringify all left keys with URLON library which supports any JSON serialazable

var values = {foo: 'bar', bar: { foo: true, bar: 2, baz: ['foo', 'bar', 'baz'], e:''}};
urlMapper.stringify('/:foo', values); // => '/bar?_bar_foo:true&bar:2&baz@=foo&=bar&=baz;&e='

Therefore developer could override stringify/parse with own implementation. The only limit is parse(stringify(object)) === object.
I have updated wip branch with draft for new implementation

/cc @itaylor @christianalfoni @maxfrigge

Okay, just to make sure I understand this, you want:
Router(controller, {
  '/:foo/:bar': 'someSignal'
});

To give the input to that signal as:
// url: /hey/ho
{
  foo: 'hey',
  bar: 'ho'
}

I really like this concept. Though what about queries? How does the developer access queries? Or are you suggesting limiting the scope? Or, hm, could you explain it from the perspective of implementing a route in Cerebral? :-) I get a bit lost, sorry, hehe

@christianalfoni See part after "About stringifying. I plan to stick next scheme by default:"
Router(controller, {
  '/:foo/:bar': 'someSignal'
});

// url: /hey/ho?_baz=:true
{
  foo: 'hey',
  bar: 'ho',
  baz: true
}

Anything not in path params stringified to query with URLON
btw, I can't see your confusion with callback.
var routeMatched = urlMapper.map(url, routes, function (signal, values) {
  signal(values);
  return true;
});
if (!routeMatched) console.warn('nothing matched');

vs
// es5
var result = urlMapper.map(url, routes);
if (result) {
  result.match(result.values);
} else {
  console.warn('nothing matched');
}

Very powerful.. but users will have to understand URLON first to understand what's happening.

@maxfrigge By users do you mean developers or end users?

And you have to be aware that param vars should never have the same name as query params.. which would be new.

Aha, I see. URLON seems very powerful, though it requires you to learn URLON to use queries with Cerebral. What does URLON do with normal queries? Just uses strings? /hey/ho?baz=foo. Will this become: {foo: 'hey', bar: 'ho', baz: 'foo'}?

@Guria Yes.. developers would be a better name :)

@christianalfoni '/hey/ho?baz=foo' <==> {foo: 'hey', bar: 'ho', baz: 'foo'}

About callback, it is about familiarity. I have never seen a library with this kind of signature:
var routeMatched = urlMapper.map(url, routes, function (signal, values) {
  signal(values);
  return true;
});
routeMatched // true

Callbacks are not typically used to return a value synchronously. Also returning a value seems unnecessary as the callback is only fired if there actually is a match.
var routeMatched = urlMapper.map(url, routes);
routeMatched // {match, params}

The callback does not give any extra value as I see it, just gives a more complex signature.

Cool! Then I am all up for URLON, as we can extend normal query use. Awesome stuff! :)

@christianalfoni  did you have noticed an anderscore?

Yeah, so: ?_baz=:true gives {baz: true} and ?baz=true gives {baz: 'true'}, right? :-)

Well if it's backwards compatible it would be really cool to have the option to use it - otherwise I would say it's better to leave it up to the developer to choose which implementation to use for parse/stringify.
Another thing to think about is.. should a developer deal with search patters or just with route definitions and the data that goes in and out.

And you have to be aware that param vars should never have the same name as query params

developers wouldn't aware on urls at all. there is only signal input and stringified representation

@maxfrigge We assume that developer will never construct and use urls by hands. He just calls controller.signals.smthHapenned.getUrl({}) and gets url. Or just uses ready <Link> component from cerebral-react

@Guria I was referring to the route definition. I you define route /:foo/bar and the have a url /hello/bar?foo=123 you could not merge the search params and path params into a single object.

why you have such urrl? where it came from?

Ah, yes, I see your point @maxfrigge. That is a gotcha, but the simplification achieved here is pretty amazing. So I would just avoid that. It is an extreme edge case I would say :-)

@Guria Got it :) You would never have that URL because you wouldn't be able to create an object that would create such a result on stringify - right?

@maxfrigge exactly

I think it's pretty cool then. Just don't bother with what the address bar "displays" and look at it as some sort of transport protocol for what you are expressing with your code.

I suppose with the example: /:foo/bar used with  /hello/bar?foo=123, the result would just be: {foo: '123', bar: 'bar'} , no errors?
But if you are missing the query/param you should be able to debug it very easily I think :-)

@christianalfoni The url /hello/bar?foo=123 could only be created by hand.. it would be impossible with the stringify implementation.

@christianalfoni

Yeah, so: ?_baz=:true gives {baz: true} and ?baz=true gives {baz: 'true'}, right? :-)

Nope. Here it is right:

?_foo:true&bar=baz <==> { foo: true, bar: 'baz' }
?_foo=true&bar=baz <==> { foo: 'true', bar: 'baz' }

But I can do in urlMapper:

?foo=true&bar=baz ==> { foo: 'true', bar: 'baz' } (only parse direction)
?_foo=true&bar=baz <==> { foo: 'true', bar: 'baz' }

@maxfrigge Good point :-) But it might happen, maybe a user inserts it. Not sure if needed handling though
@Guria I do not quite understand why ?_foo=true&bar=baz <==> { foo: 'true', bar: 'baz' }? Is the underscore just a leading underscore? Not for every query you want to parse to JS?

I think it just indicates that urlon should to it's thing (e.g. parsing typed values).
So when not having the underscore ?foo=:true <==> { foo: ':true' } instead { foo: true }

Yeah, so why do I need underscore when I just want to do normal parsing? :-)
Anyways, I think we all agree that:
/foo/bar?baz=true should become {param1: 'foo', param2: 'bar', baz: 'true'}
and
/foo/bar?_baz:true should become {param1: 'foo', param2: 'bar', baz: true}
When I am happy :-)

@christianalfoni underscore means object. we can't have properies without object :D

/foo/bar?baz=true should become {param1: 'foo', param2: 'bar', baz: 'true'}

But:
{param1: 'foo', param2: 'bar', baz: 'true'} will be /foo/bar?_baz=true

@christianalfoni But as soon as you would stringify {param1: 'foo', param2: 'bar', baz: 'true'} urlon would add the underscore - which could be confusing in those cases where developers create the url by hand.

I think that URLON is extremely cool, but not sure if it's suited as the default implementation. How about having url-mapper as the default implementation and then create urlon-mapper as an alternate implementation. If then everyone ditches url-mapper you can just make urlon-mapper the default implementation at some point.

@christianalfoni @maxfrigge
Hmm, I think I can strip first underscore safely. And we'll get querystring compatibility for very basic cases

I'll secure this with tests, of course

Yeah, there is a "must have" for URLON here and that is to make it work just like normal queries both ways. If that is problematic I suggest we use url-mapper as default, but allow to pass mapper:
Router(controller, routes, {
  mapper: urlonMapper
});

This fits very nicely in with your suggestion @Guria. Thinking of it, I think this might be the best way to do it. That way we do not make URLON "special" in Cerebral and the developer makes a conscious choice to use it and it works exactly like the URLON documentation.
How you guys feel about that?

@maxfrigge I can offer default implementation with just path-to-regexp without special query / hash support. It is the only way to keep it simple {} <==> "" without hardcoding "special" keys in object to map query / hash parts.

urlonMapper

it can't be named urlonMapper since we use 2 str/parse libs. path-to-regexp for path and route matching and URLON deals with only query part

I agree with christian. It has to be 100% compatible with default query parsing back and forth - otherwise the will be too man wtf moments.
@Guria Do I understand this right: The default implementation is path-to-regexp and urlon would just be an addon for search params?

What if we add an option to router then? :-)
Router(controller, routes, {
  useUrlon: true
});

There? :-)

:+1:  Easy enough and developers are not left in the dark about what's happening with their urls.

@christianalfoni what you would expect in case of useUrlon: false? BTW, I don't like it at all at least because it can't be router option.

Guys, My offer is stick to urlon but make it compatible with familiar qs format (but without nesting, arrays, etc)

I'll do
{ foo: 'bar', bar: 'baz'} <==> ?foo=bar&bar=baz

@Guria Having the one ring to rule the all option would be cool.
How would you handle {foo: true} or {foo: [1,2]}?
Maybe we should start with use cases before jumping in on it.

But { foo: { bar: 'baz' }} would be stringified to 'foo_bar=baz'

@Guria That's cool because it doesn't really exist in default qs parsing

@maxfrigge I woldn't handle it at all. it already handled by URLON but not handled by qs

just do npm i vjeux/URLON and try it in node REPL

My point is that qs could not guarantee parse(stringify(object)) === object. That why I don't want to provide it as default. Developer would have to make complicated checks and type conversions in actions.
With path-to-regexp we still sticked to string only values(can be workarounded I think, but now I suggest just accept this limit). But URLON unlockes to have support to anything that can be provided to signal.

BTW, I made url-mapper a factory, so it's behavior could be tweaked with options:
Router(controller, routes, {
  mapper: urlMapper(mapperOptions)
});

It may contain configuration for path-to-regexp, for example. Or even redefine compileRoute function

@Guria I get your point about type conversion, which is a plus for actions but it's adding complexity to the urls. If it was up to me I wouldn't mind it at all, but it could be irritating to others when suddenly they see a url pattern in their browser, which they don't understand.
All I am saying is that you have to be aware of what's going on and most developers are used to ?list[]=1&list[]=2 rather then list@:1&:2 - even though I would prefer the latter when you take it's benefits into account.

:+1: for the factory - very clean!

For end user list[]=1&list[]=2 and list@:1&:2 would be equally meaningless except he is a geek.
Absolutely most users never look at addressbar at all.
What user cares in fact is working and bugless behavior of app helping him to do some bussiness. If user tries to manipulate an url that a signal that app has UX problems.

@Guria Sorry - I was referring to developers again :)

Why not make it optional in the beginning and see how developers react to it?

Okay, this is a tough one...

Really good to just handle params/queries transparently with an input object
Good to empower developers to make queries be more than just queries, they can be actual JS objects to do all sorts of crazy inputs on signals by just using a url
Not good to change default look of queries. It will be off putting to developers

So we need to solve the third point here:

Do we tell developers that we have chosen to use urlon to empower them. That they should stop focusing on the url itself, just think about objects that gets passed to signals, the url is just a sideeffect

Do we implement a way to toggle it on/off some way

The best approach is to make it optional, but if it creates a lot of implementation difficulties we can still consider option 1 here. It only affects queries, which is not very common to use, but could be extremely common as we empower them using Cerebral router

As for today cerebral-router doesn't have good support for queries. It parsed with qs and exposed as meta to action input. There is nor auto mapping signal inputs to query, nor easy and clean way to signal.getUrl() with queries and hashes.
I don't want to ship semi-functional support now when I achieved a lot in splitting responsibilities between libs.
The only safe default I can suggest is ignore query / hash (as it now, but even do not provide it as meta) at all. Developer still be able to parse querystring by accessing store.get(urlStorePath), but will not able get url with queries from signal call (as it now).
And allow to opt-in with full featured query support.

So in other words:
Lets move ahead with @Guria implementation, but you have to opt-in on parsing queries using urlon? Which will be full fledged urlon queries.
You can still fall back to manually parsing queries however you want by grabbing the current url from the store.
Am I understanding this correctly?

Indeed

Okay, would you mind summarizing this in API examples @Guria? Just to have lika a conclusion on all the discussion? :-)
So:

Example of how you set up the router without urlon queries
Example of how to parse query strings if needed
Example of how you set up the router with urlon queries support
Example of how those queries are parsed/stringified

:+1 Let me know if you want me to help

@christianalfoni

Example of how you set up the router without urlon queries

Router(controller, routes, {
  mapper: urlMapper()
});

Example of how to parse query strings if needed

// dev exposes `qs` as a service
function (input, state, output, { qs }) {
  var queryString = state.get(['url']).split(/\?(.+)/)[1];
  var query = qs.parse(queryString);
}

Example of how you set up the router with urlon queries support

Router(controller, routes, {
  mapper: urlMapper({
    query: true
  })
});

Example of how those queries are parsed/stringified

for /:param route:
{ param: 'path', foo: 'bar', bar: 'true', baz: '2'} <==> '/path?foo=bar&bar=true&baz=2'
{ param: 'path', foo: 'bar', bar: true, baz: 2} <==> '/path?foo=bar&bar:true&baz:2'
{ param: 'path', foo: 'bar', bar: 'true', baz: '2', object: { array: ['string', 2, true, { foo: 'bar'}] }} <==> 'foo=bar&bar=true&baz=2&object_array@=string&:2&:true&_foo=bar'

Okay, cool,
So I think this looks really great! What I would like though is to include the urlMapper inside cerebral-router, but still allow you to override it using the mapper property. The reason is that 99% use cases will be using the urlMapper. Requiring two different dependencies to do routing will be off putting. This way we do not break any current code and we still allow flexibility in using other mappers.
So:
Router(controller, routes, {
  query: true
});

// My default mapper
Router(controller, routes, {
  mapper: SomeMapper({})
});

Does that make sense?

Ho about:
Router(controller, routes, {
  mapper: { query: true }
});

Passing a plain object will configure the default mapper - passing an object that has mapper interface methods will replace the default mapper.

That works for me too :-)

@maxfrigge :+1: good one, will use it

examples updated

Cool! I like this! :+1:  :-)

@christianalfoni what about to preserve map signature with callback, but just don't do return from callback that confuses you?

@christianalfoni also want to add matched route to callback parameters / return object:
var routeMatched = false;
urlMapper.map(url, routes, function (signal, values, route) {
  signal(values);
  routeMatched =  true;
});
if (!routeMatched) console.warn('nothing matched');

and
urlMapper.map(url, routes); // => {signal: function(){}, values: {foo: 'bar'}, route: '/:foo'}

Hehe, I am going to be a real shit about this, I do not think we should include callback signature :-)

The developer has to learn two different signatures that does the exact same thing

The developer will ask... what is the difference? There is a callback, is it async? Why is it async?

The callback does not add any value. There is nothing you can do with the callback that you can not do with a normal sync signature

But this is not a big issue of course. If you still feel it is worth it, please implement, but I just do not think it gives any value, only confusion ;-)

I understand your point. Just don't like how it would be ugly in es5 code:
var routeMatched = false;

(function(result){
  result.match(result.values);
  routeMatched =  true;
})(urlMapper.map(url, routes));

if (!routeMatched) console.warn('nothing matched');

or looked closer, seems this one pretty good:
var result = urlMapper.map(url, routes);

if (result) {
  result.match(result.values);
} else {
  console.warn('nothing matched');
}

What about route in return values? So:
{
  route: '/:foo',             // key from routes
  match: function(){},  // value (signal, component, whatever) from routes
  values: {foo: 'bar'}    // parsed values from route
}

Love it! :+1: :)

:+1:
I like where this landed.  It's cool that the match doesn't have to be a function anymore, instead the implementor gets to decide how best to use the match in their code, and urlMapper is just responsible for figuring out which url matched.

I have splitted compileRoute and mapper itself so we'll have:

require('url-mapper')() - mapper with path-to-regexp without queries
require('url-mapper')({ query: true}) - mapper with path-to-regexp with URLON queries
require('url-mapper')({ compileFn }) - mapper with redefined custom compileFn:

require('url-mapper')({
  key: 'would be passed to compileFn in options',
  compileFn: (cache, route, options) => {
    return { parse, stringify }
  }
})

require('url-mapper/mapper')(compileFn, options) - mapper with redefined custom compileFn:

require('url-mapper/mapper')({
  (cache, route, options) => {
    return { parse, stringify }
  },
  optionsForCompileFn
})

Therefore developer can provide one compileFn(cache, route, options) function that returns methods parse(url) and stringify(object)

@christianalfoni @maxfrigge
3rd and 4th bullets in latest list is about the same. So I decided not to support require('url-mapper')({ compileFn }) because it will leave unused refs to default compileFn with its deps (path-to-regexp, URLON). One who want make custom mapper should use clean variant require('url-mapper/mapper')(compileFn, options)

@Guria Makes sense. I would prefer to have one clean way too. I haven't however seen much of the url-mapper code to understand all the details :)

wip in next branch

ready with 100% coverage.
see tests for details.
next steps:

[ ] update README
[ ] resolve review comments
[ ] publish to npm

Awesome job @Guria! I think it is wise to drop the last point, as you say. I really like the principle of having one flexible way of doing it, rather than multiple ways for certain scenarios. Looking forward to its release :)

Ok. I have updated README. Would be great to get review on it and check spelling. I am not native speaker, you khow :)

I ported over itaylor/redux-action-router to the new API.  It simplified my code considerably.  :+1:
 src/index.js | 66 ++++++++++++++++++++++++------------------------------------
 1 file changed, 26 insertions(+), 40 deletions(-)


Assertion failure with immer::flex_vector_transient

I have a small dummy program that appends and erases unsigned integers from an immer::flex_vector_transient. By default, I understand that the container will use immer::refcount_policy (with immer::no_transience_policy), and everything works fine.
Since the keys are just unsigned integers (32-bits), I'd like to disable reference counting in order to measure the runtime overhead. By changing the container to use immer::no_refcount_policy, this automatically selects immer:: gc_transience_policy, which leaks memory without the Boehm GC (as stated in the documentation).
I don't care about the memory leak since this is just a test program, but I encounter an assertion failure at runtime that is unexpected:
test: ../../immer/immer/detail/rbts/position.hpp:160: leaf_sub_pos<NodeT> immer::detail::rbts::make_leaf_sub_pos(NodeT *, immer::detail::rbts::count_t) [NodeT = immer::detail::rbts::node<unsigned int, immer::memory_policy<immer::free_list_heap_policy<immer::cpp_heap, 1024>, immer::no_refcount_policy, immer::gc_transience_policy, false, false>, 5, 6>]: Assertion 'count <= branches<NodeT::bits_leaf>' failed.
Is this supposed to occur? If I manually choose immer::no_transience_policy, the assertion doesn't fail. This is the test program: test.txt

Thanks a lot @ddcc, good catch!
The problem was that copying the transient was not correctly handling the tokens that are used internally to track ownership in the gc_transience_policy, thus the transient was updating in-place nodes that were visible via two different variables... (v2 and v inside erase).
I already made a fix, will merge as soon as Travis gives a green light.

Thanks for the quick fix!


Redirect URI Issue: input parameter redirect URI is invalid (despite verification of exact match and correct configuration)

Please provide us with the following information:

This issue is for a: (mark with an x)
- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce
I followed along with the tutorial provided at this website: https://learn.microsoft.com/en-us/entra/external-id/customers/sample-web-app-node-sign-in
I have confirmed several times that the redirect URI - http://localhost:3000/auth/redirect - which is identical to the tutorial, is exactly correct in my configuration of the Web Redirect URI on Azure, and present in the body of the URL request (redacted / shortened version below).
https://##########.ciamlogin.com/#############/oauth2/v2.0/authorize?client_id=#######&scope=openid%20profile%20offline_access&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fauth%2Fredirect&client-request-id=etc., etc.
I have found several StackOverflows, Microsoft Community Submissions, etc. dating the last 4 years with similar issues. Each solution appears to be unique and not a global resolution to the problem.
Any log messages given by the failure
The error message provided is:
invalid_request: The provided value for the input parameter 'redirect_uri' is not valid. The expected value is a URI which matches a redirect URI registered for this client application.
Expected/desired behavior
That the error message contain the actual values of the URIs (so that the developer can more easily identify where there is an inconsistency), or for this issue to be investigated in case there is a bigger issue at hand here.
I can see throughout logging during the application that the redirect URI is always the same value, all the way through it landing in the parameters of the URL, and I have confirmed that it is exactly correct in the Azure configuration. I've poked this every which way the last few hours and am stumped.
OS and Version?
macOS Sonoma
Versions
Microsoft Edge, v 120
Azure msal-node v. 2.6.4 (tested on version 1.17.2 and had the same response)
Mention any other details that might be useful

Thanks! We'll be in touch soon.

The URI in question conforms to the rules laid out here(https://learn.microsoft.com/en-us/entra/identity-platform/reply-url) so it's a valid URI, especially for a development environment. Not to mention, it is the URI provided by Microsoft in the tutorial.
Thanks for any and all help!

Hi @minerupset ,
Did you find any solution?
I found a solution here.
It works, but it does not show this page.

I am still working on it.
If you have any solution, please let me know. Thank you.


Add a new annotation to avoid syntax exception while the params is an empty list

resolve #2465
In some case, such as getUsersByIdList, if the id list is empty, it will throw a syntax exception, so we have to check the list before call the mapper method, but this is not graceful to write this checking at every invocation, and it is also not robust to require the caller to write this checking. Typically, return an empty list is equivalent in this case.
If the parameter is an empty collection, what result should we get is part of the mapper's logic, with the annotation 'SkipOnEmpty', we can specify this logic in mapper(just like '@Param'), this is more graceful than checking at xxxService(where we invoking this mapper method), and is also can reduce human negligence(forget to checking and then throws a syntax exception at runtime).

Thank you, @trytocatch , but this PR is not acceptable.
I added a comment on #2465 .


Modify fqdn_metrics at the facter module level

By changing the variable at this level we keep the codebase coherent

Has this been replaced by https://github.com/alphagov/govuk-puppet/pull/7647 now?

Yes it adds a script to do some cleanup in the whisper data

Yes it adds a script to do some cleanup in the whisper data

Ok, that sounds good.


Default agent working directory

Currently we require the user to provide a working directory for each agent. By default we can just attempt to create a .plantit directory wherever the shell spawns, and also allow optional specification.

Added in f121375


late final local variable re-initialized multiple times

Repro:
class _EllipseSegmentResult {
  _EllipseSegmentResult() {
    print('>>> _EllipseSegmentResult constructor');
  }
  double endPointX = 0;
  double endPointY = 0;
  double distance = 0;
}

void main() {
  late final _EllipseSegmentResult result = _EllipseSegmentResult();
  for (int i in [1, 2, 3]) {
    print(result.endPointX);
  }
}

Expected output:
>>> _EllipseSegmentResult constructor
0
0
0

Actual output:
>>> _EllipseSegmentResult constructor
0
>>> _EllipseSegmentResult constructor
0
>>> _EllipseSegmentResult constructor
0

I compiled with dart2js without minification and without inlining.

/cc @rakudrama @leafpetersen

When run with dart2js_developer there are broken invariants:
Unhandled exception:
'package:compiler/src/ssa/locals_handler.dart': Failed assertion: line 423 pos 12: '!isStoredInClosureField(local)': Local local(main1#result) is stored in a closure field.
#0      _AssertionError._doThrowNew (dart:core-patch/errors_patch.dart:46:39)
#1      _AssertionError._throwNew (dart:core-patch/errors_patch.dart:36:5)
#2      LocalsHandler.updateLocal (package:compiler/src/ssa/locals_handler.dart:423:12)
#3      KernelSsaGraphBuilder._visitLocalSetter (package:compiler/src/ssa/builder_kernel.dart:3510:19)
#4      KernelSsaGraphBuilder.visitVariableSet (package:compiler/src/ssa/builder_kernel.dart:3472:5)
#5      VariableSet.accept (package:kernel/ast.dart:3056:44)
#6      KernelSsaGraphBuilder.visitConditionalExpression.<anonymous closure> (package:compiler/src/ssa/builder_kernel.dart:2958:25)
#7      SsaBranchBuilder.buildBranch (package:compiler/src/ssa/ssa_branch_builder.dart:93:16)

There is almost no difference between the Kernel code for these two:
void main1() {
  late final _EllipseSegmentResult result = _EllipseSegmentResult();
  for (int i in [1, 2, 3]) {
    print(result.endPointX);
  }
}

void main2() {
  _EllipseSegmentResult? _result;
  _EllipseSegmentResult result() {
    var r = _result;
    return r == null ? (_result = _EllipseSegmentResult()) : r;
  }
  for (int i in [1, 2, 3]) {
    print(result().endPointX);
  }
}

main2 runs as expected. There is something wrong with scope analysis and closure conversion.

Fix on the way: https://dart-review.googlesource.com/c/sdk/+/151867

seems like the fix landed in 8e2c51e8fd0c9203ae29b7f916937ce8673223ec, so we can now close this.


pubspec's without names cause lame build errors

I had a package (A) referenced by another package (B), and package A was missing the name field in pubspec.yaml. Pub install worked, pub build failed with the unhelpful message:
Error in pubspec for an unknown package:
Missing the required "name" field.
 - Seems like 'pub install' should have failed.
 - A path to the package would have been more helpful than 'an unknown package'.

This issue has been moved to dart-lang/pub#1057.


bugfix: detetect recursive function types in axioms

Bug fix for axioms regarding recursive function types.

.Pi PiPeline: *, %phase.Phase = PiPeline;
is a notation for
PiPeline := μ α. Phase → α
which is handled as equirecursive type?
Therefore, a type that is automatically unfolded to a function that takes a phase — effectively resulting in functions taking arbitrarily many phases (a list of phases) and can only be handled using axioms.

yes,
Pi PiPeline: *, %phase.Phase = PiPeline;

is
PiPeline := μ α. Phase → α

I'd argue it's iso-recursive. The nominal tag in the type is so to say the tag where to place unfolds. If you manually unfold the type, Thorin will not handle them as equivalent.
Originally, I intended to have all nominal entities to be - well - nominally typed. Unfortunately, this didn't turn out to be enough. For this reason we are also checking for alpha-equiv even for nominals - which makes the term nominal debatable.
Anyway, this is not restricted to axioms. Check out this example:
.Pi Hungry: *, .Nat = Hungry;
.lam hungry (n: .Nat) -> Hungry = hungry;

.let x = hungry 0;
.let y = hungry 0 1;
.let z = hungry 0 1 2;
.let w = hungry 0 1 2 3;

(From TaPL, 270).

I'd argue it's iso-recursive. The nominal tag in the type is so to say the tag where to place unfolds. If you manually unfold the type, Thorin will not handle them as equivalent.

What is the correct way in our implementation to unify the types / let thorin recognize the convertibility (iota-reduction)?
E.g.
.ax %compile.Phase: *;
.Pi PassPhase: %compile.Phase, %compile.Pass = PassPhase;
// this should be of type %compile.Phase but reports typing errors
.let optimization_phase = {
    %compile.pass_phase
        %core.partial_eval_pass
        %core.beta_red_pass
}

One trick would be to define Phase as PassPhase but this would introduce unwanted side effects.


Reproducibility

updated README.md
added configs/README.md
added datasets

A general question: why the data files in data look so suspicious? I mean there are only folds 0 and 1 for esol, and weird subsamples for qm9?

For ESOL, we used train-validation-test split: fold0 is train and fold1 is validation. Should I rename the data files and update configurations files?
In the case of QM9, we decided to use only a subsample of the train data and a subsample of validation data, thus creating new train and validation subsets. I believe this is described in the paper in section Methods.

A general question: why the data files in data look so suspicious? I mean there are only folds 0 and 1 for esol, and weird subsamples for qm9?

For ESOL, we used train-validation-test split: fold0 is train and fold1 is validation. Should I rename the data files and update configurations files?
In the case of QM9, we decided to use only a subsample of the train data and a subsample of validation data, thus creating new train and validation subsets. I believe this is described in the paper in section Methods.

The question is if users know which file is which. Do we have a script that loads these files into train, valid, test? If not, maybe we should rename the files to indicate the purpose of the files.

A general question: why the data files in data look so suspicious? I mean there are only folds 0 and 1 for esol, and weird subsamples for qm9?

For ESOL, we used train-validation-test split: fold0 is train and fold1 is validation. Should I rename the data files and update configurations files?
In the case of QM9, we decided to use only a subsample of the train data and a subsample of validation data, thus creating new train and validation subsets. I believe this is described in the paper in section Methods.

The question is if users know which file is which. Do we have a script that loads these files into train, valid, test? If not, maybe we should rename the files to indicate the purpose of the files.

The datasets are loaded using config files which are provided. Depending on the config, the data is loaded as train, validation, test or cross-validation folds and test.
If the users want to reproduce the results, they only need to provide a path to config file as an argument to one of the provided scripts.
If they want to use the code in other way, then I guess they will use the provided functions for loading the data anyway.
We do not have a separate script that only loads the data.
I guess renaming the data files would be neater. I'll do it in the evening.


Screen size fetch for Android 10 and below vs Android 11.

Fixes #2031
For for Android 10 and below API call introduced when deprecated code was refactored.

@JamesSmartCell does it make sense to have a script/Travis to run it on the oldest version of Android supported (in this case <= 10) too? Then either run it with Travis every time or manually occasionally?

@JamesSmartCell does it make sense to have a script/Travis to run it on the oldest version of Android supported (in this case <= 10) too? Then either run it with Travis every time or manually occasionally?

Yes that would be very good. I'm thinking at the very least we can build a series of macros that test all the wallet functions, perform actions etc. I also recall we used to do random monkey test suites that click all over the place.

Yes, possibly. There's varying granularity, but a lower hanging fruit might be just to display certain screens (which already covers this case as well as loading/refreshing tokens, etc) and then moving on to calling certain functions/flows and snapshot tests.
Anyway, not to pollute your PR, but something for you to think about.


BLD: meson: add Fortran flag to workaround later Gfortran

Workaround for gcc / gfortran optimization causing breakage in BLAS /
Lapack.

Thanks Matthew!


A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x4244 in tid 438 (Thread-1159)

Hi there,
I found this issue and it was giving me lot of headaches in a production App during weeks. It doesn't even show any crash analytics tools, it simply stops and it was completely random and not really frequent.

What happens here is that "zeros_in_startcode" is always 3, but "buf" is an offset inside the array which can be the last item.. so "buf[zeros_in_startcode]" can access memory out of the allocated memory. Even accessing memory outside the boundaries it does not crash always, only when that memory is a protected zone.

I made a pull request with my proposal:
https://github.com/ant-media/LibRtmp-Client-for-Android/pull/62
Thank you for your great work with this library.

Thank you. Your PR has been merged.


Media Info , check why name is not displayed

Media Info, check why name is not displayed.

I discussed with @Shadyzpop and @alexsirbu04, and we think it's better to not show any Name Field. This is because we might run into conflicts with users that post an image with same name as others. The option to fix this should be to show only the identifier.jpeg/png/etc, but again this shouldn't be shown to the user, in our opinion.

@alexcroitoru95  feel free to erase that field then from the modal.

@ChristBKK Will do.

Removed field Name from Media Info Modal.


[FEATURE] Added NSMutableDictionary+TWGMutableDictionary extension

Updated podspec to 0.2.6
Update pods on example project

@andrewmc2 You dont' need to re-run pod install or bump the version number in the podspec when you add things to the repo. You can just add them as you would normally. We will cut an official release when we are ready

@grantjk ok sounds good - i'll keep that in mind. Do you want me to revert those changes or should we just make an official release from this?

Revert them and we’ll do a release in a different commit
--
John Grant
On March 29, 2016 at 10:59:30 AM, Andrew McCallum<EMAIL_ADDRESS>wrote:
@grantjk ok sounds good - i'll keep that in mind. Do you want me to revert those changes or should we just make an official release from this?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub


[pwrmgr] Fix escalate request CDC

addresses #12981
If the escalate request is not permanent, it is possible
for the pwrmgr to miss this request since it goes through
an always-on clock synchronization.
capture and hold escalate request until the system resets.

Signed-off-by: Timothy Chen<EMAIL_ADDRESS>

@jdonjdon this test now needs some DV enhancement in order to fully work.
pwrmgr now captures the escalate request and holds it until the system is reset.
In order to do this, the tb needs to toggle rst_esc_ni when it sees the appropriate lc_rst_req go active.
Let me know if that makes sense.

@jdonjdon this test now needs some DV enhancement in order to fully work. pwrmgr now captures the escalate request and holds it until the system is reset. In order to do this, the tb needs to toggle rst_esc_ni when it sees the appropriate lc_rst_req go active.
Let me know if that makes sense.

I will update TB accordingly.

esc_req sender (alert_handler) sends a pulse. I think the receiver (pwrmgr) is updated to have a capture logic to keep its level. LGTM

yeah this one is a little bit weird. In a real system integration, the escalate input coming into pwrmgr would actually always be set (though it doesn't have to be). So as a result, the output is also always set (in the system, once we escalate, we don't go back).  In the block level though, there is no such requirement that it is fixed to that value forever.

a simple logic for this situation is a pulse stretcher based on a pulse (clk a) -> toggle (clk a) -> toggle (clk b) -> pulse (clk b) whether slow-to-fast or fast-to-slow.

a simple logic for this situation is a pulse stretcher based on a pulse (clk a) -> toggle (clk a) -> toggle (clk b) -> pulse (clk b) whether slow-to-fast or fast-to-slow.

a simple logic for this situation is a pulse stretcher based on a pulse (clk a) -> toggle (clk a) -> toggle (clk b) -> pulse (clk b) whether slow-to-fast or fast-to-slow.

esc_req sender (alert_handler) sends a pulse. I think the receiver (pwrmgr) is updated to have a capture logic to keep its level. LGTM

yeah this one is a little bit weird. In a real system integration, the escalate input coming into pwrmgr would actually always be set (though it doesn't have to be). So as a result, the output is also always set (in the system, once we escalate, we don't go back). In the block level though, there is no such requirement that it is fixed to that value forever.

a simple logic for this situation is a pulse stretcher based on a pulse (clk a) -> toggle (clk a) -> toggle (clk b) -> pulse (clk b) whether slow-to-fast or fast-to-slow.

yes that's true, Except since escalate is one of those "secure" signals, we just set it forever and forget about it :)

@jdonjdon this test now needs some DV enhancement in order to fully work. pwrmgr now captures the escalate request and holds it until the system is reset. In order to do this, the tb needs to toggle rst_esc_ni when it sees the appropriate lc_rst_req go active.
Let me know if that makes sense.

I will update TB accordingly.

TB update merge in #12758


Fix for SourceKit test after attr change

What's in this pull request?
6e8de4458f3baca3837a89904f3519ddb6d08636 added a new attribute to a function in the standard library, but the associated SourceKit test was not updated.

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@gribozavr I saw this while investigating the @warn_unused_result diagnostics issue.

@swift-ci Please smoke test and merge

Thank you!


[AutoDiff] Fix @differentiable attribute type-checking crash.

Check that original declaration has a non-error interface type to avoid crash.
Resolves TF-1017.

@swift-ci Please test tensorflow


Add bind address CL option

As the title says, this PR adds the ability to explicitly specify the ip address the service is listening to. Default bind address is still <IP_ADDRESS>

Excellent work, thank you!


Show AI internal traces in console only when verboseLogging is enabled

Fix for #86 .

:shipit:

:shipit:


"ERROR: Could not map all functions to an entry in the manifest." when adding basePath to next.config.js

Out of the box, everything works
✅ Works as expected
Following steps 1 - 4 from the (README)[https://github.com/cloudflare/next-on-pages#quick-start]
✅ Works as expected
npx @cloudflare/next-on-pages --experimental-minify
✅ Deploys as expected
npx wrangler pages publish .vercel/output/static/
However, with basePath
Add basePath to next.config.js
const nextConfig = {
  basePath: "/base-path",
  experimental: {
    runtime: "experimental-edge",
  },
  reactStrictMode: true,
};

❌ Does not work.
npx @cloudflare/next-on-pages --experimental-minify
Build completes, but logs the following ERROR:
ERROR: Could not map all functions to an entry in the manifest.
Furthermore, if I proceed to deploy the application, I get a browser HTTP ERROR 404 at /base-path and the application's 404 page at /base-path/

This happens to me as well. I rely on basePath pretty heavily in order to have many Next.js applications on the same hostname.
I've created a repro over here: https://github.com/hanford/next-on-pages-42 and can also be messaged on the Cloudflare Discord as @hanford if any additional information is helpful

I believe https://github.com/cloudflare/next-on-pages/pull/44 should add proper support for basePath on next-on-pages. I've got the changes in the PR available in .patch that can be applied using something like patch-package
The patch file is here: https://gist.github.com/hanford/9308f35b5d12a3c225a0045cf6bff3c8
(unrelated, also in the patch, I've disabled the prepInstall function because I've been using Pages direct upload and next-on-pages doesn't yet support many package managers (https://github.com/cloudflare/next-on-pages/pull/11), if desired I can create a new patch without that change..

Will this fix be accepted in the near future? I utilize basePath extensively as well and am using Pages' GitHub integration, which causes the build to fail with this same error.


Create text input field

This chat engine is to be used with Watson NLC API so it needs to have an input chat field as an integrated feature or a plugin. These are the proposed steps to implement that.

[x] Textfield that's designed to work with mobile & desktop screens
[ ] Textfield has send button
[x] Textfield input is animated up on Enter
[x] Textfield evokes a custom function
[ ] Plan and understand API data chunking. Currently we have two JSON data sets in our API. As the skillet grows (especially with Watson responses) there may be hundreds of those; we need to make sure we're organized and each of those JSON documents aren't too big and we aren't loading them redundantly if the user requests the same thing twice over, for example.

The way this seems to pan out is that chunking will work like this: there will be "conversations" (each containing bot statements, questions and reply functions) like there are now. But there could be a multiple number of them and they could be loaded in real-time.
However, the conversation history still need to have an immutable record system of some sort.
Also, it would be good to index all elements within each conversation.
It would be good to have code review and discuss this a bit more; there's a chance things might get more complex and sphaghettier as this app grows.


Actually remove ~solve

please fetch upstream

put on a fursuit and dance in it then i'll merge

put on a fursuit and dance in it then i'll merge

Oh well I'll just report the bot, easy as 1 2 3

NO

NO

Yes, remove it

Remove it.

i will remove you from this org if you do not remove.

I'M MOVING THIS TO MY PERSONAL ACCOUNT

@showierdata9978 you can't merge a pr if i don't review it

i can if its something a counsel member told u to remove, and you did not.
On Sat, Aug 27, 2022, 9:40 PM M.D. Walters @.***> wrote:

@showierdata9978 https://github.com/showierdata9978 you can't merge a
pr if i don't review it
—
Reply to this email directly, view it on GitHub
https://github.com/MeowerBots/MDWalters125/pull/1#issuecomment-1229361159,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQHW4P6UK5QIAOTBXTIKQ23V3LGQDANCNFSM572HFVTQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Refactor matrix methods to use NumSuch "NamedMatrix" objects

The Graph object re-creates some stuff being done in NumSuch.

Update on progress. I refactored Chingon so to make the Graph class inherit from the NamedMatrix class in NumSuch, but we've now encountered a Chapel issue pertaining to modifying the bounding boxes of sparse domains.

This works and is related to the current problem, I believe
/*

 chpl  -I/usr/local/Cellar/openblas/0.2.20/include -L/usr/local/Cellar/openblas/0.2.20/lib -lblas classdom.chpl

 */
use LinearAlgebra,
    LinearAlgebra.Sparse;

var nv: int = 8,
    D: domain(2) = {1..nv, 1..nv},
    SD: sparse subdomain(D),
    X: [SD] real;

SD += (1,2); X[1,2] = 1;
SD += (1,3); X[1,3] = 1;
SD += (1,4); X[1,4] = 1;
SD += (2,2); X[2,2] = 1;
SD += (2,4); X[2,4] = 1;
SD += (3,4); X[3,4] = 1;
SD += (4,5); X[4,5] = 1;
SD += (5,6); X[5,6] = 1;
SD += (6,7); X[6,7] = 1;
SD += (6,8); X[6,8] = 1;
SD += (7,8); X[7,8] = 1;

class M1 {
  var D: domain(2),
      SD = CSRDomain(D),
      X: [SD] real;  // the actual data

   proc init(X) {
     this.D = {X.domain.dim(1), X.domain.dim(2)};
     super.init();
     for (i,j) in X.domain {
       this.SD += (i,j);
       this.X(i,j) = X(i,j);
     }
   }
}

var m1 = new M1(X=X);
writeln("m1\n", m1);

class M2 {
  var D: domain(2),
      SD: sparse subdomain(D),
      X: [SD] real;  // the actual data

   proc init(X) {
     this.D = {X.domain.dim(1), X.domain.dim(2)};
     super.init();
     for (i,j) in X.domain {
       this.SD += (i,j);
       this.X(i,j) = X(i,j);
     }
   }
}

var m2 = new M2(X=X);
writeln("m2\n", m2);

Also mentioned this here: https://github.com/chapel-lang/chapel/issues/7544

Done!


Crash on open on macOS/tmux/nvim

Hi Simrat
Getting the following error code when trying to open:
Error executing lua ...vim/plugins/symbols-outline.nvim/lua/symbols-outline.lua:307: attempt to index field 'view' (a nil value)
Thanks, Auratelience

Fixed. The install instructions weren't clear enough for me. Had to define opts separately, then call .setup(opts)


Create code-server bot account

We shouldn't be sharing with cdrci.

[x] create account
[x] update token in secrets

Might want to make it generic (not specific to code-server)

Both of these have been accomplished as part of #3468
The bot account is under @cdr-oss


File name typo in TestListener

In the class TestListener, the battery status log file has a typo in the name.
It is shown as "batterstats.dumpsys.log"
but should be "batterystats.dumpsys.log"

Thanks! Got it in a fix that will push to master_staging a little later today.