text:
upgrade to netty 4.x

Update code base to consume the proper netty 4.0.x classes. This upgrades blueflood code base to use netty 4.0.40.FINAL, which is the latest 4.0.x netty up to date. There is also netty 4.1.4.FINAL but since datastax driver 3.0.0 is pulling in netty 4.0.x, I figure it's safer to use netty 4.0.x.
The main goal of this upgrade is so that datastax can use the Native epoll transport, which is supposed to perform better.

Coverage increased (+0.2%) to 75.982% when pulling 1077ca509e20812b92c431842060f1ade668b000 on shintasmith:netty into 91d390b6504bfaf538909972e2610f4b930f9451 on rackerlabs:master.

Coverage increased (+0.2%) to 75.982% when pulling fe505853a8f2a88edeeec33aa749fee4fde2fffb on shintasmith:netty into 91d390b6504bfaf538909972e2610f4b930f9451 on rackerlabs:master.

Coverage increased (+0.3%) to 76.059% when pulling ba8209b7e842a0493482b46656fa1897e444a211 on shintasmith:netty into 91d390b6504bfaf538909972e2610f4b930f9451 on rackerlabs:master.

Whats the main reason to switch from HttpRequest to FullHttpRequest?

Coverage increased (+0.3%) to 76.086% when pulling 79c5c4181b991df99a218aad356be4fbc2825203 on shintasmith:netty into 91d390b6504bfaf538909972e2610f4b930f9451 on rackerlabs:master.

@ChandraAddala I moved the max content length in HttpConfig

Looks good.

Coverage increased (+0.2%) to 76.03% when pulling 7bb13af04afc2540e72129ceaa41e62c6be727cd on shintasmith:netty into 91d390b6504bfaf538909972e2610f4b930f9451 on rackerlabs:master.

authors: ChandraAddala coveralls shintasmith

repo: rackerlabs/blueflood


text:
🛑 barbican-api is down

In 3b2036d, barbican-api (https://barbican.api.sjc3.rackspacecloud.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: barbican-api is back up in 2bdd4da after 17 minutes.

source: gharchive/issue

repo: rackerlabs/rs-flex-uptime

license: MIT

license_type: permissive

license_source: github-api


text:
AIFF Fork

Hi,
I see you use same function name for your AIFF fork, https://github.com/rackfx/Node-AIFF-File-Info, does this means that this Node-WAV-File-Info also works with .aiff ? What if I want to have wav & aiff analyses ? should I install both package ? Can they operate without conflict ?
Thanks for the precisions :)

Yes, you can use them together as separate Node modules, with separate namespaces. You can just determine which is needed by the MIME type or extension of the file and use the appropriate validator (WAV or AIFF).
Thanks!

authors: X-Raym drj-io

repo: rackfx/Node-WAV-File-Info

license: mit

license_source: bigquery


text:
Relay and Redux

So now that Relay and GraphQL are out in the open, we should start a conversation about how this relates to Redux. Anyone have thoughts on Relay will effect both the core Redux library, and what ecosystem tools will need to be built out to accommodate it?

It seems like Redux and Relay are trying to accomplish the same thing, managing your component data. In fact, Redux's @connect decorator seems very similar to Relay's containers. You're basically attaching a data source to your component. In Redux that data source is your reducers and in Relay it's your server and probably a local cache.

I think they address two very different parts of "managing your component data".
Redux is simply about transforming your local state via actions and reducers.
Relay is about creating declarative dependency specifications that a hierarchy of components can collect and combine automatically to fetch data from a server without overfetching or underfetching.
The traditional problem that Relay was trying to solve was that a component had to know what data its children required, then had to get it from the local state (assuming it's already been retrieved from the server) and then pass it down to its children via props.  If a child component's data needs changed, you needed to change the parent object and possibly the parent's parent, depending on how you'd organized things.
With Relay, the children declare the dependencies and the parent collects and combines them automatically without needing to be aware of what those dependencies are.  Then it asks the server for exactly the data it needs.
There's a topic in the reselect project discussing automatic generation of selector dependencies.  If you did that, you could probably leverage the data to do something like Relay with Redux, or perhaps feed that data directly to Relay (haven't looked at the Relay code yet, but will soon).

Right but Relay has mutations which is also a way of transforming your state. I don't think it's a good idea to have two different systems managing your state. For example, with a todo app, you would have to write an addTodo action for Redux and an addTodo mutation for Relay. This doesn't seem like a good design to me.
I could see Redux being used as a component state manager and a cache layer for Relay. In the blog post they mention investigating offline support in the future for Relay and I wonder if Redux could plug into that and enable time travel with Relay.

Actually, we might be part of the way there already. Relay already allows custom network layers:
http://facebook.github.io/relay/docs/guides-network-layer.html#content
If there was a way to handle GraphQL client-side then we could implement a Redux network layer that would intercept those requests and work its magic.

Injecting Redux into the Flux Store part of Relay/GraphQL feels directionally right. There are a lot of advantages to using Redux with Relay I can think of:

Redux devtools work, so you could step back in time through your GraphQL mutations
Fewer store/dispatcher/actions systems to learn
Hot reloading
Can use the Redux store outside of Relay code e.g. for storing client state that you don't want to sync to the server or spend time defining a GraphQL schema for
The Redux community has put a lot of thought into making Redux extensible -- this would test to see if Redux is extensible enough to support (hypothetical) redux-relay middleware
Relay/GraphQL applications could benefit from Redux middleware

Pretty exciting stuff after typing it out...
cc @yungsters @josephsavona

@CooCooCaCha I think integrating at the network layer might be too late into the pipeline.
We are in the early phases (mainly because of the focus on getting Relay open sourced) of exploring ways to expose local data via GraphQL queries and fields. We are definitely inspired by the work on Redux and would like to see how we could fulfill queries for local state from in-memory stores or maybe even native device data sources.

One nice thing that Redux support really seamlessly is universal apps, so making this conversion work would make working with universal Relay apps much easier.  I view Relay and Redux as two halves of the problem:

Redux solves the problem of managing local state and mutations (including managing caches of data from the server).  However, Redux makes querying server side data relatively imperative (i.e. send the 'GET_DATA' action and wait for the corresponding 'GOT_DATA' action to update the store).
Relay solves the problem of declaratively managing the active queries you have for server data, fetching that data and then keeping the client's cache up to date in the face of mutations.

There are three really difficult and valuable things that Relay accomplishes:

Diff the queries currently executed with the new queries from recently added components in order to query only new data from the server.
Optimistically apply updates on the client
Model both complex data structures (graph data is a hugely powerful model) and complex queries (which reduces need for round trips).

I can see two barriers to integrating relay & redux:

Redux requires all state to be in a single immutable location.  Relay appears to store its state in RelayStoreData but in a number of mutable data structures within that.  The first step I think would be to pull that out so that this state object could be managed by Redux.
Redux uses this.context to seamlessly support universal/isomorphic applications.  The same approach could work well in Relay, but it doesn't look like it's currently supported.  It looks like components like RelayRootContainer call into the singleton RelayStore and RelayStoreData. getDefaultInstance.  I don't know how much work it would be to pull the relay store from this.context or similar.

Note that I do not think that the valuable part of Relay is integration into React.  What I wonder is, could way separate out the three highly valuable parts of Relay, and make them function on top of an immutable data store.  If we could do that, then integration into Redux would be very simple.  We could then experiment with alternative ways of structuring the React portion of the application.

The same approach could work well in Relay, but it doesn't look like it's currently supported.

This is the (currently unrealized) intent for the RelayStoreData internal module. In theory, we could pass this down through your app via the RootContainer.

That would be an excellent first step towards redux integration.

Hi.. didn't really look into it, but found this repo for an example https://github.com/barbuza/react-redux-relay  any progress on relay support

Also relevant: https://github.com/gyzerok/adrenaline

Am Freitag, 18. September 2015 schrieb Dan Abramov :

Also relevant: https://github.com/gyzerok/adrenaline
—
Reply to this email directly or view it on GitHub
https://github.com/rackt/redux/issues/464#issuecomment-141569810.

@all I highly need any feedback about https://github.com/gyzerok/adrenaline. I'm stuck a little bit now about how to move on.

@gyzerok could you amend your readme with a quick overview of your approach? How are you matching stateless Redux with stateful Relay?

@wmertens It does it by not using relay at all.  It uses the lower level protocol instead.  Adrenaline is in fact a GraphQL client, rather than a relay implementation.  It's great that people are starting to experiment with alternative ways of building relay-like functionality :+1:

I agree that this is a very neat approach. The approach here should be similar to how Flux inspired many libraries (including Redux!). From what I understand, very few people use the Flux dispatcher directly, which might be overkill for many problems. I see the Relay ecosystem also turning up the same way. There could be a "redux-relay" project (Adrenaline?) that integrates GraphQL into the workflow in the most appropriate way. I wish one could directly use parts of Relay, instead of writing everything the whole thing from scratch. :100:

@wmertens I do not quite understand you. Redux is statefull to, but state live somewhere inside Redux. In Relay state also live somewhere inside. An in Adrenaline state live somewhere inside. Mb I do not get your question right?

@bbirand A lot of relay's infrastructure is reusable without starting from scratch, it's just mostly undocumented.  For example, any efficient implementation of relay-like principles will need to use something like the babel-relay-plugin which is totally reusable for non-relay GraphQL implementations.

@ForbesLindesay Do you understand principles behind babel-relay-plugin? If so, can you explain it a little more?

What adrenaline does currently is run a single query on the server side, put it's result in a cache, and then re-run the query against that cache with an identical GraphQL schema but where the resolve implementations read from cache (approximately, correct me if I've massively understood).  This makes it very difficult when the query changes to do anything other than re-query anything.
Part of the problem with this, is that due to aliasing and arguments, it's impossible to draw a proper correlation between the responses from graphql and the underlying data that should be cached.  For example, consider the following from the docs:
query {
  user(id: 4) {
    id
    name
    smallPic: profilePic(size: 64)
    bigPic: profilePic(size: 1024)
  }
}

You get a response like:
{
  "user": {
    "id": 4,
    "name": "Mark Zuckerberg",
    "smallPic": "https://cdn.site.io/pic-4-64.jpg",
    "bigPic": "https://cdn.site.io/pic-4-1024.jpg"
  }
}

What you probably end up with is a cache which looks like:
{
  "user": {
    "4": {
      "id": 4,
      "name": "Mark Zuckerberg",
      "smallPic": "https://cdn.site.io/pic-4-64.jpg",
      "bigPic": "https://cdn.site.io/pic-4-1024.jpg"
    }
  }
}

