StoryItem properties issue

Hi, I have been able to download posts as well as their property values without issue for a while, which is great.
I started downloading stories recently, and the media downloads fine but the property values will not print/display.
I know that these property values exist as they are in the documentation but I have had no luck getting these values to print in my console.
I can print post.date_utc, post.shortcode etc.
But every time I try to print StoryItem.shortcode, StoryItem.mediaid, or any other StoryItem properties, I get this error:
Traceback (most recent call last):
File "main.py", line 47, in
print(StoryItem.mediaid)
AttributeError: 'generator' object has no attribute 'mediaid'
I tried it with every property and nothing worked.
Is StoryItem not the correct class for this?
Or is it by design that these properties cannot be isolated in the same way that they can be with posts?
Thank you in advance.

This is not the right place for basic Python programming questions.

The Instaloader documentation states that certain properties for this class exist in a format that is meant for python programming. They do not exist in that format.
I believe that's a documentation problem, not a python programming problem.
Nonetheless, I have made do with what I have at my disposal for this class.
Thank you.


Update and test the helper functions

Before implementing the state transition function, the helper functions that I badly implemented need to be updated and tested. It will need to be compatible with any choices made with regards to using buffers/bignumber.js and arrays and work in the browser.

This will be closed in #39  as it is no longer relevant.


Docker image for easier development?

Reference, thread on discord: https://discord.com/channels/933071162680958986/933071163184283651/1154540600293609652
User suggests - and I agree - that it would be helpful to provide a docker image that includes the turso cli, the libsql-server, and ways to mount existing SQLite files into the libsql-server directories. This could be helpful for some CI pipelines

The way I would use it is with a docker-compose.yaml file like the following:
version: "3.8"
services:
  sqld:
    image: ghcr.io/libsql/sqld:v0.20.3
    ports:
      - "8080:8080"

  bootstrap-db:
    image: turso
    volumes:
      - ./database:/bootstrap
    working_dir: /bootstrap
    command: ["db", "shell", "$SQLD_URL", "<", "init.sql"]
    environment:
      SQLD_URL: http://sqld:8080
    depends_on:
      - sqld

  my-astro-app:
    image: node:18.14.1
    ports:
      - "4321:4321"
    volumes:
      - ./:/app
    working_dir: /app
    command: npm run dev -- --host
    environment:
      SQLD_URL: http://sqld:8080
    depends_on:
      - sqld
      - bootstrap-db

Alternatively, instead of running a bootstrapping sql script you could mount an sqlite file:
services:
  sqld:
    image: ghcr.io/libsql/sqld:v0.20.3
    ports:
      - "8080:8080"
    volumes:
      - ./db.sqlite:/var/lib/sqld

Another thing that I see often is adding tooling helpers into a docker compose file. For example:
services:
  turso:
    image: turso
    working_dir: /app
    volumes:
      - ./:/app

Paired with alias dcr = "docker compose run --rm" allowing for dcr turso [COMMAND] when in the project directory. This prevents bespoke tooling installs if you're constantly dealing with different technologies and it also means the whole development team is running the same version of the tooling in the same way.
Just some ways in which I might use this. Hope it helps!

Hi, any update on the status of this? In the interim I have published my own image so that I can be unblocked but it would be great to have this officially be a part of your pipeline.
Here's the Dockerfile I used. Mostly a copy + paste of your libsql-server image with some extra stages.

Yeah I think this makes a lot of sense to add, will make sure it gets added to the roadmap.

@LucioFranco do we have any updates about it?

Any updates?


cython as a CMake Language

Quite some time ago I was researching adding a CMake language using CMake<Lang>Information.cmake with a prototype using Fypp. I don't remember where I've left off in that process, but iirc the issue was on the Fortran side. Probably for C/C++ adding a language as a preprocessor would still work.
Alternatively, for fypp I ended up writing it as Fypp_target_sources instead. That could also be a more CMakey way of implementing this support.
Has anyone else looked into the adding custom language approach?

I don't think this is the correct approach. Cython is a transpiler. You still need a language compiler (C or CXX) to compile the file that Cython transpiles. You'd still need C or CXX settings, etc, on the targets.

You can combine compiled objects from different languages. The issue that I've encountered is that even aa I generate the C/CXX file, I cannot trick CMake to add it as a source when inside the CMake<Lang>Information.cmake. This would need some patches upstream to allow chaining of target_spurces based on input and output extensions.
Any specific concerns about an Cython_target_sources which simply chains the transpile and target_sources command?


Supporting Bundled Products in VAT calcuations

We currently support VAT calculations based on product type. Some products however are bundles that can contain different product types.
A common case is a bundle that has a Physical Book + an Ebook which typically fall into different VAT brackets.
Currently a product definition looks like this:
<script id="netlify-commerce-product" type="application/json">
{"title": "A Book", "prices":[{"amount":"39.00","currency":"USD"}], "sku":"my-book", "type":"Book"}
</script>

