Collect branches automatically.

Codecov Report
Base: 27.81% // Head: 27.81% // No change to project coverage :thumbsup:

Coverage data is based on head (b2f6659) compared to base (c409320).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           stable     #572   +/-   ##
=======================================
  Coverage   27.81%   27.81%
=======================================
  Files          69       69
  Lines        5767     5767
  Branches      318      318
=======================================
  Hits         1604     1604
  Misses       4089     4089
  Partials       74       74

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Proposal: database/sql/driver Execer should support more types

What version of Go are you using (go version)?
go version go1.5 darwin/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/user/gocode"
GORACE=""
GOROOT="/Users/user/.gvm/gos/go1.5"
GOTOOLDIR="/Users/user/.gvm/gos/go1.5/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT=""
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

Proposal/issue
I maintain a database/sql driver for crate.io (Crate), at https://github.com/herenow/go-crate
Crate is a "sql" database, it has support for object/json columns, and prepared statements are "baked in", in the sense that it provides us with a REST api to perform our operations, where we pass it our prepared statement and the args/bulk_args. For example:
curl -sSXPOST '<IP_ADDRESS>:4200/_sql?pretty' -d@- <<- EOF
{
  stmt: "INSERT INTO logs (metadata) VALUES (?)",
  bulk_args: [
      { count: 1 },
      { count: 2 }
  ]
}
EOF

Currently it doesn't seem possible to support something like:
db.Exec(`INSERT INTO logs (metadata) VALUES (?)`, []map[string]interface{}{...})

Because database/sql/driver only supports []byte, bool, float64, int64, string, time.Time [1], is that right?
Would it make sense for us to add support for any generic interface or allow drivers to provide their own IsValue()? Are there any alternative solutions?
[1] https://github.com/golang/go/blob/0104a31b8fbcbe52728a08867b26415d282c35d2/src/database/sql/driver/types.go#L180

/cc @bradfitz

@herenow No guarantee, but I'd like to do something about this for go1.8.

This is a dup of https://github.com/golang/go/issues/13567 .

Thanks. Closing as dup. We'll track in #13567


increase version to 0.4.0

was 0.3.9999

Coverage remained the same at 99.387% when pulling 09d47a8b0f263f2cca12d3daa22db7a476eeccc8 on gdkrmr:patch-1 into 808b1eb46d99102fb41881fe996012a8c2688d3f on trthatcher:master.


Creating OTP device throws 500 status code error

I am trying to add OTPDevice but getting this error

Endpoint: POST /api/v1/auth/otp-device/
Payload:
{"type":"email"}

Not sending name as it should automatically use it from backend. Correct me if I am wrong.
I am not sure if the OTPDevice's name is a good idea to be used for requesting OTP. This flow looks ambiguous to me.

name should be email/phone


Content inside the NotchKitWindow has user interaction disabled

Nothing inside the NotchKitWindow's active display ares is intractable via touches. See the video (inside of the ZIP) for an example:
NotchKitBug.mov

@roonieone I added        safeView.isUserInteractionEnabled = false to NotchKitWindow.h > setup() to fix it.

Fixed for the next release! Thanks!


Add will-change CSS properties

Tested with Chrome 37; with this property the overlays are rendered into their own rendering layer.
This can be seen by checking the "Show composited layer borders" in the chrome dev tools

@fredj are you interested in continuing this work? Closing for now. Feel free to reopen if you want to work on this again.

This PR is ready

Looks good to me. Please.
PS: I hope this won't break anything.

I'll wait for  #2594 before merging

Makes sense.

This has waited for a long time now. If no objection is raised I'll merge this PR.

Yep, please merge. Thanks.


Can point cloud upsampling downsampling be done during network forward pass?

Greate work in point cloud processing!
I noticed that in your work, point cloud sampling and neighbor search is done before the data is fed into the network. I wonder why this should be done in advance not during the forward pass of the network? And what is the drawbacks if the subsampling and the KNN is done during the forward pass?

Hi @liuzhy71,
If you downsample during the forward path, then you also have to compute convolution neighbors during the forward path. If downsampling is super fast, the neighbor computation is not so much. Therefore, some non-negligible amount of time will be used for downsampling + neighbor computation, slowing everything down.
If you downsample before the forward path, you can actually use your CPU efficiently and compute downsamping + neighbors WHILE the GPU is computing the previous forward path. Therefore the forward path is faster, and when it is done, a new input is already ready with downsampling and neighbors already computed. This is what we do here.

If my understanding is right, proprocessing the point cloud before the forward pass is used to speed up the training time. While for the inference time, the total amount of time is still the same. And furthermore, if I want to have a dynamic point cloud hierarchy of different resolution, the subsampling and neighbor search should be inserted into the forward pass?

In the case of inference, the processing time is also reduced. We can achieve a higher processing frequency for offline inference tasks. For online inference in real time, our pipeline is not ideal and has big delays.
Yes for dynamic point cloud hierarchy, you have to subsample during forward pass. A new version of the code will soon come out with this option.
In the mean time you can have a look at https://github.com/qinzheng93/Easy-KPConv which solves this


vite-plugin-kit-routes: support ENV specific routes and anchor links

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

I have hardcoded LINKS that are ENV specific.
Support Anchor Links example.com#section

Describe the solution you'd like

Add ENV support for hardcoded LINKS
Add a way to support Anchor links

Describe alternatives you've considered

Avoid using vite-plugin-kit-routes, and add in environment specific hardcoded links in in environment specific files env.local and env, lose type-safety.
Template literal with ${route('/')}#

Thx for reporting 👍
As there are 2 topics not really connected, could you split in 2 issues ? Can you also had an example for the env route ?
Ty

I have resolved:
1.vite.config.ts, supports ENV variables so this is all set.
So only issue is anchor link


Make exists templating syntax work with environment backend

Hi,
would it be too hard to make the following thing work?
{{if exists "VARIABLE"}}
    value: {{getenv "VARIABLE"}}
{{end}}

I tried it and could not make it work and it could come very handy when not using consul and other backends.
Regards

{{ if getenv "variable" }} should do the same thing. exists determines if a key exists in the existing backend.

ah ok I did not see that in the docs :)

From text/template's if:

If the value of the pipeline is empty, no output is generated; otherwise, T1 is executed.  The empty values are false, 0, any nil pointer or interface value, and any array, slice, map, or string of length zero. Dot is unaffected.

getenv is a call to os.Getenv, which returns an empty string if the envvar is not present, which is why this behaviour works that way.


MEDAL CHANGER IS ALREADY INTEGRATED

while i was searching how to make a profile changer
i ran into a post "https://www.unknowncheats.me/forum/counterstrike-global-offensive/298336-rank-win-medal-changer.html"
someone in there said that nskins wich is the skin changer used in osiris
has a medal changer
but it has no GUI for it
@danielkrupinski please add it
its as easy as it can get
i couldn't do it because i didn't know how to edit the GUI
https://github.com/namazso/nSkinz/blob/master/src/Hooks/PostDataUpdate.cpp#L153

Editing the GUI is easy as it can get https://github.com/ocornut/imgui/tree/master/docs :)

And we you to include protobuff too

what should i do to get it to work

Add New Feature => PULL REQUEST
The Code by the way isn't helpful on Osiris. If you are so smart and copy & paste it here. Try at least to understand it and change the things like CUserCmd or anything else because any posidocode is better than paste from another cheat.

@Bywnb I think u meant puesdocode

ok


manifest match should throw exception when {match} not found in the input

but there should be a setting to override this.

resolved


Remove unclosed #pragma from code sample for GetMetric

Remove #pragma warning disable CA1716  // Namespace naming from the opening line of the code sample for GetMetric

@CorruptedHeart : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


1.21.1 Fabric support

Just some simple API calls and dependency version changes to support 1.21.1 fabric

Already done.


Create the 'all' command

I have created a branch 'print_all_command' to put together some code to show how the all command can be added. This branch also refactors some of the existing functionality (log loading) into it's own function and removes the global log data variable.
I am not sure about creating a PR for this yet as I have branched from the 'write_to_file' branch in order to take the existing switch case based argument parsing approach. Perhaps it is best to wait until #12 has been merged into master before creating a PR?

Excellent.
I'll merge what we have of #12 today to keep your branch from rotting. Even though write-to-file functionality doesn't exist, we will return to it shortly.

Merged! you should be good to make a PR.

PR #16  created for review.

PR #16 Merged.


vela delete --force not supported in Linux v1.1.13

Describe the bug

vela delete --force are supported in release v1.1.13. However it' not working in Linux release.
To Reproduce

Download vela CLI release v1.1.13 for Linux.
run vela delete --help
There's no --force flag

Expected behavior

--force are supported as expected.
Screenshots

KubeVela Version
v1.1.13

Cluster information

Additional context

https://github.com/oam-dev/kubevela/pull/2747 is not backport to 1.1.x branch. It's now available in v1.2.0 and later version


SolverProblemError should provide more information about why a dependency can't be satisfied

I have a big project with lots of dependencies that I'm trying to get working in poetry. I'm getting this error when trying poetry install
  [SolverProblemError]
  Unable to satisfy the following requirements:
  - "django-imgix (^1.1.0)" required by "pyproject.toml"

Even if I pass -vvv I'm not getting any more information about what's wrong. I assume there's some conflict in the dependency tree somewhere, but I have no idea where it is. It'd be nice if poetry would print out information about what constraints have been applied to this package and where those constraints come from.

