Feature/drop xmltodict

Dropped xmltodict feature, to let the developer make the choice of how to work with the data
fixed unit tests
fixed integration tests
added containerlab with arista to the CICD lifecycle (plan on adding full feature tests w/ arista instead of sysrepo container before 2.0 release)

Codecov Report

Merging #52 (43f3f13) into next (88e1975) will not change coverage.
The diff coverage is 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff            @@
##              next       #52   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           13        13
  Lines          194       176   -18
  Branches        27        23    -4
=========================================
- Hits           194       176   -18

Impacted Files
Coverage Δ

nornir_netconf/plugins/connections/netconf.py
100.00% <100.00%> (ø)

nornir_netconf/plugins/helpers/__init__.py
100.00% <100.00%> (ø)

nornir_netconf/plugins/helpers/rpc_helpers.py
100.00% <100.00%> (ø)

...ir_netconf/plugins/tasks/editing/netconf_commit.py
100.00% <100.00%> (ø)

...tconf/plugins/tasks/editing/netconf_edit_config.py
100.00% <100.00%> (ø)

...nir_netconf/plugins/tasks/retrieval/netconf_get.py
100.00% <100.00%> (ø)

...conf/plugins/tasks/retrieval/netconf_get_config.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Add documentation for LV VIs

Adds documentation for the VIs created on this PR

@katiemacaulay thanks for the review. It should be ready for another look.


Fixed deprecated function

This change should make :Lspsaga diagnostic() work properly

fixed in https://github.com/tami5/lspsaga.nvim

fixed in https://github.com/tami5/lspsaga.nvim

Yes, im now using your fork instead of this one. Thanks :)


Add user administration interface to Northstar.

What's this PR do?
This pull request moves Aurora's user administration interface into Northstar.
How should this be reviewed?
This is a somewhat hefty PR, but it's largely "copy and paste" from Aurora.
First, a couple little touch-ups:
📝 Fixes a typo on the config for the "frontend" URL (e.g. www.dosomething.org). bceedd9
🍃 The logo now directly links you to the "admin home", rather than the user-facing "profile home". f417db6
Then, I copied over some configuration this work relies on:
🔽 I added a forms.select partial, borrowed from Rogue. 4a345b7
📑 Configured Laravel to use Forge paginators & updated styles to match what we use in Aurora. d8df057
🤝 Add helpers & custom styles from Aurora that these pages rely on. ab673ff
📛 Extracts a CauseInterests type from the profile controller, so we can reference it in our admin controller too. c0ff5e9
Finally, the main event:
🏗 Adds the user administration interface. This is less of a literal copy-paste because we're now directly making these changes in the database (rather than via a Northstar API client) and because we'd previously relied on the Forms package, which is a dependency that I didn't want to pull along here. 6adbb9e
Any background context you want to provide?
This, alongside other work in the Unified Backend epic, will allow us to retire Aurora's dynos - saving us money & allowing related changes (new user profile fields & their form entries) to be made at the same time!
I have not included the password reset & merge user functionality in this PR since it was already getting really heavy! I also haven't yet tackled how we'll deal with logging access to sensitive profile fields since this no longer routes via our API. I'll be sure to have that in place before we toggle this on in QA or production.
Relevant tickets
References Pivotal #175943296.
Checklist

[ ] This PR has been added to the relevant Pivotal card.
[ ] Documentation added for new features/changed endpoints.
[ ] Added appropriate feature/unit tests.
[ ] If new attributes were added to users, there is a corresponding PR to surface these in Aurora.
[ ] If new attributes were added to users, then the data team already knows about these changes.

For some reason the is_dosomething_domain helper's test is failing on these commits in CircleCI... but not on my local. 👻 I'm going to continue digging into that, but shouldn't block reviewing the work that's in here! ✌

For some reason the is_dosomething_domain helper's test is failing on these commits in CircleCI... but not on my local. 👻 I'm going to continue digging into that, but shouldn't block reviewing the work that's in here! ✌

Picking this back up to investigate this failing test. I haven't touched this particular helper, and the only dependency change included here was adding sokil/php-isocodes. I'm not seeing this test fail on my local on the same commit, either.
Most interestingly, we had a passing build when I pushed f417db6. However, re-running the build for that same commit today, the build fails. Same exact commit! The only difference I can see seems to be which CircleCI Docker boxes we pull.
From the passing build:
Build-agent version 1.0.48436-ed6d55c4 (2020-12-14T12:50:21+0000)
Docker Engine Version: 19.03.13
Kernel Version: Linux 5da4719a86d8 4.15.0-1077-aws #81-Ubuntu SMP Wed Jun 24 16:48:15 UTC 2020 x86_64 Linux

Starting container circleci/php:7.4-node-browsers
7.4-node-browsers: Pulling from circleci/php
  using image circleci/php@sha256:79af502ed36ede7ee6bd15d1f770018cfabd39f4128574301b8a46f777548c6e

From today's failing build:
Build-agent version 1.0.50487-04320222 (2021-01-13T13:00:25+0000)
System information:
 Server Version: 19.03.13
 Storage Driver: aufs
  Backing Filesystem: extfs
 Cgroup Driver: cgroupfs
 Kernel Version: 4.15.0-1077-aws
 Operating System: Ubuntu 18.04.4 LTS
 OSType: linux
 Architecture: x86_64

Starting container circleci/php:7.4-node-browsers
7.4-node-browsers: Pulling from circleci/php
  using image circleci/php@sha256:d1f3c3011022aae5dc2363a08e1a3e427b9539432aeca89df1b934f43c4cbe84

Perhaps we got a newer PHP patch release that changed how parse_url functions? I see some changes to parse_url in 7.4.13 and 7.4.12, but they don't at a glance seem like they'd break this test...

Picking this back up to investigate this failing test. I haven't touched this particular helper, and the only dependency change included here was adding sokil/php-isocodes. I'm not seeing this test fail on my local on the same commit, either.
Most interestingly, we had a passing build when I pushed f417db6. However, re-running the build for that same commit today, the build fails. Same exact commit! The only difference I can see seems to be which CircleCI Docker boxes we pull.
From the passing build:
Build-agent version 1.0.48436-ed6d55c4 (2020-12-14T12:50:21+0000)
Docker Engine Version: 19.03.13
Kernel Version: Linux 5da4719a86d8 4.15.0-1077-aws #81-Ubuntu SMP Wed Jun 24 16:48:15 UTC 2020 x86_64 Linux

Starting container circleci/php:7.4-node-browsers
7.4-node-browsers: Pulling from circleci/php
  using image circleci/php@sha256:79af502ed36ede7ee6bd15d1f770018cfabd39f4128574301b8a46f777548c6e

From today's failing build:
Build-agent version 1.0.50487-04320222 (2021-01-13T13:00:25+0000)
System information:
 Server Version: 19.03.13
 Storage Driver: aufs
  Backing Filesystem: extfs
 Cgroup Driver: cgroupfs
 Kernel Version: 4.15.0-1077-aws
 Operating System: Ubuntu 18.04.4 LTS
 OSType: linux
 Architecture: x86_64

Starting container circleci/php:7.4-node-browsers
7.4-node-browsers: Pulling from circleci/php
  using image circleci/php@sha256:d1f3c3011022aae5dc2363a08e1a3e427b9539432aeca89df1b934f43c4cbe84

Perhaps we got a newer PHP patch release that changed how parse_url functions? I see some changes to parse_url in 7.4.13 and 7.4.12, but they don't at a glance seem like they'd break this test...

Oh, here we go... this bug fix to FILTER_VALIDATE_URL was included in the PHP 7.14.14 changelog:

Fixed bug #77423 (FILTER_VALIDATE_URL accepts URLs with invalid userinfo). (CVE-2020-7071)
Expected result:
----------------
for security, we will filter the host before using redirect($url) .
we'll test if the host of the url to redirect is in our whitelist(e.g. aliyun.com).
how ever, a attacker will use<EMAIL_ADDRESS>to bypass the filter.
-------
parse_url("http://php.net\@aliyun.com/aaa.do");
["host"]=> string(10) "aliyun.com"

-------
parse_url("http://php.net/@aliyun.com/aaa.do");
["host"]=> string(7) "php.net"

----------------
then we'll export the url to the webpage as "<a<EMAIL_ADDRESS>aaa
then click the button, browser will open the "php.net".

That's the exact exploit we were trying to avoid in our application code (as reported by our own pen-testers)! My Homestead box is running Homestead 11.3.3 with PHP 7.4.12 (referencing dosomething/communal-docs#46) which wouldn't have this fix! I'm going to upgrade my local box to use this newer PHP release & then see what changes we need to get this passing again.

Oh, here we go... this bug fix to FILTER_VALIDATE_URL was included in the PHP 7.14.14 changelog:

Fixed bug #77423 (FILTER_VALIDATE_URL accepts URLs with invalid userinfo). (CVE-2020-7071)
Expected result:
----------------
for security, we will filter the host before using redirect($url) .
we'll test if the host of the url to redirect is in our whitelist(e.g. aliyun.com).
how ever, a attacker will use<EMAIL_ADDRESS>to bypass the filter.
-------
parse_url("http://php.net\@aliyun.com/aaa.do");
["host"]=> string(10) "aliyun.com"

-------
parse_url("http://php.net/@aliyun.com/aaa.do");
["host"]=> string(7) "php.net"

----------------
then we'll export the url to the webpage as "<a<EMAIL_ADDRESS>aaa
then click the button, browser will open the "php.net".

