Support multiple languages for Readme.md.

Description of the new feature/enhancement
Support multiple languages for Readme.md.
Having a documentation in your native language is essential if you don't speak English, and still enjoyable even if you do. This new feature would help more people who are not familiar with English to know this Windows Package Manager.
If a user is Chinese, he/she may search the information with Chinese rather than English. So it is necessary to add other language version for the Readme.

Proposed technical implementation details (optional)

We don't have a good mechanism for providing translations at GitHub. Fortunately, for https://docs.microsoft.com/windows/package-manager/ we do.

We don't have a good mechanism for providing translations at GitHub. Fortunately, for https://docs.microsoft.com/windows/package-manager/ we do.

How do I turn off the translation of winget? The only language setting I could find is for "installBehaviour", but any message winget itself outputs is still translated (and frankly driving me nuts).


Assignment 3 (Java Mini Project)

Metric
Value

alert_status
:white_check_mark: OK

bugs
0

code_smells
5

reliability_rating
A (0 Bugs)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0


Open-ECC Wallet Install and Testing

Finish seed phrase fix first.

Idea: piggyback off the brownbag?
Idea: Invite everyone who hasn't downloaded the app to an install party. BE AGGRESSIVE.
Idea: Fellowship of the ZEC, but with ECC wallet only.

Drop it for this sprint and organize a bit before doing this event.
We also may want to get in a lot of last minute improvements before this push.


After upgrading Dart SDK, flutter breaks for beta channel in windows

Steps to Reproduce

upgraded flutter with flutter upgrade
upgrade process fails with following issue on windows.

Logs

Logs

