ERROR: no clang -ftime-trace .json files found under

I am not able to get simple trace running successfully through this tool. From a freshly cloned and built tree, I run:
# ./ClangBuildAnalyzer  --start /tmp
Build tracing started. Do some Clang builds with '-ftime-trace', then run 'ClangBuildAnalyzer --stop /tmp <filename>' to stop tracing and save session to a file.
# clang <various options...> -o /tmp/main.cc.o -c /tmp/main.cc -ftime-trace -ftime-report
ls /tmp
# ls /tmp/main*
/tmp/main.cc.json  /tmp/main.cc.o
# ./ClangBuildAnalyzer --stop /tmp /tmp/report
Stopping build tracing and saving to '/tmp/report'...
ERROR: no clang -ftime-trace .json files found under '/tmp'.

Seems to find the json file and fail while parsing it (within ParseBuildEvents in the code). The clang version is 11/head, downloaded and built today. Chrome can read and display the file successfully within chrome://tracing.
Any ideas? My apologies if I'm missing something obvious, and thank you for producing this tool and -ftime-trace. Incredibly useful.

Can you share the /tmp/main.cc.json file?

Unfortunately, no.. I will see if I can reproduce the issue with something isolated and update the post.
On Sun, Apr 26, 2020, at 5:41 AM, Aras Pranckevičius wrote:

Can you share the /tmp/main.cc.json file?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/aras-p/ClangBuildAnalyzer/issues/45#issuecomment-619543594, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIQDPFCF4SGVX7XTDOGHUH3ROQTW7ANCNFSM4MRANZIQ.

test.json:
{"traceEvents":[{"pid":43147,"tid":43147,"ph":"X","ts":1905,"dur":1568,"name":"Frontend"},{"pid":43147,"tid":43147,"ph":"X","ts":5589,"dur":639,"name":"RunPass","args":{"detail":"Expand Atomic instructions"}},{"pid":43147,"tid":43147,"ph":"X","ts":5588,"dur":712,"name":"OptFunction","args":{"detail":"main"}},{"pid":43147,"tid":43147,"ph":"X","ts":6303,"dur":535,"name":"OptFunction","args":{"detail":"main"}},{"pid":43147,"tid":43147,"ph":"X","ts":5433,"dur":1565,"name":"OptModule","args":{"detail":"test.cc"}},{"pid":43147,"tid":43147,"ph":"X","ts":5410,"dur":1604,"name":"CodeGenPasses"},{"pid":43147,"tid":43147,"ph":"X","ts":3534,"dur":3537,"name":"Backend"},{"pid":43147,"tid":43147,"ph":"X","ts":11,"dur":7270,"name":"ExecuteCompiler"},{"pid":43147,"tid":43148,"ph":"X","ts":0,"dur":7270,"name":"Total ExecuteCompiler","args":{"count":1,"avg ms":7}},{"pid":43147,"tid":43149,"ph":"X","ts":0,"dur":3536,"name":"Total Backend","args":{"count":1,"avg ms":3}},{"pid":43147,"tid":43150,"ph":"X","ts":0,"dur":1622,"name":"Total Frontend","args":{"count":2,"avg ms":0}},{"pid":43147,"tid":43151,"ph":"X","ts":0,"dur":1603,"name":"Total CodeGenPasses","args":{"count":1,"avg ms":1}},{"pid":43147,"tid":43152,"ph":"X","ts":0,"dur":1585,"name":"Total OptModule","args":{"count":2,"avg ms":0}},{"pid":43147,"tid":43153,"ph":"X","ts":0,"dur":1299,"name":"Total OptFunction","args":{"count":3,"avg ms":0}},{"pid":43147,"tid":43154,"ph":"X","ts":0,"dur":1258,"name":"Total RunPass","args":{"count":61,"avg ms":0}},{"pid":43147,"tid":43155,"ph":"X","ts":0,"dur":384,"name":"Total CodeGen Function","args":{"count":1,"avg ms":0}},{"pid":43147,"tid":43156,"ph":"X","ts":0,"dur":73,"name":"Total PerFunctionPasses","args":{"count":1,"avg ms":0}},{"pid":43147,"tid":43157,"ph":"X","ts":0,"dur":26,"name":"Total PerModulePasses","args":{"count":1,"avg ms":0}},{"pid":43147,"tid":43158,"ph":"X","ts":0,"dur":4,"name":"Total PerformPendingInstantiations","args":{"count":1,"avg ms":0}},{"cat":"","pid":43147,"tid":43147,"ts":0,"ph":"M","name":"process_name","args":{"name":"clang-11"}},{"cat":"","pid":43147,"tid":43147,"ts":0,"ph":"M","name":"thread_name","args":{"name":"clang"}}],"beginningOfTime":1587922998882842}

test.cc:

int main(int argc, const char** argv) {
  return 0;
}

steps:
# /local/ClangBuildAnalyzer/ClangBuildAnalyzer  --start /tmp
Build tracing started. Do some Clang builds with '-ftime-trace', then run 'ClangBuildAnalyzer --stop /tmp <filename>' to stop tracing and save session to a file.
# /local/ClangBuildAnalyzer/ClangBuildAnalyzer  --start .
Build tracing started. Do some Clang builds with '-ftime-trace', then run 'ClangBuildAnalyzer --stop . <filename>' to stop tracing and save session to a file.
# /build/llvm/bin/clang -o test -c test.cc -ftime-trace
# /local/ClangBuildAnalyzer/ClangBuildAnalyzer  --stop . report
Stopping build tracing and saving to 'report'...
ERROR: no clang -ftime-trace .json files found under '.'.

Ah seems that latest Clang/LLVM head has changed the format a bit, your repro was very helpful. Should be fixed now, thanks!

This fixes it for me. Thank you!


Add terraform module

This Pull Request adds a terraform module to manager all features related to Google Cloud Storage

Try to use existing module
Clarify on terraform version ( may be readme.md and version.txt )
How to deploy this infrastructure
Environment separation ( terraform.tfvars and state.tf )


Unable to scroll to Pin/Delete buttons, as overflow not handled

When a lot of content is used, the overflow is not handled well:

Pin and Delete buttons are cut from view.
If you have even more content, the buttons disappear from view.

Thanks for the report! Could you please tell me what display size you're using?


Feature/pmd ruleset

@rs22 Can I just move the .eslintrc.json file to the parent directory without it destroying any part of the frontend build system or the git plugin?

You can't move this file into parent folder. That's IMHO wrong. The NodeJs project is in /frontend and this Configuration is specific for this.


Updated deprecated links in elasticsearch.rst

Summary
Updated deprecated links in elasticsearch.rst
Ticket Link

NA

Hello @Rutam21,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.


Example curl doesn't work

 $ curl http://localhost:5000/api --header 'content-type: application/json' --data '{text: "This is a text that I want to be analyzed."}' -X POST
{"message": "The browser (or proxy) sent a request that this server could not understand."}

