NoMethodError after clean project generation

After generating a new dashing project, I get the below error.
I can still run dashing start on my older projects and they all still work fine.
Here's the error on the link:

Below is the error thrown my by terminal:
2015-06-18 19:30:55 - NoMethodError - undefined method `mappings' for Tilt:Module:
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/dashing-1.3.2/lib/dashing.rb:151:in `tilt_html_engines'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/dashing-1.3.2/lib/dashing.rb:69:in `block in <top (required)>'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1610:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1610:in `block in compile!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `[]'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `block (3 levels) in route!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:993:in `route_eval'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `block (2 levels) in route!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1014:in `block in process_route'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1012:in `catch'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1012:in `process_route'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:972:in `block in route!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:971:in `each'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:971:in `route!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1084:in `block in dispatch!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `block in invoke'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `catch'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `invoke'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1081:in `dispatch!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:906:in `block in call!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `block in invoke'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `catch'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `invoke'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:906:in `call!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:894:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.2/lib/rack/logger.rb:15:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.2/lib/rack/commonlogger.rb:33:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:218:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:211:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.2/lib/rack/head.rb:13:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.2/lib/rack/methodoverride.rb:22:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/show_exceptions.rb:21:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:181:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:2021:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1486:in `block in call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1795:in `synchronize'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1486:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.2/lib/rack/urlmap.rb:66:in `block in call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.2/lib/rack/urlmap.rb:50:in `each'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.2/lib/rack/urlmap.rb:50:in `call'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/connection.rb:86:in `block in pre_process'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/connection.rb:84:in `catch'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/connection.rb:84:in `pre_process'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/connection.rb:53:in `process'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/connection.rb:39:in `receive_data'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/eventmachine-1.0.7/lib/eventmachine.rb:187:in `run_machine'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/eventmachine-1.0.7/lib/eventmachine.rb:187:in `run'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/backends/base.rb:73:in `start'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/server.rb:162:in `start'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/controllers/controller.rb:87:in `start'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/runner.rb:200:in `run_command'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/lib/thin/runner.rb:156:in `run!'
	/Users/nii236/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/thin-1.6.3/bin/thin:6:in `<top (required)>'
	/Users/nii236/.rbenv/versions/2.2.1/bin/thin:23:in `load'
	/Users/nii236/.rbenv/versions/2.2.1/bin/thin:23:in `<main>'

It works fine for me when I freshly install Dashing in my Mac.
Please direct support requests to the Stack Overflow tag.

Did exactly the same thing today, and it started working.
I'll head over to SO if it happens again.

interestingly enough i run into the same issue, so i removed the project and generated a new one what just worked.

@b1nary, yeah not sure what causes it. If it comes up again and is repeatable I'll try and document it properly here.

ran into this and it seems to be a dependency conflict. I fixed by clearing out vendored gems, updating the bundle, and ensuring dashing-1.3.4 was the version being used. Somehow one of my gems that had thor .18.X locked was causing dashing-1.3.2 to be installed.


feat(patterns): add proper messages for the raised NoMatchErrors

NoMatchError exception is used to indicate an early return from a matching stack. Currently they are just raised without any message, but all the matchers should provide a concise and cheap description.

Resolved by https://github.com/kszucs/koerce/issues/9


condexpr type resolution + null ptr cast + some tests

Adds a new implicit cast type qual_cast for implicit casts due to mismatching pointers on conditional expressions
Adds a new implicit cast type null_to_pointer to convert 0 to a pointer of appropriate type
Adds a way to test expression types.

Thanks! This doesn't yet handle decayed array types but fixing that is a bit more involved so it can be done separately.

Ah, I misunderstood your comment about rebasing. I can take a look at that over the weekend.

No worries, here's a small test case.
void foo(void) {
    int a[3], b[3], c[4];
    (1 ? a : b)[4];
    (1 ? a : c)[5];
}

Clang and gcc won't complain about the out-of-bounds access on the first one but I don't see a reason why we shouldn't give a warning if we have the information like we also do with parameters:
void foo(int foo[2]) {
    foo[3]; // clang and gcc won't complain about this, but we should since the user bothered to give us a size
}


ERROR: Unexpectedly found nil while unwrapping an Optional value

When running on iOS 9.2 on iPhone 6 I randomly get an unwrapping error at line 252. I can see from debug that my image is passed into the completion handler but it would appear that self.biggestRectangle can return nil. Any suggestions?

I am having a similar problem with iOS 9.1 on iPhone 6s.

will the issue be fixed if you replace line 252 with this code?
completion(image: image, feature: self.biggestRectangle(SobrCameraView.highAccuracyRectangleDetector.featuresInImage(enhancedImage) as! [CIRectangleFeature]))

I'm having the same unwrapping error at line 252. But with katunch's fixed line it works till now. Btw. katunch, superb work!

Is it possible to do a version bump for this fix?

Did a version bump to cocoa pods


Server wide banners

We run some on-premise ADO Servers with many collections. Today we use the banner extension to inform users about events like upcoming service, tips and other stuff.
When doing this on a server with 20+ collections and you need to publish the same banner in all collections it would be very nice to have an option to publish the banner once for all collections in the server.

Great suggstion! I think this is pretty low priority for us since the vast majority of our customers are Azure DevOps Services users, but if you would like to implement this I will definitely approve the changes.

I agree with the original poster, it would be great to be able to publish to all collections at once.
Or if the banner setting could be programed by API and it could be scripted to push to each or all collections.


build for mipsle failed

CC=mips-linux-musl-gcc CXX=mips-linux-musl-g++ CGO_ENABLED=1 GOOS=linux GOARCH=mipsle GOMIPS=softfloat  go build -ldflags="-s -w" main.go
How can i build for little endian?Thank you!
If i change "GOARCH=mipsle" To "GOARCH=mips" is ok, but my target is little endian~
Originally posted by @hongjinlin in https://github.com/mattn/go-sqlite3/issues/384#issuecomment-490831876
command-line-arguments
/usr/local/Cellar/go/1.11.2/libexec/pkg/tool/darwin_amd64/link: running mips-linux-musl-gcc failed: exit status 1
/usr/local/Cellar/musl-cross/0.9.7_1/libexec/bin/../lib/gcc/mips-linux-musl/6.3.0/../../../../mips-linux-musl/bin/ld: /var/folders/1q/3d6q6x2s6057s6fgwdxr7ffw0000gn/T/go-link-651072203/go.o: compiled for a little endian system and target is big endian
/usr/local/Cellar/musl-cross/0.9.7_1/libexec/bin/../lib/gcc/mips-linux-musl/6.3.0/../../../../mips-linux-musl/bin/ld: /var/folders/1q/3d6q6x2s6057s6fgwdxr7ffw0000gn/T/go-link-651072203/go.o: endianness incompatible with that of the selected emulation
/usr/local/Cellar/musl-cross/0.9.7_1/libexec/bin/../lib/gcc/mips-linux-musl/6.3.0/../../../../mips-linux-musl/bin/ld: failed to merge target specific data of file /var/folders/1q/3d6q6x2s6057s6fgwdxr7ffw0000gn/T/go-link-651072203/go.o
collect2: error: ld returned 1 exit status

MacOS Majove 0.14.4 (18E226)
go version go1.11.2 darwin/amd64
go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hongjinlin/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hongjinlin/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.2/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1q/3d6q6x2s6057s6fgwdxr7ffw0000gn/T/go-build079041265=/tmp/go-build -gno-record-gcc-switches -fno-common"

I'm not very familiar with mips, but are you sure you are using the right C compiler? From what I can find it sounds like you are supposed to be using mipsel-linux-musl-gcc instead.

I'm not very familiar with mips, but are you sure you are using the right C compiler? From what I can find it sounds like you are supposed to be using mipsel-linux-musl-gcc instead.

https://github.com/mattn/go-sqlite3/issues/384#issuecomment-433584967
I use this tool , i also can not found, it is my also my question
brew install FiloSottile/musl-cross/musl-cross --with-mipsel

