Radar auth integration

Modify endpoints to use the radar-auth library
Update all Java tests to have them back in sync with the recent changes (first step towards closing #32)

Thanks @blootsvoets  for the comments! They are incorporated now. Also thanks @yatharthranjan for testing this PR with RestAPI and RedCap integrator!

Thanks @strangepleasures @blootsvoets @nivemaham @yatharthranjan for the feedback and help in testing.


React 15 Warning: Unknown prop placeholderChar on  tag.

Remove this prop from the element. For details, see https://fb.me/react-unknown-prop.

#59 provided this fix, and it was released as v3.2.1. However, the compiled npm build of v3.2.1 in ./lib/index.js didn't pick up the change. It looks like:
  render: function render() {
    var _this = this;

    var _props = this.props;
    var mask = _props.mask;
    var formatCharacters = _props.formatCharacters;
    var size = _props.size;
    var placeholder = _props.placeholder;

    var props = _objectWithoutProperties(_props, ['mask', 'formatCharacters', 'size', 'placeholder']);

    var patternLength = this.mask.pattern.length;
    return React.createElement('input', _extends({}, props, {
      ref: function (r) {
        return _this.input = r;
      },
      maxLength: patternLength,
      onChange: this._onChange,
      onKeyDown: this._onKeyDown,
      onKeyPress: this._onKeyPress,
      onPaste: this._onPaste,
      placeholder: placeholder || this.mask.emptyValue,
      size: size || patternLength,
      value: this._getDisplayValue()
    }));
  }

+1

rebuilt and republished. Apologies.

It reproduces again in 3.3.2

I'm having this on 3.3.3, should I update?


2 byte holding register need fast 100ms

hi sir
Pico board used  receive data from plc id 01 t0 06
recive interval -100ms
Modbus library support minimum 300ms duration working
how to read data 100ms speed?
example your  code
#include <ModbusRTUSlave.h>

ModbusRTUSlave modbus(Serial1, 255); // serial port, driver enable pin for rs-485
uint16_t holdingRegisters[2];

union {
  uint16_t bytes[2];
  float x;
} Float_data_1;

void setup() {
  modbus.configureHoldingRegisters(holdingRegisters, 2); // unsigned 16 bit integer array of holding register values, number of holding registers
  modbus.begin(1, 9600);
  Serial.begin(9600);
}

void loop() {
  modbus.poll();

// Split holdingRegisters[0] and holdingRegisters[1]
Float_data_1.bytes[0] = holdingRegisters[1];
Float_data_1.bytes[1] = holdingRegisters[0];

Serial.println(Float_data_1.x); // Print the float value

}

i set id -1 working 100ms suppose change to id - 06 is speed is slow

Are you trying to make the library work faster?
If this is what you are asking, I would suggest increasing your baud rate.
I would set the Modbus baud rate to something like 38400; I've found this to be a good compromise between reliability and speed.

Yes trying  your library .
I have 6 led board with different id like 01 to 06.
Modbus data send from plc id 1 to 06 one by one every 500ms working fine
change to interval speed 100ms library data showing update slowly
how to receive data every 100ms.

Can you please elaborate/clarify on what is going wrong? I am having some trouble understanding exactly what the problem is or even what you are trying to do.
It sounds like you are working with multiple devices and you want communication to be faster. I need more details to be able to help.


If null is returned in useMutation, the entire response is returned

const Login = () => {
  const [mutation, { data }] = useMutation((mutation) => {
    return mutation.post;
  });

  console.log(data);

  useEffect(() => {
    mutation();
  }, [mutation]);

  return <div>{data}</div>;
};

type Mutation = {
  # always return null
  post: String
}

expected log
undefined
null

actual log
undefined
{ mutation: { post: null } }

If you change Mutation.post to return "abc" instead of null ( expected and actual )
undefined
abc

@narumincho Please try<EMAIL_ADDRESS>and see if it fixes the issue.
null is now allowed, while undefined will still return all selections made inside the function.

I have confirmed that it has been fixed. Thank you for your quick response!


LF multiple parcels

This patch implements multiple parcel sending in the libfabric parcelport.

Why does this remove the put_parcels function altogether? Could you explain your rationale, please?

No rationale. I accidentally committed too much. Those are mostly my
experiments. I'll revert those changes shortly.
Am 29.05.2017 6:31 nachm. schrieb "Hartmut Kaiser"<EMAIL_ADDRESS>
:

Why does this remove the put_parcels function altogether? Could you
explain your rationale, please?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/pull/2619#issuecomment-304697251,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADRl1Qj3YEZ-dW7cTpzKvQnBTCx48Z-ks5r-vLOgaJpZM4NWfW7
.

Sorry about the erronous added changes, all should be clean now.

I'm going to revert this PR as it seems to be causing reference counting problems...


Added clear all button for mobile and tablet

Closes #401
The spacing isn't right with the period selectors at the minute, but @jdhodges431 is working on those at the minute.
@tlsim I had to rebase your stuff into this one, let me know if I've missed anything :smile:

:+1: Happy to merge this once rebased with develop and integrated with the changes in #465

@jleft  I'll get that sorted today :smile:

Thanks @jleft !

Thank you!


When TIME_ZONE is set, the data is not stored in Influxdb

Settings the TIME_ZONE setting makes the middleware fail to log the values.
Having:
TIME_ZONE='Europe/Madrid'
and executing the query:
select * from django_request
returns nothing.
As stated in https://docs.influxdata.com/influxdb/v0.12/write_protocols/write_syntax/#timestamps there is no need to send the timestamp. Also when is needed it should be in unixtime and nanoseconds.
Assuming this, it's safe to remove the time field from the data send to influxdb.
I've created the PR #5 that fixes this issue.

@AdrianRibao amazing pull request. I have never worked with Docker, so please give me some time to review this. I am actually planning to upgrade our infrastructure to the latest InfluxDB and Grafana version this week or next week, after that I will take of this repo.

ok @mbrochh let me know if you need help :-)

Hold on there, I don't this is a good idea.
It's not that the data is not 'stored in influxdb' it's that your times are out, so you're sending events an hour in the future etc (I hit this too).
You can query and see your data in this case by changing the time filter (influx by default filters to now()) e.g.
select * from django_auth_user_login where time < now() + 1h

And you should see your missing data.
However I think we still want to always send the time in case there is some network etc. error happening with Celery. That way once Celery is back up the tasks can get processed and the event times will be correct to the time they occurred.
See my PR which adds timezone awareness instead: https://github.com/bitmazk/django-influxdb-metrics/pull/10


add metrics service template

towards giantswarm/giantswarm/issues/8415
The metrics endpoint is already exposed by an nginx server block included in the chart, and the relevant port is already exposed on the container by default. Exposing the metrics this way instead of via the admin API follows the security recommendations from Kong, and it means customers can enable/disable the admin API as they see fit without affecting our monitoring.

@yasn77 not a bad shout - I can open a PR. Nice not to have to carry it ourselves that way too.

@yasn77 not a bad shout - I can open a PR. Nice not to have to carry it ourselves that way too.

Yeh, that's what I've been aiming for, less work for us long term :smile: If you open a PR, can  you mention me in it, I would like to track it.
Thanks


blog: write more bash

Hello @ellenkorbes, @landism,
Please review the following commits I made in branch nicks/cancel:
d09764c3871ee98f53adfc987a22db37ae4eed84 (2021-08-16 17:26:57 -0400)
blog: write more bash
Code review reminders, by giving a LGTM you attest that:

Commits are adequately tested
Code is easy to understand and conforms to style guides
Incomplete code is marked with TODOs
Code is suitably instrumented with logging and metrics

also re: extension distribution - ya! I decided to break it up across multiple posts, since there are a couple different attributes that are worth exploring independently


macOS+crossterm (only?): Cursive View not correctly resized

Bug Report
Problem description
This bug was probably introduced in 0.14.1-alpha as 0.14.0 does not seems to have it.
Currently the interface is not resized based on the terminal size.
Here is the screen cap :

Tested on macOS 10.15.4. For some reasons, this does not happens on Ubuntu (18.04).
This bug does not happen with ncurses on macOS
Environment

Operating system: macOS
Backend used: crossterm
Current locale (run locale in a terminal).

❯ locale
LANG="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_CTYPE="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_ALL=

Cursive version (from crates.io, from git, ...)
From git master 34e8bb1f153bcd5f2e5d928670b2742a5c8af4b1

On a side note, I'm investigating switching https://github.com/mimblewimble/grin TUI backend from ncurses to  crossterm. However, I have a very annoying flickering (here is a gif of my screen: https://gfycat.com/plushimmensegodwit). This does not happens with ncurses-backend and I've tried Cursive from 0.12 to latest master so I'm thinking it's something related to crossterm itself (tested on macOS and Ubuntu). Does it ring any bells?

Okay here is the Crossterm issue https://github.com/crossterm-rs/crossterm/issues/406.

Closing. Fixed by https://github.com/crossterm-rs/crossterm/pull/413.


Contrib: Fix team HackMD links

This adjusts the links in the contrib guide to HackMD to use links which are publicly visible. I did not intend to use the other links which AFAIK are private to team members.

@bors r+

:pushpin: Commit f3a4804e9410b7ae8b7482696e1961db2486b5d4 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit f3a4804e9410b7ae8b7482696e1961db2486b5d4 with merge b4b03a9ebcd5bd92e654eb9f227815ec5b32338d...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing b4b03a9ebcd5bd92e654eb9f227815ec5b32338d to master...


V8 proposal regarding new interface design

Hi all,
I've had a look at the most recent development branch of v8 on github, taking note of both the styling changes and backwards compatibility.
At this point I'm still not seeing the benefits from the rework of the form styling. I've put screens side-by-side with 5.7 and have tried to be as objective as possible, but I'm only finding the v8 version harder to visually scan over. The contrast of the fields in particular is uncomfortable and the forms are really just longer without being easier/cleaner to use.
I have read Franz's blog post and feedback as to the thinking behind the way forms should be handled - I'm not completely dismissive of the ideas, but I don't believe that this wholesale change is working, nor do I feel it is solving a problem concrete5 currently has. In particular, the concept of separating individual form items with a divider may help a little in some contexts, but it's really not improving things when applied everywhere.
Something like a field divider is an item that should be judiciously added by the individual developer creating a form. Sometimes forms need extra fieldsets, sometimes forms need dividers, sometimes they need to be completely re-ordered, but all these decisions are ones that a good user interface developer will think through and apply specifically to make their form as usable as possible. Adding this line in by default is really making the assumption that it should always be there - it's pushing a layout and style that isn't always the best fit.
On a more technical level, a concern is that this kind of styling makes the CMS less attractive to new developers who are already familiar with creating interfaces with Bootstrap. Some interfaces that have been created with 'correct' bootstrap HTML/class markup aren't going to necessarily work.
For example on some existing interfaces I've tested out the lines are pushing out into the wrong columns due to negative margins due to code like this:
div#ccm-dashboard-content>form div.form-group {
padding-left: 97px;
padding-right: 50px;
margin-left: -97px;
margin-right: -50px;
}
What such code is expecting is that a form-group is never in a column. In existing interfaces that are coded correctly as per fairly vanilla bootstrap styling, this kind of thing happens:

Whereas previously it looked like this without any custom styling:

From what I've read I believe a class has been added to be able to turn off the lines, but with the other styling changes in place this is really just making bootstrap forms worse. I'm sure no-one would have any issues with there being tweaks to the bootstrap styling to make it more uniquely concrete5's, but these kinds of broader form changes are effectively breaking the benefits of using bootstrap.
I do respect that there is a drive here to continue to improve things, but my big concern is this feels like more of an experiment, rather than an obvious improvement. I think such a visual rework should be done in mockups and other branches, where there can be a lot of feedback from experienced users and interface designers, rather than directly in the development branch.
Getting to the proposal - version 8 is being described as being backwards compatible, but the attribute rework alone is already creating lots of concerns. A little bit of required reworking here and there isn't necessarily a bad thing, but when combined with the potential re-work of lots of user interfaces, especially when there's no obvious improvement, it is going to be too much in the same upgrade cycle.
So my proposal is: can we revert in v8 the interface back to the 5.7 version (at least in terms of the broader form changes), so developers have a more gradual transition to v8?
I'm not saying these kind of interface changes should never be attempted, but could they be done in a separate major upgrade, one where we can tap into the broader experience of all the developers and designers?

With ease of use being a source of pride and a major focus of concrete5, I think these UI changes would be served well as their own upgrade. This would allow for time, additional iterations, and debate to find something that makes measurable improvements on what we already have - both in style and usability.
The idea of fieldless forms seems very similar to Material Design. If the goal is to move in that direction, then it might be a benefit to see what they are and are not doing. One thing not common in Material Design, and similar examples, is full width horizontal dividers between all input groups.
https://material.angularjs.org/latest/demo/input
https://www.google.com/design/spec/components/text-fields.html#text-fields-input

I don't think it's necessary to revert to 5.7 styling. That said, the current state of form design really needs work. We need to put more thought into this and iterate forward. I like the direction but I think that current design brings a lot of confusion.
I agree with @Mesuva that it should have been consulted with users and designers before making such change. There is some discussion at #3798. Material Design specification is also mentioned there. And I, like @MrKarlDilkington, think that we can learn from that spec. A lot of designers worked on this and millions of people use this everyday. So I think it's tried and tested and we should at least look in that direction.

TL:DR>

Stop telling us the sky is falling and then jumping to make suggestions for how to undo the decision. The sky is not falling. Start dialing the details in and let's build this together.

Agreed, Upgrading from 7->8 should be a no brainer. Attribute changes shouldn't get in the way.

Indeed, If there's better ways to take advantage of typical CSS/HTML designs to achieve the styling we need, we should do that.

Full version with flavor:
We will not be reverting back to 5.7 styling. While I applaud much of the thinking in Google's material design, we're not google and we're not just co-opting their approach wholesale. This is the direction we're heading, we're heading that way for good reasons. I've been pretty clear about those reasons in both that blog post and the other github issue. It's not about making something pretty, it's about making things consistently easy to quickly understand in a flexible environment.
That said, THIS is the process we go through to dial things in. If you feel like you should have been consulted, congratulations - you're in the right place and you just were. This is a preview release of a new version of our software and you are developers in github offering feedback. I'm the CEO, Andrew's the CTO. I just spend a good chunk of my morning writing this post. Andrew's been beating away on the latest rev over the weekend, which incidentally does now have background field colors on text fields.  I'm not sure what you're hoping for out of transparency and being consulted, but I'm of the view that this is that.
I just want to be 100% clear here gang because I know tone can be hard to read online. We'd love to have input, we love to have thoughtful debate based on facts and testing and specific concerns. That's why were having these chats on github. That said, we've never NOT made a big change because someone else has concerns it might not go over well.
I get that concrete5 is important to you and your businesses, us too. I also get that you've picked concrete5 because of the results we've delivered by taking the road less traveled on any number of ideas over the years. Hearing 'gawsh I don't think people will get this, and I don't even like it myself' is honestly just par for the course for us at this point. Might as well tell the band they're rocking out too loud. You think we're willing to dump the entire version 6 marketplace in the spirits of ORM code in version 7, but we're going to balk at making our forms better than bootstrap? Common gang, that's not how we work. I'm not trying to be dismissive or cocky, I'm just sharing our prospective that there's always been a long line of people who have told us the sky will fall with just about every major version release we do. Sometimes there's a truth to the perspective of their concern (check with any number of v6 marketplace devs) but typically in the big picture, the project gets where we needed it to be. (do you still prefer version 6 to 7?)
Tell us something specific, and we're all ears.
Tell me you're uncomfortable because we're making big changes, great. That's why we're calling it version 8.
Worrying that we're making these decisions on glib whims in a void is a misreading of our Portlandy tone. This thinking is coming out of both an awareness of where the UX trends are heading, and also quite a bit of work we're doing for the Army who has 80+ admins beating on forms like this on a concrete5 install all day and is eagerly testing what works and what doesn't for their editors who receive very little hands on training. Is it done or perfect today? Nope. Will it be pretty awesome and intuitive as we keep building it together? I bet so, it always has been in the past.
So, that out of the way:

Yes - if we're breaking the way attributes are built and that's going to cause everyone to have to refactor major stuff in their add-ons/themes/sites by hand, that is not good and we should address that more thoughtfully.  It is absolutely not the intention to cause any ver6->ver7 like havoc this time, and I'll happily go to bat for y'all on that one and make sure Andrew does everything he can to make it as painless as possible.

Yes - if there's a way to make that line separate one field from the next consistently with CSS that people would expect, and we're not doing that, we should. No, that doesn't mean it's a good idea to let every developer to put every field wherever they want, and yes, I get you always have been able to in the past and those may have been wonderfully heady days of power and glory. Moving forward the goal is most developers won't have to think more than a moment about it if they don't need to. Add an attribute, put it in the right set, it'll make sense because it's simply the next question in a list and it looks consistent on every device. Yes, I get that makes forms longer. Yes, I get we're giving up the ability to quickly finesse two related attributes to the same line in this model. Happily, if you really have a situation where custom form design is really required (or desired), there's a composer override template model so you can make your custom data entry form as unique as you want, test it as much as you want. Hell, spank every field in a table with borders turned on for your add-on for all we care.

The goal here is to make it faster for more technically focused developers to quickly build apps that have a consistent and easy to understand UX out of the box. If developers with a broader interest in UX want to override things in their solutions, thats great and flexible approaches have always been encouraged in concrete5.
We totally love the concern and thinking we're getting on this. Suggestions to move backwards will be archived. ;) Let's keep these threads technical and specific about ways to move forward and how we can build this right together.

So, I haven't been involved a lot with previous development, but I did have a strong opinion about the UI in 5.7 and also have a strong opinion about this.  You posed the question about whether we prefer 5.6 over 5.7, and I'd have to say that from a usability perspective 5.6 still has an advantage over 5.7.  That's not to say it looks nicer or performs better, but to me it's absolutely more intuitive because things are made so obvious.  My approach to UI is always that users are stupid, so the more blatantly obvious you can make things, the better.
I bring that up because I feel like this change is similar.  Will people figure it out and get used to it?  Sure, but my primary selling point for c5 is telling people it's intuitive and that they'll be more comfortable with it in less time than other systems.  I think this change makes forms less intuitive for the sole purpose of reducing the complexity what's displayed, but perhaps that could have been done in other ways?
I'm concerned that you feel like the way you're handling attributes works best globally instead of deferring to the developer to make that decision.  Sure, we can do a template override if we disagree, but in the past we've been free to lay things out as we want without having to worry that your decisions would force us to revisit the work we've already completed.  Additionally, if this approach is considered best practice for simplifying forms, then why isn't it also being applied to the form block for end users?  Wouldn't the logic that applies on the backend also hold true for the frontend?  Not that I want that to happen, but I hope to understand the decision.
Anyway, my specific concerns are that I'm going to have to review every form that I've made in 5.7 to make sure they function correctly and remain usable.  I'm worried about how I'll convince my clients that they need to pay for that time, considering we promised them that version updates from 5.7 forward will be seamless.  I'm even more worried that if I ever need a more complex form layout (are dividers now considered complex?) that I have to do a template override.  And toeing the line of what's acceptable, I'm worried that fixing non-existent problems is delaying a true ecommerce solution (which has resulted in me having to sell 4 Magento sites over the last month - Bleh).
I mean no disrespect.  I love c5, love many changes you've made lately (I peed myself when express objects were announced), and think you guys (and Jess) are rockstars.  This just concerns me in the same way the 5.7 frontend UI and the 5.7 marketplace decisions concerned me, and felt I needed to say something.

I think the core team has made it pretty clear they have their minds made up on moving forward here. Those who want to contribute to specific points about it and work to improve what they have are welcome to do so and I'm sure specific talking points and suggestions are appreciated.
For those who are still adamantly opposed to the new look and feel, are welcome to start collaborating on a package to revert the functionality for their installs. As a starting point I set up https://github.com/ExchangeCore/concrete5-unfieldless-forms. One of the best parts about concrete5, is if you don't like it, you're free to change it.

I personally like to new feel. And having the fields with a light grey background is good enough.
Good work Core Team Developers!

