add --device handling

today system mounts are bypassed.
In particular /dev should be handled.  For example, you should be able to say:
docker run --device=/dev/vfio/17 and expect it to be mounted within the resulting container.
See: https://github.com/containers/virtcontainers/blob/774316c82940561557a90181e8be70aa802c167e/hyperstart.go#L253

@sboeuf  @amshinde @mcastelino

Yes good point, but I am wondering how we should handle this. Either we get an exception for /dev/vfio devices, or we create a very specific list of /dev that we want to ignore.

We should handle just the devices which are described in the config.json.
Ex: sudo docker run --runtime=runc --device=/dev/vfio -it alpine sh
Now, take a look at the resulting config.json, and you will see a "devices" section:
root@sriov-2:/var/run/docker/libcontainerd/2854615a0f3279652d210842141f7d792166a34289908b227f5d718afb526f61# cat config.json | python -mjson.tool | grep -b10 -a10 vfio
381-    },
388-    "hostname": "2854615a0f32",
420-    "linux": {
435-        "cgroupsPath": "/docker/2854615a0f3279652d210842141f7d792166a34289908b227f5d718afb526f61",
534-        "devices": [
555-            {
569-                "fileMode": 8576,
603-                "gid": 0,
629-                "major": 242,
659-                "minor": 0,
687:                "path": "/dev/vfio/17",
727-                "type": "c",
756-                "uid": 0
781-            }
795-        ],
806-        "maskedPaths": [
831-            "/proc/kcore",
858-            "/proc/latency_stats",
893-            "/proc/timer_list",
925-            "/proc/timer_stats",
958-            "/proc/sched_debug",

No I get it but I mean that right now we are bypassing some devices described in the config.json because they are handled directly by the agent. No need to take care of those on the host.
In case of /dev/vfio we don't want to ignore that, we want to mount it locally so that we can share it through the sharedDir that we give to the agent, right ? Or does /dev/vfio have to be passed to qemu ?

@amshinde Is there any reason why we are so restrictive about ignoring the whole /dev directory ?
I think we can easily fix that by using something different than strings.HasPrefix(). Indeed, when testing that way, we ignore all the subpaths including /dev.

@sboeuf In the case of /dev/vfio, we indeed would see this and then know that we have to pass this device in to the clear container (more specifically, update the qemu cmdline to pass this through).

Currently /dev is mounted within hyperstart which is what we want. Instead of ignoring system mounts we can simply restrict the check to bind mounts. (/dev is not passed as a bind mount).

Also -- I think these are in a different location within the config.json, compared to the shared host ones...

@sboeuf @egernst getting rid of the check here should be fine and would fix this:
https://github.com/containers/virtcontainers/blob/774316c82940561557a90181e8be70aa802c167e/hyperstart.go#L253

@egernst These are all passed with the "mounts" object in config.json

As last discussed, this is passed as a "devices" attribute in config.json and not as a mount.
We need to parse "devices", determine the device bdf  and pass the it as a pci passthrough to qemu.
In case where the device needs to be renamed, the agents needs to handle the renaming.

@sboeuf @egernst @amshinde Today we have a blanket ignore of all the devices passed in. We need to structure the code in a way that we do handle the subset of the devices which we may  be able to handle.
This is also true of the mounts. We assume today that all mounts are shared via 9p. But the mount happens to be a block device, we should provide the option to send it in via virt-io blk. This can be done for example for ceph rbd based volumes. And maybe in the future things like iscsi LUNs.

Yes, exactly.  I plan to work on this later this week, unless someone else beats me to it.  If anyone starts looking @ impl, please self-assign.

@mcastelino -- correct -- see https://github.com/containers/virtcontainers/issues/308 for mount discussion.

already supported...


Different behaviour function applyLinearVelocity in windows (120 fps) and android (60 fps)

What happened?
When I was testing my game on multiple platforms, I noticed that once the applyLinearImpulse(Vector2(3000, 0)) gives different results on the windows platform (120fps) and on my Android (60fps). In Windows, the distance the object traveled was noticeably greater than on the phone.
The code is written in such a way as to guarantee acceleration once and compare different platforms
What do you expect?
I expect the distance to be the same for all platforms
How can we reproduce this?
class OrthoPlayer extends SpriteAnimationComponent with KeyboardHandler
{
Body? groundBody;
bool isNeedImpulse = true;

@override
  Future<void> onLoad() async
  {
    position = Vector2(100,100);
    FixtureDef fix = FixtureDef(PolygonShape()..set([Vector2(-10,-10),Vector2(-10,10),Vector2(10,10),Vector2(10,-10)]), friction:
    0.1, density: 0.1);
   groundBody = BodyDef(type: BodyType.dynamic, position: position, fixedRotation: true),
      gameRef.world.physicsWorld);

  @override
  bool onKeyEvent(KeyEvent event, Set<LogicalKeyboardKey> keysPressed)
 {
       if(keysPressed.contains(LogicalKeyboardKey.keyE) && isNeedImpulse ){
           isNeedImpulse = false;
          groundBody?.applyLinearImpulse(Vector2(3000, 0));
       }
 }

  @override
  void update(double dt)
     {
           super.update(dt);
           position = groundRigidBody?.position ?? position;
           //after the body stops, the distance is different
     }
}

What steps should take to fix this?
No response
Do have an example of where the bug occurs?
No response
Relevant log output
No response
Execute in a terminal and put output into the code block below
Output of: flutter doctor -v
PS C:\kyrgyz_epos_game> flutter doctor -v
[√] Flutter (Channel beta, 3.22.0-0.3.pre, on Microsoft Windows [Version 10.0.22631.3593], locale ru-RU)
• Flutter version 3.22.0-0.3.pre on channel beta at c:\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 87b652410d (3 weeks ago), 2024-04-23 21:41:18 -0500
• Engine revision b4bfd45986
• Dart version 3.4.0 (build 3.4.0-282.3.beta)
• DevTools version 2.34.3
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
• Android SDK at C:\Users\gagin\AppData\Local\Android\sdk
• Platform android-34, build-tools 34.0.0
• Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
• Java version OpenJDK Runtime Environment (build 17.0.9+0--11185874)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Users\gagin\AppData\Local\Google\Chrome\Application\chrome.exe
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.7.5)
• Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
• Visual Studio Community 2022 version 17.7.34202.233
• Windows 10 SDK version 10.0.22621.0
[√] Android Studio (version 2023.2)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17.0.9+0--11185874)
[√] VS Code (version 1.82.3)
• VS Code at C:\Users\gagin\AppData\Local\Programs\Microsoft VS Code
• Flutter extension can be installed from:
https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
[√] Connected device (3 available)
• Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.22631.3593]
• Chrome (web)      • chrome  • web-javascript • Google Chrome 124.0.6367.208
• Edge (web)        • edge    • web-javascript • Microsoft Edge 124.0.2478.97
[√] Network resources
• All expected network resources are available.
Affected platforms
Android, Windows
Other information
Version of my libraries:
flame-1.17.0
flame_forge2d-0.18.0
forge2d-0.13.0
Are you interested in working on a PR for this?

[X] I want to work on this

First - on windows
Second - on Android.
In this example I once for all time call function applyLinearImpulse(Vector2(0, -5000));
But еhe player does not move up the same level

I'm guessing that you're hitting the max force per tick.
What is your zoom level, have you kept the default 10?

Yes, but on the contrary I multiply the rigid body position by 10, because I learned about Forge2d much later than I made the game.
I tried it with completely different values, and the speed is always completely different on the computer and on the phone. I have a sprint in the game, when I run without it, the speed on the computer and on the phone is also completely different. Although when I press sprint, the player on both devices starts running faster, i.e. this is not the maximum speed

https://github.com/flame-engine/flame/assets/90832165/54f1a32a-0b60-45ce-9f86-3939fc80d5e4

If you try a simpler example like https://examples.flame-engine.org/#/flame_forge2d_Tappable_Body, do you get the same behavior?

