Add sharding scaling UI

Fixes #3848 .
Changes proposed in this pull request:

Add sharding scaling UI

Pull Request Test Coverage Report for Build 1675

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.006%) to 64.705%

Files with Coverage Reduction
New Missed Lines
%

sharding-orchestration/sharding-orchestration-core/src/main/java/org/apache/shardingsphere/orchestration/internal/util/IpUtils.java
2
80.0%

Totals

Change from base Build 9434:
0.006%

Covered Lines:
11016

Relevant Lines:
17025

💛  - Coveralls

Codecov Report

:exclamation: No coverage uploaded for pull request base (sharding-scaling-ui@583e9d0). Click here to learn what that means.
The diff coverage is 61.33%.

@@                  Coverage Diff                  @@
##             sharding-scaling-ui   #4232   +/-   ##
=====================================================
  Coverage                       ?   60.8%
  Complexity                     ?     352
=====================================================
  Files                          ?    1012
  Lines                          ?   17025
  Branches                       ?    3004
=====================================================
  Hits                           ?   10352
  Misses                         ?    6020
  Partials                       ?     653

Impacted Files
Coverage Δ
Complexity Δ

...sphere/route/time/DatabaseTimeServiceDelegate.java
0% <ø> (ø)
0 <0> (?)

.../masterslave/LoadBalanceStrategyConfiguration.java
50% <ø> (ø)
1 <0> (?)

...dingsphere/route/time/impl/TimeServiceFactory.java
0% <ø> (ø)
0 <0> (?)

...config/common/YamlAuthenticationConfiguration.java
100% <ø> (ø)
0 <0> (?)

...ig/sharding/YamlShardingStrategyConfiguration.java
100% <ø> (ø)
1 <0> (?)

...yaml/config/common/YamlProxyUserConfiguration.java
100% <ø> (ø)
1 <0> (?)

...config/sharding/YamlKeyGeneratorConfiguration.java
100% <ø> (ø)
0 <0> (?)

...config/sharding/YamlShardingRuleConfiguration.java
100% <ø> (ø)
0 <0> (?)

.../yaml/config/common/YamlRootRuleConfiguration.java
100% <ø> (ø)
0 <0> (?)

...ingsphere/route/time/impl/DatabaseTimeService.java
0% <ø> (ø)
0 <0> (?)

... and 102 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 583e9d0...5ad47f0. Read the comment docs.


GH-38096: [Java] FlightStream with metadata can cause error when closing

Rationale for this change
The Java FlightStream can raise an error if metadata is transferred and ends up being closed twice.
java.lang.IllegalStateException: RefCnt has gone negative
	at org.apache.arrow.util.Preconditions.checkState(Preconditions.java:458)
	at org.apache.arrow.memory.BufferLedger.release(BufferLedger.java:130)
	at org.apache.arrow.memory.BufferLedger.release(BufferLedger.java:104)
	at org.apache.arrow.memory.ArrowBuf.close(ArrowBuf.java:1044)
	at org.apache.arrow.util.AutoCloseables.close(AutoCloseables.java:97)
	at org.apache.arrow.flight.FlightStream.close(FlightStream.java:208)

What changes are included in this PR?
When FlightStream is closed, remove any reference of previous metadata to prevent reference count going negative if closed again. Also added ExchangeReaderWriter.getResult() for convenience and clear up ambiguity on error handling.
Are these changes tested?
Unit tests added for closing with metadata and
Are there any user-facing changes?
Added ExchangeReaderWriter.getResult()

Closes: #38096

@lidavidm I was playing around with the DoExchange call and noticed a couple of issues. At first I was a little confused as to why getWriter().getResult() wasn't being called until I realized that errors were coming through the reader. If getWriter().getResult() is called before getReader().next() is called a final time, then it seems to hang.
So I noticed that you really need to call getReader().next() a final time, so it will return false or raise any errors that happened after exchanging all the batches. To hopefully make this more clear to the user I added ExchangeReaderWriter.getResult() so it will be obvious to call this instead. I'm not 100% sure that it's a good idea, so let me know what you think. Thanks!

We try to expose 'independent' readers/writers but in actuality in gRPC they are tied + the reader is the only source of errors (which in some sense makes sense, I suppose) so this is perhaps more of a mistake in our API design

Makes sense, thanks for the explanation

Thanks @lidavidm !


ensures Input.value() is only called once by all scalars

cleaned up all scalar tests to use assertEvaluate/AssertingInput which fails if Input.value() is called multiple times

@matriv pls review

Current coverage is 81.09% (diff: 72.72%)

Merging #4476 into master will increase coverage by 0.01%

@@             master      #4476   diff @@
==========================================
  Files          1303       1303
  Lines         44166      44159     -7
  Methods           0          0
  Messages          0          0
  Branches       7029       7027     -2
==========================================
- Hits          35810      35809     -1
+ Misses         5675       5654    -21
- Partials       2681       2696    +15

Powered by Codecov. Last update 0f5e864...a25f7c5


Switching from ramda.pipe to sanctuary.pipe causes errors when dealing with rx

So I have a cycle.js project, I use ramda's pipe, things work fine:

Today I wrote a PR that switches this project to using sanctuary, but ran into some really head scratching issues:

The essence of this issue can be observed by modifying
https://github.com/lacqueristas/www/pull/1/files#diff-895656aeaccff5d7c0f56a113ede9662L37
to look like this
const dom$ = map((value) => console.log(value), storage$)

It now will console a strange Array: [Object, 0, MapObservable]. Before the change if you did this you would only get Object.
Since the entire pull request is simply importing from sanctuary and switching to the pipe([]) api...I'm left wondering why this broke?

By the way, not knowing where this was actually happening (ie, what pipe) was a super pain, but I'm not sure what to do about that exactly.

First, I'm excited to see the reasons you listed in your pull request description. :)
Without looking closely at your code I can provide one guess as to what's going on. Consider:
[1, 2, 3].map(R.pipe(R.inc));
// => [2, 3, 4]

[1, 2, 3].map(R.pipe(S.inc));
// ! ‘inc’ requires one argument; received three arguments

[1, 2, 3].map(S.pipe([S.inc]));
// ! ‘pipe’ requires two arguments; received four arguments

Ramda is forgiving of "extra" arguments; Sanctuary is not.

By the way, not knowing where this was actually happening (ie, what pipe) was a super pain, but I'm not sure what to do about that exactly.

I suggest importing both R.pipe and S.pipe, then updating call sites one by one. After updating all the call sites (and resolving any issues) the R.pipe imports could be removed.

Wait, what? Why does Sanctuary behave this way? Why does ramda behave this way? Are you suggesting this isn't the "result":
[pipe(inc)(1), pipe(inc)(2), pipe(inc)(3)]

And that instead this is what's happening:
pipe([inc])(1)(2)(3)

Because that makes no sense.

Hi @krainboltgreene, I believe this was the implication:
[pipe([inc])(1, 0, [1, 2, 3]), pipe([inc])(2, 1, [1, 2, 3]), pipe([inc])(3, 2, [1, 2, 3])]

Sanctuary's pipe takes 2 arguments, but 4 are being passed in. I'm not familiar with Rx, but it does look like this is probably what is happening:
https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/select.md

@kedashoe beat me to the punch, but I'll post my comment anyway.

Let's take a step back.
R.map(S.pipe([S.inc]), [1, 2, 3])

// is equivalent to...
[S.pipe([S.inc])(1), S.pipe([S.inc])(2), S.pipe([S.inc])(3)]

// which can be more simply expressed as...
[S.inc(1), S.inc(2), S.inc(3)]

// which of course evaluates to...
[2, 3, 4]

So far so good. Array#map, though, is not so well behaved.
[1, 2, 3].map(S.pipe([S.inc]))

// is equivalent to...
[S.pipe([S.inc])(1, 0, [1, 2, 3]), S.pipe([S.inc])(2, 1, [1, 2, 3]), S.pipe([S.inc])(3, 2, [1, 2, 3])]

S.pipe thus receives four arguments: a list of functions, an element of the array, an index, and the array over which we're mapping.

 I had no idea. Okay, so I guess my "solution" here is to use R.unary?

That's a workaround, yes. You could also mention this problem to the RxJS team. It would be great to have a "lawful" map method. :)

Thanks so much for helping!

For future me's out there, Most.js doesn't suffer from this fate it looks like.

Neither does flyd :smile: (from ramda contributor @paldepind)

Map is a unary function in Highland too.


Exclude tasks with no status from task_state_time

These tasks have no timestamp defined, and 0 doesn't seem like a useful substitute timestamp here (I think, at least), so maybe just skip them?
Fixes #6

god dammit, this was supposed to be a PR against the upstream repo THANKS OBAMA


Suggestion for logger in degitx

By reviewing code under logging folder, here are a few suggestions based on the logging features in a couple of open-source projects I used to work on.  Search chartmuseum and mattermost in github. I will refer these two open-source projects as they in the content below:

I don't understand why Degitx chose to define LogLevel as int8.   They go with string instead int8.   This is one example:
DebugLevel logLevel = "DEBUG"
InfoLevel  logLevel = "INFO"
WarnLevel  logLevel = "WARN"
ErrorLevel logLevel = "ERROR"
Do we really need to return two types of zap logger in Logger struct.  zap.Logger, and zap.SugardLogger?  I think if you want to a simple one, jus go with sugared type.  If you want the flexibility, go with zap.logger.  It seems that we need more flexibility for this big project. We can use a function to return sugarLogger if needed.
logger configuration is defined in config.go.  LogConfig is wrapped inside logContext.  How can you change the log context or a config by using a configuration file?  Is it possible?  Also I see some projects use ""github.com/gin-gonic/gin" for go context.
Many projects treat configuration of a system is to provide a context.  We don't really need both config.go and context.go.  You read the config file to set up the configuration of a system.  Does it make sense?
Our logger shall be a wrapper of zap and it shall be for a general purpose.  I see a couple of places that might include nodeId or locator, which makes our logger specific.
if len(logCtx.nodeID) != 0 {
spec = append(spec, zap.String("locator", logCtx.nodeID))
}
What is template here?   what does the name of template indicate?  can we just use msg or message instead of template?
func (log *Logger) Debug(template string) {
log.internalLogger.Debug(template)
}
What do you mean internalLogger?  Do you have externalLogger?
The only thing you did in NewLogger is to call initInternalLogger.  Is it necessary to create two functions here instead of just one NewLogger( )?
please, make the code simple and easy to read for the open-source project.

