update types/part_set.go

Hi, I'm looking at the ostracon code and came across the annotation that I found awkward.
I found that the same comment is described not only in ostracon but also in cometBFT, so I changed cometBFT first and my proposal was approved.
Here is the related link: https://github.com/cometbft/cometbft/pull/1056
In types/params.go, the value of BlockPartSizeBytes is 65536 (about 64kB).
In the function func NewPartSetFromData(data []byte, partSize uint32) *PartSet in types/part_set.go, the function uses the parameter partSize which is the value of BlockPartSizeBytes.
However, the annotation says it's 4kB, so I'm doing a pull request to fix it.

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

Thank you @mansub-song for your contribution.


Home Page - Disable Clicking on John Doe

Current System Behavior
From home page, click on John Doe, you are redirected to: http://localhost:4200/#!

Requirement
When click on John Doe, nothing should happen.

This issue was moved to Code4SocialGood/c4sg-services#92


fix: resolve timestamp mismatching issue

calculate timestamp offset between binance server and local
apply timestamp offset

Opened this PR per #662

@kimchirichie
Judging from the merged commit, there seems to be build-in code to handle/prevent "Timestamp for this request was 1000ms ahead of the server's time.", unfortunately it's not working.
As alternative, I've had W10 sync time multiple times, unfortunately this error still returns regularly.
Also tried setting timestamp_offset(-1000) but that results in "TypeError: 'int' object is not callable".


Error: cpu.h: No such file or directory

Hi,
I tried to install cpu using go get, here is the error I am getting:
root@ubuntu:~# go get bitbucket.org/jpoirier/cpu
# bitbucket.org/jpoirier/cpu
/root/go/src/bitbucket.org/jpoirier/cpu/cpu.go:7:18: fatal error: cpu.h: No such file or directory
 // #include "cpu.h"
                  ^
compilation terminated.

Any idea what could be causing this error?

I didn't seem to have a problem with
$ go get bitbucket.org/jpoirier/cpu
But I also updated the readme for the github repo with the correct command:
$ go get github.com/jpoirier/cpu

btw, the cpu package lives at both bitbucket and github, although I don't use bitbucket much these days.

Yeah, it works for me now with updated command. Thanks!

Great. And thanks for taking the time post the issue!
On a side note, keep in mind that this package hasn't really had any major updates in some time.


Enhancement of Readme.MD

This is a documentation enhancement issue.
Comment your ideas with relevant references to improve the appearance of the markdown file (eg. Add images, gifs, status, details)
Issue will be assigned on the basis of your idea and FCFS basis.
Kindly fill the below template while suggesting the improvement.

Template
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Can you assign this issue to me..I would love to work on it @kanishkaa24 .
I would like to include a brief introduction part in the readme about the project and will include the tech stacks needed for it, how it can be useful and what is the importance of this project.
I would also include svg, img(of few games during playing) or emojis to make the readme more attractive !
While submitting the PR I will surely upload the screenshot so that it will be easier for you to review and merge.
Kindly assign me.


django-compressor integration, included modernizr, boilerplate markup in base.html, and organised javascripts folder.

Turn off debug in development and we're good to go!


credentialz: clarify the expected format of authorized_key field

Currently AuthorizedKey message does not define the exact format of the key that is expected to be present in the message.
https://github.com/openconfig/gnsi/blob/559f7772b66ccaf88e311d4ff2292f29a5de0baa/credentialz/credentialz.proto#L436-L445
Even if we can assume that openssh rfc4253-based keys are used, then three interpretations are possible:

authorized_key should include a full pubkey string in the form of type key comment
authorized_key should include only the key bytes, making a non-zero value of the KeyType enum mandatory
both of the above should be allowed

This should be clarified in the .proto description.
cc @marcushines @morrowc @robshakir

In some other places we specified the key type with an enum (I thought) is there a reason to not just add the fields and proper enums here?

authorized_key should include a full pubkey string in the form of type key comment
AuthorizedKey has fields authorized_key key_type and description. Would it not be natural to assume that those correspond to:
authorized_key = key bytes
key_type = type of key
description = comment
Unless the key_type and description fields are meant for something else...?

mel, that does seem like the correct mapping to me...
Perhaps we should (maybe this was @LimeHat 's point) just update the docs in the proto to make this clear?
how's: https://github.com/openconfig/gnsi/pull/211

Would it not be natural to assume that those correspond to:
authorized_key = key bytes

Not necessarily.
"authorized key" is an ambiguous term. For some it is natural to assume unix authorized_keys format which implies the full string (e.g. ssh-rsa <public_key_bytes>).
Other proto fields can be omitted (unless something says that they cannot; but nothing says that in the proto).

In some other places we specified the key type with an enum (I thought) is there a reason to not just add the fields and proper enums here?

As long as there's a strict definition of the expected inputs, I'm fine with it; the main issue is the ambiguity.
I think for a typical user (outside of google) the direct consumption of a ssh-keygen output is a simpler approach (no need to do any parsing magic), but it comes down to preferences.

Perhaps we should (maybe this was @LimeHat 's point) just update the docs in the proto to make this clear?

Yes, choose which approach you think is correct (there are at least three possible options I indicated above, and that is only under the assumption that we're sticking to the single format) and explicitly document it.


Dartium 45 crashes

Using Dartium for minutes will eventually die not message this killed.

Dartium 45 has cherry-picked all CLs for Chromium 45.0.2454.104 - Dartium now stays up for hours w/o a crash.


Issues with PDO and our data

Since the PDO upgrade, using the query function from the database classes means that we can't pass null as a value any more.
PDO expects an actual value for a column, or to use bindValue and explicitly set PDO:: PARAM_NULL for the type. As we don't use that in query we can't define the type properly, and get errors instead.
So, the manager classes need to migrate over to using prepare and bindValue to function correctly again. I would be uncomfortable in allowing a 0 to go through to the table in place of null as this could have consequences further down the line that we don't know yet.

I have tried to save an entry today, that has Publish Tabs in it. Publish Tabs don't send any data through, but PDO is still expecting a value to be present; The value it recieves is '' (an empty string).
Symphony Fatal Database Error: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'value' at row 1
An error occurred while attempting to execute the following query
INSERT INTO `sym_entries_data_11` (`entry_id`, `value`) VALUES (?,?)
Backtrace
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/toolkit/class.database.php:745]
    Database->error();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/toolkit/class.database.php:535]
    Database->q();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/toolkit/class.mysql.php:427]
    Database->insert();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/toolkit/class.entrymanager.php:209]
    MySQL->insert();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/toolkit/class.entry.php:311]
    EntryManager::edit();
[/data/sites/cms.nigella.local.embarknow.net/symphony/content/content.publish.php:1434]
    Entry->commit();
[/data/sites/cms.nigella.local.embarknow.net/symphony/content/content.publish.php:374]
    contentPublish->__actionEdit();
[/data/sites/cms.nigella.local.embarknow.net/symphony/content/content.publish.php:350]
    contentPublish->__switchboard();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/toolkit/class.administrationpage.php:464]
    contentPublish->action();
[/data/sites/cms.nigella.local.embarknow.net/symphony/content/content.publish.php:345]
    AdministrationPage->build();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/core/class.administration.php:212]
    contentPublish->build();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/core/class.administration.php:479]
    Administration->__buildPage();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/boot/func.utilities.php:189]
    Administration->display();
[/data/sites/cms.nigella.local.embarknow.net/symphony/lib/boot/func.utilities.php:171]
    symphony_launcher();
[/data/sites/cms.nigella.local.embarknow.net/public/index.php:35]
    symphony();

Adding PDO was supposed to make our API so much easier, but instead, after looking through the relevant classes, it is so much more complicated. I really want to help debug and fix this, but I have no idea where to even start.

Adding PDO was supposed to make our API so much easier, but instead, after looking through the relevant classes, it is so much more complicated.

Thought the same thing, but I assumed this is only a rough first step and a long way to go until release. To be more specific, I don't really understand why there are two database classes now, class.database.php and class.mysql.php, where one is mostly a wrapper around the other.

 It's a little bit more effort than I thought it'd be, but the hard part is done :)

I don't really understand why there are two database classes now, class.database.php and class.mysql.php.

That's me being a little ambitious/naive by thinking eventually there will be class.postgres.php, class.sqlserver.php.

There's nothing naive about being ambitious :)
I've kind of fixed my immediate issue, by forcing the Publish Tabs field locally to send null, but weirdly, it's null values in the PageManager that cause the initial issue.
Very confused, but definitely sure we need to re-address how we process queries.


Variation in output by adding spaces

@yangheng95  - please see the below issue
Text1 =  """That is the question I asked then this morning. But most important how do they continue with no support options for clients for problems with these changes."""
Text2 = """That is the question I asked then this morning.  But most important how do they continue with no support options for clients for problems with these changes."""
The only difference between text 1 and text 2 is the space after 'But'. For text2 i am getting the error, for text1 its working fine.
Below is my code.
`triplet_extractor = ASTE.AspectSentimentTripletExtractor("multilingual")
 text1 = """That is the question I asked then this morning. But most important how do they continue with no support options for clients for problems with these changes."""
 text2 = """That is the question I asked then this morning.  But most important how do they continue with no support options for clients for problems with these changes."""
triplet_extractor.predict(text2)
 `
{'text': 'That is the question I asked then this morning.  But most important how do they continue with no support options for clients for problems with these changes.',
 'Triplets': '[]',
 'error': "can't assign a NoneType to a torch.LongTensor",
 'error_type': 'RuntimeError'}

Yes, there are some problems to be solved because the quadrule sentiment extraction is an experimental feature. Please try to make some efforts to solve it, and it will be excellent if you would like to share your solution.
After all, I will try to optimize it in future. Provided that I got a easy schedule.

HIi, do you solve this problem ?


feat: standard input JSON support [APE-963]

What I did
Allows compiling using standard input JSON technique.
This is required to do anything useful with the evm source map output.
How I did it
How to verify it
Checklist

[ ] Passes all linting checks (pre-commit and CI jobs)
[ ] New test cases have been added and are passing
[ ] Documentation has been updated
[ ] PR title follows Conventional Commit standard (will be automatically included in the changelog)

id like to also test with verification but want this merged first so i can: https://github.com/ApeWorX/ape-etherscan/pull/89


embed config file: Allow override from command line

Is your feature request related to a problem? Please describe.
When an application uses a larger framework for building and/or the Embed.toml content is to some extent invocation dependent, the Embedded.toml needs to be generated at a static location, whereas all other relevant paths (in particular the Cargo target directory) can be bent away, eg. from persistent disk to a RAM disk.
Describe the solution you'd like
Providing the path of the Embed.toml file in an argument (or an environment variable) would allow .
Describe alternatives you've considered