Absolutly yes. I just copied this example (https://github.com/flame-engine/flame/blob/main/packages/flame_forge2d/example/lib/main.dart) into clean new project and replace  body.applyLinearImpulse(Vector2.random() * 5000);
on body.applyLinearImpulse(Vector2(3000,0));
And on the phone the speed of the ball is half as much. Maybe the DPI of the device matters?

DevKage had a look at it too and he found this from Box2D:

So I'm guessing the dt for forge2d should be set to a constant (or close to constant) and then that the rendering should interpolate between the results for this to be able to work more deterministically between different framerates.

So, I must override update() in my root game element about like this:
double currentDeltaTime = 0;
const double tickLimit = 1.0 / 30;

@override
void update(double dt)
{
    if(dt > tickLimit){ //to skip lags frame
       return;
    }
    currentDeltaTime  += dt;
    if(currentDeltaTime >= tickLimit){
       super.update(currentDeltaTime);
       currentDeltaTime = 0;
    }
}

That would probably work, but if I were you I would only set the physics engine to a fixed dt meanwhile the rest runs with a variable dt, so then you'd need to override update in the Forge2DWorld instead:
https://github.com/flame-engine/flame/blob/main/packages/flame_forge2d/lib/forge2d_world.dart#L22-L24

Yes, I tested several accelerations using a simple example and indeed - the speed is now the same on the phone and on the computer. Thank you!

So, most staibility with this code:
static const double tickLimit = 1.0 / 45;
double currentDt = 0;
void update(double dt)
{
currentDt += dt;
int cycles = currentDt ~/ tickLimit;
for(int i = 0; i < cycles; i++){
physicsWorld.stepDt(tickLimit);
}
currentDt -= cycles * tickLimit;
}


Add support for similar option as node's --require

See https://nodejs.org/dist/latest-v6.x/docs/api/cli.html#cli_r_require_module
This would allow using modules like dotenv as designed.

Does Electron itself support this?

Actually, you should try https://electron.atom.io/docs/api/chrome-command-line-switches/#js-flagsflags

Nice finding 👍 thanks.
I'm closing this, I'll reopen if I see anything related to forge itself.


Distinguish ExecutionFailure.assertHasDescription and assertHasDescriptionStartingWith

Previously, ExecutionFailure.assertHasDescription is actually assertHasDescriptionStartingWith. Let's make it explicit to avoid confusion.
This is the first step to resolve https://github.com/gradle/gradle-private/issues/3685

Just found another method assertThatDescription so this is not necessary.


Convert state-pension-through-partner to use ERB templates for questions

Looks good to me.

I've rebased this on master and force pushed in preparation for merging.


Reconsider division of glTF and 3D Tiles functionality into libraries

cesium-native jumps through some hoops in order to minimize the dependencies of its glTF and 3D Tiles support. Specifically, it divides up the functionality into a whole bunch of different libraries. Let's look at glTF. The glTF support in cesium-native is divided into four different libraries:

CesiumGltf: This is meant to have nearly zero dependencies on anything, so it can be used independently in almost any project. Perhaps even as an alternative to tinygltf. In practice, it depends on CesiumUtility and GSL, and the dependencies of CesiumUtility have been growing over time (as they often do) and now include glm, uriparser, spdlog, and zlibstatic. 😬
CesiumGltfReader: Adds the ability read glTF from JSON and GLB. Also knows how to "process" glTFs in various ways at load time, including image (JPEG, PNG, WebP) decoding, Draco decoding, KTX transcoding, Base64 (data URI) decoding, and meshopt decoding. For this reason it depends on a  bunch of third-party libraries that implement these things. From cesium-native, it also depends on CesiumGltf (of course), CesiumJsonReader, and CesiumAsync.
CesiumGltfWriter: The writing side of CesiumGltfReader. It doesn't support encoding all the things that the reader can decode, so it has fewer dependencies. Just CesiumGltf, CesiumJsonWriter, and modp_64 for data URI base64 encoding.
CesiumGltfContent: This is a new one that is not in main yet, and I don't love the name. But this is the first library that depends on cesium-native proper, most notably CesiumGeometry and CesiumGeospatial. If we want to compute a bounding region for glTF, or compute texture coordinates for raster overlay draping, we need those libraries. Basically the idea is that this library contains the higher-level glTF manipulation functionality; anything outside representing the glTF in memory (CesiumGltf) or reading and writing it (CesiumGltfReader / CesiumGltfWriter).

This basic division into four libraries exists for 3D Tiles, too.
So this is a lot of complexity. Is there a better alternative? Does anyone actually care that CesiumGltf is usable without most of the rest of cesium-native? Is it at all useful to have a library like CesiumGltfReader that minimizes cesium-native dependencies, while basically being no-holds-barred on third-party dependencies?
Some possible alternatives:
Two libraries

CesiumGltfObjectModel (better name idea welcome): Contains everything in CesiumGltf plus the parts of CesiumGltfReader and CesiumGltfWriter that do not require third-party dependencies. So this library knows how to read a GLB, but it doesn't know how to do Draco decoding. Depends on almost nothing in cesium-native (in fact we should try to eliminate the CesiumUtility dependency). Doesn't do anything asynchronous because it doesn't depend on CesiumAsync.
CesiumGltf: Contains everything else. Knows how to interpret / decode / manipulate glTFs. Can and will depend on just about anything in cesium-native.

One library
Just put all the glTF functionality into a single library that depends on whatever third-party and cesium-native libraries are needed. Easy. But then using any part of our glTF support will require using most of cesium-native.
I think the critical question here is whether a low-dependency CesiumGltf is valuable to anyone. If not, combining everything into one library feels like a pretty reasonable approach.
@javagl I'm interested in your opinion on this, including possibly from a Khronos perspective.

Cesium-native is a good runtime glTF loader, or it would be if #610 were ever merged :smile: If you want to replace e.g. Assimp with a glTF-focused loader, then you really need the 3rd-party libraries like draco to be useful; at that point, it doesn't matter if some extra cesium-native code is coming along for the ride.
I would vote for putting all the glTF reading / writing code in a single library. I presume that the 3D Tiles functionality would be kept separate? How about putting all that in one library too?

I also vote for the One Library, from just a maintenance perspective.
Let's not put effort into an organizational structure that has no immediate need.

Disclaimers:

I'm trying to keep my role as an 'Independent Khronos Member' and my work for Cesium separate. In Khronos calls, I never speak ~"on behalf of Cesium". And here, I will not speak ~"on behalf of Khronos". (I occasionally mentioned e.g. that something like cesium-native/CesiumGltf exists, but without "endorsing" it in any way).

I've not been actively involved in cesium-native for a while now. So I might not be up to date in every way (but I tried to keep track of some things...)

I'll try to keep comments about ~"the usual trade-offs" short... 🤞

There could be alternative forms of the 'Two Libraries' approach. I agree that one could merge the CesiumGltf/Reader/Writer library into one. But I don't necessarily agree with the details:

CesiumGltfObjectModel [...] knows how to read a GLB, but it doesn't know how to do Draco decoding

When people want to load a glTF/GLB (file ;-) ), then they'd usually like to just do a
target_link_libraries(example Cesium::CesiumGltf)
in their CMake file and be done. They don't want to see an "ERROR: There's Draco, and I don't know what to wo with that" when they try to load that file. They don't want to manually twiddle with additional dependencies. And they certainly don't want to re-implement something like decodeDraco.cpp.
On the other hand, dependency handling is a source of headaches. Git submodules, version incompatibilities, compiler differences, compile times... And for glTF, there will be Draco, Meshopt, WebP, KTX, and potentially more in the future.
So I think that a clean separation of the "core glTF code" and the "convenient glTF library" depends on a clean and good mechanism for handling extensions .
This might involve something like a "plugin concept" for extension support. Roughly: Someone can do
target_link_libraries(example Cesium::CesiumGltf)
and then load a glTF file without extensions.
For everything beyond that, there could be something like
target_link_libraries(example Cesium::CesiumGltfKtx) (Depends on KTX-Software)
and on the code side:
#include <CesiumGltfReader/GltfReader.h>
#include <CesiumGltfKtx/GltfKtx.h>
...
CesiumGltfReader::GltfReader gltfReader;
gltfReader.registerExtension(...CesiumGltfKtx...); // Now it can read glTF with KTX
....

Whether or not this is achievable with reasonable effort? I don't know....
(But it could be 'nice'/'good' in many ways...)

in fact we should try to eliminate the CesiumUtility dependency

+1 for that. (Skipping some details about libraries that contain ~"stuff of which I don't know where else to put it" - it is difficult to sort that out).
From a quick code search, CesiumGltf depends on three things from CesiumUtility:
#include <CesiumUtility/ExtensibleObject.h>
#include <CesiumUtility/JsonValue.h>
#include <CesiumUtility/SpanHelper.h>

The SpanHelper is 1 or 2 functions with 1 line of code, and could trivially be inlined.
The ExtensibleObject is... due to the overlap with 3D-Tiles.
The JsonValue appears only (?) in the classes that deal with glTF metadata extensions.
The latter is another example why it could be important to handle extensions with a "plugin-like" concept. This is strongly related to this image of some Cesium3DTiles and CesiumGltf classes that I posted earlier somewhere:

I'm convinced that there should be a Cesium3DMetadata library. Then, Cesium3DTiles could depend on this. And some CesiumGltfMetadata ("extension-plugin") library could also depend on this.

When it comes to the "role" of the CesiumGltf library, then this may also be relevant: https://github.com/CesiumGS/cesium-native/issues/221
(So... there might be a CesiumImage library that offers KTX support, and the CesiumGltfKtx extension plugin library then depends on the CesiumImage library, but other dependency structures might be possible, depending on "what belongs together"...)

CesiumGltf: Contains everything else.

Given the thoughts from above, and the point about

CesiumGltfContent: [...] to compute a bounding region for glTF, or compute texture coordinates for raster overlay draping,

Then I'd say that these are indeed things that are not related to glTF itself, but to the way how glTF is used within Cesium. So iff there was a Cesium glTF library (that supports Draco, KTX, Metadata and all the other "glTF-inherent stuff", maybe via plugins), then there could still be some CesiumGeospatialGltf library that contains these things that are not inherent to glTF itself, but specific for the context of geospatial applications.

@timoore,

If you want to replace e.g. Assimp with a glTF-focused loader, then you really need the 3rd-party libraries like draco to be useful; at that point, it doesn't matter if some extra cesium-native code is coming along for the ride.

This is a really good point, Tim. Certainly right now, the cesium-native dependencies are much lighter than the various third-party libraries involved in "complete" glTF loading. And almost everyone that wants to load a glTF will also want to do all those various decodings that are necessary to understand what was loaded (in all but trivial cases), anyway. There might be exceptions, but they're rare, so why should we optimize for it?
@javagl,

I'm trying to keep my role as an 'Independent Khronos Member' and my work for Cesium separate.

I definitely understand and appreciate that. Still, from your Khronos discussions, you likely have some insight into how much interest there in something like CesiumGltf, and what people's expectations are for it. So, to the extent you can share, I'm really interested in that.

They don't want to see an "ERROR: There's Draco, and I don't know what to wo with that" when they try to load that file. They don't want to manually twiddle with additional dependencies. And they certainly don't want to re-implement something like decodeDraco.cpp.

They wouldn't see an error. But they would see a representation of the extension as it truly exists in the glTF file, without any built-in way to, say, decode the Draco buffer into vertices. If they need that, they would need to take another dependency.
But I think you're essentially making the same point Tim did. Pretty much no one wants to load a glTF without also wanting to decode Draco (for example).

So I think that a clean separation of the "core glTF code" and the "convenient glTF library" depends on a clean and good mechanism for handling extensions .

This is very doable, and I find it quite appealing. But I think what it boils down to is having even more glTF related libraries (such as your CesiumGltfKtx example). And then users that want a fully-functionaly glTF loader that supports all the things would need to either:

add all the dependencies and write the bit of code to register all the extensions, or
instead take a dependency on a higher-level library that pulls everything together.

And I think the point that both you and Tim made (and I largely agree) is that pretty much everyone will choose (2) when given the option. And in that case, why do the extra work of maintaining all these fine-grained libraries anyway?
Regardless, a pluggable glTF load/save pipeline is a really good idea, if for no other reason than so that it can be extended from outside cesium-native. The details are tricky. But yes, I think we should do this.

I'm convinced that there should be a Cesium3DMetadata library. Then, Cesium3DTiles could depend on this. And some CesiumGltfMetadata ("extension-plugin") library could also depend on this.

Yes. This would be much easier if the specs themselves referred to common JSON Schema.

Then I'd say that these are indeed things that are not related to glTF itself, but to the way how glTF is used within Cesium. So iff there was a Cesium glTF library (that supports Draco, KTX, Metadata and all the other "glTF-inherent stuff", maybe via plugins), then there could still be some CesiumGeospatialGltf library that contains these things that are not inherent to glTF itself, but specific for the context of geospatial applications.

Yeah true, that's a good point. The idea is that the Content library contains various ways to manipulate / modify / enhance a glTF. Not all of them are geospatial in nature. We could go finer-grained, of course. That's always my temptation and default move, honestly. But sometimes I'm reminded that that slippery slope eventually leads to a library per class. And what's the point of that, versus having all the functionality in a single library and the flexibility to #include the bits you need, and letting the linker sort it out? Like all slippery slope arguments, that obviously doesn't mean we shouldn't ever factor things out into separate libraries. We just need to be thoughtful about why we're doing it, rather than just doing it because these things are independent and so we can.

