setup inference-manager-server deployment

Btw, if the plan is to put this in front of inference-manager-engine, we need to remove the ingress from inference-manager-engine?

Btw, if the plan is to put this in front of inference-manager-engine, we need to remove the ingress from inference-manager-engine?

yes, I think so


Update cache.py

query with Feature object use disk_cache may cause error，example
D.feature([symbol], [Feature('close')], disk_cache=1)

It looks great! Thanks


Enhancements for the SD WQE

Coverage decreased (-2.3%) to 70.188% when pulling 4f8065c70a2d130949335289f008437f986de3dc on phobson:SD-WQE-enh into a1a5ad46e429a41fa97dcd763899578130d816b2 on Geosyntec:master.

Coverage decreased (-2.3%) to 70.188% when pulling 89415aa5cace70672947f76ac125000ef544a4fc on phobson:SD-WQE-enh into a1a5ad46e429a41fa97dcd763899578130d816b2 on Geosyntec:master.


2D multiplayer sync?

I have a game idea stuck in my head that depends on 2D multiplayer physics.
But how do you think one would implement this with less bandwidth close to how Roblox does live physics step-by-step? Surely it would be more than just remote-events.

As for now, Firing events is the only way, if the movements are basic, the bandwidth used won't be Huge. if you just fire one event with a metatable inside containing the info you won't have to spam multiple events every tick.
hope this helps

As for now, Firing events is the only way, if the movements are basic, the bandwidth used won't be Huge. if you just fire one event with a metatable inside containing the info you won't have to spam multiple events every tick. hope this helps

Okay, so what about colliding with the real 2D world if your 2D character is desynced from the server's physics?
Roblox (in 3D) can handle reactions to collisions of unanchored parts from players moving or one of their projectiles. Recalling from BONK.io, you can collide with other players by force and they'll fly right away.

I have never tried this in the past, so I can't say much. "Server-sided" UI itself is quite difficult to get working with precision, which can only be done through events as Dsioul said. There are a few games I have seen on Roblox like a flappy bird clone that was made with UI and supported multiplayer. I'm not sure whether they took a path other than events but you could try with events first and then try to slim down bandwidth as much as you can perhaps?


Make cursor not-allowed when hovering groups where task cannot be dro…

Cursor is now type "not-allowed" when hovering task groups that aren't allowed