@hongjinlin Please do CC=mipsel-linux-musl-gcc instead. (You don't actually have to set CXX so that part can be removed.)

@rittneje I have tried "https://github.com/richfelker/musl-cross-make" this tool before,but build failed on my mac ,i have used ql database instead.Thank you very much!


Orange Dots for friends arent showing on the map

Not sure how to ad dthis to the other persons issue on this but I am having it as well since the 6.4 update.
Can only see FC markers but not friends even with the priorities set.

Same, and I was wondering if I was going crazy or not

Fixed in 34e7f2361a5b901441527c75b54db8af772a0aeb I believe


Change the name of a faction

Is your feature request related to a problem?
I cannot rename factions.
Describe the solution you'd like.
A command like /f name [NEW NAME] to rename a faction.
Describe alternatives you've considered.
To rename a faction you currently have to leave it, lose all claimed chunks and have to create a new one...very cumbersome....
Agreements

[X] I have searched for and ensured there isn't already an open issue regarding this.
[X] I have ensured the feature I'm requesting isn't already in the latest supported mod version.

Other
No response

I like this idea. I'll close this issue and it can be further discussed in #46


Change Mediatype to v2

Update oras version from 0.12.0 to 0.16.0
Change media type of image from application/vnd.oci.image.manifest.v1+json to application/vnd.docker.distribution.manifest.v2+json

Abandon this changes.


✨ add link

@YounesBessa
Cloning github.com/tonightpass/kitchen (Branch: younesbessa/link, Commit: 962ef0e)
--
13:45:42.026 | Cloning completed: 308.785ms
13:45:49.348 | Restored build cache
13:45:49.402 | Running "vercel build"
13:45:50.064 | Vercel CLI 28.5.6
13:45:50.534 | Running "install" command: `cd ../../packages/kitchen; yarn link; cd ../../examples/next-typescript; yarn link @tonightpass/kitchen; yarn install`...
13:45:50.908 | yarn link v1.22.17
13:45:50.926 | warning package.json: No license field
13:45:50.945 | warning package.json: No license field
13:45:50.948 | success Registered "@tonightpass/kitchen".
13:45:50.949 | info You can now run `yarn link "@tonightpass/kitchen"` in the projects where you want to use this package and it will be used instead.
13:45:50.949 | Done in 0.05s.
13:45:51.181 | yarn link v1.22.17
13:45:51.220 | success Using linked package for "@tonightpass/kitchen".
13:45:51.220 | Done in 0.05s.
13:45:51.511 | yarn install v1.22.17
13:45:51.629 | [1/4] Resolving packages...
13:45:52.345 | success Already up-to-date.
13:45:52.348 | Done in 0.84s.
13:45:52.364 | Detected Next.js version: 13.0.2
13:45:52.365 | Running "cd ../..; yarn build; cd ./examples/next-typescript; yarn build"
13:45:52.716 | yarn run v1.22.17
13:45:52.756 | $ preconstruct build
13:45:53.444 | 🎁 info building bundles!
13:46:02.897 | 🎁 success built bundles!
13:46:02.931 | Done in 10.22s.
13:46:03.310 | yarn run v1.22.17
13:46:03.350 | $ next build
13:46:04.044 | info  - Linting and checking validity of types...
13:46:09.430 |
13:46:09.431 | ./pages/_document.tsx
13:46:09.431 | 11:11  Warning: Using `<link />` outside of `<Head>` will disable automatic font optimization. This is discouraged. See: https://nextjs.org/docs/messages/no-page-custom-font  @next/next/no-page-custom-font
13:46:09.432 | 15:11  Warning: Using `<link />` outside of `<Head>` will disable automatic font optimization. This is discouraged. See: https://nextjs.org/docs/messages/no-page-custom-font  @next/next/no-page-custom-font
13:46:09.432 |
13:46:09.433 | info  - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules
13:46:12.528 | Failed to compile.
13:46:12.529 |
13:46:12.529 | ./pages/link.tsx:78:26
13:46:12.529 | Type error: No overload matches this call.
13:46:12.530 | Overload 1 of 2, '(props: { slot?: string; style?: CSSProperties; title?: string; children?: ReactNode; as?: ElementType<any>; defaultChecked?: boolean; defaultValue?: string \| number \| readonly string[]; ... 253 more ...; href?: string; } & { ...; } & { ...; }): ReactElement<...>', gave the following error.
13:46:12.531 | Type '"primary"' is not assignable to type '"secondary" \| "highlight" \| "blend"'.
13:46:12.531 | Overload 2 of 2, '(props: StyledComponentPropsWithAs<({ as: Component, href, id, className, disabled, onClick, variant, children, ...props }: LinkProps) => Element, DefaultTheme, { as?: ElementType<any>; children?: ReactNode; } & HTMLAttributes<HTMLElement> & { ...; }, never, ({ as: Component, href, id, className, disabled, onClick, variant, children, ...props }: LinkProps) => Element, ({ as: Component, href, id, className, disabled, onClick, variant, children, ...props }: LinkProps) => Element>): ReactElement<...>', gave the following error.
13:46:12.531 | Type '"primary"' is not assignable to type '"secondary" \| "highlight" \| "blend"'.
13:46:12.531 |
13:46:12.532 | 76 \|           }}
13:46:12.532 | 77 \|         >
13:46:12.532 | > 78 \|           <Link href="/" variant="primary">
13:46:12.532 | \|                          ^
13:46:12.532 | 79 \|             Primary variant
13:46:12.533 | 80 \|           </Link>
13:46:12.533 | 81 \|           <Link href="/" variant="secondary">
13:46:12.571 | error Command failed with exit code 1.
13:46:12.571 | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
13:46:12.598 | Error: Command "cd ../..; yarn build; cd ./examples/next-typescript; yarn build" exited with 1

 # should not open a new window

