Sitegroups doesn't allow sharing modules

Description of bug
The sitegroups functionality doesn't allow existing modules to be added from other sites.  There is no dropdown in the Add Existing Module panel to select the site.
Steps to reproduce

Create a sitegroup and add sites
Go to a site
In Edit Mode, click Add Existing Module
There is no way to select a site and page from which to add a module.  Only same site modules can be added

Current behavior
There is no way to select the site from which an existing module is to be added tot the current site.
Expected behavior
There should be a way to select the site and the page
Screenshots
If applicable, provide screenshots to help explain the bug.
Error information
It's really missing functionality rather than a bug.
Additional context
Provide any additional context that may be helpful in understanding and/or resolving the bug.
Affected version

[ ] 10.00.00 alpha build
[x ] 09.07.01 release candidate
[ ] 09.07.00 latest supported release

Also 9.6.1.
Affected browser
N/A

[ ] Chrome
[ ] Firefox
[ ] Safari
[ ] Internet Explorer 11
[ ] Microsoft Edge (Classic)
[ ] Microsoft Edge Chromium

is this a feature that should be discussed to be added?

Well IMO, this does not really need discussing, we just need to update the dropdown to be able to select modules from other portals in the group if the settings allow it...

Still is important to me!

Upon a cursory check, this one is going to be JS world (not React).  Here is the Existing Module Dialog code.
https://github.com/dnnsoftware/Dnn.Platform/blob/714db32390f800ea2336bb0fd2d54fc589256e6b/Dnn.AdminExperience/EditBar/Dnn.EditBar.UI/editBar/resources/ContentEditorManager/Js/ExistingModuleDialog.js
@jncraig I'll see if I can dig into this a bit more after DNN Summit.  Right now is last-minute-scramble time!  😱

Yes, I’m working on presentation, too!
I’m going to do Feature Maker.
On Sun, Feb 21, 2021 at 2:50 PM David Poindexter<EMAIL_ADDRESS>wrote:

Upon a cursory check, this one is going to be JS world (not React). Here
is the Existing Module Dialog code.
https://github.com/dnnsoftware/Dnn.Platform/blob/714db32390f800ea2336bb0fd2d54fc589256e6b/Dnn.AdminExperience/EditBar/Dnn.EditBar.UI/editBar/resources/ContentEditorManager/Js/ExistingModuleDialog.js
@jncraig https://github.com/jncraig I'll see if I can dig into this a
bit more after DNN Summit. Right now is last-minute-scramble time! 😱
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dnnsoftware/Dnn.Platform/issues/4023#issuecomment-782914838,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABEDMRL23OYYP3KT3HCENXDTAFPXJANCNFSM4QQ52QFQ
.

Closing per PR #4597


Protocol type 'Any' cannot conform to 'Encodable' because only concrete types can conform to protocols

i use Alamofire to create Cordova plugin
this is my code:
@objc(request:) // Declare your function name.
    func request(command: CDVInvokedUrlCommand) { // write the function code.
        let arg = command.argument(at: 0) as! [String:Any]
        if arg["url"] != nil{
            let url = arg["url"] as! String
            let param = arg["param"] as? Parameters

            AF.request(url,
                       method: .post,
                       parameters: param,
                       encoder: JSONParameterEncoder.default,
                       headers: nil).response{ res in
                                        debugPrint(res)
                                    }
        }
    }

and throw error: Protocol type 'Any' cannot conform to 'Encodable' because only concrete types can conform to protocols
Alamofire Environment
Alamofire version: 5.0.0.rc3
Xcode version: 11.1
Swift version: 5.1
Platform(s) running Alamofire: ios
macOS version running Xcode: 10.15

i use Alamofire 4.9.1 , it work correct:
    @objc(request:) // Declare your function name.
    func request(command: CDVInvokedUrlCommand) { // write the function code.
        let arg = command.arguments[0] as! [String:Any]
        let url = arg["url"] as! String
        let param = arg["param"] as! [String:Any]
        Alamofire.request(url, method: .post, parameters: param, headers: nil).responseJSON{res in
            print(res)
        }
    }

Yes, if you look, in the Alamofire 5 example you're using request(_:method:parameters:encoder:headers), which requires Encodable parameters. You can use the older request(_:method:parameters:encoding:headers) to use the [String: Any] value. I would suggest refactoring to use Encodable types.
Additionally, we use our GitHub project for bug reports and feature requests. In the future, you should open questions like this on Stack Overflow.
Cheers. 🍻

From our Contribution Guidelines
Asking Questions
We don't use GitHub as a support forum. For any usage questions that are not specific to the project itself, please ask on Stack Overflow instead. By doing so, you'll be more likely to quickly solve your problem, and you'll allow anyone else with the same question to find the answer. This also allows maintainers to focus on improving the project for others.


when webview no DidFinishLoad,then have a problem

When making a second refresh，then, do [self _dispatchMessage:message];

(void)_queueMessage:(WVJBMessage*)message {
if (self.startupMessageQueue) {
[self.startupMessageQueue addObject:message];
}
else {
[self _dispatchMessage:message];
}
}
if webview Did not finish
(void)webViewDidFinishLoad:(UIWebView *)webView
at this time do
(void) _evaluateJavascript:(NSString *)javascriptCommand {
[self.delegate _evaluateJavascript:javascriptCommand];
}
javascript No response .

beasuse  Must be loaded 'webViewDidFinishLoad' before it can respond When executing the following code

(NSString*) _evaluateJavascript:(NSString*)javascriptCommand {
[_webView evaluateJavaScript:javascriptCommand completionHandler:nil];
return NULL;
}

so how can i do that

Hi,
Please create a PR with a failing test case and reopen if you're still having issues.
Thanks!


datalist.json: Remove duplicate link

This link goes to the same repo as the one below

Thanks, just took care of this one manually due to issues removing this via PR in the past.


Adding the editorial for map, set, priority queue in the STL portion of c++

I think STL is complete when we add the major topics like map, unordered map, set, unordered set, priority queue with its editorial on how to implement it in our code.

@aaryahjolia please assign this issue to me.


Passing IP Address with a https://, tcp:// or http:// prefix results in "Too Many Colon" Error

Celestia Node version
latest
OS
Ubuntu
Install tools
No response
Others
No response
Steps to reproduce it
celestia bridge start --core.grpc http://localhost:9090

will result in an error of too many colons but:
celestia bridge start --core.grpc localhost:9090

won't.
It would be good to have both options supported from a UX point of view.
Expected result
celestia bridge start --core.grpc http://localhost:9090

Should work
Actual result
Only
celestia bridge start --core.grpc localhost:9090

works
Relevant log output
No response
Notes
No response

+1 on this. Right now if a user follows the docs exactly as they are, they will run into this issue when attempting to interact or query the local network when running a Celestia light node:
Running:
curl -X GET http://<IP_ADDRESS>:26658/balance

Returns
"querying client for balance: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp: address http://<IP_ADDRESS>:9090: too many colons in address\""root@nader-light-recording:~/celestia-node#

Cc @renaynay

@dabit3 for the second command, you're trying to connect to a validator running on localhost:9090

@renaynay hey thank you, I've updated my comment, I guess my issue ends up being the exact same as Yaz and the curl command works when --core.grpc is set without http:// or https:// prefix

@dabit3 in your updated comment, the commands are the same.
Also, I've tried to reproduce on main, but when I run
 ./build/celestia light start --core.grpc https://rpc-mamaki.pops.one:9090

It works just fine.
Please make sure you're running on the latest main and see if the issue persists.


Create JSON file of dummy blog post objects

This issue is similar to writing test cases for our blog posts ^^
Each Post object in the JSON should follow the following type:
{
author: string,
date: "xxxx-yy-zz",
title: string,
content: string,
tags: string[]
}
Examples of date: "2020-04-23", "2023-04-23", "0950-11-19"... Year 950 is a bit ridiculous, but did it as an example. Date should follow 4-digit year, then 2-digit month, then 2-digit day


[WIP] Full "webDependencies"  management