By reviewing code under logging folder, here are a few suggestions based on the logging features in a couple of open-source projects I used to work on. Search chartmuseum and mattermost in github. I will refer these two open-source projects as they in the content below:

I don't understand why Degitx chose to define LogLevel as int8.   They go with string instead int8.   This is one example:
DebugLevel logLevel = "DEBUG"
InfoLevel  logLevel = "INFO"
WarnLevel  logLevel = "WARN"
ErrorLevel logLevel = "ERROR"

The fastest open-source logger uses int8.
Since degitx hasn't an ability to change log level after its initialization from config, LogLevel could be removed at all (see). But I don't think it is needed to be changed to string.

Do we really need to return two types of zap logger in Logger struct.  zap.Logger, and zap.SugardLogger?  I think if you want to a simple one, jus go with sugared type.  If you want the flexibility, go with zap.logger.  It seems that we need more flexibility for this big project. We can use a function to return sugarLogger if needed.

We need to keep zap logger easy replaceable. Other loggers may not be divided to Logger/SugardLogger.
So only API functions should be public.

logger configuration is defined in config.go.  LogConfig is wrapped inside logContext.  How can you change the log context or a config by using a configuration file?  Is it possible?  Also I see some projects use ""github.com/gin-gonic/gin" for go context.

You can only set up a logger once by initialization from config file (see).

Many projects treat configuration of a system is to provide a context.  We don't really need both config.go and context.go.  You read the config file to set up the configuration of a system.  Does it make sense?

What do you suggest? To put all code in one file? Is it better for readability?

Our logger shall be a wrapper of zap and it shall be for a general purpose.  I see a couple of places that might include nodeId or locator, which makes our logger specific.
if len(logCtx.nodeID) != 0 {
spec = append(spec, zap.String("locator", logCtx.nodeID))
}

Locator is a part of logger specification (see).
It's also possible to create general logger without locator (see).

What is template here?   what does the name of template indicate?  can we just use msg or message instead of template?
func (log *Logger) Debug(template string) {
log.internalLogger.Debug(template)
}

Sure, I will rename it.

What do you mean internalLogger?  Do you have externalLogger?

internalLogger means encapsulated logger implementation as is written in comment. Zap Logger in our case.
There is no externalLogger, there is degitx.Logger wrapper instead.

The only thing you did in NewLogger is to call initInternalLogger.  Is it necessary to create two functions here instead of just one NewLogger( )?
please, make the code simple and easy to read for the open-source project.

initInternalLogger is already too complex. If you ask for simple code, it should be divided further for a small ones, rather than merged with NewLogger.

By reviewing code under logging folder, here are a few suggestions based on the logging features in a couple of open-source projects I used to work on. Search chartmuseum and mattermost in github. I will refer these two open-source projects as they in the content below:

I don't understand why Degitx chose to define LogLevel as int8.   They go with string instead int8.   This is one example:
DebugLevel logLevel = "DEBUG"
InfoLevel  logLevel = "INFO"
WarnLevel  logLevel = "WARN"
ErrorLevel logLevel = "ERROR"

The fastest open-source logger uses int8.
Since degitx hasn't an ability to change log level after its initialization from config, LogLevel could be removed at all (see). But I don't think it is needed to be changed to string.

Do we really need to return two types of zap logger in Logger struct.  zap.Logger, and zap.SugardLogger?  I think if you want to a simple one, jus go with sugared type.  If you want the flexibility, go with zap.logger.  It seems that we need more flexibility for this big project. We can use a function to return sugarLogger if needed.

We need to keep zap logger easy replaceable. Other loggers may not be divided to Logger/SugardLogger.
So only API functions should be public.

logger configuration is defined in config.go.  LogConfig is wrapped inside logContext.  How can you change the log context or a config by using a configuration file?  Is it possible?  Also I see some projects use ""github.com/gin-gonic/gin" for go context.

You can only set up a logger once by initialization from config file (see).

Many projects treat configuration of a system is to provide a context.  We don't really need both config.go and context.go.  You read the config file to set up the configuration of a system.  Does it make sense?

What do you suggest? To put all code in one file? Is it better for readability?

Our logger shall be a wrapper of zap and it shall be for a general purpose.  I see a couple of places that might include nodeId or locator, which makes our logger specific.
if len(logCtx.nodeID) != 0 {
spec = append(spec, zap.String("locator", logCtx.nodeID))
}

Locator is a part of logger specification (see).
It's also possible to create general logger without locator (see).

What is template here?   what does the name of template indicate?  can we just use msg or message instead of template?
func (log *Logger) Debug(template string) {
log.internalLogger.Debug(template)
}

Sure, I will rename it.

What do you mean internalLogger?  Do you have externalLogger?

internalLogger means encapsulated logger implementation as is written in comment. Zap Logger in our case.
There is no externalLogger, there is degitx.Logger wrapper instead.

The only thing you did in NewLogger is to call initInternalLogger.  Is it necessary to create two functions here instead of just one NewLogger( )?
please, make the code simple and easy to read for the open-source project.

initInternalLogger is already too complex. If you ask for simple code, it should be divided further for a small ones, rather than merged with NewLogger.


apply psr2 to src folder. require psr2 in all future builds.

apply psr2 to src folder.
require psr2 check to pass in CI build.
document adherence to psr1, 2, and 4 in readme.

hello @Sysaninster , sorry to be so noisy lately.
i merged a couple of commits related to PSR-2 and the build last night. none of it should affect any src or runtime functionality so i went ahead and patched without review after i saw each build pass.
if you are interested, and at your leisure of course, here are the requests for audit:

https://github.com/enlitepro/enlite-monolog/pull/26
https://github.com/enlitepro/enlite-monolog/pull/27
https://github.com/enlitepro/enlite-monolog/pull/28
https://github.com/enlitepro/enlite-monolog/pull/29

Hello @abacaphiliac , no problems)
I saw your requests. It's good job.


Adds a "-precert" flag to "openssl req" for creating pre-certificates

This makes it a little easier to create a pre-certificate.
I'm not sure if this is worthwhile having as a flag, given the ease of adding the poison extension through other means, but it saves a user having to lookup RFC 6962 and learn how to properly add this extension themselves.

Documentation updated and a basic test added.

By the way, the Travis build failing is unrelated to this PR - looks like master had an issue when I branched from it.

Yup, we know it’s not your fault ☺

Can this be merged, or does today's release of the beta mean it has to remain in limbo?

After internal discussion... we think it's a bug that the s2i functions for precert are missing.  String to internal.  Then it could easily parse the conf file, and also a precert flag that calls the function.  So can you write that?

No problem, I've added the requested s2i function in PR #901.

This looks like a feature, and therefore not for 1.1.0? Ping @richsalz.

Agree it seems like a feature and it wasn’t added in time, sadly.

Since PR #901 was merged, this feature became simply a "nice to have", since the same thing could be achieved through a CONF file. Was there anything that actually needed fixing with this PR (besides rebasing)?

Ping @richsalz, @mattcaswell

if @RJPercival will rebase, and someone else reviews also i'll merge.

Rebased.

Done.

The doc update to state "These SCTs can then be embedded into the pre-certificate as an extension, before
removing the poison and signing the certificate." raises a question as to whether or not the 'ca' program supports doing this.
+1

Tim raises a good point.  What do you think of adding an -rmprecert or similar flag that removes the poison before signing?  It can be a separate PR.

@RJPercival we need you to sign the ICLA.  (david and agl already have)

Sure, I can implement an -rmprecert flag. I'm not sure how much time I'll have to do so in the immediate future though. I'll try and fit it in around my other work.

@richsalz Max Sills has attempted to contact you RE the iCLA. Could you please discuss it with him?

@RJPercival I emailed with Max.  Please sign the CLA :)

Thanks, I've emailed the signed CLA.

merged to master.  don't forget you owe us a "-rmpoison" flag :)

Rather than an -rmpoison flag, wouldn't it be better to have an -scts flag that embeds SCTs into a precertificate and removes the poison in the process? In what scenario would you want to just remove the poison?

Sure, that works also; the -sct flag takes a file of PEM encoded SCT's or such?

That's what I was thinking.
On Fri, 3 Mar 2017, 18:12 Rich Salz<EMAIL_ADDRESS>wrote:

Sure, that works also; the -sct flag takes a file of PEM encoded SCT's or
such?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/pull/843#issuecomment-284028166, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB29lI1txxf8KR_owRLyeZzOw82FFCLcks5riFfxgaJpZM4HuGJb
.


Working on laughing therapy

I would like to give this new feature of laughing therapy, which leads to a new tab where we find therapies to get stress free- through laughter.

@keerthana054 that means you will add a new webpage,right..?

@keerthana054 that means you will add a new webpage,right..?

yes!

@myhacktech @Susmita-Dey Can I work on this issue?

@myhacktech @Susmita-Dey Can I work on this issue?

@keerthana054 are u still working on this?

@myhacktech @Susmita-Dey Can I work on this issue?

@Vanshiii203 yes u may go this issue


image_demo.py does not support  show mask