That's the exact exploit we were trying to avoid in our application code (as reported by our own pen-testers)! My Homestead box is running Homestead 11.3.3 with PHP 7.4.12 (referencing dosomething/communal-docs#46) which wouldn't have this fix! I'm going to upgrade my local box to use this newer PHP release & then see what changes we need to get this passing again.

Frustratingly, the latest Settler box still has PHP 7.4.12 bundled in it so we'll have to wait on a new box release to easily get this patch release. In the meantime, I was able to update my own box to 7.4.14 via sudo apt-get upgrade.

Frustratingly, the latest Settler box still has PHP 7.4.12 bundled in it so we'll have to wait on a new box release to easily get this patch release. In the meantime, I was able to update my own box to 7.4.14 via sudo apt-get upgrade.

Rebased to grab #1088 & get tests passing here.

Rebased to grab #1088 & get tests passing here.


IGNITE-14247 Add snapshot page, add checking snapshot commands

Thank you for submitting the pull request to the Apache Ignite.
In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:
The Contribution Checklist

[ ] There is a single JIRA ticket related to the pull request.
[ ] The web-link to the pull request is attached to the JIRA ticket.
[ ] The JIRA ticket has the Patch Available state.
[ ] The pull request body describes changes that have been made.
The description explains WHAT and WHY was made instead of HOW.
[ ] The pull request title is treated as the final commit message.
The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
[ ] A reviewer has been mentioned through the JIRA comments
(see the Maintainers list)
[ ] The pull request has been checked by the Teamcity Bot and
the green visa attached to the JIRA ticket (see TC.Bot: Check PR)

Notes

How to Contribute
Coding abbreviation rules
Coding Guidelines
Apache Ignite Teamcity Bot

If you need any help, please email<EMAIL_ADDRESS>or ask anу advice on http://asf.slack.com #ignite channel.

@Nikita-tech-writer Hello, can you review my changes?

@Mmuzaf Please see my comments above.

@Nikita-tech-writer I've fixed all your comments. Can I proceed?

@Nikita-tech-writer I've fixed all your comments. Can I proceed?

@Mmuzaf Absolutely!


Comments panel redesign

This is a followup to the discussion in #139524. Planned API changes means that more information can be surfaced on the UI (in particular, timestamp and thread status). At the same time, we want to reduce visual complexity; it can already be difficult to navigate through the set of comments and find which ones are relevant.
I'd  like to explore here designs that remove intermediate replies in a discussion thread. Rationale: reading a full discussion in the comments panel is not really feasible (because comment snippets are truncated and lack styling). If someone wants to read the discussion, they should open it. We need to show enough context so that a user can find the thread they are interested in.
Design 1.

Here, we show only the first and the last messages in each thread. The first message is useful for the context. The last message helps the user know what is the state of the thread, and if there was a message since they last read it.
We could add "..." somewhere to make it clearer that intermediate messages are not shown.
Design 2.

Here, we don't show the first message and we focus on the last update. We give information about hidden messages: how many messages are not shown and who where the authors. This design makes it more obvious that the full thread is not shown.
Other thoughts:

Being able to hide the resolved threads would be very useful. This would be similar to the filter we already have in the Problems panel (e.g. Show warnings can be unchecked).
It would also help if we had control on which thread is expanded. The API only lets us expand/collapse a thread in the editor view; maybe we could have the same for the Comments panel? This feature is important IMO if we keep a design that lists all intermediate replies.

(mocks designed by @albertelo)
cc @alexr00 and @isidorn

@laurentlb thank you for opening this issue, you have read my mind.  We have been discussing a design similar to design 2.
Regarding hiding resolved threads: I want to add a menu contribution point to the comments panel comments/view/title which would allow actions to be contributed to the comment panel in this area:

This feature already exists. We have been able to add icons there in our extension using:
      "view/title": [
        {
          "command": "critique.publishComments",
          "group": "navigation",
          "when": "view == workbench.panel.comments && config.critique.enableComments"
        },
        // ...
      ],

One less thing to do then!

Work in progress update:

Any feedback is welcome!

Thanks! A couple of questions:

which comment under the main thread? The middle row suggests it's a second reply from a thread of three comments.
are threads expandable? There is no chevron, but the first two nodes have a nested comment
when multiple users have replied to a thread, will their names be displayed?
To make content easier to parse, would it make sense to make the time stamp and the description smaller? Like how the directory ".github" is displayed?

which comment is displayed under the main thread? The middle row suggests it's a second reply from a thread of three comments.

It's the most recent comment on the thread.

are threads expandable? There is no chevron, but the first two nodes have a nested comment

Threads are not expandable. There was a bug that caused the third node to be missing it's comment snippet line.

To make content easier to parse, would it make sense to make the time stamp and the description smaller? Like how the directory ".github" is displayed?

Here it is with everything but the usernames in the smaller font:

And here it is with just the timestamps and the comment counts in the smaller font:

Not sure which I prefer.

I like the idea of the timestamp as supplementary information because the nodes can become complex depending on the comment. A smaller font supports rather than compete for attention. Something along the lines of the second image alexr00 posted aligns with what I was imagining, but I agree it looks a bit odd when the nested node has the username and timestamp in a smaller font. Perhaps the timestamp in a smaller font could work. That said, if this treatment is not used anywhere else besides the file nodes (file name is bigger than the directory), I'd side with consistency.
I'm happy to keep discussing this proposal:

Might we worth exploring how it looks with more usernames. Likely we'll need a treatment for collapsing or limiting how many usernames are displayed.
One thing we've discussed within the team is that it's not easy to understand that the comment shown is the last one posted in the thread. In one thread we had discussed using "..." I don't have a great solution in mind, I thought about an icon like this one:

but that feels too abstract. A tooltip could alleviate this a bit, but has discoverability shortcomings.

Did a few design variations on the panel here to (hopefully) make the threads a little more clear. I think showing the preview gets a bit in the way of just parsing the number of threads and some social platforms will try and summarize the number of comments:

I'm afraid it will be difficult to distinguish the threads. It's common for a single person to leave a bunch of comments; if all the lines are similar, it can be confusing.
When I see the last comment, I can more easily know the state of a thread and what I need to do: Is there a question? Is there a suggestion to apply? Did someone add a response since my last comment?

This could also inform filtering options mentioned by @laurentlb in the original post, e.g. showing only threads where the last reply is not from me.

Yes, let's start a new issue for this. It's a good feature request, and we should make sure the UX changes we make here don't prevent us from adding it later, but it should be added separately to facilitate our API process.

Here's where we're at so far. The arrows will instead be the nice "reply" icon from @misolori's mocks instead of the current icon.

The comment preview is the original comment in the thread.
If a comment thread only has one comment then it only gets one line.
The icon helps distinguish a thread with multiple comments. When we add resolved/unresolved this may no longer be true, but its ok to use different icons in that case.
We show the original timestamp of the thread and the timestamp of the last reply.

One nit:
The icons used in this proposal feel ideal for the task:

Are they implemented already? I couldn't find them and the latest image uses the straight arrow. If they're not, perhaps design + implementation is needed?

Yes, let's start a new issue for this. It's a good feature request, and we should make sure the UX changes we make here don't prevent us from adding it later, but it should be added separately to facilitate our API process.

I opened #143005.

The arrows will instead be the nice "reply" icon from @misolori's mocks instead of the current icon.

In the last screenshot, I think it would be useful to add the username of the last comment, e.g.

4 comments Last reply from albertelo, 1 hour ago

I often want to know if someone else has responded after me.
Apart from that, I think it looks good!

@alexr00 added the new icon as indent since we already had a reply

Here's what I merged:


Update aws-java-sdk to 1.12.629

About this PR
📦 Updates com.amazonaws:aws-java-sdk from 1.12.625 to 1.12.629
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.amazonaws", artifactId = "aws-java-sdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.amazonaws", artifactId = "aws-java-sdk" }
}]

labels: test-library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #882.


[FEATURE REQUEST] Create a release per version/date

Create a release in this repo per version/date whenever the links get updated.

Considering the frequency I expect to update this, I think this would be very time consuming. Though I will look into ways to automating it, because it would make it much simpler to check for updates

Considering the frequency I expect to update this, I think this would be very time consuming. Though I will look into ways to automating it, because it would make it much simpler to check for updates

Considering the frequency I expect to update this, I think this would be very time consuming. Though I will look into ways to automating it, because it would make it much simpler to check for updates

Yeah, that's true. It will be time consuming.

Considering the frequency I expect to update this, I think this would be very time consuming. Though I will look into ways to automating it, because it would make it much simpler to check for updates

Yeah, that's true. It will be time consuming.

I got it working with a GitHub action, so now every time I update the spam text file it creates a new release named and tagged with the date

I got it working with a GitHub action, so now every time I update the spam text file it creates a new release named and tagged with the date

I got it working with a GitHub action, so now every time I update the spam text file it creates a new release named and tagged with the date

Wow! That's epic. Thanks


Karma delegate does not work

The Karma render delegate does not currently work when using a custom build of this repo. It shows up in the viewport menu, but when I pick it, the viewer just redraws with the currently active delegate, and when I look in the viewport menu again, the Karma entry has disappeared.
I did notice that there is a $HFS/houdini/dso/usd/USD_Karma.so is not mirrored by any of the compiled components in this repo. I'm not sure if the contents of that lib are being built into one of the other libs, but that's my prime suspect right now.

This should work in the 19.0 and 19.5 branches.


add middleware entry point to preprocess messages

@benbrown i've been using this in my fork of botkit and I think at lot of people would find it useful. it introduces a middleware layer before triggering the direct_message, ambient, direction_mention and mention events. This allows for message normalization/preprocessing. for example I could write something like this:
const normalize = (bot, message, next) => {
  message.text = message.text.replace('gonna', 'going to')
  next()
}

