text:
Wrong SNI hostname used for upstream HTTPS proxy

Problem Description
When using mitmproxy with an upstream HTTPS proxy, it will attempt to use the client connection's target host for SNI in the outer TLS connection, and will subsequently fail to validate that connection and return "502 Bad Gateway" -- "Certificate verify failed: Hostname mismatch"
Steps to reproduce the behavior:

Start mitmproxy with an HTTPS upstream proxy, e.g. mitmproxy --mode upstream:https://example.com:1234 --upstream-auth user:pass
Issue an HTTP request, e.g. curl -ski -x http://127.0.0.1:8080 https://api.ipify.org
mitmproxy will log warn: 127.0.0.1:55584: Server TLS handshake failed. Certificate verify failed: Hostname mismatch and return a 502 Bad Gateway error with reason Certificate verify failed: Hostname mismatch to the client.
A packet capture of the upstream traffic shows that mitmproxy tried to use api.ipify.org for SNI in the TLS connection to the upstream proxy.

System Information
Mitmproxy: 7.0.4
Python:    3.8.10
OpenSSL:   OpenSSL 1.1.1l  24 Aug 2021
Platform:  Linux-5.4.0-26-generic-x86_64-with-glibc2.29

I haven't verified the issue yet, but thank you already for the clear report!

authors: flowztul mhils


text:
Starting via Python is no longer supported after version 7.0.2

Problem Description
Debugging and interaction are more effective  in the above way, but it has been removed after 7.0.2.
Maybe mitmproxy is positioned as a middle agent to capture packets, but I prefer to use it to do something automated as a library.
see here

Steps to reproduce the behavior:

System Information
Paste the output of "mitmproxy --version" here.

Duplicate of https://github.com/mitmproxy/mitmproxy/discussions/5274

source: gharchive/issue

authors: anylayer mhils

repo: mitmproxy/mitmproxy

license: mit

license_type: permissive

license_source: bigquery


text:
Additional fields for course/programs API endpoints

The open-discussions ETL processors for ingesting MITX Online courses and programs would benefit from having a few additional attributes included in the API endpoints: price, url (missing from programs), and description
Designs
Add the following attributes to the course/program API response (via relevant serializers).

current_price
page_url (for programs)
description (derived from CMS page?)

Does the description field need to be stripped of HTML? It's a rich text field in the CMS.

Stripping out the HTML would be good.

authors: jkachel mbertrand

repo: mitodl/mitxonline

license_source: github-api


text:
Updating the Superset icon to an OL branded logo

Adding a local static image with the OL brand icon.
Updated superset_config to point to new app logo.
What are the relevant tickets?
https://github.com/mitodl/ol-infrastructure/issues/1968
Description (What does it do?)
Updates the app icon in the Superset UI.

@quazi-h please use the attached svg logo:

source: gharchive/pull-request

authors: pdpinch quazi-h

repo: mitodl/ol-infrastructure


text:
#929
Originally posted by @MeatsMountain in https://github.com/mitogen-hq/mitogen/issues/811#issuecomment-1191748195

$ git lfs track "*.psd"

https://support.google.com/accounts/answer/3113316

repo: mitogen-hq/mitogen


text:
Use INSTA_UPDATE=force for forcing snapshot updates

In an effort to simplify the configs, this merges the INSTA_UPDATE and INSTA_FORCE_UPDATE configs. Conceptually, INSTA_FORCE_UPDATE overwrites INSTA_UPDATE; they naturally fit into the same config setting.
I realized after starting this that we want to be careful about supporting new & old versions of cargo-insta. So this takes a conservative approach, only changing insta at first, but with the future updates to cargo-insta commented in the code. I realize that adds a bit of complication; though on balance I think simplifying the configs would be helpful and this makes a step towards that.
It stacks on https://github.com/mitsuhiko/insta/pull/479, which should merge first.
I'd be open to writing some tests for this if that'd be helpful.

I think this makes sense in general. I do want to run this first though so I will hold on merging until the next release.

The latest commit:

Targets the insta version when deciding which env var to use. This lets us support older versions while also using the new env var immediately for newer versions
Adds some integration tests for both pre & post 1.40.0
For those to work, I needed to bump the current version to 1.40.0. For similar reasons, we bump the version in PRQL immediately after releasing, rather than immediately before.
Bumps MSRV to 1.65 for cargo-insta...

I would merge this but could you resolve the conflicts?

OK, done. The prior commit actually caught a semantic conflict when running on inline snapshots, so made a small change to make that work. This PR ends up being a lot of additional code for a "simplification" PR. But in retrospect I think in the long-long term in does get simpler, and there's some nice machinery here for making insta & cargo-insta work together nicely (+ our ability to test that).

Missed the release so changed the 1.39->1.40, 1.40->1.41

Will merge in the next week without more feedback, given the note above, to keep things moving.
Lmk if that's too aggressive, both for this PR and the principle

authors: max-sixty mitsuhiko

repo: mitsuhiko/insta


text:
Multiple caller-style arguments to macros

E.g. like this:
{% macro form(footer) %}
    <form>
        {{ caller() }}

            {{ footer }}

    </form>
{% endmacro %}

{% call form(...) %}
    ...body...
{% arg 'footer' %}
   ...footer...
{% endcall %}

Especially for widget-like macros it would be very useful to be able to specify more than one block of HTML that's not as limited as a simply string argument. Of course one could use the new {% set %} block but that's a bit ugly if you use it multiple times
I'm not sure about the best syntax on how to do this, so if the idea itself is accepted (ping @mitsuhiko) and someone has a good suggestion syntax-wise I wouldn't mind having a look at implementing this and sending a PR

I'd be very interested in seeing this implemented ... this is one of the features in mako that I very much miss in jinja2.
If we were to translate the equivalent mako implementation to jinja it would appear something like:
{% macro form(footer) %}
    <form>
        {{ caller() }}

            {{ caller.footer() }}

    </form>
{% endmacro %}

{% call form(...) %}
    ...body...
    {% macro footer() %}
       ...footer...
    {% endmacro %}
{% endcall %}

In mako, it seems that a macro within a call block (a def in mako parlance) gets lifted to become an attribute on the call block.  If my understanding is correct, this would not be appropriate in jinja, which treats the call block effectively as a macro, meaning the embedded macro is part of the local closure.
What if there was some kind of tag, eg submacro or attribute that could be placed within a call (or macro!), and lifted its definition up to become an attribute on its container?

That macro solution looks really strange. IMHO my arg idea is prettier. ;)

I think I'm arguing for almost exactly your syntax, just with an end tag included :-), oh and I guess that it becomes an attribute on caller, rather than another named argument in the macro.  Making it an attribute on caller would help prevent clobbering the local namespace.

caller.something() sounds good; it makes a clearer difference between normal arguments and "block-like" arguments. Not a big fan of a macro-ish name though. Seems confusing to me.

It feels like we are trying to meet an expected interface from the macro we are calling ... so what about something like implement, or using?
eg
{% call form(...) %}
    ...body...
    {% using footer() %}
       ...footer...
    {% endusing %}
{% endcall %}

{% call form(...) %}
    normal caller() stuff
    {% as footer %}
        caller.footer() stuff
    {% endas %}
{% endcall %}

That wouldn't look too bad IMO - you are already inside the caller, so you'd use the new block as the contents for caller.footer

Good argument, I like as

authors: ThiefMaster donkopotamus


text:
Using Google Provider has issues

Issues

May fail on the first API call
Tool Calling

Even if tool_choices is set to 'required', there are cases where the tool is not used

gemini-1.5-pro

Does not use the search tool after the second time

gemini-1.5-flash

Does not use from the first time

Related: #191

it is now possible to support https://mistral.ai/

In the current AI SDK version(3.2.1), an error occurs in the Researcher.
APICallError [AI_APICallError]: Request contains an invalid argument.

any updates on using Google as a provider for morphic?

by default morphic uses openai even when the Gemini Keys are provided and gpt4o are not. This causes unhandledRejection: APICallError [AI_APICallError]:

How do I force morphic to use gemini so I can further debug this issue?

When I updated the AI SDK, errors started occurring, so it should work if you check out version 0.2.15: https://github.com/miurla/morphic/releases/tag/v0.2.15
ref: https://github.com/miurla/morphic/issues/192#issuecomment-2193924534

The error continues for me

Downgrading the sdk doesn't make any sense unless its to debug. Currently Gemini-1.5-latest works for the inquiry agent & Generative UI for ai-sdk 3.3.6 but throws the error when tool calling after inquiry agent.
Here is the indepth error after inquiry agent has processed the query with Gemini 1.5
⨯ unhandledRejection: APICallError [AI_APICallError]: Invalid JSON payload received. Unknown name "default" at 'tools.function_declarations[0].parameters.properties[2].value': Cannot find field.
at /.next/server/chunks/ssr/node_modules_c0965b..js:2207:24
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async postToApi (/.next/server/chunks/ssr/node_modules_c0965b..js:2121:36)
at async GoogleGenerativeAILanguageModel.doStream (/.next/server/chunks/ssr/node_modules_c0965b..js:3766:54)
at async retryWithExponentialBackoff (/.next/server/chunks/ssr/9c4c19..js:381:16)
at async streamText (/.next/server/chunks/ssr/9c4c19..js:1461:47)
at async researcher (/.next/server/chunks/ssr/[root of the server]__1706c0..js:1930:20)
at async processEvents (/.next/server/chunks/ssr/[root of the server]__1706c0..js:2313:63) {
url: 'https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-pro-latest:streamGenerateContent?alt=sse',
requestBodyValues: {
generationConfig: {
topK: undefined,
maxOutputTokens: 2500,
temperature: 0,
topP: undefined
},
contents: [
[Object], [Object],
[Object], [Object],
[Object], [Object],
[Object], [Object],
[Object]
],
tools: { functionDeclarations: [Array] }
},
statusCode: 400,
responseHeaders: {
'alt-svc': 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000',
'content-length': '655',
'content-type': 'text/event-stream',
date: 'Thu, 11 Jul 2024 07:06:08 GMT',
server: 'scaffolding on HTTPServer2',
'server-timing': 'gfet4t7; dur=347',
vary: 'Origin, X-Origin, Referer',
'x-content-type-options': 'nosniff',
'x-frame-options': 'SAMEORIGIN',
'x-xss-protection': '0'
},
responseBody: '{\n' +
'  "error": {\n' +
'    "code": 400,\n' +
    "message": "Invalid JSON payload received. Unknown name \\"default\\" at 'tools.function_declarations[0].parameters.properties[2].value': Cannot find field.",\n +
'    "status": "INVALID_ARGUMENT",\n' +
'    "details": [\n' +
'      {\n' +
'        "@type": "type.googleapis.com/google.rpc.BadRequest",\n' +
'        "fieldViolations": [\n' +
'          {\n' +
'            "field": "tools.function_declarations[0].parameters.properties[2].value",\n' +
            "description": "Invalid JSON payload received. Unknown name \\"default\\" at 'tools.function_declarations[0].parameters.properties[2].value': Cannot find field."\n +
'          }\n' +
'        ]\n' +
'      }\n' +
'    ]\n' +
'  }\n' +
'}\n',
cause: undefined,
isRetryable: false,
data: {
error: {
code: 400,
message: Invalid JSON payload received. Unknown name "default" at 'tools.function_declarations[0].parameters.properties[2].value': Cannot find field.,
status: 'INVALID_ARGUMENT'
}
}
}
Here is the bug from the release you are referring before ai-sdk update.