Passing all the content of the Embed.yaml on the command line would in theory be nice (and consistent with how we pass programmer and chip to probe-rs run), but easily gets out of hand in terms of size.
The Embed.local.yaml can be overwritten, which will not show up as a dirty git repository state when gitignored. However, with .

Additional context
I'm using cargo-embed from RIOT-rs. Its build system is about to be configured with different actions that, for example, may run the application with or without RTT.
Next steps
Unless people scream "no, bad approach" (or have a preference for environment variable vs. command-line argument), I'd start sketching a PR for this soon-ish.

A concrete example of generated content is when the build system starts a TCP listener on a random port, and from that generates the socket entry of a default.rtt.up_channel item.

I'm generally not opposed to cargo embed --config <path> or similar if you really need it.

The Embed.local.yaml can be overwritten, which will not show up as a dirty git repository state when gitignored. However, with .

I think you might have an unfinished thought there :) And it makes me wonder what that caveat is.
Wouldn't profiles be sufficient for your use case?

I think you might have an unfinished thought there :) And it makes me wonder what that caveat is.

That's what I get from doing too many things at the same time :-)
Should have been

The Embed.local.yaml can be overwritten, which will not show up as a dirty git repository state when gitignored. However, when the same application is built and run on different boards at the same time -- which is something that is common on RIOT OS when assessing portability, and I expect to do it a lot in RIOT-rs too. That probably works when flashed one after another (cargo embed won't change its behavior once running just because its Embed.toml changes), but as our build system prides itself in parallel building of multiple variations of an application, and we plan hardware-in-the-loop testing, eventually we'll run into race conditions.

Profiles would help to some extent, but we'd still be placing Embed.local.toml in a build system where every other generated file is in an easy-to-clean-up place, we'd be appending a profile to the file for every invocation, so that's not too pretty either.

This seems to have broken the --config option for cargo_embed
❯ cargo embed --config log
error: unexpected argument '--config' found

  tip: a similar argument exists: '--config-file'

Ahhh, the documentation is out of date.
cargo embed CONFIG_NAME works. the --config flag is not needed,
https://probe.rs/docs/tools/cargo-embed/

Profiles
The data in the Embed.toml is structured in two levels: The outer layer is a configuration profile name, inside each profile there are then a series of sections with different options. The default profile is called "default" ;) When invoking cargo-embed, a different profile name can be passed as an argument with --config , which will load the settings under that profile instead of default.

The docs are out of date.

That documentation is not part of the probe-rs sources as far as I can grep. AIU this is now being tracked in https://github.com/probe-rs/probe-rs/issues/2985, with nothing more to do around this issue here.


Access denied to IP address in ipWhitelist

