When collapsing a thread browser should return to top of the next thread

Currently when you collapse a thread that you are half way through your screen position stays the same and the following threads get pulled up, leaving you looking at the middle of some later thread.  Would be great if thread collapsing moved you to the beginning of the next thread.
(Otherwise awesome, makes ACX comments bearable.)

Great idea; thanks for suggesting it!
I implemented this slightly differently: by keeping the collapsed comment itself into view. This has the advantage that it's clear which comment was just collapsed, and makes it easy to expand it again without having to scroll up, in case it was collapsed by mistake. It still has the desired effect of not scrolling past comments below the collapsed comment thread.


Train to reconstruct mesh of human from RGB image

Is it possible to train the network to reconstruct human mesh? It seems that this is possible but maybe you've tried that already? Any information about the result if so? Thanks.

Hi,
Yes it is possible and we have tried that. However, human meshes are usually various in their pose, it is hard for an encoder-decoder like structure to generalize well for unseen pose. We think a better structure is crucial for this task.


converting .tflite model to edgetpu.tflite

Hi,
im trying to convert a .tflite model to an edgetpu.tflite model. the tflite model works fine, but after converting using the edgetpu_compiler it results in relativly low detection scores and therefore just a few detection boxes.
tflite inference example

edgetpu.tflite example (unsing the detect_image.py from examples)

command i used
edgetpu_compiler model.tflite
results in
Edge TPU Compiler version 15.0.340273435

Model compiled successfully in 1042 ms.

Input model: model.tflite
Input size: 4.18MiB
Output model: model_edgetpu.tflite
Output size: 4.77MiB
On-chip memory used for caching model parameters: 3.21MiB
On-chip memory remaining for caching model parameters: 3.78MiB
Off-chip memory used for streaming uncached model parameters: 0.00B
Number of Edge TPU subgraphs: 1
Total number of operations: 158
Operation log: model_edgetpu.log

Model successfully compiled but not all operations are supported by the Edge TPU. A percentage of the model will instead run on the CPU, which is slower. If possible, consider updating your model to use only operations supported by the Edge TPU. For details, visit g.co/coral/model-reqs.
Number of operations that will run on Edge TPU: 112
Number of operations that will run on CPU: 46
See the operation log file for individual operation details.

i see that not all ops are supported by the edgetpu runtime and are executed on the cpu but, but shouldn't be the output the same as the tflite one.
Models, scripts and resources to reproduce:
tflite2edgetpu.zip
to run tflite model
python3 tflite_run.py
to run edgetpu.tflite model (its the detect_image.py from the examples)
python3 detect_image.py -m model_edgetpu.tflite -i A00147.png -o out.png -l labels.txt

@ulrichMarco You are running this on the Dev board or on any other Coral device ?

@manoj7410 Running it seperately on 'Coral Usb Accellerator' and a 'Coral M.2 Accelerator with Dual Edge TPU' both produce similar outputs.

@manoj7410
Addition:
To get a fully compatible edgetpu model i followed the steps from https://coral.ai/docs/edgetpu/retrain-detection/ with my dataset.
After computing the model i am facing still the same issue.
didnt train it the full 50k steps canceled at 41k to test it.
the new models: models.zip
Correct me if im wrong, but because the tflite model is working fine:
-The problem shouldn't be in my .record files or the scripts.
-And because I used two devices on different systems to test it, (Could you tell me if the problem is happening to you too) the problem shouldn't be in my hardware or drivers.
-So the last error spot i can imagine is the edgetpu_compiler

@manoj7410
Anything new?
Can you confirm that you get similar results?

@ulrichMarco Unfortunately, my linux laptop got crashed while training a model. I am yet to reproduce this issue at my end. Will get back to you soon on this.

@manoj7410
sry i dont want to be too impatient, but the problem persists.
Were you able to reproduce the issue?
Can you suggest a solving strategy?

@ulrichMarco I was able to reproduce this and checking within the team regarding what can be the reason for this.

@ulrichMarco it seems like there is a mis match in the post processing steps of detect_image.py and tflite_run.py
If you can change tflite_run.py and plug in edgetpu model you get same results for both the models.
print()
#interpreter = tflite.Interpreter('model.tflite')
interpreter = tflite.Interpreter('model_edgetpu.tflite', experimental_delegates =[tflite.load_delegate('libedgetpu.so.1')])
interpreter.allocate_tensors()
Can you try this and conform if the results of both models match ?

@Naveen-Dodda
i can confirm that the results of both models match. In some cases the detection scores are off by a few percent or the detectionboxes are off by a few pixels, but this is ok for my use cases.
Now i am just wonder why this problem is happening, because the detect_image.py is coming from the official detection example. And the example datasets are working fine with it, but as soon as i tried to use my custom dataset this error/problem occured. So maybe the example needs an update? I explicit used the example, because i am new object detection on edgetpu and wanted to make sure that some code i write isnt the problem

@ulrichMarco Are you still facing any issues while running models on the edgetpu ?

No the models are working now.


Impossible to munge only core GL entries into single class.

The GL bindings here are very, very, very annoying to use. Please apply sanity to these bindings.
I want a single static class munging all GL1.1 --> GL3.3 entries and defines. I DO NOT want to do GL15. and GL30.. Importing everything static is not a solution.
Please provide an accumulated GL3.3 entry or give users an easy way to accumulate. Having separate non-interfaced entries for each GL version when the entry is first introduced is just absolute madness, because there is no way to have a core profile not have the compability entries.
For example org.lwjgl.opengles.GL33  does not contain a GL33.GL_ARRAY_BUFFER define. you have to use GL15.GL_ARRAYBUFFER. However, importing GL15 imports all of the deprecated stuff in GL15 not in GL33 core. That is suboptimal.

For example org.lwjgl.opengles.GL33 does not contain a GL33.GL_ARRAY_BUFFER define.

Thats probably because org.lwjgl.opengles.GL33 does not exist. In OpenGL, GL_ARRAY_BUFFER is available under org.lwjgl.opengl.GL33. In OpenGL ES (the package you imported), it is available under org.lwjgl.opengles.GLES20. The javadoc covers this fully.

The recommended way to use LWJGL is via static imports. If you need functionality from a particular OpenGL version, you must explicitly import it. This:

is not a big deal. All tokens/functions are one <ctrl+space> away in modern IDEs, without any imports present.
protects from unintentionally using functionality from a higher OpenGL version than intended.
is better for exploring such a massive API.

Best we could do is make GL12 extend GL11, GL13 extend GL12, and so on. Using inheritance for static functionality is not a Java best practice, but it compiles and works. This way you could do an import static org.lwjgl.opengl.GL33.* and all functionality up to that version will be available.

I disagree.
It is not a big deal for your use cases, but that doesn't make the bindings any less terrible. It's just terrible in a way that doesn't affect the way you're using it.
This protects from unintentionally using functionality from a higher OpenGL version, but does not protect from unintentionally using a deprecated function from lower OpenGL when creating a core context. glBegin() doesn't exist on a core 33 context, but importing GL15.* gets me glBegin() :(
I argue static org.lwjgl.opengl.GL33.* should have EXACTLY all the entries in core 3.3, nothing more nothing less. For a library that claims to bind OpenGL, is this too much to ask? :P

You can create a forward compatible context by calling GL.createCapabilities(true). This will prevent LWJGL from loading deprecated functions. You can read this in the JavaDoc.

Are you actually planning to use LWJGL for a real project? Just asking, because the confronting tone in your posts so far make it apparent that you don't want to do anything real with LWJGL, but instead just tell how terrible you think everything is and to grind up on such minor things as the binding strategy used in LWJGL.
Why does it bother you to have glBegin when you import GL11 for GL_ARRAY_BUFFER?
In my opinion it does not make the binding terrible or hard to use in any way.
It's not like you use LWJGL to actually learn OpenGL and help you avoid its pitfalls. There is better documentation for learning OpenGL than the IDE's auto-complete on the LWJGL API.

Hi,
The forward compat would help by crashing on null funcptr. I don't see how LWJGL's bindings can not have these functions in the first place by exposing only the core profile.
I do not intend to sound confrontational. I apologise if I sounded like that. I do intend to use LWJGL, I am complaining because I hope to make LWJGL better. If I didn't care then I wouldn't even post here. I am not learning OpenGL.

Instead of trying to find ways to extend a LWJGL class to bring its GL methods into scope, why didn't you just search GLES20. in your OpenGL ES application sources and replaced it with the empty string and then just import static org.lwjgl.opengl.GLxx.* for every needed GLxx class.
That'd work too, I guess. No need to manually lookup the correct GLxx class for a given OpenGL function and use GLxx.gl....
I am not saying which way is best, just trying to plot a way for you to work with the current binding strategy.

I ended up manually plugging every ES2 entry to the equivalent GLxx., even though I would've liked to be able to just extend GL33core or something and called it a day. I couldn't extend multiple classes from Java, and the GL* bindings aren't interfaced. Guess I probably should've used a python script or something to do that, but ES2 wasn't that big.

The use case here can probably be made easier if I just did a bunch of find-replace operations across the app code itself. But the fact that there is no core GLX.X interface in LWJGL is still hardly a selling point, no matter how minor to most people.

Having interfaces implies having instances that implement those interfaces. This will never happen in LWJGL. You'll never see C bindings that look like gl.glBufferData(...). Many other libraries work like that, but the current style has been LWJGL's differentiating factor from day one.
Especially in LWJGL 3, we want the Java code to look as close to the native equivalent as possible. We want the code to feel natural to both Java developers and to developers coming from system languages. The problem of copy/pasting Android code and have it work immediately is far less important and doing the same with native code.
Do you have any input on my suggestion above? (having GL33 extend GL32, GL32 extend GL31, and so on)
On dropping deprecated functions: As @SilverTiger mentioned, a forward compatible context will not load deprecated function pointers. You do not risk crashing the JVM either, there are runtime checks for such functions (unless -Dorg.lwjgl.util.NoChecks=true is specified). If you do not want to see such functions at all (e.g. in IDE auto-complete lists), you can always clone LWJGL locally and change the code generator to exclude deprecated functions. It should be trivial, but let me know if you need help with that.

Having interfaces implies having instances that implement those interfaces. This will never happen in LWJGL.

Praise Spasi \o/
I agree, its not a big deal. And extending classes just to import static functions is plain fugly, and a bad practice as it is. I doubt anyone here wants to encourage that kind of usage.
It'd be nice to have a "import org.lwjgl.opengl.CoreGL33.*" and get all the stuff in core OpenGL 3.3 but its far from a dealbreaker.

could make a class that only contains a wrapper method for the core functions.

I agree, its not a big deal. And extending classes just to import static functions is plain fugly, and a bad practice as it is. I doubt anyone here wants to encourage that kind of usage.

I was tempted to shout yes, since it would kind of make sense that newer versions extend older ones, but a @dustContributor mentioned, it's probably inappropriate for static methods.
I still don't thin static importing everything is the greatest of all ways to handle this, especially for people who do not know OpenGL that well and try to find out how the whole thing works together. On the other hand, there is probably no perfect solution to bind Java methods to native calls, to the best course would be to leave it alone and focus on more useful things.