-  "snowpack": {
-    "webDependencies": [
-      "a",
-      "b",
-      "c"
-    ]
-  },
-  "dependencies": {
+  "webDependencies": {
    "a": "^1.2.3"
    "b": "^1.2.3"
    "c": "^1.2.3"
  },

Background
Keeping up the momentum from #228: Snowpack still relies on semver info to be stored in your package.json dependencies. This messes with our "install from the Pika CDN" story, since that means that npm will still try to install all of your dependencies. For now, all we've really done is added a second, potentially confusing install step.
If Snowpack is going to manage your install step for you, that means we need to own the semver data in a place that npm won't try to install from. We've always used the "webDependencies" as a list of local dependencies to install, but in this PR I'd like us to add support for a new, top-level, "dependencies-like" semver object.
Implementation

[X] Add support to read "webDependencies" from the top-level package.json (still supports reading it from snowpack config file / "snowpack" package.json config)
[X] Add support for a "webDependencies" object notation, which holds semver data. No breaking changes, so we should still support an array of dependency names for now.
[X] If "webDependencies" is object notation, default to --source pika.
[ ] Think through a new config val so that we can still pass additional, non-package assets/entrypoints (assets: []? include: []?)
[ ] Simplify internal config datastructure to normalize this new support (we don't want rest of the package to have to worry about whether "webDependencies" is object vs. array).
[ ] Add tests, and in general do a cleanup pass.

Creating this PR now for early feedback, specifically on the public interface changes.
/cc @dangodev @alex-saunders

This makes sense to me. +1 for the object format you went with. In general maps are great, easy structures to work with. And mirroring package.json’s dependencies structure is a nice bonus. Reasoning makes sense to me too.

Think through a new config val so that we can still pass additional, non-package assets/entrypoints (assets: []? include: []?)

What is the support story here? Is this an improvement to the --include flag or is this for a different case?

Yea, this is something new (if webDependencies becomes an object, we still need a way to define multiple entrypoints inside of one package). You're right that we already use include for something else (src scanning), so we'd need to rename that first if we used that.
"entrypoints" or "additionalEntrypoints" could be good names as well.

Got it. Yeah I’d vote for entryPoints: [] or packageEntryPoints: [] or something along those lines. That seems to be what Node calls these.

rolling #237 conversation into here, we could either continue to support a sub-extension on the types (extending string into [string, string], and similar for objects), or we could support a separate aliases key. I found that by declaring an alias, it eliminates the ability to use the automatic install methods because the aliases as described in #201 live in webDependencies. So if you want an alias in the current verison of #237, you have to opt-into manual webDependency management.
For these reasons, it might be nice if aliases was separate instead of merged into the webDependency structure. It could use the same kind of format as today, but instead of an array maybe an object?
"webDependencies": {
   "a": "^1.2.3"
   "b": "^1.2.3"
   "c": "^1.2.3"
 },
"aliases": {
  "react": "c"
 }

We basically need ways to add the alias to the importMap:
importMap.imports[alias] = `./${targetName}.js${hashQs}`;

add the aliases to rollupPluginAlias
     rollupPluginAlias({
        entries: Array.from(allInstallSpecifiers)
          .filter(spec => Array.isArray(spec))
          .map(([alias, mod]) => ({find: alias, replacement: mod})),
      }),

then the resolveRemote also doesn't have to change in #237 because if you specify aliases they have to be in package.json or webDependencies.

Just throwing my two cents into the mix here:

Love the move to a top-level entry for webDependencies, this feels much more natural and defines a clear split between node and web dependencies without a confusing middle-step.
The object notation is great and feels much more in-keeping with what users are familiar with in terms of dependency definition/management, I totally understand not wanting to introduce a breaking change but I think it would be great to phase-out the array syntax in future (2 syntax choices for the same information could definitely cause confusion)
Splitting assets from the webDependencies entry and keeping only package dependency definitions together sounds smart and should help to keep things clear and self-contained!

On this, I think either assets or webAssets would be a good name (as mentioned previously, include is too similar to different functionality already present within snowpack)
As mentioned by @ChristopherBiscardi , I think a separate aliases (webAliases?) key makes sense with this new structure. Keeping different data definitions in their own package json entries seems to be the way to go here and should help to reduce confusing datastructure logic within snowpack.

Loving the direction snowpack is headed in! It feels like it won't be long before we're a fully-fledged package manager 👀


mediaservice release

https://github.com/Azure/sdk-release-request/issues/3647

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-arm-mediaservices


issue #53, #52, #3 has been resolved.

[x] #53  ---The Button UI has been improved.
[x] #52  ---The Functionality has been changed by changing the color of active and hover classes.
[x] #3    ---Feature Enhancement Description:
Tasks:
[x] Ensure the layout and design are responsive and adapt to different screen sizes, including mobile devices.
[x] Test the project on various mobile devices and browsers to identify and fix any issues.
[x] Adjust font sizes, spacing, and UI elements for better mobile usability.
[x] Optimize images for faster loading on mobile devices.
[x] Implement any necessary CSS media queries to make the project more responsive.
Acceptance Criteria:
[x] The project should look and function well on a variety of mobile devices and screen sizes.
[x] Text and images should be legible and appropriately sized on mobile screens.
[x] The user interface should remain user-friendly on mobile devices.
[x]  The changes should not negatively impact the project's desktop version.
Additional Information:
Feel free to discuss any suggestions, ideas, or resources that could help us achieve a better mobile experience for "The Wall of Projects."

We appreciate your contributions to make this project more accessible to a wider audience. If you have any questions or need assistance, please don't hesitate to ask. Thank you for helping us improve "The Wall of Projects" for mobile users!

Issue has been resolved please check it.

[x] #53

[x] #52
[x] This issue has been improved by changing the attributes in active and hover classes.

Thank you @CodeArtist7071 for your amazing contribution..


Implement drawing tile import/export

drawing tile import with jest tests
drawing tile export with jest and cypress tests
enhanced drawing tile content tests

also:

eliminate calls to preventDefault() in mouseDown handlers so that clicks on the drawing tile allow it to become the focused tile

note that I did not eliminate other uses of preventDefault() that were not relevant to this use case, but it is possible that others should be removed at some point as well.

move some type definitions from drawing-content.ts to a new file for the benefit of clients that only need the types
modify some of the types (e.g. DrawingToolChange) to improve type inference possibilities

For review, @mklewandowski I suggest you focus on the import/export side of things since you're familiar with how that's being done in other tiles, while @sfentress you should focus on the changes to the drawing tile itself, e.g. the typing changes and the removal of preventDefault() to see if I've potentially missed something there.

When I tested on some simple drawing tiles with a couple of lines/shapes drawn, I see this saved tot he clipboard:
{
  "type": "Drawing",
  "objects": [
  ]
}

I expected to see something inside of the objects array.  Am I missing something?

I've done most of my testing at the model level. I probably just didn't hook something up right at the component level.

@mklewandowski I added another commit since your review that hooks up the import code to the document import and also adds some runtime checks for duplicate objects ids which has occurred in at least one of my test documents.

👍 Latest commit looks good!

@sfentress I'm going to go ahead and merge this but feel free to comment if you see anything in the drawing tool code worth addressing.


ENH: Refactor plot_topomap for arrowmaps

I am wondering, how I can refactor plot_topomap for arrowmaps ?

These arrows maps aka Hosaka-Cohen transformation, are like sudo estimates for the underlying current sources, pretty much poor man's minimum-norm estimate.

give it a try. You can have arrows with
https://matplotlib.org/api/_as_gen/matplotlib.axes.Axes.quiver.html

It can work on any system, we can take virtual gradients of magnetometer or axial gradiometer data.
Currently, I am transforming ctf data to a virtual 283 gradiometer system.

@larsoner @agramfort
Please review the code below and let me know, how can I integrate this code in the mne-python API

import mne
from mne.viz import plot_topomap
from mne.viz.topomap import _check_outlines
from mne.datasets import sample, spm_face
from mne.io.pick import pick_types, pick_info
from mne.forward._field_interpolation import _map_meg_channels
from mne.forward._make_forward import _read_coil_defs
from mne.channels.layout import _find_topomap_coords
import matplotlib.pylab as plt
from matplotlib.tri import Triangulation, CubicTriInterpolator
import os.path as op
import numpy as np
plt.ion()

def trigradient(x, y, z):
    tri = Triangulation(x.ravel(), y.ravel())
    tci = CubicTriInterpolator(tri, z.ravel())
    dx, dy = tci.gradient(tri.x, tri.y)
    return dx, dy, tri

sample_path = sample.data_path()
spm_face_path = spm_face.data_path()
templates = _read_coil_defs(verbose=False)

evoked_neuromag= mne.read_evokeds(op.join(sample_path,'MEG','sample' ,
                                          'sample_audvis-no-filter-ave.fif'))

raw_ctf = mne.io.read_raw_ctf(op.join(spm_face_path,'MEG','spm' ,
                                      'SPM_CTF_MEG_example_faces1_3D.ds'))
raw_ctf.apply_gradient_compensation(0)

pick_from = pick_types(evoked_neuromag[0].info, meg='grad', eeg=False,
                       ref_meg=False, exclude=[])
pick_to = pick_types(raw_ctf.info, meg=True, eeg=False, stim=False,misc=False,
                     ref_meg=False, exclude=[])

info_from = pick_info(evoked_neuromag[0].info, pick_from, copy=True)
info_to = pick_info(raw_ctf.info, pick_to, copy=True)

mapping = _map_meg_channels(info_from, info_to, mode='accurate')
data = np.dot(mapping, evoked_neuromag[0].data[pick_from])
pos = _find_topomap_coords(raw_ctf.info, pick_to)
fig, ax = plt.subplots()
plot_topomap(data[:, 174], pos, axes=ax)

x, y = tuple(pos.T)
dx, dy, tri = trigradient(x, y, data[:,174])

dxx = dy.data
dyy = -dx.data

pos, outlines = _check_outlines(pos, 'head', None)
#ax.triplot(tri, 'ko', lw=0)
x, y = tuple(pos.T)
ax.quiver(x, y, dxx, dyy, scale=0.0000000003, color='blue')

Looks pretty neat! Perhaps play a bit with the arrow color. I'd try black
or gray.
On Tue, Sep 25, 2018 at 5:09 PM Sheraz Khan<EMAIL_ADDRESS>wrote:

@larsoner https://github.com/larsoner @agramfort
https://github.com/agramfort
Please review the code below and let me know, how can I integrate this
code in the mne-python API
[image: arrowmap]
https://user-images.githubusercontent.com/2575276/46023377-8271ae00-c0b2-11e8-9e19-52f7abfa3cd2.png
import mne
from mne.viz import plot_topomap
from mne.viz.topomap import _check_outlines
from mne.datasets import sample, spm_face
from mne.io.pick import pick_types, pick_info
from mne.forward._field_interpolation import _map_meg_channels
from mne.forward._make_forward import _read_coil_defs
from mne.channels.layout import _find_topomap_coords
import matplotlib.pylab as plt
from matplotlib.tri import Triangulation, CubicTriInterpolator
import os.path as op
import numpy as np
plt.ion()
def trigradient(x, y, z):
tri = Triangulation(x.ravel(), y.ravel())
tci = CubicTriInterpolator(tri, z.ravel())
dx, dy = tci.gradient(tri.x, tri.y)
return dx, dy, tri
sample_path = sample.data_path()
spm_face_path = spm_face.data_path()
templates = _read_coil_defs(verbose=False)
evoked_neuromag= mne.read_evokeds(op.join(sample_path,'MEG','sample' ,
'sample_audvis-no-filter-ave.fif'))
raw_ctf = mne.io.read_raw_ctf(op.join(spm_face_path,'MEG','spm' ,
'SPM_CTF_MEG_example_faces1_3D.ds'))
raw_ctf.apply_gradient_compensation(0)
pick_from = pick_types(evoked_neuromag[0].info, meg='grad', eeg=False,
ref_meg=False, exclude=[])
pick_to = pick_types(raw_ctf.info, meg=True, eeg=False, stim=False,misc=False,
ref_meg=False, exclude=[])
info_from = pick_info(evoked_neuromag[0].info, pick_from, copy=True)
info_to = pick_info(raw_ctf.info, pick_to, copy=True)
mapping = _map_meg_channels(info_from, info_to, mode='accurate')
data = np.dot(mapping, evoked_neuromag[0].data[pick_from])
pos = _find_topomap_coords(raw_ctf.info, pick_to)
fig, ax = plt.subplots()
plot_topomap(data[:, 174], pos, axes=ax)
x, y = tuple(pos.T)
dx, dy, tri = trigradient(x, y, data[:,174])
dxx = dy.data
dyy = -dx.data
pos, outlines = _check_outlines(pos, 'head', None)
#ax.triplot(tri, 'ko', lw=0)
x, y = tuple(pos.T)
ax.quiver(x, y, dxx, dyy, scale=0.0000000003, color='blue')
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/5492#issuecomment-424381085,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0figNZy2_mQ4N7hNHxWsRrMUEDdcDtks5uekc8gaJpZM4WdKaT
.

here the quiver are derived from the data passed to plot_topomap. If you
want to support this feature I would add a bool parameter to plot_topomap
to show or not the arrows. If you want to pass any field vector you need to
pass a 2D array as a new arrows parameter.

here the quiver are derived from the data passed to plot_topomap. If you want to support this feature I would add a bool parameter to plot_topomap to show or not the arrows. If you want to pass any field vector you need to pass a 2D array as a new arrows parameter.

I think refactoring plot_topomap is cumbersome, may be including plot_arrowmap and trigradient functions in the topomap module is the best best.
If you are ok, I can sent the PR.
import mne
from mne.viz import plot_topomap
from mne.viz.topomap import _check_outlines, _prepare_topo_plot
from mne.datasets import sample
from mne.io.pick import pick_types, pick_info, _picks_by_type
from mne.forward._field_interpolation import _map_meg_channels
import matplotlib.pylab as plt
from matplotlib.tri import Triangulation, CubicTriInterpolator
import os.path as op
import numpy as np

plt.ion()

def trigradient(x, y, z):
    """Prepare gradient of z on the mesh define by x and y"""
    tri = Triangulation(x.ravel(), y.ravel())
    tci = CubicTriInterpolator(tri, z.ravel())
    dx, dy = tci.gradient(tri.x, tri.y)
    return dx, dy

def plot_arrowmap(data, info_from, info_to=None):

    """Plotting arrow map
    ----------
    data : array, shape (n_chan,)
        The data values to plot.
    info_from : instance of Info
        The measurement data to interpolate from.
    info_to : instance of Info
        The measurement info to interpolate to.
    Returns
    -------
    im : matplotlib.image.AxesImage
        The interpolated data.
    cn : matplotlib.contour.ContourSet
        The fieldlines..
    """

    ch_type = _picks_by_type(info_from)
    if len(ch_type) > 1:
        raise ValueError("Multiple Channel type not supported")
    else:
        ch_type = ch_type[0][0]

    if ch_type not in ('mag', 'grad'):
            raise ValueError("Channel type not supported. Supported channel "
                         "types include 'mag' and 'grad'.")

    if info_to is None and ch_type is 'mag':
        info_to = info_from
    else:
        ch_type = _picks_by_type(info_to)
        if len(ch_type) > 1:
            raise ValueError("Multiple Channel type not supported")
        else:
            ch_type = ch_type[0][0]

        if ch_type not in ('mag'):
            raise ValueError("only mag Channel type is supported")

    if info_to is not info_from:
        mapping = _map_meg_channels(info_from, info_to, mode='accurate')
        data = np.dot(mapping, data)

    pos = _prepare_topo_plot(info_to, ch_type='mag', layout=None)[1]
    pos = _check_outlines(pos, 'head', None)[0]
    fig, ax = plt.subplots()
    im, cn = plot_topomap(data, pos, axes=ax)
    x, y = tuple(pos.T)
    dx, dy = trigradient(x, y, data)
    dxx = dy.data
    dyy = -dx.data
    ax.quiver(x, y, dxx, dyy, scale=0.0000000003, color='k', lw=2)
    return fig, ax, im, cn

sample_path = sample.data_path()
evoked_neuromag = mne.read_evokeds(op.join(sample_path,'MEG','sample' ,
                                          'sample_audvis-no-filter-ave.fif'))

pick_from = pick_types(evoked_neuromag[0].info, meg='grad', eeg=False,
                       ref_meg=False)
pick_to = pick_types(evoked_neuromag[0].info, meg='mag', eeg=False, stim=False,misc=False,
                     ref_meg=False, exclude=[])
info_from = pick_info(evoked_neuromag[0].info, pick_from, copy=True)
info_to = pick_info(evoked_neuromag[0].info, pick_to, copy=True)

data = evoked_neuromag[0].data[pick_from,  174]
fig, ax, im, cn = plot_arrowmap(data, info_from, info_to)

fine with me. However I think you only need one info
can you open a PR?

The reason for second info, is to able to interpolate this map for the neuromag gradiometers, as they take gradients in circular coordinates i.e. latitude and longitude. Therefore need to be projected for visualization on the 2D manifold like topomap.
I will push the PR

PR done, one of many that will follow this year :-)

We have this now thanks to @SherazKhan :)