Checklist
config/ms_rcnn_x101_64x4d_fpn_1x_coco.py
Describe the bug
image_demo.py's result is Binary mask.
But show_result function need RLE.
So it's wrong
Reproduction

What command or script did you run?

 python demo/image_demo.py  configs/ms_rcnn/my_ms_rcnn_x101_64x4d_fpn_1x_coco.py work_dirs/my_ms_rcnn_x101^C4x4d_fpn_1x_coco/latest.pth

Error traceback
File "demo/image_demo.py", line 105, in main
    show_result_pyplot(model, img, result, score_thr=args.score_thr)
  File "/home/juzheng/code/competition/mmdetection/mmdet/apis/inference.py", line 146, in show_result_pyplot
    img = model.show_result(img, result, score_thr=score_thr, show=False)
  File "/home/juzheng/code/competition/mmdetection/mmdet/models/detectors/base.py", line 214, in show_result
    mask = maskUtils.decode(segms[i]).astype(np.bool)
  File "/home/juzheng/anaconda3/envs/python3.6/lib/python3.6/site-packages/pycocotools/mask.py", line 91, in decode
    return _mask.decode([rleObjs])[:,:,0]
  File "pycocotools/_mask.pyx", line 146, in pycocotools._mask.decode
  File "pycocotools/_mask.pyx", line 128, in pycocotools._mask._frString

Should be fixed in #2786

Fixed in #2824.


allow custom paths for chaining

The patch adds the ability to set up custom paths to the setChain command.
By moving from current_hop to pathindex we can allow loops in the path.
One problem still remains: paths containing a loop with a single hop will not be set up correctly.
say: [s1, s2, s1]
The 'IN_PORT' action is needed to set up such a flow. ryu does not support this yet.

Can one of the admins verify this patch?

test this please

Can one of the admins verify this patch?


It takes around 3-5 seconds to finish the commit. One consequence of this, other than being annoying, is I've added a file, committed, and while the commit is processing I've added another file intended to be a separate commit, but the second add finishes before the first commit, and VSCode commits both files with the same commit message. Can be undone but it's a headache and it's evidence of just how long each commit is taking.

VSCode Version: 1.37.1
OS Version: Windows_NT x64 10.0.17763

Steps to Reproduce:
Using the source control sidebar...

add a file that's been modified
commit that file with a message

Does this issue occur when all extensions are disabled?: Yes
Notes:
Haven't tested with insider.

What about in the Command Prompt? What about inside VS Code's Terminal?

The online terminal (using bash on Windows) works fine. It's only slow when using the UI in the sidebar.

What git version do you have installed?

git version 2.21.0.windows.1

Are any other operations in VS Code, related to Git, slow? Staging, reverting, etc?

@joaomoreno I have had this same issue. Staging, diffing, and reverting are all slower. @pr3tori4n any updates on your part?

For me, general slow Git operations happens too, in big projects (hundreds of files).
What has helped for me has been disabling auto-save completely and saving manually (prior, I had auto-save on focus change).


SCRUM-1689 Handling of references

Change the way reference objects are stored in the curation DB.  The following attributes are now stored:
curie - now the AGR curie, was previously the PubMed / MOD curie
submittedCrossReference - primary key of the table, value is the same as what was previously stored as curie
primaryCrossReference - curie to display in curation DB tables (preferentially PubMed curie, otherwise first alphabetically)
secondaryCrossReferences - cross-references other than the primaryCrossReference
Endpoint for synchronisation of references with literature system implemented.  If a reference is no longer found in the literature system then the object on the curation DB side is marked as obsolete.

Wrong branch pushed


deploy to local instance of kubernetes

there are still some bugs in it

there are still some bugs in it

bug fixed. i test on my local pc, all resources run well.


Threads (post sub-sections)

Threads, as seen in the various Demon Cam sandboxes, should be implemented. Preferably with the following features:

Visibilities for individual threads in a post
Handled by the scraper appropriately
Content warnings for individual threads (see issue #19)
A clearer name? ('Threads' is now often used for the 'post' model.)

Pedro had a suggestion for implementation on the forums.

This might in fact not be necessary. So far most threads have been either compressed into a single thread or separated and had their titles prefixed.

Mostly handled by the scraper now.


Update design kit to v10.20.0

Update the design kit to v10.20.0. Changelog:
https://github.com/carbon-design-system/carbon-design-kit/releases/tag/v10.20.0

Incorporate the Variants feature: https://help.figma.com/hc/en-us/articles/360056440594


Add scripts to fix 94

This PR includes the same files as https://github.com/Azure/iot-plugandplay-models/pull/20  to keep TEST in sync


Update caching to v1

Updating caching per new version
https://github.com/actions/cache/blob/master/examples.md#node---npm

I restarted my computer three times and it helped a lot


Handle multiple featureMember elements for different types (WFS format)

Parsing a GML document with multiple featureMember elements for different types was not handled correctly. parseFeatures for example returned [ol.Feature, ol.Feature, ol.Feature, Array[0], Array[0]]. The proposed fix makes sure that the returned array only contains valid features.
Closes https://github.com/openlayers/ol3/issues/5357

thanks @tsauerwein this looks good to me, please merge if Travis agrees

LGTM

Thanks for the review!


Explictily throw NotSupport for commands - Get/Set/Clea- Content, Move/Copy/New/Remove/Rename/Clear/Set-Item

Add handling to not supported commands, throw NotSupport error to reduce confusion;
Add UnitTest for all of the not supported commands.
UnitTest passed in both Full PowerShell and PowerShell Core.

 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.:x: BellaLi sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Abandonded.


feat(docs): Cookbook Onboard (AI Assistant) integration

What I Did
Extended custom.js with code to instantiate the Cookbook Onboard integration.

Resolves: #2197
How to Verify It
Launch the project in production or a dev environment and try out Cookbook Onboard by clicking the "Ask Cookbook" button in the bottom right corner of the docs :)
You can also use following preview url: https://apeworx-cookbook.vercel.app/ape/latest/userguides/quickstart.html
Checklist

[x] All changes are completed
[ ] New test cases have been added
[x] Documentation has been updated

I'm not sure if the "New test cases have been added" item on the checklist is applicable here, so I skipped it for now. Let me know if it is after all, and I'll be happy to make the necessary changes!

note: you can use docs: PR title prefix instead of feat(docs): since this is not really a feature of the Ape tool itself

bumping :)

The file being changed no longer exists.
We are using https://github.com/ApeWorX/sphinx-ape for docs now


Add detekt-test target

Add detekt_test rule which shares implementation with the existing detekt-build-target
Modify detekt-rule implementation

Set default attributes that are shared between the detekt-build-target & detekt-test-target
Always write the execution-result of detekt to a text file
Do not fail detekt execution if --run-as-test-target is passed via detekt arguments

Running the detekt-test target will fail the execution after it evaluates the execution-result that is written to the output file

Update OneShot execution to modify the contents of the params-file (if passed-in) to only passthrough detekt-related arguments

One big change since the last review: after getting OneShot execution working, I needed to make a change for OneShot to overwrite the params file after reading and then sanitizing the arguments within it: https://github.com/davidkurkov/bazel_rules_detekt/pull/1/files#diff-daf3fe337b1adb03c3c9fd860bda3e8e834bd4497453eafa2caca79bdb4e07c2R30-R76
Note: OneShot execution can be forced by setting supports-workers & supports-multiplex-workers to 0

Thank you for all of the input @Bencodes & @artem-zinnatullin ! I'm closing this draft PR and opened a couple of PRs against the upstream:

https://github.com/buildfoundation/bazel_rules_detekt/pull/148
https://github.com/buildfoundation/bazel_rules_detekt/pull/149


Do not include VCRTForwarder libs if AppContainerApplication is set t…

…o 'true'
If a cppwinrt app has a dependency on Microsoft.VCRTForwarders (Which may not be able to be helped if it is another nuget package bringing in the dependency), the forwarders will be included in the appx package, which causes the app to not work on platforms without the VCRedist binaries such as HoloLens.

This addresses the issue described in #12


Crash blocking

Goals
In some cases, I have to replace new data before drawing the view. To not ending in an endless notification call I am using commitWrite(withoutNotifying:). Therefore I have to use the main thread, because addNotificationBlock is only available in a runloop and I have to commit the write on the same realm - which have to be called from the same thread - to use withoutNotifying.
The disadvantage is that the main thread is blocking the UI.
Expected Results
If data of type SomeClass changes and some case is given, the data should be replaced by a server response. After that the view should draw with the most recent data.
Actual Results
The application crashes with this backtrace:
https://pastebin.com/DD6JEndN
Steps to Reproduce

Code Sample
override func viewDidLoad() {
    let realm = try! Realm()
    let notificationToken = realm.objects(SomeClass.self).addNotificationBlock { _ in
        if someCase {
           self.updateDataWithoutNotifying(realm, notificationToken: notificationToken) {
               self.redraw()
           }
        }
    }
}

private func updateDataWithoutNotifying(_ realm: Realm, notificationToken: NotificationToken, completionHandler: () -> ()) {
    Request(...) { response in
        // viewDidLoad runs in main queue
        OperationQueue.main.addOperation {
            defer {
                completionHandler()
            }
            realm.beginWrite()
            Storage.someClass = SomeClass(response)
            do {
                try realm.commitWrite(withoutNotifying: [notificationToken])
            } catch {
                if realm.isInWriteTransaction {
                    realm.cancelWrite()
                }
                print("Error!")
            }
        }
    }
}

Version of Realm and Tooling
Realm framework version: 2.5.0
Realm Object Server version: -
Xcode version: 8.3
iOS/OSX version: iOS 10.3
Dependency manager + version: Cocoapods 1.2.0

Hi @Patrick-Remy. Thanks for reaching out about this. I wanted to let you know that we've received your issue and that someone will follow-up with you soon with a solution or further questions.