... how much interest there in something like CesiumGltf, and what people's expectations are for it.

I don't have specific insights into the demand for native/desktop glTF loader libraries. There has been some discussion on a high level, ~"which libraries do exist" or ~"how (and under which conditions) can certain forms of development of these libraries be supported", but no specific actions derived from that yet.
In terms of the expectations, I could try to summarize one takeaway message: glTF 2.0 is pretty much fixed and final. There will almost certainly not be a glTF 3.0 in the foreseeable future, and even a 2.1 seems to be unlikely. Basically all development of new features happens via extensions. This is why "handling extensions" is important on all levels (specifications, libraries, applications). Specifically: It is very likely that people will expect (all) ratified extensions to be supported. (That's where new development and maintenance effort for loader libraries will come from)

But I think what it boils down to is having even more glTF related libraries (such as your CesiumGltfKtx example)
[...]
[...] pretty much everyone will choose (2) when given the option. And in that case, why do the extra work of maintaining all these fine-grained libraries anyway?

This is one of the "usual trade-offs" points. And it's hard to strike the right balance here.
Two extremes:

KHR_texture_basisu: This is the "KTX extension". It refers to the specification of KTX itself. Supporting it in a library requires a dependency to KTX-Software (and from what I heard, that can be a pain in the back...), and a potentially considerable implementation effort. (Maybe Draco is in a similar ballpark)
KHR_materials_emissive_strength: This extension - with a whopping 21 contributors 🙂 - defines ... *drumroll*: A number. Yes. That's it. A single number.

Having a CesiumGltfTextureBasisu project that defines a KTX-reader plugin for the Cesium glTF loader would make a ton of sense, in terms of cleanly modeling dependencies, defining interfaces, managing build times, maintenance, etc.
Having a CesiumGltfMaterialsEmissiveStrength sub-project with directory and headers and CMake files that defines a "plugin" so that the Cesium glTF loader can read a single number would look bloated.
I think that rigurously saying "one project per extension, period!" would be nice and clean from a conceptual perspective (and avoid the burden to have to decide on a case-by-case basis). Given the potential overhead, one could argue for a middle ground, and, say, put all the ("simple") PBR extensions into a CesiumGltfRatifiedPbrExtensions project or so. But this should be thought trough in terms of evolvability and scalability.
In all cases, the question is still whether users will have to manually add/register these "extension projects", or whether there should be the complete (but bulky) off-the-shelf solution that contains everything by default.

This would be much easier if the specs themselves referred to common JSON Schema.

The JSON files are basically copy-and-pasted, basically to "make both specs 'standalone'".

We just need to be thoughtful about why we're doing it, rather than just doing it because these things are independent and so we can.

I couldn't say anything here that you're not aware of, and I certainly don't have experience with maintaining complex and evolving C++-projects over an extended period of time. But it's usually far easier to combine two things, than to nicely split a large library (that covered 'unrelated') domains. And to start with the more 'fine-grained' approach tends to have positive effects in terms of the clarity of the API and the dependency handling.

@dbs4261 Aggreed - the duplication was also shown in the screenshot in my comment above, and I said

I'm convinced that there should be a Cesium3DMetadata library. Then, Cesium3DTiles could depend on this. And some CesiumGltfMetadata ("extension-plugin") library could also depend on this.

In some way, that's independent of the glTF library question (or at least, it's one chunk of work that could be carved out and addressed more or less independently).

Yeah I agree too in principle @dbs4261. Getting there is a little tricky...


[FLINK-7209] [table] Support DataView in Tuple and Case Class as the ACC type of AggregateFunction

What is the purpose of the change
This pull request adds support of DataView in Tuple and Case Class as the accumulator type of AggregateFunction
Brief change log

Updates UserDefinedFunctionUtils#removeStateViewFieldsFromAccTypeInfo to process TupleTypeInfo and CaseClassTypeInfo for DataView
Updates MapViewTypeInfo and ListViewTypeInfo to use NullSerializer for serialization when state backend is used

Verifying this change
This change added tests and can be verified as follows:

Updated tests of AggregateITCase#testGroupAggregateWithStateBackend

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

@walterddr Thanks a lot for your review. Agree with you that all the code paths should be well tested. This PR only adds some test cases for CaseClass/Tuple as the accumulator type as other code paths can be well tested by existing test cases. Please let me know if you found any code paths which are not tested. Thanks again!


[Bug] You do not have permission to create that determination

Description
Users are getting this error message when they're sending out determinations.

I think it is this code:
https://github.com/HyphaApp/hypha/blob/a77349a073eeeac06d7c2cc2398e9078af68e40c/hypha/apply/determinations/permissions.py#L13-L17

@fourthletter Is it so staff can not post determinations at all? Or does the bug only show up for some submission and/or some users?

@frjo Staf could post determinations according to the mail log. They receive this error message occasionally. This is occuring across multiple Funds so it's not only one.

@fourthletter So the determination is always posted in order but then they get this error?

@frjo
A PM sends out three determinations from a single Fund. According to the mail log every determination was sent. One of the applicants reported they did NOT receive the message, but the other two received the determination. The PM received this error message when they sent out this determination.  This PM is the 'Lead' of this Fund. I thought this was a one off bug.
A second PM reported they received a similar message when they sent out a determination from a different fund. They were not the 'Lead' of that Fund.


Diff editor scroll bar too thick

VSCode Version: 1.44.2
OS Version: windows 10 pro 1909

Steps to Reproduce:

change file
click git changes

Scroll bar looks weird isn't it?

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

@sungle3737 The diff editor scrollbar includes something called a diff overview ruler. Normally, this shows additions and deletions across the two files, e.g.:

From your screenshot, it appears that it is colored in one single block color. Also, from your screenshot, it appears to me that you are using a custom theme or you are perhaps using color customizations in your settings.json.
Can you please switch back to the default theme / remove any color customizations from your settings.json?

 "scrollbarSlider.activeBackground": "#98c2bead",

yes i added transparency it works! thank you!


Zero new elements when calling OperandStack::pushn()

This is done mainly so that locals are zeroed on function entry
Signed-off-by: Devin Nakamura<EMAIL_ADDRESS>

thanks


MONGO_URL not found; but it's there

Hi guys,
Any help will be really appreciated. Feel free to ask for more info.
Contents

What I'm trying to do
Issue
Terminal output
mup.js
settings.json

What I'm trying to do
I'm deploying from a windows machine using MingW32 and deployment is to a Ubuntu 16.04 LTS on Google Cloud.
I'm using mupx from https://github.com/arunoda/meteor-up/tree/mupx

Issue
My MONGO_URL is not getting picked up.

Terminal output
Here's what I see in my command prompt; Error at the end:
Dheeraj@DESKTOP-P9VSJPN MINGW32 /c/my-home/ide-home/WebStormProjects/ibmh (adding-home-page)
$ mupx setup
\
Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Configuration file : mup.json
Settings file      : settings.json

“ Checkout Kadira!
  It's the best way to monitor performance of your app.
  Visit: https://kadira.io/mup ”

Started TaskList: Setup (linux)
[<ip redacted>] - Installing Docker
[<ip redacted>] - Installing Docker: SUCCESS
[<ip redacted>] - Setting up Environment
[<ip redacted>] - Setting up Environment: SUCCESS

Dheeraj@DESKTOP-P9VSJPN MINGW32 /c/my-home/ide-home/WebStormProjects/ibmh (adding-home-page)
$ mupx deploy

Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Configuration file : mup.json
Settings file      : settings.json

“ Checkout Kadira!
  It's the best way to monitor performance of your app.
  Visit: https://kadira.io/mup ”

Meteor app path    : C:\my-home\ide-home\WebStormProjects\ibmh
Using buildOptions : {}
packages/reactioncommerce_core-theme/ibmh/css/master.css: warn: @charset rules in this file will be ignored as UTF-8 is the only encoding supported

Started TaskList: Deploy app 'ibmh' (linux)
[<ip redacted>] - Uploading bundle
[<ip redacted>] - Uploading bundle: SUCCESS
[<ip redacted>] - Sending environment variables
[<ip redacted>] - Sending environment variables: SUCCESS
[<ip redacted>] - Initializing start script
[<ip redacted>] - Initializing start script: SUCCESS
[<ip redacted>] - Invoking deployment process
[<ip redacted>] - Invoking deployment process: SUCCESS
[<ip redacted>] - Verifying deployment
[<ip redacted>] x Verifying deployment: FAILED

        -----------------------------------STDERR-----------------------------------
        eor-promise

<EMAIL_ADDRESS>node_modules/promise

<EMAIL_ADDRESS>node_modules/source-map-support

<EMAIL_ADDRESS>node_modules/semver

<EMAIL_ADDRESS>node_modules/source-map

<EMAIL_ADDRESS>node_modules/fibers
        => Starting meteor app on port:80

        /bundle/bundle/programs/server/node_modules/fibers/future.js:245
                                                        throw(ex);
                                                              ^
        Error: MONGO_URL must be set in environment
            at Object.<anonymous> (packages/mongo/remote_collection_driver.js:36:1)
            at Object.defaultRemoteCollectionDriver (packages/underscore/underscore.js:750:1)
            at new Mongo.Collection (packages/mongo/collection.js:102:1)
            at AccountsServer.AccountsCommon (accounts_common.js:23:18)
            at new AccountsServer (accounts_server.js:16:5)
            at Package (globals_server.js:5:12)
            at /bundle/bundle/programs/server/packages/accounts-base.js:1814:4
            at /bundle/bundle/programs/server/packages/accounts-base.js:1825:3
            at /bundle/bundle/programs/server/boot.js:242:10
            at Array.forEach (native)
        -----------------------------------STDOUT-----------------------------------

        To see more logs type 'mup logs --tail=50'

        ----------------------------------------------------------------------------

Dheeraj@DESKTOP-P9VSJPN MINGW32 /c/my-home/ide-home/WebStormProjects/ibmh (adding-home-page)
$ mupx logs --tail

Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Configuration file : mup.json
Settings file      : settings.json

[<ip redacted>] docker: "logs" requires 1 argument.
See 'docker logs --help'.
[<ip redacted>]
Usage:  docker logs [OPTIONS] CONTAINER[<ip redacted>]

Fetch the logs of a container