Well I just checked and it seems the maintainers of django-imgix have messed up their releases.
If you take a look at https://pypi.org/pypi/django-imgix/json you can see that there are no distributions for release 1.1.0 but the tarball of 1.1.0 is actually under the 1.0.0 release. So the resolver fails because it can't find any distributions for release 1.1.0 since no packages is returned (See https://github.com/sdispater/poetry/blob/master/poetry/repositories/pypi_repository.py#L92).
I could remove this condition but it would lead to the dependency being resolved (even though its dependencies wouldn't be) so I prefer poetry to fail early.
However, I agree that I should add some logging information in the PyPI repository class to ease debugging.

I appreciate very much that you looked into this problem @sdispater. I'll work around this problem by using a git dependency.


Initial pass at adding site expansion feature

As detailed in https://github.com/narc0tiq/YARM/issues/18
Known issues:

[fixed] tabs vs spaces. Oops.
[fixed] The corners of the buttons are no longer transparent. mspaint has failed me for the last time. :rage4:
[fixed] The "highlight the contents of the existing site" code doesn't actually work. I suspect that's me being bad at Lua.
[fixed] spamming the '+' button gets lots of console output (because the new button will submit any current site, then adds the site you want to expand back to player.current_site. Thinking maybe we should mute console output if there's no actual change?

However, the core of it does actually work. In my test game I have YARM monitoring a single 'patch' that's actually six different patches spread over about a thousand tiles of distance.
Thoughts:

If we have a button that allows expansion of a site, can we kick down the timer for finalizing a site to 3-5 seconds? Or maybe (this is a bigger rewrite), there shouldn't be a timer at all - smack the YARM on an ore patch and it immediately adds it, then hit the 'expand site' button and smack it on another ore patch to add that?

OK I think I've fixed the breaking issues now:

The "existing sites not highlighting" was me completely misunderstanding how tables in Lua work.
Upgraded from mspaint to paint.net and did the graphics properly.
Also fixed tabs vs spaces.

I'm still unsure about the console output for unchanged sites thing - could be unintuitive if you silently timeout.

Oh, one other thing I just thought of - with this it might be possible that the same ore patch is tracked in multiple sites. Unsure if it's worth defensively coding around this (or if it's even a problem), though.

Nah, the design makes it too hard to avoid tracking the same ore in different sites, so we just won't worry about it (and it was perfectly possible to do it before, too).
Realistically, it doesn't really matter that much, except in that the ore will be getting queried twice, so it might be a little more CPU time for the client. The (somewhat stalled) upgrade I was working on would've/will fix that by decoupling the ores from the sites.
I think I agree that we almost don't need a timer anymore, except for oil sites (which are somewhat inconvenient now, but would get really inconvenient if you had to do two clicks per oil spout). This might be mitigated by having a larger search area for when you smack an ore for the first time and it has no direct (8 adjacent) neighbours of the same kind. I'd love to mostly-automatically cover most oil deposits.
I also agree that a site that hasn't changed shouldn't output any feedback console text (conversely, if it has changed, the difference should be highlighted, e.g., "Site that_site updated, now has 256,000 iron ore (+27,000).").

Thank you for the excellent submission; I haven't reviewed the code yet, but the feature is wonderful!
I have a curiosity: should we limit the extent of a site, or do we not care? In particular, I'm thinking remote viewing a site that's actually comprised of "all the iron ore on the map" isn't going to give you much value (we can probably disregard the potential performance hit of having that many ores in a single site -- that should only affect the rate at which its totals and estimates update). On the other hand, having that site allows you at-a-glance estimate your total consumption, since we don't have a "totals" filter yet.

Site size limits - the reason I wrote this feature was to support extremely large, discontiguous sites - so I might be a bit biased. :) The perf impact of having a large site seems negligible (based on very quick testing, with absolutely no science behind said testing).
Not multi-tracking: About the only way you could do this would be to have a global table of sites with just ore_type + extents, and check that any time you add single ore. Agreed - not worth the effort, and potentially counterproductive until/if summary-per-ore is added.
Adding appropriate console text for expanded sites - will add that (probably not for a couple of days, though. However, the reason I'm saying the behaviour could be a bit unintuitive is if someone hits the '+' sign then gets distracted for a few seconds, the expansion will silently time out and they'll accidentally create a new site. Should the timer even apply to expanding sites? (if the timer didn't apply, would probably want a UI button for cancelling expansion)
Timer/oil sites: we could hardcode a wider search radius for oil, but that would probably not work particularly well for modded resources with oil-like spawn patterns (bob/dytech gems maybe?). So maybe the search radius, per-ore-type, should be in a config file somewhere? (with default of immediate-neighbour for anything not explicitly configured). Would have to be careful how the extended-range search was written to avoid duplicate tracking (and infinite loops as you track site A which sends you to B which then finds A again ...) though.

Also - total consumption is available via the production screen, but I could also see the use of having partial summaries (e.g. two different iron ore fields feeding your steel production, while another fields feed your science factory and three more fields feed your rocket factory). So yeah - maybe we should add that to the documentation that multi-tracking is implicitly supported?

Coming back to the console text for expanded sites - I guess one way to help the invisible timeout issue would be to have the '+' button show as clicked/highlighted until it times out. Thoughts?

the reason I wrote this feature was to support extremely large, discontiguous sites

Makes sense to me, and I'm glad it doesn't significantly affect performance, either. Glad to have it, then!

have a global table of sites with just ore_type + extents

Allow me to introduce you to my friend v0.8-dev (as previously stated, a little bit stalled by my lack of attention). Instead of sites containing references to individual ore entities, they store indices from the ore tracker (which invisibly uses some trickery to store the ore data in a reasonably memory-efficient way). Notable trick: the entity references aren't persisted (avoids long save/load times -- Factorio has to do a lot of lookup to restore the proxy objects, especially if doing it at load-time for a lot of entities), but get reacquired on request.

the reason I'm saying the behaviour could be a bit unintuitive is if someone hits the '+' sign then gets distracted for a few seconds, the expansion will silently time out and they'll accidentally create a new site [when they actually click].

Right, we should avoid doing that until we have some UI to show the timer itself, e.g., a progress bar. A button to cancel addition/expansion would be good, too, and then we could really do away with the timer for good (just remain in that mode until the player presses a "commit" button, maybe). I don't think that change would be so horribly cumbersome to players, and is likely more discoverable than invisible timers.

we could hardcode a wider search radius for oil

Not specifically for oil -- just trigger it if, after the first time it searches for ore around the first tile, it doesn't find anything (i.e., the first ore is a single entity without any others orthogonally or diagonally adjacent). Oil-like resources have to match this because the oil pump is a 3x3 that will have the ore in the middle (in fact, they must have at least two tiles distance between them on at least one axis).

this de-duplication is already in the current search

Yeah, it's pretty safe, I'm only concerned that a wider radius might make for a slower search -- but we're already asking the surface for "all entities of this type within this area" and getting an iterator, so the code probably doesn't change otherwise. The normal (quite dense) ores would fail the de-duplication check a bit too often for this to be a general behaviour, though (de-dup does take a bunch of CPU time).

total consumption is available via the production screen

But not the actual ore item production rate, nor an estimate of how long until it all runs out -- consumption only tells you production rate when the system's buffers are saturated.

maybe we should add that to the documentation

Definitely!

one way to help the invisible timeout issue would be to have the '+' button show as clicked/highlighted until it times out

The delete button does that -- it turns red to indicate "click me again to really delete the site, or wait for me to turn white again to cancel". It's a little difficult for players to discover, but it suits the feel of YARM as it stands.

One more note: I've skimmed your code, it looks very good. I might have specific requests later, but expect them to be lint checks at most.
I wanted to ask: maybe in a separate PR you could use reconstruct_overlay_for_existing_site to close #10? I've wanted the ability to review the overlay since YARM was created, but it was never a priority -- now it just fell into our laps, metaphorically speaking.

Not specifically for oil -- just trigger it if, after the first time it searches for ore around the first tile, it doesn't find anything

Valid, but depending if you're using RSO or base game resource gen or mods that add custom ores, you may want to have a configurable search radius. However, this is all a moot point because I'm (currently) not game enough to attempt to rewrite the mod to remove the timer completely. :)

maybe in a separate PR you could use reconstruct_overlay_for_existing_site to close #10

Doable - it'll be current extent only, not historical extent (untested - based on my understanding of resmon.tick_deposit_count, that function removes exhausted entities from the site). That good enough for now? If you're rewriting the core of the tracking in v0.8 then I'm not sure how much time is worth spending on a custom solution for historical extent tracking (I do agree it'd be cool, but would need some faffing about with the site data structure to not remove exhausted entities (leave them with a count of 0?), and appropriate changes to resmon.tick_deposit_count and resmon.finish_deposit_count). Idea: It'd be even cooler if the overlay was faded somewhat for areas that are in the historical extent but have since been exhausted. (if I'm understanding what you're doing in v0.8, historical extent tracking may not even be possible at all then because you said individual entities aren't persisted...)
On a side note, is there any way to zoom out the remote viewer so that it actually takes in the full scope of the current site? Obviously there has to be a limit somewhere, but at the moment it seems like you can add two patches of the same ore, spread by about ~100 tiles vertically, and the remote viewer will spawn in the middle of the extent and show absolutely nothing useful. Idea - rather than storing the overall extent of a site, we store the extents of each time the YARM is smacked on the ground, then allow the remote viewer to tab through views of the extents of each subsite. (Again, this is with the perspective of someone who monitors sites with a total extent size of ~1,000 tiles each way...)
Anyway, when I'm next free to spend some time on this, my plan is to:

add a new button prototype for the 'clicked-expanding' state. (NB: as above, will keep the existing timer mechanics as they are)
add new string for YARM-site-expanded. However, I see there's four locales in the mod at the moment - what happens if there's an incomplete localisation?
futz with code appropriately so that:

YARM-site-expanded is printed after a site is expanded.
YARM-site-submitted is printed after a new site is created only (i.e. not after a site is expanded).
nothing is printed after the expand button is hit but no ore was added to the site before the site was submitted.

it'll be current extent only, not historical extent

Yeah, either way works, and current extent is all we track. Historical extent would be cool, but too much effort at the moment.

individual entities aren't persisted [in v0.8]

No, but persistence (what's in global and remains over save/load) and retention (what we remember about a site until it's deleted) are different things. We can retain the coordinates if it's worth it (my default stance is to avoid doing so, but we can), which is what we need to be able to show the overlay -- I'm not 100% certain it's worth the extra complication, but it might not be that complicated.

zoom out the remote viewer

