Streamline process of assigning people to training events

Current workflow:

Go to /workshops/training_requests/.
Search for a particular person.
Click on the pencil icon to edit that TrainingRequest record.
Match the TrainingRequest to a person and mark the application as "Accepted".
Return to the list of training requests.
Select that person's record (tick box in the left column).
Select an upcoming training event from the pull down and submit in order to match that person to the training event.

There are several ways to streamline this:

When editing a particular TrainingRequest: as soon as the "Accepted" box is ticked, a pull-down should appear to allow the user to assign that person to an upcoming training event.
On the page that shows all TrainingRequests, the column title "Matched Trainee" should be a pulldown allowing me to match the person right there and then to an existing Person record, while the "State" column should allow me to change their state without leaving this page.

On the page that shows all TrainingRequests, the column title "Matched Trainee" should be a pulldown allowing me to match the person right there and then to an existing Person record, while the "State" column should allow me to change their state without leaving this page.

@gvwilson, you can accept a request and match it with person record (or create a new one) in detailed view. That is, now, you can match a request with an existing trainee account in two clicks: first click "i" icon and then click "accept & match to selected trainee account". You're automaticaly redirected back to list view. Is it quick enough?

When editing a particular TrainingRequest: as soon as the "Accepted" box is ticked, a pull-down should appear to allow the user to assign that person to an upcoming training event.

After clicking "accept & match to selected trainee account", you need select a request (that is, check the checkbox), scroll down, select training and click "match selected trainees to chosen training". That is four actions.
To sum up, each request can be processed with 2 + 4 = 6 actions now. I don't see how this can be significantly improved except that we could suggest incoming training, so to make selecting a training faster.

After the call with @gvwilson, I agree with the proposed improvements.

On the page that shows all TrainingRequests, the column title "Matched Trainee" should be a pulldown allowing me to match the person right there and then to an existing Person record, while the "State" column should allow me to change their state without leaving this page.

What if we provide only a button like match with Bob Smith<EMAIL_ADDRESS>account (instead of a pulldown) only if there is exactly one matching account and no shortcut otherwise? Is it enough?

When editing a particular TrainingRequest: as soon as the "Accepted" box is ticked, a pull-down should appear to allow the user to assign that person to an upcoming training event.