It doesn't look like that anymore, now I replaced this example with the internal and external href examples and now external hrefs open in new tabs but internal hrefs don't (just like you did in https://next-link-with-typescript.vercel.app/ (https://github.com/onRuntime/next-link))


Pushing needed SPO PowerShell edits live

Pushing needed SPO PowerShell edits live

Docs Build status updates of commit 941fe15:
:clock10: Full build: the average full build time is 17 min(s) 42 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 941fe15:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Enable-SPOCommSite.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Add meta and link tags for social media and icons

Can you please explain the task so that I can be of some help.

Hi @theprogrammerinyou. Thanks for your interest, however, I am closing this issue.
Check out this article for background information on what the issue was related to.


write it first

Dear Zipline Maintainers,
Before I tell you about my issue, let me describe my environment:
Environment

Operating System: (Windows Version or $ uname --all)
Python Version: $ python --version
Python Bitness: $ python -c 'import math, sys;print(int(math.log(sys.maxsize + 1, 2) + 1))'
How did you install Zipline: (pip, conda, or other (please explain))
Python packages: $ pip freeze or $ conda list

Now that you know a little about me, let me tell you about the issue I am
having:
Description of Issue

What did you expect to happen?
What happened instead?

Here is how you can reproduce this issue on your machine:
Reproduction Steps

...
What steps have you taken to resolve this already?
...
Anything else?
...
Sincerely,
$ whoami

Hi @shidinghong !  Given only the title of this issue, it's hard for us to know what to do or fix.  If you could explain a bit more, we'd be happy to look into the question or share our thoughts.  I'm going to close this for now, but feel free to re-open with more information!


proof of concept: decoupling of dispatching and transducers

This attempts to provide a solution to the situation described in https://github.com/ramda/ramda/issues/2083.
The idea is to have a ramda-core in which each function provides a core set of features that can be imported and composed to build additional features from there. This way, there can be how many different flavors of ramda-like libraries you would want.
The current PR takes the map function as an example. Like so, each function takes a (dispatcher, config, dispatchable, however you want to call it) which takes the core features which the core function provides and builds from there. The new map core function showed would only map over native arrays and objects. Then there are two different dispatchers: one adds all the rest of the features that the current ramda/map has and the other one does not (it does not support transducers, currying with placeholders or function composition via map) while providing additional functionality (dispatches to fantasy-land first and then to the map method).
This way you would import (from npm or repo) all the functions in ramda-core, partially apply them with the functionality you want and publish it. In the example provided I would publish a "ramda-fantasy-light" package or something like that. You could publish a flavor which only dispatches to fantasy-land methods (call it "ramda-dictatorship") or another one that dispatches to the method as is (call it "ramda-anarchy"). You could, as well, take the opportunity provide maybe/either wrapped functions and/or add some monads implementations or whatnot for a comprehensive fp toolbox.
Also, it would make more sense to publish individual lightweight functions a la lodash (eg: "ramda.filter").
All in all, I hope, would make ramda more focused, flexible, faster and shareable.
PS:

Although I've not read all of the source code to guarantee that all the transducer and default currying can be decoupled without major issues, I'm optimistic.
Some test of external functions may fail probably because I hardcoded (temporarily as a proof of concept) a piece of transducer dispatch (commented in code).

Disclaimer: I'm a Sanctuary contributor.
@rickmed, have you considered using sanctuary-type-classes as the "core"? It provides functions which dispatch to fantasy-land/-prefixed methods, and lawful implementations of methods such as Array#fantasy-land/map, Object#fantasy-land/map, and Function#fantasy-land/map.
Adding this dependency would allow us to remove hundreds of lines of code from Ramda, and would allow Ramda and Sanctuary to share a well-designed and well-tested core.

@davidchambers I have. I really like sanctuary and thought hard about how ramda and sanctuary could share a code base. In my ideal world they would. But considering the recurring theme in this issue (don't enforce features to users, but provide a frictionless as possible environment to provide them, which I believe it goes in line with ramda's philosophy, there would be these issues (please correct me where I'm wrong about sanctuary-type-classes):

Dependencies: sanctuary-type-classes functions depend on sanctuary-type-identifiers and other internal pieces of code. I understand they build up to the type checking system in sanctuary but that is a feature people may not want/need. Also, would make less sense to publish them individually (more below).

Dispatch: again, dispatching to fantasy-land is a feature people may not want/need.

Regarding 1 and 2. Would send us back to the eternal discussions about type checking at runtime at dispatch mechanisms.
3.Performance: consider Arrayfilter and ArrayMap. AFAIK sanctuary-type-classes dispatches to the  array's method. Ramda implements this filter and this map. I assume the latter are more performant.
More importantly, if you ask me, that is exactly the ramda's position in the js world. Those two algorithms are good, performant, independent and lightweight pieces of code. As a made the PR, I took a look at lodash's fp version. It made me curious why they it doesn't have individual functions published as for the OO versions. They problem is that they weren't coded for immutability from the get go, so they need to pass to a converter, which make them impractical to publish them.
The curried versions of this PR's filter and map (for arrays and objects) would be around 15-20 loc. Compose, pipe, curry, lift, etc much less. For a user just using promises, she can download a few of these to compose them and build super powerful pipelines -enabling her into fp.
Back to ramda-sanctuary-type-classes, there would be other issues like the monolithic index.js that I think would be secondary. So why not the other way around? sanctuary-type-classes to use ramda-core and build functionality from there as desired.

I will have to look at this a lot more closely later.
As to the concepts, I really like the idea of separating out the transducers code; it adds a great deal of weight to the codebase and although there is a lot of potential there, I don't think it's lived up to its promise so far.
I'm far less convinced about the dispatching and about separating the currying with placeholders.  I'm also concerned by the possible combinatorial explosion of Ramda versions.
But I recently returned to an earlier experiment that might address certain implementation and performance concerns about many of these things -- everything, in fact, except the transducers.  I've been much slower than I'd like with this metadata approach.  (My main computer has developed some issues at the same time I've had to replace three major household appliances in a few weeks.  So I haven't fixed it, and finally resorted to using an ancient machine.)  But I'm relatively happy with these basic ideas, and might like to combine some of them with what you're suggesting.  I won't be ready for at least a week, though, and I don't want to slow down what you're doing.  This is very interesting.

sanctuary-type-classes functions depend on sanctuary-type-identifiers and other internal pieces of code.

True, but sanctuary-type-identifiers is tiny. This is all there is to it:
//  type :: Any -> String
function type(x) {
  return x != null &&
         x.constructor != null &&
         x.constructor.prototype !== x &&
         typeof x.constructor['@@type'] === 'string' ?
    x.constructor['@@type'] :
    Object.prototype.toString.call(x).slice('[object '.length, -']'.length);
}

As for "internal pieces of code", at least 90% is necessary to support the exported functions. Less than 10% (I estimate) is dedicated to the TypeClass values such as Z.Functor exported for use with sanctuary-def.

dispatching to fantasy-land is a feature people may not want/need

In that case sharing code is more challenging. We could at least share the implementations of Array.map, Object.map, Function.map, etc.

AFAIK sanctuary-type-classes dispatches to the array's [map] method.

It does. Here's the current implementation:
//  Array$prototype$map :: Array a ~> (a -> b) -> Array b
function Array$prototype$map(f) {
  return this.map(function(x) { return f(x); });
}

If there's a performance benefit to an imperative implementation, we can easily update this. I'd love to see a pull request for this. :)

So why not the other way around? sanctuary-type-classes to use ramda-core and build functionality from there as desired.

sanctuary-type-classes is far more modular than Ramda. Compare the map implementations:
function map(f, functor) {
  return Functor.methods.map(functor)(f);
}

var _curry2 = require('./internal/_curry2');
var _dispatchable = require('./internal/_dispatchable');
var _map = require('./internal/_map');
var _reduce = require('./internal/_reduce');
var _xmap = require('./internal/_xmap');
var curryN = require('./curryN');
var keys = require('./keys');

module.exports = _curry2(_dispatchable(['map'], _xmap, function map(fn, functor) {
  switch (Object.prototype.toString.call(functor)) {
    case '[object Function]':
      return curryN(functor.length, function() {
        return fn.call(this, functor.apply(this, arguments));
      });
    case '[object Object]':
      return _reduce(function(acc, key) {
        acc[key] = fn(functor[key]);
        return acc;
      }, {}, keys(functor));
    default:
      return _map(fn, functor);
  }
}));

Note that Ramda's implementation switches based on type and provides inline implementations for Function#map and Object#map (the implementation for Array#map lives in _map, presumably).
The map function in sanctuary-type-classes dispatches to the appropriate method, which may be an implementation (such as Array$prototype$map above) provided by the library itself. As a result the map function itself is trivial, and each of the fantasy-land/map methods are defined separately.
In summary, Ramda and Sanctuary should share the implementations of Array#fantasy-land/map and friends at the very least. I'd been hoping that sanctuary-type-classes already allows us to do exactly this.

@CrossEye
Dispatcher
(regarding the name see below), I inverted the control to it precisely to support a simpler currying version. In its current implementation it has placeholder support built-in. I don't want to be "forced" to have code in my code base that I don't use. Specially, in a "toolbox" kind of library. But also I don't want to "force" people otherwise. So hopefully, the "dispatcher" makes frictionless to support whichever version of currying you would like. To me that is what fp is all about (part of :)); small functions that do 1 thing and compose them to create additional features.
Combinatorial Ramdas
It brings me back to the original post. IE: there needs to be better educational resources, not a more complex library as a way to educate. If you look at http://ramdajs.com/docs/#map, it takes 5 long lines to explain what it does (not including the fantasy-land's functor explanation). This confuses fp newcomers and disappoints (eg: dispatch discussion) experienced users looking to use the library in a different way (ie: reuse the code). I imagine the docs in home of map with just "Ramda provides suitable map implementations for Array and Object, so this function may be applied to [1, 2, 3] or {x: 1, y: 2, z: 3}." and a link to a list of ramda-flavors (officially or user maintained) to point experienced users that understand what the differences entail (blind map dispatch, FL, currying versions etc.). The list can be arbitrarily limited. For a "toolbox" kind of library, massively reusing its flexible source code is exactly what I would expect.
Things like the cookbook should be directly linked in the home page to teach newcomers how to easily compose functions (Re: placeholder support).
Forward
I would also like to move promptly. It would be great if you could advance a sketch or something :)
PS: About "dispatching" -just to make sure I get right that it is about the name, or at least to document. I kept the name "dispatching" to keep a reference to the current implementation. But it has nothing to do with it (in the object oriented and current implementation sense). Meaning, it is not calling any object's method -as the current "_dispatchable" is. We would change the name to reference the "function passing"/"inversion of control".

sanctuary-type-classes functions depend on sanctuary-type-identifiers and other internal pieces of code.
True, but sanctuary-type-identifiers is tiny. This is all there is to it:
//  type :: Any -> String
function type(x) {
return x != null &&
x.constructor != null &&
x.constructor.prototype !== x &&
typeof x.constructor['@@type'] === 'string' ?
x.constructor['@@type'] :
Object.prototype.toString.call(x).slice('[object '.length, -']'.length);
}
As for "internal pieces of code", at least 90% is necessary to support the exported functions. Less than 10% (I estimate) is dedicated to the TypeClass values such as Z.Functor exported for use with sanctuary-def.

In any case, again, why "force" users to have code they don't want?

In that case sharing code is more challenging.

how so?

We could at least share the implementations of Array.map, Object.map, Function.map, etc.

I agree, that is what the current PR is all about.

If there's a performance benefit to an imperative implementation, we can easily update this. I'd love to see a pull request for this. :)

what's wrong with the version I linked to?

sanctuary-type-classes is far more modular than Ramda. Compare the map implementations:

Currently, yes. That's the whole point of the (PR)[https://github.com/rickmed/ramda/blob/262415315fc30531f61f10800f454a5f49d083d1/src/new_map.js]. Which can be simplified.

In summary, Ramda and Sanctuary should share the implementations of Array#fantasy-land/map and friends at the very least. I'd been hoping that sanctuary-type-classes already allows us to do exactly this.

Again, why not build sanctuary on top of ramda-core?

In that case sharing code is more challenging.

how so?

Because Ramda can't simply depend on sanctuary-type-classes.

Again, why not build sanctuary on top of ramda-core?

Because it doesn't exist. :stuck_out_tongue_winking_eye:
If and when ramda-core has been published to npm, we'll certainly consider having sanctuary-type-classes depend on it.

In that case sharing code is more challenging.
how so?
Because Ramda can't simply depend on sanctuary-type-classes.

oh, right. Exactly, my point is to share core code. The rest of the features can be built on top.

Again, why not build sanctuary on top of ramda-core?
Because it doesn't exist. 😜

Well let's go for it! :)

Just to be clear, I don't mean that npm/ramda would necessarily mean ramda-core. Personally, I prefer a code base with no transducers, no placeholders and dispatch to FL first, then object's method, but I don't pretend for that to be npm/ramda. If decided, npm/ramda can keep exactly the same features it currently has -I would be happy to publish npm/my-lib (it doesn't even has to have the ramda prefix).

Just checking in. FWIW, I support this line of inquiry. To my mind it is worth asking how we got here and re-evaluating if we've made the right decisions.
And FWIW, my opinions on what I'd like to see stay (👍 ) or go (👎 )

Fantasy-Land 👍
Transducers 😑
Placeholders 👎

https://github.com/ramda/ramda/issues/1000

Hopefully I made a mistake, but I actually "went through ramda's code and couldn't believe what I found out". R exports 238 functions.

Same here:

Fantasy-Land 👍
Transducers 😑
Placeholders 👎

Since @buzzdecafe, @CrossEye, and I are all in favour of dispatching to fantasy-land/-prefixed methods, I'll revive #1938!

@rickmed:

It brings me back to my original post. IE: there needs to be better educational resources, not a more complex library as a way to educate. [ ... ] I imagine the docs in home of map with just

Ramda provides suitable map implementations for Array and Object, so this function may be applied to [1, 2, 3] or {x: 1, y: 2, z: 3}.

and a link to a list of ramda-flavors (official and/or user maintained) to point experienced users to who understand functional concepts and what their differences entail [ ... ]

I don't see Ramda as being primarily an educational tool.  Or rather, it was a library that @buzzdecafe and I started as a way to educate ourselves, but it has been the building of it that is educational, not the library itself.  We did it as a way to understand better functional concepts that made sense but were not part of our regular routines.  Many of these ideas weren't particularly practical to use in JS.  Ramda has been an attempt to make them more practical.
When it started to catch on, we were flabbergasted.  This was a little toy library for our own uses that only a few friends knew about.  It has shifted, and with the addition of @davidchambers and other contributors, it has grown into a more mature library, but it still maintains the focus of being an attempt to make practical in JS ideas from the FP community.
Thus, while transducers are not essential (they were a Clojure experiment ported with good reason to JS, but we might have been too quick to adopt them) and the placeholders might not be worth their implementation costs now that ES6+ is so prevalent, having map operate on arbitrary functors is quite core to what I think of Ramda as doing.  So dispatching to map methods, and supplying implementations for built-in functors -- Arrays, Objects, Functions -- are the baseline requirement.  Details of how we dispatch are certainly up for debate, and there's a serious debate about how much dispatching we should be doing.  But losing this dispatch would be for a different library, not for Ramda.  At least that's how I see it.