flutter doctor
Building flutter tool...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (9 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (8 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (7 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (6 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (5 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (4 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (3 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (2 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Running pub upgrade...
Because flutter_tools depends on charcode 1.2.0 which doesn't match any versions, version solving failed.
Error (1): Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (1 tries left)

Waiting for 0 seconds, press CTRL+C to quit ...
Error: 'pub upgrade' still failing after 10 tries.
Can't load Kernel binary: Invalid kernel binary format version.

Also tried -
To switch back to stable version - Not possible same error.
Deleted the flutter folder and then installed again.
Stable channel works well. Upgrading to beta introduces the same issue.

Are you perhaps using a pub mirror that is not up to date? pub.dev/packages/charcode shows 1.2.0 as published...
This is an unfortunate cycle though. What's happening is the tool fails to rebuild because of a pub failure, and then it looks like it might be trying to load an older snapshot somehow that isn't compatible with the new revision of Dart.
@jonahwilliams do we have a bug for this? I'm not 100% sure I understand how to reproduce it - like, what kernel binary is it actually trying to load and failing...

Hi @arnabchat90
Unable to reproduce this on Windows 10 when beta or any other channel (multi SDK setup)
Can you please provide the details asked above?
Thank you

Also had the same kind of error but it was after adding some packages with Pubsect Assist. I fix it by either upgrading to null-safety version or downgrading to latest stable version of packages. It was in a new Flutter beta project.
This error:
[rocket_guide] flutter pub get
Running "flutter pub get" in rocket_guide...
Because google_fonts 1.1.2 depends on http ^0.12.0+2 and no versions of google_fonts match >1.1.2 <2.0.0, google_fonts ^1.1.2 requires http ^0.12.0+2.
So, because rocket_guide depends on both google_fonts ^1.1.2 and http ^0.13.0, version solving failed.
pub get failed (1; So, because rocket_guide depends on both google_fonts ^1.1.2 and http ^0.13.0, version solving failed.)
exit code 1
was the last one where I had to change http from the null-safety (preview) version ^0.13.0 to the latest ^0.12.2.
I had a previous error pertaining to freezed_annotation and I fixed it by upgrading to the null-safety version. The message always seems pretty confusing to me.
I know it's not the same as upgrading flutter but these are new errors and might be related, IMHO.


Description for Procedure

@Marvasuo, you suggest using AR/YDIN - Toimenpiteen tyyppi codes in Procedure.category. Can you refer to a doc where this is recommended as a practice? Does CGI do this internally?

@Marvasuo, you suggest using AR/YDIN - Toimenpiteen tyyppi codes in Procedure.category. Can you refer to a doc where this is recommended as a practice? Does CGI do this internally?

The problem for me is that .category has a max cardinality of 1, and therefore the category should be really carefully considered.
And the base FHIR spec proposes categories to be drawn from a SNOMED value set http://hl7.org/fhir/valueset-procedure-category.html. This is also closer to what I would expect to see in category, rather than the breadth of scope or severity of the procedure.

It would be nice to have a formal link to the procedure codes in the Terminologies section.
Koodistopalvelu says:

Toimenpideluokitus pohjautuu pohjoismaiseen kirurgiseen luokitukseen (NCSP Nordic Classification of Surgical Procedures), joka on julkaistu ensimmäisen kerran v. 1996. NCSP-luokitusta ylläpitää Pohjoismaiden luokituskeskus (NCC) ja sen tekijänoikeudet ovat NOMESKO:lla.

I did not immediately find a link I could consider the "official one". Anyone else?

I did find the document https://norden.diva-portal.org/smash/get/diva2:970547/FULLTEXT01.pdf. It refers to http://www.nordclass.org. However, that page redirects to https://www.ehelse.no/kodeverk/the-nordic-who-fic-classification-centre-nordclass that gives me HTTP 404...

It also refers to nom-nos.dk. And that redirects to https://nhwstat.org. That's the right address then, right?


Making multipart form handling easier

The only way to send attachements with a form is using the multipart content encoding. This means it won't be nested json datastructure, but use the actual names put on fields blah.foo.
Both axios and superagent support creating multipart requests by sending a https://developer.mozilla.org/en/docs/Web/API/FormData FormData object.
It would be nice if there were an option to get FormData from the form submission event. Right now I'm reversing the process you use to construct the object data structure.

This is a usage question, and we try to use the issue tracker for bug reports and feature requests, as well as some discussions. StackOverflow is better place to ask for help.
You can create an helper to manipule values from onSubmit to create a FormData instance. Since this use case is really specific I don't think it should be included in Redux Form core.

How are attachments really specific? That's a common thing forms do...

+1

Something can be done like this :
reduxForm({
form: 'myForm',
multipartForm : true, // <- handle this form as a multipart from and send to handleSubmit a FormData object populated by the form's values
validate
})(MyFormView);

This should be included in redux-form core :/
Its a really importante feature.

This NEEDS to be in the core. This is not a `really specific user case.

PRs are always considered.
You guys do understand that the data is kept in JSON (or Immutable.Map) in Redux, right? So any multipart form solution is going to have to convert the JSON to FormData. I'm not sure why adding that additional code to the core library, for everyone, even without this use case to have to download, is a good solution. It seems like something additional thing that could be included in a project. A quick NPM search discovers a little-used library, json-to-form-data, for example. The fact that it doesn't get much use might be meaningful.

Not sure if this is the best solution for everyone on here, but assuming you haven't built a wizard form, you can just grab the fields off the DOM. That way you never have to worry about the JSON equivalents. This is especially great for multipart forms i.e. file fields.
const onSubmit = () => {
	const formData = new FormData(document.getElementById('my-form'));
	fetch('http://localhost:8000/my-script', {
		method: 'POST',
		body: formData
	});
};
//...
<MyForm onSubmit={onSubmit} />
//...
class MyForm extends Component {
	static propTypes = {
		handleSubmit: PropTypes.func
	};
	render() {
		return (
			<form onSubmit={this.props.handleSubmit} encType="multipart/form-data" id="my-form">
				<Field label="Name" name="name" component={input} type="text" />
				<Field label="Attachments" name="attachments" component={input} type="file" multiple value={undefined} />
				<button type="submit">Submit</button>
			</form>
		);
	}
}

I just wanted to add on to @tmaclean-LV with what I did to make sure all reduxForm fields were included: (where file is the file field param so it doesn't get overwritten)
const paramsToFormData = (data, params, preceding = '') => {
  for(let [k,v] of Object.entries(params)){
    if(v instanceof Object && v.constructor === Object){
      data = paramsToFormData(data, v, `${preceding}${k}.`)
    } else {
      data.set(`${preceding}${k}`, v)
    }
  }
  return data
}
onSubmit = async ({file, ...params}) => {
  let data = new FormData(document.getElementById('my-form'))
  data = paramsToFormData(data, params, "")
  console.log(data)
}

I did this:
export const convertToFormData = (fields) => {
  if (fields) {
    const form_data = new FormData();

    for (var key in fields) {
      if (key === 'file') {
        form_data.append(key, fields[key][0]);
      } else {
        form_data.append(key, fields[key]);
      }
    }

    return form_data;
  }
};

Then Axios picks up on the formData object perfectly.


Some row queries not working

Example:
https://dev.proxy.hxlstandard.org/data/edit?filter01=select&select-query01-01=targeted%2Bf+is+empty&url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1ytPD-f4a8CbNKTfMS3EqZOpBo9LWCk_NDKxJCgmpXA8%2Fedit%23gid%3D1101521524
is empty, is not empty, ~, and !~ seem to be problems

Part of the problem was that hxl.model.RowQuery was skipping empty values, so is empty or ~ ^$ could never be True

Deployed to beta


0.4.0 Roadmap

#55 identified a memory usage problem for archive module. Our goal for 0.4.0 is to resolve this problem and address the following issue.

[ ] default ruby provider should use net::http with streaming.
[ ] faraday should no longer be a requirement for puppet agents #60. (for now remain a requirement for puppet master for the define types/functions)
[ ] faraday can be used as an alternative provider to support migration.
[ ] linux system can use alternative default providers #61.

Since this requires several changes, master will be unstable until we resolve them. Please feel free to discuss or comment on this issue if you have any input.

This is pretty sweet. I'm excited to see open development and roadmap. Are there any testing needs you have that travis can't provide? That's kindof my current kick. @igalic mentioned that we may be hitting max_concurrent travis testing now.

Travis is sufficient for now, do we have a standard gemfile/.travis.yml config?

https://github.com/puppet-community/puppet-extlib has a good Gemfile, Rakefile, .travis.yml
That also provides hooks for you to setup blacksmith deploys of archive. I'm not sure if you want to keep publishing this to your own namespace or use forge.puppetlabs.com/puppet.
The secure: line comes from:
https://github.com/puppet-community/plumbing/blob/master/share/travis_secrets

@nanliu can you publish a 0.3.1 version in forge with archive::nexus support?

https://github.com/puppet-community/puppet-archive/pull/64 would enable the bits to enable push button deploys, which would open the door to a 3.1

@nanliu can you publish a 0.3.1 version in forge with archive::nexus support?

+1

+1 for not having to install faraday on every system, especially when no internet access is available or a local ruby gems server.  I have been working on a hacked version that bundles the gems inside the files directory.

#82 brought us up to date with https://github.com/puppet-community/modulesync_config so we're in line with some other modules and their styling/methodology.

Also, @nanliu should this issue be for 0.5.0 now?

@jyaworski, issue updated, looking for volunteers to test:

[ ] Windows platform (review & test #124).
[ ] go function (changes in progress)
[ ] artifactory function (changes in progress)

Merged #124


script.sh: uninstall instead of zap

Reverts https://github.com/caskroom/homebrew-cask/pull/44407
Running zap makes the leftover check less useful in some cases because it explodes trying to remove files it doesn't have permissions to and doesn't run the check.

Also, uninstall should usually be enough to remove everything install installs, except for the special case which prompted https://github.com/caskroom/homebrew-cask/pull/44407.


Switch to D3 v4

at some point in the future

in the latest branch, D3 is used for

scaling in the model
dom renderer for individual rows (could be changed)
header and pool renderer


add lomas client doc

Coverage report

This PR does not seem to contain any modification to coverable code.


Add known limitation for collation names

The bug was introduced in v19.2 and will be fixed in v21.1
References https://github.com/cockroachdb/cockroach/issues/56335

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/f711ac82c17603928408b16384f75f4c3619b257/
Edited pages:

v19.2/known-limitations.md
v20.1/known-limitations.md
v20.2/known-limitations.md

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/e8ef19edae28458f4335e86d747a1a14667cf0e0/
Edited pages:

v19.2/collate.md
v19.2/known-limitations.md
v20.1/collate.md
v20.1/known-limitations.md
v20.2/collate.md
v20.2/known-limitations.md


Permission Testing & Alignment

This is a merge of the permission work done in #3908 , at commit<PHONE_NUMBER>c6395fd7a35fb92790e0efb37b44f6, but only of the testing work/changes since the fundamental user permissions work came to a barrier.
Docs update

Update permissions user doc page.

Provide an "advanced" overview of deeper combination logic

Upgrade notice, linking to above added section for more details, advising slight change in logic handling.
Upgrade notice, potential longer db migration time on upgrade due to permission regeneration.

Merging in now so things can be passively tested during other developments.
Will continue manual testing here and there on development up to release.


DAOIP-5 Update: Add Transformer Script v0

Transformer script is used to generate two types of JSON files:

Applications URI JSON: Contains grant applications data from a CSV file.
Grants Pool JSON: Contains metadata about grants pools from a YAML file.

Commands and Options:
Basic Usage:
    python3 main.py --csv_file <path-to-csv> [--yaml_file <path-to-yaml>] [--generate <applications|grants|both>]
Arguments:
- `--csv_file`: **Required**. The path to the CSV file containing project data (e.g., funding amounts, project names, etc.).
- `--yaml_file`: **Optional**. The path to the YAML file containing metadata (used to generate the grants pool JSON).
- `--generate`: **Optional**. You can specify what to generate:
  - `applications`: Only generate the Applications URI JSON.
  - `grants`: Only generate the Grants Pool JSON.
  - `both` (default): Generate both the Applications URI and Grants Pool JSON.

Example Commands:

Generate Only Applications URI JSON:
python3 main.py --csv_file /path/to/projects.csv --generate applications

Generate Only Grants Pool JSON (Requires YAML File):
python3 main.py --csv_file /path/to/projects.csv --yaml_file /path/to/metadata.yaml --generate grants

Generate Both Applications URI and Grants Pool JSON:
python3 main.py --csv_file /path/to/projects.csv --yaml_file /path/to/metadata.yaml --generate both

Output:

The script will generate the following files in the ./json/ folder:

*_applications_uri.json: The Applications URI JSON based on the provided CSV data.
*_grants_pool.json: The Grants Pool JSON based on the provided YAML metadata (if applicable).

File Structure:
- CSV: Contains project-related data such as funding amount, project name, grant pool name, etc.
- YAML: Contains metadata about the DAO or organization running the grants program (used for grants pool generation).

Thanks so much @Rashmi-278 ! This looks great :)


VAPOR crashes when run through Rosetta (x86 emulation) on arm64 based M1 Macbook. Missing library?

Describe the bug
I cannot run the most recent dmg release (version 3.7) on my Macbook with Apple's new arm64 based M1 processor. There is a x86 emulation layer called Rosetta which should translate the Intel-compiled binaries but it seemingly fails to run VAPOR. This was also observed in #2609 but is not the main problem of that issue, so I thought I would open a new one. I am happy to do some debugging but I would need guidance for that. Please let me know if you need additional info.
Helpful additional information
This is the report I get after crashing. It shows, that indeed Rosetta was used to run the arm64 translated version of VAPOR and appears to be missing the geotiff library: Library not loaded: '/usr/local/VAPOR-Deps/2019-Aug/lib/libgeotiff.5.dylib'
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               vapor [11165]
Path:                  /Applications/vapor.app/Contents/MacOS/vapor
Identifier:            Vapor3
Version:               3.7.0} (3.7.0.)
Code Type:             X86-64 (Translated)
Parent Process:        launchd [1]
User ID:<PHONE_NUMBER>

Date/Time:             2022-10-05 09:49:16.8246 +0200
OS Version:            macOS 12.6 (21G115)
Report Version:        12
Anonymous UUID:        30694B89-08A6-8650-A190-3B22F8CE8674

Time Awake Since Boot: 3800 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: '/usr/local/VAPOR-Deps/2019-Aug/lib/libgeotiff.5.dylib'
Referenced from: '/Applications/vapor.app/Contents/MacOS/vapor'
Reason: tried: '/usr/local/VAPOR-Deps/2019-Aug/lib/libgeotiff.5.dylib' (no such file), '' (no such file), '' (no such file)
(terminated at launch; ignore backtrace)

Thread 0 Crashed:
0   Rosetta Runtime Routines	       0x100eda940 ???
1   <translation info unavailable>	       0x100f23c34 ???
2   dyld                          	       0x200e0da72 abort_with_payload_wrapper_internal + 80
3   dyld                          	       0x200e0daa4 abort_with_payload + 9
4   dyld                          	       0x200dbb699 dyld4::halt(char const*) + 615
5   dyld                          	       0x200db75b5 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3995
6   dyld                          	       0x200db64e4 start + 388

Thread 1:: com.apple.rosetta.exceptionserver
0   runtime                       	    0x7ff7ffd0a944 0x7ff7ffd06000 + 18756
1   runtime                       	    0x7ff7ffd183e0 0x7ff7ffd06000 + 74720
2   runtime                       	    0x7ff7ffd19e58 0x7ff7ffd06000 + 81496

Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000006   x1: 0x0000000000000001   x2: 0x0000000305845aa0   x3: 0x0000000000000077
    x4: 0x00000003058456a0   x5: 0x0000000000000000   x6: 0x70258923d503201f   x7: 0x00000020d503201f
    x8: 0x00000003058456a0   x9: 0x0000000000000000  x10: 0x0000000000000077  x11: 0x0000000305845aea
   x12: 0x0000000000000077  x13: 0x0000000305845aa0  x14: 0x0000000000000001  x15: 0x0000000000000006
   x16: 0x0000000000000209  x17: 0x0000000000000000  x18: 0x8000000108f43b70  x19: 0x0000000100ed0000
   x20: 0x00000000000007ff  x21: 0x0000000108f48fa0  x22: 0xffffffffffffffff  x23: 0x0000000100eda914
   x24: 0x0000000200e0da72  x25: 0x0000000100eda1f4  x26: 0x0000000100f231d8  x27: 0x0000000000000000
   x28: 0x0000000200df798e   fp: 0x000000002c000000   lr: 0x0000000100f23c34
    sp: 0x0000000108f43b70   pc: 0x0000000100eda940 cpsr: 0x80001000
   far: 0x0000000109504010  esr: 0x56000080  Address size fault

Binary Images:
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
       0x200db1000 -        0x200e1cfff dyld (*) <71febccd-d9dc-3599-9971-2b3407c588a8> /usr/lib/dyld
    0x7ff7ffd06000 -     0x7ff7ffd35fff runtime (*) <1f0f0114-cfb6-304b-8183-8ef52c21f8b4> /usr/libexec/rosetta/runtime

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=5436K resident=0K(0%) swapped_out_or_unallocated=5436K(100%)
Writable regions: Total=155.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=155.3M(100%)

                                VIRTUAL   REGION
REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Rosetta Arena                     4096K        2
Rosetta Generic                    776K      191
Rosetta IndirectBranch              32K        1
Rosetta JIT                      128.0M        1
Rosetta Return Stack                20K        2
Rosetta Thread Context              20K        2
Stack                             8176K        1
Stack Guard                       56.0M        1
VM_ALLOCATE                       13.3M        6
VM_ALLOCATE (reserved)              68K        4         reserved VM address space (unallocated)
__DATA                             372K        9
__DATA_CONST                        80K        1
__LINKEDIT                        1812K       10
__TEXT                            3656K        7
dyld private memory               1024K        1
mapped file                        6.1G       43
===========                     =======  =======
TOTAL                              6.3G      282
TOTAL, minus reserved VM space     6.3G      282

-----------
Full Report
-----------

{"app_name":"vapor","timestamp":"2022-10-05 09:49:16.00 +0200","app_version":"3.7.0}","slice_uuid":"179c15c1-c945-36b8-8b07-ef252ff5c736","build_version":"3.7.0.","platform":1,"bundleID":"Vapor3","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 12.6 (21G115)","incident_id":"95AEE5E2-985A-410D-92E7-DAB89315F6D7","name":"vapor"}
{
  "uptime" : 3800,
  "procLaunch" : "2022-10-05 09:49:16.7853 +0200",
  "procRole" : "Default",
  "version" : 2,
  "userID" : xxxx,
  "deployVersion" : 210,
  "modelCode" : "MacBookPro18,3",
  "procStartAbsTime" :<PHONE_NUMBER>1,
  "coalitionID" : 2055,
  "osVersion" : {
    "train" : "macOS 12.6",
    "build" : "21G115",
    "releaseType" : "User"
  },
  "captureTime" : "2022-10-05 09:49:16.8246 +0200",
  "incident" : "95AEE5E2-985A-410D-92E7-DAB89315F6D7",
  "bug_type" : "309",
  "pid" : 11165,
  "procExitAbsTime" :<PHONE_NUMBER>9,
  "translated" : true,
  "cpuType" : "X86-64",
  "procName" : "vapor",
  "procPath" : "\/Applications\/vapor.app\/Contents\/MacOS\/vapor",
  "bundleInfo" : {"CFBundleShortVersionString":"3.7.0}","CFBundleVersion":"3.7.0.","CFBundleIdentifier":"Vapor3"},
  "storeInfo" : {"deviceIdentifierForVendor":"92D764DF-586D-5B08-8166-F50D0E78C4BC","thirdParty":true},
  "parentProc" : "launchd",
  "parentPid" : 1,
  "coalitionName" : "Vapor3",
  "crashReporterKey" : "30694B89-08A6-8650-A190-3B22F8CE8674",
  "sip" : "enabled",
  "isCorpse" : 1,
  "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},
  "termination" : {"code":1,"flags":518,"namespace":"DYLD","indicator":"Library missing","details":["(terminated at launch; ignore backtrace)"],"reasons":["Library not loaded: '\/usr\/local\/VAPOR-Deps\/2019-Aug\/lib\/libgeotiff.5.dylib'","Referenced from: '\/Applications\/vapor.app\/Contents\/MacOS\/vapor'","Reason: tried: '\/usr\/local\/VAPOR-Deps\/2019-Aug\/lib\/libgeotiff.5.dylib' (no such file), '' (no such file), '' (no such file)"]},
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "faultingThread" : 0,
  "threads" : [{"triggered":true,"id":67958,"threadState":{"x":[{"value":6},{"value":1},{"value":12977461920},{"value":119},{"value":12977460896},{"value":0},{"value":8081015893376835615},{"value":141012705311},{"value":12977460896},{"value":0},{"value":119},{"value":12977461994},{"value":119},{"value":12977461920},{"value":1},{"value":6},{"value":521},{"value":0},{"value":9223372041299966832},{"value":4310499328},{"value":2047},{"value":4445212576},{"value":18446744073709551615},{"value":4310542612},{"value":8604670578,"symbolLocation":80,"symbol":"abort_with_payload_wrapper_internal"},{"value":4310540788},{"value":4310839768},{"value":0},{"value":8604580238,"symbolLocation":10,"symbol":"__abort_with_payload"}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4310842420},"cpsr":{"value":2147487744},"fp":{"value":738197504},"sp":{"value":4445191024},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":4310542656,"matchesCrashFrame":1},"far":{"value":4451221520}},"frames":[{"imageOffset":4310542656,"region":"Rosetta Runtime Routines","symbolLocation":10560,"imageIndex":0},{"imageOffset":4310842420,"region":"<translation info unavailable>","imageIndex":0},{"imageOffset":379506,"symbol":"abort_with_payload_wrapper_internal","symbolLocation":80,"imageIndex":1},{"imageOffset":379556,"symbol":"abort_with_payload","symbolLocation":9,"imageIndex":1},{"imageOffset":42649,"symbol":"dyld4::halt(char const*)","symbolLocation":615,"imageIndex":1},{"imageOffset":26037,"symbol":"dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*)","symbolLocation":3995,"imageIndex":1},{"imageOffset":21732,"symbol":"start","symbolLocation":388,"imageIndex":1}]},{"id":67960,"name":"com.apple.rosetta.exceptionserver","frames":[{"imageOffset":18756,"imageIndex":2},{"imageOffset":74720,"imageIndex":2},{"imageOffset":81496,"imageIndex":2}]}],
  "usedImages" : [
  {
    "size" : 0,
    "source" : "A",
    "base" : 0,
    "uuid" : "00000000-0000-0000-0000-000000000000"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" :<PHONE_NUMBER>,
    "size" : 442368,
    "uuid" : "71febccd-d9dc-3599-9971-2b3407c588a8",
    "path" : "\/usr\/lib\/dyld",
    "name" : "dyld"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>95808,
    "size" : 196608,
    "uuid" : "1f0f0114-cfb6-304b-8183-8ef52c21f8b4",
    "path" : "\/usr\/libexec\/rosetta\/runtime",
    "name" : "runtime"
  }
],
  "sharedCache" : {
  "base" :<PHONE_NUMBER>49472,
  "size" :<PHONE_NUMBER>8,
  "uuid" : "3765e290-e8ae-3af7-92bf-da62dfb8ac4f"
},
  "vmSummary" : "ReadOnly portion of Libraries: Total=5436K resident=0K(0%) swapped_out_or_unallocated=5436K(100%)\nWritable regions: Total=155.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=155.3M(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nRosetta Arena                     4096K        2 \nRosetta Generic                    776K      191 \nRosetta IndirectBranch              32K        1 \nRosetta JIT                      128.0M        1 \nRosetta Return Stack                20K        2 \nRosetta Thread Context              20K        2 \nStack                             8176K        1 \nStack Guard                       56.0M        1 \nVM_ALLOCATE                       13.3M        6 \nVM_ALLOCATE (reserved)              68K        4         reserved VM address space (unallocated)\n__DATA                             372K        9 \n__DATA_CONST                        80K        1 \n__LINKEDIT                        1812K       10 \n__TEXT                            3656K        7 \ndyld private memory               1024K        1 \nmapped file                        6.1G       43 \n===========                     =======  ======= \nTOTAL                              6.3G      282 \nTOTAL, minus reserved VM space     6.3G      282 \n",
  "legacyInfo" : {
  "threadTriggered" : {

  }
},
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "5fc94383418129005b4e9ae0",
      "factorPackIds" : {

      },
      "deploymentId" : 240000486
    },
    {
      "rolloutId" : "60186475825c62000ccf5450",
      "factorPackIds" : {

      },
      "deploymentId" : 240000026
    }
  ],
  "experiments" : [
    {
      "treatmentId" : "5b729754-3882-4560-826f-9c0bc27d77c6",
      "experimentId" : "6192fb082171a2330e561df0",
      "deploymentId" : 400000035
    }
  ]
}
}

Model: MacBookPro18,3, BootROM 7459.141.1, proc 8:6:2 processors, 32 GB, SMC
Graphics: Apple M1 Pro, Apple M1 Pro, Built-In
Display: DELL P2422H, 1920 x 1080 (1080p FHD - Full High Definition), Main, MirrorOff, Online
Display: Color LCD, 3024 x 1964 Retina, MirrorOff, Online
Memory Module: LPDDR5
AirPort: Wi-Fi, wl0: Apr  6 2022 05:55:54 version <IP_ADDRESS>.8.7.118 FWID 01-e7138ff2
Bluetooth: Version (null), 0 services, 0 devices, 0 incoming serial ports
Network Service: USB 10/100/1000 LAN, Ethernet, en7
Network Service: Wi-Fi, AirPort, en0
PCI Card: pci8086,15f0, USB eXtensible Host Controller, Thunderbolt@3,0,0
USB Device: USB31Bus
USB Device: USB31Bus
USB Device: USB31Bus
USB Device: USB31Bus
USB Device: Dell dock
USB Device: USB 10/100/1000 LAN
USB Device: Dell dock
USB Device: Dell dock
USB Device: Dell dock
USB Device: Dell dock
USB Device: Dell dock
USB Device: ThinkPad Compact USB Keyboard with TrackPoint
Thunderbolt Bus: MacBook Pro, Apple Inc.
Thunderbolt Device: WD19TB Thunderbolt Dock, Dell, 1, 60.60
Thunderbolt Bus: MacBook Pro, Apple Inc.
Thunderbolt Bus: MacBook Pro, Apple Inc.

To Reproduce
Steps to reproduce the behavior. For example:

Download VAPOR onto M1 Macbook
Extract dmg
Try to run it
It crashes

Expected behavior
The program should run

@maxiimilian  - I believe I have a fix.  If you have a moment, could you try using this installer on your M1 machine?

Thanks for your work. I just tried it but now a different library cannot be found. Below you can see the (truncated) error report again but the important part seems to be '/usr/local/VAPOR-Deps/2019-Aug/lib/libnetcdf.19.dylib'... Can I help you out somehow?
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               vapor [8409]
Path:                  /Applications/vapor.app/Contents/MacOS/vapor
Identifier:            Vapor3
Version:               3.7.0} (3.7.0.)
Code Type:             X86-64 (Translated)
Parent Process:        launchd [1]
User ID:<PHONE_NUMBER>

Date/Time:             2022-10-14 09:26:54.7316 +0200
OS Version:            macOS 12.6 (21G115)
Report Version:        12
Anonymous UUID:        30694B89-08A6-8650-A190-3B22F8CE8674

Sleep/Wake UUID:       AE729EE5-7391-4ACA-B371-597129733383

Time Awake Since Boot: 18000 seconds
Time Since Wake:       2483 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: '/usr/local/VAPOR-Deps/2019-Aug/lib/libnetcdf.19.dylib'
Referenced from: '/Applications/vapor.app/Contents/MacOS/vapor'
Reason: tried: '/usr/local/VAPOR-Deps/2019-Aug/lib/libnetcdf.19.dylib' (no such file), '' (no such file), '' (no such file)
(terminated at launch; ignore backtrace)

Thread 0 Crashed:
0   Rosetta Runtime Routines	       0x102b97940 ???
1   <translation info unavailable>	       0x102be65e4 ???
2   dyld                          	       0x202b64a72 abort_with_payload_wrapper_internal + 80
3   dyld                          	       0x202b64aa4 abort_with_payload + 9
4   dyld                          	       0x202b12699 dyld4::halt(char const*) + 615
5   dyld                          	       0x202b0e5b5 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3995
6   dyld                          	       0x202b0d4e4 start + 388

Thread 1:: com.apple.rosetta.exceptionserver
0   runtime                       	    0x7ff7ffbe4944 0x7ff7ffbe0000 + 18756
1   runtime                       	    0x7ff7ffbf23e0 0x7ff7ffbe0000 + 74720
2   runtime                       	    0x7ff7ffbf3e58 0x7ff7ffbe0000 + 81496

Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000006   x1: 0x0000000000000001   x2: 0x000000030923ea40   x3: 0x0000000000000077
    x4: 0x000000030923e640   x5: 0x0000000000000000   x6: 0x10258b62d503201f   x7: 0x00000020d503201f
    x8: 0x000000030923e640   x9: 0x0000000000000000  x10: 0x0000000000000077  x11: 0x000000030923ea8a
   x12: 0x0000000000000077  x13: 0x000000030923ea40  x14: 0x0000000000000001  x15: 0x0000000000000006
   x16: 0x0000000000000209  x17: 0x0000000000000000  x18: 0x800000010ac00b70  x19: 0x0000000102b8d000
   x20: 0x00000000000007ff  x21: 0x000000010ac05fa0  x22: 0xffffffffffffffff  x23: 0x0000000102b97914
   x24: 0x0000000202b64a72  x25: 0x0000000102b971f4  x26: 0x0000000102be5b88  x27: 0x0000000000000000
   x28: 0x0000000202b4e98e   fp: 0x000000002c000000   lr: 0x0000000102be65e4
    sp: 0x000000010ac00b70   pc: 0x0000000102b97940 cpsr: 0x80001000
   far: 0x0000000102be6000  esr: 0x56000080  Address size fault

Binary Images:
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
       0x202b08000 -        0x202b73fff dyld (*) <71febccd-d9dc-3599-9971-2b3407c588a8> /usr/lib/dyld
    0x7ff7ffbe0000 -     0x7ff7ffc0ffff runtime (*) <1f0f0114-cfb6-304b-8183-8ef52c21f8b4> /usr/libexec/rosetta/runtime

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=23.5M resident=0K(0%) swapped_out_or_unallocated=23.5M(100%)
Writable regions: Total=155.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=155.5M(100%)

Thanks for you help with this.  Could you try this one?

Awesome!  Thank you again for helping me test this.


docs: filled in some missing info in the docs

@bellini666 I think that addresses all of your comments. How does it seem now?

@hiporox this PR is fine to merge, just need to fix issues with pre-commit.

@bellini666 Fixed the issue that pre-commit had, but it is now error in black for some reason. Not sure what is going on there, but I believe it should be good

@bellini666 Fixed the issue that pre-commit had, but it is now error in black for some reason. Not sure what is going on there, but I believe it should be good

Yeah, there seems to be an issue with pre-commit. I'm going to take a look at it soon.
But thanks for the contribution, looks good now :)


fix the use of end and begin as part of indexing

This is part of a little memory-leak bug which was hard to debug.
Because begin and end had been identified as normal variable names, the use of it inside indexing causes new workspaces to be created.
I guess in normal Pluto this is not so decisive, as anyway a new workspace is created every time, but in my fork I am reusing workspaces where this appeared then.
Maybe it also helps normal Pluto users somehow.

One can use var"begin" anywhere so ideally this behavior should be enabled only inside indexing.
julia> let
           var"begin" = 2
           x = [1,2,3]
           x[var"begin"]
       end
1

So let's add a flag is_inside_index to ScopeState?

@schlichtanders beep boop!

We're so close!

Hi, yes I can make these changes. It is just that I probably will find time around December. As other things are currently quite high in priority.


How is this related to Twelve-Factor?

Honest question from someone learning about 12 factor: the README says:

Bring some 12 factor love to your mobile apps!

But the linked 12 factor page explicitly says to use environment variables instead of config files.

Amazing question!
At first .env may not seem very different than something like config.js. I've seen a lot of RN apps specifying their configs in a js file; that's already pretty good if these files are not checked into version control – although still not perfect since they're language-specific (very relevant for us here considering we want to use the same file to work with Android, iOS and JS).
The other problem with these files is that they they tend to grow ugly as you add more environments.
But I digress – you're right, 12 Factor encourages using the env instead of a config file. It's just that .env is pretty close to the former: it's really just an snapshot of the environment, without it you'd potentially have to type export API_URL=... whenever running your program/script locally.
And what most of the libraries supporting .env do is to really just load that environment into your process. The app then just uses the standard lib to read values from the env, which means they don't depend on the actual .env file, a nice benefit for service-side apps as different platforms have different ways to specify the env.
This is where we depart from other libraries, and from 12 factor itself. We actually don't expose variables in the environment, if anything because with mobiles apps we have the build and the runtime environment, it would be a bit weird to conflate these. And that's fine, the 12 Factor is a set of standard for "applications which run as a service". They're not intended for UI apps, although many concepts are still useful on this level.
Hope this helps! I'll close the issue but happy to clarify anything else/etc.

Ah, thanks for that explanation - now I see where the desire comes from, since in the case of React Native you want to set the variables at build time. I see there's also a way to do this with Babel - something for me to ponder. Cheers!


engine: ensure service events are stopped on app shutdown

AppEngine.stop() signals events to stop,
but needs to actually wait until loops are finished.

closed by #160


Unable to run flutterdemo with frame-it, the window closes immediately after launch

Hello,
I am following the instructions for Packaging a Flutter application (Demo) as an IoT GUI on an x86-64 Ubuntu Desktop 22.04 host and running into an issue when running the snap. I followed the directions exactly:

Cloned the repository
Checked out the Flutter-demo branch
Created the snap using the snapcraft command
Installed the snap
Ran the setup.sh script
Ran the snap with frame-it

A window is briefly displayed on the screen before being closed almost immediately. The output is as follows:
+ [ /snap/ubuntu-frame/8587/bin/run-frame = --help ]
+ mkdir -p /home/<username>/snap/ubuntu-frame/8587/.config/
+ grep -vE (^vt=|^console-provider=vt) /var/snap/ubuntu-frame/8587/frame.config
+ rm -f /home/<username>/snap/ubuntu-frame/8587/.config/frame.display
+ cp /var/snap/ubuntu-frame/8587/frame.display /home/<username>/snap/ubuntu-frame/8587/.config/
cp: cannot stat '/var/snap/ubuntu-frame/8587/frame.display': No such file or directory
+ true
+ exec /snap/ubuntu-frame/8587/bin/run-frame /snap/ubuntu-frame/8587/bin/graphics-core22-wrapper /snap/ubuntu-frame/8587/usr/local/bin/frame
+ [ /snap/ubuntu-frame/8587/bin/graphics-core22-wrapper = --help ]
+ dirname /run/user/1000/snap.ubuntu-frame
+ XDG_RUNTIME_DIR=/run/user/1000
+ export XDG_RUNTIME_DIR
+ mkdir -p /run/user/1000 -m 700
+ [ -n wayland-0 ]
+ [ -e /run/user/1000/wayland-0 ]
+ exec /snap/ubuntu-frame/8587/bin/graphics-core22-wrapper /snap/ubuntu-frame/8587/usr/local/bin/frame
[2024-03-11 11:13:49.499537] <information> mirserver: Starting
[2024-03-11 11:13:49.499591] < - debug - > mirserver: Not trying logind: "DISPLAY" is set and X need not have claimed the VT
[2024-03-11 11:13:49.499625] < - debug - > mirserver: Not using Linux VT subsystem for session management: Failed to find the current VT
[2024-03-11 11:13:49.499632] < - debug - > mirserver: No session management supported
[2024-03-11 11:13:49.499641] <information> VT switch key handler: No VT switching support available: MinimalConsoleServices does not support VT switching
[2024-03-11 11:13:49.499691] <information> mircommon: Loading modules from: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform
[2024-03-11 11:13:49.499707] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-eglstream-kms.so.21
[2024-03-11 11:13:49.499713] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-gbm-kms.so.21
[2024-03-11 11:13:49.499717] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/renderer-egl-generic.so.21
[2024-03-11 11:13:49.499720] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/server-x11.so.21
[2024-03-11 11:13:49.499723] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.8
[2024-03-11 11:13:49.500107] <information> mirserver: Found display driver: mir:eglstream-kms (version 2.16.3)
[2024-03-11 11:13:50.947177] < - debug - > eglstream: Found EGLDeviceEXT with device extensions: EGL_NV_device_cuda EGL_EXT_device_drm EGL_EXT_device_drm_render_node EGL_EXT_device_query_name EGL_EXT_device_persistent_id
[2024-03-11 11:13:50.947368] <information> eglstream: KMS support found, but device has no output hardware.
[2024-03-11 11:13:50.947373] <information> eglstream: This is probably a render-only hybrid graphics device
[2024-03-11 11:13:50.947388] < - debug - > eglstream: Found EGLDeviceEXT with device extensions: EGL_EXT_device_drm EGL_EXT_device_drm_render_node
[2024-03-11 11:13:50.947463] <information> eglstream: Failed to query DRM node for EGLDevice: Failed to acquire DRM master: Operation not permitted
[2024-03-11 11:13:50.947467] < - debug - > eglstream: Found EGLDeviceEXT with device extensions: EGL_EXT_device_drm EGL_EXT_device_drm_render_node
[2024-03-11 11:13:50.947503] <information> eglstream: KMS support found, but device has no output hardware.
[2024-03-11 11:13:50.947505] <information> eglstream: This is probably a render-only hybrid graphics device
[2024-03-11 11:13:50.947511] < - debug - > eglstream: Found EGLDeviceEXT with device extensions: EGL_MESA_device_software EGL_EXT_device_drm_render_node
[2024-03-11 11:13:50.947530] <information> eglstream: Failed to query DRM node for EGLDevice: Failed to determine DRM device node path from EGLDevice: EGL_BAD_PARAMETER (0x300c)
[2024-03-11 11:13:50.947535] <information> mirserver: Driver supports:
[2024-03-11 11:13:50.947539] <information> mirserver: 	/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 (priority 0)
[2024-03-11 11:13:50.947542] <information> mirserver: 	/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 (priority 0)
[2024-03-11 11:13:50.947548] <information> mirserver: Found display driver: mir:gbm-kms (version 2.16.3)
[2024-03-11 11:13:50.948225] < - debug - > gbm-kms: Quirks: checking device with devnode: /dev/dri/card0, driver nvidia
[2024-03-11 11:13:50.948231] <information> gbm-kms: Quirks: skipping device /dev/dri/card0 (matches driver quirk nvidia)
[2024-03-11 11:13:50.948233] <information> gbm-kms: Not probing device /dev/dri/card0 due to specified quirk
[2024-03-11 11:13:50.948272] < - debug - > gbm-kms: Quirks: checking device with devnode: /dev/dri/card1, driver i915
[2024-03-11 11:13:50.948339] <information> gbm-kms: Failed to probe DRM device: ./src/server/console/minimal_console_services.cpp(134): Throw in function virtual std::future<std::unique_ptr<mir::Device> > mir::MinimalConsoleServices::acquire_device(int, int, std::unique_ptr<mir::Device::Observer>)
Dynamic exception type: boost::wrapexcept<std::system_error>
std::exception::what: Failed to acquire DRM master: Operation not permitted

[2024-03-11 11:13:50.948374] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948404] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948433] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948462] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948492] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948526] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948556] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948597] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948627] < - debug - > gbm-kms: Quirks: checking device with devnode: (null), driver
[2024-03-11 11:13:50.948677] <information> mirserver: (Unsupported by system environment)
[2024-03-11 11:13:50.948692] <information> mirserver: Found display driver: mir:egl-generic (version 2.16.3)
[2024-03-11 11:13:50.948717] <information> mirserver: Found display driver: mir:x11 (version 2.16.3)
[2024-03-11 11:13:50.948986] <information> mirserver: Driver supports:
[2024-03-11 11:13:50.948999] <information> mirserver: 	System (priority 192)
[2024-03-11 11:13:50.949015] <information> mirserver: Selected display driver: mir:x11 (version 2.16.3) for platform
[2024-03-11 11:13:50.985533] <information> mircommon: Loading modules from: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform
[2024-03-11 11:13:50.985574] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-eglstream-kms.so.21
[2024-03-11 11:13:50.985582] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-gbm-kms.so.21
[2024-03-11 11:13:50.985586] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/renderer-egl-generic.so.21
[2024-03-11 11:13:50.985589] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/server-x11.so.21
[2024-03-11 11:13:50.985592] <information> mircommon: Loading module: /snap/ubuntu-frame/8587/usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.8
[2024-03-11 11:13:50.986038] <information> mirserver: Found rendering driver: mir:eglstream-kms (version 2.16.3)
[2024-03-11 11:13:50.986047] < - debug - > eglstream: No outputs capable of accepting EGLStream input detected
[2024-03-11 11:13:50.986050] < - debug - > eglstream: Probing will be skipped
[2024-03-11 11:13:50.986052] <information> mirserver: (Unsupported by system environment)
[2024-03-11 11:13:50.986055] <information> mirserver: Found rendering driver: mir:gbm-kms (version 2.16.3)
[2024-03-11 11:13:50.986059] < - debug - > gbm-kms: No outputs capable of accepting GBM input detected
[2024-03-11 11:13:50.986061] < - debug - > gbm-kms: Probing will be skipped
[2024-03-11 11:13:50.986063] <information> mirserver: (Unsupported by system environment)
[2024-03-11 11:13:50.986066] <information> mirserver: Found rendering driver: mir:egl-generic (version 2.16.3)
[2024-03-11 11:13:50.986069] <information> mirserver: Driver supports:
[2024-03-11 11:13:50.986071] <information> mirserver: 	System (priority 192)
[2024-03-11 11:13:50.986074] <information> mirserver: Found rendering driver: mir:x11 (version 2.16.3)
[2024-03-11 11:13:50.986099] <information> mirserver: Selected rendering driver: mir:egl-generic (version 2.16.3) for platform
[2024-03-11 11:13:51.208018] < - debug - > x11-error: Detected 60.00Hz host output refresh rate.
[2024-03-11 11:13:51.208067] < - debug - > miral: Display config using layout strategy: 'default'
[2024-03-11 11:13:51.208099] <information> miral: Display config:
8>< ---------------------------------------------------
layouts:
  default:                         # the current layout
    cards:
    # a list of cards (currently matched by card-id)

    - card-id: 0
      OUT-1:
        # This output supports the following modes<EMAIL_ADDRESS>        #
        # Uncomment the following to enforce the selected configuration.
        # Or amend as desired.
        #
        state: enabled	# {enabled, disabled}, defaults to enabled
        mode<EMAIL_ADDRESS># Defaults to preferred mode
        position: [0, 0]	# Defaults to [0, 0]
        orientation: normal	# {normal, left, right, inverted}, defaults to normal
        scale: 1
        group: 0	# Outputs with the same non-zero value are treated as a single display
8>< ---------------------------------------------------
[2024-03-11 11:13:51.208129] < - debug - > miral: Display config using layout strategy: 'default'
[2024-03-11 11:13:51.208133] <information> miral: Display config:
8>< ---------------------------------------------------
layouts:
  default:                         # the current layout
    cards:
    # a list of cards (currently matched by card-id)

    - card-id: 0
      unknown-1:
        # This output supports the following modes<EMAIL_ADDRESS>        #
        # Uncomment the following to enforce the selected configuration.
        # Or amend as desired.
        #
        state: enabled	# {enabled, disabled}, defaults to enabled
        mode<EMAIL_ADDRESS># Defaults to preferred mode
        position: [0, 0]	# Defaults to [0, 0]
        orientation: normal	# {normal, left, right, inverted}, defaults to normal
        scale: 1
        group: 0	# Outputs with the same non-zero value are treated as a single display
8>< ---------------------------------------------------
[2024-03-11 11:13:51.208187] < - debug - > miral: Wrote display configuration template: /home/<username>/snap/ubuntu-frame/8587/.config/frame.display
xkbcommon: ERROR: couldn't find a Compose file for locale "en_US.UTF-8" (mapped to "en_US.UTF-8")
[2024-03-11 11:13:51.209256] <information> mirserver: Using software cursor
[2024-03-11 11:13:51.209417] <information> gbm-kms-buffer-allocator: Enabled linux-dmabuf import support
[2024-03-11 11:13:51.213138] <information> mirserver: Selected input driver: mir:x11-input (version: 2.16.3)
[2024-03-11 11:13:51.213259] <information> mirserver: Mir version 2.16.3
[2024-03-11 11:13:51.214790] <information> GLRenderer: EGL vendor: Mesa Project
[2024-03-11 11:13:51.214813] <information> GLRenderer: EGL version: 1.5
[2024-03-11 11:13:51.214816] <information> GLRenderer: EGL client APIs: OpenGL OpenGL_ES
[2024-03-11 11:13:51.214824] <information> GLRenderer: EGL extensions: EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_CHROMIUM_sync_control EGL_ANGLE_sync_control_rate EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_EXT_protected_content EGL_EXT_swap_buffers_with_damage EGL_IMG_context_priority EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_MESA_query_driver EGL_NOK_texture_from_pixmap EGL_WL_bind_wayland_display
[2024-03-11 11:13:51.214830] <information> GLRenderer: GL vendor: Intel
[2024-03-11 11:13:51.214833] <information> GLRenderer: GL renderer: Mesa Intel(R) Graphics (RPL-P)
[2024-03-11 11:13:51.214836] <information> GLRenderer: GL version: OpenGL ES 3.2 Mesa 23.0.4-0ubuntu1~22.04.1
[2024-03-11 11:13:51.214838] <information> GLRenderer: GLSL version: OpenGL ES GLSL ES 3.20
[2024-03-11 11:13:51.214864] <information> GLRenderer: GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float GL_EXT_draw_instanced GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture GL_AMD_performance_monitor GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_pack_subimage GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_OES_viewport_array GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean GL_EXT_robustness GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object GL_OES_depth_texture_cube_map GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_debug_label GL_EXT_sRGB_write_control GL_EXT_separate_shader_objects GL_EXT_shader_framebuffer_fetch GL_EXT_shader_group_vote GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix GL_EXT_tessellation_point_size GL_EXT_tessellation_shader GL_INTEL_conservative_rasterization GL_INTEL_performance_query GL_ANDROID_extension_pack_es31a GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_copy_image GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_gpu_shader5 GL_EXT_polygon_offset_clamp GL_EXT_primitive_bounding_box GL_EXT_render_snorm GL_EXT_shader_io_blocks GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_cube_map_array GL_EXT_texture_norm16 GL_EXT_texture_view GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_context_flush_control GL_KHR_robust_buffer_access_behavior GL_NV_image_formats GL_NV_shader_noperspective_interpolation GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_gpu_shader5 GL_OES_primitive_bounding_box GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_io_blocks GL_OES_shader_multisample_interpolation GL_OES_tessellation_point_size GL_OES_tessellation_shader GL_OES_texture_border_clamp GL_OES_texture_buffer GL_OES_texture_cube_map_array GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_OES_texture_view GL_EXT_blend_func_extended GL_EXT_buffer_storage GL_EXT_float_blend GL_EXT_geometry_point_size GL_EXT_geometry_shader GL_EXT_shader_samples_identical GL_EXT_texture_sRGB_R8 GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_NV_fragment_shader_interlock GL_OES_EGL_image_external_essl3 GL_OES_geometry_point_size GL_OES_geometry_shader GL_OES_shader_image_atomic GL_EXT_clear_texture GL_EXT_clip_cull_distance GL_EXT_disjoint_timer_query GL_EXT_texture_compression_s3tc_srgb GL_MESA_shader_integer_functions GL_EXT_clip_control GL_EXT_color_buffer_half_float GL_EXT_memory_object GL_EXT_memory_object_fd GL_EXT_semaphore GL_EXT_semaphore_fd GL_EXT_texture_compression_bptc GL_EXT_texture_mirror_clamp_to_edge GL_KHR_parallel_shader_compile GL_NV_alpha_to_coverage_dither_control GL_EXT_EGL_image_storage GL_EXT_shader_framebuffer_fetch_non_coherent GL_EXT_texture_shadow_lod GL_INTEL_blackhole_render GL_MESA_framebuffer_flip_y GL_NV_compute_shader_derivatives GL_EXT_demote_to_helper_invocation GL_EXT_depth_clamp GL_EXT_texture_query_lod GL_MESA_bgra
[2024-03-11 11:13:51.214881] <information> GLRenderer: GL max texture size = 16384
[2024-03-11 11:13:51.216342] <information> GLRenderer: GL framebuffer bits: RGBA=8888, depth=0, stencil=0
[2024-03-11 11:13:51.218577] <information> mirserver: Initial display configuration:
[2024-03-11 11:13:51.218602] <information> mirserver: * Output 1: unknown connected, used
[2024-03-11 11:13:51.218606] <information> mirserver: . |_ Physical size 17.0" 338x270mm
[2024-03-11 11:13:51.218609] <information> mirserver: . |_ Power is on
[2024-03-11 11:13:51.218611] <information> mirserver: . |_ Current mode 1280x1024 60.00Hz
[2024-03-11 11:13:51.218614] <information> mirserver: . |_ Preferred mode 1280x1024 60.00Hz
[2024-03-11 11:13:51.218616] <information> mirserver: . |_ Orientation normal
[2024-03-11 11:13:51.218619] <information> mirserver: . |_ Logical size 1280x1024
[2024-03-11 11:13:51.218621] <information> mirserver: . |_ Logical position +0+0
[2024-03-11 11:13:51.218623] <information> mirserver: . |_ Scaling factor: 1.00
[2024-03-11 11:13:51.218639] < -warning- > miral: Attempt to read custom output attribute (surface-title) that wasn't added
[2024-03-11 11:13:51.218647] < -warning- > miral: Attempt to read custom output attribute (snap-name) that wasn't added
[2024-03-11 11:13:51.594563] <information> frame: New surface for snap="iot-example-graphical-snap" with title="flutterdemo"
error in client communication (pid 29782)
Gdk-Message: 11:13:51.651: Error flushing display: Protocol error
[2024-03-11 11:13:51.682583] < - debug - > mirserver: Handling Terminated from pid=29668
[2024-03-11 11:13:51.682760] < -warning- > mirserver: wl_surface@12 destroyed before associated role

I have no issue when I run a snap created from another branch, such as the mastermind game.

Checked out the Flutter-demo branch

HI @resilem, to help me try replicating the problem, would you confirm whether you mean 22/Flutter-demo or 20/Flutter-demo?

I've just followed the same instructions and they work on 22.04 and 24.04. So there must be some other difference in our environments.
Are you running a Wayland based DE such as GNOME? If so, could you try running iot-example-graphical-snap without frame-it?

I am running GNOME DE.

Setting up watches.
Watches established.

:(
That suggests GNOME is running in X11 mode. (BTW I said iot-example-graphical-snap, not snap run iot-example-graphical-snap, but that shouldn't make a difference)
Are you, perhaps, using Nvidia graphics?


rename every instance of "stable" to "legacy"

to the best of my knowledge this is only done on instances of the entire word, matching case sensitivity
I'm not sure if/how this would break non-English languages, feedback on that is welcome

The intention is to change stables to releases in the future, but that is indefinitely stalled out so this is a good option to clear up confusion in the meantime.
BTW you probably should also change the stable track in the updater to legacy too. Or do that in a different PR if you want to separate them out?

How is localization handled on the website? I know for the main emulator it is handled by Transifex and you're not supposed to change the strings in the po files manually. Not sure if it's the same here.

The intention is to change stables to releases in the future, but that is indefinitely stalled out so this is a good option to clear up confusion in the meantime.
BTW you probably should also change the stable track in the updater to legacy too. Will you be doing that in a separate PR?

I can look into that when I get some time, although I'm thinking that might take more work than a "replace all" in VS Code...

Does anyone know how is localization handled on the website? I know for the main emulator it is handled by Transifex and you're not supposed to change the strings in the po files manually. Not sure if it's the same here.

I believe it's the same here. However, the process of syncing the strings with Transifex has been handled by delroth instead of by me.

FYI, Stable was already removed from the updater in https://github.com/dolphin-emu/dolphin/pull/11457.

FYI, Stable was already removed from the updater in dolphin-emu/dolphin#11457.

Oh, I forgot about that. Nevermind then!

@JosJuice Are you able to handle a Transifex sync for this repo too? I assume this will be the same process, though I have no experience with Transifex.

Are you able to handle a Transifex sync for this repo too? I assume this will be the same process, though I have no experience with Transifex.

The exact process would be a little different since this is a different code base in a different programming language, , but I will try to look into it when I get time. It's probably not too complicated.

Superseded by #152.


Thellier GUI should save fits

Thellier GUI should save a fit when you click "next" as Demag GUI does

Also, once this is fixed, the Cookbook instructions should be updated.

@ronshaar, @ltauxe, here's my proposed change:
when "next" is clicked, save whatever interpretation is currently selected.  This prevents the annoying situation where you set bounds and click next for 10 or 15 specimens and then realize that none of those have been preserved since you didn't click save. If you delete a fit, it won't be saved.
This is how it works in Demag GUI, and seems fairly intuitive.  The only issue I see is this: if you select temperature bounds, then save a fit, then change the temperature bounds, and then click next, what should happen?  Should the "saved" fit override the last fit?
Intuitively, I prefer letting the last selected bounds be saved when you click "next".  If you agree, I will implement this.


Issue with matcher in Excercise 1.12.2

The following line of code and the instructions for this exercise may be wrong. As seen in the attached screenshot the target words are tagged as "INTJ"
https://github.com/ines/spacy-course/blob/90feb4983573db71163ffda56d8fea78a02d747f/exercises/es/solution_01_12_02.py#L15

IMO, the idea was to match proper nouns and the example could be fine, meaning the issue is on the Spacy POS tagger. I may be missing something, so certainly, someone can determine if the POS tagger needs to be fixed or the example updated.
Regards
-Gon

Hummm, I tryed several sentences like:

el juego se llama Fornite

But I get:
el          DET       det        juego       NOUN      nsubj      se          PRON      obj        llama       VERB      ROOT       Fornite     INTJ      obj
Even if I try with different known names like: Minecraft, Quake, ... I can not get the PROPN, always I get the INTJ. I also tryed another kind of simple sentences with software or videogames names and get the same result.

la empresa se llama Apple

la          DET       det empresa     NOUN      nsubj      se          PRON      obj        llama       VERB      ROOT       Apple       INTJ      obj

El jefe se llama Antonio

El          DET       det        jefe        NOUN      nsubj      se          PRON      obj        llama       VERB      ROOT       Antonio     INTJ      obj
I think this could be important to check.


Re-frame hangs in Safari 9.1

I recently upgraded re-frame from 0.4.1 to 0.6.0 and it worked great in chrome and firefox but would just hang when dispatching in Safari 9.1. I also tried both 0.5.0 and 0.7.0-alpha which resulted in the same hanging behavior in Safari.
on page load, this is dispatched:
;; core.cljs
(dispatch [:initialize-db])
----------------------------------
;; handlers.cljs
;; GET is from the cljs-ajax library
(defn initialize-db [db _]
  (GET "/init"
    {:handler #(dispatch [:process-initialize-db %1])
     :error-handler #(dispatch [:error-initialize-db %1])}) db)

Safari would show the init xhr request in the network tab but would just hang; continuously loading. No js errors or warnings were thrown. Also, my server was never hit with the init GET request.
Other dependencies in my project:
     [org.clojure/clojure "1.8.0-RC1"]
     [org.clojure/clojurescript "1.7.170"]
     [org.clojure/core.async "0.2.374"]
     [org.clojure/test.check "0.9.0"]
     [secretary "1.2.3"]
     [reagent "0.5.1"]
     [cljs-ajax "0.5.3"]
     [prismatic/dommy "1.1.0"]
     [prismatic/schema "1.0.4"]
     [com.cognitect/transit-cljs "0.8.237"]
     [org.clojars.stephen-charles/re-com "0.5.7"]]
   :plugins [[lein-cljsbuild "1.1.2"]
            [lein-ancient "0.6.8"]
            [lein-figwheel "0.5.0-2"]]

Hi @StephenCharles, can you reproduce this issue with the example re-frame project? It kinda looks like an issue with the XHR request, not re-frame?

I'll look into it. May take a bit of time as I have to annoy some friends to test it in Safari for me.

FWIW, I've done a fair amount of work with re-frame in Safari. I vaguely remember some bugs that were timing related that didn't show up in Chrome. The gist of it was that I was trying to call handlers that hadn't been created yet because I was evaluating forms in the namespace directly, rather than calling functions once I knew the handlers were set up. Not sure if that applies to you here, but maybe experiment with calling (dispatch [:initialize-db]) after the page is loaded just to start tracking down the source of the problem?

Just tested the example app and it works fine with cljs-ajax in Safari.
This error was reproduce-able in my original application (by changing the re-frame version) but my application has a lot more dependencies and external javascripts. See dependencies above and below are the external javascripts:
/* v 1.0.2 */ Chart.min.js
/* v 2.10.3 */ moment.min.js
/* v 1.4.4 */ rollbar.min.js
/* v 1.1.1 */ faye.js
/* v 15-01-2016 */ https://js.stripe.com/v2/
/* v 1.11.2 */ jquery
/* v 2135554 */ https://connect.facebook.net/en_US/fbevents.js
/* v 4.0.3 of the jquery-rails ruby gem*/
https://github.com/rails/jquery-rails/blob/ff93f91b279a760472e459e8e4ad6cdf1cc5bcf4/vendor/assets/javascripts/jquery_ujs.js

I'll close this issue for now until I can better understand what is happening. I also wanted to see if this was happening to anyone else. Otherwise it may just be an application error on my end.

Sorry, I didn't read your first report carefully enough, which versions of re-frame does your app work and not work with when using Safari?

It works with 0.4.1 and below. 0.5.0, 0.6.0, and 0.7.0-alpha do not work.
Were these timing errors occurring before 0.5.0? And what exactly would happen?

In v0.5, we re-implemented the router loop (the code that queues and processes events when they have been dispatched), dropping the previous loop which was based on core.async:
https://github.com/Day8/re-frame/blob/master/CHANGES.md#050--2015-11-5
One implication of the new router loop is that there's less of a delay between when a dispatch happens and when the associated event-handlers is run.  Prior to v0.5 there would have been at least a 5ms delay (from dispatch to event-handler), but with 0.5 that might shrink to < 1ms.

OO interesting. Well maybe other event-handlers are being processed as well?
here is the full context of what is being run on page load:
;; core.cljs
(defn ^:export main
   (re-frame/dispatch [:initialize-db])
   ;; this method will dispatch a handler for a given pathname
   (secretary/dispatch! (.-location.pathname js/window)))

--------------------------------------------
;; handlers.cljs
;; as far as I can tell, it never makes it to process-initialize-db or error-initialize-db because
;; the GET request never finishes
(defn initialize-db [db _]
  (GET "/init"
    {:handler #(dispatch [:process-initialize-db %1])
     :error-handler #(dispatch [:error-initialize-db %1])}) db)

;;; an example of a handler for a given pathname
;;; that would be dispatched from secretary/dispatch!
(defn view-dashboard-activity [db _]
  (let [dashboard (get-in db [:data :dashboard])]
    (when (nil? dashboard)
      (dispatch [:all-dashboard-loading true])  ;; this handler just updates a key in the db
      (dispatch [:initialize-dashboard])) ;; this will make a GET request similar to initialize-db (which is never made according to the Safari network tab)
    (assoc-in db [:view :current-route] r/dashboard-activity-route)))

I'm sorry I can't provide more information. Currently the only access I have to Safari is through a friend who lives 3000 miles away. In a week or so I'll be able to explore this more thoroughly.

I half suspect you've got a race-condition somewhere. The previous router masked the problem because it processed events much more slowly (more time in between event handlers getting called).
Having said that, I'm not sure why it would only happen on Safari OR why it would manifest as a weird hang.
As an experiment, what happens if  you cheat and use (re-frame/dispatch-sync [:initialize-db])?
Ultimately, I suspect you'll have to debug via this kind of method, to "see" what is happening:
https://github.com/Day8/re-frame/wiki/Debugging

@StephenCharles I was wondering if you got to the bottom of this?   We okay to close this?

I haven't had a chance to do any further debugging. At the moment I don't have easy access to a machine with Safari on it. I'm hoping to borrow someone's machine in a week or so.

@StephenCharles it appears that you connect your re-frame app to a Rails backend. Is that correct? If so, could we talk about how you do it? I'm in the process of developing a Ruby Gem that makes connecting re-frame and Rails easier: https://github.com/jhund/re-frame-on-rails

@StephenCharles by the way, I'm on Mac OS and could help with testing on Safari.

After looking over the wiki about best practices, I realized I was using subscriptions in many of my handlers. I'm not sure if this will fix the problem, but it is worth a shot.
@jhund yeah I use re-frame with rails, I'll open an issue on your repo and we can chat about it there. Thanks for the offer but it's looking like this is probably specific to my application and so I'll be bugging my co-worker about debugging it with me.

Ok it seems it was an application on my part. I removed all the subscriptions from my handlers, and newest re-frame 0.7.0-alpha-2 works great in Safari 9.1 and 9.0.3. I'll be sure to familiarize myself with the wiki more often :)


Can't install on windows 10 32bit

this log
SquirrelSetup.zip

https://github.com/atom/atom/issues/5889

Thanks for reaching out!
Even though some information may not apply, we require the template to be filled out as much as possible on all new issues and pull requests so if you can open a new issue with the template filled out, that would be helpful for us. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us half way :grinning:


Scroll styling

moves text from frames to html
reorganizes placement of items so text can scroll by on left
adds a references section

Please change out text to: (I couldn't edit it here, since it's not changes made in the PR?
frames: [
{
id: 'a',
text: 'A hydrological drought means that streamflow is abnormally low.'
},
{
id: 'b',
text: 'Here, "abnormally low" is set as a threshold'
},
{
id: 'c',
text: 'Periods of severe drought happen whenever daily streamflow is below the threshold.'
},
{
id: 'd',
text: 'You might be wondering, what happens if there is an abnormally dry spring when we expect more rain?'
},
{
id: 'e',
text: 'Well, then we need to determine periods when rainfall is abnormally low for a specific week'
},
{
id: 'f',
text: 'And let our threshold change week to week'
},
{
id: 'g',
text: 'Now we capture droughts when streamflow is abnormally low for a given week.'
},
{
id: 'h',
text: 'This variable threshold changes the timing and number of droughts.'
}
]

done


Missing Semester

As per quarter it will be nice to have the same for semester (1 or 2).
Regards.

In France, we divide the year in two semester S1 (january to june) and S2 (july to dec) and when I suggest to add this format I didn't figure it can't be differently. But after some research it seems that each country has his own way to group 6 months. so my change request is not relevant and I'm sorry for the noise.


we do a little trolling :trollface:

100 prs, almost 3 years of development. AND YOU MAKE PR 100 JUST TO FIX A SINGLE LETTER TYPO

this was the part that people where going to talk about after my death how amazing novacore pr 100 was

but no

JUST A SINGLE LETTER

UGGHHHHHHHHHH!


RuntimeError:All supplied parameter names or regex patterns not found

when i use
--cfg models/yolov5s.yaml
--weights zoo:cv/detection/yolov5-s/pytorch/ultralytics/coco/pruned_quant-aggressive_94?recipe_type=transfer
--hyp data/hyps/hyp.finetune.yaml
--recipe zoo:cv/detection/yolov5-s/pytorch/ultralytics/coco/pruned-aggressive_96
i found this error, if this recipe cannot support the yolov5_v6.0 models? Thanks!

Hi @JimmyW-11, the existing recipes were developed for yolov5 (original) and only support that architecture at the moment. Our research team is actively working on new recipes for yolov5_v6 which we hope to release within the next couple of months.
Note that the primary reason the recipes are incompatible is because the recipes targets specific layers to be pruned to a certain %. You can get around this by manually setting the layers you want pruned in the recipe or simply using the keyword _ALL_PRUNABLE__ for the params field to prune all layers. You can attain reasonable, but not quite SOTA results this way.


java.lang.OutOfMemoryError: unable to create new native thread

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method) ~[?:1.8.0_91]
at java.lang.Thread.start(Thread.java:714) ~[?:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950) ~[?:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1357) ~[?:1.8.0_91]
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) ~[?:1.8.0_91]
at org.xbib.pipeline.SimplePipelineExecutor.execute(SimplePipelineExecutor.java:105) ~[elasticsearch-jdbc-<IP_ADDRESS>.jar:?]
at org.xbib.pipeline.MetricSimplePipelineExecutor.execute(MetricSimplePipelineExecutor.java:52) ~[elasticsearch-jdbc-<IP_ADDRESS>.jar:?]
at org.xbib.tools.JDBCImporter.execute(JDBCImporter.java:237) ~[elasticsearch-jdbc-<IP_ADDRESS>.jar:?]
at org.xbib.tools.JDBCImporter.run(JDBCImporter.java:146) [elasticsearch-jdbc-<IP_ADDRESS>.jar:?]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_91]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_91]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_91]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_91]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_91]

Thread
[root@VM-172-31-105-120 ~]#pstree -p 18825|wc -l
84
[root@VM-172-31-105-120 ~]#pstree -p 18825|wc -l
84
[root@VM-172-31-105-120 ~]#pstree -p 18825|wc -l
86
[root@VM-172-31-105-120 ~]#pstree -p 18825|wc -l
86
[root@VM-172-31-105-120 ~]#pstree -p 18825|wc -l
88
[root@VM-172-31-105-120 ~]#pstree -p 18825|wc -l
96
[root@VM-172-31-105-120 ~]#pstree -p 18825|wc -l
110
[root@VM-172-31-105-120 ~]#pstree -p 18825|wc -l
118
the thread  continued  increase ，final java.lang.OutOfMemoryError: unable to create new native thread。
this is my jdbc.config-->
"user" : "order",
"password" : "order",
"schedule": "*/3 * * * * ?",
"threadpoolsize":1,
"metrics" : {
"enabled" : true
},

i meet this problem too

me too, how to resolve this?

can anyone help?

me too, how to resolve this?

I'm guessing these issues where never resolved but like the people before me, I shall ask too. Is there any fix for this? I have the exact same issue. I can watch the memory usage going up and up until it uses all the server memory. I've tried setting Java Heap variables etc and this does not help, I've increased the schedule interval and this also does not help. This is using V <IP_ADDRESS>

facing Same issue as above

I didn't ever find an actual fix for the memory leak. I just restart the river every hour using a cron job which allows the memory to be released.

Commit https://github.com/jprante/elasticsearch-jdbc/commit/ee7ec72d92fa2ee5da9356c86201fa8b54d8a481 fixes the issue.

hi jprante
I use the 'Commit ee7ec72 fixes the issue' code in script .
but when script runnng once,the thread +1. use  ' pstree -p 32063 |wc -l '
one times plus 1 , a few days later , this issue will reappeared


Daily update for docs.docker.com

Proposed changes
Daily update for November 19, 2019

Deploy preview for docsdocker ready!
Built with commit dcc29a413f8cc6c14fc6028d9b374b23a71a98dc
https://deploy-preview-9910--docsdocker.netlify.com


[Bug]-[1000]:Table data export to Excel displays column header as 0 whenever the column data type is Number

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Whenever we have a table that has a column declared as Number, when this table is exported as Excel, the header to end column declared as Number is exported as Zero.
[image/png] : https://cdn.discordapp.com/attachments/1080269931075076166/1080269931679068180/image.png
[image/png] : https://cdn.discordapp.com/attachments/1080269931075076166/1080269931913941082/image.png
[image/png] : https://cdn.discordapp.com/attachments/1080269931075076166/1080269932136235099/image.png
[image/png] : https://cdn.discordapp.com/attachments/1080269931075076166/1080269932425654352/image.png
Steps To Reproduce

Create a table widget and populate with data that has a column whose data type is set to Number.
Export the table as Excel

Public Sample App
No response
Environment
Deploy Preview
Issue video log
No response
Version
Cloud / Self Hosted  1.9.7
 Front conversations

Stats

Stat
Values

Reach
1000

Effort (months)
0.5

This seems to be working


refactor: add agent test

Agent Test File
Description
This PR includes a simple test for the Daytona Agent. Additionally, it introduces a new convention for writing tests into this repo.

Mocks (implemented with testify) should be used to Unit test complex services (such as the Agent)
Mocks should be implemented in the internal/testing/PACKAGE_NAME/mocks package.

Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[x] Tests

Checklist

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

In draft until we merge the gitprovider refactor.


ParquetCachedBatchSerializer's performance on partitioned dataframe is worse than a single partitioned dataframe

There is a sizeable difference in performance when caching RDD on a single partition compared to a distributed run.
Consider the following Dataframe with 50,000 rows and a single column with 2048 elements in each array
scala> dataDf.printSchema
root
 |-- feature: array (nullable = false)
 |    |-- element: double (containsNull = true)

When we write it out to cache and read back the count, the times are as follows with and without repartitioning it to a single partition.
scala> spark.time(dataDf.cache.count)
Time taken: 37003 ms
res4: Long = 50000

scala> spark.catalog.clearCache

scala> spark.time(dataDf.repartition(1).cache.count)
Time taken: 15361 ms
res6: Long = 50000

When we do a rough benchmarking, the times (just for writing cache) are as follows for each of the runs

12 partitions run (ms)
Single partition (ms)

1799

1741

1751

1753

1754

1753

1753

1753

1751

1762

1764

1765

21099
2471

As apparent each of the partitioned parquet files written by the ParquetCachedBatchSeriazlier are small and collectively take a long time while the file written by single partition is large (amalgamation of all the partitioned files) and is much faster to write.
I am not sure if there is a way to get around this problem as this is a known problem that GPU favors crunching large data over smaller ones
This script was used to generate the above data

This looks like classic sub-linear scaling of the GPU. You give it 12 times as much data and it only got 40% slower to do it. From my calculations it looks like we are decoding about 781 MiB of data.  That is small enough to fit into a single columnar batch. I think this is works as expected.  But if you want to take some traces or see if this still happens with more data that would be interesting.

The table size I am not sure of but the encoded in-memory parquet file was in fact 781MiB as you calculated.

Can/Should the RapidsPlugin be intelligent about noticing this and essentially add the repartition(1) to the DF before caching it? Would that mean the cache is not going to be "distributed" anymore to the other nodes?

I don't think it can be intelligent about it. Users can be smart about it and if we update the docs it could be helpful to an end user. This is because moving all of the data to fewer hosts is not going to be free. If we knew the size of the data, network speed and compression speed for the shuffle we might be able to guess at a good number of workers to repartition the data to in order to optimize read speeds, but we don't know the size, we don't know how many times the data is going to be read vs written so we would have to assume worst case that it is read only once, and even if we did we did know all of that we would be doing something the user didn't ask us to do, so we would not want it to be a default operation.  Perhaps the user knows that they are going to do some heavy computation with the data and split it up on purpose to make the load more even, and we just go and undo it for them.

Writing a small file in multiple partitions will be slower than writing that file in a single partition on a GPU as explained above


Re-enable like operator

Issue #, if available:
Resolves #185
Description of changes:
Now that the Lean implementation of wildcard matching has been fixed (#213), we can re-enable the like operator in our generators.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Note: I'm currently running the eval-type-directed-lean target locally to confirm that it doesn't generate inputs that time out. Will wait to merge this PR (regardless of approvals) until it has run for 12 hours or so.

DRT ran successfully for ~20 hours locally, so merging this.


Wording suggestion: “Consider fixing” instead of “Consider to fix”

I’m not a native speaker, but I’m pretty sure that “Consider fixing” sounds more natural than “Consider to fix”. The latter just doesn’t sound right to me.

Thank you @simevidas for the feedback!


Publish mondrian-charts and @fiberplane/fiberplane-charts

Description
This sets up mondrian-charts for publication to Crates.io and @fiberplane/fiberplane-charts and @fiberplane/prometheus-query for publication to NPM.
The main changes are a lot of documentation added and the removal of the dist folder from fiberplane-charts. We will have to see if the latter really makes for a more pleasant dev experience (I know nobody likes regenerating the dist folder, but requiring releases before we can use new features downstream might be even worse?).
Also contains some smaller tweaks and a bit of API streamlining that I ran into as I was documenting things. This also introduces a few backwards incompatibilities again, but fortunately nobody depends yet on the Rust crate, and for the TypeScript package it was inevitable due to the name change (added the @fiberplane namespace).
Checklist

:warning: The changes are not backwards compatible.
[ ] The OpenAPI schema and generated client have been updated.
[ ] New models module has been added to api generator xtask
[x] New types/fields are well-documented and annotated.
[ ] The CHANGELOG is updated.

Please link any related PRs in other repositories that depend on this:

After merging, please merge related PRs ASAP, so others don't get blocked.

regarding the local dev experience for charts:
it'd be good to document how we expect people to develop locally, because we're still going to be doing that quite a bit.
i think it'd still be possible to generate a build of the charts and link to it locally, which is how i've been doing things anyhow most of the time. that said, it is a lot of steps:

run yarn build in fiberplane-charts
run yarn pack --out charts-zzz.tgz
modify package.json in e.g., dora to point fiberplane-charts to the charts-zzz.tgz file

maybe there's a way to make this more seamless? like a script that wraps up all three steps?


ARROW-5258: [C++/Python] Collect file metadata of dataset pieces

This PR supersedes PR #4166 and provides

[x] file metadata API (C++)
[x] ParquetWriter metadata property, only available after calling close method (Python)
[x] FileMetaData to_dict method for collecting file metadata information to a dictionary (Python)
[x] support for metadata_collector kw argument to ParquetWriter and write_to_dataset for collecting the file metadata instances of dataset pieces.
[x] unit-test

@wesm , please review.

@mrocklin, @martindurant, could you also review this pull request for ARROW-1983? In particular, I have the following questions (cc: @wesm ):

The write_to_dataset interface for collecting file metadata instances of a dataset is exemplified in test_dataset_metadata. Would this be an approach that would be suitable for dask?
After collecting all file metadata of dataset pieces (possibly from different dask processes), what would be desired the interface for writing and reading the dataset metadata instances? Here's an initial proposal for Python:

def write_dataset_metadata(metadata_list, where):
    ...

def read_dataset_metadata(where, memory_map=False):
    ...
    return metadata_list

Clearly, each file metadata instance in metadata_list contains same information as in all metadata instances. Would it make sense and use to introduce a new DatasetMetadata class (in C++, also exposed to Python) that would collect the metadata information of dataset pieces in a more compact way as well as would provide I/O methods? (This also addresses the question 2.)

@pearu what do you think about having write_to_dataset append the actual FileMetaData objects instead of converting them to a dict? Then we can punt the file writing until a follow up patch

@wesm, the metadata_list contains the actual FileMetaData objects. The to_dict was introduced for convenience of tests as well as quickly viewing the information in FileMetaData objects.

Got it, thanks. Can you rebase to trigger a new build (to make sure the appveyor failure was a flake)? I'm OK to merge this with a new JIRA id (since the writing of the _metadata file will have to be addressed separately)

OK, I'll trigger the new build by getting rid of file_metadata_.reset(); statements (that are not really needed with the current control flow).

Thanks for your work on this @pearu and @wesm !
I am trying to help @mrocklin improve the dask/parquet interface.  To this end, I put together a simple notebook to explore how pyarrow.parquet can/should be used to read/write a partitioned dataset without dask (see: https://github.com/rjzamora/notebooks/blob/master/pandas_pyarrow_simple.ipynb).
In the current implementation, is there a way to read/write a single metadata file for a partitioned dataset? I assume that this would be the _metadata file?
If your search for "Assuming that a single-file metadata solution is currently missing" in the notebook I referenced, you will see where I am unsure of the best way to write/read metadata to/from a centralized location using pyarrow.parquet.  Let me know if you have any recommendations :)

Can you write to one of the Arrow mailing lists about this?

@rjzamora the writing functionality of combined metadata is indeed still missing, as you correctly stated. See https://issues.apache.org/jira/browse/ARROW-1983 for that. And I also just opened https://issues.apache.org/jira/browse/ARROW-5349 for the file path of metadata (another piece of the puzzle to get this dataset metadata working, I think).
But it would still be good to have a mailing list discussion about I think, to get a better picture of the functionalities that are still needed here.

Thanks for pointing me to Arrow-5349 @jorisvandenbossche! I do think it's probably an important piece of the puzzle.
Also, I just posted my question to the mailing list - Thanks!


Provider for Mexico

Creating the provider for Mexico is not too difficult except for the holidays that are adjusted to the closest monday.

Thanks! Is this issue just a request or are you planning on contributing the provider for Mexico?
Having holidays that are observed to the next Monday in case a national holiday is not difficult. You can see the code of other holiday providers how it is done.
Cheers! Sacha

I will try to make the contribution and create the pull request.

@gogl92 Cool! Let me know if you have any questions. Best is to use one of the existing countries as a starting point. FIY, your PR needs to be made against the develop branch :)
Cheers! Sacha

@gogl92 Wanted to check if you have made any progress with the Mexico provider. If not and you don’t have any time, I can take it over if you like


Encoding problems

In the file ref_lexicons/vader_words there are some emoticons that have encoding problems:
For example: :-Þ
What encoding is this file in?
cc: @cjhutto

I thought everything was in uft-8.

I get an error with file.readlines()
Traceback (most recent call last):
  File "reflists.py", line 21, in <module>
    print(json.dumps(wordsets, indent=2))
  File "/usr/local/lib/python2.7/json/__init__.py", line 251, in dumps
    sort_keys=sort_keys, **kw).encode(obj)
  File "/usr/local/lib/python2.7/json/encoder.py", line 209, in encode
    chunks = list(chunks)
  File "/usr/local/lib/python2.7/json/encoder.py", line 434, in _iterencode
    for chunk in _iterencode_dict(o, _current_indent_level):
  File "/usr/local/lib/python2.7/json/encoder.py", line 408, in _iterencode_dict
    for chunk in chunks:
  File "/usr/local/lib/python2.7/json/encoder.py", line 313, in _iterencode_list
    yield buf + _encoder(value)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xde in position 2: invalid continuation byte

It is latin-1....  😡

this is how you fix it. iconv -f ISO8859-1 -t UTF8

corrected in latest pull, yes? we can close this issue, I think @jpfairbanks , @scottagt

If its been fixed / committed then sounds good


Error: deploying: us-east-1: The following resource(s) failed to create: [Api].

I am trying to deploy a "sample" node.js app from the documentation, but am getting strange errors. I'm using this up.json:
{
  "name": "up-test",
  "profile": "up_test_user",
  "regions": [ "us-east-1" ]
}

I've given the up_test_user the following permissions (after some guessing and a lot of trail/error):
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "cloudformation:CreateStack",
        "cloudformation:DeleteStack",
        "cloudformation:DescribeStackEvents",
        "cloudformation:DescribeStacks",
        "cloudwatch:GetMetricStatistics",
        "iam:AttachRolePolicy",
        "iam:CreatePolicy",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:DeleteRolePolicy",
        "iam:PassRole",
        "iam:PutRolePolicy",
        "lambda:CreateAlias",
        "lambda:CreateFunction",
        "lambda:DeleteFunction",
        "lambda:GetAlias",
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration",
        "lambda:InvokeFunction",
        "lambda:ListAliases",
        "lambda:ListFunctions",
        "lambda:ListVersionsByFunction",
        "lambda:UpdateAlias",
        "lambda:UpdateFunctionCode",
        "lambda:UpdateFunctionConfiguration",
        "logs:FilterLogEvents"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

But am yielding this error:
  Error: deploying: us-east-1: The following resource(s) failed to create: [Api].

Any ideas?

Found a few more permissions missing, I'll go through and QA everything with the policy.

Yeah, more digging makes this look like a permissions error. I'll update this ticket if/when I figure out what I'm missing.

I just pushed an updated policy. I think being a bit more liberal with it might make more sense, could get realllll annoying asking people to update their policies frequently, especially for read access.

I think that's everything, closing for now but I'll continue using this policy instead of root like a good dev :D

Awesome, thanks dude! I'll try this out shortly.

@tj I'm having this and others failed to create problems.
I'm using external registrars
Console:

Policy:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "route53:*",
                "route53domains:*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "acm:*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "cloudfront:*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "cloudformation:Create*",
                "cloudformation:Update*",
                "cloudformation:Delete*",
                "cloudformation:Describe*",
                "cloudformation:ExecuteChangeSet"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "iam:AttachRolePolicy",
                "iam:CreatePolicy",
                "iam:CreateRole",
                "iam:DeleteRole",
                "iam:DeleteRolePolicy",
                "iam:GetRole",
                "iam:PassRole",
                "iam:PutRolePolicy"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "lambda:Create*",
                "lambda:Delete*",
                "lambda:Get*",
                "lambda:List*",
                "lambda:Update*",
                "lambda:AddPermission",
                "lambda:RemovePermission",
                "lambda:InvokeFunction"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "logs:Create*",
                "logs:Put*",
                "logs:Test*",
                "logs:Describe*",
                "logs:FilterLogEvents"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:Get*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "apigateway:*"
            ],
            "Resource": [
                "arn:aws:apigateway:*::/*"
            ]
        }
    ]
}

@guilhermedecampo ah those errors suck hahah, I need to improve that, it's on my list. If you visit /cloudformation in the AWS console it should show some more info for your stack and why it failed, might be easier for me to suggest something


update readme

a misspell

Thanks for the pr -- I have actually already changed this for the next push so I'll be sure to correct it then. Thanks!