Travis environment variables

my .travis.yml file has a few environment variables defined that are not being recognised by fastlane in this case

hello @rimonhanna can you run your jenkins build with the enviroment variable expressed in the next text.
If you have any failure on your build and want to review the final generated, you should declare the environment variable DEBUG_TRAVIS_YML either on your build node or in jenkins.

this will retain in your workspace the shell script generated from the .travis.yml, with this we can debug a bit more and see if the environment variables are declared correctly.

as it has been 2 month without any more information this issue is going to be close, let me know if you want it to be reopen in the future when more information is available.


feat: Fmt input using prettier

@maximousblk Let me know what you think 😁

@maximousblk Hmm maybe not, it's erroring:

ZenPad is primarily a personal note taking app and does not need a formatter.
Also I'd like to keep it as simple as possible. Syntax highlighting is already something out of this project's scope.


Handle multiple sources in a task

An alternate way to handle multiple sources in one task using gulp-stream-to-promise.

This is not a recommended pattern.


fix(SearchBox): autocomplete was not disabled by default

We were using false instead of "off" in the input of our <SearchBox/>

love it


Include .meta files

VS assumes plain text for .meta files. Just like the conf files, these could benefit from lint and autocomplete.

Addressed in v0.2.8


job #8321 mem design note after redesign

In the pseudocode ModelElementMovedModelDelta comes out of the blue.  Perhaps it’s worth providing a little context in the pseudocode as to what it is?  Does it include everything we’ve done up to this point, including the move of the graphical element?  Or, does the transaction worry only about semantic model elements and leave graphics reconciliation to sort it out if the transaction is aborted?
I’d like to see more explanation of how we determine whether a downgrade is needed.  This is an important, and somewhat tricky, aspect of the operation, and “downgrade” is the result, but it’s not the cause.  The pseudocode never mentions any analysis of visibility, and I think that’s a key point to expose in the pseudocode.
“Downgrade” seems to be a catchall term that really means “disconnect a link between two model elements, and maybe replace it with another link”.  Some additional precision may be warranted here.  I believe that downgrade includes at least four similar but different concepts:
a.	Reverting the type of a model element to the default type because after the move its current type is no longer visible.
b.	Un-assigning a component reference because after the move its assigned component definition is no longer visible.
c.	Un-formalizing a port (interface reference) because after the move its interface definition is no longer visible.
d.	Un-assigning an imported class because after the move its class definition is no longer visible.
e.	Are there others?  Certainly package references must also be considered when that support is integrated.
How far and wide does the parse-all operation extend?  Do we provide any indication to the user that we’re doing it?  I’m concerned that if the parse-all takes a long time, the user may think the tool has hung or the move operation is not working.
It strikes me that our “cut” operation will no longer behave as many people might expect (think Ctrl-x) in that it will not actually cut (remove) the selected elements.  Only when the user selects “paste” do we begin the cut operation.  Functionally, this is not a problem, because the user can employ “delete” to remove selected elements, if that’s what he really wants to do.  But, it seems we should perhaps consider renaming the operation in the UI to make it clear that it’s not really a cut operation in the traditional sense.  Does “move” followed by “paste” make any more sense?  I’m not entirely sure, but I think so.  Of course, having said all this, I’ll note that when an Excel user executes “cut” against a selected set of cells, Excel does not remove the contents of those cells, but instead provides a visual indication that it’s waiting for the paste operation.  Windows File Explorer uses a similar approach, so I guess the Ctrl-x paradigm of most editors is not universally adopted by other interfaces.

6.1.1 Typo:  “…done in a single…”
<IP_ADDRESS> Type:  “…to enable IPRs…”

job #8321 Responses to https://github.com/xtuml/bridgepoint/pull/183#issuecomment-242209586:

I did change this a bit, but please note that the new transaction is explained in detail later in the note and this is simply calling out the spot that something is added to the ongoing transaction. I do not see what more I can do here.
2 & 3. This is coming. Keith will provide more info about the “downgrade” analysis
4. Parse all has been removed after the move.
5. This will be described in the user documentation that is required as noted in this document.
6 * - I fixed these typos.
[8/24/16, 5:44:17 PM] Bob Mulvey: I want to write more about the new cut/paste paradigm (you questions #4)…
[8/24/16, 5:44:46 PM] Bob Mulvey: Your thoughts about this being like a spreadsheet are exactly how I have thought of it.
[8/24/16, 5:47:10 PM] Bob Mulvey: We do not do anything special visually, like a spreadsheet often does, to indicate the cut was done. However, I think about how during copy/paste cells are recalculated and during cut/paste they are not. This is analogous, in my mind to the fact that IDs are recreated during copy/paste and they are not during cut/paste. This is also why a user is allowed to paste multiple times after a copy, but they can only paste a single time from a cut.


License question

Hi,
Thanks a lot for this project, it seems very useful 🙏🏼
I'd like to use this internally in some of our projects and willing to send upstream any improvement we'd make, but the current license of the project is pretty prohibitive and I don't think it could fly by our legal department.
Would you be able to license it to something more permissive, that wouldn't require us to open source all of our source code if we use it?
Thanks a lot,
Adrian

Hi @ellimist,
Thanks for pointing the issue and sorry for the late reply. Truth is, I'm really bad with licenses. Please let me deep into it and come with a better one.

@ellimist I dove into, and definitively AGPLv3 is not what I was looking for when I created this library. Moved to MIT in favor of the community.
I hope this is a good fit for your company.

@manuelmhtr this is amazing, thanks a lot 🙏🏼 I'll try to send back here any changes/improvements we might make on the way.


update Storageblob sample with new package

Purpose
Move over this sample to new Azure SDK:

Move the original file to storage-blobs-python-quickstart-v3 folder
Add folder storage-blobs-python-quickstart-v4 for the sample referenced to the new SDK
Add the readme to introduce the Sample and folders in the root folder

What old sample do

What can be updated to V4:

What can't be updated to Track 2,our solution :
None

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


put pipeline output back

Coverage remained the same at 41.53% when pulling 94d2826caaf4084e6e4acca51097eae95a903edd on put_back_pipeline_output into a0781f8f6472cafb4f256172de483c02a06fabe4 on master.


Temporarily remove 'mola' package (transitional)

This PR removes the entire section for the mola package (and all their released packages), as a transition towards the new organization of packages as discussed in https://github.com/ros/rosdistro/pull/39209
Once this one is merged, I'll open new PRs for the corresponding new packages, now without risk of conflicts of packages with the same name coexisting.

@clalancette  Thanks! The next step after this removal would be https://github.com/ros2-gbp/ros2-gbp-github-org/issues/402 so we can release the new alternatives.


Fix API_VERSION

From @PhilippeR26
I received an interesting question : why ApiVersion and SpecVersion do not have the same type? Why an object on one side and a string on the other side?
https://github.com/starknet-io/types-js/blob/76a31d51b7a6254b28f75cab3ace272dfea72e25/src/wallet-api/components.ts#L22-L26
https://github.com/starknet-io/types-js/blob/76a31d51b7a6254b28f75cab3ace272dfea72e25/src/wallet-api/components.ts#L144-L149
Honestly, the question is legit.
From @tabaktoni

Question ?
_The second question I have here, and I can't remember what it is, is how developers correlate API_VERSION and SPEC_VERSION.

API_VERSION is the version of the API provided by the wallet (internally whatever), and it can be whatever let's say: 33.7.56
SPEC_VERSION is the version of the RPC Specification wallet provided, and It can be only one of the versions of the spec let's say: 0.7.1
Now, how do you correlate these two as there is no specification correlation is I guess wallets provide some table on their documentation saying:
API_VERSION SPEC_VERSION
33.7.56 | 0.7.1
33.7.55 | 0.7.1
33.7.53 | 0.7.1
33.7.32 | 0.7.0_

Fix
But I think I could do:
export type API_VERSION = string;

and
export interface ApiVersionRequest {
  api_version?: API_VERSION;
}

And avoid using ApiVersion NAME in this case i think all should be ok with naming collision

Wallet teams are interested to have rather quickly a new version of this lib, including the string types for both versions responses.


Disable features

Is your feature request related to a problem? Please describe.
I don't like that Socrates panel opens at obsidian start, and I personally don't use it.
Describe the solution you'd like
Add a togleable option to disable any of the plugin "characters" and all their commands/related windows/hotkeys will not appear, that will provide more user customization of what they find or not useful for the plugin, and make slower startup loads even.
Describe alternatives you've considered
Use workspaces plus, but it doesn't work everytime.

found out about #45 reading around, I'll close this and make it as a comment to that issue.


adding sparql check and adding the run to the makefile

For https://github.com/geneontology/go-ontology/issues/17625

Thanks for the update @balhoff


Using git providers hosted without https fails to clone repositories

Describe the bug
When a git provider API is not available through https, Daytona fails to clone the repo because it defaults to https
To Reproduce
Steps to reproduce the behavior:

Add a git provider (e.g. Gitea) hosted only with http
Create a repo from any URL of that git provider
Notice that the repo fails to clone because it defaulted to https

Expected behavior
The repo can be cloned successfully via http
Desktop (please complete the following information):

OS: any
Daytona Version: v0.19.0

Additional context
The issue is directly related to this function https://github.com/daytonaio/daytona/blob/main/pkg/gitprovider/git_provider.go#L131

Hi @Tpuljak
Lemme know if this works! If it is, then I'll raise a PR, so that you could be able to merge it into main.
// checkHTTPSAvailable checks if the given URL is accessible via HTTPS
func checkHTTPSAvailable(source, owner, repo string) bool {
	url := fmt.Sprintf("https://%s/%s/%s.git", source, owner, repo)
	resp, err := http.Head(url)
	if err != nil || resp.StatusCode != http.StatusOK {
		return false
	}
	return true
}

// getCloneUrl constructs the clone URL using the appropriate protocol
func getCloneUrl(source, owner, repo string) string {
	if checkHTTPSAvailable(source, owner, repo) {
		return fmt.Sprintf("https://%s/%s/%s.git", source, owner, repo)
	}
	return fmt.Sprintf("http://%s/%s/%s.git", source, owner, repo)
}

Done!

Hii, when I'm passing the parameters (protocol, source, owner, name) to the getCloneUrl function inside the pkg > gitprovider, the bitbuckettest.go is throwing error.
A/c the error, the expected protocol should be this: Protocol:"https", while the actual protocol is: Protocol:""
PS: Getting no clue

By the way, I fixed my old functions, where that gitlab_test.go file was throwing an error... Unit tests are passed.
Now, I'm waiting for your respond @Tpuljak, then only I'll proceed further🙂

@RS-labhub I don't see a PR I can review.

@RS-labhub I don't see a PR I can review.

Which one PR I raise?? The one with parameters (protocol, source, owner, name) or another one? Or both??

Which one PR I raise?? The one with parameters (protocol, source, owner, name) or another one? Or both??

@RS-labhub as I said. Issue comments are not the place to paste and discuss code. Open a PR that passes all test with your proposed solution and we'll comment there.


Add links to cid-redirect.json file

Purpose of this pull request
This pull request (PR) edits the cid-redirects.json file to fix 404 errors.
Issue number:
GitHub issue #2576
Select the type of change:

[x] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions and updating sections
[ ] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - Updates, maintenance, and new packages for the site, Gatsby, React, etc

@kimsauce, I did my best to catch all the broken links you listed in your Google spreadsheet. Feel free to add any I missed.

You're correct, @kimsauce, that is not a valid link: /docs/cse/automation-service-examples
The funny thing is, it will be a valid link once PR #2311 is published.

Thanks, @kimsauce!


Encapsulate BDB environment inside new CDBEnv class

Minor differences between this and the commits in question (specifically cd9696f) as this doesn't account for the needed changes to compile QT; was unable to locate a patch for this so instead wrote in the required functionality myself (subsequently this may not exactly match bitcoins implementation, I believe they actually did something similar at a later time (based on the commits where BDB was removed from everything but the wallet).
This (among other things) is needed to incorporate salvage functionality for corrupt wallet.dat files.
Works fine in my testing on linux but should definitely have some extended testing in all supported OS.
reference: https://github.com/bitcoin/bitcoin/pull/1293

Added https://github.com/bitcoin/bitcoin/pull/1728 because I see little reason not to.

This is required for mock db capabilities which are needed for unit tests.

Has anyone looked at this yet (@PaycoinMaster, @mitchellcash)?


bitwise.byte.read(17) => Cannot read property 'read' of undefined

I had used to be happy with bitwise but this code doesn't work anymore.
const bitwise = require('bitwise')

let binFlags = bitwise.byte.read(17)

console.log(binFlags)

let binFlags = bitwise.byte.read(17)
                           ^

TypeError: Cannot read property 'read' of undefined

I've used to use readByte from version < 1.0.0 but this function disappeared.

It's an easy fix, you're using the legacy require way of importing packages. Since bitwise uses import now, you'd have to either switch to that, or use the following:
const readByte = require('bitwise/byte/read').default
readByte()

// or

const byte = require('bitwise/byte').default
byte.read()

// or

const bitwise = require('bitwise').default
bitwise.byte.read()

This is not specific to bitwise and can't be avoided, you'll find it in a lot of modern libraries. It's because ES imports support multiple exports, with default being the default export.
I'll add this to the documentation, let me know if this solved the issue for you.

I see, great! Thank you for the explanation and good job with your library!

@alexis57 I updated bitwise and starting with version 1.4.0, you should be able to omit .default. Please open an issue if that doesn't work for you.


FYI: Update recursive-open-struct once it supports ruby 2.3.0

FYI. @abonas we'll need to upgrade our dependency on this gem once it supports 2.3.0:
https://github.com/aetherknight/recursive-open-struct/pull/39
Note, 2.3.0 is due around December 25th.
The kubeclient test suite fails against ruby 2.3.0preview2 with error like:
  2) Error:
TestComponentStatus#test_get_from_json_v3:
NoMethodError: undefined method `name' for #<Hash:0x007fe1fb7cb688>
    /Users/joerafaniello/Code/kubeclient/test/test_component_status.rb:14:in `test_get_from_json_v3'

  3) Error:
TestPersistentVolume#test_get_from_json_v1:
NoMethodError: undefined method `name' for #<Hash:0x007fe1fc682208>
    /Users/joerafaniello/Code/kubeclient/test/test_persistent_volume.rb:14:in `test_get_from_json_v1'

Everything passes if I hack the Gemfile/gemspec and bundle to use the proposed upstream fix
diff --git a/Gemfile b/Gemfile
index 2818a92..24cc79b 100644
--- a/Gemfile
+++ b/Gemfile
@@ -2,3 +2,5 @@ source 'https://rubygems.org'

 # Specify your gem's dependencies in kubeclient.gemspec
 gemspec
+
+gem 'recursive-open-struct', :github => "Kris-LIBIS/recursive-open-struct", :branch => "master"
diff --git a/kubeclient.gemspec b/kubeclient.gemspec
index ed828f8..ba9205d 100644
--- a/kubeclient.gemspec
+++ b/kubeclient.gemspec
@@ -28,5 +28,5 @@ Gem::Specification.new do |spec|
   spec.add_dependency 'rest-client'
   spec.add_dependency 'activesupport'
   spec.add_dependency 'json'
-  spec.add_dependency 'recursive-open-struct', '= 0.6.1'
+  spec.add_dependency 'recursive-open-struct'
 end

@jrafanie - thanks!
I see that this https://github.com/aetherknight/recursive-open-struct/pull/39 was merged, and a new 1.0 ROS gem was released. It seems to me that bumping kubeclient to work with ROS 1.0 even before Ruby 2.3 is released should be sufficient to address this issue. Is that correct?
(of course, later on, 2.3 should be added to travis.yml for testing matrix)
cc @simon3z

Yes @abonas, that would be fine.  The ROS should be completely backward compatible with existing use cases.  I"m going to run the MIQ test suite against kubeclient with the latest ROS to verify it.

@jrafanie @abonas about:
gem 'recursive-open-struct', :github => "Kris-LIBIS/recursive-open-struct", :branch => "master"

is that going to track master? It doesn't seem a good idea to track the unstable branch, isn't there any stable branch to follow instead?

Good question @simon3z.  Yes, that tracks that person's master branch.
That was a local hack to test it.
What I'm suggesting is something like this:
diff --git a/kubeclient.gemspec b/kubeclient.gemspec
index ed828f8..efd580c 100644
--- a/kubeclient.gemspec
+++ b/kubeclient.gemspec
@@ -28,5 +28,5 @@ Gem::Specification.new do |spec|
   spec.add_dependency 'rest-client'
   spec.add_dependency 'activesupport'
   spec.add_dependency 'json'
