Tracking Non-Virus Covid19 Lockdown Deaths

Is your feature request related to a problem? Please describe.
India have an increasing death rate linked to Covid19 Lockdown measures. This is peculiar comparing to other countries in the world.
Describe the solution you'd like
Please integrate API from
http://projects.datameet.org/covid19/non-virus-deaths/

API details if anyone is interested. You can cache it on your server as it changes only once a day.
https://twitter.com/thej/status/1244342448664371200

From a public health perspective, it is important to contextualize numbers to be able to make right decisions. There are no clear rights and wrongs in medicine. There are only relatively better/worse options.
Therefore integrating deaths due to non-virus causes is important.
It would also be useful to have breakdown of these deaths into different categories (eg: Non-COVID deaths due to lack of ventilators/ICU beds in hospitals, non-COVID deaths due to inability to refill on medications, accidents during migration, deaths due to police action, and so on).
These figures enable weighing risks and benefits for every time-critical decision, like provisions to be made in a hospital, or measures to take in local self governance, etc.

We have a reason columns which can contain one more values from
Medical Emergency
Road Blocked
Suicide
Lockdown
Exhaustion,
Migration
Hunger
etc. We can add more as when we encounter

{
  "id": "2020-03-25|non_virus_deaths|17",
  "key": "2020-03-25|non_virus_deaths|17",
  "value": {
    "_id": "2020-03-25|non_virus_deaths|17",
    "_rev": "3-3381b76df61bff8c3b28276a1cffad27",
    "type": "non_virus_deaths",
    "location": "Rasingapuram",
    "district": "Theni",
    "state": "KL",
    "incident_date": "2020-03-24",
    "deaths": 4,
    "reason": [
      "Forest fire",
      "Roadblock"
    ],
    "source_date": "2020-03-25",
    "source_link": "https://www.thehindu.com/news/national/tamil-nadu/death-toll-rises-to-4-in-theni-forest-fire-tragedy/article31160605.ece",
    "source": "www.thehindu.com"
  }
}

API details if anyone is interested. You can cache it on your server as it changes only once a day.
https://twitter.com/thej/status/1244342448664371200

I think the API is not allowing cross-origin requests. I was just trying out the API after @anivar  shared the same.

@esafwan  Can you cache it on your server and use it. Server side pull should be okay right?

Yes, it should work.
I had forked this repo and was directly accessing via axios from client-side to see if I can send a PR.

Let me know.
Else I will add this site to my CORS list.

@thejeshgn Sorry got a bit held up. Correct me if I am wrong, I think covid19india.org is not using a backend. It's reading data from JSON files. In that case, we only have two options:

Write a CRON job somewhere to periodically download data of non-virus death and update the JSON file from where we update the site.
Add covid19india.org to the CORS list.

I think this decision should be taken by the maintainers (@jeremyphilemon)  and  @thejeshgn .

Give me an hour. I will add cors for this domain.
Regards,
Thej
Thejesh GN ⏚ ತೇಜೇಶ್ ಜಿ.ಎನ್
http://thejeshgn.com
On Sun, 5 Apr, 2020, 3:12 PM Safwan Erooth<EMAIL_ADDRESS>wrote:

@thejeshgn https://github.com/thejeshgn Sorry got a bit held up.
Correct me if I am wrong, I think covid19india.org is not using a
backend. It's reading data from JSON files. In that case, we only have two
options:

Write a CRON job somewhere to periodically download data of
non-virus death and update the JSON file from where we update the site.
Add covid19india.org to the CORS list.

I think this decision should be taken by the maintainers (@jeremyphilemon
https://github.com/jeremyphilemon) and @thejeshgn
https://github.com/thejeshgn .
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/covid19india/covid19india-react/issues/354#issuecomment-609388380,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAASSUVHCK3IXKDODL2NRSLRLBG67ANCNFSM4LWCWSBQ
.

I have added the CORS. It should work.
In case if it didn't use one of the CORS proxies. https://gist.github.com/jimmywarting/ac1be6ea0297c16c477e17f8fbe51347

Sorry, but this seems out of our scope.


Predicting in submilliseconds

Lately there's been greater interest in faster prediction. In the near future, the dmlc group will host a new project (provisionally named) tree-lite that is dedicated to improving prediction speed.
Some facts about tree-lite:

It will read your (already trained) tree ensemble model and produce an optimized prediction library.
We aim to provide a well assorted toolbox of methods that are known to improve prediction speed. People will be able to experiment with it on their own. Good engineering will be essential in this effort --- see how xgboost lets people experiment more rapidly with tree models.
It will support multiple tree formats, so that you can use other packages (e.g. LightGBM) to train your model.

The project is currently private, but we are working hard to make it public in the near future. Stay tuned!


How can I inference the results?

Hey, How can I inference the results? (3d boundingbox or pointcloud draw)

First using the provided model to predict R, and t. then you get the estimation of the bounding box.
We provide some codes in SO-Pose/core/gdrn-selfocc-modeling/tools/my_visualizer.py for visualization.
Also the official BOP_toolkit here https://github.com/thodan/bop_toolkit/blob/master/bop_toolkit_lib/visualization.py will help you.
For point cloud, you can use scatter in python.  You can also find other advanced tools on github easily

https://github.com/shangbuhuan13/SO-Pose/blob/b1cfa9c20bfbb0b4ccd1e8c421e392958628aa4f/core/gdrn_selfocc_modeling/tools/lmo/lmo_2_vis_poses.py#:~:text=from lib.egl_renderer.egl_renderer_v3 import EGLRenderer


Use RMM Memory allocator

Closes #94.

Looks great! Not sure why this hasn't made it through CI yet. I'll look into it and we can merge as soon as it does.

Just a linting failure in CI. Can you run the format fixer and update?

Weird... Looks like it still failed linting? Does the cleanup script give you any other required changes locally?


Add CP-SCF tutorial

Add a tutorial that explains the basics of coupled-perturbed SCF. The
tutorial uses Hartree-Fock theory (CP-HF) to compute the electric dipole
polarizability tensor alpha_ij.

This look great, thanks Marvin!
Ill go ahead and pull this in now, but I will probably ask for a few changes later.
How are the other tutorials coming along?

@dgasmith I did not have the time to start with other tutorials as I had to write a preliminary report for my thesis at TUM. That report is now ready to be handed in, so I'll take some time over the weekend to get started on TDHF/C6.

@mhlechner Good to know! Hope all is well.


Add Postgres 9.6

Only mainline, no contrib image just yet, this will probably need a little more massaging.
cc @fancyremarker

👍 , note to whoever merges this to create a new DatabaseImage afterwards.


<footer/social: Add the possibility to link to facebook account>

For some reason people may wants to have one facebook account directly
linked into the footer of the site generated using cocoa-eh. So do I,
maybe more people may use that too.

Hi ! Thank you for your PR !
Seems perfect to me, thank you again !


Peribolos does not create initial PR, or takes a very long time.

Describe the bug
After installing Peribolos to @allmende, the .github repository is created, but no initial PR towards it is filed:

https://github.com/allmende/.github/pulls

To Reproduce

Install Peribolos from https://github.com/apps/peribolos/installations/select_target to an organisation or your account.
See it create the .github repository
No PR with initial configuration will be filed.

Expected behavior
Peribolos initiates a PR against the repository it just created, such as in:

https://github.com/b4mad/.github/pull/1

Additional context
Logs from https://argocd.operate-first.cloud/applications/peribolos?resource=&node=%2FPod%2Fop1st-peribolos%2Fperibolos-controller-7ccf9bfc-pbdhp%2F0&tab=logs show how the repository is created, and then silence.
Details

{"level":30,"time":1695749427503,"pid":21,"hostname":"peribolos-controller-7ccf9bfc-pbdhp","name":"probot","name":"probot","msg":"Creating '.github' repository."}
{"level":20,"time":1695749428785,"pid":21,"hostname":"peribolos-controller-7ccf9bfc-pbdhp","name":"probot","name":"probot","name":"octokit","msg":"GitHub request: POST https://api.github.com/app/installations/42246802/access_tokens - 201"}
{"level":30,"time":1695749428827,"pid":21,"hostname":"peribolos-controller-7ccf9bfc-pbdhp","name":"probot","name":"server","name":"http","req":{"id":"60c41d70-5c92-11ee-8d78-6e64a7e54dfc","method":"POST","url":"/","query":{},"params":{},"headers":{"user-agent":"GitHub-Hookshot/03108ac","content-length":"26845","accept":"*/*","x-github-delivery":"60c41d70-5c92-11ee-8d78-6e64a7e54dfc","x-github-event":"installation","x-github-hook-id":"391668396","x-github-hook-installation-target-id":"181154","x-github-hook-installation-target-type":"integration","x-hub-signature":"sha1=f07199c41e29b29ea939b5bb2e4e27f8f5991f4b","x-hub-signature-256":"sha256=2645fae91344f8ec21cdcc0c688d7d53cc7835125ba7e825ef95b4499a3c2f9c","content-type":"application/json","host":"peribolos.b4mad.emea.operate-first.cloud","x-forwarded-host":"peribolos.b4mad.emea.operate-first.cloud","x-forwarded-port":"443","x-forwarded-proto":"https","forwarded":"for=<IP_ADDRESS>;host=peribolos.b4mad.emea.operate-first.cloud;proto=https","x-forwarded-for":"<IP_ADDRESS>"},"remoteAddress":"::ffff:<IP_ADDRESS>","remotePort":43878},"res":{"statusCode":200,"headers":{"x-powered-by":"Express"}},"responseTime":1507,"msg":"POST / 200 - 1507ms"}
{"level":20,"time":1695749429373,"pid":21,"hostname":"peribolos-controller-7ccf9bfc-pbdhp","name":"probot","name":"probot","name":"octokit","name":".github","msg":"GitHub request: POST https://api.github.com/orgs/allmende/repos - 201"}
{"level":30,"time":1695749430764,"pid":21,"hostname":"peribolos-controller-7ccf9bfc-pbdhp","name":"probot","name":"server","name":"http","req":{"id":"6381b6d0-5c92-11ee-807a-6815fcd076ec","method":"POST","url":"/","query":{},"params":{},"headers":{"user-agent":"GitHub-Hookshot/03108ac","content-length":"3001","accept":"*/*","x-github-delivery":"6381b6d0-5c92-11ee-807a-6815fcd076ec","x-github-event":"installation_repositories","x-github-hook-id":"391668396","x-github-hook-installation-target-id":"181154","x-github-hook-installation-target-type":"integration","x-hub-signature":"sha1=9179e6c8397afa54116c2b1e86ffcda5833b9602","x-hub-signature-256":"sha256=7f815e08080d5742ff01df0d3eb87b841b965b5b99adb1639c5937823410a29e","content-type":"application/json","host":"peribolos.b4mad.emea.operate-first.cloud","x-forwarded-host":"peribolos.b4mad.emea.operate-first.cloud","x-forwarded-port":"443","x-forwarded-proto":"https","forwarded":"for=<IP_ADDRESS>;host=peribolos.b4mad.emea.operate-first.cloud;proto=https","x-forwarded-for":"<IP_ADDRESS>"},"remoteAddress":"::ffff:<IP_ADDRESS>","remotePort":43894},"res":{"statusCode":200,"headers":{"x-powered-by":"Express"}},"responseTime":3,"msg":"POST / 200 - 3ms"}

There are further POST events by GitHub-Hookshot after those, ignoring GET queries to /metrics and /healthz, for push, check_suite and check_run events, but still no PR appears.

This resolved with patience.

https://github.com/allmende/.github/pull/1


TypeScript indexer: Fix handling of class values and types

Since cdee8bf8a813ddd0309dbab00110f0e972282996, the structure for class VNames is:

Class name identifiers refer to the class type and have a node kind of a record
Class constructors refer to the class value and have a node kind of a function, subkind of constructor. If there is no constructor, the class name takes this.

//- @Class defines/binding Class=VName("Class#type", _, _, _, _)
class Class {
  //- @constructor defines/binding ClassCtor=VName("Class:ctor", _, _, _, _)
  constructor() {
    //- @Class ref ClassCtor
    new Class();
  }
}

//- @CC defines/binding VName("CC#type", _, _, _, _)
//- @CC defines/binding VName("CC:ctor", _, _, _, _)
class CC {}

This is probably backwards. The constructor should refer to the class type, and the class value should point to the class identifier. This should resolve problems when references to classes are interpreted in a value context and taken to the constructor when they should be taken to the class identifier. The class type and value will both have a node kind of a record.
We should also emit a separate entry for constructors with a signature of Class.constructor, for example. This makes scoping parameters and variables inside the constructor much easier, so that while the constructor and class type point to the same thing, they are not actually the same thing. The class constructor will have a node kind of a function with a subkind of a constructor.

Unfortunately, either choice has trade-offs. Broadly, we've found that users expect that the cross-references for an object should include all the things that need to be examined if that object is changed (say, for example, renamed). If the xrefs for the class don't include the constructors, they'll complain. I'd say that complaint has been fairly robust across languages.
On the other hand, when jumping to definition, users often expect the name of a class in a constructor call to go to the constructor and not the class. That means in practice that the UI needs to give the user a choice: This reference might mean the class or the constructor. There might be a reasonable default for J2D, but there's no canonical way to know which one the user really wants (because it depends on what they're doing).
In any case, I suggest caution about forcing the choice between one or the other. This isn't really a decision the indexer can make correctly in isolation. (You can of course do it anyway, my caution is more a prediction of user expectations than a correctness issue).