Which is enough to reconstruct the answer to that specific query, but only if your client knows that profilePic(size: 64) will be stored as smallPic in the cache.  What you want your cache to look like is something more like:
{
  "root": {
    "user(id:4)": ReferenceTo("User", 4)
  },
  "User": {
    "4": {
      "id": 4,
      "name": "Mark Zuckerberg",
      "profilePic(size:64)": "https://cdn.site.io/pic-4-64.jpg",
      "profilePic(size:1024)": "https://cdn.site.io/pic-4-1024.jpg"
    }
  }
}

The point I'm trying to make here is that the structure of your cache depends on the query I ran, whereas my cache's struture depends purely on the structure of the underlying data model.  It's possible to run a query against my cache without any knowledge of which queries have already been run, and get correct results.  This means that you wouldn't need users to implement client side querying functionality.
To create a query that depends on the structure of the underlying data, rather than on the query that was run, you need to be able to read in and restructure the query, then when you want to run the query against the local cache, you need to be able to understand the structure of the query again.
What the babel plugin does is something like:
var q = Relay.QL`
query {
  user(id: 4) {
    id
    name
    smallPic: profilePic(size: 64)
    bigPic: profilePic(size: 1024)
  }
}
`;

into:
var q = (function () {
  var GraphQL = Relay.QL.__GraphQL;
  return new GraphQL.Query("user", new GraphQL.CallValue(4), [new GraphQL.Field("id", null, null, null, null, null, {
    parentType: "UserType"
  }), new GraphQL.Field("name", null, null, null, null, null, {
    parentType: "UserType"
  }), new GraphQL.Field("profilePic", null, null, [new GraphQL.Callv("size", new GraphQL.CallValue(64))], "smallPic", null, {
    parentType: "UserType"
  }), new GraphQL.Field("profilePic", null, null, [new GraphQL.Callv("size", new GraphQL.CallValue(1024))], "bigPic", null, {
    parentType: "UserType"
  })], null, {
    rootArg: "id"
  }, "Unknown");
})();

Which evaluates to an object like:
{ fields:
   [ { fields: [],
       fragments: [],
       children: [],
       kind: 'Field',
       fieldName: 'id',
       calls: [],
       alias: null,
       condition: null,
       __metadata__: { parentType: 'UserType' },
       metadata:
        { edgesID: undefined,
          inferredRootCallName: undefined,
          inferredPrimaryKey: undefined,
          isConnection: false,
          isFindable: false,
          isGenerated: false,
          isPlural: false,
          isRequisite: false,
          isUnionOrInterface: false,
          parentType: 'UserType' } },
     { fields: [],
       fragments: [],
       children: [],
       kind: 'Field',
       fieldName: 'name',
       calls: [],
       alias: null,
       condition: null,
       __metadata__: { parentType: 'UserType' },
       metadata:
        { edgesID: undefined,
          inferredRootCallName: undefined,
          inferredPrimaryKey: undefined,
          isConnection: false,
          isFindable: false,
          isGenerated: false,
          isPlural: false,
          isRequisite: false,
          isUnionOrInterface: false,
          parentType: 'UserType' } },
     { fields: [],
       fragments: [],
       children: [],
       kind: 'Field',
       fieldName: 'profilePic',
       calls:
        [ { kind: 'Call',
            value: { kind: 'CallValue', callValue: 64 },
            name: 'size',
            metadata: {} } ],
       alias: 'smallPic',
       condition: null,
       __metadata__: { parentType: 'UserType' },
       metadata:
        { edgesID: undefined,
          inferredRootCallName: undefined,
          inferredPrimaryKey: undefined,
          isConnection: false,
          isFindable: false,
          isGenerated: false,
          isPlural: false,
          isRequisite: false,
          isUnionOrInterface: false,
          parentType: 'UserType' } },
     { fields: [],
       fragments: [],
       children: [],
       kind: 'Field',
       fieldName: 'profilePic',
       calls:
        [ { kind: 'Call',
            value: { kind: 'CallValue', callValue: 1024 },
            name: 'size',
            metadata: {} } ],
       alias: 'bigPic',
       condition: null,
       __metadata__: { parentType: 'UserType' },
       metadata:
        { edgesID: undefined,
          inferredRootCallName: undefined,
          inferredPrimaryKey: undefined,
          isConnection: false,
          isFindable: false,
          isGenerated: false,
          isPlural: false,
          isRequisite: false,
          isUnionOrInterface: false,
          parentType: 'UserType' } } ],
  fragments: [],
  children:
   [ { fields: [],
       fragments: [],
       children: [],
       kind: 'Field',
       fieldName: 'id',
       calls: [],
       alias: null,
       condition: null,
       __metadata__: { parentType: 'UserType' },
       metadata:
        { edgesID: undefined,
          inferredRootCallName: undefined,
          inferredPrimaryKey: undefined,
          isConnection: false,
          isFindable: false,
          isGenerated: false,
          isPlural: false,
          isRequisite: false,
          isUnionOrInterface: false,
          parentType: 'UserType' } },
     { fields: [],
       fragments: [],
       children: [],
       kind: 'Field',
       fieldName: 'name',
       calls: [],
       alias: null,
       condition: null,
       __metadata__: { parentType: 'UserType' },
       metadata:
        { edgesID: undefined,
          inferredRootCallName: undefined,
          inferredPrimaryKey: undefined,
          isConnection: false,
          isFindable: false,
          isGenerated: false,
          isPlural: false,
          isRequisite: false,
          isUnionOrInterface: false,
          parentType: 'UserType' } },
     { fields: [],
       fragments: [],
       children: [],
       kind: 'Field',
       fieldName: 'profilePic',
       calls:
        [ { kind: 'Call',
            value: { kind: 'CallValue', callValue: 64 },
            name: 'size',
            metadata: {} } ],
       alias: 'smallPic',
       condition: null,
       __metadata__: { parentType: 'UserType' },
       metadata:
        { edgesID: undefined,
          inferredRootCallName: undefined,
          inferredPrimaryKey: undefined,
          isConnection: false,
          isFindable: false,
          isGenerated: false,
          isPlural: false,
          isRequisite: false,
          isUnionOrInterface: false,
          parentType: 'UserType' } },
     { fields: [],
       fragments: [],
       children: [],
       kind: 'Field',
       fieldName: 'profilePic',
       calls:
        [ { kind: 'Call',
            value: { kind: 'CallValue', callValue: 1024 },
            name: 'size',
            metadata: {} } ],
       alias: 'bigPic',
       condition: null,
       __metadata__: { parentType: 'UserType' },
       metadata:
        { edgesID: undefined,
          inferredRootCallName: undefined,
          inferredPrimaryKey: undefined,
          isConnection: false,
          isFindable: false,
          isGenerated: false,
          isPlural: false,
          isRequisite: false,
          isUnionOrInterface: false,
          parentType: 'UserType' } } ],
  __metadata__: { rootArg: 'id' },
  kind: 'Query',
  metadata: { rootArg: 'id' },
  name: 'Unknown',
  fieldName: 'user',
  isDeferred: false,
  calls:
   [ { kind: 'Call',
       value: { kind: 'CallValue', callValue: 4 },
       name: 'user',
       metadata: {} } ] }

In there is everything you need to figure out what data is being requested, and where you should store it in the cache.  You can build a query, without taking any notice of the "alias" values, so that what you store in your cache is properly normalised, then you can apply the aliases when you read the data out of your cache.  I believe this is what relay is doing (and how it's able to query just the data that it doesn't already have).

@ForbesLindesay impressive research into Relay internals!

In [the raw query object] is everything you need to figure out what data is being requested, and where you should store it in the cache...

It turns out that the raw query descriptor - that output of the babel-relay-plugin - actually isn't sufficient for processing queries. Consider photo(size: $size) - the query description for this will have a placeholder for the size. But what value do we use for $size? Rather than directly operating on the query descriptor, Relay instead uses an abstraction that allows it to process queries and values in parallel. We'll be talking more about how Relay works in some upcoming blog posts, and we're always happy to answer questions at facebook/relay.

@acdlite did a great job on https://github.com/acdlite/relay-sink

@vicentedealencar that looks neat, but I don't think it has anything to do with redux.  It still relies on having the entire relay infrastructure in your code and having all the relay state stored in the normal relay store, so it won't let us move that state into redux.

Can somebody clarify some specific, concrete goals for Relay/Redux coordination/collaboration? Is the goal better debugging? To implement a GraphQL client and store data in Redux (which effectively means reimplementing all of Relay)? Or is to use Relay to fetch some data that is also needed for Flux stores (for example as default values for things, etc)? Please feel free to file issues over at facebook/relay if there are specific use-cases that we could help support.

@josephsavona, I for one use Redux outside of a React environment and since GraphQL is also React agnostic (and I hope it stays that way) I'd be very keen for at least some good examples/patterns for Redux as the storage engine in just vanilla Redux and GraphQL!  ;)

I'll close because there is nothing particularly actionable for Redux here.
Feel free to continue the discussion!

Good thoughts from @fdecampredon: "the only point is to control relay variables from redux state"
https://gist.github.com/fdecampredon/f337605e393a5b032b85
Also he ask about any feedback.

Very interesting visual overview of Relay: http://sgwilym.github.io/relay-visual-learners/
I wonder where Redux can fit into this.
I also wonder how Relay and Falcor compare. Could it be that they are the exact same concepts except that Relay also has the babel plugin for defining the required data?
There is https://github.com/ekosz/redux-falcor which is a straight-forward bridge allowing requesting data via actions and then getting it in the Redux store. However, that still leaves the problem of requesting the data in the first place, which could be done with https://github.com/ericclemmons/react-resolver
If Relay and Falcor are the same, the same approach could work with relay.

Relay doesn't need Redux since it has its own state manager. There is no
sense in combining them. We just may use the soul of Relay, its core idea
with Redux.

I really like managing my app state with Redux, and that's not something relay can do.
Can they be used concurrently? Relay providing server data, Redux handling app state? Would redux need to wrap relay wrappers or vice versa?

@gyzerok there may actually be merit in attempting to re-implement relay on top of redux, since one of relay's biggest problems is that its state management is not very clear or easy to understand.  It has two key problems (currently):

It doesn't work well on the server side.  This is because relay is built around instances of singleton, mutable objects.  This will be difficult to resolve into a state where javascript contexts on the server side can be safely shared amongst users (essential for reasonable performance on node.js)
It is currently complicated and confusing to implement mutations on top of.  There's no clear way to "update" or "set" values in the cache.  This leads to an awkward mutations API that attempts to declaratively map returned data from mutations to cache updates on the client.  A much simpler strategy would be to have the client write a clear set of changes (or actions in redux terminology) once it receives the data from the server.  An alternative (but somewhat more restrictive approach) might be to have the server return an array of mutation actions directly as the result of the mutation action.

Although both these problems are bing looked at by the relay team, there may still be an opportunity for the community to produce something innovative and different that proves to be not only simpler than the current relay implementation, but actually more powerful.

