How to Fight the Unknow_Java Call Stack

My hbase process consumes a lot of CPU (48 core physical machine, cost 4800% cpu_user). When I use async-profiler to locate the problem, I find a lot of unknown_Java occupation. In addition, other stacks show up normally. What's good Solution, can unknown_Java display its corresponding call stack?
I started under the root user, and the startup command was:
./profiler.sh -d 30 62663
The version used is:
async-profiler-1.6-ea-linux-x64.tar.gz
The kernel version is:
uname -a
Linux XXX 3.10.0-327.el7.x86_64 # 1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
Analysis results:
Started [cpu] profiling
--- Execution profile ---
Total samples: 135166
unknown_Java: 103087 (76.27%)
not_walkable_Java: 34 (0.03%)
skipped: 68 (0.05%)
Frame buffer usage: 6.7833%
---<PHONE_NUMBER>937 ns (75.90%), 102552 samples
  [0] [unknown_Java]
---<PHONE_NUMBER>1 ns (1.47%), 1988 samples
  [0] org.apache.hadoop.hbase.KeyValue $ KVComparator.compare
  [1] java.util.concurrent.ConcurrentSkipListMap.cpr
  [2] java.util.concurrent.ConcurrentSkipListMap.findPredecessor
  [3] java.util.concurrent.ConcurrentSkipListMap.doPut
  [4] java.util.concurrent.ConcurrentSkipListMap.put
  [5] org.apache.hadoop.hbase.regionserver.CellSkipListSet.add
  [6] org.apache.hadoop.hbase.regionserver.DefaultMemStore.addToCellSet
.......
          ns percent samples top
  ---------- ------- ------- ---
1024431079937 75.90% 102552 [unknown_Java]
<PHONE_NUMBER>4 2.17% 2932 org.apache.hadoop.hbase.util.Bytes $ LexicographicalComparerHolder $ UnsafeComparer.compareTo
<PHONE_NUMBER>1 2.12% 2867 org.apache.hadoop.hbase.KeyValue $ KVComparator.compare
<PHONE_NUMBER>0 1.71% 2305 org.apache.hadoop.hbase.KeyValue.getFamilyLength
<PHONE_NUMBER>3 1.08% 1453 org.apache.hadoop.hbase.util.Bytes.toShort

If anyone can help explain how unknow_Java was formed, thanks a lot.

Jvm Version:
1.8.0_121
JVM Options
java -Dproc_regionserver -XX:OnOutOfMemoryError=kill -9 %p -XX:MaxDirectMemorySize=80G -XX:+HeapDumpOnOutOfMemoryError -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data1/hbase/logs/hbase.gc -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=512M -Xmx80g -Xms80g -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:G1NewSizePercent=2 -XX:InitiatingHeapOccupancyPercent=65 -XX:+ParallelRefProcEnabled -XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -XX:MaxTenuringThreshold=15 -XX:G1HeapRegionSize=32m -XX:G1MixedGCCountTarget=64 -XX:G1OldCSetRegionThresholdPercent=5 -XX:MaxDirectMemorySize=85G -verbose:gc -XX:+PrintGCDetails -XX:+PrintAdaptiveSizePolicy -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution -XX:+PrintGCTimeStamps -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:LogFile=/data1/hbase/logs/compile.log -Dhbase.log.dir=/data1/hbase/logs -Dhbase.log.file=hbase.log -Dhbase.root.logger=INFO,RFA -Dhbase.security.logger=INFO,RFAS org.apache.hadoop.hbase.regionserver.HRegionServer start

This is indeed strange.
Seems like you use early access version of async-profiler. What about the latest 1.6?
Also, what exactly JDK build are you running?
java -version
java -Xinternalversion

Does profiling work with other apps? E.g. does make test complete successfully?

The version what i used is the latest version: async-profiler-1.6-ea-linux-x64.tar.gz .
java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
java -Xinternalversion
Java HotSpot(TM) 64-Bit Server VM (25.121-b13) for linux-amd64 JRE (1.8.0_121-b13), built on Dec 12 2016 16:36:53 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)
profiler with simple test Of test/Target can't found unknow_Java.
result is :
ns  percent  samples  top

7181012427   36.35%      718  Target.method1
7141017335   36.15%      714  Target.method2
379955071    1.92%       38  jni_SetObjectArrayElement
300028775    1.52%       30  jni_invoke_nonstatic(JNIEnv_, JavaValue, _jobject*, JNICallType, jmethodID*, JNI_ArgumentPusher*, Thread*)
260388687    1.32%       26  filldir[k]
259997139    1.32%       26  java.lang.StringCoding$StringDecoder.decode
209974560    1.06%       21  HandleMarkCleaner::~HandleMarkCleaner()
199994198    1.01%       20  jni_DeleteLocalRef

I'll try to investigate. But this will be probably hard without a test case. If you manage to get a self-contained example that I can reproduce on my side, this will be very helpful.

I've built an experimental version with the special treatment of unknown_Java samples.
Please, give it a try and tell if the things get better.
Please also send the stacktraces containing unknown_Java to me for the further investigation.
Thanks.
Here is the new build: async-profiler-1.6-special-linux-x64.tar.gz

I'm also having an issue identifying unknown_Java stacks with the latest release. I'm not sure if my issue is related, however, below you will see a zoomed in part of a flame graph by thread (using -t async-profiler switch), but what I find strange is that the Thread.run() method is not taking up the whole of the T-EventHandlingThread-1 function, and furthermore, there is nothing else occupying the remaining space. I assumed that the empty space should have been taken up by some unknown_Java stack after looking at a summary file.

I then used the special build you created and it appears as though I can now see unknown_Java stacks as shown in the second flame graph. Please excuse my ignorance, but are those unknown_Java stacks due to JIT compilations or something else? Also why would the unknown_Java stacks be above T-EventHandling-Thread-1? Should it not be somewhere above Thread.run()?

P.S. Great job with async-profiler. It's been very helpful in finding problems.

@kpdsquare unknown_Java denotes the cases when Java code was running, but VM wan't able to traverse the stack (possibly because of the non-standard stack frame layout or a frame in some transition state). I'm not sure about the reasons, so this is where I need your help (since I've fixed almost all unknown_Java cases observed in my own experiments).

Are there the same unknown_Java samples when running application on a different Java version?
What are the methods above unknown_Java in the flame graph?
Does the amount of unknown decrease or increase, if run Java with -XX:-TieredCompilation or -XX:TieredStopAtLevel=1?

Are there the same unknown_Java samples when running application on a different Java version?

Do you mean on a different major version or an update version? I'm currently using the following Java build:
java -version
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
Testing a later major version of Java might take a little longer for me to test. Let me know if this is what you want and I'll see if I can find the time to modify our environment for Java 11.

What are the methods above unknown_Java in the flame graph?

Above the T-EventHandlingThread-1 frame, I'm getting a small not_walkable_java frame (circled in blue below) and then the unknown_Java frame. Above the unknown_Java frame I see a frame pointing at my own application code. Above the unknown_walkable_frame I get an unknown frame which calls __clock_gettime.

Does the amount of unknown decrease or increase, if run Java with -XX:-TieredCompilation or -XX:TieredStopAtLevel=1?

In my case I was not getting many unknown frames in the first place (around 1.8%-2% from the summary), however, my issue did feel related, so I'm not sure if the following results are going to be helpful.
These tests are with the special build (1.6-special):
A1: My run with -XX:-TieredCompilation displayed an unknown_Java frame above the T-EventHandlingThread-1 frame, then a small unknown frame and my application frame above.

A2: My run with -XX:TieredStopAtLevel=1 displayed an unknown_Java frame, an Iterable.foreach and a Thread.run frame above the T-EventHandlingThread-1 frame. Above the unknown_Java frame there is a small unknown frame and my application frame.

These tests are with the latest release build (1.6):
B1: My run with -XX:-TieredCompilation displayed an unknown frame above the T-EventHandlingThread-1 frame.

B2: My run with -XX:TieredStopAtLevel=1 displayed the same frames as B1.

Thank you for the info. In fact, 1-2% of unknown frames are expected, since with asynchronous stack walking the top frame may sometimes appear in a transition/inconsistent state, when it is hard to recover the right call chain. But the problem is when unknown_Java takes more than 50% of the profile, like in the original issue.
Does your application frame (on top of unknown_Java) also appear in normal stack traces? Or does it always go together with unknown? It's unfortunate that this frame belongs to the proprietary code - it would be helpful to understand what kind of methods cause such unknown_Java situation. If you happen to see a method on top of unknown_Java, which code you may share, I'll be glad to analyse it.

I was expecting the low percentage of unknown frames to be expected, however, I only started seeing them in the flame graphs with the special build you created. So the special build solves the issue of at least being able to see the unknown frames in the flame graphs.
The application frame does appear else where, higher up on the stack (very close to the top)  in the flame graph. It might be of interest to you to know that the application frame of interest is a lambda reference for a BiConsumer, that is initialised in the constructor to avoid the BiConsumer being allocated on every call. This BiConsumer is passed to a Map.forEach() call very frequently (a few times every millisecond).
If this isn't enough information to decipher what is causing the unknown_Java, I can try and create some test code to replicate the scenario, which I would then be able to share. Might take a little while for me to get this done though given some time restraints I have.

To put the above into context, below is an obfuscated pseudo/example code of the method reference I think is causing the unknown_Java frames. Maybe this will be useful until I get around to writing some working example code I can share:
private final Map<ClassAEnum, Map<ClassBEnum, Config>> configMap;
private final BiConsumer<ClassA, ClassB> consumer;

public MyClass() {
	consumer = this:myMethodReference;
}

private void onSomeEvent() {
	// Use consumer on Map.forEach()
}

private void myMethodReference(final ClassA a, final ClassB b) {
	final P p = b.s().getP();
	final long dur = a.getDur();
	final Config config = configMap.get(a.getClassAEnum())
			.get(p.getClassBEnum());
	final double amt = config.getAmt();
	final long diff = (System.currentTimeMillis()) - b.r();
	final double ramt = b.ramt();
	b.sv(diff >= dur && Double.compare(ramt, 0) > 0
			&& M.check(ramt, amt, b.s().adp()));
}

@kpdsquare Thank you for the example. I bet in your case unknown_Java is mostly caused by System.currentTimeMillis.
System.currentTimeMillis as well as System.nanoTime are very problematic for reconstruction of async stack traces, since 1) they are JVM intrinsics that call native code without actually switching thread state to native; 2) the target native code does not follow normal frame linking pattern.
This is not a bug of async-profiler - this is just one of those cases when the stack state is not trace-friendly.
To verify that the problem is caused by System.currentTimeMillis, you may turn off the intrinsic with the following JVM options:
-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_currentTimeMillis,_nanoTime

