bizarre windows formatting bug

select generate_series(1,9), round(random());
+-------------------+---------+
|   generate_series |   round |
|-------------------+---------|
|                 1 |       1 |
|                 2 |       1 |
|                 3 |       1 |
|                 4 |       0 |
|                 5 |       1 |
|                 6 |       1 |
|                 7 |       1 |
|                 8 |       1 |
|                 9 |       0 |
+-------------------+---------+
SELECT 9
> select generate_series(1,10), round(random());
?????????????????+?????????+?????????????????????++++++++??+++???++++++++'?+++%??++++++++??+++???++++++++??+++???++++++++`?+++???++++++++??+++???++++++++??+++%??++++++++??+++%??++++++++<?+++???+++++++?%?+++%??????????????????????

Of course everything works fine in linux.

Hrm. It seems to work fine in OS X as well.
Can you try the expanded output mode (\x) and see if it has the same problem?
I'm wondering if the issue is in the formatter or in the output coming from psycopg2.
Sorry I don't have a windows box to test this out locally. :(

bah, turns out it was just windows default pager


Navigation list's popup not readable on Pre 3.0

On Pre 3.0, the popup window opened when clicking on the navigation list has its text in white on a white background (with default Sherlok Light Theme). So the entries aren't visible.

Is this for the v4.0 betas or v3.x.
If it's for 4.0, there is an example which shows you how to work around this in the 'demos' sample.

Fixed for 4.0-wip


Error selecting image.

Why when I select the picture select button does not work properly?

@paterlini How did you integrate the framework? Did you use carthage or cocoapods?

I use cocapods in swift.

@paterlini Right, I tried it to and doesn't work for me either. I'll fix this tonight!

Okey! Thank you!

This has to do with Cocoapods copying the image differently than Carthage. I couldn't find a fix for now. I'll try fixing it as soon as possible. Stay tuned!

@paterlini Okay, managed to fix the issue today. Sorry for letting you wait so long. Just make sure to use version 0.1.6.

Ok. Thank you!!

@paterlini Let me know if you run into any other issues! :)


Improve file associations

We already have Vagrantfile, but something like:
"files.associations": {
  "*.rasi": "css",
  "**/i3/config": "i3",
  "Xresources": "xdefaults",
  "*.sublime-snippet": "xml"
}

Closed by 9107da4aea7cc806cdebf513647bb5f27c5af683


NuGet restore should use the endpoint URL when provided and not rely on nuget.config

Hi,
Trying to use the 2.0.5 version of Nuget task, I'm having some troubles figuring how to make it work with the restore command.
I don't want to check in a nuget.config file. I expect the task to use the endpoint URL, as it already uses the credentials provided (just like in the push command).

Can you tell me more about your scenario? Specifically: are you restoring from package feeds outside of the Package Management extension in your VSTS account?  And, how are you restoring the packages locally without a NuGet.config?

I am currently using Nexus Repository as artifacts manager, plugged to a Nexus IQ Server.
In Nexus, I have a NuGet group, for reading and restoring purpose, which in turn:

Proxifies NuGet.org
Proxifies a dev/snapshot NuGet Nexus-hosted repository
Proxifies a production/release NuGet Nexus-hosted repository

Indeed, today, both developers and private agents can restore their packages using the default nuget.config file, which contains the URL of the NuGet group.
NuGet publish can only be achieved through a VSTS build/release, using one of two declared NuGet endpoints; one for snapshots, one for releases. In that way, the NuGet task uses the URL defined in the endpoint.
Now, on build agents (hosted or private), If I can avoid using the default nuget.config file when restauring, and -just like when I publish- rely on the endpoint URL, that would be nice.
If I'm not mistaken, the task creates a temporary nuget.config file. Why doesn't it use the endpoint URL?

Thanks for the response - it's helpful to understand your workflow. Quick clarification: is the 'default nuget.config file" you mentioned above already checked into your repo, or do developers and private agents acquire that file another way?
To answer your last question: we generally advocate checking in a nuget.config so that the repository contains all the information (including package sources) needed to build successfully.

When I say the 'default' nuget.config file, I'm talking about the one created by default when you install Visual Studio: %ProgramData%\NuGet\Config\ or now %ProgramFiles(x86)%\NuGet\Config\.
Today developers are asked to update this file (using Visual Studio) to use Nexus Repository as a package source . This is done manually on private build agents.

Makes sense; thanks.
We'll take this scenario (constructing a NuGet.config using Service Endpoints) as a potential improvement for v3 of the NuGet task. I'm going to close the GitHub issue and move this to our internal work tracking system so it doesn't get lost. Thanks for your input and for using VSTS!


After a reorganization of code, I had links out of place.  Knowing the so

After a reorganization of code, I had links out of place.  Knowing the source of the link is as important as which link it is.  Including @file in the log message does this.
Changes this:
[warn]: Cannot find object at `file:<path to file to be included>' for inclusion

To this:
[warn]: Cannot find object at `file:<path to file to be included>' for inclusion from `#<yardoc extra_file <path file will be included in> attrs={:markup=>:markdown}>'

Is listing the whole file object proper? Also what happens when it's being included into an object and not an extra file?


Complexity Validation Rule

[ ] Rework scalars to match new exception rules.
[ ] Write test for custom scalar that throws scalar exception on ParseValue.

[ ] Add variable support for validation rules
[ ] Add max complexity rule


When a package is not found, UI doesn't get updated.

Repro:
http://apicomparer.particular.net/Compare/NHibernate/<IP_ADDRESS>00...<IP_ADDRESS>00
Output is constantly
Our minions are working for you :) We are comparing NHibernate against <IP_ADDRESS>00 and <IP_ADDRESS>00

Exception thrown by handler:
2016-02-19T17:00:11  PID[6256] Information 2016-02-19 17:00:11.262 INFO  APIComparer.Backend.ComparisonHandler Received request to handle comparison for 'NHibernate' versions '<IP_ADDRESS>00' and '<IP_ADDRESS>00'
2016-02-19T17:00:11  PID[6256] Information 2016-02-19 17:00:11.371 INFO  NServiceBus.Unicast.Transport.TransportReceiver Failed to process message
2016-02-19T17:00:11  PID[6256] Information System.InvalidOperationException: Unable to find version '<IP_ADDRESS>00' of package 'NHibernate'.

and later
2016-02-19T17:01:43  PID[9416] Verbose     2016-02-19 17:01:43.378 ERROR NServiceBus.Faults.Forwarder.FaultManager Message with '78681d8f-9151-4047-9966-a5b10117eb93' id has failed FLR and will be moved to the configured error queue.
On subsequent requeuest WebApp thinks request it's still undergoing processing because of the left behind file placeholder and doesn't issue a new request, leaving user to wait.

File system with the file placeholder:

We could dogfood SP ;)
/cc @DavidBoike

We should have the backend update that doc with a "not found" message once we get a response for NuGet. Another option would be to check with NuGet if we can't find an existing comparision

@andreasohlund I'm planning to generate a content file for a failing comparison with the exception data for now as a quick fix. Would that fly?

Sounds resonable, :shipit:

Dosn't work on preview
http://apicomparer-preview.particular.net/compare/nservicebuseeee/5.0.0...5.1.3
perhaps the auto deploy isn't working?

I'll look into that

@andreasohlund remind me the flow - whenever we push to master it goes to preview and production is published manually?

This is not specific to this issue, but related to GitVersionTask issue here. Closing this one and opening new issue #63


[Feature] Add mouse event to custom tooltip function parameters

All I actually want to do is to have the tooltip (with intersect: false, mode: 'index', position: 'nearest',) follow the mouse (similar to how Google Analytics does it on their Home charts), but as far as I can tell it's not currently possible because there's no way to get the mouse position.
Can we get the mouse event added so we can hook into it?

There is a mousemove event: https://www.chartjs.org/docs/latest/general/interactions/events.html
Does that solve what you were looking for? I'm not too familiar with Chart.js's event handling

I'm assuming mousemove works since I haven't heard otherwise

