Does not work with NUXT

Hi,
I tried getting it to work with Nuxt however, facing similar issue to this.
https://github.com/nuxt/nuxt.js/issues/2241
Is vue-burger-menu SSR friendly?
Thanks

It does not support SSR at the moment
PRs welcome.

@mingsterism You can use this - https://github.com/egoist/vue-no-ssr

To use it in with Nuxt, I had use it as a plugin with no SSR
plugins/slide-menu.js
import Vue from 'vue'
import { Slide } from 'vue-burger-menu'
Vue.component('Slide', Slide)

nuxt.config.js
plugins: [ { src: '~plugins/quill-editor', ssr: false }]

index.vue
#app
 no-ssr
    Slide
        a#home(href="#")
          span Home

@mritunjaygoutam12 Adding this in WIKI would be good

It is not working with Nuxt because of all recalls to document. In order to make it work all of the components need to be rewritten in such a way that they are not recalling document during server rendering.

This can be changed:
import { Slide } from 'vue-burger-menu'
import { ScaleDown } from 'vue-burger-menu'
import { ScaleRotate } from 'vue-burger-menu'
import { Reveal } from 'vue-burger-menu'
import { Push } from 'vue-burger-menu'
import { PushRotate } from 'vue-burger-menu'
```

To this:
```
import { Slide, ScaleDown, ScaleRotate, Reveal, Push, PushRotate } from 'vue-burger-menu';
```

Has anyone made it work as @jaskiratr explained? It throws 'document is not defined' error :
var styleElement = document.querySelector('style[' + ssrIdKey + '~="' + obj.id + '"]')

Ok.. fixed.
Vue.component('Slide', Slide)

instead of
Vue.component('SlideMenu', Slide)

@jaskiratr,
I use plugin slideMenu.js:
import Vue from 'vue'
import { Slide, ScaleDown, ScaleRotate, Reveal, Push, PushRotate } from 'vue-burger-menu'

Vue.component('SlideMenu', Slide)
Vue.component('ScaleDownMenu', ScaleDown)
Vue.component('ScaleRotateMenu', ScaleRotate)
Vue.component('RevealMenu', Reveal)
Vue.component('PushMenu', Push)
Vue.component('PushRotateMenu', PushRotate)

and register it
  plugins: [
    { src<EMAIL_ADDRESS>ssr: false }
  ],

and in template I have:
<template>

    <no-ssr placeholder="loading...">
      <Slide>

          Home

      </Slide>
    </no-ssr>
</template>

and It works! no 'no document' errors anymore.
but still have error in the console:
commons.app.js:12032 [Vue warn]: Unknown custom element: <Slide> - did you register the component correctly? For recursive components, make sure to provide the "name" option.

found in

---> <Desktop> at layouts/desktop.vue
       <Root>

Did someone have to deal with it as well it?

The error still persists. Help me >>>> document is not defined

@allisonaraujoo I just did as @sbefort  said to implement and it worked.
Nuxt Version: 2.12.1

@allisonaraujoo make sure to remove Slide (or whichever you are using) from your component's components property.
Slide would be global via the plugin

In Nuxt 3 you can use this in your plugin folder vue3-burger-menu.client.js
import { Slide } from 'vue3-burger-menu'
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.component('Slide', Slide)
})


Question about when to add Noise in Stable Diffusion for Score Dist. Sampling?

I noticed that in this repo you are adding noise to the image after it has been already passed through the VAE, which seems to differ from the original paper.
After reading fantasia3D, since they use a mask I was trying to apply the mask to the noise itself (altho I'm not quite sure if that's what they do), but since the noise is applied after passing through a VAE it doesn't seem possible. Is there another way to do masking on the noise in the current work?
https://github.com/ashawkey/stable-dreamfusion/blob/42b9193c73842a5904183def95cb7df49ca05642/guidance/sd_utils.py#L105-L120

In the paper, the noise is still added prior to passing through the unet for noise prediction. The same happens here, self.encode_imgs isn't the unet, just producing a latent representation of the image for use with the unet. It's to this latent representation that noise is added, not to the original image. Thus this is just a latent diffusion model, operating in latent space rather than operating in the pixel space.
Now I haven't reason Fantasia3D in full yet, from a glance it seems they use a shape encoding of the mask + normal map as inputs to their diffusion model in that first stage. So it's not a simple process of applying the mask to the image or to the noise, but rather leveraging that information to produce a useful latent representation for downstream use, similar in spirit to how we use a latent representation of the image rather than the image itself. I think if you want to experiment with those ideas from Fantasia3D, you should be looking at how you can shape encode the mask information or shape encode the mask + image information to then be passed to the diffusion model.

mmm this makes sense, I guess because of the difference in network this is required.
I assume that working in pixel space for the noise could be made to work as well, but hasn't been done because then it would require more operations to move back to pixel space after diffusion.
I'm not entirely sure what Fantasia3D does, and hopefully once they release their code it should be more transparent what they mean.

Actually, I am still unsure why it matters if this is performed in latent space or image space?
For my specific case, I find that encoding in latent space introduces a lot of localized noise in the output, and am suspecting it may be due to using latent space. I am experimenting with changing it to image space, but is there some justification why it does in latent space other than efficiency?


Neither architype, nor library exist in Maven

Documentation https://statefun.io/getting_started/project_setup.html
Refers to archtype
$ mvn archetype:generate
-DarchetypeGroupId=com.ververica
-DarchetypeArtifactId=stateful-functions-quickstart
-DarchetypeVersion=1.1-SNAPSHOT
And dependency

com.ververica
stateful-functions-sdk
1.1-SNAPSHOT

Neither one of which exists in mvn

Hello @blublinsky,
Currently the way to use the archetype is by first building the project locally (you can follow the instructions here
We haven't published the artifacts to maven central, because the project is on its way to be a part of Apache Flink, and it would be published to maven central under its new artifact and package names (we will update the documentation once it happens)

Thanks Igal,
What is the timeframe for moving this to Flink?

We are in the process of migrating the code to the new repository and this should be completed next week, but an actual release would happen and some time later this/next month.
I'm wondering, for PoCing with Stateful Function at the moment, is it a big inconvenience for you to build the project yourself?
Thanks.

Thanks Igal,
Its fine for trying it out, was just wondering how real it is


[Doc] Incorrect description of UniformLoadShedder in pulsar site.

Search before asking

[X] I searched in the issues and found nothing similar.

What issue do you find in Pulsar docs?
There are some errors in the description of the UniformLoadShedder.
https://pulsar.apache.org/docs/next/administration-load-balance/#uniformloadshedder

We judge whether MsgRateThresholdExceeded by (Max-Min)/Min > Threshold as the graph show. But judge whether MsgThroughputThresholdExceeded by Max/Min > Threshold.
        double msgRateDifferencePercentage = ((maxMsgRate.getValue() - minMsgRate.getValue()) * 100)
                / (minMsgRate.getValue());
        double msgThroughputDifferenceRate = maxThroughput.getValue() / minThroughput.getValue();

        // if the threshold matches then find out how much load needs to be unloaded by considering number of msgRate
        // and throughput.
        boolean isMsgRateThresholdExceeded = conf.getLoadBalancerMsgRateDifferenceShedderThreshold() > 0
                && msgRateDifferencePercentage > conf.getLoadBalancerMsgRateDifferenceShedderThreshold();
        boolean isMsgThroughputThresholdExceeded = conf
                .getLoadBalancerMsgThroughputMultiplierDifferenceShedderThreshold() > 0
                && msgThroughputDifferenceRate > conf
                .getLoadBalancerMsgThroughputMultiplierDifferenceShedderThreshold();

What is your suggestion?
Correct the description of UniformLoadShedder.
Any reference?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

PTAL, thanks. @Demogorgon314 @lhotari @heesung-sn
I am not good at plotting graph, may be we need the author to fix this.


[Parse] isNonNull() check before constructing InOutTypeRepr

Fixes 2 compiler crashers
Minimum repro was:
_ as inout p<

@swift-ci Please smoke test

Nice, thanks!


Expand adapters concepts

Conceptually, explain the following in https://github.com/Point72/csp/wiki/Adapters:

[ ] Push and Pull Input Adapters
[ ] AdapterManagers
[ ] Writing an adapter in Python

We can add links to the how-to write adapter pages from here.

Probably worth doing https://github.com/Point72/csp/issues/272 first as adapters in their current state are a bit messy and confusing


dataset

I want to know how to make  profile face dataset，I cannot find useful code to make dataset,can you open this code?

You may refer to  wroten with Matlab & c.


use high precision float instead of medium in texture shader

Fiddle: https://jsfiddle.net/Icemic/wmdruwLc/show/light/
Device: MEIZU MX5 ( Android 5.1 )
Browser: Chromium
CPU: MTK Helio X10 Turbo (MTK6795)
GPU: PowerVR G6200
Detail: Draw a 800*600 image to a 800*600 canvas, there will be a 1px width line at right. After some test, I find that the image is scaled to 799*600. It must be to do with precision, maybe a GPU bug.

Solution: add precision highp float; to pixi.js/src/core/sprites/webgl/texture.vert (default is mediump)
Note: Need more test for detecting how many CPUs/GPUs effected by this bug.

A setting exists to change this i believe.
Take a look here: http://pixijs.download/v4.2.2/docs/PIXI.settings.html#.PRECISION

(and the reason it's not highp by default is due to compatibility issues on some devices if i remember correctly)

Thanks for the new docs!
But I think it is a issue only to do with sprite texture, solving it by editing global setting may not a good choise.
Besides, I did fix this problem by using highp. If it is a compatibility issue, how to explain it?

Some mobile devices do not support highp according to this comment: https://github.com/pixijs/pixi.js/issues/1922#issuecomment-115292500

Oh, I misunderstood your words before.
The issue shows that highp may cause compatibility issue, and according to http://stackoverflow.com/questions/31496639/webgl-highp-fragment-support, even iPhone5S and Nexus 5 have this issue.
Well, I have to admit the pr is not appropriate, I'll close it.
For this issue, detecting highp support by getShaderPrecisionFormat() and set PIXI.settings.PRECISION will work.

No...No, I'm a bit confused. 😭
It is said that use highpin fragment shaders will cause problem because highp support for fragment is optional, but not in vertex shaders.
So, I think my pr will not cause compatibility issue, and however fix another compatibility issue.

My bad!

Merged in my fork. Thank you.


Add an ember-basscss wrapper?

Again, thanks for an awesome project, @jxnblk.
I've noticed that recently you've begun wrapping basscss for other frameworks (ng, handlebars). I'm curious if there's interest in an Ember wrapper, namely one that integrates with the ember-cli.
Thanks to the modularity of this project it'd be possible to add each as a single module to an Ember project:

ember-basscss-buttons
ember-basscss-typography
ember-basscss-forms
etc.

Only requiring ember install:addon ember-basscss-buttons to inject basscss components and CSS into the app. With an all-encompassing ember install:addon ember-basscss which basically introduces dependencies for all the other modules.
I'd be happy to create all the wrappers for integrating basscss CSS and components (as a whole and as separate modules) into ember-cli projects. However, I don't know if you'd like those to be under your own repo umbrella, @jxnblk, or if I should just start creating them under mine. Thoughts?

I've only dabbled with Ember a little bit, so correct me if I misunderstand anything.
Generally, love this idea, and if you want to be the owner for these, feel free to do so. From my side of things, I would like to provide modularized UI components for different libraries that rely on their web-component-like aspects. It also seems like not too much work to provide options for simpler templating engines like Rails ERB and Handlebars, but those components would essentially just be helpers.
Ideally, it would be nice to have library-agnostic HTML templates for each component that could be versioned and converted to their relevant library-specific syntax – that's why I started digging into Handlebars, and am definitely interested in Ember's fast boot HTMLbars work. That said something like lodash templates is also something I want to look into for creating source templates.
Angular directives are probably first on my list, because of my familiarity and the popularity of the library. Polymer is also on the radar because of the similarities to spec-based web components. And, of course, React because of its component-based approach.
I think it'd be rad if you wanted to create an ember-basscss repo, and I could definitely link to it from this site. I'm currently pulling in README files for all the modules docs and plan on using the same approach for the handlebars-basscss repo, once its in better shape, with a larger section of the docs for Components. I don't know much about the ember-cli side of things, but it seems like a good idea.

Similarly to React/Angular/Polymer, Ember has support for web components that are attempting to adhere to the W3C as closely as possible [documentation]. The latest iterations are beginning to make these component first class citizens within the framework (an approach adopted from React). I definitely agree with you wholeheartedly, modularized UI components are the way to go, especially if they're library/framework agnostic.
I'd be happy to take ownership of the ember-basscss lib. Though, I'm first going to do a bit of digging and see if there's a method to expose web components to a wide array of front end frameworks, as that'd be ideal to attempting to manage multiple "wrappers" of Basscss. If something like Polymer is the lowest common denominator to create modular components to share among apps built in multiple frameworks (Ember/React/Ng/etc), perhaps that's the way to go. Whether that's achievable at this point, I have no idea. But, I'll do some digging and see.
Thanks for your time.

After a bit of digging, it appears that Ember 2.0 will support Polymer components (with intentions of supporting the full W3C spec in the future). So, it appears, at least for the Ember case, Polymer components is the place to start.
As such, I will close this issue and open a new one regarding Polymer components.


Identifying shadow FK values are not propagated when tracked as unchanged or modified

If the shadow PK is of nullable type
context.ChangeTracker.TrackGraph(principal, e => e.Entry.State = EntityState.Unchanged);
throws
Unable to track an entity of type '...' because primary key property '...' is null
context.Attach(principal) works, but marks the dependent as added

@AndriySvyryd Having trouble fully understanding this. If the key value of the dependent is null, then changing state to Unchanged without setting the key value should throw. Likewise, using Attach will mark the dependent as Added because it didn't have a key value set, assuming the key is generated. If the key is not generated, then it should throw like TrackGraph does.
What am I missing?

@ajcvickers The principal has the key set. How can I attach the principal and the dependent as Unchanged?

@AndriySvyryd When attaching, the primary key must be set. Because when you attach, you are saying that this entity already exists in the database, and hence already has a primary key value assigned.
If the primary key is in shadow state, and you disconnected the entity, then you need to carry the primary key with the entity in some way so that it can then be set again on the state entry before the entity is attached.

Changed the behavior for owned types where the state must match that of the owner, and the key values can be propagated said owner. Behavior for non-owned types remains the same.

@ajcvickers I don't see why owned types would be different, the owned dependent is not required to exist as there's no way of enforcing it.
Carrying around the key values and setting them feels too cumbersome when dealing with an untracked entity graph. In the common cases the dependents will have the same state as the principal, and if not it's simpler to fix the state once the entities are tracked.

I don't think we can say that an existing principal and an existing dependent is any more or less common than an existing principal and an new dependent.
Also, "an owned dependent is not required to exist as there's no way of enforcing it." I think we should discuss this since it seems to be contrary to the concept of an aggregate. That is, it's okay for some entity in an aggregate to not exist, but I don't think it's necessarily okay to then later add it to the aggregate and have it inserted. But if this is really okay, then I think aggregates have the same problem as non-aggregates and I don't see anyway to make Attach work in a standard way for primary keys in shadow state--we simply have no way of knowing the the dependent is new or not and making either choice will be right or wrong in different circumstances.
@divega?

We don't know whether the dependent will be new or not, but we do know that it will have the same key values as the principal.
We can detect the case where the shadow key values haven't been set as opposed to set to the default values.

Agreed that we can tell what the key values should be, but that's not the real issue here. The issue here is what state the dependent should be put into. If we follow what we do everywhere else, then it will always be Added. That's going to be a pretty bad experience. Likewise, if we change what we do everywhere else, then it's going to be a bad experience everywhere else.

I think we really need to decide what it means to have optional entities in an aggregate. @divega?

We can either mark them as Added or the same state as the principal, just in this particular case. This would be enough to allow the user to then change the state to what it should be.

@AndriySvyryd For owned types? Yes. The PR I sent out puts them in the same state as the principal. But based on previous comments we still need to understand if this might, at least sometimes, be wrong, since I think this impacts the entire experience of aggregates. @divega?
For non-owned types, I'm 99.999999% certain we will not change the existing behavior.

By particular case I mean identifying shadow FK that doesn't have the values set. I don't think we should do this for owned types that have non-shadow keys, but that depends on what we decide wrt aggregates.
But I'm 99.999999% certain that owned types are not aggregates.

Then what are owned types? If I have an owner and an owned entity, then together they form an aggregate.
We can't change the behavior in general for identifying relationships--that would be a massive breaking change.

An aggregate has more restrictions, as the one mentioned above. It would be implemented using owned types, but we don't have real aggregates yet.
Yes, if we propagate principal state it could be a breaking change for all code calling Attach on a graph that has identifying shadow FKs. But I find it hard to believe that this is a popular scenario, considering that we throw to shadow PKs found by convention and warn for explicit shadow PKs.

If the state ends up as Added, then we don't need to special case anything--the code as is works fine. If we start saying that entities that have a key in shadow state are going to be Unchanged, but if you move the key to the CLR type then the same code will result in Added, then I think this is extremely unexpected and goes against the general policy of shadow stateness--that properties in shadow state behave the same as properties not in shadow state.

With regard to aggregates, it was my understanding that the OwnsOne was the building block for aggregates support, just limited to certain relationship types for now. If that's not the case, then I think we need to discuss. @divega?

Marking them as Added would be fine, as long as this works:
context.ChangeTracker.TrackGraph(principal, e => e.Entry.State = EntityState.Unchanged);

We could treat shadow and non-shadow the same if we add API to mark any property as "Set" or "Not Set", this would also allow the users to save CLR default values to the database.

@AndriySvyryd @ajcvickers can't wait chat about this in person :sweat_smile: Hopefully the three of us will be able to meet in the office soon.

Thinking of both complex type and aggregate scenarios, I think it would be very unfortunate if this throws an exception rather than doing a correct update:
Customer customer;
using (var context = new MyContext())
{
    customer = context.Customers.First();
}

customer.Address.CellPhone = "555-555-5555";

using (var context = new MyContext())
{
    context.Update(customer);
    context.SaveChanges();
}

Using this model:
public class Customer
{
    public int Id { get; set; }
    public int Name { get; set; }
    public Address Address { get; set; }
}

public class Address
{
   public string Street { get; set; }
   public int Zip { get; set; }
   public string HomePhone { get; set; }
   public string CellPhone { get; set; }
}

This will work with the PR I sent, but not if the dependent is marked Added. And it doesn't involve the app developer having to know anything about setting special state and/or flags.
Interestingly, this will also work, which is pretty nice:
Customer customer;
using (var context = new MyContext())
{
    customer = context.Customers.First();
}

customer.Address = new Address
{
    Street = "1 Microsoft Way",
    Zip = 98052;
};

using (var context = new MyContext())
{
    context.Update(customer);
    context.SaveChanges();
}

@divega Can you take a look at this today? I'm holding off merging the PR until we decide what the behavior should be for owned dependents, but I think we need to make a decision in time to do something for 2.0.


build api support

If i built in the support for builds and submitted the PR, would you guys accept it?

Sure @scphantm,
We'd love to see build-info publish and get added.
I suggest you share with us the suggested API first.
Thanks

https://jfrog.com/knowledge-base/how-to-create-and-deploy-a-build-info-json-file-via-the-rest-api/


Newline not sent when evaluating a line.

vim-tidal used to immediately evaluate your code in the repl when you hit ctrl-e, now it sends the code snippet to the prompt but does not send the newline. You have to jump to the repl and click enter to evaluate your code. I don't know if this is an issue with ghci or vim-tidal.

This might be caused by https://github.com/tidalcycles/vim-tidal/commit/1f4d11548c9f25d12ce56015b31b60b264ff226a#r84654919.


Bump agent version to v3.64.0

Whoops, this has been superseeded by https://github.com/buildkite/elastic-ci-stack-for-aws/pull/1295 now.


modify scalaz dependency version to 0.1.0-0812841

https://github.com/scalaz/scalaz-reactive/issues/29

I guess you might want to drop support for Scala 2.11 @kolov


Setup associations

Hi there 👋!
In this PR I :
✅ Create a Classroom class and its constructor.
✅ Create Setter and Getter for @label.
✅ Create the has-many relationship between Classroom and Student.
✅ Create the belongs-to relationship between Classroom and Student.
✅ Make sure that when adding a student to a classroom it also sets the classroom for the student. And Make sure that when setting the classroom for a student it also adds it to the classroom's students.
✅ Create a Book class and its constructor.
✅ Create a Getter and Setter for the title and author.
✅ Create a Rental class and its constructor.
✅ Create a Getter and Setter for a date.
✅ Create the has-many side of Book and Rental.
✅ Create the belongs-to side of Rental and Book.
✅ Create the has-many side of Person and Rental.
✅ Create the belongs-to side of Rental and Person.
✅ Modify the constructor of Rental so Book and Person are set in it.

Thank you @mckent05 for your review.


Release new version 0.2.0

After closing #22 , it would be a good time for a new release:

[x] update README
[x] update CHANGELOG
[x] revise changes since 0.1.0 and bump version
[x] publish release

Closed via https://github.com/diego-plan9/lillinput/releases/tag/v0.2.0.


#resource- broken in links

I have a schema with some depth (like a user with an attribute thumbnail being a $ref to an image schema), an article having an author attribute iself being a user...
The generated markdown for the attribute table looks like:
 **[author:thumbnail:URL](#resource-date)** | *uri* | URL to an image file ...

The problem is the #resource-date is clearly false here, and in all my Attributes table they are "randomized".
No so randomized, in fact their quantities are right (if I have 6 attributes for the thumbnail (an image) of a user, I have 6 #resource-image, but in the wrong place.
Also (probably the same bug) some attributes does NOT have links on some cases they should have, and some which should not have (local strings) may have links.

The links are relatively new, so it sounds as though some edge cases just need more attention. The misdirection seems clear enough, could you provide a bit more detail on places where you expect links (or not) and aren't getting what you expect?

Actually, could you provide a specific example around the mis-linking as well? Pretty sure I've narrowed it down (https://github.com/interagent/prmd/blob/master/lib/prmd/templates/schemata.md.erb#L28), but having something specific would help be more certain.


load_from_disk vs load_dataset performance.

Describe the bug
I have downloaded openwebtext (~12GB) and filtered out a small amount of junk (it's still huge). Now, I would like to use this filtered version for future work. It seems I have two choices:

Use load_dataset each time, relying on the cache mechanism, and re-run my filtering.
save_to_disk and then use load_from_disk to load the filtered version.

The performance of these two approaches is wildly different:

Using load_dataset takes about 20 seconds to load the dataset, and a few seconds to re-filter (thanks to the brilliant filter/map caching)
Using load_from_disk takes 14 minutes! And the second time I tried, the session just crashed (on a machine with 32GB of RAM)

I don't know if you'd call this a bug, but it seems like there shouldn't need to be two methods to load from disk, or that they should  not take such wildly different amounts of time, or that one should not crash. Or maybe that the docs could offer some guidance about when to pick which method and why two methods exist, or just how do most people do it?
Something I couldn't work out from reading the docs was this: can I modify a dataset from the hub, save it (locally) and use load_dataset to load it? This post seemed to suggest that the answer is no.
Steps to reproduce the bug
See above
Expected behavior
Load times should be about the same.
Environment info

datasets version: 2.9.0
Platform: Linux-<IP_ADDRESS>-microsoft-standard-WSL2-x86_64-with-glibc2.31
Python version: 3.10.8
PyArrow version: 11.0.0
Pandas version: 1.5.3

Great to hear! I'll give it a try when I've got a moment.

@mariosasko is that fix released to pip in the meantime? Asking cause im facing still the same issue:
dataset = load_dataset("csv", cache_dir="cache", data_files=["/STORAGE/DATA/mijam/vit/code/list_filtered.csv"], num_proc=16, split="train").cast_column("image", Image())
dataset = dataset.class_encode_column("label")

quite fast.
Then I do save_to_disk() and some time later:
dataset = load_from_disk('/STORAGE/DATA/mijam/accel/saved_arrow_big')

really slow. In theory it should be quicked since it only loads arrow files, no conversions and so on.

@mjamroz I assume your CSV file stores image file paths. This means save_to_disk needs to embed the image bytes resulting in a much bigger Arrow file (than the initial one). Maybe specifying num_shards to make the Arrow files smaller can help (large Arrow files on some systems take a long time to load).


Replace (deprecated) username/password login by OAuth2 login

While I may not like the current behaviour of your bot very much, I would not like it to get banned on a technicality either. The current Reddit API guidelines insist on authenticating using OAuth2, while your code still uses an username/password combo. This patch changes this into a proper OAuth2 login. Fyi, this code is adapted from PoliteUserBotBots sources.

Commit Merged!


Update CONTRIBUTING.md with new tested JS features

These has been tested as working well in code transpiled to ES5

[ ] arrow functions
[ ] optional chaining

Done: https://github.com/playcanvas/engine/blob/master/.github/CONTRIBUTING.md#whitelisted-es6-features


Can't find gflags.lib when using CMake on installed version on Windows

(Disclaimer: I'm only a CMake journeyman so this could be a CMake issue. Please correct me if I'm wrong.)
TL;DR
gflags-config.cmake seems to export gflags_INCLUDE_DIR and gflags_LIBRARIES, but not something like gflags_LIBRARY_DIR. As a result, using the default instructions, linking fails with error LNK1181: cannot open input file 'gflags.lib'.
When built statically, the CMake config also fails to inform the generated project that it depends on Shlwapi.lib and linking fails with: "unresolved external symbol __imp_PathMatchSpecA ..."
By manually adding the library search path to the Visual Studio project and adding Shlwapi.lib as a dependency, my project builds fine.
Details
I cloned and built gflags on Windows and successfully built it with VS2013:

cd c:\tmp\gflags-2.1.2
mkdir build
cd build
cmake-gui ..
<open .sln and build with VS2013>

Building the INSTALL target on Windows puts everything under C:\Program Files\libraries\gflags, which has as children:

CMake
Include
Lib

In my own project, I followed the directions as on https://gflags.github.io/gflags/, except to find gflags.h, I had to add include_directories( ${gflags_INCLUDE_DIR} ) to tell the compiler where to find the header. gflags_INCLUDE_DIR resolves to C:\Program Files\libraries\gflags\Include and gflags_LIBRARIES resolves to gflags.lib. However, the compiler can't find gflags.lib because there isn't a gflags_LIBRARY_DIR or something to that effect which resolves to C:\Program Files\libraries\gflags\Lib.

Thanks for the detailed report.
A variable such as gflags_LIBRARY_DIR should not be required. This was common in the beginnings of CMake, but nowadays import targets with the full library path attached as property are preferred. This path is specified in the gflags-targets.cmake file. The gflags_LIBRARIES variable should simply contain the string gflags and is provided only to be "compatible" with other standard CMake Find modules. You could also just use gflags, which is the name of the respective CMake import target, not a file name such as gflags.lib. Alternatively, you can use one of the specific exported targets found in gflags-targets.cmake in the target_link_libraries command. Moreover, also the gflags_INCLUDE_DIR should not have to be specified explicitly because the gflags import target has this path as transitive include dependency property set.
You really should only need the CMake code found at https://gflags.github.io/gflags/#cmake.
Can you provide some more information to see why this doesn't seem to be sufficient in your case? For example:

CMake version?
Can you find the following in CMake/gflags-targets.cmake file and are the paths correct for your installation?

# Create imported target gflags_nothreads_static
add_library(gflags_nothreads_static STATIC IMPORTED)

set_target_properties(gflags_nothreads_static PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "/Users/as12312/Software/gflags/xcode/include"
)

# [...]

# Import target "gflags_nothreads_static" for configuration "Release"
set_property(TARGET gflags_nothreads_static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(gflags_nothreads_static PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
  IMPORTED_LOCATION_RELEASE "/Users/as12312/Software/gflags/xcode/lib/Release/libgflags_nothreads.a"
  )

Does it work if you use target_link_libraries(foo gflags_nothreads_static) instead of gflags_LIBRARIES or gflags import target, respectively? I am asking because in the gflags-config.cmake file, there is some CMake code to mimic a gflags ALIAS import target which is currently not possible with CMake yet. The actual import target names are gflags_static, gflags_shared, gflags_nothreads_static, and gflags_nothreads_shared. The gflags import target is intended to be an alias for either one of these as the "default" target to be used. If your project builds fine (i.e., the library file is found) using gflags_nothreads_static instead of gflags, the issue may be with this CMake code in gflags-config.cmake.

Before trying, please remove the include_directories(${gflags_INCLUDE_DIR}) again from your project. While this is not wrong, I would like it to be not needed. You really should be fine with just the target_link_libraries command.

When built statically, the CMake config also fails to inform the generated project that it depends on Shlwapi.lib and linking fails with: "unresolved external symbol __imp_PathMatchSpecA ..."

Thanks, I'll take note to add shlwapi.lib as link dependency of the static import targets.

BTW You could also use the example project to test the CMake configuration of your gflags installation. The CMakeLists.txt of this project basically comes down to only the following:
find_package(gflags REQUIRED)
# add_subdirectory(foo)
add_executable(foo foo.cc)
target_link_libraries(foo gflags)

Thanks for the super fast and detailed reply!
The example project: this builds out of the box and works great. However, it uses gflags as a Git submodule and is compiled in-tree. I'm trying to have my project use the one installed on the system, which I guess is pretty weird on Windows.
Re: cmake version: 3.5.1 (on Windows 8.1 x64).
In the course of going through your suggestions, I figured out what the problem was. I was mistaken when I said I cloned gflags from the source repo - instead, I got it by downloading the 2.1.2 release .zip. For some reason, doing a CMake build and install from the release results in the following directory tree:
Re: ${CMAKE_INSTALL_PREFIX}/CMake/gflags-targets.cmake
This file doesn't exist! The complete contents of my install directory:
CMAKE_INSTALL_PREFIX: C:\Program Files\gflags

CMake

gflags-config-version.cmake
gflags-config.cmake
gflags-export-release.cmake
gflags-export.cmake

Include

gflags

gflags.h
gflags_completions.h
gflags_declare.h
gflags_gflags.h

Lib

gflags.lib
gflags_nothreads.lib

Compare to a build from cloning the repo (differences in bold):

CMake

gflags-config-version.cmake
gflags-config.cmake
gflags-targets.cmake
gflags-targets-debug.cmake
gflags-targets-release.cmake

Include

gflags

gflags.h
gflags_completions.h
gflags_declare.h
gflags_gflags.h

Lib

gflags_nothreads_static.lib
gflags_static.lib

Any idea what's going on there?

More annoyingly, and this might be a CMake bug rather than how gflags is using it, when I run the INSTALL target, it adds the build directory to the registry and not where it gets installed.
I.e., even though CMAKE_INSTALL_PREFIX is set to the default value of C:\Program Files\gflags, it creates a registry key under HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\gflags: 78247c9cf0da8a791e30633c4a8845cf --> c:/tmp/gflags/bld.
(I cloned into c:\tmp\gflags. Then did mkdir bld; cd bld; cmake-gui ..).

Btw, you don't have to fix the dependency on shlwapi.lib, when building and installing out of the clone, the -targets.cmake file correctly adds it as a dependency.

The example project: this builds out of the box and works great. However, it uses gflags as a Git submodule and is compiled in-tree. I'm trying to have my project use the one installed on the system, which I guess is pretty weird on Windows.

Good! You can also test it by using your own installation of the gflags library. Therefore, simply do not initialize/update the Git submodule as explained in the README. As you have done so already, just run the following Git command before you re-execute CMake (possibly in new clean build directory):
git submodule deinit gflags

Issue 1

Re: ${CMAKE_INSTALL_PREFIX}/CMake/gflags-targets.cmake
This file doesn't exist!

Surprising that you don't get a CMake error then when gflags-config.cmake is included by the find_package(gflags) command. Because this file includes gflags-targets.cmake and this include is not optional. In any case, if this file is missing, it explains that things aren't working.
This is the line responsible for generating/installing this file.
The mistake is that I used FILE instead of RENAME and thus it uses the default name gflags-export.cmake instead of gflags-targets.cmake.

[ ] Fix install(EXPORT ...) command, specify file name with RENAME.

Issue 2
The library file names on Windows differ from Unix systems. On Unix, we can distinguish static from dynamic libraries based on the file name extension alone. On Windows, we need to have different names for the import library .lib to not confuse/overwrite it with a static library which has the same file name extension as an import library.
Are you sure you set BUILD_SHARED_LIBS to OFF (and BUILD_STATIC_LIBS to ON, but the default if both are OFF) in both cases? But then I would expect the corresponding .dll files in the Lib directory as well... not sure why the library file name is not as expected, i.e., gflags_static.lib and gflags_nothreads_static.lib. See here.

[ ] Check file names of installed static libraries (on Windows).

Issue 3

More annoyingly, and this might be a CMake bug rather than how gflags is using it, when I run the INSTALL target, it adds the build directory to the registry and not where it gets installed.

"The User Package Registry is stored in a per-user location. The export(PACKAGE) command may be used to register a project build tree in the user package registry. CMake currently provides no interface to add install trees to the user package registry. Installers must be manually taught to register their packages if desired." (https://cmake.org/Wiki/CMake/Tutorials/Package_Registry)
In my CMake BASIS project, I actually wrote a function to register the install tree instead. See here.

[ ] Update CMake package registry entry to change path during installation

Wow, you're quite the CMake master!
Re: gflags-example.
It works great once I change target_link_libraries(foo gflags) to target_link_libraries(foo gflags_static) or target_link_libraries(foo gflags_shared). Related directly to issue 2.
Re: Issue 2
I just checked, doing a full delete of the CMake cache and all generated projects between each run.
With the defaults (both BUILD_SHARED_LIBS = OFF and BUILD_STATIC_LIBS = OFF ), CMake builds and installs gflags_static.lib and gflags_nothreads_static.lib However, in gflags-targets.cmake, the corresponding targets are gflags_static, and gflags_nothreads_static.
The same happens if BUILD_SHARED_LIBS = OFF and BUILD_STATIC_LIBS = ON, as expected.
When BUILD_SHARED_LIBS = ON and BUILD_STATIC_LIBS = OFF, it builds and installs gflags.dll, gflags.lib, gflags_nothreads.dll, and gflags_nothreads.lib. The corresponding targets are gflags_shared, gflags_nothreads_shared`.
When BUILD_SHARED_LIBS = ON and BUILD_STATIC_LIBS = ON, it builds and installs gflags.dll, gflags.lib, gflags_nothreads.dll, and gflags_nothreads.lib. The corresponding targets are gflags_shared, gflags_nothreads_shared, gflags_static, and gflags_nothreads_static`.
In all cases, there is no target just called gflags.
Re: Issue 3
Awesome, thanks!

I just checked, doing a full delete of the CMake cache and all generated projects between each run.

Perfect, thanks for trying all combinations.
For the static builds, everything looks fine. However, I am curious why in case of BUILD_SHARED_LIBS and BUILD_STATIC_LIBS your installation seems to be missing the gflags_static.lib and gflags_nothreads_static.lib files?

In all cases, there is no target just called gflags.

CMake has so far no ability to define an imported ALIAS library target. This feature you can currently only use within your own project. Hence, I add the gflags target myself in the gflags-config.cmake file and copy the attributes from either one of the targets in gflags-targets.cmake as exported by CMake. The respective default target is chosen here and the gflags (i.e., @PACKAGE_NAME@) is added here.

Related even more obnoxious Windows issue: debug vs release C++ runtime libraries and _ITERATOR_DEBUG_LEVEL.
I'm working on my project which depends on gflags and during development, I need to run both the debug and release builds. If gflags is built in SHARED mode, everything works fine. However, if built with STATIC, then I have to link again a matching version of gflags since gflags depends on the C++ runtime library and (implicitly) sets the _ITERATOR_DEBUG_LEVEL value to 0 or 2. I.e., the DEBUG version of my app has to link to the DEBUG version of gflags and similarly for the RELEASE versions.
I'm not a CMake expert, but looking at the generated gflags-targets.cmake file, it looks like CMake is smart enough to point a target at different static libraries for different configurations.
# Import target "gflags_static" for configuration "Debug"
set_property(TARGET gflags_static APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
set_target_properties(gflags_static PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
  IMPORTED_LOCATION_DEBUG "C:/tmp/gflags/bld/lib/Debug/gflags_static.lib"
)

# Import target "gflags_static" for configuration "Release"
set_property(TARGET gflags_static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(gflags_static PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
  IMPORTED_LOCATION_RELEASE "C:/tmp/gflags/bld/lib/Release/gflags_static.lib"
)

The convention is to append a d at the end of the lib file, i.e., gflags_staticd.lib. And then we just have to point the DEBUG configuration of the target to that file. The magic CMake command seems to be:
set( CMAKE_DEBUG_POSTFIX d )

Oops, copy paste fail and there are too many libs, dlls, and targets :). I should have checked the preview first. You're right, with both checkboxes ON, it generates all 4 combinations, gflags_static, gflags_nothreads_static, gflags_shared, and gflags_nothreads_shared.

Yes, I am aware of the Debug library file prefix. However, I would not really expect a library with debug symbols to be part of a package installation. If you are a developer and need to debug your code, you should compile the gflags dependency yourself from sources anyway instead of using a binary package (e.g., Ubuntu/Debian package installation, Windows installer...). In this case, you should skip the install step in simply use the build tree of gflags directly as your gflags_DIR when configuring your dependent project.
P.S.: For other issues, I think it would be better if we would discuss separate issues in separate threads... makes tracking required changes easier :-).

set( CMAKE_DEBUG_POSTFIX d )

Regarding the debug postfix, if desired, this setting can be modified on the cmake command line using the -D option or in the CMake GUI.

Re: Issue 1: I couldn't find anything wrong with using install(EXPORT). To avoid issues relating to the renaming of the file, however, I introduced the internal variable EXPORT_NAME and avoid the use of the FILE option to rename the generated file upon installation. See #184.

Re: Issue 3: Added options REGISTER_BUILD_DIR and REGISTER_INSTALL_PREFIX where the latter is the default now when the gflags project is not a sub-project of another project. See #185.

The respective default target is chosen here and the gflags (i.e., @PACKAGE_NAME@) target is added here.

The imported gflags target was missing the IMPORTED_IMPLIB_<CONFIG> property, i.e., the path of the import library. Fixed by #186.


nuxt with idle-view ?

I try add idle-vue to my Nuxt app. But when I use idle-view to view. it is show error
Property or method "isIdle" is not defined on the instance but referenced during render
This my config:
plugins/idle-vue.js:
import IdleVue from 'idle-vue'
import Vue from 'vue'
import Vuex from 'vuex'
import IdleVueComponent from 'idle-vue/src/components/Idle.vue'

const store = new Vuex.Store({})

const eventsHub = new Vue()
Vue.component('idle-view', IdleVueComponent)
Vue.use(IdleVue, {
  eventEmitter: eventsHub,
  store,
  idleTime: 10000
})

nuxt.config.js
plugins: [
    {
      src: '~/plugins/firebase.js',
      ssr: false
    },
...
  ],

pages/index.vue
.form-group
  idle-view

I use nuxt ^2.6.2. Please help me. Thank you

Hey! I had the same struggle when I was trying to figure it out so hopefully this will get you up and running!
plugins/idle-vue.js:
import Vue from 'vue';
import Vuex from 'vuex';
import IdleVue from 'idle-vue';

const store = new Vuex.Store({
    state: {
        isIdle: false,
    }
});
const eventsHub = new Vue();

Vue.use(IdleVue, {
    eventEmitter: eventsHub,
    store,
    idleTime: 60000
    startAtIdle: false
  });

nuxt.config.js
plugins: [
    { src: "@/plugins/idle-vue", ssr: false },
    ...
]

You can then access isAppIdle through a computed value in your component:
computed: {
    isIdle() {
        return this.$store._vm.isAppIdle;
    },
    ...
}

However, for most cases you should be able to make use of the onIdle() and onActive() hooks provided. If that works for you, you can simplify your idle-vue.js file like so:
import Vue from 'vue';
import IdleVue from 'idle-vue';

const eventsHub = new Vue();

Vue.use(IdleVue, {
    eventEmitter: eventsHub,
    idleTime: 60000
    startAtIdle: false
  });

then in the component you wish to use the idle timer in, you can use the hooks as follows:
async onIdle() {
    this.doSomethingWhenUserIsIdle();
}
async onActive() {
    this.doSomethingWhenUserIsNoLongerIdle();
}

Hope this helps! :)

@aarontraynor Thank you so much, May be i forgot init isIdle for Vuex.  I'm using of the onIdle() and onActive() hooks provided. It work fine!


Support for MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ciphersuite

I am using the development branch and I have tried running dtls_server and dtls_client from programs/ssl examples folder. They are working fine, but the cipher suite selected by the server is  MBEDTLS_TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
I tried putting the MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in the client using mbedtls_ssl_conf_ciphersuites and I see in Wireshark that the ClientHello packet contains only this cipher suite (which is fine), but server is returning an alert.
Searching the config.h I haven't seen any reference to MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and also haven't see any in the code, excepting the cipher suites list from ssl_ciphersuites.c.
Is this cipher suite supported? I saw it listed in https://tls.mbed.org/supported-ssl-ciphersuites#ecdh_ecdsa. Am I missing some macros?

The ciphersuite is supported


Unintuitive Multiple Product Addition from Same Photo (Mobile App)

As reported by Alizarine to @raphodn

Description:

The current "add multiple items" option from a single product photo within the mobile app is not intuitive. Users may not understand its functionality or that it uses the same photo for multiple entries. This is due to the unclear labeling and placement of the "add an item" option at the bottom of the "add a price" menu.

Steps to Reproduce:

Open the mobile app and navigate to a specific product page.
Click on "add a price."
Observe the "add an item" option at the bottom of the menu.

Expected Result:

The "add multiple items" option should be clearly labeled and easily discoverable, possibly with a separate visual cue or placement within the main menu.

Actual Result:

The option is unclear and may confuse users who are trying to add multiple products from the same photo.

Suggested Solution:

Revise the presentation of the "add multiple items" option.
Consider collapsing it by default or moving it to the main menu.
Maintain an intuitive user flow: scan product → add price.

@teolemon The easiest solution would be to remove the "add product" button when coming from the product page.


Vulnerability in lodash up to v4.17.5

There's a vulnerability in lodash versions up to 4.17.5 (https://nvd.nist.gov/vuln/detail/CVE-2018-3721) which is a dependency of promise-core. Would it be possible to update the dependency to the latest version?

Thanks for reporting this @lucaswillering ! I just released<EMAIL_ADDRESS><EMAIL_ADDRESS>and<EMAIL_ADDRESS>which bump lodash to @4.17.11.
@andreyrd You are right. The versioning is designed that the user can deal with vulnerabilities directly. Of course, it is a good idea for a package maintainer to eventually enforce the upgrade.


The order of the related commands can change when rebuilding.

I've put a patch in review.
With this patch, the build seems deterministic. It is possible to diff two builds and see the differences. For example I use these commands in the www repo:
rm -rf _site_base; rake build; mv _site _site_base; (cd docs; git checkout test); rake build subs=no
diff -ur _site_base _site | diff-highlight | less

I don't think this ticket is relevant with the new site build.
rake build
mv _site ~/site-1
rake build
ksdiff _site ~/site-1

Shows no difference. (ksdiff is a third-party diff tool.) We can re-open if it seems there's really a problem here/still.


Ability to change the way array param are sendt

The request url when arrays are used is now formed like this ?var1[]=test,var1[]=test2
Is there a way to tell rapini to do it without the [] ?

Hi @thorep , yes there is, when you initialize you can pass a callback to format arrays. Example:
const { queries, mutations, requests, queryIds } = initialize(axios, {
  axios: {
    paramsSerializer: params => qs.stringify(params, { arrayFormat: 'repeat' })
  }
})

this example uses the qs library, but you can import any library you want serialize or even just write your own version. Hope that helps


V12 update

this still being worked on or no longer worked on?

Soon™
Been busy, if you're feeling adventurous you can remove the maximum from the module manifest. I did give delaying a quick test and nothing seemed broken, but wanted to test everything before I push an update

https://github.com/oWave/pf2e-flatcheck-helper/releases/tag/0.8.0


Added components for buyers dashboard

This is just the starting point for the buyer. more stuff can be added to meet MVP.

Good job adding this base for these features. Everything looks like good code structure


waveshare 1.44in lcd hat & ST7735r driver , display works but various issues

Hi, I bought one of these cheap displays ages ago to muck around with my pi zero, but they don't seem that widely supported so I am always having trouble getting it set up.
I found this driver by chance so decided to try it, because I saw it supports the ST7735r controller. This thing is actually an ST7735S, but I figured what the hell, and sure enough it worked. At first it was a bit garbled and the wrong resolution, but it was visible enough to make me keep going.
I tweaked the code to give it the correct resolution of 128x128 , and it seems to run stable enough with the spi clock divisor set at 12. It runs well enough, but the orientation is wrong (seems this can be the fault of the board layout, its mounted sideways to save space by the look of it), and also the left/right screen axis is flipped so everything reads backwards.
I managed to flip the horizontal axis. I have no idea how this is meant to be done properly, but I found a line that read 'madctl |= MADCTL_ROW_ADDRESS_ORDER_SWAP;', and commenting that out got me back to proper left and right orientation. Sorry if that seems like a kludge, but I am not really a programmer, my method is usually along the lines of 'hit it until it works', I'd appreciate some insight on how to properly do this.
I also don't know the best way to fix the rotation, it basically needs to be rotated 90 degrees, I know raspbian can do this, but I am typing this on my pi zero on a desktop monitor so I don't want to have to turn my head 90 degrees quite yet. I was also hoping there is a way to do this in the driver itself, because it would be nice to retain the ability to easily use the HDMI port, eg, to plug into a TV at someones house.
I'm really impressed by the performance, with fbtft+fbcp I only got terrible refresh rates and ended up sticking the thing in a drawer in disappointment, but with this I can play Doom with super smooth frame rates, and seemingly anti aliasing thrown in as a side effect of the screen scaling :) . It really is a nifty little gadget, a tiny joystick, 3 buttons and a screen on a board that perfectly matches the pi zero, so it's nice to finally get it working well, thanks for your hard work!

That's great info, I have managed to get it rotated correctly now, without having to mess with the hdmi output, which is great news. It seems that row/column exchange, combined with 180 degree rotation does the trick (in addition to the madctl |= MADCTL_ROW_ADDRESS_ORDER_SWAP; that was there already)
I guess this means that all the rotation is basically taken care of by the display controller itself?
Also, I have no deep understand of how these screens work, but is there enough here to add in support for this hat so that other people can use this easily?

To add support for an out of the box -DST7735S=1 path or a -DWAVESHARE_ST7735S_HAT=1 path, there are a few places where ST7735S vs ST7735R related changes will need to be done. These can be found by searching for ST7735R in the codebase. The items in particular for good implementation are to

audit through ST7735S spec sheet to verify that all the initialization commands that are shared from ST7735R at https://github.com/juj/fbcp-ili9341/blob/2e889803bfb8663eba08a92ffdd579241d9e1efc/st7735r.cpp#L28-L102 are actually valid ones also for ST7735S, so that it is not passing any silly ones there,
in particular, ensure that the refresh rate at https://github.com/juj/fbcp-ili9341/blob/2e889803bfb8663eba08a92ffdd579241d9e1efc/st7735r.cpp#L87-L88 is an appropriate one, or adapt it to compute a ST7735S specific rate,
add support for enabling/disabling DISPLAY_OUTPUT_LANDSCAPE in config.h (might not make sense for the hat, but for other ST7735Ses out there),
and, this is probably trickiest, find the "neutral" panel scan orientation to account for DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE at https://github.com/juj/fbcp-ili9341/blob/2e889803bfb8663eba08a92ffdd579241d9e1efc/config.h#L180-L192 so that when DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE is enabled, the driver should let the panel scan in its neutral orientation (madctl = 0), for least amount of tearing and latency, and when DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE is not defined, update in madctl controlled way, like was already done here.

These are a bit tricky to do without a board, the semantics of these are laid out somewhat delicately.
Something to do to help is to run git diff in your working tree to post the changes you needed, along with the CMake command line you use to configure, and post the results here. That might help someone stumble to the instructions and is a good starting point.

Got access to a WaveShare 128x128 1.44" HAT display, and added support to it today in https://github.com/juj/fbcp-ili9341/commit/9170e872b67473f04719bbff3f8e5f35ac571f5f . It is enabled via CMake directive -DWAVESHARE_ST7735S_HAT=ON.

Oh wow, that is a result way quicker than I was expecting! I was almost about to give up and suggest I could send you mine, since I have no idea what I am doing...  Or at least, I trust you more than I trust me :O) Thank you very much for this though.


fix(REACH-644): Update close button CSS

Update CSS to avoid possible conflicts with other general CSS styles of a .
There was a conflict with some WP themes:

before
after

[BOT] Preview available with hash 6ae9933df7f1aafd66be0b86f7c2fda2038610b1 here.

:tada: This PR is included in version @typeform/embed-v2.15.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix fuselibs after DateTime changes in Uno

DO NOT MERGE: TEMP STUFF FILES FOR TESTING
Fixes fuselibs impls after https://github.com/fusetools/uno/pull/1263. Only internal changes were made; no public interfaces were harmed during the making of this PR. :)
This PR contains:

[-] Changelog
[-] Documentation
[-] Tests

👍


Move FirebaseCrashlyticsReporter and CrashlyticsReporter, etc into a AlphaWalletCrashReporter pod

Oh. Let me take a quick look. Self-assigning in case you are checking

Ah, I see, there are cyclic references between AlphaWalletFoundation and crashlytics code

Oh and silly me. It's already in AlphaWalletFoundation. Ok, let's leave it for now.


Cannot create ConcatV2. Missing or invalid attribute axis

I get the following error when converting the graph containing a concat node with axis int_value greater than 2.
fatal error: Cannot create ConcatV2. Missing or invalid attribute axis.: file <omited>/Pods/MetalBender/Sources/Adapters/Tensorflow/TFConverter+Mappers.swift, line 162

And the node in question from the .pbtxt:
node {
  name: "fire2/concat/concat/axis"
  op: "Const"
  attr {
    key: "dtype"
    value {
      type: DT_INT32
    }
  }
  attr {
    key: "value"
    value {
      tensor {
        dtype: DT_INT32
        tensor_shape {
        }
        int_val: 3
      }
    }
  }
}

And if I follow correctly the code it executes the LayerConverter+Mappers.swift calls the LayerSize.fromTf with the value 3. which in return is as follow:
    static func fromTF(index: Int) -> LayerSizeAxis? {
        switch index {
        case 0:
            return .w
        case 1:
            return .h
        case 2:
            return .f
        default:
            return nil
        }
    }
}

This evaluates as nil and throws an error.
Is there an error with the graph I'm trying to convert or is a bug in the Bender that it does not support concat indexes beyond axis=2 on a concat layer?
Environment:

Xcode 8.3.3,
iOS: 10.3.2,
SDK version: 10.3

Bender, as it's based on MPSImage, it doesn't support tensors with more than 3 dimensions. What is the shape of the input tensor of the concat?

Ah ok good to know! I'm totally new to the iOS development and tipping my toes around to see what fits my project and Bender seems to be a nice API for the iOS ML projects.
Are there any "hacks" to bypass the limitation of three dimensions?
The tensors to be concatenated have shapes like [64,63,128,64] and [128,63,128,64]. This is an inception fire module I'm trying to implement. (An example is of the concat operation )


Combining TIOBE and IEEE Spectrum breaks the top slot

Thanks @sean-parent :pray: It was a blank line at EOF problem. I added a check to make sure it won't happen in the future : ) https://github.com/codereport/plr/commit/f10e1da7d58c85b39362df95d4dc6225f0749f17


strap pf rules incompatible with xhyve networking

xhyve is an OSX virtualization solution that's lighter weight than QEMU and VirtualBox. It's a promising option for running containers on OSX.
Strap's pf rules for forwarding HTTP/S ports cause outbound connections from VMs to ports 80 and 443 to be misrouted.
Here's the effect from inside the VM:
$ curl -s github.com | head
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }

Running sudo pfctl -F all -a dev.strap to unload the rules for the dev.strap anchor fixes the problem (after stopping and starting the VM):
$ curl -sv github.com | head
* Rebuilt URL to: github.com/
*   Trying <IP_ADDRESS>...
* Connected to github.com (<IP_ADDRESS>) port 80 (#0)
> GET / HTTP/1.1
> Host: github.com
> User-Agent: curl/7.47.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://github.com/
< Connection: close
<
* Closing connection 0

Strap's pf rules are:
rdr pass inet proto tcp from any to any port 80 -> <IP_ADDRESS> port 8080
rdr pass inet proto tcp from any to any port 443 -> <IP_ADDRESS> port 8443

I'm not sure what needs to change, but my guess is any to any is too broad.

I'm not sure what needs to change, but my guess is any to any is too broad.

I'm definitely up for including a fix here but as I don't use xhyve currently I think I'll need to request a pull request for a fix here. Sorry and thanks for the report.


Add fancy_layout option to HoloViews pane

The current HoloViews pane generates a simple layout of the plot and the set of widgets generated from that plot. This makes it easy to compose these two components in different ways but it doesn't match the look that the old-style HoloViews widgets use. Since we want to swap out the widgets in HoloViews with as little disruption as possible this PR adds a fancy_layout option which tries to match the look and feel of the original widget implementation.
As a simple example here is the output of a HoloMap with this option enabled:

I se this is merged already, but I'm wondering whether fancy is the right term for this arrangement.  Fancy makes it sound like it's better than the default, but really it's just different, as far as I can see.  Could we use a more neutral word here, like shaded_widgets?

Happy to change it, about to open another PR to improve the scrubber layout anyway, but -1 on shaded. Open to other suggestions.

The differences are:

The widgets are inside a widget box (which is shaded and gray)
The plot and widgets are horizontally centered and the margins are responsive
The widget box is vertically centered

Also for context, the "fancy" bit is borrowed from matplotlib's fancybox option on legends: https://matplotlib.org/gallery/recipes/transparent_legends.html

I don't think it shares much in common with the mpl fancybox option, which isn't grey or offset like that. Maybe center_shaded?  I'm just looking for something more literal and with no valence.  But it's only a slight preference, so if there's no literal name you are happy with, then I guess just keep it fancy.

Cc: @jsignell @jlstevens @jonmmease Any opinions?

What about original_layout or classic_layout

I like classic_layout.

classic_layout is fine if it's not something we plan to support forever or expect new users to consider using.

classic_layout is fine if it's not something we plan to support forever or expect new users to consider using.

We do plan to support it forever, it's the default layout HoloViews will use to render its widgets. Panel users should generally use the default layout so they can compose it themselves more easily.

I don't have strong feeling on the name itself, but should we consider this to be an enumeration rather than a boolean?  Something like layout_style='holoviews', and then leave open the possibility of other styles in the future.

Something like layout_style='holoviews', and then leave open the possibility of other styles in the future.

Not a bad idea either.

Currently the options would be 'simple' and 'classic' or 'holoviews'.

As a disclaimer, I haven't looked at it closely enough to have an opinion on whether we would want to have more options like this in the future.  I just know I've often come to regret boolean arguments 🙂

As a disclaimer, I haven't looked at it closely enough to have an opinion on whether we would want to have more options like this in the future

I would certainly have to refactor the code and come up with some better representation to express custom layouts because the code is already getting unwieldy with two options but I think more flexibility would be a good thing. People certainly have asked for more flexibility in HoloViews and while they can already achieve that if they use Panel directly and lay things out themselves I don't think it would hurt to include a few more canned layouts they can pick from.

If no one objects I'm going with:
layout_style = param.ObjectSelector(default='simple', objects=['simple', 'classic'], doc="""
    The default layout of the plot and widgets, by default it uses the 'simple' layout to make
    it easy to compose the plot and the widgets manually.""")

The last suggestion above looks good to me in terms of a layout_style parameter. I think 'simple' is clear enough as a name (the current panel behavior afaik) but 'classic' isn't too informative as to what that really means.
I am not a fan of 'holoviews' as a value and 'adjoint' is probably confusing given holoviews uses that word as well. I'm wouldn't let 'classic' block this PR but I would like to try and think of something else if possible (tricky!).

Could call it centered I guess but there could be a number of centered arrangements. One problem is that it also interacts with the widget_type parameter. Maybe we could add center_right, center_left, center_bottom, center_top, left right, bottom and top options instead. HoloViews would use center_right for regular widget and center_bottom for the scrubber.

Those options make sense to me and generalize panel nicely. Of course it is also more work to do but this would be my preferred approach...

I was reading the recent discussion starting from the top and independently thought of center_right before reading @philippjfr's comment, so I vote for that -- that way people can declare an appropriate default mapping to a layout that they prefer in general, and of course then they can always repack things manually using Panel if they wish.


Issue with Windows Hello PIN login after change password from Domain Controller and requires two attempts to login with Updated pasword

Issue after change password from Domain Controller
After Changing the password from Domain Controller/ Server. The it requires twice online login with the new updated password for the Subsequent PIN  functionality to work.
Steps to replicate the issue.
Prerequisite:
Windows Server 2019 Enterprise
Windows 10 x64 bit-1909 Enterprise
Steps:
1> Change password for a domain user XX In server
2>Client is connected to domain and enabled for Windows Hello using PIN
3>Login as user XX with the new updated password, Login is successful
4>Now again login with PIN
Error message is show as "You must sign in to this device …."
Inference:
Even after logged in with New password, Windows will not allow subsequent PIN login.
Workaround:
Users again need to login twice with the updated password to use the functionality of PIN

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ba665984-14d2-e5f1-a1a4-e8c28b61571d
Version Independent ID: 4918b293-ce78-154b-a3ee-515557367d8c
Content: Windows Hello and password changes (Windows 10) - Microsoft 365 Security
Content Source: windows/security/identity-protection/hello-for-business/hello-and-password-changes.md
Product: w10
Technology: windows
GitHub Login: @mapalko
Microsoft Alias: mapalko

We need to fix this issue as Windows Hello PIN is also used by many customers and it needs two attempts to login with the updated password and until then PIN functionality cannot be used.

@dockervenkat . Will you try to change the PIN  policy settings in GPO, see it works

@dockervenkat documentation feedback shouldn't be used for opening code issues or bugs. Please follow up through feedback hub and collect a repro of the issue that you are experiencing.


feat: setup draggable document

Add draggable document replicating https://tradetrust.io/

document will be a tradetrust demo file
when dragged, we will see a faded image of the icon with the cursor
will have animation of resizing up and down
when clicked, it will allow the user to download the file

check out https://github.com/Open-Attestation/verify.gov.sg/pull/3 instead


[5.4] Database migrations in fresh install do not work

Laravel Version: 5.4.0
PHP Version: 5.6.14
Database Driver & Version: MariaDB (MySQL) 10.1.8

Description:
I freshly installed Laravel 5.4 and ran the commands to generate the sessions, failed_jobs, notifications tables in the database.
The following migrations all fail to run due to the recent change from UTF8 charsetto utf8mb4. This is due to the column length on these migrations not being defined by default in a new install.

create_users
password_resets
notifications
sessions

The string call in these migrations doesn't specify a length, so it uses Builder::$defaultStringLength which is currently still set to 255 causing this error and making migrations not migratable from the start without changing this value via defaultStringLength() method on the Builder class.
The following errors are produced when running migrations:
[Illuminate\Database\QueryException]
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes (SQL: alter table `users` add unique `users_email_unique`(`email`))
[PDOException]
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes

Steps To Reproduce:

Install laravel 5.4
Set up configuration for database connection (no changes needed otherwise)
Try to migrate
See the failure

Thank you.

Can you add another line in config/database.php file:
'engine' => 'InnoDB ROW_FORMAT=DYNAMIC',
And try again.

Apologies if I was not clear - this isn't something I need a solution to for myself, but something that is broken within the framework without first changing something.
If the above fix is what is recommended then it should be in the configuration by default for new installs. However it would make more sense for something that uses utf8mb4 by default to change the default string length to 191 instead of the 255 it currently has.

You did not provide the error message. So, my guess was based on my experience with similar case.
If this solution worked then there are two things to consider:

Laravel 5.4 works out of box
Laravel 5.4 does not work out of box in specific conditions, i.e., when used with older MySQL/MariaDB versions and configurations. In those conditions you should specify this extra line.

And yes - it probably should be mentioned in documentation.
But before that we should find out if this is the case.

Add this to your AppServiceProvider if you have MySQL lower than 5.7.7:
use Illuminate\Support\Facades\Schema;

public function boot()
{
    Schema::defaultStringLength(191);
}

Laravel supports officially only Mysql 5.7, it should work with < 5.7 anyways...
On 5.7 it is working out of the box because on 5.7 the innodb_large_prefix is enabled by default, if you are using MySQL 5.5 or 5.6 you should manually enable it since it is disabled by default... I agree that we could add a warning on the docs, but we don't need to change the 255 to 191 since that's an issue related to older versions of the RDBMS...

Thank you all, I see the version of MariaDB I am on is slightly behind the one where the defaults have changed (10.2.2). My file format for databases is still on Antelope so I had to adjust it to allow Barracuda, and turn on innodb_large_prefix. Apologies for the misunderstanding :)