"subtract" gives bad output.

Expected Behavior
Actual Behavior
Meshlab reports 12 non manifold vertices
64 faces over non manifold edges.
(I've seen this several times, here's a simple example.)
Steps to Reproduce the Problem
Run this: program output to .stl
const { cylinder } = require('@jscad/modeling').primitives
const { translate } = require('@jscad/modeling').transforms
const { subtract, union, intersect } = require('@jscad/modeling').booleans
const main = () => {
h = 8
size = 3
const inner_d = size*0.8
const outer_d = 4+size;
c1 = cylinder({radius: outer_d/2, height: h})
c2 = cylinder({radius: inner_d/2, height: h})
let shape = union(
subtract(c1, c2),
//translate([20, 0, 0],union(c1, translate([3, 0, 0],c2))),
//translate([0, 20, 0],intersect(c1, translate([3, 0, 0],c2)))
)
return shape;
}
module.exports = { main }
Run meshlab on the stl file.
Specifications
OpenJSCAD 2.2.21 [Linux:5.15.0-39-generic,linux:x64]

Version:
Platform:
Environment: (browser, local server, node.js etc) CLI

OK, put updated code in original support.
The union also has a similar problem.
The intersect works perfectly.
Is this by an chance, the "T-junction" problem?

Yea, the issues with boolean operations creating non-manifold geometries is well known. #807 #696 and others. Here's the simplest example I've found:
union(
  cube({ size: 8 }),
  cube({ center: [0, 0, 4] }),
)

The main issue appears to be creation of T-junctions as you mention. To fix it will require either:

Fix it inside the BSP operations, likely using a data structure which tracks adjacent faces, and anytime one face is split along an edge, the adjacent face must also have a vertex introduced.
Fix it after the fact with some kind of "repair" function. We kind of already have this, but it does not seem to work reliably. I suspect this fails due to small rounding errors.

sounds faster, and I am not sure if it will be more complicated to make a better fixing tool, or change BSP to track these splits.
I can only hope someone with better knowledge of computational geometry than me will find this problem interesting to fix :)

@platypii Thanks for that example, I'm sure that will be handy while I work on this!

Fix it inside the BSP operations, likely using a data structure which tracks adjacent faces, and anytime one face is split along an edge, the adjacent face must also have a vertex introduced.
I'm starting to question if the right criterion is being use see the union algorithm here.

Fix it after the fact with some kind of "repair" function. We kind of already have this, but it does not seem to work reliably. I suspect this fails due to small rounding errors.
I find this very unlikely to work. The boolean algorithms only work on manifold sets of polygons.
Anytime you do one of the booleans, there's a good chance you're not manifold. Subsequent boolean ops will have
undefined results. Not sure you can ever fix that sort of problem in generalize.

I'm busy until next week sometime.
I intend to go after the problem full blast when I get free. So if you want to beat me to it, now's the time. :-)
I've been hunting down reference materials.
https://www.gamers.org/dhs/helpdocs/bsp_faq.html
https://commons.apache.org/proper/commons-geometry/tutorials/bsp-tree.html
Here's a paper from 1990 about this...
http://www.cs.yorku.ca/~amana/research/bsptSetOp.pdf
Alas the scan of the paper is faulty at the edge!

I should have been more clear. The example I gave DOES produce a non-manifold geometry. But on export, generalize is called and is able to fix this example. There are other examples (like yours) that fail to repair even with generalize. The nice thing about my example was just that it demonstrates the same kind of underlying issue, with nice easy round numbers. This can be shown using geom3.validate:
const jscad = require('@jscad/modeling')
const { geom3 } = jscad.geometries
const { cube } = jscad.primitives
const { union } = jscad.booleans

const main = () => {
  const obs = union(
    cube({ size: 8 }),
    cube({ center: [0, 0, 4] }),
  )
  geom3.validate(obs)
  return obs
}

module.exports = { main }

Looking at @briansturgill's example.
Before generalize, it produces 326 non-manifold edges.
After generalize there are zero-area polygons, and 71 non-manifold edges. Even after repair.

nonmanifold.js
const jscad = require('@jscad/modeling')
const { subtract } = jscad.booleans
const { geom3 } = jscad.geometries
const { generalize } = jscad.modifiers
const { cylinder } = jscad.primitives

const main = () => {
  const c1 = cylinder({ radius: 3.5 })
  const c2 = cylinder({ radius: 1.2 })
  let shape = subtract(c1, c2)
  try { geom3.validate(shape) } catch (e) { console.log(e.message) }
  shape = generalize({ triangulate: true }, shape)
  try { geom3.validate(shape) } catch (e) { console.log(e.message) }
  return shape
}

module.exports = { main }

@platypii Thanks!
So, I think I've definitively shown that the adjacent faces is not the problem.
In a manifold object, every edge has exactly two faces. That edge will get split twice.
So I modified SplitPolygonByPlane to use a Dictionary (Map) of edges to returned values and then check for the
reverse edge to see if the adjacent was already done, returning the cached intersect point if it was there, so that the
points would definitely be the same.
It made no difference.
So, I just kept number track of the number seen and alternates seen.
Over half the alternates were not seen, so clearly something is wrong with the algorithm.
I don't think this is strictly a precision problem.
I think I'll try steping through one of your simple examples in the debugger next.

It's a problem of precision.
@platypii lets investigate those zero area polygons. The generalize functions should be removing those.

Ummm... I believe that was what the recently removed repair did. It was
generally not turned on anyway.
On Tue, Jun 21, 2022 at 4:36 PM Z3 Development @.***>
wrote:

It's a problem of precision.
@platypii https://github.com/platypii lets investigate those zero area
polygons. The generalize functions should be removing those.
—
Reply to this email directly, view it on GitHub
https://github.com/jscad/OpenJSCAD.org/issues/1113#issuecomment-1162430985,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYCO7ZRTTYHQAQHLH742H3VQI7XXANCNFSM5ZG4SNQA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Brian

The serializers call generalize if necessary to create triangular meshes, etc.

Form the paper on BSP trees...
Note that this code is not robust, since numerical stability may cause errors in the classification of a point. The standard solution is to make the plane "thick" by use of an epsilon value.
Which is the current approach being taken to classify polygons for clipping.

I've found a better PDF of the naylor journal article:
http://www.vjlove.com/publications/papers/siggraph90.pdf

Which is the current approach being taken to classify polygons for clipping.

