Don't hardly depend on iron:router - Flow Router Integration

I'd like to use the useraccounts package with the flow-router. Right now it's not possible to get rid of iron:router when using the useraccounts package because of the hard dependency on it.
My suggested solutions to fix this are either:

Make iron:router specific features optional. They are only available when the app uses iron:router. This  can be achieved by making the dependency to iron:router weak and check the existence of Package['iron:router'] for the iron:router specific parts.

Use polymorphism to support multiple routers. Create a common router interface object that will delegate the execution to the router that is included in the app. This would be iron:router, meteorhacks:flow-router or a "no router" implementation.

makes sense @Sanjo!
Probably solution 1. is the easier/quicker at the moment. Could you make a PR about this?
Solution 2. sounds better! But perhaps is something that could be better integrated into a useraccounts:routing package for v2?

+1 for the ability to use flow-router instead of IR.

@splendido let me know, if you need to any help? Just tag me or send me an email.

Hello @arunoda!
Glad to see you here!
I really need to find some spare time to draw the skeleton for the new<EMAIL_ADDRESS>:(
I'm thinking to provide two independent routing packages:

useraccounts:ir-routing
useraccounts:flow-routing

without any doubts,  it would be awesome having you involved in the package for the flow router ;-)
Lets keep in touch!

sure. Thanks.

+1 to support flow-router.
Is there any way I can help with it?

...to get started even before I can manage to complete the new skeleton, we could play around on a new branch for useraccounts:core which is where all the routing support is now...
I've just created a new flow-router-integration branch!
I'll happily accept PRs on this ;-)
Most of the routing set up is done in setupRoutes which now calls regular IR API.
Something else can be found here for the ensureSignedIn plugin...
Other Router.* calls could be found here and there though...
Let me know!

+1 to flow-router & useraccounts!

Please all, les try out the current status for the Flow Router intergration!
I'd say the only way to do so is to locally clone useraccounts:core and checkout the flow-router-integration branch.
See also the Working Locally section on the README.md

@splendido trying the flow router branch. I may have messed something up but I am getting the following error: TypeError: Cannot set property 'main' of undefined
//simple accounts config for now
AccountsTemplates.configure
  defaultLayout: 'mainLayout'
  homeRoutePath: '/'
  defaultContentRegion: 'main'
  showForgotPasswordLink: true

AccountsTemplates.configureRoute('signIn');
AccountsTemplates.configureRoute('forgotPwd');
AccountsTemplates.configureRoute('enrollAccount');

<template name="mainLayout">
    {{> Template.dynamic template=main}}
</template>

At the moment you need to set the defaultLayoutRegions property in your configure object:
AccountsTemplates.configure({
    defaultLayout: 'masterLayout',
    defaultLayoutRegions: {},
    defaultContentRegion: 'main'
});

But you are right that this should not happen, because {} should be the standard value for the defaultLayoutRegions property

It works! Thank you much @PhilippSpo!

I'm using the flow-router-integration branch locally with no problem. I'm having trouble when I try to deploy however. It seems to be using master. (it errors out on bad key defaultLayoutRegions, for example)
How would I use this branch in production? (I'm using Heroku with build pack meteor-buildpack-horse).

Thats a great question since I had the same issue today an scalingo.io ..
Anybody an idea how to handle this kind of stuff ?

where are you keeping the local clone of the repo?
...I'd say that if you put it under your project/packages folder meteor should pick-up that one instead of the official package.
As a tricky workaround, you can always change the version number with something like <IP_ADDRESS>...
It should be picked up with no problems

I cloned the useraccounts core package in project/packages, switched to the flow-router-integration branch and added it as a submodule to my project repo.. when the application gets bundled/built on scalingo (Heroku probably the same) it seems to ignore the submodule or uses the master branch instead of the flow-router-integration branch

...just a silly pointer, the submodule is then pointing to the flow-router-integration branch?
Make sure that if you clone the repo from scratch you are on the correct branch!

Not with this branch but I have pushed a branch of this to production before. I believe I bumped the version number. Be sure your not using sym-links, they don't work (which makes sense but it is easy to forget).

My clone of the repo is in /[myproject]/packages and is the right branch (I can see the flow-router changes). Meteor doesn't seem to be picking it up in production however.
I thought I'd be able to change the version number as was suggested with something like: meteor add<EMAIL_ADDRESS>but that says no such package. What am I doing wrong there?

I removed the package and did the following:
cd packages/
git clone https://github.com/meteor-useraccounts/core.git --branch flow-router-integration
cd ..
git add packages/core/

and then committed the whole thing. So in this case a didn't use a submodule and it seems to work fine.

Ah! In your .meteor/packages do you have meteor-useraccounts:core? The version number is not required. I you don't have it there then it will pull the latest from atmo.

+100 for flow-router + useraccounts!

@DenisGorbachev the branch works quite well for now. User Accounts v2 is in the works.

@Kestanous Thanks for the tip, I'll check it out.

I would love to see iron-router removed as a dependency from this package.  I followed all the instructions in this thread about using flow-router instead, but I'm still seeing iron-router get installed somehow.  Every since switching to flow-router I feel like I actually understand what is going on in my app.

@splendido, it seems Iron Router is now going downhill and Flow Router is almost officially backed by MDG (see here).

We'll be ready for a RC of 2.0 in a couple weeks! :-)
there will be no routing support by default but packages useraccounts:ir-routing and useraccounts:fr-routing will be available as plugins to add routing support.
Any feedback about the names?

Any feedback about the names?

Sounds good.

+1 @splendido sounds awesome everyone is switching to flow router (me included) and I'm really eager on the official 2.0 flow router + user accounts! :)

Maybe do useraccounts:iron-routing and useraccounts:flow-routing.

the poll is open! ;-)

+1 @rclai

I agree with @rclai, the naming should be clear, no need for that level of brevity. Perhaps you can consider useraccounts:iron and useraccounts:flow as an alternative if you want to keep them short, but perhaps that's only clear for those already initiated.

Makes sense!
...so, at the moment it seems we're up to useraccounts:iron-routing and useraccounts:flow-routing

sounds epic :) Approx. when will be 2.0 ready?

I'd like to put out the first alpha version next week...
But unfortunately I'm not having that much time to work on this.

...perhaps I should take some volunteer to work a bit on the initial take off ;-)
Btw, there's an (almost empy) board on trello: see here

:+1: because the crowd says so :) But what's the most compelling post (or set of reasons) on why devs should switch from iron-router to flow-router?

There were no updates from master to flow-router-integration since the last stable commit 90b947d1d605085d7bafb6eb2c0d6a2fa9a9e4e0.
I've now merged all newer modifications into flow-router-integration.
Let me know if all works fine!
...otherwise we can revert back, or fix stuff

So I've been trying to get the following boilerplate (https://github.com/aladine/meteor-boilerplate), which uses Flow Router and User Accounts, running but the app fails on start-up
=> Errors prevented startup:

   While building the application:
   lib/router/routes.js:9:2: Unexpected token )

Any help would be greatly appreciated.

I'd say you'd better report the issue on that repository, but it might be that someone here had a chace to play with it...
Btw, form the error itself, it seems is a sintax problem: even if looking at the first 9 lines of the file I couldn't spot anything weird....

