Archi cannot run on macOS 10.15 Catalina

Version of Archi, Operating System
Archi 4.6.0
macOS 10.15.1 (19B88)
Expected Behaviour
Archimate should run when opening the Archi.app
Actual Behaviour
An error message pops up (see below). This is related to #445, however the solution proposed there does not work in macOS Catalina. The setting "Allow apps downloaded from:" can no longer be changed to "Anywhere" due to Gatekeeper.
Steps to Reproduce the Behaviour

Download Archi for macOS
Run it (double click or right click open)
Observe the error message

This is a known issue and we have documented this:

In the special README!.txt file that ships with Archi on Mac.
At the point of download on the download page
In the Archi FAQ
On the Archi forum https://forum.archimatetool.com/index.php?topic=765.0

And for anyone who is unable to read any of those, here it is again:
If your Mac states that it cannot run Archi because it is "damaged" (it isn't) run the following command from the Terminal app.
 sudo xattr -r -d com.apple.quarantine Archi.app

This will remove the quarantine bit from the Archi application to allow it to run.
(You will need to adjust the path to Archi.app or change the current directory to the location of Archi.app in Terminal.)
For more information see https://derflounder.wordpress.com/2012/11/20/clearing-the-quarantine-extended-attribute-from-downloaded-applications/

Thanks for the reply. tbh, I did not notice this on the download page.


SSL certificate problem

Issue Summary
Hi,
it seems like i have a problem with sending mail using sengrid.
Everything was working fine yesterday, but I just can't send a mail today.
What happend in beetween (the change occured at 4pm yesterday french hour).
Here is the error I get:
Exception::__set_state(array( 'message' => 'SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'string' => '', 'code' => 0, 'file' => '/home/gouvimpo/diagnostic-experts/includes/classes/SendGridtest/vendor/mashape/unirest-php/lib/Unirest/Unirest.php', 'line' => 209, 'trace' => array ( 0 => array ( 'file' => '/home/gouvimpo/diagnostic-experts/includes/classes/SendGridtest/vendor/mashape/unirest-php/lib/Unirest/Unirest.php', 'line' => 71, 'function' => 'request', 'class' => 'Unirest', 'type' => '::', 'args' => array ( 0 => 'POST', 1 => 'https://api.sendgrid.com/api/mail.send.json', 2 => array ( 'to' =><EMAIL_ADDRESS>'from' =><EMAIL_ADDRESS>'x-smtpapi' => '{"to":["xxxx@xxxxxxxx"],"category":["xxxxxxxx"]}', 'subject' => 'xxxxxx', 'text' => NULL, 'html' =>
Any advice or Idea would be nice, should I update my sendgrid lib version?
Thank for you valuable help!
Regards.
Steps to Reproduce
I'll just simplify my code here:
include('../../includes/classes/SendGridtest/vendor/autoload.php');
$from =<EMAIL_ADDRESS>$html_mail="blablabla";
$sujet = "XXXXX";

// $objMail= new mailer();
$sendgrid = new SendGrid('XXX', 'XXXX');
$mail = new SendGrid\Email();
try {
    $mail->addCategory("XXXXX");
    $mail->addTo(XXXX)->
    setFrom($from)->
    setSubject($sujet)->

    setHtml(($html_mail));
    $response = $sendgrid->send($mail);

    if (!$response) {
        throw new Exception("Did not receive response.");
    } else if ($response->message && $response->message == "error") {
        throw new Exception("Received error: " . join(", ", $response->errors));
    } else {
        //print_r($response);
    }
} catch (Exception $e) {
    var_export($e);
}

Any other information you want to share that is relevant to the issue being reported. Especially, why do you consider this to be a bug? What do you expect to happen instead?
Technical details:

sendgrid-php Version:  const VERSION = "2.0.3";
PHP Version 5.5.38

Hello @cisqo,
I can verify that nothing changed with this library during that time frame.
I suggest you reach out to our support team to see if something changed regarding our certificate. If it did not, you might want to check the configuration on server.
With Best Regards,
Elmer

Same issue happen with me as well.

Hello @imbhavin95,
Please reach out to our support team at https://support.sendgrid.com. Thank you!
With best regards,
Elmer


feat: calculate piece metadata digest

Signed-off-by: Jim Ma<EMAIL_ADDRESS>
Description

Related Issue

Motivation and Context

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation Update (if none of the other choices apply)

Checklist:

[ ] Code compiles correctly.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Codecov Report

Merging #787 (ce5c210) into main (ec8ede0) will decrease coverage by 0.18%.
The diff coverage is 18.57%.

@@            Coverage Diff             @@
##             main     #787      +/-   ##
==========================================
- Coverage   39.58%   39.40%   -0.19%
==========================================
  Files          94       94
  Lines        7647     7713      +66
==========================================
+ Hits         3027     3039      +12
- Misses       4226     4278      +52
- Partials      394      396       +2

Flag
Coverage Δ

Object-compatibility-e2etests
?

e2etests
?

unittests
39.40% <18.57%> (-0.19%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

client/daemon/daemon.go
0.00% <0.00%> (ø)

client/daemon/peer/peertask_file.go
52.55% <0.00%> (-0.92%)
:arrow_down:

client/daemon/peer/peertask_manager.go
20.14% <0.00%> (ø)

client/daemon/peer/peertask_stream.go
53.12% <0.00%> (-1.48%)
:arrow_down:

client/daemon/peer/piece_manager.go
68.11% <ø> (ø)

client/daemon/storage/local_storage.go
27.46% <0.00%> (-1.76%)
:arrow_down:

client/daemon/storage/storage_manager.go
21.48% <11.11%> (-0.28%)
:arrow_down:

client/daemon/peer/peertask_base.go
33.87% <30.00%> (+0.40%)
:arrow_up:

client/daemon/peer/peertask_file_callback.go
57.28% <33.33%> (-3.16%)
:arrow_down:

client/daemon/peer/peertask_stream_callback.go
58.41% <33.33%> (-3.39%)
:arrow_down:

... and 3 more


Update query in Gravwell kit to use regex better

It wasn't using the -e flag to look at the extracted field; this fixes it. (I was seeing stray double-quotes in results)
Also does a little dance to update the MANIFEST file:
kitctl pack /tmp/foo.kit
kitctl import /tmp/foo.kit
This updates the hashes and also ensures that all JSON is properly formatted.

ptal


Homebrew install on macOS broken

Checklist

[ ] I'm reporting a broken site support issue
[ ] I've verified that I'm running youtube-dl version 2021.12.17
[ ] I've checked that all provided URLs are alive and playable in a browser
[ ] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar bug reports including closed ones
[X] I've read bugs section in FAQ

Verbose log

PASTE VERBOSE LOG HERE

Description

I have a new copy of Homebrew installed on my new laptop. Trying to install youtube-dl throws the following error, just FYI.

% brew install youtube-dl
Error: youtube-dl has been disabled because it has a failing test since forever and no new release since 2021! It was disabled on 2024-11-23.

https://github.com/ytdl-org/youtube-dl/issues/32982#issuecomment-2504964353


feat(KONFLUX-5297): Adding rules to detect Tekton Resolver leases not distributed correctly

If you rebase on main that policy failure should go away now that https://github.com/redhat-appstudio/o11y/pull/413 is merged.

Thank you! Rebased.


Generate user information

Adds a button to generate user information
Solves #95.

@drdgvhbh thanks for this, much appreciated! :)

Closes #95


[ci] Don't test on MIPS

MIPS targets have been consistently unavailable recently, which has blocked our ability to roll the nightly toolchain.

Alternatively, we could do -Z build-std, but if there isn't a clear reason why we should be running CI on MIPS (e.g., it has uniquely interesting properties), then cutting it out is fine.

Yeah it was just a "let's test on as many targets as possible" thing; no reason to test on mips in particular.


Missing staticfile readme

Summary
Note what to do if missing static file error appears in tests
How to test

Codecov Report

Merging #75 (6d18500) into main (7f79355) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #75   +/-   ##
=======================================
  Coverage   95.10%   95.10%
=======================================
  Files          11       11
  Lines         654      654
=======================================
  Hits          622      622
  Misses         32       32

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 7f79355...6d18500. Read the comment docs.

Yes, this is still relevant. Merging.


Still developed?

Is this still being developed?
What features are planned?

Hey. Yes the project is still in development. But currently I only maintaing updates.
In the future I plane to refactore the server and controller so it should easier to add external apps (linke a app store).
Also try to use direkt communication between controller ans server (so that the view data not using MQTT anymore).
But starting after the summer.
Do you have any nice ideas for the project?
Best regards
René

publish roadmap soon

publish roadmap soon


Run with the error: Ran out of input

Hi, it may happen when you fail to completely generate all the binary inputs.
You can remove the generated binary files in the dataset folder and try again.

Hi, it is like what @yzhouas said. You can directly remove the folder named "bin" of the train and test dataset, and retrain the model you will find that the new binary inputs are generated again.


data.xmldata Module Fails to Deserialize Semantically Equivalent XMLs to Records

Description:
The xmldata module in Ballerina fails to correctly deserialize XMLs to records when only the namespace prefixes are changed, despite the XMLs being semantically equivalent. This issue occurs when deserializing an XML with a different namespace prefix than what was used during serialization, even though the namespace URIs are the same.
Consider the following XML and record:
Initial XML
<root xmlns:ex="http://www.example.com/schema">
    <ex:item>Example Item</ex:item>
</root>

Corresponding Record:
@xmldata:Name {value: "root"}
type Root record {
    @xmldata:Namespace {prefix: "ex", uri: "http://www.example.com/schema"}
    string item;
};

Serialization:
Root root = {
    item: "Example Item"
};
xml|error xmlData = xmldata:toXml(root);
// This works fine;

If I change the resulting XML to:
<root xmlns:abc="http://www.example.com/schema">
    <abc:item>Example Item</abc:item>
</root>

Deserialization:
Root newRoot = check xmldata:parseAsType(xmlData);

Actual Result:
Deserialization fails with the error
Expected Behavior:
When the XML documents are semantically equivalent (identical URIs, differing only in prefix), the xmldata module should successfully serialize and deserialize the XML without errors.
Steps to reproduce:

Define a Ballerina record with namespace information.
Serialize the record to XML using xmldata:toXml().
Modify the resulting XML by changing the namespace prefix (but not the URI).
Attempt to deserialize the modified XML back to the record using xmldata:parseAsType().

Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

I think the deserialization behavior is correct, as per the discussion here, https://github.com/ballerina-platform/ballerina-spec/issues/1268. both xml values are not ==. That is based for the data.xmldata design.

Since this is one of the common use cases, we can relax strict equality, and make the semantic equality work for the common case by default. To enable strict equality we can provide an option. @prakanth97 WDYT?

Since this is one of the common use cases, we can relax strict equality, and make the semantic equality work for the common case by default. To enable strict equality we can provide an option. @prakanth97 WDYT?

Agree. Seems like better option.


On hover a table row - change backgroundColor style

Hi,
I want to change the color of the default on hover row background.
I'm trying to override the MUITheme of the on hover row with this code:
const theme = createMuiTheme({   overrides: {     MuiTableRow: {       hover: {         backgroundColor: "rgba(0, 97, 250, 0.03)"       }     }, ...
But the result is that the background color changed to my custom color but on hover, nothing changed.
It's possible?

goo

This is possible, you can target it with JSS:
https://codesandbox.io/s/muidatatables-custom-toolbar-forked-pd6xg?file=/index.js
Unfortunately I'm not sure how to target an element with 2 classes on it, thus I'm resorting to using "!important" to force the hover override (the rule with the CSS default hover color is ".MuiTableRow-root.MuiTableRow-hover:hover").

This is possible, you can target it with JSS:
https://codesandbox.io/s/muidatatables-custom-toolbar-forked-pd6xg?file=/index.js
Unfortunately I'm not sure how to target an element with 2 classes on it, thus I'm resorting to using "!important" to force the hover override (the rule with the CSS default hover color is ".MuiTableRow-root.MuiTableRow-hover:hover").
  let getMuiTheme = () => createMuiTheme({
    overrides: {
      MuiTableRow: {
        root: {
          '&:hover': {
            backgroundColor: 'yellow !important'
          }
        }
      },
    }
  });

Any solution without the 'important' ?

I've updated the example, the below code will work without "!important". I could have sworn I tried this previously and it didn't work, but I was probably just tired.
    createMuiTheme({
      overrides: {
        MuiTableRow: {
          root: {
            "&.MuiTableRow-hover": {
              "&:hover": {
                backgroundColor: "yellow"
              }
            }
          }
        }
      }
    });

I've updated the example, the below code will work without "!important". I could have sworn I tried this previously and it didn't work, but I was probably just tired.
    createMuiTheme({
      overrides: {
        MuiTableRow: {
          root: {
            "&.MuiTableRow-hover": {
              "&:hover": {
                backgroundColor: "yellow"
              }
            }
          }
        }
      }
    });

Thank you!
I'm actually found another solution:
let getMuiTheme = () => createMuiTheme({
overrides: {
MuiTableRow: {
root: {
'&:hover': {
backgroundColor: 'yellow' // without important
}
}
},
}
});
then add to your table options: {{    rowHover: false, ... }}


Add public API

I use scour as a module in a web app. Previously, I was doing this:
    opts = scour.parse_args(args=[...])[0]
    output = scour.scourString(svg, opts)

But that fails in version 0.35, because parse_args now returns a single object instead of a tuple. The fix is easy; however, it would be nice to have a public API that would remain stable for a given major version number.

Yes, this is definitely something we want to offer.
To be able to assess this better:

What would you need/expect from a public API?
 I'd considered this function more or less private since I suspected argument handling is something every Python program does on its own...

My thoughts on what a minimal API should offer at least:

I guess something equivalent to scourString() is essential, probably we could also expose scourXmlFile()
For generating an options object we currently have generateDefaultOptions() and sanitizeOptions(). I'd suggest to expose something in the API that's basically a merged version of those two (i.e. a function that can be called without arguments to generate default options or with an existing options object to sanitize them).

I just created #121. Does this sound reasonable to you guys?
Any complaints @oberstet? Seems these are the parts that are less well documented in the Python world, but the current state looks quite workable from a usability point of view.

Hi @Ede123, thanks for that - yes, that would suit our purposes very well.

Simply to get an options object; I had just mimicked the operation of run. I didn't know about generateDefaultOptions.

What would you need/expect from a public API?

Your suggestions are fine, and suit us well. The only thing I'd add is it's sometimes nice to have a builder-like API - but don't go to the effort of implementing it on my behalf, because I don't need it:
options = options().with_quiet(True)

Here is a proposal for a public API in Python 3 type annotated syntax:
def options(options: Optional[dict]) -> dict:
    """
    Returns a dictionary including attributes for all Scour options, either set to
    (normalized) values from the input options, or set to default values.
    The dictionary is JSON serializable (it only contains simple, serializable types).
    """

def scour_string(doc: str, options: Optional[dict]) -> str
    """
    Clean the SVG given in the string and return the clean SVG. The options must be
    created from `options()`.
    """

Oh Hi! Was there any news?
I was also looking for a module way of using scour as there is nothing advertised in the readme. So far I did this:
from scour import scour
options = scour.parse_args()
options.infilename = in_path
options.outfilename = out_path

in_file, out_file = scour.getInOut(options)
scour.start(options, in_file, out_file)

I like the option object a lot already! So I was wondering if it could be available from /scour/__init__.py?
Oooops. I see 🙊 already done. kind of. Well I'd offer an explicit function for dictionary input in case its wanted.
But extra methods on the options object are nice! As I use ^ infilename, outfilename I'd then use:
options.start()
which writes to the given outfilename already.
In any way the resulting svg code ends up in options.result. If no outfilename is given one can get the code string there as well... 🤔


CLI cannot reach registry

Is this a feature request or a bug?
Bug

Expected behavior:
CLI can reach registry.entropic.dev
Actual behavior:
Failing due to registry not having a IPv6 record
See:
https://ready.chair6.net/?url=https%3A%2F%2Fregistry.entropic.dev
Proposal
Revert #177
Close #183
After revert:

Steps to replicate:

cd cli
node ./lib/main.js whoami

Environment info

OS: Arch Linux x86_64
Version of Node:  12.3.0
Version of ds: master branch

this is working with node  version 12.5.0

I think other people had ( still have? ) this issue. Not really a Node specific issue as much it is an IP address issue


Request permission to use geoLocation API, in different browsers.

This has different ,if very slight implementations in Chrome and Mozilla, however, the other browsers do not properly support this -> request permission.
What I have done with the geolocation branch is to fall back on a default location if there is an error getting a lock on location be it from permission denial or inability to request for permission. @jeffgodwyll have a look.

however, the other browsers do not properly support this -> request permission.

@JeanHuit
I haven't reviewed the code, but I just opened the site in Chrome, Firefox and Safari. Chrome and Firefox got my location.(Share box popped up)

chrome
firefox
safari

version
57.0.2950.4 dev (64-bit)
rv:50.0
9.1.2 (11601.7.7)

request permission prompt
yes
yes
yes

gets location
yes
yes
no(fall's back to default)

I guess the work done is solid in this case.

I also realised it. Later. They all  do request for the use of the location, except safari.
Cool

I also realised it. Later. They all  do request for the use of the location, except safari.
Cool


FT: AZURE COPY OBJECT

PR has been updated. Reviewers, please be cautious.

@ironman-machine r+

:hourglass: PR is now pending. CI build url: http://ci.ironmann.io/gh/scality/Integration/15159

Hello @nicolas2bert
"r+": Success

:broken_heart: :hourglass: circleCI test timed out...

@ironman-machine r+

:hourglass: PR is now pending. CI build url: http://ci.ironmann.io/gh/scality/Integration/15160

Hello @nicolas2bert
"r+": Success

:sunny: :+1: circleCI test succeeded!


read messages to be published from stdin

This PR contains the commits of #1, please merge that first.

Reading messages from stdin lets one work with all the useful streaming command line tools, e.g. curl 'http://example.org/ids.txt' | grep 123 | ants-cli --stdin some-subject.

Thanks for the contribution @derhuerst!
Can i get you to fix the lint issues, use npm run lint to see them. I will merge when its clean.
Same goes for #1.

Can i get you to fix the lint issues, use npm run lint to see them. I will merge when its clean.

Right, I somehow missed that, will do.

I have fixed the linting issues in both PRs.


[BUG] pydantic.error_wrappers.ValidationError

Describe the bug
I get the following Error after updating to 0.12.6. It get's spammed every 5 seconds in the log
Mai 24 11:54:37 benno lnbits[2485199]: 2024-05-24 11:54:37.37 | ERROR | exception in background task `unnamed`:
Mai 24 11:54:37 benno lnbits[2485199]: 2024-05-24 11:54:37.37 | ERROR | pydantic.error_wrappers.ValidationError: 1 validation error for Proof
Mai 24 11:54:37 benno lnbits[2485199]: Y
Mai 24 11:54:37 benno lnbits[2485199]:   none is not an allowed value (type=type_error.none.not_allowed)
Mai 24 11:54:37 benno lnbits[2485199]: 2024-05-24 11:54:37.37 | ERROR | will restart the task in 5 seconds.

To Reproduce
Update from 0.12.5 to 0.12.6 and run clightning v24.02.2 backend.
Expected behavior
No Error

LNbits version: 0.12.6
Database sqlite,

hotfix release 0.12.7 should fix this

I updated to 0.12.8 but this error spam is still there

Are you running the cashu extension?  This looks like https://github.com/lnbits/cashu/issues/69.

Yes, that must be it. Thank you
I will monitor that issue from now on


[5.9] Always supersede conformances implied by pre-macro-expansion conformances

Pre-macro-expansion conformances are introduced at the point where an attached extension macro is attached to a particular nominal type, and can imply other conformances. Once the macro is expanded, they are expected to be replaced by the real conformance from the extension produced by the macro. This includes any other conformances that are implied by that conformances. Ensure that the real conformance---and every conformances it implies---are considered "better" than the pre-expansion conformances.
Fixes a bug where we would pick the wrong (pre-expansion) conformances, which would then fail to get fully type-checked prior to serialization. This could accept invalid code that then crashed the compiler, as in rdar://112916159.
Cherry-picked from https://github.com/apple/swift/pull/68028

@swift-ci please test

@swift-ci please build toolchain

@swift-ci please test


Salvage Generated Loot

Description

salvage gets a lot of boards and guns which is cool but they could use collectables that have less direct utility.
lemme break it down:
Generic Valuables

jewelry
gems (cut/uncut)
documents
generic datadisks

These are all basic items that, besides a bit of flavor, don't do much. Their one benefit is that they sell for a decent chunk of cash. This makes them an item you can scatter around salvage/dungeons without worrying about balance. This also addresses the issue where salvage struggles to find valuables to bring cargo.
Scrap Items

hunks of plastic
giants gears/cogs
shards of glass.
slag (mixed ore)
trash

These items can be refined into materials via an ore processor. The more refined pieces, like gears and whatnot, can additionally be sold for a bit more than their material costs. These serve as ways of acquiring materials in a more environmentally coherent way than simply having crates of materials lying about. They also can be an easy way of filling space since the individual value of each piece of scrap is quite low.
Large Scrap

damaged engines
boulders
collapsed rubble
large broken machines

These serve as ways of introducing basic machine parts as well as materials to salvage crew. They can also yield some of the aforementioned scrap items. They can obstruct progression into dungeons and salvages and thus must be deconstructed with tools.

A few questions:

Do the items you listed already have prototypes, or do those need to be created?
If they do need to be created, do they need associated sprites as well?

Just trying to get a grasp on the scope of this issue.

A few questions:

Do the items you listed already have prototypes, or do those need to be created?
If they do need to be created, do they need associated sprites as well?

Just trying to get a grasp on the scope of this issue.

Both prototypes and sprites would need to be created


Use expose instead of ports to avoid conflicts with the openpai service on master node.

On the master node, ports 5432 and 3000 are binded by openpai. I have been exploring the Internet for a long time before finding a solution. This solution needs to modify the Postgres port declaration to expose instead of ports in docker-compose.yml.
Before
    ports:
      - "5432:5432"

After
    expose:
      - "5432"

For more details, please refer to my Github repository siaimes/openpaimarketplace .

Solved by this PR


Incorrect class #private fields initialization order with target ES2022 and useDefineForClassFields set to false

Bug Report

🔎 Search Terms

ES2022 class field initialization order
private fields order
useDefineForClassFields false
🕗 Version & Regression Information

This changed between versions 4.9.5 and 5.0.4

⏯ Playground Link

5.0.4 with runtime error (useDefineForClassFields: false, target: ES2022)
4.9.5 without runtime error (useDefineForClassFields: false, target: ES2022)
💻 Code

class Buzz {
    wow = 'one'
}

class Foo {
    #bar = this.buz.wow;
    constructor(private buz: Buzz) {}
}

new Foo(new Buzz())

🙁 Actual behavior

With 5.0.4 and useDefineForClassFields: false, target: ES2022 the above code fails in runtime because #bar = this.buz.wow; stays initialized before constructor, this doesn't happen if "normal private" is used (private bar = this.buz.wow;). Such construct works without issues on 4.9.5.
🙂 Expected behavior

The initialization is done in the same way as on 4.9.5.

Still an issue in 5.1.3.

I don't think this is supposed to work. The fact that private fields were transpiled to an assignment inside the constructor seems like a bug, because useDefineForClassFields is only supposed to affect public properties (which can be shadowed by the base class and therefore suffers from the define vs. set issue). Private fields should always be initialized before the parameter properties, solely by how scoping works.

I don't think this is supposed to work. The fact that private fields were transpiled to an assignment inside the constructor seems like a bug, because useDefineForClassFields is only supposed to affect public properties (which can be shadowed by the base class and therefore suffers from the define vs. set issue). Private fields should always be initialized before the parameter properties, solely by how scoping works.

That's fine as long as there is an error produced on compilation time. Having this quietly passing produces a lot of hard to understand issues on run-time.

Any updates on compilation errors / order fix?

Same on 5.1.6.

I don't think this is supposed to work. The fact that private fields were transpiled to an assignment inside the constructor seems like a bug, because useDefineForClassFields is only supposed to affect public properties (which can be shadowed by the base class and therefore suffers from the define vs. set issue). Private fields should always be initialized before the parameter properties, solely by how scoping works.

@Josh-Cena if this is the expected behavior, I think that, at least, should be a compilation error....
class Buzz {
    wow = 'one'
}

class Foo {
    #bar = this.buz.wow;
                ^^^_ This is property is uninitialized... or something similar

    constructor(private buz: Buzz) {}
}

new Foo(new Buzz())

I don't think this is supposed to work. The fact that private fields were transpiled to an assignment inside the constructor seems like a bug, because useDefineForClassFields is only supposed to affect public properties (which can be shadowed by the base class and therefore suffers from the define vs. set issue). Private fields should always be initialized before the parameter properties, solely by how scoping works.

I think this is supposed to work, but didn't handle this case correctly when private fields were introduced. The ideal solution would be for parameter properties to work with both private fields and --useDefineForClassFields. For such a feature to work correctly, we would have to choose between two different behaviors:

Parameter properties are initialized before all class fields, or
Parameter properties are initialized after all class fields

Prior to the adoption of private names, the TypeScript emit followed (1), which I believe is still the best approach.
If we want to correctly preserve these semantics and this evaluation order in the presence of private names or --useDefineForClassFields, then the correct emit would be to:

declare all of the class fields, including private-named fields and those introduced by parameter properties
Initialize the fields introduced by parameter properties
Initialize the remaining fields in the order they appear in the class body.

This means moving the field initializers into the constructor body:
// source
class C {
  y = this.x;
  #z = this.y;
  constructor(public x) {}
}

// transpiled
class C {
  x;
  y;
  #z;
  constructor(x) {
    this.x = x;
    this.y = this.x;
    this.#z = this.y;
  }
}

If we want to correctly preserve these semantics and this evaluation order in the presence of private names or --useDefineForClassFields, then the correct emit would be to:

declare all of the class fields, including private-named fields and those introduced by parameter properties
Initialize the fields introduced by parameter properties
Initialize the remaining fields in the order they appear in the class body.

This means moving the field initializers into the constructor body:
// source
class C {
  y = this.x;
  #z = this.y;
  constructor(public x) {}
}

// transpiled
class C {
  x;
  y;
  #z;
  constructor(x) {
    this.x = x;
    this.y = this.x;
    this.#z = this.y;
  }
}

That's the behavior I expected. Cool to know it's an unexpected breaking change, and this issue is someting fixable :smile:

5.3.2 still affected

I forgot to mention a small workaround I wrote couple months ago. It's possible to detect wrongly defined properties using eslint and this rule:
'no-restricted-syntax': [
      'error',
      {
        selector: 'PropertyDefinition[key.type="PrivateIdentifier"]:has(ThisExpression)',
        message: 'Use `private` modifier until https://github.com/microsoft/TypeScript/issues/54206 is fixed.',
      },
    ],

Hope this helps someone to prevent runtime issues.

5.5.2 also affected


Create 0000-01-02-lordfreshD.md

technological advancements for a better life

slowly getting used to it


Add ability to build minmea with meson

Hi, is this something that you would consider merging? I'm currently writing a library that pulls in minmea as a dependency and I needed to build it with meson to do so. I thought the work done here might be useful for others who are also using the meson build system.

@kosma can you take a peek when you get a chance? thanks!

@ssloboda @mtp401

When setting up a Meson project to be usable as a subproject, you have to specify its include directories. A minmea directory was added so that client code could #include "minmea/minmea.h".
The reason why one would want to #include "minmea/minmea.h" rather than #include "minmea.h" is to avoid potential name conflicts (somewhat similar reasoning to prefixing all the functions with minmea_). While in this case, it is only one header with an uncommon name that needs to be included, not using subdirectories for your includes, to my knowledge, is generally seen as bad practice. Keeping project header files in their own directory is especially important when building and installing libraries. Just imagine how many problems would come up if the headers for every library you installed got dumped, without subdirectories, into /usr/local/include/. Adding the minmea subdirectory helps prevent this sort of include directory pollution and file name conflict. Also, this helps future-proof minmea because if at some point a new header file with a common name needs to be added, e.g., utils.h, doing so will not cause any of the problems described above.
If adding the minmea directory is a no-go, I'd still like to incorporate the build with meson changes (I've got another commit to add for library installation in a different branch) because that will be useful for developers using Meson and is a non-breaking feature addition.

Also, it's been a while since I've read through the Meson docs, but I don't think it's possible to optionally fake a minmea directory for subproject includes. It's easy to optionally add a prefix when installing as a library to the system.

@ssloboda any reason you can't place minmea in a subdirectory on your own end to avoid having to move the files within this repository? I can't imagine everyone integrating libraries with meson is looking to move their location in upstream repos.

@ssloboda any reason you can't place minmea in a subdirectory on your own end to avoid having to move the files within this repository? I can't imagine everyone integrating libraries with meson is looking to move their location in upstream repos.

This can be closed if the maintainers of minmea are not interested in first class meson support. We'll contribute a wrap to Meson's wrapdb instead.

The reason why one would want to #include "minmea/minmea.h" rather than #include "minmea.h" is to avoid potential name conflicts (somewhat similar reasoning to prefixing all the functions with minmea_). While in this case, it is only one header with an uncommon name that needs to be included, not using subdirectories for your includes, to my knowledge, is generally seen as bad practice. Keeping project header files in their own directory is especially important when building and installing libraries. Just imagine how many problems would come up if the headers for every library you installed got dumped, without subdirectories, into /usr/local/include/. Adding the minmea subdirectory helps prevent this sort of include directory pollution and file name conflict. Also, this helps future-proof minmea because if at some point a new header file with a common name needs to be added, e.g., utils.h, doing so will not cause any of the problems described above.

Actually, many libraries install headers directly to /usr/local/include/ and expect users to use #include <foolib.h> -- the difference is that these libraries carefully maintain a public header API in a single file with a distinctive name.
Or sometimes they do it in multiple files with distinctive names. <foolib.h> and <foolib_utils.h>.
Many projects also install everything to a subdir #include <foolib/foolib.h>.
A third choice, yes that's right there's three of them, is that the files get installed to /usr/local/include/foolib/ but that gets added as the includedir on the compiler command line, and users still use #include <foolib.h>.
These are valid decisions, but it should in fact be a decision of the project. In general, the subdir approach tends to be taken by projects that expect to have a bunch of header files, and the no-subdir approach tends to be taken by projects that expect to have one or two header files.
Is there a serious concern that this project will grow to include many publicly installed header files?
...
Either way, with my Meson core dev hat on...
Meson does not care which approach is taken, it supports and is used for both.
What Meson does care about, is that in order for use via the wrap subprojects system, whatever include name the project expects downstream consumers to use in their source code, i.e. #include <foolib.h> or #include <foolib/foolib.h>, needs to be an on-disk file structure in the repository so that the in-tree version can be passed as a compiler include directory. This is an actual good practice.
Failure to do this means that Meson will still support building and installing the project, but will not support adding the project as a git submodule to another project and building it as a vendored copy as described in https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section
...
If the project expects people to do #include <minmea.h> then no changes need be made to the file structure here.
This conversation should NOT focus on implementing moving files around the source tree, but rather focus on convincing the project maintainers of the relative merits of different styles of includes, and then work backwards from there to implement the desired approach.

@eli-schwartz @ssloboda is it ok if only the header file is moved into a minmea/ subdirectory? As the library (.a file) would remain in the parent folder during install but the header would go into the subdir?
Would that let you use the meson build in your repo without pulling it in here? If we pulled it in here we'd have to maintain it etc... and there are a lot of build systems.

@chmorgan,
if someone uses minmea in their own project, what would you recommend they use as a header #include?

@eli-schwartz it would depend where they put the header files. If you put minmea into a 'minmea' folder you could add the containing folder to your search path and #include "minmea/minmea.h", or add minmea to your include path and #include minmea.h".
It feels like I'm misunderstanding the question though.

The question is what should be the canonical way, not what is technologically possible. :)

The include for minmea is #include <minmea.h>. It's a single-file library by design, so subfolders are not needed, not necessary, and not wanted.


jsx support without readtable via template syntax?

Is there any way to implement macro that produces jsx code from template syntax? Something like:
syntax jsx = function(ctx) {
  // This doesn't work :-(
  let v = ctx.expand('TemplateExpression');
  return #`{v}`;
};

const el = jsx`<h1/>`;

that produces:
const el = <h1/>;

After all macros have been expanded the code must be valid JavaScript so you can't have a macro expand to <h1/> since that would be a parse error.
However, if you are willing to use a prefix to implement something like jsx you can do:
syntax jsx = ctx => {
  if (/* consume the syntax <h1/> */) {
    return #`createH1()`; // or whatever the API is, I don't know jsx
  }
}
const el = jsx <h1/>;

Hm, yes. I guess, I can try to attach babel with JSX plugin and use it like this. Thanks!


Customize floatingLabelStyle for error in InputDecorationTheme

Use case
I want to customize my TextField entirely through themeData so I don't have to create a specific widget as a wrapper for it.
Right now my form field looks like this:

InputDecorationTheme doesn't expose any parameters to customize textStyle of floatingLabel when validating textField with an error. I can't change the color of the floatingLabel when focused on the textField, and unfocusing it makes the label take the default dark theme error color.

Proposal
Give inputDecorationTheme optional parameters focusedErrorFloatingLabelStyle and errorFloatingLabelStyle.

Hey @BuyMyBeard, thanks for submitting this issue!
If/when my pull request is merged and included in a release, you'll be able to do the following:
const inputDecorationTheme = InputDecorationTheme(
  floatingLabelStyle: InputDecorationStyle(
    normal: TextStyle(color: Colors.orange),
    error: TextStyle(color: Colors.red),
    focusedError: TextStyle(color: Colors.redAccent),
  ),
);

For now, feel free to use this:
final inputDecorationTheme = InputDecorationTheme(
  floatingLabelStyle: MaterialStateTextStyle.resolveWith((states) {
    if (states.contains(MaterialState.error)) {
      if (states.contains(MaterialState.focused)) {
        return const TextStyle(color: Colors.redAccent);
      }
      return const TextStyle(color: Colors.red);
    }
    return const TextStyle(color: Colors.orange);
  }),
);

It looks like a convenient floatingLabelStyle constructor won't be added anytime soon.
For now, the best solution is to extend the MaterialStateTextStyle class or to use its .resolveWith() constructor.

Update: WidgetState.map() constructor has been implemented, tests are passing, and PR is approved!
Just waiting on a final thumbs-up and we'll be good to go 👍👍

New WidgetStateProperty constructor just dropped:
const InputDecorationTheme(
  floatingLabelStyle: WidgetStateTextStyle.fromMap({
    WidgetState.error:   TextStyle(color: AppColor.red),
    WidgetState.focused: TextStyle(color: AppColor.orange),
    WidgetState.any:     TextStyle(color: AppColor.grey),
  }),
),


[Feature][dolphinscheduler-alert-plugins] add alert plugin aliyun-voice

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
add a alert plugin aliyun-voice
Use case
No response
Related issues
No response
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

[Feature-15148][dolphinscheduler-alert-plugins] add alert plugin aliyun-voice


Migrate all CSVs to bundle format

 Migrate Operators to bundle packaging format and distribution

I'm going to change this up quite a bit I think, so definitely don't merge this as-is.

I'm changing approaches. I confirmed it'll work last night and makes everything significantly simpler. Closing this and will open something new.


Feature Request: Ability to add to a Group

ability to add to a group in transmissions

Hey,
I'm afraid I can't understand your request.
Can you please clarify?
Thanks!

Could it be considered on label in 3.4 line 427

@gotzlotz You may be right. I'll give it a play when I have some time.

Thanks...


leafletLayersControl not updated when dynamically adding a new layer in overlays

Scenario:
in my layersControl:
layersControl = {
overlays: {
City: L.tileLayer.wms(....),
Airport: L.tileLayer.wms(.....)
}
};
when I work in my compoent.ts, when I click on the map, I will base on the lat lon to place a marker on the map and dynamically add a new layer by geojson data, and I want the geojson layer added into the overlay, so I do the following:
const style = {
color: '#666',
weight: 5.0,
opacity: 0.5,
fill: false
};
const cafe = new L.geoJSON(cafe_data, {style: function() { return style; } } );
const cafe_name = cafe_data[0];
this.layersControl.overlays[cafe_name] = cafe;
this.layersControl.overlays[cafe_name].addTo(this.map);
Outcome:
I can see the layer on the map, but the layerscontrol is not updated.
But if I uncheck and check other existing overlays (e.g. City), the newly added overlay will be appear on the layerscontrol.
Is it due to the applyOverlayChanges function in LeafletControlLayersWrapper class not activated?
Thank you.
Regards,
James

Can you provide more of the context of the code above (and format it properly)?
Also, which version on ngx-leaflet are you using?
It's likely that something is causing change detection to not work. You shouldn't have to manually call ".addTo(this.map)" as the plugin handles that for you. Depending on the event you're responding to when you add the new overlay, you may need to run the change in the Angular zone or invoke change detection manually.
Thanks!

The issue fixed when I upgraded the library to version 4.0.0, thank you.


Unicode objects with non-ascii characters throw UnicodeEncodingError exception (instead of RepeatedLabelError)

This code is only a couple dozen lines long, so how is it possible it has a bug? Unicode, that's how.
When this error is thrown and the input is a unicode object containing non-ascii characters, this code throws something like this:
Error
Traceback (most recent call last):
  File "/home/mlissner/Programming/intellij/courtlistener/cl/lib/tests.py", line 554, in test_normalize_atty_contact
    result = normalize_attorney_contact(pair['q'])
  File "/home/mlissner/Programming/intellij/courtlistener/cl/lib/pacer.py", line 439, in normalize_attorney_contact
    tag_mapping=mapping,
  File "/home/mlissner/.virtualenvs/courtlistener/local/lib/python2.7/site-packages/usaddress/__init__.py", line 178, in tag
    label)
  File "/home/mlissner/.virtualenvs/courtlistener/local/lib/python2.7/site-packages/probableparsing/__init__.py", line 22, in __init__
    repo_url=self.REPO_URL)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 55: ordinal not in range(128)

This is unfortunate because my calling code is designed to catch RepeatedLabelErrors not UnicodeEncodeErrors (and ideally it'd stay that way).
I guess the solution is to assume that people are going to use unicode within their code instead of strings, and to tweak the code by adding a u before the definition of MESSAGE and DOCS_MESSAGE. When I do that, it fixes the bug.
What I haven't thought through is what happens if people are using strings in the parser instead of using unicode objects. In that case, do things get better or worse?

You are right that the fix is to make sure that the right fix is to make sure that MESSAGE and DOCS_MESSAGE are unicode.
Would you mind making that PR to https://github.com/datamade/probableparsing


bug: InvalidFEOpcode when calling getPricesInWei on Arbitrum: ArbGasInfo

Component
Anvil
Have you ensured that all of these are up to date?

[X] Foundry
[ ] Foundryup

What version of Foundry are you on?
forge 0.2.0 (1281421 2024-04-05T00:17:33.105023260Z)
What command(s) is the bug in?
anvil --fork-url https://arbitrum-one.chainnodes.org/key  --fork-block-number 195292367 --fork-chain-id 42161 --chain-id 42161
Operating System
Linux
Describe the bug
When I run getPricesInWei on the arbitrum gas info contract at address 0x000000000000000000000000000000000000006C I get the following error:
Error: missing revert data (action="call", data=null, reason=null, transaction={ "data": "0x41b247a8", "to": "0x000000000000000000000000000000000000006C" }, invocation=null, revert=null, code=CALL_EXCEPTION, version=6.11.1)
    at makeError (/home/mike/dev/node/unibalancer/node_modules/ethers/src.ts/utils/errors.ts:694:21)
    at getBuiltinCallException (/home/mike/dev/node/unibalancer/node_modules/ethers/src.ts/abi/abi-coder.ts:118:21)
    at Function.getBuiltinCallException (/home/mike/dev/node/unibalancer/node_modules/ethers/src.ts/abi/abi-coder.ts:235:16)
    at JsonRpcProvider.getRpcError (/home/mike/dev/node/unibalancer/node_modules/ethers/src.ts/providers/provider-jsonrpc.ts:979:32)
    at <anonymous> (/home/mike/dev/node/unibalancer/node_modules/ethers/src.ts/providers/provider-jsonrpc.ts:563:45)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'CALL_EXCEPTION',
  action: 'call',
  data: null,
  reason: null,
  transaction: {
    to: '0x000000000000000000000000000000000000006C',
    data: '0x41b247a8'
  },
  invocation: null,
  revert: null,
  shortMessage: 'missing revert data',
  info: {
    error: { code: -32603, message: 'EVM error InvalidFEOpcode' },
    payload: {
      method: 'eth_call',
      params: [
        {
          to: '0x000000000000000000000000000000000000006c',
          data: '0x41b247a8'
        },
        '0xba3ecd3'
      ],
      id: 3,
      jsonrpc: '2.0'
    }
  }
}

Here is the type script snippet to reproduce
import { Contract, JsonRpcProvider } from "ethers";

const ARB_GASINFO_ADDRESS = "0x000000000000000000000000000000000000006C";

const _abi = [
    {
        inputs: [],
        name: "getPricesInWei",
        outputs: [
            {
                internalType: "uint256",
                name: "",
                type: "uint256",
            },
            {
                internalType: "uint256",
                name: "",
                type: "uint256",
            },
            {
                internalType: "uint256",
                name: "",
                type: "uint256",
            },
            {
                internalType: "uint256",
                name: "",
                type: "uint256",
            },
            {
                internalType: "uint256",
                name: "",
                type: "uint256",
            },
            {
                internalType: "uint256",
                name: "",
                type: "uint256",
            },
        ],
        stateMutability: "view",
        type: "function",
    },
];

(async function(){
    //const provider = new JsonRpcProvider("https://arb-pokt.nodies.app");
    const provider = new JsonRpcProvider("http://<IP_ADDRESS>:8545");
    const contract = new Contract(ARB_GASINFO_ADDRESS, _abi, provider);

    const blockTag = await provider.getBlockNumber();

    console.log( "blockTag=", blockTag );

    const result = await contract.getPricesInWei({
        blockTag
    });

    console.log( "result=", result );
})();

Notably, it works on the live mainnet node.
Thanks so much.

ah yes this makes sense
https://arbiscan.io/address/0x000000000000000000000000000000000000006C#code
support for arb precompiles/deploys are being investigated here: #7498
and some parts of ArbGasInfo precompile can probably be supported natively

cc https://github.com/foundry-rs/foundry/pull/7754

Im getting this same issue now that ive migrated my fork tests to Arbitrum
Any update on this or temporary alleveations?
is this a temporary fix: https://github.com/foundry-rs/foundry/issues/7498 ?
if so, not sure how i would go about injecting the precompile into anvil

update:
this can be alleviated with vm.etch as seen here https://book.getfoundry.sh/cheatcodes/etch


AppImage build fails

Describe the bug
The AppImage build has been failing as of late. It's been temporarily disabled for now, but the last failure can be seen here.
@swiesmann would you be able to look into this?

I took a look at this and the pkg2appimage folks seem to require ubuntu 18.04 builders to garantee that the deb package is compatible.
https://github.com/AppImageCommunity/pkg2appimage/issues/530
Maybe  i'll look into a workaround? off the top of my head we can try to force dpkg-deb -b to use older compression, or we can try to recompress the package before running pkg2appimage


Search in open editors on windows: only files opened this session searched

Open a few files from a workspace (including files not at the root of the workspace). Search in open editors for the regex .*. See full set of results. Now reload, search again. Only the opened editors are searched.

\closedWith 660d6b82f85fdf438c01f152a77a1d3d4cf85722

\closedWith 660d6b82f85fdf438c01f152a77a1d3d4cf85722

fix is still not out, it should handle that case.

fix is still not out, it should handle that case.

Here is a demo immediately following a reload.  All 4 files contain the search query:

Note that test-bed-snippets.code-snippets in in the workspace and is found without first touching the file.
    C:\Users\Mark\OneDrive\Test Bed\.vscode\test-bed-snippets.code-snippets
The other two global snippets files are NOT in the workspace and are not found via Search Only in Open Files.  Their paths:
    C:\Users\Mark\AppData\Roaming\Code - Insiders\User\snippets\global.code-snippets
    C:\Users\Mark\AppData\Roaming\Code - Insiders\User\snippets\insiders.code-snippets
Admittedly an edge case, doing a search for a term in these global snippets files without having touched them first.
Version: 1.53.0-insider (user setup)
Commit: 5a52bc29d5e9bc419077552d336ea26d904299fa
Date: 2021-01-29T05:13:48.533Z
Electron: 11.2.1
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.21301

Here is a demo immediately following a reload.  All 4 files contain the search query:

Note that test-bed-snippets.code-snippets in in the workspace and is found without first touching the file.
    C:\Users\Mark\OneDrive\Test Bed\.vscode\test-bed-snippets.code-snippets
The other two global snippets files are NOT in the workspace and are not found via Search Only in Open Files.  Their paths:
    C:\Users\Mark\AppData\Roaming\Code - Insiders\User\snippets\global.code-snippets
    C:\Users\Mark\AppData\Roaming\Code - Insiders\User\snippets\insiders.code-snippets
Admittedly an edge case, doing a search for a term in these global snippets files without having touched them first.
Version: 1.53.0-insider (user setup)
Commit: 5a52bc29d5e9bc419077552d336ea26d904299fa
Date: 2021-01-29T05:13:48.533Z
Electron: 11.2.1
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.21301

That's interesting, does this only apply for .code-snippets files or or any out-of-workspace files?

That's interesting, does this only apply for .code-snippets files or or any out-of-workspace files?

I think just the .code-snippets files.  At least no problem for these files:
    C: \Users\Mark\test.js                                             <= no workspace
    C: \Users\Mark\folder - operations\extension.js    <= a different workspace

I think just the .code-snippets files.  At least no problem for these files:
    C: \Users\Mark\test.js                                             <= no workspace
    C: \Users\Mark\folder - operations\extension.js    <= a different workspace

How bizarre. Created an issue.

How bizarre. Created an issue.


nuScenes dataset

How to visualize the detection results in the nuScenes dataset

Did you searched through the issues finding the best match?


Get JSON from more than one site

Is it possible to extend the api section in the config file to get JSON from multiple sites?

the answer is no sorry.


Investigate SEVERE UNKNOWN GATEWAY EVENT after login

Does not interfere with normal operation, seems like.
[2023-03-17 18:38:15.252259] [INFO] [Connection Manager] Connected and ready! Logged as `...`
[2023-03-17 18:38:15.252746] [FINE] [Shard 0] Handling received message from runner
[2023-03-17 18:38:15.253303] [FINER] [Shard 0] Sequence: -3
Data: {t: SESSIONS_REPLACE, s: 2, op: 0, d: [{status: dnd, session_id: ..., client_info: {version: 0, os: other, client: web}, activities: []}]}
[2023-03-17 18:38:15.255074] [SEVERE] [Shard 0] UNKNOWN GATEWAY EVENT: {t: SESSIONS_REPLACE, s: 2, op: 0, d: [{status: dnd, session_id: ..., client_info: {version: 0, os: other, client: web}, activities: []}]}
Error: autogenerated stack trace for SEVERE UNKNOWN GATEWAY EVENT: {t: SESSIONS_REPLACE, s: 2, op: 0, d: [{status: dnd, session_id: ..., client_info: {version: 0, os: other, client: web}, activities: []}]}
Stack trace:
#0      Logger.log (package:logging/src/logger.dart:200:33)
#1      Logger.severe (package:logging/src/logger.dart:269:7)
#2      Shard.dispatch (package:nyxx/src/internal/shard/shard.dart:687:18)
#3      Shard.handlePayload (package:nyxx/src/internal/shard/shard.dart:327:9)
#4      Shard.handle (package:nyxx/src/internal/shard/shard.dart:239:16)
#5      _RootZone.runUnaryGuarded (dart:async/zone.dart:1593:10)
#6      CastStreamSubscription._onData (dart:_internal/async_cast.dart:85:11)
#7      _RootZone.runUnaryGuarded (dart:async/zone.dart:1593:10)
#8      _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:339:11)
#9      _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#10     _SyncBroadcastStreamController._sendData (dart:async/broadcast_stream_controller.dart:377:25)
#11     _BroadcastStreamController.add (dart:async/broadcast_stream_controller.dart:244:5)
#12     _AsBroadcastStreamController.add (dart:async/broadcast_stream_controller.dart:474:11)
#13     _RootZone.runUnaryGuarded (dart:async/zone.dart:1593:10)
#14     _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:339:11)
#15     _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#16     _SyncStreamControllerDispatch._sendData (dart:async/stream_controller.dart:774:19)
#17     _StreamController._add (dart:async/stream_controller.dart:648:7)
#18     _StreamController.add (dart:async/stream_controller.dart:596:5)
#19     _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:192:26)

Undocumented event that can safely be ignored.
https://github.com/Rapptz/discord.py/issues/1851#issuecomment-457880626


Show zipkin trace id for query execution

Summary

Show zipkin trace id for query execution
x-b3-traceid has been added in the CORS exposed header params (CrossOriginFilter.EXPOSED_HEADERS_PARAM), which means traceId is provided in the API response header.
In studio, we need to get the value from the response header then store in the ExecutionResult and display it in the Result panel.

How did you test this change?

[ ] Test(s) added
[x] Manual testing (please provide screenshots/recordings)
[ ] No testing (please provide an explanation)

Could you add a recording/gif of the feature? It's hard to tell from the screenshot where that tooltip is getting triggered from.


Externally Defining JUnit 4 RunListeners

We use the JUnit 4 Ant task for all of our JUnit tests (well over 75k tests).  We have the need to add a custom RunListener that will be invoked for every test we execute.  I looked at how the listeners sections in the JUnit 4 ant XML works and it looks like the listeners defined in that section do not extend the JUnit 4 RunListener but instead make us of listeners based off of AggregatedEventListener.
My question is:

Am I correct in my assumption that I can't add a RunListener to the listeners section in the XML?  If you can, do you have an example?
If this is not possible, would you be open for me to create a PR to add this functionality to the JUnit 4 ant task?

We did get this to work by forking the project and adding our listener directly in SlaveMain.  This is obviously not the best way to do this and was more of a POC to make sure this would work.  I would rather add this functionality to the main project and give it back to the user base if I could.
Thanks,
Steve

The RunListener from JUnit is somewhat limited, that's why there is another interface for handling feedback events about the progress. There are several implementations in the code already, so you can use these as an example (one for emitting surefire-compatible XMLs, one for console formatting, etc.).
You didn't specify what it is you're after... but if you have a common base class you could also add a run listener dynamically from code-level via:
https://github.com/randomizedtesting/randomizedtesting/blob/master/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/annotations/Listeners.java

@dweiss - Thanks for the response!
I can't use the Listener annotation for the following reasons:

In the one repository that we use the CarrotSearch JUnit 4 ant task for does not use the RandomizedRunner.  That repository uses 17 different runners (PowerMockRunner, MockitoJUnitRunner, SpringJUnit4ClassRunner, etc).
The number of tests exceed 75k and unfortunately they are a culmination of tests that have been written over the past 12 years.  Some bad decisions were made and they do not extend from a common base class.

What I would like to do is extend the JUnit 4 Ant Task to allow external definition of custom RunListeners, much in the same what that Maven SureFire or FailSafe does:
http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html
http://maven.apache.org/surefire/maven-failsafe-plugin/examples/junit.html
(Jump to the section titled "Using Custom Listeners and Reporters")
We have a RunListener that we are using across other projects that we would like to also use with the JUnit 4 Ant Task.  As a POC, I forked the https://github.com/randomizedtesting/randomizedtesting repo and added my RunListener to the SlaveMain class and it works fine.  I would rather not fork the repo and would like to add this functionality back to the project.
I am proposing something like this in the XML:
<junit4:junit4 />
       ...
       <listeners>
             ....
       </listeners>
       <runListeners>
             <classes>com.company.CustomRunListener1,com.company.CustomRunListener2</classes>
       </runListeners>
</junit4:junit4>

When the tests are run, the RunListeners that are defined in the classes tag are loaded and added to the OrderedRunNotifier in the execute method in SlaveMain.
What do you think?
Thanks,
Steve

A RunListener is a subset of what randomized runner listeners can do. I don't quite understand why an adapter isn't possible here. If you can't live without those run listeners then sure -- please feel free to provide a patch. One thing I wouldn't want is comma-separated classes though. Separate class blocks for each listener would be much more adequate here (not to mention they'd look better when the XML is indented).

Maybe I am not understanding what you mean by creating an adapter.  Do you have an example of what an adapter like this would look like?  How do you specify that adapter to be used for our tests?  We don't use RandomizedRunner.  Would this work with any other runners?
I would be glad to do this another one but not sure how to implement this with that is currently available.
Thanks,
Steve

You don't have to use RandomizedRunner -- if you're using the ant task the test infrastructure will call listeners declared in the listeners block regardless of the actual runner used. If you have existing RunListener implementations it should be possible to write one (abstract) class to delegate events from the existing infrastructure to RunListener's interface, then write an adapter class for each of your RunListener implementations.
Anyway, those listeners are completely independent from RandomizedRunner. Try it by running a simple test class (with a custom runner or the default one) and using a console printer or XML reporting listener.
I may be on and off (away until the end of the week), but it should be fairly easy to put together?

Hi @dweiss
I created a PR to add the ability to externally attach RunListeners to a test using the JUnit 4 Ant XML.  You can add them like so:
<runlisteners>
    <junit4:run-listener className="com.salesforce.test.UserDefinedRunListener1" />
    <junit4:run-listener className="com.salesforce.test.UserDefinedRunListener2" />
    <junit4:run-listener className="com.salesforce.test.UserDefinedRunListener3" />
    <junit4:run-listener className="com.salesforce.test.UserDefinedRunListener4" />
    <junit4:run-listener className="com.salesforce.test.UserDefinedRunListener5" />
</runlisteners>

This block is optional.  The following is included in the PR:

Modified the task to add the ability to attach RunListeners
Modified the maven plugin to support this functionality as well
Added tests for these changes
Updated documentation to show how to use this new feature.

I have tested it locally with 6 RunListeners and it's working well.
Thanks!
--Steve
PR -> #262

Thanks, I'll take a look!

Thanks!  Looking forward to getting this merged so we can use it in our projects.
--Steve

@dweiss
Thanks for merging this!
Do you have an ETA when this code will be released?
Thanks,
Steve

I'll try to do it over the weekend, I'm out of office tomorrow.


Product photos are missing from resources folder for working on custom templates.

Just realized this is the same as #99


[Marketing] IronHacks blog Template Creation

Summary:
Need to create a template for future blog posts and possible new blogs by next Friday ( Oct 7. 22)

I think this is somewhat sorted but we still need to write posts. How can we move this forward? @rsundhar2002 @jialincheoh  ?


Random plants

At the distance, the forest trees and bushes looked a bit regularly placed.
I changed to the more random logic, as I found it at OSM2World:
Both (Streets+OSM2World) uses tiles/boxes to render a part of a forest etc.
O2W uses bigger ons and renders 100 Trees per Box! I added this code, but optimizend to other values.
As more random plants show les dense with gaps, I added more plants. The FPS seems not to increase much.
Feel free to test other values yourselves.
O2W, only by comment, intended to have a minimum distance between the points. I implemented it.
O2W used "seed" for the random to get a reproducible tree distribution at reload etc.
I used SeededRandom and it seems to work well.

You probably have a different environment (different node.js or npm version) compared to mine, that's why your package-lock.json is different. But it's required for deployment, it's there to make sure that when the app is deployed all the package version are the same as on the local machine. I think you shouldn't have removed it, it should stay the same because your changes don't affect any modules. I'll fix it myself later.


Images not displayed correctly (some of them are empty)

I took a list of foreign manifests (https://ronallo.com/iiif-workshop/presentation/example-manifests.html) and tried to get a PDF's.
Some links are not working in this list.
I tried this one: https://d.lib.ncsu.edu/collections/catalog/nubian-message-1992-11-30/manifest
Pdiiif creates a PDF and displays the metadata page and the first image, but the following are empty.

Just pushed a fix for this, reason was that the Manifest references OCR that fails to fetch during PDF generation due to missing CORS headers. Since we pre-calculate all object references before doing any fetches, this led to broken references and thus a broken PDF file. Fix was to insert dummy objects in these cases so the references still match 🤷🏾


Update e2e_tests.yaml: add -S flag to call of test_e2e.sh

Tests now use -S flag when calling test_e2e.sh. This flag will ensure that the extra test skip lists are used

This can not be merged until PR 437 https://github.com/kubernetes-sigs/kpng/pull/437 has been merged

Adding the update to #437 and will kill this PR


Add a quick setup for new users

Describe the enhancement you'd like
As a potential user, I want to try out the demo, but it is not clear on what to do, to make images appear.
To improve this, we should do the following:
If no scan directory is found, and we are an admin and no images are found for a given user, then we should render some text like:
"Looks like you still have to set up a scan directory and to scan some images" together with a button that has some text on it like "Getting started".
When clicking on it, it should open a modal where you set your scan directory. Instead of just updating the scan directory, it will then immediately start the scan process.
Describe why this will benefit the LibrePhotos
This will remove most of the beginner questions and will make the demo more accessible.

Implemented!


BUG Authenticator

Strange behaviour: Sometimes authentication via 6-digit-code from authenticator-app fails. (Observed when user is too fast?)
Please check server time and probably give more tolerance time for input-delays.

fine


Log expansion and contraction of metrics

Log the following:

# of DynamoDB new record events  recieved in lambda
# of payloads per event
# of dynamodb payloads per lambda

Aggregate Metric needs the following Permissions:

cloudwatch:PutMetricData

Hasn't been an issue so far, will close but re-open if we need to revisit it.


Update to Electron 0.35

Figured I'd get this started and get some more experience with the core atom code, as I'm pretty sure lots of things will need to be changed this time.
https://github.com/atom/electron/releases/tag/v0.35.0
Fixes #9534
TODO:

[x] Fix core specs failing almost instantly with no output
[x] Fix specs randomly hanging - at least, they didn't hang in the last build.
[ ] atom/tabs#238
[x] Fix notifications specs that rely on executeJavaScriptInDevTools...kinda?  Not sure if I actually fixed the underlying deprecation or not.
[ ] Attempt to update to Electron v0.36.0 - in progress
[ ] Test for and fix regressions

Regressions:

[x] Opening a new tab no longer works
[x] Adding a project folder does nothing through the context menu or file menu
[x] Adding a project folder through the keyboard shortcut/command palette opens up the folder chooser but doesn't actually add the new folder
[x] Open Your ... menu items are all broken, even when executed through the command palette
[x] Open File does not actually open the chosen file
[x] Help -> About Atom does nothing
[x] Open Settings does not work through the file menu
[x] Opening Settings or any other file that uses a URI will cause a fake folder to appear in the Tree View (eg config, init-script) and Settings - atom://config or similar to show up in the titlebar.  Reproduce by using a new window. - also an issue on master (tested on f6da4a9139bd08b4b89e85203caf20a4af72d195)
[ ] On 0.36 - menu mousedown effect is not removed when switching menus by hovering over to a new one
[x] Closing the window when Atom is launched using atom --foreground yields an error:

Error: Object has been destroyed
    at Error (native)
    at AtomWindow.module.exports.AtomWindow.getLoadSettings (file:///C:/Users/user/Documents/GitHub/atom/src/browser/atom-window.coffee:91:8)
    at AtomApplication.module.exports.AtomApplication.saveState (file:///C:/Users/user/Documents/GitHub/atom/src/browser/atom-application.coffee:452:34)
    at EventEmitter.<anonymous> (file:///C:/Users/user/Documents/GitHub/atom/src/browser/atom-application.coffee:211:8)
    at emitOne (events.js:77:13)
    at EventEmitter.emit (events.js:169:7)
    at AtomApplication.module.exports.AtomApplication.removeWindow (file:///C:/Users/user/Documents/GitHub/atom/src/browser/atom-application.coffee:104:13)
    at BrowserWindow.<anonymous> (file:///C:/Users/user/Documents/GitHub/atom/src/browser/atom-window.coffee:126:30)
    at emitOne (events.js:82:20)
    at BrowserWindow.emit (events.js:169:7)

The error occurs on the following line:
getLoadSettings: ->
    if @browserWindow.webContents? and not @browserWindow.webContents.isLoading()
      hash = url.parse(@browserWindow.webContents.getURL()).hash.substr(1)  # Here!
      JSON.parse(decodeURIComponent(hash))

Is there any way to get more output from Travis?  Core specs are (surprisingly) passing but I'm sure there's a bunch of deprecated Electron APIs being used.

And...specs are failing to run.  Not sure how to proceed from here, though I suspect I probably messed up the ipc renaming.

Ran the tests locally and it looks like we're hitting atom/electron#3484:
Insufficient number of arguments.
TypeError: Insufficient number of arguments.
    at TypeError (native)
    at parseCommandLine (C:\Program Files\Atom\resources\app.asar\src\browser\main.js:167:100)
    at start (C:\Program Files\Atom\resources\app.asar\src\browser\main.js:32:12)
    at Object.<anonymous> (C:\Program Files\Atom\resources\app.asar\src\browser\main.js:209:3)
    at Object.<anonymous> (C:\Program Files\Atom\resources\app.asar\src\browser\main.js:211:4)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Object.<anonymous> (C:\Program Files\Atom\resources\atom.asar\browser\lib\init.js:130:10)

The build then proceeds to hang.  I'll see if I can figure out what got updated; if not it looks like we'll just have to wait for Electron 0.35.1.

Specs are still timing out :disappointed:.  I can run them fine locally (albeit with a whole bunch of errors), so it might be a Mac/Linux-only issue.
All the deprecations in Atom core should be fixed though.

@zcbenz A few questions:

Requiring either ipc-main or ipc-renderer in atom-application.coffee and atom-portable.coffee throws "Cannot find module" errors.  Is there any way around that?
webContents.executeJavaScriptInDevTools doesn't seem to be a method.  In fact, looking at v0.34.x, I can't even find executeJavaScriptInDevTools, just executeJavaScript.  The 0.35 upgrade appears to have broken executeJavaScriptInDevTools as well with multiple cannot read "apply" of undefined errors, though it's only supposed to be a deprecation.
Not a question, but I'm pretty sure the deprecation message for getHomeDir() didn't tell me to use getPath('home'), just getPath().

The 0.35 upgrade appears to have broken executeJavaScriptInDevTools as well with multiple cannot read "apply" of undefined errors, though it's only supposed to be a deprecation.

Spelunking to learn...It looks like executeJavaScriptInDevTools may have broke here:
https://github.com/atom/electron/commit/91c4ed26fc9e0ed2792abd2bf594dd0d2e4bb336

@zcbenz From atom/electron@91c4ed2 it looks like the original code had
BrowserWindow::executeJavaScriptInDevTools = (code) -> @devToolsWebContents?.executeJavaScript code

then deprecated to
deprecate.member BrowserWindow, 'executeJavaScriptInDevTools', 'webContents'

which on the surface looks wrong, since deprecate.member forwards the method to webContents not devToolsWebContents, and the original code ran a different method executeJavaScript.
Another possible issue is:
BrowserWindow::getPageTitle = -> @webContents.getTitle()

was deprecated with
deprecate.member BrowserWindow, 'getPageTitle', 'webContents'

where I'm guessing that deprecate.rename is required.

@glangford Those deprecation wrappers were wrong, thanks for the notice!

I have an upgrade for npm-latest and node-latest on my laptop with a broken screen, it actually was a LOT of work, so if anyone else hasn't already done this I could fetch it while we're still upgrading API's

@50Wliu  -

...All of these seem like issues caused by the ipc renaming, but I can't get any errors or deprecation notices to appear

Fix wrong deprecation wrappers of BrowserWindow
https://github.com/atom/electron/commit/932cd92bf6dded7756196254f5d7593fc5d2e14d
Improve the deprecation notice for ipc module
https://github.com/atom/electron/commit/9c62be8fc998856fb6f5dbf032f85cacd3818659

Specs still can't find ipc-main in atom-portable.coffee for whatever reason.

Specs still can't find ipc-main in atom-portable.coffee for whatever reason.

:confused:
I went hunting for clues and saw this in the updated api docs:
const ipcMain = require('electron').ipcMain;
Refs
https://github.com/atom/electron/blob/master/docs/api/ipc-main.md
https://github.com/atom/electron/pull/3415
https://github.com/atom/electron/commit/eac2e7cc614d4e98e2828921f63d55f7b5e2c85c

Aha.  I missed atom/electron#3415 so I assumed Atom was special in that it didn't need the require('electron') part.  Surprised Electron didn't deprecate the old way.
Testing now...

Upon further inspection moving to require('electron').x won't solve anything, since that maps to the same thing as require 'x'.  The issue still remains that ipc-main/ipcMain can't be found.
Also, since we don't have electron as a node module, attempting to do the former will result in Error: Cannot find module 'electron'.  That's probably an easy fix (adding electron-prebuilt as a dependency or something?) but I feel like I'm getting way out of my comfort zone here.

Does it help to back off to 0.35.1 to see if the same inability to find the module occurs?

Does it help to back off to 0.35.1 to see if the same inability to find the module occurs?

It's been happening since the initial upgrade to 0.35.0.

Ok, one more kick at this problem:
The electron specs for ipc include this:
{ipcRenderer, remote} = require 'electron'
{ipcMain, BrowserWindow} = remote.require 'electron'

https://github.com/atom/electron/blob/master/spec/api-ipc-spec.coffee#L5
I don't understand the use of remote.require here, just pointing out the different incantation in case it helps.

Nope, remote isn't defined.  Explicitly requiring it through remote = require 'remote' (which is what other portions of the code does) fails with Error: cannot find module 'remote'.

I have updated the PR with the new styles of Electron API.

You're magical @zcbenz.  require 'electron' just refused to work for me.  Thanks so much! :star2: :100:

For the record I know what I did wrong now: I was launching through atom --dev without running script\build beforehand, so Electron wasn't the correct version (I think).

The error that occurs when closing a window (as documented in the PR body) is pretty interesting.  It seems to be happening because the browser window is being destroyed before we access it in getLoadSettings to save the serialization state in application.json.  I've made sure that the sequence of close events hasn't changed between 0.34.5 and 0.35.4 - it's always close -> closed -> before-quit.
Now the interesting part is that we're calling getLoadSettings in before-quit, which happens after closed and when the Electron documentation says to stop using the window object.  I'm not sure why continuing to access the destroyed window didn't throw an "object is destroyed" error in previous versions, but now it is.
In any case the error seems to be harmless as Atom is still able to access the copy of the window object to save the open tabs.

I've been running this for around a week now and haven't noticed any new regressions, but it would be great to have a few more :eyes: :mag:: /cc @atom/feedback.

Oh, and also: I tried looking for any bundled packages that were using the old way of requiring Electron modules, but it's pretty likely that I missed some.

What about trying to update to electron 0.36.0?
That version seems to fix atom/electron#2645 which is crashing my Atom so many times

1 failing core spec:
>> TextEditorComponent
>>   overlay decoration rendering
>>     positioning the overlay when near the edge of the editor
>>       it slides horizontally left when near the right edge on #win32 and #darwin
>>         Expected '387px' to be '375px'.
>>           Error: Expected '387px' to be '375px'.
>>           at /Users/travis/build/atom/atom/spec/text-editor-component-spec.js:1979:36
>>           at [object Generator].next (native)
>>           at step (/Users/travis/build/atom/atom/spec/text-editor-component-spec.js:1:411)
>>         Expected '399px' to be '375px'.
>>           Error: Expected '399px' to be '375px'.
>>           at /Users/travis/build/atom/atom/spec/text-editor-component-spec.js:1986:36
>>           at [object Generator].next (native)
>>           at step (/Users/travis/build/atom/atom/spec/text-editor-component-spec.js:1:411)

and one failing ac+ spec:
>> Autocomplete Manager
>>   when an external provider is registered
>>     when autocomplete-plus.suggestionListFollows is 'Word'
>>       it displays the suggestion list with a negative margin to align the prefix with the word-container
>>         Expected '-144px' to be '-143px'.
>>           at [object Object].<anonymous> (/Users/travis/build/atom/atom/node_modules/autocomplete-plus/spec/autocomplete-manager-integration-spec.coffee:969:55)
>>           at Immediate._onImmediate (/Users/travis/build/atom/atom/node_modules/autocomplete-plus/spec/spec-helper.coffee:26:9)

Seems like we have some alignment issues with 0.36.

@pleonex working on it!  If it turns out to require too much work, I'll revert the changes and try updating to 0.36 in a different PR.

@50Wliu Thanks for giving a try!

Just tried reproducing the failures locally and both specs pass (which in itself is pretty surprising since almost a quarter of Atom's specs fail on my laptop).
Looks like someone who has a Mac will have to try.

With electron 0.36 there's an issue:
If autoHideMenuBar is true and Alt is pressed, the menu bar remains hidden. (same in safe-mode, Xubuntu 15.04)

I'm pretty sure someone here left a comment about menus not toggling after the Alt key was pressed, but either my memory is a bit confuzzled or the comment got deleted.  At any rate that bug has been fixed in Electron 0.36.2 which we're now on.

There is a small issue on the upgrade, since v0.36.1 calling ipc.sendSync won't pump the message loop anymore, so when waiting for the main process to respond the rendering of page would be stopped. There are a few places in Atom sending synchronous messages on startup, which would result in a small period of white screen now, so for users they may feel the loading is becoming slower. The actual startup time is not affected.
We need to remove the sendSync calls on startup to fix the small period of white screen, or we can delay the showing of window until it is fully loaded.

@zcbenz I just did a global find for sendSync but that returned 0 results.  Can you please give a few examples of where we're calling that?

@50Wliu remote module uses sendSync under the hood, so every call of a remote object would send a synchronous message.
I just did a profile of startup code, there is no synchronous message sent on startup anymore, apparently recent performance improvements have solve this. :+1:

OK, tests are now passing on Mac CI. The problem was that remote.getCurrentWindow().setSize seems to no longer take immediate effect; there is a test that now needs to poll until window.innerWidth eventually changes to reflect the new size.
One remaining problem, which may be related, is that on startup, content starts to render before the window size is fully restored, which causes some visual glitches.
@zcbenz We still are using the remote module on startup, and its behavior seems to have changed such that it returns before the window's size changes.
I'm guessing we need to switch to using an async send, and figure out our own way of waiting until the resize is finished. Do you have any suggestions for this?

content starts to render before the window size is fully restored, which causes some visual glitches.

I reported that in a different issue (#9294)...looks like I forgot to also post the picture over here.

I've reverted the Electron version to 0.36.4 since 0.36.5 crashes Atom on startup for me.  Dump file is attached...
electron-0.36.5-crash-windows.zip

@maxbrunsfeld Travis timed out with the new await in https://travis-ci.org/atom/atom/jobs/105022601.  Seems like there's a chance that it's a bit flaky.

Travis timed out with the new await

Thanks for the heads up @50Wliu. I think that the flakiness may be due to the window size being 1 pixel off from the requested size, or something like that. I've changed the spec so that now it awaits the resize message being processed, instead of polling for an exact window size. Maybe this will help.

OK, I think I have addressed the rendering artifacts on startup, and this is ready for testing.

/cc @amytruong: Some areas that could use some testing

[ ] Startup (Mac, Linux, Windows)

Any brief visual oddities like the one @50Wliu captured above
The window should appear with the correct size, and with the correct background color based on the theme you were previously using. It shouldn't be initially white.
If the window was previously full-screen, it should still appear full-screen

[ ] Overlays, like the autocomplete pop-up should appear in the right spot. After resizing the window in various ways, when typing a word near the edge of the screen, the pop-up should always appear in a reasonable spot.
[ ] Adding project folders (the Application: Add Project Folder command) should open the native file picker dialog correctly.

@zcbenz I'm seeing a lot of this in the console on startup:
[75796:0127/133819:WARNING:id_weak_map.cc(81)] Removing unexist object with ID 1

Is this something to worry about?

I'm guessing we need to switch to using an async send, and figure out our own way of waiting until the resize is finished. Do you have any suggestions for this?

I think we should probably pass the window size to the page as part of the url, instead of reading window size in the page, it can save us the resize, which is very expensive.

I've reverted the Electron version to 0.36.4 since 0.36.5 crashes Atom on startup for me. Dump file is attached... (/cc @paulcbetts, @raelyard)

I created an issue for the crash: https://github.com/atom/electron/issues/4258.

I usually see this in the console the first time the Atom window loses focus after startup:

It is an warning message, there is no need to worry about it. It has been fixed in v0.36.5.

So the upgrade to 0.36.7 somehow broke Standard linting... Fatal error: TypeError: Cannot read property 'match' of undefined :disappointed:.  The error didn't happen in 0.36.5 so I'll see if 0.36.6 also breaks it.

So for what it's worth this script\grunt standard still works on my machine...
>script\grunt standard
Running "standard:src" (standard) task

Linting files...

✓ No Problems

Done, without errors.

Execution Time (2016-01-31 20:30:39 UTC)
loading tasks  4.1s  ████████████████████████████████ 67%
standard:src     2s  ████████████████ 33%
Total 6.1s

I'll try an entire script\cibuild next to see if that repros.

Still can't reproduce, even after a full script\cibuild.  This isn't fun.  Running Windows 10 x64.

Windows (8.1)
Atom Smoke Test
(High level test to ensure basic functionality and there's no immediate showstoppers)

[x] Run through Welcome Guide
[x] Install and update Packages
[x] Install and update Themes
[x] Verify speed and response time (Windows is just not fast enough - ever)
[x] Verify scrolling is fast (Windows just not fast enough - ever)
[x] Verify File menu bars/navigation is functioning

[x] Startup

Any brief visual oddities like the one @50Wliu captured above
The window should appear with the correct size, and with the correct background color based on the theme you were previously using. It shouldn't be initially white.
If the window was previously full-screen, it should still appear full-screen
Note: There is an existing bug where if you are full screen and hit restore down, it doesn't restore the window back to the original smaller size.

[x] Opening a new window - the window should be offset from the initial window, similarly to how new windows behave for other text editors on the platform (TextEdit on mac, Notepad on windows).
[x] Overlays, like the autocomplete pop-up should appear in the right spot. After resizing the window in various ways, when typing a word near the edge of the screen, the pop-up should always appear in a reasonable spot.
[x] Adding project folders (the Application: Add Project Folder command) should open the native file picker dialog correctly.

Mac Yosemite 10.10.5
Atom Smoke Test
(High level test to ensure basic functionality and there's no immediate showstoppers)

[x] Run through Welcome Guide
[x] Install and update Packages
[x] Install and update Themes
[x] Verify speed and response time (Windows is just not fast enough - ever)
[x] Verify scrolling is fast (Windows just not fast enough - ever)
[x] Verify File menu bars/navigation is functioning

[x] Startup

Any brief visual oddities like the one @50Wliu captured above
The window should appear with the correct size, and with the correct background color based on the theme you were previously using. It shouldn't be initially white.
If the window was previously full-screen, it should still appear full-screen

[x] Opening a new window - the window should be offset from the initial window, similarly to how new windows behave for other text editors on the platform (TextEdit on mac, Notepad on windows).
[x] Overlays, like the autocomplete pop-up should appear in the right spot. After resizing the window in various ways, when typing a word near the edge of the screen, the pop-up should always appear in a reasonable spot.
[x] Adding project folders (the Application: Add Project Folder command) should open the native file picker dialog correctly.

Linux (Ubuntu 15.00? whatever the latest is)
Atom Smoke Test
(High level test to ensure basic functionality and there's no immediate showstoppers)

[x] Run through Welcome Guide
[x] Install and update Packages
[x] Install and update Themes
[x] Verify speed and response time (Windows is just not fast enough - ever)
[x] Verify scrolling is fast (Windows just not fast enough - ever)
[x] Verify File menu bars/navigation is functioning
[x] Create new file. Save. (Verify it's saved)

Notes:

Changing themes can sometimes gives a really quick white flicker in the background. Happens so little and sporadically that it might not be worth mentioning.

Resizing the window takes awhile and I'll see white or black space before the app displays again fully but it happens on the Beta too. /shrug

Did have an unusual crash opening up a simple window

[x] Startup

Any brief visual oddities like the one @50Wliu captured above
The window should appear with the correct size, and with the correct background color based on the theme you were previously using. It shouldn't be initially white.
If the window was previously full-screen, it should still appear full-screen

[x] Opening a new window - the window should be offset from the initial window, similarly to how new windows behave for other text editors on the platform (TextEdit on mac, Notepad on windows).
Does NOT open offset from initial window but rather right on top of it

[x] Overlays, like the autocomplete pop-up should appear in the right spot. After resizing the window in various ways, when typing a word near the edge of the screen, the pop-up should always appear in a reasonable spot.

[x] Adding project folders (the Application: Add Project Folder command) should open the native file picker dialog correctly.

would like to do some more exploratory testing when I get back into town.

Thanks for the update Amy! I merged this into master so that we can use it in some further PRs. There should be ample time to do exploratory testing on master once you get back from vacation!


Delete all Stale Branches

@hepwori @camaleon2016 would like to cleanup old branches that have been merged or no longer apply.  Please give me a thumbs up if you approve.

Also inline with #33

[like]  Jay White reacted to your message:

From: Melba @.>
Sent: Tuesday, May 2, 2023 1:49:13 PM
To: ossf/wg-supply-chain-integrity @.>
Cc: Jay White @.>; Mention @.>
Subject: [ossf/wg-supply-chain-integrity] Delete all Stale Branches (Issue #59)
@hepworihttps://github.com/hepwori @camaleon2016https://github.com/camaleon2016 would like to cleanup old branches that have been merged or no longer apply. Please give me a thumbs up if you approve.
[image]https://user-images.githubusercontent.com/101211710/235685678-22e4e34a-e60a-4254-b466-037cdb3eb317.png
—
Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-supply-chain-integrity/issues/59, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AYSMSZWWNHIXEK26GSUDJJLXEEGFTANCNFSM6AAAAAAXTCQRLI.
You are receiving this because you were mentioned.Message ID: @.***>

Thumb up
Jay White (He/Him)
Security Principal Program Manager
Azure Office of the CTO
OSS Ecosystem
[Graphical user interface  Description automatically generated]
From: Melba @.>
Sent: Tuesday, May 2, 2023 6:49 AM
To: ossf/wg-supply-chain-integrity @.>
Cc: Jay White @.>; Mention @.>
Subject: [ossf/wg-supply-chain-integrity] Delete all Stale Branches (Issue #59)
@hepworihttps://github.com/hepwori @camaleon2016https://github.com/camaleon2016 would like to cleanup old branches that have been merged or no longer apply. Please give me a thumbs up if you approve.
[image]https://user-images.githubusercontent.com/101211710/235685678-22e4e34a-e60a-4254-b466-037cdb3eb317.png

Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-supply-chain-integrity/issues/59, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AYSMSZWWNHIXEK26GSUDJJLXEEGFTANCNFSM6AAAAAAXTCQRLI.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

Proceeding with deleting stale branches @camaleon2016 @hepwori

Stale Branches removed (from 3 years ago)


Question: How to deal with Code Mappings in combination with this bundle

I hope you will allow to ask me this question because even after digging in all the documentation I cannot find the correct answer for this.
Code Mappings when integrating Sentry with Symfony using this bundle might not work out of the box if you deploy multiple versions of an application you your server.
The reason is that the bundle reports absolute paths by default (I think this is correct behavior) but code mappings don't seem to allow wildcards. Meaning if you deploy your application for example to the following folders you are unable to make a code mapping for it.
/var/www/releases/1/
/var/www/releases/2/
/var/www/releases/3/

It seems normally a project truncates the path in the event meaning /var/www/releases/1/src/ becomes src/. I think this an okay solution but I'm sad that this way a lot of important information is omitted.
My question is how do others deal with this problem? Are there settings in this bundle that make dealing with this easier?
Relevant documentation:
https://docs.sentry.io/product/integrations/gitlab/#stack-trace-linking

Truncating the paths is useful to eliminate noise, in regards to aggregating the events; having events split due to happening on different servers/paths/releases would be bad, right? It's the opposite side of the spectrum of what you're asking.
If you need to investigate on where an event is happening, you should use the release option, which adds a tag with the release currently running when the event occurred. This is a separate piece of information that you can populate at will, and it's not bound to anything specific.
By default, that value uses the composer.json version, which normally falls back to the git commit hash. Depending on your deployment strategy, git could be missing and that value could be not useful, but if you populate it correctly, you'll have what you need.

@Jean85 Thank you for your answer! That indeed makes sense. What is the recommended way or truncating the path in combination with the sentry bundle?

What is the recommended way or truncating the path in combination with the sentry bundle?

It should happen by default thanks to kernel.project_dir : https://github.com/getsentry/sentry-symfony/blob/c016dc2496833c73747a5e5babf04c41791a5118/src/DependencyInjection/Configuration.php#L50-L51

@Jean85 thank you for taking the time to answer. This actually was very helpful. I found out the default prefixes were added in version 4.x. while still using 3.5 for this project I'm talking about. I will upgrade Sentry to make use of this feature.


Neko freezes when turning a page

Steps to reproduce

Open Manga
Read 10 Chapter
Page doesn't turn and Neko doesn't respond

Expected behavior
It should turn the page normally
Actual behavior
App freezes
Crash logs
No response
Neko version
2.9.0
Android version
Android 11
Device
Xiaomi Poco X3 NFC
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have tried the troubleshooting guide.
[X] I have updated the app to the newest version Latest.
[X] I have filled out all of the requested information in this form.

Do you have a video of this?

https://drive.google.com/file/d/1lmC1M3KE00_KfqZi-x4LuBsNNENjLNZo/view?usp=drivesdk

Strangely enough, I have realized that most of the time it freezes on page 27

I am unable to access the video could you share it on the discord channel?

Done

linking for future ref
https://cdn.discordapp.com/attachments/569823838305648640/981242465094873198/Screenrecorder-2022-05-30-13-28-01-9100.mp4


bug: with function buttons

https://user-images.githubusercontent.com/70818351/155530860-7e0cc882-ca59-4865-a657-d58fc60db430.mp4

I didn’t get that, can you explain a little?

type = alphanumeric
I press ALT, TAB, WIN, F7, F8 and so on
and it substitutes this value

I really can't reproduce this.
Does it only happen with type = alphanumeric?

I can't repeat it in any of your projects, but in all of mine there is a bug
if type = number, then pressing F8 will put 8

"then pressing F8 will put 8"
You mean just press F8 or combined with Fn key?

my keyboard has this, but I do it without pressing FN

@bulhiCzar And are you sure it is the v2.1.2?

I used 2.0.9
sorry

No problem, sometimes I update too many versions and I know its not good practice


new carbon cycle & climate calibration, remodularised climate

Connected the ocean carbon cycle to the atmosphere side and deleted old atmospheric carbon cycle.
Updated the climate calibration members including selected climate case and external sensi cases.
Remodularised Climate.
Updated Total global SLR name in calibration file.

The reason Energy is in there is because when I remodularised it broke an STA link somehow, so I had to add it back in. This can probably be removed and then fixed if necessary in the conflicting one. Wasn't sure if I should include isdb.

Just pushed a new commit with the newly connected carbon cycle. There now seems to be the problem that biofuels produce quite large CO2 emissions, due to the new calculation:

I assume that the variable "UNIT GtC per PCal crop" could be recalibrated? Biofuel emissions now seem to be almost as big as those from other energy sources:

Much larger than in the previous calculation

@BenjaminBlanz , @jnnsbrr , @rj1971350

I think that is in some sense true, as the amount of carbon that is eventually outgassed in the engine is not the amount of carbon that is originally in the plant on the field (i.e. before applying the harvest index). BUT it is probably also not the amount of carbon that is harvested (i.e. after applying the harvest index), as there will be a lot of leftover carbon on the way to the fuel, is my guess.
Therefore, I think Ben's original implementation actually made more sense, when we want to get only the emissions from burning the biofuel. We can probably ignore all the leftover carbon here, as the "net land carbon flux"  (now correctly implemented, see previous commit) takes care that we don't loose carbon on the way anywhere.

@lnnrtrmm excellent -- now if you were to delete the badly formed variable "CO2 emissions from Food and Land Use" (and its causers) and if the others agree put back @BenjaminBlanz's "carbon intensity of biofuels" this PR would be ready? (I will take care of the merge conflict when you tell me to)

In general I would advocate for having specific emissions variables as possible as that will help us with tracing and communicating effects of policies.


cmake: Use GNUInstallDirs for configurable install directories

Use the standard GNUInstallDirs CMake module to provide configurable install directories rather than hardcoding bin, lib, etc.  Most importantly, this fixes install on modern 64-bit systems that use lib64 rather than lib.

Thanks!


Any chance of getting a pre-built DLL?

This looks like a handy plug-in, but do you think you could post a DLL?  Installing the entire build environment is going to take half of my afternoon.
Thanks!

Please try now.

Windows libraries and installer are now added for convenience.

Thank you!