Dheeraj@DESKTOP-P9VSJPN MINGW32 /c/my-home/ide-home/WebStormProjects/ibmh (adding-home-page)
$ mupx logs --tail=50

Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Configuration file : mup.json
Settings file      : settings.json

[<ip redacted>] => Starting meteor app on port:80
[<ip redacted>] Error: MONGO_URL must be set in environment
    at Object.<anonymous> (packages/mongo/remote_collection_driver.js:36:1)
    at Object.defaultRemoteCollectionDriver (packages/underscore/underscore.js:750:1)
    at new Mongo.Collection (packages/mongo/collection.js:102:1)
    at AccountsServer.AccountsCommon (accounts_common.js:23:18)
    at new AccountsServer (accounts_server.js:16:5)
    at Package (globals_server.js:5:12)
    at /bundle/bundle/programs/server/packages/accounts-base.js:1814:4
    at /bundle/bundle/programs/server/packages/accounts-base.js:1825:3
    at /bundle/bundle/programs/server/boot.js:242:10
    at Array.forEach (native)
npm WARN deprecated This version of npm lacks support for important features,
npm WARN deprecated such as scoped packages, offered by the primary npm
npm WARN deprecated registry. Consider upgrading to at least npm@2, if not the
npm WARN deprecated latest stable version. To upgrade to npm@2, run:
npm WARN deprecated
npm WARN deprecated   npm -g install npm@latest-2
npm WARN deprecated
npm WARN deprecated To upgrade to the latest stable version, run:
npm WARN deprecated
npm WARN deprecated   npm -g install npm@latest
npm WARN deprecated
npm WARN deprecated (Depending on how Node.js was installed on your system, you
npm WARN deprecated may need to prefix the preceding commands with `sudo`, or if
npm WARN deprecated on Windows, run them from an Administrator prompt.)
npm WARN deprecated
npm WARN deprecated If you're running the version of npm bundled with
npm WARN deprecated Node.js 0.10 LTS, be aware that the next version of 0.10 LTS
npm WARN deprecated will be bundled with a version of npm@2, which has some small
npm WARN deprecated backwards-incompatible changes made to `npm run-script` and
npm WARN deprecated semver behavior.
npm WARN package.json<EMAIL_ADDRESS>No description
npm WARN package.json<EMAIL_ADDRESS>No repository field.
npm WARN package.json<EMAIL_ADDRESS>No README data

/bundle/bundle/programs/server/node_modules/fibers/future.js:245
                                                throw(ex);
                                                      ^
Error: MONGO_URL must be set in environment
    at Object.<anonymous> (packages/mongo/remote_collection_driver.js:36:1)
    at Object.defaultRemoteCollectionDriver (packages/underscore/underscore.js:750:1)
    at new Mongo.Collection (packages/mongo/collection.js:102:1)
    at AccountsServer.AccountsCommon (accounts_common.js:23:18)
    at new AccountsServer (accounts_server.js:16:5)
    at Package (globals_server.js:5:12)
    at /bundle/bundle/programs/server/packages/accounts-base.js:1814:4
    at /bundle/bundle/programs/server/packages/accounts-base.js:1825:3
    at /bundle/bundle/programs/server/boot.js:242:10
    at Array.forEach (native)

Dheeraj@DESKTOP-P9VSJPN MINGW32 /c/my-home/ide-home/WebStormProjects/ibmh (adding-home-page)
$

mup.js
{
  // Server authentication info
  "servers": [
    {
      "host": "<ip redacted>",
      "username": "ibmh",
      // or pem file (ssh based authentication)
      // WARNING: Keys protected by a passphrase are not supported
      "pem": "~/.ssh/id_rsa_ibmh_gcloud",
      // Also, for non-standard ssh port use this
      //"sshOptions": { "port" : 49154 },
      // server specific environment variables
      "env": {}
    }
  ],

  // Install MongoDB on the server. Does not destroy the local MongoDB on future setups
  "setupMongo": false,

  // Application name (no spaces).
  "appName": "ibmh",

  // Location of app (local directory). This can reference '~' as the users home directory.
  // i.e., "app": "~/Meteor/my-app",
  // This is the same as the line below.
  "app": "C:\\my-home\\ide-home\\WebStormProjects\\ibmh",

  // Configure environment
  // ROOT_URL must be set to your correct domain (https or http)
  "env": {
    "PORT": 80,
    "ROOT_URL": "http://<ip redacted>/"
  },

  // Meteor Up checks if the app comes online just after the deployment.
  // Before mup checks that, it will wait for the number of seconds configured below.
  "deployCheckWaitTime": 15,

  // show a progress bar while uploading.
  // Make it false when you deploy using a CI box.
  "enableUploadProgressBar": true
}

settings.json
{
  "ROOT_URL": "",
  "MONGO_URL": "<redacted>",
  "MAIL_URL": "<redacted>",
  "reaction": {
    "REACTION_USER": "ibmh",
    "REACTION_AUTH": "ibmh",
    "REACTION_EMAIL"<EMAIL_ADDRESS>  },
  "isDebug": "info",
  "public": {}
}

Just checked the env vars on the VM:
dheerajthe1@ibmh-prod-1:~$ echo $MONGO_URL
dheerajthe1@ibmh-prod-1:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
dheerajthe1@ibmh-prod-1:~$ echo $MAIL_URL
dheerajthe1@ibmh-prod-1:~$

Looks like none of the vars got set. Is this weirdly because I set "setupMongo": false, ?

I tried deployment from commandline (cmd.exe). Same issue. Here's the output:
C:\my-home\ide-home\WebStormProjects\ibmh>mupx deploy

Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Configuration file : mup.json
Settings file      : settings.json

“ Checkout Kadira!
  It's the best way to monitor performance of your app.
  Visit: https://kadira.io/mup ”

Meteor app path    : C:\my-home\ide-home\WebStormProjects\ibmh
Using buildOptions : {}
packages/reactioncommerce_core-theme/ibmh/css/master.css: warn: @charset rules in this file will be ignored as UTF-8 is the only
 encoding supported

Started TaskList: Deploy app 'ibmh' (linux)
[<ip redacted>] - Uploading bundle
[<ip redacted>] - Uploading bundle: SUCCESS
[<ip redacted>] - Sending environment variables
[<ip redacted>] - Sending environment variables: SUCCESS
[<ip redacted>] - Initializing start script
[<ip redacted>] - Initializing start script: SUCCESS
[<ip redacted>] - Invoking deployment process
[<ip redacted>] - Invoking deployment process: SUCCESS
[<ip redacted>] - Verifying deployment
[<ip redacted>] x Verifying deployment: FAILED

        -----------------------------------STDERR-----------------------------------

<EMAIL_ADDRESS>node_modules/source-map-support

<EMAIL_ADDRESS>node_modules/semver

<EMAIL_ADDRESS>node_modules/source-map

<EMAIL_ADDRESS>node_modules/fibers
        => Starting meteor app on port:80

        /bundle/bundle/programs/server/node_modules/fibers/future.js:245
                                                        throw(ex);
                                                              ^
        Error: MONGO_URL must be set in environment
            at Object.<anonymous> (packages/mongo/remote_collection_driver.js:36:1)
            at Object.defaultRemoteCollectionDriver (packages/underscore/underscore.js:750:1)
            at new Mongo.Collection (packages/mongo/collection.js:102:1)
            at AccountsServer.AccountsCommon (accounts_common.js:23:18)
            at new AccountsServer (accounts_server.js:16:5)
            at Package (globals_server.js:5:12)
            at /bundle/bundle/programs/server/packages/accounts-base.js:1814:4
            at /bundle/bundle/programs/server/packages/accounts-base.js:1825:3
            at /bundle/bundle/programs/server/boot.js:242:10
            at Array.forEach (native)

        => Redeploying previous version of the app

        -----------------------------------STDOUT-----------------------------------

        To see more logs type 'mup logs --tail=50'

        ----------------------------------------------------------------------------

I'm going to manually set the env vars to get this to work, but I hope you understand that that's not at all ideal.

I tried to fiddle with the containers, this output was unexpected. What am I doing wrong?
dheerajthe1@ibmh-prod-1:~$ docker ps
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

I was checking the setup-env.sh and checked the env vars file generated. Here it is:
ROOT_URL=<redacted>
#it is possible to override above env-vars from the user-provided values
  ROOT_URL=<redacted>
  METEOR_SETTINGS=<redacted>
  CLUSTER_ENDPOINT_URL=<redacted>

As expected, the MONGO_URL was missing. This must be a script error somewhere. For the time being I'm planning to edit this.

Adding MONGO_URL manually to env.list made the app work. I plan to figure out why it wasn't there in the first place. I will give a PR if I figure out.
Please help out if possible.

Ya I was just going to say "env" but you should know the new version is at kadirahq/meteor-up if you plan to submit any PRs. These are depreciated by it.

Would you suggest I use the new version?
Is it usable enough for production?
Also, Is this bug fixed there?
On Fri 29 Apr, 2016, 12:34 PM Master James<EMAIL_ADDRESS>wrote:

Ya I was just going to say "env" but you should know the new version is at
kadirahq/meteor-up if you plan to submit any PRs. These are depreciated by
it.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/arunoda/meteor-up/issues/989#issuecomment-215643130

--
--- Disclaimer --- The information in this mail is confidential and is
intended solely for addressee. Access to this mail by anyone else is
unauthorised. Copying or further distribution beyond the original recipient
may be unlawful. Any opinion expressed in this mail is that of sender and
does not necessarily reflect that of OSW Technologies Pvt Ltd.---

I'm uncertain. Let me know your experience but it's certainly the way forward.
It's in flux so it's not as "stable" in a sense, as it is in a state of transformation.
They're are the devs so they will be able to help sort out what issue is at fault.

Okay, let me check out the new version then.
Thanks for the quick replies so far James.
On Fri 29 Apr, 2016, 5:54 PM Master James<EMAIL_ADDRESS>wrote:

I'm uncertain. Let me know your experience but it's certainly the way
forward.
It's in flux so it's not as "stable" in a sense, as it is in a state of
transformation.
They're are the devs so they will be able to help sort out what issue is
at fault.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/arunoda/meteor-up/issues/989#issuecomment-215697670

--
--- Disclaimer --- The information in this mail is confidential and is
intended solely for addressee. Access to this mail by anyone else is
unauthorised. Copying or further distribution beyond the original recipient
may be unlawful. Any opinion expressed in this mail is that of sender and
does not necessarily reflect that of OSW Technologies Pvt Ltd.---

You're setting your environment variables in settings.json, and you should be setting them under env in mup.js, along with the PORT and ROOT_URL. That's why it's not picking them up.