Api Logger Middleware - Unit tests

Issue Number

#352
Overview

[ ] I have written unit tests for the new logging middleware, using a mock server

Comments

Covers pretty much everything but response streams that we don't use anyway.

@paweljakubas

Used concise notation for JSON instances
Turned the last test about requests ids into a property (in terms of the number of requests)
Added another endpoint on the mock server /long which only returns after 100 milliseconds (which is many orders of magnitude bigger than other endpoints!)
Added another property verifying that regardless of the interleaving of standard /get request and a single /long request, only one request had a time logged above 100ms (the long one) to increase confidence that request execution times are logged correctly.


ttnn.empty operations asserts page_size % sizeof(uint32_t) == 0 when last dimension is odd

When testing ttnn ops with TILE layout and random shapes like [4, 7, 21, 133] most of the operations work correctly.
But ttnn.empty operation fails when last dimension is odd with assertion like:
TT_FATAL @ ../tt_metal/impl/buffers/buffer.cpp:32: page_size % sizeof(uint32_t) == 0
info:
Page size must be divisible by sizeof(uint32_t) because buffers hold uint32_t values

Problem is observed on both GS and WH cards.
To Reproduce
Steps to reproduce the behavior:

Checkout branch ngrujic/op_bug_unit_tests (soon to be merged into main).
Run unit test tests/ttnn/python_api_testing/non_working_unit_tests/wormhole/test_empty.py using this command:

pytest tests/ttnn/python_api_testing/non_working_unit_tests/wormhole/test_empty.py

Expected behavior
There are few test cases presented in the unit test, which are failing with:
TT_FATAL @ ../tt_metal/impl/buffers/buffer.cpp:32: page_size % sizeof(uint32_t) == 0
info:
Page size must be divisible by sizeof(uint32_t) because buffers hold uint32_t values
backtrace:
 --- tt::tt_metal::Buffer::Buffer(tt::tt_metal::Device*, unsigned long, unsigned long, tt::tt_metal::BufferType, tt::tt_metal::TensorMemoryLayout, std::optional<tt::tt_metal::ShardSpecBuffer>, bool)
 --- tt::tt_metal::tensor_impl::detail::allocate_interleaved_buffer_on_device(unsigned int, tt::tt_metal::Device*, tt::tt_metal::Shape const&, tt::tt_metal::DataType, tt::tt_metal::Layout, tt::tt_metal::MemoryConfig const&)
 --- tt::tt_metal::tensor_impl::allocate_buffer_on_device(unsigned int, tt::tt_metal::Device*, tt::tt_metal::Shape const&, tt::tt_metal::DataType, tt::tt_metal::Layout, tt::tt_metal::MemoryConfig const&, std::optional<tt::tt_metal::ShardSpecBuffer>)
 --- tt::tt_metal::create_device_tensor(tt::tt_metal::Shape const&, tt::tt_metal::DataType, tt::tt_metal::Layout, tt::tt_metal::Device*, tt::tt_metal::MemoryConfig const&)
 --- tt::tt_metal::empty(tt::tt_metal::Shape, tt::tt_metal::DataType, tt::tt_metal::Layout, tt::tt_metal::Device*, tt::tt_metal::MemoryConfig const&)
 --- /home/ubuntu/tt-metal/tt_eager/tt_lib/_C.so(+0x1d0cd6) [0x7f7dd1882cd6]
 --- /home/ubuntu/tt-metal/tt_eager/tt_lib/_C.so(+0x1038e1) [0x7f7dd17b58e1]
 --- python(PyCFunction_Call+0x59) [0x5d5499]
 --- python(_PyEval_EvalFrameDefault+0x6eb0) [0x54d9f0]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(PyObject_Call+0x62) [0x5d4c12]
 --- python(_PyEval_EvalFrameDefault+0x1f26) [0x548a66]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(PyObject_Call+0x62) [0x5d4c12]
 --- python(_PyEval_EvalFrameDefault+0x1f26) [0x548a66]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python() [0x57a4af]
 --- python(_PyObject_MakeTpCall+0x296) [0x5d6066]
 --- python(_PyEval_EvalFrameDefault+0x690a) [0x54d44a]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(PyObject_Call+0x62) [0x5d4c12]
 --- python(_PyEval_EvalFrameDefault+0x1f26) [0x548a66]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(PyObject_Call+0x62) [0x5d4c12]
 --- python(_PyEval_EvalFrameDefault+0x1f26) [0x548a66]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(PyObject_Call+0x62) [0x5d4c12]
 --- python(_PyEval_EvalFrameDefault+0x1f26) [0x548a66]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python() [0x57a4af]
 --- python(_PyObject_MakeTpCall+0x296) [0x5d6066]
 --- python(_PyEval_EvalFrameDefault+0x690a) [0x54d44a]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(PyObject_Call+0x62) [0x5d4c12]
 --- python(_PyEval_EvalFrameDefault+0x1f26) [0x548a66]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(PyObject_Call+0x62) [0x5d4c12]
 --- python(_PyEval_EvalFrameDefault+0x1f26) [0x548a66]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(PyObject_Call+0x62) [0x5d4c12]
 --- python(_PyEval_EvalFrameDefault+0x1f26) [0x548a66]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(_PyEval_EvalFrameDefault+0x725) [0x547265]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(_PyFunction_Vectorcall+0x393) [0x5d5a23]
 --- python(_PyEval_EvalFrameDefault+0x725) [0x547265]
 --- python(_PyFunction_Vectorcall+0x1b6) [0x5d5846]
 --- python(_PyEval_EvalFrameDefault+0x725) [0x547265]
 --- python(_PyEval_EvalCodeWithName+0x26a) [0x54552a]
 --- python(PyEval_EvalCode+0x27) [0x684327]
 --- python() [0x673a41]
 --- python() [0x673abb]
 --- python() [0x673b61]
 --- python(PyRun_SimpleFileExFlags+0x197) [0x6747e7]
 --- python(Py_RunMain+0x212) [0x6b4072]
 --- python(Py_BytesMain+0x2d) [0x6b43fd]
 --- /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f7e10ad4083]
 --- python(_start+0x2e) [0x5da67e]

Running sweeps
To get additional information and results for different combinations of input shapes, types, layouts and memory configs for which this operation was tested you can also run locally sweeps and check the results. To do this you should:

Run non working sweep by using pytest tests/ttnn/python_api_testing/sweep_tests/run_sweep_test.py --input-path tests/ttnn/python_api_testing/sweep_tests/test_configs/ci_sweep_tests_broken/wormhole/ttnn_empty_test.yaml --input-method cli --cli-input results_ttnn_empty_wh_broken
After the run is completed all test sweeps results should be available inside specified output directory.

There are more sweeps which you can try by changing the above command to target files:
tests/ttnn/python_api_testing/sweep_tests/test_configs/ci_sweep_tests_broken/wormhole/ttnn_empty_test.yaml
tests/ttnn/python_api_testing/sweep_tests/test_configs/ci_sweep_tests_broken/grayskull/ttnn_empty_test.yaml

@nemanjagrujic this is not an issue/bug with empty operation. We only support tensors on device where the page size is a multiple of sizeof(uint32_t). So if data type is bfloat16 (2B elements) and width is odd then that is unsupported. If data type is float32 (4B elements) and width is odd then this would be supported

Actually I see this is related to ttnn and using tile layout, not through tt_lib so this would be a bug (ttnn should pad and avoid this)

Actually I see this is related to ttnn and using tile layout, not through tt_lib so this would be a bug (ttnn should pad and avoid this)

OK!

@mrakitaTT what makes this issue a P0?
P0 is a company level emergency.
I suggest that when a P0 emergency level is set on an issue, that we describe why that's the case, so that the teams know how to prioritise this.

@ayerofieiev-tt will this be padded properly with the new tensor?

@jvasilje , yes. This is exactly what Stas is enabling right now end to end for all paths - both full native c++ and python.

