MCEdit 1.5.0 64-bit Windows - Can't import large (20MB+) schematics (Merging worlds)

I'm attempting to merge several old worlds together. Despite appearing to perform the schematic import, including copying the blocks for many minutes, then on save, relighting the affected chucks, nothing is actually imported.
A rough of the steps I've taken... (Note I close and reopen MCEdit for each world, just to be safe)

Loaded old maps in official 1.8.9 client to convert them. I was happy with the result, no issues.
Reviewed each of the old maps in MCEdit 1.5, no issues found.
Pruned many chunks from the old maps to shrink them down to only include what I want (Though still largeish areas)
Checked each map to ensure no issues, still happy with the results.
Exported the entirety of each map to a schematic.
5a) Selected the chucks I wanted (All of them, really)
5b) Switched the select tool, which changed the selection to a large block, with height of 256 and large x/y.
5c) Used Export. The progress bar showed an appropriate chuck/block count and seemed successful.
Loaded the new world I am importing into and created a large space of new chucks with Flatworld generator.
Saved and reloaded everything, confirmed new chucks were good.
Attempted to import the largest schema (With all checkboxes marked, i.e. Copy Air, Copy Biomes, etc). After close to 30+ minutes of copying blocks (4 billion plus blocks), MCEdit returns control to me.
No visible effect from import, all chucks are still "flatworld"
Saved map, waiting a fairly long time for lighting to complete
Closed MCEdit and reopened the target map. All chucks are still flatworld, no evidence of import.

I attempted this several times but could not get the import to work. I later tried to smaller of my 3 world import schematics and had the same results.
I have attached the smallest schematic (Roughly 25MB)
WorldImport.zip
There are also the following error messages that occur when trying to import the schematic:
Running in fixed mode. Support files are in your Documents folder.
Splash load...
Minecraft_Server.jar storage initialized.
Each server is stored in a subdirectory of C:\Users\Redact\Documents\MCEdit\ServerJarStorage named with the server's version number
Cached servers:  [u'Release 1.8.9']
None
C:\Users\Redact\AppData\Roaming.minecraft\saves\creative
Traceback (most recent call last):
File "C:\build\bin64\build\mcedit\out00-PYZ.pyz\pymclevel.infiniteworld", line 1184, in loadLevelDat
File "_nbt.pyx", line 574, in _nbt.load (_nbt.c:11895)
IOError: [Errno 2] No such file or directory: 'c:\users\Redact\appdata\local\temp\tmpvqpe6bschematic\level.dat_old'
IOError(2, 'No such file or directory')
Canceled
Traceback (most recent call last):
File "C:\build\bin64\build\mcedit\out00-PYZ.pyz\pymclevel.infiniteworld", line 1184, in loadLevelDat
File "_nbt.pyx", line 574, in _nbt.load (_nbt.c:11895)
IOError: [Errno 2] No such file or directory: 'c:\users\Redact\appdata\local\temp\tmplgchymschematic\level.dat_old'
IOError(2, 'No such file or directory')
Canceled
Traceback (most recent call last):
File "C:\build\bin64\build\mcedit\out00-PYZ.pyz\pymclevel.infiniteworld", line 1184, in loadLevelDat
File "_nbt.pyx", line 574, in _nbt.load (_nbt.c:11895)
IOError: [Errno 2] No such file or directory: 'c:\users\Redact\appdata\local\temp\tmpdbvuyeschematic\level.dat_old'
IOError(2, 'No such file or directory')
Canceled
Destination:  _Vector(x=3664, y=0, z=-2928)

Earlier, it seemed like I couldn't place the Import selection in an area that didn't already have chunks generated. Hence, I generated some flat world. For whatever reason, I'm now able to place the schematic's import box in "no chunk" space. The result is that MCEdit very quickly displays it's "Copying x blocks" dialogue and within a second closes it, again with no visible changes to the world.
The difference in this method is that the "Copy" is over almost instantly, while copying over existing chunks takes 15+ minutes. The result appears to be the same though.
The same error message about a level.dat_old occurs in this case.

Try importing the pruned world directly instead of exporting to a schematic and importing.
It looks like exporting very large schematics (using an alternate file format) is broken.

Apologies. I feel like a complete idiot, as I did not even realize Import worked directly on level.dat files, rather than just schematics. It's been a few years.
For the record, MCEdit was able to import the level.dat with no issue.

So the BUG is: Schematics are broken

For me it works fine...


metrics provider

