Concepts and general discussion

( for those just tuning in, this thread is a continuation of a discussion started here  https://github.com/TheDuckCow/godot-road-generator/pull/177 )
Hey thanks for the detailed response.  So last night I started on a couple precursor classes I expect to use for some basic tests here, in C#.  Basically I expect almost everything road-like that might get generated will derive from some common class interface  I'm calling a 'i_DRAGGABLE' so far (names may change).  For now I'm putting anything I do within a PAVED namespace, and all of the classes involved start with "Paved".
So far I anticipate 5 main categories of 'draggable' subclasses:  The Manager, Roads,  Highways,  Parking Lots, and (eventually) Intersections  - So there's PavedRoadManager, PavedHighway, PavedRoad, PavedParkingLot, and eventually PavedIntersection.   And those all derive from i_DRAGGABLE.
Internally i_DRAGGABLE's track 3 main objects:  REFS (which contains references to generated mesh and child helper objects within the scene), OPTS (options for the draggable, established at initialization by passing in a hard-coded Struct which is then discarded and it's data stored in the OPTS class so it can be stored and passed around as a pointer), and RUNTIME, which is a Resource subclass that tracks user specified data that might change during the input / generation cycle - like a specific list of points a curvy path is generated from, or how many lanes wide a road is at a certain point along it's length, etc).
The OPTS and RUNTIME classes sound very similar but I picture OPTS as mostly static and unchanging per instance, but RUNTIME might change a lot, by the user or the generative process.  Also RUNTIME variables can be changed in the inspector with immediate feedback, but OPTS do not, they are created one time at startup and persist until the object is destroyed or reset.
Any names I've picked out are just temporary place holders.  Ultimately I'll change them around to better match the current format but for now I wanted to avoid naming conflicts, for clarity.
Each subclass of i_DRAGGABLE would itself have custom subclasses of REFS, OPTS, and RUNTIME.    So roads/highways might have certain data elements in RUNTIME that not all i_DRAGGABLES do, etc.  At a minimum, any i_DRAGGABLE at least tracks two data members, POINT_A and POINT_B.  for road segments that's the end points.  For lots/intersections (and the manager), it's the opposing corners of the defined square/rectangle.  The manager's rectangle basically defines the world bounding rectangle of the road system.
Internally I expect that intersections will ultimately be considered 'special parking lots', in that they share a lot of the same operating conditions (they're flat, basically square/rectangular, and roads can connect to any edge of that square up to two times per side).  That's my thinking going forward but details might shift around a bit.
I'm thinking of parking lots and intersections as 'terminators', and perhaps roads themselves could require at least two terminators to connect?  Seems reasonable to me, but the workflow might be a little different than current.  Basically I picture that before a person makes a road, first they'd make, say... two distant parking lots, then maybe they'd add an intersection or two in between at important points, and once those key locations are defined, roads can be created between terminator edges, so the user would click one edge of the first parking lot, drag a line over to the nearest edge of the first intersection, if any, and that would create a road segment.  Then repeat from another side of that intersection, towards either the next intersection or the end goal parking lot.
Then once a road is basically defined, it's manipulated on a segment level, so you select a segment and can either drag a mid-point handle around to specify the curve of the road, or click a 'subdivide' button which splits the segment into two segments which themselves behave the same way, until the road is appropriately twisty etc.
So I feel like this post went super long, I'll just chop it here.   That's basically what I have so far though.  Thoughts?

Thanks for sharing the commentary, happy to pepper in some of my own. I have no concerns over naming at all, we'll figure out what makes the most sense once we get to welding the parts together.

So far I anticipate 5 main categories of 'draggable' subclasses: The Manager, Roads, Highways, Parking Lots, and (eventually) Intersections

I'm curious what you have in mind, separating Roads & Highways out. Unless you are thinking of Highways a sort of composite of multiple roads? Or more in terms that you'd need to treat them differently being wider and slower bending?
For further context, while I had originally intended to include the intersection class here in the upcoming v0.5.0 release, the generalized functionality of RoadContainers basically made it unnecessary (for now).  Eventually, it might be that the intersection is more of a mesh generation helper rather than its own toplevel class (some thoughts over here).
At the moment, a RoadContainers is the building block I like to think the most about. A RoadContainer simply contains driveable roads; for now, just RoadPoints, but they could also be used as the parent container and controllers for parking lots. Basically, anything within governs its own methods of geometry generation, while the RoadContainer is meant to be the interface between one element and another. A container self calculates its own open edges (which other containers can connect to), and references to other containers when connected (to help traffic flow from one to the other). An intersection just happens to be a RoadContainer with more than two edge roadpoints. Any roadpoints that end internally (as multiple roads joining into a crossroads would) simply need to be marked with the "terminated=true" export var, so they are excluding from the external-facing edge list.

I'm thinking of parking lots and intersections as 'terminators', and perhaps roads themselves could require at least two terminators to connect?

Yup per above - would suggest thinking of it in terms of just working with RoadContainer, where all you care about are the edge interfaces (which will always be RoadPoints, since they define the "profile" of the egde). If anything, we could give additional meta dat properties about RoadContainers to indicate how they are intended to be used, or what mode governs the way the roadpoints within are used to generate the area. Or at the very least, a parking lot can can be a RoadContainer that has only one open edge (assuming one entrance), and then just ends up with other internally generated geometry and appropriate curves to represent.
Hope that helps - curious to see where this goes, and happy to help out if you get stuck anywhere!

Awesome thanks, yeah I think we're on the same page about most of that, it's real similar to what I have here in my early tests.
Regarding difference between highways and roads, with my sketched out layout:
Roads sit on the surface directly.  They also grade the ground below them, but they'll always be connected to the ground at all points.  Also roads can intersect other roads, and a general angle of 90 degrees +/- 30 degrees seems appropriate for those intersections.  However if a road connects to a highway, it's a different kind of intersection, the angle is basically the opposite, it would have to be more like 10->30 degrees or 150-170 degrees (like highway onramps, more gradual).  Since the angle is so severe, the road/lane width is no longer valid  as an intersection width , instead it would need the length of line segment that passes through a lane if that lane was turned to that severe angle (so significantly longer).  So highway on-ramps are like intersections  except they'll be much longer (as aligned with the highway it's a part of), and the actual on-ramps may have very long merging sections where they join the main highway mesh.
Highways would be a bit different geometry too, in that I picture them as being able to go over and under each other, and they might have support columns, larger curb sidewalls and/or even more spaced off distant walls that run alongside the highway,  So highways can sit on the ground and usually do but they don't have to and may stack up several layers thick to get past each other.
What I'm calling an i_DRAGGABLE so far (name will change) is basically comparable to RoadContainer I think, maybe.  Very similar.  The difference is primarily that i_DRAGGABLE is an interface, like a class decorator that I put on everything else in the road systems.  It establishes a standard format of runtime data, static options, dynamically populated mesh references, and provides a static observer that keeps track of them all and acts as a hub so they can interact.  Also by sharing a common interface, everything in the road system can basically be stored in the same array/collection, with no real concern for what specific kind of i_DRAGGABLE they are. For now, all direct interaction with the i_DRAGGABLE static observer happens through the PavedRoadManager, which has it's own collections of highways, roads, lots and whatever else.  probably an intersections collection but those may end up being children of roads, not sure yet.  This is just for organization and code clarity, by making the Manager the only class thats allowed to mess with the important static collections, i can better insure that when it's time to solve many roads all at once across multiple threads, that there is a central orchestrator / scheduler of the work queue that can keep it happening in the right order and delaying certains tasks until precursor tasks are ready and done.
I've setup parking lots with 2 ports on each side that you can interconnect very simple curved roads between.  It's ugly as sin but you can drag and drop all the points around in a reasonably intuitive way, for the roads it moves the roads around and for the parking lots the drag/drop is to move their sizing corners.  Moving a parking lot also re-solves all it's connected roads.

Highways would be a bit different geometry too, in that I picture them as being able to go over and under each other

Got it, yes that makes sense from a terrain perspective. Roads themselves would still be the same primitives but yes, would be allowed to be handled in any such way. I keep it more general in my mind, as you could always have a normal road briefly turn into an overpass (though in such examples, I think those are also ripe for dedicated RoadContainers to represent the "bridge" portion to have barriers or supports like you say).
Regarding the different intersection configurations, makes sense too. When we thought about it on our team previously, we previously broke it down into something like this. As we pictured it, 4 & 5 and higher level intersections could be grouped further together, 1 & 2 are like your highway onramp as mentioned (where the lane it splits from continues on), and then 3 is a general purpose splitter which in could be used for exit-only lane off ramps (if the split is allowed to be assymmetric) and other cases of roads coming together. Roundabotus would probably be another type unique to the others. The solid color areas are the parts where most of the special geo creation and texturing needs to be done (before thinking about other elements like cross walk decals)

Then, for higher level thinking, we had the idea that more complex intersections like clover exchanges are ultimately just breakdowns of the above ones (see for instance my post here). I think you're already on the same page here probably, just sharing the visualizations in case it triggers any ideas.
For elements of any given road: I've thought a fair bit about it, and am somewhat torn I'll admit on UX. Features like having support columns, barriers on the side, different profiles, sidewalks etc. All of those seem like they'd be ripe for an array of resource structure which belongs probably on the RoadContainer, to apply to all road segments within the container. That way you can configure on the fly or potentially (depending on how flexible the resource setup is) define your own. So the difference between highways and roads as you would define would be these resources definitions. I could imagine one resource that's even dedicated to telling the terrain system how much or little to deform. Ooo, a tunnel resource could be pretty awesome too, automatically building walls with some profile (perhaps thinking too far out, but fun to think about). So, sounds pretty similar to the classes you are talking about. We don't have anything in place in the road generator yet on this front.
The reason I've been torn on the approach: it also kind of locks you into a specific structure, instead of working within the primitive curves already existing. One key shortcoming I've read about what people find in other road generation systems is that it gets too inflexible or forces you to do things a specific way without giving an avenue to manually intervene if you need to do something manually/more custom (like import your own geometry for some intersection). In the end, something that works but then lets you manually take over geo inputs or import static meshes while retaining the AI lanes/virtual connections is the main thing.