I would like to move promptly as well. It would be great if you could advance a sketch or something :)

Here's the basic idea:
There is one internal ramda function (I'm calling it ramda for now) that is responsible for calling functions that have been configured with such helpers as curry, flip, partial, etc.  It stores a configuration object with a reference to the original function, with all parameters that have been supplied so far, a mapping of where subsequent parameters need to go to be fed to the original function.  A call to, say, map, calls this function, which checks where to place the incoming parameters and whether all of the required parameters are supplied (the way curry does, but somewhat more sophisticated), and either calls the original function or returns a new one with an updated config.  I keep vacillating between making the config a property of the function and storing it in a closure; I do expect something will eventually prevent the closure, but so far it continues to work.  This would also give me an easy place to use Dr. Boolean's Debugging Functional techniques, which would be useful.  It also would give us the place to do a lodash-style rearg if we like.
The point is that there wouldn't be nested calls to curry; placeholder checks would be centralized (if we decided to keep them; as rearg would be a real alternative.)  Each call to a Ramda-wrapped function should involve one call to this function, which would either call the original function or return a new further-configured function.  It should drop our stacks tremendously.  I don't have my head wrapped firmly enough around transducers to know how to integrate them with this vision or even if its possible.
Anyway, that's the idea.  All my experiments are on a machine with no network connections.  I will try to fix that this weekend ... assuming I have no more appliance problems!  :frowning:
I don't know how much or how little that will conflict with what you're doing.

@CrossEye

When it started to catch on, we were flabbergasted. This was a little toy library for our own uses that only a few friends knew about. It has shifted, and with the addition of @davidchambers and other contributors, it has grown into a more mature library, but it still maintains the focus of being an attempt to make practical in JS ideas from the FP community.

Not sure if it has not been apparent from my other posts but I really appreciate the work that you have done with ramda. You have made a direct and positive impact in my life by helping me write (and learn along the way) fp in js which I greatly enjoy. So thank you. Also, that same impact has been made to a lot of people and growing by the day. So much, that many of them use ramda in serious projects (their jobs or otherwise). Myself included. I believe that, whether you expected/wanted it or not, ramda is currently in an important position. If you want to write "js fp style" there is no way around using ramda. This is quite a combination; javascript which is the most popular language in the world and fp -from which people choose whole career paths based on it.
My goal with these contributions is to help accelerate moving the library forward however I can and best serve the above mentioned users -I don't really care which contributions it involves as long as it achieves it. I felt sad when reading the issue from almost 2 years ago for ramda 1.0 and it died. I made this PR to provide a solution to the never ending discussion about the configuration (dispatching, placeholders, transducers...). The dispatching discussion alone have stalled many PRs at least for 5 months -I understand also it's an unfunded OS project as many others.
I apologize if I'm intruding, being insensitive or whatnot. Or all of them :)

I don't see Ramda as being primarily an educational tool.

I'm not saying that either. However, given the its position, it makes a big impact in that regard. (imo, ramdajs.com is super important). My argument is that its base code should not be used to educate.

Here's the basic idea:
There is one internal ramda function (I'm calling it ramda for now) that is responsible for calling functions that have been configured with such helpers as curry, flip, partial, etc. It stores a configuration object with a reference to the original function, with all parameters that have been supplied so far, a mapping of where subsequent parameters need to go to be fed to the original function. A call to, say, map, calls this function, which checks where to place the incoming parameters and whether all of the required parameters are supplied (the way curry does, but somewhat more sophisticated), and either calls the original function or returns a new one with an updated config. I keep vacillating between making the config a property of the function and storing it in a closure; I do expect something will eventually prevent the closure, but so far it continues to work. This would also give me an easy place to use Dr. Boolean's Debugging Functional techniques, which would be useful. It also would give us the place to do a lodash-style rearg if we like.
The point is that there wouldn't be nested calls to curry; placeholder checks would be centralized (if we decided to keep them; as rearg would be a real alternative.) Each call to a Ramda-wrapped function should involve one call to this function, which would either call the original function or return a new further-configured function. It should drop our stacks tremendously. I don't have my head wrapped firmly enough around transducers to know how to integrate them with this vision or even if its possible.

Thank you. I'm having trouble imagining it in hard code, though. The first paragraph makes me think it's a much more convoluted solution to this PR's and the second one makes me think they are not all that different (specially if using closures). Without seeing some code, I'll risk it with the following questions:

is responsible for calling functions that have been configured with such helpers as curry, flip, partial, etc.

This part is what I think is confusing me the most. Not clear how the configuring would work. Who configures who?
Also, would the function be lightweight as to publish them individually?

It stores a configuration object with a reference to the original function, with all parameters that have been supplied so far, a mapping of where subsequent parameters need to go to be fed to the original function. A call to, say, map, calls this function, which checks where to place the incoming parameters and whether all of the required parameters are supplied (the way curry does, but somewhat more sophisticated), and either calls the original function or returns a new one with an updated config.

Is it for placeholders support? I wouldn't get why a simple curry wouldn't suffice.

The point is that there wouldn't be nested calls to curry;

Yes. It's currently a problem since all functions export curried functions which some of them are used by other ones and so on. ie: currying is too coupled.

It should drop our stacks tremendously.

This PR solves that two. Both proposed refactors would take a fair amount of work though. Because of the above.

This would also give me an easy place to use Dr. Boolean's Debugging Functional techniques, which would be useful. It also would give us the place to do a lodash-style rearg if we like.

+1! Imo, should be an important part of what ramda provides. I've been doing some research about it but wanted to open issues one by one.

Thus, while transducers are not essential (they were a Clojure experiment ported with good reason to JS, but we might have been too quick to adopt them) and the placeholders might not be worth their implementation costs now that ES6+ is so prevalent, having map operate on arbitrary functors is quite core to what I think of Ramda as doing. So dispatching to map methods, and supplying implementations for built-in functors -- Arrays, Objects, Functions -- are the baseline requirement. Details of how we dispatch are certainly up for debate, and there's a serious debate about how much dispatching we should be doing. But losing this dispatch would be for a different library, not for Ramda. At least that's how I see it.

This PR's refactor would comply with all of those requirements and more. Additionally, what if the requirement of dispatching to functors' methods changes? (however unlikely as I assume the placeholders support was in the past). What if the fantasy-land api changes? What if you want to go back to transducers support?, etc.
All of these refactors would take zero changes in core code. Fantasy-land changed? change a few characters . New functionality, build from there however you want.

But losing this dispatch would be for a different library, not for Ramda.

This really confuses me. This does not suggest anything of that sort.

Details of how we dispatch are certainly up for debate, and there's a serious debate about how much dispatching we should be doing.

This PR aims exactly at that.

@rickmed:

I apologize if I'm intruding, being insensitive or whatnot. Or all of them :)

You are not.  Not in the least. :smile:

My argument is that its base code should not be used to educate.

The first paragraph makes me think it's a much more convoluted solution to this PR's and the second one makes me think they are not all that different (specially if using closures).

Note that the goal of my work is entirely different from yours, even if they might have some overlap in some of their effects.
Yours, as I understand it,, is about simplifying the source code and allowing us to build versions of the library with different subsets of our current feature-list -- not the functions, things like default currying, FantasyLand and other dispatching, placeholders, transducers, etc.
Mine is more about call stacks, debuggability, and -- most likely -- performance.  My goal is that if you step into a Ramda-wrapped function, you walk through what will quickly become a very recognizable process of parameter juggling that leads you down one of only two paths: returning a further-configured function, or calling the original function with a full set of parameters.  If you call a wrapping function -- curry, partial, flip, arity, binary, etc -- it returns a function that will call that one function with the configuration object in scope.
I will either try to sneaker-net the code from that machine, get that machine working, or recreate it.  It's not that much code.  But it's not entirely working yet, and I still need some time to complete it.

The point is that there wouldn't be nested calls to curry;

Yes. It's currently a problem since all functions are being exported curried by default, which some of them are used by other ones and so on. ie: currying is too coupled.

Well the auto-curried function is one of the things which most users first find helpful about Ramda.  It was probably the single most important initial driving factor for the library.

It should drop our stacks tremendously.

This PR solves that too. Both proposed refactors would take a fair amount of work though. Because of the above.

Yes, and I can't tell if yours can be layered on top of mine... I'm pretty sure the other way wouldn't work.

Additionally, what if the requirement of dispatching to functors' methods changes?

I don't mean to suggest this is a feature that map should have.  I mean that this is the actual definition of map.

But losing this dispatch would be for a different library, not for Ramda.
I'm confused. This does not suggest anything of that sort. https://github.com/ramda/ramda/pull/2082#issuecomment-278403235

I meant to suggest that the other features discussed, transducers, placeholders, seem less central to Ramda, and might well be relegated to opt-in separate builds, but that I can't really imagine a Ramda build that doesn't include dispatching map.

@CrossEye
Thank you for the quick reply -in the context of your technical issues.

My argument is that its base code should not be used to educate.

I was referring to the transducers support (among others) which many people expressed were interested in for educational purposes. But I should open a separate issue about that.

Yours, as I understand it,, is about simplifying the source code and allowing us to build versions of the library with different subsets of our current feature-list -- not the functions, things like default currying, FantasyLand and other dispatching, placeholders, transducers, etc.

My motivation was the one stated above. It just so happens, logically, that the solution was to decouple code which makes the core extendable -there was demand for this in the past btw- and future-proof.

Note that the goal of my work is entirely different from yours, even if they might have some overlap in some of their effects.

We would overlap in less call stacks and performance. Mine would not change debuggability -apart of a consequence of having less stacks. I would propose the application of the techniques in drboolean's article in a different PR.

Yes, and I can't tell if yours can be layered on top of mine...

I only speculate from your description, but I think it may actually work.

Well the auto-curried function is one of the things which most users first find helpful about Ramda. It was probably the single most important initial driving factor for the library.

but that I can't really imagine a Ramda build that doesn't include dispatching map.

Again, this is not what this PR is about. No one would use ramda-core directly. It would make no sense at all a ramda without curried functions. I refactored it that way to settle the discussion about placeholders. Then I realized it would also solve the nested currying problem. It would also support users which, for any obscure reason, can't use arrow functions as placeholders replacement.
idem; map. It addresses this. I share your view in that comment. I also share Fantasy-Land 👍, Placeholders 👎. But I would want to be able to not choose between ramda and a library that, for example, complies with fl but needs to maintain a legacy map -and current users in the same position. Additionally, I speculate, it would be able to integrate with libraries like Immutable.

@CrossEye What do we do with this one?

This is one of those things that keeps coming back to haunt us.  I'm adding the Maturation tag and closing it.  All the 1.0 Discussion and Maturation tags to me are ideas that we want to revisit post v1.0 (or more likely post v2.0).  This to me is at the top of that list.  It might make 2.0 easier to write.


The o format option is not supported

I'd like to have the datetime format with the UTC offset, instead of the timezone name.
What I'd like to see:
yyyy-mm-dd hh:ii o would give 2017-01-01 00:01 -0500
where yyyy-mm-dd hh:ii z gives 2017-01-01 00:01 EST
or
yyyy-mm-dd hh:ii o would give 2017-01-01 00:01 -0000
where yyyy-mm-dd hh:ii z gives 2017-01-01 00:01 UTC
The reason I use o is that is what the JS Date seems to be looking for in the format. (I'm not real good with JS, or I'd try to fix this myself.)

Oh well, no comments, no help. I worked around the issue myself, so closing this.


Automatic position for nodes

Hi, I'm looking for a simple library to create a diagram and I'm very interested in using Drawflow.
I have a question, if I import data without a position definition for the nodes, does Drawflow organize or assign an automatic position?
if not, how complex would it be to add this?

I got it.
Wouldn't it be interesting for the lib to automatically do this positioning based on the parents and number of children?
Like this one:

For each new node added, its position would be recalculated based on the number of children

The library is intended for data flows not for diagrams. One thing is that it can be adapted.


Allow to extend AddressEmbeddable

I need to add a custom field to an AddressEmbeddable and with this MR, I can do extend it without rewriting almost all AddressEmbeddableTypeSubscriber.
What do you think?
Feel free to ask more details if needed

Looks good and indeed allows for easier changes. Thanks!


Latin character í (Latin small letter i with acute) is displayed with errors

All accentuated characters work correctly with the exception of "í", which generates a ">" on the final PPT

I think I might've fixed this. This is similar to the Danish character problem I encountered.
Can you try 5.0.1 - when I release it in a few minutes and see if the problem is still there?
Technical explanation: I was using high 8-bit chars as tokens. Now I'm using "guaranteed unused" high 16-bit Unicode codepoints instead.
Thanks!
(And sorry for taking a few days to notice your Issue.)

Thanks! But it's giving me the same problem :(
This is my output:
md2pptx Markdown To Powerpoint Converter 5.0.1 14 July, 2024
Open source project: https://github.com/MartinPacker/md2pptx
External Dependencies:
Python: 3.11.4
python-pptx: 0.6.23
Pillow: 10.4.0
CairoSVG: Not Installed
graphviz: Not Installed
Internal Dependencies:
funnel: 0.1
runPython: 0.2

My file is UTF-8 with Unicode:
ReporteAssessment.md: Unicode text, UTF-8 text
The strange thing about this issue is that most accentuated characters work, only í doesn't
Thanks again!

Thank you. Do you have a Unicode code point for it. That will help me investigate.

I encountered the same problem when using Simplified Chinese. I solved it by changing the 4924th line of code in md2pptx
with input_path.open(mode='r', encoding='utf-8') as file:

Thank you. We will need to test such a change extensively - to make sure it doesn't muck anything else up.

So, I've run this through 2 (not terribly challenging) presentations and it works.
So please test with the commit I just made (5.0.1+ 25 July when you run it.)

Shipped in v5.0.2. Keeping this open for a while - in case there are regressions.

Closing. Feel free to reopen.


[fix][client] Fix the javadoc for startMessageIdInclusive

Fixes https://github.com/apache/pulsar/issues/23498
Motivation
The Consumer#seek(long) and startMessageIdInclusive have no relation. Whether startMessageIdInclusive is present or not, Consumer#seek(long) that seek by timestamp will contain the firstMessageId.
In the code, we can see that the Consumer#seek(long) seekMessageId use the MessageId.earliest.
@Override
public CompletableFuture<Void> seekAsync(long timestamp) {
    String seekBy = String.format("the timestamp %d", timestamp);
    long requestId = client.newRequestId();
    return seekAsyncInternal(requestId, Commands.newSeek(consumerId, requestId, timestamp),
            MessageId.earliest, timestamp, seekBy);
}

Modifications
remove the Consumer#seek(long) in comment of ReaderBuilder#startMessageIdInclusive and ConsumerBuilder#startMessageIdInclusive
Documentation

[x] doc
[ ] doc-required
[ ] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository:

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 74.35%. Comparing base (bbc6224) to head (0d75283).
Report is 701 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #23508      +/-   ##
============================================
+ Coverage     73.57%   74.35%   +0.77%
- Complexity    32624    34428    +1804
============================================
  Files          1877     1943      +66
  Lines        139502   147045    +7543
  Branches      15299    16205     +906
============================================
+ Hits         102638   109330    +6692
- Misses        28908    29282     +374
- Partials       7956     8433     +477

Flag
Coverage Δ

inttests
27.30% <ø> (+2.71%)
:arrow_up:

systests
24.39% <ø> (+0.06%)
:arrow_up:

unittests
73.72% <ø> (+0.88%)
:arrow_up:

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


Add spoilers extension

So people can spoil each other on the campaign.

https://extiverse.com/extension/isamuraii/bbcode-details

Added, needs to use markdown: [details title=secrets...]bhop[/details]


Passing multiple catalogs to the XSpec ANT transformation

Hi,
A common user of Oxygen and XSpec was asking if the catalogs configured in Oxygen are passed automatically to XSpec. The XSpec framework in Oxygen uses the ANT transformation so we rely on the catalog property which at first glance looks like it has to be just one file path. In Oxygen, there is an editor variable named ${xmlCatalogFilesList} that expands to a comma separated enumeration of catalogs URLs.
Do you think it makes sense to enhance the catalog property to support such enumerations? Because if it did, then Oxygen's transformations could make use of ${xmlCatalogFilesList} and the user would automatically benefit from the already configured catalogs. Or do you see another solution?
Thanks,
Alex

Sounds reasonable.

The current build.xml converts catalog to xspec.catalog.url in order to work around a Saxon bug which is not fixed on Saxon 9.7. After we throw away Saxon 9.7 (soon), we won't need the conversion. By removing the conversion, catalog should work just fine with ${xmlCatalogFilesList}. (I haven't tested it, though.)
Per another Saxon bug, the semicolon separated list requires Saxon <IP_ADDRESS> or later. Oxygen ~21.x bundled with older Saxon versions may have a problem. Still, such users can duplicate and edit the transformation scenario.

Unfortunately this may not be an instant task. Ant catalogpath seems to accept only native paths, whereas ${xmlCatalogFilesList} is a collection of URLs possibly including non file: one.

So I have implemented this feature as follows. If this is fine, I'll create a pull request after releasing v1.6.0.

Default catalog property in xspec.framework is now ${xmlCatalogFilesList}.
Introduce a new Ant property catalog.is.uri

Default false in build.xml.
Default true in xspec.framework.
Will not be documented in Wiki for the time being.

If catalog.is.uri is true, build.xml first creates a temporary catalog file where all URIs in catalog property are referenced by nextCatalog elements.

Typically it looks like this:<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
   <nextCatalog catalog="http://my-catalog-server.example.com/catalog.xml"/>
   <nextCatalog catalog="file:/C:/Program%20Files/Oxygen%20XML%20Editor%2022/frameworks/dita/catalog.xml"/>
   <nextCatalog catalog="file:/C:/Program%20Files/Oxygen%20XML%20Editor%2022/frameworks/dita/DITA-OT3.x/plugins/org.dita.base/catalog-dita.xml"/>
   ...

Relative URIs are resolved with URL of Ant basedir property.
All subsequent <xslt> and <java> tasks in build.xml use this temp catalog file.

Wow! That was quick! :) It sounds great! I will add an issue on our side to make sure we don't miss this feature when we update the built-in framework.

I use the same technic in xspec-maven-plugin when user specifies a catalog in plugin configuration. I create a catalog (to resolve xspec impl & schematron impl files) that references (using next-catalog) the user' one.

#980 implements this.


Exclude cache folder from deno fmt

What's the purpose of this?

Do not fmt site/docs/.vitepress/cache (?)


Add documentation for spring random port

I recently started to migrate to Junit5 and did not immediately find out how to replace the SpringBootHttpTarget. (s. https://pact-foundation.slack.com/archives/C9UN99H24/p1569264854017500)
Thus, I extended the documentation with the info that was missing for me.

Thanks for the PR.


How long is the registration information retained on the client side after eureka server closed

Application(A) as a service was registered in the eureka server, so another application(B) was able to call the service (A) by eureka client. Then I shutdown the eureka server, What I'm confused about is that the app(B) still was able to call the service(A) during about 30 seconds.
Could you please explain how long is the registration information retained on the client side after eureka server closed and which property affect the duration.
Thank you,

This the most accurate info I know that can make you understand a bit how eureka works: https://github.com/spring-cloud/spring-cloud-netflix/issues/373#issuecomment-110331739
To answer your question, it hold by default, as you said, for 30 seconds the info on the client side,  and the property that can change that duration is  eureka.client.registryFetchIntervalSeconds

@sfat ,thanks for your answer, but I don't think the property that can change that duration is eureka.client.registryFetchIntervalSeconds,because i had set this property as 5 rather than 30.

@magicDong88 AFAIK it retains the cache indefinitely while it can not communicate with the eureka server.


daemonded doesn't start on Mac

I get a message like
Warn: Could not bind singleton socket at file: "/var/folders/37/cwhvzf2j3_ngll0kwst_3k540000gn/T/.unvanquished-server-EE505147981E5E2AF51FA52BF9C4BA7A/socket", error: "Address already in use"

Changing the homepath doesn't help.
daemon and daemon-tty don't have this issue.

Duplicate of #1390.


Add functionality for writing the CSV buffer to file durning a simulation

Currently, the only time that a CSV diagnostic writes its buffer to file is at the end:
https://github.com/NRL-Plasma-Physics-Division/turbopy/blob/165a006ad9ea776e775ef5d823791549b7a53ca5/turbopy/diagnostics.py#L55
It would be useful to have an option to write the buffer to file at some interval, so that it would be easier to monitor the progress of long-running simulations.

Thanks for working on this, and for your patience with me getting back to you.
I have some comments, and the code will probably have to be rearranged some from what you wrote. I'll try and put the comments in a review.

So I think I should clean up the OutputUtility functionality a bit before we continue with this. It should make the code more organized, and easier to extend. I'd say pause on this for a bit until I get that in place.

@AOstenfeld see #150 for some ideas that I'm trying for refactoring the way that Diagnostics + OutputUtilities work. I'd appreciate thoughts/comments on that code. It should make your effort easier.

Sounds good. I'll check it out.

See my comment on #148 for some new ideas I had for this.


Speaker instead of FAN

Isn't possible to expose this as speaker instead of Fan ?

as far as I know not. Sorry.


Add missing migration file and make GPS field editable

Summary

Fix #125.
Add missing migration file.

Note: .gitignore ignores migrations directory, which app should track all migration files unless admin would like to generate migration file in the production server.

Will merge manually

Because it requires rebase

Thank you @biswaz

@kracekumar Please rebase and resubmit.
The new js toggle hides the fields. Fix that too

@biswaz Sure. Let me look into it.

#135 seems a duplicate of this PR

@biswaz Have fixed the issue. Please take a look.

Can you submit a new PR, Im afraid the migration will break something

You mean, I should remove the migration file?

yes

Done


Can I use this for car like trajectory generation?

That means only liner velocity and rotate speed. I try some test and found its result only mav can follow,I am not sure how to force only x dimension speed for robot's local posion.
BTW,the doc in readme about Nonlinear Optimization
There's only 2 parameters  for PolynomialOptimizationNonLinear now.

I found polynomial path is wriggled for a car though it is fine for a mav.


Why does CheckDependencies function only compares the name and not the version?

Hello,
Output of helm version:
version.BuildInfo{Version:"v3.13.3", GitCommit:"c8b948945e52abba22ff885446a1486cb5fd3474", GitTreeState:"clean", GoVersion:"go1.20.11"}

I noticed that, if, when running helm template or helm install commands, a dependency chart version inside the Chart.yaml file differs from that chart version located in the charts/ folder, the command succeeds.
These commands succeed regardless of whether the Chart.lock file exists or not.
At the same time, the helm dependency list command marks that dependency chart with wrong version.
Looking at Helm's code, there is the CheckDependencies function that checks that the dependency charts exists in the charts/ folder. This function only compares by package name and doesn't compare the version.
Questions:

I was wondering why does it behave this way. Maybe it is related to the ability to manually manage the dependency charts?
Regardless of the above, do you think that it could be an improvement to enforce the version match when given a new flag? something like --enforce-dependency-version?

Thanks,
Raz

What's the use case for wanting to enforce the versioning?

@z4ce, appreciate your attention to this, and your question is spot on! 😊
I've been working on an enhancement for argo-cd, and in the process, I encountered an interesting scenario.
The background in a nutshell: during its reconciliation cycle, argo-cd updates its git repo, cleans up leftover uncommitted code (usually from the charts/ folder), and leverages helm template to regenerate manifests. If helm template fails, it checks the failure output for "missing dependencies". If found, it runs helm dependency build and retries helm template.
With multiple argo-cd applications having helm chart dependencies, each reconciliation cycle (which happens every few minutes) becomes quite time-consuming. The improvement I proposed in https://github.com/argoproj/argo-cd/pull/16750 tweaks the clean behavior by excluding the charts/ folder (with a new flag), reducing the need for helm dependency build.
Here is the hiccup: I assumed helm template would fail if the dependency chart version in Chart.yaml changed in the git repo. It didn't, as described in this issue. To address this, I added a call to helm dependency list to catch the "wrong version" scenario, triggering helm dependency build if needed.
As a general use case, Helm's behavior in this context seems error-prone, especially if users manually bring in, by mistake, the wrong dependency chart versions into the charts/ folder, and helm template/install remains silent about it.
I get that altering Helm's behavior has implications, which is why I'm suggesting the change only when a new flag is provided.
Thanks again for your attention!

Hey @ramir-savvy if possible join the next developer call and bring this up. I've actually had this happen before myself (changing the version, neglecting to upgrade, and inadvertently using old chart versions).  I'd be in favor of this, but I actually wish it would just be the default. Developer call info is here: https://tockify.com/cncf.public.events/detail/158/1667493000000

Hi @z4ce, I will be happy t join if you think this is the way to promote this.
Can you tell what is the procedure to brung this up? Should I prepare anything?

I can provide some context here.
The source of truth for subcharts is the charts/ subdirectory within a chart. You can put both chart archives in there and directories as charts. The charts don't need to be listed in the Chart.yaml. If there are "unmanaged" charts in the charts/ directory than them will handle them gracefully when you deal with managed charts alongside them.
Checking for dependencies looked at the named availability of dependences and stopped there. This checking is a bit primitive, was lasted updated 5 years ago, and mostly has the original form to it.
What I would suggest is that for Helm v3, where we don't make braking changes, is that Helm check the dependencies listed in the charts/ directory against the list in the dependencies within Chart.yaml.
After considering this situation and looking at the backwards compatibility direction, I would suggest that for those that are listed in the Chart.yaml and the version does not match the constraint or the version listed in the lockfile (if present), a message is placed in the UI and Helm exit in error.

Thank you @mattfarina

What I would suggest is that for Helm v3, where we don't make braking changes, is that Helm check the dependencies listed in the charts/ directory against the list in the dependencies within Chart.yaml.
After considering this situation and looking at the backwards compatibility direction, I would suggest that for those that are listed in the Chart.yaml and the version does not match the constraint or the version listed in the lockfile (if present), a message is placed in the UI and Helm exit in error.

Can you please clarify if you suggest doing that change in Helm v3 or the next version?

I think the general census was that helm install and helm upgrade should provide a warning message when helm dependency list indicates wrong version. And that would be applicable today. In Helm v4, we would want the the behavior to be exit with error. Is that right @mattfarina ?

Please also add helm template to the commands list


Should output be created if no cards were generated?

There's some cases where 0 cards might be generated without fault. A datasource might specify 0 count for each card, or it might just be empty.
However, is there really any reason to copy all resources, write stuff to disk etc. if there's no cards?
It's a minor thing, but maybe it should just warn that no output was created since there's no card.

This somewhat relates to #59. I think the conclusion is that if no errors were encountered; assume project built properly and output should be written.


[DOCFIX] Update MapReduce documentation

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/8491/
Test PASSed.

alluxio-bot, merge this please

alluxio-bot, cherry-pick this to branch-2.2 please


Authentication on mobile appears to be broken

With a Galaxy S7 - Chrome I consistently get

500 Internal Server Error
If you are the administrator of this website, then please read this web application's log file and/or the web server's log file to find out what went wrong.

Hmm, can't reproduce on my phone for my account. I assume this doesn't happen if you log out on desktop?
Does this happen even in an incognito tab? Maybe a different phone (if you have access to one) or the Android emulator?


A bug with jupyter notebook in VS code

VS Code Version:1.54.2
OS Version: MacOS Big Sur

Steps to Reproduce:

The VS code cannot detect the conda env correctly. This cause I cannot change the interpreter in the VScode!
I setup 3 env by conda, which are BINF, tf24, cv. The VSCode jupyter got 3 cv. So the detection was wrong.

Does this issue occur when all extensions are disabled?: Yes/No

My laptop is Apple silicon. And I used the VScode Universal version, which is the blue one. One this version can use jupyter notebook in it.

The tf24 and BINF with python3 cannot start up correctly

/extJupyter


fix(dao): Add missing indexes for foreign keys columns

Most of the columns receiving these indexes are already part of some composite indexes, although not in the first position. When a column is in second position or more of a composite index, the latter is not used for lookups (see 1 and 2).
All missing indexes are added by this commit except on 'snippet.artifact_id' and 'snippet.vcs_id' as this table is usually big.

@nnobelis Somehow this change makes the RepositoriesRouteIntegrationTest fail.

@nnobelis Somehow this change makes the RepositoriesRouteIntegrationTest fail.

This is this index
CREATE INDEX ort_runs_repository_id ON ort_runs (repository_id);
Causing:
Caused by: java.sql.BatchUpdateException: Batch entry 0 INSERT INTO ort_runs (created_at, "index", job_configs, repository_id, revision, status, trace_id) VALUES (('2024-09-26 10:00:06+02'), ('8'::int8), ('{"analyzer":{"allowDynamicVersions":true,"recursiveCheckout":true,"packageCurationProviders":[]},"parameters":{}}'), ('1'::int8), ('branch-45'), ('CREATED'), ('85bc0447-1f6d-4530-9632-fe7a5db0e905'))
RETURNING * was aborted: ERROR: could not serialize access due to read/write dependencies among transactions
  Detail: Reason code: Canceled on identification as a pivot, during write.

Now this change makes me nervous. Any idea why we start getting those errors ?

@nnobelis Somehow this change makes the RepositoriesRouteIntegrationTest fail.

This is this index CREATE INDEX ort_runs_repository_id ON ort_runs (repository_id); Causing:
Caused by: java.sql.BatchUpdateException: Batch entry 0 INSERT INTO ort_runs (created_at, "index", job_configs, repository_id, revision, status, trace_id) VALUES (('2024-09-26 10:00:06+02'), ('8'::int8), ('{"analyzer":{"allowDynamicVersions":true,"recursiveCheckout":true,"packageCurationProviders":[]},"parameters":{}}'), ('1'::int8), ('branch-45'), ('CREATED'), ('85bc0447-1f6d-4530-9632-fe7a5db0e905'))
RETURNING * was aborted: ERROR: could not serialize access due to read/write dependencies among transactions
  Detail: Reason code: Canceled on identification as a pivot, during write.

Now this change makes me nervous. Any idea why we start getting those errors ?
EDIT: I just that 5007a34 Looks connected IMO

This issue only occurred because the query to get the last index was highly inefficient and was later fixed by 4b78007. So it seems that the index makes the insertion slower which is expected, but I would have expected that this is much less relevant than the duration of the old query.

Closing this PR for now has there could be some unforeseen problems with the new indexes.
Maybe it will be reopened with a smaller scope (subset of the indexes) in the future.


Gems defined with extensions dirs conflict with diff versions

Problem:

Using ruby version X, two projects define some gem at differing versions.
Stub Specification does not pass extension dir, which causes issues.

We saw this as
** Notice: CityHash was not loaded. **

For optimal performance, use of the cityhash gem is recommended.

Run the following command, or add it to your Gemfile:

gem install cityhash

Environment
Bundler   1.15.0.pre.1
Rubygems  2.6.11
Ruby      2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin16]
GEM_HOME  /Users/ryanmcilmoyl/.gem/ruby/2.3.3
GEM_PATH  /Users/ryanmcilmoyl/.gem/ruby/2.3.3:/opt/rubies/2.3.3/lib/ruby/gems/2.3.0
Git       2.11.0 (Apple Git-81)
Platform  x86_64-darwin-16