I'm not asking for the incremental versions.
OpenGL 3.3 core is a very specific API. When you create a 3.3 core context you get this exact set of functions and definitions and nothing more, nothing less. Anything more is illegal without extensions. Calling GL2 functions will certainly break the spec. All I wanted is a binding to 3.3 core, nothing more, nothing less, and if there's a GL2 function that doesn't actually exist in the driver for 3.3 core, why should it exist as a function in my bindings?
LWJGL3 effectively models compatibility. It does not bind core context. It binds a superset of core context, but that's not binding the core context.
FWIW I worked for and with the OpenGL Khronos group as member and part of the vendor driver team, and my ex co-workers would probably agree that an OpenGL binding library should have the ability to bind core.
For example, glbinding can just #include <glbinding/gl32core/gl.h>, and get the functionality of the GL 3.2 core exactly, nothing more nothing less. glBegin() is not part of the GL 3.2 core and calling that is illegal even though it works in a subset of drivers.

glbinding can just #include <glbinding/gl32core/gl.h>, and get the functionality of the GL 3.2 core exactly, nothing more nothing less.

Java is not C/C++. There's no preprocessor that could accomplish what glbinding does. The only possibility so far has been to create a custom LWJGL build for your application.
Anyway, there are two enhancements being suggested here:

Core versions of the existing GL bindings, without any compatibility profile features (functions & constants). This is applicable to OpenGL only.
Being able to use all GL11 - GLXX features by statically importing only the GLXX class. This is important for OpenGL because it's old and has many versions, but it's equally applicable to AL, ALC, CL, EGL, GLX, GLES, VK.

I've been doing some experiments and it looks like we cannot easily have both 1 and 2 without breaking compatibility of the OpenGL bindings. The cleanest solution seems to be adding a separate class hierarchy GL11Core, GL12Core, ..., GL46Core and an LWJGL application uses either the existing classes or the core versions, but never both. Any other approach that I tried was either binary incompatible (apps compiled with 3.1.6 wouldn't work with 3.1.7) or source incompatible (javac is too sensitive about ambiguous static imports, even if all resolve to the same method/field in the same class).
If anyone has a better suggestion, please let me know. If a solution is clean enough that justifies breaking changes, we could defer it to LWJGL 3.2.0.
Having tried this in practice, I can see the value of having clean bindings for the core profile, as @hypernewbie suggested. There's a significant cleanup of the API, not only of deprecated functions, but also of constants. On the other hand, I still believe that being able to access all GL versions up to the version that has been statically imported is not terribly exciting. But if it helps new users, then why not.
So, I'm looking for feedback on the available options:

Add the GL11Core, GL12Core, ..., GL46Core classes, with only core profile functionality and no hierarchy between them. Users will have to statically import each one separately.
Option 1, but each core class extends the core class of the previous OpenGL version. Users statically import only the core class with the minimum required OpenGL version, which provides all functionality up to that version.
Option 2, but do the same for the current, "compatibility profile" classes too (a separate hierarchy).
Option 3, but make AL, ALC, CL, EGL, GLX, GLES, VK hierarchical too.
X. Your idea here.

Btw, instead of starting with GL11Core, we could merge 11 to 31 and start with GL31Core, since that was the first version that dropped the deprecated functionality. Or even skip that and start with the more practical GL32Core.

A binary incompatibility has been reported: kotlin-graphics/imgui#42. The library has been compiled with 3.1.7 snapshot but the application runs on an earlier version. The problem is that javac compiles:
import static org.opengl.GL33.*;
// ...
glGetInteger(...);

as GL33.glGetInteger(...) instead of GL11.glGetInteger(...).
There are workarounds if the library wants to support earlier LWJGL versions, but still, I'm considering bumping the next release from 3.1.7 to 3.2.0, to signal the potential for incompatibilities.

I know this is closed but I want to say that I started my project in 3.1.7 and ran into the same questions as OP. The new 4xC classes really made it easier. 👍


Deploy docs to GitHub pages

This should check the docs on a pull request and only deploy after a push to master. It will deploy on the gh-pages branch with only a single commit history. We will need a gh-pages branch on the exawind-builder repo but I don't have access to create one.

Hmm, I wonder why the action isn't running here. It runs on my fork.


Middleware feature

Is it possible to implement a middleware feature like the addMonitor method? Like if i want to handle every response in a certain way. Now i have to add to every request a .then

That's what addMonitor does, but I think I might not reading you right.
Are you looking for an opportunity to change the response somehow before it gets to your normal path of execution?

Yeah thats what i want to do. I have an api which sends some useless data so i want to clean all responses.

Now i do this for all of my api requests:
all() {
	return this.api.get('/business_stores').then(CleanupResponse);
}

But it would be nice if i could do something it like this:
this.api.addMiddleware(response=>{
	return CleanupResponse(response);
});

This middleware would be called right after the response is received from the server and passed to the first then.

Ok, new version is out.  It has this feature now:
https://github.com/skellock/apisauce#adding-transforms
Thx.

Wow that was fast. Thank you so much.

Great work @skellock


v1.0.0 test setup

Hey, @AminoffZ i've setup a simple ci/cd and npm tests you can view the code in the ci/cd branch, but before i put in any pull request i'm trying to see if my code is functional or not and for that it needs a few things if you'd be kind enough to set them up when you're free:

secrets.NPM_TOKEN which will enable us to npm publish after a successful CI/CD that token can be fetched from https://www.npmjs.com/ access tokens tab
Enable dependabot
Enable github actions

Hi @mAmineChniti, thank you. I'm not too familiar with github's devops but I think dependabot should be enabled now and the NPM_TOKEN added as a repository secret from this account. I think github actions are enabled, maybe. I'm going for holiday break now so might not respond in the coming week. Thanks for your contributions and happy holidays :)

Thank you for setting this up for me and happy holidays to you too.


Services_Styling

Fantastic! Only few things are left for changes.

Change the color of navbar container, Pick any color that matches background photo.
Make the sidebar opacity 75

Sure thing !


Replace to gopkg.in/yaml with github.com/goccy/go-yaml (note)

Fixes #8822

I think we need to see https://github.com/goccy/go-yaml/issues/540 fixed before merging this.

Uploading Guide_to_OMB_Website.pdf…

With https://github.com/goccy/go-yaml/issues/461 closed, I must also close this. For now, at least. I may revisit this if once I understand it better / find a workaround on Hugo's side. But re. Hugo's security policy, the templates are trusted, the content files are not. It's fairly common to print/marshal (e.g. jsonify) front matter values. So, even if the Go maps themselves isn't big, one could easily imagine the rendered output blow up with front matter constructs like the below:
---
title: Biiiig Front Matter
a: &a [_,_,_,_,_,_,_,_,_,_,_,_,_,_,_]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h,*h]
---

I'll reopen; I have worked with this library in another project, and having those anchors/aliases is really useful. I will try to figure out a way to detect these anomalies in the Go map.


Add async version for importing libs.

Fix issue with grammarLocations in generated parsers (see #14 for discussion)

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

Project coverage is 100.00%. Comparing base (f00709a) to head (7309959).
Report is 9 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff             @@
##             main       #15      +/-   ##
===========================================
+ Coverage   98.23%   100.00%   +1.76%
===========================================
  Files           1         2       +1
  Lines         113       230     +117
===========================================
+ Hits          111       230     +119
+ Misses          2         0       -2

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


Add INT16 support in modify_model_interface

Added support for 16bit quantized models in modify_model_interface.cc
Added extra arguments for inputing 16bit quantized models in modify_model_interface_main.cc
Modified 2 of the unit tests to be parametrized and covered 16bit models in modify_model_interface_test.cc

Related to #36632

@TamasArm Thank you for your contribution. Can you please sign CLA? Thanks!

@gbaned

@googlebot I signed it!

@TamasArm Can you please resolve conflicts? Thanks!

Is there anything else I can do to help move this forward?

Gentle ping: @MeghnaNatraj @renjie-liu

@TamasArm could you merge the latest changes? There is just one merge conflict.
Otherwise this looks good to me as well!
@jianlijianli Can you take a final look at this before we merge these changes?

Bear with me, I am trying to fix the issues with extra commits on my log after a failed rebase, sorry about that!

Fixed now, it's free to review again!

@akarmi Yes, we should be making the changes in the python equivalent code as well.
@TamasArm If you're not familiar with this, let us know and I can make this change later.
If you're interested to try: We have a python wrapper that internally invokes the c++ library modify_model_interface.cc which you have updated. The workflow is: User runs modify_model_interface.py --> modify_model_interface_lib.py --> pybind (python to c++ connection) file which ultimately invokes modify_model_interface.cc
To support your changes in python, you need to update modify_model_interface_constants.py to add INT16 and a test to create an INT16 quantized model and validate this in modify_model_interface_lib_test.py
If this is confusing, do let us know and we can update it on our end :)

@MeghnaNatraj Thank you for the explanation! It seems clear to me, I'll get started on it right away, I'll try to be done with it by Monday night. Should I do it in a seperate PR?

@TamasArm Yes, let us add this change in a separate PR. I'll go ahead and work on merging this change.


chore: release 3.2.5

:robot: I have created a release *beep* *boop*
3.2.5 (2019-07-26)
Bug Fixes

deps: update dependency @google-cloud/storage to v3 (#275) (aa7eeaa)

This PR was generated with Release Please.

Release is at https://github.com/googleapis/nodejs-language/releases/tag/v3.2.5

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Add a Channel Handler that closes the channel

Motivation:
Because of #600, many users will start leaking Channels because they
don't close on error.
Modifications:

Add ChannelHandlerError
Add ChannelHandlerErrorTest

Result:
User will have access to an handler to use to automatically close
the channel in case of unhandled errors
Closes #841.

@Lukasa All done, thanks for the feedback!

@normanmaurer @Lukasa Fixed! Sorry I should have pinged you!

@Lukasa @normanmaurer all squashed and ready for another review 🦸🏻♂

@swift-nio-bot test this please

@Palleas your pull request uses windows newlines (\r\n) instead of UNIX newlines (\n) and hence it doesn't pass the license header check tests. Could you run dos2unix Tests/NIOTests/NIOCloseOnErrorHandlerTest.swift Sources/NIO/NIOCloseOnErrorHandler.swift and add all the changes to your PR?
You might also want to fix your text editor to produce UNIX newlines

Uh, how did that happen 🤨 I’ll fix that today!

@Lukasa @weissi all done!

@swift-nio-bot test this please

@swift-nio-bot test this please


Add licensing information

I couldn't see any mention of what license the package is made available under. Could you add a LICENSE file (https://help.github.com/articles/adding-a-license-to-a-repository/)?

@tomasen is it possible to add a LICENSE?

Unfortunately I'm being forced to remove realip from my company's code because of this issue. It would help me tremendously if this could be resolved with a permissive license. BSD or MIT is my personal preference, but of course others may have a different view!

done

Thank you!


telco-hub: fix to allow unknown CAs in an S3 endpoint and some typos

Without the fix the observability-thanos-store-shard-x-x pods stay in CrashLoopBackOff status due to connection refused to the S3 endpoint.
Also, the format has been corrected in some Markdown lists.

After discussion, yes this is required.
Next step is to update this PR (or open a new PR) with the actual CRs required to support the bucket (secret, bucket claim, etc).
cc: @jmontesi , @jgato

Closing this PR as I missed that the documentation for the endpoint field says "Enter the URL without the protocol", so assuming a standard HTTP transaction would occur there is no need to add this extra field to allow unknown CAs.
I will put up a new PR with the CRs required to create the MultiClusterObservability resource.


close(filehandle) is not executed.

It looks like close(filehandle) constructs are not executed and filehandles are not closed:
# Set soft limit of open files to 30.
❯  ulimit -S -n 30C

# Frawk runs out of file handles.
❯  frawk 'BEGIN { for (i=0; i<=50; i++) { echo_cmd = sprintf("echo %d", i); while((echo_cmd | getline line) > 0) { print i, line }; close(echo_cmd); } }'
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
failure in runtime unexpected error when reading error status of file: [src/runtime/mod.rs:410:27] failed to crate command for reading: Too many open files (os error 24). Halting execution

# gawk closes the file handles as expected.
❯  gawk 'BEGIN { for (i=0; i<=50; i++) { echo_cmd = sprintf("echo %d", i); while((echo_cmd | getline line) > 0) { print i, line }; close(echo_cmd); } }'
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50

# When removing the file handle closing part, gawk also runs out of filehandles:
❯  gawk 'BEGIN { for (i=0; i<=50; i++) { echo_cmd = sprintf("echo %d", i); while((echo_cmd | getline line) > 0) { print i, line };  } }'
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
gawk: cmd. line:1: fatal: cannot open pipe `echo 26' (Too many open files)

There is also a typo in the error message:
Err(e) => err!("failed to crate command for reading: {}", e), to Err(e) => err!("failed to create command for reading: {}", e),

NB: the above commit doesn't fix the problem on its own. I'm looking into it, though.

I think that last change should fix the issue. Thanks for the easy-to-reproduce failure case!


Enhance with hosted Blazor WASM debug scenario

Per Debugging Blazor WASM after publish: https://github.com/dotnet/aspnetcore/issues/41033.
Dev:

But the problem is that, when I publish it (both with Release or Debug configuration), and when I launch the output executable, Alt+Shift+D throws an error on the browser console:
Cannot start debugging, because the application was not compiled with debugging enabled.

Javier:

You need to make sure you enable DebuggerSupport as well as CopyOutputSymbolsToPublishDirectory when you publish

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

ID: ec2f61c7-9f51-6735-e328-3c7b495d70c3
Version Independent ID: 4d06e565-282d-6387-aa90-cb2c2986d35a
Content: Debug ASP.NET Core Blazor WebAssembly
Content Source: aspnetcore/blazor/debug.md
Product: aspnet-core
Technology: aspnetcore-blazor
GitHub Login: @guardrex
Microsoft Alias: riande

@captainsafia ... We never addressed published, hosted Blazor WASM for the prior rounds of content work in the Debug Blazor WebAssembly topic. Do you have any feedback on this before I take a stab at adding a section of coverage from Javier's PU issue remark?

We never addressed published, hosted Blazor WASM for the prior rounds of content work in the Debug Blazor WebAssembly topic. Do you have any feedback on this before I take a stab at adding a section of coverage from Javier's PU issue remark?

Documenting the workaround should be sufficient. I would emphasize that users should make sure that flag is only enabled for local, published apps and not pushed to production deployments.


Add a method to check if a date is convertible or not

Description
This PR proposes a method to check if a given date is convertible to era or not. Users can handle unsupported old dates by calling this method without raising an exception. This will be a simple way rather than capturing an exception raised by to_era method.
Example
require 'era_ja'

Time.mktime(1868,9,7).era_convertible? #=> false
Time.mktime(1868,9,8).era_convertible? #=> true

Notes
This PR is aimed to solve a same issue with #18.  Applying both changes would be better and cause no problems.

Thank you for your response!
I will release new version. (probably 1.1.0)
I'm looking forward to the next PR 😄


Error when extract mooring stiffness matrix

Dear all,
I’m not familiar with pyMAP, and when I hope to extract mooring stiffness matrix through Ex3_StiffnessMatrixFromFST.py. However a question happends as shown below
Part from Ex3_StiffnessMatrixFromFST.py
fstFilename = os.path.join(scriptDir, 'spar\Main.fst')
print(fstFilename)
# moor = pyMAP()
moor = pyMAP(fstFilename)
error line:  moor = pyMAP(fstFilename)
TypeError: pyMAP.init() takes 1 positional argument but 2 were given
And I check the pymap.py file as shown below and it seems that the init( self ) command needs none argument which obeys the code “moor = pyMAP(fstFilename)”. Could anyone tell me how to solve this?
Part from pymap.py
class pyMAP(object):
def __init__( self ) :
    self.ierr = c_int(0)
    self.status = create_string_buffer(1024)
    print(self.ierr)
    print(self.status)

    self.f_type_d       = self.CreateDataState()
    self.f_type_u       = self.CreateInputState( )
    self.f_type_x       = self.CreateContinuousState( )

What have to be noted are that I failed to create wisdem-env through the “mamba create env” command, so I use the “pip install wisdem” and “python setup.py develop” in the base environment and then run Ex3_StiffnessMatrixFromFST.py.

There hasn't been much activity in pyMAP in a while because there has been less use of MAP as it was dropped from WISDEM and a secondary option in OpenFAST.  I see there was a bit more activity in the dev branch compared to master.  I would suggest giving that a try first.

Thank you for your comment and it really works. I have another question. The coordinate of the point in the code as shown below should be (0,0,+70) if I hope to extract stiffness matrix with reference to a point at 70m below the still water level, is it right?
K, f0 = moor.stiffness_matrix(epsilon=1e-5, point=(0,0,70))

I do not know pyMAP or MAP well enough to answer this one.  @mattEhall - do you?

Have you tried the dev branch? I should have included additional functions and updates so that matrices can be translated from oe point to another with error.
To extract the stiffness matrix at a given point the syntax is now:
https://github.com/WISDEM/pyMAP/blob/dev/examples/Ex1_StiffnessMatrixAndLoads.py#L50
Which uses a "point" as argument, to know where the loads have to be translated to, and it makes use of the values of the forces at the operating point via the function  f_op that I added to the MAP library and the python interface:
https://github.com/WISDEM/pyMAP/blob/dev/src/pymap/pymap.py#L779
This dates back to quite some time now...
I personally use the following version of the python code (not sure how much difference it has with the dev branch):
https://github.com/ebranlard/welib/blob/dev/welib/moor/mappp.py
and I typically use it like this:
https://github.com/ebranlard/welib/blob/dev/welib/yams/windturbine.py#L958

Hi,
Thank you for your kindly reply. I have tried the dev branch and I can extract mooring stiffness matrix now. Also the matrix can be translated from one point to another (https://github.com/WISDEM/pyMAP/blob/b75e20ab5553a858cae19ea58d3c3b6ae31f1238/examples/Ex3_StiffnessMatrixFromFST.py#L20). And the matrix matched the results provided by OpenFAST as shown below. And I really appreciate the information you shared.
Thank you again and have a nice day.
Mooring stiffness matrix from pymap
41181	0	0	0	-2815428	0
0	41181	0	2815430	0	0
0	0	11941	0	0	0
0	2815431	0	310785098	0	-49
-2815429	0	0	0	310784963	0
0	0	0	-81	0	11566656
Mooring stiffness matrix from document of OpenFAST
41180	0	0	0	-2821000	0
0	41180	0	2821000	0	0
0	0	11940	0	0	0
0	2821000	0	311100000	0	0
-2821000	0	0	0	311100000	0
0	0	0	0	0	11560000


"PublicAccessNotPermitted" with New-GuestConfigurationPolicy

I am getting "Invoke-WebRequest: PublicAccessNotPermittedPublic access is not permitted on this storage account." when trying to create a new Azure Machine Configuration policy, it doesnt seem right that it requires that the Storage Account must be public?
Reviewing the code, I dont see any authentication parameters on the code that grabs the file?
https://github.com/Azure/GuestConfiguration/blob/80dd21616cf5553851193ae6d30e6f15c3b6a962/source/Public/New-GuestConfigurationPolicy.ps1#L287

@ElSrJuez Hi there, just happened to notice this issue as I was browsing others.
To me the error sounds more like a network issue and not an authentication issue.
Things I would check:  does the storage account have a private endpoint?  does the fully qualified name for the storage account resolve to the private IP of the storage account's private endpoint from the location where you are running the New-GuestConfigurationPolicy command?
This should work with a private storage account on which public access has been disabled; this is how we have it set up here.  We have a fully private storage account and using Entra ID authentication initially to fetch the storage account key, which is used for subsequent operations (generating SAS key for the guest policy, etc).
Hope that helps... :)


CO-11512 Install right_aws_gem with coupa_gem

JIRA

Main JIRA ticket

Summary of issue
Update right_aws gem version
Summary of change

Updated right_aws gem version
Install gem using coupa_gem LWRP

Testing approach

[x] Manual Test
More on ticket

Merging as got 2 approvals.


Sim4life PROD: private static EC2

Actions needed:

migrate prometheus data
migrate redis data
copy traefik certificates to new nodes
update simcore and ops LB

PR solving this issue: https://git.speag.com/oSparc/osparc-ops-deployment-configuration/-/merge_requests/955
Close once this PR is merged


Use upstream patterns to fold affine.min ops in loops

This commit adds wrapper patterns to call upstream affine.min
canonicalization utilities and perform folding for them.
Wrapping is needed because we tile and distribute at the same time,
while the upstream pattern only expects tiling to function. So the
pattern "discards" the distribution aspect and feeds the tiling
aspect into the upstream pattern to make it work.
This makes it possible to replace some of the homebrewed ad-hoc
patterns. The SPIR-V side is cleaned up for this; but we don't
delete all such affine.min patterns yet; they are also relied
on in other backends and can be removed once those are migrated
over.

I think this pattern should be sufficient to replace the remaining ones (populateAffineMinSCFCanonicalizationPattern, populateAffineMinCanonicalizationPattern). Those are still used in LLVM CPU/GPU; I'll leave to @ThomasRaoux to double check that it works and remove those. :)


Error loading key "(stdin)": error in libcrypto

I get this error no matter what.
Double checked my key and added newline at the end of secret SSH_KEY:
-----BEGIN OPENSSH PRIVATE KEY----- <content> -----END OPENSSH PRIVATE KEY-----\n

Tried versions 0.9.0, 0.8.0, 0.7.0 - the same result.
- name: Setup SSH agent for git
  uses<EMAIL_ADDRESS>  with:
    ssh-private-key: ${{ secrets.SSH_KEY }}

Any help appreciated.
Thank you

Any update on this? I'm facing the same problem.

For me the issue was, that I've been adding a newline at the end of SSH key before submiting it in github page on Windows OS, that was adding \r\n, instead of just \n. After I edited this SSH key in nix editor, added single \n and then pasted it as is in browser, it all worked.
It's insane, libcrypto's logerror is a nightmare.


Text Input Component not holding state

Describe the bug
After entering text in the Text Input, the input does not hold its filled state. This causes the label to revert back to its :empty position, clipping the inputted text.
To Reproduce
Steps to reproduce the behaviour:

Go to docs.royalnavy.io/components/forms/input
Click on the Develop Tab
Enter text into input and then click off to remove focus from the input
The label reverts back to its starting position, over the top of the entered text.

Expected behaviour
The label does not revert to its default state.
Screenshots

Most likely the input needs to be put in a formik form in the docs. The field itself is stateless, it's container provides the value as a prop and handle onChange events to that value


fixes issues introduced in PR#2795

Pull Request Functional Test Report for #3384 / 7ff8639931dc30890363179d04819c253cc5309b
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

TE-3.7: Base Hierarchical NHG Update
df72f001
Log

Cisco 8000E

TE-3.7: Base Hierarchical NHG Update
1bbe49f0
Log

Cisco XRd

TE-3.7: Base Hierarchical NHG Update
fd12ce77
Log

Juniper ncPTX

TE-3.7: Base Hierarchical NHG Update
b2238a22
Log

Nokia SR Linux

TE-3.7: Base Hierarchical NHG Update
16254b06
Log

Openconfig Lemming

TE-3.7: Base Hierarchical NHG Update
80422399
Log

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

TE-3.7: Base Hierarchical NHG Update

Cisco 8808

TE-3.7: Base Hierarchical NHG Update

Juniper PTX10008

TE-3.7: Base Hierarchical NHG Update

Nokia 7250 IXR-10e

TE-3.7: Base Hierarchical NHG Update

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>0
Details

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 55.252%

Totals

Change from base Build<PHONE_NUMBER>2:
0.0%

Covered Lines:
1983

Relevant Lines:
3589

💛  - Coveralls

@self-maurya  pull 2795 only removes interface configuration associating with network instance but not deleting any interface configuration.
Here in this pull we are adding interface config again .  but this is not required right ?

I'd agree with @cprabha , it feels like this should be a deviation for the vendor that needs it.
cc @dplore

@self-maurya pull 2795 only removes interface configuration associating with network instance but not deleting any interface configuration.
Here in this pull we are adding interface config again . but this is not required ?

This current setup seems to be working for Juniper as well.
And if I don't remove the vrf-1 then it works for other vendors except Juniper.

be working for Juniper as we

Sure,  It will be helpful if this code can be moved under deviation.

be working for Juniper as we

Sure, It will be helpful if this code can be moved under deviation.

I had internal discussion with @dplore and few other folks.
As per Darren, the interfaces should be removed from the NI since the delete of the /network-instances/network-instance/ explicitly is a parent of the NI to interface mapping, so the vendor should be removing the interface configs on NI deletion.
@cprabha based on this, could you please raise a PR to introduce a deviation for Juniper.
Sample code
if !deviation {
    // reconfigure the interfaces
}

cc: @dplore


Re-implement image life-cycle management

Previously, successfully updating VM image metadata was treated as
optional (errors ignored).  This resulted in unrelated failures
(e.g. auth. token expiring) going unnoticed.  Consequentially VM
images that were in-use got deleted without warning.  Fix this by
making the operations within imgts mandatory (do not ignore
failures).
To further protect VM images from being removed while in use, introduce
a new container image imgobsolete, to be run before imgprune.
Instead of deleting images, they will be marked as 'deprecated' and
'obsolete' by this new container.  It will also encode advisory
deletion-date metadata, set 30 days into the future.
Lastly, update the imgprune container image such that it only searches for
images marked 'deprecated' and 'obsolete' with a metadata deletion-date
in the past.  This greatly simplifies the script.
The new 'obsolete' image state prevents the image from being used
or listed, but does not actually remove them.  If a mistake is
noticed, the image can be recovered manually with a simple
gcloud command:
gcloud compute images deprecate <NAME> --state=ACTIVE

Signed-off-by: Chris Evich<EMAIL_ADDRESS>

@edsantiago when you have a moment PTAL...This PR is a step toward re-enabling safer VM image cleanup, with the addition of an "undelete" option.  I apologize in advance, as it's quite "heady", with some non-linear flows.  I've done my best to dot i's, cross t's, and comment the heck out of every tricky spot.
Your pretty-graph drawing script works, but must be understood as running under three different modes:

(Top most flow) Running as part of a PR, after images are built: Apply metadata to fresh VM Images to verify imgts is functioning.  Followup with a dry-run of imgobsolete and imgprune (few other practical way to test these).

(Bottom then middle flow) Running on a branch after push or PR merge:  Build "latest" tagged versions of all container images only, no VM images are built.  No tests run (but they could).

(Bottom-only flow) Running on a branch triggered by cron: No images are built.  Use the "latest" tagged images for imgobsolete followed by imgprune.

Hopefully that makes sense.

Idea: There's no way to test the branch-push and cron workflows.  If either/both break, I'll just have to deal with it in followup PRs.

Whew. As best I can tell, with the exception of my < vs > question above, it looks like it should work. I have a bunch of changes in my local repo, where I've edited some comments and variables to help me better understand what's going on; I may clean that up and submit it next week, because I think it might help a future maintainer who is less well versed in gcloud-fu than you are.
BTW the changes I made last week to cirrus-task-map, for displaying SKIP/ONLY, needed only a few seconds' work to produce a more readable plot that doesn't require a text legend:

Was NOT expecting my "approve" to auto-merge. Damn.

changes I made last week to cirrus-task-map

Suggestion: Can you stick the only_if/skip label on the arrow instead of on the boxes?

Was NOT expecting my "approve" to auto-merge

It's not a problem, there are as-of-yet no cron-jobs in place that would execute these containers.  Incremental updates to the repo. next week are fine.

Was NOT expecting my "approve" to auto-merge

https://github.com/containers/automation_images/pull/33

Suggestion: Can you stick the only_if/skip label on the arrow instead of on the boxes?

That sounded counterintuitive to me, but I gave it a try. End result: no, it's much too confusing. First, in podman, there's an automation task that has no precursors but has a skip. Second, also in podman, there are flows that have different skips: like, unit_test is skipped on CI:DOC, but *_integration_test are skipped both on CI:DOC and on BRANCH. With skips on edges (arrows), my mind wants to think "oh, once I see a skip here, I don't have to look farther right", and that intuition is wrong. Finally, and most importantly to me, it is the task that is skipped, not the flow. It was worth a quick try, but no, I don't think it works well. Thanks for the suggestion.

Thanks for the suggestion.

Thanks for trying it out.


Site needs a footer.

There is no footer on the site.  This is very unusual.

What do we want to put in the footer? I would move the Github link to there, but otherwise?

Plain footer in place, with copyright.


Support for ID token verification

Native apps can receive ID tokens directly from Google in that auth flow; this provides some basic support with an eye toward more OIDC integration in this library.

Closing this, since the author has not addressed review comments in over a year.

I would still like to loop around on this but understand the trend is to close stale issues. Hopefully we can re-open it when I come back around.


Create a mainnet and other ready-made blockchain information classes

SimpleBlockchainInformation allows to create information about the eth subprotocol to other clients.
Use a fixed set for mainnet, goerli, rinkeby and ropsten.

Hello,I would like to work on this, can you assign this to me and can you explain where the classes needs to be added

Sure thing. I think you need to look at SimpleBlockchainInformation first - see how some of the information there like chain id, genesis hash, network ID are fixed per network? Create a map of "network name" to this information, so it becomes easier to read this from config.


how to do a pull request

Wanting to make a change to the mergit doc. @GraceGrothaus can you review my changes or just accept the request?

i reviewweeeeed this. and it looks good a' to me. and smoked well.


Profile toggling doesn't work (through special actions)

Hello,
I can't get the profile toggling to work through special actions at all. I also don't understand the must-have of an unload trigger.
I simply chose a button, followed by the action, this being Load a Profile. Then chose a profile. Let's say I use X for the button, then I expect X to change the chosen profile. It changes nothing at all.
(As for the unload button: If I wanted an unload trigger, can't I just make another special action under the other profile changing back to the first?)

Bump on this, I have the same issue

Resolved in: https://github.com/Jays2Kings/DS4Windows/pull/285

binding L2 + PS to toggle profile doesnt work

@crabjim did you try with my fix?

@yonilerner  I'm Using Build 1.4.52. Where to download your fix?

Hey im still getting this same issue

@SwifterNZ You may want to check out https://github.com/Ryochan7/DS4Windows


[firebase_performance] Fix Pub

Description
Is there a reason hotfix.5 would be needed? #1353 explains the problem.
Related Issues
Resolves #1353.
Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] If the pull request affects only one plugin, the PR title starts with the name of the plugin in brackets (e.g. [cloud_firestore])
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the [Flutter Style Guide].
[x] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the [CLA].
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[x] No, this is not a breaking change.

@mit-mit it seems that pana is using an older stable release of Flutter to analyze plugins. Would it make sense to update it to use the latest stable?
https://pub.dev/packages/firebase_performance#-analysis-tab-

We just pushed a new release on pub.dev, so it's now using Dart 2.6.0 and Flutter 1.9.1+hotfix.6:
https://pub.dev/packages/firebase_performance#-analysis-tab-


Add /dogfact command using DogApi

Command Name
/dogfact
Public API Resource
https://github.com/kinduff/dog-api
Description
/dogfact returns a random dogfact!
Implementation Details

Add a new javascript file in the commands folder
Implement a API request with the help of axios to your public API
Format the data in a readable way and send it to the user
Use the discord.js docs to get started

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I'll start with this rn! So pls assign me!

Sure, go ahead @MaestroDagan!

Hey @MaestroDagan! Well done! I reviewed you PR #23 and requested a change.
Let me know if you need help with that :)

@MaestroDagan Thanks for your contribution ❤
Your PR #23 was merged and labeled with the hacktoberfest-accepted label


Question about Gaussain Noise

Hi, thank you for your work.
I have a question about the degradation. For the Gaussian noise, in the general case, why you only set L=noise_level2/255.0 (https://github.com/cszn/BSRGAN/blob/main/utils/utils_blindsr.py#L371) instead of generating a random value between noise_level1 and noise_level2, like for the grayscale and color Gaussian noises?
Thanks!

I have the same problem.

@ShijianXu  Well, the authors say "As for sigma, it is uniformly sampled {1/255, 2/255,...., 25,255}" in the right column of Page 4. I think this may be the reason why use noise_level2 instead of noise_level.
FYI

I think the randomness of  noise level is generated by following code:
D = np.diag(np.random.rand(3))
U = orth(np.random.rand(3,3))
conv = np.dot(np.dot(np.transpose(U), D), U)
D and U are randomly sampled from 0~1.

This is for randomness, not for the noise level. The degradation level is controlled by L: img += np.random.multivariate_normal([0,0,0], np.abs(L**2*conv), img.shape[:2]).astype(np.float32)
This line simply means they only use the highest degradation level. This needs to be explained.

The noise level of 3D multivariate Gaussian noise is determined by six parameters, see Figure 1. This means we should not characterize the noise level of 3D Gaussian noise by a single scalar.  For example, the covariance matrix of [1.21, 0, 0; 0, 0, 0; 0, 0, 0] means only the green channel is added with the Gaussian noise with noise level 1.1, we cannot say the noise level of this RGB image is 1.1 or others. Due to limited space, I use a rough expression. noise_level1 is a small value, even if you set it to 0, and also even if you remove this multivariate Gaussian noise, the performance would not change too much.

We claimed in the paper that
"One can conveniently modify the degradation model by changing the degradation parameter settings and adding more reasonable degradation types (e.g., speckle noise and unaligned double JPEG compression [21]) to improve the practicability for certain applications"
It is not necessary to strictly follow my degradation design.
We mainly sell the idea of "random shuffle+double degradation+different degradation types" for more realistic degradation design.


[DOC] Outdated/incomplete examples documentation

Hi,
I am trying to start off with monai-deploy by following examples/apps breast_density_classifier
I am on ubuntu 22.04 and I am only able to run successfully using Python CLI.
When I try to run it using monai-deploy cli
monai-deploy exec app.py -i ./sampleDICOMs/3/BI_BREAST_SCREENING_BILATERAL_WITH_TOMOSYNTHESIS-2019-08-06/3 -m ./model/traced_ts_model.pt
I get error:
monai-deploy: error: argument command: invalid choice: 'exec' (choose from 'package', 'run', 'version', 'nics')
So obviously 'exec' needs to be replaced by 'run'
However, when I do that, I get further error:
monai-deploy: error: unrecognized arguments: -m ./model/traced_ts_model.pt
Running monai-deploy run --help does not list any -m cli argument. Removing it and trying to run:
monai-deploy run app.py -i ./sampleDICOMs/3/BI_BREAST_SCREENING_BILATERAL_WITH_TOMOSYNTHESIS-2019-08-06/3
results in next error:
[2024-05-22 11:22:11,121] [INFO] (runner) - Checking dependencies...
[2024-05-22 11:22:11,121] [INFO] (runner) - --> Verifying if "docker" is installed...
[2024-05-22 11:22:11,130] [INFO] (runner) - --> Verifying if "docker-buildx" is installed...
[2024-05-22 11:22:11,152] [INFO] (runner) - --> Verifying if "app.py" is available...
[2024-05-22 11:22:11,199] [INFO] (common) - Attempting to pull image app.py..
Using default tag: latest
Error response from daemon: pull access denied for app.py, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
[2024-05-22 11:22:13,124] [ERROR] (common) - The docker command executed was /usr/bin/docker image pull app.py.
It returned with code 1
The content of stdout can be found above the stacktrace (it wasn't captured).
The content of stderr can be found above the stacktrace (it wasn't captured).
[2024-05-22 11:22:13,124] [ERROR] (runner) - Unable to fetch required image.
[2024-05-22 11:22:13,124] [ERROR] (runner) - Execution Aborted
Going one level up, as suggested nd running:
monai-deploy run breast_density_classifer_app -i ./sampleDICOMs/3/BI_BREAST_SCREENING_BILATERAL_WITH_TOMOSYNTHESIS-2019-08-06/3
results in the same error as with previous command.
And finally packaging does'n seem to work either for me:
monai-deploy package -b nvcr.io/nvidia/pytorch:21.12-py3 breast_density_classification_app --tag breast_density:0.1.0
results in error:
monai-deploy package: error: argument application: No such file/folder: '/PATH/TO/PROJECT/monai-deploy/nvcr.io/nvidia/pytorch:21.12-py3'
I found out that if I don't use abbreviated cli argument, -b, for base image but a full one, --base-image this works. So this might even classify as a bug. However, this still does not fly since the next problem is:
monai-deploy package: error: the following arguments are required: --config/-c, --platform
I had to pull in and adapt the app.yaml from other examples and provide --platform. So the correct cli which moved me further was:
monai-deploy package --base-image nvcr.io/nvidia/pytorch:21.12-py3 breast_density_classifer_app --tag breast_density:0.1.0 --config breast_density_classifer_app/app.yaml --platform x64-workstation
However, as of today the base-image for pytorch container with version 21.12 (december 2021) is very outdated and it was not able to resolve conflicting packages and creating of docker image failed. So I tried using more recent base image 24.04.-py3, which succeeded, but then running the whole thing failed:
monai-deploy run breast_density_classifer_app-x64-workstation-dgpu-linux-amd64:0.2.0 -i breast_density_classifer_app/sampleDICOMs/3/BI_BREAST_SCREENING_BILATERAL_WITH_TOMOSYNTHESIS-2019-08-06/3
[2024-05-22 12:01:26,929] [INFO] (runner) - Checking dependencies...
[2024-05-22 12:01:26,929] [INFO] (runner) - --> Verifying if "docker" is installed...
[2024-05-22 12:01:26,930] [INFO] (runner) - --> Verifying if "docker-buildx" is installed...
[2024-05-22 12:01:26,930] [INFO] (runner) - --> Verifying if "breast_density_classifer_app-x64-workstation-dgpu-linux-amd64:0.2.0" is available...
[2024-05-22 12:01:27,066] [INFO] (runner) - Reading HAP/MAP manifest...
Successfully copied 2.56kB to /tmp/tmp4et7tool/app.json
Successfully copied 2.05kB to /tmp/tmp4et7tool/pkg.json
[2024-05-22 12:01:28,360] [INFO] (runner) - --> Verifying if "nvidia-ctk" is installed...
[2024-05-22 12:01:28,361] [INFO] (runner) - --> Verifying "nvidia-ctk" version...
[2024-05-22 12:01:29,008] [INFO] (common) - Launching container (01deeea6c946) using image 'breast_density_classifer_app-x64-workstation-dgpu-linux-amd64:0.2.0'...
container name:      heuristic_perlman
host name:           buddha
network:             host
user:                1000:1000
ulimits:             memlock=-1:-1, stack=67108864:67108864
cap_add:             CAP_SYS_PTRACE
ipc mode:            host
shared memory size:  67108864
devices:
group_add:           44
2024-05-22 10:01:34 [INFO] Launching application python3 /opt/holoscan/app ...
Error processing line 1 of /home/holoscan/.local/lib/python3.10/site-packages/holoscan-2.0.0.pth:
Traceback (most recent call last):
File "/usr/lib/python3.10/site.py", line 192, in addpackage

  exec(line)

File "<string>", line 1, in <module>

File "/home/holoscan/.local/lib/python3.10/site-packages/wheel_axle/runtime/__init__.py", line 77, in finalize

  from filelock import FileLock  # Local import for speed

ModuleNotFoundError: No module named 'filelock'
Remainder of file ignored
Traceback (most recent call last):
File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,

File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
exec(code, run_globals)

File "/opt/holoscan/app/main.py", line 3, in
from app import BreastClassificationApp

File "/opt/holoscan/app/app.py", line 4, in
from breast_density_classifier_operator import ClassifierOperator

File "/opt/holoscan/app/breast_density_classifier_operator.py", line 8, in
from monai.data import DataLoader, Dataset

ModuleNotFoundError: No module named 'monai.data'
[2024-05-22 12:01:41,772] [INFO] (common) - Container 'heuristic_perlman'(01deeea6c946) exited.
**Would be great if we could have a complete and working example.
Thanks**

@kavmar, thanks for the raising the issues on the outdated documentation for this example.
A pull request is being prepared by the contributor, in the meantime, please use the Jupyter notebooks to see the correct commands for running the example applications as script, packaging the application into MONAI Application Package (container image), and running the MAP container.
Below are the root causes of the errors:

The exec sub command of monai-deploy had been deprecated since MONAI Deploy App SDK v0.6. Please directly use Python interpreter to run the application, e.g.

python /home/mqin/src/monai-deploy-app-sdk/examples/apps/breast_density_classifer_app \
    -i /home/mqin/src/monai-deploy-app-sdk/inputs/BreastDensityClassification/sampleDICOMs/1/BI_BREAST_SCREENING_BILATERAL_WITH_TOMOSYNTHESIS-2019-07-08/1/L_CC_C-View \
    -o /home/mqin/src/monai-deploy-app-sdk/output_breast_density \
    -m /home/mqin/src/monai-deploy-app-sdk/models/breast_density_cr/traced_ts_model.pt

Alternatively, the input, output, and model path can be set in the well-known env variables instead of passed on the command line, e.g.
export HOLOSCAN_INPUT_PATH="/home/mqin/src/monai-deploy-app-sdk/inputs/BreastDensityClassification/sampleDICOMs/1/BI_BREAST_SCREENING_BILATERAL_WITH_TOMOSYNTHESIS-2019-07-08/1/L_CC_C-View"
export HOLOSCAN_MODEL_PATH="/home/mqin/src/monai-deploy-app-sdk/models/breast_density_cr/traced_ts_model.pt"
export HOLOSCAN_OUTPUT_PATH="/home/mqin/src/monai-deploy-app-sdk/output_breast_density"

The run sub command of monai-deploy launches the MAP container with the image name passed on the command line

For the packaging error, the command line option -b had also been deprecated since v0.6, and the full version, --base-image, needs to be used, as you have found out.
The named based image is also out of date, and the new monai-deploy packge picks a well-known default image according to the --platform option.

@vikashg

@kavmar I've gone ahead and created a pull request to fix the issues.

Thanks a lot. Going to test.

@MMelQin thanks a lot, I confirm the instructions in breast classifier application example work.
A tiny glitch/request: would be great to support monai-deploy-app-sdk on Ubuntu 24 as well. holoscan is not compatible. I am lucky to have also a box with Ubuntu 22

@MMelQin thanks a lot, I confirm the instructions in breast classifier application example work.
A tiny glitch/request: would be great to support monai-deploy-app-sdk on Ubuntu 24 as well. holoscan is not compatible. I am lucky to have also a box with Ubuntu 22

@kavmar I'd love to support Ubuntu 24 as well, and technically it should work.
The Holoscan SDK dependency has only been formally tested on Ubuntu 22.04 LTS. Holoscan V&V encompasses hardware (including ARM/X86 CPU, integrated and discreet GPU), OS, and the software, for the devkit to be capable of being cleared as a medical device.
However, here is the official statement on Holoscan SDK python package:
"The Holoscan SDK python wheels are only formally tested on Ubuntu 22.04. They are, however, expected to work on any Linux distribution with glibc 2.35 or above (see output of ldd --version) and CUDA Runtime 12.2 or above."
So, technically on X86 with discreet GPU and Ubuntu 24, Holoscan SDK would work fine, so does MONAI Deploy App SDK.


Clarify that in environments with Firewalls (ASE) you do not necessarily need access to www.powershellgallery.com

Clarify that in environments with Firewalls (ASE) you do not necessarily need access to www.powershellgallery.com.
It was not create to me and a customer that in a locked down environment you may not need to white list this.  The customer can either turnoff managedDependency in the host.json file  by turning the required property to false as documented.

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

ID: efae763f-03a9-b3b0-e7ad-52f9b1559438
Version Independent ID: 2afd9c78-e5b0-5d34-b809-47d9576399d0
Content: PowerShell developer reference for Azure Functions
Content Source: articles/azure-functions/functions-reference-powershell.md
Service: azure-functions
GitHub Login: @eamonoreilly
Microsoft Alias: glenga

@jsandersrocks Thank you for your feedback! We have assigned this issue to the author to review further and take the right course of action.


C++ Template Function Highlighting

Template functions that are manually type specified are highlighted in a different way then regular functions.

VSCode Version: 1.23.1
OS Version: Ubuntu 18.04 x86 4.15.0-22-generic

Steps to Reproduce:

Type code in picture into editor

Does this issue occur when all extensions are disabled?: Yes

Please share code as text

class C {
public:
    template<typename T>
    T func(T param) {
        return param;
    }
};

template<typename T>
void func1() {

}

void func2() {

}

int main() {
    C c;
    c.func<int>(10);
    c.func(10);

    func1<int>();
    func2();
}

Thanks.
Duplicate of https://github.com/atom/language-c/issues/215


How do i install this theme

I already have LuCI theme openwrt-bootstrap theme installed but i would like to install rosy-theme.
I tried adding src-git luci https://github.com/rosywrt/luci.git to my customfeeds but after updating package list it shows invalid link.

This theme is not in stable tree yet. Just download & install it from latest snapshot, e.g. https://downloads.openwrt.org/snapshots/packages/x86_64/luci/

Thank you 👍


feat: COPY ... TO ... (first iteration)

db=> set gcs_service_account_key to '...';
SET
db=> copy (select * from glare_catalog.tables) to 'gs://sean-test-glaredb/test2.json';
COPY

Adds COPY ... TO ..., allow (unpartitioned) writes to object storage. Supported formats are json, csv, and parquet.
Note that COPY table TO ... parses correctly, but is currently unimplemented (for now). COPY (SELECT ...) TO ... works as expected.
Note that this isn't the final iteration. There was a bit of exploratory work done here to better understand how this would work, and if there's things we can reuse for querying object storage data sources. I plan on reworking that a bit to support more formats and features.
I also added in a gcs_service_account_key session var which only works for copy right now. It made testing this a bit easier. I'm unsure if we want to leave that in. If we do, do we want to add similar vars for s3?

Superseded by https://github.com/GlareDB/glaredb/pull/1159


[swiftpm][tests] Rely on XCTest for xplat shim

The package manager tests perform some interesting acrobatics in order
to support unit tests on all platforms while also enforcing type safety.
Change this to rely on swift-corelibs-xctest as a shim layer, as that
library intends. This is the first step to using XCTMain() from within
the package manager tests.
swift-corelibs-xctest provides an API for developers to write unit
tests using XCTestCase. Since Swift XCTest cannot automatically detect test
methods like Obj-C XCTest can, Swift XCTest defines XCTestCase as
conforming to XCTestCaseProvider, which defines the allTests public
variable. The shim layer exists in swift-corelibs-xctest, and this is
where is should be.
The package manager currently explicitly marks all of its test cases as
conforming to XCTestCaseProvider. XCTestCaseProvider isn't available on
all platforms, so the package manager tests use macros to conditionally
define it. The logic for this conditional definition is convoluted:

All test cases conform to XCTestCaseProvider, regardless of platform.
XCTestCaseProvider.swift defines XCTestCaseProvider as an empty
protocol if the current platform is OS X (which uses Obj-C XCTest and thus
doesn't define XCTestCaseProvider). This file is not included in any
of the test targets, so it is not included when building from the command
line on OS X or Linux. It is included in the Xcode project, thus
allowing tests to build in Xcode.
Each target's main.swift defines XCTestCaseProvider as a protocol
that defines the allTests public variable, but only if the platform
is not Linux (on Linux, XCTestCaseProvider is already defined). These
files are used when building from the command-line, but are not
included in the Xcode project (thus the Xcode project does not have
duplicate definitions of XCTestCaseProvider).

The benefit to doing all this is to ensure that all package manager
tests conform to the XCTestCaseProvider protocol, and so developers
are informed at compile-time whether their tests will work on Linux.
This is great, but not worth the complexity above.

I am not convinced this isn't worth the complexity, we need adding tests to be as reliable as possible.
I actually want to go the other direction, and have the OS X build do more work to audit that the allTests array is declared correctly.
I would be interested in seeing if there are other ways we can simplify the current implementation though -- I have forgotten why we ended up declaring the protocol in each test target, I think it may have been because we didn't have a simple way to put it somewhere to be shared. We should be able to solve that.
Note also that all of this is hopefully temporary, just until the package manager itself really supports building test targets.
What specific problem are you trying to solve? Just extra complexity?

What specific problem are you trying to solve? Just extra complexity?

My primary goal is to have the test targets use XCTMain(). I'd like to ensure that all clients of swift-corelibs-xctest use that as an entry point. If I can reduce complexity while doing so that'd be great, but I'm beginning to understand the package manager tests are necessarily complex when compared to, say, swift-corelibs-foundation.

I would be interested in seeing if there are other ways we can simplify the current implementation though -- I have forgotten why we ended up declaring the protocol in each test target, I think it may have been because we didn't have a simple way to put it somewhere to be shared. We should be able to solve that.

This pull request was one of several approaches I tried. I also thought of having XCTestProvider be its own package, and have each of the test targets rely on it as a dependency. I can explore this further if you think that's the way to go.

I am not convinced this isn't worth the complexity, we need adding tests to be as reliable as possible.

This may be something we need to discuss further on the mailing list. It would be fantastic if swift-corelibs-xctest could provide a way to write cross-platform tests while also ensuring that developers know when they're writing tests that won't work on Linux (because they don't implement allTests).

I think what we hope to do there is get the necessary reflection features in place so that we can have some kind of auto-test discovery. Maintaining allTests isn't intended to be a long term solution...
We can tackle short term fixes to reduce the pain for now, but if we are going to invest serious work then that should be focused at getting the right long term solution in place.

I think what we hope to do there is get the necessary reflection features in place so that we can have some kind of auto-test discovery.

This would be really, really cool. :100:

We can tackle short term fixes to reduce the pain for now, but if we are going to invest serious work then that should be focused at getting the right long term solution in place.

Totally agree. Even in the short- or medium-term, though, I'd like to improve swift-corelibs-xctest, and I view XCTMain() as the canonical entry point into that system. In that vein, I'd like to have the package manager use it as well. Do you agree that this is worth pursuing?

Yes, what would a minimal patch to just move to use XCTMain() look like?

Working on it! :bow:

Closing in favor of #66.


[Phase 3] Refactor UI for the search result page

[x] Reduce the margin between different search sections
[x] Center alignment and reduce width

@Haunter17 Review


possibe "protein targeting problem" related to MVB sorting

I am not an expert in this  (at all), but there seems to be a problem with the term
"GO:0043329 protein targeting to membrane involved in ubiquitin-dependent protein catabolic process via the multivesicular body sorting pathway"
I noticed this because I was looking a the list of proteins involved in "protein targeting".
As far as I'm aware "targeting" relies on signal intrinsic to the protein but this type of sorting is "ubiquitin dependent". If this interpretation is correct we could change to
"protein sorting" and remove the protein targeting parentage?
Reported by: ValWood
Original Ticket: geneontology/ontology-requests/10285

Hi Val,
Looking at this item again now, I don't think a merge is in order. Proteins are also targeted to lysosomes as part of microautophagy and to late endosomes in the mammalian equivalent. So not all of this targeting is via MVBc. If I am not mistaken, sometimes this also involves ubiquitination.
Could change the term to be sorting instead of trageting, but what would you suggest I use as a parent?
-D

Or transport?
How does "sorting" differ from transport?
Val

Presumably this term refers to the process by which the proteins are recognized, which is separate from the movement. Transport would be more than that.
If you look at the paper that supports this term, it describes an ESCRT complex and it specifically says that the complex is required to recognize the tagged protein and sort it correctly.


DCMAW-8229: Extract logic into public key class

DCMAW-8229
What changed

Adds public key class
Adds TokenService dependencies
Updates existing mock JWT builder and renames file.

Updates imports, which includes the token and credential Lambda tests

Checklists

[x] There is a ticket raised for this PR that is present in the branch name
[ ] No PII data logged. See guidance here
[ ] Demo to a BA, TA, and the team.
[ ] Update README with any new instructions or tasks

Can we add some evidence that we still get a 200 back from the activeSession lambda?


Redis cache not support GetOrSet method

Redis cache not support GetOrSet method

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

ID: 0d01025d-86b2-bb2d-86c1-ef0695bc98e3
Version Independent ID: 5b9a6572-3671-0d54-b2ef-83d04f8b3e96
Content: Distributed caching in ASP.NET Core
Content Source: aspnetcore/performance/caching/distributed.md
Product: aspnet-core
Technology: aspnetcore-performance
GitHub Login: @guardrex
Microsoft Alias: riande

Yes, that's correct ...

https://docs.microsoft.com/dotnet/api/microsoft.extensions.caching.stackexchangeredis.rediscache
https://docs.microsoft.com/dotnet/api/microsoft.extensions.caching.distributed.idistributedcache

If you would like to make a feature request to support that method, open an issue here :point_right: https://github.com/aspnet/Extensions/issues


cloud-init files loading and execution order is not guaranteed

elemental-toolkit version:  0.11.1-150400.1.1.noarch

CPU architecture, OS, and Version: Harvester derivative

Describe the bug

The order to load and execute cloud-init files changed in this version.
To Reproduce

Here is a test example:
cat >/oem/89_test.yaml <<EOF
name: test 89
stages:
  boot:
    - commands:
      - sleep 3 && echo "test 89" | tee /tmp/89
EOF

cat >/oem/90_test.yaml <<EOF
name: test 90
stages:
  boot:
    - commands:
      - echo "test 90" | tee /tmp/90
EOF

And run elemental run-stage boot --debug get:
DEBU[2023-11-24T06:58:23Z] Generating op for stage 'test 89.0'
DEBU[2023-11-24T06:58:23Z] Generating op for stage 'test 90.0'
DEBU[2023-11-24T06:58:23Z] Reading '/oem/90_test.yaml'
DEBU[2023-11-24T06:58:23Z] Executing stage 'test 90.0'
DEBU[2023-11-24T06:58:23Z] Reading '/oem/89_test.yaml'
DEBU[2023-11-24T06:58:23Z] Executing stage 'test 89.0'
INFO[2023-11-24T06:58:23Z] Processing stage step ''. ( commands: 1, files: 0, ... )
INFO[2023-11-24T06:58:23Z] Processing stage step ''. ( commands: 1, files: 0, ... )
DEBU[2023-11-24T06:58:23Z] Stage: {"Commands":["sleep 3 \u0026\u0026 echo \"test 89\" | tee /tmp/89"],"Files":null,"Downloads":null,"Directories":null,"If":"","EnsureEntities":null,"DeleteEntities":null,"Dns":{"Nameservers":null,"DnsSearch":null,"DnsOptions":null,"Path":""},"Hostname":"","Name":"","Sysctl":null,"SSHKeys":null,"Node":"","Users":null,"Modules":null,"Systemctl":{"Enable":null,"Disable":null,"Start":null,"Mask":null},"Environment":null,"EnvironmentFile":"","After":null,"DataSources":{"Providers":null,"Path":""},"Layout":{"Device":null,"Expand":null,"Parts":null},"SystemdFirstBoot":null,"TimeSyncd":null,"Git":{"Auth":{"Username":"","Password":"","PrivateKey":"","Insecure":false,"PublicKey":""},"URL":"","Path":"","Branch":"","BranchOnly":false}}
DEBU[2023-11-24T06:58:23Z] Stage: {"Commands":["echo \"test 90\" | tee /tmp/90"],"Files":null,"Downloads":null,"Directories":null,"If":"","EnsureEntities":null,"DeleteEntities":null,"Dns":{"Nameservers":null,"DnsSearch":null,"DnsOptions":null,"Path":""},"Hostname":"","Name":"","Sysctl":null,"SSHKeys":null,"Node":"","Users":null,"Modules":null,"Systemctl":{"Enable":null,"Disable":null,"Start":null,"Mask":null},"Environment":null,"EnvironmentFile":"","After":null,"DataSources":{"Providers":null,"Path":""},"Layout":{"Device":null,"Expand":null,"Parts":null},"SystemdFirstBoot":null,"TimeSyncd":null,"Git":{"Auth":{"Username":"","Password":"","PrivateKey":"","Insecure":false,"PublicKey":""},"URL":"","Path":"","Branch":"","BranchOnly":false}}
DEBU[2023-11-24T06:58:23Z] {"sysinfo":{"version":"0.9.5","timestamp":"2023-11-24T06:58:21.942348404Z"},"node":{"hostname":"node1","machineid":"a79a61ca584c0cd073276f2565266e76","hypervisor":"kvm","timezone":"Etc/UTC"},"os":{"name":"Harvester v1.2.0","vendor":"sle-micro-rancher","version":"5.3","architecture":"amd64"},"kernel":{"release":"5.14.21-150400.24.81-default","version":"#1 SMP PREEMPT_DYNAMIC Tue Aug 8 14:10:43 UTC 2023 (90a74a8)","architecture":"x86_64"},"product":{"name":"Standard PC (i440FX + PIIX, 1996)","vendor":"QEMU","version":"pc-i440fx-8.1"},"board":{},"chassis":{"type":1,"vendor":"QEMU","version":"pc-i440fx-8.1"},"bios":{"vendor":"SeaBIOS","version":"rel-1.16.2-3-gd478f380-rebuilt.opensuse.org","date":"04/01/2014"},"cpu":{"vendor":"AuthenticAMD","model":"AMD Ryzen 5 3600 6-Core Processor","speed":2000,"cache":512,"threads":12},"memory":{"type":"RAM","size":16384},"storage":[{"name":"vda","driver":"virtio_blk","size":536}],"network":[{"name":"ens5","driver":"e1000","macaddress":"52:54:00:6a:59:7c","port":"tp","speed":1000},{"name":"ens6","driver":"e1000","macaddress":"52:54:00:01:9b:5b","port":"tp","speed":1000}]}
DEBU[2023-11-24T06:58:23Z] {"sysinfo":{"version":"0.9.5","timestamp":"2023-11-24T06:58:21.942348404Z"},"node":{"hostname":"node1","machineid":"a79a61ca584c0cd073276f2565266e76","hypervisor":"kvm","timezone":"Etc/UTC"},"os":{"name":"Harvester v1.2.0","vendor":"sle-micro-rancher","version":"5.3","architecture":"amd64"},"kernel":{"release":"5.14.21-150400.24.81-default","version":"#1 SMP PREEMPT_DYNAMIC Tue Aug 8 14:10:43 UTC 2023 (90a74a8)","architecture":"x86_64"},"product":{"name":"Standard PC (i440FX + PIIX, 1996)","vendor":"QEMU","version":"pc-i440fx-8.1"},"board":{},"chassis":{"type":1,"vendor":"QEMU","version":"pc-i440fx-8.1"},"bios":{"vendor":"SeaBIOS","version":"rel-1.16.2-3-gd478f380-rebuilt.opensuse.org","date":"04/01/2014"},"cpu":{"vendor":"AuthenticAMD","model":"AMD Ryzen 5 3600 6-Core Processor","speed":2000,"cache":512,"threads":12},"memory":{"type":"RAM","size":16384},"storage":[{"name":"vda","driver":"virtio_blk","size":536}],"network":[{"name":"ens5","driver":"e1000","macaddress":"52:54:00:6a:59:7c","port":"tp","speed":1000},{"name":"ens6","driver":"e1000","macaddress":"52:54:00:01:9b:5b","port":"tp","speed":1000}]}
DEBU[2023-11-24T06:58:23Z] running command `echo "test 90" | tee /tmp/90`
DEBU[2023-11-24T06:58:23Z] running command `sleep 3 && echo "test 89" | tee /tmp/89`
INFO[2023-11-24T06:58:23Z] Command output: test 90
INFO[2023-11-24T06:58:26Z] Command output: test 89
INFO[2023-11-24T06:58:26Z] Done executing stage 'boot'

And checking the created file we can conclude 90-test.yaml was executed without waiting 89-test.yaml to finish.
node1:~ # ls --full-time -alh /tmp/89 /tmp/90
-rw-r----- 1 root root 8 2023-11-24 06:58:26.082222614 +0000 /tmp/89
-rw-r----- 1 root root 8 2023-11-24 06:58:23.082222614 +0000 /tmp/90

Expected behavior

I'm not 100% sure if this is an expected behavior.
But from the doc:

By default Elemental and derivatives are reading and executing cloud-init files in (lexicopgrahic) sequence inside:

and the sequence prefixes before cloud-init files really make me expect commands to be executed in order. Without the guarantee, it will be hard to customize or override the cloud-init file shipped within (/system/oem).
Logs

Additional context

Hi @bk201!
Running this on latest released version v1.1.0 produces the following output:
DEBU[2023-11-24T08:46:53+01:00] Cloud-init paths set to [/system/oem /oem/ /usr/local/cloud-config/]
INFO[2023-11-24T08:46:53+01:00] Running stage: boot.before
INFO[2023-11-24T08:46:53+01:00] Done executing stage 'boot.before'
INFO[2023-11-24T08:46:53+01:00] Running stage: boot
DEBU[2023-11-24T08:46:53+01:00] Generating op for stage 'test 89.0'
DEBU[2023-11-24T08:46:53+01:00] Generating op for stage 'test 90.0'
DEBU[2023-11-24T08:46:53+01:00] Reading '/oem/89_test.yaml'
DEBU[2023-11-24T08:46:53+01:00] Executing stage 'test 89.0'
INFO[2023-11-24T08:46:53+01:00] Processing stage step ''. ( commands: 1, files: 0, ... )
DEBU[2023-11-24T08:46:53+01:00] Stage: {"Commands":["sleep 3 \u0026\u0026 echo \"test 89\" | tee /tmp/89"],"Files":null,"Downloads":null,"Directories":null,"If":"","EnsureEntities":null,"DeleteEntities":null,"Dns":{"Nameservers":null,"DnsSearch":null,"DnsOptions":null,"Path":""},"Hostname":"","Name":"","Sysctl":null,"SSHKeys":null,"Node":"","Users":null,"Modules":null,"Systemctl":{"Enable":null,"Disable":null,"Start":null,"Mask":null},"Environment":null,"EnvironmentFile":"","After":null,"DataSources":{"Providers":null,"Path":""},"Layout":{"Device":null,"Expand":null,"Parts":null},"SystemdFirstBoot":null,"TimeSyncd":null,"Git":{"Auth":{"Username":"","Password":"","PrivateKey":"","Insecure":false,"PublicKey":""},"URL":"","Path":"","Branch":"","BranchOnly":false}}
DEBU[2023-11-24T08:46:53+01:00] running command `sleep 3 && echo "test 89" | tee /tmp/89`
INFO[2023-11-24T08:46:56+01:00] Command output: test 89
DEBU[2023-11-24T08:46:56+01:00] Reading '/oem/90_test.yaml'
DEBU[2023-11-24T08:46:56+01:00] Executing stage 'test 90.0'
INFO[2023-11-24T08:46:56+01:00] Processing stage step ''. ( commands: 1, files: 0, ... )
DEBU[2023-11-24T08:46:56+01:00] Stage: {"Commands":["echo \"test 90\" | tee /tmp/90"],"Files":null,"Downloads":null,"Directories":null,"If":"","EnsureEntities":null,"DeleteEntities":null,"Dns":{"Nameservers":null,"DnsSearch":null,"DnsOptions":null,"Path":""},"Hostname":"","Name":"","Sysctl":null,"SSHKeys":null,"Node":"","Users":null,"Modules":null,"Systemctl":{"Enable":null,"Disable":null,"Start":null,"Mask":null},"Environment":null,"EnvironmentFile":"","After":null,"DataSources":{"Providers":null,"Path":""},"Layout":{"Device":null,"Expand":null,"Parts":null},"SystemdFirstBoot":null,"TimeSyncd":null,"Git":{"Auth":{"Username":"","Password":"","PrivateKey":"","Insecure":false,"PublicKey":""},"URL":"","Path":"","Branch":"","BranchOnly":false}}
DEBU[2023-11-24T08:46:56+01:00] running command `echo "test 90" | tee /tmp/90`
INFO[2023-11-24T08:46:56+01:00] Command output: test 90
INFO[2023-11-24T08:46:56+01:00] Done executing stage 'boot'
INFO[2023-11-24T08:46:56+01:00] Running stage: boot.after
INFO[2023-11-24T08:46:56+01:00] Done executing stage 'boot.after'
INFO[2023-11-24T08:46:56+01:00] Running stage: boot.before
INFO[2023-11-24T08:46:56+01:00] Done executing stage 'boot.before'
INFO[2023-11-24T08:46:56+01:00] Running stage: boot
INFO[2023-11-24T08:46:56+01:00] Done executing stage 'boot'
INFO[2023-11-24T08:46:56+01:00] Running stage: boot.after
INFO[2023-11-24T08:46:56+01:00] Done executing stage 'boot.after'

I'm not sure yet, but it sounds like you are running into this old issue in yip: https://github.com/mudler/yip/issues/67

Closing this, feel free to reopen if the issue still exists!


Are there any ways to send xml type response?

I want to send back a xml type response, but the SendAsync() method only serialize the DTO to Json type.
I'm a newbie to this wonderful framework.
Are there any ways or hints for me to send a xml type response

you can send anything like so:
public class MyEndpoint : EndpointWithoutRequest
{
    public override void Configure()
    {
        Get("test");
        AllowAnonymous();
        Description(b => b.Produces<object>(200, "application/xml"));
    }

    public override async Task HandleAsync(CancellationToken c)
    {
        const string xml = "hello world...";
        await SendBytesAsync(Encoding.UTF8.GetBytes(xml), contentType: "application/xml");
    }
}

you can even wrap that into an extension method targetting IEndpoint interface.
or create a custom base class with your own SendXXXAsync() methods.

That works. Thanks.


Changes to GetCurrentComposedLook method

Changes to GetCurrentComposedLook method, to work also in sites are not in english. In English sites the current name of the theme is "Current" but in finnish sites for example it is "Nykyinen", so the method will fail. But if we use the id of the item, which is always 1, then we will get always the right theme.

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

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

pushed to wrong branch. made new one in dev branch.


Reinforce RESP handler

Describe the bug
RESP handler often breaks, need to fix it.
To Reproduce
Steps to reproduce the behavior:
DO THIS-
(printf '+PING\r\n+PING\r\n';) | nc localhost 7379
(printf '+PING\r\n+PING\r\n';) | nc localhost 7379
(printf '+OING\r\n+PING\r\n';) | nc localhost 7379

Expected behavior
This should log "Possible security attack" on the server side and disconnect the client issuing the command.
Additional context
Try Fuzzers to break the current RESP implementation to explore more steps to reproduce the larger issue with RESP handler.

Closing this issue as shipped.


TQDM Progress Bar shows negative time and speed after resuming from checkpoint

🐛 Bug
TQDM Progress Bar shows negative time and speed after resuming from checkpoint
Screencast from 07-01-2022 10:12:29 PM.webm
To Reproduce
Train any model for sometime, then resume. The progress bar will register negative numbers
Expected behavior
Resuming should NOT cause the progress bar to display negative ETA/speed
Environment

CUDA:
- GPU:
- NVIDIA GeForce RTX 3090
- available:         True
- version:           11.6
Packages:
- numpy:             1.23.0
- pyTorch_debug:     False
- pyTorch_version:   1.12.0+cu116
- pytorch-lightning: 1.6.4
- tqdm:              4.64.0
System:
- OS:                Linux
- architecture:
- 64bit
- ELF
- processor:         x86_64
- python:            3.9.13
- version:           #42-Ubuntu SMP Thu Jun 9 23:42:32 UTC 2022

This is a duplicate of #13124. I'm closing this to keep the discussion in #13124. Feel free to subscribe to the issue to get notified about the progress.
I had already looked into it but couldn't find the reason why the bar shows the incorrect estimates yet.


New email branding

Added a new format/styling/layout for our core emails to give a more web-consistent styling for core emails.
It is fully responsive, and has been optimised for older clients as well as newer clients.
Also changed some links to the new domain.
An example email:

(^ Above was a screenshot taken from Outlook - probably the worst client in terms of HTML support. Looks a bit neater on newer clients)
Closes #799

These are all done too :)


setting window name doesn't work on tmux 2.5

Python 3.6.1 (default, Aug 23 2017, 20:07:59)
[GCC 5.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import libtmux
>>> server = libtmux.Server()
>>> server.new_session(session_name="pa")
Session($0 pa)
>>> session = server.find_where({"session_name":"pa"})
>>> session
Session($0 pa)
>>> session.new_window(window_name="telegram")
Window(@1 1:telegram, Session($0 pa))
>>> window = session.find_where({"window_name":"telegram"})
>>> window
>>> window is None
True

Explicitly calling rename_window works:
>>> session.windows[1].rename_window("telegram")
Window(@1 1:telegram, Session($0 pa))
>>> session.find_where({"window_name":"telegram"})
Window(@1 1:telegram, Session($0 pa))

But not when called "too soon":
>>> window=session.new_window(); window.rename_window("test")
Window(@2 2:aragaer@netbook:~/Projects/pa/router, Session($0 pa))
>>> session.find_where({"window_name":"test"})

I don't see any errors in logging or tmux stderr. However windows are not actually renamed - tmux list-windows shows generic names.
Trying to manually run the command I'm getting the following error:
/usr/bin/tmux new-window -P -c/home/aragaer/Projects/pa/tg -F"#{session_name}#{session_id}#{window_id}#{window_name}#{window_width}#{window_height}#{window_layout}#{window_panes}#{window_index}#{window_flags}#{window_active}#{window_bell_flag}#{window_activity_flag}#{window_silence_flag}" -ntelegram -t$0:
can't find session bash

Apparently the last "error" is caused by using non-escaped $1.
The problem with window name, which I managed to reproduce running tests, is caused by bash which sets window name to some default value. Using window_shell="sh" I managed to make it work. The following patch is enough to pass the tests:
diff --git a/libtmux/session.py b/libtmux/session.py
index ed5aab5..c8a912d 100644
--- a/libtmux/session.py
+++ b/libtmux/session.py
@@ -193,6 +193,8 @@ class Session(

         if window_shell:
             window_args += (window_shell,)
+        else:
+            window_args += ("sh",)

         proc = self.cmd('new-window', *window_args)

But I am still not sure it is the correct change. It might be better to simply warn that window name was not set properly if we can detect that bash changed it.

Can you double check which libtmux and python version this is?

0.7.4


port faq/ here

For more information here:
https://github.com/kami-blue/bot-js/pull/187

I'd rather have #12

Basically w/faq.*modulename/


libavif: 0.11.1 -> 1.0.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/libavif/versions.
meta.description for libavif is: C implementation of the AV1 Image File Format
meta.homepage for libavif is: https://github.com/AOMediaCodec/libavif
meta.changelog for libavif is: https://github.com/AOMediaCodec/libavif/blob/v1.0.1/CHANGELOG.md
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.0.1 with grep in /nix/store/5ab7r22if2h2lhjdjr1591pgk8bqahii-libavif-1.0.1
found 1.0.1 in filename of file in /nix/store/5ab7r22if2h2lhjdjr1591pgk8bqahii-libavif-1.0.1

Rebuild report (if merged into master) (click to expand)

11804 total rebuild path(s)

11804 package rebuild(s)

First fifty rebuilds by attrpath

AusweisApp2
CHOWTapeModel
ChowCentaur
ChowKick
ChowPhaser
CuboCore.coreaction
CuboCore.corearchiver
CuboCore.corefm
CuboCore.coregarage
CuboCore.corehunt
CuboCore.coreimage
CuboCore.coreinfo
CuboCore.corekeyboard
CuboCore.corepad
CuboCore.corepaint
CuboCore.corepdf
CuboCore.corepins
CuboCore.corerenamer
CuboCore.coreshot
CuboCore.corestats
CuboCore.corestuff
CuboCore.coreterminal
CuboCore.coretime
CuboCore.coretoppings
CuboCore.coreuniverse
CuboCore.libcprime
CuboCore.libcsys
DisnixWebService
EmptyEpsilon
HentaiAtHome
LibreArp
LibreArp-lv2
MIDIVisualizer
MMA
OSCAR
PageEdit
R
SDL
SDL2
SDL2_gfx
SDL2_image
SDL2_image_2_0_5
SDL2_mixer
SDL2_mixer_2_0
SDL2_net
SDL2_sound
SDL2_ttf
SDL_Pango
SDL_audiolib

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/5ab7r22if2h2lhjdjr1591pgk8bqahii-libavif-1.0.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libavif https://github.com/r-ryantm/nixpkgs/archive/047f87f3859d82a1f793fbfe08873a23d7f4df3e.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/5ab7r22if2h2lhjdjr1591pgk8bqahii-libavif-1.0.1
ls -la /nix/store/5ab7r22if2h2lhjdjr1591pgk8bqahii-libavif-1.0.1/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings
cc @mkg20001 for testing.

this should go to staging i guess? im not familiar with how to do that so feel free to do it....


Spring logging vulnerability from Sonatype Lift SBOM report after 0.2.0 deployment

See the report:
https://sbom.lift.sonatype.com/report/T1-0ff0976f7f21c391f20f-4008c1764e9b-1637001186-60dd3d21c5ea4a1ba7b9b2ad5c904edb
Here's the CVE it references: https://nvd.nist.gov/vuln/detail/CVE-2021-22096
And here is a document describing the problem in more detail with an example: http://cwe.mitre.org/data/definitions/117.html
I am not sure why it didn't catch this on kiwi's recent deployment since it also uses the same Spring version (5.3.9)

Note that both kiwi and dropwizard-service-utilities declare a spring version in their POM, and both are at 5.3.9, as of 2021-11-15.

Also note this is considered a Medium (4.3 out of 10) severity so it's not like it's a no-click remote code execution.

Note that both kiwi and dropwizard-service-utilities declare a spring version in their POM, and both are at 5.3.9, as of 2021-11-15.

The point of me saying this was that we should upgrade to Spring 5.3.12 in all three kiwiproject libraries that have a spring dependency.

Actually Spring 5.3.13 is now available, so we should use that.


Request: Bump to rustc stable 1.37.0 (eae3437df 2019-08-13)

Issue description
Simply bumping versions in pkgs/development/compilers/rust/{bootstrap.nix,rustc.nix} and specifying CARGO_HOME=$TMPDIR (#61194) will cause build failure related to LLVM.

Rust 1.37.0 is already in staging https://github.com/NixOS/nixpkgs/pull/66686, it will eventually land into master


<EMAIL_ADDRESS>Monthly update

Updates VSCode to 1.89.0

[x] I have read the Contributing Guide.

I was able to update VSCode from this patch on x64, so I am fairly confident the ARM64 changes are correct as well.

Updated automatically in 886def9.


Custom sleep time adding block

I would set the the time block to 15 minutes.

As soon as you press the timer button, it will show you 5 minutes. If you want to increase it, you have to press the timer button again. The time will always increase by 5 minutes more.

I leave this at 5 minutes so you can vary it better. Some people only want to listen for 10, 20 or 25 minutes and that doesn't work when it's increased to 15 minutes.


Temporarily disable flaky test

This test has failed a few times on my PRs and I'm noticing it failing on several PRs that didn't touch code related to this. I'm disabling this test for now.
See #1725

disturbing but ok.

I'm including the changes from #1727 here because both PRs keep failing on each other


add a :mime-subtype request parameter to override the multipart subtype

This feature has been in HTTPClient since 2014 but clj-http does not have support for it.  As a result, it is impossible to make e.g. multipart/mixed requests with clj-http (unless you construct the body and header yourself).

Merged this, thanks @pkalliok!


Trigger a rule when specific task is closed

I want to set a rule to trigger when a specific task has been closed. I can only manage to get it to work when any task is closed. Is this at all possible?

I am also looking a trigger which is conditional based


implement direct messaging

Do all the work for this issue in the branch issue-27

Thinking collection with

profile 1
profile 2
timestamp
message


Enable debug/trace for parse, unparse and test only

make debug/trace non global and sub option for parse, unparse and test only
update CLI tests

Deprecation/Compatibility:
--trace and --debug are no longer global arguments for daffodil, and are instead arguments for parse, unparse and test only.
DAFFODIL-1141

Does trace in fact work on daffodil test? I'd swear I tried this the other day and got no trace output. Do you perhaps need to do daffodil -t trace -i (both -t and -i in the older syntax) to see the trace output? I definitely wanted this to work and was surprised when it did not. I could not tell you which daffodil version I was using. 3.5.0 or 3.8.0, but I'm not sure which.

Does trace in fact work on daffodil test? I'd swear I tried this the other day and got no trace output. Do you perhaps need to do daffodil -t trace -i (both -t and -i in the older syntax) to see the trace output? I definitely wanted this to work and was surprised when it did not. I could not tell you which daffodil version I was using. 3.5.0 or 3.8.0, but I'm not sure which.

It definitely works for the cli...for both 3.5.0 and 3.8.0 without needing to do anything other than:
daffodil --trace parse -s schema.xsd data.bin
or
daffodil -t parse -s schema.xsd data.bin
I also confirmed Runner.trace works on both 3.5.0 and 3.8.0

I confirmed it also works with the test subcommand with 3.9.0, e.g. daffodil --trace test foo.tdml.

Oh I misunderstood your comment. Attempts to use "daffodil --trace test csv/test/csv.tdml" doesn't work @stevedlawrence  , what tdml file did you use?

Oh I misunderstood your comment. Attempts to use "daffodil --trace test csv/test/csv.tdml" doesn't work @stevedlawrence , what tdml file did you use?

Ah looks like that's because csv.tdml fails. It works when I try "daffodil --trace test daffodil-test/src/test/resources/org/apache/daffodil/section06/entities/Entities.tdml" for 3.8.0 but not for 3.5.0

For CSV I had to run it from the src/ directory so that Daffodil could find the non-embedded schema, e.g.
cd path/to/csv/src/
daffodil --trace test ../test/csv.tdml

I learned --trace or -t with daffodil test DOES work with 3.8.0, does NOT work with 3.5.0.
mbeckerle@orca:~/dataiti/opensource/DFDLSchemas/faketdl$ daffodil --version
Apache Daffodil 3.5.0
mbeckerle@orca:~/dataiti/opensource/DFDLSchemas/faketdl$ daffodil -t test test/TestFakeTDL.tdml test_msg_01
[Pass] test_msg_01

Total: 1, Pass: 1, Fail: 0, Not Found: 0
mbeckerle@orca:~/dataiti/opensource/DFDLSchemas/faketdl$ daffodil -t test -i test/TestFakeTDL.tdml test_msg_01
[Pass] test_msg_01

Total: 1, Pass: 1, Fail: 0, Not Found: 0


Manually trigger with click

I want to trigger the mentionsInput functionality if a user clicks a specific button, in addition to the natural of this plugin.  I have it so an '@' symbol is inserted at the caret position but it doesn't trigger the dropdown.
What am I missing?

+1