@3even
line1: FlowRouter.route(['/','/home]', {
should be: FlowRouter.route(['/','/home'], {

I'm definitely blind :(

This is regarding this comment/issue: https://github.com/meteorhacks/flow-router/issues/136
It would be great, if you could add some note on AccountsTemplates.setupRoutes() saying that to call it after the user have added routes. Otherwise, he/she might face issues as mentioned on the above post.
I hope this is true for both IR and Flow.

Thanks for pointing this out @arunoda!
...actually I already had other issues reported about route definition order, but I never realized this might be a problem with the pattern I've set up to define routes for UA.
I think the problem is AccountsTemplates.setupRoutes() is called at start up time (see here for the server and here for the client) within AccountsTemplates._init() (here and here).
This obviously causes a delay in actual routes definition so that if someone have a catch all route defined in top level code after UA routes it actually gets defined before them
...and here is the problem!
The idea was to let devs modify UA routes possibly defined by some package they're using before actual definition, but since this deferral does not bring any evident advantage, I'd say the correct solution is to actually define routes straight away when AccountsTemplates.cofigureRoute is called.
Do you think it'll be possible to change a route's settings after its first definition?
...does this makes any sense?

After the first definition, it's quite hard to change it.
I assume you are looking to change the order, it's pretty hard.
I think, if you can define routes at AccountsTemplates.cofigureRoute, it feels logical.

I didn't meant the order, rather the name, path, and the like...
But that's not a big point I guess.
I'll try to change the current behaviour: it should be a matter of moving just a couple of lines!

A few notes:

It's hard to keep up with @arunoda but I've been running the branch successfully with the latest releases of flow-router (1.9.0) and flow-layout (1.4.0) spec'd in the package.json in my local clone. flow-layout 1.4.0 fixes a crucial issue when rendering views dynamically, but may not directly affect this package.
I think any package that defines routes should mention that the order in which they're defined is significant, so both flow-router and useraccounts:core should make note in the documentation. I can help here if you'd like.
I think defining the AccountsTemplates routes at the time of configuration is better, that way we can move those lines into the router where they probably belong. In fact, in that case, I'd suggest adding an alias for AccountsTemplates.configureRoute called AccountsTemplates.addRoute (or .defineRoute) because those, to me, imply configuration and definition.

thanks @fightingtheboss for your feed-back!
I'll defenitely keep it in mind
Feel free to propose a PR to shed a light on this inside the Guide!

I've just merged some improovements by @PhilippSpo!
See #428.

Time to give feedback guys!
After almost three months playing around with the flow-router-integration branch,

what do you think of it?
is there anything you'd change?
is there anything missing?

Unfortunately I had no chance to give it a try, nor I started to look at flow-router, but I'm sure you can make a very good review!
...I also guess @arunoda would be happy to hear about any addition we might expect form  flow-router to get fully up and running! :-)
At this point we might start moving the more general parts about route configuration to useraccounts:flow-routing

I'm building a referral system with user-accounts and flow-router, so I'll be happy to give feedback within a week or so.

good to know @dandv,
happy coding then!

@arunoda Is there a way, that a trigger can prevent the action from being executed? If not how are you supposed to do this?
Because at the moment, the ensureSignedIn trigger cant render a signIn template instead of the original content, because of this.

Triggers are very similar to middlewares, but triggers don't have a next() argument. So, you've no way to block or wait the route.

Yes it is. That's an issue. We are working on a way to that.
Basically, we allow you to redirect within the trigger.
It'll land in few days.
On Mon, Jun 15, 2015 at 1:20 AM Philipp Sporrer<EMAIL_ADDRESS>wrote:

@arunoda https://github.com/arunoda Is there a way, that a trigger can
prevent the action from being executed? If not how are you supposed to do
this?
Because at the moment, the ensureSignedIn trigger cant render a signIn
template instead of the original content, because of this.
Triggers are very similar to middlewares, but triggers don't have a next()
argument. So, you've no way to block or wait the route.
—
Reply to this email directly or view it on GitHub
https://github.com/meteor-useraccounts/core/issues/308#issuecomment-111870229
.

ok thanks for the info

@arunoda the desired behavior of useraccounts is, that once you visit a route that you are only allowed to see if logged in, then you should NOT get redirected to /sing-in BUT stay on the same route and see the signUp Template/Layout rendered and not the original content.
With middlewares if you do not call the next() function (in the middleware) but call FlowLayout.render(...) you could achieve that. I don't see that working with triggers though. What is your take on that?

If this is the case, then it's very easy.
Just do it in the template level. I am quite not sure how to do it.
If this is the case, I believe you don't need to depend on the router at
all.
On 2015 ජූනි 22, සඳුදා at ප.ව. 7.24 Philipp Sporrer <
<EMAIL_ADDRESS>wrote:

@arunoda https://github.com/arunoda the desired behavior of
useraccounts is, that once you visit a route that you are only allowed to
see if logged in, then you should NOT get redirected to /sing-in BUT stay
on the same route and see the signUp Template/Layout rendered and not the
original content.
With middlewares if you do not call the next() function (in the
middleware) but call FlowLayout.render(...) you could achieve that. I
don't see that working with triggers though. What is your take on that?
—
Reply to this email directly or view it on GitHub
https://github.com/meteor-useraccounts/core/issues/308#issuecomment-114111488
.

Hi guys,
Any timeline on when useraccounts be a full-fledged package for flow-router? I'm going to test this out though in my prototype though in the next few weeks along with Materialize...

@DenisGorbachev already has one open pull request that will get things working with FlowRouter v1.16.1. It will be fully functional if middlewares are not fully deprecated in 2.0 also.
If you don't mind using submodules in your git repo than you can use that today. @splendido is on vacation, so it might take a week or two until we see more regarding useraccounts 2.0...

@tjmonsi it's the https://github.com/DenisGorbachev/meteor-useraccounts-core, and using submodules is pretty simple with latest git, so feel free to give it a go :)

@DenisGorbachev Do i still need to do this? https://github.com/meteor-useraccounts/core/blob/master/Guide.md#flow-router-integration
Or should i just use this and just create my custom routes in flow-router? https://github.com/meteor-useraccounts/core/blob/master/Guide.md#templates

@tjmonsi Yes, you need to do this, too. By the way, if you use the fork, then it's better to also use fork's documentation: https://github.com/DenisGorbachev/meteor-useraccounts-core/blob/flow-router-integration/Guide.md

@DenisGorbachev after much re-reading... I now get the flow :P So that means I'll just git clone your copy, add useraccounts:materialize (i'm using that one), and then just use it for flow-router. Would it have any problems on production stage? I'm seeing problems as told by @PhilippSpo... did you guys fixed the problem? I'm going to use @arunoda's MUPX on digital ocean and would like to get some headsup on what I need to do so it works perfectly

@tjmonsi if it works on localhost, it'll work on another machine, too. After all, it's just a client-side router :)

@tjmonsi I am currently using it in a client project, hostet on digitalocean, deployed via MUP ;)

@DenisGorbachev @PhilippSpo :+1:  Thanks guys for the replies. Will try it out within this week and post here my findings (if it is working smoothly or... well... has bugs :stuck_out_tongue: )

:+1:

The branch is working for me but I had some trouble with git submodule errors. Instead of cloning, I used this command to add submodule and pull the branch. Much easier for noobs like me :)
$ cd your/project/path
$ git submodule add --branch flow-router-integration https://github.com/meteor-useraccounts/core.git packages/core

Actually, I do the same :)
On Fri, Jul 3, 2015 at 12:53 AM Charles Han<EMAIL_ADDRESS>wrote:

The branch is working for me but I had some trouble with git submodule
errors. Instead of cloning, I used this command to add submodule and pull
the branch. Much easier for noobs like me :)
$ cd your/project/path
$ git submodule add --branch flow-router-integration https://github.com/meteor-useraccounts/core.git packages/core
—
Reply to this email directly or view it on GitHub
https://github.com/meteor-useraccounts/core/issues/308#issuecomment-118178594
.

Hey friends.  Been a while since I've used this package with Flow Router and I just discovered that it needs a little attention after the recent FR 2.0 releases.  Where do things stand with 2.0 integration?  Is anyone working on it?  What else needs to be done?  I have some time this week and would be happy to try to knock it out.  I just don't want to duplicate any effort if someone else is already working on it.

I attempted to use the flow-router-integration branch with the new kadira:flow-router release yesterday and ran into issues.
Aside from this package needing to have weak dependencies on either flow-router (meteorhacks vs kadira) package it also needs a few special wrappers for integrating with the new kadira:blaze-layout (of course, assuming the desire  of backwards compatibility with flow-router pre-2.0).  So, some wrappers, etc. are in order.
Additionally, this got into a general question of the status of the talks I read somewhere about making the 2.0 version of meteor-useraccounts:core router-agnostic. So that might be the place to start.  IronRouter compatibility is probably still a must.
I spent a half-hour or so on it yesterday just trying to hack it together for my existing purposes but then had to move onto something else (sticking to my previous pre-kadira:flowrouter implementation for now).  My proof-of-concept actually doesn't need a super functional user accounts system, so I just went with a accounts-ui-only approach for now, but I will need to revisit this in a few weeks.
FlowRouter API might be maturing very quickly at the moment to help make this integration easier too and I haven't had a chance to keep up with that.  At first glances though... FlowRouter._askedToWait might be worth taking a look at, as well as maybe seeing what projects like zimme:active-route are doing.
I'll help where I can.

I've gotten just about everything on the flow-router-integration branch working with FR 2.0 (except for ensureSignedIn).  See my branch here.  But I was also under the impression that things were getting broken out into separate packages, so I won't bother with a pull request to the core repo.  However, I use AT on just about every Meteor app I build, so I'd be happy to work  with the new routing packages for AT.
So what's the current state of things?  Is anyone working on

I've gotten just about everything on the flow-router-integration branch working with FR 2.0 (except for ensureSignedIn).  See my branch here.  But I was also under the impression that things were getting broken out into separate packages, so I won't bother with a pull request to the core repo.  However, I use AT on just about every Meteor app I build, so I'd be happy to work on getting the new routing packages up and running.
So what's the current state of things?  Is anyone working on the v2 branch or the routing packages?
https://github.com/meteor-useraccounts/core/tree/v2.0
https://github.com/meteor-useraccounts/flow-routing
https://github.com/meteor-useraccounts/iron-routing

Simple enough, and there's no reason it won't work like this.  I'll test your branch later, but a quick look at your branch shows the bare-bones changes necessary to get it working.
I think (getting back to the original issue in this issue/ticket), "Create a common router interface object" is the next task.  Not sure how I feel about the "no-router" aspect of this project?  I'm not entirely sure how this package would work without a router at all as that seems like a large amount of the value that it provides (versus just doing Meteor-core accounts-ui).  Thoughts?
I personally don't feel that flow-routing and iron-routing packages are really necessary -  this seems to make things more complicated than they need to be.  We can easily detect which router is installed (Package[kadira:flow-router]) and simply make them weak dependencies.  It should be possible to install this package with either router (and I guess, theoretically, no router, though again, I don't seen the value) and it should work fine.
I'm not sure where 2.0 stands right now, but I kind of feel like this needs to be done to the 1.0 branch?

And the discussions are continuing about authentication in FlowRouter (for fixing ensureSignedIn, but this is a popular choice, and not sure if this idea of an AuthManager is going to develop into anything or if it's just going to be a best-practice blog post.

I guess people render the forms directly into other templates and stuff, so maybe that would be the reason for the "no-router" approach?  Not sure, as I've never done it this way before.  I prefer to have routes for everything.  Input appreciated on this part.

@abernix thanks gor your thought!
I've been out for more than one months and I'm now trying to get back to the project especially on v2.0
I think you already figured out the reason for the "no-routing" philosopy, at least in base packages: the simplest scenario would be having a single sing-in/sign-up form on your landing page and this would require no particular routing stuff for useraccounts itself, it could be a {> uaForm} put somewhere within your home page and that's it.
At the same time it might get overcomplicated to figure out an interface which would be able to play nice with both IR and FR. Moreover, who knows about other possible new routing packages we'll have in the furute...
Honestly, I think something like:
meteor add useraccounts:oauth
meteor add useraccounts:bootstrap
meteor add useraccounts:flow-routing
is not too much complicated a sequence of commands to be run once at the begininng of a project ;-)
and this way the code could be lighter and easier to maintain.
I hope this makes sense.

