Refresh token support?

Is it by design or not implemented that refresh tokens aren't implemented?. I see a security.md file that states they aren't implemented, but unsure if it's more a TODO, or would conflict with the stateless nature.
From #27 I was able to get lastlogin.io working with kubectl, however the one UX pain point is it seems the id_token lasts 10 minutes.
This means I am constantly logging back in :). It seems the kubectl plugin might support getting refresh tokens without the interactivity, but as obligator doesn't return them, I think it has to go for a full authorisation flow when the token expires.
https://github.com/lastlogin-io/obligator/blob/8fc6dd1b1c5201145d10486ca94d548480d8a607/docker/security.md?plain=1#L33

Hi @btrepp, glad you're finding this useful!
Technically, I can think of a couple ways to improve this. Policy and security is where it gets tricky.
Conceptually what LastLogin is asserting is X user controlled Y email address and Z time. So currently the tokens don't live much beyond "Z time". See this link for me info.
My understanding is kubectl should be managing its own session once LastLogin has asserted an identity. But you're saying it keeps checking the ID token beyond the initial flow?

I will do some testing and get some logs.
I suspect what kubectl is doing is getting the token and storing it locally, passing onto the API when needed. If there is a refresh token i think it calls that endpoint transparently when expired.
However without a refresh token, it uses the token it has until it expires, then requests a new one.
I suspect lastlogin really wants to just provide that you own an email token, but kubectl is expecting the oidc service to provide more of that 'session' capability, as it's probably not minting it's own tokens to pass to the kubeapi, but just storing and passing them on
I very well might have cobbled these things together in some sort of duct tape and twigs situation that isn't what anyone initially intended :)

I will do some testing and get some logs.
I suspect what kubectl is doing is getting the token and storing it locally, passing onto the API when needed. If there is a refresh token i think it calls that endpoint transparently when expired.
However without a refresh token, it uses the token it has until it expires, then requests a new one.
I suspect lastlogin really wants to just provide that you own an email token, but kubectl is expecting the oidc service to provide more of that 'session' capability, as it's probably not minting it's own tokens to pass to the kubeapi, but just storing and passing them on
I very well might have cobbled these things together in some sort of duct tape and twigs situation that isn't what anyone initially intended :)
Update: Looks like kubernetes only wants to use the id token.
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens
So I think the cli will refresh the id token if it has the endpoints, but without them, I assume it expires and triggers the full flow

Ok, refreshing ID tokens is definitely supported by the spec: https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse
I think they're might be a way to do it while preserving obligator's highly stateless architecture, using relatively short-lived refresh tokens with rotation.
The main problem I see currently is that as a free service LastLogin expects to only handle human login requests. Login is relatively rare and LastLogin should be able to handle a high number of users inexpensively. If we start supporting automated refresh, it could greatly increase the load. Might not be a problem in the short term.
That said, I'm not sure it's worth the added complexity, because I don't think there's a big difference security-wise between using refresh tokens, and simply setting longer-lived ID tokens.
Do you know how long you would need ID tokens to last for in order for it to not be annoying for your use case?

So I was probably hitting regularly until I figured out what was going on
:).
For my use cases 1 hour would be plenty.
I think from a load perspective, perhaps it might be good to have some sort
of rate limiting anyway, protection from malfunctioning clients is probably
good and reasonable on what is a free service.
My other thoughts at the moment, is potentially for this use case, I should
run Dex infront of last login.
Kubectl -> Dex -> obligator -> Google/whatever.
This hopefully should have the advantage that Dex might handle the
refreshes (on something I host) but reach out to say obligatory/lastlogin
rarely, eg when I needs to figure out a user.
Dex seems to be able to upstream to another host, so that is good. Ideally
it would support anonymous Auth as well. I will give it a play.
https://dexidp.io/docs/connectors/oidc/
There could also be something there around doing that with obligator, so
retry tokens is something the end user apps should do, but the core last
login server doesn't for load.
Honestly the main reason I was using lastlogin.io. Is it was just so
fantastically easy, so you don't have to do the as much oidc pain when
hosting small apps. I've run authentik and keycloak and they were exercises
in frustration, where as obligator sorta just did one thing and did it
super well :). So adding a little bit of self hosting back is not so much a
problem :)
On Mon, 27 May 2024, 13:55 Anders Pitman, @.***> wrote:

Ok, refreshing ID tokens is definitely supported by the spec:
https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse
I think they're might be a way to do it while preserving obligator's
highly stateless architecture, using relatively short-lived refresh tokens
with rotation.
The main problem I see currently is that as a free service LastLogin
expects to only handle human login requests. Login is relatively rare and
LastLogin should be able to handle a high number of users inexpensively. If
we start supporting automated refresh, it could greatly increase the load.
Might not be a problem in the short term.
That said, I'm not sure it's worth the added complexity, because I don't
think there's a big difference security-wise between using refresh tokens,
and simply setting longer-lived ID tokens.
Do you know how long you would need ID tokens to last for in order for it
to not be annoying for your use case?
—
Reply to this email directly, view it on GitHub
https://github.com/lastlogin-io/obligator/issues/28#issuecomment-2132694912,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACAGFJLGTBTJZVXPPQGEB3ZELDENAVCNFSM6AAAAABIJIRHKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZSGY4TIOJRGI
.
 I don't see any reason ID tokens couldn't last an hour. Potentially even up to a week or more. The only problem I see is that if an app only checks whether a token is still valid, rather than checking how long ago it was issued, you could have apps trusting really old tokens. I wouldn't doubt if there are apps out there that would do that. Easy mistake to make. So we probably wouldn't want to make them last forever.

I suspect refresh would be the nicest UX

I agree. Even though it doesn't really make sense for obligator's architecture, it's the flow that apps expect. There's precedent for this. obligator implements OIDC dynamic client registration, even though it adds basically nothing. This is done for compatibility reasons.
So I think I'll add refresh tokens. Not sure about when I'll get to this though. What's your timeline, especially if I can give you 1 hour+ ID tokens immediately?

@btrepp I went ahead and upped LastLogin's ID tokens to 24 hours. That seems like a fairly reasonable value.

24 hours is awesome :) thanks.
With 24 hours being stacks for now, and it's an open source tool. My timeline is anytime before the heat death of the universe. So don't feel obligated (haha) to implement this unless you get the passion too :).


Fix tag NEQ

Fix issue #2097.

@pauldix @dgnorton

lgtm

@otoolep  I made the same mistake in the NEQREGEX I added to idsForExpr.  Can you fix that also in this PR since it's related?

+1 from @dgnorton


update topic seed queries source/platform pairs

I removed support for urls in the csv/generic_post query field, so the front end should remove support as well.
I added a postgres/generic_post query field that reads from a local postgres table and so is only useful for admins.  We probably just want to not show that option at all in the editing ui for seed queries.

I've removed this. we have author, content, and publish_date.  do we still want to support  'media_name'? or remove that too?

rahul is correct.  I have just removed the capability pass a url into the
'query' field for a csv/generic_post topic seed query.
On Mon, Apr 13, 2020 at 6:51 PM rahulbot<EMAIL_ADDRESS>wrote:

I understood this differently - I think Hal is referring to the ability to
upload a CSV to add to a topic via two different ways:

by selecting a file and uploading it while adding the platform
by supplying a URL to the CSV while adding the platform

Our platform creation UI for generic/csv supports either of those right
now via a tabbed. I think Hal is saying that he removed back-end support
for the URL-based CSV platform addition (ie. #2
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mitmedialab_MediaCloud-2DWeb-2DTools_pull_2&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=0c5FW2CrwCh84ocLICzUHjcwKK-QMUDy4RRw_n18mMo&m=XF4njGc1wqO9-JzeuwthqW0qBJzX8cfA4V-pDnfJvD8&s=-5U6u_xAbYCYTbXDD5mXuQjyYOrFjcDe5M4eHnt2H0Q&e=
on the list above). I'd guess this is part of a fix for
berkmancenter/mediacloud#697
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_berkmancenter_mediacloud_issues_697&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=0c5FW2CrwCh84ocLICzUHjcwKK-QMUDy4RRw_n18mMo&m=XF4njGc1wqO9-JzeuwthqW0qBJzX8cfA4V-pDnfJvD8&s=sQgMJseGvzyfhgw8lxixNU2WWXtCfoOQ1iJ-CrdC988&e=
.
I think the task here is to remove that tab, and related URL-based
generic/CSV platform addition code, from the front-end JS and Python code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mitmedialab_MediaCloud-2DWeb-2DTools_issues_1791-23issuecomment-2D613151873&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=0c5FW2CrwCh84ocLICzUHjcwKK-QMUDy4RRw_n18mMo&m=XF4njGc1wqO9-JzeuwthqW0qBJzX8cfA4V-pDnfJvD8&s=pkvq1IspoKsvbQs0a5ARjtsplRf1katX6JErXKiN4Yg&e=,
or unsubscribe
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAN66T6SGPQZND73FFDJKKDRMOQP3ANCNFSM4MFVR6UA&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=0c5FW2CrwCh84ocLICzUHjcwKK-QMUDy4RRw_n18mMo&m=XF4njGc1wqO9-JzeuwthqW0qBJzX8cfA4V-pDnfJvD8&s=ieEs_hwHTbI-YBHHa7prrhonSiILG577RDIJof6YvdY&e=
.

ah, ok. Emily's CSV from CrowdTangle has only 'author','content', 'publish date', so I incorrectly assumed you meant the field vs the functionality. Can one of you point to or write the requirements here for the CSV file fields so we have it documented and then either Rahul or I can implement and provide as UI Help?

ok, I've removed the option to point to a CSV URL. Currently the EditPlatformContainer page doesn't look like much. I'm wondering what they would actually edit as far as a CSV goes b/c once it's uploaded, you can't really do anything other than remove it, correct?

ah .. interesting.. since what we are doing at the api level is removing and then adding, what happens to those URLs and stories? are they truly removed?

if you remove the query, it will remove the posts discovered by that query,
but it will not remove the stories discovered through those posts.
-hal
On Tue, Apr 14, 2020 at 11:03 AM cindyb<EMAIL_ADDRESS>wrote:

ah .. interesting.. since what we are doing at the api level is removing
and then adding, what happens to those URLs and stories? are they truly
removed?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mitmedialab_MediaCloud-2DWeb-2DTools_issues_1791-23issuecomment-2D613531048&d=DwMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=0c5FW2CrwCh84ocLICzUHjcwKK-QMUDy4RRw_n18mMo&m=dwraUfyQbKFlBjEbpcFPvKqw3cNgRXRIkSL5unb5C7U&s=BhdiEvL64A0PazHdLpGJSUkkuHXKojhW_TnSQN0eJMY&e=,
or unsubscribe
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAN66T6OHMVOM6E4JFNELVLRMSCOLANCNFSM4MFVR6UA&d=DwMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=0c5FW2CrwCh84ocLICzUHjcwKK-QMUDy4RRw_n18mMo&m=dwraUfyQbKFlBjEbpcFPvKqw3cNgRXRIkSL5unb5C7U&s=gwrkXtP873C9bOWWaraLhVrDJBCQmnDFkGkWt__rq0I&e=
.