I've setup parking lots with 2 ports on each side that you can interconnect very simple curved roads between.

Already making great progress! Having simple rectangular parking lots like that certainly could be a good starting place. Curious how you are thinking about decal/texturing, though maybe that's an entire follow on topic for later.

Hey thanks for the notes, that intersection break down is very interesting.  So at first when I setup a basic extruded path with CsgPolygon3D, it was functional but of course those are kind of limited.  I couldn't find much in the way of existing projects that allow you to specify multiple extrusion cross sections per path, so I made one yesterday and it seems to be working pretty well.  For now different cross section paths have to have the same number of total points.  Also I added a basic 'simplify output' option very similar to CsgPolygon's.  I'm going to try putting a short clip onto this post to see how well video works out with these Github forums, I crunched it down with Handbrake so it's pretty small, about 5mb.
If it's too big, or you'd prefer we don't utilize any video, let me know and I'll remove it and stick with still images.
https://github.com/user-attachments/assets/48e36a8a-cd43-4597-a830-30092d9ddbce
So each path cross section shape is it's own resource, and you can specify a different shape at any normalized point along the path.  It doesn't use those normalized points in the actual path solving though, that remains stepped through at a constant rate regardless of how many cross sections are defined.  Each shape segment of those cross sections can each have it's own material and smoothing group, and when it's forming the mesh it groups them under one MeshInstance3D with multiple materials.
My plan for decals is to basically have on asphalt shader that by default just shows basic road texture, but if the vertex color is set to some flag value, it can blend in an overlay layer for things like road surface irregularities or painted stripes.  Then the painted stripes would unpack a 32 bit integer out of one of the vertex color channels, and use a few bits of that information to determine a dashing pattern, and that dashing pattern will be applied along the length of the road.  So if we wanted, say, one solid yellow line next to a dashed yellow line, that would be, basically, three segments of a road cross section, one with special vertex color saying 'overlay road paint, solid / no dashing', then another next to it with no such vertex color so it's just normal road, then another next to that one that's same as first but with dashing pattern.  Then ultimately it's all the same material but vertex variations in the mesh will make it look like several.
That same system could also be used for things like 'fire lanes' where there's broad diagonal stripes, by having some of those color bits signify if the dashing pattern should shear/skew along the width of the road.  Then those paint pattern segments would be quite a bit wider than normal paint lines, but otherwise still just a special stripe running down the road (just wider), and the shader will make the diagonal dashing happen.
Let's see if this little video clip worked out...

dashing strategy test, seems to work pretty well.  nice sharp edges.

Wow some really awesome prototyping there! And video is really nice to have, since it's clear how to see the interactions. It doesn't count towards any quota on my side, so it's more about just uploading what fits.

So each path cross section shape is it's own resource, and you can specify a different shape at any normalized point along the path.

Longwinded tangential comment, bear with me :)
One of my nits with Godot in generate is working with curves and curve points is really cumbersome (so far as I created this addon as a part of a jam at one point as a result). That's why in the current Road Generator addon project the basic puzzle pieces are RoadPoints which are ultimately spatials which can be controlled with the native 3D gizmos (instead of trying to hack build our own), use the transform dialogue, etc. In your demo, i take it your control handles are virtual? Just some thoughts, depending on how grounds-up. Reason I bring it up is right now witht the road generator adodn, by design, the RoadPoint spatials are what define things like the cross sections. Of course for your quick prototyping do whatever you like and makes sense! When it comes to integration together, we can see how the philosophies can meld together.
As for extrusions/lane management: same experience here, we also started with csg geo for simplicity. But we had to sign up to making our own addon since it was a core requirement to make more interesting roads with variable lanes, adding and removing on a whim.  It's also one of the first widget interactions we made, old demo here. The way we crudely deal with this is by making each lane be its own set of loop cuts - lanes which are in an adding or removing mode are always on the outside, never on the inside (for simplicity), and for a given RoadSegment (between two RoadPoints), the number of lanes remains constant. The way we actually do the transition is just by pinching the outside lane inwards one or more lane widths.
In case you're curious, though it gets real into the weeds: There's quite a bit of (cumbersome!) logic to make sure the lane counts on one RoadPoint lines up with that on the other. Imagine road points with lane direction setups: RP1=[rev, rev, fwd] connecting to PR2=[rev, rev, fwd, fwd] means the actual loops we have are [rev, rev, fwd, adding]  on both sides, and the "adding" lane just means that the geo on that side is expanding out one lane's worth. If we have something like [rev, rev, fwd] -> [rev, fwd, fwd, fwd] which result in a lane sequence of [removing, rev, fwd, adding, addin]. Check out this gnarly unit test here :)
We also used this to make it easy to manage which textures to show on the lanes, as each lane has its own UV space. But as I said, I'm sure there are better ways we could manage that can result in a more flexible material and trimsheet. So very open to what you are coming up with. Since each lane gets shifted it doesn't work well unless the texture makes the UVs seamless left right lane-wise, I was presuming we'd use a detail/second UV layer for more general asphalt textures (or using the lane markings as more of a mask). So they're all pretty intertwined.

32 bit integer out of one of the vertex color channels

Love the idea of making the most of bitmaps. Only concern over using vertex coloring like that, is that we have to tie the geometry (loops and edges and so forth) to the intended features we want to visualize. I don't have a problem with that on a technical level, if you're confident you can make it work for the scenarios intended, I'm all for it, but it's the reason why we shied away from a more complex solution. Also I should probably know this, but would be curious to cross check if there's any compatibility limitations for different platforms to take in vertex coloring for materials (e.g. web or mobile exports). But the upsides do sound quite "up" for flexibility!
Anyhow, all just 2c comments above, really exciting to see what you're working through. I'll say this on a self humbling note, my team and I don't have that much experience with proc gen (hmm yet we decided to tackle this effort heh), and so we've had to simplify some problems to make them feasible. It's very invigorating to see your work so far, and I do truly hope we can find a way to bring it all together! And any existing design decisions are certainly open to be challenged or changed, with right ratioanle.

Thinking about your response a little more, it is definitely pretty cool to have variable profiles/widths/sidewalks without forcing the user to split the curve into mroe "roadpoints" spatials 🤔 I'd just need to ponder what that means from a usability space, since we also need to generate RoadLanes for AI traffic and also need to have the logic of what lane count end profiles there are for connection purposes (especially between separate, preloaded scenes that need to be snapped together based on a common "edge profile"). Anyhow, UX tradeoffs can come later I suppose

Cool thanks for checking it out.  Some notes I scribbled here just trying to think some things though, thought I'd see what you think.  Apologies for the MS Paint production quality on this, just rough sketch kinda thing:

Basically what I'm doing in this one is trying to come up with a strategy to connect the curb of Road 1 (at marked point P1) to the curb of Road 2 at point P2, so that the connection segment travels through Parking Lot corner C1.  Along this path, the cross sectional shape should start (in this example) as 'wide sidewalk' at P1, remain that same shape for some portion of the connector segment, and at some point shifts into 'thin curb, no sidewalk' cross section where it connects with Road 2 (p2).
Then the idea would be for every road that connects to a port, travel clockwise from that port connector edge to the next utilized port and it's closer curb, with transitioning between different cross sectional shapes between them.
In some cases, it might be good to have this process also strip C1 out of the curb segment path, so it just goes straight from P1 -> P2.  I picture this as particularly good for highway entrance/exit ramps, for more gradual intersections.
So this is my plan so far, haven't implemented it yet but the pieces are in place.  Order of point resolution is something like:
Parking Lot provides Port A/B/etc locations (via it's Edges and where along each each the ports are).   Road(s) connect to Ports and once connected, can provide Curb profile location (and facing vectors) ala P1, P2, etc.  Then the Parking lot provides some points in between P1 and P2 (C1, possibly a few others along the path).   And Road1 would, in this case, provide the starting cross section shape, and Road2 would provide the ending one.
Then repeat for both sides of all connected roads.  In some cases, like a parking lot with only one road connected to one port, it's expected that P1 and P2 would both be provided by the same road, and P1 would be one side of the road, P2 would be the other, and multiple Corner points would be provided to encircle the entire lot between them.
And then here you can see a multi-layered road pretzel that's testing out how well they stack and could concievably for traffic 'clover leaf' patterns etc.  Looks like it'll handle overpasses and elevated highway onramps etc pretty well

About the cross sectional shape data format so far:
Originally, it was just a list of Vector2's.  X and Y, etc.  Which is fine, but they needed a little more information, like what material ID that point should be, what it's UV.X should be at that point, and some other stuff.  So it gradually became Vector3's, then Vector4's, and now it's a Basis, basically a Vector9 (or Matrix3x3).  Internally, all of these shapes are stored as an array of Basis's, but since that's weird to work with and keeping track of which Basis index equates to which shape data component could get clunky and weird, I setup a 'data exchanger struct' which is what you actually get when you request a certain shape point.  So if you request Shape Point #3, it gets Basis index #3, provides that as a creation parameter to a new Shape Data Exchanger struct, which stores it as well as a reference to the Shape Point List resource the basis came from, and what index in the array that Basis was stored in, so the Data Exchanger can put it's data back into the source array if required (usually not though, usually it'll just read the data and provide it).  Then the Exchanger has numerous Getter's setup (with matching Setters that generally go unused, except within the editor), and those Getters are things like "POS", or "MATID", or various boolean flags which are stored as Uint32 bits in one of the Basis index entries.
So the POS getter, for example, would return a Vector2 that's composed of TheBasis[0][0] and TheBasis[0][1].  Then if you Set POS, it provides value.X back into TheBasis[0][0] and Y into [0][1].    Or for the MATID, it returns TheBasis[1][0] (I think? gotta check my notes), converted to an Int, and it's setter puts a provided int back into same location, converted to a float.   Then one Basis index is only for boolean flags, and you get 32 flags per point to use for stuff.  So far there's flags for 'BreakShape' (ie, don't output this segment, so a shape can be composed of multiple sub shapes), 'SmoothBefore' and 'SmoothAfter', for smoothing group management, and 'FlatEdge', which is a special flag that shoudl be applied to asphalt/road surface points so when those points are connecting to a parking lot (ie at start and end of path segment), it changes their local Y value from whatever it normally is to just Zero.  Then the parking lots sit at local Y zero and the asphalt will smoothly connect between.
More flags and properties will utilize remaining unused Basis members as needed.  Despite how weirdly indirect this sounds, it's pretty painless to work with, all of the weird data packing and unpacking is abstracted away from the coder.

How road segments are specified, so far:
Here's a code sample (c#)
`
override public void REGENERATE_MESH() {
GENERATED_ROAD.SHAPES.Clear();
            GENERATED_ROAD.SHAPES.Add(new _PATH_EXTRUSION_SHAPE_INSTANCE().SETUP(AtNorm: 0.0f, Shape: ROAD_SHAPES_V2.TEST1));
            GENERATED_ROAD.SHAPES.Add(new _PATH_EXTRUSION_SHAPE_INSTANCE().SETUP(AtNorm: 0.2f, Shape: ROAD_SHAPES_V2.TEST1));
            GENERATED_ROAD.SHAPES.Add(new _PATH_EXTRUSION_SHAPE_INSTANCE().SETUP(AtNorm: 0.3f, Shape: ROAD_SHAPES_V2.TEST2));
            GENERATED_ROAD.SHAPES.Add(new _PATH_EXTRUSION_SHAPE_INSTANCE().SETUP(AtNorm: 0.7f, Shape: ROAD_SHAPES_V2.TEST2));
            GENERATED_ROAD.SHAPES.Add(new _PATH_EXTRUSION_SHAPE_INSTANCE().SETUP(AtNorm: 0.8f, Shape: ROAD_SHAPES_V2.TEST1));
            GENERATED_ROAD.SHAPES.Add(new _PATH_EXTRUSION_SHAPE_INSTANCE().SETUP(AtNorm: 1.0f, Shape: ROAD_SHAPES_V2.TEST1));

            _SET_ROAD_PATH_CURVE_POINTS();
            GENERATED_ROAD.NotifyPropertyListChanged();  }

`
So for this simple test, you can see it's starting and ending with TEST1 shape (accessed as a static within helper class ROAD_SHAPES), and in from either end it remains TEST1 for 20% of the road length.  Then over 10% of the length it changes to TEST2, which it remains from 30% -> 70%.
I picture us as setting up a few different version of these short scripts for any given type of road, then user can select a drop down to select between them per road segment.  Of course the user could also just specify their own arrangement of these, but for the most part I expect we could identify 99% of the situations they'd want to setup and provide that as a preset.
Where it goes next is splitting each road shape instance (ie, the shape is X at norm length position Y) so it actually specifies 3 shapes, the road itself, the left curb, and the right curb.   Then each curb will adjust its position to line up with the road width at any given point, which will reflect how many lanes exist at that point.

https://github.com/user-attachments/assets/a16d72e2-da44-4a86-941c-6e21e708e218
yay video.  The road pretzel looks delicious.

Indeed looks very delicious! Love how responsive you have the controls there. Are the white spheres just virtual widgets, or actual spatial with controls on top?
Will respond more later, I've been getting some real world reference (read: traveling)

There is an older pull request https://github.com/godotengine/godot/pull/61424 that would solve a lot of the problems mentioned here. I think CSG might become more viable as we are now also able to bake CSG meshes https://github.com/godotengine/godot/commit/6455810db88a70e02f6633f3b46101b548d96b82.
There are another couple of open issues mentioned in the pull request asking for similar features. The demand is there so I am hopeful that it will get merged eventually.

Thanks for sharing that @mkay-dev, yeah I was also eyeing those branches. Though for the project goals of the Road Generator here, we'll still likely want to end up having control over the generation steps since we need to do rather bespoke lane UV texturing and also ensure AI 3D curves placed on top match the same interpolation of the sectionals themselves. But for sure will be a good thing that Godot users will be able to make at least a little more customized roads before havign to go full self procgen (or using a plugin like ours)
Hey @FishOfTheNorthStar how's it been going? Clearly I'm back from my trip now, wasn't actually that long 😅 Curious what you see as the next steps and how it would make sense to bring in your contributions. I know you're balancing bringing updates to the terrain plugin at the same time, so let me know what you think is feasible to do in the meantime

Hey welcome back.  I haven't been able to make much progress the last couple weeks because of life stuff.  I've started a new job and it's keeping me pretty busy, and I'll be moving soon so I've been out looking for housing.  So I may be ghost for a while, but when I can I'll be posting more updates on what I've been working on.
As far as integration goes, I think a big next step for me will be reviewing and unpacking your driving-AI code, to make sure anything I do can work with it in a comparable/compatible way.  I just need to find time to dig into that.

Good luck with the transitions, that's a lot all at once!
And no pressure at all, I just didn't want to be the one holding you up. If it ever helps to do a live chat to walk through it, I'd be happy to - though the AI pathing is relatively straightforward, you can probably learn most of what you need based on this demo scene (in particular, the car script). The main convenience is that the road generator is the one creating the paths and hooking them up so one follows to the next (along with pathing to left/right lanes for easy lane switching).

Great thanks that's very helpful.  I have some of my own pathing stuff I use too, for travelling between major locations (the parking lots, in our example here).  Maybe I can get the two somewhat interoperable.
(tl;dr everything below:  Just thinking out loud to get some notes down I'll use as a general plan going forward, since I can't spend a ton of time at one time on it for now, this will help me)
I think my mid-term project goals are, in order:
Understand and integrate your existing roadgen pathing solutions, so any further development I do doesn't need that retro-fit into place later.
Then create major/minor variant roads, like a highway, that connects to surface level streets, via entrance/exit ramps.  With the highway variant being more disconnected from the surrounding terrain, or modifying it significantly, and wider, with slower turns, and sidewalls.   Then the ramps are another variant like a single lane road but with highway-class turning radius (much slower than normal single width surface level road).  Then two to four lane street level roads with very tight turning radius allowed (from lower vehicle speeds), intersections, traffic signals, and occasional side barriers.  And short one lane roads for alleys, driveways, and dirt roads.  Then alleys can connect to street level, street level can connect to ramps (via lane side exit or at intersections), and ramps are the only thing that can connect to highways.  Highways will elevate themselves as necessary to travel over clusters of street level roads (cities), or individual street level roads will form short overpass segments that disconnect from the ground to pass over highways.
Then start on road damage/destruction support, so it takes the road and shatters it into a lot of little pieces and scatters them, but can take a normalized 0->1 value and gradually shift from no damage -> completely obliterated (but not necessarily in real time).  Ultimately this is what I need for my game, and I think it'll be a work in progress for a while, but I'll consider it usable at early functionality and just improve it over time, after we get other stuff more developed.
Once those three core priorities are well developed and stable, I'll post that work-in-progress c# version for some review, and we can start tightly integrating it's workflow, general look, code structure, icons, and class/variable names with the roadgen project proper.  So it should look the same and do all the same stuff, in roughly the same way, plus some new stuff.   And I'll go through the c# and dress it up a little to read as much as possible like the gd-script version of same.  Overall the code is very similar, between c# and gdscript.
Then we'll have to see the best way to get all the c-sharp stuff back into the current gd-script version.   If nothing else, we can just do a complete translation of the c-sharp version into gd-script and hey, there it is.  But I'd rather find a way that more better inherits all your existing code as much as possible, so it's less of a big change overall.  Thoughts on this part?  Maybe you'd prefer a total rewrite anyways, sometimes those are nice, kinda dusts off the code a little.
Topic for future consideration:  trains and/or conveyor belts.  hmm...

Sounds like a solid plan @FishOfTheNorthStar
As for a total rewrite, I won't say I'm totally opposed to it - but like anything, will just need to balance the outcome with the time taken (and impact to users who are continuing to use the project, though of course any major rework would constitute a new major version anyways). But I think all of that can be clearer and be conversations once we get closer to that stage, so nothing to fret too much over right now. Understood it might be quite some time before the integration happens, but I'll be more than happy to keep chatting here and sharing ideas as you get further along and think ahead.
For using the pathing solution, yeah if you just took the RoadLane class as a starting point you'd be in good shape. As I said, it's intentionally very simple - a good chunk is visualization of the lane's direction for use in debugging in-game or -editor, and then providing some methods to let vehicles "register" themselves to a given lane, which will make non-physics/raycast-based traffic feasible. I guess the *_prior_tag variables take a moment to understand but the comment there describes the intent.
Indeed, trains systems could be a good extension as well, presuming some explicit support for railroad crossings and so forth.
For the road obliteration, (just since it's interesting to think about), curious what approaches you are tinkering with. Say if you selecting one road segment to destroy, I suppose you need to interpolate between the destruction levels on both end - if both sides are 0% destroyed but the central one is 100%, you're doing some envelope weight for the destroyed amount. Maybe this is the factor influence is defines now much to transform the parts of (post voronoi cell split) chunks with some random amounts. Though if you're going to try and have 'realistic' fracturing, with rebarb poking out and chunks of concrete behaving differently from flat hunks of asphalt, could end up being that you need to generate several layers of meshes just defined by the profile of the base surface road mech.

Since the topic of this thread is "concepts and general discussion", felt worth pasting this talk down - I have only scrubbed through so far, I want to sit down and watch the whole the thing and then share back some personal takeaways. This is a behind the scenes of this unreal engine experience, made in part with proceduralism of houdini - but seems like there would be a lot of takeaways we could learn from. Topics from my own scanning through I found interesting I'll comment more on later:

Hierarchy of road layouts
Does talk about road intersections and their strategies
Their approach to a traffic system, including stoplights/intersections
Reusable road geo (some sections of surface streets) vs "megachunks" (organic highway shapes that are always unique)
Decals, and interestingly how they use die-cut-like geo for the decals themselves while using a shared common material
Touches on parking lots at a certain point
Touches on the material and what attributes are stored there, including use of 2x UV layers and vertex coloring

https://www.youtube.com/watch?v=p570CXrCmDQ

@TheDuckCow I think the bespoke texturing could be done with a parametric shader much more easily than the method currently being used. It would also allow you to separate textures like those of the lines and the road itself. Most of all though it might make more complex intersection line generation much easier. I did find some tutorials for generating road markings in unreal but sadly none that translate well. You might also want to look at things like "Intersection Marking Tool" for Cities Skylines as it deals with exactly these problems.
Might also  be worth mentioning that there are edge-cases that almost all road systems I've seen are unable to solve well and require unique solutions. Namely overpasses cause problems and most system are just not set up for them. You can check the Syklines mod "Vanilla Overpass Project" as an example.
I'm not sure about the AI lanes but I would ask @Stebulba if he is perhaps motivated to enable more direct access during mesh generation. He was kind enough to provide me an updated patch for godot 4.3.
There seem to be far too many godot projects trying to enable procedural geometry generation that I think it would be better to pool resources here. There is another project currently going called Hoodie (https://github.com/GreenCrowDev/hoodie) that is again trying to solve the same problem. Too many wheels and too many people trying to build them by themselves.
@FishOfTheNorthStar You would also benefit from official procedural geometry support in godot as making something like a shatter node might be relatively easy in something like hoodie.

Hey @mkay-dev thanks for chiming in, good to multiple people weighing in. My thoughts on your comments:

edge-cases that almost all road systems are unable to solve:

Big agree here. I'm not assuming we'll be able to solve all cases, which is why this repo is also designed to make it easy to export out a chunk of at least starter geometry to then edit further in other applications. We won't be able to solve all cases - but we can hopefully lower the barrier to entry with at least the common cases for simple cases, or "good enough" geometry to serve as a starting point for users fixing it up in 3D software (more below)

parametric shader:

I would agree, it would make it more flexible for an out of the box solution.
A core tenant of this current road gen project is to not lock users into the limits of what the project can or can't do out of the box, and a good example of that is for users needing to completely customize their materials (I've already had a few very stylized projects which have needed to do this). Now, not that a parametric shader wouldn't allow for that (arguably, could be even easier depending on the setup), but I would need to see how it could work in practice and how easy or not it'd be for someone to substitute in their own pbr/multi map materials etc, and how easily it translates to different road styles in different parts of the world. I wouldn't want to bake region-centric logic for how we can apply marking that don't translate to other places in the world or styles someone might want to accomplish.
A very nice pro of the current material system is that exporting geometry out to do touch-up work in a 3d software like Blender works perfectly, since we're using UV tiling that carries through gLTF. I already do that when I run into mesh or material limits, such as creating intersections right now before we have proper support. Now, should new upsides greatly outweigh this convenience, sure we could provide a different option. One day, we'll probably want options for baking for LOD levels anyways, so could also argue that just becomes part of some export routine too, negating this bullet point's con.
Trailing thought: I'm also not a shading wizard, so maybe I just need a skilled contributor to help show what's possible :)

Enable more direct access during mesh generation:

Not sure I follow this, you mean in the context of creating CSG geometry?
If built in CSG, or a geometry nodes-solution like Hoodie were in place, then sure - we could build on top of that to also generate additional nodes used for AI paths. Would only be relevant though if such generation methods were capable of generation additional objects, or being able to export out data via meta/private export vars so that a plugin could read the output to then do additional steps afterwards

far too many godot projects trying to enable procedural geometry generation:

I'm definitely with you in terms of it being better to join forces rather than reinvent the wheel. (contextually, a pun!)
That being said, there are always going to be differences from what generalized solution offers compared to fit-for-purpose solutions. Best case scenario, one uses the other as a building block.
I'd be happy to contribute any outcomes of road generation techniques and especially techniques for intersections, but it'll always have to be a layer on top since the very concepts of traffic, lane counts and transitions, and network management are more specific than a geo-based tool on its own would be able to offer. Again, using common building blocks would indeed be most ideal.
In the case of Hoodie: I saw this project and definitely find it interesting. I hope one day it, or some equivalent, becomes part of Godot core much like in Blender. Or if not core, maybe more of a common dependable library for others to build on top of for tailored experiences (e.g. for road generator users, they likely have no need to be exposed to the actual node graph, but if premade graphs were running in the background to handle geo, then the road generator could handle the UX workflow on top which would call such graphs in as needed contexts).
As it is, not sure exactly how we could integrate in the near term since our use cases and dependencies are different enough - it's also very tough to be in the position of a plugin depending on another plugin. But one can hope that as both build momentum and get enough adoption, it would be feasible defer some responsible of one onto the other.

Hey @TheDuckCow

Overpass edge case: That's is definitely the right approach. I mention the overpass problem specifically because it raises many interesting questions regarding how intersection logic is handled. Creating the additional geometry for such a case is likely trivial, however handling of the AI paths and markings might become very difficult. I'm not sure how to handle such a case myself but it's been on my mind for a few years. Something to better look into early than late. It basically serves as a great thought experiment for how to implement intersections.
Parametric Shader: Regarding different styles a shader would end up providing a lot of benefits. You could mix and match different styles per road through combining single textures/colors for lines, the road surface etc. You could also generate different line types(dashed, sawtooth...) very easily in one single line shader that gets mixed with the rest. If you've ever worked with blenders shading editor try playing around with godots visual shaders. Besides having a few quirks it functions very similar so doing some testing there is quick and easy. The biggest advantage however will be intersections. In fact I think you might not be able to avoid a shader there as the number of permutations will be very, very large. A shader would allow you to for example draw interpolated lines between all lane endings at an intersection dynamically by providing some parameters to the shader. As for exporting to glTF I'm not sure how you would handle that as exporting shader results is kind of a pain in godot at the moment. I'm going to do some basic testing myself to see what can be done with the plugin in it's current state. Luckily godot let's us just drop in a shader instead of a material for the roads so the only "oddity" to deal with in the shader is the custom UV. Can't promise too much though. I am no wizard myself.
CSG: Sorry for being unclear but you've got it. I'm hoping CSG can serve as the basis for general geometry generation so if we expose some of it's data many people would be able to build on it. Since CSG is already part of godot main "upgrading" it is the thread we should all be pulling on. Getting a dedicated proc gen geometry solution is probably a long way off (I think CSG might just evolve into it). The interpolation patch would already go a long way towards that. Asking @stebulba if he could also expose some vars in the patch before it gets reviewed would probably be a good idea. Ideally your plugin would then be able to avoid the programming/work cost of creating your own geometry and you could focus on everything else.


Apps on IPFS Call

We've recently added the Apps on IPFS call back onto the weekly sprint calls on Monday. Nominally, this is about all apps on IPFS - at the moment, however, it is mostly a call for @haadcode to talk about Orbit.
It would be great if we could make it more than that! So, I have some questions for you: are there other apps on IPFS that you think ought to have a call? Would any other apps on top of IPFS benefit from a weekly or occasional call to help development along?
In particular, I want to ping: @noffle @fazo96 @whyrusleeping @hydrusnetwork @travisperson @harlantwood @VictorBjelkholm @davidar @mafintosh @cloutier and @dokterbob.
For more, see: https://github.com/ipfs/pm/issues/253.

ipget is very close to a 1.0.0 release. I could talk a bit about that and see if it encourages contributions.

I've got a paid IPFS pinning service about ready to beta.

@noffle That sounds good to me. Want to add it to the agenda here? https://github.com/ipfs/pm/issues/258
@pjz Would you be interested in talking about it on the ops call, today?

Sure; the ops call is at noon EST, correct?

The All Hands call is at noon; would be great to have a demo in that call, as we normally open it up for demos after getting through the main agenda items. The Apps on IPFS call is a bit later - 1:30 EST - where it would be awesome for you to ask questions, talk about dev issues, or otherwise contribute. :)

