Brigade Projects Page Discussion

Description
It is time to build a site that shows off the projects of the Civic Technology movement. Let us discuss what we must do to make this site as useful and successful as can be.
 A demo screenshot of a Brigade project list
The Audience

Neighbors looking for finished projects that are already set up for their use in their neighborhoods.
Brigades looking for finished projects to redeploy in their cities.
Brigades looking for projects that still need work to point new volunteers towards
People looking for all available apps within certain category - transportation, health, etc
Press

Features
The site should show off all of the Brigade projects in a filterable way, while encouraging discussion and contribution.
Inspirations

https://www.gov.uk/transformation
https://18f.gsa.gov/dashboard/
http://opengovhacknight.org/projects.html
http://codeforsanfrancisco.org/projects/
http://v3-brigade.herokuapp.com/projects
https://www.govcode.org/repos

Discussion Tasks

[x] Have a discussion about what is needed on a good projects list
[ ] Do some other user testing
[ ] Decide on the best technology to build it in

Technical Tasks

[x] Add the status column to the CfAPI as in CfAPI #133
[ ] Add the tags column to the CfAPI as in CfAPI #193
[x] Build better search functions in the CfAPI as in CfAPI #194
[ ] Build the /projects page!

History
Code for America has attempted this before, creating sites where there was an unsustainable amount of effort needed to keep the data up to date. We've solved that problem now that we have an always current civic technology project list from the CfAPI
As this page will most likely live on the Brigade website, I'm starting this conversation here. The history of the Brigade site is:

v1 - online - Code - A Rails site with many contributors. It served the Brigade well as it was growing. As Code for America became better at supporting the volunteer groups, we needed something different.
The CfAPI was built as reaction to how Brigades were operating themselves. We now meet them where they are, instead of trying to get them to log into our site.
v2 (production) - online - code - Powered by the CfAPI and works great, yet is built quickly with PHP and Javascript. It is kind of a cobweb of dependent parts, and will be hard to have lots of outside developer help on it.
v3 (under development) - online - code - A Python Flask app built for quick and easy improvements.

Quick question: any reason if we're logging these as part of "civic technology movement" that it wouldn't be on CfA main site vs. just on Brigade site? Also, is it just civic technology movement or gov technology movement?

Good question. If what we build proves to be useful for the Brigades, then we can easily include it on our main website as well. Right now, I'm planning to just filter on Brigade projects, not including the Fellows or Governments fine works.
Removing one line of code will include all projects.

My goal when reaching out to @ondrae was to have a site that allowed the best looking, best usable, most popular etc. apps show up in a visual way. Something that's easy to use by non-tech for seeing what we do, yet something that brigades would be interested in seeing what's been released. Tags and search would be key, but the community would rate/:thumbsup:/comment on them.
start out simple, showing screenshots of solutions brigades (and fellowship?) have built. The stuff on cfa.org is just fellowship-built as I understand it.
cream should rise to the top (HN style. Maybe with comments?)
I feel like a site highlighting the best in civic apps is what we're asked for by people coming to hacknight, by local leaders, etc., but that a site just listing all CfAPI repos would be hard to find the cream/best. We'd have to work hard to keep it from being a sea of microservices and old repos. May be opposing goals.
Long term dream: it turns into cfa-npm and you can deploy civic apps with one line ;)

I'll pass this issue around. Looking forward to what we come up with.

We at BetaNYC have been undertaking a similar project. It's a much less sophisticated project, a clientside Javascript app that depends on the Github API for much of its functionality. My design goals are to make Github the only backend to update the projects list –– all data will be fetched via API calls –– and it should be easily deployable to Github pages.
The only problem I have run into so far has been the limitations on how many projects you can search through Github API –– that number it turns out is precisely 14. But if we replace CfAPI with Github for the search functionality, it should work out just fine, as long as the data is complete. I am hoping that CfAPI has a write endpoint, as well.
Aside from everything that "brigade" supports, we are also planning to support a way for project owners to award badges to worthy participants through the civic.json protocol. There is a bit more planning that will need to go into how that works, but this feature will be tapping into a microservice powered by Mozilla's OpenBadges platform, which is a work in progress but seem to be mostly functional.

We have just started to talk about this in KC as a tool to help hack night attendees  connect with local projects.  Our idea is to use CfAPI along with a Google spread sheet to for information that CfAPI and GitHub do not easily provide.
On night a group started to look at the CfAPI data for project ideas.  But the data does not indicate if it is a "good" project or not.  So BretFisher comment would be a great solution for this use. It would be great if we had reviews of some sort or links to media coverage for each project, or  some sort of badge system that volkanunsal talked about in his comment.  It would be great if people that forked and tried to deployed it could comment on their experience.
The fields we are thinking for the spread sheet are:

Category:  Health, Transportation....
Technologies: a detailed list that the project uses, so instead of JavaScript we would get
HTML, JavaScript, jQuery, Bootstrap, Google Map API
Who the lead person on the project is.
Project progress: Idea, Definition, Development/Coding, Deployed, Dead
Link to project graphic, some sort of mockup/screen shot/eye candy
Civic Need that is meet by the project or a better description.

We need this to communicate what we might tell someone at the CFA Summit about a great project we know of and why they should deploy it.
A initial mockup that was done by Oleh Kovalchuke

I'm kind of with Jaime-Alexis on this one just because this is of huge importance to the Code for All community so leaving out those projects would be unfortunate. Maybe we can have another tag/sort that is by program? ie: Fellowship tools, Brigade tools, Code for All, other, etc?

However, I would say that this should be a catalog of tools that are redeployable. I don't think it should include proprietary tools or vendors.

One of the best things CfA could do here I think is publish and maintain JSON files containing moderated lists of "official" tags and categories on a server that supports CORS. The CfApi spec should still allow for arbitrary strings in the categories and tags fields, but these hosted data sources would be easy for people to plug directly into their local project database tools and gently steer data towards a unified taxonomy.

This is a much needed discussion.
We have started to work on Code for America Projects Hub here in Kansas City couple weeks ago (great minds think alike ;-). The design reflects the following goals:
The initial project goals were:

foster multi-brigade collaboration (connect skills and needs across the nation),
increase supply of civic ideas (to broaden the idea funnel),
ease onboarding for new members,
reduce project redundancy,
provide CfA projects overview with ability to filter and sort projects.

Based on these goals we came up with initial wireframes of Code for America Projects Hub, which you can see here: https://github.com/codeforkansascity/Code-for-America-Projects-Hub/issues/1
HTML/CSS (Bootstrap) prototype of the main hub page is almost completed (should be done by Monday).
The Audience and the Needs

Primary: Brigade Members wishing to apply specific skills to specific civic projects.
Primary: Civic minded people, who might have great ideas, but do not have skills or background to hack them.
Secondary: People wishing to use the completed apps.
Secondary: New brigade members wishing to know what is going on.
Secondary: Civic organizations wishing to add and use apps.

Since initial meeting the scope has expanded to include 'People' page (in line with @volkanunsal suggestion). The primary goal of 'People' page is keep brigade members engaged. The secondary goal is to help project leaders find people with skills to work on the project.  Design provides card summary view of brigade member skills and contributions similar to the projects card summary.
@ondrae, adding discussion capability to projects pages is a great idea. Initially the thought was to rate projects by starred and watched; discussion badge adds to project validity. I have added discussion badge to the wireframe.
@cbracy, CfA project badges (Fellowship tools, Brigade tools, Code for All, other, etc) – these should be included in the projects cards and to project filters (see updated mockup).
@volkanunsal, people badges (project leader, idea, hacker-extraordinaire, etc.) – these should be included in the People cards and project cards.

Great ideas everyone.
@BretFisher "deploy civic apps with one line ;)" Check out our work at https://cityvoice-heroku-builder-dev.herokuapp.com/ to see how we've been trying it so far.
@cbracy @Jaime-Alexis If this goes well, we'll put it on the front page.
@themightychris I'm open to any terms or schema we want to use, as long as its not obtuse.
@volkanunsal @tangospring Good ideas! Great wireframes. We have free myBalsamiq available if anyone else wants access.
I'm going to argue that we should keep people out of it for now though. Delay on both the people cards and the badges. Those are both great ideas and useful services, yet they should be their own project. I'm working on something to pull in lots of info about people, from github, attendance at hack night, etc. We can build badges and people profiles off of that project.
For now, we should stick to just displaying and celebrating projects, though we can show off who worked on them. This could include ranking the projects, maybe even comments, but for now I'd rather point discussions about them to wherever that project wants to have its discussions.
I definitely want to put off the idea of connecting people to projects based on skills. Its so desirable yet, just getting the projects appearing in a useful way is a project enough.
I do have some inspiration links for how we could connect people to projects that need help though:

http://www.codeforamerica.org/geeks/civicissues
https://18f.gsa.gov/dashboard/project/midas/
https://assembly.com/

Code for Germany has a great one too: http://codefor.de/projekte

Thanks for your kind words and the inspiration links, Andrew.
I can see from the inspiration samples that you are exited about developing marketing website, where the primary audience is media and curious public. Marketing websites benefit from the exemplary case studies.
Our inspiration came from the trials and tribulations of new brigade members in the relatively small brigade in Kansas City. We need tools and help from other brigades, and we would like to help to develop interesting projects in other cities (or simply branch them to apply locally). We need to know where the help is needed and do we have appropriate skills to help.
The purpose of Projects Hub is more utilitarian: to quickly identify relevant projects out of hundreds. Therefore the primary concern in designing the hub was information density and filtering/sorting.
Additional concern, addressed in the design, is to help public to make an informed contribution of new civic ideas to code (occasionally civic-minded people do not know how to develop the idea).
Screenshot of HTML/CSS prototype as of today:

I think your arguments apply to the marketing website, less so to the projects hub.
Comments/discussion threads preserve history of decision making. It is a good idea for projects web app, and should be encouraged. I do not have a good data on civic project trolling. I guess we could provide an option for disabling comments, if needed.
The 'People' screen and the gamification badges. Agreed it is an enhancement to the hub. The primary goal here is increasing engagement of brigadiers, and promoting cross-brigade collaboration. This is the case, where gamification is useful. The 'People' part of the project is especially important for nurturing small brigades, where we might have deep skills in narrow areas.

