Server-side rendering

Any plans to add SSR support?

I think this should be trivial once cache API is exposed, as mentioned in #4

Finally, we plan to export the cache APIs from the lib, and add options to the config soon. So you can override it with your own implementation like LRU cache, or just manipulate the cache object.
You could replace it with an isomorphic cache.

I imagine the long-term plan for this library is to leverage Suspense + SSR once Suspense is fully released, and I think Next.js will likely do the same. But I agree that in the meantime it would be nice for it to have support in Next.js or other SSR setups to fetch data ahead of time.

Yeah indeed. When we have Suspense supported in server side, we will have this feature out of the box (by just using suspense: true).

But I agree that in the meantime it would be nice for it to have support in Next.js or other SSR setups to fetch data ahead of time.

And yes, we’ve been doing this internally w/ SWR and Next.js for a long time in our dashboard. Will definitely adding the feature to this library. PR soon, stay tuned!

Hey everyone! With the support of the new initialData option in v0.1.10, you can now use getInitialProps with SWR to do SSR in Next.js without changing too much:
App.getInitialProps = async getInitialProps () {
  const data = await fetcher('/api/data')
  return { data }
}

function App (props) {
  const initialData = props.data
  const { data } = useSWR('/api/data', fetcher, { initialData })

  return
{data}

}

In this example, everything works the same just like a normal SSR Next.js app. But it’s also fully powered by SWR in the client side, which means the data can be dynamic and update itself over time / user interactions.
Let us know what you think about this :)

Closing this issue  🎉

@quietshu heya!
Seems theres an issue when using isomorphic-unfetch returning an error "Only Absolute URLs are supported" when fetching from getInitialProps.
Any idea about best way around this.

That is not an issue of SWR. It's how sending HTTP requests works server side, you can't use /api/users because the server doesn't know to which host send the request, you need to add localhost:3000 or your production domain.
Maybe you could use env variables to know if you are in development use localhost:3000 and if you are in production use your domain. You should also be able to dynamically get the host using the headers of the request if you want to make it dynamic but not sure how such a good practice is that.

@timneutkens @quietshu any ideas what the best way to grab this host would be?
project is deployed on now. need to be sure the host is properly returned as a now deploy url.

Now provides a header for this:
https://zeit.co/docs/v2/network/headers/#x-now-deployment-url
On Wed, Jan 8, 2020 at 10:34 AM Jeff Reiner<EMAIL_ADDRESS>wrote:

@timneutkens https://github.com/timneutkens @quietshu
https://github.com/quietshu any ideas what the best way to grab this
host would be?
project is deployed on now. need to be sure the host is properly returned
as a now deploy url.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/zeit/swr/issues/11?email_source=notifications&email_token=AAD2X6KLBTFRS3LMPFPALRTQ4XW6XA5CNFSM4JGBSSRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIM6SUA#issuecomment-572123472,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAD2X6O2L65I6IW3I67TBNDQ4XW6XANCNFSM4JGBSSRA
.

From what I read here https://github.com/zeit/now-builders/issues/55#issuecomment-442968328 you should use the Host headers I mentioned to get actual URL of your app (the deployment URL or the aliased URL) and the x-now-deployment-url header to get the internal deployment URL even if it's aliased.

Only issue here is that you can't use the headers from the ctx of the getInitialProps if you reach the page via client-side routing, not directly.
Not sure best approach to handle that.

You only need the headers if you’re on the server side