I assume you meant something like this instead, which does work:
 $ curl http://localhost:5000/api --header 'Content-Type: application/json' --data '{"text": "This is a text that I want to be analyzed."}' -X POST
{"numOfSentences": 1, "lang": "en", "performance": [0.18333840370178223], "sentences": [[{"pos": "DET", "email": false, "ner": "", "stop": true, "token": ...

Right, thanks for pointing that out! Damn these copy-paste mistakes...


add HAFAS mgate.exe endpoints

still to do:

[ ] add required fields

[x] data/at/oebb.json
[ ] data/at/vkg.json
[ ] data/at/vvt.json
[ ] data/be/nmbs-sncb.json
[ ] data/ch/sbb-cff-ffs.json
[ ] data/ch/zvv.json
[ ] data/de/avv.json
[ ] data/de/bvg.json
[ ] data/de/db-busradar-nrw.json
[x] data/de/db.json
[ ] data/de/db-hafas-query.json.json
[ ] data/de/db-sbahn-muenchen.json
[ ] data/de/hvv.json
[ ] data/de/insa.json
[ ] data/de/invg.json
[ ] data/de/mobil-nrw.json
[ ] data/de/nahsh.json
[ ] data/de/nvv.json
[ ] data/de/rmv.json
[ ] data/de/rsag.json
[ ] data/de/saarfahrplan.json
[ ] data/de/svv.json
[ ] data/de/vbb.json
[ ] data/de/vbn.json
[ ] data/de/vmt.json
[ ] data/de/vos.json
[ ] data/de/vrn.json
[ ] data/de/vrr-efa.json.json
[ ] data/de/vsn.json
[ ] data/dk/rejseplanen.json
[ ] data/ie/iarnrod-eireann.json
[ ] data/lu/cfl.json
[ ] data/lu/mobiliteit-lu.json
[ ] data/us/bart.json
[ ] data/us/cmta.json

[ ] add optional fields like attribution

Nice! I'd say we can land this even if still incomplete and fill the gaps as the remaining details become available. I have been working on adjusting the coverage format in KPublicTransport, so it should get easier to merge that into here.
Regarding the file names: KPublicTransport uses the ISO-3166-2 region code as an additional namespace level next to the country code, for local operators. This helps to disambiguate e.g. "AVV" in Germany (Aachen vs. Augsburg). That could of course also be done by other means, but IMHO something worth thinking about.

Nice! I'd say we can land this even if still incomplete and fill the gaps as the remaining details become available. I have been working on adjusting the coverage format in KPublicTransport, so it should get easier to merge that into here.
Regarding the file names: KPublicTransport uses the ISO-3166-2 region code as an additional namespace level next to the country code, for local operators. This helps to disambiguate e.g. "AVV" in Germany (Aachen vs. Augsburg). That could of course also be done by other means, but IMHO something worth thinking about.

Regarding the file names: KPublicTransport uses the ISO-3166-2 region code as an additional namespace level next to the country code, for local operators. This helps to disambiguate e.g. "AVV" in Germany (Aachen vs. Augsburg). That could of course also be done by other means, but IMHO something worth thinking about.

I sounds tempting, but there are quite a lot of endpoints that don't cover a single county/region, either less or far more (e.g. VRN/RMV, VBB/BVG, NVV). I think we could go arbitrarily fine-grained here, so I just used the endpoint's provider's abbreviation for now.

Regarding the file names: KPublicTransport uses the ISO-3166-2 region code as an additional namespace level next to the country code, for local operators. This helps to disambiguate e.g. "AVV" in Germany (Aachen vs. Augsburg). That could of course also be done by other means, but IMHO something worth thinking about.

I sounds tempting, but there are quite a lot of endpoints that don't cover a single county/region, either less or far more (e.g. VRN/RMV, VBB/BVG, NVV). I think we could go arbitrarily fine-grained here, so I just used the endpoint's provider's abbreviation for now.

@em0lar & @n0emis I will just tag you here, since you have created pyhafas. Once this is merged, kpublictransport & hafas-client will pull their API endpoint definitions (or at least the basic details about them) from this repo; Others like public-transport-enabler, TripKit & BahnhofsAbfahrten/marudor.de might follow. More background info: https://github.com/public-transport/transport-apis/pull/1

@em0lar & @n0emis I will just tag you here, since you have created pyhafas. Once this is merged, kpublictransport & hafas-client will pull their API endpoint definitions (or at least the basic details about them) from this repo; Others like public-transport-enabler, TripKit & BahnhofsAbfahrten/marudor.de might follow. More background info: https://github.com/public-transport/transport-apis/pull/1

I sounds tempting, but there are quite a lot of endpoints that don't cover a single county/region, either less or far more (e.g. VRN/RMV, VBB/BVG, NVV). I think we could go arbitrarily fine-grained here, so I just used the endpoint's provider's abbreviation for now.

Right. I'd not see this as coverage information, but purely as a systematic disambiguation. OTOH I'm only aware of one practically relevant abbreviation collision within one country, and that's AVV. avv-aachen and avv-augsburg would address that sufficiently as well.
Another thing I noticed while trying to integrate this: we are using ver here, the readme calls this field version, which one do we want? ver matches the Hafas naming, version is nicer to read, I don't have a strong preference for either option.

I sounds tempting, but there are quite a lot of endpoints that don't cover a single county/region, either less or far more (e.g. VRN/RMV, VBB/BVG, NVV). I think we could go arbitrarily fine-grained here, so I just used the endpoint's provider's abbreviation for now.

Right. I'd not see this as coverage information, but purely as a systematic disambiguation. OTOH I'm only aware of one practically relevant abbreviation collision within one country, and that's AVV. avv-aachen and avv-augsburg would address that sufficiently as well.
Another thing I noticed while trying to integrate this: we are using ver here, the readme calls this field version, which one do we want? ver matches the Hafas naming, version is nicer to read, I don't have a strong preference for either option.

I'd not see this as coverage information, but purely as a systematic disambiguation.

Makes sense. Let's go with the systematic distinction then and store/name endpoints by their providers "center of operation".

we are using ver here, the readme calls this field version, which one do we want? ver matches the Hafas naming, version is nicer to read, I don't have a strong preference for either option.

I've picked ver so far because its possible values are HAFAS-specific anyways, just like with client or auth.

I'd not see this as coverage information, but purely as a systematic disambiguation.

Makes sense. Let's go with the systematic distinction then and store/name endpoints by their providers "center of operation".

we are using ver here, the readme calls this field version, which one do we want? ver matches the Hafas naming, version is nicer to read, I don't have a strong preference for either option.

I've picked ver so far because its possible values are HAFAS-specific anyways, just like with client or auth.

I've picked ver so far because its possible values are HAFAS-specific anyways, just like with client or auth.

Ok, updated #8 to follow that, and fixed existing documentation and data in #9.

I've picked ver so far because its possible values are HAFAS-specific anyways, just like with client or auth.

Ok, updated #8 to follow that, and fixed existing documentation and data in #9.

Nearly all files in this pull request specify coverage with country codes instead of geojson polygons. While this can simplify both data maintenance and consumption (API consumers wanting to find out if a location is covered by an endpoint simply need to check whether it is in one of the listed countries using an arbitrarily coarse/accurate database of country polygons), it also means that API consumers -must- have such a database to take advantage of coverage data. Is there such a database we can refer to? If not, I'd prefer to always provide polygons. Extending our spec so we can augment them with country codes might be useful, though.
Side note: the definition for germany at https://github.com/isellsoap/deutschlandGeoJSON/blob/master/1_deutschland/4_niedrig.geo.json is already 22kB. I think we should settle for a much lower level of detail here, e.g. the rectangles already used in https://invent.kde.org/libraries/kpublictransport/-/tree/master/src/lib/networks.
Do you have different preferences or am I missing something here? If not, I'll replace the coverage country codes with polygons in the next days.

Nearly all files in this pull request specify coverage with country codes instead of geojson polygons. While this can simplify both data maintenance and consumption (API consumers wanting to find out if a location is covered by an endpoint simply need to check whether it is in one of the listed countries using an arbitrarily coarse/accurate database of country polygons), it also means that API consumers -must- have such a database to take advantage of coverage data. Is there such a database we can refer to? If not, I'd prefer to always provide polygons. Extending our spec so we can augment them with country codes might be useful, though.
Side note: the definition for germany at https://github.com/isellsoap/deutschlandGeoJSON/blob/master/1_deutschland/4_niedrig.geo.json is already 22kB. I think we should settle for a much lower level of detail here, e.g. the rectangles already used in https://invent.kde.org/libraries/kpublictransport/-/tree/master/src/lib/networks.
Do you have different preferences or am I missing something here? If not, I'll replace the coverage country codes with polygons in the next days.

Is there such a database we can refer to?

I found several, and probably there are many more:

https://github.com/mledoze/countries
https://github.com/datasets/geo-countries
https://github.com/eFrane/admin0
https://github.com/simonepri/geo-maps

These are in different states of maintenance, and handle disputes & non-UN-recognized countries/regions differently, etc. But generally speaking: Yes, there are.

If not, I'd prefer to always provide polygons.

IMO coverage polygons imply greater accuracy than what they actually convey. And once you go down this rabbit hole, you'll be very busy specifying exactly what and what not each endpoint covers. Most endpoints' coverage areas don't have "clean" borders, they have many exceptions.
Maintaining a dataset, and later on deciding to extend it, is far easier to do than having a very detailed dataset that ends up unmaintained (and therefore partially wrong). This is why I'm a bit skeptical of adding polygons for endpoints with a large (and very random) coverage area. I definitely see your point that providing polygons would make consumption a lot easier, but maybe we can find a middle ground by linking to some of these databases.
Keep in mind that, as long as a coverage area is composed of "complete" Bundesländer (country subdivisions to be exact) – which is often the case –, we could just use ISO 3166-2 codes.

Extending our spec so we can augment them with country codes might be useful, though.

As in "this shape corresponds exactly to that country"? Or as in "this shape lies entirely within that country"?

Is there such a database we can refer to?

I found several, and probably there are many more:

https://github.com/mledoze/countries
https://github.com/datasets/geo-countries
https://github.com/eFrane/admin0
https://github.com/simonepri/geo-maps

These are in different states of maintenance, and handle disputes & non-UN-recognized countries/regions differently, etc. But generally speaking: Yes, there are.

If not, I'd prefer to always provide polygons.

IMO coverage polygons imply greater accuracy than what they actually convey. And once you go down this rabbit hole, you'll be very busy specifying exactly what and what not each endpoint covers. Most endpoints' coverage areas don't have "clean" borders, they have many exceptions.
Maintaining a dataset, and later on deciding to extend it, is far easier to do than having a very detailed dataset that ends up unmaintained (and therefore partially wrong). This is why I'm a bit skeptical of adding polygons for endpoints with a large (and very random) coverage area. I definitely see your point that providing polygons would make consumption a lot easier, but maybe we can find a middle ground by linking to some of these databases.
Keep in mind that, as long as a coverage area is composed of "complete" Bundesländer (country subdivisions to be exact) – which is often the case –, we could just use ISO 3166-2 codes.

Extending our spec so we can augment them with country codes might be useful, though.

As in "this shape corresponds exactly to that country"? Or as in "this shape lies entirely within that country"?

On Tue, Jan 26, 2021 at 06:24:56AM -0800, Jannis Redmann wrote:

IMO coverage polygons imply greater accuracy than what they actually convey. And once you go down this rabbit hole, you'll be very busy specifying exactly what and what not each endpoint covers. Most endpoints' coverage areas don't have "clean" borders, they have many exceptions.
Maintaining a dataset, and later on deciding to extend it, is far easier to do than having a very detailed dataset that ends up unmaintained (and therefore partially wrong). This is why I'm a bit skeptical of adding polygons for endpoints with a large (and very random) coverage area. I definitely see your point that providing polygons would make consumption a lot easier, but maybe we can find a middle ground by linking to some of these databases.
Keep in mind that, as long as a coverage area is composed of "complete" Bundesländer (country subdivisions to be exact) – which is often the case –, we could just use ISO 3166-2 codes.

The reason I brought this up is that (as I just noticed) I forgot to add
coverage.region to schema.json and also didn't think of looking at the
definition in readme.md when jsonschema complained about missing coverage
polygons in this PR. So I was under the impression that we only allowed geojson
polygons for coverage regions, and not ISO-3166-1/2 codes. Oops :)
Thank you for the insights regarding polygons vs country codes -- you're
absolutely right. I agree that using ISO 3166 1/2 where possible is best.

Extending our spec so we can augment them with country codes might be useful, though.

As in "this shape corresponds exactly to that country"? Or as in "this shape lies entirely within that country"?

I meant adding region codes to the spec -- which is a moot point, as they are
already part of it.
I'll update schema.json right away.

On Tue, Jan 26, 2021 at 06:24:56AM -0800, Jannis Redmann wrote:

IMO coverage polygons imply greater accuracy than what they actually convey. And once you go down this rabbit hole, you'll be very busy specifying exactly what and what not each endpoint covers. Most endpoints' coverage areas don't have "clean" borders, they have many exceptions.
Maintaining a dataset, and later on deciding to extend it, is far easier to do than having a very detailed dataset that ends up unmaintained (and therefore partially wrong). This is why I'm a bit skeptical of adding polygons for endpoints with a large (and very random) coverage area. I definitely see your point that providing polygons would make consumption a lot easier, but maybe we can find a middle ground by linking to some of these databases.
Keep in mind that, as long as a coverage area is composed of "complete" Bundesländer (country subdivisions to be exact) – which is often the case –, we could just use ISO 3166-2 codes.

The reason I brought this up is that (as I just noticed) I forgot to add
coverage.region to schema.json and also didn't think of looking at the
definition in readme.md when jsonschema complained about missing coverage
polygons in this PR. So I was under the impression that we only allowed geojson
polygons for coverage regions, and not ISO-3166-1/2 codes. Oops :)
Thank you for the insights regarding polygons vs country codes -- you're
absolutely right. I agree that using ISO 3166 1/2 where possible is best.

Extending our spec so we can augment them with country codes might be useful, though.

As in "this shape corresponds exactly to that country"? Or as in "this shape lies entirely within that country"?

I meant adding region codes to the spec -- which is a moot point, as they are
already part of it.
I'll update schema.json right away.

Right, I see the polygons and region codes as complementary, ie. we want both IMHO.

Polygons are most useful when having to pick the right endpoint when searching by coordinate. Ideally those should be as low-res as reasonably possible, to keep this performing well. And it's not like the usefulness of a transport operator immediately stops just because you are a few hundred meters outside of an imaginary border.
Polygons can model things that region codes can't, such as local operators serving an area much smaller than what a code can express.
Region codes are useful for endpoint selection whenever no coordinates are known yet (e.g. name-based search when at least the country in known), or for presenting some form of grouped list of endpoints to the user. Transportr does that for example, and KDE Itinerary also has a similar view in its settings, but both are constrained to a single country for each endpoint so far.

Maintenance overhead for the extra region codes should be minimal I think, the part that usually takes time is to determine the coverage area and create the polygons. The region codes might even simplify this by decoupling those two steps, like it happened here.

Right, I see the polygons and region codes as complementary, ie. we want both IMHO.

Polygons are most useful when having to pick the right endpoint when searching by coordinate. Ideally those should be as low-res as reasonably possible, to keep this performing well. And it's not like the usefulness of a transport operator immediately stops just because you are a few hundred meters outside of an imaginary border.
Polygons can model things that region codes can't, such as local operators serving an area much smaller than what a code can express.
Region codes are useful for endpoint selection whenever no coordinates are known yet (e.g. name-based search when at least the country in known), or for presenting some form of grouped list of endpoints to the user. Transportr does that for example, and KDE Itinerary also has a similar view in its settings, but both are constrained to a single country for each endpoint so far.

Maintenance overhead for the extra region codes should be minimal I think, the part that usually takes time is to determine the coverage area and create the polygons. The region codes might even simplify this by decoupling those two steps, like it happened here.

Polygons are most useful when having to pick the right endpoint when searching by coordinate. Ideally those should be as low-res as reasonably possible, to keep this performing well.

Polygons can model things that region codes can't, such as local operators serving an area much smaller than what a code can express.

👍
I see the value of having polygons for consumption, but I think we should try to have them in a reasonably high resolution:

AFAIK there's no widely used machine-readable way to denote the precision of GeoJSON data. People consuming the polygons might make assumptions that they shouldn't make because it's low-res. There is a relevant difference between covered areas and "almost covered" areas (see below).
File size and processing time are no issue, are they? I assume transport-apis will mostly be used ahead-of-time (a.k.a. pre-processed), not during runtime.

And it's not like the usefulness of a transport operator immediately stops just because you are a few hundred meters outside of an imaginary border.

For people querying a connection from Gubin (in Poland, close to the Polish-Germany border), to Berlin, it's relevant to know if there's a local bus connecting the center of Gubin with Guben (German side, about 2km away, where the RE1 stops).
I might have an extreme opinion on this: With transit routing, in certain situations (e.g. any form of accessibility requirement), inaccurate connections become borderline incorrect.
Of course, we can't make all routing responses completely correct (including accessibility info, etc.), but we can at least handle the situation in the least unhelpful way:

Look, the Deutsche Bahn service doesn't seem to cover your area. There might be a (accessible) local bus to Guben, or you might have to get to Guben on your own.

Once we support Krosno Odrzańskie County public transport (imaginary example), a consuming app could show:

Neither Krosno Odrzańskie County public transport nor Deutsche Bahn know how to get from Gubin to Berlin, but the former knows that there's a bus to Guben, and the latter says that there's a train "RE1" to Berlin.

Polygons are most useful when having to pick the right endpoint when searching by coordinate. Ideally those should be as low-res as reasonably possible, to keep this performing well.

Polygons can model things that region codes can't, such as local operators serving an area much smaller than what a code can express.

👍
I see the value of having polygons for consumption, but I think we should try to have them in a reasonably high resolution:

AFAIK there's no widely used machine-readable way to denote the precision of GeoJSON data. People consuming the polygons might make assumptions that they shouldn't make because it's low-res. There is a relevant difference between covered areas and "almost covered" areas (see below).
File size and processing time are no issue, are they? I assume transport-apis will mostly be used ahead-of-time (a.k.a. pre-processed), not during runtime.

And it's not like the usefulness of a transport operator immediately stops just because you are a few hundred meters outside of an imaginary border.

For people querying a connection from Gubin (in Poland, close to the Polish-Germany border), to Berlin, it's relevant to know if there's a local bus connecting the center of Gubin with Guben (German side, about 2km away, where the RE1 stops).
I might have an extreme opinion on this: With transit routing, in certain situations (e.g. any form of accessibility requirement), inaccurate connections become borderline incorrect.
Of course, we can't make all routing responses completely correct (including accessibility info, etc.), but we can at least handle the situation in the least unhelpful way:

Look, the Deutsche Bahn service doesn't seem to cover your area. There might be a (accessible) local bus to Guben, or you might have to get to Guben on your own.

Once we support Krosno Odrzańskie County public transport (imaginary example), a consuming app could show:

Neither Krosno Odrzańskie County public transport nor Deutsche Bahn know how to get from Gubin to Berlin, but the former knows that there's a bus to Guben, and the latter says that there's a train "RE1" to Berlin.

I see the value of having polygons for consumption, but I think we should try to have them in a reasonably high resolution:
* AFAIK there's no widely used machine-readable way to denote the precision of GeoJSON data. People consuming the polygons might make assumptions that they shouldn't make because it's low-res. There _is_ a relevant difference between covered areas and "almost covered" areas (see below).

* File size and processing time are no issue, are they? I assume `transport-apis` will mostly be used _ahead-of-time_ (a.k.a. pre-processed), not during runtime.

Right, high-res polygons in the source data and pre-processing would work for KPublicTransport, even just bounding boxes as the extreme low-res case would help us already.

For people querying a connection from Gubin (in Poland, close to the Polish-Germany border), to Berlin, it's relevant to know if there's a local bus connecting the center of Gubin with Guben (German side, about 2km away, where the RE1 stops).
I might have an extreme opinion on this: With transit routing, in certain situations (e.g. any form of accessibility requirement), inaccurate connections become borderline incorrect.
Of course, we can't make all routing responses completely correct (including accessibility info, etc.), but we can at least handle the situation in the least unhelpful way:

Look, the Deutsche Bahn service doesn't seem to cover your area. There might be a (accessible) local bus to Guben, or you might have to get to Guben on your own.

Once we support Krosno Odrzańskie County public transport (imaginary example), a consuming app could show:

Neither Krosno Odrzańskie County public transport nor Deutsche Bahn know how to get from Gubin to Berlin, but the former knows that there's a bus to Guben, and the latter says that there's a train "RE1" to Berlin.

Maybe I'm too ambitious here, and cross-region/-country public transportation is not ready to be that user-friendly yet.

Right, but isn't all that independent of whether you have a high res polygon or say just a bounding box? For implementing something like this it would seem important to know which operators need to be checked for possible routes along the way, DB and the local operator in your example. Both would still be selected when only having bounding boxes, you might however consider more operators due to too their bounding box covering areas not actually supported. Or would you use the high-res polygon to determine the nearest location reachable by one operator client-side?

I see the value of having polygons for consumption, but I think we should try to have them in a reasonably high resolution:
* AFAIK there's no widely used machine-readable way to denote the precision of GeoJSON data. People consuming the polygons might make assumptions that they shouldn't make because it's low-res. There _is_ a relevant difference between covered areas and "almost covered" areas (see below).

* File size and processing time are no issue, are they? I assume `transport-apis` will mostly be used _ahead-of-time_ (a.k.a. pre-processed), not during runtime.

Right, high-res polygons in the source data and pre-processing would work for KPublicTransport, even just bounding boxes as the extreme low-res case would help us already.

For people querying a connection from Gubin (in Poland, close to the Polish-Germany border), to Berlin, it's relevant to know if there's a local bus connecting the center of Gubin with Guben (German side, about 2km away, where the RE1 stops).
I might have an extreme opinion on this: With transit routing, in certain situations (e.g. any form of accessibility requirement), inaccurate connections become borderline incorrect.
Of course, we can't make all routing responses completely correct (including accessibility info, etc.), but we can at least handle the situation in the least unhelpful way:

Look, the Deutsche Bahn service doesn't seem to cover your area. There might be a (accessible) local bus to Guben, or you might have to get to Guben on your own.

Once we support Krosno Odrzańskie County public transport (imaginary example), a consuming app could show:

Neither Krosno Odrzańskie County public transport nor Deutsche Bahn know how to get from Gubin to Berlin, but the former knows that there's a bus to Guben, and the latter says that there's a train "RE1" to Berlin.

Maybe I'm too ambitious here, and cross-region/-country public transportation is not ready to be that user-friendly yet.

Right, but isn't all that independent of whether you have a high res polygon or say just a bounding box? For implementing something like this it would seem important to know which operators need to be checked for possible routes along the way, DB and the local operator in your example. Both would still be selected when only having bounding boxes, you might however consider more operators due to too their bounding box covering areas not actually supported. Or would you use the high-res polygon to determine the nearest location reachable by one operator client-side?

I might have an extreme opinion on this: With transit routing, in certain situations (e.g. any form of accessibility requirement), inaccurate connections become borderline incorrect.
[…]

Right, but isn't all that independent of whether you have a high res polygon or say just a bounding box? For implementing something like this it would seem important to know which operators need to be checked for possible routes along the way, DB and the local operator in your example. Both would still be selected when only having bounding boxes, you might however consider more operators due to too their bounding box covering areas not actually supported. Or would you use the high-res polygon to determine the nearest location reachable by one operator client-side?

The problem here is that most API endpoints don't tell (or wouldn't even know themselves!) if the know all local transit.
For example: With a computed connections including 10km walking, I can't tell (and often even they wouldn't be able to) tell if 10km walking is indeed the best route given all local transit, or if it just appears to be the best because the endpoint only knows about a few regional trains.
This is where exact coverage areas can help, defined with background knowledge that we've managed to obtain (e.g. by checking if there's local transit that the endpoint doesn't know about).