Sorry it took me a bit to work this out, but I did finally get something wired something up. It was two parts -
A custom tooltip, which is similar to your example (http://www.chartjs.org/docs/latest/configuration/tooltip.html#external-custom-tooltips), but I pared down to
`custom: (tooltipData) => {
// Tooltip Element
var tooltipElement = document.querySelector('.chart-tooltip');

// Hide if no tooltip
if (tooltipData.opacity === 0) {
	tooltipElement.style.display = 'none';
	return;
}

// Remove caret
tooltipElement.classList.remove('above', 'below');

tooltipElement.style.display = 'block';

if(tooltipData.body) {
	let bodyLines = tooltipData.body.map((bodyItem) => bodyItem.lines);
	tooltipElement.innerHTML = bodyLines.join('<br>');
}

}`
and an onHover option
`onHover: (event) => {
let chart = document.querySelector('.chart');
let tooltip = document.querySelector('.chart-tooltip');

tooltip.style.top = (event.offsetY - 10) +'px';

if(event.offsetX + tooltip.offsetWidth > (chart.offsetLeft + chart.offsetWidth)) {
	tooltip.style.left = (event.offsetX - tooltip.offsetWidth - 20) +'px';
} else {
	tooltip.style.left = (event.offsetX + 40) +'px';
}

},`
I'm not sure if looking at this you may see an easier way to achieve a label that follows the mouse, but there didn't seem to be any obvious documentation about it. I feel like this would be a great default label option to have (Google Analytics style).


Error with Domain Dump

Hi when I run the latest version I get this....
root@kali:/opt/ldapdomaindump# python ldapdomaindump.py -u "davy\rich" <IP_ADDRESS>
Password:
[] Connecting to host...
[] Binding to host
[+] Bind OK
[*] Starting domain dump
Traceback (most recent call last):
File "ldapdomaindump.py", line 3, in
ldapdomaindump.main()
File "/opt/ldapdomaindump/ldapdomaindump/init.py", line 922, in main
dd.domainDump()
File "/opt/ldapdomaindump/ldapdomaindump/init.py", line 411, in domainDump
self.policy = self.getDomainPolicy()
File "/opt/ldapdomaindump/ldapdomaindump/init.py", line 254, in getDomainPolicy
self.connection.search(self.root, '(objectClass=domain)', attributes=ldap3.ALL_ATTRIBUTES)
File "/usr/local/lib/python2.7/dist-packages/ldap3/core/connection.py", line 788, in search
response = self.post_send_search(self.send('searchRequest', request, controls))
File "/usr/local/lib/python2.7/dist-packages/ldap3/strategy/sync.py", line 139, in post_send_search
responses, result = self.get_response(message_id)
File "/usr/local/lib/python2.7/dist-packages/ldap3/strategy/base.py", line 325, in get_response
responses = self._get_response(message_id)
File "/usr/local/lib/python2.7/dist-packages/ldap3/strategy/sync.py", line 165, in _get_response
dict_response = self.decode_response_fast(ldap_resp)
File "/usr/local/lib/python2.7/dist-packages/ldap3/strategy/base.py", line 509, in decode_response_fast
result = search_result_entry_response_to_dict_fast(ldap_message['payload'], self.connection.server.schema, self.connection.server.custom_formatter, self.connection.check_names)
File "/usr/local/lib/python2.7/dist-packages/ldap3/operation/search.py", line 568, in search_result_entry_response_to_dict_fast
entry_dict['attributes'] = checked_attributes_to_dict_fast(response[1][3], schema, custom_formatter)  # attributes
File "/usr/local/lib/python2.7/dist-packages/ldap3/operation/search.py", line 453, in checked_attributes_to_dict_fast
checked_attributes[name] = format_attribute_values(schema, name, decode_raw_vals_fast(attribute[3][1][3]) or [], custom_formatter)
File "/usr/local/lib/python2.7/dist-packages/ldap3/protocol/formatters/standard.py", line 213, in format_attribute_values
formatted_values = [formatter(raw_value) for raw_value in values]  # executes formatter
File "/usr/local/lib/python2.7/dist-packages/ldap3/protocol/formatters/formatters.py", line 337, in format_ad_timedelta
return format_ad_timestamp(raw_value * -1) - format_ad_timestamp(0)
TypeError: unsupported operand type(s) for -: 'str' and 'datetime.datetime'

Make sure you have ldap3 version 2.5.1, this looks like 2.5.2 which has a bug.

Thanks for the super quick reply - yes that does the trick.


Directly set task duration, and display it

In order to be able to take into account the time to spend / spent on a task, I would like to be able to edit their duration without having to specify a start date or end date (i.e. unlike https://github.com/dmfs/opentasks/issues/197).
Duration is indeed part of the CalDAV specification https://datatracker.ietf.org/doc/html/rfc4791 (as well as iCalendar's https://www.rfc-editor.org/rfc/rfc8607.html, see also https://www.grokkingandroid.com/recurrence-rule-and-duration-formats/ for how to write the duration format), but OpenTasks does not use it.
Such feature would also give the opportunity to make more advanced apps for planning tasks.

The time to spend and the time spent are two very different issues. The latter one is indeed solved by the scheduling extensions you mentioned. They allow each participant to "book" the time they spent on the task. The former issue is solved by the Task Extensions to iCalendar draft, which introduces a new property ESTIMATED-DURATION. I've indeed planned to support that and it should be easy to implement in Opentasks. However, I wanted to wait until the draft has become a proposed standard to get client sync support as well.

I like this fresh proposal!
I agree my precise use case would be best supported by ESTIMATED-DURATION.
But what about the support for DURATION today?
Shouldn't it be supported, shown and editable, anyways?
I could accommodate to that in the meantime.

DURATION has very clear semantics: DTSTART + DURATION = DUE. Hence RFC 5545 allows only one of both to be present. The new JSCalendar standard has no duration property, but an estimated-duration.

DURATION has very clear semantics: DTSTART + DURATION = DUE. Hence RFC 5545 allows only one of both to be present.
Even worse: DURATION cannot be present without DTSTART being set, and I guess OpenTasks should not do anything funny around the standard.
The new JSCalendar standard has no duration property, but an estimated-duration.
Neat, we will see if they accept it.

So your point is that in the meantime, OpenTasks cannot help me, thanks. Then what about this issue? Do you think editing durations instead of end dates is still a valid request?


Create a set of ImmutableListX, ImmutableSetX etc interfaces

ImmutableListX<Integer> immutable = ListX.of(1,2,3)
                                         .immutable();

This would lead to too many interfaces in practice.


Houdini: Remove Mantra IFD product

Changelog Description
Remove Mantra IFD product
Additional info
Fix #673
Testing notes:

Houdini publishing should still work
Houdini mantra render should not be influenced (should still work)

@BigRoy please resolve the conflict before the merge. thanks!

Should be done!


Export to plaintext

Added a button in the settings modal dialog to allow to export the current text of the prompt area:

The name of the file is the name of the current session in .txt format. Nothing else is exported, only the text that has been co-written with the AI:

I've used a blob after checking out with chatGPT because the text could be potentially very long. To be honest, I don't know if we'd run into other issues first as the text grew larger. I know that for example NovelAI doesn't load all the text necessarily.

I feel like that isn't a good place to put this button but... eh, this looks enough for now. Thank you for your contribution!


Keys Detective's return code for automated validation

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior
transloco-keys-manager find always ends with code 0 (no error).
Expected behavior
It would be useful if the transloco-keys-manager find would return some different exit code if missing keys would be found. This would enable to use this tool for validation in build/release tools like CI.
Minimal reproduction of the problem with instructions
Run the transloco-keys-manager find and see the exit code.
What is the motivation / use case for changing the behavior?
I would like to automate the process and make it easy for the developers and the CI to notice that some keys are missing (and not translated) in the extracted file.
Environment
For Tooling issues:

Node version: v12.16.2
Platform:  Windows

@JerryDoubleU I can see that in case you have missing keys and the addMissingKeys option is disabled the process will exit with code 1.
What other cases are you referring to?

That sounds like it, thanks!
It'd also be useful to be able to get the info about the 'extra keys' (exit code 2?) to be aware of the extra keys which are no longer used, or have been mistyped.

would you like to make a PR for it? 🙂

Definitely! I'll do this this week.

@JerryDoubleU available in v2.1.0. Great work!


[BUG] Study Title not an editable field on study metadata

Study title should be editable via the metadata sheet view:
ARCitect v 0.0.49

Fixed! Will be live with the next release


Fix shared library building.

Fix the shared library building for bgfx c++.

Do you have any idea to do for this problem?

Keep this code in your fork and use it that way.
Use C99 bindings.
Don't use shared library.


how to remove media notification on notification panel

Please, I want to remove media notification from my notification panel but it does not work unless I restart my phone then the media notification will be removed.
Can you add something like a close button, so that when a user clicks on the button the media player will close and disappear from the notification panel.

@Wizpna : maybe help you. this below code to start player. if you want to hide notification,
You set property "showNotification = false". I haven't tested yet, only thinking ^_^
void initState() {
// first argument for isBackground next for showNotification.
player = MediaPlayerPlugin.create(isBackground: true, showNotification: true);
initVideo();
super.initState();
}

@hulastone  it's not like that showNotificaition is the setting which toggles the visibility of the Persistent player notification.
The @Wizpna  is asking about the feature for a closing player from the notification panel.
@Wizpna  You don't have to restart the phone when an app is closed the notification automatically get closed.
The feature is in line and it will available soon.
Thanks for your vote for the feature.

@Wizpna  The bug of the not closing media player on some devices has been fixed in version 0.0.6 so closing this request
yes. there could be a close button to close the player manually when the user wants to but it's another enhancement rather than a bug.


Document url identification

After documenting the config options (#260), devote an explicit section to URL identification, particularly the handling of query vs extension strings and provide examples of the transformations.

In particular, this should describe the defaults:

?spf=navigate for spf.navigate and click requests
?spf=navigate-back for history.back() and back button requests
?spf=navigate-forward for  history.forward() and forward button navigation requests
?spf=load for spf.load requests
?spf=prefetch for spf.prefetch requests


Why not read (buffer-list) directly?

Another thought I had was, couldn't the previous buffer be determined using
(cadr (buffer-list))

instead of a variable? That would make the library even simpler.

IMO there is no way to check if current buffer has actually been switched without the variable :thinking:

Oh, duh. I was completely misunderstanding this. Sorry.


Play 2.4 installation

I feel really ridiculous about this but I just can't get the deadbolt packages to register on Play. I'm using IntelliJ and the full description of my problem is here - stackoverflow
Any help would be much appreciated!

The READMEs of both the Scala and Java versions have been updated to be useful, in both the 2.4 and master branches.  I hope this helps!

Yes thanks! Some ppl on stack helped me too!


Fixes Part 3 of Issue 75

Fixed the third part of issue 75 where the GetAllRoles() method was inappropriately returning a list of all roles for the current user when it is intended to provide a list of all roles allowed in the application context. This method is no longer implemented (see issue for more details) and the logic has been moved to the GetRolesForUser() method. Also added documentation to the methods.

Fixed #75


Global Attribute Cluster Revision needs to be fixed for Flow Measurement Cluster

Spec Snippet :

Value needs to be 3

Can be closed. Issue is resolved


feat: change next step when no git repo

Is your feature request related to a problem? Please describe.
After running cli, next steps are shown but I think the message git commit -m "initial commit"(see image bellow) can be removed when a git repo is not initialized. I have the prepared change if change is needed.

Describe the solution you'd like to see
Remove the next step with a commit message in case no git is selected.

Describe alternate solutions
An aditional git init message can be shown (before the git commit message) when no git option is selected
Additional information
No response

Have implemented it with pr #1502


pull request for e2e test at 12/23/2016 22:15:08

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Have dataset values shown somewhere on variable page

If I am looking at a variable page and working with the dataset simultaneously, I may want to have a quick/simple way to reference dataset values without digging into the data dictionary domain file.
For instance: https://www.sleepdata.org/datasets/shhs/variables/sh319b
Are the values 0 to 3? 1 to 4? It would be useful to have the ability to find this information on the variable page.

This issue may be able to be fixed in nsrr/www.sleepdata.org repository itself.

This is part of NSRR milestone 0.18.0


Add support for database scaling

This adds support for a --container-size option on db:create and
db:reload, and adds a new db:restart operation that can be used to
resize database containers and disks.
There isn't much going on here, with one notable exception: since we now
allow customers to pass an arbitrary size when creating databases via
db:create, we can easily get into a situation where we never attempt
provisioning a database, because the provision operation was rejected
in API.
In that case, we'll enqueue a deprovision operation to clean it up.
--
cc @fancyremarker

Codecov Report

Merging #226 into master will increase coverage by 1.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #226      +/-   ##
==========================================
+ Coverage   91.76%   92.84%   +1.07%
==========================================
  Files          46       46
  Lines        1628     1719      +91
==========================================
+ Hits         1494     1596     +102
+ Misses        134      123      -11

Impacted Files
Coverage Δ

lib/aptible/cli/subcommands/apps.rb
80% <ø> (ø)
:arrow_up:

lib/aptible/cli/subcommands/db.rb
86.32% <100%> (+9.32%)
:arrow_up:

spec/aptible/cli/subcommands/backup_spec.rb
100% <100%> (ø)
:arrow_up:

spec/aptible/cli/subcommands/db_spec.rb
100% <100%> (ø)
:arrow_up:

lib/aptible/cli/subcommands/backup.rb
100% <100%> (ø)
:arrow_up:

lib/aptible/cli/helpers/environment.rb
84.61% <0%> (+15.38%)
:arrow_up:

Continue to review full report at Codecov.

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


meshnamed: init at 0.2.0

Description of changes
Add meshnamed - reference implementation of meshname dns
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

Looks like the darwin build is broken. Please set broken = stdenv.isDarwin; for now. I think it can be fixed by updating sys/unix version upstream.

There's a bug in the packaged version. PR will remain a draft until it is clear what to do with the version.

There's a bug in the packaged version

Is this just for the darwin version? Under linux, this package works fine. Can we get this merged anyway?


Allow skipping switch to base branch

Idea
I would like to skip the switching to the base branch, especially if I have supplied both coverage files already.
Description
When the action is run on a PR, it always switches to the base branch. This happens regardless of whether skip-step is set to all, or whether coverage-file and base-coverage-file have been supplied.
I would like to skip this step, especially in this scenario. I would also like to be able to skip it, even if I don't have coverage from the base-branch available, and only provide the coverage-file.
This allows me to use reports generated by other test runs, without having to fetch all the git history for switching.
Furthermore, the checkout is left on the base branch (at least in some cases?), which can be confusing to following actions (e.g. uploads of coverage data to remote services).

Hey @oxc :wave:,
Your idea sounds interesting! I would try to implement this.
Regarding the behavior that branch remaining switched after the action is completed: as I understand it, you would like to see a return to the original branch after it is executed?

Hi @ArtiomTr, cool! 😊 Yes, I believe this would be the behavior I would find least unexpected.

Yes, it is weird that after running this action, other steps are left with the base branch file system, +1 to switch back to the original branch

One more vote from me to switch back to the original branch. Now we need to do that manually :(

Hello everyone,
Sorry for late response. The bug is fixed and now is available under v2 flag.


[1.4.0] Fix notification issues regarding to resigning and proposing

Proposing and resigning a masternode are not receiving notification atm

Pull Request Test Coverage Report for Build 1300

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

Totals

Change from base Build 1287:
0.0%

Covered Lines:
92

Relevant Lines:
103

💛  - Coveralls


Report task validation problems during runtime

We'd like to eventually start failing the build when there's a task that's defined in a way that's obviously wrong. Say, it has a property like @Nested FileCollection or something. We should collect all the validations we do already, or want to do in the future, and categorize as failure or warning. For the failure ones we should start emitting deprecation warnings already, so we can start failing the build in 5.0.

Let's keep this open.

This was done in 6.0 already.


Dir First$ is not compatible, its not working as expected.

Describe the bug:
Dir First$(filename$)
When Dir first$ command is used on a filename, it should return a single entry.

Pattern matching was also case sensitive on AmigaOS :-(
this problem is now fixed :-)
it now checks, if its file or path, looks like its working.


Use conda lock files for testing workflow and unpin environment.yml

This PR rewires the testing workflow to use conda lock files which allows for the unpinning of the environment.yml file. It also removes caching of the conda env as it is actually much slower on Windows runner.

Wondering if this will fix the issues in the data_loaders_refactor branch. Thanks for looking into this, Eric!

I'm afraid not. I merged this branch with the data loaders one and still got the same error

Wondering if this will fix the issues in the data_loaders_refactor branch. Thanks for looking into this, Eric!

I'm afraid not. I merged this branch with the data loaders one and still got the same error

Solved with 5e4b2924ecf36cc5c4f1a05898e88b2170d58a0d


First character not appearing / truncated on Chrome / Edge / Safari

Describe the bug
The first character inserted by the user is not correctly visible
To Reproduce
Steps to reproduce the behavior:

Go to https://choices-js.github.io/Choices/ with Chrome or Safari
Try to insert a character in the first select dropdown
The character does not appear or it is truncated

Expected behavior
The first character entered is visible
Screenshots

Desktop (please complete the following information):

OS: macOS 12.1 / Windows 10
Browser: Chrome / Safari / Edge
Version 97 / 15.2 / 97

Firefox is not affected on both Win and Mac
Smartphone (please complete the following information):

Device: iPhone 12 Pro
OS: iOS 15.2.1
Browser Safari
Version 15.2.1

Looks like this is a side-effect of #908. You can fix this with the solution suggested here (tested on Chrome, you may need additional markup for Safari).
This will be fixed in the next version.


Docs

Flesh out the docs:

daily usage
FTP
workers
backups
usage limits and metering
environment variables and secrets

Moved to roadmap


Add support for revealing a player's hand

There are several Artifact cards which require a player to reveal their hand. Instead of moving cards one by one to the revealed zone and back again (which could take a lot of time and also make it hard for players know what was revealed if they miss the animation), we should instead dump out a card list in the log.
Here are some example dogma effects which reveal a player's hand:
Choose a number and a color. Draw five ${age_4}, then reveal your hand. If you have exactly that many cards of that color, score them, and splay right your cards of that color. Otherwise, return all cards from your hand.
Reveal your hand. If you have exactly five cards and five colors in your hand, you win.
In addition to dumping the card names in the log, we likely want to try to make a few other improvements to card names in the logs:

Hovering over a card name should show a tooltip.
The card name should be colored based on the card's color (if this actually looks good). Here are the hex values for the 5 colors: Blue: #0e2a50, Red: #5a090c, Green: #122c18, Yellow #8b6a28, Purple: #220e40.
Make capitalization consistent across cards (maybe capitalize every letter if it looks good?). This has to be accomplished using .toUpperCase() in the JavaScript code after being translated (as opposed to modifying the original strings which would mess up translations).

Once this is implemented, we'd also like to make the Oars card reveal a hand if they don't have any card in their hand with a coin, as requested by Chris in https://boardgamearena.com/bug?id=36171.

Mjolnir (age 3) throws a monkey wrench into this plan because the compel effect allows the executor to choose a card (and meld) a card from their opponent's hand.

I guess we will just have to handle that case differently. We can't move those cards to the revealed area anyway because not everyone is supposed to see the cards.
That makes me wonder about Oars. Who gets to see the player's hand? Just the person playing Oars?

Text of Moylough Belt Shrine: "I COMPEL you to reveal all cards in your hand and transfer the card of my choice to my board!" It doesn't say anything about only revealing it to one person.

So whenever we explicitly see that "reveal" keyword we know that all players get to see it.

Yeah, I agree.  Reveal is public knowledge.  If the card said to transfer to the player's hand, then it would be private.

I wonder if a solution to this problem would be to just accelerate the speed of the animation when we are moving around lots of cards (e.g. 5 or more)? This would be useful in other situations too.

Yes I think that would be great.

Maybe transfer 3 cards at a time?

I suspect that trying to move around multiple cards at once will break things!

what if the cards were revealed the same way the cards in your score are revealed when you click on score or when you are prompted to do something with your score pile?
Twister (age 10) says to reveal your score pile so that is a similar problem to this.

We've decide to defer these "enhancements" until later. For now, we can just move cards one at a time.

I think we should probably prioritize this work, since this would greatly improve the user experience of certain artifact cards.
To clarify, I'm proposing we dump the cards out to the game log (as opposed to moving cards more quickly or moving multiple at a time). There are a number of tasks here, so it will likely be worth splitting some of them out into other issues (e.g. "Hovering over a card name should show a tooltip" could be a separate bug).

"Mask of Warka" could also benefit from this bulk reveal.

The functionality is added:

I'll close this and then I'll file separate issues for each of the cards which need to be updated.


Proposal: Propose possible value in case of unallowed key

ciao,
i'm thinking of adding a fuzzy string-matcher to extend the error message with a proposal which refers to an allowed key here: https://github.com/nicolaiarocci/cerberus/blob/master/cerberus/cerberus.py#L274
has anyone thoughts on how to opt-in/-out? should that behaviour be default? shall it be set per validator or per validation?

Can you provide a practical example of how this would work?

instead of unknown field, it would output something like
`hosts` is an unknown field; did you mean `host`?

meanwhile i figured out that this must happen per validation to cover sub-schemas.
the generic fuzzy-matching would rely on difflib.SequenceMatcher.ratio.
another aspect i'm thinking about is the possibility to provide a mapping of allowd values to possible mistakes to cover more deviant proposals, let's say like `{'host': ['domain', 'domains']}.

Cool stuff. The standard library never ceases to amaze me.

has anyone thoughts on how to opt-in/-out? should that behaviour be default?

Since I imagine this would have an impact on overall performance, I would say that it should be opt-in/-out and probably disabled by default.

tbc in #93


misc/cgo: TestSignalForwardingExternal sometimes fails with wrong signal SIGINT

What version of Go are you using (go version)?

$ go version
go version devel go1.19-2aa473cc54 Fri Jul 15 14:56:54 2022 +0000 linux/s390x

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="s390x"
GOBIN=""
GOCACHE="/home/jalbrecht/.cache/go-build"
GOENV="/home/jalbrecht/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="s390x"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jalbrecht/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jalbrecht/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/jalbrecht/src/goroot"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/jalbrecht/src/goroot/pkg/tool/linux_s390x"
GOVCS=""
GOVERSION="devel go1.19-2aa473cc54 Fri Jul 15 14:56:54 2022 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jalbrecht/src/goroot/src/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -march=z196 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build182921307=/tmp/go-build -gno-record-gcc-switches"

What did you do?
cd misc/cgo/testcarchive
go test -failfast -count=5000 -timeout=0 -run TestSignalForwardingExternal

What did you expect to see?
Test should always pass
What did you see instead?
--- FAIL: TestSignalForwardingExternal (1.85s)
    carchive_test.go:681: got signal: quit (core dumped); expected signal segmentation fault
FAIL
exit status 1
FAIL    misc/cgo/testcarchive   5177.741s

This test failed twice while I was testing new s390x builder hardware:
https://build.golang.org/log/b7171701f23a01295fc598a1ea596f5b1e2431e5
https://build.golang.org/log/2a0f9a0cade96e1972aed5ed315721f82c3031b0
This failure could also happen on other architectures but for some reason its more likely to happen on the new machine I'm testing. As far as I'm able to see, this failure has not happened on the existing s390x builders.
I'm able to reproduce the same failure on linux amd64 by removing the code related to waiting for the testp program to send the OK trigger which makes the window where a go thread could handle the SIGSEV signal larger: https://github.com/golang/go/blob/2aa473cc54128c1498f80263763a2a876308e565/misc/cgo/testcarchive/carchive_test.go#L630
I ran the test under strace and I think this could happen since this CL in go1.15 which makes SIGSEGV always crash the go program. In c-archive programs GOTRACEBACK=crash is always effectively set and that causes the go signal handler to send SIGINT to its own process: https://github.com/golang/go/blob/2aa473cc54128c1498f80263763a2a876308e565/src/runtime/signal_unix.go#L788
and that's how the tests sees the testp process has exited with SIGINT instead of SIGSEGV.
I think the fix could be for the test to send SIGUSR1 to testp instead of SIGSEGV. I've tried that out on s390x and amd64 and haven't seen any failures. If that makes sense, I can submit a CL.

@ianlancetaylor I think you might be the most familiar with this test. Could you have a look when you get a chance?

The point of the test is to check that SIGSEGV sent from some other process is handled correctly.  It has to be SIGSEGV, or some other synchronous signal, because those signals are handled specially in c-archive/c-shared mode.  The test was added for #14899, q.v.  Sending SIGUSR1 would not be a useful test here.
The point of waiting for the OK string is to make sure that the Go runtime is fully initialized, by the call to Noop in the C code.  That initialization should ensure that the Go SIGSEGV signal handler is installed.  If we don't wait for the string, then it is possible that the signal handle has not been installed.  So that doesn't seem like a good check of what is happening.
When I run this on linux-amd64 the signal is delivered to a C thread, so sigtrampgo sees that g == nil and winds up calling badsignal.  That seems correct as at this point in the program we don't expect any Go threads to be running.
You say that GOTRACEBACK=crash is effectively set here, but I don't quite see why that is.  Can you explain?
I do agree that if the signal is somehow delivered to a Go thread, we may not take the expected action.
One thing we should certainly do is log the test program's standard error, so that we can see what it thinks is happening.

Thanks for the explanation, that helps a lot.
Regarding the "GOTRACEBACK=crash is effectively set here" comment, I was referring to:
https://github.com/golang/go/blob/244c8b050093ec546311707760afaafabcbf2fef/src/runtime/runtime1.go#L435-L437
which will always set the crash flag for c-archive programs if I understand correctly.
I have the strace output for a failed test run and it includes both a failing test program execution and a successful one. Because TestSignalForwardingExternal runs the test program in a loop and the check done in the expectSignal function calls t.Error* instead of t.Fatal* the test program gets run a second time. Looking at the strace output again, I think it does show that the a Go thread is getting the SIGSEGV signal in the SIGINT case. Here is the full strace output: strace-failed.txt
SIGINT strace output first time in the loop:
pid 977139 - TestSignalForwardingExternal thread
pid 977322 - testp C thread
pid 977324 - some testp Go thread
I think a Go thread (pid 977324) is getting the SIGSEGV instead of the C thread (pid 977322).
This snippet starts at line 154635:
[pid 977322] write(2, "OK\n", 3 <unfinished ...>
[pid 977324] nanosleep({tv_sec=0, tv_nsec=20},  <unfinished ...>
[pid 977322] <... write resumed>)       = 3
[pid 977139] <... epoll_wait resumed>[{events=EPOLLIN, data={u32=1023, u64=4395431198072}}], 128, -1) = 1
[pid 977322] select(0, NULL, NULL, NULL, {tv_sec=60, tv_usec=0} <unfinished ...>
[pid 977139] clock_gettime(CLOCK_MONOTONIC, {tv_sec=442529, tv_nsec=884131926}) = 0
[pid 977139] futex(0x290e58, FUTEX_WAKE_PRIVATE, 1) = 1
[pid 977136] <... futex resumed>)       = 0
[pid 977139] read(3,  <unfinished ...>
[pid 977136] sched_yield( <unfinished ...>
[pid 977139] <... read resumed>"OK\n", 4096) = 3
[pid 977139] kill(977322, SIGSEGV <unfinished ...>
[pid 977324] <... nanosleep resumed>NULL) = 0
[pid 977139] <... kill resumed>)        = 0
[pid 977324] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_USER, si_pid=977135, si_uid=1001} ---
[pid 977322] <... select resumed>)      = ? ERESTARTNOHAND (To be restarted if no handler)

... <goroutine dump output from pid 977324 and other stuff>...

[pid 977324] kill(977322, SIGQUIT <unfinished ...>
[pid 977135] <... clock_gettime resumed>{tv_sec=442529, tv_nsec=894865017}) = 0
[pid 977324] <... kill resumed>)        = 0
[pid 977322] <... select resumed>)      = ? ERESTARTNOHAND (To be restarted if no handler)
[pid 977324] nanosleep({tv_sec=5, tv_nsec=4995000},  <unfinished ...>
[pid 977322] --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=977322, si_uid=1001} ---
[pid 977135] epoll_wait(4, [], 128, 0)  = 0
[pid 977327] <... futex resumed>)       = ?
[pid 977326] <... futex resumed>)       = ?
[pid 977325] <... futex resumed>)       = ?
[pid 977324] <... nanosleep resumed> <unfinished ...>) = ?
[pid 977323] <... futex resumed>)       = ?
[pid 977135] epoll_wait(4,  <unfinished ...>
[pid 977327] +++ killed by SIGQUIT (core dumped) +++
[pid 977326] +++ killed by SIGQUIT (core dumped) +++
[pid 977325] +++ killed by SIGQUIT (core dumped) +++
[pid 977324] +++ killed by SIGQUIT (core dumped) +++
[pid 977323] +++ killed by SIGQUIT (core dumped) +++
[pid 977322] +++ killed by SIGQUIT (core dumped) +++

SIGSEGV strace output second time in the loop:
pid 977135 - TestSignalForwardingExternal thread
pid 977334 - testp C thread
This snippet starts at line 156599:
[pid 977334] write(2, "OK\n", 3 <unfinished ...>
[pid 977135] <... epoll_wait resumed>[{events=EPOLLIN, data={u32=1023, u64=4395431198072}}], 128, -1) = 1
[pid 977334] <... write resumed>)       = 3
[pid 977135] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 977334] select(0, NULL, NULL, NULL, {tv_sec=60, tv_usec=0} <unfinished ...>
[pid 977135] <... clock_gettime resumed>{tv_sec=442530, tv_nsec=272942121}) = 0
[pid 977135] futex(0x290e58, FUTEX_WAKE_PRIVATE, 1) = 1
[pid 977135] read(3,  <unfinished ...>
[pid 977338] <... nanosleep resumed>NULL) = 0
[pid 977136] <... futex resumed>)       = 0
[pid 977338] futex(0xc00003ed48, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 977136] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 977135] <... read resumed>"OK\n", 4096) = 3
[pid 977336] <... nanosleep resumed>NULL) = 0
[pid 977136] <... clock_gettime resumed>{tv_sec=442530, tv_nsec=272980794}) = 0
[pid 977135] kill(977334, SIGSEGV <unfinished ...>
[pid 977336] nanosleep({tv_sec=0, tv_nsec=20},  <unfinished ...>
[pid 977136] nanosleep({tv_sec=0, tv_nsec=20},  <unfinished ...>
[pid 977135] <... kill resumed>)        = 0
[pid 977334] <... select resumed>)      = ? ERESTARTNOHAND (To be restarted if no handler)
[pid 977135] waitid(P_PID, 977334,  <unfinished ...>
[pid 977334] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_USER, si_pid=977135, si_uid=1001} ---
[pid 977334] rt_sigprocmask(SIG_SETMASK, NULL, ~[KILL STOP], 8) = 0
[pid 977334] rt_sigprocmask(SIG_SETMASK, ~[], NULL, 8) = 0
[pid 977334] sigaltstack(NULL, {ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=0}) = 0
[pid 977334] sigaltstack({ss_sp=0xc000040000, ss_flags=0, ss_size=32768}, NULL) = 0
[pid 977334] rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STKFLT CHLD STOP URG PROF RTMIN RT_1 RT_2], NULL, 8) = 0
[pid 977336] <... nanosleep resumed>NULL) = 0
[pid 977334] gettid( <unfinished ...>
[pid 977336] nanosleep({tv_sec=0, tv_nsec=20},  <unfinished ...>
[pid 977334] <... gettid resumed>)      = 977334
[pid 977334] rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
[pid 977334] rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=~[], sa_flags=SA_ONSTACK|SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
[pid 977334] getpid()                   = 977334
[pid 977334] gettid()                   = 977334
[pid 977334] tgkill(977334, 977334, SIGSEGV) = 0
[pid 977136] <... nanosleep resumed>NULL) = 0
[pid 977334] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_TKILL, si_pid=977334, si_uid=1001} ---

... <other stuff I don't understand> ...

[pid 977339] +++ killed by SIGSEGV (core dumped) +++
[pid 977338] +++ killed by SIGSEGV (core dumped) +++
[pid 977337] +++ killed by SIGSEGV (core dumped) +++
[pid 977336] +++ killed by SIGSEGV (core dumped) +++
[pid 977335] +++ killed by SIGSEGV (core dumped) +++
[pid 977334] +++ killed by SIGSEGV (core dumped) +++

One difference between the two test program executions is where the <... select resumed>)      = ? ERESTARTNOHAND (To be restarted if no handler) occurs but I don't know if that's significant.

Thanks for the pointer about GOTRACEBACK=crash.
It does seem possible to the signal to be delivered to a Go thread.  I think that https://go.dev/cl/419014 will fix the test problem.  Thanks.

Thanks for creating the CL @ianlancetaylor! I'm running go test -failfast -count=10000 -timeout=0 ./ -run TestSignalForwarding[EG].* on it now. So far so good.
Since this issue shows up on the new s390x builder VMs I'm preparing, could it also be backported?

@jonathan-albrecht-ibm Which releases would you want to see the patch in?

@ianlancetaylor I'd like to get this patch into the last two releases so that when I add the new s390x dashboard builder VMs there wouldn't be any chance of those builders failing on this test when testing security/point releases. I'm assuming that's needed but let me know if not or if there is another way of handling it.
I know 1.19 is about to be released so really I'd like to get it into which ever release branches are going to have further releases.  Would that be release-branch.go1.19 and release-branch.go1.18 right now?

I ran the TestSignalForwardingExternal and TestSignalForwardingGo tests from the CL on my s390x VM that was prone to failing the original TestSignalForwardingExternal test 10,000 times and got no failures:
$ go test -failfast -count=10000 -timeout=0 ./ -run TestSignalForwarding[EG].*
ok      misc/cgo/testcarchive   32440.474s

@gopherbot Please open backport to 1.18.
This is a test-only fix that avoids occasional test failures on s390x and possibly other systems.

Just back from vacation so belated huge thanks @ianlancetaylor!


Remote IP Address not showing up properly in second +IPD packet when using CIPDINFO

When I used the AT+CIPDINFO=1 command, I see the remote IP show up properly in the first recvied pacaket, but not the subsequent packets. Those packets show <IP_ADDRESS>
I think this might be a bug?

Hi @schwac , I have tested the command ,and found it is ok.
`AT+CWMODE=1
OK
AT+CWJAP="HUAWEI001","12345678"
WIFI CONNECTED
WIFI GOT IP
OK
AT+CIPMUX=1
OK
AT+CIPDINFO=1
OK
AT+CIPSTART=0,"TCP","<IP_ADDRESS>",8080
0,CONNECT
OK
+IPD,0,5,<IP_ADDRESS>,8080:12345
+IPD,0,5,<IP_ADDRESS>,8080:12345
+IPD,0,5,<IP_ADDRESS>,8080:12345
+IPD,0,8,<IP_ADDRESS>,8080:12345788
+IPD,0,10,<IP_ADDRESS>,8080:1234578834`
Can you post your test command?

Hi @schwac,
I will close the issue because of no update for a long time. If the problem persists, please reopen it again, thanks.


docs(federation): describe the technical federation architecture

🍰 Pullrequest

Issues

None

Todo

[X] draw a picture of the technical architecture for the current gradiod system moduls
[X] describe the steps and communication between the gradido system moduls of the current federation process

@einhornimmond Thank you for the improvement of the graphic!

Besides some types I believe this is ready to merge.


README screenshot doesn't show strikethrough correctly

I know that strikethrough isn't widely supported, but shouldn't the README screenshot (https://raw.githubusercontent.com/sindresorhus/ansi-styles/master/screenshot.png) show strikethough working?

Nah, doesn't matter. The current screenshot is more realistic of what you can expect. You shouldn't use strikethrough.


3.0 Root Certificate Expired

If the self-signed root CA certificate loaded to the client expires, the certificate will not be verified during SSL connection setup verification, and the SSL connection will be established.

Could you please describe the issue in more details? What does the self-signed root CA sign? The server certificate or the client certificate?

Could you please describe the issue in more details? What does the self-signed root CA sign? The server certificate or the client certificate?

The client loads an expired root CA certificate, and the server loads a normal secondary CA certificate and a device certificate. The root CA certificate, secondary CA certificate, and device certificate are certificate chains that can be authenticated. According to my understanding, the SSL connection fails to be established because the root CA is expired. However, the validity period of the root CA certificate is not verified during the current test in version 3.0.

The validation should in this case fail on the server side. Is the server side also openssl? And if so, does it actually require client certificate to be present or not?

If I am understanding correctly, the scenario here is that the root CA on the client (the trust anchor) has expired.  But this is not necessarily a problem, because in this setup the trust is anchored in the key of the root CA, and the certificate is largely just a convenient container to hold that key.  It can contain some additional metadata, yes, but that is to a large extent just advisory.  If the client does not want to trust the root CA past the expiration date of the containing X.509 certificate, the client is free to remove that entry from the root store.

The validation should in this case fail on the server side. Is the server side also openssl? And if so, does it actually require client certificate to be present or not?

the server is openssl, and he server does not verify the client.  just  client verify server

If I am understanding correctly, the scenario here is that the root CA on the client (the trust anchor) has expired. But this is not necessarily a problem, because in this setup the trust is anchored in the key of the root CA, and the certificate is largely just a convenient container to hold that key. It can contain some additional metadata, yes, but that is to a large extent just advisory. If the client does not want to trust the root CA past the expiration date of the containing X.509 certificate, the client is free to remove that entry from the root store.

but  in actual use, the client expects that the connection will fail once the certificate expires, instead of periodically checking whether the certificate expires. This is not a normal scenario.

but in actual use, the client expects that the connection will fail once the certificate expires

I don't believe that this is universally true of all clients.

but in actual use, the client expects that the connection will fail once the certificate expires

I don't believe that this is universally true of all clients.

ok, i see,The client must ensure that the root CA is within a limited period？

There is nothing stopping the client application to add a client cert verification call with X509_verify_cert that will report error if the client root CA has expired. As we said - it is not universally desirable so we will not change the TLS client implementation to do it automatically.

Closing since this question has been answered and no follow-up discussion has taken place.
Note that this issue is related to #13427, which has been fixed by #13590.


Prototype test: Natural Selection 1.0.0-rc.1

@amanda-phet, @ariel-phet, @kathy-phet, @KatieWoe, natural-selection/1.0.0-rc.1 is ready for prototype testing. This simulation will be put on the website as a prototype and will likely have more bugs than a publication-ready simulation.
Document issues in https://github.com/phetsims/natural-selection/issues and link to this issue. Issues should focus on base usability and pedagogy.
Assigning to @ariel-phet for prioritization.

General RC Test

What to Test

Play with the simulation normally.
Make sure you can't lose anything.
Complete the test matrix.
Try to include version numbers for browsers
If there is a console available, check for errors and include them in the Problem Description.
Focus on pedagogy issues and bugs that break the sim.
If you find bugs beyond pedagogy/breaking, still document these bugs as github issues.
If a11y aspects are present, test them, but with an eye for "normal use".

Focus and Special Instructions
There are many sim-specific query parameters in NaturalSelectionQueryParameters.js.  The only one that you need to consider for prototype testing is secondsPerGeneration (default 10), which determines how long it takes to complete 1 cycle of the generation clock. Decrease this value to make the clock run faster.

Link(s)

Simulation
Test Matrix

FAQs for QA Members

There are multiple tests in this issue... Which test should I do first?
Test in order! Test the first thing first, the second thing second, and so on.

How should I format my issue?

We typically assign the developer who opened the issue in the QA repository.

My question isn't in here... What should I do?
You should:

Consult the QA Book.
Google it.
Ask Katie.
Ask a developer.
Google it again.
Cry.

@KatieWoe assigning this one directly to @phet-steele as he expressed interest in performing this test as a way to "get back to the swing of things"
@phet-steele marking as medium priority as this test does not need to be extensive, but teachers will definitely be excited for the prototype version so sooner is better from that regard

In terms of important testing this prototype is basically done (thanks @phet-steele!)
I will do some cursory testing on an iPad and ask @amanda-phet and @oliver-phet to take a quick look on Mac

The 4 issues identified by @phet-steele have been addressed, awaiting review and verification in the next RC.
Assign this issue to me when @ariel-phet and @oliver-phet have complete their "quick looks" and I'll proceed with the next RC.  The next RC can likely be a "spot check" to verify the issues that @phet-steele identified.

We'll also need to verify the model changes the @amanda-phet requested in the next RC -- https://github.com/phetsims/natural-selection/issues/152, https://github.com/phetsims/natural-selection/issues/153.

I believe the testing matrix is complete now.

In retrospect we should have done a dev test first. There have been a lot of changed required for this RC. And it has become increasingly difficult (and time-consuming) to patch changes into the 1.0 branch, to the point where forward progress on master has ground to a halt.  After consulting with @ariel-phet, I'm going to give up on try to patch the 1.0 branch, and only make changes in master.  The next RC will either be in a new branch, or I will merge all changes from master into 1.0.  And before that RC, we'll do a quick test on a dev version.

"Issues to Verify" for the next RC:
PhET-iO:

[ ] empty client guides published with this sim design:phet-io
[ ] Studio search feature is broken
[ ] Add "Item" suffix to Solute combo box items

There's a new plan for the prototype, see https://github.com/phetsims/natural-selection/issues/116#issuecomment-682159770.
Closing this issue.


Add Ekman diffusion example

Add Ekman layer, stable boundary layer

@jakebolewski Design docs have been updated to include the equation sets / parameters

@yairchn @Zhengyu-Huang Could you update this issue when it's done? Thanks!

Closed by #51


(Prefix) subnet lookup

It would be nice if you could lookup the subnet when entering an IP address to a device.
If you've a lot of prefixes defined it can be hard to remember the defined prefix when you enter the IP address.
Maybe the input field could show a short list of prefixes in a kind of pop-up next to the input field to help you out which prefix to select.
I am aware this could be complex to figure this out how this should work, especially with IPv6, but it would be a great enhancement.
Maybe some one else can add some suggestions?

I'm not sure I understand how this would help. How would showing a list of all your prefixes help you determine what the device's IP should be? Why wouldn't you just use the existing prefix to find the desired prefix first?

I understand the way you're thinking with adding it through the prefix the other way around. I just thought it would be convenient if you could look it up the other way around when adding a device.
It might also be too complex to build in. It was just my two cents for improvement.


need better examples and common web space for SCHMA.TAG definitions

Gedcom-L is discussing SCHMA.TAG, and does not come to a solution how to do it. We understand every extension tag needs its own description, and this must be linked by SCHMA.TAG payload. In the specification we find examples for SCHMA.TAG. If you try to use them as link, you get a 404 error. We are not shure, how the definitions of extension tags should look like and where to find the citations of the spec, and hope for some readable examples.
Moreover: If every application is creating its own definitions for extension tags, merging their files will be a horror. So it would help a lot, if there is an common place in web where to put extension tag definitions and to use it by as many applications as possible. Only then we can be sure, that two extension tags have the same structure, as they have the same link. We do not see an automatic tool to compare two definitions of extension tags - created independently by different applications - and decide whether they describe the same tag or not. So importing extension tags will result in a mess of renamed tags if we cannot use same definitions for same purposes...
Especially in cases where extension tag solutions are recommended until later GEDCOM specs will have an implicit solution, the recommendations should be documented by SCHMA.TAG definitions.
Albert (Emmerich)

"Moreover: If every application is creating its own definitions for extension tags, merging their files will be a horror. "
Yes I agree.  The specification seams to imply that an extension is unique to the importing GEDCOM but does not take into account that any given software program will most likely be created from more than one imported GEDCOM files or have its own set of extensions that may (very likely) reuse the same extension tag with different meanings, locations, subtags and values/enumerations excepted for each tag.
It is also possible for similar definitions of extensions to use different tag names and a merge program would have no way to understand written definitions particularly if those definitions were written in different languages or call specific data values by different terms based on language or regional variations or the underlying understand of a specific usage.

I think there are four potentially-separable issues being discussed here.

FOAF is a bad example. That true both because (a) it experienced link-rot since 7.0.0 was published and (b) it was never a GEDCOM extension at all, just a Semantic Web ontology. I agree that it would be nice to replace it with another example, preferably an actual 7.0 extension, but so far as I know, no 7.0 extensions have been published yet. To this end, I added an example extension to my personal repositories: https://tychonievich.github.io/gx-g7-names. Would something like this be a better example than FOAF?

It would be nice to have a single central repository of extensions as not all extension authors can be relied upon to maintain good documentation in the long term. I agree, such a repository would be nice. I think the exid-types.json example shows that we can usefully have a repository of material that is not in the specification itself. That said, the right medium for such a repository when it comes to extensions is not immediately obvious to me.

A misunderstanding about Tags vs URIs. Everything you say about disagreements and collisions between extension authors is true of 5.5.1 and earlier extensions, which are permitted in 7.0 for backwards compatibility as undocumented extensions; but 7.0's documented extensions are resistant to to such collisions because it is URIs, not tags, that define their meaning. Merging files from programs that used conflicting extension tags can be handled by changing the extension tags without changing the URIs.
I should note that the URIs in no way remove the possibility of a central repository. I could imagine, for example, a repository that consists of a three-column table: extension URI, link to extension author's documentation (if any, which might be the URI itself or another link), and link to repository's version of the documentation.

We have discussed cases where extensions are recommended until a later version of the spec. _LANG is in the spec itself; two other proposed extension recommendations were not implemented (#97 and #98)—so far as I know those are the only such examples. All three examples (the one used and the two rejected) are relocated standard structures with example SCHMA entries provided. @albertemmerich, are you suggesting these recommended extensions need additional clarity?

re to Luther's no 3.:
GEDCOM 7 has again a problem with matching extension tags. Yes, they are defined by the URI. But it will happen, that the same extension tag is defined by two authors using two different URIs. So it does not make sense to rename one of these tags, but to check whether the URIs define the same tag. If so, only use one of them.
This problem will occur very often, if we do not offer the common web space. We have examples in German applications: For 5.5.1 we published an ADDENDUM defining a lot of extension tags. Many of them are still valid in 7.0 as GEDCOM 7.0 does not offer a structured solution. Examples _RUFNAME, _LOC,...
As the Gedcom-L ADDENDUM is not prepared to link to one of extensions tags (it is not fragmented), it cannot be used as SCHMA.TAG payload. The authors take the definitions of the tags, put the definition of one tag to an own webspace and link SCHMA.TAG to it. Here you are: The same extension tag by structure, name, payload requirements, substructures. However different URIs per application :-(
So if Gedcom-L creates its ADDENDUM 7 version for the tags, do all other programs willing to use these tags really will find the source, and use it, too? I think, no: It might happen that they define the same tag again and build an UIRI on their own.
Gedcom-L authors feel the problem was not solved by GEDCOM 7, may be it is more hard, as it will be very difficult to decide whether two URIs describe the same tag...
to no 4.: we need a valid example for a tag which is not defined in GEDCOM 7. As _LOC is very complicated, and has a long definition with a lot of substructures, we should start with _RUFNAME.

Let me give an example for an URI (URL) created before GEDCOM 7.0 was launched, but is used with GEDCOM 7.0 in the same way. The extension tag is:
_IMPF
This tag is used to link the record to the IMPorted File, and documenting the XREF of the record within that file, the author, and the date of import. By _IMPF we have an record <<_IMPF_RECORD>> and a calling <<_IMPF_STRUCTURE>>. You will find GEDCOM 7 files with this:
1 SCHMA
2 TAG _IMPF https://www.gen-do.de/Addendum/impf.html
If you follow that link, you find the definition written in German. If any application in the English speaking area wants to use this tag, do you think they will use the same URI (URL), or do you think they will have an own definition translated to English?

My first question would be.
if I was updating my application and decided to create an extension tag for “immigrant profile” and call it _IMPF.
How the heck would I know to even look at the German site to see that the tag was already in use.  Even if I was creating an extension for my application for “Import File” and wanted to call the tag _IMPFL or even _IMPF, I still have no clue to even look for the tag elsewhere or that I wanted several additional subtags for _TYPE, _IMPDT and _IMPID!

I also think that what some people are really looking for is a way to register extensions (and especially documentation for them) on some central site like gedcom.io for others to use to look up what has been defined and used by others.

You are thinking in terms of the user looking at a GEDCOM and determining what a tag means. BUT what about the developer of the import routine? They would most likely either kick the tag(s) to an error report if they don’t understand it and wash their hands of the whole thing or if their program thing it knows the tag(s), plop the data into some structure that probably does not make any sense to the user. Neither solution works for the end user.

If "you" means me, I'm thinking about it as a developer of an application that uses GEDCOM as its native format.   I would use the SCHMA.TAG to get the URI and use that to look up the correct entry in my tag table, in my import routine.   I haven't done that yet in my app, but it's on my list to do as I support more GEDCOM 7 features, and I understand how to do it.  (And this thread may motivate me to do so real soon now.)

If "you" means me, I'm thinking about it as a developer of an application that uses GEDCOM as its native format. I would use the SCHMA.TAG to get the URI and use that to look up the correct entry in my tag table, in my import routine.<

But the work of looking it up would be done after you wrote the code for the import and some user of yours two months or a year later gets a GEDCOM with an extension tag that you had not coded for.  That user would either lose data or have data dropped into the wrong bucket!

If "you" means me, I'm thinking about it as a developer of an application that uses GEDCOM as its native format. I would use the SCHMA.TAG to get the URI and use that to look up the correct entry in my tag table, in my import routine.<

But the work of looking it up would be done after you wrote the code for the import and some user of yours two months or a year later gets a GEDCOM with an extension tag that you had not coded for. That user would either lose data or have data dropped into the wrong bucket!

It sounds like you're assuming one has to write explicit code for each extension tag.  Not all apps do that.  Some (like mine, but I'm aware of others) preserve extension tags without knowing the meaning, e.g., just displaying the payloads to users, or preserving them when exporting.  In neither case is data lost or dropped into the wrong bucket per se.  I think worst case is just that the data becomes out of date if it's not modified when something else changes that it is supposed to be consistent with.
But that just leads to a recommendation (not a requirement) that extension tags not have values that have to be updated based on something else in the database.   One might have rules like "if the payload of a given structure changes, remove all unknown extension substructures under it" which can help in some cases.

It sounds like you're assuming one has to write explicit code for each extension tag. Not all apps do that. Some (like mine, but I'm aware of others) preserve extension tags without knowing the meaning, e.g., just displaying the payloads to users, or preserving them when exporting.<

Most of the mainstream programs (if not all) convert the incoming GEDCOM into a database that in most cases will not have a place to put all GEDCOM data.  This occurs today.
While your program may be a “Display as import”, these mainstream programs and a large majority of others are not.   The software I’m associated with both translates GEDCOM tags to actual words as well as translates the tags to multiple languages.  For Example: BIRT = Birth in English, Fødsel in Norwegian, Geburt in German, γέννηση in Greek.  Etc.

But actually I was responding to this statement, and the “you” was a reference to the programmer of most programs that interpret, internationalize, populate a database field, or otherwise display the tag code (ie, _IMFL) as a real word or concept!

A misunderstanding about Tags vs URIs. Everything you say about disagreements and collisions between extension authors is true of 5.5.1 and earlier extensions, which are permitted in 7.0 for backwards compatibility as undocumented extensions; but 7.0's documented extensions are resistant to to such collisions because it is URIs, not tags, that define their meaning. Merging files from programs that used conflicting extension tags can be handled by changing the extension tags without changing the URIs.<

URIs are still a problem with a merged file if you changed the tag name when there are collisions or just general use because “you” (the program) would never know what the incoming tag means, we’re to store it in the database that most mainstream application use, or how to internationalize the display name.

The name of the tag as used in the GEDCOM has no intrinsic significance, and so could be renamed with no consequences. For instance, a simple suffix
to differentiate similar names, such as custom_1 and custom_2 where "custom" was a clashing tag name.
The alternative using namespace prefixes (e..g. my:tag versus your:tag) would be bullet-proof but was universally voted against (I was the only
advocate) because namespaces are too complicated for many developers.
Tony
On 18/07/2022 23:21, Dave Thaler wrote:

My take on the latest questions:
it will happen, that the same extension tag is defined by two authors using two different URIs. So it does not make sense to
rename one of these tags, but to check whether the URIs define the same tag. If so, only use one of them.
This problem will occur very often

Probably all true except for the "it does not make sense to rename one of these tags". Any program can rename then at any time on a per-file basis
and according to the current spec that makes sense as long as the URI remains constant. I agree with Albert that very often apps would just use one
of them, even if the alternative does make sense. So when importing a file from another application, one really must be prepared to either rename
extension tags (preserving the URI), or drop them.
If you follow that link, you find the definition written in German. If any application in the English speaking area
wants to use this tag, do you think they will use the same URI (URL), or do you think they will have an own definition
translated to English?

I think I would use the same URI if I meant the same thing. However if I couldn't understand the definition because it's written in a language I
can't understand or find a good translator for, then I'd just define my own and not care about matching it. In that sense I would agree with.
How the heck would I know to even look at the German site

My main takeaway from the spec is that when defining documented extensions according to the FamilySearch GEDCOM 7 spec, one should not assume that
the documented extension tag must be unique or that one can look up a meaning for a given tag per se. Only the URI must be unique, and it currently
does not require the ability to even find any documentation (whether in a language you know or not). It need not be a URL, and it need not have any
way to find any actual documentation. Of course it is a lot more useful if it does, but it's not illegal if it doesn't.
—
Reply to this email directly, view it on GitHub https://github.com/FamilySearch/GEDCOM/issues/175#issuecomment-1188381275, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACDJB3VVISWRNJ2DW2JKOLDVUXKHNANCNFSM53YPOZPQ.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Tony, the name of the extension tag may be renamed. No problem, if URI would work. The problem is the mapping of the URIs to datafields within the application. I have to map the URI to the internal datafields to show the content to the user. If I have a mapping of one URI to my internal _IMPF data field, and I get the next URI from another GEDCOM file I have to check, whether this can be mapped to the same data field. Only after mapping I can provide the data with correct structure on my user interface.
The more different URIs we have for the same element, the more checkings I have to do. I do not see an automatic checking.
This may result in different _RUFNAME datafields in the program as long I could not identify the different URIs for it.
In the 5.5.1 world we have an inofficial list of names for extension tags, and with it the information which programs are using these tags. That could be handled. GEDCOM 7 is destroying this system, as we do not know how every application will build their own URI for any tag of this 5.5.1 list, and maybe applications are starting to rename the tags according differnet URI systems. Maybe the better solution is to stay with the 5.5.1 solution and use in GEDCOM 7 versions non documented tags as URI will not help. This is what I am doing so far in my application with all extension tags I know several programs are using. So far I am ignoring any SCHMA.TAG at import as it does not help me.
Sorry - I (and with me my German colleagues) do not understand, how an application can merge GEDCOM files from different other applications using different URI systems... We would need a central register to map URI to extension tags which our applications are supporting or which map the URIs of one application to the URIs of next application. Within my application the automatic mapping is only to my own URI, as I defined it.
Therefore we are asking for one URI web space, to avoid an amount of new application specific tag URIs which cannot be handled any more.
Albert

I am not 100% clear on your argument, Albert. Is it simply that you want to display  GEDCOM data to the end-user, and so want a mapping of URI ->
recognisable tag name (not annotated, or totally renamed)?
If this argument was presented by two different vendors using the same tag then there would be no solution.
The URI scheme was added to prevent clashes in 5.5.1 that would be totally ambiguous, and so unworkable.
I would argue that 95% of end-users wouldn't understand GEDCOM, even if it fell on their foot, but I acknowledge that you must have some application
requirement for it. I apologise because I don't use any public software, other than my own.
Tony
On 19/07/2022 11:13, Albert Emmerich wrote:

Tony, the name of the extension tag may be renamed. No problem, if URI would work. The problem is the mapping of the URIs to datafields within the
application. I have to map the URI to the internal datafields to show the content to the user. If I have a mapping of one URI to my internal _IMPF
data field, and I get the next URI from another GEDCOM file I have to check, whether this can be mapped to the same data field. Only after mapping I
can provide the data with correct structure on my user interface.
The more different URIs we have for the same element, the more checkings I have to do. I do not see an automatic checking.
This may result in different _RUFNAME datafields in the program as long I could not identify the different URIs for it.
In the 5.5.1 world we have an inofficial list of names for extension tags, and with it the information which programs are using these tags. That
could be handled. GEDCOM 7 is destroying this system, as we do not know how every application will build their own URI for any tag of this 5.5.1
list, and maybe applications are starting to rename the tags according differnet URI systems. Maybe the better solution is to stay with the 5.5.1
solution and use in GEDCOM 7 versions non documented tags as URI will not help. This is what I am doing so far in my application with all extension
tags I know several programs are using. So far I am ignoring any SCHMA.TAG at import as it does not help me.
Sorry - I (and with me my German colleagues) do not understand, how an application can merge GEDCOM files from different other applications using
different URI systems... We would need a central register to map URI to extension tags which our applications are supporting or which map the URIs
of one application to the URIs of next application. Within my application the automatic mapping is only to my own URI, as I defined it.
Therefore we are asking for one URI web space, to avoid an amount of new application specific tag URIs which cannot be handled any more.
Albert
—
Reply to this email directly, view it on GitHub https://github.com/FamilySearch/GEDCOM/issues/175#issuecomment-1188866720, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACDJB3SZXWNOUSJQD2WUPL3VUZ5UXANCNFSM53YPOZPQ.
You are receiving this because you commented.Message ID: @.***>

In version 5.3 of the GEDCOM specification the following was used:
USER_TAG_SCHEMA:=
n  <<USER_TAG_IN_CONTEXT>>
+m LABL <FULL_TAG_NAME>
+m DEFN <USER_TAG_DEFINITION>
+m ISA  <IS_A_KIND_OF_TAG>
With an example of:
n  SCHEMA
+1 INDI
+2 BIRT
+3 _HOSP
+4 LABL <FULL_TAG_NAME>
+4 DEFN <USER_TAG-DEFINITION>
+4 ISA  <IS_A_KIND_OF_TAG>
+3 _NURSE
+4 LABL <FULL_TAG_NAME>
+4 DEFN <USER_TAG-DEFINITION>
+4 ISA  <IS_A_KIND_OF_TAG>
An incoming GEDCOM “from the wild” would have the following information so that any program could better understand and either fully display the new tag or report an unknown value to the user.
n SCHEMA
+1 INDI
+2 BIRT
+3 _HOSP
+4 LABL Hospital
+4 DEFN The hospital name a person was born in.
+4 ISA Text
NOTE:  I’m not necessarily advocating for this specific solution but it gives a better and more useful definition of the incoming, “from the wild”, extension tag for a load program where they either have a defined database structure or programs that use GEDCOM directly.  The extension tag could have been “_XYZ2” with the same LABL of “Hospital” and an import program would still have a fighting chance of displaying the data with an understandable label.

Tony wrote: "I am not 100% clear on your argument, Albert. Is it simply that you want to display  GEDCOM data to the end-user, and so want a mapping of URI -> recognisable tag name (not annotated, or totally renamed)?"
Let me try again:
What we all need is to understand what infirmation the extension tag is carrying. Example Rufname: If I have a datafield for "Rufname" in my application, and I am using an extension tag _RUFNAME to export it, then I need to know at import, whether an URI is defining this Rufname, and I may rename the incoming extension tag to _RUFNAME. If my application cannot map the incoming tag by interpreting the URI coming with it, this mapping does not work.
A lot of applications are using _RUFNAME in the same way, and with 5.5.1 we import it by mapping our Rufname datafield to the tag name _RUFNAME. In GEDCOM 7.0 we will have the situation that the same data are coded using an URI defined by the application (specific for that application) and the tag name is no longer defining the tag, but the URI. The we do not have an agreed mapping URI <=> Rufname in between the applications as we had with _RUFNAME <=> Rufname. The tag maybe renamed to _EXTTAG00078 or so during any import.
What we see as the problem with GEDCOM 7, that the applications should create URI to define extTags in SCHMA.TAG and and cannot use a system of existing URIs (may be on a central web space). This will result in creating an own URI per application describing the data (i.e. for Rufname) with their words, in their lanuguage. How will we be able to interpret this mess of incoming URIs, especially if there is arbitrary renaming of the tags during import into programs and the name of the tag does not help any more?? You must rely on the URI, but there is no idea how an application interpretable URI should look like...

I think I understand, Albert.
The idea was that the URI uniquely defines the tag semantics, and so the mapping you outlined below should always work (i.e. no one else should mess
with a proprietary URI).
However, I think you are saying that several vendors may have a _RUFNAME extension, but with their own URIs, and you are expecting to catch them all.
This doesn't sound like a good idea, and is one of the reasons I was hoping that RUFNAME would be accepted as a standard tag -- there would then be no
ambiguity when looking at the URI.
Because of the commonality of the _RUFNAME extension then we need a single URI, either defined by FS or you group over there, Albert ... IMHO of course.
Tony
On 19/07/2022 18:23, Albert Emmerich wrote:

If my application cannot map the incoming tag by interpreting the URI coming with it, this mapping does not work.

Discussed in steering committee meeting.

In many cases, we can continue to use undocumented extension tags for existing extensions; per the spec, these have a meaning defined by their tag name. This will not always work, though, as some tags have collisions (e.g. _PLAC, _TODO) and would need a URI to be disambiguated. Because of these collisions, and for future collision avoidance, creating URIs for existing extensions may be wise.

We would like to create a repository of extensions (documented and not) like we have for EXID.TYPE; the details of what this should look like are not yet obvious. We expect we could benefit from what GEDCOM-L has done at https://wiki.genealogy.net/GEDCOM/_Nutzerdef-Tag. This repository could help prevent multiple URIs being defined for the same purpose.

Some of the other topics discussed above may be better pulled out into separate issues

Guys,  The talk of URI is just not answering the question I’m asking, what in a URI tells me anything about the meaning of the tag for a program that is importing an exTag from the wild generated by another program?  Tony has said he understands that many programs that base their exTag on GEDCOM-L and call their exTag _RUFNAME may have their own URI so a standard URI should be created to support all of them.  BUT in the wild my program can’t magically know what the URI means and the data will either be dropped or mislabeled.
Would some please answer this basic question?
I’ve worked with Data Dictionaries and data interchange software in the past.  The inclusion of a Data Dictionary from the GEDCOM creating to the GEDCOM receiving program as part of the gedZip file would be a great advantage!

Albert said in his initial entry:

We do not see an automatic tool to compare two definitions of extension tags - created independently by different applications - and decide whether they describe the same tag or not. So importing extension tags will result in a mess of renamed tags if we cannot use same definitions for same purposes...<

And I still don’t see an answer!  How or where does the URI help with this question?

steering committee stated yesterday: "2. We would like to create a repository of extensions (documented and not) like we have for EXID.TYPE; the details of what this should look like are not yet obvious."
Let's look at URI which were defined together with GEDCOM 7 spec, like https://gedcom.io/terms/v7/PLAC
Those URIs define the meaning of the tag, the super- and substructures, and explain some special situations. If we had a repository with URIs like this defining extension tags, too, applications are able to map the URI to their internal structure. For backward compatibility reasons we should assign a "recommended name" to the extension tags in 7.0, so the 5.5.1 way via defining tags by name (see https://wiki.genealogy.net/GEDCOM/_Nutzerdef-Tag) will be a starting point and the URI definitions could link the so far established extension tag names like _RUFNAME with URIs clearly defining its purpose and structures. This documentation put in a repository which is referenced in the official GEDCOM 7.0 documents will help a lot to avoid multiple URIs for same purpose, will help the applications to identify the exTags / URIs they support, and will be a starting point for discussions whether to add an extension tag as standard tag in next standard versions.
First step should be defining the internal structure of URIs and whether we will make them computer-readable for automatic interpretation by applications or we stay with a well structured form as used for GEDCOM 7 standard tags.
The repository could take definitions for 5.5.1 extensions, too. So the URI content should show for which standard versions the extension tag is defined.
For well documented extension tags as those defined and used by Gedcom-L group it is possible to transform existing definitions (see https://genealogy.net/GEDCOM/) so this can be a rather quick starting point for the repository.

the following is a draft for an URI for extension tag _RUFNAME:
`%YAML 1.2
type: structure
uri: #####/v7/_RUFNAME
extension tag, recommended tag name: _RUFNAME
descriptions:

Rufname (German)
the underlined given name within multiple given names of a person in an official (German) document

payload: http://www.w3.org/2001/XMLSchema#string
the payload must be one of the given names in payload of NAME, TRAN or GIVN
substructures: []
superstructures:
"https://gedcom.io/terms/v7/INDI-NAME": "{0:1}"
"https://gedcom.io/terms/v7/NAME-TRAN": "{0:1}"
...`
It could be published in an official repository ##### (tbd).

I don't like this -- not that this is going to influence people.
The whole object of using URIs was to unique identify the tags, and avoid the clashes where raw extension tags were previously used. Hence, by that
rationale, if _RUFNAMe (for instance) has a common definition and interpretation among a group of providers then there should be a single accepted URI
used by those providers. Trying to reverse-engineer URIs to old-style tag-names is completely against the design goal of GEDCOM 7.
As for repositories, documented functionality, and (in the future) enhanced meta-data for extension tags, not all tags are defined to be interpreted
by other software. This may be obvious but I just want to mention it. My product has about 5 or 6 extension tags that are used simply to persist data
that my program supports, and that is of no use to other software.
Tony
On 20/07/2022 10:02, Albert Emmerich wrote:

steering committee stated yesterday: "2. We would like to create a repository of extensions (documented and not) like we have for EXID.TYPE; the
details of what this should look like are not yet obvious."
Let's look at URI which were defined together with GEDCOM 7 spec, like https://gedcom.io/terms/v7/PLAC https://gedcom.io/terms/v7/PLAC
Those URIs define the meaning of the tag, the super- and substructures, and explain some special situations. If we had a repository with URIs like
this defining extension tags, too, applications are able to map the URI to their internal structure. For backward compatibility reasons we should
assign a "recommended name" to the extension tags in 7.0, so the 5.5.1 way via defining tags by name (see
https://wiki.genealogy.net/GEDCOM/_Nutzerdef-Tag https://wiki.genealogy.net/GEDCOM/_Nutzerdef-Tag) will be a starting point and the URI
definitions could link the so far established extension tag names like _RUFNAME with URIs clearly defining its purpose and structures. This
documentation put in a repository which is referenced in the official GEDCOM 7.0 documents will help a lot to avoid multiple URIs for same purpose,
will help the applications to identify the exTags / URIs they support, and will be a starting point for discussions whether to add an extension tag
as standard tag in next standard versions.
First step should be defining the internal structure of URIs and whether we will make them computer-readable for automatic interpretation by
applications or we stay with a well structured form as used for GEDCOM 7 standard tags.
The repository could take definitions for 5.5.1 extensions, too. So the URI content should show for which standard versions the extension tag is
defined.
For well documented extension tags as those defined and used by Gedcom-L group it is possible to transform existing definitions (see
https://genealogy.net/GEDCOM/ https://genealogy.net/GEDCOM/) so this can be a rather quick starting point for the repository.
—
Reply to this email directly, view it on GitHub https://github.com/FamilySearch/GEDCOM/issues/175#issuecomment-1190017442, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACDJB3SBDIOJMQIDVVQM7ETVU66BFANCNFSM53YPOZPQ.
You are receiving this because you commented.Message ID: @.***>

ACProctor said:

My product has about 5 or 6 extension tags that are used simply to persist data that my program supports, and that is of no use to other software.

Then why send it to me in a GEDCOM?
I’ve always been against none-standard tags being sent in a GEDCOM and more importantly ones that no genealogical meaning, (I’m thinking of tags for example: defining photo zoom and face recognition or printing instructions). Programs should always send only standard GEDCOM, defined in the specific release of the Standard.  The use of “extensions” in the transfer of data between two dissimilar programs should be eliminated because in general the data will be most likely dropped or misused by the receiving program because they will not understand the use!
I get that programs need to have additional data points in their application database to support concepts and enhancements they implement, but sending that data to an unknown program and thinking for a minute that it will be understood is ridiculous!
I’d rather see GEDCOM be a living, breathing concept that thru knowledgeable genealogists gets periodic updates that fix missing data-points.
If Rufname is an important concept that is unique in its self then it needs to be added to the NAME subtag set.   However, if Rufname can be normalized to a common term such as ‘Call Name’ with a TYPE tag of ‘Rufname’, where the new ‘Call Name’ subtag can also have a TYPE of ‘Preferred’, ‘Nick’, ‘Other’ (for example), then I think this would be a better solution, and easier to expand.

They have meaning in my genealogical product, and so are important if the file gets loaded back into my product after sharing with other users of it.
So, I'm not "sending to you" and you can simply ignore it. I do not acknowledge any problem here.
Tony
On 11/10/2022 14:26, Norwegian-Sardines wrote:

ACProctor said:
My product has about 5 or 6 extension tags that are used simply to persist data that my program supports, and that is of no use to other software.

Then why send it to me in a GEDCOM?
I’ve always been against none-standard tags being sent in a GEDCOM and more importantly ones that no genealogical meaning, (I’m thinking of tags for
example: defining photo zoom and face recognition or printing instructions). Programs should always send only standard GEDCOM, defined in the
specific release of the Standard. The use of “extensions” in the transfer of data between two dissimilar programs should be eliminated because in
general the data will be most likely dropped or misused by the receiving program because they will not understand the use!
I get that programs need to have additional data points in their application database to support concepts and enhancements they implement, but
sending that data to an unknown program and thinking for a minute that it will be understood is ridiculous!
I’d rather see GEDCOM be a living, breathing concept that thru knowledgeable genealogists gets periodic updates that fix missing data-points.
If Rufname is an important concept that is unique in its self then it needs to be added to the NAME subtag set. However, if Rufname can be
normalized to a common term such as ‘Call Name’ with a TYPE tag of ‘Rufname’, where the new ‘Call Name’ subtag can also have a TYPE of ‘Preferred’,
‘Nick’, ‘Other’ (for example), then I think this would be a better solution, and easier to expand.
—
Reply to this email directly, view it on GitHub https://github.com/FamilySearch/GEDCOM/issues/175#issuecomment-1274685662, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACDJB3S2K6VRXFO2AC4AWW3WCVTKDANCNFSM53YPOZPQ.
You are receiving this because you commented.Message ID: @.***>

ACProctor said:

So, I'm not "sending to you" and you can simply ignore it. I do not acknowledge any problem here.

If your GEDCOM comes to me for merging into another application then it will need to parse out GEDCOM rather than reading all of the GEDCOM into a record!  So while you don’t acknowledge any problem, it is a problem for the receiving program.
If extensions to GEDCOM are allowed, then all extensions need to be parse by the receiving program and resolved for display and or reassignment.
I would hope that programs that generate extensions would have the option of not generating those extensions.

As I said, this particular case of extension tags can be ignored by other products, as was the case in older versions. They are single records with
plain-text payloads, which makes it a trivial operation.
Tony
On 11/10/2022 15:32, Norwegian-Sardines wrote:

ACProctor said:
So, I'm not "sending to you" and you can simply ignore it. I do not acknowledge any problem here.

If your GEDCOM comes to me for merging into another application then it will need to parse out GEDCOM rather than reading all of the GEDCOM into a
record! So while you don’t acknowledge any problem, it is a problem for the receiving program.
If extensions to GEDCOM are allowed, then all extensions need to be parse by the receiving program and resolved for display and or reassignment.
I would hope that programs that generate extensions would have the option of not generating those extensions.
—
Reply to this email directly, view it on GitHub https://github.com/FamilySearch/GEDCOM/issues/175#issuecomment-1274793044, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACDJB3TOMOSX3X7H5GFQOKDWCV3ARANCNFSM53YPOZPQ.
You are receiving this because you commented.Message ID: @.***>

As such it would also be a trivial operation to not send the extensions in the first place.
I’m reminded of a guiding principle of database design and program development that to never generate data that is invalid or undefined.  One of the primary reasons “Better GEDCOM” and its successor FHISO were created and much needed, was to standardize the sharing and transfer of genealogical data between applications.  By including undefined and/or non-genealogical data in a GEDCOM, the value of the GEDCOM is reduced.
However, since you will probably continue sending these tags, we will have to agree to disagree!  I’m out on this specific topic!

What about _LOC tag, and the location records? This is a bigger step.

Yes, my suggestion would be to develop a tag and record similar to NOTE and SNOTE.  Call them PLAC and SPLAC!  And see if it can be added in at v7.1. I would like this option as well!
I’m in favor of defining more standard structures as well, but sending a structure (for example) _MARNM when a perfectly good standard structure is also available should be a no-no.
I’ve see cases were an extension is used (for example) _HUSB in a same sex marriage so that the code can determine the sex of the partner rather than looking up the sex in the INDI record.   If I export to this program and they expect a _HUSB, but I send them a WIFE they would identify that man as a female.  Or they send me a GEDCOM with a _HUSB and I drop the connection in my FAM record.  That would cause issues, bidirectional links are broken, and a family record losses a partner.
The above is just an example of where extensions that relate to functionality go off kilter! I don’t need a solution!

@Norwegian-Sardines I completely agree with everything you say. I share your concern. This has the potential to get very messy very quickly.


While running a project ,there is a problem with gradle.

It displaying that Failed to build

It displaying that Failed to build

Go to Invalidiate caches and sync or rebuild the project . Hope it helps


About AppInstance.RecommendedInstance

Could you show me the detailed scenarios that when the shell will set an instance to AppInstance.RecommendedInstance? "Some scenario" does not make sense.

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

ID: 9554b9f2-2f49-1833-1143-0103c18c37c8
Version Independent ID: ef28f9ce-bd72-0435-6238-95d574eabee1
Content: Create a multi-instance Universal Windows App - UWP app developer
Content Source: windows-apps-src/launch-resume/multi-instance-uwp.md
Service: unspecified
GitHub Login: @TylerMSFT
Microsoft Alias: twhitney

Hi, @pnp0a03, it seems that, right now, the shell never sets a non-null value for RecommendedInstance. I'm about to fix the AppInstance.RecommendedInstance topic to make that clear. That fix should be live by Monday morning.