Why are Checked* classes declared to throw Throwable

All Throwable instances must either be an Exception or an Error. The javadoc for Error states that:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.

However, because Vavr lambda classes generally declare to throw Throwable, developers end up writing this sort of thing:
public void doSomething(CheckedRunnable thing) throws MyException {
  try {
    thing.run();
  } catch (SomeExpectedException e) {
     // recover/log/rethrow/whatever
  } catch (Throwable e) { // have to catch because CheckedRunnable declares to throw
    throw new IllegalStateException("I only expected SomeExpectedException", e);
  }
}

But we've now ended up with any Error being caught and handled by the application. Obviously this can be fixed by doing something like:
  } catch (Exception e) {
    throw new IllegalStateException("I only expected SomeExpectedException", e);
  } catch (Throwable t) {
    throw (Error) t; // we know this must now be an Error
  }

But as Error doesn't have to (or indeed, based on the javadoc, shouldn't) be caught, we really shouldn't have to be doing this.
This would be avoided if the Checked* signatures instead were:
@FunctionalInterface
public interface CheckedRunnable {
    void run() throws Exception;
}

And the resulting calling code would be safer.
Aside: I'd actually prefer that the signatures were something like:
@FunctionalInterface
public interface CheckedRunnable<E extends Exception> {
    void run() throws E;
}

or perhaps, to remind users that a lambda may throw a RuntimeException:
@FunctionalInterface
public interface CheckedRunnable<E extends Exception> {
    void run() throws E, RuntimeException;
}

I don't like how Throwable is caught either. It's can hide real significant problems - problems like what you point out. using Try.of(() -> connectToDb()) makes sense to catch errors and try again or us a circuit breaker. But an ExceptionInInitializerError means that a static block in a class threw an error and the class failed to load. Based experience it's nearly impossible to determine why (the underlying problem usually vanishes).
Errors are bad and are by designed meant to not be caught:

OutOfMemoryError - You can't increase JVM Heap space from inside the JVM, so now what?
UnsatifiedLinkError - An attempt at a native library load failed. Was the library missing? Is it binary incompatible (which, based on experience reports as not found).
NoSuchMethodError - Version compatibility error, always. This is non-recoverable.

The list goes on.

Yes I am not sure why everything is designed around Throwable's. sounds like a wrong design for me. Throwable catch both exceptions and errors.

@mrpotes
Suggestion with adding generic type wouldn't work well, as once you start to combine these functions together you will end up with Exception or Throwable just because in Java it is not possible to deduce resulting type (union of exception X1 and its subtypes with exception X2 and its subtypes) of exception that can be thrown.
As for catching Throwable in Checked* this is mostly because Vavr closely resembles behaviour of Scala's Try

@KTannenberg I am not sure why we should follow Scala's Try? After all, this is a Java library.
I don't believe one can ignore the points raised by @chb0github
Catching Throwable is probably the most horrible thing in my view since it catches all Exceptions and Errors that are not meant to be caught that said if you have a better solution please suggest. But given the way it is right now it makes exception handling really hard. And Cyclops seems to have better Exception handling mechanisms.

Cyclops requires you to explicitly define all exceptions that can be throw by your code below, because of that they  don't need java to figure out types on its own.
I can agree, that catching Throwable is simple in Scala because it doesn't have silly concept of checked/unchecked exceptions, so you just deal with these Throwable subtypes you do care and let other stuff be rethrown.
Unfortunately there are libraries that misuse Errors and use them in places where some Exception should have been used.

@KTannenberg Sure but again Vavr is not a Scala library right I can understand the motivations and the theory drawn from Scala or in General functional programming perspective but at the same time building the library in Java that doesn't work well for exceptions is also not the right thing to do. For example I have the following question here https://github.com/vavr-io/vavr/issues/2142 and it just a pain to even try and come up with a solution and so far there is no solution for my question. As a user of the library it doesn't give a good experience.
"Cyclops requires you to explicitly define all exceptions that can be throw by your code below, because of that they don't need java to figure out types on its own."
Sure anything wrong with that?!
Finally, please suggest if you have a better approach.

@KTannenberg Also why you say checked/unchecked exceptions are silly? How can one enforce the client of an API to think about how to deal with Exceptions at compile time? This in my experience is very useful since I need to think about how to handle a certain Exception at compile time and as a consequence this saves lot of debugging time.
If the argument is that dealing everything at run time leads to less boilerplate code then comparison really comes down is static typing vs dynamic typing. And both has pros and cons.
Dynamic typing in general takes more debugging time than static typing. And static typing is very useful to catch errors early and takes less debugging time.

I'm not saying that Cyclops did anything wrong, in fact this is probably easiest, most user-friendly and reliable solution that they choose for their version of `Try.
Also there is nothing like "everybody should everything the way it is done in scala", in fact scala have a lot of problems as well. Why I was mentioning scala in a first place is because initially javaslang (previous name of vavr) was heavily inspired by scala's std library.

@KTannenberg Agreed. Please suggest alternatives.

@mrpotes shall we implement the interface you suggested and make it part of the next release? can someone make aware of release process for Vavr?

probably @danieldietrich Should speak to the release process and if we will allow the changes. I mean, we can talk all day but unless someone forks the code or you know a PR will make it's way in to the core then it's all academic.

Vavr doesn't need to be a java implementation of Scala's immutable libraries. The functionality vavr provides fills a very real gap in the java ecosystem and can/should vary to be ideal for the language. The Scala immutable libs are a fantastic inspiration but should be taken as only that. But not following idiomatic java will/does have ramifications everywhere.

@kant111 @KTannenberg @chb0github @mrpotes Thank you for the great discussion. I decided not to use a generic type parameter for the exception type mainly for one reason:
For simple cases it might work well but in general a call might throw multiple exception, like InterruptedException and IOException at the same time. We are not able to define a common exception in a practicable way using Java's type system - we will always end up with Throwable.
In fact Java is one of the rare languages that have checked exception, most language do not and it is generally seen as a error in language design - at least it is controversial discussed.
Using Try, we are aware about the presence of exceptions. There are many useful methods to handle such cases - recently I added more onFailure variants. I think the current approach is sufficient. Also I think having only one specific exception type is not sufficient.
I like this discussion (and hope it goes on) but I will close this ticket because we will not change the way we use exception types.

@danieldietrich I'm not sure I agree with your assertion that "we will always end up with Throwable" - as per the original comment, you will always end up with Exception - you shouldn't ever end up with Throwable unless there is some poorly written code trying to handle Errors.
I totally get the reasons for not using generics, and that's fine, but I really think you should consider changing Throwable everywhere to Exception. For me, vavr becomes a waste of time and effort without this.

Perhaps I could challenge you to give an example that shows why Throwable is actually required in vavr, where Exception would not be sufficient?

@danieldietrich I concur with others. Throwable is just the most common super-type to all exceptions but that doesn't mean it should be caught because it includes Errors which should never be caught.
The VERY first sentence states this:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.

You're the owner @danieldietrich of vavr and if you wanna make it scala-envious that's your choice. But I think you are dismissing a lot of veteran experience and bluntly stated advice from the original Java documentation going back to 1.0.

@danieldietrich "In fact Java is one of the rare languages that have checked exception, most language do not and it is generally seen as a error in language design." That's a big statement without any rational basis (since there are no examples provided yet)
https://stackoverflow.com/questions/613954/the-case-against-checked-exceptions

https://stackoverflow.com/questions/613954/the-case-against-checked-exceptions

Catching Throwable's is outright madness. There are enough examples pointed out here on why.
Checked vs Unchecked exceptions really just boils down to is static type vs dynamic type of a language.  Sure unchecked exception results in better expressive code. so does any dynamic type language with lots of syntax sugar than say any static type language. Python is way more expressive than any static type language (you  name it).

I personally like static type enforcement because it helps me debug things way faster instead of relying on a programmer's comments. How many programmers do we know in the industry care to write comments? Moreover isn't it more safe to rely on a compiler than relying on some random programmer?
so This is just a preference. It's like asking is English better than German or German better than English.

@kant111

Try can catch more than more type - specifying one type is not sufficient / it is useless. Here is an example where the most common type is Exception

import io.vavr.control.Try;

import java.util.Arrays;
import java.util.List;
import java.util.concurrent.*;

import static io.vavr.API.println;

public class Test {