Bundler settings
jobs
  Set for your local app (/Users/ryanmcilmoyl/src/github.com/Shopify/shopify/.bundle/config): "4"

Relevant Gemfile
Shopify Project:
gem 'cityhash', git: 'csfrancis/cityhash', sha: 'XYZ'
Another Project
gem 'cityhash'

see lib/bundler/rubygems_ext.rb, we need that impl of extension_dir for the stub spec, just replacing rg_extension_dir with stub.extension_dir

To replicate:
Gemfile
source 'https://rubygems.org'
gem 'cityhash', git: 'https://github.com/csfrancis/cityhash.git', ref: '3cfc7d01f333c01811d5e834f1495eaa29f87c36'

test.rb
require 'bundler/setup'
puts $:.grep(/cityhash/)

Which outputs
/Users/juliannadeau/.gem/ruby/2.3.3/bundler/gems/cityhash-3cfc7d01f333/lib
/Users/juliannadeau/.gem/ruby/2.3.3/bundler/gems/extensions/x86_64-darwin-16/2.3.0-static/cityhash-0.6.0

That cityhash-0.6.0 should be a hash

Ok, so looking into this more, stub_specification doesn't know what full_name should be because we don't have a record of the source, so it resolves to cityhash-0.6.0 rather than cityhash-3cfc7d01f333

