Unable to capture local sites with /etc/hosts

Hello,
First let me say thank you for this project, I really enjoy it.
I have the project working when I use 2 public/ internet accessiable sites.  I am now trying to get things in order so our devs can run the tests against their local machines (and compare with production) before pushing.
We do this with urls such as www.REDACTED.ifdev, which work both on the CLI and via browser.
In /etc/hosts we have
<IP_ADDRESS> www.REDACTED.ifdev

When I try to run wraith against this, I believe maybe the ruby layer is not translating or using /etc/hosts to determine the location.  I get the errors below, and all the images for the local enviroment just say "Invalid Image".  The production (beta.REDACTED.org) url shows the images just fine.
I am using a mac, 10.11, if that matters.
Reporting a problem? Please describe the issue above, and complete the following checklist so that we can help you more quickly.
Issue checklist:

[X] I have validated my config file against YAML Validator to make sure it is valid YAML.

[X] I have run the wraith info command and pasted the output below:

DEBUG: #################################################
DEBUG:   Command run:        info
DEBUG:   Wraith version:     4.2.1
DEBUG:   Ruby version:       ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin15]
DEBUG:   ImageMagick:        Version: ImageMagick 6.9.5-5 Q16 x86_64 2016-08-07 http://www.imagemagick.org
DEBUG:   PhantomJS version:  2.1.1
DEBUG:   chromedriver version:  ChromeDriver 2.33.506106 (8a06c39c4582fbfbab6966dbb1c38a9173bfb1a2)
DEBUG:   CasperJS version:   CasperJS not installed
DEBUG: #################################################

[X] I have run the command in verbose mode (by adding verbose: true to my config) and pasted the output below:

wraith capture configs/capture.yaml
DEBUG: #################################################
DEBUG:   Command run:        capture configs/capture.yaml
DEBUG:   Wraith version:     4.2.1
DEBUG:   Ruby version:       ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin15]
DEBUG:   ImageMagick:        Version: ImageMagick 6.9.5-5 Q16 x86_64 2016-08-07 http://www.imagemagick.org
DEBUG:   PhantomJS version:  2.1.1
DEBUG:   chromedriver version:  ChromeDriver 2.33.506106 (8a06c39c4582fbfbab6966dbb1c38a9173bfb1a2)
DEBUG:   CasperJS version:   CasperJS not installed
DEBUG: #################################################
Config validated. No serious issues found.
Creating Folders
SAVING IMAGES
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://www.REDACTED.ifdev/' '320' 'shots/home/320_phantomjs_local.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://beta.REDACTED.org/' '320' 'shots/home/320_phantomjs_prd.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://www.REDACTED.ifdev/' '600x768' 'shots/home/600x768_phantomjs_local.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://beta.REDACTED.org/' '600x768' 'shots/home/600x768_phantomjs_prd.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://www.REDACTED.ifdev/' '768' 'shots/home/768_phantomjs_local.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://beta.REDACTED.org/' '768' 'shots/home/768_phantomjs_prd.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://www.REDACTED.ifdev/' '1024' 'shots/home/1024_phantomjs_local.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://beta.REDACTED.org/' '1024' 'shots/home/1024_phantomjs_prd.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
Loading https://beta.REDACTED.org/ at dimensions: 768x1500

Loading https://beta.REDACTED.org/ at dimensions: 320x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 600x768

Loading https://beta.REDACTED.org/ at dimensions: 1024x1500

Loading https://beta.REDACTED.org/ at dimensions: 600x768

Loading https://www.REDACTED.ifdev/ at dimensions: 1024x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 768x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 320x1500

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/768_phantomjs_local.png on attempt number 1 of 5
WARN: Failed to capture image shots/home/1024_phantomjs_local.png on attempt number 1 of 5
WARN: Failed to capture image shots/home/320_phantomjs_local.png on attempt number 1 of 5
WARN: Failed to capture image shots/home/600x768_phantomjs_local.png on attempt number 1 of 5
Loading https://www.REDACTED.ifdev/ at dimensions: 320x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 768x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 1024x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 600x768

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/768_phantomjs_local.png on attempt number 2 of 5
WARN: Failed to capture image shots/home/320_phantomjs_local.png on attempt number 2 of 5
WARN: Failed to capture image shots/home/600x768_phantomjs_local.png on attempt number 2 of 5
WARN: Failed to capture image shots/home/1024_phantomjs_local.png on attempt number 2 of 5
Loading https://www.REDACTED.ifdev/ at dimensions: 320x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 600x768

Loading https://www.REDACTED.ifdev/ at dimensions: 1024x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 768x1500

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/320_phantomjs_local.png on attempt number 3 of 5
WARN: Failed to capture image shots/home/1024_phantomjs_local.png on attempt number 3 of 5
WARN: Failed to capture image shots/home/600x768_phantomjs_local.png on attempt number 3 of 5
WARN: Failed to capture image shots/home/768_phantomjs_local.png on attempt number 3 of 5
Loading https://www.REDACTED.ifdev/ at dimensions: 320x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 1024x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 600x768

Loading https://www.REDACTED.ifdev/ at dimensions: 768x1500

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/320_phantomjs_local.png on attempt number 4 of 5
WARN: Failed to capture image shots/home/600x768_phantomjs_local.png on attempt number 4 of 5
WARN: Failed to capture image shots/home/1024_phantomjs_local.png on attempt number 4 of 5
WARN: Failed to capture image shots/home/768_phantomjs_local.png on attempt number 4 of 5
Loading https://www.REDACTED.ifdev/ at dimensions: 600x768

Loading https://www.REDACTED.ifdev/ at dimensions: 768x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 1024x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 320x1500

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/1024_phantomjs_local.png on attempt number 5 of 5
ERROR: Unable to capture image shots/home/1024_phantomjs_local.png after 5 attempt(s)
WARN: Using fallback image instead
WARN: Failed to capture image shots/home/320_phantomjs_local.png on attempt number 5 of 5
ERROR: Unable to capture image shots/home/320_phantomjs_local.png after 5 attempt(s)
WARN: Using fallback image instead
WARN: Failed to capture image shots/home/768_phantomjs_local.png on attempt number 5 of 5
ERROR: Unable to capture image shots/home/768_phantomjs_local.png after 5 attempt(s)
WARN: Using fallback image instead
WARN: Failed to capture image shots/home/600x768_phantomjs_local.png on attempt number 5 of 5
ERROR: Unable to capture image shots/home/600x768_phantomjs_local.png after 5 attempt(s)
WARN: Using fallback image instead
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://www.REDACTED.ifdev/' '1280' 'shots/home/1280_phantomjs_local.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
DEBUG: phantomjs  '/usr/local/lib/ruby/gems/2.3.0/gems/wraith-4.2.1/lib/wraith/javascript/phantom.js' 'https://beta.REDACTED.org/' '1280' 'shots/home/1280_phantomjs_prd.png' 'body' '/private/tmp/wraith59994/javascript/disable_javascript--phantom.js' 'false'
Loading https://beta.REDACTED.org/ at dimensions: 1280x1500

Loading https://www.REDACTED.ifdev/ at dimensions: 1280x1500

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/1280_phantomjs_local.png on attempt number 1 of 5
Loading https://www.REDACTED.ifdev/ at dimensions: 1280x1500

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/1280_phantomjs_local.png on attempt number 2 of 5
Loading https://www.REDACTED.ifdev/ at dimensions: 1280x1500

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/1280_phantomjs_local.png on attempt number 3 of 5
Loading https://www.REDACTED.ifdev/ at dimensions: 1280x1500

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/1280_phantomjs_local.png on attempt number 4 of 5
Loading https://www.REDACTED.ifdev/ at dimensions: 1280x1500

Error with page https://www.REDACTED.ifdev/

WARN: Failed to capture image shots/home/1280_phantomjs_local.png on attempt number 5 of 5
ERROR: Unable to capture image shots/home/1280_phantomjs_local.png after 5 attempt(s)
WARN: Using fallback image instead
Snapping https://beta.REDACTED.org/ at: 1024x1500

Snapping https://beta.REDACTED.org/ at: 600x768

Snapping https://beta.REDACTED.org/ at: 320x1500

Snapping https://beta.REDACTED.org/ at: 1280x1500

Snapping https://beta.REDACTED.org/ at: 768x1500

CROPPING IMAGES
DEBUG: Cropping both images to 768x1500. (shots/home/768_phantomjs_local.png, shots/home/768_phantomjs_prd.png)
DEBUG: Cropping both images to 320x1500. (shots/home/320_phantomjs_local.png, shots/home/320_phantomjs_prd.png)
DEBUG: Both images are exactly 600x768 - no cropping required. (shots/home/600x768_phantomjs_local.png, shots/home/600x768_phantomjs_prd.png)
DEBUG: Cropping both images to 1280x1500. (shots/home/1280_phantomjs_local.png, shots/home/1280_phantomjs_prd.png)
DEBUG: Cropping both images to 1024x1500. (shots/home/1024_phantomjs_local.png, shots/home/1024_phantomjs_prd.png)
COMPARING IMAGES
Comparing shots/home/1024_phantomjs_local.png and shots/home/1024_phantomjs_prd.png
Comparing shots/home/320_phantomjs_local.png and shots/home/320_phantomjs_prd.png
Comparing shots/home/1280_phantomjs_local.png and shots/home/1280_phantomjs_prd.png
Comparing shots/home/768_phantomjs_local.png and shots/home/768_phantomjs_prd.png
Comparing shots/home/600x768_phantomjs_local.png and shots/home/600x768_phantomjs_prd.png
Saved diff
Saved diff
Saved diff
Saved diff
Saved diff
GENERATING THUMBNAILS
GENERATING GALLERY
Gallery generated
WARN: Failures detected:
WARN:      home failed at a resolution of 320 (85.48% diff)
WARN:      home failed at a resolution of 600 (76.74% diff)
WARN:      home failed at a resolution of 768 (90.44% diff)
WARN:      home failed at a resolution of 1024 (92.99% diff)
WARN:      home failed at a resolution of 1280 (94.37% diff)

View the gallery in your browser:
     file:///private/tmp/wraith59994/shots/gallery.html