I don't think this is necessary for the initial version of a new project browser, but something that might be worth considering in parallel is some sort of optional global ID scheme that allows projects to reference each other. I'd propose something similar to mobile app IDs in reverse DNS format like org.codeforphilly.CyclePhilly. Feed implementations could just generate this from some existing identifier like org.codeforphilly.[repoName] or have a field people can set directly. If a project has one you could document that another project published by another brigade is a fork/deploy of it.

Can't just be the git repo url?
On Mon, Mar 2, 2015 at 4:30 PM -0800, "Chris Alfano"<EMAIL_ADDRESS>wrote:
I don't think this is necessary for the initial version of a new project browser, but something that might be worth considering in parallel is some sort of optional global ID scheme that allows projects to reference each other. I'd propose something similar to mobile app IDs in reverse DNS format like org.codeforphilly.CyclePhilly. Feed implementations could just generate this from some existing identifier like org.codeforphilly.[repoName] or have a field people can set directly. If a project has one you could document that another project published by another brigade is a fork/deploy of it.
—
Reply to this email directly or view it on GitHub.

I think one of the great things about the CfApi and possibly a key reason for its wide adoption is that it doesn't mandate any centralized database, specific vendor, or specific workflow. As altruistic and useful as GitHub feels, they're still a proprietary vendor. This network should outlive most of the hip development solutions of today. Imagine if we set this network up a decade ago and now were dealing with project identifiers anchored in sourceforge URLs?
Also something we've tried to avoid in Code for Philly at least is ingraining in our DNA that one project = one source control repo on github. What if a project doesn't need source code? What if it's just a deploy of another brigade's well-maintained repo and you don't want/need to fork? What if the project consists of many repositories? What if it starts under a volunteer's personal GitHub account and then gets moved to the brigade or a partner's organization?
The great thing about reverse-DNS identifiers is that they can simultaneously be globally unique and descriptive without needing a centralized way to issue and track them -- just make sure all the ones you or your organization create are prefixed with a domain you own. This fits really well with the existing CfApi design and philosophy.
For any brigades that do follow 1 project = 1 git repo under our official organization dogmatically, generating the unique identifier field could be done with a simple spreadsheet formula to change github.com/CodeForMyPlace/MyProject to org.CodeForMyPlace.MyProject. A deploy of an existing app can just be the domain its setup at and you don't need to clutter your organizations github profile with a fork you're going to forget about and never update.
These identifiers will also come in handy once this central project site, or any other tools built to consume CfApi feeds, start getting more complex. Once you want to start storing/displaying any metadata collected outside the projects.csv feed, you need a way to link it to the rows in that spreadsheet that will survive it possibly being reordered or having some values changed. Once you're doing more than displaying whats current in the feed, you really need a stable way to reference individual projects.
They would have to be initially optional to support a gradual phase-in, but I'm not sure how any system built on top of CfApi could reliably do anything beyond displaying a feed with no additional stored data. Maybe more complex CfApi tools than need the identifiers could just ignore projects without them so it could be an opt-in ecosystem like the original CfApi launch was

Notice I said git, not github :)

Ah, my bad. Still though, s/sourceforge/svn/. A repo URL is still more of an implementation detail that should be subject to change through the life of a project and its network of deploys, and shouldn't be a requirement.

Imagine if we set this network up a decade ago and now were dealing with project identifiers anchored in sourceforge URLs?

If they were still valid URLs that represented the project source code’s chosen location, why would this be a problem?
But, my inclination is that if we go for a global ID scheme we not use natural keys for projects, and instead mint unique numeric IDs. Projects will change organizations, new people will take them over, source will move from Github to someplace else, and we’re going to want something permanent but completely un-precious to refer to them. Opaque numbers win at this.

The problem with minting unique numeric IDs is you then need a central authority issuing them, which completely breaks the CfApi's current decentralized nature. A project in code for philly's feed then couldn't be referenced by others until we went to CfA, got an ID number for the project, and then added that ID number to the project in our database. There's a good reason Apple and Google both use reverse DNS identifiers for apps.

You’d need that no matter what to guarantee no collisions, and central authority is sort-of what the CfAPI is doing. We could also use one of these sources of integers in the cloud: http://missionintegers.com, http://www.brooklynintegers.com

Reverse DNS identifiers don't guarantee no collisions any less than cloud integer services if you're relying on feed publishers to populate their own feed. Both offer the same level of guarantee that identifiers are unique but one has a global hosted service dependency. CfAPI is presently implemented as an aggregator of decentralized feeds (what it should be), cfa commons withered because it tried to be a central authority.

Sorry, wasn’t clear: my thinking is that we don’t want to rely on feed publishers to populate their own unique IDs.

If the feed publishers aren't populating unique IDs though, and your storing or associating related data with rows from those feeds, how do you deal with changes in the feed? If I change a project's title and/or URL, how do you know to update the existing project rather than create a new one?
I can't see any way for advance tools that need to store associated data working with self-published feeds unless publishers implement unique IDs. It could be gradually introduced by making the unique ID column a requirement for inclusion in the more advanced tools.

Wow @tangospring you all are having some great progress at http://codeforkc.org/Code-for-America-Projects-Hub/prototype/CfAprojectsHub.htm
We're steadily working on the Technical Tasks listed in the main post.

Hello Bret,
Sorry, I have missed your question, when you asked it.
Here is the GitHub repo for this project:
https://github.com/codeforkansascity/Code-for-America-Projects-Hub .
Relevant links are in the readme.
 Google forms are functional
already, need to be hooked up to front end.
Thanks,
Oleh
Oleh Kovalchuke
(816) 808-6177
On Mon, Mar 2, 2015 at 9:21 PM, Bret Fisher<EMAIL_ADDRESS>wrote:

Can't just be the git repo url?
On Mon, Mar 2, 2015 at 4:30 PM -0800, "Chris Alfano" <
<EMAIL_ADDRESS>wrote:
I don't think this is necessary for the initial version of a new project
browser, but something that might be worth considering in parallel is some
sort of optional global ID scheme that allows projects to reference each
other. I'd propose something similar to mobile app IDs in reverse DNS
format like org.codeforphilly.CyclePhilly. Feed implementations could just
generate this from some existing identifier like
org.codeforphilly.[repoName] or have a field people can set directly. If a
project has one you could document that another project published by
another brigade is a fork/deploy of it.
—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub
https://github.com/codeforamerica/brigade-alpha/issues/89#issuecomment-76880048
.

Thanks Andrew, we have good people here in KC.
Oleh
Oleh Kovalchuke
(816) 808-6177
On Fri, Mar 13, 2015 at 12:46 PM, Andrew Hyder<EMAIL_ADDRESS>wrote:

Wow @tangospring https://github.com/tangospring you all are having some
great progress at
http://codeforkc.org/Code-for-America-Projects-Hub/prototype/CfAprojectsHub.htm
We're steadily working on the Technical Tasks listed in the main post.
—
Reply to this email directly or view it on GitHub
https://github.com/codeforamerica/brigade-alpha/issues/89#issuecomment-79180464
.

I wanted to share the current state of the BetaNYC projects list, which I am working on. We have gotten it to run entirely on the clientside, driven by the CfAPI, Github API and Discourse API.

There is still a bit of work to do for us, including a link between our CKAN deployment and the individual projects. We are also still working on our taxonomy in order to get it in line with NYC's own taxonomy.
Let me know how it looks, works ( or doesn't!).

Wow, good work Volkan, and its live already.
We've almost got support for status in the CfAPI. It can pull either a spreadsheet or a "civic.json" file like you use at BetaNYC.
I really like how you tied it in to your forum as well.

It looks attractive, Volkan. There are a few obvious interaction issues on the very first page: search is button, not an input; icons in the tiles are not descriptive enough (I recommend adding text -- it's fairly  well established design approach). There could be more issues deeper in the site. Talk to someone with usability or IxD background in the brigade.
We, in the other City ;-), are not sitting idle either: http://codeforkc.org/Code-for-America-Projects-Hub/

Hi everyone. We added some new features to the CfAPI that should be useful for the projects pages
@volkanunsal added search! The docs are at http://codeforamerica.org/api/#api-projects
Some examples are:
http://codeforamerica.org/api/projects?q=Bicycle
http://codeforamerica.org/api/organizations/Code-for-San-Francisco/projects?q=Bicycle
We also added support for a project "status" attribute. I still need to write some docs for how to include it. You either add it to your projects list spreadsheet or if you use a GitHub org account as your list, you can add a civic.json file to each project. BetaNyC has examples https://github.com/BetaNYC/citygram-nyc/blob/master/civic.json. Clearer docs for status coming soon, but wanted to let you all know.

@ondrae awesome work!
I noticed an id property along with projects in the responses, are these being assigned by the feed consumer on codeforamerica.org? If so, what field(s) in our feeds do we need to avoid changing to prevent a new id from being generated for a project that already has one?

@themightychris that id property shouldn't be relied upon to remain consistent, as it's generated by the API's database which, at the moment, is designed so that it can be rebuilt from its sources at any time (in which case completely new IDs would be assigned).


The parameter 'options' isnt defined and the method GoogleMapOptions isnt define for class

I have problem with the "options: GoogleMapOptions" part, where the options is not define. Am i missing something? Im new with flutter.
This is my main.dart
**import 'package:flutter/material.dart';
import 'package:google_maps_flutter/google_maps_flutter.dart';
import 'dart:async';
void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
// This widget is the root of your application.
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Google Map',
theme: ThemeData(
primarySwatch: Colors.blue,
),
home: MyHomePage(title: 'Google Map'),
);
}
}
class MyHomePage extends StatefulWidget {
MyHomePage({Key key, this.title}) : super(key: key);
final String title;
@override
_MyHomePageState createState() => _MyHomePageState();
}
class _MyHomePageState extends State {
@override
Widget build(BuildContext context) {
return Scaffold(
  appBar: AppBar(
    title: Text(widget.title),
  ),
  body: Center(
    child: Column(
      children: <Widget>[
      GoogleMap(
        onMapCreated: (GoogleMapController controller) {},
        options: GoogleMapOptions(
          cameraPosition: CameraPosition(
            target: LatLng(37.4219999, -122.0862462),
          ),
        ), initialCameraPosition: null,
      ),
      ],
    ),
  ),
  floatingActionButton: FloatingActionButton(
  ), // This trailing comma makes auto-formatting nicer for build methods.
);

}
}**
where the pubspec i had include
google_maps_flutter:
git:
url: git://github.com/flutter/plugins
path: packages/google_maps_flutter

I'm getting the same problem.

