RFC: Logging Updates

Currently, we have 6 different log flavors (all with varying degrees of use and for varying purposes):

DEBUG (used 1 time)
INFO (used 3 times - one of those times is wrong and another is in a unit test)
WARNING (used a lot)
ERROR (used a lot)
FATAL (used a lot)
BUG (used 17 times)

At the moment, it seems like FATAL and BUG are used interchangeably and ERROR is sometimes used like a WARNING and other times like FATAL (calling exit right after). There are also plenty of uses of std::cout and std::cerr - sometimes nested inside bt_verbose checks.
UPDATED Proposal in a comment below.
So this is an RFC to re-work and codify these logging flavors. Here is the outdated proposal:

INFO: log info to the user regardless of log level - like using stdout
V1: log info to the user only if verbose logging is enabled (bt_verbose or -v)
V2: log info to the user only if very verbose logging is enabled (bt_verbose2 or -vv)
WARNING: log info that might affect bpftrace behavior or output but allows the run to continue - like using stderr
ERROR: abort run and log info to indicate that the user did something invalid which caused bpftrace to exit
BUG: abort run and log info to indicate that there is an internal/unexpected issue (not caused by invalid user program code or CLI use)

Note: V1 and V2 will replace all instances like this:
if (bt_verbose) {
    std::cout << "Attaching to " << probe_.funcs.size() << " functions"
              << std::endl;

So this is an RFC to re-work and codify these logging flavors. Here is the proposal:

I generally like the below but have a few comments.

INFO: log info to the user regardless of log level - like using stdout

Since this is so sparsely used, I'm wondering if we need it at all (i.e. if we need to print any information to the user in non-verbose mode). I'm sometimes using INFO for debugging but DEBUG is better for that purpose as it shows the file name and the line number. So, I'm in favor of keeping DEBUG instead of INFO.

V1: log info to the user only if verbose logging is enabled (bt_verbose or -v)
V2: log info to the user only if very verbose logging is enabled (bt_verbose2 or -vv)

I like this, although I think that bt_verbose2 is used in a single place only. As a matter of fact, it would be good to rethink the semantics of verbosity/debug options (-v, -vv, -d, -dd) as I've run into some problems with them when working with libbpf. Perhaps a good topic for the next office hours.

WARNING: log info that might affect bpftrace behavior or output but allows the run to continue - like using stderr
ERROR: abort run and log info to indicate that the user did something invalid which caused bpftrace to exit

Requiring ERROR to immediately exit will require significant updates to the semantic analyser as it tends to collect and print all errors at once. With the above, you'd probably have to file the errors as warnings and issue just a single LOG(ERROR) at the end. I'd prefer having two different flavors, say ERROR and ABORT, although ABORT should probably prefix the message with ERROR: ... to keep consistency in user-facing output.

BUG: abort run and log info to indicate that there is an internal/unexpected issue (not caused by invalid user program code or CLI use)

Note: V1 and V2 will replace all instances like this:
if (bt_verbose) {
    std::cout << "Attaching to " << probe_.funcs.size() << " functions"
              << std::endl;

I'm sometimes using INFO for debugging but DEBUG is better for that purpose as it shows the file name and the line number. So, I'm in favor of keeping DEBUG instead of INFO.

We're defining what levels come with file name and line number so that could apply to INFO but I'm fine using DEBUG instead of INFO. But yeah, I agree that neither will probably get used much.

I like this, although I think that bt_verbose2 is used in a single place only. As a matter of fact, it would be good to rethink the semantics of verbosity/debug options (-v, -vv, -d, -dd) as I've run into some problems with them when working with libbpf. Perhaps a good topic for the next office hours.

I agree with all of this. Let's get rid of verbose2 entirely. And yes, great discussion for next office hours.

Requiring ERROR to immediately exit will require significant updates to the semantic analyser as it tends to collect and print all errors at once. With the above, you'd probably have to file the errors as warnings and issue just a single LOG(ERROR) at the end. I'd prefer having two different flavors, say ERROR and ABORT, although ABORT should probably prefix the message with ERROR: ... to keep consistency in user-facing output.

Ah, good point about the semantic analyzer. I guess in the guidelines we can just specify that if you use LOG(ERROR) it should eventually lead to program termination via LOG(ABORT).

Updated proposal:

DEBUG: log info to the user regardless of log level - like using stdout (comes with file and line number)
V1: log info to the user only if verbose logging is enabled (bt_verbose or -v) Note: -vv will be deleted as it's only used in two places in one file.
WARNING: log info that might affect bpftrace behavior or output but allows the run to continue - like using stderr
ERROR: log info to indicate that the user did something invalid which will (eventually) cause bpftrace to exit via ABORT. It's possible that there a multiple errors that need to get logged to the user.
ABORT: abort run and log info to indicate that the user did something invalid which caused bpftrace to exit
BUG: abort run and log info to indicate that there is an internal/unexpected issue (not caused by invalid user program code or CLI use)

How about VERBOSE instead of V1 if we're only having one verbosity level?

ERROR: log info to indicate that the user did something invalid which will (eventually) cause bpftrace to exit via ABORT.

Does "exit via ABORT" mean something special or can ERROR just eventually trigger a clean exit?
Otherwise I like it!

Does "exit via ABORT" mean something special or can ERROR just eventually trigger a clean exit?

+1 here, we don't need to explicitly recommend exiting via ABORT, IIUC, ABORT = (error message + exit()).

How about VERBOSE instead of V1 if we're only having one verbosity level?

I prefer V1 mostly because VERBOSE is well... verbose. I was also thinking of changing WARNING to just WARN. V1 leaves the door open to have additional levels but it also implies there are multiple, which there won't be (in this proposal). I'm torn.

+1 here, we don't need to explicitly recommend exiting via ABORT, IIUC, ABORT = (error message + exit()).

JC, what is the use case for logging errors that end in a clean exit? Or am I just getting hung up on the word "clean" - we should be calling exit(1) right? But yeah, I'm fine with just calling exit(1) at some point after LOG(ERROR) instead of LOG(ABORT).

JC, what is the use case for logging errors that end in a clean exit? Or am I just getting hung up on the word "clean" - we should be calling exit(1) right? But yeah, I'm fine with just calling exit(1) at some point after LOG(ERROR) instead of LOG(ABORT).

Yes, I meant using e.g. exit(1) instead of LOG(ABORT).

Closing this as it's been mostly resolved over multiple PRs:
https://github.com/bpftrace/bpftrace/pull/3164
https://github.com/bpftrace/bpftrace/pull/3091
https://github.com/bpftrace/bpftrace/pull/3202


Parameters for esc duty cycles

Makes three parameters for esc's pwm min, max and disarmed values when using the uart_esc module.

Been running fix_code_style.sh after installing astyle but it never returns. Is astyle broken?

@blandry: try make check_format
For the params, I wonder if we should re-use the existing parameters?
https://github.com/PX4/Firmware/blob/2f48317a9ea7b05d8c61b3d1c44f8229491350b1/src/modules/sensors/sensor_params.c#L2874

I worked around the broken astyle by using the .pretty directly. Also I cannot test this on our setup because the parameters aren't saving on it (even when running sync).

Thanks! Rebased and applied!


Feed Statistics

Detection and reporting of dead feeds is currently not supported in NetNewsWire. Dead and inactive feeds slow down the Refresh without contributing anything.
It is possible to export the feeds as an opml file and run a script over it to detect dead feeds:
xpath -q <Subscriptions-iCloud.opml -e '//*[local-name()="outline"]/@xmlUrl' | sed 's/^[[:space:]]*xmlUrl="//; s/"$//;' | xargs -n1 curl -fsL -o /dev/null -w '%{http_code}\t%{url}\t%{redirect_url}\n' | grep -v $'^200\t'

But detection of inactive feeds would be more involved, and overly active and noisy feeds would be even harder to identify.
Please implement a feature where NetNewsWire will flag in the UI feeds that report error codes (404, 403, etc.) and show statistics of number of articles per period of time for each feed and allow for sorting.
An example implementation is available at Feedly's Organize Feeds page which allow for filtering the list by Inactive, Unreachable, etc., display the number of items the feed publishes a month and when was the last item published.
This will allow the user to analyze currently followed feeds and do a cleanup.

Duplicate of #1107


latest beta breaks vue-cli pwa app

Version
5.0.0-beta.3
Browser and OS info
osx chrome 70
Steps to reproduce
visit https://beta.nomadsoulmates.com
What is expected?
cannot click on login button if extension is enabled, there are console errors. If extension disabled then no problem
What is actually happening?
having the extension enabled breaks the page

Do you import lodash into Navigation.js? I do not see it.
You are using lodash in unreadNotificationsCount getter.

Try to move window._ = require('lodash'); before import store from './vuex/store'; in main.js
Devtools run all getters when vuex will be inited. Lodash in your code will setup later. window._ = _ - is bad practice. Use webpack aliases for lodash instead.


fix(recipients): dynamic block bug

Which problem is this PR solving?

Closes #434

Short description of the changes
Migrates NotificationRecipients to types.Set and NotificationRecipientDetails to types.List instead of slices.

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1206682900457198

Codecov Report
Attention: Patch coverage is 91.91919% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 83.28%. Comparing base (9c84dba) to head (fa09d4b).
Report is 2 commits behind head on main.

Files
Patch %
Lines

internal/provider/notification_recipients.go
90.80%
4 Missing and 4 partials :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #444      +/-   ##
==========================================
+ Coverage   83.21%   83.28%   +0.06%
==========================================
  Files          62       62
  Lines        4170     4235      +65
==========================================
+ Hits         3470     3527      +57
- Misses        547      551       +4
- Partials      153      157       +4

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


Tweak production Django settings

This PR is branched from #29. We can either merge this into that PR or if that PR is merged first we can instead point this at master.

Added a number of production security settings

set all cookies to be secure cookies
turn on various optional Django security settings
set an HTTP -> HTTPS redirect (SECURE_SSL_REDIRECT)
all other domains redirect to the main domain (SECURE_SSL_HOST)

Add caching with redis
Switch the session engine to secure cookies rather than adding records to the DB indefinitely
A side effect involved code formatting with black (see #30)

Fixes https://github.com/pythonsd/pythonsd-django/issues/19

Codecov Report

Merging #31 into davidfischer/refactor-settings will not change coverage.
The diff coverage is n/a.

@@                       Coverage Diff                       @@
##           davidfischer/refactor-settings      #31   +/-   ##
===============================================================
  Coverage                           98.92%   98.92%
===============================================================
  Files                                   8        8
  Lines                                  93       93
  Branches                                6        6
===============================================================
  Hits                                   92       92
  Misses                                  1        1

Impacted Files
Coverage Δ

config/urls.py
100% <ø> (ø)
:arrow_up:

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 22a8f84...c26c94e. Read the comment docs.

I'm going to merge this into #29 so we can review it in 1 place.


finish doctree module

https://github.com/freeflowuniverse/crystallib/blob/development_integration/crystallib/data/doctree/readme.md
please complete this module

progress update:

link fixing is now working, still need to add some testing for it
added tests for error reports in a collection

test by parsing a full mdbook wiki, then generate the mdbook wiki, then parse again, and compare should be the same

done


Directives Firing Twice

Since updating to version 3.0.2 from 3.0.0 I am seeing an issue where all file upload directives are firing twice, so events are being added twice, as are input boxes.
I had a dig through the angular code and it seems to be due to angular registering both angularFileUpload and ngFileUpload - this seems to be related to a commit the other day where;
var ngFileUpload = angular.module('ngFileUpload', []);
for (key in angularFileUpload) {
ngFileUpload[key] = angularFileUpload[key];
}
was added in.
What can be done to alleviate this problem?

I don't believe it's related to that. You will be including one of those in your app so one will be used. Can you create a jsfiddle? I think what you are seeing is the event firing when you click on the upload button to empty it's value and set it's value to null. That is for allowing selecting the same file again or handling user cancelling the file select popup. So as soon as you click on the button an event will be fired with empty files.

I have also faced the same problem. When I click the upload button it would pop up a window for selecting a new file. However, no matter whether I choose a file or simply click cancel, the window would show up again and this time the selection would be valid. So it ends up having twice selecting files of which the first one is invalid. How to solve that?

@clifflo that's a separate issue from what @fitzpaid describes here.
What version of plugin and what browser are you seeing this problem in?
Could you create a jsfiddle to reproduce the problem from the sample jsfiddle on readme?

Hi Danial I have fixed it myself. Actually I have used Ionic Framework and I put the uploader within the labels. Once I get the uploader out of the label it works. Perhaps later on I would post a question within Ionic Framework's forum. Anyway thanks for your help.

:+1: When the directive is inside the label, the file upload is fired twice.

@SeyZ can you create a js fiddle showing this? You can use the js fiddle sample on the readme file

I'm also seeing this happen with Angular 1.2 and MaterializeCSS 0.95.3
See example code here:
https://gist.github.com/dberube/4709a89a5787a72e60d8

I am also facing same issue

@miqdadalik @dberube could you create a jsfiddle showing the bug?

Chiming in to +1 this, it's happening with me as well.

If you guys could create a jsfiddle or plnkr to reproduce this issue I would fix it.
Is this happening with the latest version?

It's happening on 3.2.4 (installed from bower), yeah.

I cannot seem to reproduce it with the descriptions you have posted here.

Hey danialfarid, I managed to fix it for my company's project by removing the following three lines from the angular-file-upload.js file:
for (var key in angularFileUpload) {
    ngFileUpload[key] = angularFileUpload[key];
}

as the first poster suggested.
Everything seems to be working, but I'm not entirely sure what the side effects of this would be. If nothing, then it would be awesome if you made this or a similar change to fix this problem on the official code.

That won't have side effects that is just to let you use both names as the module name. But I cannot see how it could create an issue, it might be the way you reference the module or something that's why I'm asking for a reproducible sample.

It's probably specific to how we have our project setup, because I cannot seem to reproduce the issue outside of the project.
We are using the MEAN stack, which has a lot of dependencies in itself. I hope this can help you narrow it down, somehow.

I am getting issue with angularAMD+requireJS

We are having the issue with Lumx and angular material.
http://ui.lumapps.com
https://material.angularjs.org/#/

We have a thing that automatically loads all of our bower packages. I think it thinks your setup which enables both names to be used is actually two separate packages. So when it auto loads up packages it loads yours twice.
When I get some time I'll fork and do the fix, followed by a pull request to remove the lines I mentioned earlier from the code. I hope you'll accept it.

I've got the same issue with ionic inside and outside a label.

This is fixed in version 4.x.x.


Bedrock support

Are there any plans to add support for  OpenAI API compatible models, such as Antopic models, hosted on AWS Bedrock?

Specifically interested in using models hosted on Bedrock.

What's the best way to test it? I created a genaiscript file like this:
script({
    model: "anthropic_bedrock:anthropic.claude-3-haiku-20240307-v1:0",
})
$`Write a short poem.`

This is what I'm getting:
LLM error (403): LLM configuration missing for model anthropic_bedrock:anthropic.claude-3-haiku-20240307-v1:0

I think npx might be using the global package...

Not released yet :)

Try
yarn genai poem --model anthropic_bedrock:...

(fix model name)

Nice! That worked.

I see, we generate system, user messages which become user, user in anthropic. need to collapse them.

@volkanunsal try the latest in the main branch

Lgtm! Thanks for the quick turnaround.

Feel free to raise more issues as they pop up. Mostly relying on the @anthropic/bedrock-sdk package here

Thank you. One potential area of improvement is allowing builders to
specify a designated credential profile to be used. This way they can use
the default credential profile for their dev work and run the genai scripts
to check their code etc without having to go back and forth between
accounts. I haven’t checked if that exists already…
On Fri, Dec 13, 2024 at 4:00 PM Peli de Halleux @.***>
wrote:

Feel free to raise more issues as they pop up. Mostly relying on the
@anthropic/bedrock-sdk package here
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/genaiscript/issues/943#issuecomment-2542363902,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABFAMD25W2WUVNY7NDUNSD2FNDINAVCNFSM6AAAAABTR5Z36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBSGM3DGOJQGI
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

One thing to try out would be to use the aws SDK in the genai script itself to set things up; then the environment would be ready when the LLM call happens.
Sent from Outlookhttp://aka.ms/weboutlook

From: Volkan Unsal @.>
Sent: Friday, December 13, 2024 1:36 PM
To: microsoft/genaiscript @.>
Cc: Comment @.>; Subscribed @.>
Subject: Re: [microsoft/genaiscript] Bedrock support (Issue #943)
Thank you. One potential area of improvement is allowing builders to
specify a designated credential profile to be used. This way they can use
the default credential profile for their dev work and run the genai scripts
to check their code etc without having to go back and forth between
accounts. I haven’t checked if that exists already…
On Fri, Dec 13, 2024 at 4:00 PM Peli de Halleux @.***>
wrote:

Feel free to raise more issues as they pop up. Mostly relying on the
@anthropic/bedrock-sdk package here
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/genaiscript/issues/943#issuecomment-2542363902,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABFAMD25W2WUVNY7NDUNSD2FNDINAVCNFSM6AAAAABTR5Z36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBSGM3DGOJQGI
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/genaiscript/issues/943#issuecomment-2542420581 or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA73QKPXZ6RJ2VWSTDHKGMD2FNHODBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVE3DOOJXHA2DGNRYQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRSG4ZTQMZTHA2TMN5HORZGSZ3HMVZKMY3SMVQXIZI.
You are receiving this email because you commented on the thread.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I think I see what you mean. Anthropic SDK is using env vars to get the
credential values. Perhaps I can modify them beforehand.
On Fri, Dec 13, 2024 at 4:44 PM Peli de Halleux @.***>
wrote:

One thing to try out would be to use the aws SDK in the genai script
itself to set things up; then the environment would be ready when the LLM
call happens.
Sent from Outlookhttp://aka.ms/weboutlook

From: Volkan Unsal @.>
Sent: Friday, December 13, 2024 1:36 PM
To: microsoft/genaiscript @.>
Cc: Comment @.>; Subscribed @.>
Subject: Re: [microsoft/genaiscript] Bedrock support (Issue #943)
Thank you. One potential area of improvement is allowing builders to
specify a designated credential profile to be used. This way they can use
the default credential profile for their dev work and run the genai
scripts
to check their code etc without having to go back and forth between
accounts. I haven’t checked if that exists already…
On Fri, Dec 13, 2024 at 4:00 PM Peli de Halleux @.***>
wrote:

Feel free to raise more issues as they pop up. Mostly relying on the
@anthropic/bedrock-sdk package here
—
Reply to this email directly, view it on GitHub
<
https://github.com/microsoft/genaiscript/issues/943#issuecomment-2542363902>,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AABFAMD25W2WUVNY7NDUNSD2FNDINAVCNFSM6AAAAABTR5Z36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBSGM3DGOJQGI>

.
You are receiving this because you modified the open/close state.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub<
https://github.com/microsoft/genaiscript/issues/943#issuecomment-2542420581>
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AA73QKPXZ6RJ2VWSTDHKGMD2FNHODBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVE3DOOJXHA2DGNRYQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRSG4ZTQMZTHA2TMN5HORZGSZ3HMVZKMY3SMVQXIZI>.
You are receiving this email because you commented on the thread.
Triage notifications on the go with GitHub Mobile for iOS<
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android<
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/genaiscript/issues/943#issuecomment-2542430532,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABFAMG7OOCWHB7UID7JH5L2FNIMZAVCNFSM6AAAAABTR5Z36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBSGQZTANJTGI
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

open to suggestions once you get further in the usage :)

This worked for me.
process.env["AWS_ACCESS_KEY_ID"] = "..."
process.env["AWS_SECRET_ACCESS_KEY"] = "..."
process.env["AWS_SESSION_TOKEN"] = "..."

$`Write a short poem.`

To tidy it up, I put the creds in a separate file...
import "./creds"
$`Write a short poem.`

I was also able to make it work by exporting the credentials from .env.genaiscript. I think that's good enough for now. :)


Change validation for dash in company-code instead of underscore

I don't see any changes in this PR, just spaces. Also, the branch has conflicts that need fixing before I an merge.


Add auto-author and auto-label to github workflow

Closes #51

Proposed Changes

The same as this PR for phys2bids but implemented for this repo
All I did was change the directory locations in the .github/labeler.yml file, otherwise the files are the same as the phys2bids files

Change Type

[ ] bugfix
[ ] refactoring
[x] infrastructure
[ ] documentation
[ ] other

Checklist before review

[ ] I added everything I wanted to add to this PR.
[ ] [Documentation only] I built the docs locally.
[ ] My contribution is harmonious with the rest of the code: I'm not introducing repetitions.
[ ] My code respects the adopted style, especially linting conventions.
[ ] The title of this PR is explanatory on its own, enough to be understood as part of a changelog.
[ ] I added or indicated the right labels.

[ ] I added information regarding the timeline of completion for this PR.

[x] Please, comment on my PR while it's a draft and give me feedback on the development!

@smoia this is still a draft because I am wondering about the default branch being mkdoc -  does the workflow code needs to change to reflect that? I can look into it if you're not sure


Serde 1.0

Hi!
I was trying to use serde-redis in a side project of mine and ran into this issue because of a version mismatch. I had seen that serde 1.0 has already been discussed in #10, but no branches existed for it. I figured if I needed it, it'd be better to contribute.
I didn't do much besides bump the version up and making the necessary changes. You might see that there is some room for improvement. I also ran rustfmt just in case.
All tests pass, but I'm still a Rust novice, so sorry in advance if I made any mistakes!

Hey @mbStavola,
Thanks for the PR! Would you mind reverting the "Run rustfmt" commit? The unrelated changes make it more difficult to review the 1.0 changes.

Done! Sorry for the wait!
There still are some minor reformats in here from IntelliJ, but I peeked through it and it looks fine.
Anything else?

This all looks good. Thanks again for your work updating this crate to Serde 1.0!


GNMI-1.11: Removing incoming/outgoing packet delta equivalence check

When incoming and outgoing ports are in different linecards, the packet counters for ongoing traffic in gnmi-subscription may have difference in update duration.
Considering that gnmi-subscription update equivalence check may not be valid on multiple linecard dut, thus removing it.
"This code is a Contribution to the OpenConfig Feature Profiles project ("Work") made under the Google Software Grant and Corporate Contributor License Agreement ("CLA") and governed by the Apache License 2.0. No other rights or licenses in or to any of Nokia's intellectual property are granted for any other purpose. This code is provided on an "as is" basis without any warranties of any kind."

Pull Request Functional Test Report for #2401 / 57a32fa05ca607ad84cc1ed97ad656792437a577
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

gNMI-1.11: Telemetry: Interface Packet Counters

Cisco 8000E

gNMI-1.11: Telemetry: Interface Packet Counters

Cisco XRd

gNMI-1.11: Telemetry: Interface Packet Counters

Juniper cPTX

gNMI-1.11: Telemetry: Interface Packet Counters

Juniper ncPTX

gNMI-1.11: Telemetry: Interface Packet Counters

Nokia SR Linux

gNMI-1.11: Telemetry: Interface Packet Counters

Openconfig Lemming

gNMI-1.11: Telemetry: Interface Packet Counters

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

gNMI-1.11: Telemetry: Interface Packet Counters

Cisco 8808

gNMI-1.11: Telemetry: Interface Packet Counters

Juniper PTX10008

gNMI-1.11: Telemetry: Interface Packet Counters

Nokia 7250 IXR-10e

gNMI-1.11: Telemetry: Interface Packet Counters

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1541

Relevant Lines:
3164

💛  - Coveralls


Changed estimatedScrollX/Y to return Var instead of Val.

Looks good. I'm going to merge this, but maybe we should rename estimatedScrollXProperty(), estimatedScrollYProperty() to make it clearer that they are not pixel offsets.

I've always thought of scrollBar's not as pixel offsets but just values within the viewport. I know now that that's not true but I'm finding it hard to think of what a better name for these properties would be.

You thought of it the right way, then, they are not pixel offsets. To me, scrollX sounds like it is the number of pixels scrolled. Good to know that to you it doesn't.


feat: Explore | Show Only Users That Connected With Current User

Fixes Issue
closes #604

Changes proposed
four new arrays (allusers, following, follower, connection) are created having userId of users and only that data is shown whose userId are present in the new created array.
In this way filter option is implemented.
I am facing a small issue.
when the page reloads then it is not showing any data , but when I click on any filter buttons after that it works fine. It looks like It is trying to access the data before it is even loaded.

Screenshots

Note to reviewers

Code of Conduct

[x] By submitting this pull request, I confirm I've read and complied with the CoC 🖖

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

You can also join our Discord community.
Feel free to check out other cool repositories of the Thecyberworld.
Join the Thecyberworld GitHub Organisation by raising an issue (you will be sent an invitation).

@sumanjeet0012 I change this issue to draft because it is still in progress tell me when you will finish with it so we could review it.

@kabir0x23 the issue fixed :)
https://github.com/thecyberworld/TheCyberHUB/assets/76536506/09267f1b-d619-4e44-bdd4-e7c90c6d163d

fix: show ctf which regiestered by filter (connections/followers/following)
https://github.com/thecyberworld/TheCyberHUB/assets/76536506/5ae52faa-32bb-4312-aee0-c309f391da96
@kabir0x23

awesome 😀


Week 3 development step 3

This step begins making a comment box for the portfolio using JSON as instructed from the walkthroughs. I created a new page called comments.html, with the navbar modified to reflect this. I also created a new java file CommentsServlet.java to handle server requests related to comments, and renamed the old DataServlet.java file to FactsServlet.java, which now solely handles serving fun facts. This branch just stores hard-coded ArrayList data in the CommentsServlet.java file and returns it as JSON data when it receives a GET request. The comments.html file then displays the data.
Picture testing this with a hard coded array containing two elements "Hello" and "World":

TESTING: tested that comments.html was able to grab the array data from CommentsServlet.java and display it properly, with differing number of elements in the array.

I also added error handling for the getComments function as reflected from the 'week 3 development step 2' pull request.


error: handlebars does not support render

If you're experiencing this issue. please add information about your build to this issue (please, don't create another issue)

related https://github.com/assemble/assemble.io/issues/158

@eurolife are you using something like load-grunt-tasks or match-dep?

Please bear with me, as I am quite new to this, but in my grunt file, there is grunt.registerTask and after that grunt.task.run which runs the specified tasks. There is also grunt.initConfig which defines all the tasks beforehand. Does that help or are you looking for something else?

It's okay, I remember going through the same thing like it was yesterday lol. There is a lot to take in...

Does that help or are you looking for something else?

Could you add your entire gruntfile to a gist? https://gist.github.com/. If so that would be great, then just link it back here. If not, that's ok we can try to step through it

Here is a link to it https://gist.github.com/eurolife/8062a7170e9efe937798
Really appreciate you helping me with this!

Hmm, nothings jumps out at me.
just thinking out loud so we can try to narrow the problem down:

this shouldn't be needed: https://gist.github.com/eurolife/8062a7170e9efe937798#file-gruntfile-js-L27
have you tried running assemble by itself? e.g. grunt assemble?
does the issue always happen, or only when certain other tasks are run before or after? (usemin/wiredep have been the source of many conflicts and issues on assemble in the past)

i'll keep looking too

oh, I almost missed this. You mentioned that you're using assemble 0.4.x, correct? please try updating to grunt-assemble and see if that helps. make sure you:

completely delete node_modules in your project
remove assemble from package.json deps or devDeps
then do npm install grunt-assemble --save-dev

let me know if that helps

Ok, I did what you said - I removed node_modules and also removed assemble from package.json and then installed grunt-assemble. After that I also had to do npm install otherwise grunt serve would not run. Unfortunately, I am still getting that same error after doing all of that.

fyi i did try running assemble by itself and got the same error.

do you have any custom helpers? or are there any helpers that are included by the generator?

@eurolife can you link to an entire repository or at least create a gist with the package.json? Also, will you post information your environment like OS, node and npm versions?

Do you mean helpers in handlebars? I didn't add any and don't know if the
generator did. If there is a place i should look for that, let me know.
On Nov 22, 2015 20:36, "Jon Schlinkert"<EMAIL_ADDRESS>wrote:

do you have any custom helpers? or are there any helpers that are included
by the generator?
—
Reply to this email directly or view it on GitHub
https://github.com/assemble/grunt-assemble/issues/31#issuecomment-158795916
.

I'm out the door now but will put my project up on github later and will
let you know. Thanks.
On Nov 22, 2015 20:45, "Brian Woodward"<EMAIL_ADDRESS>wrote:

@eurolife https://github.com/eurolife can you link to an entire
repository or at least create a gist with the package.json? Also, will you
post information your environment like OS, node and npm versions?
—
Reply to this email directly or view it on GitHub
https://github.com/assemble/grunt-assemble/issues/31#issuecomment-158798338
.

I just figured it out. yo-webapp doesn't add a version to the package.json.
In grunt-assemble, we're using assemble-handlebars by default, which uses handlebars-helpers.
In the version of handlebars-helpers that's being used, we're using to for YAML formatting, which is using handy and trying to get the package.json version.
Since grunt-assemble attempts to first load assemble-handlebars then falls back to handlebars if it fails to load, handlebars is trying to be used as the engine directly, which doesn't have a .render method.
It works if you add a version property to your package.json file.
In later newer versions of assemble and handlebars-helpers we're doing things differently so this type of error won't happen.

In later newer versions of assemble and handlebars-helpers we're doing things differently so this type of error won't happen.

indeed. great debugging @doowb!

btw, should this be reported as a bug to handy, or to or somewhere else?

Looks like @johnyb already tracked this down: https://github.com/assemble/handlebars-helpers/issues/199
He's opened issues on both handy and to.

Unfortunately, both projects seem to be dead. :skull: :\

that's right I remember now, thanks @johnyb. seems like we should be able to do patches to fix this.

That worked! Thank you so much!

I encountered this issue by appending -SNAPSHOT to the version in my package.json
Changing "version":"1.0.0-SNAPSHOT" to "version":"1.0.0" fixed the build, without needing to change any other dependencies.
Not sure if it's the same for every instance of this error, but hopefully someone else can save some time.
 It's not an option for us to change this but maybe I can look at a fix for this
/cc @masterbee

We've just encountered this error now. Our project, including the gruntfile is here: https://github.com/standrewsdigital/digital-pattern-library
Similar to yan-kisen, above, we get the error "Warning: handlebars does not support render." if we append a pre-release tag on the end of the version number.
The package.json documentation says "Version must be parseable by node-semver, which is bundled with npm as a dependency. "
If our version number is "version": "0.9.0" then the build works, but if I add a pre-release tag, e.g. "version": "0.9.0-alpha.1" then the build fails.
Our devDependencies list:
"devDependencies": {
"grunt": "~1.0.0",
"grunt-assemble": "~0.5.0",
"grunt-contrib-clean": "~1.0.0",
"grunt-contrib-compass": "~1.1.0",
"grunt-contrib-concat": "~1.0.0",
"grunt-contrib-copy": "~1.0.0",
"grunt-contrib-jshint": "~1.0.0",
"grunt-contrib-uglify": "~2.0.0",
"grunt-contrib-watch": "~1.0.0",
"grunt-gitinfo": "~0.1.0",
"handlebars-helper-asset": "git://github.com/sjparsons/handlebars-helper-asset.git#relative-links",
"handlebars-helper-rel": "git://github.com/sjparsons/handlebars-helper-rel.git#fix",
"handlebars-helpers": "~0.7.0",
"swag": "~0.7.0"
},
The funny this is that this used to work before we updated our dependencies (question is which one broke it!).
Happy to provide more details as required.

I had the same problem. Turns out, the top-level project did not have any "version" field in the package.json file. Adding this field fixes the issue. Is is not sufficient for the field to exist, but it has actually contain a proper semver value.
The specs for package.json actually request this field and the correct formatting, so the best fix for this issue would be to add a check in grunt-assemble and improve the error message.
Thanks to garethjmsaunders for your hint!

I had the same problem. It seems that the cause was that I put a version like the following in my package.json:
{
  "version": "1.0.0-rc.1",
}

When i changed to 1.0.0 the problem disappeared.

@jonschlinkert @doowb I was able to create a fix for this by extarcting the single method used in the to package but then realized that you don't even use the package in the latest version. However there seem to be an issue that this project doesn't install handlebars-helpers past 0.5.8. Any idea why that is?

Thanks @yan-kisen, removing -SNAPSHOT in the version fixed my problem :-)