Thanks for getting in touch with us. The crash you're seeing looks like a bug. Can you create a minimal reproduction case and send it to<EMAIL_ADDRESS>Thanks.

@Patrick-Remy thanks for filing this. I'll be closing the ticket since we haven't heard back from you in a few weeks. Please open a new issue if you see similar issues with more recent releases, such as 2.6 or later.


deviantart no longer works after they changed their url

Ripme version: v1.7.56
Java version:  Version 8 Update 171 (build 1.8.0_171-b11)
Operating system: macOS High Sierra
Exact URL you were trying to rip when the problem occurred: (NSFW!!!!!)https://www.deviantart.com/victorzulu/gallery/?catpath=/

Expected Behavior
Download all images from user gallery
Actual Behavior
Deviantart no longer works since they've updated their urls. Downloads random pictures instead.

This has already been fixed and will be out in the next version of ripme


Change dist/wow.js to dist/wow.min.js on .bower.json file

Can you change dist/wow.js to dist/wow.min.js on .bower.json file?

@matthieua could you please have a look at this. Again I'm no expert, do bower packages tend to include minified files or originals?

@attilaolah @matthieua share with you an excelent article of @ryexley about bower http://bob.yexley.net/creating-and-maintaining-your-own-bower-package/ in bower docs, recommend put no minified files in main attribute, but in practice, rarely a developer does a debug over this files. However these files must be in the delivery package just for this cases.

please keep dist/wow.js


Add timespan object, create modular CSS, add initial timeline

This is part of a bigger change that will include the timespan object. I still have to link up the front-end and back-end here, so it's in progress. Just putting it out there for people to have a look at.
What's changed

Adding a timespan object, todo: mutations, actually creating them @RickCarlino would love to hear your thoughts about it. There's some chat on it in the #guide-creation channel on slack.
Adding the timeline manipulation functionality on the guide edit/new pages.
Refactoring some of the SCSS to be more modular, as suggested by @growdigital.
Added some tests

Coverage decreased (-3.63%) to 96.3% when pulling 798fcdd711673ce5872f3352b05223ed2610d222 on simonv3:add-timeline into 67f284d07d469cb72d74aa3096595f59f0b87929 on openfarmcc:master.

Coverage decreased (-3.63%) to 96.3% when pulling 798fcdd711673ce5872f3352b05223ed2610d222 on simonv3:add-timeline into 67f284d07d469cb72d74aa3096595f59f0b87929 on openfarmcc:master.

Coverage decreased (-0.46%) to 99.47% when pulling cb34d9f0fc07a142f0e747b5721af78e2fe57e06 on simonv3:add-timeline into 67f284d07d469cb72d74aa3096595f59f0b87929 on openfarmcc:master.

Coverage increased (+0.0%) to 99.93% when pulling 3084db7e168fcee7732d3b6925dcc6c5cc5f55a5 on simonv3:add-timeline into 67f284d07d469cb72d74aa3096595f59f0b87929 on openfarmcc:master.

Coverage increased (+0.0%) to 99.93% when pulling fc19fb863b90bf624058294ccbf0677d520549e7 on simonv3:add-timeline into 67f284d07d469cb72d74aa3096595f59f0b87929 on openfarmcc:master.

Coverage increased (+0.0%) to 99.93% when pulling fc19fb863b90bf624058294ccbf0677d520549e7 on simonv3:add-timeline into 67f284d07d469cb72d74aa3096595f59f0b87929 on openfarmcc:master.


index name can be as same as the table name

e.g. dataname = adult_1, self.index_count = 1
https://github.com/HoloClean/holoclean/blob/dea7dbd23f4babd6e80109c2e35e662d91def38e/dataset/table.py#L71

it will not be the same if dataname input for hc.load_data always equals to input dataset's name


updated the error checking for the new distributions

Below are the Tests used to check errors:
Dist_Cauchy_Checking.pdf
Dist_DiscreteUniform_Checking.pdf
Dist_LogNormal_Checking.pdf
Dist_Pareto_Checking.pdf
Dist_Rayleigh_Checking.pdf

Looks good. Merging.


Different set of patches for PyTorch pinned and main

The current set of patches cannot be applied to PyTorch main:
error: patch failed: c10/xpu/XPUDeviceProp.h:136
error: c10/xpu/XPUDeviceProp.h: patch does not apply
error: patch failed: c10/xpu/XPUFunctions.cpp:89
error: c10/xpu/XPUFunctions.cpp: patch does not apply
error: patch failed: test/test_xpu.py:110
error: test/test_xpu.py: patch does not apply
error: patch failed: torch/csrc/xpu/Module.cpp:230
error: torch/csrc/xpu/Module.cpp: patch does not apply

https://github.com/intel/intel-xpu-backend-for-triton/actions/runs/10449616738/job/28933849681

Should it be fixed by https://github.com/intel/intel-xpu-backend-for-triton/pull/1924?

Should it be fixed by #1924?

Either we move forward the pin every time or support different set of patches. The former is simpler when it works.


Update documentation on how to build docs using mkdocs

Is this done in PR #410? I saw you have updated the documentation in the for developers section @jwestw

@jwestw do you mind checking this issue please as I think it's been completed?

Not needed


Feat/cluster autoscaler dashboard

this will ad a default autoscaler dashboard for grafana.

Is this in use somewhere?


digraph_union fails if merge_edges is set to true

Information

retworkx version: main
Python version: Any
Rust version: Any
Operating system: Any

What is the current behavior?
If merge_edges arg is set to True, digraph_union returns wrong output. This happens in many cases (e.g graphs with node holes, mismatch edge weights) and this means we need to rework the logic of the function.
What is the expected behavior?
Fix this.
Steps to reproduce the problem
An example where an edge is deleted when it shouldn't since edge weights don't match:
import retworkx as rx

first = rx.PyDiGraph()
nodes = first.add_nodes_from([0, 1])
first.add_edges_from([
   (nodes[0], nodes[1], 'a')
])

second = rx.PyDiGraph()
nodes = second.add_nodes_from([0, 1])
second.add_edges_from([
    (nodes[0], nodes[1], 'b')
])

final = rx.digraph_union(first, second,
                         merge_nodes=True,
                         merge_edges=True
)
print(final.weighted_edge_list())
---
WeightedEdgeList[(0, 1, a)]

An example with node index hole where an edge is not deleted but it should be removed.
import retworkx as rx

first = rx.PyDiGraph()
nodes = first.add_nodes_from([0, 1])
first.add_edges_from([
   (nodes[0], nodes[1], 'a')
])

second = rx.PyDiGraph()
dummy = second.add_node('dummy')
nodes = second.add_nodes_from([0, 1])
second.add_edges_from([
    (nodes[0], nodes[1], 'a')
])
second.remove_node(dummy)

final = rx.digraph_union(first, second,
                         merge_nodes=True,
                         merge_edges=True
)
print(final.weighted_edge_list())
---
WeightedEdgeList[(0, 1, a), (0, 1, a)]

Oh, actually i'm a bit confused now. I was ready to push a fix for this but then i realized i am not sure what's the expected output for this function. I was under the impression that merge_edges=True makes sense only if you set merge_nodes=True which in this case means "if two nodes of the second graph are connected by an edge and got merged into nodes of the first graph, do not add an extra edge if the last nodes have an edge with equal weight data". But we have a test case where this assumption does not hold: https://github.com/Qiskit/retworkx/blob/main/tests/digraph/test_union.py#L34
@mtreinish Any input on this?

Yeah, I'm not sure exactly what the intent there is, based on that test it looks like it combines the edges if they're between nodes with the same weights and they have the same edge weight. Which seems a bit unexpected, like if the nodes aren't combined how do we know which edge to keep (just the first graph's)?


[Hotfix][Core][Option] Temporary cancel validate duplicate logic

Purpose of this pull request

Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

@EricJoy2048 PTAL


using a local directory as source for images

this is a feature request about using a local dir as source for images.
instead of defining every image, it would be nice if you specify a dir with images and the script just load them.

But what if you don't want all images from that dir or images you want to show are located in separate folders ?

it's trivial to make links or just copy the ones you want in a new folder.
I think is lot easier than editing an HTML file everytime you want to add a new file.
but feel free to discard this request if you don't find it apropiate :)

Thank you for your feedback!
you can make changes to repo and push them if you think its better for repo itself, thanks!


Fix section 2 of issues#16875

This PR is an amendment for section 2 about issue #16875
For Section 1 and Section 3:

The revisions for section 1 have been merged to master
Section 3 was revised by Anuchandy in PR #22691

@jongio for notification.

@jongio Who should we ping to review this PR?

Hey @v-xuto, thank you for your contribution. I see that this issue is already been taken care of here - https://github.com/Azure/azure-sdk-for-java/pull/22694

@samvaity - Thanks for your reminder, we will close this PR.


[NEW ICON] Skill Name

Skill Name
navicat
Why?
Navicat is a database management software that is used by many developers and enterprises. It would be great if it could be added
Reference Image

I created a new project since this project is no longer updating & the author left it, navicat is available skills-icons
https://skills-icons.vercel.app/api/icons?i=navicat


Remove print statements

Hello,
Would it be possible to remove the print statements from all the requests?

Or hide it behind a debug paramter for the client

two prints replaced with LOGGER

Thank you very much. This will speed things up dramatically!


Keep kind order when disposing them

Retain the kind name and order even after disposing to keep the order
Related Issue: https://github.com/kadirahq/react-storybook/issues/482

This is cool. Get this.


Output to file (instead of inline)

Thanks a lot for this work!
I'd like to output the generated code to a file that I can bring under source control and then include!(..) the content of that file. It would require a few changes to this project. Would there be interest in merging a PR with this functionality, or should I just keep it in a fork?