    public static void main(String[] args) {

        final ExecutorService executorService = ForkJoinPool.commonPool();
        final List<Callable<String>> myTasks = Arrays.asList(
                () -> "Ok!",
                () -> { throw new Error("Meep!");
        });

        { // Java variant 1
            List<Future<String>> res = null;
            try {
                res = executorService.invokeAll(myTasks);
            } catch (InterruptedException | NullPointerException | RejectedExecutionException e) {
                // e is of type Exception
                if (e instanceof InterruptedException) {
                    System.out.println("InterruptedException: " + e);
                }
                if (e instanceof NullPointerException) {
                    System.out.println("NullPointerException: " + e);
                }
                if (e instanceof RejectedExecutionException) {
                    System.out.println("RejectedExecutionException: " + e);
                }
            }
            if (res != null) {
                System.out.println("Success");
            }
        }

        { // Java variant 2
            List<Future<String>> res = null;
            try {
                res = executorService.invokeAll(myTasks);
            } catch (InterruptedException e) {
                System.out.println("InterruptedException: " + e);
            } catch (NullPointerException e) {
                System.out.println("NullPointerException: " + e);
            } catch (RejectedExecutionException e) {
                System.out.println("RejectedExecutionException: " + e);
            }
            if (res != null) {
                System.out.println("Success");
            }
        }

        { // Vavr
            Try.of(() -> executorService.invokeAll(myTasks))
                    .onFailure(InterruptedException.class, e -> println("InterruptedException: " + e))
                    .onFailure(NullPointerException.class, e -> println("NullPointerException: " + e))
                    .onFailure(RejectedExecutionException.class, e -> println("RejectedExecutionException: " + e))
                    .onSuccess(res -> println("Success!"));
        }
    }
}

@chb0github You argue about some kind of convention. I agree that Error should not be catched, but in practice 3rd party libs extend Error where it is really an Exception. There are tons of examples, e.g. in Calypso - an important trading system that exists since the 90s. But there are tons of other examples.

I uderstand your thoughts but as I said - we will keep it as-is. As always: if in doubt, align to Scala. This is our design premise.

@danieldietrich Yes, Thanks for adding those onFailure variants I have to wait until 1.0 I guess. It does look better but looks is not everything. instanceof has a performance impact as well as you may already know. variant #2 is quite good as well to be honest.
Also, Why do we care about systems or libraries that are built in 90's? Any better examples?

I think you should Advertise Vavr as "Scala inspired Java library" or something. I initially thought the library draws core concepts from Functional programming in general not just from Scala. I didn't know Vavr falls back on Scala heavily. If I knew I would have avoided using Vavr library because I might as well use Scala than using a Scala inspired library :)
Anyways since I don't see much room for discussion. I am out of this thread as well! Good luck!

@danieldietrich I'm trying to understand this issue a bit better, so here's my question.
What is the intended purpose of the Checked* functional interfaces?
To me, from the moment I saw those classes, it was pretty self-evident that they are declared like this with the intended purpose that we can use lambdas that throw checked exceptions throughout the vavr API without cluttering our own lambdas with exception handling code. That's pretty nice and helpful, but the people in this thread are right in the sense that, in order to accomplish the above goal, you only need to declare to throw Exception and you pretty much allowed all those lambdas to remain uncluttered from catching exceptions.
It there any other reason for the existence of the Checked* interfaces besides the above that I missed? Because if there's none, I'll have to agree that declaring to throw Throwable instead of Exception is unnecessary and actually harmful in this case. The harm I see in declaring to throw Throwable is that, there are practically two direct subclasses of Throwable: Exception (a checked exception type) and Error (an unchecked one). Java doesn't force you to catch Errors, on the contrary, it advises you in the docs not to. But if a method declares to throw Throwable you have no other choice but to catch Throwable, even if you intend to do anything meaningful with the Exception subclass branch only. Declaring to throw Throwable forces you to do an instanceof check on the throwable and rethrow it in case it's an Error subclass and you don't want to deal with it, which is probably the overwhelming majority of the cases. Declaring to throw Throwable makes reusing the Checked* interfaces in client code counterproductive. Of course, we can always create our own version of those functional interfaces with throwing just Exception, but then we cannot reuse those instances both in our own client code and through the vavr API.
In the rare cases when some API abuses the java exception class hierarchy by directly extending Throwable instead of Exception (both cases result in a throwable that needs to be catched), I think we could live with those very rare cases where we would need to explicitly write lambda expressions that are forced to handle that special Throwable subclass. Those cases would be very rare, and one could even argue that it's actually beneficial that it shows the user of such an API of the bad design choice, and maybe provide an incentive to refactor the offending API or use an alternative one if that's possible at all.

Hi @nfekete, thank you for the nice evening-read 😄
You made good points. Especially I like the separation of concerns of regarding the functional interfaces and the sum types like Try.
I think it is a good idea to ignore the rare cases where 3rd party library implementors made horrible design decisions by using sub-classes of Error as non-fatal exceptions.
Thx for being determined in this case!

It feels good to make useful contribution to an awesome library like vavr is, so the pleasure is mine :)

The whole project is based on contributions. The changes might look small but the effort in terms of thoughts are huge. This kind of energy doesn't get lost - it makes the library useful and also simple I think.

Based on https://github.com/vavr-io/vavr/pull/2360 https://github.com/vavr-io/vavr/pull/2352 I see the agreement reached in this thread so far has not or only partially led to the fix of making it Exception instead of Throwable?
Does this mean that a Try underlying failure will remain Throwable, and that it's up to the client application to fix this by pushing the Throwable back into a more constrained type (i.e. Exception)? Or should I deal with things differently?
I understand the tensions of fixing the API vs not breaking existing code and can't oversee the tradeoffs in this situation, but I was hoping this Throwable thing would be abandoned before 1.0...

So... there still seem to be unclarity.
I want to showcase different scenarios in order to show that it is not a good idea to...
1) Catch a specific exception type like "the other functional library Abc..."
(Look at FAIL! comments)

2) Just catch Exception and rethrow remaining throwables wrapped as RuntimeException
I understand that we could ignore Errors in the type signature because they are treated as unchecked exceptions and catched automatically by Try.
But let me be clear, there do not only exist Error and Exception as subclasses of Throwable.
🤜🏼💥 JAVA DOES ALLOW SUBCLASSES OF THROWABLE 💥🤛🏼
// Someone thought it is a good idea to build a distinct sub-tree of business exceptions
class MyDistinctBusinessException extends Throwable {
}

// Someone thought it is a good idea to build a distinct sub-tree of internal errors
class MyDistinctInternalException extends Throwable {
}

I know that it isn't good practice to extend Throwable but it is possible and therefore it happens.
We gain nothing by handling only Exception on our type signatures. The developer has to make instanceof checks nonetheless. You are still able just to use one of:
Try#recover(Class<X> exceptionType, CheckedFunction<? super X, ? extends T> recoveryFunction)

Try#recoverWith(Class<X> exceptionType, CheckedFunction<? super X, ? extends Try<? extends T>> recoveryFunction))

Maybe there will be also a
Try#onFailure(Class<X> exceptionType, Consumer<? super Throwable> action)

where X extends Throwable.
When using Try, it should not make any difference for you:

Recover the exceptions you expect
Handle all remaining (technical exception) by logging them. You have to! Or do you want just ignore any unexpected RuntimeExceptions?

Please don't miss that io.vavr.CheckedFunction0..8 will throw Exception (not Throwable)!
You can use these CheckedFunctions outside of the context of Try.

Please give me an example. Where do you need to push the Throwable back into a more constrained type? The 'recover' methods will be able to give you the expected exception type (see above).

I think this happens when I want to go back to throwing exceptions, which most likely only happens in the context of some non-var calling context; e.g.:
    // note guava CacheLoader is declared with "throws Exception"
    class MyEntityLoader extends jersey.repackaged.com.google.common.cache.CacheLoader<UUID, MyEntity> {
        public MyEntity load(UUID key) {

            return underlyingRepo.lookupMyEntity(key)
                    .getOrElseThrow(f ->
                             // have to wrap here, to make it not a Throwable... but
                            new RuntimeException());
        }
    }

But I guess this is an easy solution, and it might not be worth catering for this corner case?