This seems to work:
diff --git a/lib/bundler/remote_specification.rb b/lib/bundler/remote_specification.rb
index d89abd9..0f2ec9c 100644
--- a/lib/bundler/remote_specification.rb
+++ b/lib/bundler/remote_specification.rb
@@ -12,7 +12,7 @@ module Bundler

     attr_reader :name, :version, :platform
     attr_writer :dependencies
-    attr_accessor :source, :remote
+    attr_accessor :remote

     def initialize(name, version, platform, spec_fetcher)
       @name         = name
@@ -76,11 +76,6 @@ module Bundler
       @dependencies || method_missing(:dependencies)
     end

-    def git_version
-      return unless loaded_from && source.is_a?(Bundler::Source::Git)
-      " #{source.revision[0..6]}"
-    end
-
   private

     def to_ary
diff --git a/lib/bundler/rubygems_ext.rb b/lib/bundler/rubygems_ext.rb
index a0f8fa8..bc32d2e 100644
--- a/lib/bundler/rubygems_ext.rb
+++ b/lib/bundler/rubygems_ext.rb
@@ -23,6 +23,27 @@ require "bundler/match_platform"
 module Gem
   @loaded_stacks = Hash.new {|h, k| h[k] = [] }

+  class StubSpecification
+    attr_accessor :source
+
+    def git_version
+      return unless loaded_from && source.is_a?(Bundler::Source::Git)
+      " #{source.revision[0..6]}"
+    end
+
+    if method_defined?(:extension_dir)
+      alias_method :rg_extension_dir, :extension_dir
+      def extension_dir
+        @bundler_extension_dir ||= if git_version
+          ext_name = [name, git_version.strip].join('-')
+          File.expand_path(File.join(extensions_dir, ext_name))
+        else
+          rg_extension_dir
+        end
+      end
+    end
+  end
+
   class Specification
     attr_accessor :remote, :location, :relative_loaded_from

diff --git a/lib/bundler/stub_specification.rb b/lib/bundler/stub_specification.rb
index bc1b18f..c0b6232 100644
--- a/lib/bundler/stub_specification.rb
+++ b/lib/bundler/stub_specification.rb
@@ -9,7 +9,12 @@ module Bundler
       spec
     end

-    attr_accessor :stub, :ignored
+    attr_accessor :stub, :ignored, :source
+
+    def source=(source)
+      stub.source = source
+      @source = source
+    end

We have a spec for extensions being usable, and I can't reproduce this issue...

I think the specs don't cover all cases. Using https://github.com/bundler/bundler/issues/5594#issuecomment-294950831 between 1.14.6 and 1.15.0.pre.1, I get this:
~/src/github.com/Shopify/bund ➜ bundle exec ruby test.rb
1.14.6
/Users/juliannadeau/.gem/ruby/2.3.3/bundler/gems/cityhash-3cfc7d01f333/lib
/Users/juliannadeau/.gem/ruby/2.3.3/bundler/gems/extensions/x86_64-darwin-16/2.3.0-static/cityhash-3cfc7d01f333
~/src/github.com/Shopify/bund ➜ gem install bundler --pre
Fetching: bundler-1.15.0.pre.1.gem (100%)
Successfully installed bundler-1.15.0.pre.1
Parsing documentation for bundler-1.15.0.pre.1
Installing ri documentation for bundler-1.15.0.pre.1
Done installing documentation for bundler after 5 seconds
1 gem installed
~/src/github.com/Shopify/bund ➜ bundle exec ruby test.rb
1.15.0.pre.1
/Users/juliannadeau/.gem/ruby/2.3.3/bundler/gems/cityhash-3cfc7d01f333/lib
/Users/juliannadeau/.gem/ruby/2.3.3/bundler/gems/extensions/x86_64-darwin-16/2.3.0-static/cityhash-0.6.0


Fix deprecation warning in Ember 2.13

See http://emberjs.com/deprecations/v2.x/#toc_ember-router-router-renamed-to-ember-router-_routermicrolib

Now that 2.13 is live it would be great to get this deprecation warning silenced.

Let me figure out why the tests are failing on latest, beta, and canary...

Pending #56 to be merged with fix for failing test

Going to merge this for now and release a patch


Any way to disable authentication

We are currently evaluating some parts of Rasa-UI and are running it behind Traefik. Traefik already comes with the capability to add authentication. Therefore it would be interesting for us to add a mode that requires no authentication.
Does this make sense to you? If I wanted to implement that functionality on my own, which parts would require changes?

Hi @beevelop - are you suggesting the login screen should be optional (where you type in admin/admin)?

Pretty much. As we use a reverse proxy like Keycloak Gatekeeper in most of our cases, we don't necessarily need an authentication on the application level. Thus we could skip the authentication screen completely.
But this could also be interesting for evaluation / development use cases. It would be awesome, if we could switch this option though an ENV.


Fixes drivers apply, decompress-file and KMS licensing reset

decompress: keep original file for ungzip
Fix drivers apply on a golden image
Fix KMS licensing reset