OK, confirmed. Even with the supported morphic version(v0.2.11) , errors occur, so it probably won't work unless fundamentally fixed.

So, can we expect a fix or something soon?

Resolved this error in PR #254
FYI: @avalynndev @ngoiyaeric

w bro

authors: avalynndev freedomtrain miurla ngoiyaeric

repo: miurla/morphic


text:
Define how sources should be defined

In GitLab by @gregory.ashton on Mar 29, 2018, 00:52
There are several questions to be answered with respect to how a source is defined. Let's resolve this here.
I can see three ways the source can be implemented. I'm going to list these first, along with how they would then be used by the sampler (in any of the three cases, the user will probably just input a string saying they want a 'cbc' waveform etc).
A) Class with parameters defined at initialisation
Definition:
class Source:
    def __init__(self, name, parameters):
        self.name = name
        self.parameters = parameters

    def model(self, time):
        return parameters['m'] * time + parameters['c']

    def update_parameters(self, parameters):
        self.parameters = parameters

Use in the sampler:

# Somewhere in the initialisation of the sampler
my_source = Source('my_source', parameters)

...

# Somewhere in the likelihood
my_source.update_parameters(parameters)
waveform = my_source.model(time)

B) Class with parameters passed to model
Definition:
class Source:
    def __init__(self, name):
        self.name = name

    def model(self, time, parameters):
        return parameters['m'] * time + parameters['c']

Use in the sampler:

# Somewhere in the initialisation of the sampler
my_source = Source('my_source')

...

# Somewhere in the likelihood
waveform = my_source.model(time)

C) Model is a function
Definition:
def model(time, parameters):
   return parameters['m'] * time + parameters['c']

Use in the sampler:

# Somewhere in the initialisation of the sampler
my_source = model # This is a function, not a class instance

...

# Somewhere in the likelihood
waveform = my_source(time, parameters) # Or equivalently, model(time, parameters)

Summary
There is first an argument to be had about whether it should be a class or a function (i.e. A or B vs. C). I'm personally pro class, because it allows for future flexibility. For example, if you need to initialise an approximant or load some data etc.
Second, is the argument between A and B. I believe most of the sources where initially defined as in A (but without an update parameters method). Either will work in practise.
Personally, I think B makes more sense because there is no permanence to the set of parameters - they will get updated on every evaluation of the likelihood. One may then wonder, "if you go with B, why not just make it a function, i.e. C?" To illustrate why not, here is an example
Definition:
class Source:
    def __init__(self, name):
        self.name = name
        self.load_some_data()

    def load_some_data(self):
        self.data = load('my_big_data_file')

    def model(self, time, parameters):
        # here you do something with the data, e.g.
        m = parameters['m'] * self.data
        return m * time + parameters['c']

In this case, making it a function would require you to either load the data everytime you evaluate model, or load the data and pass it to model in the likelihood. This would be cumbersome.
TLDR: The argument for classes is it allows flexibility. The argument for B is that parameters are not data that needs to be saved or known by the source model. However, there could well be data that should be saved by the class, as in the example above.
I'll leave this open to debate and someone else (perhaps the BDFL @paul-lasky ) to decide which. Once decided, I'm happy to implement any of the three for out current models.
@moritz.huebner @paul-lasky

In GitLab by @gregory.ashton on Mar 30, 2018, 01:55
+1 for @ColmTalbot suggestion - this would resolve time/frequency domain problems. Should we also rename the logL likelihood logL_gravitational_wave or something since its not an arbitrary, but specific?
Also yes - these may be duplicate issues - my bad.

In GitLab by @moritz.huebner on Apr 10, 2018, 11:22
Sorry for reopening this one week after the fact, but I was gone last week so I was not able to contribute. I strongly object the way that the sources are currently being implemented.
The reason for this is, that currently dictionaries (that are defined by a list of strings, which is a static variable within the source class) are being used as data containers. There is absolutely no point in doing this.
@gregory.ashton wrote that "Personally, I think B makes more sense because there is no permanence to the set of parameters - they will get updated on every evaluation of the likelihood."
Going from your original proposals, version A would definitely be the typical/conventional way to implement classes. There is no advantage in keeping the data in a python dictionary instead. Classes in object oriented programming are supposed to encapsulate the implementation as far as possible. By having the parameters implemented separately, it will require the user to now carry around both the python dictionary and the class instance, instead of just having to deal with the class instance.
With respect to performance, there should not really be an issue in containing the data within a class instance compared to a dictionary. If we are estimating parameters for a single event, you will only need one class instance.
The main issue with not having it the 'conventional' way is readability for outsiders at this point. If I'm reading code, I expect that the actual parameters are being saved within the class instance, because it is the convention. And that is also where this can cause us trouble later on. You won't find good tutorials/best practice guides/sample codes that do it this way. And while I have no doubt that you can solve any arising problems eventually, it will make it way harder to search for solutions. For example, you could not use the standard python patterns for unit testing. You can not use normal design patterns to check if the values used for the instantiation are allowed.
At this point, I have a branch, where I changed all the stuff, so that it does not rely on the dictionaries anymore but instead implements the parameters as attributes in the respective class. It is fully functional - the tutorials are running fine - and is on the git as the 'source_reimplementation' branch ready to be merged. The change overhauls quite a lot of stuff, which is why I have not pushed it. If you are using a Python script, the main changes will now be, that you instantiate classes the following way:
` source = peyote.source.BinaryBlackHole('BBH', sampling_frequency, time_duration, mass_1=36., mass_2=29.,
spin_1=[0, 0, 0], spin_2=[0, 0, 0], luminosity_distance=100., iota=0.4,
phase=1.3, waveform_approximant='IMRPhenomPv2', reference_frequency=50.,
ra=1.375, dec=-1.2108, geocent_time=1126259642.413, psi=2.659)
`
Instead of defining a dictionary. And in order to change attributes, instead of
prior['mass_1'] = peyote.parameter.Parameter(     'mass_1', prior=peyote.prior.Uniform(lower=35, upper=37),     latex_label='$m_1$')
You will now see
prior.mass_1 = peyote.parameter.Parameter(     'mass_1', prior=peyote.prior.Uniform(lower=35, upper=37),     latex_label='$m_1$')

In GitLab by @ColmTalbot on Mar 30, 2018, 00:41
I left this comment (slightly differently) on https://git.ligo.org/Monash/peyote/issues/6, although maybe it would have been better here. (Are these duplicate issues, or am I missing something?)
I'd also prefer a class, I'd vote for standardisation in the output (personally I don't like having a model method).
class GravitationalWaveSource:
    ...
    def frequency_domain_strain(self, f_array, parameters):
        ...
        return {'plus':foo, 'cross':bar, ...}

    def time_domain_strain(self, t_array, parameters):
        ...
        return {'plus':foo, 'cross':bar, ...}

These could generically be related by an FFT if that's natural.
We can still have the simpler usage that is given by making your source a single method by adding a call function.
I'm going to implicitly assume we're defaulting to FD.
    def __call__(self, f_array, parameters):
        return frequency_domain_strain(self, f_array, parameters)

In GitLab by @moritz.huebner on Apr 10, 2018, 10:19
reopened

In GitLab by @gregory.ashton on Apr 4, 2018, 06:31
Okay, I'm going to close this. We can reopen in future if people want, but for now the code is written using option B

In GitLab by @gregory.ashton on Apr 2, 2018, 00:55
mentioned in commit a1c8dab6363136b543a2fbf63aa56c396149fd13

In GitLab by @gregory.ashton on Apr 4, 2018, 06:31
closed

In GitLab by @gregory.ashton on Apr 10, 2018, 23:34
But some common ground - I do actually think we are handling to many parameters in the parameters dictionary. Certain things that will never be searched over should be removed (for example the waveform_approximant). The parameters dictionary should only ever contain floats (since this is what our nested samplers/MCMC can handle).

In GitLab by @gregory.ashton on Apr 10, 2018, 23:32
Here are a few thoughts on this - I've tried to organise them to avoid this being one big block of text. I'm personally for the current implementation and these are the reasons why.
1) User interface

By having the parameters implemented separately, it will require the user to now carry around both the python dictionary and the class instance, instead of just having to deal with the class instance.

The users don't have to carry around the source and the parameters though. The user specifies only a likelihood and a prior which is passed to run (or the sampler). All the complexity is hidden inside tupak.
Moreover, we still (on your branch current) have an active_parameter_values dictionary. But rather than  passing this to loglikelihood(active_parameter_values) we set it and then call loglikelihood(). So we haven't reduced the amount of data that is being handled by making it part of the source class. We just obscure how that data is passed around.
Finally, I see the source.py class as part of the user interface. People will be writing there own sources and we must make this as easy as possible for them (more on this in a moment).
2) Instantiating sources
I think my fundamental issue can be summed up by looking at the BasicTutorial.py file on your branch where the source in initialised as follows
source = peyote.source.BinaryBlackHole('BBH', sampling_frequency, time_duration, mass_1=36., mass_2=29.,
                                       spin_1=[0, 0, 0], spin_2=[0, 0, 0], luminosity_distance=100., iota=0.4,
                                       phase=1.3, waveform_approximant='IMRPhenomPv2', reference_frequency=50.,
                                       ra=1.375, dec=-1.2108, geocent_time=1126259642.413, psi=2.659)

This makes perfect sense if you are injecting a source...but what about if you are searching some data where you don't know any of the parameters yet? How should the user define the source?
Well okay you could say let's give them all default values of None and then run through and check if they are set and if not they will be overwritten by the sampler. But this opens the door to unexpected behaviour. For example if someone writes there own source function and sets the default to 0..now they will be very confused why their results always come out wrong without raising an error.
There are ways around this of course - adding checks etc.
3) Misc.

For example, you could not use the standard python patterns for unit testing. You can not use normal design patterns to check if the values used for the instantiation are allowed.

But the instantiation is only ever going to be valid for injections. And you can just use a normal routine to check the parameters are valid.
This may be unrelated, but the branch has this in the source.py class, it appears to call itself.
    def copy(self):
        copy = BinaryBlackHole(self.name, self.sampling_frequency, self.time_duration, self.mass_1, self.mass_2,
                               self.luminosity_distance, self.spin_1, self.spin_2, self.iota, self.phase,
                               self.waveform_approximant, self.reference_frequency, self.ra, self.dec,
                               self.geocent_time, self.psi)
        return copy

Maybe this is a clever recursive trick, but if this is required for every source class I think it is a bad idea - we hope that non-experts will be able to write source classes and requiring things like this will not be appealing.
Summary
I don't think this current implementation breaks with convention nor will it cause any difficulties. Philosophically, the parameters are not data of the source object. This becomes evident when instantiating a new source - we should not require a set of parameters - we don't mean a a BBH source with some specific masses etc, but a general BBH source with any masses etc.

In GitLab by @gregory.ashton on Apr 10, 2018, 23:35
I'm also happy to be over ruled on this. Ultimately if it works I don't care. I'm resisting because I think the current method makes more sense and will reduce the time to get a usable code out.

In GitLab by @gregory.ashton on Apr 11, 2018, 10:11
We can close this now right?