config:
var config = {
address: '<IP_ADDRESS>', // Address to listen on, can be:
// - "localhost", "<IP_ADDRESS>", "::1" to listen on loopback interface
// - another specific IPv4/6 to listen on a specific interface
// - "", "<IP_ADDRESS>", "::" to listen on any interface
// Default, when address config is left out, is "localhost"
port: 8080,
ipWhitelist: [
'<IP_ADDRESS>',
'::ffff:<IP_ADDRESS>',
'::1',
'::ffff:<IP_ADDRESS>/120',
'::ffff:<IP_ADDRESS>/120'
],
Log:
0|mmm    | ><EMAIL_ADDRESS>start /Users/mmm/MagicMirror
0|mmm    | > sh run-start.sh
0|mmm    | cut: illegal option -- -
0|mmm    | usage: cut -b list [-n] [file ...]
0|mmm    |        cut -c list [file ...]
0|mmm    |        cut -f list [-s] [-d delim] [file ...]
0|mmm    | Starting MagicMirror: v2.9.0
0|mmm    | Loading config ...
0|mmm    | Loading module helpers ...
0|mmm    | No helper found for module: alert.
0|mmm    | Initializing new module helper ...
0|mmm    | Module helper loaded: updatenotification
0|mmm    | No helper found for module: clock.
0|mmm    | Initializing new module helper ...
0|mmm    | Module helper loaded: calendar
0|mmm    | No helper found for module: MMM-WiFiPassword.
0|mmm    | No helper found for module: compliments.
0|mmm    | Initializing new module helper ...
0|mmm    | Module helper loaded: MMM-DarkSkyForecast
0|mmm    | Initializing new module helper ...
0|mmm    | Module helper loaded: newsfeed
0|mmm    | All module helpers loaded.
0|mmm    | Starting server on port 8080 ...
0|mmm    | Server started ...
0|mmm    | Connecting socket for: updatenotification
0|mmm    | Connecting socket for: calendar
0|mmm    | Starting node helper for: calendar
0|mmm    | Connecting socket for: MMM-DarkSkyForecast
0|mmm    | ====================== Starting node_helper for module [MMM-DarkSkyForecast]
0|mmm    | Connecting socket for: newsfeed
0|mmm    | Starting module: newsfeed
0|mmm    | Sockets connected & modules started ...
0|mmm    | 2019-12-03 22:00:10.244 Electron[574:6716] ApplePersistence=NO
0|mmm    | Launching application.
0|mmm    | Create new calendar fetcher for url: http://www.calendarlabs.com/ical-calendar/ics/76/US_Holidays.ics - Interval: 300000
0|mmm    | Create new news fetcher for url: http://www.ynet.co.il/Integration/StoryRss1854.xml - Interval: 300000
0|mmm    | Access denied to IP address: <IP_ADDRESS>
0|mmm    | Access denied to IP address: <IP_ADDRESS>

that <IP_ADDRESS>/120 is an invalid address mask..
120 can be at MAX 32 (all 32 bits of address allowed)
you could do <IP_ADDRESS>/32 to ONLY allow from that address

that <IP_ADDRESS>/120 is an invalid address mask..
120 can be at MAX 32 (all 32 bits of address allowed)
you could do <IP_ADDRESS>/32 to ONLY allow from that address

I would like to enable whitelist my local pull and my vpn pull. what's the right syntax to do this?

found the right syntax:

ipWhitelist: [
'<IP_ADDRESS>',
'::ffff:<IP_ADDRESS>',
'::1',
'<IP_ADDRESS>/24',
'<IP_ADDRESS>/24'
],


Housekeeping: Update zeit/ncc to vercel/ncc

Reopen #190 because https://github.com/vercel/ncc/issues/748 has been fixed.
Description:
zeit/ncc is no longer maintained, so it's better to replace it with vercel/ncc.
I've confirmed that this change does not affect file size so much:

dist/cleanup/index.js: 2587155 -> 2582807 (-4348 bytes)
dist/setup/index.js: 3939141 -> 3938987 (-154 bytes)

Related issue:
None
Check list:

[x] Mark if documentation changes are required.
[ ] Mark if tests were added or updated to cover the changes.

recreated as #270


Pull in bug fixes

Hey @LukasW94,
Thanks for the changes - looks like you've crushed some bugs! I'm going to review them and merge your changes in.
Cheers,
Eric

Small side note, I don't really think that the .gitignore should've been updated. This just made sure that, after being build, I didn't had to exclude any files/folders in my commit.

I think the .gitignore is a good update - we don't want machine-specific binaries in the repo, and we definitely don't want the tacky pre-build file flag in there as it's meant to signal we've built, not cloned.
I'm working on fixing the output now.


Exchange 2010

line 215: if int(versioninfo.get('MajorVersion')) == 14:
logging.info('Exchange 2010 detected. This version is not vulnerable to PrivExchange.')
line 67: EXCHANGE_VERSIONS = ["2010_SP1","2010_SP2","2013","2016"]
I'm so confused that if all service pack of Exchange 2010 are not affected by privexchange or just SP3.

They are not vulnerable. The list of EXCHANGE_VERSIONS are a actually possible API Dialects (not vulnerable exchange versions). For example Exchange 2016 can still use the 2010_SP1 dialect for API calls.


Activate HTTPS + Enforce HTTPS

You should activate HTTPS for the custom domain in the GitHub pages settings.
SEE: https://help.github.com/en/articles/about-custom-domains-and-github-pages
And enforce HTTPS
SEE: https://help.github.com/en/articles/securing-your-github-pages-site-with-https#enforcing-https-for-your-github-pages-site

The Website is using HTTPS as on 2 July 2020,


Door placement rules break when ship modules have limited doorway snap points

The door placement rules break in at least two ways if one uses ship modules that do not have doorway snap points on all sides.
Details
Discovered the bug while using the Stroud Premium Edition mod.  The 1x1 habs have a doorway on only one side.  This has exposed at least two bugs in the door placement rules.
Please use this save game with the Dark Justice ship to see the bug: https://www.dropbox.com/scl/fi/6nqs8iiltc2myq6x25lwe/Exitsave0_25BAA021M44726561642050697261746520526F6265727473_211134_20241028032815_133_8_4.sfs?rlkey=u9gwv09a95c477145cknqmeow&dl=0
The first bug was found by the mod author, Vince134 on the Bethesda Game Studios Discord, when I DM'd him with the initial door placement issue related to his mod.  Placing the 1x1 aft doc's quarters module to the left of the 3x1 Nova eng module cause a non-functional door to appear in the eng module's midway point.
This is caused by a condition that forces a starboard door on a 3x1 Nova module even if the starboard module does not have a doorway.  The fix is to change an 'OR' to an 'AND'.  The fix is implemented in this ESM and credit should go to Vince134 - https://www.dropbox.com/scl/fi/r58r4jxqzurryjmz5ez8l/NovaStbdDoorFix.esm?rlkey=tpn5fe5lpuh4wucbtz4i5lt0p&dl=0.
In further testing, I found that adding a module that lacks doors on all sides causes additional failures in the door placement rules.  I am still trying to track down which rules are not firing properly, but I can describe the failure scenarios here.

Take the Dark Justice in the save game, replace the 3x1 Nova Eng module with a 3x1 Deimos eng module.  Board the ship and note that no doors are spawned to the 1x1 doc's quarters.

Replace the 1x1 doc's quarters with a HopeTech 1x1 companionway.  Board the ship and notice that there are now doors leading from the eng module mid-point to the companionway and out the other side to the living quarters

Move the Grav Drive back on space and place the 1x1 aft doc's quarters behind the 1x1 companion way.  Board the ship and note that the entire left rear part of the ship is inaccessible as there is no doorway leading to the 1x1 companionway.  If one does a TCL and goes into the companionway, one will see that it has spawned doors to the aft doc's quarters and the left-side living quarters, but no doors to the front or right side of the companionway to join the rest of the ship.

I've not tracked down where the rules failure reside for this 2nd issue.  I'll update this bug report if I can track it down.
Game Version
1.14.70
Language
English (EN)
Have you recreated this issue on a new game?
Yes, I can recreate this issue.
Reproduction Steps
See Details.

More testing to narrow down the failure.
The failure only occurs when:

The 1x1 aft doc's quarters are behind the 1x1 companionway
The 3x1 eng module is adjacent to the 2x1 armory, the 1x1 companionway and the 1x1 aft doc's quarters

if one slides the 3x1 eng module forward or backwards one space, so that it is only adjacent to two modules, the doors spawn properly.
The issue appears to be that when the 3x1 eng module is adjacent to all three modules, the door placement rules want to place a left door to the armory and a left door to the aft-most 1x1 module, but when the aft-most 1x1 module does not have a door on the right side, the door placement rules fail to notice that it could not place that aft-most left door.  The rest of the door placement behaves as if the aft-most left door was placed.
One can see this preference for the aft-most left door if one replaces the 1x1 doc's quarters with a generic 1x1 companionway.  The 3x1 module will spawn a left door at the front (connecting to the armory) and at the very rear (connecting to the aft-most 1x1 companionway).  The rest of the doors spawn in the same pattern seen when the aft-most module is the 1x1 doc's quarters but result in a disconnected ship because it cannot actually spawn that aft-most door.


Portable stub.exe is not being signed

All binaries are signed by my cert but stub.exe in Portable.zip root (Update.exe is also signed)
Also, how can I give a stub different more friendly name than main executable?

Thanks for reporting this!

Fixed in 04cf01cc87f04904b974dbc4275b1f0ecb97e87d.
The stub will now respect the --packTitle argument, similar to shortcuts in the installed apps.


[Event Request] Report 5754 - OnAfterSetWkshPickLine

Report 5754 "Create Pick"
procedure SetWkshPickLine(var PickWhseWkshLine2: Record "Whse. Worksheet Line")
begin
    PickWhseWkshLine.CopyFilters(PickWhseWkshLine2);
    LocationCode := PickWhseWkshLine2."Location Code";
+     OnAfterSetWkshPickLine(PickWhseWkshLine2, SortPick);
end;

+ [IntegrationEvent(false, false)]
+ local procedure OnAfterSetWkshPickLine(PickWhseWkshLine: Record "Whse. Worksheet Line"; var SortPick: Option)
+ begin
+ end;

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


CSV exports: Add option to export Excel with meta information

Exports could benefit from including meta / bookkeeping information such as the following:

Calcification rate exports:

Table name of the label calcification rates used in the calculation, whether it's a default table or a custom table.

(Possibly) The entire table of label calcification rates that was used for the computations. This should be pretty small in size compared to the rest of the data in the export, so might as well include it.

All exports:

Source name.

Image-filtering criteria used in the export.

Date of the export operation.

It seems awkward to include meta information alongside data cells, because that could break sorting or other spreadsheet processing tasks. So I think this should be implemented as an option to export to Excel format rather than CSV, with multiple worksheets included: one for the main data, and one for the meta / bookkeeping data. (And for calcification rate exports, one worksheet for the table of label calcification rates.)

Done in PR #405.


How to get this module to use cuda121

I tried to switch to cuda121 following the official guide
python -m bitsandbytes
Then I encountered the encoding error "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd5 in position 0: invalid continuation byte"
When I switch windows 11 to utf-8 mode I get the following error
===================================BUG REPORT===================================
Welcome to bitsandbytes. For bug reports, please run
python -m bitsandbytes
and submit this information together with your error trace to: https://github.com/TimDettmers/bitsandbytes/issues
bin D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes\libbitsandbytes_cuda121.dll
D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes\cuda_setup\main.py:156: UserWarning: WARNING: The following directories listed in your path were found to be non-existent: {WindowsPath('D:/ProgramFiles/text-generation-webui/conda/bin')}
warn(msg)
D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes\cuda_setup\main.py:156: UserWarning: D:\ProgramFiles\text -generation-webui\conda did not contain ['cudart64_110.dll', 'cudart64_120.dll', 'cudart64_12.dll'] as expected! Searching further paths...
warn(msg)
CUDA SETUP: CUDA runtime path found: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.1\bin\cudart64_12.dll
CUDA SETUP: Highest compute capability among GPUs detected: 8.6
CUDA SETUP: Detected CUDA version 121
CUDA SETUP: Loading binary D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes\libbitsandbytes_cuda121.dll...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++ BUG REPORT INFORMATION ++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Traceback (most recent call last).
File "D:\ProgramFiles\text-generation-webui\conda\lib\runpy.py", line 196, in run_module_as_main
return run_code(code, main_globals, None.
File "D:\ProgramFiles\text-generation-webui\conda\lib\runpy.py", line 86, in run_code
exec(code, run_globals)
File "D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes_main.py", line 95, in
generate_bug_report_information()
File "D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes_main.py", line 49, in generate_bug_report_information() information
paths = find_file_recursive(os.environ['CONDA_PREFIX'], 'cudaso')
File "D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes_main_.py", line 37, in find_file_recursive
raise RuntimeError('Something when wrong when trying to find file. Maybe you do not have a linux system?')
RuntimeError: Something when wrong when trying to find file. Maybe you do not have a linux system?

The bug report information code called by running python -m bitsandbytes has not been rewritten to work on Windows yet. I'll get around to it eventually.
Based on the information before that part, I'm pretty sure it is loading CUDA 12.1:
CUDA SETUP: CUDA runtime path found: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.1\bin\cudart64_12.dll
CUDA SETUP: Highest compute capability among GPUs detected: 8.6
CUDA SETUP: Detected CUDA version 121
CUDA SETUP: Loading binary D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes\libbitsandbytes_cuda121.dll...

The bug report information code called by running python -m bitsandbytes has not been rewritten to work on Windows yet. I'll get around to it eventually.
Based on the information before that part, I'm pretty sure it is loading CUDA 12.1:
CUDA SETUP: CUDA runtime path found: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.1\bin\cudart64_12.dll
CUDA SETUP: Highest compute capability among GPUs detected: 8.6
CUDA SETUP: Detected CUDA version 121
CUDA SETUP: Loading binary D:\ProgramFiles\text-generation-webui\conda\lib\site-packages\bitsandbytes\libbitsandbytes_cuda121.dll...

Yes, it has worked, thanks!


Random music on every startup

I used (music.mp3) file for background music
On settings ( one music for all platforms & games)
Is it possible to put multiple background mp3 music files, and play them randomly on each startup of playnite
Like:
music1.mp3
music2.mp3
music3.mp3 .......etc

This feature is currently being tested.


replace tabs in Rubocop config with spaces

YAML does not permit tabs and many parsers will error when loading a tab-indented file - http://www.yaml.org/faq.html

Thanks @thomas-mcdonald ! Would you mind closing this PR and re-opening against the develop branch per the instructions in the readme?

@ericfreese changed the branch!


conan package does not print pretty stack.

Following is my sample project setup.
# conan file
$ cat <<EOF > conanfile.txt
[requires]
backward-cpp/1.6

[generators]
CMakeDeps
CMakeToolchain
EOF

# CMakeLists.txt file
$ cat <<EOF > CMakeLists.txt
cmake_minimum_required(VERSION 3.14...3.22)

project(
  backward_sample
  LANGUAGES CXX
  VERSION 0.1
  DESCRIPTION "backward_sample"
)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

include(./conan_deps/conan_toolchain.cmake)

find_package(Backward REQUIRED)

add_executable(backward_sample backward_sample.cpp)
set_target_properties(backward_sample
  PROPERTIES
  CXX_STANDARD 17
  OUTPUT_NAME backward_sample
)
target_link_libraries(backward_sample PRIVATE Backward::Backward)
EOF

# test source file
$ cat <<EOF > backward_sample.cpp
#include "backward.hpp"

namespace backward {

backward::SignalHandling sh;

} // namespace backward

void crash() {
  volatile int* a = (int*)(NULL);
  *a = 1;
}

int main(int argc, char* argv[]) {
  crash();
  return 0;
}
EOF

I compiled this project by following step:
$ mkdir conan_deps && cd conan_deps

$ conan install .. -pr Debug

$ cmake -B build -DCMAKE_BUILD_TYPE=Debug

$ cmake --build build --verbose

I can see that it is compiled with -g option and DBACKWARD_HAS_DWARF=1 flag.
It also seems be linked with libdwarf and libelf.
[ 50%] Building CXX object CMakeFiles/backward_sample.dir/backward_sample.cpp.o
/usr/bin/c++ -DBACKWARD_HAS_BACKTRACE=0 -DBACKWARD_HAS_BACKTRACE_SYMBOL=0 -DBACKWARD_HAS_BFD=0 -DBACKWARD_HAS_DW=0 -DBACKWARD_HAS_DWARF=1 -DBACKWARD_HAS_LIBUNWIND=0 -DBACKWARD_HAS_PDB_SYMBOL=0 -DBACKWARD_HAS_UNWIND=1 -isystem /home/jbseo/.conan/data/backward-cpp/1.6/_/_/package/2e02edff0a8a2b4d15d2baca54e2cbc7ecca7eae/include -isystem /home/jbseo/.conan/data/libdwarf/20191104/_/_/package/29a01e41514e57b26ac6cb3d59a534cdaa425a4d/include -isystem /home/jbseo/.conan/data/libelf/0.8.13/_/_/package/be27726f9885116da1158027505be62e913cd585/include -isystem /home/jbseo/.conan/data/libelf/0.8.13/_/_/package/be27726f9885116da1158027505be62e913cd585/include/libelf -isystem /home/jbseo/.conan/data/zlib/1.2.13/_/_/package/be27726f9885116da1158027505be62e913cd585/include -g -std=gnu++17 -MD -MT CMakeFiles/backward_sample.dir/backward_sample.cpp.o -MF CMakeFiles/backward_sample.dir/backward_sample.cpp.o.d -o CMakeFiles/backward_sample.dir/backward_sample.cpp.o -c /home/jbseo/playground/backward_cpp/backward_sample.cpp
[100%] Linking CXX executable backward_sample
/usr/bin/cmake -E cmake_link_script CMakeFiles/backward_sample.dir/link.txt --verbose=1
/usr/bin/c++ -g CMakeFiles/backward_sample.dir/backward_sample.cpp.o -o backward_sample  /home/jbseo/.conan/data/backward-cpp/1.6/_/_/package/2e02edff0a8a2b4d15d2baca54e2cbc7ecca7eae/lib/libbackward.a -ldl -lm /home/jbseo/.conan/data/libdwarf/20191104/_/_/package/29a01e41514e57b26ac6cb3d59a534cdaa425a4d/lib/libdwarf.a /home/jbseo/.conan/data/zlib/1.2.13/_/_/package/be27726f9885116da1158027505be62e913cd585/lib/libz.a /home/jbseo/.conan/data/libelf/0.8.13/_/_/package/be27726f9885116da1158027505be62e913cd585/lib/libelf.a

However, the generated binary only print simple stack without debug info.
$ ./build/backward_sample
Stack trace (most recent call last):
#5    Object "", at 0xffffffffffffffff, in
#4    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55d51ff8e924, in
#3    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6ebd166e3f, in __libc_start_main
#2    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6ebd166d8f, in
#1    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55d51ff8ea1d, in
#0    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55d51ff8e9fd, in
Segmentation fault (Address not mapped to object [(nil)])
Segmentation fault

I cannot figure out what I have missed.
Thanks for your advice in advance.

without the necessary libraries it won't be able to read the debug symbols.
this might be the reason
On Thu, Jun 22, 2023, 00:56 jbongseo @.***> wrote:

Following is my sample project setup.
conan file
$ cat < conanfile.txt[requires]backward-cpp/1.6[generators]CMakeDepsCMakeToolchainEOF
CMakeLists.txt file
$ cat < CMakeLists.txtcmake_minimum_required(VERSION 3.14...3.22)project(  backward_sample  LANGUAGES CXX  VERSION 0.1  DESCRIPTION "backward_sample")set(CMAKE_CXX_STANDARD 17)set(CMAKE_CXX_STANDARD_REQUIRED ON)set(CMAKE_EXPORT_COMPILE_COMMANDS ON)include(./conan_deps/conan_toolchain.cmake)find_package(Backward REQUIRED)add_executable(backward_sample backward_sample.cpp)set_target_properties(backward_sample  PROPERTIES  CXX_STANDARD 17  OUTPUT_NAME backward_sample)target_link_libraries(backward_sample PRIVATE Backward::Backward)EOF
test source file
$ cat < backward_sample.cpp#include "backward.hpp"namespace backward {backward::SignalHandling sh;} // namespace backwardvoid crash() {  volatile int* a = (int*)(NULL);  a = 1;}int main(int argc, char argv[]) {  crash();  return 0;}EOF
I compiled this project by following step:
$ mkdir conan_deps && cd conan_deps
$ conan install .. -pr Debug
$ cmake -B build -DCMAKE_BUILD_TYPE=Debug
$ cmake --build build --verbose
I can see that it is compiled with -g option and DBACKWARD_HAS_DWARF=1
flag.
It also seems be linked with libdwarf and libelf.
[ 50%] Building CXX object CMakeFiles/backward_sample.dir/backward_sample.cpp.o
/usr/bin/c++ -DBACKWARD_HAS_BACKTRACE=0 -DBACKWARD_HAS_BACKTRACE_SYMBOL=0 -DBACKWARD_HAS_BFD=0 -DBACKWARD_HAS_DW=0 -DBACKWARD_HAS_DWARF=1 -DBACKWARD_HAS_LIBUNWIND=0 -DBACKWARD_HAS_PDB_SYMBOL=0 -DBACKWARD_HAS_UNWIND=1 -isystem /home/jbseo/.conan/data/backward-cpp/1.6///package/2e02edff0a8a2b4d15d2baca54e2cbc7ecca7eae/include -isystem /home/jbseo/.conan/data/libdwarf/20191104///package/29a01e41514e57b26ac6cb3d59a534cdaa425a4d/include -isystem /home/jbseo/.conan/data/libelf/0.8.13///package/be27726f9885116da1158027505be62e913cd585/include -isystem /home/jbseo/.conan/data/libelf/0.8.13///package/be27726f9885116da1158027505be62e913cd585/include/libelf -isystem /home/jbseo/.conan/data/zlib/1.2.13///package/be27726f9885116da1158027505be62e913cd585/include -g -std=gnu++17 -MD -MT CMakeFiles/backward_sample.dir/backward_sample.cpp.o -MF CMakeFiles/backward_sample.dir/backward_sample.cpp.o.d -o CMakeFiles/backward_sample.dir/backward_sample.cpp.o -c /home/jbseo/playground/backward_cpp/backward_sample.cpp
[100%] Linking CXX executable backward_sample
/usr/bin/cmake -E cmake_link_script CMakeFiles/backward_sample.dir/link.txt --verbose=1
/usr/bin/c++ -g CMakeFiles/backward_sample.dir/backward_sample.cpp.o -o backward_sample  /home/jbseo/.conan/data/backward-cpp/1.6///package/2e02edff0a8a2b4d15d2baca54e2cbc7ecca7eae/lib/libbackward.a -ldl -lm /home/jbseo/.conan/data/libdwarf/20191104///package/29a01e41514e57b26ac6cb3d59a534cdaa425a4d/lib/libdwarf.a /home/jbseo/.conan/data/zlib/1.2.13///package/be27726f9885116da1158027505be62e913cd585/lib/libz.a /home/jbseo/.conan/data/libelf/0.8.13///package/be27726f9885116da1158027505be62e913cd585/lib/libelf.a
However, the generated binary only print simple stack without debug info.
$ ./build/backward_sample
Stack trace (most recent call last):
#5    Object "", at 0xffffffffffffffff, in
#4    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55d51ff8e924, in
#3    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6ebd166e3f, in __libc_start_main
#2    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6ebd166d8f, in
#1    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55d51ff8ea1d, in
#0    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55d51ff8e9fd, in
Segmentation fault (Address not mapped to object [(nil)])
Segmentation fault
I cannot figure out what I have missed.
Thanks for your advice in advance.
—
Reply to this email directly, view it on GitHub
https://github.com/bombela/backward-cpp/issues/299, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABUZDF2FEZH2HCSSESHDYTXMP3BPANCNFSM6AAAAAAZPZ3HM4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

without the necessary libraries it won't be able to read the debug symbols.

That may be the source of the problem.
libdwarf and libelf is compiled and linked statically as specified by conan receipt and we can see that in the build log.
/usr/bin/c++ -g CMakeFiles/backward_sample.dir/backward_sample.cpp.o -o backward_sample
[BLAH_PATH]/libbackward.a
 -ldl -lm                             // <- ldl
[BLAH_PATH]/libdwarf.a    // <- linked statically
[BLAH_PATH]/libz.a
[BLAH_PATH]/libelf.a        // <- linked statically

And we can check that using ldd command.
$ ldd build/backward_sample
        linux-vdso.so.1 (0x00007ffe2c943000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f46f6dd0000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f46f6db0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f46f6b88000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f46f6aa1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f46f70a3000)

By the way, I tried installing those library globally and linked them forcefully.
Then it worked as expected.
sudo apt-get install libdwarf-dev libelf-dev

# CMakeLists.txt
# add  -ldwarf -lelf flag to forcefully link global library
target_link_libraries(backward_sample PRIVATE Backward::Backward -ldwarf -lelf)

$ cmake --build build --clean-first --verbose
...
[100%] Linking CXX executable backward_sample
/usr/bin/cmake -E cmake_link_script CMakeFiles/backward_sample.dir/link.txt --verbose=1
/usr/bin/c++ -g CMakeFiles/backward_sample.dir/backward_sample.cpp.o -o backward_sample
-ldwarf -lelf     <-- forcefully injected link
[BLAH_PATH]/libbackward.a
 -ldl -lm
[BLAH_PATH]/libdwarf.a  <-- provided by cmake. maybe ignored?
[BLAH_PATH]/libz.a
[BLAH_PATH]/libelf.a  <-- provided by cmake. maybe ignored?

Now, libdwarf, libelf, libz are linked dynamically.
$ ldd ./build/backward_sample
        linux-vdso.so.1 (0x00007ffde4d86000)
        libdwarf.so.1 => /lib/x86_64-linux-gnu/libdwarf.so.1 (0x00007f7ffa159000)
        libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1 (0x00007f7ffa13b000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7ff9f11000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7ff9ef1000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ff9cc9000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7ff9cab000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7ffa23a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7ff9bc4000)

and it works well now.
$ ./build/backward_sample
Stack trace (most recent call last):
#5    Object "", at 0xffffffffffffffff, in
#4    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55a592030a84, in _start
#3    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f76f1442e3f, in __libc_start_main
#2    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f76f1442d8f, in __libc_init_first
#1    Source "/home/jbseo/playground/backward_cpp/backward_sample.cpp", line 15, in int main(int argc, char **argv) [0x55a592030b7d]
         12: }
         13:
         14: int main(int argc, char* argv[]) {
      >  15:   crash();
         16:   return 0;
         17: }
#0    Source "/home/jbseo/playground/backward_cpp/backward_sample.cpp", line 11, in crash() [0x55a592030b5d]
          9: void crash() {
         10:   volatile int* a = (int*)(NULL);
      >  11:   *a = 1;
         12: }
         13:
         14: int main(int argc, char* argv[]) {
Segmentation fault (Address not mapped to object [(nil)])
Segmentation fault

I do not know the reason.
Maybe libdwarf should not be linked statically or libdwarf conan package has some problem in it.
Anyway, conan package should not be encouraged currently.
Thanks for the great library!

Sadly I don't know anything about conan (and not much about CMake)! I
accepted pull requests from kind people :D
On Thu, Jun 22, 2023, 17:21 jbongseo @.***> wrote:

without the necessary libraries it won't be able to read the debug symbols.
That may be the source of the problem.
libdwarf and libelf is compiled and linked statically as specified by
conan receipt and we can see that in the build log.
/usr/bin/c++ -g CMakeFiles/backward_sample.dir/backward_sample.cpp.o -o backward_sample
[BLAH_PATH]/libbackward.a
-ldl -lm                             // <- ldl
[BLAH_PATH]/libdwarf.a    // <- linked statically
[BLAH_PATH]/libz.a
[BLAH_PATH]/libelf.a        // <- linked statically
And we can check that using ldd command.
$ ldd build/backward_sample
linux-vdso.so.1 (0x00007ffe2c943000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f46f6dd0000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f46f6db0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f46f6b88000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f46f6aa1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f46f70a3000)
By the way, I tried installing those library globally and linked them
forcefully.
Then it worked as expected.
sudo apt-get install libdwarf-dev libelf-dev
CMakeLists.txt
add  -ldwarf -lelf flag to forcefully link global library
target_link_libraries(backward_sample PRIVATE Backward::Backward -ldwarf -lelf)
$ cmake --build build --clean-first --verbose
...
[100%] Linking CXX executable backward_sample
/usr/bin/cmake -E cmake_link_script CMakeFiles/backward_sample.dir/link.txt --verbose=1
/usr/bin/c++ -g CMakeFiles/backward_sample.dir/backward_sample.cpp.o -o backward_sample
-ldwarf -lelf     <-- forcefully injected link
[BLAH_PATH]/libbackward.a
-ldl -lm
[BLAH_PATH]/libdwarf.a  <-- provided by cmake. maybe ignored?
[BLAH_PATH]/libz.a
[BLAH_PATH]/libelf.a  <-- provided by cmake. maybe ignored?
Now, libdwarf, libelf, libz are linked dynamically.
$ ldd ./build/backward_sample
linux-vdso.so.1 (0x00007ffde4d86000)
libdwarf.so.1 => /lib/x86_64-linux-gnu/libdwarf.so.1 (0x00007f7ffa159000)
libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1 (0x00007f7ffa13b000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7ff9f11000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7ff9ef1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ff9cc9000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7ff9cab000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7ffa23a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7ff9bc4000)
and it works well now.
$ ./build/backward_sample
Stack trace (most recent call last):
#5    Object "", at 0xffffffffffffffff, in
#4    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55a592030a84, in _start
#3    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f76f1442e3f, in __libc_start_main
#2    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f76f1442d8f, in __libc_init_first
#1    Source "/home/jbseo/playground/backward_cpp/backward_sample.cpp", line 15, in int main(int argc, char argv) [0x55a592030b7d]
12: }
13:
14: int main(int argc, char argv[]) {
>  15:   crash();
16:   return 0;
17: }
#0    Source "/home/jbseo/playground/backward_cpp/backward_sample.cpp", line 11, in crash() [0x55a592030b5d]
9: void crash() {
10:   volatile int a = (int*)(NULL);
>  11:   a = 1;
12: }
13:
14: int main(int argc, char argv[]) {
Segmentation fault (Address not mapped to object [(nil)])
Segmentation fault
I do not know the reason.
Maybe libdwarf should not be linked statically or libdwarf conan package
has some problem in it.
Anyway, conan package should not be encouraged currently.
Thanks for the great library!
—
Reply to this email directly, view it on GitHub
https://github.com/bombela/backward-cpp/issues/299#issuecomment-1603468017,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABUZDCJOTOEAIZUSVEVVTLXMTOQBANCNFSM6AAAAAAZPZ3HM4
.
You are receiving this because you commented.Message ID:
@.***>

without the necessary libraries it won't be able to read the debug symbols.

That may be the source of the problem.
libdwarf and libelf is compiled and linked statically as specified by conan receipt and we can see that in the build log.
/usr/bin/c++ -g CMakeFiles/backward_sample.dir/backward_sample.cpp.o -o backward_sample
[BLAH_PATH]/libbackward.a
 -ldl -lm
[BLAH_PATH]/libdwarf.a    <--- linked statically
[BLAH_PATH]/libz.a
[BLAH_PATH]/libelf.a      <--- linked statically

And we can check that using ldd command.
$ ldd build/backward_sample
        linux-vdso.so.1 (0x00007ffe2c943000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f46f6dd0000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f46f6db0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f46f6b88000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f46f6aa1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f46f70a3000)

By the way, I tried installing those library globally and linked them forcefully. Then it worked as expected.
sudo apt-get install libdwarf-dev libelf-dev

# CMakeLists.txt
# add  -ldwarf -lelf flag to forcefully link global library
target_link_libraries(backward_sample PRIVATE Backward::Backward -ldwarf -lelf)

$ cmake --build build --clean-first --verbose
...
[100%] Linking CXX executable backward_sample
/usr/bin/cmake -E cmake_link_script CMakeFiles/backward_sample.dir/link.txt --verbose=1
/usr/bin/c++ -g CMakeFiles/backward_sample.dir/backward_sample.cpp.o -o backward_sample

-ldwarf -lelf     <-- forcefully injected link

[BLAH_PATH]/libbackward.a
 -ldl -lm

[BLAH_PATH]/libdwarf.a  <-- provided by cmake. maybe ignored?
[BLAH_PATH]/libz.a
[BLAH_PATH]/libelf.a  <-- provided by cmake. maybe ignored?

Now, libdwarf, libelf, libz are linked dynamically.
$ ldd ./build/backward_sample
        linux-vdso.so.1 (0x00007ffde4d86000)
        libdwarf.so.1 => /lib/x86_64-linux-gnu/libdwarf.so.1 (0x00007f7ffa159000)
        libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1 (0x00007f7ffa13b000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7ff9f11000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7ff9ef1000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ff9cc9000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7ff9cab000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7ffa23a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7ff9bc4000)

and it works well now.
$ ./build/backward_sample
Stack trace (most recent call last):
#5    Object "", at 0xffffffffffffffff, in
#4    Object "/home/jbseo/playground/backward_cpp/build/backward_sample", at 0x55a592030a84, in _start
#3    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f76f1442e3f, in __libc_start_main
#2    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f76f1442d8f, in __libc_init_first
#1    Source "/home/jbseo/playground/backward_cpp/backward_sample.cpp", line 15, in int main(int argc, char **argv) [0x55a592030b7d]
         12: }
         13:
         14: int main(int argc, char* argv[]) {
      >  15:   crash();
         16:   return 0;
         17: }
#0    Source "/home/jbseo/playground/backward_cpp/backward_sample.cpp", line 11, in crash() [0x55a592030b5d]
          9: void crash() {
         10:   volatile int* a = (int*)(NULL);
      >  11:   *a = 1;
         12: }
         13:
         14: int main(int argc, char* argv[]) {
Segmentation fault (Address not mapped to object [(nil)])
Segmentation fault

I do not know the reason. Maybe libdwarf should not be linked statically or libdwarf conan package has some problem in it. Anyway, conan package should not be encouraged currently.
Thanks for the great library!

Hi, can you elaborate more about the steps?? I'm not familiar with cpp....


uffizzi project create backend

We need to implement API for the uffizzi project create command
https://github.com/UffizziCloud/uffizzi_cli/issues/77

[POST] /api/cli/v1/projects

There is no information about route in the /api-docs

Needs to add information about  parameters for request in /api-docs

Swagger documentation updated

verified in production


Create .vsdx files from scratch, create Shapes in a empty file

Hi,
I am trying to create software architecture diagrams from inventory data. Since it is the main goal to have editable documents, Visio is a suitable solution. it would be great to use vsdx as the library.
What I was not able to find yet, is there a way to create new diagrams from scratch?
I found the description of altering existing files, but was not able to find a description of creating a completely new file, with new shapes.

You can create visio file manually with all shape with different names placed on one page that you required. use that file as template to create another visio diagram by adding new page and copy shape using name or if you know how to add new shape then add . at the last delete first page.


fix: checkboxes replace the decorators on test type page

This PR is for adding in simple checkboxes for the Test Types. This fix replaces the decorators that were originally present with styled checkboxes.

Changed "Payload Transporter" to "Non Destructive Testing"


Archiving old Tianocore site, adding new site files

Moved all old site files into _ARCHIVED and added new files into the root directory.

I've been able to prototype changes to the site in this fork of the repo:
https://github.com/jljusten/tianocore
and preview at this url http://jljusten.github.io/tianocore
Maybe this will help to show demonstrate the new site?
Also, can't we migrate the new proposed layout in place and preserve as much as possible of the current site? (Rather than _ARCHIVED...)

Hi Jordan,
Unfortunately, given the very short timeframe of this project, and making it responsive, a "teardown" was the only efficient method.
And to confirm, are you asking me to fork the tianocaore repo for you and merge my updates there to preview?

Hi Jordan,
I’m looping Travis into our discussion on the redesign/rebuild of Tianocore, if you have any questions/need clarifications on this project's requirements, it would be best to pass them directly to him. Thanks!
Ryan O'Reilly
Senior Web Developer
thenewgroup
4540 SW Kelly Avenue
Portland, Oregon 97239
Office:<PHONE_NUMBER>
Direct:<PHONE_NUMBER>
www.thenewgroup.comhttp://www.thenewgroup.com/

Hi Jordan,
Unfortunately, given the very short timeframe of this project, and making it responsive, a "teardown" was the only efficient method.
And to confirm, are you asking me to fork the tianocaore repo for you and merge my updates there to preview?
From: Jordan Justen <notifications<EMAIL_ADDRESS>Reply-To: "tianocore/tianocore.github.io" <reply<EMAIL_ADDRESS>Date: Tuesday, June 30, 2015 at 11:51 AM
To: "tianocore/tianocore.github.io" <tianocore.github.io<EMAIL_ADDRESS>Cc: Ryan O'Reilly <ryan.oreilly<EMAIL_ADDRESS>Subject: Re: [tianocore.github.io] Archiving old Tianocore site, adding new site files (#1)
I've been able to prototype changes to the site in this fork of the repo:
https://github.com/jljusten/tianocore
and preview at this url http://jljusten.github.io/tianocore
Maybe this will help to show demonstrate the new site?
Also, can't we migrate the new proposed layout in place and preserve as much as possible of the current site? (Rather than _ARCHIVED...)
—
Reply to this email directly or view it on GitHubhttps://github.com/tianocore/tianocore.github.io/pull/1#issuecomment-117300196.

Hi Jordan
Please let me know what questions you have and I can hopefully answer. I have added Laurie Jarlstrom and Steve Howard to this reply as they are our Intel contacts for the site rebuild.
Thanks
Travis Watkins
Production Director
thenewgroup
4540 SW Kelly Avenue
Portland, Oregon 97239
Office:<PHONE_NUMBER>
Direct:<PHONE_NUMBER>
www.thenewgroup.comhttp://www.thenewgroup.com/
From: Ryan O'Reilly
Sent: Tuesday, June 30, 2015 12:38 PM
To: tianocore/tianocore.github.io; Travis Watkins
Subject: Re: [tianocore.github.io] Archiving old Tianocore site, adding new site files (#1)
Hi Jordan,
I’m looping Travis into our discussion on the redesign/rebuild of Tianocore, if you have any questions/need clarifications on this project's requirements, it would be best to pass them directly to him. Thanks!
Ryan O'Reilly
Senior Web Developer
thenewgroup
4540 SW Kelly Avenue
Portland, Oregon 97239
Office:<PHONE_NUMBER>
Direct:<PHONE_NUMBER>
www.thenewgroup.comhttp://www.thenewgroup.com/

Hi Jordan,
Unfortunately, given the very short timeframe of this project, and making it responsive, a "teardown" was the only efficient method.
And to confirm, are you asking me to fork the tianocaore repo for you and merge my updates there to preview?
From: Jordan Justen <notifications<EMAIL_ADDRESS>Reply-To: "tianocore/tianocore.github.io" <reply<EMAIL_ADDRESS>Date: Tuesday, June 30, 2015 at 11:51 AM
To: "tianocore/tianocore.github.io" <tianocore.github.io<EMAIL_ADDRESS>Cc: Ryan O'Reilly <ryan.oreilly<EMAIL_ADDRESS>Subject: Re: [tianocore.github.io] Archiving old Tianocore site, adding new site files (#1)
I've been able to prototype changes to the site in this fork of the repo:
https://github.com/jljusten/tianocore
and preview at this url http://jljusten.github.io/tianocore
Maybe this will help to show demonstrate the new site?
Also, can't we migrate the new proposed layout in place and preserve as much as possible of the current site? (Rather than _ARCHIVED...)
—
Reply to this email directly or view it on GitHubhttps://github.com/tianocore/tianocore.github.io/pull/1#issuecomment-117300196.

Hi Jordan:
The tianocore.org facelift which TNG has been contracted to develop, has been authorized through all proper DMM channels and funded via the same.
I apologize for the fact that you have not been included in any of the planning and stakeholder meetings that have brought us to the point of going live with the new look and feel of tianocore.org (scheduled to have been live last Friday).
Your email is not very clear to my understanding. Are you suggesting TWO tianocore.org sites? (The “old” one and the “New” one?) The use of the word “fork” in terms of a web site seems to indicate to me that this is your intent.
The new tianocore.org look and feel (referenced as the “tianocore.org” facelift) has been modeled and reviewed using a “sandbox” server provided by TNG. All of the folks within PSI and EBP involved in the project have had opportunity to review and comment and make final decision to go live with what TNG has developed.
I have evangelized this facelift with the Intel customers and community members I work with (e.g. the IBVs). I am aware that there has been community discussion about it as well – taking us to this point, I believe.
I look forward to your response to help me better understand your positioning.
Thank you so much.
Best Regards,
Steven R. Howard  (Steve)
<EMAIL_ADDRESS>Intel SSG/STO/EBP
705 5th Ave S, Suite 500
Seattle, WA 98104
MS:UST1-4
(206) 701-8845 (Desk Direct)
(206) 434-0854 (Cell)
You have no choice but to operate in a world shaped by globalization and the information revolution. There are two options: adapt or die. - Andy Grove, 1995
The opinions herein expressed are personal in nature and do not necessarily reflect those of Intel. There is no explicit endorsement of said opinions either by Intel or any of Intel's official representatives.
From: Travis Watkins<EMAIL_ADDRESS>Sent: Tuesday, June 30, 2015 12:44 PM
To: Ryan O'Reilly; tianocore/tianocore.github.io
Cc: Jarlstrom, Laurie; Howard, Steven R
Subject: RE: [tianocore.github.io] Archiving old Tianocore site, adding new site files (#1)
Hi Jordan
Please let me know what questions you have and I can hopefully answer. I have added Laurie Jarlstrom and Steve Howard to this reply as they are our Intel contacts for the site rebuild.
Thanks
Travis Watkins
Production Director
thenewgroup
4540 SW Kelly Avenue
Portland, Oregon 97239
Office:<PHONE_NUMBER>
Direct:<PHONE_NUMBER>
www.thenewgroup.comhttp://www.thenewgroup.com/
From: Ryan O'Reilly
Sent: Tuesday, June 30, 2015 12:38 PM
To: tianocore/tianocore.github.io; Travis Watkins
Subject: Re: [tianocore.github.io] Archiving old Tianocore site, adding new site files (#1)
Hi Jordan,
I’m looping Travis into our discussion on the redesign/rebuild of Tianocore, if you have any questions/need clarifications on this project's requirements, it would be best to pass them directly to him. Thanks!
Ryan O'Reilly
Senior Web Developer
thenewgroup
4540 SW Kelly Avenue
Portland, Oregon 97239
Office:<PHONE_NUMBER>
Direct:<PHONE_NUMBER>
www.thenewgroup.comhttp://www.thenewgroup.com/

Hi Jordan,
Unfortunately, given the very short timeframe of this project, and making it responsive, a "teardown" was the only efficient method.
And to confirm, are you asking me to fork the tianocaore repo for you and merge my updates there to preview?
From: Jordan Justen <notifications<EMAIL_ADDRESS>Reply-To: "tianocore/tianocore.github.io" <reply<EMAIL_ADDRESS>Date: Tuesday, June 30, 2015 at 11:51 AM
To: "tianocore/tianocore.github.io" <tianocore.github.io<EMAIL_ADDRESS>Cc: Ryan O'Reilly <ryan.oreilly<EMAIL_ADDRESS>Subject: Re: [tianocore.github.io] Archiving old Tianocore site, adding new site files (#1)
I've been able to prototype changes to the site in this fork of the repo:
https://github.com/jljusten/tianocore
and preview at this url http://jljusten.github.io/tianocore
Maybe this will help to show demonstrate the new site?
Also, can't we migrate the new proposed layout in place and preserve as much as possible of the current site? (Rather than _ARCHIVED...)
—
Reply to this email directly or view it on GitHubhttps://github.com/tianocore/tianocore.github.io/pull/1#issuecomment-117300196.

After some manual integration the changes have mostly been merged. See http://www.tianocore.org. Thanks!


initial delivery of Flight Predictor workspace

Workspace which allows people to enter a departure and destination airport and then get info about their flight.. Needs to be used with an app which makes API requests to retrieve flight data

Maybe we should format the JSON first (not to be a single line file...).


[backport] Fix docstring of chainer.Sequential

Backport of #5438

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit 8d15dd0f01b3d344c00905dd2c9820ce03e0211d, target branch v5) succeeded!


504 Gateway Time-out excel export

Bug description
Excel export of any large component (with more than 20 000 sample vulnerabilities) returns after 50 seconds 504 Gateway Time-out error. Defectdojo is deployed via docker-compose with mysql as a container. Any suggestions on how to fix this issue? Is this configuration issue with nginx or something else? I have already tried to apply some configuration tips described on<EMAIL_ADDRESS>page, but the issue still exists.
After 50 seconds i have got redirected to web page with message:
504 Gateway Time-out
The server didn't respond in time.
Steps to reproduce
Steps to reproduce the behavior:

Go to components section
Choose Excel export option and wait (/reports/excel_export)

Expected behavior
Successful excel report creation.
Deployment method (select with an X)

[X ] Docker Compose
[ ] Kubernetes
[ ] GoDojo

Environment information

Operating System: Centos 8
DefectDojo version [2.7.1]

Logs
No important information in the docker-compose logs.

Issue related with haproxy configuration, not Defectdojo - sorry for misleading.


Remove limitations from the hs_regression_range_no_keyword script

This would autofix ~600 bugs. Should we do it?

Coverage decreased (-0.006%) to 27.257% when pulling 4fdaf30a35651fc53c743231c1f96dcfe33dc409 on marco-c:no_limit_has_reg_range_no_keyword into 04bd8db5812436a8a13f3749130fa57564381672 on mozilla:master.

Maybe you can limit in time the change

One month at a time?

I think we should do that slowly to avoid to overwhelm the mail boxes.

@marco-c I meant we should do changes only on recent bugs.

We are going to do this as part of the migration to the new 'Is Regression' field (https://bugzilla.mozilla.org/show_bug.cgi?id=1534280).


Simple CUDA-Lite example that worked on v1.0.0 hangs on v1.0.2

Hi, folks! I'm hoping you might be able to help me track down a problem that I've been beating my head against for a while.
I wrote this really simple CUDA-Lite program (consisting of a host.c and a device noop.c):
https://github.com/cucapra/hb-examples/tree/compat-v1.0.2/dummy
The essence of the problem is that this works fine on our Bladerunner v1.0.0 image (ami-0c6849749f4551621) but not on our v1.0.2 image (ami-09b8871cf40279e0f). The failure mode is a hang in hb_mc_device_tile_groups_execute—this call runs forever and never returns.
You'll see that the device code consists of a single line:
*val = 0;

Here, val is an int32_t pointer passed from the host, which uses hb_mc_device_malloc to allocate one word. Critically, if you comment out this one line, everything works fine and the kernel exits normally.
Other contingencies:

Yes, I'm resetting the FPGA before every run to work around #300.
I've dumped the eva_t that comes from the malloc call and it looks like a real address.

I'm at a loss to see what's going wrong here. Do any of you have a wild guess that might help?

Yeah, this seems like an issue. You've only run on F1?

Yes.

@bornaehsani @save-buffer Can one of pull @sampsyo's failing test into cosim?

Hi @sampsyo , terribly sorry for the late reply.
I've ported this test to the bsg_f1 and bsg_manycore repository. Unfortunately I haven't been able to reproduce the bug, it doesn't occur for me.
If you checkout to the "cuda_dram_tests" branch on both bsg_f1 and bsg_manycore repositories, I have added three tests in regards to this issue:
- test_dram_host_allocated: Similar to your test, the host allocates a word on DRAM and passes the address as input argument, the tiles write a value to it and the host compares against the expected value. --> Test passes F1 on both v1.0.0 and v1.0.2
- test_dram_device_allocated: I took this a bit further and added a similar test, in which the tiles allocate an array in DRAM and each tiles fills a portion of it. The origin tile then writes the address of the array, in another location who's address has been passed to tile's kernel as input argument. The host then copies the array from device DRAM into host dram and checks the values. --> Test passes F1 on both v1.0.0 and v1.0.2
- test_noop: As I wasn't able to reproduce the bug, I copied the exact text in your code in this test to make sure I'm not doing anything differently than your code. This test is similar to test_dram_host_allcoated in functionality. --> Test passes both F1 and COSIM on both v1.0.0 and v1.0.2
I'm not exactly sure why the test is failing for you, but can you please give these tests a try and let me know if they pass for you on F1? (if they don't perhaps we're doing something differently in setting up the environments )

Weird!! Thanks so much for following up (and no worries). I’ll try the tests out soon, after I’m home from ISCA.

Sure no problem, enjoy the conference!
By the way, the biggest change from v1.0.0 to v1.0.2 was the linker script in the bsg_manycore repo, I didn't see any custom linker scripts in your repo so I assume you're using the ones in the bsg_manycore repo, but if that is not the case you might want to make sure your linker scripts match the ones in the v1.0.2 bsg_manycore/software/spmd/common/ directory.

@sampsyo Do you know if this is fixed in v3.0.6?

The refactored DRAM regression tests are added to the master branch on bsg_f1 in PR #336. All tests pass in the v3.0.6. @sampsyo if the issue is solved in your local workspace we can go ahead and dismiss this issue. Let us know!

Thank you for looking into this, y'all! This does indeed seem to have gone away in v3.0.6. :tada:


Fix/dont raise internal exception

This PR bumps a version to v0.5.3.
Fixes #31 and #27.

Awesome, thanks a ton! 🎉


address question

I'm trying to withdraw an SPL token (KIN) to my Sollet wallet.  I've generated the address, and it says:
Token Address: kinXdEcpDQeHPEuQnqmUgtYykqKGVFq6CeVX5iAHJq6
But when I try and use this in FTX to two the withdrawal it tells me "invalid address".  How do I find the actual address of my SPL Token sub-wallet?

Click the Receive button in the token list item you're trying to withdraw to, i.e.,  your Kin receive address. For further assistance, please ask on Discord.

Ah. thank you and thank you

A link to the discord in the README would be useful


refactor withPeerSelectionAction argument list

Description

description of the pull request, if it fixes a particular issue it should link the PR to a particular issue, see ref
Checklist

Branch

[ ] Updated changelog files.
[ ] Commit sequence broadly makes sense
[ ] Commits have useful messages
[ ] The documentation has been properly updated
[ ] New tests are added if needed and existing tests are updated
[ ] If serialization changes, user-facing consequences (e.g. replay from genesis) are confirmed to be intentional.

Pull Request

[ ] Self-reviewed the diff
[ ] Useful pull request description at least containing the following information:

What does this PR change?
Why these changes were needed?
How does this affect downstream repositories and/or end-users?
Which ticket does this PR close (if any)? If it does, is it linked?

[ ] Reviewer requested

issue #4745

^ if there's an issue, it's enough to attach it in the Development section on the right, no need to add it to the project.


"cmake --build ." fail: error: ambiguous template

C++ compiler version: cmake version 3.19.8
Hazelcast Cpp client version: hazelcast-cpp-client-4.0.1
Hazelcast server version: no
Number of the clients: no
Cluster size, i.e. the number of Hazelcast cluster members: no
OS version (Windows/Linux/OSX):
Linux
Please attach relevant logs and files for client and server side.
client:
!362 # cmake --build  . --target install
[  5%] Building CXX object CMakeFiles/hazelcast-cpp-client.dir/hazelcast/generated-sources/src/hazelcast/client/protocol/codec/codecs.cpp.o
In file included from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/address.h:20:0,
                 from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/member.h:22,
                 from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/generated-sources/src/hazelcast/client/protocol/codec/codecs.cpp:18:
/tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/serialization/serialization.h:93:17: warning: type attributes ignored after type is already defined [-Wattributes]
                 };
                 ^
In file included from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/address.h:20:0,
                 from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/member.h:22,
                 from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/generated-sources/src/hazelcast/client/protocol/codec/codecs.cpp:18:
/tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/serialization/serialization.h:776:32: error: ambiguous template specialization ‘write_object<>’ for ‘void hazelcast::client::serialization::object_data_output::write_object(const char*)’
             void HAZELCAST_API object_data_output::write_object(const char *object);
                                ^
/tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/serialization/serialization.h:719:22: note: candidates are: template<class T> void hazelcast::client::serialization::object_data_output::write_object(const T*)
                 void write_object(const T *object);
                      ^
/tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/serialization/serialization.h:753:24: note:                 template<class T> typename std::enable_if<(!((((std::is_base_of<hazelcast::client::serialization::builtin_serializer, hazelcast::client::serialization::hz_serializer<T> >::value || std::is_base_of<hazelcast::client::serialization::identified_data_serializer, hazelcast::client::serialization::hz_serializer<T> >::value) || std::is_base_of<hazelcast::client::serialization::portable_serializer, hazelcast::client::serialization::hz_serializer<T> >::value) || std::is_base_of<hazelcast::client::serialization::custom_serializer, hazelcast::client::serialization::hz_serializer<T> >::value) || (std::is_array< <template-parameter-1-1> >::value && std::is_same<typename std::remove_all_extents< <template-parameter-1-1> >::type, char>::value))), void>::type hazelcast::client::serialization::object_data_output::write_object(T)
                 inline write_object(const T object);
                        ^
In file included from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/protocol/ClientMessage.h:36:0,
                 from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/generated-sources/src/hazelcast/client/protocol/codec/codecs.h:22,
                 from /tmp/hazelcast-cpp-client-4.0.1/hazelcast/generated-sources/src/hazelcast/client/protocol/codec/codecs.cpp:21:
/tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/query/paging_predicate.h:63:13: warning: type attributes ignored after type is already defined [-Wattributes]
             };
             ^
gmake[2]: *** [CMakeFiles/hazelcast-cpp-client.dir/hazelcast/generated-sources/src/hazelcast/client/protocol/codec/codecs.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/hazelcast-cpp-client.dir/all] Error 2
gmake: *** [all] Error 2

Expected behaviour
build pass
Actual behaviour
build error
Steps to reproduce the behaviour
mkdir build
cd build
cmake ..
cmake --build .

Hello @whoareu, can you provide the version of the C++ compiler on your system? If you can, please also add the output of the configuration command (the first call to cmake, cmake ..).

@yemreinci I think it is reproducible using docker build docker/hazelcast-fedora22-x86_64.dockerfile. It seems to happen on earlier gcc versions. I observed this in nightly test build logs http://jenkins.hazelcast.com/view/C++/job/cpp-fedora22-64-SHARED-Debug/  when i change for example enum struct HAZELCAST_API serialization_constants with enum HAZELCAST_API serialization_constants the problem disappears. Seems like a warning about using the struct or class keyword in enum definitions.
e.g. errors:
06:52:49 /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_VERSION=5 -DHAZELCAST_GIT_COMMIT_DATE="Fri Apr 30 18:34:35 2021 +0300" -DHAZELCAST_GIT_COMMIT_ID=763a61f -DHAZELCAST_VERSION=\"4.1.0\" -DHZ_BUILD_WITH_SSL -Dhazelcast_cpp_client_EXPORTS -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/generated-sources/src -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/build/include -m64 -Wall -g -fPIC -std=gnu++11 -o CMakeFiles/hazelcast-cpp-client.dir/hazelcast/src/hazelcast/client/client_impl.cpp.o -c /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/client_impl.cpp
06:52:51 In file included from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/address.h:20:0,
06:52:51                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/member.h:22,
06:52:51                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/entry_event.h:20,
06:52:51                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/proxy/IMapImpl.h:18,
06:52:51                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/imap.h:31,
06:52:51                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/map/NearCachedClientMapProxy.h:20,
06:52:51                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/impl/hazelcast_client_instance_impl.h:25,
06:52:51                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/hazelcast_client.h:20,
06:52:51                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/client_impl.cpp:41:
06:52:51 /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/serialization/serialization.h:93:17: warning: type attributes ignored after type is already defined [-Wattributes]
06:52:51                  };
06:52:51                  ^
06:52:52 In file included from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/proxy/IMapImpl.h:19:0,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/imap.h:31,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/map/NearCachedClientMapProxy.h:20,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/impl/hazelcast_client_instance_impl.h:25,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/hazelcast_client.h:20,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/client_impl.cpp:41:
06:52:52 /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/query/paging_predicate.h:63:13: warning: type attributes ignored after type is already defined [-Wattributes]
06:52:52              };
06:52:52              ^
06:52:52 In file included from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/eviction_config.h:22:0,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/near_cache_config.h:19,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/client_config.h:30,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/spi/impl/ClientClusterServiceImpl.h:26,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/impl/EntryEventHandler.h:24,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/imap.h:32,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/map/NearCachedClientMapProxy.h:20,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/impl/hazelcast_client_instance_impl.h:25,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/hazelcast_client.h:20,
06:52:52                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/client_impl.cpp:41:
06:52:52 /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/eviction_strategy_type.h:41:13: warning: type attributes ignored after type is already defined [-Wattributes]
06:52:52              };
06:52:52              ^
06:52:53 In file included from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/impl/ItemEventHandler.h:21:0,
06:52:53                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/proxy/IQueueImpl.h:22,
06:52:53                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/iqueue.h:19,
06:52:53                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/impl/hazelcast_client_instance_impl.h:32,
06:52:53                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/hazelcast_client.h:20,
06:52:53                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/client_impl.cpp:41:
06:52:53 /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/item_event.h:32:9: warning: type attributes ignored after type is already defined [-Wattributes]
06:52:53          };
06:52:53          ^
06:53:12 [ 15%] Building CXX object CMakeFiles/hazelcast-cpp-client.dir/hazelcast/src/hazelcast/client/cluster.cpp.o
06:53:12 /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_VERSION=5 -DHAZELCAST_GIT_COMMIT_DATE="Fri Apr 30 18:34:35 2021 +0300" -DHAZELCAST_GIT_COMMIT_ID=763a61f -DHAZELCAST_VERSION=\"4.1.0\" -DHZ_BUILD_WITH_SSL -Dhazelcast_cpp_client_EXPORTS -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/generated-sources/src -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/build/include -m64 -Wall -g -fPIC -std=gnu++11 -o CMakeFiles/hazelcast-cpp-client.dir/hazelcast/src/hazelcast/client/cluster.cpp.o -c /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/cluster.cpp
06:53:13 In file included from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/address.h:20:0,
06:53:13                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/member.h:22,
06:53:13                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/cluster.h:21,
06:53:13                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/cluster.cpp:36:
06:53:13 /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/serialization/serialization.h:93:17: warning: type attributes ignored after type is already defined [-Wattributes]
06:53:13                  };
06:53:13                  ^
06:53:14 In file included from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/eviction_config.h:22:0,
06:53:14                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/near_cache_config.h:19,
06:53:14                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/client_config.h:30,
06:53:14                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/spi/impl/ClientClusterServiceImpl.h:26,
06:53:14                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/cluster.cpp:37:
06:53:14 /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/eviction_strategy_type.h:41:13: warning: type attributes ignored after type is already defined [-Wattributes]
06:53:14              };
06:53:14              ^
06:53:16 [ 21%] Building CXX object CMakeFiles/hazelcast-cpp-client.dir/hazelcast/src/hazelcast/client/config.cpp.o
06:53:16 /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_VERSION=5 -DHAZELCAST_GIT_COMMIT_DATE="Fri Apr 30 18:34:35 2021 +0300" -DHAZELCAST_GIT_COMMIT_ID=763a61f -DHAZELCAST_VERSION=\"4.1.0\" -DHZ_BUILD_WITH_SSL -Dhazelcast_cpp_client_EXPORTS -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/generated-sources/src -I/home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/build/include -m64 -Wall -g -fPIC -std=gnu++11 -o CMakeFiles/hazelcast-cpp-client.dir/hazelcast/src/hazelcast/client/config.cpp.o -c /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/config.cpp
06:53:17 In file included from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/address.h:20:0,
06:53:17                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/client_config.h:24,
06:53:17                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/config.cpp:34:
06:53:17 /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/serialization/serialization.h:93:17: warning: type attributes ignored after type is already defined [-Wattributes]
06:53:17                  };
06:53:17                  ^
06:53:17 In file included from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/eviction_config.h:22:0,
06:53:17                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/near_cache_config.h:19,
06:53:17                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/client_config.h:30,
06:53:17                  from /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/src/hazelcast/client/config.cpp:34:
06:53:17 /home/jenkins/jenkins_slave/workspace/cpp-fedora22-64-SHARED-Debug/hazelcast/include/hazelcast/client/config/eviction_strategy_type.h:41:13: warning: type attributes ignored after type is already defined [-Wattributes]
06:53:17              };