const BotController = Botkit.slackbot({
  // can be an array of functions
  middleware: normalize
})

that's a pretty simple example but i can imagine people writing middleware to normalize common typos, slang, contractions, etc. What do you think? I'll write up the documentation and provide a solid example if you're into it.

@mikehmorrissey this seems useful! I think it would be great to have a set of standard normalization functions that we could drop in. Let's reach out in dev4slack.slack.com and see if anyone's interested in collaborating on this. Also let's poll the level of interest in this feature. I know that I have at least one bot that should be using something like this.

It would be nice—bear in mind I'm somewhat new to Node and Node idioms—if things were namespaces in such a way as to be able to add new middleware at different points in the flow. For example, I am wanting to add a middleware hook around local cacheing of channel/user/message objects.

Instead of passing a variable to the constructor why don't we use ExpressJs' app.use() typing? It seems more understandable and may afford multiple middlewares at the same time.
What do you think @mikehmorrissey ?

Or both!

@DEGoodmanWilson @anonrig @benbrown @RafaelCosman  thanks for the feedback! I definitely agree that it needs some naming work to allow for middleware in other parts of the event flow. Does anyone have a suggestion for this particular instance? I'm thinking preprocessor instead of middleware.
I think we can easily do both the constructor and the expressJS style. how i currently have it allows for setting middleware both ways.
const BotController = Botkit.slackbot({
  preprocessor: [normalize, unslang]
})

BotController.preprocessor.use(simplify)

The naming middleware is more fit to this situation. I really liked this naming style.
BotController.use(simplify);

or
BotController.use(function(data) {} );

@anonrig with the .use syntax, how do we tell Botkit at which point in the process the function should be fired?

The function shouldn't be fired actually. We can use event driven programming and have an enum of events in the botkit code. With each specific function, we can fire that event with a compatible callback mechanism where a preprocessed function will have access to.
What do you guys think about it?

I'll leave this one to the experts. @benbrown, @mikehmorrissey?

@anonrig not sure exactly what you are suggesting. I think my current implementation is pretty simple to use and understand.
@benbrown @RafaelCosman I just saw an interesting module come out that would have fit perfectly as preprocessing middleware https://blog.beepboophq.com/natural-language-slackbots-with-wit-ai-and-beep-boop-c007cf303c04#.v1egcp1zk

Still thinking about this! I plan on adding in some middleware hooks soon, but I am still researching the best way to do so.

@benbrown what are you thinking?

I'd say if you're going to call them "middleware", which seems appropriate given @mikehmorrissey's first example, then I think will make the most sense to people using Express to do what @anonrig is suggesting. I would have messages pass through each middleware in the order it was registered.
Whatever syntax you choose, I would suggest picking only one. Having two ways to support the same thing increases your complexity, docs, tests, etc.

is this pattern also going to work for adapting output to various clients? eg Slack may need a message packaged in a different way than hipchat and that can be delegated to the right middleware?
I guess hubot uses the "adapter" pattern for this, but it wasn't flexible enough to support anything other than lowest common denominator see this issue:
https://github.com/github/hubot/issues/1036#issuecomment-178240267

@benbrown feel free to close this. seems like you have a better approach on the middleware branch!


consider text change "reset"

Consider changing “Reset” button text to “New Client” or similar sentiment

'New Client' to match the left-hand-side fixed button would be consistent. (The button on the left used to say 'Reset', too. I think we just forgot the last-form-section button during that change.)


Skip backtrace for pending examples

fixes #2956
# spec/spec_helper.rb
RSpec.configure do |c|
  c.pending_failure_output = :no_backtrace
  # ...
end

:tada:
$ rspec spec/a_spec.rb
Run options: exclude {:ruby=>#<Proc: ./spec/spec_helper.rb:111>}

Randomized with seed 9609

  pending (PENDING: No reason given)
  fails (FAILED - 1)

Pending: (Failures listed here are expected and do not affect your suite's status)

  1) pending
     # No reason given
     Failure/Error: expect(1).to eq(2)

       expected: 2
            got: 1

       (compared using ==)

Failures:

  1) fails
     Failure/Error: expect(1).to eq(2)

       expected: 2
            got: 1

       (compared using ==)
     # /Users/pirj/source/rspec-dev/repos/rspec-support/lib/rspec/support.rb:102:in `block in <module:Support>'
     # /Users/pirj/source/rspec-dev/repos/rspec-support/lib/rspec/support.rb:111:in `notify_failure'

Is this a correct approach?
I'll write specs for this and will handle making it the default in 4-0-dev.

I wonder if it should even be more succinct, because 99% (I guess) of the times the details about pending specs don't matter.
It could be shown maybe like the summary of failed examples:
Taking output of https://github.com/rspec/rspec-mocks/runs/6129989849?check_suite_focus=true:
Pending examples:

rspec ./spec/rspec/mocks/verifying_doubles/class_double_with_class_loaded_spec.rb:167 # A class double with the doubled class loaded when `.new` is stubbed on a class with a private `new` uses the method signature from `#initialize` for arg verification
rspec ./spec/rspec/mocks/partial_double_spec.rb:611 # when verify_partial_doubles configuration option is set when `.new` is stubbed on a class with a private `new` uses the method signature from `#initialize` for arg verification

Or maybe like the profiler output:
 Pending examples:
  RSpec::Mocks behaves like library wide checks has no malformed whitespace
    /home/runner/work/rspec-mocks/rspec-support/lib/rspec/support/spec/library_wide_checks.rb:142
  Loading rspec/mocks/standalone exposes the RSpec::Mocks API on `main`
    ./spec/rspec/mocks/standalone_spec.rb:7
  #any_instance setting a message expectation with an expectation is set on a method that exists fails if an instance is created but no invocation occurs
    ./spec/rspec/mocks/any_instance_spec.rb:730

Both are visually distinctive from failures, but just removing the backtrace like above does not make it sufficiently different for me to realize it's not a failure.