repo: mj-will/bilby

license: MIT


text:
Shopify Login || Extensible config

This is an awesome package and just what i've been looking for. Cheers!
Unfortunately I need a Shopify Auth and I see this is the 2nd feature request in a very short time :D
If Shopify Auth is not possible, is it possible to make the package extensible with our own configs?

Will shortly work on that. Thanks for recommendation.

Hi @mjangir , maybe this is a stupid question, but is there any way to pass shop: process.env.SHOPIFY_STORE_SLUG dynamically to your package ? i.e. multiple shops want to authenticate with my app

@TheGame2500 ofcourse you can do that via async config. Please check the useClass or useFactory options.

This is how you can use it

import { ShopifyAuthModule } from '@nestjs-hybrid-auth/shopify';

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      cache: true,
      expandVariables: true,
    }),
    ShopifyAuthModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (configService: ConfigService) => ({
        clientID: configService.get('SHOPIFY_CLIENT_ID'),
        clientSecret: configService.get('SHOPIFY_CLIENT_SECRET'),
        callbackURL: configService.get('SHOPIFY_CALLBACK_URL'),
        shop: configService.get('SHOPIFY_STORE_SLUG'),
      }),
    }),
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

repo: mjangir/nestjs-hybrid-auth


text:
the volume property is ignored during playback

The volume property is ignored during playback.
Ubuntu 22.04 LTS
pactl info:
erver String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 4671
Tile Size: 65472
User Name: zenbooster
Host Name: zenpc
Server Name: PulseAudio (on PipeWire 0.3.48)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_00_1b.0.pro-output-0
Default Source: alsa_input.pci-0000_00_1b.0.pro-input-0
Cookie: 3752:061b

code:
ap = AudioPlayer("hi.mp3")
ap.volume = 1
ap.play(block=True)

volume = 1 or 100 - no difference.

True, there is one thing, but the sound is transfer over the network, but without this I can’t check it yet:
pacat -r -d alsa_output.pci-0000_00_1b.0.pro-output-0.monitor --rate=11025 --channels=1 --format=s16le  | nc -lk -p 11025

repo: mjbrusso/AudioPlayer


text:
Fix RCTRootView.initWithBundleURL signature in examples for RN 0.11

This fixes the examples to build in React Native 0.11.
The signature changed in https://github.com/facebook/react-native/commit/261f9434e54274a68d2cb50644c436197ef48baa.

Would you like me to rebase?

Yep, thanks!

Merged in your commit manually; examples are now working with RN 0.11 :+1:

Oh, OK fine, thanks!

authors: elliottsj gaearon

repo: mjohnston/react-native-webpack-server


text:
Force server FQDN to lowercase, for handling windows output gracefully.

Extend fixture test case as well.
See,
--- FAIL: TestParseLmstatLicenseInfoServer (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x28 pc=0x102cb46d4]

goroutine 38 [running]:
testing.tRunner.func1.2({0x102dcd700, 0x10311b520})
        /opt/homebrew/Cellar/go/1.21.4/libexec/src/testing/testing.go:1545 +0x1c8
testing.tRunner.func1()
        /opt/homebrew/Cellar/go/1.21.4/libexec/src/testing/testing.go:1548 +0x360
panic({0x102dcd700?, 0x10311b520?})
        /opt/homebrew/Cellar/go/1.21.4/libexec/src/runtime/panic.go:914 +0x218
github.com/mjtrangoni/flexlm_exporter/collector.parseLmstatLicenseInfoServer({0x140000de300, 0x10, 0x200?})
        /Users/mtrangoni/git/flexlm_exporter.git/collector/lmstat.go:233 +0x1e4
github.com/mjtrangoni/flexlm_exporter/collector.TestParseLmstatLicenseInfoServer(0x140002151e0)
        /Users/mtrangoni/git/flexlm_exporter.git/collector/lmstat_test.go:164 +0x844
testing.tRunner(0x140002151e0, 0x102e45fc0)
        /opt/homebrew/Cellar/go/1.21.4/libexec/src/testing/testing.go:1595 +0xe8
created by testing.(*T).Run in goroutine 1
        /opt/homebrew/Cellar/go/1.21.4/libexec/src/testing/testing.go:1648 +0x33c
FAIL    github.com/mjtrangoni/flexlm_exporter/collector 0.343s

@cloudrck cloud please test this branch, and let know if this solve your issue? #80.
Please also check if you see any uppercase server name label in your metrics. It would indicate that something else needs to be lowered.
Thank you!

@mjtrangoni Looks like this, indeed fixed the issue. Thanks for the quick fix

authors: cloudrck mjtrangoni


text:
Does ConfuserEx cause any breaking changes to an application on specific versions of Windows 7 or above (32- or 64-bit), or are anti-virus false positives the only thing to worry about?

This is a followup to my my question "What's the strongest protection settings without triggering anti-virus false positives?" ( #64 )
Does anyone know of examples of certain protection settings that cause mkaring's ConfuserEx to create breaking changes to an application on a specific versions of Windows 7 or above (32- or 64-bit) or on a machine where the user configured Windows in a certain unusual way, or are anti-virus false positives the only thing to worry about regarding issues that may occur on some users' machines but not others?

It depends on how the application is used.
I haven't encountered Windows 7 specific problems, just general issues.
Mostly centered around debugging, and reflection use.
Where I work, we have an application that cannot handle "-anti tamper" at all. It just crashes due to what the application is.
In addition, for the same reason we can't use the irreversible "rename" feature either. I have to use instead "+rename(mode=decodable)"
Any public members that might be shared with other assemblies, you can't use rename on at all, for obvious reasons.

Thanks @Gwindalmir for your sharing your experiences and thoughts regarding this very important topic.
I am sorry that you can't use anti-tamper and irreversible renaming, although as I understand it "decodable" renaming is really only reversible by the person who has the symbols.map file so at least your renaming should protect your code greatly.
My biggest concern is that I am using some protection settings that make my app no longer a simple cross-platform (Windows only, but Win 7, 8, and 10, and both 32- and 64-bit) application that is purely 100% C# that PEVerifies like a simple .NET application usually does. I've been developing pure, simple .NET applications that PEVerify for a long time and really appreciate the feature of .NET applications that they generally work on any Windows machine that is new enough and has the necessary .NET Framework. Using mkaring's ConfuserEx with the max protections per his recommendations cause my application to no longer PEVerify, and I have no real experience with what kind of issues this creates on different editions and configurations of Windows. I will do my best to test on different versions of Windows and with different configurations of Windows, but still, it would be great to know up front if there are any known issues of this kind.
I'm going to leave this issue open for another week or so in the hopes that more people share their thoughts and experiences on this.
@mkaring, any thoughts on this?
Thanks again for your help,
glasgowrob

The application will work on different versions of windows without any issue. It uses some native functions of windows, but these functions are present in the Kernel of Windows at the very least since Windows XP, likely ealier when following the Windows NT line. I can't tell you if it works on Windows ME and 98. :wink:
The renaming with the decodable option offers basically the same security as the normal version, except you can see all the letters used for the names except random unicode stuff. But it still can't be reversed without the map-file.
The compatibility problem starts getting real once you are trying to obfuscate an application that should run on anything but Windows. So an assembly that should run on Linux using Mono or .NET Core severely limits what protections you can use.
So all in all: There won't be any differences between the different versions of "recent" Windows Versions (since XP) that are introduced by ConfuserEx into your application.

I don't use MSIL generation, so I have no experience with PEVerify.
However to @mkaring's comment, I do have a .NET standard assembly that is compatible with Linux (dotnet sdk), and it works fine in my testing with the obfuscation settings I use.
I've never used PEVerify, so I have no comment on whether my assembly passes or not.

Thank you very much, @mkaring, for the detailed answer. I now feel greatly relieved about the full compatibility of ConfuserEx across recent Windows versions. I have little experience with Windows programming other than pure .NET programming, but the way you described the kernel thing makes perfect sense and is great news for all .NET developers who want to use your version of ConfuserEx.
Thanks also to @Gwindalmir for sharing your experiences with ConfuserEx obfuscation in a cross platform environment. The fact that ConfuserEx works in any cross platform application is really impressive in itself.
I am closing this issue now. Thanks again, guys.

The application will work on different versions of windows without any issue. It uses some native functions of windows, but these functions are present in the Kernel of Windows at the very least since Windows XP, likely ealier when following the Windows NT line. I can't tell you if it works on Windows ME and 98.
The renaming with the decodable option offers basically the same security as the normal version, except you can see all the letters used for the names except random unicode stuff. But it still can't be reversed without the map-file.
The compatibility problem starts getting real once you are trying to obfuscate an application that should run on anything but Windows. So an assembly that should run on Linux using Mono or .NET Core severely limits what protections you can use.
So all in all: There won't be any differences between the different versions of "recent" Windows Versions (since XP) that are introduced by ConfuserEx into your application.

Have been hit with this compatibility issue in Linux.

authors: Gwindalmir LaraSQP glasgowrob mkaring

repo: mkaring/ConfuserEx


text:
refactor: Extract the Python handler into its own repository

That was a bit of work :stuck_out_tongue:
It needs #355 to support the install cache feature of PDM (resulting in multi-location namespace packages: handlers). Merged

Any idea why CI keeps expecting Python 3.6 results?

Probably something in https://github.com/mkdocstrings/mkdocstrings/settings/branches but I'm just guessing because I don't have access to that

Yeah I think I saw settings related to CI some time ago but I can't manage to find them...

Well have you tried the exact link I just sent??

I did but I missed the edit button :rofl:
It's there indeed, thanks

You're now an owner of the org by the way

Thanks much :grin:

@pawamoy I don't intend to review, you can merge. Maybe I'll look at everything just before release

Actually hmm tomorrow is the day that I have time

Take your time, I'll probably merge tomorrow instead :slightly_smiling_face:

@pawamoy OK you can consider everything approved, other than the comments I left :)

authors: oprypin pawamoy

repo: mkdocstrings/mkdocstrings

license: ISC


text:
Check inherited members for __init__ when merging docstrings

Is your feature request related to a problem? Please describe.
Currently the Python handler only checks in declared members for an __init__ method when merging docstrings together. That means it won't show the docstring of an inherited __init__.
Describe the solution you'd like
Also check inherited members.
Describe alternatives you've considered
/
Additional context
https://github.com/mkdocstrings/griffe/issues/205

As example of this issue is provided in this comment.

authors: pawamoy waylan

repo: mkdocstrings/python


text:
Add setErrorHandler and fatalErrorHandler

exposes setErrorHandler from mlx-c
Adds a fatalErrorHandler which calls fatalError, recording a stack trace and attaching the debugger in Xcode. It would be nice to set this by default in mlx-swift, but I'm not sure if that's possible.

Usage: setErrorHandler(fatalErrorHandler)

Looks nice!  Please apply swift-format as per:

https://github.com/ml-explore/mlx-swift/blob/main/CONTRIBUTING.md#pull-requests

Thanks

authors: davidkoski finnvoor

repo: ml-explore/mlx-swift


text:
[Feature] Would it be possible to implement an RBF NN in MLX