@elpeq if you update to the latest version, you don't need to remove your -input anymore.


Possible mismatch between source code and the research paper on Prolonged LOS pre-training task

Hi there,
I was reading the paper and I found that probably the source code contradicts the one and important statement in the research paper.
According to the Med-BERT section in the paper following point is mentioned on page 7:

In BERT, the token [CLS]  was  used mainly to  summarize  the  information  from  the  two  sentences; however,  EHR sequences are usually much longer;e.g.,a sequence may contain 10 more visits, and simply using one token will inevitably lead to huge information loss. Therefore,  for both the Prolonged  LOS task and the downstream disease-prediction tasks where the information of the whole sequence is usually needed, we added a feed-forward layer (FFL) to average the outputs from all of the visits to represent a sequence,instead of using only a single token.

However, the source code is still using the first token for predictions instead of using FFL to average all the outputs. Although, the data preparation does not contains the [CLS] token. Therefore, code at the below location is using the first token which can be the any random ICD-9/10 code according to the input patients. [comment on the same location also mentions that]
https://github.com/ZhiGroup/Med-BERT/blob/ccf65acd175b50b1de10e6fdc65f34fe69e0ccbf/Pretraining Code/modeling.py#L227
Is this repository still under construction? Or there is another function which tackles this issue?
If not, then the use of single first token (i.e., ICD-9/10) might increase the noise in the system. Is there any other analysis associated with this such that it makes it easy to understand? Probably the validation loss at each epoch on Prolonged LOS task should also help to understand it better.
Any answers will be helpful and thank you in advance!