I think its an interesting idea that I hadn't thought of.
Can you elaborate on what the benefits of that approach is? Since there is a 1-to-1 mapping from GraphQL schema to Rust code, wouldn't it be enough to commit the schema?

Yes I committing the schema is enough but right now this has manual effort (copying it from the compile output). Also juniper-from-schema has a lot of deps that increase the compile time even though we only need these deps at build time.
What I would like to do is create the schema in build.rs and commit it to source code. Then there is not manual effort to check what code was generated and you reduce the runtime deps.
This is also how the protobuf library (prost)[https://github.com/danburkert/prost] works.

Alright. I think it makes sense to implement this in a fork at first and re-evaluate once that is done.
Let me know when you have something that works. I'd love to take a look.

I'm going to close this since it isn't actionable. Feel free to reopen when you have something 😊


Support periods in connection names

Split connection names from second last period instead of from the first one when listing connections.

/gcbrun


Dump RedisResult response structures to console/log/JSON/etc.

RedisResult structures can be quite complex and counterintuitive to navigate initially (being nested lists of lists of different sizes).
To support rapid prototyping, there should be a convenient way to dump response structures to a human-readable format for inspection during early development and debugging phases.

I agree. One solution would be Implementing fmt.Stringer() on the RedisResult structure. The implementation would be similar to this:
https://github.com/redis/rueidis/blob/47c3d7c027ff8b212885c5fa5378bbb687bc36fb/message.go#L1027-L1063

Thanks for the tip, @rueian! I'll see if I can work something up for my own needs. Hopefully I come back soon with a PR!

Thanks @derekm! I am really looking forward to it.

Hi @derekm, hope you are doing well. Would you be still interested in implementing this feature?


It's not clear how to actually start using this plugin

The entry page starts with a video, and the header underneath says
Will output this markdown:
But what is it that will output this markdown?
When I go through the command pallette when in any note and toggle mindmap, nothing happens.
When I copy/paste the markdown from your website, I can make it work, but I don't understand how I can get to that view with my own notes.

add yaml to your md file
---
mindmap-plugin: basic
---

notice :  the content of your md file should match the demo
# mindmap root

## node 1
- test 1
   - test 1.1
- test 2
   - test 2.1

## node 2
- test 1
- test 2

Huh, ok.  It would be good to spell out on the homepage that at a minimum, you need that particular frontmatter tag and value.
Compared to the other mindmap plug-in, why is this necessary? The other one just gives you a view that visualizes whatever note you have open as a mindmap.  What stops this plug-in from working similarly without the tag?


feat: update job name to use metadata

Issue #, if available:
Description of changes:
Ensure the BDK doesn't use assumptions about the ARN format for jobs. Name is now extracted from metadata instead of being parsed from the ARN.
Testing done:
Unit and integ tests passing.
Merge Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.
General

[x] I have read the CONTRIBUTING doc
[x] I used the commit message format described in CONTRIBUTING
[x] I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

[x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[x] I have checked that my tests are not configured for a specific region or account (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

As job name and arn are still coupled. The move to the new pattern matching could introduce testing gaps. We could take the test changes as a follow up for full UUID support.


[Question] Usage

Is this only for Photoshop? Or can I copy from desktop image and edit as text?

For now the code only sends the image to Photoshop but it should be rather trivial to swap to another editor. In fact, a few people have mentioned working on a GIMP integration.
To edit as text you probably will have to add an extra step of OCR.


Default ingress annotations on global cannot be overridden

The current annotations for the global ingress are set as follows
https://github.com/pingidentity/helm-charts/blob/9f5b096600279c835b91b7fb91ca90754ea0e5a8/charts/ping-devops/values.yaml#L39-L41
We have found that if these are not appropriate for the environment and we need to have our own ingress annotations block, these pre-seeded annotations are mixed with the new ones, causing failure.
E.g, if we set the following in our values file (notice we've removed the ingress class and changed the name of backend-protocol annotation):
annotations:
      ingress.kubernetes.io/backend-protocol: HTTPS

we get the resulting definition, which causes a failed ingress:
│ Annotations:                     ingress.kubernetes.io/backend-protocol: HTTPS                                    │
│                                  kubernetes.io/ingress.class: nginx-public                                        │
│                                  meta.helm.sh/release-name: [obscured]                                                │
│                                  meta.helm.sh/release-namespace: [obscured]             │
│                                  nginx.ingress.kubernetes.io/backend-protocol: HTTPS                              │

It may be best to unset the default annotations as such:
annotations: {}
    #  nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    #  kubernetes.io/ingress.class: "nginx-public"

@patrickcping and I talked and agreed that we should take these default annotations out and provide documentation around this, should the deployer be using the nginx controller.

Close with release 0.3.2


Update http4s-blaze-server, http4s-circe, ... to 0.21.24

Updates

org.http4s:http4s-blaze-server
org.http4s:http4s-circe
org.http4s:http4s-dsl

from 0.21.1 to 0.21.24.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Applied Migrations

dependency:v0_21@org.http4s:http4s-scalafix:0.21.5

Documentation:

https://github.com/http4s/http4s/releases/tag/v0.21.5

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

labels: library-update, semver-patch, scalafix-migrations

Superseded by #318.


Bug when rendering emojis

It does render them but flashes this symbol before rendering them

then turns to the emoji

code: CoolName.jsx:

tailwind.config.js:

Thanks for the pickup, I haven't actually tested this with Emojis before so I'll have to investigate to see what's going on.


prefix naming method is not work for peer macros applied to extensions

Description
peer macro  applied to extensions does not take effect when using the prefix for introducing declarations.

Steps to Reproduce
No response

This issue is also encountered when using peer-to-peer macro generation protocols


Change the KUDO namespace Overwrite semantic.

What would you like to be added:
Currently, KUDO always overwrites resources' namespace consistently, using either the namespace from --namespace or the default namespace if not specified. We want this to be changed.
The expected semantic is as following:

KUDO never overwrites any resource's namespace. If not specified, use the operator's namespace.
KUDO operator builders are recommended to always define the namespace for each of their resources as {{ .Namespace }}.
If any resource has its namespace hardcoded, e.g., namespace: gilbert, KUDO should respect it. Return an error if any namespace not existed.

Why is this needed:

The current semantic is not ideal for any operator which manages resources in multiple namespaces.
Always-Overwriting semantic would disallow kudo operator developers to enforce any hard-coded namespace to any group of resources.

NOTE:
This request will not be backward compatible, but I believe this is a good move for the future. We can introduce a configuration flag for the deprecation cycle.

@Gilbert88 based on todays meeting... we do NOT anticipate supporting this request.  To support honoring namespaces defined in manifests in the KUDO operator is to support multiple namespaces which after significant discussion we are not able to do until we support cluster-wide resource management.
Put another way... we would like to support this request, but there is a lot of infrastructure to support before we can.
We can discuss more on thurs in our working meeting... (or anytime individually)


[instrumentation-python] context attributes propagation for bedrock

Closed by https://github.com/Arize-ai/openinference/pull/433


Implement single-project "super-build"

The cloe packages are distributed individually, and nominally have been developed individually, despite always being released with a unified version. Unfortunately, Conan does not provide good tooling for developing in a workspace of federated packages, and the workflows that we've had to use have made development iteration complicated, longer, and more tiring than they need to be.
This PR converts the cloe package from a meta-package to a super-build containing all other packages.
A new package, cloe-meta, takes the role that the previous cloe package took.
Questions:

[ ] What happens if someone uses cloe and another package that cloe provides? This was fine in the past, but I think it will not work anymore.
[ ] Should we even have cloe-meta? Because of Conan v1 limitations, it's not even useful as a lockfile recipe, which is what I intended to use it for.

Note: If you try to use cloe and something that it provides, such as cloe-runtime in a same recipe, then you will get:
  ERROR: At least two recipes provides the same functionality:
   - 'fable' provided by 'cloe/0.23.0-next@cloe/develop', 'fable/0.23.0-next@cloe/develop'
   - 'cloe-runtime' provided by 'cloe/0.23.0-next@cloe/develop', 'cloe-runtime/0.23.0-next@cloe/develop'
   - 'cloe-models' provided by 'cloe/0.23.0-next@cloe/develop', 'cloe-models/0.23.0-next@cloe/develop'

I'm not sure how it is if packageA requires cloe and packageB requires cloe-runtime.

I'm not sure how it is if packageA requires cloe and packageB requires cloe-runtime.

I added such a test-case and documented the results.


R18 file name tag is being ignored

Prerequisites

[x] Did you read FAQ section?
[x] Did you test with the latest releases or commit ?

Description
[Description of the bug or feature]
It seems the %R-18% tag for filenames is being ignored.
Steps to Reproduce

[First Step]
I've set up my filepaths like this:

filenameformat = %member_id%-%artist%\%R-18%\%urlFilename%
filenamemangaformat = %member_id%-%artist%\%R-18%\%urlFilename%
filenameinfoformat = %member_id%-%artist%\%R-18%\%urlFilename%
filenamemangainfoformat = %member_id%-%artist%\%R-18%\%urlFilename%

[Second Step]
Then download all my bookmarks via mode 6.

[and so on...]

Expected behavior: [What you expected to happen]
Each Artist folder should contain up to two subfolders based on if the images are R18.
Actual behavior: [What actually happened]
Images are placed directly within the artist directory. Completely skipping the %R-18%/.
Versions
Latest Release

please upload the log file?
It should only create R-18 directory if the image has tag with R-18 or R-18G.
https://github.com/Nandaka/PixivUtil2/blob/master/PixivHelper.py#L225-L230

pixivutil.log

Actually reading your answer again and checking the results. The documentation gave me the impression that a non r18 folder would be created. But I'm guessing the path for that resolves to something//something instead, and windows just ignores redundant slashes.


Question: How to enable the autocompletion support of the pkgs besides Glib

The addon now cannot treat using Gee correctly and treats it as an error The namespace name Gee' could not be found`, is there any way to enable the autocompletion support?

The language server needs to understand the compiler flags for your source file(s). Gee could be a namespace belonging to anything. Therefore, you need to tell VLS to use --pkg gee-0.8, either by specifying this in your meson.build file in the project root dir or by putting #!/bin/env vala -S --pkg gee-0.8 at the top of your file.
For more information, please see the "important note": https://github.com/vala-lang/vala-language-server#editors

The language server needs to understand the compiler flags for your source file(s). Gee could be a namespace belonging to anything. Therefore, you need to tell VLS to use --pkg gee-0.8, either by specifying this in your meson.build file in the project root dir or by putting #!/bin/env vala -S --pkg gee-0.8 at the top of your file1.
For more information, please see the "important note": https://github.com/vala-lang/vala-language-server#editors
Footnotes

Generally you'd only do this if your source file is a Vala script. leftwards_arrow_with_hook

Thank you for your explanation! It works now.
I didn't know vala can also support JIT before. This is really a useful feature.
Something else, the arg. -S may need to be passed at first for env to recognize.

@wszqkzqk right, the -S comes after env and before vala.
This is not JIT'ed code by the way, since it's not compiled piecewise or with no optimizations. It's not interpreted at all---Vala just compiles the whole file into a temporary executable and runs that.

@wszqkzqk what does VLS say? Are you mixing MSYS2 VLS with Win32 Meson?

@Prince781
I'm using meson and vls from msys2 usrt64, and the output was:
(vala-language-server:57008): vls-WARNING **: 09:16:23.030: mesonproject.vala:68: for target 25a6634@@gtkpacker-resources_c@cus, source #0, could not substitute special arg `DEPFILE'

(vala-language-server:57008): vls-WARNING **: 09:16:23.032: mesonproject.vala:339: target #5 (6199aec@@gtkpacker-pot@run) has no target sources

(vala-language-server:57008): vls-WARNING **: 09:16:23.032: mesonproject.vala:339: target #6 (6199aec@@gtkpacker-gmo@run) has no target sources

(vala-language-server:57008): vls-WARNING **: 09:16:23.032: mesonproject.vala:339: target #7 (6199aec@@gtkpacker-update-po@run) has no target sources

(vala-language-server:57008): vls-WARNING **: 09:16:23.045: compilation.vala:297: Compilation(25a6634@@gtkpacker@exe): file D:\17265\Documents\projects\GtkPacker\src\main.vala does not exist either on the system or in memory

(vala-language-server:57008): vls-WARNING **: 09:16:23.045: server.vala:326: Failed to build project - file D:\17265\Documents\projects\GtkPacker\src\main.vala does not exist either on the system or in memory

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.473: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.474: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.475: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.475: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.481: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.484: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.487: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.489: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.491: vala_symbol_get_name: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.501: vala_object_type_construct: assertion 'type_symbol != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:23.501: vala_interface_add_prerequisite: assertion 'type != NULL' failed

(vala-language-server:57008): vls-WARNING **: 09:16:23.531: server.vala:155: unhandled notification `initialized'

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.008: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.008: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.008: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.008: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.008: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.008: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.008: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.008: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.011: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.011: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.011: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.011: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.011: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.011: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.011: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.011: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.013: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.013: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.013: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.013: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.013: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.013: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.013: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.013: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.015: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.015: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.015: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.015: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.015: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.015: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.015: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.015: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.016: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.016: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.016: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.016: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.016: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.016: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.017: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vala-CRITICAL **: 09:16:24.017: vala_data_type_get_parameters: assertion 'self != NULL' failed

(vala-language-server:57008): vls-WARNING **: 09:16:24.543: compilation.vala:297: Compilation(25a6634@@gtkpacker@exe): file D:\17265\Documents\projects\GtkPacker\src\main.vala does not exist either on the system or in memory

(vala-language-server:57008): vls-WARNING **: 09:16:24.543: server.vala:749: Failed to rebuild and/or reconfigure project: file D:\17265\Documents\projects\GtkPacker\src\main.vala does not exist either on the system or in memory

(vala-language-server:57008): vls-WARNING **: 09:16:24.543: server.vala:326: Failed to rebuild/reconfigure project: file D:\17265\Documents\projects\GtkPacker\src\main.vala does not exist either on the system or in memory

@wszqkzqk please open a new issue on vala-language-server describing your problem with Meson on Windows. Also, please enable debug messages in the extension settings.


[Bug] Can't Open the Program after upgrading to 3.13.4

Checklist

[X] My issue was not mentioned by others, and it is not a duplicate issue.

Description
I can't open it. I upgrade the launcher by itself, and then the launcher can't be opened. When I look at the taskmgr, the program was in the list, then disappear, and then another starward.exe emerged, and after a few second, it disappeared.
Then I tried the version in Github Action, also failed with the same behaviour.
Note: the log below are the log before upgrading, after upgrading it doesn't generate any log at all.
Reproduction Steps
null
Expected Behavior
No response
Screenshots
No response
Starward Version
3.13.4
Windows Version
Windows 11 26120.2130, Insider Program 24H2
Log
[12:42:15.960] [INFO]
Welcome to Starward v0.13.3
System: Microsoft Windows NT 10.0.26120.0
Command Line: D:\Games\Starward_miHoYo_starter\app-0.13.3\Starward.dll

[12:42:15.990] [INFO] Starward.Services.DatabaseService
Database path is 'D:\Games\Starward_miHoYo_starter'

[12:42:16.021] [INFO] Starward.Services.DatabaseService
Database version is 11, target version is 11.

[12:42:16.153] [INFO] Starward.Pages.MainPage
Last game region is hk4e_global

[12:42:16.179] [INFO] Starward.Pages.MainPage
Navigate to "GameLauncherPage" with param hk4e_global

[12:42:16.913] [INFO] Starward.Pages.GameLauncherPage
Game install path of hk4e_global: "D:\Games\miHoYo\Genshin_Impact\Genshin Impact game"

[12:42:16.941] [INFO] Starward.Pages.GameLauncherPage
Acutal version and gamebiz of hk4e_global is "5.0.0".

[12:42:17.846] [INFO] Starward.Services.UpdateService
Start to check update (Preview: True, Arch: X64)

[12:42:18.655] [INFO] Starward.Services.UpdateService
Current version: "0.13.3", latest version: "0.13.4", ignore version: null

Additional Context
No response

I have also noticed this problem and have deleted the update and am looking for the cause of the problem.


Tables number codec: support "NaN", "Infinity", "-Infinity" for float, double CQL types

As per design documents, 64-bit double and 32-bit float CQL column types need to allow storing and access of a couple of "not-a-number" types:

"NaN" (for things like divide-by-zero result"
"Infinity" and "-Infinity" (for over/underflow) cases

These are tricky because JSON Numbers cannot represent such values: as such, codec needs to convert between JSON String values with specific constants to/from Java Double and Float constants used by C* CQL driver.
What needs to be tested:

(unit test) Ability for JSONCodec to properly convert these not-a-number representations into matching Double / Float constants
(IT) Ability to insert these NaN values into DB columsn
(IT) Ability to read (find()) such values stored in DB, get as expected JSON Strings

What do you think about representing NaN, Infinity, etc. as:
{
  "prop1": { "$NaN": true }
}

I don't necessarily like the idea of sending string "NaN" or "Infinity" over the wire, although I suppose that isn't terribly bad given that we know the schema type.

That would be another way to go about it -- I think that would probably be part of the "strict types" extension discussed as follow-up after initial release, where we'd add JSON Object wrapper around most if not all values.
And yes, sending String absolutely requires schema knowledge: something many/most types will need wrt "relaxed" (or "simple") values that we start implementation with.


[Proposal] set singleton mode in webview_flutter iOS

Column(
  children: [
    SizedBox(
      height: MediaQuery.of(context).padding.top,
    ),
    const Flexible(
      child: WebView(
        initialUrl: 'http://<IP_ADDRESS>:8800/',
        javascriptMode: JavascriptMode.unrestricted,
      ),
    ),
    const Flexible(
      child: WebView(
        initialUrl: 'http://<IP_ADDRESS>:8800/',
        javascriptMode: JavascriptMode.unrestricted,
      ),
    ),
  ],
),

There are two same webviews on the page, the code is very simple, that is get the value in localStorage every second and display it.
const App = () => {
  const [state, setState] = useState(localStorage.getItem('ttt') ?? 'none')
  const [time, setTime] = useState(0)

  useEffect(() => {
    /**
     * get localStorage every second and display it
     */
    setInterval(() => {
      setTime((t) => t + 1)
      setState(localStorage.getItem('ttt') ?? 'none')
    }, 1e3)
  }, [])

  return (

{time} seconds

{state}

        <button
          onClick={() => {
            localStorage.setItem('ttt', Math.random().toString())
          }}
        >
          add random
        </button>

  )
}

iOS Preview
The two webviews have the same initial value (this is correct), but when I update one of the values, the other does not update (but the timer can be seen to be working properly)
https://user-images.githubusercontent.com/8766034/144547583-a9ad2634-4c8a-445e-8b7f-320c4ddc3274.MP4
Android Preview
On Android devices, everything works fine
https://user-images.githubusercontent.com/8766034/144547986-14424868-4829-410b-b592-24e280e676d0.MP4
Other
iOS: 15.1.1
webview_flutter: 2.3.1
Flutter (Channel stable, 2.5.3, on macOS 12.0.1 21A559 darwin-arm, locale zh-Hans-CN)

I am not an iOS developer, and I found a solution saying that maybe this should be set to singleton mode

I found a piece of code on the Internet, and it is now behaving normally on iOS.
But I think webview_flutter should be set to singleton mode by default. Or at least give a configuration item. Because not every developer is an iOS developer, I am even a web developer.
So I didn't know that WKVebview would have such a weird situation.
For the standard Web specification, the localStorage between multiple webviews should be shared.

Hi @hellohejinyu, thank you for filing this issue.
I’m unable to reproduce the issue to confirm if having a singleton mode is required. I'll be labelling this for further investigation.

We really need the standard Web specification : the localStorage should be shared between multiple webviews.

https://github.com/flutter/plugins/pull/4869
I created a PR wihch implement a static WKProcessPoo. Issue seems fixed.

https://user-images.githubusercontent.com/8766034/158499136-9b016761-aefa-4e17-a4b6-d7e975c16156.MP4
@AleksandarSavic95 I haven't reproduced what you said here，Cookie does not behave abnormally on iOS. I suggest that you can turn on debugging of the webview and check what is missing.

@hellohejinyu thank you for your prompt and detailed answer!
After some additional tests, I am now 100% sure that I need to contact those external developers and ask them to set the expiration date for the cookies. If no expiration dates are set, the cookies are not restored the next time I start the app.
Thanks once again!

Per discussion in https://github.com/flutter/plugins/pull/4869, this is something that would need to be added as a client-configurable option, not an unconditional behavior, since sharing the process pool is not desirable in all cases.


train.py

Please publish train.py as soon as possible

Please tell me when it will be released

We just have released train_synapse.py. We will release others eventually.


Adding styles to the navigation, adding homepage

I was getting a bunch of warnings about unused imports, so I went through some of the files and removed unused imports. I'm pretty sure this will help speed up compile and reduce final package size.

we probably would need to remove the fake data before merge cc @austintgriffith @azf20 @ironsoul0 @sadda11asm

LGTM. We can merge.


Select property on MS PowerShell is not working a excepted

[Enter feedback here]
As per the belwo doc when you query the items through powershell you need add select parameter to the powershell command
It doesnt  work with out select
For example Get-MgUser -UserId $userId -Property "displayName,givenName,postalCode,identities"  this only retun the basci values like id,UPN ,mail,displayName
Get-MgUser -UserId $userId -Property "displayName,givenName,postalCode,identities" | Select displayName,givenName,postalCode,identities
https://learn.microsoft.com/en-us/powershell/microsoftgraph/use-query-parameters?view=graph-powershell-1.0#property-parameter
lot of customer getting confuse why the data fields are not bale to reterive

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

ID: e3162dd2-cc3e-64f1-757b-ab752a6320ac
Version Independent ID: d6551c10-ae06-eb82-c905-88ec2beb760a
Content: Get a user - Microsoft Graph v1.0
Content Source: api-reference/v1.0/api/user-get.md
Product: users
Technology: microsoft-graph
GitHub Login: @yyuank
Microsoft Alias: MSGraphDocsVteam

Thank you @nukala29 for raising this issue. Unfortunately, this forum is only for documentation-related issues for the REST API. For PowerShell issues, please file them in the Microsoft Grap PowerShell SDK repo.


[Single-Tech-Samples] - Purview - Sample 1

Existing purview sample has been moved to sample1_ms_purview_in_mdw folder under the purview folder and this changes are in a branch called ydaponte/623-move-purview-sample-to-sample-1.

Could you please check if this content is still relevant? Purview had a long evolution in the meantime and we think that we might need to deprecate the sample if you confirm that the behavior driven by the sample is no longer necessary.
If the content is still relevant, could you please take a look to the branch and make a quick e2e test to make sure the functionality you implemented is still working as expected with the latest releases of Purview.

Closing issue as we have archived this sample


Force upgrade express to 4.19.2

JIRA link
Change description
Force upgrade express to 4.19.2
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

New PR has been created so this is not needed anymore


Remove eclipse plugin from Gradle build

Given you can't really import Gradle into Eclipse due to the major
limitations Eclipse has (Groovy, Kotlin, Spock, ...), simplify the
build scripts and the documentation to clarify that.

Thanks for removing something that is broken.
I did a quick check if there is anything else we can remove, and only found these imports :)
https://github.com/gradle/gradle/blob/69956050c26ffe0d1dff0cffb7c624a0b2a4645f/subprojects/tooling-api/tooling-api.gradle.kts#L22-L23
https://github.com/gradle/gradle/blob/69956050c26ffe0d1dff0cffb7c624a0b2a4645f/subprojects/tooling-api/tooling-api.gradle.kts#L18

Thanks fo catching! Fixed


Reducers

Into
Firstly, I'd like to say thank you to all involved in putting together this proposal to move a signals spec and standard forward. It's really exciting!
I've been working with signals in concept for over 4 years starting with a proof-of-concept library IronJS (https://ironjs.org). Now, we have many implementations and takes on signals each with unique capabilities and trade-offs.
I've recently been exploring minimalism for a signals API with the project called Flash (https://github.com/flash-js/core). It's take on signals is to consider them as just functions which can react to other functions.
It has "static signals", which hold cached value in memory, and it has computed signals. These are common semantics which other implementations have, and they appear to be included in the proposal.
Proposal
The one new, yet very powerful semantic, is the concept of what is being dubbed a "reducer signal". It is a computed signal, which references the previous value from the compute function. By referencing it's previous value, it requires memory and therefore makes it like a static signal in this respect. The ability for a signal to reference itself can enable a host of applications because it gives a computed signal a standard way to manage it's own life-cycle and state. With reducer signals, the ability to reduce any signal over time is trivial when it would other wise require multiple signals/hacks to accomplish. This additional API of self-reference is minimal for the gains it imposes.
I'll provide some examples of its use and applications for consideration in this proposal. Unless I have missed something in the spec, this is not yet included in the proposal.
Reducer API
const reducerSignal = on((prev = own(default)) => {
  return prev + dependency();
})

This signal reference it's previous value using own(). This function returns undefined or the default argument on the first invocation of the signal compute function. The following invocations of the compute function will result in the previous value of the prior compute function invocations. This self-reference is the defining characteristic of a reducer function and hence a reducer signal. A signal can reduce to a value over-time. This introduces a life-cycle (time factor) to the signal beyond just the momentary state declaration of a signal. The purpose of this design is to isolate such a time-based signal in an API that remains declarative and easy to reason about; otherwise, the complexity of such a thing can easily lead to more error-prone variants to achieve the same goal.
Life-Cycle Management
In this example, we illustrate how a self-reference can be leveraged for explicit life-cycle management/hooks.
const signal = on((cleanup = own()) => {
  cleanup()
  const id = setInterval(() => { ... } )
  return () => clearInterval(id)
})

This example illustrates how cleanup functions similar to the life-cycle event in React's useEffect could trivially be implemented. This implementation could be abstracted into a utility for convenience. It is not limited to a single life-cycle event because it can be extended with further complexity when the application requires it.
Control Flow
const batch = on((acc = own([])) => {
  if (acc.length === size - 1) {
    return [...acc, op()] // new batch of size
  }
  if (acc.length >= size) {
    // Start new batch using old batch reference
    acc.splice(0, acc.length, op())
  }
  // Return current batch
  return acc
})

const render = on(() => {
  paintEffect(batch())
})

In this example, we have a reducer of operations op() that are accumulated in acc for batch signal. Only when the batch reaches a length of size - 1 do we create a new array reference of length size operations and return it as the new value for batch. This triggers target signals downstream to re-compute over batch. Otherwise, we build on the current accumulator within the compute function for batch, resetting the size for a new batch until we reach a the size - 1 condition again to broadcast the new batch.
This is a useful pattern and control flow mechanism for signal graphs. I've yet to see API's the provide a way to trivially declare such control flow. This is one example of control flow which can be achieved with reducers. There may be other less contrived examples of this, but it is simply here to showcase the application that reducer signals have over the control flow aspect of a program's design.
Conclusion
I hope to have made a case for considering the capabilities of self-referencing signals and the use-case that derive from having them. I'd very much like to weigh out the pros/cons to such a proposal and any alternatives which achieve the same goals with less API overhead if there exists any such alternative. Otherwise, I strongly believe "reducer signals" to be a novel semantic too valuable to pass on within this standard's proposal.
Addendum: Note on Flash
The Flash library referenced is a work in progress and not a complete functional implementation of the proposals therein, yet. The goal of that project is to distill down the concept of a signal as a reactive function and the minimal API necessary to achieve that primitive.

This is a really interesting idea. Would it technically only require the Signal.Computed() callback to receive the previously computed value as an argument?

By referencing it's previous value, it requires memory and therefore makes it like a static signal in this respect

Technically it doesn't really require extra memory because the computed has to remember its previous value anyway.
IMO something like this can be easily implemented in userland, except if the system supports transitions, when the computed itself would need to support this I guess, as you can't just store the previous value in a random variable in the closure anymore if the graph can be forked and the same computation can kinda simultaneously have different values.

cc/ @shaylew Something to keep in mind as you explore transitions/forks.

In the case of forks/transitions, the computed would need to re-fire providing the new value. I guess the one thing here to consider is that the computed must be a pure function if relying on this heuristic, otherwise this will cause a world of problems (that's why React has had to double invoke effects).

This is a really interesting idea. Would it technically only require the Signal.Computed() callback to receive the previously computed value as an argument?

That's all it would require in the design proposed in this proposal. With Flash, a separate function was opted for because computed signals in Flash hold no cached value. Only when an explicit use of own is made, will the compute function hold a value. If Signal.Compute hold a value/memory footprint, then parameterization is feasible for the design of the spec's API. However, I would opt for consideration of cache-less/memory-less compute signals in the proposal.

By referencing it's previous value, it requires memory and therefore makes it like a static signal in this respect

Technically it doesn't really require extra memory because the computed has to remember its previous value anyway.
IMO something like this can be easily implemented in userland, except if the system supports transitions, where the computed itself would need to support this I guess, as you can't just store the previous value in a random variable in the closure anymore if the graph can be forked and the same computation can kinda simultaneously have different values.

In Flash, the compute does not need to hold onto it's return value; it is ephemeral by default and strictly a compute function. Accessing the value of a computed signal is to invoke it's compute function to derive the value, unless the compute function is a reducer.
I'm not familiar with transitions. Could you reference the discussion on transitions please?

In the case of forks/transitions, the computed would need to re-fire providing the new value. I guess the one thing here to consider is that the computed must be a pure function if relying on this heuristic, otherwise this will cause a world of problems (that's why React has had to double invoke effects).

I'd presume purity on compute functions is an inescapable matter. What sort of considerations has the proposal made to mitigate any potential foot-guns that an impure compute function may introduce that would otherwise be a step backwards if self-reference were to be included in the spec?

In Flash, the compute does not need to hold onto it's return value; it is ephemeral by default and strictly a compute function. Accessing the value of a computed signal is to invoke it's compute function to derive the value, unless the compute function is a reducer.

Here they work differently, if the value doesn't change between executions they don't tell their dependents to refresh themselves, and in order to know if the value actually changed they need to hold a reference to their old value. Like that's kind the whole point of a signal, a computed is just a signal that gets updated according to a function you give it.

I'm not familiar with transitions. Could you reference the discussion on transitions please?

I don't have any pointers about that unfortunately, the only stuff I know about transitions I've learned in Solid's discord, I haven't implemented this myself (it doesn't seem worth the complexity and chance of bugs, as code need to be written in a way that's save under transitions, which seems a major pain in the ass).

This is closely related to the "classic" functional reactive programming stuff, which is basically "circuits with a delay operator". It's a pretty clean/principled way to introduce state/history into a reactive system, although it does  move you away from from-scratch consistency in some respects.
...Unfortunately it kind of only makes sense for eager Computeds, not lazy ones. If you try to mix this with laziness, you get something that depends not only on the history of its inputs, but the history of when it was observed or not observed. Maybe eager Computeds would be useful for other reasons, in which case giving that type of Computed access to its previous value seems reasonable enough.
@EisenbergEffect Yeah, that's something I should keep in mind there -- a Computed that has observable effects isn't necessarily safe to clone/rerun in a speculative transaction, and having mutable state captured in the closure of a Computed is a common pattern for building some kinds of behavior like history-sensitivity.

...Unfortunately it kind of only makes sense for eager Computeds, not lazy ones. If you try to mix this with laziness, you get something that depends not only on the history of its inputs, but the history of when it was observed or not observed

I'm not sure I'm following the reasoning 🤔 Isn't what the last value of the computed is orthogonal to whether the computed is an eager one or not? I'm pretty Sure isn't going to ditch support for this once they switch to lazy computeds for example.

It's implementable for lazy computeds but it's no longer very well-behaved. A lazy computed only runs when someone reads it, so its previous value isn't determined solely by the history of its dependencies; you also have to know the history of when it was read to know which states it saw and which it skipped over.

I see 🤔 I guess at the end of the day something like that in some sense can ~always happen, if you have only eager computeds you are probably going to need a way to pause updates to not refresh things a million times unnecessarily when updating lots of signals, which creates a similar situation.

What is the benefit of laziness over eager?

The annoying thing here is it's still possible to write well-behaved lazy computeds that make some use of history, as long as the history doesn't affect their value (as defined by their own equals function).
For instance you might be building up an object piece by piece, and reusing pieces that would be the same as last time can let you avoid allocation, keep downstream computeds from having to recompute as often, or make the equality check cheaper.
This is very much not the original use case for reducers, though; "you can have the previous value, as long as you don't do anything with it that affects your output" makes for a tricky API and there's not much the framework can do to tell whether you're straying from the subset with clean semantics.

Here they work differently, if the value doesn't change between executions they don't tell their dependents to refresh themselves, and in order to know if the value actually changed they need to hold a reference to their old value. Like that's kind the whole point of a signal, a computed is just a signal that gets updated according to a function you give it.

A computed signal that doesn't cache its value would always impact its targets (downstream) unless you explicitly opt for this behavior and make it stateful.
const stateless = on(() => source())
const statefull = on(() => {
  own()
  return source()
})

The reason I chose this in the design for Flash is because you can have both patterns if you opt for stateless by default.
I'm curious as to the primary motivation behind "laziness" for signal implementations. It seems like a needless feature since any signal not worth running shouldn't be declared anyway. Laziness reverses the control-flow; why have it backwards like this?

I'm curious as to the primary motivation behind "laziness" for signal implementations.

I am curious why you need a signal if you don't want the laziness and caching?  Those are the two main benefits of this data-type.
If a Computed does not cache its value, then it must be always dirty.  If the abstraction isn't caching the value, then it can't know that it would, might, or would not change when re-calculated.  For example: what would the behavior be of new Signal.Computed(() => Math.random()) without a caching mechanism?
And as for laziness: I tried disabling this in our application just to see, and it increased the number of Computeds we calculate from 20,000 to 300,000.  Not to mention that that probably introduced "glitches" into those computations.  And we provably never used the computed value for anything "real".

I am curious why you need a signal if you don't want the laziness and caching? Those are the two main benefits of this data-type.

Control-flow and state management in a declarative style.

If a Computed does not cache its value, then it must be always dirty. If the abstraction isn't caching the value, then it can't know that it would, might, or would not change when re-calculated. For example: what would the behavior be of new Signal.Computed(() => Math.random()) without a caching mechanism?

It would be as you expect; always dirty. If a Computed caches its value, Math.random() would always cascade as a change down the graph aside from the slim chance that Math.random() === cachedValue. If it didn't have a cached value the behavior is idempotent.

And as for laziness: I tried disabling this in our application just to see, and it increased the number of Computeds we calculate from 20,000 to 300,000. Not to mention that that probably introduced "glitches" into those computations. And we provably never used the computed value for anything "real".

What sort of "glitches" would it introduce? I'm curious as to what you mean by glitches here.
Of course, every signal change propagating does the graph would case more computed calls.  I suppose in the event that an effect pulls at the end of the graph, it would be querying the graph backwards and grab the latest cached values that aren't dirty and recomputing dirty signals but stoping the traversal if the new computed value matches the cache?
This means that in a lazy-based system, not all signal changes necessarily have an effect on the system unless it directly changes the target signals downstream all the way to the endpoints (effects). How is this different from a push system which will also propagate changes downstream and stop at identical values to nodes which have a cached value?


Ingest versions

zipline ingest can downgrade the assets db
This lets us publish an "old" db version for the most recent release of zipline, using the latest code base.

Coverage increased (+0.3%) to 86.462% when pulling ba14bf01bf105e2d296655ea445f2f26f0a15cb5 on ingest-versions into 82436aa54845ef9cf718ff49ba82e0634f3282ce on master.

Coverage increased (+0.3%) to 86.462% when pulling ba14bf01bf105e2d296655ea445f2f26f0a15cb5 on ingest-versions into 82436aa54845ef9cf718ff49ba82e0634f3282ce on master.

Coverage increased (+0.1%) to 86.34% when pulling 4bcb5f898c35d329479265c1e061efe7d6c8ace4 on ingest-versions into eba78aec1bb869c73bf930dccd1fe676669ff74d on master.

Coverage increased (+0.1%) to 86.29% when pulling f4ad4c261faae05816201187eebb9e0be2e1290a on ingest-versions into a788191b8e919cc30eec14fdebd712024eac8c96 on master.

Coverage increased (+0.1%) to 86.29% when pulling 317c5f07ccf10f2037343eb1577505b8454ef29c on ingest-versions into a788191b8e919cc30eec14fdebd712024eac8c96 on master.


Size-limit template parameters

Templates have a field called parameters of type bytes. A user can create a template with parameters of arbitrary length and use that to make a request to a provider, and the provider would then have to fetch that. Should we limit the size of this field during creation (with a hardcoded limit)? We don't want to limit the potential uses of this field either.

This is resolved by
https://github.com/api3dao/airnode/blob/48330b3266a153d26a99dc62a0e2ad001ce26f63/packages/node/src/evm/templates/template-fetching.ts#L56


OSX-ARM64: 0.13.0 cross zig

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Reorganized builds into separated scripts. osx-arm64 is integrated to the new PR: https://github.com/conda-forge/zig-feedstock/pull/38


Editing environment variables for normal user (non-admin) requires UAC prompt

Microsoft PowerToys version
0.77.0
Installation method
GitHub
Running as admin
No
Area(s) with issue?
Environment Variables
Steps to reproduce
PowerToys installed machine wide with a local admin user.
PowerToys started with normal user (non local admin).
When I enable environment variables and click on Launch Environment Variables the UAC prompt pops up and then I can only manage my variables for the local admin user but not for the normal user.
"Launch as administrator" is greyed out - but shouldn't. When I click on it, the UAC prompt should pop up and ask for my local admin user and then I can edit the local admin user variables AND system variables.
✔ Expected Behavior
I should be able to edit my environment variables for the normal user.
When I call "C:\Windows\System32\rundll32.exe sysdm.cpl,EditEnvironmentVariables" I can edit my normal user variables only.
When I call "C:\Windows\System32\rundll32.exe sysdm.cpl,EditEnvironmentVariables" with "Run as administrator" the UAC prompt pops up and then I enter my local admin user and I can edit the local admin user variables AND the system wide variables.
❌ Actual Behavior
When I enable environment variables and click on Launch Environment Variables the UAC prompt pops up and then I can only manage my variables for the local admin user but not for the normal user.
"Launch as administrator" is greyed out - but shouldn't. When I click on it, the UAC prompt should pop up and ask for my local admin user and then I can edit the local admin user variables AND system variables.
Other Software
No response

Just tried it today again and it works as expected. Mysterious.