@jvasilje Yesterday @tt-mpantic and I went through the whole list of ttnn issues that we are hitting from tt-mlir compiler and tried to prioritize them before tomorrows SW Bugs meeting.
This was the priority criteria that we've used:

PO - If the issue is blocking the MNIST model working end to end and it also satisfies some of the next two conditions:

We can't make a workaround for that issue in the compiler
We can make a workaround but it would be too messy and hard to revert so we would rather not make it

P1 - If the issue is blocking some other model that we plan to support in this sprint, or if we can make a decent workaround in the compiler
P2 - Rest of the issues

Please let us know if you disagree with this criteria and we can adjust it. We have set the priority to the metal GH issue itself (using labels) but if you prefer we can only set that priority inside the Projects - TT Forge box (image below), and then we can triage with your team so you can agree on priority on your side to set to GH issue itself. Although I think it would be easier if we can just agree on the criteria so we can set the priority upfront, and then your folks can push back on case by case basis if they disagree and adjust the priority if needed.

I suggest that when a P0 emergency level is set on an issue, that we describe why that's the case, so that the teams know how to prioritise this.

Sure, sorry about that, will do in the future!
This issue concretely is blocking us for having MNIST model working end to end and it is not easy to workaround this issue in the compiler.

This test is passing on main now (if you fix some issues with the args being lists on the python side). Is there a concrete test which fails?

@TT-BrianLiu I've verified this now works in tt-mlir for our test cases when I remove the workaround, you can close the issue if everything is done from your side (I don't know if you need to update some tests in metal)


0.0.6 - Update to forge 41.0.98

Fixes breaking changes in forge 41.0.94.

Thanks for your work! Will be merging this and uploading it shortly. Your name will be in the credits for the 1.19 re-release

Hello from the future! I created the 1.19 release but once the Fall semester came I totally forgot to release it. Now instead of releasing 1.19, I'm releasing 1.19.2 since it's the newest version. Nevertheless, your code helped me get rid of some obstacles in the upgrade process. Thanks again and your name will be in the credits in tomorrow's 1.19.2 release.


Support concrete default for impl argument.

Great library!
It would be really powerful to provide concrete defaults for generic parameters, the below example fails to compile:
#[builder]
fn foo(#[builder(default = std::iter::empty())] arg: impl IntoIterator<Item = String>) {
    drop(arg);
}

213 |     #[builder]
    |     ---------- expected this type parameter
214 |     fn foo(#[builder(default = std::iter::empty())] arg: impl IntoIterator<Item = String>) {
    |                                ^^^^^^^^^^^^^^^^^^ expected type parameter `I1`, found `Empty<_>`

A note for the community from the maintainers
Please vote on this issue by adding a 👍 reaction to help the maintainers with prioritizing it. You may add a comment describing your real use case related to this issue for us to better understand the problem domain.

Hi, thank you for creating the issue! Unfortunately, this isn't possible with the current design of the builder struct's type signature. The builder captures the generic parameters eagerly.
There is a cool article that explores the design where generic parameters are resolved lazily, but that approach is a huge rabbit hole of complexity and probably will lead to unacceptable compile times.
Additionally, I think using #[builder(default)] with generic parameters (including impl Trait) is an antipattern due to the current design of "eager generic parameters". I'm planing to document that antipattern for the next release.
In short the problem is the following:
#[bon::builder]
fn example(#[builder(default)] value: impl Default) {}

let _ = example().call();

This code doesn't compile with the error because the compiler can't infer the type of the omitted impl Default parameter:
type annotations needed
cannot satisfy `_: std::default::Default`

Instead, once the next version of bon (#156) is released, you could write this code like this:
#[bon::builder]
    fn foo(
        #[builder(default = vec![], with = FromIterator::from_iter)]
        arg: Vec<String>
    ) {
        drop(arg);
    }

    let _ = foo().call();

The new #[builder(with = ...)] annotation allows you to move the generic parameters to the setter, removing it from the builder struct. So the setter still accepts impl IntoIterator<Item = String>, but in the function you already receive a concrete collection type.
Let me know if this makes sense to you and you understand the footguns with the generic types inference here. I'll need to document this and want to make sure the wording is clear.

I see. Well, another way to work around this is to wrap the value in Option<> and handle it internally:
fn foo(arg: Option<impl MyTrait>) {
    if let Some(arg) = arg {
        // ...
    } else {
        // ...
    }
}

Although... there is still a problem with infering the generic type if you don't pass a value to a setter, so this doesn't compile:
foo().call();

instead you'd need to write this:
foo::<TraitImplType>().call()

Unfortunatelly, this is the limitation of the language where you can't assign default values for generic type parameters in functions (although that's possible to do with generic struct/enum/union)

Yep it's not possible to solve without bon/builders. I was imagining with bon it could work like:

trait MyTrait;

impl MyTrait for ();

impl MyTrait for usize;

#[builder]
fn foo(arg: impl MyTrait) {}

foo() // Builder<()>
    .call() // foo::<()>

foo() // Builder<()>
    .arg(10) // Builder<usize>
    .call() // foo::<usize>

but I don't claim to know the internals or that this would work.
Feel free to close this issue if you're sure it won't be possible to action :)

Interesting idea... Although in general case, and after desugaring this should work with named generic types and the user needs to clarify the exact type of thee default value:
#[builder]
fn foo<T: MyTrait = ()>(#[builder(default = ())] arg: T) {
}

I think syn accepts default values for generic types in function position like that, so this may be actually workable with this syntax where the user has to uses the verbose named generic type parameter syntax, and has to specify the default value for the generic type for which the default expression is written.
The tough part is that the setter needs to be generated like this:
impl<T, State> FooBuilder<T, State> {
     fn arg<U>(value: U) -> FooBuilder<U, SetArg<State>> { /**/ }
}

This is where the macro needs to figure out the proper generics for the arg. For example, when there are many generic parameters, the macro needs to only add generics that are used in the type of the arg and ignore all the rest.
This approach is definitely workable in simple cases, but needs some more prior design to prove that it can work in a general case with complex T::Assoc, where ... clauses and other stuff.

A problem with this approach.. How should the finishing function be written?
impl<T, State> FooBuilder<T, State> {
    fn call(self) {
        let arg: T = self.arg.unwrap_or(|| default_expression);
        __org_foo(arg)
    }
}

This suffers from the same problem where we need to cast default_expression to T. Maybe this can be achievable with some unsafe transmute or some other type system cool trick.. Need to think about this more

How should the finishing function be written?

By not having arg as Option<T> but instead T, or FnOnce(T) for performance. The value shouldn't be set to default at the end, but at the beginning with this approach.

The value shouldn't be set to default at the end, but at the beginning

That's unacceptable. Imagine the default value performs some complex computation or allocation. Calculating it eagerly would require paying the cost of that even if the default value is overridden.
Also, the default expression today guarantees access to already set members in scope. From the docs:

You can also use the values of other members by referencing their names in the default expression. All members are initialized in the order of their declaration. It means only those members that are declared earlier (higher) in the code are available to the default expression.

Storing FnOnce(T) in the builder's fields is not possible because how would you then set an override for the value? Also FnOnce requires yet another generic parameter on the builder's struct for the type of the function itself.

I could make it work like this with a transmute (although it doesn't compile because the names of internal builder fields are generated with random words in them to ensure their privacy, but that wouldn't be a problem if this code was generated instead).
#[bon::builder(
    builder_type = FooBuilder,
    finish_fn(vis = "", name = call_internal),
)]
fn foo_internal(#[builder(setters(name = arg_internal))] arg: impl IntoIterator<Item = String>) {}

fn foo() -> FooBuilder<std::iter::Empty<String>> {
    foo_internal()
}

impl<T: IntoIterator<Item = String>, State: foo_builder::State> FooBuilder<T, State> {
    fn arg<U: IntoIterator<Item = String>>(self, value: U) -> FooBuilder<U, State>
    where
        State::Arg: foo_builder::IsUnset,
    {
        FooBuilder {
            __private_twilight_phantom: std::marker::PhantomData,
            __private_twilight_named_members: (Some(value),),
        }
    }

    fn call(self) {
        let arg: T = self.__private_twilight_named_members.0.unwrap_or_else(|| {
            let default: std::iter::Empty<String> = std::iter::empty();
            unsafe { std::mem::transmute(default) }
        });

        __orig_foo_internal(arg)
    }
}

fn main() {
    foo().call();

    foo().arg(["foo".to_owned()]).call();
}

But then I completely forgot about the maybe_ version of the setter that accepts an Option<T>. I don't see how it could be written:
let _: Builder<??, _> = foo().maybe_arg(Some(["str".to_owned()]));

What would be the type ??? Is it [1; String] or is it std::iter::Empty<String>? The problem is that the type of that generic parameter strictly depends on wether a Some or None was passed. So such setter wouldn't be possible to write

There is a lot to research and experiment with here. I don't see an obvious design that would fit into the existing model without compromising some existing features, but maybe there is such a design that satisfies all requirements. I'd leave this issue open until a comprehensive design appears that takes into account all the edge cases. The first thing to do is to have a code snippet of the generated code like I did above that makes it obvious how generation of such code could be automated in a macro and how it would interact with other existing configs of the macro.
I'll try to think about this more once after I close the current higher priority items


Combination of three paprs

Very rough ATM, minimal cleanup done, but maybe could work?

ohh, forgot to add more memory.

bot, retest this please

bot, retest this please

bot, retest this please

@rhatdan  @mheon and @baude helped me get this one building locally.  It's running well all the way through executing the integration tests.  So the papr stuff is probably working fine (when papr starts working again we'll know for sure) and it's code/makefile stuff that's breaking now.  Heading to get lunch to give jlebon some time.

ahh there she goes!  thx @jlebon !

OMG! There are no quotes around ${TAGS} so it's treating multiple SPACE-SEPARATED tags as multiple arguments, not multiple tags...adding J$%*%&&388#! quotes...

bot, retest this please

bot, retest this please

Needs a rebase.

@rhatdan @mheon said there's no reason other than "sexiness" to do the build inside a container.  I'm not opposed to it in practice...except for...your way introduces a tight-coupling between the host-setup, and the testing.  IMHO, best to have a gap there, b/c it makes it easier to swap one host environment for another.  And/Or, having multiple VMs running the same testing steps (supported by papr).  I think @baude had in mind to do something like this
All that said, are you married to the container-way?  (I'm happy to amend this PR to only realize the division of labor part.)

It's not sexiness - you should always do builds in containers, and don't have that stuff on your host.  Even for workstations.  There are many reasons (security), and you'll be a lot less likely to hit package management disasters.  And further once you do this, it's just as easy to spin up e.g. CentOS/RHEL/whatever containers and use those.

@cgwalters or...we do it both ways :D

FWIW I think "Fedora Atomic" is Fedora too.  So I'd title it "Test in Fedora Cloud and Fedora Atomic".

FWIW I think "Fedora Atomic" is Fedora too. So I'd title it "Test in Fedora Cloud and Fedora Atomic".

True true, an easy fix, thx.

I would prefer if the tests would happen outside of the container, since things like SELinux will not be tested if running inside of a container.

@rhatdan latest push does both, in and out of a container.  However @baude wants to take this over, so closing...

In bubblewrap's papr we build in a container, then install to the host and test there.

Note specifically the use of e.g. ostree admin unlock etc.

Another great example of this pattern that I mentioned earlier is projectatomic/atomic, which @baude is intimately familiar with :). Specifically, notice how the PAPR YAML simply calls out the same script for all three platforms.