@ianmartorell Oh, I thought that was if we needed any custom env for a particular server. That's because the comment reads as follows:
  // server specific environment variables
  "env": {}

I shall try this. Thanks.

This worked. Thanks


make docs GUI to be generated during the build instead of downloading it from external place

using swagger-ui is better, for example: you can send sample requests directly from it in swagger-ui


Images for kotlinpoet, leakcanary, moshi, okhttp, okio, retrofit

Also remove obsolete projects.
Also regenerate index.html

I'd like to add for Workflow too – what's your process for generating these?

Instructions are in the readme!
https://github.com/square/square.github.io#update-list-of-repos

Saw that, thought there might be more to it. Thanks!


Xcode 7 Swift 2.0 Compilation Fix

Release Notes

Compiler was complaining that unsignedInteger was not allowed for UInt's, so I switched to unsignedLong

Thanks @jglawrence, that's very odd. It should be unsignedInteger and not unsignedLong (even though both can compile). Can you share the compiler warning you experienced?

@marmelroy before merging this, let me test it in Xcode 7.2. Maybe there was some weirdness in 7.0.1.
I'll post a screenshot of the error tonight.

Well, looks like this is no longer an issue in Xcode 7.2! Oh well!
Thanks for the work on this, very helpful library @marmelroy

Thanks @jglawrence!


replicate.run stopped working

const replicate = new Replicate({
  useFileOutput: false,
});

const output = await replicate.run(
    "microsoft/bringing-old-photos-back-to-life:c75db81db6cbd809d93cc3b7e7a088a351a3349c9fa02b6d393e35e0d51ba799",
    {
      input: {
        image: inputImageUrl,
      },
    },
  );

  console.log(output); // this is undefined  now

I started having issues with replicate-javascript since yesterday. Replicate run always seem to return undefined. But I can see predictions being successful in the dashboard.  I'm using v1.0.0, and I tried upgrading to v1.0.1 as well.

I also experienced this problem. Sometimes output is undefined or [undefined], albeit successful in dashboard

Getting similar issues, it just seems to be returning a long readableStream.
utput [
  FileOutput {
  [Symbol(kType)]: 'ReadableStream',
  [Symbol(kState)]: <ref *1> {
  disturbed: false,
  reader: undefined,
  state: 'readable',
  storedError: undefined,
  stream: undefined,
  transfer: {
  writable: undefined,
  port1: undefined,
  port2: undefined,
  promise: undefined
},...]

Downgrading to @0.31.1 fixed it.
Haven't tried any version in between from 0.31 -> 1.0.1

@AakashKB That's a normal behavior. should read this release note

This was a problem with the API itself sometimes returning a prediction object in an invalid state. That issue should now be fixed. Thanks again for the report!

I'm still seeing ReadableStream being returned for 1.0.1.  I've tried 3 different models, all using example input from docs.

@customlogic As I said above, that's a normal behavior. should read this release note

@customlogic As I said above, that's a normal behavior. should read this release note

Thanks, after I wrote the comment I found the documentation on github.  I think the problem is that there's a mismatch between this update and the examples on the main Replicate site. As it stands now, ALL examples on the site are broken.


Delete deploy scripts from package.json

Because master is now a protected branch, there is no use for the
deploy scripts anymore. These scripts combined the versioning, pushing
tags and publishing, however we are no longer able to perform these
actions all at once.

I think I'll leave these scripts in for admins.


feat: Azure deployment k8s StorageClass for stream-api

Jira :https://keboola.atlassian.net/browse/ST-1962
please see:
https://keboola.atlassian.net/wiki/spaces/ENGG/pages/3514040374/Cloud+storage+benchmarks#Azure--(VM-node:-Standard_F4s_v2)
I got up to about 173 MB/s. But we don't have a better instance than Standard_F4s_v2 for testing. We have a larger VM size in production, so we can always tune the speed there.
Changes:
new Kubernetes storage class for Azure dedicated to stream-api service
Plan:

[x]  set ENV to VG for Azure testing
[x]  review & merge this
[x]  deploy to testing Azure stack
[ ]  run benchmarks
[ ]  compare benchmarks with GCP
[ ]  decide if we need some changes based on benchmark results

@Matovidlo je to na testingu nasazené


What tools to use to generate arrayOfPeaks?

On your page http://www.wavesurfer.fm/example/audio-element I was reading that it is possible to prove an arrayOfPeaks to wave surfer that is generated prior (on the server). Out of curiosity, what tools do you suggest to generate the arrayOfPeaks or arrive at it? Thanks of your support.

These programs:
https://github.com/beschulz/wav2json
https://github.com/bbcrd/audiowaveform
Just make sure you generate an array of floats. The length doesn't matter. To keep it small it's often OK to have the floats rounded to 3-4 digits.

Thanks, that's great!


MAISTRA-2107 Validate shell scripts with shellcheck

@luksa create the prow job for it, then we can run the test on this very PR! :)

/retest

/test all

/test all

Thanks! I was just typing a comment to ask you how to do this :)

@luksa JFYI, this is the version of shellcheck we are using: https://github.com/maistra/test-infra/blob/main/docker/maistra-builder_2.3.Dockerfile#L22

We should update it to 0.8.0


Added 'australieast'

Australia East is now a supported region: https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models

Cancelled: Australia East, contains GPT Models but not: text-embedding-ada-002.


fix the single page userguide to link to the new 5.0 upgrade guide location

The name of the .adoc file was changed previously, but the link was not updated until now.

Cherry-picked to release


Creating ADT messages from Synthea csv output

Has anyone found a reliable tool to create HL7 ADT messages from the csv output files?

Hi Joseph, we've had a few teams internally investigating this for a while now and discussed it with Jason at DevDays.
Essentially, there is not enough information in the current output to create useful ADT messages because there is no Scheduling module in Synthea.
One option we are looking at is to create the module and merge it back into the main branch.
Another is to implement a 'fake' scheduling module based on the output (e.g., random amounts of time backward from encounter, randomly cancel and recreate appointments, etc.).  This would read in the existing output and generate the messages from it.
In either case, we have been working to try and define what useful data looks like (e.g., which messages should we focus on creating).
Do you have specific messages or a specific use case?