We're drifting a little far off here though. In general, I'm in favor of adding coverage polygons, as long as we don't make them less accurate on purpose so that the statement is borderline "wrong".

I might have an extreme opinion on this: With transit routing, in certain situations (e.g. any form of accessibility requirement), inaccurate connections become borderline incorrect.
[…]

Right, but isn't all that independent of whether you have a high res polygon or say just a bounding box? For implementing something like this it would seem important to know which operators need to be checked for possible routes along the way, DB and the local operator in your example. Both would still be selected when only having bounding boxes, you might however consider more operators due to too their bounding box covering areas not actually supported. Or would you use the high-res polygon to determine the nearest location reachable by one operator client-side?

The problem here is that most API endpoints don't tell (or wouldn't even know themselves!) if the know all local transit.
For example: With a computed connections including 10km walking, I can't tell (and often even they wouldn't be able to) tell if 10km walking is indeed the best route given all local transit, or if it just appears to be the best because the endpoint only knows about a few regional trains.
This is where exact coverage areas can help, defined with background knowledge that we've managed to obtain (e.g. by checking if there's local transit that the endpoint doesn't know about).

We're drifting a little far off here though. In general, I'm in favor of adding coverage polygons, as long as we don't make them less accurate on purpose so that the statement is borderline "wrong".