So I realised some of the tests I did yesterday with the tiered compilation flags may have not been applied. For this reason I’ve redone the tests for completeness (see below) along with the intrinsic tests, even if you’re pretty certain of the reasons behind the unknown_Java here.
A summary of the tests from my perspective:

With the current 1.6 release build, I'm not even able to see the unknown_Java frames above the T-EventHandlingThread-1 frame. The special build fixes this for me, making it somewhat less confusing for me to see where the CPU cycles are going.
Disabling the intrinsics didn't appear to remove the unknown_Java in my test runs.
Disabling tiered compilation or stopping at tiered compilation level 1 didn't appear to make any difference.
I'm still uncertain if the unknown_Java frames are as a result of the System.currentTimeMillis as you suggested.

Are you going to merge the special build changes you've made into master?
These tests are with the special build (1.6-special):
A1: My run with -XX:-TieredCompilation displayed a small not_walkable_java, an unknown_Java, and a Thread.run frames above the T-EventHandlingThread-1 frame. Above the unknown_Java frame there are three frames: Intepreter, and two application frames, one of which is a reference to SomeClass$$Lambda$352/253733343.accept.

A2: My run with -XX:TieredStopAtLevel=1 displayed an unknown_Java and a Thread.run frames above the T-EventHandlingThread-1 frame. Above the unknown_Java frame there is a fpu2long_stub frame which calls into __clock_gettime.

These tests are with the latest release build (1.6):
B1: My run with -XX:-TieredCompilation displayed only the Thread.run() frame above T-EventHandlingThread-1 frame, with empty space beside it.

B2: My run with -XX:TieredStopAtLevel=1 displayed the same frames as B1.
These tests are with the special build (1.6-special):
C1: My run with -XX:+UnlockDiagnosticsVMOptions -XX:DisabledIntrinsic=_currentTimeMillis,nanoTime displayed an unknown_Java and Thread.run frame above T-EventHandlingThread-1 frame. Above the unknown_Java frame there is a call into my application frame referencing SomeClass$$Lambda$353/1767605733.accept.

These tests are with the latest release build (1.6):
D1: My run with -XX:+UnlockDiagnosticsVMOptions -XX:DisabledIntrinsic=_currentTimeMillis,nanoTime displayed the same frames as B1.
P.S. Thanks for taking the time to look into this.

@kpdsquare Thank you for the update. Looks like in your case the source of unknown_Java is not System.currentTimeMillis. Not sure what else it could be then. Will try to create a reproducer basing on your example.
Meanwhile I've commited the changes from the 'special' build into master.

@zhengzhuobinzzb I committed several improvements that should reduce the amount of unknown_Java frames. Can you re-check the latest version from master? For your convenience, I prepared a binary build, too: async-profiler-1.6-21af257-linux-x64.tar.gz

Not sure if this is related but I just found out that there's a very small percentage (~0.5%) of stack traces that don't contain Java frames but only native ones. This seems to be related to deoptimizations. What seems a bit strange is that this happens inside a java.lang.Thread, not a VM thread.
This is not a problem for my use case, just wanted to share these findings.
Some examples of the native frames in these cases:
TemplateInterpreter::deopt_reexecute_entry
vframeArrayElement::unpack_on_stack
vframeArray::unpack_to_stack
Deoptimization::unpack_frames
deoptimization

tiny_free_no_lock
free_tiny
Deoptimization::cleanup_deopt_info
Deoptimization::unpack_frames
deoptimization

default_zone_malloc
malloc
os::malloc
CHeapObj<
CHeapObj<
Deoptimization::fetch_unroll_info_helper
Deoptimization::fetch_unroll_info
deoptimization

@felixbarny Yes, this is an expected behavior. Deoptimization is a process of replacing Compiled frames with Interpreter frames right on the Java stack of a running application. This indeed happens in the context of the working Java thread: basically, JVM deliberately trashes the stack where it currently runs :) No surprise, that in the middle of this process the stack is not walkable.
This should not happen often in a normal application. It's safe to ignore such samples.


IVoiceChannel.ConnectAsync() doesn't returns anything?

When I'm trying to connect to voice channel, it doesn't make a return (variable still null).
audioClient = await SomeVoiceChannel.ConnectAsync();
await SendAsync(audioClient, pathToSoundFile)//System.NullReferenceException

There is a difference between "doesn't make a return" and "variable null"... Can you provide an MCVE?


BUG: curve_fit gives wrong results with Pandas float32

Describe your issue.
This issue is related to previous issues with curve_fit and float32, which were partially resolved in PR #10076. Incorrect fitting still happens when passing data as a float32 Pandas Series. Here is an example adapted from #2280.
Reproducing Code Example
import pandas as pd
import scipy.optimize as opt

def func(x, a, b): return a*x + b
x = np.array([0,1])
y = np.array([0,0])
p0 = [0.1, 0.1]
p1 = opt.curve_fit(func,            x , y, p0=p0)
p2 = opt.curve_fit(func, pd.Series(x).astype('float64'), y, p0=p0)
p3 = opt.curve_fit(func, pd.Series(x).astype('float32'), y, p0=p0)
print('\n p1 = ',p1,'\n p2 = ',p2,'\n p3 = ',p3)

Error message
p1 =  (array([0., 0.]), array([[inf, inf],
       [inf, inf]]))
 p2 =  (array([0., 0.]), array([[inf, inf],
       [inf, inf]]))
 p3 =  (array([0.1, 0.1]), array([[inf, inf],
       [inf, inf]]))

SciPy/NumPy/Python version information
1.8.0 1.22.3 sys.version_info(major=3, minor=8, micro=10, releaselevel='final', serial=0)

Hi @d-cogswell, thank you for reporting. Indeed I can confirm this is happening when using Pandas Series, but not with NumPy arrays. This is because the internal casting to float is only happening for array_like. See:
if isinstance(xdata, (list, tuple, np.ndarray)):
    ...

I am unsure what we could do here since we don't want to have Pandas specific code here. We should check why we don't try to use np.asarray all the time.

We don't use np.asarray for x because of the last part of this docstring:

xdata : array_like or object. The independent variable where the data is measured.
Should usually be an M-length sequence or an (k,M)-shaped array for functions with k predictors, but can actually be any object.

TLDR: this issue is down to calculations not being done in double precision, which is up to the user to ensure.