the current code allows the user to edit(that is remove/create behind the scenes) another CSV to the CSV platform. I think we are good. Adding multiple CSVs could be something the researchers want but let's wait and see. I think merging CSVs is likely to introduce errors.


Improve set API for how to set the value of optional parameter

set API is defined too much parameters.
It's hard to skip optional and only focus on parameter that I want.
Actual Behavior
set( name: string, value: string, expires?: number | Date, path?: string, domain?: string, secure?: boolean, sameSite?: 'Lax' | 'Strict' ): void;
If I need only to set sameSite and skip other options, I'll to call something like the following
set('foo', 'fooValue', null, null, null, false, 'Lax');

Expected Behavior
It should be
set('foo', 'fooValue', { sameSite: 'Lax'});

Specifications

Version: 2.1.0

Hello,
there is already a pull request by @alessioferrero in the works: https://github.com/7leads/ngx-cookie-service/pull/53 😃
Cheers


How about copy Resources to resources/modulename ?

Hello,
I know in modules Resources have lang and views directories, but on main resources have assets for example less files.
Is any config to add copy resource assets from modules to resources in use modules:publish (also if copy elixir config for gulp is helpful more ) ?

You can publish the assets using publishes method in your module's service provider
// on boot method
$this->publishes([
    __DIR__.'/../Assets/less' => base_path('/resources/assets/less')
], 'less')

Works great, thanks :)


Why not determine whether it is a group by whether the combinator is blank?

https://github.com/react-querybuilder/react-querybuilder/blob/e0f2f9f4059c3f68f6c309220d5ff24c3f35b7e7/packages/react-querybuilder/src/components/RuleGroup.tsx#L258C33-L288
Why not determine whether it is a group by whether the combinator is blank?
I hava some code with java, deserialize rule string to Java Object by Jackson libary, e.g.:
Rule rule = objectMapper.readValue(ruleJsonStr, Rule.class);

result has rules attribute with null value always, because the java Rule class has 'rules' field, then something went wrong

Cannot read properties of null (reading 'map')

We can't determine whether it's a group based on the combinator because if you use the independentCombinators prop, groups have no combinator property at all. rules is the only common, required property between RuleGroupType and RuleGroupTypeIC.
But aside from that, I can't really tell what you're trying to accomplish in the Java code. From my cursory glance at the Jackson library, it looks like maybe you could use an intermediary or wrapper class instead of using Rule.class directly?


Work with @ scoped / npm private modules?

Hi,
Thanks, this is a super useful tool.
Could it be made to work with private npm modules, ie. those scoped by username like @username/packagename?
James

Thanks James - it should be working with scoped modules. I don't have access to any private modules to try, I'll see what I can do.

Great thanks, I think I can give you access to one of mine if it would help.

Sure, thanks!

I've made a dummy module which is private and added you as a collaborator - its called @homerjam/dummy-module. Let me know if I can do anything else to help.

Scoped modules doesn't have to be private. Example: https://www.npmjs.com/package/%40sindresorhus%2Fdf
I just fixed support for scoped packages in package-json. Just upgrade to 2.0.0 and it should just work. (Note that the interface changed from callback-style to promise).

Nice, thanks @sindresorhus, and I appreciate that you've changed it to promises.

 While I do appreciate the change to promises, what I really meant to write is that I appreciate that you shared the update news here in this ticket so I can easily address the problem! Thanks for saving me time trying to figure out what's wrong and helping the npm-check users. :heart_eyes:
New version soon to fix this.

Hmm, not sure if I'm doing something wrong here but this still isn't working for me. I've updated to 4.1.0 but still seeing Registry error Package or version doesn't exist.
@dylang is @homerjam/dummy-module working for you?

Thanks for this feedback @homerjam. I'll reopen and investigate the problem.

@homerjam, i'm not finding @homerjam/dummy-module in the npm registry.
Example of a scoped module found:
https://www.npmjs.com/package/@websdk/nap
Not found:
https://www.npmjs.com/package/@homerjam/dummy-module

@dylang did you login?
Here's the page that about the type of modules I'm talking about (in case there's some confusion).
https://www.npmjs.com/private-modules

Oops, good catch @homerjam! I didn't notice that npmjs.com logged me out.
Once logged in I didn't realize I had to also pay the $7/month to access private modules. I'll do that too, very happy to support Isaac and team.

Ah, it never occurred to me that collaborators would also need to pay! $7 is very reasonable I think but I had intended to allow access to some of my modules to other users without them needing to pay necessarily.

I forgot too, because it's not how it works on Github.com.
I've paid for my account, and I'm able to repro the issue. It appears that package-json does not support private packages because it doesn't send the auth token. I'll create an issue for that project.

https://github.com/sindresorhus/package-json/issues/12 created.

I've found an annoying problem that I've created a temporary solution to here. Be great to get your thoughts and eventually bring this in to npm-check.

Hi @dylang package-json has now been updated to fix the above. Would you mind updating the dependencies when you get a chance? Thanks!

Hi @homerjam, thanks for following this and letting me know there's now a fix.
Just re-install npm-check to get the updated package-json.
npm i -g i npm-check

Oh I see! Great, thanks


[Autocomplete] Save onBlur (free solo)

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
There is clearOnBlur I think it will be really good to add saveOnBlur, I saw many of my users write a text in freeSolo mode but forget to click enter.
I will be happy to create a PR for that if you want (solved it already on my local project)
Examples 🌈
When a user will turn on the saveOnBlur attribute the last value will be added to the values.
Motivation 🔦
I think it will help users use this component from what I saw especially in freeSolo mode users add a text but without Enter the value will not update

From my quick thought, it sounds a good improvement for the free solo but do you see any concern for the usage that is not free solo?

In regular mode, it should check if the written word is equal to one of the options if it is, select it, if not clear/do nothing.
Or if we want to keep it simple it could be an option for freeSolo only.
This is what I think, would love to hear your thoughts about that as well...

I think it make sense to support saveOnBlur only for freeSolo mode. Feel free to submit a PR and tag me. Thanks!

Hey, @obsd Is there any progress?

Hello,
I just had the same thought and stumbled onto this issue.
@obsd Is there any progress by now?
Or would you be kind enough to show how you got it working on your local project?

Hi @siriwatknp I'd to pick this up if it's still available.

Hi @siriwatknp I'd to pick this up if it's still available.

Sure! feel free to tag me in the PR.

@siriwatknp created PR for this issue https://github.com/mui/material-ui/pull/36280


Fix host and port for proxy connections

This fixes errors when using a proxy, as described in this issue:
https://github.com/kevin1024/vcrpy/issues/214

Thanks.  Please provide a test that shows the bug this is fixing.

I'd also consider patching urllib3 rather than making our socket mock falsy
On 22 Jun 2017 18:05, "Kevin McCarthy"<EMAIL_ADDRESS>wrote:

Thanks. Please provide a test that shows the bug this is fixing.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kevin1024/vcrpy/pull/319#issuecomment-310442255, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZQTDjpx8laxbv3wm7HqwZtf2s5S-2Kks5sGp7pgaJpZM4OCgID
.

@graingert, it appears that urllib3 does that for a reason, so I wouldn't change that.
Instead, I changed VCRConnection to only have a sock once a connection has been made. urllib3 is expecting this behaviour because that is what the httplib HTTPConnection does: https://github.com/python/cpython/blob/2.7/Lib/httplib.py#L820

How things are going with this PR? i got same issue.

@Smosker, this fixes the issue, but tests are failing because they are failing on master (https://github.com/kevin1024/vcrpy/issues/338).
I am currently not working on this, so you are welcome to have a go at getting the tests to pass.

hello @samuelfekete, thanks for your PR. can you update your branch? tests have been fixed and are working normally again :soccer: :top:

@hartwork, I have rebased and it's green! Thanks @lamenezes for the reminder.

@samuelfekete thanks for updating this PR. I will review this as soon as I can :)

@lamenezes any update on this?
I'm waiting for the proxy patch to be merged so I can use the wonderful vcrpy at work.


Computational Time

Thank you for sharing the code! I'm interesting at the time cost for the experiments in this paper.
The paper says:

We obtain a throughput of 825 images per second ... on an A100 GPU at a batch size of 1,000 (for CIFAR10)

The overall latency of this joint denoise-then-classify model is 1.5 seconds per image on an A100 GPU at a batch size of 32 ... (for ImageNet).

If I understand correctly, for CIFAR10 with $N=100000$, it takes $100000 / 825 \approx 121$ seconds to certify a single image, and $336$ hours for the whole test set of $10000$ images on a single A100. Correspondingly for ImageNet with $N=10000$, it takes $1.5 * 10000 / 32 \approx 469$ seconds to certify a single image, and $130$ hours for $1000$ images in the test set.
I run the code with a V100 and spend 10 minutes for certifying one image of CIFAR10. It increases the difficulty to replicate the result. I guess I might need to replace the ViT with more lightweight model like WideResNet to reduce the budget.

If I understand correctly, for CIFAR10 with $N=100000$, it takes $100000 / 825 \approx 121$ seconds to certify a single image, and $336$ hours for the whole test set of $10000$ images on a single A100. Correspondingly for ImageNet with $N=10000$, it takes $1.5 * 10000 / 32 \approx 469$ seconds to certify a single image, and $130$ hours for $1000$ images in the test set.

This is correct. The ViT model we used for CIFAR-10 takes input as $224\times224$, which is the main runtime bottleneck.You can use the pretrained wideresnet from robustbench.
Thanks for your interest in our work. Please let me know if you have further questions.

Thanks for your reply :)


Arquillian Extension for liferay

Just started reviewing :) :octocat: Sent from GH.

Just started reviewing :) :octocat: Sent from GH.


Route name view not found

Laravel Version: 8.83.26
PHP Version: 8.0.14
Database Driver & Version: 8.0.31

Description:
When adding routes with controller and name view it throws an exception that view is not found. More specific

UnexpectedValueException
Invalid route action: [view].

Steps To Reproduce:
Create a controller with a public method view.
Go to the route file and add something like
  Route::prefix('reports')
         ->controller(ReportController::class)
         ->name('reports.tasks.')
         ->group(function () {
             Route::get('view', 'view')->name('view');
         });

Run any command like PHP artisan route:clear

Hey there,
Unfortunately we don't support this version anymore. Please check out our support policy on which versions we are currently supporting. Can you please try to upgrade to the latest version and see if your problem persists? If so, please open up a new issue and we'll help you out.
Thanks!


[Feature Request] install it conditionally

At the moment, it looks like it's impossible to conditionally instrument the worker (if a config prop is set), it makes it hard to disable it during tests with miniflare (also not sure it works with miniflare?)

I think I have a pretty decent workaround for this.
I have the instrumentation code running everywhere (locally, in production and in Miniflare).
The telemetry data is only sent in production.
This is a snapshot of the important parts of my setup
src/index.ts
export type Env = {
  // the environment is passed in locally using .dev.vars or wrangler.toml
  ENVIRONMENT: 'development' | 'production';
  HONEYCOMB_API_KEY: string;
};

const handler = {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    return app.fetch(request, env, ctx);
  },
};

