An idea for primitive arguments support

I want to describe a pretty damn crazy idea which may bring support for primitive arguments. As far as I can see right now, this is the only way to properly support #467, so it is kind of important :)
A quick reminder: the main problem comes on the definition building stage. With the current setup, we invoke a definition method with TyphoonInjectionByRuntimeArgument instances as faux arguments, but this isn't possible for non-object arguments. If we try to pass objects in place of primitive arguments, we run into all sorts of trouble. So, we need a different approach to denote our runtime arguments.

Here is how it can be done. No matter what primitive type is, we have at least one byte of data at our disposal. The main idea is to use this byte to store our runtime argument index: 0x01 for the first runtime argument, 0x02 for the second, and so on. For object arguments, we would pass NSNumbers containing a value constructed in the same fashion. These values get passed to definition method & property descriptors, where we can convert them back to runtime injections.
However, there is a second trick to this. You might have guessed the problem already: how do we differentiate between disguised runtime injections and actual integers / chars / NSNumbers / NSValues / etc.? Here's how. As we face a possible ambiguity, we should reinvoke the same definition method again, this time encoding runtime arguments with different values (say, shifted by 0x80). We will be able to see what changed and what did not, and therefore figure out the places where we came across genuine values.
I can't see any particular problems with this, but my knowledge of code is still limited, do you?
There is also a way to support TyphoonConfig() in a similar fashion. TyphoonConfig() should basically return NSValue (either directly or, better, masked behind a protocol) and maintain a private global table of mapping "integer values -> config keys". We have 128 spare values, let's say we spend 20 of them to encode runtime arguments, then the rest can go to support config keys and potential other needs - it's a plenty of space.
Sorry if all this is chaotic, I'm pretty excited about this solution and would really love to bring it to life :) Need a word from you guys first though.

Hm, that sounds interesting.
some points from me:

We should do this algorithm only with primitive runtime arguments. In other cases let's use old approach with TyphoonInjectionByRuntimeArgument objects
Sending argument index as runtime argument value - yes, I though about that too.. but I found that inconvenient in past.. Your suggestion with two calls sounds interesting. I'll think what else we can do here to avoid double Definition creation.

@alexgarbarev

We should do this algorithm only with primitive runtime arguments. In other cases let's use old approach with TyphoonInjectionByRuntimeArgument objects

The NSNumber instead of TyphoonInjectionByRuntimeArgument approach works well because basically it allows for an easier, unified logic. With primitive arguments, we'll retrieve them as boxed NSValues, so we can use the same injection transformation code for both objects and primitives.
It also gives us a direct support for the new API from #467, e.g.:
- (id)knightWithDamselsRescued:(NSNumber *)damselsRescued
{
	return [[Knight typhoonDefinition] initWithDamselsRescued:damselsRescued.unsignedIntegerValue];
}

Note damselsRescued.unsignedIntegerValue here, it won't work with TyphoonInjectionByRuntimeArgument.

I've finally got a working implementation of this :) Wanna clean up a bit before opening a PR, but it works and passes all the tests. The only thing it lacks at the moment is support for BOOLs (@(boolRuntimeArgument) in particular), but I have a plan for that too.
Also, I've done some profiling of our project which uses the old version of Typhoon. Apparently, the definition building part doesn't take a big percentage of Typhoon startup - e.g., it takes less than assembly selector swizzling or actual singleton instantiation. So, having to call each definition method twice might not be such a big of deal. Gonna do some profiling with the new version soon.

Wow congrats, looking forward to that!

After some further consideration, I guess I came to a conclusion that this is probably not a good idea after all. While it's possible to work around sharp corners of BOOLs, the whole process of encoding/decoding turned out to be an unnecessarily complex routine. In fact, it introduces not-so-obvious problems on the user level as well. Let's say we have this:
- (LittleEngine *)littleEngineThatCould:(BOOL)could {
    return [TyphoonDefinition withClass:[LittleEngine class] configuration:^(TyphoonDefinition *definition) {
        [definition injectProperty:@selector(failed) with:@(!could)];
    }];
}

There's nothing wrong with that, but it won't work, and it's very confusing why it wouldn't. As a user, I'd have to keep in mind that I have to use my primitive arguments as is, and if I forget about that, there's no way to give an early warning. This is too bad.
However, all this actually brings us to a new approach I would like to discuss in #467 (as a more on-topic issue).

The discussion was moved to PR #467.


research TLS usage

In order to gauge the impact of disabling TLS1.0 and TLS1.1 on our ALBs, we should get numbers on TLS usage on our ALBs.
It would be good to know:

TLS usage by version across the platform
top users of TLS < 1.2

We should be able to get this from ALB logs, which are in an S3 bucket. This gist may be helpful: https://gist.github.com/bengerman13/4b31709aa1915da73900fd9bcfeaae92
We should limit this to ~2 hours

I'm going to close this issue as there's no valid indication we're running TLS 1.1


⚠ Bofrost.at has degraded performance

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

HTTP code: 200
Response time: 1294 ms

Resolved: Bofrost.at performance has improved in e98dae3 after 6 minutes.


Various tweaks and fixes

test this please

test this please

test this please

test this please

build this please

test this please

test this please

test this please

test this please

test this please

test this please

test this please

test this please


Dark mode: Theme switcher control

Description
Introduce a new CSS var inside .dropdown.
Introduce new rule for svgs inside dropdowns. ⚠ Might be breaking.
Introduce 2 new Sass var.
Updated toggle switcher in our examples and navbar accordingly.
Reorganize docs navbar to have something more branded navbar (more spacing).
Remove hacky CSS from #2237.
Related issues
Fixes #2242
Closes a thing inside #2223: Switching from light to dark mode
Live previews

https://deploy-preview-2425--boosted.netlify.app/
https://deploy-preview-2425--boosted.netlify.app/docs/examples/form

There was a sub-task regarding the theme selector. We could evaluate it while developing this PR:

Check the HTML structure of the dropdowns in our doc header. We probably should use <button>s (like in Bootstrap) rather than <a>s


Using RFC2136 dns challenge does not allow to create multi domain certs.

Since the rfc2136 provider requires me to set the zone upfront, i cannot create a cert covering more than one zone. e.g. RFC2136_ZONE=a.nl, ./lego --dns=rfc2136 -d www.a.nl -d www.b.nl run
Since I realize this is rather dns-setup specific, could we perhaps create a zone with a special meaning? like "auto", which will derive the zone from the last 2 parts of the fqdn? aka www.a.nl > a.nl ?  Perhaps even parametrize it? auto:3 for say a.co.uk zones.

I guess we could lookup the zone names for the domains like the other DNS providers do and get rid of the RFC2136_ZONE parameter all together.

That is ... awkward. I guess one could query for the SOA on each level till one finds a SOA.
bigbox.ch.polyware.nl > nothing
ch.polyware.nl > nothing
polyware.nl > SOA > gotcha
But yeah, for lack of a better way, that might be the best we can do.

No need to traverse - the authority section contains the SOA of the zone:

dig SOA bigbox.ch.polyware.nl @<IP_ADDRESS>

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60090
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;bigbox.ch.polyware.nl.		IN	SOA

;; AUTHORITY SECTION:
polyware.nl.		1169	IN	SOA	ns1.iaf.nl. netwerk.iaf.nl.<PHONE_NUMBER> 28800 7200 2419200 1200

Are you sure all nameservers will report the authority section? Looking at various internet posting on the topic made me doubt that assumption. (Although I agree that if you are incapable of setting RC2136_NAMESERVER to your own authoritative nameserver, you probably should not be doing this at all.)

Name servers authoritative for a zone MUST include the SOA record of
the zone in the authority section of the response when reporting an
NXDOMAIN or indicating that no data of the requested type exists

Yeah, that part was clear. Just that not any nameserver would do, so the query needs to be done against RFC2136_NAMESERVER.
I'll try to whip up a patch

so the query needs to be done against RFC2136_NAMESERVER

That's what i thought too. We can't expect a recursive nameserver to include the SOA in it's answer.

https://github.com/xenolf/lego/pull/143

Closed per #143


How to write rules?

Your tool seems to be the thing I need. Unfortunately it ignores all the bounces I need it to parse. How can I write new rules if it just won't let me inspect what it sees?
I thought this is a no-brainer for the tool:
Message from yahoo.de.
Unable to deliver message to the following address(es).

<EMAIL_ADDRESS>This user doesn't have a yahoo.de account<EMAIL_ADDRESS>[0]

--- Original message follows.

The original message is over 5K. Message truncated.