Has anyone managed to implement redux with graphql, with or without relay? It looks like the current repos above are more of a proof of concept versus something used in production. All I can think of is to http the graphql endpoint and return the results to redux, but you loose all the caching capability.

I want to try it, I would use them orthogonally. Relay pours data into the
app and Redux handles app state, routing, calling Relay mutations…
I guess that may cause problems when relay and redux data overlap, but I
need to try to see :-)
On Thu, Dec 3, 2015, 2:21 AM Patrick Heeney notifications@github.com
wrote:

Has anyone managed to implement redux with graphql, with or without relay?
It looks like the current repos above are more of a proof of concept versus
something used in production. All I can think of is to http the graphql
endpoint and return the results to redux, but you loose all the caching
capability.
—
Reply to this email directly or view it on GitHub
https://github.com/rackt/redux/issues/464#issuecomment-161485954.

--
Wout.
(typed on mobile, excuse terseness)

@wmertens That's sort of solved my issue, but now relay makes 2 requests, one with the hardcoded initial value, and then one when I call setVariables.

Still convinced this would be the biggest advancement in the react (and redux) space for early 2016.  I'd love to see this happen.  If I knew a bounty could help, I'd start one.

@patrickheeney this repo uses Redux and GraphQL: https://github.com/mattkrick/meatier without Relay

@baopham holy cow that looks awesome! I was just looking at meteor and noticing all the things it is mentioning :+1:

Looks like there are a lot of people interested in this topic (Relay/Redux, GraphQL, and reducing complexity) I'm working on a design for a simple yet functional GraphQL client that will play very nicely with the Redux approach to app state.
Curious what people think about this set of design principles: https://github.com/apollostack/apollo-client/pull/7/files?short_path=83772ba

Came here after reading quite a bit on the topic. It was an unexpected curvy trip in which I started with reading on redux' reselect, then graphql, then relay, then alternatives. I also read the whole discussion here. Seems like there is no complete Relay alternative that offers everything @ForbesLindesay pointed out:

There are three really difficult and valuable things that Relay accomplishes:

Diff the queries currently executed with the new queries from recently added components in order to query only new data from the server.
Optimistically apply updates on the client
Model both complex data structures (graph data is a hugely powerful model) and complex queries (which reduces need for round trips).

Most crucial of those for me is the first. The apollo-client that @stubailo mentioned says this in the docs:
We are always going to be improving the efficiency of the query diffing algorithm. Right now, it just does basic operations, but in the future it will be able to fetch single missing objects, and diff deeply nested queries. Follow along on the GitHub repository to find out when these features are coming.

Which makes me wonder to what extend is the diffing done in apollo client? What is supprorted?
The other aforementioned adrenaline project is strangely documented for my brain. Why do I need the schema on the frontend? Why is there if (__CLIENT__) checks in the resolvers?
In any case, whatever the solution is I don't know how should GraphQL data be represented in Redux store if components define alias fields in their GraphQL? @ForbesLindesay has posted a extract of serialized GraphQL with all parts required for figuring out caching, which is far from just the data which makes me kind of reluctant to keep this in my redux store.
Any new solutions, projects, developments?

@antitoxic I have a half completed solution, PM me if interested. This will be open sourced when it's ready.
Goal

think in redux's terms: only use action creators, middlewares, selectors
flexible fragments composition
data to be automatically available to the component that defines a fragment
action creators to easily compose queries, mutations and "markDirty"s
query diffing to fetch only required fields.

Life cycle

connected component start rendering
selector select data from store
selector sees undefined data
selector return dirty state
connected component render with "loading" element
component did mount
subscribe to store and select the state
check if graphql state has dirty entities
if dirty, dispatch a queryDirty action,
store unchanged, component not re-rendered, else rendered
queryDirty action goes through the middleware
graphqlMiddleware intercepts the action
the middleware sends an "optimised" query to the server
server return data
middleware normalises the data
middleware forward the result to the next middleware until the actual dispatch on the redux store gets called
rootReducer gets called
graphql reducer gets called
graphql reducer merges the normalised data into a new state
connect component gets notified of the updated state
goto 7

@jackielii I am interested of course, though I don't know if PM functionality exists in github (email me at: antitoxic at gmail). If you change your mind on open-sourcing your work earlier, I think everyone here will be interested.
The flow you described is similar to what I have in mind. I don't know how 13. and 15. would work. They seem the most tricky.

Hmm, this is an interesting approach - asking for a query, having that set a dirty state in the store, and then using that to compose an efficient query to send to the server.
In Apollo Client we're taking a slightly different approach where we start with the query called by the UI, then compare that against the store and send the diffed query without marking dirty state.
I think this would be a really exciting thing to try out!
One thing that we do have which I think could be very useful, are utilities to read and write queries to a normalized store, see here:

Reading/diffing against a normalized cache object: https://github.com/apollostack/apollo-client/blob/75878c57947824c7e917b351af668ff1aa11e288/src/data/diffAgainstStore.ts#L82-L92
Writing a GraphQL result to the store: https://github.com/apollostack/apollo-client/blob/75878c57947824c7e917b351af668ff1aa11e288/src/data/writeToStore.ts#L109-L123

If there were a way to factor those out so that all of these different clients to use them, I think that would be a big win so that we could focus on where stuff is different rather than constantly reimplementing ways to read and write GraphQL data in normalized form.

@jackielii , @stubailo : just to toss in one more related link, https://github.com/tommikaikkonen/redux-orm is a purely client-side approach to managing relational data in a Redux store. Might be some useful comparison in approaches.

I think it would be really cool to have the ability to read arbitrary normalized data using a GraphQL query, even if it didn't come from a GraphQL server. We're pretty close to that with Apollo client, but it would be a great way to decouple your UI from the data model by introducing the GraphQL abstraction layer. Since the GraphQL layer is strongly typed, you could then integrate with Typescript checking, validate your queries, etc. and maybe eventually migrate to using a GraphQL server which I think will be the best option.

Semi-sorta off-topic, but: the thing that's bugging me the most about all this GraphQL talk is the server side. How do you actually use and implement this on the server? How feasible is it to use GraphQL with an existing application? Can you put a GraphQL adapter around an existing data setup? Is all this Node-only?

You sure can do all of the above, and in many different languages! All of our posts are about JavaScript for now, but you can do the same stuff in any language:

How one of our contributors put a JavaScript GraphQL server on top of .NET, MySQL, MSSQL, and a PHP API: https://medium.com/apollo-stack/the-business-case-for-graphql-cc7a2b93148d
Tutorial for building a GraphQL server that talks to three backends: https://medium.com/apollo-stack/tutorial-building-a-graphql-server-cddaa023c035?source=latest
A general post about questions people have coming from REST: https://medium.com/apollo-stack/how-do-i-graphql-2fcabfc94a01#.37216p92t

We're actually migrating parts of our existing Node/Mongo/Meteor/React app to Apollo right now, and using it in just a few views of the application is working out really well. Hopefully will have a post about that soon.

@stubailo : thanks.  One more very off-topic question: how does GraphQL deal with continually-refreshed data, if at all? For example, say I've got a service that's tracking some info that's changing over time, and at the moment I'm just doing dumb polling every 15s to get the latest value, and doing diffing on the client.  How would a GraphQL setup deal with trying to keep that data current?

I think it would be really cool to have the ability to read arbitrary normalized data using a GraphQL query, even if it didn't come from a GraphQL server.

I’ve been feeling this too.

@markerikson GraphQL doesn't deal with data that is continually changing. Even with subscriptions in graphql there are things you have to setup whether it be through sockets, observables or w/e. I built react-reach to test out how to use it with redux. I learned a few things about it. One thing that sucks about react-reach is that you cant collocate queries/mutations nicely with it.  The second iteration that I've been working tries to make collocating queries/mutations nicer, as well as handles batching. I think I'll be done in 1-2 weeks. I also want to add normalization to the second iteration not sure if to depend on normalizr or make a homegrown solution. If you guys have any ideas for things you would like if you are using graphql with redux lmk.

@kennetpostigo: ah.  thanks for the clarification.  Yeah, I have two existing apps.  First one is basically CRUD, done with an RPC-style approach, and I'm prototyping a React+Redux rewrite for the original GWT client.  The other is Backbone, and primarily showing live updates of server data.  Just curious how GraphQL might work for that scenario, but sounds like the answer is "not really".

@gaearon want to talk sometime? I think it would literally just be a couple of tweaks to the internal query stuff of Apollo Client, and then we can publish it as a separate package.

I'm just doing dumb polling every 15s to get the latest value, and doing diffing on the client. How would a GraphQL setup deal with trying to keep that data current?

@markerikson this is a fully-supported pattern in apollo client, basically you can just set a pollInterval on your query, and it will integrate that result into the store for you. No custom diffing or normalization logic required.

I also want to add normalization to the second iteration not sure if to depend on normalizr or make a homegrown solution.

Try the Apollo Client normalizer? I'd be happy to work with you to factor that out into a separate module. I think if we work together to make one really great GraphQL normalizer, then we can all benefit from it, rather than implementing a new thing every time which will have its own edge cases and behavior. We're doing our best to make it pluggable, for example by accepting a custom dataIdFromObject function which lets you specify an arbitrary function to get the normalization ID from the object.

@stubailo sounds good, if you can give me a rundown on where the normalization parts in apollo are I'd be glad to help in extracting it out. PM me on the graphql slack.

Some more new stuff
https://medium.com/@matt.krick/2990c81aa807

I think there are definitely many ways to do this stuff and lots of different approaches are valid, I think the best we can do is share some of the tooling so that we aren't all reinventing the wheel each time!

@stubailo I tried to following the Redux's middleware approach:
action dispatched and middleware intercepts and translates.
As for "mark dirty", it's just an plain action with a graphql query, middleware intercepts it and normalise it, then merge into the store, and from here it goes back to Redux's life cycle, any component subscribe to the parts of state that's updated to "dirty", it updates, and requests for more data if needed(intersect action)
I tried to send you an email to the address in you github profile, but got rejected. could you give me you email if want to discuss a bit more?

Normalise is just a process of executing a graphql query, so basically I re-use the graphql's execute to do the nomalising. and the structure of the normalised data is just like a type hashmap:
Map<typeName: string, entityMap: Map<key: mixed, entity: Map<fieldNameWithArgs: string, value: mixed>>>

anyone interested, please email jackie.space at gmail

I re-use the graphql-js's execute to do the nomalising

I personally think loading the schema on the client and using GraphQL-JS is not the right approach, which is why we wrote a much simpler executor that doesn't rely on knowing the schema.

could you give me you email if want to discuss a bit more?

I don't really use email (but I should update that address) but you can find me on the GraphQL or Apollo slack channels:

http://slack.apollostack.com/
https://graphql-slack.herokuapp.com/

