Make Deserializer public (again, sorry)

In my previous PR, I made the type public, but I forgot to give a path to interested crates. Sorry to open a second PR for so little :(

No worries :)

released as 0.4.1


Inconsistent behavior across charts

The posit connect chart specifies the following:
    {{- if eq .Values.strategy.type "RollingUpdate" }}
    rollingUpdate:
      maxUnavailable: {{ .Values.strategy.rollingUpdate.maxUnavailable }}
      maxSurge: {{ .Values.strategy.rollingUpdate.maxSurge }}
    {{- end }}

The PM chart just has:
  {{- with .Values.strategy }}
  strategy:
    {{- toYaml . | nindent 4 }}
  {{- end }}

It would be nice if the templating was consistent, as this tripped me up when working with the charts. I thought just specifying strategy.type: RollingUpdate was enough because it worked for the connect chart, but in the PM chart you also need to specify rollingUpdate: null under strategy.

Thanks for reporting @Almenon ! To be clear: do you think that the Connect chart's approach is preferable?

I don't have much of a preference, but if you want me to pick one as the 'best' I'll pick the PM chart as it is more flexible. But up to you :)


[PiranhaJS] Fix dependabot alert

Update serialize-javascript to 3.1.0

@mkr-plse Can we identify dependency issues before commit through a check?

Happy with the contents of the PR, but please change title to "[PiranhaJS] Upgrade serialize-javascript to 3.1.0" and then mention the dependabot alert in the description of the PR/commit, as otherwise the title is not descriptive of the change.
And, @s7rthak, not sure if there is a way to run the dependabot logic on PRs, but worth looking into that.


How to right click on the app on taskbar using winappdriver?

I want to verify app is present on the taskbar or not
Right click on the app and close

Please suggest on these two scenarios

Can anyone please help on this issue. Thank you

@anunay1 @alakshmi1030  @shankarkc @DHowett @aakilb - Can anyone help on this issue

kkch19 I suppose it is not possible for now.
Did you check is available in PageSource for Desktop sessions  https://github.com/microsoft/WinAppDriver/blob/master/Docs/FAQ.md#when-and-how-to-attach-to-an-existing-app-window?

The Taskbar is under the Desktop/Root element so can be accessed using the Root session.
var desktopCapabilities = new AppiumOptions();
desktopCapabilities.AddAdditionalCapability("app", "Root");
var Desktop = new WindowsDriver<WindowsElement>(new Uri("http://<IP_ADDRESS>:4723"), desktopCapabilities);
var taskbar = Desktop.FindElementByClassName("Shell_TrayWnd");

Next, navigate to the app icons area/pane and find the one that is yours. The app icons have names like:
<appName> - # running window[s]
The icons do not seem to have other normal properties so finding by name seems the only way.
//Find the appIconsPane
var appIconsPane = taskbar.FindElementByClassName("MSTaskListWClass");
//Find your app icon
//Example with Notepad++
var myAppIcon = appIconsPane.FindElementByName("Notepad++ - 1 running window");


Make mails in list keyboard accessible

Currently, you can't use the keyboard to select a mail from an overview list, for example inbox, archives, etc. (FYI, I'm experiencing this problem using VimFx on Firefox, though I imagine similar extensions in other browsers would have the same problem.)
I chose to put a role="button" attribute on the email subjects, and also on the timestamps because that seems a conventional place to link from too (see for example the clickable timestamps on Twitter or Facebook).

The role="button" attribute should be added on the time-element component.

I'm no longer using the application, but anyone willing to pick up this branch is free to do so.


Kerberos no longer working under 1.25

Issue Type: Bug
Authentication using Kerberos isn't working. It works under version 1.24 but not version 1.25. Just keep getting the prompt to run kinit, which isn't needed as a ticket is already in place.
Thanks!
Azure Data Studio version: azuredatastudio 1.25.0 (8c6bd8c857592c14afbb589a7d307baec1f5b5ed, 2020-12-05T06:43:11.244Z)
OS version: Darwin x64 18.7.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-6360U CPU @ 2.00GHz (4 x 2000)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 3