Issues affected/resolved
(See https://github.com/blog/1506-closing-issues-via-pull-requests)
Resolves #51
Description:
Basic system  metrics and info

This change is

Reviewed 15 of 15 files at r1, 6 of 6 files at r2, 2 of 2 files at r3, 7 of 7 files at r4, 2 of 2 files at r5, 1 of 1 files at r6.
Review status: all files reviewed at latest revision, 6 unresolved discussions.

.gitignore, line 6 [r3] (raw file):
yeah this commit should be squashed with the one that introduces the binary

cmd/metrics-provider/main.go, line 12 [r1] (raw file):
I wonder if we should just do this in logrusx's init() func and let bygones just be.

providers/metrics/disk.go, line 17 [r2] (raw file):
what does io mean?

providers/metrics/hardware.go, line 15 [r5] (raw file):
I guess you can combine these two lines if you want.

providers/metrics/network.go, line 16 [r2] (raw file):
ditto wrt io is this current usage or something?

cmd/metrics-provider/metrics-provider, line 0 [r1] (raw file):
can we rebase and get rid of this binary from history

Comments from Reviewable

Review status: all files reviewed at latest revision, 6 unresolved discussions.

.gitignore, line 6 [r3] (raw file):
Done.

cmd/metrics-provider/main.go, line 12 [r1] (raw file):
Mabye. There's plenty of places to change it (and/or make logrusx better), so better for a separate issue/PR.

providers/metrics/disk.go, line 17 [r2] (raw file):
Things like bytes read/written, read/write times, read/write count.

providers/metrics/hardware.go, line 15 [r5] (raw file):
Done.

providers/metrics/network.go, line 16 [r2] (raw file):
Things like bytes sent/received, packets sent/received.

Comments from Reviewable

Review status: 7 of 17 files reviewed at latest revision, 6 unresolved discussions.

cmd/metrics-provider/metrics-provider, line  [r1] (raw file):
This seems to be gone after rebasing the gitignore into the first commit. I can't find the file in the history on my side.

Comments from Reviewable

Reviewed 10 of 10 files at r7, 6 of 6 files at r8, 7 of 7 files at r9, 2 of 2 files at r10, 1 of 1 files at r11, 1 of 1 files at r12.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


[Lab-2] Implement of generic quick sort algorithm

Implement of generic quick sort algorithm.

Work done.


Add tests for pg_attrdef ENR change

This commit adds tests for the engine change adding pg_attrdef to ENR.
Task: BABEL-4752
Description
[Describe what this change achieves - Guidelines below (please delete the guidelines after writing the PR description)]

What is the change? This is best described in terms of “Currently, Babelfish does X. With this change it now does Y.” Think of “What did it used to do?” and “What does it do now?”

Why was the change made? What drove our desire to put effort into the change?
How was the code changed should only appear for large commits. This can serve as a rough roadmap to what’s contained in the commit. It should be very high level; if it’s directly referencing code it’s probably too detailed. It’s also critical that this section of a commit message does not try to replace proper code documentation (ie, block comments or README files). Generally, this section should only appear if the commit itself is large enough that it’s helpful to provide a roadmap to someone looking at the commit.
The last descriptive piece is the “title” for the commit: the very first line of the commit message, which should typically be less than 80 characters. A good title is critical, because it’s the only thing that shows up in places like the Github commit listing. No one’s got time to read through full commit messages when trying to find a single commit out of dozens.

Issues Resolved
[List any issues this PR will resolve]
Test Scenarios Covered

Use case based -

Boundary conditions -

Arbitrary inputs -

Negative test cases -

Minor version upgrade tests -

Major version upgrade tests -

Performance tests -

Tooling impact -

Client tests -

Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>8
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 73.435%

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
42187

Relevant Lines:
57448

💛  - Coveralls


I want to change the dapui console

I have this problem when debugging in c where the dapui console doesn't show anything and is completely useless I found a solution and its just having another console in another tab going back and forth between dapui and the other console is a bit irritating is there a way I can remove dapui console and replace it with this one ?

@Rahim-444, please tell me how. I have the same issue(

@Rahim-444, please tell me how. I have the same issue(

i fixed the issue a long time ago i don't remember what i did to fix it you can check on my nvim config search the commits if possible i no longer work with the C language i don't remember how to even start a debugger atm lol, if you still can't find it or need help you can follow up with another comment i will try to help

@Rahim-444  After some research, I found out that it was gdb's implementation issue. Thanks anyway.


DataSpace can be included and localized in relational stores

What type of PR is this?
Improvement
What does this PR do / why is it needed ?
Consumers can include and localize the relational stores under a dataspace using the existing include syntax for mapping and store.

This PR was closed because it has been inactive for 35 days. Please re-open if this PR is still relevant.


Crash in background NSURLSession "HTTPMessage::ensureParserFinished()"

I'm seeing a lot of stack traces that look like this recently (perhaps more prevalent in iOS 8).
I know AFNetworking isn't in the stack trace, but since I only use AFNetworking to do my background transfer service I figured I would ask:
Anyone else come across anything similar?
Thread : Crashed: com.apple.NSURLSession-work
0  libsystem_kernel.dylib         0x39b91dfc __pthread_kill + 8
1  libsystem_pthread.dylib        0x39c0fd37 pthread_kill + 62
2  libsystem_c.dylib              0x39b31909 abort + 76
3  libsystem_malloc.dylib         0x39bc23af szone_error + 334
4  libsystem_malloc.dylib         0x39bc2637 free_small_botch + 66
5  CFNetwork                      0x2b8ba935 HTTPMessage::ensureParserFinished() + 72
6  CFNetwork                      0x2b8ba8c9 HTTPMessage::copyAllHeaderFields(__CFArray const**) + 12
7  CFNetwork                      0x2b8e421d -[NSHTTPURLResponse allHeaderFields] + 44
8  CFNetwork                      0x2b92deb1 -[__NSURLBackgroundSession setCookiesFromResponse:forOriginalRequest:] + 212
9  CFNetwork                      0x2b9315f5 __81-[__NSURLBackgroundSession backgroundTask:didCompleteWithError:timingData:reply:]_block_invoke + 136
10 libdispatch.dylib              0x39aab8cb _dispatch_call_block_and_release + 10
11 libdispatch.dylib              0x39ab3651 _dispatch_queue_drain + 952
12 libdispatch.dylib              0x39aae09d _dispatch_queue_invoke + 84
13 libdispatch.dylib              0x39ab4ba1 _dispatch_root_queue_drain + 320
14 libdispatch.dylib              0x39ab5cd7 _dispatch_worker_thread3 + 94
15 libsystem_pthread.dylib        0x39c0ce31 _pthread_wqthread + 668

We are seeing the original stack for a crash. Any signs of a solution on this from Apple ?
hread: Unknown Name (Crashed)
0	  libsystem_kernel.dylib             	0x2ff19dfc __pthread_kill + 8
1	  libsystem_c.dylib                  	0x2feb9909 abort + 74
2	  libsystem_malloc.dylib             	0x2ff4a3af szone_error + 332
3	  libsystem_malloc.dylib             	0x2ff4a637 free_small_botch + 64
4	  CFNetwork                          	0x217f3c35 _ZN11HTTPMessage20ensureParserFinishedEv + 70
5	  CFNetwork                          	0x217f3bc9 _ZN11HTTPMessage19copyAllHeaderFieldsEPPK9__CFArray + 10
6	  CFNetwork                          	0x2181d6b5 -[NSHTTPURLResponse allHeaderFields] + 42
7	  CFNetwork                          	0x21867429 -[__NSURLBackgroundSession setCookiesFromResponse:forOriginalRequest:] + 210
8	  CFNetwork                          	0x2186ac85 __81-[__NSURLBackgroundSession backgroundTask:didCompleteWithError:timingData:reply:]_block_invoke + 134
9	  libdispatch.dylib                  	0x2fe337bb _dispatch_call_block_and_release + 8
10	 libdispatch.dylib                  	0x2fe3b5b1 _dispatch_queue_drain + 950
11	 libdispatch.dylib                  	0x2fe35f85 _dispatch_queue_invoke + 82
12	 libdispatch.dylib                  	0x2fe3cb9b _dispatch_root_queue_drain + 336
13	 libdispatch.dylib                  	0x2fe3dcd7 _dispatch_worker_thread3 + 92
14	 libsystem_pthread.dylib            	0x2ff94e31 _pthread_wqthread + 666
15	 libsystem_pthread.dylib            	0x2ff94b84 start_wqthread + 6

I was getting a consistent crash with "Malloc Enabled". But, when i commented out the AFNetworkActivityLogger, the crashed stopped completely.
//    [[AFNetworkActivityLogger sharedLogger] startLogging];
//    [[AFNetworkActivityLogger sharedLogger] setLevel:AFLoggerLevelInfo];
Can someone please verify the same ? Thanks.

@achaudhari1 Yep same for us. I think the activity logger digs into the HTTP headers frequently and therefore triggers the underlying bug more often.

@dbachrach Awesome thanks.

Is anyone seeing this issue who is not using the AFNetworkActivityLogger extension?
I'm not using AFNetworkActivityLogger in our project and we're still seeing way too many of these crashes on a daily basis in production :(

We are not using AFNetworkActivityLogger extension and we are seeing many crashes too :-(

@shawnallen and I had a twitter discussion about this over here for those interested: https://twitter.com/shawnallen/status/560211813145378816
He filed a rdar and apparently a recommended workaround is to call "allHeaderFields" on the same thread which the request is manufactured. I'm doing this now:
dispatch_async(_myUploadTaskQueue, ^{

    uploadTask = [_myAFHTTPUploadClient uploadTaskWithRequest:urlRequest
                                                     fromFile:filePathForUpload
                                                     progress:nil
                                            completionHandler:^(NSURLResponse *response, id responseObject, NSError *error) {

                                                dispatch_async(_myUploadTaskQueue, ^{

                                                    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse*)response;
                                                    if ([httpResponse respondsToSelector:@selector(allHeaderFields)]) {
                                                        NSDictionary *dictionary = [httpResponse allHeaderFields];
                                                    }

                                                });
                                            }];
});

I've just made this change. I'm going to push a new internal build to our team for testing and I'll report back in the next couple days if this crash seems to stop from our testing.
Thanks for your help, @shawnallen!

I should add that it isn't just -allHeaderFields; the message parser which is internally referenced by an equivalent to CFHTTPMessage, is set up when you create the response. When you start accessing values in the response, such as -allHTTPHeaders, the parser is finalized and then freed.
The problem, discovered thanks to DTS' help, is that the finalization code is not thread safe.
So, calling -allHeaderFields on the creating thread ensures that the parser is freed on the thread, before the response "escapes" (DTS' tongue-in-cheek metaphor) to any other threads.

On Jan 27, 2015, at 5:17 PM, Don Holly<EMAIL_ADDRESS>wrote:
@shawnallen and I had a twitter discussion about this over here for those interested: https://twitter.com/shawnallen/status/560211813145378816
He filed a rdar and apparently a recommended workaround is to call "allHeaderFields" on the same thread which the request is manufactured. I'm doing this now:
dispatch_async(_myUploadTaskQueue, ^{
uploadTask = [_myAFHTTPUploadClient uploadTaskWithRequest:urlRequest
                                                 fromFile:filePathForUpload
                                                 progress:nil
                                        completionHandler:^(NSURLResponse *response, id responseObject, NSError *error) {

                                            dispatch_async(_myUploadTaskQueue, ^{

                                                NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse*)response;
                                                if ([httpResponse respondsToSelector:@selector(allHeaderFields)]) {
                                                    NSDictionary *dictionary = [httpResponse allHeaderFields];
                                                }

                                            });
                                        }];

});
I've just made this change. I'm going to push a new internal build to our team for testing and I'll report back in the next couple days if this crash seems to stop from our testing.
Thanks for your help, @shawnallen!
—
Reply to this email directly or view it on GitHub.

@donholly @shawnallen Thanks so much for sharing these details! Clears up a mystery.

@dbachrach have you seen this happen in the non-NSURLSession based APIs?
I've only ever seen it happen in Background NSURLSession configurations myself.
I also took your fix and applied it on the NSURLSession based APIs. Thanks!

I will report back after we've banged on it a bit more over here to see if it resolves the issue.

I am trying to remember back whether it was NSURLSession (we switched awhile back), but it definitely was not background configurations.

@donholly I've been seeing this with the non-session API when using the JSON deserializer.

I am unfortunately able to reproduce this still :(
@shawnallen - Does this fix seem appropriate?
https://github.com/donholly/AFNetworking/commit/d1b7ac5a0f38e83d29c8c0b9ffc324e2475a1f65

@donholly Your fix to run the code on a custom dispatch queue doesn't guarantee at all that the blocks will be executed in the same thread every time.

@oscahie - yep! Noticed that, which is why I referenced the new fix:
https://github.com/donholly/AFNetworking/commit/d1b7ac5a0f38e83d29c8c0b9ffc324e2475a1f65

Not necessarily.
After that response is built, you need to make sure that the call/determination you are doing is invoked.  But in your scenario, IIRC, this is opaque to you and comes from the NSURLSession machinery and it may have originated on a different thread.
In my situation, I am not using NSURLSession and am personally responsible for actually making the response instance.
I do not have an answer (lazy answer, I haven't dug into it) for how you'd be able to replace that response with one you originated.

On Jan 30, 2015, at 11:58 AM, Don Holly<EMAIL_ADDRESS>wrote:
I am unfortunately able to reproduce this still :(
@shawnallen - Does this fix seem appropriate?
donholly@d1b7ac5
—
Reply to this email directly or view it on GitHub.

@shawnallen - got it. Unfortunately I don't think I'll have the luxury of building out my own response at the CFNetwork layer since I need to use the background capabilities provided by NSURLSession. I assume this isn't possible without using those higher-level APIs?

I was able to catch this in the debugger finally (NSURLSession background uploads). The crash appears to happen just after the app calls
- (void)application:(UIApplication *)application handleEventsForBackgroundURLSession:(NSString *)identifier completionHandler:(void (^)())completionHandler
Here's the stack trace showing that the XPC Connection from nsurlsessiond calls into the app which ends up triggering the crash:

Quite obscure... Not really sure what I can do about this. Likely going to file another rdar with this info.
Any thoughts appreciated!

It doesn't sound like you will -- unfortunately.

On Jan 30, 2015, at 12:24 PM, Don Holly<EMAIL_ADDRESS>wrote:
@shawnallen - got it. Unfortunately I don't think I'll have the luxury of building out my own response at the CFNetwork layer since I need to use the background capabilities provided by NSURLSession. I assume this isn't possible without using those higher-level APIs?
—
Reply to this email directly or view it on GitHub.

That is unfortunate. Once Apple fixed the thread-safety problem, this should ameliorate all of these instances.

On Jan 30, 2015, at 6:27 PM, Don Holly<EMAIL_ADDRESS>wrote:
I was able to catch this in the debugger finally (NSURLSession background uploads). The crash appears to happen just after the app calls

(void)application:(UIApplication *)application handleEventsForBackgroundURLSession:(NSString *)identifier completionHandler:(void (^)())completionHandler

Here's the stack trace showing that the XPC Connection from nsurlsessiond calls into the app which ends up triggering the crash:
Quite obscure... Not really sure what I can do about this. Likely going to file another rdar with this info.
Any thoughts appreciated!
—
Reply to this email directly or view it on GitHub.

I have been struggling with this error, it is unclear to me if there is any reliable work around.
I am doing multiple uploads and getting the double free malloc  randomly on URLSession: task:didCompleteWithError: delegate.
I have tried
dedicated queue
putting synchronize in the method
I have tried reading the NSString *responseDescription = task.response.description  and scanning it for the code,
using a try catch
Nothing seems to help. I can sometimes do 3000 uploads without a crash, but then I can get 3 crashes in a 100.
I am using NSURLSession in the background without AFNetworking

Just a heads up - it looks like this may have been fixed in iOS 8.2.
Still keeping an eye on it, but Crashlytics hasn't reported any 8.2 crashes in ensureParserFinished() for us yet.
Fingers crossed.

That would be great!  My Radar on Foundation is still open, and I'm still receiving crashes from 8.2 users which don't incorporate the workaround.  Yet, I'm also not using background NSURLSessions -- fingers crossed for you too!

On Mar 14, 2015, at 4:04 PM, Don Holly<EMAIL_ADDRESS>wrote:
Just a heads up - it looks like this may have been fixed in iOS 8.2.
Still keeping an eye on it, but Crashlytics hasn't reported any 8.2 crashes in ensureParserFinished() for us yet.
Fingers crossed.
—
Reply to this email directly or view it on GitHub.

Thanks to everyone who has taken the time to investigate and share their findings in this thread.
Unfortunately, because this appears to be a bug in the underlying Foundation URL Loading System, there is no real way for AFNetworking to work around this issue. Unless anyone objects, I'm going to close this thread, as there is no actionable resolution on our part.
If anyone has any updates, please feel free to continue the discussion here. If anyone happens to find a workaround that AFNetworking can adopt, we'd be glad to take a look—please open a PR if you do.

This issue was the top crasher in one of our apps (Thumbtack.com). The vast majority of crashes were in iOS 8, but also some in 9.
We also found that using NewRelic is likely to trigger the crash more frequently than without.
Thankfully, I have a workaround for you all.
You need to ensure that the NSMutableURLRequest internal HTTP parser is finalized before any other thread may inspect the request. You can do this simply by calling -[NSMutableURLRequest HTTPBody].
In our app, we wrap NSMutableURLRequest in our own class, so we call -[NSMutableURLRequest HTTPBody] in the initializer, as you can see here:
@implementation TTJSONObjectRequest

- (instancetype)initWithMethod:(NSString *)method path:(NSString *)path parameters:(NSDictionary *)parameters {
    self = [super initWithMethod:method path:path parameters:parameters];
    if (self) {
        self.requestSerializer = [AFJSONRequestSerializer serializer];
        NSError *error = nil;
        self.request = [self.requestSerializer requestWithMethod:method URLString:self.url.absoluteString parameters:parameters error:nil];

        if (!self.request) {
            TTLogError(@"Failed to create request: %@", error);
            return nil;
        }

        [self.request setValue:JsonApiMimeType forHTTPHeaderField:@"Content-Type"];
        [self setUserAgent:self.request];

        // iOS's internal HTTP parser finalization code is not thread safe, and can
        // result in a double free crash.
        // This workaround finalizes the parser before we hand-off the request to
        // NSURLSession, ensuring that other threads inspecting the request do not
        // trigger a race to finalize the parser.
        [self.request HTTPBody];
    }
    return self;
}

@end

And here's a test case to reproduce the crash (obviously you'll need to adapt it to your own code):
- (void)testCrash {
    for (;;) {
        TTObjectRequest *objectRequest = [[TTObjectRequest alloc] initWithMethod:@"GET" path:@"/some/path" parameters:@{} files:@[]];
        // Uncomment to fix crash.
        // [objectRequest.request HTTPBody];

        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [objectRequest.request HTTPBody];
        });

        [objectRequest.request HTTPBody];
    }
}

Just FYI, I've been revisiting this issue, since we have recently added a lot heavier usage of NSURLSession APIs in our codebase, and (not?) surprisingly the crash within NSURLRequest is still reproducible as of iOS 10.1.1 using @ileitch's test case, so I have had to code defensively using the suggested workaround. Unfortunately I have not been able to repro the crash in NSHTTPURLResponse using the same technique on any iOS version, but I have to assume the issue still exists as of iOS 10 too.

I've seen similar crash when not using AFNetworking. It happened in call to -[NSURLResponse allHeaderFields].

I face the same issue with you.
1CoreFoundation0x180dd183cCFAllocatorDeallocate +48
2CFNetwork0x18152aebcHTTPMessage::ensureParserFinished() +112
3CFNetwork0x18152b0a0HTTPMessage::copyAllHeaderFields() +20
4CFNetwork0x18144e074-[NSURLRequest(NSHTTPURLRequest) allHTTPHeaderFields] +36
5BitAutoPlusStore0x101bb08f8-[SBLogURLProtocol stopLoading] +508 (SBLogURLProtocol.m:139)
6CFNetwork0x18147be28CFURLProtocol_NS::forgetProtocolClient0() +88
7CFNetwork0x18147bdb8___ZN16CFURLProtocol_NS20forgetProtocolClientEv_block_invoke +24

How do you mend it? Thank you.

I've seen this crash while using WebViewProxy. Probably using custom NSURLProtocol somehow causes this crash.

My condition is the same with you.I face the crash in using custom NSURLProtocol.
1CoreFoundation0x180dd183cCFAllocatorDeallocate +48
2CFNetwork0x18152aebcHTTPMessage::ensureParserFinished() +112
3CFNetwork0x18152b0a0HTTPMessage::copyAllHeaderFields() +20
4CFNetwork0x18144e074-[NSURLRequest(NSHTTPURLRequest) allHTTPHeaderFields] +36
5BitAutoPlusStore0x101bb08f8-[SBLogURLProtocol stopLoading] +508 (SBLogURLProtocol.m:139)
6CFNetwork0x18147be28CFURLProtocol_NS::forgetProtocolClient0() +88

Crash frequency is high, but not appear by test, just appear after production.This is very terrible, which make me worry.


Kth index removal from a given string

Have you read the Contributing Guidelines on Pull Requests?
Yes
Description
Fixes #5791
It is used  to remove the nth index from a string and print the remaining string.
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
This pr solves issue #5791

@bhav09 @HarshCasper kindly have a look.


Adding docker building and running of elastichoney

Not sure if this is something you would want, but it's all packaged nicely if you would like to make it available. If you want to up your version of go, just change the FROM line in the Dockerfile to something from go's docker repository

Yeah, sure, why not. Docker is cool. Elastichoney is cool. They should work together.
Thanks for this!


Running pivy-importer fails on Mac

I attempted to run pivy-importer on my MacBook Pro 2015, Siera v. 10.12.3, Java 1.8.0_112 and ended up with this error
MUSRS186002-942:tmp rs186002$ java -jar pivy-importer-0.4.1-all.jar --repo ~/tmp/pypi virtualenv:15.0.1 pip:7.1.2 --replace alabaster:0.7=alabaster:0.7.1,pytz:0a=pytz:2016.4,Babel:0.8=Babel:1.0,sphinx_rtd_theme:0.1=sphinx_rtd_theme:0.1.1
alabaster:0.7=alabaster:0.7.1
pytz:0a=pytz:2016.4
Babel:0.8=Babel:1.0
sphinx_rtd_theme:0.1=sphinx_rtd_theme:0.1.1
12:53:02.579 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in virtualenv:15.0.1
12:53:04.256 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in pip:7.1.2
12:53:04.777 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in pytest:3.0.6
12:53:05.196 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in virtualenv:1.10
12:53:05.872 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in scripttest:1.3
12:53:05.936 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in mock:2.0.0
12:53:06.671 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in py:1.4.29
12:53:06.825 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in setuptools:34.1.1
12:53:06.940 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in argparse:1.4.0
12:53:07.010 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in colorama:0.3.7
12:53:07.076 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in pbr:0.11.0
12:53:07.161 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in six:1.9.0
12:53:07.228 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in funcsigs:1.0.0
12:53:07.354 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in Sphinx:1.5.2
12:53:09.066 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in Jinja2:2.7
12:53:09.386 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in Pygments:2.0
12:53:10.152 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in Sphinx:1.3
12:53:11.369 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in unittest2:1.1.0
12:53:11.506 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in pip:9.0.1
12:53:11.748 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in ordereddict:1.1
12:53:11.811 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in six:1.5.0
12:53:11.883 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in Jinja2:2.3
12:53:12.307 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in docutils:0.11
12:53:12.514 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in snowballstemmer:1.1.0
12:53:12.637 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in Babel:1.3
12:53:13.104 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in alabaster:0.7.1
12:53:13.169 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in imagesize:0.7.1
12:53:13.232 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in requests:2.4.0
12:53:13.403 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in colorama:0.3.5
12:53:13.473 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in nose:1.3.7
12:53:13.568 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in simplejson:3.10.0
12:53:13.638 INFO  c.l.p.i.deps.DependencyDownloader - Pulling in html5lib:1.0b10
Exception in thread "main" java.lang.RuntimeException: Unable to find version 2.2 for chardet
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:80)
	at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:74)
	at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor(ConstructorSite.java:84)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:247)
	at com.linkedin.python.importer.pypi.ProjectDetails.maybeFixVersion(ProjectDetails.groovy:55)
	at com.linkedin.python.importer.pypi.ProjectDetails$maybeFixVersion.call(Unknown Source)
	at com.linkedin.python.importer.distribution.SourceDistPackage$_parseRequiresText_closure1.doCall(SourceDistPackage.groovy:81)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1019)
	at groovy.lang.Closure.call(Closure.java:426)
	at groovy.lang.Closure.call(Closure.java:442)
	at org.codehaus.groovy.runtime.DefaultGroovyMethods.callClosureForLine(DefaultGroovyMethods.java:5236)
	at org.codehaus.groovy.runtime.StringGroovyMethods.eachLine(StringGroovyMethods.java:615)
	at org.codehaus.groovy.runtime.StringGroovyMethods.eachLine(StringGroovyMethods.java:636)
	at org.codehaus.groovy.runtime.StringGroovyMethods.eachLine(StringGroovyMethods.java:595)
	at org.codehaus.groovy.runtime.dgm$1060.invoke(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
	at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
	at com.linkedin.python.importer.distribution.SourceDistPackage.parseRequiresText(SourceDistPackage.groovy:50)
	at com.linkedin.python.importer.distribution.SourceDistPackage.getDependencies(SourceDistPackage.groovy:41)
	at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
	at org.codehaus.groovy.runtime.metaclass.MethodMetaProperty$GetBeanMethodMetaProperty.getProperty(MethodMetaProperty.java:76)
	at org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.callGroovyObjectGetProperty(GetEffectivePogoPropertySite.java:68)
	at com.linkedin.python.importer.deps.DependencyDownloader.downloadDependency(DependencyDownloader.groovy:72)
	at com.linkedin.python.importer.deps.DependencyDownloader$downloadDependency.callCurrent(Unknown Source)
	at com.linkedin.python.importer.deps.DependencyDownloader.download(DependencyDownloader.groovy:50)
	at com.linkedin.python.importer.ImporterCLI.main(ImporterCLI.java:73)

Ok, figured it out. Had to extend command line by adding these 2 to "--replace" flag:
chardet:2.2=chardet:2.3.0,setuptools:0.6a2=setuptools:34.1.1
But where that list is coming from? Is it hardcoded or is it red from somewhere? The former would be really unfortunate

And why this is not pulling PyYAML lib? In fact - who and how determines which libraries to pull? I see a rather short list of stuff which is for most parts is useless to me. What am I missing? Here's my command:
java -jar pivy-importer-0.4.1-all.jar --repo ~/tmp/ virtualenv:15.0.1 pip:7.1.2 --replace alabaster:0.7=alabaster:0.7.1,pytz:0a=pytz:2016.4,Babel:0.8=Babel:1.0,sphinx_rtd_theme:0.1=sphinx_rtd_theme:0.1.1,chardet:2.2=chardet:2.3.0,setuptools:0.6a2=setuptools:34.1.1

@bostone The pyvi-importer is just an example to get people started quickly and provides just the packages that were needed for our CI runs triggered by commits here.
Internally, at LinkedIn, we have a Python product that uploads external packages into our artifactory + Ivy files created by analyzing the dependencies. Thus, when our developers need a new package, we can easily get it (and its transitive dependencies) into our artifactory (if they are not already there).
Being a Python program, this tool is much better at analyzing the needs of Python packages than pyvi-importer and it has various options. This is a much more sophisticated program and highly customized for internal LinkedIn use, so we did not open-source it. We expect that enterprise users will be able to build something similar for their own needs. I had been contacted by some who used pyvi-importer as a guidance to build a very simple Python program that uploads the dependencies to their custom artifact repository.
If the community feels the need for a tool like this, we can look into producing a simpler open-source version of it, but the timeline for that would depend on our priorities.

For project that advertise itself as dependency resolution solution I found it strange that I have to jump over multiple hoops just to import a single library. It's not a critique but rather an observation. I really think this needs to be described in more details right away so not to build false expectation. In my personal opinion this project can only really take off if it provides easy way of plugging into official and/or Artifactory-based PyPi repo.
Initially I thought that it was enough to provide some definition in the "repositories" section. Then I red in the documentation that I need to use pivy-importer and now both of these things are not (essentially) true. It's really frustrating. For light-medium Python project it seems to me that I'm better off just writing few gradle tasks that would run some python scripts and that's a pity because I really like the premise of this project

@bostone Some users have successfully used pyvi-importer for their projects. See for example the contribution from our user: https://github.com/linkedin/pygradle/tree/master/examples/iris-classification
We are open to suggestions and are working with the users to improve documentation and resolution of the pain points. We'll definitely look into providing our Python tool in some form to the community. As @sixninetynine suggested, we'll also look into providing something that will allow easier setup of a localized repo on one's development machine.
Thank you again for the comments and input. We value it, particularly because it's hard to notice these deficiencies in our environment.  We use pygradle every day without issues on over thousand products, but we have our internal plugin wrapping it and adding some custom/new features and our repo populated with our tools. It's important to hear from users like you to understand where the issues can arise. Also, our users come from quite different environments with very different needs and each input is important to try and understand the generic solution that would help as many people as possible.
We can work together on these improvements.

Love that I'm getting response from you guys. The initial setup was really easy and impressive until I hit the wall with one simple dependency. I think at this point this is a weakest link. Naturally, I was really disappointed that I cannot easily import from PyPi. How about adding automation that behind the scenes sets local ivy repo and pulls dependencies from PyPi based on what user specifies in the "dependencies" section? How far fetch would that be?
I'll look at the example you pointed to
Thanks again.
Bo

How about adding automation that behind the scenes sets local ivy repo and pulls dependencies from PyPi based on what user specifies in the "dependencies" section? How far fetch would that be?

Not far-fetched at all! Our internal tool runs a process very similar to this :)

