Graphic tasks

Since there's so much interest on having a high level GUI running locally on NodeOS I will list here the tasks that need to be done to make this feasable:

[ ] Add EGL support to NodeOS

[ ] Compile libMesa without any dependency on X11

[ ] HTML renderer

[ ] Gecko running on framebuffer (DRI)
[ ] Gecko running on EGL
[ ] Webkit running on framebuffer (DRI)
[ ] WebKit running on EGL
[ ] Static build of Webkit Context_Renderer

[ ] Add support to use full screen resolution, not default 800x600
[ ] Update resolution on framebuffer resize (Is that possible?)

[ ] Add WebGL support to node-canvas (OpenGL ES 2.0)

Anything more?

Yes the frame buffer size can be updated. I've done so much research I can quote code from the kernel XD
This looks like an about complete list to get started. Would you like me to make a fork for us to work on instead of throwing things at the main thread? I do remember you suggesting that the graphic edition be separated from the server edition?

I've done so much research I can quote code from the kernel XD

Ah, that's good :-P

Would you like me to make a fork for us to work on instead of throwing things at the main thread?

I think this things can be worked and tested on regular Linux systems, so I would work on them as independent projects and later see how to integrate them (maybe also published as npm packages... :-P)

Could you add "/gecko" where you put webkit ? ^^

Could you add "/gecko" where you put webkit ? ^^

Done ;-)

I think this things can be worked and tested on regular Linux systems, so I would work on them as independent projects and later see how to integrate them (maybe also published as npm packages... :-P)

Yeah this was my intention. Fourth npm module, here I come!
(Does anyone else realize how our efforts for this project are pushing other things along in other projects at the same time?)

Does anyone else realize how our efforts for this project are pushing other things along in other projects at the same time?

That's just one of the thing I mostly love of Node.js and npm and why I'm trying to make NodeOS elements as standard and reusable on other systems as possible :-D

That's just one of the thing I mostly love of Node.js and npm and why I'm trying to make NodeOS elements as standard and reusable on other systems as possible :-D

NodeOS = cure to lyfe

A thought about graphics integration: Something that I am reminded of for this project is my old Apple //e (as I mentioned in another thread), which had graphics but also supported 4 lines of text at the bottom of the screen, which could be turned on or off. We could perhaps take similar inspiration at least in the development stages of NodeOS, where most of the screen is a graphical environment but several lines of text are found at the bottom where the command-line user still interacts as they did before. The advantage to this would be that we don't have to implement both graphics and hitbox input at the same time.

@compynerd255

most of the screen is a graphical environment but several lines of text are found at the bottom where the command-line user still interacts as they did before.

I actually really like your suggestion. NodeOS doesn't have a default window manager as graphics aren't a part of the core operating system.
Because of this, each window manager would have to implement it on their own. now, I can forsee a lot of managers being built of a rendering engine u've been developing (and now testing :D) called Yunitto, and I will attempt to bake this feature into it as a configurable addition making it easier for wm developers to integrate.
Awesome suggestion!

@lite20 I'm glad that you like it. Of course, I'm not sure how useful this feature would be for general public use - it might be easier on us if we just wrote in a mouse. I can certainly see this feature being useful for development, though - the text, which could also be on the top or the side of the screen, could be used as a debugging log / interaction window. It could even be used as a simple HUD. I'll post these ideas in more detail on your Yunitto repository.

I'll post these ideas in more detail on your Yunitto repository.

Yes thank you! This way I can ensure it's executed and properly developed.

Of course, I'm not sure how useful this feature would be for general public use - it might be easier on us if we just wrote in a mouse.

For general purpose users, yes this is probably  a weird window they may not be a fan of, but it could be incredibly useful to developers, and if we made the source swappable, any app could tap in and use it.

Isn't this similar to the browser dev console? Also, this could be easily done with blessed or a div, I don't think it's needed to have it at the graphic layer but the application one...

Isn't this similar to the browser dev console?

True. This however isn't accessible on mobile devices unfortunately.

Isn't this similar to the browser dev console? Also, this could be easily done with blessed or a div, I don't think it's needed to have it at the graphic layer but the application one...

Hm. Good point. What I was thinking was just making a module and apps could use it as they pleased.

Isn't this similar to the browser dev console?

Similar, but not the same - a pure text window offers the following features that a dev console does not:

The text window can display whatever it wants, and can even move the cursor around and overwrite itself.
The text window can be interacted with by normal TTY interaction.
Any type of input (not just context sensitive input) can be requested from the text window. (This is probably the most important feature).

One (game) application I could see of this would be an audio-visual version of Zork or another text adventure game: it is played using the text prompt, exactly as the original, but most of the screen is occupied with a visual retelling.
This could also be very useful in other applications if the background could be transparent.

One (game) application I could see of this would be an audio-visual version of Zork or another text adventure game: it is played using the text prompt, exactly as the original, but most of the screen is occupied with a visual retelling.

This could also be very useful in other applications if the background could be transparent.

With all these customizations this might be a reasonably sized module. I like it!

Just a side note too graphic developers, don't forget about this burried thread:
https://github.com/NodeOS/NodeOS/issues/147

Just a side note too graphic developers, don't forget about this burried thread:
#147

Thanks for remind it, definitely GitHub needs some mechanism to pin some issues on the top, since we are using it somewhat as a forum. Please make them all of you a suggestion about that to give some pressure :-) By the moment, I've created a new label so we can "pin" some important issues there :-)

Say we want the location of wallpapers to be standard across window managers. Does NodeOS have a location where files and data that are to be shared should be?
We could use voidpool to keep a map of all the files to their respective locations so that shared things like the path to the desktop wallpaper could be fetched with pool.get('wallpaper')

Say we want the location of wallpapers to be standard across window managers. Does NodeOS have a location where files and data that are to be shared should be?

I didn't consider this use case... Since each windows manager is considered a standalone project it would have its own wallpapers as resources of itself. To have a common location, I only can think about store them on an independent module that all window managers would have as dependency, or have some mechanism like XDG user directories to be able to define some common folders.
Take also in account that the windows manager will run client side and it's independent of the NodeOS backend server, so also it could be a Chrome apps connecting to a remote NodeOS server and have embedded the wallpapers. If you want to have some wallpapers in common, I only can think about a $HOME/Images/wallpapers folder or something similar, but user would need to put them there manually. I think windows manager could only be able to show by default the wallpapers that has embedded inside their own module or any of its dependencies, but it's not possible to install them outside itself without a postinstall script, and this could be dangerous because it would overwrite previous ones.

Ah okay. The reason I mentioned was because the user might have an app to change the wallpaper. If the wallpaper was in a different location for each window manager, the app would have to have several implementations.

I only can think about a $HOME/Images/wallpapers folder or something similar

The reason I suggested using Voidspace is so the path could be changed. Yes the user would have to put it there manually but apps could check and if it existed, use it. Else a default of course.
By $HOME are you referring to the users home directory? Just making sure

I have an idea!
If anyone has ever created an Electron.js app (I have) they're in the same situation as the apps we build. Electron apps have a "server" layer which operates on the NodeJs thread, and a "browser" layer, which is CEF.
NodeOS all's are basically in the same situation but with a gap potentially between the browser and  server.
To work with this in electron, they introduced a module called "remote". Remote allowed the browser thread to " require" modules on the server side. The server side would do all the execution and return results to the browser thread.
I'm going to look a bit into their code to see how they did it but maybe we could use a similar "remote" module that allowed users to perform operations in the server side and get the results. (RPC, but with more hype :) )

The reason I mentioned was because the user might have an app to change the wallpaper. If the wallpaper was in a different location for each window manager, the app would have to have several implementations.

Shouldn't this be a config option of the Desktop Manager?

The reason I suggested using Voidspace is so the path could be changed. Yes the user would have to put it there manually but apps could check and if it existed, use it. Else a default of course.

Do you have a link to Voidspace? I can't be able to find it anywhere...

By $HOME are you referring to the users home directory? Just making sure

Yes, that's it.

Shouldn't this be a config option of the Desktop Manager?

Maybe, we've never discussed this before, so it hasn't been standardized. If it would be, we ought to decide how apps would access it.
If all apps stored their public variables in one location or via one system, fetching something like the desktop wallpaper path. Voidspace could probably do this too.

Do you have a link to Voidspace? I can't be able to find it anywhere...

It's out on NPM and its repository is on bitbucket.
Npm: https://www.npmjs.com/package/voidspace
Repo: https://bitbucket.org/Lite20/voidspace
The status says beta but the latest version is actually a stable release. I just haven't updated the text :P
Voidspace works on all platforms, including the web.

Why not make the NodeOS server more independent from the GUI client? I'd like to use NodeOS without any GUI. Also, i'd imagine window managers / desktop environments without anything like wallpapers at all. So please don't narrow the architecture down on the usual mainstream-like GUIs.
That's also the reason why I think that the NodeOS server should know nothing about the GUI client.

@derhuerst, I absolutely agree with you, this things should be only client-side. There would be some support modules used by the backend server of the windows managers to have some common features, but definitely this functionality should not be on the NodeOS core. A wallpaper is usually a simple image, and that could be stored on the user browser localStorage as a data: URI.

Why not let the window manager / GUI serve itself?

A wallpaper is usually a simple image, and that could be stored on the user browser localStorage as a data: URI.

AFAIK, browser extensions can have their own bundled files. For other things, a local HTTP server could be started, serving all the assets the window manager needs.

Why not make the NodeOS server more independent from the GUI client?

From what I know, it is. All installs of NodeOS (except maybe pre-installs ;) ) use NodeOS server, and a GUI can be installed as any other npm package.
You install, and bam; GUI. :

Why not let the window manager / GUI serve itself?

I agree. The interaction between apps and the server doesn't need to be standardized. It's only the interface apps would use that would need to be standard in order to avoid having to recode apps.

Would it be ok to use qt-embedded to use webkit as html rendering engine ?
Qt-embedded is indeed lighweight and we could use its webkit port... However, I am not sure if this would be against the 'no-gui-framework'-idea (thats why I' m asking)

Would it be ok to use qt-embedded to use webkit as html rendering engine
?
Qt-embedded is indeed lighweight and we could use its webkit port...
However, I am not sure if this would be against the 'no-gui-framework'-idea
(thats why I' m asking)

A little bit, but as far as it can be compiled statically and work
fullscreen directly on the framebuffer or EGL, it could be a valid first
aproximation.

Another possibility is the CEF. It has got the ability to render to the frambuffer by default which makes it also a legitim possibility
Last but not least we got the good old gecko... I found a b2g port for 'normal' linux versions, however it may be outdated (which is sad but true :/)
1,2 or 3 ? (My personal favourite is 2..)

Another possibility is the CEF. It has got the ability to render to the frambuffer by default which makes it also a legitim possibility

I like #2 :3

It has been discussed before, CEF/content_shell over EGL is the desired renderer, but until we get that other alternatives are welcome, like content_shell over framebuffer or Gecko.

https://github.com/formula1/node-webkit-canvas
So this is something mentioned before but I've finally gotten around to it.
HTMLDoc -> Processor -> RGB(A?) Values
Using Webkit.js and headless-gl (it no longer uses 2d-contexts from what I can tell)
Ok, so heres where I'm at with this. I am getting no errors within webkit.js however I am getting buffers with all white pixels (255, 255, 255, 255). This may be due to the viewport not being handled correctly. Its also possible that webkit.js is hiding errors since headless-gl doesn't handle 14 out of the 144 functions that webkit.js needs.
Theres also a few forks that have been updated far more recently such as sbrown345's. Any thoughts more than welcome

@formula1, if I understood correctly, have you managed to make webkit.js to work against node-canvas and Linux framebuffer? Wow... O_O Yeah, it will be slow, but it would be a cool demo and proof of concept, and would be useful until we get to work something more performance savvy, good work! :-D
Could you be able to explain a little bit more how the elements are integrated? :-)

BTW... I managed to make a static build of qt :)... (wasn't that hard) I'll write the rest of it this weekend

BTW... I managed to make a static build of qt :)... (wasn't that hard)

Cool :-) Against what graphic layer, framebuffer or EGL? Have you check it works on your Ubuntu machine launching it from the terminal?

At the moment it is running against the framebuffer (but it is indeed possible to run it against EGL)
I tested ut on a Ubuntu 15 Mate machine (and my raspi). It runs of the terminal...

Ah ok, that's a good signal :-) I was worried it would be compiled against X11 or being using some X11 libs. Ok, when you get it tell us so we can review it ;-)

At the moment it is running against the framebuffer (but it is indeed possible to run it against EGL)
I tested ut on a Ubuntu 15 Mate machine (and my raspi). It runs of the terminal...

I want dis tho :3

Hope that I am able to finish it this weekend ^^

Hope that I am able to finish it this weekend ^^

I will camp out and wait!

Considering @Coretool is going down a much cleaner approach, i'll probably stop development. I have no idea how webgl works and working within a 15000 line emscripten file isnt too easy.
It turns out that webkit js doesnt use 2d context, only webgl. I havent gotten it to work with frame buffer because I cant render an image : /. I only draw white screens thus far. It doesnt seem to perform too bad (though it doesnt even work in the first place) Id say maybe a solid 20 Frames per second lol
So heres what I did

webkitjs requires a bunch of globals from the browser - https://github.com/formula1/node-webkit-canvas/blob/master/DOMPolyfills/BrowserSandbox.js

window object (which also acts as global)
document object (this seems only to be used when going to and from fullscreen, which is still experimental)
image - in 2d context, they clone what is written by the another canvas
blob - also needed for the other canvas
crapload of webgl stuff
url to support blob urls likely

webkit js also needs a canvas as an argument

with this canvas it only grabs webgl context

I created or required a polyfill for everything above. Most important being the canvas (which i return headless gl as the webgl context). From there webkitjs does its thing with the globals/settings and thats it.

Progress update
I managed to build a static Qt lib. It is basically the minimal qt lib (without any X-lib-* attachments)... It seems like the examples work fine, so it should be ok. I haven't built the Rendering application yes, because I still have some questions that I would like to have answered before I start writing the 'browser':
Do we need a address bar ?
Do we need support for svg and gifs ?
Do we need buttons like 'backward' and 'forward' ? (Or will the desktop implement them ?=
As always, ideas are welcome =)

Do we need an address bar?
Do we need buttons like 'backward' and 'forward'?

As this is an HTML renderer for the NodeOS desktop, this is just me, but I would say no to these - it seems to me that page history is pretty meaningless here.
But very yes to all the other ones. :)

I managed to build a static Qt lib. It is basically the minimal qt lib
(without any X-lib-* attachments)...

Awesome! :-D

Do we need a address bar ?

No, we don't need it, since the desktop app will be given as parameter and
we'll not move from there.

Do we need support for svg and gifs ?

It would be nice to have them specially SVG, but it's ok to enable them in
a future compilation if it give you too much problems.

Do we need buttons like 'backward' and 'forward' ? (Or will the desktop
implement them ?=

No, they are not needed because it will render the desktop web page given
as parameter, so the concept of navigation history doesn't makes sense here.

Ok, I just finished the first qt build, without svg and gifs. (It takes about an hour to build...)Now I'll move on to build the final application =)

Ok, I just finished the first qt build, without svg and gifs. (It takes about an hour to build...)Now I'll move on to build the final application =)

Ok :+1: please take note of all the steps you are doing and the commands you are using so we can write a script to automate the process and build newer versions later ;-)

Sure ^^ But first I have to find out the right combination of them ;)

Well, you can keep writting them anyway so this way we are sure don't miss any magic compiler or configuration flag... ;-)

Do we need a address bar ?

I would assume not seeing that the display manager ought to handle what's shown

Do we need support for svg and gifs ?

That would be awesome!

Do we need buttons like 'backward' and 'forward' ? (Or will the desktop implement them ?=

The desktop would need to implement them. If the desktop doesn't want them and they're there its more of a hassle than if they're not there and the desktop wants them.

Do we need OpenGL ? (maybe for later...)

Once again, would be super awesome to have. Do you mean WebGL or OpenGL?

Do we need the mouse & keyboard input framebuffer libs (Yes they exist, and I would say yes ^^)

Yes, definitely. Being a graphic layer, a desktop would need these no matter what. Might as well include them!

Do we need media backends for things like audio ?

This is honestly optional. I don't think we would, as each app would probably have it's own code for managing audio and such. For systems trying to implement multiple rendering platforms (like a yunitto-based Desktop that needs to handle both local, and external connections) it might be pleasant to it to use it's own system.
However if it is included, apps that don't want it could easily ignore it and use their own systems so it's really up to you. :stuck_out_tongue:

Do we need media backends for things like audio ?

This is honestly optional. I don't think we would, as each app would
probably have it's own code for managing audio and such. For systems trying
to implement multiple rendering platforms (like a yunitto-based Desktop
that needs to handle both local, and external connections) it might be
pleasant to it to use it's own system.
However if it is included, apps that don't want it could easily ignore it
and use their own systems so it's really up to you.

Since graphic apps will be based on html they will use the Audio API, so
yes, se need audio support. Take in account that desktop needs to work on
regular web browsers, too...

Progress Update
Hey =) I finished the renderer -> it takes the target URL as the line argument and renders to the frame buffer or EGLFS
Where should I dump the code ? @lite20 Do you still want it at Yunitto or should I create a new repo ?

Hey =) I finished the renderer -> it takes the target URL as the line
argument and renders to the frame buffer or EGLFS
Where should I dump the code ?

What about its own repo :-)

Ok =) I'll create it tomorrow since I don't have a computer near me...

The code is now online, go visit it here. I named the project noGui which stands for nodeOs-Gui. Waiting for your comments on it ^_^/

I named the project noGui which stands for nodeOs-Gui.

I love it :-D I wanted to use "nodeos-" as prefix for NodeOS related
modules and projects, but I like the idea of using "no" as short
alternative or for projects not so directly related but still focused for
Node.js, similar to how "tx" is used as prefix for Python Twisted packages
:-D

Cool that you like it ^^

Cool that you like it ^^

It was a nice idea :-)

@coretool you can create a new repo or put it in Yunitto. Your choice. I'll just cross-clone it into Yunitto if you put it into another repo ^_^

@coretool you can create a new repo or put it in Yunitto. Your choice.
I'll just cross-clone it into Yunitto if you put it into another repo ^_^

It's on the noGUI repo. Why do you want to copy it on Yunitto? Is not
possible to have it as dependency, or download it automatically?

Everything is possible :)

@lite20 No, it hasn't been modulized yet, but I am working on that (automated build script(s) are in development, thanks to piranna).

@lite20 No, it hasn't been modulized yet, but I am working on that
(automated build script(s) are in development, thanks to piranna).

You are welcome :-)

It's on the noGUI repo. Why do you want to copy it on Yunitto? Is not
possible to have it as dependency, or download it automatically?

I was under the impression that it wasn't yet a module. But since you have build script(s) coming, integration will be easy.

Just if anyone was wondering, Yunitto's browser rendering works and is open for experimentation. If anyone has issues with it, please let me know so we can clean it up

Could you be able to remind us what was the purposse of Yunitto, please?
El 17/2/2016 6:20 PM, "Lite McFish"<EMAIL_ADDRESS>escribió:

Just if anyone was wondering, Yunitto's browser rendering works and is
open for experimentation. If anyone has issues with it, please let me know
so we can clean it up
—
Reply to this email directly or view it on GitHub
https://github.com/NodeOS/NodeOS/issues/201#issuecomment-185309942.

@piranna it's designed for desktop managers. (Works on any platform including NodeOS) and handles multiple screens and interfaces for the DM. for example it provides an easy way for a DM to support rendering to a local screen (using noGUI), or a browser over the same interface.

Can we pin this thread?

Done. Don't you have permissions to add labels?

@piranna yes, I do :P I just wanted to ask first

Cool ;-) Don't need to ask for this small things :-)
El 1/7/2016 8:19, "Lite McFish"<EMAIL_ADDRESS>escribió:
@piranna https://github.com/piranna yes, I do :P I just wanted to ask
first
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NodeOS/NodeOS/issues/201#issuecomment-229863240, or mute
the thread
https://github.com/notifications/unsubscribe/AAgfvhIJI0gSOyekctCCAzpianVY_N5Pks5qRLGBgaJpZM4G-r60
.

Hahah okay, I won't ask next time :P

Hahah okay, I won't ask next time :P

;-)

I've been following this project for a few years and am excited about the GUI prospects, is this still the right thread for such a discussion, (#311 seems more active)? Either way, I have a couple of comments and questions:
@Coretool Just wanted to mention, nogui is not very searchable on the Google machine, but I did find your package by searching "github nodeos-gui". Here it is, for anyone else looking..
@piranna I've seen in the mention of QT in other threads, (like issue #311), as well as WebKit and Blink. I'm not familiar with the C++ layer required to make rendering a reality, but where are we in relation to the checklist at the top of this thread?
I've seen recurring mention to #147 so I also want to express my viewpoint: This project should implement, or provide a platform for, Blink, or a similar external dependency on which developers can implement their own visual layer, but not impose any opinions on the view layer itself. As an example: "GUI windows" are mention in #147, but that raises concern that this platform will result in the same sort of application layer we get from conventional operation systems, (which some users may not see as an improvement).
TL;DR How do we get to a web browser-like environment from where we're at now? The flexibility of a blank page running this much closer to the hardware sounds like a damn good place to build an interface, regardless of the hardware powering it.
p.s. @piranna and contributors: This project is amazing, thank you for your commitment!