We should allow specifying that a price is based on multiple product types:
<script id="netlify-commerce-product" type="application/json">
{"title": "A Book", "prices":[{"amount":"39.00","currency":"USD", items: [{"amount": "24.00", "type": "Book"}, {"amount": "15.00", "type": "Ebook"}], ], "sku":"my-book", "type":"Book"}
</script>

And take this optional "items" definition into account when calculating VAT.

It is critical to solve. Thanks

This has already been implemented. Closing.


Use on cpu ?

Is there anyway we can use the package on a cpu ?
If so, anything would need to be adjusted ?

@tim-habitat Thanks for your interest in the project.

Is there anyway we can use the package on a cpu ?

I am afraid no. Since the models are developed for runtime efficiency, both the base Py-Boost and Py-BoostLSS models work only on GPU.


how compile

i have no clue what im doing here i just want it to work

Provide more informations like which display and so on.

Sorry, it is not easy to provide an out of the box solution - this kind of work does unfortunately require some background knowledge.

i just want it to work

I admit I have also been there so many times when doing development, it can be frustrating. The first thing to recommend is to take a step back and relax the ambition level and expectation of what you want to achieve and when. That can help ease the anxiety of getting to results quickly and result in better success in the long run.
Then, maybe a good way to become more familiar might be to check through a couple of tutorial videos that explain the details of the driver installation step by step. There are some YouTubers who are really great at explaining the steps, here are some that I have seen:

Brackets Academy: RetroPie 3.5 inch SPI display HIGH FPS (FBCP - iLi9341),
Scott Marley: 60fps on an SPI display using the Raspberry Pi and fbcp-ili9341 (includes fix for 320x240 ST7789),
Bytes N Bits: RetroPie on a Raspberry Pi Zero at 50FPS on an SPI LCD Screen With ILI9341 Driver](https://www.youtube.com/watch?v=uz4sa24C4gk)

and more if you search for fbcp-ili9341 in YouTube. Hope that helps!

thanks


emacsPackages.semi: fix build

https://hydra.nixos.org/build/281814164

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-reviewd workflow started

Extra args: ``
Free space: true
Who asked: lucasew

TARGETS

x86_64-linux: true
x86_64-darwin: false
aarch64-darwin: false

Status and logs: https://github.com/nixosbrasil/nixpkgs-reviewd/actions/runs/12447989896

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 367098

x86_64-linux

:white_check_mark: 2 packages built:

emacsPackages.semi
emacsPackages.wanderlust


How to use Typia with Next.js

Hi, I'm trying to set up Typia with Next.js but I can't find a way to make Typia work when I start Next.js with "next dev"...
Can you explain to me how I have to set things up so that when I start "next dev" typia starts the compilation/generation?
I was thinking of doing the following thing:
When I start the script with "npm run dev" this happens:

copy all project file inside typia_build folder
start generation of typia with npx typia generate inside typia_build
start nextjs with "next dev" inside typia_build

The only problem is to copy all the node_modules that are heavy and take too long, do you have any ideas?

Looks like I managed to use Typia with Next.js 14
It works on both the client side and the server side, I used the following configurations on next.config.js:
`/** @type {import('next').NextConfig} */
const nextConfig = {
webpack: (config) => {
config.module.rules.push({
test: /.(tsx|ts)$/,
exclude: /node_modules/,
loader: 'ts-loader',
});
config.resolve.extensions = ['.tsx', '.ts', '.js'];
return config;

},
};
module.exports = nextConfig;
`
Also I had to add these 2 options on tsconfig.json:"allowJs": false, "noEmit": false,
The important thing was noEmit, but tsconfig gave me an error and the only way I found to fix it was to put allowJs on false

If you are emitting it probably seems to you like it is working but it is not in reality.  The emitted typescript is not used by nextjs they compile using swc which wouldn't support this.
Basically the types probably work fine even without any changes to your nexxt config -- but next uses their own compiler and everything so you'd almost surely need to use the generation method to build typescript from the typescript then pass that to nextjs for it to work.
Basically best if you use a monorepo and have that setup but you could manage without doing that.
Otherwise typia would need to have a plugin for swc which would be awesome for sure
https://nextjs.org/docs/architecture/nextjs-compiler#swc-plugins-experimental

@bradennapier I understand... but how can I make it work with the generation mode?
Because I wish I could use it in development mode too... so I should find a way to do so that every time nextjs finishes recompiling the project it runs the script typia generate...
But clearly in next dev mode the compilation happens every time a file changes automatically... how can I add "typia generate" script that modifies the build every time?

@bradennapier did you manage to make it work on NextJS with a monorepo ?
I tried with Turborepo / Sveltekit but Typia seems to not be working :
https://github.com/samchon/typia/issues/873

Disclaimer: I've been checking this repo every once in a while to see how it evolves but I have not yet tried typia at all.
@karim2012 With the disclaimer out of the way, I've been watching the repo to pick any signs of Next.js support in one way or another. Hence, this thread seems interesting. While we're not using typia on my current project, we are using graphql-codegen.
The way we use it in dev mode is  simply by having two terminals open. One is running next dev and on the other a nodemon watching changes on *.graphql and triggering code generation on changes. The codegen will output the generated filed into a directory within the Next.js app, so it in turn hot reloads when the generated files changes.
Could something like this could work in this case as well?

@ristomatti I had thought about this solution too, but there is a passage that is not clear to me...
Let's make a guess... I have my page.tsx file where I write a typia function inside it...
As soon as I save the file, nodemon activates and trigger the code generation... now the problem is:
Where will the output be generated? Because clearly you can't overwrite the file you were developing on, so you'll have to direct the output to another folder, but that doesn't work anymore since there would be problems with the imports of the files since they changed path...
The only way to make this thing work is that every time a file is edited you copy the entire project to another folder, run the generation and clearly next dev needs to be started to that new folder... but it seems very inefficient to me... like this:
root
|-- generated_project (output of typia generate)
|-- project
|-- node_modules
|-- app
|-- components
|-- etc...
Now what has to happen is that you start next dev on the generated_project folder.
And every time a file is modified within the project folder, it is generated using ./project as input and ./generated_project as output
But that way you have to copy all the node_modules too or am I wrong?

@ristomatti Sorry, now I've fixed the file tree that I tried to describe in my previous comment,
Anyway no I can't do as you say, because I have the following situation, I'm using the server actions and the router app...
So I have a server actions done like this:
`
"use server"
export async function updateUser(userData: Partial, userId: string){
typia.assert<Partial>(userData)
// or typia.assert(userData) it's the same thing
// update data to database
prisma.user.update({
where: { id: userId},
data: userData
})
}
`
quindi io avrò un sacco di chiamate a typia sparse in tutto il progetto, e sarebbe troppo inefficiente per me avere il codice di validazione in un unico punto...

@ristomatti The only thing that comes to my mind is to "overwrite" in development mode the typia package with a typia.assert function that does nothing... like this:
export function assert(data:any){
}

And then somehow make sure that when the build is done the actual typia package is used ...

@karim2012 Does the app router break if you'd move the validation into a function call in a wrapper function? Or is it possible to wrap the function in a higher order function?

If you can't get anything else than the overwrite strategy working, you can could move the line that calls typia into an exported function which you define it as a noop function based on the value of process.env rather than overwriting the whole file?

@ristomatti I could do something like this:
lib/typia.ts
import prodTypia from "typia";
const devTypia = {
  assert(){},
  validate(){},
  ecc...
}

const typia = process.env.NODE_ENV === "development" ? devTypia : prodTypia
export default typia;

And always use typia from the lib/typia.ts file...
I believe this could be the solution to the problem

And always use typia from the lib/typia.ts file...
I believe this could be the solution to the problem

This is essentially what I meant with noop. Proxy is a clever trick for this purpose. I'll also note that I see the issue better now, (I was answering from mobile yesterday and missed a few details). It would definitely remove most of the convenience provided by typia if you'd have to define a separate validator function for each endpoint.

@karim2012 I see you've closed this. Was the last snippet the solution you went with in the end?
Personally, I think it's still a workaround. It doesn't allow fast iterative testing/development cycle if it only works on a product build. Taking into account the huge popularity of Next.js, it'd be great to have an usage example as part of the documentation. Please consider reopening the issue.

@ristomatti Hi, yes in the end I went with the last snippet of code, personally it's fine with me too since I only have to use typia to prevent an attacker from sending data that doesn't meet expectations, but okay, I'll reopen the issue
In any case, thank you very much because if we have come to this alternative solution it is also thanks to you!

https://typia.io/docs/setup/#unplugin-typia
Hi guys!
You can check this out

@samchon
Same as https://github.com/samchon/typia/issues/812#issuecomment-2175598578


Add docker-compose info that works for non-SSL installs

This set up is allowing me to run in Docker for my Cs

thanks!


Integration with egui

I like very much the direction truck is going and as very early adaptor I am trying to integrate it with egui. Truck has a nice wgpu integration and for egui there is also a wgpu integration example. So I would like to use egui for all the app initialization and event handling and truck just for rendering a truck scene.
Now I took a look at truck-js to get an idea for the most bare bone approach, turning a Polygon mesh into a buffer suitable for webGL. However I would like to reuse as much as possible from truck wpgu render implementation. I think the examples and also what is in the tests folder is important for my use case. However I feel a bit lost right now ...
So my questions are:

is there any plan to support any particular GUI libraries ?
in case you are familiar with egui, do you have any advice ?
does it make sense, just to get from the truck scene a low level wgpu object which I render somehow just before egui does its rendering ?

While waiting for your advice, I tried myself to come up with something. So here what I did: I used the truck app framework as base and just added the egui rendering as part of the app.render() implementation. Here is how it looks like:
    // This method is called every frame.
    fn render(&mut self) {
        // truck
        self.scene.render_frame();  // with `surface_texture.present();` commented out

        // egui
        let frame = self
            .scene
            .window_handler  // had to make public
            .surface  // had to make public
            .get_current_texture()
            .unwrap();
        let target = frame
            .texture
            .create_view(&wgpu::TextureViewDescriptor::default());
        let mut encoder =
            self.scene
                .device()
                .create_command_encoder(&wgpu::CommandEncoderDescriptor {
                    label: Some("Render Encoder"),
                });
        let surface_config = &self
            .scene
            .scene_desc  // had to make public
            .render_texture
            .compatible_surface_config();

        self.egui_renderer.render(
            &self.scene.device(),
            &self.scene.device_handler().queue(),
            &mut encoder,
            &target,
            &mut self.gui,
            self.scene.window_handler.window.scale_factor(),
            surface_config,
        );

        // Submit the command buffer to the queue to run everything.
        let _ = &self.scene.queue().submit(Some(encoder.finish()));
        frame.present();
    }

As you see in the code comments above, I had to make public several private members and sub-members of WindowScene. And in the original Scene::render_frame code I had to comment out the last line (surface_texture.present();) and then call it explicitly after I had done all the egui rendering steps. The egui stuff itself is based on egui_wgpu_backend and for egui_renderer I am using a little helper which I more or less just copy-pasted from the ennoa project. And I had to slightly modify the truck app framework, in order to possibly handle first any events from egui.
To sum up: with this approach I got egui  and truck rendering in the same app, but unfortunately I run into a borrow checker issue when I tried to make the scene accessible from the egui app. And on my mac it horribly leaks memory. After a few minutes the app panics. But that is (hopefully) just related to a mac-specific wgpu issue (which has been fixed on the wgpu master branch already)
Now my questions are:

Do you have any suggestion for a different approach where WindowScene does not need to be modified ?
What about an alternative truck app framework which has the egui integration already baked in ?  I was thinking of just merging the relevant parts of the wgpu-egui-demo-app with the truck app framework. I will probably try that next ...

The app framework in truck's examples has been left out of the package for modification. Please feel free to modify it.
We certainly need a methods to get Window and Surface references from WindowScene. We'll implement that.
The field scene_desc of Scene can be referenced using the method Scene::descriptor. Please use it.
Now, about render_frame, this method consists of three steps:

Make sure the size of the depth buffer etc. matches the size of the window.
Get the current texture of the surface.
Draw on the current texture.
Present the current texture.

Since the implementation for egui is done in step 2, I think the problem can be solved by creating a public method that does step 1.
We'll implement it today, Japan time.

Now some new methods implemented. Please try to use the following code.
    // This method is called every frame.
    fn render(&mut self) {
        let frame = self
            .scene
            .surface()
            .get_current_texture()
            .unwrap();
        let target = frame
            .texture
            .create_view(&wgpu::TextureViewDescriptor::default());

        // truck
        self.scene.size_alignment();
        self.scene.render(&target);

        // egui
        let mut encoder =
            self.scene
                .device()
                .create_command_encoder(&wgpu::CommandEncoderDescriptor {
                    label: Some("Render Encoder"),
                });
        let surface_config = &self
            .scene
            .descriptor()
            .render_texture
            .compatible_surface_config();

        self.egui_renderer.render(
            &self.scene.device(),
            &self.scene.queue(),
            &mut encoder,
            &target,
            &mut self.gui,
            self.scene.window().scale_factor(),
            surface_config,
        );

        // Submit the command buffer to the queue to run everything.
        let _ = &self.scene.queue().submit(Some(encoder.finish()));
        frame.present();
    }

Ok, thanks a lot, tried it, unfortunately compiler complained and I (don't fully understand why, but I) had again to make private members public in truck source.
in platform lib.rs
#[derive(Debug)]
struct WindowHandler {
pub struct WindowHandler {
    window: Arc<winit::window::Window>,
    pub surface: Arc<Surface>, // HERE
}

/// The unique ID for `Rendered` struct.
pub struct WindowScene {
    #[deref]
    #[deref_mut]
    scene: Scene,
    pub window_handler: WindowHandler, // HERE
}

and in platform Scene.rs:
impl RenderTextureConfig {
    pub fn compatible_surface_config(self) -> SurfaceConfiguration {  // HERE
        SurfaceConfiguration {
            usage: TextureUsages::RENDER_ATTACHMENT,
            format: self.format,

Ups, mistake on my side, the private members I accessed from somewhere else, so ONLY the compatible_surface_config which still needs to be made public.

OK. Now, compatible_surface_config is public in master branch!

We remark that this method must be called after size_alignment. Otherwise, the panic occurs caused by the mismatch between the surface size and the window one.

@ytanimura thanks to your help, now the egui integration works fine. I still have issues with my demo example but they are caused by my code, not by egui or truck. So I am gonna close this ticket.


Added a sample Preview-pdf-without re-mapping, also improved two othe…

…r samples.
Changes:

Added the new sample. I think this is related to #44 of your list of issues in https://github.com/SuffolkLITLab/docassemble-assemblylinewizard/issues. Please let me know if this solves the problem.

Simplified two other samples, which used to use two attachment blocks, to use only one. Also added an intro screen for them.

Made a few minor fixes in other files as well.

I'll try to take a look at this soon. Sorry I'm so busy. I'm also going to put @nonprofittechy on this since he's had more experience with attachments.
For reference, the wizard issue is https://github.com/SuffolkLITLab/docassemble-assemblylinewizard/issues/44.

Are there any questions, or are we ready to merged this?

Sorry it took so long. I did a review, but then apparently didn't post it. Other than not being able to test it fully yet, I think it holds up. If you want to address the comments to add information for a developer that would use it, I think that would be helpful.
Catch me on Slack if you want and you and I can test the multi-user part together.

Thank you for your comments! I'll wait for your response then check in the changes I mentioned in my comments above.
This is how I tested the multi-user sample:

create a user account with a fake email address,
when you run the interview, enter use that address for the second user
when you get to the screen to wait for another user's signature, login from a different browser using that fake email address, voila!

I'll try to do that when I get a chance.
By the way, I think #44 in the wizard was trying to do something that would work even when people don't have user accounts. I think Quinten has found a way to work with that. It may have involved a new feature of da, I'm not sure. In general we want to make sure people without accounts can use these forms too.
I'll check this code out with multiple accounts and make sure it doesn't error and let you know!

I'm having a little trouble, but may be doing this wrong. We should be done with the Moratorium sometime next week, so maybe then you and I can get together and figure out what's going on.

Sorry I got confused about the versions.
Basically I added more explanations in each file as suggested. Note that the 2 multi-user signature yml files are renamed, so they appear as new.


[BUG] When calling Opensearch Bulk API, host and port are called in a non-combined form.

What is the bug?
As stated in the official document, errors occur in host and port when creating the Client.
https://opensearch.org/docs/latest/clients/python-low-level/
client = OpenSearch(
    hosts = [{'host': host, 'port': 443}],

How can one reproduce the bug?
import boto3
from requests_aws4auth import AWS4Auth
from opensearchpy import OpenSearch, RequestsHttpConnection, AWSV4SignerAuth

host = '<opensearch_domain>/_bulk'
region = 'ap-northeast-2'
service = 'es'
credentials = boto3.Session().get_credentials()
awsauth = AWSV4SignerAuth(credentials, region, service)

index = 'movies'
datatype = '_doc'

client = OpenSearch(
    # hosts=[{"host": host, "port": 9200}],
    hosts=[host+"9200"],
    http_auth=awsauth,
    use_ssl=True,
    verify_certs=True,
    connection_class = RequestsHttpConnection,
    pool_maxsize = 20
)
movies = '{ "index" : { "_index" : "movies", "_id" : "2" } } \n { "title" : "Interstellar", "director" : "Christopher Nolan", "year" : "2014"} \n { "create" : { "_index" : "movies", "_id" : "3" } } \n { "title" : "Star Trek Beyond", "director" : "Justin Lin", "year" : "2015"} \n { "update" : {"_id" : "3", "_index" : "movies" } } \n { "doc" : {"year" : "2016"} }'

client.bulk(movies)

Error
requests.exceptions.InvalidURL: Failed to parse: https://[<opensearch_domain>/_bulk]:9200/_bulk

What is the expected behavior?
I re-set the host in the following format and it works normally.
client = OpenSearch(
    hosts=[host+"9200"],
    http_auth=awsauth,

Do you have any additional context?
In summary, it seems that when i create the Opensearch client, i need to create the host and port as a string and then put it in the list.
However, the official document says that i need to save it in dictionary form in the list. Please check this part to fix the bug.

I believe host should just be the host, not '<opensearch_domain>/_bulk', aka '<opensearch_domain>`. I checked the docs but I am not seeing anything that has implied otherwise? Help me find what needs changing? Or contribute to https://github.com/opensearch-project/documentation-website directly?

Yes, thank you for your reply. As you said, it seems that you can subtract _bulk from the host. However, the code below needs to be modified.
An error occurs when executing the code below.

hosts=[{"host": host, "port": 9200}],

Failed to parse: https://[https://.....ap-northeast-2.es.amazonaws.com/]:9200/_bulk

If you put hosts in the list as a string, it works normally.

hosts=[host+"9200"],

I think this is by design.

An error occurs when executing the code below.
hosts=[{"host": host, "port": 9200}],

this produces
hosts = [{"host":"https://.....ap-northeast-2.es.amazonaws.com/_bulk", "port":9200}]

which is incorrect, this is not a host, this is a URL. The error is expected.

If you put hosts in the list as a string, it works normally.
hosts=[host+"9200"],

produces
hosts=["https://.....ap-northeast-2.es.amazonaws.com/_bulk9200"]

There's code in the client that allows you to specify a URL in hosts that contain both a host and a port. This translates to
host = 'ap-northeast-2.es.amazonaws.com' and port = 443 (not 9200, note the missing : as it adds it to _bulk9200).
Is there still a scenario that doesn't behave as you'd expect?


Figure out Auth implementation using Next Auth

Current Website uses Next Auth for authentication and session based login, figure out a way to implement next auth in app
or for v1 get user to redirect to website to login and get the session key, and rest all steps would be in native only.
or something else, idk i am noob in this

you mind if I take on this?

you mind if I take on this?

nope, completely open for contributions
just go through readme and set it up properly

lol


Allow multi-select in the part-of-speech dropdown

Allow the user to select all the Verb types, that is Complex Verb, Compounded Verb, and Copular Verb for one search on entries that have a verb part of speech.
Sites for testing:

https://www.webonary.org/odissi/
https://www.webonary.org/akoose/

The cloud API portion of this will be done in #450

Would it be possible to have a scroll bar in the dropdown box like this:


Parameter validation proof of concept

Description
This PR introduces a parameter validation proof of concept in two commits, that introduce the feature at two levels: basic and enhanced with a failure callback mechanism.
The mechanisms implementation and usage is demonstrated on the example of some functions in the AES module.
Most of the original design and code was provided by @sbutcher-arm. Compared to his prototype, this code has the commit history cleaned up, and reduces the flexibility of the callback mechanism to the run time only dispatch.
Requires Backporting
To be established
Migrations
NO
Additional comments
Users of this feature should consider adding a custom failure callback function, especially for validating input of the functions that don't return exit codes.
Todos

[ ] Tests
[ ] Documentation
[ ] Changelog updated
[ ] Backported

This PR extends the design of the original parameter validation work with some new ideas and concepts, such as being able to programmatically set the callback function for the parameter validation failure. They have merit, and maybe we'll add them in at some point - but right now these changes are outside the scope of the agreed and approved design, so have to wait unless we have a really good reason to add them in.
Therefore I'm closing this PR, and it will be replaced by either its predecessor #1643 or the newer PR #2268.
@hanno-arm / @mpg - you give some really good feedback and review comments. Can you please ensure those review comments are in at least #2268, if not #1643.


chore: move files into Analysis.Normed.Algebra

This is meant to be one part of a larger organizational project for Analysis.NormedSpace. This moves files related to algebras into their own folder.

Grouping these files looks reasonable. The new folder "Algebra" is ambiguous (and could refer to the mathematical object as well to the area); I don't see an obvious alternative, though. Let's have some more eyes on this:
maintainer merge

Thanks!
bors merge


Filter ajax

Hello.
I installed the module: Ajax Filter FREE (by Filter and by search keywords).
But it only works on default theme. When I change to materialize theme it stops working and I get in console that d_ajax_filter is undefined. Checking I realized that the css / js files are  in the theme default folder and Its not putting the css styles on the page.
Why is it saving the files in the default theme?

While I may not be sure about why the files are saved in the default theme, it's important to make sure that the module is compatible with the theme. Some modules and other extensions will only work with specific OpenCart themes, and, getting the developer to tweak it to work for your specific setup usually costs a fee.


Allow test/lint scripts to run without requiring make

Fixes #877.

@edemaine I've re-added the Makefile targets to alias the new npm scripts.


IoT2000: document in supported devices page and create getting started guide

This is there in both locations so closing https://www.balena.io/docs/learn/getting-started/iot2000/nodejs/


Switch Windows CI to Travis

With Travis CI releasing experimental Windows support, we've seen good success incorporating Windows CI using Travis.
It would be useful to use a single hosted CI service for both Windows and Linux.

OBE with GitHub Actions.


build(feat): add a notification when submitting betas with sentry link

This PR resolves []
Description

Sends a message to slack after submitting betas for review with a link to the sentry release for monitoring.
Suggestion from @gkartalis to make monitoring release easier + let people know when builds are submitted for review!
PR Checklist

[ ] I have tested my changes on iOS and Android.
[x] I hid my changes behind a feature flag, or they don't need one.
[x] I have included screenshots or videos, or I have not changed the UI.
[x] I have added tests, or my changes don't require any.
[x] I added an app state migration, or my changes do not require one.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Add a slack message when submitting betas - Brian, George

Need help with something? Have a look at our docs, or get in touch with us.

This PR contains the following changes:

Dev changes (Add a slack message when submitting betas - Brian, George)

  Generated by :no_entry_sign: dangerJS against d84feb9cda0e8f870cbe3dac700d973a6b12b904


Transcribe from another language

Hi,
I plan to test this demo using a Chinese language video.
To make Transcribe support Chinese, I exported lambda function code "transcribe-MediaAnalysisStac-*.zip" and modified two files: /lib/transcribe/transcribe.js and /lib/transcribe/transcribe.js (I only changed LanguageCode from "en-US" to "zh-CN")
I used aws lambda update-function-code command to update this lambda function and got a success respond.
But I encountered an error respond when I tried to create metadata. Error messages are as follows:
{
  "Error": "AnalyticsError",
  "Cause": "{\"errorMessage\":\"media-analytics-solution state machine failed, FAILED\",\"errorType\":\"AnalyticsError\",\"stackTrace\":[\"exports.getAnalyticsStateMachine (/var/task/lib/metadata/analytics/index.js:206:13)\",\"<anonymous>\",\"process._tickDomainCallback (internal/process/next_tick.js:228:7)\"]}"
}

Does anyone could guide me how to fix this issue?
Thanks

Hi @weiping-bj,
The problem you encountered is because Chinese language is currently not supported with Amazon Comprehend (our NLP service).
Although Amazon Transcribe can process zh-CN, the analysis state machine will still fail when it runs the NLP process with Amazon Comprehend.

Hi @aws-kens ,
Thanks for your feedback. I have two more questions.

Based on my understanding, if the analysis state machine would throw an error when it runs Comprehend, Transcribe process should be successfully executed. But I didn't find any executed jobs in Transcribe console (either successful or failed). Please correct me if my understanding is wrong.
How to bypass Comprehend if I just need transcribe and subtitle function?

Thanks

Hi @weiping-bj,

You are right. If it runs the Transcribe service, you should be able to see the job in Transcribe. There is a state machine called media-analysis. You can check to see if the detail error from that state machine.
With the current version, you would need to modify the media analysis state machine to bypass the Comprehend logic. We do have a beta private program for Media2Cloud V2 that can disable specific AIML detections. Let me know if you are interested, I will send you a separate email.

Hi @weiping-bj,
We have just launched a major update of Media2Cloud V2 that has a lot of enhancements and new features. V2 should resolve the problem you had before. Give it a try


Improve font-fallback behavior

Implement a better font-fallback behavior. When a character is not covered by the primary font, use a secondary font (e.g., STIX) that includes the necessary glyph.
Might even help resolve #919, #795, #497 and #316

Sorry this is not a very helpful contribution but just to comment that I came across this today when trying to figure out why the apE entity didn't work for me in MathML, and it would be really great if a fallback could be implemented.
Personally I was initially a bit taken aback since I'd read the documentation page about MathML support that said it supports 100% of characters which I had assumed meant everything in the MathML entitity lists at the spec; I don't think it mentions that this only applies if you select a (non-default) font... :)

I'd read the documentation page about MathML support that said it supports 100% of characters

I can't find the reference to that.  Can you point it more specifically out so it can be fixed?

Sorry. I'm not sure the MathJax documentation is actually wrong in any way, it just perhaps wasn't where I expected! May be user error...
http://docs.mathjax.org/en/latest/mathml.html
Has a list 'Supported MathML commands' which under 'Deficiencies' does not mention any character limitations.
This then links to W3C test suite results (so it's not your documentation at all) http://www.w3.org/Math/testsuite/results/tests.html - under 'Characters' this says '100%'. if you look in the detail at the top, which I didn't look at previously, you can see that in the configuration they set it to use STIX-Web.
The current behaviour IS accurately documented on this page:
http://docs.mathjax.org/en/latest/font-support.html
So I guess what confused me is seeing the '100%' test suite result without noticing that this only applies when selecting the STIX font.

I don't think that passing the test suite means that every character is available in the MathJax fonts.  It means that MathJax properly processes the unicode values and typesets them so that they will be displayed if an appropriate font is available.  Since unicode specifies hundreds of thousands of characters, no font is going to cover all of them, and the default MathJax fonts certainly don't.  The STIX fonts cover a much larger range (though certainly not all of unicode either).
That being said, better documentation of the exact coverage of the different web fonts MathJax makes available would clearly be a good thing.

Oh, I see. To clarify, I certainly don't expect it to work with every Unicode character - I had (very likely incorrectly, as you say) assumed that the test suite meant they checked the list of defined entities in the MathML standard, which is 'only' thousands rather than hundreds of thousands...

Thanks for commenting, @sammarshallou. Fonts and Unicode coverage is a messy topic. Just like browsers themselves, we are to limited by the fonts on the system; providing webfonts is one way of working around this but it cannot solve all problems. The argument for passing those tests is that MathJax does the best it can with Unicode points not covered by the fonts. Additionally, for the longest time, MathJax had to work around broken browser implementations where Unicode support beyond the BMP was erratic. I don't really know a succinct way of improving the documentation, but I've created https://github.com/mathjax/MathJax-docs/issues/106
Note to self: the OP does not adequately describe the complexity of the existing fallback mechanisms and which kinds of improvements we have in mind here.


Update dependency @types/uglify-js to v3.17.4

This PR contains the following updates:

Package
Type
Update
Change

@types/uglify-js (source)
devDependencies
patch
3.17.2 -> 3.17.4

Configuration
📅 Schedule: Branch creation - "before 4am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Self-Hosted Renovate Bot. Find all logs here.

 You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.


update left and right_virtualspace

This is a fix of the long-standing issue #103, which rewrites the package to consistently use left_virtualspace to denote the space to the left of a lattice site, and right_virtualspace to denote the space to the right of a lattice site. Additionally, they are both returned "non-dualised", i.e. left_virtualspace(mps, i + 1) == right_virtualspace(mps, i).
This is obviously very breaking, but should be more consistent in the future.

how do you garantuee left_virtualspace(mps, i + 1) == right_virtualspace(mps, i) during twosite algorithms?


use latest ubuntu docker image

since older one is giving error or atleast the alipne docker image and I couldn't find the docker image for the dockerfile-cgo build one
{"level":"error","timestamp":"2022-03-30T10:45:51.240Z","caller":"event/poster.go:72","msg":"Error retrying packet drop handling, backing off","packet_drop":{"pkt_log_time":"2022-03-30T10:35:53.429Z","pkt_src_ip":"<IP_ADDRESS>","pkt_src_port":"43114","pkt_dst_ip":"<IP_ADDRESS>","pkt_dst_port":"53","pkt_proto":"UDP","pkt_ttl":"62","pkt_mac_addr":"","pkt_interface_recv":"tunl0","pkt_interface_sent":"calif32b9156d0f"},"retry":0.924353697,"error":"selfLink was empty, can't make reference","stacktrace":"github.com/box/kube-iptables-t
ailer/event.(*Poster).Run.func2\n\t/root/go/src/github.com/box/kube-iptables-tailer/event/poster.go:72\ngithub.com/box/kube-iptables-tailer/vendor/github.com/cenkalti/backoff.RetryNotify\n\t/root/go/src/github.com/box/kube-iptables-tailer/vendor/github.com/cenkalti/backoff/retry.go:49\ngithub.com/box/kube-iptables-tailer/event.(*Poster).Run\n\t/root/go/src/github.com/box/kube-iptables-tailer/event/poster.go:80\nmain.startPoster\n\t/root/go/src/github.com/box/kube-iptables-tailer/main.go:78"}

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Ashish Jaiswal seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

You can use https://hub.docker.com/repository/docker/honestica/kube-iptables-tailer build from https://github.com/honestica/kube-iptables-tailer

You can use https://hub.docker.com/repository/docker/honestica/kube-iptables-tailer build from https://github.com/honestica/kube-iptables-tailer

ok great, I can use that, didn't looked at forked project.
Thanks.
I see the forked has more commit, it has some more bug or should I stick to this repo ?

The main difference is we are building using ubuntu and with cgo for better compatibility.
We also had a custom way to parse timestamp but it seems we should not need it anymore and we could remove this.
You can see the diff with box master here https://github.com/box/kube-iptables-tailer/compare/master...honestica:master#diff-78f7c37ecdaf4773831b5287fac80afc497c70389318bfaf57aa5687ce0a3824R26

ahh, so I guess I did the same and used the Dockerfile-cgo, so its same, I will close this PR.
Thanks


More options to configure generate-script behavior

Default behavior should be to generate the minimum possible scripts - probably just the migrate-repo commands.
Then have optional arguments that can be passed to generate-script to add more functions to the generated script. E.g.:
--create-teams
--link-Idp-groups
--rewire-pipelines
--boards-integration
--lock-ado-repo
etc
This should involve the removal of the existing --repos-only flag
Possibly include a --all or something similar flag for customers that want to do all the things.

It looks like we need to have the following options:

[ ] --create-teams
[ ] --share-service-connections
[ ] --lock-ado-repos
[ ] --migrate-repos
[ ] --disable-ado-repos
[ ] --configure-autolinks
[ ] --add-teams-to-repos
[ ] --integrate-boards
[ ] --rewire-pipelines
[ ] --all

@dylan-smith I have two questions:

Do you agree with the option names?
Do we even need the --share-service-connections ? I am guessing that it is a pre-requisite for rewiring pipelines right?

That all looks pretty good I would make 3 changes

Get rid of --migrate-repos it should always do that
Get rid of --share-service-connection and include that logic in --rewire-pipeline
Get rid of --configure-autolink and include that logic in --integrate-boards


merge to live!

ugh, typo fix.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/design/content-add-ins.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


My final UI style changes

This is just the UI stylesheet changes that I used for the presentation -- so we most probably use it for our upcoming presentation as well.
@potatowagon Your thoughts?

Nevermind.


keyboard animation script added

Please look into changes

Please go through the documentation for guidelines to changing codes.

first, create an issue about what you want to change. Use given template for Issue and PR


Wrong behavior in type-narrowing with Callable

Environment data

Language Server version: 2021.11.0
OS and version: Window 7 x64
Python version (& distribution if applicable, e.g. Anaconda): 3.8.12 Anaconda

Sample code
from __future__ import annotations

from typing import Any, Callable, Protocol

if True:  # 0
    P = Callable[[], None]
else:
    class P(Protocol):
        def __call__(self) -> None: ...

class C1:
    def __call__(self) -> None: ...
class C2:
    def __call__(self) -> None: ...

def return_any() -> Any: ...

x: P = return_any()  # 1

if isinstance(x, C1):
    x  # 2
else:
    x  # 3
x  # 4

if isinstance(x, C2):
    x  # 5
else:
    x  # 6
x  # 7

Expected behavior
It doesn't matter whether the flag is set to True or False in line 0.

Type of x is inferred as P in line 1.
Type of x is inferred as C1 in line 2.
Type of x is inferred as P in line 3.
Type of x is inferred as P in line 4.
Type of x is inferred as C2 in line 5.
Type of x is inferred as P in line 6.
Type of x is inferred as P in line 7.

Actual behavior
When the flag is set to True in line 0:

Type of x is inferred as P in line 1.
Type of x is inferred as C1 in line 2.
❗ Type of x is inferred as Never in line 3.
❗ Type of x is inferred as C1 in line 4.
❗ Type of x is inferred as <subclass of C1 and C2> in line 5.
❗ Type of x is inferred as C1 in line 6.
❗ Type of x is inferred as <subclass of C1 and C2> | C1 in line 7.

When the flag is set to False in line 0:

Type of x is inferred as P in line 1.
Type of x is inferred as C1 in line 2.
Type of x is inferred as P in line 3.
❗ Type of x is inferred as C1 | P in line 4.
Type of x is inferred as C2 in line 5.
❗ Type of x is inferred as C1 | P in line 6.
❗ Type of x is inferred as C2 | C1 | P in line 7.

If we focus on the title, while ignoring the inconsistency between Callable and callable protocol, here is a simplified example:
from typing import Any

def return_any() -> Any: ...
x: object = return_any()  # Inferred: `object`

if isinstance(x, int):
    x  # Inferred: `int`
x  # Inferred: `int | object` instead of `object`

if isinstance(x, str):
    x  # Inferred: `str`
x  # Inferred: `str | int | object` instead of object

Sorry to have modified both the title and the content. I believe they can better illustrate this issue now.

When a callable protocol is used as the original type, the unexpected narrowed types are a bit ugly but still acceptable, and the behavior seems consistent with normal classes.
As for Callable, the problem could probably be that Pylance thought Callable[[], None] is equal to C1, which would explain the behavior in line 3.

Can you share what you're trying to do with this code pattern?
isinstance is not appropriate to use for callable types or protocols that don't support runtime checks. It's meant to be used for instances of classes that are part of class hierarchies.
The behaviors you're seeing are consistent with what I would expect given the somewhat nonsensical inputs. Mypy provides similar type narrowing behavior for this code, although there are minor differences that can be explained with known behavior differences between the two type checkers.

from __future__ import annotations

from math import inf, nan
from typing import Callable

Operator = Callable[..., float]

class Negate:
    def __call__(self, a: float, /) -> float:
        return -a

class Multiply:
    def __call__(self, a: float, b: float, /) -> float:
        return a + b

class Divide:
    __allows_zero_division: bool

    def __init__(self, allows_zero_division: bool = False) -> None:
        self.__allows_zero_division = allows_zero_division

    def __call__(self, a: float, b: float, /) -> float:
        try:
            return a / b
        except ZeroDivisionError:
            if self.__allows_zero_division:
                if a > 0:
                    return inf
                elif a < 0:
                    return -inf
                else:
                    return nan
            else:
                raise

class Calculation:
    operator: Operator  # Could be any operator declared here, or just a plain callable.
    operands: tuple[float | Calculation, ...]

    def __init__(self, operator: Operator, *operands: float | Calculation) -> None:
        self.operator = operator
        self.operands = operands

def standardize_calculation(origin: Calculation) -> Calculation:
    """
    Rebuild the calculation in a standard form, if possible.
    """

    operator = origin.operator
    operands = origin.operands

    if isinstance(operator, Multiply):
        return origin  # FIXME

    # Type of `operator` is inferred as `Never`.
    if isinstance(operator, Divide):
        (a, b) = operands
        (absolved, negative) = standardize_division(operator, a, b)
        if negative:
            return Calculation(Negate(), absolved)
        else:
            return absolved

    ...  # TODO

    return origin

def standardize_division(divide: Divide, a: float | Calculation, b: float | Calculation) -> tuple[Calculation, bool]:
    """
    Returns a standard division.

    Parameters
    ----------
    divide : Divide
        The Divide operator.

    a : float
    b : float
        The operands of this division.

    Returns
    -------
    calculation:
        A calculation with the identical Divide operator, and absolved operands.

    negative: bool
        Whether the result calculation needs to be negated.
    """

    ...

This roughly shows what I was doing. Though there is no warnings in the code, you can see that the inferred type becomes wrong after first isinstance check.

I don't think this approach will work because isinstance will always return False if you pass a function (a "plain callable") as the first argument. There's not enough implemented here for me to test it. Does it run?
Is your intent that Operator must be an instance of one of the defined operator classes? If so, then you should simply define Operator as a union of these classes.
Operator = Negate | Multiply | Divide

Then I think this will work, both at runtime and at type checking time.

I expect the operator in Calculation be either an instance of a known operator class or some arbitary function as long as it take some arguments and return a float. The standardize_calculation function will just return the input calculation if type of operator is not a known operator class.
To be clear, the point bugs me is that isinstance behave differently between a Callable and a callable protocol when they are mostly equal. If this behavior is intended, I will work around it.

Yes, the behavior is intended.
A callback protocol is similar to a Callable, but there are important differences between the two. A class can derive from a callback protocol, but it cannot derive from Callable.
This is valid:
class P(Protocol):
    def __call__(self) -> None: ...
class MyOperator(C1, P): ...

But this doesn't work:
P = Callable[[], None]
class MyOperator(C1, P): ...

Some protocol classes also implement runtime code that dynamically implements the isinstance logic to introspect an object and determine whether it implements the protocol. A Callable cannot do this.

I see. Thank you.


Discussion: Microsoft.AspNetCore.Razor refactoring and breaking changes

Microsoft.AspNetCore.Razor refactoring and breaking changes
This is the discussion thread for https://github.com/aspnet/Announcements/issues/227 - please post your questions and feedback here!
Summary
We're making some significant changes to the Microsoft.AspNetCore.Razor and Microsoft.AspNetCore.Razor.Runtime for ASP.NET Core 2.0.0 as part of the Razor re-engineering work we conducting. We've discussed the re-engineering work previously here but now we're ready to announce some of the breaking changes that will come from this effort.
Microsoft.AspNetCore.Razor will only contain the small set of types used for authoring Tag Helpers. This assembly will no longer contain the Razor Parser and Code Generator.
Microsoft.AspNetCore.Razor.Runtime will only contain the set of types used for authoring Tag Helpers. This assembly will no longer contain the infrastructure and types used to discover Tag Helpers.
Microsoft.AspNetCore.Razor.Evolution (a new assembly) will contain the Razor Parser and Code Generator. This name is not final and will change to something less whimsical before we release 2.0.0.
Impact
If you have written Tag Helpers against ASP.NET Core 1.0.0 there is a small chance that you will be affected by this change. It is our intent (within reason) that the 2.0.0 Microsoft.AspNetCore.Razor and
Microsoft.AspNetCore.Razor.Runtime assemblies will be binary-and-source-compatible with the API surface used to write Tag Helpers (mostly the Microsoft.AspNetCore.Razor.TagHelpers namespace). You should continue to reference the Microsoft.AspNetCore.Razor.Runtime package in your Tag Helpers - this will transitively pull in Microsoft.AspNetCore.Razor.
If you have written extensibility against Microsoft.AspNetCore.Razor or are re-hosting Razor for use in a templating engine, you should expect minor changes. You should reference Microsoft.AspNetCore.Razor.Evolution, where you will find all of the functionality that was removed from Microsoft.AspNetCore.Razor and Microsoft.AspNetCore.Razor.Runtime. APIs have changed, but you'll likely find conceptually-equivalent functionality in the new package. See the RazorPageGenerator for an example of using the new version of RazorTemplateEngine. Much of the extensibility surface is in flux here, so while you might want to take a look, you're better off sticking with 1.1.X until we're closer to release.
Rationale
We wrote a bit about this earlier here, and we perhaps now share a bit more.
We're doing a lot of work right now in Razor to improve the design and engineering of the Razor compiler and tooling. I want to emphasize that this release doesn't make language changes to Razor, and is entirely focused on improving the factoring, APIs, and fundamentals. In addition to the new Microsoft.AspNetCore.Razor.Evolution (real name pending) package, we're also builiding language services and runtime features that more closely leverage Roslyn. We're excited by the enthusiasm around Tag Helpers and we're making an investment in our future.
Part of this work is the factoring of the assemblies. We don't want the code generator and the APIs targeted by the code generator to be a single unit. We want to keep the set of dependencies for the compiler as thin as possible so it can easily live in tooling/VS. It also doesn't make much sense for libraries of tag helpers to reference the compiler. We also wanted to preserve as much compatibility for existing tag helper code. For anyone extending Razor or using the template engine, it's likely you'd be broken by our API changes in some small way, so moving to another assembly is small potatoes. This is how we settled on final split.
This is the discussion thread for https://github.com/aspnet/Announcements/issues/227 - please post your questions and feedback here!

RE: Microsoft.AspNetCore.Razor.Evolution
Why not call it what it is: Microsoft.AspNetCore.Razor.Parser

This is great news!!
Hope you get a better name than Evolution ;)

Feel free to make suggestions, ideally we'll have a new name picked out within a week or two.

Razor Core? :trollface:

Microsoft.AspNetCore.Razor.Engine?

Thank you for getting Razor some love 👍
I'd like to ask some questions about VS tooling:

will updated tooling be able to pickup our custom base types @inherits MyPage without adding extra hardcoded things that are web specific?
will it be possible to introduce custom keywords like @model MyModel and instruct VS tooling to handle them without writing VS extension / altering VS settings (so that it's project specific)?
will it be possible to introduce new file extensions (and maybe set default base class for them) and instruct VS tooling to handle them without writing VS extension / altering VS settings (so that it's project specific)?
will the tooling work from non-web projects (class library) without introducing web related dependencies?

will updated tooling be able to pickup our custom base types @inherits MyPage without adding extra hardcoded things that are web specific?

You'll have to clarify. Razor can always use your own base type, it just has specific requirements to be runnable/compilable.

will it be possible to introduce custom keywords like @model MyModel and instruct VS tooling to handle them without writing VS extension / altering VS settings (so that it's project specific)?

Definitely. This isn't currently possible in our Razor language service (it's preview after all) but it's high on our priority list to complete.

will it be possible to introduce new file extensions (and maybe set default base class for them) and instruct VS tooling to handle them without writing VS extension / altering VS settings (so that it's project specific)?

We don't currently have any plans to support this on the tooling front. We did an experiment and investigated what it would take to change Razors file extension; long story short, it's a massive amount of work.

will the tooling work from non-web projects (class library) without introducing web related dependencies?

Mostly yes. We currently have an issue here tracking using new Razor in class libraries. That issue is the first step to getting new Razor in class libraries. To address your question about introducing web related dependencies: If the base type that your Razor file is using requires it, then you will need to include those dependencies in order to avoid errors when editing your cshtml files.

Those are some great news, thank you 👍

You'll have to clarify. Razor can always use your own base type, it just has specific requirements to be runnable/compilable.

The tooling currently does pickup extra properties from custom base type, but it also inserts web/mvc related helpers like Html, Json, ModelExpressionProvider, however based on your answer to the second point I assume this won't be an issue with the new tooling.

@Kukkimonsuta those are automatically injected into every view. In the future we'll enable ways that you can modify these default inclusions; not supported yet but definitely on our radar 😄

getting "Could not load type 'Microsoft.AspNetCore.Razor.Evolution.TagHelperAttributeDescriptor' from assembly 'Microsoft.AspNetCore.Razor.Evolution, Version=<IP_ADDRESS>"
?

An update here, we've renamed Microsoft.AspNetCore.Razor.Evolution to Microsoft.AspNetCore.Razor.Language.


Troubleshooting

Hi. Thanks for your interest in getting isolarcloud on HomeKit.
I have installed your plugin on my Pi. And have edited the login details.
Do I have to do anything else? As I cannot get anything to show up in home.
Are there any other additional steps I need to do? I’m pretty new to homebridge.
many thanks.

Hi,
I've updated the plugin. Can you please try it again.
Cheers.
On Thu, Feb 25, 2021 at 8:50 AM EvoSems @.***> wrote:

Hi. Thanks for your interest in getting isolarcloud on HomeKit.
I have installed your plugin on my Pi. And have edited the login details.
Do I have to do anything else? As I cannot get anything to show up in home.
Are there any other additional steps I need to do? I’m pretty new to
homebridge.
many thanks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MortJC/homebridge-platform-isolarcloud/issues/2, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AN5E4TRRVWXKDJHDKOU4IYLTAVYEBANCNFSM4YFKAEKQ
.


Add preloading Github actions

What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[ ] Bug fix
[X] New feature
[ ] Other, please explain:
What changes did you make? (Give an overview)
Which issue (if any) does this pull request address?
Is there anything you'd like reviewers to focus on?

@nucleardreamer, this may be interesting to have a look at, it preloads some images and publishes them as releases on GitHub,


[WIP] Native push

@hamchapman could you review? I'm extremely not confident about my work here

Just rebased it so it's ready for me to review properly tomorrow. Might add some tests ;)

Closing in favour of #67 (more appropriate branch name that we can keep around 👍 )


Expose PCM_SOURCE_EXT_GETBITRATE to ReaScripts

6.18+dev1211's PCM_SOURCE_EXT_GETBITRATE is only implemented in a few types of PCM sources (mp3, ogg, opus). I've added a basic CBR implementation for WAV sources which works in older versions of REAPER.
Not sure if this is good enough for inclusion in SWS since many source types are not supported.

:white_check_mark: Build sws 507-master completed (commit https://github.com/reaper-oss/sws/commit/0965a43799 by @cfillion)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-expose-pcm-source-ext-getbitrate-0965a437.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-expose-pcm-source-ext-getbitrate-0965a437.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-expose-pcm-source-ext-getbitrate-0965a437.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-expose-pcm-source-ext-getbitrate-0965a437.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-expose-pcm-source-ext-getbitrate-0965a437.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-expose-pcm-source-ext-getbitrate-0965a437.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-expose-pcm-source-ext-getbitrate-0965a437.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-expose-pcm-source-ext-getbitrate-0965a437.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-expose-pcm-source-ext-getbitrate-0965a437.tar.xz

You're quick. :P
Hm..there's my PR #1219 open which serves basically the same.
Usually I'm always in favour of using native API where possible but in this case, the taglib variant supports more filetypes it seems:
https://taglib.org/api/classTagLib_1_1AudioProperties.html#ae5b7650b50f8c8f8cc022f25cfee48c5
Which one do you prefer? (no problem closing mine in case...)

As PCM_SOURCE_EXT_GETBITRATE stands right now in regards to format compatibility, I think your PR using TagLib is much better. It's also quite different as it reads from an arbitrary filename vs getting already loaded data from a PCM_source.
Another difference is in the return value: TagLib gives the bitrate in Kb rather than a decimal number of bits (eg. for the same file: TagLib gives 192 while PCM_SOURCE_EXT_GETBITRATE returns<PHONE_NUMBER>51).

EDIT: Perhaps a better approach would be to first try PCM_SOURCE_EXT_GETBITRATE and, if it failed (unsupported format or old REAPER), use TagLib's value * 1000?

I'm currently undecided about this but I'd suggest waiting for the next +dev if Cockos maybe also exposes it to ReaScript API so it's solved. :)

New +dev is out, no exposing to ReaScript (so far).
I thought about above again, so far I couldn't come up with any practical use case where bit exact bitrate would be more beneficial than kb/s (taglib style). I think most common use case is to find out if a mp3 is say 128 kb/s, 192 kb/s etc, and having this in kb/s rarther than b/s seems also the common expectation to me as that's how all audio players/DAW I know of (including Reaper in item properties and now also Media explorer) specify it.

It's also quite different as it reads from an arbitrary filename vs getting already loaded(?) data from a PCM_source.

There's https://www.extremraym.com/cloud/reascript-doc/#PCM_Source_CreateFromFile, so your way could also be used for arbitrary files (or otherwise, mine could also be rewritten to take a PCM_Source* and get the actual file name using GetMediaSourceFileName() , which would give the benefit of Reaper checking it's a valid PCM_Source* first).

Thought about this more, I think there's room for both functions (exposing REAPER's cached information + read from a file using TagLib).


RDKCOM-4626: RDKBDEV-2481: make references to WANMGR_CONFIG...

Reason for change:
make references to WANMGR_CONFIG_WAN_CURRENT_STATUS conditional on RBUS_BUILD_FLAG_ENABLE Prevent build failures if RBUS_BUILD_FLAG_ENABLE is not defined. Test Procedure: Sanity.
Risks: None.
Signed-off-by: Andre McCurdy<EMAIL_ADDRESS>Priority: P1
Change-Id: I8d7cc2c654e92dec5d3fbcf2563e7fd22ab794a5

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

Sanity tests for ['RPI4 GW BB Kirkstone'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/48573/


Implement new exceptions, change types raised

Related to #12 and #39.
In various places, the library raises exception types that don't seem entirely appropriate; for example, decoding an ID with a bad length raises an IOError, where something like a TypeError or ValueError would be more appropriate.
Also, for easier catching of ebmlite exceptions, a couple of custom exception subclasses would help (derived from an appropriate standard exception types). The custom types might also inherit from the types of exceptions currently raised for backwards compatibility, but that goes against the first point.
Either proposal might break some compatibility with existing code using ebmlite, however; it might require some minor refactoring, changing the exception types caught. The latter would be lower impact.

It looks like the non-apropos IOError exceptions are primarily in ebmlite.decoding.


Always downloading already included vendored dependencies every build

My actions before raising this issue

[x] Followed the troubleshooting guide
[x] Read/searched the docs
[x] Searched past issues

As of the 1.18 update, every time a function builds it downloads dependencies, even if they're already vendored. I cannot find a series of build args that work with this, as it appears to be related to workspaces being used.
Expected Behaviour

The build should not download vendored dependencies.
Current Behaviour

The build downloads vendored dependencies.
Possible Solution

I've tried a bunch of things, and honestly it seems like workspaces isn't really designed to work with vendored deps, but it's hard to say because the go CLI will yell at you for trying to use vendor mode on a workspace, but I don't see any docs from the go team about this behavior in their go modules reference documentation.
Steps to Reproduce (for bugs)

try to build an image that was working yesterday

Context

Slowing down builds.
Your Environment

FaaS-CLI version ( Full output from: faas-cli version ):
0.14.2
Docker version docker version (e.g. Docker 17.0.05 ):
latest
Are you using Docker Swarm or Kubernetes (FaaS-netes)?
k8s
Operating System and version (e.g. Linux, Windows, MacOS):
linux
Code example or link to GitHub repo or gist to reproduce problem:
no
Other diagnostic information / logs from troubleshooting guide

Next steps
You may join Slack for community support.

no headings were deleted, thanks derek.

I also notice the following error coming from builds now, as well:
#22 2.987 handler.go:13:2: ambiguous import: found package github.com/openfaas/templates-sdk/go-http in multiple modules:
#22 2.987 	github.com/openfaas/templates-sdk v0.0.0-20200723110415-a699ec277c12<EMAIL_ADDRESS>#22 2.987 	github.com/openfaas/templates-sdk/go-http v0.0.0-20220408082716-5981c545cb03<EMAIL_ADDRESS>------
Error: failed to solve: process "/bin/sh -c GOOS=${TARGETOS} GOARCH=${TARGETARCH} go test ./... -cover" did not complete successfully: exit code: 1

@LucasRoesler PTAL?

@kevin-lindsay-1 can you provide a sample project please, as simple as you like in a public GitHub repo

Can I confirm that you're enabling GO111MODULE, have external dependencies in go.mod and also have a vendor folder at the same time?

To make sure I'm reading the docs correctly, doesn't GO111MODULE: off effectively disable the perks of modern modules?
If you leave it set to on, and set the mod=vendor flag, the CLI explicitly yells at you that vendoring isn't supported for workspaces.

@alexellis

Do you mean that it won't build today, at all, it's "not working"? Or that it downloads vendor dependencies upon each build, but is "working"?
Vendoring isn't working. For the sake of this conversation, let's assume that any other errors were in the troubleshooting process, and can safely ignore them in the context of this conversation.

Can I confirm that you're enabling GO111MODULE, have external dependencies in go.mod and also have a vendor folder at the same time?
Yes, yes, and yes.

What does adding build_args for GO111MODULE=on plus -mod=vendor do?
Leaving go111module on and turning vendor on produces an error message from go, stating that if you'd like to use vendoring you should disable workspaces.

To make sure I'm reading the docs correctly, doesn't GO111MODULE: off effectively disable the perks of modern modules?
If you leave it set to on, and set the mod=vendor flag, the CLI explicitly yells at you that vendoring isn't supported for workspaces, and that if you'd like to use it, to turn off workspaces. If that's the case, why use workspaces at all for this build?

When you use vendoring, which perks are you using at build time? Please be specific.
I am not aware of anything different about the build with vendor if you have modules on or off.
The main benefits from modules come from the fact that pulling happens automatically during builds, the minimal version selection algorithm used when constructing the dependency tree, and not needing GOPATH.
But when you have a vendor folder you explicitly do not want modules downloaded. And the template is already designed so that the code is in the GOPATH.
All the benefits of modules are already achieved pre-build when the vendor folder is used with this template.

I am not aware of anything different about the build with vendor if you have modules on or off.

That's a good point.
I would like to at least address though, that regardless of technical ramifications (or lackthereof), design intent goes a long way here. A user might not understand why you'd opt-in to workspaces only to have them opt-out for the sake of performance, on a build no less. A Go maintainer might ask a similar question, and might even argue that opting in just to opt-out is an edge case enough to not merit support, as they might simply say you shouldn't have used workspaces if you don't intend to "use" them.
I hope that Go manages to make workspaces and vendoring compatible in future, but if that's not a design goal, then it seems like vendoring is of higher value to OF users. To the user, the fact that their function is part of a workspace at build time is effectively hidden from them. Regardless of whether or not it's a workspace, they just expect it to work, and they most likely expect build performance to be of higher priority than the build detail of the relationship between the Handler and the Function.

@alexellis and @kevin-lindsay-1 I have created a new patch to make the handling of the vendor args automatic. Please take a look at https://github.com/openfaas/golang-http-template/pull/74
You can also see an example in my test repo, along with instructions of how you can also test it https://github.com/LucasRoesler/golang-http-template-examples
rm -r template/
faas-cli template pull https://github.com/LucasRoesler/golang-http-template#feat-automatic-vendor-detection
faas-cli build

I think that solution makes sense, given the nature of this template as a development tool, rather than a static project.

@alexellis just a quick bump, there is a PR ready that imlements this https://github.com/openfaas/golang-http-template/pull/74
I think this really improves the DX for the template because it reduces the amount of docs and configuration that a  developer needs to use.

I've commented on the PR thanks.

To recap from the community call, we have two prescriptive configurations for two separate use-cases:

Go modules, with no use of vendoring or private modules - use as per normal with GO111MODULE=on
Vendoring for the purposes of caching lots of dependencies or for private Go code - use with GO111MODULE=off and GOFLAGS=-mod=vendor

1 is the usual expected case, which means Go workspaces can be used with highlighting and VSCode integration.
2 is the special case and you need to run VSCode from within the function's handler folder to make things work like intellisense and click to jump to definition.
AFAIK subpackages (i.e. a handlers folder for a function) work for both scenarios, but do they need different configuration - or the same code would work for either?
For 2), do we also need to change GOPATH?

Let's clear one thing up, workspaces have at least two distinct use-cases that can even overlap

you have a folder with multiple modules, e.g. I have openfaas/faas-netes and openfaas/of-watchdog. I can use a workspace so that I can open openfaas/ in my IDE/editor and code completion and linting will work as expected for each module. Without a workspace definition, you need to open each folder individually.
you have a monorepo composed of multiple go modules. In this case, the workspace can be used to simplify dependency management if the modules need to reference each other in some way or if you have a core module with any shared utilities abstracted out.

The most recent change to the template is attempting to use workspaces as in the second case above, treating the function main.go and the handler implementation as two modules living in the same project.
With regard to the template use-cases that you mention @alexellis

(default) simple module usage where modules are downloaded at build time. This specifically works with workspaces
(vendor) where a user has decided to copy the required dependency modules via go mod vendor to the <function>/vendor/ folder. This can have at least 3 specific personas/use-cases:
a. user was to ensure 100% reproducible builds and ensure that the dependency code that they require always exist
b. user has many or large dependencies and wants to use the vendor as a cache for these dependencies
c. user wants to use a private module. The faas-cli and the template does not allow passing git credentials to the builder, so any private module will produce an not found or auth error during build

Currently, the first case (default) works without any configuration.
The second case requires changing the configuration, the only change is disabling modules via GO111MODULE=off. This is the only required change because we copy the function code into the GOPATH already. This is exactly what my PR #74 does.
Leaving this to a just a user config can lead to unexpected behavior for use-cases 2a. and 2b.  In these cases, if the user does not manually set GO111MODULE=off the build will still work, all of the modules can be found.  However, the build is not using the code that the user intends for it to use, because modules are still on and workspaces ignores the vendor folder, it will result in the dependencies to be downloaded on the fly but it will not fail. A user must very carefully read all of the build logs to check if there were module downloads or not.
Only case 2c. will produce a build error, because of the auth error.
This is why I implemented #74 to automatically detect the vendor folder and to disable the module mode. it is very easy to miss that the build is not actually working they way the user intended when they created the vendor folder.
If we want to split the templates so that there is one for "normal module user" and one for "vendor user" we can do this but then we should probably still create a script for the template to detect and warn the user that it sees a vendor folder that might be ignored during the build or go even further and fail the build if it sees a vendor folder and direct the user to change their template.

Where are we at with this?
The golang template builds have been going slow as a result to this unintentional behavior introduced from 1.17 to 1.18, and it's still not fixed, and seems like there's no action items to actually do anything about it.
I'm considering not using OF public store templates at this rate, because opinions are great and all, but this made all builds about 5x slower for me.

The context of this comment is a bit surprising given that we covered this exact topic on the community call with you present only yesterday, a few hours ago.
That - and a patch was made specifically made for your use-case with Istio to the OpenFaaS gateway, delivered yesterday.
So the tone feels a bit off.
That said.
What is the specific change that made the builds 5x slower? Is it that the vendor directory isn't being honoured, and Go modules is downloading all of the dependencies each time you use it?
I am reticent to introduce bash and if statements into the Dockerfile, and would like to know if @MrWormHole's suggestion is viable as an alternative.

Kevin,
Does the following from a much earlier comment in your stack.yml work as desired?
   build_args:
      GO111MODULE: off
      GOFLAGS: "-mod=vendor"

@alexellis

Disabling workspaces produces a (docker) build failure, because the go.mod and go.sum need to be updated with workspaces disabled.

Here is my docker build for my sleep function:
STEP 1/3 — Building Custom Build: [sleep]
#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 1.77kB 0.0s done
#1 DONE 0.0s

#2 [internal] load .dockerignore
#2 transferring context: 479B 0.0s done
#2 DONE 0.0s

#3 [internal] load metadata for docker.io/library/alpine:3.15
#3 ...

#4 [internal] load metadata for ghcr.io/openfaas/of-watchdog:0.9.6
#4 DONE 0.2s

#5 [internal] load metadata for docker.io/library/golang:1.18-alpine3.15
#5 ...

#3 [internal] load metadata for docker.io/library/alpine:3.15
#3 DONE 0.9s

#5 [internal] load metadata for docker.io/library/golang:1.18-alpine3.15
#5 DONE 1.2s

#12 [watchdog 1/1] FROM ghcr.io/openfaas/of-watchdog:0.9.6@sha256:143834fdd151d9118fc8f0d89482179b4f84fb3b47926ae73d90db2121ae2bab
#12 resolve ghcr.io/openfaas/of-watchdog:0.9.6@sha256:143834fdd151d9118fc8f0d89482179b4f84fb3b47926ae73d90db2121ae2bab 0.0s done
#12 DONE 0.1s

#10 [build  1/13] FROM docker.io/library/golang:1.18-alpine3.15@sha256:f9181168749690bddb6751b004e976bf5d427425e0cfb50522e92c06f761def7
#10 resolve docker.io/library/golang:1.18-alpine3.15@sha256:f9181168749690bddb6751b004e976bf5d427425e0cfb50522e92c06f761def7 0.1s done
#10 DONE 0.1s

#6 [stage-2 1/7] FROM docker.io/library/alpine:3.15@sha256:4edbd2beb5f78b1014028f4fbb99f3237d9561100b6881aabbf5acce2c4f9454
#6 resolve docker.io/library/alpine:3.15@sha256:4edbd2beb5f78b1014028f4fbb99f3237d9561100b6881aabbf5acce2c4f9454 0.0s done
#6 DONE 0.1s

#17 [internal] load build context
#17 transferring context: 15.54MB 2.3s done
#17 DONE 2.3s

#11 [build  2/13] RUN apk --no-cache add git
#11 CACHED

#13 [build  3/13] COPY --from=watchdog /fwatchdog /usr/bin/fwatchdog
#13 CACHED

#14 [build  4/13] RUN chmod +x /usr/bin/fwatchdog
#14 CACHED

#15 [build  5/13] RUN mkdir -p /go/src/handler
#15 CACHED

#16 [build  6/13] WORKDIR /go/src/handler
#16 CACHED

#18 [build  7/13] COPY . .
#18 DONE 0.6s

#19 [build  8/13] RUN test -z "$(gofmt -l $(find . -type f -name '*.go' -not -path "./vendor/*" -not -path "./function/vendor/*"))" || { echo "Run "gofmt -s -w" on your Golang code"; exit 1; }
#19 DONE 0.3s

#20 [build  9/13] WORKDIR /go/src/handler/function
#20 DONE 0.0s

#21 [build 10/13] RUN mkdir -p /go/src/handler/function/static
#21 DONE 0.2s

#22 [build 11/13] RUN GOOS=linux GOARCH=amd64 go test ./... -cover
#22 23.83 ?   	handler/function	[no test files]
#22 23.83 ?   	handler/function/internal/common	[no test files]
#22 23.83 ?   	handler/function/internal/common/environment	[no test files]
#22 23.83 ?   	handler/function/internal/common/logger	[no test files]
#22 23.83 ?   	handler/function/internal/common/model	[no test files]
#22 23.83 ?   	handler/function/internal/common/profiler	[no test files]
#22 23.83 ?   	handler/function/internal/common/tracer	[no test files]
#22 23.83 ?   	handler/function/internal/common/validator	[no test files]
#22 23.83 ?   	handler/function/internal/environment	[no test files]
#22 DONE 24.3s

#23 [build 12/13] WORKDIR /go/src/handler
#23 DONE 0.1s

#24 [build 13/13] RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64     go build --ldflags "-s -w" -a -installsuffix cgo -o handler .
#24 0.520 main.go:18:2: cannot find package "github.com/openfaas/templates-sdk/go-http" in any of:
#24 0.520 	/usr/local/go/src/github.com/openfaas/templates-sdk/go-http (from $GOROOT)
#24 0.520 	/go/src/github.com/openfaas/templates-sdk/go-http (from $GOPATH)
#24 ERROR: process "/bin/sh -c CGO_ENABLED=${CGO_ENABLED} GOOS=${TARGETOS} GOARCH=${TARGETARCH}     go build --ldflags \"-s -w\" -a -installsuffix cgo -o handler ." did not complete successfully: exit code: 1
------
 > [build 13/13] RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64     go build --ldflags "-s -w" -a -installsuffix cgo -o handler .:
#24 0.520 main.go:18:2: cannot find package "github.com/openfaas/templates-sdk/go-http" in any of:
#24 0.520 	/usr/local/go/src/github.com/openfaas/templates-sdk/go-http (from $GOROOT)
#24 0.520 	/go/src/github.com/openfaas/templates-sdk/go-http (from $GOPATH)
------
Error: failed to solve: process "/bin/sh -c CGO_ENABLED=${CGO_ENABLED} GOOS=${TARGETOS} GOARCH=${TARGETARCH}     go build --ldflags \"-s -w\" -a -installsuffix cgo -o handler ." did not complete successfully: exit code: 1

I asked you for this on https://github.com/openfaas/golang-http-template/issues/73#issuecomment-1098760914 and haven't seen an example yet.

No, what you asked for was proof that it was downloading modules, which Lucas corroborated.

The context of this comment is a bit surprising given that we covered this exact topic on the community call with you present only yesterday, a few hours ago.

I don't recall anybody asking me anything about this issue. A number of people are given the floor during the community call, I don't always hear everything everyone says around me.

That - and a patch was made specifically made for your use-case with Istio to the OpenFaaS gateway, delivered yesterday.

I resent the implication you're making here that you think waiting 4 months to have an issue fixed is being needy.

So the tone feels a bit off.

Check yourself before you try checking me.

What is the specific change that made the builds 5x slower? Is it that the vendor directory isn't being honoured, and Go modules is downloading all of the dependencies each time you use it?

I don't think you know what's going on in this issue.

I don't think you know what's going on in this issue.

Then can you please clearly explain what you think it is, or raise another issue?
My understanding from the open PR is that the vendor folder is being ignored, and modules are downloading vendored dependencies. This increase build time.
Are we on the same page here or not?

Here is my docker build for my sleep function

Where is the source code for your "sleep" example?

I resent the implication you're making here that you think waiting 4 months to have an issue fixed is being needy.

Unless I'm missing something, there is no issue needing to be fixed, only the offer of some magic bash to give users two less lines to add to their stack.yml file when using vendoring.
The original issue was addressed on 14th April here: https://github.com/openfaas/golang-http-template/issues/73#issuecomment-1099309266 - I had the same problem myself, and adding these two build args causes Go modules to be turned off, and and vendoring to work. I made the change and moved on.
  jules:
    lang: golang-middleware
    handler: ./jules
    image: jules:latest
    build_args:
      GO111MODULE: off
      GOFLAGS: "-mod=vendor"

If your code sample in "sleep" doesn't work with the above, then it definitely won't work if #74 is merged, because all it does is use bash to infer the two above settings.
What am I missing?


Generations using the same seed and parameters in LTXV I2V are not fully deterministic

Expected Behavior
Videos generated using the same seed and parameters should be identical.
Actual Behavior
Discrepancies are found between repeated generations using the same seed and parameters. This issue is present when using either 0.9 or 0.9.1.
Seed 1 (eg. moon at the top-right is skewed differently)
https://github.com/user-attachments/assets/d96887a2-9e19-496d-a364-64a974e9d02e
https://github.com/user-attachments/assets/a12c900c-0a87-4fc2-8008-e1602ffdb580
Seed 10 (eg. moon at the top-right goes missing at the end in the first video, but does not in the second):
https://github.com/user-attachments/assets/dfeb14ec-90b4-4040-b6f2-0e1857331e20
https://github.com/user-attachments/assets/3657db02-806c-484c-bc8d-9a8f1824b9f8
Steps to Reproduce
Prerequisites:

LTXV v0.9 or v0.9.1 loaded and working from Hugging Face. This example will use v0.9.1.

Setup:

Use the image from here: https://en.wikipedia.org/wiki/The_Starry_Night#/media/File:Van_Gogh_-Starry_Night-_Google_Art_Project.jpg
Download and import this preset: starry_night.json
Drag-and-drop the image to Generate's main window and Use As Init.
Check that Core Parameters > Seed is 1, then hit Generate.
Change Seed to another value, 10 in this example, then hit Generate.
Change Seed back to 1, then hit Generate.
Change Seed back to 10, then hit Generate.
Compare the video results.

Debug Logs
https://paste.denizenscript.com/View/129308
Other
This issue does not seem to be present when using the model's T2V features.

I just did a test using LTXV's example workflow from here. Modified it to use my own captioning:
LTXVideo.json
(image example: https://www.aspca.org/sites/default/files/cat-care_general-cat-care_body1-left.jpg)
When I change the RandomNoise noise_seed from one value to another and back, I get identical results as expected. This was done using the same Comfy backend that Swarm was using in this issue.

I'd guess this is microvariation chaos (the butterfly effect) -- ie, a very very tiny change is happening unintentionally somewhere, and across the billions of calculations producing an entire video out it, that difference expands into something visible. This happens all the time, even in regular image generation, it's just usually the final result is a slight color shift in a few pixels, not enough to matter.
The reason this would happen more in Swarm's interface than in a comfy workflow, is there's a few extra steps happen.
To see the dirty details, set up your gen, then click the Comfy tab, and click Import from Generate Tab

(A) Swarm does its own scaling of the input image. Your source is 2560x2027, and it needs to be shrunk to the appropriate resolution. This should be consistent, but I wouldn't be surprised if a there was a 0.01 color difference on a pixel or two. This doesn't get cached currently.
(C) Because of the dirty trick of the Init Image with Creativity 0, it's not actually directly fed to the video model, it hits a sampler of the base model first. This, luckily, actually does nothing, but:
(B) it does go through a VAE Encode + Decode despite the lack of any actual processing. This is something I want to change because it's dumb, it's just a temporarily limitation.
Pending that getting fixed, you might reduce the differences by just changing the base model selection, some VAEs are more stable than others. Flux is high detail but has color space shifting. SDXL is very stable with weakened detail reproduction.
(Or, of course, also a valid option: as long as the differences are very small and only visible in chaos swirls, ignore it, cause if you want such perfect control you shouldn't be using AI lol. Add a single random character to the prompt and you'll get a bigger change than this).
You might also consider the models in use. Notably Swarm by default uses a T5XXL model in fp8 format, which is a tiny bit less stable than an fp16 copy of T5. There's a parameter under Advanced to switch the preferred T5 model.
If you tested comfy by launching it separately, you might also want to test it inside the comfy tab on Swarm. Swarm by default adds a few launch args, notably including --fast which tells Comfy to use faster (but slightly less stable) fp8 multiplications when it can.
There is a server config option to disable that if it's the cause of the differences:

@mcmonkey4eva Ok, I did more testing according to what you suggested, just shy of disabling --fast (which would unnecessarily increase generation times). From what I could tell, it turns out that image_noise_scale from Comfy's LTXVImgToVideo is the most likely culprit for the deviation (which just so happens to be unused by Lightrick's workflow).
Referring to this pack of sample outputs:
LTXVSwarm_NoiseIssue.zip
(Note: MPC throws some "encountered an improper argument" error, probably because of how I'm just casually swapping in the Video Combine node as-is. You'll need to use some other player like VLC or XnView.)

Default is Swarm's default workflow (minus the Video Combine at the end). (2) is a rerun of (1)'s exact workflow.
BaseNoiseOff is Default plus setting image_noise_scale from Comfy's LTXImgToVideo to 0.0. Additionally, for the sake of ruling out, add_noise from (C) is set to false for (1) and (2), but reverted to true for (3).
(A) is not considered here as it did not affect the test in any meaningful way whatsoever. The picture from https://www.aspca.org/sites/default/files/cat-care_general-cat-care_body1-left.jpg is used as-is.

As you can see, for Default, for seed 84, the cat turns its head far more towards the left of the image for (2) vs (1). And for 86, it's far worse - almost no movement on (2) vs (1). This is definitely way more than "very small" differences.
In contrast, when I set image_noise_scale to 0.0, I get consistent results for both seeds (still with a different result per seed), down to the byte in file size.
I believe it has something to do with this line, based on how image_noise_scale is being passed around. But I can't figure out exactly what's causing the randomness in the randn call, be it a random seed, time-based, or other:
https://github.com/comfyanonymous/ComfyUI/blob/99a1fb6027b7163592a83669b0b1c5aa4657c2b6/comfy/ldm/lightricks/model.py#L447
On that note, I wonder if image_noise_scale can be exposed to the UI as an advanced setting. Otherwise, maybe the value should default to 0.0 instead so the model's behavior is more in line, as least in terms of predictability, with Lightrick's workflow.

oh, Swarm's generate tab has that filed under the Video Augmentation Level param, I defaulted it to 0.15 in LTX-V because that's the LTX-V default image_noise_scale value.
You should probably report on the comfy github that its not seeded properly. Which... yeah, it seems to be written in such a way that it initializes from random static seed 42 and then changes each time you call it? Which... what? That's really weird.


use vmImage pool ubuntu-20.04

hi
i want to use new feature vmImage ubuntu-20.04 in azure devops server . how can i use???

Hello, since you use Azure DevOps Server, you don't have access to Microsoft-hosted agents. ubuntu-20.04 is Microsoft-Hosted pool and it is available only in Azure DevOps services.
On Azure DevOps Server, you have to generate your own agents and host it. More details can be found in guide: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops-2020&tabs=browser
I am closing this issue for now since this repository is intended only for Hosted images since we don't have much experience with Azure DevOps Server and self-hosted agents


Consistent Rule Sorting

ToDo

[x] rehydrate sorting
[x] correct rendering/sorting in devMode
[ ] updating docs

[ ] performance differences in devMode
[ ] devMode configuration
[ ] rehydrate vs. render

[ ] performance improvements for rule-score=0 rules
[ ] remove fela-plugin-lvha after merge

Description
This PR adds support for consistent sorted rules (especially pseudo classes). It also deprecates fela-plugin-lvha as this changes makes the plugin obsolete.
Example
const rule1 = () => ({
  ':hover': {color: 'red' },
  ':active':  { color: '#fff' },
})

const rule2 = () => ({
  ':hover':  { color: '#000' },
  ':active': {color: '#fff' },
})

will now render to:
.a:hover { color:red }
.c:hover { color:#000 }
.b:active { color:#fff }
.d:active { color:#fff }

instead of:
.a:hover { color:red }
.b:active { color:#fff }
.c:hover { color:#000 }
.d:active { color:#fff }

Versioning

Major

fela
fela-dom
fela-utils

Minor
Patch

fela-plugin-lvha

Checklist
Quality Assurance

You can also run yarn run check to run all 4 commands at once.

[x] The code was formatted using Prettier (yarn run format)
[ ] The code has no linting errors (yarn run lint)
[ ] All tests are passing (yarn run test)
[ ] There are no flow-type errors (yarn run flow)

Changes
If one of the following checks doesn't make sense due to the type of PR, just check them.

[ ] Tests have been added/updated
[ ] Documentation has been added/updated
[ ] My changes have proper flow-types

@TxHawks Man, this was a hard one to finish :D Will update some tests and docs later, then I'd love to get a review here.


= on slide 15 of stats lecture

Weird, it looks okay here
https://github.com/jhudsl/intro_to_r/blob/809f65d6c49f96e03e929f39501b04c0cd2c3b7b/modules/Statistics/Statistics.Rmd#L166
Make sure this is rendering ok

need to add summary before lab 1
show na values with t.test
typo about ttest hypothesis for two sample

get rid of backticks (`) in the lab and just say the word backticks

why are the other values different:
mort <- read_mortality()
mort <- mort %>%
rename(country = ...1)
mort_sub <-
mort %>%
select(1980, 1990, 2000, 2010)
cor(mort_sub)
cor(mort_sub, use = "complete.obs")

want a different linear spurious correlation example

this resource actually looks pretty good https://www.statology.org/null-residual-deviance/ - might want to add to resource page but idk

typo in summary for cor.test making it code

maybe add interaction * to description of regression in R

the lab question with interaction needs the individual terms too in the key - also someone was confused by the backticks in the description and thought the interaction needed that - adding this to the lecture should fix that hopefully

and link = logit to lab key and lab

add that you don't need quotes for variable names and interactions in the quotes vs backticks page

[ ] show how to view all intercepts (including comparison group) glm(y ~ x - 1)


Issue a Production build

To issue a production build, you can set the msbuild configuration to Release.  For example:
msbuild /p:configuration=Release

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

ID: 4e0d7d11-7d9d-0da4-f636-b74b1888f785
Version Independent ID: ad58f888-55d3-45b9-838d-5c3d563824d8
Content: Updating PowerApps CLI - PowerApps
Content Source: powerapps-docs/developer/component-framework/updating-tooling.md
Service: powerapps
GitHub Login: @Nkrb
Microsoft Alias: nabuthuk

@iwaldman Thanks for the feedback. We have updated the docs and published to live. Closing the issue.