I think in the case of a class instantiation, the indexer should point to the constructor. In all other cases, it's easiest to simply point to the class name - this harshly defines the class value and class type to be the class name, which is less ambiguous than the class type sometimes being the constructor, sometimes being the class name, etc.
In fact, the only time we call the constructor of a TypeScript class (aside some esoteric use cases) is during instantiation.

The indexer should ref both, but only ref/call the ctor.

I think in the case of a class instantiation, the indexer should point to the constructor. In all other cases, it's easiest to simply point to the class name

Right—it's pretty clear it should do that either way. But if it doesn't also point to the class, the xrefs for the class will not show them, and I expect users to file bugs about it.


report code coverage

As a developer, I want the dotnet-build to anylaze and report code-coverage, in order to let others quickly gain insights of the current-code-coverage of the repo, to let them  grasp if the provided code is covered good enough for their needs :)

probably, https://coveralls.io/ might be a good fit.
Current problem is to collect coverage in a folder that could be picked up by https://github.com/coverallsapp/github-action to be published...bummer
dotnet test-command generates coverage-files somewhere under src/.../TestResults/GUID/coverage.info (or similar).
This path would be needed in the coveralls-action.
@justinL23 got an idea for this?

https://github.com/microsoft/vstest/issues/4014

https://github.com/coverallsapp/github-action/issues/55


Ensure only one metaoperatorconfig and metaoperatorcatalog in one namespace

fix #76

@horis233 Maybe we can delete the newer config or catalog cr if we find the size >1

@gyliu513 done, remove the delete logic and add a notification for users to delete.


Create JJB templates for all the jobs

This way all the jobs are updated by scale-ci-watcher when we make changes to the templates. This will also enable us to recreate/migrate the pipeline on any Jenkins instance.

We now have jjb templates for all the supported jobs.


Conditional fields support

Consider example: we have many employees and only supervisor can see employee's salary, right now AFAIU it's only possible to set salary to nil using
class EmployeeBlueprint < Blueprinter::Base
  identifier :id
  fields :first_name, :last_name

  field :salary do |employee, params|
    if params[:current_user] == employee.supervisor
      employee_salary
    else
      nil
    end
  end
end

It's impossible to use a :view with salary field, since supervisors are different for different employees. So it would be useful to have something like
class EmployeeBlueprint < Blueprinter::Base
  identifier :id
  fields :first_name, :last_name

  field :salary, if: :supervisor?

  def supervisor?(employee, params)
    params[:current_user] == employee.supervisor
  end
end

to remove this field completely.

class EmployeeBlueprint < Blueprinter::Base
  identifier :id
  fields :first_name, :last_name

  field :salary, if: :supervisor?

  def supervisor?(employee, params)
    params[:current_user] == employee.supervisor
  end
  view :employee do
end

I think views was meant to intentionally do this. For example:
  # controller
  class EmployeesController < ApplicationController
    def show
        employee = Employee.find(:id)
        view = current_user == employee.supervisor ? :supervisor : :employee
        render json: Blueprinter.render(employee, view: view)
    end
  end

# Blueprint
class EmployeeBlueprint < Blueprinter::Base
  identifier :id
  view :employee do
    fields :first_name, :last_name
  end
  view :supervisor do
    include_view :employee #inherit fields from :employee
    field: :salary
  end
end

I should've clarified in the first post, the issue is collection serialization, i. e. the case
EmployeeBlueprint.render([
  Employee.create(supervisor: first_supervisor),
  Employee.create(supervisor: second_supervisor)
])

Hmm ok, in that case I think it's a feature that blueprinter could support. @dlcarter @AllPurposeName does this make sense to you guys as well?

Yeah this is a compelling case, I think. 👍


"Unable to find libfuse" in MacOS

I tried to run hellobot with:
poetry run python -m sample_bots.hellobot
And an exception is raised:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Users/qinyu/job/alf/singal_bot/forestbot-template/template.py", line 1, in <module>
    from forest.core import Bot, Message, run_bot
  File "/Users/qinyu/Library/Caches/pypoetry/virtualenvs/yourbot-1I-L8FrT-py3.9/lib/python3.9/site-packages/forest/core.py", line 43, in <module>
    from forest import autosave, datastore, payments_monitor, pghelp, utils, string_dist
  File "/Users/qinyu/Library/Caches/pypoetry/virtualenvs/yourbot-1I-L8FrT-py3.9/lib/python3.9/site-packages/forest/autosave.py", line 16, in <module>
    from forest import fuse, mem, utils
  File "/Users/qinyu/Library/Caches/pypoetry/virtualenvs/yourbot-1I-L8FrT-py3.9/lib/python3.9/site-packages/forest/fuse.py", line 56, in <module>
    raise EnvironmentError("Unable to find libfuse")
OSError: Unable to find libfuse

I failed to google a solution to this problem. Any thoughts?

Are you using MacPorts or Homebrew?

Are you using MacPorts or Homebrew?

I have installed programs with Homebrew. I don't think that I have used MacPorts.


Mark fields named width or height public even if they're fieldref

Fixes #186

This is behaviourally the same as the patch I showed, but with a better (IMO) note about why we do what we do here

thanks


Alamofire.upload with Multipart Form Data isn't removing temporary files after the request finished

Pod version: 3.5.1
Swift version: 2.2

I found the source of the problem. The temporary file should be removed after the operation ends. According to the documentation, the temporary folder only gets cleaned when the app is not running so, basically, it means that if the user never decides to kill the app or never reboots his device then, the temporary folder will remain.
Any clue on where to put the code to clean up the temporary file?

I noticed that the multipartFormData has been reimplemented on 4.0.0 version but unfortunately I'm still using Xcode 7.3.1 and I can't update the project right now.

Assigning a taskDidComplete in the moment of the task could be a solution, right?

Hi @ricardopereira,
Thanks for opening up this issue. I've just pushed up 9688b16f into master which automatically removes the temp file from disk after the upload completes. This will be part of the Alamofire 4.1.0 release which should be out by Monday.
If you're not using the latest version of Alamofire, you could manually delete the file like so in a response handler.
Alamofire.upload(
    multipartFormData: { multipartFormData in
        multipartFormData.append(unicornImageURL, withName: "unicorn")
        multipartFormData.append(rainbowImageURL, withName: "rainbow")
    },
    to: "https://httpbin.org/post",
    encodingCompletion: { encodingResult in
        switch encodingResult {
        case .success(let upload, _, streamFileURL):
            upload.responseJSON { response in
                debugPrint(response)

                // This is how you can remove the file
                if let streamFileURL = streamFileURL {
                    do {
                        try FileManager.default.removeItem(at: streamFileURL)
                    } catch {
                        print("Failed to remove stream file at URL: \(streamFileURL) - error: \(error)")
                    }
                }
            }
        case .failure(let encodingError):
            print(encodingError)
        }
    }
)

Cheers. 🍻

@cnoon Thanks 👍
BTW, on 3.x, how can I remove the temporary file if it fails?

Great call @ricardopereira! I just pushed up e68bfdcc which will automatically delete the temp file in the event of a failure. Unfortunately there's no way to do this in the 3.x version of Alamofire.


Multiple updates to the same id in one Batch result in multiple documents with the same id in the index

While easy to fix and avoid, I wasn't expecting batches to write multiple values for the same ID in the index. It may be intentional? What are the reason for it? Anyway it can be avoided by using a map keyed by the ID and only writing the result to the batch.