@cazzar I believe that the graphics has been one of the hardest points for many of us. While in concept it is simple, in practice it has turned up not so much. However, passionate people like me, you, @Coretool, @lite20 and of course @piranna keep the vision alive.
I believe the next steps to getting this done is isolating what we need for graphics.

A way to render to Hardware - Using framebuffer we only need to provide it RGB values
A way to transform HTML to RGB Values

Talk to someone from the blink/webkit team to see how we can incorporate their rendering engine

Chromium Embedded Framework was a thing for a period of time
Opera started using blink as well so its not unheard of or unreasonable

Talk to someone on servo - Rust + Javascript may be a future we can get into
Ideally we use blink or some other rendering engine, however I know when I look at the code I certainly get fatigued just
Edit phantomJS to see if we can do streaming output or capture on each dom change (avoid css transformations)
Edit a pre-existing html to renderable output such as https://www.npmjs.com/package/wkhtmltopdf
machine learn our way to a rendering engine :)

A way to get the code into the rendering system and out again

The easy part as we can just create a wrapper library

I think we are all busy people so the more hands that can dig into this the better. I myself have about 3 projects I currently am taking care of though I still keep an eye on this one because its special to me

@formula1 I have an idea which could provide a rough but experimental graphic runtime for NodeOS. :P I'll keep you all posted

@piranna Mesa can be compiled without X dependencies by disabling GLX and XA. However, the main problem is that some components of Mesa (GBM and EGL) cannot be built as static libraries.
Another issue I've faced is that on compiling Mesa with the NodeOS toolchain, it failed on a missing zlib.h

@piranna Mesa can be compiled without X dependencies by disabling GLX and XA. However, the main problem is that some components of Mesa (GBM and EGL) cannot be built as static libraries.

This components are mostly related to hardware drivers, so it makes sense that can't be compiled statically, but instead each system should have their own ones for their particular hardware. We already have libfuse as a dynamic library because it's fairly common and had some problems compiling it statically, so I don't see it bad to add this ones too, only that stick to the really few needed ones, and if possible put them in the user directory instead of system globally.

Another issue I've faced is that on compiling Mesa with the NodeOS toolchain, it failed on a missing zlib.h

Possibly related to https://github.com/Coretool/noGUI/issues/10.


Support for TypeScript import types

What version are you using?
https://eslint.org/doctrine/demo/ as of today.
What JSDoc comment were you trying to parse?
@param {import("path/to/module").Foo} arg The argument.
What Doctrine options were you using (sloppy, unwrap, etc.)?
recoverable
What happened? Include output if possible.
{
    "description": "",
    "tags": [
        {
            "title": "param",
            "description": "The argument.",
            "type": null,
            "errors": [
                "not reach to EOF"
            ],
            "name": "arg"
        }
    ]
}

What did you expect to happen?
{
    "description": "",
    "tags": [
        {
            "title": "param",
            "description": "The argument.",
            "type": {
                "type": "NameExpression",
                "name": "import(\"path/to/module\").Foo"
            },
            "name": "arg"
        }
    ]
}

TypeScript allows for types to be imported inline.  See examples here: https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-JavaScript
// We can also import declarations from other files using
// 'import' types:

/**
 * @param p { import("./a").Pet }
 */
function walk(p) {
    console.log(`Walking ${p.name}...`);
}

Unfortunately, ESLint's valid-jsdoc rule does not allow these same types.  It would be great if the linter rule allowed these import types.

Thanks for this issue. We have decided to officially end-of-life JSDoc support in ESLint. As a result, this repository and project will no longer be maintained.
Thanks for understanding and we apologize for any inconvenience.


Gen ai cards

Resolve import errors brought by block name changing
No ticket
Test URLs:

Before: https://stage--express--adobecom.hlx.page/express/?lighthouse=on
After: https://gen-ai-cards--express--adobecom.hlx.page/express/?lighthouse=on

Codecov Report

Merging #273 (f71386f) into stage (36f1cee) will increase coverage by 0.79%.
Report is 27 commits behind head on stage.
The diff coverage is 63.23%.

@@            Coverage Diff             @@
##            stage     #273      +/-   ##
==========================================
+ Coverage   46.70%   47.50%   +0.79%
==========================================
  Files          29       30       +1
  Lines        8840     9193     +353
==========================================
+ Hits         4129     4367     +238
- Misses       4711     4826     +115

Files Changed
Coverage Δ

express/blocks/columns/columns.js
36.28% <5.08%> (-6.78%)
:arrow_down:

express/scripts/utils/pricing.js
70.80% <21.62%> (-5.20%)
:arrow_down:

express/blocks/shared/video.js
34.49% <27.27%> (-0.17%)
:arrow_down:

express/blocks/marquee/marquee.js
88.45% <42.85%> (-0.89%)
:arrow_down:

express/blocks/faq/faq.js
83.15% <71.42%> (-2.24%)
:arrow_down:

express/blocks/banner/banner.js
88.09% <76.92%> (-6.78%)
:arrow_down:

express/blocks/gen-ai-cards/gen-ai-cards.js
80.00% <80.00%> (ø)

express/blocks/pricing-summary/pricing-summary.js
83.85% <81.25%> (-1.60%)
:arrow_down:

express/scripts/scripts.js
39.42% <100.00%> (+0.57%)
:arrow_up:

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Wrongly treating jest.config.js as JSON

Hello! First, really appreciate you bring this extension back from the grave!
Second, it appears that your extension is attempting to parse my jest.config.js as JSON instead of evaluating it as JavaScript. For example, when I have a very basic config like so:
module.exports = {
	clearMocks: true,
	collectCoverage: true
};

I get the following error:
[2020-05-21 20:43:13.960] [ERROR] Error trying to parse Jest setup file: c:\Development\myaccount-frontend\jest.config.js [SyntaxError: Unexpected token m in JSON at position 0
	at JSON.parse (<anonymous>)
	at c:\Users\XXX\.vscode\extensions\kavod-io.vscode-jest-test-adapter-0.3.3\dist\extension.js:425:2523169
	at Generator.next (<anonymous>)
	at o (c:\Users\XXX\.vscode\extensions\kavod-io.vscode-jest-test-adapter-0.3.3\dist\extension.js:16:1418)]

Is this a bug, or is there something I need to do myself to get it to recognize that it's a JS file and not a JSON file?
Thanks!

Can you tell me what version of the extension you have?  There was an issue around that kind of behaviour that was recently fixed.  I'm interested in whether the auto-updating is working correctly.

Sure! 0.3.3. VS Code believes it’s the latest and the Marketplace on the web believes 0.2.0 is the latest 🤷🏼♂

Ok cool. Do you want to try uninstalling and reinstalling? That should bring you to the latest version. I know there is an issue with the marketplace version. You've just confirmed that it is now a significant issue.

After uninstalling and re-installing it now shows v0.2.0 installed! At least that matches the Marketplace version now. Surprisingly my issue went away however, everything's working now. Don't know if that helps you or not.

Cheers. I have released a patch version that gets everything in sync as a temporary fix. I have to update the CI pipeline to fix permanently. Closing this for now, please reopen if problem persists.


Implement DMP-71: Add list staffs API

Signed-off-by: Prnyself<EMAIL_ADDRESS>

ref: https://github.com/beyondstorage/dm/pull/71


A few cleanup items

Cleaning up a few items that I noticed during previous work:

guard against Platform.AWS being nil
dockerfile LABEL shoudl have equal sign in assignment
error string should not start with a capital letter
variable should not mask imported package name

All are in their own commits for easy review

/assign @legionus @dmage

/retest

/lgtm

/retest

/lgtm

/retest

/retest

/retest

/retest

/hold

/hold cancel
/lgtm
a redundant check never killed anyone.

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

@bparees had to rebase (had a conflict) can I get an lgtm please?

/lgtm


Deployment playbooks should run independently of Provisioning

Deployment playbooks should not require hardware configuration and should therefore work in Docker (the main exception being Docker in Docker which is tested on a VM). It should therefore be possible to set default variables in any roles so that they'll just work on a standard system, but will take account of optional vars for custom configs as provided by the provisioning playbook.
An added benefit is that in the event of a disaster the entire system can be run on any VM, albeit with degraded performance.

All production roles and playbooks are decoupled from this repository.


devmapper: isolate faulty devices in separate bucket

Problem

A critical issue can happen that devmapper snapshotter fails to
create new snapshot because the snapshot ID conflicts in scenario
that we will explain later. The error message is like:
"
"failed to create containerd container: failed to save metadata for device "vg0-mythinpool-snap-67451"
(parent: "vg0-mythinpool-snap-45443"): object already exists"
"

An reproducer

Restarting containerd during processing an snapshot creating request may
lead to this issue, but the possibility is low. To fast reproduce, the
following fault injection is enough:
func (s *Snapshotter) Prepare(ctx context.Context, key, parent string, opts ...snapshots.Opt) ([]mount.Mount, error) {
...
	err = s.withTransaction(ctx, true, func(ctx context.Context) error {
		mounts, err = s.createSnapshot(ctx, snapshots.KindActive, key, parent, opts...)
		// crash injection
		panic("panic after creating snapshot, but before the upper database tx commits")

		return err
	})

	return mounts, err
}

Why snapshot ID conflicts

The snapshot ID is the seqence ID of snapshotter metadata.db.
The snapshot name is in format of $thinpool-snap-$snapshot ID, which stores
in devmapper snapshotter $thinpool.db.
The 2-layer databases are separately wrapped by tranasations. The outer transation
is for metadata.db, and the inner transaction is for $thinpool.db.
As the reproducer, panic comes between inner tx commits and out tx not commits yet.
Then, the sequence ID of metadata.db is not committed, it will reuse the snapshot ID
before panics, but that snapshot ID has already been used by $thinpool.db.

Idea

Because containerd can quit or crash at any time, it's possible that the snapshot ID can
conflict. Currently, I have no idea how to handle 2 nested transactions.
One possible fix is to isolate faulty devices to s separate buckets to avoid snapshot name
conflicts in such case.
Fixes #5646
Signed-off-by: Eric Ren<EMAIL_ADDRESS>

