not able to process GitHub schema file

I'm hitting a few bumps in the road while trying to run it. The hitch seems to be with parsing the schema file. I've tried two examples. First was the one I gathered from the FSharp.Data.GraphQL sample. It had a commenting style that was triple-double-quoted above and below each line.
Reading configuration from C:\repo\GitHubGraphQL\snowflaqe.json ⏳ Loading GraphQL schema from ./schema.docs.graphql Syntax Error GraphQL (1:1) Unexpected String "" 1: """    ^ 2: Defines what type of global IDs are accepted for a mutation argument of type ID.
Then I tried another that came from running the introspection query which gave back a json result. That too hit an error, but this time on a null.
Reading configuration from C:\repo\GitHubGraphQL\snowflaqe.json ⏳ Loading GraphQL schema from ./schema.docs.json Value cannot be null. (Parameter 'source')
So I'm stuck - to a first approximation. I'm continuing to work on the file handling for updating/mutating the CSV, and will save the best for last. 😁 I'm  attaching both files here. Thanks in advance for giving it a once-over when you can.
schema.docs.zip

Hi @houstonhaynes, thanks for the issue report. I will try to figure out why the introspection results aren't working 😓

There is something funny going on with the schema file. I was just debugging the parsing logic. It does fail but it is because the schema is missing some crucial information about the objects and their types. I already have a sample Github schema that I run my tests against and it has this type for example:
This is a piece of my local schema.json file generated from Github's API
 {
                    "kind": "INTERFACE",
                    "name": "Actor",
                    "description": "Represents an object which can take actions on GitHub. Typically a User or Bot.",
                    "fields": [
                        {
                            "name": "avatarUrl",
                            "description": "A URL pointing to the actor's public avatar.",
                            "args": [
                                {
                                    "name": "size",
                                    "description": "The size of the resulting square image.",
                                    "type": {
                                        "kind": "SCALAR",
                                        "name": "Int",
                                        "ofType": null
                                    },
                                    "defaultValue": null
                                }
                            ],
                            "type": {
                                "kind": "NON_NULL",
                                "name": null,
                                "ofType": {
                                    "kind": "SCALAR",
                                    "name": "URI",
                                    "ofType": null
                                }
                            },
                            "isDeprecated": false,
                            "deprecationReason": null
                        },
                        {
                            "name": "login",
                            "description": "The username of the actor.",
                            "args": [],
                            "type": {
                                "kind": "NON_NULL",
                                "name": null,
                                "ofType": {
                                    "kind": "SCALAR",
                                    "name": "String",
                                    "ofType": null
                                }
                            },
                            "isDeprecated": false,
                            "deprecationReason": null
                        },
                        {
                            "name": "resourcePath",
                            "description": "The HTTP path for this actor.",
                            "args": [],
                            "type": {
                                "kind": "NON_NULL",
                                "name": null,
                                "ofType": {
                                    "kind": "SCALAR",
                                    "name": "URI",
                                    "ofType": null
                                }
                            },
                            "isDeprecated": false,
                            "deprecationReason": null
                        },
                        {
                            "name": "url",
                            "description": "The HTTP URL for this actor.",
                            "args": [],
                            "type": {
                                "kind": "NON_NULL",
                                "name": null,
                                "ofType": {
                                    "kind": "SCALAR",
                                    "name": "URI",
                                    "ofType": null
                                }
                            },
                            "isDeprecated": false,
                            "deprecationReason": null
                        }
                    ],
                    "inputFields": null,
                    "interfaces": null,
                    "enumValues": null,
                    "possibleTypes": [
                        {
                            "kind": "OBJECT",
                            "name": "Bot",
                            "ofType": null
                        },
                        {
                            "kind": "OBJECT",
                            "name": "EnterpriseUserAccount",
                            "ofType": null
                        },
                        {
                            "kind": "OBJECT",
                            "name": "Mannequin",
                            "ofType": null
                        },
                        {
                            "kind": "OBJECT",
                            "name": "Organization",
                            "ofType": null
                        },
                        {
                            "kind": "OBJECT",
                            "name": "User",
                            "ofType": null
                        }
                    ]
                },

However, that same type from your introspection results is missing the types of the object fields
                {
                    "name": "Actor",
                    "kind": "INTERFACE",
                    "description": "Represents an object which can take actions on GitHub. Typically a User or Bot.",
                    "fields": [{
                            "name": "avatarUrl"
                        },
                        {
                            "name": "login"
                        },
                        {
                            "name": "resourcePath"
                        },
                        {
                            "name": "url"
                        }
                    ]
                },

So the question is, how did you generate the JSON schema file? Did you use the Standard Introspection Query against the API?

So the short answer is yes. Just to make sure I pulled the one linked here and diffed it. The queries match. I just re-ran the introspection query and diffed the result against what I saved last night (local time) and it's WILDLY different. It's lit up like Christmas. SO OF COURSE running it this morning it worked without a hitch. Geez I feel like the person who takes their car to the shop to have the mechanic look at their car - and then it fails to make the bothersome noise that caused the concern in the first place... 🙄


Tippecanoe segfaults on Microsoft building footprint GeoJSON files

I've tried to convert GeoJSON files from the recent Microsoft building footprint data into MBTiles.
According to Nikola Trifunović the GeoJSON don't contain invalid entries anymore, but the conversion with tippecanoe leads to a crash at 49.9 %. All files I've tried until now crash when exceeding 49.9 %.
Maine (Link) / tippecanoe -o Maine.mbtiles -zg --drop-densest-as-needed Maine.geojson

I have been unsuccessful in reproducing a segfault with the latest d64ac19 commit on Ubuntu 17.04 and the above linked data:
./tippecanoe -o /dev/shm/maine.mbtiles -zg --drop-densest-as-needed Maine.geojson
For layer 0, using name "Maine"
752054 features, 38871324 bytes of geometry, 752005 bytes of separate metadata, 0 bytes of string pool
Choosing a maxzoom of -z10 for features about 336 feet (103 meters) apart
Choosing a maxzoom of -z12 for resolution of about 70 feet (21 meters) within features
  99.9%  12/1264/1492

file /dev/shm/maine.mbtiles
/dev/shm/maine.mbtiles: SQLite 3.x database, last written using SQLite version 3019003

ll /dev/shm/maine.mbtiles
-rw-r--r-- 1 root root 20201472 Jul 16 02:07 /dev/shm/maine.mbtiles

md5sum /dev/shm/maine.mbtiles
60ec884d66677b94749d7861dd1f7dc2  /dev/shm/maine.mbtiles

It works for me too, but if you can provide more information about the environment that it fails in, I can try to debug.

Closing in the absence of information about how to reproduce


reportlab installation using pip3 reporting error in python3.9

What documentation would you like added?
We are on IBM i V7.3. We installed the python3.9 from IBM repo using open-source package management.
We installed the wheel and necessary development tools. Now we want to install reportlab python package but we are getting error during the wheel build. Please suggest.
command '/Qopensys/pkgs/bin/gcc' failed with exit code 1.
Error: failed building wheel for reportlab.

We were able to install the reportlab by setting the linux compatible flag option. CFLAGS=-D_LINUX_SOURCE_COMPAT pip3 install


[Feature Request] No recent pip wheel available for linux arm64

Motivation
We use TensorDict in our code and trying to run it on GH200 nodes, only old version is available (0.2.x I think), while recent versions are available only for x64.
Solution
It would be great to have prebuilt binaries available for linux arm64 systems.
Alternatives
Either built from source (I guess?), or not use it
Additional context
GH200 system
Checklist

[x] I have checked that there is no similar issue in the repo (required)

Yeah you're right. iirc I didn't manage to upload them on pypi so I had to put them in the release notes
https://github.com/pytorch/tensordict/releases/tag/v0.6.2


text-to-speech service using IAM_APIKEY

Couldn't get speech from TJBot working when using the iam-apikey for a deployed text-to-speech service.
This does work when using the same service when deployed in a region that still uses uname/pwd for authentication.

code is being archived


autoplay prop is toggled but doesn't work as expected

Bug Report
Current Behavior
Okay, here it goes..
~A video shows more than 1000 words~

I've made a setup where there are 10 panels. Each panel has a card and displays some widgets.
I added a button that toggles the [autoplay] and changes the [speed] and [autoplay-timeout] props.
the [speed] and [autoplay-timeout] both have 12500 ms setting to make it appear as autoscrolling.
upon reaching the first or last slide I change [autoplay-direction] so I ge tthe bounce effect, you get the idea ;)
After setting the [autoplay] to false it keeps playing. I checked this by logging the prop and it gets set to false. Maybe it has something to do with the [speed] and [autoplay-timeout]?
The speed changes but only after the last transition is done. (takes about 12500ms)
Btw, toggling the mouse-drag setting does not work either.
Now to the code!
Input Code and steps to reproduce
Carousel component:
<carousel
          :autoplay="carouselPlaying" <!-- initially: true -->
          :autoplay-timeout="playTimeout" <!-- initially: true -->
          :speed="playTimeout" <!-- initially: 12500-->
          :autoplay-direction="carouselDirection" <!-- initially: 'forward'-->
          :mouse-drag="paginationEnabled" <!-- initially: false -->
          :pagination-enabled="paginationEnabled" <!-- initially: false -->
          :autoplay-hover-pause="false"
          :per-page="3"
          :scroll-per-page="false"
          :space-padding="32"
          easing="linear"
          @pageChange="displayPage"
        >
  <slide
            v-for="n in 10"
            :key="n"
   >
....

This is my toggle method.
toggleCarouselPlaying() {
      this.carouselPlaying = !this.carouselPlaying;
      this.paginationEnabled = !this.paginationEnabled;
      if (this.playTimeout === constTimeout) {
        this.playTimeout = 100;
      } else {
        this.playTimeout = constTimeout;
      }

      console.log(`${this.carouselPlaying} ---- carousel playing`);
      console.log(
        `${this.paginationEnabled} ----- pagination enabled + mouse drag`,
      );
    },

Expected behavior/code
When I press pause, I want the carousel to imediately stop autoplaying, be able to drag the slides as well as navigation through pagination.
Environment

Vue-carousel:  v0.16.2
Babel version(s):
"babel-core": "^6.26.0",
"babel-eslint": "^8.2.2",
"babel-loader": "^6.4.1",
"babel-plugin-transform-async-to-generator": "^6.24.1",
"babel-plugin-transform-runtime": "^6.23.0",
"babel-preset-es2015": "^6.24.1",
"babel-preset-stage-2": "^6.24.1",
"babel-register": "^6.26.0",
Node/npm version:
node: v10.11.0
npm: v6.3.0
OS: [e.g. OSX 10.13.4, Windows 10]
windows 10

Hey @gertvdkolk, I haven't looked fully into this but at first glance, I think the issue is similar to #320 in that a few of these settings are only checked on the carousels creation. I'll take a more detailed look, but if that's the case we're planning to remedy this in v1.0.0 by exposing a carousel-events api.
I'm out of office currently, if you're investigating and find anything in the meantime feel free to post here :octocat:

For me is working the stop autoplay:
Vue.component(VueCarousel.name, VueCarousel);
VueCarousel.props.autoplay.default = false;

Hey @marceloviana, do you mind sending over a jsFiddle or a working reproduction? From what you've posted, I think this should be working. If it's not, we'll need some more info to help debug


Fixed a crash in error handing of rand_drbg_new

That is a stress test with random memory error injection that I occasionally execute.

Merged, thanks!


Questions on updating worker and main containers with new requirements

On my current setup I have 2 VMs:
VM 1: Redis, Webserver, Flower, Scheduler
VM 2: Worker(which communicates with Redis on VM 1)
How do I add new requirements to the existing containers without destroying and recreating them?

If you want to install package with pip, I don't think you could do that. In script/entrypoint.sh
https://github.com/puckel/docker-airflow/blob/024cf2d08d2de1edf63f780c4d60c5d8fc70b265/script/entrypoint.sh#L36
install package when container start.
But you could still install package with pip in you VM, but it will not exists when you restart you container thougth images.
If you want to install extra package in you container, maybe change Dockerfile is the best way.


Add test for refs caching

The problem with refs caching lays in gojsonschema code. There is a GET request which can't be cached on kubeconform side.
I think the best solution for caching refs would be to have http transport with supports caching and pass it to gojsonschema

Most code for caching can be deleted in favour of external module gregjones/httpcache
Easy to implement other caching method (just use one of the cache backend included in httpcache)
Standard interface means caching inside of gojsonschema code can be done as simple and passing http transport as argument (when and if gojsonschema supports it)

yep that ll need patching gojsonschema.. might have a look, some day :)

yep that ll need patching gojsonschema.. might have a look, some day :)

BTW thanks a lot for filing that bug https://github.com/xeipuuv/gojsonschema/issues/322  :+1:

Closing, it looks like gojsonschema is not very actively maintained... and this will be fairly difficult to complete :(


spec: should include more details on how invalid requests and responses should be handled

The spec describes valid requests and a valid responses, but, aside from how to handle an invalid content-type for streams or unsupported message codec for unary, it does not indicate what actions a Connect server or client should take in the face of an invalid request or response.
On the server side:

How should a server handle a request with an unsupported method (i.e. anything but POST for most methods; anything but POST or GET for idempotent methods)?
How should a server handle a streaming request that indicates an unsupported codec?
It should be clarified that the response content-type for streaming calls must match the request content-type.
How should a server handle a streaming request for a server-stream operation that has an incorrect number of request messages (!= 1)?
How should a server handle a stream message that has the "compressed" bit set even though no compression is configured via content-encoding?

There are similar concerns with how a client should handle an invalid response.

How should a client handle a response with an invalid content-type?
How should a client handle an unsupported response content-encoding?
How should a client handle a streaming response with a non-200 HTTP status code?
How should a client handle a streaming response for a client-stream operation that has an incorrect number of request messages (!= 1)?
How should a client handle a stream message that has the "compressed" bit set even though no compression is configured via content-encoding?

The spec should be expanded to provide more clear guidance on expected behavior in the face of these kinds of errors.

All good points :) It'd be great for the spec to match the conformance tests on all of these points.


React 18 Flickering

When running under React 18 the current version of the charts is flickering on mouse wheel operations. This appears to be due to React 18 batching updates originating from native event handlers. See https://react.dev/blog/2022/03/08/react-18-upgrade-guide#automatic-batching
We've tried using the recommend method of FlushSync to avoid the batching, whilst this does remove the flickering, it also produces an unacceptable level of performance and jerk.
The only workaround at the moment is to use ReactDom.render instead of ReactDom.createRoot().render, this will mean the same behaviour as React 17 but with a warning in the console.

Any updates on this?

Has anyone been able to solve it?

@Arnau-Gelonch I found a (very suboptimal) work-around for now. It's not perfect:

struggles to handle resizing
miserable for performance (very noticeable on mobile) if you have a busy page
interactions are still a big laggy but doesn't flash which is an improvement

class StockChart extends React.Component<StockChartProps> {
  idFromProps(): string {
    return `candle-chart-${this.randomId}`;
  }

  componentDidUpdate(): void {
    if (this.props.data.length === 0) {
      return;
    }

    // if there is already a chart rendered, remove it
    const element = document.getElementById(this.idFromProps());
    if (this.hasRendered && element) {
      ReactDOM.unmountComponentAtNode(element);
      this.hasRendered = false;
    }
    if (!this.hasRendered) {
      ReactDOM.render(this.internalRender(), document.getElementById(this.idFromProps()));
      this.hasRendered = true;
    }
  }

  componentDidMount(): void {
    this.componentDidUpdate();
  }

  componentWillUnmount(): void {
    const element = document.getElementById(this.idFromProps());
    if (this.hasRendered && element) {
      ReactDOM.unmountComponentAtNode(element);
    }
  }

  public render() {
    // use ReactDom.render to render the component
    return <div id={this.idFromProps()} />;
  }

  public internalRender() {
    // render your chart
  }
}

Leave this.clearThreeCanvas() only in getSnapshotBeforeUpdate and remove it from other places

Are there any updates on this? My company is looking to use this library in an upcoming product. We could possibly devote dev time to fixing.

@carterjfulcher I would've thought this is already fixed, there is no flickering anymore
However, I do notice the chart is not displayed when panning vertically.
It does work horizontally. This can be checked on the current stories.
I spent a few hours debugging the code, inspecting basically the draw functions in the ChartCanvas class but have not been able to identify the issue yet, as they "seem" to be ok to me so far.
Anyone else having this issue ?
Any idea ?

On React 18, panning and zooming still flickers

@carterjfulcher I would've thought this is already fixed, there is no flickering anymore (under React 17 rendering method) However, I do notice the chart is not displayed when panning vertically. It does work horizontally. This can be checked on the current stories. I spent a few hours debugging the code, inspecting basically the draw functions in the ChartCanvas class but have not been able to identify the issue yet, as they "seem" to be ok to me so far. Anyone else having this issue ? Any idea ?

this is exactly what we are experiencing

Is there any method to fix this in next.js?

Leave this.clearThreeCanvas() only in getSnapshotBeforeUpdate and remove it from other places

This fixed the problem, Does it have any consequences? If not why is someone not creating a PR as this fixes the issue?

Leave this.clearThreeCanvas() only in getSnapshotBeforeUpdate and remove it from other places

@Cr1pter I resolved the issue in next.js with this suggestion, You can do these changes in the ChartCanvas.js present in the module.


[capi] Comply with Tizen ACR comments

This patch applies comments from the Tizen ACR
Self evaluation:

Build test: [x]Passed [ ]Failed [ ]Skipped
Run test: [x]Passed [ ]Failed [ ]Skipped

Signed-off-by: Parichay Kapoor<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #440. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.


feat: multiwindow support; refactor render

Yep, it will probably be even easier without splitting the code. I'll drop this PR then.


Wrong project.gradle.parent

Expected Behavior
project.gradle.parent points to the project's immediate parent, even if this project's parent has it's own parent
Current Behavior
project.gradle.parent points to the topmost project, not for real parent
Context
Such a behavior misleads when using nested composite builds, where some project includeBuild other project, wich, in turn, includeBuild third project.
For instance, it causes Android Gradle Plugin crash in ModelBuilder.getBuildName()
Steps to Reproduce
Let 3 projects: bottom, middle and top, laying in the same directory. i.e.
root/top
root/mid
root/bottom
top/settings.gradle.kts
rootProject.name = "top"
includeBuild("../mid")

mid/settings.gradle.kts
rootProject.name = "mid"
includeBuild("../bottom")

bottom/settings.gradle.kts
rootProject.name = "bottom"

All three projects have build.gradle.kts:
println("${project.name} parent is ${project.gradle.parent?.rootProject?.name}")

When running ./gradlew init got output
Welcome to Gradle 8.0-rc-3!

For more details see https://docs.gradle.org/8.0-rc-3/release-notes.html

Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

> Configure project :bottom
bottom parent is top

> Configure project :mid
mid parent is top

> Configure project :
top parent is null

> Task :init SKIPPED
The build file 'build.gradle.kts' already exists. Skipping build initialization.

BUILD SUCCESSFUL in 15s

As you see, parent of both bottom and mid is top.
But I expect parent of bottom is mid
Your Environment
Gradle 8.0 RC3
Build scan URL: https://scans.gradle.com/s/222bhbgxeuoka

I came to this issue from an answer to my question in StackOverflow. I'm linking it here as it might help to understand a simple use case for this situation.

This definitely highlights a lack of documentation. I can't find anything detailing this behavior.
So I'm speculating. Since any included build can include any other build in turn, the graph of included builds can have cycles and to work around that, so I guess internally we might somewhere store all included builds as direct descendants of the root build.
The only clue in the documentation I could find is here: https://github.com/gradle/gradle/blob/7dec5105c7585151d7339beddfc549e04697a9cd/subprojects/tooling-api/src/main/java/org/gradle/tooling/model/gradle/GradleBuild.java#L67 (and this is not even the same thing that we are looking at).

Thank you for your interest in Gradle!
This is a valid documentation issue which we will address.

Thank you for attention to issue I had found.
But what is the reason to flatten nested composite build structure?
In my oppinion more useful would be preserve composition tree-like structure.

The main reason is that a given build can be included in multiple builds (think composites of composites), but for Gradle, it still is a single unique build.


Add a visual CMS

Need to integrate updated deployment given static site generation

not needed. blog moved to substance


Outdated dependencies

centrifuge		                        v1.0.4
SPAdes genome assembler		v3.15.5
We know that at least the deprecated SPAdes would cause crashes.

A brief investigation revealed that both of these packages are managed by conda, and the crash was caused by a stale local copy.


chore: fix some problematic comments

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for this, can you get the commit message in line with the guidelines?

Thanks for this, can you get the commit message in line with the guidelines?

Of course. Modified.
Please review again.


Fuzzy hashtag row detection

Follow Postel's Principle, and be more flexible about detecting the hashtag row.  Currently, a hashtag row must have every cell containing either a valid HXL hashtag or nothing.

Decided on the following algorithm: if a row appears within the first 25 and has valid HXL hashtags in at least 50% of its non-empty cells, then treat it as an attempted hashtag row.


reflection: imperative equivalence for declarative import

as today, we only have loader.import('./foo.js').then(m => {...}), which is reflective to import * as m from "./foo.js", as we discussed earlier today, we might need to provide reflection for the other two options (default and named exports import declarations).
@dherman suggested:
local.import("./foo.js").then((def, named) => ...)
local.importNamespace("./foo.js").then(m => ...)

I really like the (def, named) => signature.
What is different between local.importNamespace("./foo.js").then(m => use(m)) vs. local.import((def, named) => use(named))?

(Sorry for the meta discussion, but where I'm from "reflection" means functions for analysis, http://en.wikipedia.org/wiki/Reflection_(computer_programming).
This subject seems to be "Imperative equivalence for declarative loading" or similar).

To clarify, or to raise the question, depending on how you look at this, but local.import("./foo.js").then(def => ...) is really not reflective as the current proposal, essentially because def will not get updated if the value change in the provider module.

Hmm maybe that is an argument for only having the namespace form.

importDefault?

I'm not sure what problem we are trying to solve here?
How is
local.import("./foo.js").then((def, named) => ...)

better than:
local.import("./foo.js").then({default: def} => ...)
local.import("./foo.js").then({foo} => ...)

Lets try to keep the API surface area minimal. The special cases can always be done in user code and added later version of the spec.

Yes, I'm with @arv on this, es6 with make this elegant without the need for multiple methods/signatures. import should return the module. import/export is already complicated enough (I still have to reference this all the time), let's not complicate the dynamic apis as well.

@arv @matthewp A low-level reflection API can be minimal and general. But the local import object is a high level API, meant for common use. And it's meant to be the dynamic analog of what you can do with the declarative syntax. It should have its defaults be symmetric with the surface syntax.
In the surface syntax, when you import a default, you don't have to write d-e-f-a-u-l-t. It's just the simplest thing where you have to say the least. In short, we want to allow:
local.import("./my-app-controller.js").then(MyAppController => ...)

as the most convenient case just like
import MyAppController from "./my-app-controller.js";

would be.
Another way of looking at this is that single-export needs to be as convenient in this API as it is today in existing JS module systems. Not having to say default explicitly is very important to the ergonomics.
But we also have to allow importing the namespace object, of course. And sometimes a module will not have a default export, so forcing you to write .then((dummy, named) => ...) is obnoxious for those cases. Hence a second method specifically for asking for the namespace object.

@caridy @domenic It's important to understand the use case of local import as not being about reflection but rather about dynamic loading. Reflection is a low-level operation meant for when you're trying to extend the base semantics of the language/system. Dynamic loading is simply a thing apps commonly need to do.
Also keep in mind that .import will not resolve the promise until the module has been initialized, fully executing its top-level code. The overwhelming majority of the time, the aliasing behavior is only important for the initialization phase where top-level bindings are being set up. It's extremely rare to mutate top-level exports after that point. So it's inappropriate to optimize this API around that as a constraint.
Again, the low-level loader API should fully generalize the semantics, and there it is certainly sensible to have operations that just produce the namespace object as the most general thing. But the purpose of the local import API is as a high-level API whose ergonomics and style should mirror the ergonomics and style of the declarative syntax.

Not having to say default explicitly is very important to the ergonomics.

Yes

It's extremely rare to mutate top-level exports after that point.

Agree. We can probably make the case that the value of the default export should never change, in which case something like local.import("./foo.js").then(def => ...) should be fine.

You have to say default all the time already, it's a common way to export things.  I see your point about having symmetry between the forms. But the declarative form is nice because of syntactical affordances you won't have here.
Question,
local.import("./foo.js").then((def, named) => ...)

even valid? I thought Promise only had a single return value.

You have to say default all the time already, it's a common way to export things.

The important distinction is that you only say default inside the implementation of a module, just as you have to do something explicit in CommonJS/Node (module.exports = ...;). But on the consumer side, you don't have to think about it having a name. Anyway sorry to beat a dead horse; it sounds like you agree the symmetry is important.

I thought Promise only had a single return value.

LOLOLOL. (At least I'm slightly comforted by the fact that the lead of the promises spec didn't catch this either. ;-P)
I think a reasonable alternative is two forms, with the short name providing the default, and the longer name providing the namespace object:
l.import("./rubber-chicken.js").then(RubberChicken => ...)
l.importAll("./utils.js").then(utils => ...)

The latter lets you extract the default export if you want:
l.importAll("jQuery").then(namespace => {
  let $ = namespace.default;
  ...
});

Or you can combine the two operations:
Promise.all(l.import("jQuery"), l.importAll("jQuery"))
  .then(([$, namespace]) => ...);

jejeje, importAll resonates well with me considering the work we have done on https://github.com/estree/estree/blob/master/es6.md#exportalldeclaration, which is symmetrical to the import all concept. I like it.
still we should clarify whether and how people will be able to update the default export from within a module, if there is no way to do that, then this syntax will be perfect.

I think a reasonable alternative is two forms, with the short name providing the default, and the longer name providing the namespace object:

l.import("./rubber-chicken.js").then(RubberChicken => ...)
l.importAll("./utils.js").then(utils => ...)

I would appreciate a simplified explanation of what you all are talking about here.  What is a "namespace object"?

What is a "namespace object"?

Also known as a module instance object in earlier versions of the module spec; ES6 now calls them "module namespace exotic objects." For example when you do
import * as fs from "fs";

It's the object that fs is bound to. It exposes all the module's named exports as properties (and if there's a default export, it has a named property called default that points to that).

Thanks!
So the idea here is that
l.import("./rubber-chicken.js").then(RubberChicken => ...)
l.importAll("./utils.js").then(utils => ...)

is better than
l.import("./rubber-chicken.js").then(RubberChicken => ...);
l.import("./utils.js").then(ns => ns.default).then(utils => ...);

(where my import returns the namespace)?
IMO import should give the namespace. If we really need a thing for default (which we've almost never used in our es6 code), then it should have the special name, eg something obvious like importDefault.  The short name should do the non-special thing.

An overloaded API like
l.import("./rubber-chicken.js").then(RubberChicken => ...);
l.import("./utils.js").then(ns => ns.default).then(utils => ...);

is bad because it changes what it returns based on whether you have a default export. But adding a default export should be a backwards-compatible API evolution: it should not break clients who aren't currently using it. The module system was designed with this principle as well.

IMO import should give the namespace. If we really need a thing for default (which we've almost never used in our es6 code), then it should have the special name, eg something obvious like importDefault. The short name should do the non-special thing.

I recognize there will be different styles in different communities, but default export is a highly popular pattern in many many JS ecosystems (from jQuery and underscore to AMD to NPM), and the ES6 module system picked that as a winner. In particular, the ergonomics of the import syntax in the module system are optimized for default export. The ES6 design isn't going to change, and the design of the reflective API has to parallel the design of the syntax.

An overloaded API like

l.import("./rubber-chicken.js").then(RubberChicken => ...);
l.import("./utils.js").then(ns => ns.default).then(utils => ...);

There is no overloading here.  The namespace is returned, always.

default export is a highly popular pattern in many many JS ecosystems (from jQuery and underscore to AMD to NPM), and the ES6 module system picked that as a winner.

That's quite different from my read. To me this default thing was added to appease the backward compat crowd. Really it seems obvious: if the ES6 module system picked it as winner then we would not need the funky extra default keyword at all!
Our dynamic import should mirror our static import:
  Reflect.loader.import('./foo.js').then(foo => ...);  // namespace foo

mirrors
  import * as foo from "./foo.js";

and
  Reflect.loader.importDefault('./foo.js').then(foo => ...); // default from foo

mirrors
  import { default as foo } from './foo.js';

To counterbalance @johnjbarton, in my ES6 projects I almost never use named imports.
I am still not very comfortable with the fact that .import() gives a non-updatable binding while import gives the magic-updating one. I would be more comfortable if we forced people to type .default since then the exotic object [[Get]] would be triggered each time, ensuring the binding stays updated.

@domenic Could you point to an example? (Mine is the Traceur source https://github.com/google/traceur-compiler).
Is there a cogent pro/con discussion on this issue?

@johnjbarton nobody will do import { default as foo } from './foo.js';, they will do import foo from './foo.js'; that's the whole point @dherman is trying to make, you should NOT have to use the keyword default to import the default export, and that should be the most common use-case.

To counterbalance @johnjbarton, in my ES6 projects I almost never use named imports.

same here, you can check the of the packages used in formatjs.io, we use named exports in some places, but the majority of them are default exports.

While I do like the looks of the API that @dherman is proposing being the dynamic form of the importing the default export, I want to echo @domenic's concern about the non-updating binding. To me, this difference is trumping the economics argument and I think import() should return a Promise for the "module namespace exotic object."
My gut feeling is that the number of dynamic imports within an app's code base will be dwarfed by those which use the declarative syntax, so I don't think the economics arguments holds up against the wtf-js one.

I'm still slightly on the side of only having the one signature import that returns the module.  I do not see the benefit of only getting part of a module.
Regardless please do not choose importAll if you go this route.  Users will assume it takes an array of modules to import.  "import all of these things" makes sense, "return all of the bindings from this import" less so.
Personally I'm with @johnjbarton and use mostly named imports.  But why should we base this on conjecture? It seems like there is enough es6 code floating around that a decent survey could be done.

I think we might be over-estimating how used import is going to be.  In my experience we use it in 2 or 3 places primarily:

To initially load your application.  This will be superseded by <module>.
To progressively load parts of an application.
To conditionally load modules (based on environment variables for example).

1 is going to go away, and 2 and 3 are not used by a lot of applications anyways.  I think import is safely within the realm of sophisticated applications. People working on these applications can handle default, imo.

@caridy Nevertheless, any explanation of import foo from './foo.js'; will have to include the word default. To distinguish dynamic import of the namespace (that is, default thing we get without the default keyword) from the dynamic import of the developer-designated default we need a modifier. The natural modifier is 'Default', applied to obtain the developer-designated default.  Applying a modifier "All" and having it return the thing we get by default without using default just compounds the confusion, in much the same way as I have done here.

Yikes, I believe I've perpetrated a pretty big confusion here. (Mea culpa!) There are two separate APIs to discuss, and I think at various points in this thread we may have been talking about one or the other. For clarity, let me give them names:

reflective import: an API on Reflect.Loader.prototype that provides a complete reflection of what the module system can do
async import: an API on the object bound via import local from this; that provides a way to progressively, asynchronously import modules

The difference
My view is that a reflective layer is meant more for advanced, frameworky code that is thinking at the level of the mechanics of the language semantics, but async import is more common. @matthewp fairly makes the point that it's still pretty rare. As @ericf put it in a private chat, it'll be common per-app-codebase but rare in frequency; most apps will have it, but each app will typically have only a handful of instances of it.
Constraints
Reflecting export mutability
We all agree it's a requirement for the low-level reflective API to reflect the mutability of exports. Module namespace objects are live views of the module's exports, so in that sense it's reasonable for the low-level reflective API to just have a single method that produces the namespace object.
Respecting the single-export mental model
The design of the module system allows a mental model where you can conflate the concept of a module's default export with the module itself. For example, you can create a UI component called AdminPanel that is the single export of a module, and allow the consumer to think of "admin panel" as being both the module and its sole export:
import AdminPanel from "./admin-panel.js";
...
someComponent.click().then(() => {
  let panel = new AdminPanel();
  ...
});

Notice how both the name of the module and the name of its exported abstraction are the same concept.
Now, if the programmer decides the admin panel is used rarely, they can do progressive loading of the code and change this to an async import. If we provide a convenient method for dynamic loading of default export, the programmer writes:
import local from this;
...
someComponent.click().then(() => {
  local.import("./admin-panel.js").then(AdminPanel => {
    let panel = new AdminPanel();
    ...
  });
});

If we only have a method that produces a namespace object, they have to drop below that level of abstraction:
import local from this;
...
someComponent.click().then(() => {
  local.import("./admin-panel.js").then(({ AdminPanel: default }) => {
    let panel = new AdminPanel();
    ...
  });
});

IOW, instead of the local import being just an async way of importing, it's also a reflection mechanism: you have to think about the details of the JS module system instead of just thinking about your app concepts.
Hazard of late mutations of default export
If the admin panel decides to mutate its default export late at runtime, it's possible for uses of a default-export-only API to go stale. For example, the admin panel might do something like:
var AdminPanel = class { ... };
...
// mutate the default export at runtime
someComponent.click().then(() => {
  AdminPanel = ...;
});
...
export { AdminPanel as default };

and then code that uses it might hang onto a stale binding:
...
local.import("./admin-panel.js").then(AdminPanel => {
  someOtherComponent.click().then() => {
    let panel = new AdminPanel(); // oops! didn't get the updated binding
  });
});

Note that this is not an issue for mutation of the default export during initialization, since the import promise is only fulfilled after initialization completes. So for example you won't witness incomplete initialization of cycles. They have to explicitly modify the binding later on.
Consistency between the two layers
If both loader and local objects have importing APIs, for them to be subtly different would be confusing. For example, if loader.import() produces a namespace object but local.import() produces the default export, this would be an inconsistency between two APIs that are highly related.
My conclusion
I think this comes down to how real we think the risk of the hazard is and how bad the mental model violation is. IMO, the risk is low because people rarely mutate their exports, and the mental model violation is very bad for a high-level API, because the whole purpose of the design of the module system was to provide syntactic sugar to empower the conflation of single exports with their module. All that said, I recognize @matthewp's point that this is not going to be a ton of code per codebase, because progressive loading of an app is typically only done in a few select places.
So my preference is that we support both .import and .importAll on both objects. This allows you to get at the full namespace object and to get the full live-updated version of the default export if you have to. The worst-case scenario is that some popular library or libraries to export a runtime-mutating default export and it becomes a best practice to avoid .import and use .importAll, but I think it's better as a best practice to say don't mutate your exports after module initialization.

+1 on *.import() and *.importAll() where importAll() is reflective of import * as ... and import() is just sugar on top of importAll(), as in *.import("./mod.js").then(({ def: default }) => {...}); since def is not a live binding, but a stale binding.

Fair points, I won't fight this too hard even though I don't love it.
Now back to bikeshedding :-)  I really think All is wrong here. If a function is a verb and its arguments the object, importAll says "import all of these modules".  But what we really are saying is "import everything from this module".  importFrom maybe?  If its named importAll I guarantee you devs will confusingly do:
importAll(['./login-panel.js', 'admin-panel.js']).then(function(panels) { });

I like importFrom.

Good point, but both forms correspond to import _______ from "..."; so it's not the right distinction. I hate to tax both APIs but what would you think of

.importFrom("foo").then(Foo => ...)
.importAllFrom("foo").then(ns => ...)
Does that clear up the ambiguity with importing multiple modules? I'm not sure what I think of it...

A more concise naming scheme that I'm warming to would be import and importStar. The correspondence to the analogous syntax is very obvious that way.

again, in estree we were from *Batch, to *Star to *All. I think we can settle with importFrom() and importAllFrom(), it is pretty clear for me that it does not import multiple modules, if that is the case, then it will be importFromAll().

How about import and importModule?
On Mar 14, 2015 7:40 AM, "Caridy Patiño"<EMAIL_ADDRESS>wrote:

again, in estree we were from *Batch, to *Star to *All. I think we can
settle with importFrom() and importAllFrom(), it is pretty clear for me
that it does not import multiple modules, if that is the case, then it will
be importFromAll().
—
Reply to this email directly or view it on GitHub
https://github.com/whatwg/loader/issues/36#issuecomment-80480872.

How about import and importModule?

I'd hate to tax import even for the sake of consistency.  I don't hate the import and importStar combo.

I think, importAll is too close to Promise.all.
However I can't decide which variant is better:
import&importModule: Most of my modules have a default export, so I need that variant more often
importDefault&import: The general method has the shorter name, that's nice, too
@dherman Your example above has a problem: Can you correct that?
local.import("./admin-panel.js")
  .then(AdminPanel => someOtherComponent.click())
  .then() => {
    let panel = new AdminPanel(); // <- AdminPanel is undefined
  });

@MajorBreakfast Fixed, thanks. Having the general method get the shorter name is the wrong way around. "Make the common cases easy and the uncommon cases possible."

Ah, there's one I overlooked: the namespace form is import * as ns from "foo", so the as could be the differentiator: import vs importAs. That's actually pretty sweet. Short and sweet for both, privileges single-export, connects to the syntax. I like it!

If it does not already, I would imagine that import-as form could be modified to allow only partial imports such as import { newPropName1, newPropName2 } as ns from "foo"; (i.e., producing ns === {newPropName1: ... newPropName2: ...}). If this form is or could be allowable, then the meaning would thus seem to be implied more by the * than the as.
What about importFull?
And for either case, how about actually allowing the syntax as mentioned in https://github.com/whatwg/loader/issues/36#issuecomment-79407109 for import (as opposed to the proposed importAs). Together with parameter destructuring, this would make writing multiple imports very elegant.

producing ns === {newPropName1: ... newPropName2: ...}

I don't think this is necessary; the idea of partial imports is not that only a partial module is imported but simply that you're only binding the parts you care about in local variables. Destructuring gives you the analogous thing:
local.importAs("admin-panel").then(({ foo, bar }) => { ... });

I don't see much benefit to allocating a new object with only some of the exports defined on it, and it also brings in new complexities like whether to include other state that might live on the namespace object (like expando properties with Symbol names).

And for either case, how about actually allowing the syntax as mentioned...

You get that with Promise.all already, but maybe you'd like to see this available with more convenience? ISTM a convenient way to do this is to overload import and importAs to accept either an array or a stringable, so if you write:
local.import(["foo", "bar", "baz"]).then(([foo, bar, baz]) => { ... });

you wait for all three, and if you write:
local.import("foo").then(foo => { ... })

you only wait for the one. Otherwise we start getting a combinatorial explosion of awkwardly named methods (import, importAs, importAll, importAsAll).
But I can see how the overloading would be more convenient than
Promise.all(["foo", "bar", "baz"].map(s => local.import(s))).then(([foo, bar, baz]) = { ... });

:+1: on importAs

The number of choices in this discussion is evidence to me that trying to match the static API is not a good way to go. They just aren't alike.
Maybe we need to just admit that ES6 doesn't have a single export and not tailor the API to the hack to make it (almost) appear that it does.  Dynamic importing is an "advanced" API anyways, I think I'm back on board for having a single loader.import that loads the entire module and then using destructors to get the default, if that's what you need.

@dherman +1 for overloading with arrays for the added convenience.

I don't think that the name importAs fits:
//Actual renaming: "as" fits
import * as name from 'module'
import { hello as world } from 'module'

// No renaming: "as" doesn't fit
System.importAs('module')
  .then(module => { ... })

I think I'm a bit @matthewp now (just import) or import+importDefault. Those two options are the only options that have descriptive names. The other feel wrong to me.
+1 for overloading with arrays.
@dherman Found another mistake:
.then(({ AdminPanel: default }) => {
should be
.then(({ default: AdminPanel }) => {, It's propertyName: variableName = defaultValue (mdn)

-1 for overloading with arrays. We have compositional primitives for a reason. People can write their own dwimImport function if they really can't deal with Promise.all.

-1 as well on the overloading.

In my view, a person should be able to write declarative code out of the box. There is almost nothing more basic in JavaScript than wishing to load modules, and having to copy in extra boilerplate just to do that detracts, imo, from its elegance, quick digestability to others reading the code, and speed of development. One can hide away implementation details within dedicated modules but the actual loading should not need implementation details, imv.

@brettz9 It's hard to debate this until https://github.com/whatwg/loader/issues/27 is answered. From my perspective the spec authors haven't decided yet if they want Loader to be low-level and follow Extensible Web (which would be my preference) or be a high-level API that accomplishes only what is needed to load ES6 modules. From the issues I've participated in sometimes it seems they want it to be the former and sometimes the latter.
We've seen in the past what happens when an API is both too low and too high (IndexedDB) so I hope this is decided quickly; it will make these other discussions much easier.

Earlier @dherman said:

Yikes, I believe I've perpetrated a pretty big confusion here. (Mea culpa!) There are two separate APIs to discuss, and I think at various points in this thread we may have been talking about one or the other. For clarity, let me give them names:

reflective import: an API on Reflect.Loader.prototype that provides a complete reflection of what the module system can do
async import: an API on the object bound via import local from this; that provides a way to progressively, asynchronously import modules

Is the second one a replacement for what we used to call the dynamic loading: eg System.import()?  Or is there three APIs using the word import()?

@johnjbarton no. async import reference to the ability to access a loader instance that is bound to a module, and therefore it can perform the exact same import operations that you can achieve using the declarative syntax. We don't know yet, but in previous discussions it seems that it aligns well with what we want to achieve with the global loader, in other words, they will have the same API, although the internals are a little bit different since one of them is relative to a page, the other is relative a the module.

How about importNS here? For import namespace. Would that terminology be correct?

It's hard to debate this until #27 is answered. From my perspective the spec authors haven't decided yet if they want Loader to be low-level and follow Extensible Web (which would be my preference) or be a high-level API that accomplishes only what is needed to load ES6 modules. From the issues I've participated in sometimes it seems they want it to be the former and sometimes the latter.

I certainly don't feel undecided about it! :) I tried to answer the question in this thread. In short:

The static syntax is the overwhelmingly common case and of course high-level.
Async import, while less common than syntax, will still be likely to come up a few times in most any reasonable-sized app, and is a high-level API.
Reflective import will be used rarely, mostly in the internals of loading frameworks. It's a low-level API.

@matthewp Async import and reflective import are two different APIs, and they don't have the same design constraints. In particular, async import is tied to syntax so it can never be fully abstractable. This means people are more prone to suffering through the papercuts.

Maybe we need to just admit that ES6 doesn't have a single export and not tailor the API to the hack to make it (almost) appear that it does.

You're eliding the semantic model with the programming model. While the internal semantics of ES6 does not have any special concept of a default export, default export is a central part of the design. It's part of the way modules are thought about and the way they are written.
I appreciate people working through the different possibilities here, btw. I know it can be frustrating but IMO it's always good to map out a space of possibilities before landing too soon on a conclusion. In that spirit, another comment coming in a sec... ;-P

@johnjbarton No, import local from this; is a candidate syntax for functionality we've known has been missing from ES6: the ability to expose to each module its own specific information. This includes metadata like its filename as well as the ability to do dynamic loading relative to that module.

@domenic @caridy Let's hold off on the overloading question as a mostly-orthogonal question for just a bit.

So here's another syntactic possibility we hadn't considered previously for async import. :D
A late-breaking addition to ES6 was the new.target syntax, and in the process of discussing the idea, Allen Wirfs-Brock mentioned the possibility of exposing module metadata via an analogous import.foo syntax. The attractive thing about this is that it allows programmers to get access to metadata and async import without needing to inject an extra import declaration at top-level. (This was a benefit of my original idea of using this, but @domenic -- rightly! -- objected that we should not encourage the use of this outside of the context of methods and class constructors.)
In that light, a candidate syntax-and-API for async import would be:
import.default("Spinner").then(Spinner => { ... });
import.namespace("fs").then(({ readFile, writeFile }) => { ... });

(I can live with making default explicit here for a few reasons. I'll grant @matthewp's point that this is more advanced than the declarative syntax. But it's still important to have convenient async API to match the convenient syntax because, as I've said, it's exposed to syntax and higher level than the reflection API. And it's important for the default case to be more convenient than the namespace case.)
Note that if we specify .default and .namespace to be hard-bound to this module, then they can conveniently be extracted and used in higher-order abstractions. So even without overloading, the convenience of Promise.all is pretty good:
Promise.all(["Spinner", "Slider", "Gallery"].map(import.default)).then(...);
Promise.all(["fs", "util", "collections"].map(import.namespace)).then(...);

Forgot to mention, I also propose the metadata (like filename, URL, debugging info, etc) live as a separate subobject, probably import.metadata. It's nice to separate the concerns of async import from accessing module metadata, and it also sets the metadata object aside as the place where host environments can stash non-standard properties.

@dherman Can you explain how this works? Is import a contextual object available within a module?

@matthewp It's not reflected as a first-class object, in that you can't get your hands on the object directly. It's like an object where the syntax only allows you to access certain predetermined properties. So for example you can ask for new.target but you can't say var x = new; ... x.target ...

But yes, it's contextual per-module.

That's interesting, I hadn't heard of this feature. I'll have to dive into esdiscuss then, but I think I understand what you're saying.
I like the idea overall and agree it's a clever way of working around this problem.  You do still want access to the loader within a module, import.local maybe.

I should also show what this ends up looking like in async functions:
let Spinner = await import.default("Spinner");
let { readFile, writeFile } = await import.namespace("fs");
...

Very elegant!

This look pretty elegant!
Everything suddenly becomes very clean if we can go this way.
Don't be to frustrated: We can restart the naming discussion around this syntax! :) :)
Promise.all(['Spinner', 'Slider', 'Gallery'].map(import)).then(...) // Default import, call import as a function

import.namespace('fs').then(fs => ...) // Namespace import

import('fs', 'readFile').then(readFile => ...) // New idea: Named import shortcut

You tell me if treating import as function does even work. I just assume that it's possible since the static syntax includes always the from part that is pretty distinctive for a parser.

Does this need to be a metaproperty and not some form of a function? It seems like a language extension would mean this loader would have to be the backer for all host environments if it assumes it gains meta-properties.

@bmeck Not having the Loader be the backer for all host environments would be a major mistake.

@matthewp you need to explain that in depth. loader vs es import/export are 2 different things to my knowledge

They are different things but users write code that run in multiple JavaScript environments.

@matthewp it has different implications semantically than existing code/systems (couchdb, webworkers, mongodb, node, ringojs, ...) which is the issue. having the semantics able to match would be nice as well as be much safer for upgrade purposes

I agree, a breaking change for those legacy systems is probably a no-go.  I wish there were more participation here from all interested parties but this repo has been largely dark for the last several months.
There's a specification at amodro-lifecycle that attempts to address some of these legacy needs such as Node, I would suggest giving it a read if you have time.

@matthewp my last experience here did not include metaproperties or requirements for it to be used as the import hook handler for VMs. https://github.com/WebAssembly/design/issues/256 brought me here made me see several changes like this issue which make it a much larger scope than I thought it was. my interest came as a result of the increased scope and WASM making me come reread it in the current form

The metaproperty proposal only exists in this issue and hasn't been written to any spec AFAIK.  There hasn't been any increase in scope to my knowledge, it is now much smaller is scope actually.

@matthewp we commented on it because it is a language extension which immediately concerned us. A lot of work is often done in conversations and only shows up in specs to replace TODOs etc. at a very late stage if we want to read public available text. I think talking in issues is fairly similar to talking about the spec.

@matthewp @bmeck just a side note, the import imperative call is bound to the loader instance that loads the host module in the first place (just like require() is bound to the host module), which means all modules will have access to it since they all have a loader associated, even if it is the built-in default loader implemented by the runtime.


Fixed issue with record -> replay body encoding

This matches the replay decode check in https://github.com/node-nock/nock/blob/master/lib/request_overrider.js#L325
Ideally we would also add a corresponding check for isBinaryRequestBodyBuffer (https://github.com/node-nock/nock/blob/master/lib/request_overrider.js#L347):

if((common.isContentEncoded(headers) || isBinaryRequestBodyBuffer) && common.isBinaryBuffer(mergedBuffer)) { ...

However I wanted to keep this pr small and get some feedback.

So I was thinking about this more. The appropriate way of doing this is to store the binary or hex information in the recoding and not try and guess it. Agreed?

@ierceg All meta information is captured. However the logic to determine if the data should be stored/loaded as binary is different. Centralizing this logic would also solve this issue. However it might be easier to just store that information as binary=true/false.


autogen-assistant doesn't work on Azure OpenAI

If you edit the the get_default_agent_config()-Method in utils.py to use Azure OpenAI, as described in the documentation:
`def get_default_agent_config(work_dir: str, skills_suffix: str = "") -> FlowConfig:
"""
Get a default agent flow config .
"""
llm_config = LLMConfig(
    config_list=[{
            "model": "gpt4",
            "api_key": "<myKey>",
            "api_base": "<myBase>",
            "api_type": "azure",
            "api_version": "2023-06-01-preview"
    }],
    temperature=0,
)

`
Then you'll receive an error:
openai.OpenAIError: The api_key client option must be set either by passing api_key to the client or by setting the OPENAI_API_KEY environment variable

Thanks for noting this @ArneJanning .
I am looking at the OAI_CONFIG_LIST documentation here and it looks like the correct formatting for azure openai models is
{
        "model": "<your Azure OpenAI deployment name>",
        "api_key": "<your Azure OpenAI API key here>",
        "base_url": "<your Azure OpenAI API base here>",
        "api_type": "azure",
        "api_version": "2023-07-01-preview"
    }

Note that the difference is api_base  -> base_url .
What do you get when you try the above?

Thank you for your answer @victordibia .
I changed the api_base to base_url and still get the same error:
`autogenra ui --port 8081
INFO:     Started server process [105794]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://<IP_ADDRESS>:8081 (Press CTRL+C to quit)
INFO:     <IP_ADDRESS>:56470 - "GET / HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56470 - "GET /app-a69e64a20490df34caf8.js HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56482 - "GET /framework-34c4775408c4a2a587eb.js HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56470 - "GET /webpack-runtime-9a1c1a0dc45832ebafbd.js HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56482 - "GET /page-data/index/page-data.json HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56470 - "GET /page-data/app-data.json HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56470 - "GET /component---src-pages-index-tsx-9c8c5671443f8293283f.js HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56470 - "GET<EMAIL_ADDRESS>HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56482 - "GET<EMAIL_ADDRESS>HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:56488 - "GET /manifest.webmanifest HTTP/1.1" 200 OK
Traceback (most recent call last):
File "/home/arne/src/autogen3/autogen/samples/apps/autogen-assistant/autogenra/web/app.py", line 85, in add_message
response_message: Message = chatmanager.chat(
^^^^^^^^^^^^^^^^^
File "/home/arne/src/autogen3/autogen/samples/apps/autogen-assistant/autogenra/autogenchat.py", line 24, in chat
flow = AutoGenFlow(config=flow_config, history=history, work_dir=scratch_dir, asst_prompt=skills_suffix)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arne/src/autogen3/autogen/samples/apps/autogen-assistant/autogenra/autogenflow.py", line 26, in init
self.sender = self.load(config.sender)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arne/src/autogen3/autogen/samples/apps/autogen-assistant/autogenra/autogenflow.py", line 116, in load
agent = autogen.UserProxyAgent(**asdict(agent_spec.config))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arne/src/autogen3/.venv/lib/python3.11/site-packages/autogen/agentchat/user_proxy_agent.py", line 72, in init
super().init(
File "/home/arne/src/autogen3/.venv/lib/python3.11/site-packages/autogen/agentchat/conversable_agent.py", line 115, in init
self.client = OpenAIWrapper(**self.llm_config)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arne/src/autogen3/.venv/lib/python3.11/site-packages/autogen/oai/client.py", line 77, in init
self._clients = [self._client(config, openai_config) for config in config_list]  # could modify the config
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arne/src/autogen3/.venv/lib/python3.11/site-packages/autogen/oai/client.py", line 77, in
self._clients = [self._client(config, openai_config) for config in config_list]  # could modify the config
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arne/src/autogen3/.venv/lib/python3.11/site-packages/autogen/oai/client.py", line 138, in _client
client = OpenAI(**openai_config)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arne/src/autogen3/.venv/lib/python3.11/site-packages/openai/_client.py", line 93, in init
raise OpenAIError(
openai.OpenAIError: The api_key client option must be set either by passing api_key to the client or by setting the OPENAI_API_KEY environment variable
`

I get the same error with OpenAI api_key. No matter how I set get_default_agent_config().
I tried
llm_config = LLMConfig(     config_list=[{             "model": "gpt-4",             "api_key": "<myKey>",     }],     temperature=0, )
and also tried the old way I use in autogen
config_list = [     {         'model': 'gpt-4',         'api_key': "<myKey>",     }, ] llm_config = {     "cache_seed": 42,       "temperature": 0,     "config_list": config_list, }

Yeah i've the same issue, whatever i used, the message stay here the api_key is not passed to the original openai library

I try code like this, and then run python test/twoagent.py success.
config_list = [ { 'model': 'gpt-3.5-turbo', 'api_key': "xx","base_url":"xxx","api_type":"azure","api_version": "2023-07-01-preview" }]

To fix this, try to change code at autogen-assistant/frontend/src/components/atoms.tsx. Add the following code, then cd autogen-assistant/frontend, use yarn build rebuild the frontend.

After that, when add mode, you need fill the Api Version, then save it.

Now you can use the Azure OpenAI.

When direct pip and run autogenra or autogenstudio from cmd, how to specify azure OpenAI config file?  and I tried to edit the model config (add key/base_url, model type and version etc) from autogenstudio Build page, it did not take effect too.  Maybe need to add a config parameter for this, e.g.  autogenstudio ui --config "config_file"

Looking into it. Thanks
Get Outlook for iOShttps://aka.ms/o0ukef

From: Yanzhi Li @.>
Sent: Saturday, December 16, 2023 8:32:34 AM
To: microsoft/autogen @.>
Cc: Comment @.>; Assign @.>
Subject: Re: [microsoft/autogen] autogen-assistant doesn't work on Azure OpenAI (Issue #755)
When direct pip and run autogenra or autogenstudio from cmd, how to specify azure OpenAI config file? and I tried to edit the model config (add key/base_url, model type and version etc) from autogenstudio Build page, it did not take effect too. Maybe need to add a config parameter for this, e.g. autogenstudio ui --config "config_file"
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/autogen/issues/755#issuecomment-1858861660 or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALZV765QAUQFYTVWLYJXRTYJXEKFBFKMF2HI4TJMJ2XIZLTSWBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVI3DCMJVGQ3TENJVHCSG4YLNMWUWQYLTL5WGCYTFNSBKK5TBNR2WLKRWGEZDSMBTGE2TKONENZQW2ZNJNBQXGX3MMFRGK3FMON2WE2TFMN2F65DZOBS2YSLTON2WKQ3PNVWWK3TUUZ2G64DJMNZZJAVEOR4XAZNKOJSXA33TNF2G64TZUV3GC3DVMWUTMOBQGEZDAMBXGGBKI5DZOBS2K2LTON2WLJLWMFWHKZNKGIYDAOJXGA4DKMZZQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKRWGEYTKNBXGI2TKOECUR2HS4DFUVWGCYTFNSSXMYLMOVS2UNRRGI4TAMZRGU2TTJ3UOJUWOZ3FOKTGG4TFMF2GK.
You are receiving this email because you commented on the thread.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

my issue was llm_config was not passed to autogen.groupchatmanager function.  After the fix, no more api_key missing error.
BEFORE:
    groupchat = autogen.GroupChat(agents=[user_proxy, assistant], messages=[], max_round=MAX_ITER)     manager = autogen.GroupChatManager(groupchat=groupchat)
AFTER:
    groupchat = autogen.GroupChat(agents=[user_proxy, assistant], messages=[], max_round=MAX_ITER)     manager = autogen.GroupChatManager(groupchat=groupchat, llm_config=llm_config)
Here is my llm_config:
`config_list = [
{
"model": "gpt-35-turbo",
"api_key": os.environ.get("AZURE_OPENAI_API_KEY"),
"base_url": os.environ.get("AZURE_OPENAI_API_BASE"),
"api_type": "azure",
"api_version": "2023-07-01-preview",
}
]
llm_config={
"timeout": 600,
"cache_seed": 42,
"config_list": config_list,
}`

When direct pip and run autogenra or autogenstudio from cmd, how to specify azure OpenAI config file? and I tried to edit the model config (add key/base_url, model type and version etc) from autogenstudio Build page, it did not take effect too. Maybe need to add a config parameter for this, e.g. autogenstudio ui --config "config_file"

I had the same doubt about using run autogenstudio ui from cmd

HI @huangpan2507 ,
AutoGen studio is a UI interface on top of AutoGen.
Currently, it is built such that the user specifies the agent workflow configuration in the UI (rather than a config file).


Create-React-App

Need someone to create a React App to start the client side of the project.  If you need help understanding what that means, take a look here: https://reactjs.org/docs/create-a-new-react-app.html
Terminal Command: npx create-react-app

Hi Ben, is it just creating a New React App so that we can add all the HTML and CSS files in there ?

Yup! Real simple


🐛 [BUG] - Overwhelming Info Output from Unreferenced Definitions

Pre-requisites

[X] I checked the documentation and found no answer.
[X] I checked to make sure that this issue has not already been filed.

What version of the AaC package are you using? Check your version with the command: aac version.
0.2.17
Description
The new validation that checks for unreferenced definitions is producing overwhelming output. It's a combination of issues including false-positives and some edge cases. When I run validation on the usecase for the alarm clock model I get this massive output:

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_plant_uml/gen_plant_uml.yaml.
No references to 'Generate PlantUML Diagrams' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/model/alarm_clock/usecase.yaml.
No references to 'Trigger Alarm' in the language context.

Validation ERROR from 'Usecase sources and targets refer to defined participants' in
/workspace/AaC/python/model/alarm_clock/usecase.yaml. Source 'alarm' of step 'The alarm is
activated to emit a noise from the AlarmClock speaker' does not refer to a participant of the usecase.

Validation ERROR from 'Usecase sources and targets refer to defined participants' in
/workspace/AaC/python/model/alarm_clock/usecase.yaml. Target 'alarm' of step 'The timer
emits an alarm notification to the alarm' does not refer to a participant of the usecase.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/unique_requirement_ids/unique_requirement_ids.yaml.
No references to 'Validate requirement IDs are not duplicated.' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_protobuf/gen_protobuf.yaml. No references
to 'SchemaMessageOptions' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_design_doc/gen_design_doc.yaml. No
references to 'Generate System Design Document' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/model/alarm_clock/structures.yaml. No references to 'my_alert' in the
language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/spec/spec.yaml. No references to 'Backend' in the language
context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/reference_fields/reference_fields.yaml. No
references to 'Validate query reference format' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/root_keys/root_keys.yaml. No references to
'Validate root keys' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_gherkin_behaviors/gen_gherkin_behaviors.yaml.
No references to 'Generate Gherkin Feature Files' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/unique_names/unique_names.yaml. No references
to 'Unique definition names' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/reference_targets/reference_targets.yaml. No
references to 'Reference target valid' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_protobuf/gen_protobuf.yaml. No references
to 'Map' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/exclusive_fields/exclusive_fields.yaml. No
references to 'Mutually exclusive fields' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/unused_definitions/unused_definitions.yaml. No
references to 'Validate definition references' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/validator_implementation/validator_implementation.yaml.
No references to 'Validation definition has an implementation' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_plugin/gen_plugin.yaml. No references to
'CommandArgumentFields' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/defined_references/defined_references.yaml. No
references to 'Type references exist' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/validator_implementation/validator_implementation.yaml.
No references to 'Validate implementations for validators' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/usecase_participants/usecase_participants.yaml.
No references to 'Validate usecase participants' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/spec/spec.yaml. No references to 'Generation' in the language
context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_protobuf/gen_protobuf.yaml. No references
to 'Generate Protobuf Messages' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/unique_names/unique_names.yaml. No references
to 'Validate names are not duplicated' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/spec/spec.yaml. No references to 'Query' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/spec/spec.yaml. No references to 'Internal' in the language
context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/reference_fields/reference_fields.yaml. No
references to 'Reference format valid' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/requirement_references/requirement_references.yaml.
No references to 'Validate referenced IDs' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/model/alarm_clock/structures.yaml. No references to
'AddTimerAlertRootNode' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/unused_definitions/unused_definitions.yaml. No
references to 'Definition is referenced' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/required_fields/required_fields.yaml. No
references to 'Required fields are present' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/subcomponent_type/subcomponent_type.yaml. No
references to 'Subcomponents are models' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/required_fields/required_fields.yaml. No
references to 'Validate required fields' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/usecase_participants/usecase_participants.yaml.
No references to 'Usecase sources and targets refer to defined participants' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_plugin/gen_plugin.yaml. No references to
'Generate Plugin' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/reference_targets/reference_targets.yaml. No
references to 'Validate query reference targets' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/defined_references/defined_references.yaml. No
references to 'Validate type references' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_protobuf/gen_protobuf.yaml. No references
to 'ProtobufPrimitiveTypesExtension' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/spec/spec.yaml. No references to 'Management' in the language
context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/root_keys/root_keys.yaml. No references to
'Root key is defined' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/exclusive_fields/exclusive_fields.yaml. No
references to 'Validate mutually exlusive fields' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/requirement_references/requirement_references.yaml.
No references to 'Referenced IDs exist' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_json/gen_json.yaml. No references to
'Generate JSON' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/subcomponent_type/subcomponent_type.yaml. No
references to 'Validate model subcomponents' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/model/alarm_clock/usecase.yaml. No references to 'Set Alarm Time' in the
language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/cli/builtin_commands/specifications/specifications.yaml. No
references to 'Specifications' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/first_party/gen_protobuf/gen_protobuf.yaml. No references
to 'EnumMessageOptions' in the language context.

Validation INFO from 'Validate definition references' in
/workspace/AaC/python/src/aac/plugins/validators/unique_requirement_ids/unique_requirement_ids.yaml.
No references to 'Requirement ID is unique' in the language context.

Reproduction URL
https://github.com/DevOps-MBSE/AaC
Reproduction steps
Please enter an explicit description of your issue
1. Open the repo
2. Run `aac validate model/alarm_clock/usecase.yaml'
3. Get overwhelmed.

Screenshots
No response
Logs
Not helpful

Pertinent Files
In repo

Not currently being experienced in 0.4.0 because the constrainer was not brought forward and converted. The conversion task for this is #741 . That potentially the conversion could make use of the dataref primitive constraint since it is the constraint that runs when checking referenced definitions.

Based on the results of the 0.4.0 implementation and the current thoughts on the unreferenced constraint not being needed currently, this issue is being closed.


UI - Setting snapshot/backup configuration when creating a volume

As a UI user, I want to be able to set snapshot/backup configurations while creating Longhorn volume.

We should able to add an advanced option while creating the volume, which includes:

Base image option
Frontend selection
Recurring snapshot/backup

@meldafrawi I tried add an advanced option while creating the volume, But it doesn't look very friendly.

Remove the blocker. Move this issue to the next release.

We're going to use https://github.com/longhorn/longhorn/issues/467 to address this issue.


materialQuantities missing on certain Revit Categories

The materialQuantities object is missing on the following Revit Categories:

Ducts (needs to be specified for the actual duct thickness)
Duct Insulation
Flex Ducts
Flex Pipes
Pipes
Railings
Ramps

I am looking into this atm. It appears that the method Autodesk.Revit.DB.Element.GetMaterialIds() malfunctions for these categories. Hence, the quantities are not added. I will further investigate the issue and propose a solution soon after.

Fixed in the 2.17 connector version
https://github.com/specklesystems/speckle-sharp/releases/tag/2.17.0%2Fall


Failing on Windows 7 with Meteor <IP_ADDRESS> -- Command failed: The system cannot find the path specified

demeteorizer version : 2.2.7
I just updated my meteor app to <IP_ADDRESS> on windows and am trying to demeteorizer it -- now I get the following error:
C:\Users\Steven McDowall\work\galaxy\rts\sources\RTViewer>demeteorizer -o c:\dep
loy\Galaxy\RTViewer
Input:  C:\Users\Steven McDowall\work\galaxy\rts\sources\RTViewer
Output: c:\deploy\Galaxy\RTViewer
Determining Meteor version...
Meteor version: <IP_ADDRESS>
Output folder exists, deleting...
Bundling Meteor App...
Demeteorization failed: Command failed: The system cannot find the path specifie
d.
Any ideas? Would be nice if it would print out the "path" it can't find...
Thanks!
P.S. The same app can be demeteorized just fine on my Mac with the same 2.2.7 version, so this looks like a Windows specific issue... ??
P.S.S.  It appears it's because I have a space in the Input name (output may do the same) -- looks like demeteorizer will "escape" the space even in Windows with a "\ " .. but Windows of course uses \ as a path delimiter .. hence it can't find the input directory (even though it's already in there) ..
Not sure of the best way to fix the bug though .. I implemented what maybe a hack with this code -- but it seems to work .. by simply not doing any escaping on Windows.. but I'm no windows expert so not sure the ramifications ..
var os           = require('os') ;
const modulesNotInRegistry = [
'aws-sdk-browser-builder',
'nw-pre-gyp-module-test',
'forge-nodejs-example'
];
/**

Escapes special characters out of the specified path.
@param {String} filePath The path to escape.
*/
var escapePath = function (filePath) {
if (!filePath || filePath.length === 0) return filePath;

// SJM - It doesn't look like we should do any escaping of the filepath if we are in Windows..
if ( os.platform().substring(0,3) !== 'win' ) {
filePath = filePath.replace(/ /g, '\ ');
filePath = filePath.replace(/&/g, '\&');
filePath = filePath.replace(/(/g, '\(');
filePath = filePath.replace(/)/g, '\)');
}
return filePath;
};

Looks like there are still some compatibility issues with Windows.
Thanks for the detailed report. :)

Try using the branch #path-escaping and see if that corrects the issue.

I'll give it shot tomorrow when I'm back at my "normal" Windows workstation ...

OK -- this is a bit embarrassing -- but how do I try out that branch?  Some npm install option or ??
Thanks

Install the module from this repo/branch:
$ npm install -g onmodulus/demeteorizer#path-escaping
:+1:

Ok!
Tried it on both Windows and Mac OSX and it appears to be working much better!

On Aug 7, 2015, at 10:26 AM, Matt Hernandez<EMAIL_ADDRESS>wrote:
Install the module from this repo/branch:
$ npm install -g onmodulus/demeteorizer#path-escaping
—
Reply to this email directly or view it on GitHub https://github.com/onmodulus/demeteorizer/issues/134#issuecomment-128714030.

The fix is live in<EMAIL_ADDRESS>Thanks for reporting this!


Fix create LB, Listener and Pool

@cuonglm  No. I jist removed some unneeded fields in create request payload.


Howto: Diff two objects and get the textual differences of its fields

Hi All,
Just came across this tool and can I say its awesome. Thank you for building it. Now I know this isn't an issue but I was unable to find anywhere to ask a question for this repo.
So if it's allowed here's my question.
I have two Objects representing a users "Project", which is made up of the following:
@Getter
@Setter
@Document(collection = "UserProjects")
public class Project {

    @JsonView({ProjectView.FullProjectView.class, ProjectView.FullProjectViewWithUserProfiles.class})
    @Id
    private String _id;

    private String blockId;

    private String userId;

    private String projectSlug;

    @NotBlank(message = "Project name is required")
    private String projectName;

    @NotBlank(message = "Project Body is required")
    private String projectBody;

    private String projectBodyPreview;

    private LinkedHashSet<CodeSnippet> codeSnippets;

    private String projectBodyPreviewPlain;

    private UserProfile projectCreator;

Now when a user updates / modifies the Project object I would like to be able to show a diff between whats changed and more importantly what fields changed.
Looking at the documentation this is what I'm looking for on a per field level:
        DiffRowGenerator generator = DiffRowGenerator.create()
                .showInlineDiffs(true)
                .mergeOriginalRevised(true)
                .inlineDiffByWord(true)
                .oldTag(f -> "~")      //introduce markdown style for strikethrough
                .newTag(f -> "**")     //introduce markdown style for bold
                .build();

        //compute the differences for two test texts.
        List<DiffRow> rows = new ArrayList<>();
                rows = (generator.generateDiffRows(
                Arrays.asList("This is a test senctence."),
                Arrays.asList("This is a test for diffutils.")));

And below might give an indication of what I'm hoping todo
  try {
            Class clazz = project1.getClass();
            Field[] fields = clazz.getDeclaredFields();
            for (Field field : fields) {
                field.setAccessible(true);
                Object o1 = field.get(project1);
                Object o2 = field.get(project2);
                if (o1 == null && o2 == null) {
                    continue;
                } else if (o1 == null && o2 != null) {
                    diffRows.add(new DiffRow(DiffRow.Tag.INSERT, field.getName(), "", o2.toString()));
                } else if (o1 != null && o2 == null) {
                    diffRows.add(new DiffRow(DiffRow.Tag.DELETE, field.getName(), "", o1.toString(), ""));
                } else if (!o1.equals(o2)) {
                    diffRows.add(new DiffRow(DiffRow.Tag.CHANGE, field.getName(), "", o1.toString(), o2.toString()));
                }
            }
        } catch (Exception ex) {
            ex.printStackTrace();
        }

Can someone point me in the right direction please?
Thanks again

So why do you use this library at all. You detect all the changes and now you only need to visualize those.

If your object only contains basic types or String types, then this is very easy, you can use reflection to get the values of all member variables of the object for comparison. But if your object contains other complex objects nested, it is not easy to implement, such as Address in Student.java, Info in Address, just like LinkedHashSet, UserProfile in your Project.java, you only Can deep clone your object, and then traverse each property for comparison

But that is what you want and what java-diff-utils should do for you, a recursive scan and check for object properties. Right? So somewhere this nesting should be processed.


soul-dashboard. Paging query does not work after click  [System Manage/Plugin/Batch Enable Or Disabled] button

Describe the bug
Paging query does not work after click  [System Manage/Plugin/Batch Enable Or Disabled] button
Environment

Soul version(s): [e.g. 2.2.1]

Steps to reproduce
Expected behavior

Debug logs

Click to expand
replace this line with your debug logs

ok, I will pr right away.

ok, I will pr right away.


Create an affiliation for people imported with no titles to enable organization mapping

@cmh2166 suggested:

Generic associated with (parent of employed by)? And question to Profiles about why they include people without affiliations?

A question regarding this behavior was sent to the #sul-cap-collab channel.

Can we get examples of people that this applies to and how many they are

4552 stanford people have no positions because they are affiliated with R001 or an unknown organization.
11 stanford people have no positions because they have no titles.

See attached.
no_positions.log

I had a chance to speak with Tina today and she said they are going to try and get to the R001 org code and "fix" those, which presumably means ensuring there is an actual organization in the list of orgs (perhaps creating new orgs that don't exist in the process) and then putting the new (or current) org codes in people's profile records instead of this R001 code.  Our problem is that its not likely to happen for our current workcycle.
So I suppose we could  (1) not include these people at all, (2) leave them unmapped to any organizational unit, or (3) map them to some department called "Unknown".
The unmapped or unknown position leaves us with the people and their research but makes the filtering by department/school potentially not complete (which seems like a reasonable tradeoff to me for now).
Another possibility is to look into the Directory service (https://uit.stanford.edu/developers/apis/person and https://uit.stanford.edu/node/25188), which should give us the actual organization affiliation, but I am not sure we have the development time to go down this path for now.


how should we handle ordered categoricals?

Similar to R's factors, Pandas has an ordered argument that indicates that the categories have an ordering. I'm not sure what happens when you have an ordered Categorical.

In the case of ordered categoricals do we ever expect to see new categories?


Backend

Contains all backend features necessary to reach the minimum viable product.

Closing this issue since I am changing the system for organizing stories into epics.


Paint Format / Inline Mode

Jodit Version:  3.2.xxxxx
Browser:  ALL
OS:  Windows
Paint format does not work in inline mode. See
https://xdsoft.net/jodit/play.html?preset=inline

Try in https://github.com/xdan/jodit/releases/tag/3.4.1


pull request for e2e test at 01/28/2017 09:26:14

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


Setup the Kanbanboard for JS Capstone

GitHub project link: https://github.com/VaheStepanyan100/javascript-capstone
We are two partners for this project

Hi Team,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉
Highlights

Good job setting up the board correctly.

Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Write new topic on user talk page if user has enabled structured discussion

If we are trying to created new section on user talk page where user has enabled structured discussion Wikimate unable to create new section.
Code:
$page = $wiki->getPage($userName); $page->setText("Text", 'new');

https://www.mediawiki.org/wiki/Structured_Discussions
Example: https://or.wikipedia.org/wiki/User_talk:Jnanaranjan_sahu
Here is a discussion I have started on the talk page:
https://www.mediawiki.org/wiki/Topic:Uq7swz65t02tjz29
It has an API also to post message.

That looks... complicated. ;)
Well, I am busy enough with other (non-Wikimate) projects already and don't need this myself, so I'm afraid I can't spare the time to research and develop support for this. If someone else submits a properly coded and documented PR for it, I may be able to take a look and review that later.

Thanks for the information.


why somepalce still use Object.assign, it cause an error in some browser

https://github.com/akiran/react-slick/blob/master/src/inner-slider.js#L26
https://github.com/akiran/react-slick/blob/master/src/mixins/helpers.js#L326

In which browser you are seeing issue ?
which version of slick are you using ?

latest version; IE9 and some android devices

You can add this polyfill to solve the problem.

We are already using transform-object-assign babel plugin to fix this
https://github.com/akiran/react-slick/blob/master/.babelrc#L6


Removing ByteStringer.wrap() around partial byte arrays.

The ByteString.copyFrom() turns out to be more efficient.  Removing the ByteStringer.wrap(byte[], int, int) and replacing its uses with BytString.copyFrom(byte[], int, int).

LGTM


service: Add native Backblaze B2 API support

Backblaze B2

ok,plz assign to me

Backblaze B2

I have a little question. To access b2, we need to authorize b2 to obtain a token with a 24-hour expiration time. Should we maintain the token, or should the user enter the token?

Should we maintain the token, or should the user enter the token?

Yes, we should maintain the token. Users only need to input their application key.

I can't get mut self in backend, how can I update the token?

I can't get mut self in backend, how can I update the token?

You can store token inside Arc<Mutex<Token>>, take gdrive as reference.

I can't get mut self in backend, how can I update the token?

You can store token inside Arc<Mutex<Token>>, take gdrive as reference.

I got it, i had a brain fade there 🤣

Add, thanks @hoslo!

However, I dont see B2 in the official docs anywhere. https://opendal.apache.org/docs/category/services

Sure, those documents are manually maintained. We're exploring methods to improve their upkeep through automation. Meanwhile, would you like to contribute the documentation for b2?


DTR restore storage flag

Fixing #9767
https://docs.docker.com/ee/admin/restore/restore-dtr/

Deploy preview for docsdocker ready!
Built with commit 12900e9d09d99a2a081b71433b536b73c3ef6009
https://deploy-preview-9786--docsdocker.netlify.com

Deploy preview for docsdocker ready!
Built with commit 9d82941e4659a591490ba6763f38488ec7af5426
https://deploy-preview-9786--docsdocker.netlify.com


fix(index): remove catch statement to allow rejection, always return promise

Fixes https://github.com/dyaa/node-ssl-checker/issues/9

finally reverted  the un-intentional change ;)

Thanks @wzr1337 :+1: