Can create an empty question

Explanation
I was hoping to see what the error looked like when leaving some fields blank, but apparently it's ok to leave the question text and correct answer blank too.

Steps to reproduce

As an instructor, go to the form to create a new question.
Submit the form without entering anything.

Severity
Minor.

#127


[PE-D][Tester C] Table of content looks too plain

Table of content looks too dull and plain. Also the size is weirdly small. The fint size is inconsistent between DG and UG  ToC

Labels: severity.VeryLow type.DocumentationBug
original: ishan-agarwal-05/ped#15

Thank you for the suggestions for improvements.
This will be close as it is a non-issue and a issue of personal preference.


Connection inside docker network

Hello,
I am trying to use metabase and clickhouse with the metabase-clickhouse-driver, however, I can't manage to connect to the clickhouse database when using a bridge network. The metabase container manage to communicate with the clickhouse container with ping -c 1 name_clickhouse_container:5432, and when I use --network host  metabase also manage to connect with host localhost, but when I am trying to set name_clickhouse_container as host inside metabase, ther error message says it is missing the port.
Would you know where the issue might reside?
Best regards,
David
I am trying to use this project: https://github.com/plausible/hosting with the docker instruction
docker run -d -p 3000:3000 \
-v ~/metabase-data:/metabase-data \
-net hosting_default \
-e "MB_DB_FILE=/metabase-data/metabase.db" \
--name metabase metabase/metabase

[please adapt the docker call in order to add the clickhouse driver].

Sorry, but the driver does not interfere with any networking, and I do not know enough about Docker networking to help you


Add onWhitespace?

I've been experimenting a bit with Acorn for rewriting JavaScript code, but at the moment it's a bit tricky because there's no direct access to whitespace. If there was an onWhitespace handler, then it would be possible to use that plus onToken and onComment to be able to reconstruct the JavaScript source exactly, which would make rewriting significantly easier.
Is this something you'd be open to?

I don't think this is necessary -- you already have the source string and the offset of a given node into it. Whenever I've needed information about whitespace, scanning for whitespace on node boundaries by indexing into the source string worked wonderfully (and more conveniently than it would be to first accumulate whitespace information through a callback then searching it).

My use case is slightly different, I basically just want to run through the code and replace tokens, so I'd just keep adding whitespace, comments, and tokens onto the result as they come in.
I'm sure I can figure out another way to do it, it just seemed like this was the last missing piece of info not exposed via a method. Thanks for the response!

I see. But can't you just track the current position (the end of the last-seen comment or token) and add a whitespace item whenever a new item comes in that doesn't come directly after the previous one?

Yeah, that's what I'm looking at doing. I thought maybe the parser was accumulating whitespace and would be easy to expose rather than calculate, but it seems that's not the case, so no worries.

Looks like consensus is reached, so I'm closing this issue.


Job Board with Custom Code

[ ] https://github.com/getopenwater/cmsresearch/issues/2 implement there the "Was this article helpful" functionality.  This will require custom code.  @apexdodge to help explain the best way to do it

[ ] Now let's move onto a new site for https://bootleg224.github.io/FrontTheme/demo-jobs/index.html

[ ] implement job listing, job view page; no need yet for apply to job page

[ ] Implement post job page https://bootleg224.github.io/FrontTheme/demo-jobs/post-job.html  this will require server side code, use the same pattern @apexdodge suggested

Helpful video for this project:
https://www.youtube.com/watch?v=RkgyK_wSPEE


Use in python project?

How can we use it to a python code ?
I want to use piper for my project,  since the readme tells only the Command line so i can't do TTS in realtime mode what i mean is if i have a website  that connects to a websocket server where piper is installed , i need to stream the piper audio route back to website ? is it possible ?

Please check out our video in which we used the Piper TTS in Python code
https://www.youtube.com/watch?v=EiInDFhPRvw


read_csv does not apply dtype=str correctly to NA values

Hi,
It seems that read_csv() ignores the dtype=str when encountering NA values. For instance if the contents of file.csv is:
id,symbol
1,NA
NA,g2
3,g3
4,g4
Then df=pandas.read_csv('file.csv', dtype={'id':float, 'symbol':str}) will return the following data frame:
id symbol
0   1    NaN
1   NaN   g2
2   3     g3
3   4     g4
which means it casts NA value in the symbol column as a float. Is this a bug or part of the read_csv design? It would make sense that when dtype=str is specified all the values will be treated as string. Note that in the above example using 'keep_default_na=False' in read_csv will cause an error.
Thanks,

dupe of #10223


Add option to set the file extensions for which parsing is active

Right now, this extension only supports the file extension .edi.
Having the option to also, for instance, parse .270 or .271 files would be very useful.
I'd also be happy to submit a PR if someone could point me to where the file extension settings are in the source, since I haven't had experience with VSCode extensions in the past.

Hey @Polymetric! - that would be great, I always appreciate pull requests.
If you want, you can add extensions to this array:
https://github.com/Silvenga/vscode-edi-x12-support/blob/master/package.json#L45

https://github.com/Silvenga/vscode-edi-x12-support/pull/6

Resolved via #6.


Cannot parse params in Router middleware

Hey, so I'm working on a directory handler that uses the express.Router() in a module, then I app.use("/", require(<module>)) which one of the directories has a parameter in it which causes an DS is not define error within FS
const express = require("express");
const fs = require("fs");

const router = express.Router({mergeParams: true});

router.get("/cdn/:image", function (req, res) { // This is the line with the error
  if(new RegExp(/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/g).test(req.params.image)) {
    if(fs.existsSync(process.cwd() + '/app/images/' + req.params.image + '.jpg')) {
      res.sendFile(process.cwd() + '/app/images/' + req.params.image + '.jpg')
    } else {
      res.send("404 Not Found.")
    }
  } else {
    res.send("404 Not Found.")
  }
});

module.exports = router;

ReferenceError: fs is not defined
    at C:\Users\diamo\Desktop\Local Server V2\app\routes\API\cdn.js:6:5
\index.js:360:14)
    at param (C:\Users\diamo\node_modules\express\lib\router\index.js:371:14)
    at Function.process_params (C:\Users\diamo\node_modules\express\lib\router\index.js:416:3)
ss\lib\router\index.js:281:22
    at Function.process_params (C:\Users\diamo\node_modules\express\lib\router\index.js:341:12)
    at next (C:\Users\diamo\node_modules\express\lib\router\index.js:275:10)
    at Function.handle (C:\Users\diamo\node_modules\express\lib\router\index.js:174:3)
    at router (C:\Users\diamo\node_modules\express\lib\router\index.js:47:12)

https://github.com/expressjs/express/blob/bb7907b932afe3a19236a642f6054b6c8f7349a0/lib/router/index.js#L47
I could be doing something completely wrong, but I've asked others and they have also said it appears to be an issue with Express or I'm using it wrong.
Thanks!

Are you sure you are not using some kind of system that is altering your source files like a compiler of some kind? The error at hand is the JavaScript runtime throwing that the variable fs is undefined when trying to use it. The line 6 column 5 would match exactly to your first fs call if you had something removing blank lines and empty leading whitespace, which is a common thing compilers do...
FWIW Running your code there is Node.js without any type of compiler does not produce an error, so at the very least if you do believe it to be an issue with Express.js, at least I'm not seeing how with the information provided. We'd need completely details of all the code and steps required in order to produce that error in order to better assist.


Add start subcommand in ctr.

Related to #1272
How to test:

Create a container, and then exit

$ ctr run  docker.io/library/busybox:latest test top
Mem: 1035364K used, 4044028K free, 3680K shrd, 101184K buff, 684700K cached
CPU:  3.3% usr  3.3% sys  0.0% nic 93.3% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.00 0.01 0.05 1/210 5
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    1     0 root     R     1216  0.0   1  0.0 top
^C

Execute the ctr start command to start the container again

$ ctr start test
Mem: 1033492K used, 4045900K free, 3680K shrd, 101240K buff, 684700K cached
CPU:  3.3% usr  3.3% sys  0.0% nic 93.3% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.00 0.01 0.05 1/211 6
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    1     0 root     R     1216  0.0   1  0.0 top

Signed-off-by: Yanqiang Miao<EMAIL_ADDRESS>

Codecov Report

Merging #1298 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1298   +/-   ##
=======================================
  Coverage   23.36%   23.36%
=======================================
  Files          45       45
  Lines        4579     4579
=======================================
  Hits         1070     1070
  Misses       3307     3307
  Partials      202      202

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e8625bc...ac72bba. Read the comment docs.

LGTM


experiment: allow non-shared async* types (only)

So that we can write parametric abstractions, in the absence of a shared type constraint.
By popular demand. Fixes (part of) #3892.
Example:
import Debug "mo:base/Debug";
import Array "mo:base/Array";

actor a {

  func expect<T>(a : () -> async* T) : async* T {
    await* a();
  };

  func mapPar<A,B>(args : [A], f : A -> async* B) : async* [B] {
     let vs = Array.init<?B>(args.size(), null);
     for (i in args.keys()) {
        vs[i] := ?(await* f(args[i]));
     };
     Array.tabulate<B>(args.size(), func i { let ?v = vs[i]; v });
  };

  public func f(a : Nat) : async Text { debug_show(a) };

  public func go() : async () {
     let x = await* expect<Nat>(func () : async* Nat {await async 1});
     assert x == 1;

     let vs = await* mapPar([0,1,2], func (a : Nat) : async* Text { await f(a) });

     Debug.print(debug_show vs);
  }
};

Pros: just a minor tweak
Cons:

still requires ugly eta-expansion of shared functions calls.
can't just abstract over async* T (must be a function  U -> async* T) to avoid scope violations.
(Perhaps async* T should be implicitly scope-polymorphic (since the computation is delayed anyway)).
can't use implicit lambda arguments because we don't insert scope parameters for those (a separate, but annoying, issue: our sugar to do so is (syntactically) type driven, which obviously doesn't work when types are omitted.

TODO

[ ] test run-drun/do-async-poly.mo needs revisiting

Oh crap, that's actually mapSeq (sequential map), not mapPar (parallel map), due to lazy semantics of async*. Maybe this doesn't give us what we want unless we also do non-shared async types after all. Will need to experiment some more first.

That's annoying.
Does it have to be lazy?

Does it have to be lazy?

I think it does, if you want await* to demarcate the effects. But I'm open to better suggestions. I think the way to solve this is to lift the restriction on vanilla async t. Still scratching my head here.

I’m not thinking this through, but could async* { e } eagerly start evaluating e until the first actual await? A bit like async { e } “eagerly” (but in a separate threat) starts evaluating e?

I’m not thinking this through, but could async* { e } eagerly start evaluating e until the first actual await? A bit like async { e } “eagerly” (but in a separate threat) starts evaluating e?

That would be the semantics of the 'do async e' I originally proposed, except with a separate type. I guess the problem then is that the effects happen even without 'await*'. With 'async e' nothing happens unless you 'await',

Ah, right

Just doing some repo cleanup for better focussing on active work:
Closing PR as it seems inactive for a longer time. Please re-open if it is still relevant and after it has been updated with latest master changes.


Input challenges to CTFd & export/backup

Lance will put the challenges into the tool and then we will export them and save the backup somewhere. That way we can load the backup when the environment is spun up.

done


Added AngularJS Cheatsheet

What does this PR do?

Add new CheatSheet

Description

Added AngularJS Cheatsheet

Screenshots or Links

NONE

Additional context

NONE

Checklist:

[x] Read our contributing guidelines.
[ ] Search for duplicates.
[ ] Used an informative name for this pull request.

Follow-up

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

Thanks @crescentpartha


Support for TaskWarrior

https://github.com/GothenburgBitFactory/taskwarrior is a beautiful CLI task management application with desktop apps and web frontends.
Some for of support for read/write hooks for event/task list would be great!

yeah, +1, ;-)
On Sat, Aug 6, 2022, 5:42 PM Mina Nagy Zaki @.***>
wrote:

https://github.com/GothenburgBitFactory/taskwarrior is a beautiful CLI
task management application with desktop apps and web frontends.
Some for of support for read/write hooks for event/task list would be
great!
—
Reply to this email directly, view it on GitHub
https://github.com/itchyny/calendar.vim/issues/201, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAR6S6ZFRUNBZIGHVXVXU2LVX3L5RANCNFSM55ZL2G6Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Would like it too !


Catch up to Ecto 2.0.3, released 30 Jul 2016.

Coverage remained the same at 85.783% when pulling 68e0f0b8833dde0d89c6563e0bb49858ce344cb2 on ecto-2.0.3 into dbde1f4f877228b41a9c4b7e36c2d4707ebff162 on master.


[C-Api] new API to flush the pipeline

Add new API to flush the pipeline.
If new input should be run without old data in pipeline, this is necessary to clear all.
Signed-off-by: Jaeyun<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #28. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

2021-04-06 add testcase for pipeline flush (need nnstreamer PR https://github.com/nnstreamer/nnstreamer/pull/3179)

:octocat: cibot: @jaeyun-jung, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nnstreamer-api/ci/repo-workers/pr-checker/28-202104061425500.70041298866272-269221d77f5b243970777c55cca460f0e9f0eb6e/.

:octocat: cibot: @jaeyun-jung, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nnstreamer-api/ci/repo-workers/pr-checker/28-202104091650490.68520498275757-87d1deea20244ab8b120ad08d6581c87af7994eb/.


Add tests for PyTorch 1.9

Fix #189.

Thanks, LGTM. Could you trigger docker image build and configure webhook?

/test

Let's merge so that we can work on supporting PyTorch 1.9 in separate PR.


chore: add .secrets.baseline

This PR adds a .secrets.baseline file to aid us in team codescans.

:tada: This PR is included in version 5.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


isolate styles to reduce collisions

Is your feature request related to a problem? Please describe.
When using Hope UI in parallel with other components, the other components are affected by Hope UI's global CSS reset, even if they are not directly wrapped with <HopeProvider>.

Describe the solution you'd like
Apply the CSS reset starting from a .hope-root container (or something similar), rather than the document root.
For example, Svelte Materialify implements this to some degree and applies most of its styles starting at .s-app; and there can be multiple .s-app roots.

This is possible, however this will require <HopeProvider> to render an extra div element to apply the .hope-root class.

This is possible, however this will require <HopeProvider> to render an extra div element to apply the .hope-root class.

Do you see any downsides to this? I personally prefer that implementation, as it provides the user with more granular control of styles via the .hope-root > * selector namespace, but I'm wondering if you have any additional insights.
If there's a good argument for keeping the global implementation, maybe a new <HopeFragment> component could be introduced to provide the alternate functionality without removing the ability to use global scope as well.

The extra div in HopeProvider might break some user's css and cause layout issue. One other alternative can be making all Hope UI components independent of the css reset and provide it as component like <CssReset /> but this will take much more time to do

Or like MUI we can use a <CssReset /> component which is global and renderless and a <ScopedCssReset> which render a div with the scoped reset.
Or add a globalCssReset props to the HopeProvider which is true by default (no breaking change) and you set it to false and manually wrap Hope UI components with the <ScopedCssReset>

Or just a scopedCssReset props which is false by default (for global reset) and when you set it to true HopeProvider wrap it's children with the scoped one for you.
I think this one has the better DX.

After some experimentation it will be more complicated than I expected. Having scoped css reset under an .hope-root selector break some components styles. For example .hope-root a selector break css classes applied to the <Anchor> component which have a lower specificity (11 vs 10).

Or just a scopedCssReset props which is false by default (for global reset) and when you set it to true HopeProvider wrap it's children with the <ScopedCssReset> for you.

That seems like a pretty good implementation 👍

For example .hope-root a selector break css classes applied to the  component which have a lower specificity (11 vs 10).

Just checked out how the CSS was being implemented and saw that you're using stitches, which I'm not familiar with. Is this something that can be overcome with their style API?


mobile: make Envoy::DirectResponseTesting::MatchMode an enum class

They seem to have a number of advantages over "plain" enums according to https://stackoverflow.com/a/18335862, and this will allow them to be imported properly into Swift.
Similar to https://github.com/envoyproxy/envoy/pull/26036
Commit Message:
Additional Description:
Risk Level: Low, only used for Swift tests at the moment.
Testing: Existing tests.
Docs Changes: None.
Release Notes: None.
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/assign @RyanTheOptimist


A11y_AzuredataStudio_ManageAccessForFile_ScreenReader:Name property of check box is not announced by Voice Over .

GitHubTags: #A11y_AzureDataStudio;#A11yMAS; #A11yTCS;#SQL Azure Data Studio;#WCAG1.3.1;#WCAG4.12;#WCAG4.2.1;#sktopApp;#Win10;#Voice Over;
**Environment Details: **
Application Name: Azure Data Studio
Version: 1.12.0-insider (user setup)
Commit:6582debd7388b1be512fc3a9b956d3e54f6115e7
Date: 2019-10-03T08:56:27.454Z
VS Code: 1.38.0
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: MacOS Mojave 10.14.6
Additional Details:
Tool Name : VoiceOver
Steps to Reproduce:
1.Install and Launch the application the azure data studio application.
2.Connet to the servers with the required credentials.
3.Navigate to the control panel and click on the “Jupyter books” icon.
4.Navigate till HDFS folder and right click on it and click on manage access.
5.Start Voice Over and observe the announcement.
Actual:
Voice Over is Not announcing name property of the check box.
Expected:
Voice Over should announce name property of the check box.
User Impact:
Screen Reader user will not able to relate with the Check box.
Attachment for Reference:
7943_A11y_AzuredataStudio_ManageAccessForFile_ScreenReader.pptx
Does this issue occur when all extensions are disabled?: Yes

Closing as a duplicate of https://github.com/microsoft/azuredatastudio/issues/7799.

GitHubTags:#SQLADS-MAC-May2019;


Feature suggestion for trillium-api: ApiConnExt should include is_json_request()

This is primarily used for content negotiation or special handling for api vs non api requests.
pub async fn not_found(conn: Conn) -> Conn {
    if conn.is_json_request() {
      conn.with_status(404).with_json(JsonError { message = "Not found", code = "NotFound" }).halt()
    } else {
       conn.with_status(404).with_body("Not Found").halt()
    }

}

Closing this issue as it was written in regards to trillium-api-v0.1. Additionally, "json request" is unclear, as it could either refer to Accept or Content-Type. In the example above, it is being used to determine response format, which should be based on the Accept header, but #227 uses Content-Type.


MSYS-appveyor-install.bat: use mingw-w64-xxx variants

Use mingw-w64-xxx variants of openssl and zlib on MSYS2 build for Windows

This PR needs an update so it can rebuild and pass.

Should be working now.

Thanks!


feat: add EmptyStateErrorMessage and update a11y test dependency

Closes #27

Preview: https://AI-infra-ui-components-pr-64.surge.sh

I am now looking at component groups and wondering if this component is necessary to introduce, given that there already is ErrorState / MissingPage /... and these other EmptyState use cases.

That gives me an idea - let me take a second stab at this

Once this component-groups issue gets resolved, we can use this component rather than reexport that component here (to make sure the API matches the old implementation in RHOAI


Fix a signedness compiler warning in vector.to_py

When compiling cythonized code which uses std::vector we get the following compiler warning on GCC 8 and Python 3.9 (which is turned into an error in our case):
my_file.cpp: In function ‘PyObject* __pyx_convert_vector_to_py_int(const std::vector<int>&)’:
my_file.cpp:4716:33: warning: comparison of integer expressions of different signedness: ‘Py_ssize_t’ {aka ‘long int’} and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
   for (__pyx_t_5 = 0; __pyx_t_5 < __pyx_t_4; __pyx_t_5+=1) {
                       ~~~~~~~~~~^~~~~~~~~~~

The generated code in question is as follows:
/* "vector.to_py":75
 *     cdef object item
 *
 *     for i in range(v.size()):             # <<<<<<<<<<<<<<
 *         item = v[i]
 *         Py_INCREF(item)
 */
  __pyx_t_3 = __pyx_v_v.size();
  __pyx_t_4 = __pyx_t_3;
  for (__pyx_t_5 = 0; __pyx_t_5 < __pyx_t_4; __pyx_t_5+=1) {
    __pyx_v_i = __pyx_t_5;

__pyx_t_5 is of type ‘Py_ssize_t’ (signed), and __pyx_t_4 aka __pyx_t_3 is size_t (unsigned), causing GCC to rightfully complain.
Fix the generated code by explicitly using the signed variant of the vector's size in the loop.
This bug has been introduced in
https://github.com/cython/cython/pull/4081, which also contains some discussion on the use of signed vs unsigned types. This patch chooses to keep the status quo and only fixes the compiler warning.

Thanks, that looks god.


Use controller.backendconfig instead of custom BackendConfig

There's no need to create a separate BackendConfig - there are provisions for this in the helm chart already. See https://github.com/jenkinsci/helm-charts/blob/main/charts/jenkins/VALUES_SUMMARY.md#gke-backendconfig as a reference.

Using backendconfig from the helm chart now.


Updated solr to 7.7.3

fixes https://github.com/antleaf/nims-mdr-development/issues/502
I was able to build and save changes without any errors or additional changes required.
PLEASE DO NOT MERGE. I used image solr:7.7.3. I will change this to solr:7 and test again

I also tested with solr:7 and it works


Suppress memory leak report in glibc NSS under Ubuntu

There is absolutely nothing we can do about this leak, reported in both
MySQL and PostgreSQL tests for getpwuid() called from inside the
corresponding client libraries, so just suppress it.

Applied as 4f1fbfcd4698dc8a4fcacf650635bb8fae75ada8, this does help a bit, even if it's not enough to fix Valgrind run yet.


Tag Editor

Project description
A tag editor with Qt GUI and command-line interface. Supports MP4 (iTunes), ID3, Vorbis, Opus, FLAC and Matroska.
Metadata

homepage URL: https://github.com/Martchus/tageditor
source URL: https://github.com/Martchus/tageditor
license: mit, GPLv2.0
platforms: linux

I am working on it.
Progress: https://git.beyermatthi.as/nixpkgs/log/?h=init-tageditor


Mac OS X: no probe was found

Brandons-MacBook-Air:rp2040-project-template brandonros 2022-03-02 17:50:45 $ probe-run --list-probes
Error: no probe was found.

Common reasons for this are faulty cables or missing permissions.
For detailed instructions, visit: https://github.com/knurling-rs/probe-run/tree/2f138c3#troubleshooting

$ elf2uf2-rs --verbose --deploy ./target/thumbv6m-none-eabi/debug/rp2040-project-template
Found pico uf2 disk /Volumes/RPI-RP2
Detected FLASH binary
Mapped segment 0x10000100->0x100001a8 (0x10000100->0x100001a8)
Mapped segment 0x10000000->0x10000100 (0x10000000->0x10000100)
Mapped segment 0x100001a8->0x10003208 (0x100001a8->0x10003208)
Mapped segment 0x10003210->0x10003a98 (0x10003210->0x10003a98)
Mapped segment 0x10003a98->0x10003ac8 (0x2003fbc8->0x2003fbf8)
Uninitialized segment 0x2003fbf8->0x20040000 (0x2003fbf8->0x20040000)
Transfering program to pico
Page 0 / 59 0x10000000
Page 1 / 59 0x10000100
Page 2 / 59 0x10000200
Page 3 / 59 0x10000300
Page 4 / 59 0x10000400
Page 5 / 59 0x10000500
Page 6 / 59 0x10000600
Page 7 / 59 0x10000700
Page 8 / 59 0x10000800
Page 9 / 59 0x10000900
Page 10 / 59 0x10000a00
Page 11 / 59 0x10000b00
Page 12 / 59 0x10000c00
Page 13 / 59 0x10000d00
Page 14 / 59 0x10000e00
Page 15 / 59 0x10000f00
Page 16 / 59 0x10001000
Page 17 / 59 0x10001100
Page 18 / 59 0x10001200
Page 19 / 59 0x10001300
Page 20 / 59 0x10001400
Page 21 / 59 0x10001500
Page 22 / 59 0x10001600
Page 23 / 59 0x10001700
Page 24 / 59 0x10001800
Page 25 / 59 0x10001900
Page 26 / 59 0x10001a00
Page 27 / 59 0x10001b00
Page 28 / 59 0x10001c00
Page 29 / 59 0x10001d00
Page 30 / 59 0x10001e00
Page 31 / 59 0x10001f00
Page 32 / 59 0x10002000
Page 33 / 59 0x10002100
Page 34 / 59 0x10002200
Page 35 / 59 0x10002300
Page 36 / 59 0x10002400
Page 37 / 59 0x10002500
Page 38 / 59 0x10002600
Page 39 / 59 0x10002700
Page 40 / 59 0x10002800
Page 41 / 59 0x10002900
Page 42 / 59 0x10002a00
Page 43 / 59 0x10002b00
Page 44 / 59 0x10002c00
Page 45 / 59 0x10002d00
Page 46 / 59 0x10002e00
Page 47 / 59 0x10002f00
Page 48 / 59 0x10003000
Page 49 / 59 0x10003100
Page 50 / 59 0x10003200
Page 51 / 59 0x10003300
Page 52 / 59 0x10003400
Page 53 / 59 0x10003500
Page 54 / 59 0x10003600
Page 55 / 59 0x10003700
Page 56 / 59 0x10003800
Page 57 / 59 0x10003900
Page 58 / 59 0x10003a00

elf2uf2-rs worked fine

Hi! The RP2040 has a USB Mass Storage based ROM Bootloader. Unfortunately this is only suitable for uploading UF2 files, and cannot be used as a debugger with Probe Run. elf2uf2-rs works by finding where the drive is mounted and cp'ing the UF2 file to the mounted folder.
You will need a Raspberry Pico running DapperMime firmware, or some other supported Debug Probe to work with probe-run.

PR #304 documents this more clearly.


Traffic Extract's "end" Parameter not behaving as expected

Appreciate the new 11.3.6 feature to designate traffic export start and end parameters with date time precision.
However, the parameters values are not constraining the data export as expected.
This command:
workloader.exe traffic -s 2024-08-15T11:00:00Z -e 2024-08-15T11:01:00Z --output-file SomeMinutes.csv
....produces a file with records spanning more than the designated time range.
Results indicate that the start parameters is properly being utilized, but the end parameter is not, as data always goes through 23:59:59 of the specific date]

@fwalton-tm can you share a redacted version of your workloader.log for that one command? the log should have the json body sent to the API. I'm really just interested in the timestamps being generated in the JSON. Everything else can be redacted.

When I use those parameters, I am seeing the following, which looks right:
{"sources":{"include":[[]],"exclude":[]},"destinations":{"include":[[]],"exclude":[{"transmission":"broadcast"},{"transmission":"multicast"}]},"services":{"include":[],"exclude":[]},"start_date":"2024-08-15T11:00:00Z","end_date":"2024-08-15T11:01:00Z","policy_decisions":[],"max_results":100000}

(Note - the -s and -e flags should not have the Z at the end. Those will throw errors.

Code generated to invoke API does seems correct.
Possible that the API is not interpreting it correctly?
Two other items of note,

I tried both with and without trailing "Z", same result each way
The extractor generates ~550K records each day, despite the record limit parameter

Blocked from uploading files here, sending log separately

Attached file contained metadata pertaining to the last few invocations, including one prior to the file update.
/ Thanks
Fred
From: Brian Pitta @.>
Sent: Thursday, August 15, 2024 15:31
To: brian1917/workloader @.>
Cc: Walton, Frederick @.>; Mention @.>
Subject: Re: [brian1917/workloader] Traffic Extract's "end" Parameter not behaving as expected (Issue #107)
[External]
@fwalton-tmhttps://github.com/fwalton-tm can you share a redacted version of your workloader.log for that one command? the log should have the json body sent to the API. I'm really just interested in the timestamps being generated in the JSON. Everything else can be redacted.

Reply to this email directly, view it on GitHubhttps://github.com/brian1917/workloader/issues/107#issuecomment-2292400654, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BJYJZOUNTHAD7T7YNFKJN6DZRUT3JAVCNFSM6AAAAABMS7STSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJSGQYDANRVGQ.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


Added a warning about signed commit issues

This will only work if pipelining is enabled. You'll also have to change DeployForm to include the message I believe for environments that don't have pipelines enabled or configured.
Note: It's been years since I've touched Deploynaut code, I could well be wrong :)

Could someone else confirm this? I have no idea of how Deploynaut is structured - this was the only template change I could infer from the URL I use to deploy...
@hafriedlander @halkyon @stojg @mateusz

Looks like one possible solution for the older version of deploynaut. But I would be keen to get an related issue. I saw @madmatt opened an issue in the gitlib package at https://github.com/gitonomy/gitlib/issues/108

Yeah, I was thinking that gitlib was some kind of PHP extension, but it's actually just a PHP script shelling out to git, so it's much easier for us to just fix ourselves :)

This looks like it can be closed, as the issue was fixed upstream in gitonomy. @stojg Can you confirm?

I'm closing it, it's fixed as far as I can tell. If not, feel free to reopen.


Proposal to add C++ code editor in Engine as Addon

The idea is to keep this as easy as possible. The workflow would be similar to this: https://libriscv.no/docs/godot/rustprogram
Rust Usage Workflow:
When creating a Script you have option to create Rust script file:

Create file (just normal C++ file)

Edit c++ files in the editor

Compile them

Since this would be generic, it would probably support GDExtension. So you would how to be able to write c++ code and build it, either when using regular CMake projects, SConstruct projects (when doing GDExtension addon), or something else.
Autocomplete
For this the code needs to be processed to offer autocomplete options
Build
For this there can be a build option, similar to how C# has. Also, if not, when Saving files and/or when running project, build the code to a GDExtension or DLL (custom lib).
Compiler
As for building, we could support either setting compiler path and using that, or using local Docker and use that (send files to the Docker and get the binary output and save it).

Hi, maybe this is off topic, but wouldn't it be easier to write everything in gdscript and before creating the executable use something like the plugin (https://github.com/Lcbx/GdScript2All) that translates the code and creates the executable with the selected code?

Interesting, will read that and see how it is useful and where it could fall into all this.

Yeah, this needs the Godot 4.4 to work (with godot-sandbox module)


SaltRemover don't remove salt depending on the SMILES representation.

I use SoltRemover in removing benzoate from Alogliptin benzoate (https://pubchem.ncbi.nlm.nih.gov/compound/16088021), but I think it does't work well.
from rdkit import Chem
from rdkit.Chem.SaltRemover import SaltRemover

# use C instead of Alogliptin (CN1C(=O)C=C(N(C1=O)CC2=CC=CC=C2C#N)N3CCC[C@H](C3)N) to simplify code.

# case. 1: NG don't remove benzoate
remover = SaltRemover(defnData='C1=CC=C(C=C1)C(=O)O') # benzoate
Chem.MolToSmiles(remover(Chem.MolFromSmiles('C.C1=CC=C(C=C1)C(=O)O'))) # C benzoate
>>> 'C.O=C(O)c1ccccc1' #  don't remove benzoate

# case. 2: OK remove salt without ring
remover = SaltRemover(defnData='C=CC=C(C=C)C(=O)O') # remove ring from benzoate
Chem.MolToSmiles(remover(Chem.MolFromSmiles('C.C=CC=C(C=C)C(=O)O')))
>>> 'C' # salt removed

# case. 3: OK another representation of benzoate
remover = SaltRemover(defnData='c1ccccc1C(=O)O') # alternative benzoate representation
Chem.MolToSmiles(remover(Chem.MolFromSmiles('C.C1=CC=C(C=C1)C(=O)O')))
>>> 'C' # salt removed

Thanks.

Oops, I misunderstood defnData. It's not SMILES but SMARTS, right?
It seems suitable behavior. sorry.

Yeah, the defnData is SMARTS.


Add integrations list page

Need help on the content that we want to add.

I see - I didn't realize that the front matter supported all of yaml. I'll throw it in there

Feedback on frontend:

[ ] Buttons render a little off, that may just be a local CSS issue I have.
[ ] Add ability to give example apps for integrations that we haven't yet built, or link to other content like a blog post. For languages besides Python, all integrations will fall into this category.

For some languages we might have multiple example applications. Could we think about how to display multiple apps with maybe a description for each?
For the backend I think we should just do something similar to the error tracking API I built that uses the Notion API. That was pretty straightforward and would be an easy way to capture this data.


@include-media within a rule body?

I love that this plugin exists! Is it possible to use the include-media declaration from within a rule (like you could in scss)? I got so used to doing things like this in sass that in trying to switch from the old way to the new way feels prehistoric.
scss:
.sidebar {
  font-size: 12px;
  @include media(">tablet") {
    font-size: 14px;
  }
  @include media(">desktop") {
    font-size: 16px;
  }
}

The above doesn't compile with postcss + postcss-include-media. It seems that this plugin requires the declaration outside the rule body (like raw css)?
.sidebar {
  font-size: 12px;
}

@include-media(">tablet") {
  .sidebar {
    font-size: 14px;
  }
}

@include-media(">desktop") {
  .sidebar {
    font-size: 16px;
  }
}

Is there another plugin I need to add to the stack in order to get this behavior, is there a technical limitation, or is this functionality worth adding to this plugin?

I was mainly looking forward to using this plugin for this exact functionality.. Have you solved the issue?
@jackmcpickle , could you please elaborate if this functionality that @jkeen is possible to achieve?

@pavlexander Yes. Updated the tests and docs/readme. You need postcss-nested too. Load that before and you should be good. Will look to including it in maybe later.
Sorry for late reply @jkeen. Missed this issue.

@jackmcpickle This works, but is there a way to make it so that it's using @include media(...) as opposed to @include-media(...)?
My Scss theme doesn't like that syntax apparently, and prettier wants to toss a space after -media.

So looking deeper @ekfuhrmann Seems the AST for @ rules in postcss treats it different.
See
for line @include media('>=phone') {
atRule: {
      name: <ref *2> AtRule {
        raws: {
          before: '',
          between: ' ',
          afterName: ' ',
          semicolon: false,
          after: ' '
        },
        type: 'atrule',
        name: 'include',
        parent: <ref *1> Root {
          raws: [Object],
          type: 'root',
          nodes: [Array],
          source: [Object],
          proxyCache: [Circular *1],
          lastEach: 1,
          indexes: [Object],
          [Symbol(isClean)]: true,
          [Symbol(my)]: true
        },
        source: { start: [Object], input: [Input], end: [Object] },
        params: "media('>=phone')",
        nodes: [ [Rule] ],
        proxyCache: [Circular *2],
        [Symbol(isClean)]: false,
        [Symbol(my)]: true
      }
    }

I'm happy to add in a config for this.

@ekfuhrmann Pushed 1.1.0 release. supports ruleName config. See readme.

This is incredible! With that I changed it to use @media and it works like a charm. Thank you so much for being able to implement that so quickly as well as document it!

@ekfuhrmann thats strange. If I try the same thing in my tests it works. But this is in an isolated state. So maybe in real world setting with many plugins and nested css it doesn't work. “¯_(ツ)_/¯“

It didn't begin to log the error until I had a bracket comment in my scss .
@use '../base/typography';

.tag {
  color: lime;

  @media ('>=md') {
    color: red;
  }

  // Comment here caused the console to log the error
  &__label {
    @include typography.h1;
  }
}

It's possible that some other stuff in my config is the culprit here. No matter, should it come up for someone else, using a different name fixes the error.

Having @media ('>=md') { does look a bit magic. 😅

Having @media ('>=md') { does look a bit magic. 😅

hah, I like simplicity. I settled for @mq ('>=md').
Thanks again for the plugin. I've long loved the old scss include-media and am happy to see it living on strong in postcss!


Add initial Plugin specification

This PR adds a new Plugin entity type. It is modelled like the Module entity.
A plugin and a module both have immutable commits and a label history. Which means they can be similarly referenced within configuration files by a label or an explicit commit.
Note, given the similarities between commits and labels, there's an alternative proposal by @doriable in https://github.com/bufbuild/registry-proto/pull/132#issuecomment-2407967961 to avoid duplicating common definitions.

At the top-level, it seems like we are making carbon copies of definitions for resources, commits, and labels here, which makes sense from the perspective that these are shared concepts. But because of that, I also think rather than making copies, we should actually be defining our APIs to reflect the fact that they are shared. My thoughts are something that looks like:
(main %=)🐱~/src/buf/registry-proto @ $ tree .
.
├── buf
│   └── registry
│       ├── resource
│       │   ├── module
│       │   │   └── v1
│       │   │       ├── file.proto
│       │   │       ├── graph.proto
│       │   │       ├── graph_service.proto
│       │   │       ├── module.proto
│       │   │       └── module_service.proto
│       │   ├── plugin
│       │   │   └── v1
│       │   │       ├── code_generation.proto
│       │   │       ├── collection.proto
│       │   │       ├── plugin.proto
│       │   │       └── plugin_service.proto
│       │   └── v1
│       │       ├── commit.proto
│       │       ├── commit_service.proto
│       │       ├── digest.proto
│       │       ├── download_service.proto
│       │       ├── label.proto
│       │       ├── label_service.proto
│       │       ├── resource.proto
│       │       ├── resource_service.proto
│       │       └── upload_service.proto
│       ├── module (same as current)
│       ├── owner (same as current)
│       └── priv (same as current)
├── buf.lock
└── buf.yaml

Or alternatively, a slightly less nested structure:
(main %=)🐱~/src/buf/registry-proto @ $ tree .
.
├── buf
│   └── registry
│       ├── module
│       │   ├── v1 (same as current)
│       │   ├── v1beta1 (same as current)
│       │   └── v2
│       │       ├── file.proto
│       │       ├── graph.proto
│       │       ├── graph_service.proto
│       │       ├── module.proto
│       │       └── module_service.proto
│       ├── owner (same as current)
│       ├── plugin
│       │   └── v1
│       │       ├── code_generation.proto
│       │       ├── collection.proto
│       │       ├── plugin.proto
│       │       └── plugin_service.proto
│       ├── priv (same as current)
│       └── resource
│           └── v1
│               ├── commit.proto
│               ├── commit_service.proto
│               ├── digest.proto
│               ├── download_service.proto
│               ├── label.proto
│               ├── label_service.proto
│               ├── resource.proto
│               ├── resource_service.proto
│               └── upload_service.proto
├── buf.lock
└── buf.yaml

In either case though, I think the API should reflect what the shared entities are. This proposal would also come with the following changes:

This would add P1 as a new digest type to the overall digests, and then I think I would want to use protovalidate rules to enforce B* digests for module and P1 digest for plugins.
Download/upload contents would now be one-ofs of module content, check plugin content, code generation content
Resource would now be one-of the following: Module, Plugin, Label, or Commit

I am open to different names other than "resource", this just felt consistent with what we have right now. But basically, I think the premise of this is that if there were any foundational changes to either labels and/or commits, right now it's implicit that you need to update both modules and plugins, whereas this would make it explicit.

@bufdev did you have an opinion on @doriable 's proposal in https://github.com/bufbuild/registry-proto/pull/132#issuecomment-2407967961
Afaics the initial module API was intentionally designed to isolate all the module-related definitions. Did we want to revisit this with the addition of plugins?

@bufdev did you have an opinion on @doriable 's proposal in https://github.com/bufbuild/registry-proto/pull/132#issuecomment-2407967961

I think in principle, I'd agree with it - we're trying to merge our understanding of how resources are versioned (commits, labels), and it would be nice if the API reflected that. However, when you actually look at what that means implementation-wise, it will be a significant refactor without much/any gain product-wise - we're talking weeks of work here without a payoff. You'll have to keep around all the existing module.v1 and module.v1beta1 types as they have shipped in v1 and are used by the CLI - removing the services isn't an option. I would instead strive to keep the common types as closely-matched as possible (see source_control_url et all above), giving us the ability to merge our concept of resource in a v2 set of API packages in the future.

To recap:

Make collection a well-defined entity with a read-only service to GetCollections and ListCollections. This is a many-many relationship, so we we'll have collections_ids on the Plugin.
Remove the Plugin managed field. We don't need it initially. We will revisit it once we have Buf-managed check plugins.
description and source_url belong to Plugin / Module entity, updateable via the UI or API.

documentation and source_control_url belong to commits, immutable.
bufbuild/bufplugin updated accordingly

Okay to depend on bufplugin protos, pull them in as a dependency. Add PluginInfo to Commit.
Punt on protoc plugins. Focus on check plugins. We don't need to solve this to ship check plugins.
Potentially some renaming of the bufplugin to just plugin, unlikely to change to naming to "extensions".

I would probably keep in v1beta1 for a little bit unless you're supremely confident this is the final shape, but up to you

It was changed back to v1beta1 in dea5e2a2.
I'd feel more confident marking it as v1 once we've flushed out code generation plugins.


Cant figure out hljs-source

Hey there - pretty new to angular and cant for the life of me figure out hljs-source.   I have a modal that pops up and renders code.  I need that rendered code to be highlighted.  I've tried everything but I feel like it should be simple!  I would appreciate any help!

{{currentPost.code}}

Try this

holy crap that worked! thanks for the quick response, i really appreciate it!


doc: fix typo

Maybe we can also 1) change the example in https://ml.energy/zeus/reference/monitor/energy/#zeus.monitor.energy.ZeusMonitor to use a global ZeusMonitor variable, 2) provide a dummy training function (e.g., implemented by sleep) so that users can run the demo easily?

Yeah, that makes sense. I'd be happy to review the PR if you're willing to implement the change.

https://github.com/ml-energy/zeus/pull/70


Github action queue

Sometimes I push 2 or 3 times rapidly, which causes the queue to build up.
The GitHub feature cancels jobs if a newer job for that PR exists.
This would cut down on GitHub operating costs.
We can't do this for the terraform jobs because of the state lock.

@rin-skylight I've been updating our GH actions over time; this is complete!


Array literal with explicit as type uses alias of given type.

I came across this behaviour while working on #2094.
It appears that an array literal, even when the as type is given explicitly, uses the alias of the as type as the type argument for the Array type. Consider the following example:
trait iso T
class iso A is T
class iso B is T
class iso C is T

actor Main
  new create(env: Env) =>
    let a: T = A
    let b: T = B
    let c: T = C
    let abc: Array[T] = [as T^: A; B; C] // works
    let abc': Array[T] = [as T: A; B; C] // fails: literal has type Array[T!]

I can understand why this works the way it does (the literal elements must actually have type T^ so that they can be pushed into an Array[T]), but I think it's cumbersome, and also surprising that it doesn't follow the same semantics as a let reference with a type (compare the first few lines of the example above with the array literal lines).
I'm going to propose this be shifted so that the semantics of the element type as it relates to the type argument is still the same (the alias of the element type is the type argument), but the as type is considered to be the aliased element type, not the pre-aliasing element type. In other words, the as type would just be the type argument that gets passed to the Array.
I think this would be less cumbersome and less confusing. Thoughts?

We decided on the sync call that this was a principle of least surprise bug.


[Modal] Fix style tab image and add usage guidance around spacing

Take out the style image of the red spacer next to a text input. We want to allow people to use that space for everything other than body copy.
Need to also update usage guidance to reflect this
Conversation:

fixed


Separate each line of the quotes and add spacing between each paragraph

It would look great to me if we could separate each line of the quotes and add spacing between each paragraph!
To separate each line of the quotes, we could add + "
" after the line here:
https://github.com/whateverzpy/LeetCode-Markdown/blob/4ebf864fcc72b99093fea540bc7c224fbd3ca803/content-scripts/content.js#L23
To add spacing between each paragraph, we could probably check if the content is "Example 1:", "Constraints:", or "Follow\-up:", and add "
\n\n" before "**" for it:
https://github.com/whateverzpy/LeetCode-Markdown/blob/4ebf864fcc72b99093fea540bc7c224fbd3ca803/content-scripts/content.js#L8-L10

Can you come up with a specific example of a leetcode problem and show how it works? Thanks!

Sure! :)
So here is a markdown file generated from 3. Longest Substring Without Repeating Characters.
^ As you can see, there are no line breaks between Input, Output, Explanation in the Example 1, 2, 3 in the Preview.
And here is a version I'm looking forward to.
^ In addition to adding line breaks into the Examples, we may also add a little spacing between the description, Examples, and the Constraints!
Here is the diff.
^ As you can see, I simply add
 tags at the end of each line of the Examples, and the places I would like to add some spacing.
But actually, I did notice that this line break thing is kind of a markdown parser issue after I posted this issue...
Like you would also need two line breaks to be able to move the text after the cursor to a different line in a markdown file on GitHub, or it will still in the same line. But in here, the comment block I'm writing right now, one line break moves the text after the cursor to a new line. You don't need additional
 tags to separate each line of the Examples if you paste the generated markdown here...
So I'm thinking about adding some options (checkboxes) into it, something like

[ ] with
 tags at the end of each line in a quote.
[ ] with
 tags for the spacing between each section.

Then users can choose the markdown format they want.
But not sure if this would be a feature you would like to add...

Whether in an online Markdown editor, Typora, or VS Code, the input, output, and explanation sections seem to be rendered consistently with the original problem format. So I decided not to add this feature.

However, the unexpected line break occurred in the longest substring section above.(I will try to fix it, maybe you can help 😂)
Anyway, thanks!

Yeah, I did notice some editors deal with the Markdown syntax as we expect.
(My VS Code does not though😖...)

However, I saw this answer on Stack Overflow. It includes the original Markdown specification.
You can see that the creator of Markdown intended not to convert every line break to a
 tag.
But what really caught my attention was:

When you do want to insert a
 break tag using Markdown, you end a line with two or more spaces, then type return.

I would probably never know this if I didn't see it here😂.
So, instead of adding
 tags directly into the Markdown, what we should do (if we want) is to add two spaces at the end of the line. Then the next line will become a new line in standard Markdown syntax!
I believe adding two spaces at the end of the line won't even cause an additional line break into those editors you mentioned? What do you think, would you like to do it if so?
As for adding spacing between each section, I see there are actually

 tags there. Would you like to try to convert them to
 tags? (Two spaces does not seem to work for adding the spacing...)
Yeah, I did notice the "substring" issue there haha. But I couldn't find out the reason easily. Actually, I'm not even very familiar with JavaScript or HTML, or have an environment to test and fix it. I just read your code and guess actually 🤣. I could create a new issue for this though... (if you want)🤣🤣🤣

Please email me<EMAIL_ADDRESS>Perhaps we can exchange more information.


Fixes rewrite path example and discovery

Given that we would like to make the following rewriting (in both discovery and declarative context)

/foo  to /
/foo/ to /
/foo/anything/else to /anything/else

We need to

force the presence of a leading / after rewriting as we may result in an empty uri path otherwise (this happens with current example)
exclude it from remaining group

For more consistency, this should be the default behaviour for discovery.
See #1282
See #1359
See #1360
I implemented unit tests to validate the expected behaviour.

Any news on this? Small contribution...

So basically, this doesn't require the trailing slash on the discovery locator? I think that's fine

@spencergibb yeah that's that. The idea is to both handle  /foo and  /foo/ as rewritten to / in order not to have empty path in first case


added limits to rule api

I see several unrelated commits by @Nexucis in here, could you restrict the PR to just the relevant changes?
Also, was this change discussed somewhere previously (I don't see an issue reference or such)? Generally adding limits to the API is an interesting question, as limits should normally come with offsets and paging as well, which is something we have decided not to do yet in Prometheus (because it would require much more state-keeping on the side of the Prometheus server to be able to serve subsequent pages). In any case it would at least require some discussion (either on the dev mailing list or GitHub Discussions) to figure out if and how to do this across all of our API endpoints.

Ah sorry! I did not see the referenced issue https://github.com/prometheus/prometheus/issues/9342

The "limits" being referred to over here aren't related to the API. This PR adds the new limit field in the rule group to the rules API response.


Support custom foreign key names (continued work of #1311)

This PR has missing unit tests for PR #1311.
This PR enables declaring custom foreign key name.
t.integer('key_name_id')
  .references('target_table_id')
  .inTable('target_table_name')
  .withKeyName('foreign_key_name')

https://github.com/tgriesser/knex/compare/master...vellotis:feature/support-custom-foreign-key-names?expand=1#diff-b91681a6009d38db70d89305944b4318R166
t.foeign('key_name_id', 'foreign_key_name')
  .references('target_table_id')
  .inTable('target_table')

https://github.com/tgriesser/knex/compare/master...vellotis:feature/support-custom-foreign-key-names?expand=1#diff-b91681a6009d38db70d89305944b4318R173
Closes #1311
Closes #415

Thanks! Feature look good 👍 Documentation is needed for this, but I'll include this to next release anyways. https://github.com/knex/documentation/issues/21


Unable to create an alpine VM

Describe the bug
Unable to create an alpine VM.
Error message:
create 'alpine-dns': setup: do initial setup: run command '[adduser -u 326009303 -D -s /bin/sh richardd]': exit status 1; output: adduser: number 326009303 is not in 0..256000 range

To Reproduce
Steps to reproduce the behavior:

Try to add an alpine VM

Expected behavior
Expect to have a created VM.
Screenshots

Logs
Attach log files by opening OrbStack's Help menu and clicking “Show Logs”, or email them for privacy.
vmgr.log
PLEASE ATTACH THE ENTIRE LOG FILE WITHOUT REMOVING ANY LINES. There is usually important context earlier in the log.
Info report

OrbStack info:
  Version: 0.13.0 (130000)
  Commit: ba57f21d6c60d45e0469196f4a67c79ec9911eea (v0.13.0)

System info:
  macOS: 13.2.1 (22D68)
  CPU: arm64, 12 cores
  CPU model: Apple M2 Max

Additional context
Add any other context about the problem here.

Duplicate of #134. Unfortunately there's no workaround right now since Alpine's user management tools reject Active Directory UIDs.


Don't Merge! PR real time test for source branch full build

OPS Build status updates of commit 682af23:
:clock10: Pending: waiting for processors (11 builds ahead of you)
:warning: OPS Build is busy, currently there are 11 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

OPS Build status updates of commit 682af23:
:clock10: Full build: the average full build time is 6 min(s) 13 sec(s) This is based on the last 113 build(s) for this repository
:warning: This is a FULL build due to a configuration change (usually in openpublishing.publish.config.json and/or docfx.json). It is strongly suggested to merge this configuration change after the business hours, as it could impact the overall build performance of other PRs on the '.openpublishing.publish.config.json' branch. For more detailed info, please click here.

OPS Build status updates of commit 682af23:
:clock10: Full build: the average full build time is 6 min(s) 13 sec(s), this is based on the last 113 build(s) for this repository.
:warning: This is a FULL build due to a configuration change (usually in openpublishing.publish.config.json and/or docfx.json). It is strongly suggested to merge this configuration change after the business hours, as it could impact the overall build performance of other PRs on the '.openpublishing.publish.config.json' branch. For more detailed info, please click here.

OPS Build status updates of commit 682af23:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

docfx.json
:white_check_mark:Succeeded

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


[KOGITO-4469] - Conditions should reflect latest evaluated status

Signed-off-by: Karel Suta<EMAIL_ADDRESS>https://issues.redhat.com/browse/KOGITO-4469
Many thanks for submitting your Pull Request :heart:!
Please make sure your PR meets the following requirements:

[x] You have read the contributors' guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains a link to the JIRA issue
[x] Pull Request contains a description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[ ] You've tested the new feature/bug fix in an actual OpenShift cluster
[ ] You've added a RELEASE_NOTES.md entry regarding this change

Porting changes from https://github.com/kiegroup/kogito-operator/pull/790 into product operator.

Latest version is not available yet in https://pkg.go.dev/github.com/kiegroup/kogito-operator , not sure how it can be published (apart from releasing proper release).
@vaibhavjainwiz @ricardozanini What approach we should take to allow picking latest Kogito operator changes in here? To be able to adjust implementation based on changes in Kogito operator.

Latest version is not available yet in https://pkg.go.dev/github.com/kiegroup/kogito-operator , not sure how it can be published (apart from releasing proper release).
@vaibhavjainwiz @ricardozanini What approach we should take to allow picking latest Kogito operator changes in here? To be able to adjust implementation based on changes in Kogito operator.

To refer to master branch of kogito-operator inside rhpam-kogito-operator, you could call go get github.com/kiegroup/kogito-operator@master.
It will import latest commit on master

That's fine for now, but I'd rather have these structures imported from upstream instead. Is it possible? Sorry for the silly question. I have to try the new codebase by myself. We should avoid this kind of task since it's hard to maintain.


fix(readme): Circle CI

Fix wrong Circle CI badge link

It looks like this was fixed already in the previous PR.
Thanks,
Dan


After set the locale, year change not detected when change the year manually(without pick the year)

Hi, when i am change the year in by manually(with keyboard) enter the year this not hit the below pickdate() function, first it was works fine, i am adding the locale to this 'en-IN' after this was not working. Below i am share my code.
Please help me where i do the mistake
 @Component({
      selector: 'sb-clr-date-picker',
      template: `<input
           [formControl]="control"
           (dateTimeChange)="pickDate($event)"
           [owlDateTimeTrigger]="dtPicker2"
          [owlDateTime]="dtPicker2">
          <owl-date-time [pickerType]="'calendar'" #dtPicker2></owl-date-time>`
  })

export class SbClrDatePickerComponent {
   @Input() control: FormControl = new FormControl(new Date());
   @Output() change = new EventEmitter();

  constructor(dateTimeAdapter: DateTimeAdapter<any>) {
      dateTimeAdapter.setLocale('en-IN');
  }

  pickDate(d: Date) {
     this.change.emit(d);
  }
}

Pleas use StackBlitz to build an app and show the issue you mention about
I would close this until it is confirmed as an issue.
To answer you question, the date time format might change after you setting a different locale and the picker could not translate your date time string to a proper Date object. In this case, the picker would not fire a (dateTimeChange) event.

Hear is the  Stack blitz, in this you test select today date after change the year into 2019(or something) by manually by keyboard then open date picker it still showing the today, i am using form control to this it will give null in this case.

As I said before, the date time format might be changed after you setting a different locale and the picker could not translate your date time string to a proper Date object.
Back to your example,
this is because the locale en-In date time format is 'dd/mm/yyyy', but Native Javascript Date object could not parse the string to a specific format. This is nothing we could do. Native Javascript Date parse() function would always parse a string to Date object relative to your system's locale. In this case, I would recommend you to use OwlMomentDateTimeModule and let MomentJs to handle locale parse and format. You could learn more about OwlMomentDateTimeModule from the README and the demo page.


GelfHandler produces Fatal error when called in Garbage Collection

In my usecase, Monolog with a GelfHandler is used in a __destruct()-function. Some pseudo-code is attached.
When doing so, I am getting:
PHP Fatal error:  Call to a member function publish() on a non-object in /vagrant/vendor/monolog/monolog/src/Monolog/Handler/GelfHandler.php on line 62
PHP Stack trace:
...
PHP   4. SomeClass->__destruct() SomeClass.php:0
PHP   5. Monolog\Logger->warn() SomeClass.php:<line-nr, where ->warn() is called>
PHP   6. Monolog\Logger->addRecord() /vagrant/vendor/monolog/monolog/src/Monolog/Logger.php:503
PHP   7. Monolog\Handler\AbstractProcessingHandler->handle() /vagrant/vendor/monolog/monolog/src/Monolog/Logger.php:269
PHP   8. Monolog\Handler\GelfHandler->write() /vagrant/vendor/monolog/monolog/src/Monolog/Handler/AbstractProcessingHandler.php:37

Please fix this issue.
Using monolog/monolog 1.15
class SomeClass
{
    public function __destruct()
    {
        $logger = new Logger('some name');
        $gelfPublisher = new Publisher();
        $gelfHandler = new GelfHandler($gelfPublisher);
        $logger->pushHandler($gelfHandler);

        $logger->warn('log to elk');
    }
}

I don't really see how that error is possible with the code you show, is this really how you're using monolog?

Without more info I can not do anything about this, closing but if you want to provide more then I will reopen.

I know this is two years old, but I'm actually having this problem as well.
The gist is that in the destructor of Monolog\Handler\Handler, as well as in Monolog\ErrorHandler::handleFatalError(), ->close() is called on the handler. In case of GelfHandler, it unsets the publisher, leaving itself in a broken state.
If then some other code tries to log something, be it from a destructor that is randomly executed at a later time, or, in case of handleFatalError(), in another shutdown function, instead of gracefully refusing to log anything, the GelfHandler causes (another) fatal.
I agree that logging from shutdown functions or constructors may not be a good idea. However, I don't think the handler should cause a fatal error in these cases. For example, StreamHandler even re-opens the stream automatically in write() if it's been closed before. (I don't know whether that's a good idea, but that's what happens.)
Here is a short test script to show what I'm talking about:
<?php
require 'vendor/autoload.php';
$handler = new Monolog\Handler\GelfHandler(
    new Gelf\Publisher(new Gelf\Transport\UdpTransport())
);
$logger = new Monolog\Logger(null, [$handler]);
Monolog\ErrorHandler::register($logger);
register_shutdown_function(function() use ($logger) {
    $logger->debug('Something that shouldn\'t crash the application');
});
trigger_error('Something fatal', E_USER_ERROR);

Executing this will raise two fatal errors, first "something fatal," and then "Call to a member function publish() on null." For comparison, if you don't pass the handler to the Logger constructor, effectively creating a StreamHandler, only one fatal occurs (and afterwards the debug message is logged).
This can't be intended behavior...?


Update CHANGELOG to graphql api names

Related to: #805

@jinjoolee07

Replacing the method name with the GraphQL API name means replacing it with the name of the GraphQL API that is called externally.
One example is that the actual function implementing qeury that provides dns traffic event in giganto is named dns_raw_event, but the actual GraphQL API call to it is named dnsRawEvent.
https://github.com/aicers/giganto/blob/301611dc2716c4ec54861da1c049e3cef9b017c4/src/graphql/network.rs#L1244-L1252
https://github.com/aicers/giganto/blob/301611dc2716c4ec54861da1c049e3cef9b017c4/src/graphql/client/schema/dns_raw_events.graphql#L2-L9

@jinjoolee07
According to our rules, we need to use GitHub keywords, such as "close", instead of manually linking the related issue.

For consistency I'd like to suggest using "GraphQL", not graphQL, graphql, Graphql or any other casings.

@jinjoolee07 I think we need two PRs to completely resolve https://github.com/aicers/giganto/issues/805, because we need one toward main branch and  another toward tis branch. But I am afraid that this trigger phrase "Fixes: https://github.com/aicers/giganto/issues/805" will automatically mark the issue as complete, as soon as this PR gets merged. Could you take a look at it please?

For consistency I'd like to suggest using "GraphQL", not graphQL, graphql, Graphql or any other casings.

Thank you for the suggestion! I’ve just made the edits to ensure it's consistently using 'GraphQL' throughout. Please let me know if I missed any instances.

@jinjoolee07 Could you check these lines please? Since below lines are not displayed in the "Files changed" tab, I could not make comments on the lines.

https://github.com/aicers/giganto/pull/808/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR74 : For this, I think parenthesis should be removed.
https://github.com/aicers/giganto/pull/808/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR145 : Maybe query to GraphQL API
https://github.com/aicers/giganto/pull/808/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR150 :  Maybe query to GraphQL API
https://github.com/aicers/giganto/pull/808/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR330 : I suggest "Fixed export GraphQL API to export statistics data for all cores."

@jinjoolee07 Could you check these lines please? Since below lines are not displayed in the "Files changed" tab, I could not make comments on the lines.

https://github.com/aicers/giganto/pull/808/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR74 : For this, I think parenthesis should be removed.
https://github.com/aicers/giganto/pull/808/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR145 : Maybe query to GraphQL API
https://github.com/aicers/giganto/pull/808/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR150 :  Maybe query to GraphQL API
https://github.com/aicers/giganto/pull/808/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR330 : I suggest "Fixed export GraphQL API to export statistics data for all cores."

Modification completed

Could you resolve conflict as well?

Since the codecov is not working as we intended in this PR, and I think https://github.com/aicers/giganto/issues/816 will resolve the problem. So I suggest to rebase this PR on top of main branch, after #816 is merged to the main. Then, I expect the codecov to compare this PR against the latest main commit, and thus pass the codecov check.

@jinjoolee07 I am sorry but I would like to ask you for one more thing. Could you change "graphql api" to "GraphQL API" in your commit message?

@jinjoolee07 I am sorry but I would like to ask you for one more thing. Could you change "graphql api" to "GraphQL API" in your commit message?

Modified the commit message to GraphQL API


Client update transactions are too large

Summary of Bug
Client update transactions are too large and can be easily made smaller.  The size of client update transactions is a risk to chains using ibc.
Notes from @ValarDragon

each client update lists all the validators + all signatures with both carrying way too much data
Simplest things would be:

Delete:

Signature/block_id_flag, infer "BLOCK_ID_COMMIT"
Signature/Timestamp -> UnixNano timestamp

"Can't tell if this validator set hash is verified against root, if so nothing that reads as a trivial change then (because priority changes every block), you can make an ID system for val addrs at least, but ID system isn't a mini change"
Expected Behaviour
Client updates are significantly reduced in size, without the use of zero knowledge proofs.
Version
all
Steps to Reproduce
Contact Jacob Gadikian via slack to discuss how to reproduce the issues that can be caused by this approach.
implementation
I think that most of this could be done in the relayer.  Versioning could let the relayer know which client update info to send, and there wouldn't be breaking changes.

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged/assigned

Would echo this, we are wasting tremendous amounts of blockspace throughout cosmos due to this.
In general I'd expect the tx size to be on the order of magnitude of 100 signatures * 64 bytes / signature = 6.4kb. (Lets say 10-20kb is short-term reasonable after some overheads) I forgot how we estimated the real size, but I remember it being 150-200kb.
At least the idea of inferring BLOCK_ID_FLAG_COMMIT if blank seems like a very light change, and something I concur that relayer software should be able to handle, so it can be done in a way thats backwards compatible.
Would be great to do a quick survey of where all the size is coming from. What seems like the big deal to me is that we are communicating all validators two times, in a very space inefficient manner. (Using full addresses, pubkeys, voting power, proposer priority). We should stop communicating all validators and be much more refined in whats communicated. Proposer priority should never be needed for instance. Note that its not included in validator set hash. (source: https://github.com/cometbft/cometbft/blob/869833ee12c8c399fb0c487befcdac427236be2b/types/validator.go#L16 )

@ValarDragon - yeah, if we had a clientv1 and a clientv2, I think the relayer could do the rest.
I am still battling through the thing amulet published against my will, notional and I will be a minute here on fixes.
https://forum.cosmos.network/t/amulet-security-advisory-for-cometbft-asa-2023-002/11604/13

I guess one thing interesting is that for proposer priority, the relayer could just edit it to be 0. Then it won't get serialized in protobuf

Played with this, here is a URL for format-free decoding of header that Carlos shared: link the overhead is actually not as bad.
The BLOCK_ID_FLAG is actually not included, but instead an enum option! We also see proposer priority isn't included, and that for absent validators further data isn't included.
It appears the signatures are currently implemented as one entry per validator. Since thats the case, we can/should omit the validator address along with the signature, as its implied by the index. I do not know where the IBC software currently finds the address (is it from the vote, or implied by the index)
The tendermint ValidateBasic code checks this address, but we could easily just copy the validate basic code into IBC-go and omit this check. (this code is called here).
Should also be able to make the transmission of the validator set at least not resend the pubkey for pubkey/address pairs already known. (storing an Addr->Pubkey map in state)

Adding in some more context from slack so it is not lost -
Improvements to the IBC client update structure could be via:

Moving the light client verification from TM to IBC
Not verifying / including all validator signatures, just 2/3rds of them. (And including indication whether others voted)
Other data size improvements by removing elements that are not needed for light client operation

Another feature besides bandwidth / gas, is that this is currently the cause of 10% of all CPU usage from tx execution on Osmosis, so will have a slight benefit to sync rate

https://github.com/cosmos/ibc-go/issues/2951 is related also

spoke to the team at Stride and they're facing the same issue of state bloat from client update messages. from their side they'd like to be able to prune some of this bloat in an automated way on a regular cadence. they recommend the same as above - reduce the size of update client message and/or restrict the amount of updates that can be submitted.


added auto port scan

Coverage decreased (-0.06%) to 27.158% when pulling 9bf522c7ba3dbac58c437f4debdbce87cd95a3f7 on sosey:portscan into 018914fd1ff8406657d3870704f33bfab501ed4b on spacetelescope:master.


Dio throws exception with [500], but I can print the response code and it's a successful 204

New Issue Checklist

[x] I have searched for a similar issue in the project and found none

Issue Info

Info
Value

Platform Name
android

Dio Version
2.1.7

Repro rate
100%

Repro with our demo prj
No

Issue Description and Steps
      try {
        String binding = await userRepository.getEnvBinding(event.subDomain);
        Response r =  await apiTwilioBinding.deleteBinding(
            event.subDomain, event.accessToken, binding);
        print(r.statusCode);
        await userRepository.deleteEnvBinding(event.subDomain);
        yield TwilioBindingNotSet();
      } catch (e) {
        String message = '${event.subDomain} unbinding failure: $e';
        print(message);
        yield TwilioBindingFailed(message: message);
      }

I/flutter (26701): 204
I/flutter (26701): demo unbinding failure: DioError [DioErrorType.RESPONSE]: Http status error [500]

What happened here, is that the server gave me a 204 code. The operation was certainly successful. I can print the response code to console and it says 204. Yet, dio still throws an exception saying there was a 500 server error.
In no circumstances would I expect both print statements to print, especially with 2 different status codes. I'm not even sure if this is an issue with Dio specifically, but it is very strange.

I have the same issue.
My http request is successful and i can print the data i get to console but Dio keep throwing exception so my app thought there's an error and not displaying any data.

I'm also encountering the same issue!

In my case, my solution was to make dio return type dynamic like this:
dio.delete<dynamic>('delete/api');


MSFT_xPowerPlan Support for Nano server

MSFT_xPowerPlan support for Nano server is currently missing.
There is already a module available that does this and it could easily be merged
https://github.com/J0F3/cPowerPlan
If nobody else is working on it i will properly take a look at how it could be done.

Hi @AndreasSobczyk - sorry for not getting back to you sooner (I've only just picked up this repo as one of the ones I maintain so I'm trying to clear the backlog)!
This would be awesome if you feel like merging the nano support across - it would gratefully accepted. So if you're keen on doing this, I'll mark the issue as in progress.

Hi @PlagueHO -  no problem, i actually forgot this completely since Microsoft have chosen to remove the support for intrastructure roles in Nano server, and my usecase was for hyper-v


Get Attempting to unscale FP16 gradients while finetune on float16

The initial script showed error gpu doesn't support bfloat16 and ask me to use float16 instead.
I modify as below.
fabric = L.Fabric(
        accelerator="cuda",
        devices=devices,
        strategy=(DeepSpeedStrategy(config=ds_config) if devices > 1 else "auto"),
        precision="16-mixed",
    )

with EmptyInitOnDevice(device=fabric.device, dtype=torch.float16):
        model = Parrot(config)

It shows errors when optimizer trying to step
File "finetune_adapter.py", line 117, in train
    optimizer.step()
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/lightning/fabric/wrappers.py", line 72, in step
    return self._strategy.optimizer_step(
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/lightning/fabric/strategies/strategy.py", line 193, in optimizer_step
    return self.precision.optimizer_step(optimizer, **kwargs)
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/lightning/fabric/plugins/precision/amp.py", line 83, in optimizer_step
    step_output = self.scaler.step(optimizer, **kwargs)
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/torch/cuda/amp/grad_scaler.py", line 370, in step
    self.unscale_(optimizer)
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/torch/cuda/amp/grad_scaler.py", line 284, in unscale_
    optimizer_state["found_inf_per_device"] = self._unscale_grads_(optimizer, inv_scale, found_inf, False)
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/torch/cuda/amp/grad_scaler.py", line 212, in _unscale_grads_
    raise ValueError("Attempting to unscale FP16 gradients.")
ValueError: Attempting to unscale FP16 gradients.

Hi! Can you try removing dtype=torch.float16 from EmptyInitOnDevice?
float16 mixed training should keep the model in float32 precision

I try both removing the dtype or setting dtype to float32, get error in model initialization.
File "finetune_adapter.py", line 65, in main
    model = Parrot(config)
  File "/disk3/ai/ml_experiments/finetune_llms/lit-parrot/lit_parrot/adapter.py", line 135, in __init__
    h=nn.ModuleList(Block(config, i) for i in range(config.n_layer)),
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/torch/nn/modules/container.py", line 279, in __init__
    self += modules
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/torch/nn/modules/container.py", line 320, in __iadd__
    return self.extend(modules)
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/torch/nn/modules/container.py", line 401, in extend
    for i, module in enumerate(modules):
  File "/disk3/ai/ml_experiments/finetune_llms/lit-parrot/lit_parrot/adapter.py", line 135, in <genexpr>
    h=nn.ModuleList(Block(config, i) for i in range(config.n_layer)),
  File "/disk3/ai/ml_experiments/finetune_llms/lit-parrot/lit_parrot/adapter.py", line 109, in __init__
    self.mlp = MLP(config)
  File "/disk3/ai/ml_experiments/finetune_llms/lit-parrot/lit_parrot/model.py", line 141, in __init__
    self.proj = nn.Linear(hidden_dim, config.n_embd, bias=True)
  File "/disk3/ai/ml_experiments/finetune_llms/venv/lib/python3.8/site-packages/torch/nn/modules/linear.py", line 96, in __init__
    self.weight = Parameter(torch.empty((out_features, in_features), **factory_kwargs))
  File "/disk3/ai/ml_experiments/finetune_llms/lit-parrot/lit_parrot/utils.py", line 121, in __torch_function__
    return func(*args, **kwargs)
RuntimeError: handle_0 INTERNAL ASSERT FAILED at "../c10/cuda/driver_api.cpp":15, please report a bug to PyTorch.

Uh that's strange. There might be a bug in EmptyInitOnDevice.

Yes, get the exact error on when dtype=torch.float32 is passed.

I'll try to reproduce it. Thanks for your patience

It's working for me :/

I printed out the gpu memory used in the model initialization loop. The memory used went to ~11GB before the error. My best guess is the error is due to OOM. My GPU only has 12GB memory. If loading the 3B model in float16 requires ~7GB memory, 12GB will not be enough for float32.
I will close the issue, thanks a lot for trying to reproduce.


Add dropout2d

Proposed changes
Implement 2D dropout + expose 1D dropout in documentation. I have tested my code against PyTorch's Dropout2d. Should I include further tests, e.g. comparing with torch results ?
Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING document
[x] I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have updated the necessary documentation (if needed)

Arg, I made a mess with the git history, I will deal with it asap

I'm not sure on the state of your repo. But what usually works well for me is to:

Pull with rebase
Resolve conflicts during rebase
Commit and force push to the branch you are working

I dont know what I did, but now I cannot push to my branch anymore 🥲

Argh


Remove function for imagestreamtag

What changes have been made
Remove function for imagestreamtag
Checks

[X] I've made sure the tests are passing.
Testing Strategy

[X] Unit tests
[ ] Manual tests
[ ] Testing is not required for this change

The function can stay here.
Is there some specific reason to remove it?

The function can stay here. Is there some specific reason to remove it?

I added this function to use in customRayImage test and this function is not used anywhere else so thought to remove it

As it is a general function it can be kept.

As it is a general function it can be kept.

I am fine with it

Closing the PR


Adjusting the condition that checks whether an assignment localization needs syncing with exercise.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@2ccfb87). Click here to learn what that means.
The diff coverage is 85.00%.

@@            Coverage Diff            @@
##             master     #391   +/-   ##
=========================================
  Coverage          ?   72.51%
=========================================
  Files             ?      446
  Lines             ?    14514
  Branches          ?        0
=========================================
  Hits              ?    10525
  Misses            ?     3989
  Partials          ?        0

Impacted Files
Coverage Δ

app/commands/cleanup/CleanupLocalizedTexts.php
4.00% <0.00%> (ø)

app/model/entity/Assignment.php
93.71% <86.66%> (ø)

app/model/entity/base/ExerciseData.php
94.80% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2ccfb87...34b5145. Read the comment docs.


@BundleProperty not working to retrieve value

I declared a @BundleProperty in a fragment, set the value by calling Fragment.putMyProperty(...), and then passed the bundle as arguments to the fragment, but in the fragment, the value I get back is always the default value.

Hm. I'll look into it. Thanks for reporting.

Aha. I did something stoooopid. You used an int right?
I foresee a patch coming really soon. :)


fix(conversion):World to image throws an exception on outside image

There are lots of cases where world to image should allow producing coordinates outside the image.  Make the exception optional.

Hmmm, looking at it again, I guess it shouldn't throw an error at all. Maybe we just remove that check fully?


Generating thumbnails using cloud functions

From @kitkatgithub on April 2, 2017 2:45
There is a sample cloud function that generates a thumbnail for an image in Storage.  Is there a reason why friendlyPix generates the thumbnail on client vs using the server-side function?
Copied from original issue: firebase/friendlypix#85

Yes: because this was built before Cloud Functions was available :) We could have changed it since then but haven't had time to get to it yet.
Doing this on the server is better because it will ensure that the thumbnail and the full image are the same. Currently a badly-intentioned user could in theory upload a different pic for the thumbnail and the full image.

From @kitkatgithub on April 2, 2017 16:25
Thank you @nicolasgarnier , this would be great to see!

We're going to be deprecating the friendlypix-web repo so we're closing all open PRs and Issues.  We apologize for not addressing your issue, we should have done more to maintain this repository and we will aim to do better in the future.
For developers who want to learn about Firebase on the web, we recommend the Get to know Firebase for Web codelab.


Add usage instructions

Thanks for this! I had just assumed most people would use the docker container to not have to deal with Elixir versions 😅

For sure!  Thanks for this project.  Really neat idea


Add missing dependencies

lib(ayatana-)appindictor-gtk3: necessary for notifications icons
libnotify-bin: necessary for notify-send
libnotify4/libnotify: necessary to register notifications
dunst/notification-daemon: necessary to server notifications

For: QubesOS/qubes-issues#6426
Fixes: QubesOS/qubes-issues#8453
Fixes: QubesOS/qubes-issues#7991

This won't fly on R4.1:
  - nothing provides libayatana-appindicator-gtk3 needed by qubes-video-companion-sender-1.0.7-1.1.fc32.noarch from @commandline

Does it mean the sender is incompatible with dom0 in R4.1 anyway? If that's the case, maybe don't build it (change += in Makefile.builder with just :=) ?

If Ayatana is not present, it falls back to plain AppIndicator.
Also Dom0 with Fedora 37 does not have Ayatana also and I have been screensharing Dom0.
See my comment in rpm_spec/qubes-video-companion-dom0.spec.in:
## Fedora 37 doesn't have libayatana-appindicator-gtk3
Requires:       libappindicator-gtk3

Which is just a comment I left to remember to later fix the package name on the next Dom0 major upgrade.

Ok, but this means it's really a dependency of the sender subpackage, not dom0 one, no? Can you move it to the right place but make it conditional (%if 0%{?fedora} <= 37)? You can use %else too.

Ok, but this means it's really a dependency of the sender subpackage, not dom0 one, no? Can you move it to the right place but make it conditional (%if 0%{?fedora} <= 37)? You can use %else too.

Added the if statement to rpm_spec/qubes-video-companion-dom0.spec.in.
There is no sender subpackage in the dom0 spec, only in the domU spec. The dom0 spec does not try to install a subpackage. I am therefore unsure what you mean of moving that requires to the correct place, as Dom0 spec does not have a subpackage.

There is some confusion in the package split - dom0 gets both -dom0 and -sender packages built for it, and both contain relevant qrexec services and all sender files. It should be either only -dom0 being built for dom0, or the -dom0 one should have only dom0-only files (default policy) and depend on -sender.

There is some confusion in the package split - dom0 gets both -dom0 and -sender packages built for it, and both contain relevant qrexec services and all sender files. It should be either only -dom0 being built for dom0, or the -dom0 one should have only dom0-only files (default policy) and depend on -sender.

You are right, changed the Makefile.builder dom0 section to use :=.


Add swig to package.xml

I know swig is only needed for building the python interface but is it so bad to have it as a dependency?

Hi @tonynajjar, thank you for the PR. Merged!


Added welcome users typescript example

Proposed Changes
Added sample welcome users for typescript

Please break this down to one sample per PR. It will help the review process.
Thank you for this effort!

@EricDahlvang Sorry, please merge the first two first pull request first. I apparently branched out of the other PR instead of master.


layers: Update Valid Usage enums in log_msg

Update Valid Usage enums in core_validation and update
their status in the VU database.
This completes Jira task VL-65.
Change-Id: I51ed327ad65f3a5d1f64bba01ad576c6656f88df

Note: deleting a branch too quickly after pushing to master can cause a race with Travis-CI.
Travis-CI will begin its integration builds, but that can fail if the branch is deleted too quickly.


Communication Error on sim with carla

Describe the bug
Followed the instructions to get openpilot running with Carla. Once the bridge starts, opendbc seems to have issues with the counter of the signals:
...
0x17C COUNTER FAIL 2 -- 3 vs 3
0x17C COUNTER FAIL 2 -- 0 vs 0
0x17C COUNTER FAIL 2 -- 1 vs 1
0x17C COUNTER FAIL 2 -- 2 vs 2
...

As far as I can tell, the signal counter does not increase. Yet, when creating the can messages the idx does increase.
Also os.read() seems to have issues reading from stdin as the input size to input does not have the proper input size (but I assume this is a follow up problem of the one above?):
Traceback (most recent call last):
  File "/home/jodo/openpilot/selfdrive/modeld/runners/keras_runner.py", line 57, in <module>
    run_loop(m)
  File "/home/jodo/openpilot/selfdrive/modeld/runners/keras_runner.py", line 32, in run_loop
    ret = m.predict_on_batch(idata)
...
ValueError: Cannot reshape a tensor with 0 elements to shape [1,12,128,256] (393216 elements) for 'model/reshape/Reshape' (op: 'Reshape') with input shapes: [1,0], [4] and with input tensors computed as partial shapes: input[1] = [1,12,128,256].

How to reproduce or log data
Run openpilot with Carla as described here.
Device/Version information (please complete the following information):

Device: Linux Mint 19.2
Version: latest master (85a09b3113fe45b5feee7c1c421e2c43cb2ac03a)
Car make/model: carla sim

Which version of tensorflow were you running?

Having the same issue with Mint 19.3
@pd0wm: Tensorflow version is 2.2.0 according to Pipfile.lock
Could it be the wrong CUDA or NVIDIA driver version or something like that?
Maybe you could tell us the versions you are using in-house.

remove this line https://github.com/commaai/openpilot/blob/master/tools/sim/lib/can.py#L41
msg.append(packer.make_can_msg("POWERTRAIN_DATA", 0, {}, idx))


[Proto] Support Cosmos scalar type definitions

CosmosSDK released support for scalar type definitions: https://github.com/cosmos/cosmos-sdk/pull/9933
They make working with custom types much easier for us, and support for other languages than Go isn't needed in our case. The gravity module already makes use of them, but our compiler doesn't actually apply the needed changes, meaning the underlying datatypes are still native typed.
We should upgrade this some time.
Opening this issue to keep track of it.

Is the implementation of the scalar types really finished, though? It seems it adds the scalar types annotations, but doesn't change the generators, meaning we still get the underlying native types. That PR does not change the resulting data types.
For instance, the latest version of cosmos still has string address fields even though they have the scalar type annotation in the proto definition. I compiled the protos from the HEAD of the repo and got the same results. Upgrading our proto compiler also yields the same.
We could still add the annotations, but we don't seem to get much benefit from it now.

Nah, this was really meant as a tracking ticket so I wouldn't forget about this. I don't think they'll update their generators any time soon tbh. Feel free to skip this one.


Hyper-Parameter settings on ImageNet

Hi, I am reproducing the results of Omni-GAN on ImageNet128. I used the same settings as BigGAN except I changed the batch size, added weight decay to Generator and Discriminator. But the generated images occured mode collapse at very early training stage. Below is the scripts I used.
python3 train.py
--dataset I128_hdf5 --parallel --shuffle  --num_workers 8 --batch_size 256
--num_G_accumulations 1 --num_D_accumulations 1 --load_in_mem
--num_D_steps 1 --G_lr 1e-4 --D_lr 4e-4 --D_B2 0.999 --G_B2 0.999
--G_attn 64 --D_attn 64 --G_nl inplace_relu --D_nl inplace_relu
--SN_eps 1e-6 --BN_eps 1e-5 --adam_eps 1e-6 --num_epochs 200
--G_ortho 0.0 --G_shared --G_init ortho --D_init ortho
--hier --dim_z 120 --shared_dim 128 --G_eval_mode --G_ch 96 --D_ch 96
--ema --use_ema --ema_start 20000 --use_multiepoch_sampler
--data_root ../data --sv_log_interval -1
--test_every 2000 --save_every 1000 --num_best_copies 1 --num_save_copies 1 --seed 0
--loss_type omni --G_WD 1e-5 --D_WD 1e-5
I also checked experiments with projection loss and without weight decay and reset the number of accumulations to 8 (batch size equals to 2048), the resulting images were normal.
Are there any differences between my settings and yours? Could you give me some suggestions. By the way, what's the batch size you use for ImageNet 32x32? Do you use batch size of 32? it seems very small and the networks will need more time to update.

Hi,
The omni-loss is a much stronger classification loss than the projection-based loss and cannot employ a large batch size similar to that of the BigGAN. For the ImageNet128x128 experiment, the core hyperparameters are modified as follows:
batch_size: 256
num_G_accumulations: 1
num_D_accumulations: 1
num_D_steps: 1
Generator:
    weight_decay: 0.001
Discriminator:
    weight_decay: 0.00001

However, the script you provided above seems to be consistent with the hyperparameters I used, and I don't know why you didn't get good results. By the way, I used 8*v100 with 32G VRAM each for the ImageNet 128x128 experiment.
As for the ImageNet 32x32 experiment shown in the paper, since I didn't have large-scale GPU resources at that time, the experiments in the paper were conducted on a single 1080Ti GPU. The batch size is set to 64 for ImageNet 32x32.
I'm curious why your experiment didn't work well. I provide the more detailed configuration as follows:
  args:
    dataset: I128_hdf5
    data_root: "datasets/ImageNet_hdf5/ILSVRC128.hdf5"
    num_workers: 8
    batch_size: 256
    num_G_accumulations: 1
    num_D_accumulations: 1
    num_D_steps: 1
    G_lr: 1e-4
    D_lr: 4e-4
    D_B2: 0.999
    G_B2: 0.999
    G_attn: '64'
    D_attn: '64'
    G_nl: inplace_relu
    D_nl: inplace_relu
    SN_eps: 1e-6
    BN_eps: 1e-5
    adam_eps: 1e-6
    G_ortho: 0.0
    G_shared: true
    G_init: ortho
    D_init: ortho
    hier: true
    dim_z: 120
    shared_dim: 128
    G_eval_mode: true
    G_ch: 96
    D_ch: 96
    ema: true
    use_ema: true
    ema_start: 20000
    test_every: 2000
    save_every: 1000
    num_best_copies: 4
    num_save_copies: 2
    seed: 0
    use_multiepoch_sampler: true
  Discriminator:
    output_dim: 1002
    weight_decay: 0.00001
  Generator:
    weight_decay: 0.001
  omni_loss:
    mode: p_and_n
    gamma: 1.0
    margin: 0.0

I hope this helps!

Hi,
The omni-loss is a much stronger classification loss than the projection-based loss and cannot employ a large batch size similar to that of the BigGAN. For the ImageNet128x128 experiment, the core hyperparameters are modified as follows:
batch_size: 256
num_G_accumulations: 1
num_D_accumulations: 1
num_D_steps: 1
Generator:
    weight_decay: 0.001
Discriminator:
    weight_decay: 0.00001

However, the script you provided above seems to be consistent with the hyperparameters I used, and I don't know why you didn't get good results. By the way, I used 8*v100 with 32G VRAM each for the ImageNet 128x128 experiment.
As for the ImageNet 32x32 experiment shown in the paper, since I didn't have large-scale GPU resources at that time, the experiments in the paper were conducted on a single 1080Ti GPU. The batch size is set to 64 for ImageNet 32x32.
I'm curious why your experiment didn't work well. I provide the more detailed configuration as follows:
  args:
    dataset: I128_hdf5
    data_root: "datasets/ImageNet_hdf5/ILSVRC128.hdf5"
    num_workers: 8
    batch_size: 256
    num_G_accumulations: 1
    num_D_accumulations: 1
    num_D_steps: 1
    G_lr: 1e-4
    D_lr: 4e-4
    D_B2: 0.999
    G_B2: 0.999
    G_attn: '64'
    D_attn: '64'
    G_nl: inplace_relu
    D_nl: inplace_relu
    SN_eps: 1e-6
    BN_eps: 1e-5
    adam_eps: 1e-6
    G_ortho: 0.0
    G_shared: true
    G_init: ortho
    D_init: ortho
    hier: true
    dim_z: 120
    shared_dim: 128
    G_eval_mode: true
    G_ch: 96
    D_ch: 96
    ema: true
    use_ema: true
    ema_start: 20000
    test_every: 2000
    save_every: 1000
    num_best_copies: 4
    num_save_copies: 2
    seed: 0
    use_multiepoch_sampler: true
  Discriminator:
    output_dim: 1002
    weight_decay: 0.00001
  Generator:
    weight_decay: 0.001
  omni_loss:
    mode: p_and_n
    gamma: 1.0
    margin: 0.0

I hope this helps!

Thank you very much for your reply, let me try it again.

Thank you very much for your reply, let me try it again.

If you have any questions, please let me know. Thank you！

If you have any questions, please let me know. Thank you！

I am very sad that the current review of our paper is not so good. Thus I decide not to disclose the details of the experiment on ImageNet 128 x 128. All code and hyperparameters for the ImageNet 128/256 experiment will not be made public unless our paper is accepted. Thanks for your interest.

I am very sad that the current review of our paper is not so good. Thus I decide not to disclose the details of the experiment on ImageNet 128 x 128. All code and hyperparameters for the ImageNet 128/256 experiment will not be made public unless our paper is accepted. Thanks for your interest.

I can feel what you said. No worries. I believe your work is a great job. Hope your paper can be accepted.

I can feel what you said. No worries. I believe your work is a great job. Hope your paper can be accepted.

I can feel what you said. No worries. I believe your work is a great job. Hope your paper can be accepted.

Thank you so much for your encouragement.

I can feel what you said. No worries. I believe your work is a great job. Hope your paper can be accepted.

Thank you so much for your encouragement.