const otelConfig: ResolveConfigFn = (env: Env, _trigger) => {
  // IMPORTANT: during development or testing, this will be false
  const shouldSample = env.ENVIRONMENT === 'production';

  return {
    exporter: {
      url: 'https://api.honeycomb.io/v1/traces',
      headers: { 'x-honeycomb-team': env.HONEYCOMB_API_KEY },
    },
    service: { name: 'rest-api', version: env.GITHUB_SHA },
    sampling: {
      // by setting the ratio to 0, we effectively stop traces from being sent in development
      headSampler: { acceptRemote: true, ratio: shouldSample ? 0.5 : 0 },
    },
  };
};

export default instrument(handler, otelConfig);

There are some issues with some versions of wrangler where Miniflare blows up, but that should be fixed with the latest wrangler if I am not mistaken.
The challenge is that I can’t conditionally instrument things based on an environment setting is that I don’t get the environment until after I have instrumented the code.
My recommendation would be to run unit tests against your bare handler, not the instrumented one.
If you look at the example worker I have a handler.ts which exports the regular handler and then in index.ts I import that one and do all the configy bits in there.
But if you want to run your unit tests against the instrumented code, @AdiRishi seems to have that working too.
@AdiRishi, would you be able to write up that post into a “howto run this locally/in unit tests” doc?
That would be amazing.


Colored Code

What is your question?
I see people sent code that has pretty colors like this:

However mine always looks like this:

How do I make mine look pretty?

Reply to this comment and you will see what we do:
function replayToThisComment()
  function lookUppperThisCode()
    andYouWillSeeWhatItIs()
  end
end

Reply to this comment and you will see what we do:

function replayToThisComment()

  function lookUppperThisCode()

    andYouWillSeeWhatItIs()

  end

end

0-0
Beautiful :0

'''lua
local Speed
=0.05
local angle
=5
adds up quick
cam be
"Game
" HUD
or
Other
there can be multiple cameras
local cameras
= {"'Game" }
local Radians
=0
function onUpdate()
Radians
= Radians + Speed
for i, v in pairs (cameras) de
setProperty("cam"..v
end
end
'''

'''lua
local Speed =0.05 local angle =5 adds up quick cam be "Game " HUD or Other there can be multiple cameras local cameras = {"'Game" } local Radians =0 function onUpdate() Radians = Radians + Speed for i, v in pairs (cameras) de setProperty("cam"..v end end
'''

Lol, don’t use ’, use ```

'''lua

local Speed =0.05 local angle =5 adds up quick cam be "Game " HUD or Other there can be multiple cameras local cameras = {"'Game" } local Radians =0 function onUpdate() Radians = Radians + Speed for i, v in pairs (cameras) de setProperty("cam"..v end end

'''

Lol, don’t use ’, use ```

Sorry I'm on my phone right now