It was false warning above, the error was actually this line which is different from our nightly build warnings:
/tmp/hazelcast-cpp-client-4.0.1/hazelcast/include/hazelcast/client/serialization/serialization.h:776:32: error: ambiguous template specialization ‘write_object<>’ for ‘void hazelcast::client::serialization::object_data_output::write_object(const char*)’
             void HAZELCAST_API object_data_output::write_object(const char *object);

We still need to know what is the compiler version this occurs and the cmake configurat'on command logs as @yemreinci requested above.

@whoareu did you see the above question regarding the compiler version?

@whoareu, I am closing this as we couldn't reproduce this.
Please reopen with your compiler version information if you are still experiencing this issue.


some plugin usability points

🐛 Bug
i have a couple feedback points on the plugins that i've noted from my work on #1104 but are more general that plugin writers.

[ ] I love the plugin errors dialog, but it would also be nice to see errors directly in the console when calling code in the console. We can wait till #1090 for that, but wanted to note it here too. There were a few times when I'd run the save_layers, and things would fail, but i wouldn't realize until going to the error dialog.

[ ] I have a hard time reading the blue text in the error messages in the plugin dialog.

[ ] The plugin sorter should be a singleton - right now I can add multiple copies of it

There is no Plugin Sorter any more and error message formatting is much improved by https://github.com/napari/napari/pull/4414
I'm going to close this as out-dated.