Hi Maitreya,
Thanks for pinpointing this issue, Yes, there is another pretraining code version that make sure that we use the full sequence and not the first token for the LOS pretraining task. This is file run_EHRpretraining_QA2Seq.py
The initial version was following the original [CLS] pretraining code available on Google BERT, and therefore it was giving more power to the first diagnosis in the patient record and supposedly making the pre-training classification task (LOS) more difficult. While the second is the more appropriate implementation using the whole patient sequence information.
We compared the performance of the 2 options and the performance of the pre-trained models on the downstream tasks was similar. We are clarifying the same in the paper revision.
Thank you


chore(main): release github.com/mikesmitty/mdns-mesh 0.6.12

:robot: I have created a release beep boop
0.6.12 (2023-12-02)
Bug Fixes

avoid duplicate actions workflows (#23) (1b86618)
deps: Update dependency go to v1.21.4 (#38) (6dd8100)
deps: Update Go modules (#39) (ef3596a)
deps: update module github.com/miekg/dns to v1.1.57 (#35) (42e8847)
deps: update module github.com/nats-io/nats.go to v1.31.0 (#7) (72c5e00)
deps: update module github.com/spf13/viper to v1.17.0 (7f98ccb)
deps: update module golang.org/x/net to v0.18.0 (#33) (5d1f3c3)
deps: update module golang.org/x/sys to v0.14.0 (#31) (66ce3a0)
don't strip v from version tags (#29) (8141232)
give release-please a pat (#21) (9c0e7ac)
make tagged ghcr image available (#27) (e2346f3)
release build trigger (#19) (bf452c9)
update go version to 1.21 and go mod tidy (#18) (6cc443d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/mikesmitty/mdns-mesh/releases/tag/github.com/mikesmitty/mdns-mesh-v0.6.12 :sunflower:


Allow token as authorization for accessing attachments

This PR makes it possible to access attachments using token as authorization. You can currently get information about a release attachment using the API with token as authorization (e.g. GET /repos/{owner}/{repo}/releases/{id}/assets/{attachment_id}). However to download the actual attachment you need to use normal login as token is restricted to API.
Currently you can download attachment like this:
curl -u user:password "https://try.gitea.io/attachments/262c8395-a089-410a-be88-985e319ea058" -o "File.ext"

This PR makes it possible to download attachment like this:
curl  -H "Authorization: token <token>" "https://try.gitea.io/attachments/262c8395-a089-410a-be88-985e319ea058"-o "File.ext"

Note: Currently this will only have affect when REQUIRE_SIGNIN_VIEW = true, as attachments always accessible otherwise. See #7908.

Codecov Report

Merging #7909 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #7909      +/-   ##
==========================================
- Coverage   41.43%   41.42%   -0.01%
==========================================
  Files         478      478
  Lines       63943    63945       +2
==========================================
- Hits        26492    26488       -4
- Misses      34001    34007       +6
  Partials     3450     3450

Impacted Files
Coverage Δ

modules/auth/auth.go
50% <100%> (+0.38%)
:arrow_up:

models/repo_list.go
72.08% <0%> (-1.02%)
:arrow_down:

routers/repo/view.go
42.53% <0%> (-1.02%)
:arrow_down:

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 2d0b90c...70a45cb. Read the comment docs.

This looks like it will give access to uploading attachments with tokens as well. Is that alright?

This looks like it will give access to uploading attachments with tokens as well.

I did not consider that. However I am not sure it actually will allow uploading. I match against /attachments/ and not /attachment. Would /attachments/ also be routed for uploading?

I did not consider that. However I am not sure it actually will allow uploading. I match against /attachments/ and not /attachment. Would /attachments/ also be routed for uploading?

Check here:
https://github.com/go-gitea/gitea/blob/08c63190c68ca63f99f510f7f2c6cda41d531343/routers/routes/routes.go#L512

To ensure this has no side affects, I added a check that it is a GET request to attachment.

Will this work if gitea is hosted on a subpath, e.g. /gitea/attachments?
I have a feeling this check is not right and too specific to attachments. Shouldn't a access token with access to a specific repo can do everything on that repo? I think we're missing the bigger picture.

Will this work if gitea is hosted on a subpath, e.g. /gitea/attachments?
I have a feeling this check is not right and too specific to attachments. Shouldn't a access token with access to a specific repo can do everything on that repo, including posting attachments to their own comments and retrieving attachments of all comments?
I think we're missing the bigger picture.

@silverwind This is the same method used for IsAPIPath(), so I guess it's alright. See:
https://github.com/go-gitea/gitea/blob/ca6fb004ac50fc924861112403895d637c6a2d1d/modules/auth/auth.go#L28-L30
and
https://github.com/go-gitea/gitea/blob/ca6fb004ac50fc924861112403895d637c6a2d1d/modules/context/auth.go#L75-L83

Will this work if gitea is hosted on a subpath, e.g. /gitea/attachments?

I think it is handled by macaron (trimming site prefix), in macaron.go:
// ServeHTTP is the HTTP Entry point for a Macaron instance.
// Useful if you want to control your own HTTP server.
// Be aware that none of middleware will run without registering any router.
func (m *Macaron) ServeHTTP(rw http.ResponseWriter, req *http.Request) {
	if m.hasURLPrefix {
		req.URL.Path = strings.TrimPrefix(req.URL.Path, m.urlPrefix)
	}
	for _, h := range m.befores {
		if h(rw, req) {
			return
		}
	}
	m.Router.ServeHTTP(rw, req)
}

It might not be a security risk to allow token generally, but tokens are usually used for scripts and integrations or similar, and I think it should not be encouraged to use the web interface for that (which is for humans). For example even if allowed to post attachments with tokens, there is a check for csrf cookie so it would be complicated to implement. Better to extend the API and encourage to use it. Unless it should be possible to login on web interface with token as well, but I don't think that is a good idea.

make LGTM works !


test: Fix flaky KeyValueStoreXdsDelegateIntegrationTest

This commit addresses a few aspects of the tests flakiness:

Ensure that the Envoy server is shutdown before restarting it to load xDS from the KV store.
Don't try to re-establish the xDS FakeUpstreams after shutdown. We need to use the same ports, otherwise we can't create a bootstrap config passing in the FakeUpstream's port without first having a running FakeUpstream, and if we try to re-use the same port, we ocassionally get port "Address already in use" errors. Re-checking connection establishment doesn't add a huge amount of value to the KV store test, so we just remove that part of the test to avoid flaky behavior.

This partially addresses https://github.com/envoyproxy/envoy/issues/26974.

Note, this PR still produces occasional errors when running w/ --runs-per-test=100, but the errors are less frequent, so this PR is still an improvement. I'm still working on figuring out the remaining errors.


Create a "Hero" Image for the home page

Example:

Hero Images tend to go at the top of a page!

Please assign this issue to me


fix(timeline): 修复单个节点数据显示线条问题

PR
PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our Commit Message Guidelines
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

It looks like the issue is due to an incorrect value of the headerHeight, and I noticed that it behaved correctly when I resized the page.

@all-contributors please add @MNZhu for code


Installation issue on the HPC Cluster

Hi all,
I would like to install this package on a HPC cluster, but there are some problem with installing the 'pin' package. Is there any way to avoid using 'pin'? I think 'pin' can only install in Linux and the cluster is not linux. Is that possible to replace the 'pin' with 'pinocchio', the command "conda install pinocchio -c conda-forge" works for me. Thank you very much.
Kind regards,
QIang

"pin" is just the name with which pinocchio can be installed using pip (it seems "pinocchio" is already used by an other project there).  So if the pip installation doesn't work for you, I think it should be fine if you locally remove "pin" from the requirements and instead install pinocchio via conda.
However, I don't want to change it on the main repo (in case that is the question), as I want to keep it independent from conda.  So you would need to clone it, modify locally and install from source.
Does this answer the question?

Hi Felix,
Thanks. This makes sense to me.
Kind regards,
Qiang
On Wed, 31 Aug 2022 at 10:09, Felix Widmaier @.***>
wrote:

"pin" is just the name with which pinocchio can be installed using pip (it
seems "pinocchio" is already used by an other project there). So if the pip
installation doesn't work for you, I think it should be fine if you locally
remove "pin" from the requirements and instead install pinocchio via conda.
However, I don't want to change it on the main repo (in case that is the
question), as I want to keep it independent from conda. So you would need
to clone it, modify locally and install from source.
Does this answer the question?
—
Reply to this email directly, view it on GitHub
https://github.com/open-dynamic-robot-initiative/trifinger_simulation/issues/89#issuecomment-1232676897,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AROLZVQ4C3NHSRJARLD6WPTV34OMJANCNFSM56VQT3FA
.
You are receiving this because you authored the thread.Message ID:
<open-dynamic-robot-initiative/trifinger_simulation/issues/89/1232676897@
github.com>

--
Qiang Wang
PhD Candidate
School of Electrical and Electronic Engineering, R324A
University College Dublin, Belfield, Dublin 4, Ireland
D04 V1W8
Phone: +353 (0) 830154869


BUG: scipy.stats.norm wrong expected value of function when loc is large

The expected value of a normal distribution should be the center of the distribution, but scipy gives wrong results when loc/scale is large.
Reproducing code example:
>>> import scipy.stats as stats
>>> stats.norm.expect(loc=10, scale=1)
10.000000000000004
>>> stats.norm.expect(loc=20, scale=1)
20.0
>>> stats.norm.expect(loc=30, scale=1)
30.0
>>> stats.norm.expect(loc=36, scale=1)
3.3637320653305685e-10
>>> stats.norm.expect(loc=40, scale=1)
1.5746385460369797e-26
>>> stats.norm.expect(loc=10, scale=0.1)
2.3378433179863228e-37

Scipy/Numpy/Python version information:
Scipy 1.1.0
Numpy 1.14.3

The expect method is implemented with scipy.integrate.quad.  When func is not given, it is assumed that func(x) = x.  quad is used to numerically integrate func(x)*pdf(x) over the support of the distribution.  For the normal distribution, the integral is over [-inf, inf].  Apparently this use of quad isn't robust enough to handle large loc.
The problem also occurs with other distributions.  For example,
In [52]: from scipy.stats import gamma, logistic

In [53]: gamma.expect(args=(145,))
Out[53]:<PHONE_NUMBER>0000045

In [54]: gamma.expect(args=(148,))  # Result should be 148.
Out[54]: 5.607236961785617e-09

In [55]: logistic.expect(loc=80)
Out[55]: 80.00000000000004

In [56]: logistic.expect(loc=85)  # Result should be 85.
Out[56]: 6.13219419324224e-09

Perhaps it could fixed by integrating over multiple intervals:  a finite interval [c, d] where c and d are based on the given values of loc, scale and the shape parameters (for distributions that have them), plus integrals over [a, c] and [d, b], where [a, b] is the support of the distribution (e.g. a = -inf and b = inf for the normal distribution).
Or, perhaps the variable of integration could be changed to z = (x - loc)/scale.

Note that the correct value can be computed by manually setting the integration limits:
In [73]: norm.expect(loc=50, scale=1)  # Bad result.
Out[73]: 9.38568238272931e-98

In [74]: norm.expect(loc=50, scale=1, lb=-50, ub=150)
Out[74]: 50.0

In [75]: gamma.expect(args=(148,))  # Bad result.
Out[75]: 5.607236961785617e-09

In [76]: gamma.expect(args=(148,), lb=0, ub=400)
Out[76]:<PHONE_NUMBER>00001

In [77]: logistic.expect(loc=85)  # Bad result.
Out[77]: 6.13219419324224e-09

In [78]: logistic.expect(loc=85, lb=-50, ub=250)
Out[78]: 84.99999999999999

Could there be a way of throwing a warning or similar when this kind of inconsistencies occur? At least users would be aware that there might be problems with the obtained results.

The same issue also occurs when using a small loc and a large upper or lower bound:
>>> norm.expect(loc=1, scale=1, ub=10, conditional=True)
0.9999999999982133

>>> norm.expect(loc=1, scale=1, ub=20, conditional=True)
0.9999999999999999

>>> norm.expect(loc=1, scale=1, ub=30, conditional=True)
1.0

>>> norm.expect(loc=1, scale=1, ub=40, conditional=True)
3.4007656189526604e-22

>>> norm.expect(loc=1, scale=1, ub=50, conditional=True)
8.381344573482554e-89

do we have any update on the bug fixes?

Wow, actually, this tends to speed things up, at least on average among the test cases:

import scipy.stats as stats
from scipy.stats import gamma, logistic

def f():
    a = stats.norm.expect(loc=10, scale=1)
    b = stats.norm.expect(loc=20, scale=1)
    c = stats.norm.expect(loc=30, scale=1)
    d = stats.norm.expect(loc=36, scale=1)
    e = stats.norm.expect(loc=40, scale=1)
    f = stats.norm.expect(loc=10, scale=0.1)
    g = gamma.expect(args=(145,))
    h = gamma.expect(args=(148,))  # Result should be 148.
    i = logistic.expect(loc=80)
    j = logistic.expect(loc=85)  # Result should be 85.
    return a, b, c, d, e, f, g, h, i, j

print(f())  # half incorrect in main, all correct in PR
%timeit f()  # 362ms in main, 207 ms in PR

Surprisingly, it even speeds things up for the problems that main currently gets correct.
def f():
    a = stats.norm.expect(loc=10, scale=1)
    b = stats.norm.expect(loc=20, scale=1)
    c = stats.norm.expect(loc=30, scale=1)
    # d = stats.norm.expect(loc=36, scale=1)
    # e = stats.norm.expect(loc=40, scale=1)
    # f = stats.norm.expect(loc=10, scale=0.1)
    g = gamma.expect(args=(145,))
    # h = gamma.expect(args=(148,))  # Result should be 148.
    i = logistic.expect(loc=80)
    # j = logistic.expect(loc=85)  # Result should be 85.
    # return a, b, c, d, e, f, g, h, i, j
    return a, b, c, g, i

%timeit f()  # 322 ms in main, 101 ms in PR

So I take back what I wrote; I'm in favor of a fix like this. I'll see if I can speed it up more with point and a single call to ppf.

points won't work for functions with infinite support.
ValueError: Infinity inputs cannot be used with break points.


Create pearson_correlation.py

@vjindal2 i'm merging this but make sure you add the file in a specific folder next time :)


Update HumanoidDescription.yaml

Increase consistency and clarity
Changes

Added parentheses to two method calls

Checks
By submitting your pull request for review, you agree to the following:

[X] This contribution was created in whole or in part by me, and I have the right to submit it under the terms of this repository's open source licenses.
[X] I understand and agree that this contribution and a record of it are public, maintained indefinitely, and may be redistributed under the terms of this repository's open source licenses.
[X] To the best of my knowledge, all proposed changes are accurate.

Hey @RoloTheDevBunny, thanks a bunch -- agreed that it's more clear with the parentheses. I thought it was a typo until it ran successfully. 😄 We also recommend this syntax in the style guide: https://roblox.github.io/lua-style-guide/#functions

Yes, it's a little weird seeing method calls without the parentheses. I see it a lot working on code that has gone through obfuscation, but it is interesting that they were included on one line and omitted the next.


.Net Pub/Sub quickstart documentation does not match C# code

Expected Behavior
Dapr quickstarts should work when following the directions specified
Actual Behavior
Dapr Pub/Sub quickstart for .Net launches but the subscriber does not receive events when following the quickstart directions
Steps to Reproduce the Problem
Working through the .Net Pub/Sub quickstart guide (https://docs.dapr.io/getting-started/quickstarts/pubsub-quickstart/) I noticed that I would not receive the published events on the order-processor app. This is due to the quickstart guide specifying the wrong port in the following command:
dapr run --app-id order-processor --resources-path ../../../components --app-port 7005 -- dotnet run
If you look at pub_sub/csharp/sdk/order-processor/properties/launchSetting.json, the app is launched on port 7006. This port mismatch from the dapr run command to the launch settings causes the app to never pick up published events. No errors are thrown so it looks like nothing is wrong, you just never get the events.
Update dapr run command with port 7006 to fix:
dapr run --app-id order-processor --resources-path ../../../components --app-port 7006 -- dotnet run

/assign

This looks to be correct in the Dapr docs: https://docs.dapr.io/getting-started/quickstarts/pubsub-quickstart/
but incorrect in the HTTP readme as it still says 7005: https://github.com/dapr/quickstarts/blob/master/pub_sub/csharp/http/README.md#run-dotnet-message-subscriber-with-dapr


Major refactoring

Refactored Extension.php into separate Controllers, Helpers and ServiceProviders.

Pinging @xiaohutai Don't forget about this one. ;-)

Bump @xiaohutai

@DennisSnijder
Sorry for testing this so late... I've been out of the Bolt loop for a bit.
Regarding your extension, I keep getting:
Class 'Bolt\Extension\Bolt\JsonApi\Provider\APIProvider' not found

both with testing locally in extensions/local/bolt/jsonapi/ and making a test test-pull-request branch and installing it with stability set to dev (in config.yml).
I've also tried adding [ "", "src/" ] in the extension's composer.json and then composer dumpautoload in the ./extensions/ folder, but that doesn't seem to fix it for me.
The older versions do still work for me though.

Same problem here, any updates on this?

This fork does work. I haven't been able to test any other calls other than just doing /json/pages. BOLT doesn't automatically update the installed.json file under the extensions directory if you screw up your composer.json and try to do dump-autoload. You must manually add that to the installed.json file in the composer directory.
That aside, I did have to change a few other things to get it working. I am going to try to test it some more tonight and see where I can get it. In order to get it fully working, you need to update the UtilityHelper to look like the following and update ApiResponse setContent to accept the same arguments as the Response hint change array $content to $content.
 /**
    * @param string $filename
    * @return string
    */
   public function makeAbsolutePathToThumbnail($filename = '')
   {
       $config = $this->app['extensions']->getEnabled()['JSON API']->getConfig();
       return sprintf('%s/thumbs/%sx%s/%s',
           $this->app['paths']['canonical'],
           $config['thumbnail']['width'],
           $config['thumbnail']['height'],
           $filename
       );
   }

OK, it seems to work if I add the [ "", "src/" ] fix in composer.json.


Active state on mobile menu broken

I noticed the active states in the mobile menu are no longer working correctly after the latest updates to staging. It should be highlighting the currently clicked item in red but it seems to either be showing too many in red or none at all.

Also refer to #183


The charm should error if microk8s pods aren't able to start after a while

Summary
Deploying microk8s with (most probably) missing proxy configuration causes the pods necessary for microk8s to work (like calico, coredns, etc.) not to be able to start due to not having access to the registry. On the Juju side there's no indication of an issue other than the status being stuck with no change for a long time:
Model     Controller        Cloud/Region        Version  SLA          Timestamp
microk8s  foundations-maas  maas_cloud/default  2.9.31   unsupported  10:31:31Z

App        Version  Status   Scale  Charm      Channel  Rev  Exposed  Message
microceph           waiting      3  microceph  edge       9  no       (workload) Leader not ready
microk8s            waiting      3  microk8s   edge     187  yes      waiting for control plane

Unit          Workload     Agent      Machine  Public address  Ports      Message
microceph/0   waiting      idle       0        -                          (workload) Leader not ready
microceph/1   waiting      idle       1        -                          (workload) Leader not ready
microceph/2*  maintenance  executing  2        -                          (bootstrap) Service not bootstrapped
microk8s/0    waiting      idle       0        -               16443/tcp  waiting for control plane
microk8s/1    waiting      idle       1        -               16443/tcp  waiting for control plane
microk8s/2*   waiting      executing  2        -               16443/tcp  (leader-elected) node is not ready: KubeletNotReady

Machine  State    Address        Inst id     Series  AZ   Message
0        started  -              microk8s-1  jammy   AZ1  Deployed
1        started  -              microk8s-2  jammy   AZ2  Deployed
2        started  -              microk8s-3  jammy   AZ3  Deployed

Digging a bit on the microk8s units found this situation:
root@microk8s-3:~# microk8s.kubectl get nodes
NAME         STATUS     ROLES    AGE   VERSION
microk8s-3   NotReady   <none>   60m   v1.28.2
root@microk8s-3:~# microk8s.kubectl get pods -A
NAMESPACE     NAME                                     READY   STATUS     RESTARTS   AGE
kube-system   calico-node-v2fjc                        0/1     Init:0/2   0          60m
kube-system   coredns-864597b5fd-hgwkb                 0/1     Pending    0          60m
kube-system   calico-kube-controllers-77bd7c5b-sspgd   0/1     Pending    0          60m

and messages like these on the snap.microk8s.daemon-kubelite.service logs:
Sep 15 09:38:38 microk8s-3 microk8s.daemon-kubelite[25945]: E0915 09:38:38.216844   25945 remote_runtime.go:193] "RunPodSandbox from runtime service failed" err="rpc error: code = DeadlineExceeded desc = failed to get sandbox image \"registry.k8s.io/pause:3.7\": failed to pull image \"registry.k8s.io/pause:3.7\": failed to pull and unpack image \"registry.k8s.io/pause:3.7\": failed to resolve reference \"registry.k8s.io/pause:3.7\": failed to do request: Head \"https://registry.k8s.io/v2/pause/manifests/3.7\": dial tcp <IP_ADDRESS>:443: i/o timeout"
...
Sep 15 09:40:06 microk8s-3 microk8s.daemon-kubelite[25945]: E0915 09:40:06.642264   25945 kubelet.go:2855] "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"

What Should Happen Instead?
To make for a better user experience, the units should try to detect the situation and go into error state so that the user can start checking.
Reproduction Steps
Deploy microk8s charm on an environment with no access to the registry.

Thank you for reporting this @facundofc. We should try to report the cluster's state if something goes wrong. At some level we are doing this. I see for example that the microk8s unit is reporting to be waiting for the control plane. At the level of the charm it is not so trivial to figure out what might be wrong and unfortunately k8s does not give you a single place to look for errors. In your case, it was a proxy setting, in another case might be dockerhub pull limits, or a missing kernel module, or low disk space, or a network mis-configuration, or even a slow network connection. Overall we try to report the state of the cluster but we are not (yet) in a state where we can reliably detect the exact reason for an error. Your point however is valid, we will try to improve the status report in the future by trying to detect common problems.

@ktsakalozos Wondering if there's any suggestion or workaround for this issue?
SolQA bumped into this in 10+ test runs this month.
You might find link to failed runs here - https://solutions.qa.canonical.com/bugs/2043103.


ValueError: Error initializing torch.distributed using env:// rendezvous: environment variable RANK expected, but not set

The code takes some environment variables in llama_finetuning.py. Is there a reference as to how should I set them?

@kushalj001 if you running with torchrun, https://github.com/facebookresearch/llama-recipes/tree/main#multiple-gpus-one-node they would be set automatically, also part of the debug flags are being set again automatically calling this func in the script, https://github.com/facebookresearch/llama-recipes/blob/main/utils/train_utils.py#L248


Prep for Cats 0.8.0 and Scala 2.12.0

A couple of things that can go ahead and go in.

Current coverage is 82.46% (diff: 100%)

Merging #424 into master will increase coverage by 0.04%

@@             master       #424   diff @@
==========================================
  Files            65         65
  Lines          2070       2064     -6
  Methods        1914       1911     -3
  Messages          0          0
  Branches        156        153     -3
==========================================
- Hits           1706       1702     -4
+ Misses          364        362     -2
  Partials          0          0

Powered by Codecov. Last update 873f670...996857e


Update LAST_DECL_ATTR and add verification to ensure it is always updated

I forgot to update LAST_DECL_ATTR in https://github.com/swiftlang/swift/pull/76256. Update here and verification to ensure LAST_DECL_ATTR and LAST_TYPE_ATTR is always updated.

@swift-ci smoke test

LGTM

@swift-ci test linux platform


esbuild fails when SENTRY_DSN environment variable is not defined

Problem
The esbuild build fails when the SENTRY_DSN environment variable is not defined, with the error:
Root Cause

esbuild's define option requires all values to be JSON serializable
When process.env.SENTRY_DSN is undefined, it results in an undefined value which is not a valid JSON value

Thanks for highlighting it. I have SENTRY_DSN set in my system, so I didn't notice it before. I've updated the code, could you try it now?

Thanks for highlighting it. I have SENTRY_DSN set in my system, so I didn't notice it before. I've updated the code, could you try it now?

Thanks, now it's OK, I'll close this pr: https://github.com/sweetpad-dev/sweetpad/pull/84


[FEATURE] Filter valid entities when using the ls command

medperf <entity> ls currently doesn't have an option to only show entities that have is_valid flag as True. This feature was requested from BraTS2023 organizers.
The solution would be to have an option (e.g. medperf <entity> ls --valid) that lists only valid entities.

This filtering is client-side

merge master here and see what's been changed during this half of year


Add value_attr to pie chart nodes

Dear Ben - I have added a new setting to help tooltip plugins such as Bootstrap tooltip display values when hovering over a pie slice. The only problem is I don't now how to bump the version properly, or to compile into the minified version. I have added some documentation into index.html. Please feel free to ignore the request but I saw some other people had discussed this so I thought I would put it out there..

That's great, thanks! As you say lots of people have requested this but nobody has done the work yet! Don't worry about versions and minifying etc, I'll sort that when I create a new release.
I looked at this before and got stuck considering what the best attribute would be - there's some good discussion here http://stackoverflow.com/questions/15532371/do-svg-docs-support-custom-data-attributes. To be honest I'm still not sure where I stand on it. title would be my first choice but I'm not sure whether I care about making sure it's valid SVG...


Security Groups differ from aws recommendation

I have issues
Security Groups differ from aws recommendation
I'm submitting a...

[ ] bug report
[x] feature request
[ ] support request
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
Currently, cluster sg opens outbound <IP_ADDRESS>/0 for all port.
Similarly, worker node sg opens inbound port from 0-65535 from worker node sg.
If this is a bug, how to reproduce? Please include a code sample if relevvant.
What's the expected behavior?
Aws recommends cluster sg only opens inbound 1025-65535 port to worker node sg.
Aws recommends worker sg only opens inbound 443 and 1025-65535 ports to worker node sg.
Here's the reference. https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html
Are you able to fix this problem and submit a PR? Link here if you have already.
I could fix this and submit a PR.
Environment details

Affected module version:
OS:
Terraform version:

Any other relevant info

Hey @ryanli-me

Currently, cluster sg opens outbound <IP_ADDRESS>/0 for all port.

Yes, this is for the EKS service itself. What else would you have here? Or even for the nodes, what else would you have here?

Similarly, worker node sg opens inbound port from 0-65535 from worker node sg.

This is to itself. What else would you have here? Here's the AWS CFN: https://github.com/awslabs/amazon-eks-ami/blob/master/amazon-eks-nodegroup.yaml#L207-L216

Aws recommends cluster sg only opens inbound 1025-65535 port to worker node sg.

Yes, from EKS service to nodes: https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/workers.tf#L85-L94

Aws recommends worker sg only opens inbound 443

https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/workers.tf#L96-L105

Maybe make a PR to make it clearer what you mean?

Add additional_cluster_security_group_ids or similar so that EKS control plain outbound access can be limited to worker nodes? Or can EKS control plane/cluster be attached to a single security group?

@wikko I am not 100% sure what you mean but I don't think it's related to this issue?

EKS control plain outbound access can be limited to worker nodes

This is not desirable because your kubectl from your workstation needs to access the cluster endpoint also. As does anything else that needs access to k8s API, such as deployment tools (travis, CI etc), developers and any users who use kubectl.
Hope that helps 😎

I was talking about control plane outbound access e.g. minimum and recommended outbound access for control plane is mentioned here:
https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html
How are those outbound rules relevant to kubectl?

Ahh, yes, you are correct. My mistake, I was conflating the EKS cluster endpoint and the control plane. They are separate.
Again, feel free to make a PR for these changes.

It's actually a mystery how I can connect to EKS  with kubectl when the cluster SG seems to limits inbound access to worker nodes (as recommended).

Because the cluster endpoint that kubectl connects to is like any other AWS API, i.e. always publicly accessible

I'm gonna close this now. Feel free to reopen if it's still an issue.


Replace python libraries with better maintained versions

Also fixed encoding issue in password hashing and shebang lines.
Tested and working.

Note: This would reqiure running pip install -r requirements.txt in the virtualenv again

Looks good to me. Merging. Thank you @kaechele  for your contribution.


raspios "latest" images are now .xz (not .zip) archives

The download.sh script needs to be updated accordingly, taking into account fact that xz does not like files without .xz extension....

Thank you for the report.
We can detect automatically format based on remote file suffix instead of using URL. This was done in #36.
Please feel free to submit a new PR with the typo and the new image.


fix(stream): missing transplant for zipWithLatest

Initial idea to use T.transplant came from @r-cyr, I moved the transplant up so it would apply for the entire zip.
I am not sure what kind of test I should add for this @mikearnaldi? I think the case we're solving by grafting is one where a Stream isn't closed, which I don't have a clue how to craft a test case that's supposed to end after a while.

I added a test case which is failing, so that invalidates my fix unfortunately. I am not sure if the test case is valid, but I think so.

It seems the grafting fix only changes the actual fiber that's causing the interrupt.

I traced the problem to Channel.mergeWith, I had to apply the exact same Effect.transplant to extend their lifespan into the parent scope.

Adding context from discord (for posterity):


How to beautify DUST file?

Description
how to beautify DUST file, do we need to add language in config file?
Input Before Beautification
This is what the code looked like before:
<INSERT CODE HERE>

Expected Output
The beautified code should have looked like this:
<INSERT CODE HERE>

Actual Output
The beautified code actually looked like this:
<INSERT CODE HERE>

Steps to Reproduce

Add code to Atom editor
Run command Atom Beautify: Beautify Editor
This beautified code does not look right!

Debug
Here is a link to the debug.md Gist:
Checklist
I have:

[ ] Tried uninstalling and reinstalling Atom Beautify to ensure it installed properly
[ ] Reloaded (or restarted) Atom to ensure it is not a caching issue
[ ] Searched through existing Atom Beautify Issues at https://github.com/Glavin001/atom-beautify/issues
so I know this is not a duplicate issue
[ ] Filled out the Input, Expected, and Actual sections above or have edited/removed them in a way that fully describes the issue.
[ ] Generated debugging information by executing Atom Beautify: Help Debug Editor command in Atom and added link for debug.md Gist to this issue

Is this the dust you are referring to? http://www.dustjs.com/
I vaguely remember adding support for that to Pretty Diff years ago.  If the file extension isn't recognized then submit a pull request adding language support.

https://github.com/Glavin001/atom-beautify/issues/392


[Protocol Change Request] Improving Time Travel using In-Commit Timestamps

Feature request
Overview

This feature request is about changing Delta commit timestamps to improve time travel.
Motivation

Delta currently relies on the file modification time to identify the timestamp of a commit. This timestamp is used for time travel queries, log cleanup, and staleness checks. However, file modification time is not a very reliable way of getting a timestamp — this can easily change when the files are copied/moved to another directory (e.g. for disaster recovery purposes) or when any manual fixes are performed to the Delta log. In such cases, time travel on the delta table breaks as of today. The possibility of non-monotonic file timestamps also adds lots of code complexity in Delta as we try to handle it heuristically in the best possible way.
Further details

We propose a new Writer feature that will require clients to generate a timestamp just before performing a commit and store it in the commit itself.
Compliant writers will ensure that the timestamp stored in Commit X+1 is always greater than Commit X. To be able to ensure this, the client will need to perform conflict detection for these timestamps.

The writer will write this timestamp in the CommitInfo action. Furthermore, the writer will always write CommitInfo as the first action in a commit.
Clients that understand these new timestamps will now read the commit file to get the actual timestamp. These timestamps will now be used for time travel queries and by other operations that use timestamps.

The detail proposal and the required protocol changes are sketched out in this doc.
Willingness to contribute
The Delta Lake Community encourages new feature contributions. Would you or another member of your organization be willing to contribute an implementation of this feature?

[X] Yes. I can contribute this feature independently.
[ ] Yes. I would be willing to contribute this feature with guidance from the Delta Lake community.
[ ] No. I cannot contribute this feature at this time.

This is being released as a preview feature in 3.2 (https://github.com/delta-io/delta/pull/2962). The feature will be generally available by 4.0.

This is being released in 3.3.0 (in RC stage right now)


Migrating to AWS SDK V3 | Replace node-http-handler Package

Explain the changes

@aws-sdk/node-http-handler was deprecated (here). I found it out through this aws/aws-sdk-ls-v3#4990.
I run npm uninstall @aws-sdk/node-http-handler.
I changed the imports that already used this package from @aws-sdk/node-http-handler to @smithy/node-http-handler.

Issues: Fixed #xxx / Gap #xxx

none.

Testing Instructions:

none.

[ ] Doc added/updated
[ ] Tests added

I am not sure about which is the stable version and what package we need to adopt.
Because @aws-sdk/node-http-handler package is marked under preview on aws-sdk documentation https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/preview/Package/-aws-sdk-node-http-handler/
@smithy/node-http-handler is the latest package available.
https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-smithy-node-http-handler/
The documentation is not really clear about what is what.
This link says that @smithy is rename to aws-sdk.
May be @dannyzaken @liranmauda can suggest better

Hi @v-harihar,
I'll try to respond to your comments:

I am not sure which is the stable version and what package we need to adopt.
Because @aws-sdk/node-http-handler package is marked under preview on aws-sdk documentation https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/preview/Package/-aws-sdk-node-http-handler/

The comment about preview is about the documentation API: "This AWS SDK API Reference for JavaScript v3 is in preview and is subject to change." and not about the package itself, the current version is this. Inside it you can see the package @smithy/node-http-handler (here).

@smithy/node-http-handler is the latest package available. https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-smithy-node-http-handler/

I agree, I also added in the description the PR that changed the packages.

The documentation is not really clear about what is what.
This link says that @smithy is rename to aws-sdk.

In the link, it says: "The @aws-sdk/node-http-handler package has become deprecated... Apparently it has now moved to the @smithy". It is fine, we move to use the package under smithy.
@dannyzaken @liranmauda I hope it is clear.


Add PostGIS support

Hello again,
First, I updated the scripts so that all of the prefixes are gtfs_. Some where gtf_. I'm not sure if you had a good reason for that but I couldn't figure it out. =) But more importantly...
I added gtfs_tables_makespatial.sql to add PostGIS support. This basically adds a the_geom column to gtfs_stops and makes a new gtfs_shape_geoms that has a shape_id and the_geom columns, and mirrors gtfs_shapes but much fewer rows (only 1 per trip).
Finally, I converted the README to markdown so I could read it better, rearranged a few things, and added PostGIS docs.
I hope this is useful for you. It certainly is for me!

Thanks again, this is great
On Mon, Dec 19, 2011 at 11:34 AM, Aaron Ogle <
<EMAIL_ADDRESS>
wrote:

Hello again,
First, I updated the scripts so that all of the prefixes are gtfs_. Some
where gtf_. I'm not sure if you had a good reason for that but I couldn't
figure it out. =) But more importantly...
I added gtfs_tables_makespatial.sql to add PostGIS support. This basically
adds a the_geom column to gtfs_stops and makes a new gtfs_shape_geoms
that has a shape_id and the_geom columns, and mirrors gtfs_shapes but
much fewer rows (only 1 per trip).
Finally, I converted the README to markdown so I could read it better,
rearranged a few things, and added PostGIS docs.
I hope this is useful for you. It certainly is for me!
You can merge this Pull Request by running:
git pull https://github.com/atogle/gtfs_sql_importer master
Or you can view, comment on it, or merge it online at:
https://github.com/cbick/gtfs_SQL_importer/pull/3
-- Commit Summary --

change all table prefixes to 'gtfs', not 'gtf'
add geometry support for postgis
add spatial indexes
README to markdown, add postgis docs
rename README to README.md
drop gtfs_shape_geoms in case it already exists

-- File Changes --
R README.md (101)
M src/gtfs_tables.sql (104)
M src/gtfs_tables.sqlite (132)
M src/gtfs_tables_dropindexes.sql (112)
M src/gtfs_tables_makeindexes.sql (148)
M src/gtfs_tables_makeindexes.sqlite (6)
A src/gtfs_tables_makespatial.sql (37)
M src/import_gtfs_to_sql.py (2)
M src/vacuumer.sql (26)
-- Patch Links --
https://github.com/cbick/gtfs_SQL_importer/pull/3.patch
https://github.com/cbick/gtfs_SQL_importer/pull/3.diff

Reply to this email directly or view it on GitHub:
https://github.com/cbick/gtfs_SQL_importer/pull/3


feat(dashboard-renderer): add grid layout components

Summary
Grid layout
https://konghq.atlassian.net/browse/MA-2268
Add new GridLayout component to act as the foundation from where we can continue expanding custom dashboards.
GridLayout is a separate, standalone component that can be imported from this package and used to arbitrarily render any content, components, divs, etc in a grid, on any page, anywhere.
Updated DashboardRenderer to use GridLayout for laying out the Tiles
Updated DashboardDefinition and TileDefinition schemas to include positioning and sizing info that is passed off to the GridLayout component
Grid defaults to tiles that are minimum width and height of  150px by 150px
See the following example:
<DashboardRenderer
  :context="context"
  :definition="definition"
/>

const context: DashboardRendererContext = {
  filters: [],
  timeSpec: {
    type: 'relative',
    time_range: '15M',
  },
}

const definition: DashboardDefinition = {
  // 5 x 5 grid
  gridSize: {
    cols: 5,
    rows: 5,
  }
  tiles: [
    {
      chart: {
        type: ChartTypes.HorizontalBar,
      },
      query: {},
      // Position at column 1, row 1
      position: {
        col: 1,
        row: 1,
      },
      // Spans 3 columns and 2 rows
      size: {
        col: 3,
        row: 2,
      }
    },
    {
      chart: {
        type: ChartTypes.Gauge,
        metricDisplay: ChartMetricDisplay.Full,
        reverseDataset: true,
        numerator: 0,
      },
      query: {},
      // Position at column 1, row 3
      position: {
        col: 1,
        row: 3,
      },
      // Spans 3 columns and 2 rows
      size: {
        col: 3,
        row: 2,
      }
    },
  ],
}

https://www.loom.com/share/d1860d63881049e8b1d5feeff8ed054a

PR Checklist

[ ] Naming & Structure: the files and package structure use the conventions outlined in the Creating a Package docs.
[ ] Tests pass: check the output of all package unit and/or component tests.

[ ] If this PR is the result of a bug, test coverage was added accordingly.

[ ] Functional: all changes do not break existing APIs, but if so, a BREAKING CHANGE commit is in place to bump the major version.
[ ] Conventional Commits all commits follow the conventional commit standards outlined in the main README.
[ ] Docs: includes a technically accurate README, and the docs have been updated accordingly based on the changes in this PR.

I thought this was going to be a POC, not actually merged into the package?

I thought this was going to be a POC, not actually merged into the package?

I made quick enough progress on the layout that it doesn't need to be a POC, we need to use the layout for the feature.
Eventually it can be replaced once there's a Kongponent that meets our needs here?

@filipgutica I think it would make sense to look for an existing library to generate the grid instead of creating something like this from scratch. I'm guessing one exists that also supports saving the layout, etc. like we chatted about

This component already does everything we need it to do, as, is in this PR. Can we not move forward with this?


Unify license

Licensing README under different license seems unnecessary. Why?
There is a good reason to use one license.
Could the whole package be (re-)licensed under Apache-2.0 please? Thanks.

no problem, feel free to open a pull request to change it.


Update getting started

I've updated the getting started tutorial. It was too boring 🐳

Deploy preview ready!
Built with commit 8dde9eebc5b1332f7ee769eb3a3a04c3c407b6cc
https://deploy-preview-696--docker-docs.netlify.com

🐳🚀


var variable undefined

It seems there is an issue related to var declarations:
function main() {
    var x = 'before';
    console.log(x);
    var x = 'after';
}
main();

The expected behaviour is printing "before", while it prints "undefined".
This code work as expected:
function main() {
    x = 'before';
    console.log(x);
    var x = 'after';
}
main();

My guess is that it's hoisted both var declarations separately rather than merging them.
What are you trying to achieve with this code?

I'm trying to avoid var, it is just that I've spotted a difference between official JavaScript and Microvium.

Ok, thanks for pointing it out. I've added it to the to-do list.


Can't move while jumping

Hi!
As the title says, I can't seem to move when i jump.
I'm new to XR and Godot Development, but everything (but that issue) is working correctly.
Is it possible to configure the XRToolsPlayerBody or the Physics config to do that? Thanks heh

Ended up doing my own movement script heh


BlackRock changes

When calling getAllUsers() the method queries for all Symphony user ids, and then creates a bunch of threads that each queries Symphony POD for the information about a user id. The code currently allows 5 seconds for all users to be returned. After 5 seconds it returns the subset of users that have been added; in BlackRock this means calls to getAllUsers() only returns one third of all users. Additionally the flag indicating if a given SymUser is active, e.g. their account is enabled, is not set.
This pull request:

Leaves the default time for waiting for all user data to be returned (unchanged) at 5 seconds
Allows the default time to be modified by setting SYMPHONY_GET_ALL_USERS_TIMEOUT as a VM argument, e.g. for 2 minutes -DSYMPHONY_GET_ALL_USERS_TIMEOUT=120
Sets the active flag on SymUser when calling getAllUsersWithDetails()

Updated code in line with previous comments.
Thoughts?

I will merge this pull request on Tuesday 16th October (2 weeks away).
Please raise any concerns prior to this date.


Possible to get 'total bytes sent' and 'stream end' from ctx.seekableStream ?

I'm using ctx.seekableStream(file.inputStream(), "audio/mpeg") to stream files to the client and I'm planning to log some statistics about how many bytes have actually been sent. As far as I understand the browser it will call the endpoint multiple times to get a small chunk on every request.
Is it possible to get this information from the seekable stream somehow?
And is it possible to identify when the stream (chunk) ended?
Ty for any information.

Just after posting this question I checked the response headers and found out that: ctx.res.getHeader(Header.CONTENT_LENGTH) is probably what I was looking for 🙂.
Now I assume this is what the browser will receive but the process is asynchronous and might be aborted bevor all bytes are transferred right?

@fq-selbach async or not isn't relevant here, I think, since the browser is free to stop reading the response at any point for any reason. The content-length header will tell you the size of the chunk, and you can also get information about which chunk it is (the range). This is what SeekableWriter.kt does:
ctx.status(206)
ctx.header(Header.CONTENT_TYPE, contentType)
ctx.header(Header.ACCEPT_RANGES, "bytes")
ctx.header(Header.CONTENT_RANGE, "bytes $from-$to/$totalBytes")
ctx.header(Header.CONTENT_LENGTH, "${to - from + 1}")
ctx.res.outputStream.write(inputStream, from, to)

Hi @tipsy , thanks for the info.
It looks like the data in the header depends on how the browser (or any client) actually reads the data 🤔 because sometimes it requests multiple small chunks and other times it simply requests the complete file. In the latter case ctx.res.getHeader(Header.CONTENT_LENGTH) is empty :-| probably due to if (ctx.header(Header.RANGE) == null) { ....

since the browser is free to stop reading the response at any point for any reason

Because of that I was wondering if we could get the actual sent bytes from the stream itself?
I'm using Javalin v3.13.12 btw.

@fq-selbach I suppose you could wrap the output stream and attach a listener to it?

Maybe something about g-zip compression 🤔

I don't think there is any gzip-compression on this, the SeekableWriter is writing directly to the output stream.
The SeekableWriter class is very small, maybe it makes sense to copy and modify it?

It's an option, but I'm not really sure how :-/.
The thing that confuses me is that CountingInputStream.getByteCount is either too large or 0 (when SeekableWriter uses ctx.result(inputStream)). I doubt that any custom modification will give a different result.

Well, to modify it I first need to understand where to find the information I need. The class is not doing anything magical so my best guess was to count bytes via CountingInputStream which doesn't even require modification of SeekableWriter because we have access to the input stream. Now I'm not sure what the problem is, why is the number of bytes 0 in the ctx.result(inputStream) case and why is it too big in the ctx.res.outputStream.write(inputStream, from, to) case? 🤷♂ Maybe my understanding of the InputStream is wrong ... I'm not sure ...

If you copy the class you can create your own version of this function:
private fun OutputStream.write(inputStream: InputStream, from: Int, to: Int, buffer: ByteArray = ByteArray(1024)) = inputStream.use {
    it.skip(from.toLong())
    var bytesLeft = to - from + 1
    while (bytesLeft != 0) {
        val read = it.read(buffer, 0, Math.min(buffer.size, bytesLeft))
        this.write(buffer, 0, read)
        bytesLeft -= read
    }
}

And add your counter inside of it?

CountingInputStream should in theory count every byte read via it.read(...). So at this point I guess I have to prove that the result is the same. Both outcomes will create a bunch of follow-up questions 😆 but I guess that's inevitable now.
The reason why I want to use CountingInputStream is that it's supposed to apply in the same way to ctx.res.outputStream.write and ctx.result(inputStream). The latter case is probably the bigger problem because in the first case the chunks and the value of ctx.res.getHeader(Header.CONTENT_LENGTH) are at least approximately the same.
Assuming I'd write a new SeekableWriter I can simply replace ctx.seekableStream(file.inputStream(), "audio/mpeg") with SeekableWriterV2.write(ctx, file.inputStream(), "audio/mpeg") ?

I think I solved the "mystery" 🙂.
CountingInputStream counts the skipped bytes as well meaning each request that reads only a chunk of the file is counted as "read bytes" + "skipped bytes" to find position. In the case where the whole file was read at once I was simply counting the bytes too early since the stream is read after ctx.result(inputStream) returned.
So I ended up writing a new CountingInputStream implementation instead of a new SeekableWriter like this:
import static org.apache.commons.io.IOUtils.EOF;
import java.io.IOException;
import java.io.InputStream;
import java.util.function.Consumer;
import org.apache.commons.io.input.CountingInputStream;

/**
 * Adapted version of {@link CountingInputStream} to get download statistics.
 */
public class DownloadCounterStream extends CountingInputStream {

    private long totalBytesRead = 0l;
    private Consumer<Long> onClose;

    /**
    * Constructs a new DownloadCounterStream.
    * @param in - the input stream
    * @param onClose - callback on stream close with totalBytesRead
    */
    public DownloadCounterStream(final InputStream in, Consumer<Long> onClose) {
        super(in);
        this.onClose = onClose;
    }

    /**
     * Get total bytes actually read by this stream
     * (without skipped bytes like {@link #getByteCount()}).
     */
    public long getTotalBytesRead(){
    	return this.totalBytesRead;
    }

    /**
     * Adds the number of read bytes to the count.
     */
    @Override
    protected synchronized void afterRead(final int n) {
        if (n != EOF) {
            this.totalBytesRead += n;
        }
        super.afterRead(n);
    }

    @Override
    public void close() throws IOException {
    	super.close();
    	this.onClose.accept(this.totalBytesRead);
    }
}

And I'm using it like this:
DownloadCounterStream is = new DownloadCounterStream(Files.newInputStream(file.toPath()), total -> {
    System.out.println("Total bytes sent: " + total);
});
ctx.seekableStream(is, ct);

Nice ! I'll add an "info" tag to the issue :)


Can no longer craft enchanted golden apples

The mod used to add the crafting recipe for the enchanted golden apple to match LCE. In 1.7 this has disappeared. Is this intentional? It might have been accidentally removed when adding updating the mod to 1.21, which added new crafting recipes.

Cobweb to string recipe from TU57 is gone too.

Fixed in version 1.7.3, thanks for reporting.


Break and continue blocks

We did both for microbit. Lets just be consistent in my opinion.

We did both for microbit. Lets just be consistent in my opinion.


refactor(migrate): add createDatabase & ensureConnectionValidity to RPC

Removed planMigration
Reordered all definitions alphabetically
added createDatabase & ensureConnectionValidity to RPC API

Related https://github.com/prisma/schema-team/issues/309
TODO in next PR

[ ] Replace usage of command in createDatabase to createDatabase RPC
[ ] Replace usage of command in canConnectToDatabase to ensureConnectionValidity RPC

TODO: fix conflicts


Disable packages sent to sentry

Problem Statement
Would love to disable sending packages information with each error. Looks like waste of resources since these dependencies are very stable and we have more than 50 of packages. Never used this info to debug an error.

Solution Brainstorm
Just add a setting to disable sending this information.

You can disable the package integration as shown here https://docs.sentry.io/platforms/php/guides/laravel/integrations/#custom-integrations
Just replace \Sentry\Integration\ExceptionListenerIntegration with \Sentry\Integration\ModulesIntegration.


[US] Enhance Use Case 2 functionalities

As a user of the app, I want to enhance the use case 2 functionalities, so that I can update a ticket's information and close a ticket.

MoSCoW
Risk
Story Points

Should have
low
2

Acceptance Criteria

Use custom buttons feature for extra functionalities
Have a test suit for the url used for the functionalities

Tasks

[x] Add new functionalities as stored procedures

[x] Update ticket info/status
[x] Assign ticket to a user
[x] Any other functionality found to be desirable (as found by the developer working on this)

[x] Update ER diagram and port it to diagram.io

https://github.com/WillTrem/UInnovate/assets/10947924/fa26dbf6-0055-4de1-8af0-9dd9019c3b00

Signing off!

Uploading US146_updated.mp4…

https://github.com/WillTrem/UInnovate/assets/10947924/b77d80e5-39f5-45f1-9822-9f391c2d8b27