@sixninetynine I forked the project and am working on externalizing list of "packagesToInclude" for pivy-importer. Here's question for you. From the hardcoded list which packages are actually required for pygradle build to work. I'm guessing anything related to virtualenv, pip, setuptools, flake8, pytest, wheel. But what about the rest? I much rather keep the default list and append the dependencies dynamically. Here's what you guys have by default:
def packagesToInclude = ['virtualenv:15.0.1', 'pip:7.1.2', 'setuptools:19.1.1', 'setuptools-git:1.1',
                             'flake8:2.4.0', 'flake8:2.5.4', 'pytest:2.9.1', 'pytest-cov:2.2.1', 'pytest-xdist:1.14',
                             'wheel:0.26.0', 'pbr:1.8.0', 'Sphinx:1.4.1', 'six:1.10.0', 'pex:1.1.4',
                             'requests:2.10.0', 'Flask:0.11.1', 'docutils:0.12', 'appdirs:1.4.0',
                             'packaging:16.8'].join(" ")

I fixed pyvi-importer behavior in #138.
Also added --latest option and --pre option to allow installation of the latest (highest) supported version of dependency and to allow pre-releases (alpha, beta, rc) which are disallowed by default in the new version.
Can you try using the latest version @bostone (0.6.1 was just released).

Regarding the question what's required -- only the the dependencies we need for the build, and Flask + requests for our examples (we'll consider dropping these two). Otherwise, we bring the dependencies that particular Python project needs and specifies in its build.gradle file. The list is now quite minimal in 0.6.x.