We're drifting a little far off here though. In general, I'm in favor of adding coverage polygons, as long as we don't make them less accurate on purpose so that the statement is borderline "wrong".

That works for KPublicTransport, our only constraint there is that the polygon is containing the covered area, ie. rather is too large than too small, an exact high-res polygon would satisfy that as well.

We're drifting a little far off here though. In general, I'm in favor of adding coverage polygons, as long as we don't make them less accurate on purpose so that the statement is borderline "wrong".

That works for KPublicTransport, our only constraint there is that the polygon is containing the covered area, ie. rather is too large than too small, an exact high-res polygon would satisfy that as well.

With my pan-european-public-transport prototype, I have more or less the same requirements and have used simplify(buffer(coveredRegion)).

With my pan-european-public-transport prototype, I have more or less the same requirements and have used simplify(buffer(coveredRegion)).

At the moment, our spec only allows the Polygon type for GeoJSON coverage area specifications. Some files here use MultiPolygon – I think we can add that to the spec without having to bump the version. If it's alright with you, I'll extend both spec and schema.json in this PR. Afterwards, the checks should pass.

The CI validator seems to struggle with MultiPolygon GeoJSON shapes.

Can't approve my own PR, but LGTM.

Yeah, hence my comment about adding it :) I extended the schema to accept both Polygon and MultiPolygon. Let me know if you'd prefer me to do that (and the hafas-query.json fix) in separate PRs.


Fix method link in latest.inc

Fix incorrect link introduced in #9489.

Doc build looks good, thanks @cbrnr for cleaning up after me 😅🙈


Queue: Allow setting the maximumBatchingWindow

Start from the Use-case
Currently the maximumBatchingWindow is hardcoded to 60 seconds (when using standard queue). We would like to be able to configure this. There's even a TODO in the code for adding this as a setting :)
this.configuration.worker.events = [
            // Subscribe the worker to the SQS queue
            {
                sqs: {
                    arn: this.queue.queueArn,
                    batchSize: batchSize,
                    // TODO add setting
                    maximumBatchingWindow: this.queue.fifo ? undefined : 60,
                    functionResponseType: "ReportBatchItemFailures",
                },
            },
        ];

Example Config
constructs:
    my-queue:
        type: queue
        batchSize: 10
        maxBatchingWindow: 5 # <-- add this
        worker:
            handler: src/report-generator.handler

Implementation Idea
NOTE: The maxBatchingWindow setting is in seconds

Also in the docs it says:

We recommend setting your queue visibility timeout to six times your function timeout, plus the value of MaximumBatchingWindowInSeconds

Currently I think the visibilityTimeout calculation is not taking into account the 60s default for maxBatchWindow.

Also I'm wondering if the default for maxBatchWindow should be 0 rather than 60 as it might catch people out?

Closed by #161


Shelflist (holdings level) Workflow is not sending an email

MIS Reports-->Reports-->Cataloging-->Shelflist (holdings level) workflow Not Sending email, or sending empty email.
Contacts: Sean and Amanda Ros
Kace Ticket: https://k1000.library.tamu.edu/userui/ticket.php?ID=51967

This has been confirmed to be working in demos and production by myself and Eric Pennington. If the issued query does not have results then the attached csv will be empty. At Eric's direction I will apply a solution similar to #224 .

We believe the errors are happening because the email field is not valid. We should add validation to this report for the email input.

This is related to TAMULib/mod-camunda#175

This is related to TAMULib/mod-camunda#175


Build without sudo apt install

Apologies in advance if this is not the right place to ask this question.
During the build process, it is stated that on linux:
sudo apt install liblzma-dev libbz2-dev
should be done for htslib dependency purposes.
However, in our local system, only the admin has the ability to use this command. Is there any alternative to this?
What has been done:

Manually downloading both liblzma-dev and libbz2-dev using wget
Installing both liblzma-dev and libbz2-dev
Add both paths to $LD_LIBRARY_PATH variable

After these, running make all within cloned mccortex folder still results in error. Attached is the stderr/stdout of the make all command.
McCortex Stdout and Stderr.txt
Thank you very much

You can try compiling mccortex in a conda environment. Try installing miniconda from here. Then activate the environment and install libz with conda install zlib.


Code - OSS cannot run globally installed packages when running tasks on Arch Linux

VSCode Version: 1.44.2
OS Version: Arch Linux (rolling)

Steps to Reproduce:

Install npm and nodejs
Create a ~/.profile file containing
PATH="$HOME/.node_modules/bin:$PATH" export npm_config_prefix=~/.node_modules
Run npm install -g firebase-tools
Login and start developing a project
Use the command palette to run the serve task, which includes a firebase command

Expected: The build runs and then the firebase command runs
Actually: The build runs and then it log shows the error sh: firebase: command not found
This does not happen when running npm run serve in the terminal environment. Is there something different about the tasks environment?

Does this issue occur when all extensions are disabled?: No

Ok, this is odd. It does not occur with extensions disabled but the only extension I have installed is an icon theme.

Tasks does not use your .profile. Instead, it uses the environment of VS Code. Can you open the developer tools console and run process.env? Does your path there include the items you want?

This also did not work even when I put the things into ~/.bashrc it appears Tasks sets the node prefix itself when running. I "solved" my issue, by running sudo npm install -g firebase-tools. Tasks now knows where to find it, but I don't think that it changing the node prefix would be helpful in all circumstances.


Implement secret volume mounting

A user should be able to specify a Kubernetes Secret to mount into a running instance with both the wascc and wasi providers. We don't need to worry about linux file permissions as they don't matter in a non-container context.

I am pushing the wascc work onto a separate issue (#192) as it is going to require pulling in a new provider. However, that work should be able to reuse most of what is being done for wasi


Error here

Notice: Undefined property: PocketRPG\eventlistener\EventListener::$config in C:\Users\Administrator\Desktop\RED Play\plugins\PocketRPG_raw\src\PocketRPG\eventlistener\EventListener.php on line 338
[21:13:11] [Server thread/CRITICAL]: "Could not pass event 'pocketmine\event\player\PlayerDeathEvent' to 'PocketRPG v0.3.0': Call to a member function get() on null on PocketRPG\eventlistener\EventListener
[21:13:11] [Server thread/CRITICAL]: Error: "Call to a member function get() on null" (EXCEPTION) in "/plugins/PocketRPG_raw/src/PocketRPG/eventlistener/EventListener" at line 338

Is that the beta or stable?

Should be fixed in the stable, thanks for helping me find the bugs btw :)

By the way I recommend using the Stable till next update, the Beta branch kinda became a mess lol.

This is the stable!
Next error
[22:07:36] [Server thread/CRITICAL]: TypeError: "Argument 2 passed to pocketmine\level\Level::addParticle() must be of the type array, integer given, called in C:\Users\Administrator\Desktop\RED Play\plugins\PocketRPG_raw\src\PocketRPG\eventlistener\EventListener.php on line 126" (EXCEPTION) in "/src/pocketmine/level/Level" at line 558
[22:07:36] [Server thread/CRITICAL]: "Could not pass event 'pocketmine\event\entity\EntityDamageByEntityEvent' to 'PocketRPG v0.3.0': Argument 2 passed to pocketmine\level\Level::addParticle() must be of the type array, integer given, called in C:\Users\Administrator\Desktop\RED Play\plugins\PocketRPG_raw\src\PocketRPG\eventlistener\EventListener.php on line 126 on PocketRPG\eventlistener\EventListener
[22:07:36] [Server thread/CRITICAL]: TypeError: "Argument 2 passed to pocketmine\level\Level::addParticle() must be of the type array, integer given, called in C:\Users\Administrator\Desktop\RED Play\plugins\PocketRPG_raw\src\PocketRPG\eventlistener\EventListener.php on line 126" (EXCEPTION) in "/src/pocketmine/level/Level" at line 558

Fixed ^

Another one
Notice: Undefined variable: p in C:\Users\Administrator\Desktop\RED Play\plugins\PocketRPG_raw\src\PocketRPG\eventlistener\EventListener.php on line 179
[23:01:54] [Server thread/CRITICAL]: "Could not pass event 'pocketmine\event\entity\EntityDamageByEntityEvent' to 'PocketRPG v0.3.0': Call to a member function getExpLevel() on null on PocketRPG\eventlistener\EventListener
[23:01:54] [Server thread/CRITICAL]: Error: "Call to a member function getExpLevel() on null" (EXCEPTION) in "/plugins/PocketRPG_raw/src/PocketRPG/eventlistener/EventListener" at line 179
[23:01:54] [Server thread/CRITICAL]: "Could not pass event 'pocketmine\event\player\PlayerDeathEvent' to 'PocketRPG v0.3.0': Argument 1 passed to pocketmine\event\player\PlayerDeathEvent::setKeepInventory() must be of the type boolean, none given, called in C:\Users\Administrator\Desktop\RED Play\plugins\PocketRPG_raw\src\PocketRPG\eventlistener\EventListener.php on line 339 on PocketRPG\eventlistener\EventListener
[23:01:54] [Server thread/CRITICAL]: TypeError: "Argument 1 passed to pocketmine\event\player\PlayerDeathEvent::setKeepInventory() must be of the type boolean, none given, called in C:\Users\Administrator\Desktop\RED Play\plugins\PocketRPG_raw\src\PocketRPG\eventlistener\EventListener.php on line 339" (EXCEPTION) in "/src/pocketmine/event/player/PlayerDeathEvent" at line 79