Memory (System)
8.00GB (0.03GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

azuredatastudio-postgresql
Mic
0.2.7

azdata-sanddance
msr
3.1.0

Duplicate of https://github.com/microsoft/azuredatastudio/issues/13751


Reducing memory footprint of one_hot for Large Vector Testing

Description
Using single element one hot location NDarray multiple times to ensure one_hot vector is single row only and not multi row.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Testing
MXNET_TEST_COUNT=1 nosetests --logging-level=DEBUG --verbose -s tests/nightly/test_large_vector.py:test_one_hot
/home/ubuntu/anaconda3/lib/python3.6/site-packages/h5py/__init__.py:36: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.
  from ._conv import register_converters as _register_converters
test_large_vector.test_one_hot ... ok

----------------------------------------------------------------------
Ran 1 test in 9.735s

OK

Currently running full suite of all tests in test_large_vector.py

@mxnet-label-bot add [pr-awaiting-review]

@apeforest @ChaiBapchya PR is ready for review

Actually, after checking test_large_array.py, I think this test is redundant. We can remove it from test_large_vector.


Fix for #6

Adjust error handling to log error and generated query for easier debugging
Adjust so exception is thrown when actual error happens, instead of relying on client's check for zero modified rows
Rewrite query generation to make sure nested objects are properly serialized and % is properly escaped.

@pandafox the implementation before is that we raise an error as well. We just changed it to return None because most of the developers that will use it is accustomed to returning Null when there is an error in the query (and we're too lazy to try catch..lol).
Do you think it is better to raise the error rather than to return None?

I believe exception is a better pratice because it allows more control on the user end to deal with specific errors that they want to handle. If the user wants to ignore the error, they can. And if they want to have a global exception reporting and logging so they don't need to handle it every time.


Jenkins nightly pychapel test should exercise pip/Pypi installer

Cray-internal Jenkins nightly pychapel test should exercise pip/Pypi installer
Now that Pychapel 0.1.18's pip/Pypi installer works (on Linux-64, at least- see #88), Chapel's nightly Jenkins tests should test and verify that it still works.

There's no more nightly pychapel


issues with generating bindings for large record

Since the issue #134 has been solved, I tried to implement a long record with the example I gave in #171. However, when I run the host program, I got this error:
Error: failed to convert function `hey` to given type

Caused by:
    0: type mismatch with parameters
    1: expected 1 types, found 4

This is my WIT file
hey: func(i: event) -> event

record event {
    a: string,
    b: string,
    c: string,
    d: string,
    e: string,
    f: string,
    g: string,
    h: string,
    i: string,
}

and this is part of my host program that instantiate a wasm module that implements the hey funciton and invoke this funciton
let module = Module::from_file(&engine, "target/wasm32-wasi/debug/guest.wasm")?;
let (import, _i) =
    import::Import::instantiate(&mut store, &module, &mut linker, |ctx| &mut ctx.data)?;
let info = import.hey(
    &mut store,
    import::EventParam {
        a: "a",
        b: "b",
        c: "c",
        d: "d",
        e: "e",
        f: "f",
        g: "g",
        h: "h",
        i: "i",
    },
)?;

Ah nevermind, I forgot to compile the guest program so that it has the updated record bindings.


Add blog post about forensic container checkpointing

This adds a blog article how to use forensic container checkpointing which was merged in Kubernetes v1.25.
https://github.com/kubernetes/enhancements/issues/2008

@sftim Thanks for the detailed feedback. I tried to change everything as you suggested.

Updated as suggested.

We usually publish articles on weekdays. How about 2022-10-31?

We usually publish articles on weekdays. How about 2022-10-31?

Sure. I just picked a random date in the future. No preference from my side.

Changed date to 2022-10-31 and added a sentence about pre-alpha status of the image format.

@sftim PTAL, I added a sentence that the security implications are not completely understood.

Applied your suggestions and tried to address your other comments.

At this point, I'd like to get another review from someone else. @adrianreber is there someone familiar with the checkpointing feature that could take a look over this?

At this point, I'd like to get another review from someone else. @adrianreber is there someone familiar with the checkpointing feature that could take a look over this?

@rst0git can you take a look. I guess you are most familiar with this topic.

At this point, I'd like to get another review from someone else. @adrianreber is there someone familiar with the checkpointing feature that could take a look over this?

@mikebrow was also involved in the KEP discussions. Any comment from your side?

(would be nice to publish this before v1.26 comes out)

@haircommander I did one change as suggested. Not sure what to do about your other three review comments.
@sftim as you heavily influenced the style and the tone of the article I would be happy for any further suggestions from your side about the three open discussion items.

:thought_balloon: is it worth mentioning a RuntimeClass for the container runtime with experimental checkpoint restore enabled?

RuntimeClass toggles between different OCI Runtimes underneath the CRI implementation (cri-o/containerd).

Can also be the same runtime with different settings (right?). Not a blocker for the article, just a thought.

RuntimeClass toggles between different OCI Runtimes underneath the CRI implementation (cri-o/containerd).

Can also be the same runtime with different settings (right?). Not a blocker for the article, just a thought.

yeah it could be! I am curious of cases where that'd be used :)

Please update the article with a tentative publication date: the 5th of December. Let's see if we can get it published on that day.

I think when reading the first sentence --
Forensic container checkpointing allows the creation of stateful copies of a running container without the container knowing that it is being checkpointed.
I have to look further down into the article to find this --
Forensic container checkpointing is based on [Checkpoint/Restore In Userspace](https://criu.org/) (CRIU).
which I think should be the first sentence in this article.
Not sure if this has been checked for technical accuracy but the rest of the article looks ok (without checking for technical accuracy myself).

Thanks @occase

@haircommander I removed --drop-infra-ctr=false from the article. The corresponding PR (https://github.com/cri-o/cri-o/pull/6379) is only blocked by the broken CI so far. Let me know if you are okay with removing your hold.
@sftim Release data updated
@occase Happy to do the change, but so far @sftim has been doing most stylistic changes, so let's see what he says.

/hold cancel
/lgtm
We might want to mention some of the alternatives (eg: whole-node snapshots, perhaps with the help of a specialized hypervisor, or even dedicated hardware). Not essential though.

I would make the change that @occase suggests, or something broadly like it.

Changed as suggested by @occase

Hello Prow my old friend.


Question on the Resample Allocator

Hi, I want to ask if the below is the correct implementation of the Resample Allocator Layer? In this case covmat = covariance_layer(Q) and rets = transform_layer(x)  are used to initialize the MultivariateNormal.
import torch
from deepdow.deepdow.layers import NumericalMarkowitz, Resample, CovarianceMatrix

batch_size = 2
num_assets = 5

transform_layer = torch.nn.Linear(5, 5)
allocate_layer = NumericalMarkowitz(n_assets=num_assets, max_weight=1)
covariance_layer = CovarianceMatrix(sqrt=False, shrinkage_strategy='diagonal')
gamma_sqrt = torch.nn.Parameter(torch.ones(1), requires_grad=True)
alpha = torch.nn.Parameter(torch.ones(1), requires_grad=True)

allocate_layer_rsample = Resample(allocate_layer)

Q = torch.rand((batch_size,num_assets,num_assets))
x = torch.rand((batch_size,num_assets))

covmat = covariance_layer(Q)   <--- initialize MultivariateNormal
rets = transform_layer(x)      <--- initialize MultivariateNormal
gamma_sqrt_all = torch.ones(len(x)) * gamma_sqrt
alpha_all = torch.ones(len(x)) * alpha

weights = allocate_layer_rsample(covmat, rets=rets, gamma=gamma_sqrt_all, alpha=alpha_all)
weights.shape # (2,5)

EDIT:
on another note, for the sampling part of the Resample Allocator,
https://github.com/jankrepl/deepdow/blob/eb3b02d0f5d9660035845105ffaa126a170dce6e/deepdow/layers/allocate.py#L335
might want to consider the reparameterization trick as well, just change to dist.rsample((n_draws,)). It allows for backprop through the random node and it is used in reinforcement learning's SAC as well. Although I am not sure about how it affects performance.

Hi! Thanks for the great question!!
Regarding the code example you wrote, yes, that is the intended usage of the Resample layer. The covmat and rets determine uniquely the Multivariate Normal distribution and each forward pass just samples from it multiple times and runs the underlying allocator.
Regarding the sample vs rsample method, I need to read up on this and I will get back to you ASAP. When I was implementing it I was assuming sample would not break the computational graph and one can backpropagate without any issues. When running tests and experiments there were never any problems. However, I might be wrong here.

I digged into it and you were absolutely right. The gradients were not able to flow through the sample operation. I was kind of surprised that loss.backward() goes through anyway without raising exceptions. However, the tensor.grad=None and a  gradient descent step seems to treat it as if the gradients were zero.
Thank you very much for pointing this out!


Subtitles and Slides sync option

@Trekky12 Hi! I am using the cli version of this app as back-end for my use case. I see there is an option to explicitly sync videos and background music, but there seems to be no such option to explicitly sync slides with their corresponding titles/subtitles. Is there a way I can ensure that if slide 1 runs for 5 seconds, then its corresponding title also run for 5 seconds?
Thanks for making such a useful app/repository!

Thank you for the kind message 😊
Actually the subtitles should always start at the end of the transition-in:
https://github.com/Trekky12/kburns-slideshow/blob/5883ab585ad08ec4ef020cb131d70a43cbc671ed/slideshow/SlideManager.py#L854-L855
and end on the end of the transition-out:
https://github.com/Trekky12/kburns-slideshow/blob/5883ab585ad08ec4ef020cb131d70a43cbc671ed/slideshow/SlideManager.py#L858-L859
With titles you mean the black overlay title like in the demo ("Demo Slideshow"), right?

At the moment it is indeed not possible to sync the titles duration to the slides duration. Do you want to sync all titles to the corresponding slide durations?

Hey @pk1130,
I've added a cli parameter --sync-titles-to-slides in the development branch. Is this what you need?

@pk1130 can this issue be closed?


:memo: Docs: (subsection) Jump diffusion

What is it and why is it useful in quantifying and modeling risk

Closing this for now as we should focus on more core documentation.


Synthesis failed for Google.Cloud.Logging.V2

Hello! Autosynth couldn't regenerate Google.Cloud.Logging.V2. :broken_heart:
Please investigate and fix this issue within 5 business days.  While it remains broken,
this library cannot be updated with changes to the Google.Cloud.Logging.V2 API, and the library grows
stale.
See https://github.com/googleapis/synthtool/blob/master/autosynth/TroubleShooting.md
for trouble shooting tips.
Here's the output from running synth.py:
2021-03-19 22:44:16,358 autosynth [INFO] > logs will be written to: /tmpfs/src/logs/Google.Cloud.Logging.V2
2021-03-19 22:44:16,940 autosynth [DEBUG] > Running: git config --global core.excludesfile /home/kbuilder/.autosynth-gitignore
2021-03-19 22:44:16,946 autosynth [DEBUG] > Running: git config user.name yoshi-automation
2021-03-19 22:44:16,953 autosynth [DEBUG] > Running: git config user.email<EMAIL_ADDRESS>2021-03-19 22:44:16,961 autosynth [DEBUG] > Running: git config push.default simple
2021-03-19 22:44:16,966 autosynth [DEBUG] > Running: git branch -f autosynth-Google.Cloud.Logging.V2
2021-03-19 22:44:16,971 autosynth [DEBUG] > Running: git checkout autosynth-Google.Cloud.Logging.V2
Switched to branch 'autosynth-Google.Cloud.Logging.V2'
2021-03-19 22:44:17,198 autosynth [DEBUG] > Running: git rev-parse --show-toplevel
2021-03-19 22:44:17,205 autosynth [DEBUG] > Running: git log -1 --pretty=%H
2021-03-19 22:44:17,210 autosynth [DEBUG] > Running: git remote get-url origin
2021-03-19 22:44:17,245 synthtool [ERROR] > Failed executing git checkout master:

error: Your local changes to the following files would be overwritten by checkout:
	google/cloud/dialogflow/v2/answer_record.proto
	google/cloud/dialogflow/v2/conversation.proto
	google/cloud/dialogflow/v2/conversation_profile.proto
	google/cloud/dialogflow/v2/participant.proto
Please commit your changes or stash them before you switch branches.
Aborting

Traceback (most recent call last):
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/tmpfs/src/github/synthtool/autosynth/synth.py", line 354, in <module>
    main()
  File "/tmpfs/src/github/synthtool/autosynth/synth.py", line 189, in main
    return _inner_main(temp_dir)
  File "/tmpfs/src/github/synthtool/autosynth/synth.py", line 312, in _inner_main
    git_source.enumerate_versions(sources, pathlib.Path(temp_dir))
  File "/tmpfs/src/github/synthtool/autosynth/git_source.py", line 202, in enumerate_versions
    source_versions = enumerate_versions_for_source(git_source, temp_dir)
  File "/tmpfs/src/github/synthtool/autosynth/git_source.py", line 166, in enumerate_versions_for_source
    local_repo_dir = str(synthtool_git.clone(remote))
  File "/tmpfs/src/github/synthtool/synthtool/sources/git.py", line 85, in clone
    shell.run(["git", "checkout", "master"], cwd=str(dest), check=True)
  File "/tmpfs/src/github/synthtool/synthtool/shell.py", line 39, in run
    raise exc
  File "/tmpfs/src/github/synthtool/synthtool/shell.py", line 33, in run
    encoding="utf-8",
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/subprocess.py", line 438, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['git', 'checkout', 'master']' returned non-zero exit status 1.

Google internal developers can see the full log here.

Autosynth passed, closing! :green_heart:


Signed URL generation is really slow

I'm migrating over from S3 and I was really surprised to see that signed url generation is extremely slow with this library. This must be a bug? I'm getting one of these for every signed url:
Sending HTTP get https://www.googleapis.com/storage/v1/b/REDACTED?
200
#<Hurley::Response GET https://www.googleapis.com/storage/v1/b/REDACTED == 200 (586 bytes) 217ms>
Success - #<Google::Apis::StorageV1::Bucket:REDACTED
 @cors_configurations=
  [#<Google::Apis::StorageV1::Bucket::CorsConfiguration:REDACTED
    @http_method=["PUT"],
    @max_age_seconds=3600,
    @origin=["*"],
    @response_header=["Content-Type", "Access-Control-Allow-Origin"]>],
 @etag="CAM=",
 @id="REDACTED",
 @kind="storage#bucket",
 @location="US",
 @metageneration="3",
 @name="REDACTED",
 @project_number="REDACTED",
 @self_link="https://www.googleapis.com/storage/v1/b/REDACTED",
 @storage_class="MULTI_REGIONAL",
 @time_created=Sun, 19 Mar 2017 15:55:07 +0000,
 @updated=Sun, 19 Mar 2017 16:22:25 +0000>

Is this expected?
This is my code:

  def bucket
    @storage ||= Google::Cloud::Storage.new
    @bucket ||= @storage.bucket(ENV.fetch('GOOGLE_CLOUD_STORAGE_BUCKET'))
  end

  def thumbnail_url
    bucket.signed_url(
      thumbnail_name,
      method: 'GET',
      expires: 300
    )
  end

Hi @AndrewVos, thanks for reporting this issue.
Have you tried Creating Signed URLs with gsutil? I am wondering how the response time would compare.

@quartzmo yeah I have and if I recall correctly there was some sort of request happening with that too. Strange.
Anyway, this is way faster: https://blog.oestrich.org/2016/01/signing-google-cloud-storage-urls/

Oh also another issue, if content_type isn't specified in PUT then the signature will not match.
Not sure if that is a bug or just lack of documentation.

Is this expected?

It depends on how the code you've shared is being used. If the bucket instance object is being created new each time, then yes it will make an API request for the Bucket data.

Oh also another issue, if content_type isn't specified in PUT then the signature will not match.
Not sure if that is a bug or just lack of documentation.

The GCS docs seem to state that pretty clearly.

@quartzmo Should we add Project#signed_url that accepts both bucket and path, similar to Bucket#signed_url and File#signed_url?

@blowmage Yes, I think that is a good idea.

if content_type isn't specified in PUT then the signature will not match.

@blowmage Does this need to be added to google-cloud-storage docs?

Does this need to be added to google-cloud-storage docs?

Up to you. I think the current docs are fine, but we have different opinions on the role of docs. :) If you think otherwise I will support any changes you think best.

Well you don't really expect http requests when you're newing and object. Maybe that's just me.
Is content_type a required parameter? If it isn't then it probably should be...

@blowmage even if the GCS docs do state that clearly it's not where I would be looking if this gem wasn't working for me. I had to search around and found the answer on stackoverflow. If the param is required the people wouldn't have this problem.
Also the problem with doing these requests when you new up the bucket is that in Rails you would have to somehow store a singleton which isn't very nice and is probably unexpected behaviour for most.

Well you don't really expect http requests when you're newing and object. Maybe that's just me.

Pretty much every object in Google Cloud has an associated API call. This is how we know information about the bucket, such as whether it exists.

Is content_type a required parameter? If it isn't then it probably should be...

The content_type argument is not required because there are URLs that can be generated that do not specify it. For example, a GET request usually does not specify a content type.
I did find one code example that was using PUT but did not specify a content_type, and I have updated the code example to include it.

Also the problem with doing these requests when you new up the bucket is that in Rails you would have to somehow store a singleton which isn't very nice and is probably unexpected behaviour for most.

You may want to reconsider that. You will likely benefit from memoizing a Google Cloud storage objects on the thread. Every time you call Google::Cloud::Storage.new API calls are made to verify your credentials and create an OAuth token. You may also have additional overhead due to establishing a TCP connection, TSL handshake, DNS lookups, etc.

Pretty much every object in Google Cloud has an associated API call. This is how we know information about the bucket, such as whether it exists.

Sure, but what I'm trying to get at here is that it seems to be a convention in Ruby to not do anything much other than setting ivars in initialize. Maybe that's just me, but I was 100% sure it was signed_url causing the request, because I don't expect calling new on something to be doing anything slow.
Regarding content_type maybe raising when it is actually required and isn't present depending on the method might be more user friendly? No real opinions on that :)

Is this issue resolved by #1362?

I don't know if this issue is completely resolved by #1362. It seems that what @AndrewVos is looking for is a way to sign urls completely independently from all the other functionality of google-cloud-storage. Even using googleauth's default credentials might be too much, since that also involves API calls to establish an OAuth token.
I suspect the only way to consider this issue resolved is create a separate signing gem that looks similar to his GoogleStorage class.
All that said, I think we can close this issue. Just not sure we can consider it resolved. Thoughts?

Yeah that's definitely what I was looking for @blowmage and I just ended up using some code from that link I pasted earlier.
I think this issue is resolved, but perhaps it might be useful to somehow explain in the documentation that the bucket class should be memoized? I can see people copying and pasting the example code in (which instantiates a bucket) and ending up with the belief that Google Cloud Storage requires a request to build a signed url. This almost turned me off from using GCS entirely, which would have been a shame!
Anyway, closing this because it's resolved for me personally. Thanks for your help!


fetch is impure

The fetch function (and I guess json and text, though it is less observable in that case) initiates an asynchronous action before even returning the Aff result.
Example program:
hello :: String
hello =
  let response = fetch "http://localhost:8080/index.html" defaultFetchOptions in
  "Hello world"

main :: forall e. Eff (console :: CONSOLE | e) Unit
main = log hello

This actually fetches the URL even though the Aff action was only let-bound within a pure function, and the Aff is never run.
This is because your FFI functions are missing a thunk, and should return Effs:
exports.fetchImpl = function (url) {
  return function (options) {
    return fetch(url, options);
  };
}

Should either be
exports.fetchImpl = function (url) {
  return function (options) {
    return function() {
      return fetch(url, options);
    }
  };
}

and add an Eff to the import, or use EffFn2

What ended up being annoying though is that the node-fetch people decided to make a class that wraps the actual error: https://github.com/bitinn/node-fetch/blob/e7c1ef88ede64c1a8fa9cfc5a2690d10c11225ce/src/fetch-error.js#L16
Maybe we need to wrap their API in turn, but they already do strip out a ton of information 😞

We fixed this a while back with Eff Promise right?

I think you're right.


Nostr remote signing

Description
Nostr remote signing NIP-46.
Docs:
https://github.com/nostr-protocol/nips/blob/master/46.md

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I'm delighted to take on the Nostr remote signing implementation, having worked with Go, JavaScript, TypeScript, Solidity, and Cairo. I've worked on a variety of blockchain and cryptographic protocols, giving me a solid foundation for implementing NIP-46.
How I plan on tackling this issue
First, extensively examine the NIP-46 documentation to grasp the connection protocol and message formats.
Implement the needed event types to sign requests and answers.
Establish secure communication routes between the signer and the requester.
Create appropriate error handling and timeout mechanisms for failed signature attempts.
Develop a rigorous testing suite to ensure reliable signing procedures.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
hello @ i'm an experienced frontend developer and a blockchain developer  i would love to work on this issue
Pleasee kindly assign :)

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I'm nik, i am a Core linux and Blockchain dev.
How I plan on tackling this issue
I would love to:
Build a remote signing service that stores private keys securely
Implement NIP-44 encryption for all client-signer messages
Set up relay routing with optional connection secrets
Add auth challenges for sensitive operations
Support NIP-05 for easy user onboarding
But i'm open for more context and guidance.
I dont think i would need more than 3 days at max to fix this

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
i have experience in blockchain previously as personal projects and OS, so hoping to make use of them here and mark my first odhack contribution

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I have experience with blockchain protocols and cryptographic signing methods, particularly within decentralized applications. My background includes implementing and integrating various Nostr NIPs, which equips me to understand and adapt NIP-46 for remote signing effectively.
How I plan on tackling this issue
To implement Nostr remote signing (NIP-46), I will begin by reviewing the official documentation to ensure a thorough understanding of the specifications. I will design the signing mechanism to facilitate secure off-chain signatures, focusing on user authentication and the integrity of signed messages. This will involve creating the necessary API endpoints to handle signing requests and responses, ensuring they comply with the NIP-46 requirements. Additionally, I'll implement error handling and logging for better debugging. Once developed, I will conduct comprehensive tests to validate the functionality and security of the remote signing process, ensuring a seamless user experience.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am a typescript dev. A new-comer here, willing and ready to contribute to contribute to solve the issue.

Can I start working on this?

Can I handle this task?

I'd be happy to do this.

Is this issue still available?

I want to work on this issue, please can I be assigned this

Hello @MSghais . Is this all about creating Nostr remote signing Hook? if so, my ETA is 3days. Thanks

Mind if I take this issue?

I'd love to work on this!

I'm a senior fullstack dev, assign me some of your tasks and I'm committed to finishing them by the end of the next few weeks.
I don't know nostr, but it's the time to discover it

May I take this issue on?

Is it okay if I tackle this?

I’d like to resolve this.

I’d love to work on this task.

I would like to work on this issue

I'd love to give this a go.


add api for updating room metadata

I - very naively - copied the updateParticipant functions and adapted them for an updateRoom api.
Right now this is untested and I'm marking the PR as a draft. Just wanted to give space for feedback early in case I'm going about it entirely wrong.

 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.lukasio seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

I think you should put the metadata variable as byte array so we can serialize whatever we want in it and define it in the protocol buffer messages.
You should also create a permission to allow users to edit the metadata.
I think you should also create a UpdateRoom we hook

Thanks for your feedback!

metadata variable as byte array
I thought it might be useful to follow the same approach for the room metadata as for the participants. Me personally, as a user of livekit, would expect both kinds of metadata to behave similarily also in terms of payload. But I'm of course happy to change that if people see that differently.

You should also create a permission to allow users to edit the metadata.
similar to before. updateParticipant is a server only api and I expected that the maintainers want to keep it that way for updateRoom

You should also create a UpdateRoom webhook
nice idea! I will try to see if I can find out how to do that.

Hey @lukasIO, thanks for your contributions.
Do you have a particular use case in mind with this feature? That may give me a bit more context on how the feature should be structured.
We use protocol buffers to generate most of these definitions, so you'd first have to modify the members in the protocol repo, before the correct types will be generated: https://github.com/livekit/protocol. I'm happy to propose an API design with a bit more information about various use cases folks have. I'll post in issue too.

closing in favor of https://github.com/livekit/livekit-server/pull/126


Remove nux=1

done part of https://github.com/Azure-Samples/active-directory-angularjs-singlepageapp/pull/43


New term request: abnormal cortical subventricular zone

Preferred term label
abnormal cortical subventricular zone

Synonyms
abnormal cortical SVZ

Textual definition
any structural anomaly of the region of the developing mammalian cortex that extends between the ventricular zone and the intermediate zone (IZ) that developed from the IZ

Any additional notes to clarify the meaning or use of the term. Please provide a PubMed ID or URL(s) for the source of this information.
Paper PMID:29033352 discusses goings-on in the SVZ

Suggested parent term
MP:0008457 abnormal cortical intermediate zone morphology

How is this different from MP:0004274 'abnormal embryonic/fetal subventricular zone morphology'?

From: Sue Bello <notifications<EMAIL_ADDRESS>Reply-To: obophenotype/mammalian-phenotype-ontology <reply<EMAIL_ADDRESS>Date: Monday, 19 March 2018 at 12:20
To: obophenotype/mammalian-phenotype-ontology <mammalian-phenotype-ontology<EMAIL_ADDRESS>Cc: Laurens Wilming <laurens.wilming<EMAIL_ADDRESS>Author <author<EMAIL_ADDRESS>Subject: Re: [obophenotype/mammalian-phenotype-ontology] New term request: abnormal cortical subventricular zone (#2696)
How is this different from MP:0004274 'abnormal embryonic/fetal subventricular zone morphology'?
Ah, no it isn’t! I searched the ontology for ‘ventricular’ and none of the subventricular terms come up… I frequently have issues with the search function, I must say. Often you search for a keyword and the desired term doesn’t appear, but then when you find the term some other way it turns out the keyword is right there! And for example searching for 'T cell’ you get a bunch of T…. cell false positives (decreased thyrotroph cell numberhttp://www.informatics.jax.org/vocab/mp_ontology/MP:0008338, decreased theca cell numberhttp://www.informatics.jax.org/vocab/mp_ontology/MP:0009370, increased Leydig cell tumor incidencehttp://www.informatics.jax.org/vocab/mp_ontology/MP:0009592) but not ‘abnormal T cell number’ or ‘abnormal T cell compartment’. :-)
Laurens
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/obophenotype/mammalian-phenotype-ontology/issues/2696#issuecomment-374294734, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AcE3CFLak0kfgcotd93rF9W_N0Rd3mV0ks5tf-jmgaJpZM4SquvI.

Dr Laurens Wilming
Alleles & Phenotypes Curator
Mouse Genome Informatics
The Jackson Laboratory
600 Main Street
Bar Harbor, ME 04609, USA
www.jax.org
The Jackson Laboratory: Leading the search for tomorrow's cures
The information in this email, including attachments, may be confidential and is intended solely for the addressee(s). If you believe you received this email by mistake, please notify the sender by return email as soon as possible.


Use pip to install Python scripts in platforms

Switching to setuptools required restructuring the platforms tree. Functionality remains the same, including new stubs where the scripts used to be to retain the ability to run the scripts from inside the OPAE SDK source tree.
The platforms database is now stored inside the platmgr Python package instead of in share since Python strongly encourages storing all package data inside the packages tree.
The deprecated CMake installer script that platforms used to run is removed.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 65.537%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
13173

Relevant Lines:
20100

💛  - Coveralls


Anchor-169 add bank_account_type in customer fields and SEP-9 fields

PR Checklist
PR Structure

[ ] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[ ] This PR's title starts with name of package that is most changed in the PR, ex.
paymentservice.stellar, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[ ] This PR adds tests for the most critical parts of the new functionality or fixes.

What
Adds bank_account_type to the list of SEP-9 fields, with initial supported values of checking or savings. Some jurisdictions have banking systems that require that the account type be specified in addition to the account number.
Note that bank_account_type does not indicate the format of bank_account_number, and should not be used to validate bank_account_number.
If an anchor needs to be able to validate an account identifier, it should use other SEP-9 fields added specifically for the format they're looking to validate, such as cbu_number or clabe_number. These fields often contain pieces of information other than the user's account number with their bank.
For example, CBU numbers contain identifiers for the bank, the bank branch, the type of account, and the account number itself. Instead of trying to decompose CBU numbers and passing each piece via the bank_account_number, bank_number, bank_branch_number, and other SEP-9 fields, it is much easier for businesses operating in those jurisdictions to accept account identifiers in the formats that are common in those jurisdictions.
Why
N/A
Known limitations
N/A

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Reference Server Preview is available here:https://anchor-ref-pr748.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr748.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr748.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr748.previews.kube001.services.stellar-ops.com/


[AI Generated] Enhancements: Sandboxed Environment, Error Handling, and Documentation Updates

[AI Generated] ### Enhancements Implemented:

Sandboxed Environment:

Created a Dockerfile to set up the agent in a Docker container.
Created a docker-compose.yml to manage the Docker container and associated services.

Error Handling Enhancements:

Improved the create_pull_request function to provide more detailed feedback and handle different error scenarios.
Enhanced the sync_repo function to perform actual syncing operations and provide meaningful feedback.

Documentation Updates:

Updated the README.md with comprehensive setup instructions, including prerequisites and steps to build and run the Docker container.
Added examples of common usage scenarios, including running the agent and creating a pull request.
Included a troubleshooting section to help users resolve common issues.

These enhancements aim to improve the safety, reliability, and usability of the autonomous agent. Please review and provide feedback.

Rejecting since the requested changes are not compatible with the existing dev_tools.py


chore!: merge namespace package into shares package

Second part of the merge

Another step would be moving Blob, Share, and Namespace to the root, leaving the business(parsing, splitting, etc.) logic behind(in current or new pkg).

Another step would be moving Blob, Share, and Namespace to the root, leaving the business(parsing, splitting, etc.) logic behind(in current or new pkg).

I like this. I would even go to put the all the types in a package with a separate go.mod so that it can be imported from all repos without having any logic dependencies that might be undesirable in some repos

I would even go to put the all the types in a package with a separate go.mod so that it can be imported from all repos without having any logic dependencies that might be undesirable in some repos

Why would the logic be undesirable? I don't usually like having a types only package. It's counter to object oriented languages. You shouldn't separate types from their function

Why would the logic be undesirable? I don't usually like having a types only package. It's counter to object oriented languages. You shouldn't separate types from their function

That depends on the logic. If it requires some specific packages that we might not want to import in some projects, then we can separate that.
My motivation for having a separate types project is to be able to import in core, app, node, etc, without having to worrying about a dependency hell. This would allow defining the types in a single place instead of having 2 or 3 definitions just because we can't import the package containing them.

I don't usually like having a types only package. It's counter to object oriented languages

That's a bold statement because this is how most of the Golang std library is designed. The low-level types and interfaces are separated in a sovereign(kek) pkg while specialized logic/implementations are in sub or other pkgs. Examples:

crypto
net
io
sql

The low-level types and interfaces are separated in a sovereign(kek) pkg while specialized logic/implementations are in sub or other pkgs. Examples:

Interfaces with multiple implementations in sub packages is different from a single implementation and splitting the raw type from the business logic that uses it

Interfaces with multiple implementations in sub packages is different from a single implementation and splitting the raw type from the business logic that uses it

+100. Given we don't have multiple implementations of namespace, shares, or blobs, I'm in favor of defining the types and methods on those types in the same package.

Just to be clear, I am in favour of that as long as we don't have any weird dependencies. Especially, having dependencies on app for example, core, cosmos-sdk or... in the logic of the types

Interfaces with multiple implementations in sub packages is different from a single implementation and splitting the raw type from the business logic that uses it

Its both the interfaces with implementations as well as core types and specialized logic

Given we don't have multiple implementations of namespace, shares, or blobs, I'm in favor of defining the types and methods on those types in the same package.

I am not proposing splitting methods from types, but separating higher level businnes logic like splitting data into shares from the types:

Clarity and focus. People navigating the repo to use the types don't need to see share splitting, etc. The types package has its single responsibility to hold those types and low level tooling around those, like versioning, stringification, etc
Avoids temptation to access private fields
Ensures the API and methods of the types are complete. The separation overtime forces us to extend basic methods and tools around those types.
Avoids pulling unrelated code into binaries when you only need types

Anyway, I honestly dont wanna block you on this, but would like to know why coupling these makes sense to you. It's not a hill I am willing to die on the time will show us if there are issues with the current approach, like it showed for when we tried keeping every type in a its own pkg.

@Wondertan, I'm not totally opposed to what you're saying. I just feel like this is more an avenue to bike shed then something that brings tangible benefits so I just don't want to allocate too much time to it. I think when you're dealing with blobs or shares it's because you're trying to construct a square or read parts of a square thus I feel that keeping them together makes sense. There all part of the same logical realm. Blob -> Shares and Shares -> Blobs.
FYI: I do think some of the structs, like the Builder and maybe even the SparseShareSplitter should be made private.

There will also be some logic separated from the share package, namely the "compact shares" which is it's own encoding protocol i.e. [][]bytes -> Blob


eixsts “expected item after attributes" when use "#[derive(Debug)];" in rustc 1.5.1

eixsts “expected item after attributes" when use "#[derive(Debug)];" in rustc 1.5.1

Please provide the context in which the error occurred and the full error message.

Please provide the context in which the error occurred and the full error message.

OK，this problem was resolved


Encountering Value Error When Running the Provided Colab Example

Issue Description
I encountered an issue when using the code from the sample Colab file. The code is as follows:
model = whisper.load_model("small.en-tdrz")
result = whisper.transcribe(model, "demo_video.mp4", verbose=True, condition_on_previous_text=False)
# time segments are a bit more stable without prev_text conditioning as it wasn't yet fine-tuned that way

ValueError: tuple.index(x): x not in tuple

Also, I tried the model with MP3 and WAV files but got the same error!

I just tried the Colab notebook as well and run into this issue. Will look into what's up (likely has something to do with this PR https://github.com/akashmjn/tinydiarize/pull/11), thanks for pointing it out.


Revert "Fix error conversion for WorkflowExecutionAlreadyStartedError (#4838)"

What changed?
This reverts commit 48a157e1af87e8302b5d8e492480c15d89a9f277.

Why?
We have some internal retries checking the old error code.

How did you test it?

Potential risks

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 0183665e-b198-49df-a75d-07caaaca9bdc

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
46 unchanged lines in 9 files lost coverage.
Overall coverage increased (+0.006%) to 57.255%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

service/history/handler.go
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

client/history/client.go
2
38.1%

client/history/metricClient.go
2
45.3%

common/task/weightedRoundRobinTaskScheduler.go
2
89.64%

service/history/handler.go
2
47.17%

service/history/task/transfer_standby_task_executor.go
2
85.98%

common/persistence/dataManagerInterfaces.go
3
58.66%

service/frontend/workflowHandler.go
4
59.98%

service/history/historyEngine.go
9
69.49%

service/history/task/task_util.go
20
70.57%

Totals

Change from base Build 01834744-8abf-4cf1-a1c7-28aa67113249:
0.006%

Covered Lines:
85086

Relevant Lines:
148608

💛  - Coveralls


Add Log field to Context

This is adds Log field to Context, allowing the Controller to log messages using the application logger.
This field is ensured to never be nil. If there is no any application logger set then the default logger which writes to stdout is used.

Coverage increased (+0.2%) to 76.242% when pulling 1041f555edc6b268c9df8fa9025978f44120e41e on dev into e06e0ed5ff970b3206c87526483101fb42c33f90 on master.


Host configuration step missing in documentation to setup Meshery locally

Description
When ran Meshery locally the hosts are not configured properly due to which error shows up as
Adapter was not configured due to an error
Expected Behaviour

Either we should have a script added to configure the etc/hosts file that could be ran with the make command

or Alternatively

Add description for how to configure i.e. steps should be added in the docs telling to add the <IP_ADDRESS> mesherylocal.layer5.io line in the file etc/hosts.

Screenshots/Logs

Present Behaviour:

Error Appears something Like this
Expected changes:
After the configuration manually or by script etc/hosts file should contain line <IP_ADDRESS> mesherylocal.layer5.io
Environment:

Meshery Version: Any
Kubernetes Version: Any
Host OS: Any
Browser: Any

We’ll stay away from automatically editing the user’s hosts file as it’s a little too invasive and individuals contributing to the project should be aware of networking considerations when working on Meshery.
We might change the default configuration away from mesherylocal.layer5.io, though, to just localhost.

Not a bug. Removing bug label.

@Ayush-Khandelwal-007 great alternative suggestion. Yes, minimally, we should add instructions in the contributing guide about this. In fact, they are right here - https://docs.meshery.io/project/contributing-ui#running-meshery-from-ide

I'll propose a third solution: change from mesherylocal.layer5.io to localhost as the default location for each adapter.

@leecalcote That would be grate!


export-distro sometimes encounters 0MQ message body error

🐞 Bug Report
Affected Services
The issue is located in: the communication between export-distro and core-data via 0MQ
Is this a regression?
Yes, it doesn't happen in Delhi release
Description and Minimal Reproduction
Running EdgeX v1.0.0 with multiple Device Services on lower power kit (Dell3000, UPSquared), and create multiple export registrations, and wait for 5-15 mins until the error log printed in export-distro.  All export-distro goroutines are terminated when this issue occurs. In the error log, 'events events' bit looks wrong.
🔥 Exception or Error
level=ERROR ts=2019-07-01T14:35:12.820403389Z app=edgex-export-distro source=registrations.go:350 msg="exit msg: found more than 2 incoming messages (1 is no topic, 2 is topic and message), but found: 3"
When we print with a bit more info we see:
level=ERROR ts=2019-07-08T18:40:04.596019465Z app=edgex-export-distro source=registrations.go:350 msg="exit msg: found more than 2 incoming messages (1 is no topic, 2 is topic and message), but found: 3, message content: [events events {"Checksum":"","CorrelationID":"e8c3960b-afb3-42b5-910f-4f20d6e36267","Payload":"eyJjb3JyZWxhdGlvbi1pZCI6ImU4YzM5NjBiLWFmYjMtNDJiNS05MTBmLTRmMjBkNmUzNjI2NyIsImlkIjoiMWIwYzlhNzItMjRhNC00YTFiLTgyYTgtOTgxZDUxNDVjMTg5IiwiZGV2aWNlIjoiUmFuZG9tLUludGVnZXItRGV2aWNlIiwib3JpZ2luIjoxNTYyNjExMjA0NTYwNDgwODUxLCJyZWFkaW5ncyI6W3siaWQiOiI5OThlN2MxNy0xMTYyLTRlMmYtYjBmYy0wNjJmMzdkYTJmM2MiLCJvcmlnaW4iOjE1NjI2MTEyMDQ1NDI1OTA4MDcsImRldmljZSI6IlJhbmRvbS1JbnRlZ2VyLURldmljZSIsIm5hbWUiOiJSYW5kb21WYWx1ZV9JbnQxNiIsInZhbHVlIjoiLTQ5NTkifV19","ContentType":"application/json"}]"
level=INFO ts=2019-07-08T18:40:04.596015754Z app=edgex-export-distro source=registrations.go:250 msg="Terminating registration goroutine"
level=INFO ts=2019-07-08T18:40:04.597181997Z app=edgex-export-distro source=registrations.go:250 msg="Terminating registration goroutine"
level=INFO ts=2019-07-08T18:40:04.597900919Z app=edgex-export-distro source=registrations.go:250 msg="Terminating registration goroutine"
🌍  Your Environment
Deployment Environment:
lower power kit, such as Dell3000, UPSquared
EdgeX Version:
Edinburgh Release v1.0.0
Anything else relevant?
The log is printed by https://github.com/edgexfoundry/go-mod-messaging/blob/18e14ad62fb232c3fddceea415da29d0b56d5906/internal/pkg/zeromq/client.go#L172 , and the message content printing is added by us

FWIW that error message is coming from the following location in the go-mod-messaging module
https://github.com/edgexfoundry/go-mod-messaging/blob/8a7864e25347004b93e696f26b74d0c6a56b78e3/internal/pkg/zeromq/client.go#L166
@rsdmike @lenny-intel for visibility

Based on the logs above we are getting the events topic twice and then the message envelope.
events events {"Checksum....
we should be getting:
events {"Checksum....
So wondering if the previous message envelope got dropped.

@TomFlem , can you check your core data logs for this error?
`the length of the sent messages does not match the expected length'

@lenny-intel I got the same issue
core-data log
level=INFO ts=2019-07-10T05:39:17.7960776Z app=edgex-core-data source=event.go:239 msg="Putting event on message queue"
level=INFO ts=2019-07-10T05:39:17.7962221Z app=edgex-core-data source=event.go:257 msg="Event Published on message queue. Topic: events, Correlation-id: 5c7631b0-20af-49b5-b63c-4358f9671f1c "
level=INFO ts=2019-07-10T05:39:21.1586094Z app=edgex-core-data source=event.go:239 msg="Putting event on message queue"
level=INFO ts=2019-07-10T05:39:21.158918Z app=edgex-core-data source=event.go:257 msg="Event Published on message queue. Topic: events, Correlation-id: 281eb742-a43c-4e65-8f90-d645e0e031b4 "
level=INFO ts=2019-07-10T05:39:21.1679273Z app=edgex-core-data source=event.go:239 msg="Putting event on message queue"
level=INFO ts=2019-07-10T05:39:21.1686831Z app=edgex-core-data source=event.go:239 msg="Putting event on message queue"
level=INFO ts=2019-07-10T05:39:21.1694699Z app=edgex-core-data source=event.go:257 msg="Event Published on message queue. Topic: events, Correlation-id: 7057b211-4c96-4fc2-968c-e60f8099e786 "
level=INFO ts=2019-07-10T05:39:21.1739622Z app=edgex-core-data source=event.go:257 msg="Event Published on message queue. Topic: events, Correlation-id: 219f57e8-5c37-48c1-a36f-255c7a142989 "
level=INFO ts=2019-07-10T05:39:21.1815768Z app=edgex-core-data source=event.go:239 msg="Putting event on message queue"
level=INFO ts=2019-07-10T05:39:21.1817464Z app=edgex-core-data source=event.go:257 msg="Event Published on message queue. Topic: events, Correlation-id: 4f1d4929-6548-4431-b99d-bab2aecd15ad "
level=INFO ts=2019-07-10T05:39:26.7243752Z app=edgex-core-data source=event.go:239 msg="Putting event on message queue"
level=INFO ts=2019-07-10T05:39:26.7249153Z app=edgex-core-data source=event.go:257 msg="Event Published on message queue. Topic: events, Correlation-id: a8a2f505-043b-4e63-b15d-10a50302a77f "

export-distro log
level=INFO ts=2019-07-10T05:39:06.7335397Z app=edgex-export-distro source=httpsender.go:67 correlation-id=9ed25ed0-66e3-40f6-8719-8682c14c297e duration=3.58ms msg="Response: 200 OK"
level=INFO ts=2019-07-10T05:39:06.7336146Z app=edgex-export-distro source=httpsender.go:73 msg="Sent data: 7B226964223A2264363238666266652D613531322D346438322D613663642D616230653065643464643161222C22646576696365223A2252616E646F6D2D426F6F6C65616E2D446576696365222C226F726967696E223A313536323733373134363732313136303430302C2272656164696E6773223A5B7B226964223A2231373336636431382D306435652D343439372D626666622D316236363639333539333331222C226F726967696E223A313536323733373134363731333731383530302C22646576696365223A2252616E646F6D2D426F6F6C65616E2D446576696365222C226E616D65223A2252616E646F6D56616C75655F426F6F6C222C2276616C7565223A2266616C7365227D5D7D"
level=INFO ts=2019-07-10T05:39:16.7271274Z app=edgex-export-distro source=httpsender.go:67 correlation-id=6761ec32-103c-4c2c-8c92-050687f0874c duration=12.7865ms msg="Response: 200 OK"
level=INFO ts=2019-07-10T05:39:16.7273089Z app=edgex-export-distro source=httpsender.go:73 msg="Sent data: 7B226964223A2265616163633737642D633138322D346366362D613862632D343739336335346665623733222C22646576696365223A2252616E646F6D2D426F6F6C65616E2D446576696365222C226F726967696E223A313536323733373135363639363632353930302C2272656164696E6773223A5B7B226964223A2264613138346661312D636230312D346531612D623936362D626366316163363965316536222C226F726967696E223A313536323733373135363638373738333030302C22646576696365223A2252616E646F6D2D426F6F6C65616E2D446576696365222C226E616D65223A2252616E646F6D56616C75655F426F6F6C222C2276616C7565223A2274727565227D5D7D"
level=ERROR ts=2019-07-10T05:39:21.1821154Z app=edgex-export-distro source=registrations.go:346 msg="exit msg: found more than 2 incoming messages (1 is no topic, 2 is topic and message), but found: 3"
level=INFO ts=2019-07-10T05:39:21.1822993Z app=edgex-export-distro source=registrations.go:246 msg="Terminating registration goroutine"
level=INFO ts=2019-07-10T05:39:21.1826086Z app=edgex-export-distro source=registrations.go:246 msg="Terminating registration goroutine"
level=INFO ts=2019-07-10T05:39:21.1826169Z app=edgex-export-distro source=registrations.go:246 msg="Terminating registration goroutine"

@TomFlem , can you check your core data logs for this error?
Unable to send message for event: the length of the sent messages does not match the expected length

No we don't see this error.

Thanks @weichou1229. This is great information which confirms this issue is not just on low power devices. I will have one of our devs who uses a MAC attempt to recreate.

@rsdmike was able to recreate the issue on his MAC Book. I was not able to recreate it on my Linux box which ran for 2hrs.

I have now reproduced this issue on my Linux box running https://github.com/edgexfoundry/developer-scripts/blob/master/compose-files/docker-compose-edinburgh-no-secty-1.0.0.yml
I left it running over night.

I built latest images for core-data and export-distro from master (with Trevor's race condition fix) and still got the issue. This time it occurred fairly quickly, with approx 15mins.

Fix was included in v1.0.1 images


⚠ Bofrost.lu has degraded performance

In d37376b, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1926 ms

Resolved: Bofrost.lu performance has improved in a9b364c after 20 minutes.


Improve Time Series labelling navigation

Is your feature request related to a problem? Please describe.
Navigating time series (moving forward) is pretty hard and frustrating. I need to move my mouse over the bottom window and move it slowly. With a long time series it's unusable.
Describe the solution you'd like
It looks like scroll and/or hotkeys can ease the work, e.g. arrows or <,> or h,l (vim style)
Describe alternatives you've considered
Additional context

This would be very useful. 👍  for performance with longer time series.

Any updates on this? It would be great to have easier navigation.

@alexandrnikitin unfortunately there are no updates :-(

+1 for this feature, scrolling through preview is very annoying :/


Register Azure Event Hubs as Pub/Sub

https://github.com/dapr/components-contrib/pull/242

Post 0.5.0


Avoid trees to close to buildings and footways

Places like zoos, theme parks or cementories are usually covered with a lot of trees. Most areas just add a nature=wood to charackterize this land cover. Unfortunatly this seems to result in a pretty dense filling with trees, which touches buildings but also the ways like here at the Zoo Rostock

Maybe you could add a test, if a tree comes to close to buildings or streets / footways? Yes sometimes this objects are covered by a tree, but usually not that much?

Related issue: #49


Kerbalism has misordered versions in CKAN and other version issues

CKAN version 1.25.3
KSP version 1.4.5
Operating System: Windows 10 1803
Mod: Kerbalism
Current Mod Maintainer: KSP forum user N70 and others
Source: https://github.com/steamp0rt/Kerbalism/
Download: https://spacedock.info/mod/1774/Kerbalism/
CKAN metadata:
several .ckan in a directory:
https://github.com/KSP-CKAN/CKAN-meta/tree/master/Kerbalism/
Issue: Kerbalism has misordered versions in CKAN and other version issues
Other issues include a CKAN download marked as being for KSP 1.4.5 is actually for KSP 1.3.1
Description:
Saw this post in the KSP topic for Kerbalism about a player running KSP 1.4.5 getting a KSP 1.3.1 version of Kerbalism as the default from CKAN.
https://forum.kerbalspaceprogram.com/index.php?/topic/172400-131145-kerbalism-v190/&page=35&tab=comments#comment-3458441
I took a look at Kerbalism in CKAN and with KSP compatibility set to KSP 1.4 and 1.3, saw this list of versions:
BP-1.4.3          KSP 1.3.0 - 1.3.1
BP-1.4.2          KSP 1.3.0 - 1.3.1
BP-<IP_ADDRESS>       KSP 1.3.0 - 1.3.1
BP-<IP_ADDRESS>       KSP 1.3.0 - 1.3.1
<IP_ADDRESS>             KSP 1.4.0 - 1.4.5
<IP_ADDRESS>             KSP 1.4.0 - 1.4.5
<IP_ADDRESS>             KSP 1.4.0 - 1.4.3
<IP_ADDRESS>             KSP 1.4.0 - 1.4.3
1.6.0                KSP 1.4.0 - 1.4.3
1.5.1                KSP 1.4.0 - 1.4.3
1.5.0                KSP 1.4.0 - 1.4.3
....
Checking on Kerbalism's GitHut and Spacedock pages, I see Kerbalism offered downloads for both KSP 1.3.x and 1.4.x versions of its recent releases (see links for GitHub and Spacedock above).  The most recent is <IP_ADDRESS> for KSP 1.4.5 and BP-<IP_ADDRESS> for KSP 1.3.1
I obtained the .zip files for Kerbalism from both CKAN and GitHub directly.
For CKAN's "BP-1.4.3  KSP 1.3.0 - 1.3.1", download was AC8B14B6-Kerbalism-BP-1.4.3.zip.  Kerbalism.version file attached as AC8B14B6-Kerbalism-BP-1.4.3.zip--Kerbalism.version.
For CKAN's "<IP_ADDRESS>   KSP 1.4.0 - 1.4.5", download was 2B6BA28E-Kerbalism-<IP_ADDRESS>.zip.  Kerbalism.version file attached as 2B6BA28E-Kerbalism-<IP_ADDRESS>.zip--Kerbalism.version.
Both of these .version files claim the install is for KSP 1.3.1.
GitHut has download Kerbalism-1.9.0-1.3.1.zip
Kerbal.version file attached as Kerbalism-1.9.0-1.3.1.zip--Kerbalism.version.
GitHut also has download Kerbalism-1.9.0-1.4.5.zip.
Kerbal.version file attached as Kerbalism-1.9.0-1.4.5.zip--Kerbalism.version.
The .version files claim they are for KSP 1.3.1 and 1.4.5 respectively.
Sizes of Kerbalism.dll from respective downloads:
AC8B14B6-Kerbalism-BP-1.4.3.zip--Kerbalism.version     292,352
2B6BA28E-Kerbalism-<IP_ADDRESS>.zip--Kerbalism.version        349,696
Kerbalism-1.9.0-1.3.1.zip                                                 349,696
Kerbalism-1.9.0-1.4.5.zip                                                 350,208
It appears the CKAN download for KSP 1.4.5, Kerbalism's <IP_ADDRESS>, is the KSP 1.3.1 version instead.
Zip containing the 4 Kerbalism.version files attached.
20180926a-Kerbalism.version.zip

I have heard that it is problematic to have Spacedock offer up versions of a mod compiled for different KSP versions.
Along with other measures to resolve these issues, I wonder if adopting a new Kerbalism version numbering scheme could help (along with appropriate use of epoch numbers).  I got the idea from Kopernicus's version scheme.
Versions 1.4.5.build for KSP 1.4.5
Versions 1.3.1.build for KSP 1.3.1
New build X comes out, compile version 1.4.5.X for KSP 1.4.5 and 1.3.1.X for KSP 1.3.1.
I wonder if with proper .version files, CKAN receiving the information from Spacedock could automatically keep things straight.
Don't know if this could be made to work, as I don't know the details of the protocol between Spacedock and CKAN and what CKAN does, besides it extracting the .version file and using it.

The .version file for the supposedly 1.3.1 backport says:
  "URL": "http://ksp-avc.cybutek.net/version.php?id=559",

... which in turn says:
{"NAME":"Kerbalism","URL":"http://ksp-avc.cybutek.net/version.php?id=559","DOWNLOAD":"https://spacedock.info/mod/1749/Kerbalism","CHANGE_LOG_URL":"https://spacedock.info/mod/1749/Kerbalism","VERSION":{"MAJOR":1,"MINOR":9,"PATCH":0,"BUILD":0},"KSP_VERSION":{"MAJOR":1,"MINOR":4,"PATCH":4},"KSP_VERSION_MIN":{"MAJOR":1,"MINOR":4,"PATCH":0},"KSP_VERSION_MAX":{"MAJOR":1,"MINOR":4,"PATCH":5}}

So that's where it's getting 1.4 compatibility from. Updating the online .version file pointed to by URL allows mod authors to extend or change the game version compatibility info without requiring users to download a new copy of the mod (note that KSP-AVC also works this way). That URL field should point to an online .version file that's specific to the backport series, but it's currently shared with the 1.4 series.

So Am I right in saying we should just have the 1.4.x versions on the current Spacedock and also start a new Spacedock Kerbalism-BP that has just the 1.3.1 Backport in it ?

tbh would be good if there was a way Spacedock, AVC and CKAN could support Backports with same version numbers.

I'm not the expert here, but I think you could do backports with the scheme I laid out in my reply to the initial post in one mod profile on both GitHub and Spacedock.  The backport and the current version have to have 2 different version numbers because they are different.  (Near 2 decades of use of Debian's apt including backports.)  You make those version numbers both relate to their difference, the KSP version number they are compiled for, and their similarity, the code release they share (obviously with condition code based on that KSP version number).
Say the next build of Kerbalism is called 191, even if there are no changes from the current, just to fix this version problem.  Then you compile
Kerbalism <IP_ADDRESS> for KSP 1.4.5
Kerbalism <IP_ADDRESS> for KSP 1.3.1
Those go on GitHub and Spacedock (which both need the version numbers in their download .zip filenames).  On CKAN, I think a properly crafted .netkan on getting the info from Spacedock would take their Kerbalism.version files and push out
Kerbalism 1:<IP_ADDRESS> for KSP 1.4.0 to 1.4.9
Kerbalism 1:<IP_ADDRESS> for KSP 1.3.0 to 1.3.1
The epoch numbers ("1:") are also used in Debian.  It places them as more recent than all the previous epoch releases.
That way, on CKAN, if it's set to have KSP 1.3 as compatible, it gets Kerbalism 1:<IP_ADDRESS>.
If it's set to have KSP 1.4 as compatible, even if it also has KSP 1.3 as compatible, it gets Kerbalism 1:<IP_ADDRESS>.
Next Kerbalism build is 192.  Put <IP_ADDRESS> and <IP_ADDRESS> in the respective .version files and onto Spacedock.  Spacedock tells CKAN.  Via the .netkan's on CKAN it now offers up 1:<IP_ADDRESS> and 1:<IP_ADDRESS> to CKAN users.
And everyone gets the right version.

That scheme would mess with the CI dev builds, probably best to have the Backports separate.
Kerbalisms versioning uses Major.Minor.Patch.Build

I think you can still use that build system.
Think of what KSP uses.
2018 Jul 26 Thu		KSP <IP_ADDRESS>3
2018 Jun 21 Thu		KSP <IP_ADDRESS>5
2018 Apr 27 Fri		KSP <IP_ADDRESS>2
2018 Mar 28 Wed		KSP <IP_ADDRESS>0
2018 Mar 13 Tue		KSP <IP_ADDRESS>9
2018 Mar 06 Tue		KSP <IP_ADDRESS>7
2017 Nov 15 Wed		KSP <IP_ADDRESS>1
2017 May 25 Thu		KSP <IP_ADDRESS>4
2016 Dec 06 Tue		KSP <IP_ADDRESS>2		Unity 5.4.0p4
2016 Nov 01 Tue		KSP <IP_ADDRESS>4
2016 Oct 11 Tue		KSP <IP_ADDRESS>6
2016 Jun 21 Tue		KSP <IP_ADDRESS>9
2016 Apr 30 Sat		KSP <IP_ADDRESS>0
2016 Apr 29 Fri		KSP <IP_ADDRESS>0
2016 Apr 19 Tue		KSP <IP_ADDRESS>0		Unity 5 & 64-bit !!!
Note the big jump in build numbers between each release.  The "missing" numbers were the development builds.

You can either put them all on GitHub, flagging as pre-release.  And only push to Spacedock (and thus) when it's a general release build.
You can special number the general release builds, say all builds ending in '0' are general release.
So for development, you have:
192
193
194
195
196
197
198
199
201
202
203
210
That 210 is the general release build, with the non-zero ending showing it as such.

Or you can do what sarbian does with MechJeb.  Keeps a separate repository for dev builds.  He even has it as a repository you can add to CKAN so you can use CKAN to install development MechJeb.  (Have to go into CKAN settings and add the MechJeb dev Metadata Repository by clicking on "New" and selecting it.)
And the development versions have numbers like:
<IP_ADDRESS>-803
<IP_ADDRESS>-802
<IP_ADDRESS>-801
....
with one of them eventually pushed out as the general release when appropriate.
sarbian sets up the development as separate.  Allows people to use it as a different manual or CKAN install.

So, you could have the next Kerbalisms to fix the version numbers be:
1:<IP_ADDRESS>
1:<IP_ADDRESS>
then in a separate dev build, have
1:<IP_ADDRESS>-01
1:<IP_ADDRESS>-02
etc and 1:<IP_ADDRESS>-xx for KSP 1.3.1.  When you get a good version for release, say -07,
1:<IP_ADDRESS>-07  on the dev track becomes 1:<IP_ADDRESS> on the main release track
or some system like that.
I think you need to keep the backport and the current KSP release together, else you will have a major port to do on new KSP versions.  This method or some others have minor porting just to push out general releases.
Again, I think these will work.  Others will have to fill in the details of implementing this.

personally I don't like the idea of merging the Major.Minor.Patch into a Build section. Also our BP port is handled automatically with CI. Not a big deal to upload the BP build to a separate Spacedock entry.
But all being said it is N70 who has the say in what happens.

Would be better if Spacedock AVC and CKAN had provision for updates to backports rather than treating backports as old releases.

That's a major feature and it may not be the right way to do things, as it would complicate KSP-AVC, Spacedock, and CKAN.  And backports should be able to be done with appropriate version numbers (and properly crafted .version files) of the mod releases without any changes to the 3 of them.  That's why I outlined a few ways above.
I also did that because of the consequences of doing it in a different way, like separate mods for Kerbalism and Kerbalism-backports, which aren't necessarily understood until it's taken through a major KSP release.    sarbian separates MechJeb into main release and development versions and that may be the better way to split, if you feel you have to split.  But with the right system for version numbers, it should be possible to handle development, main release, and backports all together.
Backports are a recent phenomenon (last 10 to 15 years) and an extension that occurs when more than one version of the major system (Debian or KSP major release) is in use.  How Debian uses them now has evolved into this from a slightly different method back around 8 years ago.  Debian apt really didn't change, just how to tell it about the existence and priority of backports.   The standard package info (inside the software package, the .deb file) on which Debian release, the package version number, and its versioned dependencies is all the info Debian apt needs to pick the right version to install.
Overall, Debian has more knobs and whistles than is needed for Spacedock and CKAN.  But the ideas around it can help figure things out for Spacedock and CKAN.

This issue still is catching some users.  Like this one on the KSP forums who's CKAN gave him Kerbalism BP-1.4.3 instead of 2.1.2.
https://forum.kerbalspaceprogram.com/index.php?/topic/172400-literally-every-ksp-version-since-13-kerbalism-v212/&page=50&tab=comments#comment-3535160
Currently the list of Kerbalism versions in CKAN looks like this.
BP-1.4.3     KSP 1.3.0 - 1.3.1
BP-1.4.2     KSP 1.3.0 - 1.3.1
BP-<IP_ADDRESS>   KSP 1.3.0 - 1.3.1
BP-<IP_ADDRESS>   KSP 1.3.0 - 1.3.1
2.1.2        KSP 1.3.1 - 1.6.99
2.1.1        KSP 1.3.1 - 1.6.99
<IP_ADDRESS>      KSP 1.3.1 - 1.5.9
<IP_ADDRESS>      KSP 1.3.1 - 1.5.1
<IP_ADDRESS>      KSP 1.3.1 - 1.5.9
and so on.

The BP-* versions were de-indexed in KSP-CKAN/CKAN-meta#1411.
Kerbalism since 2.1.1 seems to have released one version with broad support rather than individual backports. Is this issue resolved?

I'll confirm in the next few days.  If the BP-* versions were de-indexed and things appear as they do for you, that should be good.


ailab_OmniGen - Failed to import OmniGen. Please check if the code was downloaded correctly.

Error Message:

ailab_OmniGen - Failed to import OmniGen. Please check if the code was downloaded correctly.

ComfyUI Error Report
Error Details

Node ID: 14
Node Type: ailab_OmniGen
Exception Type: RuntimeError
Exception Message: Failed to import OmniGen. Please check if the code was downloaded correctly.

Stack Trace
  File "/Users/user.xyz/pinokio/api/comfy.git/app/execution.py", line 289, in execute
    obj = class_def()

  File "/Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-OmniGen/ailab_OmniGen.py", line 57, in __init__
    raise RuntimeError("Failed to import OmniGen. Please check if the code was downloaded correctly.")

System Information

ComfyUI Version: v0.2.7-28-g9a0a5d3
Arguments: main.py
OS: posix
Python Version: 3.10.15 | packaged by conda-forge | (main, Oct 16 2024, 01:24:20) [Clang 17.0.6 ]
Embedded Python: false
PyTorch Version: 2.3.1

Devices

Name: mps

Type: mps
VRAM Total:<PHONE_NUMBER>8
VRAM Free:<PHONE_NUMBER>2
Torch VRAM Total:<PHONE_NUMBER>8
Torch VRAM Free:<PHONE_NUMBER>2

Logs
2024-11-18T14:14:34.102159 - [START] Security scan2024-11-18T14:14:34.102187 -
2024-11-18T14:14:37.925725 - [DONE] Security scan2024-11-18T14:14:37.925756 -
2024-11-18T14:14:38.459849 - ## ComfyUI-Manager: installing dependencies done.2024-11-18T14:14:38.459924 -
2024-11-18T14:14:38.459954 - ** ComfyUI startup time:2024-11-18T14:14:38.459977 -  2024-11-18T14:14:38.460003 - 2024-11-18 14:14:38.4599362024-11-18T14:14:38.460024 -
2024-11-18T14:14:38.460091 - ** Platform:2024-11-18T14:14:38.460113 -  2024-11-18T14:14:38.460139 - Darwin2024-11-18T14:14:38.460160 -
2024-11-18T14:14:38.460183 - ** Python version:2024-11-18T14:14:38.460205 -  2024-11-18T14:14:38.460225 - 3.10.15 | packaged by conda-forge | (main, Oct 16 2024, 01:24:20) [Clang 17.0.6 ]2024-11-18T14:14:38.460251 -
2024-11-18T14:14:38.460277 - ** Python executable:2024-11-18T14:14:38.460300 -  2024-11-18T14:14:38.460324 - /Users/user.xyz/pinokio/api/comfy.git/app/env/bin/python2024-11-18T14:14:38.460347 -
2024-11-18T14:14:38.460366 - ** ComfyUI Path:2024-11-18T14:14:38.460384 -  2024-11-18T14:14:38.460407 - /Users/user.xyz/pinokio/api/comfy.git/app2024-11-18T14:14:38.460427 -
2024-11-18T14:14:38.460835 - ** Log path:2024-11-18T14:14:38.460870 -  2024-11-18T14:14:38.460897 - /Users/user.xyz/pinokio/api/comfy.git/app/comfyui.log2024-11-18T14:14:38.460920 -
2024-11-18T14:14:38.475990 -
Prestartup times for custom nodes:2024-11-18T14:14:38.476031 -
2024-11-18T14:14:38.476065 -    4.4 seconds:2024-11-18T14:14:38.476089 -  2024-11-18T14:14:38.476112 - /Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-Manager2024-11-18T14:14:38.476132 -
2024-11-18T14:14:38.476153 -
2024-11-18T14:14:43.790648 - Total VRAM 32768 MB, total RAM 32768 MB
2024-11-18T14:14:43.790789 - pytorch version: 2.3.1
2024-11-18T14:14:43.790973 - Set vram state to: SHARED
2024-11-18T14:14:43.791028 - Device: mps
2024-11-18T14:14:49.687656 - Using sub quadratic optimization for cross attention, if you have memory or speed issues try using: --use-split-cross-attention
2024-11-18T14:14:56.853609 - [Prompt Server] web root: /Users/user.xyz/pinokio/api/comfy.git/app/web
2024-11-18T14:15:01.537371 - ### Loading: ComfyUI-Manager (V2.51.9)2024-11-18T14:15:01.537440 -
2024-11-18T14:15:01.942172 - ### ComfyUI Revision: 2836 [9a0a5d32] | Released on '2024-11-18'2024-11-18T14:15:01.942249 -
2024-11-18T14:15:01.970738 -
Import times for custom nodes:
2024-11-18T14:15:01.970902 -    0.0 seconds: /Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/websocket_image_save.py
2024-11-18T14:15:01.970957 -    0.0 seconds: /Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-OmniGen
2024-11-18T14:15:01.971000 -    0.4 seconds: /Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-Manager
2024-11-18T14:15:01.971050 -
2024-11-18T14:15:01.976674 - Starting server

2024-11-18T14:15:01.977034 - To see the GUI go to: http://<IP_ADDRESS>:8188
2024-11-18T14:15:02.062145 - [ComfyUI-Manager] default cache updated: https://raw.githubusercontent.com/ltdrdata/ComfyUI-Manager/main/alter-list.json2024-11-18T14:15:02.062217 -
2024-11-18T14:15:02.072397 - [ComfyUI-Manager] default cache updated: https://raw.githubusercontent.com/ltdrdata/ComfyUI-Manager/main/model-list.json2024-11-18T14:15:02.072447 -
2024-11-18T14:15:02.123095 - [ComfyUI-Manager] default cache updated: https://raw.githubusercontent.com/ltdrdata/ComfyUI-Manager/main/github-stats.json2024-11-18T14:15:02.123163 -
2024-11-18T14:15:02.152080 - [ComfyUI-Manager] default cache updated: https://raw.githubusercontent.com/ltdrdata/ComfyUI-Manager/main/extension-node-map.json2024-11-18T14:15:02.152131 -
2024-11-18T14:15:02.173098 - [ComfyUI-Manager] default cache updated: https://raw.githubusercontent.com/ltdrdata/ComfyUI-Manager/main/custom-node-list.json2024-11-18T14:15:02.173145 -
2024-11-18T14:15:03.802836 - FETCH DATA from: /Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-Manager/extension-node-map.json2024-11-18T14:15:03.802872 - 2024-11-18T14:15:03.809587 -  [DONE]2024-11-18T14:15:03.809638 -
2024-11-18T14:18:01.212819 - got prompt
2024-11-18T14:18:01.352941 - Downloading OmniGen code from GitHub...2024-11-18T14:18:01.353016 -
2024-11-18T14:18:01.552943 - Downloaded model.py2024-11-18T14:18:01.553004 -
2024-11-18T14:18:01.802608 - Downloaded pipeline.py2024-11-18T14:18:01.802770 -
2024-11-18T14:18:02.014096 - Downloaded processor.py2024-11-18T14:18:02.014302 -
2024-11-18T14:18:02.315353 - Downloaded scheduler.py2024-11-18T14:18:02.315590 -
2024-11-18T14:18:02.524638 - Downloaded transformer.py2024-11-18T14:18:02.524686 -
2024-11-18T14:18:02.737360 - Downloaded utils.py2024-11-18T14:18:02.737467 -
2024-11-18T14:18:03.032962 - Downloaded __init__.py2024-11-18T14:18:03.033068 -
2024-11-18T14:18:03.033145 - OmniGen code setup completed2024-11-18T14:18:03.033198 -
2024-11-18T14:18:03.033825 - OmniGen models verified successfully2024-11-18T14:18:03.033916 -
2024-11-18T14:18:03.048685 - Error importing OmniGen: No module named 'diffusers'2024-11-18T14:18:03.048782 -
2024-11-18T14:18:03.051331 - !!! Exception during processing !!! Failed to import OmniGen. Please check if the code was downloaded correctly.
2024-11-18T14:18:03.064999 - Traceback (most recent call last):
  File "/Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-OmniGen/ailab_OmniGen.py", line 53, in __init__
    from OmniGen import OmniGenPipeline
  File "/Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-OmniGen/OmniGen/__init__.py", line 1, in <module>
    from .model import OmniGen
  File "/Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-OmniGen/OmniGen/model.py", line 9, in <module>
    from diffusers.loaders import PeftAdapterMixin
ModuleNotFoundError: No module named 'diffusers'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/user.xyz/pinokio/api/comfy.git/app/execution.py", line 289, in execute
    obj = class_def()
  File "/Users/user.xyz/pinokio/api/comfy.git/app/custom_nodes/ComfyUI-OmniGen/ailab_OmniGen.py", line 57, in __init__
    raise RuntimeError("Failed to import OmniGen. Please check if the code was downloaded correctly.")
RuntimeError: Failed to import OmniGen. Please check if the code was downloaded correctly.

2024-11-18T14:18:03.065620 - Prompt executed in 1.85 seconds

Attached Workflow
Please make sure that workflow does not contain any sensitive information such as API keys or passwords.
{"last_node_id":16,"last_link_id":20,"nodes":[{"id":10,"type":"PreviewImage","pos":[460,928],"size":[553.608642578125,826.3672485351562],"flags":{},"order":4,"mode":0,"inputs":[{"name":"images","type":"IMAGE","link":15,"label":"images"}],"outputs":[],"properties":{"Node name for S&R":"PreviewImage"},"widgets_values":[]},{"id":3,"type":"PreviewImage","pos":[460,50],"size":[553.608642578125,826.3672485351562],"flags":{},"order":5,"mode":0,"inputs":[{"name":"images","type":"IMAGE","link":13,"label":"images"}],"outputs":[],"properties":{"Node name for S&R":"PreviewImage"},"widgets_values":[]},{"id":13,"type":"ailab_OmniGen","pos":[1070,50],"size":[400,428],"flags":{},"order":6,"mode":0,"inputs":[{"name":"image_1","type":"IMAGE","link":17,"shape":7,"label":"image_1"},{"name":"image_2","type":"IMAGE","link":18,"shape":7,"label":"image_2"},{"name":"image_3","type":"IMAGE","link":null,"shape":7,"label":"image_3"}],"outputs":[{"name":"IMAGE","type":"IMAGE","links":[16],"slot_index":0,"label":"IMAGE"}],"properties":{"Node name for S&R":"ailab_OmniGen"},"widgets_values":["2 people at the coffee shop (image_1, image_2)","","Auto","Balanced",3.5,1.8,50,true,false,1024,512,344924858632789,"randomize",1024]},{"id":9,"type":"PreviewImage","pos":[1560,50],"size":[1037.9891357421875,808.0861206054688],"flags":{},"order":7,"mode":0,"inputs":[{"name":"images","type":"IMAGE","link":16,"label":"images"}],"outputs":[],"properties":{"Node name for S&R":"PreviewImage"},"widgets_values":[]},{"id":16,"type":"LoadImage","pos":[-500,830],"size":[320,310],"flags":{},"order":0,"mode":0,"inputs":[],"outputs":[{"name":"IMAGE","type":"IMAGE","links":[19],"slot_index":0},{"name":"MASK","type":"MASK","links":null}],"properties":{"Node name for S&R":"LoadImage"},"widgets_values":["me_3.jpeg","image"]},{"id":15,"type":"LoadImage","pos":[-490,290],"size":[320,310],"flags":{},"order":1,"mode":0,"inputs":[],"outputs":[{"name":"IMAGE","type":"IMAGE","links":[20],"slot_index":0},{"name":"MASK","type":"MASK","links":null}],"properties":{"Node name for S&R":"LoadImage"},"widgets_values":["trump-fail.jpg","image"]},{"id":12,"type":"ailab_OmniGen","pos":[-50,280],"size":[400,428],"flags":{},"order":3,"mode":0,"inputs":[{"name":"image_1","type":"IMAGE","link":20,"shape":7,"label":"image_1"},{"name":"image_2","type":"IMAGE","link":null,"shape":7,"label":"image_2"},{"name":"image_3","type":"IMAGE","link":null,"shape":7,"label":"image_3"}],"outputs":[{"name":"IMAGE","type":"IMAGE","links":[13,17],"slot_index":0,"label":"IMAGE"}],"properties":{"Node name for S&R":"ailab_OmniGen"},"widgets_values":["None","","Auto","Balanced",3.5,1.8,50,true,false,512,768,619694633692645,"randomize",1024]},{"id":14,"type":"ailab_OmniGen","pos":[-50,820],"size":[400,428],"flags":{},"order":2,"mode":0,"inputs":[{"name":"image_1","type":"IMAGE","link":19,"shape":7,"label":"image_1"},{"name":"image_2","type":"IMAGE","link":null,"shape":7,"label":"image_2"},{"name":"image_3","type":"IMAGE","link":null,"shape":7,"label":"image_3"}],"outputs":[{"name":"IMAGE","type":"IMAGE","links":[15,18],"slot_index":0,"label":"IMAGE"}],"properties":{"Node name for S&R":"ailab_OmniGen"},"widgets_values":["None","","Auto","Balanced",3.5,1.8,50,true,false,512,768,1016326586691859,"randomize",1024]}],"links":[[13,12,0,3,0,"IMAGE"],[15,14,0,10,0,"IMAGE"],[16,13,0,9,0,"IMAGE"],[17,12,0,13,0,"IMAGE"],[18,14,0,13,1,"IMAGE"],[19,16,0,14,0,"IMAGE"],[20,15,0,12,0,"IMAGE"]],"groups":[],"config":{},"extra":{"ds":{"scale":0.6115909044841462,"offset":[1073.4208934950116,84.25099433680789]}},"version":0.4}

Additional Context

Fresh installed the latest Pinokio Version
Fresh installed ComfyUI Version
Followed the OmniGen install guide
Run Process - Auto Install gets triggered
Error appears.

@1038lab what can I do? I don't see where my failure is.

python3 -m pip show peft
Name: peft
Version: 0.13.2
Summary: Parameter-Efficient Fine-Tuning (PEFT)
Home-page: https://github.com/huggingface/peft
Author: The HuggingFace team
Author-email<EMAIL_ADDRESS>License: Apache
Location: /Users/user.xyz/Library/Python/3.10/lib/python/site-packages
Requires: accelerate, huggingface-hub, numpy, packaging, psutil, pyyaml, safetensors, torch, tqdm, transformers

python3 -m pip show diffusers
Name: diffusers
Version: 0.30.3
Summary: State-of-the-art diffusion in PyTorch and JAX.
Home-page: https://github.com/huggingface/diffusers
Author: The Hugging Face team (past and future) with the help of all our contributors (https://github.com/huggingface/diffusers/graphs/contributors)
Author-email<EMAIL_ADDRESS>License: Apache 2.0 License
Location: /Users/user.xyz/Library/Python/3.10/lib/python/site-packages
Requires: filelock, huggingface-hub, importlib-metadata, numpy, Pillow, regex, requests, safetensors

......\python_embeded\python3 -m pip install -r ./requirements.txt
seems all good :/

Why douse ModuleNotFoundError: No module named 'diffusers' fail .. maybe because of the python/site-packages?

I am getting the same thing when using a fresh install + Manager + this custom_node and nothing else. Seems requirements are missing.
I tried manually installing diffusers, which resolved the above error, but then I got this:
024-11-24T03:59:55.957417 - Error importing OmniGen: No module named 'timm'2024-11-24T03:59:55.957417 -
2024-11-24T03:59:55.969365 - !!! Exception during processing !!! Failed to import OmniGen. Please check if the code was downloaded correctly.

Then I installed timm and got this:
No module named 'peft'

Then I installed peft and everything worked!
To validate, I confirmed the following files in this custom node invokes the above dependencies:
model.py
from diffusers.loaders import PeftAdapterMixin
from timm.models.vision_transformer import PatchEmbed, Attention, Mlp

pipeline.py
from peft import LoraConfig, PeftModel

@1038lab when convenient, I would recommend please adding diffusers, timm, peft to the requirements.txt to fix this issue and I suspect this one here as well: https://github.com/1038lab/ComfyUI-OmniGen/issues/26
These are the versions that are working on my fresh install in case you'd like to know what versions:
diffusers>=0.31.0
peft>=0.13.2
timm>=1.0.11

Getting this same error with a fresh install from inside of comfyui. Hope it can get fixed soon.


%{_libexecprefix} different on openSUSE and Fedora

The openstack/rpm-packaging project got recently some lint failures (using spec-cleaner) like:
-%dir %{_prefix}/lib/monasca
-%{_prefix}/lib/monasca/agent
+%dir %{_libexecdir}/monasca
+%{_libexecdir}/monasca/agent

On openSUSE Tumbleweed, I get:
$ rpmspec --eval '%{_libexecdir}'
/usr/lib

But according to Fedoras doc, it is:
%{_prefix}            /usr
%{_exec_prefix}       %{_prefix}
%{_libdir}            %{_exec_prefix}/%{_lib}
%{_libexecdir}        %{_exec_prefix}/libexec

This is correct behaviour.
If you install stuff to /usr/lib on Fedora then you screwed up, they don't allow /usr/lib.

And actually it seems the fedora installs the pyton stuff to /usr/lib, but some to libexec.

Solution to fix this would be to detect if _libexecdir on the spec-cleaner side evals to the /usr/lib prior the replacements.

Added an option to change this behaviour as needed.


Use Anserini from within an eclipse project

I have my own Maven project and I built an inverted index for my dataset using Lucene V8.0 ... I can't perform query expansion though in Lucene. I wanted to use Anserini to load my index and perform the search with query expansion, but I found no document that guides me on how to do this. May you please help? I don't want to use Anserini externally as I have further processing on the results returned from the search before producing the output.
An example of how to load an index using anserini (in java) would be mostly appreciated. Also how to search and perform query expansion (ex:RM3)

Unfortunately, Anserini is not designed to work with "generic" Lucene indexes, since it expects the fields to be named a certain way, etc.
I suppose you can build a Lucene index "outside" of Anserini and just make sure the fields are properly named, etc., but we have no experience with this...


week 4 mapAPI

added map API to page

Michaela and Ihsan - want to take a first look here and then hand off to Kaveh and I for final LGTM?


First build fails when importing library built with vue-cli in another Vue project

Version
4.3.1
Reproduction link
https://github.com/some1else/buggy-vue-lib/
Environment info
buggy-vue-lib/example:

  System:
    OS: macOS Mojave 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
  Binaries:
    Node: 10.14.1 - /usr/local/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 81.0.4044.129
    Edge: Not Found
    Firefox: 73.0.1
    Safari: 12.1.2
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0
    @vue/babel-plugin-transform-vue-jsx:  1.1.2
    @vue/babel-preset-app:  4.3.1
    @vue/babel-preset-jsx:  1.1.2
    @vue/babel-sugar-functional-vue:  1.1.2
    @vue/babel-sugar-inject-h:  1.1.2
    @vue/babel-sugar-v-model:  1.1.2
    @vue/babel-sugar-v-on:  1.1.2
    @vue/cli-overlay:  4.3.1
    @vue/cli-plugin-babel: ~4.3.0 => 4.3.1
    @vue/cli-plugin-eslint: ~4.3.0 => 4.3.1
    @vue/cli-plugin-router:  4.3.1
    @vue/cli-plugin-vuex:  4.3.1
    @vue/cli-service: ~4.3.0 => 4.3.1
    @vue/cli-shared-utils:  4.3.1
    @vue/component-compiler-utils:  3.1.2
    @vue/preload-webpack-plugin:  1.1.1
    @vue/web-component-wrapper:  1.2.0
    buggy-vue-lib: link:../ => 0.1.0
    eslint-plugin-vue: ^6.2.2 => 6.2.2
    vue: ^2.6.11 => 2.6.11
    vue-eslint-parser:  7.0.0
    vue-hot-reload-api:  2.3.4
    vue-loader:  15.9.2
    vue-style-loader:  4.1.2
    vue-template-compiler: ^2.6.11 => 2.6.11
    vue-template-es2015-compiler:  1.9.1
  npmGlobalPackages:
    @vue/cli: Not Found

Steps to reproduce
/tmp/buggy-vue-lib $ yarn install && yarn build
/tmp/buggy-vue-lib $ cd example && yarn install
/tmp/buggy-vue-lib/example $ yarn build # fails
/tmp/buggy-vue-lib/example $ yarn build # succeeds

What is expected?
The built library is expected to work the first time around.
What is actually happening?
ESLint loader fails to interpret either umd or commonjs builds on the first try:
$ vue-cli-service build

⠴  Building for production...

 ERROR  Failed to compile with 1 errors                                                                       4:39:01 PM

 error  in ../dist/buggyvuelib.umd.js

Module Error (from ./node_modules/thread-loader/dist/cjs.js):

/private/tmp/buggy-vue-lib/dist/buggyvuelib.umd.js
    4:42  error  'define' is not defined                                                                                no-undef
    5:3   error  'define' is not defined                                                                                no-undef

...

✖ 15 problems (15 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

 @ ./src/main.js 7:0-40 8:8-19
 @ multi ./src/main.js

 ERROR  Build failed with errors.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Both the library and the example project were created with vue create, using the default (Babel & ESLint) settings.
In similar issues, I noted suggestions to specify NODE_ENV=production and omit source-maps from the production build, which did not resolve the issue (as seen in the repro).
I verified that the same issue occurs when using the npm link or a published npm module.

https://cli.vuejs.org/guide/troubleshooting.html#symbolic-links-in-node-modules
Can't reproduce with a published npm module.


Update GoodPractice tutorial

Replace GoodPractice references to Mind Tools due to merge of companies.

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

@goodpracticeAdmin : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@goodpracticeAdmin  we have updated the Goodpractce Toolkit app as per your comments please provide your feedback
#please-close


feat - 2.0 alert support

Second attempt at creating a PR for this branch as I think the last one got broken as I force-pushed my subsequent changes 🤞

Hi @jan-molak - I've been testing this code locally with my application and it seems like I am hitting up against the same problem that I originally encountered with [https://github.com/jan-molak/serenity-js/issues/65](issue #65), so I think that the error handling that was added to the 1.x photographer might need to be migrated to version 2.0 as well. Shall I have a go at this?

Hmmm...Latest build is failing with NoSuchAlertError: no such alert
@serenity-js/protractor: (node:8720) UnhandledPromiseRejectionWarning: NoSuchAlertError: no such alert
@serenity-js/protractor:   (Session info: headless chrome=78.0.3904.108)
@serenity-js/protractor:   (Driver info: chromedriver=77.0.3865.40 (f484704e052e0b556f8030b65b953dce96503217-refs/branch-heads/3865@{#442}),platform=Linux 4.15.0-1028-gcp x86_64)
@serenity-js/protractor:     at Object.checkLegacyResponse (/home/travis/build/jan-molak/serenity-js/node_modules/selenium-webdriver/lib/error.js:546:15)
@serenity-js/protractor:     at parseHttpResponse (/home/travis/build/jan-molak/serenity-js/node_modules/selenium-webdriver/lib/http.js:509:13)
@serenity-js/protractor:     at doSend.then.response (/home/travis/build/jan-molak/serenity-js/node_modules/selenium-webdriver/lib/http.js:441:30)
@serenity-js/protractor:     at <anonymous>
@serenity-js/protractor:     at process._tickCallback (internal/process/next_tick.js:189:7)
@serenity-js/protractor: (node:8720) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 3)

And then later on other specs are failing with UnexpectedAlertOpenError: unexpected alert open: {Alert text : Press OK or Cancel}
Browser
@serenity-js/protractor:        returns no entries if the console log is empty:
@serenity-js/protractor:      UnexpectedAlertOpenError: unexpected alert open: {Alert text : Press OK or Cancel}
@serenity-js/protractor:   (Session info: headless chrome=78.0.3904.108)

So I'm a but stumped really and need some help please @jan-molak. Also I see this error when I try and run the protractor tests locally:
><EMAIL_ADDRESS>test /Users/nick/dev/git-personal/serenity-js/packages/protractor
> nyc --report-dir ../../target/coverage/protractor protractor ./spec/protractor.conf.js

[09:25:24] I/launcher - Running 1 instances of WebDriver
[09:25:24] I/direct - Using ChromeDriver directly...
[09:25:27] E/launcher - Error: Error: Cannot find module 'is-plain-object'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
    at Function.Module._load (internal/modules/cjs/loader.js:507:25)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)

Again, I'm a but stumped about that one!

I am having the same issue, I was able to accept the alert but the ScreenShot failed ( I am taking screenshot on each interaction). that causing the whole test to break! is there any workaround to fix the screenshot exception? are you guys expecting this pull request to be merged soon?

Hiya @mtahat and @jan-molak  - gosh lots has changed since I created this PR. I'll give this a rebase and then see what happens with the tests and then take it from there? Would be great to get this merged as I still have a local version of BrowseTheWeb in my "working" project that I'd like to lose :-)

Hi @jan-molak - I've rebased and cleaned up this PR and await your review and merge 👍

Thanks @nbarrett, I'll review it shortly!

🎉  👍  Cheers @jan-molak - serenity-js has Alert support! (actually they matured into ModalDialogs)