[X] I have pasted the contents of my config file below:

##############################################################
##############################################################
# This is an example configuration provided by Wraith.
# Feel free to amend for your own requirements.
# ---
# This particular config is intended to demonstrate how
# to use Wraith in 'capture' mode, which is best suited to
# comparing a test and live version of the same website.
#
# `wraith capture capture.yaml`
#
##############################################################
##############################################################

# (required) The engine to run Wraith with. Examples: 'phantomjs', 'casperjs', 'slimerjs'
browser: "phantomjs"

# (required) The domains to take screenshots of.
domains:
  local: https://www.REDACTED.ifdev
  prd: https://beta.REDACTED.org

# (required) The paths to capture. All paths should exist for both of the domains specified above.
paths:
  home:     /

# (required) Screen widths (and optional height) to resize the browser to before taking the screenshot.
screen_widths:
  - 320
  - 600x768
  - 768
  - 1024
  - 1280

# (optional) JavaScript file to execute before taking screenshot of every path. Default: nil
before_capture: 'javascript/disable_javascript--phantom.js'

# (required) The directory that your screenshots will be stored in
directory: 'shots'

# (required) Amount of fuzz ImageMagick will use when comparing images. A higher fuzz makes the comparison less strict.
fuzz: '20%'

# (optional) The maximum acceptable level of difference (in %) between two images before Wraith reports a failure. Default: 0
threshold: 5

# (optional) Specify the template (and generated thumbnail sizes) for the gallery output.
gallery:
  template: 'slideshow_template' # Examples: 'basic_template' (default), 'slideshow_template'
  thumb_width:  200
  thumb_height: 200

# (optional) Choose which results are displayed in the gallery, and in what order. Default: alphanumeric
# Options:
#   alphanumeric - all paths (with or without a difference) are shown, sorted by path
#   diffs_first - all paths (with or without a difference) are shown, sorted by difference size (largest first)
#   diffs_only - only paths with a difference are shown, sorted by difference size (largest first)
# Note: different screen widths are always grouped together.
mode: diffs_first

verbose: true

Just want to chime in and say that I am on a Mac 10.12.6 and am also using /etc/hosts to define some domain <IP_ADDRESS> local.www.REDACTED.com and the screenshots work fine.
I am using 'chrome' as my browser here instead of phantom, but I don't know if that will make a difference.


[Publisher] Issue regarding the alignment of subscriptions, while creating an API

The alignment of the subscription drop down is not in alphabetical order, while creating an API.

Duplicate https://github.com/wso2/product-apim/issues/5838


SR 716: handle constant structs with padding

Handle padding in global structs.
Previously there was a mismatch between SIL's concept of a
struct (padding is implicit) and LLVM's (padding is explicit) in IRGen's
constant evaluator. The explicit padding fields need to be given a value
in the IR.

Resolves SR-716.

@swift-ci Please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 5aa6d8bc6b0d10dae9146cf37e900a09cc40abe3
Test requested by - @huonw

@huonw I noticed that @rjmccall made some comments about formatting. You should check out git-clang-format. It solves these issues really nicely. I can show you how to set it up on Monday if you want.