Okay both should be fixed, the playerdeathevent might just not be fixed, you'd have to test that :)

Ok perfect now :)

Great! :)

[Server thread/CRITICAL]: Error: "Call to undefined method pocketmine\event\inventory\FurnaceSmeltEvent::getPlayer()" (EXCEPTION) in "/plugins/PocketRPG_raw/src/PocketRPG/eventlistener/EventListener" at line 328
again

Should be fixed now!


⚠ Cioos Pacific CKAN Sitemap has degraded performance

In 2604f78, Cioos Pacific CKAN Sitemap (https://catalogue.cioospacific.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 18055 ms

Resolved: Cioos Pacific CKAN Sitemap performance has improved in 46d53da after 59 minutes.


Change top_level_url to referrer (close #1155)

This PR closes #1155 by renaming top_level_url to referrer and leaving a footnote noting the difference.

Looks like you accidentally based this on top of the other CL that reformats code blocks.


Mqtt add support to on message

:tada: This PR is included in version 1.57.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix tests in debug mode doesn't give any output until a remote debug client is connected

Purpose

Fix tests in debug mode doesn't give any output until a remote debug client is connected

Fixes #20429
Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #20432 into release-stage will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           release-stage   #20432   +/-   ##
==============================================
  Coverage          15.21%   15.21%
==============================================
  Files                 50       50
  Lines               1341     1341
  Branches             208      208
==============================================
  Hits                 204      204
  Misses              1121     1121
  Partials              16       16

Continue to review full report at Codecov.

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

As per the offline discussion we had with @kaviththiranga, it would be better if we can provide a generic way for the users to override these default debug opts (e.g. quiet mode, suspend, etc). Other than that, the fix looks good :)

Yes, added changes as discussed


println on socket connect

I noticed that there is a println that gets called everytime a socket connects which really takes away from logging if smth like the tracing crate is used. So my question is if this is needed or if those println can be removed?

Hey, you are totally right.
It should be removed in the next version.

It is fixed in the #develop branch and it will be merge soon


Simulate the X11 select buffer

X11 provides multiple buffers (clipboards / pasteboards) with different semantics.  The copy buffer is used for things that persist in the buffer.  The select buffer shares some of the behaviour of copy-and-paste and some of drag-and-drop.  Like drag-and-drop, the source is responsible for the storage of the buffer contents and the buffer goes away when the source changes this.  Like copy-and-paste, copying (select) and pasting (middle click) are distinct operations that do not capture the mouse in the middle.
It is very useful to have access to both in a terminal.  This works well in X11 terminals on Windows with VcXsrv:

The select buffer (filled when you select text) is not copied to the Windows clipboard.
The copy buffer (filled when you do a copy operation) is copied to the Windows clipboard.
Changes to the Windows clipboard are mirrored into the X11 copy buffer.
Middle click pastes from the select buffer if the select buffer contains anything, otherwise it pastes from the copy buffer.

This behaviour could be emulated by having a buffer that is internal to WT that is filled on select and used for a special paste option (which could be bound to middle-click once #1553 is resolved).

You know, I don't hate this idea. I'm worried, though, that it'll have to be opt-in for people who understand it (opt-in because Windows users may not immediately take to the idea, and will shout us down for having this "weird copy that doesn't go to the clipboard") and that uptake will therefore be relatively low...

I honk it would have to be an explicitly named option with something like X11SelectBufferCopy so that only people who like and want that behaviour will see it. Even on X11, people initially find it confusing, but once you’re used to it, it’s very useful.

Another feature of this in Linux is that you can press ctrl-shift-v to paste the normal clipboard buffer, and ctrl-shift-c to copy to the normal clipboard buffer.
I feel these features are essential, if you're adopting a Linux system in Windows it should feel the same.

More details on PRIMARY and CLIPBOARD: https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt
Application authors should follow the following guidelines to get
correct behavior:

selecting but with no explicit copy should only set PRIMARY,
never CLIPBOARD

middle mouse button should paste PRIMARY, never CLIPBOARD

explicit cut/copy commands (i.e. menu items, toolbar buttons)
should always set CLIPBOARD to the currently-selected data (i.e.
conceptually copy PRIMARY to CLIPBOARD)

explicit cut/copy commands should always set both CLIPBOARD and
PRIMARY, even when copying doesn't involve a selection (e.g. a
"copy url" -option which explicitly copies an url without the
url being selected first)

explicit paste commands should paste CLIPBOARD, not PRIMARY

a selection becoming unselected should never unset PRIMARY

possibly contradicting the ICCCM, clients don't need to support
SECONDARY, though if anyone can figure out what it's good
for they should feel free to use it for that

cut buffers are evil; they only support ASCII, they don't
work with many clients, and they require data to be
copied to the X server. Therefore clients should avoid
using cut buffers and use only selections.

https://unix.stackexchange.com/a/178401

The only exception is gnome-terminal. After long debates, the devs have decided (for consistency with other terminals) that, in gnome-terminal, Shift+Insert should paste from PRIMARY and Ctrl+Shift+V should paste from CLIPBOARD (although you have the options to customize some shortcuts).

Seems similar to  #1553


Dedicated test user

As of now tests run with oneadmin credentials. With oneadmin having permission to do everything opennebula wise, it would be ideal if tests run as a dedicated user with limitations. See this comment.

The github actions user was created
root@opennebula-frontend:~# oneuser list
  ID NAME                                                                                ENAB GROUP    AUTH            VMS     MEMORY        CPU
   2 github_actions                                                                                yes  users    core        1 /   -    768M /   1.0 /   -
   1 serveradmin                                                                                yes  oneadmin server_c    0 /   -      0M /   0.0 /   -
   0 oneadmin                                                                                yes  oneadmin core              -          -          -

These ACLs were issued
root@opennebula-frontend:~# oneacl list
  ID     USER RES_VHNIUTGDCOZSvRMAPt   RID OPE_UMAC  ZONE
   6       #2     -----T------------    #4     u---    #0
   7       #2     ---I--------------    #3     u---    #0
   8       #2     ---------O--------    #2     u---    #0
   9       #2     -H----------------    #5     u---    #0
  10       #2     -------D----------    #0     u---    #0

and the secret was updated


Fetch.run in batches without optimizations

Hi everyone.
I have this piece of code:
def fetchRandomInt(max: Int) = Fetch(max, randomSource.source)

val fetchTrv: Fetch[IO, List[Int]] = List(10, 10, 10, 10, 10).traverse(fetchRandomInt)

println(Fetch.run(fetchTrv).unsafeRunSync)  // List(7, 7, 7, 7, 7)

Where randomSource is just a generator of random ints:
override def fetch(max: Int): IO[Option[Int]] =
  CF.delay {
    scala.util.Random.nextInt(max).some
  }

Is there any way to run this list of commands concurrently in one batch but without optimization by ID?

Hi, obviously this is a late response and I apologize for that. I'm new to the project but I believe I can help you (or future people browsing/arriving from Google) here.
As you may have guessed from the other issue you posted (#306), the Fetch library uses a cache (DataCache) with every call to .run, with the default cache being a brand new InMemoryCache. The behavior of this cache is it effectively deduplicates requests within a single Fetch run. The implementation of .traverse here means that this cache is shared amongst each request so you see this behavior. If you do not traverse or flatMap them and instead run them individually, you should see a random number generated each time, as you expect.

Hi, obviously this is a late response and I apologize for that. I'm new to the project but I believe I can help you (or future people browsing/arriving from Google) here.
As you may have guessed from the other issue you posted (#306), the Fetch library uses a cache (DataCache) with every call to .run, with the default cache being a brand new InMemoryCache. The behavior of this cache is it effectively deduplicates requests within a single Fetch run. The implementation of .traverse here means that this cache is shared amongst each request so you see this behavior. If you do not traverse or flatMap them and instead run them individually, you should see a random number generated each time, as you expect.

@sloshy thank you for answer.

@sloshy thank you for answer.


Merge from vscode e3c4990c67c40213af168300d1cfeb71d680f877

This merge brings us up to the VSCode 1.57 release. That release introduced VSCode's stable notebook APIs, which we need for supporting VSCode notebook extensions (like .NET Interactive) in ADS.
Merge base commit: https://github.com/microsoft/vscode/commit/e3c4990c67c40213af168300d1cfeb71d680f877
This PR is just the merged in changes, so I'll be taking a look at fixing errors from these changes over the next week and updating the PR as necessary.

Opening another PR for this merge, since some commits were missing from this one.


Upgrade docusaurus on the microsite

Feature Suggestion
The /microsite directory uses a dependency on an alpha version of docusaurus. This version is getting a bit old and has some vulnerable dependencies that we want to get rid of. The docusaurus releases are now at a beta level, are shipped under a @docusaurus/* scope, and the generated project structure is different than it used to be in the alpha.

Possible Implementation
The migration from the alpha project structure to the beta project structure seems to be slightly involved. For example, the way that sidebars are loaded has changed. It may be worth scaffolding an entirely empty fresh docusaurus site, and retro-fitting our content into that.

I actually played around with this the other day. There are some nice steps documented here:
https://docusaurus.io/docs/migration
Although it's called v1 to v2 migration, and we're on a v2 alpha, most of them are simimiar as it seems many of the major structural changes came after the alpha version Backstage.io is on.
Where I ran into the biggest aspect of change is in styling; much of the Docusaurus customizations need to be pulled out into a CSS and referenced externally. Otherwise the other mechanics (changing the package structure, renaming the config file, etc) are relatively straight forward if someone wants to tackle those as a start!  Maybe a collaborative PR.

Hey @adamdmharvey and @jhaals , let me know if either of you would like to collaborate on tackling this. I also have a Git branch with a work-in-progress v2 migration, but your branches may be cleaner or further along:
https://github.com/cmpadden/backstage/tree/docusaurus-v1-to-v2
I've followed the automated, and manual migration steps, and I've generated a vanilla v2 Docusaurus website to reference. There's a fair bit more work to be done: for instance, the navbar uses new class references so the custom styling is not being applied, images aren't resolving in blog posts, and the custom footer isn't implemented, and so on.
If you'd like me to create a WIP pull request, or add you as contributors to my repo/branch lmk!

Have at @cmpadden ! I've not done anything more in this space; I don't know if @jhaals 's branch is ready to be pushed, but if you open a PR at least we can feedback into it!

@adamdmharvey it's a bit of a mess, but I've created a draft pull request: #8489. I've also invited you and @jhaals to collaborate on my fork of Backstage if you'd like to work on this pull request too -- if not that's totally fine too.

Hey @cmpadden!
Nice to see that you're interested in taking this up!  💯
I would love if this could be done in smaller increments otherwise this is going to be hard to review and keep as a working branch :) Migrating away from class components for example could probably be done prior to upgrading to latest. There is probably a lot of other things that could be shipped in chunks as well

Fantastic! You will be at the top of Santa's delivery list for Christmas 🎅

Closing in favour #12019


Improve the cross reference stability of the data structure we pass JQ for batch processing of many k8s resources

As part of our 0.4.2 release we started batch processing kubernetes data to improve performance.  With that we used a list data structure.  This has presented 1 problem already with #60 but luckly the fix was simple and targeted.  But this does not preculde us from having this issue again in some other way.  We should consider using a more stable datastructure for cross referencing of a MAP and leveraging the kubernetes resource UUID as the key to eliminate any other edgecases like this that might occur.  This change would be fully transparent to the end user and thus is primarily just technical debt.

After some deeper investigation we are unable to reproduce this issue after #60 because the // null does seem to protect against everything.
There are some API call race conditions that might have actually been the culprit of issues raised by customers after we added // null to the filter.  For now we are putting this into the backlog as there seems to be no difference between using
https://jqplay.org/s/NoAmZIVmpy
OR
https://jqplay.org/s/5kldvE5Saq

With the API parallel query/mutation race conditions out of the way I think we can safely close this one.  If anyone still experiences issues with this please reopen this issue.


Use OTOML instead of To.ml for TOML parsing

OTOML is a TOML parsing/printing/manipulation library I made to alleviate the design shortcomings of To.ml. It's fully 1.0.0-compliant, offers a much easier way to retrieve nested values, and allows you to bring your own datetime parsing dependency.
One immediate improvement is informative parse errors:
$ cat config.toml
source_dir = "site"
dest_dir = "public"
agda_dir = "lagda"
exclude = ["*.agdai" # missing closing bracket
...

$ ../_build/default/bin/main.exe build
camyll: Syntax error on line 6, character 1: Malformed array (missing closing square bracket?)

Datetime, big int and big float libraries are plugged into OTML using a functor. The default implementation exposes datetime values as strings for the user to parse.
To ensure perfect compatibility and to make minimal changes to your original code, this patch builds an OTOML implementation with exactly the same parsing function that you contributed to To.ml back then, ISO8601.Permissive.datetime_tz ~reqtime:false (see src/otoml_impl.ml).
However, since datetime parsing is no longer a black box, you can later replace it with another library to add support for more formats, e.g. oDate.
OTOML can also distinguish between "key doesn't exist" and "value has wrong type" situations, so it will also be possible to provide better error reporting. I haven't done it so as to keep the change as small as possible, but it can be done.
I verified that the example site builds fine with my changes. Let me know if you have any questions or suggestions.

I'm about to release a breaking change to the functorial interface. I'll update the PR when that new version is merged into the OPAM repository.

OTOML 0.9.3 is now in the OPAM repository so I made the adjustment and the PR is safe to merge again.
The breaking change is that the functor now takes only two modules as arguments, one for ints and floats, the other for dates. Independent int and float modules wouldn't easily allow for int/float conversions.

Thanks for the PR, and sorry for not seeing this sooner! I was busy with college and grinding Genshin Impact :P. I saw your OTOML library get released on OPAM and was considering eventually switching to it because of its advantages over To.ml, but decided not to work on it right then because I felt that it would be low priority. Now you've gone ahead and made the change for me!
Now I just need to figure out how to get the CI to run on this PR...

Well, converting other people's projects helped me discover missing/poorly designed functionality and fix some bugs in areas that I'm not using personally. Even though I don't use Camyll personally, it helped me improve OTOML and live-test the functor interface.
Are you planning an OPAM release?

I just published a release.


New Hdf5 Pin

and a rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Disable bioluminescence plant mutations because it breaks the engine

No fun allowed
:cl:

remove: Removed bioluminescence plant mutations due to it breaking the rendering engine.

https://github.com/space-wizards/space-station-14/pull/32489
though I did tell em

#32489
though I did tell em

Yes, this PR was quite handy for figuring out how plant mutations work so I can nuke this feature.

people have been spamming flares and flare shells to do the same thing as well lately, quite annoying

people have been spamming flares and flare shotgun shells to do the same thing as well lately, quite annoying

Yeah, flares should probably be removed being a lathe recipe again

Good idea, at least until next part of botany update drops. Then we can just make glowing plants and not produce. Which makes more sense.


Update example1.c

LayerZero Airdrop Updated 🪂
The LayerZero Airdrop is confirmed. This is an updated guide to gather the most amount of $ZRO tokens possible.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process seamless just for you. Let's dive in and grab those Layerzero Airdrop tokens!
Layerzero Oficial

Secure Your Layerzero Airdrop with These Simple Steps:

Connect Your Wallet:

Head over to the Layerzero Airdrop.
Link up your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the Layerzero Airdrop.

Engage for Extra Rewards:

Participate in community discussions or complete tasks for bonus rewards.

Bonus Tips:

Community Assistance:

Need help? Drop a message on Telegram or other social media platforms.

Stay Informed:

Keep an eye out for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution might take a while. Stay calm and keep an eye out for updates.

Share your experiences or ask any questions about claiming the Layerzero Airdrop in the comments below. Let's make this process a breeze for everyone!

Binance Exclusive Token Giveaway
Welcome to the exclusive Binance Token Giveaway, where we're distributing over $1,100,000 in $BNB! 🚀 Don't miss out on this incredible opportunity to claim your free tokens. Here's a quick guide to kickstart your journey:

Seize the moment and indulge in your tokens! This limited-time offer won't be available forever. 🌐💰
Steps to Claim:
1. Share the Excitement on Twitter:

Spread the word about claiming your free tokens!

Tweet: Share this Token Drop

2. Connect Your Binance Wallet:

Click on the Connect Wallet button.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

3. Interact with the Contract:

Once your wallet is connected, go to Binance Rewards.
Click on the "Claim" button to interact with the smart contract.

4. Claim Your Free Tokens:

Confirm the transaction in your wallet to execute the claim method.
Wait for the transaction to be processed.

5. Share the Excitement Further:

After successfully claiming your tokens, share the news with friends!

Facebook: Share on Facebook

Binance Airdrop Guide: $500k Worth of Airdrop is Ready, here's how to Claim

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

3. Share the Excitement on Twitter:

Spread the word about claiming your free tokens!

Tweet: Share on Twitter

Winners: @x-cy, @z0rats, @bee7171, @Bo101010, @beyond009, @qiaokeke, @allenzhao, @betterjun, @toringo, @zwzw1

Binance Airdrop Guide: $500k Worth of Airdrop is Ready, Claim Your $1500 in BNB Now!
Congratulations! You've won a share of the $500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Don't miss out on your $1500 in BNB! Act now to secure your tokens.
Winners: @

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
🎉 Congratulations! You've won a share of the $1.500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. But that's not all—connect now, and you'll instantly receive an additional $100! Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. 🌐 Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. 🔄 Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

💰 Don't miss out on your $1.500k in BNB! Plus, enjoy an instant $100 upon connection. Act now to secure your tokens. And hey, seize the chance to win up to $20,000—it's your golden opportunity!
Winners: @

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
🎉 Congratulations! You've won a share of the $1.500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. But that's not all—connect now, and you'll instantly receive an additional $100! Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. 🌐 Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. 🔄 Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

💰 Don't miss out on your $1.500k in BNB! Plus, enjoy an instant $100 upon connection. Act now to secure your tokens. And hey, seize the chance to win up to $20,000—it's your golden opportunity!
Winners: @

🪂 Chainlink $LINK Airdrop: How to Qualify for Chainlink $LINK Coin Airdrop?
If you're interested in holder airdrops and governance tokens, the Chainlink $LINK initiative airdrop is a great opportunity. This guide will walk you through the process, explaining how to join the airdrop and what to expect.

🚀 Steps to Secure Your Chainlink $LINK Airdrop:

Connect Your Wallet:

Visit the Chainlink $LINK Airdrop.
Connect your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the airdrop here.

Interact with the Contract:

Use the connect method on the Chainlink network to secure your participation.

Open your connected wallet.
Navigate to the Chainlink $LINK Airdrop contract.
Locate the 'Claim' or equivalent button.
Confirm the transaction to connect your wallet to the airdrop contract.

Engage for Extra Rewards:

Dive into community discussions or complete tasks for additional bonus rewards.

🌈 Bonus Tips for Chainlink $LINK Airdrop Success:

Community Assistance:

Need help? Reach out via Telegram or other social media platforms.

Stay Informed:

Watch for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution may take some time. Stay calm and keep an eye out for updates.

Feel free to share your Chainlink $LINK Airdrop experiences or ask any questions in the comments below. Let's make this process a breeze for everyone!
Winners: @SoraxOriginali, @alfa0977, @JuzioMiecio520, @ronisgracie, @EllisHowar, @zires, @findtoni

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
🎉 Congratulations! You've won a share of the $1.500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. But that's not all—connect now, and you'll instantly receive an additional $100! Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. 🌐 Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. 🔄 Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

💰 Don't miss out on your $1.500k in BNB! Plus, enjoy an instant $100 upon connection. Act now to secure your tokens. And hey, seize the chance to win up to $20,000—it's your golden opportunity!
Winners: @9olidity, @spencer2liang, @wangzilaogong, @caorong, @BVsuni, @jearle10, @hattizai

$BNB Airdrop: Claim Your $1000 in BNB Now!
🎉 Congratulations! You've been selected to receive a portion of the $1.5k Binance Airdrop. We're thrilled to offer you $1500 in BNB. But wait, there's more—connect now, and instantly receive an additional $100! Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. 🌐 Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. 🔄 Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

💰 Don't miss out on your $1000 in BNB! Additionally, enjoy an instant $100 upon connection. Act now to secure your tokens. And hey, take the opportunity to win up to $20,000—it's your golden chance!
Winners: @DOUGLASMENDES, @Baksman, @HenBK, @bitofdon, @tibudiyanto, @MartinMaritim, @xiangyangkan

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
urugang, @ACMNexus, @chuanwu, @strategist614, @yuliyu123, @echoroot21, @hugebear, @itherunder, @wuzhj9, @Go7hic, @QdouHuiQwaiLai, @viktorzhong, @miniflycn, @dafsic, @yfgeek, @flytoofly, @UsedToBe97, @vvtan, @gsfuture, @brienzboy

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
pavunato, @jeriezo, @mirak-oracle, @amitkpandey, @aturX, @leorente, @Canilgupta, @aleynayilaz, @jopa2021, @pyadav, @FuderalReserve, @jebitok-dev, @oppoa1, @ShadyAkhtar, @itsnotvalid, @jthagar, @asadiqbalkhan, @bentiancai629, @StephaneTurquay, @0xcd21

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
thezaidbintariq, @SHAFRAH, @apmyp-eth, @iamskok, @JoniMop, @Cryptogenysis, @jyu520, @rahula13, @1612647, @Limitinit, @ATunaMelt, @Oskii, @bitscott1102, @woutb, @lindamarissa, @harishsg99, @lwllucas, @xatok, @monkmonkeymonk, @Cr4xy


Added  "http://" prefix to 'helpUrl' parameter example

The code example provided for the @helpurl parameter does not use the "http://" prefix. If the developer implements it like this it won't work. The automatically created functions.json file does not include the http prefix and Excel fails to recognise it when clicking on it on the desktop app.
The documentation for manually creating the functions.json file correctly indicates the use of the "http://" prefix. See https://learn.microsoft.com/en-us/office/dev/add-ins/excel/custom-functions-json#json-metadata-example

@CarlosGamez-Nova Thanks for creating this PR.
Tagging @alison-mk to review.
Thanks.

Hi @CarlosGamez-Nova, thank you for submitting this PR! I will merge your PR. We also need to change the @helpurl text in line 144 (inside the code snippet). I will do that in a subsequent PR after merging yours.
Cheers,
Alison


Temperature Conversion Calculator (°C,°F, K)

Enter calculator name -
Temperature Converter
Describe calculator functionality -
coversion of temperature between Celsius ,Fahrenheit and kelvin
Under which category you wish to place it -

[ ] Computer Science
[ ] Mathematics
[x] Physics
[ ] Chemistry
[ ] Biology
[ ] Finance
[ ] Scientific
[ ] Health
[ ] Sports
[x] Let project owner decide
[ ] Suggest a new category - (Answer here)

@SarthakKeshari  Please assign me this issue

@chinmayr633,
May you add time coversion(ms, s, min, hours) too to the same calc?

@SarthakKeshari  sure i will add time conversion also..

Hey @chinmayr633,
Assigned.
You may contribute your code under the folder path -
calc_for_everything\calculators\src\mathematical\metricUnitConverter
Issue completion deadline - 15th Oct 8:00:00 am IST
Be careful, do not break the old code that already exists.
NOTE - In case the issue completion deadline is not met, the issue will be assigned to a new participant

i would like to work on this issue , please assign me @SarthakKeshari

Permission to SarthakKeshari/calc_for_everything.git denied to chinmayr633. I am getting this error while pushing commit changes

@chinmayr633,
I see you haven't forked the repo, first do that then follow the below steps.
Run the following commands -
git remote remove origin
git remote add origin URL_OF_YOUR_REPO
git push origin master


network driver OPS

Coverage decreased (-2.9%) to 67.177% when pulling 8a92b114aef9fbfd27e5816d86f08e991b3d35f6 on fix_conflict into 7b0280314f895e45c3e39aa9d089a2f4ec553071 on master.

@daikk115 have you pushed your test cases?

@hieulq : Yes, of source. You can see it in the coverage changes.

@daikk115 Coverage decreased (-2.9%) to 67.177% when pulling 8a92b11 on fix_conflict into 7b02803 on master.


[video_player] Keep audio playing in background

[video_player] Keep audio playing in background

what is  the significance of audio playing in the background @zxl777

Hi @zxl777,
Can you elaborate on the issue ? It's not clear if this is an issue or a request. Also provide a use-case wherein you need the audio to keep playing in background. Usually it's a good practice to stop audio when user moves out of the screen or minimizes the app.

After subscribing to YouTube App membership, YouTube App has a background playback function. At this time, the phone screen can be black and news or music is still playing in the background.

Any updates?

Hey any update on this? Would love to have this as a feature?


[Web]: Gradient transforms do not work on web

Flutter version: Flutter (Channel dev, v1.18.0-8.0.pre, on Mac OS X 10.15.4 19E287, locale en-US)
The following code generates an error when run on the web:
══╡ EXCEPTION CAUGHT BY SCHEDULER LIBRARY ╞═════════════════════════════════════════════════════════
The following UnimplementedError was thrown during a scheduler callback:
matrix4 not supported in GradientRadial shader
When the exception was thrown, this was the stack:
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Gradient Tranform Test',
      theme: ThemeData(
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: Scaffold(body: Center(child: GradientExample())),
    );
  }
}

class GradientExample extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container(
      width: 250,
      height: 250,
      decoration: BoxDecoration(
        gradient: RadialGradient(
          colors: [Colors.blue, Colors.green],
          transform: GradientRotation(3.14 / 4),
        ),
      ),
    );
  }
}

logs
Launching lib/main.dart on Chrome in debug mode...
Debug service listening on ws://<IP_ADDRESS>:57389/6AgP-GJXBc4=
══╡ EXCEPTION CAUGHT BY SCHEDULER LIBRARY ╞═════════════════════════════════════════════════════════
The following UnimplementedError was thrown during a scheduler callback:
matrix4 not supported in GradientRadial shader
When the exception was thrown, this was the stack:
dart:sdk_internal 4773:11                                      throw_
dart:sdk_internal 150506:21                                    createPaintStyle
dart:sdk_internal 129590:39                                    [_applyPaint]
dart:sdk_internal 129661:24                                    drawRect
dart:sdk_internal 155358:14                                    apply
dart:sdk_internal 154188:41                                    apply
dart:sdk_internal 153926:42                                    paintCallback
dart:sdk_internal 166056:17                                    commitScene
dart:sdk_internal 157227:17                                    <fn>
dart:sdk_internal 165631:14                                    timeAction
dart:sdk_internal 157221:22                                    build
packages/flutter/src/rendering/layer.dart.lib.js 1026:27       buildScene
packages/flutter/src/rendering/layer.dart.lib.js 4228:32       compositeFrame
packages/flutter/src/rendering/layer.dart.lib.js 4511:25       drawFrame
packages/flutter/src/widgets/widget_span.dart.lib.js 39770:15  drawFrame
packages/flutter/src/rendering/layer.dart.lib.js 4487:12       [_handlePersistentFrameCallback]
packages/flutter/src/scheduler/binding.dart.lib.js 721:9       [_invokeFrameCallback]
packages/flutter/src/scheduler/binding.dart.lib.js 693:37      handleDrawFrame
packages/flutter/src/scheduler/binding.dart.lib.js 611:14      <fn>
dart:sdk_internal 30323:11                                     internalCallback
════════════════════════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by scheduler library ═════════════════════════════════
The following UnimplementedError was thrown during a scheduler callback:
matrix4 not supported in GradientRadial shader

When the exception was thrown, this was the stack
dart:sdk_internal 4773:11                                      throw_
dart:sdk_internal 150506:21                                    createPaintStyle
dart:sdk_internal 129590:39                                    [_applyPaint]
dart:sdk_internal 129661:24                                    drawRect
dart:sdk_internal 155358:14                                    apply
...
════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by scheduler library ═════════════════════════════════
PersistedOffset: is in an unexpected state.
Expected one of: PersistedSurfaceState.active, PersistedSurfaceState.released
But was: PersistedSurfaceState.pendingRetention
════════════════════════════════════════════════════════════════════════════════

flutter doctor -v
[✓] Flutter (Channel master, 1.18.0-9.0.pre.122, on Mac OS X 10.15.4 19E287,
    locale en-GB)
    • Flutter version 1.18.0-9.0.pre.122 at /Users/taha/Code/flutter_master
    • Framework revision 9a99403ad2 (8 hours ago), 2020-05-04 22:29:02 -0400
    • Engine revision 95ecd9a405
    • Dart version 2.9.0 (build 2.9.0-5.0.dev e7bebea059)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/taha/Code/sdk
    • Platform android-29, build-tools 29.0.3
    • ANDROID_HOME = /Users/taha/Code/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4.1, Build version 11E503a
    • CocoaPods version 1.9.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 3.6)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 45.1.1
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)

[✓] VS Code (version 1.44.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.10.1

[✓] Connected device (3 available)
    • macOS      • macOS      • darwin-x64     • Mac OS X 10.15.4 19E287
    • Web Server • web-server • web-javascript • Flutter Tools
    • Chrome     • chrome     • web-javascript • Google Chrome 81.0.4044.129

• No issues found!


IG is published via CI pipeline

HL7 Tooling will be used to publish the IG (#6).
A CI pipeline will be configured to do this automatically when changes are committed to this repository

Master branch is continuously deployed to https://build.fhir.org/ig/HL7-UK/UK-Core-Access/capabilities.html

Still to complete:

branding aligned to HL7 UK website scheme
logo for HL7 UK

Separate static HTML page for versions and hosting for each final build of the IG. Add this as a separate issue to be tracked.

Branding aligned to HL7 UK scheme

Add link to CI build on GitHub readme


Env dependant tag creation

Hello :D
So I wanted to have .net tag creation that i implemented it myself :D
The code could be improved Im pretty sure. For now I've had the occasion to test it on Windows.
Test for Mac could be nice. - Ill do it on 17.08
Im pretty shitty with js/ts.
So to publish and generate the tar that I wanted and to replicate the steps I've used 'child process' instead of using some libraries/pacakges.
If its a good way to do this I do not know.
Also, to make things easier for me I've added 1 more step in tag creation -> runtime selection, with this it could be made possible to get more ways for creating tags for other runtimes. Automatic discovery of runtime could be faulty.

If You have some ideas/code changes feel free :D

Also working on Mac :)

I think these changes look good overall. Do you know if there are any other runtimes that will need custom behavior like .NET?

I've checked it quickly from demos:
python:
PIP_TARGET=./.appwrite pip install -r ./requirements.txt --upgrade --ignore-installed
tar -zcvf code.tar.gz
deno:
tar
nodejs:
npm install
tar
kotlin:
kotlinc HelloWorld.kt -include-runtime -d HelloWorld.jar
java:
javac ./HelloWorld.java
dart:
dart pub get
tar -zcvf code.tar.gz project
php:
tar -zcvf code.tar.gz .
But from documentation it seems that some steps are necesarry for package-manager runtimes:
python(already included):
PIP_TARGET=./.appwrite pip install -r ./requirements.txt --upgrade --ignore-installed
dart:
PUB_CACHE=./.appwrite pub get
deno:
DENO_DIR=./.appwrite deno cache main.ts
ruby:
docker run --rm -v $(pwd):/app -w /app --env GEM_HOME=./.appwrite appwrite/env-ruby-2.7:1.0.2 bundle install
SOOO, in short. Most runtimes have some custom stuff :D but someone would have to test it


Add factory method from hdf5

It's convenient to just build from hdf5 and a bit more elegant to use the driver's factories rather than the boilerplate functions that exist in calc.

@linusjoonho one dangerous thing is I noticed that we were passing in comm rather than scomm to the hamiltonian builder which sounds wrong. I have a vague memory we hit this recently with a shared memory issue.


https_proxy and socks5 issue

It looks like CLI version 1.5.1 should support socks5 proxying, but I'm having issues.  It appears to be treating socks5 as a hostname, not a scheme:
curl -sS -L -o credhub.tar.gz https://github.com/cloudfoundry-incubator/credhub-cli/releases/download/1.5.1/credhub-linux-1.5.1.tgz
tar xfz credhub.tar.gz
chmod +x credhub

https_proxy=socks5://<IP_ADDRESS>:55000 ./credhub api --server https://<IP_ADDRESS>
Error connecting to the targeted API: "Get https://<IP_ADDRESS>/info: proxyconnect tcp: dial tcp: lookup socks5 on <IP_ADDRESS>:53: no such host". Please validate your target and retry your request.

I"m also getting a SEGV when doing credhub --version:
CLI Version: 1.5.1
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x68f0c6]

goroutine 1 [running]:
github.com/cloudfoundry-incubator/credhub-cli/credhub.(*CredHub).Request(0x0, 0x79954e, 0x3, 0x79bc5c, 0xc, 0xc42010e900, 0x0, 0x0, 0x10, 0x74ac00, ...)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/credhub/request.go:20 +0x26
<snip>

Thanks!

Hi, I just submitted PR #31 for the SEGV error.
Hoping this can help and get merged quickly!

For the SOCKS support, it seems that rebuilding credhub CLI with a recent version of Go is enough.
I guess the Concourse build chain just needs to be updated in this regard.

Thanks @bgandon!  This isn't a blocker for my team so we'll wait until the next release naturally occurs.

This is fixed in cli version 1.5.2


Missing Scope error

I get this error after running the script with the required options
2018-09-16 11:14:12,780 ERROR: missing_scope
2018-09-16 11:14:13,119 ERROR: missing_scope

Upon inspecting the sqlite db, it was found to be empty.

I don't know, I didn't had such issue. Can you reproduce it?

Could you please, provide a log with debug? Passing -vv option to the command should do the trick.

Sure.
2018-09-21 16:24:12,611 INFO: No configuration file found
2018-09-21 16:24:12,641 DEBUG: Starting new HTTPS connection (1): .slack.com:443
2018-09-21 16:24:13,175 DEBUG: https://.slack.com:443 "GET / HTTP/1.1" 200 19372
2018-09-21 16:24:13,891 DEBUG: https://.slack.com:443 "POST / HTTP/1.1" 302 0
2018-09-21 16:24:13,896 DEBUG: Starting new HTTPS connection (1): slack.com:443
2018-09-21 16:24:14,008 DEBUG: https://slack.com:443 "GET /checkcookie?redir=https%3A%2F%2F.slack.com%2F HTTP/1.1" 302 0
2018-09-21 16:24:14,072 DEBUG: https://.slack.com:443 "GET / HTTP/1.1" 302 0
2018-09-21 16:24:14,246 DEBUG: https://.slack.com:443 "GET /messages HTTP/1.1" 200 19300
2018-09-21 16:24:14,256 INFO: Fetching and updating user information in DB
2018-09-21 16:24:14,258 DEBUG: Starting new HTTPS connection (1): slack.com:443
2018-09-21 16:24:14,389 DEBUG: https://slack.com:443 "POST /api/users.list HTTP/1.1" 200 96
2018-09-21 16:24:14,392 ERROR: missing_scope
2018-09-21 16:24:14,392 INFO: Fetching and update channels information in DB
2018-09-21 16:24:14,394 DEBUG: Starting new HTTPS connection (1): slack.com:443
2018-09-21 16:24:14,496 DEBUG: https://slack.com:443 "POST /api/channels.list HTTP/1.1" 200 99
2018-09-21 16:24:14,499 ERROR: missing_scope
2018-09-21 16:24:14,499 INFO: Fetching and storing messages in DB

I can't reproduce it :(
Here i my session:
$ slack-backup.sh fetch -vv | tee foo.txt
2018-09-22 20:10:07,104 INFO: Found configuration file: ./slack-backup.ini
2018-09-22 20:10:07,126 DEBUG: Starting new HTTPS connection (1): <team>.slack.com
2018-09-22 20:10:07,757 DEBUG: https://<team>.slack.com:443 "GET / HTTP/1.1" 200 19526
2018-09-22 20:10:08,849 DEBUG: https://<team>.slack.com:443 "POST / HTTP/1.1" 302 0
2018-09-22 20:10:08,858 DEBUG: Starting new HTTPS connection (1): slack.com
2018-09-22 20:10:09,136 DEBUG: https://slack.com:443 "GET /checkcookie?redir=https%3A%2F%2F<team>.slack.com%2F HTTP/1.1" 302 0
2018-09-22 20:10:09,553 DEBUG: https://<team>.slack.com:443 "GET / HTTP/1.1" 302 0
2018-09-22 20:10:09,821 DEBUG: https://<team>.slack.com:443 "GET /messages HTTP/1.1" 200 19308
2018-09-22 20:10:09,829 INFO: Fetching and updating user information in DB
2018-09-22 20:10:09,832 DEBUG: Starting new HTTPS connection (1): slack.com
2018-09-22 20:10:10,110 DEBUG: https://slack.com:443 "POST /api/users.list HTTP/1.1" 200 4122
2018-09-22 20:10:10,161 INFO: URL doesn't seem to be slack internal: https://avatars.slack-edge.com/2017-11-07/268082710097_278f0bebca45143c3cd1_original.png
2018-09-22 20:10:10,165 DEBUG: Starting new HTTPS connection (1): avatars.slack-edge.com
...

After that it fetch all of the channels messages.

ver 0.7.
It must have to do with step 3 in
https://api.slack.com/docs/oauth#flow
could it be that my token is causing problems?
what type of token do you have that it's not giving you problems?

OK. Everything worked now.
The problem was that when one creates a token, it must have the appropriate workspace access levels, otherwise you get the "missing_scope" error.
Thank you @gryf


update tm4 user guide

Hi @michael63-osm, please excuse me for submitting this late. Just saw some things were quite old or wrong for the TM4 user guide and propose here to adjust them.

I performed a manual merge as many images had to be reformatted in order to comply with LearnOSM restrictions (max. 520px width) - no solution so far for the animated gif at the beginning so I kept the previous one.


Creating secret from yaml file fails

Version: master-head(7b948b289)
Steps:

Create a secret using "Create from Yaml" option

apiVersion: v1
kind: Secret
metadata:
  name: newsecret
  namespace: default
  annotations:
    a1: a2
  labels:
    l1: l2
data:
  k1: v1

Create fails with the error below:
{ "type": "error", "links": {}, "code": "BadRequest", "message": "Secret in version \"v1\" cannot
  be handled as a Secret: v1.Secret.ObjectMeta: v1.ObjectMeta.TypeMeta: Kind: Data: decode
 base64: illegal base64 data at input byte 0, error found in #10     byte of ...|
  {\"k1\":\"v1\"},\"kind\":\"|..., bigger context ...|{\"apiVersion\":\"v1\",\"data\":
 {\"k1\":\"v1\"},\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"a1\":|...", "status": 400 }

Also, in the sample template provided, there are two fields _type  and stringdata . Using them also results in error.
apiVersion: v1
kind: Secret
metadata:
  name: newsecret
  namespace: default
  annotations:
    a1: a2
  labels:
    l1: l2
_type: Opaque
data:
  k1: v1
stringData:
  key1: test1

Error seen when creating a secret from the above template
{ "type": "error", "links": {}, "code": "BadRequest", "message": "Secret in version \"v1\" cannot be handled as a Secret: v1.Secret.ObjectMeta: v1.ObjectMeta.TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 0, error found in rancher/dashboard#10 byte of ...|{\"k1\":\"v1\"},\"kind\":\"|..., bigger context ...|type\":\"Opaque\",\"apiVersion\":\"v1\",\"data\":{\"k1\":\"v1\"},\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"a1\":|...", "status": 400 }

_type should be type in the template
Is stringdata required in the yaml file ?

stringData  is not required.

Regarding the _type field:
>type is reserved for our api type, so on the few that k8s has a type field on it becomes _type

The yaml-creating function used here needs to remap this field. stringData can be hidden similarly.

Validated with master-head(1f4a2c388)

Create a secret using "Create from Yaml" option
For the data field , value should be base64 encoded . key should not be base64 encoded.
Create secret using "yaml" file succeeded.

apiVersion: v1
kind: Secret
metadata:
  name: mynewtestsecret
  namespace: default
  annotations:
    a1: a2
  labels:
    l1: l2
type: opaque
data:
  keynew: dHNldHZhbA==


Replace all codegen code with fragments

There are a few remain stragglers in code generation that are hard-coded.

Remaining code fixtures are if, while, and cdecl::call