I like this output, we don't minimise failures to single lines in the default formatters and we shouldn't here either but we could go further and make this setting something like: pending_failure_output = :full | :no_backtrace | :skip where we print as is (:full, the default for 3.x), print this this (:no_backtrace default for 4.x), or skip entirely that section (:skip, possibly what we'd use on our CI)

We don't seem to refer to pending as failures. What do you think of calling this setting just pending_output to avoid confusion?

Theres a bit of mixed terminiolohy within our code base, as prior to 3.x we only had pending to mean "some spec yet to pass, maybe, so skip" but 3.x split this into "Pending specs are expected failures, they are verified to fail." and "skipped specs are skipped" as far as I know skipped specs already don't raise a failure like case?

We seem to mark skipped examples as pending, too. And they appear as such contributing to the number of pending examples in the footer:
describe ".configuration", :skip do

25 examples, 0 failures, 1 pending

But yes, they are not run and won't fail the build (if they would pass).

This is looking good but I'd love a cucumber feature

My thought exactly. Cracked my teeth with trying to cover this change with specs.

I don't quite understand if this feature will appear in the docs or not. We have a .nav file. And the clear_examples.feature is not listed there, and it's not in the generated docs. But even though it limits features to be shown under Configuration, all of them appear in the docs. So I guess it doesn't matter if we add it to .nav or not - it will appear in generated docs.

Released in 3.13.0, apologies it has taken so long.


Test Tour React

see #23385 for the theory.
React quick starter: https://github.com/facebookincubator/create-react-app/

I have started contributing to React docs, on how to setup VS Code for Chrome debugging:

https://github.com/react-boilerplate/react-boilerplate/pull/1698


[WIP] Dlang update

Motivation for this change
Bring dlang versions to newest versions and refactor everything to be nicer.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build ldc dmd dtools dub

Can somebody please check if the current state of this PR works on macOS?
I upgraded my machine to Mojave and dmd does not build anymore.
I would like to know it it was indeed the updgrade to Mojave.

dmdBuild fails for me: https://gist.github.com/4e91fbbc81327745b36d81d0bce7946d

@GrahamcOfBorg build ldc dmd dtools dub

Thanks!
Yes that's the problem. What version of macOS do you use?

Btw. what's going on on hydra? All darwin builds fail with "canceled by user".

Yes that's the problem. What version of macOS do you use?

10.13

Btw. what's going on on hydra? All darwin builds fail with "canceled by user".

All evaluations (even older ones) were stopped just few hour ago I would guess that they were terminated to drop current backlog. I could find mention of this on IRC https://logs.nix.samueldr.com/nixos/2019-02-18#1971702;

Wow, just wow.
I found the commit which introduced the build failure for dmd: ca1062ea24d7d78ddec59400518fd4bbf7caa685
It's a changed documentation/comment in the make-wrapper. :dizzy_face:

<EMAIL_ADDRESS>explains a bit the details about what is dmd trying to do.

@ThomasMader This is certainly a nice find, but do you have an explanation for what is going on?

Not yet but that commit seems not to be the correct one.
When I rebase my PR branch to ca1062e~1 I get the same error.
If I do the same on master branch I get a download for dmd package.
So it's probably something machine specific and I need to redo my bisect because I marked as good when a download was available.

@GrahamcOfBorg build ldc dmd dtools dub

Ok let's get this into master for now before the branch off. It's important to update the packages to the new versions and all the other changes make everything much more resilient.
The dmd problem with the "-run" parameter on macOS is not understood yet but I disabled the failing tests for now to get a working build and this situation is better than what is currently in master.
I was able to reproduce that I can not successfully build revisions to which there are packages on hydra from master. So it has something to do with the machine.
I will analyse the problem further and open a PR or issue depending on the outcome and link back to this PR as well.
As I did not include the error message here yet here it is:
/var/tmp/dmd_runWK6b1G: Permission denied
core.thread.ThreadError@core/thread.d(3197): Unable to load thread state

It happens when dmd is used with the -run parameter which compiles, links and runs the program without leaving any files on the machine. As it is not used as heavily and not needed at all for building other packages it's not a blocker.

@GrahamcOfBorg build ldc

I've tried to rebuild this on macOS. This time I get a failure in dtools: https://gist.github.com/veprbl/3e0be30bd86142418232f6bf1ff57147

I've tried to rebuild this on macOS. This time I get a failure in dtools: https://gist.github.com/veprbl/3e0be30bd86142418232f6bf1ff57147

Sorry, forgot to build dtools on macOS. Fixed it by disabling the only test which was using the -run parameter for now.
I also changed the names you suggested.

I think you squashed two dub-related commits so the new commit message "dub: Disable network tests because they add impurities" doesn't mention the version bump.

No dub stayed at the same version because there is no new version yet.
I really disabled only the network tests and the rdmd test because of the -run issue.

@ThomasMader Thank you!


:unlet $FOOBAR

When an environment variable isn't set, exists() return false. We can assign a value to the variable with :let, after which point it exists. But we can't revert to an non-existent state (related to unsetenv (3C))
call assert_false(exists('$FOOBAR'))
let $FOOBAR = 1
call assert_true(exists('$FOOBAR'))
unlet $FOOBAR
call assert_false(exists('$FOOBAR'))

It's in the todo list:
Can we make ":unlet $VAR" use unsetenv() to delete the env var?
What for systems that don't have unsetenv()?

If I would want to implement this, where do I start?

As I mentioned in https://github.com/vim/vim/issues/2854, Vim doesn't have a way to revert $TZ. So we should implement unlet $FOOBAR.

It looks like this issue can be closed.  Patch 8.0.1832 took care of this.

closing.


Add tabs when there's more than one terminal active.

A couple notes here:

Let me know if I'm missing something with themes here that could make this change simpler. It took me a while to track down various missing styles and make the tabs actually render.

Right now the tabs show up on all devices, but I was considering making them layout-large only. Here's a screenshot on the N5. I actually think it looks pretty good, but I'm happy to make it large screens only if you want.

And I found a FC while trying :

Open a connection that ask for a password,
Enter bad passwords as long as ConnectBot ask for it,
When ConnectBot detect connection reset and ask to close say "Yes"
FC

E/AndroidRuntime(31567): java.lang.IllegalStateException: The application's PagerAdapter changed the adapter's contents without calling PagerAdapter#notifyDataSetChanged! Expected adapter item count: 2, found: 1 Pager id: org.connectbot.debug:id/console_flip Pager class: class android.support.v4.view.ViewPager Problematic adapter: class org.connectbot.ConsoleActivity$TerminalPagerAdapter
E/AndroidRuntime(31567): 	at android.support.v4.view.ViewPager.populate(ViewPager.java:999)
E/AndroidRuntime(31567): 	at android.support.v4.view.ViewPager.populate(ViewPager.java:951)
E/AndroidRuntime(31567): 	at android.support.v4.view.ViewPager.onMeasure(ViewPager.java:1473)
E/AndroidRuntime(31567): 	at android.view.View.layout(View.java:15658)
E/AndroidRuntime(31567): 	at android.view.ViewGroup.layout(ViewGroup.java:5038)
E/AndroidRuntime(31567): 	at android.widget.RelativeLayout.onLayout(RelativeLayout.java:1076)
E/AndroidRuntime(31567): 	at android.view.View.layout(View.java:15671)
E/AndroidRuntime(31567): 	at android.view.ViewGroup.layout(ViewGroup.java:5038)
E/AndroidRuntime(31567): 	at android.widget.FrameLayout.layoutChildren(FrameLayout.java:579)
E/AndroidRuntime(31567): 	at android.widget.FrameLayout.onLayout(FrameLayout.java:514)
E/AndroidRuntime(31567): 	at android.view.View.layout(View.java:15671)
E/AndroidRuntime(31567): 	at android.view.ViewGroup.layout(ViewGroup.java:5038)
E/AndroidRuntime(31567): 	at com.android.internal.widget.ActionBarOverlayLayout.onLayout(ActionBarOverlayLayout.java:494)
E/AndroidRuntime(31567): 	at android.view.View.layout(View.java:15671)
E/AndroidRuntime(31567): 	at android.view.ViewGroup.layout(ViewGroup.java:5038)
E/AndroidRuntime(31567): 	at android.widget.FrameLayout.layoutChildren(FrameLayout.java:579)
E/AndroidRuntime(31567): 	at android.widget.FrameLayout.onLayout(FrameLayout.java:514)
E/AndroidRuntime(31567): 	at android.view.View.layout(View.java:15671)
E/AndroidRuntime(31567): 	at android.view.ViewGroup.layout(ViewGroup.java:5038)
E/AndroidRuntime(31567): 	at android.view.ViewRootImpl.performLayout(ViewRootImpl.java:2086)
E/AndroidRuntime(31567): 	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1843)
E/AndroidRuntime(31567): 	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1061)
E/AndroidRuntime(31567): 	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:5885)
E/AndroidRuntime(31567): 	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:767)
E/AndroidRuntime(31567): 	at android.view.Choreographer.doCallbacks(Choreographer.java:580)
E/AndroidRuntime(31567): 	at android.view.Choreographer.doFrame(Choreographer.java:550)
E/AndroidRuntime(31567): 	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:753)
E/AndroidRuntime(31567): 	at android.os.Handler.handleCallback(Handler.java:739)
E/AndroidRuntime(31567): 	at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime(31567): 	at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime(31567): 	at android.app.ActivityThread.main(ActivityThread.java:5254)
E/AndroidRuntime(31567): 	at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime(31567): 	at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime(31567): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
E/AndroidRuntime(31567): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)

Thanks, @alescdb. Are you able to repro that without this PR on master? It seems more likely that this would have been caused from one of my other recent changes.

No I can't reproduce on master.
OK, I found the exact actions to reproduce :

Open a first connection,
Open a second connection,
Return to the first connection by swipping (not with Tabs)
Exit (with command line exit), ConnectBot ask "Close Yes/No", say "Yes"
FC

Weird... I can't seem to repro with your steps here. I'll keep messing around and trying to break it.

If it can help I made a video, I can reproduce 100% (only swipe cause FC not clicking on the tab) :
http://youtu.be/WwkuQs-E6SY

Thanks! Can you try again now? I think I've tracked it down and fixed it, but you seem to have a more reliable repro environment for some reason.

Same behaviour with commit 56f4def53bfe7bf1886a525c9a7cd67324091a51

Are you sure tabs are what you want here? We had another branch where someone had converted everything to Fragments where we could have the host list on the left and switch between them there.
At any rate, I think this needs to be made big screen only. The action bar already takes up too much room on the phone.

@kruton: Yeah, I think tabs are the nicer solution from a UX perspective than a drawer panel. I'll work on making this large screen only.
@alescdb: Even exactly following your repro steps from the video and in your comments, I'm totally unable to repro for some reason on my Nexus 5 or Nexus 9. What device and Android version are you on? @kruton, are you able to repro this?

Ah, now I have it happening at least enough to get some breakpoints in and see what's going on. I'll keep digging.

@jklein24 I have a Nexus 5 and a Nexus 9, both on the latest 5.1.1
Just some ideas for small devices :

A dropdown in ActionBar,
Navigation Tabs in ActionBar,
PagerTitleStrip (which is smaller than tabs and can have a lot of items)

cc @bengolds for UX input on small screens

Status of the crash:
I believe this is a threading issue because the bridges array (owned by the TerminalManager) is the backing data source of the adapter. When a bridge is disconnected, TerminalManager removes the bridge from the bridges array and then sends a message to ConsoleActivity, which calls notifyDataSetChanged. From my added logs, it looks like when the crash occurs, it happens after the message is sent by TerminalManager, but before it's received by ConsoleActivity. If there's a layout right at that point, things explode.
Maybe if there's a disconnectHandler, we should assume it will also handle the removal from the bridges array so that it can be done on the UI thread. That seems like pretty nasty encapsulation breaking, though. I'm still pretty new to Android development so the concept of which pieces need to be on the UI thread and how to coordinate that is all a bit foreign to me. Is there a common pattern that I'm missing here?

OK, now I think I got it for real! @alescdb, please tell me you can't repro still :-). Also if either of you knows a better way to solve this issue in TerminalBridge, let me know. As I mentioned, I'm new to the best-practices for multi-threading on Android.

@jklein24 I confirm that commit b067b78b004f8dd2607fe1acea0e7ec47e108212 (with tabs) and 64f59c9c98b7b827f1475e8e98cb3929ba0c4d93 (without tabs on my N5) are both OK, no more FC !


[Question] The results of the local model are inconsistent with the web ui in the demo

Question
May I ask, based on the same test data, using the llava: 34b-v1.6-q3_K_S model locally and the llava v1.6-34b model for web UI in the demo, there is a significant difference in the results obtained between the two. The results in web UI are significantly better than those in the local environment. What is the reason for this?
The problem is: Which country recorded the highest death rates due to outdoor air pollution over the years?
The result in the web UI is: The graph you've provided shows the outdoor air pollution death rate for several countries from 2005 to 2012. The country with the highest death rate due to outdoor air pollution over the years shown on the graph is Myanmar. The line representing Myanmar's death rate is the highest among the countries depicted, indicating a higher number of deaths attributed to outdoor air pollution per 100,000 people.
The local result is：India recorded the highest death rates due to outdoor air pollution over the years according to this chart