@swift-ci please test
I've updated the pull request, which should address the review. It restructures things in the vein of @rjmccall's suggestion of doing two passes over an array of llvm::Constant *, although the only way to get the stored properties that I can see result in some weirdness with the closure in emitConstantStruct.
It is also git-clang-format clean, so the formatting should be good now. (Thanks @gottesmm for pointing me to that script, I think I've got it setup in an appropriate way.)

@swift-ci please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 5aa6d8bc6b0d10dae9146cf37e900a09cc40abe3
Test requested by - @huonw

@huonw This looks great! One request from me would be to add an IRGen FileCheck test.

I... don't know what that test failure means. It doesn't seem to be in any code I touched, and running the validation tests locally (-T, right?) passes fine.

@swift-ci Please test
I added a IRGen test (test/IRGen/constant_struct_with_padding.sil), tell me if it looks reasonable please, @slavapestov.

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test.
Updated.

@swift-ci Please test.
Updated.

@swift-ci Please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 9246b1ead46eb071b1cb91754f776ecca66d9185
Test requested by - @huonw

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 9246b1ead46eb071b1cb91754f776ecca66d9185
Test requested by - @huonw

@swift-ci Please test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 642117b5511276c2da8ea64e36bac8ed30ff9572
Test requested by - @huonw

@swift-ci Please test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 642117b5511276c2da8ea64e36bac8ed30ff9572
Test requested by - @huonw

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 642117b5511276c2da8ea64e36bac8ed30ff9572
Test requested by - @huonw

@moiseev, @phausler, know what's up with the macOS failure? Why would we lose the length property all of a sudden?
12:35:14 2016-10-03 12:34:08.112 swift[56714:13650955] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -length only defined for abstract class.  Define -[_TtCs19_NSContiguousString length]!'

@jrose-apple That failure does not make any sense to me. I verified that @objc for a property will be properly generated for an abstract object being passed. So something else must be at play here. I guess I can move it back into the standard lib instead of the overlay (but that seems sub-par)

Ah, you did land that change. I thought that hadn't happened yet. In that case the problem is that SwiftPM doesn't depend on Foundation, so the overlay is never loaded.

*sigh* I was thinking it made sense to move the fast-path operations, not length itself, but of course the fast-path operations are still useful even without the overlay. My bad.

I would have preferred for the string bridge to live in Foundation entirely. Perhaps we should consider making it only operate when Foundation is imported. That would be a breaking change but I think it would be highly desirable to not get spooky behavior differentials like this failure.
IMHO swiftpm should be importing Foundation if it is relying on the bridge.

(taking this to swift-dev to stop bothering @huonw)

Hang on, this really shouldn't be related to #5071 because that hasn't landed yet.

@jrose-apple are we getting build cruft interceding between builds somehow?

I sure hope not. I see a lot of "reset --hard" and "clean -f" in that build log. But even then I agree with you: the change to a property shouldn't make any difference.

@swift-ci Please test


Service for manipulating Custom MongoDB Roles

I created a new service for operating the API for Custom MongoDB Roles. This is in preparation for adding a new resource for roles to the Terraform MongoDB Atlas provider.
Tried to follow the conventions of the rest of the code. Thinks I wasn't sure about:

whether I should enumerate somewhere the possible Custom Role Actions, but I figured these might change with time and perhaps are better left as plain strings.
whether I should also test paging parameters, because the response structure for the Custom MongoDB Roles list is different from the other APIs -- does not have Links, Results nor TotalCount.

I can, of course, add both of the above, if so requested.

cc @themantissa

@mpaluchowski  thank you so much for your submission!  We are working on our internal process/procedure so it may take a little time but I'll keep you updated.   Please feel free to reach out to me directly<EMAIL_ADDRESS>or here with any questions.

Wanted to provide an update: we apologize for the delay but hope to have engineering resources for the review soon.  Again feel free to reach out to me directly<EMAIL_ADDRESS>or here with any questions in the mean time.

Melissa, I appreciate your updates, but have to say I find the situation discouraging. Since I submitted the pull request (to which I was openly encouraged by your colleagues), there have been a number of commits made to this repository, as well as to the Terraform provider (including the 0.3.1 release). This means that clearly you have people working on the code, who would be capable of reviewing my submission. It's a matter of priorities, not of "having engineering resources".

Hi @mpaluchowski,  I can very much see how that would look to be the case but it really is a case of not having the resources for this particular area.   I'll share all I can so that you can see why there is activity and will hopefully understand that we very much appreciate your contribution and are working diligently to have the resources to give it the full attention it deserves.
As was noted in the original blog announcing our work on plugins for the HashiCorp provider (https://www.mongodb.com/blog/post/terraform-and-vault-are-coming-to-mongodb-atlas) we contracted with an outside, expert company in this development work. What that means is that everything being done was already agreed to contractually.  The work you've seen in the Terraform repo falls under bug fixes or misses in the original scope that the company is under contract to correct.   No features will be added till we get our next set of work started.
It is similar with Vault, the work being done in that repo is  in response to work we are doing with HashiCorp to get the work reviewed, corrected if needed, and approved/verified by them per our contract with the developers.  Anything else being approved there are doc updates, which are something I can knock out.
This means we do not have any engineering hours scheduled or contracted for PR reviews (or new features) at this time.  Quite honestly I'm thrilled to have a pretty extensive PR so soon!   It just happened to be sooner than the work to get a process and scheduled time to have our experts review it was done.   I'm pushing things as quickly as I can and can tell you that your work is at the top of the list.
I truly hope this transparency helps.  Thank you for giving me a chance to provide it.

@themantissa Thank you. I appreciate the candid update.

@mpaluchowski Wanted to get an update to you as we've moved forward.  We are about to start on a new round of work and it will start with the review of your PR.  It will begin in the first week of December.   Then we should move along much more quickly.  Thank you!

LGTM! Thank you so much! 👍

@mpaluchowski Please do let us know if you plan to submit a PR for the Terraform work so I can get it scheduled for review as quickly as possible when it comes in.

@themantissa I would like to submit it. I was just wondering whether you're planning to release a fixed version of this Go client first, so that I can build the Terraform code against it, or should I be building against a Git revision -- temporarily, at least?

Let me check with the team and see where we are - we should be at a point, or very close to, a good place for a new release.   Stand by!

Actually... I just noticed that the Terraform provider is now linked to the latest master revision of the Go client, which is enough for me to work on. I can go ahead and build the Terraform resource.


Fork Ethermint JSON-RPC server and make it include non-Ethereum tx that calls EVM

Currently Ethereum txs (initiated & signed by an EOA: e.g. metamask tx on zEVM) are processed by the Ethermint module and the ethermint RPC infrastructure indexes and provides Ethereum JSON-RPC Ethermint ETH JSON-RPC.
However when cosmos txs call EVM (examples:
https://github.com/zeta-chain/zeta-node/blob/f4b71ecc0bba901ce26f5274647b91fe14a28593/x/crosschain/keeper/keeper_cross_chain_tx_vote_inbound_tx.go#L69)
this transaction and receipt are not provided by ETH JSON-RPC, because this is not Ethereum tx and it's not included in the following important ETH JSON-RPC:

eth_getBlockByNumber
eth_getBlockByHash
eth_getTransactionByHash
eth_getTransactionByBlockHashAndIndex
eth_getTransactionReceipt
eth_getLogs
eth_getFilterLogs

Desired: Synthesize Ethereum transaction/receipt/logs from the cosmos tx/responses/log (the EVM logs at least) and include them in the above RPC call results.
Key References:
#420: forking ethermint RPC into zeta-node in which we implement the above additioins. This PR works on Ethermint 0.19 but (copy and redirect the ethermint/server and ethermint/rpc packages). Need to adapt to ethermint 0.21 as the current develop branch uses 0.21.
#363 : this PR synthesizes and exposes cosmos tx as ethereum tx, but in a separate set of non standard RPC. Need to incorporate these into standard ETH JSON-RPC.

Closing as it looks no longer relevant.

Closing as it looks no longer relevant.


Update intersphinx mappings

Summary
With the change to publishing many of the qiskit docs in ecosystem this updates the mapping url for rustworkx accordingly.
Since this is now the correct url, I also marked it for stable backport, for any docs updates we do, though I imagine the redirect on the former url will be in place for some time.
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 85.869%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
18589

Relevant Lines:
21648

💛  - Coveralls


docker: Error response from daemon: create ./output: "./output"

New to docker so it could be my lack of knowledge.
When trying to run the command below from the documentation, I am getting a docker error. If I remove the . from ./output it runs. What am I doing wrong?
docker run -v "./output:/tmp/output" punksecurity/smbeagle -c /tmp/output/results.csv -u USERNAME -p PASSWORD
docker: Error response from daemon: create ./output: "./output" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.
See 'docker run --help'.

Sorry for the insanely long time to get back to you.
You need to use an absolute path.  We'll update our docs
docker run -v "$(pwd)/output:/tmp/output" punksecurity/smbeagle -c /tmp/output/results.csv -u USERNAME -p PASSWORD


Edge-based routing without turn-costs

Discussion came up in #1698.

I think ideally we would have:

traversal_mode=edge_based/node_based (or edge_based=true/false ?) to determine the traversal mode, default: node. I think I would prefer traversal_mode, because this way we could throw an error if somebody still uses edge_based.
turn_costs=true/false to enable/disable turn costs, default: false

Maybe we need to make the defaults for traversal_mode and turn_costs configurable via config.yml ?

case
traversal_mode
turn_costs
expected behavior

1
node_based
false
node-based routing, no turn costs (and no u-turns)

2
node_based
true
enable traversal_mode=edge_based automatically

3
edge_based
false
edge-based routing, no turn costs (u-turns are free) unless CH is enabled in this case this should be an error because there will only be an edge-based CH profile with turn costs !? (see below)

4
edge_based
true
edge-based routing with turn costs and default u-turn costs (infinity/no u-turns)

So from the user perspective the most common cases would be:

specify nothing -> node based, no turn costs, no u-turns
set turn_costs=true -> edge based, with turn costs, no u-turns

For expert users:

set traversal_mode=edge_based -> edge-based routing, no turn costs, free u-turns

After this selection is made we check (do not use the vehicle or encoding manager to 'derive' the values for edge_based/turn_costs as is done currently):

if turn_costs=true: does the selected vehicle/encoder support turn costs (i.e. is there a turn cost extension for this encoder) ? if not throw an error.
is there a CH profile for the selected vehicle and the chosen traversal mode ? if not throw an error. however see #1637...
if an edge-based CH profile is selected and turn_costs=false throw an error (or should this be possible as well (requires edge-based CH preparation without turn costs and keeping track if CH preparation included turn-costs or not (in CHProfile)).


Arrow improvement

Makes it possible for 'on_activate' to be used when registering arrows.
Could be used to set the velocity or textures etc. of the arrow.

Added, thanks dude.


Units from zabbix and value maps

Hello, please consider getting units item attribute from the zabbix API source using item.get. Using it, we can achieve one click graph creation by automatically assigning Y-Axis type in Grafana similar to simple graph feature in the zabbix itself.
Value maps can also be collected for status-like metrics , so we do not need to redefine mapping once again in single stat panels.
Thanks for your great work !

Looks like this is already implemented, so closing this.


Fixed GitHub Repo and Updated to SpongeForge 833+

I updated to use the new way of getting builders, as well as fixed up your repository so it follows normal conventions.

Awesome! Will look this over and get it added. Thanks for the help.

@Erigitic Of course, :smile:

Done

Why didn't you just merge the PR?

I like to test out the code to make sure everything works out as planned before pushing it to GitHub. As far as I know, when merging a PR, I cannot do this.

Ah. Well, you know you can merge the PR, test to verify it works, and if not, undo the merge. Cheers!

Did not know that. I am a novice GitHub user so I am still in the process of understanding everything. Will keep this in mind for the next time. Sorry about the confusion and thanks again for the help.


Compilation on Windows 10 appears incomplete

Operating System: Windows 10
Compiler: MinGW-TDM-GCC-64
xgboost version used: 0.6
I was able to complete the compilation, however the only files generated in the lib folder are libxgboost.a and libxgboost.dll  (no xgboost.dll).  Thus I can't complete the python installation.

Quick update - After much trial and error - I have it working!
After a variety of tries with a number of Cygwin/MinGW flavors, it turns out using CMake/Visual Studio worked out best and I did get a functioning xgboost.ddl generated.  I strongly suggest following the official installation guide to the "T".  The only generator that works is the one suggested (Visual Studio 14 2015 Win64), also try to follow the default settings set out by the CMakefile and use the older Visual Studio SDK (ver 8.1 not 10.0) - I have Visual Studio 2017 installed along with CMake 3.9.0
Nice piece of software by the way!  My models are running screaming fast - I happen to have dual GTX-1080 GPU cards.


Introduce a concept guide for writing JSON and YAML based on a protobuf message

Unfortunately I had to hard-code our tables in HTML because I wanted multi-line code snippets in the table. Github markdown only supports a single line of content in a tabel's cell when the table is declared in markdown with pipes.

Updated to correct (lowerCamelCase) casing in the JSON/YAML examples.
We provide both because, as you say, YAML is a superset of JSON so a user can provide us config as JSON. Further, the mixer's config API accepts both JSON and YAML payloads so both formats can be used. Finally, it helps provide more context for the transformations: one example may not be clear but seeing the same example in multiple related forms can help drive home the core concept.

Tasks and Tutorials are for things that have step-by-step instructions.
Reference will ultimately primarily be for auto-generated authoritative
reference material like API docs and CLI command-line options.
So to me, this does belong in Concepts. It just doesn't belong at the top
of the table of contents. When we start filling in more docs, we can nest
this doc deeper, under the overall Config section.
How's that sound?
On Mon, Apr 10, 2017 at 7:57 PM, Shriram Rajagopalan <
<EMAIL_ADDRESS>wrote:

@rshriram commented on this pull request.
Suggestion: can we move this to reference , like the rules-dsl ? Or into
Tasks
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio.github.io/pull/13#pullrequestreview-32004272,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVucHfplsujGkmYwcxleKewPG4Dg_SjTks5ruuwDgaJpZM4M5a9Y
.

So the way I was viewing this was as a Task, with title, "Writing mixer configuration files" [I guess its a grey area here. I can go either way between concept and Task]. But I do agree that this does not belong in the ToC for concepts. It should be nested under the mixer.

This is more general than just mixer, though: proxy config is also yaml-conforming-to-proto-schema, as is manager config, right? I attempted to pull out anything mixer specific (with the exception that the examples use mixer protos).

I think the routing rule config doc (https://istio.io/docs/reference/rule-dsl.html) needs to tie into this one. Maybe in the first paragraph where it says that it's base on a proto 3 schema, it can point to this document for details on the mapping. Notice, however, that the routing language is described in YAML (not JSON), so I tend to agree with @kyessenov that it might be better for this doc to leave out the JSON examples and focus on YAML instead.
The reverse linkage may also be good, that is, this doc could include a link to https://istio.io/docs/reference/rule-dsl.html as an example of where the mapping is used.

PTAL


Dex (basic)

What kind of PR is this?:

/kind feature
What this PR does / why we need it:
Which issue(s) does this PR fixes?:

Fixes part of #54
Screenshot:

Codecov Report

Merging #62 (5b59f89) into main (4739c9e) will increase coverage by 1.87%.
The diff coverage is 89.47%.

:exclamation: Current head 5b59f89 differs from pull request most recent head fff53ad. Consider uploading reports for the commit fff53ad to get more accurate results

@@            Coverage Diff             @@
##             main      #62      +/-   ##
==========================================
+ Coverage   71.60%   73.48%   +1.87%
==========================================
  Files          13       15       +2
  Lines         162      181      +19
  Branches       25       30       +5
==========================================
+ Hits          116      133      +17
- Misses         46       47       +1
- Partials        0        1       +1

Impacted Files
Coverage Δ

src/pages/dex/index.tsx
88.23% <88.23%> (ø)

src/components/loader/loader.tsx
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

closed via https://github.com/DeFiCh/scan/pull/155


xlsx + electron: jszip reference error

Hi, I've created a plain electron app using electron-forge and its typescript & webpack template. When calling XLSX.read in the renderer.ts, the following error is thrown, leading to this line in jszip.js. Package versions can be seen in the package.json below.

ReferenceError
Uncaught ReferenceError: require is not defined
    at e (jszip.js:26)
    at jszip.js:26
    at jszip.js:1
    at Object../node_modules/xlsx/jszip.js (jszip.js:1)
    at __webpack_require__ (bootstrap:789)
    at fn (bootstrap:100)
    at make_xlsx_lib (xlsx.js:2960)
    at Object../node_modules/xlsx/xlsx.js (xlsx.js:21698)
    at __webpack_require__ (bootstrap:789)
    at fn (bootstrap:100)

package.json
{
  "devDependencies": {
    "@electron-forge/cli": "^6.0.0-beta.54",
    "@electron-forge/maker-deb": "^6.0.0-beta.54",
    "@electron-forge/maker-rpm": "^6.0.0-beta.54",
    "@electron-forge/maker-squirrel": "^6.0.0-beta.54",
    "@electron-forge/maker-zip": "^6.0.0-beta.54",
    "@electron-forge/plugin-webpack": "^6.0.0-beta.54",
    "@marshallofsound/webpack-asset-relocator-loader": "^0.5.0",
    "@typescript-eslint/eslint-plugin": "^4.8.1",
    "@typescript-eslint/parser": "^4.8.1",
    "css-loader": "^4.3.0",
    "electron": "11.0.1",
    "eslint": "^7.13.0",
    "eslint-plugin-import": "^2.22.1",
    "fork-ts-checker-webpack-plugin": "^5.2.1",
    "node-loader": "^1.0.2",
    "style-loader": "^1.3.0",
    "ts-loader": "^8.0.11",
    "typescript": "^4.0.5"
  },
  "dependencies": {
    "electron-squirrel-startup": "^1.0.0",
    "xlsx": "^0.16.8"
  }
}

Did anyone of you already encounter this issue, I guess that's a quite standard setup with webpack & typescript.
Do you have any Idea what's going on here and how to fix that, any help is appreciated!

@aplr Hi, did you manage to get this error fixed?
I am encountering the same thing but with Parcel Builder.

@aplr Hi, did you manage to get this error fixed?
I am encountering the same thing but with Parcel Builder.

@aplr I have the same error, I try to start reading xlsx.ReadFile/read or via fs in the react function , but it gives the same error. Were you able to solve the problem?


plottr-inspectr incompatible with Python 3.10

Creating a fresh Python 3.10 environment, installing plottr, then attempting to run plottr-inspectr yields the error:

Steps to reproduce:

Open an Anaconda terminal and run conda create -n <env_name> python=3.10.
Run pip install pyqt5 in the new environment.
Run pip install qcodes.
Run pip install plottr.
Run plottr-inspectr to produce the error.

Note that repeating the above steps with python=3.9 instead of 3.10 does not lead to any error.

Could you check if https://github.com/toolsforexperiments/plottr/pull/257 solves the issue?

Sorry, I'm a bit late. You worked too fast 😄 yes that fixed the issue, thank you.

Thanks, I will push out a new release tomorrow with the fix


'tooltipLabelColor' does not exist in type 'ChartDataSets'

Type error occurred after upgrading the package to the latest version 1.1.0.

Seems like we are using an older version of React template.


Smoke tests should validate Known Authority Constants

https://github.com/Azure/azure-sdk-for-python/pull/10469


Block: Set up SonarQube

As someone setting up the project infrastructure, I want to have a detailed guide on how to set up a SonarQube instance for Azure DevOps so that I can get this done fast and without errors.

Added --restart always to the docker run command and now the container with sonarqube is always up and running.


x/tools/gopls: find references shouldn't include starting identifier

When you find references on an identifier, the identifier itself is returned as a reference in addition to other locations that reference it. I realized this defeats my editor's if-single-result-jump-straight-there logic since there will be two results even if your identifier is only referenced in one (other) spot.
Is there a reason to keep the starting identifier in the results?

Seems that LSP has helpfully provided us with an includeDeclaration boolean, which I suppose we are ignoring: https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#textDocument_references. We should probably just respect that, and then editors can decide whether or not to show the declaration.

Actually, after taking a closer look - it seems like we mostly do respect this setting, unless the identifier was implicitly declared (which I believe only happens in a type switch). So, then I think this sounds like a client-side issue?

I checked and my editor does send "includeDeclaration": false.
I think the identifier itself gets included during the normal scan over Defs.


Upcase postal code for CanadaPostPWS

Canada Posts web service API is not every friendly with downcase'd postal codes. Therefore as part of removing whitespaces also upcase. Also add some tests around this behaviour.
Test failures are all remote UPS related seems like the API is having some issues
ActiveShipping::ResponseError: Failure: XML Rating and Service Selection Service Unavailable

fix CI and re-ping?

ci is 💚
repinging for review @nicolaslupien @qq99

LGTM


Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: number.  Check the render method of Home.

NB Never post screenshots of code. Post copy paste-able code if you include any.
Ignoring this will likely lead to direct closing of the issue.
Please respect the time and energy of open source maintainers.
Bug
Please provide a clear and concise description of what the bug is.
Include screenshots if needed.
Please test using the latest release of the library, as maybe said bug has been already fixed.
Unexpected behavior
If you have unexpected behavior, please create a clean project with the latest versions of react-native and react-native-svg
react-native init CleanProject
cd CleanProject/
yarn add react-native-svg
cd ios && pod install && cd ..
modify App.js -> run the app

If it's still an issue with the latest versions,
please make an sscce in the clean project,
and make it available as a git repo on github.
Or as a https://snack.expo.io/ if expo has the latest version,
and / or the bug exists both in the latest version and the one used in expo and snack.
Environment info
Run react-native info in your terminal and copy the results here. Also, include the precise version number of this library that you are using in the project
React native info output:
 // paste it here

Library version: x.x.x
Steps To Reproduce
Issues without reproduction steps or code are likely to stall.

git clone https://github.com/user/rnsvg-bug-repro
cd rnsvg-bug-repro
yarn
yarn ios
yarn android
...

Describe what you expected to happen:

Short, Self Contained, Correct (Compilable), Example
If you are having a problem with some code and seeking help, preparing a Short, Self Contained, Correct Example (SSCCE) is very useful. But what is an SSCCE?
It is all in the name, really. Take a look at each part. The version prepared for others to see should be:
Short (Small) - Minimise bandwidth for the example, do not bore the audience.
Self Contained - Ensure everything is included, ready to go.
Correct - Copy, paste, (compile,) see is the aim.
Example - Displays the problem we are trying to solve.
http://www.sscce.org/

The README is wrong, it should be
- import Svg, {
+ import {
+ Svg,
  Circle,
  Ellipse,

I am currently encountering this same behaviour as the title says.
I have added both react-native-svg and react-native-vg-transformer
Then I changed metro.config.js
Then I added declarations.d.ts as mentioned in the documentation.
Then I used the following code for importing:
import Logo from "../../theme/assets/svgs/logo_white.svg";
Then I used the following code for using it but getting error as mentioned in the title of this issue:
<Logo width={200} height={200} />
Any help would be really appreciated. Thanks.
PS: Versions:
react-native-cli: 2.0.1
react-native: 0.73.4

Hey guys,
@awerudev @hamzafarooq-10P
The issue is actually self-explanatory 😃 Provide string instead of number ;)
Instead of setting the dimension as numbers:
<Logo width={200} height={200} />
pass them as strings
<Logo width="200" height="200" />

I have this issue as well using react native 0.74.1 as well
I tried using
<Logo width={200} height={200} />
and
<Logo width="200" height="200" />
Any help would be much appreciated as I am upgrading my project and use SVGs on every screen

Hello @AdamLee321,
Can you share your metro.config and share the example to reproduce that issue, please.

Hey guys, @awerudev @hamzafarooq-10P
The issue is actually self-explanatory 😃 Provide string instead of number ;)
Instead of setting the dimension as numbers: <Logo width={200} height={200} />
pass them as strings <Logo width="200" height="200" />
Also don't forget to clean your builds, because it's important when you work with SVGs:
Android: cd android ./gradlew clean
iOS: cd ios xcodebuild clean

Working fine with this. Thank you.

Hello @hamzafarooq-10P,
It works for you, correct?
Can we close this issue?

Hello @hamzafarooq-10P, It works for you, correct? Can we close this issue?

Well, I am not the one who raised this issue. :)

Hello @MUSHTHAK2899,
Can you share the example to reproduce that issue?
Thank you

I also face this issue in react native 0.74.2
System:
  OS: macOS 13.6.6
  CPU: (8) arm64 Apple M2
  Memory: 105.17 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.16.0
    path: ~/.nvm/versions/node/v18.16.0/bin/node
  Yarn:
    version: 3.6.4
    path: ~/.nvm/versions/node/v18.16.0/bin/yarn
  npm:
    version: 9.7.1
    path: ~/.nvm/versions/node/v18.16.0/bin/npm
  Watchman:
    version: 2<IP_ADDRESS>
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/tnguyen6/.asdf/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.2
      - iOS 17.2
      - macOS 14.2
      - tvOS 17.2
      - visionOS 1.0
      - watchOS 10.2
  Android SDK:
    Android NDK: 22.1.7171670
IDEs:
  Android Studio: 2024.1 AI-241.15989.150.2411.11948838
  Xcode:
    version: 15.2/15C500b
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.10
    path: /usr/bin/javac
  Ruby:
    version: 2.7.6
    path: /Users/tnguyen6/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.74.2
    wanted: 0.74.2
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false

I've also created a minimal project that can reproduce the issue: test_project

@ducthong230497, I didn't see any place where do you use react-native-svg in repo

in the assets folder there are 2 svg files. I import and use them directly in App.tsx


It seems that leetcode-cn users not supported?

In weekly-contest-303，It seems no rating changes display about leetcode-cn users.

I'm able to see the rating change for all the users. Can you provide some extra info regarding this?

I'm able to see the rating change for all the users. Can you provide some extra info regarding this?
for example, a leetcode-cn user  named guardianemptycoder, he attempted the weekly-contest-303, but I can't find his rating changes on your leetcode-rating-predicator.

I'm able to see the rating change for all the users. Can you provide some extra info regarding this?

for example, a leetcode-cn user named guardianemptycoder, he attempted the weekly-contest-303, but I can't find his rating changes on your leetcode-rating-predicator.

another question, when I finded user named pi-hua-ting, I could find his related results quickly, but I tried to find "pi-hua", it returned nothing. Will fuzzy search feature be supported someday in the future?

I'm able to see the rating change for all the users. Can you provide some extra info regarding this?

for example, a leetcode-cn user named guardianemptycoder, he attempted the weekly-contest-303, but I can't find his rating changes on your leetcode-rating-predicator.

As for now you have to type case-sensitive exact username to get the rating change. You can find GuardianEmptyCoder's rating changes by searching for GuardianEmptyCoder.

another question, when I finded user named pi-hua-ting, I could find his related results quickly, but I tried to find "pi-hua", it returned nothing. Will fuzzy search feature be supported someday in the future?

You can create a separate issue for this feature request.  We can implement this in the future.


DataGrid IA explorations

Exploring how to handle DataGrid vs TanStack in IA

[x] Mock up examples
[x] Share with the team
[ ] Refine follow on work in parent issue

@oliviaflory Trying to follow the trail of where this IA exploration work landed and the impact on the Code tab of the DataGrid components on our site.  Can you pls share the Figma file or where the exploration landed? Thx

@ljcarot sorry I didn't realize the Figma wasn't linked.
I'm going to write a few issues for what the next steps are in the epic today


Add command-line option --splinter-webdriver-executable

For phantomjs/chrome drivers

Coverage decreased (-1.58%) to 88.57% when pulling b761217bcac41466d61c7046b7e52b525d6daa1a on sureshvv:master into fa4dc1e4020edd8e40222740588f82cd3beac23e on pytest-dev:master.

2 things:

there are commits from unrelevant PR, which is implemented already, so please remove those
can't it just be solved via PATH variable when running pytest?

OK.. May be not needed.

Coverage increased (+0.46%) to 90.61% when pulling 740be292a938cdc466f6195eda9ae8fad0bf586b on sureshvv:master into fa4dc1e4020edd8e40222740588f82cd3beac23e on pytest-dev:master.

please rebase to origin/master

Just learning git. Do not know about rebasing. But have made a new commit with just the changes. Let me know if any changes are needed.

Coverage increased (+0.37%) to 90.52% when pulling f45fbfbbfe4b8ef866370ad656e047e037af64b4 on sureshvv:master into fa4dc1e4020edd8e40222740588f82cd3beac23e on pytest-dev:master.

run this
git remote add upstream git@github.com:pytest-dev/pytest-splinter.git
git branch --set-upstream-to=upstream/master
git checkout -b webdriver-executable
git rebase -i origin/master  # follow the instructions
git push origin webdriver-executable
# edit PR on github to use this branch

and for future, don't do features directly on master, create branches

edit PR on github to use this branch

That's not possible.  A new PR would be required.
But you can force-push it to your master.
@sureshvv
If you have your commit with only the changes already, you can also use that by cherry-picking it directly:
# Create a new branch, based on origin/master
git checkout -b splinter-webdriver-executable origin/master
# Cherry-pick the commit from your other branch
git cherry-pick fa4dc1e
# Push it to your master, overwriting what is there
git push -f sureshvv splinter-webdriver-executable:master

This will update this PR (which is using your master branch).
@bubenkoff is right in that you should always use a branch for your PRs, which makes it easier to change/rebase them.

I recommend using https://github.com/github/hub btw, which provides additional commands to interface with Github.
@bubenkoff
You could also cherry-pick the commit or squash-merge them into master directly.  But then it's also good for @sureshvv to learn this.. :)

yep, that's why i tried to instruct him :)
On 12 April 2015 at 14:49, Daniel Hahler<EMAIL_ADDRESS>wrote:

I recommend using https://github.com/github/hub btw, which provides
additional commands to interface with Github.
@bubenkoff https://github.com/bubenkoff
You could also cherry-pick the commit or squash-merge them into master
directly. But then it's also good for @sureshvv
https://github.com/sureshvv to learn this.. :)
—
Reply to this email directly or view it on GitHub
https://github.com/pytest-dev/pytest-splinter/pull/23#issuecomment-92054346
.

--
Anatoly Bubenkov

Another pull request with single commit has been created now.


Pylance does not recognize typing.Final

Environment data
Pylance v2021.7.4

Language Server version: 2021.7.4 (pyright 209f9621)
OS and version: Linux Debian (Python Docker official image slim-buster)
Python version: 3.8.2

Expected behaviour
No error as in the following case when Final is omitted:
from dataclasses import dataclass

@dataclass
class MyDataclass:
    name: str = field()

MyDataclass(name="bar")

and second case
from dataclasses import dataclass

@dataclass
class MyDataclass:
    name: str = field()

    @classmethod
    def from_name(cls, name: str) -> MyDataclass:
        instance = cls(name)
        return instance

Actual behaviour
Error:
No parameter named "name" PylancereportGeneralTypeIssues
(constant) name: str
occurs due to the presence of Final as in the following case:
from dataclasses import dataclass
from typing import Final

@dataclass
class MyDataclass:
    name: Final[str] = field()

MyDataclass(name="bar")

and second case
from dataclasses import dataclass
from typing import Final

@dataclass
class MyDataclass:
    name: Final[str] = field()

    @classmethod
    def from_name(cls, name: str) -> MyDataclass:
        instance = cls(name)
        return instance

Error:
Expected 0 positional arguments Pylance(reportGeneralTypeIssues)
These are clearly false-positives and not expected behavior.
Code Snippet / Additional information
Contents of pyrightconfig.json file:
{
    "ignore": [],
    "pythonPlatform": "Linux",
    "pythonVersion": "3.8",
    "typeCheckingMode": "basic",
    "useLibraryCodeForTypes": true,
    "venv": "/opt/venv/bin/python"
}

Thanks for the bug report.
It wasn't immediately clear to me whether this was a bug based on the Python documentation. It took a bit of digging and experimentation to convince myself that the current behavior in Pylance is indeed incorrect.
PEP 591 (which introduced Final) says:

Type checkers should infer a final attribute that is initialized in a class body as being a class variable. Variables should not be annotated with both ClassVar and Final.

And PEP 557, which introduced dataclass, says:

If a field is a ClassVar, it is excluded from consideration as a field and is ignored by the Data Class mechanisms.

Consistent with these two statements, Pylance assumed that your use of Final indicated that name was implicitly a ClassVar and should not be considered a dataclass field.
However, after some experimentation, I've confirmed that there is apparently an implied exception to the PEP 557 rule for dataclasses. This exception isn't spelled out in any PEP, and I suspect that it was simply an oversight when dataclass was implemented. In any event, it's too late to change the behavior now without introducing a backward compatibility problem, so we're stuck with the inconsistency.
I've updated the dataclass logic in Pylance to add this exception so the behavior is consistent with the runtime support for dataclass.

Hi Eric, thanks for the super quick response, fix and explanation. Very much appreciated. How often are releases of pylance?
There is another issue I want to bring to your attention but I cannot reproduce it in isolation and unfortunately I cannot share my code with you as it's intellectual property. Another error occurs when using the @final decorator from the typing module. The error reads as follows:
Expected class type but received "_F@final"PylancereportGeneralTypeIssues)

I removed use of this decorator from my code as I don't really need it. This seems like a bug to me but I cannot be sure. The code producing this issue looks a little similar to the below (but this only has the issue described above that you have now fixed):
from dataclasses import dataclass
from typing import Final

def from_name(klass: MyDataclass) -> Dict[str, MyDataclass]:
    my_data: Dict[str, MyDataclass] = {"name": MyDataclass(klass.name)}
    return my_data

@final
@dataclass
class MyDataclass:
    name: Final[str] = field()
    age: Final[Optional[int]] = field()

The error shows on the MyDataclass in both Dict type annotations (whether it is a return type, a variable and the same issue happens in a function parameter annotation). Maybe from the error message you have an idea of what is going on even though I cannot reproduce it for you?

We typically release a new version once a week on or about Wednesday.
The error message above seems to reference a type variable _F that is used in the scope of a function or method called final. I don't see any TypeVars used in your sample, so there's probably something missing to repro the issue. If you're able to find a repro with a minimal sample, please feel free to open another issue.

There are no uses of TypeVar anywhere in my entire codebase. The closest thing I see is use of InitVar in two places in the codebase. I tried to reproduce with that but still no luck.
I will wait for the new release of pylance and try again with that. If I can reproduce then I will submit a new issue. Thanks very much for your help. You can go ahead and close this issue when you are ready.

This issue has been fixed in version 2021.7.5, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202175-22-july-2021

Issue still.

Pylance: v2024.9.2
VSCode:
版本: 1.93.1 (user setup)
提交: 38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40
日期: 2024-09-11T17:20:05.685Z
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22631


fix: Install content on the target machine instead of the provisioning

When trying to install node_exporter on the target machines, at a certain point the binaries would start to be installed on the machine where ansible is running which is not the point when doing automation tasks. This correction will avoid the installation of the exporter on the provisioning machine and also solve this error:
TASK [prometheus.prometheus.node_exporter : Download node_exporter binary to local folder] ************************
fatal: [...*]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ubuntu@localhost: Permission denied (publickey).", "unreachable": true}
Now, the binaries will be downloaded to ubuntu@targetmachine instead of ubuntu@localhost

There are reasons why it is downloaded on the provisioner and not directly on the target, it saves you from downloading the binary multiple times and it's not always that the target hosts can access the internet (although that is less of an issue after #28 got merged).
I understand why it might be appealing to be able to download the binaries directly on the target machines. But rather than changing the roles from fetching the binaries on the provisioner to fetch them on the target it would be better if it were a configurable option, so that you could choose which method you want.
With that being said, I think there might be something wrong with the setup on your provisioner, AFAIK ansible should use a local connection by default when talking to localhost and not use ssh.

#425


DirtyJIT MDC

how do i make this work using dirtyjit? it does nothing using dirtyjit it only works via sidestore enable jit button

DirtyJIT requires an already started process which is inapplicable to LiveContainer.


Migrate to sbt-typelevel

Following from http4s-dom, this one tests a couple new things:

tlCrossRootProject
Publishing hash releases, to s01 (that's where my personal group id is)

yolo this one too 😉


use --user=root Startup failure

I'm using deepin Linux
x11docker --desktop   --user=root  --size 320x240 x11docker/lxde
Unable to start successfully
x11docker.log at pastebin

Thanks for reporting!
I can reproduce this issue if I use option --no-init on my debian system.
The deepin docker package seems to miss /usr/bin/docker-init as I see in your logfile.
With /usr/bin/docker-init the issue does not appear.
Though, I am not sure about the reasons. Neither x11docker logfile nor LXDE logfile does show anything obvious. Same happens with x11docker/xfce.
Same happens with option --sudouser instead of --user=root.
I will investigate further and inform you if I find out something.

I have published a new release v4.2.0.
x11docker --desktop --user=root --size 320x240 x11docker/lxde will run now without any issue and without additional setup.
I'll close this issue. Feel free to reopen if you still have an issue.
Thanks again for reporting!

The problem is really solved in the new version


UPSTREAM: : Reworded logs to indicate non-critical issues and …

Resolves RHOAIENG-6710
Updated some log messages in DSP server to clearly convey that the reported issues are non-critical and intended for informational purposes only, helping users understand that these messages do not require immediate action.

Commit Checker results:
**NOTE**: These are the results of the commit checker scans.
If these are not commits from upstream kfp, then please ensure
you adhere to the commit checker formatting

commitchecker verson unknown
Validating 1 commits between bbfb5897533403b38ad8956424931868c103b0b0...332712fbb95e9b69bad2b40bc72d28c85866f179

A set of new images have been built to help with testing out this PR:
API Server: quay.io/opendatahub/ds-pipelines-api-server:pr-67
DSP DRIVER: quay.io/opendatahub/ds-pipelines-driver:pr-67
DSP LAUNCHER: quay.io/opendatahub/ds-pipelines-launcher:pr-67
Persistence Agent: quay.io/opendatahub/ds-pipelines-persistenceagent:pr-67
Scheduled Workflow Manager: quay.io/opendatahub/ds-pipelines-scheduledworkflow:pr-67
MLMD Server: quay.io/opendatahub/mlmd-grpc-server:latest
MLMD Envoy Proxy: registry.redhat.io/openshift-service-mesh/proxyv2-rhel8:2.3.9-2
UI: quay.io/opendatahub/ds-pipelines-frontend:pr-67

An OCP cluster where you are logged in as cluster admin is required.
The Data Science Pipelines team recommends testing this using the Data Science Pipelines Operator.  Check here for more information on using the DSPO.
To use and deploy a DSP stack with these images (assuming the DSPO is deployed), first save the following YAML to a file named dspa.pr-67.yaml:
apiVersion: datasciencepipelinesapplications.opendatahub.io/v1alpha1
kind: DataSciencePipelinesApplication
metadata:
  name: pr-67
spec:
  dspVersion: v2
  apiServer:
    image: "quay.io/opendatahub/ds-pipelines-api-server:pr-67"
    argoDriverImage: "quay.io/opendatahub/ds-pipelines-driver:pr-67"
    argoLauncherImage: "quay.io/opendatahub/ds-pipelines-launcher:pr-67"
  persistenceAgent:
    image: "quay.io/opendatahub/ds-pipelines-persistenceagent:pr-67"
  scheduledWorkflow:
    image: "quay.io/opendatahub/ds-pipelines-scheduledworkflow:pr-67"
  mlmd:
    deploy: true  # Optional component
    grpc:
      image: "quay.io/opendatahub/mlmd-grpc-server:latest"
    envoy:
      image: "registry.redhat.io/openshift-service-mesh/proxyv2-rhel8:2.3.9-2"
  mlpipelineUI:
    deploy: true  # Optional component
    image: "quay.io/opendatahub/ds-pipelines-frontend:pr-67"
  objectStorage:
    minio:
      deploy: true
      image: 'quay.io/opendatahub/minio:RELEASE.2019-08-14T20-37-41Z-license-compliance'

Then run the following:
cd $(mktemp -d)
git clone git@github.com:opendatahub-io/data-science-pipelines.git
cd data-science-pipelines/
git fetch origin pull/67/head
git checkout -b pullrequest 332712fbb95e9b69bad2b40bc72d28c85866f179
oc apply -f dspa.pr-67.yaml

More instructions here on how to deploy and test a Data Science Pipelines Application.

Commit Checker results:
**NOTE**: These are the results of the commit checker scans.
If these are not commits from upstream kfp, then please ensure
you adhere to the commit checker formatting

commitchecker verson unknown
Validating 0 commits between d0ee4ca4524ece9f201581345ef791a1d4ee8e68...0374852ea62b5cc8b0d99a4b38aef4fc362970d5

Change to PR detected. A new PR build was completed.
A set of new images have been built to help with testing out this PR:
API Server: quay.io/opendatahub/ds-pipelines-api-server:pr-67
DSP DRIVER: quay.io/opendatahub/ds-pipelines-driver:pr-67
DSP LAUNCHER: quay.io/opendatahub/ds-pipelines-launcher:pr-67
Persistence Agent: quay.io/opendatahub/ds-pipelines-persistenceagent:pr-67
Scheduled Workflow Manager: quay.io/opendatahub/ds-pipelines-scheduledworkflow:pr-67
MLMD Server: quay.io/opendatahub/mlmd-grpc-server:latest
MLMD Envoy Proxy: registry.redhat.io/openshift-service-mesh/proxyv2-rhel8:2.3.9-2
UI: quay.io/opendatahub/ds-pipelines-frontend:pr-67

Commit Checker results:
**NOTE**: These are the results of the commit checker scans.
If these are not commits from upstream kfp, then please ensure
you adhere to the commit checker formatting

commitchecker verson unknown
Validating 0 commits between d0ee4ca4524ece9f201581345ef791a1d4ee8e68...250cff4fe6071260f6cce944c842a5de4a739308

lgtm but can you squash these before we merge it?

/lgtm
/approve
thanks!

Commit Checker results:
**NOTE**: These are the results of the commit checker scans.
If these are not commits from upstream kfp, then please ensure
you adhere to the commit checker formatting

commitchecker verson unknown
Validating 0 commits between d0ee4ca4524ece9f201581345ef791a1d4ee8e68...3fe68376ce94d1ca7354d68bae7d530a899b7b1c

Commit Checker results:
**NOTE**: These are the results of the commit checker scans.
If these are not commits from upstream kfp, then please ensure
you adhere to the commit checker formatting

commitchecker verson unknown
Validating 0 commits between a8fbbd2020d280f4cab31245a9639a350207b3f9...3fe68376ce94d1ca7354d68bae7d530a899b7b1c

Change to PR detected. A new PR build was completed.
A set of new images have been built to help with testing out this PR:
API Server: quay.io/opendatahub/ds-pipelines-api-server:pr-67
DSP DRIVER: quay.io/opendatahub/ds-pipelines-driver:pr-67
DSP LAUNCHER: quay.io/opendatahub/ds-pipelines-launcher:pr-67
Persistence Agent: quay.io/opendatahub/ds-pipelines-persistenceagent:pr-67
Scheduled Workflow Manager: quay.io/opendatahub/ds-pipelines-scheduledworkflow:pr-67
MLMD Server: quay.io/opendatahub/mlmd-grpc-server:latest
MLMD Envoy Proxy: registry.redhat.io/openshift-service-mesh/proxyv2-rhel8:2.3.9-2
UI: quay.io/opendatahub/ds-pipelines-frontend:pr-67

Change to PR detected. A new PR build was completed.
A set of new images have been built to help with testing out this PR:
API Server: quay.io/opendatahub/ds-pipelines-api-server:pr-67
DSP DRIVER: quay.io/opendatahub/ds-pipelines-driver:pr-67
DSP LAUNCHER: quay.io/opendatahub/ds-pipelines-launcher:pr-67
Persistence Agent: quay.io/opendatahub/ds-pipelines-persistenceagent:pr-67
Scheduled Workflow Manager: quay.io/opendatahub/ds-pipelines-scheduledworkflow:pr-67
MLMD Server: quay.io/opendatahub/mlmd-grpc-server:latest
MLMD Envoy Proxy: registry.redhat.io/openshift-service-mesh/proxyv2-rhel8:2.3.9-2
UI: quay.io/opendatahub/ds-pipelines-frontend:pr-67


improving Prolog test speed for gprolog

The Prolog test suis (tests/prolog) is not very fast for gprolog. Indeed, compiling/consulting Logtalk’s large Prolog files is not very fast in gprolog (mainly due to file IO since generated files are plain Prolog text files - something I plan to improve). It seems that these files are consulted at each test. Currently, on my M2 Mac:
% 186 test sets: 175 completed, 9 skipped, 2 broken, 0 timedout, 0 crashed
% 3138 tests: 97 skipped, 2918 passed, 123 failed (0 flaky)
real	5m16.638s
user	4m30.196s
sys	0m38.063s

Maybe it is possible to modify Logtalk to run several tests in the same session (e.g. all tests in the same directory ?). However, I understand this is maybe a major change in your code.
There are 2 other possibilities for gprolog which needs few modifications in Logtalk: compilation for byte-code and compilation to native code.
Preliminary step: create integration/logtalk_gp_new.pl
Both solutions require an initial modification in the integration file to replace the initialization/1 directive (consisting of several consult/1) by include/1 directives. This is an improvement and could be applied to all other ISO systems.
NB: I call this file logtalk_gp_new.pl but it is not necessary to have 2 files, simply replace the current logtalk_gp.pl by this content:
:- set_prolog_flag(suspicious_warning, off).
:- include('$LOGTALKHOME/integration/logtalk_comp_gp.pl').
:- include('$LOGTALKHOME/adapters/gnu.pl').
:- include('$LOGTALKHOME/paths/paths.pl').
:- set_prolog_flag(suspicious_warning, on).

NB2: I had to put the include('logtalk_comp_gp.pl') first (while it is consulted last), else I had a compilation warning:
In file included from logtalk_gp_new.pl:29
                 from $LOGTALKHOME/integration/logtalk_comp_gp.pl:26
$LOGTALKHOME/core/core.pl:191: warning: directive occurs after definition of logtalk_library_path/2 - directive ignored

To test with this logtalk_gp_new.pl (before replacing existing logtalk_gp.pl), modify gplgt.sh:
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp.pl']" "$@"
exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp_new.pl']" "$@"

With this inclusions all tests work well (i.e. as previously and with same timing).
Solution 1: compile for byte-code
This can be done with:
gplc -w logtalk_gp_new.pl

This creates a file logtalk_gp_new.wbc which can be loaded with load/1 built-in.
Modify gplgt.sh replacing consult/1 by load/1:
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp.pl']" "$@"
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp_new.pl']" "$@"
exec gprolog --entry-goal "load('\$LOGTALKHOME/integration/logtalk_gp_new.wbc')" "$@"

With this, the whole test is around 33% faster:
% 186 test sets: 175 completed, 9 skipped, 2 broken, 0 timedout, 0 crashed
% 3138 tests: 97 skipped, 2918 passed, 123 failed (0 flaky)
real	3m33.545s
user	2m51.542s
sys	0m34.623s

Solution 2: compile to native-code
A new top-level called gplgt_native including logtalk code should be obtained with:
gplc -o gplgt_native --new-top-level logtalk_gp_new.pl

But this reveals a problem:
Undefined symbols for architecture arm64:
  "predicate('$logtalk#0.print_message#3'/4)", referenced from:

It seems that '$logtalk#0.print_message#3'/4 is created in a temporary file/folder (I could not find its definition with grep, I only found it is invoked in core/core.pl). I fixed it by surrounding the 2 invocations in core.pl with call/1:
619c619
< 	'$logtalk#0.print_message#3'(comment(debugging), debugger, logtalk_debugger_aborted, ExCtx).
---
> 	call('$logtalk#0.print_message#3'(comment(debugging), debugger, logtalk_debugger_aborted, ExCtx)).
6729c6729
< 		'$logtalk#0.print_message#3'(Kind, core, Message, ExCtx)
---
> 		call('$logtalk#0.print_message#3'(Kind, core, Message, ExCtx))

The compilation is now OK:
gplc -o gplgt_native --new-top-level logtalk_gp_new.pl

NB: I suppose the adequate way to solve this is to add a multifile/1 directive in core.pl (easy) but also in the temporary file created in scratch/ (more difficult for me):
:- multifile('$logtalk#0.print_message#3'/4).

Anyway, this creates a new top-level, run it with:
./gplgt_native

This file should act exactly as gplgt.sh, so we can now modify gplgt.sh as follows:
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp.pl']" "$@"
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp_new.pl']" "$@"
#exec gprolog --entry-goal "load('\$LOGTALKHOME/integration/logtalk_gp_new.wbc')" "$@"
exec "$LOGTALKHOME/integration/gplgt_native" "$@"

With this, the whole test time is divided by 2:
% 186 test sets: 175 completed, 9 skipped, 2 broken, 0 timedout, 0 crashed
% 3138 tests: 97 skipped, 2918 passed, 123 failed (0 flaky)
real	2m55.230s
user	2m18.015s
sys	0m30.221s

Conclusion
It is easy to improve, logtalk for gprolog (the inclusion vs consult can be done for other systems). I would be in favor of let the user chose which version it wants, e.g. modifying the script gplgt.sh to accept an additional argument (default=consult or bcfor byte-code or nc for native code). Another possibility is to proved 3 scripts.
Then modify logtalk_tester.sh to accept one of the 3 above (e.g. -p gnu, -p gnu_bc, -p gnu_nc or any other option).

Detailed reply later. Meanwhile, have you noticed:
https://github.com/LogtalkDotOrg/logtalk3/tree/master/scripts/embedding/gprolog

The Prolog test suis (tests/prolog) is not very fast for gprolog. Indeed, compiling/consulting Logtalk’s large Prolog files is not very fast in gprolog (mainly due to file IO since generated files are plain Prolog text files - something I plan to improve). It seems that these files are consulted at each test. Currently, on my M2 Mac:
% 186 test sets: 175 completed, 9 skipped, 2 broken, 0 timedout, 0 crashed
% 3138 tests: 97 skipped, 2918 passed, 123 failed (0 flaky)
real	5m16.638s
user	4m30.196s
sys	0m38.063s

Maybe it is possible to modify Logtalk to run several tests in the same session (e.g. all tests in the same directory ?). However, I understand this is maybe a major change in your code.

That's already the case: each test set is in its own directory. I assume you meant all tests in a directory and  it's sub-directories?

There are 2 other possibilities for gprolog which needs few modifications in Logtalk: compilation for byte-code and compilation to native code.
Preliminary step: create integration/logtalk_gp_new.pl
Both solutions require an initial modification in the integration file to replace the initialization/1 directive (consisting of several consult/1) by include/1 directives. This is an improvement and could be applied to all other ISO systems.

Nowadays, yes. But, in general, consulting, ensure loading, or including files shouldn't make a significant difference in Logtalk startup times.

NB: I call this file logtalk_gp_new.pl but it is not necessary to have 2 files, simply replace the current logtalk_gp.pl by this content:
:- set_prolog_flag(suspicious_warning, off).
:- include('$LOGTALKHOME/integration/logtalk_comp_gp.pl').
:- include('$LOGTALKHOME/adapters/gnu.pl').
:- include('$LOGTALKHOME/paths/paths.pl').
:- set_prolog_flag(suspicious_warning, on).

NB2: I had to put the include('logtalk_comp_gp.pl') first (while it is consulted last), else I had a compilation warning:
In file included from logtalk_gp_new.pl:29
                 from $LOGTALKHOME/integration/logtalk_comp_gp.pl:26
$LOGTALKHOME/core/core.pl:191: warning: directive occurs after definition of logtalk_library_path/2 - directive ignored

The warning seems to be due to the core.pl file containing the multifile directive for this predicate but no clauses for it. The paths.pl file contain both. A gplc issue or limitation in the handling of multifile/1 directives?

To test with this logtalk_gp_new.pl (before replacing existing logtalk_gp.pl), modify gplgt.sh:
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp.pl']" "$@"
exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp_new.pl']" "$@"

With this inclusions all tests work well (i.e. as previously and with same timing).

That should indeed be the case.

Solution 1: compile for byte-code
This can be done with:
gplc -w logtalk_gp_new.pl

This creates a file logtalk_gp_new.wbc which can be loaded with load/1 built-in.
Modify gplgt.sh replacing consult/1 by load/1:
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp.pl']" "$@"
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp_new.pl']" "$@"
exec gprolog --entry-goal "load('\$LOGTALKHOME/integration/logtalk_gp_new.wbc')" "$@"

With this, the whole test is around 33% faster:
% 186 test sets: 175 completed, 9 skipped, 2 broken, 0 timedout, 0 crashed
% 3138 tests: 97 skipped, 2918 passed, 123 failed (0 flaky)
real	3m33.545s
user	2m51.542s
sys	0m34.623s

Solution 2: compile to native-code
A new top-level called gplgt_native including logtalk code should be obtained with:
gplc -o gplgt_native --new-top-level logtalk_gp_new.pl

But this reveals a problem:
Undefined symbols for architecture arm64:
  "predicate('$logtalk#0.print_message#3'/4)", referenced from:

It seems that '$logtalk#0.print_message#3'/4 is created in a temporary file/folder (I could not find its definition with grep, I only found it is invoked in core/core.pl). I fixed it by surrounding the 2 invocations in core.pl with call/1:
619c619
< 	'$logtalk#0.print_message#3'(comment(debugging), debugger, logtalk_debugger_aborted, ExCtx).
---
> 	call('$logtalk#0.print_message#3'(comment(debugging), debugger, logtalk_debugger_aborted, ExCtx)).
6729c6729
< 		'$logtalk#0.print_message#3'(Kind, core, Message, ExCtx)
---
> 		call('$logtalk#0.print_message#3'(Kind, core, Message, ExCtx))

This fix is not an option that I'm willing to apply to the core.pl file. The solution here is to use the provided embedding script that I mentioned in my previous reply.

The compilation is now OK:
gplc -o gplgt_native --new-top-level logtalk_gp_new.pl

NB: I suppose the adequate way to solve this is to add a multifile/1 directive in core.pl (easy) but also in the temporary file created in scratch/ (more difficult for me):
:- multifile('$logtalk#0.print_message#3'/4).

Anyway, this creates a new top-level, run it with:
./gplgt_native

The embedding script can be used to create a new GNU Prolog + Logtalk top-level without those hacks.

This file should act exactly as gplgt.sh, so we can now modify gplgt.sh as follows:
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp.pl']" "$@"
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp_new.pl']" "$@"
#exec gprolog --entry-goal "load('\$LOGTALKHOME/integration/logtalk_gp_new.wbc')" "$@"
exec "$LOGTALKHOME/integration/gplgt_native" "$@"

With this, the whole test time is divided by 2:
% 186 test sets: 175 completed, 9 skipped, 2 broken, 0 timedout, 0 crashed
% 3138 tests: 97 skipped, 2918 passed, 123 failed (0 flaky)
real	2m55.230s
user	2m18.015s
sys	0m30.221s

Conclusion
It is easy to improve, logtalk for gprolog (the inclusion vs consult can be done for other systems). I would be in favor of let the user chose which version it wants, e.g. modifying the script gplgt.sh to accept an additional argument (default=consult or bcfor byte-code or nc for native code). Another possibility is to proved 3 scripts.

That would require the compilation to byte code or native code to be done once to be effective, ideally during installation or when updating the Logtalk git repo clone. But that rises some complications. E.g. installation can happen running a manual installation script or using one of the provided installers. Also, any solution should work the same for both POSIX and Windows systems.

Then modify logtalk_tester.sh to accept one of the 3 above (e.g. -p gnu, -p gnu_bc, -p gnu_nc or any other option).

That's far easier. It only requires deciding on the name of the native gplgt version.

Testing your suggestion for the logtalk_gp.pl shows that the changed file order breaks settings files (which are used to override default flag values). The correct order is:
:- set_prolog_flag(suspicious_warning, off).
:- built_in.
:- include('$LOGTALKHOME/adapters/gnu.pl').
:- include('$LOGTALKHOME/paths/paths.pl').
:- include('$LOGTALKHOME/core/core.pl').
:- set_prolog_flag(suspicious_warning, on).

But, as you mentioned, then compilation to native code fails with errors.
P.S. The relevant test set here is logtalk3/tests/logtalk/settings.

I'm happy to change the logtalk_gp.pl file to use include/1 directives. But the fix for the compilation to native code error is in the GNU Prolog side (in the handling of multifile/1 directives). To be clear, breaking settings files functionality is not an option.

Obviously ! I keep you informed when I make some progress on this.

BTW, the executable is not standalone and needs logtalk Prolog code be around.

Not sure I understand. Are you referring to the executable generated by the current embedding script? I can delete all the Logtalk code from its install location and the executable still works fine. And its startup time is noticeably faster than the gplgt integration script.

I just tested the embedding feature and it woks very well. I followed example in ../SCRIPT.txt I and the 'logtalk' executable generated is standalone. It starts must faster. How can I use it to run the tests ? I tried to simply modified gplgt.sh:
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp.pl']" "$@"
exec $HOME/collect/logtalk "$@"

But this does not work.
BTW: can you rapidly explain me what does the script ? (I tried to understand how it works: it seems important files are copied in a tmp dir (e.g. core.pl), I suppose others are generated in this tmp dir. I also seen several logtalk_compile, what is the result of the logtalk compilation ? What is the difference between what I did in my experiments and what the script does (both generated a native executable) ?

I just tested the embedding feature and it woks very well. I followed example in ../SCRIPT.txt I and the 'logtalk' executable generated is standalone.

Thanks for confirming. Btw, is there a way to check if a gplc generated executable have any dependency in some external Prolog code?

It starts must faster. How can I use it to run the tests ? I tried to simply modified gplgt.sh:
#exec gprolog --entry-goal "['\$LOGTALKHOME/integration/logtalk_gp.pl']" "$@"
exec $HOME/collect/logtalk "$@"

But this does not work.

The logtalk_tester.* scripts will need to be modified to accept an alternative to -p gnu. I will look into it.

BTW: can you rapidly explain me what does the script ? (I tried to understand how it works: it seems important files are copied in a tmp dir (e.g. core.pl), I suppose others are generated in this tmp dir. I also seen several logtalk_compile, what is the result of the logtalk compilation ? What is the difference between what I did in my experiments and what the script does (both generated a native executable) ?

A small part of Logtalk (the built-in objects, protocols, and categories) is implemented in Logtalk itself. Thus, calls to the logtalk_compile/2 predicate are used to compile those Logtalk source files into intermediate Prolog code, which is then combined with the Prolog code for the compiler/runtime and the backend adapter file (and optionally the intermediate  Prolog code generated from a Logtalk application). The logtalk_compile/2 predicate differs from the logtalk_load/2 predicate in that it compiles to disk instead of both compiling to disk and loading the resulting Prolog files.

Btw, is there a way to check if a gplc generated executable have any dependency in some external Prolog code?

You can test if there is a a dependencies at the native executable level (dynamic libs) with ldd (or otool -L on mac). There is no dependencies on Prolog files, except if the Prolog compiled code does itself consult/1, load/1 (or any other file reading).

The logtalk_tester.* scripts will need to be modified to accept an alternative to -p gnu. I will look into it.

That would be great !

A small part of Logtalk (the built-in objects, protocols, and categories) is implemented in Logtalk itself. Thus, calls to the logtalk_compile/2 predicate are used to compile those Logtalk source files into intermediate Prolog code, which is then combined with the Prolog code for the compiler/runtime and the backend adapter file (and optionally the intermediate Prolog code generated from a Logtalk application). The logtalk_compile/2 predicate differs from the logtalk_load/2 predicate in that it compiles to disk instead of both compiling to disk and loading the resulting Prolog files.

Nice piece of work. Really

Thanks. Btw, can you take a look to the "Known issues" section in the https://github.com/LogtalkDotOrg/logtalk3/blob/master/scripts/embedding/gprolog/NOTES.md file and let me know if anything there is now outdated?

I'm testing with changes to the logtalk_tester.sh script that support:
$ logtalk_tester -p gnunative

This assumes a gplgt_native executable in the system PATH that was generated using:
$ ./gprolog_embed_logtalk.sh -c -d ~/collect

This new executable works fine and I can load applications and run tests from its top-level. But it doesn't work when called from the logtalk_tester.sh script. The problem seems to be that the script calls the executable using the --query-goal option. But the option seems to not be available. What am I missing?

Solved using:
$ ./gprolog_embed_logtalk.sh -c -d ~/collect -- --new-top-level

https://github.com/LogtalkDotOrg/logtalk3/commit/9999ebc6b9181d6fc5c732a65b1413b1281718ef

Exactly, pass --new-top-level to act as a new top-level (and thus recognize top-level options).
We can even then add -n to name the executable and pass gplc option to avoid suspicious warning:
./gprolog_embed_logtalk.sh -c -n gplgt_native  -d ~/collect -- --new-top-level --no-susp-warn

However, logtalk_tester .sh -p gnunative does not yet work.

In the above commit I went with shorter names: gnunc and gplgtnc.

Works perfectly ! Thanks.
A (minor) suggestion: you could extend the system allowing logtalk_tester.sh -p option of the form system[_variant] which would invoke:

systemlgt.sh if there is no variant part.
system_variant_ if there is a variant.

This will simplify (future) use of other embedded systems by logtalk_tester.sh:
For gprolog we could have:
-p gp invoking gplgt.sh as now (no change)
-p gp_nc invoking gplgt_nc (small change)
and even
-p gp_bc invoking gplgt_bc (if one day we want to handle a pre-compiled version for byte-code)
This requires a bit change for gprolog: -p gnu becoming -p gp (gnu is not a good idea since gnulgt is a bit confusing).
Do you think it is useful ?

System identifiers were taken from the names of the Prolog systems minus the word Prolog. Thus gnu, swi, trealla, ... Same identifiers are use for the Logtalk prolog_dialect flag values. I see no sufficient reason here to break backwards compatibility.

OK. I then summarize (on a Unix-like system):
Create a gprolog native executable called gplgtnc thanks to logtalk embedding capabilities and copy/link it under a directory of the PATH:
$ cd $LOGTALKHOME/scripts/embedding/gprolog
$ ./gprolog_embed_logtalk.sh -c -n gplgtnc  -d ~/collect -- --new-top-level --no-susp-warn
$ ln -s ~/collect/gplgtnc SOME_DIR_OF_PATH

Use it to execute the tests:
$ cd $LOGTALKHOME/tests/prolog
$ logtalk_tester.sh -p gnunc

Thanks again

Also explained in the updated man file.
Thanks for your feedback and help.


Change novis.mac and vis.mac with new detector configuration names

Remove defunct detector configuration names and add new Box and Line SK configurations.

Looks good.


H

Bug Type
Functional
Reproduction steps
G
Actual result
G
Expected result
U
Suggested Severity
Vulnerability
Device
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional Context
B

https://github.com/tonkeeper/ton-connect/issues/26#issue-2622396883


Blog Posts: No alt-text or title-text attributes on featured images

... although inline images have them. Looks like it might be add-able through config, though:
https://answers.netlify.com/t/alt-text-and-title-text-for-featured-image/1681/2
If that isn't possible, we should probably avoid featured images, and use leading inline images instead for accessibility reasons.

It looks pretty straight forward to add the title and alt text to the image and the blog management GUI, so I'll plan on doing that. The only labor intensive part is going to be going back through 10 years of blog posts to add those. But if I do it in chucks of six months or a year, it won't be that bad.

I think if you show us how to do it, the team can make those edits. And you
can focus on improvements
On Sat, Feb 27, 2021, 18:52 Kyle Johnson<EMAIL_ADDRESS>wrote:

It looks pretty straight forward to add the title and alt text to the
image and the blog management GUI, so I'll plan on doing that. The only
labor intensive part is going to be going back through 10 years of blog
posts to add those. But if I do it in chucks of six months or a year, it
won't be that bad.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/xbmc/kodi-tv/issues/56#issuecomment-787109833, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNLEZA57ZLL5WDCILWQWNTTBEWNNANCNFSM4YKDHUXQ
.

OK, the code and CMS updates are done so that a featured image can have both a title and alt text. I updated the Matrix final blog post so you can see what that looks like.  While you technically could update the alt text and title from the CMS GUI, I would not recommend it, as each time you save an updated post the entire site rebuilds.  Instead, I'd recommend getting a copy of the site via git and then editing the index.md file for each blog post in src/content/article/.  The title and alt text are in the frontmatter part at the top. An unedited file that has a featured image will look like this:
---
title: Refactoring of the Add-on Subsystem
date: 2021-01-03T00:52:00.000Z
author: Frank H.
featured_image:
  src: /images/blog/olav-ahrens-rotne-jvBXiynINGE-unsplash.jpg
  title: ''
  alt: ''
---

and a finished one will look like this:
---
title: Kodi 19.0 "Matrix" - Release
date: 2021-02-19T20:49:22.165Z
author: Prof Yaffle
featured_image:
  src: /images/blog/kodi_splash_v19.0_matrix_final_1080p.jpg
  title: Kodi 19 Matrix splash screen
  alt: Kodi 19 Matrix splash screen
---

We should probably figure out some process so that people aren't working on the same files at the same time. Not that we couldn't figure it out at merge, but I don't want to do double or triple work.

I can find this: featured_image:  589 times in the code base. Of those 338 don't have a featured image featured_image: ""
Searching for featured_image: / will give you the remaining ones, that we need to fix.
I'll prepare a branch, that has all these edits, but need a manual cleanup of these occurrences.

Sorry, these counts were done on an old version. Here's the branch https://github.com/xbmc/kodi-tv/pull/61

@Razzeee Thanks for doing this. Remind me of correct github etiquette here: fork your branch, commit to that fork, and raise a PR? Clone and push directly? Or am I okay to directly edit the files in your branch on github (which will be quicker)?

Honestly do whatever you think is easiest. I would have gone for Clone and push directly

Okay, I've added/adjusted alt and title text for all 2021, 2020 and 2019 blog posts. Enough already, I think that'll do :smile:
Hopefully, no huge failings, although it's possible that some embedded apostrophes might confuse - I removed where I noticed them.

Thanks for that.  I'm going to go ahead and merge it and close this issue.  The reality is that according the the accessibility specs (at least the ones I used a few years back), images can have a blank alt text if they are purely decorative (i.e. they convey no meaningful information). Screen readers skip them (or just say something like "decorative image" depending on the vendor).  And you could argue that most of the featured images are just decorative. So have good ones back a couple years is going to be just fine.