Could the MLX team consider implementing a native Radial Basis Function (RBF) layer in the MLX framework? An RBF layer would greatly enhance MLX's capabilities in function approximation and interpolation, particularly for applications requiring smooth, localized transformations of inputs. This addition would be beneficial for users seeking to integrate complex, non-linear mappings into their MLX-based machine learning models. This would be particularly useful in scientific computing for scenarios where the loss needs to be  based on data generated with external libraries that cannot be  used directly because autograd would not be able to compute the gradients.

Are you looking for something like the following or something more complicated?
import mlx.core as mx
import mlx.nn as nn

class RBFLayer(nn.Module):
    def __init__(self, input_dims, hidden_dims, output_dims, bias=True):
        super().__init__()

        # The initialization of the centers and betas depends on the input
        # distribution, but the following should be kind of fine for a standard
        # normal. Also the betas are going to be learnable this way, maybe it
        # is better to freeze them or make sure they are positive by
        # parameterizing them as logbetas.
        self.centers = mx.random.normal((hidden_dims, input_dims))
        self.betas = mx.full((hidden_dims,), 1/input_dims)
        self.projection = nn.Linear(hidden_dims, output_dims, bias=bias)

    def __call__(self, x):
        # Normalize the shape a bit
        shape = x.shape
        x = x.reshape(-1, shape[-1])

        # Pairwise distance
        x2 = 0.5 * x.square().sum(-1)
        c2 = 0.5 * self.centers.square().sum(-1)
        xc = x @ self.centers.T
        dist = x2[:, None] + c2[None, :] - xc

        # Compute the rbf
        # Here we could use mx.softmax(-dist, -1) for normalized rbf
        # or have fixed β_i etc.
        rbf = mx.exp(-(self.betas * dist))

        # Finally gather the outputs
        return self.projection(rbf).reshape(*shape[:-1], -1)

Hi Angele,
Thank you, this is a great. I will have to experiment with it and fine tune it a bit but it gives me a good starting point and I will reach out for your wisdom if I run into trouble. If I manage to get it working with a couple of examples I am trying right now, I will share it back including any adjustments.

I am closing the issue but feel free to reopen if something comes up.

authors: angeloskath sck-at-ucy

repo: ml-explore/mlx


text:
Handle case of site being down for home page.

If AWS website is down there will be a bad experience on the mobile app because the HomePage template is hosted on AWS.  We could handle this by having a backup home page on device and use it on failure.

Homepage is now being served out of the app.  Closing


text:
Update Manifest

We should revisit the manifest structure and content, renaming or removing fields to make it more clear that is represents a dataset

New manifest structure is implemented as part of #901.


text:
Add component install extra and update others

Follow-up on #587

You can run a pipeline on the local runner with the base installation.
The downside to including more dependencies in the base installation, is that they will be installed inside each component as well.
We could still simplify things by removing the docker extra and including it in both the vertex and kfp extras.

I see, I forgot that docker is only needed for pushing images:

In this case we probably don't need to include them in the requirements.txt of the example notebooks
I would maybe still include then docker with all the runners since it can be used to publish images on all of them
Can we also raise errors to instruct the user to install the component extra if it's not installed (similar to docker and kfp/vertex)

authors: PhilippeMoussalli RobbeSneyders


text:
filterList shows either JPG or jpg, not both

Compilation Environment
I'm not compiling the library myself, but using it under Ubuntu 20.04 via LWJGL, which is used by the Kotlin framework I'm using (OPENRNDR).
Describe the bug
I have .JPG and .jpg files in the same folder. I specify both extensions which OPENRNDR concatenates with a semicolon as filterList.
If I use "JPG;jpg" then JPG files are shown, and with "jpg;JPG" only jpg files are listed. If I use only one of the two options then that one is shown.
Is there any way to list both? Is this a known issue with the library or is it system / framework specific?
User Description
Individual

Sorry for the noise, issue solved. I need to specify "jpg,JPG" and that shows both of them.

repo: mlabbe/nativefiledialog

license: Zlib


text:
Build on ARM (raspberry pi)

I've tried to build sickmuse on a respberry pi with Debian 8 and run in the following issue:
I there any explanation fix for it - see error in the attachment:
status.txt
Thank you in advice
BR

This looks like a problem in installing the python-rrdtool requirement. As they noted you need rrdtool and its development headers installed to compile it. I have no experience doing that myself on a Raspberry Pi.

Mark, thank you for your help! indeed, librrd-dev was not installed.

authors: mlavin zeldor

repo: mlavin/sickmuse


text:
[Bug] Mistral generates repetitive content after a few rounds of long conversation

🐛 Bug
Chatting with Mistral on MLC LLM's Testflight distro, I noticed that it fails to correctly handle long conversation as demonstrated below:
https://github.com/mlc-ai/mlc-llm/assets/22515877/0298bb11-750a-49e8-945a-624be1ee4ee0
On 00:21, I asked a question about dumbbell chest press, but Mistral started to repeat its previous answer using exact words starting 00:17. To rule out the possibility of miscommunication, I clarified the question on 00:33, but still it repeated the previous answers with many exact words.
The issue is pretty easy to reproduce with 5 different topics I tried, and the behavior is relatively consistent that it generates exact words - based on that, I'm afraid it could be some bugs hiding in KVCache handling rather than the model itself.
Environment

Platform (e.g. WebGPU/Vulkan/IOS/Android/CUDA): iPhone
Operating system (e.g. Ubuntu/Windows/MacOS/...): iOS 16
Device (e.g. iPhone 12 Pro, PC+RTX 3090, ...): iPhone 15 Pro Max
Any other relevant information: It's the latest MLC Chat from Testflight

CC @CharlieFRuan @davidpissarra

I believe is with the model. Check out this link: https://huggingface.co/mistralai/Mistral-7B-v0.1/discussions/29

Thank you @Rishita32 for following up! Looks like we are good to conclude this issue for now.

repo: mlc-ai/mlc-llm


text:
ML Perf Mobile Closed Rules Clarification - Object Detection and Image Segmentation

1 Object DetectionCan we modify the settings of TFLite_Detection_Postprocess of MobileDET? Alignment with RulesWe change TFLite_Detection_Postprocess to use fast NMS, along with some modification to detection number and thresholds. This is a kind of approximation approach, which is listed in the allowed example list in 8.2 section of rule:“Approximations (e.g. replacing a transcendental function with a polynomial)”Retraining ConsiderationsNo retraining is required, however we do tune the fast NMS hyper parameters to improve the accuracy result.Accuracy Validation Analysis

Task and Data Set
Target Reference Accuracy
Proposed Accuracy Achieved

Object DetectionMS-COCO 2017
95% of FP32 (mAp: 0.285)
After Tuning: 0.2791

2 Image SegmentationCan we swap the order of the ResizeBilinear op and Argmax op at the end of the model?Alignment with RulesThe modifications make no changes to the weight values of the model and are close approximations to the original model.Retraining ConsiderationsNo retraining required.Accuracy Validation AnalysisWith this change the prediction quality remains is within the acceptable range.

Task and Data Set
Target Reference Accuracy
Proposed Accuracy Achieved

SegmentationADE20K (32 classes, 512x512)
97% of FP32 (32-class mIOU: 54.8)
After Reordering: 53.4 mIOU

plus folks to review and comment.

Notes From ML Commons Mobile Working Group Discussion on June 23 2021
1 - Object Detection NMS may not be allowed in closed division (60% certain that is not allowed in closed -DK)
In ML Perf 1.0 - We wanted to avoid getting gains from Hyper Parameter Searching on NMS.
Open Division could be allowed.
2 - Did not discuss during meeting

Here are my own opinions:

There are many NMS variants available, and also within same NMS algorithm one can tradeoff computational complexity with accuracy. Hence if NMS algorithm or its hyperparameters are allowed to change, once can tradeoff the complexity/accuracy of their NMS algorithm with the complexity/accuracy of their network, so it will not be a consistent benchmark for closed division. If we treat the NMS parameters as weights, then changing NMS of the reference model will fall under this category which is not allowed: Modifying weights during the timed portion of an inference run (no online learning or related techniques)

One can view a node which fuses the resize and the Argmax as a fused node, in that case the swapping operations may be allowed under main inference rules Model Equivalence Rules (fusing or unfusing operation)
https://github.com/mlcommons/inference_policies/blob/master/inference_rules.adoc#82-model-equivalence

That's a bit tricky. Considering that those are not mathematically equivalent and there is reduction of computation (512x512 argmax over 32 classes --> 128x128 argmax over 32x32 classes, which means 1/16 computation complexity)

@willc2010 is this resolved?

Checked with Mobile WG and @dylanzika-google and this issue can be closed.


text:
Fix NCF target accuracy

Correct number is 0.635 HR@10.

SWG:
Owners state that the correct number is "0.635 HR@10" -- this seems to conflict with something written in the rules doc. The rules should be amended to reflect 0.635 HR@10.

authors: bitfort petermattson

repo: mlperf/policies


text:
dependencies upgrade

mainly to avoid glib/gtk breakage from rust-lang/rust#49799.
I could only test with the cargo test suite. The actual program panicks since for some reason systemd1 doesn't show up on my user session bus:
➤ qdbus --system | rg org
 org.freedesktop.timesync1
 org.freedesktop.systemd1

➤ qdbus | rg org
 org.PulseAudio1
 org.freedesktop.ReserveDevice1.Audio0
 org.pulseaudio.Server
org.freedesktop.DBus

huh I missed #54, sorry. This is again master and not rewrite.

repo: mmstick/systemd-manager


text:
Support for [datatype]array format

Mentioned in https://github.com/mmvergara/supabase-schema-dart-class-generator/issues/5#issuecomment-2184016359

Done in PR https://github.com/mmvergara/supabase-schema-dart-class-generator/pull/20


text:
ENH: apply_forward; compute sensor space data from source estimate

This is useful, e.g., when evaluating methods or when working with surrogate data in source space.

Ok, now apply_forward returns Evoked, so it is consistent with apply_inverse.

one last thing before you want to kill me ... To me having a template and include, exclude parameters is a bit redundant. I would expect the output Evoked to have the same channels and the function to raise an error if a data channel in Evoked is not present in the forward. A typical use case would be to keep only the MEG channels and I don't feel it would be very convenient with include, exclude. I'd rather do first a pick_channels_evoked and then the apply_forward. I'm just trying to avoid having too many different ways to do the same thing. If you're fed up I can do it tomorrow if you want.

True, it is a bit redundant. At the moment, the returned Evoked/Raw object will have all the channels that are present in fwd, as the channel info is copied from there. The problem with using pick_channels_evoked is that the corresponding function doesn't exist for Raw (and it would be difficult to implement, as the data usually stays on disk).
How about we use pick_channels_forward and pick_types_forward (I can add this function)?

Yes, it will be nice and clean :).

I like that !

Regarding raising an exception, isn't all the channel info included in fwd['chs']?

it should but you never know what users do :)

At the moment I copy the channel information from there, so it should work even if a channel isn't present in the info of the template. Right?

I think it shouldn't

Another attempt ;-)

merged ! I'll polish the tests

done !

authors: agramfort mluessi

repo: mne-tools/mne-python


text:
MRG: Tiny improvement to the axis labels in "generalization across time and conditions" decoding example

Make it easy to see at a signle glace which condition was used for training and which for testing.

