[BUG] VSCode extension very glitchy - stealing focus, closing interface components, resetting graphs

Current Behavior:
I'm very excited by what you have planned here, but there are numerous glitches in the VS Code extension that make it practically impossible for me to explore Quary at the moment.
Here is a video with a small example - see how the Configure window disappears when you click "where", and then when you try again, it disappears when you click to change the operator.
https://github.com/quarylabs/quary/assets/19584280/81554560-12a0-4ffd-8961-135bf43bf34a
I have encountered numerous behaviours similar to this, such as:

When editing the templated SQL while a graph is visible, it seems the graph keeps refreshing, stealing focus from my text input, so I can only type one character at a time.
Any type of clicking within the customise window is fraught. Sometimes it doesn't seem to register the click, sometimes it closes the customise window but keeps all the settings, sometimes it deletes all the settings or changes them to something randomly different. Sometimes it does actually work.
Saving the chart file in the Quary extension view (not the yaml text editor view) sometimes doesn't save it - you re-open the chart and it's the same as it was before you made your changes.

Obviously this is not the behaviour you are seeing, since it makes the whole thing virtually impossible to use.
Expected Behavior:
VS Code extension should behave like it does in the promo video on the quary.dev homepage.
Steps To Reproduce:
Follow the quickstart https://www.quary.dev/docs/quickstart-supabase
Attempt to make a chart and customise it to any degree.
Environment:

OS: MacOS 13.6.6 (22G630)
VS Code: 1.89.1 (Universal)
quary 0.1.0
quary extension published 2023-11-19, 22:59:26

Anything else:
Let me know what other information would be helpful!

Hey @abirtley apologies for this experience, we're looking into this!

Hey @abirtley fix is currently being reviewed. I will update this ticket once we have tested the changes internally and made a release.

Wonderful, can't wait to give it a try for real!

Hey @abirtley, I have just deployed the fixes! Looking forward for you to try it - let me know if you find anything else 👍

Wonderful! I can confirm this is now working as expected 🎉

Great! Thanks for confirming

Great! Thanks for confirming


Add draft file-content resource specification

PR Summary
The purpose of the file-content resource is to ensure the content of a file matches the desired state.

If the file does not exist, the file is created.
The file's checksum is computed. If a checksum was passed in and both checksums match, processing
is complete.
If no checksum was provided, the files content is compared to the specified content.

If the specified content is provided as YAML, then the YAML parsing rules for blocks are applied.
If the text contains escape sequences, the escape sequences are converted.
If the eol property is provided, all default escape sequences are replaced with the eol value,
which can be one of LF, CRLF, or CR. Note: This property is only meaningful with YAML input.

If the source content does not match the file, then the file is clobbered and replaced with the source
content.

PR Context
This PR provides a starting point to discuss the behavior for the file-content resource implementation.

The first point notes that the resource creates a file if it doesn't exist - we may want an explicit example case showing that the file can be removed.
Thinking about the eventual schema, is it in scope to define a file that exists but with content we don't care about? Otherwise, the schema would have to require at least one of content and hash.checksum.
Thinking about eol, I think that's a writeOnly property - it's a directive that controls how the ingested YAML should be read, but that's handled one level removed (at least) from the resource - so maybe it should munge any non-escaped EOL characters?

Thinking about eol, I think that's a writeOnly property - it's a directive that controls how the ingested YAML should be read, but that's handled one level removed (at least) from the resource - so maybe it should munge any non-escaped EOL characters?

I agree 100% about it being writeOnly.
It's a directive that is specific to YAML -- for handling the case where YAML is going to provide LF, but on Windows, some use cases will need CRLF. I'm still coming up to speed on who/where some processing happens. If the resource is always getting JSON from DSC and not processing the input directly, then it's not possible to determine the difference between a YAML parser inserted LF and an escaped LF coming from the source.

The first point notes that the resource creates a file if it doesn't exist - we may want an explicit example case showing that the file can be removed.

Right now, the missing delete example is intentional, but open for discussion.
I think this resource is literally just for file content. I'm trying to avoid the heavily overloaded resource that is available from the existing Windows File resource. I can imagine different resources for delete, mirror-tree, acl-[Windows|Linux|macOS], maybe something just for file-info.
I'm going to insist that delete is something that the robo-copy resource does by copying empty directories. ;)