Programatically? There is a write-only player.zoom, but I'm not at all sure how we translate coordinate bounds to a required zoom level (and we don't/can't know the player's viewport size, either).

we store the extents of each time the YARM is smacked on the ground

Can't read that (remember, in multiplayer, remote peers only exist as conceptual entities -- they don't have a viewport), but we can store the coordinates that were smacked and center on those, cycling through multiple ones -- needs a "next camera" button. I also wouldn't mind placing an entity where the player smacks the ground, which would be the notional "camera" that is remotely monitoring.
You wanna write that into an issue, so we don't forget?

what happens if there's an incomplete localisation?

I believe it falls back to the English locale text if only that one exists. I'm not at all sure what would happen if, say, only Hebrew existed. Probably just an "Unknown locale: locale-key" message.

Your plan sounds great! I look forward to seeing it in action.

OK, I think that's everything. Hopefully.

Beautiful, thanks, mate. I'll have a look at it tonight after I get home from work (in a few hours).

Sorry about that, got caught up in AFK life things instead; I'll get to it soonest.

Hey there, thanks so much for the work you've put in! This is amazing, and I've finally gotten a few minutes to play around with it.

First thought: it's really weird that you can press the + and then have to go hunt down (and pick up) your resource monitor item. Maybe the button shouldn't be visible unless you have the monitor in hand (less discoverable, but also less inconvenient to the player), or perhaps you should have to press the button with monitor in hand (and message the player to tell them what to do if they just press it normally).
The biggest obvious concern: clicking the + button can cause a noticeable pause on a large site (1-2 seconds on my 5 million iron ore site), and it's down to the existing ore highlight. Factorio doesn't like making a lot of entities all at once, so this is why the sites build up over multiple ticks (the animation is cool, too, but that's a side-effect). Secondary mention: RSO can make some ore deposits with huge entity counts, so some players would see this pretty much immediately.
Bug report: I clicked to add to a site and then clicked the ground accidentally. This canceled the addition, but the button is still red. The console shows Error: __YARM__/resmon.lua:377: attempt to index local 'site' (a nil value).
Visual effect: it takes until the next visual refresh for a site's + to turn back white. I haven't looked at the code in detail, but can you trigger a visual update after site editing finishes?
Worth noting: clicking the + button resets the site's percentage, even if you do nothing else. This is acceptable, but there should maybe be a mention in the Readme.

I am otherwise impressed by how well this huge (by extents) site is working out. Sure, it takes a couple of refresh cycles to update its stats, but it does update them regularly enough I'm not going to complain. And I love being able to keep adding to it.
This is great!

Existing highlight: should we make this a mod config option? Or tweak it somehow so it builds up over some number of ticks? Thinking maybe something like (pseudo code):
on each tick:
if temp_list is empty and entity_table is not all highlighted, pick an entity from entity_table into temp_list
for each entity in temp_list:
- highlight entity
- add immediate neighbours to temp_list

Which, assuming I can logic, should mean each ore deposit should be highlighted sequentially (but with no guarantee of which deposit gets chosen first) - the other option is we store a list of places where the YARM has been smacked with each site and radiate out from there (or if we ever put the camera/multiple views thing in, the cameras would be a natural place to highlight from). That's probably more natural, but a bit more work - and will also potentially fall apart when sites get near to exhaustion (because then the YARM smack site is empty ground, rather than being a resource).
Bug report: will investigate sometime over the weekend.
Vis fx: yeah, we can force an update for all players in submit_site. I should probably pull that out into it's own function because it's called in four or five places already.
Percentage reset: I can probably work around that, but it's going to be a bit complicated. Actually ... it's because I call resmon.finalize_site in resmon.on_click.expand_site, which I'm fairly sure is mostly redundant - we don't need to reset stats or recalculate the bounding box when the GUI button is clicked. Should just be able to get away with setting the finalizing state and the finalizing_since tick count.

each ore deposit should be highlighted sequentially (but with no guarantee of which deposit gets chosen first)

Right, we don't really care about order necessarily, we just need to be building up the entities gradually (at whatever rate they get built up during ore discovery).

and will also potentially fall apart when sites get near to exhaustion

That's the biggest reason to avoid it, really. The hybrid you've shown, that picks an entity from the site's list and radiates out from there using normal ore discovery, is pretty good. You might even be able to use the ore discovery code directly with some refactoring.
In v0.8 this will probably even start with the earliest discovered ore still existing, because the site ore list will be a simple array.

Should just be able to get away with setting the finalizing state and the finalizing_since tick count.

I think so, yes. Give it a try, see if it helps. I imagine it'll still reset if you do make changes, but then at that point, the player should be expecting it.

One other thing I just thought of: what happens when two players try to expand the same site at the same time? With two sub-cases: either they're expanding it into the same new patch, or into different patches.
You should look me up (Narc0tiq) on the Factorio IRC (irc://irc.esper.net/#factorio) and see if we can get together and mess with it in multiplayer some time.

One other thing I just thought of: what happens when two players try to expand the same site at the same time?

Huh, that's a fun one. Best guess - the UI sync is forced in all the right places (I think) so they'll both be expanding the same site, and either:

the first one to submit will write the new site data into force_data, and the second one to attempt to submit will either get an error or silently fail; or
the first one to submit will write their version of the site into force_data, and the second one will overwrite the same site.

I'm picking the first option as the more likely one but I'm not 100% certain.

Bug report: I clicked to add to a site and then clicked the ground accidentally. This canceled the addition, but the button is still red.

Resolved. Turns out I didn't actually test as thoroughly as I thought I did. :flushed:

Worth noting: clicking the + button resets the site's percentage, even if you do nothing else.

Resolved. Removed the call to resmon.finalize_site in resmon.on_click.expand_site and instead just set the finalizing state and time directly.

Visual effect: it takes until the next visual refresh for a site's + to turn back white. I haven't looked at the code in detail, but can you trigger a visual update after site editing finishes?

Resolved. There's a new function resmon.update_force_members_ui', too (because I was doing for _, p in pairs(player.force.players) do resmon.update_ui(p) end in six different places).
So, the only open issue is making the highlighting not-blocking, plus maybe the UX of needing to find your YARM after pressing the + button. I guess the other option there would be to bring the player's YARM into their cursor (assuming they have a YARM and their cursor is empty).

I'm picking the first option as the more likely one but I'm not 100% certain.

I'd guess at the latter, actually, because the key (the force, and the site name) is relatively stable (incidentally, this suggests we can copy a site if one player renames it while another is expanding it; I do not consider this an issue, necessarily, but it should not crash).

Turns out I didn't actually test as thoroughly as I thought I did.

Yup, that happens. Er, I mean, cough, I have no idea cough how that could possibly work. cough :angel:

I guess the other option there would be to bring the player's YARM into their cursor (assuming they have a YARM and their cursor is empty).

Yes, I hadn't considered it, but that's a fair point.
On that note, an "add site" button could do the same just for general adding. And then, you know, we could just remove the recipe for the resource monitor item and just spawn one when the player needs it (and discard it thereafter). And I've just talked myself into a largish UX change that I'm going to go ahead and shove into a different issue.

So, the only open issue is making the highlighting not-blocking

I've been playing around with various ways of handling this - and while I could make scan_current_site generic enough to handle either adding a new site or re-overlaying an existing site, I worry it's going to make the code a bit obscure - would have to make parameters for both the action taken (in the current instance, that's add_single_entity) and potentially the list of things to do.
Question: What should happen if we have a highlight running in the background, and the player tries to extend the site?
Secondly, what happens if we have a site that takes longer than 10 seconds to highlight? Should we not start the timer until the highlight is finished?

I worry it's going to make the code a bit obscure

Yeah, I can see that; don't worry about it. Just reuse whatever makes sense to, if anything.

What should happen if we have a highlight running in the background, and the player tries to extend the site?

Either it goes into the queue and will get processed as soon as the highlighting is done, or (if at all possible), it gets done in parallel. Depending on how the highlight works, working in parallel may or may not be doable. If so, that affects the below.

Secondly, what happens if we have a site that takes longer than 10 seconds to highlight? Should we not start the timer until the highlight is finished?

Think you answered your own question there -- wait for the highlight to finish before running the timer. If it's possible to run highlight and discovery in parallel, as above, then the timer really shouldn't start until after both are done (currently it's keyed to discovery only).

OK, took a stab at it. It's probably fairly buggy, but works fine on my machine. :innocent:
Relevant notes:

Re-adding an overlay to an existing site should run in parallel with any expansions you click.
The timer doesn't start until the site is fully highlighted.
Haven't tested what happens if you don't have a YARM in your inventory when you click the + button
I did, accidentally, find out that you can robot-place (by shift-click) a YARM and it will actually be constructed as an entity. Fairly sure I didn't introduce that behaviour, though.

OK, took a stab at it.

Yes! That's excellent; I have to try it out in as evil a circumstance as I can manage, but if it works, we've got us a (potential) winner.

I did, accidentally, find out that you can robot-place (by shift-click) a YARM and it will actually be constructed as an entity. Fairly sure I didn't introduce that behaviour, though.

I'm quite certain you're right; I'll try to do it on a clean copy of YARM and write it up as a separate issue. Surprised nobody reported it before -- you'd think at least 10 people would've been holding shift at the wrong moment (so at least one would've reported it).

Now I get to play with it, hooray! Dis gon b gud.
First order of business: tell the player they can't add to a site when they don't have a resource monitor at all. Likewise, tell them if something goes wrong with putting the resource monitor in their hand. In both cases, avoid starting the add-to-site process.
Secondly, the right thing happens when I try to add an already-added (but not yet highlighted) ore to the same site. However, I'm getting reports that Site "SW 32" updated, now has 2,046,979 Iron ore (+-48). (the obvious reason being that the miners working it reduced it by 48 while the addition process was ongoing). I'm okay with getting the report, but I'm not okay with the "+-".
Interesting behaviour: if you delete a site while the adding process is ongoing, the site will be recreated when the addition finalizes. In this case, there will be no feedback to the player that anything happened (other than the site showing up again in their YARM).
Otherwise, this is damn near perfect -- making this 12 million ore deposit has never been easier:

First order of business: tell the player they can't add to a site when they don't have a resource monitor at all. Likewise, tell them if something goes wrong with putting the resource monitor in their hand. In both cases, avoid starting the add-to-site process.

Can do. Will need to rearrange various bits of code, though. (I spent like four hours getting the background overlay regeneration working, and about 5 minutes doing the YARM-to-cursor bit, so one of them is likely a bit more polished than the other)

Secondly, the right thing happens when I try to add an already-added (but not yet highlighted) ore to the same site. However, I'm getting reports that Site "SW 32" updated, now has 2,046,979 Iron ore (+-48). (the obvious reason being that the miners working it reduced it by 48 while the addition process was ongoing). I'm okay with getting the report, but I'm not okay with the "+-".

I'll probably change the logic here so that the site is only listed as having expanded when an ore entity is actually added to the site (currently a site is listed as having expanded as soon as you smack the YARM on a resource). I'll also check the amount_added and only put a '+' in front if it's actually positive.

Interesting behaviour: if you delete a site while the adding process is ongoing, the site will be recreated when the addition finalizes. In this case, there will be no feedback to the player that anything happened (other than the site showing up again in their YARM).

Also fixable, although as I think about it more it may be slightly more complicated than I thought. Essentially, we need to clear player_data.current_site if it's the same site as we're currently deleting. (Don't want to always clear current_site, because we could be deleting a different site to the one we're currently expanding...)

four hours getting the background overlay regeneration working, and about 5 minutes doing the YARM-to-cursor bit

That sounds about right; one of these is much trickier than the other.

only listed as having expanded when an ore entity is actually added to the site

I don't know, I'm pretty okay with YARM telling me the difference from the old total (and resetting the 100% point can be a desirable feature). Just doing the '+' in back-end code rather than locale should be enough.

delete a site while the adding process is ongoing

Also fixable, although as I think about it more it may be slightly more complicated than I thought.

I'm not terribly concerned about it, so you could also just ignore it altogether. It's well within the realm of acceptable behaviour.

it'll be a couple days

Not a problem, I've only really poked at this while at work in the first place -- it'll keep another few days.

Hey, that's cool! My CI integration actually detected something! I'm sure you weren't intending to test that, but it's the first time I've gotten feedback from it that it does work :+1:

Hey, that's cool! My CI integration actually detected something! I'm sure you weren't intending to test that, but it's the first time I've gotten feedback from it that it does work :+1:

As the following commit implies, I should probably test locally before pushing. :unamused:
Er I mean yes I totally intended to test your CI pipeline and it passed! :confetti_ball:
On a related note - do you want me to squash some of these commits together, or are you not worried about a bunch of fixup commits in your history?
Anyway, I've fixed the display issue (around '+-48') and improved the messaging around the pull-YARM-to-hand functionality. I think I'm going to leave "only listing a site as expanded when a new ore is added to it" and "properly delete a site if you delete it while the expansion timer is going" as won't-fix (for now at least), can always revisit them later.

do you want me to squash some of these commits together, or are you not worried about a bunch of fixup commits in your history?

I honestly don't mind them at all; if you really want to, you can prettify, but it's purely up to your comfort level.

leave "only listing a site as expanded when a new entity is added to it" and "properly delete a site if you delete it while the expansion timer is going" as won't-fix (for now at least), can always revisit them later.

Agreed, and many thank-yous!
I'm going to get this merged in after I give it a new test (and a style/lint/nitpicking pass around the code). You've done tremendously fine work here, thanks.

Sorry for the delay; as you've noticed, this is now merged. I hope you'll have time for more contributions in future, and thanks again.


Use  command mappings

Command mappings simplify everything except obtaining the start and end
of the visual area.  Previously '< and '> gave the start and end such that
the start preceded the end.  Now we have to determine which end is which
ourselves.

The added complexity isn't worth it.


Permissions for creating work items?

This page talks a lot about "the ability to view, modify, or edit work items" but nowhere does it mention creating work items. I'm  confused by this! I guess this is configured differently, but a link to another page giving more info would have been helpful.

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

ID: 022fb627-3fc3-e748-8431-a4597bb27ad5
Version Independent ID: 0b56992a-b121-6095-5a60-65548fdd5a3b
Content: Set permissions and access for work tracking - Azure DevOps
Content Source: docs/organizations/security/set-permissions-access-work-tracking.md
Product: devops
Technology: devops-security
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

@dancoupar - Thank you for the feedback.  Most permissions that support editing or modifying work items apply to creating them. However, to avoid further confusion, I'll update the content to be more explicit. There are some places where users don't have full permissions to create a work item based on the page they are on and the access they've been granted.


Update the Spanish translation file

Update the Spanish translation file with:

Fixed some typos in Spanish.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@alexeybannov @LinneyS @pavelbannov can you check this pull request? if all is ok merge it, thanks.

@macagua
Thank you very much for the translation


How to check for active state in another orthogonal region

Hi, is there currently any way to check for the current active state in another orthogonal region from within a guard? As there is no way any more to gain access to the statemachine in guards/actions I struggle to get that working.
I'd love to have anything like is_in as in the following example:
struct transitions
{
    auto operator()() const noexcept
    {
        using namespace sml;
        return make_transition_table(
            * "s1"_s + event<e1>                   = X,
            * "s2"_s + event<e2> [ is_in("s1"_s) ] = X);
    }
};

Is anything like that already available or is there another (better?) way to do something similar?
BTW: Awesome stuff, Kris!!!

There is an example isin implementation in #185 but that doesn't compile for me.

Here is a short modification of the example which is in #185 which works for states in the same state machine:
#include "sml.hpp"
#include <cassert>

namespace boost {
namespace sml {
namespace front {
namespace actions{
struct isin{
  template <class TState>
  class isin_impl : public front::action_base {
   public:
    explicit isin_impl(const TState &state) : state(state) {}
    template <class T, class TSM, class TDeps, class TSubs>
    bool operator()(const T &, TSM &sm, TDeps &, TSubs & subs) {
        using state_t = typename TSM::state_t;
        using states_ids_t = typename TSM::states_ids_t;
        return aux::get_id<state_t, typename TState::type>((states_ids_t *)0) == aux::cget<TSM>(subs).current_state_[0];
    }

   private:
    TState state;
  };
  template <class TState>
  auto operator()(const TState &state) {
    return isin_impl<TState>{state};
  }
};
} // namespace actions
} // namespace front
static front::actions::isin isin;
} // namespace sml
} //namespace boost

using namespace boost;

struct e1 {};
struct e2 {};

struct transitions
{
    auto operator()() const noexcept
    {
        using namespace sml;
        return make_transition_table(
            * "s1"_s + event<e1> = X,
            * "s2"_s + event<e2> [isin("s1"_s)] = X);
    }
};

int main() {
    using namespace sml;

    sm<transitions> sm{};
    assert(sm.is("s1"_s, "s2"_s));

    sm.process_event(e2{});
    assert(sm.is("s1"_s, X));
}

You can probably merge the two solutions together somehow to get a single isin that works for same level, as well as different level, state machines.


API availability and mappings

Is there a reason some API methods are only available when some mappings are enabled? I guess many people (myself included) will use the API to define their own custom key mappings. It would be nice if one could disable all mappings and yet be able to use all API methods.

Are you talking about these functions https://github.com/numToStr/Comment.nvim/blob/master/doc/API.md? Or do you want something else?

Yeah, sorry for explaining it poorly.
I noticed I had to set mappings = {extras = true} in order to use require'Comment.api'.gcO(), but that ended up creating gcO as a mapping. It would be nice if I could set mappings = {} and yet be able to use all API methods.

Ahh, I get it now. To be honest I did that on purpose as gc{o,O,A} can be easily re-created as you can see in the following example
local E = require('Comment.extra')
local U = require('Comment.utils')
local A = require('Comment.api')

local cfg = A.get_config() or {}

E.norm_o(U.ctype.line, cfg) -- gco
E.norm_o(U.ctype.block, cfg) -- (Bonus) gbo

E.norm_O(U.ctype.line, cfg) -- gcO
E.norm_O(U.ctype.block, cfg) -- (Bonus) gbO

E.norm_A(U.ctype.line, cfg) -- gcA
E.norm_A(U.ctype.block, cfg) -- (Bonus) gbA

(Only thing is that these modules aren't documented yet. But It's WIP 😃)

Oh, I thought the goal of the newly released API was precisely to eliminate the need of such code.
Do you think it would be bad design if the whole API was fully available at all times?

Seconded -- with Lua plugins, the API should be the primary export, with mappings only (optional) sugar on top.

I am also figuring that out my myself how to export the functions nicely. I mean they are kinda exported via require('Comment.{api,opfunc,extra}') and you can even use them to make your custom commenting function. IMO the only thing that is missing is proper :help docs.

(Here the basic mappings are so ubiquitous for the purpose that setting them by default is OK in my eyes.)

Yeah, this was also my first observation as the community was already familiar with vim-commentary :)

IMO the only thing that is missing is proper :help docs.

Agreed; although I would prefer toggle_line(vmode,cfg) for gcc (with toggle_line() using the right defaults to get the current toggle() behavior` -- have the name describe what it does, not the "usual mapping" (which people coming fresh to comment.nvim would not know).

@numToStr  IMO you did an awesome job at creating/exporting an API so people can better use your plugin. The only thing that was unexpected for me was the need to enable extra key mappings in order for the API to be available to use. At best those key mappings will simply be ignored (my case); at worst they may clash with other mappings that might have been already set by the user.

@clason @mbenford Thanks for bringing this up. I'll rethink the API situation a bit more and let you know. Meanwhile, If you have any suggestions please let me know :)

Care to try #94 ;)
(I'll later update the docs for the APIs)

@numToStr Thanks for the update. I think the new API methods are much more user-friendly!
I managed to setup my keymaps as follows:
require'Comment'.setup{
	mappings = {}, -- no need to enable anything. Yay!
	ignore = '^$',
}

local map = require'map'
map.n{'<leader>cc', '<cmd>lua require"Comment.api".toggleln_linewise_op()<cr>'}
map.n{'<leader>cb', '<cmd>lua require"Comment.api".toggleln_blockwise_op()<cr>'}
map.n{'<leader>c', '<cmd>lua require"Comment.api".call("toggle_linewise_op")<cr>g@'}
map.v{'<leader>cc', '<esc><cmd>lua require"Comment.api".toggle_linewise_op(vim.fn.visualmode())<cr>'}
map.v{'<leader>cb', '<esc><cmd>lua require"Comment.api".toggle_blockwise_op(vim.fn.visualmode())<cr>'}
map.n{'<leader>co', '<cmd>lua require"Comment.api".insert_linewise_above()<cr>'}
map.n{'<leader>ca', '<cmd>lua require"Comment.api".insert_linewise_eol()<cr>'}

It works like a charm. However, I had to peek into api.lua in order to understand how the plugin itself was calling some methods, and I found that some extra configuration is needed. For instance, .call must be used for operator-pending mode to work, which seems to be a private function, and <esc> must called for visual mode. I think it would be best if these details were abstracted away and a simple API call would work out of the box. In other words, the plugin itself should use the API the same way a user would. If that's not possible, then I guess the docs should explain how to replicate the builtin mappings using the API methods.

For instance, .call must be used for operator-pending mode to work, which seems to be a private function

I guess, I could export that as a shorthand for setting operatorfunc :)

and <esc> must called for visual mode.

I can't do much about it. You'll still need to know a little about how VISUAL mode works. Also, we can mention this in docs :)

I think it would be best if these details were abstracted away and a simple API call would work out of the box. In other words, the plugin itself should use the API the same way a user would. If that's not possible, then I guess the docs should explain how to replicate the builtin mappings using the API methods.

Abstracting everything away is not always practical, for example [count]gcc mapping but we can mention how to achieve something in detail in the wiki and docs which I'll tackle next :)
And lastly thanks for trying out the new APIs as soon as I finish the docs I'll merge it.

I can't do much about it. You'll still need to know a little about how VISUAL mode works. Also, we can mention this in docs :)

My mappings with Kommentay were like this:
local map = require'map'
map.n{'<leader>c', '<Plug>kommentary_line_default', noremap = false}
map.x{'<leader>c', '<Plug>kommentary_visual_default<C-c>', noremap = false}

I don't know what it's going on under the hood. I wonder if it's something that could be applied here as well?

local map = require'map'
map.n{'<leader>c', '<Plug>kommentary_line_default', noremap = false}
map.x{'<leader>c', '<Plug>kommentary_visual_default<C-c>', noremap = false}

Ohh, I forgot about the plug mappings. To be honest I've never used them and I also don't know whether I want to expose them or not.

@mbenford I'll give <Plug> mappings a try #96. But regarding APIs, I think they are in good shape and I would like to merge them. So, If you have any suggestions please let me know :)

But regarding APIs, I think they are in good shape and I would like to merge them. So, If you have any suggestions please let me know :)

I'm happy with the API as it is now. Maybe @clason could weigh in as well?

I'll give  mappings a try #96.

I personally don't care much about  mappings and I'm fond of using a Lua API whenever possible. I  mentioned Kommentary because its "API" works in Visual Mode without having to use <esc> explicitly, and I thought that whatever it does to achieve that could be applied here.


[Feature Request] Add options support to insert and delete methods of Query Builder

Is your feature request related to a problem?
No, is related to a need.
My need is to be able to use writeConcern option to allow async write operations.
Describe the solution you'd like
I'd like to pass options parameter to insert and delete methods, as it already happens for update method.
Additional context
I've already created a PR #2029

@danielerota can you show example for this async write operation?

I need to log API operation, so the code can't stop if log insert (into mongodb) fail.
An example call here:
$collection = app('db')->connection('mongodb')->collection('characters');
try {
     $collection->insert(array("_id"=>"unique21"), array("writeConcern" => new WriteConcern(0)));
}catch (\Exception $e) {        }

This specific usage is useful in case you are not interested about the status of the operation (e.g. for logging). In this way you don't have to wait for the acknowledge from MongoDB and the script can continue the execution, saving time.
However, the options array can contain other useful MongoDB options. Currently, only update method handles the $options parameter, so I think id would be right that also insert and delete support it.

I need this feature addition as well 👍

I need this feature addition as well

+1

+1

+1

+1

+1

+1

+1


Training iteration time is too long

Hi!
I want to train my own gray-scale video dataset with this model. I just modified the number of in channels and out channels, and used my own dataloader, but I found it's pretty slow in each iteration. I used the official code to train and enabled AMP during training with 6 frames as input.
It would cost about 8 seconds per iter with batch size 4 on single Tesla V100, which is a thousand times more than the time given in the paper.
Here is a part of logs:
...
2024-05-08 16:38:01,914 INFO: [IART_..][epoch: 39, iter:   4,075, lr:(1.999e-04,2.499e-05,)] [eta: 30 days, 19:36:29, time (data): 8.109 (0.003)] l_pix: 2.5940e-02
2024-05-08 16:38:09,855 INFO: [IART_..][epoch: 39, iter:   4,076, lr:(1.999e-04,2.499e-05,)] [eta: 30 days, 19:35:04, time (data): 8.106 (0.003)] l_pix: 2.6145e-02

I also trained on single RTX 4070Ti with batch size 1. I found that the forward function took about 65 ms but the backward function took about 1800 ms, which seems to be abnormal and also doesn't match the time given in the paper.
I wonder if there are any details I haven't noticed that are causing these problems, thanks!

Hi
For 6 frames input, you can disable all gradient checkpointing by set https://github.com/kai422/IART/blob/4c8ae5968f4625af5b0eb43827fa962b022904b0/archs/iart_arch.py#L31C35-L31C60:
to   use_checkpoint = [False, False, False, False],.
You can also adjust it according to your GPU memory size.
Thanks for pointing out of this!
Regards,
Kai

@kai422 Hi, kai. Could you explain the function of the parameter use_checkpoint? Why for 6 frames input, can we set use_checkpoint = [False, False, False, False]?

Hi,
If we change use_checkpoint = [False, False, False, False], it will not affect to the performance of the model, Am i right?
And in the paper, do u also use this setting?
Thanks

Hi, the option for using gradient checkpointing will not affect gradient computation, it only trade-off computation for memroy saving.  (https://pytorch.org/docs/stable/checkpoint.html)
Regards,
Kai

I see, thanks for quick reply


[TPC-H] Generate expected results for SF > 1

At SF==1, our TPC-H queries boil down to "overcomplicated pandas" since we don't really partition anything. At larger scale factors, several different size-based optimizations kick in and significantly alter the query plans. As a result, results may be correct at SF==1, but may be wrong at SF>1 (see https://github.com/dask-contrib/dask-expr/pull/917#issuecomment-1983112150).
We should generate the expected results at larger scale factors to be able to run the correctness tests at larger scale.

Yes having results for scale > 1 makes sense
I am cautiously optimistic that the result in the linked PR is correct though, Polars also ends up with an empty result

Polars also ends up with an empty result

That really doesn't make me feel any better about our input data :D I'll investigate this a bit more.


Don't dismiss the Reimbursement Account Page after validating a withdrawal account

@luacmartins please review
Details
Make sure we don't close the Reimbursement Account Page after validating a withdrawal account, regardless if you have the Expensify Card or not.
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/180851
Tests

Create workspace
Go to connect bank account page
Select Connect bank account and use steps in option (1) of this SO
Enter validation amounts to finalize setup
Make sure that the right docked modal stays open after you finish the setup.

🚀 Cherry-picked to staging by @luacmartins in version: 1.1.7-10 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by @roryabraham in version: 1.1.8-9 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Enhancement/support duckdb relation

Continues from #22. So review that one first.
Addresses #10 by adding kernel_computation=True support for duckdb.duckdb.DuckDBPyRelation objects supported by narwhals.

I first tried to see if I could use the existing pygwalker database Connector class. But this needs a connectionstring and I simply could not figure out how to get it if I only have access to the relation because the connection is created by the user outside of "my control". I've asked for help in https://github.com/duckdb/duckdb/discussions/14768.
The current approach tries to implement a custom Connector class. The key point is to be able to execute subqueries on existing relations. It can actually be done in them most simple case but not more advanced cases (see added tests). I've asked for help in https://github.com/duckdb/duckdb/discussions/14772.
An alternative approach would be to see if I could use the BaseDataFrameParser. But as far as I can see I will run into the same problems as I have now.

Found the .query argument which solves the issue.


Using GPU version of mxnet

As I could not use torch on GPU (https://github.com/MouseLand/cellpose/issues/211) I wanted to test mxnet with GPU but I got this message:
(cellpose) saskra@a:~/PycharmProjects/cellpose$ python -m cellpose --train --dir /downsized/mixed/ --chan 0 --train_size --use_gpu --img_filter _img --mxnet
MXNET CUDA version not installed/working.
>>>> using CPU

After installing mxnet_cu102 I got this error:
(cellpose) saskra@a:~/PycharmProjects/cellpose$ python -m cellpose --train --dir /downsized/mixed/ --chan 0 --train_size --use_gpu --img_filter _img --mxnet
Traceback (most recent call last):
  File "/home/saskra/PycharmProjects/cellpose/cellpose/core.py", line 61, in _use_gpu_mxnet
    _ = mx.ndarray.array([1, 2, 3], ctx=mx.gpu(gpu_number))
NameError: name 'mx' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/saskra/anaconda3/envs/cellpose/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/saskra/anaconda3/envs/cellpose/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/saskra/PycharmProjects/cellpose/cellpose/__main__.py", line 264, in <module>
    main()
  File "/home/saskra/PycharmProjects/cellpose/cellpose/__main__.py", line 118, in main
    device, gpu = models.assign_device((not args.mxnet), args.use_gpu)
  File "/home/saskra/PycharmProjects/cellpose/cellpose/core.py", line 79, in assign_device
    if gpu and use_gpu(istorch=istorch):
  File "/home/saskra/PycharmProjects/cellpose/cellpose/core.py", line 57, in use_gpu
    return _use_gpu_mxnet(gpu_number)
  File "/home/saskra/PycharmProjects/cellpose/cellpose/core.py", line 64, in _use_gpu_mxnet
    except mx.MXNetError:
NameError: name 'mx' is not defined

When forcing "import mxnet as mx" I get this error, although cudnn is installed:
(cellpose-gpu) saskra@a:~/PycharmProjects/cellpose$ python -m cellpose --train --dir /downsized/mixed/ --chan 0 --train_size --use_gpu --img_filter _img --mxnet --pretrained_model cyto
Traceback (most recent call last):
  File "/home/saskra/anaconda3/envs/cellpose-gpu/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/saskra/anaconda3/envs/cellpose-gpu/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/saskra/PycharmProjects/cellpose/cellpose/__main__.py", line 9, in <module>
    from cellpose import utils, models, io
  File "/home/saskra/PycharmProjects/cellpose/cellpose/models.py", line 10, in <module>
    from . import transforms, dynamics, utils, plot, metrics, core
  File "/home/saskra/PycharmProjects/cellpose/cellpose/core.py", line 13, in <module>
    from mxnet import gluon, nd
  File "/home/saskra/anaconda3/envs/cellpose-gpu/lib/python3.7/site-packages/mxnet/__init__.py", line 23, in <module>
    from .context import Context, current_context, cpu, gpu, cpu_pinned
  File "/home/saskra/anaconda3/envs/cellpose-gpu/lib/python3.7/site-packages/mxnet/context.py", line 23, in <module>
    from .base import classproperty, with_metaclass, _MXClassPropertyMetaClass
  File "/home/saskra/anaconda3/envs/cellpose-gpu/lib/python3.7/site-packages/mxnet/base.py", line 351, in <module>
    _LIB = _load_lib()
  File "/home/saskra/anaconda3/envs/cellpose-gpu/lib/python3.7/site-packages/mxnet/base.py", line 342, in _load_lib
    lib = ctypes.CDLL(lib_path[0], ctypes.RTLD_LOCAL)
  File "/home/saskra/anaconda3/envs/cellpose-gpu/lib/python3.7/ctypes/__init__.py", line 364, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: libcudnn.so.8: cannot open shared object file: No such file or directory

Any help would be appreciated! :-)

Sorry to see you're having problems. My best guess is that you don't have the right CUDA dependencies installed (also related to your posts in #211). I had to reinstall ubuntu on my machine at least twice to get it right... 10.2 is what I ended up using. Apparently drivers are backwards-compatible, but you want to stay about a year behind the latest CUDA release.

I have installed CUDA 10.2 in this environment via conda. Unfortunately, I cannot change the OS or graphics cards driver as too many other projects are depending on them. The only chance might be something like a Docker container. But even then I needed to know the exact configuration.

Hmm there may be settings you need to change in your bashrc? Do you have the CUDA libraries added to your PATH and LD_LIBRARY_PATH?

I always install CUDA only via Conda, because I need different versions in different projects. So the bashrc, PATH etc. should not play a role in my opinion.

There are two backends for cellpose: mxnet and torch. the default is torch, maybe it's recognizing it for torch?
have you tried also installing cudnn with conda? I don't have much advice here, I've always installed cuda outside conda when working with mxnet

Yes, maybe it is only recognised for torch, but that would also be strange. I have installed Cudnn via conda. However, I will test the training using torch again with the latest source code version here from the repository as soon as I have the resources free. If that works, I wouldn't need mxnet at all.

I don't think it would be so strange, torch may be detecting the cudatoolkit and setting the paths correctly. You could also try the advice here for mxnet: https://github.com/MouseLand/cellpose/issues/56
I'm going to close this issue for now


fixed the translation

Documentation

[x] My pull request requires an update on the documentation repository.

@Sanjaybhattwebkul please verify this and merge

@heysagnik
Thanks for your contribution


Add support for IsPassive="true"

The current implementation of IsPassive consists of passing this value thru to the home IdP (similar to ForceAuthn).
From os-core section 3.4.1: "If [IsPassive is] 'true', the identity provider and the user agent itself MUST NOT visibly take control of the user interface from the requester and interact with the presenter in a noticeable fashion"
The implementation if IsPassive in OpenConext is not complete:

OpenConext can show a WAYF if the user has no session, this should not happen. Instead;
when passive is not possible OpenConext should respond with a SAML Status, since we cannot show an error to a user:
samlp:Status
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoPassive" />
/samlp:StatusCode
/samlp:Status

Also in case of other errors we should pass a status code to the IdP.
Because OpenConext passes IsPassive to the home IdP (as it should), OpenConext should expect and be able to handle a status code from the IdP.

I researched this issue and these are the conclusions:
When receiving an IsPassive authnrequest, EB:

sends a correct NoPassive response when >1 IdP is connected to this SP;
sends a correct IsPassive authnrequest when 1 IdP is connected to this SP;
processes an assertion correctly when this IdP decides to return one;
throws an exception and shows the error screen "Identity Provider error" when the IdP returns a NoPassive response.

Only the last bullet is incorrect behaviour. The correct behaviour is that if EB receives a NoPassive from the IdP, it should similarly send out a NoPassive message to the SP.


fix loose metadata when retrieve from Chroma

metadata was lost if no line-of-code keys present

Thank you, good catch!

also i want to ask how can i get document id from vecstore or retriever? maybe we need to pass id in metadata for each document or better generate and pass it to metadata in client code?

Yeah I think at the moment your best bet is to pass it in as metadata.

@jacoblee93 Pass in metadata from client code or extend langchain implementation and add ids to metadata when return docs?


Cleanup PropertyFactory API

Clean up the PropertyFactory and Property APIs to decouple them completely from the Config API so they can be backed by other configuration mechanisms.

archaius-pull-requests #336 SUCCESS
This pull request looks good

NetflixOSS » archaius » archaius-pull-requests #170 SUCCESS
This pull request looks good

LGTM

archaius-pull-requests #339 FAILURE
Looks like there's a problem with this pull request

NetflixOSS » archaius » archaius-pull-requests #173 FAILURE
Looks like there's a problem with this pull request

archaius-pull-requests #340 SUCCESS
This pull request looks good

NetflixOSS » archaius » archaius-pull-requests #174 SUCCESS
This pull request looks good

NetflixOSS » archaius » archaius-pull-requests #203 FAILURE
Looks like there's a problem with this pull request


Default simulator architecture now x86_64 instead of standard i386

Hi,
I've tried running an iOS app I'm developing with bazel run and it now breaks as some libraries I depend don't have x86_64 in their universal compilation (because armv7, arm64, and i386 are the standards), so it breaks.
Is there a special reason it was swapped? Is there an easy way to swap it back to default to i386?
Thanks
Indigo

We indeed changed the default for this here recently as it more closely reflected the desired default for several users.
You can always change defaults for your builds by changing your ~/.bazelrc.
For instance, append this to the end of your ~/.bazelrc to build with i386 by default:
build --ios_cpu=i386


Http client update

Just some minor API changes.  Confirmed that building my project from scratch still works.  Helps keep the nix build working to have things as current as possible.  :)

The Travis-CI build failed like this:
0.17s$ rake
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)

... but I'm not sure why it's even trying to execute rake on a Haskell project ... ?

Thank you for the suggestion! It looks like it is already bumped in the dev build: https://github.com/elm-lang/elm-compiler/blob/master/elm.cabal#L242
So the next release will have the latest version of this. (The architecture of things changed a lot, so it is hard to predict where to check for things like this right now. Should be cleared up after the release though. Sorry for the trouble in the meantime!)

No big deal, thanks for the quick response! :)


standalone_pvr.report under signoff/<design>/

Add a standalone PVR report for each block, this includes:

LVS
DRC
CVC
Antenna

This can be done using the automation script.

LVS, DRC, and STA of all re-implemented blocks and top-level caravel are added to ./signoff/<design_name>/signoff.rpt using Caravel signoff automation script
CVC is performed using Mitch's custom script and it runs on the caravel top-level
Magic antenna checks never finished (killed after 48 hours); Calibre antenna checks require runset development.

fixed in b6288a75d70831da3602a3fd94d8826656ef2e91


capibility missing to adjust temperature for thermostat

Describe Your Problem:

The Wi-Fi heater that is connected to SmartThings operates normaly when using the ST app. However, when I integrate it with HomeKit using the homebridge smartthings plugin, I encounter an issue where I am unable to adjust the temperature. It appears that only the on/off switch, temperature sensor, and contact sensors are added.
Upon reviewing the logs, it appears that the SmartThings plugin only created a switch, a temperature measurement, and a contact sensor. However, it is unclear why no accessory was created for the thermostatHeatingSetpoint, likely which I needed for adjusting temperature.
(screenshots) All four capabilities are displayed correctly in the SmartThings app. However, only three capabilities are visible in the Homebridge UI.
Logs:
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] DEVICE DATA: {"deviceId":"*****","name":"난방조절기 HCM-300(8)","label":"안방난방","manufacturerName":"SmartThingsCommunity","presentationId":"*****","deviceManufacturerCode":"SiHAS","locationId":"*****","ownerId":"*****","roomId":"*****","components":[{"id":"main","label":"main","capabilities":[{"id":"healthCheck","version":1},{"id":"refresh","version":1},{"id":"switch","version":1},{"id":"thermostatHeatingSetpoint","version":1},{"id":"temperatureMeasurement","version":1},{"id":"contactSensor","version":1}],"categories":[{"name":"Thermostat","categoryType":"manufacturer"}]}],"createTime":"2023-10-13T07:03:16.107Z","profile":{"id":"*****"},"viper":{"manufacturerName":"SiHAS","modelName":"HCM","endpointAppId":"*****"},"type":"VIPER","restrictionTier":0,"allowed":[]}
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Restoring existing accessory from cache: 안방난방
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Creating instance of SwitchService for capabilities switch
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Adding SwitchService to 안방난방
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Registered SwitchService for capabilities switch
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Creating instance of TemperatureService for capabilities temperatureMeasurement
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Adding TemperatureService to 안방난방
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Registered TemperatureService for capabilities temperatureMeasurement
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Creating instance of ContactSensorService for capabilities contactSensor
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Adding ContactService to 안방난방
[10/25/2023, 8:36:35 AM] [Smartthings Plug (IK)] Registered ContactSensorService for capabilities contactSensor

Plugin Config:
Unedited default config.

Screenshots:

Environment:

Plugin Version: 1.5.20
Homebridge Version:  1.6.1
Node.js Version:  18.16.0
NPM Version:
Operating System:  Debian Bullseye

I believe that issue #197 might be of the same type as this problem.

Thanks for the log.  I will take a look in the next week or two and see if I can fix this.

I have the exact same issue


Add in-browser version control for files and folders of a project (git)

One option to achieve version control for a projects files and folders is to use git inside of the browser.
There seems to be some prior work but they all have problems and don't work out of the box.

(most promising) creationix/js-git has a variety of tiny modules that make it up and work with it
whylee/nogit
SamyPesse/gitkit-js
git-html5.js
alternative dat
alternative hyperdrive (here is a little introduction to the project)

Next Steps:
To make some little spike and try to see what features are supported and how they work in the browser and what's left missing. Then decide with which project to go and maybe also get in touch with the authors to implement missing features and make it all work

Categories for git related libraries on npm

git init
gitSSH
git-fetch-pack (protocol)
git-apply-delta
git-create-delta
git side-band-messages
git packfile
git pull/clone/fetch
github url
git remote
git push
git objects (blob)
git tree
git history/walker
git add/commit
git stage/index (add)
git rev
git repo (abstract)
git repo
git odb (object database)
git fs (git browser storage, github api)
git log
git sha1 / secure tag
git zlib
git refs tags/branch/head/...
git status
git cherry pick
git checkout
git config (git ignore)
git working copy
git diff
git conflict (merge/rebase)
git stash

Each of those categories contains around a dozen libraries that are related to the category name.
Currently I'm trying to put together a minimal version that works in the context of remix re-using libraries where possible and writing some glue code where existing stuff doesnt work. The version won't support all possible git features but just some essentials and more git related features can be added over time.
It also opens the question how to present certain git features in the UI.

Github requests limitation (API)

`60 requests per hour for anonymous requests https://developer.github.com/v3/#rate-limiting
5000 requests per hour for authenticated requests https://developer.github.com/v3/#schema

I was talking with creationix, the author of js-git. Since the initial implementation some time has passed.
Not everything is up to date. From what has been implemented, it's possible to use js-git in the browser.

it will use a "virtual file system" (which cannot be backed by localStorage but needs indexDB)
it can't push/pull to git servers

Github, Bitbucket & others
Github and other "git cloud services" don't have CORS set in a way that would allow push/pull/clone of git directories. Instead, they offer a proprietary REST API that can be used and would need adapters to be implemented. What has been done instead is a js-github module, that can be mounted as a "virtual file system" in the browser, so working on files would directly work on the github repository instead of locally in the browser.

Current Status

I currently have a little test project in which I'm using js-git in the browser.
I'm using an indexDB backed virtual file system.
I'm running a localhost git server

The idea:

make it possible to push/pull/clone from/to that localhost git server
once it works - write an adapter that uses the same interface but behind the scenes uses the github api

An alternative - which would require users to install remixd and git would be to don't use git at all, but instead we add some REST endpoints for common commands like git commit, git pull, git push, git add, ... basically remote controlling the command line git from the browser

Flow:

connect Github account (copy-paste token OR login with Github (mini handshake server))

not anonymous -> 5000 API calls/h

buttons in Browser solidity editor:

git init and git clone
git comit -am + message
git log --oneline -5 -> go to commit/git checkout
git push --force
git delete (diconnects locally)

index DB

@yann300  can I close this?


Fixing boolean[] indexing failure during ingestion

Pinot DataType missed the toInternal() implementation for BOOLEAN_ARRAY and TIMESTAMP_ARRAY.

Codecov Report
Attention: Patch coverage is 0% with 14 lines in your changes missing coverage. Please review.

Project coverage is 0.00%. Comparing base (59551e4) to head (dc0e3a4).
Report is 771 commits behind head on master.

Files
Patch %
Lines

...ment/creator/impl/SegmentColumnarIndexCreator.java
0.00%
8 Missing :warning:

...or/impl/stats/IntColumnPreIndexStatsCollector.java
0.00%
6 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (59551e4) and HEAD (dc0e3a4). Click for more details.
HEAD has 53 uploads less than BASE

Flag
BASE (59551e4)
HEAD (dc0e3a4)

integration
7
1

integration2
3
1

temurin
12
1

java-21
7
1

skip-bytebuffers-true
3
0

skip-bytebuffers-false
7
1

unittests
5
0

unittests1
2
0

java-11
5
0

unittests2
3
0

integration1
2
0

custom-integration1
2
0

Additional details and impacted files
@@              Coverage Diff              @@
##             master   #13630       +/-   ##
=============================================
- Coverage     61.75%    0.00%   -61.76%
=============================================
  Files          2436     2480       +44
  Lines        133233   137052     +3819
  Branches      20636    21311      +675
=============================================
- Hits          82274        0    -82274
- Misses        44911   137052    +92141
+ Partials       6048        0     -6048

Flag
Coverage Δ

custom-integration1
?

integration
0.00% <0.00%> (-0.01%)
:arrow_down:

integration1
?

integration2
0.00% <0.00%> (ø)

java-11
?

java-21
0.00% <0.00%> (-61.63%)
:arrow_down:

skip-bytebuffers-false
0.00% <0.00%> (-61.75%)
:arrow_down:

skip-bytebuffers-true
?

temurin
0.00% <0.00%> (-61.76%)
:arrow_down:

unittests
?

unittests1
?

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

boolean[] should not flow into the segment creation engine. Its value should already be replaced with internal storage format within DataTypeTransformer

good point!  I actually saw boolean[] comes from the this Transformer....

boolean[] should not flow into the segment creation engine. Its value should already be replaced with internal storage format within DataTypeTransformer

Seems that the issue is type conversion of toInternal() for BOOLEAN_ARRAY and TIMESTAMP_ARRAY are missed.


Java Object transformation to list

Is Java object transformation to list possible??
From the documentation here https://www.datafaker.net/documentation/schemas/#java-object-transformation it seems only singleton is posssible unless i missed something.
Please advise. Here is my iomplementation:
Faker faker = new Faker();

Schema<Object, ?> schema = Schema.of(
                Field.field("name", () -> faker.name().firstName()),
                Field.field("email", () -> faker.internet().emailAddress())
        );

BaseFaker bfaker = new BaseFaker();
Client client = bfaker.populate(Client.class, schema); //Here i would like to have a collection of fake Clients instead

you could use FakeCollection or FakeSequence https://www.datafaker.net/documentation/sequences/
to do it like
List<DefaultPerson> list = new FakeCollection.Builder<DefaultPerson>()
            .suppliers(() -> Faker.populate(DefaultPerson.class)).generate();

        System.out.println(list);

@snuyanzin Thanks for the feedback.
Issue now is the Client objects  have the same fields values. Goal is to have random value for each instance.
List<Client> client = new FakeCollection.Builder<Client>().suppliers(()
                -> Faker.populate(Client.class, schema))
                .len(5).generate();

client2.forEach((t) -> {
            System.out.println(t.getName() + " " + t.getEmail());

        });

Output
Hellen<EMAIL_ADDRESS>Hellen<EMAIL_ADDRESS>Hellen<EMAIL_ADDRESS>Hellen<EMAIL_ADDRESS>
Although it works with simple Collection generation
List<String> names =
    faker.collection(
            () -> faker.name().firstName(),
            () -> faker.name().lastName())
        .len(5)
        .generate();

Output
Corkery
Otha
Moore
Tisa
Sawayn

Can you share the complete code snippet?

Hi @albilu , could you give the snapshot release a try?

Hi @albilu , could you give the snapshot release a try?

@bodiam works as expected thanks! any date on when it will be release?

Hi @albilu , could you give the snapshot release a try?

@bodiam works as expected thanks! any date on when it will be release?

It's released, you can use the 2.0.2 now.


Amplify mock doesn't set environment variables on python lambda function

Describe the bug
When running amplify mock python based lambda functions do not have their AWS environment variables set.
Amplify CLI Version
4.39.0
To Reproduce

Create a Lambda function in amplify using amplify add function and choose a python runtime
print(os.environ)

Expected behavior
environment variables should be set, just like when using the NodeJS runtime.
Desktop (please complete the following information):

OS: Mac
Node Version. v12.20.0

Additional context
There seem to be lots of issues with lambda functions that run on python. From not being able to import any modules, etc. This really needs to be addressed, as being able to mock locally is key to productive development.

Closing as a duplicate of #4234


add support for home_interval variable to actiontec component

If the home_interval is set then the device_tracker will not let a device be AWAY if it has been HOME in the last home_interval seconds.

Thanks again for the code review, Paulus.  I don't know how it was working at all with all those mistakes.  I think/hope I've got it all straightened out now.

Looks good, merging.

@nkgilley Any chance of also adding this option for nmap device tracking to help solve the iPhone issues? (iPhones dropping in and out of the network to save battery)

This will be customizable in a future version of the device tracker
On Sun, Sep 6, 2015, 11:00 Carlo Costanzo<EMAIL_ADDRESS>wrote:

@nkgilley https://github.com/nkgilley Any chance of also adding this
option for nmap device tracking to help solve the iPhone issues? (iPhones
dropping in and out of the network to save battery)
—
Reply to this email directly or view it on GitHub
https://github.com/balloob/home-assistant/pull/308#issuecomment-138104370
.

Awesome.  This would be REALLY useful for the device_sun_light_trigger and iOS devices.  The lights just kept going on all night as the phones dropped on and off of wifi to save battery.


cargoLock.lockFile is broken

Describe the bug
cargoLock.lockFile currently does not work and fails in cargoSetupPostPatchHook.
Steps To Reproduce
Steps to reproduce the behavior:

try to build the following nix expression from https://github.com/NixOS/nixpkgs/pull/131538
the lock file is available here https://github.com/vrmiguel/ouch/blob/master/Cargo.lock

{ lib, rustPlatform, fetchFromGitHub }:

rustPlatform.buildRustPackage rec {
  pname = "ouch";
  version = "0.1.5";

  src = fetchFromGitHub {
    owner = "vrmiguel";
    repo = pname;
    rev = version;
    sha256 = "00ah8hgrppa61jhwb74zl5b509q0yp2pp27w9frm814iqx70qn38";
  };

  cargoLock = {
    lockFile = ./Cargo.lock;
  };

  cargoSha256 = "181aq8r78g4bl1ndlwl54ws5ccrwph0mmk9506djxvfdy3hndxkg";

  meta = with lib; {
    description = "Taking the pain away from file (de)compression";
    homepage = "https://github.com/vrmiguel/ouch";
    license = licenses.mit;
    maintainers = [ maintainers.psibi ];
  };
}

$ nix-build -A ouch
this derivation will be built:
  /nix/store/f39071gy3qrnv0raja0armcmz1i0nkr7-ouch-0.1.5.drv
building '/nix/store/f39071gy3qrnv0raja0armcmz1i0nkr7-ouch-0.1.5.drv' on 'ssh-ng://bill.r'...
copying 0 paths...
building '/nix/store/f39071gy3qrnv0raja0armcmz1i0nkr7-ouch-0.1.5.drv'...
unpacking sources
'unpacking source archive /nix/store/jgf24040yc62rvrp6v5n1kggakd7qbqd-source
source root is source
patching sources
Executing cargoSetupPostPatchHook
Validating consistency between /build/source//Cargo.lock and /build//Cargo.lock
/nix/store/mbahsiqqj61wjyh2yyzflxpf35hdpjbz-diffutils-3.7/bin/diff: /build/source//Cargo.lock: No such file or directory
/nix/store/mbahsiqqj61wjyh2yyzflxpf35hdpjbz-diffutils-3.7/bin/diff: /build//Cargo.lock: No such file or directory
ERROR: Missing Cargo.lock from src. Expected to find it at: /build/source//Cargo.lock
Hint: You can use the cargoPatches attribute to add a Cargo.lock manually to the build

Expected behavior
The Cargo.lock file should be applied
Additional context
Add any other context about the problem here.
Notify maintainers
@danieldk
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

+postPatch = ''
+  cp ${./Cargo.lock} Cargo.lock
+'';

fixes the issue. I think it is the intended behavior since cargoLock.lockFile and Cargo.lock in src can be different, also Cargo.lock doesn't have to be under root folder since you can specify path to Cargo.lock with --manifest-path flag

Thanks! If that's the case, I think having this documented in https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/rust.section.md would be helpful.


@propertyWrapper value in actor-isolated property 'home' can not be mutated from a non-isolated context

Describe the bug
Compiler shows warnings about can not be mutated from a non-isolated context in Xcode 14.0 when assigning value when using custom @propertyWrapper .
Steps To Reproduce
public struct Home {
}

@propertyWrapper
public final class MyPropertyWrapper<Value: Sendable>: @unchecked Sendable {
    public var wrappedValue: Value

    public init(wrappedValue: Value) {
        self.wrappedValue = wrappedValue
    }
}

public actor MyActor {

    @MyPropertyWrapper
    private var home: Home

    public init(home: Home) {
        self.home = home // Actor-isolated property 'home' can not be mutated from a non-isolated context; this is an error in Swift 6
    }
}

as a workaround it is possible to use MyPropertyWrapper<Home> and then warning dissapears.
public actor MyActor {

    private var home: MyPropertyWrapper<Home>

    public init(home: Home) {
        self.home = MyPropertyWrapper<Home>(wrappedValue: home)
    }
}

Expected behavior
There should not be warning about Actor-isolated property 'home' can not be mutated from a non-isolated context when using @MyPropertyWrapper
Warning not appear in Xcode 13.4.0.
Screenshots

Environment (please fill out the following information)

Xcode Version/Tag/Branch: Xcode 14.0.0 beta 6

Additional context
Add any other context about the problem here.

Reduced:
public struct Home {}

public actor MyActor {

  private var home: Home {
    get { Home() }
    set { }
  }

  public init(home: Home) {
    self.home = home
  }
}

Reduced:
public struct Home {}

public actor MyActor {

  private var home: Home {
    get { Home() }
    set { }
  }

  public init(home: Home) {
    self.home = home
  }
}

???

It’s a smaller version of the code that triggers the same error. It’s nothing to do with property wrappers specifically, but with using a computed property.

Aaa okay make sense now - thanks for explanation.

Found out that this workaround works for me (instead of using computed property i use reference to propertyWrapper):
public actor MyActor {

    @MyPropertyWrapper
    private var home: Home

    public init(home: Home) {
        _home = MyPropertyWrapper<Home>(wrappedValue: home)
    }
}

You need to make sure home is a published property
@Published var home: Home? = nil


Also lift struct fields

Fix #336
bors merg

bors merge

I added the boundedness check for lifting, hopefully it can fix it


Don't alloc header names

Split from #335

Rebased on 7e8a405 and measured. Made it worse.
dev (7e8a405) - 499k
391 (e0ebb12) - 465k (-7%)

@DamianEdwards hopefully it will behave better on  #362

Closing this taken some legibility improvements to  #424


How to define num_action for new trade type?

If I train the model for new trade type, for example, Japanese Stock or London Future, how to define num_action?

Hi,
If you are referring to the task portfolio management, the ideal solution is the number of stocks in the pool plus 1.
The num_action indicates the number of dimensions of your action in portfolio management. In our trading environment, the action will first go through a softmax and transform itself from action to each portfolio weights. The reason to plus 1 is to add a riskless asset, saying cash, to the portfolio weights to make the simulation more realistic.

Maybe  my expression is not clear enough.
I mean what value should assigned to num_action when train the model for new trade type.
Is the action means BUY OPEN, SELL OPEN, BUY CLOSE, SELL CLOSE, VOLUME and so on when the trade type is future?

Sorry for the late reply,
I am still confused about your expression. Could you specify the config file algorithms, environment and task you are referring?

@qinmoelei @DVampire @EC2EZ4RD Maybe my expression is not clear enough.
I mean what value should assigned to num_action when train the model for new trade type. Is the action means BUY OPEN, SELL OPEN, BUY CLOSE, SELL CLOSE, VOLUME and so on when the trade type is future?

If you are referring to high frequency trading environment, the process is as followed.
For high frequency trading environment, you need to have the snapshot of limit order book of your new trade type. The reason for that is during high frequency trading, transaction accuracy is the key. You can only conduct the order if there is enough liquidity in the market (saying, if you want to buy 0.01BTC right away, you have to check whether someone else in the market want to sell it in the limit order book, if there is no one want to sell it. Then your order could not be fully executed). The price per unit of the executed order is also determined by your order size. (saying if you want to 1 BTC, there is a person want to sell 0.2 BTC at $25000/BTC and another person want to sell 0.8 BTC at $26000/BTC, you overall are paying $(0.225000+0.826000)/(0.2+0.8))/BTC for one single BTC, but if you are only buying 0.2 BTC, then the price should be $25000/BTC.
Back to you question, under this trading scenario, the action itself only represents the position you want to hold currently, and the price is automatically calculated by the limit order book. Since each broker has regulation about the minimum volume for each order. We design the num_action to regulate the number of positions we are allowed to hold. This parameter with the parameter max_holding_number all together form the trading volume of your order.
For instance, if the max_holding_number  is 0.01 and the num_action is 5. It means the allowed positions are [0, 0.0025,0.005,0.0075,0.01], indicating the minimum volume for an order is 0.0025.
Therefore, the action does not mean BUY OPEN, SELL OPEN, BUY CLOSE, SELL CLOSE but just the position you want to hold currently.
Hope this answer your question, and please star and fork our repo, your support is very important for us.

Thank you very much for your patient reply!
Now I know the meaning of this variable.

@qinmoelei
Where do the operations define, such as BUY OPEN, SELL OPEN, BUY CLOSE, SELL CLOSE?

@qinmoelei
"So, the operation is limited in BUY CLOSE, SELL CLOSE"
Is that wrong? Without OPEN operation, there is no position. Then CLOSE operation is Meaningless.


Images not previewing

In the WYSIWYG pane or view, images are broken, whcih I assume is because the url/location is relative to the wrong path. I'd like to fix that.
I saw something in docs or issues: "customtHTMLRenderer"??

A reasonably innocuous workaround is adding the server-relative path to the image location.


split Relationship and update schemaVersion w/signoff

Notes for Reviewers
This PR fixes #11123
Update the schemaVersion for all.
All tests done everything working fine.
Know Issue when there are multiple edges of same kind, type, sub-type  only the first file is saved.
Signed commits

[ ] Yes, I signed my commits.

"....the first file is saved." You mean, imported?

"....the first file is saved." You mean, imported?

Yes, sir I meant the first file that is imported .

@Jougan-0 have you asked @innocentrda to review? There will be merge conflicts in his open PRs.

@Jougan-0 have you asked @innocentrda to review? There will be merge conflicts in his open PRs.

No, I doing it now.


Repeating timer

example: timer add repeating 10d 5d  // this would add a timer in 5 days, which would repeat every 10 days.
example: timer add repeating 10d  // this would add a timer in 10 days which would also repeat every 10 days
example: timer edit  repeating 10d // modify existing timer to repeat every 10 days.

instead of using the word repeating we can also use r so it's faster to type

Would have to do some major refactoring for this so lowpriority for now