@jlebon @cgwalters I think we're all in general agreement.  Thanks for the links.  @baude is taking this over.


node-telegram-bot-api in nodejs not working with socks5 proxy

I am making the bot of telegram through nodejs by using node-telegram-bot-api but the thing is that telegram is banned in Pakistan and we have to use proxy in out nodejs program. I used the socks5 proxy and after the whole program I see a problem saying --->
error: [polling_error] {"code":"EFATAL","message":"EFATAL: Error: connect ECONNREFUSED ::1:1080"}
I have checked my firewall and allowed all the ports from inbound and outbounds to all my ports.
I have chosen 2 different methods of proxy 1 is of request and the other one is simple with polling.
in my .env file I have other port like 3000 or 3002 but even then it tries to connect with 1080 which is a socks5 port and it does not exist in computer may be.
`** METHOD 1:**
const express = require('express');
const app = express();
const telegramBot = require('node-telegram-bot-api');
const Agent = require('socks5-https-client/lib/Agent');
const TOKEN = "6110349259:AAFDIH6oy6AAp52jU6Z8yINc_qROC-CE0Pg";
const bot = new telegramBot(TOKEN, {
polling: true,
request: {
agentClass: Agent,
agentOptions: {
socksHost: process.env.PROXY_SOCKS5_HOST,
socksPort: parseInt(process.env.PROXY_SOCKS5_PORT),
// If authorization is needed:
socksUsername: process.env.PROXY_SOCKS5_USERNAME,
socksPassword: process.env.PROXY_SOCKS5_PASSWORD
}
}
})
** METHOD 2:**

const request = require('request')
const express = require('express');
const app = express();
const TelegramBot = require('node-telegram-bot-api');
const Agent = require('socks5-https-client/lib/Agent');
const TOKEN = "6110349259:AAFDIH6oy6AAp52jU6Z8yINc_qROC-CE0Pg";
var options = {
url: "https://api.telegram.org/bot1111111...11/getMe",
agentClass: Agent,
agentOptions: {
socksHost: process.env.PROXY_SOCKS5_HOST,
socksPort: parseInt(process.env.PROXY_SOCKS5_PORT),
// If authorization is needed:
socksUsername: process.env.PROXY_SOCKS5_USERNAME,
socksPassword: process.env.PROXY_SOCKS5_PASSWORD
}
}
request(options, function (error, res, html) {
if (!error && res.statusCode == 200) {
console.log(html)
} else {
console.log(error)
}
})
const bot = new TelegramBot(TOKEN, {
polling: true,
request: {
agentClass: Agent,your text
agentOptions: {
socksHost: process.env.PROXY_SOCKS5_HOST,
socksPort: parseInt(process.env.PROXY_SOCKS5_PORT),
// If authorization is needed:
socksUsername: process.env.PROXY_SOCKS5_USERNAME,
socksPassword: process.env.PROXY_SOCKS5_PASSWORD
}
}
});`

Have you solved them

Based on the information you have provided, it appears that you are encountering an error with your Node.js program while attempting to use the Telegram Bot API with a SOCKS5 proxy server. Specifically, you are receiving an error message that indicates that the connection to the proxy server is being refused.
To troubleshoot this issue, there are several steps that you can take. First, you should verify that the SOCKS5 proxy server is running and configured correctly. It is also important to double-check your SOCKS5 proxy settings to ensure that the values in your environment variables are correct and that you are using the correct host and port.
If these steps do not resolve the issue, you may want to consider trying a different SOCKS5 proxy server or using a different method of connecting to Telegram, such as the MTProto protocol. Additionally, disabling your firewall temporarily may help to determine if it is causing the issue.
As a software engineer, I would also recommend checking your code to ensure that you are not using the wrong environment variables or hardcoded proxy server settings. It is important to ensure that your code is using the correct environment variables and not hardcoded values that may be incorrect.
I hope this information is helpful to you in resolving your issue. If you have any further questions or concerns, please do not hesitate to let me know.

I am facing the same problem as you. If you solve it, please let me know. Thank you


doc: add pypet/BRIAN2 example pipeline

Create a pipeline for the pypet/BRIAN2 example found here. Stages in this pipeline could include:

setup. installs dependencies using virtualenv
run. runs the pipeline
plot. visualize results

@felix11h could you please help with the specification the post-processing stage, i.e. once the pypet script runs, how would we visualize the results?

Yes, I can do this! Please keep me updated on when and how I can contribute. Is it still planned to use Singularity as a container?

Oh, yeah, I forgot about singularity. @Franko1307, do you think you can modify a singularity image instead of doing it with virtualenv? We would need to:

install Singularity on Travis (instructions here), so that we can keep CI'ing this pipeline
the setup stage would now create the image with pypet/BRIAN2 in it. For this we have two options:

pull an existing docker image and then convert it to Singularity's format.
build one using Singularity's Singularity file, the equivalent to a Dockerfile.

make singularity a binary requirement for this pipeline (and docker two if you go with option 1 above).

Please keep me updated on when and how I can contribute.

thanks @Felix11H! One thing it would be helpful is to have a python script that generates plots from the output of pypet/BRIAN2. Not sure what you use in your domain, matplotlib/seaborn?

@ivotron I finally made a small example here, I hope this is helpful. A Python 3 environment with Brian2, pypet, matplotlib and numpy is needed for this. Let me know if dependencies turn out to be more complicated.
I'm still very interested in seeing a Singularity container for an example like this. Let me know how else I could contribute.


Upgrade opg-performance-analytics to fix console error

Purpose
perfume.js has a known bug in their library that creates an error in the console where the PerformanceObserver does not disconnect correctly.
Upgrading the above package includes the fix for it. (1.1.1)
Fixes UML-970
Approach
Bump the version in the package.json file
Learning
Any tips and tricks, blog posts or tools which helped you. Plus anything notable you've discovered about the Refunds service
Checklist

[x] I have performed a self-review of my own code
[x] I have added relevant logging with appropriate levels to my code
[ ] I have updated documentation (Confluence/GitHub wiki/tech debt doc) where relevant
[x] I have added tests to prove my work
[ ] The product team have tested these changes

Coverage remained the same at 81.735% when pulling 709fde0c3b9d775b0dc7ccb2ef4c10173cf166b9 on UML-970-opg-performance-upgrade into a6b13b3c72af9764236e5252a1c31b44a079d037 on master.


Error when building /pi_examples/label_image on RPi 3 (/usr/include/jpeglib.h:792:3: error: ‘size_t’ does not name a type)