The x axis label is cropped in the rendered example:
https://output.circle-artifacts.com/output/job/15c958e1-bb3f-44a3-b74d-dcb46b55a6fc/artifacts/0/dev/auto_examples/decoding/decoding_time_generalization_conditions.html

This doesn't happen locally for me. Any idea how to fix that?

We should switch to constrained_layout=True figure creation. In 100% of my use cases in the last year or two it has worked without needing any adjustments. We should probably change all our plotting functions to use it at some point...

Looks good to me!
https://output.circle-artifacts.com/output/job/27b04d6a-216f-49df-b3fe-cecb58d044f4/artifacts/0/dev/auto_examples/decoding/decoding_time_generalization_conditions.html#sphx-glr-auto-examples-decoding-decoding-time-generalization-conditions-py

I'm assuming the "push right" rather than "fill" is due to 1) the aspect being forced to be equal in the image by matshow and 2) being associated with the colorbar, which makes sense

Great, thanks for your help, @larsoner

authors: hoechenberger larsoner


text:
MAINT: Add h5py to pip-pre runs

h5py is now up on https://pypi.anaconda.org/scientific-python-nightly-wheels/simple/ , let's use it

Needs https://github.com/h5py/h5py/pull/2386


text:
[MRG] Fix pickling of NamedInt and NamedFloat

Fixes #6235.

Please add a tiny test that just tries to pickle such a small object. Thx

LGTM complains that the first argument should be called self (and not obj). That's OK, I'll change it, but then shouldn't the first argument to __new__ also be called self? Why is it called cls even though it is not declared as a @classmethod? And why doesn't LGTM complain? @agramfort @larsoner

shouldn't the first argument to new also be called self? Why is it called cls even though it is not declared as a @classmethod

