Update all forum links to community.cesium.com

This updates all links in this repo from the old Google groups to the new community.cesium.com and changes names from forum -> community forum where appropriate.
I also updated forum links in the change log to point to the right topic in the new community forum.
@shehzan10

Thanks for the pull request @OmarShehata!

:heavy_check_mark: Signed CLA found.
:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

Fixed http -> https and the one incorrect link in changes.md.
@shehzan10

LGTM. Thanks @OmarShehata.


General Issue: Clean-up Round 2

Background Information
To achieve a "stable" admiral version we need a clean-up of admiral, i.e.,

avoid that functionality of functions overlaps
name function and arguments consistently
close gaps in functionality

This issue is intended to collect functions which should be revised and identify gaps.
@pharmaverse/admiral , please feel free to add.
Definition of Done
No response

From @kaz462 :
There are four functions for deriving extreme event/record as a new parameter, the function names are a bit confusing to me when I try to compare them: _record(s)/_event, with/without _param
| Data source:      one or multiple | Extreme is ordered by - | filter/dataset source argument name
-- | -- | -- | --
1.derive_extreme_records| one | order argument | filter/ |
2.derive_extreme_event  | one | the order of events entered and the order argument |
3.derive_param_extreme_event | one  |order argument| filter_source/dataset_source
4.derive_param_extreme_record | multiple   | the order of sources entered and the order argument   | /source_datasets |

What do you think of combining some functions? e.g.,

function 3 is a special case of function 2 (has been combined through https://github.com/pharmaverse/admiral/pull/1882)

function 4 is an extension of function 2 by allowing multiple data sources

Should we make some argument name consisnent across those functions?

Should all flag functions provide true_vlue and false_value argument?

derive_summary_records() should provide the dataset_add argument.
Consider the following use case.
adae <- adae %>%
  mutate(AVAL = 1)

adsaftte_aetot <- derive_summary_records(
  adae,
  filter = ANL01FL == "Y",
  set_values_to = exprs(
    PARAMCD = "AETOT1",
    PARAM = "Number of occurrences of any adverse event",
    PARCAT1 = "Total Occurrences",
    ANL01FL = "Y"
  ),
  by_vars = exprs(STUDYID, USUBJID),
  analysis_var = AVAL,
  summary_fun = sum
) %>%
  filter(PARAMCD == "AETOT1") %>%
  select(STUDYID, USUBJID, PARAMCD, PARAM, PARCAT1, AVAL, ANL01FL)

The filter() and select() call at the end could be omitted if the dataset_add argument is available.

The arguments of derive_vars_joined(), derive_var_joined_exist_flag(), and filter_joined() should be made consistent. For example, all functions should provide the dataset_add argument.

@bms63 should we actually turn this into discussion with the respective individual pieces of consolidation as their own issues?

Yes lets move to discussion - also makes it easier to follow threads


Add Large Tile Stamp Tool for Tiled

This is an extension / script someone wrote for me that should allow the user to simulate the effect of different grid size tiled layers in a single map. We'd have to configure the parser to take this into account and with respect to tile skipping, on those layers, though, but there are certainly advantages to using larger tile sizes for background layers.

Is it ok to publish this extension as MIT?

I'll ask but the repository says

Feel free to use these scripts as you wish. Credit appreciated but not required.


update hin api server

This resubmission is to correct http -> https for api servers.  Looks like it should work


Implement Commons categories (+ category depth) as 'starting point' for new OpenRefine projects

(This first was an issue in the OpenRefine/OpenRefine repository, but we have decided to implement this as part of the Commons extension.)
When editing batches of Wikimedia Commons files, regular Commons and GLAM contributors will typically take one or more Wikimedia Commons categories as input or 'starting point' in various tools. Examples include AC/DC, the ISA Tool, and VisualFileChange. It would be great if that would be possible in OpenRefine too (rather than asking users to start with a list of file names).
Alternatives considered
In the earlier integration scenarios, we kind of assumed that users would start off with lists of file names.
However, this does produce some extra hurdles to users (which may be especially difficult and annoying to newcomers). They would have to use other tools in order to get a list of file names on Wikimedia Commons, which complicates the workflow.
Typically, users would resort to

PetScan outputting csv, tsv, plain text or a PagePile (example query)
the Wikimedia Commons query service (example query) (much less frequently though, as WCQS is not yet very actively used)

These tools are not rocket science, but they're not super intuitive either. It's absolutely possible to help users figure this out through documentation and by providing sample queries that are very easy to modify. That said, it will be a more smooth and seamless and less frustrating experience if the Commons Extension facilitates direct usage of Commons categories.
Additional context
Typically, Wikimedia tools allow refined interaction with Commons categories, which we want to facilitate too:

Choosing/selecting categories at once
Specifying subcategory depth for each individual category

Various screenshots of how other Wikimedia tools do this:
The ISA Tool

PetScan

(link to this example)

Wireframes by @lozanaross:

Part of general upload workflow wireframes (v2, February 2022).

Some nice categories to test with (good mix of not too specific, nice number of files to be returned, interesting subcategories)

Category:Temminck Groll Collection - simple flat category, you can use this with depth 0, will return 2,000+ files
Category:Photographs by Gerard Dukker in the Netherlands - larger set of files, try this with depth 3 or 4. There may be redundancy of files returned.
Category:Emoji - try this with depth 3 or 4 as well


DO NOT MERGE - Try to reproduce issue #90 visual acceptance test

This project uses semver, please check the scope of this pr:

[x] #patch# - backwards-compatible bug fix
[ ] #minor# - adding functionality in a backwards-compatible manner
[ ] #major# - incompatible API change

CHANGELOG
Please add a description of your change here, it will be automatically prepended to the CHANGELOG.md file.

Visual Acceptance tests:
No changes

Seems to be working fine. I did the following:
Commit + push => with change in tests = new changes
Commit + push => with change in the same tests (different from first change) = new changes
Commit + push => with non related change = new changes with the same picture that the first time
I will git it one last try:
Commit + push => with change in tests
Commit + push => with non related changes


Clean proxy in logs

Fixes #30

Codecov Report

Merging #42 into master will increase coverage by 0.40%.
The diff coverage is 57.14%.

@@            Coverage Diff             @@
##           master      #42      +/-   ##
==========================================
+ Coverage   51.68%   52.08%   +0.40%
==========================================
  Files           5        5
  Lines         238      240       +2
  Branches       39       39
==========================================
+ Hits          123      125       +2
  Misses        109      109
  Partials        6        6

Impacted Files
Coverage Δ

rotating_proxies/expire.py
79.34% <57.14%> (+0.45%)
:arrow_up:

@kmike could you please review it?


Amazon S3 authentication error

I can no longer run pipeline, getting the following error:
botocore.exceptions.NoCredentialsError: Unable to locate credentials

I think this is associated with this commit that now gets data from Amazon S3? Anyway, this may not really be a big deal if I don't need to run pipeline myself, but I'd flag it because it makes it hard for me to check code updates.

We require detailed metadata with associated submission dates to properly reconstruct sequence counts that were available on past date. I've made a note of this in commit 65db26cb2b8adcb2b7590651473f3e78f929ff1e.
Once we have a more final analysis we can version the derived sequence counts.


Custom title page for LaTeX documents/books

Link to suggestion
https://github.com/nmfs-opensci/quarto_titlepages
Targeted section
Extensions
Describe your suggestion
This template makes a custom title page using the information in the YAML (from the xyz.qmd for a single doc and from index.qmd for a Quarto book).
Checklist

[X] checked if your suggestion is not already listed in Awesome Quarto list.
[X] checked if it can fit in an existed section or open a discussion to suggest any new sections..
[X] checked when it's a repository if it's maintained (archived repository will be rejected).

Ok, v2.0 is ready and extension seems to be working.
https://github.com/nmfs-opensci/quarto_titlepages
Thanks for your help! I added you to the acknowledgements/author list.


Update ipartition to 3.6.0

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask's name and version.

Thank you for the contribution. It was merged directly as dd3e0d76d06f3c2144dd91da8dd5696d8f0f0fa3. Your contribution is still credited to you.


added year_num() function: process from R-Instat to extract year from a date

added date_components.py file containing a single function year_num() following a similar structure to climatol windrose() to call R script and retrieve output
added yday_366.r containing an R function required by year_num()

@iedwards some general questions arising from this PR:

What is the correct folder and file structure for the processes to be created? e.g. a folder for each process, or each group like R-Instat,? Should files contain a single function?
Should we be using a documentation convention such as docstrings to document Python functions created?
In what format will data be passed in to processes? e.g. obs for windrose() or dates for year_num(). Will the processes need to deal with multiple formats or will this be standardised?
In what format should functions that return data be in? Here I have used np.array to return a numeric array of years.
There seems to be multiple ways of using the rpy2 package to interact with R. For example, I used a different way of converting a Python array into an R compatible array than used in climatol windrose()

Happy to make separate issues for these questions to allow discussion.

Do we want to expose functions like year_num()?
I had expected this level of function to remain hidden, perhaps inside an R-instat CRAN library, and that only the process names that we identified in the process catalog would be made available in this intial phase?

Yes, possibly this is not useful to expose. I picked this from the R-Instat processes list as one that I thought was simple to implement to start understanding rpy2 and how to implement generally. I could pick a more obvious useful one instead like a graphical display.

Apologies Danny - I didn't remember that "make dates from components" and "use dates" (to return the component parts) were top priorities on the R-Instat process list.
This is a capability that is likely to be required when importing, exporting and cleaning data and will also feed into other processes.
I'll take another look at it in this context. It raises some interesting questions.

Yes, that makes sense. It wasn't clear to me how this might be used directly but it could be useful as a data processing step for other processes as you mention.
If you could also comment on the general approach that would be useful as I could then start on some of the graphical processes.

Is there an obvious process (or processes) that could use the date components that we can do next and use as a demonstration?

There are some R-Instat processes that require date components, for example, the climatic boxplots process requires year and "day of year" components from the date. If we assume that the climatic boxplot process will have a single "date" argument then it could use the internal date component methods internally. Is that the kind of thing you were thinking? If so, I could add that process to the PR.

I think the aim here is to enable a dialogue to set up the required dates and times and to pass them into the database in the right format. Climsoft uses a datetime data type, but other databases will use other formats, especially the CLICOM CSV files which are numeric text fields. So this is a sub-process which will be needed by a lot of other processes. It might be as simple as defining in the API interface that the argument must be a datetime type value or range, and then for those databases which always use a datetime, then the action is null, but for others it would translate the datetime into text or numbers. There is a linked issue about the exact definition of the datetime attached to an observation, especially for values over a period (rainfall, max and min temperature etc). Midas and Climsoft define these as the time of observation, with the period extending backwards from that time. CLICOM used the traditional "cast-back" date for daily rainfall and max temperature, but not min temperature. WIGOS metadata allows for multiple definitions including the start of period and mid-period.

Yes, I think these might be lower level processes to handle dates/times from and into databases. There's also a question of whether these should be implemented via R as they could also be done easily in Python.
My intention here was mainly to create an example of an R-Instat process implemented in this structure, but I recognise this wasn't the best starting point as date/times has broader points to consider. I think a graphical process might be a simpler starting point.

@dannyparsons I actually think we're on the right track here.
Yes, date management in the database will be more complicated and we'll need to create similar capabilities in Python in the future, but if we continue as we are we have the opportunity to achieve:
a) three or more externally-identified high-priority R-Instat processes implemented
b) a demonstration of process chaining
c) conformance with our principle of working with external libraries (e.g. R-Instat) without modifying them to suit OpenCDMS, e.g. using date components to give boxplots the input it expects