I think @jshimko will come out with a PR soon to update the flow-router-integration branch so to have people able to continue on it.
...but the goal is now bringing v2.0 branch to a published alpha version or something!

...yep!  See #490

The interface can be more abstract and specific to the user accounts package. The point is that each router integration implements the same methods. Adding a new router integration would be also easy this way.

yes I see what you mean @Sanjo.
I guess the configuration API will be the same (as long as possible) for all routing packages, but the actual code will defenitely be different.
What I meant is I don't thinks it is wise to write a single configureRoute method (or whatever) which automatically detects the intsalled routing packag is and then try to use slightly different code based on the context...

@splendido i also think that it would/could get complicated really quickly, when trying to have one package for all routers. Of course it would be cool to automatically detect the router being used, but this job can easily be done by the developer using the useraccounts package. And in the end the difference between the approaches is just that the (routing specific) code is separated into some packages and the logic which router is being used goes to the developer..

After further thinking, I think this is what should happen:
useraccounts:core should only give us all the at<Feature> templates and any other user account configuration.
And all the iron:router configuration stuff and the Iron Router plugin should be taken out and put into a separate helper package like useraccounts:iron-router-helpers or useraccounts:iron-routing. It makes sense because of how iron:router works. It renders stuff.
And for the kicker, we don't need any Flow Router integration because of its non-template-rendering nature and the fact that it is NOT tied to Flow Layout, or Blaze Layout, or any template engine. Like @arunoda said, "we don't need to depend on the router at all". All someone needs to do is something like:
// /client/lib/user-auth.js
FlowRouter.triggers.enter([function (context, redirect) {
  if (! Meteor.user()) {
    redirect('/sign-in');
  }
}]);

FlowRouter.route('/sign-in', {
  action: function () {
    // FlowLayout.render('layout', { main: 'atSignIn' });
    // BlazeLayout.render('layout', { main: 'atSignIn' });
    // React.render(<MeteorTemplate template=Template.atSignIn />, mountNode);
  }
});

Tracker.autorun(function (c) {
  // If for some reason we detect that the user was logged out
  if (! c.firstRun && ! Meteor.user()) {
    // FlowLayout.render('layout', { main: 'atSignIn' });
    // BlazeLayout.render('layout', { main: 'atSignIn' });
    // React.render(<MeteorTemplate template=Template.atSignIn />, mountNode);
  }
});

So what I envision the ideal path to be is to take the iron:router stuff out and put it in a separate package. Any iron:router user will just need to install that package. Then any other person using Flow Router with whatever templating engine can take advantage of the atTemplates and now everyone's happy.
Let me know your thoughts.

I like the idea. Would it be already be useful with the current iteration
of useraccounts?
On Tue, 4 Aug 2015 20:20 Richard Lai<EMAIL_ADDRESS>wrote:

After further thinking, I think this is what should happen:
useraccounts:core should only give us all the at templates and
any other user account configuration.
And all the iron:router configuration stuff and the Iron Router plugin
should be taken out and put into a separate helper package like
useraccounts:iron-router-helpers or useraccounts:iron-routing. It makes
sense because of how iron:router works. It renders stuff.
And for the kicker, we don't need any Flow Router integration because
of its non-template-rendering nature and the fact that it is NOT tied to
Flow Layout, or Blaze Layout, or any template engine. Like @arunoda
https://github.com/arunoda said
https://github.com/meteor-useraccounts/core/issues/308#issuecomment-114137621,
"we don't need to depend on the router at all". All someone needs to do is
something like:
// /client/lib/user-auth.js
FlowRouter.triggers.enter([function (context, redirect) {
if (! Meteor.user()) {
redirect('/sign-in');
}
}]);
FlowRouter.route('/sign-in', {
action: function () {
// FlowLayout.render('layout', { main: 'atSignIn' });
// BlazeLayout.render('layout', { main: 'atSignIn' });
// React.render(, mountNode);
}
});
Tracker.autorun(function (c) {
// If for some reason we detect that the user was logged out
if (! c.firstRun && ! Meteor.user()) {
// FlowLayout.render('layout', { main: 'atSignIn' });
// BlazeLayout.render('layout', { main: 'atSignIn' });
// React.render(, mountNode);
}
});
So what I envision the ideal path to be is to take the iron:router stuff
out and put it in a separate package. Any iron:router user will just need
to install that package. Then any other person using Flow Router with
whatever templating engine can take advantage of the atTemplates and now
everyone's happy.
Let me know your thoughts.
—
Reply to this email directly or view it on GitHub
https://github.com/meteor-useraccounts/core/issues/308#issuecomment-127581562
.

Ok, I can absolutely see different packages being a benefit for 2.0, and I break stuff up into packages internally - I fully understand the light-weight aspect of it.  My only defense for keeping it in a single package is for easier on-boarding of new users.  Auto-detection is always nice for new users, and I really don't know how many routers there are going to end up being.  It's not out of the question that a router will be "built-in" at some point.
But really, I was really trying to address the problem for 1.0 users though, assuming that 2.0 is a bit off.  I guess this all depends on the timeline for a 2.0 branch. :smile: I feel like many people are actively switching to flow-router right now (as in, yesterday) so perhaps a short-term solution (which @jshimko basically has) would be nice.  Additionally, I feel like having flow-router in a separate branch right now might be actively discouraging users from using this (very good) package.  The use seems to be dropping on Atmosphere... or perhaps everyone is doing local clones?  I know I am.

@rclai, I think that's the right idea.  Though, I do think any requirement to add a different package will obviously have to come in a 2.0.0 release, and that's fine.  So for @tjmonsi, I think that change would be too large for a 1.0.0 release because it would be a breaking upgrade for those already using iron-router.

I'm still of the idea that also a usraccounts:flow-routing will be necessary to provide users with routes configured out of the box with a very few lines...
The thing is that some internal template initialization should be addressed within FR triggers before actual rendering, and I think letting also this part to the developer would be too much complicated and not that intuitive...

about taking IR stuff out of the current version: we can do it very quickly, but I wouldn't bump to 2.0 (which would be the correct thing to do btw...).
We might think about a minor bump including some warning in case AccountsTemplates.configureRoute is called without the useraccounts:iron-routing package installed...
Does it make sense?
I obviously like to get people easily out of the IR dependency as quick as possible ;-)

Yes, I was thinking that as well, just wasn't sure if you were comfortable doing that.

The problem with have routes configured for Flow Router is that it will tie it to a specific template engine, which Flow Router was specifically designed not to do. How would you tackle that?

That's a good point!
I've read about the Blaze/React alternatives, but I actually had no time to have a look at FR yet... :(
Perhaps in this case the rendering engine could be autodetected within the useraccounts:flow-routing package?
...and we're back to the previous point! But maybe it would be easier in this case?

Or we could just make the rendering engine a configuration option for people using useraccounts:flow-router.

That would be cool. Can we figure that out later though, perhaps in a separate issue? I don't think that it stops us from doing what is actionable now (if you're in agreement), which is to de-couple the iron:router features to another package, and let core be only atTemplates and the user account-related config functionality. What do you think?

@splendido is right and ease-of-use route-creation (i.e. useraccounts:flow-routing, etc.) will be needed.  I'm all about simplicity and ease of getting up-and-running (as I'm about to make very clear) :smile:.
Why not have a default configuration, with just one package, that just works?  Pick a router and go for it (iron-router is great).  Keep the code well compartmentalized within the package, but have it integrated in the package. Make the dependency on this router weak: true.  Then, if someone wants to add an override package (useraccounts:flow-routing?), fine, it will take the place of the default configuration and it will force that router.  None of the built-in functionality will run.
In the case that someone does add useraccounts:flow-routing then have it (for now) just use BlazeLayout.  I think that's fine for the short term and covers (guessing here) 90-95% of the users.  Then, as @jshimko says, make it a configuration option in the future (3.0?).
Overall, my feelings are...

Leave this 1.0 branch in the dust.  So many people are already probably forked into this flow-router-integration branch, if they want to stay there, they can stay there.  I believe it will keep working as long as it's dependency stays as the meteorhacks:flow-router version, right?  Anyone using the official version will see that a new 2.0 branch is out that they need to make changes for.
Obey semantic versioning - Why make a warning?  The warning is in the version number.

Change milestones on other non-iron-router/flow-router related stuff to a 3.0 milestone - get to it soon.
Make a new 2.0.0 release which implements the rest of what has been suggested everyone, as I tried to summarize above, and release it asap.

It just seems like this router thing is the most pressing thing for this package right now to keep it moving forward with a strong user-base.  I'm a big proponent of this package over the alternatives, and again, I feel like usage is dropping because use is getting too complex.

I'll try to get IR stuff out into useraccounts:iron-routing tonight then!
... @jshimko: could you do the FR part on useraccounts:flow-routing?  v1.11.1

@splendido Yep.  :)

ok guys, I've just pushed some commits to core to get rid of IR stuff
and then I've also initialized the iron-rounting repository.
Tomorrow I'll have a bit of testing and I'll try to add something about this new scenario into the README.
...a comprehensive Quick Start seems to be missing.
If you're quicker than me, I'll happily accept PRs ;-)

...please note that you now need to define routes after the usual AccountsTemplates.configure({}) block since routes are now defined on the fly and some configuration should be set in advance for everything to work correctly.

The counterpart for FR should follow soon on flow-rounting