__new__ is called to actually create the instance of the class, i.e. it is pretty much creating what every other method will then refer to as self. The naming reflects this.
I pushed a commit to simplify the NamedInt and NamedFloat classes, and add copyright to the new test file. (They don't all have it but probably should.)

OK, so __new__ should really have cls as its argument name (I know it's just a naming convention). Thanks for cleaning up some more, if CIs turn green and @agramfort is happy I think this could be merged.

Thanks @cbrnr

authors: agramfort cbrnr larsoner


text:
WIP: avoid warning in SURE when passing grid & allow to return empty stc

cc @PABannier
let me know what you think

For the empty STC + warning part, LGTM!

authors: PABannier agramfort


text:
No fill not calling MobFoxInterstitialAdDidFailToReceiveAdWithError

Hi,
I'm finding that when an ad can't be filled I don't receive a call on the delegate for the error handler.  I think it used to work this way.  I'm assuming it is no fill because in the console the MobFox code is printing:
MobFox ad response: {
error =     {
noAd = 1;
};
}
When there is an ad, or I use the test id everything works fine.
Thanks.

Hi,
From looking at the code nothing pops out immediately but as you describe it it's consistent behavior. We'll reproduce it and try to issue a fix tomorrow.
Thanks

I have tested interstitial ad and the response is return, also delegate function of AdDidFail is called. you can test this scenario with our demo app and also send me your implementation code to my email: shimi.s@matomy.com

I've tried the demo app it works fine with the same account.  I hoped it was simply that I'd mangled the spelling of 'interstitial' but the callback is correctly spelt.  I'll send you my code to check over, thanks.

authors: dwxw nabriski shimisheetrit

repo: mobfox/MobFox-iOS-SDK


text:
[Feature Request] New commands

Is your feature request related to a problem? Please describe.

maestro upgrade

it would automatically update the new version: curl -Ls "https://get.maestro.mobile.dev" | bash
In case your version is updated to the latest.
Congrats! You're already on the latest version of Maestro (which is v1.34.1)

maestro update
It should tell you if there is a more up-to-date version than yours.

Hey, thanks for creating an issue. This sounds like something that should be a responsibility of a package manager. So I'll consider it a duplicate of #1513

repo: mobile-dev-inc/maestro


text:
Hide Keyboard fails intermittently.

Hide Keyboard is still not 100% reliable. I found following flow where it fails:
# flow_contacts_android.yaml
appId: com.android.contacts
---
- launchApp
- tapOn: "Create new contact"
- tapOn: "First name"
- inputText: "FName01"
- tapOn: "Last name"
- inputText: "LName01"
- tapOn: "Phone"
- inputText: "80011085400"
- hideKeyboard
- tapOn: "Email"
- inputText: "lname01.fname01@gmail.com"
- tapOn: "Save"

Device: Pixel 6 Emulator

It also seems that this command is introducing a line break (Nexus S, SDK 32) https://github.com/mobile-dev-inc/maestro/blob/5f866556debc28a8157ab5949fb1f40ed24268a3/maestro-client/src/main/java/maestro/drivers/AndroidDriver.kt#L351

KeyEvent 4 seems to work ('back', which dismisses the keyboard) http://www.temblast.com/ref/akeyscode.htm

authors: imanishverma nhaarman raulriera


text:
add ConfigurationKeys

added configuration keys (for v16 only)

i added the configuration keys to enums.py, not sure if you need to update your schema_to_enums.pu script to prevent them from being overwritten.

Also, might be nice to separate the keys for the different profiles. What would be a good way to do that?

Thanks for this @lbbrhzn, I guess you manually added all the keys, right? in order to avoid losing data, what I think we could do is to add an extra file, containing the original OCPP config keys, for 1.6 and read from there when we run the schema_to_enums.py, but not sure if it is the best idea

Not sure either. Perhaps that's something you can do in a new pull request?

This PR is superseded by #413. Thanks @lbbrhzn

authors: OrangeTux lbbrhzn tropxy

repo: mobilityhouse/ocpp


text:
🛑 Asian Food is down

In 4671cd1, Asian Food (https://asianfood.com.uy) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Asian Food is back up in 6919480 after 7 minutes.

repo: mobilitysol/monitorweb


text:
Averaging centroided spectra results in empty spectra

Since some time, I do not recall how long exactly, the mzdata::spectrum::average_spectra functions returns empty spectra (full range of mzs but intensity is always NaN or 0). Playing around locally a bit I figured out that changing the PeaksShapeModel::from::<FittedPeak> into PeakShapeModel::from_centroid(...) with some fwhm (both 3.0 and 1e-4 returned something that looked somewhat sensible). Could it be that th fwhm is not set properly in the code? Do you have any ideas on how to set it to some sensible default for the given data?

Now that you point it out, I see the problem is probably https://github.com/mobiusklein/mzdata/blob/main/src/spectrum/group.rs#L785 and this error is in other places too. FittedPeak::from leaves the full_width_at_half_max attribute initialized to the default, 0.0. This probably should have a dedicated conversion function instead of relying on From here.
Picking the right FWHM is difficult because it's a function of the mass analyzer's resolution. You'll find different equations for different analyzers as well. That said, from previous experience I would use a value of 0.01 or 0.005 if it is greater than dx still.

Fix is now live on the main branch. Please let me know if this addresses the issue you observed and if so I'll cut a new release

This patch works wonderfully.

authors: douweschulte mobiusklein

repo: mobiusklein/mzdata


text:
Warning: Could not find any test files matching pattern

Hi Mocha Team !
The problem :
This warning stops my tests on Circle CI V2.0 (Ubuntu 14.04, Nodejs 8.9.3) :
...
yarn test
...
$ eslint .
$ mocha "./src/migrations/index.test.js" --require babel-core/register
Warning: Could not find any test files matching pattern: ./src/migrations/index.test.js
No test files found
error Command failed with exit code 1.

I tried to fix it reading similar issues like #2895 but nothing works.
My package.json :
...
"test-migrations": "mocha \"./src/migrations/index.test.js\" --require babel-core/register",
"test": "yarn run lint && yarn run test-migrations && mocha \"./src/index.test.js\" --require babel-core/register",
...

I also tried to write the path differently like :
mocha src/migrations/index.test.js --require babel-core/registe but it doesn't work
Weird behavior :
There's not warning and everything works fine on

OSX
Ubuntu 16.04
Debian Jessie
Debian Stretch

How could i solve this problem ?
Thanks a lot !

nobody could help during the holidays ? :) @Bamieh @boneskull @markowsiak @Munter ?
Thanks a lot !  that's quite important for us, our CI can't work with this error :/

@Aarbel This error is logged when mocha is unable to resolve the file path. Are you sure the src directory is being copied into the CI?
Please replace the test script with ls src/migrations and see what logs.

@Bamieh
ok the problem comes from docker-compose and not mocha, i created an issue here : https://github.com/docker/compose/issues/5519

authors: Aarbel Bamieh

repo: mochajs/mocha


text:
Docs: document programmatic usage of mocha, more specifically: createStatsCollector

Use case: Use mocha as part of a build pipeline with a root suite with nested suites, without it being the main entrypoint for mocha CLI.
Issue: Documentation on how to use the 'pure' JS API is sparse, but more specifically there is no documentation code sample showing that initiating createStatsCollector is required after a certain version (TBD?), even for non-custom reporters. This is a google search for the exact match 'statsCollector' on the mochajs.org website:
https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fmochajs.org+"statsCollector"
This works in mocha 5.x:
const { Suite, Context, Runner, reporters: { Spec }} = require('mocha')
const childSuite = require('./childSuite')

const rootContext = new Context()
const rootSuite = new Suite(rootContext)
rootSuite.addSuite(childSuite)

const runner = new Runner(rootSuite)
const spec = new reporters.Spec(runner)

runner.run()

But throws uncaught(): got truthy exception TypeError: Cannot read property 'passes' of undefined in mocha 9.x:
Full error log
mocha:runner uncaught(): got truthy exception TypeError: Cannot read property 'passes' of undefined
  mocha:runner     at Spec.Base.epilogue (node_modules/mocha/lib/reporters/base.js:363:30)
  mocha:runner     at Object.onceWrapper (node:events:513:28)
  mocha:runner     at Runner.emit (node:events:406:35)
  mocha:runner     at end (node_modules/mocha/lib/runner.js:1051:10)
  mocha:runner     at node_modules/mocha/lib/runner.js:912:7
  mocha:runner     at next (node_modules/mocha/lib/runner.js:489:14)
  mocha:runner     at Immediate. (node_modules/mocha/lib/runner.js:574:5)
  mocha:runner     at processImmediate (node:internal/timers:464:21) +1ms
  mocha:runner uncaught(): Runnable has already passed; bailing gracefully +1ms
  mocha:runner total number of failures: 1 +0ms
  1) should have a 'Installation' section
  mocha:runner abort(): aborting +1ms

Not sure in which version this was changed but it is due to missing a StatsCollector. The following snippet works as expected on mocha@latest:
const { Suite, Context, Runner, reporters: { Spec }} = require('mocha')
const createStatsCollector = require('mocha/lib/stats-collector')
const childSuite = require('./childSuite')

const rootContext = new Context()
const rootSuite = new Suite(rootContext)
rootSuite.addSuite(childSuite)

const runner = new Runner(rootSuite)
createStatsCollector(runner)
const spec = new reporters.Spec(runner)

runner.run()
// but why not suite.run() which sounds more logical but does nothing?

Also hard to find in a guide (but somewhat  figuring in the API docs):

runner.run must be called & not suite.run
whether child suites inherit the root suite runner/reporter (they do) and whether a separate runner/reporter is supported/required/recommended for child suites
how to access parent/root context from a child suite, or ensure all suites share context
the difference between/ when to use suite.addSuite(new Suite(title, context)) vs Suite.createSuite(title, context)

Use case: Use mocha as part of a build pipeline with a root suite with nested suites, without it being the main entrypoint for mocha CLI.

Mocha does not offer any public API to achieve this, e.g. Suite.prototype.addSuite is a private function. I have seen third-party packages depending on our private functions and also the weirdest example of dynamically creating tests via before hooks. But developping that way is on your own risk and you won't find any official docs about that.
So it's possible that your code - runnig on Mocha@5 - breaks on Mocha@9. Changes in private parts of the code base are no breaking changes. createStatsCollector is private as well.
So most of your question can only be answered by studying Mocha's code and then fiddling around.
Maybe using Mocha via CLI and dynamically creating tests via top-level-await or --delay option could be an alternative?

@juergba Sorry  addSuite is indeed private, but new Suite and Suite.createSuite aren't, so Mocha definitely does provide a public API to achieve this, if one can trust the @public docblocks also documented in the API docs. Here is an (undocumented- example using only public methods:
const Mocha = require('mocha')
const tests = new Mocha()

tests.addFile('./path/to/childSuite.js')
tests.run()

It's unfortunate that createStatsCollector and Suite.addTests are private, because having them public would allow completely integrating mocha in a custom workflow. The example below also only uses public methods, but in the current state Mocha can only be instantiated like this with a 0-test suite.
const rootSuite = new Mocha.Suite('Root')
const childSuite = Mocha.Suite.create(rootSuite, 'Child')
// childSuite.addTest('A test', function() {  require('assert').equal(true, true) })
const runner = new Mocha.Runner(rootSuite)
// const createStatsCollector = require('mocha/lib/stats-collector')
// createStatsCollector(runner)
// would be more consistent as Mocha.StatsCollector.create(runner)
const reporter = new Mocha.reporters.Spec(runner)

runner.run()

Yes, your first example is correct and you find it documented in our wiki and also in our sample repo. It's a completely different use case  since you are not trying to build a test hierarchy (runner) with nested suites by programmatic means.
Your second example: createStatsCollector is private. We will never offer a public API to use Mocha programmatically without creating a mocha instance. Btw mocha does handle statsCollector.

@juergba thanks a lot for taking the time to answer in detail, and the docs pointer.
In my use case, a static site generator reads the input to test in memory, and I needed a way to pass this data across test suites, re-using mocha's nicely formatted output, which is not possible using the .addFile  API.
I understand this is an edge case and therefore this issue can be closed.

authors: juergba webketje


text:
Compiling a simple example using cargo test panics

Using cargo test instead of cargo build for compiling a simple example panics in compiler/rustc_codegen_rmc/src/codegen/intrinsic.rs.
Steps to reproduce:

cargo new --lib foo
cd foo
RUST_BACKTRACE=1 RUSTFLAGS="-Z trim-diagnostic-paths=no -Z codegen-backend=gotoc --cfg=rmc" RUSTC=rmc-rustc cargo test --target x86_64-unknown-linux-gnu -j1

with RMC version: 02a830b8734

thread 'rustc' panicked at 'removal index (is 0) should be < len (is 0)', compiler/rustc_codegen_rmc/src/codegen/intrinsic.rs:306:64
stack backtrace:
   0: rust_begin_unwind
             at /home/ubuntu/tools/rmc/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /home/ubuntu/tools/rmc/library/core/src/panicking.rs:100:14
   2: alloc::vec::Vec<T,A>::remove::assert_failed
             at /home/ubuntu/tools/rmc/library/alloc/src/vec/mod.rs:1393:13
   3: alloc::vec::Vec<T,A>::remove
             at /home/ubuntu/tools/rmc/library/alloc/src/vec/mod.rs:1398:13
   4: rustc_codegen_rmc::codegen::intrinsic::<impl rustc_codegen_rmc::context::goto_ctx::GotocCtx>::codegen_intrinsic
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/codegen/intrinsic.rs:306:58
   5: <rustc_codegen_rmc::overrides::hooks::Intrinsic as rustc_codegen_rmc::overrides::hooks::GotocHook>::handle
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/overrides/hooks.rs:266:21
   6: rustc_codegen_rmc::codegen::statement::<impl rustc_codegen_rmc::context::goto_ctx::GotocCtx>::codegen_funcall
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/codegen/statement.rs:336:28
   7: rustc_codegen_rmc::codegen::statement::<impl rustc_codegen_rmc::context::goto_ctx::GotocCtx>::codegen_terminator
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/codegen/statement.rs:71:17
   8: rustc_codegen_rmc::codegen::block::<impl rustc_codegen_rmc::context::goto_ctx::GotocCtx>::codegen_block
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/codegen/block.rs:30:28
   9: rustc_codegen_rmc::codegen::function::<impl rustc_codegen_rmc::context::goto_ctx::GotocCtx>::codegen_function::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/codegen/function.rs:99:71
  10: core::iter::traits::iterator::Iterator::for_each::call::{{closure}}
             at /home/ubuntu/tools/rmc/library/core/src/iter/traits/iterator.rs:734:29
  11: core::iter::adapters::map::map_fold::{{closure}}
             at /home/ubuntu/tools/rmc/library/core/src/iter/adapters/map.rs:84:21
  12: <core::iter::adapters::enumerate::Enumerate<I> as core::iter::traits::iterator::Iterator>::fold::enumerate::{{closure}}
             at /home/ubuntu/tools/rmc/library/core/src/iter/adapters/enumerate.rs:106:27
  13: core::iter::traits::iterator::Iterator::fold
             at /home/ubuntu/tools/rmc/library/core/src/iter/traits/iterator.rs:2171:21
  14: <core::iter::adapters::enumerate::Enumerate<I> as core::iter::traits::iterator::Iterator>::fold
             at /home/ubuntu/tools/rmc/library/core/src/iter/adapters/enumerate.rs:112:9
  15: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
             at /home/ubuntu/tools/rmc/library/core/src/iter/adapters/map.rs:124:9
  16: core::iter::traits::iterator::Iterator::for_each
             at /home/ubuntu/tools/rmc/library/core/src/iter/traits/iterator.rs:737:9
  17: rustc_codegen_rmc::codegen::function::<impl rustc_codegen_rmc::context::goto_ctx::GotocCtx>::codegen_function
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/codegen/function.rs:99:13
  18: <rustc_codegen_rmc::compiler_interface::GotocCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/compiler_interface.rs:104:35
  19: rustc_codegen_rmc::utils::debug::<impl rustc_codegen_rmc::context::goto_ctx::GotocCtx>::call_with_panic_debug_info::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/utils/debug.rs:87:13
  20: std::thread::local::LocalKey<T>::try_with
             at /home/ubuntu/tools/rmc/library/std/src/thread/local.rs:399:16
  21: std::thread::local::LocalKey<T>::with
             at /home/ubuntu/tools/rmc/library/std/src/thread/local.rs:375:9
  22: rustc_codegen_rmc::utils::debug::<impl rustc_codegen_rmc::context::goto_ctx::GotocCtx>::call_with_panic_debug_info
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/utils/debug.rs:84:9
  23: <rustc_codegen_rmc::compiler_interface::GotocCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
             at /home/ubuntu/tools/rmc/compiler/rustc_codegen_rmc/src/compiler_interface.rs:103:25
  24: rustc_interface::passes::start_codegen::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/passes.rs:1056:9
  25: rustc_data_structures::profiling::VerboseTimingGuard::run
             at /home/ubuntu/tools/rmc/compiler/rustc_data_structures/src/profiling.rs:611:9
  26: rustc_session::utils::<impl rustc_session::session::Session>::time
             at /home/ubuntu/tools/rmc/compiler/rustc_session/src/utils.rs:16:9
  27: rustc_interface::passes::start_codegen
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/passes.rs:1055:19
  28: rustc_interface::queries::Queries::ongoing_codegen::{{closure}}::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/queries.rs:254:20
  29: rustc_interface::passes::QueryContext::enter::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/passes.rs:784:42
  30: rustc_middle::ty::context::tls::enter_context::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_middle/src/ty/context.rs:1760:50
  31: rustc_middle::ty::context::tls::set_tlv
             at /home/ubuntu/tools/rmc/compiler/rustc_middle/src/ty/context.rs:1744:9
  32: rustc_middle::ty::context::tls::enter_context
             at /home/ubuntu/tools/rmc/compiler/rustc_middle/src/ty/context.rs:1760:9
  33: rustc_interface::passes::QueryContext::enter
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/passes.rs:784:9
  34: rustc_interface::queries::Queries::ongoing_codegen::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/queries.rs:245:13
  35: rustc_interface::queries::Query<T>::compute
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/queries.rs:38:28
  36: rustc_driver::run_compiler::{{closure}}::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_driver/src/lib.rs:407:13
  37: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/queries.rs:394:19
  38: rustc_driver::run_compiler::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_driver/src/lib.rs:312:22
  39: rustc_interface::interface::create_compiler_and_run::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/interface.rs:203:13
  40: rustc_span::with_source_map
             at /home/ubuntu/tools/rmc/compiler/rustc_span/src/lib.rs:976:5
  41: rustc_interface::interface::create_compiler_and_run
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/interface.rs:197:5
  42: rustc_interface::interface::run_compiler::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/interface.rs:219:12
  43: rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals::{{closure}}::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/util.rs:145:13
  44: scoped_tls::ScopedKey<T>::set
             at /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:137:9
  45: rustc_span::create_session_globals_then
             at /home/ubuntu/tools/rmc/compiler/rustc_span/src/lib.rs:109:5
  46: rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals::{{closure}}
             at /home/ubuntu/tools/rmc/compiler/rustc_interface/src/util.rs:143:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.58.0-dev running on x86_64-unknown-linux-gnu

note: compiler flags: -Z trim-diagnostic-paths=no -Z codegen-backend=gotoc -C embed-bitcode=no -C debuginfo=2 -C incremental

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack

[RMC] current codegen item: codegen_function: std::hint::black_box
_ZN4core4hint9black_box17h6d4673120023aca8E
[RMC] current codegen location: Loc { file: "/home/ubuntu/tools/rmc/library/core/src/hint.rs", function: None, line: 157, col: Some(1) }

RMC unexpectedly panicked during code generation.

If you are seeing this message, please file an issue here instead of on the Rust compiler: https://github.com/model-checking/rmc/issues/new?labels=bug&template=bug_report.md
error: could not compile `foo`

The steps above no longer result in a panic. Instead, they result in the following error:
     Running unittests (target/x86_64-unknown-linux-gnu/debug/deps/libfoo-43614fd88c70bcf2.rlib)
error: test failed, to rerun pass '--lib'

Caused by:
  could not execute process `/home/ubuntu/examples/iss586-2/foo/target/x86_64-unknown-linux-gnu/debug/deps/libfoo-43614fd88c70bcf2.rlib` (never executed)

which is encountered when cargo test tries to run the binary that calls the tests, which obviously RMC does not produce. The workaround is to specify the --no-run option to cargo test to prevent it from trying to run the non-existing binary:
RUSTFLAGS=$(rmc-rustc --rmc-flags) RUSTC=$(rmc-rustc --rmc-path) cargo test --no-run --target x86_64-unknown-linux-gnu -j1

One can then proceed with converting the symbol tables to goto binaries, linking them, and running CBMC.

@zhassan-aws can you please update the issue to reflect what you expect? From our offline discussions, I'm assuming that you want an option for cargo rmc to allow the user to pass a test function as a proof entry point. Correct?

Correct. We can close this issue though and create a separate feature request for cargo rmc.

With #672, cargo rmc now supports a --tests option. Closing this issue.

authors: celinval zhassan-aws

repo: model-checking/rmc


text:
use assert-false instead of nondet for missing functions

Description of changes:
Currently, CBMC does nondet for missing functions, which may be unsound if they have side-effects. Instead, soundly assert false.
Resolved issues:
Resolves
Call-outs:
None of
Testing:

How is this change tested? Existing regression suite

Is this a refactor change? No

Checklist

[ ] Each commit message has a non-empty body, explaining why the change was made
[ ] Methods or procedures are documented
[ ] Regression or unit tests are included, or existing tests cover the modified code
[ ] My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

This is a tough one. I almost feel like this should be an option to how a user runs rmc or even a proof-harness.

This is used in CBMC when we run verification of larger projects where we cut off calls to functions, but do not want execution to stop. Essentially, this is part of aggressive slicing - and yes, it's known to be unsound.

authors: celinval danielsn nmanthey


text:
Tables: More precise error message if dimensions do not match

Reported by beutlich on 20 May 2014 10:18 UTC
It happened that the table dimension in a external text file was given as double tab(n1,m1) whereas it should be double tab(n2,m2) with n2>=n1 and/or m2>=m1. The Modelica Standard Tables generate an error message like "Error in line 1234 when reading numeric data of matrix "tab(n1,m1)" from file "tables.txt" which does not point to the actual problem cause when looking at line 1234. The error message should be improved such that the actual dimensional issue gets more obvious.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1494

Comment by beutlich on 21 May 2014 16:06 UTC
Resolved by b4e7b23253941d4999bd26855c983bd1dda7142a and 1c0a407278668bcba1b92022e84136ad88ef85ba.
Such a table
double tab(2,2)
0 0 1
1 2 2

will now print the improved error message whereas
double tab(2,2)
0 0 1
1 ? 2 2

gives the old error message and
double tab(2,2)
0 0 1
1
2 2

previously gave and still gives no error message at all since it might be by purpose to only read the partial table.

Modified by beutlich on 5 Jan 2015 13:19 UTC

Changelog modified by beutlich on 5 Jan 2015 13:19 UTC
Improve the error message in case of trailing numbers in external table text files of the Modelica Standard Tables

repo: modelica/Modelica


text:
🛑 XBackbone is down

In cb748a6, XBackbone ($XBACKBONE_URL) was down:

HTTP code: 403
Response time: 98 ms

Resolved: XBackbone is back up in 487388a.


text:
Avoid warnings from nmap

Hi,
when running
my( $nmapCmd ) = "/usr/bin/nmap";
my( $nmap ) = new Nmap::Parser;
$nmap->parsescan( $nmapCmd, '-n -sn', ( "192.168.1.1/24" ) );
I get lots of warning like this one:
adjust_timeouts2: packet supposedly had rtt of -102238 microseconds.  Ignoring time.
Reason seems to be "-v -v -v" in the call to nmap in Parser.pm.
Is there anything I can do against these warnings?
Thx and bye.
Michael.

Unfotunately it may not be possible as using those switches provides additional information in the XML as far as I remember.

authors: apersaud nobanzai

repo: modernistik/Nmap-Parser


text:
FEAT-#3536: Change work with native+omnisci

Signed-off-by: Maria Rubtsova maria.rubtsova@intel.com

What do these changes do?

[ ] commit message follows format outlined here
[ ] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] signed commit with git commit -s
[ ] Resolves #3536
[ ] tests added and passing
[ ] module layout described at docs/developer/architecture.rst is up-to-date