@stubailo is there documentation describing to what level the apollo client support diffing?

@antitoxic here it is: http://docs.apollostack.com/apollo-client/core.html#forceFetch
There's an issue open to do fancier diffing, which would be easy to implement but there are some concerns with data consistency - if you diff down to individual fields, then different fields on the same object might get out of sync. https://github.com/apollostack/apollo-client/issues/113

I use GraphQL and GraphQL-relay server side.  Then I use redux and redux-thunk in my application.  The thunks are called by the components and compare their data-requirements against the state before conditionally loading more from graphQl.
This setup works excellent and I am happy with the stack.
However, when I look at the elegance of relay queries I envy their dynamic nature and expressiveness.
It would be great if we could come up with a special action, based on thunks/sagas, or some middleware - that could

Parse relay data requests from components, using schema
Use a custom translation to compare requirement against redux state
Fetch data, if needed
Use a custom translation in the reducer to put the result into state

I think the translations between relay/graphql and app state will be challenging, which would perhaps require some common structure. But a flexible relay action in redux would definitely be a powerful tool!.

@tvedtorama this is almost exactly what Apollo Client was designed to do, have you taken a look at that yet? It has all of the custom translation etc you just mentioned.

@stubailo No, I didn't quite catch its mission from the discussions above.  Looks really promising and I love that they use Typescript.  I jumped right to the redux-integration which explained things for me: http://dev.apollodata.com/react/redux.html
Thanks for this great tip!

I have integrated Redux and Relay in a way not mentioned in this thread.  I have a GraphQL type that defines the representation of the Redux state.  That state is provided in my root Relay query.  Upon the initial load of the graphql root, this state is also loaded, and initializes the Redux state.  Whenever the Redux state is updated on the client, I commit a mutator to push that state up to the server, and use the optimistic update to immediately provide the new state in the Relay fragment.  The graphql server then does have chance to respond to the client state and modify it and other graphql fragments accordingly, which may update the client state again.

@naturalethic does that mean that you essentially don't have any client state any more, and all client states go through the server? I'm having trouble imagining a use-case in which that would be desirable for all client state.

@helfer This solution is evolving as I play with it, however there is no reason one could not choose to send only a subset of the client state to the server, or none at all.  If one were to subclass Relay.DefaultNetworkLayer, one could filter out and ignore queries of this particular mutation, and I suspect the optimistic update would still pass the new state through to the Relay store, though I have not tried that yet.
Under such a condition, one could provide, purely on the client, a loop back from redux into relay, where a copy of the redux state is a branch on the relay state tree.

So now that Relay and GraphQL are out in the open, we should start a conversation about how this relates to Redux. Anyone have thoughts on Relay will effect both the core Redux library, and what ecosystem tools will need to be built out to accommodate it?

authors: CooCooCaCha ForbesLindesay antitoxic baopham bbirand boosh bsr203 clintwood fgarcia fingermark gaearon gyzerok halil199409 helfer ide jackielii josephsavona kennetpostigo markerikson mindjuice naturalethic nhagen nodkz patrickheeney stubailo tvedtorama vicentedealencar wmertens yungsters

repo: rackt/redux


text:
Drop "behavior" from enhancer names

Per @knowbody ... pity "scroll" wasn't free on npm, though.

I think the npm name is okay

I know, and even if it were available, it'd be a shame to take up a name like that for a package that we might just end up merging into history or whatever later on anyway.

source: gharchive/pull-request

authors: knowbody taion

repo: rackt/scroll-behavior


text:
where can we find the roadmap ?

The next version of Ractive we have wait a long time,can we have a timeline ,thanks

I'm afraid we adhere to the John Carmack 'when it's done' philosophy of release cycles around here, much as we try to be a bit more disciplined. The good news is that the big chunk of work standing in the way of the next version (0.8) has been merged, so now it's a case of fixing any major bugs and tidying up the build a bit. Next couple of weeks hopefully, depending on how things go!

repo: ractivejs/ractive


text:
Replace  446 in ru constants translate

Repair wrong translation 446.humanize in locale :ru
>>  Humanize.configure {|config| config.default_locale = :ru}
=> :ru
>> 446.humanize
=> "шесть"
>>

Thank you for your PR <3

Just released this in humanize 2.4.3.

authors: radar sergey-arkhipov

repo: radar/humanize


text:
Document how to deal with cubes with beams

At the moment, when loading a cube in Jy/beam, the .unit attribute will give Jy and summing into a 1D spectrum also gives a spectrum in Jy which is confusing since this is actually (I think?) Jy/beam.
I think we should document how to make use of the radio_beam package, as well as potentially make .unit return Jy/beam. Furthermore, we should show how to convert a cube from Jy/beam to Jy/pixel, which at the moment I could not figure out how to do without calling e.g. proj_plane_pixel_area.
Finally, I think we should make radio_beam a required dependency so that all the beam warnings no longer appear by default.

This is closely related to https://github.com/astropy/astropy/pull/5173.  Astropy doesn't support "beam" as a unit very well at the moment.  This is a real problem and a pretty big flaw in how spectral_cube writes files.
The main reason for not including radio_beam as a hard dependency is to encourage use of this package for non-radio data.

@keflavich - radio_beam is such a lightweight dependency that (once released) I don't think there would be any harm in including it in install_requires. I doubt many users would even notice.
I thought radio_beam subclassed Unit, hence why I thought the Jy/beam could be preserved, but just saw it's a Quantity. So is the solution to push forward with astropy/astropy#5173?

@keflavich - just thinking out loud about this, is there a reason we can't just create a new unit every time we parse a FITS file and make it correspond to an area on the sky:
In [15]: beam1 = u.def_unit('beam', represents=0.1 * u.sr)

In [16]: beam1
Out[16]: Unit("beam")

In [17]: beam2 = u.def_unit('beam', represents=0.2 * u.sr)

Then it will look like 'beam' to the user but will behave as a solid angle, which is basically what it is.

Beams already have that property; a beam object is steradian-equivalent.  The problem is that the astropy equivalency I wrote is a Jansky-Kelvin equivalency, while it should have been a Jy/sr-Kelvin equivalency.

Until astropy#5173 is merged, #310 is the answer.  We'll probably need to do some astropy version checking because pre/post 5173 will be incompatible.

Closed by #310.

authors: astrofrog keflavich

repo: radio-astro-tools/spectral-cube


text:
🛑 GPS Receiver API is down