How can I get which code line has problem?
Running [/home/runner/golangci-lint-1.36.0-linux-amd64/golangci-lint run --out-format=github-actions --path-prefix=src/github.com/containerd/containerd --timeout=5m] in [/home/runner/work/containerd/containerd/src/github.com/containerd/containerd] ...
  Error: ineffectual assignment to `err` (ineffassign)
  Error: ineffectual assignment to `err` (ineffassign)

  Error: issues found

@renzhengeek ideally transactions should prevent us ending up in wrong state.
I see that metadata.createSnapshot calls s.Snapshotter.Prepare outside of transaction (https://github.com/containerd/containerd/blob/main/metadata/snapshot.go#L357).
If we nest them, do you thing that will help? (I don't recall why exactly they're not nested, but worth exploring).

But is it possible to track the state of the device to have this information e.g. inner tx done, outer tx done?

Hi,
Sure, it's possible to track that information. If we do so, we still need to check the device state, and decides if the sequence ID of the metadata boltdb should be decreased by 1, which seems a bit complicated to me.

@renzhengeek ideally transactions should prevent us from ending up in wrong state.
I see that metadata.createSnapshot calls s.Snapshotter.Prepare outside of transaction (https://github.com/containerd/containerd/blob/main/metadata/snapshot.go#L357) block, so these are two independent transactions.

Given my poor english, I'm not sure if I understand you clearly. You mean the two independent tx are:

metadata.createSnapshot();
s.Snapshotter.Prepare;
, do you?

However, I mean different places, please see comments inline code of devmapper's code (https://github.com/containerd/containerd/blob/main/snapshots/devmapper/snapshotter.go#L197):
func (s *Snapshotter) Prepare(ctx context.Context, key, parent string, opts ...snapshots.Opt) ([]mount.Mount, error) {
...
	err = s.withTransaction(ctx, true, func(ctx context.Context) error {    // metadata boltdb tx, the snap-id comes from its DB sequence id
		mounts, err = s.createSnapshot(ctx, snapshots.KindActive, key, parent, opts...) // inside createSnapshot(), there are steps to to within the tx of the boltdb of $thinpool.db.
		// crash injection
		panic("panic after creating snapshot, but before the upper database tx commits")

		return err
	})

	return mounts, err
}

Specifically, the outer tx is:
https://github.com/containerd/containerd/blob/25d7f907c03a58b5fa30c6f90c3a36aa308e124c/snapshots/devmapper/snapshotter.go#L452
the inner tx operations are:

createSnapshot(), same function name with metadata mod, but within devmapper: https://github.com/containerd/containerd/blob/main/snapshots/devmapper/snapshotter.go#L352
just take one place for example:
https://github.com/containerd/containerd/blob/main/snapshots/devmapper/snapshotter.go#L384
https://github.com/containerd/containerd/blob/25d7f907c03a58b5fa30c6f90c3a36aa308e124c/snapshots/devmapper/pool_device.go#L358
https://github.com/containerd/containerd/blob/25d7f907c03a58b5fa30c6f90c3a36aa308e124c/snapshots/devmapper/pool_device.go#L389

If we nest them, do you thing that will help? (I don't recall why exactly they're not nested, but worth exploring).

Will rethink after confirm the problem with you:-)

Or should we cleanup metadata if inner snapshots call fails?

When should we cleanup?
I assume it's during starting containerd. But, one possible case is that we cannot judge if the two tx/db are in consistent, or if the inner snapshot call fails. The case is as the reproducer I provide in the commit id:

the inner snapsots actually complete without error;
containerd quits for whatever reasons, just before committing the outer tx.

Hope I make it more clear a bit.

please ping me if someone has the same problem and needs such fix. closed at this moment.

Hi, I'm seeing the same error. Oncd a node is in this state, new pod/container will consistently fail and cannot recover by itself. @renzhengeek Did you get the fix merged or a newer containerd version will address this issue?
Events:
  Type     Reason                  Age                From     Message
  ----     ------                  ----               ----     -------
  Warning  FailedCreatePodSandBox  10s (x3 over 35s)  kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create containerd container: failed to save metadata for device "vg_thin-containerd_thin_pool-snap-54" (parent: "vg_thin-containerd_thin_pool-snap-1"): device "vg_thin-containerd_thin_pool-snap-54" is already there {DeviceID:44 Size:64209761075 Name:vg_thin-containerd_thin_pool-snap-54 ParentName: State:Activated Error:}: object already exists

@renzhengeek we are seeing this issue on a NFS setup.
Steps to repo:

Configure the devmapper device over NFS.
Start 'nerdctl load'.
While nerdctl load is in progress, kill containerd process.
Restart containerd.
In next nerdctl load attempt, it failed with error -
failed to prepare extraction snapshot \"extract-572349390-ZU8W sha256:6a4a177e62f374d68e6889ffa22b644db056e1d47ee4085c88408fa1d153871d\": failed to save metadata for device \"containerd-pool-snap-1144\" (parent: \"\"): device \"containerd-pool-snap-1144\" is already there {DeviceID:51 Size:5368709120 Name:containerd-pool-snap-1144 ParentName: State:Activated Error:}: object already exists: unknown


Make app compatible with Android API 10 (2.3.3 minimun)

Reduce the minSdkVersion to 10 and test if still compiles/works.

Can you test if it works correctly? Unzip it then install the apk.
henkaku_server-1.5_api10.apk.zip

It worked perfect thank you

Fixed on 4472178b666b575062d459e32ba0cab6b047daa4


Some optimizations in arrow_buffer::util::bit_util do more harm than good

Describe the bug
The bitmap access and manipulation functions in arrow_buffer::util::bit_util do not follow the most obvious implementation strategy...
pub fn get_bit(data: &[u8], i: usize) -> bool {
    data[i / 8] & (1 << (i % 8)) != 0
}

Instead, they use table lookup techniques like...
const BIT_MASK: [u8; 8] = [1, 2, 4, 8, 16, 32, 64, 128];
pub fn get_bit(data: &[u8], i: usize) -> bool {
    (data[i >> 3] & BIT_MASK[i & 7]) != 0
}

According to the discussion within PR 5760, this was demonstrated to be beneficial to performance during the development of older versions of arrow.
However, in my testing with rustc 1.78 and a Zen 3 CPU (AMD Ryzen 5 5600G), I have shown that modern rustc is in fact perfectly able of generating optimal code from the simple version, and that the table lookup version can easily degrade into worse performance if the compiler optimization process does not perfectly succeed at eliminating its overhead.
Therefore, I think arrow should switch back to the obvious code, and will submit a PR accordingly.
To Reproduce
The repository https://github.com/HadrienG2/bitmap-bench contains microbenchmarks of three implementations of bit readout, setting and clearing:

The simplest implementation, called naive.
The current arrow implementation, called const_table.
A variation of the current arrow implementation where the table is stored inside of a static variable instead of a const, called static_table (the rationale for this variant will be explained below).

These implementations are exercised by the benchmark on a bitmap which fits into an L1 cache (which is when the performance of bit access functions has the largest impact). Three access patterns are evaluated:

The hidden_constant pattern repeatedly accesses the bitmap at widely spaced indices which are hidden from the compiler's optimizer. This models a scenario where the compiler optimizer does not manage to figure out the user's data access pattern and must generate maximally pessimistic random bitmap access code.
The linear_all pattern accesses all bits from the bitmap from start to finish, and exposes this fact to the compiler's optimizer. The optimizer should thus be able to leverage this regular pattern for optimization, for example accessing all bits of a bitmap should compile into a simple shift-and-test loop, setting all the bits of a bitmap in order should compile into writing 0xff to each byte of the bitmap, and clearing all the bits of the bitmap in order should compile into writing 0x00 to each byte of the bitmap.
The linear_strided pattern is similar to linear_all, but accesses every other bit instead of accessing every bit. This is a little bit harder on the optimizer, but is still expected to compile into byte-wise operations during writes (byte |= 0b01010101 for setting, byte &= 0b10101010 for clearing).

You can run the benchmark workloads with cargo bench, and on my machine (rustc 1.78, AMD Ryzen 5 5600G CPU), this yields the following results:

The simple implementation is almost always the fastest (within margin of measurement error), except in one scenario (clearing all bits) where it was measured a bit slower. This scenario was further investigated, and it turns out that the compiler generated assembly which is rigorously identical to the measured-fastest implementation in that scenario, so my understanding is that the speed difference comes from a benchmark artifact like a code alignment issue that is not relevant to real-world usage.
The current table lookup implementation can be as fast as the simple implementation when the compiler manages to optimize out the table and compile it into in-register bit-testing code. But because the table is a const, which does not have a fixed memory location in the program address space, whenever this optimization process does not go perfectly smoothly, the compiler must emit an instruction which writes the table to the program stack, which is quite costly, followed by table lookups which are also costlier than in-register bit testing.
I tried to evaluate the impact of table writes by writing an alternate version of the table lookup implementation where the table is a static variable instead of a const. As expected, this implementation never suffers from table write overheads, however it still suffers from table lookup overhead (which, as mentioned earlier, is costlier than in-register bit testing), and it can also suffer from a different kind of compiler optimization mishap where the compiler optimizer "forgets" that the table contains bytes with a single bit set, resulting in worse code in simple patterns like linear iteration.

Expected behavior
The bit operations provided by arrow should be the one that perform best, which in this case are also the simplest.

Also found the abseil blog has mention this: https://abseil.io/fast/9

label_issue.py automatically added labels {'arrow'} from #5772


add an error check of flash_area_open()

Contribution description
tests/subsys/settings/fcb/src/settings_test_fcb.c : add an error check of flash_area_open() in config_wipe_fcb()
Signed-off
Signed-off-by: Xinrong Han<EMAIL_ADDRESS>Issue
Fixes parts of #30195

I have fixed the commit message. Is it not proper?

Error: See https://docs.zephyrproject.org/latest/contribute/#commit-guidelines for more details

e675309c2f2ecf984b3e460d28e63b78f273aa03: author email (Han Xinrong<EMAIL_ADDRESS>needs to match one of the signed-off-by entries.
Error: See https://docs.zephyrproject.org/latest/contribute/#commit-guidelines for more details

1: UC5 Title exceeds max length (85>75): "tests: subsys: settings: fcb: settings_test_fcb: add error check in config_wipe_fcb()"
Error: Process completed with exit code 1.

@Hxinrong You need to reduce the line length in title of the commit message for the check to pass:
1: UC5 Title exceeds max length (85>75): "tests: subsys: settings: fcb: settings_test_fcb: add error check in config_wipe_fcb()"
Error: Process completed with exit code 1.

@Hxinrong You need to reduce the line length in title of the commit message for the check to pass:
1: UC5 Title exceeds max length (85>75): "tests: subsys: settings: fcb: settings_test_fcb: add error check in config_wipe_fcb()"
Error: Process completed with exit code 1.

@Hxinrong do you have plans to address the review comments? Otherwise, could someone else take over the PR?


Camera does not open <image_picker>

I am getting this error whenever I try to open the camera with image opener:
(in my opinion, image_picker does not take conflict in account)
E/flutter (12347): [ERROR:topaz/lib/tonic/logging/dart_error.cc(16)] Unhandled exception:
E/flutter (12347): PlatformException(error, Attempt to invoke virtual method 'android.content.res.XmlResourceParser android.content.pm.ProviderInfo.loadXmlMetaData(android.content.pm.PackageManager, java.lang.String)' on a null object reference, null)
E/flutter (12347): #0      StandardMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:547:7)
E/flutter (12347): #1      MethodChannel.invokeMethod (package:flutter/src/services/platform_channel.dart:279:18)
E/flutter (12347): <asynchronous suspension>
E/flutter (12347): #2      ImagePicker.pickImage (package:image_picker/image_picker.dart:47:40)
E/flutter (12347): <asynchronous suspension>
E/flutter (12347): #3      UploadFilesToDatasetState.getImage (file:///Users/vibhavkotriwala/Desktop/work/4ceed_app/lib/pages/upload_to_dataset.dart:20:35)
E/flutter (12347): <asynchronous suspension>
E/flutter (12347): #4      _InkResponseState._handleTap (package:flutter/src/material/ink_well.dart:494:14)
E/flutter (12347): #5      _InkResponseState.build.<anonymous closure> (package:flutter/src/material/ink_well.dart:549:30)
E/flutter (12347): #6      GestureRecognizer.invokeCallback (package:flutter/src/gestures/recognizer.dart:102:24)
E/flutter (12347): #7      TapGestureRecognizer._checkUp (package:flutter/src/gestures/tap.dart:161:9)
E/flutter (12347): #8      TapGestureRecognizer.acceptGesture (package:flutter/src/gestures/tap.dart:123:7)
E/flutter (12347): #9      GestureArenaManager.sweep (package:flutter/src/gestures/arena.dart:156:27)
E/flutter (12347): #10     _WidgetsFlutterBinding&BindingBase&GestureBinding.handleEvent (package:flutter/src/gestures/binding.dart:147:20)
E/flutter (12347): #11     _WidgetsFlutterBinding&BindingBase&GestureBinding.dispatchEvent (package:flutter/src/gestures/binding.dart:121:22)
E/flutter (12347): #12     _WidgetsFlutterBinding&BindingBase&GestureBinding._handlePointerEvent (package:flutter/src/gestures/binding.dart:101:7)
E/flutter (12347): #13     _WidgetsFlutterBinding&BindingBase&GestureBinding._flushPointerEventQueue (package:flutter/src/gestures/binding.dart:64:7)
E/flutter (12347): #14     _WidgetsFlutterBinding&BindingBase&GestureBinding._handlePointerDataPacket (package:flutter/src/gestures/binding.dart:48:7)
E/flutter (12347): #15     _invoke1 (dart:ui/hooks.dart:134:13)
E/flutter (12347): #16     _dispatchPointerDataPacket (dart:ui/hooks.dart:91:5)

My code for AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          xmlns:tools="http://schemas.android.com/tools"
    package="com.example.myapp">

    <!-- The INTERNET permission is required for development. Specifically,
         flutter needs it to communicate with the running application
         to allow setting breakpoints, to provide hot reload, etc.
    -->
    <uses-permission android:name="android.permission.INTERNET"/>

    <!-- io.flutter.app.FlutterApplication is an android.app.Application that
         calls FlutterMain.startInitialization(this); in its onCreate method.
         In most cases you can leave this as-is, but you if you want to provide
         additional functionality it is fine to subclass or reimplement
         FlutterApplication and put your custom class here. -->
    <application
        android:name="io.flutter.app.FlutterApplication"
        android:label="my_app"
        android:icon="@mipmap/ic_launcher">

        <activity
            android:name=".MainActivity"
            android:launchMode="singleTop"
            android:theme="@style/LaunchTheme"
            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale|layoutDirection|fontScale|screenLayout|density"
            android:hardwareAccelerated="true"
            android:windowSoftInputMode="adjustResize">
            <!-- This keeps the window background of the activity showing
                 until Flutter renders its first frame. It can be removed if
                 there is no splash screen (such as the default splash screen
                 defined in @style/LaunchTheme). -->
            <meta-data
                android:name="io.flutter.app.android.SplashScreenUntilFirstFrame"
                android:value="true" />
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>

        <provider
                android:name="android.support.v4.content.FileProvider"
                android:authorities="com.example.myapp.fileprovider"
                android:exported="false"
                android:grantUriPermissions="true"
                tools:replace="android:authorities">
            <meta-data
                    android:name="android.support.FILE_PROVIDER_PATHS"
                    android:resource="@xml/filepaths"
                    tools:replace="android:resource" />
        </provider>

    </application>
</manifest>

Code for camera open button:
class UploadFilesToDataset extends StatefulWidget {

  final String datasetId;
  UploadFilesToDataset(this.datasetId);

  State createState() => new UploadFilesToDatasetState();
}

class UploadFilesToDatasetState extends State<UploadFilesToDataset> {
  File _image;

  Future getImage() async {
    var image = await ImagePicker.pickImage(source: ImageSource.camera);

    setState(() {
      _image = image;
    });
  }

  @override
  Widget build(BuildContext context) {
    return new Scaffold(
      appBar: new AppBar(
        title: new Text('Upload File(s)'),
      ),
      body: new Center(
        child: _image == null
            ? new Text('No image selected.')
            : new Image.file(_image),
      ),
      floatingActionButton: new FloatingActionButton(
        onPressed: getImage,
        tooltip: 'Pick Image',
        child: new Icon(Icons.add_a_photo),
      ),
    );
  }

This should fix the issue -
change AndroidManifest.xml to:

Hi! @vibhav2799 this solution seems to be outdated but problem is not :( android:name part is problematic as well as android:resource. Both are marked red, building fails.

flutter clean solved the issue for me, as mentioned in #28550


Feat: Support for Capacitor V6.0

Is this currently planned?

in 2 weeks hopefully I have the time todo it

@moberwasserlechner thank you for the response!
Is this going to be a huge lift?

@xpluscal @moberwasserlechner  does this package automatically send SMS without default SMS APP? When i tried it opens in SMS APP. Thanks

No. The default app always opens. Both platforms do not allow sending sms in the background since a few years.On 12.07.2024, at 06:22, lajith111 @.***> wrote:
@xpluscal @moberwasserlechner  does this package automatically send SMS without default SMS APP? When i tried it opens in SMS APP. Thanks
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

@moberwasserlechner Thank you for quick reply,, Actually i am using this Cordova capacitor  plugin https://github.com/cordova-sms/cordova-sms-plugin
In this We have using below code for send SMS with target android 13  which works in Android 14 without opening default SMS app. This plugin if    //intent: '' it send sms automatically   but it require only SEND SMS permission
Apologize if i am wrong i am not android dev i am expertise in only .NET
var app = {
    sendSms: function() {
        var number = document.getElementById('numberTxt').value.toString(); /* iOS: ensure number is actually a string */
        var message = document.getElementById('messageTxt').value;
        console.log("number=" + number + ", message= " + message);

        //CONFIGURATION
        var options = {
            replaceLineBreaks: false, // true to replace \n by a new line, false by default
            android: {

                //intent: '' // send SMS without opening any other app, require : android.permission.SEND_SMS
            }
        };

        var success = function () { alert('Message sent successfully'); };
        var error = function (e) { alert('Message Failed:' + e); };
        sms.send(number, message, options, success, error);
    }
};

Does your use case allows background sending and is your application live?
I dropped support because Android did not allow the background sending a few years back for most use cases. And less code means less maintenance work.
https://support.google.com/googleplay/android-developer/answer/10208820?sjid=3031348539978350994-EU
TL;DR: Imo this means: Only apps, which have SMS sending as their "core functionality/main purpose" are allowed to use background sending.

Soyry for wasting yourtime.. Actually my App not in Play store / manually APK installation to users.
And my app does not use background for sending SMS and
In our app users do the transaction & sent sms to customers using SIM card..
For this use case it will be helpful to us if you provide a option Thanks..

Sry but such non standard use cases I can not support because of maintenance costs.
I have very little time for Open Soruce, which needs to be used efficiently.
You can of course always fork this repo and use your own version of it.

ok,Thanks

Support for Capacitor 6 was release today. I could not test it on a device so please report any issues. I'll fix the Cap 6 related next week.


🚧 Experience index

Purpose
This PR introduces a Proof of Concept (PoC) for the Experience Index, inspired by the IEEE Standard for Learning Object Metadata paper.
Proposal
The primary goal of this work is to lay the foundation for a more advanced system. To avoid the process of handling Alembic configuration, some code sources have been initially placed in the core package, with the intention of refactoring them in the near future.
Such system should enable us populating dropdown values for selecting videos in a course in the frontend.
A follow-up PR will be submitted shortly, proposing a statements crawler to populate the database with learning objects extracted from statements.

[X] Models
[X] Endpoints
[x] Tests
[x] Clarify Self-Referential Many-to-Many relation (Relation Table)

What's next?

@quitterie-lcs

For tests naming pattern, I would stick to the name of the API method (get rather than read, to be able to easily retrieve all concerned tests when developing)

I don't totally agree on this one. The experience index is doing CRUD operations. The operation paths are not named after the HTTP method, but the type of CRUD operation they handle.
I feel, having tests' name not matching the name of the operation path, could be a bit misleading. Wdty @jmaupetit?

I feel, having tests' name not matching the name of the operation path, could be a bit misleading. Wdty @jmaupetit?

I think tests naming pattern is fine. But I also think we should organize tests so that their path follows the source code they are testing, e.g. move tests/test-xi-api-experience.py to tests/xi/routers/test_experiences.py (this is the pattern we stick to in other projects).


Remove empty user when put permission

What is this PR for?
check empty users and delete it.
What type of PR is it?
[Bug Fix]
How should this be tested?
clear note permissions then your note can't read.
Screenshots (if appropriate)
Questions:

Does the licenses files need update?no
Is there breaking changes for older versions?no
Does this needs documentation?no

I would want to see you again with nice contribution. Thanks.


[no-master] Disable slow scalaTestSuite tests when running in Rhino.

Because under Rhino, they are too slow.

scalaTestSuite/test under 2.13.0 is our biggest source of spurious failures in our CI at the moment. This should address that problem.


Update version

@tiesjan
Do you plan to update pip with a new version soon?

Hi @CleitonDeLima, I plan to do a release shortly after Django 4.2 is released in April. It will include several new features and deprecations.

Nice!
I also saw that the empty form was changed using the template tag, perhaps due to an error when deleting a form.  I haven't been able to test it yet, I just saw the code.

A quick comment regarding the use of the <template> tag. The <template> behaves differently to the normal DOM elements (see https://stackoverflow.com/questions/66137470/template-queryselector-inside-template-tag-not-working for details). The example on the django-convenient-formsets is using IDs for all the elements and so the example works but if you rely on classes, then using the <template> will raise Unable to find DOM elements with selectors.

I see, thanks for pointing this out. I wasn't aware the removeChild method wouldn't work here and apparently this is not covered by the end-to-end tests either. I am able to reproduce that exception now.
It seems that one way to fix this is by cloning template.content.firstElementChild instead of template.content directly. This would require the <template> tag to contain a single element only, which in turn contains the empty form. This is the exact structure as in the example and how I usually use the library, so it sounds like a simple but good solution to me. Any ideas on this?
@joahim I don't quite get what difference it makes in using classes or ids and whether this is related. If I understand correctly, the library needs to find the <template> tag using any query selector and from then on simply clone its contents. Am I missing something?

Any ideas on this?

The first problem is that it returns an element, the form would need to have a parent element, I believe this is optional, or not?

@tiesjan please disregard my ramblings about using ids vs classes :-) I confused two different problems when trying out the <template> approach.
As for the solution: I personally like the idea of using the <template> tag and therefore like what you propose. And it would be good to make this choice clear in the docs if you decide to use it.
One more thing: I noticed there is a mismatch between the README version displayed on the GitHub and PyPI.

Thanks for both your input. I've added a fix and clarified the expected structure in the documentation in 34319d8. Let me know if you still find some bugs! 🙂

The first problem is that it returns an element, the form would need to have a parent element, I believe this is optional, or not?

@CleitonDeLima It is correct that the form would need to have a parent element, but in practice this is already the case due to the formSelector parameter. Nothing changes here, it's just clarified in the documentation.
As for storing a stringified empty form in an attribute on the add form button: I consider this out of scope for this library. For simplicity, I would rather focus on handling DOM elements only. Also, rendering HTML code inside element attributes may not be the most secure approach.

One more thing: I noticed there is a mismatch between the README version displayed on the GitHub and PyPI.

@joahim Correct. The README file is read inside setup.py, so PyPI will automatically be updated in the next release.

Version 2.0 has been released! 🎉


[FEATURE] Provide TypeScript typings

Typings for the Node API: https://deepstream.io/docs/server/node-api/

@yasserf @WolframHempel any update on this?

We actually just converted deepstream to typescript so this should come out of the box after our next major release end of year

@yasserf  A year's over, nothing happened?

Any update on this?

We have a V4 version that is RC that is totally written in typescript, we will be looking to generate a declaration from that rather than maintain two

I'll wait for the V4. I didn't realised it existed. Thank you!

Awesome! It’s current an RC and being used btw by some people, barely and
breaking changes. So if you want you can start using it now!
On Tue, 12 Mar 2019 at 15:09, Rodrigo<EMAIL_ADDRESS>wrote:

I'll wait for the V4. I didn't realised it existed. Thank you!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/deepstreamIO/deepstream.io/issues/757#issuecomment-472037403,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACm7S_3amYtlEyEIbM0xZKiqVh0yM7bLks5vV8MmgaJpZM4Og8L9
.


Questions about version of Waymo Open Dataset?

Hi,
Thanks for releasing codes! During running pre-processing in WOD, I am confused that which version of WOD should be used. Is 1.2.0 or 1.3.0 ?

I guess both are fine. To be honest, I am not sure about how Waymo evolves these days. However, I guess these newer versions are compatible with 3D MOT, since the upgrades are mainly related to trajectory prediction, occupancy flow forecasting, camera-based 3D detection, etc. Maybe you can try 1.3.0 first?


Execution environment dropdown is shifted to the right

See the screenshot:

Instead, the dropdown should be aligned with the left side of the green box. The text must also be aligned.

Oh, your issue was earlier, but mine contains more info ;) https://github.com/enso-org/enso/issues/6445

merging to #6445


add 15551 and zukeswap

All Submissions:

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Blockchain Submissions:
We'll need the following to integrate your EVM-compatible blockchain:

[x] At least one AMM on your chain with a daily volume over $100k. Do you include it in your PR?
[x] Your chain logo
[x] Your native token logo
[x] Blockexplorer that could open account and transactions pages
[x] High-performance RPC endpoint. Raise the issue in this repo or reach out our team at Discord with access details.

New AMM Submissions:
We'll need the following to integrate your AMM:

[x] Do you have a daily trading volume over $20k?
[x] Does "type" at AMM config match your code base?
[x] Your AMM logo. Please add a link to your logo or attach it to a new issue in this repo.

Chain & Native Token Logo: https://raw.githubusercontent.com/ZukeSwap/zukeswap-default-token-list/main/assets/WLOOP/logo.png
AMM logo: https://raw.githubusercontent.com/ZukeSwap/zukeswap-default-token-list/main/assets/0xE3bAAb444d70CE9FCe8d07Ef24Af1Ae5C5E09fD1/logo.png

Due to Lack of stablecoins on chain.


Ensure that the scroll bridge is working

Ensure that the scroll bridge is working
This PR addresses issue #20 and ensures the proper functioning of the Scroll bridge.
Resolves #20
Changes

Removal of ScrollCrossDomainOwnable Extension

Removed the ScrollCrossDomainOwnable extension
Rationale: The xDomainMessageSender on Scroll will be the Scroll bridge contract, not the function caller. This makes the extension redundant, as the Scroll L1 messenger records the originator from L1 as the bridge contract.

Fix Transaction Reversion Due to Gas Fees
The issue arose because we were incorrectly passing the same msg.value to the l1SendMessage function and the receiveRoot function (a non-payable function). This caused the messenger service to not receive enough gas to process the transaction, as the Ether (msg.value) intended for the gas was instead being passed along with the message, impacting the gas needed for execution.
To resolve this, we set the value of the receiveRoot transaction to 0, ensuring that the Ether is used for transaction fees rather than being passed with the message itself. This adjustment prioritizes the gas fee over the value parameter in the sendMessage function, allowing the messenger to properly process the transaction.

Correct ABI Encoding

Replaced abi.encodeCall with encodeWithSignature for proper ABI encoding
The Scroll messenger requires the use of encodeWithSignature for ABI encoding of function calls. However, abi.encodeCall was incorrectly used in this instance.

Workflow

Deploy World ID on Scroll
Deploy Scroll bridge on L1
Set Scroll bridge address (only owner) on Scroll World ID
Call the propagateRoot function on the Scroll bridge (open to anyone for testing)

Related Contracts

Scroll World ID: 0x810bec8f6dd1e5b7925c8a9bb09c4254d3e2f9da
Scroll State Bridge: 0xF978A54CFEDDC497679129e166eF7E256501885e

Testing

Deployed and tested the updated contracts on Sepolia testnet
Verified successful root propagation between L1 and L2

Please review and test these changes to ensure the Scroll bridge is functioning as expected.

I'm still getting test errors @Ugo-X :
[FAIL. Reason: log != expected log; counterexample: calldata=0x04f2ce7200000000000015d63992474bee44bf3f56348f0be5cf85f75727dbe43a4d3858 args=[35090410347441852217557155930751459674472408307896461812381784 [3.509e61]]] test_owner_setRootHistoryExpiry_succeeds(uint256) (runs: 0, μ: 0, ~: 0)
[FAIL. Reason: log != expected log; counterexample: calldata=0xf944a454000000000000000000000000adbc564ec0041eecc2c8ebbed9ee38b9d59db9ae args=[0xAdbC564EC0041EeCC2c8EBBEd9eE38b9D59db9Ae]] test_owner_transferOwnershipOp_succeeds(address) (runs: 0, μ: 0, ~: 0)
[FAIL. Reason: log != expected log] test_propagateRoot_suceeds() (gas: 36155)

New Changes to PR

Switched back to using cross domain ownable
So after deployment, deployer of scroll world id has to set ownership of the scoll world id to the state bridge for them to continue using it.
Tests are fork tests, so will work when deployed on each networks.


[SPARK-27750] Standalone scheduler - ability to prioritize applications over drivers, many drivers act like Denial of Service

What changes were proposed in this pull request?
Don't allow drivers to use all the cores in spark standalone scheduler. Reserve some cores for apps

Why are the changes needed?
Airflow is triggering many Spark jobs in parallel, spark standalone gets 'full' with drivers and can never execute apps as drivers took all the cores. The spark cluster essentially becomes stuck and never completes any drivers (as no cores avail to run the associated apps), never frees up cores. Manual intervention is needed to either kill some drivers (but airflow can retry sending them), or force scale up of the spark cluster by registering more workers (than ASG MaxSize).

Does this PR introduce any user-facing change?
By default no, they must opt-in by explicitly setting config value > 0

How was this patch tested?
Running in prod for 3 months

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@Ngone51 but each driver can have different amount of cores

@Ngone51 but each driver can have different amount of cores

Yeah, but for such case, many drivers race for the reserved core concurrently, how can we know which drivers win the race and decide the amount of cores for them?

@Ngone51 as long as some cores are not used by any driver, then i don't mind which drivers got in first. I just want some cores that can only be consumed by apps

I just want some cores that can only be consumed by apps

When we limit the number of running drivers, we'll definitely have reserved cores for the apps.

@Ngone51 that is worse, one day you could have 10 drivers each taking 1 core, another day you could have 5 drivers each taking 4 cores (in this case if u limited on 10 drivers, all cores would be used). So it does not work well with diff sized drivers. Cores is simple/uniform way

What's blocking you from choosing the client deploy mode? Using the client deploy mode would let you launch the driver program locally and thus no need to worry about drivers involved into  cluster resource contentions.

Speaking of the proposed improvement, it does somehow migrates the issue by allowing you to launch at least a few executors, but it would probably still be the case that not enough cluster resources are going to executors, thus many drivers still need to wait for free slots to launch their pending tasks. Without other considerations, I think you should give client deploy mode a try (or you already have other issues thus not able to choose the client mode) ?

@jiangxb1987 client deploy mode is subject to limits of single master machine. if I want to run 200+ spark-submits in parallel then the master machine must have a enough memory to support all those drivers. With my change few executors is all I need, but even I can reserve 100s of cores for just apps with this new config

Sorry I don't have enough context to understand your use case, but submitting 200+ applications at the same time to a Spark cluster is something I'm not expecting. Basically I would expect a lot less applications, and each application can submit a few jobs, thus we don't really need to launch that much of drivers.

i am doing a data lake, where 10000s of files of different schemas get ingested daily. what is the reluctance to merging this?

can u pls merge @dongjoon-hyun ?

The proposed improvement is just not necessary. I don't see any need to submit 200+ applications, you could start one application and submit multiple jobs.

@jiangxb1987 ur suggestion is don't scale?

What do you mean by scale? You don't need 200 drivers, you can still launch one application and submit your jobs, this way your workload should work.

one app is going to be slower 2. what if 7 out of 200 job fails, whole app fails meaning poor resumability. 3. files arrive at different times, so can't wait for all to arrive and then do single app. This PR fixes clear bug, spark standalone gets itself stuck. if you don't like the number 200, think of submitting 6 apps in cluster mode on a 4 core cluster, spark gets full of drivers and no apps can ever run, spark stays stuck forever. With this fix, I can guarantee some cores for apps so spark never gets stuck with only drivers

I‘m -1 to this change, because it's trying to resolve an issue that doesn't even exist.
Please read https://spark.apache.org/docs/latest/cluster-overview.html before you ask. Thanks!

Thank you for your proposal, @tooptoop4. However, according to the above discussion, I'll close this PR. Thank you, @tooptoop4 , @Ngone51 , @jiangxb1987 .


Specify ingress IP in Debug

This allows the possibility to expose an ingress to multiple IP while running with tye run.
It might interest anybody running a service locally for the benefit of an emulator or device.
Current version only allows to expose localhost.
Ingresses bindings have a new option: ip. Setting an ip will allow binding to the ip. '*' will allow binding to all ips.
Syntax is the same as Kestrel as it is passed to Kestrel after parsing checks.
Note: unit test don't run in the windows pipeline because of firewall issues, they do run in linux and on windows, in Debug.
resolves #1041

@Hylaean Overall, looks good.  Just a couple of comments/questions and then a merge conflict that needs to be resolved.


Win11: diffusers library not working, throws error: "ImportError: cannot import name 'apply_rope' from 'diffusers.models.attention_processor'"

This is for bugs only
Did you already ask in the discord?
No, because I found a fix myself but others might find this helpful
You verified that this is a bug and not a feature request or question by asking in the discord?
Yes
Describe the bug
I installed on Win11 using the installer on 22 August 2022. However, starting after following the tutorial failed with error message:
File "[...]ai-toolkit\toolkit\ip_adapter.py", line 8, in
from diffusers.models.attention_processor import apply_rope
ImportError: cannot import name 'apply_rope' from 'diffusers.models.attention_processor'
pip show diffusers output:
Name: diffusers
Version: 0.31.0.dev0
Summary: State-of-the-art diffusion in PyTorch and JAX.
Home-page: https://github.com/huggingface/diffusers
Author: The Hugging Face team (past and future) with the help of all our contributors (https://github.com/huggingface/diffusers/graphs/contributors)
Author-email<EMAIL_ADDRESS>License: Apache 2.0 License
Location: f:\ostris\ai-toolkit\venv\lib\site-packages
Requires: filelock, huggingface-hub, importlib-metadata, numpy, Pillow, regex, requests, safetensors
Required-by: lycoris-lora
If I go back to the previous stable version, everthing appears to be working. Command used:
python -m pip install diffusers==0.30.0
Suggested fix: Change line 4 in requirements.txt
from:
"git+https://github.com/huggingface/diffusers.git"
to:
"diffusers==0.30.0"

See pull-request which fixes the issue here: https://github.com/ostris/ai-toolkit/pull/124

There was a breaking change in diffusers, but it is fixed with https://github.com/ostris/ai-toolkit/commit/338c77d67733a2d6d9c4fdd55623ae04f5ed5ead .


bump chart to 0.9.6

bump chart to 0.9.6

/ok-to-test-managed sha=3a33ae4 provider=aws

/ok-to-test-managed sha=3a33ae4 provider=gcp

/ok-to-test-managed sha=3a33ae4 provider=gcp

tests were ok https://github.com/external-secrets/external-secrets/actions/runs/6524476826, and only the destruction of the cluster failed (but the cluster was still deleted...). So I am merging


[FEATURE REQUEST] Creating an FAQ section

Description
Is your feature request related to a problem? Please describe.
I would like to create a FAQ section for site, which answers the basic Qs of the user.
It would be redirected to the contact us page
Describe the solution you'd like
Sample :->

If you have any other questions or need further assistance, Please don't hesitate to contact our customer support team. We are here to help you!
Describe alternatives you've considered
Plz assign this task to me under gssoc'23.

Hey @abhi03ruchi Go for it, and design a nice one ✨😍


Wait for the webhook service to be listening before advertising the Jobset replica as ready.

What would you like to be added:
As mentioned on the title, wait for the webhook service to be listening before advertising the Jobset replica as ready. Like on the kueue here.
Why is this needed:
It causes flakes in kueue https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_kueue/2408/pull-kueue-test-e2e-main-1-28/1802723422271180800. To fix it we need to wait for jobset operator ready and to be sure that webhooks runs success.

/cc @mimowo @alculquicondor

+1 in Kueue we use readiness probes to delay marking the deployment as available until the webhook service is ready.
This allows users to wait for the webhooks service by waiting for availability of the deployment.
We use this mechanism in kueue e2e tests here, but it can also be checked conveniently by users by kubectl wait --for=condition=available .

Yes.
/assign

Makes sense, thanks for working on this @mbobrovskyi


[usb-device-info] Adapt window content to resize

Hello Reilly,
Just noticed this. Can you please review this CSS patch?
BUG=#340
TBR=@reillyeon

lgtm

Thank you Reilly!

Updated webstore item: https://chrome.google.com/webstore/detail/usb-device-info/igkmggljimacfdfalpeelenjeicmfnll


arle: pass sbom_gcs_path to all jobs of interest

Make sure we are passing sbom_gcs_path both to arle and gce publish jobs.

/lgtm


fix(lint/useValidAnchor):  fix progressively enhanced anchors are flagged

Summary
Closes https://github.com/biomejs/biome/issues/1835

Test Plan
New tests added.
Now anchor with onClick property should not throw an error when there is a valid href value
<a href="http://www.deque.com" onclick="window.open(this.href); return false;"> Annual Reports </a>

Appreciate the fast turn around on this one!


update dependencies & update to 1.20.2

Updated all the dependencys and updated the mixin to work with 1.20.2
Might have raised the bar with the newest fabric versions too high...
Since it's pretty simple changes feel free to implement them on your own if you want to support older fabric versions as well.

Updated to 1.20.4 and added updater warning in this release


Fix #554, Updated ubuntu version in CI workflows

Checklist (Please check before submitting)

[X] I reviewed the Contributing Guide.
[X] I signed and emailed the appropriate Contributor License Agreement to<EMAIL_ADDRESS>and copied<EMAIL_ADDRESS>
Describe the contribution
Fix #554, update OS versions in github workflows
Testing performed
Check workflow results after pushing
Expected behavior changes
no impact to behavior
System(s) tested on
Browser
Contributor Info - All information REQUIRED for consideration of pull request
Haven Carlson - NASA

Could also use "ubuntu-latest" so we don't have to update the workflows every time a new version comes out.


Broken selector for workbench.getTitleBar().getItem("")

Hi, it seems the method getItem() on TitleBar is broken. When called (with parameter 'File' in this case) I get this error
2023-06-30T16:40:31.504Z INFO webdriver: DATA {using: 'xpath', value: './/div[@aria-label=".//div[@aria-label="File"]"]'}
2023-06-30T16:40:31.543Z WARN webdriver: Request failed with status 400 due to The selector ".//div[@aria-label=".//div[@aria-label="File"]"]" used with strategy "xpath" is invalid! For more information on selectors visit the WebdriverIO docs at: https://webdriver.io/docs/selectors

The selector indeed looks wrong, I'd expect the @aria-label to contain just "File" rather than another xpath.
Other methods such as getItem() on StatusBar or even getItems() on TitleBar itself seem to work fine, only that one method causes trouble.
I'm using wdio-vscode-service version 5.1.0

Thanks for reporting!

We greatly appreciate any contributions that help resolve the bug. While we understand that active contributors have their own priorities, we kindly request your assistance if you rely on this bug being fixed. We encourage you to take a look at our contribution guidelines or join our friendly Discord development server, where you can ask any questions you may have. Thank you for your support, and cheers!

@christian-bromann here is the fix with tests showing the problem

Let's continue convo in #77


the bridge network doesn't respect --link'd containers

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST
-->
Description
When adding a container to the bridge network using 'docker network connect --link', containers using that network cannot address the linked container by its linked name. When doing the same process with a new network, the linked container can be addressed by its linked name.
Steps to reproduce the issue:
To reproduce the network not behaving as expected:
$ docker run -d -p 8080:8080 --name serv skelterjohn/http
$ # first disconnect it, since it's automatically added without --link and with an IP address
$ docker network disconnect bridge serv
$ docker network connect --link serv:serv bridge serv
$ docker run --network bridge curl serv:8080
curl: (6) Couldn't resolve host 'serv'

skelterjohn/http creates a simple container that serves "Hello, world!" on port 8080. skelterjohn/curl creates a simple container that has a 'curl' entrypoint.
If instead of serv:8080 I use the IP address found in 'docker network inspect bridge', it is able to connect successfully.
If, instead of bridge, I make a new network, things work.
$ docker run -d -p 8080:8080 --name serv skelterjohn/http
$ # first disconnect it, since it's automatically added without --link and with an IP address
$ docker network create mynetwork
$ docker network connect --link serv:serv mynetwork serv
$ docker run --network mynetwork curl serv:8080
Hello, world!

Describe the results you received:
When using bridge, I was not able to connect to the container using the name I provided with the --link option.
Describe the results you expected:
I expected to be able to connect.
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
# docker version
Client:
 Version:      1.12.2
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   bb80604
 Built:        Tue Oct 11 18:19:35 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.2
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   bb80604
 Built:        Tue Oct 11 18:19:35 2016
 OS/Arch:      linux/amd64

Output of docker info:
# docker info
Containers: 25
 Running: 2
 Paused: 0
 Stopped: 23
Images: 6
Server Version: 1.12.2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 56
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 4.4.0-47-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.613 GiB
Name: foobar
ID: IK4B:7YFO:ZDYA:OS3P:XJ5T:UJYW:6P3O:X756:RZ2C:FDO2:GEFP:43GN
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: skelterjohn
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
ubuntu trusty on GCE.

--link is local to the container, not bound to the network.
If you want to provide an alias to the joining container that works across the network, use --alias.
I'm also not sure if these are meant to work with the bridge network, though.

ping @mavenugo

"Error response from daemon: Network-scoped alias is supported only for containers in user defined networks"
Regarding --link being local to the container - is the fact that it worked with mynetwork in the example above the bug? :(

@skelterjohn No, because the container is already named "serv", there's no linking required to get the name.

@skelterjohn I think you are mixing the default Service Discovery feature of user-defined networks with the --link functionality. The DNS based Service Discovery feature is NOT enabled on default bridge network.
The --link functionality as @cpuguy83 explained is per-container. And you are using it incorrectly. --link should be configured on the consuming container and not the serving container.
Also --net-alias is supported only on user-defined networks (not on default bridge network).
In your case, pls try using the --link in the consuming curl container.

I should give the full context of what I'm trying to do.
I'm on the team that created the Google Container Builder service, and the way people build containers using the service is they (via a list of build steps that can also do other things) run 'docker build' on our VM.
Now, a build step is just a container that we run for you. It so happens that we provide one with 'docker' as its entry point (and we run it with the docker daemon's socket volume-mounted in). Then, to build an image they use that container and specify the args. So, ['build', '.', '--tag=foo'], for example.
We also provide credentials to the build by spoofing the GCE metadata server, which is hosted at metadata.google.internal if you're already on a GCE machine. But we own that machine, so the "real" metadata server will not have credentials for the customer's build. Instead, we run another container that acts like the real metadata, but has customer information instead.
For build steps, we --link the metadata container to the step container, and so it looks like metadata is available and has the customer's information without them doing anything special.
Unfortunately, when the build step turns around and does a 'docker build', the containers created by 'docker build' to create layers do not have this --link. Asking them to specify a --network=cloudbuild is a little annoying for DX, considering this is supposed to be transparent and "just work".
So, I wanted to add it to the default network.
If aliases can't be used in the bridge network, is there some way to make another network the default?

I was just referred to https://docs.docker.com/engine/userguide/networking/default_network/build-bridges/ which seems to provide the guidance I seek.


[New template] NVIDIA NGC jupyterlab images.

WHY:

Try to use a good environment to build the Jupyter environment.

HOW:

Add template and Dockerfile into the repo.
Two templates: NGC-tensorflow and NGC-pytorch images.

Signed-off-by: simonliu<EMAIL_ADDRESS>

Close old and create new one.

Already update ngc rapids notebooks app template.


chore: rename five lemmas involving mathlib3 names

Commits can be reviewed individually.

In principle, I don't mind. In practice,

there are 160 lemmas with this (by loogle), so I'd prefer a separate PR
I'm not sure if there's consensus for this change; how do you read this zulip discussion?

Thanks!
bors r+
Changing set_integral to setIntegral seems like a good idea to me, but not in this PR.


Membership

https://www.24petwatch.com/lost-pet-protection/membership
https://www.24petwatch.com/ca/lost-pet-protection/membership

PR: https://github.com/hlxsites/24petwatch/pull/125

Done.

code merged: CSS
documents available on Sharepoint: US + CA


How can I run script part and get the content of the page

Steps to reproduce
Tell us about your environment:

Puppeteer version: 5.5.0
Platform / OS version: WSL Ubuntu / 18.04
URLs (if applicable): https://twitter.com/MarkRober/status/1256956499286298625
Node.js version: 12.16.2

What steps will reproduce the problem?
Please include code that reproduces the issue.
          try {
            const browser = await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});
            const page = await browser.newPage();

            await page.goto('https://twitter.com/MarkRober/status/1256956499286298625');
            await page.setJavaScriptEnabled(true);
            const fullContent = await page.content();
            await browser.close();
            console.log(fullContent.match(/.{10}og:.{25}/gi));
          } catch (err) {
            console.log('err:', err);
          }

What is the expected result?
[ 'property="og:site_name" content="Twitt' ,
'property="og:url"...',
'property="og:title"...',
'property="og:image"...'
]
What happens instead?
Only returns [ 'property="og:site_name" content="Twitt' ]
I used the puppeteer not the puppeteer-core. When I see this website with 'inspect' of the browser, I could see those 'og's, but I have no idea how I can get these using puppeteer (I am going to use 'open-graph-scraper' to extract og tag after letting puppeteer run javascript part and get the HTML afterward).
I tried to use page.setJavaScriptEnabled(true);, but it doesn't seem to do what I want. Is there any way that I can try in?
Thanks.

That regular expression in your .match() looks pretty brittle.
Looks like you're searching for things like:
<meta property="og:site_name" content="Twitter" />

Consider using a regular expression which keys on the structure of the content:
.match(/property="og:[^"]+"/g)
If you wanted the whole meta tag, you could search for:
.match(/<meta property="og:.+?[/]>/g)
However, your bigger problem is that page (as of today) has no tags that match
property="og:url"
property="og:title"
property="og:image"

So, Twitter has changed what you're scraping for.
Review the page content and change what metadata you're matching on?


build failed with darwin_386

this is the failed log:
##[error]/Users/runner/go/pkg/mod/github.com/elastic/gosigar@v0.10.5/concrete_sigar.go:20:11: cpuUsage.Get undefined (type Cpu has no field or method Get)
##[error]/Users/runner/go/pkg/mod/github.com/elastic/gosigar@v0.10.5/concrete_sigar.go:30:13: cpuUsage.Get undefined (type Cpu has no field or method Get)
##[error]/Users/runner/go/pkg/mod/github.com/elastic/gosigar@v0.10.5/concrete_sigar.go:49:10: l.Get undefined (type LoadAverage has no field or method Get)
##[error]/Users/runner/go/pkg/mod/github.com/elastic/gosigar@v0.10.5/concrete_sigar.go:55:10: m.Get undefined (type Mem has no field or method Get)
##[error]/Users/runner/go/pkg/mod/github.com/elastic/gosigar@v0.10.5/concrete_sigar.go:61:10: s.Get undefined (type Swap has no field or method Get)
##[error]/Users/runner/go/pkg/mod/github.com/elastic/gosigar@v0.10.5/concrete_sigar.go:67:10: p.Get undefined (type HugeTLBPages has no field or method Get)
##[error]/Users/runner/go/pkg/mod/github.com/elastic/gosigar@v0.10.5/concrete_sigar.go:79:11: fd.Get undefined (type FDUsage has no field or method Get)
##[error]/Users/runner/go/pkg/mod/github.com/elastic/gosigar@v0.10.5/sigar_darwin_386.go:11:12: undefined: sysctlbyname
you can see on this link:
https://github.com/glvd/accipfs/runs/573143054?check_suite_focus=true
i build my project with windows,linux,darwin
but only the darwin_386 was failed.

@godcong hi! did you fix this? it's happening to me too

@godcong hi! did you fix this? it's happening to me too
I posted it for a while、nobody cares about this. so i closed it.

I have not compiled the x86 version


loader updated

Description
Updated the loader and add a new and better UI-designed loader for a better user experience.
closing issue: #87

Summary by CodeRabbit

New Features

Integrated ClockLoader and BarLoader from react-spinners for improved loading animations across the app.

Enhancements

Updated loading animations on the Home, Login, and Signup pages for a more consistent and visually appealing experience.

Bug Fixes

Improved error handling within the login process to ensure smoother user experience during authentication.

??

@aryasoni98 sir please see it for review and give an update on it asap.

@aryasoni98 sir please see it for review and give an update on it asap.

check the error I share the log ss on commit . some function issue on Login and Home file .

@aryasoni98 sir please see it for review and give an update on it asap.

check the error I share the log ss on commit . some function issue on Login and Home file .

Okay sir will update this pr asap


Can't change OSC port

I manually changed VRChat's osc port, but now the problem is that I can't find any Settings in OyasumiVR to change the osc port, which seems to have been removed since version 11.0? I can't use anything that requires osc now.

Correct, I see the problem. The reason that this is no longer possible, is because OyasumiVR now automatically discovers VRChat's OSC server via OSCQuery. This is generally how OSCQuery is meant to work: various applications are able to discover each other without knowing each others ports and addresses in advance.
I've now tried changing the port through the launch parameter myself as well, and it turns out that VRChat's implementation of this is kind of a half-measure: When changing the port away from the default port (9000), VRChat keeps advertising port 9000 over OSCQuery, even though this is no longer correct. It looks to me like they have just hardcoded this value. ...I would personally consider this a bug in VRChat, not OyasumiVR.
I've submitted a bug report with VRChat, as this is something that should be fixed on their side: https://feedback.vrchat.com/bug-reports/p/oscquery-vrchat-reports-the-incorrect-listening-port-for-osc-when-changing-it-vi. If you could give it an upvote that would be appreciated.
In the meantime that of course is of no use to you, so I'll see if I can add some flags to OyasumiVR to override whatever port VRChat advertises. Until I get that feature out, your only option is to leave VRChat running on its default port 9000.

I didn't get to adding the port overrides, but it seems like VChat has fixed this issue now in their new beta build 2024.1.1, build 1400. I'm sure it will make its way to the release version soon. As such, I'll be closing this issue.


Very good work. Can I extract this PIM module separately and add it to my own model?

Sure! And if you have any questions, please let me know. You can also send an email to<EMAIL_ADDRESS>

Have you successfully integrated into a module? If so, can I use it in my code？

We update our code, thanks! --> how to build model


Update manage-integration-runtimes.md

Update the Azure Data Factory Integration runtime to Microsoft Integration Runtime.   Copy the OS Details and  first 2 bullets from this section https://docs.microsoft.com/en-us/azure/data-factory/create-self-hosted-integration-runtime#prerequisites will help

@seaswara : Thanks for your contribution! The author(s) have been notified to review your proposed change.


chore: add release-please to ci

Pull Request Test Coverage Report for Build 883179999

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 879602544:
0.0%

Covered Lines:
106

Relevant Lines:
106

💛  - Coveralls


SAML SSO exploration

Today we are using keycloak broker under the hood to integrate the SAML2.0, we should try to avoid this dependency and try to have generic implementation using spring security.

Closing this as we havn't find any shortcomings with the current approach. Also regarding the SSO for embedded apps SAML behaviour will be similar to the OIDC.