We would most likely be interested in ADT message types of the following to start:
ADT-A01 – patient admit
ADT-A02 – patient transfer
ADT-A03 – patient discharge
ADT-A04 – patient registration
ADT-A05 – patient pre-admission
ADT-A08 – patient information update
ADT-A11 – cancel patient admit
ADT-A12 – cancel patient transfer
ADT-A13 – cancel patient discharge
ADT-A31 - update person information
Thanks!
[Image result for crisp hie logo]
Joe Haney
Integrations Team Lead
CRISP Health | 7160 Columbia Gateway Drive, Suite 100
Columbia, MD 21046
(p)<PHONE_NUMBER>
(e) joseph.haney<EMAIL_ADDRESS>http://www.crisphealth.orghttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.crisphealth.org%2F&data=02|01|jmilam%40cardinalsolutions.com|2139c11ad9ef43f89d3208d4d47195d8|414efc3368fe4520802faea4401192d0|0|0|636367031687675548&sdata=Dh9HYtFywTzEkZv9%2BNvwG%2B8qxnWPq%2FyiUtZ3Q7TwEyY%3D&reserved=0
From: Gino Canessa<EMAIL_ADDRESS>Sent: Thursday, June 27, 2019 12:43 PM
To: synthetichealth/synthea<EMAIL_ADDRESS>Cc: Joseph Haney<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [synthetichealth/synthea] Creating ADT messages from Synthea csv output (#535)
Hi Joseph, we've had a few teams internally investigating this for a while now and discussed it with Jason at DevDays.
Essentially, there is not enough information in the current output to create useful ADT messages because there is no Scheduling module in Synthea.
One option we are looking at is to create the module and merge it back into the main branch.
Another is to implement a 'fake' scheduling module based on the output (e.g., random amounts of time backward from encounter, randomly cancel and recreate appointments, etc.). This would read in the existing output and generate the messages from it.
In either case, we have been working to try and define what useful data looks like (e.g., which messages should we focus on creating).
Do you have specific messages or a specific use case?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/synthetichealth/synthea/issues/535?email_source=notifications&email_token=AMO6TF3OLVWVKYCGPFYLTIDP4TUYZA5CNFSM4H35WAKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYXWPDQ#issuecomment-506423182, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMO6TF3FNDSEWJNUD7NT2G3P4TUYZANCNFSM4H35WAKA.
WARNING: This email originated outside of CRISP. Even if this looks like a CRISP email, it is not. DO NOT CLICK links or attachments unless you are positive the content is safe. ------------ This email originates from outside your organization. Do not click on any links or open attachments unless you recognize the sender and have verified that the contained content is safe.

The contents of this e-mail and any attachments are intended solely for the use of the named addressee(s) and may contain confidential and/or privileged information. Any unauthorized use, copying, disclosure, or distribution of the contents of this e-mail is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete this email.
Thank you.

FWIW this is not open source, but: I have successfully fed Synthea data into a Smile CDR FHIR repo and then used the standard HL7v2 transforms to get v2.x feeds for various data types out of it for testing.

Gino,
We are Maryland’s designated state-wide Health Information Exchange (HIE) and will use this ADT data to test new and existing integrations via Mirth Connect interfaces.  With this test data, we can segment our channel/transformation logic testing away from any production systems and use realistic but non-production data for confirmation of any new integrations or any necessary changes to existing integrations.  With the expansions of national networks on the horizon, the testing data could become invaluable to meeting designated timelines, etc.
Let me know your thoughts.
[Image result for crisp hie logo]
Joe Haney
Integrations Team Lead
CRISP Health | 7160 Columbia Gateway Drive, Suite 100
Columbia, MD 21046
(p)<PHONE_NUMBER>
(e) joseph.haney<EMAIL_ADDRESS>http://www.crisphealth.orghttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.crisphealth.org%2F&data=02|01|jmilam%40cardinalsolutions.com|2139c11ad9ef43f89d3208d4d47195d8|414efc3368fe4520802faea4401192d0|0|0|636367031687675548&sdata=Dh9HYtFywTzEkZv9%2BNvwG%2B8qxnWPq%2FyiUtZ3Q7TwEyY%3D&reserved=0
From: Gino Canessa<EMAIL_ADDRESS>Sent: Thursday, June 27, 2019 12:43 PM
To: synthetichealth/synthea<EMAIL_ADDRESS>Cc: Joseph Haney<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [synthetichealth/synthea] Creating ADT messages from Synthea csv output (#535)
Hi Joseph, we've had a few teams internally investigating this for a while now and discussed it with Jason at DevDays.
Essentially, there is not enough information in the current output to create useful ADT messages because there is no Scheduling module in Synthea.
One option we are looking at is to create the module and merge it back into the main branch.
Another is to implement a 'fake' scheduling module based on the output (e.g., random amounts of time backward from encounter, randomly cancel and recreate appointments, etc.). This would read in the existing output and generate the messages from it.
In either case, we have been working to try and define what useful data looks like (e.g., which messages should we focus on creating).
Do you have specific messages or a specific use case?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/synthetichealth/synthea/issues/535?email_source=notifications&email_token=AMO6TF3OLVWVKYCGPFYLTIDP4TUYZA5CNFSM4H35WAKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYXWPDQ#issuecomment-506423182, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMO6TF3FNDSEWJNUD7NT2G3P4TUYZANCNFSM4H35WAKA.
WARNING: This email originated outside of CRISP. Even if this looks like a CRISP email, it is not. DO NOT CLICK links or attachments unless you are positive the content is safe. ------------ This email originates from outside your organization. Do not click on any links or open attachments unless you recognize the sender and have verified that the contained content is safe.

The contents of this e-mail and any attachments are intended solely for the use of the named addressee(s) and may contain confidential and/or privileged information. Any unauthorized use, copying, disclosure, or distribution of the contents of this e-mail is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete this email.
Thank you.

Hi Joe, that sounds like a great use case and well defined message requirements.  We are sorting out the best approach internally right now - I will update this thread as soon as I have more concrete info from our side.
Did you have a specific timeline you are meeting, or just a general "as soon as possible"?

For what it's worth... We use an external system data in SQL (Query and SSIS Packaging) to make a final txt file in ADT^A31 for new patient creation.   So maybe loading the CSV to a SQL table, do the data mapping, and writing the code for it is an option?

Hi Joe, that sounds like a great use case and well defined message requirements. We are sorting out the best approach internally right now - I will update this thread as soon as I have more concrete info from our side.
Did you have a specific timeline you are meeting, or just a general "as soon as possible"?

Any update on this?

Nothing testable - have you tried Jame's process (e.g., loading data into a FHIR server and using the v2 transforms)?

Using Smile CDR just for this doesn't fit our budget unfortunately.

I created a tool for this purpose - https://github.com/mayankthebest/MayaMaker

@mayankthebest I looked at your tool, and tried out the public instance, and it seems to work (although I don't use HL7 v2 enough to comment on the results). Cool!

hi @jawalonoski, we are currently building a HL7v2.5 exporter for synthea and I was looking into this issue and have a question: is there any way to use a module to build a in-house referral chain? If the encouter-type == inpatient then encounter has various stays within the hospital on different wards?

@hannesUlrich There is no "referral" state in the module builder or engine today, there is also no concept to capture ward information. The closest thing you can do is just have a series of inpatient encounters (like the Covid19 module) with different codes (e.g. ICU) or insert a "Procedure" with a code that is a child of the SNOMED referral code (3457005) between the encounters.

Alternatively, you could use the Health Record Editors feature to add additional information to inpatient encounters after they end. You would have to extend the State.Encounter class to hold that extra information. The advantage of this is that it could work on encounters from any module rather than you having to edit each module separately.


Typo "availalbe" in order confirmation email

The order confirmation email (subject: "EuroPython2019: Order confirmation") sports a typo at the lower half of the email template:

Your tickets were created and are availalbe on your profile page here:

Should probably read "available" in that sentence.

Thanks for catching this, @bittner ! Should be fixed soon :)

Thank you for fixing it!


Respect list style of hierarchy

When changing the hierarchy with tab between numbered and unnumbered lists, the style only seems to be adapted in one direction:
1. test
2. test
3. test
    - a
    - b <Cursor>
    - c
4. test

Upon <S-Tab>, the line correctly changes to 4. b. But using <Tab> then doesn' change it back yielding
1. test
2. test
3. test
    - a
    4. b <Cursor>
    - c
4. test

Using the default configuration and the plugin as it is on main at the time of this comment, this is how it behaves for me. This seems to be the behavior that you're after.

Can you provide more information?


feat: upgrades to<EMAIL_ADDRESS>

feat: upgrades to<EMAIL_ADDRESS>ci(.github/workflows): upgrades to node@18.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#39  👈
#38
#37
#36
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @matthewhartstonge and the rest of your teammates on  Graphite


If you have more formats than items, you get an error in python but not perl

If you have more formats than items, you get an error in python but not perl, for example:
my $r = sprintf("%s")

Fixed in v0.985


Create 0000-01-02-JavierMeisnitzer.md

created a file and made a commit, and opened a pull request

help again


(Fix) Remove MM warning and fix white pending tx page

We shouldn't create a request to get token symbol and decimals, if a destination address is not a contract. Sometimes it causes a white screen for pending tx page.
Also, MM warning about EIP-1102 implementation is removed.
@dennis00010011b @fvictorio @patitonar please take a look.
Should be merged to master and released as soon as possible.

Tests are successful eventually


Script for visualizing the probability and magnitude hyperparameters

Could you please publish the script for drawing these fancy visualizations?

Probability Hyperparameters over Time
Magnitude Hyperparameters over Time

This was done in google sheets / charts :)

Alright. I will manage to write a Python script to plot similar graphs using matplotlib. It helps to gain some insights into the augmentation schedule learned.


change to svg images

Because they look nicer!

Hi,
sorry - but as per contribution guidelines we need a CLA in place before we can accept a PR... but as it's a tiny edit I'm happy to apply manually if you like ?

Yes, thanks!


Question Forum

I know this is the complete wrong way but i could not find any other way of asking a question.
Is there a Forum where we as users from bosun ( New user ) can ask questions.
Marcel Koert

You can ask on Stack Overflow, we monitoring the feed for the site.


showInputBox does not pass preset value

VSCode Version: 1.5.2
OS Version: OSX 10.11.6

Steps to Reproduce:

use vscode.window.showInputBox
pass a string to the value options field
Hit enter

Please have a look at the following code:
window.showInputBox({
    prompt: 'Please enter a variable name for the default export',
    placeHolder: 'Default export name',
    value: declaration.name,
    validateInput: s => !!s ? '' : 'Please enter a variable name'
}).then(defaultAlias => {
    if (defaultAlias) {
        console.log('something set!');
    }
}));

The value in the value field of the options hash is not passed, when the user just hits "enter". So if the user is fine with my prediction, an empty string is passed to the promise. The problem is, that this also happens when the user hits escape.
In my opinion, showInputBox should pass the inserted value to the promise IF the user hits enter and undefined when the user hits escape.
Cheers

dupe of #11503


VR reply packets - interface mismatch

ISSUE TYPE

Bug Report

COMPONENT NAME
VR

CLOUDSTACK VERSION
4.14.1 and onwards

CONFIGURATION
Advanced networking with at least 2 public ranges
Network with one source NAT IP on one range, enable static NAT IP from the other public range
OS / ENVIRONMENT
Tested with Vmware 6.7
SUMMARY
The outgoing traffic for VMs goes from one VR interface when the request is initiated within the VM, however if the request comes from the internet to the static NAT IP, then the reply goes from a different VR interface
STEPS TO REPRODUCE
- Add an additional public range on the physical network for a zone
- Create a network and deploy a VM on it
- Acquire an additional public IP from the new range on the network
- Enable static NAT on the new IP
- Verify a new VR interface has been created
- (if necessary enable egress rules)
- From within the VM, ping a server outside the network -> Verify the traffic on the VR goes through one interface (for example with tcpdump)
- From outside the network, ping the VM static NAT IP -> Verify the request on VR arrives to the same interface as the step above but the reply is sent through a different interface

EXPECTED RESULTS
Same interface is used for the outgoing traffic

ACTUAL RESULTS
root@r-18-VM:~# tcpdump -i eth4 icmp -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth4, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:23:45.383531 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 9332, seq 72, length 64
16:23:46.383363 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 9332, seq 73, length 64
16:23:47.394501 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 9332, seq 74, length 64
16:23:48.389304 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 9332, seq 75, length 64
16:23:49.394640 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 9332, seq 76, length 64

root@r-18-VM:~# tcpdump -i eth2 icmp -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:23:53.407090 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 9332, seq 80, length 64
16:23:54.406632 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 9332, seq 81, length 64
16:23:55.414142 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 9332, seq 82, length 64
16:23:56.411103 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 9332, seq 83, length 64
16:23:57.412352 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 9332, seq 84, length 64

@weizhouapache did we fix this, or is this a different issue?

@DaanHoogland is not fixed, I was able to reproduce it on 4.17.0


Major rework

A big mess of changes:

Update everything to handle both planes
Non linear elements
Dispersion with non linear elements
Change name to pyaccelerator to prepare for pypi upload
Tune computation
Chromaticity computation (still some misteries)
Dipsersion, tune, chromaticity matching (not thoroughly tested)
Add element strength dp/p dependence
And probably some other things I don't remember

I will also be moving the tutorials out of this repo to make sure no nosey students end up finding them. I will be moving them to a private repo: https://github.com/loiccoyle/pyaccelerator_tutorials


Mount the root filesystem by label rather than path

Support identifying the root filesystem via a kernel command line like
'ostree_root=LABEL=mylabel'. Also make it mount a filesystem labeled 'otaroot'
by default.
This means it is possible to test the Minnowboard build in Qemu.

Review score: 11/11


Thesis: Write evaluation of 3 dirty tile detection approaches

Describe 3 different approaches to detect dirty tiles

tile-cover + updated geometries from postgis
recursive CTE + updated geometries
insert trigger with recursive CTE on single geometrie

Wrote low quality  text so we don't forget those chapters later.
But definitly needs to be revisited in the writing phase again.


Not all ACS locations actually available for k8s

In the Azure Quick Start docs, we suggest running this command to discover what locations exist for container services:
$ az account list-locations --query [].name --output tsv
eastasia
southeastasia
centralus
eastus
eastus2
westus
northcentralus
southcentralus
northeurope
westeurope
westus2
....

However, many of those locations will later fail when trying to actually create the service:
$  az acs create --resource-group="${AZURE_RG_NAME}" --location="${AZURE_DC_LOCATION}" \
>   --orchestrator-type=kubernetes --master-count=1 --agent-count=1 \
>   --agent-vm-size="Standard_D2_v2" \
>   --admin-username="matt" \
>   --name="${AZURE_SERVICE_NAME}" --dns-prefix="mboersma" \
>   --ssh-key-value @/Users/matt/.ssh/id_rsa.pub
creating service principal.........done
waiting for AAD role to propagate.done
The provided location 'westus2' is not available for resource type 'Microsoft.ContainerService/containerServices'. List of available regions for the resource type is 'japaneast,centralus,eastus2,japanwest,eastasia,southcentralus,australiaeast,australiasoutheast,brazilsouth,southeastasia,westus,northcentralus,westeurope,northeurope,eastus'.