:white_check_mark: Build windows-openstack-imaging-tools 1.0.189 completed (commit https://github.com/cloudbase/windows-openstack-imaging-tools/commit/baeb536d79 by @ader1990)

:white_check_mark: Build windows-openstack-imaging-tools 1.0.190 completed (commit https://github.com/cloudbase/windows-openstack-imaging-tools/commit/4cf575fe3d by @ader1990)

:white_check_mark: Build windows-openstack-imaging-tools 1.0.191 completed (commit https://github.com/cloudbase/windows-openstack-imaging-tools/commit/46bcd1e290 by @ader1990)

:white_check_mark: Build windows-openstack-imaging-tools 1.0.192 completed (commit https://github.com/cloudbase/windows-openstack-imaging-tools/commit/73bc4707f8 by @ader1990)

:white_check_mark: Build windows-openstack-imaging-tools 1.0.193 completed (commit https://github.com/cloudbase/windows-openstack-imaging-tools/commit/1b3c9825ce by @ader1990)


feat(UI): View navigation rework

User can now navigate between their views using a dropdown visible in the page header.

View list in dropdown leverage the previously built component.
The list item now have the option to be the selected one.
Old sub view has been deleted.

UI preview:
https://github.com/user-attachments/assets/bf7949c5-1915-403d-83e4-f8d6e6ea9312
In my opinion we should put the toasts back to the bottom of the viewport as tehy may conflict with this important element of the UI.

Toasts at the bottom are indeed likely better.

Found a bug with the display of the selection: the tick mark doesn't show for the view that is actually selected
2024-11-14T15_40_29_screen_record.mp4

Nice catch thanks !
It should be fixed now.


Support ordering in searches

As far as I can tell, there's no way to specify the order for a sort parameter in a search. See for example https://developer.github.com/enterprise/2.6/v3/search/#search-repositories.
Consider supporting order for all the types of searches in the link above.

Fixed toward 1.82


What kind of load-balancing ?

I work for two weeks on Kubernetes  now and i didn't find any informations about the kind of load-balancing.
I explain myself, I want to know if kubernetes uses round-robin or other kind of load-balancing specific.
Or if Kubernetes uses all load-balancer.
And how can we specify on a file ?

Right now, Kubernetes only uses round-robin load balancing in kube-proxy.

And will they implement other load-balancers or they will stay on the round-robin idea?

It's round robin, with optional session affinity. It may change to a
simpler probabilistic model soon (still with affinity). We don't have plans
to do anything else at the moment, though we are not against it. Do you
have real requirements?
On Jun 4, 2015 7:55 AM, "Pierre Soulerot"<EMAIL_ADDRESS>wrote:

And will they implement other load-balancers or they will stay on the
round-robin idea?
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/9243#issuecomment-108923660
.

For now, I have not real requirements but round robin with, for example, a database container with some replicas, it can be weird, right ? Even if I know a database container with some replicas can be weird too, it just an example for understand.

You can use ClientIP for session affinity, so that repeated connections
(within a time window) will get the same backend.
On Thu, Jun 4, 2015 at 8:15 AM, Pierre Soulerot<EMAIL_ADDRESS>wrote:

For now, I have not real requirements but round robin with, for example, a
database container with some replicas, it can be weird, right ? Even if I
know a database container with some replicas can be weird too, it just an
example for understand.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/9243#issuecomment-108931478
.

Thanks for help.


Test project template against Django's branches

This ensures our project template does not raise any warnings when used with the latest version of Django and Python.

Merged in 252ca973d3e69ed4e950715c225c016c21bf1561


⚠ Bofrost.de has degraded performance

In a51ad8a, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1136 ms

Resolved: Bofrost.de performance has improved in 9b56721.


support imageRepo with password

What type of PR is this?

/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

/lgtm


Fix the nav bar color

The color should be aligned to the black/grey color around the title div.

we went back to the old navbar so this issue is no longer relevant


[Enhancement] kclvm installation scripts can append the PATH

see here: https://github.com/howieyuen/kusionstack.io/blob/1ac368788b43185122ac08611363bdefd905060b/static/scripts/install-kusion.sh#L167

Close with #31


DatePicker on External Input Element

This should also work.
<DatePicker
    selected={this.state.startDate}
    onChange={this.handleChange}
    className='red-border' >
     <input type='text' placeholder="Enter Date">
</DatePicker>

Or other way.
For me DatePicker is  a not a control. Date Picker should be a Effect on a control.
for example, My desired input can be anywhere or any library can generate it.
We can have a optionally. as User may want to send external input element or not.

I like this idea; here are a couple things I thought of

I think this should probably be exposed as a separate component, possibly DatePickerWrapper to separate logic (currently the DatePicker and the DateInput are pretty tightly coupled).  As a bonus, this could be a mixin, or as an extra bonus, an annotation??
Open state would need to be entirely managed by the user since

we probably don't want to attach random callbacks to the child component
most elements don't have focus/blur state

@rafeememon Probably there is no need to replace whole DateInput. That is really need is to replace native input inside. Looks like its not so hard

@nsisodiya this may be mostly resolved by #551, is that right?

Yep, looks like it. Closing due inactivity.


AMB-970: Object-level Handling & Clone With Offset

Added Rule.clone_with_offset to support Group Check-In's need of retaining multiple RRule objects based on the user's choice but before and after to support creating new Check-Ins, transitioning them prior to the chosen meeting time, and closing the meeting after it is completed.

@somewes This is ready for a review. I believe I didn't make any changes to your POC in https://github.com/ambitioninc/ambition-utils/pull/56 and only added the cloning methods plus tests.
https://github.com/ambitioninc/ambition/pull/10632 is the ambitioninc/ambition changes depending on this. I have all tests passing locally but CI won't pass there until these ambition-utils changes are available.


CherryPy version

Currently we set the CherryPy<9.0 via requirements.txt but I'm actually not keen to keep it on an over 4 years old version forever.
@gmiranda
You mentioned that it performs better, and I see the HTTP engine indeed changed with v9.0: https://github.com/cherrypy/cherrypy/blob/main/CHANGES.rst#v900
However, I tested the newest v18.6.1 (after removing the obsolete and conflicting config to disable timeout monitoring) and it works very well here, no performance drop recognisable. Can you check if you if it's still slower and how I can replicate?

One PR which enables support for any higher CherryPy version without changing something on <9.0: #31

On the newest CherryPy version, also the error about (by client) untrusted self-signed TLS certificate is gone (hidden): https://github.com/HTPC-Manager/HTPC-Manager/pull/28#issuecomment-879246793
It doesn't solve the underlying issue that clients don't trust it, regardless whether imported on OS-level, but at least the logs are not spammed 🙂.

I just learned that the documented engine change is just a structural one, not functional one: Code has been shifted into the dedicated cheroot project but not changed. Of course it developed further afterwards.

Found it. The idle CPU usage is significantly higher. On my VM with CherryPy < 9 it its mostly 0% with a short peak to 1% (average over a second) every ~5 seconds. With CherryPy == 9.0.0 and above, it is never below 1% (average over a second), mostly jumps between 1% and 2%, sometimes 3%. That is multiple times more, on a small SBC likely a real problem.
I further narrowed it down to the cheroot version 8.4.2 (Jul 28, 2020) which introduced this significant idle CPU usage increase. On v8.4.1 this is much lower, but still significantly than with CherryPy 8.x (where cheroot is not used). The earlier idle CPU change occurred from cheroot 8.0.0 to 8.1.0.
Latest CherryPy with cheroot 8.0.0 has nearly identical CPU usage than CherryPy v8.9.1 (with engine included). The centisecond (?) counter in htop raises reliably by 1 every 5 seconds with CherryPy v8.9.1 and reliably every 4 seconds with latest CherryPy + cheroot v8.0.0 (which works even that this CherryPy version declares cheroot>=8.2.1 as requirement).
cheroot v8.1.0 implemented this change which implements a new connection manager to handle idle connections and keep alive requests better. But this seems to imply significantly higher CPU load: https://github.com/cherrypy/cheroot/pull/199
Interestingly v8.4.2 implemented a performance regression "fix" that was implemented exactly with the above PR: https://github.com/cherrypy/cheroot/pull/308
It reduces the connection timeout (?) from 0.1 to 0.01 and I can only assume that some loop it processed hence 10 times more often, leading to the significantly raised idle frequency. It however seems to increase request performance, as the 0.1 delay adds up on request answers, which is now reduced to 0.01s.
Those PRs seem to fix real problems, so we do a trade-off by using the old CherryPy here, regarding concurrent connections and keep alive requests. I'll report/forward those findings to the CherryPy/cheroot team, probably something can be done to reduce overhead on those loops. Also the changelog mentions that "a better fix is yet to come", which I cannot find yet. Probably a push can help 🙂.

Reported: https://github.com/cherrypy/cheroot/issues/378

Found it. The idle CPU usage is significantly higher. On my VM with CherryPy < 9 it its mostly 0% with a short peak to 1% (average over a second) every ~5 seconds. With CherryPy == 9.0.0 and above, it is never below 1% (average over a second), mostly jumps between 1% and 2%, sometimes 3%. That is multiple times more, on a small SBC likely a real problem.
**

That's exactly the issue I ran into. I recall making some changes to support and optimize 9.0 and above, but it was still worse. Glad that you've gone further!

Jep, and there is already a PR open for a long time which fixes the issue. I probably found other ways to further enhance the connection manager, so probably we can make it faster and consume less CPU time on idle then before.

Finally we should have solved it via: https://github.com/cherrypy/cheroot/pull/401
cheroot v8.6.0 has just been released with this change: https://pypi.org/project/cheroot/#history


Internal server error handler

:tada: This issue has been resolved in version 0.12.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Suggestion-Kantele] Hide active player in look view

As a player, when i type the 'look' command, i wouldn't expect to see my own character name in the room description

I did a naive implementation of this by rejecting the current character from the list of characters via pid comparison (using event.from_pid). @oestrich mentioned that we should do something better than comparing pids so i have refactoring in mind to inject the character's actual id into the event ( event.from_character_id or perhaps event.acting_character_id ??)

Fixed in 9a5b15fa7a3c2b29d8ffa81fc33548815dc64fc5
Thanks for reporting!