xdata is not converted to a np.float64 array because it's not a list, tuple or np.ndarray. We can't cast everything to np.ndarray because the user might want to supply a specific kind of object that they don't want to cast.
func is being supplied an x with a pd.Series of dtype=float32. Thus the output of a*x + b is calculated in single precision.
leastsq is probably changing aandb` with a step size designed for np.float64 operation, so there will be a large round off error resulting from that single precision calculation. (i.e. the jacobian can't be calculated properly).

This function works:
def func(x, a, b):
    x = np.asfarray(x, np.float64)
    return a*x + b

This function doesn't work:
def func(x, a, b):
    return np.asfarray(a*x + b, np.float64)

I don't think this is a SciPy bug (in as much as I don't think we should change the current behaviour), but it's probably worth updating the documentation. e.g. add something to the Notes along the lines of:
Notes
------
The user must ensure that all calculations are done in double precision, as the optimization process may fail on some inputs. Checks could include an `x` 'array_like' having a dtype of np.float64, making sure intermediate calculations in `func` are carried out in double precision, and that the `output` of `func` is in double precision.

I think it is not a very laborious task to squeeze in .to_numpy() explicitly for example
p3 = opt.curve_fit(func, pd.Series(x).to_numpy(dtype=np.float32), y, p0=p0)

is returning consistent results.

Sure. I think we're on the same page @ilayn, thinking that's the responsibility of user code?

Yes, we are slowly converging to the conclusion that handling array_like and other non NumPy arrays were not good design as it lead to many issues. If array is expected better to work with arrays to avoid lots of if else cases

Agreed 👍 thank you both for jumping in.
@d-cogswell Would you like to make a PR to maybe improve the documentation?

Personally, I would not use a warning. Some test suites are failing on warnings and it introduces some churn then for maintainers to filter out warnings if they would use something else. I think updating the doc is enough (we can make this clearer by having a note on the parameters' descriptions too)

I created PR #16173.


Add unit tests for addROI() and getROI()

We should add some simple tests for annotations, where we add ROIs to the viewer, retrieve them back and compare them for equality.
Something like:
const viewer = new DICOMMicroscopyViewer.api.VLWholeSlideMicroscopyImageViewer(...)
const circle = new DICOMMicroscopyViewer.scoord3d.Circle([1000, 1000, 1], 100);
const roi = new DICOMMicroscopyViewer.roi.ROI({scoord3d: circle});
viewer.addROI(roi);
const retrievedROIs = viewer.getAllROIs();
// assert that original and retrieved objects are equal, i.e. have identical coordinate values

Fixed at https://github.com/dcmjs-org/dicom-microscopy-viewer/commit/2ddefd823f9a921110e4e46fd4288f35eec3e46a

Nice. Thanks @biharck


install: conditionally push image to repository

conditionally tag-and-push a built image to the specified image repository, examples being:
minikube
gcr.io
PR Checklist

[ ] simple searchable title - [mds-db] Add PG env var, [config] Fix eslint config
[ ] briefly describe the changes in this PR
[ ] mark as draft if should not be merged
[ ] write tests for all new functionality

Impacts

[ ] Provider
[ ] Agency
[ ] Audit
[ ] Policy
[ ] Compliance
[ ] Daily
[ ] Native
[ ] Policy Author

@invertigo @mdurling with this patch tagging-and-pushing images is now invokable via the installer cli, eg:
note: assuming the images are already built (ie 'yarn build') one can tag-and-push the images to an image repository as follows:
% ./bin/install -c:image-repository=[repo-url] install:image

Please retarget this PR at @lacuna-tech/mds-core


🚀 Feature: Migrate away from cypress-plugin-snapshots

🔖 Feature description
Replace cypress-plugin-snapshots with cypress-plugin-visual-regression-diff in the techdocs-cli.
🎤 Context
cypress-plugin-snapshots seems to be unmaintained since some time back and pulls in at least one vulnerable transitive dependency (an old socket.io). Their own issues seem to refer to cypress-plugin-visual-regression-diff as a replacement.
✌ Possible Implementation
Seems to be a pretty straight forward replacement. There seems to be only two usages of .toMatchImageSnapshot in the cypress tests.
👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, I don't have time to work on this right now

Hi! I would like to try to fix this issue!
Have I understand the issue right that .toMatchImageSnapshot should be changed to .matchImage() in cypress-plugin-visual-regression-diff instead?

Not sure what the new syntax is! Haven't looked into it - but that sounds right.

@freben  I would like to contribute this issue plz assign me.

@sanjeev98kumar looks like @malin-mallan already has a PR for this: https://github.com/backstage/backstage/pull/14868

Okay
On Fri, Nov 25, 2022, 10:18 PM Andre Wanlin @.***>
wrote:

@sanjeev98kumar https://github.com/sanjeev98kumar looks like
@malin-mallan https://github.com/malin-mallan already has a PR for
this: #14868 https://github.com/backstage/backstage/pull/14868
—
Reply to this email directly, view it on GitHub
https://github.com/backstage/backstage/issues/14851#issuecomment-1327693236,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A3G47RM5UGE4WHK5GJA6H2TWKDUVXANCNFSM6AAAAAASLD4UKA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
The information contained in this electronic communication is intended
solely for the individual(s) or entity to which it is addressed. It may
contain proprietary, confidential and/or legally privileged information.
Any review, retransmission, dissemination, printing, copying or other use
of, or taking any action in reliance on the contents of this information by
person(s) or entities other than the intended recipient is strictly
prohibited and may be unlawful. If you have received this communication in
error, please notify us by responding to this email or telephone and
immediately and permanently delete all copies of this message and any
attachments from your system(s). The contents of this message do not
necessarily represent the views or policies of BITS Pilani.

Could someone take a look at my PR?

Hey! Taking a look today!

Could someone take a look at the PR again?

Closing as fixed in #15368


Loading a file as Document makes StartStyling() and SetStyling() break after text is inserted or deleted by user

https://github.com/HTD/TraxCodeEditor/tree/master/Test1
The test (Test1 project) uses signed ScintillaNET 3.5.0 from Nuget package.
It sets up 2 identical Scintilla instances, configures exactly one highlighting style, loads a short text into both instances but using different methods. The text using ASCII encoding to reject any encoding issues.
Left instance's text is loaded by assigning its Text property. Right instance's text is loaded using Scintilla.ILoader instance.
Both editors are set up to highlight the word "FOX" on each UI update.
Then I simulate of adding and deleting some characters from both editors. I delete all I insert, so the text in both editors should not be changed, and so their highlighting shouldn't change.
Expected behavior: identical text and highlighting on both sides.
Observed behavior: highlighting of the last line in the right editor is moved incorrectly.

I believe this is an issue with the native Scintilla component. I've opened a ticket for that team to take a look:
https://sourceforge.net/p/scintilla/bugs/1745/
To summarize, the delete notification doesn't appear to be working correctly when the text being deleted was added via the Scintilla.ILoader. You can verify this by watching the Scintilla.Delete event. The result is that the byte-to-char translation layer in ScintillaNET is getting out of sync.

So I've read the guy's answer. I added UndoCollection = true after loading document and now it works. I'm not sure, but it's probably not a bug, OR... Maybe ScinntillaNET should ensure UndoCollection is true in Document setter?
This seems like the right thing to do (in Document setter):
var ptr = value.Value;
DirectMessage(NativeMethods.SCI_SETDOCPOINTER, IntPtr.Zero, ptr);
DirectMessage(NativeMethods.SCI_SETCODEPAGE, new IntPtr(NativeMethods.SC_CP_UTF8)); // see issue #87
DirectMessage(NativeMethods.SCI_SETUNDOCOLLECTION, new IntPtr(1));


feature request - rotate image 90 degree

Would it be possible to implement also option to rotate image/stream 90 dregree (clockwise and anti-clockwise)?
Currently only 180degree is possible.

Sorry but it's not possible.
This class of settings is managed by Yi firmware.

ok, thx for checking.
I was wondering as with other webcams this is possible.


Update virtual-machines-windows-extensions-customscript.md

Hello. I cannot find anything that indicates how often the commands contained in the custom script extension are executed. Is it when the machine deployed? Is it ran each time the VM is rebooted? Is it run on a schedule? Can I force the extension to execute the commands it contains anytime I want? etc

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@RickFlist : Thanks for your contribution to the Azure documentation! The author, @neilpeterson, has been notified to review your proposed change.

@RickFlist : Thanks for your contribution to the Azure documentation! The author, @neilpeterson, has been notified to review your proposed change.

I've spoken with Rick offline on this.
#please-close


chore(browser): remove timing issues with restart and fork

remove .ready since forking should automatically return a browser
getNewDriver should return a promised WebDriver that can be awaited
fix interaction tests and local driver tests
update unit tests for async await due to getNewDriver fix

closes #5031

This appears to be having some problems. I thought it was something to do with a chrome and chromedriver mismatch. I'll have to find the culprit tests. This might take a while.

So this journey started out as a jasmine upgrade. And its no longer a jasmine upgrade. Maybe that can be the next step after this merge.

I think in this PR could be fixed interaction_spec, because there appears .ready() method

.ready is not a method but a property to a promise for the forked browser instance. This is a weird way to do it. Removing it makes sense.


Adding a browser-based inference client with streamlit + streamlit-webrtc

Hey guys, I love your work building a full-duplex foundation model!
I built a browser-based streaming inference client using streamlit + streamlit-webrtc. Hope you find it useful! Enjoy! 🎧

This is awesome - will review soon

Initial test gets Error: navigator.mediaDevices is undefined. It seems the current document is not loaded securely.
We use a standalone 4090 rack at the office so I haven't been able to test with localhost, which I assume is the issue. This is both with and without use_ice_servers. Will debug more later but lmk if you've seen this and know a fix.

Initial test gets Error: navigator.mediaDevices is undefined. It seems the current document is not loaded securely.
We use a standalone 4090 rack at the office so I haven't been able to test with localhost, which I assume is the issue. This is both with and without use_ice_servers. Will debug more later but lmk if you've seen this and know a fix.

@calculating hey, thanks for testing this out!
Microphone access by the webrtc component requires https if not connecting to localhost for security reasons. To get around this you can ssh into your GPU server with port forwarding ssh -L <IP_ADDRESS>:8501:remote-host:8501 user@remote-host and then connect to localhost as usual. I also pushed an update to the readme with a note on this workaround.

@neelr I committed your suggested title and instruction text, thanks again for the review!

@nicholascc can you review and merge if it looks good?


fix gluon bi-rnn cell single step unroll

Description
fix gluon bi-rnn cell single step unroll bug. resolves #15062
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[x] fix gluon bi-rnn cell single step unroll

@mxnet-label-bot add [Gluon, RNN]

@zhreshold the issue is tracked in #9686


refactor: fix active link on header menu item click

This PR fix the shadow of the active link when click on the header menu item.

:tada: This PR is included in version 1.10.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add Subset Regex to Benchmarks

From Microsoft's paper on their new derivative-based regex engine (RegexOptions.NonBacktracking):

Incidentally, the result for Rust further highlights the importance of avoiding outliers, as it would be a clear winner if not for the pattern [a-q][ˆu-z]{13}x. The crux of the pattern is that [a-q] denotes a subset of [ˆu-z] much like in the classical example a.{13}. This pattern is challenging for DFA based engines, as the loop can be entered multiple times, leading to a 2^13 factor in number of states. Optimizations in NonBacktracking have made this pattern no longer visible as an outlier.

It might be worthwhile including this case in the benchmarks.

Please link the paper.

That benchmark is in this repo. But it's not part of the curated set. Please see contributing guidelines for proposing a change to the curated set.

The paper is here. If it's already part of the repo, I'm not personally sure of whether it should be part of the curated set, I just thought it was an interesting case that might be worth testing.

All righty, now that I have hands on a keyboard, I took a look at this. I defined a new set of benchmarks based on this pattern and varied it a bit. I was in particular interested to see how perf change depending on two factors: whether Unicode mode was enabled and the size of the bounded repeat. Unicode matters here because it changes the meaning of [^u-z].
The first thing I did was compare the current release of the regex crate (1.10.2) with an older version (1.7.3). The older version is likely what was benchmarked in the paper, and it reflect the status quo of the regex crate before this year and before I effectively rewrote the entire crate.
$ rebar cmp tmp/results.csv -e rust/regex
benchmark                                   rust/regex          rust/regexold
---------                                   ----------          -------------
reported/i13-subset-regex/original-ascii    5.8 GB/s (1.00x)    442.4 MB/s (13.33x)
reported/i13-subset-regex/original-unicode  331.4 MB/s (1.00x)  15.9 MB/s (20.83x)
reported/i13-subset-regex/big-ascii         91.1 MB/s (1.00x)   9.5 MB/s (9.60x)
reported/i13-subset-regex/big-unicode       34.9 MB/s (1.00x)   13.9 MB/s (2.52x)
reported/i13-subset-regex/huge-ascii        15.6 MB/s (1.00x)   8.4 MB/s (1.86x)
reported/i13-subset-regex/huge-unicode      15.6 MB/s (1.00x)   12.4 MB/s (1.26x)

The patterns used are as follows:

*/original-*: [a-q][^u-z]{13}x
*/big-*: [a-q][^u-z]{23}x
*/huge-*: [a-q][^u-z]{80}x

Here, we can see that the latest version of the regex crate is universally faster. In some cases by a fair margin. But once you get up to the higher bounded repeat, perf levels out a bit and there isn't much difference. The reason for the difference, in very broad strokes, is:

It looks like the regex crate is now a bit smarter about the reverse suffix optimization, which gets triggered in the original-ascii case. That is, it looks for x and then does a reverse scan to look for a full match. Do note that sometimes the optimization fails. It has guard-rails built into it to avoid quadratic behavior. When this happens, it falls back to a standard forward scan of the lazy DFA. The lazy DFA is pretty fast, so this overall works well and stays fast.
The original-unicode case is like the original-ascii case. Except, when it falls back to the lazy DFA, the lazy DFA eventually gives up entirely and that in turn falls back to the PikeVM.
The big-ascii is like the original-unicode case. It attempts the reverse suffix optimization but that fails occasionally, and since the lazy DFA's cache is filled up quickly, it falls back to the PikeVM. Presumably this happens more quickly because of the bigger bounded repeat (despite the fact that ASCII is used).
The big-unicode, huge-ascii and huge-unicode benchmarks are more of the same. As the regex grows in size, the lazy DFA quits earlier and earlier. Until ultimately, a ceiling is hit and performance is dominated by the PikeVM.

Because of the delicate interaction with the suffix literal optimization, I added another benchmark using the pattern [a-q][^u-z]{80}[x\xE0-\xFF] and ran it on the regex crate:
$ rebar cmp tmp/results2.csv
benchmark                                           rust/regex         rust/regexold
---------                                           ----------         -------------
reported/i13-subset-regex/huge-ascii-nosuffixlit    15.4 MB/s (1.00x)  8.3 MB/s (1.85x)
reported/i13-subset-regex/huge-unicode-nosuffixlit  15.4 MB/s (1.00x)  12.7 MB/s (1.21x)

In this case, there are no literal optimizations. Performance is unchanged with the huge-ascii and huge-unicode benchmarks. This is actually great news, because it means that the literal optimization failing doesn't impact things too much here.
For the regex crate, one can largely "fix" this problem by giving the lazy DFA more cache. Potentially a lot more cache. It's a legitimate work-around, but the cost is more memory.
Now let's compare with some other engines. Given the .NET folks were the ones who published the paper, let's start there (this is .NET 8):
$ rebar cmp tmp/results.csv -e '^rust/regex' -e dotnet
benchmark                                   dotnet             dotnet/compiled     dotnet/nobacktrack  rust/regex           rust/regexold
---------                                   ------             ---------------     ------------------  ----------           -------------
reported/i13-subset-regex/original-ascii    12.9 GB/s (1.33x)  17.1 GB/s (1.00x)   11.8 GB/s (1.44x)   5.8 GB/s (2.96x)     442.4 MB/s (39.47x)
reported/i13-subset-regex/original-unicode  13.3 GB/s (1.39x)  18.5 GB/s (1.00x)   11.7 GB/s (1.58x)   331.4 MB/s (57.20x)  15.9 MB/s (1191.66x)
reported/i13-subset-regex/big-ascii         43.5 MB/s (4.22x)  183.4 MB/s (1.00x)  23.7 MB/s (7.75x)   91.1 MB/s (2.01x)    9.5 MB/s (19.34x)
reported/i13-subset-regex/big-unicode       43.5 MB/s (4.24x)  184.6 MB/s (1.00x)  22.0 MB/s (8.39x)   34.9 MB/s (5.28x)    13.9 MB/s (13.29x)
reported/i13-subset-regex/huge-ascii        39.1 MB/s (4.92x)  192.3 MB/s (1.00x)  24.5 MB/s (7.84x)   15.6 MB/s (12.34x)   8.4 MB/s (22.92x)
reported/i13-subset-regex/huge-unicode      39.1 MB/s (4.94x)  192.9 MB/s (1.00x)  24.6 MB/s (7.85x)   15.6 MB/s (12.38x)   12.4 MB/s (15.54x)

This is a rather good showing for .NET. The gap has been closed between regex 1.7 and regex 1.10, but still, the dotnet/compiled engine is doing quite well here. THe dotnet/nobacktrack engine does worse (is that what is being measured in the paper? it's a DFA right?), but still better than the regex crate when the regex crate cannot benefit from literal optimizations as much. I would be curious to understand a bit more what the dotnet engine is doing here. I don't know how to profile .NET programs on Linux. It at least seems clear that it's using literal optimizations in the original-{ascii,unicode} case, but not in the {big,huge}-{ascii,unicode} cases. I would be curious to find out why.
OK, let's zoom out a bit and get a broader picture of things:
$ rebar rank tmp/results.csv
Engine              Version           Geometric mean of speed ratios  Benchmark count
------              -------           ------------------------------  ---------------
perl                5.38.1            1.38                            6
python/regex        2023.10.3         8.89                            6
dotnet/compiled     8.0.0             11.54                           6
dotnet              8.0.0             35.16                           6
dotnet/nobacktrack  8.0.0             52.70                           6
hyperscan           5.4.2 2023-04-22  56.88                           5
pcre2/jit           10.42 2022-12-11  61.32                           6
rust/regex          1.10.0            93.04                           6
regress             0.7.1             145.23                          6
javascript/v8       21.4.0            219.38                          6
java/hotspot        21.0.1+12-LTS-29  258.92                          6
python/re           3.11.6            266.10                          6
icu                 72.1.0            385.06                          6
re2                 2023-11-01        409.14                          6
d/ldc/std-regex     2.105             438.12                          6
pcre2               10.42 2022-12-11  459.20                          6
rust/regexold       1.7.3             465.28                          6
d/dmd/std-regex     2.106             536.71                          6
go/regexp           1.21.5            676.16                          6

I was not expecting that! perl is usually quite slow compared to other engines, but it is doing amazingly well here. So is python/regex (which is also usually pretty slow).  My guess is that it has a specific optimization pass that is kicking in for this regex.
I had hoped that the bounded-repeat benchmark in the curated set would be enough to cover cases like this, but I think I'm wrong there. This particular regex exposes some very interesting behavior from the regex engines, and I think it might actually be a good candidate to move into the curated set because I don't think this is really covered by anything else in the curated set. Thank you for bringing this up.

Here are the benchmark definitions: https://github.com/BurntSushi/rebar/blob/f9a4f5c9efda069e7986a262efe8649aa78c0933/benchmarks/definitions/reported/i13-subset-regex.toml


Send double parameters with full precision

Sometimes doubles must be transferred with more digits than the Qt
default of 6. This increases the number of transmitted digits to the
maximum reasonable value (DBL_DIG).
Fixes #9

Thanks!


[FEATURE REQUEST] Enable global default default for cluster region in Kyma setup

Which area is mainly impacted
Configuration
Requested Feature
When provisioning a Kyma runtime in SAP BTP two regions need to be specified:

Region of subaccount
Region of cluster

There is no defaulting possible as the relation between subaccount region and cluster region is not unique. Currently the cluster region must be specified in the use case file.
It would be good to have the definition available in the parameters file to keep information in one place for basic setups.
Use Case/Scenario

Provisioning of a Kyma cluster
Definition of cluster region

Would you like to support us?

[X] Yes, I would like to support you

Anything else?
No response

In order to remain flexible concerning the cluster region, the flow should be:
If a definition for the cluster region is available in the use case file, this value will be used for the cluster
If there is no definition in the use case file, then the value from the parameter file should be taken as default.

Closed by PR #134


Add extra fields to the log entries

It appears from the current logs that is getting emitted from flagr is coming with certain fields pre-defined. Without making changes to the code / forking and putting our own version, is there a provision in the flagr service where a new field can be added to the log? We are planning to add something like "sourceContext" that will tell us which system (or instance) of flagr (as we host multiple instances) is emitting this log? Not picky on the field name and it can be anything but just looking for a technical provision if this is allowed.
Current: {"level":"info","measure#flagr.latency":3609700,"method":"GET","msg":"completed handling request","remote":"<IP_ADDRESS>:56178","request":"/api/v1/flags","status":200,"text_status":"OK","time":"2021-06-08T07:39:32Z","took":3609700}
Expected:
{"sourceContext": "blablabla", "level":"info","measure#flagr.latency":3609700,"method":"GET","msg":"completed handling request","remote":"<IP_ADDRESS>:56178","request":"/api/v1/flags","status":200,"text_status":"OK","time":"2021-06-08T07:39:32Z","took":3609700}

@gkkishan interesting, I'm wondering what could be use as an identifier to the machine/instance/container running...

There're 3 logging places I can think of

Flagr's verbose logging middleware to stdout https://github.com/checkr/flagr/blob/master/pkg/config/middleware.go#L43
Flagr's evalResult to stdout https://github.com/checkr/flagr/blob/master/pkg/handler/eval.go#L327
Flagr's evalResult to dataRecorder https://github.com/checkr/flagr/blob/master/pkg/handler/eval.go#L225

Each of them can be added with additional server-side logging context, from your description, looks like it's source 1. Things can be configurable via env variables, for example
FLAGR_SERVER_SIDE_LOGGING_CONTEXT='{"sourceContext": "blablabla", "region": "xyz"}'

And then the whole logging context will be merged into the logging body - may want to do it in a backward compatible way.
PRs are welcome!


Update dependencies, add code coverage, update linting

Update to latest dependencies,
Add Snyk vulnerability check,
Add linting rules,
Add editor config,
Add code coverage and rules, but don't enforce as a CI test yet,
Test on node 4 and 6

This looks fine but could you add something to the description after adding Snyk.

Looks good to me.

LGTM @gavboulton happy for you to merge this.


[Feature Request]: Custom-Built Exponent Client

Hi guys,
First off, love what you've done.  Expo is fantastic and will tremendously help get React Native in the hands of folks who otherwise would not have access to it.  I'd be remiss to not also mention its kickass developer experience.  So, high fives all around!
I noticed your tooling for the Expo Client is very close to how AppGyver implements their Scanner.  Same kind of concept -- the client already has the native entitlements the SDK expects, local dev environment has a utility to expose a port and QR code, the client QR code scan brings JS in, the app runs, and choirs of angels sing.
I saw that if you detach your native projects, it's basically back to "vanilla" React Native dev...which isn't terrible, but the Expo DX is so good that it will definitely feel like a downgrade.
I'm not sure if you guys have considered this, but AppGyver gave a "semi-escape hatch" for their Scanner.  Basically, you could build build custom versions of the scanner (in this case, the Expo Client) with whatever custom native libraries they have linked.  This would allow someone the latitude of "ejecting" and linking non-SDK libraries, but still have the DX of the AG Scanner.
Now, if I recall, it was definitely a little involved, as you basically had to create a distribution profile for iOS and keystore for Android, upload it to AG's infrastructure, and then have it build your Custom Scanner.  I feel like you could even automate that process, since I see the exp cmd line utility creates that stuff for me.
Anyway, TL;DR: A custom-built Exponent Client would be an amazing future feature for Expo, as there's definitely a lot of use cases that would require ejecting out of the "vanilla SDK".
Thanks again for your work, and I'm looking forward to using (and hopefully contributing back to) this ecosystem!
Eric

As far as I know, when ejecting from Expo, you still have access to all the goodies offered by Expo SDK, you only lose the build-related features, without ejecting publishing directly to the store is automated. So, not back to Vanilla RN for sure. I think this is ought to be clarified with the upcoming release this week in the docs section.

Correct @sonaye when you eject to ExpoKit, you keep almost all of the features offered by the Expo SDK. There are a few small things that are different right now - for example push notification don't work out of the box on Android.
@ericnograles does that make sense? Which part of the docs are confusing?

@jesseruder @sonaye totally makes sense, thanks.  And that's really what I was referring to was the awesomeness that is the Build Tooling.  To clarify, upon ejecting, you basically just have to manage it like a normal React Native app (Xcode/Android Studio) and can no longer do Expo.io Client magic, right?

Yes you need to use Xcode/Android Studio after detaching. Unfortunately not much we can do there, just a technical limitation.

Hi! We're tracking feature requests on Canny now, and I've created one there for this idea. Thanks!


Attempt to fix #9919 - Intersecting discriminated union breaks type narrowing

Fixes #9919.
This PR adds support for discriminating union types that are also intersected. As a side effect a type is now eligible for discrimination when it is a union or intersection - even if the discrimination property is not a union itself. This is to handle situations where the property type is narrowed by subsequent intersections.

Hi @gcnew, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

@ahejlsberg want to take a look?

@gcnew, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, MSBOT;

@gcnew Thanks for your contribution!
We're about to merge #9407 which contains a number of changes in this area, including optimizations to improve performance in code bases with large union types (100+ constituent types) such as would result if we convert the compiler itself to depend on these features. Merging that will undoubtedly affect this PR. Not sure if you've looked at that already.
One concern I have with incorporating intersection types is that I will cause even more types to be generated by narrowing operations, thus negatively affecting performance. Also, if we go beyond just the top level of union types we really should handle any arbitrary number of nested unions and intersections, e.g. ((A | B) & (C | D) | (E | F) & (G | H)). And of course we'd need to make sure that all the different kinds of narrowing are covered. It's definitely not a simple task.

@ahejlsberg Thank you for taking a look at this PR!
Yes, I'm following #9407 and I suspect that this code will not be compatible with what's to come.
I agree that complete support of arbitrary ADT/intersection blending will have memory and performance implications especially if done naively as I did here. On the other hand, this is what makes TypeScript more expressive than ML-like languages. If we can isolate the performance hit only for the rare users/use cases that consciously take advantage of this feature will that be an acceptable compromise? After all having type casts and vanished type-safety is arguably worse.

This behaviour is being implemented in https://github.com/Microsoft/TypeScript/pull/11717. Closing this one in favour of the latter.


clarify date comparisons when deleting old models/groups

Related Issues/PRs

#xxx
What changes are proposed in this pull request?
clarify date comparisons when deleting old models/groups
How is this patch tested?

[ ] I have written tests (not required for typo or doc fix) and confirmed the proposed feature/bug-fix/change works.

Does this PR change any dependencies?

[x ] No. You can skip this section.
[ ] Yes. Make sure the dependencies are resolved correctly, and list changes here.

Does this PR add a new feature? If so, have you added samples on website?

[x ] No. You can skip this section.
[ ] Yes. Make sure you have added samples following below steps.

Find the corresponding markdown file for your new feature in website/docs/documentation folder.
Make sure you choose the correct class estimators/transformers and namespace.
Follow the pattern in markdown file and add another section for your new API, including pyspark, scala (and .NET potentially) samples.
Make sure the DocTable points to correct API link.
Navigate to website folder, and run yarn run start to make sure the website renders correctly.
Don't forget to add <!--pytest-codeblocks:cont--> before each python code blocks to enable auto-tests for python samples.
Make sure the WebsiteSamplesTests job pass in the pipeline.

/azp run

Codecov Report

Merging #1733 (b004bce) into master (6ea02bd) will decrease coverage by 81.27%.
The diff coverage is n/a.

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


4.0 NavigationServer 2D issues.

Godot version: v4.0.dev.custom_build.6a683f801
OS/device including version: Mac Pro 2018/Big Sur (11.0.1)
Issue description: NavigationServer2D seems to have some issues with the following items from my testing and assumptions on how it should work.  My assumptions could, however, be totally wrong 😁

TileMaps:  Tiles with no navigation polygons seem to have "seams" that allow the pathfinding to plot a path along their borders, at least if they're a part of a tileset that has other tiles that are completely covered by a navigation polygon.  This is not a problem in  3.2 stable.

NavigationServer2D/Map doesn't seem to combine overlapping regions into a single navigation polygon.  It is my understanding from reading blogs/proposals about the new navigation system that that was one of the main feature of the new system 😄

NavigationServer2D seems to generate paths between two regions with a path that goes outside these regions.  I would expect this not to be the desired behaviour.

NavigationServer2D sometimes generates a visible inefficient path on what seems to be really straightforward path in Tilemaps.  This could be related to how TileMaps seem to generate its  navigation polygon

Steps to reproduce:
I attached the same project for 3.2 and 4 with this ticket.  It demonstrates what I assume are issues.  It's a simple 2d scene with a navigation2d node.  The node contains:

Two identical tilemaps that have navigation polygons in their tileset.  Overlapping the tilemaps is a navigation polygon. The tileset used has four tiles, two with no navigation polygons and two that are completely covered by a navigation polygon,.
Two identical navigation polygons.  Overlapping them both is a navigation polygon.
The good old godot sprite!

Right mouse button allows you to move the godot sprite to the current mouse position.
Left mouse button uses get_simple_path to draw a line from the current sprite position to the current mouse position

Positioning the sprite on one side of the white no navigation tile cluster on one of the upper maps and using the left mouse button to plot a path to the other side of the white cluster will create a path that travels along the seams of the white tiles in the 4.0 project.  This does not happen in the 3.2 version.
You cannot position the sprite on one of the "island" regions and plot a path to the other region that is/should be conntected to it by an overlapping navigationregion/polygon.  This is expected not to work in 3.2 but I thought is should work in 4.0
Plotting a path between the two lower "island" regions made of a single navigationpolygon plots a path that goes straight through the non navigation space between them. Happens in 3.2 and 4.0
Plotting simple paths on the tilemap islands will sometimes generate a wonky path that will snap back into a "straight" path by left clicking a few pixels around the position that gave the wonky path.

Maybe I'm not understanding the new Navigation system, or setting things up wrong, or have the wrong assumptions, but after messing around with this while playing around with a prototype for a game this seems like genuine bugs to me.
Best Regards,

Óli Fly

NavigationTest_3_2.zip
NavigationTest_4.zip

cc @AndreaCatania

This sounds similar to these (rather dated) issues: #30883 and #41349. It seems to be an issue with the NavigationPolygon not getting initialized the way they are defined in the tileset. Will this be fixed in 4.0?

So it tested the project in 4.0 after fixing it due to being a little outdated by now.
groud explained everything that was setup wrong already like the too much overlapping navigationpolygons.
The edge merge problems were fixed with #47024 and the tileset with #48535 in Godot 4.0.
I could not test the tileset cause the ui is currently broken in Godot 4.0 but the .tres file looked ok.
I could not find any bug or issue with the navigationpath or the navigationpolygon.


Alternative to loading svelte.config.js ?

Hi, thanks for writing svelte-jester, it seems like the best way to use Jest with Svelte! :slightly_smiling_face:
I noticed that, if a project's package.json declares "type": "module" (new in Node 14), then when running jest it throws an error because it expects an ES module, not a CommonJS module. (See error below.)
I know svelte.config.js is a convention borrowed from svelte-preprocessor, but I wonder if there could be a way to pass the options directly into svelte-jester? This would eliminate the need to load a separate file. Alternatively, it seems that allowing a filename like svelte.config.cjs would also work.
(Interestingly, changing svelte.config.js to use ES module format rather than CommonJS format throws the same error.)
Uncaught Error: Must use import to load ES Module: ~/my-project/svelte.config.js
require() of ES modules is not supported.
require() of ~/my-project/svelte.config.js from ~/my-project/node_modules/cosmiconfig/dist/loaders.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename svelte.config.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from ~/my-project/package.json.

(FWIW, in case someone is googling this error and happens upon this GitHub issue, I worked around it by forking svelte-jester and avoiding loading the separate file.)

Hey @nolanlawson I haven't dug in this issue completely, but to shed some light on why I made the library this way is because:
Jest does not support async transformations at the moment, svelte.preprocess is async, so the only way around it is running a child process synchronously which then executes async code. Now this is why I chose to use svelte.config.js. You can't pass a function from one process to another (I'd love to know if it's actually possible, don't think so), and as you know svelte-preprocess takes in a complex configuration containing functions and what not. To load it in the child process it needs to exist externally in a file.
So I decided for the time being while we wait for Jest to support async transforms (there is a PR being worked on) to use svelte.config.js because of the explanation above but also as you said it's a convention used by svelte-preprocess and also svelte-vscode so most people should be familiar with it by now and have it in their projects.
I understand you want to pass the configuration directly but we can't right now, as soon as we can I'll make a PR for it :)

In regards to the ES module error, do you have any proposed solution on how it could exist in a seperate file for the time being. Does simply supporting both .js and .cjs files solve the issue?

I agree that this svelte config file is needed to provide options but I found no documentation on it nowhere. The only config I know for svelte is the rollup one, and I don't know how it relate to what's expected in svelte.config. I just jumped on the bandwagon of svelte testing and I struggle so much to find resources and correct configuration.

@mihar-22 I didn't test it, but yes, it looks like supporting svelte.config.cjs would also do the trick.

while we wait for Jest to support async transforms (there is a PR being worked on)

For reference, it looks like this is the issue https://github.com/facebook/jest/issues/9504 and PR https://github.com/facebook/jest/pull/9889

		plugins: [
			["@babel/plugin-transform-modules-commonjs", { "allowTopLevelThis": true }],
			]

have you tried this adding to you babel config file?

@MikeProcudin I tried adding that to one of our new projects (which is having the same issue) and added that project as a dev dependency, and still get the same error.

@wallw-bits , hey, I've changed svelte-jester to jest-transform-svelte and it worked for me.
Hopefully, it will be the case with ur stuff.

@wallw-bits , hey, I've changed svelte-jester to jest-transform-svelte and it worked for me.
Hopefully, it will be the case with ur stuff.

jest-transform-svelte doesn't support all the options from svelte-jester. But it might work, depending on your setup.

I know svelte.config.js is a convention borrowed from svelte-preprocessor

It should be noted that this is not just a svelte-preprocessor convention, but rather is the official standard of the Svelte ecosystem. Rich proposed it in https://github.com/sveltejs/svelte/issues/1101 and implemented it in SvelteKit, which is the official way to build Svelte apps

@nolanlawson Can you please retry with the latest version and jest 27+? Sveltekit requires ESM, so this should not be the problem anymore.

Looks like I can set preprocess: './svelte.config.cjs'. This works for me: https://github.com/nolanlawson/emoji-picker-element/pull/260
Thanks a bunch!


move esc handler to root component

we need this everywhere else we get errors (see menubar console.log)
@keybase/react-hackers

How do I repro this? I tried looking in the menubar console and pressing ESC, but I'm not seeing anything there.

Without it you can see an exception being thrown with a null context. Turn
on secondary dev tools and set pause on break points
On Thu, Jul 6, 2017 at 7:23 PM Max Goodman<EMAIL_ADDRESS>wrote:

How do I repro this? I tried looking in the menubar console and pressing
ESC, but I'm not seeing anything there.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/pull/7665#issuecomment-313545720, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfhUw8WN1V0P_UpAeWVekewtSQPv6xTks5sLWxYgaJpZM4OQO_c
.

@keybase/react-hackers bump. this just moves the global escape handler which is required by sub components to exist through context to the shared Root object so it works on menubar/trackers/etc. without this we actually get errors thrown when an escape handler is used (like on master)


New Release?

Hi, this is probably not strictly an issue, but I was wondering if you were planning another release at any point? Specifically, it would be useful for me if the line number changes I did a while ago could make it into a version on Nuget.
Thanks,
Richard

bump @sinairv

bump @sinairv

@304NotModified I appreciate your persistence!

👼

I was about to try to add a feature I wanted, but then noticed 5 open PRs from 2018 so I think I'm just going to live with the workarounds instead. >.<

Superseded by https://github.com/YAXLib/YAXLib/issues/116


bowling: be more explicit about when errors should happen

The JSON file currently says "When to error is also left up to your
implementation", but we should instead be explicit.
Let's say I roll 5, then roll 6, then roll 0 18 times.
Okay, that's 20 rolls, that's a full game, so I can take the score now,
right?
Now I try to take the score and find that I get an error. Argh!
In the absolute best case, the error result from score would be so kind
to tell me that my roll 6 way back there was invalid, but in the worst
case it might not, and I would be left to my own devices to figure out
what happened, since there was no feedback on any of the individual
rolls.
This commit proposes that invalid rolls be made explicit right when the
roll is made, not at some unspecified time in the future (when
attempting to take the score of the game). This is done via a
roll_should_fail key that is mutually exclusive with the expected
key.
Previous discussions I know of (since I was involved):

exercism/xrust#213 (comment)
exercism/xhaskell#440

I think it is desirable to fail as soon as possible, as in general that is a good strategy to follow. How to specify it, I'm not sure. That's a bit harder I think.

OK, nobody gave a better suggestion, so I'm rolling with roll_should_fail.

Verified for correctness at https://github.com/petertseng/x-common/compare/verify...petertseng:verify-roll-should-fail?expand=1

OK, now using the error object of #401.

Verified for correctness at https://github.com/petertseng/x-common/compare/verify...petertseng:verify-roll-should-fail?expand=1

Just a comment, that shouldn't prevent merging this:
The fact that you are proposing to use a shouldFail or an expected that could contain an error (two distinct encodings for exceptional conditions) suggest that restricting error to be a string  if forcing alternative encodings of error-related data.

The fact that you are proposing to use a shouldFail or an expected that could contain an error (two distinct encodings for exceptional conditions) suggests that restricting error to be a string is forcing alternative encodings of error exception-related data.

I think that's because there are two methods being tested here:

Recording a roll.
Getting the score.

With the PR almost being merged, we could be using the property field to indicate that a different property is being tested, right?

So you are suggesting that the tests look something like this (I gave one example for each of the three different cases represented: Score succeeds, score fails because game is incomplete, roll fails because it is invalid (we could explicitly add cases where the roll succeeds; the expected value would probably just be null I suppose).
    [ { "description"   : "game with no strikes or spares"
      , "property"      : "score"
      , "previous_rolls": [3, 6, 3, 6, 3, 6, 3, 6, 3, 6, 3, 6, 3, 6, 3, 6, 3, 6, 3, 6]
      , "expected"      : 90
      }
    , { "description"   : "can't score incomplete game"
      , "property"      : "score"
      , "previous_rolls": [0, 0]
      , "expected"      : {"error": "something"}
      }
    , { "description"   : "can't roll more pins than there are on the lane"
      , "property"      : "score"
      , "previous_rolls": [5]
      , "roll"          : 6
      , "expected"      : {"error": "something"}
      }
    ]

Actually, shouldn't the last case be:
{ "description"   : "can't roll more pins than there are on the lane"
  , "property"      : "roll"
  , "previous_rolls": [5]
  , "roll"          : 6
  , "expected"      : {"error": "something"}
}

With the property being tested set to "roll" instead of "score"?

With the property being tested set to "roll" instead of "score"?

You're right. Edited to be so, so that we are on the same page

You're right. Edited to be so, so that we are on the same page

I think your three test-cases example looks perfect now! Very clean and understandable. Great!

First of all, let me say that I agree with the idea of returning which of the rolls in the lists in invalid. It is an useful information for the user.
Sorry for getting in the middle of this PR, I was just thinking out too loud. Now, let me explain what I meant.

I think that's because there are two methods being tested here:

Recording a roll.
Getting the score.

This may be where we diverge. I think the exercise is just about scoring a game, so we need to test score, and that is also the only test group in the canonical-data.json.
To fulfill the new requirements of returning which roll is the invalid, this score may return:

A score, for a valid and complete game.
An exceptional value for an incomplete game.
Another exceptional value for an invalid list of rolls, with the information of which roll is the invalid one.

A valid score should be represented normally in expected:
"expected": 42

An exceptional condition would, by convention, be represented as an error:
"expected": { "error": "Incomplete game" }

or
"expected": { "error": "Invalid roll 6 - Cannot score more than 10" }

I was just thinking that, because error was defined as a string in #551, there is not way for us to include more information about the error in a structure way.
Anyway, it seems that this PR has taken a turn, and now the proposal includes also testing an intermediary function. In this case, I think that my original arguments doesn't apply anymore.

@rbasso I'd also be content with your solution, but I do really like to "fail-fast" in my code, and failing on an invalid roll instead of only failing when calculating a score seemed reasonable to me.

First, I will say that I will propose a new file to match the new schema, which should make clear when the errors are happening.

Second, I will say that the Haskell track only has a score function returning an Either, with the Left being a type that can either be an invalid roll (specifying precisely which roll was invalid) or an incomplete game. The discussion can be seen at https://github.com/exercism/xhaskell/issues/440 and the result at https://github.com/exercism/xhaskell/blob/master/exercises/bowling/test/Tests.hs
Now I see what we mean when we say we want a richer error than just "error": <string>": it would be great to have structured data specifying which roll was invalid in the error object. Exception-based languages should be able to make this happen easily too; if this is seen as desirable we should revise the error object.

EBWODP:

I will propose a new file

But not now. Maybe in 12 hours.

About when to fail

@rbasso I'd also be content with your solution, but I do really like to "fail-fast" in my code, and failing on an invalid roll instead of only failing when calculating a score seemed reasonable to me.

Think in what I wrote more like a question than a suggestion. By the way, I also prefer to fail-fast most of the times, @ErikSchierboom.
I was just pondering that maybe we are letting details of "how to solve the problem" affect the "how to specify the problem". If the solution gives the correct results, it shouldn't matter how it does it internally.
About more structured expected types

Now I see what we mean when we say we want a richer error than just "error": ": it would be great to have structured data specifying which roll was invalid in the error object. Exception-based languages should be able to make this happen easily too; if this is seen as desirable we should revise the error object.

I just started thinking about the subject after we added the restrictions from #551 in #602, but maybe the problem can be generalized a little. Maybe error is just a special case of the more general problem of returning different things depending on the input data.
Let's say we have a function called feedShark, which can return one of the following (a sum type), depending on the input food:

Case 1 - a boolean indicating if it has eaten the food.
Case 2 - an exceptional value, indicating that the object  is something too big to even think about feeding it.
Case 3 - another exceptional value, indicating that the feeder has lost a body part in the proccess, also indicating which part was eaten.

We have a lot of different ways to encode that in JSON:
[ { "description": "Try to feed a furniture"
  , "property"   : "feedShark"
  , "food"       : "wardrobe"
  , "expected"   : false
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "expected"   : "Impossible"
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "expected"   : { "feederEaten": "right arm" }
  }
]

We could also be more descriptive about the cases, like this:
[ { "description": "Try to feed a furniture"
  , "property"   : "feedShark"
  , "food"       : "wardrobe"
  , "expected"   : { "eaten": true }
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "expected"   : { "impossible": {} }
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "expected"   : { "feederEaten": "right arm" }
  }
]

We could even flatten everything, maybe for readability:
[ { "description": "Try to feed a furniture"
  , "property"   : "feedShark"
  , "food"       : "wardrobe"
  , "eaten"      : true
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "impossible" : {}
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "feederEaten": "right arm"
  }
]

About when to fail

@rbasso I'd also be content with your solution, but I do really like to "fail-fast" in my code, and failing on an invalid roll instead of only failing when calculating a score seemed reasonable to me.

Think in what I wrote more like a question than a suggestion. By the way, I also prefer to fail-fast most of the times, @ErikSchierboom.
I was just pondering that maybe we are letting details of "how to solve the problem" affect the "how to specify the problem". If the solution gives the correct results, it shouldn't matter how it does it internally.
About more structured expected types

Now I see what we mean when we say we want a richer error than just "error": ": it would be great to have structured data specifying which roll was invalid in the error object. Exception-based languages should be able to make this happen easily too; if this is seen as desirable we should revise the error object.

I just started thinking about the subject after we added the restrictions from #551 in #602, @petertseng, but maybe the problem can be generalized a little. Maybe error is just a special case of the more general problem of returning different things depending on the input data.
Let's say we have a function called feedShark, which can return one of the following (a sum type), depending on the input food:

Case 1 - a boolean indicating if it has eaten the food.
Case 2 - an exceptional value, indicating that the object  is something too big to even think about feeding it.
Case 3 - another exceptional value, indicating that the feeder has lost a body part in the proccess, also indicating which part was eaten.

We have a lot of different ways to encode that in JSON:
[ { "description": "Try to feed a furniture"
  , "property"   : "feedShark"
  , "food"       : "wardrobe"
  , "expected"   : false
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "expected"   : "Impossible"
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "expected"   : { "feederEaten": "right arm" }
  }
]

We could also be more descriptive about the cases, like this:
[ { "description": "Try to feed a furniture"
  , "property"   : "feedShark"
  , "food"       : "wardrobe"
  , "expected"   : { "eaten": true }
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "expected"   : { "impossible": {} }
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "expected"   : { "feederEaten": "right arm" }
  }
]

We could even flatten everything, maybe for readability:
[ { "description": "Try to feed a furniture"
  , "property"   : "feedShark"
  , "food"       : "wardrobe"
  , "eaten"      : true
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "impossible" : {}
  }
, { "description": "Try to feed a big animal"
  , "property"   : "feedShark"
  , "food"       : "elephant"
  , "feederEaten": "right arm"
  }
]

Same old place.
https://github.com/petertseng/x-common/compare/verify...petertseng:verify-roll-should-fail?expand=1

The unindent is inevitable to match the new schema. But that's why it's in its own commit, so that it is easily seen that that commit only unindents.

IMHO, the current version is great. What do you think @rbasso? Perhaps we should move the discussion about return values to a separate issue?

IMHO, the current version is great. What do you think @rbasso?

I'm usually against testing for intermediary functions, but I never solved this exercise and I trust that you have your reasons. 👍

Perhaps we should move the discussion about return values to a separate issue?

It was just an idea...I guess I'm spending too much time with JSON. 😄

@rbasso Well, the problem description requirements actually explicitly mention two operations to be implemented:

roll(pins : int) is called each time the player rolls a ball. The argument is the number of pins knocked down.
score() : int is called only at the very end of the game. It returns the total score for that game.

:)

Well, the problem description requirements actually explicitly mention two operations to be implemented

You are indisputably right about that. 😄

Sorry, no squash since I think the individual changes are easier to understand than a single diff that purports to change the entire file (it really doesn't)
I was a bit selfish and only served my specific goals for this PR: The goal of expressing in some way that a roll should fail fast (as soon as it is known to be erroneous).
There are other goals that are still worthy, even though I left them aside for this PR. I kept the scope small for this PR, but these are worth their own discussion:
More structured data in error
This allows tracks to easily check whether the right kind of error is given. This seems easy enough to implement for a few tracks: Those with sum types can check that the constructor, and those with exceptions can check the class of the exception.
From what I know, the Swift track is very diligent about doing this. I don't have time to show y'all all the examples, but:

https://github.com/exercism/xswift/blob/master/exercises/minesweeper/Tests/MinesweeperTests/MinesweeperTests.swift#L69
https://github.com/exercism/xswift/blob/master/exercises/queen-attack/Tests/QueenAttackTests/QueenAttackTests.swift#L35
https://github.com/exercism/xswift/blob/master/exercises/largest-series-product/Tests/LargestSeriesProductTests/LargestSeriesProductTests.swift#L52
https://github.com/exercism/xswift/blob/master/exercises/bowling/Tests/BowlingTests/BowlingTests.swift#L103

Other tracks don't do that as often. I explained in https://github.com/exercism/x-common/issues/401#issuecomment-275585678 that  e.g. Rust merely checks Result#is_err and Haskell merely checks Data.Either.isLeft (with bowling being a unique case where the error type is checked!)
If more tracks are interested in doing this, it is certainly possible. It may be good to see whether there is any fixed schema that will relieve us from having to write exercise-specific code for each exercise's errors.
Bowling overspecifying
The https://github.com/exercism/x-common/blob/master/exercises/bowling/metadata.yml tells us this exercise hails from http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata . Now, note that we have already morphed it from its original form since we require checking for errors whereas the original did not.
We may consider further revisions, such as not specifying the internals and only asking "the score resulting from these rolls, or error". For maximum effect it is probably good if the error describes which roll is erroneous (as the Haskell tests do).
I don't oppose that change, but I do believe it is best left until we have a better error.

:tada:


 Please turn it off using 'regolith unlock'.

This is not true. Maybe it was "accidentally fixed" at some point? I can't reproduce the issue


Add hate to init.py

add a hate module
Short description of what this resolves:
Changes proposed in this pull request:
-I think the purpose of Jarvis on messanger is to communicate with people. I think adding a hate module is helpful for communication with people. So I will make a hate module and send a pull request. Please check.

Fixes: #

Thank you for taking the time to contribute! This is sincerely appreciated. 😇
(Powered by GitMate.io)


Find a way to extract ZIP on Windows without Powershell

As it turns out, the Windows 7 version of Powershell is old and does not have the Expand-Archive command yet. This is a good reason to look for alternative ways, since nothing else stops Catapult from supporting Windows 7. Options:

Implement extraction from scratch in GDScript.
Find a suitably licensed command line utility for unzipping that could be bundled with Catapult.

Now using bundled UnZip by InfoZip.


tcp connection pool drain falls into infinite loop

Per #4043, there was a bug in draining connections using the TCP connection pool in conjunction with the TCP proxy.
Repro steps:
It's pretty easily reproduced by adding a TCP proxy test case that configures a drain callback and then simulates an upstream close.
The connection pool invokes the TCP proxy's callback, which releases the connection back to the pool, placing it in the ready list (the connection pool has not yet processed the close event). Upon processing the event, the conn pool attempts to remove the connection from the busy list (where it no longer resides) and then triggers the drain callback which loops over the ready list, closing connections. Because the connection is already closed, no event is triggered and the connection remains on the ready list, causing an infinite loop.
Call Stack: see #4043

Fixed in #4067


Refactor

Refactor to create a metadata layer that is then used in the generators.

This is done #76, #79, #80


HDDS-9060. [snapshot] Add unit-testcase for snapshot fs -deleteSnapshot

What changes were proposed in this pull request?
Add UTs for fs deleteSnapshot - TestOzoneFsSnapshot#testSnapshotDeleteFailure
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-9060
How was this patch tested?
Testcase file - hadoop-ozone/integration-test/src/test/java/org/apache/hadoop/fs/ozone/TestOzoneFsSnapshot.java
mvn -l testlog.out -Dtest=TestOzoneFsSnapshot#testSnapshotDeleteFailure test
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.hadoop.fs.ozone.TestOzoneFsSnapshot
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.999 s - in org.apache.hadoop.fs.ozone.TestOzoneFsSnapshot
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0

Please review - @nilotpalnandi @sadanand48 @smengcl


Check Header spacing

Once https://github.com/ONSdigital/design-system/pull/1802/files is released (anything over 44.1.2) we should check whether our slightly modified Header with description looks okay.

Irrelevant now that we've tweaked Headers a bit.


Jpmc develop from staging 2

Clone https://github.com/civis-vote/civis-frontend/pull/237
Razorpay Integration


Train/Test/Validate with BetaGeoFitter

I am looking to do a train/test/validate on subsets of my data. Is there a means of using the existing functions for this? Maybe a variant of calibration_and_holdout_data?

Hey @lexykassan, calibration_and_holdout_data does the train/test, so you may have to do some manual pre-processing on the original dataset to also include validate

Hey. Thanks for the quick response. To be clearer, I have already used the time-based validation on the training set. What I am looking for is cross-validation of different subsets of customers summarized in the same time period. e.g. how extensible is this model across the same time period but different observations? Is there a built-in capability for this?

ah I see. You could hash & mod k the customer_ids from the original dataset into K subsets of the original dataset, and use that for k-fold validation. Ex: hash all ids, partition the ones that are 0 mod K. Put that smaller subset into calibration_and_holdout_data to get a split. Train on the K-1 other dataset using summary_data_from_transaction_data, and then predict on the smaller subset. Is that clear?

So are you saying that there is no way in the lifetimes package to apply the model to new data? Do you have to completely retrain the model every time you have a new customer? This seems like a substantial limitation.

I likely am confused. The examples I see in the docs are for the same set of customers with a train and test time period. How would one call the model itself to predict on a different set of data? For instance, in the docs there is self.predict that calls conditional expected purchases but it appears to only allow for predicting on one customer at a time. Could this be used to score an expected purchase count for all customers in a different data set? Theoretically the math wouldn't change - just the scale of calculation.

For example:
bgf.fit(train['t'], train['freq'], train['r'])

# predict new orders on unseen customers, up to time 10
bgf.conditional_expected_number_of_purchases_up_to_time(10, test['t'], test['freq'], test['r'])

Ah, OK. It was not clear that the index value could be omitted there. Thank you. I will try that.


Use custom copiers declared in Config

Fixes #31
I ran into a weird issue in Terraform LS where certain struct fields weren't being copied under some circumstances and I found this was because an external imported package also uses copystructure and overrides custom copiers.
Ideally I'd like to just avoid the global state entirely, but this doesn't seem possible until this bug is fixed.

Hah! Thanks


Slight update to grammar on the home page

Yes i know this is nitpicky

lgtm! (sry for late reply 🙏🏻 )
Thank you for contributing!


Pointer#copy_to and Pointer#copy_from should return the number of bytes copied

This is more to make things a little cleaner on the Slice side of things. Currently the Pointer#copy_* methods end up returning the pointer, and when using the copy methods with a raw pointer that's probably fine, seeing as it requires you to include the number of bytes being copied.
However when it comes to Slices they just defer to the copy method for the underlying pointer, which means that those methods also end up returning a pointer. In the case of Slice#copy_to(slice : Slice) the number of bytes being copied may be less obvious, so I think it would be a good idea to return that number rather than returning the underlying pointer.
This would be more similar to the copy function in Go.

Pointer copy is just a wrapper against memcpy which copies exact number of bytes requested and returns a pointer to the destination. Signature of memcpy as below
void * memcpy ( void * destination, const void * source, size_t num );
so don't know what benefit one will have in returning the len argument back to its caller?

Pointer copy is just a wrapper against memcpy which copies exact number of bytes requested and returns a pointer to the destination. Signature of memcpy as below
void * memcpy ( void * destination, const void * source, size_t num );
so don't know what benefit one will have in returning the len argument back to its caller?

@naqvis the use case is probably kind of niche, but I'll try to show a simple example which is often seen in crypto libraries:
# buffer and output are both slices of the same length
count = buffer[<EMAIL_ADDRESS>@index += count

In this case the number of bytes being copied isn't obvious. It can be determined by doing<EMAIL_ADDRESS>or buffer.size - @index, but just returning a count feels better imo.

@naqvis the use case is probably kind of niche, but I'll try to show a simple example which is often seen in crypto libraries:
# buffer and output are both slices of the same length
count = buffer[<EMAIL_ADDRESS>@index += count

In this case the number of bytes being copied isn't obvious. It can be determined by doing<EMAIL_ADDRESS>or buffer.size - @index, but just returning a count feels better imo.

@watzon so you are talking about Slice#copy_from(self) and Slice#copy_to(self) methods. Pointer variation of these methods require user to provide the size argument. Slice overloads does offer size validation, or else approach you are using above is quite dangerous in pointer version, where you are exposing your app to segfaults or buffer overruns.
I would suggest to change the title of this issue to Slice .... instead of Pointer.

@watzon so you are talking about Slice#copy_from(self) and Slice#copy_to(self) methods. Pointer variation of these methods require user to provide the size argument. Slice overloads does offer size validation, or else approach you are using above is quite dangerous in pointer version, where you are exposing your app to segfaults or buffer overruns.
I would suggest to change the title of this issue to Slice .... instead of Pointer.

As I mentioned earlier, this is mostly for Slice, but Slice itself just defers to the Pointer method anyway, so why not change the return value in the Pointer method.

As I mentioned earlier, this is mostly for Slice, but Slice itself just defers to the Pointer method anyway, so why not change the return value in the Pointer method.

I think it makes sense for Slice. Maybe for pointer too. I was also confused because of the title, you can't subslice a pointer.

I think it makes sense for Slice. Maybe for pointer too. I was also confused because of the title, you can't subslice a pointer.

I would be fine only having it for the particular Slice method, but after looking at the way the code is written now I figured it would make just as much sense to have it on Pointer as well since that's what Slice defers to.

I would be fine only having it for the particular Slice method, but after looking at the way the code is written now I figured it would make just as much sense to have it on Pointer as well since that's what Slice defers to.

There is a similar issue: #13773


feat(API version): using swagger 0.1.0 and OpenAPI code gen.

Had to switch to open api generator:
https://github.com/OpenAPITools/openapi-generator#13---download-jar
Important
If you want to use the current version and don't want npm to accidentally upgrade you to new minor release please use ~ prefix for your dependency version:
"@manageiq/topological_inventory": "~1.0.3",

:tada: This PR is included in version 1.1.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Feat: make getattr and setattr of ClasswiseWrapper more general

What does this PR do?
Fixes #2389
Related PR: #2390

Before submitting

[x] Was this discussed/agreed via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure to update the docs?
[x] Did you write any new necessary tests?

PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.

Did you have fun?
Make sure you had fun coding 🙃

📚 Documentation preview 📚: https://torchmetrics--2424.org.readthedocs.build/en/2424/

Dear @Borda and @SkafteNicki,
This PR makes __getattr__ and __setattr__ of ClasswiseWrapper more general to fetch the attribute of inner metric and ClasswiseWrapper.


Tools dnsenum not available from apt-get using 2.7-slim

Hello,
I just saw that when using brutex in Docker, the install.sh script doesn't work since dnsenum is not available in the repo. Would it be better to use kalilinux/kali-linux-docker as base image ? Or finding a way to install the tool another way ?
What do you think ?
Cheers,
Patrik

Please reopen if not already fixed. Thanks!


Add stereo conversion to mono in UtteranceCloner and a generalized text to file reader with a personalized name according to model_id

An error appeared when entering a stereo audio in run_prosody_override which was raised from the UtteranceCloner when using silerovad. Commit 2f8ea93 fixes the error and the code is exactly the one used to fix this issue in the run_text_to_file_reader.
In commit 9082cf5 I changed all the language test functions to one function called new_test, where I included a personalized name according to the model_id. This will help new users of the toolkit see their test files with their own model's name without having to create a new function for their model and target language.

@Flux9665 did you see the pull request?

Hi, thanks for the fix! I am attending a conference right now and the hotel wifi is terrible, I will check everything next week when I get back.

[accept] The fix in https://github.com/DigitalPhonetics/IMS-Toucan/commit/2f8ea9309cadb8535163a5e4dbaf97bfef2dfc23 is necessary, thank you for this!
[change required] The change of the file-reader demo in https://github.com/DigitalPhonetics/IMS-Toucan/commit/9082cf5bb0377c2f4d6c5a16c29d2ae35ff2c435 does however not fit well with the philosophy on redundancy of the toolkit and makes the code less readable. The model_id is already part of the arguments of the function, I would prefer it if we just put the model_id into the filename of the existing functions, rather than make a more abstract function.

@Flux9665 I did the change.


Respect initial window names

fixes #14.
Initial window names are detected by observing the value of automatic-rename in an after-new-window hook.
the hook copies this value to @tmux_window_name_enabled, and then sets automatic-rename off.
from the tmux man page (about automatic-rename):

This flag is automatically disabled for an individual window when a name is specified at creation with new-window or new-session

Thanks for the contribute!
Why do we need to copy the value to @tmux_window_name_enabled?

When a window has been created with an initial name, we want to respect that, and not rename it.
From my understanding of the plugin code, the renaming is enabled by the @tmux_window_name_enabled option. copying the value from automatic-rename makes the value of @tmux_window_name_enabled 1 if created without a name, and 0 if created with a name, like we want.

Closed with feature/respect_new_window_name next time you can open a branch on your fork instead of working on master and tick allow author to edit so I can edit the PR before merging


Added automatic builds + docker support

Currently the containers can be found at:
https://hub.docker.com/r/devedse/lancacheui_api
https://hub.docker.com/r/devedse/lancacheui_frontend
  lancacheui_api:
    image: devedse/lancacheui_api:latest
    restart: unless-stopped
    environment:
      - logFileLocation=/data/logs/access.log
    volumes:
      - /dockercomposethings/lancache/logs:/data/logs
    ports:
      - 3002:3002/tcp

  lancacheui_frontend:
    image: devedse/lancacheui_frontend:latest
    restart: unless-stopped
    environment:
      - logFileLocation=/data/logs/access.log
    volumes:
      - /dockercomposethings/lancache/logs:/data/logs
    ports:
      - 4173:4173/tcp

How would this look when you add the above example code to the main docker-compose file (https://github.com/lancachenet/docker-compose/blob/master/docker-compose.yml)
Because then you could reuse the variables set in .env and have a single file to manage lancache + the ui.


Overlaping rectangles

Rectangle r1 = new Rectangle(0.1f, 0f, 32f, 32f);
Rectangle r2 = new Rectangle(32f, 0f, 32f, 32f);
if (r2.overlaps(r1)) Gdx.app.log("", "true");
This two rectangles are not overlaping, but the function returns true.
The corner of r1 is 31.1f, and the x of r2 is 32f, so they are not overlaping, right?

No, the corner of r1 is 32.1f. This is correct behavior.

@Anuken Im sorry but Im confused.  The corner of r1 is 32 + 0.1 = 32.1, so it overlaps the other rectangle at 32, 32.

@Anuken Ok, sorry, that was foolish of me, I was confused because I was thinking in pixels. Thanks for your time.


Problem with Update from v0.64.0 to v0.64.1

Microsoft PowerToys version
0.64.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
Installer
Steps to reproduce

✔ Expected Behavior
Didn't get any error
❌ Actual Behavior
I got an error
Other Software
No response

Did you clean up your PC with 3rd party tools (like CCLeaner) between the previous update and the last one? It asks for the previous (0.63.0) MSI package in the installer folder.

Not able to repro this, going to close. Let us know if you see this again!


Update error handling in SDKSynchronizer.swift

This ticket is about to use of ZcashError. How to do it is described in #361.

Closed with #1002


Checks for null data transaction (OP_Return) before issuing error to debug.log

Description:
CWalletTx::GetAmounts could not find output address for null data transactions, thus issuing an error in debug.log. This change checks to see if the transaction is OP_RETURN before issuing error.
Fixes bitcoin issue 6142.
Source: https://github.com/bitcoin/bitcoin/pull/7200
Commit 1: https://github.com/accraze/bitcoin/commit/b6915b82398d2e1d1f888b3816adfaf06d9a450e
Commit 2: https://github.com/accraze/bitcoin/commit/c611acc38a95d336a824b632823aa1b652e570df
Commit 3: https://github.com/accraze/bitcoin/commit/d812daf967ba4173bfa1c37eeb4ab7a0ccc4df25
Gridcoin code locations: (Unsure which of the two locations should have this change, very similar code chunks)
https://github.com/gridcoin/Gridcoin-Research/blob/master/src/wallet.cpp#L910
https://github.com/gridcoin/Gridcoin-Research/blob/master/src/wallet.cpp#L831
TL;DR:
The following code snippet:
if (!ExtractDestination(txout.scriptPubKey, address))
Changes to:
if (!ExtractDestination(txout.scriptPubKey, address) && !txout.scriptPubKey.IsUnspendable())
Justification:
OP_Return transactions are null data transactions & currently (potentially) create an error in the debug.log file. Fixing this will compliment OP_Return functionality within the Gridcoin client.

Added in <IP_ADDRESS>, but not enabled, due to the false belief the other part of the feature would require a mandatory.  Im syncing and staking with the new OpReturn feature enabled, so lets enable this in the release tonight and test it.  Ill leave this open for testing.


optimize insert users/items/feedback

Codecov Report

Merging #411 (39bf28e) into master (97224d0) will increase coverage by 0.49%.
The diff coverage is 66.41%.

@@            Coverage Diff             @@
##           master     #411      +/-   ##
==========================================
+ Coverage   74.04%   74.54%   +0.49%
==========================================
  Files          52       52
  Lines       10527    10591      +64
==========================================
+ Hits         7795     7895     +100
+ Misses       1982     1940      -42
- Partials      750      756       +6

Impacted Files
Coverage Δ

master/tasks.go
58.90% <0.00%> (ø)

storage/data/database.go
73.91% <ø> (ø)

worker/worker.go
67.21% <33.33%> (ø)

master/master.go
1.12% <50.00%> (ø)

server/rest.go
73.25% <53.84%> (+0.76%)
:arrow_up:

storage/data/mongodb.go
82.04% <71.42%> (-0.24%)
:arrow_down:

storage/data/redis.go
70.65% <76.00%> (+0.30%)
:arrow_up:

storage/data/sql.go
81.80% <76.47%> (-0.17%)
:arrow_down:

storage/cache/database.go
82.60% <80.00%> (-0.45%)
:arrow_down:

storage/cache/redis.go
84.10% <81.81%> (+22.07%)
:arrow_up:

... and 5 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 97224d0...39bf28e. Read the comment docs.