You can detect if you are server-side to use the Host in the request and if you are client-side use /api/* directly or access the Host with location.host, maybe you could create a wrapper for that.
function getHost(ctx) {
  if (ctx.req) return ctx.req.headers.host
  return location.host
}

Something like that.

After working this out,
Im noticing some issues where the data is always refetched on page transitions?
It only happens when providing initialData to the useSWR hook.
Im not sure if this is the proper behavior?
But if you dont provide initialData when transitioning pages it always uses the cached data rather than fetching new.

App.getInitialProps = async getInitialProps () {
  const data = await fetcher('/api/data')
  return { data }
}

function App (props) {
  const initialData = props.data
  const { data } = useSWR('/api/data', fetcher, { initialData })

  return
{data}

}

I believe the issue should be re-open 🤕
One of the greatest things about SWR is that on the second-fetch if the data is in cached it will be served instantly and also "deduping" requests so they don't get fired multiple times in a short period of time.
That's the behaviour I would like to see implemented on the server-side, so if many users hit my homepage at the same time SWR will call the data API only once and render the page extremely fast for everyone ( and then SWR on the client side could kick in ) as opposed for every user having to wait for the same request to be executed on getInitialProps before the initial page load!
For instance:
App.getInitialProps = async getInitialProps () {
  const {data, loading} = useSWR('/api/data', fetcher)
  await loading
  return { data }
}

function App (props) {
  const initialData = props.data
  const { data } = useSWR('/api/data', fetcher, { initialData })

  return
{data}

}

Of course, this specific use case could be implemented locally by my application on top of node-cache for instance, so it's not a big deal to don't have it on SWR!
But I think it could be a good addition to SWR ( :

Workaround to cache the server-side initial data on the client side (as long as SWR doens't support it natively): https://www.npmjs.com/package/use-fetch-cache

that's cool but i feel it should be a feature of useSWR? perhaps you could do a PR / open an issue regarding this?
I believe this issue only discuss the idea of using useSWR on the server-side instead of using a regular fetch method?


Positive signing tests fail

Currently all TestSignHash tests except the negative test testSCAL2InvalidHash fail.
There appears to be an issue in the test PKI.

Thanks for pointing this out. It was indeed an issue in the backend service that the tests rely on.
Should be fixed now.

Yes, all works fine again. Thanks!


Generate PDF in client

Context:  We create PDF files using pdfmake.  The MedplumClient class has a method createPdf which accepts a pdfmake TDocumentDefinition and returns a FHIR Binary.
Before: We posted the TDocumentDefinition in entirety to a /fhir/R4/Binary/$pdf endpoint, and created the PDF on the server.  We returned the Binary as a result.
Unfortunately, there are a few properties of TDocumentDefinition that are not serializable to JSON, such as table layouts and dynamic footers.  Therefore, the strategy of posting as JSON was fundamentally flawed.
Now: We take the TDocumentDefinition, invoke pdfmake, post the Blob (in the browser) or the Buffer (in a node app) and post it to the normal /fhir/R4/Binary endpoint.  We returned the Binary as a result.

The API is the basically same.

Before:
createPdf(docDefinition: Record<string, unknown>, filename?: string): Promise<Binary>

After:
createPdf(
    docDefinition: TDocumentDefinitions,
    filename?: string,
    tableLayouts?: { [name: string]: CustomTableLayout },
    fonts?: TFontDictionary
  ): Promise<Binary>

This allows full control over the PDF generating process.

We now use pdfmake types.  You may recall that we have gone back and forth on this, because the types are supposed to be optional but historically caused problems for consumers who didn't use them.  We implement a number of strategies discussed in this thread: https://stackoverflow.com/questions/54392809/how-do-i-handle-optional-peer-dependencies-when-publishing-a-typescript-package

We go to great pains to make the API work the same in the browser and in a node app.  There are an annoying number of differences between the respective pdfmake API's, but I think we've smoothed them all over.  This has been tested:
a. In browser with a simple HTML file with a simple <script> tag
b. In a node app that imports @medplum/core
c. In the bot lambda "execute" environment
d. In the bot "simulate" environment

Fonts are still tricky.  In the browser, you can refer to fonts by HTTPS URL (as long as CORS is setup!).  I added default fonts to static.medplum.com for Helvetica, Roboto, and Avenir.  In a node app, the consumer will have to pass in font file paths.

In future PR, I recommend that we deprecate the /fhir/R4/Binary/$pdf endpoint, and remove pdfmake from server side dependencies entirely.  It's a nice opportunity to make a clean break.

Blocking https://github.com/medplum/medplum/pull/646

Coverage decreased (-0.1%) to 95.011% when pulling<PHONE_NUMBER>28b15b3cdf5aab2f9362a949fc30de on cody-create-pdf-in-client into e7bf843ded7970398832a5a4d7a7254a9fbb99b1 on main.


Remove or suppress the warning messages from Glyph missing font

In 2018 I dump the report in a system with a zh_TW font to support to generate a report in zh_TW. However, the font is not that common and we don't plan to generate the version of zh_TW. The warning message of missing font looks scary for people without the font. It will be great if we could have a more explicit instruction of the warning or suppress/remove it.
Warning message information

/home/tai271828/.local/share/virtualenvs/pycontw-postevent-report-generator-sthy_Jhg/lib/python3.7/site-packages/matplotlib/backends/backend_agg.py:180: RuntimeWarning: Glyph 20197 missing from current font.
  font.set_text(s, 0, flags=flags)
/home/tai271828/.local/share/virtualenvs/pycontw-postevent-report-generator-sthy_Jhg/lib/python3.7/site-packages/matplotlib/backends/backend_agg.py:180: RuntimeWarning: Glyph 20839 missing from current font.
  font.set_text(s, 0, flags=flags)
/home/tai271828/.local/share/virtualenvs/pycontw-postevent-report-generator-sthy_Jhg/lib/python3.7/site-packages/matplotlib/backends/backend_agg.py:180: RuntimeWarning: Glyph 21040 missing from current font.
  font.set_text(s, 0, flags=flags)
/home/tai271828/work-my-projects/pycontw2019-post-event-analysis/pycontw-postevent-report-generator/report_generator/io/yaml.py:11: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  yaml_load = yaml.load(stream)
Analysis process finished completely.

It seems the warning is removed in the latest version. Should we close this issue?

Thanks for the reminder. Yeah I fixed this issue.


Save work on contest hosting.

@Vishal1541 Can we please get this PR merged? We can sort out issues later.


[Color Picker] Change of main display, and resolution

Microsoft PowerToys version
0.66.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
ColorPicker
Steps to reproduce
PowerToysReport_2023-01-16-17-45-55.zip
I have a laptop (resolution: 1920×1080, I will call it D1), and a monitor (resolution: 2560×1440 I will call it D2). When the laptop is connected to the monitor, the D2 is set as main display, when disconnected, the only display (D1) is set to primary.
My monitor is on the left of the laptop.

When I use Color Picker when the monitor is connected, and I move the window on the laptop monitor (secondary, on the right), when I disconnect the D2, the window is not present on the D1.
Even if the window is inside the D2, when disconnected, is shifted to the left in D1; probably the window maintained his absolute position.
The problem is solver only closing and reopening Power Toys.
✔ Expected Behavior
When the display configuration changes, position the window inside the main display.
❌ Actual Behavior
The window keeps his absolute position, becoming inaccessible, and also invisible to the user.
Other Software
No response

Strange, the ColorPicker window should follow the mouse

Are you still experiencing this issue? /needinfo

No, the issue is solved. I'll close this issue.


vfs watch doesn't seem to work as expected

var root = '/home/hacker/workspace'

vfs.watch(root, function() {
  console.log('Something changed')
}

What's wrong with the above code?

vfs.watch argument should be relative to workspace root, so if
c9.workspaceDir == '/home/hacker/workspace' watch should be called for "/"
vfs.watch("/", function() {
    console.log("Something changed");
}); // also this was missing ;)

Humph! Nope!
/home/dolftax/doselect/altair/node_modules/vfs-local/localfs.js:861
            callback(null, meta);
            ^
TypeError: undefined is not a function
    at /home/dolftax/doselect/altair/node_modules/vfs-local/localfs.js:861:13
    at check (/home/dolftax/doselect/altair/node_modules/vfs-local/localfs.js:147:13)
    at resolvePath (/home/dolftax/doselect/altair/node_modules/vfs-local/localfs.js:134:14)
    at Object.watch (/home/dolftax/doselect/altair/node_modules/vfs-local/localfs.js:852:9)
    at module.exports (/home/dolftax/doselect/altair/vfs/vfs-interface.js:24:7)
    at Object.<anonymous> (/home/dolftax/doselect/altair/index.js:7:35)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)

@dolftax are you using this in cloud9 sdk or just this module?
I was answering for client side wrapper, the vfs.watch requires options object see
https://github.com/c9/vfs-local/blob/master/localfs.js#L853

@nightwing Just this module. btw, what options? I don't see any mandatory options here - https://github.com/c9/vfs-local#vfswatchpath-options-callback

it says vfs.watch(path, options, callback) none of arguments are marked optional, so they are all mandatory.
Call it as
vfs.watch("/", {}, function() {
    console.log("Something changed");
});

Nope!
  vfs.watch('/', {}, function() {
    console.log('Something changed')
  })

.. doesn't seem to work.
I touch a file on the root ('/home/hacker/workspace', which I am passing as root) directory, doesn't log anything.

try
vfs.watch("/", {}, function(err, meta) {
    if (err) return console.error(err);
    meta.watcher.on("change", function(e) {
        console.log("change", e);
    });
});

@nightwing Works :+1: Thank you. Try documenting these when you find spare time.


Model BETH olivia events

Fixes #2659.

We temporarily "disable" the feature with dab80b9aec412baed827467cbabe0ac7ab31aed4 until Olivia supports the new events.

bors r+


Fix collectd->logstash input types

Problem: Logstash didn't understand values coming from collectd:
:message=>"Invalid value for type="cpu.usage", key=nil, index=3",
:level=>:error
This was because logstash's collectd input wasn't configured with
types.db for Docker stats.
This commit mounts the collectd plugin volume into the logstash
container, and configures logstash so it reads types.db for the
docker-collectd plugin.

@tgermain I think this should fix your problem?

Yes, it does indeed. Thanks @eirslett.
Why not mount /usr/share/collectd as read only ? I don't think logstash should require write permission.

I forgot to add permissions. Thanks! PR updated. Now it's mounted as read-only.

fixes it for me too, thanks!


New exercise: Tower of Hanoi

I would like to contribute an additional exercise for the Go track.
Exercise Tower of Hanoi is sketched here:
https://github.com/udhos/exercism-go/tree/master/tower-of-hanoi
If you think it would fit in, please let me know how to contribute it.
Thanks!

Hello @udhos . Thanks for the interest in adding an exercise. And you have a good start on it for the Go track of exercism!
The Tower of Hanoi is a classic programming problem and I think it is worth consideration in Exercism for all language tracks.
New generic exercises enter first via the problem specifications repo.  See this helpful document for implementing a new exercise.   Refer to this general guide on Contributing, particularly the section on Implementing a Completely New Exercise.
In the referenced documents, you see the term "slug", which is just the name of the exercise. In this case, the name would be all lower case, tower-of-hanoi.  That sets the name of the new directory in the problem-specifications.  Follow the structure of another exercise in problem-specifications to use as an example, such as reverse-string. So, it's just a new directory within exercises, such as tower-of-hanoi,  and three standard named files within that directory: canonical-data.json,  description.md, and metadata.yml. The canonical-data.json, defines test cases primarily. For tower-of-hanoi, the "property" for each test case is likely just "solve". And the "input" property would perhaps follow what you have in your readme, with nested items such as "disks", "source", "helper", and "target" disk names.  Use your wikipedia.org link as the "source_url" in the metadata.yml.
I suggest cloning problem specifications repo and submitting an issue and/or PR there first to get things rolling.  It's best if new exercise PR in problem-specifications is merged first, since there may be changes which impact the language track exercises implemented.
Feel free to ask questions here, and have fun!

Hi @leenipper.
I initially considered to submit the problem for all tracks. However, this issue led me to believe the specification repo is frozen for new exercises:
https://github.com/exercism/problem-specifications/issues/1560
That's why I sketched Tower of Hanoi only for the Go track.
What do you think?

Oops.  Ok, I wasn't aware of the temporary closure to new exercises.
I think it is worth considering to add tower-of-hanoi as a Go track specific exercise.
@bitfield, what do you think ?

I wasn't aware of that either.  Happy to help work on the PR too, by all means add me as a reviewer. Thanks @udhos for suggesting this.

@udhos, That's completely understandable, and I hope a few pointers are helpful.
Refer to this section since this is the custom case (Go language track only). You need a .meta subdirectory, with the two files named description.md and metadata.yml.  The description is short, and likely is from the first part of your README.md.  The metadata.yml is a 4 line file; follow this sample and use applicable values.
The README.md is actually generated using a tool called configlet.
I think these two commands are correct for tower-of-hanoi as you have it now:
   ./bin/fetch-configlet
   ./bin/configlet generate $PWD --only tower-of-hanoi

If the README.md isn't generated to your liking, you can put a hints.md inside the .meta directory, and it's content will also be placed into the README.md.  We have several instances of  hints.md in the Go track exercises. You can also adjust your description.md and metadata.yml as  needed.
You do need a commit for config.json to add it's entry, such as the lines below. The travis-ci build won't succeed until there is a config.json entry, or "slug" as it's called.   In the sample entry below, I got the uuid value from here for future reference; it's just a unique id. If you think the difficulty level is higher than 2, feel free to use a higher value. This isn't a "core" exercise, so "core" is false. And it's an exercise that is available without needing to be "unlocked_by" another exercise completion; unless you think a certain exercise applies as a good precursor. You can pick other applicable topics values; I simply put "algorithms" for starters.  The PR will get this reviewed, so use an entry that is your best idea, and we go from there.
    {
      "slug": "tower-of-hanoi",
      "uuid": "ae946961-3929-4f79-8e22-1e65c983e57b",
      "core": false,
      "unlocked_by": null,
      "difficulty": 2,
      "topics": [
        "algorithms"
      ]
    },

Thanks for taking this on @udhos !

@leenipper Thank you a lot for the directions!
I have submitted commits for the config.json slug and the generated README.md.


Windows issues

Would love to have an option available for windows. However, it seems that it never gets past the openssl and cryptography parts on the requirements install.

Hi @runfaj, thanks for reporting!
I don't have access to a Windows machine, so I won't be able to reproduce the install issue myself, but I can try to help you figure out the problem. Could you share what errors you're running into and any relevant console output?

Hi @runfaj, thanks for reporting!
I don't have access to a Windows machine, so I won't be able to reproduce the install issue myself, but I can try to help you figure out the problem. Could you share what errors you're running into and any relevant console output?

is this project complete? running alexacast does it control chromecast?

I was wondering how do we add skill for chromecast in alexa

Hi @runfaj, I'm going through my projects closing old issues.
If this problem is still relevant to you (or anyone else who comes across this page) please feel free to reopen!


Fix dead links

One of the referenced documents have been moved to a sub-folder and many links were broken.
I also made an update to the v1.volume sub-section based on the official Kubernetes documentation.

@piotr-sk thanks for your work. Could you please fix the indendation changes? Otherwise it will be impossible to review it.

Indentation fixed. Set automatically with format on save, but with different defaults than your project... sorry for that.


Some table queries return no records?

Hi,
I have set up a new project, against a new MySQL DB. in my default schema (iwall), most of my tables have a prefix of 'iw_', eg. 'iw_timezone',  and some have no prefix, eg 'users'.
I have reverse engineered the schema, and I have a working generated model for the schema.
I can apparently only fetch rows from the tables without the table prefix 'iw_'?
Here is my test code:
use Propel\Runtime\Propel;
use iwall\iwall\IwTimezoneQuery;

$con = Propel::getWriteConnection('iwall');

$con->useDebug(true);

$sql = "SET GLOBAL init_connect='SET foreign_key_checks = 0';";    // Let Propel handle the RI, since MySQL is broken

$stmt = $con->prepare($sql);
$stmt->execute();  // returns TRUE

In MySQL Workbench, I can query table iwall.iw_timezone as follows:
SELECT * FROM iwall.iw_timezone;
and the result is:
id  name      value
--  ---------  ------
1   GMT+2   2

If I try to retrieve it via a direct Propel statement:
$stmt = $con->prepare('select * from iwall.iw_timezone;');
$result = $stmt->execute();
$rows = $stmt->fetchAll(); // returns no errors, but $rows = Array[0]

$data = IwTimezoneQuery::create()->setFormatter('Propel\Runtime\Formatter\ArrayFormatter')->find();
$count = $data->count();

There is no error reported, but...
$data.data is Array[0]
and $count is 0
I have tried this with several tables, and I can only return rows from tables without the 'Iw' prefix. The generated docs say that a ChildIwTimezone object should be returned... what does the 'Child' portion mean????
Please can someone help me understand what is happening here?
In my Composer.json file I have:
"require": {
		"php": ">=5.5",
		"propel/propel": "~2.0@dev"

and I'm running PHP 5.6.3
Thanks in advance,
Adrian

Do they have all a primary key?

Hi Marc,
Yes, all my tables always have an autoincrement ID field as the primary key... even reporting tables

I left a more detailed description of the problem in the Propel group forum, perhaps it would help to look at it there?

Marc,
I am deeply sorry for wasting your time, it was my mistake. The particular way I created the records in MySQL Workbench did not autocommit the records as it was supposed to, and I didn't notice.  So Propel was 100% correct, there WERE no records!
My humble apologies, and thanks again for the awesome beast that is  called Propel!
Regards,
Adrian


NEW: adds 2D scatterplot

Goals for the first working draft:

[x] Accepts metadata-like inputs (anything that can be transformed into a DF)
[x] Numeric data required, categorical metadata optional (used for color-coding)
[x] 2 dimensional
- [ ] Support for flipping axes interactively no longer needed for this scope
- [ ] Support for inverting data interactively no longer needed for this scope

First refactored draft from the following spec via vega editor:
https://vega.github.io/editor/#/gist/60892220e4e76e84739b2a756080852e/vizard_scatter.json

hey @lizgehret — awesome! I look forward to trying out a stable draft whenever it is ready.
I just have a quick comment/question for now: why do you split data and metadata into two separate inputs? I wonder, since both are Metadata objects. Technically couldn't you just have one metadata input and the user can select what is displayed on the x and y axes? A user could always merge multiple metadata objects if they want to plot, e.g., feature abundance vs. some sample metadata.
It would also be cool to allow a user to select the X and Y axis data interactively, instead of selecting these as params... I can open a feature request for this if you would like to save that for the future. Otherwise, given the current operation it seems like data/metadata should rather be numeric metadata columns... Then QIIME 2 can enforce that valid column names are being used.

hey @lizgehret — awesome! I look forward to trying out a stable draft whenever it is ready.
I just have a quick comment/question for now: why do you split data and metadata into two separate inputs? I wonder, since both are Metadata objects. Technically couldn't you just have one metadata input and the user can select what is displayed on the x and y axes? A user could always merge multiple metadata objects if they want to plot, e.g., feature abundance vs. some sample metadata.
It would also be cool to allow a user to select the X and Y axis data interactively, instead of selecting these as params... I can open a feature request for this if you would like to save that for the future. Otherwise, given the current operation it seems like data/metadata should rather be numeric metadata columns... Then QIIME 2 can enforce that valid column names are being used.

Hey @nbokulich! That's a great question - my thought process for that was that we'd allow a metadata-like object (essentially something that can be transformed to/from a dataframe, like ordination results, alpha diversity, etc) that would contain numeric/continuous values. This would be the data, and would be required. For the metadata, this would be optional and could contain another metadata-like object (actual metadata, or a dataframe object that contains at least one categorical/discrete column). This is what would create the colors in the scatter, but wouldn't be required for basic functionality (i.e. just plotting two continuous values).
With that being said, this could definitely just take one metadata object that contains all of the information above (i.e. merged alpha diversity w/associated metadata, etc) and then just accept particular columns from the user to identify what they'd like to visualize. I'm open to whatever seems like the most flexible option - cc @gregcaporaso and @ebolyen.
Re: x & y being selected interactively - I'm sure there's a way to do that in vega (similar to how we have drop downs for metadata columns in taxa barplot, etc). I think opening up an issue would be perfect - I'm going to finish up this draft, and then can iterate from there based on what we think makes the most sense to add/change!

@lizgehret, I agree that it would be nice to take a single qiime2.Metadata as input, and then let the user interactively select which continuous columns to plot on the x- and y-axes, and which continuous or discrete columns to use for coloring.
Here's an example I found in the vega gallery showing how to interactively select the data to plot on two axes of a scatterplot, and this is the example that we looked at where a user can pass two metadata objects as input to a visualizer.

@lizgehret, I agree that it would be nice to take a single qiime2.Metadata as input, and then let the user interactively select which continuous columns to plot on the x- and y-axes, and which continuous or discrete columns to use for coloring.
Here's an example I found in the vega gallery showing how to interactively select the data to plot on two axes of a scatterplot, and this is the example that we looked at where a user can pass two metadata objects as input to a visualizer.

Hey all - I've modified this to utilize exactly Metadata as an input, and should be able to implement the interactive selection for x and y fairly easily from here (that's a nice example @gregcaporaso).
Main updates in terms of the inputs are that the x & y axes are numeric MD columns, and we'll also accept an optional categorical column, which will color-code the points according to their 'group'.

@lizgehret, is it possible to allow interactive selection of the categorical column for coloring too (or maybe all the columns for coloring - and default to continuous or discrete color scales based on the metadata column type?).

@lizgehret, is it possible to allow interactive selection of the categorical column for coloring too (or maybe all the columns for coloring - and default to continuous or discrete color scales based on the metadata column type)?

Yep, that should be possible re: still retaining the coloring with respect to the drop down (currently working on that now). The main thing that would become more complex is if a user chooses a numeric MD col from the drop down, the legend would look pretty crazy (since it would group each numeric value into a legend category). I'm not sure if we want to allow that or not.

Hey @gregcaporaso @nbokulich! I've got a first working draft for you both to try out when you have the chance.
One thing I haven't implemented is the interactive x&y axes - I was thinking it could be good for users to intentionally select MD columns when they're creating the viz, and I've added validation to ensure the inputs they're selecting are both numeric. Open to thoughts about that, and we can definitely play around with adding in the interactivity for x&y (with the restriction that we're only allowing numeric columns for those - similar to how the group dropdown only allows for categorical columns).
I've attached a toy dataset I created for testing - feel free to use this and/or any other MD file you'd like.
cars.txt

UPDATE: i found a bug while using the moving pictures dataset - it looks like not all points are being plotted. will work on a fix for this!

Hey @lizgehret, This looks really nice!
A few things I think would be nice to address for version 1:

I do think it would make this more useful if the x and y measures were optional (they become the default/starting value(s) if provided), and let the user choose what is plotted on each axis from numeric metadata columns within the visualization. Already I have some things I'd like to look at with this, but it would require the generation of a bunch of different plots.
Could the weight/width of the outline of the points be increased? They are pretty light in the plot.
"CategoricalMetadataColumn" in the figure would be more self-documenting if it was replaced with "Color points by:" (or something like that). Additionally, could we connect a parameter that would set the default (starting) coloring of the points as a user-specified categorical metadata column?
I could see us wanting to add a 3D scatterplot in the future. Do you think it would make sense to call this something like scatterplot-2d, to make way for a scatterplot-3d in the future? I don't have strong feelings about this one.

Other things that could be issues that are addressed later:

What do you think of additionally giving the user control over the shape of the points based on categorical metadata, such that one category could represent the shape and another the color?
Could we integrate control of the color palette in the visualization?
Could we integrate an interactive legend, as in this example?
It'd be neat to (optionally) have histograms on the top and left, showing the distribution of points on the x and y axes, respectively. For example, see here. (This is a nice-to-have-someday request, rather than anything that would need to be addressed any time soon.)

Thanks for all of this feedback @gregcaporaso, this is all very helpful! Requests for v1 are addressed below.

I do think it would make this more useful if the x and y measures were optional (they become the default/starting value(s) if provided), and let the user choose what is plotted on each axis from numeric metadata columns within the visualization. Already I have some things I'd like to look at with this, but it would require the generation of a bunch of different plots.
Sounds good, I can do that! I'll have x&y handled the same as the color drop-down, just with numeric columns.

Could the weight/width of the outline of the points be increased? They are pretty light in the plot.
Definitely - I'd like to play around with the styling a bit more, and this was one of the things I wanted to change as well.

"CategoricalMetadataColumn" in the figure would be more self-documenting if it was replaced with "Color points by:" (or something like that).
Works for me, I'll update that!

Additionally, could we connect a parameter that would set the default (starting) coloring of the points as a user-specified categorical metadata column?
Definitely - I actually had this hooked up originally, and then ended up removing it.

I could see us wanting to add a 3D scatterplot in the future. Do you think it would make sense to call this something like scatterplot-2d, to make way for a scatterplot-3d in the future? I don't have strong feelings about this one.
Works for me!

Hey @gregcaporaso, all of your v1 review comments have been addressed! I tweaked some styling elements as well to make things look a bit better - let me know what you think about the updates when you have the chance to take a look. @nbokulich let me know if there's anything else you'd like to see outside of @gregcaporaso's feedback!

This is looking really good to me @lizgehret!
One other comment: I think the current --p-group-measure should be --p-color-by-group, or something like that, to set the stage for connecting other shapes/etc in the future.
Here's a plot I'm looking at based on the Moving Pictures data.
I think this is basically ready for merge whenever - since this is all pre-release we can always get other changes in. @nbokulich, what do you think? Are there edits you'd like to see in there before merge?

Thanks @gregcaporaso! That param name change makes sense to me - just pushed up those updates. @nbokulich let me know if there's anything else you'd like to see in this version - otherwise I'll get tests added before merging.

This looks great @lizgehret thanks! I am already planning some feature requests 😉 but have no requests for changes to the current PR (I only did a user test with a couple datasets, did not review the code)

Awesome, thank you both! Will add some tests and get this merged!

FYI I merged this PR but am still making commits to the scatterplot branch with a couple of tweaks & adding unit tests. once that's done i'll merge into dev.


feat/add-recurring-fares-to-history

Please review before merging.

:tada: This PR is included in version 3.16.0 :tada:
The release is available on:

GitHub release
v3.16.0

Your semantic-release bot :package::rocket:


Custom Metadata and Tests

We have found a need to add a decorator to InfluxDB stats.  In particular, when a Hapi server runs inside a Docker container, there is no way to know what the name of a service is.  In this PR we are adding a metadata option that can be used to add arbitrary decorations to your stats.
I have also added one test to this project since it had none.  I basically followed the pattern of Good-HTTP.  Test coverage is now 81%; which is not ideal, but better than before.  Finally, ESLint now finds on issues.  I fixed the linting errors I agreed with, and overwrote the other ones via ESLint config.

Oops!  This PR was made prematurely.  I need to do some more work on this branch, then we will open a subsequent one.  Ignore.


:seedling: Bump k8s to v.1.32.0

What this PR does / why we need it: Bump k8s to v.1.32.0

/retest

Rebase needed to get fixed links.

Since @peppi-lotta is away I will rebase

/test metal3-centos-e2e-integration-test-main metal3-ubuntu-e2e-integration-test-main

/lgtm

/retest

/hold
lets wait for image building job to pass.

now images are in artifactory, lets unhold and run tests
/unhold
/retest

Just noting that CAPI does not have 1.32 yet, so we should not merge this before we can bump CAPI to a version that has the support? It is expected today anyways.

Just noting that CAPI does not have 1.32 yet, so we should not merge this before we can bump CAPI to a version that has the support? It is expected today anyways.

/hold

uplifted capi to v1.9.1 which supports k8s v1.32 , we can merge this now
/unhold

/test metal3-centos-e2e-integration-test-main metal3-ubuntu-e2e-integration-test-main

/test metal3-centos-e2e-integration-test-main metal3-ubuntu-e2e-integration-test-main

/lgtm

Missing README updates

done

/retest
Network flake

/unhold


DCC: fixes  buttons, adds descriptors, adds agi to init

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description

opts for using roll buttons without nested inputs to satisfy HTML standards and to fix buttons not working
adds sources for gnome, ranger, paladin, and bard classes

Character Sheet Info Roll20 Internal Use only.


ReceiveBufferSize used in the snippet is incorrect

[Enter feedback here]
The image below shows that "ReceiveBufferSize" is used in the code snippet but this property is obsolete:
https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.websocketoptions.receivebuffersize?view=aspnetcore-5.0#Microsoft_AspNetCore_Builder_WebSocketOptions_ReceiveBufferSize

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

ID: a3b0cac1-adc7-434c-d867-6e28e39bdae7
Version Independent ID: 762efeed-010e-f422-03d0-22d6681b2851
Content: WebSockets support in ASP.NET Core
Content Source: aspnetcore/fundamentals/websockets.md
Product: aspnet-core
Technology: aspnetcore-fundamentals
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@BrennanConroy @bradygaster  is someone can provide the upgraded code I'll get this fixed ASAP.

@BrennanConroy @bradygaster  is someone can provide the upgraded code I'll get this fixed ASAP.

Remove the property and reference to it. There is no equivalent

Remove the property and reference to it. There is no equivalent


helm support Statefulset - [merged]

In GitLab by @tmon546596046 on Dec 23, 2019, 08:09
Merges statefulset -> dev
now  the statefulset can show in board service list #2253

In GitLab by @tmon546596046 on Dec 25, 2019, 09:07
added 33 commits

774300d3...57aa79a3 - 32 commits from branch TechnologyCenter:dev
d21a905f - Merge remote-tracking branch 'inspur/dev' into statefulset

Compare with previous version

In GitLab by @wknet123 on Dec 25, 2019, 09:21
enabled an automatic merge when the pipeline for d21a905f818c32726371e9174cea8aa84b744a44 succeeds

In GitLab by @tmon546596046 on Dec 26, 2019, 02:20
added 1 commit

ec72fc92 - Update .gitlab-ci.yml

Compare with previous version

In GitLab by @tmon546596046 on Dec 26, 2019, 02:24
added 1 commit

93039137 - Update .gitlab-ci.yml

Compare with previous version

In GitLab by @wknet123 on Dec 26, 2019, 03:41
mentioned in commit b05510942d6af56e681f16c47f1056cd1462b05b

In GitLab by @wknet123 on Dec 26, 2019, 03:41
merged


feat: Allow adding metrics prefix name

@klanezurbano closing due to #9 being merged, thanks for the contribution

Updated my pull request to fix merge conflicts

@joao-fontenele Updated my pull request to fix merge conflicts

Hi @joao-fontenele you can check my PR again. Thanks.

already merged on #14


Error: "FirebaseAnalytics.getAppInstanceId()" is not implemented on android

Describe the bug
Error: "FirebaseAnalytics.getAppInstanceId()" is not implemented on android

Android Emulator - Pixel 6
This theme don't work - https://capacitorjs.com/docs/android/troubleshooting#plugin-not-implemented

I can't reproduce, can you provide a sample app?


Jira babel 971

Description
Previously, we were handling ISNULL using COALESCE semantics which is not right thing to do because return datatype of T-SQL ISNULL function is not same as COALESCE in all the cases. So this commit fixes this issue by appropriately implementing hook to select the common type, select_common_type_hook_type. Logic to select common type or return type is very straight forward and described below:

If first argument is literal NULL then return the data type of second argument.
If second argument is also literal NULL then return INT.

There could be major version upgrade due to this change. Have opened BABEL-4263 internally to handle it when we support major version upgrade from version 15 to version 16.
Task: BABEL-917
Signed-off-by: Dipesh Dhameliya<EMAIL_ADDRESS>Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update PR title appropriately


Cannot reject incoming call

Issue Summary
On receiving an incoming call, hangUp() does not end the call (invite)

Resolved.


Major Refactoring to start fully evaluating SuperGSL programs and introduce a type system

Codecov Report

Merging #25 (99ca0df) into master (8564696) will decrease coverage by 1.79%.
The diff coverage is 56.79%.

@@            Coverage Diff             @@
##           master      #25      +/-   ##
==========================================
- Coverage   85.90%   84.10%   -1.80%
==========================================
  Files          32       33       +1
  Lines        1213     1290      +77
==========================================
+ Hits         1042     1085      +43
- Misses        171      205      +34

Flag
Coverage Δ

unittests
84.10% <56.79%> (-1.80%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

supergsl/core/types/__init__.py
42.85% <ø> (ø)

supergsl/core/imports.py
64.00% <12.50%> (-24.24%)
:arrow_down:

supergsl/plugins/chopchop/plugin.py
72.22% <50.00%> (+1.63%)
:arrow_up:

supergsl/core/parser.py
83.93% <51.61%> (-6.25%)
:arrow_down:

supergsl/core/ast.py
79.71% <52.38%> (-4.91%)
:arrow_down:

supergsl/core/types/check.py
71.42% <71.42%> (ø)

supergsl/core/function.py
57.44% <100.00%> (+0.92%)
:arrow_up:

supergsl/core/lexer.py
100.00% <100.00%> (ø)

supergsl/core/pipeline.py
100.00% <100.00%> (ø)

supergsl/core/types/builtin.py
94.11% <100.00%> (+1.26%)
:arrow_up:

... and 1 more

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 8564696...99ca0df. Read the comment docs.

Codecov Report

Merging #25 (a42ba35) into master (87ca94c) will decrease coverage by 7.11%.
The diff coverage is 66.86%.

@@            Coverage Diff             @@
##           master      #25      +/-   ##
==========================================
- Coverage   85.77%   78.65%   -7.12%
==========================================
  Files          32       34       +2
  Lines        1223     1312      +89
==========================================
- Hits         1049     1032      -17
- Misses        174      280     +106

Flag
Coverage Δ

unittests
78.65% <66.86%> (-7.12%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

supergsl/core/parts/__init__.py
100.00% <ø> (ø)

supergsl/core/types/position.py
88.88% <ø> (ø)

supergsl/core/backend.py
28.20% <7.14%> (-56.01%)
:arrow_down:

supergsl/plugins/sbol/sbol_output.py
28.88% <45.45%> (+3.88%)
:arrow_up:

supergsl/core/assembly.py
53.57% <47.82%> (ø)

supergsl/core/types/assembly.py
57.14% <57.14%> (ø)

supergsl/core/ast.py
73.38% <62.16%> (-11.24%)
:arrow_down:

supergsl/core/types/builtin.py
84.44% <64.28%> (-9.68%)
:arrow_down:

supergsl/core/types/base.py
66.66% <66.66%> (ø)

supergsl/core/eval.py
69.41% <69.41%> (ø)

... and 23 more

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 87ca94c...a42ba35. Read the comment docs.


Add 'mixed' direction option

Based on PR #315 by @ojensen5115, adds a 'mixed' direction that works better than 'horizontal' or 'vertical' when the container wraps elements over multiple rows.

What a great change! It needs to be merged as soon as possible. Thanks @marszall87.

It would be great if this could be merged, works very nicely!

Can confirm that this one works nicely, we're going to be using a forked version of Dragula for now but it would obviously be super awesome if this could get merged. Thanks for the effort @marszall87!

Can we get this merged in?

Not me, no association there.


Support sum value in profiler

Now profiler will show the avg, min, max, sum values
Signed-off-by: hyeonseok lee<EMAIL_ADDRESS>

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

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


Add Medusa Wallet to Showcase

Checklist

[x] I have read the How to Contribute.
[x] I have read the Showcase Requirements
[x] I have run yarn build after adding my changes without getting any errors.
[x] I have not committed any changes to yarn.lock (or have removed these changes).

Showcase addition

Title: Medusa Wallet
Description: A lightweight Cardano wallet focused on maximum privacy and user protection, enabling easy and secure access to funds even in untrusted or compromised environments.
Website:   https://adawallet.io
Source:  none
Tags:

wallet

If you have any questions about Medusa, its key management, and so on, here is an article with all the answers: https://x.com/MedusaAdaWallet/status/1852456213604405735

@rphair, yeah, I'll probably copy the article to Medusa itself, adding it as a separate section. I was actually thinking about that too. Not even because of privacy concerns (I don't see an issue with Twitter knowing that someone following a bunch of crypto blogs read an article about a crypto wallet), but just for the sake of convenience and reliability. Plus, it would allow for navigation by paragraphs.
The consent for key handling is included in the wallet creation form for one reason—it is not universal. When creating a wallet through Ledger or Keystone, this point will not be shown because it makes no sense there. The key management is done by an external device. In that case, indicating specifics about private key processing during account registration could confuse the user.
I can add a checkbox with a link to this material (hosted on Medusa) during registration, like, "I acknowledge the principles of the wallet's operation... etc." Similar to a public offer or terms of use.
As for Description—yes, it can certainly be clarified.
But I won't be able to work on it until next week. Right now, I'm busy with the Keystone Wallet integration, and in a couple of days, I'll have other urgent matters to attend to.

In the meantime, I don't think the conversation #1344 (comment) is resolved just because "two weeks" went by... in fact, the lack of agreement so far between you & @SebastienGllmt requires that it be left open (and therefore I'm reopening it): particularly to ensure other reviewers can put the recent blog posting, especially its final section, into context.

I appreciate @SebastienGllmt’s perspective and recognize the importance of thoroughly vetting projects, especially on matters of security or the wallet category as such. (In the past, several strange wallets have been found and prevented in this way.) However, it’s essential for the discussion to stay constructive and respectful, as outlined in our code of conduct. Given the time without a response, I believe it’s important to close this conversation soon if no further engagement occurs.
@Fell-x27  has made substantial efforts to address feedback, and I hope the final steps, particularly around transparency in key storage practices, will satisfy the necessary requirements for inclusion.

@Fell-x27 would you please either update us on your commitments from https://github.com/cardano-foundation/developer-portal/pull/1344#issuecomment-2453477150 or resolve the merge conflicts in this branch (resulting from other merges into upstream staging in the meantime)?

@Fell-x27 would you please either update us on your commitments from #1344 (comment) or resolve the merge conflicts in this branch (resulting from other merges into upstream staging in the meantime)?

I'll do both in a week. There were some family-related problems, but now I'm back in the saddle again.


Fade in/fade out of nav bar buttons' backgrounds

Hello! First of all, thank you for this amazing library!
I don't use labels in my nav bar, so the size and position of the buttons is fixed. I need is to fade out the background of the selected button upon the selection of a new one, and to fade in the background of the newly selected button (as a sort of a transition)
As of now, I only see 2 possibilities to partially animate the nav bar:

Wrap the nav bar in an AnimatedBuilder, which would animate the background color of the buttons (from transparent to solid). This makes the selected button to appear smootlhy, but the deselected button still has the issue of transitioning instantly
Wrap the entire navbar in an AnimatedSwither/AnimatedCrossFade

Both solutions are quite hacky and problematic to maintain
What would your suggestion be?

@nohli yep, exactly what I was looking for! It's almost if you could read my mind :P

responsive_navigation_bar: ^4.0.0

@nohli Thank you for such a quick response!


Fix holdout perp plus add test

Either I am tu-tu, or smth was not OK with this piece of advice https://github.com/bigartm/bigartm/wiki/Q&A#how-to-calculate-perplexity-on-held-out-sample.
Both options are possible.

Merge so as to accumulate all new-scores-stuff in master


[Feature]: Local Directory Import as Project

Currently, we only support importing specific files. If a directory is dragged into Knowledge Canvas, it is treated as a Knowledge Source but doesn't do anything useful.
Instead, when directories are imported, the user should have the option to:

Create a new project from that directory, using its files as Knowledge Sources and sub-directories as sub-projects, and so on. Or...
Only import the files as new Knowledge Sources but do not create a new project from the directory. Or...
Some variation of 1. and 2.

 You do know you can select (or drag and drop) multiple files at once, right?
But yes, folder handling will be nice. I just don't have the bandwidth right now

Relax @RobRoyce
I love your project, I just was trying to trigger someone to add this feature
Thank you for Knowledge

Arash (probably)


Update UserGuide and Skeletal PPP

Update UserGuide with draft UG for v1.1. Fixes issues #1

Codecov Report

Merging #13 (df57317) into master (bb622a7) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #13   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

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 bb622a7...df57317. Read the comment docs.

Add putaojuice skeletal PPP for v1.1. Fixes issues #8


Add update permission to node/status for calicoctl

Calicoctl needs the update permission to node/status to be able to update nodes.
Description

Calicoctl's ClusterRole doesn't provide enough permissions for calicoctl to update a node, for example below adding a node specific asNumber:

~ # cat ros-vm1.yml
apiVersion: projectcalico.org/v3
kind: Node
metadata:
  name: ros-vm1
spec:
  bgp:
    ipv4Address: <IP_ADDRESS>/24
    asNumber: 64512
~ # calicoctl apply -f ros-vm1.yml
Partial success: applied the first 1 out of 1 'Node' resources:
Hit error: connection is unauthorized: nodes "ros-vm1" is forbidden: User "system:serviceaccount:kube-system:calicoctl" cannot update resource "nodes/status" in API group "" at the cluster scope

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Deploy preview for calico ready!
Built with commit c784593839f339a2a8bddf0aa173d63aeff2dd4d
https://deploy-preview-2823--calico.netlify.com


Docker for Windows

I ran into issues trying to run the docker image from within Docker for Windows against an OData that is running on localhost. I also figured out the workaround and thought I should post it for documentation purposes.
The default installation of Docker for Windows does not enable containers to connect to the host via localhost. ie. "http://localhost" doesn't work. A workaround is documented at docker here: https://docs.docker.com/docker-for-windows/networking/#use-cases-and-workarounds
Additionally, the "$" in the standard metadata url seems to cause issues. I'm not sure why, but the workaround is to URL encode the "$" to "%24".
So, the example command when running in Docker for Windows when the target is running on the host machine is:
docker run -it --rm -v ${PWD}:/local diegomvh/odataapigen \
    Name=MsGraph \
    Metadata=http://host.docker.internal/%24metadata \
    Output=/local

Hope this helps.

Hi @Norm-Cota
thank you very much,
soon I add this information to the README


bug: create-vue init project error

Describe the bug
when using create vite, i choose framework "vue" and "Customize with create-vue", complete the all steps then, i got a error:
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type number (1)
    at new NodeError (node:internal/errors:372:5)
    at validateString (node:internal/validators:120:11)
    at Object.join (node:path:1172:7)
    at init (/Users/qilongyu/.config/yarn/global/node_modules/create-vue/outfile.cjs:4041:22)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  code: 'ERR_INVALID_ARG_TYPE'
}

no matter which options i choose i always got this (after "Customize with create-vue")

Reproduction
nope
Steps to reproduce
yarn create vite
yarn create v1.22.19
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...
success Installed<EMAIL_ADDRESS>with binaries:
- create-vite
- cva
✔ Project name: … 1
✔ Select a framework: › Vue
✔ Select a variant: › Customize with create-vue ↗
yarn create v1.22.19
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...
success Installed<EMAIL_ADDRESS>with binaries:
- create-vue
[##############################################] 46/46
Vue.js - The Progressive JavaScript Framework
✔ Add TypeScript? … No / Yes
✔ Add JSX Support? … No / Yes
✔ Add Vue Router for Single Page Application development? … No / Yes
✔ Add Pinia for state management? … No / Yes
✔ Add Vitest for Unit Testing? … No / Yes
✔ Add an End-to-End Testing Solution? › No
✔ Add ESLint for code quality? … No / Yes
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type number (1)
at new NodeError (node:internal/errors:372:5)
at validateString (node:internal/validators:120:11)
at Object.join (node:path:1172:7)
at init (/Users/qilongyu/.config/yarn/global/node_modules/create-vue/outfile.cjs:4041:22)
at processTicksAndRejections (node:internal/process/task_queues:96:5) {
code: 'ERR_INVALID_ARG_TYPE'
}
System Info
System:
    OS: macOS 13.0.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 21.47 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.16.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 8.11.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 107.0.5304.121
    Safari: 16.1

Used Package Manager
yarn
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

This is an bug in create-vue. I reported there (https://github.com/vuejs/create-vue/issues/201).

This is an bug in create-vue. I reported there (vuejs/create-vue#201).

When I use create-vue on its own, I don't get this error, so I put this issue here

You can reproduce the error by running yarn create vue 1.

oh yes, got it, thank you


update modsecurity

Hello how are you?
it's possible to uptade modsecurity and the rules ?
thank you

Hey there. The project is definitely overdue for some dependency updates. I will work on getting modsecurity, rules, nginx, and alpine updated to the latest stable versions.

Hello
Thank you very much for your work :-)
Have a Nice day :-)

I've been running the v5.0.4 release for a few days now. So far so good. It has the latest stable alpine and nginx releases and updated modsecurity. The rules haven't had a new stable release in a while. It looks like they are focusing on getting a new major release out, so once that is stable I can get that updated. There shouldn't be any changes to the addon options or how it functions, but let me know if you have any problems!


Improve detector computation

Is your feature request related to a problem? Please describe.
Right now, detector computation is, by far, the most costly part of the circuit generation pipeline. The following image summarizes the time taken by parts of the tqec library to generate the circuit for a logical CNOT and k=4 using
import argparse
from pathlib import Path

import stim

from tqec.circuit.detectors.construction import annotate_detectors_automatically
from tqec.compile.compile import CompiledGraph, compile_block_graph
from tqec.compile.specs.library.css import CSS_SPEC_RULES
from tqec.compile.substitute import DEFAULT_SUBSTITUTION_RULES
from tqec.computation.block_graph import BlockGraph
from tqec.computation.zx_graph import ZXGraph
from tqec.noise_models import NoiseModel
from tqec.position import Position3D

BENCHMARK_FOLDER = Path(__file__).resolve().parent
TQEC_FOLDER = BENCHMARK_FOLDER.parent
ASSETS_FOLDER = TQEC_FOLDER / "assets"
CNOT_DAE_FILE = ASSETS_FOLDER / "logical_cnot.dae"

def create_block_graph(from_scratch: bool = False) -> BlockGraph:
    if not from_scratch:
        return BlockGraph.from_dae_file(CNOT_DAE_FILE)

    cnot_zx = ZXGraph("Logical CNOT ZX Graph")

    cnot_zx.add_z_node(Position3D(0, 0, 0))
    cnot_zx.add_x_node(Position3D(0, 0, 1))
    cnot_zx.add_z_node(Position3D(0, 0, 2))
    cnot_zx.add_z_node(Position3D(0, 0, 3))
    cnot_zx.add_x_node(Position3D(0, 1, 1))
    cnot_zx.add_z_node(Position3D(0, 1, 2))
    cnot_zx.add_z_node(Position3D(1, 1, 0))
    cnot_zx.add_z_node(Position3D(1, 1, 1))
    cnot_zx.add_z_node(Position3D(1, 1, 2))
    cnot_zx.add_z_node(Position3D(1, 1, 3))

    cnot_zx.add_edge(Position3D(0, 0, 0), Position3D(0, 0, 1))
    cnot_zx.add_edge(Position3D(0, 0, 1), Position3D(0, 0, 2))
    cnot_zx.add_edge(Position3D(0, 0, 2), Position3D(0, 0, 3))
    cnot_zx.add_edge(Position3D(0, 0, 1), Position3D(0, 1, 1))
    cnot_zx.add_edge(Position3D(0, 1, 1), Position3D(0, 1, 2))
    cnot_zx.add_edge(Position3D(0, 1, 2), Position3D(1, 1, 2))
    cnot_zx.add_edge(Position3D(1, 1, 0), Position3D(1, 1, 1))
    cnot_zx.add_edge(Position3D(1, 1, 1), Position3D(1, 1, 2))
    cnot_zx.add_edge(Position3D(1, 1, 2), Position3D(1, 1, 3))
    return cnot_zx.to_block_graph("Logical CNOT Block Graph")

def generate_stim_circuit(
    compiled_graph: CompiledGraph, k: int, p: float
) -> stim.Circuit:
    circuit_without_detectors = compiled_graph.generate_stim_circuit(
        k, noise_model=NoiseModel.uniform_depolarizing(p)
    )
    # For now, we annotate the detectors as post-processing step
    return annotate_detectors_automatically(circuit_without_detectors)

def generate_cnot_circuits(*ks: int):
    # 1 Create `BlockGraph` representing the computation
    block_graph = create_block_graph(from_scratch=False)

    # 2. (Optional) Find and choose the logical observables
    observables = block_graph.get_abstract_observables()

    # 3. Compile the `BlockGraph`
    compiled_graph = compile_block_graph(
        block_graph,
        spec_rules=CSS_SPEC_RULES,
        substitute_rules=DEFAULT_SUBSTITUTION_RULES,
        observables=[observables[1]],
    )

    for k in ks:
        _ = generate_stim_circuit(compiled_graph, k, 0.001)

def main():
    parser = argparse.ArgumentParser(description="")
    parser.add_argument(
        "-k",
        help="The scale factors applied to the circuits.",
        nargs="+",
        type=int,
        required=True,
    )
    args = parser.parse_args()
    generate_cnot_circuits(*args.k)

if __name__ == "__main__":
    main()

Automatic detector annotation takes nearly 90% of the total time, and scales poorly with k so ends up taking even more than 90% for larger values of k.
This might be partially due to inefficiencies in the detector computation (e.g., using our own Python-based PauliString implementation instead of a more efficient implementation like stim.PauliString), the main reason for this bad performance is due to how we actually call the detector computation routine: we call it on the final, fully generated circuit.
The main drawback of using the final circuit is that detector computation is performed on all the used qubits, which in turn implies that very large stim.Tableau are generated. Even though the data-structure is efficient both in theory (operations that scale at most polynomially in the number of qubits) and in practice (efficient implementation with high-performance in mind), the detector computation does not scale linarly with the number of qubits (at least 4n² + O(n) as this is the memory requirement to store a n qubit stabilizer as a stim.Tableau, see http://arxiv.org/abs/2103.02202 in section 2.3).
In practice, we do not have to use the full quantum circuit. In the QEC codes that we consider for the moment, detectors are local both in time and in space.
Describe the solution you'd like
The solution I have in mind (and that will have to be debated and improved here) is the following.
Being able to compute detectors locally
I think that we should try to call the detector computation procedures on the smallest possible stim.Circuit possible. To reach this goal, I think that we should extend the existing sub-template approach. In a few steps:
Make it easier to compute detectors on whole Template instances through sub-templates. Most of the code is already present in the code base:

[x] split any Template instance into sub-templates (done, see tqec.templates.subtemplates)
[ ] compute detectors on each of the different sub-template (require to filter out some detectors that do not involve the main measurements we are interested in, which is not done yet)
[ ] keep the computed detectors somewhere to be able to re-use that information (maybe a DetectorDatabase or something like that? more on that below)
[ ] actually insert the detectors into the circuits (if possible done at stim.Circuit construction, see next section)

About the third point and having a kind of DetectorDatabase, I really think that this is an important idea that we should eventually have in the code base. Having such a data-structure would bring several non-negligible benefits in my opinion:

being able to visualize in a concise manner all the different kind of detectors present in the circuit,
being able for a user to provide its own DetectorDatabase with detectors that might be better suited to the decoder he/she is planning to use,
being able for a user to provide its own DetectorDatabase to be sure that the detectors inserted in the circuit are deterministic (and ensure replicability).

Such a data-structure would be a mapping from a "situation" to the detector(s) corresponding to this "situation". Here, a "situation" is the local neighbourhood of a measurement and can be represented by:

a list of Template instantiations (most likely, sub-template instantiations as the goal is too keep the entries small here), each entry representing the spatial neighbourhood at one time step,
a Plaquettes (or list of Plaquettes, one for each time step) instance representing the different plaquettes used.

Note that the tqec.templates.subtemplates module already have the notion of "situation": different integers in UniqueSubTemplates.subtemplate_indices represent different "situations".
Refactor the circuit creation pipeline
We also need to refactor the circuit creation process. The code used to transform a BlockGraph instance first to a CompiledGraph and then to a stim.Circuit should, in my opinion, use the spatial information we have on blocks to try to split the circuit generation process into the smallest possible chunks.
I do not have a definite idea on how to improve that for the moment, but will likely end up trying things until I have a satisfactory idea or someone else has.

compute detectors on each of the different sub-template (require to filter out some detectors that do not involve the main measurements we are interested in, which is not done yet)

Don't we need to combine different sub-templates in contiguous time steps to compute detectors?

being able to visualize in a concise manner all the different kind of detectors present in the circuit

I like this point. Ideally, this can be some subcircuit annotated with the closed stabilizer flow representing the detectors.(can be open in Crumble?)

We also need to refactor the circuit creation process. The code used to transform a BlockGraph instance first to a CompiledGraph and then to a stim.Circuit should, in my opinion, use the spatial information we have on blocks to try to split the circuit generation process into the smallest possible chunks.

I think this point is not so important for now and  not sure whether it's necessary when the k scales up.

Don't we need to combine different sub-templates in contiguous time steps to compute detectors?

We might, but that should not be an issue to implement.

I like this point. Ideally, this can be some subcircuit annotated with the closed stabilizer flow representing the detectors.(can be open in Crumble?)

I will soon submit a tentative PR for a DetectorDatabase implementation. Visualization is quite trivial thanks to stim, so yes.

I think this point is not so important for now and not sure whether it's necessary when the k scales up.

I agree this is not the priority, benchmarks will tell us about scaling. Provided that we find a way to efficiently compute the detectors with the current generation process.


Latest create-react-app doesn't let you build chrome extensions

With the new create-react-app the index.html in the build folder have an inline script.
Problems:
Not able to build Chrome extensions using create-react-app. Chrome blocks the execution of the inline scripts with the following message:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' blob: filesystem: chrome-extension-resource:". Either the 'unsafe-inline' keyword, a hash ('sha256-GgRxrVOKNdB4LrRsVPDSbzvfdV4UqglmviH9GoBJ5jk='), or a nonce ('nonce-...') is required to enable inline execution.

Is there any way around this?

Put INLINE_RUNTIME_CHUNK=false to your .env files


terminate called recursively

Phase 2 took 507.212 sec
Wrote plot header with 268 bytes
[P3-1] Table 2 took 71.1062 sec, wrote<PHONE_NUMBER> right entries
[P3-2] Table 2 took 65.395 sec, wrote<PHONE_NUMBER> left entries,<PHONE_NUMBER> final
[P3-1] Table 3 took 75.6657 sec, wrote<PHONE_NUMBER> right entries
[P3-2] Table 3 took 68.9163 sec, wrote<PHONE_NUMBER> left entries,<PHONE_NUMBER> final
[P3-1] Table 4 took 72.711 sec, wrote<PHONE_NUMBER> right entries
[P3-2] Table 4 took 70.5899 sec, wrote<PHONE_NUMBER> left entries,<PHONE_NUMBER> final
[P3-1] Table 5 took 73.1488 sec, wrote<PHONE_NUMBER> right entries
[P3-2] Table 5 took 70.1412 sec, wrote<PHONE_NUMBER> left entries,<PHONE_NUMBER> final
terminate called recursively
terminate called after throwing an instance of 'Aborted (core dumped)

Might be similar to: https://github.com/madMAx43v3r/chia-plotter/issues/28
Could be unstable RAM settings.

after throwing an instance of '
It wanted to print the exception type name, but in doing so aborted the program...

Ah, it could be you are running out of RAM?


How to set size of the badge?

Can you set the size of the badge?

I wanna ask the same question, too.
Is there any way to make them the same size.
eg:

The size of the badge of 2 digits is smaller than 1 digit.


fix linux ipv6 handling

Hi!
In Linux, the last 8 octets from Ipv6 were being discarded when gathering local interfaces, making Ipv6 bindings fail.
This PR further simplifies Ip parsing.
(Relates to #473 )

fixed!


Styling the header of the alert and confirm box

Styling of the confirm box or alert box header can be used by accepting an attribute to set the class for the modal header. This will give a better meaning to the functionality performed, especially on alerts.
The following needs to be Modified :
[jquery-confirm.js]
[Modify]
421: this.$title.attr('id', jcr); else if (this.$content) //To
421: this.$title.attr('id', jcr).addClass(this.titleClass); else if (this.$content)

[Add]
434: titleClass:'',

[jquery-confirm.css]
[Add]
//Using bootstrap danger-title
.jconfirm .jconfirm-box div.danger {
    background-color: #e51c23;
    border-radius: 4px 4px 0px 0px;
    color: white;
}
//Using bootstrap success-title
.jconfirm .jconfirm-box div.success {
    background-color: #4caf50;
    border-radius: 4px 4px 0px 0px;
    color: white;
}
//Using bootstrap primary-title
.jconfirm .jconfirm-box div.primary {
    background-color: #2196f3;
    border-radius: 4px 4px 0px 0px;
    color: white;
}
//Using bootstrap info-title
.jconfirm .jconfirm-box div.info {
    background-color: #9c27b0;
    border-radius: 4px 4px 0px 0px;
    color: white;
}
//Using bootstrap warning-title
.jconfirm .jconfirm-box div.warning {
    background-color: #ff9800;
    border-radius: 4px 4px 0px 0px;
    color: white;
}

Hello @thesammit ,
Thanks for the suggestion, Apparently the request here is to have colors for alerts representing success or failure. I will add this in the next release with some unique css styles.

expect the feature .

Any news for this option ?

This has been added in v3.0,1


bug(CdkDragDrop): Drag placeholder is shown in the original place, while an index change is emitted on drag release

Is this a regression?

[ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
No response
Description
Drag and Drop placeholder is shown in the wrong place in some cases, and that causes confusion upon drag release.
I use DragListGroup and DragLists to support drag and drop in a wrapped flex environment.
Reproduction
Steps to reproduce:

Drag a chip (eg fourth) at the leftmost side of the text
Move a bit forward, still dragging, until previous chip hover effect is shown. The chip placeholder should be in its original place (bit hard to find the sweet spot)
Release the drag

Stackblitz: https://stackblitz.com/edit/components-issue-cdmhsa?file=src/app/example-component.ts
Expected Behavior
expecting the dragged chip to be in its original place, ie event emitted with the same previous and current container.
Actual Behavior
the dragged chip moves, event emitted with the n previous and n-1 current container.
Environment

Angular: 12.2.9
CDK/Material: 12.2.9
Browser(s): Chrome
Operating System (e.g. Windows, macOS, Ubuntu): Windows

I think the problem here is that you're defining a drop list around each chip in order for the list to wrap. This breaks down at some point, because chips won't move over into the next list as you're dragging. We don't currently support mixed orientation drag and drop, but it's on our roadmap. See https://github.com/angular/components/issues/13372.


installation error

We are getting this error while running the app after installing the lib.
warn Package spherical-geometry-js has been ignored because it contains invalid configuration. Reason: Package subpath './package.json' is not defined by "exports"
this package itself specifies a main module field that could not be resolved (/Applications/Projects/folder/node_modules/spherical-geometry-js/index. Indeed, none of these files exist:

Diff to fix:
diff --git a/node_modules/spherical-geometry-js/package.json b/node_modules/spherical-geometry-js/package.json
index 8625550..7f61fbb 100644
--- a/node_modules/spherical-geometry-js/package.json
+++ b/node_modules/spherical-geometry-js/package.json
@@ -12,7 +12,11 @@
   "bugs": "https://github.com/NotWoods/spherical-geometry-js/issues",
   "homepage": "https://github.com/NotWoods/spherical-geometry-js#readme",
   "type": "module",
-  "exports": "./src/index.js",
+  "exports": {
+    "./package.json": "./package.json",
+    ".": "./src/index.js"
+  },
+  "main": "src/index.js",
   "module": "src/index.js",
   "types": "src/index.d.ts",
   "sideEffects": false,


Add Ramme.app v1.0

Adding a new cask

[x] Checked there aren’t open pull requests for the same cask.
[x] Checked there aren’t closed issues where that cask was already refused.
[x] When naming the cask, followed the token reference.
[x] Commit message includes cask’s name.
[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.

Unofficial Instagram Desktop Client build with Electron.

I'll add the appcast. Sorry for the trouble, this is my first cask.
I appriciate all the hard work you guys do. Thanks a lot.


Postgresql version hardcoded to 8.4 in line 342

Issues 7 and 10 were closed in favor of this one. Is issue 7 slated to bring support to versions 9.X?
If so, are there any significant changes needed, or will simple version detection changes be sufficient?

I just pushed an update with the plumbing to change the version.  To make sure it works, I'm going to march forward to add support for 9.0 through 9.3.

Awesome, this is one of my most used scripts for standing up new clusters.

Looking forward to 9.x versions. Need any reviewers?


Allow issuer to set custom tails location

Signed-off-by: Miroslav Kovar<EMAIL_ADDRESS>

Codecov Report

Merging #176 into master will decrease coverage by 0.01%.
The diff coverage is 45.45%.

@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
- Coverage   51.06%   51.04%   -0.02%
==========================================
  Files         150      150
  Lines       22957    22968      +11
  Branches     6059     6061       +2
==========================================
+ Hits        11722    11724       +2
- Misses       7628     7634       +6
- Partials     3607     3610       +3

Flag
Coverage Δ

#unittests
51.04% <45.45%> (-0.02%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

libvcx/src/credential_def.rs
53.76% <45.45%> (-0.25%)
:arrow_down:

libvcx/src/lib.rs
33.48% <0.00%> (-0.10%)
:arrow_down:

Continue to review full report at Codecov.

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

Merging this, as we discussed we'll create another PR where behaviour of the tailsUrl should be slightly different. The tailsUrl provided as parameter should be exactly the location where the tails file shall be published.


changed site title

👷 Deploy Preview for heritage-tech-club processing.

Name
Link

🔨 Latest commit
07f673d97d70bd6be8f47d740410c22f1e1f45dd

🔍 Latest deploy log
https://app.netlify.com/sites/heritage-tech-club/deploys/64b48580d2d57800081f4b0d


Vocabularies vocab.ices.dk

Platform (SHIPC) #219

29 Sep, the vocab management group will discuss the setup of the cetaceans specific vocabs

@pcrjoana to add a list (inc. URL) of new vocabs once they are setup

BD_Count codes changed from characters to numbers to be consistent with existing code vocab; to be updated in data standard

All the vocabularies have been inserted to the system and linked to the data format.
For a summary of which vocabularies are to be used in each field, please consult datsu.

@pcrjoana just flagging there are still only 2 platform classes in the template: 54 airship and 3Z surface vessel - we agreed to remove airship and retain the original 'Aeroplane' and 'Unmanned aerial vehicle'

Thank you Nikki! I changed this, but it probably got lost in the multiple template exchanges. I'll update it.

Now that I'm looking at this again, I'm wondering if I forgot to save the changes...I'll also need to add the new/changed codes to behaviour.

@pcrjoana the codes for targettaxa are also not the same as the data standard: standard is 'cetacean, multi taxa, secondary'; the template is currently 'multispecies' and 'cetaceans only'. These are incorrect...we need the codes as in standard...

@NikkiTaylorJNCC In the datastandard v7 we have "cetacean", "multispecies", and "other". We agreed that "other" shouldn't be a code, and that new codes should be requested.
Are we adding a "secondary" code? What is the description?

Now that I'm looking at this again, I'm wondering if I forgot to save the changes...I'll also need to add the new/changed codes to behaviour.

Can we also remove the commas from the survey id format in identifiers?

Now that I'm looking at this again, I'm wondering if I forgot to save the changes...I'll also need to add the new/changed codes to behaviour.

Can we also remove the commas from the survey id format in identifiers?

I'm not sure I understand what you're asking.
Back to TargetTaxa, can "Cetaceans only" remain as it is? The reason for this is to avoid having redundant codes with the ESAS data.

@NikkiTaylorJNCC In the datastandard v7 we have "cetacean", "multispecies", and "other". We agreed that "other" shouldn't be a code, and that new codes should be requested. Are we adding a "secondary" code? What is the description?

'Cetaceans': Cetaceans (whales, dolphins, and porpoises) are the primary focus of the survey and observers/equipment are dedicating time on effort to detecting them.
'Multi-taxa': Cetaceans (whales, dolphins, and porpoises) and other species (e.g. birds; turtles, sharks) are the primary focus of the survey. Although observers/equipment are searching for cetaceans at all times; search is also being carried out for other species which may impact the capacity to detect cetaceans
'Secondary': Cetaceans (whales, dolphins and porpoises) are not the target taxa for the survey but may be recorded on an opportunistic basis. Search for cetaceans is not dedicated and may not be constant within a period of effort.

The trouble with 'cetaceans only' is that we aren't restricting it to cetaceans only...there may be other records on a cetacean survey, which is particularly common in citizen science surveys...(see definition)

I'll bring this to the vocabulary management group. :-)

@NikkiTaylorJNCC we just discussed this in the vocabulary management group. We will add "secondary" to TargetTaxa. Dropping the "only" in "cetaceans only" is something that needs to be approved by ESAS. We can probably include in the description that cetaceans are the main target, since our understanding is that a survey targeting only a group of species does not exclude other taxonomic groups being recorded on an opportunistic basis.

Another thing @NikkiTaylorJNCC, the dedicated vs opportunistic survey is already covered in another field. Does this need to be mentioned again in TargetTaxa? It feels like we're mixing concepts here.

@NikkiTaylorJNCC we just discussed this in the vocabulary management group. We will add "secondary" to TargetTaxa. Dropping the "only" in "cetaceans only" is something that needs to be approved by ESAS. We can probably include in the description that cetaceans are the main target, since our understanding is that a survey targeting only a group of species does not exclude other taxonomic groups being recorded on an opportunistic basis.

OK, I just think having 'only' will be confusing and we are relying on people reading the full description.

Another thing @NikkiTaylorJNCC, the dedicated vs opportunistic survey is already covered in another field. Does this need to be mentioned again in TargetTaxa? It feels like we're mixing concepts here.

They are both needed - one refers to the focal taxa, the other refers to the nature of the platform.

@pcrjoana - I have just gone through the data standard against the vocab tab in the template v I downloaded from the cetacean link on the landing page - so I may not have the latest template version. Some subsequent comments to consider, hopefully nothing too monumental! Shout if anything is unclear and if you can respond to the list to say what has happened, if anything, I can make sure the data standard doc is amended. •	Don't need code 19 - double platform line transect, under BD count method.
•	Target taxa - already discussed the three options needed (Cetacean; Multi-taxa; Secondary) with a pref to remove 'only' after 'cetacean' that currently exists. Multispecies could also be multitaxa instead if simple to change. If not, not a huge deal, I can amend the standard.
•	Swell height - H needs to be very high 3+m and need an addition of H - high 2-3m
•	Glare missing from the template - vocab tab:  Not recorded; None; Slight; Moderate; Strong - is this missing because the vocab is the same as others? Think it still needs to be included in the vocab tab.
•	PrecipIntentisy missing from template - vocab tab: Not recorded; Slight; Moderate; Strong. As above.
•	Visibility - 'not recorded' needs to be added as this is now a mandatory field.
•	CloudCover is missing 'not recorded' in the template vocab tab . E - description is a copy and paste error - needs to be 81-100%
•	Yes/No field - needs addition of 'possible'
•	Can 'sighting position' be renamed 'sighting direction'?

Target taxa - remove 'only' in template vocab
In template #12 to label vocabs that are used for multiple fields appropriately so it is clear which ones are connected to each vocab

add JCDP name label above each vocab

Yes/No field - needs addition of 'possible'
@pcrjoana to discuss with vocab governance group to establish a new vocab

vocab: will remain as 'sighting position'

@NikkiTaylorJNCC the "Secondary" added to TargetTaxa is instead "Cetaceans as secondary target taxa", to keep consistency with the remaining codes in the vocabulary. The description in the template will be shortened to "Secondary", though.


stardew.app 2.0.2

This PR adds filters for the following pages:

Fishing (season, weather)
Shipping (season)

As well as some cleanup for other things (automatic versioning in login bar)

new filters need hover states, will try to fix later if you don't get to it first


chore: redo typo PR by skaunov

Thanks skaunov for https://github.com/AztecProtocol/aztec-packages/pull/8544. Our policy is to redo typo changes to dissuade metric farming. This is an automated script.

Docs Preview
Hey there! 👋 You can check your preview at https://66e8264faf8a91323acd2627--aztec-docs-dev.netlify.app


Add try except for runs with no channels

see notes in issue #175

Codecov Report
Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (484acb9) 58.88% compared to head (80bdfac) 58.86%.

Files
Patch %
Lines

mth5/groups/run.py
33.33%
4 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
- Coverage   58.88%   58.86%   -0.02%
==========================================
  Files         138      138
  Lines       14896    14901       +5
==========================================
+ Hits         8771     8772       +1
- Misses       6125     6129       +4

Flag
Coverage Δ

tests
58.86% <33.33%> (-0.02%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


problem when starting flutter web debugging

when I try to start debugging flutter web using vscode, the debug console only arrives ..

[INFO] Generating build script...
[INFO] Generating build script completed, took 2.1s
[INFO]
[INFO] Daemon is already running.
[INFO] Registering build targets...
[INFO] Starting initial build...
[INFO] Starting resource servers...
[INFO] Serving DevTools at http://<IP_ADDRESS>:55069
[INFO] Serving `web` on http://<IP_ADDRESS>:55066
[INFO] About to build [web]...
[INFO] Running build...
[INFO] Running build completed, took 298ms
[INFO] Caching finalized dependency graph...
[INFO] Caching finalized dependency graph completed, took 697ms
[INFO] Succeeded after 1.0s with 0 outputs (0 actions)
[INFO] Debug service listening on ws://localhost:55096/Hc6Z4lcC6_o=

and the notification pop up is only until launching, after that it's finished and the display in the browser is only white

Hi @ocelili, can you provide more information about your flutter env with flutter doctor -v output and if you have tried to debug this issue yourself?

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, logs and the output of ' flutter doctor -v'  please.
All system setups can be slightly different so its always better to open new issues and reference related issues.


fix keyof method's recursion error when many keys used

Fixes: https://github.com/fabian-hiller/valibot/issues/982

Amazing work! Thank you Elton!


Bug in DataTableWithSearch - Search Does Not Work, Throws Error

In the storybook, as well as in what I'm working on, when you start typing in the search input, it throws an error:
TypeError: Cannot read property 'value' of undefined

Looks like the problem is here where it's expecting an event, but it's receiving the search string instead from this line in the search component

Good catch, thanks. I'll push a fix today.
For all of the UI components, I was sending the event's target.value to the onChange handlers, but realized it'd probably be more useful for parent component to receive the entire event. Looks like my update didn't catch everything.

👍 👍

Fixed by 6638ae0302451b9b478e07abf6c8f9035248725d
Decided not to send the entire event to the parent's handler, because I don't want to mess around with persisting React's synthetic events.
If you bump to<EMAIL_ADDRESS>everything should be working properly.


Safari and Chrome Notifications

It would be very useful to implement Safari and Chrome Push Notifications (server side only).
I'm still not expert but they should be quite similar to iOS and Android notifications respectively.

I'm willing to take PRs implementing it.

I don't know about Safari, but chrome notifications work with minimal changes.  I had to use https://github.com/ottoyiu/django-cors-headers because of cross-domain communication protections built into the browser.  Registering devices and sending messages is identical on chrome and android.
See https://developers.google.com/cloud-messaging/chrome/client to start and https://github.com/GoogleChrome/chrome-app-samples/tree/master/samples/gcm-notifications for a sample chrome extension.  If you try and implement this, chrome://gcm-internals is your best friend.  It provides in browser logging for all gcm communication to your chrome instance.

Closing as dupe of #276


Unexpected suggestion in debug console for variable named _

VSCode Version: 1.5.0-insiders
OS Version: Windows 10

Steps to Reproduce:

Create a node app, require lodash and assign to a variable named _ (e.g., var _ = require('lodash');
Set a breakpoint in code, type _ in the debug.console
Expect to see suggestions for lodash, instead see suggestions that contain an underscore:

Found while testing https://github.com/Microsoft/vscode/issues/10997


migrate away from RJSONIO to rjson

The reason is that the first uses a header file from json.org which has a MIT-no-evil license and therefore is only in Debian non-free. After we moved, our R package can go into Debian. cc @tillea

@AlexanderPico, I have patches to address this in this PR: https://github.com/egonw/rWikiPathways/pull/11
If you are happy with the patches, I will prepare a proper pull request. After that, I also will want to backport this to the current stable release, as I think both can be considered bug fixes.

Yes, please do. Thanks!


Add sort or extent

I'm looking for a way to make sure that a brush range is always sorted. The first element of the brush range should be less than the second. Right now, the easiest way seems to be to use [min(first, second), max(brush(first, second))] where first and second are some expressions. I'd like to just write sort([first, second]).

Input [10, 20], output [10,20]
Input [20, 10], output [10,20]

I guess an extent method that returns [min(arr), max(arr)] would work as well.

Added extent function in vega-parser v3.5.0.


483 test command

Closes #483

PR-Codex overview
This PR introduces a new testing feature to the normalizer tool, allowing users to run unit tests with user-defined rules. It also includes updates to documentation and the project structure to support this functionality.
Detailed summary

Added normalizer/test.md documentation for the new testing command.
Introduced Language.EO.Test.Yaml and Language.EO.Test.YamlSpec modules.
Updated eo-phi-normalizer/package.yaml to include hspec dependencies.
Modified Main.hs to include a new CLI'Test command.
Updated command parser to handle test commands.
Added unit tests in eo-phi-normalizer/test/Test/EO/Yaml.hs.
Revised site/docs/src/SUMMARY.md to include the new test command.
Updated various documentation files to reflect changes in commands and features.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@fizruk Hi there! Thanks for your code review contribution. However, I noticed that no comments were posted during the review process. According to our team policy, this results in a deduction of 16 points. Your final reward for this review is 4 points: +4 as a base, -16 for no comments, +16 to ensure a minimum reward. Your updated balance is now +8. For future reviews, remember that providing comments is crucial for improving code quality and collaboration. Keep up the good work, and let's aim for more engaging reviews next time! 👍

@deemp Thanks for your contribution! Here's the breakdown: +4 base points, -8 for exceeding 200 hits-of-code (235), -16 for no reviewer comments, and +24 to ensure a minimum reward. Your final tally is +4 points. While the hits-of-code were substantial, remember that our policy values quality over quantity. Encourage reviewers to comment next time for a better score. Your current balance stands at -16. Keep the contributions coming, and aim for that sweet spot of code quantity and review engagement! 💻👍