But this just gets ignored. I tried other mails but they also get ignored. I really want to write a rule for this. For debugging reasons it would be nice to disable all ignore rules and inspect every mail to adjust rules.
$ ./bouncefetch -d
[00:00:00.000 INFO]     Loading config and rules... DONE
[00:00:00.002 INFO]     Connecting to IMAP server... DONE
[00:00:00.452 INFO]     Selecting 1/1 INBOX... OK
.%X%X%X%
[00:00:02.274 INFO]     All finished!
[00:00:02.274 INFO]
[00:00:02.274 INFO]     4 mails checked
[00:00:02.275 INFO]     4 deleted mails
[00:00:02.275 INFO]     0 handled soft bounces
[00:00:02.275 INFO]     0 handled hard bounces
[00:00:02.275 INFO]     4 ignored mails
[00:00:02.275 INFO]     0 unidentifyable bounces
[00:00:02.275 INFO]     0 no crosscheck matched
[00:00:02.275 INFO]     0 unhandled mails

This tool in general looks very promising for what I need.

I guess the problem here is that the bounces are getting identified but no reference to the client could be found. At the moment we only rely on either the custom header or the X-Failed-Recipients header which unfortunately is nowhere near to be considered "the standard" (as bounces in general).
Although it is pretty straight forward to parse out the email address in this example it isn't in most of the cases. Do you have ideas on how to handle that better? I thought about adding the possibility to allow rules to parse out the recipient address but it would make it a lot more cumbersome to define those.
Since we use the custom header approach (and we found that this works very well, almost all bounces can be identified this way) we didn't spend that much energy in trying to somehow parse the addresses out of the mail body. We might have but you almost always need per-rule specific regex since the bounces are so different.
When I created this tool I had little amount of samples (hence the small ruleset) but I now have yet to grasp over 70k bounces from our system alone. I also have a big list of new rules I have yet to sort out since some are very specific to us. Maybe I get some good ideas while doing that :)
Cheers
PS: If you want I can add an option to also inspect matched bounces with no candidate (client reference) found.

The problem is that I have a lot of bounces already received that I want to sort. They all don't have a custom header and I would think that a minority has the X-Failed-Recipients header. So I'm looking for a tool that can parse the message body. My first try with a perl module looked promising but it fails to extract emails from bounces with multiple emails in the body.
From what I can tell of the small sample I used for testing is that they all seem to use a familiar style. The majority of those is generated by my own mailserver.
The structure seems to be:
<EMAIL_ADDRESS>reasontext

<EMAIL_ADDRESS>reasontext

Where reasontext would be the thing to parse (if such a structure is detected) to get the reason. The reasontext can start with or contain newlines and there is at least one mailserver who ommits the <>: characters around the email.
Can you add body-parsing support so that bouncefetch can detect such blocks? I would then use my mails to incrementally create rules for the reasontext part.

Are you thinking about separate rules for the body-parsing or using existing ones and give them the ability to provide an email address?
Since most rules are currently just sub-string testing I have no idea what the best way to define them would be. I guess in most cases the reason text is somewhat combined with the email address?
I saw bounces how you described them but I also saw things like rule(/user <(.+)> unknown/i) where the reason and target email is the same sentence. Either I have redundancy in the rules or the definition becomes more cumbersome (e.g. block syntax with detect and extract directives or something like that)

I thought of separate rules for body parsing that is triggered by the subject line. It is really frustrating. All the tools I find are either very old and/or they don't recognize multiple email addresses per bounce message.
The reasontext may contain the email address (but it usually is already in the line directly above), but I also get the output form the remote MTA like that:
<EMAIL_ADDRESS>host mx.junkemailfilter.com[<IP_ADDRESS>] said:
    550-REJECTED - spamtext [S=9 - BadHeloNS Slow FNONS BadFromNS DOB-FROM] -
    550-X=pascal H=my.mailserver.com [<IP_ADDRESS>]
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>S=[Subjectline
    still Subjectline] (in reply to end of DATA command)

This is usul yahoo reply (this is in one bounce mail):
Message from yahoo.com.
Unable to deliver message to the following address(es).

<EMAIL_ADDRESS>Sorry your message to<EMAIL_ADDRESS>cannot be delivered. This account has been disabled or discontinued [#102].

<EMAIL_ADDRESS>This user doesn't have a yahoo.com account<EMAIL_ADDRESS>[0]

--- Original message follows.

First of all: Yeah it's frustrating :) Bounces are not my favorite thing to handle due to their vast variety.
Is there anything special about how you send the mails? Because it seems strange to me to get "combined" bounces and I have never seen them so far. But we also don't use CC/BCC so maybe that's why?
When you say "triggered by the subject line" you literally mean the mail subject? I haven't looked for subject/reason format correlations but I haven't seen that much variation in subjects anyway. Most commonly it's one of those:

delivery status notification (failed)
mail delivery failed: returning message to sender
Auto-reply: … ooo mails, etc.

I also have to cope with the fact that bouncefetch wasn't designed for "combined bounces" aka. multiple addresses in one bounce. Now I actually understand what you mean with tools not being able to handle multiple addresses (my experience was that tools just regex'd any mail adress and normally end up with multiple junk ones). With this problem the custom header wouldn't work anyway, at least at the moment when bouncefetch only expects one case per bounce.
I'll fiddle a bit and see what I can come up with :) I'll keep you updated. And if you have any more ideas: please let me know ;)

I have to use cases. The first is using BCC with batches of 20 to send out mail (phpBB). The other is sending out single mails using TO. I didn't yet look at the bounces from the second case which now seem to be easier to manage since they should have only one email per bounce.
My idea was to check for the special header and if that is not there check the subject if it is a known delivery status and then look for the blocks of email + reasontext in the body.
I found another tool that does scan the body of the bounce (PHPMailer-BMH). There are quite a lot forks on github but it seems to do the job at least for the single bounces. The most "combined bounces" I get from my own mailserver where it can't find a mailserver to send to. These are also multiple mails and reasons per one bounce.


How to save to file the result of dependency-tree

I have several hundreds dependencies, and I prefer to save it to a file, so that I can place bookmarks, search and so on.
I've tried ivyReport but provides an unreadable report.
Any suggestion?

Sorry for never answering your question, @DavidPerezIngeniero. Do you still need help with this?

It is not urgent, but I would be interested in any hint you can provide.

Next version will get support through the solution in #165.

Thanks!


Sci/benchmark iluvatar

支持天数llama13b Pretrain。

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 4 committers have signed the CLA.:white_check_mark: DesmonDay:white_check_mark: DrownFish19:x: ZHUI:x: tianyu.zhoutianyu.zhou seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


TTTAttributedLabel + GestureRecognizer

If TTTAttributedLabel inside UIView that has tap gesture recognizer, links inside label can not be handled due to touchesCancelled.
To handle this case I need something like this:
func gestureRecognizer(gestureRecognizer: UIGestureRecognizer, shouldReceiveTouch touch: UITouch) -> Bool {
return self.textLabel.linkAtPoint(touch.locationInView(textLabel)) == nil
}
But linkAtPoint is not public method, is there any reason why it can't be public? Or can you suggest another workaround please
Thanks!

My version was too old, found in recent version containslinkAtPoint
Thanks!


HTTPS on Map Stack

Map Stack URLs are http, not https. But more and more websites are requiring https.
In particular lots of people are using Map Stack URLs in ArcGIS Online. Some examples:

http://www.arcgis.com/apps/MapSeries/index.html?appid=033d0896fb06446d8151c4b469fd4b33
http://www.arcgis.com/apps/MapTour/index.html?appid=c3ecc1ceb7a5429ab2acb629fec674cc

However, soon ESRI is going to eliminate all instances of http URLs on ArcGIS Online: https://blogs.esri.com/esri/arcgis/2017/06/06/web-security-and-story-maps/
Even though the direct use of Map Stack tile URLs is an unsupported feature, we should investigate the feasibility of adding https to Map Stack.

Any news on this? I was hoping to start creating some for my ArcGIS Online story maps.


Multicluster Integration test

add integration initial scripts
integration codes for resource controllers
add integration test in docker and howto doc

Signed-off-by: Lan Luo<EMAIL_ADDRESS>Co-authored-by: Lan Luo<EMAIL_ADDRESS>Co-authored-by: zbangqi<EMAIL_ADDRESS>Co-authored-by: Aravinda Kidambi<EMAIL_ADDRESS>

/test-multicluster-e2e

Codecov Report

Merging #3031 (859ff9d) into feature/multi-cluster (9b32acf) will increase coverage by 0.39%.
The diff coverage is 49.90%.

@@                    Coverage Diff                    @@
##           feature/multi-cluster    #3031      +/-   ##
=========================================================
+ Coverage                  40.17%   40.57%   +0.39%
=========================================================
  Files                        166      181      +15
  Lines                      20750    21857    +1107
=========================================================
+ Hits                        8337     8869     +532
- Misses                     11598    12104     +506
- Partials                     815      884      +69

Flag
Coverage Δ

