No Such Module 'RealmSwift' ; Xcode 9 Beta Swift 4

Goals

After installation of Realm with Cocoa Pods;
I want to import RealmSwift without Xcode's
compiler complaining.
Expected Results

Realm installed. Import RealmSwift with no errors
Actual Results

Error Message: No Such Module Realm Swift
Steps to Reproduce

Create new Xcode Project.
Name it RealmTasksTutorial
Close Xcode
Open Terminal
Navigate to project's directory i.e. cd ../RealmTasksTutorial
run this command: pod init
run this command: nano Podfile
uncomment platform: iOS 9 and add 'pod RealmSwift'
pod install
open RealmTasksTutorial.xcworkspace

Code Sample

import UIKit
import RealmSwift
//MARK: Model
class ViewController: UITableViewController {
}
Version of Realm and Tooling

Realm framework version: 2.9
Realm Object Server version:  n/a
Xcode version:  Xcode 9 beta
iOS/OSX version: 11
Dependency manager + version: Ruby Gems 2.0 / cocoa-pods 1.2.1
Swift version: 4

Please try the CocoaPods instructions here, and get back to us if it still doesn't work.

@austinzheng
After running the deintegrate cocoa pods commands:
pod cache clean Realm
pod cache clean RealmSwift
pod deintegrate || rm -rf Pods
pod install --verbose
rm -rf ~/Library/Developer/Xcode/DerivedData
and reopening the project RealmTasksTutorial.xcworkspace with 'open' command.
I am getting the same error.

@michaelcordero, I followed the steps you shared and was unable to reproduce the problem. CocoaPods pulled down v2.9.1 of both Realm and Realm Swift, which is newer than the version you mentioned using, but there were no relevant changes between v2.9.0 to v2.9.1.
The fact that Xcode is unable to find the RealmSwift module suggests that it, or the Realm framework it depends on, is missing or has failed to build.
Just to confirm: are you seeing this error when building the RealmTasksTutorial project, or are you simply seeing it after opening the Xcode workspace? I do know that Xcode will complain about failing to find modules simply because you've not got around to building them yet. In that case hitting Cmd-B or Product -> Build will build your project and its dependencies, and will likely clear up the issue.
If you are seeing the error as a result of building your project, this presumably indicates that Realm or RealmSwift failed to build. In that case you'll want to share the build log that Xcode created while building your project as it will contain relevant information, such as the error messages, that will help us understand the failure. You can find the build logs under the Report navigator in Xcode (View -> Navigators -> Show Report Navigator, or Cmd-9).

@michaelcordero, have you had a chance to try this again (either with Xcode 9 beta 4, or the recently-released beta 5)?

Not yet. But I will because I had some version issues with FBSDKCoreKit, so
hopefully if I tweak the versions it will work.
On Tue, Aug 8, 2017 at 2:32 PM Mark Rowe<EMAIL_ADDRESS>wrote:

@michaelcordero https://github.com/michaelcordero, have you had a
chance to try this again (either with Xcode 9 beta 4, or the
recently-released beta 5)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/realm/realm-cocoa/issues/5196#issuecomment-321058306,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIGArhUwqubQFQ0ZUsFSAoRDSL214HLPks5sWLfXgaJpZM4Op9zc
.

It looks to me as if we've answered your question. I'm going to close this issue. Please feel absolutely free to open a new one if you have more questions.

you need to delete the pods folder in the project, and make pod install

Hi I' having a similar issue. I have a project written in Swift 3. I'm using Realm 3.0.0 and it compiles and runs just fine. When I try clicking "Conversion to Swift 4" I get a "No such module as 'RealmSwift' Swift Compiler Error. I tried the cleaning suggested by Austin Zheng above. I also tried deleting and reinstalling cocoapods. I'm using Xcode version 9.0 (9A235).
I installed Realm via a Podfile shown below. Any thoughts would be appreciated.
Thanks!
Uncomment the next line to define a global platform for your project
platform :ios, '11.0'
target 'My App' do
Comment the next line if you're not using Swift and don't want to use dynamic frameworks
use_frameworks!
Pods
pod 'Charts', '~> 3.0.4'
pod 'RealmSwift', '~>3.0.0'
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '4.0'
end
end
end
end

Please create a new ticket and fill out the Issue Template. Thanks.


Using omnisharp latest setting causes omnisharp to fail downloading with 404

Environment data
dotnet --info output:
.NET Core SDK (reflecting any global.json):
 Version:   2.1.302
 Commit:<PHONE_NUMBER>

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.302\

Host (useful for support):
  Version: 2.1.2
  Commit:  811c3ce6c0

.NET Core SDKs installed:
  1.1.9 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.300 [C:\Program Files\dotnet\sdk]
  2.1.301 [C:\Program Files\dotnet\sdk]
  2.1.302 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

VS Code version: 1.26.1
C# Extension version: 1.15.2
Steps to reproduce
Set "omnisharp.path": "latest" in user settings
Open an existing project c# project
Watch C# output window
Expected  behavior
vscode downloads the latest omnisharp
Actual behavior
Getting latest OmniSharp version information
Downloading package 'Latest OmniSharp Version Information' (1 KB).................... Done!
Installing OmniSharp Version = 3.5.0-beta.1858...
Platform: win32, x86_64

Downloading package 'OmniSharp for Windows (.NET 4.6 / x64), Version = 3.5.0-beta.1858' failed (error code '404')
Failed at stage: downloadAndInstallPackages
404

@divinebovine Thank you for filing the issue. We are looking into it.

@divinebovine Thanks--the 404 should be resolved.

Yeah this is fixed now. @rchande Shall we close this one ?

Hey guys, thanks for looking into this, but I'm still experiencing the 404.

@divinebovine Should be fixed (again) (and not regress). Try again?

@rchande thanks, it appears to be fixed.

Yeah, this is happening again. A new VSCode version was released yesterday, which might not be a coincidence.

@Logerfo @RunninglVlan It seems to be fixed for me. Can you try again ?

Yes, it's also fixed for me.

Can you give it a try, coz it worked for me. I had some settings in my settings.json file like proxy settings, omnisharp path etc. But, it failed when I switched to dotnet core 3 and new latest VS Code.
When I emptied out all the settings in settings.json VS code automatically downloaded all the required files and worked. Keep {} only in File->Preferences->Settings.Json (comment all settings) and see if it fixes as its working for me now. [Note, i have proxy settings in cmd(env variables) and .npmrc as internet is necessary]


Support |DataDirectory| for SQLite provider

Summary of the changes

Added |DataDirectory| checks in SqliteConnection connection string path
Created unit test for checking |DataDirectory| support

Fixes #13840

I wonder if sqliteConnection.DataSource should also expand this when the connection is closed...

(Lets see what SQL CE does...)