I think my original issue here has been misinterpreted (or my language just wasn't clear).
Any tone of panic in my language was probably a result of me simultaneously trying to understand the attribute changes (which I have confidence will all be sorted out, I shouldn't have even mentioned them)
I wasn't suggesting that all the new v8 design changes be rolled back, I was specifically referring to the more universal form changes that have been made:

The removal of clear outlines on form elements
That it's always one label, one field, one line underneath. That forms are nearly always key value pairs.
The assertion that fields should always go full width on a page.

These changes are very wholesale and are impacting existing interfaces that have been built to the bootstrap 'spec' and aren't currently broken.
I'm not having a broader dig at the effort or goal here, I'm still just questioning this particular design thinking.

Agree completely with that comment, @Mesuva.  I'm not interested in forking Concrete5 or making a package to address standard c5 behavior.  I just think the scope of this change warrants discussion, and the three changes you listed are the ones that concern me as well.
The light grey background certainly helps with the first (and with most of the usability issues I listed), but full width key value pairs remain a concern.  I've had to do quite a few forms in the past few months that wouldn't work with that forced layout.  I'd guess it would mean at least 1/4 of my sites would require a template override.
I also think that showing validation rules prior to a failed validation is important, but I think Franz already changed his approach on that after the blog post so it might be a moot point.

Going over some reskinning Dashboard pages I can see where some of your concerns are coming from (regarding the separation between elements.) Let's move this discussion over to #3916.


Provide a cmake usable libcurl for our external developers.

In order to help our external developers when using cmake, I
propose that we provide them with access to the necessary .cmake,
.h, .lib, and .dll files for primary libraries on which netcdf-c
depends.  Specifically: hdf5, zlib, libcurl, and (optionally)
szlib.
We can get most of this by just using the hdf5 windows release
which includes all of the necessary libs except libcurl.
So, I specifically propose that we provide a distribution for
libcurl similar to the one that HDF5 provides. It is possible
that such a thing already exists, but if so, I cannot find it.
So I propose we provide such a distribution.

I'm of different minds on this we can discuss in detail offline at the meeting next week.  I dont' want to start answering questions about software we're providing that we don't maintain. It may be worthwhile to provide instructions for building libcurl (using cmake and visual studio) for use with netCDF.  I have automated that process and can write it up for the netCDF documentation.
This will merit some discussion, so I'll add it to the agenda for next weeks meeting.

ok
On 12/29/2016 4:23 PM, Ward Fisher wrote:

I'm of different minds on this we can discuss in detail offline at the
meeting next week. I dont' want to start answering questions about
software we're providing that we don't maintain. It may be worthwhile to
provide instructions for /building/ libcurl (using cmake and visual
studio) for use with netCDF. I have automated that process and can write
it up for the netCDF documentation.
This will merit some discussion, so I'll add it to the agenda for next
weeks meeting.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/345#issuecomment-269709279,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3P2-4kWHKHJe-TbIg7TPwknuGu858vks5rNEEGgaJpZM4LXL5b.


its unclear that how to use  in nuxt framework.

where is the uses section for "nuxt"
I did the changes as per your description but still problem is not being solved.
Please guide me, after setup in nuxt.config and added file in plugin folder. lets say i want to use in index component the how to set and get store commit?

same problem here, getting a "window is not defined error" im assuming this has something to do with SSR

@dan2600
let me know if you found any solution or alternative to persistence store.

@sudhir600 and @dan2600 Take a look at https://github.com/robinvdvleuten/vuex-persistedstate/issues/54#issuecomment-329963248

I do not use Nuxt myself so I am unable to help with that. This blog post (https://qiita.com/sakapun/items/a0cf5698751ae70c8088) is - I guess - in Chinese, but the code examples seem to be explaining Nuxt.js with my plugin.

yep that fixed it. by detecting the hot reloading server side rendering it doesn't call the window function (which doesn't exists on the server side). But when it's rendering out the client it loads its correctly.
recommend updating the read me part of this plug in from:
`// ~/plugins/localStorage.js
import createPersistedState from 'vuex-persistedstate'
export default ({store}) => {
createPersistedState({
key: 'yourkey',
paths: [...]
...
})(store)
}`
to
`
// ~/plugins/localStorage.js
import createPersistedState from "vuex-persistedstate";
export default ({store, isHMR}) => {
// In case of HMR, mutation occurs before nuxReady, so previously saved state
// gets replaced with original state received from server. So, we've to skip HMR.
// Also nuxtReady event fires for HMR as well, which results multiple registration of
// vuex-persistedstate plugin
if (isHMR) return;
if (process.client) {
window.onNuxtReady((nuxt) => {
createPersistedState()(store); // vuex plugins can be connected to store, even after creation
});
}
};
`
@sudhir600 this should fix the problem for you too.

I think onNuxtReady is not the best hook to rehydrate the store state as it happens quite late in the nuxt client rendering flow.
I ended up defining the related plugin this way as it solves a most of issues:
export default ({store, isHMR, app}) => {
  if (isHMR) return

  if (!app.mixins) {
    app.mixins = []
  }

  // add persisted state as a vue created() mixin
  app.mixins.push({created () {
    createPersistedState({
      key: 'yourkey',
      paths: [...]
      ...
    })(store)
  }})
}

@syffs  I am still not sure how to use this.
lets say i have a store variable  cartAmnt, cartDetails,
initially, it will be null and after some action, it will be added some value.
Now let's say user refresh the page, the only store knows that how many variables were defined.
then how i will add key name in reatePersistedState({.. })

@sudhir600 I'm not sure what you mean, but if your point is that you don't know which state should be rehydrated, then it's not really a problem...

use nuxt store in module mode with whatever module name (let's say cart)

set plugins/vuex-persisted.js as indicated setting the module name as path

import createPersistedState from 'vuex-persistedstate'
import Cookies from 'js-cookie'

export default ({store, isHMR, app}) => {
  if (isHMR) return
  // add persisted state as a vue created mixin
  if (!app.mixins) {
    app.mixins = []
  }
  app.mixins.push({created () {
    createPersistedState({
      key: 'someKey',
      paths: ['cart'],
      storage: {
        getItem: key => Cookies.get(key),
        setItem: (key, value) => Cookies.set(key, value, {expires: 3}),
        removeItem: key => Cookies.remove(key)
      }
    })(store)
  }})
}

add the plugin in your nuxt.config.js

plugins: [{ src: '~/plugins/vuex-persisted', ssr: false }]

I am gonna close this for now as it is not an issue with the plugin but a question about someone's application architecture. Please move the discussion to a platform like Spectrum or StackOverflow.


Feature request: Block linking

I saw that header linking is already planned. Are there any plans for linking blocks as well?
This would make it so that you could completely replaced the default linking pattern with this plugin.

Yes. I hope to be able to add the two things at the same time.

It is simple enough to support inserting links to blocks that already have an id defined. So linking to a block like this:

Supporting the native link insertion functionality where all blocks in the note are shown and a block-id is generated when a specific block is selected will be more work. I'm not sure how to get all blocks in a specific note, so I will have to research this.
Is linking to blocks that already have a block id enough for your use case or would you need the extended functionality of the native link insertion?

It all depends on what you want to do with this plugin. I would personally love it if this plugin could completely replace the native link inserter because I prefer using one thing for one purpose.
I don't use block links that often tbh, but when I do, I do usually create new ones instead of linking to old ones.
Linking to existing block should be more than enough for the time being. If you have more time later, you can implement the future completely.

Thanks for your answer. I will do as you suggest. I have some ideas on achieving full block creation support, but I will start with the low-hanging fruit and just support linking to existing blocks.

A quick update: Even linking to existing blocks is not as easy as I thought. At least if I want it to look good. I will continue to look into this since it would be nice to have the same features as native Obsidian link suggestions.


is_cwd_a_dot_git_directory:1: = not found

Started getting this after updating. Happens when cding into a any dir in any git repo:
$ # i press enter
is_cwd_a_dot_git_directory:1: = not found  # gets printed before prompt shows up again
$

I have to turn git-radar off for now because of this :\ Any idea what's the cause?

Are you running zsh by chance?
I found this which looks like it gives a similar error because of the == in the new function that you referenced. I am unable to reproduce this problem using bash, so if it is a zsh specific thing, that could be why.

based on that link, it is possible that surrounding the == with single quotes like this '==' will resolve the problem. I quickly tried it with bash and it still seems to work.
Maybe you could try adding that and see if that works... If it does, then come back and let us know.

@hallzy i am using zsh, but i didn't understand which function you were talking about. I'm not executing any zsh code. the error above happens because git-radar is executing it: https://github.com/michaeldfallen/git-radar/blob/7c5fbb877bf27b20aae3eae1f0eaf668274a8a02/radar-base.sh#L539

Is it possible to revert the zsh incompatible change until this issue is fixed? I use git-radar as a submodule and it's really a PITA that I cannot update it.

Issue fixed. Sorry this has been open so long, I've recently switch jobs and had a fair bit on my plate starting a company etc.
I'd like to explore the idea of opening collaborator access to a few people so git-radar isn't at my mercy alone. It seems that it's used widely enough that the users can't rely on me alone to keep it going (as evidenced by the number of open issues and pull requests).

closing as fixed

:+1: thanks for fixing and thank you very much for your ongoing work on git-radar!


[docs] Autoload some fixtures now we dont have FixtureHelper

I am pretty sure we should have any docs about using fixtures globally (practical examples). Current docs limits itself by saying:

Using global fixtures is similar to using non-global ones. The only difference is that you declare these fixtures in yii\codeception\TestCase::globalFixtures() instead of fixtures(). When a test case loads fixtures, it will first load global fixtures and then non-global ones.

What is the expected result?
Docs about practice ways to load fixtures automatically, like global fixes, even for functional testing;
What do you get instead?
http://www.yiiframework.com/doc-2.0/guide-test-fixtures.html#defining-and-using-global-fixtures
It does not explain how to do it. I used to load fixtures through FixtureHelper that now is not included in the fw anymore. Even FixtureHelper is not documented. I found how to use it by reading comments in issues and over web.
Additional info
http://www.yiiframework.com/forum/index.php/topic/73349-how-to-auto-load-some-fixtures-for-functional-testing/
If anyone could give some tips/guidelines I could even update the docs after and make a PR.
Thanks.

Q
A

Yii version
2.0.10

PHP version
7.01

Operating system
Mint 18

I have written an answer to your forum post. FixtureHelper is not a class provided by Yii, so I have no idea what that was or how it works. Fixtures as described in the guide are mainly used for unit testing. If there is a way to use them for functional testing the FixtureController class could maybe help with that, but i have no experience with that.

I think it's this helper: https://github.com/yiisoft/yii2-app-advanced/blob/2.0.0/tests/codeception/common/_support/FixtureHelper.php

Codeception Yii module nowadays is able to load fixtures by itself: http://codeception.com/for/yii

codeception.com/for/yii is really useful. I already had readen from the start to the end.
But, the only thing I see I can do using codeception, without Yii facilities (I mean, an Yii helper like FixtureHelper) is to use load config of the codeception to dump all data in a only set before each test or  use haveInDb() method.
Not sure that it (haveInDb) will be pleasant to code, but it could be a cleaner way to "declare" pre requisites in the functional testing or to show real data situation. Obviously could be turn a mess too!

I have written an answer to your forum post.

Thank you. I will see it!

FixtureHelper is not a class provided by Yii, so I have no idea what that was or how it works. Fixtures as described in the guide are mainly used for unit testing. If there is a way to use them for functional testing the FixtureController class could maybe help with that, but i have no experience with that.

Ok, no problem. I think samdark has already answered. It seems that those fixtures things will not be "managed" entirely by Yii anymore, but from now on we will have to use codeception ways to do it.

If you don't have plans to document something about it, I think this issue could be closed.
Thanks.


Update CODE OF CONDUCT.md

Fixes/ Closes : Issue #196

We actually need a place where the code of conduct violation can be reported.

Please add the issue number in the description.

Hey @akash19coder, can you please try putting the content of this file in Grammarly and then try fixing some obvious things which can be fixed? I tried and found so many things which can be fixed in one click.

I have actually done it. I have corrected mistakes using Grammarly

@akash19coder, there are so many files coming in your PR. Please fix your PR only to have those changes which you want to push.


Zookeeper server fixes

The following pull request patches zookeeper, so running server with zkServer.sh
becomes usable:

Wrap zkServer.sh, so server can find paths
Patch shebangs in output scripts, which makes running zookeeper server pure

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: zookeeper
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: zookeeper
Partial log (click to expand)
unpacking source archive /nix/store/17m02fq48gkyhrshrwm2c3lip9lk0pdr-zookeeper-3.4.12.tar.gz
source root is zookeeper-3.4.12
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file zookeeper-3.4.12/dist-maven/zookeeper-3.4.12-tests.jar.sha1.asc
installing
patching script interpreter paths in /nix/store/15qv6af3l68jvfs0292bk9dr58g0q4ls-zookeeper-3.4.12/bin
/nix/store/15qv6af3l68jvfs0292bk9dr58g0q4ls-zookeeper-3.4.12/bin/zkCli.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/8zkg9ac4s4alzyf4a8kfrig1j73z66dw-bash-4.4-p23/bin/bash"
/nix/store/15qv6af3l68jvfs0292bk9dr58g0q4ls-zookeeper-3.4.12/bin/zkCleanup.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/8zkg9ac4s4alzyf4a8kfrig1j73z66dw-bash-4.4-p23/bin/bash"
/nix/store/15qv6af3l68jvfs0292bk9dr58g0q4ls-zookeeper-3.4.12/bin/zkEnv.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/8zkg9ac4s4alzyf4a8kfrig1j73z66dw-bash-4.4-p23/bin/bash"
/nix/store/15qv6af3l68jvfs0292bk9dr58g0q4ls-zookeeper-3.4.12/bin/zkServer.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/8zkg9ac4s4alzyf4a8kfrig1j73z66dw-bash-4.4-p23/bin/bash"
/nix/store/15qv6af3l68jvfs0292bk9dr58g0q4ls-zookeeper-3.4.12


[BUG] MisInformation when elasticSearch gives 413 status code

Context

ElasticDump version
6.0.0
Elasticsearch version: 5.6.16
Node.js version (note that nodejs v8+ is required for this tool)
v8.10.0
Full command you are having issue with (with inputs and outputs)

NODE_OPTIONS=--max_old_space_size=16384 elasticdump --input=document_content_index.json  --overwrite=true   --output=$ESURL/document_content_index   --type=data

A data-set you can share publicly which reproduces the problem

Describe the bug
While running this, the error that elasticdump gives is:
Wed, 10 Jun 2020 23:44:33 GMT | Total Writes: 1115
Wed, 10 Jun 2020 23:44:33 GMT | dump ended with error (set phase)  => Error

This is happening because the error returned was empty.

at Request.baseRequest (/usr/local/lib/node_modules/elasticdump/lib/transports/elasticsearch.js:671:15)

However, the status code and status message are as follows:
413 Request Entity Too Large
It would be great if we can provide better logging information in elastic dump.
Current behavior
While running this, the error that elasticdump gives is:
Wed, 10 Jun 2020 23:44:33 GMT | Total Writes: 1115
Wed, 10 Jun 2020 23:44:33 GMT | dump ended with error (set phase)  => Error

**Expected behavior**
A well-defined error message indicating the status message as well as the status code.

I can provide a small pull request for the same.

feel free to provide a PR.

NB: (Although I I'm not mistaking the body of a 413 is empty), so what's actually needed is a report of the status

@ferronrsmith Yeah! Since the body was empty, we can provide report status for better error messages. I will raise a PR soon. Thank you.

closed by https://github.com/elasticsearch-dump/elasticsearch-dump/commit/1654ca08612110dacf4c88fde8e870b12afcdff3


Sample inference script for FLAN-T5 XXL using DeepSpeed & Hugging Face.

Hi there,
I trained a flan-t5-xxl model following the steps from your blog. The training went well without any issues.
I ran the model for inference with an inference script for a normal huggingface seq2seq model. Just called the script with deepspeed as:
deepspeed --num_gpus=4 test_flan_t5_xxl.py --model_id /mnt/flan_modelling/flan-t5-xxl-ner-ft/checkpoint-26/

The out of the model is very random. I believe I am doing something wrong, maybe I need to pass the config file for inference as well.
Could you please provide a sample inference script. My appologies if this is quite trivial, I am fairly new to deepspeed.
Looking forward for your responce.
Best,
Irshad

What do you mean with the "out" is really random?

Ohh sorry, I mean output of the model was random, Not what was expected at all.

I used the below code for inference:
import sys
import time
import torch
import argparse
import numpy as np
import pandas as pd

import deepspeed
import evaluate
import datasets
from datasets import load_dataset
from transformers import AutoTokenizer
from transformers import DataCollatorForSeq2Seq
from transformers import AutoModelForSeq2SeqLM, Seq2SeqTrainingArguments, Seq2SeqTrainer

def parse_arge():
    """Parse the arguments."""
    parser = argparse.ArgumentParser()
    # add model id and dataset path argument
    parser.add_argument("--model_id", type=str, default="/mnt/flan-t5-xxl", help="Model id to use for training.")
    parser.add_argument("--per_device_train_batch_size", type=int, default=8, help="Batch size to use for training.")
    parser.add_argument("--per_device_eval_batch_size", type=int, default=8, help="Batch size to use for testing.")
    parser.add_argument("--generation_max_length", type=int, default=140, help="Maximum length to use for generation")
    parser.add_argument("--generation_num_beams", type=int, default=1, help="Number of beams to use for generation.")
    parser.add_argument("--deepspeed", type=str, default=None, help="Path to deepspeed config file.")
    args = parser.parse_known_args()
    return args

def inference_function(args):
    tokenizer = AutoTokenizer.from_pretrained(args.model_id)
    model = AutoModelForSeq2SeqLM.from_pretrained(args.model_id)

    while True:
        text = input('Input text:\n')
        t1 = time.time()
        batch = tokenizer.prepare_seq2seq_batch(src_texts=[text], max_length=256, truncation=True, return_tensors="pt")
        output = model.generate(batch["input_ids"], max_length=128, min_length=2,  early_stopping=True, num_beams=1)#, temperature=0.8, top_p=0.75)#, top_k=10, num_beams=5)
        print([tokenizer.decode(g, skip_special_tokens=True, clean_up_tokenization_spaces=True) for g in output])
        print(time.time()-t1)

def main():
    args, _ = parse_arge()
    inference_function(args)

if __name__ == "__main__":
    main()

whats your model id and output?

I have raised a different issue #12 with better detail. Please feel free to delete this issue.


"java.text.ParseException: Next event is not a Separator" raised

when you pass a filename header with an unescaped quote in it.  It's fine for this to be an error, but is the java specific exception appropriate?
I set a header like this:
Content-Disposition: attachment; filename=" "Value Added" in Editorial Acquisitions.pdf"

Tracking with: https://jira.duraspace.org/browse/FCREPO-1295


Generate Icons meta data scaffold

Follow up to discussion with Josh, we need a scaffold of icon meta data file. From what I remembered during our discussion, the following fields in the meta data file would be useful:

name
description
alias
category
variants

Duplicate of carbon-elements issue


Missing content about permissions required to configure/create each option

This is very nice document clarifying and listing available authentication methods and recommended scenarios for possible ACR authentication options.
However I miss access control (IAM) content which would explain if you need to be an owner or contributor to ACR or subscription. That would quickly filter out methods which are and which are not available for person with particular access restrictions.
To sum up I would need to know which of the methods are available to:

person which is a contributor (at RG level or ACR level ?)
person which is an owner (at RG level or ACR level ?)
person which is neither a contributor nor an owner (at RG level or ACR level ?)
...

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

ID: df40e112-6cf4-f6ce-4d82-d36bbd561405
Version Independent ID: a68e6e7b-dfa2-8640-0a43-cd15f24facdb
Content: Registry authentication options - Azure Container Registry
Content Source: articles/container-registry/container-registry-authentication.md
Service: container-registry
GitHub Login: @dlepow
Microsoft Alias: danlep

@przemolb
Thanks for the feedback! We are currently investigating and will get back on this.

@dlepow Can you please add your comments on this.

@przemolb - This is great feedback. I've noted your comments and agree the IAM content would be useful to include. I'll keep this item open for an upcoming update of this content.
#in-process

@przemolb - We sincerely apologize for the delayed response. To assign Azure roles, you must have Microsoft.Authorization/roleAssignments/write permissions in the subscription, such as User Access Administrator or Owner. (Reference)
The requested updates have not been made since the creation of this issue, and the timeline for resolution may vary based on resourcing, so we've created an internal work item to incorporate your suggestions. We are closing this issue for now, but feel free to comment here as necessary.
#please-close


Cannot connect to Docker Hub

Expected behavior
Connect to Docker Hub
Actual behavior
Server 500 error
Information about the Issue
(HTTP code 500) server error - {"message":"Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"}
Steps to reproduce the behavior

Use Kitematic to download MongoDB container
Error occurs.

Please make sure that you're on a stable connection and use a solid DNS such as Google DNS.


SSR with NextJS and Unistyles

Description
The question was reported here: #48 , and I was able to reproduce it. There are two areas for improvement:

[ ] The useDimensions hook,
[ ] The import to the preprocessor from react-native-web.

I was able to patch it quickly, but I need to conduct more tests to find a proper solution.
https://github.com/jpudysz/react-native-unistyles/assets/9088288/eba34099-2561-46b5-ae88-4f5fcdf5bba4
Steps to reproduce

Import react-native-unistyles in a project with NextJS
Run it

Snack or a link to a repository (optional)
No response
Unistyles version
1.0.0
React Native version
0.72
Platforms
React Native Web

Released with 1.1.0


showChoices can block the player control after exit

Create a template with the starter-kit:
npx degit rpgjs/template my-rpg-game
cd my-rpg-game
npm install
npm run dev

Edit src/server/player.ts to display a choice when a player joins the map

      async onJoinMap(map: RpgMap) {
        const choice = await this.showChoices('What color do you prefer?', [
         { text: 'Black', value: 'black' },
         { text: 'Rather the blue', value: 'blue' },
         { text: 'I don\'t have a preference!', value: 'none' }
        ]);
      }

Reload http://localhost:3001/, you see the choice menu correctly displays but the player is no longer controllable at exit.
Now add a line await this.showText('Hello World'); at the end of onJoinMap and save.
Reload http://localhost:3001/, the choice menu displays first, then the "Hello World" message at exit and then you can still move the player.

(so a workaround for this bug is to always call a showText after an showChoices, which maybe we want to do in practice anyway...)

Fixed on the update (alpha.10)


Kubeless should load function in separate AssemblyLoadContext

Is this a BUG REPORT or FEATURE REQUEST?:
Bug report
What happened:
I cannot load Newtonsoft JSON into .Net Kubeless function since it will throw error:
System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=<IP_ADDRESS>
What you expected to happen:
It is expected to work
How to reproduce it (as minimally and precisely as possible):
Create a function with Newtonsoft.Json 12.0.3 as dependency.
Anything else we need to know?:
Simular problem was with Amazon Lambda:
https://github.com/aws/aws-lambda-dotnet/issues/450
https://github.com/aws/aws-lambda-dotnet/issues/453

cc/ @allantargino

Hi @vasicvuk,
The runtime is already shipped with Newtonsoft.JSON 11.0.2. At any class you can just import it  (using Newtonsoft.Json;) without explicit adding it as a dependency on your .csproj.
The error you are getting is because by default the runtime won't load duplicated dependencies. Does 11.0.2 satisfy your needs?

@allantargino This issue is about having separate Assembly Load Context so that this issue won't happen for any other library.
Anyway we would like to always have up to date libraries in case of security issues.

I've just come across this same issue, or at least I presume it's the same issue. My pod crashes on startup due to failing to load an assembly, the only assembly in my csproj (aside from the Kubeless.Functions one) is Newtonsoft.Json.
Removing the --dependencies foo.csproj argument results in a compilation error as the Newtonsoft namespace cannot be found. I presumed that as Newtonsoft.Json 11.0.2 was already shipped with the runtime, and it was my only dependency that I could remove the csproj from the deployment entirely, is this not correct?
Also, I agree with @vasicvuk that not being able to ship functions with the latest version of libraries is far from ideal, especially as we're looking at porting some code over to functions that already makes use of Newtonsoft.Json 12.0.2 and downgrading is not really an option.

Hi @garethpixelpin and @vasicvuk,
I see your point and makes sense to have an isolated environment for dependencies.
We would appreciate any contributions to the .NET Core runtime in order to introduce this behavior (please check the source code at https://github.com/kubeless/runtimes/tree/master/stable/dotnetcore/src).
As soon as this refactor is merged https://github.com/kubeless/runtimes/pull/58, we can accept that enhancement.
Thanks!


Cannot use up and down arrows to navigate out of a group.

It works for me actually. do you have this bug for any case?


issue 2956

issue #2956, added info about Education editions of Windows 10, source: Windows 10 editions for education customers

@JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks.

@Justinha - can you please assist to check, approve and merge the content for this PR based on issue #2956?
Thank you.

@Justinha - I would like to follow up on this. Can you please assist to check, approve and merge the content for this PR based on issue #2956?
Thank you.


This works with public keys?

Hi, I was using oauth server from https://oauth2.thephpleague.com/installation/ with public and private keys, but using the public key as secret with file_get_contents didn't work.

Is it uses rsa256 then you should be able to use something like:
$app = new Slim\App;

$app->add(new Tuupola\Middleware\JwtAuthentication([
    "secret" => $publickey
    "algorithm" => ["RS256"]
]));

You can find example of how to generate the token in firebase/php-jwt README. This middleware uses firebase/php-jwt for decoding the token.

It works! Thanks!
But I think I will continue with the oauth server


local-cache and link-to-sdk don't seem to work well together

Hi,
I've tried to use this action to set up NDK r23c in GHA's Ubuntu 20.04's runner, using the link-to-sdk option so that it would be found where it used to be pre-installed (GH removed it from their Ubuntu 20.04 runner recently: https://github.com/actions/runner-images/commit/8bb825ba131f48691fd1adb189d6893819c49114).
This seems to work if local-cache isn't used, but if I use both options, then the NDK doesn't seem to be found in /usr/local/lib/android/sdk/ndk/23.2.8568313.
Example build log: https://github.com/godotengine/godot/actions/runs/6936937595/job/18870055757
With this config:
      - name: Install Android NDK r23c
        uses: nttld/setup-ndk@v1
        with:
          ndk-version: r23c
          link-to-sdk: true
          local-cache: true

Ideally I'd like to use both, so that I can install the NDK once and keep it cached for all subsequent runs.
I would imagine it would restore /home/runner/.setup-ndk/r23c from the cache, and re-create the symlink in /usr/local/lib/android/sdk/ndk/23.2.8568313 each time.

I fixed it in my repository this way
All files were restored in the correct directory ${{steps.setup-ndk.outputs.ndk-path }}.
The problem was that the symbolic links when restoring from the cache referred to /opt/hostedtoolcache/ndk/r23/x64/ and not to /home/runner/.setup-ndk/r23 (action job)
Changed clang++ from /opt/hostedtoolcache/ndk/r23/x64/toolchains/llvm/prebuilt/linux-x86_64/bin/clang to /home/runner/.setup-ndk/r23/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
Changed llvm-strip from /opt/hostedtoolcache/ndk/r23/x64/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-objcopy to /home/runner/.setup-ndk/r23/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-objcopy

I'll give this a look later today, should be an easy fix. Cool seeing this used in Godot :D

Thanks for the quick update!
I indeed had a similar error without pre-installing the NDK on another Godot repo (godot-cpp): https://github.com/godotengine/godot-cpp/actions/runs/6930951873/job/18859997384
So your findings seem correct.
That didn't break the main godot repo's CI though, presumably because our SCons buildsystem has some logic to check the existence of the NDK and install it if missing. Not sure why it then started failing with using this action with local-cache + link-to-sdk though.
I tested the fix and it doesn't seem to work yet for me:

First run install NDK and caching it: https://github.com/godotengine/godot/actions/runs/6954839302/job/18922445237?pr=85156
Second run re-using the cache: https://github.com/godotengine/godot/actions/runs/6955355592/job/18923995748?pr=85156

I may have an invalid cache from a previous attempt that I'd need to clean manually?

I confirm, without manually fixing the links, the same error appears
https://github.com/DmitriySalnikov/godot_debug_draw_3d/actions/runs/6955475648
And no errors with my Restore Android Symlinks step
https://github.com/DmitriySalnikov/godot_debug_draw_3d/actions/runs/6955529520/job/18924474269

@raftario can you check again what the problem is?

I will during the weekend

The honest answer is that I genuinely have no idea why the issue arises and would need to dig into it more, but didn't have time for it during the holidays and don't have time for it now as I am in the process of moving across the country. I'd be more than happy to accept contributions from someone willing to do the work but in the meantime I'm the only person maintaining this action and fixing a small edge case in it is pretty far down my priority list. I hope you can understand.

Thank you for replying, that is completely understandable and I wish you good luck. I might attempt looking into this in the future but my hands are full at the moment, so I don't think that will happen anytime soon.


[Fix #526] Document and give example of JSON in data

Fixes https://github.com/apache/incubator-kie-kogito-docs/issues/526

Description:
As per subject. Also adds function of type expression and more info on $SECRET data type.

@kaldesai can you please take a look?


Testing a clean single test.

This is just a test -- obviously not merging this in! -- that wiping out tests/ entirely and replacing its contents by a trivial manually-created test just does the job.
I've used the workflow_dispatch: trigger as well, on the respective branch, manually. It worked.

CC @miropeter, :point_up:!
25 seconds for JavaScript and 1 minute for Kotlin test runs. Me happy, taking into consideration this involves building the container inside the Github action, and installing Java/Kotlin into it.
Closing this PR now =)


Possible Moves Function is Faulty

The Analysis
When the submit button is clicked, the analysis page shows an array with some pawn moves and b's. The possible bishop moves are not functioning properly.

It is patched now.


Cant pass extra data in nodes in simulation.nodes function

I want to pass extra data like nodeId to use later
For example find a node under mouse cursor, then get nodeId and make some operations
Im building nodes inthis way:
const nodes: (SimulationNodeDatum)[] = notes.map(c => Object.create(c))

all extra data from notes is removed
if I force like this:
const nodes: (SimulationNodeDatum)[] = notes.map(c => Object.create({ ...c, tmp: true }))

I have an error:

It seems to be working here https://observablehq.com/@recifs/simulation-nodes-with-added-data--support


Updated documentation for FW update of ETH robots

Hi all,
I have just updated the instructions for performing FW update on the ETH robots.
The new instructions can be found in the howto files inside folder https://github.com/robotology/icub-firmware-build/tree/master/ETH.
The files are now also linked by http://wiki.icub.org/wiki/Firmware#ETH_robots.

Dear all
we just updated the firmware following the instructions, but when we were updating the firmware with the CanLoader, we saw in the debug messages of the program on the terminal that there was a complaint about not having a recent version of the eUpdater module of the firmware.
We have been reading the instructions on the link you pasted (https://github.com/robotology/icub-firmware-build/blob/master/ETH/howto-eth-boards-programming.txt) but there is no mention of a procedure to update this eUpdater. Shall we do it?
@misaki43  @dogoepp  @paraschos

@marcoaccame could you give a look at this?

Something useful on this side: https://github.com/robotology/icub-firmware-build/blob/master/ETH/howto-eth-boards-fundamentals.txt

So if I get it correctly, to upload the eUpdaer we have to do the following:

Boot the boards, click discover twice (i.e. load the eUpdater at ``START'')
Flash the eApplPROGupdater as firmware (i.e. at ``DEF'')
Jump to eApplication, a.k.a. ``DEF'' (or just reboot everything Do not click twice at the discover)
Flash the new eUpdater (while the eApplPROGupdater is running)
Reboot, click discover twice
Flash the proper firmware
Reboot and is it done

@serena-ivaldi I just checked
https://github.com/robotology/icub-firmware-build/blob/master/ETH/howto-eth-boards-programming.txt
Isn't it that Sec. (7) does the eUpdater update?

Hi @serena-ivaldi @paraschos @marcoaccame
What's the status of this?

@pattacini Not sure, I am in Darmstadt. @serena-ivaldi Did you finish it?
@marcoaccame the new documentation is appreciated. Really clear! However, if you are in a hurry it is quite lengthy for checking it for the first time. Maybe you would like to have a quick n dirty version on the top of the howto with just the commands.
Q: What is the order that of board chain? Is it the same as the IP (increasing from 1 to 11)?
I just want to know to make debugging easier if ever needed... Maybe it should also be in the documentation.

Hi all,
sorry for the delay.
In short.

Hi @serena-ivaldi, for now, there is no need to update to the new eUpdater (and eLoader),
but if one wants to do it, the documentation can be found on section (7) of https://github.com/robotology/icub-firmware-build/blob/master/ETH/howto-eth-boards-programming.txt. And I am available for support during the update.
Hi @paraschos, the quick-n-not-so-dirty version of instructions is in https://github.com/robotology/icub-firmware-build/blob/master/ETH/howto-eth-boards-simple-fw-update.txt. I have decided to describe most common operations and to discard advanced ones.
The chain of ETH boards can change from robot to robot. The correct action would be to add the HW schematics in a file inside robots-configuration repository.  For your robot the addresses are:
<IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS> - <IP_ADDRESS>

In more details.

The canLoader does not really complain. It just tells:  [WARNING] remote board did not sent any ack to command 0x20. it may have a version of eUpdater older than .... The reason is that in the summer there has been a retro-compatible change of protocol between the canLoader and the eUpdater and it was a good thing to add some debug prints about what the canLoader finds on the boards on the various robots.

The change of protocol is only a piece of some activities aimed at a general improvement of the FW programming tools. Eventually (end of year), there will be a new GUI which manages both CAN and ETH boards, hopefully with better and clearer modes of operation. The new GUI is wip under the branch fwupdater2 of icub-main / icub-firmware-shared.

The new GUI will behave in a slightly different manner, will have a simplified layout for common operations and a complete one for advanced users.  Thus, completely new documentation is required.

The new GUI will still manage old versions of eLoader / eUpdater even if a full FW update will give extra functionalities.

In order to offer enhanced features to this GUI, we needed to extend / review the protocol capabilities between the programs running on pc104 (aka: ethLoader, canLoader, the new GUI) and FW running on the ETH boards (eLoader, eUpdater, eApplication).

The new protocol is already used by ethLoader and canLoader which also guarantee retro-compatibility with old versions of FW. Also, we have released new versions of eLoader (v 2.20), eUpdater (v 2.20 and now v 2.21) and application because with them the ethLoader can retrieve some more information from the ETH boards. But older FW versions still work as they did before.

Here is an example of what you can see in both cases: (a) keeping old FW, and (b) upgrading eLoader + eUpdater. Board <IP_ADDRESS> has an old FW whereas <IP_ADDRESS> has the latest FW. The new eLoader FW v 2.20 allows you to recognise the type of ETH board. The new eUpdater FW v 2.20 allows to retrieve more information about what is running on the board and to edit the field Info. At the moment it is not that much which I believe can justify an update.

Thanks @marcoaccame
Closing; feel free to reopen it again if needed.


Fix for KamuSM root name constraint encoding

Description
The Kamu Sertifikasyon Merkezi (KamuSM) root certificate authority successfully petitioned Mozilla to expand the imposed name constraint placed on the TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1 root to allow issuing for all *.tr domains.
In https://github.com/rustls/webpki-roots/pull/36 we tried to update the corresponding webpki-roots constraint, but arrived at the wrong encoding, making the constraint inoperative with webpki. This branch cleans up an unused name constraint constant and fixes the KamuSM root name constraint encoding.
Resolves https://github.com/rustls/webpki-roots/issues/38
codegen: remove unused ANSSI name constraints.
The Agence Nationale de la Securite des Systemes d'Information (ANSSI) root is not present in the generated lib.rs, and so the associated name constraints are not used.
codegen: correct TUBITAK1 name constraints.
The content was misencoded, resulting in a permitted subtree base name that's an otherName type general name with a nonsensical value. These types of general name are not supported by webpki, making the name constraint functionally a no-op.
The updated encoding correctly specifies a permitted subtree with a dNSName type base general name with the value ".tr".
See #38 for a more detailed breakdown of the issue and fix.
Cargo: version 0.25.1 -> 0.25.2.
Increases the package version in preparation for a release.

Probably good to add a version bump here, too?

Probably good to add a version bump here, too?

Good call, I've added a commit for that.

Have you given any thought to better tests that would have caught this?

A little bit, it's a tricky situation. I think for each name constraint we want a negative test that the constraint correctly rejects a certificate that doesn't meet the name constraint requirements, but we can't source that for real trust anchors with real name constraints if the web PKI is working as intended.
The only two options I've been able to think of are:

writing test infrastructure to generate our own trust anchor with a name constraint matching the one under test, but with keypairs under our control, and then having it issue a positive and negative test case we can check with EndEntity::verify_for_usage.
exposing more of the webpki name validation API surface so we could instantiate GeneralName instances and call verify.rs's check_presented_id_conforms_to_constraints directly without needing to worry about the other aspects of validation that verify_for_usage requires (valid signatures, etc).

The latter feels unpleasant and counter to the goals of the webpki crate. The former is probably doable with some legwork? WDYT?

Hmm, maybe (2) could still work if we move check_name_constraints() to become a method of Cert and rename SubjectCommonNameContents and variants a bit to clarify its purpose, that would be a decent entry point?
But (1) definitely feels like more of an integration test. Bit more work to get going but probably a better situation in the long term.
(And that would allow us to close #7, I think?)

But (1) definitely feels like more of an integration test. Bit more work to get going but probably a better situation in the long term.

I'll experiment with this a little bit (but it might be time consuming enough that we shouldn't block the fix release waiting on it).

Yeah, feel free to just get this out -- we already have a tracking issue for the tests anyway!

Published 0.25.2.

we can't change issued certs or find misissued certs, but we can change the constraints so the issued cert we do have becomes outside the constraint:

Good idea :+1:

Nice, I'm going to make sure this is published just to make sure we make this fix available for users.

Thanks! I appreciate it.

But (1) definitely feels like more of an integration test. Bit more work to get going but probably a better situation in the long term.

I'll experiment with this a little bit (but it might be time consuming enough that we shouldn't block the fix release waiting on it).

Here's something like what I was thinking: https://github.com/rustls/webpki-roots/pull/40


UI design for homepage

Issue that this pull request solves
Closes: # (issue number)
Proposed changes
Brief description of what is fixed or changed
Types of changes
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update (Documentation content changed)
[ ] Other (please describe):

Checklist
Put an x in the boxes that apply

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] My changes does not break the current system and it passes all the current test cases.

Screenshots
Please attach the screenshots of the changes made in case of change in user interface
Other information
Any other information that is important to this pull request

@himanshu007-creator Please don't close the PR on your own. In that case the mentors tend to misss on the PR's. PR's are supposed to be closed only the maintainers and mentors.


[Coverity CID: 182894] Error handling issues in /samples/net/nats/src/main.c

Static code scan issues seen in File: /samples/net/nats/src/main.c
Category: Error handling issues
Function: write_led
Component: Samples
CID: 182894
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

*** CID 182894:  Error handling issues  (CHECKED_RETURN)
/samples/net/nats/src/main.c: 201 in write_led()
195     		fake_led = state;
196     	} else {
197     		gpio_pin_write(led0, LED_PIN, !state);
198     	}
199
200     	pubstate = state ? "on" : "off";

CID 182894:  Error handling issues  (CHECKED_RETURN)
Calling "nats_publish(nats, "led0", 0U, msg->reply_to, 0U, pubstate, strlen(pubstate))" without checking return value. It wraps a library function that may fail and return an error code.

201     	nats_publish(nats, "led0", 0, msg->reply_to, 0,
202     		     pubstate, strlen(pubstate));
203
204     	printk("*** Turning LED %s\n", pubstate);
205     }
206
** CID 182893:    (OVERRUN)

In the process of submitting a PR for this issue. Can this issue be assigned to me?


util: fix extra linter errors

These errors were discovered when running some extra linters which are not part of the default suite. I will enable the extra linters in a different PR.

@raghavendra-talur with this golang change in play, how does it impact some of the changes in this PR?

@raghavendra-talur with this golang change in play, how does it impact some of the changes in this PR?

Looks like the fix attempts to address this failure. It is possible that the linters downstream are older, and hence "complaining" about the same. One option is to address this downstream only?

@ShyamsundarR you are right. Closed this PR as you have already handled the backport.


⚠ Bofrost.de has degraded performance

In cae6327, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1175 ms

Resolved: Bofrost.de performance has improved in 051427a after 8 minutes.


defaults option doesn't respect undefined

If I want a particular option to have the default value undefined, and I don't supply that option on the command line, it isn't returned as undefined.

Can you provide your code, and an example invocation and the results?

I was not able to reproduce this problem from your description.
const parser = require('minimist');
const result = parser(process.argv.slice(2), {
    default: {foo: 'bar', example: undefined}
});
console.log(result);

% node index.js
{ _: [], foo: 'bar', example: undefined }

There isn't enough information to help with this issue, and no activity in a month. Closing this issue as can't reproduce.
Feel free to open a new issue if it comes up again, with new information and renewed interest.


"asn1.js": "^5.2.0" with error

SyntaxError: Use of const in strict mode.

some error with me

This issue happens from #37, and seems to be the same as the following issue:
https://github.com/indutny/asn1.js/issues/99
@calvinmetcalf @shrpne
I think that #37 should be reverted because this commit contains ES6 features, which means that the commit has a non-negligible impact.
Thanks.

Duplicate of #41
Btw, i'm personally not against of reverting it in v5 and releasing it under v6

Duplicate of #41
Oh, thanks.

Closing as a duplicate of #41.


Use non-escaped JSON format for devicedb payloads

Since the payload for devicedb keys is application-controlled,
we can modify maestro so that it reads/writes non-escaped JSON
for its key data which makes it significantly easier to use the
Pelion Cloud REST API for setting logging and network config.
This also makes us consistent with every example on the Internet
for sending JSON formatted data through 'curl'.
for example, here is the old format:
curl -X PUT ...
-H 'Content-Type: application/json'
-d '"{"key":"value"}"'
and here is the new format:
curl -X PUT ...
-H 'Content-Type: application/json'
-d '{"key":"value"}'

Refer to this link for build results (access rights to CI server needed):
https://edge-jenkins.isgtesting.com/job/test_team-build-maestro/83/


koreader: init at 2022.05.1 (built from source)

Reviewers: it will be easier to read this PR if you look at each commit individually, rather than smashed together the way the "Files Changed" tab shows them.
The first three commits are trivial; they are included because without them CI will fail.  The fourth commit renames the existing koreader expression to koreader-bin without any changes to it.  The fifth commit marks the sourceProvenance of koreader-bin.
The sixth commit is where all the interesting stuff is.
Two utility functions, mapAttrsToConcatStringSep and buildLuaRock, near the top of the file are likely to be useful outside of this particular package.  They have comments suggesting they might be moved elsewhere.  I prefer to do that in separate PRs following this one.
Ancestral WIP-draft was https://github.com/NixOS/nixpkgs/pull/178320
Description of changes
This expression (koreader/src.nix) builds koreader from source.
The previous koreader expression has been renamed koreader-bin as suggested by @AndersonTorres, and has been moved to koreader/bin.nix.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking

[X] Fits CONTRIBUTING.md.

Force-push is to resolve the merge conflict caused by 5f7b9cffae972e4fed69419315517678a93a4c3e

Do we really have to vendor all of these? I'm sure koreader builds fine with any version of most of these dependencies.

That is my next project!
However, I think that the default nix-env -iA koreader should always upstream-approved versions of koreader's dependencies.
If we diverge from the versions used by upstream, any quirks or bugs that arise from our version-bumps will create "support blowback" for upstream... people will complain to them about weird bugs that they can't reproduce without realizing that it's really our fault for bumping the version of something (say, glib or openssl) without testing its effect on koreader.
My plan is to add a top-level parameter doNotVendor = [ "pname", "pname", "pname" ... whose default value is [] (i.e. vendor everything), and add a third top-level package koreader-unvendored which "unvendors" as many things as possible.  But we should not mislead people into thinking that koreader-unvendored is koreader.  Also I think it is inevitable that koreader-unvendored will become broken quite frequently... I'm not sure I can commit to keeping it unbroken at all times the same way I commit to rapid-response maintainership of koreader/src.nix and vendored.nix.

Using a vendored version has the disadvantage of longer build times and untimely security updates.

Yes, and the shorter build times are the main attraction for me, since I'm about to start hacking on koreader... soon my ebook reader will finally have a "totally ignore the touchscreen" mode like all of my dead-tree books do!

Heroic, I should say.

:blush:

Squashed.

The main reason we "vendor" e.g. zstd is because the primary target is embedded systems.

This is stretching the word "embedded"... these aren't microcontrollers running an RTOS.  All the popular ebook devices (Kindles and Kobos) are full-fledged arm-linux-gnueabi machines -- Linux, glibc, and all.  Kindles even have their own glib.so, and koreader uses it.  AFAICT "kindle build" of koreader just sets CC=arm-linux-gnueabi-${CC} and decides which touchscreen+eink driver gets built.

It should be perfectly fine to use ...

Thanks for clarifying.  Does this statement apply to ereader builds as well?  Because those are the ones that really matter.  Being able to nix build pkgsCross.arm32-linux.koreader.kindle and rsync it to my device is a goal.
Also, curious, what is different about MuPDF?  Koreader seems to backport a huge amount of material to mupdf-1.13.0; did something awful happen in the following release?

It is not clear that getting the tests to run inside the nix sandbox is feasible.
They expect network access, only partly in order to download more lua packages that aren't used during the build.  It's extremely tedious to work on them inside the sandbox because the tests run after the entire build has finished, and the build takes a long time, and AFAICT nix doesn't have good support for restarting partially-completed sandboxed builds.  Modularizing the build into separate derivations would need to come first.

some kind of MINIMAL_DESKTOP variable to say that we're in some kind of Debubuntu/NixOS environment

This is slightly funny since I don't run NixOS and am frequently told that my workstation isn't a "desktop" because it omits certain software ;)  But I guess all terminology is loaded in some way.

@Frenzie, thank you for patiently explaining so many things to me in this thread.  You've been very generous with your time.
I've been thinking a lot about this PR.  I still think that nixpkgs' amazing support for cross-compilation would make koreader's build process much simpler and more maintainable.  I do a lot of cross-compilation and it's very hard to go back.  However I'm no longer think it's a good idea to build the ereader/device builds of koreader from an expression kept in the nixpkgs repo.  With very few exceptions, nixpkgs doesn't keep old versions of things around for very long.  That policy simply doesn't work for things like koreader that have to deal with manufacturer-supplied kernels and userspaces.
  I'll try to be more aware of these "patchelfpkgs" expressions which are in nixpkgs mainly because NixOS doesn't have its own repo, and resist the urge to make them build from source.

We have put a lot of time and effort into https://github.com/koreader/koxtoolchain and without that

There's a similar situation with another piece of software which I am very fond of, coreboot.  Curiously, coreboot's version-pinned toolchain is in nixpkgs, but coreboot itself isn't.

But does the concept make sense to you? ;-)

Yes, absolutely.  Chromium and firefox both vendor enormous quantities of libraries (probably more than koreader does) but only use them if the linker can't find a corresponding system library.  For situations where automatic detection is inappropriate I belive the manual option is --with-system-libfoo.


error during installation

install by executing :
sam install skills -g https://github.com/snipsco/snips-skill-respeaker.git
got error :

Running setup.sh & generating virtual environment for snips-skill-respeaker
✖ Error setting up virtualenv, one or more actions might not be able to run. Reason :
src/mqtt_pal.c: In function ‘mqtt_pal_recvall’:
src/mqtt_pal.c:66:16: warning: duplicate ‘const’ declaration specifier [-Wduplicate-decl-specifier]
const void const *start = buf;
^~~~~

what could be wrong?

Hello,
It seems there is warning comes from installation. Everything should be ok. The issue is that sam can not distinguish an error or a warning, it will always report as an error.


[9.x] Allow multiple Fields to be selected with insertGetId in pgsql

Overview
Builder::insertGetId with PostgreSQL works with the RETURNING clause. This enables arbitrary fields to be returned from the inserted rows and also works for multi-row inserts. Currently this cannot be utilized. This PR aims to change that.
Changes to PostgresGrammar
compileInsertGetId now accepts an array as $sequence.
When given an array, it wraps all elements and joins them with , (comma) to produce the RETURNING clause.
When not given an array it behaves like previously.
Changes to PostgresProcessor
processInsertGetId now also accepts an array as $sequence.
The behavior is as follows:
If multiple rows were inserted, an array of same length with the selected ids will be returned.
If only one column is selected, this column will be in the array.
If multiple columns were selected, the array contains associative arrays with $fieldName => $fieldValue.
If the returned array would only contain one item, the item is returned directly.
If no rows were inserted, null is returned. (Open to debate, if an empty array would be better).
Some examples:

One row inserted, one column (or defaulted) $sequence -> simple value returned
Multiple rows inserted, one column (or defaulted) $sequence -> array of simple values returned
One row inserted, multiple columns $sequence -> array of selected columns (Open to debate, if an array with one element  containing selected columns would be better)
Multiple rows inserted, multiple columns $sequence -> array of arrays of selected columns

Note on automatic tests: I would appreciate help on this topic, as I have not worked with mocks yet and don't know how I would write automatic tests for this.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


Simplified Admonition Titles

We propose a simplified syntax to allow arguments for all named admonitions. The syntax allows an argument for any title of a named admonition like {tip} or {note}, to allow users to easily set the color and icon of an admonition while also having a custom title. The proposed syntax is:
```{note} Custom Note Title
Body of the styled admonition.
```

Coauthored with @mmcky.
See also:

https://github.com/executablebooks/myst-spec/issues/49

TODO:

[ ] Merge cross references, turn that to active MEP0001!
[ ] Another pass on the document, cleaning up any ideas
[ ] Get images into a local folder
[ ] discuss MEP codemods and how to do this, update that section

So to frank, I fell it will be impossible to make this change in https://github.com/executablebooks/MyST-Parser:
it would break too much, without any deprecation route.
As discussed in https://github.com/executablebooks/myst-spec/issues/57, I do think it would be possible with div though, i.e.
:::{note} Custom Note Title
Body of the styled admonition.
:::

Ok, I didn't understand the different code paths between a fence and a code block on the python/docutils side. For JS there isn't an issue at all.
I think that really high-grades the colon-fence MEP. Happy to have the colon fence be the documented/only way to do this, the only reason I used backticks here is because that isn't in the myst-spec at all yet.
Will open an issue here to track that, and then move onto #10.

Yep, as mentioned in https://github.com/executablebooks/MyST-Parser/pull/713
I feel the key difference here is that:

``` fence should be for enclosing non-myst content
::: div should be for enclosing myst content

(Happy to jump on a chat to discuss this with you guys 😄 )

Note, one thing that is maybe problematic about {#name .class key=value} though, is if you need a flag, like
:::{name}
:flag:
:::

e.g. this is not currently valid attribute syntax {flag}

Yep, as mentioned in executablebooks/MyST-Parser#713
I feel the key difference here is that:

``` fence should be for enclosing non-myst content
::: div should be for enclosing myst content

hey @chrisjsewell @rowanc1 I am not sure I fully understand this point / discussion.
It would be great to link up at some point to fully explore this.
My concern here is that from a user perspective -- they really shouldn't need to know the difference between myst and non-myst content in my mind. To me we have an entry point into directives which represents -- do something special with whatever is in here.

My concern here is that from a user perspective -- they really shouldn't need to know the difference between myst and non-myst content in my mind. To me we have an entry point into directives which represents -- do something special with whatever is in here.

Except, I would suggest, many people do. ::: containers were heavily requested, in particular as a way to have admonitions (or really any directive containing Markdown) render correctly in "non-myst" environments (like here on GitHub).
That, plus it makes it a lot more friendly for static anlysers (like syntax highlighters and LSPs) to assess the source text, without having knowledge of every possible directive
If we do a quick GitHub search: https://github.com/search?q=\"colon_fence\"&type=code
there are 1200 hits
By contrast, and I'm happy to be proved otherwise, I've had very few people ask for what this MEP proposes;
it's more of a nice to have.
and yeh to re-iterate, this MEP is essentially suggesting changing the whole semantics of ``` directive parsing, to improve one use-case.
Plus, in a way that would likely break many myst-parser projects and, more critically, it would break them in a way that is really difficult/impossible to detect, warn about and provide deprecation pathways

As a random end user stumbling across this let me remark that @chrisjsewell's direction sounds good to me. I had the wish already that anything in a colon fence would be rendered as markdown, period. So e.g.
:::
*Hello*
:::

should render like an admonition without a title (and not like a code block).
Then why not pick up the first heading level text and use it as the title?
A less clunky syntax for specifying classes would also be great. I had even thought of something like this:
:::{note.theorem} Theorem

Let $n \in \mathbb N$ and ...
:::


Which release file?

In the tutorial, it says to use the release file at latest release, but it does not say which one. Should I use the ui or the api?

Further errors on the tutorial (although, I'm not totally sure they're errors, because I don't know if I'm installing the right release):
when I run sudo supergiant --config-file /etc/supergiant/config.json, it tells me it's running on port 3001, whereas in the tutorial, it says 8080
It does not output the password when I first run it for the admin

Another bug in the tutorial, when I try to run the api release, I get
root@supergiant:~# sudo supergiant --config-file /etc/supergiant/config.json
panic: sql: unknown driver "sqlite3" (forgotten import?) [recovered]
panic: sql: unknown driver "sqlite3" (forgotten import?)
goroutine 1 [running]:
github.com/supergiant/supergiant/vendor/github.com/urfave/cli.HandleAction.func1(0xc4204df8f0)
/home/travis/gopath/src/github.com/supergiant/supergiant/vendor/github.com/urfave/cli/app.go:478 +0x23b
panic(0x18200a0, 0xc42031a4b0)
/home/travis/.gimme/versions/go1.10.linux.amd64/src/runtime/panic.go:505 +0x229
github.com/supergiant/supergiant/pkg/core.(*Core).Initialize(0xc420662000)
/home/travis/gopath/src/github.com/supergiant/supergiant/pkg/core/core.go:109 +0xdb
main.main.func1(0xc4203488c0)
/home/travis/gopath/src/github.com/supergiant/supergiant/cmd/server/server.go:35 +0x33
reflect.Value.call(0x172cac0, 0xc42031a140, 0x13, 0x1b24b72, 0x4, 0xc4204df8b0, 0x1, 0x1, 0xc420076040, 0x1ae7be0, ...)
/home/travis/.gimme/versions/go1.10.linux.amd64/src/reflect/value.go:447 +0x969
reflect.Value.Call(0x172cac0, 0xc42031a140, 0x13, 0xc4204df8b0, 0x1, 0x1, 0x2, 0x1, 0xc420322850)
/home/travis/.gimme/versions/go1.10.linux.amd64/src/reflect/value.go:308 +0xa4
github.com/supergiant/supergiant/vendor/github.com/urfave/cli.HandleAction(0x172cac0, 0xc42031a140, 0xc4203488c0, 0x0, 0x0)
/home/travis/gopath/src/github.com/supergiant/supergiant/vendor/github.com/urfave/cli/app.go:487 +0x16d
github.com/supergiant/supergiant/vendor/github.com/urfave/cli.(*App).Run(0xc420599080, 0xc420038090, 0x3, 0x3, 0x0, 0x0)
/home/travis/gopath/src/github.com/supergiant/supergiant/vendor/github.com/urfave/cli/app.go:245 +0x4d0
main.main()
/home/travis/gopath/src/github.com/supergiant/supergiant/cmd/server/server.go:177 +0xc0c

Ok, that would be great, thanks! I didn't see that anywhere in the docs though, but i agree installation should probably be a high priority...please let me know when it is ready!

Thanks for letting us know it was giving you trouble, too. 🙂 Every extra voice helps us prioritize these glaring issues! 🙂 I'll update you as soon as I can!

The docs have been updated! https://supergiant.readme.io/v1.1.0/docs/linux
Hopefully this satisfies this particular issue. If there's no need to keep this issue open, I'll close it. Regarding #596, I'd like to leave it open for now, as a solution for it is still in the pipeline.

Nope, all good, thanks!


Update beam-master version to 20240524.

There is a recent update on the version dependency of google-cloud-storage, so we need a new beam-master image.

R: @damccorm


Lack of a tag list in the sidebar: Users cannot easily retrieve all notes associated with a specific tag.

Summarized Feedback from<EMAIL_ADDRESS>Lack of a tag list in the sidebar, because users cannot easily retrieve all notes associated with a specific tag. This feature is present in Google Keep and is desired in Fleeting Notes.


Wagtail 4 Support

Autocomplete is not working with Wagtail 4.0. It shows the interface but while searching categories it returns nothing. And after a reload the autocomplete field disappears.

Any priority on this?

We're using wagtail-autocomplete 0.9.0 with wagtail 4.0 without issues. We've even tested it with the latest 4.1rc1. You may have to provide sample code, so it can be reproduced.

As far as I could tell the package works perfectly on Wagtail v4 latest release.
I submitted a PR: https://github.com/wagtail/wagtail-autocomplete/pull/130 that only updates the tests and docs for v4 without any changes made the core package files.

reprodu

Is it possible to share the sample code?


258 -  Support Multiplexed on Portal

Issue Number
#258
Purpose/Implementation Notes
Added support for Multiplexed downloads.
Types of changes

New feature (non-breaking change which adds functionality)

Checklist

[x] Lint and unit tests pass locally with my changes

Screenshots
N/A

This is looking good. One recommendation would be to instead of assigning isVisible on every column. We should just loop over the columns and if that property is not defined, set it to true, since that is the default behavior that we want.

assigning isVisible on every column

Completed, thank you for the feedback!


Lighting "linux" app no longer compiles on Mac

Problem
../../examples/lighting-app/linux/main.cpp:182:50: error: no member named 'StartWiFiManagement' in 'chip::DeviceLayer::ConnectivityManagerImpl'
        chip::DeviceLayer::ConnectivityMgrImpl().StartWiFiManagement();
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
../../examples/lighting-app/linux/main.cpp:187:28: error: no member named 'ThreadStackMgrImpl' in namespace 'chip::DeviceLayer'
        chip::DeviceLayer::ThreadStackMgrImpl().InitThreadStack();
        ~~~~~~~~~~~~~~~~~~~^
2 errors generated.

I get this if I just run ./gn_build.sh at toplevel on Mac.  Note that this is compiling this app, but not on Linux.

StartWiFiManagement is only defined if CHIP_DEVICE_CONFIG_ENABLE_WPA but the use here is unconditional.   Note that chip_enable_wifi is only set to true in src/platform/device.gni if chip_device_platform == "linux".
examples/lighting-app/linux/main.cpp  does not include platform/ThreadStackManager.h.  And even if it did there is no platform/Darwin/ThreadStackManagerImpl.h

Proposed Solution
Fix the broken handling of the WPA ifdef.  Not sure what is supposed to happen with the thread stack manager.
@erjiaqing

Duplicate of #4472 I guess.

Duplicate of #4472 I guess.

I guess this is a duplicate of #4472

I guess this is a duplicate of #4472


Trying to vendor a package with a dependency to gopkg.in

Hi,
I am trying to vendor a repository that has a dependency on hashicorp nomad project. I am getting issues with the dependency on gopkg.in and seem unable to solve them.
If i run dep init in my repository i get a Solve error and no generated files. i.e. there is no toml file or vendor file generated so i cannot edit the dependencies.
The error I get is:
 No versions of gopkg.in/tomb.v2 met constraints:     v1: Could not introduce gopkg.in/tomb.v2@v1, as its subpackage gopkg.in/tomb.v2 is missing. (Package is required by github.com/hashicorp/nomad@f-driver.)\
An example main.go that replicates this problem is:
package main

import (
	"github.com/hashicorp/nomad/api"
	"github.com/prometheus/common/log"
	"github.com/hashicorp/nomad/command"
)

func main() {
	client, err := api.NewClient(api.DefaultConfig())
	if err != nil {
		log.Fatal(err)
	}

	log.Info(command.JobGetter{})

	log.Info(client.Agent().NodeName())
}

What version of dep are you using (dep version)?
dep:
 version     : devel
 build date  :
 git hash    :
 go version  : go1.8.3
 go compiler : gc
 platform    : darwin/amd64

What dep command did you run?
dep init
What did you see instead?
 No versions of gopkg.in/tomb.v2 met constraints:     v1: Could not introduce gopkg.in/tomb.v2@v1, as its subpackage gopkg.in/tomb.v2 is missing. (Package is required by github.com/hashicorp/nomad@f-driver.)\

hi, welcome! thanks for posting an issue 😄
i think this may end up being addressed by #1053. though this error
No versions of gopkg.in/tomb.v2 met constraints: v1: Could not introduce gopkg.in/tomb.v2@v1, as its subpackage gopkg.in/tomb.v2 is missing. (Package is required by<EMAIL_ADDRESS>
is weird, because it indicates that the v1 branch is making it through on a gopkg.in v2 constraint. we reimplement gopkg.in's logic internally (it's the only way to map the semantics of that domain into dep's world of constraints and versions), and that just seems like a straight up bug?
if you could post the output of dep init -v, though, that'd be really helpful. if it's really long, a gist is preferred.

If i run dep init in my repository i get a Solve error and no generated files. i.e. there is no toml file or vendor file generated so i cannot edit the dependencies.

this is probably one of our top three issues right now - we need to give you at least something to work with on dep init failure, rather than just kicking you back to square one 😢 😢

Hi,
Thanks I have run this with dep init -v its in the gist here https://gist.github.com/darren-west/561525901184ff789ea4eb6dbe98a624
Thanks

thanks for the gist. i've replicated this locally - the problem appears to be that gopkg.in/tomb.{v1,v2} are ending up sharing a source repository, even though they should be treated separately. it's fine when we only use one of them, but when we use two, we end up getting one's data in the place of the other's. that's why v2 reports only having a v1 branch available - we already visited v1, so it won out.