unit-tests
40.57% <49.90%> (+0.39%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...lers/multicluster/clustermanager/remote_cluster.go
0.00% <0.00%> (ø)

.../controllers/multicluster/clusterset_controller.go
0.00% <0.00%> (ø)

...lers/multicluster/clustermanager/leader_elector.go
24.24% <24.24%> (ø)

...lticluster/clustermanager/local_cluster_manager.go
29.41% <29.41%> (ø)

...ticluster/clustermanager/remote_cluster_manager.go
43.13% <43.13%> (ø)

...ter/controllers/multicluster/service_controller.go
57.77% <57.77%> (ø)

...multicluster/clustermanager/fake_remote_cluster.go
66.66% <66.66%> (ø)

...clustermanager/remote_resourceimport_controller.go
69.42% <69.42%> (ø)

...ntrollers/multicluster/serviceexport_controller.go
70.41% <70.41%> (ø)

...trollers/multicluster/resourceexport_controller.go
71.06% <71.64%> (ø)

... and 10 more

/test-multicluster-e2e

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

/test-mc-integration

@aravindakidambi sure, It's only for single cluster, I will add a doc about integration test and guide how developer can add integration test.

/test-mc-integration

/test-mc-integration

hi @jianjuns @tnqn @aravindakidambi  I am still working on this PR, but Could you take a look at top 2 commits which includes multicluster integration test to see if the overall structure and framework is OK? thanks.

/test-mc-integration

@antoninbas : would you check if we are able to share e2e test code with Antrea?

e2e tests are in a separate PR it seems, I left a comment there
For this PR, unfortunately I don't understand why we need to create a Kind cluster to run the "integration" tests. The document (multicluster/test/integration/README.md) mentions that the integration tests use envtest, but also mentions that we need a real (Kind) cluster. It doesn't explain why, but it seems to me that having to spin up a Kind cluster mostly defeats the purpose of using envtest in the first place.

@antoninbas , envtest framework also supports using existing cluster. I didn't make it clear in the doc. those binaries provided by envtest are actually trying to simulate a K8s API, but it has no other controllers running like Service/Endpoint controllers, we need these controllers to assign Service IP etc so our test codes can check MC Service related logic.

@luolanzone I realized that envtest could support real clusters when I looked at the code. Could you update your document to include the information from your above comment and explain the reason for spinning up a real Kind cluster for integration tests?

@jianjuns @aravindakidambi  @antoninbas do you have any new comments for this PR? thanks.

/test-mc-integration


[KYUUBI #2270] Implement tag based SessionConfAdvisor

Why are the changes needed?

close #2270
How was this patch tested?

[X] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #2271 (5d1cc58) into master (0ee5371) will decrease coverage by 0.23%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master    #2271      +/-   ##
============================================
- Coverage     62.26%   62.03%   -0.24%
  Complexity       69       69
============================================
  Files           349      354       +5
  Lines         16723    16785      +62
  Branches       2261     2266       +5
============================================
- Hits          10413    10412       -1
- Misses         5354     5416      +62
- Partials        956      957       +1

Impacted Files
Coverage Δ

.../org/apache/kyuubi/plugin/tag/TagConfAdvisor.scala
0.00% <0.00%> (ø)

...org/apache/kyuubi/plugin/tag/TagConfProvider.scala
0.00% <0.00%> (ø)

...main/scala/org/apache/kyuubi/plugin/tag/Tags.scala
0.00% <0.00%> (ø)

...he/kyuubi/plugin/tag/file/FileTagConfAdvisor.scala
0.00% <0.00%> (ø)

...e/kyuubi/plugin/tag/file/FileTagConfProvider.scala
0.00% <0.00%> (ø)

...ache/kyuubi/operation/KyuubiOperationManager.scala
94.11% <0.00%> (-1.97%)
:arrow_down:

Continue to review full report at Codecov.

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

@yaooqinn @ulysses-you Could you please help me review it and give some suggestions?

kyuubi-server-plugin is trying to make itself dependency free, especially scala and kyuubi-common.
I don't quite understand the meaning of tag-level?

can you provide some some details about your idea ? and it would be good to give some use case.

kyuubi-server-plugin is trying to make itself dependency free, especially scala and kyuubi-common.

I will change to java implementation and remove scala and kyuubi-common dependencies

why do we need a new config file called kyuubi-tags.conf? it seems that kyuubi-defaults.conf can do the same thing

Because I want to read it periodically, so that we don't have to restart the service after modifying it.

I don't quite understand the meaning of tag-level?

The tag-level is used to distinguish tags of different types.

SYSTEM:
The SYSTEM-level tag is used for global configuration. (This is the same as kyuubi-conf, I can remove it.)

SERVER:
The SERVER-level tag, which uses the server name as a tag, is used for different server configurations.
We can define different server names for different clusters, so we can use the server tag to get the configuration of different clusters.

USER:
The USER-level tag, which uses the user name as a tag, is used for different user configurations.
We can use user tag to get user-specific configuration.

TAG:
The TAG-level tag, used for custom tag types. We can customize some tags and give default configuration.
For example, we can set the user engine-share-level for adhoc tag and the connection engine-share-level for batch tag.

can you provide some some details about your idea ? and it would be good to give some use case.

There are some use cases in https://github.com/apache/incubator-kyuubi/pull/2271#issuecomment-1094484686, are these reasonable?

@wForget  I have a question, can this pr be able to submit ad-hoc and batch tasks at the same time? Whether to start 2 kyuubi server processes or 1 process

@wForget  I have a question, can this pr be able to submit ad-hoc and batch tasks at the same time? Whether to start 2 kyuubi server processes or 1 process

@wForget I have a question, can this pr be able to submit ad-hoc and batch tasks at the same time? Whether to start 2 kyuubi server processes or 1 process

@Narcasserun  This feature is only for injecting some configuration into the session through the configured tags, and does not implement the function of request routing, we can also consider it in the future.

The current implementation is outdated, I will reimplement it, closing it first.


[mesheryctl] system status errors when platform is unavailable

See mesheryctl Command Tracker for current status of commands.
Current Behavior
mesheryctl presents an error when executing system status when the system is missing prerequisite dependencies. The system being used in this scenario does not have Docker installed (does not have docker available.
Desired Behavior
mesheryctl should detect whether or not prerequisites of the platform are availablle (docker cli in this case) and capture this error gracefully, informing the user of the failed preflight check (of the specific missing dependency).
Preflight health check should identify the missing dependency.
Screenshots/Logs
➜  mesheryctl git:(master) ./mesheryctl system status
Missing Meshery config file.
Create default config now [y/n]? y
Default config file created at /Users/willcalcote/.meshery/config.yaml
Error: exec: "docker-compose": executable file not found in $PATH
Usage:
  mesheryctl system status [flags]

Flags:
  -h, --help   help for status

Global Flags:
      --config string    config file (default location is: /Users/willcalcote/.meshery/config.yaml) (default "/Users/willcalcote/.meshery/config.yaml")
  -c, --context string   (optional) temporarily change the current context.
  -v, --verbose          verbose output
  -y, --yes              (optional) assume yes for user interactive prompts.

Environment

Host OS: Mac M1
Meshery Client Version: stable-v0.5.37
Platform: neither

Contributor Resources

mesheryctl Contributing Guide
Beginner's guide to contributing to Meshery and mesheryctl
mesheryctl Command Tracker
Meshery CLI Commands and Documentation
Layer5 Community Slack

I'd like to look on this... May I know what it needs to be done to fix that bug?

@leecalcote Can we(@alphaX86 and me) combinely work on this issue ?

I'd like to look on this... May I know what it needs to be done to fix that bug?

That's where you come into the game. :wink:

Oooh 😂 OK! We'll try to figure out then


Add: GRTS TV

Channel Name
GRTS TV
Alternative Names (optional)
No response
Network (optional)
No response
Owners (optional)
No response
Country
GM
Subdivision (optional)
No response
City (optional)
Serekunda
Broadcast Area
c/GM
Languages
eng
Categories (optional)
general
NSFW
FALSE
Launched (optional)
1967-01-01
Closed (optional)
No response
Replaced By (optional)
No response
Website (optional)
https://www.youtube.com/@GRTSTV
Logo
https://yt3.googleusercontent.com/ytc/AGIKgqOvqFhIkjJOlczBFpNcZlcQXg8fZ5f9KIb1n-ww=s176-c-k-c0x00ffffff-no-rj
Notes
No response

Please update your request:

link to the official website is incorrect

https://github.com/iptv-org/database/blob/master/CONTRIBUTING.md#channels

Corrected


Make the model used by both cobrapy and cobra toolbox?

It is know some GEMs can only run on the cobra toolbox based on MATLAB, but it can't be read and used by another popular toolbox-cobrapy. Thus, it should make sure that the GEMs can be used by both MATLAB or cobrapy. Otherwise the test result should be given which toolbox can read and run the GEMs.

As long as the model is valid SBML, should it then not work in both COBRA and cobrapy? What would be an example of when this fails?

I remember there is  a GEM, which can be read by COBRA toolbox, but can't be read by cobrapy. I need firstly read it using COBRA and export a new xml file. The new xml file then can be read by cobrapy. I will further test some examples and give you feedback later.

The advantage of using SBML as a standard file format for encoding GEMs is those valid models are agnostic of any particular software solution. We should better encourage modelers to ensure the validity of their SBML file to benefit from the ability to conduct a large variety of different analyses with the same model in several modeling tools, not limited to any particular software.
Tightly coupling a model to a specific software tool can face two severe problems:

Even very popular software has faced a situation where its development slows down or could not be maintained for some time. This process could lead to a situation where the software becomes outdated and the model possibly with it.
The software could also quickly evolve, and an older version that was able to run the model could become replaced by a newer version. If a model requires a particular version of a software tool, it might become difficult with time to run it on newer hardware or later operating systems.

For these reasons, storing a model in a valid SBML file is preferable. There are tools to check the validity of a model, such as the SBML validator or MEMOTE. Those can be even used as part of a continuous integration setup of model development and testing.
Please note that the SBML Test Suite now includes constraint-based models, allowing software developers to assess if their software is compliant. Consequently, valid SBML models should run in any standard-compliant software.

There is an automated-validation branch that relies on GH Actions to run different tests on latest releases of models that follow standard-GEM. I've just made a note there about SBML testing. Basic YAML testing is in place, but it will take a while until the validation setup is nice and thorough. We should continue to add ideas for validations there.

I am not sure how closely this relates to the issue, or even if it is still an issue with the latest versions of cobrapy and cobratoolbox, but I often encounter models with metabolite names that are read differently by these two softwares, usually the appended '_c' or [c] that denotes the compartment. Is there a best practice that is bulletproof for both softwares?

@sulheim both programs still convert identifiers upon reading models which is not ideal but also somewhat necessary because folks have taken to using identifiers that are not SBML compliant. In cobrapy, we have been discussing not changing the identifiers read from SBML at all but additionally providing a 'nice' identifier that users can work with most of the time. However, this is a long way down the development roadmap.

@sulheim thanks for bringing up this issue regarding compartment abbreviations in metabolite names. Do you think there is a test case that can be added to the automatic validation that is part of standard-GEM?

If there is no issue with identifier overloading with semantic information yet, please let us create one and continue discussing compartment abbreviations as metabolite identifier suffixes in this different thread.

Good idea @draeger . There is now a note in #9 about the metabolite identifier suffixes. I am now closing this issue, please reopen if needed.


Added poker classification & color segmentation

amlaanb

amlaanb

this repo isn't for people to add undocumented side projects or classwork


Update to manifest version 3

Update manifest.json file (browser_action is renamed to action, update web_accessible_resources)
Update to use the Chrome Scripting API

See Migrating to Manifest V3

Thank you so much for the quick and good work!
It works like a charm and this is really something I had not time to investigate. You will be remembered forever!


Demo version vs latest stable version

Hi i just tested demo version and its fantastic.
But when i used docker image with version  1.0.6 i see that template options is missing.
How can i use the same version that on the demo on the stie ?

Hello!
Thank you for your feedback. We're glad you like Kansha.
The demo version is a development snapshot. Even more work has been
done since then and we are currently preparing a new stable release.
If you are impatient, you can start off the master branch by following
the instructions here:
http://kansha.readthedocs.io/en/latest/quickstart.html#python-package
Tell us if you have any difficulty.
Romuald Texier-Marcadé
02 23 21 21 50
Ingénieur de développement
Net-ng
6, rue de Jouanet
35700 RENNES
http://www.net-ng.com/
On Mon, Feb 6, 2017 at 1:53 PM, Gman1988<EMAIL_ADDRESS>wrote:

Hi i just tested demo version and its fantastic.
But when i used docker image with version 1.0.6 i see that template
options is missing.
How can i use the same version that on the demo on the stie ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Thanks for answear i have two more questions:

when you plan to release next stable version ?
how to start off the master branch version ? i used those instructions but instruction
easy_install --find-links=http://www.nagare.org/snapshots/  kansha==1.1.0

dont work ;/

Sorry, my bad! The actual instructions you need to start off the master branch are there: http://kansha.readthedocs.io/en/latest/devsetup.html
The master branch needs to undergo extensive testing before we make an official stable release. There is no due date yet.
Stay tunned and update your local copy of the master branch to get the latest fixes.

Ok i tried to manage this and its working, but i want to make this easy and fast to deploy and this is not the best solution.
When you release the newest version with docker ?

Stable releases are automatically pushed to pypi and docker hub. The (much awaited) next stable release in near, but I can't give any schedule yet.

Hello!
Kansha v2.0.0 has just been released! Follow the instruction on the README to try it in docker.


sys.stdout.reconfigure(line_buffering=True) AttributeError: '_io.TextIOWrapper' object has no attribute 'reconfigure'

sys.stdout.reconfigure(line_buffering=True)
AttributeError: '_io.TextIOWrapper' object has no attribute 'reconfigure'

This should work once you update your python version to >=3.7.

This should work once you update your python version to >=3.7. Feel free to follow up if not.

Is there any solution for the lower version?

Modifying the code to work around the offending line is an option, but python 3.6 is relatively old and won't receive security patches beyond the end of the year.

Modifying the code to work around the offending line is an option, but python 3.6 is relatively old and won't receive security patches beyond the end of the year. PRs welcome though.

Thank you very much, 3.7 is running normally😁


.Capabilities.HelmVersion.Version does not include the patch version

Let's suppose I'm using Helm version 3.16.1. When I execute the following:
{{- $version := semver .Capabilities.HelmVersion.Version -}}
I get 3.16.0.
Why does .Capabilities.HelmVersion not include the patch version? Is there any specific reason or advantage to omitting that information?

How was the Helm binary built? I'm not able to replicate your issue. I see the patch version accurately.

To be honest, I'm not able to reproduce it. Probably I was doing something wrong. Sorry.


Fixed formatting in lambda1.cs

Fixed the code formatting inside the main methode in lambda1.cs

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

Thank you once again @ckoenig95. You fix will be pushed to production on our next content update and should probably be live either today or tomorrow.


How to create tls config with default public root certificate.

How to create a client same as below nodejs code
const client = new hello_proto.Greeter(
  "myhost:443",
  grpc.credentials.createSsl()
);

I don't know how the nodejs client works but you can take a look at the transport docs. There are also a couple of tls examples available.

Also, there is a tls-roots feature flag that will enable rustls-native-certs, maybe that's what you are after?

Thank you for your advice.
I just tried
    let tls = ClientTlsConfig::new();
    // create channel connect to server
    let channel = tonic::transport::Channel::from_static(
        "https://myhost",
    )
    .tls_config(tls)
    .expect("Couldn't create TLS configuration")
    .connect()
    .await?;

but got
Error: tonic::transport::Error(Transport, hyper::Error(Connect, Custom { kind: InvalidData, error: WebPKIError(UnknownIssuer) }))

I'll try tls-roots feature.


Release 70.0.0

See changelogs.

@jpuri I'm having difficulties finding a PR related to the release you were preparing for @metamask/signature-controller. Should this be actually released, or should be excluded?

Looking at this discussion: https://github.com/MetaMask/core/pull/1568
Looks like we can remove @metamask/signature-controller for now.

@mikesposito could we pull this commit that was just merged into the release: https://github.com/MetaMask/core/commit/f89db77fb7afd4be913c7d026d64dc86f0a42eac ?

I've added a new changelog entry for the change that was just merged and will approve this PR so we can get it merged tomorrow.

Merging this to unblock the DevX team.

@metamaskbot publish-preview


Limit number of participants

Make it so that only a limited number of people can sign up to an event.
Admins/Prefects should be able to bypass this.
This should be nullable and default to null - the expected behaviour here is that any number of people can sign up.

lol this got some progress with events locking. happy to close this for now


just updates mocha

Just updates mocha. Tests still seem to run fine. Since it's a minor version change, it shouldn't break anything (praying to the gods of semver).
closes #180

Not even minor, patch! 😬


added spotify clone

Description
This is a Spotify Clone, having a similar interface as of the app and plays music.
Fixes #277
This is issue no #277
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Explain the Testing instructions
Test Configuration:

Operating system:
Version:
Text-editors used:

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

maam i have increased the spacing of play button. For the responsive one,I will try it

@ManaliPawar its not responsive yet try to make it responsive take ur time
if its not responsive - > level2
if its responsive - > level3

@ManaliPawar

I have increased the spacing but not able to make it responsive ma'am

BTW you have'nt pushed the changes, spacing is still the same.

Ok ma'am

Will do it today itself.


cephfs csi driver can run as nonroot use and Provide services？

Describe the feature you'd like to have
now the cephfs csi driver run as root user,can the ds and sts run as nonroot?
What new functionality do you want?
now the cephfs csi driver run as root user,can the ds and sts run as nonroot?
What is the value to the end user? (why is it a priority?)
How would the end user gain value from having this feature?
How will we know we have a good solution? (acceptance criteria)
Add a list of criteria that should be met for this feature to be useful
Additional context
Add any other context or screenshots about the feature request here.

@jianglingxia please  Fill all the relevant fields in the feature request template

in my project that user think use root user maybe not security，so the community now can support the feature use nonroot run ds and sts to provider cephfs volume create and delete and mount and umount ?
if ds and sts can not run nonroot and why?
really thanks

@ajarr ^^

@joscollin ^^

@jianglingxia Can you explain what are ds and sts? It is possible to create and delete a Volume using a non-root user in CephFS.

@joscollin  cephfsplugin daemonset(ds) which is responsible for mounting and unmounting cephfs subvolumeto/from  app pod
cephfsplugin provisioner statefulset(sts) which is responsible for creating/deleting cephfs subvolume

Does any one of these daemonset(ds) or statefulset(sts) work with a non-root user from your side? Especially statefulset(sts)?

I have not tested this one, but if we are able to execute ceph and rbd command without root user it should be possible ideally

Yeah those volume/subvolume operations should work with a non-root user.
@jianglingxia Could you please give us more clarity on this issue?

thanks for all of you reply!
yeah,ds provider mount and umount cephfs ,sts provider create and delete cephfs volume
if cephfs command can execute non-root user success then maybe ds and sts can run non-root,
but the community can support it?
or can you give me some advice  that if i modify the ds and yaml ,use PodSecurityPolicy
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
? but i not tested
thanks for your advice!

@Madhu-1 ^^

@jianglingxia please give a try and let us know the result!

/ # cat /etc/passwd
root:x:0:0:root:/root:/bin/ash
storage:x:1000:1000:Linux User,,,:/home/storage:/bin/sh
/ # su storage
/ $ whoami
storage
/ $ ceph-fuse /paasdata/docker/plugins/cephfs.csi.ceph.com/controller -m <IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS> -c /etc/ceph/ceph.conf -n client.admi
n --key=AQBmVY1dAAAAABAA57Xt8+lGfYloaNtxRztmhA== -r / -o nonempty
ceph-fuse[817]: starting ceph client
ceph-fuse[817]: ceph mount failed with (1) Operation not permitted

@jianglingxia You may not have permissions. Follow this document [1], Check your keys, check if the user has write access to mountpoint.
[1] https://docs.ceph.com/docs/master/cephfs/fuse/


Carousel out of Range Exception when loading shorter DataList while on last page(s) and navigating

Describe the bug
Radzen Carousel index will be out of bound if you load a new list which is shorter than current Index
To Reproduce
Steps to reproduce the behavior:

Create a default Carousel, best with Auto = false for easier timing
Go to the End of the carousel (highest index)
Load new data list, which is shorter than current into the bound variable
Now the carousel should update and show less index points for navigation without any of them being marked as active. But as Index is still too high you can't navigate as it is ArgumentOutOfRangeExeption on the "next" button.

On Auto=true it will be simply stuck on the last item of the list, but will be harder to time for reproducing.
Easy way to reproduce same error:

Go to official Demo for carousel
Add/Change button for manual navigation to jump to an index out of range (Count() + 1 for example)
(Build it to run)
Click that "wrong" button

Expected behavior
Not getting stuck or crashing. Should just jump to first item if out of range is called.
Desktop (please complete the following information):

Browser Chrome
Radzen Version 5.5.3

Additional context
Clicking on any of the available pager points is working, it will jump to the correct item.
But even going to previos item can be out of range, if the new list is still shorter.

I tried my hand at a Pull Request for a fix. (#1770)
As it is my first try on GitHub doing this please let me know if I should go about it in a different way.

Thanks for the pull request @Anspitzen! I think there is a more general way to fix this - I'll push it directly.


Client-Side UI: Extend React Prototype

Draw the rest of the owl time:

[x] Core rendering HTML content provided by a plugin (see detail view plugin content left-side/right-side) PluginTemplateExtension.[right/left/full_width]_page
[x] Plugin providing additional tabs on object detail view PluginTemplateExtension.detail_tabs
[ ] Core view rendering new components provided by a plugin (New, should be available via React)
[x] Plugin providing buttons in list view (TBD)

With what we've implemented for the plugin features above this should be straight forward to implement

[ ] Plugin overriding entire core view Views.override_views (assuming Django routing is no longer in play)
[ ] Plugin's home & config views:

://nautobot/plugins/example-plugin/config/
://nautobot/plugins/example-plugin/

Core rendering HTML content provided by a plugin (see detail view plugin content left-side/right-side) PluginTemplateExtension.[right/left/full_width]_page

Works similarly to Nautobot 1.x
No changes for plugin developers
Plugin template content fetched from django by javascript and loaded into the js ui via the dangerouslySetInnerHTML property

TODO

[ ] Load all tabs on page load but don't load content until active tab changes

Plugin providing additional tabs on object detail view PluginTemplateExtension.detail_tabs

Works similarly to Nautobot 1.x
No changes for plugin developers
Plugin template content fetched from django by javascript and loaded into the js ui via the dangerouslySetInnerHTML property

TODO

[ ] Load all tabs on page load but don't load content until active tab changes

Core view rendering new components provided by a plugin (New, should be available via React)

TODO

Plugin providing buttons in list view (TBD)

TODO?

Plugin overriding entire core view Views.override_views (assuming Django routing is no longer in play)

TODO

Plugin's home & config views

TODO

To augment or override core components with React componenets, plugins will export a plugin config constant in index.js that works similarly to the django PluginTemplateExtension class. Example:
const plugin_config = {
  detail_tabs: {
    "dcim:site": [ExamplePluginDcimSiteTab1],
    "dcim:device": [ExamplePluginDcimDeviceTab1]
  },
  full_width_page: {
    "circuits:circuit": [ExamplePluginCircuitFullWidthComponent]
  },
  view_overrides: {
    "ipam:prefix": {
      "list": ExamplePluginIpamPrefixListViewOverride,
      "retrieve": ExamplePluginIpamPrefixRetrieveViewOverride,
      "update": ExamplePluginIpamPrefixUpdateViewOverride,
      "destroy": ExamplePluginIpamPrefixDestroyViewOverride,
    }
  },
  buttons: {
    "ipam:ipaddress": [ExamplePluginButtonComponent]
  }
}

export default plugin_config


Truncating PBAR shear correction value

pyNastran defaults the shear correction values to 1e8 (meant to approximate infinity to recover EB beam behavior) for PBAR cards if the values are specified in the bdf file. This high value can lead to poor scaling in the stiffness matrix, which can lead to numerical issues in the solution. To fix this I'm adding a truncation step in _elemCallBackFromBDF that will use a smaller value of 1e3 instead.

pyNastran defaults the shear correction values to 1e8 (meant to approximate infinity to recover EB beam behavior) for PBAR cards if the values are specified in the bdf file.

Just checking my understanding, this should say "if the values are not specified in the bdf file" right? So if the user specifies correction factors in their BDF those will be correctly passed on to TACS?


Issue with update_index on after_commit :delete when overriding _id

@pyromaniac Due to an existing implementation detail (in another language) I have an index definition in Chewy that ends up looking like this ...
module Indices
  class DogsIndex < Chewy::Index
    define_type Models::Dog do
      field :id, type: "long"
    end

    define_type Models::Owner, name: "owner" do
      root parent: "dog",
           parent_id: -> { dog_id },
           _id: -> { external_id } do
        field :id, type: "long", value: -> { external_id }
        field :dog_id, type: "long"
        field :name
      end
    end
  end
end

For my Models::Owner it looks like
module Models
  class Owner < ActiveRecord::Base
    belongs_to :dog
    update_index "Indices::Dogs#owner", self
  end
end

I also tried these variations on update_index
update_index "Indices::Dogs#owner" do self end

update_index "Indices::Dogs#owner" do |owner| owner end

They had the same impact.
external_id is a attribute on an Owner model instance.
When creating or updating a instance of Owner I see no issues. However when I destroy an instance I get a sad face because the { external_id } bit is evaluated and self is equal to the id of the Owner instance, not the Owner instance, so therefore I get an error like undefined local variable or method external_id for 1:Fixnum
I'm trying to debug through this myself, but no luck so far.

To be even more clear - here is what the original mapping code looks like in Python. Perhaps what I'm doing wrong has to do with my declaration of the mapping in Chewy and not to do with the update_index call
self._put_mapping('owner', {
            "owner": {
                "_parent": {
                    "type": "dog"
                },
                "_routing": {
                    "required": True,
                    "path": "dog_id"
                },
                "_id": {
                    "path": "id"
                },
                "properties": {
                    "dog_id": {
                        "type": "integer",
                        "index": "not_analyzed",
                    },
                   "name": {
                      "index": "not_analyzed",
                   },
                }
            }
        }, index=self.index_name)

I also realize I can get to the external id in the updates_index block via the previous_changes hash, but I don't see how that helps unless I use some kind of anti-pattern to decorate self such that self.id returns self.external_id inside of the block only.

Don't you have any stacktrace?

D, [2015-11-14T00:47:31.414963 #19050] DEBUG -- :   Models::Owner Load (0.6ms)  SELECT  owners.* FROM owners  WHERE owners.deleted_at IS NULL AND owners.id = 7511 LIMIT 1
DEBUG -  Chewy strategies stack: [2] <- atomic @ /home/vagrant/xxxxxxxx/current/dwapi/lib/routes/resources.rb:173
DEBUG -  Chewy strategies stack: [2] -> atomic @ /home/vagrant/xxxxxxxx/current/dwapi/lib/routes/resources.rb:173
DEBUG -  Chewy strategies stack: [2] <- atomic @ /home/vagrant/xxxxxxxx/current/dwapi/lib/routes/resources.rb:182
D, [2015-11-14T00:47:31.417015 #19050] DEBUG -- :    (0.4ms)  BEGIN
D, [2015-11-14T00:47:31.418603 #19050] DEBUG -- :   SQL (0.4ms)  UPDATE owners SET owners.updated_at = '2015-11-14 00:47:31', owners.deleted_at = '2015-11-14 00:47:31' WHERE owners.id = 7511
D, [2015-11-14T00:47:31.420985 #19050] DEBUG -- :    (2.0ms)  COMMIT
DEBUG -  Chewy strategies stack: [2] -> atomic @ /home/vagrant/xxxxxxxx/current/dwapi/lib/routes/resources.rb:182
D, [2015-11-14T00:47:31.425000 #19050] DEBUG -- :    (0.5ms)  SELECT COUNT(*) FROM owners  WHERE owners.deleted_at IS NULL AND owners.id IN (7511)
NameError - undefined local variable or method external_id' for 7511:Fixnum: 	/home/vagrant/xxxxx/current/dwapi/lib/indices/dogs_index.rb:11:in block (2 levels) in class:DogsIndex'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/fields/root.rb:72:in instance_exec' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/fields/root.rb:72:in compose_id'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:89:in delete_bulk_entry' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:81:in block (2 levels) in bulk_body'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:81:in map' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:81:in block in bulk_body'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:79:in each' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:79:in inject'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:79:in bulk_body' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:30:in block (2 levels) in import'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:126:in block in import_objects' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:125:in each_slice'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:125:in each' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:125:in map'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:125:in import_objects' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:86:in import'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:28:in block in import' 	/usr/local/rvm/gems/ruby-2.1.1/gems/activesupport-4.1.7/lib/active_support/notifications.rb:159:in block in instrument'
/usr/local/rvm/gems/ruby-2.1.1/gems/activesupport-4.1.7/lib/active_support/notifications/instrumenter.rb:20:in instrument' 	/usr/local/rvm/gems/ruby-2.1.1/gems/activesupport-4.1.7/lib/active_support/notifications.rb:159:in instrument'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:27:in import' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy/atomic.rb:27:in block in leave'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy/atomic.rb:27:in each' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy/atomic.rb:27:in all?'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy/atomic.rb:27:in leave' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy.rb:36:in tap'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy.rb:36:in pop' 	/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy.rb:44:in wrap'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy.rb:161:in strategy' 	/home/vagrant/xxxxxxx/current/dwapi/lib/routes/resources.rb:182:in block in registered'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1603:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1603:in block in compile!'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in []' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in block (3 levels) in route!'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:985:in route_eval' 	/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:135:in route_eval_with_newrelic'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in block (2 levels) in route!' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1006:in block in process_route'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1004:in catch' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1004:in process_route'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:115:in process_route_with_newrelic' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:964:in block in route!'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:963:in each' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:963:in route!'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1076:in block in dispatch!' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in block in invoke'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in catch' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in invoke'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1073:in dispatch!' 	/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:166:in dispatch_and_notice_errors_with_newrelic'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:152:in block in dispatch_with_newrelic' 	/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:366:in perform_action_with_newrelic_trace'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:149:in dispatch_with_newrelic' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:898:in block in call!'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in block in invoke' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in catch'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in invoke' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:898:in call!'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:886:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/rack/browser_monitoring.rb:23:in traced_call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:55:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/rack/agent_hooks.rb:30:in traced_call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:55:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/bugsnag-2.8.10/lib/bugsnag/rack.rb:33:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-cors-0.3.1/lib/rack/cors.rb:72:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/home/vagrant/mattermark/current/dwapi/lib/rack/rate_limit.rb:21:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.2/lib/rack/logger.rb:15:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.2/lib/rack/commonlogger.rb:33:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:217:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:210:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.2/lib/rack/head.rb:11:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.2/lib/rack/methodoverride.rb:21:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:180:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:2014:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1478:in block in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1788:in synchronize'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1478:in call' 	/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:86:in block in pre_process' 	/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:84:in catch'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:84:in pre_process' 	/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:53:in process'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:39:in receive_data' 	/usr/local/rvm/gems/ruby-2.1.1/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in run_machine'
/usr/local/rvm/gems/ruby-2.1.1/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in run' 	/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/backends/base.rb:73:in start'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/server.rb:162:in start' 	/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/controllers/controller.rb:87:in start'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/runner.rb:200:in run_command' 	/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/runner.rb:156:in run!'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/bin/thin:6:in <top (required)>' 	/usr/local/rvm/gems/ruby-2.1.1/bin/thin:23:in load'
/usr/local/rvm/gems/ruby-2.1.1/bin/thin:23:in <main>' 	/usr/local/rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in eval'
/usr/local/rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in <main>' E, [2015-11-14T00:47:31.438646 #19050] ERROR -- : Exception: NameError: undefined local variable or method external_id' for 7511:Fixnum
E, [2015-11-14T00:47:31.438792 #19050] ERROR -- : /home/vagrant/xxxxxx/current/dwapi/lib/indices/dogs_index.rb:11:in block (2 levels) in <class:DogsIndex>' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/fields/root.rb:72:in instance_exec'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/fields/root.rb:72:in compose_id' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:89:in delete_bulk_entry'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:81:in block (2 levels) in bulk_body' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:81:in map'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:81:in block in bulk_body' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:79:in each'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:79:in inject' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:79:in bulk_body'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:30:in block (2 levels) in import' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:126:in block in import_objects'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:125:in each_slice' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:125:in each'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:125:in map' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:125:in import_objects'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/adapter/orm.rb:86:in import' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:28:in block in import'
/usr/local/rvm/gems/ruby-2.1.1/gems/activesupport-4.1.7/lib/active_support/notifications.rb:159:in block in instrument' /usr/local/rvm/gems/ruby-2.1.1/gems/activesupport-4.1.7/lib/active_support/notifications/instrumenter.rb:20:in instrument'
/usr/local/rvm/gems/ruby-2.1.1/gems/activesupport-4.1.7/lib/active_support/notifications.rb:159:in instrument' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/type/import.rb:27:in import'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy/atomic.rb:27:in block in leave' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy/atomic.rb:27:in each'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy/atomic.rb:27:in all?' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy/atomic.rb:27:in leave'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy.rb:36:in tap' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy.rb:36:in pop'
/usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy/strategy.rb:44:in wrap' /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.7.0/lib/chewy.rb:161:in strategy'
/home/vagrant/xxxxxx/current/dwapi/lib/routes/resources.rb:182:in block in registered' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1603:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1603:in block in compile!' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in []'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in block (3 levels) in route!' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:985:in route_eval'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:135:in route_eval_with_newrelic' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in block (2 levels) in route!'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1006:in block in process_route' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1004:in catch'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1004:in process_route' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:115:in process_route_with_newrelic'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:964:in block in route!' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:963:in each'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:963:in route!' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1076:in block in dispatch!'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in block in invoke' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in catch'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in invoke' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1073:in dispatch!'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:166:in dispatch_and_notice_errors_with_newrelic' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:152:in block in dispatch_with_newrelic'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:366:in perform_action_with_newrelic_trace' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/sinatra.rb:149:in dispatch_with_newrelic'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:898:in block in call!' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in block in invoke'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in catch' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in invoke'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:898:in call!' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:886:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/rack/browser_monitoring.rb:23:in traced_call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:55:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/rack/agent_hooks.rb:30:in traced_call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:55:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/bugsnag-2.8.10/lib/bugsnag/rack.rb:33:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-cors-0.3.1/lib/rack/cors.rb:72:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/home/vagrant/mattermark/current/dwapi/lib/rack/rate_limit.rb:21:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.2/lib/rack/logger.rb:15:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.2/lib/rack/commonlogger.rb:33:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:217:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:210:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.2/lib/rack/head.rb:11:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.2/lib/rack/methodoverride.rb:21:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:180:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:2014:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1478:in block in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1788:in synchronize' /usr/local/rvm/gems/ruby-2.1.1/gems/sinatra-1.4.5/lib/sinatra/base.rb:1478:in call'
/usr/local/rvm/gems/ruby-2.1.1/gems/newrelic_rpm-<IP_ADDRESS>5/lib/new_relic/agent/instrumentation/middleware_tracing.rb:57:in call' /usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:86:in block in pre_process'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:84:in catch' /usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:84:in pre_process'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:53:in process' /usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/connection.rb:39:in receive_data'
/usr/local/rvm/gems/ruby-2.1.1/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in run_machine' /usr/local/rvm/gems/ruby-2.1.1/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in run'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/backends/base.rb:73:in start' /usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/server.rb:162:in start'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/controllers/controller.rb:87:in start' /usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/runner.rb:200:in run_command'
/usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/lib/thin/runner.rb:156:in run!' /usr/local/rvm/gems/ruby-2.1.1/gems/thin-1.6.3/bin/thin:6:in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.1/bin/thin:23:in load' /usr/local/rvm/gems/ruby-2.1.1/bin/thin:23:in '
/usr/local/rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in eval' /usr/local/rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in '
<IP_ADDRESS> - - [14/Nov/2015 00:47:31] "DELETE /1.3/orm/owners/7511 HTTP/1.1" 500 11867 0.0805

Sorry to bother you with this, I've just been busting my face up against it all day.

Well, the problem is here: https://github.com/toptal/chewy/blob/master/lib/chewy/type/import.rb#L91
I'm trying to compose id, while id is not an object. And it is not an object because atomic strategy stores ids instead of objects. https://github.com/toptal/chewy/blob/master/lib/chewy/strategy/atomic.rb#L23

Is this working as you expect or do you believe that this is a defect for which a change / fix is appropriate?

Defect. And solution would be: in the atomic strategy here https://github.com/toptal/chewy/blob/master/lib/chewy/strategy/atomic.rb#L23 to use adapter.some_method which returns identify method result or composed ids using type-defined id evaluator if is exist. And remove https://github.com/toptal/chewy/blob/master/lib/chewy/type/import.rb#L91 and https://github.com/toptal/chewy/blob/master/lib/chewy/type/import.rb#L111 lines code since here we will have composed id already.

Misspelled: use type.identify which uses type.adapter.identify to add composing logic there

The only thing I'm concerned about is: composing id evaluation would be highly inefficient for objects collection. But actually we have the same case currently, so it is fine. Also none of the specs supposed to be broken with such an approach.

k. With a fix in place will you patch 0.7.0 to 0.7.1 or do I need to switch to latest v?

Better to switch to latest, there are tones of fixes

Which version of ES are you running your specs against? I can't get latest master to pass locally. Which is odd because it didn't used to be an issue.

Failure/Error: stub_model(:city)
     NoMethodError:
       undefined method `stub_model' for #<RSpec::ExampleGroups::ChewySearch::NamedScopes:0x000000069f1388>

19 additional errors with the same NoMethodError.

Yeah same problem even with a completely fresh checkout. Hmm.

Check out travis.yml
14 Ноя 2015 г. 12:49 пользователь "caldwecr"<EMAIL_ADDRESS>написал:

Yeah same problem even with a completely fresh checkout. Hmm.
—
Reply to this email directly or view it on GitHub.

@pyromaniac as an FYI I had to uncomment the
# gem 'activerecord'

from the Gemfile to get the specs passing. Not sure why so many gems are commented out in the Gemfile

Well, because gemfile is mostly a template for appraisals :) Any success on patch? Maybe you have questions?

Close on patch. About to push it up.

Ok well I'm having trouble with removing line 91 from type/import.rb - can you be a bit more clear about exactly what you think these areas of code should look like?
I'll push up the change I have and open a PR where we can discuss the removals (L91 and L111)

See #282

Hey, @caldwecr, look, it is a bit complicated and probably almost impossible to fix this in a common way, but there is a workaround:
module Models
  class Owner < ActiveRecord::Base
    belongs_to :dog
    update_index("Indices::Dogs#owner") { destroyed? ? external_id : self }
  end
end

Tell me please if it works or not for you. I will continue fixing everything over the weekend, currently I don't have much time to do this though.

Or maybe it would not help. Try the latest master please, I did some patch

The latest master appears to fix the problem when I test it in the application. It (strangely) still fails the spec that I wrote
describe "Destroying a Owner model" do
    it "updates the ::dogs#owner" do
      expect { owner.destroy }.
        to update_index Indices::DogsIndex::Owner
    end
  end

produces
(to actual test the change I built the gem and installed it as 0.8.3)
Failure/Error: expect { owner.destroy }.
     NoMethodError:
       undefined method `with' for nil:NilClass
     # /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.8.3/lib/chewy/rspec/update_index.rb:103:in `instance_eval'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.8.3/lib/chewy/rspec/update_index.rb:103:in `instance_eval'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/chewy-0.8.3/lib/chewy/rspec/update_index.rb:103:in `block (2 levels) in <top (required)>'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-expectations-3.1.2/lib/rspec/matchers/dsl.rb:43:in `block in match'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-expectations-3.1.2/lib/rspec/expectations/handler.rb:48:in `handle_matcher'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-expectations-3.1.2/lib/rspec/expectations/expectation_target.rb:54:in `to'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-expectations-3.1.2/lib/rspec/expectations/expectation_target.rb:87:in `to'
     # ./spec/chewy/updating_indexes_spec.rb:54:in `block (3 levels) in <top (required)>'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:152:in `instance_exec'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:152:in `block in run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:222:in `call'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:222:in `call'
     # ./spec/spec_helper.rb:91:in `block (3 levels) in <top (required)>'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/database_cleaner-1.4.1/lib/database_cleaner/generic/base.rb:15:in `cleaning'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/database_cleaner-1.4.1/lib/database_cleaner/base.rb:92:in `cleaning'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/database_cleaner-1.4.1/lib/database_cleaner/configuration.rb:86:in `block (2 levels) in cleaning'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/database_cleaner-1.4.1/lib/database_cleaner/configuration.rb:87:in `call'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/database_cleaner-1.4.1/lib/database_cleaner/configuration.rb:87:in `cleaning'
     # ./spec/spec_helper.rb:90:in `block (2 levels) in <top (required)>'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:322:in `instance_exec'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:322:in `instance_exec'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:380:in `execute_with'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:446:in `block (2 levels) in run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:222:in `call'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:222:in `call'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:447:in `run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/hooks.rb:500:in `run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:331:in `with_around_example_hooks'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example.rb:149:in `run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example_group.rb:490:in `block in run_examples'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example_group.rb:486:in `map'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example_group.rb:486:in `run_examples'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example_group.rb:453:in `run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example_group.rb:454:in `block in run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example_group.rb:454:in `map'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/example_group.rb:454:in `run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:111:in `block (2 levels) in run_specs'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:111:in `map'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:111:in `block in run_specs'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/reporter.rb:53:in `report'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:107:in `run_specs'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:85:in `run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:69:in `run'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:37:in `invoke'
     # /usr/local/rvm/gems/ruby-2.1.1/gems/rspec-core-3.1.7/exe/rspec:4:in `<top (required)>'
     # /usr/local/rvm/gems/ruby-2.1.1/bin/rspec:23:in `load'
     # /usr/local/rvm/gems/ruby-2.1.1/bin/rspec:23:in `<main>'
     # /usr/local/rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `eval'
     # /usr/local/rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `<main>'

Finished in 8.32 seconds (files took 2.2 seconds to load)
1 example, 1 failure

It seems like you have Mocha installed but not enabled: https://github.com/toptal/chewy/blob/master/lib/chewy/rspec/update_index.rb#L197

Looks good to me. Can you ship a latest version 0.8.4?
Kind regards. Thanks for all the assistance.

Welcome! As for a new version - it will be a little bit later. Use master please for now.

Btw, there was a Mocha fix, did it help?

Yes that did help. It resolved my issue.

@mainameiz thanks, you was in time :)

Great :-)


Fix of default test executions summary for non-first feature

Right now behavior is pretty strange, when we execute several feature files with:
behave -i tests/features --f xray -D xray.summary='Our cool summary'
At the end we get only 1 xray ticket with Our cool cummary summary and others have default one Execution of automated tests.
This PR suppose to deal this issue.

Thank you for the PR. It looks good, I'll merge it after I fix the CI.

Thank you for the PR. It looks good, I'll merge it after I fix the CI.

Thanks. Looking forward to see new build on PyPI.


Node Status

Description
Building on the Node State work in #321 we need a /status endpoint to report current status of all nodes in the cluster.  Status should include the following information

Version
Replica Number
Number of nodes
List of Databases

name
column Label
max slice per DB
Highest Column ID
Time Quantum
Frames per Database

name
Frame type
Row Label
Row ID range per frame (TDB)
cache size per frame
List Views per frame

View type

List of nodes with the following info per node:

ID of node
IP of node
Node State
Health value (TBD)
Slices owned by node from DB
Replica Slices owned by node by DB

Success criteria (What criteria will consider this ticket closeable?)

@raskle I'm closing this because it was sitting in Review/QA
Please re-open it (or open a new ticket) if there is still work that needs to be done on this.


Conflict with core-js

anonymous/node_modules/react-helmet/node_modules/core-js/modules/_hide.js:4
return $.setDesc(object, key, createDesc(1, value));
          ^

    TypeError: Cannot redefine property: Symbol(Symbol.iterator)

core-js is a Mongoosastic dependency if i get it right.
any idea?

We are in the process of deprecating, then removing polyfills from Helmet.

@cwelch5 i found out that importing Helmet before Mongoosastic (which uses.l core.js for my understanding) solves the issue for now

Fixed in<EMAIL_ADDRESS>


Error when using example code

I am making a BLE beacon finder app. I copied the example code for the "flutter_blue_beacon" package to test if it works. When I run it, I get the following error:
A problem was found with the configuration of task ':flutter_blue:generateDebugProto'.
> Directory 'C:\Users\***\AndroidStudioProjects\ble_app\build\flutter_blue\extracted-include-protos\main' specified for property '$3' does not exist.

Is this an error with the example code or the package?
Thank you in advance.

I am making a BLE beacon finder app. I copied the example code for the "flutter_blue_beacon" package to test if it works. When I run it, I get the following error:
A problem was found with the configuration of task ':flutter_blue:generateDebugProto'.
> Directory 'C:\Users\***\AndroidStudioProjects\ble_app\build\flutter_blue\extracted-include-protos\main' specified for property '$3' does not exist.

Is this an error with the example code or the package?
Thank you in advance.

I got the same issue

I have same problem...


Update Guide-Intro.md

Add a sentence to remind the user to import Button. The error is fairly self explanatory but if someone new is learning explicitly explaining doesn't hurt.
Please provide enough information so that others can review your pull request:
Explain the motivation for making this change. What existing problem does the pull request solve?
Just trying to make documentation more explicit. Won't be offended in anyway if this doesn't match the author's original intention and is rejected.
Prefer small pull requests. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise split it.
Test plan (required)
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure you test on both platforms if your change affects both platforms.
The code must pass tests and shouldn't add more Flow errors.
Code formatting
Look around. Match the style of the rest of the codebase.

Hey, thanks for the PR - it's sort of a duplicate of what's in #2679 ;)

It looks like it's the same part of the guide-intro but two different
issues. I did hit that issue as well that's mentioned in 2679. If you want
to just add it to 2679 go for it!
On Mon, Oct 2, 2017 at 1:23 AM Lorenzo Sciandra<EMAIL_ADDRESS>wrote:

Hey, thanks for the PR - it's sort of a duplicate of what's in #2679
https://github.com/react-community/react-navigation/pull/2679 ;)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/react-community/react-navigation/pull/2681#issuecomment-333470270,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAyb-6e8EXBtppya8gOUTtS9-ct5XmVaks5soJ2bgaJpZM4PqCz5
.

Ohh I see sorry I'm terrible with the Github review UI I only saw the code from the one comment so was super confused, thanks for being so patient and the great getting started guide!


Can not start, stay in the process

VSCode Version:1.13.1
OS Version:window10

Steps to Reproduce:
1.double click.Can not start,stay in the process.
2.After uninstalling, double-click to start, the problem still exists
note:

After the editor is upgraded, there is a problem

Reproduces without extensions: No
picture

Have you tried restarting your machine? Did it work with version 1.12?

I restarted the computer many times, and the problem still exists
the vscode version is 1.13.1

Who can help me?

Can you try starting from the command line with code --verbose and post the output here?

@chrmarti
I'm sorry I didn't see your reply. I reset my computer, and then the problem was solved. However, the reasons for the problem are still unclear. The problem was that I upgraded from 1.12 to 1.13. So vscode couldn't run. But the program will stay in the process.


Changing Quick-Copy Style?

Log ID: A8NT62WW-euc
I'm trying to use this plugin for Obsidian.md:
https://github.com/mgmeyers/obsidian-zotero-desktop-connector
I'm trying to get it to output in-text citation with the MLA (9th) style, and I think it needs the Quick-Copy function to work, as changing that, changes the plugin's output. However, I can't figure out how to change the Quick-Copy style to one that outputs MLA, i.e. simply (Author page-number).
Is this possible? Or am I misunderstanding the purpose of Quick-Copy?
Thanks!!

I think this was just awkward to set up, I'll get something better over the weekend.


Improve developer experience when debugging

Summary of the new feature / enhancement
I just sent my first PR to this project and I went through two issues which took me some time to figure out:

If you try to debug pwsh with Visual Studio it will start \win7-x64\publish\pwsh.exe, which is not what is build by VS. This is misleading.
System.Management.Automation.csproj has set EmitCompilerGeneratedFiles to true, and this is making the start of debugging process fail, unless you right click the solution and restore all nuget packages. Only after you are able to debug.

This experience is bad for newcomers and needs to improve.
Proposed technical implementation details (optional)

Add to src/powershell-win-core/Properties/launchSettings.json:

    "powershell-win-core-debug": {
      "commandName": "Project"
    }

Remove from src/System.Management.Automation/System.Management.Automation.csproj:

  <PropertyGroup>
    <!-- we persist source generator files under 'gen' folder so that they are visible to IDEs -->
    <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
    <CompilerGeneratedFilesOutputPath>gen\SourceGenerated</CompilerGeneratedFilesOutputPath>
  </PropertyGroup>

can I take this task to work?


Upgrade Ginkgo and EnvTest

With upgrading EnvTest, we have a much easier setup for tests!
Ginkgo we are upgrading to v2, which has small back-incompatabilities.

@janhoy and @gerlowskija I know y'all have both had issues with your M1 macbooks and the build system before. So I definitely want to have y'all successfully do a run through before merging this 🙂

Note, when you upgrade your golang version (1.19 is now required) I highly suggest running make clean mod-tidy to clear all of your cached dependencies

This works for me!  I had a small issue with bad syntax on a chmod command used by make clean.  (I've pushed that fix up to this PR after a short conversation offline with Houston)


Use Homebrew to set a cookie?

Can Homebrew set a cookie?  If so, perhaps you could follow the logic that Scoop's oraclejdk package uses; essentially set the oraclelicense to accept-securebackup-cookie.

I understand that OracleJDK only needs an accepted licence to allow a download. InstantClient however needs the user to be signed in in addition to the licence. In other words, I have not found a combination of cookies to give access to the files.

Sorry, I guess that I forgot about that.
What if the formula an option that assumed that the credentials had been provided (user supplied values at https://login.oracle.com/mysso/signon.jsp which sets the required auth cookies).  If so, sending a POST to http://www.oracle.com/technetwork/topics/intel-macsoft-096467.html with form element of oraclelicense set to accept-ic_macosx-cookie, generates the various ZIP files' URLs.
To perform authentication, these form elements need to be set: sso_username, ssopassword, locale, v, request_id, OAM_REQ, site2pstoretoken.  I suppose you could prompt for the first two (which assumes that you've created an Oracle account), but you'd have to issue a GET request to http://www.oracle.com/technetwork/topics/intel-macsoft-096467.html to get the current values of the other elements.

I would hesitate to merge such a change in even if someone made a PR for it. There would be a lot of flaky logic involved in my opinion.

Oracle makes it complicated to install the packages automatically. I do not want to hack around that fact. Any code that tries to will probably end up being complex and unstable. Let's instead nag Oracle to simplify file downloads.
Closing this issue until there are better ideas.


Report country code in upper case

While at it, maybe we should rename NETWORK to NETWORK_TYPE. I'd expect something called NETWORK to be the name of the network

While at it, maybe we should rename NETWORK to NETWORK_TYPE.

Done


enable clearing UPNs from UserInfo entries stored in Azure Storage

Story: I need to remove all email addresses after 30 days.
We need to support a scheduled task that removes UPNs from UserInfo structs in the Azure Storage Tables after some duration.
As of this issue, these are Job, Task, and Repo structs need to have UPNs scrubbed.
AB#39994473

Resolved with PR #1051


Any number for performance benchmark?

The project looks promising, is there any number about its performance?

At a high level, performance is “fast”. Exact numbers depend on what test is being run, and the environment in which it is being run.  (These observations hold for weaker/untuned hardware, but with software options tuned for higher performance [e.g. RAM storage, loose consistency]. Using better hardware/tuning will result in better performance. Changing software options will lower performance.)
Single operation latency: ~150 us.
Scale: At least tens of thousands of concurrent writers and readers, and thousands of servers.
Throughput: For small values, a single client thread can write/read around 100,000 key-value pairs per second using bulk operations. Adding threads increases throughput. With larger values, throughput becomes constrained by the network (we have tested through 10G).


cannot import name 'imresize'

<<Please describe the issue in detail here, and for bug reports fill in the fields below.>>
ImportError                               Traceback (most recent call last)
 in ()
1 # Code (adapted) from https://github.com/ageron/handson-ml
2
----> 3 from scipy.misc import imresize
4 #from keras.preprocessing.image import ImageDataGenerator
5
ImportError: cannot import name 'imresize'
Reproducing code example:
<<A short code example that reproduces the problem. It should be self-contained, i.e., possible to run as-is via 'python myproblem.py'>>

Error message:
<<Full error message, if any (starting from line Traceback: ...)>>

Scipy/Numpy/Python version information:
<<Output from 'import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info)'>>

These functions are available only when Pillow is installed.

Thank you. How to install Pillow. If you please share the codes

For Pillow installation see: https://pillow.readthedocs.io/en/5.1.x/installation.html.
pip install Pillow
works in many platforms/environments.