Ok I'll continue on this to implement the climatic boxplots functionality as well using the date components aspects.
How do you see process chaining working? One implementation of climatic boxplots would be calling the date components within the method e.g.
def climatic_boxplots(date, ...) # + other parameters for boxplot
   # call date component processes
   year <- year_num(date)
   doy <- doy(date)
   # call R code to produce boxplots

But this isn't chaining the processes, just calling them within each other.
In R you could do something like below where df is a data frame with date and rain columns. This is 'piped' to the mutate() function to manipulate the data by adding year and doy columns and then the result with the new columns is piped to ggplot to produce the graph. (mutate is part of the dplyr package's "grammar of data manipulation")
df %>%
   mutate(year = year_num(date), doy = doy(date)) %>%
   ggplot(aes(x = doy, y = rain)) +
      geom_boxplot() +
      facet_wrap(~year)

In Python we could achieve something similar by adopting the pandas package for working with data and any one of the data manipulation packages that replicate dplyr's piping (dplython, plydata, pandas-ply). Maybe something like:
def climatic_boxplots(data, ...) # + other parmaters for boxplot
   data >> mutate(year = year_num(X.date), doy = doy(X.date)) >> boxplots(x = "doy", y = "rain", facet = "year")

Is this the kind of thing you were thinking of or not?

Piping the output of one function to the input to the next function isn't standard in Python - it's probable best that we don't force developers to use it (but it looks interesting, and could be useful).
By "chaining" I just mean two separate functions that can be called sequentially.

In the Python environment I'm using "chaining" in the context of a function chain (due to our grammar conversations - see image below):

new_obs = add_date_components(obs)
plot = boxplot(new_obs, ...)

It could be combined in a single statement, but it's not necessary: boxplot(add_date_components(obs), ...)
My example may be contrived... new_obs may actually be the same object as obs.

In the Web API context I mean "process chaining". I'm having trouble finding a simple example, but see here

We already have pandas as a pyopencdms dependency... could you return a pandas' DataFrame instead of a numpy array?

Most of you already know (sorry!), but here is a reminder of plain R ways to extract components from a date. Example:
date=as.Date('2020-04-17') #create a date
strftime(date,'%Y') #year
strftime(date,'%m') #month
strftime(date,'%d') #day
strftime(date,'%j') #day of the year ('julian' day)


Add stars as class method

Fixes #9

@nkprince007 Why did you remove the initialize method? Only doing self.stars will define stars as a class method.

@nkprince007 You can close this PR and make a new one updating the readme. Issue #9 is being updated now.

Sure.


Use /attachments/refresh-urls for attachment URLs without expiry parameters

Describe the request
Use /attachments/refresh-urls for attachment URLs without expiry parameters
Is your feature request related to a problem? Please describe.
Attachment URLs without expiry parameters fail the command when using slash commands
Additional context
POST /attachments/refresh-urls
{"attachment_urls": ["url1", ...]}

No? If they didn't want bots using it they would've made bots unable to use it.

Fair enough, this just does not seem like something that Discord wants bot devs to use, especically if this can be used on older URLs.
Maybe make a PR to the api docs and see if they accept it to confirm if its allowed/intentionally exposed to bots?

I'm not speaking on Essem's behalf, his opinion very likely differs from mine, I'm just expressing disbelief that this is something Discord intentionally left open.
Feel free to reopen this, Essem might do it.

From what I understand the attachment expiry was to stop people from using Discord's CDN as personal file hosting. I see no reason why they'd have problems with bots using it to refresh attachments from within Discord.

Looking at the original announcement for the change (you'll need to be in the Discord Developers guild to view), it looks like it's intended for bots to be able to refresh attachments:

To access the attachment CDN link after the link expires, your app will need to fetch a new CDN URL. The API will automatically return valid, non-expired URLs when you access resources that contain an attachment CDN URL, like when retrieving a message.

With this in mind, I don't see much of an issue with implementing this.

Okay so they just did something that inconviences everyone and then introduced an api endpoint, intended for bots, that completely defeats the point of them doing it.


Publish C++ development style guidelines

We are implicitly following parts of the Google C++ style guide, but as we are taking some departures from it (e.g., exceptions, user-defined literals, etc.), we should do one of the following:

publish a complete style guide on what features we will or won't use, OR
publish a style guide that's a diff based on the Google C++ style guide

At the very least, we should clarify that we're using only what's available in C++11 and Abseil. Other questions might be around what can be brought in from other third-party libraries, e.g., Boost, which the Google C++ style guide also has a section on.
Without such clarification, it's unclear what contributors can use for development and what they can't (or at least, shouldn't).

Made sure the style guide covers:
[] Which files are included with <foo.h> vs. "foo.h"
[] When is it necessary to root namespaces, i.e. ::testing vs. testing, or ::google.


Possible Memory Leak in scipy.spatial.distance.pdist and scipy.spatial.distance.cdist

My issue is about a possible memory leak in scipy.spatial.distance.pdist and scipy.spatial.distance.cdist
Reproducing code example:

import numpy as np
from scipy.spatial.distance import pdist
X = np.random.uniform(0, 100, size=10000).reshape(-1, 10)
for _ in range(10000):
    test = pdist(X/0.01, metric='sqeuclidean')

Error Description:
On my Mac OSX 10.14.6 the memory consumption of the snipped above quickly rises into the Gigabytes (after a few seconds). If I remove the division from the pdist argument (see below), the problem vanishes. (I don't think this is intended behavior, as it also leads to excessive memory consumption in the Gaussian Process Regression implementation of Sklearn, where they have a similar line in the implementation of the RBF kernel)
The code, which does not produce this problem (division removed):
import numpy as np
from scipy.spatial.distance import pdist
X = np.random.uniform(0, 100, size=10000).reshape(-1, 10)
for _ in range(10000):
    test = pdist(X, metric='sqeuclidean')

Scipy/Numpy/Python version information:
1.7.0 1.21.0 sys.version_info(major=3, minor=8, micro=5, releaselevel='final', serial=0)

This is a duplicate of  #14382 and should be fixed in the next minor release.

Fixed by https://github.com/scipy/scipy/pull/14384 ; I wonder if I need to think about getting that out sooner than later.

Fixed by #14384 ; I wonder if I need to think about getting that out sooner than later.

Thanks a lot! By installing from source, I indeed managed to verify, that the problem seems to be solved.
I personally would appreciate being able to install this new version via pip, as I need to also run my code on a cluster, where I doubt that I have enough privileges to build from source.


Apply CSRF fixes from #4176 to develop

I haven't adequately tested this, give me a chance to run through them all before merging.

Okay this is good to merge.


feature - use a curved layout

Replace the deprecated WearableListView in the SunshineWatchFaceConfigActivity with the new WearableRecyclerView.

Have replaced with WearableRecyclerView.


Add basic code coverage/API tests for RFSA

What does this Pull Request accomplish?
Add tests that exercise the different codegen features in the RFSA service to make sure we get reasonable results.
Why should this Pull Request be merged?
Improve validation of RFSA service.
What testing has been done?
Ran and passed included tests. Except GetRelayName_ReturnsRelayName, which currently fails due to AB#1639825.

Bypassing @SparkingSpork . More j2. Need to fix the build.


spike interface integration

Hi @JaerongA, one early comment while this is still in progress - if the current plan is to keep the integration on a separate but permanent branch, let's use a more meaningful name for the branch on the upstream repo. Something like datajoint-spikeinterface or spikeinterface so that users looking through the list of branches will know what it contains.

Hi @JaerongA, one early comment while this is still in progress - if the current plan is to keep the integration on a separate but permanent branch, let's use a more meaningful name for the branch on the upstream repo. Something like datajoint-spikeinterface or spikeinterface so that users looking through the list of branches will know what it contains.

Sure. Good suggestion.. I'll change the name.


Add web page showing DUT console

The web page which can send commands to DUT via serial port and shows the DUT console is added.
The specification;

you can select the serial port which you send commands to from the "select serial" button. After that, the text saying "port is selected" will be shown and the serial port will be opened.
you can send commands to your DUT via the port from the form bottom of the web page. Then, the DUT console will be shown on the page. If you didn't select any port, alert window will be shown.

Notice;

DUT default shell is bash, so the console output is decorated. Therefore, the escape sequence is displayed as garbled characters. You should run /bin/sh command at first.

I fixed reviewed points.

move directory & add to index.md
change font
fix the button position
scroll automatically when a list item is added

I fixed the element sizes and the scrolling bug. Please check when you have time!

LGTM!! Thanks for fixing the issue!


Cookie is not a constructor

I'm using that command to login in https://github.com/jlobos/instagram-web-api#instagramcredentials-opts
const client = new Instagram({ username: '', password: '' })
But I get that error:
TypeError: Cookie is not a constructor

Please share your entire code so we can help you

Hello thanks for the reply.
With debug I can see that the problem is on :
    const request = require('request-promise-native')
    const jar = request.jar(cookieStore)
    jar.setCookie(request.cookie('ig_cb=1'), baseUrl)

My Controller:
exports.index = async (req, res) => {

    const client = new Instagram( {"username":"XXXX","password":"XXX"} )

    console.dir(client);

    res.render('instagram/index', {
        title: 'Instagram'
    });
};

My dependencies
"@fortawesome/fontawesome-free": "^5.15.3",
    "@ladjs/bootstrap-social": "^7.0.2",
    "axios": "^0.19.2",
    "body-parser": "^1.19.0",
    "bootstrap": "^4.6.0",
    "bootstrap-social": "^5.1.1",
    "chalk": "^4.1.1",
    "clipboard": "^2.0.8",
    "coinmarketcap-api": "^3.1.1",
    "compression": "^1.7.4",
    "connect-mongo": "^3.2.0",
    "cron": "^1.8.2",
    "datepicker-moment": "^2.0.2",
    "dialogs": "^2.0.1",
    "dotenv": "^8.2.0",
    "errorhandler": "^1.5.1",
    "express": "^4.17.1",
    "express-flash": "^0.0.2",
    "express-handlebars": "^5.3.0",
    "express-session": "^1.17.1",
    "express-status-monitor": "^1.3.3",
    "fs": "*",
    "google-drive-sheets": "^1.3.1",
    "google-spreadsheet": "^3.1.15",
    "googleapis": "^39.2.0",
    "html-to-text": "^5.1.1",
    "http": "*",
    "https": "^1.0.0",
    "instagram-web-api": "^2.2.2",
    "jquery": "^3.6.0",
    "jsonfile": "^6.1.0",
    "lodash": "^4.17.21",
    "lusca": "^1.7.0",
    "moment": "^2.29.1",
    "moment-timezone": "^0.5.33",
    "mongoose": "^5.12.5",
    "morgan": "^1.10.0",
    "node-sass": "^4.14.1",
    "node-sass-middleware": "^0.11.0",
    "node-telegram-bot-api": "^0.50.0",
    "nodemailer": "^6.5.0",
    "nodemailer-sendgrid": "^1.0.3",
    "popper.js": "^1.16.1",
    "pug": "^3.0.2",
    "puppeteer": "^5.5.0",
    "puppeteer-core": "^5.5.0",
    "sanitize-html": "^2.4.0",
    "socket.io": "^4.1.2",
    "twitter-lite": "^0.14.0",
    "validator": "^13.6.0"

Thanks


Question - How do I set the server to use all available disk space? Install only allocated 100GB.

Closing, this belongs on the discussion board.


Removed AKS reference

It should be AKS Engine instead

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


slack receiver send_resolved unexpected results

What did you do?
Created a new route/receiver matching slack-no-resolves severity label
  - receiver: slack-no-resolves
    match:
      severity: slack-no-resolves
    continue: true

- name: slack-no-resolves
  slack_configs:
  - send_resolved: false
    http_config: {}
    api_url: <secret>
    channel: alerts
    username: alertmanager
    color: '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}'
    title: 'Alert: {{ .CommonAnnotations.summary -}}'
    title_link: <>
    pretext: '{{ template "slack.default.pretext" . }}'
    text: '{{ template "slack.text" . }}'
    footer: '{{ template "slack.default.footer" . }}'
    fallback: '{{ template "slack.default.fallback" . }}'
    icon_emoji: '{{ template "slack.default.iconemoji" . }}'
    icon_url: https://avatars.slack-edge.com/2017-04-22/172492516832_96357bf9662f2abf55ee_72.jpg

What did you expect to see?
No resolve notifications for alerts with slack-no-resolves severity label
What did you see instead? Under which circumstances?
Resolve notifications always received in Slack for alerts with slack-no-resolves severity label
Environment
Docker/k8s

System information:

Linux 4.4.86+ x86_64

Alertmanager version:

Version Information
Branch:
HEAD
BuildDate:
20181109-15:40:48
BuildUser:
root@4ecc17c53d26
GoVersion:
go1.11.2
Revision:
d4a7697cc90f8bce62efe7c44b63b542578ec0a1
Version:
0.15.3

Alertmanager configuration file:

global:
  resolve_timeout: 5m
  http_config: {}
  smtp_from: Alertmanager <>
  smtp_hello: localhost
  smtp_smarthost: <>
  smtp_auth_username: <>
  smtp_auth_password: <secret>
  smtp_require_tls: true
  slack_api_url: <secret>
  pagerduty_url: https://events.pagerduty.com/v2/enqueue
  hipchat_api_url: https://api.hipchat.com/
  opsgenie_api_url: https://api.opsgenie.com/
  wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/
  victorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/
route:
  receiver: slack
  group_by:
  - alertname
  routes:
  - receiver: slack
    match:
      severity: slack|email
    continue: true
  - receiver: slack-no-resolves
    match:
      severity: slack-no-resolves
    continue: true
  - receiver: email
    match_re:
      severity: ^(?:email)$
    continue: true
    repeat_interval: 1h
  group_wait: 10s
inhibit_rules:
- source_match:
    severity: critical
  target_match:
    severity: warning
  equal:
  - alertname
  - cluster
  - service
receivers:
- name: slack
  slack_configs:
  - send_resolved: true
    http_config: {}
    api_url: <secret>
    channel: alerts
    username: alertmanager
    color: '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}'
    title: 'Alert: {{ .CommonAnnotations.summary -}}'
    title_link: {{ .Receiver }}
    pretext: '{{ template "slack.default.pretext" . }}'
    text: '{{ template "slack.text" . }}'
    footer: '{{ template "slack.default.footer" . }}'
    fallback: '{{ template "slack.default.fallback" . }}'
    icon_emoji: '{{ template "slack.default.iconemoji" . }}'
    icon_url: https://avatars.slack-edge.com/2017-04-22/172492516832_96357bf9662f2abf55ee_72.jpg
- name: slack-no-resolves
  slack_configs:
  - send_resolved: false
    http_config: {}
    api_url: <secret>
    channel: alerts
    username: alertmanager
    color: '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}'
    title: 'Alert: {{ .CommonAnnotations.summary -}}'
    title_link: {{ .Receiver }}
    pretext: '{{ template "slack.default.pretext" . }}'
    text: '{{ template "slack.text" . }}'
    footer: '{{ template "slack.default.footer" . }}'
    fallback: '{{ template "slack.default.fallback" . }}'
    icon_emoji: '{{ template "slack.default.iconemoji" . }}'
    icon_url: https://avatars.slack-edge.com/2017-04-22/172492516832_96357bf9662f2abf55ee_72.jpg
- name: email
  email_configs:
  - send_resolved: false
    to: <>
    from: Alertmanager <>
    hello: localhost
    smarthost: <>
    auth_username: <>
    auth_password: <secret>
    headers:
      From: Alertmanager <>
      Subject: '{{- if .CommonLabels.test }} TEST{{ end }} Alert: {{ .CommonAnnotations.summary
        }}'
      To: <>
    html: '{{ template "email.text" . }}'
    require_tls: true
templates:
- /etc/alertmanager-templates/*.tmpl

I tried to reproduce with a similar configuration but didn't succeed. The routing-tree-editor doesn't show the problem either...

The routing tree editor is cool 👍
I explicitly set all receivers to be send_resolved: false yet every Slack alert always sends resolves. I think I'm going to try 0.16.1 and see if anything changes.

Upgrading to 0.16.1 resolved this issue, closing

Thanks for following up!


Remove scheduler service

We were discussing the need of scheduler service in Claudie.
Initialy it was created to manage which nodepools should increase/decrease in size based on for example: cloud costs.
At this stage this is handled by user and/or autoscaler node pools.
Scope of this task:

[ ] Update Claudie code and move the current scheduler workflow to other service - for example context-box/claudie-operator
[ ] Review backward compatibility
[ ] Update workflow documentation/diagrams

closed by https://github.com/berops/claudie/pull/1498


TypeScript Conversion for react-native-animated-numbers

Hey @heyman333
I wanted to express my gratitude for the fantastic work on react-native-animated-numbers. It's been incredibly useful. I've  converted the entire codebase into TypeScript.  I've fixed a major crash issue
I'd love to send a pull request to contribute this TypeScript version.
Thanks again!

@0xVikasRushi Thanks! please feel free to send pull request. This is opensource and openworld : )

Hey @heyman333
I wanted to express my gratitude for the fantastic work on react-native-animated-numbers. It's been incredibly useful. I've converted the entire codebase into TypeScript. I've fixed a major crash issue
I'd love to send a pull request to contribute this TypeScript version.
Thanks again!

Hello friend, May you create a repo or pull your typescript version?


Please support XFS for iSCSI docker volumes

I see in the code some of the groundwork to support XFS for the filesystem backing the iscsi docker volumes. This would be a nice addition as XFS allows for growing, which would also be a nice feature to add to the netappdvp plugin.
Sometimes you just want to grow a volume without wiping out what is already there.

Tracked internally as US2343

@ragesaq and I tried to change the util.FormatVolume filesystem parameter to "xfs" instead of "ext4", but the filesystems errored. I will post the error here.
--- a/storage_drivers/ontap_san.go
+++ b/storage_drivers/ontap_san.go
@@ -397,7 +397,7 @@ func (d *OntapSANStorageDriver) Attach(name, mountpoint string, opts map[string]
                // put a filesystem on it if there isn't one already there
                if e.Filesystem == "" {
                        // format it
-                       err := utils.FormatVolume(deviceToUse, "ext4") // TODO externalize fsType
+                       err := utils.FormatVolume(deviceToUse, "xfs") // TODO externalize fsType
                        if err != nil {
                                return fmt.Errorf("Problem formatting lun: %v device: %v error: %v", name, deviceToUse, err)
                        }


yr sensor

Home Assistant release (hass --version):
Latest from dev
Component/platform:
yr sensor
Description of problem:
No longer updated as often as it should.
Introduced by pr:  https://github.com/home-assistant/home-assistant/pull/4158

Add https://raw.githubusercontent.com/home-assistant/home-assistant/be272ac64a691f04bbd8ea92d7914521cc59508e/homeassistant/components/sensor/yr.py
to .homeassistant/custom_components/sensor/yr.py for a temporary solution


Could you please share example of code on how to use trained models for the text classification?

Hi there,
Good job for what you have done here. I would like to use trained models using one of your classifiers (for example, gpt-2 or LX-net) on a new input.  Do you have code that will help me use the trained models for inference?
Thanks in advance.

You can read from here, https://www.tensorflow.org/guide/saved_model
I will add later based on that documentation, but quite late.


[1.11] Bump Mesos to nightly 1.5.x 3ce0e64

High-level description
This is a routine bump to the latest Mesos and mesos-modules.
Related JIRA Issues
Checklist for all PRs

[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[x] Read the DC/OS contributing guidelines
[x] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[x] Changelog:
https://github.com/apache/mesos/compare/74a6f3cdb8206b41f96e1ebf5981783ea999c250...3ce0e64ba1d357c0894820f1ced9d51fa68484a7
https://github.com/dcos/dcos-mesos-modules/compare/95c2d1dd95bd848d15c687fb8b31b6ba52e1ac25...2ad4a4156614ca6dd096b23fbebaf3a915836f0d

[ ] Test Results: [link to CI job test results for component]

[ ] Code Coverage (if available): [link to code coverage report]

@mesosphere-mergebot label Ready For Review

@mesosphere-mergebot label Ready For Review


g1nc/Fortran/RDGEN1.for

Compile gives error: undefined reference to gbytes, sbytes, length, and skfile.
gbytes/sbytes libraries are online at http://rda.ucar.edu/libraries/gbytes/

Fixed by commit 51d4d69c.


Draw.io 9.3.1(Desktop, OSX, older Mac) crashed

Hi,
I tried to run draw.io, but it constantly crashes when/before opening. See below for the messages that are logged. It does show noting; no window, no banner, nothing (but the log below)
I used: draw.io-9.3.1.dmg, on a older mac: MacBook Pro (15-inch, Late 2008); OSX 10.11.6 (El Capitan)
This is kind of a show-stopper ...
Hope this reports helps to make a fix, or suggest a workaround
Thanks
Log:

05/11/18 11:54:30,849 draw.io Helper[54077]: <<<< VTVideoEncoderSelection >>>> VTSelectAndCreateVideoEncoderInstanceInternal: no video encoder found for 'avc1'
05/11/18 11:54:30,850 draw.io Helper[54077]: [11:54:30.849] VTSelectAndCreateVideoEncoderInstanceInternal signalled err=-12908 (err) (Video encoder not available) at /Library/Caches/com.apple.xbs/Sources/CoreMedia_frameworks/CoreMedia-1731.15.207/Sources/VideoToolbox/VTVideoEncoderSelection.c line 1308

f you are having trouble starting the application from the launcher in macOS after installation, try starting it from the Application folder the first time (it should then open from the launcher as well). See https://desk.draw.io/support/solutions/articles/16000083313


removeChildren error

There is an error in the removeChildren function.
https://github.com/photonstorm/phaser/blob/v2.6.2/src/pixi/display/DisplayObjectContainer.js#L229
var removed = this.children.splice(begin, range);
begin is undefined
I believe that the correct should be:
var removed = this.children.splice(beginIndex, range);

I can confirm this, changing begin to beginIndex fixes issue. There is no variable named begin in removeChildren function.

This was fixed in Phaser CE several months ago. Please upgrade to that version, or fork and patch locally, as there will be no more changes to Phaser v2 I'm afraid.


[Task]: Fix performance degradation for Flink with side inputs

What needs to happen?
When streaming job executed on FlinkRunner started to use side-inputs, we noticed big performance impact on throughput. This is observed on v2.33.0. Example of hot stack trace:  hot-stack.txt
Issue Priority
Priority: 2
Issue Component
Component: runner-flink

I plan to submit an MR with pipeline options serialisation problem.


how do you run the tests locally?

I'd like to open a pull request for something, but I can't figure out how to run the tests. Can you please advise @vitalets. Thank you.

@mitcht, could you take a look?

I'll spend some time today at 12 EST looking at how this works.  Seems like grunt docs might generate a file 'dev.html' with a test item in the left menu. However, there is an injector error.
 Unknown provider: editableIconsProvider <- editableIcons
I will probably be able to fix it.
@lalitkapoor See if you can replicate this.

opening test/e2e/dev-test.html in browser is not work?

I had to host it on an actual server before it would run...

ok, it seems not to be a problem.
I my current projects I use this:
npm i http-server -g
http-server test/e2e

it starts start static web server in specified directory.

@vitalets I tried that in the past.  It would be great if you investigate and find error..

@vitalets do you mind trying to find the error? I'm not as familiar as you are with the code base.
We should add a CI maybe so that the chances of failing releases is reduced.

The bower packages are out of date first of all. The newer versions don't quite work right. You might look down that road.

The tests have all been fixed in pull-request #443


ci: deploy dev docs to netlify

This PR adds instructions that tells Netlify how to build our documentation for the purposes of previewing it.

Codecov Report

Merging #1271 (f6fbe1a) into main (1a2e924) will decrease coverage by 0.01%.
The diff coverage is n/a.

:exclamation: Current head f6fbe1a differs from pull request most recent head 74c3e23. Consider uploading reports for the commit 74c3e23 to get more accurate results

@@            Coverage Diff             @@
##             main    #1271      +/-   ##
==========================================
- Coverage   31.06%   31.05%   -0.02%
==========================================
  Files         359      359
  Lines       14231    14231
==========================================
- Hits         4421     4419       -2
- Misses       9810     9812       +2

Impacted Files
Coverage Δ

model/src/application/callback/mod.rs
52.38% <0.00%> (-1.59%)
:arrow_down:

http/src/routing/route.rs
6.30% <0.00%> (-0.32%)
:arrow_down:

http/src/routing/route_display.rs
9.98% <0.00%> (ø)

Continue to review full report at Codecov.

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

I'd like to hear some feedback on if y'all would benefit from this feature. It will eventually cost money as the free tier only has 300 build minutes and each commit to a PR uses 4 build minutes. We can look into a way to build the docs on Github Actions and upload them to Netlify, or there might be a better service for this out there.

I don't see it as a big need, it may be nice to have on a few prs that makes major changes to the documentation, but most prs does not really need it.

I agree, but I'd like to use this for selected PRs. Couldn't we make a bot that triggers a netlify build when mentioned or when a tag gets added to a PR? Something like: preview-docs tag gets added -> netlify build -> link comment?

I agree, but I'd like to use this for selected PRs. Couldn't we make a bot that triggers a netlify build when mentioned or when a tag gets added to a PR? Something like: preview-docs tag gets added -> netlify build -> link comment?

I like this idea. I'll see what it entails.

Closing this for now since there are better solutions.


Log successful and failed login attempts

Do you have updates on this topic?

This feature will be part of Lychee 3.1.


revert: "fix(executor): Fix compatibility issue with k8s>=1.21 when s…

…elfLink is no longer populated (#5992)"
This reverts commit d7c5cf6c95056a82ea94e37da925ed566991e548.
Signed-off-by: Alex Collins<EMAIL_ADDRESS>

@alexec The build fails here for the same reason that we are using image from docker hub, right?

It'll fail the first time it runs on master, but should pass second time.


Support Unix sockets

This adds handling for unix:// URLs.

Trying to remember why I didn't keep them 🤔

Part of the answer: https://github.com/redis-rb/redis-client/issues/22#issuecomment-1124910725


support new JSON response mode for Gemini 1.5 Pro

Fixes #18
This allows doing
$client
    ->generativeModel('models/gemini-1.5-pro-latest')
    ->withGenerationConfig(new GenerationConfig(responseMimeType: 'application/json'))

and the response will be JSON then.

Hello,
First of all, thank you for your feedback. This feature is currently in beta. Including it in the package might be a problem at the moment.
https://github.com/google-gemini-php/client/issues/14

Yeah I see. Maybe allowing GenerationConfig|Arrayable might be a solution? being constrained for the allowed config by this lib seems not so ideal. Whenever new config options are available this would require an update/release as we see with this issue.

The package is currently not sending requests to the beta api. Therefore the stable api will not recognize this feature. I plan to create a separate branch for this and other beta features, so that those who want to use beta features can access them through this branch.
https://github.com/google-gemini-php/client/blob/06536196184cb6b29f096e29705a175b7b7350af/src/Factory.php#L33

Yes, this is possible, but anyone using the package will need to be aware that this parameter only works in beta. As I said, I'm planning to open a separate branch for the beta to add these features, I'll let you know when that's done.

Hello @aydinfatih do you have any update regarding the beta branch? Thanks

Hi @aydinfatih maybe instead of separate branch BetaGenerationConfig could be provided ?

I also think that the decision to exclude beta APIs is like putting the package on the shelf. Most generative AI providers release or mark their first revisions as beta or preview versions. Since this is a relatively new area, most users are really looking to use the latest versions.

Hi @dmaicher @beliven-daniele-sarnari @avengerweb @pionl
This feature has been added to the beta version. You can use it by updating the version of the package in composer.json to the version I specified.
https://packagist.org/packages/google-gemini-php/client#1.0.0-beta
You can check the PR
https://github.com/google-gemini-php/client/pull/34


CMS-451: Build EditAndReview table components

Jira Ticket
CMS-451
Description

This branch hooks up the /parks API route (and adds a custom useApi hook to query it).
It replaces the hardcoded Bootstrap table with a react component that displays the data and links to the "park details page" route.
It adds an environment variable to the frontend for VITE_API_BASE_URL so you'll need to update your local .env - see .env.example or grab the new one from 1Password

Forgot we also need to sort the table by the park name :\ The rest is still ready to look at, though

What do you think of a pattern like this. It kind of looks cleaner and it's pretty popular in React. Especially when you have a hook for fetching data like the one you added here.
const MyComponent = () => {
  const [data, loading, error] = useFetchAPI('api/parks');

  if (loading) {
    return
Loading...
;
  }

  if (error) {
    return
Error: {error.message}
;
  }

  return (

      {data.map((item) => (

{item.name}

      ))}

  );
};

I definitely prefer that early return pattern to putting big indents and "&&" in the template. I'll clean it up a bit and push that with some other cosmetic updates I discussed with Amanda today 👍

I forgot about useMemo 😊 I'm used to computed properties all being memoized automatically 😄  We can tackle that in a quick ticket later on once we get all the pages working together


Contribution guide

This PR adds a contribution guide that outlines and explains strict guidelines on how to properly contribute to Tamagui.

I think we want to update the main readme then right? It sort of duplicates some of this content. Probably want to make sure quick start npm create tamagui@latest is called out there and then links to contributing and other relevant areas.


API and Implementation Improvements

Primarily removes unnecessary use of dynamic dispatch, interior mutability, and async functions. As a result some public APIs have changed, generally making them more Rusty.

Will address requested changes and the CI failure later today.
My bandwidth is a little limited at the moment, so while I'll likely make some sibling PRs to other repos, I can't guarantee how soon/if that will happen. I made this PR since I needed this crate in a project I'm working on and wanted to see these changes rendered if possible.

My bandwidth is a little limited at the moment, so while I'll likely make some sibling PRs to other repos, I can't guarantee how soon/if that will happen. I made this PR since I needed this crate in a project I'm working on and wanted to see these changes rendered if possible.

The thing is this project is directly consumed in the other webrtc-rs projects and as such merging it will require work in all upstream projects. I'm likewise strapped for bandwidth and won't have time to upstream these breaking changes.
I'd be reluctant to merge this until we at least know the scope of the upstream changes required and whether the changes would be problematic to integrate in those projects.

I'd be reluctant to merge this until we at least know the scope of the upstream changes required and whether the changes would be problematic to integrate in those projects.

Actually, thinking about this. This is still an improvement even if you or I don't have time to upstream the changes atm.

https://github.com/webrtc-rs/rtp/pull/27/commits/8b4116b7414b3edb68a59f9d38156d8d7a9b79a3 should resolve all the feedback above. Let me know if you have any more questions/concerns.

Actually, thinking about this. This is still an improvement even if you or I don't have time to upstream the changes atm.

It's also worth bearing in mind that it's unlikely that an individual or group of individuals would have the spare time to synchronously rework the API of this whole ecosystem niche, so most changes will probably have to be done incrementally :)

So uh I'll fix the cargo format issue but not sure what to do about the fact that we hit an ICE in CI job

We have migrated this crate to the monorepo(webrtc-rs/webrtc) please re-open this pull request over there.


Create side-quest for learning jQuery

We want to create an activity for mentees to get a feel of how jQuery works in this part of the curriculum.
Mentees are expected to have learned how to construct basic Javascript functions and are familiar with the DOM.

Just my $0..02....  Why would anyone bother learning jQuery these days?
(I understand that work on some existing project might require it, but with that criteria, we would need to cover a LOT of fading technology).  (And it's probably generous to call jQuery "fading" at this time.


velocity projection between s-domain and joint domain

with the current implementation of s-variable, there are some issues when it comes to the non-zero velocity at waypoint:

all the joints are linear functions in the s-variable (e.g. q_i(s)=m_i * s+ c_i  for any joint i), so q`(s) for each joint has its own value which is m_i, and q_dot for each joint is (q_dot(s) = q`(s) * s_dot = m_i * s_dot). the current function to project q_dot on s-domain project_limits_onto_s calculates s_dot for each joint and then takes the min s_dot as the dominant one, and as a consequence:
as the s_dot is the minimum value ( in our case), all the joint velocities will be related to each other with ratio (m_i/m_j) e.g m_j is the joint with minimum s_dot and m_i any other joint.

Example with numbers [ when we convert joint velocity to s-domain]:

linear functions of s-variable are q(s)=[0.6s, 0.8s],   starting joint velocity= [0.0, 0.1] ==> [0.0, 0.125] in s-domain , as 0.0 is the dominant s_dot, then both joints start with joint velocity equal to (m_is_dot) = 0.0.  ending joint velocity=[0.3, 0.4] ==> [.33, .625] in s-domain,  as 0.33 is the dominant s_dot. then the ending joint velocity  equal to (m_is_dot) = [0.19, .26]. as q`(s) is constant (m_i for i joint) then all the velocities are related to each other.

I was wondering why the topp-ra method does not have the same issues, I found that they using s-variable in such a way that q(s) is a cubicspline  [q(s)= as^3 + bs^2 + cs + d] , so [q`(s) =  3as^2 + 2bs + c], which mean that with the same rule (q_dot(s) = q`(s) * s_dot ),  a single value of s_dot combined with the three variables (a, b, c) can result in non-related velocities in joint-domain.  they are using piecewise cubic functions instead of piecewise linear functions.

the second issue: when calculating s_dot ( instead of converting joint velocities to s-domani and choose minimum between of them ), the velocity in s-domain (s_dot) will be continuous but when it is converted to the joint domain it won't be continuous anymore as each segment have its own function (or its own slope m_i)

the third issue:  if any joint velocity becomes zero (change direction), then s_dot for that joint will be zero, and as we take minimum s-dot, then all the other joints will have zero velocity as well.

Thanks for the detailed explanation! If I understand correctly the 3 points are:

The joints velocities are all related to each other by some constant ratio at each segment in the path. I'm not sure why this is a problem - in fact it must be true or else the arm would be leaving the chosen path, which could result in collisions.

There are discontinuities where linear segments meet - this also is always going to be true for piecewise linear paths. Any S-parameterization of the path will have the same problem; fundamentally it is impossible for the robot to change direction in joint space instantly without having infinite instantaneous acceleration and jerk. The solution is that we must create smooth blends in the path before doing time parameterization - that's what I'm working on now.

I don't think this will be a problem after we add blending to smooth transitions between segments. The joint whose velocity passes through zero will have dj/ds = 0 for the point where it changes direction. So ds/dt can still be nonzero while keeping dj/dt for that joint equal to zero.

yes, you got the three points I want to discuss. I agree that the joints' velocities will be related to each other for each segment. but as you mentioned that "There are discontinuities where linear segments meet - this also is always going to be true for piecewise linear paths", I think this discontinuity can be removed if the joints are represented by a higher-order polynomial of S.

If the higher level polynomial follows the same geometric path as the piecewise linear path, then the only way it would avoid velocity discontinuities would be to have dj/ds = 0 for all joints  at the points where the arm changes directions. That would mean no matter how you did the time parameterization ( ds/dt ), all joints will stop at every waypoint - so we'd be just as well off keeping the piecewise linear function of s for the joints, and using a time parameterization that stops the robot at every waypoint.
I'm pretty convinced that moving with the joints with non-zero velocity through the waypoints will require geometric change to the path, not just a change in the form of the parameterization.

update after blending:
A. Before:

As the main source of velocity discontinuity which happened between any two adjacent segments is that we are using linear (1st order) piecewise s-variable [ where qi(s)=mi * s+ ci for each joint i] ... check the following fig. for a two-segment path/trajectory:

Explanation: consider  "dqsj" is the velocity of segment s and joint j
for any value of s_dot at the end of the first segment, we have two values for joint velocities according to the relation [ dq1=m1s_dot]  and [ dq2=m2s_dot] lets called them dq11 and dq12.
the same way the begging of the second segment, for any value of s_dot we have dq21 and dq22.
as m1m2 during the second segment, there is no way to have dq11=dq21 and dq12=dq22 except of setting s_dot=0, which mean dq11=dq12=dq21=dq22=0, which stop at each waypoint.

Note: the acceleration looks continuous because we fit each segment separately using the fit_seven_segment function and we always start and end with zero acceleration. and for each segment, we start and end with one velocity in s-domain which generates discontinuous velocity in joint domain [ dqi=mi*s_dot for each joint i].

B. After:

by adding a blending segment (with a higher order of s or based on sinusoidal function), we have [dqi = qi'(s)*s_dot  for each joint i ]. as qi'(s) is not linear anymore and it has more degree of freedom, it servers as a transition between the velocities of the two segments, where the blending segment starts with (q11, q12) and ends with (q21, q22) which keeps the velocity of the two joints continuous, check the following figures path/trajectory for same waypoints:

I was trying to transfer the original segment to be represented with a higher order of s-polynomial but it did not work.

as Jon suggested we can search for another method for calculating the motion profile for the blending segment which grantee the limits along the curvature.

@jonbinney
we might need to change the project_limits_onto_s, this function takes only the first derivative of q(s) into account which is true for the original segments (as 2nd and 3rd derivative are zeros because it is linear in s), but it is not true for the blending segment. .... as the blending 2nd and 3rd dervative are not zeros, look at the following equations from paper:

we were using equation number (2) to project velocity, acceleration, and jerk limits which is not right in the blending segment case

Yes, @mahmoud-a-ali you're right. project_limits_onto_s assumes a linear segment path.  If we want to  compute constant jerk/acceleration/velocity limits for the blending section, we'll have to take use the equations you listed and take the minimum (the limits are different at each point in the blending section).

Hmm... this is slightly trickier than i thought.  The use the chain rule to get the jerk depending on q(s) and s(t):

In the rest of this comment, I'm going to use the following nomenclature so that i can write in plain text:
sd means ,
sdd means
sdd means
Looking at these, it becomes clear that the constraints on sd, sdd, and sdd are not independent - meaning that the constraint on sdd depends on choice velocity and jerk, the constraint on sddd depends on the acceleration and velocity chosen, etc.
Put another way, if you plotted the region of valid values for sd, sdd, and sddd on the axes sd, sdd and sddd, that region would not be an axis-aligned rectangular prism. So we can't just return upper and lower limits on sd, sdd, and sddd for curved parts of the path - we have to return something more complicated. In the paper, they use the following representation for the jerk constraint:

where:

For their SCO approach, that is fine as long as the can use tricks to decompose the constraints into a set of convex constraints. For the kinds of approaches we've been pursuing this is more complex. My original thought was that we could require sd to be constant within the blending regions. This greatly simplifies the limits - you know that sdd and sddd are zero, so the upper and lower limits on sd only depend on s (where you are in the blended region). My hunch is that for a blend region that has constant curvature in joint space, the limits on sd will actually be constant across the entire blend region (the limit on sd only depends on the curvature). I still need to think through this though.

@mahmoud-a-ali @gavanderhoorn what do you think about me moving this repository to gitlab so that we can use latex math in issues, pull requests, and readme files? https://docs.gitlab.com/ee/user/markdown.html#math

Update: I tried out gitlab's markdown, and while it is almost exactly what we need, it is missing a couple of key features. Specifically, it doesn't have \dddot to denote the third derivative. I was able to create a def for it:
\def\dddot#1{#1^{\mathclap{\dotsb}}}
\dot{s} + \ddot{s} + \dddot{s}

But since each math block has its own scope, we would have to copy and paste that first line into every one. Overall I think it isn't worth the move. I'll look into latex to image renderers that we can use to create math images we can copy to github issues as a workaround.

What about using d''' notation?

The TOPPRA authors use apostraphes to indicate the derivative with respect to s - so they have equations with a mix of dots and apostraphes:

I'd suggest that in plain text we use d for dot so we could write the above equation as
qddd = q'''sddd^3 + 3q''sddsd + q'*sddd


Name constructors to reflect the object name.

See #791

This will be nice. One thought though, do we just want to name the function the same as the name of the "class"?  This would create something that looks more like what coffee script generates when doing classes.

Note: Discussion on this is happening in #791.

I like the idea of naming constructors to reflect the class name. I hate that JS doesn't help us with this, but I think keeping the word "constructor" somewhere in the inner function would be the closest analog of a C++/Java setup since that's where we initialize our variables:
var Name = (function NameClass() {
  function constructorName(name) {
    this.name = name;
  }

  constructorName.prototype = {
  };
  ...

  return constructorName;
})();

I think this is more in line with how we've been using our classes. What do y'all think?

@arturadib, have you seen my comment in #791, https://github.com/mozilla/pdf.js/issues/791#issuecomment-2721247?
Basically, I'd like to keep the name as short as possible as this is what shows up in the debugger as well and having shorter names is useful there (escp. as the name you propose starts with always the same "constructor", such that the real name of the object might get truncated at the end if there is not enough space left).

I'd like to keep the name as short as possible

That's a fine goal, but naming the self-executing function "constructor":
var RefSet = (function RefSetConstructor() {

is confusing since it clashes with the inner constructor function, which in my opinion is the closest analog to constructors in class languages.
As a first-time contributor I enjoyed how the function name "constructor" was self-explanatory.
(Also, we have already been using huge names for anonymous functions...)

@jviereck I'm actually thinking leaving constructor as it is is OK (and preferred since it helps new contributors). In Firebug we can resolve name ambiguities by clicking on the function name in the Profiler or checking out the Stack. Can't you do that with Chrome?

C++ and Java don't have constructor's named "constructor"

C++ and Java have been designed to support constructors and destructors with a very specific syntax; there's no ambiguity there.
I just want to point out the tradeoff - easier debugging for some (I never had an issue with this as I use Firebug's stack and/or click-to-see feature), versus less clear class structure for newcomers. I'll let you guys take it from here.

I'd like to name those anonymous functions. AnimalClosure sounds good to me.
I don't have a strong opinion about the constructor function name. Animal, AnimalCtor, AnimalConstructor are imo ok.
I can do some refactoring/renaming after the naming convention settled.

This actually doesn't fix my main debugging gripe, in firefox everything still shows up as "Object", on Chrome it makes it better though.  Seems firebug only gets the name right if you do the more typical style of
function Animal(name) {
  this.name = name;
}
Animal.prototype.speak = function() {};

I suppose an issue should be raised for firebug on that (unless there already is). If the function would be anonymous then backtracing and profiling would be a bit worse. I'd keep the names.

function Animal(name) {
  this.name = name;
}
Animal.prototype.speak = function() {};

Should we just remove the closure-wrapping for declarations, that don't need it? I think that should be the case for most of our "class" declarations.

I like the idea!

I like the style above, but I prefer consistency over anything.  I really don't want to have two styles.

@arturadib, @notmasteryet, can you please jump in and leave a comment what you think? We're quite stuck here :/

can you please jump in and leave a comment what you think? We're quite stuck here

I agree with Brendan -- we have to be consistent throughout the code.
The latest style is fine by me, but we either change the whole thing or leave it as it is.

Most people like going the new function style
function Animal(name) {
  this.name = name;
}
Animal.prototype.speak = function() {};

but if we use it, it should be used everywhere.
Are there places in the code, where doing this change isn't possible?

Are there places in the code, where doing this change isn't possible?

I think this will require a much greater effort. @kkujala if you have the patience and courage to do this across our files and check that it doesn't break things, please go ahead and open a new PR when you're done. Thanks!
For now I'm closing this PR.

That new style would require us to get rid of any of the "private static" functions and variables.  Off the top of my head I can think of quite a few places that new style will require a good deal of refactoring if we decide to go with that.  We should really decide if the new style is worth the effort before anyone invests any time refactoring.

@kkujala We like the style in this Pull Request, which keeps the self-executing wrappers.
If you decide to go ahead with the new PR, can you please apply this style to all files besides obj.js? Thanks!

@arturadib, ok, I can make a new PR. Are you sure you want to have a one huge patch? I think it would be easier to gradually make the changes file by file.

@kkujala, don't bother about a big patch. It should be quite simple, as you just do renaming of some strings and should be easy to check. Is that good for you?


[Swift+WASM] Add an ABI hook for whether swiftcc is supported.

This adds an extension point so the ABI can declare whether or not it supports the swift calling convention. Open to suggestions if you think this doesn't belong here (or is flat out the wrong thing to try and to do bring up wasm).

[ ] Depends on #235.

I feel like @rjmccall is in a better position to review this.

I've resisted doing this on other targets because:

it's basically trivial to support the CC on a target by just using the standard rules for your platform (or, in this case, ignore it when preparing wasm output);
it's not at all unreasonable to think that a backend might want to give special treatment to swifterror and swiftself, and doing so is much easier if they only appear in conjunction with swiftcc; and
it's much easier to write portable tests for frontend IR output if as much as possible is consistent across targets.

@rjmccall that makes a lot of sense, thanks. Will investigate that angle instead.


Pub/Sub API

Integration with gcloud pub/sub service!

Is that different than #18 ?

Closing this one in favor of #18 please use that one for adding any more information regarding Pub/Sub integration.

Awesome thanks


How not to compute a metric at each call of the update?

I couldn't find it in the documentation (although I've seen it already) where it's specified how to compute a metric only when the compute method is called (and not every call of the update method).

Hi @celsofranssa,
I am not sure I understand the question. If you just call update the metric will not call compute. If you call forward then it is correct that the metric calls both update and compute.

Hi @celsofranssa, I am not sure I understand the question. If you just call update the metric will not call compute. If you call forward then it is correct that the metric calls both update and compute.

That was the reason. Then I have to call only compute.

You were probably looking for the compute_on_step argument which where deprecated in v0.8 (https://github.com/Lightning-AI/metrics/pull/792) and removed in v0.9. Setting this argument to False meant that forward would just call update and not also compute.
Closing the issue.

You were probably looking for the compute_on_step argument which where deprecated in v0.8 (#792) and removed in v0.9. Setting this argument to False meant that forward would just call update and not also compute. Closing the issue.

Exactly.


naming/organization for variants on light, depth, schmidt, etc. functions

LakeMetabolizer uses k.cole, k.read, k.vachon, etc. to distinguish among available functions for estimating k. Did that work well, and should we plan to do it again (though probably with underscores, e.g., calc_light_methodA, calc_light_methodB)? Any lessons learned that we can apply here? @lawinslow @jread-usgs

i think we're good


Archive this repo

This repo is evidently unmaintained. Please archive the repo so people know not to use it on projects.

yes is better. any alternative?

yes is better. any alternative?

I switched to inversify

@chriskuech @alfiadoDev Sadly it is a sad state of affairs for many TypeScript DI libraries. Inversify maintenance is not much better, if you see their GitHub repo, without counting a small release v6.03 made just yesterday, the previous one v6.01 was done 3 years ago. On top of that, there are some very concerning issues related to the future of the project (See here and here). Archiving tsyringe I think is strong measure for a project with 5K stars on GitHub and 350K NPM downloads weekly. Before that, in my opinion it would be better to try searching for new maintainers among contributors or anyone else willing to help. And this is something Inversify is doing. If you go to their issues page, the first thing you see is the Maintainers wanted issue pinned on the top.

hey guys, inversify has a new group of working members now, things will shift in a good direction. I will keep the pinned issue pinned so that other people who wants to join can do so.

@PodaruDragos Very glad to hear such a reassurance from someone actively working on it 👍

yes is better. any alternative?

Hey everyone, I have been working on a library called di-wise. Welcome to try it out.

I worked on a project called Needle DI. It does not depend on reflection metadata and features tree-shakeable injections tokens. Feel free to share any feedback.


changed internalvalue const to method calls

PR Checklist:

[x] I have tested this extensively and it does not break any existing behavior.
[ ] I have added/updated examples and tests for any new behavior.
[ ] If this is a significant change, an issue has already been created where the problem / solution was discussed: [N/A, or add link to issue here]

PR Description

Right now, if you add some dataset to a chart, and then you clear the chart and insert some data again, you will get this error when highlting an entry:
TypeError: Cannot read property 'x' of undefined
at LineDataSet.BaseDataSet.getEntryXValue (file: node_modules/@nativescript-community/ui-chart/data/BaseDataSet.js:37:0)
at ChartHighlighter.buildHighlights (file: node_modules/@nativescript-community/ui-chart/highlight/ChartHighlighter.js:65:0)
at ChartHighlighter.getHighlightsAtXValue (file: node_modules/@nativescript-community/ui-chart/highlight/ChartHighlighter.js:54:0)
at ChartHighlighter.getHighlightForX (file: node_modules/@nativescript-community/ui-chart/highlight/ChartHighlighter.js:19:0)
at ChartHighlighter.getHighlight (file: node_modules/@nativescript-community/ui-chart/highlight/ChartHighlighter.js:11:0)
at GlucoseChart.getHighlightByTouchPoint (file: node_modules/@nativescript-community/ui-chart/charts/Chart.js:210:0)
at BarLineChartTouchListener.onTapGesture (file: node_modules/@nativescript-community/ui-chart/listener/BarLineChartTouchListener.js:407:0)
at Function._handleEvent (file: node_modules/@nativescript/core/data/observable/index.js:230:0)
at Handler.notify (file: node_modules/@nativescript/core/data/observable/index.js:216:0)
at HandlerDelegate.gestureHandlerDidChangeStatePrevStateExtraDataView (file: node_modules/@nativescript-community/gesturehandler/gesturehandler.ios.js:107:0)
This is happening because the getEntryForIndex method is returning an undefined entry. Looking through the code I found out that the getEntryForIndex method gets updated:
updateGetEntryForIndex() {
        const internalValues = this.getInternalValues();
        if (internalValues instanceof ObservableArray) {
            this.getEntryForIndex = function (index) {
                return internalValues.getItem(index);
            };
        }
        else {
            this.getEntryForIndex = function (index) {
                return internalValues[index];
            };
        }
}

but the internalValues is declared on the updateGetEntryForIndex method, not on the getEntryForIndex update, this is causing internalValues to stay empty and thus returning undefined when trying to get the entry. Fixed by simply making the call inside the updated methods instead.
What does this add/ remove/ fix/ change?
removes a const to add 2 method calls.
WHY should this PR be merged into the main library?
Solves a possible crash.

I see the issue but i would prefer for updateGetEntryForIndex to be updated when mValues gets changed.
The reason is that getEntryForIndex is the most critical function in the whole library and thus it has to be as fast as possible. You can clearly see on 10000 entries datasets. And thus makig the calls inside getEntryForIndex makes a real difference.

@farfromrefug Thank you for the input! updated the PR

@DiegoMacBD thanks for this PR!

@DiegoMacBD released in 1.2.12


"if" keyword removed from pg_search_scope

I have a rails app that I recently updated to rails 5, and I've updated pg_search in the process.
However, now I receive this error:
*** ArgumentError Exception: Unknown key: :if. Valid keys are: :against, :ranked_by, :ignoring, :using, :query, :associated_against, :order_within_rank

This is the corresponding code in the model:
pg_search_scope :search, against: [:applicant_first, :applicant_last, :address],
    using: {
      tsearch: {prefix: true}
    }, :if => lambda {|import| !(import.archived?) }

If the if keyword was removed, is there an alternative? It seems to still work with the multisearchable functionality, interestingly.

if was never available for pg_search_scope.
You ought to make another scope that only returns non-archived records and then chain it:
class MyClass
  pg_search_scope :search, against: [:applicant_first, :applicant_last, :address],
    using: {
      tsearch: {prefix: true}
    }
  scope :not_archived, where(archived: false)
end

MyClass.search("some query").not_archived

The reason that if was added to multisearchable is so that not every record would generate a corresponding entry in the global PgSearch::Document's table.

Huh. I'll have to figure out what happened, then - and how that code got
into production. Thanks.
On Sat, Sep 24, 2016, 4:23 PM Grant Hutchins<EMAIL_ADDRESS>wrote:

Closed #326 https://github.com/Casecommons/pg_search/issues/326.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Casecommons/pg_search/issues/326#event-801349691, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADISY-ecU2K7rkl9B9dCkhiTvLba0EmLks5qtYamgaJpZM4KFX9M
.


Support to operate on a table cell with a certain row and column header pattern.

Problem
In com.ibm.itest.cloud.common.pages.elements.TableElement, locating a table cell can be done with its row and column indices. New methods may need to locate the table cell by its row index and column header pattern.
Potential solution
First, get the column index by the matching column header pattern. Then, locate the cell with the row and column indices.

The code is reviewed and merged. Close it.


Update validator.shacl.ttl

xone to or for source/provenance etc - no reason cant use multiple options here

closing PR as we've superseded this and allowed multiple provenances


copying memento from demos to u2

Also modify the current demo so that it still works when using the new standard U2 version.


Bump flutter_lints to 4.0

Follow-up to https://github.com/flutter/packages/pull/6695.

Now that flutter_lints 4.0 is live I am kicking the tests here. Will submit when everything is green.


[@nativescript/firebase-messaging-core][android] Error when trying to register device

With the latest changes (3.2.3), I'm getting an error when trying to register device and get token on Android. The same code has been working fine with version 3.2.0. The error is:
Error: java.lang.NullPointerException: Parameter specified as non-null is null: method kotlin.jvm.internal.Intrinsics.checkNotNullParameter, parameter messaging

From what I was able to troubleshoot it is because of this code that delays loading until first usage:
https://github.com/NativeScript/firebase/blob/0636cd44f691ab9100df63b7f7b39dcfb542c2ef/packages/firebase-messaging-core/index.android.ts#L207-L213
Which was changed in the bump deps commit:
https://github.com/NativeScript/firebase/commit/0636cd44f691ab9100df63b7f7b39dcfb542c2ef#diff-f74cba432ab62cdf5bdf373d3c4c8f3d63dcb1fd4cdcddd473144d2b3c981f80
Seems that this delay load does not work as expected and on all places in the plugin either this._native should be replaced with this.native so that it inits correctly, for example here:
https://github.com/NativeScript/firebase/blob/0636cd44f691ab9100df63b7f7b39dcfb542c2ef/packages/firebase-messaging-core/index.android.ts#L218-L225
Or the previous init in the constructor should be returned. No idea why it was delay loaded in the first place...

In the newer google services there was an issue when calling the getInstance early would crash so the delay was added, yes you're correct those ._native should be the using the.native

@triniwiz do we know if we have a fix for this yet?

Has this issue with using ._native instead of .native been patched?


How can i use other datasets like non-git ones?

How about you elaborate ?

Closed because no info provided. Feel free to reopen.


replace not working Fatal error by plain error return

What does this PR change?
Calling Fatal().Err() is not enough without .Msg(), but instead just return error.
This also enables term and exec logging with trace log level.
Test coverage

No tests: add explanation

[X] DONE

Links
Issue(s): https://github.com/SUSE/spacewalk/issues/23774

[X] DONE

Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:

[ ] No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)
Before you merge
Check How to branch and merge properly!

Thanks a lot Ondrej.


offline_sev_kbc: fix compatabiliy with sample kbs

Annotation format got out of sync between offline_sev_kbc and offline_fs_kbs. We have previously discussed more effective code sharing between these two and maybe now is the time to implement. I am posting this simple fixup to document components needed for SEV demo.

I'll fix the tests shortly.

Looks like we have a bit of a CI issue.

Now that #34 is merged, hopefully rebasing this on top of main will solve the two CI errors with rustfmt on nightly and beta.
@fitzthum when you're back — please rebase...

Now that #34 is merged, hopefully rebasing this on top of main will solve the two CI errors with rustfmt on nightly and beta.
@fitzthum when you're back — please rebase...

I just rebased and pushed @fitzthum branch.

Thanks @sameo !


chore: update deps and ci

Description
Update deps and ci config file.

Linked Issues
Additional context

just curious, what's blocking this pr from merging?


Update syn to 1.0

The API has changed quite a bit. No pressing need but would be nice to give it a whirl.

cc #22, update quote as well

Looks like #42 should fix this issue. Just saying.

Indeed, this was fixed by #42


Parse error using MySQL 8 since flyway 6.3

Which version and edition of Flyway are you using?
Tested with flyway 6.2.4 (works), 6.3.3 (fails) and 6.4.0 (fails)
If this is not the latest version, can you reproduce the issue with the latest one as well?
(Many bugs are fixed in newer releases and upgrading will often resolve the issue)
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
CLI on docker
Which database are you using (type & version)?
MySQL 8
Which operating system are you using?
Linux / Mac
What did you do?
(Please include the content causing the issue, any relevant configuration settings, the SQL statement that failed (if relevant) and the command you ran.)

Migration should work as expected
What did you see instead?
Unable to parse statement in /flyway/sql/V201908081130__scheduleAndDelInvalidTokens.sql at line 1 col 1: Delimiter changed inside statement at line 1 col 1: -- Schedule deletion of expired and otherwise invalid tokens
The error happens on the comment -- Schedule deletion of expired and otherwise invalid tokens If I remove this comment it's working fine but this would change an already applied migration.

This will be fixed by 6.4.1. Probably resolved along with the fixes for https://github.com/flyway/flyway/issues/2782 or https://github.com/flyway/flyway/issues/2795


Add TypeScript definitions

Hello @tot-ra :wave:
As mentioned in another issue we are planning to add new features. Exploring the code we realised that some types are missing. We plan to gradually add typing while developing new features.
We have notticed the GraphQL schema is manually specified. We have used a GraphQL + TypeScript library (typegraphql) for other projects that works well. Do you think it's OK to refactor the project using it? This change may affect a significant part of the project.
Thank you so much! :smile:

hey. I didn't use it myself & looking at typescript decorators feature it reminds me of doctrine or java.
I personally dislike this style of meta-programming because

it takes away control from the regular iterative style & adds more declarative style instead
it adds much noise @annotations to class & method definitions, that I'm loosing focus of the actual logic

On the other hand, I was sceptical of typescript too initially 🤷🏻♂ . I'd suggest to add some minor PR into this repo to see how it looks like & how much issues does it solve. WDYT?

I understand the cons of using decorators but I still think the pros of faster development and GraphQL schemas from source code are good enough to consider it. Still, it's not a big deal.
Talking about typescript, we can add it to a part of the project and show it in a PR as you said :+1:


LightSwitch Low-Code Line of Businness App Framework

https://learn.microsoft.com/en-us/visualstudio/productinfo/visual-studio-lightswitch-support-announcement
Microsoft Visual Studio LightSwitch was an extension and framework specifically tailored for creating line-of-business applications built on existing .NET technologies and Microsoft platforms. The applications produced were architecturally 3-tier: the user interface ran on either Microsoft Silverlight or HTML 5 client, or as a SharePoint 2013 app; the logic and data-access tier was built on WCF Data Services and exposed as an OData feed hosted in ASP.NET; and the primary data storage supported Microsoft SQL Server Express, Microsoft SQL Server and Microsoft SQL Azure. LightSwitch also supported other data sources including Microsoft SharePoint, OData and WCF RIA Services. LightSwitch included graphical designers for designing entities and entity relationships, entity queries, and UI screens. Business logic could be written in either Visual Basic or Visual C#. LightSwitch was included with Visual Studio 2012 Professional and higher. Visual Studio 2015 is the last release of Visual Studio that included the LightSwitch tooling.The first version of Visual Studio LightSwitch was released July 26, 2011. the tool was purchased and installed as a stand-alone product. As of October 14, 2016, Microsoft no longer recommends LightSwitch for new application development.

This should be already live after #66. Also see comments there for dates.


updates reference level, includes all fitted models in objects

This PR introduces more accurate reference levels and extra output to improve debugging. The updates are now more consistent with the oaxaca package. Results below for the twofold models
Breaking changes:

group_var should be factor from now on where reference level is the second level of the factor variable. the first level will be introduced in the model as a dummy when pooled model argument specifies the Jann(2008) model.
OaxacaBlinder::chicago_long is updated to have a factor column gender instead of female / male binary numeric columns

Non-breaking change

output object contains 4 fitted models in output_obj$meta$fitted_models (model for A, model for B and pooled models (jann / neumark)

formula = real_wage ~ age | gender
data = OaxacaBlinder::chicago_long

# oacaxa works with binary / logical
datasetv2 = data
datasetv2$gender = ifelse(datasetv2$gender == "male", 1, 0)

modv1_twofold_neumark = OaxacaBlinder::OaxacaBlinderDecomp(
  formula=formula,
  data = data,
  type = 'twofold',
  pooled = 'neumark',
  baseline_invariant = FALSE,
  n_bootstraps = NULL
)
modv1_twofold_jann = OaxacaBlinder::OaxacaBlinderDecomp(
  formula=formula,
  data = data,
  type = 'twofold',
  pooled = 'jann',
  baseline_invariant = FALSE,
  n_bootstraps = NULL
)
modv2 = oaxaca::oaxaca(formula = formula, data = datasetv2, R=NULL)
#> oaxaca: oaxaca() performing analysis. Please wait.

# check outputs oaxaca for neumark
summary(modv1_twofold_neumark)
#> Oaxaca Blinder Decomposition model
#> ----------------------------------
#> Type: twofold
#> Formula: real_wage ~ age | gender
#> Data: data
#>
#> Descriptives
#>                  n    %n mean(real_wage)
#> gender==male   412 57.9%           13.69
#> gender==female 300 42.1%           17.52
#>
#> Gap: -3.83
#> % Diff: -28.01%
#>               coefficient   % of gap
#> explained           -0.20       5.3%
#> unexplained         -3.63      94.7%
#> unexplained_a       -2.06      53.7%
#> unexplained_b       -1.57      40.9%
t(t(modv2$twofold$overall[c(5), ]))
#>                          [,1]
#> group.weight        -1.000000
#> coef(explained)     -0.204005
#> se(explained)              NA
#> coef(unexplained)   -3.630331
#> se(unexplained)            NA
#> coef(unexplained A) -2.060458
#> se(unexplained A)          NA
#> coef(unexplained B) -1.569873
#> se(unexplained B)          NA

# check outputs oaxaca for jann
summary(modv1_twofold_jann)
#> Oaxaca Blinder Decomposition model
#> ----------------------------------
#> Type: twofold
#> Formula: real_wage ~ age | gender
#> Data: data
#>
#> Descriptives
#>                  n    %n mean(real_wage)
#> gender==male   412 57.9%           13.69
#> gender==female 300 42.1%           17.52
#>
#> Gap: -3.83
#> % Diff: -28.01%
#>               coefficient   % of gap
#> explained           -0.19       5.0%
#> unexplained         -3.64      95.0%
#> unexplained_a        0.00       0.0%
#> unexplained_b       -3.64      95.0%
t(t(modv2$twofold$overall[c(6), ]))
#>                              [,1]
#> group.weight        -2.000000e+00
#> coef(explained)     -1.918078e-01
#> se(explained)                  NA
#> coef(unexplained)   -3.642528e+00
#> se(unexplained)                NA
#> coef(unexplained A) -1.940510e-14
#> se(unexplained A)              NA
#> coef(unexplained B) -3.642528e+00
#> se(unexplained B)              NA

# check existence of all models in output object
str(modv1_twofold_jann$meta$fitted_models, max.level = 1)
#> List of 4
#>  $ mod_a                 :List of 13
#>   ..- attr(*, "class")= chr "lm"
#>  $ mod_b                 :List of 13
#>   ..- attr(*, "class")= chr "lm"
#>  $ mod_pooled_neumark1988:List of 13
#>   ..- attr(*, "class")= chr "lm"
#>  $ mod_pooled_jann2008   :List of 14
#>   ..- attr(*, "class")= chr "lm"

Created on 2024-03-23 with reprex v2.0.2

@davidskalinder what do you think of this?
this is an alternative + some extras for https://github.com/sinanpl/OaxacaBlinder/pull/11

Some notes here that I don't know what to do with yet:
In oaxaca, observations for which the group variable takes the value 1/TRUE get assigned to group B, whereas 0/FALSE gets assigned to group A:
> oaxaca::oaxaca(ln.real.wage ~ foreign.born | female, oaxaca::chicago, R = NULL) |> purrr::pluck("y")
oaxaca: oaxaca() performing analysis. Please wait.
$y.A
[1] 2.704193

$y.B
[1] 2.498258

$y.diff
[1] 0.2059347

> oaxaca::chicago |> dplyr::group_by(female) |> dplyr::summarize(mean = mean(ln.real.wage, na.rm = TRUE)) |> as.data.frame()
  female     mean
1      0 2.704193
2      1 2.498258

After loading the branch in this PR, observations for which the group variable takes a value of the second factor level get assigned to group A, whereas the first factor level gets assigned to group B:
> OaxacaBlinderDecomp(ln_real_wage ~ foreign_born | gender, chicago_long) |> purrr::pluck("gaps")
$gap
[1] -0.2059347

$pct_gap
[1] -0.08243132

$EY_a
[1] 2.498258

$EY_b
[1] 2.704193

> chicago_long |> dplyr::group_by(gender) |> dplyr::summarize(mean = mean(ln_real_wage, na.rm = TRUE)) |> as.data.frame()
  gender     mean
1   male 2.704193
2 female 2.498258

> levels(chicago_long$gender)
[1] "male"   "female"

... as expected given the assignments in parse_formula() (line 13, currently) and fit_models() (lines 63-64, currently).
So to summarize:

package
group_A_val
group_B_val

oaxaca
0 or FALSE
1 or TRUE

OaxacaBlinder
second level
first level

It seems to me that the implementation above is therefore the wrong way around?
NB that I think part of the problem might be that the language is a bit fuzzy.  Jann (2008:455) doesn't use the term "reference" for a value of the group variable, but instead notes that when the decomp is performed in the usual way (subtracting group B from group A, same as in calculate_coefs), the decomp is "formulated from the viewpoint of group B".  I think we should probably use that language to avoid getting turned around.
I should also check how Stata defines the groups by default and add it to that table.  Might not get to that this evening though.

Here's how Jann's Stata command handles it:
. oaxaca ln_real_wage age normalize(LTHS some_college college high_school advanced_degree), by(female)
(normalized: LTHS some_college college high_school advanced_degree)

Blinder-Oaxaca decomposition                    Number of obs     =        666
                                                Model             =     linear
Group 1: female = 0                             N of obs 1        =        378
Group 2: female = 1                             N of obs 2        =        288

   endowments: (X1 - X2) * b2
 coefficients: X2 * (b1 - b2)
  interaction: (X1 - X2) * (b1 - b2)

So the full table is like so:

package
group_A_val
group_B_val

oaxaca (Hlavac)
0 or FALSE
1 or TRUE

oaxaca (Jann)
0
1

OaxacaBlinder
second level
first level

Of course, the levels of a factor aren't really the same as the two values of a logical, but I think it's natural to view the FALSE value as being like the first level and the TRUE value as the second; so if we want to stick to the implementation of the other packages, the direction of the implementation in this PR should be flipped.
Having said that: I'm not entirely convinced that that's a bad thing, for several reasons:

It seems counterintuitive to me to subtract the TRUE group variable from the FALSE one.  (Though I suppose it is more intuitive if the TRUE group is often a disempowered group whose disempowerment is being investigated?  So, for instance, it makes sense to do the decomposition from the viewpoint of female == TRUE?)
lm() (and probably other models in R?) by default uses the first level of a factor as the reference level.  (It's not entirely clear to me how Stata chooses the reference level.)
relevel() only sets the first level of a factor (which it calls the "reference level"); so it can easily be used to set the first level, but not the second.

I think item 3 is the most serious of these problems, since users need a way to set the "viewpoint" level easily.  If they can't do that using relevel(), then I think we should export another function to do it instead (which can probably just be a function that flips relevel() but is more intuitively named).
@sinanpl, any thoughts about this?

I'll add BTW that personally I still feel like the best way to handle this is just to have OaxacaBlinderDecomp() take a new option to specify the value of the viewpoint group.  If we follow through on this PR's proposal to drop the auto-group-choice behavior, then this doesn't even have the problem of requiring two options as discussed in https://github.com/sinanpl/OaxacaBlinder/pull/11#issuecomment-2015494016.  I think allowing users to directly specify the viewpoint level is clearer and more straightforward, and of course we can still set the default group how we want depending on the considerations above...

So @sinanpl my plan was to try to complete this PR and get it into the codebase so I could start using (and testing!) the package in my project.  However, thinking about it, I don't want to make the call on how to handle what I guess I'll now (until I find a better name?) start calling the "viewpoint" group until you weigh in (i.e., on whether to use the first factor level as the other packages do, to use the second level as this PR does, or to have a user-specified option with one of the levels as the default).  Obviously any changes to that setup would be breaking changes, and possibly confusing ones at that, so I'm hesitant to send the thing in a direction that's hard to get back from later.
For the time being, I'll implement a new private mod with a simple version of my preferred solution of a user-specified option and use that for testing.


Backend tokens support

We should be able to generate backend tokens, but only behind auth middleware.
Tokens can be of types ALL & READ_ONLY.

Backend token support is added.
Currently we only support ALL and no READ_ONLY tokens yet.


chore(ci): move protobuf specs to repository top level

Summary
Move the Astria protobuf specs into a top-level proto/ folder and perform Protobuf to Rust code generation in a self-standing compilation tool.
Background
The protobuf specifications are the single point of truth for Astria's API. As such they should stand by themselves in the repository hierarchy and not be a detail of the astria-proto Rust crate as a language-specific implementation.
Furthermore, the current state using integration tests to compile protobuf to rust code via integration tests made for bad developer experience: a error compiler higher level abstractions on top of the generated lower level interfaces lead to the test - and hence code generation - never running. For example, this happened frequently due to the programmer anticipating changes made to a protobuf message but before re-generating code.
Protobuf-to-Rust compilation now happens in the astria-protobuf-compiler binary crate, and the check for the Protobuf spec and generate Rust code being in sync is moved to a github action.
Changes

Move crates/astria-proto/proto under the repo root to proto/astria
Create an astria-protobuf-compiler tool that invokes buf and calls tonic-build
Run the protobuf compiler in CI and test if it leaves the git tree unchanged, fail otherwise (as opposed to doing this check in Rust before)

Testing
All Rust code using the protobuf definitions still compiles. Deleting the generated code prior to this change and then re-generating with the new tool leaves the git tree unchanged. Deleting a single file makes the github action fail (meaning the job checking for proto spec and Rust being synced works).

Ran pedantic clippy on the protobuf-compiler tool, added the pedantic clippy check in CI.


localization - use dart/intl package

I wonder, wouldn't it better if you adjust the package to use dart/intl package thus remove this tedious task and guarantee much broader  localization support for you excellent package?

Thank you. That's a good suggestion, but I'm too busy to change it recently.


Add parenthesis around print parameters

First step for python3 compatibility :)

Bump!

Thanks a lot for the change @strycore! Sorry this was left for so long. I am attempting to get this project back to speed.
There is at least one issue though. The print statements do not work the same as before. For example:
>>> srcfile = 'something'
>>> print 'Could not open', srcfile
Could not open something
>>> print('Could not open', srcfile)
('Could not open', 'something')

Because wrapping things in parentheses just creates a tuple that is then passed to print. It is the same as
>>> print ('Could not open', srcfile,)
('Could not open', 'something')

It looks like this branch went away too and I don't want to merge it directly into master. I'll have to think about what to do. If you are able to get this PR ready again let me know. Otherwise I may just close it for now.

The print issue can easily be fixed with a from future import print_function. As for the branch, I must have deleted it with checking the status of this pull request, I'll make another one then.


Revert "Test with newest cf-units: no longer called cf_units."

Reverts SciTools/iris#3265
Following #3274 (thanks @lbdreyer !)
Likewise part of routing these changes via v2.2.x branch instead of direct to master ...

Thanks @pp-mo !


Add support for developing within Devcontainers

Is your feature request related to a problem? Please describe.
This feature isn't related to the function of FreeRDP. My aim is to allow myself and others to compile FreeRDP from within a devcontainer. The idea here is that during initialization of the devcontainer, all required dependencies would be installed. Although not my main goal I believe it could allow others to contribute faster and lower the bar for entry
Describe the solution you'd like
Simply adopting the the devcontainer spec as well as implementing the Dockerfile to install all of the necessary dependencies.
Describe alternatives you've considered
I support installing the dependencies locally on my machine, however I'd like to not clutter my machine that way and would value the separation of development environment in docker and my work station
Additional context
I could implement this feature if it was accepted. Although since FreeRDP is a GUI app I suspect the usefulness of devcontainers is lower. However having reproducible builds could be convenient

a starting point would be https://github.com/FreeRDP/FreeRDP/wiki/Compilation#compilation or the ci scripts https://github.com/FreeRDP/FreeRDP/blob/master/.github/workflows/codeql-analysis.yml

Some people doesn't use.. Please fixed it immediately.. & any further Problem send a message on insta thank you