Autosave supports

Unload when triggered autosave

Hi @SeibelStan,
Can you be more explicit for the new feature you want ?
Thank you for using my package.


Render all picking buffers in one pass

Improve perf by calling gl.readPixels() only once
Breaking: occluded objects can no longer be picked even if on a separate layer.
Breaking: onHover and onClick callbacks are invoked by layer.pick(). This allows layers to block an event if necessary. Layers that override the default pick() method must now call super.pick() after augmenting the info object, or call the callback functions themselves.

@ibgreen @shaojingli I incorporated your feedbacks in the latest commit.
Need review: using LayerManager.context to remember the last picked color. This allows us to only invoke mouse events on layers that are affected. As a result:

onHover is only called on enter/leave events.
onClick is only called on the picked layer.
GeoJSONLayer can just pass onHover and onClick props down to sublayers and no longer has to maintain an internal state.

Need review: using LayerManager.context to remember the last picked color. This allows us to only invoke mouse events on layers that are affected.

@Pessimistress Sounds like a great idea, however would it be possible to do this as a separate PR? It is a bit hard to review as an add-on to this PR.  I think there might be some complications here (e.g. what if the layer data, or list of layers, change between picks etc...)

Need review: using LayerManager.context to remember the last picked color. This allows us to only invoke mouse events on layers that are affected.