Looks much cleaner to me :)

I suggest to remove all lines above "To enable OmniSci engine launch export"

Not sure how it will look like but I would use the line To enable Omnisci engine ....

I suggest not confuse users - just mention storage format and that’s it as I already suggested earlier. For some reasons I was sure all other info was deleted but no :(

Omnisci is not a storage format only, but it is an engine as well. I think specifying omnisci storage format only will not be enough.

wait a minute... this particular PR is about it, right?. It simplifies things - we can set only storage format for Omnisci now

Yes, exactly. I am more concerned about the description in docs.

I don't get it. I suggest removing all lines that mention "engine" and "experimental" to not bother users by that information. Only about storage format which is now sufficient for work with Omnisci. Am I missing something here?

Yes, it is sufficient for work with Omnisci but I am not sure that would be clear for users because there are places where we mostly refer to Omnisci as an engine. Anyway, let's try your suggestion and will see how it looks like. @Rubtsowa, could you take a look at this?

authors: Garra1980 Rubtsowa YarShev

repo: modin-project/modin


text:
OpenUPM package

I'd love to see this package on https://openupm.com/.
Usually I would add this package myself but I don't know about your git tags.
docs: https://openupm.com/docs/adding-upm-package.html

That's currently my goal, and should be there within 24 hours!

This might take a little longer than anticipated as I'll need to look at how I incorporate the third party libraries as requirements rather than dlls. It's on my list of things to do for the start of next week.

You can reference the Unity's internal JSON library (which isn't recommended but it works): https://bintray.com/unity/unity-staging/com.unity.nuget.newtonsoft-json
You might also be able to add git references as dependencies: https://openupm.com/packages/com.coffee.git-dependency-resolver/

authors: MeikelLP Melodatron

repo: modio/UnityPlugin


text:
如何在ob中使用啊

我把外观中的主题设置为默认,
然后在笔记文件开头加入div的标签,
可以起作用
但是不能分段,要每一段都打标签吗,这样写起来太麻烦了,
有没有比较方便的设置方法

请在 obsidian 中直接下载安装就可以生效了 obsidian://show-plugin?id=heti

我就是在ob的插件市场安装了,然后好像没有设置的地方,在插件列表里有这个heti,怎么使用是最方便的呢?比如是需要没个md文件里写html标签?还是有什么更好的方法呢?

比如minimal这个主题就有配套的 minimal theme settings ,这个heti好像没有,那么一般来说怎么设置默认的样式呢?

我就是在ob的插件市场安装了,然后好像没有设置的地方,在插件列表里有这个heti,怎么使用是最方便的呢?比如是需要没个md文件里写html标签?还是有什么更好的方法呢?

实际上只需要安装并开启插件，样式就会被自动应用到所有正文页面，并不需要额外的操作，也不需要更改你的主题。但是因为 heti 本身并没有配置项，所以插件也没有任何可配置选项。
如果想要确认是否已经生效可以在 Inspect 中选中任意一段文字查看是否有 heti 相关的样式在生效，比如：

我就是在ob的插件市场安装了,然后好像没有设置的地方,在插件列表里有这个heti,怎么使用是最方便的呢?比如是需要没个md文件里写html标签?还是有什么更好的方法呢?

实际上只需要安装并开启插件，样式就会被自动应用到所有正文页面，并不需要额外的操作，也不需要更改你的主题。但是因为 heti 本身并没有配置项，所以插件也没有任何可配置选项。
如果想要确认是否已经生效可以在 Inspect 中选中任意一段文字查看是否有 heti 相关的样式在生效，比如：

不需要手动添加html标签吗？好像没有效果啊

Obsidian 的编辑模式没有使用标准的 HTML 标签，因此只有在阅读模式下才可以看到正确的样式。
可以尝试在 view -> Toggle Developer Tools -> Elements 中选中任意正文元素（例如标题）查看是否 heti 的相关样式生效。

authors: Edwardvi moeyua

repo: moeyua/obsidian-heti


text:
🛑 STATUS.MOFE.IO is down

In 6ea5eb7, STATUS.MOFE.IO (https://status.mofe.io) was down:

HTTP code: 0
Response time: 0 ms

Resolved: STATUS.MOFE.IO is back up in d3cb5d8.

repo: mofelee/upptime


text:
Added Hyp Function 3 description to Comp Spec

@ekrolen I am not stealing your thunder by having an output of my function be a line chart for the "numerators" of my proportions, right? I just wanted to make sure since Hypothesis Function 2 will also be outputting line charts.

No problem - I think if it makes sense for both tests it should be done for both tests!

authors: ekrolen logan-obrien


text:
Deprecated rb_thread_select removed from trunk.

Hi there! I wanted to report that I'm having some trouble with God (hah) and the Ruby 2.2 previews. Trying to invoke the executable, I get messages like this:
ruby /usr/local/rvm/gems/ruby-head@global/bin/god -c /etc/sidekiq_manager.god -D: symbol lookup error: /usr/local/rvm/gems/ruby-head@global/gems/god-0.13.4/ext/god/netlink_handler_ext.so: undefined symbol: rb_thread_select

I think rb_thread_select was deprecated, and has finally been taken out of trunk, based on reports from EventMachine users and developers (e.g., eventmachine/eventmachine#495). Thought it might be something worth looking into before the next official release.
Thanks so much for your work on this totally invaluable gem, and take care!

I'd like to confirm the problem with god 0.13.1
but it is gone with god 0.13.6
ruby 2.2.2p88 (2015-03-25 revision 50085) [x86_64-linux]
Linux *** 2.6.18-028stab101.1 #1 SMP Sun Jun 24 19:50:48 MSD 2012 x86_64 x86_64 x86_64 GNU/Linux

authors: eiked phyllisstein

repo: mojombo/god


text:
Update the for and id field attributes with the form field name so yo…

Hi @mokhosh
First of all, thanks for this package!
I need multiple star rating form fields on the same form but that is not possible at the moment because the for and id attribute are always star-1 for exmple so you haven the same for and id's at different star rating fields.
Create a fix where I add the form field name before the for and id to prevent this.

Thanks!

repo: mokhosh/filament-rating


text:
Any news regarding packagist integration

It should really be quite simple to add it and would make installations through composer easier.
see old issue: https://github.com/mollie/Shopware6/issues/41

hi. do you mean this one? https://packagist.org/packages/kiener/mollie-payments-plugin

Hi @boxblinkracer not sure why but for some reason I missed it when searching the last time.
Probably because I was searching for a different vendor name mollie. The name mollie/shopware6-plugin or similar would probably be better but not sure how much effort such a rename would be and if it is worth the effort.

hi
perfect
that name was set before we started to maintain the plugin. its indeed not a perfect one and we already discussed a change, but phu...kinda risky :)
would still be great to have it changed and branded as "mollie"

authors: AndreasA boxblinkracer


text:
当MLLinklabel添加单击事件UITapGestureRecognizer的时候，导致didClickLink失效

你好，类似微信朋友圈回复评论，点击评论者名字可以促发didClickLink:linkText:linkLabel:，然后点击整条评论，希望促发回复评论的事件，但是如果在当MLLinklabel添加单击事件UITapGestureRecognizer的时候，就会导致didClickLink:linkText:linkLabel:失效了，无奈我添加了一个- (void)didClickOther:(MLLinkLabel*)linkLabel;事件，在下面调用，让他点击其他地方响应。
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
    if (self.activeLink) {
        NSString *linkText = [self.text substringWithRange:self.activeLink.linkRange];

        //告诉外面已经点击了某链接
        if (self.activeLink.didClickLinkBlock) {
            self.activeLink.didClickLinkBlock(self.activeLink,linkText,self);
        }else if (self.didClickLinkBlock) {
            self.didClickLinkBlock(self.activeLink,linkText,self);
        }else if(self.delegate&&[self.delegate respondsToSelector:@selector(didClickLink:linkText:linkLabel:)]){
            [self.delegate didClickLink:self.activeLink linkText:linkText linkLabel:self];
        }

        [self performSelector:@selector(setActiveLink:) withObject:nil afterDelay:self.activeLinkToNilDelay];
    } else {
        if(self.delegate&&[self.delegate respondsToSelector:@selector(didClickOther:)]){
            [self.delegate didClickOther:self];
        }
        [super touchesEnded:touches withEvent:event];
    }
}