I'll try and make one or both, aiming for at least the Apps on IPFS call.

@RichardLitt Oops, I wasn't fast enough to see your comment. I'll add myself for next week.

No worries! Catch you then.

We've been doing the apps calls regularly for a couple of weeks now


Missing Appendix in CodeReview Paper

The paper in CodeReviewer mentions a dataset cleaning process described in an Appendix in Section 3.3:"we clean the pre-training and downstream datasets carefully following the steps described in Appendix (attached as supplementary material).".
However, I couldn't locate this appendix in both the ACM library's published version and the arXiv pre-print.
Could you please clarify the availability or location of the referenced Appendix in the CodeReviewer paper? Access to this material would greatly aid in understanding the dataset cleaning steps crucial to comprehending the CodeReviewer workflow.
Thank you for your assistance.

Get!
Thank you!


Error handling

Error handling for inputs in add book.
Ex. 19 for month, 2029 for year, empty fields etc.

Empty fields fixed in b6038edff4cb0225cca88d782bd396c08aecf85b

Error handl. for already existsing books should be impl.

handl. for month < 0 and month > 12, as well as year < 1900 and year > year now (datetime). Extra for year < yearnow but month > monthnow


Implement additional inventory mocks

We're currently only supporting three inventory types, let's implement the rest!
A PR should add mock implementaties for any of these inventory types (the ones with a check mark have already been implemented):

[x] Anvil
[x] Barrel
[x] Beacon
[x] Blast Furnace
[x] Brewing
[x] Cartography
[X] Chest
[x] Crafting
[x] Creative
[x] Dispenser
[x] Dropper
[x] Enchanting
[x] Ender Chest
[x] Furnace
[x] Grindstone
[x] Hopper
[x] Lectern
[x] Loom
[x] Merchant
[X] Player
[x] Shulker Box
[x] Smithing
[x] Smoker
[x] Stonecutter
[x] Workbench

Note that some of these are not creatable (check org.bukkit.event.inventory.InventoryType), so ServerMock#createInventory should throw an error. Many of the ones that are creatable can most likely be easily implemented using the SimpleInventoryMock class.

:eyes: I will probably "claim" this issue since I have actually already implemented that a week ago for an upcoming PR
https://github.com/TheBusyBiscuit/MockBukkit/blob/blockstates/signs/src/main/java/be/seeseemelk/mockbukkit/inventory/DropperInventoryMock.java

I increased the scope of it a wee bit because I thought it would maybe be insane to have 23 separate tickets just for inventories.

Ah okay, that's perfect!

@seeseemelk The checklist needs to be updated.

Which once have been implemented?

Ah, it seems to be Barrel, Dispenser, Dropper, and Shulker Box

This is officially done!


Remove bad practices from the PowerShell sample commands

The "Create a CmdExec job step" contains two problematic PowerShell examples:

PowerShell.exe -Command "& { Get-Date }"

There's no reason to use "& { ... }" in order to invoke code passed to PowerShell's CLI via the -Command (-c) parameter - just use "..." directly. Older versions of the CLI documentation erroneously suggested that & { ... } is required, but this has since been corrected.
Therefore:
PowerShell.exe -Command "Get-Date"

PowerShell.exe -Command "& {&SQLCmd.exe -S $(ESCAPE_NONE(SRVR)) -Q 'select @@version'}"

Aside from the unnecessary & { ... } enclosure (and the fact that you don't need PowerShell to simply invoke an executable):

Use of & isn't strictly necessary here (the executable name is a literal name/path that is neither quoted nor contains variable references)

If you do want to use it (which may make sense, given that it is safe to always use it), it's best to put a space between the & and the executable name (& SQLCmd.exe ...); while not using a space technically works, using one helps readability in general, and, more importantly, is better for symmetry with the related dot-sourcing operator, . , which requires a space.

Therefore:

Either:

PowerShell.exe -Command  "SQLCmd.exe -S $(ESCAPE_NONE(SRVR)) -Q 'select @@version'"

Or:

PowerShell.exe -Command  "& SQLCmd.exe -S $(ESCAPE_NONE(SRVR)) -Q 'select @@version'"

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

ID: db6f2a8a-7b0a-b5b6-7095-b7569d2c23bb
Version Independent ID: 26d6594a-6d7d-7091-0f4b-382bb4a38ebe
Content: Run Windows PowerShell Steps in SQL Server Agent - SQL Server
Content Source: docs/powershell/run-windows-powershell-steps-in-sql-server-agent.md
Service: sql
Sub-service: sql-server-powershell
GitHub Login: @markingmyname
Microsoft Alias: maghan

@mklement0 -- Michael, thank you for your clear feedback.  I am updating this article.

@markingmyname -- Mark, please review this change in private PR 29297.


Update landscape.yml

Pre-submission checklist:
Please check each of these after submitting your pull request:

[ ] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[ ] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[ ] Have you picked the single best (existing) category for your project?
[ ] Does it follow the other guidelines from the new entries section?
[ ] Have you included a URL for your SVG or added it to hosted_logos and referenced it there?
[ ] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[ ] Does your project/product name match the text on the logo?
[ ] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~15 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

Build failed because of:
bad indentation of a sequence entry at line 313, column 13:
                - item:
                ^

Deploy preview for landscape failed.
Built with commit 7af097b33656d6f30474bbf0c1eb80ef70eca573
https://app.netlify.com/sites/landscape/deploys/5ee63885cc5026000858e66b

I entered another one which should fix the issues


When I use git push to commit changes，something was wrong

When I use git push to commit changes, i meet the error

The configuration information is as above

It appears that there may have been an issue with the OpenAI request. To ensure everything is set up correctly, please double-check your OpenAI configuration. Occasionally, such issues can also be caused by network connectivity problems.
For a quick verification, you can run the following test case, which should confirm whether your configuration is working as expected:
com.googlesource.gerrit.plugins.chatgpt.integration.CodeReviewPluginIT.sayHelloToGPT

It appears that there may have been an issue with the OpenAI request. To ensure everything is set up correctly, please double-check your OpenAI configuration. Occasionally, such issues can also be caused by network connectivity problems.
For a quick verification, you can run the following test case, which should confirm whether your configuration is working as expected:
com.googlesource.gerrit.plugins.chatgpt.integration.CodeReviewPluginIT.sayHelloToGPT

Thank you for your answer.But I can't execute "sayHelloToGPT" correctly.
Here's a screenshot of the relevant code:
sayHelloToGPT:

Configuration.java:

Console Output:

Does GptToken mean OPENAI_API_KEY?
I'm not sure what the problem is, I haven't changed the code elsewhere, and would appreciate your advice!

The HTTP 403 error indicates that you lack the necessary permissions. Please ensure that your account is properly configured on Gerrit to grant you comment posting permissions, and then try again.

The HTTP 403 error indicates that you lack the necessary permissions. Please ensure that your account is properly configured on Gerrit to grant you comment posting permissions, and then try again.

I'm sure my account has permission to comment. Because I configured an administrator account.
I'm wondering if there might be a configuration issue with apache that is preventing access to the gerrit.

Yes, it's possible. You could try bypassing Apache and access Gerrit directly to see if the issue persists.

Yes, it's possible. You could try bypassing Apache and access Gerrit directly to see if the issue persists.

I found the cause of the problem, I have to add '/a/' to the url for posting comments and in the config file the password is not the login password but the http token.

Since the issue is resolved, I am closing this ticket. If you encounter any further issues or have additional suggestions, please feel free to open a new issue. Your feedback is highly appreciated.


TAS: Use redundand specs flag for kubeflow integrations.

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Use redundand specs flag for kubeflow integrations.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

NONE

/cc @mimowo


sui-source-validation-service failed to run

Code branch: mainnet
Run command:  cargo run --release --bin sui-source-validation-service crates/sui-source-validation-service/config.toml
rustup show
Default host: x86_64-apple-darwin

Error msg:
error[E0432]: unresolved import `sui_move::build`
  --> crates/sui-source-validation-service/src/lib.rs:32:15
   |
32 | use sui_move::build::resolve_lock_file_path;
   |               ^^^^^ could not find `build` in `sui_move`

error: future cannot be sent between threads safely
   --> crates/sui-source-validation-service/src/lib.rs:328:38
    |
328 |                         tokio::spawn(async move { verify_package(&network, package_path).await });
    |                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ future created by async block is not `Send`
    |
note: opaque type is declared here
   --> crates/sui-source-validation-service/src/lib.rs:138:6
    |
138 | ) -> anyhow::Result<(Network, SourceLookup)> {
    |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: this item depends on auto traits of the hidden type, but may also be registering the hidden type. This is not supported right now. You can try moving the opaque type and the item that actually registers a hidden type into a new submodule
   --> crates/sui-source-validation-service/src/lib.rs:316:14
    |
316 | pub async fn verify_packages(config: &Config, dir: &Path) -> anyhow::Result<NetworkLookup> {
    |              ^^^^^^^^^^^^^^^
note: future is not `Send` as it awaits another future which is not `Send`
   --> crates/sui-source-validation-service/src/lib.rs:328:51
    |
328 |                         tokio::spawn(async move { verify_package(&network, package_path).await });
    |                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ await occurs here on type `impl std::future::Future<Output = std::result::Result<(Network, BTreeMap<(AccountAddress, Symbol), SourceInfo>), anyhow::Error>>`, which is not `Send`
note: required by a bound in `tokio::spawn`
   --> /Users/tiutiutiu/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/tokio-1.28.1/src/task/spawn.rs:163:21
    |
161 |     pub fn spawn<T>(future: T) -> JoinHandle<T::Output>
    |            ----- required by a bound in this function
162 |     where
163 |         T: Future + Send + 'static,
    |                     ^^^^ required by this bound in `spawn`

error: future cannot be sent between threads safely
   --> crates/sui-source-validation-service/src/lib.rs:337:38
    |
337 |                         tokio::spawn(async move { verify_package(&network, package_path).await });
    |                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ future created by async block is not `Send`
    |
note: opaque type is declared here
   --> crates/sui-source-validation-service/src/lib.rs:138:6
    |
138 | ) -> anyhow::Result<(Network, SourceLookup)> {
    |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: this item depends on auto traits of the hidden type, but may also be registering the hidden type. This is not supported right now. You can try moving the opaque type and the item that actually registers a hidden type into a new submodule
   --> crates/sui-source-validation-service/src/lib.rs:316:14
    |
316 | pub async fn verify_packages(config: &Config, dir: &Path) -> anyhow::Result<NetworkLookup> {
    |              ^^^^^^^^^^^^^^^
note: future is not `Send` as it awaits another future which is not `Send`
   --> crates/sui-source-validation-service/src/lib.rs:337:51
    |
337 |                         tokio::spawn(async move { verify_package(&network, package_path).await });
    |                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ await occurs here on type `impl std::future::Future<Output = std::result::Result<(Network, BTreeMap<(AccountAddress, Symbol), SourceInfo>), anyhow::Error>>`, which is not `Send`
note: required by a bound in `tokio::spawn`
   --> /Users/tiutiutiu/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/tokio-1.28.1/src/task/spawn.rs:163:21
    |
161 |     pub fn spawn<T>(future: T) -> JoinHandle<T::Output>
    |            ----- required by a bound in this function
162 |     where
163 |         T: Future + Send + 'static,
    |                     ^^^^ required by this bound in `spawn`

For more information about this error, try `rustc --explain E0432`.
error: could not compile `sui-source-validation-service` (lib) due to 3 previous errors

Thanks for reporting this. I am unable to reproduce, unfortunately.
Here's my setup:
git commit: 49cd553543263eb7e2356614a5a6f1a47a73e37b
🚀 sui % rustup show
Default host: aarch64-apple-darwin
stable-aarch64-apple-darwin
rustc 1.73.0 (cc66ad468 2023-10-03)

Sorry to hear that @qpb8023 Unfortunately, I don't have an x86 apple machine I could try this on, so not sure what to suggest for now.
However, when I run the command I was in the root folder of the Sui repository, and not in the sui/crates/sui-source-validation-service. So try to run it in the root folder of Sui.


Question: anonymous id update on identify call

Hi, I just want to verify if it is an expected behaviour that an anonymous ID is being updated after calling identify.
In the docs, anonymousId is saved in the user’s cookie, as well as localStorage, and will stick with that user until the cache is cleared or a reset call is triggered.
Thank you.

Hi @ZPGC, sorry to answer late,
This is an expected behaviour HERE is the link with the documentation.


Add debug information to MA skill update request

When a main application is submitted, it forcibly request member audit to update a character's skills. Given the issues with celery spawning those tasks, we'd like a record of it in the debug log.

Apparently this was already done.
https://github.com/EVE-University/whctools/blob/main/whctools/utils.py#L259


Missing required include in C++;

I found I have to include <functional> before including generated headers.
No big deal, but should be in the generated code, itself.

Actually, the latest does exactly this.
Here is the entire block at the top of each generated file.
#if __cplusplus >= 201103L
#  include <cstdint>
#  include <functional>
#  include <string>
#  include <cstring>
#endif


tqdm behaviour

VSCode Version:
OS Version: Windows10 Home single language

Steps to Reproduce:

using tqdm in notebook generates the message about hbox and its properties
Progress bar should have been there

Sample code to reproduce that behaviour:
from tqdm.notebook import notebook as td
for i in td(range(0, 10000)):
    c=1
Please note: I have already updated ipywidgets

Does this issue occur when all extensions are disabled?: Yes/No
Yes

please file issue agains the Jupyter extension https://github.com/microsoft/vscode-jupyter


Format big count number of library to human readable

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1177

Relevant Lines:
1177

💛  - Coveralls


docs-bug(cdk-tree): stackblitz examples are broken

Documentation Feedback
All examples that are importing:
import {NestedFoodNode, NESTED_DATA} from '../tree-data';
are missing that tree-data.ts file
Affected documentation page
https://material.angular.io/cdk/tree/overview

Is anybody working on this issue? I can try to fix it if you don't mind.


how do you control a item? a sorter or unloader?

If it's not in the README or documented in the .pyi file it may not be possible. I haven't touched this project in a while so I don't remember, but I would prefer if the issues section remained for issues.


Bold font does not display

https://www.loom.com/share/1fc1157797c64942935ec08cfff7d973

Fixed with latest version


Add api switch

Having a switch to go between etherhub, epool, and gastracker or any other known public api would be nice.

great idea. are epool and gastracker open to that? the etherhub node is running on a low-budget server and requests can be slow.

gastracker doesn't support whole set of api, for example filters aren't supported atm. but other things should work

awesome. etherwallet only uses getBalance, sendTx, and contract interactions.

that should work. You try https://api.gastracker.io/web3


specify format for --dump-resources

Would it be possible for the CLI to support specifying the output-format to get a format like json, xml, toml etc. ? One parsable format would be enough to support a rich ecosystem of tools for further processing.

Well my bad, it is already supported via the --reflect flag


Fix metadata.md generation

fix #12422
It turns out that Resources in macOS and catalyst are generated by xcodebuild in Privacy Manifest bundles. When xcodebuild creates a fat framework including Catalyst, the Resource structure is maintained.
This PR fixes the directory enumeration so that Privacy manifest bundles are always treated as atomic entities. Reference https://developer.apple.com/documentation/foundation/filemanager/2765464-enumerator
#no-changelog

Fix #12422

#> It turns out that Resources in macOS and Catalyst are generated by xcodebuild in Privacy Manifest bundles. When xcodebuild creates a fat framework including Catalyst, the Resource structure is maintained.

This PR fixes the directory enumeration so that Privacy manifest bundles are always treated as atomic entities. Reference https://developer.apple.com/documentation/foundation/filemanager/2765464-enumerator
#no-changelog

0Ç	*ÜHÜ˜
†Ç
0Ç1
0	`ÜHe0Ç8	*ÜHÜ˜
†Ç)Ç%

ConsentText

default
iOS & iPadOS Beta are pre-release software.  Your use is subject to and licensed only under the terms and conditions of the iOS and iPadOS Beta Software License Agreement ("BSLA"), including any applicable consent to collect diagnostic data set forth therein.  If you have not agreed to the BSLA, you are not permitted to use this software.  By installing iOS or iPadOS Beta and submitting feedback through Feedback Assistant, you consent to Apple's use of your information by its privacy policy (http://www.apple.com/legal/privacy).  Installing this iOS/iPadOS Beta Software Profile will allow you to install the iOS/iPadOS Beta on your device. It may provide you with access to Apple tools so that you may help Apple troubleshoot issues with your device and help Apple improve iOS and iPadOS and related products and services.  This version of iOS & iPadOS is only for use by members of the Apple Developer Program, Apple Beta Software Program, or Apple Customer Seed Program.  Attempting to install this version of iOS/iPadOS unauthorizedly could put your device in an unusable state, which could necessitate an out-of-warranty repair.  Please be sure to back up your devices using the latest version of iTunes and archive that backup before installing the iOS/iPadOS Beta release.  Devices updated to iOS/iPadOS Beta cannot be restored to the current publicly available version of iOS/iPadOS without restoring the device to its factory settings and data created after the installation of the Beta software may be lost or unrecoverable on an earlier version of iOS or iPadOS.  Please refer to the Apple Developer Program, Apple Beta Software Program, or Apple Customer Seed Program websites for more information about restoring your device, or visit: https://support.apple.com/en-us/HT203282.
Apple Confidential Profile. Do not distribute. Not to be used or disclosed without permission from Apple. Copyright ¬© 2023, Apple Inc. All rights reserved.

PayloadContent

PayloadContent

DefaultsData

SeedGroup
PublicBeta

DefaultsDomainName
.GlobalPreferences

DefaultsData

SeedProgram
PublicSeed

DefaultsDomainName
com.apple.seeding

DefaultsData

SBIconVisibility

DefaultsDomainName
com.apple. Appleseed.FeedbackAssistant

DefaultsData

MobileAssetAssetAudience
48407998-4446-46b0-9f57-f76b935dc223
MobileAssetSUAllowOSVersionChange

MobileAssetSUAllowSameVersionFullReplacement

MobileAssetServerURL-com.apple.MobileAsset.MobileSoftwareUpdate.UpdateBrain
https://mesu.apple.com/assets/iOS17PublicSeed
MobileAssetServerURL-com.apple.MobileAsset.SoftwareUpdate
https://mesu.apple.com/assets/iOS17PublicSeed
MobileAssetServerURL-com.apple.MobileAsset.SoftwareUpdateDocumentation
https://mesu.apple.com/assets/iOS17PublicSeed

DefaultsDomainName
com.apple.MobileAsset

PayloadIdentifier
com.apple.applebetasoftware
PayloadType
com.apple.defaults.managed
PayloadUUID
617630D8-C055-40A1-A4E8-AC30FD8A5ACE
PayloadVersion
1

PayloadDescription
Configures your iOS/iPadOS device for use with the Apple Beta Software Program.
PayloadDisplayName
iOS 17 & iPad 17 Beta Software Profile Beta Software Profile
PayloadIdentifier
com.apple.applebetasoftware
PayloadOrganization
Apple Inc.
PayloadRebootSuggested

PayloadType
Configuration
PayloadUUID
0C90EE68-9104-4D65-80A5-538784AAE2BE
PayloadVersion
1
RemovalDate
2025-01-31T00:00:00Z
TargetDeviceType
1

†Ç	s0Ç0Ç�†π˚eëJòi0
	*ÜHÜ˜
�0b10	UUS10U

Apple Inc.1&0$UApple Certification Authority10U
Apple Root CA0
130524174337Z
280524174337Z0Åå1@0>U7Apple Application Integration 2 Certification Authority1&0$UApple Certification Authority10U

Apple Inc.10	UUS0Ç"0
	ÜHÜ˜
�Ç�0Ç
Ç�∏H°glVùÂp≈FÙØÖ„Ω:ﬁ°ÁŸ®6<b•|†G≥kÅ¨˛ÿtÊ5∞XOtÿ£˛Ì-Ó§s%Y‘ñ‹&œù'ãTú‹í±‡3bô»πØ6§jÅëßm››-ÃÅ}Ã)â£…ô™¢ÏŸgi<øD($±ƒ,5÷±�%ÔPß€%∆√Oo[áæÒìß‘l^≤9.©·m; Æ9q?ÛπÙWù#�OôÉ^üXæµ—Ï◊≤~¬e‚ÒÏ<¶¸n€V≥Ó
≤K…¢Ò1ˆÆﬁ5l√Ä^Pcê∂∫m\¿„ü&ÉJﬁõ©∞Zo˚õkÅÏ›ﬂ2ﬁ¸.B¢ xZ◊�£Å¶0Å£0U˜æ|!`ë€={ÿ:2Åiﬂûlõ0Uˇ0ˇ0U#0Ä+–iGîv<EMAIL_ADDRESS>'0%0#†!†Ühttp://crl.apple.com/root.crl0Uˇ0
*ÜHÜ˜cd�0
	ÜHÜ˜
�Ç�ïÕç˝§]ıÒ¿áIá›≥3ì≠Ñ–!ì„Ÿ÷⁄Ø	"Ç`
<YBÒ-ì∂?ˇÙÙÓjx¡.˚; LÆeCÀœ®Î=7êE/Jç®àk‚ö€Ôg∏Ò‰ÿÜqw” Ûâ‡Ø§Í(§?4ye6ÉTAq◊!‹PUEŒéº˜‹U–≥ (Q¨sQ¨yãní†7	a1/°—∫Î·\7¿ÿ—Á‡RB§îãˆ`"`|†¿?¡ïÖ’¬'c∞bVôÌ%ÙÃàôô‹T∑yËÅÖ8@¬πÌMb‘+ˆ)Òg°·çrwˆ†î+QàÑSÚÛí	ÑÛËø°&œ¸í7ª@0ÇS0Ç;†¿6üôk
0
	*ÜHÜ˜
�0Åå1@0>U7Apple Application Integration 2 Certification Authority1&0$UApple Certification Authority10U

Apple Inc.10	UUS0
201214200231Z
231214200231Z0s1.0,U%AppleCare Profile Signing Certificate1 0UConfiguration Profiles10U

Apple Inc.10	UUS0Ç"0
	ÜHÜ˜
�Ç�0Ç
Ç�⁄˚ÒîE0H(Ï∂A§[˚B†JVﬂ˙LWÊ˝¯÷fˆ◊Ô√WW¿[khíü≥oÌRãtÈAjò≥ªQ¨wüÈñ˜;$ﬁ#¿Â∞ª§˝gB™b}œÒAÛ,≥!Çƒ˚—hsœ˚Íö“dÀt©P
+ÒèÜ¸˚SÔõõfƒÇeÔ2›V`^"˛Ô—8â{HéáÙFØ…UôÜw.î◊N_á‹ñHûà$&uwY``ÈL5ıòÓ⁄z¯O›óø”ôr°ÎD; H“âéyõÂ» H'>¯ ìÿÚ÷Qn‹∞
+˘l∑T⁄Á2ÑS•ˇQÜæi'•\?W∞ﬂ∫"zoS5S˚¢‘—"X‹/�£Çœ0ÇÀ0Uˇ0�0U#0Ä˜æ|!`ë€={ÿ:2Åiﬂûlõ0@+40200+0Ü$http://ocsp.apple.com/ocsp04-aaica020ÇU Ç0Ç0Å˛	*ÜHÜ˜cd0Å0(+http://www.apple.com/appleca0Å√+0Å∂Å≥Reliance on this certificate by any party assumes acceptance of the applicable standard terms and conditions of use, certificate policy, and certification practice statements.0U%ˇ
0	*ÜHÜ˜cd0U9Sˆ«G`‘∆?£l%áÍ$%∫∑0UˇÄ0
	ÜHÜ˜
�Ç�Sﬂ3Áh¬-3=%‡¨qëdŸERñ˜ﬂ˘æ)? nCÿŒÚ,õ]∂OLE.Ü|g#ÊQg%á«ºì™ÎKú∑ Á
S•OÔp4É⁄æô≤’Î(˜∏ÃÊsæ¶Ê@ƒÁ0AF�Ôt, ThœEißì|‡‡ﬁé⁄:Kéq˜€¯∑…Ñıy¨[$G…ç¯≠§Hﬁ÷‹Üw+˜p ò•A•
]z ]ùÔÜÚÈ/˚ˆìtÓP¯Soø≠ƒ|√Il” VæÈëÜ‰<» ÁÃ»óÔ¯Øf∞3∆5ús∏x¶cPbbã…UÇ¥V◊&Ò¶üËvπ†|: Ø"–Åâh≈≤1Ç=0Ç9Ä9Sˆ«G`‘∆?£l%áÍ$%∫∑0	`ÜHe0
	ÜHÜ˜
�Ç�ñ˚ƒƒDÜ˙™¿gì∏�´y6Ì€‹˙∫›§¢Ñ~/v›ÊBxâƒÖÊ,˛PﬂùÚ ¬ÔÖj¶∑tuæ`Ï◊v5„∏pÒÇÏÁÛ%°“™±Q|	Ω†j∆Àï¸fK0â$ˆ4}|à`Ûq(ä»ƒ∑ìÆj»—ß?)ÕT¿òaÇÏ¯&∏7°Ô#º£>Œer§—Õï® \zHkN©<5˝ÚºF4Ûãª®"\ï¡‘dÍGivo&D
÷ÖY\∏ÏÜ‰Aœ·Óèl„!1¿	±_4Òég4tC·	≤ç!~)HÓá∆$
„¶⁄¯)>eö, Ë√≤S˚t÷∑˙$,y


Cannot proceed further during tracker setup

After entering target username there are 2 options, neither one works. and it doesn't track anything as far as i'm aware

Hey @RV7PR have you made any changes to the script's code ?

@new92 did a fresh git clone without making any changes

@RV7PR Ok I made some changes, I think I found the bug. Delete the previous instatools folder, make a new git clone and let me know

Yes it's working now🙌🏼

@new92 I have a question tho, where are the current followers and followings get saved?

Yes it's working now🙌🏼

Great !

@new92 I have a question tho, where are the current followers and followings get saved?

The current followers are saved in a list named FOLLOWERS and the current followings are saved in a list named FOLLOWEES

So it's inside the script session? not saved by a file? so i cant close the script and later start it to see if there are changes?
I also noticed this inside the code:
while FOLLOWERS == FOLLOWERSAF or FOLLOWEES == FOLLOWEESAF:

But shouldn't that be AND instead of OR

My idea of the tracker would be that it first get all followers and followings and save that to a file, so you can close the script and  maybe a week later you start the script and compare the saved followings and followers to the current followers of followings and save an overview of all changes and update the followers and followings file

So it's inside the script session? not saved by a file? so i cant close the script and later start it to see if there are changes?
I also noticed this inside the code:
while FOLLOWERS == FOLLOWERSAF or FOLLOWEES == FOLLOWEESAF:

But shouldn't that be AND instead of OR

Yeah yeah, well the changes (the usernames of the followers / followees added / removed) are saved in a text file named trackerResults.txt so you can check them in there. Actually it should be OR but I understand your confusion. Well when you enter the num. 3 in the tracking options, the script tracks both for changes so if there is a change in followers and not in followees (if we had replaced the OR with an AND) it would be TRUE AND FALSE which equals to FALSE as a result it wouldn't display the changes in the followers. If you want further explanation please let me know

My idea of the tracker would be that it first get all followers and followings and save that to a file, so you can close the script and maybe a week later you start the script and compare the saved followings and followers to the current followers of followings and save an overview of all changes and update the followers and followings file

Well it's a good idea but I don't think the users would want to wait a whole week to learn about the results of the script. What do you think ? But for surely we can add that idea to the script. Let me create a poll about it.

My idea of the tracker would be that it first get all followers and followings and save that to a file, so you can close the script and maybe a week later you start the script and compare the saved followings and followers to the current followers of followings and save an overview of all changes and update the followers and followings file

Well it's a good idea but I don't think the users would want to wait a whole week to learn about the results of the script. What do you think ? But for surely we can add that idea to the script. Let me create a poll about it.

I was thinking more of an extra option to manually track, so you dont have to necessarily wait a week, you can update it after an hour or a day but that way you dont have to always keep the script running and just close it, it also doesn't have to update every 5 min and when you accidentally close the script you wont lose the updates in that timeframe

After checking back at my script i got this:
JSON Query to graphql/query: 429 Too Many Requests [retrying; skip with ^C]
Number of requests within last 10/11/20/22/30/60 minutes grouped by type:
                             iphone:    0    0    0    0    0    0
 * 37479f2b8209594dde7facb0d904896a:    9   13   25   25   41   81
   58712303d941c6855d4e888c5f0cd22f:   10   20   30   38   50  100
Instagram responded with HTTP error "429 - Too Many Requests". Please
do not run multiple instances of Instaloader in parallel or within
short sequence. Also, do not use any Instagram App while Instaloader
is running.
The request will be retried in 7 seconds, at 21:47.
JSON Query to graphql/query: 429 Too Many Requests [retrying; skip with ^C]
Number of requests within last 10/11/20/22/30/60 minutes grouped by type:
                             iphone:    0    0    0    0    0    0
 * 37479f2b8209594dde7facb0d904896a:   10   10   26   26   42   82
   58712303d941c6855d4e888c5f0cd22f:   10   17   30   33   50  100
Instagram responded with HTTP error "429 - Too Many Requests". Please
do not run multiple instances of Instaloader in parallel or within
short sequence. Also, do not use any Instagram App while Instaloader
is running.
The request will be retried in 324 seconds, at 21:52.
Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 403, in get_json
    raise TooManyRequestsException("429 Too Many Requests")
instaloader.exceptions.TooManyRequestsException: 429 Too Many Requests

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 403, in get_json
    raise TooManyRequestsException("429 Too Many Requests")
instaloader.exceptions.TooManyRequestsException: 429 Too Many Requests

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 403, in get_json
    raise TooManyRequestsException("429 Too Many Requests")
instaloader.exceptions.TooManyRequestsException: 429 Too Many Requests

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/****/github/InstaTools/Tracker/Tracker.py", line 639, in <module>
    main()
  File "/Users/****/github/InstaTools/Tracker/Tracker.py", line 473, in main
    FOLLOWERS = [follower.username for follower in profile.get_followers()]
                                                   ^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/structures.py", line 1131, in get_followers
    return NodeIterator(
           ^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/nodeiterator.py", line 93, in __init__
    self._data = self._query()
                 ^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/nodeiterator.py", line 103, in _query
    self._context.graphql_query(
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 483, in graphql_query
    resp_json = self.get_json('graphql/query',
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 448, in get_json
    return self.get_json(path=path, params=params, host=host, session=sess, _attempt=_attempt + 1,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 448, in get_json
    return self.get_json(path=path, params=params, host=host, session=sess, _attempt=_attempt + 1,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 438, in get_json
    raise ConnectionException(error_string) from err
instaloader.exceptions.ConnectionException: JSON Query to graphql/query: 429 Too Many Requests

My idea of the tracker would be that it first get all followers and followings and save that to a file, so you can close the script and maybe a week later you start the script and compare the saved followings and followers to the current followers of followings and save an overview of all changes and update the followers and followings file

Well it's a good idea but I don't think the users would want to wait a whole week to learn about the results of the script. What do you think ? But for surely we can add that idea to the script. Let me create a poll about it.

I was thinking more of an extra option to manually track, so you dont have to necessarily wait a week, you can update it after an hour or a day but that way you dont have to always keep the script running and just close it, it also doesn't have to update every 5 min and when you accidentally close the script you wont lose the updates in that timeframe

Oh okay, yeah sure that can be done.

After checking back at my script i got this:
JSON Query to graphql/query: 429 Too Many Requests [retrying; skip with ^C]
Number of requests within last 10/11/20/22/30/60 minutes grouped by type:
                             iphone:    0    0    0    0    0    0
 * 37479f2b8209594dde7facb0d904896a:    9   13   25   25   41   81
   58712303d941c6855d4e888c5f0cd22f:   10   20   30   38   50  100
Instagram responded with HTTP error "429 - Too Many Requests". Please
do not run multiple instances of Instaloader in parallel or within
short sequence. Also, do not use any Instagram App while Instaloader
is running.
The request will be retried in 7 seconds, at 21:47.
JSON Query to graphql/query: 429 Too Many Requests [retrying; skip with ^C]
Number of requests within last 10/11/20/22/30/60 minutes grouped by type:
                             iphone:    0    0    0    0    0    0
 * 37479f2b8209594dde7facb0d904896a:   10   10   26   26   42   82
   58712303d941c6855d4e888c5f0cd22f:   10   17   30   33   50  100
Instagram responded with HTTP error "429 - Too Many Requests". Please
do not run multiple instances of Instaloader in parallel or within
short sequence. Also, do not use any Instagram App while Instaloader
is running.
The request will be retried in 324 seconds, at 21:52.
Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 403, in get_json
    raise TooManyRequestsException("429 Too Many Requests")
instaloader.exceptions.TooManyRequestsException: 429 Too Many Requests

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 403, in get_json
    raise TooManyRequestsException("429 Too Many Requests")
instaloader.exceptions.TooManyRequestsException: 429 Too Many Requests

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 403, in get_json
    raise TooManyRequestsException("429 Too Many Requests")
instaloader.exceptions.TooManyRequestsException: 429 Too Many Requests

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/****/github/InstaTools/Tracker/Tracker.py", line 639, in <module>
    main()
  File "/Users/****/github/InstaTools/Tracker/Tracker.py", line 473, in main
    FOLLOWERS = [follower.username for follower in profile.get_followers()]
                                                   ^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/structures.py", line 1131, in get_followers
    return NodeIterator(
           ^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/nodeiterator.py", line 93, in __init__
    self._data = self._query()
                 ^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/nodeiterator.py", line 103, in _query
    self._context.graphql_query(
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 483, in graphql_query
    resp_json = self.get_json('graphql/query',
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 448, in get_json
    return self.get_json(path=path, params=params, host=host, session=sess, _attempt=_attempt + 1,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 448, in get_json
    return self.get_json(path=path, params=params, host=host, session=sess, _attempt=_attempt + 1,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/instaloader/instaloadercontext.py", line 438, in get_json
    raise ConnectionException(error_string) from err
instaloader.exceptions.ConnectionException: JSON Query to graphql/query: 429 Too Many Requests

Hmm, this error seems like frequent usage but let me take a better look at it and I'll come back to you.


push frame updates to datomic

Feature Persist Frame State
This feature will formate each frame after it has finished processing and save that state to datomic. After the game has finished, a transaction to update the game status is submitted and the game is transitioned to a closed state.

Not yet. This feature is just responsible for updating datomic with frame / game updates.


provider upcall test under MSVC

Question: Is there any test case building and loading a test provider via the "external" load mechanism, i.e., not using OSSL_PROVIDER_add_builtin? I'd then like to extend it like e.g. here.
Reason for asking: oqsprovider faces one of the most bizarre test case problems it has ever seen: Always when building/running oqsprovider, the upcall via c_obj_create (OSSL_FUNC_core_obj_create) succeeds; but only under MSVC a subsequent check whether a NID has really been assigned receives NID_undef (checked e.g. via OBJ_sn2nid).
This failure however only happens if the configuration file activating oqsprovider is loaded by using OSSL_LIB_CTX_load_config If in turn "OPENSSL_CONF" points to the very same file a NID gets properly returned (as always is the case under UNiX).
The good test case can be observed here, the bad test case here: In the latter case, "OPENSSL_CONF" has not been set for the first 3 (failing) tests. A check added to testing is here -- but passes testing also on MSVC -- presumably because as it's using OSSL_PROVIDER_add_builtin. Hence the original question.
Thanks in advance for any thoughts. Hunch: Does the logic loading providers differ (under MSVC) when being passed a specific "libctx" vs. loaded "globally" by setting "OPENSSL_CONF"?

Unfortunately there is no internal test provider built as shared module.

Unfortunately there is no internal test provider built as shared module.

Thanks for this re-confirmation. I'd like to suggest this then as a feature (request) for any possibly upcoming discussions regarding provider development.

Unfortunately there is no internal test provider built as shared module.

Errr.....p_test.so? See test/p_test.c

Loaded from test/provider_test.c

Ouch, sorry for forgetting about that one.

Thanks for the pointer. I tried to reproduce the error behaviour with p_test but failed. This issue thus is resolved -- but might be followed up by sth else if/when I understand better why oqsprovider behaves so differently under Windows as compared to Unix.


Error in Training Code!!

Size missmatch in loss0 = self.criterion(outputs[1][0],targets). outputs[1][0] producing an 1 dimensional tensor but target has 48 elements. The error is -
dimension out of range (expected to be in range of [-1, 0], but got 1). Any help will be highly appreciated.

Never mind. I found the issue!!


Derive Default for Rect

Makes it slightly nicer to work with and I don't see a reason against the derive. Pos2 already is Default.

There is a reason: what should the default be? You have now defined it to be the rectangle containing the origin (0,0). When does this default make sense? I don't know. I do know that this default is a foot gun when you want to use Rect as a bounding box - then Rect::NOTHING is a better default. Yes, I have seen that exact problem cause bugs :)


CI against JRuby <IP_ADDRESS>

JRuby <IP_ADDRESS> has been released.
http://jruby.org/2017/12/07/jruby-9-1-15-0.html

👍


[Playground] Result filter bug

What happened?
Steps to reproduce:

Select an example
Press the 'Run' button
Wait for results
In result filter select 'Output' option
Press the 'Run' button again

Expected behaviour:
Filter uses previously selected option 'Output' and user sees only the outputs.
Now:
The filter resets its state and user sees both logs and outputs.
Issue Priority
Priority: 3
Issue Component
Component: beam-playground

.take-issue

.take-issue


[Flink] Unified usage method for the parameter 'metadata columns' in the mysql database cdc and mysql table cdc

Purpose

Unified usage method for the parameter 'metadata columns' in the mysql database cdc and mysql table cdc
Before modification:
In mysql database cdc, the metadata column is separated by commas;
In mysql table cdc, the metadata column directly obtains multiple parameters.

Tests

API and Format

Documentation

API is something we need to focus on considering compatibility, and behavior is a part of API. Unless absolutely necessary, we should not compromise API compatibility.


feat: Add next-auth middleware to protect pages

Motivation
At present, we do not have a streamlined approach to prevent unauthorized access to pages that require the user to be logged in. The current implementation involves manual checks on the session to determine if the user needs to be redirected to the login page or not.
Solution
Introduce next-auth middleware to handle the protection of pages that require the user to be logged in. The middleware will maintain a list of protected paths and in case the user is not logged in, they will be immediately redirected to the /login page. This not only simplifies the codebase by removing the redundant code for page protection but also saves bandwidth for the user.
Changes

Implement next-auth middleware to protect the /settings/account page
Create a constant for the path /settings/account
Set the redirection to /login for unauthenticated users
Remove the secret option in favor of using NEXTAUTH_SECRET in Vercel's project environment variables
Add a test file to cover the middleware.ts file

Testing

Log out of the application
Access the /settings/account page and verify if it redirects to /login
Log in to the application by filling in the login form
Verify if it redirects to /settings/account after successful login

Additional Info
In future pull requests, more pages such as /review/[lessonSlug] will be added to the list of protected pages.
Related issues

#1629

I noticed there are some hardcoded paths in the new changes, maybe consider using the constants instead?

@SlyBouhafs Thanks for reviewing the PR :)
I fixed most of the issues.


TabsColor does not change colors for "quickly opened tabs".

If you quickly open files in Vs Code from the list in the panel on the left, they all open in the same single tab. This is done specially so that only useful tabs stay opened in the program. New tabs for files are opened only if the file is dragged with the mouse or if a lot of time has passed since the previous tab was opened.
Tabs Color  does not know how to handle tabs that are openinig quickly. Every time I set the color for a quick-open tab, the color doesn't change.  But if I drag the same tab into the right panel with my mouse, the tab's color will immediately change. The same thing happens if I type anything on a quick opened tab. Please find enclosed gif screen recordings.
Tabs Color v0.2.11, Windows.
The same behavior for local folder and when working with SSH Remote.

v.0.2.12 added "Support tabs in preview mode".
It's seems to fix issue but not for tabs colored by directory.
Files listed in settings with tabsColor.byDirectory{} has no color in preview mode.

the preview mode coloring is now possible but with limitations, follow the thread here #48


dynamodb-local: 2023-12-14 -> 2.2.1

Description of changes

Added a maintainer script to auto update the dynamodb-local package.
The version number was wrong, the downloads are versioned by their release date, but the version was different.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[X] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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

[ ] 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
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.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

[X] Fits CONTRIBUTING.md.

How about moving the update script out of the nix file ?

^^


Automatically update and check copied code

We copy the GraphQL models from the stolostron/search-api-v2 project in order to avoid additional dependencies. This patch adds go:generate directives to automatically update that code when make generate is executed.
Related: https://issues.redhat.com/browse/MGMT-16108
Related: https://github.com/stolostron/search-v2-api/blob/main/graph/schema.graphqls
Related: https://github.com/stolostron/search-v2-api/blob/main/graph/model/models_gen.go

FYI: @danielerez

/lgtm


Docs: Label clarification

Signed-off-by: John Howard<EMAIL_ADDRESS>1.6 came and went some time back... Just made the docs a little more consistent between two adjoining sentences :smile: @thaJeztah

LGTM, thanks!

LGTM 🐯


remove redundant allocation in msm

This vec is only used for flat_map

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (master)
[ ] Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[ ] Wrote unit tests
[ ] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[x] Re-reviewed Files changed in the GitHub PR explorer

amazing, thank you -- this looks great!
Do you have any benchmark to see if that degrades unexpectedly performances?
(this stuff is all sensible to caching)

amazing, thank you -- this looks great!
Do you have any benchmark to see if that degrades unexpectedly performances? (this stuff is all sensible to caching)

Only local benchmark that shows less allocations and up to 5-10% improvement on really big inputs

amazing! MSM's would really benefit a lot when the bounds on the scalar vector is known in advance. I just created an issue on https://github.com/arkworks-rs/algebra/issues/685 as it should be separate from this one.


fixed message not displaying for invalid input

Description of changes
This fixes the issue with errors not displaying when an invalid input is enterd in one of the fields when the user is creating/ updating a book. Also, the styling for erros was updated in previous commit for creating a book but not for updating a book. This has now been fixed.
Fixes #66
Screenshots (If Applicable)
N/A
Checklist

[ ] I have unit tested my code.
[ ] I have integration tested my code.
[X] All new and existing tests passed.
[ ] I have updated the diagrams ModelsUMLClassDiagram and EntityRelationshipDiagram (if necessary).

Please rename your branch to bug-fix/update_class_of_error_msg
Same goes to the commit
Also does the model attribute check belongs in this pr
Shouldnt be a different pr?

Please rename your branch to bug-fix/update_class_of_error_msg
Same goes to the commit
Also does the model attribute check belongs in this pr
Shouldnt be a different pr?

The model attribute check is what makes the message show up again