BTW, I also think compare with match/replace is a separate resource. Right now I am thinking of something that supports an array of sed-like commands that run like a sed pipeline. (Not sed, but sed-like, so not the full sed syntax, and using ECMA 2018 regex, since there's a crate for that.)

I think this resource is literally just for file content. I'm trying to avoid the heavily overloaded resource that is available from the existing Windows File resource. I can imagine different resources for delete, mirror-tree, acl-[Windows|Linux|macOS], maybe something just for file-info.

I think I disagree - the resources are declarative, and for the most part what they can do they should be able to _un_do. I'm not suggesting that this resource should be made a full replacement for the File resource - though I do think we need one, eventually, because laying down files is a critical part of configuration management (as is removing them, though less frequently) - but the declarative model that _exist represents is a contract for the resource being able to create, update, and delete the instance as needed.

I also think compare with match/replace is a separate resource. Right now I am thinking of something that supports an array of sed-like commands that run like a sed pipeline.

I'm not sure I follow on this - what declarative state would I model with this resource?

If the resource is always getting JSON from DSC and not processing the input directly, then it's not possible to determine the difference between a YAML parser inserted LF and an escaped LF coming from the source.

That's my understanding, so in that case the only coherent model would be to say "turn all EOL sequences into this sequence" or "leave the EOL sequences alone" I think.

Without being able to interact directly with the YAML, I think the value of the eol property is questionable.
How common is the issue of "how to interpret embedded line endings in YAML input"?
If this is something common, it makes sense to create an issue to update the dsc command and make the behavior universal. If it is uncommon, then I think it should be removed completely. After the MVP for file-content is working, there will be a follow-up release that adds the ability to copy the content from a file. This will copy whatever line endings are in the file. Meanwhile, even without an eol property, the existing proposal will handle CRLF escape sequences.
At any rate, I think I need to remove the eol from this proposal.

I have been thinking about, "what if I was running this as a command line tool?" One result of that is that I think I should rename the path property as file. The meaning will stay the same.

I think I disagree - the resources are declarative, and for the most part what they can do they should be able to _un_do.

I think there needs to be a resource that provides presence/absence for all file objects, provides basic file info, and some amount of file-system info. I would make this the new file resource.
This resource would work for directories, files, and symbolic links. The file info would be read-only. This is not the resource that would manage file permissions (basically don't exist on Windows) or ACL (basically unique to OS, and in some cases unique to distribution).
This only real set action for this resource would be to set _exist to false, and delete the file object if necessary. It would be aware of different types of objects and have functionality to act recursively on directory trees. It would also be aware of links and provide the ability to act on the link versus the link target.
If a user needs to remove a file and manipulate the content, then they can have a dependency step that uses the file resource to remove the file.

With _exists being used, I would agree that _exists = false should delete the file.  In this case, the content and hash don't matter.  Otherwise, there's no point to have that if _exists is always true.  It may make sense for a separate FileInfo resource which handles things like permissions, etc... would also handle existence and having FileContent only ever care about the content with the assumption that the file exists.

I always think it's a good idea to look at what existing tools use and why:

Ansible file module
Ansible win_file module
Chef file resource
Puppet file resource
Salt file state

In more-or-less every case, POSIX is the default and Windows/NTFS is the special case, which makes sense for *Nix-first tools, which is how these were all developed.
Ansible has different modules because it uses on-the-target scripts to get the work done, and it's more coherent to split the implementations this way for their architecture. Ansible's file module (and win_file) create, update, and remove the files. Ansible separates out the content definition for files to copy/win_copy and template/win_template modules. The file module also handles file attributes, ownership, and mode permissions, but win_file does not.
Chef allows you to define a file with its ownership, permissions, and content. It handles POSIX and NTFS with the same resource. This is probably the most "batteries included" implementation, but that means the implementation is much more complex to provide the smoothest user experience.
Puppet uses a resource-provider model, where you swap the backend for a resource (and the resource can define different backends on a per-platform basis, as needed). The file resource handles defining a file with its ownership, permissions, and content. It's roughly on par with Chef for "batteries included" with the caveat that the translations for POSIX permissions is... imperfect, so in practice people ignore them for Windows and use the acl resource instead.
I don't really have a good handle on Salt, but it seems to be able to do content, ownership, and permissions, with the caveat that it ignores ownership and permissions on Windows.
So then the question is: why do these implementations mostly seem to collect these properties together into singular (to the user, even if the implementation is actually multiple discrete code modules) resources? Because their goal is to make declaring state as low-effort for the user as possible. Consider the difference between these hypothetical configs:
Separate Resources
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json

variables:
  FooConfigPath: /etc/xdg/FooBarBaz/foo/foo.config.json

# _exist is implied true for every resource
resources:
  - name: foo config file
    type: DSC.File/Basic
    properties:
      path: "[variables('FooConfigPath')]"
  - name: foo config ownership
    type: DSC.File.Posix/Ownership
    properties:
      path: "[variables('FooConfigPath')]"
      owner: app_foo
      group: app_admin
  - name: foo config permissions
    type: DSC.File.Posix/Permissions
    properties:
      path: "[variables('FooConfigPath')]"
      mode: 644
  - name: foo config content
    type: DSC.File/Content
    properties:
      path: "[variables('FooConfigPath')]"
      content: |
        server:  https://foo.app
        updates:
          automatic:       true
          check_frequency: 30

Single resource
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json

# _exist is implied true for every resource
resources:
  - name: foo config
    type: DSC/File
    properties:
      path:      /etc/xdg/FooBarBaz/foo/foo.config.json
      owner:     app_foo
      group:     app_admin
      mode:      644
      content: |
        server:  https://foo.app
        updates:
          automatic:       true
          check_frequency: 30

The latter is easier for a user to reason about and is less likely to conflict - what happens if I define this configuration?
resources
  - name: foo config info
    type: DSC.File/Info
    properties:
      path:   /etc/xdg/FooBarBaz/foo/foo.config.json
      _exist: false
  - name: foo config content
    type: DSC.File/Content
    properties:
      path:    /etc/xdg/FooBarBaz/foo/foo.config.json
      content: |
        server:  https://foo.app
        updates:
          automatic:       true
          check_frequency: 30

I see how having separate resource configurations is more verbose and more cumbersome for the user. I think there's some missing dependencies, but I'm guessing that is part of the point.

@michaeltlombardi can you go into the idea you were tossing around for composition, i.e., resource type File*? Also, whether it's a single resource, or some type of composition, what does _exist mean when a file can exist, but the content doesn't match or the permissions are different? Conversely, what do any of the properties other than the path mean if _exist is set to false on the input?
It might be cumbersome, but in the last example with the delete and the content set, with the addition of a dependency you have purge/replace, while without the dependency you might have undefined behavior.

@michaeltlombardi my expectation isn't that we'd have lots of small File related resources, but I do think it makes sense to optimize for certain domains of functionality:

FileContent (sed, grep, etc...)
FileAttribute (ownership, attributes, permissions, existence) - This could handle both Windows/non-Windows by having a nested WindowsPermissions vs PosixPermissions object.
FileCopy (recursion, overwrite, etc...)

These somewhat map to different command-line tools that exist on POSIX systems rather than having a single resource with a complicated schema.  It also means that in the future, if a better community resource that handles file content comes along, you can just replace that resource usage with the better one.


Intellij 15.0.3 code inspection done and obvious/easy fixes applied

I have ran the IntelliJ code inspections and the following obvious/easy fixes have been applied only where it made sense, if on doubt it was skipped:

redundant return variables.
if-statement simplifications.
unnecessary imports removed.
unnecessary boxing/unboxing removed.
unnecessary type-casting removed.
some String concatenation within StringBuilder replaced by StringBuilder append.

The fixes for their corresponding inspections were carefully applied after humanly checking that IntelliJ would not introduce a side-effect.
This branch will result result on a slightly better GC before JIT optimizes, no side-effect or functionality or feature has been modified or added.
Signed the Netty CLA

@normanmaurer - 3.x = assign to you :wink:

I tried to do the same thing for branch 4.0 but realized you are avoiding using iterators and boxing/unboxing purposely so I wonder now if my branch will make any sense to you, except for the if simplifications.

Afaict most of these changes are just relying on the compiler to do implicitly what was done explicitly. It makes for slightly more readable code but it is unlikely to affect GC or CPU usage.

I just re-pushed with implicit iterator removed.

I removed the implicit iterator and size variable and replaced by futures.size(), the rest I kept the same. I force pushed so it is the same set of changes without iterator.

-1 for if-statement simplifications. Some are ok but as @huguesb mentioned I doubt there would be any performance improvement and the readability of the code is not as easy as before. Another possible problem with merging multiple object field checks on one line is debugging NPEs.

Short-circuit boolean expressions are well known to be optimized away and for debugging you usually break point at the target line and see the current variable values, some if-statements don't even make much sense TBH

Netty 3.x is pretty much at its EOL which makes safer to format code and stuff.

Re-based from current 3.10 to make diff easier though it is unlikely this branch is going to be merged.

Re-based from current 3.10 to make diff easier and corrected an iterator I thought I had changed back to old way.


[MINOR] avoid adding duplicated publishment in spec

Although duplicated publisher won't impact anything since we convert it to map and publisher name is the key, avoid duplicated publisher in schedule state is meaningful.

LGTM, will merge


Fix systemd unit files to work with modern systemd

@sargun what did they change to break this?

@alberts Env variable setting with spaces has to be in quotes now

Can you add a line to docs/systemd-rules.md about that?

Updated.

@sargun @drewkerrigan do we want this one or https://github.com/dcos/dcos/pull/739 or both?


Last written packet not being delivered (epoll)

Expected behavior
The packet is always delivered and the connection is closed with FIN or FIN+RST?, when using this piece of code:
channel.writeAndFlush(kickPacket).addListener(ChannelFutureListeners.CLOSE);

Actual behavior
There's a 10% chance this code will race and will result with connection reset for the client.
A working so-far workaround is to add a listener that waits 50ms before calling channel.close().
Steps to reproduce
...?
Minimal yet complete reproducer code (or URL to code)
Not sure yet, it's hard to unit test a race :(
Netty version
4.1.9-FINAL-Snapshot as of 4 weeks ago(9ee4cc0)
Soon I'll test again on latest master, but I haven't seen any commits relating to fixing epoll write functionalities.
(I know the read() epoll bugs were fixed just recently, but nothing related to write() )
JVM version (e.g. java -version)
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu<IP_ADDRESS>-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
OS version (e.g. uname -a)
cc @Scottmitch

I just confirmed this on latest Netty 4.19-FINAL
internal exception: java.io.ioexception: an existing connection was forcibly closed by remote

That's seriously interesting :o I just tested it with Wireshark.
The packet IS delivered(flags PSH+ACK). Soon after there's a RST+ACK packet. The client still gets "forcibly closed by remote" before the packet is handled. Why is that?

On a case where it's received correctly(the ratio I see now is more like 40% race, 60% not racing) the sequence is:
SERVER -> CLIENT(PSH+ACK): kick packet
CLIENT -> SERVER: FIN+ACK
SERVER->CLIENT: RST+ACK

When I kick myself on a legit server there is no RST anywhere, there's FIN. Clearly something wrong on the netty side.

I checked whether I am overriding SO_LINGER with 0 which could create this problem according to this http://stackoverflow.com/a/8764491 but I see no mention of this in my codebase.

I found a unit test for this bug, but somehow it's still passing

According to this comment this may be a problem with calls to shutdown(...)?
http://stackoverflow.com/a/8875362

Yeah so adding channel.shutdownOutput() before channel.close() makes it work properly....Now it's sending FIN. This should be the default behaviour. I can come up with a PR...

@ninja- did you read: http://m.blog.csdn.net/article/details?id=29864509 ?
I think what you describe may be expected. Did you check the nio transport and see if it acts the same ? (it should).

@ninja- - Before you come up with a PR to change behavior can you submit a stand alone unit test which demonstrates the issue. If this is just a matter of calling shutdown can this be done at the application layer if your application requires this behavior?

@Scottmitch maybe it's a client-side bug? I remember a netty bug that caused connection resets to be processed before processing incoming data. The client is using some version of netty 4 out of 2015 I think (which is the build date of the game client...) so that's something I don't 100% control.
Anyway, I added a delay and I am happy enough with this code:
            handle.writeAndFlush(new Kick(reason)).
                addListener(new ChannelFutureListener() {
                    @Override
                    public void operationComplete(ChannelFuture future) throws Exception {
                        ((DuplexChannel) future.channel()).shutdownOutput();
                        future.channel().eventLoop().schedule(new Runnable() {
                            @Override
                            public void run() {
                                handle.close(); // workaround some problems related to kicks
                            }
                        }, 50L, TimeUnit.MILLISECONDS);
                    }
                });

@ninja- - We have had some bugs in this area in the past, and a lot has changed since 2015 so it is possible the older client code is contributing. Let me close this for now and if you are able to provide a unit test which demonstrates the issue we will fix it.


I'm doing an image generation experiment, but my script outputs a json file, how do I train a Transformer model to generate a pixel representation of an image?

I'm doing an experiment with image generation, but my script outputs a json file, how can I train a transformer model??
import cv2
import json
import numpy as np
import os
from PIL import Image

def image_to_text(image_path, text_path):
    # Read the image and convert to grayscale
    image = cv2.imread(image_path)
    gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)

    # Apply thresholding to get a binary image
    _, binary = cv2.threshold(gray, 128, 255, cv2.THRESH_BINARY | cv2.THRESH_OTSU)

    # Find contours
    contours, _ = cv2.findContours(binary, cv2.RETR_TREE, cv2.CHAIN_APPROX_SIMPLE)
    contours_list = [contour.flatten().tolist() for contour in contours]  # Flatten and convert to list

    # Convert image to list of pixel values
    pixels = image.flatten().tolist()

    # Save mode and size
    mode = image.shape[2] if len(image.shape) == 3 else 1  # Color if 3 channels, grayscale if 2
    size = image.shape[:2]

    # Write pixel data and contour information to text file
    with open(text_path, 'w') as text_file:
        json.dump({'mode': mode, 'size': size, 'pixels': pixels, 'contours': contours_list}, text_file)

def text_to_image(text_path, output_image_path):
    # Read pixel data and contour information from text file
    with open(text_path, 'r') as text_file:
        data = json.load(text_file)
        mode = data['mode']
        size = tuple(data['size'])
        pixels = data['pixels']
        contours_list = data['contours']

    # Reconstruct the image from the pixel information
    image_array = np.array(pixels, dtype=np.uint8)
    if mode == 1:
        image_array = image_array.reshape(size[0], size[1])  # Grayscale
    else:
        image_array = image_array.reshape(size[0], size[1], mode)  # Color

    img = Image.fromarray(image_array)
    img.save(output_image_path)

    # Reconstruct the image contours
    contours = [np.array(contour).reshape(-1, 1, 2) for contour in contours_list]  # Reshape to contour format
    img_contours = cv2.imread(output_image_path)
    cv2.drawContours(img_contours, contours, -1, (0, 255, 0), 2)
    cv2.imwrite(output_image_path, img_contours)

def batch_process(input_folder, output_folder_text, output_folder_images):
    # 确保输出文件夹存在
    if not os.path.exists(output_folder_text):
        os.makedirs(output_folder_text)
    if not os.path.exists(output_folder_images):
        os.makedirs(output_folder_images)

    # 遍历文件夹中的所有图像文件
    for filename in os.listdir(input_folder):
        if filename.lower().endswith(('.jpg', '.png', '.jpeg')):  # 处理常见的图像格式
            print(f"Processing {filename}...")
            image_path = os.path.join(input_folder, filename)
            base_filename = os.path.splitext(filename)[0]
            text_path = os.path.join(output_folder_text, base_filename + '.txt')
            output_image_path = os.path.join(output_folder_images, filename)

            # 图像到文本
            image_to_text(image_path, text_path)

            # 文本到图像
            text_to_image(text_path, output_image_path)

# 使用示例
input_folder = 'D:/llama2.c-master/1/images'
output_folder_text = 'D:/llama2.c-master/1/text'
output_folder_images = 'D:/llama2.c-master/1/imagesout'

batch_process(input_folder, output_folder_text, output_folder_images)

@lucidrains  Can you help me?

@win10ogod it is not ready yet


RFC: Associated const underscore

Allow _ for the name of associated constants. This RFC builds on RFC 2526 which added support for free const items with the name _, but not associated consts.
// RFC 2526 (stable in Rust 1.37)
const _: () = { /* ... */ };

impl Thing {
    // this RFC
    const _: () = { /* ... */ };
}

Constants named _ are not nameable by other code and do not appear in documentation, but are useful when macro-generated code must typecheck some expression in the context of a specific choice of Self.
Rendered

When does associated const code get run? at type definition? when substituting concrete types into generic arguments? never?
so, if I write:
pub struct S<T>(T);

impl<T> S<T> {
    const _: () = assert!(core::mem::size_of::<T>() % 2 == 0);
}

when does the assert get run?

Great question! I had not thought about that. I have added a paragraph proposing that they are evaluated never, aligning with the behavior of a named associated constant that is accessed never, but I'd welcome considering other options.

I have added a paragraph proposing that they are evaluated never, aligning with the behavior of a named associated constant that is accessed never, but I'd welcome considering other options.

I think that never being evaluated will be highly unintuitive, we should instead require them to be evaluated (though memoization is allowed) when generating any code that creates a type Self where enough generics have concrete types/values such that all generics used in the const are concrete types/values.
so:
pub struct S<T, U, const V: usize>(T, U);

impl<T> S<T> {
    const _: () = {
        let v: Option<T> = None; // use `T`
        panic!("1: T");
    };
    const _: () = {
        let v: Option<(T, U)> = None; // use `T` and `U`
        panic!("2: T and U");
    };
    const _: () = {
        let v: Option<(T, U)> = None; // use `T` and `U`
        let v = [(); V]; // use `V`
        panic!("3: T, U, and V");
    };
}

pub fn f<T, U>(v: S<T, U, 8>>) {} // doesn't error, since only V has a concrete value
pub fn g<U, const V: usize>(v: S<i8, U, V>>) {} // errors with message "1: T"
pub fn h<const V: usize>() {
    let f = f::<u8, i8, V>; // errors with messages "1: T" and "2: T and U"
}
const _: () = {
    let v: S<u8, i8, 5>; // errors with messages "1: T" and "2: T and U" and "3: T, U, and V"
};

so, basically as if:
pub struct S<T, U, const V: usize>(T, U);

impl<T> S<T> {
    const _: () = ...;
}

was instead written:
pub struct S<T, U, const V: usize>(T, U, PhantomData<[(); {Self::_CONST;}]>);

impl<T> S<T> {
    const _CONST: () = ...;
}

This would be so helpful! Thanks for writing this, David!
In favor of these constants being evaluated: https://github.com/rust-lang/rust/issues/112090

It seems that the intent of the change is to allow undocumented static assertions within traits, where this is easier to implement. There are probably corner cases that I cannot think of immediately. I found the use of anonymous const blocks non-intuitive on first encounter but clearly appreciate their use now.
I would expect code in const blocks to only affect compilation; therefore, they are fundamentally different than creating symmetry to let bindings.
I also anticipate a natural progression that if all of the const blocks symmetry is added, they will be sugared out by keyword or macro. Like C++ static_assert or Zig comptime where intent is clear/concise.

One further thought: the whole const _: () = { .. } thing was a total hack -- albeit, a useful one. I do wonder if it's time to add something more first-class, e.g. "anonymous modules", something like that.

@rustbot labels -I-lang-nominated
We discussed this in the T-lang meeting last week.
There was consensus that the problem this is trying to solve is a real problem.
However, people were concerned about whether it might be too surprising that these were not evaluated.  It wasn't that people wanted them evaluated exactly; the concern was simply the potential for surprise.
Aside from the practical motivation (which may be better served by some more specialized feature), the main reason to allow this (with the proposed behavior) would seem to be consistency on two fronts.  We allow const _  elsewhere, and we don't evaluate unused associated constants.
The consensus was that we wanted more discussion in the RFC itself about this behavior, e.g. acknowledgment that this might be surprising, discussion of things we could do to mitigate the surprise, discussion of why maybe this would be less surprising than it seems or why the consequences of that might not be severe, an argument for why we should do it anyway, etc.
Please renominate for T-lang after addressing these in the RFC so the team can review again.

If the concern is about people being surprised by code not being evaluated, how about introducing wildcard associated functions?
Eg:
impl Thing {
    fn _() {
        /* ... */
    };
}

This would probably be more intuitive to most people. If someone reads this code:
impl Thing {
    fn _() {
        assert!(...);
    };
}

It's immediately obvious that something is wrong here because that function is obviously never going to be run.

Finding myself wanting this specifically for assertions: is there a particular reason why we couldn't change the associated type behaviour at an edition boundary, and then warn for associated-const-underscore usages on previous editions? Or is this not specific to associated constants and actually specific for all named constants, and it's just that we're wanting this in particular for the associated constants?
Right now I'm using them as a way of confirming validity of generic consts, since even simple things like casting a u8 to a usize so it can be used as an array length is not allowed. I have to accept a usize as my generic const, then panic if its length is more than 255, which I would prefer to guarantee statically.


How to use with meteor/check?

After upgrading from the old atmosphere to the new npm version of simple-schema, the check-calls in my meteor methods throw a funny error.
I call it as usual with check(theObject, MyCollection.simpleSchema())
That causes my server console to show the following error and send the usual match error to the client:
I20170331-19:01:46.304(2)? Exception while invoking method 'entries.insert' Error: Match error: Missing key 'pick'
I20170331-19:01:46.305(2)?     at exports.check (packages/check.js:57:15)
I20170331-19:01:46.305(2)?     at [object Object].Meteor.methods.entries.insert (imports/api/Entry/server/methods.js:9:5)
I20170331-19:01:46.306(2)?     at maybeAuditArgumentChecks (packages/ddp-server/livedata_server.js:1737:12)
I20170331-19:01:46.307(2)?     at packages/ddp-server/livedata_server.js:719:19
I20170331-19:01:46.308(2)?     at [object Object]._.extend.withValue (packages/meteor.js:1122:17)
I20170331-19:01:46.310(2)?     at packages/ddp-server/livedata_server.js:717:40
I20170331-19:01:46.310(2)?     at [object Object]._.extend.withValue (packages/meteor.js:1122:17)
I20170331-19:01:46.311(2)?     at packages/ddp-server/livedata_server.js:715:46
I20170331-19:01:46.311(2)?     at [object Object]._.extend.protocol_handlers.method (packages/ddp-server/livedata_server.js:689:23)
I20170331-19:01:46.312(2)?     at packages/ddp-server/livedata_server.js:559:43
I20170331-19:01:46.320(2)? Sanitized and reported to the client as: Match failed [400]

pick is one of the methods the returned schema-object has, right?
Is it not possible to check objects in the meteor methods using check any more?
I also tried to check the passed object with MyCollection.simpleSchema().validate(theObject)
Yes, this ... well ... works. But it reports a really ugly 500 internal server error to the client, not very useful to display in a message box for the user.

This took me some time to find as well; I didn't see this in the documentation (perhaps a PR to add it would be in order?) but the option to have simpl-schema automatically clear Meteor's check requirement upon validation is found here in the code, and I've used it successfully:
https://github.com/aldeed/node-simple-schema/blob/3eca0e858ba318d4764d3dea29380c8555531159/lib/SimpleSchema.js#L499
So instead of the check call you wrote above, you should simply call:
MyCollection.simpleSchema().validate(theObject, {check});

...and simpl-schema will automatically call the passed-in check library upon successful validation to tell Meteor that a check has been performed.
That being said, the above usage merely ensures that Meteor's check is cleared without needing to invoke it directly; it sounds like you were possibly also seeking some specific functionality from the way check throws errors, which you probably won't get from this approach.

I'm still getting an error in my console
exception while invoking method 'insertTrip' Error: Did not check() all arguments during call to 'insertTrip'
I'm using the above check passing with
Trips.schema.validate(doc, {check});
The strange part is that the document is still being inserted into MongoDB

It would be good if someone could post and link to a simple Meteor app that shows this issue.
In general, the recommendation of MDG these days, which I agree with, is to use validated-method, which will give you nice error messages when used with schema.validator(). With this, you don't need check or audit-argument-checks.
I know it can be painful to update all existing methods to this pattern, though, so if we can keep check working without much extra code, we should.


How to make it draggable?

I want to know how I can make the widgets draggable and display as per my visual? Say for example Grafana.com. They have the draggable functionality.
Kindly, let me know  your views soon.

@plouc it's a pretty important feature, most other dashboard libraries have it

I personally like the explicit approach, where you define the order and placements in the code instead of trying to fight with the draggable grid where the grid/system tends to guess the my intentions often wrong :(

I'm not planning to add this kind of functionality, Mozaïk isn't the same tool as grafana or kibana (and has way less resources than the teams/companies behind those products :)), those tool were built to allow data exploration while Mozaïk provide a way to give a predefined view of your data.


Deprecation warnings to fix

Getting the following warning as part of training cycle:
FutureWarning: Passing a dict as an indexer is deprecated and will raise in a future version. Use a list instead.
  data_1 = data[subset]

We should update to future-proof asap.

Also had a report that from NumPy v1.24.0 our codebase is exiting with error due to following issue:
Error: AttributeError: module 'numpy' has no attribute 'object'. np.objectwas a deprecated alias for the builtinobject.
Since this was only ever an alias, should be trivial to rectify in the codebase by replacing np.object with object. @edvinskis could you take a look when you have a second?

The issues have been addressed in v1.2.4. I'll be closing this issue now.


Handling of inherited interfaces

Here I will be using interfaces to refer to any inherited class of size 0 (or 1 in ghidra) which the __vmi_class_type_info struct defines as being located at offset 0.
Currently interfaces which the __vmi_class_type_info structure defines as being located at offset 0 are being appended to a union named "super_interfaces". It has come to my attention that the way this decompiles may be considered undefined behavior. I also just don't like it. I am looking for some suggestions on how to handle these cases and in the meantime I may go back to searching for the first inherited class declared to be at offset 0 which has a size > 1 and considering that to be the derived base which is actually located at offset 0. All others would be appended to a list in the description or in the comments of that field.

I'm thinking of creating a way to discover and override calls to these interface functions. This would allow the removal of the union, which doesn't really work anyway, and would decompile as if it was a class method of the implementing class. This would also aid in type propagation. My main concern at this time is having a large amount of function overrides and the impact it may have on ghidra.


CE-520

bit.ly access token is now stored in the system table during the install wizard
during installation the token will be validated by connecting to bit.ly
when the bit.ly service is created, the token will be read from the database (via SystemService)
the BitlyBundle has been removed, so we have better control on the access token
make sure to update the database schema on existing installations

Nice work, thanks so much!


BUG: Unhandled Exception on message.text???

Unhandled: [object Promise] Reason: TypeError: Cannot read property 'text' of undefined

As the title said.

More details.

I am unable to provide more details, as it did not tell me which line it happened.
My source is here.

@austinhuang0131 ow, I know as much as you do in this case. 🤔
I would suggest you use .catch blocks everywhere (i.e. better error handling) to see where the error occurs and why.
Also, see if the error occurs on a specific message / command, so you can inspect that block of code.

Well, I put bot.command(...).catch(...) but it doesn't seem to work (not a function). I had bluebird.
Telegram will re-send all messages that had not been handled, so this is not going to work.

Sorry about that.

@austinhuang0131 Glad your problem was solved! :+1:


Grammar tweak

Signed-off-by: yuxiaobo<EMAIL_ADDRESS>
What this PR does / why we need it:
Grammar tweak.
Special notes for your reviewer:
If applicable:

[ ] this PR contains documentation
[ ] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

/assign @mattfarina

/assign @bacongobbler


Upload formdata using backgroundUpload

Currently this packages allows for uploading files in the background following compression. However, I have not been able to figure out if there's a way to upload other pieces of data with the media. E.g. sending information such as the title and description of the media file alongside the file itself. This feature would greatly improve background uploads.
Really appreciate the work gone into this package btw, thank you.

@hkhan6916 thanks, i will add this soon.

Hi @nomi9995
Thank you for this amazing library, specially for the expo support. I cant wait to be able to add data along with the background upload. Would be greatly appreciated.

Hi @nomi9995
Thank you for this amazing library, specially for the expo support. I cant wait to be able to add data along with the background upload. Would be greatly appreciated.

Hey @haibert, thought i'd help out as i've found a pretty good solution until @nomi9995 gets a chance to implement something more convenient. Turns out you can trigger external functions following compression. I used react-native-background-upload for ios and android. You can use it like so...
await VideoCompress.compress(         file://pathToFile,         {           compressionMethod: "auto",         },         (progress) => {           console.log({ compression: progress });         }       ).then(async (compressedUrl) => {         // Then trigger the code for react-native-background-upload.          Docs - https://github.com/Vydia/react-native-background-upload       });

@hkhan6916
Thank you so much for the thought and consideration. Unfortunately it seems like id need to eject expo to use react-native-background-upload which is not an option for us right now.
Expo is amazing, really hope the community fully embraces it as RN progresses

@hkhan6916
Oh I do too! I use a custom build client.
Just to be clear are you saying that you are using eas build with react-native-background-upload ?
Meaning we're you able to get react-native-background-upload working without ejecting? Or you were just speaking in generalities

@hkhan6916 @haibert sorry, I am too much busy with office work these days, I hope I will add formdata at the start of next week. thanks

@hkhan6916
Oh I do too! I use a custom build client.
Just to be clear are you saying that you are using eas build with react-native-background-upload ?
Meaning we're you able to get react-native-background-upload working without ejecting? Or you were just speaking in generalities

@haibert Yes. Just install and run EAS build.

@nomi9995 no worries my man. we really appriciate it. cant wait for the feature!

@hkhan6916 sorry to bug you again but the documentation for react-native-background-upload is not very thorough. how were you able to send the body ? It also doesn't have a body param. It looks like it has a "parameters" option but doesnt really say how to use it. do you turn your data into json and put it inside the parameters ? id love to see your code for the usage

Hey @haibert  sorry for the late response. In case you still need help, my code looks like:     const options = {       url: "someurl",       path: somePathToFile,       method: "POST",       type: "multipart",       maxRetries: 2,       headers: {         "content-type": "multipart/form-data", // IMPORTANT         Authorization: Bearer ${token},       },       parameters: {         postId: post?._id, // any extra data i want to send alongside the file       },       field: "file",       // Below are options only supported on Android       notification: {         enabled: false,       },       useUtf8Charset: true,     };     Upload.startUpload(options)

@hkhan6916 no worries thank you so much!  I gotta talk to the backend guys to make sure they make changes since the request is not going to be a JSON anymore. And i'm curious do you know what format the backend will receive the actual file in ? meaning is this going to send the base64 of the file to the server or... ?


Slate docker image does not build using Apple M1

Bug Description
Using the provided pre-built image from DockerHub in an Apple M1 computer, I'm not able to build the project. This is because the Slate pre-built image is ONLY builded using the linux/amd64 architecture.
If I do a fork of the repository as this guide explains https://github.com/slatedocs/slate/wiki/Using-Slate-in-Docker, it's working fine. This is  because the Dockerfile you are defining is using ruby:2.6-slim as base image, that supports linux/arm architecture, so when the M1 downloads the image, it knows which arch it should use.
Could be possible to build the slate image using linux/arm arch too?
Thanks!
Screenshots

Browser (please complete the following information):

OS: macOS Monterey v12.2

Should be doable by following https://blog.oddbit.com/post/2020-09-25-building-multi-architecture-im/.

Hey @MasterOdin thanks for taking care of this 👏  I've just seen that there is a new test image in the DockerHub builded with the arm architecture.
Are you planning to moving it to a final release?
Thank you!

There are now published linux/arm64 and linux/ppc64le images available for the 2.13.0 release, as well as for any future release. Please let me know if you run into any issues with using them.


Version 1.3 requires PHP 5.5 but the Vagrant box has PHP 5.4.43

The Vagrant install does not install PHP 5.5 so you cannot compose your vendors from within the Vagrant box.
vagrant@precise64:/vagrant$ ./composer.phar install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - This package requires php >=5.5 but your PHP version (5.4.43-1+deb.sury.org~precise+1) does not satisfy that requirement.

Blocks https://github.com/TomHAnderson/zf-oauth2-doctrine/pull/41

On investigation, I think we need to use a different base box. Will look into it soon.

@TomHAnderson I'm having trouble getting things updated; I have an updated box, which brings updated PHP, and I've ensured the config files are being properly placed, but the server is responding with a 403 on all requests. It may be a day or two before I have this ready.
In the meantime, the Docker configuration works great, and you can use that as an alternative.

Is php cgi w/ no Authorization header?  Thanks for working on this.

We could consider getting rid of the puppet provisioner, and use a stand-alone Vagrantfile like this one. https://github.com/zendframework/ZendSkeletonApplication/blob/master/Vagrantfile

Having a MySQL install in the virtual machine is very useful.

@jeremiahsmall I considered it, but that provisioner was one I wrote as my first foray into Vagrant, and it's not terribly robust.
I've generated new configuration using PuPHPet (which was the basis of our original configuration for the Apigility skeleton), and have opened #105 with the patch. The initial vagrant up takes a while to provision, but after that, it's very fast, and "just works". You also end up with a lot of tools out-of-the-box, which I think will be useful for a base box.

@weierophinney, oh, I didn't realize that. I though @gianarb had written that one. It was fairly recently PR'd by him: https://github.com/zendframework/ZendSkeletonApplication/pull/288
In any case, we also use Puppet provisioners, but we have managed to keep most of the mess out of the repo by gitignoring .puppet/modules


Basic travis-ci integration

I also noticed that this project doesn't have any CI, even though it has a test suite.
This PR adds basic CI support, running node LTS/stable on linux and OS X in Travis.
Theres also some basic support for automatic github release generation and npm package submission, in order to enable this, @yortus should update the email line with an email and insert GITHUB_TOKEN and NPM_TOKEN as secure variables (see https://docs.travis-ci.com/user/environment-variables/#Encrypting-environment-variables).

Hi @no2chem. I don't think its worth it to integrate Travis CI in this project. Updates are very infrequent and there will be no further development. Also the majority of installation issues occur on Windows, and Travis CI doesn't test that.


TypeScript definitions file for the framework not generated (h5.d.ts)

I have "generateTypeScript": true defined in h5.json in all assemblies in my solution, and TypeScript definitions files are generated for those assemblies, but no TypeScript definitions file is generated for the H5 framework (e.g. h5.d.ts) so there are no definitions for namespaces like System, etc.

Here's a repo with a minimal reproduction of the issue: https://github.com/BenjaminFarren-eaton/demo-h5-typescript-issue

Any news on this issue?, I have the same problem in my project.


Amplify Mock does not support AWSDateTime!

How did you install the Amplify CLI?
brew
If applicable, what version of Node.js are you using?
18.16.0
Amplify CLI Version
12.4.0
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
None.
Describe the bug
I am using amplify to manage an AppSync API backed by a DynamoDB table.
One of the fields is of the type AWSDateTime!.
Everything works properly on staging, when querying AppSync directly.
But the API created by amplify mock api returns validations errors on perfectly OK AWSDateTime! values:
{
	"errors": [
		{
			"message": "Expected value of type \"AWSDateTime!\", found \"2020-01-01T00:00+00:00\"; DateTime cannot represent an invalid date-time-string 2020-01-01T00:00+00:00.",
			"locations": [
				{
					"line": 5,
					"column": 11
				}
			]
		},
		{
			"message": "Expected value of type \"AWSDateTime!\", found \"2020-01-01T20:00+00:00\"; DateTime cannot represent an invalid date-time-string 2020-01-01T20:00+00:00.",
			"locations": [
				{
					"line": 6,
					"column": 9
				}
			]
		}
	],
	"data": null
}

Expected behavior
No validation errors when passing 2020-01-01T00:00+00:00 as AWSDateTime! to the mocked API.
Reproduction steps

amplify mock api with an AWSDateTime! field
start: "2020-01-01T00:00+00:00"

Project Identifier
1e5d38be45b2aa68d2e028b81984bf56
Log output

# Put your logs below this line

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

Hey @mrtolkien, Thank you for bringing this to our attention. Could you please use YYYY-MM-DDThh:mm:ss.sssZ (example: 2020-01-01T00:00:00.000Z) format for AWSDateTime and let us know. We are able to create the records using the YYYY-MM-DDThh:mm:ss.sssZ format.


Inquiry on FP8 Quantization for Query in masked_multihead_attention_kernel

Dear Community,
I have gone through numerous resources and carefully examined the relevant code. However, there is one aspect that I find particularly perplexing and I would greatly appreciate the community's insight.
Specifically, I noticed that in masked_multihead_attention_kernel (Qk_dot<T, THREADS_PER_KEY>::scale_dot(q_vec, k_vec, k_scale_quant_orig_f)), the attention query (Q) does not appear to be FP8 quantized. By quantizing the query (Q) to FP8, we could potentially use FP8Gemm(Q, K^T) and FP8Gemm(P, V) to optimize the computation and fully leverage the hardware capabilities.This observation raises a few questions for me:

Have I missed any critical information in the code that pertains to the FP8 quantization of the query (Q)?
Is the absence of FP8 quantization for the query (Q) due to concerns about precision?
Are there any existing studies or conclusions that explain why the query is not FP8 quantized?

I am currently referencing the trtllm master commit 9691e12 (June 25).
Thank you very much for your time and assistance. I look forward to any guidance or insights you can provide.
Best regards

https://github.com/NVIDIA/TensorRT-LLM/issues/1921


Add target to just deploy dataplane

make edpm_compute_baremetal deploys both controlplane and dataplane. However, we've a requirement in CI to deploy the operators and then patch some environment variables before deploying rest. make edpm_baremetal can be used there. We can probably trash the all-in-one target (edpm_compute_baremetal) later if we want. However, the new target won't work when control plane has been deployed with NETWORK_ISOLATION=true.
Also, fixes one BMAAS cleanup issue.

recheck


submodule support ?

Hello after adding a submodule to my public repository i got this error:
[2019-04-05 21:57:25] [DEBUG] Running command: 'git --git-dir=/work/working/private/src/.git fetch --no-tags --recurse-submodules=no --prune -- /work/working/private/incremental_bundles/incremental.bundle +refs/heads/*:refs/heads/* +refs/tags/*:refs/tags/* +refs/semmle/*:refs/semmle/*' in current directory ('/work/working/private') From /work/working/private/incremental_bundles/incremental.bundle * [new ref] refs/semmle/semmle-polled-revision-0fb74fb7647f3a876dba572bca803a5b6537c6e1 -> refs/semmle/semmle-polled-revision-0fb74fb7647f3a876dba572bca803a5b6537c6e1 [2019-04-05 21:57:26] [DEBUG] Stack trace: com.semmle.util.exception.UserError: Could not open git repository at /work/working/private/src/.git/modules/vendor/strong_type

my config:
extraction:
  cpp:
    prepare:    # Customizable step used by all languages.
      packages:
        - python-pip
        - pkg-config
    after_prepare:    # Customizable step used by all languages.
      - git submodule -q update --init
      - pip3 install --local cmake conan
      - pip3 install --local cmake conan --upgrade
      - ls ~/.local/bin
      - export PATH=$PATH:~/.local/bin
      - conan --version
      - cmake --version
      - conan profile new default --detect
      - conan profile update settings.compiler.version=8 default
      - conan profile update settings.compiler.libcxx=libstdc++11 default
      - conan remote update conan-center https://conan.bintray.com False
      - conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan False
      - conan remote add skypjack https://api.bintray.com/conan/skypjack/conan False
      - mkdir $LGTM_SRC/_lgtm_build_dir
      - cd $LGTM_SRC/_lgtm_build_dir
      - conan install -g cmake ../
      - cd -

full log:
https://lgtm.com/projects/g/Milerius/nephtys/logs/rev/pr-32ede09a4956bbe052eb655497a864a1db9b61c1/lang:cpp/stage:Build merge_0fb74fb7647f3a876dba572bca803a5b6537c6e1

Hi @Milerius! I'm not sure your question has ended up in quite the right place, but I'll do my best to answer! :-)
Unfortunately our support for submodules is still a little limited, and here I suspect you've hit a known issue sometimes encountered when submodules change in a pull request. It's to do with how we cache repos, to limit the pressure we put on GitHub's servers.
I see from your recent commits that you may have already found your own workaround, but if you're still having problems could I direct you to our support forum at discuss.lgtm.com? There someone with more powers might be able to help you further!

Hi @nickfyson
For the moment as workaround I kick the submodules yes !
Thanks you for the link of the discuss.lgtm.com !


For reference: schema validation

Description of feature
https://github.com/frictionlessdata/tableschema-java

A simple version of a validation and conversion script can be found here:
https://github.com/nvnieuwk/nf-samplesheet-conversion


better description of GAMS execution/license errors & debugging

The tutorial and docs should explain how to deal with different types of GAMS errors, like missing/invalid license or execution errors (infeasibility).
The debugging features also need to be explained.

The path to the GAMS log and lst file should also be retrievable, to make it easier to find the error.


[Improvement]: Integrate function semtype into jBallerina type engine

Description
Extend #42506 so that "normal" type checker also uses function semtype
Describe your problem(s)
No response
Describe your solution(s)
No response
Related area
-> Compilation
Related issue(s) (optional)
No response
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response

Closing with #42622


[Bug] An empty Menu Button in the Mobile screens

Description
When you switch to mobile screen, a menu button appears. This menu has no content and hence should be removed.
Expectation
There should be no Menu button since there are no contents. Also, in the desktop screens, there are no menus(there is no navbar).

[x ] I would be interested in resolving this bug.

Hi! I'm leaving this comment here as suggested so this issue can be officially assigned to me. Thank you @possumbilities


How to enable php session

Here is my vercel.json file

{
  "functions": {
    "api/*.php": {
      "runtime"<EMAIL_ADDRESS>    }
  },
  "routes": [
    { "src": "/api/(.*)",  "dest": "/index.php" }
  ]
}

here is my session script
api/session1.php
<?php

session_start();
$_SESSION['user'] = 'Ann Cooler';

?>

api/session2.php
<?php

session_start();
echo $_SESSION['user'];

?>

The session is  not working at all

Hi @areaboy. It's a feature, when you request your different lambdas they have different user space. You can imagine them like different docker containers. You need to use some shared space, for example redis, if you need multiple lambdas. Or you can use one lambda (one index.php) and require different session.php file according routes.

Thanks for getting back to me. Please do you have a php sample code  and vercel.json sample configuration. Am New to Vercel.  Thanks

I have encouter this issue before but I end up using databse as session driver. just need to provide your db credential and SESSION_DRIVER=database is fine

How would I go about doing that? I'm very new to php and Vercel so I don't fully understand where to write that. Thank you

@Transyfor the place for me to put db credential and SESSION_DRIVER=database is file .env at the root directory

same problem

suggest
'driver' => env('SESSION_DRIVER', 'file'),
replace
'driver' => env('SESSION_DRIVER', 'cookie'),

Sessions are allowed to use in Vercel Functions, but you need to use /tmp folder for them.


Short-style NamedTuple type can't be used as generic type argument at second position

The short-style type declaration {x: Int32, y: String} should be equivalent and interchangable with NamedTuple(x: Int32, y: String). But it seems it only works as generic type argument at the first position:
foo : Array({x: Int32, y: String})
bar : Hash({x: Int32, y: String}, String)
baz : Hash(String, {x: Int32, y: String}) # expecting token ')', not '{'

This is a bit complex to implement. For example:
call([] of A, {x: Int32} -> Int32)

The type of the array is obviously a Proc, but look at this:
call([] of A, {x: Int32})

Now the type of the array is A, and then comes a named tuple instance. The parser need to do a big lookahead to determine this, which is bad (the parser tries not to do lookahead).
I think we should either emove the shortcuts for tuples and named tuples. Writing Tuple(Int32, Int32) vs. {Int32, Int32} is not that painful, and same goes with NamedTuple. It will also simplify the language a bit.
Alternatively, just document that this isn't possible, and you'll have to use NamedTuple(...).

Yet another solution could be to have a different parsing depending on the position. If it's inside generic type arguments, it's obvious that { will refer to a named tuple type. But outside it it might not be that obvious, and maybe a hash literal or named tuple instance literal would be more obvious. But this of course is also confusing... maybe removing the shortcuts is the best thing to do. In any case, these types are not that common to merit a shortcut.
Another idea is, in calls, to assume that in call([] of A, B), will be parsed as [] of A followed by some argument, as proc types are not that common in such generic types. If you do want a proc type, surround with parentheses: call([] of (A, B -> ...)).

@asterite we've always had different parsing depending on the context. For type arguments, type shortcuts always work, but outside they pretty much never do. For example, var : {x: Int32} has always parsed {x: Int32} as NamedTuple(x: Int32), but var = {x: Int32} has always parsed {x: Int32} as a tuple literal of type NamedTuple(x: Int32.class)

@asterite In your example it's actually the short-style proc type that makes it more complicated because it makes the , ambiguous. Short-style tuple types don't add ambiguity to the type grammar.
It's only that var = {x: Int32} could also be interpreted as var = NamedTuple(x: Int32), but it's clear that this means a named tuple literal.

So you both propose that we fix it only inside generic arguments (but not after of)? Sounds good to me. In fact, I think I might change the rule a bit to only parse a single type after of, unless you use parenthesis, so lookahead is never needed.

Oh, actually, it's a bit more complex. For example this:
class Foo
  property block : Int32, Int32 -> Int32
end

Since property just looks like a call, here there's the ambiguity of knowing where what comes after , is a type that eventually forms a proc, or if it's a second argument to property.
So... I guess I'll just improve the parsing for when you are clearly inside generic arguments (basically inside ( of a generic instantiation).

So... I guess I'll just improve the parsing for when you are clearly inside generic arguments (basically inside ( of a generic instantiation).

That's the main issue here :+1:


Promote Atto parser as a module

This PR moves the current parser (using parser-combinators) into a new module and makes it possible to implement other parsers.
Then it moves atto parser as a module and checks that parser tests are giving the same outputs with both parsers.
This PR is a draft because there's a difficult choice to make.
At this point, users have to add a new dependency (parserc) to their projects to use Cron class as previously.
There are two solutions.
1/
We could accept that change and write a nice migration documentation, even write a scala steward rule. After all, it's just an additional dependency to add.
2/
The other solution I can see is to rename core into even-more-core and change core to be an aggregate of even-more-core and parserc.
This solution creates two new dependencies for our users but it would be transparent to them.
We would then just have to find a decent name for even-more-core.
@alonsodomin What do you think?

Looks good so far, only minor nitpicking from my side

Do you have an opinion about the migration path for users?

Do you have an opinion about the migration path for users?

I would simply make the new Atto parser the default but making it such that source code backwards compatibility is maintained. Meaning that a bumping the cron4s version downstream doesn't require any code changes.
However, at least for one or two versions, keep the legacy scala-parser-combinators implementation, which could be simply enabled by having an extra parameter in the Cron.parse methods, something like useLegacyParser: Boolean = false. This should be documented in the docs, there is migration folder where that should be documented.
This will in fact break binary compatibility so may require a major version bump. i.e.: 0.5.x

Do you have an opinion about the migration path for users?

I would simply make the new Atto parser the default but making it such that source code backwards compatibility is maintained. Meaning that a bumping the cron4s version downstream doesn't require any code changes.

That seams fair.

However, at least for one or two versions, keep the legacy scala-parser-combinators implementation, which could be simply enabled by having an extra parameter in the Cron.parse methods, something like useLegacyParser: Boolean = false. This should be documented in the docs, there is migration folder where that should be documented.

This one is more a problem. My main goal is to be able to remove the dependency to scala-parser-combinators lib. So keeping the implementation in the same module won't work for me.
However, I can make Atto the default and put the scala-parser-combinators version in another module and document how to use it.
I'm not sure which problem it solves though.

This will in fact break binary compatibility so may require a major version bump. i.e.: 0.5.x

Ok.

I don't think that keeping the old parser solves any problem in particular more than potentially prevent it. While it's great that we have tests that we can use to validate both implementations there may be some cases in which the behavior of each the two parsers still differs somehow and I find it polite towards end users to be able to opt out of the new parser, at least in the next version. In following versions the old parser (and opt-out flag) would be removed altogether.
I don't mind if the old parser is moved to its own module or kept as is, probably the former is a cleaner implementation. If in a separate module it could also be argued that now the end user needs to choose which parser to use by importing the specific parser module (instead of using a flag to opt-out).
However I personally put priority on end user experience and still believe that having a default parser is a much better experience as a consumer of the library, also it allows to a smooth version upgrade: imagine an scenario in which Scala Steward creates an upgrade PR in someone else's repo, if the PR fails due to missing dependencies other users are less likely to look deeply into it and upgrade.
Regarding dragging around the dependency on Scala parser combinators, there are ways to make it in the use site, for example if we mark it with % Optional in our dependencies then it should need to be explicitly included downstream if users prefer that.
I mean, the usage of flag is not a hard requirement, just a quick idea thrown out. I'm open to there strategies that allow end users to opt-out of the new parser, just would like it to be documented and not being super-complicated to do.

Thank you for your detailed reply.
I thing that making Atto the default implementation and putting parser-combinators version in its own module fulfill your end user requirement : for most users, the upgrade will just work, and for people wanting the previous parser, they import the dependency and explicitly instantiate the parser.
I will have a look next week and propose a non-draft PR.

@alonsodomin I updated the PR. Now the core module depends on atto which itself depends on domain.
The code previously in core is now in domain.
core is effectively an empty module that pulls atto to make the transition smooth for users.
I have a (hopefully) last problem: Atto does not have a native version, so I can't build a native core module that uses atto.
I can have some version specific code in native directory to make Cron use the parser-combinator parser but I don't know how to specify that core depends on atto for js and jvm but on parserc on native. Do you have a clue how to implement that?

Hello, specifying different dependencies for each target platform is super easy, you need to use .jsSettings(...), .jvmSettings(...) or .nativeSettings(...) and put the libraryDependencies setting for the specific platform in there.
https://github.com/portable-scala/sbt-crossproject
Regarding this refactoring, need to sit through it, as a start not a big fan of it, or even the naming domain chosen..., much less of having an almost empty module.
Let's look at the codebase in funcional point of view: The parser itself doesn't depend on all of the classes/traits that have been moved. In fact it should only require the types defined in the expr package. There are couple of offenders in this case: CronField and CronUnit as those are required by the expr package but both are defined in the root package. All the logic that calculates future dates operates on the CronExpr type, which gets constructed after parsing and therefore it doesn't directly depend on a parser implementation, nor the parser needs any of that to.
My preferred approach would be to make a clean cut between what is required to construct the CronExpr, and _what we can do once we have a CronExpr. That leave two modules that actually provide with functionality on their own, one has all the dependencies needed by the parsers (and nothing else) and core keeps all the lib logic that operates on CronExpr. Regarding naming, the new module can be named as cron4s-kernel, it's lame but it's a common practice in other projects.
There is an extra issue I see: the Cron singleton object. This was from the origin always intended as an easy entry point into the parser but the way it is right now it will create a bytecode conflict for the cases in which someone wants to opt-out of the Atto parser. This is because both the core module and the parsec module define the same cron4s.Cron package. This needs extra thought as regardless if the modules being used by end users, there must be only one definition of this type. A potential solution is that, instead of instantiating the singleton with a parser, the individual methods in the Cron type take an implicit Parser type as extra parameter. This parameter can have a default that points to the Atto parser but should be easily overridden when doing import cron4s.parser.Parsec._ providing such a package or object provides with the appropriate implicit instance.

Thanks for your feedback.

Hello, specifying different dependencies for each target platform is super easy, you need to use .jsSettings(...), .jvmSettings(...) or .nativeSettings(...) and put the libraryDependencies setting for the specific platform in there. https://github.com/portable-scala/sbt-crossproject
Regarding this refactoring, need to sit through it, as a start not a big fan of it, or even the naming domain chosen..., much less of having an almost empty module.
Let's look at the codebase in funcional point of view: The parser itself doesn't depend on all of the classes/traits that have been moved. In fact it should only require the types defined in the expr package. There are couple of offenders in this case: CronField and CronUnit as those are required by the expr package but both are defined in the root package. All the logic that calculates future dates operates on the CronExpr type, which gets constructed after parsing and therefore it doesn't directly depend on a parser implementation, nor the parser needs any of that to.
My preferred approach would be to make a clean cut between what is required to construct the CronExpr, and _what we can do once we have a CronExpr. That leave two modules that actually provide with functionality on their own, one has all the dependencies needed by the parsers (and nothing else) and core keeps all the lib logic that operates on CronExpr. Regarding naming, the new module can be named as cron4s-kernel, it's lame but it's a common practice in other projects.

That would work for me

As far as I understand, there's no ADT-like to express Cron expressions. The parsers are instantiating some Nodes which already contain logic about what we can do about them.
Implementing this plan would require to:

define an ADT representing a CronExpr (in kernel module)
once parsed, we transform this ADT into the current Node types  (in core module)

It's should not be too hard but before I dive into it, do you think there's a better plan?
Is it what you meant in the first place @alonsodomin ?

With the last commit, we now have a parser module that provides just enough types to write a parser.
Then atto and parserc are implemented in term of cron4s.parser.
And finally, core module produces the usual cron4s.expr types from cron4s.parser ones.
@alonsodomin Let met know if this looks fine to you.


Use PEP 695 typing

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.48%. Comparing base (ec5d62b) to head (c9ba160).
Report is 82 commits behind head on devel.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##            devel    #1563      +/-   ##
==========================================
- Coverage   90.42%   88.48%   -1.95%
==========================================
  Files          49       52       +3
  Lines        6037     6426     +389
==========================================
+ Hits         5459     5686     +227
- Misses        578      740     +162

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


Add Book Binder

Changes

Adds the Book Binder page to the Electric Machines category

We should really go into config options for these things too.

sure

Something like this you had in mind @WalshyDev?

I meant going into what the specific options are. End of the day, this is a wiki. It should have as much info as it can

I wasnt sure whether to keep the little text on top of the table
Soon Ill also make a pr to add this for all existing machines

I don't the summaries are needed


Affine Warp

Hi there,
First, thank you so much for these resources. They are really great tools.
I was testing the Spatial Transformer layer and have noticed an odd behaviour. In some experiments I have ran, I have noticed an odd behaviour, where when doing a rotation about the z-axis, the image is rotated, however, it's also scaled down. I dug in the code and I noticed the _single_aff_to_shift function. I see that you add the identity matrix to affine matrix.
To remedy that, I subtracted the identity matrix and it worked fine.
I saw the comment in the code, but it still doesn't make sense for me. Maybe I don't understand something, but why did you add this initially?
Kind Regards

Hi @sergiumocanu ,
We have this convention to be consistent with the dense version of the transform, where what we expect is the displacement field, that is, the is the difference from identity, which is often used in these networks. To be consistent with this, we expect the affine to be the difference from identity -- so passing in a matrix of 0s would represent 'no change').
I agree there is some ambiguity here as to what is the best representation. We tried to clarify this in the documentation, but we'd welcome suggestions in general:
    The Layer can handle both affine and dense transforms.
    Both transforms are meant to give a 'shift' from the current position.
    Therefore, a dense transform gives displacements (not absolute locations) at each voxel,
    and an affine transform gives the *difference* of the affine matrix from
    the identity matrix.

I see, ok. Thank you for the response. It makes sense now since the layer is handling both affine and dense warp. I think I missed this particular comment you mentioned.


blank messages

when sending a message in discord, only the user's name is in the message on minecraft. the other way around works fine.

#11


[5.6] LogManager driver capable of producing logger with any Monolog handler

The provided driver allows a configuration centric approach to creating Logger instances (channels) where the handler can be any of the built-in Monolog handlers without needing to write custom factories (code).
By using Container::build() it is capable of matching any named constructor values from any Handler that are provided in the handler_params configuration option.  For non-monolog provided handlers, it is capable of accepting an option handler_class where it will use the full class name to instantiate/build.
Example of creating a php://stderr non-bubbling StreamHandler based logger:
    'channels' => [
        'nonbubblingstream' => [
            'driver' => 'monolog',
            'handler_type' => 'stream',
            'handler_params' => [
                'stream' => 'php://stderr',
                'bubble' => false
            ]
        ],
    //...

Example of a LogEntries based channel logger:
    'channels' => [
        'logentries' => [
            'driver' => 'monolog',
            'handler_type' => 'LogEntries',
            'handler_params' => [
                'token' => '123456789'
            ]
        ],
    //...

This feature is completely backwards compatible and opt-in.  If accepted, I will document it's usage in the manual.

Instead of binding contextual parameters into the container, is it possible to use makeWith?

Yes! I didn't realize that make would create instances of arbitrary (non-registered) types. This is much better, it's more clear and concise. (Used make over makeWith since the latter is listed as an alias.)

Tweaked things a hair... just went with handler configuration option that must be the class name. Figured people can just use Handler::class and import the handler at the top of the configuration file.
Renamed handler_params to with since it kinda matches the container argument.
Thanks!

I dig the changes. Thanks!


Main Website Compound Document Violates the Full Linkage Requirement?

I believe the main website compound document on the first page violates the "full linkage" requirement of jsonapi compound documents.
The included comment (type="comments" id="5") has resource linkage to an author (type="people" id="2") but that person (type="people" id="2") does not exist in the included section of the included document.
I believe this violates the full linkage requirement of compound documents?

@scott-mcdonald The way I interpret "full linkage" is that every resource in included must have a corresponding resource identifier object somewhere else in the document, but the reverse is not required. It is valid, and perhaps useful, to have "naked" resource identifier objects that don't correspond to a resource representation in the same document.
Though my interpretation could be wrong too...

@csantero I re-read the full linkage part of the specification and you may be right... I believe though most developers would expect if a resource is referenced via a resource identifier in the data section of a relationship it would appear somewhere in the document (primary or included sections) to make the document "complete" and "atomic", but I would be interested to hear what others think.

The intent as I understand it is what @csantero described. That said, I'd be open to any ideas for making the wording clearer.

I believe though most developers would expect if a resource is referenced via a resource identifier in the data section of a relationship it would appear somewhere in the document (primary or included sections)  to make the document "complete" and "atomic"

I think I understand what you're saying (i.e., that some people might expect "if there's a resource identifier object, I should be able to match that to a resource within the document"), and it'd be perfectly reasonable to build an API that functions that way (and so just returns links rather than resource identifier objects for resources that aren't included). I think our intention though was always that resource identifier objects could be useful on their own, to tell clients if the relationship's contents have changed, even if the referenced resources aren't included.

The relevant verbiage re: "full linkage" is:

Compound documents require "full linkage", meaning that every included resource MUST be identified by at least one resource identifier object in the same document. These resource identifier objects could either be primary data or represent resource linkage contained within primary or included resources.

The example is not in violation, as @ethanresnick and @csantero have said, so I'm going to close this now. But please open a fresh issue or PR if you have ideas to improve the clarity of the wording.


Updating of TrayIcon image does not work

Sample Code:
public static void main(String[] args) throws AWTException {
    final var tray = SystemTray.getSystemTray();
    final var blackIcon = new ImageIcon(ResourceUtils.get("/tray/images/recording-dark.png")).getImage();
    final var whiteIcon = new ImageIcon(ResourceUtils.get("/tray/images/recording.png")).getImage();
    final var popUpMenu = new PopupMenu();
    popUpMenu.add("Hello World");
    final var trayIcon = new TrayIcon(
            MacOSTrayIconFixer.getInitialIcon(blackIcon, whiteIcon),
            "Tray Icon Test",
            popUpMenu
    );

    tray.add(trayIcon);
    MacOSTrayIconFixer.fix(trayIcon, blackIcon, whiteIcon);

    final var pausedBlackIcon = new ImageIcon(ResourceUtils.get("/tray/images/paused-dark.png")).getImage();
    final var pausedWhiteIcon = new ImageIcon(ResourceUtils.get("/tray/images/paused.png")).getImage();

    new Timer().schedule(new TimerTask() {
      @Override
      public void run() {
        SwingUtilities.invokeLater(()->{
          trayIcon.setImage(MacOSTrayIconFixer.getInitialIcon(pausedBlackIcon, pausedWhiteIcon));
        });
      }
    }, 5000);
  }

With the code above, the icon image does not get changed after 5000ms.
If I comment out the MacOSTrayIconFixer.fix(trayIcon, blackIcon, whiteIcon);, the switching if icon image works just fine.
Am I just missing something?
I also tried to calling MacOSTrayIconFixer.fix again but it is not working too. It somehow has empty icon graphic but still alive in the menu bar.

OS Version: MacOS 11.5.2
Machine: Mac Mini (2018)
Architecture: Intel Chipset

Hi @edmandiesamonte, take a look on last version (fixer and test).


missing import include

from django.conf.urls import include
Add this line in mysite/urls.py file , to avoid
    path('', include('myapi.urls')),
NameError: name 'include' is not defined

Hi @ravinayag - see line 2 of the file you mentioned. The import is already there:
from django.urls import path, include

Perhaps you somehow removed it while changing the code, but the repo works as currently published


Using react-play with others builders show some problems that can be corrected to be ready to switch from CRA

Others builders analysis can help to find problems in the current code, even if they are not blocking the application.
These analisys can help to improve the actual code.

error while building with react-scripts:

Will happen only if using vite instead of CRA but will happen too with webpack outside CRA, in fact, you can find it installed with cra but not assessible to others builders.

There are few errors like updating the saas dependency to Node-saas as the former one is depreciated and also material-styles is making some problems.


[Fix #8586] Add AllowForAlignment config param in CommentIndentation

While the Layout/CommentIndentation cop normally looks forward to check if a comment is correctly aligned, this new configuration option makes the cop look backwards for an end-of-line comment that the currently inspected comment is potentially aligned with.

Looks good to me. Thanks for tackling this!


Change TabLine highlight

I don't know in which different scenarios these highlights may be used, but for a regular bar of (de)selected items, I think the default deselected colors stand out too much. Like an inactive window, they should be in the background compared to the selected item.
Top (old), bottom (new)

Thanks for your contibution


Demo app fails with a 404 unless user is logged in

The demo fails with a 404 unless the user is logged in, but the requirement to log in isn't surfaced.
See http://stackoverflow.com/questions/31887028/error-404-when-image-is-uploaded-to-blob-store-while-working-locally for an example of this affecting a new user.
The proximate problem is
user=users.get_current_user().user_id()

which will raise an exception when users.get_current_user() returns None for a non-logged-in user. This is complicated by
except:
    self.redirect('/upload_failure.html')

which attempts to redirect to a non-existent file and masks the problem as a 404.
I'll submit a pull request that resolves both issues.

Thanks for the report @davewsmith, Yes, a PR would be great. Be sure to sign the CLA, as described in CONTRIBUTING.md

Both done. Sorry for the delay. I was away for a week.
On Mon, Aug 10, 2015 at 8:55 AM, Jeff Mendoza<EMAIL_ADDRESS>wrote:

Thanks for the report @davewsmith https://github.com/davewsmith, Yes, a
PR would be great. Be sure to sign the CLA, as described in
CONTRIBUTING.md
https://github.com/GoogleCloudPlatform/appengine-blobstore-python/blob/master/CONTRIBUTING.md
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/appengine-blobstore-python/issues/3#issuecomment-129504610
.


[5.0] Improve StringMemoryTest.swift

The test fails on some bots as written before.
rdar://48845923

@swift-ci Please test


download: skoala version updated to v0.40.2

download: skoala version updated to v0.40.2

@windsonsea please help to review and merge, thanks.


Refactor Andy main class to avoid dependencies on output

The Andy class currently requires the output directory. We should change that, make the Andy class to return a nice data structure, and let AndyOnWebLab write files to disk. This facilitates other clients, such as the AndyOnAWS that I'm writing right now that doesn't need files on disk, but to put them on a JSON.

This was implemented in #194


Add "ts-toolbelt" to the whitelist

Adds "ts-toolbelt" to the whitelist to bring its external typings to DefinitelyTyped (for ramda & others)

This is in production now.

Thanks!


Case of nicknames should be preserved

Nicknames are currently stored lower-cased:
<Paul> AgainstHumanity: me
<AgainstHumanity> paul: Nice! You're in!
<AgainstHumanity> We've now got 2 of minimum 4. Anyone else?
<AgainstHumanity> Type "AgainstHumanity: me" if you'd like to play too.
<grifferz> hmm, lower-cased your nick

It should be possible to store them in natural case and downcase only for comparisons.

<AgainstHumanity> The Card Tsar is filbert; current Black Card:

Scores command outputs lower case names:

213557 <Dominic> #redated scores
213557 <AgainstHumanity> [#redated] Active Players: dominic(5) filbert(5) kfullert(3) chrisjrob(3) kwyjibo(2) eckrall(2) takumo daviey prando ging
213557 <AgainstHumanity> [#redated] Top 3 all time: dominic(5) filbert(5) kfullert(3) chrisjrob(3) kwyjibo(2) eckrall(2)

Also the black command outputs the tsar's name in lower case:

213721 <Dominic> #redacted black
213721 <AgainstHumanity> Current Black Card for game in #redacted:
213721 <AgainstHumanity> → Today on The Jeremy Kyle Show: "Help! My son is _____!"
213722 <AgainstHumanity> The current Card Tsar is filbert
213722 <AgainstHumanity> Use the "Play" command to make your play!

Two instances here:

214222 <@Dominic> AgainstHumanity: winner 1
214222 < AgainstHumanity> dominic: Sorry, you're not the Card Tsar – that's filbert.

It looks like build_waitstring may produce lower case nicknames in the list of people, or single person that the game is waiting on.

Thanks @domcleal. I've consolidated all your reports into one comment and will check them off as they're fixed.

[ ]

<AgainstHumanity> I'm forcibly resigning daviey from the game due to idleness. Idle since 2015-02-26T12:04:58.
<AgainstHumanity> Now that daviey was dealt out, all the plays are in. No more changes!

Thanks, I added another to https://github.com/grifferz/pah-irc/issues/1#issuecomment-76476364.

[ ] Only one instance was fixed in 72292fa, there's still the Tsar name:

<AgainstHumanity> The winner is Filbert, who now has 2 Awesome Points! The new Card Tsar is dominic. Time for the next Black Card:

I think you've probably fixed this issue with the latest round of commits, thanks!

[ ] When a channel name is given in an unknown command privately, the sender's name is returned in lower case.  (Seems to always be downcased here: https://github.com/grifferz/pah-irc/blob/515a41d/lib/PAH.pm#L536)

<Dominic> #issue 1
<AgainstHumanity> dominic: Sorry, that's not a command I recognise. See https://github.com/grifferz/pah-irc#usage for more info.

Calling this one done now, then.

Always one more...

[ ] <+AgainstHumanity> Daviey: Sorry, this hand is complete and we're waiting on dominic to pick the winner. Please try again later.


TypeError: Cannot read property 'toString' of null when clicking on Plastic bar

When I click on the plastic bar under items in the list, it shows a TypeError.
Additional context
It seems to happen only with a link I saved for 30 SPM base. And it also happens when I do the same with Light oil.

Let me know if you still see any issues with this, it should be fixed now.


[FEATURE] Support model versioning metadata

Describe the feature
Model versioning indicates the version control of ML models. It describes the practice of storing, tracking, and managing the changes in an ML model. It's recommended support metadata management of model versioning in Gravitino.
Motivation
No response
Describe the solution
No response
Additional context
No response

@SteNicholas   Thank you for proposing this. I have two questions:

How are users currently managing model versions?
how would Gravitino integrate with the existing ML ecosystem if it supports model metadata?

I will do this ML model management feature in the next release cadence (0.8).


React Router v4

I am going to be working on this later today

Is there anything I could do to help integrate React Router v4?

My team is using v3 until the ecosystem moves to v4.  At the moment, there is limited upside to v4 with SSR and data fetching since you need to double render or use an addon to allow static route declarations. The former is meh for performance and the latter adds extra boilerplate to do the exact same thing that v3 does. My plan is to wait for v4 to get out of beta and re-assess the best path forward in order to limit churn. If we @palmerhq move to v4, then we'll upgrade.

Could you briefly explain why the double render would happen?

See #212


multithreading not working way faster

Hi,
I just run these two commands:
fastp -l 80 -n 3 -w 2 -i fastqdata/file_R1.fastq.gz -I fastqdata/file_R2.fastq.gz -o fastp_output/file_R1_2w.gz -O fastp_output/file_R2_16w.fastp_2w.gz
fastp -l 80 -n 3 -w 16 -i fastqdata/file_R1.fastq.gz -I fastqdata/file_R2.fastq.gz -o fastp_output/file_R1_16w.gz -O fastp_outputfile_R2_16w.fastp_16w.gz
And the execution times were:

w = 2: 1926 seconds
w = 16: 2185 seconds (first run), 1558 seconds (second run)

Is this somehow expected?
Server information:
CORES: 56
RAM: 380 GB
FILES SIZE: 15GB

make sure that I/O is not the bottleneck. NFS or heavily loaded file systems may reduce I/O performance drastically.

Hi,
I have recently started using fastp and currently exploring the performance scalability of this tool.
I think this issue is a relevant point to observe, but benchmark data would nice if it's already published somewhere.
Thanks in advance.

tested with fastp 0.20.1, with different -w settings from 16 to 2, all tasks take about 80s to finish the test dataset. I am using memdisk for this testing purpose.
Can anyone please show a positive example that the -w parameter actually improves speed?


CarouselView scroll "back" on web causes browser back action (unless perfectly horizontal)

https://main-api.flutter.dev/flutter/material/CarouselView-class.html
If you navigate to this page from somewhere else and try to scroll the carousel view BACK you have to slide perfectly horizontally. Any deviation and you start the mac "back" action in the browser.
Look at https://dartpad.dev/?run=true&sample_id=material.CarouselView.2&channel=main
Flutter 3.24.0-1.0.pre.214
https://github.com/user-attachments/assets/13cc05ce-5bbb-4302-9c5b-7fa196090491
I thought it was related to https://github.com/flutter/flutter/issues/143276#issuecomment-2251606907 – but I'm being told...not

CC @moffatman @Piinks

Yeah idk. Maybe we need some e.preventDefault() somewhere

Weird that it acts FINE on native, BTW. I tried on Mac desktop.

Why is it weird? Desktop apps do not have a back gesture (which is conflicting with the scroll gesture) like web does AFAIK.

cc @QuncCccccc

If the carousel is not consuming the non-horizontal scroll events, it's likely that we're letting them continue in the browser, which is more lenient with the direction of the scroll and triggering the back gesture.
I broke this here:

https://github.com/flutter/flutter/pull/145500

Before my change above, the engine would just preventDefault on every event, regardless of it being handled by flutter or not.
I think a solution for this issue is for the web engine to preventDefault all events once that the framework tells it to preventDefault, until the current touch gesture ends (on pointerUp/pointerCancel).

The same issue with a simple ListView:

CarouselView still needs more improvement for desktop and web, cause touch swipe would work on mobile devices but desktop and web can't detect touch swipe we need more events like keyboard, mouse wheel and holding down click and drag. plus CarouselController also need more simple functions like next and previous.

@4nkit-5hukla this issue is not specific to CarouselView. Please file new issues for feature requests.

I haven't verified that the issue is caused by the change above, but it's likely, especially if it affects other widgets. I'll take a deeper look, the line of when to cancel/leave events is very blurry :P

Is there a temporary workaround to fix this issue? It seems to occur with all horizontally scrollable widgets, like TabBarViews and TableViews, where scrolling pushes back or forward navigation pages, leading to a poor user experience. Perhaps disabling the swipe gesture navigation completely could help?

@enqvida, try specifying overscroll-behavior-x on the html element inside your index.html
html, body {
  overscroll-behavior-x: none;
}

Started getting complaints about this recently on Chrome. It's an incredibly frustrating experience to be navigated off the site constantly. I compared the behavior to non-flutter sites that have horizontal scrolling, and the back navigation arrow doesn't kick in until you reach the end of the horizontal scroll. On flutter apps it now immediately navigates back instead of scrolling.

Kate Lovett, I'm not sure why my contribution to the issue, with additional observations, would be classified as spam. This is the first comment I've made on the issue. I am not spamming anything. Really bad look to be so defensive towards a comment that wasn't toxic or spam.

@enqvida, try specifying overscroll-behavior-x on the html element inside your index.html
html, body {
  overscroll-behavior-x: none;
}

This solved my issue :)

@enqvida, try specifying overscroll-behavior-x on the html element inside your index.html
html, body {
  overscroll-behavior-x: none;
}

That is not a solution for me.
Flutter should prevent the external scrollview (including the non-flutter) from scrolling until the internal one reaches the end.


make API call to getBlock() to determine if emulator is fully up

Description
Change the way flow-js-testing detects emulator status: from reading emulator logging to making an API call to /live endpoint
Related issue: https://github.com/onflow/flow-js-testing/issues/61
tests

create a simple test project, verified tests are working there
introduce long delay in emulator startup, verified tests are working
introduce long delay in emulator startup, set a short timeout for tests, verify test will fail due to timeout

For contributor use:

[x] Targeted PR against master branch
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
[ ] Code follows the standards mentioned here
[ ] Updated relevant documentation
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Added appropriate labels

@kerrywei what version of CLI we need to enable this?

current latest version is good enough, that /live endpoint has been there for a while. once Gregor implemented all RESTful APIs including the /ping API, we can switch to the /ping API, which is more official

merge in the solution to get it further vetted by the community. I run the pipeline 42 times, all succeeded with any failures