Looks like CE just returns the string as it was specified in the connection string (always). I'm fine having the same behavior for unopened connections.
We already have a similar difference with relative paths (they're made absolute when open).

        var connStr = "Data Source=|DataDirectory|\\test.sdf";
        var engine = new SqlCeEngine(connStr);
        engine.CreateDatabase();

        var conn = new SqlCeConnection(connStr);
        conn.Open();
        Console.WriteLine(conn.DataSource);

Returns:
   "Data Source=|DataDirectory|\test.sdf"

Thanks, @ErikEJ! I was just skimming through source code, so i'm glad you could confirm the behavior.

@bricelam I'd made those review changes, all seemed good to me. Nit and all!


Collections tab gives The page you were looking for doesn't exist.

Describe the bug
When you open up the collections tab and do not have any collections available "it will error out with The page you were looking for doesn't exist." This only happens when inside of a library. If you are not in a library and have all models open it is fine.
To Reproduce
Steps to reproduce the behavior:

Open Manyfold
Click on a library you have
click on collections tab

Expected behavior
I would expect the collections tab to work the same in and out of a library and display
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: all systems as it is server side issue
Browser:
Version [e.g. 22]

Additional context
This happens on a fresh docker deployment too.  I am using the docker compose with all components in their own containers from the website and running as of the report 0.80.1 (754df235).

Good spot, thank you!


Camel XML Configuration Import in Camel CDI appölication not working

Based on the original Apache Camel example (https://github.com/apache/camel/tree/master/examples/camel-example-cdi-xml) I implemented a wildfly-camel example that should illustrate the use of Camel XML configuration files into Camel CDI applications.
Camel XML Configuration Import support should be available since Camel 2.18.
Unfortunatley this feature doesn't seem to work.
See my example:  https://github.com/jochenr/wildfly-camel-examples/tree/master/camel-cxf-jaxws-cdi-xml

I think the XML file needs to be exposed to the classpath. So placing it in WEB-INF may not be enough. Try adding it to src/main/resources so that it ends up being packaged to WEB-INF/classes.

I'll leave this issue open to serve as a reminder to add some notes to our documentation about this.

Hello James,
thank you very much:-) You are right. After moving "cxfws-camel-context.xml" the example works.
I didn't expect this, because in all the other examples the *-camel-context.xml files are located in the WEB-INF folder.
If you tell me what I have to clean-up, I send you a pull request for the example (and also for my example with JAAS security). It would be nice to have some more projects in the "official examples".
Thank you
Jochen

Please can you clean up any unnecessary comment blocks, I see a few empty comments in some of the files.
We also need some tests. Take a look at the existing ones to see how we do things. It's pretty simple, you reference the example WAR in itests/pom.xml, then deploy it from the Arquillian test case and verify that the example works by hitting an HTTP endpoint or checking log file content etc.
Also, if you do submit a PR please submit it to the wildfly-camel-examples project, as I'm about to remove the examples directory from this project.
Thanks!


Publish Romanian 4.0 translation

The Romanian 4.0 translation has been approved via our translation process and is ready to go live.
Once it is published, please add română to the language list on other published translations, with a link to the Romanian translation.
Thank you!

Looks good!


chore(DependenciesWhitelist): add D3 to Whitelist to prevent breaking changes

@andy-ms this is the initial PR to add d3 for package.json-stubs in line with our discussion here: DefinitelyTyped/DefinitelyTyped#23257.

Don't think this will be necessary if you use path mapping, see my comment on that issue.

I will respond back in the main issue thread on DT.

Closed as per discussion in DefinitelyTyped/DefinitelyTyped#23257


fix for the revert level 51

This solution will falsly match on:

"Bad Commit"
foo "Bad Commit"

However I think it is good enough and importantly it supports the correct solution.

This solution will falsly match on:

"Bad Commit"
foo "Bad Commit"

However I think it is good enough and importantly it supports the correct solution.


Can't run o1-preivew and o1-mini models in the langsmith playground

Issue you'd like to raise.

Here's the error message:
BadRequestError('Error code: 400 - {'error': {'message': "Unsupported value: 'stream' does not support true with this model. Only the default (false) value is supported.", 'type': 'invalid_request_error', 'param': 'stream', 'code': 'unsupported_value'}}')Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/langchain_core/runnables/base.py", line 2303, in _atransform_stream_with_config
File "/usr/local/lib/python3.11/site-packages/langchain_core/runnables/base.py", line 3385, in _atransform
File "/usr/local/lib/python3.11/site-packages/langchain_core/runnables/base.py", line 5573, in atransform
File "/usr/local/lib/python3.11/site-packages/langchain_core/runnables/base.py", line 1473, in atransform
File "/usr/local/lib/python3.11/site-packages/langchain_core/language_models/chat_models.py", line 494, in astream
File "/usr/local/lib/python3.11/site-packages/langchain_core/language_models/chat_models.py", line 472, in astream
File "/usr/local/lib/python3.11/site-packages/langchain_openai/chat_models/base.py", line 2015, in _astream
File "/usr/local/lib/python3.11/site-packages/langchain_openai/chat_models/base.py", line 785, in _astream
File "/usr/local/lib/python3.11/site-packages/ddtrace/contrib/internal/openai/patch.py", line 289, in patched_endpoint
resp = await func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/openai/resources/chat/completions.py", line 1490, in create
File "/usr/local/lib/python3.11/site-packages/openai/_base_client.py", line 1831, in post
File "/usr/local/lib/python3.11/site-packages/openai/_base_client.py", line 1525, in request
File "/usr/local/lib/python3.11/site-packages/openai/_base_client.py", line 1626, in _request
openai.BadRequestError: Error code: 400 - {'error': {'message': "Unsupported value: 'stream' does not support true with this model. Only the default (false) value is supported.", 'type': 'invalid_request_error', 'param': 'stream', 'code': 'unsupported_value'}}
Suggestion:
No response

This is a major annoyance. Can be fixed with the correct pydantic validation.

have u tried deactivating stream as shown here?
https://langchain-ai.github.io/langgraph/how-tos/disable-streaming/?h=o1#disabling-streaming

How is disable_streaming different from the streaming flag on the ChatOpenAI.


Fix "Warning: slow font initialization"

When using the GNUPlotInterface (see galileo/tools) a strange bug occurs. Sometimes, the figures plot perfectly fine, but other times, we get "Warning: slow font initialization" and the legend disappears from the plot. This only seems to happen for the first plot- any subsequent ones work fine.

The issue seems to be resolved by using a single Gnuplot process. The plots render much, much faster now as well.


Update error() and PageError types to include details property for more descriptive error messages

Describe the problem
When throwing an error, it would be nice to pass more info to the Error Page than just a single message property. Kit already allows me to pass an object to the error() function and access it in +error.svelte. However, I get type errors.
+page.server.ts
throw error(401, {
    message: 'Not Logged In',
    details: 'Please login to access this page.'
});

+error.svelte

    {$paged.error?.message}

    {$page.error?.details ?? ''}

Example Error Page

Describe the proposed solution
Update types for PageError interface and error() function to include an optional property details.
ambient.d.ts
export interface PageError {
    message: string;
    details?: string;
}

index.d.ts
export function error(
    status: number,
    // this overload ensures you can omit the argument or pass in a string if App.PageError is of type { message: string }
    body?: { message: string, details?: string } extends App.PageError ? App.PageError | string | undefined : never
): HttpError;

Alternatives considered
Would be nice to include any # of optional properties but I'm not sure how to type that.
Importance
nice to have
Additional Information
No response

You can type PageError yourself in src/app.d.ts:
//app.d.ts
declare namespace {
  PageError {
    message: string;
    details?: string;
  }
}

You also need to implement the handleError functions and return the details for them to actually show up.

@dummdidumm thanks for the info. I didn't realize I could type my own PageError. This is very helpful and solved my problem. I didn't have to do anything with handleError function to access the additional properties in my svelte page.


make runtest

make runtest frame for tttttttttttttttteeeeeeeeeeeeeeeeeeeeesssssssssssssssssssttttttttttttttttttttt

need get camera data stream.

+1 vote

add raw data but not works. should test more.


Need for required enums on 2.0

Description
With 2.0, enums must have a default value. And enums with default value are not required anymore. I would like to have enums required but I didn’t find a way to do it.

Closing in favor of #333


Template 10 for Visual Studio 2017 RC

I don't know if I did something wrong, yet I cannot find the Template 10 extension for Visual Studio 2017 RC.
Do you guys know if it's available or if it isn't, do you plan to release Template 10 for VS 2017?
Thank you,
Julien

Because it doesn't exist...

Usually we wait for RTM, but I have it working 2017 here locally. I'll test a little more next week and publish. Here's the problem. They changed the structure of the projects in 2017. If I change the VSIX to the 2017 structure then it will be weird in 2015. If I leave it right for 2015 then it is weird in 2017.  My inclination is to always support the latest. And I'll likely make it right for 2017 and strange for 2015.
But, if you have any opinions, I am open.

Just found this within the release notes to VS 2017 RC [(https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)]

Users will be warned when trying to install an extension that was not built using the new VSIX format. The old VSIX format does not specify prerequisites needed and may fail to work if those prerequisites are unavailable in Visual Studio 2017 RC. The new VSIX format is backwards compatible and can target past versions of Visual Studio up until Visual Studio 2012.

This would solve everything. It would take away the need to wait for RTM and it would make it possible to have only one development branch for all versions down to VS 2012. At least that is what I think this paragraph wants to tell us ;)
Hope MS can hold this claim...

Any updates on this? Starting my UWP development but downloaded VS2017 RC and now I can't get all the niceties of Template10. Thanks!

Cut and paste?

Any plan to release the extension for VS 2017, now that it is RTM?

Any update?

C'mon @JerryNixon , help us ride the wave of enthusiasm here! Just release what you have and we'll let you know how good it is :)

I also jumped ship to VS 2017. Any news?

Up?


Render Linux runtimes properly when creating web app

Related to https://github.com/microsoft/vscode-azureappservice/issues/1202


tuya local does not map readings anymore

My tuya local devices defined with product id (registered in mappings.py) do not update the readings anymore. the readings stay as dp_xx and do not show the right name and is not commandable anymore (happy heating season began, so i realized now with my heating devices...)
list of one of my devices:
Internals:
DEF        tuya QgDtdkPRBJ9g360K 002009445cxxxxxxxxxx <IP_ADDRESS>  a5bxxxxxxxxx
DEVICEID   002009445xxxxxxxxx
FHEMPYTYPE tuya
FUUID      632b1976-f33f-8cc0-c94d-8e6eada133216fe4
FVERSION   10_fhempy.pm:0.182830/2019-01-16
IODev      [fhempy_local]
NAME       [flKonvektor]
NR         1102
PYTHONTYPE tuya
STATE      Istwert: 23°C
Sollwert: 22°C
Schalter: 0
Stufe: off
Lamellen: 0
TYPE       fhempy
eventCount 16
READINGS:
2022-09-21 16:27:09   dp_01           0
2022-09-21 16:27:09   dp_02           22
2022-09-21 16:27:02   dp_03           23
2022-09-21 16:24:58   dp_04           off
2022-09-21 16:25:00   dp_07           0
2022-09-21 16:20:30   state           online
args:
[flKonvektor]
fhempy
tuya
QgDtdkPRBJ9g360K
002009445xxxxxxx
<IP_ADDRESS>
a5b48a00xxxxxxxx
argsh:
Attributes:
DbLogExclude .*
IODev      [fhempy_local]
alias      Konvektor Flur
devStateIcon on:rc_dot@green off:rc_dot@grey
gassistantName Konvektor
genericDeviceType aircondition
group      Konvektor
homebridgeMapping {
"On": {
"reading": "Power",
"valueOff": "off",
"cmdOn": "Power on",
"cmdOff": "Power off"
},
"TemperatureControlSetCelsius": {
"reading": "TempSet",
"cmd": "TempSet",
"minCelsius": 0,
"maxCelsius": 300,
"stepCelsius": 10,
"formatUx": "C"
},
"TemperatureControlAmbientCelsius": {
"reading": "TempCurrent"
}
}
icon       vent_used_air
realRoom   Flur Erdgeschoss
room       00_Haus,20_Flur,43_FhemPy,61_Heizung,62_Lueftung,73_GoogleHome
userattr   PythonModuleStatus PythonModuleStatus_map structexclude
webCmd     Power:TempSet:Mode:Shake
webCmdLabel Schalter
:Sollwert
:Stufe
:Lamellen

could you please add this heating device to mappings.py (just can open in raw in github):
"utzgmksz7zj66als": {
"schema": [
{
"mode": "rw",
"code": "Power",
"name": "开关",
"property": {"type": "bool"},
"iconname": "icon-dp_power2",
"id": 1,
"type": "obj",
"desc": "",
},
{
"mode": "rw",
"code": "TempSet",
"name": "目标温度",
"property": {
"unit": "℃",
"min": 10,
"max": 49,
"scale": 0,
"step": 1,
"type": "value",
},
"iconname": "icon-dp_temp",
"id": 2,
"type": "obj",
"desc": "",
},
{
"mode": "ro",
"code": "TempCurrent",
"name": "当前温度",
"property": {
"unit": "℃",
"min": 0,
"max": 50,
"scale": 0,
"step": 1,
"type": "value",
},
"iconname": "icon-dp_sun",
"id": 3,
"type": "obj",
"desc": "",
},
{
"mode": "rw",
"code": "Mode",
"name": "模式",
"property": {
"range": ["auto", "50_per", "100_per", "off"],
"type": "enum",
},
"iconname": "icon-dp_mode",
"id": 4,
"type": "obj",
"desc": "",
},
{
"mode": "rw",
"code": "Shake",
"name": "摇头",
"property": {"type": "bool"},
"iconname": "icon-dp_shake",
"id": 7,
"type": "obj",
"desc": "",
},
]
},

new product id added
tried to fix the local mapping error
Can you please try with version 0.1.473?

Thank you 👍 3 of my 4 devices are working fine with the update. I got still one device I cannot switch by fhempy but the readings are updated when using the smart things app.. I will try to setup this device again tomorrow...