-  spec.add_dependency 'recursive-open-struct', '= 0.6.1'
+  spec.add_dependency 'recursive-open-struct', '= 1.0.0'
 end

Personally, I'd go with ~> 1.0.0 so it accepts patch level updates to the gem.

Personally, I'd go with ~> 1.0.0 so it accepts patch level updates to the gem.

@jrafanie @abonas either = 1.0.0 or ~> 1.0.0 (in case they're really strict with the stable branch and they don't break often/ever) is fine by me.

@jrafanie @abonas either = 1.0.0 or ~> 1.0.0 (in case they're really strict with the stable branch and they don't break often/ever) is fine by me.

I would go with = and not ~> because they did break couple of times in the past with regressions that created some issues for us.

@abonas @simon3z FYI, if you bump the kubeclient release to 0.10.0, we'll need a openshift_client gem that allows it.  It's currently requiring ~> 0.8.0 so it only picks up 0.8.0, 0.8.1, etc.  Not 0.9.0, 0.10.0.  And we'll need those gem versions updated in the manageiq gemfile.  We have 10 days until 2.3.0 is released so it's not a big rush yet.

would go with = and not ~> because they did break couple of times in the past with regressions that created some issues for us.

That's fine @abonas.  I try to use ~> until a gem behaves badly and then I get really pessimistic and use = too.


More navbar tweaks, closes #178

What changed

Moved app links into dropdown for all apps (other than Beacon)

Screencap

:+1: if @shellicious approves of the additional dropdown.

APPROVED!


gateway: dir-listing links with prefix broken again

e.g. https://ipfs.io/refs/ links to https://ipfs.io/lists

Fixed in e168fd918f3030076a79f55b269a4c5813566957


Add AUR Package Build Exit Code Check

To prevent failed build task continuing, introduce exit code check.
Example:
https://github.com/ChimeraOS/chimeraos/actions/runs/7939157980/job/21682894843
This job failed to package but the whole task still continued.

Nice catch. Thank you!


Added the integrated_content helper to the article text.

@marijnotte 0.6 does not have a travis file, can you merge this PR for me?


SIM800L not working with Hologram Cloud Message (but works with SMS message)

Thank you for this wonderful code you share here.
In my case (I am using a SIM800L (core board) and Arduino Uno) everything works fine but I can not recieve messages from Hologram Cloud Message. I can recieve messages via SMS messages.
On Hologram site it says "The Hologram Dash does not support receiving cloud messages. You must use SMS to send data to the Dash." Is it the same case with SIM800L?

In the Hologram Dashboard, I can send messages via Cloud Data to my Arduino with a SIM800L.
Have you had any success ?


ValueSchedule cannot supports other parameter schedul

I tried to another way, use the lerp node to do a comparison of denoise linear changes, but it seems to have made no difference.


High Availability for Pilot

High-level Epic for adding support for high availability for Pilot (same principles can be applied to other Istio Control plane components).

Add auto-scaling for pilot/mixer
Add liveness and readiness probes
have data-plane continue to function in the absence of or when partitioned from control-plane
handle various points of failures - pilot, mixer, ingress, gateway, pilot-agent process, envoy process, istio-proxy container, zone , datacenter.

subscribe

Can you please specify the availability target and whether human errors are
included?
I have done similar work before. The solution heavily depends on the goal.

The goal is to improve it in general by addressing the items in the description (auto-scaling etc..), without a specified SLO. Any advice will be appreciated.


cluster: use atoi instead.

Signed-off-by: johncming<EMAIL_ADDRESS>

we're specifically parsing using a uint for a reason, since we don't want to accidentally allow a negative port value