Could we leave "state" column uneditable and automatically mark a request accepted when you match it with a training?
You propose to add "submit" button at the bottom, so you can change multiple trainees. What if the view was reloaded after clicking at match with Bob Smith<EMAIL_ADDRESS>account button and one more after selecting a training from a drop-down (or clicking explicit submit button at the right side of the drop-down)? That makes implementation much simpler (no need for formsets, validation is much simpler, we don't need JS), but this results in a lot of page refreshes (two refreshes for each request), which may be disruptive.

On 2016-09-18 1:42 PM, Christopher Medrela wrote:

On the page that shows all TrainingRequests, the column title
"Matched Trainee" should be a pulldown allowing me to match the
person right there and then to an existing Person record, while
the "State" column should allow me to change their state without
leaving this page.

What if we provide only a button like |match with Bob Smith
<EMAIL_ADDRESS>account| (instead of a pulldown) only if there
is exactly one matching account and no shortcut otherwise? Is it enough?

A significant number of the matches this time were by name, but with
different email addresses, so I'd strongly prefer the pulldown.

When editing a particular TrainingRequest: as soon as the
"Accepted" box is ticked, a pull-down should appear to allow the
user to assign that person to an upcoming training event.

Could we leave "state" column uneditable and automatically mark a
request accepted when you match it with a training?

Yes.

You propose to add "submit" button at the bottom, so you can change
multiple trainees. What if the view was reloaded after clicking at
|match with Bob Smith<EMAIL_ADDRESS>account| button and one
more after selecting a training from a drop-down (or clicking explicit
submit button at the right side of the drop-down)? That makes
implementation much simpler (no need for formsets, validation is much
simpler, we don't need JS), but this results in a lot of page
refreshes (two refreshes for each request), which may be disruptive.

I'd prefer to be able to do many matches at once.  I realize formsets
are a pain, but all the back-end logic is there (I hope?)
Thanks,
Greg

A significant number of the matches this time were by name, but with
different email addresses, so I'd strongly prefer the pulldown.

AMY searches for an existing account by matching email or name.

So what happens if the name matches but the email address doesn't?  Or
if there are several people with the same name (either distinct
individuals, or because we have two records for the same person and have
only just realized it)?  I strongly prefer a pulldown.

So what happens if the name matches but the email address doesn't?

If there is only one Person record with exactly the same name, AMY suggests this Person (I'm talking about the form in TrainingRequest detailed form where you can match the request with a Person). If there is more than one matching record, AMY doesn't guess and don't propose anything. Should I change the logic there?

Nope, please leave that logic as-is --- I would just like a pulldowns in
the "Matched Trainee" and "Matched Training" columns of
https://amy.software-carpentry.org/workshops/training_requests/ to make
it easier to match and assign lots of people.

Closing this because we have made significant changes in how we accept Training Requests over the past year or two.


Add max-len warning rule

Adds warning when line length exceeds 80 characters, except for the following:

ifs
useState
useReducer
nullish coalescing operator expressions
ternary conditions
string assignment

foo = 'bar'
{ foo: 'bar' }

Note:

The ignoreStrings option was not set because any line including a string is ignored. This means imports are not checked.

I don't know the value of this! what do you think @flaviocastro

A bit redundant if we're going with prettier


Gracefully handle interact spamming

Delete old message before displaying new one, or don't display the new message if it's the same as the old one.

9df7657


Bot refactoring for easier use and updating

PR Summary
Trying to update the github resource management bot so we can see the behaviors more clearly and segmented out, WIP as I mainly want the bot itself to check for syntax issues
PR Context

PR Checklist

[ ] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[ ] Summarized changes
[ ] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[ ] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[ ] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[ ] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:

[ ] Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
(which runs in a different PS Host).

[ ] Issue filed:

[ ] Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.

[ ] Issue filed:

[ ] Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).

[ ] Issue filed:

[ ] Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[ ] Issue filed:

@StevenBucher98 You need to resolve the conflicts.


ZyteApiProvider could make an unneeded API request

In the example below ZyteApiProvide makes 2 API requests instead of 1:
@handle_urls("example.com")
@attrs.define
class MyPage(ItemPage[MyItem]):
    html: BrowserHtml
    # ...

class MySpider(scrapy.Spider):
    # ...
    def parse(self, response: DummyResponse, product: Product, my_item: MyItem):
        # ...

Findings so far:

https://github.com/scrapinghub/scrapy-poet/pull/151 won’t fix this.
This issue seems to be caused by Zyte API provided classes being resolved at different stages. If you request both product and browser_response directly in the callback, a single request is sent. Otherwise, first Product is injected, then MyItem resolves to MyPage, then BrowserHtml is injected. I am not sure yet how to best solve that.

We also thought the solution may involve the caching feature in ItemProvider but didn't imvestigate further.

Indeed.

New finding: Switching MyItem to MyPage works, even if there is still some level of indirection. Could explain why https://github.com/scrapinghub/scrapy-poet/pull/153 works.

This issue also messes up how the ZYTE_API_MAX_REQUESTS setting is computed. PR: https://github.com/scrapy-plugins/scrapy-zyte-api/pull/114
Example code:
from web_poet import WebPage
from zyte_common_items import Product

handle_urls("example.com")
@attrs.define
class MyPage(WebPage[Product]):
    # ...

class MySpider(scrapy.Spider):
    # ...
    def parse(self, response: DummyResponse, product: Product):
        # ...

since WebPage contains a dependency for response: web_poet.HttpResponse, the dependency plan in scrapy-poet's injector would be:
[
    (<class 'web_poet.page_inputs.http.HttpResponse'>, {}),
    (<class 'zyte_common_items.items.Product'>, {}),
    (<class 'my_project.page_objects.MyPage'>,
     {'navigation_item': <class zyte_common_items.items.Product'>,
      'response': <class 'web_poet.page_inputs.http.HttpResponse'>}),
    (<class 'types.FakeCallSignature'>,
     {'page_object': <class 'my_project.page_objects.MyPage'>})
]

The issue here is that scrapy-poet has a "build-as-you-go" mechanism for fulfilling dependencies. This means sending separate requests to fulfill:

HttpResponse
Product

This means we have incremented the scrapy-zyte-api/processed stat for which the ZYTE_API_MAX_REQUESTS relies on (code ref).

I looked into this further and it still occurs without any Page Objects invovled.
Given the following spider:
class BooksSpider(scrapy.Spider):
    name = "books"

    def start_requests(self):
        yield scrapy.Request(
            url="https://books.toscrape.com",
            callback=self.parse_nav,
            meta={"zyte_api": {"browserHtml": True}},
        )

Case 1
✅ The following callback set up is correct since it has only 1 request:
# {"productNavigation": true, "url": "https://books.toscrape.com"}
def parse_nav(self, response: DummyResponse, navigation: ProductNavigation):
    ...

Case 2
❌ However, the following has 2 separate requests:
# {"browserHtml": true, "url": "https://books.toscrape.com"}
# {"productNavigation": true, "url": "https://books.toscrape.com"}
def parse_nav(self, response, navigation: ProductNavigation):
    ...

This case should not happen since browserHtml and productNavigation can both be present in the same Zyte API Request.
Case 3
However, if we introduce a Page Object to the same spider:
@handle_urls("")
@attrs.define
class ProductNavigationPage(ItemPage[ProductNavigation]):
    response: BrowserResponse
    nav_item: ProductNavigation

    @field
    def url(self):
        return self.nav_item.url

    @field
    def categoryName(self) -> str:
        return f"(modified) {self.nav_item.categoryName}"

❌ Then, the following callback set up would have 3 separate Zyte API Requests:
# {"browserHtml": true, "url": "https://books.toscrape.com"}
# {"productNavigation": true, "url": "https://books.toscrape.com"}
# {"browserHtml": true, "url": "https://books.toscrape.com"}
def parse_nav(self, response: DummyResponse, navigation: ProductNavigation):
    ...

Note that the same series of 3 separate requests still occurs on:
def parse_nav(self, response, navigation: ProductNavigation):
    ...

I wonder if some of the unexpected requests are related to https://github.com/scrapy-plugins/scrapy-zyte-api/issues/135.

Re-opening this since Case 2 is still occurring. Case 3 has been fixed though.

@BurnzZ so do you think after your latest analysis that case 2 still happens or not?

@wRAR I can still reproduce Case 2. 👍

OK, so the difference between this use case and ones that we already test is having "browserHtml": True in meta. Currently the provider doesn't check this at all. It looks like it should? cc: @kmike

OTOH I'm not sure if even we handle this in the provider the request itself won't be sent?

@wRAR Let's try to focus on how Case 2 (or any of these cases) affect https://github.com/zytedata/zyte-spider-templates, not on the case itself. The priority of supporting meta is not clear to me now; it may not be necessary in the end, or it could be.

I've been working on converting a (working but incomplete) spider from using HttpResponse to BrowserResponse and seem to be getting bit by this bug and I have yet to come up with a satisfactory workaround. I believe my scenario is basically case #3 above but since i'm not using zyte-spider-templates the above referenced fix doesn't apply.
Here's an attempt to simplify what I'm seeing:
class BooksSpider(scrapy.Spider):
    name = "books"
    parse_my_book_page = callback_for(MyBookPage)

    def start_requests(self):
        yield scrapy.Request(
            url="https://books.toscrape.com",
            callback=self.parse_my_book_page,
            meta={"zyte_api": {"browserHtml": True}},
        )

@handle_urls("")
@attrs.define
class MyBookPage(ItemPage[MyItem]):
    response: BrowserResponse

    @field
    def url(self):
        return self.response.url

    @field
    def something(self): -> str
        return len(self.response.raw_api_response.get('browserHtml'))

This always triggers two requests to zyte api.
You can replace the meta={"zyte_api": {"browserHtml": True}}, line with any other documented method for requesting browserHtml and you will still always end up with 2 browserHtml requests as ZyteApiProvider doesn't make any attempt to check that it already has a response that can function as a valid BrowserResponse.
If you drop the browserHtml flag completely you'll still get 2 requests, one http and one browser.
Since ZyteApiProvider does allow an HttpResponse to fulfill an AnyResponse dependency, I thought I could trick it with this hack but that fails (understandably) with this error got multiple values for argument 'response'. And this approach would be very unintuitive if it did work.
def parse_my_book_page(self, response: HttpResponse, page: MyBookPage):
    yield page.to_item()
...
class MyBookPage(ItemPage[MyItem]):
    response: AnyResponse

Am I going about this the wrong way? Should I be doing something other than yielding my own browserHtml request? The second generated request is correct and does what I want (including the more complex actions and network capture that my real world scenario requires) but I don't see how to avoid the initial unnecessary request. Maybe I should go study the zyte-spider-templates code a little closer to see if I can lift that into my case without using the template.

After some more thought, I've found a successful albeit ugly workaround. By providing my own provider for BrowserResponse at a higher priority than ZyteApiProvider, I can avoid the code that generates the second request.  This makes some strong assumptions that won't generalize well but it works well enough for my use case for now until someone proposes a better solution.
class BrowserResponseProvider(PageObjectInputProvider):
    provided_classes = {BrowserResponse}

    def __call__(self, to_provide: Set[Callable], response: Response) -> Sequence[BrowserResponse]:
        browser_html_str = getattr(response, "raw_api_response", {}).get("browserHtml") or response.body
        return [BrowserResponse(url=response.url, status=response.status, html=BrowserHtml(browser_html_str))

I think in your case the right approach is:
class BooksSpider(scrapy.Spider):
    name = "books"

    def start_requests(self):
        yield scrapy.Request(
            url="https://books.toscrape.com",
            callback=self.parse_my_book_page,
        )

    def parse_my_book_page(self, response: DummyResponse, page: MyBookPage, _response: AnyResponse):
        yield page.to_item()

@handle_urls("")
@attrs.define
class MyBookPage(ItemPage[MyItem]):
    response: BrowserResponse

    @field
    def url(self):
        return self.response.url

    @field
    def something(self): -> str
        return len(self.response.raw_api_response.get('browserHtml'))

i.e.:

Remove the request meta, and set the callback response parameter to DummyResponse, so that requests are only sent through dependency injection, and not also through regular Scrapy mechanisms.
Request the response in the callback signature with a different parameter (the first, response parameter is special and cannot be used for dependency injection). You can use AnyResponse in the callback to get whatever the page object dictates, and let the page object be the one forcing browser for the target URL and output type.


KORE Translation: impure functions

This is referring to things like doing IO as functions.

This needs significant design work because doing things like impure function operations will probably never have an actual meaning in Kore. Doesn't mean we can't do it, but we need to do it carefully.

Nothing currently requires this though, so low priority.


Missing Setups

Todo list of must to have configurations:

[ ] Using passport for authentication schemes
[ ] Support dotenv for reading and injecting vars
[ ] DB's connection support (starting with NoSQL MongoDB)
[ ] Workflow for publishing tagging, versioning, and publishing to npm with Github actions.

@mohanagy add label discussion to this issue
so we can iterate and convert the things we should have into tasks to be worked on


Microsoft teams?

Are you going to implement in the near future the option to download videos from Microsoft Teams too? (Is it somewhat possible?) Thanks in advance!

Aren't those recordings already on MS Stream?

Aren't those recordings already on MS Stream?

No, it's actually not. Some videos can't be played in Microsoft Stream. I've tried a couple of times before, no success. I only have the Microsoft Team Link to the video, and even changing it to a Microsoft Stream URL (with the ID) won't let me download the video.
How can I download videos from Microsoft Teams? (if this is already possible)

Exactly, not all videos are available in Microsoft Stream.
https://teams.microsoft.com/l/meetup-join/19%3Ameeting_YWJiZGY1ODYtNDE1Ny00MDM5LWJmMTYtNDA3Y2FiZTgxYTMz%40thread.v2/0?context={"Tid"%3A"4f0132f7-dd79-424c-9089-b22764c40ebd"%2C"Oid"%3A"64979a43-443e-4edc-87b2-74dd8ff11f2d"%2C"IsBroadcastMeeting"%3Atrue}
This video is an example.

Sorry, i don't know how that works, could be MS Teams hosting property. This is out of scope for destreamer.

@alessandrotodisco Did you by any chance find a solution on how to download those kinds of videos? I'm having the same problem now and I can't figure anything out other than using a screen recorder :/

@Olgabrezel Unfortunately no. The only boring solution I found is by using a screen recorder..

@Olgabrezel @alessandrotodisco I'm sorry that I can't help you but I have no such video at my disposal to do some reverse engineering and tell you if and how to download them :/

@lukaarma It would be so awesome if you could try that! For such a video - the link that alessandro posted above works for me. I just logged in on Microsoft and chose to participate anonymously and the video loaded. So perhaps you could use that for testing?

did the deed, I reversed the platform logic and lo and behold I have the url of the video and the auth token
BUT
the video is streamed using SmoothStreamingMedia, proprietary format of Microsoft. I have to do some more digging to find a good and working downloader for that but in the meantime I leave these here
SOURCE => videojs.getPlayers().teamsDefaultPlayer.options_.sourceList.slice(-1).pop().src

AUTH => document.cookie.match(/TSAUTHCOOKIE=(.*?);/)[1]

FFmpeg may be able to download SmoothStreaming as is. If it's not i believe we can form an HLS URL out of it, i highly doubt they only publish a SS stream. Can you post the manifest URL (censored) so i can have a look?

Ffmpeg doesn't parse SS playlists
I tried getting the hls as we do in Destreamer with (format= hls.codeword.thatIdontRemember) at the end of the URL instead of (format=SS.thatIdontRemember) but no dice the server doesn't have the encoding
As soon as I'm on my pc I'll send you an email with links and the SS playlist I was able to download
As per converting to HLS it should be quite easy with a smal script so I'll look into that

Keeping this open so that maybe we don't get duplicates

@snobu You said that this is out of scope for Destreamer, so if Iwanted to implement this I should do it in another tool? Or can I try and implement it here?

@lukaarma I would never say no to a PR if you implement that. However i would probably wait until we learn more about the SharePoint/OneDrive MSStream vNext thing, since it may affect how Teams saves recordings.

@lukaarma Have you abandoned this idea?

Responding to the musings above about someone muddling through this process by hand and describing what they found:
I played one of these public Microsoft-Teams-hosted videos in a web browser while capturing packets and eventually figured out how to get a plain .mp4 of the stream contents (no screen-recording or re-encoding). Steps:

The root of most of this is the 'manifest' request.  It had a URL like https://endpoint1-blah.blah.blah.blah.office.net/11111111-2222-3333-4444-555555555555/66666666-7777-8888-9999-aaaaaaaaaaaa.ism/manifest(format=mpd-time-csf)

Per Den Delimarsky's advice, you can change the format=mpd-time-csf part to format=m3u8-aapl-v3 to get the same stream metadata in HLS/m3u8 format instead of the MPEG-DASH XML format.  I don't think this is necessary, but this is the path I took, so I mention it here in case it was important.  ffmpeg supports both formats.  This change also had the effect of giving me one mp4 stream with both audio and video instead of separate audio and video streams.

The top-level manifest offers  multiple URLs for different quality levels.  They're something like https://endpoint1-blah.blah.blah.blah.office.net/11111111-2222-3333-4444-555555555555/66666666-7777-8888-9999-aaaaaaaaaaaa.ism/QualityLevels(128000)/Manifest(audio,format=m3u8-aapl-v3) and they're full of entries like Fragments(audio=12345678999,format=m3u8-aapl-v3).
Here's where the problems start:

Problem: Tools that read this fragment-list combine the fragment names and the base URL in a different way than the server expects.  ffmpeg looks for the fragments at the URL

https://endpoint1-blah.blah.blah.blah.office.net/11111111-2222-3333-4444-555555555555/66666666-7777-8888-9999-aaaaaaaaaaaa.ism/QualityLevels(128000)/Manifest(audio,format=m3u8-aapl-v3)/Fragments(audio=12345678999,format=m3u8-aapl-v3)
but the server serves the file at the URL
https://endpoint1-blah.blah.blah.blah.office.net/11111111-2222-3333-4444-555555555555/66666666-7777-8888-9999-aaaaaaaaaaaa.ism/QualityLevels(128000)/Fragments(audio=12345678999,format=m3u8-aapl-v3)
Note the missing Manifest(...) penultimate path component.

Problem: The line breaks in the fragments list are \r\n and sometimes ffmpeg breaks lines by \n, leaving the \r on the end of the URL, which the server rejects as 400.

Problem: The server responses with the fragments of video data have a content-type: video/mp2t (or audio/mp4 and video/mp4 for the mpd-time-csf/MPEG-DASH streams) header and no Content-Encoding header.  But the contents are actually AES-128 encrypted.
ffmpeg attempts to support this!  Invoking ffmpeg on the manifest URL directly results in it muttering about crypto+https://... URLs, so it knows it needs to decrypt something, but it isn't able to find the key.  Even after I separately extracted the key and was able to provide it to ffmpeg directly on the command line, I was unable to get ffmpeg to play the encrypted fragments, sometimes with silly results like ffmpeg trying to aes-decrypt the text file that lists the fragment names and then failing to parse it.

Anyway, I just fetched and then concatenated all the Fragments.
(Concatenate first. Concatenate-then-decrypt worked.  Decrypt-then-concatenate did not work.)

From the packet capture, I observe that the browser got the decryption key from a no-body POST to https://blah.keydelivery.blah.media.azure.net/?KID=bbbbbbbb-cccc-dddd-eeee-ffffffffffff, which returns a 16-byte body that is the decryption key.  This link is in the MPEG-DASH manifest as keyUriTemplate.  The browser sends a HMACSHA256 Bearer Authorization header, and I get 401 if I don't send one.

It looks like this token comes from an earlier request to https://prd.attend.teams.microsoft.com/teams/66666666-7777-8888-9999-aaaaaaaaaaaa/bbbbbbbb-cccc-dddd-eeee-ffffffffffff/19:meeting_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxx@thread.v2/0?role=Attendee, and all those fields were in the stream-viewing/'meeting-invite' link.

The MPEG-DASH manifest also has the decryption IV.

With the key, iv, and concatenated fragments, I can now decrypt the stream: openssl enc -d -aes128 -iv<PHONE_NUMBER>1111112222222233333333 -K<PHONE_NUMBER>5555556666666677777777 -in allthefragments -out stream.mp4

Again, these are public videos—nothing here bypasses any access controls. These are just the details of how Microsoft Teams implements public videos: By serving them encrypted and then offering the key to anyone that asks.

Could you please elaborate what you did from step 3 and forward? I have the KID, Bearer, Issuer, HMACSHA256, response from the keydelivery and I think all the components but I can't get it to work; how do I concatenate the streams for example? ffmpeg refuses to do anything with the crypto+https-URLs and Google is worthless when trying to find anything with a plus sign :/

how do I concatenate the streams for example?

cat * > out


Add s390x support

This PR adds support for building on s390x architecture.

The related issue: https://github.com/longhorn/longhorn/issues/3733

@thomasferrandiz Please help rebase from the master because of the recent BCI introduction. Thank you.

PR rebased on master to take into account the BCI migration.

Also the problem of missing docker volume in the drone s390x pipeline is fixed in the updated PR.


bionic stemcell. grafana startup freeze

Testing

prometheus bosh release
bionic stemcell 0.19

We observe grafana start freeze (post-start)

Hi there,
seeing same issues with bionic stemcell 0.24

Seems the nc command checking the open grafana port is the culprit:
broker/801ac959-c4b5-4251-a4be-fd823f32355e:/var/vcap/sys/log/grafana# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root      5880   704  0 Apr19 ?        00:00:00 bash /var/vcap/jobs/grafana/bin/post-start
root      5887  5880  0 Apr19 ?        00:00:00 bash /var/vcap/jobs/grafana/bin/grafana-admin-password
root      5891  5887  0 Apr19 ?        00:00:00 nc <IP_ADDRESS> 3000

broker/801ac959-c4b5-4251-a4be-fd823f32355e:/var/vcap/sys/log/grafana# nc -vz <IP_ADDRESS> 3000
Connection to <IP_ADDRESS> 3000 port [tcp/*] succeeded!

broker/801ac959-c4b5-4251-a4be-fd823f32355e:/var/vcap/sys/log/grafana# nc  <IP_ADDRESS> 3000
=> freeze

Yes, that is was I also just found out... currently trying to figure out why this is happening because a curl on http://localhost:3000 is working fine

So it seems like
nc <IP_ADDRESS> 3000 < /dev/null
is behaving differently on Xenial and Bionic. For Xenial it immediately returns, for Bionic it does not. This approach was apparently applied to fix issues with cent os.

We could adjust the following line
https://github.com/bosh-prometheus/prometheus-boshrelease/blob/9cccf9494a86b0b2420b5d9dd086397cbecf7c72/jobs/grafana/templates/bin/grafana-admin-password#L8
to look like the following
 if nc -w 5 <IP_ADDRESS> <%= p('grafana.server.http_port') %> < /dev/null; then


Style Update - Fallout V&D

Submission Checklist
Required

[ ] The pull request title clearly contains the name of the sheet I am editing.
[ ] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[ ] The pull request makes changes to files in only one sub-folder.
[ ] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: <   >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: <   > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: <   > (i.e. Dungeons & Dragons, FATE)

[ ] I have followed the Character Sheets Standards when building this sheet.

[ ] I have authorization from the game's publisher to make this an official sheet on Roll20 with their name attached.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description
All styles were removed from the HTML and moved to the CSS. We are still using some legacy.

Character Sheet Info Roll20 Internal Use only.


[SPARK-47993][PYTHON] Drop Python 3.8

What changes were proposed in this pull request?
This PR proposes to drop Python 3.8 in PySpark.
Why are the changes needed?
Python 3.8 is EOL in this October (https://devguide.python.org/versions/). Assuming from the release schedule for Spark 4, I think it's better to drop it now before we do it after branchcut, etc.
This also fixes the broken scheduled build (https://github.com/apache/spark/actions/runs/8818780802)
Does this PR introduce any user-facing change?
Yes, it drops Python 3.8 support.
How was this patch tested?
The changes will be tested through CI.
Was this patch authored or co-authored using generative AI tooling?
No.

BTW, I have two comments.

We need a vote for this because it's still alive, @HyukjinKwon .
I'm not sure ModuleNotFoundError could be the reason of dropping a Python version. Do we have any other reason which bans Python 3.8?

https://github.com/apache/spark/actions/runs/8802717653/job/24159244287

ModuleNotFoundError: No module named 'zoneinfo'

+1 for dropping Python 3.8 support

Could you take a look at the CI failure, @HyukjinKwon ?

zoneinfo is new to Python 3.9. It seems something in the build expects Python 3.9 or newer.
Looks like it's this line, which was added in #46122 a few days ago.

Will fix all up soon.


OS X Inotify watcher not working

Using OS X El Capitan.  Tail.Lines is open, but nothing ever comes out.  I've poked around with various options to see if I can get it working, but nothing ever works unless I use Poll: true in the Config passed to TailFile.  I'll try and open a PR with a failing test sometime in the next week or two.

I'm using OSX El Capitan and haven't had any issues. @binary132 can you reproduce it in a small snippet of code?


postgres_ffi/wal_generate: add last_wal_record_xlog_switch and use it in tests

Based on #1989, it should be merged afterward.
Fixes #1190: if I use the old version of WalDecoder locally, the new test test_wal_generate[last_wal_record_xlog_switch] fails. Now it passes.
Uncovers and fixes #1991 as well. The new test test_wal_generate[last_wal_record_xlog_switch_ends_on_page_boundary]  fails if I do not process padlen > 0 first.

@hlinnaka Would you mind checking whether it tests/fixes https://github.com/neondatabase/neon/issues/1190 as you'd expected?

Yep, looks good to me, thanks!

@arssher Added some comments in the generate_last_wal_record_xlog_switch_ends_on_page_boundary function, should address all of your comments.


Move away from Printf

Replace Printf usage with status Queues in subctl
Signed-off-by: Janki Chhatbar<EMAIL_ADDRESS>Colour code for WARNING:

@Jaanki can you handle comments and rebase/fix conflicts on top of master? CI is fixed, but you will need to rebase.


Banking management system in CPP.

Description
I'm a GSSoc22 contributor. I'm looking to create a pull request regarding a small mini-project that is a bank management system. I don't find anywhere in this repo whether projects are allowed or not but it is in the CPP domain.  So I'm making this issue.
Idea behind the project
Like we often visit banks for any reason so there we observe that hoe banks are dealing with the customer accounts.  Thought and ideas are from there only.
How does it works
This is a project that covers domain topics of CPP. It is a combination of file handling IO and a vast stretched area of classes and objects and other stuff also.
After running the program there will be an interface with multiple option
some of which are listed below area as:

Show my record.
add my records.
last balance transfer.

Most important it will handle all database history with file handling only.
this is all about my project.
Thanks...

Domain
CPP
Type of Contribution
No response
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

/assign

Hey buddy did you mean, can I start working on the issue.


Vector reflect() issue

The documentation isn't very clear but it seems odd that if I want to reflect a vector v that I have to do normal.reflect(v) instead of v.reflect(normal). Is that intended or is it a bug?
This affects both Vector2 and Vector3 in the same way (and the slide() function as well). Here's some GDScript to show the "problem":
    var v = Vector2(1,1)
    var normal = Vector2(1,0)
    var reflect = v.reflect(normal)
    print(reflect) # -1,-2 but expected -1,1
    var reflect = normal.reflect(v)
    print(reflect) # -1,1 is correct

Eh. The more I've thought about this, the less it matters to me. I'm inclined to just update the documentation to make it clear how it works.

Fixed by https://github.com/godotengine/godot/issues/8201


docs: Add a bunch of documentation on Travis CI.

@adnrs96 @gnprice I'd love a review on this for clarity!

it seems like you use two spaces between sentences often.

Yep, that's what I learned in school (it was the standard taught in America at the time).  It's possible I should evaluate investing time to change my habits on this front.

Just sent a bunch of comments! This will be useful -- most of all, I think, the comments in the scripts and config.
Zooming out a bit: what are the intended uses of this document? It seems like a mix of developer docs and user docs, for users of Travis-for-Zulip. It'd probably be worth concentrating the user docs together so that people can read them without going through the developer docs. E.g., the "sign up your personal repo" bit, and maybe a section like "Reading Travis CI output" that discusses the setup/run structure and the hiding of output.

I pushed an updated version, that also features attempts to remove some of the code in .travis.yml that I think we can delete.
Regarding purpose, this is intended primarily for developers working on our Travis CI setup who might want to know how it works.  I agree we should do some sort of extraction of the stuff useful to folks who don't care how it works to the top, though.
BTW @umairwaheed FYI, is there anything I'm missing?  I guess we should mention coveralls?
Four follow-up issues to open:

Extract "Using Travis" section to top of Travis CI doc.
Make our ts stuff run unconditionally in Travis.
https://github.com/zulip/zulip/pull/5247#discussion_r120453159
https://github.com/zulip/zulip/pull/5247/files/65d39fb8997579afc4556a5133c8ed36a1704350#diff-8316f2fc56945c1095b64113e0fb0096

OK, I think I've addressed all the comments either in the form of an issue or just changing the docs.  Merged, thanks everyone for the reviews!  I expect we'll want to do several of those in the near term.

BTW @umairwaheed FYI, is there anything I'm missing? I guess we should mention coveralls?

Yep, and the hooks that we call for Coveralls and Zulipbot. The Coveralls hook is used because we are using parallel builds. When a sub-build finishes it lets Coveralls know that it has finished.


[Tabs] Fix an edge case where children and value props change

[ ] PR has tests / docs demo, and is linted.
[x] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[x] Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

Update the Tabs component getTabs method to accept a conditional parameter of props (default value is this.props) which will then use that props to iterate over the children. Also changed the getSelectedIndex method to pass the props it receives in its parameters to getTabs. This solves and edge case where, in componentWillReceiveProps, the Tabs component receives a new active tab as well as a new set of tabs (props.children). Since this passes in newProps to getSelectedIndex, this will use the newProps.children (new tabs if they have changed) value over this.props.children (old tabs).
Closes #4633.
Closes #5118.
Closes #5156.
May closes #4860 too.

Any chance someone could review this? It's only a 3 line change after all, and this scenario doesn't seem that far-fetched to me, especially in the context of using tabs for routing.

@mike-robertson Thanks for taking the time to dig into this issue 🙈  !
The fix looks good to me. I have only one concern. We miss a unit test.
Do you have the time to work on it? (some tips)
Otherwise, I can take care of it.

Yea I can write a unit test for it, I'll probably have some time this weekend to look it over.

@mike-robertson If you don't have time to write some unit test for this, I can do it.

I just started a couple, but if you'd rather I won't complain. I noticed there is no coverage for this component so I'm not sure if I should just test what I changed which doesn't feel right.

@mike-robertson Right, let's get this component some proper test coverage.


Xcode 7 Project WindowsAzureMobileServices.framework bitcode enabled

I am trying to update my iOS app to make it compatible with Xcode 7/iOS 9 and I get this build error:
WindowsAzureMobileServices.framework/WindowsAzureMobileServices(MSDateOffset.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The WindowsAzureMobileServices framework needs to be rebuilt with bitcode enabled in the build settings.
This is extremely urgent...please update your iOS framework as soon as possible.

We will take a look at getting a build & release done. In the meantime, you can clone this repo and should be able to run bash build.command and get a framework generated for you.  (After making the necessary edit to the proj)

Thanks!


As CS student who doesn’t want to type the absolute path, I can tag file with relative path, so that I can tag my files easily.

CS student who doesn’t want to type the absolute path
Tagging file with relative path
Tag my files easily

Done


Please document the exact SHA of atd in use

I've recently upgraded bs-atdgen-codec-runtime & atd and the code generated from master atd doesn't work anymore.
  We've found a bug for you!
  /home/tim/src/pt/all/swage/web/src/Types_bs.ml 121:39-84

  119 │ )
  120 │ let write_zt_network = (
  121 │   Atdgen_codec_runtime.Encode.adapter Atdgen_runtime.Json_adapter.Typ
        e_field.restore (
  122 │     Atdgen_codec_runtime.Encode.make (fun (t : zt_network) ->
  123 │       (

  The module or file Atdgen_runtime can't be found.
  - If it's a third-party dependency:
    - Did you list it in bsconfig.json?
    - Did you run `bsb` instead of `bsb -make-world`
      (latter builds third-parties)?
  - Did you include the file's directory in bsconfig.json?

Can you give the exact version of atd you are using? And a small example to reproduce? I am a bit surprised, because we are using the master version of atd with bs-atdgen-codec-runtime 1.1.0 too and no problem here.

I'm using master (today) of atd with bs-atdgen-codec-runtime 1.1.0

Ahha! I had a  in my atd file (old style)

Even though I figured out my mistake, it still might be handy to note which version of master goes with each release (while we are in this state of limbo where atd isn't released yet.)

Glad to know it works for you. You are right, I will add a note about which atd version we know is working.


Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Unable to complete login process due to delay in opening server connection.

Not saying this is a bug, but perhaps it's worth troubleshoot

  test-mssql:
    runs-on: windows-2022
    steps:
      - uses: actions/checkout@v3
      - name: Install a SQL Server suite of tools
        uses<EMAIL_ADDRESS>        with:
          install: localdb

Connection in separate check step works fien
      - name: Check
        run: |
          Get-OdbcDriver -Platform 64-bit | Select-Object -ExpandProperty Name
          sqlcmd -S "(localdb)\MSSQLLocalDB" -Q "SELECT @@VERSION;"

p.s Thanks for this action!

Hi,
I've the same error. Do you find how to fix it?
Thanks,

I forgot about this report. Well, it looks like the password is required on Windows.
Here is what works for me:
https://github.com/nanodbc/nanodbc/blob/62c27ec71842302a6fa28efc59637515441706c1/.github/workflows/ci-windows.yml#L123-L130

@Max84 I completely forgot about this issue. Well, it looks like explicit credentials are required and no implicit Windows authentication is possible. Here is what I do and what works:
https://github.com/nanodbc/nanodbc/blob/012d9d196dcf6d81d9e2ff20c5022bb8c5136a59/.github/workflows/ci-windows.yml#L123-L134
   - name: Install SQL Server
      uses<EMAIL_ADDRESS>      with:
        install: localdb
        sa-password: Password!123
        version: ${{ matrix.mssql }}
    - name: Check
      run: |
        sqlcmd -S "(localdb)\MSSQLLocalDB" -U sa -P "Password!123" -Q "SELECT @@VERSION;"


fix Issue 10378 - Local imports hide local symbols

This is a fix of https://issues.dlang.org/show_bug.cgi?id=10378 and a reboot of https://github.com/D-Programming-Language/dmd/pull/4915
It requires https://github.com/D-Programming-Language/phobos/pull/3989
This version is based on a comment Andrei made to me a long time ago about it. Symbol lookup is now done in two passes (formerly one). The first pass goes up through the scopes, checking everything but imported modules. If that fails, the scopes are gone through again, checking only imported modules.
This algorithm:

retains the scoped nature of nested imports, i.e. names in nested imports will hide outer imported names
works the same for function locals as it does for struct members, which was my complaint about #4915
does not issue errors for shadowing - it simply finds the shadowed symbol first.
breaks existing code. Turns out that people did rely on it. See https://github.com/D-Programming-Language/phobos/pull/3989
is pretty simple. (the large number of lines of code changed is mostly due to debugging and printing code which I'll remove once it passes the autotester
exposed a bug in the way the compiler is implemented, see https://github.com/D-Programming-Language/phobos/pull/3989 for that, too. I'm sure there'll be other instances in the wild of this.
it should only be a hair slower, as it never looks in the same hash table twice

Looks like I #deadalnix proposed this algorithm here:
https://issues.dlang.org/show_bug.cgi?id=10378#c9

Yes, that's how it needs to be !

hmm, why isn't the autotester running on this?

Needs this Phobos fix:
https://github.com/D-Programming-Language/phobos/pull/3990
Folks, this language change is clearly going to break existing code.

nice work!

Auto-merge toggled on

When this is merge, I think we need a doc change too.

Auto-merge toggled off

I want to review this.

@WalterBright : Also I give you a chance to remove debugging code from this PR.

@WalterBright : Is there any chance we get a deprecation for the old behaviour ?
I agree that is the right direction to go, and that old code relied on a bug. However, that code was not necessarily broken / buggy, which is why I don't think breaking it without a proper deprecation is okay.

The most of PR summary needs to be copied into commit log, no?

Excepting my comments, the implementation itself looks good to me.

@Geod24 Nice question. Walter, how do you think about deprecation notification?

Re: deprecation, is there a way to have a compiler switch to invoke the old behavior? Then you deprecate the switch.

I'd ask about the new symbol lookup rule definition and its implementation, with following two cases:
// case 1
template Mix2()
{
    mixin Mix1!();
    import baz; // imports x
}

template Mix1()
{
    import bar; // imports x
}

import foo;     // imports x

void main()
{
    {
        mixin Mix1!();
        auto y = x;     // foo.x, or bar.x?
    }
    {
        mixin Mix2!()
        auto y = x;     // foo.x, bar.x, or baz.x?
    }
}

// case 2
import foo;     // imports x

class B
{
    import bar; // imports x
}
class C : B
{
    void test()
    {
        auto y = x;     // foo.x, or bar.x?
    }
}

For case 1, does this PR make a result that you expect?
For case 2, the lookup path is branching. For that case, is the new lookup rule properly defined, and is it well implemented?

The travis Cl build failure is due to it not merging D-Programming-Language/phobos#3990

Regarding case 2, this is what should be correct behavior:
module imp1;
enum X = 1;
enum Y = 1;

module imp2;
enum X = 2;
enum Y = 2;

import imp1;
enum X = 0;

class B {
    import imp2;
    static assert(X == 0);
    static assert(Y == 2);
}
class C : B {
    static assert(B.X == 0); // Error: no property 'X' for type 'foo.B'
    static assert(B.Y == 2); // Error: no property 'Y' for type 'foo.B'

    static assert(X == 0);
    static assert(Y == 1);
}

This is not what it does now, I'll have to fix.

deprecation notification?

Good question. I'd really rather not, as it could make things very confusing. I'd rather see first what the beta period says.

Regarding case 2, this is what should be correct behavior:
...
This is not what it does now, I'll have to fix.

Make sense. I'll wait your fix.

Sadly, this is adding a lot of special cases to the code. When you think about it, what seems "intuitive" to programmers is anything but logically consistent.

Implementing what looks simple, case 2, and compiling Phobos results in:
std\regex\internal\parser.d(1430): Error: None of the overloads of '__ctor' are callable using argument types (Regex!char*),
candidates are:
std\regex\internal\ir.d(229):        std.regex.internal.ir.Bytecode.this(IR code, uint data)
std\regex\internal\ir.d(235):        std.regex.internal.ir.Bytecode.this(IR code, uint data, uint seq)
std\regex\internal\parser.d(1435): Error: cannot implicitly convert expression (__withSym) of type Regex!char* to uint
std\regex\internal\parser.d(1435): Error: cannot implicitly convert expression (__withSym) of type Regex!char* to uint
std\regex\internal\parser.d(1436): Error: function expected before (), not 1u of type uint
std\regex\internal\parser.d(1444): Error: function expected before (), not enforce(__withSym, delegate const(char)[]() => nul
l, "std\\regex\\internal\\parser.d", 1444u) of type Regex!char*
std\regex\internal\parser.d(1449): Error: cannot implicitly convert expression (__withSym) of type Regex!char* to uint
std\regex\internal\parser.d(1449): Error: cannot implicitly convert expression (__withSym) of type Regex!char* to uint
std\regex\internal\parser.d(1453): Error: cannot implicitly convert expression (__withSym) of type Regex!char* to uint
std\regex\internal\parser.d(1458): Error: cannot implicitly convert expression (__withSym) of type Regex!char* to uint
std\regex\internal\parser.d(1468): Error: cannot implicitly convert expression (__withSym) of type Regex!char* to uint
std\regex\internal\parser.d(1469): Error: constructor std.regex.internal.kickstart.Kickstart!char.ShiftOr.this (ref Regex!cha
r re, uint[] memory) is not callable using argument types (Regex!char*)
std\regex\internal\parser.d(25): Error: template instance std.regex.internal.parser.lightPostprocess!char error instantiating

std\regex\internal\parser.d(1399):        instantiated from here: makeRegex!string
std\regex\package.d(324):        instantiated from here: Parser!string
std\regex\package.d(316):        instantiated from here: regexImpl!string
std\regex\package.d(333):        ... (3 instantiations, -v to show) ...
std\net\curl.d(425):        instantiated from here: recvReq!char
std\net\curl.d(424):        instantiated from here: __lambda1!(Socket)
std\net\curl.d(424): Error: function std.net.curl.TestServer.handle (void function(Socket s) dg) is not callable using argume
nt types (void)
std\net\curl.d(489): Error: function std.net.curl.TestServer.handle (void function(Socket s) dg) is not callable using argume
nt types (void)
std\net\curl.d(553): Error: function std.net.curl.TestServer.handle (void function(Socket s) dg) is not callable using argume
nt types (void)
std\net\curl.d(935): Error: function std.net.curl._basicHTTP!char._basicHTTP no return exp; or assert(0); at end of function

I can make no sense of this. Worse, how do we expect users to deal with the changed lookup rules?

Coming from another language that changed it's lookup rules.  Generally it's always hell to make the switch in existing codebases.
Maybe for catching errors early we could have the following (in pseudocode)
s = lookupSymbol (sym);
if (s is null)
{
    sx = lookupSymbolOld (sym);
    if (sx && global.transition10378)
        error("lookup rules has changed for sym
            Before: sx
            After: not found");
    s = sx;
}

Needs this Phobos change, too:
https://github.com/D-Programming-Language/phobos/pull/3993

I finally found what the tribble was.

Looks like there's another one in std.stream

Looks like there's another one in  std.stream

and another fix:
https://github.com/D-Programming-Language/phobos/pull/3994

Auto-merge toggled on

Please stop merging giantic changes w/o review.

breaks existing code. Turns out that people did rely on it. See D-Programming-Language/phobos#3989

I'm running into the same issue w/ #5426, we can under no circumstances just break this code. Please add a deprecation for the old behavior.

does not issue errors for shadowing - it simply finds the shadowed symbol first.

And another breaking change, this one being the main point of the change.
For a transition period you'll have to perform both lookups and issue a deprecation before we can switch the behavior.

perform both lookups

Not so easy.

double lookups mean half speed
look at all the changes - adding a runtime switch to all of them?

@MartinNowak since you're online at the moment, please take a look at https://github.com/D-Programming-Language/phobos/pull/3994 as it is blocking this.

double lookups mean half speed

If it helps, you only need to lookup to the same scope level.
But the more important question is half speed of what? Do you think symbol lookup is actually a performance problem?

look at all the changes - adding a runtime switch to all of them?

A runtime switch doesn't solve the problem that this will break a lot of code.

See D-Programming-Language/phobos#3989

Why does this PR affect the behavior of import std.zlib : compress; std.zlib.compress();, when std is available from some other scope?

Do you think symbol lookup is actually a performance problem?

Yes. It's usually in the short list of top time consuming compiler activities. There's even a note to that effect in the search code.

Why does this PR affect the behavior of  [...]

There are explanatory comments in the Phobos PR.

You could keep the old mixed lookup behavior for now, and if it finds a symbol from an import, look in outer scopes for a local only symbol. The overhead should be very small b/c you're only searching a few scopes.

the problem that this will break a lot of code.

Some relevant points:

There was a lot of demand for this change, and some fairly bitter complaining about the existing behavior.
There was justification in the complaints, in that benign additions to one module can maddeningly and unpredictably break other modules. I.e. modules were not 'hygienic' and that breaks part of D's mission.
Changing this behavior exposed compiler lookup bugs that existing code was (likely inadvertently) relying on.
Fixing the broken code has turned out to be rather easy, even for code I was not familiar with. My rant above turned out to be a bug in the compiler that took me several hours to track down.
I think the fixes to Phobos have all made the code (slightly) better. Symbol lookup should not rely on byzantine threads through who knows what.

You could keep the old mixed lookup behavior for now, and if it finds a symbol from an import, look in outer scopes for a local only symbol. The overhead should be very small b/c you're only searching a few scopes.

Lookup is nowhere near that simple, as I discovered. Take a look at the new fail_compilation test case I added. Furthermore, the compiler does not keep track of the path it took to find a symbol, so a fair bit of logic and data would have to be retained for your idea to work.

Pls turn the automerge back on for https://github.com/D-Programming-Language/phobos/pull/3994 as I want to get this PR passing the autotester.

@WalterBright I think it is already clear that this will break a lot of code.
You could try using this compiler with dub, vibe.d, or some older codebase (undead?).
The additional lookup cost would be there for only one or two release, and could be removed afterwards. It might not sound ideal, but it is better than breaking a lot of code that's out there.
As for the question of breaking changes, I'd like to point out Don's 2013 talk about cost / benefit (up to 36m).
Fixing module imports bug definitely brings value long-term. However, the unpleasant effect of this bug (your point 2, about benign addition(s)) happens during developement. Which means all the immediate benefit of this change goes to code that to be written, while all the cost goes to existing code.

Not that bad actually.

Before
After

The error messages are pretty poor though.
Error: function dyaml.emitter.FastCharSearch!("\x0a\x85\x28\x20\x29\x20"d, 256u).canFind (const(dchar) c) is not callable using argument types (EventID[], const(EventID))
Error: template instance TagId!(TestStructure.optional_string) template 'TagId' is not defined

Let's please get rid of the bad habbit to break code for the greater good, w/o even trying hard enough to avoid breakage.
I haven't seen anything where deprecation wasn't possible (except where lacking deprecation support from the compiler), and I'm quite confident that w/ a bit more thought, we'll find a way to turn this change into a smooth transition.
In the meantime I have a concise, non-breaking fix for 313, can we get that in first?
https://github.com/D-Programming-Language/dmd/pull/5426

This is missing a changelog entry btw.

Does the new lookup rule also affect to UFCS symbol search? It's handled insearchUFCS function today.

Some relevant points:

No need to argue for this change, I'm all for it. It's just that the change could be done better.

Furthermore, the compiler does not keep track of the path it took to find a symbol, so a fair bit of logic and data would have to be retained for your idea to work.

It shouldn't be that hard, you'd prolly have add a few LOC here.
How about changing the out parameter of Scope.search from ScopeDSymbol to Scope and turning the flags parameter of Dsymbol.search to ref so you can set a mark when it crosses an import.
Then if a symbol was found in an import, you can search the rest of the scope chain for sth. hiding that symbol.

Does the new lookup rule also affect to UFCS symbol search? It's handled in searchUFCS  function today.

Yes, and searchUFCS() got the same change as Scope.search().

Yay, finally passing!

Added changelog.dd entry.

Did some changes to add comments and fix added names.

So what do you think about deprecating this before making the change.
It seems actually even simpler than described above, just tweak Scope.search to also return the scope a symbol was found in. If that symbol comes from a different module (before resolving aliases) you know it was imported and can check whether it hides a local symbol in any scope above the one returned.

If that symbol comes from a different module (before resolving aliases) you know it was imported

Not if it was a base class or template mixin or with scope.

I added a switch to revert to the old behavior.

A switch doesn't solve the problem, you're still breaking many build setups, and then people would have to find out how to manually override switches when running dub test on Travis-CI against a particular dmd version.
However you turn it, just breaking existing code (w/o prior deprecation) tears apart our tiny ecosystem and easily kills a few useful but not so well maintained libraries. Let's leave behind those old days where dmd updates used to break almost every library.
Let me know, if you're not willing to put effort into the deprecation step, then I'll work on that.

BTW, added a deprecation switch.

@MartinNowak worksforyou?

Generally: I think we need to fold this together with fixing https://issues.dlang.org/show_bug.cgi?id=314 - we should only change lookup once.

314 is a protection not a lookup issue.

As said above, those switches don't work and pretend to offer a choice that is hard to fiddle into existing build setups, e.g. hardly anyone uses dip25. We should always choose deprecation instead of behavior changes and errors.
At the same time only few code seems to be affected by those issues, the lookup rule is a major improvement, and the changelog is very clear about it. I want to have a more detailed look at the broken libraries before merging this.

This PR still contains a regression, please fix.
template Mixin()
{
    public import std.stdio;
}

void test()
{
    mixin Mixin!();
    mixin Mixin!() m2;
    writeln("foo");
    m2.writeln("foo");
}

And another bug, this one in a library, that is both important but unmaintained (D-YAML).
Overloading of functions imported from another module with functions imported through a mixin template no longer works.
module foo;

template CanFind()
{
    void canFind(string s, dchar needle) {}
}

// canFind should be an overload set
mixin CanFind!();
import bar;

void test()
{
    "abc".canFind('d');
    "abc".canFind("d");
}

module bar;
void canFind(string s, string needle) { }

It seems you're not treating mixin templates like imports, but you should. Both can collide w/ local symbols and can cause the same problematic symbol clash when changing sth. in a library providing the mixin template.

It seems you're not treating mixin templates like imports, but you should.

This is correct, and a deliberate choice.

Both can collide w/ local symbols and can cause the same problematic symbol clash when changing sth. in a library providing the mixin template.

That's right. I was reluctant to change how template mixins behave because I did not have a good handle on how they were used in the wild, if at all, and have not heard a single complaint about them. Template mixins have very different use cases from module imports, and an important one is to inject symbols into the local scope.

This PR still contains a bug, please fix.

To be clear, both writeln's are not found. This is a deliberate design decision, and not a bug. The same result will happen if Mixin was a base class - the derived class will not consider the import of std.stdio when searching it for symbols.

A switch doesn't solve the problem,

There are 3 choices:

make the new behavior the default and have a switch to revert to the old behavior (what I implemented)
make the switch implement the new behavior, and leave the old as the default (what -dip25 does)
detect when there's a difference and issue a deprecation message (your proposal)

While I agree with your attitude about not breaking things, (3) will make lookups take much longer, and will be problematic to implement.

To be clear, both writeln's are not found. This is a deliberate design decision, and not a bug.

Well, it used to work, but with this PR it's no longer possible to import sth. through a mixin template.

While I agree with your attitude about not breaking things, (3) will make lookups take much longer, and will be problematic to implement.

Let's see if we can get away with it.

While I agree with your attitude about not breaking things, (3) will make lookups take much longer, and will be problematic to implement.

Assuming it is possible to implement (3), a switch could be added for disabling the double lookup for those who are worried about the speed.  That way we get the safe upgrade path by default.

a switch could be added for disabling the double lookup for those who are worried about the speed.

I guarantee that people testing the speed will not know about that switch, and we get bad pr by default. It's hard enough getting people testing optimization to throw the right switches.

with this PR it's no longer possible to import sth. through a mixin template

What is sth? Also,
import foo = bar;

will cause foo to be searched. It is not impossible.
Finally, I suggest we merge this, and @MartinNowak can work on strategies to implement (3).

What is sth? Also,
import foo = bar;
will cause foo to be searched. It is not impossible.

Well the exact example I gave above, adding an import via mixin no longer works.
template Import()
{
    import std.stdio;
}

void test()
{
    mixin Import!();
    writeln("Hello");
}

I guarantee that people testing the speed will not know about that switch, and we get bad pr by default. It's hard enough getting people testing optimization to throw the right switches.

Compared to the (possibly silent) code breakage, compilation speed is a minor concern.  If we compile slightly slower for a few of releases it's a small price to pay.

compilation speed is a minor concern

That's what everyone tells me who works on the compiler, it's the attitude of every other language compiler. However, many people who use D (and Digital Mars products) tell me their major reason is compile speed. They mention it first when I ask "why did you switch to D." dmd has suffered bad degradations in compile speed over the last two years, primarily due to the addition of poor template instantiation algorithms with no regard for performance.
Furthermore, adding a deprecation message will make this enhancement unusable. The whole point is to have the imports not hide locals - if a message appears every time, it falls apart.
Silent breakage is a possibility, but a remote one. I have not seen one yet. All the breakage encountered to date were fairly loud and straightforward to fix, and relying on the old behavior was a bad practice anyway by any measure.
Adding a backwards compatibility switch is not perfect, but it is the most reasonable solution.

I agree that speed is important.  It's just not as important as avoiding breakage, especially if the slowdown is temporary.

Furthermore, adding a deprecation message will make this enhancement unusable. The whole point is to have the imports not hide locals - if a message appears every time, it falls apart.

Are you sure that's the case?  Adding a deprecation message allows library authors time to fix their code before the semantics change.

Are you sure that's the case?

If I make use of the feature that imports are not searched, I get a deprecation message because they are.

Furthermore, adding a deprecation message will make this enhancement unusable. The whole point is to have the imports not hide locals - if a message appears every time, it falls apart.

What about adding the deprecation message only if -transition=import is passed?

What about adding the deprecation message only if -transition=import is passed?

Then you've got pretty much what this PR is right now.

If I make use of the feature that imports are not searched, I get a deprecation message because they are.

If that wasn't clear until now, deprecation of course means you can't change the lookup rule before the deprecation is over (at least 2-3 releases ~= 6 months).

proposed:

users install new compiler, start getting deprecation messages
users must change build to add -d, or fix the errors

versus this pr:

users install new compiler, start getting error messages
users must change build to add -transition=import, or fix the errors

I oppose the proposal because:

it delays by up to a year(!) an enhancement we believe will result in significant encapsulation improvements
dealing with it involves just as much work by users
it slows the compiler down, a serious shortcoming that piles on top of all the other changes that disregard performance
implementing it is not as trivial as suggested

proposed:

users install new compiler, start getting deprecation messages
users must change build to add -d, or fix the errors

The messages are nagging you (or some upstream library maintainer) to fix the issue, but you can safely ignore them, that's what deprecation messages are for.
You should never use -d btw.

I oppose the proposal because:

it delays by up to a year(!) an enhancement we believe will result in significant encapsulation improvements

Seriously? Those import problems are about 10 years old, 6 month more or less won't make much of a difference. Note that a deprecation will already help to find

dealing with it involves just as much work by users
it slows the compiler down, a serious shortcoming that piles on top of all the other changes that disregard performance
implementing it is not as trivial as suggested

At the moment it looks like this change causes little issues, so we might indeed decide to do it. This should be a very rare exception, but initially no thought was spend on avoiding the breakage.
Please respond to https://github.com/D-Programming-Language/dmd/pull/5445#issuecomment-184015747, I don't see how we can proceed w/ this until mixins are fixed.

Please respond to #5445 (comment), I don't see how we can proceed w/ this until mixins are fixed.

It isn't supposed to work, as I explained earlier. It is deliberate intended behavior, just like:
class B {  import std.stdio; }
class C : B {
  void test() {
      writeln("Hello");
  }
}

will no longer work.

It isn't supposed to work, as I explained earlier. It is deliberate intended behavior, just like:

I couldn't believe you're seriously arguing that it should no longer be possible to mixin an import into another scope.
I would agree w/ the base class example but only b/c the import is private (if the base class were in a different module), breaking public imports in base classes is a different topic.

class Klass
{
  public import std.stdio;
}
void test(Klass klass) { klass.writeln("hello"); }

Now you're breaking valid use-cases w/o offering replacements. Importing modules into a class isn't pretty, but this is how D worked for ages, live with it or help people to update their code.
Not allowing imports in template mixin is an arbitrary restriction, breaking even more valid use-cases. Just to quote the docs It is analogous to cutting and pasting the body of the template into the location of the mixin.

I couldn't believe you're seriously arguing that it should no longer be possible to mixin an import into another scope.

Believe it :-)

I can't think of a reasonable use case for it. Just because you can doesn't make it a good idea.
The mixin can do things like:

import foo : a, b, c;

if specific names are to be imported. This is valid and works.
3. It would still leave us with the problem of unexpected behavior when a mixin import gets names added to it by a third party
4. string mixins can be used

If we're going forward with this accepting some breakage, then we also need to fix 314 and prolly should implement http://wiki.dlang.org/DIP22.
Are we sure we can manage that in the next 4 weeks, so it's ready for 2.071.0?
How about we merge this and the 313 fix into a separate import_fixes branch, then work on the other issues before merging the whole story back into master.
This would also allow us to build preview releases to get feedback from closed source D users.

We knew beforehand that changing imports and lookup is going to be tough, but I'm glad we're finally fixing this b/c the current implementation causes small code breakages all the time.
<EMAIL_ADDRESS>

We should think a bit about tooling to make the necessary code changes simpler.
We could at least add another switch to do the presumably expensive double lookup, and emit a useful deprecation message (import pkg.mod : sym;) if the found symbols don't match.

313, yes, since it's ready to go. The rest, no, they are not ready. I intend to go back to work on EH, as it's clear it won't get done if I don't do it.
I don't agree with creating essentially a fork. We don't have a large enough community to make that worthwhile or manageable.
This is a good enhancement. There's a switch to revert to the old behavior. I think the worries about this, while I agree with the sentiment, are a bit overblown. Every case the new behavior errored on was, in my not so humble opinion, crap code to begin with and I was happy to fix them.
This enhancement is important because it is an enabling enhancement. It enables us to advocate, with confidence, the notion of using local imports to improve encapsulation and comprehensibility of code, which are key features of D. It resolves a problem that has been embarrassing for us, and greatly annoyed many people. I don't believe we should be sitting on it.

add another switch

Please, no:

complexity
documentation
it is not as easy as you suggest - note that every override of search() changed the flags.
if a user sees new "undeclared symbol" messages, he can simply add the -transition=import switch and if the error goes away, he knows that's what the problem is.

BTW, doing a fork has more problems. This change touches a lot of files, and I've had to rebase it twice in 4 days just so it will merge. I'm not keen on the time investment in this.

I don't have much to offer here, except support for this change. As much as this will break code, people have been clamoring for import issues to be fixed for almost a decade. I think folks will understand this is going to help them even though their code breaks.
Regarding build issues, I think those are somewhat secondary to the ability to have code that compiles for both older and newer versions of the compiler. Simply because the two alternative compilers lag behind DMD. So as long as there is a way to fix broken code so it compiles for the new scheme and the old scheme, I'd say passing the right flags is a secondary concern.

Your arguments are correct, the very few issues this caused ¹ relied on rather obscure behavior, and the new lookup rules are a huge improvement.
The code is also clearer now, and we have a nice explanation in the changelog.

Auto-merge toggled on

Auto-merge toggled on

Thank God.
Thanks Walter for doing this!

I have a question on this. If I want to have an inner scope where I add an overload via an import, how would I do it? Currently, you have to re-import the original so they are on the same level. From my reading of the new rules, this would continue to be the case.
An example of what I'm talking about is in the bug report this PR is fixing (at the end of the comment): https://issues.dlang.org/show_bug.cgi?id=10378#c16

Currently, you have to re-import the original so they are on the same level.

That's right (and this PR does not change that behavior).

So as long as there is a way to fix broken code so it compiles for the new scheme and the old scheme,

I had no problems doing that for the Phobos library breakage.

Right. The only confusing part is to require importing the current module you are in (because another module hijacked a module symbol you were using).
Interestingly, this doesn't happen when you import at module level. The current module trumps any imports. But when you import at a scope, then the rules change. As a user of library code, I can see value in importing a module locally when it only pertains to that particular function. What I'm concerned with (and am still, even though I like the PR as merged), is that a movement of an import from the module level to a scoped level changes what happens.
example:
module a;

void foo() {import std.stdio; writeln("a");}

void bar() {}

module b;
import a;

void foo() {import std.stdio; writeln("b");}

void main()
{
    bar();
    foo();
}

This outputs "b"
Hey, look, we can just import a locally in main, because we only need bar in there!
module b;

void foo() {import std.stdio; writeln("b");}

void main()
{
    import a;
    bar();
    foo();
}

This now outputs "a".
I'm unsure of the "fix" for this, but it may be good practice to recommend always importing within an inner scope using renamed imports (to avoid hijacking like this).

@schveiguy Your second example now outputs b with this PR. This fix is the whole point of this PR.

our second example now outputs b with this PR

Oh right! I wasn't thinking about the fact that local module functions aren't actually imported :)
So no need to reimport the current module if the current module's function is what you want. This is great! Thanks.

Could someone please tell me if this breakage is intentional or should I file a regression?
int memcmp(in ubyte[] a, in ubyte[] b)
{
	import core.stdc.string;
	assert(a.length == b.length);
	return memcmp(a.ptr, b.ptr, a.length);
}

This no longer works because it tries to call itself - not what I would expect TBH, seems like a bug to me.

I think it's intentional, as imports now are considered after local module functions.
I disagree that it's a bug. If you imported core.stdc.string in the module, the imported memcmp wouldn't be considered.

If you imported core.stdc.string in the module, the imported memcmp wouldn't be considered.

That would not be surprising. The behavior in the above snippet is surprising, though, because the import is "closer" (in scope terms) to the use of the memcmp symbol than the function declaration.
Changing the import to a selective import makes it compile again, which is weird, as I always thought that selective imports are simply selective versions of imports, and do not grant additional visibility to the selected symbols.
I kind of see why this change was necessary, though, but the additional complexity and code breakage isn't nice.

Yes, selective import actually aliases the symbol (and only the one you selected) into your local scope, which would override any other imported symbols and local symbols.
It is going to be very confusing, and code-breaky, because it's been this way for so long. I don't think there's a way we could do this without breaking code.

Note: I always looked at it the opposite way -- that importing in a local scope should not change how the import was done, just what scopes could see the import. Moving an import inside a function shouldn't change the behavior of the function, you are just trying to avoid polluting namespaces (you can see my example above).

@schveiguy are you sure? core.stdc.string.memcmp has a different signature to the function that imports it's module.  I can see no reason why that snippet would even consider recursively calling itself.

Could someone please tell me if this breakage is intentional or should I file a regression?

It's behaving exactly as intended.

has a different signature

Signatures are considered for overload resolution, not for name lookup. D has always worked this way, and so has C++.

Turn on -transition=checkimports, it should give you a proper deprecation warning about the changed lookup.

Turn on -transition=checkimports, it should give you a proper deprecation warning about the changed lookup.

I am seeing new deprecation warnings even without this flag (using dmd master). Is the flag meant for stable and the breaking changes for master, or something else?

It's behaving exactly as intended.

OK. Another question: does a selective import not imply a static one? E.g.:
import std.stdio : readln;
import std.conv;

void main()
{
	std.stdio.writeln("Hello, world!");
}

This now gives:
test.d(6): Deprecation: module std.stdio is not accessible here, perhaps add 'static import std.stdio;'

but that strikes me as redundant considering the selective import.

does a selective import not imply a static one?

No it was not supposed to. But this is due to a different pull:
https://github.com/D-Programming-Language/dmd/pull/5426


Modifications for Ultimate Goal game

Work in progress. Need to add Wobbles, Goal stands, some modifications to robot


async version of models serializer

Coverage decreased (-1.4%) to 95.714% when pulling 6d69cb8f8f6d5c0852864f9a5e5ab95671112a02 on uSide:develop into 7cad89a73a111308e40f847f8711d2bc751910b2 on adonisjs:develop.

Hey @uSide!
Thanks for your contribution! ❤
May you add some tests to your PR?

Vladimir Kleshko @uSide Jan 23 17:21
hey guys! do you plan to implement computed properties with generators support?
Harminder Virk @thetutlage Jan 23 17:44
@uSide Can u share the use-case on what exactly you are trying to achieve?
Vladimir Kleshko @uSide Jan 23 18:38
for example, I want computed property for my model where I can fetch data from redis

@uSide I am not in favor of async computed properties. I asked for the use case to understand what exactly you are trying to achieve. Fetching data from redis is not a computed property at all and should be handled by your application.

@thetutlage okay, another simple example: I have some async service and want to retreive data from it without saving this data to db. Sure, this is not a "best practice" for large data, but for small selections it will be nice I think

Yeah then you should make use of your controller to fetch the data, Why you want to keep it on the model instance?

Let me provide an example.
So you have your PostsController index method where you want to display information about your posts.
{% for post in posts %}
  {# ... #}
  {{ post.view_count }}
  {# ... #}
{% endfor %}

The attribute view_count is stored in a Redis database, so the code above will not works.
You can do the same by using your controller to fetch the data from Redis and then you need to map the data.
{% for post in posts %}
  {# ... #}
  {{ redisData[post.id] }}
  {# ... #}
{% endfor %}

@thetutlage to reduce number of cycles and make code cleaner. If you have some tree data it will be a big controller like: load data from db -> call toJSON, where lucid map all relations/etc -> load data from async service -> another big map to extend result json. In this case we dont have code in model, but in result we will have a heavy controller

@RomainLanz Yes this is less expensive than hitting redis for each record that you fetch from database.
For example: If you have 30posts inside database, the computed property will make 30 calls to redis server for each post instance.
Ideally you can make use of paginate method to get the counts. Also if their is complexity in the code, it is better to abstract that logic to usable service, instead of replying on computed properties.

@uSide Doing async in a loop in the recommended. You will end up with a O(n) issue.
As @thetutlage said, if you have 30 posts you will need to do 30 requests to your service/database. That's why we eager/lazy-load relation.
You need to fetch those remote data from your controller and create a dictionary/hash to retrieve them in your view.
I have written an example above.

I have no more arguments. Close a pr ?

If you feel your code is getting unmanagable, feel free to throw the actual situation you are in the gitter room and we all can discuss about it.
But async computed properties will case performance issues no matter what. Closing the PR for now


Make gardener upgrade e2e tests mandatory

/kind enhancement
What this PR does / why we need it:
Make gardener upgrade e2e tests mandatory

/cc @oliver-goetz


Setting username and password for DataSource

Hi,
I want to use airlift db-pool for pooling my MySQLConnection. I have gone through the code but how to set username and password for the MySQL data source. In ManagedDataSourceConfig.java we have two defunct properties (db.userename and db.password) apart from that I didn't see any ways to set the username or password.
(The user name and password can be set from the url itself)

(db.userename and db.password)， why deprecate


rqt_robot_dashboard: 0.6.0-1 in 'foxy/distribution.yaml' [bloom]

Increasing version of package(s) in repository rqt_robot_dashboard to 0.6.0-1:

upstream repository: https://github.com/ros-visualization/rqt_robot_dashboard.git
release repository: https://github.com/ros-gbp/rqt_robot_dashboard-release.git
distro file: foxy/distribution.yaml
bloom version: 0.10.7
previous version for package: null

I don't understand what you mean. The package.xml has a license declared. Sibling packages such as rqt_graph don't have a separate license file.

@hidmic Can you point me at an example?

The package.xml has a license declared.

Indeed. And while you're not bound to have a copy of it in a LICENSE file within the repository, it is advisable (see REP-2004). Like ros2/rviz does. It is not a hard requirement though.

Sibling packages such as rqt_graph don't have a separate license file.

Hmm, that is both true and not great.

A) I see no specific recommendation in the REP for a copyright file. It just says "Must have a declared license" and a license is declared in package.xml, the standard place in ROS.
B) I understand that it would be preferable to have a license file, but that REP also says that it is an antigoal to enforce quality levels.

We've started trying to encourage packages to add a top-level LICENSE file, and making sure that they exist for new packages (see REVIEW_GUIDELINES).

It just says "Must have a declared license" and a license is declared in package.xml, the standard place in ROS.

Had to go over it again. You're right it is not very specific about what having a declared license means.

it is an antigoal to enforce quality levels.

Right, that's why I said it's not a hard requirement. I cannot and will not block this release if you choose not to. It'd be great if you did add it though.

Closing for #29564


Upload of xml: value="attribute" needs to be uploaded into forms correctly

e.g., magnification

Value nodes now show and save properly within the forms. Fixed in commit #80


⚠ Bofrost.at has degraded performance

In 0674f33, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1039 ms

Resolved: Bofrost.at performance has improved in 34c9215.


Removing Sensitive Information from Github Issue Edit History

Now that GitHub is a Microsoft product and has introduced an edit history, how can I remove sensitive elements of my issue comment that contain sensitive information?

Hi, I believe this is a question about GitHub.com, the website. This issue tracker is for a command-line utility called hub, not the website itself. For reporting bugs and requesting features for GitHub the website, please email<EMAIL_ADDRESS>Thank you!

Oh thanks, I hadn't realized.  You all do great work on this command, btw!


Relative URL for Image Path IE 11

I'm sorry, I can't tell if this is a PptxGenJS issue or an internet explorer issue or both.
Here is an example of my code:
pptx.defineSlideMaster({
  title:` 'Title Slide With Picture 1',
     bkgd:`  {path: "../pptReportAssets/images/bkgdImage.png" },
      objects:` [
        {` 'image': { x:11.58, y:5.78, w:1.31, h:1.31, path: "../pptReportAssets/images/logoTitleBlue.png" } }
      ],
      slideNumber:` { x:0.42, y:7.17, font_face:'Calibri', fontSize:7, color:'FFFFFF' }
    });
  };

In FireFox, Chrome, and Edge this all works just fine. However, in Internet Explorer, it doesn't like the relative path here.  I can use the same relative path as a link on my HTML page and it works fine.
Internet Explorer appears to take this relative path, and turn it into an absolute path. So....
Let's say I'm in the following directory:
http://localhost/TopDir/SecondDir/
By using the relative path above, I would expect it to go here: (and it does in the other browsers):
http://localhost/TopDir/pptReportAssets/images/bkgdImage.png
But with Internet Explorer, it goes here:
http://localhost/TopDir/SecondDir/../pptReportAssets/images/bkgdImage.png
I also tried something simpler
slide.addImage({ path:'../pptReportAssets/images/logo.png', x:1.0, y:1.0, w:8.0, h:4.0 });
This also does not work in Internet Explorer.

Hi @ineran,
I tested this issue today on Windows 10 using IE11 and the image loaded successfully for me.
slide.addImage({ path:'../logo.png', x:1.0, y:1.0, w:1.0, h:1.0 });
I'm not sure why you're experiencing this issue... If you find anything, please let me know.

I can't add an image at all now actually.  I've tried this on multiple devices.  I have one function in my entire HTML file...
function createPowerPoint(){
``
var pptx = new PptxGenJS(); var slide = pptx.addNewSlide();
slide.addImage({ path:'logo.png', x:1.0, y:1.0, w:1.0, h:1.0 });
pptx.save('Test Slides');
};
When I compare the debugger in Internet Explore and Google Chrome, something happens at function convertImgToDataURLviaCanvas(slideRel) but I can't quite tell what.  In Google Chrome, it jumps right to the line that says canvas = null.  In Internet Explore it goes through the:
catch(ex) {
	this.onerror(); ``	return; ``	}
"ex" says "Promise is undefined." It then takes you through this.onerror().
The console error messages I'm getting are 👍
"Unable to load image: "logo.png"
Please check the image URL:
http://localhost/IEBug/logo.png"
and
"SCRIPT5009: Promise is undefined
pptxgn.js (1692, 3)"
I'm sorry, I thought it was an issue with relative paths but it actually appears to be something different.

So found something very interesting.... when I link to the library using:

It doesn't work. I get the errors I'm mentioning.  However, when I link to the library using:

It works. Can that be possible? lol

SCRIPT5009: Promise is undefined

There it is - IE11 users need to include promise.min.js or use the bundle.

This requirement is mentioned elsewhere, but not in the README for some reason (oops), so i've added a blurb about it now.  Sorry!

No worries.  I'm assuming there isn't a major issue with using the bundle with other browsers, correct?

Correct.


No mapping documentation

There should be documentation, either gh-pages or wiki. Preferably wiki.
The docs should outline the basic structure of maps, manifest files, task and sabotage creation.
While the code itself is semi-well documented and readable enough, the base classes of tasks and sabotages should be documented separately.

I could look into writing some docs if you'd like. Just need collaborator access.

Started some work on this on the wiki.


doc(kafka-logger): Chinese version with minor changes.

https://github.com/apache/incubator-apisix/pull/1312/files#diff-50701cc078da868ee61347ef72b1ab43

I have already updated the doc.But I have a problem is that it looks the plugin does not support sync writing anymore(I have a look the code of plugin), is it still work?@Akayeshmantha

Hi Vinci
Yes the plugin works.But it will send the logs after the log buffer timout
expires.This was an action taken to make sure external log plugins wont
affect performance of the APISIX gateway.
Regards
Ayesh
On Fri 15. May 2020 at 15:03, Vinci Xu<EMAIL_ADDRESS>wrote:

I have already updated the doc.But I have a problem is that it looks the
plugin does not support sync writing anymore(I have a look the code of
plugin), is it still work?@Akayeshmantha
https://github.com/Akayeshmantha
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-apisix/issues/1337#issuecomment-629223510,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE3JLHJQPKD3KX7BVDU7STTRRU4RHANCNFSM4LTBA76Q
.

--
Software Engineer
*Salzburg Research Forschungsgesellschaft *
Salzburg, Austria

Sorry, I seem misled you.
My problem is that the document write a plugin property named "async", it used to control whether send data asynchronously, but the code of plugin does not define this property (now the plugin default send data asynchronously).So I want to know whether this property still work?

Hi Vinci
Yes its only sending data async way now. You are right that attribute needs
to be removed from the doc.
Regards
Ayesh
On Fri 15. May 2020 at 17:35, Vinci Xu<EMAIL_ADDRESS>wrote:

Sorry, I seem misled you.
My problem is that the document write a plugin property named "async", it
used to control whether send data asynchronously, but the code of plugin
does not define this property (now the plugin default send data
asynchronously).So I want to know whether this property still work?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-apisix/issues/1337#issuecomment-629316328,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE3JLHIITCKNHWVMBFPE423RRVOLRANCNFSM4LTBA76Q
.

--
Software Engineer
*Salzburg Research Forschungsgesellschaft *
Salzburg, Austria

Oh sorry I actually thought I was getting emails I replied to mails so it popped out like this sorry about the inconvenience.

Ok, I have already remove it from doc


Change signatures of the style operator descriptors.

Prefer to pass the CallExpr instead of just the list of actual
arguments. This change will allow the operators to use properties
stored together with the CallExpr node. Also, it makes it possible
for evaluators to return the CallExpr node when partially evaluating
expressions.
Signed-off-by: Roberto Raggi<EMAIL_ADDRESS>

Codecov Report

Merging #961 into master will increase coverage by <.01%.
The diff coverage is 50.74%.

@@            Coverage Diff             @@
##           master     #961      +/-   ##
==========================================
+ Coverage   47.88%   47.89%   +<.01%
==========================================
  Files         228      228
  Lines       21657    21660       +3
  Branches     4944     4944
==========================================
+ Hits        10371    10374       +3
  Misses      11286    11286

Impacted Files
Coverage Δ

...asource-protocol/lib/operators/FeatureOperators.ts
15.38% <0%> (ø)
:arrow_up:

@here/harp-datasource-protocol/lib/Expr.ts
89.55% <100%> (+0.06%)
:arrow_up:

...atasource-protocol/lib/operators/ColorOperators.ts
100% <100%> (ø)
:arrow_up:

...datasource-protocol/lib/operators/TypeOperators.ts
100% <100%> (ø)
:arrow_up:

...atasource-protocol/lib/operators/ArrayOperators.ts
90.9% <100%> (+0.9%)
:arrow_up:

...datasource-protocol/lib/operators/CastOperators.ts
100% <100%> (ø)
:arrow_up:

...here/harp-datasource-protocol/lib/ExprEvaluator.ts
91.34% <100%> (ø)
:arrow_up:

...tasource-protocol/lib/operators/ObjectOperators.ts
93.75% <100%> (ø)
:arrow_up:

...e-protocol/lib/operators/InterpolationOperators.ts
89.79% <100%> (ø)
:arrow_up:

...datasource-protocol/lib/operators/FlowOperators.ts
85% <100%> (ø)
:arrow_up:

... and 4 more

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 0c48613...c84ec11. Read the comment docs.


Support for Fritz!Powerline Smart Plug 546E

Is your feature request related to a problem? Please describe.
Support for FRITZ!Powerline 546E Smart Plug with energy metering
Describe the solution you'd like
It would be great to have these supported similar to the FRITZ!Dect based plugs.
Describe alternatives you've considered
cannot reach the garage with Wifi based plugs.
Additional context
I'm using several FRITZ!Powerline 546E based plugs to control the charge of my e-bikes.

I guess they should follow exactly the same API and hence be supported already?

Thanks for looking into this @andig
If I compare the AIN in the docue with what I see in the GUI of the Powerline adapter is looks different. The AIN of my smart Plug looks more like a mac address 6xHEX with two digits and : as separator

You were right, seems to be working!


Inconsistent "property does not exist" on F-bounded mapped type with intersection

TypeScript Version:  3.6.0-dev.20190726 (reproducible all the way back to 2.4 afaict)

Search Terms: f-bounded polymorphic, intersection, mapped type, property
Code
type X<T> = { [K in keyof T]: string } & { b: string };
interface Y extends X<Y> {
  a: "";
}
declare const y: Y;
y.a; // "", okay
y.b; // hinted as string, but error!
//~ <--  Property 'b' does not exist on type 'Y'. 🤔

type KY = keyof Y; // "a" | "b"
type YA = Y["a"] // okay
type YB = Y["b"] // error!
//          ~~~ <-- Property 'b' does not exist on type 'Y'.
type B = Exclude<keyof Y, "a"> ; // "b"
type YB2 = Y[B]; // okay, string! 😵

Expected behavior:
I expect either no errors (y.b is type string), or I expect the particular F-bounded mapped type Y extends X<Y> to be disallowed.
Actual behavior:
Split-personality weirdness where property "b" both does and yet does not exist on type Y.
Playground Link:
Link
Related Issues: Not really obvious to me, #18280 hits some of the same concepts but is not the same issue

I know that this is a weird construction, and I'm okay not using it (although something like it is useful in representing otherwise unrepresentable type constraints), but the resultant behavior is just so bizarre that I had to report it.  Especially how Y["b"] is an error, but Y[B] is not an error.

Split-personality weirdness where property "b" both does and yet does not exist on type Y.

That’s just the new undocumented “Schrödinger's properties”.  It’s not a bug, it’s a feature!

Wait, maybe this is a duplicate of #23537?  Or close enough?

Would be nice to report a circularity error here. There are a few places where we defensively set lazy resolution caches to empty before invoking the resolution logic such that circular references don't trigger infinite recursion. Ideally we'd use our pushTypeResolution logic in those cases, but I'm concerned that might uncover circularity errors that really are harmless. Anyway, I don't think this is a pressing issue.


BUG do not load predictions whenever fetching unrelated infos

closes #226
Avoiding to load the predictions when computing the leaderboard.

@tomMoral this seems better than the joblib cache thing.

All the set_* functions are still loading the predictions. We need to access the attributes directly if we want to avoid loading the predictions.

FYI so I am sure that we are not loading the predictions when scoring. This is a bit more complex but still readable I think.
I really would like to have a test for that.