I have the impression, that my problem with tuya is related to my other issue (https://github.com/fhempy/fhempy/issues/93). Each time I try to define or defmod something in my tuya devices my log is filled with these entries which will lead in crash and restart of my whole fhem instance:
2022.09.22 12:00:22.620 1: BindingsIo (fhempy_local): ERROR JSON: invalid character encountered while parsing JSON string, at character offset 4096 (before "\x{1}\x{ef}\x{bf}\x{bd}...") at /usr/share/perl5/JSON.pm line 190.
2022.09.22 12:00:22.620 1: BindingsIo (fhempy_local): received JSON was: {"FHEMPYTYPE": "tuya", "PYTHONTYPE": "tuya", "args": ["WEB", "flKonvektor", "00_Haus,20_Flur,43_FhemPy,61_Heizung,62_Lueftung,73_GoogleHome", null], "defargs": ["flKonvektor", "fhempy", "tuya", "QgDtdkPRBJ9g360K", "002009445ccf7f3df1c7", "<IP_ADDRESS>\u00a0a5b48a00f2ee781e", "3.1"], "defargsh": {}, "msgtype": "function", "NAME": "flKonvektor", "argsh": {}, "id": 71033619, "function": "FW_detailFn", "finished": 1, "returnval": "


colab2pdf

@amrzv
I'm trying to promote my colab2pdf code snippet, and I put in a lot of work trying to optimize it.
I'm wondering if it can have a home in your awesome-colab-notebooks repo.
https://github.com/drengskapur/colab2pdf

Sure, added!


Add Export pipe

Ah, dang, I actually wanted that to be two different pull requests but forgot to create separate branches and now the commits are merged in the pull request...
If you don´t like it that way but would accept the modifications individually just close this pull request and I´ll try again.

Yes, it should've been two pull requests, but it's not a very big deal since I like the direction you're going.
The main reason I can't take this PR is that there's absolutely no new tests that proves that this works.
Please have a look at my comments as well.
Last: I need to know why you want the Export pipe. I have no problem understanding why it would be cool to crunch pngs, but I fail to see the usecase for Export. Also, I would very much appreciate if the usecase was documented in the POD with some example of why someone would like to use the pipe and if there's any gotchas regarding caching.

Regarding the usage of "Export": In my custom use case I´m going to have hundreds of them and I don´t want that traffic to reach my app servers. Plus I´ll have a bunch of different apps and want to keep my nginx config simple. This use case may not be applicable to other people so I reduced the docs to the common base: use this, so you can have your assets served directly by your webserver.
Well, things currently work for me so I´ll close this pull request for now and see when I can come up with a revised (and compartmentalized) version. I´ll even try to run your .perltidy (which I simply didn´t see) instead of my own config...

That usecase is not very good: It can be solved with caching in the reverse proxy instead. I do that with cloudflare (a CDN), which means only the first request hits my app server.

I´ll leave the "Export" pipe out, then. Perhaps I´ll independently publish it as Mojolicious::Plugin::AssetPackX::Pipe::Export, eventually.
Regarding the OptiPng pipe: I didn´t like that I had to modify the code in AssetPack.pm for deriving the helper name from the asset format. That´s an - imho unnecessary - extendability restriction. Perhaps there should be a global configuration option in M:P:AssetPack mapping formats to helper names? Unfortunately that would mean that the user would be responsible for the correct configuration if using certain pipes. So it might make more sense putting it in the hands of a pipe to register the appropriate tag helper for a format it can process? That does not look like an ideal solution, too.
The correct tag helper is a property of the asset, but assets do not take configuration options except their building blocks?!

Sorry. I don't follow. Do you mean you want to get hold on the app->asset object from within a pipe? If so just call assetpack(): https://metacpan.org/pod/Mojolicious::Plugin::AssetPack::Pipe#assetpack
Could you please comment on the line in the PR? I might be able to understand more easily what you're meaning about "helper".

Don´t know how to link to it directly; see the modification of lib/Mojolicious/Plugin/AssetPack.pm
at https://github.com/jhthorsen/mojolicious-plugin-assetpack/pull/81/files
Also, I forgot: using M:P:AssetPackX would require the full name in the pipe configuration. That´s ugly.
Since you said you consider the namespace M:P:AssetPack "your own" I´ll have to think of something else...

Call it M::P::AssetPack::Pipe::ExportToDirectory. (I don't like "AssetPackX::")
It's not that I want the namespace for myself. It's just that I might want some generic names to be part of core, such as "Export".

What do you think about b807282?

Managing that as a property of the respective asset looks good to me.
Regarding the namespace: in fact I´d consider using "M::P::AssetPackX" the superior solution.
Appending the "X" is common on CPAN nowadays; if you advertise using "M::P::AssetPackX" for external contributions and test for pipes in "M::P::AssetPack" first (then "M::P::AssetPackX" and finally everything else), you can make sure that the "standard solutions" will be preferred, that contributions will be easily findable in CPAN and that any name clashes won´t be your problem...

I won't add support for "AssetPackX" unless you get (at least) another vote and provide a PR. I think it's terrible if I suddenly break your module, because i decided to add my own module with conflicting names. What I could add support for is the same "namespaces" logic as mojolicious use to resolve plugins.

Please have a look at 28b07d6.

Can't really comment on the code. I still haven't even caught up with the Pipe stuff... but, I see chrunch that probably should be crunch or crush. Also here, I believe Which that should just be Which :smile_cat:

👍


[WFLY-12168] Upgrade wildfly-core from 9.0.0.Beta7 to 9.0.0.Final

JIRA: https://issues.jboss.org/browse/WFLY-12168

Release Notes - WildFly Core - Version 9.0.0.Final
        Component Upgrade

[WFCORE-4472] -         Upgrade Undertow to 2.0.21.Final

[WFCORE-4490] -         Upgrade XNIO to 3.7.2.Final

[WFCORE-4491] -         Upgrade jboss-remoting to 5.0.12.Final

[WFCORE-4506] -         Upgrade JBoss MSC to 1.4.6.Final

        Bug

[WFCORE-4489] -         Missing quotes in wildfly\bin\standalone.bat

[WFCORE-4500] -         IllegalStateException in ManagementSecurityIdentitySupplier

[WFCORE-4503] -         A space in $JAVA path causes bad MODULAR_JDK resolution

First SM job failed https://ci.wildfly.org/viewLog.html?buildId=153673&buildTypeId=WF_PullRequest_LinuxSm&tab=buildResultsDiv. Started a new one to just test for a successful run.


[LANG-1549] implement TODO in CharSequenceUtils.lastIndexOf : remake it.

Hi.
If this change is accectable then I will start CharSequenceUtils.indexOf using same way.
Though, need there be more tests about this function?

Coverage decreased (-0.03%) to 95.01% when pulling 2def83c302b085b255f6b6e0ac17eb5e06cb3bbe on XenoAmess:refine_CharSequenceUtils into 3d4ed4a8ac63db1e51601ffc31fed44dccbb276c on apache:master.

Hi.
According to 72 Hour Lazy Consensus rule, if nobody against this pr, I will continue developing codes about this pr in 50 hours later, means the same functin in indexOf.

Merged manually


fixed typo error with the word application

The word application has been spelt as "APPLCIATION". Submitting PR to fix this typo error.

@amanjeetsingh : Thanks for your contribution! The author, @HeidiSteen, has been notified to review your proposed change.


Context vars set in an async dependency are visible for sync routes but not for sync functions run inside ThreadPoolExecutor

Potentially related tickets https://github.com/tiangolo/fastapi/issues/953 and https://github.com/tiangolo/fastapi/issues/2619.
Example
from concurrent.futures.thread import ThreadPoolExecutor
from contextvars import ContextVar

import uvicorn
from fastapi import FastAPI
from fastapi.params import Security

ctx = ContextVar('', default='N/A')
app = FastAPI()

async def auth():
    ctx.set('test')

def sync_task():
    return ctx.get()

@app.get('/sync1', dependencies=[Security(auth)])
def sync1():
    with ThreadPoolExecutor() as tp:
        return {'hello': tp.submit(sync_task).result()}

if __name__ == '__main__':
    uvicorn.run(app)

Description

Curl /sync1 and you'll get {"hello": "N/A"}.
Should get {"hello": "test"} instead.

So, context vars are not visible within futures run via ThreadPoolExecutor. Why is that? What needs to be done to make them visible? Where is it documented?
Attempt to run via contextvars' run() makes no difference (but I'm noob here):
@app.get('/sync2', dependencies=[Security(auth)])
def sync2():
    def wrapper():
        with ThreadPoolExecutor() as tp:
            return {'hello': tp.submit(sync_task).result()}
    context = contextvars.copy_context()
    return context.run(wrapper)

The result is the same.
Howevever, a direct call works just fine:
@app.get('/sync1', dependencies=[Security(auth)])
def sync1():
    return {'hello': sync_task()}

This returns {"hello": "test"}.
Async routes work always:
async def async_task():
    return ctx.get()

@app.get('/async1', dependencies=[Security(auth)])
async def async1():
    return {'hello': await async_task()}

@app.get('/async2', dependencies=[Security(auth)])
async def async2():
    return {'hello': await run_in_threadpool(sync_task)}

These return {"hello": "test"}.
Environment

OS: Linux
FastAPI version: 0.61.1
Starlette version: 0.13.6
Uvicorn version: 0.12.2
Python version: 3.7.9

This is a known Python issue rather than FastAPI.
See: https://github.com/python/cpython/pull/9688
I'd love to open PR to fix this on our side. For example this implementation of ThreadPoolExecutor fixes your case.

from concurrent.futures import Future, ThreadPoolExecutor
import functools
import contextvars
from typing import Callable, Future

class ContextSafeThreadPoolExecutor(ThreadPoolExecutor):
    def submit(self, fn: Callable, *args, **kwargs) -> Future:
        ctx = contextvars.copy_context()

        return super().submit(partial(ctx.run, partial(fn, *args, **kwargs)))

Hey, thanks for the insight!
As far as I can tell, the linked ticket and (somewhat branching) discussion is about loop.run_in_executor(). But I'm not sure we should use that inside a thread already spawned?
I mean, if I'm using a sync route, FastAPI/starlette already spawns a thread. Context var, set in async dependency, is visible within that thread. Only when I invoke a thread within the thread, will I lose the context var.
But maybe you just meant that if the linked fix ever gets merged, then we could use loop.run_in_executor() instead of run_in_threadpool()? Or at least that run_in_threadpool() would become simpler.
However, we would still need the sub-classed ContextSafeThreadPoolExecutor, when spawning threads within a sync route?

I'd love to open PR to fix this on our side

What's the API / utility function that you had in your mind?

As far as I can tell, the linked ticket and (the somewhat confusing) discussion is about loop.run_in_executor(). But I'm not sure we should use that inside a thread already spawned?

The problem here is, like you mentioned a thread is already spawned, you are creating another Thread inside it.
In here, when you spawn another thread inside a thread, you are doing something like this:

As i shown in the diagram, the auth coroutine never changes your original context. asyncio is natively context-safe, but threads are not.
Since Python 3.9 we have asyncio.to_thread
async def to_thread(func, /, *args, **kwargs):
    """Asynchronously run function *func* in a separate thread.

    Any *args and **kwargs supplied for this function are directly passed
    to *func*. Also, the current :class:`contextvars.Context` is propogated,
    allowing context variables from the main thread to be accessed in the
    separate thread.

    Return a coroutine that can be awaited to get the eventual result of *func*.
    """
    loop = events.get_running_loop()
    ctx = contextvars.copy_context()
    func_call = functools.partial(ctx.run, func, *args, **kwargs)
    return await loop.run_in_executor(None, func_call)

Which is pretty similar to what Starlette doing right now:
async def run_in_threadpool(
    func: typing.Callable, *args: typing.Any, **kwargs: typing.Any
) -> typing.Any:
    loop = asyncio.get_event_loop()
    if contextvars is not None:  # pragma: no cover
        # Ensure we run in the same context
        child = functools.partial(func, *args, **kwargs)
        context = contextvars.copy_context()  # <------------------ here
        func = context.run
        args = (child,)
    elif kwargs:  # pragma: no cover
        # loop.run_in_executor doesn't accept 'kwargs', so bind them in here
        func = functools.partial(func, **kwargs)
    return await loop.run_in_executor(None, func, *args)

So the Starlette done his part right so far. They can't do better than that (I believe)

the linked ticket and (the somewhat confusing) discussion is about loop.run_in_executor()

So coming back to this again, currently you can not retain the context that changes inside of run_in_executor.
Run in executor basically wraps the function and submit's it to the executor using executor.submit. Which also looks like this.
return futures.wrap_future(executor.submit(runner), loop=self)

But, maybe you just meant that if the linked fix ever gets merged, then we could use loop.run_in_executor() instead of run_in_threadpool()? Or at least that run_in_threadpool() would become simpler?

However, we would still need the sub-classed ContextSafeThreadPoolExecutor, when spawning threads within a sync route?

No, if this gets merged (I don't think this will happen in near future.), we won't need to subclass it anymore, in depth, the threads have their own stack, when you run a function with run_in_threadpool it goes from these steps.

Your function goes into run_in_threadpool(func, *args, **kwargs) -> T:
run_in_threadpool copies the context that is inside the global state.
1-) Wraps the function to run inside the context. functools.partial(context.run, func, *args, **kwargs)
2-) Then uses run_in_executor to run the function  `await loop.run_in_executor(None, func).
run_in_executor, uses executor.submit to submit to function to a thread.

Nothing fancy in executor.submit, has two locks, one on global state and another on shared state. It is just a basic threading.Lock. Locks the both and puts function to the queue.SimpleQueue, nothing fancy.

This is the most interesting part (run_in_executor doesn't copies the context on global state). Lots of discussions happened on this topic.
Let's start with: Bugs Python Issue 34014:
* Issue context: PEP 567 supports copying context into another threads, but for asyncio users each call run_in_executor requires explicit context propagation.

What's the API / utility function that you'd add?

I'm not sure about we can do something about this, all we are doing is copying the context that is at global state and sharing it between the states. But in your example, you are creating a new Subclass of Executor which is ThreadPoolExecutor.
Someone said in the earlier discussion at #953  "logically dependency should have the same context as route handler.".  It is also not right.
This will work, or without making this coroutine will work (def sync1()).
@app.get('/sync1', dependencies=[Depends(auth)])
async def sync1():
    return {'hello':sync_task()}

But we can do nothing about the code below, this is completely up to Python interpreter.
    with ThreadPoolExecutor() as tp:
        return {'hello': tp.submit(sync_task).result()}

As far as i seen from the discussions this is also a wont-fix feature request and there are plently amount of reasons that makes this comprehensible.
Yury Selivanov said:

I considered enabling that, but in the end decided not to. The reason is that it's possible to use a ProcessPoolExecutor with run_in_execuror(), and context cars currently don't support pickling (and probably never will). We can't have a single api that sometimes works with contextvars and sometimes doesn't.

So this is a "won't fix".

Impressive diagram! :) Thanks for writing that out.
I would have placed Event Loop directly under Uvicorn/FastAPI, but I guess that would be just wrong then. Actually, pardon me if I got something wrong, as I don't know this stuff by heart:
In short, if I understand right, asyncio.to_thread() is nice, a more "standard" way to do run_in_threadpool() (though there are subtle differences). The loop.run_in_executor() fix (to copy context) is not really needed, as both run_in_threadpool() and asyncio.to_thread() already have the necessary boilerplate to run inside the context.
None of these actually retain the changes made to context vars within. Which is not the topic here, as the problem is seeing the context vars. Propagating back, is indeed https://github.com/tiangolo/fastapi/issues/953.
However, these are solutions for spawning threads from event loop (async) context, where you await. My need is to really do some sync calls concurrently in sync parts of code. Which means that I cannot do await asyncio.to_thread(), await loop.run_in_executor() or await run_in_threadpool(), so I guess that leaves me your ContextSafeThreadPoolExecutor. Right?

I would have placed Event Loop directly under Uvicorn/FastAPI but you clearly know this better. Actually, pardon me if I got something wrong, as I don't know this stuff by heart

That's right, that part is not clear enough, but as you mentioned it uses asyncio.get_event_loop to get current thread's event loop. I tried to seperate the function and coroutine there, ups.

In short, if I understand right, asyncio.to_thread() is nice, a more "standard" way to do run_in_threadpool() (though there are subtle differences)

It is actually the same thing, but unlike asyncio.to_thread, starlette's run_in_threadpool prechecks the contextvars since it is added in 3.7.
try:
    import contextvars  # Python 3.7+ only or via contextvars backport.
except ImportError:  # pragma: no cover
    contextvars = None  # type: ignore

The loop.run_in_executor() fix (to copy context) is not really needed, as both run_in_threadpool() and asyncio.to_thread() already have the necessary boilerplate to run inside the context.

None of these actually retain the changes made to context vars within. Which is not the topic here, as the problem is seeing the context vars. Propagating back, is indeed #953.

Exactly,  in your case if anything is going to change, it should be in standard library.

However, these are solutions for spawning threads from event loop (async) context, where you await. My need is to really do some sync calls concurrently in sync parts of code. Which means that I cannot do await asyncio.to_thread(), await loop.run_in_executor() or await run_in_threadpool(), so I guess that leaves me your ContextSafeThreadPoolExecutor. Right?

Yup, i'd love to see if any other solutions are available because i had a similar situation before and this is what we came up with.

Which is not the topic here, as the problem is seeing the context vars. Propagating back, is indeed #953.

Yup, Django's _restore_context looks promising. Though there are plenty amount of abstractions in Django's codebase that i really don't like to the read :laughing:
That also being said, keep this one open, since the context and use case is different from #953

Additionally, it seems that yield dependency calls the tail in a different context:
async def get_db():
    token = DB.set(42)
    try:
        yield
    finally:
        DB.reset(token)

Sprinkling in logging.warn("xx %r", id(asyncio.current_task())) shows that:

task1 is used to set up the db
task1 is used to process the request
task2 is used to cleanup the db 🙈

We now depend on anyio, and the last release (3.4.0) should have fixed this (even if the original issue was without anyio).
https://anyio.readthedocs.io/en/stable/versionhistory.html

Thanks for the discussion everyone!
As @Kludex says, indeed, the original issue should be solved by the new AnyIO version. It is discussed here: https://github.com/agronholm/anyio/issues/363 , the fix was here: https://github.com/agronholm/anyio/pull/390
About @dimaqq's comment, that's another independent issue that I've been working on for several days. 😅 It is fixed by the just released FastAPI 0.74.0. 🎉
More details in the PR: https://github.com/tiangolo/fastapi/pull/4575

Quickly glancing, would it be so that the AnyIO improvement also fixes https://github.com/tiangolo/fastapi/issues/953?

Hi, I reran the test @tuukkamustonen sent in the OP with a minimal modification to run it using pytest and it still fails.
I'm using anyio==3.5.0, fastapi==0.75.2 and Python 3.9.11.
from concurrent.futures.thread import ThreadPoolExecutor
from contextvars import ContextVar

from fastapi import FastAPI
from fastapi.params import Security
from fastapi.testclient import TestClient

ctx = ContextVar('', default='N/A')
app = FastAPI()

async def auth():
    ctx.set('test')

def sync_task():
    return ctx.get()

@app.get('/sync1', dependencies=[Security(auth)])
def sync1():
    with ThreadPoolExecutor() as tp:
        result = tp.submit(sync_task).result()
    return {'hello': result}

client = TestClient(app)

def test_context_var_propagation():
    response = client.get("/sync1")
    assert response.status_code == 200
    assert response.json() == {"hello": "test"}

/Users/diego/.pyenv/versions/python-3.9/bin/python "/Applications/PyCharm CE.app/Contents/plugins/python-ce/helpers/pycharm/_jb_pytest_runner.py" --path "/Users/diego/Library/Application Support/JetBrains/PyCharmCE2021.3/scratches/scratch_2.py"
Testing started at 17:48 ...
Launching pytest with arguments /Users/diego/Library/Application Support/JetBrains/PyCharmCE2021.3/scratches/scratch_2.py --no-header --no-summary -q in /Users/diego/Library/Application Support/JetBrains/PyCharmCE2021.3/scratches

============================= test session starts ==============================
collecting ... collected 1 item

scratch_2.py::test_context_var_propagation FAILED                        [100%]
scratch_2.py:29 (test_context_var_propagation)
{'hello': 'N/A'} != {'hello': 'test'}

Expected :{'hello': 'test'}
Actual   :{'hello': 'N/A'}

I was able to make the test pass by using a ThreadPoolExecutor's initializer as a workaround:
from concurrent.futures.thread import ThreadPoolExecutor
from contextvars import ContextVar

from fastapi import FastAPI
from fastapi.params import Security
from fastapi.testclient import TestClient

ctx = ContextVar('', default='N/A')
app = FastAPI()

async def auth():
    ctx.set('test')

def sync_task():
    return ctx.get()

@app.get('/sync1', dependencies=[Security(auth)])
def sync1():
    current_ctx = ctx.get()
    with ThreadPoolExecutor(initializer=lambda: ctx.set(current_ctx)) as tp:
        result = tp.submit(sync_task).result()
    return {'hello': result}

client = TestClient(app)

def test_context_var_propagation():
    response = client.get("/sync1")
    assert response.status_code == 200
    assert response.json() == {"hello": "test"}

/Users/diego/.pyenv/versions/python-3.9/bin/python "/Applications/PyCharm CE.app/Contents/plugins/python-ce/helpers/pycharm/_jb_pytest_runner.py" --path "/Users/diego/Library/Application Support/JetBrains/PyCharmCE2021.3/scratches/scratch_2.py"
Testing started at 17:52 ...
Launching pytest with arguments /Users/diego/Library/Application Support/JetBrains/PyCharmCE2021.3/scratches/scratch_2.py --no-header --no-summary -q in /Users/diego/Library/Application Support/JetBrains/PyCharmCE2021.3/scratches

============================= test session starts ==============================
collecting ... collected 1 item

scratch_2.py::test_context_var_propagation PASSED                        [100%]

============================== 1 passed in 0.25s ===============================

Process finished with exit code 0


Measurable Decomm: show aggregate decomms

We can currently see each decomm/replacement by clicking on individual ratings in an applications measurable rating tree.  However there is no overall view either for an application or for a group of applications, or for a specific measurable.

Some sql that I've been playing around with that shows decomms/replacements which include a given org unit (postgres):
with
     ous as (
         select id
         from entity_hierarchy
         where ancestor_id = 20
           and kind = 'ORG_UNIT')
select distinct
       dapp.name,
       m.name,
       m.id,
       case
           when dapp.organisational_unit_id in (select id from ous) then 1
           else 0
       end decommer_in_selector,
       mrd.planned_decommission_date,
       rapp.name,
       case
           when rapp.organisational_unit_id in (select id from ous) then 1
           else 0
       end replacer_in_selector,
       mrr.planned_commission_date
from measurable_rating_replacement mrr
inner join measurable_rating_planned_decommission mrd
    on mrr.decommission_id = mrd.id
inner join measurable m
    on mrd.measurable_id = m.id
inner join application rapp
    on mrr.entity_id = rapp.id
inner join application dapp
    on mrd.entity_id = dapp.id
where
    dapp.organisational_unit_id in (select id from ous)
    or
    rapp.organisational_unit_id in (select id from ous);


Purge 3rd party components

trikRuntime, Box2D, qextserial

Download:
Environment: QT=5.12, ARCH=32, CONFIGURATION=release, QTIFW=C:\Qt\Tools\QtInstallerFramework\3.1


sha256sum: docker-compose.sha256sum: no properly formatted checksum lines found

"features": {
      "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {},
  }

43.15 Preparing to unpack .../moby-compose_2.32.0-debian12u1_amd64.deb ...
43.16 Unpacking moby-compose (2.32.0-debian12u1) ...
43.88 Setting up moby-compose (2.32.0-debian12u1) ...
45.47 compose_version=2.32.0
45.47 (*) Installing docker-compose 2.32.0...
69.08 sha256sum: docker-compose.sha256sum: no properly formatted checksum lines found
69.08 ERROR: Feature "Docker (docker-outside-of-docker)" (ghcr.io/devcontainers/features/docker-outside-of-docker) failed to install! Look at the documentation at https://github.com/devcontainers/features/tree/
main/src/docker-outside-of-docker for help troubleshooting this error.

Firewall issue

Firewall issue


Update main.cpp

Make sure printf gets '\n'

Still fails but at least its a behavioral failure and not a missing flush.
Test::Output::Start
[WARNING] Using default settings. Define your settings in the file "./mbed_settings.py"
MBED: Instrumentation: "COM5" and disk: "E:"
HOST: Copy image onto target...
        1 file(s) copied.
HOST: Initialize serial port...
Looking for K64F with MBEDLS
...port ready!
HOST: Reset target...
HOST: Property 'timeout' = '20'
HOST: Property 'host_test_name' = 'serial_complete_auto'
HOST: Property 'description' = 'Serial Complete'
HOST: Property 'test_id' = 'MBED_39'
HOST: Start test...
HOST: 12345678
HOST: Unexpected output. '123456789' Expected. but received '12345678'

{{failure}}
{{end}}
Test::Output::Finish
TargetTest::K64F[9900]::ARM::MBED_39::Serial Complete [FAIL] in 5.41 of 20 sec
Test summary:
+--------+------------+-----------+---------+------------------+--------------------+---------------+-------+
| Result | Target     | Toolchain | Test ID | Test Description | Elapsed Time (sec) | Timeout (sec) | Loops |
+--------+------------+-----------+---------+------------------+--------------------+---------------+-------+
| FAIL   | K64F[9900] | ARM       | MBED_39 | Serial Complete  |        5.41        |       20      |  0/1  |
+--------+------------+-----------+---------+------------------+--------------------+---------------+-------+
Result: 1 FAIL

Completed in 12.17 sec


[Question] How to limit the flow on this side of hstore?

Problem Type (问题类型)
struct / logic (架构 / 逻辑设计问题)
Before submit

[X] 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

Server Version: 1.0.0 (Apache Release Version)
Backend: RocksDB x nodes, HDD or SSD
OS: xx CPUs, xx G RAM, Ubuntu 2x.x / CentOS 7.x
Data Size:  xx vertices, xx edges

Your Question (问题描述)
How to limit the flow on this side of hstore?
Vertex/Edge example (问题点 / 边数据举例)
No response
Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)
No response

try this
https://gofile.io/d/yMHabA
select the desired compiler in the installer

@dosu When multiple servers access the hstore together, is there any configuration to implement read/write traffic control on the hstore?


Cancel fetch PRs

Issues: Cancel fetch PRs if user login with admin/password in dev #242

@Sunnidhya Can you please locally run npm run lint:fix, that should fix the linting and UI lint job should pass.


custom attributes in consumer config now seq again

resolves #27

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Ayrat Hudaygulov seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks; not sure what I was thinking!


Make ajv a peer dependency

Making ajv a peer dependency of ajv-formats resolves issue #13 that is causing TypeScript version mismatch errors on every ajv upgrade.

Pull Request Test Coverage Report for Build 624953550

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 92.377%

Totals

Change from base Build 423983827:
0.0%

Covered Lines:
121

Relevant Lines:
128

💛  - Coveralls

This PR broke ajv-formats@^1 support with npm@6 and npm@7 with --legacy-peer-deps.
Reproducible by:
npm install @eslint/eslintrc conf --legacy-peer-deps
node -e "require('conf');"

Should be fixed by setting both:
"dependencies": {
  "ajv": "^7.0.0"
},
"peerDependencies": {
  "ajv": "^7.0.0"
},
"peerDependenciesMeta": {
  "ajv": {
    "optional": true
  }
}

so it has to be patched in both v1 and v2 then...

@epoberezkin I don't think so, but not sure about yarn and pnpm.
But currently it is completely broken for npm@6 and npm@7 with --legacy-peer-deps
peerDependencies is ignored, see another reproduction:
mkdir repro
cd repro
npm install ajv-formats --legacy-peer-deps
node -e "require('ajv-formats')"

Also, the example above is not representative of real life use cases - there is no use case when you would be installing ajv-formats without also installing ajv.

For example, what is the setup (and how common it is) when running npm without --legacy-peer-deps fails (which is the use case for using it, as far as I understand)? Your examples work without it.

Our generated project is --legacy-peer-deps safe for angular, not for react neither vue.
What about npm@6? Which is included in every node lts versions.
Easily reproducible with
npx npm@6 install @eslint/eslintrc conf
node -e "require('conf');"

Same output
internal/modules/cjs/loader.js:883
  throw err;
  ^

Error: Cannot find module 'ajv/dist/compile/context'
Require stack:
- /Users/mshima/aplicacoes/ajv/node_modules/ajv-formats/dist/limit.js

Would it work if you run in with --force (which would report the conflict, but could be better)?

--force had many problems recently. It's great when executing manually.
But our workflow executes npm install automatically, It's safer to use npm@6 behavior (which is well known) than using --force.
You should at least update the package.json engines version to require npm >= 7.8.0 since you don't support npm@6 anymore.
We reverted the conf package to a version that doesn't depends on ajv-format at https://github.com/jhipster/generator-jhipster/pull/14531.
And a new release is planned for soon, this won't be a problem anymore for jhipster.
Thanks for your time.

need to test the proposed change.

@mshima I've tested and it does look like the original problem does not re-occur after this change - thank you!
@drtyh2o can you please test that it is still working ok with your setup?
It is now released as v1.6.1 and v2.0.2

@drtyh2o can you please test that it is still working ok with your setup?
It is now released as v1.6.1 and v2.0.2

v2.0.2 seems to work fine for me. Thanks.

Thank you @drtyh2o.
The problem is that with this change I cannot run ajv tests (at least not locally on Mac - they do run on GitHub CI) - the tests use on ajv-formats, so it's dev dependency for ajv...
Before the test I need to do npm link && npm link ajv - it is needed to test "standalone code", so it can require("ajv"), as it would be for the users.
npm link ajv fails, with npm link ajv --legacy-peer-deps and with npm link ajv --force the tests fail...
@mshima - any idea how it can be fixed?

@epoberezkin dev dependency on ajv should be dropped from ajv-formats, it's a prod dependency already.

Before the test I need to do npm link && npm link ajv - it is needed to test "standalone code", so it can require("ajv"), as it would be for the users.

Some of this can be help:

links can be problematic, it may break the linked package node_modules tree. You may try something like npm link && npm link ajv && cd ../ajv-formats && npm install && cd ../ajv
install from github instead of linking when testing with latest version: npm install ajv-validator/ajv-formats#master
GitHub actions uses npm@6, maybe related?
for cross dependency, maybe you should add a mono-repo like package.json in the parent folder for this.
Just in time for npm 7.8.0 that brings lots of fixes supporting this. https://github.com/npm/cli/releases/tag/v7.8.0

I use some cross dependencies too, but test with released versions (normal tests) or install using GitHub link (option 2 for integration tests testing both sides).

The whole point of peerDependencies is that they’re specifically not declared production dependencies. The typical pattern for libraries and plugins is to define these sorts of packages as peerDependencies (for when the library is being installed) and devDependencies (for when the library is being developed). Having ajv be a production dependency of ajv-formats is what causes the original issue whenever new versions ofajv are published. Whoever is installing ajv-formats should be responsible for also installing ajv. Having ajv-formats install a version of ajv is the problem this PR attempts to resolve. While the latest version seems to work, I feel this is destined to break on the next ajv update. My recommendation is to leave ajv in devDependencies and remove it from dependencies.

The whole point of peerDependencies is that they’re specifically not declared production dependencies.

That's not true.
https://classic.yarnpkg.com/en/docs/dependency-types/#toc-peerdependencies
This is useful for packages like react that need to have a single copy of react-dom that is also used by the person installing it.
Having single copy of a package so the api is compatible for the whole dependency tree.
peerDependency takes precedency (at least for npm@7), so the dependencies entry is just ignored.
The fix I've proposed is commonly used to fix this kind of problem.
IMO packages should keep npm@6 compatibility at least while node 14 (which includes npm@6) is supported.
Installing with --legacy-peer-deps:
$ npm explain ajv ajv-formats

<EMAIL_ADDRESS>node_modules/ajv
<EMAIL_ADDRESS>from<EMAIL_ADDRESS>  node_modules/@eslint/eslintrc
<EMAIL_ADDRESS>from the root project

<EMAIL_ADDRESS>node_modules/ajv-formats/node_modules/ajv         <--- only installed with<EMAIL_ADDRESS>
<EMAIL_ADDRESS>node_modules/conf/node_modules/ajv
<EMAIL_ADDRESS>from<EMAIL_ADDRESS>  node_modules/conf
<EMAIL_ADDRESS>from the root project

<EMAIL_ADDRESS>node_modules/ajv-formats
<EMAIL_ADDRESS>from<EMAIL_ADDRESS>  node_modules/conf
<EMAIL_ADDRESS>from the root project

Using npm@6 or npm@7 with --legacy-peer-deps, ajv@6 is deduped side by side with ajv-formats@1, breaking ajv-formats.
Using npm@7 without --legacy-peer-deps dedupes correctly:
$ npm explain ajv ajv-formats

<EMAIL_ADDRESS>node_modules/ajv
<EMAIL_ADDRESS>from<EMAIL_ADDRESS>  node_modules/@eslint/eslintrc
<EMAIL_ADDRESS>from the root project

<EMAIL_ADDRESS>node_modules/conf/node_modules/ajv
<EMAIL_ADDRESS>from<EMAIL_ADDRESS>  node_modules/conf
<EMAIL_ADDRESS>from the root project
  peerOptional<EMAIL_ADDRESS>from<EMAIL_ADDRESS>  node_modules/conf/node_modules/ajv-formats
<EMAIL_ADDRESS>from<EMAIL_ADDRESS>    node_modules/conf
<EMAIL_ADDRESS>from the root project

<EMAIL_ADDRESS>node_modules/conf/node_modules/ajv-formats
<EMAIL_ADDRESS>from<EMAIL_ADDRESS>  node_modules/conf
<EMAIL_ADDRESS>from the root project

While the latest version seems to work, I feel this is destined to break on the next ajv update

I actually did test the scenario of the update, by first having ajv: 7.2.2 in package.json, and then changing it to ajv: ^7.2.4 and running upgrade - it did not break (same for v8).
Also, for unrelated reason, I've published ajv 8.0.4 and then 8.0.5 - did it break the dependency in ajv-format in your case @drtyh2o? I was hoping you'd be able to test the update scenario in a similar way... We can just wait till the next update and see if something breaks.

@mshima thanks for the suggestions

dev dependency on ajv should be dropped from ajv-formats, it's a prod dependency already.

indeed, but I don't think it's what causes the issue

GitHub actions uses npm@6, maybe related?

most likely - I was going to add printing version to the test...

install from github instead of linking when testing with latest version

it didn't change anything - it still fails on npm link ajv...

You may try something like npm link && npm link ajv && cd ../ajv-formats && npm install && cd ../ajv

I don't understand - ajv-formats is in node-modules, I am linking npm link ajv inside ajv, not in ajv-formats
Anyway, for now I've downgraded local npm to v6.


Feature/acm 82 chil2021 updates - Clean start from Mini-Conf v1.5 with content updates for ACM-CHIL 2021

This PR consists of clean copy of code taken from upstream Mini-Conf master (v1.5) and updating pages for the upcoming ACM CHIL 2021 conference.

Thanks everyone, I think this is a good start. Just had a quick chat with Marzyeh and Tristan and we're hoping that we can all get together next Monday to plan out what we need in terms of website etc in a bit more detail. Hopefully this will make your life a bit easier Tak! I'll follow up with an email shortly.


Refresh the odata model after the batch request

Hi Gurus,
I need to set the newly expanded data with the old odata model after the batch request. But I don't know how to make it. The batch request doesn't seem to support refresh the data model automatically.
B.R.
Yang

Hi Yang,
check out the refresh function of a binding https://openui5.hana.ondemand.com/docs/api/symbols/sap.ui.model.Binding.html
BR,
Tobias


problem extracting bigquery table data to cloud storage

I am in chapter 9 of the book trying to extract BigQuery table into Google Cloud Storage when I ran into a problem.
The code where I ran into problem is (inside the correct project id is printed by PROJECT):
%%bash
PROJECT=$(gcloud config get-value project)
for dataset in "train" "eval" "all"; do
  TABLE=dsongcp.flights_${dataset}_data
  CSV=gs://${BUCKET}/ch9/data/${dataset}.csv
  echo "Exporting ${TABLE} to ${CSV} and deleting table"
  bq --project_id=${PROJECT} extract --destination_format=CSV $TABLE $CSV
  bq --project_id=${PROJECT} rm -f $TABLE
done

For some odd reason, I am getting weird error message:
Exporting dsongcp.flights_train_data to gs://tribbute-ml-central/ch9/data/train.csv and deleting table in project tribbute-ml
BigQuery error in extract operation: BigQuery API has not been used in project
457198359311 before or it is disabled. Enable it by visiting https://console.dev/
elopers.google.com/apis/api/bigquery.googleapis.com/overview?project=457198359311
then retry. If you enabled this API recently, wait a few minutes for the
action to propagate to our systems and retry.

This is followed by:
CalledProcessError: Command 'b'PROJECT="tribbute-ml"\nfor dataset in "train" "eval" "all"; do\n  TABLE=dsongcp.flights_${dataset}_data\n  CSV=gs://${BUCKET}/ch9/data/${dataset}.csv\n  echo "Exporting ${TABLE} to ${CSV} and deleting table in project ${PROJECT}"\n  bq extract --project_id=${PROJECT} --location=us-central1 --destination_format=CSV $TABLE $CSV\n  bq --project_id=${PROJECT} rm -f $TABLE\ndone\n'' returned non-zero exit status 1.

Weird thing is that I already enabled BigQuery API for my project and "457198359311 " is not even my project. (I verified that in the bash command correct project id gets printed)
Anyone knows what's causing this issue and how to fix it?

This looks like a bug. It's possible that
bq extract
is using a "shadow" project to run a pipeline to do the extraction.
Can you file an issue against BigQuery?
https://issuetracker.google.com/savedsearches/559654?pli=1&q=(componentid:187149%2B status:open %2B type:Bug) OR (componentid:187065%2B customfield82940:"BigQuery" status:open)
Looks like people are running into issues with saving query results as a
table as well, but they don't get the nice error message that you do.
thanks
Lak
On Wed, Aug 3, 2022 at 2:11 PM Chris Shin @.***> wrote:

I am in chapter 9 of the book trying to extract BigQuery table into Google
Cloud Storage when I ran into a problem.
The code where I ran into problem is (inside the correct project id is
printed by PROJECT):
%%bash
PROJECT=$(gcloud config get-value project)
for dataset in "train" "eval" "all"; do
TABLE=dsongcp.flights_${dataset}_data
CSV=gs://${BUCKET}/ch9/data/${dataset}.csv
echo "Exporting ${TABLE} to ${CSV} and deleting table"
bq --project_id=${PROJECT} extract --destination_format=CSV $TABLE $CSV
bq --project_id=${PROJECT} rm -f $TABLE
done
For some odd reason, I am getting weird error message:
Exporting dsongcp.flights_train_data to gs://tribbute-ml-central/ch9/data/train.csv and deleting table in project tribbute-ml
BigQuery error in extract operation: BigQuery API has not been used in project
457198359311 before or it is disabled. Enable it by visiting https://console.dev/elopers.google.com/apis/api/bigquery.googleapis.com/overview?project=457198359311
then retry. If you enabled this API recently, wait a few minutes for the
action to propagate to our systems and retry.
This is followed by:
CalledProcessError: Command 'b'PROJECT="tribbute-ml"\nfor dataset in "train" "eval" "all"; do\n  TABLE=dsongcp.flights_${dataset}_data\n  CSV=gs://${BUCKET}/ch9/data/${dataset}.csv\n  echo "Exporting ${TABLE} to ${CSV} and deleting table in project ${PROJECT}"\n  bq extract --project_id=${PROJECT} --location=us-central1 --destination_format=CSV $TABLE $CSV\n  bq --project_id=${PROJECT} rm -f $TABLE\ndone\n'' returned non-zero exit status 1.
Weird thing is that I already enabled BigQuery API for my project and
"457198359311 " is not even my project. (I verified that in the bash
command correct project id gets printed)
—
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/data-science-on-gcp/issues/153,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANJPZ6DRWYL2OOL7HKWWP3VXLN6ZANCNFSM55QILGTA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I filed an issue.
For now if anyone else runs into same issue, you can manually export the table. Go the BigQuery, then click the table you want to export. Under export tab click "Export to GCS"


Homebrew.HB no longer automatically taps if a package in a tap is specified (e.g. "homebrew/science/hdf5")

While brew search returns information on packages in untapped taps, brew info does not. Thus Homebrew.HB determines that the package cannot be installed, even though an attempted add would work.
See https://github.com/JuliaIO/HDF5.jl/pull/314 for more.

Note that this means anyone's OS X CI is broken if it depends on HDF5.jl, as hdf5 is no longer present in staticfloat/juliadeps (which is tapped by default).

+1 just ran into this problem yesterday with hdf5

Thanks for the report, I've got a fix pushed up in e19eea016424ddb4479003a33c048997e3dd929e

Is this in the last release?   Are you certain that the path is correct in your provides() call?  Could you post the entire error message here?  With the following diff to the current master of Metis.jl:
diff --git a/deps/build.jl b/deps/build.jl
index be5e526..be9e1f7 100644
--- a/deps/build.jl
+++ b/deps/build.jl
@@ -4,16 +4,16 @@ using BinDeps,Compat

 libmetis = library_dependency("libmetis", aliases=["libmetis5"])

-@windows_only begin
+@static if is_windows()
     using WinRPM
     provides(WinRPM.RPM, "metis", libmetis, os = :Windows)
 end

-@osx_only begin
+@static if is_apple()
     if Pkg.installed("Homebrew") === nothing
         error("Homebrew package not installed, please run Pkg.add(\"Homebrew\")")  end
     using Homebrew
-    provides(Homebrew.HB, "metis", libmetis, os = :Darwin)
+    provides(Homebrew.HB, "homebrew/science/metis", libmetis, os = :Darwin)
 end

 provides(AptGet, "libmetis5", libmetis)

I get the proper behavior:
julia> Pkg.build("Metis")
INFO: Building Rmath
INFO: Building Homebrew
Already up-to-date.
INFO: Building Blosc
INFO: Building HDF5
==> Tapping homebrew/science
Cloning into '/Users/sabae/.julia/v0.4/Homebrew/deps/usr/Library/Taps/homebrew/homebrew-science'...
remote: Counting objects: 20983, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 20983 (delta 4), reused 0 (delta 0), pack-reused 20974
Receiving objects: 100% (20983/20983), 6.22 MiB | 1.34 MiB/s, done.
Resolving deltas: 100% (12421/12421), done.
Tapped 622 formulae (656 files, 8.0M)
INFO: Building LightXML
INFO: Building Metis
==> Installing metis from staticfloat/juliatranslated
==> Downloading https://homebrew.bintray.com/bottles-science/metis-5.1.0.el_capitan.bottle.1.tar.gz
Already downloaded: /Users/sabae/Library/Caches/Homebrew.jl/metis-5.1.0.el_capitan.bottle.1.tar.gz
==> Pouring metis-5.1.0.el_capitan.bottle.1.tar.gz
🍺  /Users/sabae/.julia/v0.4/Homebrew/deps/usr/Cellar/metis/5.1.0: 18 files, 12.2M
Warning: Already linked: /Users/sabae/.julia/v0.4/Homebrew/deps/usr/Cellar/metis/5.1.0

To return to an "untapped" configuration, you should be able to just run:
using Homebrew
Homebrew.rm("metis")
;brew untap homebrew/science

Note, I'm using metis instead of metis4, as the other dependencies in build.jl that I saw seemed to be fine with a metis 5 or newer.

;brew untap homebrew/science

untaps the tap that's unrelated to Julia (the one that's in /usr/local/Homebrew). Neither Homebrew.rm("homebrew/science") nor Homebrew.untap("homebrew/science") worked for me. I had to
$ cd ~/.julia/v0.5/Homebrew/deps/usr/
$ ./bin/brew untap homebrew/science

Then:
julia> Homebrew.tap_exists("homebrew/science")
false
julia> VERSION
v"0.5.0"

My project requires metis4 instead of metis but note https://github.com/JuliaSparse/Metis.jl/pull/21. Here's the relevant line: https://github.com/JuliaSmoothOptimizers/HSL.jl/blob/master/deps/build.jl#L20
Now (forgive the deprecation warnings):
julia> Pkg.build("HSL")
INFO: Building Homebrew
Updated Homebrew from 066cd46 to 09e0b09.
Updated 2 taps (homebrew/core, homebrew/versions).
==> Updated Formulae
antigen                                          homebrew/versions/libmongoclient-legacy
aws-sdk-cpp                                      imagemagick
fzf                                              ipfs
git-credential-manager                           khard
global                                           offlineimap
gupnp                                            reposurgeon
homebrew/versions/gnupg21                        sonar-runner
INFO: Building HSL
WARNING: `@osx_only` is deprecated, use `@static if is_apple()` instead
 in depwarn(::String, ::Symbol) at ./deprecated.jl:64
 in depwarn(::String, ::Symbol) at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 in @osx_only(::Any) at ./deprecated.jl:496
 in include_from_node1(::String) at ./loading.jl:488
 in include_from_node1(::String) at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 in evalfile(::String, ::Array{String,1}) at ./loading.jl:504 (repeats 2 times)
 in cd(::##6#8, ::String) at ./file.jl:59
 in (::##5#7)(::IOStream) at ./none:13
 in open(::##5#7, ::String, ::String) at ./iostream.jl:113
 in eval(::Module, ::Any) at ./boot.jl:234
 in eval(::Module, ::Any) at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 in process_options(::Base.JLOptions) at ./client.jl:239
 in _start() at ./client.jl:318
 in _start() at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
while loading /Users/dpo/.julia/v0.5/HSL/deps/build.jl, in expression starting on line 15
Error: No available formula with the name "metis4"
=========================================[ ERROR: HSL ]==========================================

LoadError: ArgumentError: `brew info` failed for String["metis4"]!
while loading /Users/dpo/.julia/v0.5/HSL/deps/build.jl, in expression starting on line 21

=================================================================================================

========================================[ BUILD ERRORS ]=========================================

WARNING: HSL had build errors.

 - packages with build errors remain installed in /Users/dpo/.julia/v0.5
 - build the package(s) and all dependencies with `Pkg.build("HSL")`
 - build a single package by running its `deps/build.jl` script

=================================================================================================

What am I doing wrong?
Thanks.

untaps the tap that's unrelated to Julia

That happens if you don't run using Homebrew beforehand, in order to setup the paths properly such that brew commands get sent to the Homebrew.jl brew executable, not the system-wide brew executable.
What you did is equivalent though, so no harm no foul.

julia> Homebrew.tap_exists("homebrew/science")
false

Now that is VERY interesting.  Could you do the following for me, and show me what it says:
julia> using Homebrew

shell> find $(Homebrew.brew_prefix) -name metis4.rb
/Users/sabae/.julia/v0.5/Homebrew/deps/usr/Library/Taps/homebrew/homebrew-science/metis4.rb

That happens if you don't run using Homebrew beforehand,

Whether I do using Homebrew beforehand or not, it's my /usr/local tap that disappears. Perhaps that has to do with the issue?! Do you also have Homebrew outside of Julia?
julia> using Homebrew

shell> find $(Homebrew.brew_prefix) -name metis4.rb
/Users/dpo/.julia/v0.5/Homebrew/deps/usr/Library/Taps/homebrew/homebrew-science/metis4.rb

Well, I think I found the problem.  It's ironic, really.  You have a few calls to Homebrew.prefix("metis4") inside HSL.jl's build.jl, which need to be Homebrew.prefix("homebrew/science/metis4").  Changing that gets past these Homebrew issues, but you really shouldn't need to manually calculate metis_libpath like that, or manually push!() onto Libdl.DL_LOAD_PATH.  All that should be taken care of by BinDeps.  I encourage you to look over, as an example, the Nettle.jl file that sets up BinDeps across multiple OS's.  First we declare a BinDeps dependency "object", that I call nettle, then I declare that Homebrew.jl can provide that object, and then the last thing I do is tell BinDeps to map the nettle dependency object to a concrete library variable name called nettle that I can use in my code by including deps.jl and then just directly using the nettle variable.
BinDeps will automatically find the libraries and store absolute paths to them in deps.jl.  On my OSX machine, my deps.jl for Nettle looks like this:
$ cat deps.jl
# This is an auto-generated file; do not edit

# Pre-hooks

# Macro to load a library
macro checked_lib(libname, path)
    ((VERSION >= v"0.4.0-dev+3844" ? Base.Libdl.dlopen_e : Base.dlopen_e)(path) == C_NULL) && error("Unable to load \n\n$libname ($path)\n\nPlease re-run Pkg.build(package), and restart Julia.")
    quote const $(esc(libname)) = $path end
end

# Load dependencies
@checked_lib nettle "/usr/local/lib/libnettle.dylib"

# Load-hooks

Thanks a lot for your help. I really appreciate your time.

You have a few calls to Homebrew.prefix("metis4") inside HSL.jl's build.jl, which need to be Homebrew.prefix("homebrew/science/metis4")

I think not because:
julia> Homebrew.prefix("homebrew/science/metis4")
"/Users/dpo/.julia/v0.5/Homebrew/deps/usr/Cellar/homebrew/science/metis4/4.0.3_1"

and that folder doesn't exist. Homebrew.prefix("metis4") returns the correct value.
I do need to compute that path because I subsequently must pass it to configure and I don't want it to pick up some other METIS library that might lie around (especially METIS 5).

Aha, here you have indeed found a bug in Homebrew.jl!  Congratulations.  PR fixing this running through tests, I'll merge it once CI passes, then I would ask you to Pkg.checkout("Homebrew") to get that fix, ensure that everything is "homebrew/science/metis4" (the Homebrew.prefix("homebrew/science/metis4") call should return the correct path this time), then continue and see if you get any farther.

Thanks. The only way I've found for Homebrew.jl to tap homebrew/science automatically is to add an explicit Homebrew.add("homebrew/science/metis4") before the provides() line. Otherwise, it just won't tap science.

So it's important to realize at what point Homebrew.jl is failing here; the buildscript is dying before we even get to BinDeps trying to install things.  It's dying because you still have a [Homebrew.prefix("metis4") toward the bottom of your build.jl file.  You should be able to see this by the line number that is reported in the backtrace that Julia's giving you.
I've merged the OSX fix because Travis is taking too long.  Go ahead and try it again, after making those changes.  FWIW, I'm still not able to build HSL.jl because of other errors in the file, namely you try to reference deps/downloads/hsl_ma97-2.3.0.tar.gz, which doesn't exist.
If you'd like general help in setting up your build.jl file, I would be happy to help you out, but I'll need a little explanation of everything you're trying to do.  :)

Oh, also, please remove the Homebrew.add("homebrew/science/metis4") on this line, it's going to cause you more trouble than good.  :)

Ok, thanks. Now it's working with prefix("homebrew/science/metis4"). It taps homebrew/science, installs metis4 and all. Many thanks for that. I removed the Homebrew.add line.
Is there going to be a new version tagged soon or are we just supposed to stick with master?

FWIW, I'm still not able to build HSL.jl because of other errors in the file, namely you try to reference deps/downloads/hsl_ma97-2.3.0.tar.gz, which doesn't exist.

See https://github.com/JuliaSmoothOptimizers/HSL.jl#hsl. The HSL isn't open source but must be downloaded manually and placed where indicated. That's why you can't build and why the build process is so complicated.

Since you offer, here's a question about another use of BinDeps and Homebrew. The question is in two parts:

On OSX, I gave up trying to get this to work: https://github.com/JuliaSmoothOptimizers/AmplNLReader.jl/blob/msys/deps/build.jl#L12. With your latest changes in master, asl is downloaded and poured, but only libmp is found. I can't get libasl to be recognized. However, if I brew install asl by hand (outside of Julia), it's recognized and all is well. I don't get it because the bottle is the same.

On Windows, the WinRPM for asl is outdated, so I'm trying to build from source under MSYS. BinDeps appears to recognize that it'll have to build from source but at Pkg.build time, it bails.

Debugging such issues is incredibly opaque (and frustrating) so any input would be welcome.
Thanks.

Updating WinRPM is going to be far, far easier than building from source. Building from source on Windows is going to fail on well over 90% of users' systems. Provide binaries. Where there are binaries already provided by an automated build service that aren't new enough, submit an update request. Doing so on the opensuse build service is about as easy as doing it for homebrew.

Is there going to be a new version tagged soon or are we just supposed to stick with master?

I tend to tag new versions pretty frequently, expect one sometime around this weekend, just so we can make sure everything is working as it should be.

Debugging such issues is incredibly opaque (and frustrating) so any input would be welcome.

100% agreed, which is why I offered my help.  :)
I'll take a look at problem 1 later (we should definitely be able to accommodate that), but problem 2 is something that isn't going to be solved very easily on most user's hardware.  I would highly suggest working with upstream to get newer WinRPM versions of asl.

Just to verify before you submit the update request, asl doesn't change all that much over time, but the new version that you want to use should be backwards-compatible in terms of uses in Ipopt, Bonmin, etc, right?

Users shouldn't have to build from source. I'm just asking Appveyor to do it. So far I've found it much easier to ask Appveyor to build from source using MSYS than to do anything on OpenSUSE, which seems quite opaque to me. If you know how to do it, I'd really appreciate if you could bump asl. Yes, I think it should be backwards compatible. The changes I need for AmplNLReader are only related to the so-called simplified interface.

What have you tried? I don't want to be the only person who knows how to do this. It's not hard, I'd rather teach additional people how to do it. You register for an account, find the package, click branch, edit the spec file for your branched personal copy and replace the uploaded tarball with the new version, then submit an update request. If you make the changes, point me to your personal project branch and I can double-check that they look good before you open the change request, if you'd like. The same process needs to be done twice for 32 bit and 64 bit, but it's the exact same steps so will be easier the second time.
Building from source only on appveyor via BinDeps then trying to have users download the artifacts from that will be error-prone. Exactly which toolchain are you using on AppVeyor, etc. You need to be careful.

Here's what I attempted some months ago and eventually gave up on: https://build.opensuse.org/project/show/home:dpo:branches:windows:mingw:win64

@staticfloat I agree binaries are better, but why isn't BinDeps recognizing that it should build from source? Is that an MSYS oddity?

Windows machines are so incredibly unlikely to be configured properly to build from source, that we don't even try by default (Note how BuildProcess is not included in the default priority list of providers on Windows).

looks like @vitaut added a few new checks to the cmake, that it can't guess the results for when cross compiling. If you've done an msys build anywhere, look in the log for the results of the checks and add a few more flags to the cmake call in the spec file. The service download thing on obs is also a little odd, better to download the actual tarball as a file and upload that.

I understand but MSYS should provide an environment that's very similar to a Unix toolset. For example, I got PROPACK to build properly with gfortran: https://ci.appveyor.com/project/dpo/propack-jl (though not using BinDeps).
Is there a way to ask BinDeps nicely to build from source? Can I add to BinDeps.defaults?

Yes, you can push!() onto BinDeps' list, but I do agree with @tkelman that absolutely the best way to do this is to request a new WinRPM version.

Ok, ok ;-)

msys is rarely installed for users. and which specific mingw toolchain variant you use is very important for ABI compatibility with Julia. msys also happens to be a path mangling hack that only exists to pretend you aren't cross compiling. actually cross compiling works well and lets you build from a real unix system instead of going through a slow windows-specific emulation layer.

I also agree but my aim for the time being is to build and test, not to package artefacts and distribute them.

I resolved the problem with bottled asl. It was an rpath issue. Now Homebrew.jl pours the bottle on OSX ≥ 10.10 and all is well.  I can't get ASL to build with either MSYS or MS Studio. I opened https://github.com/ampl/mp/issues/107.


chore: removes EmptyBlock in favour of XEmptyState

Moves our EmptyBlock component to be called XEmptyState (part of our global x module).
Also adds docs and corrects a few missing semantic HTML elements.
(I found an unused file src/app/services/views/ServiceConfigView.vue during this work so deleted it here)

Just a quick note, there is other work that this will clash with if I merge this now. As its a refactor I'd rather wait until the other work has gone in, shouldn't be too long now.


⚠ Bofrost.at has degraded performance

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

HTTP code: 200
Response time: 2416 ms

Resolved: Bofrost.at performance has improved in b222c62.


Find (instead of get) permission required when including relational data

Correct me if I'm wrong, but I think only get permission were required on a class before when including relational data. With Parse Server find permission is needed.
var query = new Parse.Query(Post);
// In Parse Comment only needed public get class level permission.
// In Parse Server find is required.
query.include("comments");

Are include queries supposed to require find permission? Personally I think it would make more sense to only require get.

Further testing showed that I was wrong on my premise that get permission only was required in parse.com. It was the user session that didn't work correctly in my case.


Sync with Upstream

This pull request updates the fork to match the latest changes from the upstream repository.

triggered by ODH/CFO release, closing


only use the required lodash components

Only include the lodash components that are actually used
Builds on #5 and improves it

@finneganh this PR not resolve the issue link ?

@EmilioAiolfi and @eddiemonge It seems to solve the issue

Pretty sure that this wouldn't solve any bundle size issues as now the 4.x lodash modules may be coming from different places.
I maintain that in a correctly-functioning build setup the current use of lodash 3 should not cause a problem.


Add header with image and TOC similar to zivid-python

Draw inspiration from https://github.com/zivid/zivid-python. However, when updating the image in  https://github.com/zivid/zivid-python it was noted that we should have a system that is easier to maintain. I propose to implement what was proposed in https://github.com/zivid/zivid-python/issues/111#issuecomment-758475065.

Thx for updating this. I see that https://github.com/zivid/zivid-ros maintained by @apartridge is still using the old image. I have also proposed to @zivid/customer-success that they add headers with images and TOC to their repositories.
I propose to place the image at a static URL, for example, https://www.zivid.com/hubfs/softwarefiles/images/zivid-generic-github-header.png. Then marketing can maintain that image and all repositories are updated automatically.
@SatjaSivcev can you implement this system when you add a header to all your repositories, and also make a PR to https://github.com/zivid/zivid-python and https://github.com/zivid/zivid-ros?

Fixed in #155

Fixed in #155

I see you did not do the TOC menu part like we have in https://github.com/zivid/zivid-python and https://github.com/zivid/zivid-ros. Can you elaborate on why? Fine if you don't want it, just curious.

I see you did not do the TOC menu part like we have in https://github.com/zivid/zivid-python and https://github.com/zivid/zivid-ros. Can you elaborate on why? Fine if you don't want it, just curious.

I missed that. Will do.

I missed that. Will do.


Update the patches to llvm8

thanks!
I'll merge just before we update to LLVM 8

oops nevermind, I didn't notice this was to my branch, merging now


lsps2: match payment_size_msat minimum

Small nit: The minimum payment_size_msat is smaller than or equal to the fee + htlc_minimum_msat. A forward of exactly htlc_minimum_msat is eligible for forward as well.

ACK


Update to new paper version

😲 what's new in v2?
btw, I think we resolved your lion issue! https://github.com/lucidrains/lion-pytorch/issues/24

I'm not sure, but the pdf link on v1 was giving me errors and hanging and I noticed this link.

btw, I think we resolved your lion issue! https://github.com/lucidrains/lion-pytorch/issues/24

Thanks. Training lots of models soon. I'll give it a try


refactor: exclude encoding of reading state results in chain extension

Because we funnelled the read state functions through read_state on the contract size the result had to be raw bytes, therefore encoded on the runtime and decoded in the contract. The read state functions are now called specifically and therefore the result can be its type (e.g. Balance). By refactoring it prevents the pop api having to decode the read state results which can decrease the contract size.
With the current contract it decreases it from 7.1K to 6.8K (don't compare with the psp22 contract as the logic implemented is not equal).
In stead of:
fn read_fungibles_state<T, E>(
	key: Keys<T>,
	env: &mut Environment<E, BufInBufOutState>,
) -> Result<Vec<u8>, DispatchError>
where
	T: pallet_contracts::Config
		+ pallet_assets::Config<TrustBackedAssetsInstance, AssetId = AssetId>
		+ fungibles::Config,
	E: Ext<T = T>,
	T: frame_system::Config<AccountId = sp_runtime::AccountId32>,
{
	env.charge_weight(T::DbWeight::get().reads(1_u64))?;
	match key {
		TotalSupply(id) => Ok(fungibles::Pallet::<T>::total_supply(id).encode()),
	}
	...
}

We do:
fn read_fungibles_state<T, E>(
	key: Keys<T>,
	env: &mut Environment<E, BufInBufOutState>,
) -> Result<(), DispatchError>
where
	T: pallet_contracts::Config
		+ pallet_assets::Config<TrustBackedAssetsInstance, AssetId = AssetId>
		+ fungibles::Config,
	E: Ext<T = T>,
	T: frame_system::Config<AccountId = sp_runtime::AccountId32>,
{
	env.charge_weight(T::DbWeight::get().reads(1_u64))?;
	match key {
		TotalSupply(id) => env.write(&fungibles::Pallet::<T>::total_supply(id), false, None),
	}
	...
	Ok(())
}

Closed by #122


translations are not being updated on disabled elements

Hi,
We have buttons that are disabled by default; and only enable when the form is valid and ready for submission.  When the user changes the language, all content is correctly refreshed, but the caption on the button remains unchanged.  This only occurs when the button is disabled.
Is this a known issue?  I'm guessing this is caused by browser behaviour not allowing for ANY update on disabled elements, but maybe we should build in an option to temporarily enabled when angular-translate updates the translated caption, and re-disable right after that?  I'm guessing it might cause flickering, but not having it translated seems even worse to me.
THanks for considering :-)
David.

To add to this.  It seems to be only occuring in MacOS Safari.

@denjaland  Please prepare a working demo of this issue.. i.e. in plnkr. Which version of Safari is affected?

I'll dig into that asap.

friendly reminder: @denjaland any update?

Demo is here, I don't see an issue. http://plnkr.co/edit/ueNaUBOXje7Qx60IMBMJ?p=preview
Closed due inactivity.

sorry - I lost sight of this issue.  It can be closed as you did though.


ci: remove not needed workflow

This PR removes not needed golang workflow.
This change will optimize github actions runtime.
Thanks to this line the file I just removed will not be created here by bot again.

Yaaaayyy! 🎉 Congratulations on your first contribution, Karina! 🙌

/rtm


Added logo

fixes issue:#23

fixes issue:#23
U have done great job,
But can you try something else unique
Also we looking for new namee so you don't need
To follow the same logo as name of site,  it can be any design

Please review it.

@geetika005

Yes i am working on it

i am unable to see home.css file in the real repository because i think someone is working on it but earlier it was there so now should i just commit the logo image ?

I have uploaded the new logo image sir and deleted the css file as the home page is not ready yet


Bug Function app.getTakerFee()

Describe the bug
The bot was fine. When the purchase signal was given, the error appeared in the app.getTakerFee () function
To Reproduce
2021-05-24 21:41:00 | ETHUSDT (BULL) | 1m | Close: 2621.5 | v EMA12/26: 2639.9644 < 2640.1743 v | v MACD: -0.2099 < 0.7311 v | v OBV: -1051.5205 (-170.1500%) v | ERI: sell | WAIT | Last Action: BUY | -1.0295% (delta: -24.62)
support: 2603.24, resistance: 2624.26, fibonacci (l): 2618.96, fibonacci (u): 2641.62
2021-05-24 21:42:00 | ETHUSDT (BULL) | 1m | Close: 2589.55 | v EMA12/26: 2632.2083 < 2636.4244 v | v MACD: -4.2161 < -0.2583 v | ^ OBV: -5643.2519 (436.68%) ^ | ERI: sell | WAIT | Last Action: BUY | -2.2357% (delta: -56.57)
support: 2575.0, resistance: 2603.24, fibonacci (l): 2567.49, fibonacci (u): 2596.3
KeyError('success')
Traceback (most recent call last):
File "pycryptobot.py", line 1048, in main
runApp()
File "pycryptobot.py", line 1041, in runApp
executeJob(s, app, state, trading_data)
File "pycryptobot.py", line 996, in executeJob
executeJob(sc, app, state, trading_data)
File "pycryptobot.py", line 996, in executeJob
executeJob(sc, app, state, trading_data)
File "pycryptobot.py", line 996, in executeJob
executeJob(sc, app, state, trading_data)
[Previous line repeated 134 more times]
File "pycryptobot.py", line 337, in executeJob
state.last_buy_fee = round(state.last_buy_size * app.getTakerFee(), 8)
File "C:\bot\models\PyCryptoBot.py", line 535, in getTakerFee
return api.getTakerFee(self.getMarket())
File "C:\bot\models\exchange\binance\api.py", line 132, in getTakerFee
fees = self.getFees(market)
File "C:\bot\models\exchange\binance\api.py", line 97, in getFees
resp = self.client.get_trade_fee(symbol=market)
File "C:\Users\Felipe\anaconda3\lib\site-packages\binance\client.py", line 2169, in get_trade_fee
if not res['success']:
KeyError: 'success'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "pycryptobot.py", line 1086, in
main()
File "pycryptobot.py", line 1064, in main
runApp()
File "pycryptobot.py", line 1041, in runApp
executeJob(s, app, state, trading_data)
File "pycryptobot.py", line 996, in executeJob
executeJob(sc, app, state, trading_data)
File "pycryptobot.py", line 996, in executeJob
executeJob(sc, app, state, trading_data)
File "pycryptobot.py", line 996, in executeJob
executeJob(sc, app, state, trading_data)
[Previous line repeated 2 more times]
File "pycryptobot.py", line 346, in executeJob
sell_taker_fee=app.getTakerFee(),
File "C:\bot\models\PyCryptoBot.py", line 535, in getTakerFee
return api.getTakerFee(self.getMarket())
File "C:\bot\models\exchange\binance\api.py", line 132, in getTakerFee
fees = self.getFees(market)
File "C:\bot\models\exchange\binance\api.py", line 97, in getFees
resp = self.client.get_trade_fee(symbol=market)
File "C:\Users\Felipe\anaconda3\lib\site-packages\binance\client.py", line 2169, in get_trade_fee
if not res['success']:
KeyError: 'success'
(base) C:\bot>]
Screenshots

Desktop (please complete the following information):

Windows 10
Python 3.7.8

Can you confirm what version of python-binance you are using?
It should be 0.7.9
% python3 -m pip freeze | grep binance
python-binance==0.7.9
There is a breaking change in the latest version of the library.

I have version 0.7.9.
Which one would be correct?

I am having this one too but only for simulator.

I removed getTakerFee in the Binance api.py file and it worked

Another problem was that my operating system clock was out of sync. So I synchronized and now everything works fine

Thanks, I'll add some code to handle that error in getTakerFee more gracefully. Otherwise is this resolved?

for me it's solved.....bot running normally

Thanks should be fixed now. I put an additional check for that missing 'success' key as well.


Db workflowversion hotfix expr

locally working fix for https://github.com/dockstore/dockstore/issues/3252
introduces constraints
will need further testing to make sure we're not deleting too much when introducing constraints
will need further testing to see whether refresh/hosted workflows/upsert still functions as expected
will need to test adding aliases (seemed to be missing tests for unit tests for one set of methods)

Note to self: rats, services

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

Complexity increasing per file
==============================
- dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

Complexity increasing per file
==============================
- dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

Complexity increasing per file
==============================
- dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

See the complete overview on Codacy


feat(Pointwise): monotonicity of pow

... and s ^ n = ∅ ↔ s = ∅ ∧ n ≠ 0
From GrowthInGroups

[x] depends on: #19249

What about now?


Figure out issues with Travis CI automated tests

When running the tests, some pass and some don't.  Same thing happens at home, however after a few tries, they all work.  There's probably some limits being hit.

It appears that I was sending requests a little too quickly.  I slowed down the test by adding hard waits into the test code.  There are a few times it still does it too fast, but re-running the test online will fix the issue typically.


Add time.Time type convert to clickHouse Date type #20 issue

Coverage increased (+0.02%) to 96.569% when pulling b0e509ebd8485e13115355c0dd5f2af46f0a08db on Xsikor:master into 83cdea998525dba85dd89db03e64d9a5b4a50d0d on roistat:master.


📝 Fix documentation

🔥 Remove docs autobuilding
📝 Generate current API Reference

Codecov Report

Merging #49 (6be9d00) into master (75f74d0) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #49   +/-   ##
=======================================
  Coverage   96.07%   96.07%
=======================================
  Files           8        8
  Lines         561      561
=======================================
  Hits          539      539
  Misses         22       22

Continue to review full report at Codecov.

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