local Speed
=0.05
local angle
=5
adds up quick
cam be
"Game
" HUD
or
Other
there can be multiple cameras
local cameras
= {"'Game" }
local Radians
=0
function onUpdate()
Radians
= Radians + Speed
for i, v in pairs (cameras) de
setProperty("cam"..v
end
end```

Yeah! Now use spaces, it have to be like this:
local Speed = 0.05
local angle = 5
-- adds up quick cam be "Game" "HUD" or "Other"
-- there can be multiple cameras
local cameras = {"'Game" }
local Radians = 0
function onUpdate()
  Radians = Radians + Speed
  for i, v in pairs (cameras) do
    setProperty("cam"..v
  end
end

And take in mind that it gphave to be like this:
` ``
code
```
Not like this:
Code```

And take in mind that it gphave to be like this:
` ``
code
```
Not like this:
Code```

Like I said I'm on my phone lol...
But thanks a lot :D

And for other color codes, use the extension file, for example:

Language code
Extension of the file
What to use to color it

LUA
lua
lua

JavaScript
js
js

Haxe
hx
hx

Do you get it?

And if you want to write things more advanced, I recommend you to read this: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/about-writing-and-formatting-on-github, and then go down the page for more writing


fix: LSDV-5112: Fix the disable state of submission button

PR fulfills these requirements

[x] Commit message(s) and PR title follows the format [fix|feat|ci|chore|doc]: TICKET-ID: Short description of change made ex. fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errors
[ ] Tests for the changes have been added/updated (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[x] Best efforts were made to ensure docs/code are concise and coherent (checked for spelling/grammatical errors, commented out code, debug logs etc.)
[x] Self-reviewed and ran all changes on a local instance (for bug fixes/features)

Change has impacts in these area(s)
(check all that apply)

[ ] Product design
[x] Frontend

Describe the reason for change
(link to issue, supportive screenshots etc.)
What does this fix?
(if this is a bug fix)
What is the new behavior?
(if this is a breaking or feature change)
What is the current behavior?
(if this is a breaking or feature change)
What libraries were added/updated?
(list all with version changes)
Does this change affect performance?
(if so describe the impacts positive or negative)
Does this change affect security?
(if so describe the impacts positive or negative)
What alternative approaches were there?
(briefly list any if applicable)
What feature flags were used to cover this change?
(briefly list any if applicable)
Does this PR introduce a breaking change?
(check only one)

[ ] Yes, and covered entirely by feature flag(s)
[ ] Yes, and covered partially by feature flag(s)
[ ] No
[ ] Not sure (briefly explain the situation below)

What level of testing was included in the change?
(check all that apply)

[ ] e2e
[ ] integration
[ ] unit

Which logical domain(s) does this change affect?
(for bug fixes/features, be as precise as possible. ex. Authentication, Annotation History, Review Stream etc.)

/git merge master

Codecov Report
Patch coverage has no change and project coverage change: -0.02 :warning:

Comparison is base (c4b9340) 65.23% compared to head (440a358) 65.22%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1378      +/-   ##
==========================================
- Coverage   65.23%   65.22%   -0.02%
==========================================
  Files         435      435
  Lines       27155    27155
  Branches     7167     7167
==========================================
- Hits        17715    17711       -4
- Misses       8115     8118       +3
- Partials     1325     1326       +1

Impacted Files
Coverage Δ

src/common/Button/Button.tsx
90.62% <ø> (ø)

src/components/BottomBar/Controls.js
5.19% <0.00%> (ø)

src/components/CurrentEntity/GroundTruth.js
63.63% <ø> (ø)

... and 2 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

/git merge master


Removed unused Maven repository

I'm closing this PR out because in end, I'm certain that the Shibboleth repository is needed.
For verifying the artifacts, I started a separate PR
https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/3


Pull from kserve:main

Motivation
Pull in latest changes from upstream
Modifications

add pvc support
add support for payload processor (required for trustyai)

Testing
We will test the PRs for modelmesh-serving and modelmesh together

Create a fresh OCP cluster
Install the opendatahub operator in the opendatahub namespace
Install the following kfdef

apiVersion: kfdef.apps.kubeflow.org/v1
kind: KfDef
metadata:
  name: odh-modelmesh
  namespace: opendatahub
spec:
  applications:
    - kustomizeConfig:
        repoRef:
          name: odh-manifests
          path: odh-common
      name: odh-common
    - kustomizeConfig:
        overlays:
          - odh-model-controller
        parameters:
          - name: monitoring-namespace
            value: opendatahub
          - name: odh-modelmesh
            value: 'quay.io/vedantm/modelmesh:v0.11.0-alpha'
          - name: odh-modelmesh-controller
            value: 'quay.io/vedantm/modelmesh-controller:v0.11.0-alpha'
        repoRef:
          name: manifests
          path: manifests/opendatahub
      name: model-mesh
  repos:
    - name: odh-manifests
      uri: 'https://api.github.com/repos/opendatahub-io/odh-manifests/tarball/master'
    - name: manifests
      uri: >-
        https://api.github.com/repos/VedantMahabaleshwarkar/modelmesh-serving/tarball/kserve011alpha
  version: master
status: {}

Execute the following commands
INFERENCE_SERVICE_PROJECT=mesh-test
oc new-project $INFERENCE_SERVICE_PROJECT
mkdir temp && cd temp
git clone git@github.com:opendatahub-io/modelmesh-serving.git
cd modelmesh-serving/quickstart
oc apply -f sample-minio.yaml -n $INFERENCE_SERVICE_PROJECT
oc apply -f openvino-inference-service.yaml -n $INFERENCE_SERVICE_PROJECT
oc apply -f openvino-serving-runtime.yaml -n $INFERENCE_SERVICE_PROJECT
oc apply -f service_account.yaml -n $INFERENCE_SERVICE_PROJECT
Wait till all pods in mesh-test are running
ROUTE=$(oc get routes -n mesh-test example-onnx-mnist --template={{.spec.host}}{{.spec.path}})
TOKEN=$(oc sa new-token user-one -n mesh-test)
curl -k https://$ROUTE/infer -d @input.json -H "Authorization: Bearer $TOKEN" -i
the curl command should return the following output

{"model_name":"example-onnx-mnist__isvc-82e2bf7ea4","model_version":"1","outputs":[{"name":"Plus214_Output_0","datatype":"FP32","shape":[1,10],"data":[-8.233052,-7.749704,-3.4236808,12.363028,-12.079106,17.26659,-10.570972,0.7130786,3.3217115,1.3621225]}]}

do we push these commits into main branch?

unit test failed please check it.

Tested the deploy locally, isvc doesn't seem to come up:
NAME                 URL   READY   PREV   LATEST   PREVROLLEDOUTREVISION   LATESTREADYREVISION   AGE
example-onnx-mnist                                                                               108m

By the way, from a component perspective, we don't need to test kfdef way. We focus on the unit test and functional test. Then odh-manifest repo will test the kfdef way.


NixOS-Rebuild Automatic Hostname detection even when TargetHost

It looks like you accidentally mass-pinged a bunch of people, which are now subscribed
and getting notifications for everything in this pull request. Unfortunately, they
cannot be automatically unsubscribed from the issue (removing review request does not
unsubscribe), therefore development cannot continue in this pull request anymore.
Please make sure the PR preview looks right before opening a new pull request with your changes.
In order to avoid this in the future, there are instructions for how to properly
rebase between branches in our contribution guidelines.
Setting your pull request to draft prior to rebasing is strongly recommended.
In draft status, you can preview the list of people that are about to be requested
for review, which allows you to sidestep this issue.
This is not a bulletproof method though, as OfBorg still does review requests even on draft PRs.


Provide super-power kubeconfig for emergency scenarios

Currently, Terraform code creates a kubeconfig you can use to access the cluster without any restriction (RBAC, etc.).
It is useful for some users to have such a file in emergency scenarios, where for some reason or another Dex/Gangway are failing and need to recover the cluster.

Note: in lokomotive-kubernetes (using k8s 1.15 at least) this was not created. It is created in lokomotive, but in only one controller.
I think this is fine, but just sharing the info in case someone (probably me) needs it


Lib rename

Description
Publishes ESM to dist-esm/ rather than lib/ throughout the repo.
I've left lib/ .gitignore'd, excluded from search, and in the clean scripts so that devs can easily clean up leftover state.

don't want to push this in.


Add parallel exporter

Exporter currently take too long to complete (around 1 hour and 10 minutes), and will only get longer to run as the OSV database expands.
This change parallelizes the exporter along each ecosystem, separating the ecosystem export portion of the script from the selection of each ecosystem. This roughly reduced the time taken down to how long the longest ecosystem takes to export, 13 minutes or so.

Ended up at 7 because that's the maximum number of cores for a pod a node with 8 cores can support (since some CPU is being used up by metrics and logging driver). It doesn't really matter too much now. I'll switch this to 6 to get a more round number.


Update Vagrant

Update Vagrant to 1.9.5
Also, change the order of SHA256 from deb,rpm,dmg to deb,dmg,rpm to reflect the order of: https://releases.hashicorp.com/vagrant/1.9.5/vagrant_1.9.5_SHA256SUMS

published to the galaxy as andrewrothstein.vagrant v1.0.9. thanks for the contribution!


Defect: MPI_Type_extent, type of 2nd argument is pointer to MPI_Aint

Defect/Bug Report
Defect: MPI_Type_extent, type of 2nd argument is pointer to MPI_Aint

OpenCoarrays Version: 1.9.1
Fortran Compiler: GNU Fortran (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 7.1.0
C compiler used for building lib: gcc (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 7.1.0
Installation method: Manual, Win7-64
Output of ver: Microsoft Windows [Version 6.1.7601]
MPI library being used: Intel(R) MPI Library for Windows* OS, Version 2017 Update 3 Build 20170405
Machine architecture and number of physical cores:  Intel Haswell i7, 4 cores, 8 threads
Version of CMake: N/A

Observed Behavior
C:\TEMP\oca\src_1.9.1\mpi>gcc --version
gcc (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 7.1.0

-I.. used to find libcaf.h
-I../.. used to find mpi.h
-D_POSIX used to find SIGKILL in signal.h
-DALLOCA_MISSING because it is missing
-DUSE_GCC for correct typedef of MPI_Aint in mpi.h (long long int)
-g -Og for debugging with gdb
-m64 to give an error message if compile attempted with Win32 version of mingw-w64 gcc

C:\TEMP\oca\src_1.9.1\mpi>gcc -g -m64 -DGCC_GE_7 -DPREFIX_NAME=_gfortran_caf_ -DUSE_FAILED_IMAGES -DALLOCA_MISSING -D_POSIX -DUSE_GCC -Og -c mpi_caf.c -I .. -I ../..
mpi_caf.c: In function 'redux_char_by_reference_adapter':
mpi_caf.c:4140:30: warning: passing argument 2 of 'MPI_Type_extent' from incompatible pointer type [-Wincompatible-pointer-types]
   MPI_Type_extent(*datatype, &string_len);
                              ^
In file included from mpi_caf.c:44:0:
../../mpi.h:1121:5: note: expected 'MPI_Aint * {aka long long int *}' but argument is of type 'long int *'
 int MPI_Type_extent(MPI_Datatype datatype, MPI_Aint *extent);
     ^~~~~~~~~~~~~~~

In linux (which is LP64), the correct typedef of MPI_Aint is long int (see mpi.h from MPICH 3.2).  For Windows (which is LLP64), the mpi.h from the Intel MPI Windows SDK defines -DUSE_GCC to implement the correct typedef of long long int for MPI_Aint with GCC.
Intel MPI Windows SDK, mpi.h:  int MPI_Type_extent(MPI_Datatype datatype, MPI_Aint *extent);

C:\TEMP\oca\src_1.9.1\mpi>fc /L /N mpi_caf.c mpi_caf.c.original
Comparing files mpi_caf.c and MPI_CAF.C.ORIGINAL
***** mpi_caf.c
 4142:  {
 4143:    MPI_Aint string_len;
 4144:    MPI_Type_extent(*datatype, &string_len);
***** MPI_CAF.C.ORIGINAL
 4142:  {
 4143:    long int string_len;
 4144:    MPI_Type_extent(*datatype, &string_len);
*****

Question
I posted details of my build (including build of import library for impi.dll) and results at people.tamu.edu/~bmaggard, in case anyone is interested in a native Win64 CAF solution (Win7-64; mingw-w64 gfortran 7.1.0.rev2; Intel MPI Runtime 2017 Update 3; OpenCoarrays-1.9.1).  Execution results are equivalent to building 1.9.1 on linux with install.sh (Fedora 26; gcc-gfortran 7.1.1-3, MPICH 3.2, OpenCoarrays-1.9.1).
For GCC 7.1.0, my question at this time is whether I should be using any/all of the defines:  COMPILER_SUPPORTS_CAF_INTRINSICS, STRIDED, and COMPILER_SUPPORTS_ATOMICS.  Feedback appreciated on this question.

N.B.: Officially, we do not support Windows, because we don't have good access to windows machines, and are short on manpower and funding. However, we welcome any contributions to improve our unofficial windows support.
I can't remember the details, but I seem to recall that MS MPI may have some issues with MPI-3 RMA. Try searching through our closed issues for "windows" to see if you can find any relevant clues. Also, perhaps @jeffhammond or @afanfa knows more about this.
As far as appropriate defines go, for GCC 7.2 (would be same for 7.1) on mac OS, CMake generates the following compilation lines:
opencoarrays.F90: (NOT needed for GCC 7.1, unless you wish to use some special extensions)
/usr/local/bin/gfortran-7 -DGCC_GE_7 -DMPI_WORKING_MODULE -DPREFIX_NAME=_gfortran_caf_ -DUSE_FAILED_IMAGES -I/Users/ibeekman/Sandbox/opencoarrays-clean/src -I/usr/local/Cellar/mpich/3.2_3/include -I/Users/ibeekman/Sandbox/opencoarrays-clean/build/mod  -O3 -DNDEBUG -O3 -J../../mod   -c /Users/ibeekman/Sandbox/opencoarrays-clean/src/extensions/opencoarrays.F90 -o CMakeFiles/caf_mpi.dir/__/extensions/opencoarrays.F90.o

mpi_caf.c: (should be all you really need...)
/usr/local/bin/gcc-7 -DGCC_GE_7 -DMPI_WORKING_MODULE -DPREFIX_NAME=_gfortran_caf_ -DUSE_FAILED_IMAGES -I/Users/ibeekman/Sandbox/opencoarrays-clean/src -I/usr/local/Cellar/mpich/3.2_3/include -I/Users/ibeekman/Sandbox/opencoarrays-clean/build/mod  -O3 -DNDEBUG   -o CMakeFiles/caf_mpi.dir/mpi_caf.c.o   -c /Users/ibeekman/Sandbox/opencoarrays-clean/src/mpi/mpi_caf.c

For GCC 7.1.0, my question at this time is whether I should be using any/all of the defines: COMPILER_SUPPORTS_CAF_INTRINSICS, STRIDED, and COMPILER_SUPPORTS_ATOMICS. Feedback appreciated on this question.

Here is a guide to the defines you should and should not be using:

GCC_GE_7 Set this define if building against GFortran >= 7.0
MPI_WORKING_MODULE Unless the windows MPI SDK ships with an mpi.mod generated by GFortran 7.x you should NOT set the define. (It shouldn't have any impact on mpi_caf.c, however.)
PREFIX_NAME should be set to _gfortran_caf_ when compiling for GFortran >= 5.2, should be the same on Windows
USE_FAILED_IMAGES should NOT be set, unless you're confident that windows MPI has support for experimental/proposed MPI features required to support fault tolerant failed images in Fortran 2015(?). I would strongly recommend NOT defining this for your windows build. Right now, there is a private fork of the OpenMPI fault tolerance project that has working experimental features to support failed images and MPICH 3.2. I am unaware of any other MPI implementations with sufficient support for the proposed experimental MPI features required to be able to enable failed images in OpenCoarrays.
STRIDED is for an experimental more efficient transfer of strided coarrays. I'm not sure if the implementation is 100% complete, @afanfa probably knows.
COMPILER_SUPPORTS_CAF_INTRINSICS is not needed except for old GCC/GFortran <= 4.9
COMPILER_SUPPORTS_ATOMICS seems to be outdated (it looks like we need to update the documentation in INSTALL.md too) to add experimental events support in GCC/GFortran <= 6 or 7, which now has native events support, I'm pretty sure. (Events were partially implemented via atomics in the coarrayfortran.F90 extensions module.) This should definitely NOT be set for GFortran 7.1.

@jbmaggard Is my understanding correct that by applying the patch wherein long int string_len; ==> MPI_Aint string_len; and adding -D_POSIX and -DUSE_GCC allow you to successfully build and run OpenCoarrays 1.9.1 on windows against Intel(R) MPI Library for Windows* OS, Version 2017 Update 3 Build 20170405? ❗ 🎉

Also, FYI, there is a script to build OpenCoarrays using WSL at https://github.com/sourceryinstitute/OpenCoarrays/blob/master/windows-install.sh

Also, this def looks like a bug in OpenCoarrays: https://www.mpich.org/static/docs/v3.2/www3/MPI_Type_extent.html

@jbmaggard one additional question: Do you anticipate those defines need to always be set on Windows? (i.e. for cygwin or other non mingw windows environments?)

@jbmaggard please let me know if https://github.com/sourceryinstitute/OpenCoarrays/pull/436/files looks like it will fix the issue.

@zbeekman Affirmative.  Using the Intel MPI Runtime, along with an import library to impi.dll allows build and run of all the src/tests examples (Win64 native, not cygwin or WSL).  Results are comparable to what I get on linux by mpiexec'ing (all of) the executables built by install.sh.
@zbeekman Thanks for the comments on compiler defines.  I started by doing a cmake, make clean, make VERBOSE=1 on linux to see exactly what gfortran, gcc, and ar command lines were being used for compile and link.
-D_POSIX is a mingw-w64 issue.  You will see the #ifdef if you take a look at signal.h.  Specifically, it was needed to have #include <signal.h> in mpi_caf.c define SIGKILL.
From intel mpi.h, on -DUSE_GCC to typedef MPI_Aint as long long int:
#ifdef MPI_AINT64_TYPE
#undef MPI_AINT64_TYPE
#endif
#if defined(USE_GCC) || defined(GNUC)
#define MPI_AINT64_TYPE long long
#else
#define MPI_AINT64_TYPE __int64
#endif
typedef MPI_AINT64_TYPE MPI_Aint;
#undef MPI_AINT64_TYPE
From mpi_caf.c on alloca.h; functionality is apparently provided elsewhere by other includes for mingw-w64:
#ifndef ALLOCA_MISSING
#include <alloca.h>        /* Assume functionality provided elsewhere if missing */
#endif

@zbeekman On the src/mpi/CMakeLists.txt changes you propose, I think it may be a little more complicated than that.

My success was with mingw-w64 GCC, not TDM or mingw (specifically about -D_POSIX)
Defining MPI_Aint in Intel MPI's mpi.h compatible with mingw-w64 gcc is why I used -DUSE_GCC
You have to build an import library to the Intel MPI runtime's impi.dll (I called it libimpi.a) using the gendef and dlltool utilities of mingw-w64.
The mingw-w64 /bin and Intel MPI /bin both have to be in the path of the cmd window, for the gfortran runtime and the Intel MPI runtime.

@zbeekman I do not consider Windows to be a relevant platform for parallel computing and know very little about how various parallel programming tools behave in that environment.  My standard recommendation for using HPC tools on Windows is to install a Debian VM in Virtual Box.  My attempts to use WSL in Windows 10 have proven unsuccessful and frustrating.

@jeffhammond sure, I guess I miss-remembered you being part of a past discussion. Thanks for the input!
@jbmaggard What do you suggest I do RE: PR #436? The change to mpi_caf.c appears to be required no matter what, and a bonafide bug, judging from various MPI documentation. I don't entirely follow your comments above, since I have zero relevant experience with Windows, and I don't know or understand all the differences between mingw, mingw-w64, TDM (?)
Am I understanding you correctly that:

-D_POSIX is mingw(-w64?) specific? CMake provides functionality to test for mingw as listed in the Variables that describe the system section of their documentation. Is it a reasonable guess that we should define _POSIX for any mingw variant?
-DUSE_GCC is needed by Intel MPI? So we should really be detecting Intel MPI rather than windows to decide whether we need to add this definition? Do you know if this is true on *nix platforms too? If so any ideas on how to do system introspection to detect the Intel MPI runtime? (@jeffhammond do you have any thoughts on this? Feel free to ignore my inquiries if you're not inclinde to, BTW)

As far as alloca.h goes it's for allocating memory on the stack thats automatically freed, and different platforms provide this functionality in different ways. For instance FreeBSD includes this in libc: https://www.freebsd.org/cgi/man.cgi?query=alloca&apropos=0&sektion=0&manpath=FreeBSD 6.1-RELEASE&format=html

I hope you don't mind but I'm uploading your notes on Windows MPI + caf here for future reference.
Step3_oca_windows_results.txt
Step2_oca_windows_build.txt
Step1_oca_linux.txt
Notes_gfortran_msmpi.txt
I also asked the CMake folks for Intel MPI introspection advice: https://gitlab.kitware.com/cmake/cmake/issues/17189

@zbeekman I've tried to keep my comments to facts.  That is why my original post was only about something I was certain was an error in mpi_caf.c, based on the mpi.h of MPICH 3.2.
My hope in posting was that OpenCoarrays will use this correction as a way to go forward without making the code specific to linux (not LP64 only).  Since Intel MPI is at least available on many high performance clusters, and works with gfortran and OpenCoarrays, I thought it might be of interest to the project that the Windows Intel MPI can work with 1.9.1 and gfortran for a native Win64 CAF.
I make no claims to expertise on open source for the Win64 platform, but I'll to help as I can.
I've been using mingw-w64 for only a few months, but with very good success.  I plead ignorance as to whether -D_POSIX applies to any native Win64 toolchains other than mingw-64 (other native Win64 toolchains include TDM, mingw, msys2-mingw-w64).
On -D_POSIX, I observed a compile error that SIGKILL was undefined, and looking at signal.h, observed that -D_POSIX would fix that on mingw-w64.
The -DUSE_GCC is specifically for the Intel Windows MPI typedef of MPI_Aint in mpi.h, which is why I excerpted a few relevant lines from mpi.h at the part where the typedef of MPI_Aint is made.  Looking at mpi.h from Microsoft MPI SDK (8.1) for windows indicates that Microsoft does something similar for the typedef of MPI_Aint, using -D_WIN64.
Microsoft MPI (8.1) defines MPI_VERSION as 2, and my experience indicates that trying to compile mpi_caf.c (1.9.1) with mpi.h from Microsoft MPI results in several missing defines and "implicit procedure" errors.
Intel Windows MPI Runtime (2017, Update 3) indicates it is MPI-3.1, and its mpi.h sets MPI_VERSION 3.  I do know that with the import library to impi.dll, OpenCoarrays 1.9.1 can be used to build CAF applications.
I don't really know what might be a good choice going forward if  this project wants to have a cmake build of a native Win64 OpenCoarrays.  I will try to put together some thoughts on this an make a post when I have a few facts.

@zbeekman
On going forward with a native Win64 "install.sh" type of install, it looks like MSYS2 might work well for the project, as it provides a bash shell, cmake, gnu make, current GCC, etc.  It appears that MSYS2/mingw64/GCC-7.2.0 is a native x86_64-posix-seh toolchain built from (or at least very similar to) the mingw-w64 project.  I don't know very much about cmake (MSYS2 has 3.9.1 as mingw64/), but I did post my notes on installing MSYS2, building native Win64 libcaf_mpi, and documented testing of natively compiled and linked Win64 CAF programs with the same examples under src/tests as built by install.sh on linux; using Win7-64, updated MSYS2/mingw64/GCC-7.2.0, Intel MPI Runtime 2017, Update 3 (by creating an import library interfacing impi.dll), and OpenCoarrays-1.9.1.zip.  Detailed notes are posted at people.tamu.edu/~bmaggard in the hpc/oca folder.
On the topic of introspection for cmake, the install of the Intel MPI Runtime sets the I_MPI_ROOT environment variable to the location where .\intel64\bin\impi.dll is installed.  If/when Microsoft MPI reaches a point of development compatible with OpenCoarrays, it may be noteworthy that its install sets the MSMPI_BIN environment variable to point to the location where .\msmpi.dll is located.

Apologies for joining this discussion late. I haven't ready every post in detail, but I would like to provide context that I hope is helpful.  It suggest we support all platforms but add significant caveats regarding non-HPC platforms or uncommon platforms.  For example,  we could require that addressing issues on such platforms be handled via user contribution of code or funding.
I will be the technical lead on a PDE solver project project starting soon with the following amongst its requirements and preferences for the application code:
Requirements:

Open-source.
Parallel.
Works on Windows and Linux.

Preferences:

Modern Fortran.

Because this list relates to the application, it doesn't constrain the compiler or runtime library.   However, it makes coarray Fortran and gfortran/OpenCoarrays very attractive .  It therefore makes sense to consider Windows supported whenever made feasible via user contributions of code or funding. As a fallback, if Windows proves infeasible, then the aforementioned project could require the Intel compiler be used on Windows, but that precludes the use of the Fortran 2015 parallel features that gfortran and OpenCoarray support.

@afanfa
In the first reply above, zbeekman says:
STRIDED is for an experimental more efficient transfer of strided coarrays. I'm not sure if the implementation is 100% complete, @afanfa probably knows.
Please comment, especially with regard to GCC 7.2, MPICH 3.2, and Intel MPI 2017, Update 3.
Excerpted from mpi.h (Intel MPI 2017, Update 3)
#define MPI_SUBVERSION 1
#define MPICH_NAME     3
#define MPICH         1
#define MPICH_HAS_C2F  1

/* MPICH_VERSION is the version string. MPICH_NUMVERSION is the
 * numeric version that can be used in numeric comparisons.
 *
 * MPICH_VERSION uses the following format:
 * Version: [MAJ].[MIN].[REV][EXT][EXT_NUMBER]
 * Example: 1.0.7rc1 has
 *          MAJ = 1
 *          MIN = 0
 *          REV = 7
 *          EXT = rc
 *          EXT_NUMBER = 1
 *
 * MPICH_NUMVERSION will convert EXT to a format number:
 *          ALPHA (a) = 0
 *          BETA (b)  = 1
 *          RC (rc)   = 2
 *          PATCH (p) = 3
 * Regular releases are treated as patch 0
 *
 * Numeric version will have 1 digit for MAJ, 2 digits for MIN, 2
 * digits for REV, 1 digit for EXT and 2 digits for EXT_NUMBER. So,
 * 1.0.7rc1 will have the numeric version 10007201.
 */
#define MPICH_VERSION "3.2"
#define MPICH_NUMVERSION 30200300

#define MPICH_RELEASE_TYPE_ALPHA  0
#define MPICH_RELEASE_TYPE_BETA   1
#define MPICH_RELEASE_TYPE_RC     2
#define MPICH_RELEASE_TYPE_PATCH  3

#define MPICH_CALC_VERSION(MAJOR, MINOR, REVISION, TYPE, PATCH) \
    (((MAJOR) * 10000000) + ((MINOR) * 100000) + ((REVISION) * 1000) + ((TYPE) * 100) + (PATCH))

/* I_MPI_VERSION is the version string. I_MPI_NUMVERSION is the
 * numeric version that can be used in numeric comparisons.
 *
 * I_MPI_VERSION uses the following format:
 * Version: [MAJ].[MIN].[REV][EXT][EXT_NUMBER]
 * Example: 2017.0.0b0 has
 *          MAJ = 2017
 *          MIN = 0
 *          REV = 0
 *          EXT = b
 *          EXT_NUMBER = 0
 *
 * I_MPI_NUMVERSION will convert EXT to a format number:
 *          ALPHA (a) = 0
 *          BETA (b)  = 1
 *          RC (rc)   = 2
 *          PATCH (p) = 3
 * Regular releases are treated as patch 0
 *
 * Numeric version will have 4 digits for MAJ, 2 digits for MIN, 2
 * digits for REV, 1 digit for EXT and 2 digits for EXT_NUMBER. So,
 * 2017.0.0b0 will have the numeric version<PHONE_NUMBER>0.
 */
#define I_MPI_VERSION "2017.0.3"
#define I_MPI_NUMVERSION 0

@rouson
Excerpted from your previous comment above:

As a fallback, if Windows proves infeasible, then the aforementioned project could require the Intel compiler be used on Windows, but that precludes the use of the Fortran 2015 parallel features that gfortran and OpenCoarrays support.

Could you add a bit of detail on Fortran 2015 parallel features supported by gfortran (version specific please) with OpenCoarrays, that go beyond current ifort capabilities?
I've been successful building libcaf_mpi.a on the ada custer (CentOs 6, GCC 6.4.0, Intel MPI 2017 Update 3, OpenCoarrays 1.9.1), and am considering a presentation to share with HPRC staff.
On a side note, that might be more appropriate through a different channel, I am highly interested in PDE solution...  I'd be fascinated to hear more about problem being solved, approach, methods, etc.

Could you add a bit of detail on Fortran 2015 parallel features supported by gfortran (version specific please) with OpenCoarrays, that go beyond current ifort capabilities?

Intel 17 support for 2015 features seems to be limited to ISO/IEC TS29113:2012, Further Interoperability with C (16.0), although the page looks pretty old (Oct. '16): https://software.intel.com/en-us/articles/intel-fortran-compiler-support-for-fortran-language-standards I haven't tried any F2015 features with ifort, so I can't comment as to whether or not this is an up to date document.
From TS 18508 the following are the major F2015 additional parallel features:

EVENTS: Events have been part of OpenCoarrays and GFortran since at least Oct. 2016. With OC 1.9.1 & MPICH 3.2 they work with GFortran 6.4 and 7.2 on macOS. This is probably the most important feature, since it gives you finer grained & performant control of execution segment ordering. An example of its utility is outlined below
FAILED_IMAGES(): This requires GFortran >= 7.1, OC >= 1.9.0 and MPI with user level failure mitigation (ULFM) support. ULFM is a proposed/experimental MPI feature, and is only supported by recent MPI implementations. For MPICH you need 3.2 with this patch applied or to use the head/master version. The utility of failed images is not as powerful without teams support
TEAMS: Work has started on teams (compiler side and OC side) but it likely will be limited to the 8.x release, and will not be ready for O(months).

More on the utility of events:
For example, if you have a FD or FV code for the solution of PDEs with a traditional domain decomposition, each image can use events to determine when to do a halo exchange with its neighbor. The images can use puts, which are non blocking, to give their neighbors the data they need, and then event_post to tell the neighbor that the data is ready. This way each image can attempt to overlap communication with computation and prioritize, in the following order:

Consuming data available in halo exchange buffers if available, to free them for it's neighbors, using events to check if the data has been sent yet, and to ack that it has been consumed and the buffer(s) freed
Perform interior computations needed to send halo data needed by neighboring images, and send the data, using event_post() to indicate that the remote image's buffer has been populated with halo exchange data
If neither of the above actions can be taken compute a portion of the interior domain, if there is work left to do
If the interior domain is finished enter a spin-wait loop, to check each remaining halo exchange buffer for new data using event_query()

This way, each image tries to get out of the way for the other image as quickly as possible, and will perform its own local work while it waits on remote data if any work is left to do. You can introduce two buffers for each halo exchange region (N, W, S, E, up, down, NW, SW, SE, NE, etc.) similar to a double-buffered read, so that you can put data even if the remote image has yet to consume the current time-steps data held in that buffer. Using defined assignment, data dependencies can be handled completely automatically with this scheme.

@zbeekman
Thanks for detailed response on Fortran 2015 features implemented with gfortran and OpenCoarrays.
Above, you said:

STRIDED is for an experimental more efficient transfer of strided coarrays. I'm not sure if the implementation is 100% complete, @afanfa probably knows.

@afanfa
Any comment on status of the STRIDED compiler define?  I observe that the last sentence of the latest installation instructions (1.9.2) says:

In order to activate efficient strided-array transfer support, uncomment the -DSTRIDED flag inside the make.inc file.

I suspect we may need to edit our INSTALL.md again.... Your best bet is to avoid strided transfers if you can (for efficiency) and if you do need them and try -DSTRIDED I think it's not 100% complete in implementation (i.e. puts, gets, and getputs)

@zbeekman
Good job on 1.9.2 release.  I like the improvements to install.sh.  With the SOVERSIONing system, is GCC7 now supported?  I observe that acceptable_compiler.f90 still has < 7.0.0.

OK, this is a bit of a long story... GCC 7 has been supported since 1.9.0, BUT for the average everyday user we default to the 6.x branch. Perhaps we're at the point where enough bugs have been fixed, but only for the 7.x branch to outweigh the outstanding regressions in 7.x. To me, the biggest issue with 7.x is #292. What happened with #292 is that to support allocatable components and further optimization (and perhaps other reasons, this change was made to GFortran without consulting us... or at least the majority of us)  the responsibility for type conversion during coarray assignments was moved from GFortran to the -fcoarray=lib library. What this means is that Assignments involving coarrays with type conversions will fail when using 7.x. In my mind this is a pretty substantial issue, so we point most users at the 6.x branch when they install OpenCoarrays with the super user friendly (we hope) install.sh script.
If you want to install OpenCoarrays with GFortran 7.x you have a few options.

Use a packaged version. I know Homebrew installs OpenCoarrays using the latest GCC which is 7.x by default.
Build via CMake. Make sure to set FC and CC to what/where GFortran and GCC are on your system, and that your MPI is setup (on your PATH, module loaded, etc.)
Use install.sh and pass the flags specifying the compilers to point to the GCC 7.x toolchain and pointing it to a compatible MPI installation. (install.sh --help gives the short and long options for these. I only remember the short options for the compilers off the top of my head: -f /path/to/fortran/compiler, -c /path/to/c/compiler -C /path/to/c++/compiler)

Oh, also I need to look into the code for acceptable_compiler.f90...
Perhaps we stopped using it? Or more likely there is some strange bug.
On Mon, Sep 25, 2017 at 5:32 PM jbmaggard<EMAIL_ADDRESS>wrote:

@zbeekman https://github.com/zbeekman
Good job on 1.9.2 release. I like the improvements to install.sh. With the
SOVERSIONing system, is GCC7 now supported? I observe that
acceptable_compiler.f90 still has < 7.0.0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sourceryinstitute/OpenCoarrays/issues/435#issuecomment-332019902,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAREPJB3KgSm9yGhVhwxkeBVxkreUyhQks5smBvogaJpZM4O8ccU
.

@vehre Please give us an update regarding whether you'll have time soon to work on issue #292.

I had some time on the weekend and am looking forward to find some on Tuesday, which is a bank holiday in Germany.


Text sometimes gets overlapped by navigation bar (in landscape orientation)

[x] I am able to reproduce it
[x] I have verified the issue exists on the latest version

Version used:
Latest version at the moment,  1.10.0
Android version:
Android 8.0, Nexus 6P
When rotating the screen, navigation buttons can overlap the text (as if the navigation bar is not accounted for in some cases). See attached image.

Tracking in #227


Update source to 1.0.173

We shouldn't squash version bumps like this as it erases source history. I've rebased on top of the new version and cherry picked your changelog update.

what do mean
"We shouldn't squash version bumps like this as it erases source history."
are you saying to separate the changelog entry away from the actual version bump?


edge case:  Innert disabled* being true when 00:00 selected

Hi,
Thanks for publishing this project.
If you don't set the disabledFrom or disabledTo inputs; and you have a CTO who likes doing things "at" midnight (i.e. he choose 00:00:00); the validation (which isn't enabled) will still say that its an error.
I resolved this on my copy of the source by adding to the top of isDisabled()
if(this.disabledFrom ==='' && this.disabledTo==='') { return false; }

I didn't include a unit test; but I have been running with this extra line of code for some time

Assuming pencilpix has merged, no further action taken


Publisher endpoint perhaps misleadingly suggests publisher has no errors, when they do have validation issues

Describe the bug
The publishers.json endpoint states that a publisher has no errors with their data, though the publisher page shows that they have validation issues.
To Reproduce
Steps to reproduce the behaviour:

Go to https://iati-canary.herokuapp.com/publishers.json?q=worldbank&errors=true
See that error_count: 0
Go to https://iati-canary.herokuapp.com/publisher/worldbank
See that 80 datasets have validation issues

Expected behaviour
Show that 80 datasets have validation issues in the publisher endpoint for the World Bank

Sounds good! The code for the looks absolutely baffling. Happy to accept a pull request! ;)


[Papercut][SW-15814] Fix sorting of filters in categories if using el…

in addition to https://github.com/shopware/shopware/pull/749

@mitelg is this still relevant?


Release new version

Hello!
At first, thank you and all contributors for your great job!
Can you release new version and publish new binaries? I need feature about select from yaml file and I am using Ansible role which needs to have URL for latest binary.
I can for, build, release new version and working with my fork. But it's not a true way. :)
Thank you, @wrouesnel.

I have the same situation. It would be great if the latest release is available in binary!

There's a few open issues I need to resolve first, which requires a clean up of the CI test builds to make sure I cover off first.

Released version 0.1.1 yesterday and published to docker.

@wrouesnel  thank you! 👍


update to latest jsPDF in Export PDF example

point to the latest version and need to change the name of the global variable ... ?
it's seems work for me please re-check ...

@jipexu - you’ll need to base your branch on a more recent commit to get the above failing security check to pass.
You can do this in a number of ways.  Here is one:
git pull --rebase openlayers main
git push --force origin main

This assumes you have named this remote openlayers and your own remote origin.

@tschaub thanks ! Definitely I still have a lot of trouble to work effectively with this tool ... I always forget something ... Well, I am trying to do something cleaner.

It is usually good practice to use a defined stable version and update periodically to new versions after checking compatibility.  latest links can change at any time and break applications - for example if the latest mapbox-gl.js was used in the Mapbox-gl Layer example a Mapbox API key would now be needed in addition to the MapTiler key, and the latest jszip would not work in the KMZ Drag-and-Drop example.

Another (maybe better) option would be to add jspdf to devDependencies (npm install --save-dev jspdf) and import jspdf from 'jspdf' instead of using the cdn version.

It is usually good practice to use a defined stable version and update periodically to new versions after checking compatibility. latest links can change at any time and break applications - for example if the latest mapbox-gl.js was used in the Mapbox-gl Layer example a Mapbox API key would now be needed in addition to the MapTiler key, and the latest jszip would not work in the KMZ Drag-and-Drop example.

@mike-000 thanks you are right  i hesitated to point the latest or the 2.2.0 ... so point to the 2.2.0 is better

Another (maybe better) option would be to add jspdf to devDependencies (npm install --save-dev jspdf) and import jspdf from 'jspdf' instead of using the cdn version.

@ahocevar  sorry but this is  much more than my technical level ... ;-(  so i can not help more for this option

close by #12417  thanks @ahocevar


JSON value for "nearest-station" : 0 ??

In the JSON for the API, the "nearest-station" value seems to be always set to zero.  Is this just because the value is not being currently calculated, so defaults to zero?  If so, is it possible to set the value with respect to the station providing the "currently" value set?

At the moment PirateWeather only integrates model data and does not use station data in the API which is why that value is always zero.
I do not see anything in the road map that station data will be added in the future and I'm not sure how difficult it would be for @alexander0042 to integrate.

Thanks @cloneofghosts for the quick reply here! You also nailed the answer- the API currently uses gridded model results, so there aren't any "station", per se. It's something that I've been thinking about including, but not presently on the roadmap, so not in the immediate future.


Geocoder status: "Invalid request to geocoder" (Android device)

For two days I've been trying to do reverse-geocoding with this plugin. The problem is that I keep getting an "Invalid request to geocoder" status.
I've been all over the documentations:

Google API: https://developers.google.com/maps/documentation/geocoding/intro#ReverseGeocoding
The cordova plugin googlemaps Wiki: https://github.com/mapsplugin/cordova-plugin-googlemaps/wiki/Geocoder
Google API Errors: https://developers.google.com/maps/documentation/static-maps/error-messages#invalid-requests

This is where I call the geocode function:

$scope.codeLatLng = function codeLatLng(lat, lng) {
                //var latlng = {lat: parseFloat(lat), lng: parseFloat(lng)};
                var latlng = new plugin.google.maps.LatLng(lat, lng);
                $scope.geocoder.geocode({'latLng': latlng}, function(results, status) {
                    if (status == 'OK') {
                        alert(results);
                        alert(results[1]);
                        if (results[1]) {
                            //formatted address
                            alert(results[0].formatted_address);
                            //find country name
                            for (var i=0; i<results[0].address_components.length; i++) {
                                for (var b=0;b<results[0].address_components[i].types.length;b++) {
                                    //there are different types that might hold a city admin_area_lvl_1 usually does in come cases looking for sublocality type will be more appropriate
                                    if (results[0].address_components[i].types[b] == "administrative_area_level_1") {
                                        //this is the object you are looking for
                                        $scope.city = results[0].address_components[i];
                                        break;
                                    }
                                }
                            }
                            //city data
                            alert($scope.city.short_name + " " + $scope.city.long_name)
                        } else {
                            alert("No results found");
                        }
                    } else {
                        alert("Geocoder failed due to: " + status);
                    }
                });
            }

I tried changing the "latlng" parameter in the request to "location" and I tried changing the object latlng to an object with "lat" and "lng" properties. No success.
I am working with ionic and installed the plugin with Cordova. I also haven't included any script in my index.html because I understand that the plugin doesn't require it.
Config.xml:
<plugin name="cordova-plugin-geolocation" spec="~2.4.0" />
<plugin name="cordova-plugin-googlemaps" spec="https://github.com/phonegap-googlemaps-plugin/cordova-plugin-googlemaps">
        <variable name="API_KEY_FOR_ANDROID" value="A***Sy****skPRHO*****CEJcaA****jyCo" />
        <variable name="API_KEY_FOR_IOS" value="" />
        <variable name="NSLOCATIONWHENINUSEUSAGEDESCRIPTION" value="Show your location on the map" />
        <variable name="NSLOCATIONALWAYSUSAGEDESCRIPTION" value="Trace your location on the map" />
</plugin>

I also checked to see that my API key wasn't restricted as the app is signed with a debug keystore. When I will go to production I will change the key to my restricted production key.

geocoder.geocode({'position': latlng}

@wf9a5m75 Thanks for the quick reply. I changed it and now I get status == undefined. Any ideas?

This plugin does not return the second argument

You misunderstand this plugin is not the same as JavaScript API.

@wf9a5m75
Thank you so much man! I followed the Wiki and now understand how it works. Appreciate it!


Bug Report:

Please check for duplicates or similar issues, as well performing simple troubleshooting steps (such as clearing cookies, clearing AppData, trying another browser) before submitting an issue.
If you are playing a downloaded version of the game, what operating system are you using?
Windows (x86), Windows (x86_64), Linux, or macOS? Specify below.
windows 10 x64 bit
What version of the game are you using? Look in the bottom left corner of the main menu.
dnb 3.0b
Have you identified any steps to reproduce the bug? If so, please describe them below. Use images if possible.
no
Please describe your issue. Provide extensive detail and images if possible.
source/PlayState.hx:292: characters 12-24 : Type not found : VideoHandler
source/LoadingState.hx:18: lines 18-226 : ... Defined in this class
source/StoryMenuState.hx:260: characters 17-29 : Type not found : VideoHandler
source/CompatWarningState.hx:27: characters 72-73 : Int should be flixel.util.FlxAxes
source/CompatWarningState.hx:27: characters 72-73 : ... For optional function argument 'repeatAxes'
source/Note.hx:339: characters 18-28 : Class has no field scrollType
source/SelectLanguageState.hx:34: characters 70-71 : Int should be flixel.util.FlxAxes
source/SelectLanguageState.hx:34: characters 70-71 : ... For optional function argument 'repeatAxes'
nothing edited

nvm people will probably not respond so god dang it

don’t make issues about the mod here since this is more for the engine instead

please don’t make issues about the mod here since this is more for the engine instead

well, its literally the same thing. it puts the same error

please don’t make issues about the mod here since this is more for the engine instead

well, its literally the same thing. it puts the same error

the code for the engine has been modified a lot from DNB

makes sense, ill try to compile from the engine

makes sense, ill try to compile from the engine

alright

oh the engine works ok i was gonna post a error of why i couldnt install hscript and then saw there was a github res for it so i git from that and it worked

oh the engine works ok i was gonna post a error of why i couldnt install hscript and then saw there was a github res for it so i git from that and it worked

👍🏻


fix line order for fgd export

Small fix, Line order of the @tool hint seems to be preventing the file from loading, this allows the export of fgd to work again for me.

Look good, thanks!


Revert Cmd+Enter shortcut for Send in Mail?

Hi
I think that I saw an issue/comment about this shortcut not working in Mavericks (but I can't find it in this repo strangely) so apologies in advance for creating a dupe...
Originally I tried commenting out the override in .osx 4267ea9582e3bac8ad70cae1048eedbbe367090e but that didn't work so I tried setting it with the unicode values for Cmd+Shift+D but I must be doing it wrong as this doesn't work either.
defaults write com.apple.mail NSUserKeyEquivalents -dict-add "Send" -string "@\\U2318 @\\U21E7 @\\U0064"

It'd be nice to have the keyboard shortcut to Send in Mail back... Any help would be great - thanks.

This had been fixed for a while but I forgot that this issue was still open!


Safari UI fix

Summary:
Please summarize the scope of the changes you have submitted, what the intent of the work is and anything that describes the before/after state of the project.
Type of change:
Please delete options that are not relevant.

[ ] New capability
[x] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team
Summary by Sourcery
Fix UI issues in Safari by adjusting CSS styles for input elements and improve demo readability by importing the non-minified JavaScript file.
Bug Fixes:

Fix UI rendering issues in Safari by updating CSS styles to use transparent colors for input border and container.

Enhancements:

Update demo HTML to import the non-minified JavaScript file for better readability and debugging.

Hey @rmenner - I've reviewed your changes - here's some feedback:
Overall Comments:

The change from 'index.min.js' to 'index.js' in the import statement could potentially impact performance. Is this intentional, perhaps for development purposes?

Here's what I looked at during the review
Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

This has been fixed. Cleaned up the build to include the index.min.js

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


FrameHandle abs position info correction

https://github.com/wurstscript/WurstStdlib2/blob/41572ac812d296a9a8a8d879be0608e1b4a27e62/wurst/_handles/Framehandle.wurst#L76
(0, 0) is the bottom left corner of the 4:3 screen.
(0.6, 0.6) the top right corner of the 4:3 screen.

@Krypt0n

Okay the screen max position is (0.8,0.6) since the screen is 4:3

might be true now, i had not time to test wiht new wc3 version, it should be intented to be .8, .6 but in first ptr 1.31 version only .6 .6 was addressable


EXC_BAD_ACCESS when repeatedly using Future

Hello folks. I am investigating an issue where I can trigger iOS to crash with an EXC_BAD_ACCESS when repeatedly using Futures.
From OpenCombineTests.swift in my sample project repo:
import XCTest
import OpenCombine

private class Item {}

final class OpenCombineTests: XCTestCase {
    func testBadAccessSimplified() async {
        let item = await Future<Item, Never> { promise in
            DispatchQueue.global().async {
                promise(.success(Item()))
            }
        }
        .value
    }
}

If I run this test case repeatedly until failure with enough iterations (10000+), an EXC_BAD_ACCESS will (most likely) occur. See screenshot:

For context, this behavior also occurs when running with Apple's Combine. I haven't had much luck finding anyone who can help me understand what's going on here, so I am creating an issue here as I figure you folks might be able to help. 🙏
Notes:

I have also been able to reproduce this issue a normal application lifecycle context
As far as I can tell, the issue seems limited to Combine or OpenCombine usage. I have not been able to reproduce similar behavior with any other async library/solution.

Related links:

See Swift forum thread
See GitHub sample project

I think the issue might be caused by accessing the Future's result from the Conduit from outside of the Future's lock here. Strangely neither the Address nor Thread sanitizers are able to catch this.

I think the issue might be caused by accessing the Future's result from the Conduit from outside of the Future's lock here. Strangely neither the Address nor Thread sanitizers are able to catch this.

Hi @tarbaiev-smg. To clarify, are you thinking this issue is a bug with OpenCombine, or with my usage of Future? If it's the latter, can you please help me understand exactly what I'm doing wrong? Thank you!

Definitely the implementation, both Combine and OpenCombine. I spent a weekend investigating this exact issue.


GCE: Retrieve regions & zones lazily, closes #1661

Lazily retrieve zones & regions on GCENodeDriver
Description
Implements #1661
Status

done, ready for review

Checklist (tick everything that applies)

[x] Code linting (required, can be done after the PR checks)
[ ] Documentation
[ ] Tests
[x] ICLA (required for bigger changes)

Done @dpeschman-godaddy

LGTM, thanks. And thanks to @dpeschman-godaddy for a review.


Logos at Advisory Group should be center.

Description
As you can see in screenshot bellow, the logos are not center.

@diamanthaxhimusa I think is not correct part of code what you have use the columns inside rows. So, I hope that I explained you this part enough to understand and to improve that.

The space between logos in row 3 is not sam.

The logos on the third row is more large than others logos

The logo SEHD has a very small size.


i3dm: add support for SCALE and SCALE_NON_UNIFORM per instance

see https://github.com/CesiumGS/3d-tiles/tree/master/specification/TileFormats/Instanced3DModel#instance-semantics

fixed


sorted_vec_set: finish changing to a container adapter

Summary
Fixes sorted_vector_set and adds tests.
Test plan

make test-devel
CI
D43547429

Codecov Report

Merging #80 (7e2475e) into main (878b9bf) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #80      +/-   ##
==========================================
- Coverage   33.37%   33.35%   -0.02%
==========================================
  Files          38       38
  Lines        6259     6259
  Branches     3440     3440
==========================================
- Hits         2089     2088       -1
  Misses       2292     2292
- Partials     1878     1879       +1

Impacted Files
Coverage Δ

src/TreeBuilder.cpp
47.66% <100.00%> (ø)

src/OICodeGen.cpp
38.38% <0.00%> (-0.05%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Docs: improve client doc

The documentation says that when using .stream you'll receive
a Stream[F, Http1Client], this is false. The method returns a
Client[F].
I've also added the type on the val below just to make it obvious
what you have at this point. To me, it was not when I first reached
into the doc.

Sorry @ChristopherDavenport , I totally forgot the type parameter.

Is there anything else I can do regarding that PR?

Wow this one slipped my apologies

No apologies required, thanks to you both


document seems to have error with respect to timeout

py-filelock documentation has following information.
timeout (float) – The maximum time waited for the file lock. If timeout <= 0, there is no timeout and this method will block until the lock could be acquired. If timeout is None, the default timeout is used.
However in actual code when timeout = 0  filelock doesn't wait and raises Timeout exception if lock is acquired by someone else, which seems right but doesn't match with documentation.
So documentation should say following.
timeout (float) – The maximum time waited for the file lock. If timeout < 0, there is no timeout and this method will block until the lock could be acquired. If timeout is None, the default timeout is used.

Thank you, will be fixed in the next version.


ui-components dioxus' latest version(0.5) makes build fail

The build fails unless the dioxus version is pinned to the 0.4 series.

$ cargo run
warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2021 which implies `resolver = "2"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions
   Compiling db v0.1.0 (/workspace/crates/db)
   Compiling ui-components v0.1.0 (/workspace/crates/ui-components)
error: Expected a valid body node.
       Expressions must be wrapped in curly braces.
  --> crates/ui-components/src/layout.rs:31:13
   |
31 |             &cx.props.children
   |             ^

error: missing trailing comma
  --> crates/ui-components/src/users.rs:24:25
   |
24 |                         cx.props.users.iter().map(|user| rsx!(
   |                         ^^

error[E0412]: cannot find type `Scope` in this scope
  --> crates/ui-components/src/layout.rs:12:23
   |
12 | pub fn Layout<'a>(cx: Scope<'a, AppLayoutProps<'a>>) -> Element {
   |                       ^^^^^ not found in this scope
   |
help: consider importing this struct
   |
3  + use std::thread::Scope;
   |

error[E0412]: cannot find type `Scope` in this scope
  --> crates/ui-components/src/users.rs:12:16
   |
12 |     fn app(cx: Scope<Props>) -> Element {
   |                ^^^^^ not found in this scope
   |
help: consider importing this struct
   |
1  + use std::thread::Scope;
   |

warning: unused import: `crate::layout::Layout`
 --> crates/ui-components/src/users.rs:1:5
  |
1 | use crate::layout::Layout;
  |     ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error[E0107]: type alias takes 0 lifetime arguments but 1 lifetime argument was supplied
  --> crates/ui-components/src/layout.rs:9:15
   |
9  |     children: Element<'a>,
   |               ^^^^^^^---- help: remove these generics
   |               |
   |               expected 0 lifetime arguments
   |
note: type alias defined here, with 0 lifetime parameters
  --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/dioxus-core-0.5.1/src/lib.rs:46:14
   |
46 |     pub type Element = Option<VNode>;
   |              ^^^^^^^

error[E0478]: lifetime bound not satisfied
 --> crates/ui-components/src/layout.rs:6:10
  |
6 | #[derive(Props)]
  |          ^^^^^
  |
note: lifetime parameter instantiated with the lifetime `'a` as defined here
 --> crates/ui-components/src/layout.rs:7:27
  |
7 | pub struct AppLayoutProps<'a> {
  |                           ^^
  = note: but lifetime parameter must outlive the static lifetime
  = note: this error originates in the derive macro `Props` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0107, E0412, E0478.
For more information about an error, try `rustc --explain E0107`.
warning: `ui-components` (lib) generated 1 warning
error: could not compile `ui-components` (lib) due to 10 previous errors; 1 warning emitted
warning: build failed, waiting for other jobs to finish...

I also needed to downgrade for the example to work.  I almost got it converted over but will still having some issues on the users.tier().map() part.  The Dioxus site got me most of the way there but decided to keep moving forward and come back to this issue later.  I am guessing one of use could do a PR once we figure out what needs to be updated.
https://dioxuslabs.com/learn/0.5/migration/props

That should work now.


MessageTooBig

Also i got such response from GCM
{ statusCode: 200,
  statusMessage: 'OK',
  body: '{"multicast_id":6777736059144782845,"success":0,"failure":1,"canonical_ids":0,"results":[{"error":"MessageTooBig"}]}' }

For simple payload - "Hello". Encoded payload is too big, any way to resolve it? I understand that encrypted payload is big, but how to pass normal data in this case? But sometimes for same payload it works...

The relevant specifications (and GCM for older Google clients) all specify that the maximum size is 4096 bytes (and that in practice it should be slightly lower due to encoding).
Are you sure your payload is <4kb after encryption?

It problem can be closed.
We use base64 url encode for raw_data. It was wrong. Classic base64 help resolve it issue. Thanks.
{code}
body = JSON.stringify({
"registration_ids": ["cIKD0Ykm2ZI:APA91bG-OP...."],
"raw_data": payload.ciphertext.toString('base64')
});
{code}


Prepare 0.6 release

Remaining action items:

[x] move release notes to 0.6 directory
[x] build docs locally; proofread the release notes
[x] merge this PR
[x] tag the release
[ ] git checkout main
[ ] git pull
[ ] git show (verify it's the commit we want to tag)
[ ] git tag -a 0.6.0 -m "Circuit Knitting Toolbox 0.6.0"
[ ] git show (double/triple check the tag is on the correct branch)
[ ] git push origin 0.6.0
[ ] Wait for CI to finish. The release should then be available on GitHub and pypi.
[ ] create the stable/0.6 branch
[ ] start with same commit as above checked out
[ ] git checkout -b stable/0.6
[ ] git show (check before pushing)
git push --set-upstream origin stable/0.6
get docs to deploy from the new stable branch (should happen automatically at this point after CI runs both on the new
stable branch and then on the gh-pages branch)

Previous release PR: https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/pull/438

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 93.541%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2346

Relevant Lines:
2508

💛  - Coveralls


Misc updates

Updates
    - Bugfix: Rate limit exceeded
    - Bugfix: only last message was being returned because messages were not being appended to list.
    - Refactor: Moved code_systems and client to top of file: (i) for easy access, (ii) in case of client, it needs to be constructed only once.
    - Refactor: Removed some unused comments
    - Refactor: Misc code simplifications, variable renames, comments.
    - Update: Added caching
    - Update: Saved raw results as well
    - Update: Added error and info messages
    - Update: Added the rest of explicit keywords as described in requirements

@rohaher @DaveraGabriel Did some updates today. I have some new results:
no messages found.txt
zulip_raw_results.csv
zulip_report1.csv

Just realized there's a bug in the report. It's not summing up the results correctly. I can fix that


Why data from users cannot store in database

Hi thanks man for making this, my quick question is why the data cannot store in database in other hand you provide folder database, what do i wrong here please guide me ?
Thanks

Well you can save the data in database  and  that's why the database schema is provided.The demo of the library doesn't  include storing user data in database, it stores data in session.You can modify the code depending upon your requirement.


vendor: update opencontainers/runtime/specs-go

runv reports error when create container.
"docker: Error response from daemon: json: cannot unmarshal object into Go value of type []string."
Signed-off-by: Gao feng<EMAIL_ADDRESS>

what was the version of the docker you using?
see 22ef6cb99f60918add8b4be3ba6f40f7a54b50f0

moby, docker-17.06.0

LGTM


Also include shortname on click

In latest release shortname is not includes in the click handler anymore, I've added that in this pull request.

Oops, thanks for catching this!


English function?

Hi is there any plan to make the plugin in english? Thanks!

Check out the updated version here

It should be in English if you selected English in Obsidian. Let me know if it does not work. Thanks


Incorrect warning in train_test_split

When applying train_test_split to a float64-typed dataset, I get an erroneous warning that says there are mixed types:

Using dask_ml version 1.0.0 on a GCS instance.

What are the types of X and y? both Dask Dataframe / Series, or a mix of dask and pandas?

Both are pandas; y was pop()ed from X.

Ah, in that case we're doing the correct thing (using scikit-learn). We just shouldn't warn.

I've tried switching to torch tensors, but I get the same error:

Moreover, the split fails entirely:
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-42-273a132217bf> in <module>
----> 1 X_train, y_train, X_test, y_test = train_test_split(X, y)

/opt/anaconda3/lib/python3.7/site-packages/dask_ml/model_selection/_split.py in train_test_split(test_size, train_size, random_state, shuffle, blockwise, *arrays, **options)
    458             train_size=train_size,
    459             random_state=random_state,
--> 460             shuffle=shuffle
    461         )

/opt/anaconda3/lib/python3.7/site-packages/sklearn/model_selection/_split.py in train_test_split(*arrays, **options)
   2122
   2123     return list(chain.from_iterable((safe_indexing(a, train),
-> 2124                                      safe_indexing(a, test)) for a in arrays))
   2125
   2126

/opt/anaconda3/lib/python3.7/site-packages/sklearn/model_selection/_split.py in <genexpr>(.0)
   2122
   2123     return list(chain.from_iterable((safe_indexing(a, train),
-> 2124                                      safe_indexing(a, test)) for a in arrays))
   2125
   2126

/opt/anaconda3/lib/python3.7/site-packages/sklearn/utils/__init__.py in safe_indexing(X, indices)
    217                                    indices.dtype.kind == 'i'):
    218             # This is often substantially faster than X[indices]
--> 219             return X.take(indices, axis=0)
    220         else:
    221             return X[indices]

TypeError: take(): argument 'index' (position 1) must be Tensor, not numpy.ndarray

I assume this is because it is trying to use sklearn to split torch tensors?

Yeah, with a torch Tensor I think we're just doing
sklearn.model_selection.train_test_split(X, y). I'm not sure
what the expected behavior for scikit-learn is there.
On Wed, Oct 2, 2019 at 12:47 PM Chris Fonnesbeck<EMAIL_ADDRESS>wrote:

I've tried switching to torch tensors, but I get the same error:
[image: image]
https://user-images.githubusercontent.com/81476/66068104-93999a00-e512-11e9-8195-6ddf78b5f95c.png
Moreover, the split fails entirely:

TypeError                                 Traceback (most recent call last)
 in
----> 1 X_train, y_train, X_test, y_test = train_test_split(X, y)
/opt/anaconda3/lib/python3.7/site-packages/dask_ml/model_selection/_split.py in train_test_split(test_size, train_size, random_state, shuffle, blockwise, *arrays, **options)
458             train_size=train_size,
459             random_state=random_state,
--> 460             shuffle=shuffle
461         )
/opt/anaconda3/lib/python3.7/site-packages/sklearn/model_selection/_split.py in train_test_split(*arrays, **options)
2122
2123     return list(chain.from_iterable((safe_indexing(a, train),
-> 2124                                      safe_indexing(a, test)) for a in arrays))
2125
2126
/opt/anaconda3/lib/python3.7/site-packages/sklearn/model_selection/_split.py in (.0)
2122
2123     return list(chain.from_iterable((safe_indexing(a, train),
-> 2124                                      safe_indexing(a, test)) for a in arrays))
2125
2126
/opt/anaconda3/lib/python3.7/site-packages/sklearn/utils/init.py in safe_indexing(X, indices)
217                                    indices.dtype.kind == 'i'):
218             # This is often substantially faster than X[indices]
--> 219             return X.take(indices, axis=0)
220         else:
221             return X[indices]
TypeError: take(): argument 'index' (position 1) must be Tensor, not numpy.ndarray
I assume this is because it is trying to use sklearn to split torch
tensors?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-ml/issues/550?email_source=notifications&email_token=AAKAOIU7533I3VVCMQKFWTTQMTND5A5CNFSM4I4YGV42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFTKHA#issuecomment-537605404,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKAOIRZX4FMY7EV7ZWYQA3QMTND5ANCNFSM4I4YGV4Q
.


TypeError: unhashable type: 'list'

I followed the steps one by one, using Python version 3.9, but encountered an error when running src/fetch_data.py. The error message is as follows:
File "D:\anaconda3\envs\gupiao\lib\typing.py", line 215, in _remove_dups_flatten
all_params = set(params)
TypeError: unhashable type: 'list'

Hey,
Thanks for your patience. I have updated the code. I hope your issues have been resolved.
Harshit Kushwaha


Change nil datatype values in db/fixtures to string

In the db/fixtures __class files, if datatype isn't set, set it to string.
@gmcculloug -- can you link me the talk article about the next steps of doing import/export stuff to reset manageiq/redhat domains after review please?

@d-m-u - Here is the talk topic: http://talk.manageiq.org/t/creating-a-pull-request-for-enhancements-to-manageiq-automate-domain/1041
I am closing this PR since I am really looking to get the automate export files updated, not just a script that does that work.  Ping me if you want to discuss.


add supported provider type

add supported provider type

Note that the user of vela doesn't know what is contour or nginx ingress. So there won't be a 'type' field in trait spec.
Instead, the provider of ingress is a platform admin's concern that should be decided by:

trait definition, and be configurable by vela install config

or, auto discover by whether contour or nginx ingress is available (default provider should be defined in this case)

is simplest and 2. is favorable, leave to @wonderflow for final decision

@resouer yes, I think we could adopt the first solution as a quick fix, that make the provider field configured in traitdefinition template.

closing as we have automatically generate this doc

closing as we have automatically generate this doc


Fix several typos

Hello,
I fixed some typos found in your documentation
Hope it helps.
Best regards,Elias.

Thanks!