In f1362ac, GPS Receiver API (http://tracker.ace-energy.co.th/receiver/api/v1/health) was down:

HTTP code: 504
Response time: 15037 ms

Resolved: GPS Receiver API is back up in ce94929.

repo: radiuszon/upptime


text:
[Spinner] Any way to change color and size ?

I'd like to make the spinner bigger than the given option size which is 20px * 20px with 100% scaling.
And change the color of it.
Thank you.

You can override width, height, and color via the regular style prop if size and color props don't work for you.
How large is your target size though and what does your design look like?

@vladmoroz
I guess I didn't read the documentation properly...
By "style prop", do you mean regular CSS?

How large is your target size though and what does your design look like?

The target size is 40px * 40px and the design is the same as the provided Spinner component from Radix-UI Themes except for the color which is #027FFF.

Yeah, with regular CSS
We'll consider adding more sizes but this should work in the meantime

Guess this can be closed

authors: kotAPI vladmoroz yukiyohure

repo: radix-ui/themes


text:
Add Click Parameter on MenuItem

Currently it's only possible to provide a Path parameter to the children of the <Menu> and the <Menu> takes full control.
This PR makes it possible to also add the Click EventCallback to the children (MenuItem), this way we can use additional logical before navigation and have more control of the component if we don't want to use the Click of the parent
This PR introduces no breaking changes, but an additional parameter Click to the MenuItem

Hey @vertonghenb,
Thanks for your pull request however RadzenMenuItem already have onclick propagated to the menu:
https://github.com/radzenhq/radzen-blazor/blob/master/Radzen.Blazor/RadzenMenuItem.razor#L5
https://github.com/radzenhq/radzen-blazor/blob/master/Radzen.Blazor/RadzenMenuItem.razor.cs#L84-L90
Using Value of the event argument you can check which exactly menu item is clicked.

@enchev true, but it's quite tedious and can be error prone if you forget one of the values.

authors: enchev vertonghenb

repo: radzenhq/radzen-blazor


text:
/usr/bin/env: ‘node’: No such file or directory

I had this error in my Linux distribution Lubuntu 16.04.3.
To work around this error, I had to install 'nodejs-legacy'.
Maybe you can verify if legacy nodejs is installed.

@robertopc I'm working on upgrading this project to use a more modern version of Node which should fix this issue. I will update this as soon as I do it.

@robertopc The new release should solve this issue you were experiencing. I've changed the way binaries are distributed and compiled.
I'm gonna close the issue but feel free to open again if you still see problems.

authors: rafaelrinaldi robertopc

repo: rafaelrinaldi/whereami


text:
Full screen notifications not showing when device is locked on some devices

1 - Describe the bug
Full screen notification does not show on some devices when they are locked. I first tested on an Android 10 device and the notification page showed up as expected. I then tested on other device with Android 6, 8, 10 and 12, and in all cases, the device wakes up, but the page did not show up when screen was locked. User has to unlock the device to view the full screen notification.
2 - Provide us as much information as possible
Dependencies
  intl: ^0.17.0
  timezone: ^0.9.1
  timer_builder: ^2.0.0
  path_provider: ^2.0.11
  path: ^1.8.2
  sqflite: ^2.2.2
  flutter_slidable: ^2.0.0
  shared_preferences: ^2.0.0-nullsafety
  flutter_system_ringtones: ^0.0.6
  android_alarm_manager_plus: ^2.1.0
  just_audio: ^0.9.31
  awesome_notifications: ^0.7.4+1
  audio_session: ^0.1.13

Tested devices
Working: Full screen notification shows up even when device is locked
Not working: Full screen notification shows up only after device is unlocked

 Android Version
	 Device Model
	 Behavior

 Android 6
	 Samsung Galaxy S6
	 Not working

 Android 8
	 Huawei P10 Lite
	 Not working

 Android 10
	 Infinix Note 7
	 Working

 Android 10
	 Xiaomi Poco M3
	 Not working

 Android 12
	 Xiaomi Redmi Note 10
	 Not working

In addition to my code below, I found the same behavior when running the phone call example project, except that one didn't even work on the Infinix device. The behavior was the same in both debug and release builds.
AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.flux.clock">
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
    <uses-permission android:name="android.permission.WAKE_LOCK"/>
    <uses-permission android:name="android.permission.USE_FULL_SCREEN_INTENT" />
    <!-- For apps with targetSDK=31 (Android 12) -->
    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
   <application
        android:label="Clock"
        android:name="${applicationName}"
        android:icon="@mipmap/ic_launcher">
        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTop"
            android:theme="@style/LaunchTheme"
            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"
            android:hardwareAccelerated="true"
            android:windowSoftInputMode="adjustResize"
            android:showWhenLocked="true"
            android:showOnLockScreen="true"
            android:turnScreenOn="true">
            <!-- Specifies an Android theme to apply to this Activity as soon as
                 the Android process has started. This theme is visible to the user
                 while the Flutter UI initializes. After that, this theme continues
                 to determine the Window background behind the Flutter UI. -->
            <meta-data
              android:name="io.flutter.embedding.android.NormalTheme"
              android:resource="@style/NormalTheme"
              />
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
        <!-- Don't delete the meta-data below.
             This is used by the Flutter tool to generate GeneratedPluginRegistrant.java -->
        <meta-data
            android:name="flutterEmbedding"
            android:value="2" />
        <service
            android:name="dev.fluttercommunity.plus.androidalarmmanager.AlarmService"
            android:permission="android.permission.BIND_JOB_SERVICE"
            android:exported="false"/>
        <receiver
            android:name="dev.fluttercommunity.plus.androidalarmmanager.AlarmBroadcastReceiver"
            android:exported="false"/>
        <receiver
            android:name="dev.fluttercommunity.plus.androidalarmmanager.RebootBroadcastReceiver"
            android:enabled="false"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.BOOT_COMPLETED" />
            </intent-filter>
        </receiver>
    </application>

</manifest>

Initilization:
void main() async {
	WidgetsFlutterBinding.ensureInitialized();

	await AwesomeNotifications().initialize(null,
	[NotificationChannel(
	  channelGroupKey: alarmNotificationChannelGroupKey,
	  channelKey: alarmNotificationChannelKey,
	  channelName: 'Clock Alarm',
	  channelDescription: 'Notification channel for clock alarms',
	  defaultColor: ColorTheme.accentColor,
	  locked: true,
	  importance: NotificationImportance.Max,
	  playSound: false,
	  enableVibration: false,
	  enableLights: false,
	)],
	channelGroups: [ NotificationChannelGroup(
	  channelGroupKey: alarmNotificationChannelGroupKey,
	  channelGroupName: 'Clock Alarm Group',
	)], debug: kDebugMode);

	runApp(const App());
}

Firing notificaton
This is done from a different isolate, scheduled by Android Alarm Manager Plus.
AwesomeNotifications().createNotification(
  content: NotificationContent(
    id: alarmNotificationId,
    channelKey: alarmNotificationChannelKey,
    title: 'Alarm Ringing...',
    category: NotificationCategory.Alarm,
    fullScreenIntent: true,
    autoDismissible: false,
    wakeUpScreen: true,
    locked: true,
  ),
  actionButtons: [
    NotificationActionButton(
      showInCompactView: true,
      key: alarmSnoozeActionKey,
      label: alarmSnoozeActionLabel,
      actionType: ActionType.Default,
      autoDismissible: true,
    ),
    NotificationActionButton(
      showInCompactView: true,
      key: alarmDismissActionKey,
      label: alarmDismissActionLabel,
      actionType: ActionType.Default,
      autoDismissible: true,
    ),
  ],
);

Notification Controller
 @pragma("vm:entry-point")
  static Future<void> _onActionReceivedMethod(
      ReceivedAction receivedAction) async {
    print("payload: ${receivedAction.payload}");

    switch (receivedAction.buttonKeyPressed) {
      case alarmSnoozeActionKey:
        break;

      case alarmDismissActionKey:
        dismissAlarm();
        break;

      default:
        App.navigatorKey.currentState?.pushNamedAndRemoveUntil(
          alarmNotificationRoute,
          (route) {
            return (route.settings.name != alarmNotificationRoute) ||
                route.isFirst;
          },
          arguments: receivedAction,
        );
        break;
    }
  }

App Routes
 @override
  Widget build(BuildContext context) {
    return MaterialApp(
      navigatorKey: App.navigatorKey,
      debugShowCheckedModeBanner: false,
      title: 'Clock',
      theme: theme,
      initialRoute: '/',
      onGenerateRoute: (settings) {
        switch (settings.name) {
          case '/':
            return MaterialPageRoute(builder: (context) => const NavScaffold());

          case alarmNotificationRoute:
            return MaterialPageRoute(
              builder: (context) {
                final ReceivedAction receivedAction =
                    settings.arguments as ReceivedAction;
                int scheduleId =
                    int.parse((receivedAction.payload?['scheduleId'])!);
                return AlarmNotificationScreen(
                    alarm: getAlarmByScheduleId(scheduleId));
              },
            );

          default:
            assert(false, 'Page ${settings.name} not found');
            return null;
        }
      },
    );
  }

3 - How To Reproduce the Error
Steps to reproduce the behavior:

Scheduled a full screen notification
Lock the device
Wait for the notification to fire
Device wakes up but full screen notification is not shown

4 - Expected behavior
The full screen notification should show even when the device is locked, like in most alarm and call apps.

but the page did not show up when screen was locked

The decision on whether or not to display the landing page of the automatic one-click notification, as with full-screen notifications, is up to the operating system, and this logic may change between Android distributions. This is the expected behavior.

@rafaelsetragni A bit off-topic but, I was under the assumption that full screen intents are the recommended method of creating full screen alarm/call receiving functionality. I have tested apps that show a full screen page on lock screen on the listed devices. Are you aware of how that is usually done?

Ok, so I found out that the behavior I was going for wasn't actually related to notifications but to setting specific flags that allows the app to appear over the lock screen. This could be achieved either by setting them directly in MainActivity.kt, which would cause the entire app to appear over lock screen:
import io.flutter.embedding.android.FlutterActivity
import android.app.Activity
import android.os.Bundle
import android.view.WindowManager;

class MainActivity : FlutterActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
        getWindow().addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD);
        getWindow().addFlags(WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED);
        getWindow().addFlags(WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON);
    }

or using flutter_windowmanager to add and clear the flags dynamically so only a particular screen appears over the lock screen.

Hi @AhsanSarwar45 thanks for sharing your POV on this issue. Actually I was wondering how to add call like notifications that apps like WhatsApp show full screen call notifications even when app is terminated and locked , is there any provision to do the same using this package or could you please help if any with your prior experience with this package?


text:
Dependency version using lodash/underscore

I started using some of the same function names for checks like isUndefined, etc. I could save some bytes if I create a dependency version while maintaining a non-dependent version. I am using uglifyjs and there is an options for removing parts of the code inside conditionals.
https://www.npmjs.com/package/uglify-js#conditional-compilation
will have to figure out how to do it.

I am not using underscore/lodash, except for _.indexOf when needed.

repo: rafde/PrioritizedSubPub


text:
Suggest update RxJava and RxAndroid version.

I see your lib use old version of rxjava and rxandroid.
And currently,I use your lib by this in gradle script:
compile 'io.reactivex:rxjava:1.1.1'
 compile 'io.reactivex:rxandroid:1.1.0'

    compile('com.ragnarok.rxcamera:lib:0.0.2'){
        exclude group: 'io.reactivex',module:'rxjava'
        exclude group: 'io.reactivex',module:'rxandroid'
    }

By the way,thanks to ragnraok for your awesome RxCamera Lib.

@wind0ws would you mind to send a PR for this?

@sibeliusseraphini Sorry for my poor english.Does PR means Public-Relation?
RxCamera depend on RxAndroid and RxJaAVA, RxAndroid depend on RxJava.

PR - Pull Request

repo: ragnraok/RxCamera


text:
Run HIL-SERL in simulation without real-world robot

I really want to try running the algorithm and experience the process of "teaching" robots, but I don't have a physical device.... So I would like to inquire if the existing code supports interaction within a simulation environment? If not, could you give me some advice on how I might need to modify the code to achieve this?

try this one: https://github.com/rail-berkeley/serl/blob/main/docs/sim_quick_start.md

repo: rail-berkeley/hil-serl


text:
Expose available bundle list

This PR exposes the available bundle list so Rails new helper can list them. It still requires updating the Gemfile.lock
Related to:

https://github.com/rails/rails/issues/43251
https://github.com/rails/rails/pull/43254

If this PR is merged and released, then we can update Rails with: https://github.com/rails/rails/pull/43255

Closed based on https://github.com/rails/rails/pull/43255 discussions.

repo: rails/cssbundling-rails


text:
rubygems.org release ?

Hi,
I think it's time to cut a new version and release it on https://rubygems.org.
Would help with https://github.com/collectiveidea/audited/pull/276.
Regards

It is not ready for a release yet.

authors: kwent rafaelfranca

repo: rails/rails-observers


text:
how can we ensure each job is consumed at least once?

question
I'm currently learning the solid queue design, which I find very clean and enjoyable to read.
I have a question around handling jobs after they transition from ReadyExecution to ClaimedExecution. If the entire process crashes unexpectedly (not a graceful shutdown), how are the jobs already in the ClaimedExecution state handled? Currently it doesn't seem there is logic to cover this case.
My question is: if these claimed jobs are not handled, how can we ensure each job is consumed at least once?
this code
lib/solid_queue/worker.rb:
def poll
  claim_executions.then do |executions|
    executions.each do |execution|
      pool.post(execution)
    end

    executions.size
  end
end

def claim_executions
  with_polling_volume do
    SolidQueue::ReadyExecution.claim(queues, pool.idle_threads, process.id)
  end
end

I would appreciate any clarification on this matter.Thank you!

Hey @mxchenxiaodong, thank you! There's a brief explanation about this in the README:

If processes have no chance of cleaning up before exiting (e.g. if someone pulls a cable somewhere), in-flight jobs might remain claimed by the processes executing them. Processes send heartbeats, and the supervisor checks and prunes processes with expired heartbeats, which will release any claimed jobs back to their queues. You can configure both the frequency of heartbeats and the threshold to consider a process dead. See the section below for this.

When you start a new supervisor, or simply periodically, the supervisor checks for processes that have died and deregister them. Deregistering a process releases its claimed executions. Also, claimed executions have their own release method. Yours doesn't work because the job is already in the system and you can't just enqueue it again.

I understand now, thank you for the explanation~
app/models/solid_queue/process.rb
class SolidQueue::Process < SolidQueue::Record
  after_destroy -> { claimed_executions.release_all }
end

😆

authors: mxchenxiaodong rosa


text:
Multiple CSS files for Tailwind apply directives

Hey!
We have used tailwind for some time in our project and are now attempting to upgrade to Rails 7 with importmaps and this gem instead of Node.
We seem to have stumbled upon a problem with how we arranged our CSS files as we had split them over multiple files and done @import in our application.css file. If we do that with this gem we just get these errors