I suffered the issue here. The web demo version ran this "llava-v1.6-34b" version of llava. Given the "34b-v1.6" version of model in Ollama, the results of queries into these two models are significantly different as well. The one in the web demo outperformed the one in ollama. May I know which tag in Ollama can match the performance in the web demo?

I am seeing the exact same thing.
Currently, I am running Llava:34b-V1.6 in Ollama, and it just does not recognize things in a form and hallucinates values - whereas the HF-hosted Llava 34b (https://llava.hliu.cc) does a great job.
Who should we ping here? .cc @haotian-liu
Thanks!


densewarp incompatible with Python2

Hi Alex!
I just wanted to raise this as a GitHub issue since Python2 is deprecated, but the fix to make the function compatible is pretty trivial.
To highlight the issue I ran into,

I tried applying Timewarping to a 3D array (ntrials x ntime x ndim) of data.
I was successfully was able to apply ShiftWarping to the data (and the results made sense)
I was able to apply PiecewiseWarping with n_knots=0 (linear timewarping), but the output did not make sense.

I dove into the code and found that in piecewisewarp.py, the function densewarp has this line (Line 557, https://github.com/ahwillia/affinewarp/blob/master/affinewarp/piecewisewarp.py#L557) :
            # fraction of trial complete
            x = t / (T - 1)

In Python2, this line results in integer division which results in x=0 for all indices in T except for the last index (x=1). To fix this, I simply did:
            # fraction of trial complete
            x = float(t) / (T - 1)

This is not an issue in Python 3, as this line does not result in integer division But I just wanted to give you a heads up in case you wanted to make the change to the code since it is forward-compatible with Python3. Thanks!
Best,
Lahiru

Thanks! I'm not sure I want to officially support Python 2, since there might be other minor bugs / incompatibilities that I'm unaware of.

I added a warning statement for anyone using Python 2, see - https://github.com/ahwillia/affinewarp/commit/95e91958f36fc69042754618d44f0f97f1f91f97


build: wrap artifacts in directory

It's considered best practice to nest release artifacts in a directory before archiving the result. When users extract the archive, it keeps the artifacts together and labels them with their version number. This is especially helpful when multiple versions are present.

Holding off on this since it's going to break assumptions in CI scripts when the version isn't pinned. We're going to wait until there is another breaking change and do it all at once.


docs: Update example flame graphs

We fixed a bug affecting how native stacks are shown in flame graphs.
Update the flame graphs in our documentation to pick up the fix.
Signed-off-by: Matt Wozniski<EMAIL_ADDRESS>

I will trust you here 😆

I will trust you here 😆

If you do want to review, cloning and opening the .html files in a browser is the way to go 😉

If you do want to review, cloning and opening the .html files in a browser

cloning?!? On my phone?!?


Support for Laravel 5.5 Automatic Package Discovery

@llaski Thanks for your pull request, I will update as soon as possible.


w2uiGrid: Disable delete button on row select

I want to be able to enable/disable the delete button depending on the row that is selected.   Is there a (easy) way to do so.
Thanks

see onSelect event and do it in onComplete function
http://w2ui.com/web/docs/w2grid.onSelect
http://w2ui.com/web/docs/utils/events
Please submit only bugs here, questions -> stack overflow.

Thank you. I moved the discussion here: http://stackoverflow.com/questions/30028366/w2uigrid-disable-delete-button-on-row-select


Revert splitting Peerset into PeerStore & ProtocolController

This PR is intended to remove the possible cause of the peer count instabilities before the release. There are "more proper" fixes on the way, but they haven't been thoroughly tested, so just reverting seems to be the best option.

I'm not sure if we want merge this after all. The peer count during my GCP tests is flaky and it looks like this gives marginal improvement. Based on these findings I bisected the history and at least for me, for some bizarre reason, the parity-db update causes instability in the peer count. Here are peer counts before and after the update.

I don't understand why peer stability would have anything to do with parity-db

I have converted the PR into draft so somebody accidentally do not merge it.

The parity-db change has definitely changed something but it's not used anywhere in sc-network. The number of OpenDesiredByRemote(SetId(0)) has halved between the parity-db versions. The only thing I can come up with is that the substream spam is caused by some local async issue and that is alleviated by the parity-db change, this PR and disabling inbound connections for light clients. Considering that we want this spam to decrease and that the logs don't seem to indicate any other concerns, let's not merge this PR and instead focus on shipping QUIC + hole punching sooner.


OG add twitter card and og image

Changes proposed

Better OG images

Why
While sharing LinkFree links on Discord or Twitter, I noticed that the LinkFree OG can be improved.
I have some prior experience with creating dynamic OG images. So, I created one for LinkFree 🤗
How
Repo: https://github.com/codinasion/LinkFree-OG
OG images are created by Github actions and updates every 6/12 hours (not decided yet!)
The OG images are provided through an API 👉🏻 https://linkfreeog.codinasion.org
There are two separate APIs, one for LinkFree and the other for User Profile
LinkFree: https://linkfreeog.codinasion.org
Profile: https://linkfreeog.codinasion.org/<GITHUB_USERNAME>
Showcase

What difference it makes (on Discord)

Note There are some profile OGs missing because LinkFree API return Internal Server Error
Reference 👉🏻 https://linkfree.eddiehub.io/api/users/ibrahimq21

Note There are some profile OGs missing because LinkFree API return Internal Server Error
Reference 👉🏻 linkfree.eddiehub.io/api/users/ibrahimq21

Hey @Panquesito7
any fix for this 🤔

Update
Now able to handle all profiles 🚀 🎉
Link: https://linkfreeog.codinasion.org/ibrahimq21

How
If LinkFree API response is 500 then GET profile Json directly from Github

Note Some profiles Json have incorrect data

url vs Url vs URL
https://github.com/EddieHubCommunity/LinkFree/blob/10d7d70bccff54cf782dd656393dc18d4b9d8941/data/Drabzit.json#L8-L21
Broken Links
https://github.com/EddieHubCommunity/LinkFree/blob/10d7d70bccff54cf782dd656393dc18d4b9d8941/data/Drabzit.json#L15

Hey @eddiejaoude @Pradumnasaraf
Could you please review this PR 👀
Thank you in advance for your time and consideration 🤗

Thank you for your contribution. It is better to raise an issue first so these can be discussed without you doing work first.
It looks good, but 3rd party services like this go up and down, and therefore have a negative effect on our app.
Currently I am not keen on introducing this dependency. Maybe we can do something similar on a smaller scale as part of the application itself?

Sure, thanks


106: add: toggle turn off popup on mnemonic login

Description

closes #106
Checklist

[x] Targeted PR against correct branch.
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[x] Wrote unit tests.
[x] Run flutter format.
[ ] Updated the documentation.
[ ] Added an entry to the CHANGELOG.md file.
[x] Re-reviewed Files changed in the Github PR explorer.

added


Add fsspec to HDFS CI build

Currently, the HDFS build is failing on Travis due to the recent addition of fsspec as a dependency (ref https://travis-ci.org/dask/dask/jobs/561785392#L685-L702)

There are some test failures in dask/bytes/tests/test_hdfs.py. @martindurant IIUC the PyArrowHDFS class in fsspec should pass method calls to the underlying pa.hdfs.HadoopFileSystem instance. But based on https://travis-ci.org/dask/dask/jobs/561862864#L748-L775 it appears the walk method for the AbstractFileSystem base class is getting called instead. This is my first time looking at the fsspec code base, so I could be missing something though

I'll have a look

Yep, needed fixing - wasn't being tested.
https://github.com/intake/filesystem_spec/pull/72 did the work, and changes to dockerfile and tests coming here soon (separate PR).

Superseded by #5130


simple-cipher: add test to check that messages longer than the key can be decoded.

I just come across a solution for the "Simple Cipher" exercise from a student, which could encode messages longer than the key but failed to decode messages longer than the key, and yet, because we haven't a test to cover this, all tests would pass giving an illusion of correctness.
This pull request adds a test to also check that a message longer than the key can be decoded.

Actually, looking at the canonical data, you probably took it from there:
{
  "description": "Can handle messages longer than the key",
  "property": "encode",
  "input": {
    "key": "abc",
    "plaintext": "iamapandabear"
  },
  "expected": "iboaqcnecbfcr"
}

This expects a plaintext of `"iamapandabear" and expected value of "iboaqcnecbfcr" after encode.

Silly me. Copy / paste error... 🤦♂. I'll fix as soon as I get home (the invoked method should be decode rather than encode. Actually you've reminded me that I need to update the test canonical data first / instead. Thanks!

@SleeplessByte: Fixed! Correspondent problem specifications PR: exercism/problem-specifications#1460.

exercism/problem-specifications#1460 has been merged @SleeplessByte.

You're the best @paparomeo

This was bugging me all the time when mentoring. As I came around to addressing this here I found it was fixed already. Many thanks!


Automatically use the most recently installed version of Terraform

I just installed tfenv and tried to get setup with the latest version of Terraform, but ran into an unexpected bump along the way.
$> tfenv install latest
[INFO] Installing Terraform v0.9.4
[INFO] Downloading release tarball from https://releases.hashicorp.com/terraform/0.9.4/terraform_0.9.4_darwin_amd64.zip
######################################################################## 100.0%
[INFO] Downloading SHA hash file from https://releases.hashicorp.com/terraform/0.9.4/terraform_0.9.4_SHA256SUMS
tfenv: tfenv-install: [WARN] No keybase install found, skipping GPG signature verification
Archive:  tfenv_download.aid7dB/terraform_0.9.4_darwin_amd64.zip
  inflating: /code/tfenv/versions/0.9.4/terraform
[INFO] Installation of terraform v0.9.4 successful
$> which terraform
/code/tfenv/bin/terraform
$> terraform --version
cat: /code/tfenv/version: No such file or directory
tfenv: /code/tfenv/libexec/tfenv-version-name: Version could not be resolved (set by /code/tfenv/version or tfenv use <version>)
/code/tfenv/libexec/tfenv-exec: line 22: /code/tfenv/versions//terraform: No such file or directory

I was expecting to be able to use the version of terraform that I just installed without needing the extra step of $> tfenv use latest. I got everything working once I realized I had to do that, but it would be a nice UX improvement if it did that automatically upon install of a version.
Thoughts?

@conorgil
Sorry for late reply.
A contributor kindly implemented the feature. Please try updating tfenv latest 😺
https://github.com/kamatama41/tfenv/pull/50

Thanks for linking to #50


Lua Error: string expected, got nil

Getting the following error when I try to analyze someIP packets: 'Lua Error : PATH\someip.lua:129: bad argument #3 to '__newindex' (string expected, got nil)' . If needed I will uploaded a packet for analysis.

Hi, probably the packet has a wrong message type.
I can add maybe a default type for unknown type number.
Could you please upload the pcap?
Thanks.

Here is a packet sample.
Lua error.zip

This packet SOME/IP header is malformed, some fields are 0xFF like the protocol version, also the message type is 0xFF but there no such type. It is true that the code needs to handle the errors. I can have a look maybe next week to see how much is needed to be done.
But anyway you should try to see why you have malformed header.
Cheers.

That cleared things out. Thanks!

try the develop branch, should be OK now
https://github.com/jamores/eth-ws-someip/tree/develop

Latest build shows some weird Info, uploading a picture and a packet.

Offset.zip

yes your message type is still 0xFF


Use CreateProcess as config for the Process backend

This is more a proposal for discussion. Feel free to reformulate.

I like the versatility that having  Config :: CreateProcess provides, and from a minimality standpoint it makes sense, but I have two problems with it:

I'd say the purpose of smtlib-backends is threefold: a) provide a common interface to different backends, b) make it easy to use those backends and c) take care of optimizing stuff. With this API a) and c) would still be provided but I feel like b) wouldn't: now if you want to switch from the default solver you have to import the process library and learn how to use it (even if it's just the basics). I'm all for giving more advanced possibilities but I don't want that to impact the basic use of the library, which will probably be how most people use it anyways.
I personally don't know what all the fields in CreateProcess do but now I should try to understand them to ensure they're not conflicting with the rest of the library. For instance, for all I know delegate_ctlc might affect and even break the behavior of Process.close. We could just say that the behavior is unspecified but then why provide the options in the first place ? We might be better off just telling the user to implement their own backend.

Makes sense to me.
Note that while the Handle type is exposed, the user can create the process herself and fill in the Handle fields manually.


preparations for WEB-Flasher

This PR solves 3 issues

the FW-name is created dependent on the target MCU  (ESP32 / ESP8266) to be properly detected by the WEB Flasher
the _FLASHER version binary for ESP8266 is created
the python scripts are written to be ready to run in GitHub Actions as well as on the local PC

I'm going to merge and tag this as prerelease to make a live-test

@sumnerboy12
One other thing:
One might argue that the repo has ESP32  in its name, but after we enabled esp8266 as well, that's not true anymore.
Should we rename those to ...-ESP-... instead?  as you have for your TempSensor?

Yeah I think they should all be called ESP personally. But not sure I can be arsed changing them all.

I can't make the change , don't have permission to do that.

Don't think I do either on SuperHouse repos.


[1.7.10, 1.12.2] High resolution skins (> 30 KB) are not visible on the second client (upload via GitHub Gist)

When I try to set a skin with a resolution of 1024x512, and 606 KB weight (20 times the maximum limit for local export, with a maximum of 30 KB), then on the second client (connection via "Open to LAN") instead of the skin, above player displayed:
Model failed to load: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

GitHub Gist was used for export, on 1 client side (who uploaded) the skin is displayed normally, Gist is available, the connection is stable. As for the error, I only found on the Internet that this is due to  “The Java application cannot create a trusted TLS / SSL connection. Perhaps the application is trying to connect to the server via HTTPS and the server is using a self-signed certificate or a certificate that is not accepted Java node."
I am more than sure that I am doing something wrong, but so far I have not found a solution for myself. In addition, this problem exists for me on both 1.7.10 and 1.12.2, so again, most likely it’s me doing something wrong, but neither in “Exporting” nor in any other opened issue I didn't find anything

I'm using prism launcher with a custom java version - jdk1.8.0_351. Is this still a problem? If so, which version should I use, 8u391?

Quite strange, but this is true. Upgrading from jdk1.8.0_351 to jdk1.8.0_391 solved the problem, thanks!


Create tests for ride-hailing/BidParams using jest.

first-timers-only
This issue is tagged :octocat: first-timers-only. It is only for people who have never contributed to open source before, and are looking for an easy way take their first steps.
Consider this your chance to dip your toe into the world of open-source, and get some bragging rights for writing code that makes drones fly, lets cars find charging stations, helps people and goods get from place to place, and more.
Find more first-timers-only issues from DAV Foundation here.
Thank you for your help :heart:
What is this project?
DAV (Decentralized Autonomous Vehicles) is a new foundation working to build an open-source infrastructure for autonomous vehicles (cars, drones, trucks, robots, and all the service providers around them) to communicate and transact with each other over blockchain.
As an organization that believes in building a large community of open-source contributors, we often create issues like this one to help people take their first few steps into the world of open source.
dav-js
This SDK enabled integrating any client side JS and NodeJS code with the DAV Network.
How you can help
The Issue
Create tests for ride-hailing/BidParams using jest.
You need to create tests to check that the serialize and deserialize methods work as expected.
Please use the test file for class NeedParams as a basis for your new code.

Function serialize in class BidParams must return a JSON object that contains all properties defined in the BidParams instance.

Function deserialize in class BidParams receives a JSON string and must initialize all the properties of the BidParams instance with the values in the JSON string.

bidParams1.desrialize(bidParams2.serialize()) == bidParams2 must therefore always be true.
NOTE: Some names are changed between protocol string representation of instance properties:

location is internally represented as { lat , lon } but serialized as { latitude , longitude }
Private properties are internally prefixed with _ but serialized without the prefix. i.e. _protocol becomes protocol

Contributing to dav-js

[ ] Make sure this issue is labeled up-for-grabs and not labeled claimed, to verify no one else is working on it.
[ ] Comment in this issue that you would like to do it.
[ ] Open dav-js GitHub page and click the ★ Star and then ⑂ Fork buttons.
[ ] Clone a copy to your local machine with $ git clone git@github.com:YOUR-GITHUB-USER-NAME/dav-js.git
[ ] Code Code Code
[ ] Once you've made sure all your changes work correctly and committed all your changes, push your local changes back to github with $ git push -u origin master
[ ] Visit your fork on GitHub.com (https://github.com/YOUR-USER-NAME/dav-js) and create a pull request for your changes.
[ ] Make sure your pull request describes exactly what you changed and references this issue (include the issue number in the title like this: #7)
[ ] Please do not fix more than one issue at a time. Your pull request should only fix what is described in this issue.

Asking for help
We appreciate your effort in taking the time to work on this issue and help out the open source community and the foundation. If you need any help, feel free to ask below or in our gitter channel. We are always happy to help 😄

Hi! I would like to handle this issue

Hello @VictoriaKuznetsova it's all yours :smile:

I have question about type of currentVehicleLocation in BidParams. I can't find a class with that name. Maybe it shoud be interface ILocation?

@VictoriaKuznetsova You spotted a bug 👍
I just fixed it and pushed the code. It now imports ILocation.

About this note:
location is internally represented as { lat , lon } but serialized as { latitude , longitude }
It doesn't work this way. Function serialize returns { lat , lon } as-is.
Is it by design?

@srfrnk Can you look at @VictoriaKuznetsova 's comment?

About this note:
location is internally represented as { lat , lon } but serialized as { latitude , longitude }
It doesn't work this way. Function serialize returns { lat , lon } as-is.
Is it by design?

This was irrelevant - removed it. Nice catch.

Great PR @VictoriaKuznetsova! Merged.

Thank you


BUG: Unmarshalling nullable objects

According to my tests, the latest openapi-core release (0.13.3 at the time of this writing) is ignoring the nullable keyword when unmarshalling an object, so it fails here:
  File "/home/berislav/.virtualenvs/tm/lib/python3.7/site-packages/openapi_core/unmarshalling/schemas/unmarshallers.py", line 201, in _unmarshal_properties
    value_props_names = value.keys()
AttributeError: 'NoneType' object has no attribute 'keys'

I will write a quick minimum test case when I have a minute, opening this now if someone can take a look.

Can confirm given issue.
I've managed to fix it by entirely remove nullable: true specifications from my OpenAPI schemas.

Here's a minimal example I could whip up:
import json

from openapi_core import create_spec
from openapi_core.validation.request.datatypes import RequestParameters, OpenAPIRequest
from openapi_core.validation.request.validators import RequestValidator

spec_dict = {
    "openapi": "3.0.1",
    "info": {"title": "Test Spec", "version": "0.0.0"},
    "servers": [{"url": "http://localhost"}],
    "paths": {
        "/test": {
            "post": {
                "requestBody": {
                    "content": {
                        "application/json": {
                            "schema": {
                                "type": "object",
                                "properties": {
                                    "foo": {
                                        "type": "object",
                                        "nullable": True
                                    },
                                }
                            }
                        }
                    }
                },
                "responses": {"204": {"description": "Empty response."}}
            }
        }
    }
}

spec = create_spec(spec_dict)

request_body = {"foo": None}

request = OpenAPIRequest(
    full_url_pattern="http://localhost/test",
    method="post",
    parameters=RequestParameters(),
    body=json.dumps(request_body),
    mimetype="application/json",
)

result = RequestValidator(spec).validate(request)


Possibility to utilize categorical data

My feature dataset contains a lot of categorical data... I found qlib only supports float dump. Is there a practical way to dump and train with categorical data? Thanks in advance.

The underlying .bin data does not support categorical data directly.
You may convert it to float before storing them
Thanks.

The underlying .bin data does not support categorical data directly.
You may convert it to float before storing them
Thanks.

Thanks so much for your reply. I'm giving it a try.


On mobile, avatars are uncontrollable big at pull request's Files page

Description
On Android Chrome, avatars are uncontrollable big at comments on pull request's Files page.
Example page: https://git.calculate-linux.org/calculate/calculate-overlay/pulls/22/files#issuecomment-361
Gitea Version
1.16.9
Can you reproduce the bug on the Gitea demo site?
No.
Log Gist
No response
Screenshots

Git Version
No response
Operating System
No response
How are you running Gitea?
I visit it via a browser.
Database
None

Well, can't reproduce on reproduce the bug on the Gitea demo site.
Maybe have been already fixed or is a theme issue.
Fill free to close after an analysis.

It has been fixed. Please upgrade to latest.


Consider setting num retries to a fixed value

Idea has been bounced around in some internal conversations, filing for tracking.
cc @samrogerson

fixed in #754


Error when building the library on OSX

  Building Torch → `~/.julia/packages/Torch/gHnkT/deps/build.log`
┌ Error: Error building `Torch`, showing the last 100 of log:
│   inflating: libtorch/include/torch/csrc/utils/tensor_numpy.h
│   inflating: libtorch/include/torch/csrc/utils/tensor_qschemes.h
│   inflating: libtorch/include/torch/csrc/utils/tensor_types.h
│   inflating: libtorch/include/torch/csrc/utils/throughput_benchmark-inl.h
│   inflating: libtorch/include/torch/csrc/utils/throughput_benchmark.h
│   inflating: libtorch/include/torch/csrc/utils/tuple_parser.h
│   inflating: libtorch/include/torch/csrc/utils/variadic.h
│   inflating: libtorch/include/torch/csrc/utils.h
│   inflating: libtorch/include/torch/csrc/WindowsTorchApiMacro.h
│   inflating: libtorch/include/torch/custom_class.h
│   inflating: libtorch/include/torch/extension.h
│   inflating: libtorch/include/torch/script.h
│    creating: libtorch/lib/
│   inflating: libtorch/lib/libasmjit.a
│   inflating: libtorch/lib/libbenchmark.a
│   inflating: libtorch/lib/libbenchmark_main.a
│   inflating: libtorch/lib/libc10.dylib
│   inflating: libtorch/lib/libc10d.a
│   inflating: libtorch/lib/libcaffe2_detectron_ops.dylib
│   inflating: libtorch/lib/libcaffe2_module_test_dynamic.dylib
│   inflating: libtorch/lib/libcaffe2_observers.dylib
│   inflating: libtorch/lib/libCaffe2_perfkernels_avx.a
│   inflating: libtorch/lib/libCaffe2_perfkernels_avx2.a
│   inflating: libtorch/lib/libCaffe2_perfkernels_avx512.a
│   inflating: libtorch/lib/libcaffe2_protos.a
│   inflating: libtorch/lib/libclog.a
│   inflating: libtorch/lib/libcpuinfo.a
│   inflating: libtorch/lib/libcpuinfo_internals.a
│   inflating: libtorch/lib/libfbgemm.a
│   inflating: libtorch/lib/libfbjni.dylib
│   inflating: libtorch/lib/libfoxi_loader.a
│   inflating: libtorch/lib/libgloo.a
│   inflating: libtorch/lib/libgmock.a
│   inflating: libtorch/lib/libgmock_main.a
│   inflating: libtorch/lib/libgtest.a
│   inflating: libtorch/lib/libgtest_main.a
│   inflating: libtorch/lib/libiomp5.dylib
│   inflating: libtorch/lib/libmkldnn.a
│   inflating: libtorch/lib/libnnpack.a
│   inflating: libtorch/lib/libnnpack_reference_layers.a
│   inflating: libtorch/lib/libonnx.a
│   inflating: libtorch/lib/libonnx_proto.a
│   inflating: libtorch/lib/libprotobuf-lite.a
│   inflating: libtorch/lib/libprotobuf.a
│   inflating: libtorch/lib/libprotoc.a
│   inflating: libtorch/lib/libpthreadpool.a
│   inflating: libtorch/lib/libpytorch_jni.dylib
│   inflating: libtorch/lib/libpytorch_qnnpack.a
│   inflating: libtorch/lib/libqnnpack.a
│   inflating: libtorch/lib/libshm.dylib
│   inflating: libtorch/lib/libtorch.dylib
│   inflating: libtorch/lib/libtorch_python.dylib
│    creating: libtorch/share/
│    creating: libtorch/share/cmake/
│    creating: libtorch/share/cmake/ATen/
│   inflating: libtorch/share/cmake/ATen/ATenConfig.cmake
│    creating: libtorch/share/cmake/Caffe2/
│   inflating: libtorch/share/cmake/Caffe2/Caffe2Config.cmake
│   inflating: libtorch/share/cmake/Caffe2/Caffe2ConfigVersion.cmake
│   inflating: libtorch/share/cmake/Caffe2/Caffe2Targets-release.cmake
│   inflating: libtorch/share/cmake/Caffe2/Caffe2Targets.cmake
│    creating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/FindCUDA.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/FindCUDNN.cmake
│    creating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/CMakeInitializeConfigs.cmake
│    creating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/make2cmake.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/parse_cubin.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/run_nvcc.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/select_compute_arch.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindPackageHandleStandardArgs.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindPackageMessage.cmake
│    creating: libtorch/share/cmake/Caffe2/public/
│   inflating: libtorch/share/cmake/Caffe2/public/cuda.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/gflags.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/glog.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/mkl.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/mkldnn.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/protobuf.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/threads.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/utils.cmake
│    creating: libtorch/share/cmake/Gloo/
│   inflating: libtorch/share/cmake/Gloo/GlooConfig.cmake
│   inflating: libtorch/share/cmake/Gloo/GlooConfigVersion.cmake
│   inflating: libtorch/share/cmake/Gloo/GlooTargets-release.cmake
│   inflating: libtorch/share/cmake/Gloo/GlooTargets.cmake
│    creating: libtorch/share/cmake/Torch/
│   inflating: libtorch/share/cmake/Torch/TorchConfig.cmake
│   inflating: libtorch/share/cmake/Torch/TorchConfigVersion.cmake
│ ERROR: LoadError: Failed to get libtorch.
│ Stacktrace:
│  [1] error(::String) at ./error.jl:33
│  [2] top-level scope at /Users/hg344/.julia/packages/Torch/gHnkT/deps/build.jl:21
│  [3] include at ./boot.jl:328 [inlined]
│  [4] include_relative(::Module, ::String) at ./loading.jl:1094
│  [5] include(::Module, ::String) at ./Base.jl:31
│  [6] include(::String) at ./client.jl:431
│  [7] top-level scope at none:5
│ in expression starting at /Users/hg344/.julia/packages/Torch/gHnkT/deps/build.jl:16

Setup:
julia> versioninfo()
Julia Version 1.2.0
Commit c6da87ff4b (2019-08-20 00:03 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin18.6.0)
  CPU: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, skylake)
Environment:
  JULIA_CXX_RTTI = 1

Fixed by https://github.com/TuringLang/Torch.jl/commit/e7c1518847805bfef0939977a855304873261d15 @yebai

thanks, that worked. Now I got a new error:
┌ Error: Error building `Torch`, showing the last 100 of log:
│   inflating: libtorch/lib/libprotoc.a
│   inflating: libtorch/lib/libpthreadpool.a
│   inflating: libtorch/lib/libpytorch_jni.dylib
│   inflating: libtorch/lib/libpytorch_qnnpack.a
│   inflating: libtorch/lib/libqnnpack.a
│   inflating: libtorch/lib/libshm.dylib
│   inflating: libtorch/lib/libtorch.dylib
│   inflating: libtorch/lib/libtorch_python.dylib
│    creating: libtorch/share/
│    creating: libtorch/share/cmake/
│    creating: libtorch/share/cmake/ATen/
│   inflating: libtorch/share/cmake/ATen/ATenConfig.cmake
│    creating: libtorch/share/cmake/Caffe2/
│   inflating: libtorch/share/cmake/Caffe2/Caffe2Config.cmake
│   inflating: libtorch/share/cmake/Caffe2/Caffe2ConfigVersion.cmake
│   inflating: libtorch/share/cmake/Caffe2/Caffe2Targets-release.cmake
│   inflating: libtorch/share/cmake/Caffe2/Caffe2Targets.cmake
│    creating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/FindCUDA.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/FindCUDNN.cmake
│    creating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/CMakeInitializeConfigs.cmake
│    creating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/make2cmake.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/parse_cubin.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/run_nvcc.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA/select_compute_arch.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindCUDA.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindPackageHandleStandardArgs.cmake
│   inflating: libtorch/share/cmake/Caffe2/Modules_CUDA_fix/upstream/FindPackageMessage.cmake
│    creating: libtorch/share/cmake/Caffe2/public/
│   inflating: libtorch/share/cmake/Caffe2/public/cuda.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/gflags.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/glog.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/mkl.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/mkldnn.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/protobuf.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/threads.cmake
│   inflating: libtorch/share/cmake/Caffe2/public/utils.cmake
│    creating: libtorch/share/cmake/Gloo/
│   inflating: libtorch/share/cmake/Gloo/GlooConfig.cmake
│   inflating: libtorch/share/cmake/Gloo/GlooConfigVersion.cmake
│   inflating: libtorch/share/cmake/Gloo/GlooTargets-release.cmake
│   inflating: libtorch/share/cmake/Gloo/GlooTargets.cmake
│    creating: libtorch/share/cmake/Torch/
│   inflating: libtorch/share/cmake/Torch/TorchConfig.cmake
│   inflating: libtorch/share/cmake/Torch/TorchConfigVersion.cmake
│ -- The C compiler identification is Clang 4.0.1
│ -- The CXX compiler identification is Clang 4.0.1
│ -- Check for working C compiler: /Users/hg344/.julia/conda/3/bin/x86_64-apple-darwin13.4.0-clang
│ -- Check for working C compiler: /Users/hg344/.julia/conda/3/bin/x86_64-apple-darwin13.4.0-clang -- broken
│ CMake Error at /usr/local/Cellar/cmake/3.16.1/share/cmake/Modules/CMakeTestCCompiler.cmake:60 (message):
│   The C compiler
│
│     "/Users/hg344/.julia/conda/3/bin/x86_64-apple-darwin13.4.0-clang"
│
│   is not able to compile a simple test program.
│
│   It fails with the following output:
│
│     Change Dir: /Users/hg344/.julia/packages/Torch/OUETH/csrc/build/CMakeFiles/CMakeTmp
│
│     Run Build Command(s):/usr/bin/make cmTC_67224/fast && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTC_67224.dir/build.make CMakeFiles/cmTC_67224.dir/build
│     Building C object CMakeFiles/cmTC_67224.dir/testCCompiler.c.o
│     /Users/hg344/.julia/conda/3/bin/x86_64-apple-darwin13.4.0-clang   -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk   -o CMakeFiles/cmTC_67224.dir/testCCompiler.c.o   -c /Users/hg344/.julia/packages/Torch/OUETH/csrc/build/CMakeFiles/CMakeTmp/testCCompiler.c
│     Linking C executable cmTC_67224
│     /usr/local/Cellar/cmake/3.16.1/bin/cmake -E cmake_link_script CMakeFiles/cmTC_67224.dir/link.txt --verbose=1
│     /Users/hg344/.julia/conda/3/bin/x86_64-apple-darwin13.4.0-clang   -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names   CMakeFiles/cmTC_67224.dir/testCCompiler.c.o  -o cmTC_67224
│     ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd, file was built for unsupported file format ( 0x2D 0x2D 0x2D 0x20 0x21 0x74 0x61 0x70 0x69 0x2D 0x74 0x62 0x64 0x2D 0x76 0x33 ) which is not the architecture being linked (x86_64): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd
│     ld: dynamic main executables must link with libSystem.dylib for architecture x86_64
│     clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
│     make[1]: *** [cmTC_67224] Error 1
│     make: *** [cmTC_67224/fast] Error 2
│
│
│
│
│
│   CMake will not be able to correctly generate this project.
│ Call Stack (most recent call first):
│   CMakeLists.txt:2 (project)
│
│
│ -- Configuring incomplete, errors occurred!
│ See also "/Users/hg344/.julia/packages/Torch/OUETH/csrc/build/CMakeFiles/CMakeOutput.log".
│ See also "/Users/hg344/.julia/packages/Torch/OUETH/csrc/build/CMakeFiles/CMakeError.log".
│ ERROR: LoadError: failed process: Process(`cmake -DCMAKE_PREFIX_PATH=/Users/hg344/.julia/packages/Torch/OUETH/csrc/libtorch ..`, ProcessExited(1)) [1]
│
│ Stacktrace:
│  [1] pipeline_error at ./process.jl:813 [inlined]
│  [2] #run#536(::Bool, ::typeof(run), ::Cmd) at ./process.jl:728
│  [3] run at ./process.jl:726 [inlined]
│  [4] #5 at /Users/hg344/.julia/packages/Torch/OUETH/deps/build.jl:28 [inlined]
│  [5] cd(::getfield(Main, Symbol("##5#6")), ::String) at ./file.jl:96
│  [6] top-level scope at /Users/hg344/.julia/packages/Torch/OUETH/deps/build.jl:26
│  [7] include at ./boot.jl:328 [inlined]
│  [8] include_relative(::Module, ::String) at ./loading.jl:1094
│  [9] include(::Module, ::String) at ./Base.jl:31
│  [10] include(::String) at ./client.jl:431
│  [11] top-level scope at none:5
│ in expression starting at /Users/hg344/.julia/packages/Torch/OUETH/deps/build.jl:26
│
│ Full log at /Users/hg344/.julia/packages/Torch/OUETH/deps/build.log

I didn't check it thoroughly yet, but could you deactivate your Conda environment and try it again? I saw from the log you are using a compiler in a Conda env, which is Clang-4.0.1, but generally on a macOS nowadays, the compiler is Clang 11.x or even newer.

Indeed, running conda remove clang fixed the issue.

The binary got built successfully, now got this error
julia> using Torch
[ Info: Recompiling stale cache file /Users/hg344/.julia/compiled/v1.2/Torch/Hauli.ji for Torch [3ba4a88b-5b67-4a96-bb04-131d22fbab27]
ERROR: InitError: error compiling __init__: could not load library "libtorch_capi"
dlopen(libtorch_capi.dylib, 1): image not found
Stacktrace:
 [1] _include_from_serialized(::String, ::Array{Any,1}) at ./loading.jl:685
 [2] _require_from_serialized(::String) at ./loading.jl:736
 [3] _require(::Base.PkgId) at ./loading.jl:1023
 [4] require(::Base.PkgId) at ./loading.jl:911
 [5] require(::Module, ::Symbol) at ./loading.jl:906
during initialization of module Torch

This might be fixed now.

Thanks, it's working now!


clightning: 24.05 -> 24.08

Description of changes
This will fix build https://hydra.nixos.org/build/270933657

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ocfox can you please drop the formatting change fro the PR? I don't like it

No problem, I just use nixfmt-rfc-style.

@prusnak nixfmt-rfc-style is widely accepted, and even enforce for new changes https://github.com/NixOS/nixpkgs/pull/326407


Documentation

Added some initial documentation for the modeler.
these updates closely follow the readme for the predictor, as well as the installation docs for the use case. With that in mind, I am happy to give them major revisions / add a lot more. Any suggestions appreciated.

Please can I merge this, to prevent me from deleting it accidentally again?
@elmiko


KOGITO-3589 Extract apps from kogito-runtimes

https://issues.redhat.com/browse/KOGITO-3589
Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Pull Request title is properly formatted: KOGITO-XYZ Subject
[ ] Pull Request title contains the target branch if not targeting master: [0.9.x] KOGITO-XYZ Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains link to any dependent or related Pull Request
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket

nightly and release tested

this will be done once needed


feat: add include field to observe agent config that propagates to OTEL host log receiver

Description
OB-37220 add include field to observe agent config that propagates to OTEL host log receiver
This enables us to use the agent config to list logs files.
Ex:
# agent config
host_monitoring:
  enabled: true
  logs:
    enabled: true
    include: ["/log/test.log"]

# otel config snippet (generated via `observe-agent config`)
receivers:
  filelog/host_monitoring:
    include:
      - /var/log/**/*.log
      - /var/log/syslog
      - /log/test.log

Checklist

[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Open questions:

Should this entirely overwrite the default or extend it?
Windows uses the OTEL receiver windowseventlog instead of filelog, so this concept doesn't translate very well. Right now this agent config field does nothing on windows; is that okay?


LIST -min -max parameters

LIST Command should have -min -max parameters (both facultative)
Min **OR** max.

    /list -min 30
    /list -max 5

Min **AND** max.

    /list -min 25 -max 30
    /list -min 40 -max 50

We should adjust the LIST command handler to accept the ELIST conditions referenced in the Modern spec above, and take them into account while parsing and outputting channels. When we do this, we can add those we implement to the ELIST RPL_ISUPPORT numeric.

@vegax87 I've added support for this in 179d87b84235f7b6aac4043ebdd6ab5be7e2bea9 (latest commit in the devel branch). If you wanna give that a shot, we should be able to close this issue with the next release! Thanks again for yelling for this issue.

You should now be able to do this in v0.8.1. If you can't or have other trouble, please feel free to reopen this or create a new issue. Thanks again for reporting this, it's much appreciated!


Determine if we can use timedatectl show in the timezone resource

It's possible that we can easily parse out the data from timedatectl show on systemd hosts and avoid the need for a fragile regex. We just need to make sure this exists on older systemd hosts like RHEL7/SLES 12/Ubuntu 16.04

Ubuntu 16.04 does not have the show command.


Refactor Logging Quickstart spec and fix by adding order clause to entry fetch

Refactor Logging Quickstart spec and fix by adding order clause to entry fetch

logging.entries filter: was not working without additional order: option

is this intended behavior or a bug?

simplify log name to "quickstart_log_#{Time.now.to_i}"
always try to delete log after spec runs, allowing for NotFound exceptions
refactor entry lookup into a helper method

quickstart passed. sample spec failed.


feat : Adding Dynamic Star Rating System

Kindly updated your forked repo as it has merge conflict and put a pr again