Yes, but the problem (at least with the Cube, Cube example) is that it is not clipping properly.  Or more accurately, edges that should have been split were not. As I said, I think the algorithm implementation is faulty. (It's kind of a myth that there is a BSP union algorithm... generally the academics wave their hand and say it's possible. Note, I only have found only one other package that use BSP's for 3D at all, and that is the Apache Commons project I gave the link to earlier.)
None of the big packages (that are open source) use BSP trees.
Certainly the choice of plane for the split is very questionable.  It doesn't match at all what was said in:
https://www.gamers.org/dhs/helpdocs/bsp_faq.html

Anybody at an institution that has access to this: https://www.sciencedirect.com/science/article/abs/pii/S0010448512002412?via%3Dihub
It sounds like exactly what we are looking for.
Title: "Fast and robust Booleans on polyhedra"

Anybody at an institution that has access to this:

I am willing to bu iy for $32 if you are eager to try it out.

Anybody at an institution that has access to this:

I am willing to bu iy for $32 if you are eager to try it out.

I too am willing to buy it, but only if it looks like it really does what it is billed to do. Abstracts are unreliable.
I was hoping someone could take a look at it first to see if was implementable.
Academics are prone to hand waving when it comes to the hard parts.

So I think I may have figured out what is wrong with the Booleans algorithm. I think it may be for convex polyhedron.
We have convex polygons, but definitely not convex polyhedron [that would be wrong].
Anyway, it would explain why somethings are missed.
If I am right, we'll have to find a different algorithm.
I tried find evanw's email but didn't find it.
Perhaps we could ask him about the origins of the algorithm, that might quickly decide the matter.

The paper is on sci hub :innocent:
Also evan's email is in the git logs of https://github.com/evanw/csg.js though not sure its current

@briansturgill there are some more in the references
this one is may 2022 https://arxiv.org/abs/2205.14151 https://arxiv.org/pdf/2205.14151.pdf

Hm, I'm not seeing any effect from changing that line. On your example with the 2 cylinders, I get exactly the same numbers of non-manifold edges with EPS or with EPS * EPS. I looked at the values we were getting for distancesquared and they were all either like 0 or 0.001 or 1e-32. None were affected by choice of EPS = 0.00001 or EPS * EPS = 1e-10. Maybe I'm missing something?

Hm, I'm not seeing any effect from changing that line. On your example with the 2 cylinders, I get exactly the same numbers of non-manifold edges with EPS or with EPS * EPS. I looked at the values we were getting for distancesquared and they were all either like 0 or 0.001 or 1e-32. None were affected by choice of EPS = 0.00001 or EPS * EPS = 1e-10. Maybe I'm missing something?
@platypii

Perhaps I wasn't clear enough.  You do indeed still get manifold issues, etc. The changes only occur when you output an STL file. It is passing meshlab perfectly. In other words, you need to go through snap/insertTjunctions/triangulate.
I just went back and checked and that one change in insertTjunction fixes this sample:
(To be clear, I checked that (EPS*EPS) failed and just EPS works (in meshlab).
Git is showing no other changes in code. (Eariler I had many but backed them out.)

var g2 = new Geom2();
Geom3 TapPost(double h, double size, double post_wall = 2, bool add_taper = false, double z_rot = 0)
{
    var inner_d = size * 0.8; //Possibly snug, but with PLA I prefer that
    var outer_d = post_wall * 2 + size;
    var a = ExtrudeLinear(height: h, gobj: Circle(outer_d / 2.0));
    var b = (Geom3)Translate((0, 0, -1), ExtrudeLinear(height: h + 2, gobj: Circle(inner_d / 2.0)));
    a = Cylinder(radius: outer_d / 2.0, height: h);
    b = (Geom3)Translate((0, 0, -1), Cylinder(radius: inner_d / 2.0, height: h + 2));
    //a = Triangulate(a);
    //b = Triangulate(b);
    var gobj = (Geom3)Subtract(a, b);
    //gobj = (Geom3)ExtrudeSimpleOutlines(Circle(outer_d / 2.0), Circle(inner_d / 2.0), height: h);
    //gobj = Triangulate(gobj);
    //gobj.Validate();
    if (add_taper)
    {
        var cout = Circle(outer_d / 2.0);
        var cylout = ExtrudeLinear(height: h * 2, gobj: cout);
        cylout.Validate();
        var cin = Circle(inner_d / 2.0);
        var cylin = ExtrudeLinear(height: h * 2 + 2, gobj: cin);
        cylin.Validate();
        var cb = Cuboid((outer_d, outer_d, h * 3 + 2), center: (0, 0, 0));
        cb.Validate();
        var g3 = (Geom3)Subtract(cylout, Translate((0, 0, -1), cylin));
        //g3.Validate();
        g3 = (Geom3)Subtract(g3, Rotate((45, 0, z_rot), Translate((0, 0, h), cb)));
        //g3.Validate();
        gobj = (Geom3)Union(gobj, (Geom3)Translate((0, 0, -h * 2), g3));
    }
    return gobj;
}

/*
var a = Cylinder(radius: 4.5, height: 8, segments: 10);
a.Validate();
var b = (Geom3)Translate((0, 0, -1), Cylinder(radius: 2, height: 10, segments: 10));
b.Validate();
var g = (Geom3)Subtract(a, b);// TapPost(8, 5, add_taper: false);
*/
var g = TapPost(8, 5, add_taper: true);
Save("/tmp/test.stl", g);
//g.Validate();

So, EPS (1e-5) might be too large:
For:
g = Union(Sphere(radius: 20), Translate((5, 5, 5), Sphere(radius: 20)));
Save("/tmp/test.stl", g);

I set the value to 1e-6 and get no errors from meshalb.
At 1e-5. it causes 1 failure that was different (I thought maybe it "fixed" a T-junction that wasn't a T-junction.
However, 1e-7 and below still sees errors from unfixed T-junctions.
The real solutions is to of course not to create T-junctions to begin with.
One serious problem with the current algorithm is it doesn't require triangulation.
Booleans are much simpler when everything is a triangle.

OK, I've tried various values, it looks like 1e-6 works the best.
This is all very much a hack though.

Ok, after mind numbing searching, I think I've found the general approach that should be used to replace 3D boolean processing.
This approach is used in Blender and CGAL and apparently in OpenGL as well.
It requires that meshes be triangulated.
There are a number of papers:
https://cims.nyu.edu/gcl/papers/zhou2016mas.pdf
https://arxiv.org/pdf/1601.07953.pdf
https://igl.ethz.ch/projects/winding-number/robust-inside-outside-segmentation-using-generalized-winding-numbers-siggraph-2013-jacobson-et-al.pdf
https://www.dgp.toronto.edu/projects/fast-winding-numbers/fast-winding-numbers-for-soups-and-clouds-siggraph-2018-barill-et-al.pdf
These 4 papers all contain Alec Jacobson (ETH & Univ. Toronto) as a primary/co-author.

Sorry to jump in late; I just found your library. I too am a big fan of OpenSCAD, web development, and computational geometry. I've been building a library that might be helpful on the Mesh Boolean front: https://github.com/elalish/manifold
It's C++, but we now have a WASM build that's <200kb; you can see a really basic test here. I built it from the ground up for topological robustness; I can't promise there are no bugs, but I think it avoids a lot of the problems being talked about here. If anyone wants to kick the tires, I could definitely use more bug reports.
As a bonus, it's also several orders of magnitude faster than OpenSCAD: https://elalish.blogspot.com/2022/03/manifold-performance.html (and it's had some performance improvements since this was written).

@elalish wow, that looks promising indeed. We are definitely interested in making the boolean engine plugabble at some point and also explore what there is. I am also very curious seeing that you also have a gpu variant.

Sorry to jump in late; I just found your library. I too am a big fan of OpenSCAD, web development, and computational geometry. I've been building a library that might be helpful on the Mesh Boolean front: https://github.com/elalish/manifold
...
@elalish Interesting, does the algorithm you are using require the meshes to be triangulated. (Our current one doesn't, but I'm having trouble find one to replace that directly.)
I'm doing a C# translation of JSCAD, with a Python API Wrapper. C++ is somewhat problematic for me, though I guess I could translate that too. :-)

I don't think you're late to the game at all... currently focused on fixing the 2D problem. But 3D needs done too!

So, yes and no. Manifold's API is based on triangle meshes (I wouldn't trust an input polygonal face to be planar). However, a Boolean operation obviously creates polygonal faces from triangle inputs, so I have internal triangulation and decimation routines to return it to a clean triangle mesh. I invented by own robust triangulator as part of writing this library, since none of the existing ones could guarantee manifoldness and handle rounding errors the way I wanted.
The Boolean itself can operate on polygon meshes and I tried that approach (leave the internal data structure polygonal and only triangulate at the end as needed), but it turns out there are nasty edge cases when input polygons are nearly coplanar and when the polygons have holes. It's much more reliable to triangulate at each step.

@elalish

The Boolean itself can operate on polygon meshes and I tried that approach (leave the internal data structure polygonal and only triangulate at the end as needed), but it turns out there are nasty edge cases when input polygons are nearly coplanar and when the polygons have holes. It's much more reliable to triangulate at each step.

Yeah, that's the conclusion I've been coming to as well... First I need to get 2D Primitives and Extrudes robust and properly triangulated (almost there), then I'll tackle 3D. Any suggested papers for 3D mesh booleans? Oh, I love the GPU stuff.... but not likely practical for my own project at this stage.

Manifold already has a Python API wrapper, in addition to WASM. Is there a reason you can't use it directly? It has extrusion with triangulation and lots of other handy functions. If you're interested in collaboration, it would be great to flesh out our 2D subsystem (I'm thinking of taking a dependency on clipperLib).

Working on 3D now. Does anyone know why the retessellation of coplanar polygons were added to the booleans?
The algorithm seems to be designed to remove the triangulation that I so having been adding.
Why did someone thing this is needed? I tried to look in the git logs, but it only goes back to the last source tree reorganization.
Anyway, I have commented it out at the moment, and it doesn't seem to hurt anything.

Working on 3D now. Does anyone know why the retessellation of coplanar polygons were added to the 3D booleans?
The algorithm seems to be designed to remove the triangulation that I have been working so hard to add.

simply to reduce the number of small polygons, which is a by product of the booleans.

Ok, now I know way more about BSP trees than I ever wanted to know.
I also no why the retessellation was absolutely necessary... in fact Naylor knew about this problem in 1990.
I add some paper links in the next comment.
The short version:
The BSP boolean algorithm is severly broken. As Naylor admits the problem, one thinks it might be an intractable problem.
But the problem with boundary conditions (i.e. T-junctions) and the tiny triangles are all expected. JSCAD is amazing in that it was made to more or less work.
Here's his comments (THE UPPER CASING IS MY EMPHASIS.)
He fails to mention the real problem is that the algorithm breaks things up so oddly that it is impossible to act on structural knowledge.
VII.  Numerical Robustness

The occurrence of numerical errors due to finite arithmetic has
been a nemesis of geometric computing since its inception. Its
negative impact is greatest when the result of a numerical com-
putation is used to discriminate logical alternatives in an algo-
rithm. This can lead to arbitrarily "discontinuous" behavior;
that is, the output of the algorithm can be highly sensitive to~
small random perturbations of the discriminators (the program
may fail as well). While a number of schemes have been devised
to ameliorate the problem, the simplest and most common is
the use of e-intervals. For example, a discrimination based on
whether a real value X is less than, greater than, or equal to 0
can be replaced with one that determines whether a X < -e, X >
+E, or in [ - e +el respectively. More sophisticated methods
enforce the intended semantics through a variety of schemes (
see e.g. [Karasiek 89]).

The only numerical computation in this work is the parti-
tioning of a polygon by a plane. Its primitive operation is the
dot product of a point and a plane to determine the location of
that point with respect to the plane. The specific algorithm we
use assumes the semantics of planar, convex polygons, and we
rely on the epsilon method just described to attain robustness
(to dampen the noise). Thus, the hyperplanes are in effect slabs
2E thick. ANY FAILURE OF THIS TECHNIQUE IS DETECTED, BUT NO
CORRECTION STRATEGY IS EVIDENT OTHER THAN USING LARGER EPSILONS
(THIS HAS BEEN IN USE SINCE [Naylor 81]).

Unfortunately, THIS APPROACH IS INSUFFICIENT TO ACHIEVE A RO-
BUST BI-PARTITIONING OPERATION. In fact, larger epsilon exacer-
bate the problem. Recall that there is a correlation between the
location of the two bps: P l ' s location = IrgBoth ¢=> P2's loca-
tion = InBoth, and similarly On ¢=> On, and NotInBoth ¢0
NotInBoth . Numerically this does not always hold. OUR AP-
PROACH IS TO DETECT INCONSISTENCIES AND INDUCE A MAPPING TO ONE
OF THE CONSISTENT RESULT. When one location is InBoth and the
other is InNegHs or InPosHs, we can force the the former to be
either InNegHs or InPosHs by selecting the "half" which
contain vertices farthest from the partitioning plane, or we can
force the second to the InBoth condition by extracting "on"
vertices. If only one bp is On, we force it to a value consistent
with the other bp. WHILE WE BELIEVE THAT FORCING SEMANTIC CON-
SISTENCY IS ESSENTIAL, OUR CURRENT CHOICES FOR ENFORCING THIS ARE
AT THIS POINT ONLY TENTATIVE.

NUMERICAL PROBLEMS ALSO AFFECT ATTAINING THE SEMANTICS OF
THE NEIGHBORHOOD OPERATION. The method used for constructing
bsp trees, defined in the continuum, implies that any sets lying
in T.root region.bp.shp will not be On any sub-hp in either of
T's subtrees; however, NUMERICALLY THIS DOES NOT ALWAYS HOLD.
We employ the following defense. When a face fragment from
node V is classified as On during the neighborhood operation at
a descendant node U, we essentially treat that node as if it were
contained in the face's sub-hp, i.e. as if it did not exist. We
then choose the subtree of U that is "not adjacent" to V, and
continue the search.

The combination of these techniques has led to a robust set
operation algorithm is the sense that the program will not fail
and its output is in the neighborhood of the ideal output over a
large numerical range. For example, the standard test in which a
set operation is performed between a cube and a second cube
that has been rotated successively about each of its three prin-
cipal axes by an angle 0t has been executed successfully with
viewing resolution. AN UPPER BOUND TO THE THICKNESS IS THE
POINT AT WHICH THE AFFECT OF TREATING FACES AS BEING CO-PLANAR,
WHEN IN FACT THEY ARE NOT, BECOMES VISIBLE TO A VIEWER.

The paper quoted above is "Merging BSP Trees Yields Polyhedral Set Operations"
http://www.vjlove.com/publications/papers/siggraph90.pdf
I believe than evanw may have been using either an early version of this paper, or else both he
and this group of students learned from the same source:
https://static1.squarespace.com/static/51bb9790e4b0510af19ea9c4/t/51bf7c34e4b0a897bf550945/1371503668974/CSG_report.pdf
That group of students seem to have hit similar problems to what we have experienced.
It is amazing that JSCAD has gotten things to work as well as they did.
Anyway, I'm moving on to rolling my own algorithm.
Most things these days are hardware oriented. Old school approaches even worked on arbitrary polygons.
Though do to colinear/coplanar issues, one is definitely better of with triangles.
So using what I've gleened from O'Rourke and others, I'm going to take the obvious  old school approach, but on triangles.
The first cut will be O(n)+O(m^2) where in "n" is the number of polygons and m is the number of polygons not culled by a bounding-box exclusion.
In the end I expect I'll end up with O(n)+O(m log m) as there are various techniques to cut down on the intersection checks.

@briansturgill Indeed, I started my Manifold library because A) some folks I worked with in the CAD industry said a robust mesh boolean operation has been an open problem for a long time and they didn't think it was feasible to solve and B) I found someone's dissertation that outlined a new approach avoiding floating-point error entirely. It's taken me years, but I haven't found a manifoldness error in ages. Might you be interested in collaboration? It's a long road to reimplement.

... It's a long road to reimplement.

I'm not entirely ruling the possibilty of collaboration out, but I think I'm a lot closer than you think I am.
O'Rourke Computation Geometry in C is a good place to look at the old school approach to booleans.
Note, we might be talking at cross-purposes here.  If you are dealing with meshes for more than say 3D printing... especially if you are dealing with models that will go through constant hardware manipulation... robutness has a much different meaning.
For my purposes (an OpenSCAD replacement), being what is sometimes called "numerically stable" is sufficient.
You aren't going to put such a model through 1,000,000 random boolean ops. You just need to not be sloppy.
I've already gotten the rest in line... I just need the 3D booleans. They really are not that hard, especially as I am not doing realtime stuff. I just need to get the performance to be sufficient. I'll be very shocked if I can't beat the existing algorithm in a couple of week's time. Mostly because the existing algorithm needs FOUR different fix-it passes. Really, that's just sad.

Looking at this topic I am more and more convinced that jscad take more effort in separating modeling part of the library from the actual boolean operations, or even further than just booleans.
One big reason is that I have different priorities for the output precision correctness and speed depending if I am rendering preview or exporting for 3d printing .
@elalish I have bookmarked manifold, and hopefuly will have time in the future to play with it too :)

Also I would like to point you to checkout https://github.com/bluelightning32/walnut
A design doc for how the internals of Walnut work is available at: https://docs.google.com/document/d/1G9616Bs4OURC1fKEUgY0b25A_Wra7Mn9mVxW1SmjVRY/edit?usp=sharing

Thanks for the pointer, that library looks cool. I was thinking about how to fix up non-manifold / self-intersecting input and that looks like it could help.

@elalish

... It's a long road to reimplement.

Coming around to believing this.
Amazing how the academic papers punt on the hardest parts (while still claiming to be robust).
My biggest problem is I really want to avoid the C++.
The C++ you use is very modern and kind of out there (i.e. lots of C++ only features used).
It does appear to be good code though.
Still, it would be a bear to translate to C# or JS.
It's not small either... 2x the size of 3D booleans in JSCAD?
I am currently looking at bridging to Manifold so I can get some speed comparisons.

@briansturgill I just got a notification from you on this thread, but your comment seems to have vanished. Anyway, I thought you might be interested in a JS example of manifold: https://elalish.github.io/manifold/bindings/wasm/examples/model-viewer.html - the whole library is <150kb gzipped.

@elalish Yeah, I posted, then deleted it as I haven't made up my mind.
I agree that "It's a long road to reimplement".
Every academic source left out the hardest parts, yet still claimed to be robust.
Much of the open-source is not really open (tied up in GPL).
I've been through several algorithms in detail in the last few weeks and several things are true:

Implementations, even when using exact arithmetic, fall short of robust, often failing to even to do manifold.
All algorithms I've seen need much post processing to fix things.
Many algorithms/implementations admit up front that their 3D booleans are not robust.
Looking at Smith's dissertation, it is clear that he doesn't really do everything he says (and your own writeup about implementation confirms that).

Note the above seems to be true of Manifold as well (except you've focused on being manifold).
So, I'm in a quandry. Manifold is roughly 2x bigger than the equivalent code in JSCAD. I suspect that the algorithm is faster,
but that isn't certain. Both algorithms are complex and only running head to head with the same examples on the same
hardware would determine relative speed.
I had written (in the post I deleted) that I was about to attempt that comparison, but when I started in on trying to compile
the code, I discovered you had only compiled it on Linux. Having done a lot cross-platform C++ in my life, this was
the last straw... I'm not interested in trying to get it to work on the 4 (soon 5 or 6) platforms I want this to run on.
C++ always claims to be portable, but life is very unpleasant there.
My C# code (developed on Linux) ran first shot on Windows and MacOS. NO RECOMPILATION WAS NEEDED!
Though recompilation to native also worked first shot.
So, I'm beating on the insertTjunction code again, trying find a way to get objects to be manifold after each operation.
If necessary, I'll just make the validation not check manifold if it's been through a boolean op.
In the end, I've gotten things to be reliably manifold after post-processing, but only if the geometry has been snapped,
which you can only do that once without causing problems.
Adding the geometry flag for it being through a boolean op would also be helpful in knowing that the insertTjunction was actually needed. (Currently, all output goes through that.)
I don't see a way forward with Manifold... translating that modern C++ (good code BTW) to C# would be very difficult.
I would not attempt it without some evidence that the algorithm was significantly faster than the current one.

Thanks for the writeup; I agree with most of what you're saying. However, a few things:
We do in fact have Manifold now compiling on a variety of targets, including Windows (build steps in yml, CI results). Github doesn't have a MacOS CI, but a user did report that it worked there with LLVM (obviously not the CUDA-accelerated version, but the single-threaded is fine). And of course we have the WASM build, which I figured was the only part that would matter for OpenJSCAD, given the name, but perhaps I'm missing something?
I would say your 1-3 points do not in fact apply to Manifold; really it's whole purpose of existence is solve those for the first time. It does do post-processing, but that is for performance and ease of use of the output. It is guaranteed manifold at every step (this used to only be true for geometrically-valid input, but even that requirement has now been removed).
I appreciate the code review in any case! I really need to update our README; a lot has changed. I don't know that Manifold is significantly faster than what you have now, at least in single-threaded mode. I would expect it to be about the same or better - it's the guaranteed manifoldness that sets it apart.

Github doesn't have a MacOS CI

I think it does, you can take a look at this as an example . You can also take a look at MacOS jobs here .

@elalish

... And of course we have the WASM build, which I figured was the only part that would matter for OpenJSCAD, given the name, but perhaps I'm missing something?

I'm with CSharpCAD (and Pycscad)... a port of JSCAD that has some extras (and is missing a few things too)... I share code/bug reports/ideas with the JSCAD people but am not a part of their team.
Have you ever run your WASM version against JSCAD?

which I figured was the only part that would matter for OpenJSCAD, given the name, but perhaps I'm missing something

you are right here regarding jscad, I have bookmarked manifold to look into at some point later

@briansturgill Gotcha; indeed it's less appropriate for CSharpCAD 😄 We do have Python bindings now if that's useful.
Thanks @udif, I didn't realize that. We'll have to add it.
We're working on getting a v2.0 out the door fairly soon; a lot of work has happened in the last 6 months! So stay tuned for that release.

@elalish  I discovered that the Bytecode Alliance released wasmtime-dotnet 1.0 5 days ago, so I was going to try Manifold for speed. But I cannot get it to build. I am confused, you seem only to build it with Github CI?
I just wanted to get Python and WASM versions under Linux.

Cool! Would you mind filing an issue with your build difficulties? I have been using manifold.yml as our canonical build instructions since the CI validates they are complete and correct. As I say, I need to update the README with some distillations of that. But seeing the troubles people have will help me know what to write there.

I'll probably do more of this discussion to Manifold's board, but felt this thread needs an update.
@elalish where would you want this done, Discussions?
Using union script by @platypii (translated to python and adding subtract and intersect) I managed to get a first round of timing tests comparing the C# version of the BSP algorithm with Manifold's algorithm, both using their Python bindings.
I then spent the rest of the day trying to figure out if it was actually true. I've been through it thoroughly and it appears that Manifold's booleans are 3 ORDERS OF MAGNITUDE (1000x) faster than the BSP-based booleans in JSCAD/CSharpCAD.
There are some caveats.
First, the sphere code between the two was different, but I changed the segment values (100 for JSCAD/CSharpCAD and 150 for Manifold) so that  the resulting sphere had approximately the same number of vertices and faces.
The Python interface to C# is probably less efficient than the one to Manifold, however the overhead is probably not substantial realtive to the operations being tested.
The test by @platypii is edge case oriented... I don't know if that is having an effect or not.
Finally, JSCAD/CSharpCAD is faster handling the "disjoint" case as we have special handling for that. I'm assuming Manifold doesn't bother checking (it's still very fast for that case).
Here is my code for Manifold:
from pymanifold import Manifold
from time import time_ns

segments = 150

def test(x, radius, name):
    s1 = Manifold.sphere(radius=1, circular_segments=segments)
    s2 = Manifold.sphere(radius=radius, circular_segments=segments).translate(x, 0, 0)
    start = time_ns()
    ret = s1+s2
    finish = time_ns()
    if name == "ignore":
        return
    print("union", name, (finish-start)/1000000.0)
    start = time_ns()
    ret = s1^s2
    finish = time_ns()
    print("intersect", name, (finish-start)/1000000.0)
    start = time_ns()
    ret = s1-s2
    finish = time_ns()
    print("subtract", name, (finish-start)/1000000.0)

test(4, 1, "ignore");
test(4, 1, "disjoint");
test(2, 1, "touching");
test(1, 1, "overlap");
test(0, 1, "same");
test(0, 0.5, "inside");

Using separate programs, I checked the output from Manifold and it appears correct. Indeed, in the case "union overlap", CSharpCAD was producing output that was not manifold. Manifold handled it correctly.
I'm hoping someone on the JSCAD team will attempt timing tests with the WASM version.
I will be working on the WASM version (under C#'s new wasmtime package) soon.

@briansturgill, @elalish  that is great news, looking forward to trying out manifold wasm

Thank you @briansturgill! You really made my day with your analysis.
Manifold does in fact have a fast path for disjoint inputs, but it could probably use further optimization; I'd guess we're not skipping as much as we could.

Oh, forgot to answer the question: Yes, please start a Discussion thread in Manifold.

I've also got issues with a subtract call (slicer mentions "open edges"), would this be the same issue? and if so, are there any workarounds currently available?
Here's a screenshot from Blender, the selected vertex can be moved freely away from the vertical face. Is that what is considered an "open edge"?

Code below, without the final subtract code the slicer doesn't complain about any open edges
model.js
const { sphere, roundedRectangle, cube, line } = require('@jscad/modeling').primitives
const { extrudeLinear, extrudeRectangular } = require('@jscad/modeling').extrusions
const { translateZ } = require('@jscad/modeling').transforms
const { subtract } = require('@jscad/modeling').booleans

const main = () => {

  const mm = 1;
  const cm = 10;

  const widthOuter /* (X) */ = 20 * cm;
  const depthOuter /* (Y) */ = 10 * cm;
  const heightOuter /* (Z) */ = 10 * cm;
  const bottomThickness = 2 * mm;
  const wallsThickness = 4 * mm;
  const radius = 1 * cm;

  const baseshapeCenter = [0, depthOuter/2]
  const baseshape = roundedRectangle({ center: baseshapeCenter,  size: [widthOuter, depthOuter], roundRadius: radius });
  const ext = extrudeLinear({ height: heightOuter}, baseshape);

  const radiusInner = radius - wallsThickness;
  const baseshapeNeg = roundedRectangle({ center: baseshapeCenter,  size: [widthOuter - 2* wallsThickness, depthOuter - 2 * wallsThickness], roundRadius: radiusInner });
  const extNeg_ = extrudeLinear({ height: heightOuter - bottomThickness}, baseshapeNeg);
  const extNeg = translateZ(bottomThickness, extNeg_);
  const res = subtract(ext, extNeg);
  return [res, sphere({size: 10})]
}

module.exports = { main }

Let me know how I can help, I'm keen to get this resolved!

manifold library has come a long way from when this thread was started. I am following it closely, and finally have some basinc examples working in jscad.app. My guess with manifold you would not have those errors @nmattia.
I firmly believe future of jscad is in adopting manifold (if not completely, at least as an optional CSG backend)

@hrgdavor thanks! I'm actually giving it a try. The API reference seems to have moved so it's a slow but promising start (the part that failed in JSCAD is exporting without issues in Manifold).
I did have a look at the JSCAD sources and I'm actually not sure it's a boolean issue afterall (in my case); looks like it might be an issue with the way JSCAD triangulates. The STL export does have some triangulation code but AFAICT it shouldn't actually run because the model goes through triangulatePolygons & friends first. Once I got there I decided to give Manifold a go 😬
Will report on how that goes!

@udif JSCAD internally does care if polygons are triangulated or not. That's the biggest difference with modern CSG engines.
let us know if you find anything suspicious, and can reproduce with a fairly simple test.

I've also got issues with a subtract call (slicer mentions "open edges"), would this be the same issue? and if so, are there any workarounds currently available?
Here's a screenshot from Blender, the selected vertex can be moved freely away from the vertical face. Is that what is considered an "open edge"?
Code below, without the final subtract code the slicer doesn't complain about any open edges

@udif can you supply the name of the slicer? There are many and many are subpar when dealing with mesh issues.
Blender also has 'repair' functions as Blender itself can produce invalid meshes.
My personal favorite is Meshlab. You might want to look at this application.

@z3dev do you mean @nmattia ?
The slicer is PrusaSlicer, which does autorepair. Regardless of the slicer, the blender screenshot does show the issue. IIUC the technical term for the STL rule being broken here is "vertex-to-vertex rule":

Vertex-to-vertex rule. Each triangle must share two vertices with each of its adjacent triangles. In other words, a vertex of one triangle cannot lie on the side of another.
fabbers.com, The Stl Format

Or do you mean that, upon import, Blender messed with the Mesh which makes the screenshot moot? I'll admit I didn't read the actual STL output... 😂
Thanks for pointing out Meshlab, I'll keep it in mind!

Coming in from the Manifold side of things... Please keep in mind that STL is a lossy format regarding manifoldness. Effectively all STLs (even ones produced from a proper manifold) require fixing and that fixing process is heuristic and can easily result in a previously manifold mesh becoming non-manifold, but worse, the results will be different when imported through different software. I would strongly recommend 3MF (or even OBJ) as alternatives that actually encode manifoldness (topological) data. I also authored an EXT_mesh_manifold extension to glTF that works properly even when you have discontinuous vertex properties on a mesh.

The slicer is PrusaSlicer, which does autorepair. Regardless of the slicer, the blender screenshot does show the issue. IIUC the technical term for the STL rule being broken here is "vertex-to-vertex rule"

This the typical issue reported as booleans operations do not produce 'watertight' meshes. That's why all the generalize functions were created. The output is typically good enough for the slicers to print or to fix.

Or do you mean that, upon import, Blender messed with the Mesh which makes the screenshot moot?

Absolutely not. I was just wondering which slicer was being used. Not all slicers are the same, and Prusa is one of the better ones.


Remove a11y alert till we have no a11y issues

The purpose of the a11y alert we have when running Headlamp in default mode is so we find regressions in a11y. This is a very good idea because it's a very direct way to realizing when things related to a11y have been broken, which would otherwise get in the code.
However, we do have some a11y issues as of now and the popup is just shown every time at the beginning of running Headlamp, which prompts everyone to just dismiss it automatically hence defeating its purpose of showing up right when a11y regressions happen. All this means a11y issues keep growing, which render the alert just an annoyance.
Therefore. I think we should fix the a11y issues if they're not too many. If they are, we should just disable the alert and then fix the a11y issues (so we have a few weeks without annoying developers with it), before bringing the alert back.

Fixed by #984 .


MariaDB & mySQL testing

On MariaDB 10.3.12

[x] Questions update
[x] Groups update
[x] Answers update
[x] Labels update
[x] DefaultValues update

Checked on 5.6.39-1

[x] Questions update
[x] Groups update
[x] Answers update
[x] Labels update
[x] DefaultValues update

And count is OK too

Checked on mantis DB : one answers lost , but it's OK !


Add more types in the pull request template

Type of change:

[ ] Bugfix
[x] New feature provided
[ ] Improve performance
[ ] Backport patches

What this PR does / why we need it:

This PR adds new types in the pull request template since the ones provided currently do not cover all scenarios of pull requests. Should fix #1572 .
Pre-submission checklist:

[x] Did you explain what problem does this PR solve? Or what new features have been added?
[ ] Have you added corresponding test cases?
[ ] Have you modified the corresponding document?
[x] Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

Codecov Report

Merging #1644 (f0921cc) into master (7503056) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1644   +/-   ##
=======================================
  Coverage   41.09%   41.09%
=======================================
  Files          88       88
  Lines        7550     7550
=======================================
  Hits         3103     3103
  Misses       4087     4087
  Partials      360      360

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


Using multiple Layouts

Hey I don't see how to properly use multiple layouts. I have two layouts, but when using Flow Router to change the URL and try to load the new layout, it works but then gives this message:
react-runtime-dev.js?8fefd85d334323f8baa58410bac59b2a7f426ea7:21998 Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
 (client) <body class="pushable
 (server) <header data-reactid=```

And eventually this:

```Exception from Tracker recompute function:
Error: Invariant Violation: ReactMount: Root element ID differed from reactRootID.```

What is the proper way to change layouts between pages?

Can I have a sample app for this?

@arunoda actually I figured it out. It appears the structures weren't the same so it couldn't diff the two doms. So I made sure that both layouts had an outer  with a  inside. Now it works. Thank you!


Create contribution guidelines

@mrkara Hi Muhammet, is this still valid or can we close this please?

After clarifying with @mrkara , closing this issue as 'Wont Fix', as only maintenance and bug fixes will be carried out for legacy Signer


About a new chart dataset in Chinese.

Thanks for your great work.
I just wonder whether to have a plan for creating and opening source a new chart dataset in Chinese?
Thanks.

I think it is hard. One reason is that both CLIP and Llama are hard to understand Chinese. Maybe Qwen-VL is more appropriate for this purpose?

Thanks


kdb: switch to python3

Description of changes
kdb supports python3 as of https://github.com/KDE/kdb/commit/7e5633c36316cd8cf180eae982c5bc4574bb62bf

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 169631 run on x86_64-linux 1

3 packages marked as broken and skipped:

kexi
libsForQt512.kdb
libsForQt514.kdb

1 package built:

libsForQt5.kdb (libsForQt515.kdb ,plasma5Packages.kdb)


fs_rename can't rename only casing of files on case-insensitive systems

fs_rename will error when you try to rename File.txt to file.txt on MacOS, which has a case-insensitive file system by default. I assume this is, because it checks if the file exists, before attempting to rename it. If there is a file file.txt, also File.txt will return true for the check, since the file system is case-insensitive.

Platform: Darwin Martins-MacBook-Pro.local 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64

Ref: https://github.com/nvim-tree/nvim-tree.lua/issues/914

uv_fs_rename() straight up calls rename(2) so whatever error you're seeing comes directly from the operating system, not from any extra leg work that libuv is doing.
That said, I can't reproduce what you're describing. It simply renames the file. I run an older version of macOS, though.

I can't reproduce this in any form either. And I am on the absolute latest release (13.2–22D49) with standard APFS settings

Ok this is weird. It's a problem in Neovims nvim-tree and it's said that renaming a file or directory is done using uv.fs_rename(). Maybe rename is structured this way and Finder is circumventing this issue? Since mv also seem to not have this problem it probably also circumvents the edge case?


Update PHP to 8.2

#54

[ ] This might need some faffing with PHP extensions, etc.

We should remove deprecation warning before bumping the PHP version.

Things that stop it working, yes. There are definitely deprecations, which are unavoidable as it still supports PHP 5.6+ and various libraries include deprecated code (mostly Guzzle). They're usually hidden unless you define PLATFORMSH_CLI_REPORT_DEPRECATIONS=1 as an env var and run with -vvv.

Rebased

Rebased again / updated to 8.2.10

$ ./internal/legacy/archives/php_linux_amd64 --version

PHP 8.2.10 (cli) (built: Sep 20 2023 16:58:29) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.10, Copyright (c) Zend Technologies

$ ./internal/legacy/archives/php_linux_amd64 -r 'foreach (["curl", "json", "openssl", "pcre", "phar", "zlib", "posix", "pcntl"] as $ext) echo extension_loaded($ext) ? "$ext: found\n" : "$ext: not found :(\n";'

curl: found
json: found
openssl: found
pcre: found
phar: found
zlib: not found :(
posix: found
pcntl: found

Rebased + updated to 8.2.11

I've added zlib
I haven't tested if this builds OK for Windows / OS X / ARM

Deprecation warnings are gone and everything seems to be working great!


UC8151 fast/turbo PLL setting is immediately overwritten

UC8151::Setup takes LUT speed as an argument, which determines which function to call to set the lookup table registers for that mode. This happens early in Setup:
https://github.com/pimoroni/pimoroni-pico/blob/68d87d1f6e8a033193188e5d567b79a3a0e26767/drivers/uc8151/uc8151.cpp#L337-L353
In UC8151::fast_luts() and UC8151::turbo_luts() PLL control register is set to 200Hz:
https://github.com/pimoroni/pimoroni-pico/blob/68d87d1f6e8a033193188e5d567b79a3a0e26767/drivers/uc8151/uc8151.cpp#L231-L234
But at the end of UC8151::Setup it is always set back to 100Hz again
https://github.com/pimoroni/pimoroni-pico/blob/68d87d1f6e8a033193188e5d567b79a3a0e26767/drivers/uc8151/uc8151.cpp#L384-L386

Testing with 200hz PLL setting with my Rust port of this driver seems to not work either.
It's very likely that without having this line overriding the value to HZ_100 that fast and turbo LUT modes would not work.
They do function if I set the PLL to 150hz (0b00101001), but the result is not as good as 100hz.
Also, the notes seem to imply that default_luts is equivalent to the OTP LUT, but it seems significantly slower - OTP is much closer to the medium LUT setting in terms of time taken.


Fast forward resolved/rejected promises with fibers await

This makes awaiting an already resolved promise significantly faster.

Looking forward to also seeing similar changes in the v2/v3 branches 👍

@clue Once this one lands, I'll port it to the v2 and v3 branches.


Speed Question for single machine and distribute training

Below is the speed output:
For one gpu, single machine:
Node[0] 06:49:12 INFO:root:Epoch[5] Batch [47]	Speed: 161.80 samples/sec	Train-Perplexity=892.936346
For distribute training, three workers
Node[0] 06:49:12 INFO:root:Epoch[5] Batch [47]	Speed: 161.80 samples/sec	Train-Perplexity=892.936346
Node[1] 06:49:12 INFO:root:Epoch[5] Batch [47]	Speed: 161.80 samples/sec	Train-Perplexity=892.936346
Node[2] 06:49:12 INFO:root:Epoch[5] Batch [47]	Speed: 161.80 samples/sec	Train-Perplexity=892.936346
Could I say that, the speed for single machine is 161.80 samples/sec, the speed for distribute training is 161.80*3 samples/sec

Anyone can help me?

This issue is closed due to lack of activity in the last 90 days. Feel free to ping me to reopen if this is still an active issue. Thanks!


1.0.22 App Store 베타 빌드 심사 통과 못함

이슈 내용
Guideline 1.2 - Safety - User Generated Content
We found in our review that your app includes user-generated content but does not have all the required precautions. Apps with user-generated content must take specific steps to moderate content and prevent abusive behavior.
Next Steps
To resolve this issue, please revise your app to implement the following precautions:

A mechanism for users to block abusive users

Resources
Learn more about our policies for user-generated content in App Store Review Guideline 1.2.
Screenshots

App Store Review Guideline 1.2 참고

공유패널, 업로드 화면에서 글 작성 시, 신고하기 화면 등에서 경고성 문구 추가가 필요해보임

1.0.23 버전에서 승인됨


xiaomi.airc.r24r00 gives invalid value 101 for Filter Life Level

Describe the bug
xiaomi.airc.r24r00 gives invalid value when no filter is installed.
Expected behavior
disable filter field or shows N/A while its not applicable
Debug log
[homebridge-miot] This plugin generated a warning from the characteristic 'Filter Life Level': characteristic was supplied illegal value: number 101 exceeded maximum of 100. See https://homebridge.io/w/JtMGR for more info.

Additional context
this.addPropertyByString('filter:filter-life-level', '{"siid":21,"piid":1,"type":"urn:miot-spec-v2:property:filter-life-level:0000001E:xiaomi-r24r00:1","description":"Filter Life Level","format":"uint8","access":["read","notify"],"unit":"percentage","valueRange":[0,101,1]}');

The range is currently autogenerated, more manual override may be required.

That is kind of odd as we assume that filter life level is a value between 0 and 100%. What the heck does 101% mean for the filter life level?😅
I guess we would need to manually adjust the auto generated class and set those to 100% max, could you test that out and provide a pull request?

"valueRange":[0,100,1]}'

tried this, still generating the warning

Then I would need to have a look and handle that in code.

Should be fixed with version 1.7.2


[ios] problem building on iPhone

@lazaronixon Does anything need to be done for building project on a phone?
anyone else encountered this?

thanks!

Are you did this step?
Installation iOS
Drop /node_modules/react-native-turbolinks/ios/Turbolinks.framework to XCode Embedded Binaries and then check "Copy items if need" when it is prompted.
Install Turbolinks Framework IOS
After that check if a copy of Turbolinks.framework is in your ios project folder. If not copy it manually.

yes, and the .framework is in iOS folder
tried to google a little ( keep in mind that this is beyond me ), can it have anything to do with the valid architectures for the turbolinks.framework?

Did you run?
npm install react-native-swift --save

yes yarn add react-native-swift so its in there

to clarify, it works on simulator but not when I build Generic or onto phone

Thank you I will test it

Fixed https://github.com/lazaronixon/react-native-turbolinks/releases/tag/v1.2.8

still having problem

All is working here... I pushed a production app to App Store today.


Readme is missing AsyncContext usage

I always have to look up how to use AsyncContext on your stack overflow answer: http://stackoverflow.com/a/9212343/360211
I think this use case would be good in the ReadMe.

This issue is solved now.

@cable729 I haven't added it to the README yet.

AsyncContext is in markdown now rather than wiki, and indirectly linked to from the README.


arp-speaker compile fails for ARM

Is this a bug report or a feature request?:
bug
What happened:
CGO_ENABLED=0 GOOS=linux GOARCH=arm go build -o build/linux/arm/arp-speaker
go.universe.tf/metallb/vendor/github.com/mdlayher/raw
../vendor/github.com/mdlayher/raw/timeval.go:17:6: cannot use int64(timeout / time.Second) (type int64) as type int32 in field value
../vendor/github.com/mdlayher/raw/timeval.go:18:7: cannot use int64(timeout % time.Second / time.Microsecond) (type int64) as type int32 in field value
Makefile:22: recipe for target 'arp-speaker' failed
What you expected to happen:
clean compile
How to reproduce it (as minimally and precisely as possible):
See docker branch and execute 'make build'
Anything else we need to know?:

/cc @mdlayher

All other targets compile; this is probably the things where the int type is 32 bits on arm


Compose File docs do not provide Windows examples

File: compose/compose-file/index.md, CC @gbarr01
Many things like volumes have different syntax for volumes.  We should provide examples for Windows for compose.
/cc @friism @brandonroyal

Closing this ticket due to its age, and the impending refactor. If you think this is in error, feel free to reopen. Thanks!


Package Requested

[X] I would like someone else to build the manifest.
[ ] I would like help so I can submit the manifest.
[X] I have performed a search and couldn't find this package.
[ ] I have checked that the installer for this package is not a script file
[ ] I think there is a new version available and I have provided the URL.

Please provide the following information
Publisher: php
Publisher Url: https://www.php.net/
Package Name: php
Description: A popular general-purpose scripting language that is especially suited to web development.
Package Version: 8.2.3
Installer URL: https://windows.php.net/download#php-8.2
Current Package Identifier (for new versions): NA

duplicate of https://github.com/microsoft/winget-pkgs/issues/56226 . closing sorry.


crashing on shotgun fire + custom weapon request

Triton TR15
Crash.txt
crash is caused upon firing a shotgun at enemies.

The TR-15 is already supported.
I'll take a look at the shotgun in a bit. It shouldn't break like that.

Does the crash still happen without Pocohud installed? Poco is ancient by now, and it looks like some other mod is actually causing the crash.

Does the crash still happen without Pocohud installed? Poco is ancient by now, and it looks like some other mod is actually causing the crash.

yes, still occurs without pocohud.
was not aware about the TR15, it isn't in the supported custom weapons list on the mod workshop mod page.

Looks like this happens if you have another mod with burstfire installed, such as vanillahud plus. I'll take a look at it.

Fixed.


Exclude node_modules all the time

Currently, we set the default of BUILDKITE_TEST_ENGINE_TEST_EXCLUDE_PATTERN to be **/node_modules to exclude files within node_modules directory.  If customers configure the BUILDKITE_TEST_ENGINE_TEST_EXCLUDE_PATTERN to their needs, files inside the node_modules can accidentally get picked up by the client. We need to exclude files inside node_modules all the time.

I'm not sure I 100% agree with this change. For me, we should either use the default value if an override isn't provided, or do what the user says they want to do.
Did someone raise this as an issue?

This is to avoid accidentally running a test inside node_modules when customers configure the exclude patterns. Without this, the customer will have to write a complicated glob pattern to exclude node_modules plus other patterns. Customer might not aware that they have to also exclude node_modules explicitly if they want to configure the exclude patterns.
Do you think there will be a case where a customer wants to run a test inside node_modules, I doubt so?

This is to avoid accidentally running a test inside node_modules when customers configure the exclude patterns. Without this, the customer will have to write a complicated glob pattern to exclude node_modules plus other patterns. Customer might not aware that they have to also exclude node_modules explicitly if they want to configure the exclude patterns.
Do you think there will be a case where a customer wants to run a test inside node_modules, I doubt so?

I doubt there will be either, it's just the principle of 'We provide all of the behaviour through the default or you provide all of the behaviour by overriding that default' feels a bit nicer than 'We provide all of the behaviour through the default or you provide some of the behaviour with us adding to it if you override it'. It feels like this is a downside of using the environment variables as a configuration pattern. File-based formats like YAML or JSON or TOML would allow you to specify an array of regex values to exclude rather than having to craft a single regex to handle it all. We don't have that though, so it's a bit moot.
Happy for this to be non-blocking and just something to keep in mind.

Thanks for putting your thoughts, everyone. I'll go forward with these changes. We can update this if customers find this harder to use, or when we switch to using a configuration file that will allow us to have more flexibility in configuring the pattern.


Can't read more than 4095 bytes with Editor::readline().   input data silently truncated.

When I read in a large line, eg 4864 bytes the resulting string is silently truncated to 4095 chars, as evidenced by calling .len() on the resulting string.   In my case, this was causing subsequent deserialization to fail and it took a while to figure out it was a rustyline issue, not a serialization issue.
I see that LineBuffer can accept a larger buffer size, but i don't see any way to make that happen using Editor or Config.  I also don't see any way to turn on the internal "can_growth" option.
I think there are three related issues here:

It should be possible to specify the initial buffer size when using an Editor.
It should be possible to specify can_grow, true or false.
If the input (or output) exceeds the buffer size then an error should be returned.  silent truncation should not occur.

nevermind.  I figured out that this is actually caused by linux (tty) limitations.   just google readline linux 4096 and you will see.
I was able to work around it by removing the ICANON tty flag.  eg:
stty -icanon
It can also be done in code, eg using termion crate.   This looks something like:
fn unset_tty_icanon() -> Result<(RawFd, Termios)> {
    let tty_fd = std::io::stdin().as_raw_fd();
    let termios_old = Termios::from_fd(tty_fd).unwrap();
    let mut termios_new = termios_old.clone();
    termios_new.c_lflag &= !ICANON;
    tcsetattr(tty_fd, TCSADRAIN, &termios_new)?;
    Ok((tty_fd, termios_old))
}


Cannot parse double backslashes

Does not from a quick test log anything that has a double backslash.
const parse = njsp(json => console.log(json))

parse('[ "\\\\" ]')
parse('[ "\\" ]')
parse(JSON.stringify(["\\"]))

Not sure if i am meant to escape them first, but thought it could be useful to let it be known. I understand it has no test yet and is on initial commit.

Thanks!


MQTT Fan component does not have a control for setting fan speed

Version 0.30.1, Python 3.5.2, running on Windows
I'm trying to set up a MQTT Fan component.
This is my setup:
fan:
  platform: mqtt
  name: "Prezracevanje"
  command_topic: "Unity/Engine/Prezracevanje/Set/Dummy"
  speed_state_topic: "Unity/Engine/Prezracevanje"
  speed_command_topic: "Unity/Engine/Prezracevanje/Set"
  retain: false
  qos: 0
  payload_off: "0"
  payload_low_speed: "1"
  payload_medium_speed: "2"
  payload_high_speed: "3"

My ventilation system is always on (the reason for the "Dummy" command topic) and I want to control the speed using this component. Speeds are set with numbers from 0 to 3 sent to the speed command topic.
I get a component that doesn't have a control for setting speeds.

Am I doing something wrong or is the component not complete?

I see the same problem with the demo fan component.

I just setup a MQTT fan with the same results.  If this feature isn't complete, I would like to help.  Please let me know how I can make this better.

Does anyone know if this is something that will be added into the system? I am having the same issue, no way to control anything but on and off. I would love to be able to control the 3 speeds from the panel:)

Being somewhat frustrated by this issue, I found a workaround until it gets fixed:
Setup a MQTT sensor that reads the fan state (integer 0-3 in my case), then setup an input slider to set the commanded state (again integer 0-3), group them together in a panel and add an automation rule that sends a MQTT update when you move the slider like this:
input_slider:
  commanded_ventilation_state:
    name: "Nastavitev_prezracevanja"
    initial: 0
    min: 0
    max: 3
    step: 1

automation:
  - alias: "Vent"
    trigger:
      platform: state
      entity_id: input_slider.commanded_ventilation_state
    action:
      service: mqtt.publish
      data:
        topic: "Unity/Engine/Prezracevanje/Set"
        payload_template: "{{ states('input_slider.commanded_ventilation_state') | int }}"
        retain: false
        qos: 0

It's not fancy, but it works.

Thanks FrenkK! I don't need anything fancy, as long as it works:)
I'll give this a go a little later on tonight.


Cloud Launcher - Create Offer

in progress....

This is getting closer.  Open related issues are:
https://github.com/couchbase-partners/google-deployment-manager-couchbase/issues/21
https://github.com/couchbase-partners/google-deployment-manager-couchbase/issues/22
The display file is currently broken.  Need to wire it into couchbase.py (replacing couchbase.jinja) once that is resolved.

Currently tracking a number of issues for this. Emily and Frank are looking into it.
I edited the display file some more.  It’s in a state that’s close to the UI I’m aiming for, but it’s not rendering in the Partner Portal, which I assume means I broke it again.  Can you help out with the syntax here?
https://github.com/couchbase-partners/google-deployment-manager-couchbase/tree/master/cloudlauncher
If we can get that working, next steps I see are:
Connect couchbase.py file to replace couchbase.jinja
Resolve Service Account issue - https://github.com/couchbase-partners/google-deployment-manager-couchbase/issues/22
Resolve script import issue - https://github.com/couchbase-partners/google-deployment-manager-couchbase/issues/21

The service account issue is resolved.  We still have the script issue - #21 and the display file is currently broken.

The script issue was resolved by flattening.

Current issues are:

I hit a stumbling block with setting the disk size.  I don’t know why that isn’t working. I’d really like to show you the behavior I’m seeing and see if you have any ideas.  To work around that I left the disk size as an un-validated integer and moved on.  Here’s where I dropped the disk type and it started working again: https://github.com/couchbase-partners/google-deployment-manager-couchbase/commit/4d4cd9cb1cbbcee336da63ae975ee853ac56d86d

I’m not sure what to do about the plaintext couchbasePassword field.  One solution would be to autogenerate the password, but if so we’d want to follow that approach in the DM template outside of Cloud Launcher as well so we didn’t split the codebase.  Another approach would be a masked text field, but I think you mentioned that widget doesn’t exist.

The default deployment name is rather lengthy.  That causes us to hit the 57 character limit for resource.baseInstanceName.  I’m not really sure how to resolve that.

There’s a potential issue hiding in the defaultZone.  If that zone has different machine types than the regions deployed in, the deployment will fail. I’m not sure if there’s a solution here.

Frank to look into pw masking.  If not get password.py and integrate to output.

Not going to use the disk object, just using an int.
Frank to check on deployment length issue.

Ben to go over marketing copy and upload latest package.

I think our only gap is keys for hourly-pricing images.  Once the keys are in place I can create the images.  Both hourly-pricing and byol DM archives have been submitted.

In progress.  Email thread with the last few issues is ongoing.

Done.

https://console.cloud.google.com/launcher/partners/couchbase-public


Property color of Picker's Item fires onValueChange

I have gone through these following points

Check latest documentation: https://docs.nativebase.io/
Check for existing open/closed issues for a possible duplicate before creating a new issue: https://github.com/GeekyAnts/NativeBase/issues
Use the latest NativeBase release: https://github.com/GeekyAnts/NativeBase/releases
Check examples from NativeBase KitchenSink https://github.com/GeekyAnts/NativeBase-KitchenSink
For discussion purpose make use of NativeBase Slack: http://slack.nativebase.io/
For queries related to theme, check Theme Variables from Docs and live NativeBase Theme Editor http://nativebase.io/customizer/

Issue Description
node, npm, react-native, react and native-base version, expo version if used, xcode version
Node: v12.6.0
npm: v6.9.0
react-native: v0.59.10
native-base: ^2.12.1
Project created without Expo, and using Visual Studio Code as editor.
Expected behaviour
Basically, what happens:

I have a dark/white theme switch, which toggles brightness value
I have a Picker containing all the colors available as primary colors for my app (Generated using colors object)
Here is a colors object snippet:

red: {
    primary: '#EF5350',
    dark: '#FF867C',
    light: '#B61827'
},
pink: {
    primary: '#EC407A',
    dark: '#FF77A9',
    light: '#B4004E'
}

When I toggle the dark/white theme switch, it should update the color of each Picker Item, depending of the theme I actually chose (Lighter color on dark theme, darker color on white theme according to my previous colors object) WITHOUT calling onValueChange.

Actual behaviour
When I dynamically change the color property of Picker's Items, it fires onValueChange.
Steps to reproduce
<Picker
    mode="dropdown"
    iosIcon={<MaterialIcon name="arrow-down-drop-circle-outline" />}
    selectedValue={this.state.secondarySelected}
    onValueChange={this.onSecondaryChange.bind(this)}>
    { Object.keys(colors).map((val, i) => {
        return <Picker.Item
        label={val.charAt(0).toUpperCase() + val.slice(1)}
        value={i}
        key={i}
        color={colors[val][brightness]} /> // Here
      }) }
</Picker>

On brightness property update (light <=> dark), it refreshes the Picker's Items and fires onValueChange function.
How I fixed this in my case
I fixed this by setting a static color to my Picker's Item's (Not depending anymore of brightness variable):
<Picker
    mode="dropdown"
    iosIcon={<MaterialIcon name="arrow-down-drop-circle-outline" />}
    selectedValue={this.state.secondarySelected}
    onValueChange={this.onSecondaryChange.bind(this)}>
    { Object.keys(colors).map((val, i) => {
        return <Picker.Item
        label={val.charAt(0).toUpperCase() + val.slice(1)}
        value={i}
        key={i}
        color={colors[val].primary} /> // Here
      }) }
</Picker>

Is the bug present in both iOS and Android or in any one of them?
I could only test on Android, but I suppose iOS to have the same issue!
Any other additional info which would help us debug the issue quicker.
I think that the color property of Picker's Item causes value to change, but isn't really

Additional info
I think that just refreshing picker's content causes onValueChange to be triggered because without my brightness variable, I guess that Picker's content isn't changing.. I mean, he has no reason to change!

There is no color property of Picker.Item. If you wish to change the item color, you need to pass it in Picker, see docs: https://docs.nativebase.io/Components.html#picker-text-and-item-text-styles-headref

There is ! Picker.Item was changing text color when passing color property... but ok ..
I did it because I wanted each item to have a different text color and it was working really well.. Anyway

Anyway, looks like that's my bad, so thanks.


feat(filesystem): Customisable column width

I've added a width field to the configs so that the width of the columns displayed in the file explorer can be customised. Text that are too long are also truncated with … to prevent the columns from being offset.
Edit: vim.fn.printf is used instead of string.format to prevent an error when the width is more than 99.
Demo:

require("neo-tree").setup({
  default_component_configs = {
    last_modified = {
      width = 10,
    },
    created = {
      enabled = true,
      width = 30,
    },
  },
})

This is the fix mentioned in #1614.

otherwise LGTM, could you add it to the README as well?

I've added the options into the readme, thanks for the suggestion!

ty! pinging @cseickel.


Functions

Functions
This reliant on things described in #237, and being familiar with the python function semantics will help, although I given an overview.
ConcreteFunction
A ConcreteFunction, both here and in python, is a wrapper for a native function handle. This is a set of "compiled" code that can be ran, but the signature can't be changed. Performance optimizations depend on that signature being well-known, too, apparently, i.e. argument shapes should be specified, even if they aren't required on placeholders.
Python
Functions in python are done via tf.function. Since python is duck typed, the dtypes and shapes of inputs can change, so a function will create a new ConcreteFunction for each distinct realized input signature (this is called tracing). Type hints can be used to limit re-tracing.
Supported arguments and what they expose to the signature are:

Tensors -> Dtype and shape
List of tensors -> number of items
Map with tensor values -> keys
Python objects -> identity

Of note is that if python objects are used as arguments, a new ConcreteFunction will be made for each set of argument values, so this is discouraged.
Because of the way tracing works, python side effects are only executed on each trace, which is unreliable. They will always be executed on the first call, but the function may not be re-traced each call.
Python control flow is converted to TensorFlow control flow (this is impossible for us).
Variable creation and initialization is handled as described in #237, the only thing we need to know is that global variable creation is forbidden after the first trace.
Outputs can be a single tensor or a tuple of tensors.
Java
For our implementation, I'm envisioning something similar to ConcreteFunction's API, where you would have a method like:
fun defineFunc(tf: Ops, inputs: Inputs): Map<String, Operand<*>> {
    val x = inputs.input<TFloat32>("x")
    val y = tf.math.add(x, tf.constant(2f))
    return mapOf("y" to y)
}

Function.define(::defineFunc)

The actual syntax is mostly irreverent and will likely change, but a few things to note:

inputs are defined as the function is built. I don't like this very much (it allows for shenanigans using non-tensor inputs, e.g. adding n inputs where n is itself an input. This would throw a runtime error), but don't see a good way around it.
as such, we only need to return outputs

Note that we have no way of converting Java control flow to tensorflow's like is done in Python. This will be noted and highlighted in the docs. It's generally not an issue though, since we can't resolve tensors in functions, so any control flow will be dependent on Java args which will cause re-tracing on new values anyways (it's a bit sub-optimal, but works fine).
I also plan a Kotlin compiler plugin to do the transform if you annotate the function like Python does, but I'm not sure if officially supporting it is a good idea (the compiler API is unstable and undocumented, although it will be released eventually).
Inputs and Outputs
Using a Inputs builder instead of the existing signature builder is because it's necessary to allow for more complicated inputs (i.e. not just placeholders).
Like python, I would want to allow as inputs:

tensors (ofc) - input.input(Class<TType> dtype). Note that type can be family types like TFloating.
List of tensors - input.list, input.list(Class<TType> dtype) for a list of the same dtype
Map of tensor values - input.map, input.map(Class<TType> dtype)
Java objects - input.javaInput<T> (typing is done by casting, since the argument map is untyped anyways)

This would work very similarly to how Python handles it, creating a signature for each set of argument values (with the same criteria as Python's) and caching ConcreteFunctions based on that. The parameter list (i.e. names and types) would be static, and we would use it to get the argument signature without re-tracing the function. If a retrace resulted in a different parameter list an error would be thrown.
For outputs, I want to support single tensors, a list, and a String -> Operand map (shown above). The values of the list and map would be limited to tensors. The resulting Function objects will be type safe wrt their outputs (i.e. the call method returns List or Operand). I'll also add a type safe single input single output version.
Variables and Captures
As described in #237, global variables are created in an attached eager initScope, and limited to the first trace. This works since everything from the initScope are automatically captured when used. As described in #237, I would like a way to create variables once and remember them on further calls automatically, but this requires execution environment wide unique ids, which is prohibitive (or at least I can't think of a better way).
Operands from other environments that are accessible from the function definition can be captured by the closure. Only operands from the initScope will be captured automatically on use. Otherwise, you can use input.constCapture(x) to bring x into scope if it's from a compatible environment, or input.capture(() -> x) (the preferred way), which will reflect any updates to x.
Constant captures from eager sessions use tf.constant(x.asTensor), and lambda captures or captures from graphs work by adding an input, but providing the argument each time the function is called.
Operands from any eager environment can be captured, but if captures from a graph are used they all must come from the same graph, and the function can only be called from that graph, since the captured value needs to be accessible for calls. This is the case almost all the time anyways.
Saving and Loading
Currently not supported.  Described in #237 a bit, but essentially we would need to convert the initial values from an eager context to a graph, and the needed C apis aren't exposed yet (if it's even possible).  There's workarounds like just saving the current value we could look into if this is very necessary.

For the function definition syntax, I think that Kotlin is creating a method reference? Could you use Java in the examples please (unless referring to how this would be exposed in Kotlin). Is that method reference then immediately executed (i.e. traced) by Functions.define?
If it is indeed creating a method reference, then I think we should define a Java functional interface which we can type more strongly which is accepted by the function creation system. It's going to be hard to express to Java developers that this code is only executed once to build the graph, especially if it allows arbitrary Java inputs (which I actually would like to avoid if at all possible because the behaviour will be hard to explain), so relying upon lambdas which conform to some named type (e.g. FunctionBuilder) will help signal that this builds the function rather than executes it. We could even rely on an explicit builder pattern though the appropriate typing signal might be harder.
Why do we want to allow retracing when Java inputs change? It'll be a pain to track, especially if the Java input objects are mutable, and might well lead to very odd behaviour. Why not make the user define a new function with the updated inputs? I think the retracing is likely to be a source of bugs in Python anyway, it is in JAX, and I'm not sure we want to encourage mysterious behaviour.
What's the return type from Function.define, or does it mutate some internal state? We should probably name them too.

For the function definition syntax, I think that Kotlin is creating a method reference? Could you use Java in the examples please (unless referring to how this would be exposed in Kotlin). Is that method reference then immediately executed (i.e. traced) by Functions.define?

Yeah, and I converted it.  Tracing would be done at the first call, since it requires the arguments.

If it is indeed creating a method reference, then I think we should define a Java functional interface which we can type more strongly which is accepted by the function creation system.

A functional interface sounds good to me.  Something like:
@FunctionalInterface
public interface MapFunctionDefinition {
  public Map<String, Operand<?>> define(Ops tf, Inputs inputs);
}

@FunctionalInterface
public interface ListFunctionDefinition {
  public List<Operand<?>> define(Ops tf, Inputs inputs);
}

@FunctionalInterface
public interface FunctionDefinition<T extends TType> {
  public Operand<T> define(Ops tf, Inputs inputs);
}

with nice javadocs.

Why do we want to allow retracing when Java inputs change?

The reason behind Java inputs is mostly to allow control flow.  In python you can do something like:
def test(x, neg=True):
  if neg:
    return -x
  else:
    return x

To allow the same type of thing in Java, we need a way to pass Java objects into the function, since we can't get the values from tensors.  I don't love it either, especially since you lose the type information, but I don't see a good way around it either.  Python converts the if statement to a tf.cond op, which we can't do, so to get the new output we have to retrace it.
There's also a use case that I'm looking at for the Kotlin version which is serializing an input w/ operands to a template and operand list, then passing in the operands and template as inputs and deserializing it in the function, which would allow any serializable type to be used as input.  It's a bit specific, but more generally allowing Java inputs opens up a lot of possibilities for more complicated functions like this.
For mutability, I need to check what Python does, but what I think it does and what I would do here is re-trace every time if there's any Java inputs, which makes mutability not a concern and avoids having to cache the values.  We could then add an inputs.immutableJavaInput<T>() that would check equality.
I'm not sure what you mean by "Why not make the user define a new function with the updated inputs?".  That's essentially what's going on behind the scenes anyways.  And since there's no good way to declare inputs other than inputs you'd have to do something like:
class ParamFunc{
  public ParamFunc(boolean neg){
    this.neg = neg;
  }
  private final boolean neg;
  public final Function func(){
    return Function.define((tf, inputs) -> {
      final var x = inputs.get("x", TFloat32.class);
      if (neg){
        return tf.math.neg(x);
      } else {
        return x;
      }
    });
  }
}

// use
public static Operand<TFloat32> text(Ops tf, Operand<TFloat32> x, boolean neg){
  return ParamFunc(neg).func.call(tf, x);
}

which is a bit of a mess.  Plus, the bigger problem with re-defining a function like this is that they can't share variables, so if you declare a (global) variable inside the function it would be re-created each call (whereas if we do this via re-tracing they will be reused).
I could see some way to force re-tracing, as bug prevention.  Something like callWithRetrace.

What's the return type from Function.define, or does it mutate some internal state? We should probably name them too.

Function.define would return a Function, MapFunction, or ListFunction, depending on what the definition returns.  It's callable like ConcreteFunction.  There's no internal state.

An updates since I've been playing with generating function ops: there is a space for a function class that supports captures, variables, and the new init scope, but not retracing.  This is equivalent to python's DeFun, and the main use for it is that since it only ever has one ConcreteFunction, you can pass it to ops like If.  It also allows users to avoid re-tracing issues at the cost of some functionality (collection imports won't work, and Java ones only do if they are immutable, at which point they should be captures, so I'd forbid it).

Two more things I want to add to this, clarifying the above a bit:
Function types
I'd want three types of functions (names TBD):

The existing native ConcreteFunction.  Used to manage dependencies, direct link to native function, no inlining
DefinedFunction: a traced function with eager initSession, variables, captures, etc, but it's only ever traced once (and as such maps to a single ConcreteFunction).  Can't support java inputs/captures, collection inputs, or datatype polymorphism.  Good for controlling retracing and as inputs to ops.
Function: the python equivalent, supports everything mentioned.

Inlining is the ability to inline into an outer function graph (and maybe normal graph) and to execute in eager mode for debugging (w/ a global flag like Python), which requires keeping the definition lambda around.
Polymorphism on input definers
I'm thinking of doing something like:
// not sure the type inference will work properly like this, may have to add helper functions w/ concrete types
public static DefinedFunction define(FunctionDefiner<? super CapturesAndInputs > def)
public static Function define(FunctionDefiner<? super InputSpec> def)

// possibly more, with different output types.  Or add type param for output type
public interface FunctionDefiner<T extends InputSpec>{
   public Outputs define(Ops tf, T inputs);
}

abstract class InputSpec{
    protected final Ops tf;
}
class CapturesOnly extends InputSpec{
    public Operand<T> capture(Producer<Operand<T>> value)
    public Operand<T> captureConstant(Operand<T> value)
}
class CapturesAndInputs extends CapturesOnly {
    public Operand<T> input(String name, Class<T> type)
}
class CapturesInputsAndJavaValues extends CapturesOnly {
    public T javaInput(String name, Class<T> type)
    public T javaCapture(Producer<T> value)
}

The exact hierarchy is still up in the air, I'm considering adding one for captures, inputs, and collection inputs, or maybe only having InputSpec, Captures, CapturesAndInputs, and Everything.  The importance of those three is that InputSpec (i.e. nothing, Producer-like) is what is supported by all ops that take functions, Captures is what is supported by functions passed to ops like If that support passing inputs, CapturesAndInputs is what is supported by DefinedFunction, and everything is everything supported by Function.
That way we can have an If op method that looks like:
public Operand<T> ifOp(Operand<TBool> cond, FunctionDefiner<CapturesOnly> thenBranch, FunctionDefiner<CapturesOnly> elseBranch)

that uses DefinedFunction internally.  There's some magic that needs to happen to find the captures and pass them through properly, so the signature might change slightly, but it shouldn't change too much.  Most likely it will involve a new subclass of CapturesOnly w/ a shared capture pool.  But that's an implementation detail that won't be exposed.


Passing id of first association to second association

I am trying to create a record using the following Factory:
FactoryGirl.define do
  sequence :email do |n|
<EMAIL_ADDRESS>  end

  factory :user do
    ignore do
      account {}
      project {}
      role    {}
    end

    email
    password "password123"
    password_confirmation "password123"

    trait :owner do
      ignore { role 'Owner' }
    end

    trait :team_member do
      ignore { role 'TeamMember' }
    end

    trait :collaborator do
      ignore { role 'Collaborator' }
    end

    trait :client do
      ignore { role 'Client' }
    end

    after_create do |user, p|
      properties = { user: user, account: p.account,
        project: p.project, role: p.role }.delete_if{ |k,v| v.nil? }

      FactoryGirl.create(:membership, properties)
    end
  end

  factory :membership do
    account
    user
    role ''
    project
  end
end

This works great, except for the fact that Project has a belong_to relationship to Account. Right now, the created project is never tied to the account directly, only through the membership table, which is not the way I want it to work. The problem is that I don't know if it's possible/can't find a way to pass the id of the generated Account to the generated Project.
So for example, the :membership part would look something like this:
  factory :membership do
    account
    user
    role ''
    association :project, account_id: account.id
  end

Except, this causes a #<NoMethodError: undefined method id' for #FactoryGirl::Declaration::Implicit:0x007f8e3cdd3890>` error.

What about swapping out association :project, account_id: account.id with project { association :project, account_id: account.id } in the membership factory?

@joshuaclayton great tip, lazy attributes worked brilliantly here. I'm amazed at the flexibility of FactoryGirl.


Use buf remote plugins for generation

When the BSR supports it, our buf.gen.yaml should use remote plugins.

This actually isn't that desirable because the remote plugins are not reproducible as things change are made on buf's backend.


telegram

please can someone explain to me what is telegram and what is the purpose of it? not sure how to use it. thanks.

yes me too i don't understand the purpose of it and how telegram will help us to buy players ? if there's any one to explain to us, thank you

if configured you will get a notification to your telegram whenever bot buys / sells a player or if captcha gets triggered.
Can be useful if you are away from the bot , and if captcha gets triggered you will get a notification, so you can open web app and solve the captcha

Thank you for the explanation. Makes sense to me now

ok thank you for your help and thanks a lot for your job. I have another question, there's a lot of failure buy because other users won the card, does it have a relation with the speed of search or the speed of purchase ?

@princeroronoa , now a days many are using bot which is causing you to lose the card , just try to find a optimal time when there is less demand on market and try to run the bot during that time to increase the chance of winning the cards


Question on Custom Request Aggregation

Expected Behavior / New Feature
Referring to my config (see below). I have two aggregate routes - an "automatic" one, and one using a custom aggregator. The automatic/internal one calls both internal APIs and combines the two result sets into one as expected.
I wish to return a customised/filtered set of results given the individual results of each internal call, and expected that using a custom aggregator would allow me to do this. To use a lazy example, given the "tom and laura" example from the docs, I might wish to only return their ages i.e. anonymised data.
Actual Behavior / Motivation for New Feature
I have set up a custom aggregator class implementing IDefinedAggregator as described in the docs (see below). While I have implemented said interface, and it is called as expected, all it seems to receive is headers and routing info for each of the individual internal APIs called. At this stage I have no interest in adding/removing/transforming any of that. I guess retrieving the actual data is done in a further step(?), and it's this I'd like access to.
As an aside, most of my attempts to return from the Aggregator method silently fail and hang the client (the one time it doesn't if when one of the APIs requires authorisation and I try to access a header state that is not returned for this- this gives a 500 response). There is another issue #883 that reports this, but his solution is confusing as it no longer satisfies the interface definition.
Steps to Reproduce the Problem

config
{
"ReRoutes": [
{
"DownstreamPathTemplate": "/graph/{owt}/relations",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 50789
}
],
"UpstreamPathTemplate": "/graphymcgraphface/{owt}/relations",
"UpstreamHttpMethod": [ "GET" ],
"Key": "getgraphrelations"
},
{
"DownstreamPathTemplate": "/graph/{owt}",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 50789
}
],
"UpstreamPathTemplate": "/graphymcgraphface/{owt}",
"UpstreamHttpMethod": [ "GET" ],
"Key": "getgraph"
,
"AuthenticationOptions": {
"AuthenticationProviderKey": "TestKey",
"AllowedScopes": []
}
}
],
"Aggregates": [
{
"ReRouteKeys": [
"getgraph",
"getgraphrelations"
],
"UpstreamPathTemplate": "/graphymcgraphfaceaggro/{owt}"
},
{
"ReRouteKeys": [
"getgraph",
"getgraphrelations"
],
"Aggregator": "MeFirstAggregator",
"UpstreamPathTemplate": "/graphymcgraphfaceaggrocustom/{owt}"
}
]
}

services.AddOcelot(Configuration)
.AddSingletonDefinedAggregator();

public class MeFirstAggregator : IDefinedAggregator
{
public Task Aggregate(List responses)
{
???
}
}

Specifications

Version: 1.5.2
Platform: windows (both web api using ocelot and internal apis hosted locally in IIS. Client: Insomnia)
Subsystem: .net core 2.2

I am using something like this:
public async Task<DownstreamResponse> Aggregate(List<DownstreamContext> responses)
{
    var xResponseContent = await responses.FirstOrDefault(r => r.DownstreamReRoute.Key.Equals("<Y_REROUTE_KEY>")).DownstreamResponse.Content.ReadAsStringAsync();

    var yResponseContent = await responses.FirstOrDefault(r => r.DownstreamReRoute.Key.Equals("<Y_REROUTE_KEY>")).DownstreamResponse.Content.ReadAsStringAsync();

    var contentBuilder = new StringBuilder();
    contentBuilder.Append(xResponseContent);
    contentBuilder.Append(yResponseContent);

    var stringContent = new StringContent(contentBuilder.ToString())
    {
        Headers = { ContentType = new MediaTypeHeaderValue("application/json") }
    };

    return new DownstreamResponse(stringContent, HttpStatusCode.OK, new List<KeyValuePair<string, IEnumerable<string>>>(), "OK");
}

Make sure you check your status codes before accessing any the downstream content though!

Thank you very much, that's exactly what I was looking for!


update the extension for whatsapp web 2020

update the extension for whatsapp web 2020, macros are not working

Solved by #5


Generated defines for enum min/max are not always smallest and largest value

The generated defines for enum minimum and maximum value were actually the first and last value.
Related pull requests: #194, #404

Fix merged also to 0.3.9 maintenance branch, will be included in <IP_ADDRESS> eventually.

Fix released in <IP_ADDRESS>.


grsi-config needs updating

grsi-config needs updating with new libraries (and some obsolete ones to be removed). I can do this but exactly what we want to go into 'grsilibs', 'detlibs' (more obvious) and 'grsimore' isn't clear to me.

Thanks for noticing this. Is this hindering your work right now? Is it something we need a quick fix for, or is it something we can take some time to think about. I honestly don't know the whole reason behind this separation either.

I've changed my local version so it isn't urgent for me. It is basically only a problem (I think?) if you want to compile things independently of a grsisort make.

I've changed my local version so it isn't urgent for me. It is basically only a problem (I think?) if you want to compile things independently of a grsisort make.
It should also be noted that two flags are also required in the g++ compile line that weren't last time I tried this: -lMinuit and -lPyROOT

Ok. The new libraries can be fixed easily. I know it's not the best fix, but you can also compile within the scripts, util, or myAnalysis directories and all of the libraries should be linked properly regardless of how the config is setup.

Our co-op student Hiral also noticed problems with running existing scripts (LeanMatrices) on analysis files sorted with the new version, where the spectra showed little to no counts. I'll check again if this is still the case. So basically we have to use "g++ myscript.cxx -o myscript..." using the flags suggested by @jhenderson88 for all user scripts now? It would be nice to include these in the make.

@MikeBowry Jack's problem is a compile/no compile problem, not a does not run properly. The g++ command was always there but you have to properly include your own flags, which compiling within the GRSISort directory does for you. Was Hiral's issue in coincident matrices? Many people have had issues without altering things like timing gates.

@r3dunlop Ok. Hiral looked at the LeanMatrices problem again - she will open a new issue in a moment.

This should be fixed in PR #777

I'm assuming that this is solved?


Fix --preimage storage value

Related to: https://github.com/AcalaNetwork/chopsticks/issues/630 and https://github.com/paritytech/polkadot-sdk/issues/3522
I'm trying to simulate some bridge-initialization calls using chopsticks. I used the code found in dry-run-preimage.ts as an example for crafting my own dev_setStorage call for simulating an approved preimage. The initial version didn't work (it was failing with CallUnavailable) and it took quite a while to find the solution presented in #630. Not sure if this is the best fix, but I think it would bring value to have this fixed. At least it would have saved a lot of time for me.

dry-run-preimage works fine. what are you trying to fix?

Oh, I see. Sorry, I didn't realize. Ok. I'll close the PR then.


Cannot read properties of undefined (reading 'prototype')  on Object.create(http.ServerResponse.prototype)`

using "express": "^4.18.2", to run my website but it gives error as below
Uncaught TypeError: Cannot read properties of undefined (reading 'prototype')
    at Object.<anonymous> (response.js:43:45)
    at a (index.2a3db62f.js:1:455)
    at Object.<anonymous> (index.2a3db62f.js:1:768)
    at a (index.2a3db62f.js:1:455)
    at index.js:11:1

and it takes us to this line
var res = Object.create(http.ServerResponse.prototype)
check here: https://www.recursivezero.com/  and click on any page , it is not navigating because of this error.

Hello, and sorry for the trouble. Express is a Node.js module meant for the Node.js runtime pn your server; it does not run inside a web browser, which is the underlying cause of your issue.

didnt get you?

Express does not function inside a web browser, that is why you are getting that error. You need to run it on Node.js.


[Feature]: Ability to just have currencies always showing

Describe the feature
Would absolotuely love to just have currencies always showing without having to click.
Describe the implementation
A tick box for always showing would be great

I think the solution here is to just make currency show/hide persist, so that if you open it, and /reload, it stays that way.

Currency window does persist and up to 7 currencies can be tracked directly on the bag frame.


feat(commit): view commits

Question
Response

Version?
v1.6.0

Devices tested?
iPhone 6 Simulator

Bug fix?
no

New feature?
yes

Includes tests?
no

All Tests pass?
yes

Related ticket?
#5

Screenshots

Don't mind the merge button color. Because I can't find a mergable pull request again.

Before
After

And two added screens.

List
Detail

Description

Repicked @Antoine38660's work in #258. Migrated to the new i18n mechanism and did a little UI changes.

create new screens: commit and commit-list

make the committer name clickable

clickable branch name for push events in events screen
view commits from repository screen
show commits count and clickable in issue(pull request) screen

Coverage decreased (-0.7%) to 50.396% when pulling 7c1df1f15b138e6c67842caa4b421ebeb4d3ab2f on repick_258 into 54b5ff37cfe4a3338c932976347c17b7b74a55ec on master.

@gitpoint/maintainers To avoid blocking future changes, please forgive my dictatorship. I will merge this PR by myself without reviews.


improved annactl command line tool framework structure

fixes
This PR fixes #202.
checklist

[ ] Make sure you read and understood the CONTRIBUTING.md.
[ ] Make sure you applied sufficient labels, milestone and assignee.
[ ] Make sure all TODOs are addressed.
[ ] Make sure there is sufficient documentation.
[ ] Make sure there are sufficient tests.
[ ] Make sure all commits are squashed before merging.
[ ] Make sure to delete the feature branch after merging.

Current coverage is 96.43% (diff: 100%)

Merging #213 into master will not change coverage

Powered by Codecov. Last update 4c93412...d36cdb3

LGTM