I think that this is the correct place to put it.
a quick question:

GeoJSONLayer can just pass onHover and onClick props down to sublayers and no longer has to maintain an internal stat

is GeoJSONLayer able to add more info to the picking info object in this model?

@ibgreen @shaojingli I'm going to land the approved changes and open a new PR.


Preferences

I am unable t open the preferences. ive tried right clicking and control + right click but nothing happens.

hi, which version of SpotMenu are you using?
Could you please try a previous version and see if it works (e.g 1.6)
All releases

I originally tried it on 1.7. I just downloaded 1.6 and im experiencing the same issue unfortunately.

@kmikiy @lumberjack76 I am facing a similar issue. I am on 1.7 (I downloaded the latest today) and Sierra 10.12.5. Everytime I click on Preferences, the application closes. Right clicking on the bar and then doing Command+, (as opposed to clicking) achieves the same output.

im having the exact same issue. dont know for how long, just saw this happening today

Could one of you follow the steps from how to build and show me what it writes to the console and where the app stops in the code when the app crashes?

I am having a similar issue in 1.7 (and all other installed versions) where Control clicking the Spotify Icon in the Menu Bar or pressing "CMD+," does not open preferences. No crashes, freezing, or app closing, just nothing happens.
OS X 10.12.6, Spotify <IP_ADDRESS>6.g7edcc575
I have deleted 1.7 from the computer and installed 1.6. The same issue still occurs.