Language tags for Klingon are wrong.

@rhurey : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Make sure CI runs dependent SDKs tests after a dependency change

Currently we manually update if_changed.sh to make sure the tests for dependent projects are run for PRs. Ideally, we should update the scripts so, that the dependency are calculated based on the SDK podspecs.

It's not ideal but the cron job is likely enough. Running every product's CI for a change in something like Core would be expensive and slow, so we likely won't make changes here and depend on the cron job to catch things within 24 hours.


Known URI paths are no longer printed after upgrading from 0.7.2 to 0.8.x

At version 0.7.2 I get the following log message when I try to hit an incorrect URL:
No service at method address /services/myapp/tilesservice/pin method name  object name null
SERVICES[/services/myapp/tilesservice/TAKETILE, qbitTilesService, /services/myapp/tilesservice, /services/myapp/tilesservice/taketile/, /services/myapp/tilesservice/taketile, /services/myapp/tilesservice/ping, /services/myapp/tilesservice/takeTile, /services/myapp/tilesservice/PING]

2015-06-06 18:46:54.588 ERROR 2261 --- [/services/myapp] i.a.qbit.service.impl.ServiceBundleImpl  : known URI path /services/myapp/tilesservice/TAKETILE
2015-06-06 18:46:54.588 ERROR 2261 --- [/services/myapp] i.a.qbit.service.impl.ServiceBundleImpl  : known URI path qbitTilesService
2015-06-06 18:46:54.588 ERROR 2261 --- [/services/myapp] i.a.qbit.service.impl.ServiceBundleImpl  : known URI path /services/myapp/tilesservice
2015-06-06 18:46:54.588 ERROR 2261 --- [/services/myapp] i.a.qbit.service.impl.ServiceBundleImpl  : known URI path /services/myapp/tilesservice/taketile/
2015-06-06 18:46:54.588 ERROR 2261 --- [/services/myapp] i.a.qbit.service.impl.ServiceBundleImpl  : known URI path /services/myapp/tilesservice/taketile
2015-06-06 18:46:54.588 ERROR 2261 --- [/services/myapp] i.a.qbit.service.impl.ServiceBundleImpl  : known URI path /services/myapp/tilesservice/ping
2015-06-06 18:46:54.588 ERROR 2261 --- [/services/myapp] i.a.qbit.service.impl.ServiceBundleImpl  : known URI path /services/myapp/tilesservice/takeTile
2015-06-06 18:46:54.588 ERROR 2261 --- [/services/myapp] i.a.qbit.service.impl.ServiceBundleImpl  : known URI path /services/myapp/tilesservice/PING