So, this was an intentional design change from Bleve.  Specifically, in Bluge it is INVALID to add documents with the same identifier to a single batch.  If you do so, it will fail to maintain the invariant that document identifiers are unique.
If we don't want to allow this, why don't we enforce it ourselves?  Simply because there are some use cases where you never have duplicates at all, and therefore having the batch implementation use a map internally to de-duplicate is not only unnecessary, it makes reusing batch objects essentially impossible.  The big downside is that it means applications must de-duplicate entries in the batch themselves.  In practice I have found this not to be a huge deal, but I understand this is an API pain point, and I'm willing to consider other options.
And obviously we have not found a way to correctly communicate this, as you have run into this issue..
In the future with generics, it might even be possible for us to have 2 batch impls (one dedups, and one doesn't) without a perf penalty.  But for now, we've opted to simply make Bluge more powerful/useful, at the expense of making this part harder.  If you have suggestions to improve this that don't involve giving up batch re-use I'm open to other ideas.

Thanks for the fast reply. Yes that makes sense however it would be nice to have some comments on the batch struct or method https://github.com/blugelabs/bluge/blob/master/index/batch.go That would solve it in my opinion.
I somehow overlooked it in the docs https://blugelabs.com/bluge/indexing


Missing modules

When I dragged Plugins folder into my project folder, there popped out an error window titled "Missing RobotEngine Modules" and it said "the following modules are missing or built with a different engine version: SocketIOClient, SIOJson, SocketIOLib, CoreUtility, SIOJEditorPlugin, UDPWrapper."
Then when I tried to to rebuild them, it failed and said that I should rebuild manually from the source.

use the .7z in releases not source code, which includes the binaries for your project


mismatch from documentation?

Description
I've been tracking a bug in git 2.36 which is fixed in 2.37 -- the image information for 20220724.1 claims it has git 2.37.1 but I'm still seeing 2.36
here's my job run: https://dev.azure.com/asottile/asottile/_build/results?buildId=13799&view=logs&j=94d9d3b4-8e3d-5cdc-d6c7-40ce0e4fea69&t=3be1b07c-7b5b-4b02-84ff-33b8af3eb53d
(excerpt from setup):
Current image version: '20220724.1'

(excerpt from checkout)
git version
git version 2.36.1.windows.1

the documentation for 20220724.1 is at this commit: https://github.com/actions/virtual-environments/pull/5957 and contains this information:
Git 2.37.1.windows.1

I'm wondering why I'm seeing a disparity from the documentation -- and would really like to be on git 2.37 :D
Platforms affected

[X] Azure DevOps
[ ] GitHub Actions

Virtual environments affected

[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] macOS 10.15
[ ] macOS 11
[ ] macOS 12
[ ] Windows Server 2019
[X] Windows Server 2022

Image version and build link
20220724.1
https://dev.azure.com/asottile/asottile/_build/results?buildId=13799&view=logs&j=94d9d3b4-8e3d-5cdc-d6c7-40ce0e4fea69&t=3be1b07c-7b5b-4b02-84ff-33b8af3eb53d
Is it regression?
kind of? but not really -- it's a regression in git -- here's a passing run though (which was on git 2.30.2): https://dev.azure.com/asottile/asottile/_build/results?buildId=13615&view=results
Expected behavior
I expect to have git 2.37.1 as the documentation states
Actual behavior
I am seeing git 2.36.1
Repro steps

run any job which checks out code
note the git version

notably git 2.36.1 on windows has a bug with the output of pre-push hooks is in an undefined order which one of my tests is sensitive to

Hello @asottile.
The documentation is correct. There are a couple of git versions available on Azure DevOps images:

https://github.com/microsoft/azure-pipelines-agent
Pre-installed on an image

If we take a look at the build we can find the agent version - Current agent version: '2.206.1' - https://github.com/microsoft/azure-pipelines-agent/releases
PS > cd .\vsts-agent-win-x86-2.206.1\
PS D:\vsts-agent-win-x86-2.206.1> .\externals\git\cmd\git.exe -- version
PS D:\vsts-agent-win-x86-2.206.1> .\externals\git\cmd\git.exe --version
git version 2.36.1.windows.1

Please create a new issue in the https://github.com/microsoft/azure-pipelines-agent repository.
cc @geekzter

shouldn't the docs show the version that's being used rather than the version that's not? I don't see the point in having the wrong one documented

No, it shouldn't. It's part a 3rd party external agent. You can still use git version which mentioned in the doc.


Do not stop console on invalid command

For now invelid comand produces the next message and stops console
Execution halted
Process finished with exit code 1

Fixed in 0ed59a6deea7a493a9e50ebdf8fe65eb1011660f


Failed to create engine using tmx files

Hi,
I am a beginner to your program, and I am trying to create an engine using tmx files. When I type:
./mmt create en tr examples/data/train/en_TR
I get an error message saying:
ENGINE:  default
BILINGUAL CORPORA: 2 documents
MONOLINGUAL CORPORA: 0 documents
LANGS:   en > tr
INFO: (1 of 6) Corpora cleaning...
ERROR Unexpected exception:
Command 'java -Xmx3550m -cp /home/sinan/Downloads/mmt/build/mmt-2.4.jar -Dmmt.home=/home/sinan/Downloads/mmt -Djava.library.path=/home/sinan/Downloads/mmt/build/lib eu.modernmt.cli.CleaningPipelineMain -s en -t tr --output /home/sinan/Downloads/mmt/runtime/default/tmp/training/clean_corpora --input /home/sinan/Downloads/mmt/examples/data/train/en_TR' failed with exit code 1
Traceback (most recent call last):
File "./mmt", line 846, in
main()
File "./mmt", line 792, in main
actionscommand
File "./mmt", line 186, in main_create
training.start()
File "/home/sinan/Downloads/mmt/cli/training.py", line 63, in start
self._builder.build(self)
File "/home/sinan/Downloads/mmt/cli/mmt/engine.py", line 402, in build
self._build(resume=False, listener=listener)
File "/home/sinan/Downloads/mmt/cli/mmt/engine.py", line 482, in _build
method(self, args, skip=skip, log=log_stream, delete_on_exit=self._delete_on_exit)
File "/home/sinan/Downloads/mmt/cli/mmt/engine.py", line 294, in call
self._f(*args, **kwargs)
File "/home/sinan/Downloads/mmt/cli/mmt/engine.py", line 526, in _clean_tms
args.bilingual_corpora = self._engine.cleaner.clean(args.bilingual_corpora, folder, log=log)
File "/home/sinan/Downloads/mmt/cli/mmt/processing.py", line 80, in clean
shell.execute(command, stdout=log, stderr=log)
File "/home/sinan/Downloads/mmt/cli/libs/shell.py", line 55, in execute
raise ShellError(str_cmd, returncode, stderr_dump)
cli.libs.shell.ShellError: Command 'java -Xmx3550m -cp /home/sinan/Downloads/mmt/build/mmt-2.4.jar -Dmmt.home=/home/sinan/Downloads/mmt -Djava.library.path=/home/sinan/Downloads/mmt/build/lib eu.modernmt.cli.CleaningPipelineMain -s en -t tr --output /home/sinan/Downloads/mmt/runtime/default/tmp/training/clean_corpora --input /home/sinan/Downloads/mmt/examples/data/train/en_TR' failed with exit code 1
My tmx files contain both english and turkish texts with some tags and I am sure that they are encoded in UTF-8 format. I've read another issue about a similar problem and in that case you said the date and time format in the tmx file was wrong. So, checked date and time in my tmx files they looked OK.
By the way, I can create engines using monolingual parallel text files without any errors.
Can you please help me solve this problem?
Thank you.

Hi @Sinantra , and welcome to ModernMT! :)
can you please upload here the log file in /home/sinan/Downloads/mmt/runtime/default/logs/training.log?

Thanks for the quick response:)
Log file:
training.log

Here's the problem (from training.log):
Exception in thread "main" java.lang.IllegalArgumentException: EN-US

Right now ModernMT applies a strict check on languages (we plan to be more "elastic" in the future), and a language must match this format:
[a-z]{2}(-[A-Z]{2})?

So.. basically, you have to transform "EN-US" in "en-US".

Actually, I'm planning to work on this asap. Meanwhile, if you can, just replace the language tag as I mentioned: it should be much faster than waiting for me :)

Ok then, I will replace the language tag as you mentioned :)
Thank you.

I changed the language tags and it worked. I also had to change TR to tr-TR.
Thanks again for your help.

Hi @Sinantra ,
this has been solved in the new MMT master branch.
Thanks for your support and patience.


Getting information on next job

Acceptance Criteria

[x] AC-12.1: A field worker should be able to get information on their next job using the Jobber API
[x] AC-12.2: When a field worker requests for information on their next visit, and it has an important note, the smart assistant should return the next visit’s location, time frame, client, description of the visit, how far the location is from current location, and the important note associated  with the visit
[x] AC-12.3: When a field worker requests for information on their next visit, and it has important notes, the smart assistant should return the next visit’s location, time frame, client, description of the visit, how far the location is from current location, and the important notes associated  with the visit
[x] AC-12.4: When a field worker requests for information on their next visit, and it has no important notes, the smart assistant should return the next visit’s location, time frame, client, description of the visit, and how far the location is from current location
[x] AC-12.5: When a field worker requests for information on their next visit, and there is no next job for the day, the smart assistant should inform them there is no more jobs for the day

solved

@dai-dao Looks like the description field in a visits is often set to null. So when you ask for the next job you will often get a comma followed by nothing where the description should be:

We should also be rendering the dates as times so like 5:30 pm instead of the epoch times. I think returning then notes might be a bit too much but that's up to you.


I made changes only to NodePool, but NodeClass has changed as well