I had the same issue. Usually I leave the right click on magic mouse disabled. So, I couldn't access "preferences" using control+click. I had to enable right click in Mac OS System Preferences and them it worked, I right-clicked the app at the menu bar and could see the preferences menu.


About GPS Accuracy on Live MAP

I've successfully run this program with ESP32 and Ili9341 3.2 TFT LCD with Ublox-M8N GPS module.
However I have a problem with the result showing in Live Map (ARROW point), it doesn't look like what I see with the web based map even though it's the same longitude and latitude.
when viewed in Live View from Tile X and Y it does give the correct image but gives the wrong ARROW point.
is there any configuration to be able to adjust it?
may provide an offset configuration or other to match the actual situation.
Thanks very much.

@AhmadPanogari
The program uses the GCJ-02 coordinate system by default, and you need to switch to the WGS-84  coordinate system in your country.
Modification method:
Modify the X-Track/USER/App/Config/Config.h file in
#define CONFIG_MAP_USE_WGS84_DEFAULT true
or
Modify the SystemSave.json file in the SD card
"sysConfig.mapWGS84": 1

I've changed those settings and now it's accurate.
Thank you, sorry for the late response


resource: Add Resource[Endpoints] and adapt existing watchers

Adds Resource[*Endpoints] which moves the resolving of the Endpoint or EndpointSlice into the constructor for the resource. K8sWatcher refactored to use the Resource[*Endpoints] and code cleaned up to work with just *Endpoints rather than the 3 different kinds. Some messiness around collapsing them into one type and hiding the underlying resource kind. Please review those changes carefully (CachesSynced, metrics in endpoints watcher, ipcache.ResourceKindEndpoint). I've tried to keep existing behavior as much as I could, but could've potentially missed something.
See individual commits and #23734 for motivation.