And the JSON response I get is:
{"address":"/services/myapp/tilesservice/pin","detailMessage":"there is no object at this address: /services/myapp/tilesservice/pin\n method name=\n objectName=null Service Address not found","cause":"io.advantageous.qbit.service.ServiceMethodNotFoundException: there is no object at this address: /services/myapp/tilesservice/pin
 method name=
 objectName=null Service Address not found"}

This is very helpful for debugging, because you can immediately see what paths are registered.
In the 0.8.7 version (it started from 0.8.0 though) I only see this when I hit a wrong URL:
["Unable to find handler"]

But everything works fine if I fix the URL. However, the previous messages were much more helpful. When I saw that I didn't know what's going on.
I checked in the code and the most recent version still contains the logging of known paths, but the breakpoint there isn't hit when the URL is incorrect.
I based my service on the qbit and spring boot integration tutorial. I didn't do any code changes after upgrading from 0.7.2 to 0.8.0.
Is there a way to restore that behaviour in 0.8.x?

Code is still there.
        if (methodCallConsumer == null) {
            logger.error("No service at method address " + methodCall.address()
                    + " method name " + methodCall.name() + " object name " + methodCall.objectName() + "\n SERVICES" + serviceMapping.keySet() + "\n");

            Set<String> uris = serviceMapping.keySet();

            //noinspection CodeBlock2Expr
            uris.forEach((String it) -> {
                logger.error("known URI path " + it);
            });

            throw new ServiceMethodNotFoundException("there is no object at this address: " + methodCall.address()
                    + "\n method name=" + methodCall.name() + "\n objectName=" + methodCall.objectName(), methodCall.address());
        }

I wonder if you have disabled logging somehow?

Yes, I wrote that the code is still there, but it isn't executed.

aha

It is only for REST calls not WebSocket.
I was testing with WebSocket.
I ran into it with REST.
Ok... so I moved the responsibility of the REST dispatching from the service bundle to StandardRequestTransformer.
In the transform method....
if (metaData == null) {
            errorsList.add("Unable to find handler");
            return null;
        }

It says... hey.. I can't find nothing, but it does not then go into detail like we did before.
I agree that the detail was nice.
I will add logging to StandardRequestTransformer such that if info is true, then it will go through every method, and say.. here are the patch I know about.
Not sure if this should be info or debug. :)

Info if startup-based.  debug for runtime cases.  My .02.
On Mon, Jun 8, 2015 at 11:47 PM, Richard Hightower<EMAIL_ADDRESS>
wrote:

It is only for REST calls not WebSocket.
I was testing with WebSocket.
I ran into it with REST.
Ok... so I moved the responsibility of the REST dispatching from the
service bundle to StandardRequestTransformer.
In the transform method....
if (metaData == null) {
errorsList.add("Unable to find handler");
return null;
}
It says... hey.. I can't find nothing, but it does not then go into detail
like we did before.
I agree that the detail was nice.
I will add logging to StandardRequestTransformer such that if info is
true, then it will go through every method, and say.. here are the patch I
know about.
Not sure if this should be info or debug. :)
—
Reply to this email directly or view it on GitHub
https://github.com/advantageous/qbit/issues/253#issuecomment-110224715.

--
Thanks,
Chris

fair enough.
On Mon, Jun 8, 2015 at 10:03 PM, revelfire<EMAIL_ADDRESS>wrote:

Info if startup-based. debug for runtime cases. My .02.
On Mon, Jun 8, 2015 at 11:47 PM, Richard Hightower <
<EMAIL_ADDRESS>
wrote:

It is only for REST calls not WebSocket.
I was testing with WebSocket.
I ran into it with REST.
Ok... so I moved the responsibility of the REST dispatching from the
service bundle to StandardRequestTransformer.
In the transform method....
if (metaData == null) {
errorsList.add("Unable to find handler");
return null;
}
It says... hey.. I can't find nothing, but it does not then go into
detail
like we did before.
I agree that the detail was nice.
I will add logging to StandardRequestTransformer such that if info is
true, then it will go through every method, and say.. here are the patch
I
know about.
Not sure if this should be info or debug. :)
—
Reply to this email directly or view it on GitHub
<https://github.com/advantageous/qbit/issues/253#issuecomment-110224715
.

--
Thanks,
Chris
—
Reply to this email directly or view it on GitHub
https://github.com/advantageous/qbit/issues/253#issuecomment-110226775.

--
Rick Hightower
(415) 968-9037
Profile http://www.google.com/profiles/RichardHightower

ok.. just added. let's see how it turns out.


I can't run a program

Hi, I've got a problem by starting lsdreader.
$ lsdreader -v
Traceback (most recent call last):
  File "/usr/local/bin/lsdreader", line 7, in <module>
    from lingvoreader.lsdreader import main
  File "/usr/local/lib/python3.6/site-packages/lingvoreader/lsdreader.py", line 53
    except ValueError, e:
                     ^
SyntaxError: invalid syntax

python3.6

And I know now why.
Thanks for great program :)


Feedback for “Goodies”

From: https://orm.drizzle.team/docs/goodies#get-table-information
import { getTableConfig, sqliteTable } from 'drizzle-orm/sqlite-core';

export const table = sqliteTable(...);

const {
  columns,
  indexes,
  foreignKeys,
  checks,
  primaryKeys,
  name,
  schema,
} = await getTableConfig(table);

Printing the object ends with: schema: undefined
TypeScript warns: Property 'schema' does not exist on type '{ columns: SQLiteColumn<any, object>[]; indexes: Index[]; foreignKeys: ForeignKey[]; checks: Check[]; primaryKeys: PrimaryKey[]; uniqueConstraints: UniqueConstraint[]; name: string; }'.ts(2339)
getTableConfig is failing to out put schema or the Docs are outdated.

I think that SQLite doesn't support schemas like postgres. That's why you don't see it there. But it's a docs issue in any case.


Google maps needs API key (Interactive maps section)

Section 7 now needs google API key before map will load
m_leafmap.set_api_key('your_google_api_key')
m = leafmap.Map(center=[-35.287243572265822,<PHONE_NUMBER>81177202], zoom=19)
m.add_basemap("SATELLITE")

I recently removed Google basemaps from leafmap to avoid vialoting Google Maps' terms of service. I need to update the notebook examples to replace Google Earth basemaps with other alternatives.
https://github.com/opengeos/leafmap/pull/522