The CSS will start working again if we merge all into the application.tailwind.css but that results in a large and unwieldy file. So the main question is: Is there a way to have multiple CSS files that are compiled by tailwind without using Node

From my research on this, at the moment there is not, since there is no postcss plugin.
Also I'm not sure if this is tailwindcss-rails or tailwind standalone cli build issue.
But, I may be wrong on this one, i didn't spend a lot of time researching this issue.

From my research on this, at the moment there is not, since there is no postcss plugin. Also I'm not sure if this is tailwindcss-rails or tailwind standalone cli build issue.
But, I may be wrong on this one, i didn't spend a lot of time researching this issue.

I don't think it's really an issue/bug from either this gem or the CLI tool, it's just not a feature. Tailwind CLI only seem to accept one file to it and does not have functionality to include other files, as far as I understand

If you're using HTTP2, no substantial benefit for bundling CSS into a single file. You can refer to multiple files just fine. Either way, it's indeed not a feature of this standalone TW setup.

@dhh The point was not to have bundling, but my understanding is tailwind needs to "build" each CSS file and there seem to be no way to make this happen. So if I just link to the CSS file the @apply directives will not be resolved and i get the errors you see in the screenshots

I don't think I follow? Is it that you're using @apply in multiple files? If so, I'd just stop doing that 😄. As I understand it, @apply is meant to be a sparse, rare usage. If you're doing it so much you need multiple files to contain it all, I think it's worth considering if Tailwind is the right fit.

I don't think it's really an issue/bug from either this gem or the CLI tool, it's just not a feature. Tailwind CLI only seem to accept one file to it and does not have functionality to include other files, as far as I understand

👍🏼
@dhh issue here is that it is "common" practicle to separate components into different files
styleshhets/
  components/
   button.css
   card.css
 application.css

And then include those components using @import inside the application.css
But, with standalone CLI that is not possible since there is no postcss

I think such a setup sorta defeats the purpose of Tailwind, to be honest. Their tag line is literally "Rapidly build modern websites without ever leaving your HTML". Anyway, it is what it is, if you're using the standalone version of Tailwind. If you must have postcss, then you'll need the whole Node enchilada.

I agree that we may be overusing the @apply after from reading closer in tailwind's docs it's definitely not the recommended way

We made the same "mistake" in the past @mathias234 , it takes a time to adjust after BEM or similar stuff 😅

+1 to this. I would love to be able to keep my railsy CSS structure with several small CSS files in stylesheets, while still being able to sprinkle a little heretical @apply in them when needed.
I guess just a tiny ruby pre-compiler that watches and simply merges all css files in /stylesheets/ before handing them over to tailwind would do the trick without node and in very few lines of code? @mathias234 wrote a hack to that effect here: https://github.com/lnu-norge/lokaler.lnu.no/blob/c13668de1aaa723a1432b87db46a0b12d146c96b/lib/tasks/css_packer.rake

I think such a setup sorta defeats the purpose of Tailwind, to be honest. Their tag line is literally "Rapidly build modern websites without ever leaving your HTML". Anyway, it is what it is, if you're using the standalone version of Tailwind. If you must have postcss, then you'll need the whole Node enchilada.

To me Tailwind has become both a way to rapidly build without leaving my HTML, but also a design system that adds consistency.  When Tailwind can't keep up with all my CSS needs, I end up using a few CSS files as well - usually split into several small files to try to keep them from getting too messy - and then I use @apply to get that sweet consistency of colours, margins, and more.
Typical use cases where I feel tailwind-in-html falls short and I find myself reaching for @apply:

Styling third party HTML with set classes (impossible with tailwind)
Styling standard content typography (p, a, h1, etc. (feels impractical to make custom view_components or whatever for all of them)
"Combined utility classes" for combinations of utility classes I repeat on several different components and would want to change one place to change them all

Genuinely looking to learn here: Is using @apply wrong for these cases? It feels natural to keep tailwind-in-html as far as it can take me, but then eject to CSS for these cases - and I don't think we have over-done it?
For number 1 I don't see any other way to do it - but I guess the other two could be mostly achieved by creating composable components, but I guess that would require view_components too? Or could I do it efficiently and nicely with vanilla rails?

I'm not so much rendering an opinion on right or wrong, as much as just parroting what the TW guidelines are. As well as of course just noting the inherent constraints we have using the standalone TW compiler. Ultimately, you should write CSS the way that feels right for your app! And that may well be "I need Node, because I want PostCSS and other stuff" ✌

Thanks for the response!

"I need Node, because I want PostCSS and other stuff"

Would you be open to a PR that allows for a tiny precompile step that simply combines all css files in /stylesheets/ into one file, that is then passed to tailwind? Written with pure ruby code and without ever needing Node, of course.
Not unlike what @mathias234 hacked together here: https://github.com/lnu-norge/lokaler.lnu.no/blob/c13668de1aaa723a1432b87db46a0b12d146c96b/lib/tasks/css_packer.rake

I think having a small precompiler live in a gem which we can point to from the README makes sense to me 👍

I was able to find away or a solution.
Within application.tailwind.css I wrapped my custom classes which includes @apply with@layer components {}.
Example...
@tailwind base;
@tailwind components;
@tailwind utilities;

@layer components {
    .auth {
        @apply relative;
        --tw-bg-opacity: 1;
        background-color: rgba(255, 255, 255, var(--tw-bg-opacity));
    }
    .auth:before {
        content: "";
        margin-left: -48%;
        background-image: url("assets/bg-login.svg");
        background-repeat: no-repeat;
        background-size: auto 100%;
        background-position: 100%;
        height: 100%;
        position: absolute;
        top: 0;
        left: 0;
        width: 100%;
    }
    .auth_container {
        @apply container mx-auto;
    }
    .auth_grid {
        @apply block grid-cols-2 gap-4;
    }
}

It works for me and hope it helps.

Hey!
We have used tailwind for some time in our project and are now attempting to upgrade to Rails 7 with importmaps and this gem instead of Node. We seem to have stumbled upon a problem with how we arranged our CSS files as we had split them over multiple files and done @import in our application.css file. If we do that with this gem we just get these errors
The CSS will start working again if we merge all into the application.tailwind.css but that results in a large and unwieldy file. So the main question is: Is there a way to have multiple CSS files that are compiled by tailwind without using Node

Hey man, I have this one solution for me, just create rake task lib/tasks/csspacker.rake with the next code:

desc "Packs all CSS files from app/assets/tailwind_stylesheets into app/assets/application.tailwind.css
      then runs the tailwind build"
task pack_css: :environment do
  files = Dir["./app/assets/tailwind_stylesheets/**/*.css"]

  File.open("./app/assets/stylesheets/application.tailwind.css", "w") do |main_file|
    main_file.write("/* GENERATED FILE! */\n")
    main_file.write("@tailwind base;\n")
    main_file.write("@tailwind components;\n")
    main_file.write("@tailwind utilities;\n")
    main_file.write("\n")

    files.each do |file_path|
      File.open(file_path, "r") do |file|
        loop do
          main_file.write(file.readline)
        rescue StandardError
          main_file.write("\n")
          break
        end
      end
    end
  end
end

Rake::Task['tailwindcss:build'].enhance [:pack_css]

desc "Run tailwind:build on changes in directory app/assets/tailwind_stylesheets"

task 'pack_css:watch' do
  listen = Listen.to(Rails.root.join('app', 'assets', 'tailwind_stylesheets')) do
    Rake::Task[:pack_css].execute
    Rake::Task['tailwindcss:build'].execute
  end

  listen.start
end

Rake::Task['tailwindcss:watch'].enhance ['pack_css:watch']```

@dhh hi, what you can say about this solution?

@loqimean thanks for providing an alternative.
A couple things that I've noticed:

it requires gem "listen", "~> 3.8" in order to work
it will replace the original application.tailwind.css causing it to become the same as if there were no separate files and duplicating code as you commit it.

Keep rocking!

So, what about now, TailwindCSS allows to do it in its new version without any additional things

So, what about now, TailwindCSS allows to do it in its new version without any additional things

Would you mind sharing a bit more about that? I'd really appreciate as I've just created a new rails project and was unable to figure that out.
Thanks a bunch!

@loqimean thanks for pointing that out.
I've checked I had latest tailwind version and tried that approach both with @import and @tailwind and none worked... it will actually import those into application.css with all @apply within it thus not parsing at all.
Please let me know if you have had any further progress with it.
I really appreciate your help here.

With the latest version of the gem, I have something like this and it works
In app/assets/stylesheets/application.tailwind.css:
@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";
@import "./buttons.css";

/* You can put css here too */

Then in app/assets/stylesheets/buttons.css:
@layer components {
  .btn {
    @apply px-6 py-4;
    @apply rounded-lg shadow-xl;
    @apply hover:cursor-pointer;
  }
}

With the latest version of the gem, I have something like this and it works

@brunoprietog Thanks a lot for taking the time to help along.
I've created a brand new project with the same code you pasted above and it is publicly available here
Somehow it will get a bit messed up as it will get both versions conflicting.
There is a /posts scaffold just to test the CSS but when trying to inspect this is what i get:

BTW, I've also tried with the defaults with no luck as well:
@tailwind base;
@tailwind components;
@tailwind utilities;
@import "./buttons.css"

I must be missing some obvious detail here.
I'd sincerely appreciate any insights!

Tailwind requires a watcher that rebuilds the CSS when files change. So, you have to run bin/rails s in one terminal and bin/rails tailwindcss:watch in another. The generator includes a bin/dev file, which Foreman uses to run multiple processes in a single terminal window. These processes are defined in the procfile.dev file. So, you have 2 options: Run the commands separately, or run bin/dev.
Also, if you are going to follow this approach, I recommend you to use Propshaft instead of Sprockets, you can do it by passing the -a propshaft option to the rails new generator, like this: rails new myapp --css tailwind -a propshaft.
Let me know if it works

@brunoprietog I was already using bin/dev. Replacing Sprockets with Propshaft did the trick.
Thanks again!

For anyone else finding this, in my (pretty clean) Rails app the @tailwind directive stops other imports for working.
ie, this doesn't work:
@tailwind base;
@tailwind components;
@tailwind utilities;

@import "./buttons.css";

But this does work:
@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

@import "./buttons.css";

For anyone else finding this, in my (pretty clean) Rails app the @tailwind directive stops other imports for working.
ie, this doesn't work:
@tailwind base;
@tailwind components;
@tailwind utilities;

@import "./buttons.css";

But this does work:
@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

@import "./buttons.css";

I had the same issue (Rails 7.1, esbuild, tailwindcss), this worked for me!

authors: AhmedNadar DanielJackson-Oslo Mth0158 brunoprietog dhh dixpac fagiani iHiD loqimean mathias234

repo: rails/tailwindcss-rails


text:
lib/install/tailwindcss.rb assumes newline at end of app/assets/config/manifest.js

If there is no newline at the end of app/assets/config/manifest.js, append_to_file in the following codeblock will add //= link_tree ../builds to the end of the last line, breaking the build with a process_link_tree_directive error:
# tailwindcss-rails/lib/install/tailwindcss.rb:23-25

if (sprockets_manifest_path = Rails.root.join("app/assets/config/manifest.js")).exist?
  append_to_file sprockets_manifest_path, %(//= link_tree ../builds\n)
end

I think the simplest fix would be to add a newline to the start of the line added by append_to_file, as lib/install/tailwindcss.rb does for the append_to_file  call targeting .gitignore:
# tailwindcss-rails/lib/install/tailwindcss.rb:27-29

if Rails.root.join(".gitignore").exist?
  append_to_file(".gitignore", %(\n/app/assets/builds/*\n!/app/assets/builds/.keep\n))
end

This will result in extra whitespace sometimes in app/assets/config/manifest.js, but that doesn't appear to be semantically significant.
If the maintainers agree with this approach, I'd be happy to open a PR to fix. Thanks for reading and for the work you do on this great gem ❤

@litchk Thanks for reporting this! Yes, that approach seems fine to me and I'd be very grateful if you opened a pull request. Thank you!

Sure thing, and will do.
Do you have any opinions on how to test the fix within the context of the current test setup? lib/install/tailwindcss.rb is currently only tested by test/integration/user_journey_test.sh.
I think ideally a test would check that a app/assets/config/manifest.js file both with and without a newline at the end is properly formed after running lib/install/tailwindcss.rb. So my thought is to basically have 2 or 3 tests:

Run rails new, replace app/assets/config/manifest.js with a dummy file without a newline at the end, run lib/install/tailwindcss.rb, check that app/assets/config/manifest.js looks OK
Run rails new, replace app/assets/config/manifest.js with a dummy file with a newline at the end, run lib/install/tailwindcss.rb, check that app/assets/config/manifest.js looks OK
Run rails new, don't touch app/assets/config/manifest.js, run lib/install/tailwindcss.rb, check that app/assets/config/manifest.js looks OK

(3) doesn't really do anything different, but I like the idea of testing against what rails new really outputs. Ideally I would just generate a Rails app once for all the tests, for speed's sake.
I could follow the model of test/integration/user_journey_test.sh for this or do it within Test::Unit.
By the way, I think I should fix/test the same thing for append_to_file "Procfile.dev", "css: bin/rails tailwindcss:watch\n".
Let me know if you have any opinions here, if not can just make a call and you can let me know your thoughts on the result.

@litchk Thanks for asking about testing ... this feels like enough of an edge case, and integration testing with the user journey is challenging enough (and takes SO LONG on windows!🙄), that I'm OK skipping test coverage here.

authors: flavorjones litchk


text:
Error "Undefined index: password" when updating the profile.

On Account component, there is a new logic to get password index. It causes a problem when my page is only a feature to update the profile details (name, phone, etc.)

To prevent this, the logic should check the password index first before getting it or using array_get() function.

This is fixed by #420 and will be available in version 1.5.3 of the User plugin.

authors: bennothommo triasrahman

repo: rainlab/user-plugin


text:
🛑 RiotSkin4CN-Download is down

In dd460ea, RiotSkin4CN-Download (https://s-cd-4307-general.oss.dogecdn.com/riotskin4cn/live.json) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RiotSkin4CN-Download is back up in e75e81e after 10 minutes.


text:
🛑 RiotSkin4CN-Download is down

In fcb1c57, RiotSkin4CN-Download (https://s-cd-4307-general.oss.dogecdn.com/riotskin4cn/live.json) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RiotSkin4CN-Download is back up in 2ff9083.


text:
🛑 RiotSkin4CN-Download is down

In 0569492, RiotSkin4CN-Download (https://s-cd-4307-general.oss.dogecdn.com/riotskin4cn/live.json) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RiotSkin4CN-Download is back up in 9ce9863.


text:
include Dance Helix (alpha vscode extension)

https://marketplace.visualstudio.com/items?itemName=silverquark.dancehelix
An extension to Vscode that simulates the Helix editor!

Added in
https://github.com/rajasegar/awesome-helix/commit/5d996c8978793698b383c93d36c2e8f993f03014

repo: rajasegar/awesome-helix


text:
is darwin or ios possible ?

I always hit "undefined: getSurfaceDescriptor" issue. See below.
``´
➜  gio-windowing git:(main) ✗ go build .
go: downloading github.com/rajveermalviya/gio v0.0.0-20220407081512-669757591f4c
go: downloading golang.org/x/image v0.0.0-20210628002857-a66eb6448b8d
go: downloading gioui.org/cpu v0.0.0-20210817075930-8d6a761490d2
go: downloading gioui.org/shader v1.0.6
go: downloading golang.org/x/exp/shiny v0.0.0-20220328175248-053ad81199eb
go: downloading github.com/benoitkugler/textlayout v0.0.10
go: downloading golang.org/x/exp v0.0.0-20220328175248-053ad81199eb
go: downloading github.com/go-text/typesetting v0.0.0-20220112121102-58fe93c84506
go: downloading github.com/gioui/uax v0.2.1-0.20220325163150-e3d987515a12
github.com/rajveermalviya/go-webgpu/examples/gio-windowing
./main.go:70:34: undefined: getSurfaceDescriptor
➜  gio-windowing git:(main) ✗ cd ..
➜  examples git:(main) ✗ cd triangle
➜  triangle git:(main) ✗ go build .
go: downloading github.com/go-gl/glfw/v3.3/glfw v0.0.0-20220320163800-277f93cfa958
github.com/rajveermalviya/go-webgpu/examples/triangle
./main.go:52:32: undefined: getSurfaceDescriptor
➜  triangle git:(main) ✗ cd ..
➜  examples git:(main) ✗ cd gio-windowing
➜  gio-windowing git:(main) ✗ gogio -arch arm64,arm,amd64 -target android .

https://github.com/rajveermalviya/go-webgpu/blob/main/.github/workflows/ci.yml#L25 prevents CI testing darwin ?

Hey @rajveermalviya
Yeah i saw the _linux.go version. and started to make _darwin version, but I could not work it out even with https://pkg.go.dev/github.com/rajveermalviya/go-webgpu/wgpu#SurfaceDescriptorFromMetalLayer. Sorry but i mostly do basic http stuff in golang.
DO you think you can write that code ?
I can test it at least locally here on my intel mac.

this might work for CI for Darwin and IOS, so i asked here: https://github.com/nektos/act/discussions/1143

I can test it at least locally here on my intel mac.

I have created a PR #115 which adds support for glfw based triangle example.
Would appreciate if you can test it.

it works
➜  rajveermalviya git clone git@github.com:rajveermalviya/go-webgpu.git -b darwin-examples
Cloning into 'go-webgpu'...
remote: Enumerating objects: 1513, done.
remote: Counting objects: 100% (139/139), done.
remote: Compressing objects: 100% (76/76), done.
remote: Total 1513 (delta 70), reused 118 (delta 60), pack-reused 1374
Receiving objects: 100% (1513/1513), 914.69 MiB | 7.06 MiB/s, done.
Resolving deltas: 100% (817/817), done.
Updating files: 100% (70/70), done.
➜  rajveermalviya ls
go-webgpu
➜  rajveermalviya cd go-webgpu
➜  go-webgpu git:(darwin-examples) cd examples
➜  examples git:(darwin-examples) cd triangle
➜  triangle git:(darwin-examples) go build .
➜  triangle git:(darwin-examples) ✗ ./triangle
[go-webgpu] [Warn] Surface does not support present mode: Mailbox, falling back to FIFO
[go-webgpu] [Warn] Surface does not support present mode: Mailbox, falling back to FIFO
[go-webgpu] [Warn] Surface does not support present mode: Mailbox, falling back to FIFO
[go-webgpu] [Warn] Surface does not support present mode: Mailbox, falling back to FIFO

i can compile and run gio ios also if need be.

it works

thanks for testing :tada:

i can compile and run gio ios also if need be

it will first require ios builds of wgpu-native static libraries. will surely try too add them

cool. I can't believe you were able to code the darwin triangle without a MacOS to try it on. Impressive dude !!

mostly thanks to zig cc's magic.
setting correct env for gopls & it provides linting in vscode.
it only goes as far as being able to build for macos on linux. still need a mac to run/test the binary.

thanks - i am def going to check out that link when i have a second... I heard of zig, but never had a reason to look into it deeper.
Still amazing either way.

hey @rajveermalviya
I just noticed there is an IOS lib now.

Hey @rajveermalviya If you need MAC Testing again just let me know.

repo: rajveermalviya/go-webgpu


text:
Run test suite as part of CI flow

We'll want to keep an eye on practicality of this basic setup with how
slow the test suite might be.
If things are too slow and hurting our dev speed we can tweak the setup
to us to decouple the tests from the rest of the CI flow.

@DonGambas mind putting some 👀  on this. It's running just the TS library's tests for now. Takes a while, but actually isn't that much slower than how long it takes for me locally.

this looks great, and love that we'll run these as part of the CI now. Also the broader investigation gives us a good basis for which to further improve the ts library tests and the cli tests.

authors: DonGambas rweald

repo: rally-dfs/rly-ts


text:
traverse()

Being a proposal for an analogue to prop() which traverses nested objects
The following is a proof-of-concept meant to facilitate discussion, as this implementation is not necessarily the most performant. While I noticed there were other, more... verbose proposals, this one aims to be practical, and adhere to the existing design and implementation principles as much as possible. It should compose mostly the same as prop() in most cases.
If desired, I can poke at it with JSPerf and submit a proper PR with unit tests & error-checking.
// import { curry, is, map, pipe, prop } from "ramda";

var traverse = curry(function(props, object) {
  return pipe.apply(null, map(prop, props))(object);
});

var o = {
  foo: {
    bar: { baz: "nested value" }
  }
};

console.log(traverse(['foo', 'bar', 'baz'], o)); // => "nested value"
console.log(traverse(['foo', 'bar', 'baz'])(o)); // => "nested value"
console.log(traverse(['foo', 'bar', 'bad'])(o)); // => undefined
console.log(traverse(['foo', 'bar', 'bad', 'worse'])(o)); // => Error

Although this admittedly runs counter to the philosophy, I wanted to include an alternative implementation for the sake of completeness, end-user convenience, and because the implementation is so damn simple:
var traverse = curry(function(props, object) {
  return pipe.apply(null, map(prop, is(String, props) ? props.split('.') : props))(object);
});

console.log(traverse(['foo.bar.baz'], o)); // => "nested value"

Thanks for your time & consideration.

This is similar to R.path.

Wow, how have I never found this before!?
Well, thanks, I feel sheepish, haha.

Well this is Ramda, so i would hope people are comfortable feeling sheepish. :wink:

Well, thanks, I feel sheepish, haha.

The funny thing is that after almost a year of lots of public activity on this project, that may be the first time I've heard someone use that line.  Not that there haven't been plenty of other sheep-related jokes, mind ewe.
:smile:

Wow, I did not even realize I set that one up. :+1:

Damn, I just assumed it was intentional!

I'm sure there was some kind of subliminal influence. :wink:

Is this equivalent to:
const getKey = (...path) => {     const levels = R.map((level) => {         return R.prop(level);     }, R.reverse(path));     return R.compose(...levels); }

Is this equivalent to:
const getKey = (...path) => {
    const levels = R.map((level) => {
        return R.prop(level);
    }, R.reverse(path));
    return R.compose(...levels);
}

Yes, see the docs for R.path.

authors: CrossEye buzzdecafe davidchambers nateabele sidjain26

repo: ramda/ramda


text:
align lensPath with lensIndex by supporting negative indeces

see #2667

This looks good to me.  I am not really a fan of supporting negative indices, but I would rather maintain the consistency.
Anyone else?  @ramda/core?

added some tests + docs

Thanks! I added a test that should address your feedback.

Looks good to me.  :herb:
@Bradcomp?


text:
Futures Data (CME, EUREX, etc)

Dear Community,
Is it possible to supply QuantStats with external futures data saved in .csv or .xlsx format.
Typical data providers (e.g. YFinance)  don´t have data I'm looking for (mostly bond futures at CME, EUREX).
Kind Regards
Jose

Hi @jortiz12,
Yes this is possible. I would also recommend you have a look at alternatives that could be used as a substitute to make life a bit easier (e.g. there might be ETFs that track the same instruments?). However, if you are after a higher level of accuracy you can simply download the data for the timeframe you are after (direct from CME, EUREX, etc), save it to .csv or .xlsx format (example below uses csv), place this file in the same folder as your python script, import that into your script and use pandas to convert the datetime string column to real datetime and capture the percentage change of the instrument daily over that time. An example of this shown below.
import quantstats as qs
import pandas as pd

instrument_daily_close_price = pd.read_csv("instrument_daily_close_price.csv")
instrument_daily_close_price['Date'] = pd.to_datetime(instrument_daily_close_price['Date'], format='%d/%m/%Y')
instrument_daily_close_price['pct_change'] = instrument_daily_close_price['Price'].pct_change()
instrument_daily_close_price = instrument_daily_close_price[['Date','pct_change']]  # Drop out all unrequired columns
instrument_daily_close_price = instrument_daily_close_price.set_index('Date')
instrument_daily_close_price_series = instrument_daily_close_price.squeeze()    # Convert to pandas series
instrument_daily_close_price_series.index = instrument_daily_close_price_series.index.tz_localize(None)

comparison_instrument = qs.utils.download_returns('SPY')    # Download historical prices for benchmark.
comparison_instrument.index = comparison_instrument.index.tz_localize(None)
qs.reports.html(instrument_daily_close_price_series, comparison_instrument, output=1, download_filename="output.html")

Let me know if this answers your question?
Kind regards,
git-shogg

Check out https://github.com/Lumiwealth/quantstats_lumi, which is being updated regularly. We are a fork of this library that is being maintained by Lumiwealth

authors: git-shogg grzesir jortiz12

repo: ranaroussi/quantstats


text:
RKE2 - Root OCID tenancy compartment error

Using the root OCID compartment tenancy fails with "A valid compartment OCID is required". This may be a repeat of #13.
Versions
Rancher: v2.6.4
OKE: v1.7.1
OCI: v1.1.0
Screenshot

PR: https://github.com/rancher/ui/pull/4849

authors: ITestInProd jlamillan


text:
Persitency for live iso image how-to ?

Is your feature request related to a problem? Please describe.

"C.I.R.R.U.S. : Cloud Iac Reservoir de Ressources Unifiées pour Salles de tp"
CIRRUS will be a k3s IPv6 only cluster dedicated to computer science and network educational labs.
On cirrus all cluster nodes, (bare metal or cloned VM) k3s server as well as agent, will  share the same immutable unique live iso image.

cirrus-os is a c0S-toolkit derivative called abcd4cirrus-os : alpine bbased cOS derivative for cirrus-os
cirrus node unique image is an immutable live iso file built with cOS-toolkit

All tools and services like k3s will be embedded on that unique shared live iso image. No service install nor OS updates or upgrades need to be done, even using that neat air-gap update cOS mode based on  elemental, on each node when 1st booting.
Node updates will be done by simply restarting node on a new iso image, eventual rollback only need to point to the previous iso image.  On a cluster with N nodes, I don't want to install nor upgrade N times, even with an automated airgap mode facility, when N will scale up.
So node customization and persistent data (config files, network interfaces conf, k3s state or log files)  need to be overlayed on COS_PERSISTENT labeled block device of cos-toolkit facility on a auxiliary block device (usb stick or other), host SSD and disks will be fully dedicated to  a distributed storage backend (probably Rook/ceph or Longhorn based). I don't want to use node disk or partition to locally install cos-derivative.
Describe the solution you'd like

A simple way to activate cOS persistence on an auxiliary labeled COS_PERSISTENT block device when live iso booting like some common live demo distrib
(similar to what I tried to to do with auxiliary DELTA disk on k3os, see https://github.com/rancher/k3os/discussions/832 for a similar feature request)
Describe alternatives you've considered

Trying to activate persitency with cOS cloud-init facility with no success. What do I miss in the doc ? I must say I'm a newby about cloud-init.

adding persistency in my image following system/immutable-rootfs and build ISO
customize grub-cfg or syslinux.cfg to remove rd.cos.disable```` kernel parm But it doesn't work, live boot initamfs step timeout entering in "emergency mode"..."Press Enter for maintenance``` which is a symptom of dracut failed to determinate rootfs

Probably not the good way...
What I understand, nested alpine squashfs image has probably cOS presistency through /system/oem or  /run/cos/cos-layout.env files from the build but iso primary image and its initramfs has no support for cloud-init persistency directive.
Additional context

Managing  toram boot parameter would be a plus.

Hi @j-landru the project looks really great, and thanks for the feedback!
This should be already possible, and it is documented here: https://rancher-sandbox.github.io/cos-toolkit-docs/docs/reference/packages/system-immutable-rootfs/#configuration-with-an-environment-file
To configure the booting layout add a cloud config file in /system/oem, for example /system/oem/99-persistency.yaml (not tested) in the image:
name: "Configure persistent dirs bind-mounts"
stages:
  rootfs.after:
    - if: '[ -f "/run/cos/live_mode" ]'
      name: "Layout configuration"
      environment_file: /run/cos/cos-layout.env
      environment:
        VOLUMES: "LABEL=COS_OEM:/oem LABEL=COS_PERSISTENT:/usr/local"
        OVERLAY: "tmpfs:25%"
        RW_PATHS: "/var /etc /srv"
        PERSISTENT_STATE_PATHS: >-
           ....
        PERSISTENT_STATE_BIND: "true"

@mudler thank you for your help, thank you for your help, sorry for this late feedback. I am in a lectures period and my project activity is taking a back seat...
Your /system/oem/99-persistency.yaml example is the good way to proceed for live mode persistency.  My first tries was unsuccessful;  hang during initramfs step and timeout in rescue mode (Entering emergency mode), no rootfs found. Spent some time before debugging my mistake, as I stupidly modified label:stanza  in myiso.yaml``` file, setting it back to its COS_LIVE original value did the trick.
I've now persistent live mode overlayed on a secondary COS_PERSISTENT labeled block device.
Persistent dirs and files survive between reboot in /home or /root dirs. It also work for /etc subdirs like /etc/runlevels (it's an Alpine openrc init so service starting are managed as entries under /etc/runlevels subdirs ).
But I don't explain why persistency doesn't work for my customization in /etc/conf.d dir, like my keyboard settings managed in loadkmap file. Files in that specific location seem to roolback to their original state between reboot. What am i doing wrong or miss in the RTFM ? as I set the whole /etc dir in PERSISTENT_STATE_PATHS: stanza of my 99-persistency.yaml file.

sorry for the noise...
```/etc/conf.d````  is persistent. I made a new test, setting a persistent test file in that subdir. This fie "boot survive". So my keyboard conf persistency problem is elsewhere, not a cos-persistency issue.

Hey @j-landru was this solved? Did you encountered any more issues related to this card or can we proceed to close it?
Thanks!

@Itxaka Yes, this card can be closed. Excuse me not to have react sooner

No probs, thanks for answering!

authors: Itxaka j-landru mudler

repo: rancher-sandbox/cOS-toolkit


text:
Need more resilience for managing the rancher install

If some of the helm charts are still installed, both install and uninstall will fail
If k8s is in an ERROR state, it should let the user know that (beyond the red-colored icon), and offer to fix whatever the problem is rather than do a reset.

As we are no longer going to offer Rancher as part of the experience I'm going to close this issue.
If we bring it back later in some form we can bring this up again.

authors: ericpromislow mattfarina

repo: rancher-sandbox/rd


text:
Fix volumeDriver to pool to host allocation bug

If a volumeDriver is specified on an instance and that volumeDriver
resolves to a pool, allocation should be restricted to hosts belonging
to that storage pool.

LGTM

Addresses rancher/rancher#2725

authors: cjellick ibuildthecloud

repo: rancher/cattle


text:
multiple path for volume

Hello all
First thanks for your opensource project.
How can I run convoy vfs/nfs daemon with multiple specified path for saving volumus?
thanks a lot

What do you mean by multiple specified path? Currently one Convoy daemon only support one vfs.path a.k.a. one specific path.

@yasker  I think the original reporter was asking if it is possible to have multiple convoy daemons running, each with its own storage location.
For example, we have 2 local storage pools, one backed by fast SSDs and the other by slower HDDs. Ideally we could use multiple instance of the convoy daemon (or a single instance configured to support backends) to store some volumes in one pool and some volumes in another.
Something like:
--volume-driver=convoy-pool1
--volume-driver=convoy-pool2

@Ramblurr Sorry, we haven't provided such functionality yet. I think the multiple instance usage is more doable, and different locations can be referred as different driver names.
It should be possible to get it done without modifying the core code, by using different directories as the configuration root and different name in the volume plugin spec provides to the Docker.

authors: Ramblurr fahimeh2010 yasker

repo: rancher/convoy


text:
Unlabeled selects missing elements in view only

When an unlabeled select is in view mode it looses it's dropdown and select options.
edit:

view:

I could set a min height but wanted this to be tested and reviewed by a dev before doing so.
/design-system/form-controls

@lvuch and I looked at this this afternoon and I believe she will be putting the fix in.

authors: lvuch westlywright

repo: rancher/dashboard