不知道作者有没有更好的方法？如果有麻烦更新代码下。

https://github.com/molon/MLLabel/issues/33

repo: molon/MLLabel


text:
moment.locale() throws TypeError

I am using moment,js as a bootstrap datimepicker dependency. Unfortunately am getting
TypeError: undefined is not a function in the console which ultimately prevents the datetimepicker from working correctly. Can you please have a look at this?. Thanks
p.s. I am using gem momentjs-rails for Rails which implements moment.js version 2.9.0.

I know this is a super old ticket (I just drop by every once a while, and it looks like the other contributors have been busy too), but we'd need a jsfiddle to have much chance of helping you.

Closing for now.  If you can show us your implementation in a jsfidle, let us know and we'll reopen.

authors: ewamarciniak icambron mj1856

repo: moment/moment


text:
.diff(x, 'days') doesn't seem to use 24 hour days

Description of the Issue and Steps to Reproduce:
There seems to be handling for DST that causes .diff to fail when used with days as units
Please include the values of all variables used.
> a = moment("2017-10-30T00:00:00Z")
> b = moment("2017-10-29T00:00:00Z")
> a.diff(b, 'hours')
24
> a.diff(b, 'days')
0
>

Environment:
OS X timezone CET
node v6.11.3
> console.log( (new Date()).toString())
Mon Oct 30 2017 17:59:49 GMT+0100 (CET)
> console.log((new Date()).toLocaleString())
10/30/2017, 5:59:49 PM
> console.log( (new Date()).getTimezoneOffset())
-60
> console.log(moment.version)
2.19.1

I don't see this mentioned in the documentation, but it looks like the diff for days is operating against local time instead of absolute time.  The local time for your first moment is something like 29th Oct at 2AM, and the second moment is 30th Oct at 1AM.  These look like they're less than 1 day apart in local time.
If you want the result of a diff to use 24 hour units instead of variable-length days (23..25 hours) I think it's more reliable to use foo.diff(bar, 'hours') / 24.
I think the documentation for diff would benefit from explicitly discussing how days are treated (as it already calls out the special behaviour for month and year diffs.)

The relevant documentation isn't linked to in all the right places, but it's here.

authors: ashsearle icambron kalleaaltonen


text:
Types are broken

 const Redis = new MomentoRedisAdapter(
        new CacheClient({
          configuration: Configurations.Laptop.v1(),
          credentialProvider: CredentialProvider.fromEnvironmentVariable({
            environmentVariableName: "MOMENTO_AUTH_TOKEN",
          }),
          defaultTtlSeconds: 3600,
        }),
        "myMomentoCache",
      );

hi @0xMALVEE ! Thanks for the bug report.
This error message looks like you might have 2 different versions of the momento nodejs SDK installed; perhaps you have one listed directly in your package.json file, and one that you are getting transitively from momento-node-ioredis-client?
Can you share your package.json file, or the dependencies part of it? I believe this problem should be resolved if you ensure that you've installed the same version of the momento nodejs sdk that the ioredis client depends on.
We will also try to make a few changes to make this setup experience work a little better, but please let us know if that resolves it!

@cprice404

So, node-ioredis-client currently has a strict dependency on @gomomento/sdk v1.77.0:
https://github.com/momentohq/momento-node-ioredis-client/blob/e6999d0f17cff273ec513bc05d8f27108abad6a1/package.json#L23
Having two different versions of the sdk module will cause the errors you are sharing. You can try changing the dependency in the package.json file to 1.77.0 instead, I believe that will fix it.
In the meantime we will also look into relaxing this dependency constraint to prevent this issue, and maybe we can also re-export the necessary things from the sdk package so that you don't need to express an explicit dependency on it.
Let me know if pinning to 1.77.0 works for now though!

repo: momentohq/momento-node-ioredis-client


text:
requirejs

Thank you for this nice module. Can you please advice how to use it with require.js. In my case console always show:
"Module 'dateTimePicker' is not available! You either misspelled the module name or forgot to load it. If registering a module ensure that you specify the dependencies as the second argument."
I checked all paths and it correct.
paths: {
    ...
    'angular-material': '../bower_components/angular-material/angular-material',
    'moment': '../bower_components/moment/min/moment-with-locales.min',
    'datepicker': '../bower_components/smDateTimeRangePicker/dist/sm-picker-min'
},

// Add angular modules that does not support AMD out of the box, put it in a shim
shim: {
  'angular-material':['angular','angular-animate','angular-aria'],
  'datepicker': ['angular', 'moment']
}

...
define([
'angularAMD',
'angular-material',
'moment',
'datepicker',
], function (angularAMD) {
var app = angular.module("app", ['ngMaterial', 'smDateTimeRangePicker']);
return angularAMD.bootstrap(app);
});

Hi I think its fixed now, i just pushed new commit with version 0.0.7b,
Problem was not with your code but my source code, yesterday i committed incorrect files.
http://plnkr.co/edit/2ePb5nf8vH71iH5byP7q?p=preview

Thanks! It works now, but I dont understand, how to define moment in my case.
I receive: "ReferenceError: moment is not defined". Can you advice, please, how to add moment in my requirejs configuration?

I have never worked with  requirejs. Please follow the documentation from momentjs.
http://momentjs.com/docs/#/use-it/require-js/
this should help you out.

Got it. Just added:
var moment = require('moment');
at the top of sm-picker-min.js
'use strict';
var moment = require('moment');
function run($templateCache){........
Thank you again for your great work. I guess its the best datetimepicker for angular material.

repo: mominsamir/date-time-picker


text:
🛑 haccp is down

In 89c6b81, haccp (https://www.haccp.or.kr) was down:

HTTP code: 400
Response time: 896 ms

Resolved: haccp is back up in 36bae5b after 17 minutes.


text:
准备用MLN实现lua文件更新

但是使用和查看demo比对发现，加载的是本地bundle文件，貌似静态文件不支持修改，也没有发现demo中关于该部分的代码，请问MLN是否支持本地bundle文件中部分文件比对更新呢？如果有，麻烦指点一下如何更新

我理解应该是问热更新问题，MLN可以很方便的做到热更新。demo把lua文件放到了bundle里实际你可以像存储普通文件一样把lua文件放任意位置。

authors: jerrykill yp-mon

repo: momotech/MLN


text:
[Merge] MONDO:0000170 and MONDO:0010303

Mondo term (ID and Label)
microphthalmia, isolated, with coloboma and colobomatous microphthalmia
Reason for deprecation
microphthalmia, isolated, with coloboma seems to be based on the phenotypic series, which seems to have the same children as colobomatous microphthalmia.  If there is no distinction, would you consider a merge?
Also, please consider having full names as the preferred labels for MCOPCB1 and MCOPCB2

Term to be merged with
Your nano-attribution (ORCID)
If you don't have an ORCID, you can sign up for one here

Thanks @maglott I'll send this to the users list and hope to get to this soon.

Thanks @maglott I'll send this to the users list and hope to get to this soon.

authors: maglott nicolevasilevsky

repo: monarch-initiative/mondo


text:
[NTR] grouping class: metabolic disease, endocrine system disease, or autoimmune disease

Preferred term label:
metabolic disease, endocrine system disease, or autoimmune disease
Definition (free text, please give PubMed ID, if applicable, in format PMID:#######)
A disease or disorder that is a metabolic disease, endocrine system disease, or autoimmune disease.
Parent term (use OLS, or your favorite ontology browser)
'disease or disorder'
Children terms (if applicable) Should any existing terms that should be moved underneath this new proposed term?

metabolic disease MONDO:0005066
endocrine system disease MONDO:0005151
autoimmune disease MONDO:0007179

Note
I mentioned this to @mellybelly on Skype. This is needed for the INCLUDE data coordinating center, to annotate the diagnosis "Other metabolic, hormonal, or autoimmune condition(s) diagnosed"
cc @mellybelly @cmungall @sabrinatoro @pnrobinson @lopierra

We decided this was no longer needed. We don't love adding upper union classes in an ontology


text:
Allow to include from different parts of the same page

Using the same start and end arguments, allow to include multiple times from the same page. Closes #50

Pull Request Test Coverage Report for Build 912117756

23 of 23 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 903950561:
0.0%

Covered Lines:
157

Relevant Lines:
157

💛  - Coveralls

authors: coveralls mondeja

repo: mondeja/mkdocs-include-markdown-plugin


text:
Update plugin.py

Handle case where item is a Section.
AttributeError: 'Section' object has no attribute 'file'

Pull Request Test Coverage Report for Build 928166658

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 88.143%

Totals

Change from base Build 926456783:
0.05%

Covered Lines:
394

Relevant Lines:
447

💛  - Coveralls

Released in v0.0.13.

authors: ali1rathore coveralls mondeja

repo: mondeja/mkdocs-mdpo-plugin


text:
Change message ephemeral

Changed all statements by Auriga to EphemeralMessage.
I considered refactoring as well, but since the differences would be significant, I decided to limit the changes to the above for now
https://moneyforward.slack.com/archives/C03CB6NF2G6/p1720156080683339

@sho0126hiro 🙏

repo: moneyforward/auriga


text:
the error screen is displayed after login

I'm using authMode is PKCE. iOS Version is 6.3.0。
After logging in, an error screen appears, As for this phenomenon, where am i missing setting?
thanks for help me.

@awe-mt
thanks for your help.
The following code
let configuration = MTLConfiguration()
configuration.environment = .staging
configuration.scopes = [
            MTLClientScopeGuestRead,
            MTLClientScopeAccountsRead,
            MTLClientScopeTransactionsRead
]
let mtLinkClient = MTLinkClient(configuration: configuration)

I need to set any other values？

Thank you. We will investigate and try to get back to you early next week.

@awe-mt
Hi team,
Do you have any progress?

@zzpmaster We have updated a misconfiguration for your client and you should be able to login with the SDK. Could you please try again? Thank you.

@zzpmaster We have updated a misconfiguration for your client and now you should be able to login with the SDK. Could you please try again? Thank you!

@awe-mt
Thanks so much!
After clicking the login button, it keeps showing the loading icon.  After dozens of seconds, the loading icon disappears and the page does not jump. Need to update the SDK？

@zzpmaster With the configuration of the SDK you previously shared, I could not reproduce this problem. Is this still happening on your side?

@mt-erik
it works very well. Thanks so much!  Worked like a charm. You are a legend.

authors: awe-mt mt-erik zzpmaster

repo: moneytree/moneytree-link-ios-sdk