Well i change the version of google_maps_flutter and its work already
On Mon, Mar 18, 2019, 15:21 Jatin Madaan<EMAIL_ADDRESS>wrote:

I'm getting the same problem.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/29031#issuecomment-473796545,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqGtWBQVYf8YXiureRNWfe8RnWEDMtN4ks5vXz5egaJpZM4bkuk5
.

@SuriahKamaruddin Which version are you using ?

was this ever resolved?

Yes, I change the class name.
On Sun, Jul 14, 2019, 13:53 changstagangsta<EMAIL_ADDRESS>wrote:

was this ever resolved?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/29031?email_source=notifications&email_token=AKQ22WCOYOBOB5FTG6SQU7DP7K5MJA5CNFSM4G4S5E42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ36W3A#issuecomment-511175532,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKQ22WHLTFGHCSCHT3436QTP7K5MJANCNFSM4G4S5E4Q
.

could you be more specific?

Hi, could you please confirm if this problem still exists with the latest versions on stable or master?
Thanks a lot

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.

Facin this same issue with the latest version of google_flutter_maps ..Please help!

Could everyone who still has this problem please file a new issue with the exact descriptions what happens, logs and the output of 'flutter doctor -v'  please.
All system setups can be slightly different so it's always better to open new issues and reference related issues.

First create CameraPosition _kGooglePlex = .....//  then use in GoogleMap( initialCameraPosition: _kGooglePlex). as it shows here https://pub.dev/packages/google_maps_flutter. Don't know if I am correct.


Google Location Sharing Error 500

Home Assistant release with the issue:

0.71.0
Last working Home Assistant release (if known):
Uncertain, I believe it was working in 0.70.1 originally, then stopped working in the same version
Operating environment (Hass.io/Docker/Windows/etc.):

Raspian
Component/platform:

https://www.home-assistant.io/components/device_tracker.google_maps/
Description of problem:
Log files are filling up with HTML responses from Google showing an error 500. Location sharing is still working intermittently, however showing delays of well over an hour on updates. (e.g. I left home at 17:20 and this component didn't update until 18:55 with my new location)
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
- platform: google_maps
  username: my_google_account_username
  password: my_google_account_password
  scan_interval: 300

(note that the scan_interval appears to be ignored, and I have tried this both with, and without, that line with no change to behaviour)
Traceback (if applicable):
2018-06-21 08:27:51 ERROR (SyncWorker_1) [locationsharinglib.Service] Unable to parse response :<!DOCTYPE html>

  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 500 (Server Error)!!1</title>

500. That’s an error.

The server encountered an error and could not complete your request.
If the problem persists, please report your problem and mention this error message and the query that caused it.  That’s all we know.
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.6/site-packages/locationsharinglib/locationsharinglib.py", line 386, in _get_data
    data = json.loads(response.text.split("'", 1)[1])
IndexError: list index out of range

Additional information:
Note that the component is still occasionally returning valid results, however my log file is filling up quickly with this and the usefulness of the component is being severely degraded.

After updating to 0.72.1 I am seeing this error less frequently, but it still exists.

Note that this is not the captcha error and is, as far as I can tell, unrelated to that error.

Got the same problem after upgrading to 0.77.1 today. Worked fine in 0.76.3
Log Details (ERROR)
Fri Aug 31 2018 19:54:13 GMT+0200 (centraleuropeisk sommartid)

Unable to parse response :<!DOCTYPE html>

  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 500 (Server Error)!!1</title>

500. That’s an error.

The server encountered an error and could not complete your request.
If the problem persists, please report your problem and mention this error message and the query that caused it.  That’s all we know.
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/locationsharinglib/locationsharinglib.py", line 389, in _get_data
    data = json.loads(response.text.split("'", 1)[1])
IndexError: list index out of range

+1 on the problem above.

I have that problem as well.

I am seeing this in 0.77.3 as well.

I have seen this error from the beginning but lately I have noticed it is much more frequent.  Location reporting still works though.

I have seen this error from the beginning but lately I have noticed it is much more frequent. Location reporting still works though.
Working with what delay though? I find that it's now often hours before it updates, making it basically useless.

Working with what delay though? I find that it's now often hours before it updates, making it basically useless.

At most an hour on my end

An hour is basically hopeless though. I can use location sharing in makes and get a delay of no more than 5 minutes.
This component is badly broken.

Try to remove scan interval and see if you get better results.  I dont have the extreme time differences you do but the error also does not show up each time the component scans on my end.

If you read the report above, you'd see I had tried with, and without, scan internal. You'd also see that it appears to be ignored.
You claim not to have the time lag, yet you say it can be a lag of up to an hour. If that's no lag, I'd hate to see what your consider lag!
Location sharing is useless if it isn't reasonably close to real time. Home assistant isn't a historical archive, it's a home automation system, those need real time (or close to real time) data to be of any use.

As you can see from the locationsharinglib issue reaper7 referenced above, I'm having this problem, too. To me, this is an issue with locationsharinglib, not with the HA component that uses it. If it's "normal" for the server to not respond from time to time, the library should attempt to hide that to some extent. Or if it's not normal, and the library should be doing something differently, then it should be "fixed."
FWIW, scan_interval is ignored by device_tracker/google_maps.py. It is currently hard-coded to query the server every 30 seconds.

v3.0.2 of locationsharinglib makes broken server responses a log warning so at least it is less vocal on the log.


Fix scan pattern

when rule has:
test:1:one
test:2:one
test:1:two
scan pattern is:
test:*:one
correct result should:
test:1:one
test:2:one
but result is:
test:1:one
test:2:one
test:1:two

v4.2.1


Add support for Single Message Transforms (SMTs)

The Kafka Connect API also provides a simple interface for manipulating records as they flow through both the source and sink side of your data pipeline. This API is known as Single Message Transforms (SMTs), and as the name suggests, it operates on every single message in your data pipeline as it passes through the Kafka Connect connector.
Some common uses for transforms are:

Renaming fields
Masking values
Routing records to topics based on a value
Converting or inserting timestamps into the record
Manipulating keys, like setting a key from a field’s value

Hi
SMTs are part of Kafka connect platform and not of the sink
you can look here for an example of how to integrate it
https://github.com/microsoft/kafka-connect-cosmosdb/blob/b5e29740bd53cc0f9d9688e50c8961eb8580a163/doc/README_Sink.md#single-message-transforms

Closing


[Github] feat: change type of class MediaUrlPlaceholderHandler

Why is this change necessary?

What does this change do, exactly?
Use the correct abstract class
Describe each step to reproduce the issue or behaviour.
Decorate the class, see crashing. [https://github.com/FriendsOfShopware/FroshPlatformThumbnailProcessor/blob/main/src/Core/Media/MediaUrlGenerator.php#L11|https://github.com/FriendsOfShopware/FroshPlatformThumbnailProcessor/blob/main/src/Core/Media/MediaUrlGenerator.php#L11]
Please link to the relevant issues (if any).
Checklist

[x] I have rebased my changes to remove merge conflicts
[ ] I have written tests and verified that they fail without my change
[x] I have created a changelog file with all necessary information about my changes
[x] I have written or adjusted the documentation according to my changes
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

—
Imported from Github. Please see: [https://github.com/shopware/shopware/pull/3831|https://github.com/shopware/shopware/pull/3831]

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-37555
[created from NEXT-37555, comment 508265]


Unable to run Migration "201603151731262_AddIndexForPackageDeletes" on LocalDb

I just tried to update my dev-environment and needed to update the database and run "Update-Database -StartUpProjectName NuGetGallery -ConfigurationTypeName MigrationsConfiguration"
Sadly it failed, because the migration<PHONE_NUMBER>31262_AddIndexForPackageDeletes contains a SQL statement which is only available on SQL Enterprise:
Applying explicit migration:<PHONE_NUMBER>31262_AddIndexForPackageDeletes.
System.Data.SqlClient.SqlException (0x80131904): Online index operations can only be performed in Enterprise edition of SQL Server.

Current SQL Migration Script:
Sql("IF NOT EXISTS(SELECT * FROM sys.indexes WHERE name = 'nci_wi_Packages_Deleted' AND object_id = OBJECT_ID('Packages')) CREATE NONCLUSTERED INDEX [nci_wi_Packages_Deleted] ON [dbo].[Packages] ([Deleted], [Listed]) INCLUDE ([Description], [FlattenedDependencies], [IsPrerelease], [PackageRegistrationKey], [Tags], [Version]) WITH (ONLINE = ON)");

Working SQL Script:
Sql("IF NOT EXISTS(SELECT * FROM sys.indexes WHERE name = 'nci_wi_Packages_Deleted' AND object_id = OBJECT_ID('Packages')) CREATE NONCLUSTERED INDEX [nci_wi_Packages_Deleted] ON [dbo].[Packages] ([Deleted], [Listed]) INCLUDE ([Description], [FlattenedDependencies], [IsPrerelease], [PackageRegistrationKey], [Tags], [Version]);

I guess you had a good reason for the "WITH (ONLINE = ON)"), but this leads to problems with non-enterprise environments.

Feel free to PR 😏

Insert "I have no idea what I'm doing"-img here - PR submitted :+1:

"WITH ONLINE=ON" basically is non-blocking when running on production, the other alternative will grab a lock and make things go bad on our production site :)
Thanks for the fix!

But when you run the same migration now on production things will go bad, right? Or is this already applied and therefor is not a problem anymore?

Already applied and thus no more issue.


make_release: 1.8.3

Only thought of it now, but there's also the rpm package thingy
(see https://github.com/Incubaid/arakoon/commit/c9cd6a9b7311d38423d146c09fa07f4a2151ce95 )

Ok


log owner field when creating key

Issue #, if available:
Description of changes:
Testing (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/lgtm


[Feature Request] Back / Forward Buttons on Project View

Pretty much what the title says. This would allow history navegation even when the History window is not directly visible.

I believe I don't have a way to add buttons to the project view. I could add buttons to the history window, not sure if it is the same for you.  Also, there are two shortcuts for back and forward:
                [MenuItem("Window/Gemserk/Previous selection %#,")]
		public static void PreviousSelection()
		{
			selectionHistory.Previous ();
			Selection.activeObject = selectionHistory.GetSelection ();
		}

		[MenuItem("Window/Gemserk/Next selection %#.")]
		public static void Nextelection()
		{
			selectionHistory.Next();
			Selection.activeObject = selectionHistory.GetSelection ();
}

You could change them if you want other shortcuts.

Thanks for the shortcuts man. Yes, buttons in the history windows would be nice!

Will check if I can found a way to add buttons to the project view.

After some research, I think there is no way to add these buttons to the project view yet, we need to wait for Unity to move that window to the new UIElements code.


Support for JobConfiguration.labels

Is your feature request related to a problem? Please describe.
We would like to provide labels for query jobs, which we can't with this library meanwhile it's there in the "legacy" library.
Describe the solution you'd like
The ability to call com.google.cloud.bigquery.QueryJobConfiguration.Builder.setLabels(java.util.Map<String, java.lang.String> labels).
Describe alternatives you've considered
We can fallback to the legacy library, and implement pretty much everything that is related to this again that is in this library, but it seems like a waste of time.
Additional context
None.

Closing via #6367, #6376, #6387 and #6407


Fix markdown

The README.markdown file rendered wrong:

This PR fixes the markdown syntax to have headings properly converted to html.

Thanks!

Sorry lost track of this... got fixed in other PR. Thanks!


DOJO(mentor): Create exercises page

Create the following page
Required components to be created:

Preview card

Components to be created within the page:

Inputs form
Dropdown to switch the lesson module

Misc:

The page will be accessed through /mentor/[lessonSlug]/exercise (could be discussed with engs)

Good feature.


Is this project dead?

Not sure where to ask this question so dropping it here. I noticed a lot of issues are not being looked at. Since we are looking at using kapacitor for the long term, it'd be good to know if the project itself is not going to be decommissioned?

Same question here :/ There's very few mentions of Kapacitor in Influxdata docs. With my team we have the feelings that Kapacitor has been integrated in InfluxDB 2.0 by default, without naming it as alert engine. And no more Kapacitor Enterprise, have the features been moved in another offering ?

The project isn't dead @m4ce @ValD97 .  We are in the process of moving some features from kapacitor enterprise to OSS.  Kapacitor enterprise will be dead, but we are putting resources on OSS.  Sorry if I haven't gotten to all the issues yet.

@docmerlin - thanks for the reply. This is excellent news. I think Kapacitor is the most powerful monitoring tool there is out there at the moment. Keep it up.


Migrate Hi l1a hk to CdfAttributeManager

Algorithm Description:
Use CdfAttributeManager to define Hi L1A CDF attributes

Completed in #714. Thanks to Tenzin


Usage of namespaces causes "unexpected token" error when PHPMD is installed via Phive

PHPMD version: 2.9.1
PHP Version: 8.1.1
Installation type: Phive
Operating System / Distribution & Version: Alpine 3.15

Current Behavior
When I declare a namespace in a class or use a class from another namespace I get an "unexpected token" error. This only happens, when PHPMD is installed via Phive. If it is installed via Composer there is no error.
Expected Behavior
Analysis should work without error when PHPMD is installed with Phive.
Steps To Reproduce:

Install PHPMD with Phive: phive install phpmd
Create a class in a namespace or add a use statement for a class in another namespace
Execute tools/phpmd src text phpmd.xml
You should see something like: Unexpected token: App\Foo, line: 5, col: 11, file: /var/www/html/src/Foo/Foo.php

My example class looks like this:
<?php

declare(strict_types=1);

namespace App\Foo;

use App\Bar;

final class Foo
{

}

Here is my phpmd.xml:
<?xml version="1.0"?>
<ruleset name="PHPMD rule set"
         xmlns="http://pmd.sf.net/ruleset/1.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 https://pmd.sf.net/ruleset_xml_schema.xsd"
         xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd"
>
    <description>All rules</description>
    <rule ref="rulesets/cleancode.xml" />
    <rule ref="rulesets/codesize.xml" />
    <rule ref="rulesets/controversial.xml" />
    <rule ref="rulesets/design.xml" />
    <rule ref="rulesets/naming.xml" />
    <rule ref="rulesets/unusedcode.xml" />
</ruleset>

Checks before submitting

[x] Be sure that there isn't already an issue about this. See: Issues list
[x] Be sure that there isn't already a pull request about this. See: Pull requests
[x] I have added every step to reproduce the bug.
[x] If possible I added relevant code examples.
[x] This issue is about 1 bug and nothing more.
[x] The issue has a descriptive title. For example:  "JSON rendering failed on Windows for filenames with space".

You get an older version of PHPMD (current is 2.12.0) I have no personal experience with Phive. Is that a problem with Phive or did we miss something?

I have installed PHPMD with Phive. I do not get a newer version even if I run phive update phpmd.
Maybe the probelm is caused by this older version like describe in #853.
It would be nice if the newest version could be installed with Phive. Is there a Phar with 2.12.0 yet?

Yes: https://github.com/phpmd/phpmd/releases/download/2.12.0/phpmd.phar
You can get them from https://github.com/phpmd/phpmd/releases in the "Assets" section from each release. This is our most up-to-date channel for both composer and phar new releases.

It seems that the signature has not been uploaded to releases since 2.10.0. That's why phive refuses to install versions newer than 2.9.1.

I can confirm that. If the --force-accept-unsigned option is used the latest version is installed which does not have the described bug. However, this defeats the purpose of using Phive. It would be nice to have a GPG signature for the latest PHPMD version.

@kylekatarnls I believe the release just has to be signed with your GPG key like before. If you look at https://github.com/phpmd/phpmd/releases/tag/2.9.1 you will see it contains the asc file, however, the latest version does not: https://github.com/phpmd/phpmd/releases/tag/2.12.0
This is unfortunately not something we can do, as this requires your GPG key. I did find this HN thread, with a link to the debian wiki on how to do this: https://news.ycombinator.com/item?id=11494997
The top comment suggests a much easier solution of simply signing the release with -s, which in the man pages says:
       -s, --sign
           Make a GPG-signed tag, using the default e-mail address’s key. The default behavior of tag GPG-signing is controlled by tag.gpgSign configuration variable if it exists, or disabled otherwise. See git-config(1).

I have not tried this myself, but more than happy to look into this further if you need any help.

Thanks.
I'm not sure we'll be able to recover the previous PGP key<EMAIL_ADDRESS>So this will be the new key for signature of the PHAR from 2.10.0:
Fingerprint: 9882 DD2B 3881 3C08 EA65 1B69 A4E5 5EA1 2C7C 085C

PHPMD (PHPMD Phar Releases Signer<EMAIL_ADDRESS>
All new releases are now downloadable via Phive.


Find Replace

Type: Feature Request
Please add a dropdown for Find String with history of searched strings
VS Code version: Code 1.85.1 (0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2, 2023-12-13T09:49:37.021Z)
OS version: Windows_NT x64 10.0.19045
Modes:

Are you aware that the UpArrow key already recalls history?

/duplicate of #23099
Please upvote that issue.
In the meantime, as mentioned above, you can use UpArrow/DownArrow or Alt+UpArrow/DownArrow to navigate history of search and replace fields

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


error menu mobile

Thanks!

hi, i have also facing this issue,how can i solve ? help me

@DevBala-6
do the following
pull the latest upate from the master branch
run php artisan vendor:publish --force
run php artisan config:cache

Now open the url in mobile and reload the page again.
Thanks,

Hi @shubhwebkul
Header is not showing in mobile view

fixed


K20 HIC waits until USB is configured to enable target power

Previously the K20DX128 HIC would immediately enable the target power switch in gpio_init(). This can cause problems with certain computers on boards (i.e., upcoming MIMX6RT1050-EVK) that have high inrush currents. This change causes the interface to wait until USB is configured to turn on the power switch.

Added gpio_handle_usb_connected() to gpio.h. This is is stubbed out for all HICs other than K20.
Interface main function calls gpio_handle_usb_connected() when USB is configured, and when it is about to be disconnected. The bootloader is not modified.
The K20 HIC implements this function to enable the target power switch only after high power has been negotiated with the USB host. It also turns off the power switch if USB is being disconnected.

@flit this change requires that FRDM boards are connected to a USB port with a data connection for the device to be powered right? That means you wouldn't be able to run off of a wall charger or portable battery pack. That seems like a fairly big downside to this change.

@c1728p9 That is a good point—you do actually need a USB host to configure the device. On the other hand, it's not USB compliant to (attempt to) draw more than 100 mA prior to configuration. For some PCs, boards that draw > 100 mA will simply not power up and are unusable. This is clearly not acceptable for customers, so we need some solution.
Some boards have a 5V power jack and/or can be powered via the target's USB connector. But not all.
Maybe we could have a timer? If USB is not configured within a certain time, then go ahead and flip the power switch.

@c1728p9 @cederom Do either of you have any preference about how to work around this? We definitely need to be USB compliant by default for high power boards, so must wait for USB configuration to enable the power switch.
Options:

Add macro so power switching after USB config is only done on boards where max current draw is greater than 100 mA.
Add timeout for USB config. After timeout, we enable the power switch anyway.
Combination of above two.
Other options?

Keep in mind that for boards that can accept Arduino shields or other expansion boards, you can easily exceed the 100 mA limit. So the first option may not be very good, as you could only apply it to boards that did not have expansion capabilities.

@c1728p9 @cederom Added 5 second timeout for USB config, after which target power is enabled.

Hello @flit :-)
The first thing that comes to my mind is some sort of board-specific fix/quirk in board init/setup if the problem relates only to that particular board.. not necessairly to all boards out there..
If there are two USB connectors on the board, at least one of them should be used to power the board.. even if USB is not configured.. that may be user design that does not use USB at all but still wants to take power from USB port and power adapter as @c1728p9 mentioned..
From what  I understand the problem is with some target powered from DAPLink USB connector takes too much of energy.. but when it is connected with DAPLink and interface firmware works then what is exactly the problem? Could you please explain in detail? Is it about Target draining more than 100mA with no USB configured? If so this looks like target firmware or board issue..?

@cederom In short, the problem was that DAPLink on the K20 HIC was not USB compliant. The interface app would always turn on the target power switch prior to enabling USB. If the board drew more than 100 mA between when the switch was enabled and when USB was configured, certain PCs would disable the port.
We noticed this problem on the MIMXRT1050-EVK board since it is particularly power hungry. However, any board that has expansion capabilities (i.e., Arduino shield) can easily draw more than 100 mA. So this is a problem that most users could face.
The 5 second timer is to support powering via a USB wall wart—specifically the case that @c1728p9 mentioned. If DAPLink is running on the K20 HIC, then by design we know USB has been connected. If USB is not configured within 5 seconds, it's almost certainly because there is not a USB host.
If you can suggest a better way to identify that a USB power source without a host has been connected, I'll be happy to hear it! Maybe we could disable the timer once USB communication has started (first SETUP packet received from host), rather than when USB is configured. The downside to this is that it would require modifications to the USB stack instead of being entirely contained in main.c.
Fyi, we're going to production with this version of the firmware due to time constraints. (The board support is on commit flit/DAPLink@9cf8778c8f8f086, which will eventually be upstreamed.)

Thanks for more details @flit :-) Why don't we just power on the target right after USB is configured.. and keep the target in reset or power down state until then? :-)

Hi @cederom, your suggestion to keep the target in reset or power down until USB is configured, at which point we power on the target, is exactly what this PR originally did. (And still does, with the addition of the timeout.) But without the USB configuration timeout, we can't support USB wall warts.

ah, so this is the timeout not delay, then all fine..? :-)

/morph test

Right 😄  It's just a timeout, not a delay.

Hi @c1728p9, Do you have any concerns about the implementation? Have you had a chance to review the code?

@c1728p9 Do you think this change should be applied to the KL26Z HIC? I didn't want to touch that since it affects the microbit's behaviour. But on second thought, users can power external devices via the microbit's expansion header, so the same issue may be encountered.

Changed timeout to 2 seconds and changed gpio API to gpio_set_board_power(bool powerEnabled). Rebased and squashed.

Applied changes from review commands, rebased, and squashed.

/morph test

/morph test


Wuandy/pg firestore

Hey there! So you want to contribute to a Firebase SDK?
Before you file this pull request, please read these guidelines:
Discussion

Read the contribution guidelines (CONTRIBUTING.md).
If this has been discussed in an issue, make sure to link to the issue here.
If not, go file an issue about this before creating a pull request to discuss.

Testing

Make sure all existing tests in the repository pass after your change.
If you fixed a bug or added a feature, add a new test to cover your code.

API Changes

At this time we cannot accept changes that affect the public API.  If you'd like to help
us make Firebase APIs better, please propose your change in a feature request so that we
can discuss it together.

Please close, merge, or comment. We plan to close stale PRs on November 28, 2023.


Validate signatures of builds

Right now the rust binaries are accompanies by gpg signatures, but rustup does not check them.
I don't want to bring in native dependencies unless they are dead simple to build. We should probably try the gpgme bindings first, since those would be compatible with our existing gpg keys. If that doesn't work out then we can explore more exotic options.
Previous thread.

What about calling out to an external GPG process, like rustup.sh did?

What about calling out to an external GPG process, like rustup.sh did?

This is what the gpgme bindings do effectively.

cc https://github.com/rust-lang-nursery/rustup.rs/issues/242

@DemiMarie I'd rather not do that because we can't guarantee the presence of GPG, and I want everybody to get the advantage of signature validation.

I want everybody to get the advantage of signature validation.

:+1: This should not be optional, preventing downgrade attacks.

https://pijul.org/openpgp/ may be part of the solution.

Anything involving PGP will have to be optional.

Ok, after writing both Thrussh and the OpenPGP crates, here are some thoughts:

Anything involving GPG will have to be optional.

This is a GnuPG issue. The binary called GPG changes name with different versions (which leads to really unstable situations in systems like NixOS, where it's normally called gpg2, but also sometimes gpg inside a nix-shell, depending on the channel).
First of all, I am really grateful to the the authors of OpenPGP and GnuPG for getting the world to use encryption and signatures and an almost easy way.
That said, I also realize that RFC 4880 is really unclear and ambiguous, even on really important things. GnuPG has the merit of being the main available implementation. It's also well tested (despite being 200000 lines of C, not counting crypto).
However, according to my tests, GnuPG does not always include cryptographically important parts of OpenPGP, such as "modification codes", an OpenPGP feature described in the RFC, which are more commonly called MAC in other cryptography libraries. This might allow an attacker to modify an encrypted message without decrypting it.
If we try to implement OpenPGP in Rust, there are really big issues with the format, which IMHO do not make it suitable to use in applications such as rustup:

The scope of a signature is never clearly specified. In RFC4880, hashes of "data" are signed, but "data" is never clearly defined. GnuPG apparently chose to sign the hash of the contents of files, opened in binary mode (i.e. without converting \n to CRLF). This lack of clarity in the RFC is really problematic, as it might allow an attacker to change file names in the signature of multiple files. To achieve compatibility with GnuPG, Rustup packagers would have to make sure only tar archives get signed, and would also have to describe this very clearly to downstream packagers.

The RFC is very complicated for simple things, such as length encoding. For instance, the length of a 512 bytes RSA key can be encoded in four different format, which might allow implementations to save up to 3 bytes, compared to a simple big endian u32. And as Rust supporters probably know, it's quite easy to get array lengths wrong. If you want to achieve interoperability with the world outside Rust, you'll have to rely on C code decoding array lengths from a tricky format.

I realize there are lots of awesome C programmers out there, and the authors of the above mentioned software are clearly among them.

Btw, I'm currently thinking of a format with the same features as PGP (a web of trust using the existing infrastructure, encryption and signatures).
I'm seriously thinking of reusing the SSH RFCs, because they are really well defined, precise, well tested, and able to encrypt/sign large amount of data efficiently.

I don't think a web of trust makes sense for rustup. You have to trust on first use anyway, so it seems much simpler and more straight forward to just use TOFU.

@vks: Before writing the OpenPGP crate, I used to believe this wasn't the case, and used to think that the web of trust was really cool. I'm not so sure anymore. Here is some arguments:

https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html
http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html

This is a GnuPG issue.

It's an issue for any method which attempts to use a user's existing web of trust to validate downloads: it's unrealistic to have that as a prerequisite to install toolchains via rustup.
As far as I'm concerned, the plan was always to just encode the public key inside the rustup binary, and have a pure-rust solution to verify the signatures of downloads against that public key. The "web of trust" only comes into play for someone installing rustup for the first time, and if they're doing that via their package manager, then even that's unnecessary.

Then the best method seems to be:

Don't use PGP.
Sign with Ed25519.
Make it so that people organizing Rust events have a copy of the key (Ed25519 keys are really short), and show it on the first slide of the event. Key hashes are not sufficient, as demonstrated by GnuPG.

This doesn't solve everything, though: when the key or the cryptosystem is compromised, you'll have to "revoke" the key.

Make it so that people organizing Rust events have a copy of the key

While that certainly does not hurt, I don't think it is necessary. The first time you install rustup, you have to trust the binary anyway (unless we get reproducible builds). So you have to trust that the rustup server and your https connection to it are not compromised, and that you get the right rustup binary with the correct hardcoded key.
I don't think revocation is a problem with TOFU (see ssh). You would have to just get the new key via https.

I'd advocate for adopting The Update Framework for verifying the security of rust distributions.
There are numerous advantages of the The Update Framework especially semantics for key rotation, the use of only strong cryptography in the spec and json format data files etc. The Update Framework was designed specifically for the relevant use case of securing software distributed through a repository.
https://theupdateframework.github.io/

@zmanian https://github.com/rust-lang/crates.io/issues/75

As far as I'm concerned, the plan was always to just encode the public key inside the rustup binary, and have a pure-rust solution to verify the signatures of downloads against that public key

Yeah that is my expectation. I don't know any other solution that can work in practice. We can't expect users to do any manual steps beyond clicking something on our website. rustup.sh did this while still using GPG though - it just told it which keys to use.

This doesn't solve everything, though: when the key or the cryptosystem is compromised, you'll have to "revoke" the key.

Yes, thanks for mentioning that. Key revocation is important.
@zmanian Thanks for bringing that to my attention. Looks very promising. We should consider it stongly.
Thanks for all the great feedback, all.

I've gathered up some code for this in https://github.com/djc/rust-sign/blob/master/src/main.rs; I think this provides pretty much all the pieces required. Integrating this into rustup.rs will require more context/design, I guess?

@djc We might want to have something more complex like The Update Framework mentioned above.

@vks that's not really a helpful response, in that (a) you're suggesting the work I did has little to no value, and (b), you're not providing a clear way forward.
I came here via @brson's someday list thread and implemented the thing he mentioned there (using ring to sign/verify with Ed25519). Clearly, to be useful, this needs to be integrated into rustup.rs. Clearly, that's not what I've done in the rust-sign repo. Still, the code in the rust-sign repo provides most of the crypto-related pieces of Ed25519 signing and verification, so I believe it provides some value. I might be able to contribute more of my expertise and/or time here, but, as I said, I don't think I can do so unless more context/design/direction is provided.

Oh, and it seems that The Update Framework predates the JOSE (JSON crypto) family of IETF RFC's, so at least some of the ways the spec does crypto feels a bit antiquated. It might be better to adopt the roles and process from TUF without going by the letter of the spec.

@djc You were asking for more context/design, and I think TUF provides this. In no way did I intend to suggest your work had little value or to provide a clear way forward.

@djc Thanks for putting that together! This looks like a great basis to work off of. Offhand I don't have a full design to suggest, and I need to read the TUF documentation still, but unless it seems strongly unadvisable I'm inclined to keep a pure-Rust solution, so maybe we can do a design influenced by TUF, even a standalone TUF-like library that all Rust programs can take advantage of.
There are a lot of pieces at play in Rust distribution. This is just a brain-dump of how things work today and the binaries that need to be verified:

The rustup binaries themselves are downloaded from addresses like https://static.rust-lang.org/rustup/dist/$triple/rustup-init, along with accompanying .sha256 files. Presumably the binaries need to be verified.
The rustup binaries are generated today on travis and appveyor, which is a fairly questionable place do be doing that, but given that that's where they are being built, it would be nice to have seperately-revokable subkeys for these builds.
There are several steps to acquiring the rust binaries: first rustup downloads the .toml manifests from addresses like https://static.rust-lang.org/dist/channel-rust-beta.toml. Since these contain URLs that rustup follows I guess they need to be verified.
From there rustup downloads several tarballs from the archives in directories like https://static.rust-lang.org/dist/2016-09-12/index.html. Each of these needs to be verified.
These binaries are generated by the rust build slaves, and the manifests on the build master. We can probably generate the signatures for all in one batch job on the build master. Again it would be nice to have a seperately-revokable key for this machine.
Another thing to take into account is that I plan to fix the notorious checksum failures by adding yet another layer of indirection to both the rustup and rust download process (basically, have one single file that acts as a "symlink" to an archive directory). Since this contains data that rustup will interpret it probably also needs to be verified.

I'm strongly interested in rewriting the entire release build process, but it seems unlikely to happen soon. So lots of complex legacy stuff to accommodate.
To make this more concrete, what I might expect the data used by rustup to end up looking like on static.rust-lang.org, based on how things are organized today, is:

static.rust-lang.org/

rustup/current.toml - this is the single "symlink" file that indicates: the location in the archives to find the current release; the checksum of the name of that location; the signature of the name of that location. This solves the previously-linked checksum problem by having a single stable URL that rustup looks for (the problem is caused by having two such URLs today that must be in sync, and sometimes aren't). It doesn't exist today.
rustup/archive/$version/$target/rustup-init - the rustup binary in the archives. These are uploaded to unique locations for each release and exist today. The 'current.txt' file contains the necessary info to derive this path.
rustup/archive/$version/$target/rustup-init.sha256 - the (existing) checksums
rustup/archive/$version/$target/rustup-init.sig - the (new) signatures
dist/rust-manifest-nightly-current.toml - as before, this is a new file that indicates where in the archives to find the rust-manifest-nightly.toml file (which today is not downloaded from the archives). It contains the metadata, that data's checksum, and its sig all in one file.
dist/$date/rust-manifest-nightly.toml - the archived manifest
dist/$date/rust-manifest-nightly.toml.sha256 - the (existing) checksums
dist/$date/rust-manifest-nightly.toml.sig - the (new) signatures
dist/$date/$package.tar.gz - the various tarballs installed by rustup
dist/$date/$package.tar.gz.sha256 - the (existing) checksums
dist/$date/$package.tar.gz.sig - the (new) signatures

This is all of course open for debate. An interesting thing to note here is that the sigs are stored in two different ways: in the "current.toml" files they are in toml keys in the file and are signatures of other toml keys; in other cases they exist next to the complete files they are signing.
Though I think putting signatures next to the bins is a generally good forward-compatible strategy with any changes to the way we might treat the manifests in the future. We could also consider embedding signatures of the tarballs directly in the manifests, though that doesn't work in a straightforward way for the manifests themselves.
I'm sure there's lots more to consider.

How do you guys like rsaltpack?  It implements saltpack's encoding of MessagePack format using sodiumoxide.

@brson What do you think are the next atomic steps to moving this forward?
Should we formalize what information the build system should publish?

I think we should figure out how/how much the update framework applies to the rustup ecosystem, determining what abstract elements we should implement. Then, the next step could be figure out a design for making those abstract elements concrete.

What if we write something establish a data structure and some validation code the key hierarchy and key validity period for the Update Framework?

@djc TUF applies to rustup in a pretty straghtforward way.
@zmanian I pondered writing a TUF implementation.
What has stopped me so far is that I don't currently have the time/energy.

In discussing this a bit with @brson yesterday, one thing we realized was that we don't actually need to check the signature of downloaded artifacts, only the manifest. Each manifest contains a cryptographic hash of the artifacts being download (e.g. sha256) so as long as we verify the signature of the manifest that should transitively apply to the artifacts we then later download.
(just wanted to note that here)

I think we could add the TUF required data to the manifest files and an appropriate signature. Very good observation @alexcrichton

In thinking about how to solve the checksum problem I've also been thinking about how to make that solution forward compatible with signing. So I've finally read the TUF spec, and I think I want to just use TUF wholesale.
My understanding of TUF invalidates some of the plans I had to fix the checksum problem, and TUF actually has a scheme for solving the checksum problem. But implementing and rolling out TUF will take some time. So what I'm probably going to do is come up with a quick fix for the checksum problem as a temporary hack, with the expectation to throw it away after TUF is implemented.
As far as implementing TUF goes I have not starting thinking about the strategy yet. Ideally we would leverage the TUF test suite to validate a Rust implementation, but the reference implementation seems to be written in Python, which makes the matter tricky.

The ideal way to implement TUF might be to create a Rust API, create a C API on top, create Python bindings on top of that that conform to the reference implementation, then use the reference implementation's test suite to test conformance. As a nice side effect we'd then provide the world a TUF that can be used via C.

I made an irlo thread describing how I imagine solving several problems in the rustup distribution format: https://internals.rust-lang.org/t/future-updates-to-the-rustup-distribution-format/4196. It includes a scheme for integrating TUF.

I LOVE this!!!!
The biggest advantage of having a portable TUF implementation with a C API
is that ex.  OCaml and Perl (whose package managers are totally insecure)
could use it.  I know that the insecurity of OPAM (the OCaml package
manager) has killed off my interest in OCaml development.
I would also like to see TUF applied to Cargo.
On Oct 13, 2016 1:34 PM, "Brian Anderson"<EMAIL_ADDRESS>wrote:
The ideal way to implement TUF might be to create a Rust API, create a C
API on top, create Python bindings on top of that that conform to the
reference implementation, then use the reference implementation's test
suite to test conformance. As a nice side effect we'd then provide the
world a TUF that can be used via C.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/rustup.rs/issues/241#issuecomment-253582724,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGWB5cjExDadtVZH-prOFvWQ27ChGy3ks5qzmufgaJpZM4H9Zcu
.

@DemiMarie Unrelated to this specific issue, but for your information migrating OPAM to use TUF is a long-standing goal of the OPAM devs, has had received active development effort and is on the roadmap for v2.0.

The ideal way to implement TUF might be to create a Rust API, create a C API on top, create Python bindings on top of that that conform to the reference implementation, then use the reference implementation's test suite to test conformance. As a nice side effect we'd then provide the world a TUF that can be used via C.

This sounds great. If there's any tension between a library usable from other languages, and a generic crate easy to use in Rust, I guess I'd vote for the second one.
My specific use case is Pijul: many projects are distributed as git repositories today (like NixOS), and being able to sign these using TUF would be really cool.

@pijul be sure to sign SHA-2/Blake2b hashes of a Merkle tree, not the SHA-1 hash that Git does on its own (so you will need to do the hashing yourself).

The ideal way to implement TUF might be to create a Rust API, create a C API on top [...] As a nice side effect we'd then provide the world a TUF that can be used via C.

Argh a TUF implementation was something I was interested in doing before I ever wrote a line of Rust. Even met with the TUF authors, and this benefit of a Rust implementation was definitely interesting to them. But then I went nowhere with it.
Perhaps it's less intimidating to start with Rust updates as a much narrower use case than Crates.io...

It looks like I can't personally devote any time to implementing TUF in the near future, but I'd encourage anyone else to start on it.

Work on a Rust TUF is going on here.
https://github.com/heartsucker/rust-tuf

@zmanian oh wow thank you! Excited to see where it goes.

Oh hai @brson. Checking in here to say that I'm almost done with delegations on rust-tufwhich means you could get a large chunk of the signing / verification benefits of TUF right very soon. Some of the other things (slow data, complete disaster recovery) haven't been implemented yet, so it's not TUF Compliant, but that shouldn't stop getting this in. There's some basic docs already, and plugging this in shouldn't (I hope) be too difficult.
Anyway. Is there a roadmap or plan to get this implemented? Because it requires some work on the maintainers' side like setting up keys and whatnot.

@heartsucker, @alexcrichton and I had a chat about tuf integration. Here are the scattered notes for future reference: https://public.etherpad-mozilla.org/p/rustup-tuf

@brson Would it be possible for you to make a milestone / project here for collecting issues related to this? There are some tasks that I might be able to delegate for this. I think one of them that I could offload to someone else would be update to hyper 0.10 since that's the version rust-tuf is built on.

@brson Would it be possible for you to make a milestone / project here for collecting issues related to this? There are some tasks that I might be able to delegate for this. I think one of them that I could offload to someone else would be update to hyper 0.10 since that's the version rust-tuf is built on.

There is additional discussion of the particulars of the TUF implementation on issue #1217.

Has anyone yet mentioned or thought of using using signify (originating from OpenBSD IIRC)?
There seems to even be a Rust implementation (docs contain various links).

Can we just use libsodium?  Portable.  Simple.  Fast.
On Feb 22, 2018 6:33 PM, "Katze"<EMAIL_ADDRESS>wrote:

Has anyone yet mentioned or thought of using using signify (originating
from OpenBSD IIRC)?
There seems to even be a Rust implementation
https://docs.rs/crate/signify/0.4.1 (docs contain various links).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/rustup.rs/issues/241#issuecomment-367859320,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGWByv2C3LA4WXtIO1XKpfd7-0UENLpks5tXflBgaJpZM4H9Zcu
.

The point of using TUF is that it provides strong security properties from the metadata outside of just "we used a good signing scheme / hash algorithm." Signify and libsodium do not provide that.

I haven't read through the entire thread, but just since it wasn't mentioned yet: If you want to verify PGP signatures, there's now Sequoia, written in Rust! Not sure how that is useful in context of TUF though, hope this comment isn't just useless spam.

@dbrgn Sequoia looks interesting (I've been following it for awhile), but it seems like rustup would probably want to use the openpgp crate that Sequoia is based on (which I'm a bit confused about, because the one on crates.io hasn't been updated for 2 years)

Rustup has been quietly verifying GPG signatures on channel downloads for some time now.  I'm going to close this, although there's still the trust chain consideration I think other issues cover that quite well.

@kinnison does it fail if the signatures cannot be obtained or verified?

@DemiMarie Currently it warns, though nobody has reported the warning showing up.  We intend to shift it to an error soon.

Is there a way to force it to error?

@DemiMarie Currently it warns, though nobody has reported the warning showing up. We intend to shift it to an error soon.

What is the issue that tracks that? I thought it was this one. There should be an open issue until it is fixed.

The high level tracking issue is here - https://github.com/rust-lang/rustup/issues/2028 and I've updated it with the current state of play AIUI.  If you feel I should reopen this issue as well for tracking that then I'm okay to do so.


Automatic transfer of raw files from RawTherapee

Using the snap version 2.10 I am not able to automatically transfer raw files from RawTherapee as the required file /tmp/<image_name>.tif cannot be found although the file is definitely in that place.

A snap app has no access to the root / system partition. Hence no access to /tmp
It's a real problem as some gimp plugins may need that /tmp place.
See if it's possible to tell to RawTherapee to send its files to another place than /tmp, some place within reach of gimp-snap ( /home or /media, /mnt, /run/media granted you connected gimp-snap to the removable-media interface ) ?


Debugging statements flagged in ENVIRONMENT-DIVISION and DATA-DIVISION

Development environment used

Editor Platform

[ x] Visual Studio Code
[ ] CodeReady Workspaces
[ ] Eclipse Che
[ ] Standlone Theia

Platform Version:
VS Code version 1.46.0
Z Open Editor Version 0.5.1
Operating System (on which VS Code runs such as Windows 10 2004, otherwise name and version of platform such as OpenShift v4.3):
Windows 10 Version 2004
Linux Ubuntu 16.04 LTS.
Java Version (when using VS Code or Theia, extecute java -version and paste the details here):
OpenJDK Runtime Environment (build 1.8.0_252-b09)
Eclipse OpenJ9 VM (build openj9-0.20.0, JRE 1.8.0 Windows 10 amd64-64-Bit Compressed References 20200422_667 (JIT enabled, AOT enabled)
OpenJ9   - 05fa2d361
OMR      - d4365f371
JCL      - 5e623848e9 based on jdk8u252-b09)
Logs attached (see here how to get them): yes/no

Problem Description
According to IBM documentation for Enterprise COBOL, SOURCE-COMPUTER paragraph:
"You can code debugging lines in the environment division (after the OBJECT-COMPUTER paragraph), and in the data and procedure divisions.   "
Debugging lines placed in the ENVIRONMENT-DIVISION and DATA-DIVISION are flagged with  ' "BASIS" expected instead of this error.' Debugging lines in the PROCEDURE-DIVISION are not.
Detailed steps for reproducing the problem:
Add an ENVORONMENT-SECTION.
In the ENVIRONMNET-SECTION add a CONFIGURATION-SECTION.
In the CONFIGURATION-SECTION add a SOURCE-COMPUTER. IBM-370 WITH DEBUGGING MODE. paragraph.
Optionally, add an "OBJECT-COMPUTER. IBM-370. paragraph following the SOURCE-COMPUTER paragraph.
Add  "       D     DISPLAY 'DEBUGING mode enabled." statements to the ENVIRONMENT-DIVISION, DATA-DIVISION and PROCEDURE-DIVISION.
Observed behavior:
The statements added to the ENVIRONMENT-DIVISION and DATA-DIVISION are flagged as described above. This is true both with and without the OBJECT-COMPUTER paragraph after the CONNFIGURATION-SECTION in the ENVIRONMENT-DIVISION.
Designed behavior:
According to the IBM documentation quoted above, the debugging lines should not be flagged in the ENVIRONMENT-DIVISION or the DATA-DIVISION.

@edrubins Hi Ed, I think there may be some confusion on the DISPLAY statements being placed in the Environment and Data Divisions.  The IBM documentation doesn't really make it clear, but any statements placed in those divisions still need to be valid statements for those divisions.  Display statements are not valid for the Env and Data divisions.  When WITH DEBUGGING MODE is present, all lines with a 'D' in column 7 will be compiled and therefore must be valid statements and syntactically correct.  If you try compiling a program with those DISPLAY statements in those divisions, you should get a compile error.


log_core: Add Kconfig symbol for init priority

Users may want to do some configuration after the kernel is up, but before initializing the log_core. Making the log_core's init priority configurable makes that possible.
Signed-off-by: Ian Oliver<EMAIL_ADDRESS>

@cfriedt if/when this gets merged it would be useful for us to get the change backported to the 2.7 branch


请教一下，打成jar包后运行后：Cannot determine embedded database driver class for database type NONE

java -jar xupdate.jar  报错：
WARN 24080 --- [           main] ationConfigEmbeddedWebApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'accountController': Unsatisfied dependency expressed through field 'accountService'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'accountService': Unsatisfied dependency expressed through field 'accountMapper'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'accountMapper' defined in URL [jar:file:/E:/JavaProject/XUpdateService/target/xupdate.jar!/BOOT-INF/classes!/com/xuexiang/xupdateservice/mapper/AccountMapper.class]: Unsatisfied dependency expressed through bean property 'sqlSessionFactory'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'sqlSessionFactory' defined in class path resource [tk/mybatis/mapper/autoconfigure/MapperAutoConfiguration.class]: Unsatisfied dependency expressed through method 'sqlSessionFactory' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSource' defined in class path resource [com/alibaba/druid/spring/boot/autoconfigure/DruidDataSourceAutoConfigure.class]: Invocation of init method failed; nested exception is org.springframework.boot.autoconfigure.jdbc.DataSourceProperties$DataSourceBeanCreationException: Cannot determine embedded database driver class for database type NONE. If you want an embedded database please put a supported one on the classpath. If you have database settings to be loaded from a particular profile you may need to active it (no profiles are currently active).
Description:
Cannot determine embedded database driver class for database type NONE
Action:
If you want an embedded database please put a supported one on the classpath. If you have database settings to be loaded from a particular profile you may need to active it (no profiles are currently active).
再开发模式没有问题，请问一下这个该怎么配置

用maven 命令打的jar包


payment links /payment pages

I don't think there is presently a way to make subscription payments with this sdk. I have a payment link, I want to subscribe clients to that link and charge them.

I am sorry there's no support for subscriptions. That should be handled on the server-side not the client-side. This package is just to receive one-time card/bank payments.


Add ESP32-DevKitC evaluation boards

SUMMARY

I have added 5 out of 7 ESP32-DevKitC V4 evaluation-boards. I did not add two of those 7 because their datasheet recommended no new designs. I imagined using this for female pin headers, so the evaluation-board can be put in the socket. I added two layouts, one with lots of silkscreen prints and one without these, because for amateurs like me it is easier to look where the USB port is.
DATASHEETS / REFERENCES

ESP32 DevKitC Getting Started
ESP32-WROOM-32E / UE Datasheet
OPEN QUESTIONS / UNRESOLVED ISSUES

CHECKLIST

[X] I have read and followed the library conventions¹.
[X] For packages, I followed IPC7351C (see details in library conventions).
[X] For modified elements, I bumped their version number².
[ ] I already used the new library elements in a design and verified their correctness (optional).
[X] I'm the copyright owner of the added content (i.e. the changes are made by myself, not copied/imported from somewhere else).
[X] I agree to publish all my changes under the CC0 Public Domain License³, allowing everyone to use and modify the content without any restrictions.

¹ Library Conventions: https://docs.librepcb.org/#libraryconventions
² Minor version bump if only metadata was modified (e.g. "0.1" -> "0.1.1"), major version bump if functional changes were made (e.g. "0.1" -> "0.2")
³ CC0 Public Domain License: https://en.wikipedia.org/wiki/CC0

Hello, is there any chance this PR will be reviewed anytime? Or is this in the current stage of development not feasable?

Hi @Soraxem,
Sorry for the long delay! There's a lot of other work ongoing which makes it difficult to find time reviewing library additions...
Here my thoughts:

Symbol/component: I'd highly prefer to make these more consistent with the already existing ESP32 library elements, in particular:

Rename pins/signals, e.g. "IO5" instead of just "5" and "IO7/D0" instead of just "D0". I think this makes it much more clear (avoid confusion with pad numbers).
Symbol pin arrangement - Same power/enable pin locations as the other ESP32 symbols (which is basically our standard for MCU-like symbols as it provides space for capacitors): EN - 5.08mm space - 5V - 5.08mm space - 3V3 - 5.08mm space - GND. And I think I'd prefer having all I/Os on the right side, sorted by their IO number, without grouping :thinking: In the end, the grouping depends on the use-case so other people might prefer different grouping, while sorting by IO number is kind of neutral/universal...

Packages:

I'm not sure about having two footprint variants for the silkscreen. What would you think about having one variant with something in between (outline of headers, outline of board, module and USB connector, but no more details)? Especially any texts other than {{NAME}} and {{VALUE}} should be removed anyway IMHO. And details like the buttons should be moved to the "Top Documentation" layer, to see them in assembly plans but not on silkscreen.
Not a big deal, but the button polygons are currently drawn as 4 independent lines, while a single polygon would be preferred.
The restring on the pads look a bit small to me, I suspect this could be difficult to solder. I'd suggest increasing the pad diameter to 1.7mm. Btw, do you actually know what drill diameter is used on the DevKitC board? I never found a detailed mechanical drawing specifying this...
There are library check warnings (no 3D model) which should be approved.

Would be nice if you could check/adjust these things :slightly_smiling_face:


[fftw3] OpenMP enabled targets missing?

Hello everybody,
I've built fftw3 with openmp support on a Linux machine and everything went smoothly, i.e. all the libs (including fftw3_omp) exist after the installation. However, it seems like there is no dedicated cmake target for fftw3 with openmp but only the non-threaded lib targets get exported as FFTW3::fftw3. Going through FFTW3LibraryDepends.cmake in $VCPKG_ROOT/installed/x64-linux/share/fftw3 confirms this.
Is this the intended behaviour? Am I missing something here?
Thank you for the support!

@timzimm Sorry I am late. Could you please provide the codes which you want to use in your project?

Sure. Here is a minimal example. It is essentially the first example in the FFTW documentation:
$ cat main.cc
#include<fftw3.h>

int main(){
    fftw_init_threads();
    fftw_plan_with_nthreads(2);

    size_t N = 1<<15;
    auto in =  reinterpret_cast<fftw_complex*>(fftw_malloc(sizeof(fftw_complex) * N));
    auto out = reinterpret_cast<fftw_complex*>(fftw_malloc(sizeof(fftw_complex) * N));
    fftw_plan p = fftw_plan_dft_1d(N, in, out, FFTW_FORWARD, FFTW_ESTIMATE);

    fftw_execute(p);
    fftw_destroy_plan(p);
    fftw_free(in);
    fftw_free(out);
}

$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.12)

find_package(FFTW3 CONFIG REQUIRED)

add_executable(test main.cc)
target_link_libraries(test FFTW3::fftw3)

$ cmake -DCMAKE_TOOLCHAIN_FILE=$HOME/vcpkg/scripts/buildsystems/vcpkg.cmake .
-- The C compiler identification is GNU 9.1.0
-- The CXX compiler identification is GNU 9.1.0
-- Check for working C compiler: /opt/bwhpc/common/compiler/gnu/9.1.0/bin/gcc
-- Check for working C compiler: /opt/bwhpc/common/compiler/gnu/9.1.0/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /opt/bwhpc/common/compiler/gnu/9.1.0/bin/g++
-- Check for working CXX compiler: /opt/bwhpc/common/compiler/gnu/9.1.0/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done

$VERBOSE=1 make
[ 50%] Building CXX object CMakeFiles/test.dir/main.cc.o
/opt/bwhpc/common/compiler/gnu/9.1.0/bin/g++   -isystem /home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/include   -o CMakeFiles/test.dir/main.cc.o -c /home/hd/hd_hd/hd_em426/tmp/main.cc
[100%] Linking CXX executable test
/pfs/data1/software_uc1/bwhpc/common/devel/cmake/3.14.0/bin/cmake -E cmake_link_script CMakeFiles/test.dir/link.txt --verbose=1
/opt/bwhpc/common/compiler/gnu/9.1.0/bin/g++    -rdynamic CMakeFiles/test.dir/main.cc.o  -o test  -L/home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/debug/lib /home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/debug/lib/libfftw3.a -lm
CMakeFiles/test.dir/main.cc.o: In function `main':
main.cc:(.text+0x9): undefined reference to `fftw_init_threads'
main.cc:(.text+0x13): undefined reference to `fftw_plan_with_nthreads'
collect2: error: ld returned 1 exit status
make[2]: *** [test] Error 1
make[2]: Leaving directory `/pfs/data2/home/hd/hd_hd/hd_em426/tmp'
make[1]: *** [CMakeFiles/test.dir/all] Error 2
make[1]: Leaving directory `/pfs/data2/home/hd/hd_hd/hd_em426/tmp'
make: *** [all] Error 2

As you can see, the provided target only links against the single threaded version of the library.
To my understanding there should be something like a "fftw3_omp" target that links against libfftw3_omp and the openmp runtime. Note that the libraries were build:
$ ls $HOME/vcpkg/installed/x64-linux/lib/libfftw*
/home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/lib/libfftw3.a
/home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/lib/libfftw3f.a
/home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/lib/libfftw3f_omp.a
/home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/lib/libfftw3l.a
/home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/lib/libfftw3_omp.a

Can I assist any further?

@timzimm If you want use fftw_init_threads() and fftw_plan_with_nthreads(), you should install fftw3[threads]. I installed fftw3[threads] and make this project successfully.

I agree. Installing fftw3[threads] solves the problem. However, the target binary then
uses pthreads. I want to use OpenMP.
$ ldd test
        linux-vdso.so.1 =>  (0x00007ffe683a3000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b91226ce000)
        libstdc++.so.6 => /path/to/gnu/9.2.0/lib64/libstdc++.so.6 (0x00002b91228ea000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b9122ccd000)
        libgcc_s.so.1 => /path/to/gnu/9.2.0/lib64/libgcc_s.so.1 (0x00002b9122fcf000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b91231e7000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b91224aa000)

What to I have to do to make this work with OpenMP? What is the purpose of fftw3[openmp] then? Am I misinterpreting something?
According to the fftw3 documentation on this subject:
http://www.fftw.org/fftw3_doc/Usage-of-Multi_002dthreaded-FFTW.html
one should link against -lfftw3_omp -lfftw3 -lm and add -fopenmp as compiler flag. None of this happens if I install fftw3[openmp] and then look at the verbose make output:
$ VERBOSE=1 make
[ 50%] Building CXX object CMakeFiles/test.dir/main.cc.o
/opt/bwhpc/common/compiler/gnu/9.2.0/bin/g++   -isystem /home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/include   -o CMakeFiles/test.dir/main.cc.o -c /home/hd/hd_hd/hd_em426/tmp/main.cc
[100%] Linking CXX executable test
/pfs/data5/software_uc2/bwhpc/common/devel/cmake/3.16.4/bin/cmake -E cmake_link_script CMakeFiles/test.dir/link.txt --verbose=1
/opt/bwhpc/common/compiler/gnu/9.2.0/bin/g++    -rdynamic CMakeFiles/test.dir/main.cc.o  -o test   -L/home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/debug/lib  /home/hd/hd_hd/hd_em426/vcpkg/installed/x64-linux/debug/lib/libfftw3.a -lm
CMakeFiles/test.dir/main.cc.o: In function `main':
main.cc:(.text+0x9): undefined reference to `fftw_init_threads'
main.cc:(.text+0x13): undefined reference to `fftw_plan_with_nthreads'
collect2: error: ld returned 1 exit status

Ok, I will fix it soon.

The related issue: https://github.com/FFTW/fftw3/issues/195

Any advancements on adding FFTW3::fftw3_omp target?


Add [LIQUID-STERLLAR Liquidstellar.org] #exchange #issuer GBZZSI…QH7CPU

Address: GBZZSI5HMUZP7ID5337NSZDQ7PDKSGJQAZYR5ZD3J6YBHIS33NQH7CPU
Tags: exchange issuer
Title: LIQUID-STERLLAR  Domain: Liquidstellar.org
Requested by @mustyrado

@Mustyrado This has been combined with the same issue #342 Please post and new information on that post.


Investigate shared web workers

While  the IWC is designed to support CH/FF/IE, the localstorage link and complexity of distributed consensus are two bottlenecks on performance. Chrome and Firefox support shared webworkers http://caniuse.com/#feat=sharedworkers
using current the current implementation as a fallback for non-capable browsers, investigate the possibility of using shared web workers. Since it is a single script ran, the IWC bus will all be ran in one location (rather than the default: each client instance opens a bus instance) thus no need for a consensus. In addition the shared web worker would drop the need to write to local storage as the link between instances as all IWC clients will attach to the same bus, this should improve throughput and alleviate the issue of minimized & out of focus (a browser tab not in current display) IWC connections being governed to a 1 write to local storage/second.

initial effort completed in #335.
Master is not stable, debugger & intent chooser were missed on the update, will address before next version release. Use of 1.1.0 instead of master is advised.

As of 1.1.6 shared workers have been deemed stable, any behavior discrepancies should be opened in new issues.


 If not, here are a few pointers.

Blog post
Sec 2 of this paper
Slide 50

Next steps

Figure out the full list of simplifications currently implemented
Try above example using ego

Here are some more simplifications which are currently implemented:
simplify_existential_locations:
  ex x; ens x->...; ex y; ens y->... ==> ex x; ens x->...; ex y; ens x->...
    if x=y appears somewhere

remove_temp_vars:
  ex x; ens x=c; S ==> ex x; S
    if x does not occur in S and c is a constant

optimize_existentials:
  ex x; S ==> S
    if x does not occur in S
  ex x; S; S1 ==> S; ex x; S1
    if x does not occur in S but occurs in S1

remove_vars_occurring_twice:
  ex x; ens x=0/\res=x ==> ex x; ens 0=0/\res=0

propagate_function_stage_equalities:
  ens b=(fun ...)/\a=b; a(...) ==> ens b=(fun ...); b(...)

simplify_pure:
  ens !(x=true) ==> ens x=false
  ens x=x ==> ens true
  ens c=c ==> ens true
  ens true/\P ==> ens P
  ens false/\P ==> ens false
  ens c+c ==> ens c1
    if c1=c+C


Add xstar to Ecosystem page

What changed? Why?
Adding  XStar to the Ecosystem page.
Notes to reviewers
Terms Link: https://xstar.id/userterms
How has it been tested?
Running the page locally.

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/2

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
1

Sum
2

@human85
Hello, thank you for this PR. Could you please clarify what portions of Xstar are live on Base and how they can be used in the ecosystem?

@human85
Hello, thank you for this PR. Could you please clarify what portions of Xstar are live on Base and how they can be used in the ecosystem?

XStar introduces a new approach to prove the personhood of humanity on chain. We ask users to connect the wallet addresses of base with their social network accounts and scan the face to check the liveness. One face is connected with only one wallet address. Then, we ask user to mint a sbt on Base. If users pass the facial recognition and liveness check, they can mint diamond human keys on Base. If they only connect the social network accounts with the wallet addresses, they can also mint SBTs of gold human keys on Base. Users can also check the humanity score in our front end to check the humanity level in our front end. We think the proof of personhood on base is important identity infrastructure.

@human85
Thank you for the additional information. Can you please share what users can do with the gold and diamond SBTs, respectively, once they've paid to mint them on Base? Can you also please share the contract addresses for them?

@human85
Thank you for the additional information. Can you please share what users can do with the gold and diamond SBTs, respectively, once they've paid to mint them on Base? Can you also please share the contract addresses for them?

Human Keys: Unlocking New Possibilities
Human Keys can be seamlessly integrated into a variety of use cases. Currently, we have implemented them in our Telegram mini-game, XStar Fleet. Players who possess Human Keys receive multiplied rewards in farming games based on their humanity scores. This requires linking their Base wallet addresses with their unique Telegram ID, ensuring a personalized and secure experience.
Since the deployment of the Human Keys smart contracts in November, 1,150 users have minted Soulbound Tokens (SBTs) on Base, with over 40% of these users verifying their facial information on Base, showcasing strong adoption and engagement within the ecosystem.
Additionally, we have integrated our humanity score with Blockscout, allowing users to easily check their humanity level directly on the platform. This enhances transparency and accessibility for all participants in the ecosystem.
We are also actively exploring partnerships with other DeFi projects, particularly in the Base ecosystem. For example, integrating Human Keys with lending protocols can revolutionize the way borrowers are evaluated. By leveraging proof of personhood, platforms can verify the liveness of borrowers, potentially allowing them to offer reduced collateral requirements and stand out from competitors.
At present, our primary focus is on expanding within the Base ecosystem, bringing the benefits of Human Keys to more innovative projects and platforms.
Human Key contract address: 0x64baa16c194adc2c07c70026fdacdbba9370131b


It doesn't working with base64 string

var base64 = "the base64 string convert from a xlsx(excel 2007) file.";
var workbook = XLSX.read(base64, { type: "base64" });
the base64 string is from a xls file, it will be ok, but if the base64 string is from a xlsx file, it doesn't working.
Do you know what I mean? my english is very poor. so, if you don't, please forgive me.

Can you share the base64 string and the XLSX file?
Sent from my iPad

On May 29, 2015, at 01:39, zxy900213<EMAIL_ADDRESS>wrote:
var base64 = "the base64 string convert from a xlsx(excel 2007) file.";
var workbook = XLSX.read(base64, { type: "base64" });
the base64 string is from a xls file, it will be ok, but if the base64 string is from a xlsx file, it doesn't working.
Do you know what I mean? my english is very poor. so, if you don't, please forgive me.
—
Reply to this email directly or view it on GitHub.

Sorry,I have deleted the excel file.
I tried to create the same file, but i can't make this problem reappear.