If swarm load balance support ip-hash or other load balance strategy ？

when i do rolling update. the same user visit the site the new release in one request and other request get old release.(due to swarm round-robin). is there any solution for this problem?

This issue is for https://github.com/docker/swarmkit not the old standalone Swarm.


Connection create success depends on when I call uv_run()

Im trying to create connection using AMQP::LibUvHandler. like this:
connection.reset(new AMQP::TcpConnection(this, address));
this function is called in thread of object that implements override functions of TcpHandler like onConnected, onClosed, etc.
Everything works when connection is made like in example:
            connection.reset(new AMQP::TcpConnection(this, address));

            AMQP::TcpChannel channel(connection.get());

            // create a temporary queue
            channel.declareQueue(AMQP::exclusive).onSuccess([&](const std::string &name, uint32_t messagecount, uint32_t consumercount) {

                // report the name of the temporary queue
                Logger::Instance()->log_warn("queue {}", name);
            });
            uv_run(uv_default_loop(), UV_RUN_DEFAULT);

AMQP::onConnected() callback is called and in RabbitMQ interface I see queue being created, but AMQP::onReady() never called...When is it called?
But when I move uv_run(uv_default_loop(), UV_RUN_DEFAULT); to other places(like before connection is created, but LibUvHandler already was initialized) or simply remove channel-queue creation:
connection.reset(new AMQP::TcpConnection(this, address));
uv_run(uv_default_loop(), UV_RUN_DEFAULT);

even AMQP::onConnected() is not called.
I never used libuv before so I dont understand how it works under the hood, but I was under impression once events to watch were added into loop by LibUvHandler instantiation I can call uv_run(). May be calling other methods like channel creation adds additional events to watch? And if I do not do it before calling uv_run() then uv cycle is finished before those events are added to watch list? So may be whenever I add a channel or queue I need to run uv_run() everytime just to be safe?
EDIT:
I am trying to implement reconnection pattern to rabbitmq via conditional variable, so firstly Im trying to create connection:
connection.reset(new AMQP::TcpConnection(this, address));
then I wait for it to report in onReady() that everything is cool so I can proceed but even onConnected() never called. And after connection would be established I would proceed to channel-queue creation and messaging. I was imagining that if connection is not created onError() would be called, so I can put thread to sleep and try again in 5 seconds. But onError() also never called, after initial single call to monitor() nothing gets called.

Can you provide a working and minimal test program that demonstrates the issue without threads?

No that is not the problem. The problem is that you run your loop in a different thread than the AMQP connection.

Right now it works in different threads. UV loop is running in one thread, and AMQP is initialized and being run in the other.

Which is wrong.

This is not informative. Why is this wrong? UV loop doesnt really care which thread it occupies, also it shouldnt care who tells him which events to watch, my understanding is this. And it works. It didnt worked in same thread, nor in different threads, unill I added entity that allows uv loop run indefinitely. So far my understanding is this, Im not amqp/libuv developer so If you can correct me, I would appreciate that.
Here is working example taken from examples:
    auto *loop = uv_default_loop();

    // handler for libev
    MyHandler handler(loop);

    // make a connection
    AMQP::TcpConnection connection(&handler, AMQP::Address("amqp://nexcityapi:asdfg23SFva@<IP_ADDRESS>:6056/"));

    // we need a channel too
    AMQP::TcpChannel channel(&connection);

    // create a temporary queue
    channel.declareQueue(AMQP::exclusive).onSuccess([&connection](const std::string &name, uint32_t messagecount, uint32_t consumercount) {

        // report the name of the temporary queue
        std::cout << "declared queue " << name << std::endl;
    });

    // run the loop
    uv_run(loop, UV_RUN_DEFAULT);

queue name is printed.
Here is example I tried to implement:
    auto *loop = uv_default_loop();

    // handler for libev
    MyHandler handler(loop);

    // make a connection
    AMQP::TcpConnection connection(&handler, AMQP::Address("amqp://nexcityapi:asdfg23SFva@<IP_ADDRESS>:6056/"));

    uv_run(loop, UV_RUN_DEFAULT);

    // we need a channel too
    AMQP::TcpChannel channel(&connection);

    // create a temporary queue
    channel.declareQueue(AMQP::exclusive).onSuccess([&connection](const std::string &name, uint32_t messagecount, uint32_t consumercount) {

        // report the name of the temporary queue
        std::cout << "declared queue " << name << std::endl;
    });

single thing printed "connected", program gets stuck.

This is not informative. Why is this wrong? UV loop doesnt really care which thread it occupies, also it shouldnt care who tells him which events to watch, my understanding is this. And it works. It didnt worked in same thread, nor in different threads, unill I added entity that allows uv loop run indefinitely. So far my understanding is this, Im not amqp/libuv developer so If you can correct me, I would appreciate that.
Here is working example taken from examples:
auto *loop = uv_default_loop();

// handler for libev
MyHandler handler(loop);

// make a connection
AMQP::TcpConnection connection(&handler, AMQP::Address("amqp://"));

// we need a channel too
AMQP::TcpChannel channel(&connection);

// create a temporary queue
channel.declareQueue(AMQP::exclusive).onSuccess([&connection](const std::string &name, uint32_t messagecount, uint32_t consumercount) {

    // report the name of the temporary queue
    std::cout << "declared queue " << name << std::endl;
});

// run the loop
uv_run(loop, UV_RUN_DEFAULT);

queue name is printed.
Here is example I tried to implement:
auto *loop = uv_default_loop();

// handler for libev
MyHandler handler(loop);

// make a connection
AMQP::TcpConnection connection(&handler, AMQP::Address("amqp://"));

uv_run(loop, UV_RUN_DEFAULT);

// we need a channel too
AMQP::TcpChannel channel(&connection);

// create a temporary queue
channel.declareQueue(AMQP::exclusive).onSuccess([&connection](const std::string &name, uint32_t messagecount, uint32_t consumercount) {

    // report the name of the temporary queue
    std::cout << "declared queue " << name << std::endl;
});

single thing printed "connected", program gets stuck.

Where is the thread that you were talking about?

here is crude example:
void uv_TimerCallback(uv_timer_t* handle)
{

}

uv_timer_t timer_req;

void ThreadProc()
{
    uv_timer_init(uv_default_loop(), &timer_req);
    uv_timer_start(&timer_req, uv_TimerCallback, 5000, 2000);
    uv_run(uv_default_loop(), UV_RUN_DEFAULT);
}

int main(int argc, char *argv[])
{
    auto *loop = uv_default_loop();

    std::thread m_thread = std::thread(&ThreadProc);

    // handler for libev
    MyHandler handler(loop);

    // make a connection
    AMQP::TcpConnection connection(&handler, AMQP::Address("amqp://"));

    // we need a channel too
    AMQP::TcpChannel channel(&connection);

    // create a temporary queue
    channel.declareQueue(AMQP::exclusive).onSuccess([&connection](const std::string &name, uint32_t messagecount, uint32_t consumercount) {

        // report the name of the temporary queue
        std::cout << "declared queue " << name << std::endl;
    });

    if(m_thread.joinable())
				m_thread.join();
     return 0;
}

also prints queue name.

Remember: AMQP objects are not thread safe. You cannot call methods on the objects from multiple threads because you will sooner or later run into crashes, race conditions, unexpected behavior, etcetera. Just like you will run into problems if you start writing to the same file from multiple threads, or to the same memory buffer, you can also not use AMQP connections from multiple threads.
Your MyHandler class lives in the std::thread thread.  This is all good if you do not make other access the Connection class in other threads too.
And here is the problem: in the main() function of the program, which is a different thread(!), you construct a channel, you call channel.declareQueue() and so on. This is wrong. Because now you use the connection in two threads at the same time.
Maybe it works for you in a test environment, because of pure luck. But in the longer run, if you run this in production, and give it some real load, it will eventually crash or freeze or break or do other nasty things.

I see. Thank you for reply. So my setup currently this: I was planning on having one thread for AMQP where Im initializing connection, channels, queue, etc, and after everything is done just putting thread on conditional variable that wakes up thread if connection is lost to try to reconnect. Second thread is uv loop. That's it.
I've looked at the code and it appears only place where uv loop interacts with AMQP is void TcpConnection::process(int fd, int flags)  which accesses AMQP::TcpState  which is called as uv loop callback in uv loop thread.
Apparently this isnt thread safe?
This leaves me confused to be honest. UV loop occupies whole thread, and after initialization of AMQP connection (when onReady is called and I created a channel) I have no way of communicating with AMQP besides uv loop. For example, if outside of AMQP-UV thread I'll decide I need to create new channel/queue, how I should go about it? I will need to add new event to loop with a callback "create_new_channel"? This is intended way of communication with AMQP objects?

Don't use threads.. Don't do it. Use the event loop to run your entire application. And if you can't modify your application to have a single event loop, run all the AMQP stuff in a separate thread, and use mutexes or so to hand over work items (like publish-operations or consumed messages) from one thread to the other. But stay far away from even trying to access the AMQP objects from multiple threads at the same time. They are, like almost all C++ objects, not thread safe by design, so don't even try to access them from multiple threads.
And even when you do a deep-inspect of the AMQP-CPP code and think 'well if I do it like this it might just work because I see how it is implemented' you should still not do it. Don't break the encapsulation principle by assuming a certain behavior of AMQP-CPP. The objects are not thread safe. Period.

I obviously would wrap access to defined by me AMQP objects in mutex guard. The thing Im interested whether I should modify uv callback that uses connection to notify AMQP about change in filedescriptors readablity/writeability in mutex too if I will be accessing any other AMQP object that potentially uses connection from outside thread(like creating channel).

"The thing Im interested whether I should modify uv callback that uses connection to notify AMQP about change in filedescriptors readablity/writeability in mutex too"
Answer: no this is not necessary. You don't have to use mutexes here because you will (of course) run the event loop in the same thread as the rest of the AMQP code, so there is no need to mutex-protect this.
Watch out: it is very important to not use threads!

All right, thank you.


Cache the redirect urls

From what I can tell in the code, the redirect URLs aren't stored. Since the images are immutable, why not cache those for let's say a week, so the loadbalancer can just serve those requests from memory for popular images

Ah I see you set an expire date on the image at Amazon. Maybe make that configurable but also save it in the storage so you can tell everyone requesting the resource the link is valid until then.