What related GitHub issues or StackOverflow threads have you found by searching the web for your problem?
Some comments here mention the same problem: https://github.com/tensorflow/tensorflow/issues/4680#issuecomment-256078792
Environment info
Operating System:
Raspberry Pi 3
RASPBIAN JESSIE WITH PIXEL
Image with PIXEL desktop based on Debian Jessie
Version:September 2016
Release date:2016-09-23
Kernel version:4.4
If installed from source, provide
If possible, provide a minimal reproducible example (We usually don't have time to read hundreds of lines of your code)
followed instructions here:
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/pi_examples/
What other attempted solutions have you tried?
Tried changing compiler defined in Makefile to g++-4.8 but to no avail
Logs or other output that would be helpful

make -f tensorflow/contrib/pi_examples/label_image/Makefile
gcc --std=c++11 -O0 -I/usr/local/include -I. -I/home/pi/code/tensorflow/tensorflow/contrib/pi_examples/label_image/../../makefile/downloads -I/home/pi/code/tensorflow/t
ensorflow/contrib/pi_examples/label_image/../../makefile/downloads/eigen/ -I/home/pi/code/tensorflow/tensorflow/contrib/pi_examples/label_image/../../makefile/gen/proto
/ -I/home/pi/code/tensorflow/tensorflow/contrib/pi_examples/label_image/../../makefile/gen/proto_text/ -c tensorflow/contrib/pi_examples/label_image/label_image.cc -o /
home/pi/code/tensorflow/tensorflow/contrib/pi_examples/label_image/gen/obj/tensorflow/contrib/pi_examples/label_image/label_image.o
In file included from tensorflow/contrib/pi_examples/label_image/label_image.cc:26:0:
/usr/include/jpeglib.h:792:3: error: ‘size_t’ does not name a type
size_t free_in_buffer; /* # of byte spaces remaining in buffer /
^
/usr/include/jpeglib.h:804:3: error: ‘size_t’ does not name a type
size_t bytes_in_buffer; / # of bytes remaining in buffer /
^
In file included from /usr/include/jpeglib.h:29:0,
from tensorflow/contrib/pi_examples/label_image/label_image.cc:26:
/usr/include/jpeglib.h:835:3: error: ‘size_t’ has not been declared
JMETHOD(void , alloc_small, (j_common_ptr cinfo, int pool_id,
^
/usr/include/jpeglib.h:837:3: error: ‘size_t’ has not been declared
JMETHOD(void FAR , alloc_large, (j_common_ptr cinfo, int pool_id,
^
In file included from tensorflow/contrib/pi_examples/label_image/label_image.cc:26:0:
/usr/include/jpeglib.h:990:34: error: ‘size_t’ has not been declared
EXTERN(void) jpeg_CreateCompress JPP((j_compress_ptr cinfo,
^
/usr/include/jpeglib.h:992:36: error: ‘size_t’ has not been declared
EXTERN(void) jpeg_CreateDecompress JPP((j_decompress_ptr cinfo,
^
/usr/include/jpeglib.h:1000:30: error: ‘FILE’ has not been declared
EXTERN(void) jpeg_stdio_dest JPP((j_compress_ptr cinfo, FILE * outfile));
^
/usr/include/jpeglib.h:1001:29: error: ‘FILE’ has not been declared
EXTERN(void) jpeg_stdio_src JPP((j_decompress_ptr cinfo, FILE * infile));
^
tensorflow/contrib/pi_examples/label_image/label_image.cc: In function ‘tensorflow::Status LoadJpegFile(std::string, std::vector, int, int, int*)’:
tensorflow/contrib/pi_examples/label_image/label_image.cc:108:32: error: cannot convert ‘FILE* {aka _IO_FILE*}’ to ‘int*’ for argument ‘2’ to ‘void jpeg_stdio_src(j_dec
ompress_ptr, int*)’
jpeg_stdio_src(&cinfo, infile);
^
tensorflow/contrib/pi_examples/label_image/label_image.cc: In function ‘int main(int, char**)’:
tensorflow/contrib/pi_examples/label_image/label_image.cc:318:3: error: ‘vector’ was not declared in this scope
vector tensorflow::Flag > flag_list = {
^
tensorflow/contrib/pi_examples/label_image/label_image.cc:318:3: note: suggested alternatives:
In file included from /usr/include/c++/4.9/vector:64:0,
from tensorflow/contrib/pi_examples/label_image/label_image.cc:29:
/usr/include/c++/4.9/bits/stl_vector.h:214:11: note:   ‘std::vector’
class vector : protected _Vector_base<_Tp, _Alloc>
^
/usr/include/c++/4.9/bits/stl_vector.h:214:11: note:   ‘std::vector’
tensorflow/contrib/pi_examples/label_image/label_image.cc:333:52: error: ‘flag_list’ was not declared in this scope
string usage = tensorflow::Flags::Usage(argv[0], flag_list);
^
tensorflow/contrib/pi_examples/label_image/label_image.cc:335:8: error: in argument to unary !
if (!parse_result) {
^
tensorflow/contrib/pi_examples/label_image/label_image.cc:341:49: error: cannot convert ‘std::string {aka std::basic_string}’ to ‘const char*’ for argument ‘1’ to
‘void tensorflow::port::InitMain(const char*, int*, char***)’
tensorflow::port::InitMain(usage, &argc, &argv);
^
tensorflow/contrib/pi_examples/label_image/Makefile:79: recipe for target '/home/pi/code/tensorflow/tensorflow/contrib/pi_examples/label_image/gen/obj/tensorflow/contri
b/pi_examples/label_image/label_image.o' failed
make: *** [/home/pi/code/tensorflow/tensorflow/contrib/pi_examples/label_image/gen/obj/tensorflow/contrib/pi_examples/label_image/label_image.o] Error 1

I've solved half of errors by adding
#include <stdio.h>
before line:
#include <jpeglib.h>
Now I'm getting:

tensorflow/contrib/pi_examples/label_image/label_image.cc:319:3: error: ‘vector’ was not declared in this scope

Just managed to build it successfully with slight code changes. I don't know C++ but I followed errors and fixed it one by one. It seems that this commit broke things: https://github.com/tensorflow/tensorflow/commit/20c02ffe0e6b8af4902487f852e15daa16caa523#diff-48887acc98c15e53f942842ecd65190f
So what I did was:
Open label_image.cc and do this:
Add:
#include <stdio.h>
before
include <jpeglib.h>
Find:
vector tensorflow::Flag > flag_list = { around line 320 and change it to:
std::vector<tensorflow::Flag> flag_list = {
Last thing, just couple lines after last change:
tensorflow::port::InitMain(usage, &argc, &argv); change it to:
tensorflow::port::InitMain(argv[0], &argc, &argv);
That's it, now just run:
make -f tensorflow/contrib/pi_examples/label_image/Makefile
and wait a minute while it finishes, you can then run example by running:
tensorflow/contrib/pi_examples/label_image/gen/bin/label_image
Could anyone help me understand what happened in this diff that broke things and how it got merged to master? Also, I'm not really sure last change is the right thing to do, but it compiles and builds so it is a quickfix for me.

Thanks! Would you mind sending a PR?

No problem, It's getting a bit late here so I might send it tomorrow morning.

Nice, thanks!

Thanks, worked for me! Some really obvious errors there that a linter would have picked up.

Go this to work, thank you @drag0


how to get a specific playlist in v1,not in user

the endpoint: https://api.spotify.com/v1/playlists/{playlist_id}/tracks

It's unclear what you mean. Please look at the examples provided (https://github.com/thelinmichael/spotify-web-api-java/blob/master/examples/data/playlists/GetPlaylistsTracksExample.java)


feat: Hide props with default values within snapshot

This PR will avoid props with their default values within snapshot (Fixes https://github.com/vuejs/vue-test-utils-next/issues/945).
<template>
  <my-component />
</template>

Will now be stubbed to <my-component-stub /> and no longer to <my-component-stub some-props="default-value" />.
This may lead to invalid snapshots and could be a breaking change?
I currently use JSON.stringify for object comparison but I want to replace it.
https://github.com/freakzlike/vue-test-utils-next/blob/efca188cf62bea1f0e4ed07c9cd4766016c1c71c/src/stubs.ts#L115-L116
// TODO: use some different object comparison
return JSON.stringify(defaultValue) === JSON.stringify(propValue)

Is there already any existing util for this? (I haved found one). If not I will create one.

Will this only impact shallowMount? Eg, for components using mount, I think all the prop values should be shown?

It only impact stubbed components so shallowMount and stubs in mount.
I'm also thinking if the props should be sorted by name. I faced some discrepancies of snapshots a while ago because I just changed the order of how the props are passed to the component.

I have added a util function deepCompare and determine the default values of the props during stub setup and not on every render

I'd like some more feedback on this one, maybe @xanf or @cexbrayat or @afontcu ?
My concern is PR adds a lot of complexity that I foresee as difficult to maintain and also will make it very hard to make changes without breaking snapshots.
I'm thinking that VTU should not even be concerned with snapshots; this is a Jest only feature, which can be heavily customized with their snapshot serializer API. Furthermore, different people have different opinions on snapshots, and I don't think we should be enforcing any opinions on them. Knowing the default prop value is likely important for some people.
Finally, this fix is specific to snapshots with shallowMount, a type of test which is going to be brittle and break at the slightest change to any implementation detail (good tests should be resilient to implementation details changing). How useful and beneficial is providing a highly opinionated snapshot, a feature where the desired behavior is different for each dev and testing framework?
I feel like this is going to cause a lot of overhead in the future and we may unintentionally break snapshots in minor versions. I'd like to get some more feedback before we merge this. Thanks for the work so far!

I understand your concerns. Another proposal could be to override the default stub generation by setting a function in the global mounting options. So something like:
const wrapper = shallowMount(MyComponent, {
  global: {
    createStubs: ({ name, component }) => {
      // Implement own logic to create a stub
      return defineComponent({
        name,
        render: () => // Custom render logic
      })
    }
  }
})

This will allow the user the customize the default stub generation when using shallowMount or stubs: { ChildComponent: true }. Maybe some generic function could also be provided by a plugin package

I also tend to think it adds too much complexity for the benefits...

Hi! First of all, thank you for your work on this, I actually learned a couple of things reading your code 🙌
That being said – I agree on the overall feeling of too much complexity – and also, a bit of opinionated. Assuming that component snapshot testing is useful, why wouldn't I get the default values of props? Or why wouldn't I want to break if prop order changes?
With that, I believe this PR should not be merged, as the behavior of snapshot testing is not something Vue Test Utils should control extensively.
Again, thanks!

If you want to make a snapshot serializer that implements this same behavior and need VTU to expose things, we could do that.


specify OBC component function for determining attitude

completion of this task entails defining a function (for OBC component) for determining attitude.
Acceptance criteria:

[ ] include function in a functions.yaml
[ ] specify rotation matrix as output parameter
[ ] specify input parameters

[ ] 3-axis gyro rates
[ ] 3-axis magnetometer vector
[ ] 3-axis sun sensors
[ ] GPS (lat & long)
[ ] RTC

@hungrygusbus tagging you in a comment, since I can't assign you yet

refer to https://github.com/modelb-llc/trrs-wssm as reference


CI: Add AWS integration test workflow, clean up

Reference Issues or PRs
Related to #1951

What does this implement/fix?
Put a x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features not to work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[x] Did you test the pull request locally?
[x] Did you add new tests?

Any other comments?

I commented out the GPU test for now as it kept timing out. I will test it manually and work on adding it to integration tests in another PR.


handle multiple environments with docker-compose.yml and drop the use of the init.tpl file

I'm so sorry for the premature review, I hadn't noticed it was a draft. It came up in my GitHub notifications and I instinctively jumped to the Files tab in excitement.
As for the .env files my concern was not about the name at all (I appreciate you adding the leading dot, thanks!) but about doubling their count by including copies for dev and prod. But again that was a very minor concern so please just discard that.

I'm closing this, as we're re-assessing our approach.


Feature Request: Update logic for how names are returned via Search

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Problem:
I searched for tim g in NewDot and Tim Golen was the 27th person returned.
Solution:
Update logic to take into account both first and last names (and first characters?) to return more accurate results. ie. use AND instead of OR.  (comment here in Slack if this isn't clear, I (Matt A) am unsure of how exactly the current search works)
Context/Examples/Screenshots/Notes:

Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @mallenexpensify
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1673986253628449
https://expensify.slack.com/archives/C01SKUP7QR0/p1674486075840079
View all open jobs on GitHub

This issue has not been updated in over 15 days.  eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

This issue has not been updated in over 15 days.  eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

This issue has not been updated in over 15 days.  eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

I still encounter issues with this, including during Onshore.  I'll try to add more examples here.  Bumping back to weekly cuz E Chat is going to get used a lot more, including at large conferences and we want search to work well

Putting on hold pending https://github.com/Expensify/Expensify/issues/261800 and moving back to Monthly

Just got bit in the ass by this one, as I typed vic fast then instantly sent a message.  She should show up first cuz:

It's the first three letters of her first name
I've chatted with her HUNDREDS of times vs a few times with Miroslav


Redundant type specification when passing one generic function to another

What version of Go are you using (go version)?

go version go1.18beta1 darwin/amd64

Does this issue reproduce with the latest release?
Latest beta release, yes.
What operating system and processor architecture are you using (go env)?
go env Output
GOARCH="amd64"
GOOS="darwin"

What did you do?

package main

import "fmt"

func mapValues[T int64 | float64 | uint64](in []T, mapper func(T)T) []T {
	out := make([]T, len(in))

	for i, n := range in {
		out[i] = mapper(n)
	}

	return out
}

func adder[T int64 | float64 | uint64](n T) T {
	return n + 1
}

func main() {
	intValues := []int64{1, 2, 3, 4, 5}
	floatValues := []float64{1.1, 2.2, 3.3, 4.4, 5.5}

	fmt.Printf("map of ints: %v\n", mapValues(intValues, adder))
	fmt.Printf("map of floats: %v\n", mapValues(floatValues, adder))
}

What did you expect to see?

map of ints: [2 3 4 5 6]
map of floats: [2.1 3.2 4.3 5.4 6.5]

What did you see instead?

./main.go:22:55: cannot use generic function adder without instantiation
./main.go:23:59: cannot use generic function adder without instantiation

The compiler requires me to specify types for adder when passing it to mapValues:

fmt.Printf("map of ints: %v\n", mapValues(intValues, adder[int64]))
fmt.Printf("map of floats: %v\n", mapValues(floatValues, adder[float64]))

However, if I change the first one to uint64 like this:

fmt.Printf("map of ints: %v\n", mapValues(intValues, adder[uint64]))

... then I get the following error:

./main.go:22:55: type func(n uint64) uint64 of adder[uint64] does not match inferred type func(int64) int64 for func(T) T

This begs the question: if the compiler knows what type adder should be why do I have to say it?

This begs the question: if the compiler knows what type adder should be why do I have to say it?

There are two different things going on here: determining the type argument to pass to adder, and then calling mapValues.  The compiler is able to infer the type argument for mapValues from the first argument (intValues or floatValues) so there is no need to specify a type argument for mapValues.  And that means that the compiler knows the type that the second argument to mapValues, adder, must have.
However, there is no type inference rule that uses a known type to infer the type arguments for adder.  In the current language there are only two type inference rules, function argument type inference and constraint type inference.  You are looking for a different kind of type inference rule, that we might perhaps call context type inference.  Without that sort of type inference, the compilation fails if you don't specify type arguments for adder.
When you do specify type arguments for adder, the compiler is able to determine the complete type for the second argument to mapValues.  It can then see whether that type is assignable to the second argument to mapValues, based on the type arguments inferred for mapValues based on the first argument.  In the adder[uint64] case the types are not assignable, and compilation fails as you have seen.
The new inference rule you want is mentioned in the proposal document at https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference-for-generic-function-arguments .
Since this is known and documented, I'm going to close this issue.  Thanks for raising it.

@siggimoo at least this works: https://go.dev/play/p/3qD8okY5duZ?v=gotip
see valueOper function. Demonstration that when you don't know the type T you can still pass around/use generic function types without additional [T] there.
Seems this is slightly annoying, but not a blocker for making generic libraries.


Conveniece method for namespacing

Hey,
Here's a bit of refactoring around the use of NAMESPACE. Removes some duplication and a lot of string concatenation.

@VodkaBears I changed the namespaced method, taking your comments into account. Didn't know that arguments was leaking so badly. Hopefully the method is now much more lightweight.

Sure, no problem


Update readme

Fix up grammar and typos
Standardize headers, links, code and indentation to follow GitHub markdown best practices.

@N-Usha LGTM. please review.


longer latency after post-training quantization

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
I modified the example script a bit to print inference latency
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Google Colaboratory with CPU
TensorFlow installed from (source or binary):
! pip install -U tf-nightly==1.13.0.dev20181027
TensorFlow version (use command below):
tf-nightly-1.13.0.dev20181027
Python version:
2.7
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:
Exact command to reproduce:

Describe the problem
The post-training quantization documentation claims that it provides 3x lower latency: https://www.tensorflow.org/lite/performance/post_training_quantization
But when I try with the example script: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/lite/tutorials/post_training_quant.ipynb
I found that quantized model is apparently slower than original one.
(You can see the logs below. Quantized model provides longer latency).
Why is the experiment result different from the documentation claim?
Should I try some other example/environment?
Source code / logs
The original one with floating-point:
Accuracy after 500 images: 0.970000 average time: 0.002977
Accuracy after 1000 images: 0.960000 average time: 0.003007
Accuracy after 1500 images: 0.952667 average time: 0.003022
Accuracy after 2000 images: 0.951500 average time: 0.003026
Accuracy after 2500 images: 0.949600 average time: 0.003026
Accuracy after 3000 images: 0.954000 average time: 0.003024
Accuracy after 3500 images: 0.956857 average time: 0.003029
Accuracy after 4000 images: 0.954000 average time: 0.003031
Accuracy after 4500 images: 0.954222 average time: 0.003032
Accuracy after 5000 images: 0.954200 average time: 0.003038
Accuracy after 5500 images: 0.957091 average time: 0.003043
Accuracy after 6000 images: 0.958500 average time: 0.003047
Accuracy after 6500 images: 0.959692 average time: 0.003050
Accuracy after 7000 images: 0.960714 average time: 0.003050
Accuracy after 7500 images: 0.962400 average time: 0.003051
Accuracy after 8000 images: 0.964375 average time: 0.003052
Accuracy after 8500 images: 0.965059 average time: 0.003051
Accuracy after 9000 images: 0.966889 average time: 0.003052
Accuracy after 9500 images: 0.968000 average time: 0.003052
Accuracy after 10000 images: 0.966700 average time: 0.003054
total time: 30.540090
0.9667
With post-training quantization:
Accuracy after 500 images: 0.970000 average time: 0.004113
Accuracy after 1000 images: 0.959000 average time: 0.004096
Accuracy after 1500 images: 0.950667 average time: 0.004093
Accuracy after 2000 images: 0.950000 average time: 0.004084
Accuracy after 2500 images: 0.948000 average time: 0.004077
Accuracy after 3000 images: 0.952667 average time: 0.004081
Accuracy after 3500 images: 0.955714 average time: 0.004103
Accuracy after 4000 images: 0.953000 average time: 0.004125
Accuracy after 4500 images: 0.953111 average time: 0.004133
Accuracy after 5000 images: 0.953200 average time: 0.004130
Accuracy after 5500 images: 0.956182 average time: 0.004126
Accuracy after 6000 images: 0.957667 average time: 0.004132
Accuracy after 6500 images: 0.958923 average time: 0.004137
Accuracy after 7000 images: 0.960000 average time: 0.004142
Accuracy after 7500 images: 0.961600 average time: 0.004146
Accuracy after 8000 images: 0.963625 average time: 0.004149
Accuracy after 8500 images: 0.964353 average time: 0.004148
Accuracy after 9000 images: 0.966222 average time: 0.004145
Accuracy after 9500 images: 0.967368 average time: 0.004140
Accuracy after 10000 images: 0.966100 average time: 0.004136
total time: 41.360908
0.9661
We can see after post-training quantization, the latency is apparently longer......
But in the documentation, it claims to reduce latency....

Same problem here. I trained mobilenet on keras on my own dataset and after convert to tflite and use on the application, the FPS was around 250ms and with the post-training quantization was about 450ms.
Keras: 2.2.4
tf-nightly-gpu: '1.13.0-dev20181110'

@mengwanguc did you find any solution?

Same problem.

Hi all, thanks for the issue!
We may need to optimize some kernels that your models are using. We experienced up to 3x on models we optimized, but there are many ops that may still need extra attention :)
We are looking into this. To help us reproduce, could you provide the following:
(1) Which model are you running?
(2) What device/architecture are you running on?
Also, if possible could you provide your TFLite float and TFLite quantized model for reproducing? Feel free to direct email me.

Hi @suharshs
(1). I'm using the MNIST model
(2). I'm running on Google Colab with CPU.
It's Intel(R) Xeon(R) CPU @ 2.30GHz with ~12.7G RAM.
Here the generated TFLite models :
TFLite float: https://drive.google.com/file/d/146fFE4jEXaTLfgXWK3ByQ0XOxIYqa8I1/view?usp=sharing
TFLite quantized: https://drive.google.com/file/d/1dcl9hWzcKNSvoOQBqgTOy3QLsvJLz010/view?usp=sharing
Thanks,
Meng

@suharshs
Actually this is the Google Colab notework I used: https://colab.research.google.com/drive/1ki6VI522w8oUCdoTu4azPZ2_dSZMPHtB

Same problem here


ERROR in Error encountered resolving symbol values statically. Calling function 'makeDecorator', function calls are not supported.

After updating angular-cli (now on version 1.0.0-rc.0) I'm getting the following error and I'm not sure how to get this fixed. Maybe you can help?
ERROR in Error encountered resolving symbol values statically. Calling function 'makeDecorator', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function,
resolving symbol NgModule in<EMAIL_ADDRESS>
resolving symbol NgModule in<EMAIL_ADDRESS>
resolving symbol NgModule in<EMAIL_ADDRESS>
resolving symbol NgModule in<EMAIL_ADDRESS>
resolving symbol CoolStorageModule in /Users/marco/TaxiID/corporate.taxiid.nl/node_modules/angular2-cool-storage/index.d.ts,
resolving symbol CoolStorageModule in /Users/marco/TaxiID/corporate.taxiid.nl/node_modules/angular2-cool-storage/index.d.ts

Thanks for making such an awesome module!

Hey,
This should be fixed in the latest version.
Please remove the node_modules/angular2-cool-storage folder.
Then install the latest version of angular2-cool-storage.
Hope this helps :)

Hi Hacklone,
Thanks for the super quick reply! Instead of removing the node_modules directory and just running npm i I've now ran npm uninstall --save angular2-cool-storage followed by npm install --save angular2-cool-storage and that fixed it.
Happy it was as simple as that hah! Thanks for your help!

Same problem here with  "@angular/core": "4.3.0-beta.0",
ERROR in Error encountered resolving symbol values statically. Function calls are not supported. Consider replacing the function or lambda with a reference to an exported function (position 194:50 in the original .ts file), resolving symbol NgModule in<EMAIL_ADDRESS>resolving symbol CoolStorageModule in node_modules/angular2-cool-storage/index.d.ts, resolving symbol CoolStorageModule in node_modules/angular2-cool-storage/index.d.ts

It seems, we need to reopen issue

Yes i am getting same issue in latest version
"angular2-cool-storage": "^3.1.0",


Need help configuring CMake in Linux

Following the Developer's guide, after installing dependencies and cloning the git on the Raspberry Pi I try to run:
sudo ccmake <VeloView>/Superbuild
But received:
-bash: /Superbuild: Permission denied
Seems like some simple step that I am missing!
I also could not find/identify the CMake configuration file where I am supposed to enable:
ENABLE_veloview=ON
USE_SYSTEM_boost=ON
USE_SYSTEM_python=ON
USE_SYSTEM_qt=ON

Thanks in advance for your help!

type following commaand
sudo ccmake VeloView/Superbuild


SuperDebug collapsable

Is your feature request related to a problem? Please describe.
When having large forms the SuperDebug can hinder you a bit and you have to scroll down to see the actual form.
Describe the solution you'd like
Make it optionally collapsable, so you just see the label + status.
<SuperDebug data={registerForm} collapsable />

It should remember the state with a session storage value, so even if I refresh the page, it should stay as before.

Sounds good, how do you propose that the state should be remembered for each instance of the component? Identity won't be preserved after a page refresh.

sessionStorage.setItem("sveltekit-superforms", JSON.stringify({
    "debug": {
        "<id>": {
            "collapsed": true
        }
    }
}));

or a similar structure.
Alternatively with a context module, so all your debugs are either open or collapsed.

Storing it is simple, but I don't see how to easily acquire a unique id for each instance over multiple requests, without specifying it as a prop, which is a bit cumbersome? I think having a global setting for all instances is the only simple way.

It's added now, a collapsible prop that will store its state per route in sessionStorage.


Unintelligible behavior without Play Services update

It seems that the new Play Services Location APIs in 11.0.1 show somewhat unintelligible behavior when a device does not have the ability to update Play Services, e.g. the Android Emulator without Play Store (I tested on Android Emulator API level 23, which does not have 11.x Play Services yet). The code below never reaches the OnCompleteListener; the "Update Play Services" dialog shows up, but then a stacktrace is printed from Play Services code, and nothing else happens. No feedback available to app code about the situation as far as I can tell.
LocationServices
        .getSettingsClient(fragment.getActivity())
        .checkLocationSettings(settingsRequest)
        .addOnCompleteListener(task -> {});

06-14 23:05:03.245 4606-4606/com.example.something E/DialogRedirect: Failed to start resolution intent
                                                                    android.content.ActivityNotFoundException: No Activity found to handle Intent { act=android.intent.action.VIEW dat=market://details?id=com.google.android.gms&pcampaignid=gcore_11010000-d-com.example.something-21 flg=0x80000 pkg=com.android.vending }
                                                                        at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:1798)
                                                                        at android.app.Instrumentation.execStartActivity(Instrumentation.java:1512)
                                                                        at android.app.Activity.startActivityForResult(Activity.java:3917)
                                                                        at android.support.v4.app.BaseFragmentActivityJB.startActivityForResult(BaseFragmentActivityJB.java:50)
                                                                        at android.support.v4.app.FragmentActivity.startActivityForResult(FragmentActivity.java:79)
                                                                        at android.support.v4.app.ActivityCompatJB.startActivityForResult(ActivityCompatJB.java:30)
                                                                        at android.support.v4.app.ActivityCompat.startActivityForResult(ActivityCompat.java:146)
                                                                        at android.support.v4.app.FragmentActivity.startActivityFromFragment(FragmentActivity.java:937)
                                                                        at android.support.v4.app.FragmentActivity$HostCallbacks.onStartActivityFromFragment(FragmentActivity.java:1047)
                                                                        at android.support.v4.app.Fragment.startActivityForResult(Fragment.java:963)
                                                                        at android.support.v4.app.Fragment.startActivityForResult(Fragment.java:952)
                                                                        at com.google.android.gms.common.internal.zzw.zzrt(Unknown Source)
                                                                        at com.google.android.gms.common.internal.zzt.onClick(Unknown Source)
                                                                        at com.android.internal.app.AlertController$ButtonHandler.handleMessage(AlertController.java:163)
                                                                        at android.os.Handler.dispatchMessage(Handler.java:102)
                                                                        at android.os.Looper.loop(Looper.java:148)
                                                                        at android.app.ActivityThread.main(ActivityThread.java:5417)
                                                                        at java.lang.reflect.Method.invoke(Native Method)
                                                                        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
                                                                        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

I see that the Fragment containing this code receives a random call to onActivityResult() with a result code of 65538. Guessing that this is related to the problem, but don't know what to make of it.

Tracking it down more I see that eventually a notification is displayed, which ultimately triggers the listener.

@bubenheimer seems like you mostly figured it out.  The emulator behavior is worse than you'll see in the wild because they're some of the only devices that have Google Play services but don't have Play Store access to update it, which breaks the update flow.  I think if you try it on a real device you'll see something much more sane.
And the 65538 code you're seeing is a result of how onActivityResult works with Fragments.  The request code is bit-shifted and combined with the fragment's id so that the Activity knows which child Fragment to dispatch the result to.

@samtstern thanks for the final word on this. It looks like the emulator behavior essentially mimics the behavior of a user who dismisses the update dialog, so it seems useful for consistently testing this case.
I believe though that I've identified an issue in 11.0.0 with the GoogleApiClient approach when using enableAutoManage. If an update (resolution) dialog pops up and there is a configuration change, the dialog does not come back. I still have to use this approach in other places with more complex connection-based operations, so I wonder how to get it in front of the right people to be fixed. I've created a small project to reproduce the issue at https://github.com/bubenheimer/playservicesupdaterotationbug


Cross compiling

Currently cross-compiling is not a simple or straight-forward. It requires copying several libraries from the target architecture so gcc won't complain. These are the libraries I've needed to copy so far:
libusb.so
libutil.so
libdl.so
librt.so
libpthread.a
libgcc_s.so.1
libc.a

Also, libudev.so.1 seems to be required for libusb.so however it doesn't seem like adding this to ld's search path solves the issue.
I'd propose a small guide be added or linked for cross-compiling, and secondly, if anyone has a working solution to cross-compiling, I would be ecstatic to know how it was accomplished.

What exactly do you want to achieve? Cross compiling from linux x86 to linux arm, or to a different operating system like windows?

Linux x86 to Linux Arm specifically in this case. I would expect to need the libraries of the target system regardless though (of course they would be different depending on the OS).

What cross C / C++ compiler toolchain do you use? Did you get some from your system package manager, or did you build it yourself / with the help of some tool like crosstool-ng?

I'm using the x-tools-armv7-bin toolchain in the arch linux user repo (arm-unknown-linux-gnueabihf-gcc).

Okay you can run armv7-gcc -print-sysroot (or however it is actually called), which should give you back the directory, where all the libraries and headers of the toolchain are stored. Normally for cross toolchains this includes the most common C and C++ libraries, so you can get up and running without the need to build some extra libraries.
To get new libraries like libusb working, I would just suggest you compile them yourself and install them into your cross compiler sysroot.
To be able to compile the libraries, you have to build them one by one, beginning with the first, which does not have any dependencies on other missing libraries.
Most C / C++ libraries use autotools as their build system, and you can go through this step for step:
1.) Download and extract source code of e.g. libusb
2.) Obtain the target arch of the cross compiler by running armv7-gcc -v. In the output search for the value of Target.
3.) Obtain the cross compiler sysroot by running armv7-gcc -print-sysroot.
4.) In the source dir of the library you run ./configure CC=armv7-gcc --host=TARGET_ARCH --prefix=SYSROOT. This configures your build.
5.) Run make, or make -j8 (Hint: the -j8 will use all your 8 CPU cores, you may have to adjust that part).
6.) Run make install. This will install the library shared objects, resources and headers into your before configured prefix / sysroot. Your cross compile can now find and access these resources.

Thanks, with that I've almost gotten it to work. Cross compiling libudev is a pretty long rabbit hole since it's been merged into systemd. I ended up copied the compiled library from the device into the sysroot for the cross-compiler which let me compile and install libusb which let me cross-compile hidapi. Unfortunately it seems to segfault when running the compiled application. I'll post back after I figure out why or if I can cross-compile systemd.

@Lindenk , the cross compiling story of the crate was improved a little in the current master. (more available backends and a fix to the buildscript).

@Lindenk can you show how you tell Cargo where to look for those native libraries? I'm trying to cross-compile for a MIPS (little Endian) architecture on a MT7688 and seeing these errors, which I presume  means I need to tell Rust which libraries to use:
  = note: mipsel-openwrt-linux-musl-gcc.bin: warning: environment variable 'STAGING_DIR' not defined
          mipsel-openwrt-linux-musl-gcc.bin: warning: environment variable 'STAGING_DIR' not defined
          /toolchain/bin/../lib/gcc/mipsel-openwrt-linux-musl/5.3.0/../../../../mipsel-openwrt-linux-musl/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libusb-1.0.so when searching for -lusb-1.0
          /toolchain/bin/../lib/gcc/mipsel-openwrt-linux-musl/5.3.0/../../../../mipsel-openwrt-linux-musl/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libusb-1.0.a when searching for -lusb-1.0
          /toolchain/bin/../lib/gcc/mipsel-openwrt-linux-musl/5.3.0/../../../../mipsel-openwrt-linux-musl/bin/ld: cannot find -lusb-1.0
          collect2: error: ld returned 1 exit status

@theronic You are getting an error from your cross mipsel-openwrt-linux-musl-gcc.
Normally a cross compiler should not search system directories e.g. /usr/lib/x86_64-linux-gnu/ for static and dynamic libraries. It should search in the cross compiled library path. This is distribution / toolchain specific.
For example I have
/usr/lib/arm-linux-gnueabihf/libusb-1.0.so
My arm-linux-gnueabihf-gcc is searching in the correct directories..
From your output:
mipsel-openwrt-linux-musl-gcc.bin: warning: environment variable 'STAGING_DIR' not defined

My guess is, that your cross compiler wants a STAGING_DIR, where the cross compiler sysroot is located.
export STAGING_DIR="/your/path/to/the/openwrt/staging/dir"
cargo build

This is just a guess.


fix(deps): update dependency gitpython to v3.1.32

This PR contains the following updates:

Package
Update
Change

gitpython
patch
==3.1.31 -> ==3.1.32

Release Notes

gitpython-developers/GitPython (gitpython)
v3.1.32: - with another security update
Compare Source
What's Changed

Bump cygwin/cygwin-install-action from 3 to 4 by @dependabot in https://github.com/gitpython-developers/GitPython/pull/1572
Fix up the commit trailers functionality by @itsluketwist in https://github.com/gitpython-developers/GitPython/pull/1576
Name top-level exceptions as private variables by @Hawk777 in https://github.com/gitpython-developers/GitPython/pull/1590
fix pypi long description by @eUgEntOptIc44 in https://github.com/gitpython-developers/GitPython/pull/1603
Don't rely on del by @r-darwish in https://github.com/gitpython-developers/GitPython/pull/1606
Block insecure non-multi options in clone/clone_from by @Beuc in https://github.com/gitpython-developers/GitPython/pull/1609

New Contributors

@Hawk777 made their first contribution in https://github.com/gitpython-developers/GitPython/pull/1590
@eUgEntOptIc44 made their first contribution in https://github.com/gitpython-developers/GitPython/pull/1603
@r-darwish made their first contribution in https://github.com/gitpython-developers/GitPython/pull/1606
@Beuc made their first contribution in https://github.com/gitpython-developers/GitPython/pull/1609

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.31...3.1.32

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline


Fixed typo

Link in Modifiers section originally read 'can be found are here'.

Overview
Replace this paragraph with a description of your changes and reasoning. Provide links to external references/discussions if appropriate.

Resolves #NN.
Nature of This Change

[ ] 🐛 Fixes a bug
[ ] 🚀 Implements a new feature
[ ] 🛁 Rewrites existing documentation
[ ] 💅 Fixes coding style
[ ] 🔥 Removes unused files / code

Related Application Change

Application Pull Request: https://github.com/ExpressionEngine/ExpressionEngine/pulls/NNN

Thanks, @alexsmacd!


Verify licenses of 3rd party software are compatible with MIT

LUE is licensed under the MIT license. This is only possible if licenses of software we depend on are compatible. This needs to be verified. Also, if 3rd party licenses require us to ship their license and copyright notices, we must start doing this.

More info: https://gw-ospo.github.io/oss-licensing/intro.html

I will work on this.


Summoning doesnt work with transit

Summoned players are frozen for the first 30 seconds due to PP breaking some of the transit stuff

Fixed https://github.com/Civcraft/PrisonPearl/pull/174


Switch to Devise

I think devise would simplify the authentication code and reduce security risks. It would also allow omniauth strategies to be used as well.

+1

ok, in next versions I will add device to manage sessions.

Did you ever think about implementing this?

I am sorry, I have planned to work with this the next month.
Cheers!

This would be a highly beneficial addition

@owen2345 any news so far for this feature

Hi @merongivian,
please check this: https://github.com/owen2345/camaleon-cms/issues/434#issuecomment-263279521


Add input validation and unit tests

[x] Added input validation
[x] Added unit tests

@awmatheson we have the same schema issue here. Hope we can fix this soon.

@awmatheson Pleas review and test with different inputs. Feel free to add additional unit tests. I will also test tomorrow.

[ ] Switch to SDK 1.4.0
[ ] enable identity_type for AmlCompute
[ ] enable identity_id for AmlCompute


Shows container name in the host details page

We are now fetching the through objects and showing the name of each running container.

Looks good!