Description
Observed Behavior:
When I changed only the NodePool setting and applied, the NodeClass setting was also changed.
The only place to change is in NodePool resource value of key: “karpenter.k8s.aws/instance-cpu”.
The only unexpected change is the value of .spec.metadataOptions.httpPutResponseHopLimit in NodeClass, which is changed from 2 to 1.
The httpPutResponseHopLimit was not defined in Yaml, but used the default. (I intentionally set it to 2 now because of this issue)
As I assume, we upgraded from v0.37 to v1 about a month ago.
At that time, I did not take any action because the httpPutResponseHopLimit did not change to 1, which is the v1 default, without changing httpPutResponseHopLimit to 2.
Is it possible that this has now been changed to the default of 1?
before
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: nodepool
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["m6i"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: "karpenter.k8s.aws/instance-cpu"
          operator: In
          values: ["16", "32", "48"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: nodeclass
      expireAfter: 720h # 30days
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: 25
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: nodeclass
spec:
  amiFamily: AL2023
  amiSelectorTerms:
    - name: amazon-eks-node-al2023-x86_64-standard-1.29-v20241024
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "dev"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "dev"
  role: "noderole"
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 60Gi
        volumeType: gp3
        encrypted: true
        deleteOnTermination: true
        throughput: 125
  tags:
    CostEnv: dev
    CostService: service
    CostTeam: team
  userData: |
    #!/bin/bash
    modprobe iptable_nat
    modprobe ip6table_nat
    dnf -y install rsyslog
    systemctl enable --now rsyslog

after
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: nodepool
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["m6i"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: "karpenter.k8s.aws/instance-cpu"
          operator: In
          values: ["4", "8", "16", "32", "48"] <-- here
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: nodeclass
      expireAfter: 720h # 30days
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: 25

Expected Behavior:

Change only where expected.

Reproduction Steps (Please include YAML):

Checking

Versions:

Chart Version: 1.0.6(oci://public.ecr.aws/karpenter/karpenter)
Kubernetes Version (kubectl version): v1.29.10-eks-7f9249a

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Was this the first time you had reapplied the EC2NodeClass since upgrading to v1? This is expected behavior for defaulted fields - if the field hasn't been specified and you apply the manifest, the default will be used.

@jmdeal
Thank you replied, I understood.
If I apply an EC2NodeClass that has not been modified, does it behave that way?


Crash with: free(): double free detected in tcache 2

I have the following in my i3 config:
exec --no-startup-id setxkbmap -layout de,us -option 'grp:alt_shift_toggle'
exec --no-startup-id xkb-switch --i3

It crashes quite arbitrarily. I didn't succeed to reproduce it reliably yet. Even after some stress testing like changing the keyboard layout or changing the focused window excessively didn't enforce a crash. This might indicate a race condition problem.
The log after the crash contains
free(): double free detected in tcache 2
Therefore, to debug a bit by myself, I built xkb-switch myself and launched it within valgrind to get some more information:
https://pastebin.com/EcJtqW2E
journalctl shows:
Module /home/mine/xkb-switch-i3/Debug/xkb-switch with build-id d2a9fdfa700f4e3a8f058f2d6141532d8286e9ed
Module /home/mine/xkb-switch-i3/Debug/libxkbswitch.so.1.8.5+i3-1 with build-id 69e53ed063bf7c3d2111ee169dae76b997dad089
Module linux-vdso.so.1 with build-id 34c0ea075a5642c584dd6db5b229d5fb28564ebb
Module libXdmcp.so.6 with build-id 8ca0792d23c8b8b4c0864297512349292bea5955
Module libXau.so.6 with build-id 1c67764663e07bec24d8951e5fd93f4d165979ff
Module ld-linux-x86-64.so.2 with build-id c09c6f50f6bcec73c64a0b4be77eadb8f7202410
Module libdl.so.2 with build-id bb9bd2657bfba9f60bd34d2050cc63a7eb024bc4
Module libxcb.so.1 with build-id 0d1ef11740a5daad2ee331e812a51aa6574af222
Module libc.so.6 with build-id 85766e9d8458b16e9c7ce6e07c712c02b8471dbc
Module libgcc_s.so.1 with build-id 5d817452a709ca3a213341555ddcf446ecee37fa
Module libm.so.6 with build-id 596b63a006a4386dcab30912d2b54a7a61827b07
Module libstdc++.so.6 with build-id 88ad4eff81a00c684abfe0f863e87434123d8943
Module libxkbfile.so.1 with build-id de5e415879c20263a8dd42f8cf2dd88107c2bfb2
Module libX11.so.6 with build-id 5ba5798d193c0065014b8c6252a0678671c8d478
Module libjsoncpp.so.25 with build-id 87680bad0ee329d980627591e5543fef570aa048
Module libsigc-2.0.so.0 with build-id 6b1f9f8e4d7ad41a0a5ac1c861dbab8616010a32
Stack trace of thread 1046:
#0  0x00007f66addda34c __pthread_kill_implementation (libc.so.6 + 0x8f34c)
#1  0x00007f66add8d4b8 raise (libc.so.6 + 0x424b8)
#2  0x00007f66add77534 abort (libc.so.6 + 0x2c534)
#3  0x00007f66addce397 __libc_message (libc.so.6 + 0x83397)
#4  0x00007f66adde433c malloc_printerr (libc.so.6 + 0x9933c)
#5  0x00007f66adde665c _int_free (libc.so.6 + 0x9b65c)
#6  0x00007f66adde8be3 free (libc.so.6 + 0x9dbe3)
#7  0x00007f66ae4661f1 n/a (/home/andreask/xkb-switch-i3/Debug/libxkbswitch.so.1.8.5+i3-1 + 0xa1f1)
#8  0x0000564d0b2cf511 n/a (/home/andreask/xkb-switch-i3/Debug/xkb-switch + 0x2b511)
#9  0x00007f66add78310 __libc_start_call_main (libc.so.6 + 0x2d310)
#10 0x00007f66add783c1 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2d3c1)
#11 0x0000564d0b2cd9b5 n/a (/home/andreask/xkb-switch-i3/Debug/xkb-switch + 0x299b5)
ELF object binary architecture: AMD x86-64

Because the strack trace seems a bit different than for https://github.com/Zebradil/xkb-switch-i3/issues/6, I'm not sure if they are related. But what they have in common is that it seems to be a problem with freeing memory.
Let me know if I can help in any way

Exact same thing here.
Distro: Arch (installed from AUR)

Thanks for reporting and for the fix.
Please, check the latest version (1.8.5+i3-2).


Clean up usage of GTest and GMock

For both GTest there is only one public header file each - gtest.h
and gmock.h. All the other header files should be considered internal
headers.
This change replaces all includes of gmock/gmock-*.h by
gmock/gmock.h and gtest/gtest-*.h by gtest/gtest.h.
Test: Compiles

@dpallotti @dimitry- @danielfenner I guess one review is enough since it's a rather mechanical change.

Thanks, @dimitry-


Get read-the-docs up and running

read-the-docs currently points to gitlab, now need to setup with github

@JoshuaSteer I don't have access to the current read-the-docs dashboard, so can't change where the docs point to as the name 'AmpScan' is already taken. I believe you can change this if you go to https://readthedocs.org/dashboard/ and change the url it changes to.

Good point - I'll sort tonight

@jack-parsons access now added on rtd and I've changed the repo pointer to github, let me know if you have any problems accessing

Read the docs is now building successfully


How to reload Webview?

I'm an iOS developer, I try to using webview_flutter: ^0.0.1+1, so I have 2 question:

How to reload WebView with other URL? WKWebView reload
How to know WebView finish load or facing error?  WKNavigationDelegate

Thanks!

I split this into 2 separate feature requests: #25099 #25100.


[Tracking] Provider compiled for darwin/arm64

Important Factoids
Apple M1 chip is here. Porting work is occurring for everyone. Opening a tracking ticket to provide public visibility on the work.
References
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

https://github.com/golang/go/issues/38485
https://github.com/hashicorp/terraform/issues/27257
https://github.com/hashicorp/terraform-provider-aws/issues/16948
https://github.com/newrelic/terraform-provider-newrelic/issues/1180

Status update: Go 1.16 was released today with non-prerelease, first-class support for darwin/arm64.

As this is a library, there isn't much to do here.  The New Relic Terraform Provider consumes and builds an arm64 asset, so this appears to be working as expected.


oh pending appointments by time.

fixes #220

can you bump werkzeug on requirements.txt up to 0.15.5?


Fix phaser 2.4 incompatible.

Please do not include these things in your PRs:

Built files (in the dist/ folder)
Project files (like the .idea/ directory)

Also, please do not change the version in package.json, I will do that when I am ready to release. If you could clean those things up and rebase it I would be happy to look at this PR.

Sorry, it's automatically changed.

Only if you run the release gulp task, just revert those changes I mentioned and I can probably merge this in.


Godot bumps project.godot modification time when exporting

Godot version
3.5-rc6
System information
ArchLinux
Issue description
When exporting a project using CLI with --no-window, the modification time of project.godot changes.
This leads to a "Files changed on disk" pop-up appearing in the Godot editor if it's running during the export process.
This is not a major issue but it makes working on a project annoying if you're frequently exporting a project for multiple platforms while keeping the editor open.
It seems like this behavior might be intentional, so I'm really wondering what's the reason for Godot CLI exporter to bump the modification time of project.godot.
Update: this can be prevented by setting project.godot as immutable with chattr +i (export still works without issues), but then the Godot editor starts spitting errors about being "unable to lock the project".
Steps to reproduce

Create a new project
Open if in the Godot editor
While keeping the editor open, run exporter: godot --no-window --export preset_name -q --verbose
Observe the "Files changed on disk" pop-up in the Godot editor

Minimal reproduction project
No response

Related to https://github.com/godotengine/godot/issues/31186. I'll keep this one open to track only the behavior on export.

This is intended, see #47385
However I think it makes sense to not do that when running with --export flag.
You can export in headless mode (--headless), this prevents saving the project (#50767)


adding tech stacks

please assign me this issue under gssoc as i would like to contribute and adding the stack shields and badges in the readme.

Kindly assign this issue to me .


extend data.ARTICULATION, data.ACCIDENTAL, etc. to include SMuFL code points

From<EMAIL_ADDRESS>on January 27, 2015 17:56:57
While it's not necessary to allow all the possibilities of SMuFL, adding some additional values (additional quarter-tone and just intonation accidentals and additional articulations, for example)
Original issue: http://code.google.com/p/music-encoding/issues/detail?id=214

From<EMAIL_ADDRESS>on January 27, 2015 14:59:51
Labels: Milestone-ReleaseNext

I wonder if it is a good idea to add the code points as a value? It could be problematic when there are compound glyphs. And SMuFL is not very semantic and may have different symbols to indicate an accent, but for MEI it should be an accent with different rendering.
Wouldn't it be better to allow @altsym to be used more generally and have it point to a symbolTable of SMuFL codepoints? We could provide this table as a downloadable file that can be xincluded when one wants to use SMuFL codepoints.
<symbolTable>
      <symbolDef xml:id="smufl_someStrangeAccentForm">
          <anchoredText>&#xCODE;</anchoredText>
      </symbolDef>
      <!-- etc -->
</symbolTable>
<!-- elsewhere -->
<artic artic="acc" altsym="#smufl_someStrangeAccentForm"/>

Allowing code points as the value of @artic is a bad idea.  @altsym should already point to a symbolDef element (not symbolTable).  symbolDef must be redefined along the lines of TEI's char element (in pseudo DTD syntax) --
symbolDef (symName?, symProp*, mapping*, model.graphicLike*, annotLike*)
symName (#PCDATA)
symProp (unicodeName | localName), value)
mapping (#PCDATA | symbol)*  -- this is expressed as a mixed content model but it really should be one or the other, not mixed
The indirection provided by this methodology insulates one from future changes, such as the adoption of SMuFL into Unicode or the creation of a SMuFL competitor.
But this may be too "heavy" a solution for some, so there could be a "quick and dirty" alternative -- add stdval (or code, and perhaps authURI and authority) attributes to elements that we expect to point to SMuFL via a codepoint value.  Schematron can be added to insure that stdval attributes where we expect SMuFL (this is not universal) conform to a standard syntax, such as '#xE0000'.  The only problem I see with this is that it is the SMuFL names that are persistent, not the codepoints.  Another possibility is to add a codepoint attribute that must conform to the standard syntax.  In either case, the trick is to support SMuFL without making MEI SMuFL-centric.
Comments?  @lpugin, @kepper?
Quick question -- How does one insert code as Raff has done above?

You can do that by enclosing your code with three backticks. Optionally, you can set the language, so:

```xml
... your xml code here ...
```

altsym should already point to a symbolDef

I know that, and my example complies. What I meant is that I think @altsym should be more widely available, for example it is not on <artic> at the moment. That would be needed even with with what you're suggesting right? Or would you want an entirely new attribute for the codepoints or names?

Sorry, I misunderstood your suggestion.  Yes, '@altsym' should be more widely available.  But it should be used only to point internally; that is, to the ID of a '' element.  One or more new attributes have to be added to support the "quick and dirty" method.

The "quick and dirty" method I now think would be best accomplished by adding @smuflname and @smuflcode in a new MEI.smufl module. This would make it possible to "short circuit" the @altsym / <symbolDef> methodology in a very intuitive way. If SMuFL is eclipsed someday by some other system, then it would be very easy to ignore the SMuFL module and create another for the new thing.  But, I want to keep the more abstract @altsym approach too.
Supporting SMuFL is more than just adding these attributes, however.  It also means making sure that MEI and SMuFL have the same level of granularity; that is, there are some things in MEI that are currently expressed in attributes (notehead shape and stems, for instance) that would be better treated as elements, so that they can bear the new attributes mentioned above.  This is also related to the changes sought by the black mensural notation folks.
@lpugin and I already had some discussion along these lines, but I'd like to hear from others. @kepper ?

Am 06.07.2015 um 20:18 schrieb pe-ro<EMAIL_ADDRESS>
The "quick and dirty" method I now think would be best accomplished by adding @smuflname and @smuflcode in a new MEI.smufl module. This would make it possible to "short circuit" the @altsym /  methodology in a very intuitive way. If SMuFL is eclipsed someday by some other system, then it would be very easy to ignore the SMuFL module and create another for the new thing. But, I want to keep the more abstract @altsym approach too.

I'd like to see some real-world examples, ideally some that illustrate the problems where MEI and SMuFL implement a different level of granularity…

Supporting SMuFL is more than just adding these attributes, however. It also means making sure that MEI and SMuFL have the same level of granularity; that is, there are some things in MEI that are currently expressed in attributes (notehead shape and stems, for instance) that would be better treated as elements, so that they can bear the new attributes mentioned above. This is also related to the changes sought by the black mensural notation folks.

Just the other day, I encountered yet another problem with Beethoven, or better with expectations about the encoding of his scores. To make a long story short, it was about the expectation that a note would be more or less still the same thing, even after he added a flag to turn a quarter into eighth. Right now, I have to delete the original 4, and add another 8. It is left to things like @sameas, @corresp or (certainly less accessible) the reference to the same svg:shapes in @facs to indicate the close relationship between these two notes. With ,  and similar child elements of notes, this could be encoded in a more accessible way. However, at this point I would probably refuse to use it in our project, as it results in an extremely verbose encoding, which is hardly maintainable. So yes, I see a benefit in having it, even in a quite different context. At the same time, I'm afraid of the consequences it might have. We should clearly discourage to use these elements unless people really know what they're doing…
Just my first thoughts…
jo

@lpugin and I already had some discussion along these lines, but I'd like to hear from others. @kepper ?
—
Reply to this email directly or view it on GitHub.

I think you've just provided a very good example (better than any I can conjure at the moment).  Note heads, stems, and flags are the only examples I have found so far that require "elevation" to element status, since we already provide accid, artic, and dot elements inside <note>. BTW, <notestem> would be best expressed as simply <stem> as it must be allowed within <chord> too.
I share some of your reluctance to go too far in this direction, not so much because of the verbosity it adds, but because of the added complexity as it relates to editorial intervention (soon <rdg> will allow just about everything in MEI).  But, if we're going to address more visual characteristics (which is necessary to deal with medieval; i.e., black mensural, and modern notation), then it's a fait accompli.  And we've already entered this territory with <accid>, etc.
This is not to say that the "shorthand" method of using attributes should go away.  On the contrary, it should be preserved not only for its terseness, but I would argue that in most cases it is entirely correct to see a set of alterations as one editorial act, for example turning a quarter note into an 8th, which is best represented in a simple way; that is, as the deletion of the quarter note and the addition of an 8th even though what Ludwig did was add a flag. It depends on what the object of the representation is -- the text alteration or the writing acts.  Again, it's a matter of granularity.  Of course it's up to the project to define where it wants to draw the line.  I suspect that most people aren't going to be interested in the kind of stuff that Beethovenswerkstatt is. But they shouldn't be denied the means to use SMuFL.
I wouldn't discourage the use of these elements, just caution that they be used intelligently.  But intelligently can have different meanings.

I'm wondering (assuming the addition of <notehead>, <stem> and <flags> as children of <note>) if we can exclude these from <app>. It seems to me that since these things (along with <accid> and <dot>) influence the fundamental "character" of a note (as opposed to <artic> which affects only its performance), a change in their presence or value imply a completely different note, not the same note with a different rendering.  Referring to Jo's Beethoven example, the addition of a flag may be seen (and perhaps, encoded) as a simple graphical change.  BUT, there's a more fundamental change going on that should be represented by two different note elements.  If the proposed elements are excluded from <app> (and maybe from <add>, <del>, etc.), then the encoder is guided toward this world view.  If not, then we open up the possibility of confusion between the purely graphical and the "meaningful".  I think this is what frightens Jo (as it does me too).
Does anyone have strong objections to
<app>
  <rdg>
    <note dur="4">
      <!-- with descriptions of notehead, stem, flags, etc. -->
    </note>
   </rdg>
    <rdg>
      <note dur="8">
        <!-- with descriptions of notehead, stem, flags, etc. -->
      </note>
    </rdg>
</app>

as opposed to
<note>
  <app>
    <rdg>
      <!-- description of notehead, stem, flags, etc. -->
    </rdg>
    <rdg>
      <!-- description of notehead, stem, flags, etc. -->
    </rdg>
  </app>
</note>

or a similar approach using <add>, <del>, etc.?
Since all the attributes of <note> are optional, this latter encoding is possible.  BUT, it gives the visual rendition of the note precedence over its logical qualities and leaves too much implicit in the encoding, therefore making the encoding less useful.  I just haven't figured out a remedy that doesn't create other aches and pains.

Well, let me contradict myself. I agree that adding a flag significantly changes the character of a note. However, this is already a conceptual approach that may not be appropriate for every project under the sun. I know you'd like to restrict the possibilities for abusing edit.trans markup (app/rdg, add, etc.), but I don't think that's feasible. Probably, the best we can do is to add a whole lot of Schematron rules to prevent "false" nesting. I can see good arguments for something like

and I don't think we can really determine a reasonable point where this stops making sense. Again, I would suggest to use Schematron to prevent the use of attributes and elements, but the reason to have those extra child elements (at least for CMN) is the additional flexibility to address complicated situations. Restricting the possibilities thus seems counter-productive. Channeling them, or better: providing guidance through Schematron seems more worthwhile to me.
In some sense, this all comes down to the problematic preference for mei-all.rng by many people. We need to improve our communication that mei-all really shouldn't be people's starting point to work with MEI. If we could make them use a mei-cmn-standard.rng versus a mei-cmn-advanced.rng (other repertoires following the same model) instead, the situation might be much better. We could even think about a system similar to the CC licenses for labeling schemas: two letters for the repertoire, another two letters indicating advanced encoding ( = much more elements allowed), two letters for inclusion of editorial markup, two for facsimiles etc. Such an approach could give a general sense of what can be expected from that particular schema. Even when people start to customize from one of those, it could be indicated accordingly. If we could come up with a obvious labeling system, it could help to better manage expectations, but also to prevent misuse / misunderstandings of how to use MEI appropriately.
Am 07.07.2015 um 00:16 schrieb pe-ro<EMAIL_ADDRESS>
I'm wondering (assuming the addition of ,  and  as children of ) if we can exclude these from . It seems to me that since these things (along with  and ) influence the fundamental "character" of a note (as opposed to  which affects only its performance), a change in their presence or value imply a completely different note, not the same note with a different rendering. Referring to Jo's Beethoven example, the addition of a flag may be seen (and perhaps, encoded) as a simple graphical change. BUT, there's a more fundamental change going on that should be represented by two different note elements. If the proposed elements are excluded from  (and maybe from , , etc.), then the encoder is gui ded toward this world view. If not, then we open up the possibility of confusion between the purely graphical and the "meaningful". I think this is what frightens Jo (as it does me too).
Does anyone have strong objections to
<app

<
rdg

<

note dur="4"

</

note

</
rdg

<

rdg

  <

note dur="8"

  </

note

</

rdg

</
app>
as opposed to
<note

<
app

<

rdg

</

rdg

<

rdg

</

rdg

</
app

</
note>
or a similar approach using , , etc.?
Since all the attributes of  are optional, this latter encoding is possible. BUT, it gives the visual rendition of the note precedence over its logical qualities and leaves too much implicit in the encoding, therefore making the encoding less useful. I just haven't figured out a remedy that doesn't create other aches and pains.
—
Reply to this email directly or view it on GitHub.

I think we're in agreement: additional elements inside <note> for head, stem, and flags provide a great deal of encoding power, but power in the hands of the uninitiated they're problematic. So, encoders need guidance -- via Schematron, documentation, etc.
I also agree that mei.all is over-used and that it would be good to make some "pre-cooked" customizations available, but this is not a complete solution to the issue. (I hesitate to call it a problem as it's part of the design of profile-based systems like MEI and TEI.)
When the customization service is back up, it will be technically easy to create sub-set schemas. The major question is where to put them and how to maintain them.  Should creating these be part of the build system the way MEI-cmn, -neumes, and -mensural are now?  Which customizations should we make?  What gets left out?

You're right, we're in agreement. It seems we've gone a long way in this ticket, and I hardly remember what actually started this discussion. Maybe someone who's more familiar with all these possibilities can move this into a separate ticket, with a more appropriate title?
What I would hope to get is a simplified version of roma, that is, a website where the user gets a very brief explanation of the purpose of each module, and a toggle button to turn on or off that module. Some presets can be provided (and explained), but this should be rather simple to implement – both the user interface and the "backside preparation" of the corresponding scheme. However, we don't need to rush this, I'd say. Let's get straight with the next release first…
Am 07.07.2015 um 17:27 schrieb pe-ro<EMAIL_ADDRESS>
I think we're in agreement: additional elements inside  for head, stem, and flags provide a great deal of encoding power, but power in the hands of the uninitiated they're problematic. So, encoders need guidance -- via Schematron, documentation, etc.
I also agree that mei.all is over-used and that it would be good to make some "pre-cooked" customizations available, but this is not a complete solution to the issue. (I hesitate to call it a problem as it's part of the design of profile-based systems like MEI and TEI.)
When the customization service is back up, it will be technically easy to create sub-set schemas. The major question is where to put them and how to maintain them. Should creating these be part of the build system the way MEI-cmn, -neumes, and -mensural are now? Which customizations should we make? What gets left out?
—
Reply to this email directly or view it on GitHub.

I have thought about a customization service where you can turn on/off modules. It would be a bit tricky since you would have to generate the ODD customization file, which would mean likely starting with the MEI-all template and then automatically commenting the disabled modules via an XSLT.

Yeah, I figure that’s how it has to work.  Having a look at the TEI process probably wouldn’t hurt, too.

I'm happy to write that XSLT. It would require some parameters from the website, indicating which modules to drop. You just need to specify in which way it is most comfortable for you to pass along that info. The task should be simple enough to be doable with XSLT1.0, if that helps for the workflow�
Am 07.07.2015 um 17:48 schrieb Andrew Hankinson<EMAIL_ADDRESS>
I have thought about a customization service where you can turn on/off modules. It would be a bit tricky since you would have to generate the ODD customization file, which would mean likely starting with the MEI-all template and then automatically commenting the disabled modules via an XSLT.
�
Reply to this email directly or view it on GitHub.

I’m not sure what you mean by starting “with the MEI-all template”.  As long as the modification is limited to turning off modules, I think it could be as simple as creating an ODD customization file that contains nothing but  elements for the desired modules.  This could be generated by applying an XSLT to the mei-source.xml file.

Hi, I'm just catching up with this discussion.
I wonder if the proposed @smuflname and/or @smuflcode should allow multiple values for combining glyphs. This may help avoiding having to match SMuFL's granularity. And it would certainly be useful for ornaments (see #241). SMuFL is uniquely concerned with the graphemic domain. We shouldn't jeopardize MEI's modelling of music notation to match SMuFL's.
I enjoyed your exchange about expressing some note properties as elements and I think I am in agreement too. Besides worrying about the uninitiated user, we should probably also keep in mind tools that read and write MEI as well. The more we add multiple ways of encoding the same thing, the more generic tools will have to either support all, or be specific about what they do or do not support. There is always ODD to the rescue, I suppose...
If new elements like <notehead>, <flag>, etc. are added to a new module, we should be specific about the module's role. Will it exist specifically to allow descriptive (probably mostly editorial) markup for these note components? Or do we imagine that it could be used for other less descriptive reasons? For example it could be used to map specific SMuFL code-points to these components (which is what I supposed got the conversation started...). Is that something that we really want? It may result in multiple ways of modelling a note without any specific descriptive reason for doing so...

Allowing multiple values in @smuflname and @smuflcode would, as you say, support combining glyphs.  I see how could work for <trill> or a generic <ornam> element, but I'm not so sure about using it on something like <note>.  Doing so could provide a "stop gap" solution, but I think we'd eventually have to deal with the cognitive dissonance it would create anyway.  In the proposals / discussion of the mensural IG, we're already seeing the need for increased granularity.  Why not allow in CMN (and beyond) as well?
Adding some new elements for the components of <note> and <chord> is not a drastically different thing -- we've already done this by allowing <accid>, <artic>, and <dot>. The element vs. attribute issue remains the same -- each one is appropriate for some uses. I think the new <notehead>, etc. elements will/should eventually "win out" mostly because they provide a higher level of granularity; that is, it becomes possible to assign attributes to them. They also provide the added benefit of being easier to handle in terms of editorial intervention -- we just have to be careful about how we deal with them.  I believe, for example, that by continuing to treat duration as an attribute, we're effectively restricting the use of <headshape> to the visual domain, especially when it's inside one of the editorial or transcriptional elements like <supplied> or <rdg>.
I don't think these new elements belong in a new module -- in fact, I believe they're revisions to the core.  With the addition of these new elements, I think we should re-think the need for and the domain assignments of many attributes.  Moving @accid, @artic, @slur, etc. to the analytical domain would encourage the use of elements over attributes and begin to eliminate the need to support 2 ways of dealing with these things (and others).  The attributes wouldn't go away; they'd just be de-emphasized.
Just to clear up any potential misunderstanding, I'm suggesting the addition of an element called <flags> (with an 'S'), not <flag>.  In other words, the element would describe the number, shape, etc. of all flags as a group.  There would not be an individual element for each flag.  Also, <flags> might be better situated as a child of <stem>, rather than directly in <note>.

@lpugin, you want to jump in here?

It seems to me that the SMuFL codepoints and the introduction of new elements are two different things (even though not completely unrelated, I agree). I don't think we need to rush for the SMuFL addition. Maybe we should wait until we have a clearer idea on what to do with it. By introducing the topic at MEC we wanted to make sure we do not duplicate things that are already defined in SMuFL. The noteheads example is a good one.
Concerning the introduction of new elements, my view on this is that I would introduce them only when they are needed to represent something that cannot be done with attributes. When it comes to encode different "version" (e.g., different noteheads), I would prefer to just move up the split to a higher level as suggested by @pe-ro . That is,
<app>
  <rdg>
    <note dur="4" headshape="circle" />
  </rdg>
  <rdg>
    <note dur="4" headshape="diammond" />
  </rdg>
</app>

Instead of
<note dur="4">
  <app>
    <rdg>
      <headshape value="circle" />
    </rdg>
    <rdg>
      <headshape value="diammond" />
    </rdg>
  </app>
</note

I get where you're coming from, Laurent, but (and here we go with the interconnectedness of all these things), if we consider the needs of the black mensural notation crowd (and the not-yet-created postmodern notation IG), there will either have to be an increase in the number of elements or an explosion in the number of attributes for visual qualities.  My thinking is that a small increase in the number of elements (with added attributes) is better than a large increase in the number of attributes on existing elements. The fact that it makes MEI and SMuFL mesh better is another point in its favor.

I'll chime in to say I feel a bit uneasy about favouring sub-element encoding over attribute encoding. One of the best design features of MEI is, in my mind, the clear separation between the object and an object's properties via the use of elements/attributes where appropriate. This makes MEI much more human-readable and easy to understand.
I do undertand the need to talk about certain features as their own object (stems, flags, accidentals, etc.). However, I would really stress the need for caution here -- as I understand it, the use of attributes was purposefully chosen for specific reasons, and making them second-class citizens would be a step backwards in many ways.

I whole-heartedly agree. We are in a dilemma here, having to balance quite different expectations and requirements. We probably all agree that in most cases, attributes will be absolutely sufficient, but we also recognize that there are cases where additional granularity is needed. At the same time, it seems like a good idea to use one approach (either attributes or elements) consistently throughout one project, since this makes it much easier to chew these files with an application. However, my experience is that this sometimes just doesn't work, at least not in projects that do more or less manual encodings of sources instead of generating the encodings by OMR or from an existing dataset. The problem there is that you ultimately know your encoding guidelines when you're done, not when you start. Part of the deal is that you revise your guidelines, and adjust them to the issues you encounter while working with the sources. In this scenario, you go back and forth between different encoding concepts anyway, and sometimes just for one processing step in the middle.
I don't believe that this is a solution for every project, but MEI allows to combine encoding concepts (i.e. "let's do ties as attributes as often as possible, but use an element when there is something to be said about a particular tie"). It is not upon MEI to prioritize any of the existing encoding models � we can only provide arguments for their applicability in specific situations, i.e. provide guidance. If people decide to use MEI like MusicXML (with all these elements, we're getting there�) for a simple "Mary had a little lamb", it's their decision � even if (or if not?) we all clearly prefer the attributes we had so far. We can provide some arguments, but the decision is ultimately not ours � given we decide that there's a general need for those elements in all MEI, not just in the mensural part.
Some more thoughts on the model:
From my Beethoven perspective, it seems half-hearted to do only  instead a . If we encounter a situation where one flag is added to an 8th, potentially in a different medium, attributes on one combined element don't help much. If this requires to replace one  with another , I could equally well go up another level and replace the .
Putting the / on a stem seems reasonable. In case we decide to do , we could require them to be in order (from the closest to the note head to the most distant or vice versa). However: Could we imagine a situation where a composer just wrote some flags, without a stem? Where would it appear then � in , or in a  with no other information provided?
The same problem of placement arises for stems. Mr. Beethoven often wrote nothing but stems � no notehead on either end. I'm sure other composers did that as well. While in our project, we decided to not mimic this level of openness in the MEI (but instead provide our interpretations, linked back to the shapes traced with SVG), others may want to do that. What scares me is that we're starting to decompose MEI as "music encoding" format, turning it more and more into a "graphics encoding" format. Like I said earlier, in Beethoven, we're effectively replacing the complete  when the duration changes. This is something we've been discussing for quite some time (and still question now and then), but I believe it's just a matter of perspective: Do we try to transcribe the source as it stands, or do we provide an interpretation of it? At the level of complexity that many of Beethoven's manuscript offer, these things turn out to be different, and we clearly decided to do only the latter with MEI, and delegate the first to SVG. While the scriptural intervention might have been minimal, our interpretation is something quite different � an 8th instead of a quarter. However, they still refer to the same graphical object(s) on the page, and I could retrieve them from our encoding.
To make a long story short � while I see great benefits in having those additional elements also in CMN, I still hesitate to include them. In our project, we considered the addition of such elements, and clearly decided against them, because they would bloat our data model very drastically. However, I don't want to restrict others to a decision that was made for one very specific project. All I can say is that at this point we would probably not use the proposed elements�
jo
Am 09.07.2015 um 09:57 schrieb Andrew Hankinson<EMAIL_ADDRESS>
I'll chime in to say I feel a bit uneasy about favouring sub-element encoding over attribute encoding. One of the best design features of MEI is, in my mind, the clear separation between the object and an object's properties via the use of elements/attributes where appropriate. This makes MEI much more human-readable and easy to understand.
I do undertand the need to talk about certain features as their own object (stems, flags, accidentals, etc.). However, I would really stress the need for caution here -- as I understand it, the use of attributes was purposefully chosen for specific reasons, and making them second-class citizens would be a step backwards in many ways.
�
Reply to this email directly or view it on GitHub.

Jo

Do we try to transcribe the source as it stands, or do we provide an interpretation of it?

Your question reminds me to Elena's keynote at MEC, where she clearly put her penny down beside the latter. On the other hand, the question is where is the border line between the two? I always wondered about the post-CMN notation in MEI, and I am glad that Perry mentioned "the not-yet-created postmodern notation IG". The further we go from CMN, the more important the graphical nature of the score becomes - think of graphical scores at the extreme!
These are just thoughts though, with admittedly little argumentative value regarding the debate whether it's useful introduce stem elements in the CMN module.
My gut feeling is that they would be useful. Re  vs.  debate, would you think a structure like:
<flags>
  <flag/>
  <flag/>
</flags>

would be an overkill? (Child elements obviously optional, and attributes on flags could also be used instead)

Am 09.07.2015 um 11:42 schrieb Zoltan Komives<EMAIL_ADDRESS>
Jo
Do we try to transcribe the source as it stands, or do we provide an interpretation of it?
Your question reminds me to Elena's keynote at MEC, where she clearly put her penny down beside the latter. On the other hand, the question is where is the border line between the two?

I strongly believe there is no natural border, and it is upon us to draw the one we want – which makes it so hard to decide…

I always wondered about the post-CMN notation in MEI, and I am glad that Perry mentioned "the not-yet-created postmodern notation IG". The further we go from CMN, the more important the graphical nature of the score becomes - think of graphical scores at the extreme!

Well, there is certainly room in MEI to cover parts of that, but I doubt that we can come up with an encoding standard for non-recurring notational systems, made up for just one score. I believe that if we want to do so, it becomes even more important to work with abstractions, that is, not encode the appearance (at least not with MEI), but instead its "meaning" (whatever that means…). However, drawing a border between semantics and graphics in this area isn't simple either…

These are just thoughts though, with admittedly little argumentative value regarding the debate whether it's useful introduce stem elements in the CMN module.
My gut feeling is that they would be useful.

same for me – I'm just concerned about the potential (bad) consequences, and if they justify to take this approach in areas where we seem to have no real-world use-case yet. We could introduce it for mensural, but wait for other repertoires…

Re vs. debate, would you think a structure like:

would be an overkill? (Child elements obviously optional, and attributes on flags could also be used instead)

fine with me.

—
Reply to this email directly or view it on GitHub.

Your question reminds me to Elena's keynote at MEC, where she clearly put her penny down beside the latter [rv: to provide an interpretation]. On the other hand, the question is where is the border line between the two?

Perhaps unsurprisingly, given that Elena is my teacher, but I argue that text encoding is always a tool for formalizing interpretation. The encoding always crystallizes an interpretation, regardless of whether the intention is transcribing the source as it stands (rather: as you think it stands) or to provide a more hands on interpretation of it. It is impossible to create an unbiased model of a cultural object, even more than it is impossible to take an unbiased facsimile photo of it.
A stem is a stem because we decide it is a stem and not a random mark on the page. You have to argue for that interpretation even if it's obvious. Your encoding formalizes your conscious choice.
I'm not opposed to adding elements in principle, but there's plenty more to consider. A couple of things that come to mind:

note property attributes should really be encouraged over elements, so they should probably be in a module that is turned off by default. I agree that MEI wants to be agnostic about which structures to use and in what combination, but this may be the one case where we can't be. These elements should be used if they're truly needed. Maybe a primary source encoding module?
this will be a change that messes up backwards compatibility. Now we have <dot/> for very similar reasons and dots can be mixed with articulations, etc. in the body of <note/>. So to be consistent, we should model <flag/> after <dot/>. But that would result in a disorganized body. Or we'll have to at least have <dots/> if we go with <flags/>. Or we'll have to create new elements for organizing the different components of the note. Either way, the current status of <dot/> will have to change in a non-backwards compatible manner. Or is there another way that I'm not seeing here?

Raff, I see your reasoning here re: <flag> vs. <flags>, but I still think that may be a step too far.
I agree that we should investigate the possibility of putting these new "granularity" elements in some kind of module so that they can be isolated from "core" MEI.
I'm not in a great rush to take this path; i.e., going toward a more element-centric encoding, but in light of the fact that MusicXML and SMuFL are "teaming up" so to speak, we have to react if we expect to play nice with the commercial sector.  And as I stated earlier, addressing the needs of additional uses; e.g., black mensural and lute tablature, is a significant factor.
We can talk this thing to death or we can start doing something about it -- I suggest the latter.  But, I for one am "dead in the water" when it comes to creating test customizations without a working customization service.  Let's table this discussion until that's working again and move on to other issues.

We can open it again if necessary

Now that the customization service is humming along again (thanks to Andrew and Raffaele), I'd like to reopen this issue and provide a customization that supports SMuFL. Can I attach files here?

The markup below demonstrates the SMuFL capabilities I've been talking about. <note> now allows <notehead> and <stem> children.  Schematron is used to constrain the use of <notehead> to a single occurrence.  Also, while <stem> can occur as a descendant of <app>, <notehead> cannot.  In addition, <stem> can only be used when it is a descendant of <note>, meaning that it can occur within <app>, but only if the <app> is within <note>.  <flags> is only allowed as a child of <stem>, making it impossible to describe the difference between readings as one involving only stems, in the same way that one can't describe the difference between readings as one between noteheads alone.  In both these cases, one is forced to utilize <note> elements, the basic idea being that if notes differ with respect to their noteheads (where there is potential for difference in semantic meaning), they are different beasts.
In addition to the changes to support SMuFL, @headshape on <note> has been pulled apart into multiple attributes -- @head.shape, @head.fill, @head.fillcolor, @head.mod, @head.visible, and @head.color (in keeping with the issue that addresses a revamping of data.HEADSHAPE).  With respect to color, the idea is that @color affects the color of all parts of the note, unless a more specific attribute is used. So, @head.fillcolor would change the color of the inside of the note, leaving the outline and the stem in the original color.  If @head.fillcolor is used in the absence of @color then a default color is presumed.
Not every attribute available on <notehead> and <stem> is available on <note> and <chord>.  The intention was to continue capturing the same data that we've been gathering (albeit with more attributes now) and to employ the same strategy as that used for <accid>, <artic>, and <dot>; that is, if you want to capture more detail than is allowed using attributes, then you must employ child elements.  For example, in the same way that if you want to specify the color of an accidental you have to use <accid> instead of @accid, if you want to capture the color of a stem, then you must use <stem> and not the @stem attributes. **NB: I just noticed that <stem> isn't allowed as a child of <chord>, but I think that's easily remedied.
Only a single <flags> child is allowed within <stem>; however, its attributes are allowed to take multiple values. This is in keeping with the way<EMAIL_ADDRESS>is handled.  The number of values should agree with the number of flags.  Although I haven't yet been able to come up with one yet, it would be great to have a Schematron rule that makes sure that if any attribute on <flags> has multiple values, then all attributes have to have the same number of values.  I'd appreciate help with this rule, as I don't have the slightest idea how to write it, but I think it involves the use of SQL.
Looking at the figured bass markup at the end of the example, you'll see that there are a couple of ways of using SMuFL within text. One is to use the Unicode character entity for the thing you want to insert (ਖ਼ in this example, although I'm not sure if this is the proper way to address characters in the PUA).  Another option is to use the <symbol> element (which can now appear within text). The advantage of this method is that you can then use the full range of attributes on <symbol>.
You'll also notice in this example a nod toward supporting black mensural notation. For example, flags/@shape allows values appropriate for this repertoire. What you can't see (without access to the schema that the example validates against), is that 'stem/@dirsupports a much expanded set of values -- "up, down, left, right, ne, se, sw, and nw" -- that when taken in combination withstem/@posallow for virtually every kind of weird stem that one can imagine being given for a single note.  (Stems for chords containing augmented unisons is yet to be addressed.) Multiple stems found in this repertoire are supported by allowing multiple occurrences ofwithin`.  My plan is to restrict this for CMN in the mei-CMN customization.
I've tried to consider the objections raised during the discussion while also moving toward a level of granularity that makes it possible to intuitively support SMuFL.  I don't believe some kind of multi-valued attribute, say on <note>, that captures any/all pertinent SMuFL code points is particularly "intuitive". I don't think I've added any new complexity that wasn't already inherent in the system once <note> and the children of <app> were allowed to contain <accid>, <artic>, and <dot>.
I'm eager to hear any comments.  And, even though we're supposed to keep the addition of new features to a minimum, I'd like to put this into the next release.  This would put us miles ahead of our competitors in the support of SMuFL.  ;-)
<staff xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.music-encoding.org/ns/mei">

  <layer>
    <chord stem.dir="up" stem.mod="1slash" stem.len="7.5mm">

      <note head.shape="backslash" head.fill="solid" head.fillcolor="purple" head.mod="paren"
        head.visible="false" stem.pos="right" stem.dir="down" stem.len="7.5" stem.mod="1slash"
        stem.with="above" artic="acc bend" accid="f" color="blue" colored="true" enclose="brack"
        smufl.code="#xE1D6">

        <notehead color="aqua" mod="circled" rotation="45" shape="square" smufl.code="#xE0AB"/>
        <!-- Schematron prevents notehead from occurring more than once within note -->
        <!-- <notehead/> -->
        <stem color="black" pos="center" dir="down" len="7.5" mod="1slash" visible="true"
          with="above" smufl.code="#xE219">
          <!-- Need constraint that makes sure all flag's attrs have multiple values if one attr has multiple values -->
          <flags color="fuchsia green" fillcolor="gray green" pos="left right" shape="straight
            hooked" smufl.code="#x1D1EA" fontname="BravuraText"/>
        </stem>
        <stem color="red" pos="center" dir="up">
          <flags pos="end" color="red"/>
        </stem>
        <accid />
        <dot fontname="myOwnFont" fontsize="33"/>

        <app>
          <rdg>
            <dot/>
            <stem/>
          </rdg>
        </app>

      </note>

    </chord>

    <app>
      <rdg>
        <dot/>
        <!-- Schematron prevents stem from occurring unless it's the descendant of a note -->
        <!-- <stem/> -->
      </rdg>
    </app>

    <harm tstamp="1">
      <fb>
        <f>
          <choice>
            <orig><rend fontname="Bravura"><symbol smufl.code="#xEA59" smufl.name="figbass5Raised2"
                /></rend></orig>
            <reg><rend fontname="Bravura">ਖ਼</rend></reg>
          </choice>
        </f>
      </fb>
    </harm>

  </layer>

</staff>

Hi Perry, looks like terrific work. A few comments and questions:

Schematron is used to constrain the use of  to a single occurrence.

Why is Schematron needed for this?

the basic idea being that if notes differ with respect to their noteheads (where there is potential for difference in semantic meaning), they are different beasts.

I agree with this and I think it helps to avoid proliferation of unnecessary add/rdgs

In addition to the changes to support SMuFL, @headshape on <note> has been pulled apart into multiple attributes -- @head.shape, @head.fill, @head.fillcolor, @head.mod, @head.visible, and @head.color

This worries me and I see it as a regression. It's very procedural markup and I wish this information lived outside of MEI in a CSS-like document. This also includes other attributes like @fontname. I didn't mind this kind of markup on <rend> because MEI is not for text encoding, so some procedural markup in that domain is tolerable. But this is procedural markup in the music notation and I don't like it. I understand the pressure to support SMuFL ASAP, but it shouldn't come at the cost of descriptive markup. I'm also not a fan of having @sumfl. attributes and I think a <symbol>-based solution is way better, but it looks like I'm alone in this so be it :)

The number of values should agree with the number of flags. Although I haven't yet been able to come up with one yet, it would be great to have a Schematron rule that makes sure that if any attribute on  has multiple values, then all attributes have to have the same number of values.

It sounds doable with XPath, something like (it may be a report rather than assert, I always mix them up):
<sch:rule context="mei:flag">
   <sch:assert test="
        if (count(distinct-values(
            for $att in @* return
                 count(tokenize($att, ' '))
            )) > 1)
        then false()
        else true() ">All attributes must have the same number of values</sch:assert>
</sch:rule>

use the <symbol> element (which can now appear within text)

Hurrah! This makes things a bit easier for <ornament>, too (see #254).

stem/@dir supports a much expanded set of values -- "up, down, left, right, ne, se, sw, and nw"

Honestly, I wouldn't mind having these values added to the datatype for @place. The question is, though, where do we stop? E.g. "I want s-se".

To conclude, I think there are parts of this customization that do not belong to MEI, but rather to an external CSS-like specification. I'm referring in particular to the proposed attributes on note to describe color, fill, visibility, and font face . Why don't we work together on a CSS for MEI instead? It could be expressed in XML (as an MEI module, say), but it needs to be stand-off and replaceable.
On the other hand, the segmentation into multiple elements for <note> is still grounded in the descriptive domain, and it will make more detail encoding possible, so I welcome those upgrades.

Thanks.  I put some effort into it.  :-)
I used schematron to constrain the occurrence of <notehead> in order to simplify the content model of <note>.  The content model of <note> is kept simple (in DTD-like syntax):
(notehead | stem | model.noteModifierLike | model.verseLike | model.sylLike | appLike | model.editLike | model.transcriptionLike)*
so that the order of the content isn't significant. But, the number of occurrences of any <note> child  elements isn't controlled.  Hence, the need for schematron.  The answer to the more general question, Why should a note have only one notehead? is that if there's more than one notehead on a stem, then MEI calls that a "chord".  :-)  A similar principle is at work with regard to <stem>; that is, in CMN a note can only ever have 1 stem.  A note with 2 stems is an indication of overlapping "layers".  A schematron rule for this must be added in the CMN customization, however.  Adding it in the MEI "core" would disallow the use of multiple stems in mensural notation when using the mei-all schema.
You're definitely not alone in your desire to encourage people to use descriptive markup. But, there are instances where a description (and I use that word intentionally) of the physical attributes of the notation is the best that can be done.  I still see this as descriptive markup.  Because music data objects, like <note> have no content to wrap something like <rend> around (and wrapping <rend> around <note> leads to an insanely complex data model), the attributes allowed on <rend> must be moved up in the hierarchy to the object itself (in this case, <note>).  The same thing happens on <artic>, <accid>, and so on and so on ... In fact, placing these attributes on the object reinforces the idea that their content is descriptive and not necessarily renditional.  I would never encourage someone to use these attributes to describe intended output.  That is the province of a stylesheet or style language.
You're also not alone in your desire to encourage the use of the @altsym/symbolDef approach.  I didn't put it into this proposal, but my intention is to also expand the role of <symbolDef> by making it more like TEI's <charDecl> element.  That is, using @altsym to point to a <symbolDef> which, in turn, either references a code point in SMuFL (or similar system), provides a vector graphic (in SVG), or describes the symbol using text.  The @smufl.* attributes are just a short cut for those who don't want the overhead of using <symbolDef> for common cases.
Re: schematron for the attributes on flags -- the more I think about this, the less desirable it becomes.  I'm inclined to leave it out for now.  In any case, distinct-values won't work because some flags might be the same color (for instance) -- color="blue red blue" is 3 values, not 2. :-)
I'm inclined not to add the extra values allowed by stem/@dir to @place because @place is exclusively for specifying the relationship between an object and its staff -- what does it mean to say that an accidental is southwest of the staff?  As for where to stop, I think the current set of compass points is generous.  Any other direction/vector could be expressed as rotation from "north".  But that's for a much later version of MEI. :-)

Re: schematron for the attributes on flags -- the more I think about this, the less desirable it becomes. I'm inclined to leave it out for now. In any case, distinct-values won't work because some flags might be the same color (for instance) -- color="blue red blue" is 3 values, not 2. :-)

No, it will work: distinct-values() is applied to the count of tokens, not to the values. Basically given two attributes with values "a a" and "b c", the XPath first counts the number of values for each attribute and returns a sequence: (2, 2). Then distinct-values() makes sure that all counts are the same: distinct-values((2, 2)) returns 2. A final check makes sure that distinct-values() only returned one value (so the attributes have the same number of token values).
If we had two attributes with values "a b" and "c", the count would have returned a sequence of (2, 1), thus distinct-values() would return (2, 1) and cause the final check to fail.
I'm sure there's a less complex solution, but this should do :)

I'm inclined not to add the extra values allowed by stem/@dir to @place because @place is exclusively for specifying the relationship between an object and its staff -- what does it mean to say that an accidental is southwest of the staff?

But what about an ornament that is placed to the left of the note? This makes me wonder if @place would be better defined as relative to the element it is placed on, rather than the staff.
For the rest, I think I'm OK with the proposal, unless someone else has other views on the procedural/descriptive debate... @kepper?
Have you been working on a branch for this ODD? Maybe you can send a Pull Request so that we can look at the code too? Happy to help through the process via email, if needed!

Ok, I'll take your word on the distinct-values() issue.  Still, I think this particular schematron constraint isn't necessary.

Closed by commit de72af3e7595ccb6f3e9ae6da1f0cddaf9e03d66


fix/allow service to exit

relates to https://github.com/OpenVoiceOS/ovos-microphone-plugin-alsa/issues/7
instead of blocking waiting for ctrl+c press the service should crash loudly on error

systemd or container engines will take care of the restart if the service crashes. :+1:


Optimize memory compsumption

This fixes #249:

Add garbage collection
Change binary serialization instead of JSON
Tweaks badger configuration to avoid memory-mapping log files.

Moving to binary serialization drastically improves memory usage.
I tried to run 3 different daemons with the same configuration and by repeating the same operations:

derive 5 fee addresses and fund each of them with 10 utxos (50 in total)
derive 5 addresses for a market and fund the market with 1 utxo per each address

The first daemon was the master version and the datadir, overall, ended occupying 4.7MB on disk.
The second daemon had all the changes but the binary serialization and its datadir was 3.7MB.
The last daemon had all the changes and took only 315KB on the disk.
Please @tiero, review this.

We may want to use compression as well?


Does it support 'Text-to-Speech Streaming' yet?

Thank you for building it,
Does it support 'Text-to-Speech Streaming' yet?, I don't see the guide to setup for 'streaming'
https://developers.deepgram.com/docs/tts-websocket

Hey @paulVu you are right it's not yet implemented, I missed it's release, I'll look into it :)

@paulVu now it does in 3.0.0 :)
Check deepgram.speak.live() or deepgram.speak.liveSpeaker()

Thank you so much, you are rock


ArrowKeyStepper: expose onKeyDown as a property

Hello. We're looking to use ArrowKeyStepper in an interactive product choosing modal and want to experiment with different navigation methods, in particular:

Navigation with different keys (ws, tab)
Capturing user choice with enter key

ArrowKeyStepper is really close code-wise to solve this usecase, but isn't flexible enough.
Proposal
Introduce new prop onKeyDown. For example:
onKeyDown?: (
  event: KeyboardEvent,
  setScrollState: (row: number, column: number) => void
)

Existing onKeyDown implementation would become the default, but users could swap out the implementation wholly.
setScrollState function could be used by users inside the function to force navigation. Alternatively, to use this new prop you would need to use a controlled component.

+1, this breaks global keydown listeners.