@splendido this is great! I'm glad that after 100 comments on here things are now mobilizing :smile:

Good job guys.
I really like the no-route solution for user-accounts.
@rclai yes flow-router's idea is to decouple and use it with different layout engines. I think the idea is successful with since now we can use both Blaze and React with FlowRouter.
That's why I like a router independent  version.

@rclai I'm sorry you guys had to wait 100 comments before getting things moving on...
I really hoped v2.0 was out much earlier with the routing stuff taken out of core, but I've been away for more than a month and I'm having very little spare time right now.
Hopefully things will get better also thanks to contributions from the community...

@arunoda I'm glad you like it!

I've just pushed a first version of flow-rounting!
I had to change a bit of stuff also in core to handle a few things.., but I had no time to test anything :(
Please let me know in case you get a chance to play a little with the new packages and find some problem!

@splendido Will try in a few, but how will it work with let's say, useraccounts:materialize?

Hi @splendido
Had to use this with a simple project and here's what I got:
W20150806-01:19:59.757(-4)? (STDERR)
W20150806-01:19:59.759(-4)? (STDERR) /home/dev/.meteor/packages/meteor-tool/.1.1.4.beln8f++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:245
W20150806-01:19:59.760(-4)? (STDERR)                                            throw(ex);
W20150806-01:19:59.760(-4)? (STDERR)                                                  ^
W20150806-01:19:59.760(-4)? (STDERR) TypeError: Cannot set property 'defaultLayoutRegions' of undefined
W20150806-01:19:59.760(-4)? (STDERR)     at packages/underscore/underscore.js:848:1
W20150806-01:19:59.760(-4)? (STDERR)     at Array.forEach (native)
W20150806-01:19:59.761(-4)? (STDERR)     at _.each._.forEach (packages/underscore/underscore.js:105:1)
W20150806-01:19:59.761(-4)? (STDERR)     at Function._.extend (packages/underscore/underscore.js:845:1)
W20150806-01:19:59.761(-4)? (STDERR)     at Package (packages/useraccounts:flow-routing/lib/core.js:15:1)
W20150806-01:19:59.761(-4)? (STDERR)     at /home/dev/workspace/bellweather-project/.meteor/local/build/programs/server/packages/useraccounts_flow-routing.js:257:4
W20150806-01:19:59.761(-4)? (STDERR)     at /home/dev/workspace/bellweather-project/.meteor/local/build/programs/server/packages/useraccounts_flow-routing.js:264:3
W20150806-01:19:59.762(-4)? (STDERR)     at /home/dev/workspace/bellweather-project/.meteor/local/build/programs/server/boot.js:222:10
W20150806-01:19:59.762(-4)? (STDERR)     at Array.forEach (native)
W20150806-01:19:59.762(-4)? (STDERR)     at Function._.each._.forEach (/home/dev/.meteor/packages/meteor-tool/.1.1.4.beln8f++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
=> Exited with code: 8

and it still loads iron router dependencies because it tries to load useraccounts:core. It messes up with the already loaded FlowRouter.

Here's what it is loading in my dependencies:
iron:controller            added, version 1.0.8
iron:core                  added, version 1.0.8
iron:dynamic-template      added, version 1.0.8
iron:layout                added, version 1.0.8
iron:location              added, version 1.0.9
iron:middleware-stack      added, version 1.0.9
iron:router                added, version 1.0.9
iron:url                   added, version 1.0.9
useraccounts:core          added, version 1.11.1
useraccounts:flow-routing  added, version 1.11.1

While I already have these:
// Using FlowRouter
<EMAIL_ADDRESS><EMAIL_ADDRESS>
I think I'll try forking useraccounts:core and useraccounts:materialize and maybe remove the dependencies on iron router, then just try to play with it (Might just plan on using FlowRouter as is to define the routes)

Ok I got it working now,
Forked your useraccounts:core (just found out that the core dependencies on Iron Router was removed yesterday, used mine for now)
Then did this...
<EMAIL_ADDRESS><EMAIL_ADDRESS>
It is currently working... for now... will update in a few

Sorry, I should have mentioned I still haven't published the new changes.
So, yes, to test the new packages you have to do it with local clones...
Then:

`export PACKAGE_DIRS="path/to/local/clones/"
cd yourProject
meteor add useraccounts:materialize
meteor add flow-routing
meteor

should be enough to go, provided you have local clones for useraccounts:core, and useraccounts:flow-routing (for useraccounts:materialize the latest published version should be just fine)

The useraccounts:flow-routing package is out!
Thank you all for the great support :-)
...please report problems in separate issues from now.

...please try it out and in case you like it, star it both on atmosphere and github ;-)


Refresh if URL is already open in browser

Currently, if browser.OpenURL is invoked multiple times, it will open multiple tabs in the web browser. I'd like to be able to maintain a single invocation, whereby the tab is refreshed if it's already open.

Thank you for raising this issue. I don't know how to do what you've asked so I'll mark this issue marked help wanted.

Thanks. If I figure it out somehow, I’ll submit a PR. Hopefully someone else can beat me to it! ;-)

I haven't looked through it yet, but Facebook's create-react-app does this with their dev utils and might be a good resource to lead us in the right direction.
https://github.com/facebook/create-react-app/blob/master/packages/react-dev-utils/openBrowser.js

i think @karlhepler lead is a good one.
i also came across this issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=141942
and i hope this can be solved by using specific browser commands (this might cover more use cases then just chromium on OSX)

I haven't looked through it yet, but Facebook's create-react-app does this with their dev utils and might be a good resource to lead us in the right direction.
https://github.com/facebook/create-react-app/blob/master/packages/react-dev-utils/openBrowser.js

it appears that Facebook uses open under the hood, which itself utilizes xdg-open.


switch Explore > Teams to new teams

Rough but serviceable.

Ping @rohitpaulk.

I want this so I can see the teams we have on the site and what their profile pages look like as I think about #3456.

Sorry, failing test ...

Tests fixed, @rohitpaulk.


Color Scheme Generator for Tailwind

Hey Tailwinders!
Just wanted to share a tool I built (mainly for my own use) to quickly generate some UI colors.
 Then you can just copy the output to your tailwind.js config!
All colors (Call-To-Action, Info, Warning, Success, Danger) and greys automatically match the hue of your main brand color.
Check it out: https://adevade.github.io/color-scheme-generator/
If you have any suggestions or ideas, I would love contributions!
Happy coding ❤

@adevade This is great! I was looking for something like this. I also found 0to255.com, which can help in picking your primary color. The two together is very neat. Anyway, posting in case anyone else stumbles on this post.

Thanks for this 🔥

@kiru Thank you! Yes, of course! I'll push an update later today!

You are right, it works! I did not realize that grouping in colors was not necessary. Thank you.

Hi,
I just found about this one: https://javisperez.github.io/tailwindcolorshades/
Which looks perfect to adjust some colors (for example if my brand is a blue that is not in tailwind palette, I can simply adjust all the blues of the tailwind config!)


Landrush doesn't register VMs on Vagrant 1.6

Installed landrush plugin and enabled within the Vagrantfile.
I have two virtual machines which I'm setting hostnames for, however, when I do a vagrant up, landrush doesn't run.
Running vagrant landrush vms also returns 'No Dependant VMs'
This is on, Vagrant 1.6.1 and landrush 0.13.1

Landrush works with Vagrant 1.7 and I think also 1.8.
Please reopen if you experience further problems.


Low resolution gray radiation aquaplanet has wrong result

Found by @valeriabarra @LenkaNovak. See this build for example.
Here is the qt (g/kg) at level 6 at day 30

Thank you @szy21 ! More plots from a similar coupled experiment are here, added by @juliasloan25


Create Github pages

Create github pages:

Copy the most content from my blog to have all resources in one place.
Generate javadoc

Work in progress.

Github page is online:
http://hannesdorfmann.com/mosby/


cached-nix-shell: init at 0.1.2

Motivation for this change
https://github.com/xzfc/cached-nix-shell/issues/8
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

bump
Rebased, updated to v0.1.2, introduced a new dependency BLAKE3.


Update appveyor.yml

Hi guibranco,
just trying to fix issue #140, please check it out

:x: Build VTEX-SDK-dotnet 2.3.261 failed (commit https://github.com/guibranco/VTEX-SDK-dotnet/commit/0add56086d by @viktoriussuwandi)

Hi @guibranco,
How about this PR ?
Should it close without merge, or anything need to add/improve ?

@viktoriussuwandi I am updating the files, just wait. I tracked all Prs that you submitted, just wait, no need to push a comment on every single one.

:x: Build VTEX-SDK-dotnet 2.3.265 failed (commit https://github.com/guibranco/VTEX-SDK-dotnet/commit/6062aad481 by @guibranco)

:white_check_mark: Build VTEX-SDK-dotnet 2.3.269 completed (commit https://github.com/guibranco/VTEX-SDK-dotnet/commit/3a290dd081 by @guibranco)

:white_check_mark: Build VTEX-SDK-dotnet 2.3.273 completed (commit https://github.com/guibranco/VTEX-SDK-dotnet/commit/40f4f336f4 by @guibranco)

Thanks @guibranco !


Hotfix: Change inciweb rss feed url

Change rss feed url from inciweb
Trello: https://trello.com/c/3XpaGIu1
Github: https://github.com/artofthetrekcom/inciweb/pull/10

 REXML::ParseException: Missing attribute equal:
Line: 5
Position: 527
Last 80 unconsumed characters:


Data Points at indexes (0, n-1) not visible on LineChart Graphs

Using your example from issue https://github.com/Abhinandan-Kushwaha/react-native-gifted-charts/issues/116 for a quick example:
https://user-images.githubusercontent.com/17049683/162674082-84a32c21-022e-4d85-8939-7871cc663ae1.mp4
As you can see, the data points at index (0,n-1) are barely visible which is causing some issues for my implementation.
I think offering a data prop config verticalLineShiftX would be useful alongside the current props such as verticalLineThickness.
Or you can program yourself so it adds a automatic shift to the data points at index 0 and index n-1.

Hi @NemyaNation 👋
This problem is now solved in version 1.0.17🎉
Just add the property pointerShiftX (and also pointerShiftY if needed) to specific data points.
For above example, the data array would look like-
const lineData = [
    {value: 8, pointerShiftX: 10},
    {value: 10},
    {value: 12},
    {value: 8},
    {value: 11},
    {value: 13},
    {value: 19},
    {value: 18},
    {value: 22},
    {value: 20},
    {value: 28},
    {value: 32},
    {value: 36},
    {value: 40},
    {value: 38},
    {value: 40},
    {value: 42},
    {value: 46},
    {value: 44},
    {value: 40},
    {value: 36},
    {value: 32},
    {value: 38},
    {value: 36},
    {value: 32},
    {value: 28},
    {value: 22},
    {value: 20, pointerShiftX: -10},
  ];

Hope it helps🤗


[SPARK-37489][PYTHON] Skip hasnans check in numops if eager_check disable

What changes were proposed in this pull request?
Skip hasnans check in FractionalExtensionOps.astype, IntegralExtensionOps.astype, FractionalOps.astype and DecimalOps.astype to improve the performance if eager_check disable.
Why are the changes needed?
To improve the performance if eager_check disable.
Does this PR introduce any user-facing change?
Yes, with eager_check disable, didn't raise exception in nan case.
How was this patch tested?
UT

Test build #145725 has started for PR 34746 at commit a0b0e07.

Test build #145725 has finished for PR 34746 at commit a0b0e07.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50195/

Test build #145727 has finished for PR 34746 at commit 4f457ef.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145725/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50197/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50195/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/50195/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50197/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/50197/

Thanks @Yikun !!

Test build #145737 has started for PR 34746 at commit 5885d42.

Test build #145737 has finished for PR 34746 at commit 5885d42.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145737/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50207/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50207/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/50207/

Test build #145741 has started for PR 34746 at commit bcc326d.

Test build #145741 has finished for PR 34746 at commit bcc326d.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class UDFBasicProfiler(BasicProfiler):
case class PrettyPythonUDF(

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50211/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145741/

Test build #145746 has started for PR 34746 at commit 55bfce8.

Test build #145746 has finished for PR 34746 at commit 55bfce8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50211/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50217/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/50211/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145746/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/50217/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/50217/

ERROR [2.132s]: test_reuse_worker_of_parallelize_range (pyspark.tests.test_worker.WorkerReuseTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/__w/spark/spark/python/pyspark/tests/test_worker.py", line 195, in test_reuse_worker_of_parallelize_range
    self.assertTrue(pid in previous_pids)
AssertionError: False is not true

flaky test failure and unrelated, and looks like it failed many times[1][2][3] before, I submitted a JIRA: https://issues.apache.org/jira/browse/SPARK-37498 , will take a look when I get time.
[1] https://github.com/apache/spark/runs/1182154542?check_suite_focus=true
[2] https://github.com/apache/spark/pull/33657#issuecomment-893969310
[3] https://github.com/Yikun/spark/runs/4362783540?check_suite_focus=true

Merged to master.


When a tensor value produced by accelerator is to be sent to host, if all its users are on the host (similar to the case of a result tensor from a TF program), stop issuing an accelerator-to-host copy warning for it.

One use case is outfeeding the loss value for logging/debugging within a TF
training loop, where such data transfer is async with respect to TF computation,
and is not expected to hurt TF performance.
The motivating test case for this PR is the following:
public func SR8313(_ n: Int) -> Tensor<Double> {
  var t = Tensor(1)
  var i = 0
  while i < n {
    t += 1
    i += 1
  }
  return t
}

The marked SIL code from TFPartition pass is:
---- ANALYSIS STATE FOR FUNCTION $S8test_tmp6SR8313y10TensorFlow0D0VySdGSiF ----------
Tensor start point:   %5 = integer_literal $Builtin.Int64, 0          // user: %11
Tensor end point:   %27 = struct $Tensor<Double> (%26 : $TensorHandle<Double>) // user: %28
SIL with markings:

bb0:
  %0 = argument of bb0 : $Int                       // users: %3, %1
    debug_value %0 : $Int, let, name "n", argno 1   // id: %1
    %2 = integer_literal $Builtin.Int64, 0          // user: %4
[Arg]   %3 = struct_extract %0 : $Int, #Int._value      // users: %4, %22
[Arg]   %4 = builtin "cmp_slt_Int64"(%2 : $Builtin.Int64, %3 : $Builtin.Int64) : $Builtin.Int1 // user: %7
[Copy]    %5 = integer_literal $Builtin.Int64, 0          // user: %11
[Move]    %6 = graph_op "Const"() {dtype: $Double, value$tensor: f64 0x3FF0000000000000 /* 1 */, __device: "ALL_DEVICES"} : $TensorHandle<Double> // users: %8, %11
[Copy]    cond_br %4, bb2, bb1                            // id: %7

bb1:
    br bb6(%6 : $TensorHandle<Double>)              // id: %8

bb2:
[Copy]    %9 = integer_literal $Builtin.Int64, 1          // user: %18
    %10 = integer_literal $Builtin.Int1, -1         // user: %18
[Copy]    br bb3(%6 : $TensorHandle<Double>, %5 : $Builtin.Int64) // id: %11

bb3:
[Move]  %12 = argument of bb3 : $TensorHandle<Double>     // users: %17, %15
[Copy]  %13 = argument of bb3 : $Builtin.Int64            // user: %18
[Move]    %14 = graph_op "Const"() {dtype: $Double, value$tensor: f64 0x3FF0000000000000 /* 1 */, __device: "ALL_DEVICES"} : $TensorHandle<Double> // users: %16, %15
[Move]    %15 = graph_op "Add,i,i"(%12 : $TensorHandle<Double>, %14 : $TensorHandle<Double>) {T: $Double, __device: "/device:CPU:0"} : $TensorHandle<Double> // users: %24, %25
    strong_release %14 : $TensorHandle<Double>      // id: %16
    strong_release %12 : $TensorHandle<Double>      // id: %17
[Copy]    %18 = builtin "sadd_with_overflow_Int64"(%13 : $Builtin.Int64, %9 : $Builtin.Int64, %10 : $Builtin.Int1) : $(Builtin.Int64, Builtin.Int1) // users: %20, %19
[Copy]    %19 = tuple_extract %18 : $(Builtin.Int64, Builtin.Int1), 0 // users: %25, %22
    %20 = tuple_extract %18 : $(Builtin.Int64, Builtin.Int1), 1 // user: %21
    cond_fail %20 : $Builtin.Int1                   // id: %21
[Copy]    %22 = builtin "cmp_slt_Int64"(%19 : $Builtin.Int64, %3 : $Builtin.Int64) : $Builtin.Int1 // user: %23
[Copy]    cond_br %22, bb5, bb4                           // id: %23

bb4:
    br bb6(%15 : $TensorHandle<Double>)             // id: %24

bb5:
[Copy]    br bb3(%15 : $TensorHandle<Double>, %19 : $Builtin.Int64) // id: %25

bb6:
  %26 = argument of bb6 : $TensorHandle<Double>     // user: %27
    %27 = struct $Tensor<Double> (%26 : $TensorHandle<Double>) // user: %28
    return %27 : $Tensor<Double>                    // id: %28
---- END OF ANALYSIS STATE FOR FUNCTION ----------

From the above, br bb6(%6 : $TensorHandle<Double>) and br bb6(%15 : $TensorHandle<Double>) are not marked for accelerator, so they triggered
accel-to-host copy warnings for %6 and %15 before this patch. However, these
tensors effectively serve as result tensors of the program (this point becomes
more clear, if we add a t += 0.0 right after the while loop in the above
test case, where the resulting tensor would become a result tensor of the TF
program), so issuing copy warnings for them is not very useful.
Deleted the scalarToHost() test case from
diagnostics_scalar_transfers.swift, because it's difficult to construct a test
case where we'd still warn on copying a scalar value from accelerator to host,
but the other test scalarToAccelerator() provided coverage for the compiler
flag -tf-warn-scalar-transfer.
Resolves SR-8313.

@swift-ci please test tensorflow

You have convinced me that eliminating warnings for transfers that are async with respect to the TF computation is probably a good idea.
But whether the transferred value gets used in graph ops seems orthogonal to whether it's async wrt the computation. For example, here's a transfer that's async even though the value gets use in graph ops:
// weights and inputs are on accelerator
loop {
  let predictions = predict(weights, inputs) // predict happens on accelerator
  print(predictions) // transfers predictions to host
  let gradients = gradient(weights, inputs, predictions) // gradient happens on accelerator
  weights -= gradients
}

Therefore, what if we just eliminate all transfer-to-host warnings? This will eliminate warnings for transfers that are async with respect to the computation. Transfers that block the computation should still produce warnings, because they'll emit copy-to-accelerator warnings!

Discussed a bit more in person. I like the simplicity of only warning on host->TF transfers!
One potential concern is that TF->host transfers within a loop can still potentially slow down TF performance. e.g.
while ... {
  weights -= tf_computation(...)
  print(weights)
}

Since weights keep being updated, if the transfer is not fast enough, and TF does not have enough RAM to buffer the older copies of weights to be sent to host, that can block TF computation. This concern remains valid also in the case of weights being functionalized -- where each loop iteration produces a new copy.
Marc made a fair point that whether this would actually impact TF performance depends on the runtime context -- how fast the network is, how much TF RAM, and how large is weights, etc. So it's not clear that issuing a compile-time warning is always the most appropriate thing to do.
As the next step, Marc will write up a doc to seek more team/community input, and I'll hold off on this PR.

I don't think that this patch is the right direction, but I think that you're on to something here.  My objection to this patch in particular is that there is no way to know whether something is "async".  I think you're trying to allow things like:
let x = tensorstuff()
print(x)
But it is very simple for this to become synchronous w.r.t. the accelerator:
var x = tensorstuff()
x = sin(x)   // copy to host, libm sin(), copy back to accel
tensorstuff(x)
I think that sends of scalar values from the host to the accelerator should not be a warning: this should be implementable with an efficient broadcast to all the replicas, and is the vastly most common case for unstructured control flow (where we send out bools :).
It's also worth pointing out that the case in the testcase only happens because the function is marked public, which isn't what normal models will do.  We do this in the testsuite because it is a simple way to force a deabstraction/partitioning scope.


pkg/plugins: add plugin name in discovery path

The current plugin discovery mecanism expect all the socket and spec to be located at the root of /usr/share/docker/plugins. When running a plugin in a container mounting /usr/share/docker/plugins as a volume can be problematic as it would give a plugin access to all other plugin sockets.
This patch add a lookup for /usr/share/docker/plugins/{pluginname}/{pluginname}.sock before fallbacking into /usr/share/docker/plugins/{pluginname}.sock.
Let me know if this need better testing (for the fallback, the spec), I rushed this quickly in the contributor room between two session.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "discovery-plugin-path" git@github.com:proppy/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

@GordonTheTurtle thanks for flagging me a as contributor newb

I think this is a good idea, but that directory is going away. See #13951 for more information.

@proppy I've made the subsequent changes in #13951 to support subdirectories. I'm going to close this PR. Please, feel free to review the changes there. Thanks a lot for thinking of this.


activate provisioner repos

this would replace https://github.com/SUSE-Cloud/automation/pull/625

Why did we integrate the activate/deactivate functionality anyway when everything gets activated on install?

Why did we integrate the activate/deactivate functionality anyway when everything gets activated on install?

Because repos can be added after the install... That's the whole point of the change.

So you still need to remove line 342 and the block starting at line 362...

+1

:+1:

+1


Logout button is named "Remove account"

This was actually done on purpose.
Is there a better way to phrase this?

That seems like a technical description. To the user, for all intends and purposes, it is simply logging out right? If you want to make clear that user data is cleared from the device maybe put that as a note on the screen after clicking...? Anyway just my two cents.

I think you are right. Damn those developers using their technical descriptions for everything!
While we are at it, I would like to move this functionality to the navigation drawer header. Doesn't make any sense to have this as an "action" next to the list of time sheets.


"Undefined variable: allCategories (View: C:\Users\JeuLun\Desktop\E-commerce\resources\views\vendor\voyager\products\edit-add.blade.php)"

Laravel Version: 5.5
Voyager Version: 1.0
PHP Version: 7.2.3

Description:
The code associated with the issue:
<?php $__currentLoopData = $allCategories; $__env->addLoop($__currentLoopData); foreach($__currentLoopData as $category): $__env->incrementLoopIndices(); $loop = $__env->getLastLoop(); ?>
Steps To Reproduce:
Whenever I wanted to add/edit a product.

As this is not a Voyager view you have to provide some more information/input like your view-file and what exactly you are trying to do and how

Ah very sorry for your time taken, its just me forgotten to insert my controller name for the BREAD info....
Thanks for replying instantly.


[CLOSED] Audit currently ported implementations for sizes and boundary conditions

 Issue by izaera
Friday Nov 01, 2013 at 17:27 GMT
Originally opened as https://github.com/izaera/cipher/issues/20

Given that current implementations have been ported from Java it could be the case that they work for the tests but fail for boundary conditions (due to overflows or things like that).
I want to make sure that the current algorithms don't suffer these issues.

 Comment by izaera
Thursday Nov 14, 2013 at 18:51 GMT

All seems to be OK. Although Salsa20 checks for overflow when 2^70 bytes have been processed I decided not to do the same for SIC because it causes some overhead and is very unlikely that it happens.
I added a comment to warn users of SIC so that I can sleep well :-P.


Adds flex layout to the wiki edit panel so that the heights will fill

Purpose
Adds flex layout to the wiki edit panel so that the heights will fill.
Changes
The display type of the elements contained in the the body of the edit panel now have flex layout.
Side effects
flex box is not IE 9 compatible so it falls back to original set height which shows a 500px height box that fits and leaves space for narrow view.

Pinging @brianjgeiger and @rliebz

@sloria This should fix the last of the minor display issues with full-sized edit column I mentioned in my PR.

slick. :octopus:


Repo sync for protected CLA branch

The pull request is created from master637363929907738203 to master to fix git push error for protected CLA branch

@cmcclister : Thanks for your contribution! The author(s) have been notified to review your proposed change.


python3Packages.aioshelly: 0.6.3 -> 0.6.4

Motivation for this change
Update to latest upstream release 0.6.3
Change log: https://github.com/home-assistant-libs/aioshelly/releases/tag/0.6.4

Related Home Assistant change: https://github.com/home-assistant/core/pull/51081
Target Home Assistant release: current (only dependency update, no code changes)

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Added a release notes entry if the change is major or breaking
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 124463 at eb1353f5 run on aarch64-linux 1

3 packages built successfully:

home-assistant
python38Packages.aioshelly
python39Packages.aioshelly


Disable automatic image download

Is it possible to disable automatic image downloading? On my iOS device I have it setup where images are only downloaded when I tap on them but that doesn't happen on the desktop client.
Videos are however only downloaded when I tap on them (both on my device and on the desktop client) which is the intended setting.
Is there a way to get this behavior?

i don't know if this would be possible ...

Is this an API/WhatsApp limitation? I'm not familiar with Objective-C so it' would be a bit hard for me to point to where a change could be made.

I think WhatsApp must implement this feature because it isn't possible to limit the communication between WhatsApp Web and the App. We don't ask to get the messages, we only open web.whatsapp.com.

correct, but i will check the option to hook into the getMessage Event...
need some time for that


fix: default datax plugin

Purpose of the pull request
This pr fix default datax plugin, using RDBMS as default.
Fix https://github.com/apache/dolphinscheduler/issues/14180

Please associate PR to your issue.

does datax use rdbms as its default plugin?

does datax use rdbms as its default plugin?

IMHO, datax use rdbms as default🤔.

Codecov Report

Merging #14204 (22ee1c8) into dev (c6ac356) will decrease coverage by 0.04%.
The diff coverage is 4.61%.

:exclamation: Current head 22ee1c8 differs from pull request most recent head 4862a84. Consider uploading reports for the commit 4862a84 to get more accurate results

@@             Coverage Diff              @@
##                dev   #14204      +/-   ##
============================================
- Coverage     38.36%   38.32%   -0.04%
+ Complexity     4469     4465       -4
============================================
  Files          1229     1229
  Lines         42887    42863      -24
  Branches       4764     4732      -32
============================================
- Hits          16454    16429      -25
- Misses        24608    24611       +3
+ Partials       1825     1823       -2

Impacted Files
Coverage Δ

.../server/master/runner/WorkflowExecuteRunnable.java
10.34% <0.00%> (-0.04%)
:arrow_down:

...er/master/runner/operator/TaskTimeoutOperator.java
0.00% <0.00%> (ø)

...dolphinscheduler/plugin/task/datax/DataxUtils.java
0.00% <0.00%> (ø)

...nscheduler/service/process/ProcessServiceImpl.java
30.96% <11.53%> (-0.03%)
:arrow_down:

... and 35 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

restart the failed E2E


Add ClipboardHelper for clipboard operations

Added ClipboardHelper.h and ClipboardHelper.cpp to implement clipboard functionality.
Registered HsQMLClipboardHelper type in QML

This update allows QML to access clipboard operations through a C++ helper class, enabling text copying to the system clipboard.

@Kleidukos wanna review?

I am honoured by the offer, but I am illiterate in C++ 🥲

@Kleidukos That's fine. Do you know any security by any chance?
https://github.com/futrnostr/futr/blob/f1306f5dda1e8ab65b5f239d58b7461e8bc679f3/src/Nostr/Encryption.hs
see https://github.com/futrnostr/futr/pull/21
I wrote this, but I have no clue what I am doing here hahahaha
it works though.....

I can emit some recommendations, as I participate in the Haskell Cryptography Group, but nothing beats an audit. ;-)


Make volume slider logarithmic

A linear volume slider makes any values in the top ~80% not make much difference. An intuitive slider would be logarithmic.

An option would make more sense


[Feature Request]: feign.Target.url should be RefreshScope bean to refresh URL of a feign client instance

In the integration environment we need to frequently change feign client url due to some unavoidable circumstances
Deploying application everytime after change in the feign client url is not a wise idea. Feign comes with out of the box support for loading URL through configuration property feign.client.{contextId}.url. Since this property is applied at the application startup during  FeignClient instance creation and there is no way to refresh these settings via /actuator/refresh. However, feign client connectTimeout and readTimeout are refreshable with the enablement of the property feign.client.refresh-enabled.
Possible solution
Whenever feign.client.refresh-enabled=true then FeignClient constructed from org.springframework.cloud .openfeign.FeignClientFactoryBean should be composed with Refresh scoped ReferableHardCodedTarget<T> (new target extending feign.HardCodedTarget<T>).  ReferableHardCodedTarget<T> will have refreshcoped URL bean RefreshableUrl instead of url property of type string.
Then /actuator/refresh will be able to refresh feign.client.{contextId}.url via RefreshableUrl bean.
Feature demand
After looking at issue #483, I have realised that many of us are expecting this feature to be available. Refer to this comment.
Additional context
If the request looks justified then I will be happy to contribute the same.

May I have any feedback?

May I have any feedback?

Hello @jas34 , thanks for reporting the issue. We'll discuss it within the team and get back to you.

Hello, @jas34 I have marked it as an enhancement, but I'm not sure how soon I'll be able to work on it. Would you like to submit a PR?

@OlgaMaciaszek, I will be happy to contribute. I will start working on this next week, expect PR soon.

Sounds great, @jas34 .

@OlgaMaciaszek here is PR https://github.com/spring-cloud/spring-cloud-openfeign/pull/766


Modify README to guide contributors

It will include:

dependencies
installation
testing
and other guidelines.

Geat! thanks for your help, I am making you a contributor


Undetect

Hey Guys,
How can i undetect the File?
When the file is opened, it is displayed by the anti virus program. How can I prevent the person from NOT noticing that I have sent it to them?
Greetings MajinBoo
(Written with Google translator :D)

judging by the fact that you're accessing a remote system that isn't yours (correct me if wrong), I don't think that's possible bro
what file are you trying to send?

Its for the Client Build file, I think that was the Name. Do you know any very good Keyloggers with the Features like this one

Hey Guys,
How can i undetect the File?
When the file is opened, it is displayed by the anti virus program. How can I prevent the person from NOT noticing that I have sent it to them?
Greetings MajinBoo
(Written with Google translator :D)

Please don't use this Software... The Client should be aware that you are connecting to him. You are looking for Trojan wich Quasar isn't.

Oh okey, do you know good Trojan?


[Automation] Generate Fluent Lite from fluidrelay#package-2022-06-01

[Automation] Generate Fluent Lite from fluidrelay#package-2022-06-01

/azp run prepare-pipelines

/azp run java - fluidrelay - ci


Dont close

Hi im new to this i truly do not know how to use this.
If someone can give me a full guide that woud be nice.
My discord user is ponscripter.901.
Please add me and help me.
Thank you.
Also dont close please

Do not come back.


To-do list

Basic to-do list, in order to document remaining changes.

[x] Change changeURL in order to detect whether defaults have been set
[ ] Deal with Select All / Deselect All buttons (first idea is having just a new URL parameter with select=all/none)
[x] Investigate weird performance issue (seems slower now than just calling changeURL without arguments) with how I'm now calling changeURL

In order to check if defaults have been changed, look into how processData sets the default countries (line 439) and adapt from there.

:heavy_check_mark: Change changeURL in order to detect whether defaults have been set
Need to test this to check if works/borks stuff.

New idea. Having a button to restore to defaults (in the middle of the select all / deselect all)

:heavy_check_mark: Investigate weird performance issue (seems slower now than just calling changeURL without arguments) with how I'm now calling changeURL
Remembered to check the actual live page if my perceived performance issue (slight 1 second pause between button presses) was there and it turns out it is, which means my code isn't directly responsible for it. It is something to look into forward.

:heavy_check_mark: Deal with Select All / Deselect All buttons (first idea is having just a new URL parameter with select=all/none)
The buttons have the basic functionality, however two things need to be solved before the pull request:

[ ] Changing Region after selecting all doesn't update correctly the URL (the url still thinks everything is selected, even though it is not)
[ ] Making Vue.js recognize the new select parameter

The createURL event seems to fire before the actual renderization/selection of the buttons/countries. Using the checkbox variable to halt all being added should work.

:heavy_check_mark: Changing Region after selecting all doesn't update correctly the URL (the url still thinks everything is selected, even though it is not)
:heavy_check_mark: Making Vue.js recognize the new select parameter

The code should now be ready for a pull request. Tomorrow, after some basic checks.
In case I decide to add the "restore to defaults" button, a thing of note is that changing the selectedCountries array also changes everything else, so that's pretty much how to do it.


feat: add AthenaConfig to impl.py

Description
Add AthenaConfig to impl.py following recommendations
I have added the Table configuration as well as the connection parameters that can be passed to cursor.execute()
This might help to resolve https://github.com/dbt-athena/dbt-athena/issues/377, but it doesn't fix it by itself
Models used to test - Optional
I ran the unit tests locally and they all passed
I ran some of the functional tests and they passed too, but I didn't run all of them
Checklist

[x] You followed contributing section
[x] You kept your Pull Request small and focused on a single feature or bug fix.
[x] You added unit testing when necessary
[ ] You added functional testing when necessary

I believe that there is still some work to do no?
In https://github.com/dbt-athena/dbt-athena/issues/377 we decided to pick the workgroup from model config and pass it down to adapter.run_query_with_partitions_limit_catching, this means that in each macro you need to:

pick the workgroup from config using jijia-> {%- set work_group = config.get('work_group', default=target.work_group) -%}
inject workgroup when possible to when we execute queries

Hey @nicor88 you're right there is still some work to do, but I thought I would start off with a smaller change first which might help with #377. In the meantime I've raised a question on slack channel https://getdbt.slack.com/archives/CBSQTAPLG/p1694451069966319 about the best way of tackling this. I'm worried about the amount of refactoring required if I modify all the materialisations.

@nicor88 Did not know there was a slack channel raising now :-)

@svdimchenko I don't have permission to add the label to run the functional tests, do think it's worthwhile running those?
Also not too sure what docstring too used because explanation on dbt website isn't very clear: database- and relation-level configs
Hence why I raised a question on slack. I'll get the attribute descriptions from the README.

@svdimchenko I don't have permission to add the label to run the functional tests, do think it's worthwhile running those?
Also not too sure what docstring to use because explanation on dbt website isn't very clear: "database- and relation-level configs"
Hence why I raised a question on slack. I'll get the attribute descriptions from the README.

I agree with you, docstring is not obligatory. However we should have all parameters defined I guess. So this comment should be fixed: https://github.com/dbt-athena/dbt-athena/pull/412#discussion_r1322474172

@SoumayaMauthoorMOJ it's recommended for new contributors to follow the contributing section.
In there there is a step called make setup that also takes care of installing  the pre-commit hooks, therefore the same checks that we execute in the CI are executed before commiting - please have a look - exactly as @svdimchenko suggested btw.

Sorry will do this evening  :-)


e2e: remove chrome

chromedp has led to flakiness every now and then
it was used to check that static assets dont return 404
we can just use regular http GET to do the same check

[ ] I added CHANGELOG entry for this change.
[x] Change is not relevant to the end user.

Changes

Verification

Chrome is needed to evaluate JS here.


MS SQL engine support

Support of SQL Server
Limitations:

No mysqldump equivalent, so generated tests must be supplemented by tables_schema.sql with CREATE TABLE ... queries
sqlcmd utility must be installed. See https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup-tools
Limit with offset support only for SQL Server 2012 and above. In older versions it can be made only with ugly queries like in http://stackoverflow.com/questions/2135418/equivalent-of-limit-and-offset-for-sql-server
Values of UNIQUEIDENTIFIER type will be treated as UUID string, not GUID
NULL values for BINARY or VARBINARY are not supported  (at this moment) due to bug in go-mssqldb driver. See https://github.com/denisenkom/go-mssqldb/issues/196
All columns with IDENTITY will be excluded from Insert and Update clause (even if IDENTITY_INSERT is set to ON)
Special types are left behind

SQL Server 2016 docker images:

Windows: https://hub.docker.com/r/microsoft/mssql-server-windows/
Linux: https://hub.docker.com/r/microsoft/mssql-server-linux/

Bugs are possible, but tests pass (without FK)

Wow, there is an impressive amount of work here, thank you. Being primarily Linux users we'd not really given much thought to MS SQL. You've given us a lot to review and discuss, we'll try and get this done as quickly as possible. Thanks again.

I forgot to mention, excellent work and thank you very much for this! It looks like the code slid in pretty nicely for the most part :)

@aarondl, about FK. Yes, tests are passing when foreign keys are disabled.

@aarondl, now all inserts processing without AutoGenerated columns list, but I do not know what to do with the updates, I do not yet see any other way.

I would like to say such awesome work @nemec784!

Now all tests are passing (including Upsert)

Hey there. Planning on re-reviewing very soon. I've been out of town on business and couldn't get to this. Join us on Slack if you'd like to collaborate in something closer to real time: https://sqlboiler.from-the.cloud

Unfortunately, my knowledge of the language and the difference in time zones do not allow me to communicate in real time, but thanks for the invitation.

Thanks for review!
I have made changes and now uniqueidentifier treats as uuid. All other mistakes are also fixed.

@aarondl, please review the latest changes.

Went to go test this. The postgres and mysql tests are broken. Template formatting errors:
Error: unable to generate output: failed to format template

 733 			eventOneColumns,
 734 			eventOneColumnsWithDefault,
 735 			eventOneColumnsWithoutDefault,
 736 			nzDefaults,
 737 			whitelist,
>>>> 		)update := strmangle.UpdateColumnSet(
 739 			eventOneColumns,
 740 			eventOnePrimaryKeyColumns,
 741 			updateColumns,
 742 		)if len(update) == 0 {
 743 			return errors.New("models: unable to upsert event_one, could not build update column list")

Also, I haven't looked at it, but it might be smart to make the default schema for mssql "dbo"?

Was working a bit on the CI. It's pretty complicated because typically you've got sqlcmd & the db in a container, and running sqlboiler's tests requires sqlcmd to be in PATH. I wonder if I could fake it out by placing a script in it's place... Hmm.

Fixed. Now the tests are passing for MSSQL and PostgreSQL (MySQL did not check).

@aarondl, I see only one way to set default schema name - remove default value from:
rootCmd.PersistentFlags().StringP("schema", "s", "public", "The name of your database schema, for databases that support real schemas")

update description to:
"The name of your database schema, for databases that support real schemas (defaults: Postgres - public, Sql Server - dbo)"

and set it in preRun depending on the driverName.

@aarondl, it looks like there is an error in circle.yml:
    - ./sqlboiler postgres -o "postgres"
    - ./sqlboiler postgres -o "mysql"

https://github.com/vattle/sqlboiler/blob/master/circle.yml#L11

@aarondl, sqlcmd can be installed separatly:
https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup-tools
And circleci allow to install additional software via apt-get:
https://circleci.com/docs/1.0/installing-custom-software/#installing-via-circleyml

Let's iterate on any remaining pieces. I've done the change for the driver specific schemas. I also noticed that error in the circle.yml yesterday when I opened it and corrected it.

Thanks for all the hard work :)

It was a really hard work, but we did it! Thank you for your time, it was excellent experience for me! :-)

Thank you @nemec784, excellent job.


Issue while compiling wasm extension with tinygo

Hi Team,
I've latest tinygo & go installed locally. On compiling the main.go as suggested on the page in ep07 getting lot of errors, pasting the output below. Did I miss something?
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:151:6: ProxyLog redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:20:6: 	other declaration of ProxyLog
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:155:6: ProxySetProperty redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:107:6: 	other declaration of ProxySetProperty
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:159:6: ProxyGetProperty redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:104:6: 	other declaration of ProxyGetProperty
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:163:6: ProxySendLocalResponse redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:23:6: 	other declaration of ProxySendLocalResponse
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:169:6: ProxyGetSharedData redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:27:6: 	other declaration of ProxyGetSharedData
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:173:6: ProxySetSharedData redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:30:6: 	other declaration of ProxySetSharedData
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:177:6: ProxyRegisterSharedQueue redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:33:6: 	other declaration of ProxyRegisterSharedQueue
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:181:6: ProxyResolveSharedQueue redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:36:6: 	other declaration of ProxyResolveSharedQueue
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:185:6: ProxyDequeueSharedQueue redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:39:6: 	other declaration of ProxyDequeueSharedQueue
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:189:6: ProxyEnqueueSharedQueue redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:42:6: 	other declaration of ProxyEnqueueSharedQueue
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:193:6: ProxyGetHeaderMapValue redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:45:6: 	other declaration of ProxyGetHeaderMapValue
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:197:6: ProxyAddHeaderMapValue redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:48:6: 	other declaration of ProxyAddHeaderMapValue
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:201:6: ProxyReplaceHeaderMapValue redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:51:6: 	other declaration of ProxyReplaceHeaderMapValue
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:205:6: ProxyContinueStream redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:69:6: 	other declaration of ProxyContinueStream
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:209:6: ProxyCloseStream redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:72:6: 	other declaration of ProxyCloseStream
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:212:6: ProxyRemoveHeaderMapValue redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:54:6: 	other declaration of ProxyRemoveHeaderMapValue
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:216:6: ProxyGetHeaderMapPairs redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:57:6: 	other declaration of ProxyGetHeaderMapPairs
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:220:6: ProxySetHeaderMapPairs redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:60:6: 	other declaration of ProxySetHeaderMapPairs
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:224:6: ProxyGetBufferBytes redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:63:6: 	other declaration of ProxyGetBufferBytes
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:228:6: ProxySetBufferBytes redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:66:6: 	other declaration of ProxySetBufferBytes
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:232:6: ProxyHttpCall redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:75:6: 	other declaration of ProxyHttpCall
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:238:6: ProxyCallForeignFunction redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:80:6: 	other declaration of ProxyCallForeignFunction
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:242:6: ProxySetTickPeriodMilliseconds redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:83:6: 	other declaration of ProxySetTickPeriodMilliseconds
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:246:6: ProxySetEffectiveContext redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:86:6: 	other declaration of ProxySetEffectiveContext
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:250:6: ProxyDone redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:89:6: 	other declaration of ProxyDone
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:254:6: ProxyDefineMetric redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:92:6: 	other declaration of ProxyDefineMetric
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:259:6: ProxyIncrementMetric redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:95:6: 	other declaration of ProxyIncrementMetric
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:263:6: ProxyRecordMetric redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:98:6: 	other declaration of ProxyRecordMetric
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls_mock.go:267:6: ProxyGetMetric redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/abi_hostcalls.go:101:6: 	other declaration of ProxyGetMetric
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/hostcall_utils_tinygo.go:28:6: RawBytePtrToString redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/hostcall_utils_go.go:28:6: 	other declaration of RawBytePtrToString
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/hostcall_utils_tinygo.go:36:6: RawBytePtrToByteSlice redeclared in this block
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/hostcall_utils_go.go:37:6: 	other declaration of RawBytePtrToByteSlice
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/hostcall_utils_go.go:32:9: cannot use size (variable of type int) as uintptr value in struct literal
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/hostcall_utils_go.go:33:9: cannot use size (variable of type int) as uintptr value in struct literal
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/hostcall_utils_go.go:41:9: cannot use size (variable of type int) as uintptr value in struct literal
../../../../go/pkg/mod/github.com/tetratelabs/proxy-wasm-go-sdk@v0.16.1-0.20220223010114-7b68c2382bf8/proxywasm/internal/hostcall_utils_go.go:42:9: cannot use size (variable of type int) as uintptr value in struct literal

Installed versions:
go : go1.15.2 darwin/amd64
tinygo : 0.22.0 darwin/amd64 (using go version go1.15.2 and LLVM version 13.0.0)

There might be some mismatch between the versions used in ep07 -- for the latest and greatest tutorial, check this: https://tetratelabs.github.io/wasm-workshop/1_prerequisites/
Let me know if you still can get it to work and we can ask other experts as well on the community slack


(Re-)create metrics.fr.cloud.gov dashboards

We just need to upload them, also we should make sure we are all admins in grafana.

I guess this is the relevant page in the docs?


fix File.exists? deprecation

File.exists? is deprecated; use File.exist? instead

@shairontoledo can you merge? :pequi:
With Ruby 3.2 we need this fix 👍🏻

I encountered similar issue. Any chance we can have a new version released?

@okarsono gem 0.9.8 has been pushed


Vulnerability roundup 84: gnome-font-viewer-3.34.0: 1 advisory

search, files

[ ] CVE-2019-19308 CVSSv3=5.5 (nixos-20.03)

Scanned versions: nixos-20.03: 82b5f87fcc7. May contain false positives.

See also: #75977

20.03 is Frozen and EOL.
As such, issue is closed.


AsterixDB Source Operator

This PR implements AsterixDBSourceOp.
Limitations and design compromises:

Due to the fact that AsterixDB supports semistructured data, while Texera only supports row-based data, we have to flatten any existing datatypes in AsterixDB in order to create a Tuple in Texera. Currently, we do the flattening in AsterixDB by requesting special defined queries, which result in format of [CSV](https://asterixdb.apache.org/docs/0.9.6/csv.html). This CSV format can also save network load, comparing to JSON or ADM.

The connection to AsterixDB is HTTP based, the response are in JSON. We need to parse this JSON response to get the result (the actual result could be in CSV format). We used scalaj as the HTTP Client, however it cannot parse some special encodings. Thus it will result in a loss of un-parsable data. This only occurs when any text field contains non UTF-8 characters. We need to explore better HTTP Clients in scala to handle this issue.
Update: now replaced scalaj with unirest-java, problem solved.

For simplicity, we are using the synchronized API instead of the asynchronous API to query from AsterixDB. Currently the timeout limit is set to 10 seconds, which means the HTTP Response of the query Request must get returned in 10 seconds, otherwise it will be dropped. This also means the query that we sent must not be very expensive. To support an expensive query, we can utilize the progressive mode, which cuts an expensive query into several mini queries that can respond within 10 seconds.
Update: will keep using synchronized API as the Texera operator itself is synchronized.

Full text search query is pretty complex and not well defined in AsterixDB, some known issues:

Disjunction on multiple Conjunctions would give Internal Error (on versions <=0.9.5)
Example:
(ftcontains(t.text, ["Today", "at", "work"],  {'mode': 'all' }) OR ftcontains(t.text, ['Today', 'at', 'home'],  {'mode': 'all' }))
Solution: remove "all" when using Disjunction on multiple Conjunctions, because mode by default will be 'all':
(ftcontains(t.text, ["Today", "at", "work"]) OR ftcontains(t.text, ['Today', 'at', 'home']))
Does not support phrase search.

Given the issues above, right now we only support one input from keywords, in either Disjunction ('any') or Conjunction ('all') mode. The example input on keywords parameter is as following:

['Today', 'at', 'work'], {'mode': 'all'}
['Today', 'at', 'work'], {'mode': 'any'}

The HTTPClient uses logback, which default log level is set to DEBUG. This will result in a massive amount of logging, which needs to be addressed later.

 Created from JetBrains using CodeStream

I am adding support for<EMAIL_ADDRESS>(Big DB's deployed version).

Converted this as a draft now since progressive logic on AsterixDB needs more discussion.


Examples cleaned up

Almost everything is fine now, build noise is way down.

Hey, sorry this has been sitting for so long; I've just been swamped.  I'll be able to look at and review this request on Sunday.  Sorry for the delay.

no problem. i'm quite busy too. since there are no pressing issues, i'm fine with delays.

Thanks a ton, and sorry for the amazing delay.  For some reason my gcc thinks ctime returns an int, but I'm just not going to touch that :-/ .