@feliksik thank you for the example!
Vavr 1.0 will wrap the original exception in a NonFatalException (which extends RuntimeException).
See source.
(Don't get irritated because of the @Deprecated annotation. That is still in the flow/work in progress.)

Look ma, Scala lang contains a custom Exception that extends Throwable:

(However, it should not be caught...)


Read initial level values on application start

Fixes: https://github.com/aspnet/Logging/issues/517
Fixes: https://github.com/aspnet/AzureIntegration/issues/5

:shipit:


Fix for weight loading bug with channels_first

@fchollet This is the start of a fix for the channels_first weight loading bug. The bug is due to loading weights from Keras 1 models that used the Tensorflow backend. The current weight loading code assumes all Keras 1 models have Theano dim ordering and so things get messed up. Also the original_backend is not found automatically in the old models and so is set to None, which makes it difficult or impossible to always convert correctly. Thus I made it so the user can specify the original_backend so things can be appropriately converted. Note that I removed layer_utils.convert_all_kernels_in_model(model) from the vgg16 example since the weight loading code takes care of the kernel flipping already.
TODO:

Properly handle Conv1D  and Conv2DTranspose. I wasn't sure exactly what to do here so I left it alone, but the same issues probably apply.
Fix other applications where weight loading is a problem.

Thank you very much for your help！

The original backend is orthogonal to the original data format.

backend information is only used to convert kernel weight values (unrelated to shape) due to differences in convolution implementation (TF does correlation)
only data_format / dim_ordering affects whether or not we should be transposing the kernels
data_format information is a layer attribute

This bug has been fixed in: https://github.com/fchollet/keras/pull/6658
Thanks!


touchAngle

touchAngle option (Number, default 45) passed to the Carousel component, specifying the maximum angle in degrees, allowing dragging.

sorry @piotr-s-brainhub we decided we won't implement this issue in the react-carousel


Python 3.6 support and Python 3.3 EOL

I do not know if this is they way that you want to go but some food for thought...

Add a PyPI trove classifier for Python 3.6.
Python 3.3 goes EOL in a few weeks https://docs.python.org/devguide/index.html#branchstatus  Should we remove it?
Clean out some Python 3.2 requirements.

Should we remove it?

It's good to know that it's EOL and we can remove it once maintaining support is a problem. But in general, I don't like dropping support for things before it causes a maintenance burden.

Closing in favor of #1079


[Bug]: cannot delete empty Sharepoint backup

What happened?
I'm experiencing an error with corso backup delete sharepoint , after running a --site '*' backup, I have a number of backups listed as 'No Data' which, all well and good but I cannot delete those backups. Trying to gives me Error: Deleting backup a6c6473e-10ed-4fb5-8c36-76b0523eca8d: snapshot ID required for deletion
any backup that didn't have 'No Data' is deleting just fine
Corso Version?
Corso v0.6.1
Where are you running Corso?
OSx 13.3 (22E252)
Relevant log output
No response

hmmm could be a change between corso versions. We should now save metadata for incremental backups even if there's no data (items) to backup
It seems like there's a bug in the delete code that could be causing this. The linked block is duplicated in that statement and the if-block below. We should probably just keep the if-block version

PR - https://github.com/alcionai/corso/pull/3250


[FLINK-25433][runtime] Adds retry mechanism to DefaultResourceCleaner

What is the purpose of the change
We want to make the cleanup try to run infinitely until the cleanup is resolved.
Brief change log

Adds FutureUtils.retryWithDelay in DefaultResourceCleaner

Verifying this change

DefaultResourceCleanerTest was extended to cover the retry mechanism

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: yes
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? JavaDocs

How about we add a test that covers that the cleanup ultimately fails after exceeding retries.

That's a good idea. But I realized that this is already covered by the testConcurrentCleanupWithException* tests. Therefore, I left it without the extra test.

I addressed the comments, and in addition to that, added a *ITCase (after renaming the DispatcherFailOverITCase into DispatcherCleanupITCase) covering the retry logic in a bigger context.

Thanks for the reviews @dmvk and @metaswirl . I squashed the changes and rebased the branch. I will merge the PR after the final AzureCI run succeeded.

Looks like rebasing wasn't a good idea. There are failures on master covered by FLINK-26065. Additionally, the e2e tests stopped due to some problem that looks like an infra issue

@flinkbot run azure


Use the AOCL BLIS 4.2

resolves: LWPTENSILE-1363
Summary of proposed changes:

Switched hipBLASLt to use BLIS-4.2 and the overall test (hipBLASLt-test) time reduced from 45 minutes to 24 minutes (Almost 2 times speed-up).
The hipBLASLt use case, which was reported to have 250 times slower CPU-GFLOPs in this ticket  LWPTENSILE-1363, had a performance boost from 0.3 to 788 GFLOPs when using BLIS-4.2.

This PR is ready to be merged, unless if there is any further comments. Thanks


Course code Button in calendar should be a Chip

The changes in #626 changed the Button component in the Course Render Pane to a Chip component in order to clean up messy styling. It overlooked the identical component also present in the Calendar Course Event popover. This should be fixed for visual consistency.

+1

I'll also add that you should take the clickToCopy() function from helpers.ts and put it in there because it's made specifically for the section code yet is named and placed as if it has a general purpose.


Include list of valid Main signatures

Any chance this article could contain the list of all valid signatures, like what is in the blog post C# 7 Series, Part 2: Async Main?
All the signatures can be inferred from the information given in this article, but I just find it easier to pick out the one I want from a list rather than read through the points and figure it out. It would also help newcomers to C# who may not see the direct relation from those point to what the code should actually look like.
This is the list I'm talking about:
public static void Main();
public static int Main();
public static void Main(string[] args);
public static int Main(string[] args);
public static Task Main();
public static Task<int> Main();
public static Task Main(string[] args);
public static Task<int> Main(string[] args);

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

ID: 6280abc4-899a-187d-1de4-1ea629ac5419
Version Independent ID: 24dbcd84-98c0-421e-d586-5d081ce2ec34
Content: Main() and command-line arguments - C# Programming Guide
Content Source: docs/csharp/programming-guide/main-and-command-args/index.md
Product: dotnet-csharp
Technology: csharp-fundamentals
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Thanks for pointing this out @gabeluci I agree, a list would be useful here.
I've added this to our backlog, and added the up-for-grabs label for any community members to address. If you'd like to submit a PR with the updates, I'll watch for it and help get it published.


Documentation Link Broken

System Health details
N/A
Checklist

[X] I have added battery_notes: to my configuration.yaml and restarted.
[X] I have read the FAQ's.
[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of any previous issues..

Describe the issue
The highlighted link in the image goes to a 404 page.

Reproduction steps
Click the link.
Debug logs
No response
Diagnostics dump
No response

Thanks, fixed now but you'll probably need to clear/reload the page in your browser to get the latest version immediately.

Confirmed fixed. Thanks for the quick responses.


[Firmata] missing void startSysex(void) method

Can you supply information as to why it is needed?

Firmata.cpp calls it "startSysex" / "endSysex" while I named it "beginSysex" / "endSysex" in UwpFirmata. I agree that it should have matched the latter, but not sure if we should change it now?

void FirmataClass::startSysex(void)
{
    FirmataStream->write(START_SYSEX);
}

bool
UwpFirmata::beginSysex(
    uint8_t command_
    )
{
    _sys_command = command_;
    _sys_position = 0;
    return true;
}

These do not have similar functionality...

We are trying to provide a familiar API surface, so we should at least have parity. I would take the logic from beginSysex(), move it startSysex(), then have beginSysex() call startSysex() and deprecate beginSysex().

We should revisit this issue. New UwpFirmata implementation does not use startSysex() or endSysex(). New function signatures are:
[Windows::Foundation::Metadata::DefaultOverload]
void
sendSysex(
        SysexCommand command_,
        IBuffer ^buffer_
    );

and
void
    sendSysex(
        uint8_t command_,
        IBuffer ^buffer_
    );

which allow the entire IBuffer to be sent at once. No more need to invoke 3 functions for one concept. It does not perfectly match the Firmata API (as this issue was meant to resolve) but is arguably more sensible on our platform.

I'll close this issue. The original observation is no longer valid.


Client Crash when attempting to load waypoints

When conecting to a server after you have set way points the client crashes
If you delete the folder
C:\Users\user\AppData\Roaming.minecraft(or in my case .technic)\modpacks\modpackname\saves\servername\
you can then reconect to the server without the client crashing.
https://pastebin.com/FcHgw3xv

Note this happens when the waypoints are shown in the world

i'll see if i can reproduce this. and add a null check so we dont crash any more

Thank you!

I was able to reproduce this today on a different PC on a different MC account. In case you need it and or it makes life easier for you here is the location of the mod pack https://www.technicpack.net/modpack/mittzfitz-testing.1134793
and the test server is beesyndicate.ddns.net:415

Hello again Vectron
I know that for most people these mods are a hobby and very understandably. many many other things in life take priority over them.
I was just wondering how this fix was going and if you have any sort of ETA?


does not build with latest rustc

Compiletest does not build with the latest rustc probably due to https://github.com/rust-lang/rust/pull/64663
   Compiling compiletest_rs v0.3.22
error[E0063]: missing field `report_time` in initializer of `test::TestOpts`
  --> /home/matthias/.cargo/registry/src/github.com-1ecc6299db9ec823/compiletest_rs-0.3.22/src/lib.rs:98:5
   |
98 |     test::TestOpts {
   |     ^^^^^^^^^^^^^^ missing `report_time`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0063`.
error: could not compile `compiletest_rs`.

We should probably just pass report_time: false, yeah?

I'm now getting this error when trying to compile this crate on the latest nightly:
error[E0560]: struct `test::TestOpts` has no field named `report_time`
   --> src/lib.rs:129:9
    |
129 |         report_time: false,
    |         ^^^^^^^^^^^ `test::TestOpts` does not have this field
    |
    = note: available fields are: `list`, `filter`, `filter_exact`, `exclude_should_panic`, `run_ignored` ... and 9 others

This will be automatically fixed in the next nightly, use the previous version of this crate till then.
We fixed the crate for rustc master since we needed that to handle a tangled web of tooling brokenness with Clippy and cargo.

While compiling this crate on its own seems to be fixed on the new nightly, I'm still seeing this issue when trying to run Rocket's scripts/test.sh.
$ rustc --version
rustc 1.40.0-nightly (37538aa13 2019-09-25)

This field is not conditioned on norustc, which I believe causes the error - Rocket uses the stable feature of compiletest.


Immediate work will not run if another periodic work can run during this period

I have this periodic work scheduled like this:
val expireNotificationWork = PeriodicWorkRequestBuilder<ShoppingListNotificationWorker>(1, TimeUnit.DAYS) // This will default to flex 1 day
                    .addTag(TAG_1)
                    .build()

            WorkManager.getInstance()?.enqueueUniquePeriodicWork(
                    jobName,
                    ExistingPeriodicWorkPolicy.REPLACE,
                    expireNotificationWork)

And an immediate work enqueued like this
val connectedConstraints = Constraints.Builder()
                    .setRequiredNetworkType(NetworkType.CONNECTED)
                    .build()

            val immediateWork = OneTimeWorkRequestBuilder<UpdateGeofencesWorker>()
                    .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 2, TimeUnit.SECONDS)
                    .setConstraints(connectedConstraints)
                    .addTag(ONETIME_TAG)
                    .build()

WorkManager.getInstance()?.enqueue(immediateWork)

Every time I enqueue the immediate work only the periodic work will run and not any one time work.
So the periodic work will run multiple times per day but the one time work never.

This is on 1.0.0-alpha4

Thanks for reporting this.
I'm closing this issue because this forum is for issues with the codelab.
If you think that this is a problem of the WorkManager library, please open a bug on the WorkManager public issue tracker: https://issuetracker.google.com/issues/new?component=409906&template=1094197
Please reopen if you still think this is an issue with the codelab.


Implement Flag for allowing tethering mode to work with CIQ simulator

Added flag for choosing between ConnectIQ.IQConnectType.WIRELESS and ConnectIQ.IQConnectType.TETHERED when initializing ConnectIQ.  Defaults to WIRELESS

Only thing i am not certain about is use of uppercase() on enum name because I wasn't sure how strings are handled in conversion.

The only issue with that is it won't convert to SCREAMING_SNAKE_CASE. You can use the recase package in Dart to do that before you send the value

The only issue with that is it won't convert to SCREAMING_SNAKE_CASE. You can use the recase package in Dart to do that before you send the value

Is it worth having the extra dependency when it isn't really being used at this point?  I can shift the casing change to the flutter side (.toUpperCase() on enum name value) so it would be easy to add that package if there are constant case multi word values added to that enum.

I suppose not as long as we remember to actually do it if we need to in the future. The code is technically wrong even though it gives the correct result right now.


Course10

What does this PR do?
Add resource(s) | Remove resource(s) | Add info | Improve repo
For resources
Description
Javascript tutorial in kannada
Why is this valuable (or not)?
it will teach people who speak Kannada how to code in java script eventually making their society more advanced
How do we know it's really free?
its is free on youtube
For book lists, is it a book? For course lists, is it a course? etc.
Checklist:

[x] Read our contributing guidelines.
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction).
[x] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

Be sure to check the free-programming-books-lint output for linter errors. Alphabetical order and spacing are the most common problems.


[Feature Request] link() helper on CrudColumn and certain CrudFields

Feature Request
What's the feature you think Backpack should have?
Backpack just implemented the relationship option for ajax selects and multiple selects. It would be nice to have a property in these select fields along the lines of 'hyperlink => true', which would make the items that are listed out clickable and would allow the user to navigate to that specific model's CRUD Controller to edit / view that item by clicking on it.
Right now our clients ask for this all the time and we end up building out custom templates for this which is a lot of work and renders a large feature of backpack pretty useless for us because of a smaller requirement.
Have you already implemented a prototype solution, for your own project?
No
Do you see this as a core feature or an add-on?
Core Feature

Totally agree. It was talked about when we first launched 4.2, but we haven't gotten to it (yet).
The way I see it, it would be link() or linkTo() or linksTo(), not hyperlink() which is longer and rarely used, I think. And the parameter would be probably be the Controller it would point to (or Model, whichever is actually needed to achieve this).
So for Columns you'd be able to do:
// if we need it to point to the CrudController
CRUD::column('category')->link(\App\Http\Controllers\Admin\CategoryCrudController::class);
CRUD::column('category')->linkTo(\App\Http\Controllers\Admin\CategoryCrudController::class);
CRUD::column('category')->linksTo(\App\Http\Controllers\Admin\CategoryCrudController::class);

// if we need it to point to the Model
CRUD::column('category')->link(\App\Models\Category::class);

// actually if what we need is the model (unlikely) we can probably guess it from the field, so it would be
CRUD::column('category`)->link();
// or
CRUD::column('category`)->withLinks();

After writing this I've realised you mentioned FIELDS not COLUMNS - and I guess we can do that for the relationship field too, indeed. Though it should probably open the link in a new tab there, to prevent the unwanted situation where the admin edits something, clicks a link to a related item, then loses all their changes.
--
Thanks for raising this @selected-pixel-jameson - it's indeed a feature that will probably help out a lot. I've prioritised it so we get it done within 4.1 as a non-breaking change.
Cheers!

In terms of implementation, I see this as a convenience method on CrudColumn, just like size() on the CrudField class. It wouldn't be an attribute per-se, but a convenience method that helps set the:

wrapper[element] to a;
wrapper[href] to the route to the show method for that particular entry;

@tabacitu atm our wrapper wraps the field itself, to accomodate this we must change wrapper implementation as we did in columns to be in every selected entry instead of the whole field.

😭 Ok then.
I definitely think we should automate it for columns with a link() - that's what a developer wants 99% of the time.
I don't know about fields, then... Will think about it... My first thought is that it's not worth rewriting the wrapper feature for this little. Not sure people actually want to open the related entry from the Create / Update form... (@selected-pixel-jameson please correct me if I'm wrong).

Technically in columns we already have the option to open each individual selected entry with their own anchor, so clicking it would render whatever link developer wants.
From what I see, this link() helper would be a replace for wrapper, so why not use wrapper() instead ?

@pxpm in columns, that's what link() should do behind the scenes - set the wrapper to an anchor with a href pointing to that entry's Show operation. It'd be just for convenience, instead of having to write:
                CRUD::column('category`)->wrapper([
                    'href' => function ($crud, $column, $entry, $related_key) {
                        return backpack_url('category/'.$related_key.'/show');
                    },
                ]);

you'd write:
                CRUD::column('category`)->link();
                // or
                CRUD::column('category`)->withLinks();
                // or
                CRUD::column('category`)->withLinksToShow();
                // or
                CRUD::column('category`)->linkToShow();

Or something like that, I'm not sure what the best name would be.


[Fix #1612] Allowed expand_path on inherit_from in .rubocop.yml

I think this [Fix #1612], but let me know if I'm missing anything!

Ok I updated my pul request with @Koronen feedback. Thanks for your help!

Ok I updated my pul request with @Koronen feedback. Thanks for your help!

LGTM! :+1:

This needs to be rebased.

Hmm so I ran git rebase upstream/master from my feature branch and it said, Current branch add-expand_path-on-inherit_from is up to date.
Am I missing something about how to perform a proper rebase?

@mattjmcnaughton Seems to me you're doing the right thing. Try pulling the master locally and rebasing on top of it.

 Sorry I'm just new to the whole process of rebasing.

 Sorry I'm just new to the whole process of rebasing.

Yes.

Ok done!

Coverage decreased (-0.16%) to 99.48% when pulling ea8b085ada20cdd0e8618c9402fb49c6ad1d962c on mattjmcnaughton:add-expand_path-on-inherit_from into aa4159c254cec127158a8c792ac88d5b011749dc on bbatsov:master.

Coverage decreased (-0.16%) to 99.48% when pulling ea8b085ada20cdd0e8618c9402fb49c6ad1d962c on mattjmcnaughton:add-expand_path-on-inherit_from into aa4159c254cec127158a8c792ac88d5b011749dc on bbatsov:master.

:+1:


pkgsStatic.gcc: fix build

Description of changes
There's no libgcc.so in a static-only build.
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/unable-to-build-pkgsstatic-gcc/27795/9

@ofborg build pkgsStatic.gcc


Release v1.1.1

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).

Will rebase when #584 is merged.


One pen to draw them all advancement given automatically

The One pen to draw them all advancement is given to the player as soon as anything enters their inventory the first time.

Hi NillerMed, oky let me have a look at this (the first advancement I ever made, yay) - it worked fine on my SMP server strangely.
Was this in on a new world (e.g. your setup) or could people have already had the pen in the inventory before, so that the advancement triggered because it was added later? Cheers,-

Okay, MC1.16 somehow has a problem with that advancement JSON, I presume the advancement is anyway important to a "major minority", so I simply removed it for the back port. The fix version is redstonepen-1.16.5-1.0.8-b3.  It's already in the approval process on Curse.
Thanks again for the hint! Cheers,-

Thank you kindly :D


test: Cypress | Flaky fixes

Description

This PR fixes below specs:
cypress/e2e/Regression/ClientSide/BugTests/AbortAction_Spec.ts (running below multiple times to remove from flakylist)
Flaky fixes
-- cypress/e2e/Regression/ClientSide/Widgets/Others/StatboxDsl_spec.js
-- cypress/e2e/Regression/ClientSide/Widgets/Others/IconButton_2_spec.ts

Type of change

Script fix (non-breaking change which fixes an issue)

Testing
How Has This Been Tested?

[X] Cypress CI runs

Checklist:
QA activity:

[X] Added Test Plan Approved label after Cypress tests were reviewed

Summary by CodeRabbit

Tests

Updated Cypress regression tests to use StatboxDsl_spec.js instead of Fork_Template_spec.js.
Adjusted test case numbers and content for "tooltip" and "visible and disabled toggle" tests.
Removed and renumbered test case "4. Verify onClick".
Added a new test case "7. Verify onClick" with updated logic for testing onClick functionality.

/ci-test-limit runId=7781227214

/ci-test-limit runId=7781227214

/ci-test-limit runId=7781227214

/ci-test-limit

/ci-test-limit runId=7782951873

/ci-test-limit runId=7782951873

/ci-test-limit runId=7782951873

/ci-test-limit runId=7782951873

/ci-test-limit runId=7782951873


x86: Add endbranch to indirect branch targets for Intel CET

To support Intel CET, all indirect branch targets must start with
endbranch.  Here is a patch to add endbranch to all function entries
in x86 assembly codes which are indirect branch targets as discovered
by running openssl testsuite on Intel CET machine and visual inspection.
Since x86 cbc.pl uses indirect branch with a jump table, we also need
to add endbranch to all jump targets.

Merged to master.  Thanks for the submission.


Update third party

Cfr. #74
Will update with latest remotes first.

@NicolasT, could you rebase to get an eve/main.yml ?

@Zempashi Please re-review (couple of minor changes in new commits)


a bunch of errors on npm install

I couldn't even run the app, here is what I got on npm install
MacBook-Air:ReactNativeSampleApp-master Arbor$ npm install

><EMAIL_ADDRESS>install /Users/Arbor/Desktop/ReactNativeSampleApp-master/node_modules/appium/node_modules/bufferutil
> node-gyp rebuild

  CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
In file included from ../src/bufferutil.cc:16:
../../nan/nan.h:261:25: error: redefinition of '_NanEnsureLocal'
NAN_INLINE v8::Local<T> _NanEnsureLocal(v8::Local<T> val) {
                        ^
../../nan/nan.h:256:25: note: previous definition is here
NAN_INLINE v8::Local<T> _NanEnsureLocal(v8::Handle<T> val) {
                        ^
../../nan/nan.h:661:13: error: no member named 'smalloc' in namespace 'node'
    , node::smalloc::FreeCallback callback
      ~~~~~~^
../../nan/nan.h:672:12: error: no matching function for call to 'New'
    return node::Buffer::New(v8::Isolate::GetCurrent(), data, size);
           ^~~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/node_buffer.h:31:40: note: candidate function not viable: no known conversion from 'uint32_t' (aka 'unsigned int') to 'enum encoding' for 3rd argument
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
/Users/Arbor/.node-gyp/5.7.0/include/node/node_buffer.h:43:40: note: candidate function not viable: 2nd argument ('const char *') would lose const qualifier
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
/Users/Arbor/.node-gyp/5.7.0/include/node/node_buffer.h:28:40: note: candidate function not viable: requires 2 arguments, but 3 were provided
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate, size_t length);
                                       ^
/Users/Arbor/.node-gyp/5.7.0/include/node/node_buffer.h:36:40: note: candidate function not viable: requires 5 arguments, but 3 were provided
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
In file included from ../src/bufferutil.cc:16:
../../nan/nan.h:676:12: error: no viable conversion from 'v8::MaybeLocal<v8::Object>' to 'v8::Local<v8::Object>'
    return node::Buffer::New(v8::Isolate::GetCurrent(), size);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:210:7: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'v8::MaybeLocal<v8::Object>' to
      'const v8::Local<v8::Object> &' for 1st argument
class Local {
      ^
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:210:7: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'v8::MaybeLocal<v8::Object>' to
      'v8::Local<v8::Object> &&' for 1st argument
class Local {
      ^
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:214:13: note: candidate template ignored: could not match 'Local' against 'MaybeLocal'
  V8_INLINE Local(Local<S> that)
            ^
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:326:13: note: candidate template ignored: could not match 'S *' against 'v8::MaybeLocal<v8::Object>'
  V8_INLINE Local(S* that)
            ^
In file included from ../src/bufferutil.cc:16:
../../nan/nan.h:683:26: error: no member named 'Use' in namespace 'node::Buffer'
    return node::Buffer::Use(v8::Isolate::GetCurrent(), data, size);
           ~~~~~~~~~~~~~~^
In file included from ../src/bufferutil.cc:7:
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:221:5: error: assigning to 'v8::Primitive *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../../nan/nan.h:414:12: note: in instantiation of function template specialization 'v8::Local<v8::Primitive>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(v8::Undefined(v8::Isolate::GetCurrent())));
           ^
../../nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
In file included from ../src/bufferutil.cc:7:
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:221:5: error: assigning to 'v8::Boolean *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../../nan/nan.h:424:12: note: in instantiation of function template specialization 'v8::Local<v8::Boolean>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(v8::True(v8::Isolate::GetCurrent())));
           ^
../../nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
In file included from ../src/bufferutil.cc:7:
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:221:5: error: assigning to 'v8::Function *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../../nan/nan.h:1514:12: note: in instantiation of function template specialization 'v8::Local<v8::Function>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(handle)->Get(kCallbackIndex)
           ^
../../nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
In file included from ../src/bufferutil.cc:7:
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:221:5: error: assigning to 'v8::Object *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../../nan/nan.h:1632:12: note: in instantiation of function template specialization 'v8::Local<v8::Object>::Local<v8::Value>' requested here
    return NanEscapeScope(handle->Get(NanNew(key)).As<v8::Object>());
           ^
../../nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
9 errors generated.
make: *** [Release/obj.target/bufferutil/src/bufferutil.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:100:13)
gyp ERR! stack     at ChildProcess.emit (events.js:185:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Darwin 15.3.0
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/Arbor/Desktop/ReactNativeSampleApp-master/node_modules/appium/node_modules/bufferutil
gyp ERR! node -v v5.7.0
gyp ERR! node-gyp -v v3.2.1
gyp ERR! not ok
npm WARN<EMAIL_ADDRESS><EMAIL_ADDRESS>install: `node-gyp rebuild`
npm WARN<EMAIL_ADDRESS>Exit status 1

><EMAIL_ADDRESS>install /Users/Arbor/Desktop/ReactNativeSampleApp-master/node_modules/appium/node_modules/utf-8-validate
> node-gyp rebuild

  CXX(target) Release/obj.target/validation/src/validation.o
In file included from ../src/validation.cc:15:
../../nan/nan.h:261:25: error: redefinition of '_NanEnsureLocal'
NAN_INLINE v8::Local<T> _NanEnsureLocal(v8::Local<T> val) {
                        ^
../../nan/nan.h:256:25: note: previous definition is here
NAN_INLINE v8::Local<T> _NanEnsureLocal(v8::Handle<T> val) {
                        ^
../../nan/nan.h:661:13: error: no member named 'smalloc' in namespace 'node'
    , node::smalloc::FreeCallback callback
      ~~~~~~^
../../nan/nan.h:672:12: error: no matching function for call to 'New'
    return node::Buffer::New(v8::Isolate::GetCurrent(), data, size);
           ^~~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/node_buffer.h:31:40: note: candidate function not viable: no known conversion from 'uint32_t' (aka 'unsigned int') to 'enum encoding' for 3rd argument
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
/Users/Arbor/.node-gyp/5.7.0/include/node/node_buffer.h:43:40: note: candidate function not viable: 2nd argument ('const char *') would lose const qualifier
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
/Users/Arbor/.node-gyp/5.7.0/include/node/node_buffer.h:28:40: note: candidate function not viable: requires 2 arguments, but 3 were provided
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate, size_t length);
                                       ^
/Users/Arbor/.node-gyp/5.7.0/include/node/node_buffer.h:36:40: note: candidate function not viable: requires 5 arguments, but 3 were provided
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
In file included from ../src/validation.cc:15:
../../nan/nan.h:676:12: error: no viable conversion from 'v8::MaybeLocal<v8::Object>' to 'v8::Local<v8::Object>'
    return node::Buffer::New(v8::Isolate::GetCurrent(), size);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:210:7: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'v8::MaybeLocal<v8::Object>' to
      'const v8::Local<v8::Object> &' for 1st argument
class Local {
      ^
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:210:7: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'v8::MaybeLocal<v8::Object>' to
      'v8::Local<v8::Object> &&' for 1st argument
class Local {
      ^
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:214:13: note: candidate template ignored: could not match 'Local' against 'MaybeLocal'
  V8_INLINE Local(Local<S> that)
            ^
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:326:13: note: candidate template ignored: could not match 'S *' against 'v8::MaybeLocal<v8::Object>'
  V8_INLINE Local(S* that)
            ^
In file included from ../src/validation.cc:15:
../../nan/nan.h:683:26: error: no member named 'Use' in namespace 'node::Buffer'
    return node::Buffer::Use(v8::Isolate::GetCurrent(), data, size);
           ~~~~~~~~~~~~~~^
In file included from ../src/validation.cc:7:
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:221:5: error: assigning to 'v8::Primitive *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../../nan/nan.h:414:12: note: in instantiation of function template specialization 'v8::Local<v8::Primitive>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(v8::Undefined(v8::Isolate::GetCurrent())));
           ^
../../nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
In file included from ../src/validation.cc:7:
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:221:5: error: assigning to 'v8::Boolean *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../../nan/nan.h:424:12: note: in instantiation of function template specialization 'v8::Local<v8::Boolean>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(v8::True(v8::Isolate::GetCurrent())));
           ^
../../nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
In file included from ../src/validation.cc:7:
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:221:5: error: assigning to 'v8::Function *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../../nan/nan.h:1514:12: note: in instantiation of function template specialization 'v8::Local<v8::Function>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(handle)->Get(kCallbackIndex)
           ^
../../nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
In file included from ../src/validation.cc:7:
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:221:5: error: assigning to 'v8::Object *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/Arbor/.node-gyp/5.7.0/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../../nan/nan.h:1632:12: note: in instantiation of function template specialization 'v8::Local<v8::Object>::Local<v8::Value>' requested here
    return NanEscapeScope(handle->Get(NanNew(key)).As<v8::Object>());
           ^
../../nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
9 errors generated.
make: *** [Release/obj.target/validation/src/validation.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:100:13)
gyp ERR! stack     at ChildProcess.emit (events.js:185:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Darwin 15.3.0
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/Arbor/Desktop/ReactNativeSampleApp-master/node_modules/appium/node_modules/utf-8-validate
gyp ERR! node -v v5.7.0
gyp ERR! node-gyp -v v3.2.1
gyp ERR! not ok
npm WARN<EMAIL_ADDRESS><EMAIL_ADDRESS>install: `node-gyp rebuild`
npm WARN<EMAIL_ADDRESS>Exit status 1

Thanks.

any success in getting this to work? maybe it's a different node version or something?

for me it installed without errors by upgrading node-inspector from 0.12.3 to 0.12.8.
(node version 6.3.0 and npm version 3.10.3)

npm install fails even after upgrading node-inspector
npm ERR! Darwin 15.3.0
npm ERR! argv "/usr/local/Cellar/node/6.4.0/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v6.4.0
npm ERR! npm  v3.10.3
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>install: `node-pre-gyp install --fallback-to-build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the v8-profiler package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs v8-profiler
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls v8-profiler
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/preetam/Documents/react_samples/react-native/ReactNativeSampleApp/npm-debug.log
npm ERR! code 1

npm-debug.txt

I have the same issue. I still couldn't resolve the issue until now.

@preetb123 @haojiezhang what node and npm versions are you using?

BLs-MacBook:ReactNativeSampleApp brian$ npm -v
3.10.5
BLs-MacBook:ReactNativeSampleApp brian$ node -v
v5.4.1

maybe this should use .nvmrc  Anyone have any thoughts on that r what to make it happen?

upgraded node-inspector here since that seemed to help some people: https://github.com/taskrabbit/ReactNativeSampleApp/pull/30

I'm getting this issue during run on Android
\TestRunnerManager.java:14: error: cannot find symbol
private @Nullable DevSupportManager mDevSupportManager;
^
symbol:   class DevSupportManager
location: class TestRunnerManager
D:\react_native\ReactNativeSampleApp-master\android\app\src\main\java\com\sample
\MainApplication.java:19: error: getUseDeveloperSupport() in <anonymous com.samp
le.MainApplication$1> cannot override getUseDeveloperSupport() in ReactNativeHos
t
protected boolean getUseDeveloperSupport() {
^
attempting to assign weaker access privileges; was public
D:\react_native\ReactNativeSampleApp-master\android\app\src\main\java\com\sample
\TestRunnerManager.java:30: error: cannot find symbol
mDevSupportManager = (DevSupportManager) field.get(mReactContext);
^
symbol:   class DevSupportManager
location: class TestRunnerManager
Note: D:\react_native\ReactNativeSampleApp-master\android\app\src\main\java\com
sample\TLSSetup.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
4 errors
:app:compileDebugJavaWithJavac FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:compileDebugJavaWithJavac'.

Compilation failed; see the compiler error output for details.

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output.

BUILD FAILED
Total time: 7.207 secs
Could not install the app on the device, read the error above for details.
Make sure you have an Android emulator running or a device connected and have
set up your Android development environment:
https://facebook.github.io/react-native/docs/android-setup.html


Scaling while zooming

Hello,
As you see in the attached screenshot, I found that when zooming the scaling of the grid shows strange behavior, in which, the point is divided into a value on the left of the grid and the rest of it above.
Is it possible to enhance the scaling to show the number as a whole on both axis?
Thanks in advance for your help.
BR
Fady

Hi @FadyDev, this post doesn't have a screenshot. Can you add one or post a code sample to help me reproduce this behavior? Thanks!

Hi,
Sorry, I think I had some connection problems while uploading. Here is the screenshot :)

Hallo @swharden
I added the screenshot right after your reminder. I hope you could find a solution for that problem.

Hi @FadyDev, thanks for the screenshot. I'm still a little confused what the problem is though...
Are you asking why this numbers is here?

That number is offset notation.
http://swharden.com/scottplot/cookbooks/4.0.29/#customize-ticks-offset-notation
Offset notation is disabled by default in ScottPlot 4.0.29. You can manually disable it like this:
plt.Ticks(useOffsetNotation: false);

Does this answer your question?


Docgen API throws errors when compiling old balas

 @xlight05 cloned issue wso2-enterprise/ballerina-registry#1999 on 2023-03-16:

Description:
$Subject. This occurs with the new change of not generating api docs if it compilation errors with 2201.4.0.
Since ballerina central just uses project API of the latest stable ballerina version to compile the balas uploaded to central to generate api docs, with the above recent change, when an old bala compiled with an older version, is pushed to central, it fails to generate api docs.
We need to think of possible ways to solve this issue.

Pack API docs, triggers and connectors json with the bala and central can consume them. This will remove the need to compile bala from central.

Central needs to compile the package with the pushed ballerina lang dist version. Therefore needs multi-distribution support. This will complicate the implementation a lot.

 @xlight05 commented on 2023-03-16:

Reverted the change until we have a proper solution from the central side.
https://github.com/ballerina-platform/ballerina-lang/pull/39901
https://github.com/ballerina-platform/ballerina-lang/pull/39899
https://github.com/ballerina-platform/ballerina-lang/pull/39902


Write Part - 2 Step - 3 & unit test

Implement Step03Controller and write all unit tests. Verify the display name of the test conforms to the pattern of "Part X Step Y". Follow the standardize naming, comments, etc. to be consistent.

Does some of the same things as Part 01 Step 04


Provide a better error message when builder == null for MaterialPageRoute

Steps to Reproduce

Navigating to a namedRoute using onGenerateRoute. parts[1] should not be null
      onGenerateRoute: (RouteSettings settings) {
        WidgetBuilder _builder;
        List<String> parts = settings.name.split("/");
        if (parts[0] == 'tallydetails') {
          _builder = (context) => TallySheet(title: parts[1]);
        }
        return new MaterialPageRoute(builder: _builder, settings: settings);
      },

Logs
Here is the dump in vsCode
Launching lib\main.dart on Android SDK built for x86 in debug mode...
Built build\app\outputs\apk\debug\app-debug.apk.
I/flutter (20260): == snapshot
D/        (20260): HostConnection::get() New Host Connection established 0x9f317980, tid 20304
D/EGL_emulation(20260): eglMakeCurrent: 0x9c8134e0: ver 3 0 (tinfo 0x9f3032e0)
I/flutter (20260): ══╡ EXCEPTION CAUGHT BY GESTURE ╞═══════════════════════════════════════════════════════════════════
I/flutter (20260): The following assertion was thrown while handling a gesture:
I/flutter (20260): 'package:flutter/src/material/page.dart': Failed assertion: line 49 pos 15: 'builder != null': is
I/flutter (20260): not true.
I/flutter (20260):
I/flutter (20260): Either the assertion indicates an error in the framework itself, or we should provide substantially
I/flutter (20260): more information in this error message to help you determine and fix the underlying cause.
I/flutter (20260): In either case, please report this assertion by filing a bug on GitHub:
I/flutter (20260):   https://github.com/flutter/flutter/issues/new?template=BUG.md
I/flutter (20260):
I/flutter (20260): When the exception was thrown, this was the stack:
I/flutter (20260): #2      new MaterialPageRoute
I/flutter (20260): #3      MyApp.build.<anonymous closure>
I/flutter (20260): #4      _WidgetsAppState._onGenerateRoute
I/flutter (20260): #5      NavigatorState._routeNamed
I/flutter (20260): #6      NavigatorState.pushNamed
I/flutter (20260): #7      new TallyView.<anonymous closure>
I/flutter (20260): #8      _InkResponseState._handleTap
I/flutter (20260): #9      _InkResponseState.build.<anonymous closure>
I/flutter (20260): #10     GestureRecognizer.invokeCallback
I/flutter (20260): #11     TapGestureRecognizer._checkUp
I/flutter (20260): #12     TapGestureRecognizer.handlePrimaryPointer
I/flutter (20260): #13     PrimaryPointerGestureRecognizer.handleEvent
I/flutter (20260): #14     PointerRouter._dispatch
I/flutter (20260): #15     PointerRouter.route
I/flutter (20260): #16     _WidgetsFlutterBinding&BindingBase&GestureBinding.handleEvent
I/flutter (20260): #17     _WidgetsFlutterBinding&BindingBase&GestureBinding.dispatchEvent
I/flutter (20260): #18     _WidgetsFlutterBinding&BindingBase&GestureBinding._handlePointerEvent
I/flutter (20260): #19     _WidgetsFlutterBinding&BindingBase&GestureBinding._flushPointerEventQueue
I/flutter (20260): #20     _WidgetsFlutterBinding&BindingBase&GestureBinding._handlePointerDataPacket
I/flutter (20260): #21     _invoke1 (dart:ui/hooks.dart:168:13)
I/flutter (20260): #22     _dispatchPointerDataPacket (dart:ui/hooks.dart:122:5)
I/flutter (20260): (elided 2 frames from class _AssertionError)
I/flutter (20260):
I/flutter (20260): Handler: onTap
I/flutter (20260): Recognizer:
I/flutter (20260):   TapGestureRecognizer#55f95(debugOwner: GestureDetector, state: possible, won arena, finalPosition:
I/flutter (20260):   Offset(368.3, 637.6), sent tap down)
I/flutter (20260): ════════════════════════════════════════════════════════════════════════════════════════════════════

Find the issue, not a bug. The builder was being set to null. You can close the bug or as you indicate provide more diagnostics.

I'm going to close. I think the error message is pretty clear.


DraggableCore: throttle drag events

For performance heavy eventhandlers it's often necessary to throttle drag events before handling them.
Currently this is made difficult due to the fact that if one throttles the dragHandler, one simply misses events; i.e. deltas are not grouped together easily.
Is this something that DraggableCore could support?
One idea would be to add a property that sets a time-window and emit only one event for the set of underlying drag events that happened in that window. Deltas should be summed within the window.

Why not throttle the expensive part of your handler? I'd like to keep that
kind of complexity out of this module.
On Jul 7, 2016 7:27 AM, "Arjen Jonathan"<EMAIL_ADDRESS>wrote:

For performance heavy eventhandlers it's often necessary to throttle drag
events before handling them.
Currently this is made difficult due to the fact that if one throttles the
dragHandler, one simply misses events; i.e. deltas are not grouped together
easily.
Is this something that DraggableCore could support?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mzabriskie/react-draggable/issues/172, or mute the
thread
https://github.com/notifications/unsubscribe/ABJFPxb60rL5uW_GyyqOW7Fe9WqT1dXsks5qTPDJgaJpZM4JHBvm
.

Yeah that's definitly possible. It's just that there is a large "common" part in throttling drag-events and only a very small usage-part. So conceptually it made sense to me to have it as part of react-draggable for reuse.
It doesn't need to be part of DraggableCore of course. It could be a component that composes DraggableCore.

Technically you could also use <Draggable>, set the axis to 'none' to prevent moving while dragging and set the position property yourself. Then just listen to drag events. <Draggable> will keep track of its own position.
Depending on what you're doing that may be more or less complicated than writing your own HOC.

Interesting approach. I assume Draggable doesn't add much unnecessary overhead to the handler?

Not really. The main difference is that it manages CSS translations itself (which you can turn off with axis) and it manages its own state, which is mandatory if you want it to tell you how much it's moved in absolute terms, no matter how many drag messages you ignore.

From my own experience, when dragging elements on screen, deltas are something you don't want to rely on. You should only rely on "absolute" delta, which implies that draggable should save the starting point from where the drag started. A difference between the current point and the starting one gives you the absolute delta (draggable could also provide a helper method for it).
This absolute delta is immune to throttling.
Danko

On 07.07.2016., at 14:27, Arjen Jonathan<EMAIL_ADDRESS>wrote:
For performance heavy eventhandlers it's often necessary to throttle drag events before handling them.
Currently this is made difficult due to the fact that if one throttles the dragHandler, one simply misses events; i.e. deltas are not grouped together easily.
Is this something that DraggableCore could support?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Yes, which involves state. <DraggableCore> is stateless. <Draggable>
is not. That's why there are two components.

Danko Kozar<EMAIL_ADDRESS>July 7, 2016 at 8:25 AM
From my own experience, when dragging elements on screen, deltas are
something you don't want to rely on. You should only rely on
"absolute" delta, which implies that draggable should save the
starting point from where the drag started. A difference between the
current point and the starting one gives you the absolute delta
(draggable could also provide a helper method for it).
This absolute delta is immune to throttling.
Danko

On 07.07.2016., at 14:27, Arjen Jonathan<EMAIL_ADDRESS>wrote:
For performance heavy eventhandlers it's often necessary to throttle
drag events before handling them.
Currently this is made difficult due to the fact that if one
throttles the dragHandler, one simply misses events; i.e. deltas are
not grouped together easily.
Is this something that DraggableCore could support?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mzabriskie/react-draggable/issues/172#issuecomment-231076310,
or mute the thread
https://github.com/notifications/unsubscribe/ABJFP-DaIZXffaQwX1sOG67HWPJXZ1MVks5qTP4tgaJpZM4JHBvm.

I would say not necessary the React state (used to trigger render), but non-state non-props DOM- related "state" (simple Javascript variable holding the coordinate of drag start).
But yeah, people for some reason avoid to use simple JS outside of React state.
Danko

On 07.07.2016., at 15:28, Samuel Reed<EMAIL_ADDRESS>wrote:
Yes, which involves state. <DraggableCore> is stateless. <Draggable>
is not. That's why there are two components.

Danko Kozar<EMAIL_ADDRESS>July 7, 2016 at 8:25 AM
From my own experience, when dragging elements on screen, deltas are
something you don't want to rely on. You should only rely on
"absolute" delta, which implies that draggable should save the
starting point from where the drag started. A difference between the
current point and the starting one gives you the absolute delta
(draggable could also provide a helper method for it).
This absolute delta is immune to throttling.
Danko

On 07.07.2016., at 14:27, Arjen Jonathan<EMAIL_ADDRESS>wrote:
For performance heavy eventhandlers it's often necessary to throttle
drag events before handling them.
Currently this is made difficult due to the fact that if one
throttles the dragHandler, one simply misses events; i.e. deltas are
not grouped together easily.
Is this something that DraggableCore could support?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mzabriskie/react-draggable/issues/172#issuecomment-231076310,
or mute the thread
https://github.com/notifications/unsubscribe/ABJFP-DaIZXffaQwX1sOG67HWPJXZ1MVks5qTP4tgaJpZM4JHBvm.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

It is intentional as it has previously been very painful to manage
overriding state in these components. I have built several large projects
on top of Draggable and thus I built something simple and stateless. It's
purpose is only to abstract away browser difficulties. It is a building
block.
If you need more, build a hoc.
On Jul 7, 2016 9:01 AM, "Danko Kozar"<EMAIL_ADDRESS>wrote:

I would say not necessary the React state (used to trigger render), but
non-state non-props DOM- related "state" (simple Javascript variable
holding the coordinate of drag start).
But yeah, people for some reason avoid to use simple JS outside of React
state.
Danko

On 07.07.2016., at 15:28, Samuel Reed<EMAIL_ADDRESS>wrote:
Yes, which involves state. <DraggableCore> is stateless. <Draggable>
is not. That's why there are two components.

Danko Kozar<EMAIL_ADDRESS>July 7, 2016 at 8:25 AM
From my own experience, when dragging elements on screen, deltas are
something you don't want to rely on. You should only rely on
"absolute" delta, which implies that draggable should save the
starting point from where the drag started. A difference between the
current point and the starting one gives you the absolute delta
(draggable could also provide a helper method for it).
This absolute delta is immune to throttling.
Danko

On 07.07.2016., at 14:27, Arjen Jonathan<EMAIL_ADDRESS>wrote:
For performance heavy eventhandlers it's often necessary to throttle
drag events before handling them.
Currently this is made difficult due to the fact that if one
throttles the dragHandler, one simply misses events; i.e. deltas are
not grouped together easily.
Is this something that DraggableCore could support?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/mzabriskie/react-draggable/issues/172#issuecomment-231076310
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ABJFP-DaIZXffaQwX1sOG67HWPJXZ1MVks5qTP4tgaJpZM4JHBvm
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mzabriskie/react-draggable/issues/172#issuecomment-231086216,
or mute the thread
https://github.com/notifications/unsubscribe/ABJFP3e_4LLrblCUyNSvD0tO_76KksS3ks5qTQaegaJpZM4JHBvm
.


Drop bandit, pycodestyle, pydocstyle, and yapf from the Python image

All of those tools are being dropped from the Python extension for VS Code due to lack of usage.

Hi 👋
Thanks for the information. To remove these utils from the python image, they first need to be removed from the Python Feature here
ℹ dev.md & manifest.json are autogenerated docs which will get overwritten unless we remove them from the Python Feature. The only change needed for images will be removing the checks from test.sh and releasing new images. 😄
// cc @Chuxel / @bamurtaugh / @craiglpeters Any thoughts/concerns for removing these utils from the Python Feature (which will end up getting removed from the images as well) ?
I could help with the cleanup if there are no concerns.

I'm all in favor of cleanup wherever possible like this!
@brettcannon How are you notifying users of this change in the Python extension? Since it sounds like this could be potentially breaking for a small number of users, curious on the approach.
As a sanity check we could perform before removing, we could post this PR in the dev container community Slack channel as a heads up and see if anyone from that group would be impacted or knows of a scenario that would be.

To remove these utils from the python image, they first need to be removed from the Python Feature here

Already done in https://github.com/devcontainers/features/pull/449 .

How are you notifying users of this change in the Python extension?

We're not there yet, this is just pre-emptive so users don't start using these tools and then have them disappear on them in a few months.

As a sanity check we could perform before removing, we could post this PR in the dev container community Slack channel as a heads up and see if anyone from that group would be impacted or knows of a scenario that would be.

Do note this is somewhat of a part 1 of 2. Nearly all the tools left behind will eventually be in separate extensions which ship them in-box. As I said, I'm doing this now so people don't start to rely on things I know are on there way out the door, but I didn't want to be too disruptive by yanking stuff that will work somehow, just perhaps via a separate extension.

For me, the key thing is certain things shouldn't get lit up for the Python extension for VS Code (e.g. don't turn on Pylint on by default, don't direct people towards yapf). Knowing that, how would you prefer me to handle that? Do you just want me to turn off everything or ignore the tools in https://github.com/devcontainers/features/pull/449 instead? I'm just not clear on how I should view this image since it seems to install things based on the Python extension, but if that was just a way to start this and I should view this as independent of the extension that's obviously fine.

For me, the key thing is certain things shouldn't get lit up for the Python extension for VS Code

This is helpful context. Since these images are for us in any dev container spec-supporting tools, including but not limited to VS Code, I could see the potential for some deviation.
From my understanding, the change in the Features PR that updates VS Code settings would make sense to merge in, as this is a VS Code-specific aspect of the Feature setup. But, I think we'd want to leave general support for these libraries in other parts of the image and Feature if they're going to come back in through separate extensions as you mention?

I'll focus on updating the settings over in https://github.com/devcontainers/features/pull/449/ then and close this out to leave the base image alone.

I think we'd want to leave general support for these libraries in other parts of the image and Feature if they're still potentially useful libraries (as they're likely going to come back in through separate extensions as you mention)?

Actually, none of the tools I slated for removal in this PR are coming back through separate extensions; they are going to be flat-out dropped from support. The tools I left in will be coming into VS Code via separate extensions.


vst_components.get_thrusters() only returns active thrusters

This issue occurs when only Valkyrien Skies and addons are installed and no other mods

[X] I have tested this issue and it occurs when no other mods are installed

Minecraft Version
1.18
Mod Loader
Forge
Issue description
I'm not sure if it's intentional or a bug but vst_components.get_thrusters() only returns active thrusters

Issue reproduction

place down thrusters on a ship and activate one of them with redstone
on an onboard computer run #vst_components.get_thrusters(). It only returns 1 of the thrusters on the ship

Logs
No response

That's not easy to do because thrusters don't "belong" to the ship if they are not activated
this behavior should be changed anyways because of performance reasons


Move orgs and users to the "Your account" page

Context
With notifications coming up soon, we are moving account-related provider content to live under the account section. This includes the current profile page, the users page and the organisations page. We have also renamed organisations to organisational permissions.
Changes proposed in this pull request
The base of this PR is to move the nav links for Orgs and Users to be in the account page. Along the way, there were a few things I cleaned up, including: The org permissions setup success screen, adding breadcrumbs and page titles in the users and orgs pages
Page header now looks like:

Account page:

If the user does not have manage users or orgs:

Users page (and breadcrumbs):

Success page for permission setup:

Guidance to review
I copied the routing, breadcrumbs and page titles from the prototype. Have I missed anything?
Link to Trello card
https://trello.com/c/GNqpIZAr/2980-put-users-and-organisational-permissions-into-the-account-area
Things to check

[x] This code does not rely on migrations in the same Pull Request
[x] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[x] API release notes have been updated if necessary
[x] New environment variables have been added to the Azure config

Until we have notifications can you use one column for all items please.


Expand defaultAssetUrlOptions

Expanded defaultAssetUrlOptions to include other asset-linking attributes

It seems odd to me that the <audio> element was omitted even though it was present in vue 2.
I don't see a reason why the attributes added in this PR were omitted in the first place. If there's a reason or a potential drawback to this change, I'd like to know!

I believe this would make #7914 redundant.
A couple of places that might also need updating if this is merged:

https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue#asset-url-handling
https://vue-loader.vuejs.org/guide/asset-url.html


pb with tokeniser

I tried to run from scratch the rwkn-4neo, I used my token vocab.json created , it still give me that error, I tried eveything , changed token nothing  any hinch pls
Traceback (most recent call last):
File "/home/ubuntu/chatrwkv/chat.py", line 83, in
tokenizer = TOKENIZER("/home/ubuntu/RWKV-v4neo/out/out/vocab_new.json")
File "/home/ubuntu/chatrwkv/src/utils.py", line 23, in init
self.tokenizer = Tokenizer.from_file(WORD_NAME)
Exception: key must be a string at line 1 column 2

use https://github.com/BlinkDL/RWKV-LM/blob/main/RWKV-v4/run.py to run your train-from-scratch model


Tag management system

A tag management system that allows:

Tag owner to invite and manage tag collaborators
User to claim tag when a tag has not been claimed
Notify corresponding users for changes in collaborators

Completed.


Computing time Triangles

I opened this issue cause of the computational time spent to generate shapes using TriangleMesh.
I tried to measure computing time generating a simple scene with sky, ground and the solid made by triangle's meshing, with no antialiasing and 10 rays per pixel. I built a graph of the time used in terms of the number of vertices passed by command line:

We need a method to speed up the code. One soolution could be parallelize the Triangle and TriangleMes classes to be more efficient. Another way could be using a simple shape like a sphere to make a fast check for the rayInterception before calculating all the normals of the triangles.

I implemented successfully the AABB method to decrease computing time.
This method consists in generating a box contsaining the whole shape and doing a fast check before the rayInterception calculus: if the intersection between ray and box is null, the method return null.
The computing time really decrease with this method adn the comparison with the previous graph is the following one:

Both graphs doesen't have error bars because I had no time to cycle the rendering enough times to have a significative variance of data.

Great! In which commit did you fix this issue? Can you provide a reference?

I had no time to parallelize the TriangleMesh class, so this issue will be presented to te future users. It could be intresting also implement the KD tree method.