/test

Looks really nice!

I am not a good reviewer for this PR. Removing myself.

/test

/test

/test

/test-1.26-net-next

/test

Oh, it conflicts again

/test

test-1.16-4.19 likely hitting https://github.com/cilium/cilium/issues/25524? Since test on 1.16 is important (to check that Endpoint object handling works) I'll rerun the test.
error: unable to upgrade connection: Authorization error (user=kube-apiserver-kubelet-client, verb=create, resource=nodes, subresource=proxy)

/test-1.16-4.19


[Feature Request]: Replace cfg_if macros with someting else

Describe the feature
Rookie is designed for macOS, Windows, and Linux, and currently heavily uses cfg_if, making the code less readable.

https://github.com/thewh1teagle/rookie/pull/31


Can't run iOS Simulator debug mode on a M1 MBP due to dylib

First of all: amazing project! Everything works as expected, only one thing bugging me right now.
I can't seem to build my app for the iOS Simulator on an M1 Max MBP.
[Xcode error 'building for iOS Simulator, but linking in dylib built for iOS .. for architecture arm64']
Launching XCode using Rosetta and then building using X86 works fine, but the performance using the X86 simulator is pretty bad compared to arm64. Also build times are like 3-6x times longer. Building the app using arm64 for an iPhone works as expected.
Any solution?

same problem

I found out it's due to the prebuilt NodeMobile lib being compiled for x86 only, would be cool to get built instructions + instructions on how to include the arm64 lib into the package when it's built.
Building https://github.com/nodejs-mobile/nodejs-mobile using the M1 should work.

No idea, I have given up on this library, wait a year and then come back to see how this library develops

solve as I have mention at https://github.com/nodejs-mobile/nodejs-mobile-react-native/issues/10#issuecomment-1728708885

I can run nmrn apps on iOS Simulator as of version 18.17.4.
When describing a bug, please always specify which versions are pertinent.


fix(link): fix workitemlinktypes URL

[ ] What does this PR do? [Mandatory]
Note: If you are still working on the changes, prefix the PR title with "WIP" and add the label "DO NOT MERGE"

After space template PR comes in we are getting 404 for workitemlinktypes API.
[ ] What issue/task does this PR references? [Mandatory]

NA
[ ] Are the tests Included? [Mandatory]

Test is in this PR https://github.com/fabric8-ui/fabric8-planner/pull/2563

Ike Plugins (test-keeper)
Thank you @vikram-raj for this contribution!

It appears that no tests have been added or updated in this PR.
Automated tests give us confidence in shipping reliable software. Please add some as part of this change.
If you are an admin or the reviewer of this PR and you are sure that no test is needed then you can use the command /ok-without-tests as a comment to make the status green.
For more information please head over to official documentation. You can find there how to configure the plugin - for example exclude certain file types so if PR contains only them it won't be checked.

@vikram-raj Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2574 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2574 and visit http://localhost:5000 to access it.


German parser

This adds functionality to deal with non-projective dependency structures.
It implements the pseudo-projective parsing idea from Nivre & Nilsson 2005.
This enables the parser to be trained on non-projective treebanks.

Geil :)


Roll Flutter Engine from 2be41c6d0152 to 4d2a94959e5c (8 revisions)

https://github.com/flutter/engine/compare/2be41c6d0152...4d2a94959e5c
2023-03-03<EMAIL_ADDRESS>Roll Skia from d953c63dd96b to 04e32a9e5641 (2 revisions) (flutter/engine#40038)
2023-03-03<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from oGC2UFWpzRXTrEiJg... to 4BjO0CPYCTfpHYDyO... (flutter/engine#40037)
2023-03-03<EMAIL_ADDRESS>Roll Dart SDK from a32e24068a6c to b1016d8f293a (2 revisions) (flutter/engine#40036)
2023-03-03<EMAIL_ADDRESS>[macOS] Add README.md for macOS embedder (flutter/engine#40032)
2023-03-03<EMAIL_ADDRESS>Do not end the frame in the raster cache if ScopedFrame::Raster returns kResubmit (flutter/engine#40007)
2023-03-03<EMAIL_ADDRESS>[Embedder API] Freeze parts of API for ABI stability (flutter/engine#39963)
2023-03-03<EMAIL_ADDRESS>Roll Skia from a0ab1e734490 to d953c63dd96b (9 revisions) (flutter/engine#40035)
2023-03-02<EMAIL_ADDRESS>Remove PlatformConfiguration and ViewConfiguration (flutter/engine#40012)
Also rolling transitive DEPS:
fuchsia/sdk/core/mac-amd64 from oGC2UFWpzRXT to 4BjO0CPYCTfp
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jsimmons@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.