The first command should be replaced with one that lists only the appropriate regions.

I actually opened an issue on the azure cli for this as well: https://github.com/Azure/azure-cli/issues/2396

This issue was moved to teamhephy/workflow#29


Versions 1.0.6-1.0.7 crash Cyrillic

Versions 1.0.6-1.0.7 crash Cyrillic symbols in html-templates in VSC.1.0.5 works good.

I cannot reproduce this error.

Please provide the following information:

OS;
File encoding;
djLint version (pip freeze).

My friend using Windows has the same problem. Everything works fine for me on Linux.
So far I don't know how to fix this. Need help.

I cannot reproduce this error.

Please provide the following information:

OS;
File encoding;
djLint version (pip freeze).

OS - Windows 10
File encoding - UTF-8
djLint version - 1.0.6-7 - break, 1.0.5 - works fine

Solution: https://github.com/Riverside-Healthcare/djLint/issues/243#issuecomment-1124603803.

Solution - update djLint to version 1.1.1 or higher.


Interactive Scatterplot

This PR builds on the work introduced in the Scatterplot widget PR. Users can interactively select data points with the lasso tool offered by matplotlib.

Codecov Report
Base: 81.07% // Head: 79.76% // Decreases project coverage by -1.30% :warning:

Coverage data is based on head (a996a63) compared to base (f092bcf).
Patch coverage: 58.57% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #28      +/-   ##
==========================================
- Coverage   81.07%   79.76%   -1.31%
==========================================
  Files          10       10
  Lines        1210     1275      +65
==========================================
+ Hits          981     1017      +36
- Misses        229      258      +29

Impacted Files
Coverage Δ

src/napari_spatialdata/_categoricals_utils.py
60.00% <ø> (ø)

src/napari_spatialdata/_utils.py
68.37% <25.00%> (-1.54%)
:arrow_down:

src/napari_spatialdata/_view.py
80.69% <37.50%> (-3.80%)
:arrow_down:

src/napari_spatialdata/_scatterwidgets.py
83.09% <68.00%> (-4.93%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

LGTM!!


arizona_tpl_compile.erl: think about using modules to be the view (compile/1)

It eases maintenance...

I don't have a clear idea of what this means. I've marked it as resolved in https://github.com/arizona-framework/arizona/pull/164, but I'm not sure.

It comes from the linked pull request: there was a bunch of stuff I moved from code to Issues.

Hmm, ok, so #164 will close this issue. Thanks, @paulo-ferraz-oliveira!


Doesn't work well with find_each

See https://gist.github.com/d2b87ce12167f15b5438

Seems we can't fix this because find_each calls find_in_batches which has the following description:
"It’s not possible to set the order. That is automatically set to ascending on the primary key (“id ASC”) to make the batch ordering work. This also mean that this method only works with integer-based primary keys. You can’t set the limit either, that’s used to control the batch sizes."
/cc @mseckington


add store to timestamp field mapping

Any unit tests to implement?

Thanks for the PR @KodrAus ! I left one minor comment.
We have a few unit tests for the timestamp field.  It would be great if you could include the store field in those tests as well.
Also, would you mind signing the CLA?

I've signed the CLA. Thanks for linking to the unit tests, I'll make the changes and add tests

Excellent, thank you!  One other nitpick I just noticed ^^.

How's this looking now? It should be verifying that store is not serialized in TimestampFieldUsingExpression and that it is in TimestampFieldUsingString

LGTM!  Thanks again @KodrAus

No worries! I'm trying to get more involved in the ES community, since I've been mooching off it for years


Drop Id's for Accounts & Circles

Since a Circle Name and an Account Name both must be unique, there, and as the Id's only serve a purpose for external communication, they can be dropped, and the names can replace them.
This will require a fairly large API correction.

The current Id's cannot be altered, whereas the names of both Members & Circles can. If the same CWS instance is used by multiple systems - it will prevent a local caching of information of they can change. For this reason, the bug/enhancement is closed as won't fix.


How to run on a mac

I'm new to a Mac.  Took me an hour to figure this out...
Mac users using terminal should add variables to ~/.zshenv.   (e.g. export AWSPASS=123456).
The code also needed import os at the top to run in terminal

Can you please provide a link to the guide you had this issue with? Thanks!

Hi Daniel, sorry.  I've done soooo many labs and trainings since starting I don't know which one that is.  I'm pretty sure it would be whereever we learn how to install SnowSQL and use that.  I don't know which quick start guide covers that.  That guide would say to modify the .profile but Mac's ZSH terminal doesn't use that.  It uses .zshenv


Fix TypeError when cc.frozen is nonzero numpy.integer

The current implementation of the frozen orbital check can raise a TypeError when cc.frozen is set to a nonzero numpy.integer value. This occurs because the logic attempts to call len() on the numpy.int64 value.
This PR adds a hasattr check to properly validate if an object supports len() before attempting to call it, fixing the TypeError while maintaining the existing behavior for all valid input types (None, 0, sequences).
Changes:

Add hasattr(frozen, '__len__') check before attempting len()
Maintain existing behavior for all valid input types

Test Plan:

Tested with cc.frozen = None  # Works as before
Tested with cc.frozen = 0     # Works as before
Tested with cc.frozen = []    # Works as before
Tested with cc.frozen = np.int64(1)  # Now works correctly

Thank you for identifying this issue!

Thanks for the fixes!


Fix documentation and comments to reflect the new esp_log_level_set API (and not deprecated esp_log_set_level)

Lines up documentation to reflect the esp_log_set_level -> esp_log_level_set API change.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Merged in https://github.com/espressif/esp-idf/commit/a8b75ed974c0c2b4d8bd5b61bb3dcb4ba15e5642, thanks!


Standardize H5MD Output

Currently, the H5MD output of MRMD does not meet some of the requirements of the H5MD standard (see ref. [1]) This creates problems when reading the output with analysis packages such as MDAnalysis, which could otherwise be a very convenient interface. Consequently, meeting the requirements should be accomplished.
[1] P. de Buyl, P. H. Colberg, and F. Höfling, H5MD: a structured, efficient, and portable file format for molecular data, Comput. Phys. Commun. 185, 1546 (2014) [arXiv:1308.6382].

Can you be more explicit about what is missing/wrong?

Can you be more explicit about what is missing/wrong?

Ah, yes. I've found three changes that would need to be made:

In section 3.7 in ref. [1] (see above), they define the name of the position item to be "position" rather than "pos", as it is in MRMD at the moment. This leads to MDAnalysis not recognizing at all that there even are positions stored in the file.
Same section, same problem, but with the velocity item.
edges is at the moment stored as an attribute, but it is supposed to be data according to section 3.8 in the case of an NVT simulation. For NPT, one would need to store it as anitem with step, time and value attached as data. This leads to MDAnalysis not recognizing the box edges at all, which lets the RDF function crash.

Interesting. I thought I used MDAnalysis in the past with this output. But you are right. Can you check if #28 is conformant to the standard?
1 and 2 are no problem. However, 3 has some caveats. Does the standard assume the box is located at (0,0,0)? This does not have to be the case for MRMD. So we might need to shift all positions.
Previously I was also using the format for checkpoint and restart my simulation. However the format is not sufficient reconstruct the whole simulation. This is why I additionally need minCorner, maxCorner, and ghostLayerThickness.

Please ignore these pushes on my fork above. This was the changes I attempted earlier. But now I'm checking your pull request #28, so let's stick to that.

Please ignore these pushes on my fork above. This was the changes I attempted earlier. But now I'm checking your pull request #28, so let's stick to that.

Oh, you did not link your attemp. I am sorry I was not aware of your attempt, I did not want to silently dismiss your work. Please make sure to reference your work as soon as your start somewhere, so I get notified about it. You can even create a draft PR.

No problem! It was all local until today. Next time I will use a draft PR as you suggest.


Region support for Models

I have the problem that i have to geocode only postal_codes from time to time. That postal_codes arent unique over the world and google sets them to other countries. Only with the Region setting for google they stay on the right place.
I did the change in my pull request: https://github.com/alexreisner/geocoder/pull/323
its turned down, cause this shouldnt be a global setting.
Are there other ways around?

Is it still the case that its not possible to configure region / bounds for the google API when geocoding in a model?

@rarruda you can do it like this:
after_validation :geocode_with_region

def geocode_with_region
  results = Geocoder.search("...", :params => {:region => "..."})
  self.latitude = ...
  ...
end

Thanks @alexreisner ! Works wonders!

Thanks! Works wonders!
But I'd like to suggest documenting this solution in README.md. :)

Example added to README (see b4e6603159f3dbf72e16b7994f114ab0697f9070).


[bug] Fix import conflict for SamplingParams

Conflict between llama_models.llama3.api.datatypes.SamplingParams and vllm.sampling_params.SamplingParams results in errors while processing VLLM engine requests. The PR aliases vllm samplingparams to resolve the conflict.
The problem really occurs due to the blanket import from llama_models.llama3.api.datatypes import * in vllm.py. If we can update that to import specific modules instead of the entire namespace, the proposed fix here is not necessary.
Test-plan
Before:
curl http://localhost:5000/inference/chat_completion -H "Content-Type: application/json" -d '{"model": "Llama3.1-8B-Instruct", "messages": [{"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Write me a 2 sentence poem about the moon"}], "sampling_params": {"temperature": 0.7, "seed": 42, "max_tokens": 512}}'

Stacktrace:
INFO:     Uvicorn running on http://[::]:5000 (Press CTRL+C to quit)
18:56:22.799 [INFO] [chat_completion] vLLM chat completion
18:56:22.800 [INFO] [chat_completion] Sampling params: strategy=<SamplingStrategy.greedy: 'greedy'> temperature=0.7 top_p=0.95 top_k=0 max_tokens=512 repetition_penalty=1.0
INFO 10-22 18:56:22 async_llm_engine.py:207] Added request 0b8f72db356c403790e0f5fe11d84efe.
INFO 10-22 18:56:22 async_llm_engine.py:184] Finished request 0b8f72db356c403790e0f5fe11d84efe.
INFO 10-22 18:56:22 metrics.py:349] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 0.0 tokens/s, Running: 0 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 0.0%.
Traceback (most recent call last):
  File "/home/ubuntu/subramen/llama32/llama-stack/llama_stack/distribution/server/server.py", line 240, in endpoint
    return await maybe_await(value)
  File "/home/ubuntu/subramen/llama32/llama-stack/llama_stack/distribution/server/server.py", line 200, in maybe_await
    return await value
  File "/home/ubuntu/subramen/llama32/llama-stack/llama_stack/distribution/routers/routers.py", line 98, in chat_completion
    return await provider.chat_completion(**params)
  File "/home/ubuntu/subramen/llama32/llama-stack/llama_stack/providers/impls/vllm/vllm.py", line 193, in chat_completion
    return await self._nonstream_chat_completion(request, results_generator)
  File "/home/ubuntu/subramen/llama32/llama-stack/llama_stack/providers/impls/vllm/vllm.py", line 198, in _nonstream_chat_completion
    outputs = [o async for o in results_generator]
  File "/home/ubuntu/subramen/llama32/llama-stack/llama_stack/providers/impls/vllm/vllm.py", line 198, in <listcomp>
    outputs = [o async for o in results_generator]
  File "/opt/conda/envs/llamastack-vllm-stack/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 1029, in generate
    async for output in await self.add_request(
  File "/opt/conda/envs/llamastack-vllm-stack/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 112, in generator
    raise result
  File "/opt/conda/envs/llamastack-vllm-stack/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 762, in engine_step
    await self.engine.add_request_async(**new_request)
  File "/opt/conda/envs/llamastack-vllm-stack/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 495, in add_request_async
    self._add_processed_request(
  File "/opt/conda/envs/llamastack-vllm-stack/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 689, in _add_processed_request
    raise ValueError(
ValueError: Either SamplingParams or PoolingParams must be provided.

The ValueError is raised because it fails the isinstance(params, vllm.sampling_params.SamplingParams) check.
After:
curl http://localhost:5000/inference/chat_completion -H "Content-Type: application/json" -d '{"model": "Llama3.1-8B-Instruct", "messages": [{"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Write me a 2 sentence poem about the moon"}], "sampling_params": {"temperature": 0.7, "seed": 42, "max_tokens": 512}}'

{"completion_message":{"role":"assistant","content":"The moon glows softly in the mid night sky, \nA beacon of wonder, as it catches the eye.","stop_reason":"out_of_tokens  ","tool_calls":[]},"logprobs":null}

@raghotham added the before/after in the original post, pls lmk if any other details can help clarify the issue and fix

Thanks @subramen


Install whois tool

Info:

Docker version 18.09.0, build 4d60db4
Laradock commit ($ git rev-parse HEAD): d8c36ab86007f04293d380bcf8325cb70c76fdd0
System info (Mac, PC, Linux): MAC
System info disto/version: Mojave

Issue:
How i can install whois tool ?
Expected behavior:

Reproduce:
$ whois vk.com
Relevant Code:
// place a code sample here

Solved.
apt update
apt install whois


Add isClose, a replacement for approxEqual

As suggested in PR #7173, I wrote a new version of approxEqual (called isClose to avoid naming conflicts), which is based on the thoughts given in [1]. The purpose of both functions is the same, namely providing a utility for comparing floating point numbers. This is necessary, because operations on floating point numbers inevitably produce rounding errors and therefore cannot be compared reasonable using ==.
The main difference is, that this function has much stronger default values for the error allowed, based on the capabilities of the used floating point type. This helps in catching errors, especially as approxEqual is mainly used in unittests. This addresses issue #15881. Together with PR #7180 this can be considered a fix for that issue.
The new function is furthermore symmetric, to avoid users being confused or have to remember the order of the operands. This addresses issue #15763.
After this PR has been approved I think, it would be wise to continue with the following roadmap:

replace all occurences of approxEqual in Phobos by isClose. With one exception, approxEqual is only used in unittests. The exception is secantMethod in std/numerical.d.
deprecate approxEqual in favour of isClose. (I don't know if I'm in the position to deprecate anything, nor to ask for it, but I think, this would be a good idea in the long-run.)
After some time, remove approxEqual alltogether.

[1] https://www.python.org/dev/peps/pep-0485/

Add more unittests for 100% code coverage.

resolved merge conflict

I had to remove the github account with which I created this PR but forgot to close this before. Can anyone with appropriate write access close this PR?

I had to remove the github account with which I created this PR but forgot to close this before. Can anyone with appropriate write access close this PR?

Done.


Interfaces and classes considered equal

TypeScript Version:
1.8.0
Code
// A self-contained demonstration of the problem follows...
class A {
	constructor(a: number, b: boolean) {

	}
	foo() {

	}
	bar: boolean;
}

function doIt(a: A) {
	if (a instanceof A) {

	}
}

doIt(new A(1, true));

doIt({ foo() { }, bar: false }); // expect type check error

Expected behavior:
The second to doIt should raise a type check error.
Actual behavior:
It does not. I assume it was a conscious decision and I wonder why? This break assumptions the instanceof operator makes and has led to subtle bugs on our side.

TypeScript is a structural typing system, not a nominal one. 😄  Therefore anything that shares the same structure is considered type equality.

I understand that, but a class has a constructor and a prototype which I would expect to be present in the structure of a class but not in the structure of a object literal

You can add a private or protected property to a class if you don't want this to happen accidentally.

@RyanCavanaugh Doesn't that mean that in effect I can never rely on instanceof esp when using OR-typing and type guards as propagated by TypeScript? I think that design choice should be revisited.
function doIt(a: A | number) {

    if (a instanceof A) {

    } else if (typeof a === 'number') {

   } else {
      // what now?
   }
}

Some history, initially instanceOf checks were nominal. i.e. in side the true branch, the type is narrowed to the class, but outside it nothing happens, as we can not be sure that it is not of the type A but not created by the constructor A.
We then got feedback about users thinking of instanceof as a type check not a constructor check. and when you have something that is A|B you expect the else of if (x instnceof A)  to mean it is a B.
@RyanCavanaugh did some research on what common patterns we see in the wild (see https://github.com/Microsoft/TypeScript/issues/1719#issuecomment-73746885) and that reinforced the idea that the constructor and the type are thought of as the same.
So, though i agree that instanceof is a nominal check, it seems that most users do not think of the difference between nominal and structural checks when testing for types that much.
As for your last example, I had a discussion about this with @ahejlsberg yesterday. We think the correct behavior is to narrow to {} in the else branch. this way instanceof type guards work similar to typeof and undefined/null guards.

For us the problem is twofold. Take the CompletionItem provider we ask extension writers to implement. The interface states that you should CompletionItems[], which is a class, or a CompletionList. Since we want to protect against bad extensions we check the returned values like so:

			let list: CompletionList;
			if (Array.isArray(value)) {
				list = new CompletionList(value);
			} else if (value instanceof CompletionList) {
				list = value;
				defaultSuggestions.incomplete = list.isIncomplete;
			} else if (!value) {
				// undefined and null are valid results
				return;
			} else {
				// warn about everything else
				console.warn('INVALID result from completion provider. expected CompletionItem-array or CompletionList but got:', value);
				return;
			}

Now the problem is that an extension writer doesn't get a compile error when returning a structure instead of a new'ed object but we still ignore his value since it doesn't comply to our checked. Working around this by not using instanceof but some manually property-by-property check isn't what my performance buddy would recommend.

I would say the check in value instanceof CompletionList does not match the interface declaration for provideCompletionItems; the interface just says return something that looks like CompletionList, nothing in there says it has to be an instance of CompletionList. i think what you really want is a nominal marker (https://github.com/Microsoft/TypeScript/issues/202) on CompletionList that says, rely i want an instance of CompletionList class that i have implemented and not just a structural match.

Yes, wouldn't something like this solve the problem:
class CompletionList {
  private __class = 'CompletionList';
  /*...*/
}

Now no duck can quack like CompletionList except CompletionList.

Well, it just makes very ugly API if I have to put these markers in every class of our system. We use classes because we see additional benefit from that (like ctor logic, etc) but it seems TypeScript is not fit for that.

does not match the interface declaration for provideCompletionItems

@mhegazy That's the whole point. The interface declaration says return CompletionItem or CompletionList which both are defined as classes, not interfaces.

We use classes because we see additional benefit from that (like ctor logic, etc) but it seems TypeScript is not fit for that.

But when consuming CompletionList why do you need it to be a created instance of the class when it is structured exactly the same.  Or asked another why, why do you need nominal typing?  If it is shaped like CompletionList you can do every operation you want on it in a safe way.
There is good reason why TypeScript is structurally typed, because of the permissiveness of the language it is a superset of.  Many people have tried to project concepts of other languages into JavaScript because of familiarity only to find out that it doesn't work that way.  ES6 Classes are nothing more than a constructor functions with an assigned prototype and a bit of logic which throws if you don't use a magical keyword new.

We also allow people to write extensions in Javascript (in which you don't get type checking) and I want to be save in case where a client returns something which is neither a CompletionList nor a CompletionItem array but something more or less random

I think then what you are saying is that from an interface perspective, you would be completely fine with someone providing you an object that was structurally typed like CompletionList but the easiest and only effective runtime way to ensure the structure is like CompletionList is to use instanceof, but at runtime instanceof is effectively a nominal type guard, while at design time it is a structural type guard, meaning the behaviours diverge and could give end developers in either TypeScript or the Salsa language services a false idea that their design time behaviour will match the run time behaviour.

yes, well said. maybe TypeScript should emit instanceof usage to function calls that do instanceof || all_properties_match

Not that this addresses the design time/runtime behaviour of instanceof, but since we (Dojo 2) don't generally use ES6 classes (or constructor functions for that matter) in a lot of code, instead of instanceof we often use custom type guards that do enough structural checking to be able to narrow the type.  Even though we except people to use Dojo 2 without TypeScript or the Salsa language services, we believe that adding significant overhead in value checking at runtime, when there are specifically tools to avoid this at design time is a burden we wouldn't want to put on the end user of an application.
I realise there maybe a difference when you are trying to execute others code and need to try to do a level of guarding against people being malicious, but considering a custom type guard to weed out random "junk" maybe sufficient (because if the TypeScript team agree about the behaviour, it will be a while before it would become available).

We have got feedback previously about users thinking of classes nominally and interfaces structurally. but i have to say there is value in making these two interchangeable, specially for ambients, the way the definition author decided to write the declarations should not dictate your runtime semantics.
I do not think we can change that now anyways, or that would be a huge breaking change. An option would be what is tracked by https://github.com/Microsoft/TypeScript/issues/202, possibly adding a tag on the classes marking them as nominal.

I will bring this issue to discussion. https://github.com/Microsoft/TypeScript/issues/7271 seems to be the same issue. so marking this one as a duplicate of https://github.com/Microsoft/TypeScript/issues/7271.