Well, its immutable anyway. This only ensures that an image receives a request once per month. the redirect rules are saved to the SQLite database, and the image resources should live forever anyway


Adding campaign tracking code to the video link

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

#sign-off

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


prevent liquid tags from being displayed in PDF

I'm using asciidoc to write content for a jekyll docs site and to create PDFs of some pages for specific customers.
Occasionally, for Jekyll, we need {% raw %} liquid tags around code blocks when {{s  are used in code examples, to prevent Jekyll from thinking those {{s are Liquid.
The problem is these {% raw %} tags are being displayed in the PDF text.
Just wondering if there's a way around this - applying a tag of some sort to the tags (🙃 ) to tell asciidoctor-pdf not to include them is my main thought right now.
I guess there's no way to render the Liquid prior to the PDF being generated...
Thank you!

My only suggestion would be to hide them inside of preprocessor conditionals:
ifdef::env-site[{% raw %}]

I guess there's no way to render the Liquid prior to the PDF being generated...

These are different technology stacks (Asciidoctor PDF doesn't know anything about Liquid), so no, not with Asciidoctor PDF. You could consider making a PDF from the HTML using a different tool. Then it could work.


can only process 64kBit streams

I have build this project with NODEMCU 0.9 and VS1053 without a TFT.
But only 64kBit streams are processed properly. With faster streams the tone is unclear.
What to do?

Please give the URL of a failing stream.  Can you check if this stream works on a Windows machine?

I have tried many - alwas the same error. So, it is not a matter of one URL only.
I can hear voices from faster streams but it is not understandable.
Furthermore it seems that volume controll doesn't work or the output signal is extrem stong.
I use the VS1053B. Are the control commands different to the VS1053?

Please give the URL of a failing stream. Can you check if this stream works on a Windows machine?

I use the standard radio.ini and replaced item 6 and 7 with 64kbit streams. Those work any other not.
I think the problem comes from signal XSC. Because when I connect it as proposed - nothing happen. When I tie XCS with 10 K to GND then 64 kbit work. It seems - control commands are not accepted.

Remove the reset circuit (the 2 diodesand the 1 k resistor).  Then tie the RST pin of the VS1053 to the RST of the NodeMcu or with a pull-up resistor to +3.3V

Ok, I made the modifications, but without no success.
I attached 2 screenshots measured with my slow logic analyzer.

Yes, XCS seems to be the problem.  It should be low during the clockpulses.


Can I use regular tailwind styles?

I have some code that looks like this, but it renders like this, aka it doesn't render any of my normal tailwind classes. Is this to be expected or do I have something misconfigured?
(globals.css is being imported into layout.js) (thanks for your work)

my tailwind config wasn't looking at my js components. sorry, thanks again!


Deploy to Web App

Does this occur consistently?
Repro steps:

Action: appService.Deploy
Error type: Error
Error Message: Task not found
Version: 0.16.5
OS: darwin
OS Release: 18.7.0
Product: Visual Studio Code
Product Version: 1.45.0
Language: en

Call Stack
file:/workbench.desktop.main.js:4010:286
processTicksAndRejections task_queues.js:85:5

@guillermobadia please add repro steps


Beresheet

With the move to Hardhat. This branch is very out of date and full of merge errors. So closing this

Replacing the the non Edgeware changes with https://github.com/joinzien/scarce-editions/pull/45


Arduino code for IR sensor on Lateral Suspension

Description
This is the initial Arduino code for counting the wheel revolutions on a lateral suspension wheel. A signal is sent to the BBB every time an input is received by one the IR pins.
Click up link
Changes

IR sensor pin takes an input
Output is sent to BBB.

Additional Info
screenshots, commands to run etc.

Codecov Report

Merging #107 (233dc8a) into master (2ba617f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #107   +/-   ##
=======================================
  Coverage   30.32%   30.32%
=======================================
  Files          68       68
  Lines        3680     3680
=======================================
  Hits         1116     1116
  Misses       2564     2564

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2ba617f...233dc8a. Read the comment docs.

@kshxtij and I spent some time trying to get the arduino to work. Most things failed, the strings method works for now; so committing this while we keep experimenting.

Replaced by #120.


1619 emission intensity calculated field diffs

ZH CARD 1619

Actually, one more thing, I was able to reproduce that bug where the diffs don't show. I've filled out adjusted:

But don't see it here:

One further suggestion I didn't think of before--we could add Adjusted GHG in the cypress test so it shows up in the happo shots. Right now it shows up when creating a project but not in the diffs:  (I think the spacing in the summary has always been a bug)

I've added that to e2e tests. and yes, that spacing issue exists for a long time.


Dropdowns

Add support for dropdown sockets. Sockets with dropdowns have a black arrow next to them; the menu is brought up when the arrow is clicked. Otherwise, the socket can be typed in normally.
Specified through modeOptions by adding a "dropdown" property to a function description object, like
"pen": {
  dropdown: [
    {text: 'red', display: 'red'}
    {text: 'blue', display: 'blue'}
  ]
}

This display property can be arbitrary HTML.

The description of the config in the PR isn't accurate any more: you now map from position to a list of strings (maybe it's an option to map to objects with HTML, but it's not tested).
Can you

Add a quick test that exercises a non-zero arg index, and an HTML menu.
Add documentation to embedding.md describing how to do it.

Looks great!


Time picker flow doesn't work after complete

Describe the bug
I use the time picker mode & set the flow to [hours, minutes], then I conditionally set the flow value based on the time picker value & what overlay is being opened. When the first flow is being proceed for the first time, the flow is working properly. On my case, it will directly open the hours overlay, then the minutes overlay. But after it, if I open the hours overlay again, it doesn't move to the minutes overlay
To Reproduce
Steps to reproduce the behavior:

Go to Reproduction
Click the input, it will open the hours overlay directly
Pick an hour, then it will open the minutes overlay
Pick a minute, then it will close the minutes overlay and back to the time overlay (display with hours, minutes, and up & down button)
Click the hours button, then pick an hours

Expected behavior
After the step 5, the expected behavior is to open the minutes overlay, because the flow is still [hours, minutes]
Screenshots
https://github.com/Vuepic/vue-datepicker/assets/21327758/66a798d8-6a45-4b47-a3cf-4065ff3999cd
Desktop & mobile (please complete the following information):

Browser [e.g. chrome, safari]
Library version: 8.6.0

This is expected behavior, because flow is only triggered on the mount. I'll expose a method to re-trigger it.


MSI Memory HCL: ERROR: Vendor BIOS HCL

@pietrushnic I managed to extract a Memory report for the Z690-A motherboard, which I committed here, using the find . -name "Micro-Star_International_Co.,_Ltd._MS-7D25*.tar.gz" -print0 | xargs -0 -n1 bash -c './dts-hclmgr memory "$0"'
However, the only thing I get for the Z790-P motherboard is:
ERROR: Vendor BIOS HCL
ERROR: Vendor BIOS HCL
ERROR: Vendor BIOS HCL
ERROR: Vendor BIOS HCL

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
ERROR: Vendor BIOS HCL
ERROR: Vendor BIOS HCL
ERROR: Vendor BIOS HCL
ERROR: Vendor BIOS HCL
ERROR: Vendor BIOS HCL
ERROR: Vendor BIOS HCL

So no results and lots of errors. Does this mean that there are no reports for this motherboard?

It may be a bug, but I was generating those reports in the past. I will look into that when I find time.


[Improvement] ToIcebergPartitionSpec.java missing private constructor

What would you like to be improved?
Utility classes should have private constructors.
How should we improve?
Add private constructor.

Will be working on this one.


Stylistic issues

prefer underscore convention to camel case R/featureExtractionFunctions.R
avoid unnecessary spacings in docstrings
standardize jargon when talking about the feature extraction process
check style using lintr

Thank you @philerooski for assigning this to yourself 👍


Add user role for referee admin

On a region level a new role is required that allows to download/import region games and add/modify referees.
No other regional ability is required

check if really required


Installation issues

Hi,
Thanks for making this tool available for KNIME. 2 Things:

in order to be able to install the nodes I had to unzip the ZIP file first
after this I get the following error when trying to install in KNIME 5.2.5

An error occurred while installing the items session context was:(profile=KNIMEProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]at.ac.univie.pharminfo.molcompass.channel.bin.win32.x86_64 <IP_ADDRESS>407021015, action=org.knime.product.p2.actions.ShellExec). ShellExec command exited non-zero exit value:
Any ideas?
BW/Evert

Hi Evert,
I have not tested it under Windows with this version of KNIME. I will check it next week.


[MAS1.4.3] [Visual Requirements- Add language understanding] Luminosity Ratio is less than 4.5:1  for “add a LUIS app manually “ link present in the LUIS application  dialog

Actual Result:
Luminosity Ratio is less than 4.5:1  for “add a LUIS app manually “ link present in the LUIS application  dialog
Expected Result:
Luminosity Ratio should be greater than or equal to 4.5:1 for “add a LUIS app manually “ link
Note: Same issue repro for below path
Bot Explorer->Services->+symbol->Add QnA maker
Please refer the attachment:MAS1 4 3_Qna maker.png
Bot Explorer->Services->+symbol->Add Dispatch
Please refer the attachment:MAS1 4 3_Add a Dispatch.png
Repro Steps:
1.Open the Bot Framework V4 Emulator.
2.Navigate to the bot explorer and select it
3.Navigate to the services symbol and select it
4.Navigate to the Add Language understanding(LUIS) and select it
5.Dialog gets opened
6.Open 'Colour Contrast Analyser' application.
7.Verify whether Luminosity Ratio is less than 4.5:1 for “add a LUIS app manually “or not
User Impact:
Users with low vision or colour blindness needs that difference between contrast of link is always high.
Test Environment:
OS Build: Version 1903(OS Build 18362.239)
Application: Bot Framework V4 Emulator
Tool: Colour contrast analyser
MAS Reference Link:
https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/WopiFrame.aspx?sourcedoc={a73546c7-765f-489c-b18f-afb659fe99e6}

This was fixed in #1828


Alpine Expression Error: "filteredItems()"

We're getting the following error when upgrading from Livewire 2 to Livewire 3. It only happens for commands that have a dependency, i.e., you press the first item, try to search in the dependency list, and the error is thrown. The published view has not changed.

I have the same issue here 👋🏻

same here


JCL-335: issue request builder & grant approval calls

The names are at the moment taken form the JS library:

Request issueAccessRequest
CompletionStage approveAccessRequest
We can of course rethink the names.

The issueAccessRequest has a toCompletableFuture().join() now, not sure.

I know we discussed removing the extra class but that would require me to pass Map<String, Object> around. Because of this, I try here to create more architecture.
Is it going in the right direction?

Superseded by #461


Voice "SDK"

[ ] add voice.ts to the SDK
[ ] add createsource method to fixie client
[ ] remove need to pass init...make optional
[ ] plumb API key from client through to voice service


[Enum Request] Field Status in RoutingHeader, RoutingVersion, ProdBomHeader, ProdBomVersion

Please make the field "Status" in tables RoutingHeader, RoutingVersion, ProdBomHeader, ProdBomVersion an enum, we would like to use the same enum for our apps.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Accept the language as optParam

Is your feature request related to a problem? Please describe.
I want to use the MapsPlaces API with your php-client, but I need the response text in german. In the official API documentation is written, that you can use the language parameter to change the language of the response, but if I want to use it with your client, an error is thrown that this parameter is unknown.
Describe the solution you'd like
Please add the language parameter to the accepted optParameters.
https://developers.google.com/maps/documentation/places/web-service/details?hl=de#language
Thanks in advance :)

can be closed after investigation I found out that the language can be set with languageCode. Maybe you could update the documentation or i didn't found it :D
Thanks anyways


Extend emulateNetwork to accept custom objects

We have a few cases where we want to customize what throughput/latency values we want to use. With this PR, we can either use the preset values already present in Taiko, or supply an object that fits Chrome Dev Tools' needs. Hopefully this is still within the spirit of the repository, let us know if there are any changes you'd like us to make!

Thanks for the PR!
Is {offline: true|false} necessary? I am assuming the other values { downloadThroughput: number, uploadThroughput: number, latency: number } are ignored when offline is true.
So the use case is see is
emulateNetwork('offline`)

or a custom
emulateNetwork({ downloadThroughput:  50, uploadThroughput: 2, latency: 2 }) // These are random numbers

@zabil good question! We took a look at Chrome's emulateNetworkConditions documentation to see if it handled default values at all, but it does not - I'm not sure how Chrome handles those if you omit a key. We like the idea though that something like online could be omitted and have a true value, so we've added default values of { offline: false, downloadThroughput: 0, uploadThroughput: 0, latency: 0 } - so if I say emulateNetwork({ downloadThroughput:  50, uploadThroughput: 2, latency: 2 }) or even emulateNetwork({ downloadThroughput:  50, uploadThroughput: 2 }), it would use these defaults and hopefully match user expectation. This includes an update to the documentation too.


Your GH_TOKEN is showing

Your package.json file has a token showing:
    "gh-publish": "export GH_TOKEN=b9e252e0b0404c2d8fbe403ca2a42dbd6dd13334 && electron-builder build --x64 --mac -p always"

Apologies if this was intentional, it just looked like it might be something private, and not meant to be visible to the public.

Thank you!


Testing - projectile.bouncy

What
Wiki link
Details

maximum bounce amount works for entities and blocks
allow any block / entity works (this overrides List and Whitelist)
whitelist and blacklist
speed modifier

Can you think of ways to break this feature?
This should work properly as I tested these pretty well back then, but still requires testing. With larger projectile hitboxes this doesn't always work properly.
When posting testing results, make sure to include configurations used!

Fixed and tested
    Bouncy:
      Maximum_Bounce_Amount: 2
      Blocks:
        Allow_Any: true
        Default_Speed_Multiplier: 0.6
      Entities:
        Allow_Any: true
        Default_Speed_Multiplier: 0.6


TypeError on API error

Steps to reproduce

Open https://consultation-stats.toolforge.org/?wiki=hu.wikipedia.org&page=Wikipédia%3AKocsmafal+(egyéb) and open your browser console.
Wait. A lot. This is a pretty big page with huge edit history, sorry for not finding a smaller one. (Maybe you should create a server-side component that queries the database directly and returns all the data for one single GET request instead of issuing tons of API calls.)
Notice the error TypeError: data.query is undefined occurring in line 127 of wiki-repository.js. I got this while processing the result of https://hu.wikipedia.org/w/api.php?action=query&meta=globaluserinfo&format=json&guiuser=<IP_ADDRESS>&origin=*&guiprop=groups.

Comments
I see that it’s in a try block, but within that block it’s in a callback function, so the try-catch doesn’t apply. Since you await the result anyway, maybe the easiest is to await just the fetch call and process everything in the main function’s body instead of using callbacks (here and everywhere else in the file). Of course, you can also simply skip getting errors by not querying global groups for IPs… But you should either make use of the try or remove it either way.

Hello @tacsipacsi, that's a great feedback, thank you.  Yeah ideally, an alternate branch should be created with a version that can use SQL dumps to minimize HTTP request.
I've mentioned this in an earlier discussion https://github.com/samuelguebo/consultation-stats/issues/3. For now I got rid of the redundant try/catch blocks and improved the loading time by getting rid of some await/async. You may want to give it a try again after clearing your cache: https://consultation-stats.toolforge.org/?wiki=hu.wikipedia.org&page=Wikipédia%3AKocsmafal+(egyéb)

It still errors out, although the problematic line is #147 now. You could test whether data.error is an object (not undefined), and not take any step further if it is.

@tacsipacsi, I wasn't able to see the error but I've followed the advice of checking for data.error and exiting in https://github.com/samuelguebo/consultation-stats/commit/9a5e23a002738f65bbcebddec8b08ba6f5c4f5a0. Feel free to submit a PR if you're still able to experience the error, and I'll be happy to merge.

(Sorry for the late response.) Now I don’t see any errors. Probably you looked at the browser console? Maybe that doesn’t show the exception; it’s set to display all XHR requests for me, so it’s completely unusable on this page anyway. I have Firefox set to automatically break on uncaught exceptions (Debugger tab), and that was where noticed the exception.


fix(deviceinfo.d.ts): fix typescript declaration export

Description
In #466 the export of the main module was changed to use default export.
Change the typescript declaration to use default export, too.
Checklist

[ ] I have tested this on a device/simulator for each compatible OS
[ ] I added the documentation in README.md.
[ ] I mentionned this change in CHANGELOG.md.

😍 👍

Thank you!

Great, thank you for quick response and merge!


Wait until the form field is un-focused for validation

Hi,
I'm just wondering if Judge is supposed to use this ^ automatically or if the expected behavior is for Judge to validate all of the fields before they are ever entered by the user.  For me, Judge is showing a form of red before the user enters anything.
Thanks,
Erik

Hi @ErikVDW,
how judge validates your inputs is specified in your application JS. Judge validates with judge.validate() inside your JS.
it is possible you are calling something like
$(document).ready(function () {
  judge.validate(your_element_here);
});

This seems like an implementation issue. Make sure you are calling judge.validate on the an event if you don't want validation to occur on page load.


Python stopped working

Hello, when I used the Set Parameters function and dragged a avi file into the video file column it said that "Python has stopped working." Can you help me with that? Thanks.

The Anaconda Prompt said "not enough value to unpack <expected 3, got 2>"

It is possible is caused by the new version of OpenCV. It seems that they changed the API of some functions and it is breaking the current version of Tierpsy. In order to check if this is the case open an anaconda prompt and type:
python -c "import cv2; print(cv2.__version__)"

If the value is 4.X.X or similar then it is a problem with the opencv version.
You can try to downgrade it back to 3. If you installed using conda type:
conda install opencv=3

If you used pip then:
pip install opencv-python-headless==<IP_ADDRESS>

Please let me know if it works. If it is not a problem of the opencv version then I would need more information.

Hello,
When I install the opencv3 it announced me another error.
from .utilsextension import <
ImportError: DLL load failed: The specified module could not be found.
Avelino Javer<EMAIL_ADDRESS>于2019年9月6日周五 上午2:54写道：

It is possible is caused by the new version of OpenCV. It seems that they
changed the API of some functions and it is breaking the current version of
Tierpsy. In order to check if this is the case open an anaconda prompt and
type:
python -c "import cv2; print(cv2.version)"
If the value is 4.X.X or similar then it is a problem with the opencv
version.
You can try to downgrade it back to 3. If you installed using conda type:
conda install opencv=3
If you used pip then:
pip install opencv-python-headless==<IP_ADDRESS>
Please let me know if it works. If it is not a problem of the opencv
version then I would need more information.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ver228/tierpsy-tracker/issues/64?email_source=notifications&email_token=ANDKEXHLGDZ3WLBGWHZJNVTQIIEDDA5CNFSM4IUCDRC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6CCAGA#issuecomment-528752664,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANDKEXDA4UBJAEZYQ4ZAWY3QIIEDDANCNFSM4IUCDRCQ
.

It seems your anaconda installation got broken somehow. It is very hard to say anything with only that information. Try to install opencv using pip (maybe first uninstall opencv conda uninstall opencv . Otherwise, you might one to either use a new environment or reinstall anaconda completely.

I fixed the opencv issue. Now is 3.4.2. But it still announce me not enough
values to unpack. What extra info do you need? Thanks.
Avelino Javer<EMAIL_ADDRESS>于2019年9月10日周二 下午3:36写道：

It seems your anaconda installation got broken somehow. It is very hard to
say anything with only that information. Try to install opencv using pip
(maybe first uninstall opencv conda uninstall opencv . Otherwise, you
might one to either use a new environment or reinstall anaconda completely.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ver228/tierpsy-tracker/issues/64?email_source=notifications&email_token=ANDKEXBXHDQVEKF6THOMCSLQJAAMFA5CNFSM4IUCDRC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6MNCMI#issuecomment-530108721,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANDKEXCUTPBTHPL7SGRXGNDQJAAMFANCNFSM4IUCDRCQ
.

I change the opencv edition to <IP_ADDRESS> and the error was fixed. Thank you
for your help!! I really appreciate that!
Chang Li<EMAIL_ADDRESS>于2019年9月10日周二 下午4:10写道：

I fixed the opencv issue. Now is 3.4.2. But it still announce me not
enough values to unpack. What extra info do you need? Thanks.
Avelino Javer<EMAIL_ADDRESS>于2019年9月10日周二 下午3:36写道：

It seems your anaconda installation got broken somehow. It is very hard
to say anything with only that information. Try to install opencv using
pip (maybe first uninstall opencv conda uninstall opencv . Otherwise,
you might one to either use a new environment or reinstall anaconda
completely.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ver228/tierpsy-tracker/issues/64?email_source=notifications&email_token=ANDKEXBXHDQVEKF6THOMCSLQJAAMFA5CNFSM4IUCDRC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6MNCMI#issuecomment-530108721,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANDKEXCUTPBTHPL7SGRXGNDQJAAMFANCNFSM4IUCDRCQ
.


ActionView::Template errors and precompile errors in Circle CI

Here is the error message when I run tailwind build before specs. I know the docs say it doesn't work with the sassc-rails gem. I have sass-rails which has sassc-rails as a dependency.  The part that's giving me trouble is that tailwindcss:build, assets:precompile, /bin/dev, all work locally even with sass-rails installed. Does sass-rails also need to be removed from the Gemfile and does anyone know why my local set isn't having the SassC::SyntaxError problems?
 I tried purging the load cache. It didn't work.
ActionView::Template::Error:
       Error: Function hsla is missing argument $saturation.
               on line 1 of stdin
       >> color}:root,[data-theme]{background-color:hsla(var(--b1)/var(--tw-bg-opaci
          ------------------------------------------^
     # stdin:1
     # ./app/views/layouts/application.html.erb:16:in `_app_views_layouts_application_html_erb___3961564301017774669_33980'
     # ./spec/features/signup_spec.rb:8:in `block (2 levels) in <top (required)>'
     # ------------------
     # --- Caused by: ---
     # SassC::SyntaxError:
     #   Error: Function hsla is missing argument $saturation.
     #           on line 1 of stdin
     #   >> color}:root,[data-theme]{background-color:hsla(var(--b1)/var(--tw-bg-opaci

@scarrick68 Were you able to fix it? I'm having the same issue


Release @2.82.0 broke semver minor version

Hi sorry to be a pain, but upgrading the Hawk dep broke the semver minor version. This is a breaking change as the new hoek uses const instead of var. Hawk uses Hoek, which uses const. This release should be major version @3.
const Hoek = require('hoek');
^^^^^
SyntaxError: Use of const in strict mode.

Same here. Node version: 0.12.7 for historical reason.

tell me about it...

I am having a similar issue. Using node version 0.12.7 Please revert back to request version 2.81.0 or change the hawk dependency to version ~3.1.3

Same here

Same issue. Breaking my build. @rahul2983 quick update would save me a lot of hassle.

We are using another module that depends on this, and in that module, it writes dependencies as request ^2.54.0. Things really beyond my control now... either we make our local copy of that module or just upgrade node (highly leverage here)

+1 same issue.  Please resolve per everyone's suggestions above.

I had the same problem, temporarily fixed it by changing my dependency from "request": "^2.81.0" to "request": "2.81.0"...

same here!

npm-shrinkwrap.json
{
 dependencies: {
  request: {
   version: "2.81.0"
  }
 }
}

Lesson here is always fix your package versions, don't rely on people and semantic versioning myth.

Changed from "^2.78.00" to "2.78.00". Our server was just sending a 502 error. I agree with @gogson, fix your versions, don't rely on others.

This broke our builds too as the new version of hawk uses let etc in its source which is  as expected by node < 6 but also uglify used in many build pipes to minimize distributions. So while unintended this is a big surprise for many users of the library. At a minimum also engines in package.json should get updated. Unless the new version is very warranted reverting to a version of hawk that does not require new runtimes would be a good idea.

Our build broke yesterday too due to upstream node-sass, jsdom, and probably others. We're working on workarounds now but it would be great if this could be reverted/fixed in this package.

Hopefully this can all teach us a lesson for the future: Any project that stops testing against a major version of Node.js should consider it a breaking change. Else you don't know if you by accident introduce breaking changes down the line. Then this issue would not have happened 😄
This project used to test both v0.10 and v0.12 in the .travis.yml file.

The solution to your problems is quite simple: STOP SUPPORTING v0.10 & v0.12.
Almost a year ago the Node.js project's maintenance window ended for pre v4 releases. This includes critical security updates and OpenSSL. It is irresponsible to continue to support and encourage people to run these versions of Node.js.
Bumping the major version would require every downstream user of request, which if you include deep dependencies is more than half the registry, to manually bump their major version in order to continue getting new releases of Node.js.
It's not fair to the people who are doing the right thing and keeping up to date with supported versions of Node.js to opt them out of updates without intervention so that people who are refusing to upgrade can continue to get fixes.
If you MUST support v0.10 and v0.12 then you can lock your package version while the rest of the ecosystem continues to get fixes, including security fixes like the ones in hawk.
It's quite simple, if you are running an old and insecure version of Node.js then you are no longer going to get security fixes from Node.js OR request, and its dependencies like hawk.

BTW, these "breaks" all seem to be in tests on v0.10 and v0.12.
Remove travis support for those releases. They are unsupported by the Node.js project, they shouldn't be supported by your package.

Whilst I agree that no one should be on an old version of node - that option is not always available.
Traditionally, if you want to drop support for something and introduce a breaking change, the way to do it is with a major version.

Whilst I agree that no one should be on an old version of node - that option is not always available.

Nobody is saying you have to upgrade to a new Node.js.
But, you don't ALSO get dependency upgrades in perpetuity. If you want to run an old applications on an old Node.js, lock your deps. Otherwise they are likely to break.

Traditionally, if you want to drop support for something and introduce a breaking change, the way to do it is with a major version.

I just don't consider a change "breaking" if it breaks on an unsupported version of Node.js.

The solution to your problems is quite simple: STOP SUPPORTING v0.10 & v0.12.

It's the correct solution, no doubt about it, but it's far from being "quite simple" for reasons related to scale, organizational makeup, technical debt, prioritization of work, separation of organizational concerns, etc...

It's the correct solution, no doubt about it, but it's far from being "quite simple" for reasons related to scale, organizational makeup, technical debt, prioritization of work, separation of organizational concerns, etc...

I think we're conflating application upgrades and module upgrades.
Module can just drop old versions from their travis.yml file. That's pretty easy.
Applications are much harder, but if they decide not to upgrade they can simply lock down the versions of their deps and stop upgrading their deps.

Applications are much harder, but if they decide not to upgrade they can simply lock down the versions of their deps and stop upgrading their deps.

That's true, but then the application won't receive speedy security updates and bug fixes. It's a bit of a balance...
I completely agree though that supporting legacy Node versions from a package maintainer's perspective is very difficult, and advising both the module and application maintainers to drop support for legacy Node versions is good advice.

@mikeal I really think @xepps made the correct point. The issue becomes too hard to solve if old project is depending on some modules that are using some other modules that are using request. For example: googleapis -> gapitoken -> request ^2.54.0, in this case, if a project is using googleapis in node 0.12.7, they are screwed and there is no easy way to fix this, other than upgrading node (not always an option). So making this change in a major version like 3.0.0 or something like that would help a lot and resolve it.

Please consider that version numbers are free, customers experiencing bugs in production is expensive. This caused me 1.5 hours of fumbling while prod was on fire. No one is going to care that your library is v15.0.0 if it means that dropping backward compat is done responsibly (with a semver major version).
I totally understand the position that 0.x is to be universally dropped, but that isn't done overnight. In my opinion the only responsible thing to do, especially when you have a large number of downstream projects, is to make dropping 0.x compat a major version regardless of 0.x's support state.
Even if one does not share this view, others will, and they deserve to be warned of the potential breaking changes in their library with the red flag of a major version.

Please consider that version numbers are free

Except when you have a large install base that only automatically upgrades minor releases. If we push a new major it would take years for maybe 10% of our users to be getting the number of updates they get now.

This is a case of who do you want to optimize the experience for: people who run on unsupported platforms or people who keep up with the bare minimum of staying on a supported node LTS version? I completely agree with @mikeal that the people we should care about more are those running supported versions.
The actual semver violation was 11 months ago here: https://github.com/request/request/commit/01aefdd87cdd9cc44af6828c55fe5ef9c7e205d7
Dropping support should have been a major then when the contract changed. The same argument could have been made then though, but back then I would have been more supportive of those losing compatibility. A year later, now that request v2 has been re-contracted as node 4+, it's too late to make this argument for a major bump.
Also - doesn't npm complain when you install request on unsupported node version?!

 I am tired of people making the argument that they should be able to just use whatever random module from the npm registry they find and things should magically work. It's software made by humans. I review every single dependency of code I bring into my projects and all their dependencies. And I expect everyone to do the same. Sounds unrealistic?
 Period. You clearly don't know how to run node in a responsible manner. If you are still running node 0.x you are in completely uncharted territory - you are running unsupported garbage that is known to have bugs and security issues.  But you are as likely to hit really complex bugs in socket handling and memory leaks that a "semver compliant" version of request can expose that only exists in node 0.x.
If you are running an unsupported version of anything, you should stop upgrading everything! Own your mistakes for a change.

Also - doesn't npm complain when you install request on unsupported node version?!

Yup :)

In reply to @hueniverse

I completely agree with mikeal that the people we should care about more are those running supported versions

Yes, however there was a time when node 0.x was supported. My argument is that at the point you chose to no longer support it, there should have been a major version increment. If there had been, then this never would have happened. Like you mention, that was 01aefdd.

 Period. You clearly don't know how to run node in a responsible manner.

Please don't make assumptions about people you don't know's competency or intentions, it degrades the discussion. Mistakes happen regardless of competency. I'll happily own up to the fact that there should have been lockfiles on the legacy repos if you own up to the fact that changing the node version in 01aefdd should have been a major version.
Since the major version was not correctly incremented in 01aefdd, you can make the argument for or against this version requiring a major version, but I don't want to get into that. Both are valid.

Another way to look at this for anyone who got hit by this: your environment is fully exposed to the worse kind of DoS attack vector - operational incompetence.
I am being harsh here for a reason because you got lucky today and some of you still consider this to be someone else' fault. This change caused your application to fail instead of leak data, lose money, or cause irreversible hard. What I hope you have learned today is that ANYONE with publish rights to ANY module you depends on, directly or indirectly, can shut down your entire environment.
Think about what you are admitting to have created - an environment where hundreds (if not thousands) or people have the power, maliciously or innocently, to put you out of business (if only for a short period of time), without any accountability or recourse. Maybe open source isn't for you.
  I have at least 95% access. I have publish rights to qs and I don't even maintain that module anymore - that's 2.5 million daily downloads. npm Inc. will stop me from deleting the module from the registry, a minor improvement over the last registry clusterfuck. But I can still push garbage and impact 2.5 million clients if it takes npm Inc a full day to shut me down.
There is always a delicate balance between productivity (using loose version requirements in your package file to automatically get new version) and security (not getting hit by random shit being posted to the registry). But an easy line to draw is between your local development environment and your production or operational environments.
"Can I afford this system to go down or be exposed to malicious code for a short period of time?" is a simple question to ask yourself. For your personal laptop? probably. For the team's build servers? probably not.
If anyone can cause you to run whatever code they want, you have a massive problem. Again, I can publish right now, a version of qs, that when loaded into memory, will upload files from your machines to my cloud account. Maybe I'll grab your browser history and publish some interesting stats on the kind of porn node developers prefer... It won't last long as people will notice and npm Inc. will take action.
And no, you can't event trust me because my systems can be hacked. If someone gets access to an npm access token from any of my machines, they gain the same power... I don't even trust modules I am the sole publisher of.
Consider this experience an inexpensive lesson in open source operational security.

Yes, however there was a time when node 0.x was supported. My argument is that at the point you chose to no longer support it, there should have been a major version increment.

This has actually never been the case. We dropped support for 0.1.x, 0.2.x, 0.4.x, 0.6.x and 0.8.x without a semver major, and those releases were all major releases (Node.js didn't follow semver until iojs). The only semver major we did was for breaks in request's API.

Except when you have a large install base that only automatically upgrades minor releases. If we push a new major it would take years for maybe 10% of our users to be getting the number of updates they get now.

Does anyone actually auto-upgrade any dependency anymore? Just further exasperates this entire problem.

@jasonpincin If nobody was auto-upgrading deps we wouldn't have people in this issue saying this version broke their 0.12 setup :)

Fair. :)

Except when you have a large install base that only automatically upgrades minor releases. If we push a new major it would take years for maybe 10% of our users to be getting the number of updates they get now.

If nobody was auto-upgrading deps we wouldn't have people in this issue saying this version broke their 0.12 setup :)

I don't think you can have it both ways.

This thread depict how wrong is the notion of semantic version in practice:
@mikeal considers that the change is not a MAJOR one because it breaks unsupported (but not unused) nodejs releases.
This decision complies with the semantic version definition ? Yes ? No ? It seems to me that is up to the dependency provider ... and that is something that you cannot rely on 'automatically' (e.g. using the '^' operator in npm).
And if you cannot rely on that ... what is the real value of semantic versioning ? ( Place your witty answer here )

I don't think you can have it both ways.
This thread depict how wrong is the notion of semantic version in practice:

Agree with you both. It's why I pin versions & commit npm-lock/shrinkwrap in my apps, and advocate that others do the same. In the past I've not pinned versions in my published modules. That was a mistake.

One of my packages depends on request, I use a request@^ dependency in my package (instead of ~) to ensure that my package will not be locked to an old minor version of request that will no longer get security updates and will instead use the most recent version of request that is still supposed to be compatible with my package. If request made a major version increment to drop support for an upstream EOL version of node, I would be happy to do the same in my package while updating the nodejs compatibility version in my package as well.
However, because back in 2.77.0 request decided to publish the breaking change of dropping 0.10 support, old versions of my package that explicitly state a contract of "node": ">=0.10.0" are now broken in a version of node that they state they support. So that version contract in that major version of my package is now broken, because of request.
Now, because request refuses to honor its own contract in a way that can affect my package, I've actually started considering pinning my package to request@~ instead of request@^ to ensure that request never again causes that contract in my package to break in current/future releases of my package.
Which is of course the complete opposite result of the request authors' reason for not incrementing the major. The desire to keep the same major version number despite making technically breaking changes just so packages targeting that major version still get security updates on the "currently supported" versions of node. May cause the opposite effect if packages instead start pinning request to ~ which won't get security updates.
And as for the "0.10 is EOL, shouldn't be used because it doesn't get security upgrades, and thus we can make breaking changes without having to increment our major version number" argument, that argument is faulty, it completely ignores linux support<EMAIL_ADDRESS>is still packaged with the debain release "jessie", jessie is a LTS release that will receive security upgrades till April 2020, and historically Debian has a habit of applying major security patches to packages to fix security bugs even when the original software considers these versions EOL and isn't applying security patches to them. This means that for users of debian jessie<EMAIL_ADDRESS>should still be a reasonable version of node to use until April 2020.

Debian has a completely insane and outdated notion of what is secure/stable. Node.js 0.10 is not secure and it is not stable. Period. Full stop. There is no definition of the term "secure" or "stable" that applies to 0.10.x. I'm not going to try and understand the internal logic of Debian maintainers but I'm also not going to consider their mindset in decisions I make in this project.
@dantman correctly notes that 2.77.x is when we deprecated 0.10.0 (and 0.12.0 btw).
We noted this by changing the target range in package.json. There's a reason that the supported versions of Node.js are independent of the semantic version of request itself. Anyone run old versions from that point on would see large warnings from npm on installation.
I've said this several times, and I'll say it again, I'm not going to silently opt the majority of request users out of security updates by bumping the major version in order to not inconvenience people running EOL versions of Node.js.
Everything is a tradeoff. I understand that people stuck on old versions don't like this tradeoff, but you are in the minority, and we only have the resources to support a single major line of development, so the choice was between breaking you or opting the rest of the community out of automatic updates. This will not be the last time you are inconvenienced by changes like this in dependencies so it's a good idea for you to lock down your deps with shrinkwrap and stop updating them. Or, better yet, update to a supported version of Node.js.
For package authors: it's up to you whether or not to bump the major version, but supporting EOL versions of Node.js is not a good practice and encourages irresponsible/insecure behavior of your users.
For a longer rant on the reality of Security and Sustainability in open source you can read this https://twitter.com/mikeal/status/911353245628481536

I've said this several times, and I'll say it again, I'm not going to silently opt the majority of request users out of security updates by bumping the major version in order to not inconvenience people running EOL versions of Node.js.

Installation of older/insecure versions of a library without security updates is not silent. Not if you bother to deprecate them.
npm deprecate request@^2 "request 2.x releases no longer receive security updates, please upgrade to request 3.x"

Debian has a completely insane and outdated notion of what is secure/stable. Node.js 0.10 is not secure and it is not stable. Period. Full stop. There is no definition of the term "secure" or "stable" that applies to 0.10.x. I'm not going to try and understand the internal logic of Debian maintainers but I'm also not going to consider their mindset in decisions I make in this project.

You don't seem to understand how Debian LTS works. Debian applies security patches to software in its packages, even if they are not applied to the upstream version. Would you care to actually list an example of a security issue in<EMAIL_ADDRESS>that still affects jessie? I can find an example of the opposite.
For instance, node.js is affected by the CVE-2017-1000381 security issue discovered this year in c-ares which the official versions of node.js have only patched 4+ with fixes for (fixed in 4.8.4, 6.11.1, 7.10.1, 8.1.4. However, the c-ares version used by the<EMAIL_ADDRESS>package included in Debian jessie, has been patched with the CVE-2017-1000381 fix. So despite the official node.js release of 0.10 being vulnerable to CVE-2017-1000381, the Debian jessie release of 0.10 is not vulnerable to that security issue.

And you don't seem to be guaranteeing that I won't one day wake up one day in 2018 and find that a release of my package is now broken in node@4 because of a request@^ dependency despite the fact that nodejs@4 will still likely be present in whatever the current stable version of Debian is (stretch is the current release and has 4.8.2~dfsg-1, buster is the current testing, i.e. upcoming release, and has 4.8.4~dfsg-1), Debian will be keeping it updated with security patches, and the broken version of my package declares that it supports node >=4 and is "the" latest version of the packages users on that version of node can install.

Installation of older/insecure versions of a library without security updates is not silent. Not if you bother to deprecate them.

If people paid attention to these warnings then we would have all these people so surprised by the latest release. They've been easily ignoring version conflict warnings for almost a year.

You don't seem to understand how Debian LTS works. Debian applies security patches to software in its packages, even if they are not applied to the upstream version. Would you care to actually list an example of a security issue in<EMAIL_ADDRESS>that still affects jessie? I can find an example of the opposite.

To my knowledge, Debian has never back ported a single fix to an old versions of Node.js, much less all the dependencies an application might have.
Perhaps they do this privately and people paying the right vendors are getting fixes. If they are, fine, they can patch request and the deps we're taking in request along with their Node.js work.

And you don't seem to be guaranteeing that I won't one day wake up one day in 2018 and find that a release of my package is now broken.

Not exactly. If you keep using the same version of request you will never break.
If you are not locking the version of request and continue trying to update it, yes, a new release will eventually break.
Other packages will also break as old releases continue to fall out of circulation and are not tested against. This is a good thing, we all need to move forward and stay on support and secure versions of Node.js.

To my knowledge, Debian has never back ported a single fix to an old versions of Node.js, much less all the dependencies an application might have.

I just gave an example of Debian backporting a fix to a security vulnerability that affects node. Debian splits up packages, i.e: the libraries nodejs uses (the biggest source of security issues) are separate packages instead of directly part of the nodejs package and they get security packages individually, which implicitly fixes the security issue in node. So the only time Debian needs to make a backport directly to the nodejs package that you'll see in the changelog for the nodejs package is if it's a security vulnerability directly in the nodejs source code created by one of the nodejs devs (a rare type). Would you care to give me an example of one of those, or another security vulnerability you'd like me to check the nodejs package for?

Great! Debian can do the work of backporting hawk to 0.10.0 and keeping a working fork of request for 0.10.x users, cause I'm not going to waste my time supporting EOL versions of Node.js.
If they want to support EOL software they can do all the work of supporting it, both in Node.js and in dependencies like request.

So to summarize what's come out of this: Pin everything. Semver (within NPM at least) has an extremely finite window in which it has any meaning at all.

So to summarize what's come out of this: Pin everything. Semver (within NPM at least) has an extremely finite window in which it has any meaning at all.

shrinkwrap/yarn is good to use in applications, it'll give you control over exactly what versions of libraries are installed and only upgrade them when you intend to upgrade packages.
However I wouldn't say that about semver or npm. The mass majority of packages used by people on npm stick to semver. For example the hawk package request uses where this error originally is thrown from bumped its major to 4.0.0 when it dropped support for nodejs@<4. It's just that request is one of the few packages that doesn't care to stick to semver when doing so. The only reason that hawk is throwing that error is because request started depending on it without a major release. So you can safely use ^ for most packages, but do have to be wary of a few black sheep like request.

i think a better summary might be to not use dependencies that are marked as incompatible. even locking dependencies isn't ideal if you aren't first confirming compatibility.
for example, my builds call npm ls and check the status code to ensure things like peer-dependencies are compatible with each other. i do this even before i run my test suite to ensure i have a reasonable starting point.
i'm not sure if that particular command would fail for packages that are incompatible with the current node version (it does not fail for deprecations), but i would be surprised if there weren't a way to ensure that your project is not ignoring warning programmatically.
can anyone confirm if npm ls or a similar command could help identify node version compatibility so that others running into issues could take real action to improve their situation, even if upgrading isn't an option?

Sometimes users just forget to update their Node.js, so I built these:

https://github.com/jokeyrhyme/update-nodejs-notifier.js
https://github.com/jokeyrhyme/package-engines-notifier.js

In my own CLI tools, I usually have these set to start bugging users if their version of Node.js is older than 90 days, and if their Node.js version doesn't match package.json:engines.node

This will get even more fun next week when I publish new major versions of all my modules to only support node v8... :-)

Below error/issue resolved with this solution:
Solution:
sed -i '27 a "request":"2.81.0",' /opt/apache-ambari-2.2.2-src/ambari-web/package.json
I just added specified "request" version(older version "2.81.0")  in "package.json" file below problem resolved.
Here is my error:
[INFO]
[INFO] --- exec-maven-plugin:1.2.1:exec (compile-brunch) @ ambari-web ---
[DEBUG] Configuring mojo org.codehaus.mojo:exec-maven-plugin:1.2.1:exec from plugin realm ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent: sun.misc.Launcher$AppClassLoader@5c647e05]
[DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec' with basic configurator -->
[DEBUG]   (f) basedir = /opt/apache-ambari-2.2.2-src/ambari-web
[DEBUG]   (f) classpathScope = runtime
[DEBUG]   (f) commandlineArgs =  build
[DEBUG]   (f) executable = brunch
[DEBUG]   (f) longClasspath = false
[DEBUG]   (f) project = MavenProject: org.apache.ambari:ambari-web:<IP_ADDRESS>.0 @ /opt/apache-ambari-2.2.2-src/ambari-web/pom.xml
[DEBUG]   (f) session = org.apache.maven.execution.MavenSession@5ce4369b
[DEBUG]   (f) skip = false
[DEBUG]   (f) workingDirectory = /opt/apache-ambari-2.2.2-src/ambari-web
[DEBUG] -- end configuration --
[DEBUG] Executing command line: brunch build
/opt/apache-ambari-2.2.2-src/ambari-web/node_modules/ember-precompiler-brunch/node_modules/jsdom/node_modules/request/node_modules/hawk/node_modules/boom/lib/index.js:5
const Hoek = require('hoek');
^^^^^
Error: You probably need to execute npm install to install brunch plugins. SyntaxError: Use of const in strict mode.
at /opt/node-v0.10.44-linux-x64/lib/node_modules/brunch/lib/watch.js:433:19
at Array.map (native)
at loadDeps (/opt/node-v0.10.44-linux-x64/lib/node_modules/brunch/lib/watch.js:418:10)
at loadPackages (/opt/node-v0.10.44-linux-x64/lib/node_modules/brunch/lib/watch.js:438:15)
at /opt/node-v0.10.44-linux-x64/lib/node_modules/brunch/lib/watch.js:458:19
at /opt/node-v0.10.44-linux-x64/lib/node_modules/brunch/lib/helpers.js:529:16
at /opt/node-v0.10.44-linux-x64/lib/node_modules/brunch/lib/helpers.js:485:14
at /opt/node-v0.10.44-linux-x64/lib/node_modules/brunch/node_modules/read-components/index.js:263:16
at /opt/node-v0.10.44-linux-x64/lib/node_modules/brunch/node_modules/read-components/index.js:72:14
at Object.cb [as oncomplete] (fs.js:169:19)
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Ambari Main ........................................ SUCCESS [  3.970 s]
[INFO] Apache Ambari Project POM .......................... SUCCESS [  0.591 s]
[INFO] Ambari Web ......................................... FAILURE [01:08 min]

I'm late to the party, and I can't resist chiming in.
Everyone who is complaining about "semver not being adhered to", try reading the spec again. The spec deals specifically with the public API of the versioned item. How that API is implemented is not covered, as long as that API remains the same:

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

http://semver.org/#spec-item-5
In fact, it's point number 1 in the summary of the spec.
Did request's API change? No? Then semver wasn't broken.

I asked other people what do they think of request package versioning strategy.
There are only 10 responses. Please, do the same poll and you'll get the similar result.

My point is - it does not matter what is the most SemVer spec compliant way of versioning. People expect NPM modules to bump major version when they drop support of an old node.js.


gnucash: 3.3 -> 3.4

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/gnucash/versions.
meta.description for gnucash is: '"Personal and small-business financial-accounting application"'.

Checks done (click to expand)

built on NixOS
/nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4/bin/gnc-fq-check passed the binary check.
/nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4/bin/gnc-fq-helper passed the binary check.
/nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4/bin/gnc-fq-dump passed the binary check.
/nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4/bin/gnucash passed the binary check.
/nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4/bin/.gnucash-wrapped passed the binary check.
5 of 5 passed binary check by having a zero exit code.
0 of 5 passed binary check by having the new version present in output.
found 3.4 with grep in /nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4
directory tree listing: https://gist.github.com/2e770d0deb9cd993ff19e449dfa32f45
du listing: https://gist.github.com/360e895e864b9a92fc9268eddf78351a

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)
1 package rebuild(s)
1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
gnucash

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A gnucash https://github.com/r-ryantm/nixpkgs/archive/54e179d51aeb004a82cca7bed3bfb9ea222b68af.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4
ls -la /nix/store/91gqgx6v5r3yf8g8pfsnya649d64gir2-gnucash-3.4/bin

cc @peti @domenkozar for testing.

https://www.gnucash.org/news.phtml


Running python startquill_cherry.py gives syntax error

Prems-Macbook-Pro:Quillpad-Server-master Aggrigator$ python startquill_cherry.py
File "startquill_cherry.py", line 497
cherrypy.engine.subscribe.('start_thread', connect)
^
SyntaxError: invalid syntax
Prems-Macbook-Pro:Quillpad-Server-master Aggrigator$

@sharath-tachyon @tachyontech Can you please help me with this issue?

change
cherrypy.engine.subscribe.('start_thread', connect)
to
cherrypy.engine.subscribe('start_thread', connect)
basically remove the . after subscribe
Hope it helps :)

Traceback (most recent call last):
File "startquill_cherry.py", line 9, in
from QuillSourceProcessor import QuillSourceProcessor
File "/home/Quillpad-server/QuillSourceProcessor.py", line 131
"Loaded english dictionary from...", fname
^
IndentationError: unexpected indent

Hi Pankaj,
Did you make any modifications to the file and save it? Python has a problem if you mix tabs and spaces in the same script..
When in doubt change your editor to make tabs and spaces visible. It is also a very good idea to have the editor resolve all tabs to 4 spaces or always use tabs to avoid this confusion.

I think the better solution is to debug. Changing the code  from
"Loaded english dictionary from...", fname
to
print ("Loaded english dictionary from...", fname)
should do the trick.
PS : I have made a pull request which fixes all these issues in the code, the code runs flawlessly once all the dependencies are met. Please have a look at them here https://github.com/teamtachyon/Quillpad-Server/pull/2

@sharath-tachyon Hi, could you please have a look at the pull request ( https://github.com/teamtachyon/Quillpad-Server/issues/url ) and possibly merge it if it's fine. Also I think it would be better to improve the readme to give a more details explanation on how to set it up. I am planning to write a blog about the same, let me know if it could help :)


public haddocks

It would be nice to have a public location for the ghcjs-base haddocks like other packages have on hackage.

I would really appreciate this as well!

They'll be on hackage once ghcjs-base is on hackage (once GHCJS is released)
You can do stack haddock ghcjs-base to build the docs locally.

Given that haddocks are on hackage, I think this issue can be closed :-)
http://hackage.haskell.org/package/ghcjs-base-<IP_ADDRESS>


model.GetModel() returned wrong SupportedGenerationMethods

Here is my code:
async Task Main()
{
	var googleAI = new GoogleAI(apiKey: Util.GetPassword("GEMINI_API_KEY"));
	var model = googleAI.GenerativeModel(model: Model.Embedding).Dump();
	var response = await model.GetModel().Dump();
}

I don't know why. The SupportedGenerationMethods property seems wrong. The model.GetModel() call still think he is models/gemini-pro model?

I do checked with the REST API call directly. The response is correct. I don't know why.
{
  "name": "models/embedding-001",
  "version": "001",
  "displayName": "Embedding 001",
  "description": "Obtain a distributed representation of a text.",
  "inputTokenLimit": 2048,
  "outputTokenLimit": 1,
  "supportedGenerationMethods": [
    "embedContent"
  ]
}

I found the bug now. The default value of the model argument pass into GetModel should not fixed with gemini-pro. It should get value from _model by default.

Thanks for the catch. It shouldn't be an optional parameter after all.
I understand the assumption. The method itself is at the wrong location. It should not be a member of the model type but belonging to the IGenerativeAI interface.
Same for other methods like ListModels, CreateTunedModel, etc.
Those are currently at the wrong place.
Very good findings!
Thank you very much, @doggy8088


support protobuf on the store-indexer

clients like unity and co have much better support for protobuf then custom transports like trpc (even if it's json at the end of the day). it could also be useful for web browsers when network traffic becomes the bottleneck.

doesn't look like trpc has a protobuf transport out-of-the-box
regular eth rpc is all JSON and clients need that as a fallback anyway, so JSON for now seems fine (if not a little heavy)
we can prob optimize the json payload for snapshots to reduce duplicate data (i.e. keys) if we can't get good raw binary support

It's mostly about ease-of-integration over speed and network bloat.
It's actually quite hard to integrate dynamic JSON with compiled languages
like C# and Rust given all schemas need to be known in advance. As an
example, Lermchair didn't know / has a hard time integrating the indexer
into their Unity codebase.
Protobuf has tooling in all languages to generate libraries to interact
with a schema (with types and co), while TRPC is specific to Javacsript and
it's underlying JSON format is a little bit obscure.
I think we can add multiple heads to the indexer, possibly as different
binaries (so we have one process indexing into the storage, and we can
scale the processes reading from the DB). One of them could be a gRPC
server w/ Protobuf. The work will mostly be defining a Protobuf schema for
our return data (which is a list of tables and records within them iirc).
On Tue, Aug 15, 2023 at 9:39 AM Kevin Ingersoll @.***>
wrote:

doesn't look like trpc has a protobuf transport out-of-the-box
regular eth rpc is all JSON and clients need that as a fallback anyway, so
JSON for now seems fine (if not a little heavy)
we can prob optimize the json payload for snapshots to reduce duplicate
data (i.e. keys) if we can't get good raw binary support
—
Reply to this email directly, view it on GitHub
https://github.com/latticexyz/mud/issues/1299#issuecomment-1678598919,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFBYUKZI35ZVPC23FNXP2QTXVMYTRANCNFSM6AAAAAA3PQZLOE
.
You are receiving this because you authored the thread.Message ID:
@.***>

different frontends for the indexer makes a lot of sense! they'll need to
be scaled separately from the data ingestion process anyway
On Tue, Aug 15, 2023 at 9:52 AM ludens @.***> wrote:

It's mostly about ease-of-integration over speed and network bloat.
It's actually quite hard to integrate dynamic JSON with compiled languages
like C# and Rust given all schemas need to be known in advance. As an
example, Lermchair didn't know / has a hard time integrating the indexer
into their Unity codebase.
Protobuf has tooling in all languages to generate libraries to interact
with a schema (with types and co), while TRPC is specific to Javacsript
and
it's underlying JSON format is a little bit obscure.
I think we can add multiple heads to the indexer, possibly as different
binaries (so we have one process indexing into the storage, and we can
scale the processes reading from the DB). One of them could be a gRPC
server w/ Protobuf. The work will mostly be defining a Protobuf schema for
our return data (which is a list of tables and records within them iirc).
On Tue, Aug 15, 2023 at 9:39 AM Kevin Ingersoll @.***>
wrote:

doesn't look like trpc has a protobuf transport out-of-the-box
regular eth rpc is all JSON and clients need that as a fallback anyway,
so
JSON for now seems fine (if not a little heavy)
we can prob optimize the json payload for snapshots to reduce duplicate
data (i.e. keys) if we can't get good raw binary support
—
Reply to this email directly, view it on GitHub
https://github.com/latticexyz/mud/issues/1299#issuecomment-1678598919,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AFBYUKZI35ZVPC23FNXP2QTXVMYTRANCNFSM6AAAAAA3PQZLOE>

.
You are receiving this because you authored the thread.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/latticexyz/mud/issues/1299#issuecomment-1678613452,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAD4HN4EPM3WABDWO2JEO3TXVM2FLANCNFSM6AAAAAA3PQZLOE
.
You are receiving this because you commented.Message ID:
@.***>

for future us:
https://github.com/timostamm/protobuf-ts
https://github.com/stephenh/ts-proto
we'd just need to come up with a friendly spec for requests/responses (since the spec needs to be defined ahead of type and doesn't support arbitrary structures)


build: bump/remove dependencies

This PR bumps a few of our dependencies and removes a couple of unneeded dependencies.
Checklist

[ ] npm test passes (tip: npm run lint-fix can correct most style issues)
[ ] tests are included
[ ] documentation is changed or added

:tada: This PR is included in version 4.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


.editorconfig file added to the repository

Strongly inspired by this one: https://github.com/dotnet/corefx/blob/master/.editorconfig
Merging this PR would require reformating existing files, I will do if so.

I didn't know that:
https://www.jetbrains.com/help/resharper/Using_EditorConfig.html
Totally awesome!
Will merge this later today


External authorization checks/helpers

Idea based on FirstBlood's token: https://github.com/Firstbloodio/token/blob/2ee2fccb4d111bee461de569bf792619cab40650/smart_contract/FirstBloodToken.sol#L228
Provide a mechanism for contracts to validate external auth mechanisms such as verifying an EC signature before proceeding with the function.

We have a very generic SignatureBouncer that will revert if the call doesn't comes signed from one of the approved bouncers.
I think that if we make the bouncer a contract that verifies an EC signature, and then forwards the call adding their signature, this solves the example that Manu is giving. And many other things can be build on top of that. @shrugs can you please confirm if we can close this issue or if there's something missing?

Yup, SignatureBouncer solves this issue (except the hash is also of the contract address, which stops someone from potentially using the same signature for multiple contracts managed by a single signer.
I'd say this is solved!


Add new RALPMH questionnaires

Add new RALPMH questionnaires: ERS, RALPMH Covid Symptoms, and Pulse Ox Response

Can you please run the script again?
Can you also please add the updated script code in this PR? Thanks.

Is it fine if I add it in a separate PR? I also want to make other changes.

Is it fine if I add it in a separate PR? I also want to make other changes.

Yes sure


set story file header flags correctly on start/restart

ZEMU leaves the story file header untouched, but it should set the following header flags properly on starting a game:

01[4]: Status line not available?
01[5]: Screen-splitting available?
01[6]: Is variable-pitch font the default?
10[0]: Transcription is on?
10[1]: Fixed-pitch font?
32: Standard revision number

Added in commit e1676b8..c53e292


send pipeline notifications to the Workstation team channel

Description
Workstation owns ChefDK, so let those humans know what's up.


IPython console startup file / run lines not working

Description of your problem
Ipython console startup settings specified in spyder preferences, or my ipython startup file, don't work.
What steps will reproduce the problem?
First issue - startup code in ipython_config.py is processed when I start ipython from a prompt, but not in Spyder.
2nd issue - Preferences -> Ipython Console -> Startup -> Run a file isn't run.  I have a print statement, nothing is printed.  Also a magic line to set precision of printed numbers, doesn't work.
3rd issue - content of "run code" dialog box isn't run.
What is the expected output? What do you see instead?
ipython startup stuff to happen, it doesn't.
Please provide any additional information below
OK so the real issue is I want to control the precision of printed numbers in ipython console in spyder.  Without having to type %precision %.4g every time.
Versions and main components

Spyder Version: 3.0.0
Python Version: 3.5.2
Operating system: Windows 7, anaconda dist., all up to date as of 2 oct 2016.

Dependencies
Please go to the menu entry Help > Optional Dependencies (or
Help > Dependencies), press the button Copy to clipboard
and paste the contents below:

ipython_config.py is not run anymore because it's specific to Python. Please use the Jupyter configuration files instead.
@jitseniesen, could you check what's happening here?

Hmm, some commands work, but some don't.
If you put the statement x=1 in either the startup file (set in Preferences -> IPython Console -> Startup -> Run a file) or the startup code (set in Preferences -> IPython Console -> Startup -> Run code), then this is executed as expected, and x  has the value 1 in the IPython console. So it's not all broken. :smile:
A print statement in either of these places has no effect. A %precision statement also has no effect.
However, if you run an IPython console outside Spyder and specify a startup file using the IPYTHONSTARTUP environment variable, the behaviour is the same: x=1 has an effect, but print() and %precision do not. Reading ipython/ipython#7950, I think it may not be our fault.
I don't know how the IPython console in Spyder works, so I'm not going to investigate this further at the moment.

http://shawnleezx.github.io/blog/2015/08/03/some-notes-on-ipython-startup-script/ suggests that you cannot use IPython magic (like %precision) in startup scripts.

Thanks a lot @jitseniesen for checking this out!! About your remark, the IPython console in Spyder works in a very similar way to what you get when you run jupyter qtconsole, but with some internal additions to connect each console to the other Spyder plugins.
@dstrozzi, you need to use this file as startup file for %precision to work
from IPython import get_ipython
ipython = get_ipython()

ipython.magic("precision %.4g")

print statements (as @jitseniesen noted) don't work, but that's not Spyder's fault, it's just the way IPython works :-)

OK, I finally got around to this.  Making my own startup file with the
lines from Carlos does indeed work.  Thank you!
On Mon, Oct 3, 2016 at 4:34 PM, Carlos Cordoba<EMAIL_ADDRESS>wrote:

Closed #3494 https://github.com/spyder-ide/spyder/issues/3494.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/3494#event-811059154, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIlJFOrIl6Rn56s5sV6kvqXLlS5PWYWQks5qwZEegaJpZM4KMEAR
.

I am executing my code on  Spyder IDE and it does not show me on the console as an OUTPUT.
whats should I do in this case?
I am executing below code.
import numpy as np
import matplotlib.pyplot as plt
import pandas as pd
import statsmodels.api as sm
X = np.append(arr = X, values = np.ones((50,1)).astype(int), axis = 1)
X_opt = X[:, [0, 1, 2, 3, 4, 5]]
#Our X_opt array has a dtype of object and this may be causing an error. Try changing it to float.
X_opt = np.array(X_opt, dtype=float)
regressor_OLS = sm.OLS(endog = Y, exog = X_opt).fit()
and I am looking P- Values as an output but it shows me blow line instead of P-values.
runfile('C:/Users/lenovo/Desktop/ML/Python/Part 2 Regrassion/Section 7 - Multiple Linear Regression/Python/01 Multiple linear regression.py', wdir='C:/Users/lenovo/Desktop/ML/Python/Part 2 Regrassion/Section 7 - Multiple Linear Regression/Python')


Metric Cache seems to get inconsistent when state variable is a list

🐛 Bug
I debugged into this for a longer time now. I am not 100% sure if it is a bug, but i have no idea what i am doing wrong.
I have attached my custom metric to the Trainer and call trainer.validate(model, datamodule) to compute the metric on the whole Validation set. In each step i print my metric in the .compute() function.
What confused me a lot is, that the val_mymetric value is always the same as the metric value of the last batch. Heres my output (only two batches):
mymetric after 1. batch: 0.109375
mymetric after 2. batch: 0.20454546809196472
# end output of .validate():
{'val_cross_entropy': 0.2601596713066101,
 'val_mymetric': 0.20454546809196472}

I also found that in the last computation the metric only holds the values from the last batch in preds
My Metric (only important functions)
class MyMetric(Metric, metaclass=abc.ABCMeta):
    def __init__(self):
        super(MyMetric, self).__init__()
        self.softmax = nn.Softmax(dim=1)
        self.add_state("preds", list())
        self.add_state("labels", list())

    def reset(self):
        self.preds.clear()
        self.labels.clear()

    def update(self, preds: torch.Tensor, target: torch.Tensor):
        self.preds.append(self.softmax(preds))
        self.labels.append(target)

IMHO the problem is the following:
# metric.py

# save context before switch
cache = {attr: getattr(self, attr) for attr in self._defaults}

The cache is taking the exact same object that get's cleared by the .reset() function. I think the cache should be built with a copy of each object? The id() of the cache object and metric object was the same.
To Reproduce
Steps to reproduce the behavior:
as the metric is confidential i am not able to add a bigger code snippet here.
Expected behavior
At the end of the epoch, the Cache-Content should hold all elements that come in by update() and not be cleared by the .reset()
Environment
PyTorch Version (e.g., 1.0): 1.10.0
Flash Version: 0.6.0
OS (e.g., Linux): Ubuntu on Docker
How you installed PyTorch (conda, pip, source): pip with virtualenv
Build command you used (if compiling from source):
Python version: 3.8.12
CUDA/cuDNN version: 11.4

Creating a new list-object instead of clearing the existing one seems to fix it. The list in cache is then a different object then in the metric. Maybe worth mentioning in docs?
def reset(self):
    self.preds = []
    self.labels = []

@daMichaelB what TorchMetrics version are you using? :rabbit:

@daMichaelB what TorchMetrics version are you using? 🐰

Hey @Borda: it is version 0.6.2

Creating a new list-object instead of clearing the existing one seems to fix it. The list in cache is then a different object then in the metric. Maybe worth mentioning in docs?

mind send a PR?
cc: @SkafteNicki

Creating a new list-object instead of clearing the existing one seems to fix it. The list in cache is then a different object then in the metric. Maybe worth mentioning in docs?

mind send a PR? cc: @SkafteNicki

Sure! I will add a PR to mention it in the docs

Hi @daMichaelB,
Maybe I am misunderstanding something here, but normally we do not recommend that users implement their own reset method. If all states are initialized with self.add_state the default reset method will reset them for you:
https://github.com/PyTorchLightning/metrics/blob/43a226101e05ec8e5a5fe4ad64b90c44af1a3b34/torchmetrics/metric.py#L396-L409
In the case of list it will automatically create a new one.

Hey @SkafteNicki . Oh damn, that explains a lot. Thanks for clarification. then i misunderstood this 😄
I guess we can then close it ?! Thanks!

Hi @daMichaelB ,
No I think this is a clear indication that we do not communicate well enough that reset method should not be implemented by the user. So let's keep it and figure out a doc fix :]

@daMichaelB could have an idea how to reformulate it... mind sending your proposal as a PR?

@daMichaelB could you take a look at PR #785 if that improves the documentation on this issue?

Hey @SkafteNicki . Thats perfect! thank you very much for the great work here! I think that makes it very clear


Fix trailing comma in exapmle react-library.json

Description
In the example tsconfig for a react library there is a trailing comma inside the compiler options which would make it invalid JSON.

Allow CI Workflow Run

[ ] approve CI run for commit: 84d9bc8e376250d2ce33856a7be737209d2dab7a

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

Will investigate the CI issue later, PR looks good.


Typing Master

Project title
Typing Master
Project Description
This web app would help one to track their typing speed.
Web stack

HTML , CSS AND JAVASCRIPT.
Screenshot(mandatory)

Additional Context(mandatory)
Are you contributing under any open-source program ?
i am working under codepeak'23.

Hey @AnkitaSikdar005 , I have opened a pull request regarding this task please do review it.


Output exact FFMpeg error

Q
A

Bug?
no

New Feature?
yes

Version Used
master

FFmpeg Version
4.1.3

OS
MacOS

Actual Behavior
How does PHP-FFMpeg behave at the moment?
When the underlying FFMpeg command fails, you only have an "Encoding Failed" message and the command that failed. I know that you just can copy the command and run it on the console, but it would be nice if the output included the error from FFMpeg, so running the command from the console it is not neccesary to check what is happening.
What is the behavior you expect?
The error output includes the error from FFMpeg.
Possible Solutions
@jens1o I am willing to add this feature, because I consider it would be very helpful and would make  developers' life easier, but I don't know where to code the solution. Looking at the source code, I found that the error output is handled by the Alchemy/BinaryDriver library, and looking at it, there is even a commit which adds the error output from the command in one of its error handling blocks, but since there is some duplication on that code, the command error output is missing from the block which actually is used by FFMpeg when an encoding failed.
Now it worries me that Alchemy/BinaryDriver has no commits since a while now, so I'm not sure if I should do a PR on that library, but I'm also aware that you are a mantainer of that library as well, so if you say that you are willing to merge the PR on that library, I can do it.
The other option we have is doing the handling on the FFMpeg code, since we have access to the Process object, we can call $process->getErrorOutput() from there. I'm looking forward to your response. I'm loving the library btw, is sooo convenient to work with FFMpeg from PHP :)

Sorry for my late response! I really like this idea. I've created a BinaryDriver issue to track its work. I think the first step would be to dig in there. Would you like to take it(if you have any questions, I'm here to support you)?

Any update on this?

While a new API in BinaryDriver has been added, the corresponding part in php-ffmpeg is missing, yet. Would you like to file a pull request? Then we would need to find errors, and how we can detect them in the error message. :)

Damn I was afraid that the CI would fail in older versions due to changes in ExecutionFailureException constructor. Nevetheless @jens1o I would like to know what are your insights on the changes I made. I think that I will create a method on the TestCase class to use the right arguments when creating ExecutionFailureException according to the current PHP version

Since i don't know how you want to implement this feature, i will just write the errors I see, while working with it:

Too many packets buffered for output stream 0:1

x264 [error]: not compiled with 10 bit depth support
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

This feature is intended to output the errors, like the one you posted there, from this library, rather than having to copy and paste the full command into your terminal and run it to see the FFMpeg error. Is only intended to output the error from the FFMpeg binary.

Ahh I see then nevermind

Any update on this?


Create child scopes for SwiftPM operations

Some SwiftPM functions check whether their observability scope has errors. If we use the same observability scope for all SwiftPM operations during SourceKit-LSP’s lifetime, a single SwiftPM error will set the hasError bit in that observability scope for the entirety of SourceKit-LSP’s lifetime, impacting all upcoming SwiftPM operations.
Creating a separate child scope for every operation fixes

@swift-ci Please test


Frontend data "API"

Support API like ... read https://github.com/okfn/data.okfn.org-new/issues/6
Acceptance criteria

[x] /core/finance-vix/r/{name-or-index-in-list}[.csv,.json]

[x] .csv => redirect to pkgstore url for that file (with 302 temporary)
[x] .json => same ...

[x] pkg store for json files is /latest/.datahub/data-json/{path-for-csv-including.csv}.json

[ ] (Low priority) no extension - render html page with resource info, link to parent package and a preview of the data ...

Tasks

[x] create a new route to handle the path /core/finance-vix/r/{name-or-index-in-list}[.csv,.json]
[x] workout and create logic to identify needed url and redirect to there

FIXED - we're leaving html versions for later as it is not a priority atm.


Revert "Disable Html for markdown"

Brad wants to make an announcement for when this is made, and MCrow doesn't like the fact that it doesn't auto convert and it looks ugly, (the following is my opinion) despite the fact that raw HTML shouldn't have been allowed in the first place.
Reverts UnturnedStore/UnturnedStore#20
Will be re-reverted at a later stage.

Maybe brad can make an script to migrate all the old html to markdown

Probably, but for now it'll be made with an announcement and any un-migrated things apparently someone will manually migrate them. Don't know the whole plan, but shrug.


Losing details in send form

if you need to move from the main screen in desktop client to copy something from desktop the send screen disappears and you appear to need to start over...

Duplicate of https://github.com/ArkEcosystem/ark-desktop/issues/5


Create iterator class for Hdf5 files with audio features

Thanks, Pat. Let's have a default shape of (0,0) or None. I typically don't have an idea of how many FFT bins exist, so I would probably grab the entire spectra. I could place this check in my WavFeeder.py, but it would more elegant to place it here.


Bug: CRV llamalend leverage issue.

Background
CRV for llamalend doesn't work. Please check differences between 2 crvUSD controllers for each collaterals and find the solution.

@wc117 @webelf101 was this done?


Fix automated conformance tests.

Fix multithreading issue with REQUIRE macro in catch.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for submitting this! I'll get somebody more familiar with the threading in this area to review it.

Oh apparently you know Bryce :) Seems likely that we should probably quit the thread early in case of error (since these were requires) which would also simplify the updating logic. Took me a while to realize that variable didn't need to be atomic since only the non-main thread would write to it.

Looks good, can you add a changelog fragment in changes/cts? See the readmes in there for info.


Fix issue with scrolling when package not found

Fix issue with attempting to scroll through possible corrections when not-found package has no packages with matching names causing crash.
This behavior originates with commit 6624ecb3b85e82e9f1a08823f6e41ee805d35a9e, to my knowledge, where pacman rules were created. In both uses of get_pkgfile (in pacman.py and in pacman_not_found.py), it would be appropriate for get_pkgfile to return an empty list when the pkgfile does not find any packages by the correct name. However, the pkgfile command returns 1 in these circumstances, and as such subprocess raises an exception. Now, when this exception is caused by pkgfile returning 1 with no output (when it finds no packages), get_pkgfile will not cause a crash.

Good catch, @awonnacott! :+1:
Can you please add a test case for it?
Thanks!

I'm not familiar with your testing framework, but I'll look into it.

Thanks!