[SUPPORT] org.apache.hudi.common.util.FSUtils logging too verbose

for one simple spark-submit (COW data source) org.apache.hudi.common.util.FSUtils is logged on 21 lines, each line being 2700+ bytes
example of one line
2020-08-03 14:19:52,892 [main] INFO  org.apache.hudi.common.util.FSUtils - Hadoop Configuration: fs.defaultFS: [file:///], Config:[Configuration: core-default.xml, core-site.xml, mapred-default.xml, mapred-site.xml, yarn-default.xml, yarn-site.xml, hdfs-default.xml, hdfs-site.xml, spark_hadoop_conf.xml, file:/home/ec2-user/spark_home/conf/hive-site.xml], FileSystem: [S3AFileSystem{uri=s3a://mybucketo, workingDir=s3a://mybucketo/user/ec2-user, inputPolicy=normal, partSize=104857600, enableMultiObjectsDelete=true, maxKeys=5000, readAhead=65536, blockSize=33554432, multiPartThreshold=2147483647, serverSideEncryptionAlgorithm='AES256', blockFactory=org.apache.hadoop.fs.s3a.S3ADataBlocks$DiskBlockFactory@c247b02, boundedExecutor=BlockingThreadPoolExecutorService{SemaphoredDelegatingExecutor{permitCount=2405, available=2405, waiting=0}, activeCount=0}, unboundedExecutor=java.util.concurrent.ThreadPoolExecutor@78f1d29[Running, pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 1], statistics {11286 bytes read, 4304 bytes written, 160 read ops, 0 large read ops, 19 write ops}, metrics {{Context=S3AFileSystem} {FileSystemId=8624b3cf-eff7-4713-8405-95fc9bd35d90-mybucketo} {fsURI=s3a://mybucketo/private/sparkevents} {files_created=6} {files_copied=0} {files_copied_bytes=0} {files_deleted=1} {fake_directories_deleted=0} {directories_created=1} {directories_deleted=0} {ignored_errors=5} {op_copy_from_local_file=0} {op_exists=44} {op_get_file_status=138} {op_glob_status=0} {op_is_directory=36} {op_is_file=0} {op_list_files=1} {op_list_located_status=0} {op_list_status=21} {op_mkdirs=0} {op_rename=0} {object_copy_requests=0} {object_delete_requests=6} {object_list_requests=124} {object_continue_list_requests=0} {object_metadata_requests=240} {object_multipart_aborted=0} {object_put_bytes=4304} {object_put_requests=6} {object_put_requests_completed=6} {stream_write_failures=0} {stream_write_block_uploads=0} {stream_write_block_uploads_committed=0} {stream_write_block_uploads_aborted=0} {stream_write_total_time=0} {stream_write_total_data=4304} {object_put_requests_active=0} {object_put_bytes_pending=0} {stream_write_block_uploads_active=0} {stream_write_block_uploads_pending=5} {stream_write_block_uploads_data_pending=0} {stream_read_fully_operations=0} {stream_opened=22} {stream_bytes_skipped_on_seek=0} {stream_closed=22} {stream_bytes_backwards_on_seek=0} {stream_bytes_read=11286} {stream_read_operations_incomplete=22} {stream_bytes_discarded_in_abort=0} {stream_close_operations=22} {stream_read_operations=29} {stream_aborted=0} {stream_forward_seek_operations=0} {stream_backward_seek_operations=0} {stream_seek_operations=0} {stream_bytes_read_in_close=0} {stream_read_exceptions=0} }}]
some ideas:

"Hadoop Configuration" block be removed or split to separate log class
make it DEBUG level?
only print metrics that are non-0 ?

Added https://issues.apache.org/jira/browse/HUDI-1148


Request to support sentence-t3-base and all-mpnet-base-v2

Hi,
We're planning on productionizing fastembed, and would like to put in a request for two models:
sentence-transformers/sentence-t5-base and sentence-transformers/all-mpnet-base-v2

Will have the sentence-transformers/all-mpnet-base-v2 out tomorrow this time. Might take a bit longer on T5 Base. Does that unblock you?

@Kaydeeb0y Sure. Thanks.


Analysis of error exposure and handling

Is your feature request related to a problem? Please describe.
Capture various scenarios where errors need to be properly handled and document the expected behavior
Describe the solution you'd like
NA
Describe alternatives you've considered
NA
Additional context
Doc

Existing at_client methods and the exceptions handled/thrown in each method was analysed
proposed exception hierarchy is documented in https://github.com/atsign-foundation/at_client_sdk/issues/468


Meshery CssBaseline import e2e error case

Current Behavior

https://github.com/meshery/meshery/blob/e0a3a0c26362c5351697d8bf049eb9f3ef26d737/provider-ui/pages/_app.js#L5
Desired Behavior
should remove it from the source code?

Implementation

Acceptance Tests

Mockups

Contributor Guides and Handbook

🛠 Meshery Build & Release Strategy
📚 Instructions for contributing to documentation

Meshery documentation site and source

🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@leecalcote should we remove the import statement and its TODO?

@dipankardas011, if you can confirm that the TODO is complete, yes.

@dipankardas011, if you can confirm that the TODO is complete, yes.

Before

After

as its already commented ig it's not needed

not sure about this one

Is there a use case for CssBaseline, or rather a benefit to using this?
From Material UI, the reason for CssBaseline is that it is a component helps to kickstart an elegant, consistent, and simple baseline to build upon.
Was it beneficial to use this in the beginning?

bump
I'm currently working on this PR for provider-ui which may or may not be using CSSBaseline
https://github.com/meshery/meshery/pull/6911


Issue for triggering new releases

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/17044
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.4.0 -m "<description of version>" fcc05fa3ae2edfe384d3fc189a61c016bed4ff77
git push origin v0.4.0

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/18169
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.4.1 -m "<description of version>" 6fed9cb5b1f92a03ed83303997abbf16c5854d4d
git push origin v0.4.1

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/19475
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.4.2 -m "<description of version>" 250c0550168fdf33957e776ebb0b44de04b6fa3c
git push origin v0.4.2

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/20426
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.4.3 -m "<description of version>" 3b1b35db56da5c764dd5248259d14bc8bd3db790
git push origin v0.4.3

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/21399
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.0 -m "<description of version>" 3e989d5e7d677d73b4c06d087f9a10c6fadcd511
git push origin v0.5.0

@JuliaRegistrator register

Error while trying to register: "Tag with name v0.5.0 already exists and points to a different commit"

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/21672
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.1 -m "<description of version>" 8c3e948d6db3c39b47f201fdd5601c7b63a7a08f
git push origin v0.5.1

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/22912
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.2 -m "<description of version>" 7314ca514c625bfbabff117655667ee74f502eba
git push origin v0.5.2

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/23306
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.3 -m "<description of version>" 3785f0d88fa09e860bda579613c886abcbe90c01
git push origin v0.5.3

Also, note the warning: Version 0.5.3 skips over 0.5.2
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/22912
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.2 -m "<description of version>" 3f67fbca8c2b5ebe473d142374c946a68a4cbe1f
git push origin v0.5.2

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/22912
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.2 -m "<description of version>" c03b5f8da241dbc20b1c31c00b58b42a9f232259
git push origin v0.5.2

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/22912
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.2 -m "<description of version>" c03b5f8da241dbc20b1c31c00b58b42a9f232259
git push origin v0.5.2

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/22912
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.2 -m "<description of version>" 348a9f61b6958081f97c238a1b2517b9b758bb89
git push origin v0.5.2

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/24175
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.3 -m "<description of version>" 1fb4532fff530e41188d7f1e6deab3f3fb5d9afe
git push origin v0.5.3

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/24175
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.3 -m "<description of version>" 65eedad5639940f5218b99954d8bee99f4905267
git push origin v0.5.3

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/25151
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.4 -m "<description of version>" ab9c97ecd538aa8d28d2f95c87a4f973883ea954
git push origin v0.5.4

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/25372
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.5.5 -m "<description of version>" 55ca25bfe4cff04a54add6bd2abb5ecd1b89501f
git push origin v0.5.5

@JuliaRegistrator register

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/27335
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.0 -m "<description of version>" fed846c6e5139c0282808802addb2360a4165e0a
git push origin v0.6.0

Registration pull request created: JuliaRegistries/General/27335
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.0 -m "<description of version>" fed846c6e5139c0282808802addb2360a4165e0a
git push origin v0.6.0

@JuliaRegistrator register

@JuliaRegistrator register

Error while trying to register: "Tag with name v0.6.0 already exists and points to a different commit"

Error while trying to register: "Tag with name v0.6.0 already exists and points to a different commit"

@JuliaRegistrator register

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/28680
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.1 -m "<description of version>" e938e5bdc645d1255eb8374ed54066188cef3cd9
git push origin v0.6.1

Registration pull request created: JuliaRegistries/General/28680
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.1 -m "<description of version>" e938e5bdc645d1255eb8374ed54066188cef3cd9
git push origin v0.6.1

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/30393
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.2 -m "<description of version>" c44a972ec57bbf7e235c0066fbafde4ea53bb8cf
git push origin v0.6.2

@JuliaRegistrator register
release notes:

[x] Add support for MLJ's upcoming iteration API (https://github.com/alan-turing-institute/MLJ.jl/issues/139, #116)

Registration pull request created: JuliaRegistries/General/32600
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.3 -m "<description of version>" b2b9f0c7032a5b15ae5838e7c35a56cd99023a96
git push origin v0.6.3

@JuliaRegistrator register
release notes:

[x] Extend compat for MLJBase to ^0.17.7, ^0.18

Registration pull request created: JuliaRegistries/General/33155
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.4 -m "<description of version>" 83f58c993a020b29d4d4b79bbccf617b43563905
git push origin v0.6.4

@JuliaRegistrator register
release notes:

[x] (enhancement) Make plotting for machines bound to TunedModel instances work for more than two hyper-parameters (#41, PR #121)
[x] Extend compatibility for MLJModelInterface to include version 1.0

Registration pull request created: JuliaRegistries/General/34829
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.5 -m "<description of version>" 267a16f27a965116485df0fa5cd53761919784e3
git push origin v0.6.5

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/37714
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.6 -m "<description of version>" a5e4448f8dbe61632539b3cfdd23ae0a2886cb2c
git push origin v0.6.6

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/37848
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.7 -m "<description of version>" da9364b4d6c13c96e2b0c37f8207e87569681e34
git push origin v0.6.7

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/38618
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.8 -m "<description of version>" 17aa6c53f9c1477401af3a1b7afe4bc3df6543df
git push origin v0.6.8

@JuliaRegistrator register branch=master
cc @lhnguyen-vn

Registration pull request created: JuliaRegistries/General/40775
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.9 -m "<description of version>" b1f8d191704143ddf67e4c8cb6428fc74ea45378
git push origin v0.6.9

@JuliaRegistrator register branch=master
release notes:

[x] (enhancement) Allow the use of models of varying type in the Explicit strategy and provide a convenient syntax TundedModel(models=..., ) (#142)

Registration pull request created: JuliaRegistries/General/41664
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.10 -m "<description of version>" d5d7beb96ae04ccfcda60be1dd5a0e36c88f7c75
git push origin v0.6.10

@JuliaRegistrator register branch=master
release notes:

[x] Fix problem with reproducibility when acceleration isa CPUThreads (#126, #145) @lhnguyen-vn

Registration pull request created: JuliaRegistries/General/44622
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.11 -m "<description of version>" a819b50878abd2185da93f12a4a4984df7b1ce41
git push origin v0.6.11

@JuliaRegistrator register branch=master
release notes:

[x] (enhancement) Allow specification of deterministic measures for probabilistic predictors (#148)

Registration pull request created: JuliaRegistries/General/45267
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.12 -m "<description of version>" a47019becb7c9e32e2f2e3ee94d83c078d79667b
git push origin v0.6.12

@JuliaRegistrator register branch=master

Error while trying to register: "Tag with name v0.6.12 already exists and points to a different commit"

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/45394
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.13 -m "<description of version>" afcd71977c4fbdb4ddd8db65b9f89f346bdd4665
git push origin v0.6.13

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/47910
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.14 -m "<description of version>" a9f573253c865d304f60228a6f31b883c0210d73
git push origin v0.6.14

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/51150
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.15 -m "<description of version>" 0b50093563a18b889bfda8ec12d97c2028706aeb
git push origin v0.6.15

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/51361
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.16 -m "<description of version>" 31f0255cf79b61c3608f5b71c418ba6464fffcd6
git push origin v0.6.16

@JuliaRegistrator register branch=master
Release notes:

(breaking) Change default tuning strategy from Grid to RandomSearch() (#147)
(breaking) Remove deprecated learning_curve! method (#151)
(breaking) Adapt to serialization changes in MLJBase 0.20. In particular, this allows serialization of TunedModel(model=...) when model is not pure Julia (#165) @olivierlabayle

Registration pull request created: JuliaRegistries/General/58001
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.7.0 -m "<description of version>" ebf09836b6950721e2c041a39c2c16fe4ebaee1a
git push origin v0.7.0

@JuliaRegistrator register branch=master
Release notes:

(enhancement) Add user to specify class weights  when constructing TunedModel , for passing to measures (#172)
(convenience) Allow user to specify models as an argument instead of keyword, as in TunedModel(model, tuning=...) (#175)
Suppress some unecessary "outer layer" caching of training data (#173)

Registration pull request created: JuliaRegistries/General/60915
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.7.1 -m "<description of version>" d87788a902ebb70b4ce794b2bb14737d3c4c2007
git push origin v0.7.1

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/62485
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.7.2 -m "<description of version>" f9ad59dd8cade573779b165990484a5cbadd3ace
git push origin v0.7.2

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/67532
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.7.3 -m "<description of version>" bfa9723175d419a3b1d746cae11e4b34225e8901
git push origin v0.7.3

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/71790
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.7.4 -m "<description of version>" 094dbe85b74c23bd69525282db4e21a6516131d9
git push origin v0.7.4

@JuliaRegistrator register branch=master
Release notes:

(breaking) Bump MLJBase compatibility to version 1. When using without MLJ, users may need to explicitly import StatisticalMeasures.jl. See also the MLJBase 1.0 migration guide (#194)

Registration pull request created: JuliaRegistries/General/92206
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.0 -m "<description of version>" b436f9748aadd0e77cb505323877e9e233e62d73
git push origin v0.8.0

@JuliaRegistrator register branch=master
Release notes:

(breaking) Bump MLJBase compatibility to version 1. When using without MLJ, users may need to explicitly import StatisticalMeasures.jl. See also the MLJBase 1.0 migration guide (#194)

Registration pull request updated: JuliaRegistries/General/92206
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.0 -m "<description of version>" 7e4ae96aa6eebbf761f92b5772089617ef56077f
git push origin v0.8.0

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/99405
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.1 -m "<description of version>" 60ad34450e6419e5a8491de03c4a0008e8a7144d
git push origin v0.8.1

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/102482
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.2 -m "<description of version>" 39d6cb46787d998aee5b7de315f8941142d231aa
git push origin v0.8.2

@JuliaRegistrator register branch=master
Release notes:

Include full evaluation objects (key = :evaluation) in history entries (#210)

Registration pull request created: JuliaRegistries/General/103060
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.3 -m "<description of version>" 4f1dd7176078572979bba3b4e5c1ddb7af693a24
git push origin v0.8.3

@JuliaRegistrator register branch=master
Release notes:

(enhancement) Implement feature importances that expose the feature importances of the optimal atomic model (#213)

Registration pull request created: JuliaRegistries/General/103528
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.4 -m "<description of version>" 9fe1f52477c09e00c046e77e1533c11def060e49
git push origin v0.8.4

@JuliaRegistrator register branch=master
Release notes:

Write the PerformanceEvaluation objects computed for each model (hyper-parameter set) to the history, or write compact versions of the same (CompactPeformanceEvaluation objects) by providing TunedModel(...) a new option compact_history=true.  The evaluation objects are accessed like this: evaluation = report(mach).history[index].evaluation, where mach is a machine associated with the TunedModel instance. For more on the differences between PerformanceEvaluation and CompactPerformanceEvaluation objects, refer to their document strings. (In MLJTuning 0.5.3 and 0.5.4 an experimental feature already introduced PerformanceEvalution objects to the history, but with no option to write the compact form. In the current release, compact objects are written by default.)

Registration pull request created: JuliaRegistries/General/106297
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.5 -m "<description of version>" bac0ac9bdd4036ba4069b328dab914386a7e9975
git push origin v0.8.5

@JuliaRegistrator register branch=master

(new feature) Add logger option to TunedModel wrapper, for logging internal model evaluations to an ML tracking platform,  such as MLflow via MLJFlow.jl. Default should be nothing for no logging (#193). The logger must support asynchronous messaging if TunedModel(model, ...) is specified with the option acceleration=CPUThreads() or CPUProcesses(). Currently, CPU1() (the default) is supported by MLJFlow.jl's loggers, while ansynchronous support is a work in progress; see https://github.com/JuliaAI/MLJFlow.jl/pull/41 #193.

Registration pull request created: JuliaRegistries/General/107292
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.6 -m "<description of version>" 1af0202b7fc256e03c15a9604696e6092a0b141e
git push origin v0.8.6

Registration pull request updated: JuliaRegistries/General/107292
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.6 -m "<description of version>" 1af0202b7fc256e03c15a9604696e6092a0b141e
git push origin v0.8.6

Registration pull request updated: JuliaRegistries/General/107292
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.6 -m "<description of version>" 1af0202b7fc256e03c15a9604696e6092a0b141e
git push origin v0.8.6

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/108129
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.7 -m "<description of version>" 66581bcb92869a456684b41c01637a0be8a14593
git push origin v0.8.7

@JuliaRegistrator register branch=master
Release notes:

Change default logger from nothing to MLJBase.default_logger() (which can be reset with MLJBase.default_logger(new_logger)) #221

Registration pull request created: JuliaRegistries/General/111329
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.8 -m "<description of version>" 1421263d8404306621152e3b8303828ffce704f1
git push origin v0.8.8


Make tests for Names

write a test to check for \n, \t, \r and similar in the Sources.source and Names.

Need a concrete example.
Test would go in the test_integrity.py as part of the test_names_table function.


Unify & simplify some view geometry calculations

This unifies the 'offset to line' calculations, and removes
the separate storage of a scroll offset in the EditView.
This tries to have  the y-offset to line number math in one place.
Additionally we don't track the scroll offset independently, and
assume that the view's bounds are up to date when we need them.
Review Checklist

[ ] I have responded to reviews and made changes where appropriate.
[x] I have tested the code
[x] I have updated comments / documentation related to the changes I made.
[x] I have rebased my PR branch onto xi-mac/master.

testing these is possible; but i'm not sure how to write those tests in such a way that you aren't just writing the same equation in both places. 😒

I played around to see if a simple unit test was easy to do but instantiating the edit view is tricky, so no dice.
For manual testing: select a line. Move the cursor so that the center hashmark of the selection indicator (the little dash in the center of the 'I' cursor) is just above the selection. Click, and make sure that the cursor is placed on the line above the selection. Repeat, but this time click just below the selection; the cursor should be placed on the selected line.

thanks @mmatoszko!


Remove the Environment Banner from production environment

Overview

The current way is to check the keyword in the window.location.hostname which is not good
We can have env in the config map(environment variable) - check it for "dev, test, demo or localhost" to show the banner

@dinesh-aot , prod still have a test banner


Migrated http_proxy_advanced_test from SDK.

Travis is having issues with binding to the IPv6 loopback adapter. Following the issue here.


[DO NOT MERGE] Test Circleci with debug GC

Trying @rainers's advice from https://github.com/dlang/phobos/pull/5929#issuecomment-352184482 to debug the DScanner failure.

We now build with BUILD=debug so one

one already sees the entire stacktrace nicely
one can ssh into the machine easily and grab the file

-> closing.


Signing for "MicrosoftFluentUI-FluentUIResources-ios" requires a development with Xcode 14

Environment Information

Platform:

[x] iOS
[ ] macOS

Package version(s): (fill this out, include which package manager you're using)
Xcode and OS versions: (fill this out if relevant)

Please provide a reproduction of the bug:

Actual behavior:
Not running with Xcode 14.
Expected behavior:
Should work.
Priorities and help requested:
Are you willing to submit a PR to fix? (Yes, No). No
Requested priority: (Blocking, High, Normal, Low) Blocking
Products/applications affected: (if applicable)

Please fix ASAP, I need to deliver my project, now i have updated Xcode 14, getting this issue. Signing for "MicrosoftFluentUI-FluentUIResources-ios" requires a development

Please fix ASAP, I need to deliver my project, now i have updated Xcode 14, getting this issue. Signing for "MicrosoftFluentUI-FluentUIResources-ios" requires a development

Hi @HariMohanAgrawal , could you send the full error message, or a screenshot of the error message that you are experiencing? Thanks!

Please try with Xcode 14, in real device its not working.

I was also facing the same issue. I had to choose Microsoft Coorporation Team manually to resolve it. @HariMohanAgrawal

Sorry Microsoft Corporation Team is not showing inside Team drop down, Only my apple account team is showing, but we can not add our apple account inside team, It should be fix without doing anything.
@sophialee0416 Please check, before Xcode 14 its was working fine we can not set our team with third party library.

@sophialee0416
Any update, when it will fix, I need to deliver my app.

@HariMohanAgrawal our team will need to discuss how to address this problem but I will return back to this thread once we reach a conclusion. Unfortunately I am not able to repro this issue on my end

You can check this with Xcode 14, in fresh project just install this library, and run in device. Issue will generate.

Hi,
This issue is not fixed yet, I am working on Xcode 14. But unable to run in device. Getting issue "Signing for "MicrosoftFluentUI-FluentUIResources-ios" requires a development"


[RHODS-1641] Add notebook_namespace parameter for cm and secrets

This change is required for Jupyter server pod placement in custom namespaces. This PR is part of the RHODS-1641 issue
It adds a new parameter in SingleUserProfiles, User, and OpenShift classes named notebook_namespace for that case.

I have not tested this yet, but the changes appear to be exactly what I expected to see. nice

Update, I have now seen this work. /lgtm


InputDatePickerFormField not respecting ambient locale

The InputDatePickerFormField docs say:

When the field is saved or submitted, the text will be parsed into a [DateTime] according to the ambient locale's compact date format

But it should also show the date input text form as the current locale.
My locale is pt_BR, confirmed by running print(Intl.systemLocale); under build():

And this is what is shown:

mm/dd/yyyy is a en_US date standard, in Brazil (pt_BR we use dd/mm/yyyy and InputDatePickerFormField fails to automatically switch to it.
The fieldHintText docs say:
/// The hint text displayed in the [TextField].
///
/// If this is null, it will default to the date format string. For example,
/// 'mm/dd/yyyy' for en_US.

Which leads me to believe that it will get the ambient locale's string format, but it doesn't.

Ok, I figured it out, I didn't configure any localization on Flutter for this App as its only supposed to be used in Brazil.
I think the localized widgets should default to the system locale if no localization information was configured into the MaterialApp.

Hi @feinstein
We discussed this on another issue  https://github.com/flutter/flutter/issues/68055
Closing as duplicate of https://github.com/flutter/flutter/issues/68055


docs: add SECURITY.md

Codecov Report

Merging #237 (8fe8a72) into main (467af57) will not change coverage.
Report is 1 commits behind head on main.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff            @@
##              main      #237   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         1    -1
  Lines           93        24   -69
  Branches        15         3   -12
=========================================
- Hits            93        24   -69

Flag
Coverage Δ

linux-gcc-13
100.00% <ø> (ø)

macos-clang
?

windows-cl
?

windows-clang
?

Flags with carried forward coverage won't be shown. Click here to find out more.
see 2 files with indirect coverage changes


JUP-52-make-carousel-bigger

I mean it looks good but I can't tell a difference between this pr and dev. I feel like there was some design specific change that was wanted but I don't remember what exactly.

I think it was that Solomon wanted the carousel to fill the whole space horizontally, cause currently if you widen the page enough there is additional white space, @RubenOlano correct me if I'm wrong.

Yep, that's what Solomon told me.


tensorflow.python.framework.errors_impl.UnknownError: JIT compilation failed. [Op:FloorMod]

Click to expand!
Issue Type
Bug
Source
binary
Tensorflow Version
2.9.1
Custom Code
No
OS Platform and Distribution
Linux
Mobile device
No response
Python version
3.9.13
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
11.6.2
GPU model and memory
No response
Current Behaviour?
Getting the following error.

  File "lib/python3.9/site-packages/tensorflow/python/framework/ops.py", line 7164, in raise_from_not_ok_status
    raise core._status_to_exception(e) from None  # pylint: disable=protected-access
tensorflow.python.framework.errors_impl.UnknownError: JIT compilation failed. [Op:FloorMod]

Can be fixed by setting the following , however that implies XLA being used is some form.
TF_XLA_FLAGS="--tf_xla_auto_jit=-1" XLA_FLAGS="--xla_gpu_cuda_data_dir=${CUDA_PATH}"

### Standalone code to reproduce the issue

```shell
Not sure how to do that.

Relevant log output
No response

@whatdhack
In order to expedite the trouble-shooting process, please provide a code snippet to reproduce the issue reported here. Thank you!


[Question] Is it possible to see which command cause exception - OCommandExecutionException?

OrientDB Version: 2.2.17
Java Version: 1.8
OS: CentOS 7
Hello,
I use pyorient API to load data from different sources to OrientDB. Sometimes there are inconsistencies in the source data and it couses exceptions like "No edge has been created because no source vertices". I execute a lot of commands in one transaction to easy rollback it when something goes wrong.
My question is:
Is it possible to see which command cause the exception OCommandExecutionException("No edge has been created because no source vertices") or OCommandExecutionException("No edge has been created because no target vertices") - OCommandExecutorSQLCreateEdge.java? I mean the exact command e.g. "Create edge e from A to B". When I execute everything in one transaction it's impossible to handly catch which command caused the problem. Unfortunately the OCommandExecutionException say nothing more than those sentences.
Regards,
Miyazawa-Shi

Hi @Miyazawa-Shi , that is already implemented in latest release 2.2.30, please wait for one day and we release it.

Great message! Thank you so much :)

so we released it, you can check it ))

Now, I use the lastest release 2.2.30, but unfortunately I have the same message without details :( com.orientechnologies.orient.core.exception.OCommandExecutionException: No edge has been created because no source vertices DB name="*****"
When I run e.g. 100 commands in one transaction by pyorient api I have no idea which one cause the exception.

Hi @luigidellaquila could you comment on that?

Hi @Miyazawa-Shi
Let me double-check it, I think CREATE EDGE executor needs a little fix
Thanks
Luigi

HI @Miyazawa-Shi
I just pushed a fix on 2.2.x, it will be released with 2.2.31
Thanks
Luigi