Great points, added all your suggestions 👍 I also fixed the bug where not-allowed cursor didn't show up correctly when hovering over a single task (the bug which showed up in the demo). Css was just missing one class from the :not pseudo class
&.draggingSomething:not(.loading) { ... to
&.draggingSomething:not(.loading, .dropDisabled) { ...


Failed to send policy update as monitor notification

Cilium master during v1.10 dev cycle (but likely affects v1.9.0).
I started Cilium under microk8s and hit this warning:
level=warning msg="Failed to send policy update as monitor notification" error="monitor agent is not set up" policyAddRequest=7ae059f5-2dfc-11eb-936b-54e1ad14ebc0 policyRevision=2 subsys=daemon

This seems like a race condition between policy processing and monitor server startup, likely a red herring but if users observe it they may think that it is meaningful when it is not.
I suspect this was introduced by commit d543d418bde3ad55e8759e9f28941f830bfc94bb (/cc @gandro), as previously we didn't check the error in Daemon.policyDelete(...).

To be clear, I don't believe this is a real issue, my main concern is that it pollutes the logs with a warning when otherwise everything appears to be fine. Fixing it will likely involve digging into the daemon startup logic and understanding whether to either conditionally skip sending events like this, somehow queueing them, or forcing policy handling to wait on monitor startup (probably not ideal).

I suspect this was introduced by commit d543d41 (/cc @gandro), as previously we didn't check the error in Daemon.policyDelete(...).

Yes, looking at the changes I did around that time, that seems a correct assessment: My commit made made this into a warning (whereas before, it was silently ignored). I think we could probably extract the fmt.Errorf("monitor agent is not set up") as a ErrMonitorNotReady variable or something and conditionally ignore it.
To me, the question overall is if this is something that we should only handle in the policy update case, of if we should generally either drop or queue any agent notifications if the agent is not yet set up.


Sounds to be added into multiple mods

Here is a list of sounds to be added in some mods :

[X] https://www.cloudcorner.com/file/fb7fffc8fa5d3d5bcf1f31150a95a421 -> deathpeople1 -> death_messages , played for other players
[X] https://www.cloudcorner.com/file/02e3834f1908b6900bb2a3f196802253 -> achievement_get -> achievement , played when players win an achievement
[X] https://www.cloudcorner.com/file/0ca285361a8531f216652355edbc258b ->deathplayer1 -> death_messages , played when a played dies
[X] https://www.cloudcorner.com/file/1c610ce1bbeed53e624ff32b033554f2 -> randomsounds -> We don't know

We should talk about the use we will have of them last one, or maybe discard it, on IRC or there.

Added 93b83cff8dda6b1d649d6b342b16864d76ecd0d9


CLS recording "expected layout shifts"

We have implemented Web Vitals code for our client, on amerigas.com.  In our pre-production testing, we found an issue with the CLS metric.  CLS is supposed to be set on “unexpected layout shifts” on the page, but is being set on “expected” layout shifts, including those listed below:

The Alert header opening and closing;
Closing FAQ sliders;
The sticky header “sticking” and “unsticking”;
Opening a new browser tab and returning to the page (this appears to happen only on Macs);
Chrome autofill values being displayed after cursor focus on a form field.

This is artificially inflating the CLS metric for our client, and we are concerned that this will negatively affect our client's Web Vitals score and SEO.

Can you provide more details? It's not clear to me whether the examples in this list involve user interactions. If they do, can you please explain exactly what the user interaction was?
Also, in case you're not aware, the interactions used to consider a shift "expect" are tap, click, and keypress. See this callout on web.dev/cls:

The hadRecentInput flag will only be true for discrete input events like tap, click, or keypress. Continuous interactions such as scrolls, drags, or pinch and zoom gestures are not considered "recent input". See the Layout Instability Spec for more details.

Philip,
Thanks for the reply.  What I noted are interactions, explained below, and can be replicated on this page, among others.  In testing the Web Vitals code, we had the values set in console.log, and saw that CLS was set on each of these actions.

Closing FAQ sliders - click on FAQ to open, then click to close
The sticky header “sticking” and “unsticking” - scroll up and down the page; also, open a meu drop down (e.g., About Propane) and scroll down the page
Chrome autofill values being displayed after cursor focus on a form field - place cursor in the Search All Support box with autofill turned on

Closing FAQ sliders - click on FAQ to open, then click to close

I think in this case the API is functioning correctly. The problem here is that the animation is too slow, so the shifts happening more than 500ms after the user clicks are in fact being reported as "unexpected".
See my console output, and notice the hadRecentInput flags:

To fix this, you have two options:

Switch to only transitioning the transform property (recommended in general).
Make the transition faster.

Honestly, in my opinion I'd recommend doing both. The first part of the transition does feel a bit slow to me.

The sticky header “sticking” and “unsticking” - scroll up and down the page; also, open a meu drop down (e.g., About Propane) and scroll down the page

Hmm, this looks like it might be a bug in Chrome. Interestingly, we had another report today for what looks to be the same issue. Here's the crbug to track it:
https://bugs.chromium.org/p/chromium/issues/detail?id=1150657

Chrome autofill values being displayed after cursor focus on a form field - place cursor in the Search All Support box with autofill turned on

I can't actually reproduce this issue, as no autofilling is happening for me.

I'm going to close this issue as I think none of the things reported are a problem with the web-vitals library, but rather concerns with the Web APIs. If you feel strongly that these APIs are affecting the metric quality, I'd recommend filing CR bugs (crbug.com) to report the issues rather than reporting them here.


fix for typo in opts var name in zoom settings

This will avoid this:
ReferenceError: opt is not defined
    at module.exports (.../google-maps-image-api-url/index.js:10:45)

Thanks for this. Merging.

NP Thank you guys for this pubic and free module


Using different config for sub-levels

Hi
Is it possible to use a different context for rendering sub-level menus? I have a horizontal navigation which only renders first level and a second navigation which renders level 2. But level 2 must have a different classes for <ul> list.
.navbar
  .navbar-inner
    .container
      = render_navigation :level => 1

(...)

  .sidebar
    = render_navigation :level => 2,:context => :dashboard # :context has no effect here.

I can always do it with jQuery as it was suggested in Wiki, but I feel like there should be possibility to separate styles for levels rendered in different parts.

You can set the dom-class and dom-id of each level independently:
...
primary.dom_id = 'primary-id'
primary.dom_class = 'primary-class'
primary.item :key_2, 'name', url, options do |sub_nav|
  sub_nav.dom_id = 'secondary-id'
  sub_nav.dom_class = 'secondary-class'
  sub_nav.item :key_2_1, 'name', url, options
end
...

The specified attributes should be applied on the generated ul-element if you're using the list renderer. Let me know if I'm wrong.
Does this help?

I think andi's solution should work for your use case - if not, perhaps you could author a custom renderer to more closely fit your needs.
Cheers,
Mark.

Thanks @andi, completely missed that!


Upgrade failed, not booting anymore

file system trashed. vital file not found. it happens unfortunately. power loss? did you cycle a reboot? it looks like it died in the middle of an update...

You might be able to call opnsense-bootstrap but need to configure Inernet manually from the shell. Vital files seem to be missing so who knows if that even still works. I can only suggest to import and reinstall. It has the benefit of rebuilding the file system. If it's a VM don't know, but as hardware I would be worried about the disk health.
Cheers,
Franco

Getting a cert error on attempted bootstrap.

use -i parameter

Thank you for the help.  Probably an underlying issue on the host.  I should still with esxi which I understand better.


reduceObj ?

How would you guys feel about reduceObj ?
In Clojure there is reduce-kv https://clojuredocs.org/clojure.core/reduce-kv.
It feels usable but maybe I'm overlooking some smart way of using existing function(s) in ramda to achieve the same thing?

uh-oh

Interpreting pithy warnings from @buzzdecafe sometimes takes a little guide:
#257, #364, #546, #625, #656, #920
... and probably others.
Of course you can always just do this:
var foldObj = R.useWith(R.reduce, R.identity, R.identity, R.values);
foldObj(R.add, 0, {a: 1, b: 2, c: 3}); //=> 6

Ahh, sorry, I should have searched a bit more before posting.
Thanks for links! ...and implementation suggestion!

No worries.
My chief concern is with code like this:
var diff = function(a, b) {return b - a;},
    obj1 = {a: 1, b: 2, c: 3},
    obj2 = {b: 2, a: 1, c: 3};
_.reduce(obj1, diff); //=> 2
_.reduce(obj2, diff); //=> 4

ES6 will at least standardize this, so that we don't have to worry about this oddity being implementation-dependent.  But it's still fairly nasty.

ES6 will at least standardize this, so that we don't have to worry about this oddity being implementation-dependent. But it's still fairly nasty.

ES6 standardizes the existing de facto behavior, the one you disagree with. By ES6, obj1 and obj2 should be iterated differently.

ES6 will at least standardize this, so that we don't have to worry about this oddity being implementation-dependent. But it's still fairly nasty.

Yap, ES6 standardizes the existing de facto intuitive behavior, the one you disagree with. By ES6, obj1 and obj2 should be iterated differently.

I don't love this iteration order, it's true.  It's made worse by exceptions for small integers:
Object.keys({a: 1, b: 2, 10: 3}); //=> ["10", "a", "b"]

But that's at most a minor point in my objection to including a foldObj function.  Ramda is, of course, about functional programming.  And one of the key tenets of FP is that one can at any time substitute equivalent expressions for one another without changing the behavior of a program.  By most definitions (including Ramda's, Underscore's, lodash's, and that of the structured cloning algorithm) these two are considered equal: {a: 1, b: 2, c: 3} and {b: 2, a: 1, c: 3}.  And yet I could not legitimately substitute one for the other in foldObj and get the same result.
That's the fundamental problem.
This is not restricted to object literals, either.  It goes much deeper.  FP is mostly about evaluating expressions, and the order of evaluation should never matter.  But now these this code:
var obj = {};
obj.a = 1;
obj.b = 2;

and this one:
var obj = {};
obj.b = 2;
obj.a = 1;

have fundamentally different behavior.
Ramda does not solve this, of course, and can fall prey to the same sorts of issues when it does anything that converts an object into its component parts: keys, values, etc.  Had we a choice, when implementing these in our ES3-ES6 environments, we might we have returned something more set-like from such calls, but there is nothing readily available.  (Some pseudo-set like {a: true, b: true, c: true} just kicks the can further down the road without solving anything.)  But in returning something like this, at least it should be reasonably clear that we're returning a representation of the object, and not the representation.  It's a compromise, sure, but it seems a reasonable one.
But most fundamentally, the objection goes to why.  It's pretty clear what folds on lists do.  They can be described in a single sentence, and examples are straightforward.  I can't describe what a fold on an object is, without first resorting to some sort of description of the extraction of an iterable list of keys.  That tells me that any time one really wants to fold a JS object, one really should perform such an extraction manually first.
It seems to tell us that foldObj is not a useful abstraction on is own right.

I don't love this iteration order, it's true. It's made worse by exceptions for small integers:

It's integer indexes (large or small), in ascending numeric index order, then non-indexes, in property creation order, then symbols in creation order.

By most definitions (including Ramda's, Underscore's, lodash's, and that of the structured cloning algorithm) these two are considered equal: {a: 1, b: 2, c: 3} and {b: 2, a: 1, c: 3}

Not by structured clone, I think you mean by its deep equiv method which isn't really a great example because as I've explained before it's a bit loose on equivalence as it detects primitives and objects as equiv, checks index only values for arrays, etc.

And yet I could not legitimately substitute one for the other in foldObj and get the same result.

You wouldn't expect one to understanding object iteration order.

I can't describe what a fold on an object is, without first resorting to some sort of description of the extraction of an iterable list of keys.

The same could be said for any iteration like array iteration.

It seems to tell us that foldObj is not a useful abstraction on is own right.

The repeated requests and its support in other libs kind of counter that.

I don't love this iteration order, it's true. It's made worse by exceptions for small integers:

The iteration order is specified

Yes, it's that specification I don't particularly like.  But that's really not my major objection here.  The real problem is at the fundamental level of what such a function should do.

And yet I could not legitimately substitute one for the other in foldObj and get the same result.

By understanding object iteration order you wouldn't expect one to be substitutable for the other.

So would you suggest Ramda change equals, find a foldObj that doesn't conflict with equals or abandon the idea of such a law as equal(obj1, obj2) ==> equals(foldObj(fn, init, obj1), foldObj(fn, init, obj2))?  We'd have to do at least one of those.

I can't describe what a fold on an object is, without first resorting to some sort of description of the extraction of an iterable list of keys.

The same could be said of any iteration, like array iteration.

I don't think so.  We can easily use the phrase "in order" in the description of folding a list.  That phrase does not make a great deal of sense for the HashMaps/Dictionaries that are JS objects, even if the specification does now determine a property iteration order..

It seems to tell us that foldObj is not a useful abstraction on is own right.

I donno, repeated dev requests and its support in other libs kind of counter that a bit.

Repeated requests is why we've spent as much time on this as we have.  But we can find no reasonable way to fulfill these requests that fit with Ramda's ideas.  Support in other libs is not much of a motivator.  It's always interesting motivation (or its converse), but if other libraries were built on the principles we wanted, or were likely to change the way we wanted them to, we wouldn't have started our own.

I see reduce methods as a swiss army knife. It can be an invert, mapKeys, mapValues, pick, omit, etc.

We try very hard not to let such implementation concerns steer our public API.  Even if we used an internal foldObj for such functions -- Ramda has equivalents for all those but mapKeys -- we still wouldn't expose it unless it made sense as a public function.  All these functions return new objects, where key order doesn't matter, so iteration order also doesn't matter.  But that's simply not true in a general-purpose foldObj.

So would you suggest Ramda change equals, find a foldObj that doesn't conflict with equals or abandon the idea of such a law as equal(obj1, obj2) ==> equals(foldObj(fn, init, obj1), foldObj(fn, init, obj2))? We'd have to do at least one of those.

Naw, I'd say they're different and one doesn't have to support the other. equals is about loose equivalence and foldr is object iteration and accumulators.

I don't think so. We can easily use the phrase "in order" in the description of folding a list.

Naw you still have to define the order 0 through length or length to 0.

But we can find no reasonable way to fulfill these requests that fit with Ramda's ideas.

Then maybe Ramda's ideas need adjustments.

All these functions return new objects, where key order doesn't matter, so iteration order also doesn't matter. But that's simply not true in a general-purpose foldObj.

You shouldn't be concerned with key order for a general-purpose foldObj.

I'd say they're different. equals is about loose equivalence and foldr is object iteration and accumulators. One doesn't have to support the other.

So then you'd suggest that we abandon my proposed law?  My preference is to simply abandon the idea of foldObj, as I don't see it making a lot of sense.

I don't think so. We can easily use the phrase "in order" in the description of folding a list.

You still define the order. Be it 0 through length or length to 0.

Lists have a natural iteration order.  And lists are the fundamental data type Ramda operates on.  Because there is no built-in list type, we settle for dense arrays as a reasonable approximation, but we still think of the structures as LISP-style lists.  'length to 0' is no more reasonable for lists than 'odds-indices, increasing, then even-indices, decreasing'.  But this is reasonable for a list:
iterate [] = <complete>
iterate head:tail = <process head> then <iterate tail>

But we can find no reasonable way to fulfill these requests that fit with Ramda's ideas.

Then maybe Ramda's ideas need adjustments.

That's precisely the attitude of some other libraries that made me want to create something like Ramda.  I would rather write a library that serves my needs in a consistent fashion than one which caters to whatever happens to be popular.  Whatever popularity Ramda has achieved has been based, I believe, on it's strict adherence to a functional programming philosophy, and our mantra of being a "practical, functional library for Javascript developers."

You shouldn't be concerned with key order for a general-purpose foldObj.

Yes you should.  If the function supplied is not commutative, then a foldObj that iterates in an arbitrary order (and yes, the order given by the spec is for these purpose entirely arbitrary) will not allow you to substitute perfectly equivalent objects that happen to have had their properties defined in a different order.  This is very much contrary to the spirit of FP.

So then you'd suggest that we abandon my proposed law? My preference is to simply abandon the idea of foldObj, as I don't see it making a lot of sense.

Yap, I think it's reasonable to expect foldObj to operate differently than a loose equivalence method.

'length to 0' is no more reasonable for lists than 'odds-indices, increasing, then even-indices, decreasing'.

In this case I was thinking of reduceRight or lastIndexOf which iterate an array from right to left. In much the same way a plain object can be iterated from the left or the right.

I would rather write a library that serves my needs in a consistent fashion than one which caters to whatever happens to be popular.

I think consistency is a cherry-picked in Ramda.

Whatever popularity Ramda has achieved has been based, I believe, on it's strict adherence to a functional programming philosophy, and our mantra of being a "practical, functional library for Javascript developers."

I think it had more appeal when it was a bit simpler.

Yes you should.

Naw.

This is very much contrary to the spirit of FP.

You've made practical exceptions in Ramda in the past I think this falls into that category or else

I was thinking of reduceRight or lastIndexOf which iterate an array from right to left. In much the same way a plain object can be iterated from the left or the right.

reduceRight on lists is about order of evaluation, not iteration order:  http://foldr.com/,  http://foldl.com/.  And for lists, lastIndexOf is at its core a composition of reverse and indexOf.  Granted an array implementation might give you a more performant way to achieve this, but that's the essence.  And reverse is fairly simple too:
reverse xs = rev xs []  where
  rev (x:xs) acc = rev xs (x:acc)
  rev []     acc = acc

I would rather write a library that serves my needs in a consistent fashion than one which caters to whatever happens to be popular.

It's my understanding that Ramda's consistency is already cherry-picked for practicality's sake.

I suppose one could put it that way... if one was feeling unkind.  I would say that we ever play a balancing game between purity/consistency and pragmatism.

I think [Ramda] had more appeal when it was a bit simpler.

Sometimes I think that too.  But mostly I'm happy and excited by the growth of the library.  The additional features rarely affect users who are not intent on using them, but they offer a great deal of power to users who choose to try them out.

This is very much contrary to the spirit of FP.

Practical exceptions have been made for Ramda in the past I think this falls into that category.

I'm hard-pressed to come up with examples where we've sacrificed core FP principles on our public API.  We make all sorts of concessions to reality in our implementation, for various pragmatic reasons.  But that is quite different.  Could you please share details, if you have examples?
However, even it we've done so in the past, why is this an important enough function to merit such an exception?  You mention how you use it to implement a number of Object functions.  Ramda implements most of those functions too, without using foldObj.  I'm having a hard time seeing any reason to think of this as a high priority.

reduceRight on lists is about order of evaluation, not iteration order

It boils down to iteration order and in much the same way as object iteration.

I would say that we ever play a balancing game between purity/consistency and pragmatism.

Word games?

But that is quite different. Could you please share details, if you have examples?

I believe that would be @davidchambers area of expertise. If there's an angle to be more FP he's found it and opened an issue or discussion here on it.

I'm having a hard time seeing any reason to think of this as a high priority.

The priority is yours to set. If there's demand, and I think there's a fair amount, it's an indicator of a feature gap for your users.

reduceRight on lists is about order of evaluation, not iteration order

It boils down to iteration order

Well no:
reduce(add, 0, [1, 2, 3, 4, 5]);      //=> ((((0 + 1) + 2) + 3) + 4) + 5
reduceRight(add, 0, [1, 2, 3, 4, 5]); //=> 1 + (2 + (3 + (4 + (5 + 0))))

This different order of evaluation can lead to all sorts of different behaviors/performance characteristics.  reduce is available for tail-call optimization.  reduceRight can handle lazy/infinite lists.
Moreover, they can have different results:
var fn = (acc, val) => acc < 15 ? acc : acc / val;
R.reduce(fn, 20, [1, 2, 3, 4, 5]); //=> 10
R.reduceRight(fn, 20, [1, 2, 3, 4, 5]); //=> 4

and in much the same way as object iteration.

I find object iteration no more clear than WeakMap iteration.  Would you expect as WeakMaps become more common to have to find a way to iterate over its entries too?

But that is quite different. Could you please share details, if you have examples?

I believe that would be @davidchambers' area of expertise.

In other workds, no, you don't have any examples?

Well no

I think we're talking about different things. Clearly implementation does include a description of iteration.

I find object iteration no more clear than WeakMap iteration. Would you expect as WeakMaps become more common to have to find a way to iterate over its entries too?

Object iteration is certainly more clear, it's spec'ed after all. On the other hand WeakMaps are designed to be non-iterable.

In other workds, no, you don't have any examples?

I know Dave is much more versed in your style of communication and more active on the day to day so can totally take the ball on that front. I'd point to dispatchers or discussions of more functionally pure approaches that were rejected on the grounds of practicality.

Sometimes I think that too. But mostly I'm happy and excited by the growth of the library.

I think it's lost some of its charm,

I'm not surprised.  There is charm to youth and naivety that dissipates as one matures.

from its roots as an underscore-like lib with auto-curried flipped-arg methods,

You really have seemed to taken what was simply the easiest thing to demonstrate in Ramda's approach and assumed that it was the only goal of the library.  Putting parameters in the right order for currying was a simple practical choice.  It wasn't really even a decision.  It was essential to the style of coding we wanted to support.  But that was always only one of many important goals.  We've also always stressed immutability of user data, API simplicity, referential transparency, and other standard FP concerns as well as pragmatic abilities to work with the grain of JS rather than against it.
Ramda was not ever specifically an Underscore-like library.  Because Underscore (and later lodash) were trying to supply many of the standard FP functions, and Ramda did so as well, there is a fair bit of overlap.  But the main inspiration we drew from these libraries was two-fold: the positive one of users asking whether we'd consider adding this or that feature that Underscore offers, and the related examination of names used by other languages and other libraries, and the negative one of our own frustration with not being able to comfortably use Underscore / lodash to easily code applications in a truly functional manner.

with the addition of dispatching,

This has been around since long before the world heard of Ramda.  It was discussed in #1, and implemented in 55d439b, almost a year before the first announcements of Ramda.  It has grown and changed since then, but dispatching has long been a goal of the library.  We were discussing this with Eweda, before we even conceived of Ramda.

transducers,

I'm surprised you reject that effort (which is still not complete) as it's one of the few major undertakings we've had focused on performance, and you suggest next that a deemphasis on performance disappoints you.

performance deemphasis,

That's been there from the start, though, too.  We have not ever focused on performance.  When performance problems are brought to our attention, we often try to address them.  At some point after our API is stabilized, we will probably look more to this.  But most of us feel that we've rarely had our library performance end up being a bottleneck in our code, so it's still not a very high priority.  I remember when lodash was first released, one of the strong selling points was its improved performance over Underscore.  While that's admirable, it's a very different focus than our own.

and removal of one-off methods in favor of cook book entries for 3 function deep composed alternatives.

I'm not sure what you're speaking about here.  Is it the removal of map.idx, filter.idx, etc., in favor of addIndex(map), addIndex(filter)?  That's the only place I can think of where we've removed any large number of functions and offered instead recipes.  I'm happy with the resulting consistency and find it simple to use, but it has been a difficult period of adjustment as the library matures.

I think we're talking about different things. Clearly implementation does include a description of iteration.

Of course that has absolutely nothing to do with Ramda's implementation of reduce, or with most other library's implementations, unless they choose to delegate to the native version in some or all circumstances.
Ramda has never been bound to the the functions specified in Array.prototype; we've always used our own.

I find object iteration no more clear than WeakMap iteration. Would you expect as WeakMaps become more common to have to find a way to iterate over its entries too?

I think object iteration is certainly more clear, it's spec'ed after all. On the other hand WeakMaps are designed to be non-iterable.

I think perhaps I'm finally understanding a fundamental difference in our approaches, one that might explain many of our disagreements in the issues here.  Does the following sound right?:  You expect functions to operate on the types Javascript supplies, to handle their quirks, to take advantage of their special features.  I on the other hand, want my functions to operate on slightly more abstract data types, ones which can often be approximated by Javascript types but which are not necessarily implemented exactly as I'd like in the language.
I know we've had this discussion about lists.  Ramda's ideal collection type is a list.  Since there is no readily-available simple list implementation in JS, we choose to accept dense arrays as a close parallel.  But we find no need to do special processing to deal with the possibility of sparse arrays.  Those don't represent lists, and so are not legitimate input to Ramda.  Caveat emptor.
I think there's a similar issue here with objects.  Ramda wants to deal with HashMap/Dictionary implementations of the concept of objects.  It has no issues with the prototype chain, but some of the object metadata such as readable/writeable flags on properties and property iteration sequence, is noise that Ramda chooses to ignore as having nothing to do with dictionaries/hash maps.
It is such idealized objects, each one in essence a set of keys linked to values, that Ramda tries to work with.  And in such, iteration could only be arbitray, based perhaps on some natural ordering of the keys.
Does this distinction clarify anything?  Does it muddy any waters?  :smile_cat:

I'm not surprised. There is charm to youth and naivety that dissipates as one matures.

Hopefully not this soon in the project's life.

You really have seemed to taken what was simply the easiest thing to demonstrate in Ramda's approach and assumed that it was the only goal of the library.

Naw, I didn't assume that.

I'm surprised you reject that effort (which is still not complete) as it's one of the few major undertakings we've had focused on performance, and you suggest next that a deemphasis on performance disappoints you.

Unfortunately Ramda's transducer work doesn't translate to performance elsewhere in the lib. It could probably be moved to a separate lib entirely.

When performance problems are brought to our attention, we often try to address them. At some point after our API is stabilized, we will probably look more to this.

Once the API and behaviors stabilize it may be difficult to make the shifts needed.

and removal of one-off methods in favor of cook book entries for 3 function deep composed alternatives.

I'm not sure what you're speaking about here. Is it the removal of map.idx, filter.idx, etc.

Naw, I was thinking more along the lines of changes to things like the max method.

Of course that has absolutely nothing to do with Ramda's implementation of reduce,

Follow me here.

Does it muddy any waters?

Yap, last four paragraphs muddied it up.

I think this reply is relevant https://github.com/ramda/ramda/pull/1335#issuecomment-132694682.

I think this reply is relevant https://github.com/ramda/ramda/pull/1335#issuecomment-132694682.

Absolutely.  I want to respond, but as you may have noticed, short-form is not my strong suit.  :smiling_imp:  I won't have time for a day or two, but I will respond by the end of the weekend at the latest.

Absolutely. I want to respond, but as you may have noticed, short-form is not my strong suit.  :smiling_imp: I won't have time for a day or two, but I will respond by the end of the weekend at the latest.

Cool. If it helps you better work through your reasonings then it's a win.

I want to apologize.  I thought I'd have plenty of time to write this weekend, but I ended up spending most of my time on home improvement projects and have not have had the time to write.  Most of my thoughts are in order, but it will still take me a bit of time to write them up.  I will get to it soon.

As I said over in #1335, I've spent a lot of time thinking through this issue and the issues surrounding and and or.  I wrote:

My position has not changed drastically on either, but I will try -- here and there -- to summarize what I think, and why. I'm not attempting to shut off debate on either topic but to stop something I do too often: over-engaging in back-and-forth reflexive argument on these issues. If I don't respond to someone's points, it does not mean either that I agree or that I disagree, only that I have already had my say. I will try to respond if someone is succeeding in changing my mind, though.

I'm going to respond to the issues involved in various reduceObj discussions here, whether they were raised on this thread, on #1327 or on #1335.  I'm hoping that further discussion can converge on this one thread.
Earlier I listed a number of other issues that discussed folding objects, including, #257, #364, #546, #625, #656, and #920.  Obviously this issue and #1327 can be added to the list, possibly others.  This is probably the largest number of issues raised for a single request that we haven't been willing to fulfil.  Clearly there is a hunger out there.
Some of that might be misplaced.  We're to the point where we reflexively answer any request for such a feature with an immediate rejection.  We're polite about it, generally, and we explain why this doesn't fit well with Ramda.  But if we took the time to learn what the requester was trying to do, we might find that we already supply it.  @paldepind already noted that one of the examples from lodash's documentation is better expressed in Ramda through mapObject.  And earlier in this thread I gave a simple useWith-based implementation that we should probably port to the Cookbook.
What does it mean to fold?
The issue, in my mind, has never been with how to create such a function.
This issue is with what it's supposed to do.  folds iterate over a collection and repeatedly apply a binary function to the previous result and the next element of the collection, returning the final value.  The order of the collection might or might not influence the result, depending upon whether the function is commutative.
The problem with extending that notion to objects is the word 'iterate'.  Regardless of implementation details, and new specifications as we've discussed them before, objects do not admit to any definitive means of iteration.  Objects in JS are very simple: they map a set of named keys to values.  We can decide to iterate them in some order according to their keys, according to their values, according to some other odd hybrid of the two.  The order we choose can be lexicographic, or some sort of crazy mix of numeric and order of definition.  But the main point is that we can decide.  There are no clear and obvious choices here.
Here's an example:
var obj = {a: 'foo', b: 'bar', c: 'baz'};
foldObj(concat, '', obj); //=> 'abc';

This is a reasonable reading of "iterate over a collection and repeatedly apply a binary function to the previous result and the next element of the collection, returning the final value."  Clearly its not what other libraries have chosen, nor is it what I would assume, but it's also not completely absurd.  Objects are mappings of keys to values.  Why should we assume that fold operates on the values?  Why not the keys?  Or why not a (key, value) tuple?  How about if each iteration were passed an object with key and value properties?
In fact, many of these are possible, and many choices might serve the needs of those making such requests (although presumably not just an iteration of the keys.)
Ordering of Objects
But there is a much deeper problem. When we say 'iterate' we are implying a sequential collection of steps.  Again, this might not matter much if the function is commutative.1  But if it's not, then folding it against [1, 2, 3] is likely to lead to a different result than folding it against [1, 3, 2].  This is generally not considered an issue at all.  The whole point of lists is that they have a defined order to their elements.
Objects are different.  While I do understand that there has long been a de facto iteration order, and that that order is now specified in the ES6 spec, this does not help with older environments, and worse, it does not recognize the fact that objects are in fact at their core Maps / Dictionaries.  A map has no definitive iteration order.  It's not that one can't iterate; it's that depending upon iteration order of your map is depending on something far too close to random to be useful in functional programming.
Problems for Ramda
The goal of Ramda is to make easy in Javascript some of the functional techniques found in other languages.  It's designed to help support developers who want to code in a functional manner.  There are many implications of this, including our emphases on functional composition and immutability.  Another important one is referential transparency, which essentially says that the behavior of a program doesn't change when an expression is replaced by its value.  This implies that equal values should be freely substitutable as inputs to Ramda functions with no noticeable difference in outputs.
Ramda has an equals function to delineate what we think are equal values.  This is where things get tricky.  In Ramda,
R.equals({a: 1, b: 2, c: 3}, {b: 2, a: 1, c: 3}); //=> true  (1)

This is just as we want it.  We think of objects as maps.  The order in which the properties were defined is irrelevant.  Moreover, there are other laws that we would generally assume, even if they aren't generally made explicit:
// for any `key` in obj:
R.equals(R.assoc(key, obj[key], R.dissoc(key, obj)), obj); //=> true  (2)

Or, in imperative terms,
// for any `key` in obj1:
var obj2 = R.clone(obj1);
delete obj2.key
obj2.key = obj1[key];
R.equals(obj1, obj2); //=> true  (3)

To make a foldObj that matched the behavior of the fold in, say, lodash, and met our insistence on referential integrity, we would have to change equals so that (1) simply failed and (2) and (3) were only true in the case that key was the last-defined property of the object.  That's crazy behavior, and not anything I think Ramda should ever support.  Object equality is about values associated with keys, and not with the temporal order of their definitions.
But Ramda is already doing this!
@jdalton pointed out that we still do have this behavior:

var o1 = { 'a': 1, 'b': 2 };
var o2 = { 'b': 2, 'a': 1 };

R.keys(o1); // ["a", "b"]
R.keys(o2); // ["b", "a"]

R.toPairs(o1); // [["a",1],["b",2]]
R.toPairs(o2); // [["b",2],["a",1]]

R.values(o1); // [1, 2]
R.values(o2); // [2, 1]

(There were many more snippets in his example, but most of them had to do with the order of side effects such as console.log statement, which don't worry me at all.)
I noted this earlier, but swept it aside, saying,

But in returning something like this, at least it should be reasonably clear that we're returning a representation of the object, and not the representation. It's a compromise, sure, but it seems a reasonable one.

I was being ridiculous.  There really are no shades of gray here.  This is the same issue.  I should be able to substitute equal values into a Ramda function and get equal results.
I do understand that @jdalton was not suggesting that what we are doing here is wrong, but instead that it's evidence that a foldObj implementation would not be so strange.  I'm afraid I have to take it differently, though, as a notice that we're not being as consistent as we might like.
So, is there any solution?
I think so, and it's one we've discussed before, namely sorting the keys of an object before returning them or before doing something like fold that depend on key order.  This has been dropped before for a lack of enthusiasm.  It's never seemed worth the effort, but I think it's time to take it on.
If we do this the following might surprise people a bit:
R.keys({foo: 1, bar: 2, baz: 3, qux: 4}); //=> ["bar", "baz", "foo", "qux"]

and if we do create a foldObj implementation, this might also surprise some:
R.foldObj((a, b) => b - a, {start: 10, end: 50}); //=> -40

but at least it would be consistent with
R.foldObj((a, b) => b - a, {end: 50, start: 10}); //=> -40

which is the type of issue that I've continually raised in these discussions.
But these surprises are less problematic, I believe, than the ones where two objects that are identical except for the order of property definition have different behavior with respect to Ramda functions.
This would allow for interesting invariants:
R.equals(x, y) ~~> R.equals(x, R.zipObj(R.keys(x), R.values(y)))
               ~~> R.equals(y, R.zipObj(R.keys(x), R.values(y)))

This is not some highly important, well-known invariant, more of a riff on the better-understood fact that
R.equals(x, R.zipObj(R.keys(x), R.values(x))); //=> true

But it's interesting nonetheless.  This would require, what I think is an obvious choice, that values and toPairs results would be sorted according to the results of the sort of keys.  This just seems natural.  But I would certainly be interested to hear arguments for other choices.
Is there an alternative?
There is only one reasonable alternative that I can see: change R.equals to include checks for property order.  We could insist that {a: 1, b: 2} and {b: 2, a: 1} are simply not equal.
This would be consistent with our other criteria, but is a fairly horrifying.  It elevates the implementation details of a Javascript data type, when Ramda is generally trying to work at a higher level.  Ramda's default collection type is a list, and we operate with dense arrays simply because they are the closest analogues offered by the language.  Similarly, our default record type is a dictionary, and we operate with objects simply because they again are the closest analogues available.
As I see it, this is really the only alternative that's consistent with Ramda's philosophy, and it's this horrible.  So I'm pretty well convinced that our best bet will be to create a consistent sort order for anything that turns an object into a list, especially keys, values, and toPairs.  I'm assuming that the natural String sort on the keys would suffice, although it would be interesting to hear if others had differing ideas on this.
So what about foldObj?
I still don't want foldObj.  I simply don't believe it makes sense.  I think the vast majority of requests for it could be handled by either calling mapObj or piping the results of values to map(myFunc).
If we did sort the keys, though, I would not object strenuously to a PR for such a function.  If we solve the referential transparency issue, then my objections to the very nature of the function are resolved.  But my feelings on the need for -- or the sense of -- such a function don't alter at all.  Someone who wants to fold an object has their data already locked into the wrong data structure.

1 A commutative function, f, is a binary function for which, given any values of x and y for which the function is defined, f(x, y) = f(y, x)

So PRs to enforce sort order?

I think default sort on keys would be worse than the current approach of ignorance. I'd hate to see some get gotchad by numerical keys changing order, e.g. {2: 3, 3: 4, 17: 1, 150:2}

@megawac: I could see a more sophisticated sort that puts integer-like keys first, in numeric order.  I had considered that, but not bothered to mention it.  The point is not the specific order, but to make one that we can count on, one that's consistent with the rest of Ramda's ideas.

If we do this the following might surprise people a bit:

That's a pretty good sign that what you're doing is not for JavaScript programmers.
There is a much much simpler solution. The doctor says:

Don't write code where the result depends on the ordering of keys in objects.

It really is that simple and is generally a good practice in JS anyway. This is what users of _.fold do. That is what Haskell users of fold in Data.HashMap do. I think we should trust that Ramda users can figure it out as well. Iinstead of pulling of a complex trick to redefine how a core data structure in the language works in a highly unidiomatic way.
In the case of reduceObj it amounts to: Only pass commutative functions to reduceObj.

In the case of reduceObj it amounts to: Only pass commutative functions to reduceObj.

Excellent advice! When followed, we needn't worry about the order in which the object's properties are enumerated, so having a defined enumeration order would do no harm (setting aside performance). When ignored, the result would ideally depend on the object's value rather than its history.
One other option is to use a random enumeration order. If we're to violate referential transparency, we could at least do so in a way which makes it impossible to depend on an object's history. A situation in which the behaviour of R.foldObj(f, a) is "correct" some of the time and the behaviour of R.foldObj(f, b) is "correct" some of the time is preferable to a situation in which the behaviour of R.foldObj(f, a) is always "correct" (due to the history of a) and the behaviour of R.foldObj(f, b) is always "incorrect" (due to the history of b). Such inconsistent behaviour is unlikely to go unnoticed for long.
I'd prefer, though, to define enumeration order. The fact that R.keys({x: 1, y: 1}) is not equivalent to R.keys({y: 1, x: 1}) really bothers me.

The fact that R.keys({x: 1, y: 1}) is not equivalent to R.keys({y: 1, x: 1}) really bothers me.

@davidchambers Because it crates an itch in you or because it has caused some real world problems? If the latter I am interested to hear what they might be.

Because it crates an itch in you or because it has caused some real world problems?

It limits my ability to reason about programs. I consider this a real-world problem.
x ≍ y should imply f(x) ≍ f(y).

x ≍ y should imply f(x) ≍ f(y).

Yes, but {x: 1, y: 1} is not equal to {y: 1, x: 1} so R.keys({x: 1, y: 1}) should not be equal to R.keys({y: 1, x: 1}). One might say that the issue is with R.equals because it thinks those are equal.

One might say that the issue is with R.equals because it thinks those are equal.

that is one approach. IMO it makes sense to treat {x: 1, y: 2} as equal to {y: 2, x: 1} so I prefer the other approach, which boils down to imposing a sort on the keys. otherwise you can't get consistent results when folding. this sucks for transducers, since you would have to pay the sort penalty up front if you then want to lazily fold over the object.

I could see a more sophisticated sort that puts integer-like keys first, in numeric order.

why? i think all we want to guarantee is that such a fold would be consistent. as long as the iteration order is reliably the same for objects considered equal, i really don't care what the details of that sort are. at a certain point you have to wonder if you are using the wrong data structure if you find yourself needing to fold js objects and caring deeply about the output order.

It limits my ability to reason about programs. I consider this a real-world problem.
x ≍ y should imply f(x) ≍ f(y).

Yes, that.  And as to ordering, I would prefer the extension implied by the comment from @megawac to plain Unicode sorting, but the main question now is whether to sort at all.

I could see a more sophisticated sort that puts integer-like keys first, in numeric order.

why? i think all we want to guarantee is that such a fold would be consistent. as long as the iteration order is reliably the same for objects considered equal, i really don't care what the details of that sort are. at a certain point you have to wonder if you are using the wrong data structure if you find yourself needing to fold js objects and caring deeply about the output order.

I can buy that.
But on the other hand, if we have to do a sort, I have no issue with making the sort as useful as we can.

that is one approach. IMO it makes sense to treat {x: 1, y: 2} as equal to {y: 2, x: 1} so I prefer the other approach

I very much agree. I don't want to change R.equals. My point was that I don't agree with neither Scott nor David when they use R.equals to determine if we are breaking referential transparency. It simply does not work because R.equals deliberately does not distinguish between things that are undeniably different in the language. If we use === instead then neither R.keys nor R.reduceObj breaks referential transparency.
I.e. things that R.equals consider identical are not guaranteed to be interchangeable in general so we can not use it as our basis for validating referential transparency. We could of course guarantee the statement: if f is a Ramda function and R.equals(a, b) === true then R.equals(f(a), f(b)). But in my opinion that is too naive because it ignores both the limitations of R.equals and of JS. And prevents us from doing things that makes sense and are useful.
To put it another way: R.equals is not the one and only way to determine equality. It is merely an approximation at how we want JS to be. But it is a leaky abstraction. Sometimes and object is a map and sometimes it is a record. Sometimes an array is a list and sometimes it's a set. Sometimes we even have to care about reference equality. There is no single way to define what equality is.

@paldepind:

To put it another way: R.equals is not the one and only way to determine equality. It is merely an approximation at how we want JS to be.

Of course it's not.  But I really would like to promote it as the way Ramda thinks about equality.  If we can't do that, then we should fix it up until we can.  David, as always, has a simpler formulation:
x ≍ y should imply f(x) ≍ f(y).
where a ≍ b means R.equals(a, b).

I.e. things that R.equals consider identical are not guaranteed to be interchangeable in general so we can not use it as our basis for validating referential transparency.

Can you think of examples of x, y, and some Ramda function f for which we would want x ≍ y but not f(x) ≍ f(y)?  If we had some real examples, that might have to change my thinking.

Of course it's not. But I really would like to promote it as the way Ramda thinks about equality.

Yes. We agree on that. But it's limitations should not get in the way of what we can do. Defining referential transparency in terms of R.equals should be the default but we should realize when that approach does not work.

Can you think of examples of x, y, and some Ramda function f for which we would want x ≍ y but not f(x) ≍ f(y)? If we had some real examples, that might have to change my thinking.

The example that started it:

I'd prefer, though, to define enumeration order. The fact that R.keys({x: 1, y: 1}) is not equivalent to R.keys({y: 1, x: 1}) really bothers me.

The array returned by R.keys is supposed to represent a set but R.equals does not know that. Thus we'd have to remove R.keys if we really wanted to enforce the before mentioned rule.
If we took the principle of being for JavaScript developers seriously we'd just add this function instead of inventing problems in our heads and complex performance damaging "solutions". Otherwise we should probably bring back the Eweda tag line: A (probably im-)practical functional library for Javascript programmers.

Defining referential transparency in terms of R.equals should be the default but we should realize when that approach does not work.

... and try to fix them?  :smile:

The array returned by R.keys is supposed to represent a set but R.equals does not know that.

Do you see that as a problem with equals?  My whole point was that I see this as an issue with keys.  I really did at one point creating an internal implementation of Set to deal with this, but  whatever I came up with was eventually going to want to be iterable and would have to face the same problem, so I moved my thinking back up the stack.

If we took the principle of being for JavaScript developers seriously we'd just add this function instead of inventing problems in our heads and complex performance damaging "solutions".

I think that mantra, which I just threw together, has turned out to be wonderful.  It's led to all sorts of creative tensions that are probably best for the library (the only non-controversial word in the whole thing.)  "A practical functional library for Javascript developers."  I like it!
You and I are arguing opposite sides from what we did in #1335, where I was all about the Javascript behavior.  Here I think that the whole idea is to introduce more useful FP constraints into the language.  As always, "a foolish consistency is the [hobgoblin of little minds][re]."
I would expect this to affect performance only in those places where we need it to, where objects are converted to lists for public consumption.  Internally, we can still use a more efficient keys function.

Otherwise we should probably bring back the Eweda tag line: A (probably im-)practical functional library for Javascript programmers.

:smiling_imp:
I should point out that Ramda's current tag line was Eweda's tag line first, until we realized just how badly that elegant code would perform.
[re]: http://www.brainyquote.com/quotes/quotes/r/ralphwaldo136909.html

David, as always, has a simpler formulation:

That formulation does not work in general as I pointed out before.

... and try to fix them?  :smile:

I can understand the motivation but I don't believe it's practical.

Do you see that as a problem with equals?  My whole point was that I see this as an issue with keys.

You can consider it an issue with R.keys. But one could also say it's a problem with equals because it does not distinguish between {x: 1, y: 1} and {y: 1, x: 1}. One could also say it's a problem with ECMAScript 5 because it does not have sets. It's all problems but what matters is that R.keys is useful and the best we can do.

I think that mantra, which I just threw together, has turned out to be wonderful.  It's led to all sorts of creative tensions that are probably best for the library (the only non-controversial word in the whole thing.)  "A practical functional library for Javascript developers."  I like it!

Yes. I like it too.

You and I are arguing opposite sides from what we did in #1335, where I was all about the Javascript behavior.  Here I think that the whole idea is to introduce more useful FP constraints into the language.  As always, "a foolish consistency is the [hobgoblin of little minds][re]."

It's a bit funny indeed. But note that I'm certainly not arguing for JavaScript's behavior. But instead rolling out a complex solution I propose to simply avoid writing code that depends in said semantics.

I would expect this to affect performance only in those places where we need it to, where objects are converted to lists for public consumption. Internally, we can still use a more efficient keys function.

We can't know if the function passed to R.reduceObj is commutative or not.
If one took my advice:

Don't write code where the result depends on the ordering of keys in objects.

Then "those places where we need it to" would be no places at all.

We can't know if the function passed to R.reduceObj is commutative or not.
If one took my advice:
Don't write code where the result depends on the ordering of keys in objects.
Then "those places where we need it to" would be no places at all.

If the solution is "don't use non-commutative functions" then reduceObj is completely redundant since you can simply: reduce(f, {}, values(obj))

If the solution is "don't use non-commutative functions" then reduceObj is completely redundant since you can simply: reduce(f, {}, values(obj))

Well, you don't know what the function does, so you can't assume that {} is an appropriate initial value.  It wouldn't work for foldObj((a, b) => a + b, 0, {a: 1, b: 2, c: 3}), which is similar to the example I keep using, but using a commutative function instead.

sorting the keys of an object before returning them or before doing something like fold that depend on key order.

This still feels like a premature anti-optimization to me. Why do something that nobody has asked for to protect them from a problem nobody has had? The fact that

this issue has been raised so many times (and who knows how many others have wanted reduceObj but didn't raise an issue)
somewhere between zero and very few (I can't remember a single one) issues have been raised by users tripped up by the undefined iteration order of all the current ramda object functions

seems like a very good reason for ramda to support reducing objects and not worry about the order of the keys/values.

I think @kedashoe is spot on! Let me also point out what he said in another thread on this matter:

Probably it is good the engines seem to be heading towards a defined order, but does anyone here plan on relying on that? In other words, I think plain javascript objects are a tool to be used as unordered key-value pairs.

Which to me indicates that he uses the same guiding principle as me (and many other JS devs I assume): Don't write code that depends on the ordering of object keys.
@CrossEye
In the PR on R.and and R.or you used this argument:

I also work with and help mentor a very large team, often including as many as 30 developers with hands in the Javascript codebase, from rank beginners to very experienced. There are all sorts of problems that come up on code review, but this is not a significant one.

Now tell me. How often does errors occur caused by usage of Object.keys or similar functions that depends on the ordering of object keys?
Something else: Earlier in this thread you wrote:

My preference is to simply abandon the idea of foldObj, as I don't see it making a lot of sense.

Does anyone still think that foldObj does not make sense? Let me point out that every map data structure in Haskell implements foldable and that is even though some of them have arbitrary ordering of key/values.

Don't write code that depends on the ordering of object keys.

100% agree. in which case reduceObj is redundant.
Nonetheless, it would be nice if:
obj1 = {a: 1, b:2};
obj2 = {b: 2, a: 1};

equals(obj1, obj2); // true; works today
equals(keys(obj1), keys(obj2)); // would be nice if this were so; at present it is false

likewise for values, etc.
``

@kedashoe:

Why do something that nobody has asked for to protect them from a problem nobody has had?

Because it's the right thing to do.
If Ramda tries to enforce referential transparency, it should be serious about it.  Otherwise, why try to use a dedicated functional library at all?
The fact that we notice a problem before any user brings it to our attention is a good thing!
@paldepind:

There are all sorts of problems that come up on code review, but this is not a significant one.

Now tell me. How often does errors occur caused by usage of Object.keys or similar functions that depends on the ordering of object keys?

I make a huge distinction between what other users do and what our library does.  We were discussing truthy and falsey values in Javascript, and I noted that this did not cause issues in the language.  Here I see Ramda acting entirely incorrectly, returning two non-equivalent results for two equivalent values.
I'm actually quite amazed to find resistance to fixing this.  This one feels to me like one of those glad-we-caught-it-before-it-did-real-harm moments.

My preference is to simply abandon the idea of foldObj, as I don't see it making a lot of sense.

Does anyone still think that foldObj does not make sense? Let me point out that every map data structure in Haskell implements foldable and that is even though some of them have arbitrary ordering of key/values.

That is still my preference.  But if we fix the key order, then I wouldn't put up a fight about it.
Let me note again, "arbitrary" is not the same as "inconsistent".  What I'm proposing is to add a consistent, even if arbitrary, ordering to keys, et al..  The current ordering is inconsistent with equals.

The fact that we notice a problem before any user brings it to our attention is a good thing!

I think you are hurting users, not helping them. If Ramda does this it will be treating JS objects differently from their native behavior and different from every other library. If a user writes codes that relies on object key order, their program should blow up.

If Ramda tries to enforce referential transparency, it should be serious about it. Otherwise, why try to use a dedicated functional library at all?

Well we've all been using ramda for quite a while now without this being enforced by any of these methods, so maybe it is okay afterall and we aren't fools for using a dedicated functional library that permits it :) It seems like a great property, I'm glad Ramda takes it seriously. But it doesn't make sense for objects, and that is ok. @jdalton is advocating for this method, clearly he has not been inundated with issues. Ramda, underscore, lodash, all these functions that don't enforce any key order, can you find any issues that have been raised? I glanced at lodash and couldn't find any. I would be curious to read the discussions if you can find them.

I make a huge distinction between what other users do and what our library does.

You will have to explain why changing the semantics including the signature of a function is not the same as changing what our library does?

Let me note again, "arbitrary" is not the same as "inconsistent".

It is exactly the same. Including most importantly how users will have to deal with it.
I think this is probably the most unpragmatic proposal I've seen yet with regards to Ramda.
Trying to enforce referential transparency in a language without referential transparency.
IMO much less radical things have been rejected with the argument that Ramda is practical and for JS developers.

I make a huge distinction between what other users do and what our library does.

You will have to explain why changing the semantics including the signature of a function is not the same as changing what our library does?

I'm sorry, but I'm not following here.  Are you suggesting that I'm proposing a signature change?  I'm not.  I'm suggesting only that before returning the data from keys, values, and toPairs, the results are sorted by the key values.  They would still return lists; the lists would simply now be consistent, regardless of, as @davidchambers described it, the history of the object.  That is
var obj1 = {a: 1, b: 2, c: 3};
var obj2 = R.assoc('b', 42, R.dissoc('b', obj1));

R.equal(R.keys(obj1), R.keys(obj2)); //=> true

Let me note again, "arbitrary" is not the same as "inconsistent".

It is exactly the same. Including most importantly how users will have to deal with it.

How will users have to deal with it?  What harm comes from sorting the keys?  You've already pointed out a principle: "Don't write code that depends on the ordering of object keys."  Anyone following that will have no issues at all.  Anyone who depends only on consistent behavior in the keys will get that.  The only ones who might be tripped up are those depending upon a particular ordering that was only formally specified six weeks ago, an ordering not consistent with our notion of equality.
As to "arbitrary" versus "consistent", I don't know for certain, but I'd be willing to bet money (ok, perhaps only a small amount, but hard cold cash, nonetheless :stuck_out_tongue: ) that the Haskell maps you're speaking of, would iterate in the same order given the same contents.  That's what I mean by "consistent".  But the order might be "arbitrary", i.e. not specified by the language spec, and possibly varying from one implementation to another.  Those are very different notions.  I would like to make our sort order consistent.  But it can be arbitrary, although I'd prefer something simple, probably alphabetic, perhaps modified to meet @megawac's objection.  Here "arbitrary" and "consistent" can coexist peacefully.

@CrossEye

I'm sorry, but I'm not following here.

Recap: I wrote

In the PR on R.and and R.or you used this argument [...] How often does errors occur caused by usage of Object.keys or similar functions that depends on the ordering of object keys?

Then you wrote

I make a huge distinction between what other users do and what our library does. We were discussing truthy and falsey values in Javascript, and I noted that this did not cause issues in the language. Here I see Ramda acting entirely incorrectly, returning two non-equivalent results for two equivalent values.

Indicating that #1335 was somehow only about "what users do" and that this issue is about "what our library does". Then I ask:

You will have to explain why changing the semantics including the signature of a function is not the same as changing what our library does?

Since that is what #1335 does.

How will users have to deal with it? What harm comes from sorting the keys?

I am not talking about sorting the keys.
Recap: You wrote

Let me note again, "arbitrary" is not the same as "inconsistent".

Making some odd distinction between how the keys in Data.HashMap are ordered arbitrarily and how the keys in a JS object are ordered by insertion order. Then I write:

It is exactly the same. Including most importantly how users will have to deal with it.

Because that is the truth. If you use Data.HashMap your code cannot rely on any ordering of the keys which is exactly the as what I suggest one do in JS.
Let me also point out that there is nothing arbitrary nor inconsistent about the order of keys in a JavaScript object.

What harm comes from sorting the keys?

You've recognized this earlier in the thread so I'm not sure why you're asking that question. Alse, performance.
This is basically the essence of this thread:

R.equals does not recognize one fundamental fact about the object data structure in JS, namely that key/vals are ordered by insertion (it's like appending to a list).
You guys wants to redefine what objects are in JS

I think redefining a core data structure is insane and naive.

@paldepind:
[ ... he said, she said elided: not going anywhere, and probably not all that important.]

How will users have to deal with it? What harm comes from sorting the keys?

I am not talking about sorting the keys.

Ok, I guess I'm confused.  That's the proposal I made above, and I thought we were discussing it.  Do your actually object to it or not?

Because that is the truth. If you use Data.HashMap your code cannot rely on any ordering of the keys which is exactly the as what I suggest one do in JS.

But you can freely substitute another Data.HashMap with the same contents, regardless of how it was built and get the same behavior.  This is what I believe is missing in Ramda right now, and what I feel is an important issue.

What harm comes from sorting the keys?

You've recognized this earlier in the thread so I'm not sure why you're asking that question.

Please remind me.  This whole thread has been building for me toward the notion that we were going to have to resurrect the key-sorting proposal.  It's never thrilled me, and I have felt for a while that it was mostly for some really isolated issues that it even mattered.  The list of issues @jdalton raised on the other thread demonstrated to me that it was more than a small matter.  And now we're facing the same problem for Maps and Sets.

Also, performance.

Yes, it will slow down calls to keys, values, and toPairs.  I don't know by how much.  There might be one or two others.  But sort is n log(n), not horrible; we're not going to hit quadratic time on this.  And I guess I don't find those to be critical functions.  We'd also pay this penalty if we decide to include a foldObj function of course.  None of this scares me.

This is basically the essence of this thread:

R.equals does not recognize one fundamental fact about the object data structure in JS, namely that key/vals are ordered by insertion (it's like appending to a list).

Yes, in much the same way that many Ramda functions do not recognize the fundamental fact about the array data structure in JS that it may be sparse.

You guys wants to redefine what objects are in JS

Not exactly, but we want to work with an idealized version of them.  We are not altering the underlying objects, only the glosses on it we generate with functions such as keys, values, and toPairs.  The point is that we want to consider two objects with the same key-value pairs as the same.  The fact that the language treats them differently is to me an unfortunate and confusing part of the specification, not something to be emulated.

I think redefining a core data structure is insane and naive.

Do you think that all Ramda list functions should be changed to deal with the possibilities of sparse arrays?
I think that Ramda is much better off dealing with a higher level of abstraction, and a slightly more idealized version of the world.
A user who wants the native behavior can still use the native Object.keys, or do a simple map over that to get a native equivalent of values or toPairs if she really wants that behavior.  Those would not be compatible with Ramda's equals, but that would be her concern.
I simply don't see the downside (outside a minor performance concern.)

Ramda functions do not recognize the fundamental fact about the array data structure in JS that it may be sparse.

That is not fundamental.

Ramda functions do not recognize the fundamental fact about the array data structure in JS that it may be sparse.

That is not fundamental.

But the iteration order of properties of objects, left undefined by the specification until this June, is fundamental?

But the iteration order of properties of objects, left undefined by the specification until this June, is fundamental?

No. It's just something that makes console.loging nicer. Good practice is still not to rely on key order. You want to change it into a data structure with a consistent key order that users can rely on. That is a fundamental change.

Good practice is still not to rely on key order. You want to change it into a data structure with a consistent key order that users can rely on. That is a fundamental change.

No.    What I want to ensure is this:
x ≍ y should imply f(x) ≍ f(y).
for all Ramda functions.  I would much rather do this by changing keys than by messing with equals; I think equals accurately captures what we want it to, and changing it so that objects are only equal if their properties were inserted in the same order would be a travesty.  That would be a fundamental change.  Changing the order in which we list the keys of an object is not at all big deal.

I hesitate to join in the fun here, but it seems like a reduceObj function would still maintain referential transparency if the provided accumulator function was expected to be commutative.
If we were to go down the path of first sorting by keys, then the likelihood of someone being able to use a non-commutative function is fairly low, as we have now dictated the order of iteration and evaluation. This suggests to me that the sort is unnecessary.
Given the demand for this function, I would be happy to see it included in Ramda providing its docs cover sufficient warnings about the need for commutative accumulator functions.

a reduceObj function would still maintain referential transparency if the provided accumulator function was expected to be commutative.

As I mentioned above, it is already trivial to reduce an object with a non-commutative function: reduce(f, acc, values(obj)), so IMO such a function is redundant.

@scott-christopher:
I probably should have started another topic here.  Although this started from the reduceObj question, the main issue at the moment is whether we sort the result of keys, values, etc.  The rationale is simple: Ramda defines its notion of equality with equals and referential transparency implies that equals(a, b) ~~> equals(f(a), f(b)) for any f.  keys, value, etc. fail this because they are iterated in insertion order, which our equals doesn't respect.  That's all I'm looking to fix.  If we do fix it, I'd not stand in the way of a reduceObj, even if it still seems a little absurd to me.
But what I want to do is fix these holes in our current functions.  Does this make sense?
@kedashoe and @paldepind have made it clear that they don't see a reason to do so; even further, I think they see it as potentially harmful. @davidchambers and @buzzdecafe have expressed support for the idea.  So it's a pretty split community.
I'm having a hard time because once I really recognized the problem it seemed so glaringly obvious to me that we had to fix it that I wasn't expecting any opposition at all, except for a little pushback on possible performance of these few functions.  I was quite stunned to find that what seems so obvious and so important to me is not at all so to others I respect.

As I mentioned above, it is already trivial to reduce an object with a non-commutative function: reduce(f, acc, values(obj)), so IMO a reduceObj function is redundant.

Sure, if you're only interested in the values. I would expect that if we're going to offer a reduceObj it should provide the key along with the value to the accumulator. This can also already be achieved by reduce(f, acc, toPairs(obj)), but it's pretty clumsy (without es6 destructuring) having to reference the key and value by array index in the accumulator rather than simply being available as function arguments.

But what I want to do is fix these holes in our current functions. Does this make sense?

Sorry, I was confusing the two discussions. Yes it does make sense. I'm undecided whether the results of keys, values and toPairs should be sorted or not. I'd suspect the performance impact would be pretty minimal for small objects, but it could be annoying for larger objects. That said, I would prefer to uphold the notion of x ≍ y should imply f(x) ≍ f(y).

But what I want to do is fix these holes in our current functions. Does this make sense?

Sorry, I was confusing the two discussions. Yes it does make sense. I'm undecided whether the results of keys, values and toPairs should be sorted or not.

I'd love to hear suggestions for other ways to do this.  It seems to me that there are only two options to fix the problem: change equals to match the current key/value/toPairs insertion order semantics, or change those functions to yield consistent results regardless of insertion order.  I'm proposing the latter.  If there is another way to do this without sorting, I'm all ears.  Or if you have a third general option, I'd like to know what it is.  I think we all would!  :smile:

Ideally the keys, values and toPairs would return sets/multisets rather than arrays, but that's not really feasible.
I like the current behaviour of equals such that it respects the unordered nature of an object, so I would opt for sorting if it meant keeping that.
The 3rd general option is to leave them as they currently are, with some commentary added to their docs as a warning that the resulting lists should be effectively treated as unordered.

Ideally the keys, values and toPairs would return sets/multisets rather than arrays, but that's not really feasible.

I had that thought initially as well, but I felt it might just end up kicking the can down the road to whenever we pulled an iterator out of those results.

The 3rd general option is to leave them as they currently are, with some commentary added to their docs as a warning that the resulting lists should be effectively treated as unordered.

It's possible.  I'm extremely wary of a documentation-only solution, especially when what we are documenting is an exception to our normal practices.  But obviously we could do this.


Improvements to how and what is stored in the texture caches.

Built upon the good work from https://github.com/pixijs/pixi.js/pull/3789

For Text, the base textures were in the BaseTextureCache, but textures weren't in the TextureCache. This has been fixed
Now able to tell the BaseTexture the origin of where the canvas being passed through has come from. ie. was it from the text class? was it from the graphic class? was it from caching as a bitmap? More information now to track where these canvases (canvii??) have been generated from
BaseTexture has addBaseTextureToCache and removeBaseTextureFromCache functions, to match regular Texture. Any adding or removing to the BaseTextureCache is now through these functions
Protection around adding and remove items to the caches using the functions

! Breaking change. When you call Texture.fromTextureFromCache - it no longer automatically removes it's base texture from the base texture cache. Not sure how people feel about this
? I don't like lines 233 to 236 in Texture.js, and line 591 in BaseTexture.js - I don't see why they are there or why they are needed, but I chickened out on removing them!

I'm in favor of consistent & shorter API names:

*.removeFromCache instead of BaseTexture.removeBaseTextureFromCache and Texture.removeTextureFromCache
*.addToCache instead of BaseTexture.addBaseTextureToCache and Texture.addTextureToCache

This will require deprecating Texture.addTextureToCache and Texture.removeTextureFromeCache

I agree.. doing that would also get around the breaking change problem, as the deprecated removeTextureFromCache function can carry on also removing the base texture from its cache.

What about switching off mipmaps for all "fromCanvas" methods?

Should *.addToCache warn (in debug builds only, perhaps) when something in the cache is going to be overridden?

Do we have a way of doing that yet? If not, if someone wanted to PR adding support for something like https://github.com/jsoverson/preprocess - then some warning code as you described would be the perfect fit.

You can already use preprocessor in the builds, however the lib version does not respect preprocess statements.

Done.
Also allowed removing from either cache by actual instance... so if a texture was added to the cache under multiple ids, this would remove them all.
Also added some unit tests for the new functionality (which also cover legacy behaviour)

Finally got around to this - textureCacheId is now textureCacheIds, and is an array.
Unit tests updated to reflect this change

LG2M 🚢


Fix default_texture_param in shader pipeline to support uniform arrays

Continuation of https://github.com/godotengine/godot/pull/49485. This will allow users to use set_default_texture_param/get_default_texture_param (in Shader or RenderingServer) for assigning default textures to uniform array by using an optional index parameter.

Needs a rebase.

Thanks!


User should see new invite design

We did a few changes in the following parts of the feature-

[x] Main screen - feed new design

[x] Main screen- new icon instead of the invite a reward+ notification on changes

[x] increase +1 when  a new friend joins or claims
[x] reset counter after user visits the invites page

[x] Invite screen- new design for the instructions

[x] Invite screen- social media buttons are aligned to the left

[x] Invite screen- all of the invitee's are under the same title with different icons that display their status

[x] Inviter will receive 100 G$

[x] Invitee will receive 50$

[x] invitee triggers payout

[x] New events added

[x] show invite card again after two weeks

[x] copy link text

[x] share texts

[x] bonus given once invitee claims

[x] new design for share buttons + link

[ ] twitter shorter text
all of this is described in the following document with the relevant design links

https://docs.google.com/document/d/1Q8xl6p1OSY4XYZmHH_Fow7P00L6LaQP2xiQZiNlLrs8/edit

@Esfir-E open questions
what initiate the bounty redemption - currently user need to open the invite page to trigger it
new question: what about the new invitee bonus?
options:

after claim invitee triggers bonus redemption for both inviter and invitee
inviter opens invite page and trigger bonus redemption for both

should copying the invite url also include a text - when user press "copy" (on desktop, not native share)

Hey

About the  initiate bounty redemption-  i prefer this option -after claim invitee triggers bonus redemption for both inviter and invitee
you mean like indication that it was indeed copied or the actual text- i dont think we need to display the actual text after user press 'copy'
i will have it by the end of the day from marketing
Yes still think the reminder is relevant in case the user didnt invite anyone and wasn't active for 2 weeks

@Esfir-E waiting for answers

@sirpy new design for the internal page-
https://app.zeplin.io/project/5fbfcf1e77d2fab82f7ee073/screen/5fc3abc4ab7489b7358ec5f6

@sirpy The Invite design has checked. There are no new issues.
Checked on the QA 1.18.0-0
Device: Windows 10 // Google Chrome Chrome v.87.0.4280.88

@sirpy The Invite design has checked. There are no new issues.
Checked on the QA 1.18.0-0
Device: Windows 10 // Google Chrome Chrome v.87.0.4280.88


nice work but dont have resolutions

works properly but need 360p,480p.. or sth

The script is only used for single link, you may go here https://github.com/ArdiArtani/Photo-Google-Player-Script if you to have resolutions


Fetch dynamic data for profile dialog box

Description
I am bit confused in this cause the need to fetch dynamic data for profile dialog box is just for the bio and nothing else. Should I add this now or later?

Steps to reproduce
Hover over user avatar on post.
It will open a dialog box which will contain a static bio.
Screenshots
No response
Desktop (please complete the following information)
No response
Smartphone (please complete the following information)
No response
Additional information
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I have checked the existing issues
[X] I'm a GSSoC'23 contributor
[X] I want to work on this issue

Description
I am bit confused in this cause the need to fetch dynamic data for profile dialog box is just for the bio and nothing else. Should I add this now or later?
Steps to reproduce
Hover over user avatar on post. It will open a dialog box which will contain a static bio.
Screenshots
No response
Desktop (please complete the following information)
No response
Smartphone (please complete the following information)
No response
Additional information
No response
Record

[x]  I agree to follow this project's Code of Conduct
[x]  I have checked the existing issues
[x]  I'm a GSSoC'23 contributor
[x]  I want to work on this issue

Sorry but this has just been resolved with a merged pr #993 :)
The data included username,displayname,bio,location,etctetc

closing as duplicate to #952 (perhaps it was not updated and that was a mistake, sorry)

No need to say sorry. Its absolutely fine. Thanks for informing.


Update dependencies and fix linting issues

@nechaido these changes were introduced because the rule no-prototype-builtins has been added to the eslint:recommended config.


Free infoset element during unparse

This refactors how we figure out when DINodes are final during
unparsing, mainly for arrays. Previously, arrays were marked final
when their parent became final, but that meant arrays could
potentially stick around for a long time. Instead, we set arrays as
final when a new element is added after it, or if it's the last thing
in a complex type. In both cases, we know no more elements will be
added and the array is final
After marking DINodes as final we free them if they are not used in an
expression to reduce memory requirements
Changes dfdlx:outputTypeCalcNextSibling function to mark possible next
siblings and itself as used in an expression, since both are needed in
the function implementation so we cannot free those elements.
Add new releaseUnneededInfoset tunable which allows one to disable
this freeing of infoset elements, for both parse and unparse. This is
helpful when running unit tests that do manual inspect of the infoset
after it is complete to ensure correctness. We can't have these
elements being freed. Refactor existing variable names to match this
tunable
Adds areDebugging logic to UState, similar to PState, so we can
disable freeing infoset nodes while debugging.

DAFFODIL-1272

How about a test mode? A settable flag in pstate/ustate and a mutable list.
Instead of just nilling the refs to things being released when the flag is set you also push them onto the list. At end of a test run we inspect the list to insure the right things have been put on the list?
Seems like small effort for a big increase in testability maintainability of this feature. Could be done for both parse and unparse.

From: Steve Lawrence<EMAIL_ADDRESS>Sent: Friday, October 16, 2020 9:54:04 AM
To: apache/incubator-daffodil<EMAIL_ADDRESS>Cc: Beckerle, Mike<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [apache/incubator-daffodil] Free infoset element during unparse (#437)
@stevedlawrence commented on this pull request.

In daffodil-core/src/test/scala/org/apache/daffodil/infoset/TestInfoset.scalahttps://github.com/apache/incubator-daffodil/pull/437#discussion_r506448616:

*/

def testInfoset(testSchema: scala.xml.Elem, infosetAsXML: scala.xml.Elem): (DIElement, Root, DaffodilTunables) = {

val schemaCompiler = Compiler().withTunable("allowExternalPathExpressions", "true")

val schemaCompiler =

 Compiler()

   .withTunable("allowExternalPathExpressions", "true")

   .withTunable("releaseUnneededInfoset", "false")

It's actually kindof hard to write a test to make sure everything is getting cleaned up appropriately. At the end of unparsing, the DIDocument should have a single child, the root element. If that root element isn't used in an expression it should get set to null. So at the end of a parse, the DIDocument child(0) should be null if not used in an expression. But that only tests that we were able to free the root element. It's possible things were broken so that no a single other element was freed and the only thing actually freed was the root element. And since the root elemen was freed, there's no way to know if any of it's children were freed--we no longer have any access to it or it's children.
Maybe the best way to ensure this is working correctly is to just develop tests that would fail with OutOfMemory errors if we weren't cleaning up infoset correctly. Those tests would likely be too large/take too long to keep in the Daffodil repo, but I believe @dfthompsonhttps://github.com/dfthompson is working on some tests that live in Owl's internal test infrastructure. Once those are done, we might want to find a place where those can be made public so others can test them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/apache/incubator-daffodil/pull/437#discussion_r506448616, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALUDA3C6CIZTTQYZQ7JQEDSLBF7ZANCNFSM4SSADTDQ.

Doesn't seem totally unreasonable. I guess individual tests would then need to manually maintain a list of elements that are expected to be freed and compare against this built-in list? I can't think of a good way to automate it the process.

The infoset "chunks" on the list of released ones might still convert to xml elements via toXML. If so you can take the whole array, convert to an XML doc by wrapping an element around them all, and a test can then contain a corresponding expected XML chunk to compare to it.

Not a bad idea, but I guess it still requires someone to manually create the expected XML. I was hoping for some other way things to just know what shoudl be release. But that's probably too difficult and fragile. I'll come up with a way to easy create the expected results. XML might be a good approach.

Another thought, what if instead we make it so that if we would have freed a DINode but didn't then we modify some new state in the DNIode that says that it would have been freed. And when we output the infoset as XML we have to ability to configure it to include an attribute saying it would have been freed. Then we just have these tests disable freeing output as XML with this attribute, and then we can easily inspect the XML to determine which elements would have been freed. No concerns with elemetn children being null, and the resulting XML should look exactly like the infoset, just with extra attributes. Thoughts?

That seems like a better choice. We just mark the nodes and convert to an XML attribute.

From: Steve Lawrence<EMAIL_ADDRESS>Sent: Friday, October 16, 2020 12:49:22 PM
To: apache/incubator-daffodil<EMAIL_ADDRESS>Cc: Beckerle, Mike<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [apache/incubator-daffodil] Free infoset element during unparse (#437)
Another thought, what if instead we make it so that if we would have freed a DINode but didn't then we modify some new state in the DNIode that says that it would have been freed. And when we output the infoset as XML we have to ability to configure it to include an attribute saying it would have been freed. Then we just have these tests disable freeing output as XML with this attribute, and then we can easily inspect the XML to determine which elements would have been freed. No concerns with elemetn children being null, and the resulting XML should look exactly like the infoset, just with extra attributes. Thoughts?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/apache/incubator-daffodil/pull/437#issuecomment-710210484, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALUDA2A3WCXDRBQSVFUJTLSLB2RFANCNFSM4SSADTDQ.

Ok, I've just added a commit that adds some state to track when an infoset element would have been released if it's disabled, adn the ability to output this state with the ScalaXMLinfosetOutputter. Also added some tests that verify that DINodes are being released as expected.

Still need one more +1 before this can be merged. @jadams-tresys @olabusayoT @tuxji Any chance one of you could take a look at this?


Ctrl+Shift+F (Search)

Type: Feature Request
Can VSCode please allow this key-combo to toggle the search panel?
When I use my mouse and click the magnifier icon, depending on the state of the panel it changes to the opposite as intended. Although, using the hot-keys CTRL SHIFT F only opens the panel and a subsequent input again of this key combination only keeps the panel open, instead of closing it as desired.
Thank You for taking my input. Have a great day!
VS Code version: Code 1.85.0 (af28b32d7e553898b2a91af498b1fb666fdebe0c, 2023-12-06T20:48:09.019Z)
OS version: Windows_NT x64 10.0.22621
Modes:

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.85.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Currently, CTRL+B should toggle the side bar visibility via workbench.action.toggleSidebarVisibility. You could add a keybinding for workbench.action.toggleSidebarVisibility that runs on CTRL+SHIFT+F when searchViewletVisible like this:

We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on StackOverflow, where the community has already answered thousands of similar questions. You may find their guide on asking a new question helpful if your question has not already been asked. See also our issue reporting guidelines.
Happy Coding!


IndexError when passing empty string to predict() and predict_proba()

When passing empty string into predict function, this line and this line will cause the IndexError.
If possible I think it could be changed to if text == "" or text[-1] != '\n': and the problem should be solved.

I also found this pull request that also want to tackle the same problem. Rather than just remove the empty strings, I think keeping it would reduce the problem that the item and the predicted result cannot be aligned.

I made a PR #156  for this issue.


Alter email to base64, because the regex enconding

Proposed changes
Changed the user email to base64 for the k8s labels objects, regarding to this issue. #3634
This was implemented based on this comment for PR #3648.
Types of changes
What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

[x] New feature (non-breaking change which adds functionality)
[x] Bugfix (non-breaking change which fixes an issue)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices applies)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[x] I have signed the commit for DCO to be passed.
[x] Lint and unit tests pass locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[x] I have added necessary documentation (if appropriate)

Dependency

Please add the links to the dependent PR need to be merged before this (if any).

Special notes for your reviewer:

Thanks, @deividMatos for this PR.

Thanks, @deividMatos for this PR.

Yes, I tested it with a member of my squad and we created several flows to test in different scenarios, all in local dev

Thanks @deividMatos for this PR! This will unblock a lot of users! Have test the changes and will take it as part of our next release! 🚀

Thanks @deividMatos works for us too !

Hi,
Could we decode this in the UI to display the originating user email ?

Hi @ludovic-pourrat , this is already handled in the UI. Attaching a screenshot for reference!

@amityt my bad my graphql-server was not updated, after applying the patch on my deployment, many thanks for your answer !


Add support for GatewayClass

Previously we just ignored this CRD. This adds support for properly
selecting only applicable gateways.

ping @istio/wg-networking-maintainers

@hzxuzhonghu yes, when the original impl was merged the GatewayClass was not fully defined yet

@howardjohn can you share a link to K8s Gateway Class Spec?

https://github.com/kubernetes-sigs/service-apis/blob/master/api/v1alpha1/gatewayclass_types.go#L47
On Tue, Mar 10, 2020 at 8:17 AM Neeraj Poddar<EMAIL_ADDRESS>wrote:

@howardjohn https://github.com/howardjohn can you share a link to K8s
Gateway Class Spec?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/21793?email_source=notifications&email_token=AAEYGXI3GNELQI2SG6WSMTTRGZKZPA5CNFSM4LAV4UPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOL27HA#issuecomment-597143452,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXIFQ7AWL2ZC6MHOGDDRGZKZPANCNFSM4LAV4UPA
.