text:
Error when rub npm start

bon@bon-K72Dr://home/bon/work/redux/examples/counter$ npm start

redux-counter-example@0.0.0 start /home/bon/work/redux/examples/counter
node server.js

events.js:160
throw er; // Unhandled 'error' event
^
Error: listen EADDRINUSE :::3000
at Object.exports._errnoException (util.js:953:11)
at exports._exceptionWithHostPort (util.js:976:20)
at Server._listen2 (net.js:1253:14)
at listen (net.js:1289:10)
at Server.listen (net.js:1385:5)
at EventEmitter.listen (/home/bon/work/redux/examples/counter/node_modules/express/lib/application.js:617:24)
at Object. (/home/bon/work/redux/examples/counter/server.js:17:5)
at Module._compile (module.js:541:32)
at Object.Module._extensions..js (module.js:550:10)
at Module.load (module.js:458:32)
npm ERR! Linux 3.19.0-58-generic
npm ERR! argv "/home/bon/.nvm/v6.2.0/bin/node" "/home/bon/.nvm/v6.2.0/bin/npm" "start"
npm ERR! node v6.2.0
npm ERR! npm  v3.9.0
npm ERR! code ELIFECYCLE
npm ERR! redux-counter-example@0.0.0 start: node server.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the redux-counter-example@0.0.0 start script 'node server.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the redux-counter-example package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node server.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs redux-counter-example
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls redux-counter-example
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /home/bon/work/redux/examples/counter/npm-debug.log

Well, this is the root error: listen EADDRINUSE :::3000.  So, presumably you have something else already running listening on port 3000.  Close any other development servers or stuff you have running, and try again.

authors: Stas-Buzunko markerikson

repo: reactjs/redux


text:
What's up with Gitbook?

I noticed Gitbook added a loading state.

I think it reflects badly on Redux. This is just a static website, why does it need a loading screen? I think it will give a wrong impression that this is how Redux apps behave (even though Gitbook has nothing do with Redux).
Can we please opt out of this change? Or maybe it's time we start migrating away from Gitbook.

This is also not at all how it's intended to look.

The website looks kinda amateur because of this.

Maybe #2846

To be clear I'm not complaining about Gitbook per se, I understand they might have other priorities and it's a free project.
But I'm concerned that we're updating to versions that degrade the user experience and leave it like this for more than a month. The badge situation looks very funny.
The way the title changes is reflective of the worst stereotypes that people have about single-page apps:

I think in the future we should be more intentional about upgrades and watch out for usability issues like this. Especially given that unintentionally reflect both on React and Redux despite the site having nothing to do with them.

For Jest, Prettier, and a bunch of other projects we're now using Docusaurus: https://github.com/facebook/Docusaurus.
Maybe we could look into using it for Redux too? It produces static websites with a mobile-friendly layout that renders Markdown and doesn't have those issues.

@gaearon We're tracking this (GitBook problems) over in #2846.
If we want to move away from GitBook, we can discuss that in a separate issue.

source: gharchive/issue

authors: gaearon taffapsn timdorr

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 Bellshade Website is down

In 323292b, Bellshade Website (https://bellshade.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Bellshade Website is back up in b8a5599 after 8 minutes.


text:
Fixes Issue 774:  Supporting additional cover image extensions

Description
Previously cover images were accepted in .png format only.
This PR allows plays to accept additional image extensions as the preview.
Fixes #774
Type of change
Please delete options that are not relevant.

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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.

Replace cover.png in one of the src/plays/<play_name> directories with cover.jpg or cover.jpeg
Displayed play will now set the new cover image as preview

Checklist:

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

Screenshots or example output

Before: Play with cover.png

After : Replacing cover.png with a new image, cover.jpg

@koustov @atapas any further changes needed that's blocking the merge of this PR?
I'd be happy to make some updates, if required :)

source: gharchive/pull-request

repo: reactplay/react-play


text:
Can't resolve 'reactstrap' when using github master branch

Issue description

components: reactstrap
reactstrap version #master
import method umd/csj/es
react version #16.3.2
bootstrap version #4.1.1

What is happening?
Module not found: Can't resolve 'reactstrap'
when using github master branch
What should be happening?
should not error just like the released version
Steps to reproduce issue

create-react-app
yarn add https://github.com/reactstrap/reactstrap.git#master
call any component from reactstrap

Error message in console
Failed to compile.

./src/App.js
Module not found: Can't resolve 'reactstrap' in '/home/user/reactstrapbeta/src'

If you add from github, you only have src files. You must "build" dist files from src files in order to use it.

This is correct, reactstrap doesn't check in dist files. You can either build the dist or reference the /src/index directly and instruct your build/bundling tool to babel the contents of it (not 100% sure if that last thing will work, but it seems like it would based on how some other component libraries get away with not having a dist at all)

npm install --save reactstrap react react-dom

Thank  you, it helped me npm install --save reactstrap react react-dom

authors: Nguyenau Samiys TheSharpieOne buncismamen locpd

repo: reactstrap/reactstrap

license: mit

license_source: bigquery


text:
infinite loader / spinner with SVG in reflow

https://readium.firebaseapp.com/?epub=https%3A%2F%2Fcdn.rawgit.com%2FIDPF%2Fepub-testsuite%2Fmaster%2Fcontent%2F30%2Fepub30-test-0100&epubs=epub_content%2Fepub_testsuite.opds

also with Chrome app
https://twitter.com/lapprimerie/status/864134384890388480

Fixed: https://github.com/readium/readium-shared-js/commit/94b83a1cda376091838a91cff6258f4cb452f54f

CC @JCCR (FYI)

repo: readium/readium-js-viewer


text:
Add multiple colors

test

aa


text:
Add methods to direct buffer for putting and getting numbers encoded as ASCII

Natural numbers
Signed numbers
Decimal numbers
Should be implemented allocation free.

Artio actually already has methods for this on its AsciiBuffer. I'm happy to PR the additions if you want.

It would be good to migrate some of them. The implementations from Artio could be better optimised, e.g. single bounds check rather than byte by byte, plus a few other refinements. Artio could then use the versions in Agrona.

I'm just taking a look at this issue now. What are your thoughts on the correct behaviour for getting a numeric value if the ascii encoded bytes aren't with the range '0' - '9' ? For example I call getInt(4, 3) and the bytes in that range are 'abc'. At the moment I throw an Exception rather than just returning the wrong number but I wonder if that's really the responsibility of the Buffer or of the caller.

Thanks @RichardWarburton. I think it should throw a NumberFormatException when not containing 0-9 or -.

We should offer the parsing of int and long. I think methods should be named parseIntAscii and parseLongAscii to indicate they are performing a parse operation. With the other way being putIntAscii and putLongAscii respectively.

Cool, thanks for the feedback.
There's also the issue of floats. In Artio we have our own DecimalFloat class that is used for precise encoding of values and can be parsed/written. Is it worth bringing this into Agrona as well, or just using plain Java floats.

I think for now ints and longs are sufficient and we can decide in time how to handle decimals and floats.

repo: real-logic/agrona


text:
Covert to ARC

Development of Sockit has stalled, so I've brought the project more in line with a modern Objective C style.

Getting an update on this today had me seriously scratching my head.

same lol

Yeah I don’t think this will get merged 🤠
Cheers,
Jesse

On 24 Feb 2019, at 10:29 am, Oliver Jones notifications@github.com wrote:
Getting an update on this today had me seriously scratching my head.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

authors: jessedc orj sync

repo: realestate-com-au/sockit


text:
Test for QuasiQuotes

fix #59
The purpose of refactoring
My purpose of 2c889cf is...

to use a more natural way.

To abort the computation, use fail.
https://hackage.haskell.org/package/template-haskell-2.15.0.0/docs/Language-Haskell-TH.html#g:2

to make error states easier to handle.

Side effect of the refactoring
By 2c889cf , compile-time error messages are changed.
I think but this change is good. They get more simple.
Before:
/Users/ikngtty/Projects/src/github.com/realglobe-Inc/hrafnar/server-test/Hrafnar/ParserSpec.hs:69:25: error:
    • Exception when trying to run compile-time code:
        multiple characters
CallStack (from HasCallStack):
  error, called at util/Hrafnar/Util.hs:29:20 in hrafnar-0.1.0.0-Jqfmt167IwoGCyqBIvYRaG-hrafnar-util:Hrafnar.Util
      Code: Language.Haskell.TH.Quote.quoteExp rawC "ab"
    • In the quasi-quotation: [rawC|ab|]
   |
69 |             Lit' (Char' [rawC|ab|])
   |                         ^^^^^^^^^^

After:
/Users/ikngtty/Projects/src/github.com/realglobe-Inc/hrafnar/server-test/Hrafnar/ParserSpec.hs:69:31: error:
    • multiple characters
    • In the quasi-quotation: [rawC|ab|]
   |
69 |             Lit' (Char' [rawC|ab|])
   |                               ^^^^

Great! It might be pleased in Haskell community, if you summarize to an article.

I think that too.  And I want to bundle that code into a package and publish it to Stackage.
But these tasks are a little heavy. I'll do it when I have plenty of time.

repo: realglobe-Inc/hrafnar

license: WTFPL


text:
Anyways to get this working with ollama

Kind of a noonish I really dig what your doing but open ai going to be adding quick when releasing to madness I want to use open source is there ways to do this only with the ollama

Yes, I just pushed update to dev branch that supports ollama. I added some support for it a while back and never updated. Let me add some documentation for it.

I added ollama support for embeddings, between that and koboldcpp you can do everything locally. I added documentation on how to switch to it in the readme. To edit ollama settings you will need to change them in embeddings.py (for instance switching the ollama model or the url.)

authors: TheMindExpansionNetwork reality-comes

repo: reality-comes/discordrp


text:
Misc docs additions

Small additions to 2 of the READMe's

Awesome! Thanks for that David! I'll take it from here and flesh it out some more. :)

Alrighty, I added some more detail to both the root, and iOS READMEs!

authors: TimOliver dhmspector

repo: realm-demos/realm-loginkit


text:
Failable initializer crashes for realm objects

I am using realm 0.98.1,  have following failable initializer
   convenience init?(message: [String: AnyObject]) {
      guard let x = message["x"] as? Double else {
            return nil
      }

When init returns nil this code crashes (EXC_BAD_ACCESS) with stack:
#0	0x0000000180b0953c in pthread_mutex_lock ()
#1	0x000000010188489c in realm::Table::unregister_row_accessor(realm::RowBase*) const ()
#2	0x000000010187d908 in realm::RowBase::impl_detach() ()
#3	0x00000001016ff3c8 in realm::BasicRow<realm::Table>::~BasicRow() at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa-master/core/include/realm/row.hpp:761
#4	0x000000018050eb54 in object_cxxDestructFromClass(objc_object*, objc_class*) ()
#5	0x000000018051a080 in objc_destructInstance ()
#6	0x00000001028215b4 in swift_deallocUninitializedClassInstance ()

This looks like a Swift bug to me. The base class's destructor is run even if you return before calling the designated initializer, which will then generally crash because it's operating on uninitialized garbage data. As a workaround you'll need to call self.init() before returning.

Filed a swift bug: https://bugs.swift.org/browse/SR-745

Closing as I believe the Swift bug is now fixed.

authors: Igor-Palaguta jpsim tgoyne

repo: realm/realm-cocoa


text:
Better handling of ARC-related property names

Goals
Report a brutal bug.
Expected Results
Not Crash
Actual Results
Crash
Steps to Reproduce
Add data contain unicode
Get that unicode data --> crash
Code Sample
import Cocoa
import RealmSwift

@NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate { //EXC_BAD_ACCESS at this line

    @IBOutlet weak var window: NSWindow!

    func applicationDidFinishLaunching(_ aNotification: Notification) {
        // Insert code here to initialize your application
        Database.add()
        _ = Database.get()
    }
}

class Database {
    static var realm: Realm {
        return try! Realm()
    }

    static func add() {
        try! realm.write {
            realm.add(NamerObject())
        }
    }

    static func get() -> String? {
        return realm.objects(NamerObject.self).first?.newName
    }
}

class NamerObject: Object {
    dynamic var newName: String = "tên mới"
}

If you want to test yourself, complete project here:
RealmUnicode.zip
Version of Realm and Tooling
Realm version: Newest
(i just add github "realm/realm-cocoa" in my Cartfile and run carthage update this morning, nothing else)
Xcode version: Version 8.1 (8B62)
Swift version: 3.0.1
OSX: 10.11.6 (15G1108)
Pretty sure it happens with swift 2.3 xcode 8.0 too. I doubt that this happen in many platforms and versions
What cause the bug:
Property name begins with "new*" like "newA, newB, newXXX"
How to fix
change
dynamic var newName: String = "tên mới"

to
dynamic var name: String = "tên mới" // or do whatever that not use "new*" for property name

Broke-in-tear comment:
It took me tons of time to figure out why it crash while there're no clue about it, i have to cut of my code many, many time to the version that i reported.
Hope Realm team can fix or at least warn other about this because bug like this is so brutal, it might cause nightmare to other (like what happen to me)

Thank you for reporting this issue and for the example project, @hunganh0403! I was also able to reproduce it, the crash happens during the autorelease pool draining. With memory management diagnostics turned on it seems that the resulting string was deallocated somewhere outside the autorelease pool.
*** -[CFString release]: message sent to deallocated instance 0x60004213bfe0

/cc @bdash, @tgoyne

ARC assigns special meaning to selectors starting with new, alloc, copy, mutableCopy, and init, which applies to dynamic properties in Swift. We should probably either reject properties with such names or try to return a non-autoreleased object from them.

The issue also depends on the default value for this property: if some other string is specified the issue doesn't reproduce.

I believe this was fixed with 2.4.3. From the release notes:
* Reject Swift properties with names which cause them to fall in to ARC method
  families rather than crashing when they are accessed.

Closing this ticket.

authors: austinzheng hunganh0403 stel tgoyne


text:
Deadlock after receiving a "N5realm10LogicErrorE: Bad version number "

May be a duplicate / follow up of #4428 and #4649
Goals
Just using Realm.
Expected Results
No bugs, no freeze, no warnings.
Actual Results
I'm getting this using Realm v2.4.4, but I got a customer getting that same freeze using v2.0.4, so I was wrong when I was saying that issue was introduced after 2.0.4 (cf the previous issue).
The app is freezing after logging "N5realm10LogicErrorE: Bad version number".
Looks like a deadlock (since the audio is still playing, just the interface won't respond anymore)
Here the full stack trace from Xcode when the app has entered in the deadlock:
* thread #1: tid = 0x14ac3, 0x000000018f6cae1c libsystem_kernel.dylib`__psynch_cvwait + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x000000018f6cae1c libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x000000018f7909c0 libsystem_pthread.dylib`_pthread_cond_wait + 640
    frame #2: 0x000000018f0b93ec libc++.1.dylib`std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 56
    frame #3: 0x0000000101e629f4 Realm`realm::_impl::NotifierPackage::package_and_wait(realm::util::Optional<unsigned long long>) [inlined] void std::__1::condition_variable::wait<std::__1::unique_lock<std::__1::mutex> realm::_impl::RealmCoordinator::wait_for_notifiers<realm::_impl::NotifierPackage::package_and_wait(realm::util::Optional<unsigned long long>)::$_12>(realm::_impl::NotifierPackage::package_and_wait(realm::util::Optional<unsigned long long>)::$_12&&)::'lambda'()>(this=<unavailable>, __pred=<unavailable>)::$_12) + 204 at __mutex_base:345 [opt]
    frame #4: 0x0000000101e62988 Realm`realm::_impl::NotifierPackage::package_and_wait(realm::util::Optional<unsigned long long>) [inlined] std::__1::unique_lock<std::__1::mutex> realm::_impl::RealmCoordinator::wait_for_notifiers<realm::_impl::NotifierPackage::package_and_wait(this=<unavailable>)::$_12>(realm::_impl::NotifierPackage::package_and_wait(realm::util::Optional<unsigned long long>)::$_12&&) + 32 at realm_coordinator.hpp:175 [opt]
    frame #5: 0x0000000101e62968 Realm`realm::_impl::NotifierPackage::package_and_wait(this=<unavailable>, target_version=<unavailable>) + 64 at collection_notifier.cpp:422 [opt]
    frame #6: 0x0000000101f4c124 Realm`(anonymous namespace)::KVOTransactLogObserver::parse_complete(this=<unavailable>) + 1208 at transact_log_handler.cpp:639 [opt]
    frame #7: 0x0000000101f4b024 Realm`bool realm::SharedGroup::do_advance_read<(anonymous namespace)::KVOTransactLogObserver>(this=<unavailable>, observer=<unavailable>, version_id=<unavailable>, hist=<unavailable>)::KVOTransactLogObserver*, realm::VersionID, realm::_impl::History&) + 300 at group_shared.hpp:1058 [opt]
    frame #8: 0x0000000101f4214c Realm`realm::_impl::transaction::begin(std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> > const&, realm::BindingContext*, realm::_impl::NotifierPackage&) + 72 at group_shared.hpp:960 [opt]
    frame #9: 0x0000000101f42104 Realm`realm::_impl::transaction::begin(std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> > const&, realm::BindingContext*, realm::_impl::NotifierPackage&) [inlined] void realm::_impl::SharedGroupFriend::promote_to_write<(anonymous namespace)::KVOTransactLogObserver>(sg=0x00000001058a3600)::KVOTransactLogObserver*) at group_shared.hpp:1120 [opt]
    frame #10: 0x0000000101f42104 Realm`realm::_impl::transaction::begin(std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> > const&, realm::BindingContext*, realm::_impl::NotifierPackage&) [inlined] void realm::LangBindHelper::promote_to_write<(anonymous namespace)::KVOTransactLogObserver>(sg=0x00000001058a3600)::KVOTransactLogObserver&&) at lang_bind_helper.hpp:349 [opt]
    frame #11: 0x0000000101f42104 Realm`realm::_impl::transaction::begin(std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> > const&, realm::BindingContext*, realm::_impl::NotifierPackage&) [inlined] auto realm::_impl::transaction::begin(std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> > const&, realm::BindingContext*, realm::_impl::NotifierPackage&)::$_1::operator()<(anonymous namespace)::KVOTransactLogObserver>((anonymous namespace)::KVOTransactLogObserver&&) const + 4 at transact_log_handler.cpp:706 [opt]
    frame #12: 0x0000000101f42100 Realm`realm::_impl::transaction::begin(std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> > const&, realm::BindingContext*, realm::_impl::NotifierPackage&) [inlined] void (anonymous namespace)::advance_with_notifications<realm::_impl::transaction::begin(context=<unavailable>, sg=0x0000000104c52298)::$_1>(realm::BindingContext*, std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> > const&, realm::_impl::transaction::begin(std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> > const&, realm::BindingContext*, realm::_impl::NotifierPackage&)::$_1&&, realm::_impl::NotifierPackage&) + 476 at transact_log_handler.cpp:674 [opt]
    frame #13: 0x0000000101f41f24 Realm`realm::_impl::transaction::begin(sg=0x0000000104c52298, context=<unavailable>, notifiers=0x000000016fd294f0) + 40 at transact_log_handler.cpp:705 [opt]
    frame #14: 0x0000000101e7f7ac Realm`realm::_impl::RealmCoordinator::promote_to_write(this=0x0000000104c1a6b8, realm=<unavailable>) + 148 at realm_coordinator.cpp:777 [opt]
    frame #15: 0x0000000101f2db44 Realm`realm::Realm::begin_transaction(this=0x0000000104c521a8) + 168 at shared_realm.cpp:458 [opt]
    frame #16: 0x0000000101f111e0 Realm`::-[RLMRealm beginWriteTransaction](self=<unavailable>, _cmd=<unavailable>) + 28 at RLMRealm.mm:443 [opt]
    frame #17: 0x0000000101f114d8 Realm`::-[RLMRealm transactionWithBlock:error:](self=0x00000001740bf380, _cmd=<unavailable>, block=<unavailable>, outError=0x0000000000000000)(), NSError **) + 52 at RLMRealm.mm:488 [opt]
    frame #18: 0x0000000101f1149c Realm`::-[RLMRealm transactionWithBlock:](self=<unavailable>, _cmd=<unavailable>, block=<unavailable>)()) + 24 at RLMRealm.mm:484 [opt]
    frame #19: 0x0000000101b96624 ****`-[**** ****:](self=0x00000001702267e0, _cmd="****:", idx=0) + 268 at ****.m:291
    frame #20: 0x0000000101b97140 ****`-[**** ****](self=0x00000001702267e0, _cmd="****") + 76 at ****.m:332
    frame #21: 0x0000000101b927a4 ****`-[**** ****](self=0x00000001702267e0, _cmd="****") + 40 at ****.m:62
    frame #22: 0x00000001001000a4 ****`-[**** ****:](self=0x00000001058ade00, _cmd="****:", sender=0x00000001058e3000) + 112 at ****:284
    frame #23: 0x00000001965e7d30 UIKit`-[UIApplication sendAction:to:from:forEvent:] + 96
    frame #24: 0x00000001965e7cb0 UIKit`-[UIControl sendAction:to:forEvent:] + 80
    frame #25: 0x00000001965d2128 UIKit`-[UIControl _sendActionsForEvents:withEvent:] + 452
    frame #26: 0x00000001965e759c UIKit`-[UIControl touchesEnded:withEvent:] + 584
    frame #27: 0x00000001965e70c4 UIKit`-[UIWindow _sendTouchesForEvent:] + 2484
    frame #28: 0x00000001965e2328 UIKit`-[UIWindow sendEvent:] + 2988
    frame #29: 0x00000001965b2da0 UIKit`-[UIApplication sendEvent:] + 340
    frame #30: 0x0000000196d9c75c UIKit`__dispatchPreprocessedEventFromEventQueue + 2736
    frame #31: 0x0000000196d96130 UIKit`__handleEventQueue + 784
    frame #32: 0x00000001906aab5c CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
    frame #33: 0x00000001906aa4a4 CoreFoundation`__CFRunLoopDoSources0 + 524
    frame #34: 0x00000001906a80a4 CoreFoundation`__CFRunLoopRun + 804
    frame #35: 0x00000001905d62b8 CoreFoundation`CFRunLoopRunSpecific + 444
    frame #36: 0x000000019208a198 GraphicsServices`GSEventRunModal + 180
    frame #37: 0x000000019661d7fc UIKit`-[UIApplication _run] + 684
    frame #38: 0x0000000196618534 UIKit`UIApplicationMain + 208
    frame #39: 0x00000001002050b4 ****`main + 140 at AppDelegate.swift:21
    frame #40: 0x000000018f5b95b8 libdyld.dylib`start + 4

I replaced the app symbols by **** because I can't post it in public. However, I can share the full stack by email if that help.
Steps to Reproduce
Once again, I don't have an easy way to reproduce it. It's a global environment issue: having a few realm transactions running at the same time, after a few more, it will freeze.
In this context, my realm is storing around 50k objects, not sure if that can change something.
Code Sample
Sadly, don't have one... but I will try right now to make a sample project reproducing that issue since I have a better idea of the context.
Version of Realm and Tooling
Realm version: 2.4.4
Xcode version: 8.2.1
iOS/OSX version: iOS 10.2.1
Dependency manager + version: Carthage 0.20.1

More input: it seems that I'm able to reproduce it only when I have a few dozens of objects in Realm, and only if I'm doing live updates on realm objects (meaning for example synchronising a full catalog of song, so the object state will changed every few seconds).
If don't have a large database, and doing these real time changes, I can't reproduce it. So, it's probably a different case than #4428 since it was reproductible without these both conditions.

More input: I can also reproduce it by firing manual realm transaction (by clicking on buttons in the app), it seems to freeze when two transactions are starting / ending at the same time, race condition?

Hi @tbaranes! Thanks for the info! Sorry to hear you're having some trouble here.
There's probably not a lot we can do without a sample app to let us properly examine what's going on here. Would you even be able to post some sample code of the actual write transaction that's causing this failure? You can email it to help@realm.io if you need to keep it private.
Thanks!

Sorry for the delay @TimOliver, I had a few things to do and didn't get the time to answer.
I just sent an email with more information and a few lines of code, hope that helps.
Also, I tried v4.5.0, but the bug is still here (no miracle here 😬 )

Hanging forever in beginWriteTransaction or refresh after an error occurs  on the notification worker thread is expected, as it's waiting for the notification worker to finish its current set of work and that'll never happen. As a result, the state of things when the actual freeze happens isn't very interesting; it's what leads to the LogicError(bad_version) being thrown that matters.
The stack trace when the exception is thrown might be somewhat informative, if you can enable exception breakpoints in Xcode and then trigger the problem.

@tgoyne Here the stack trace when exception is thrown (and catch by exception breakpoints):
Realm was compiled with optimization - stepping may behave oddly; variables may not be available.
* thread #21, name = 'RLMRealm notification listener', stop reason = breakpoint 1.1
    frame #0: 0x000000018f122efc libc++abi.dylib`__cxa_throw
  * frame #1: 0x0000000101ebda7c Realm`void realm::LangBindHelper::advance_read<(anonymous namespace)::TransactLogValidator>(realm::SharedGroup&, (anonymous namespace)::TransactLogValidator&&, realm::VersionID) [inlined] void realm::SharedGroup::advance_read<(anonymous namespace)::TransactLogValidator>(this=<unavailable>)::TransactLogValidator*, realm::VersionID) at group_shared.hpp:934 [opt]
    frame #2: 0x0000000101ebd9b0 Realm`void realm::LangBindHelper::advance_read<(anonymous namespace)::TransactLogValidator>(realm::SharedGroup&, (anonymous namespace)::TransactLogValidator&&, realm::VersionID) [inlined] void realm::_impl::SharedGroupFriend::advance_read<(anonymous namespace)::TransactLogValidator>(sg=<unavailable>)::TransactLogValidator*, realm::VersionID) at group_shared.hpp:1114 [opt]
    frame #3: 0x0000000101ebd9b0 Realm`void realm::LangBindHelper::advance_read<(anonymous namespace)::TransactLogValidator>(sg=<unavailable>, observer=<unavailable>, version=<unavailable>)::TransactLogValidator&&, realm::VersionID) at lang_bind_helper.hpp:335 [opt]
    frame #4: 0x0000000101ebd984 Realm`realm::_impl::transaction::advance(sg=<unavailable>, (null)=<unavailable>, version=<unavailable>) at transact_log_handler.cpp:688 [opt]
    frame #5: 0x0000000101dfbc90 Realm`realm::_impl::RealmCoordinator::run_async_notifiers(this=0x000000011de55a48) at realm_coordinator.cpp:652 [opt]
    frame #6: 0x0000000101dfb764 Realm`realm::_impl::RealmCoordinator::on_change(this=0x000000011de55a48) at realm_coordinator.cpp:463 [opt]
    frame #7: 0x0000000101de2d80 Realm`realm::_impl::ExternalCommitHelper::listen(this=0x0000000170241e90) at external_commit_helper.cpp:217 [opt]
    frame #8: 0x0000000101de3e4c Realm`std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>::operator()() [inlined] realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0::operator()() const at external_commit_helper.cpp:159 [opt]
    frame #9: 0x0000000101de3e48 Realm`std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>::operator()() [inlined] std::__1::__invoke<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>(decltype(std::__1::forward<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>(fp)(std::__1::forward<>(fp0))), realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0&&) at __functional_base:416 [opt]
    frame #10: 0x0000000101de3e44 Realm`std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>::operator()() [inlined] _ZNSt3__112__async_funcIZN5realm5_impl20ExternalCommitHelperC1ERNS2_16RealmCoordinatorEE3$_0JEE9__executeIJEEEvNS_15__tuple_indicesIJXspT_EEEE(this=<unavailable>) at future:2348 [opt]
    frame #11: 0x0000000101de3e44 Realm`std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>::operator(this=<unavailable>)() at future:2341 [opt]
    frame #12: 0x0000000101de3dd4 Realm`std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::__execute(this=0x000000017012e6a0) at future:1031 [opt]
    frame #13: 0x0000000101de3f98 Realm`std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*> >(void*, void*) [inlined] std::__1::__invoke<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*, void>(decltype(*(std::__1::forward<std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*>(fp0)).*fp(std::__1::forward<>(fp1))), void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*&&)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*&&) at __functional_base:383 [opt]
    frame #14: 0x0000000101de3f7c Realm`std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*> >(void*, void*) [inlined] _ZNSt3__116__thread_executeIMNS_19__async_assoc_stateIvNS_12__async_funcIZN5realm5_impl20ExternalCommitHelperC1ERNS4_16RealmCoordinatorEE3$_0JEEEEEFvvEJPSA_EJLm1EEEEvRNS_5tupleIJT_DpT0_EEENS_15__tuple_indicesIJXspT1_EEEE at thread:347 [opt]
    frame #15: 0x0000000101de3f7c Realm`std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >*> >(__vp=0x0000000170220480) at thread:357 [opt]
    frame #16: 0x000000018f791850 libsystem_pthread.dylib`_pthread_body + 240
    frame #17: 0x000000018f791760 libsystem_pthread.dylib`_pthread_start + 284
    frame #18: 0x000000018f78ed94 libsystem_pthread.dylib`thread_start + 4

Does that help? 🤔

This should be fixed by https://github.com/realm/realm-object-store/pull/424.

Good to know! Let me know when it will be available in realm-cocoa, I will test it again. Also, is realm-object-store embed in realm-cocoa even if we are not using it?

Since #4813 has been merged, I tested the master version, seems to be fixed! Thanks 🤘

Glad to hear it!

authors: TimOliver jpsim tbaranes tgoyne


text:
Move Mac, Android build to the pipeline job

We now have linux builds running with a Jenkinsfile.  This means we can now port the mac build to the Jenkinsfile and run all supported platforms with one pipeline.
@fealebenpae @ironage
Related to #194

Looks like the Mac side was taken care of in #212.

@alebsack / @emanuelez, is adding an Android CI job something that you'd be able to tackle? Even just testing compilation for the supported architectures would be a good first step. We also have #208 tracking running the unit tests on devices.

@bdash Yeah, I have a WIP PR here: #221

authors: alebsack bdash

repo: realm/realm-object-store


text:
Strip back

about me and nav bar chNGES

header changes

repo: realstoman/nextjs-tailwindcss-portfolio


text:
If ream.config.js throws it is silently ignored

Steps to reproduce
Create ream.config.js:
const path = require('path')
module.exports = {
  entry: 'myentry.js',
  plugins: [
    require('no/such/package')()
  ]
}

Run npm-run ream dev
Expected result
Somehow Error: Cannot find module 'no/such/package' is printed.
Actual result
ream.config.js is ignored altogether.

It's a bug in a dependency, should be fixed if you re-install ream.

Thanks. yarn remove ream && yarn add ream fixed it indeed.

authors: IlyaSemenov egoist

repo: ream/ream


text:
how to have tree structure in routes?

Just want to organize folder structure and willing to be reflected in routes. Like...
components/articles/Index.jsx => /articles/index
components/articles/View.jsx => /articles/View
The snippet I've tried not working as expected:
router(require,
  route('home', '/',
    route('sub')
  ),
  route('articles',
    route('index'),
    route('view')
  )
);

It structures it like so:
components/Articles
components/articles/View
rather than using Index, though that would be a nice option. I'd be open to a pull request.

with the routes like
router(require,
  route('home', '/',
    route('sub')
  ),
  route('articles',
    route('view')
  )
);

The button
<Button onTap={() => this.router().transitionTo('articles')}>

returned error messages: Error: Invariant Violation: Cannot find a route named "articles"

I believe you'd need articles to be inside of home:
router(require,
  route('home', '/',
    route('articles',
      route('view', '/articles/:id')
    )
  ),
);

Which would give you /articles and /articles/1

I'm kind of confused of how to have a tree structured routes, can you put out some examples of it?

I don't understand this router at all:

Warning: No route matches path "/". Make sure you have  somewhere in your routes

router(require,
	route('auth', '/foo'),
	route('home', '/',
		route('sub')
	)
);

authors: Tjorriemorrie kiang natew wuichen

repo: reapp/reapp-routes


text:
Use [@bs.unwrap] for transforms

@bs.unwrap (https://bucklescript.github.io/bucklescript/Manual.html#_using_polymorphic_variant_to_model_arguments_of_multiple_possible_types_since_1_8_3) can unwrap polymorphic variants to only pass the underlying value. This means we can have a nicer way to model transforms:
~transform=[|
   `translateY({translateY}),
|]

instead of:
~transform=[|
  translateY(~translateY),
|]

BTW we can keep the old function around.

I see more char on the first snippet than the second one.
What are the benefits?

@jfrolich up to my previous question: what is the point of the change? Are the bindings less verbose somehow?

Yeah was just an idea, but agree it's probably not worth a change.

authors: MoOx jfrolich

repo: reason-react-native/reason-react-native


text:
@react-navigation v5

We need to cover v5, bindings should be much simpler (because api is).
I will create a branch & a PR if I can make something usable (for now will keep them local to my project).
If anyone have something, please share even if that's WIP
poke @cem2ran @cknitt

WIP started here https://github.com/reason-react-native/reason-react-navigation/tree/v5

Bs 7 version here https://github.com/reason-react-native/reason-react-navigation/tree/v5-bs7
We need to delete v5 & publish v5-bs7 after being sure we handled this https://reactnavigation.org/blog/2020/02/06/react-navigation-5.0.html#a-note-for-alpha-users

Master already point to v5!


text:
Website is not available in Russia

Because RKN blocked some subnet of IPs where Netlify has its CDN, rebassjs.org is blocked in Russia. I can use VPN of course but it is better to setup redirects to now.sh in case request is from Russia (if it is possible)
Netlify forum topic

Thanks for the heads-up! Since this sounds like an issue with Netlify, I'm not sure there's much I can do from here

:(

authors: jxnblk talentlessguy

repo: rebassjs/rebass


text:
user story: trigger a sequence

[ ] record multiple lighting takes
[ ] cut them
[ ] filter them
[ ] combine them
[ ] store a new sequence
[ ] trigger that one time when I play a MIDI note higher than pitch X.

The big difficulty is how to select a sub region of a tech. Right now, I cannot select in the mapplotlib window.

That looks very hard so let's do something easier.

Record a take, saved automatically by timestamp
Takes aren't saved
Select between takes in lower window
there are slider/number controls for the selection in a pane below:

begin
end
which tracks are included

You can save that selection as a named file

We are going to need these new commands:

record

stop

clear recordings

shift selection

bigger

left
right

smaller

left
right

save segment

Two different sorts of recordings.

"anonymous" timestamp only ones
A segment

repo: rec/litoid


text:
Got a postgres/libpq-dev dependency error while installing recap-core

I was trying to install recap-core and I got this error -

Took me a couple of reads before I realized what I was missing.
Added the minor guideline in PR #72

Thanks for the PR! This is helpful, though I don't want to put it in the README--there are a lot of these types of issues with Python. Instead, I think I'm going to convert this issue to a Q&A discussion, and put your answer in it. That way it's discoverable from Google.

authors: abhiramr criccomini

repo: recap-cloud/recap


text:
Update README.md

https://github.com/TusharAMD/SuperSpeechSaga/issues/101

@sanjay-kv
This one too
Please mark as level 1 and merge it as it is already marked as level 1 but not merged

repo: recodehive/Opensource-practice


text:
➕Add Hamburger to the website and Make it Responsive

Hey @sanjay-kv
I want to add a hamburger menu to the website because the current navbar is causing responsiveness issues.
The navbar is not adjusting correctly on smaller screens and is extending beyond the viewport body.
Implementing a hamburger menu will help in making the navigation more responsive and user-friendly on mobile devices.

Could you please assign me with this?
thankyou!

How this going @aslams2020

@sanjay-kv Was Completing Other repos tasks,will do this today itself..

repo: recodehive/awesome-github-profiles


text:
Fix typo in README

Was checking this project out and noticed a small typo in the readme where it links to the latest release of recogito-js instead of this repo's latest release.
This fixes that typo.

Hey, well spotted! Many thanks! :-)

authors: bibliotechy rsimon

repo: recogito/annotorious


text:
Odd behavior for some labels in TokenClassificationRecord

Describe the bug
For a TokenClassificationRecord, some of the predictions don't show up correctly. As shown in the image below, the word 'Snoring' isn't underlined like the word 'Fatigue' is. And when I hover over 'Snoring' the expected pop up is displayed without color. For context, we have many labels (~100).
To Reproduce
Steps to reproduce the behavior:

Upload many TokenClassifcationRecords with many labels and predictions.

Expected behavior
All tokens that correspond to predictions are displayed in the same manner. Underlined with a color, etc...
Screenshots

Environment (please complete the following information):

OS [e.g. iOS]: Linux / Mac
Browser [e.g. chrome, safari]: Chrome
Rubrix Version [e.g. 0.10.0]: 0.13.0
ElasticSearch Version [e.g. 7.10.2]:
Docker Image (optional) [e.g. rubrix:v0.10.0]:

Quick fix

[ ] Rotate the color every 50 labels endlessly

authors: Amelie-V coreyelowsky

repo: recognai/rubrix


text:
[Search] Enable results highlighting for textual fields

Find a way to return highligthting info with search results. We can exploit the elasticsearch highlighting keeping in mind that, for text classification, highlighting for multiple fields is not trivial when no default string searches.
For example, given a dataset with records including  inputs.subject and inputs.body the query:
size weight

could match terms in inputs.subject, inputs.body or both.
But, if we select a field in query:
inputs.subject: (size weight)

the highlight results could bring info for both fields subject and body, resulting in highlighting information that is not totally truthful

I think we could live with this "additional" highlighting info, as long as the highlights of the original query are present.

Since the computed highlighting won't be totally accurate and for the sake of performance, we can return only the relevant terms in search that makes record match.
What do you think @dvsrepo @dcfidalgo ???
The client (UI and client) could build the needed highlighting with those keywords.

Could you maybe provide an example of a query, record, and the returned terms you have in mind? Maybe we can also have a quick call about that.

The PR #1201 implements what I propose.
The query list* will match following records text:
- The listener can be implemente....
- Last listen in spotify was .....
- People is listening som.....
- Google is listed as the comp....

And the records keywords suggested in response should be:
- ["listener"]
- ["listen"]
- ["listening"]
- ["listed"]

Yes, let's have a discussion about this. Maybe one comment ahead, not sure what the workflow of our WS for token classification will be, but maybe it would be helpful to also return start, end char indexes of the returned keywords. Not sure if this is technically possible.

authors: dcfidalgo frascuchon


text:
Adding "dot" to the BASH function definition

Splitting a large PR into smaller ones — this one adds "." (dot) to the list of allowed characters in a BASH function name, since function names like git.squash are allowed.

@kigster: Thanks! Tests are failing, however, could you check? — https://github.com/reconquest/shdoc/runs/1651714739#step:4:135

@kigster: Thanks! Tests are failing, however, could you check? — https://github.com/reconquest/shdoc/runs/1651714739#step:4:135

Yup, looking.

Yup, looking.

You can't pass more than one argument for shebang @seletskiy
ср, 6 янв. 2021 г., 13:55 Stanislav Seletskiy notifications@github.com:

@seletskiy commented on this pull request.
In shdoc
https://github.com/reconquest/shdoc/pull/28#discussion_r552505711:

@@ -1,5 +1,6 @@
-#!/usr/bin/gawk -f

+##!/bin/sh
I do not have access to the Mac environment, but shouldn't #!/usr/bin/env
-S gawk -f be sufficient here?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/reconquest/shdoc/pull/28#pullrequestreview-562567149,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACAN7ZH577D6US5FZB6CIODSYQ6S7ANCNFSM4VVZX6CQ
.

You can't pass more than one argument for shebang @seletskiy
ср, 6 янв. 2021 г., 13:55 Stanislav Seletskiy notifications@github.com:

@seletskiy commented on this pull request.
In shdoc
https://github.com/reconquest/shdoc/pull/28#discussion_r552505711:

@@ -1,5 +1,6 @@
-#!/usr/bin/gawk -f

+##!/bin/sh
I do not have access to the Mac environment, but shouldn't #!/usr/bin/env
-S gawk -f be sufficient here?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/reconquest/shdoc/pull/28#pullrequestreview-562567149,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACAN7ZH577D6US5FZB6CIODSYQ6S7ANCNFSM4VVZX6CQ
.

@kovetskiy you can by using -S argument for env:
       -S, --split-string=S
              process and split S into separate arguments; used to pass multiple arguments on shebang lines

@kovetskiy you can by using -S argument for env:
       -S, --split-string=S
              process and split S into separate arguments; used to pass multiple arguments on shebang lines

I left a comment on that commit with the reference:
The /bin/sh solution was based on the answers to
https://unix.stackexchange.com/questions/97141/distributing-a-script-should-i-use-bin-gawk-or-usr-bin-gawk-for-shebang
Basically yes I couldn't make it work consistently on OS-X and Linux. On a Mac gawk is installed into /usr/local/bin while on Linux its is /usr/bin.
The sh solution works across all systems and I believe is much more portable 😎

I left a comment on that commit with the reference:
The /bin/sh solution was based on the answers to
https://unix.stackexchange.com/questions/97141/distributing-a-script-should-i-use-bin-gawk-or-usr-bin-gawk-for-shebang
Basically yes I couldn't make it work consistently on OS-X and Linux. On a Mac gawk is installed into /usr/local/bin while on Linux its is /usr/bin.
The sh solution works across all systems and I believe is much more portable 😎

Is there a blocker for this? I applied the updated, original patch, and removed the changes to the shebang and the script began to work with function names with dots, with all tests passing:

Is it possible to just merge in those changes to the regex to work with functions with dots? It seems the shebang is being addressed again in PR #35, and adding these changes one at a time is likely a good idea

Closing in favor of #36

authors: eankeen kigster kovetskiy seletskiy

repo: reconquest/shdoc


text:
GNOME + Calamares

update nixpkgs and remove KDE
move graphical options into separate file
flake.lock: update RedNix
remove kde files
change xfce to gnome
GTK colors: remove _breeze

Is there any reason why, you'd change to GNOME precisely and not any other WM ? Why not let the user decide, but I'm not sure if it's that easy, there would be the need to provide a configuration for many WM

@unrooted was complaining that KDE is too slow. We still wanted to use Wayland, without using some WM unfamiliar to a majority of users. So we chose GNOME, as it runs decently on relatively new hardware (last 10 years).
Anyone wanting to use something else can either edit these configs or install using Calamares.

Install using Calamares allows you to choose a specific WM ?

Yes.

@AkechiShiro that's a very good question why one would pick specifically Gnome as their DE over anything else
upon very lively discussions with a few current users, who use RednixOS on mainly VMs, as well as @fufexan, the good switch would be to utilize anything using Wayland in order to minimize, if not fully eliminate infamous X11 tearing effects
as of right now there are 2 properly working DEs for NixOS, which can run using Wayland, and those are either KDE or Gnome, and after a few checks on VMs it seems that Gnome is working a bit smoother
you may ask why not to just go with pure WM without DE, the reason is that it would require users to learn most likely totally new WM, at which point they could just go and do changes themselves, instead of leaving them in unfamiliar environment
that's also where Calamares comes into play, as it provides an option to pick your own DE/WM as well makes install process somewhat easier for less experienced users
what is more, approach presented by @fufexan also cleans up the repo significantally and handles configurations in way more elegant way
feel free to ask us any other questions in case those arise, good to see you still being interested in this project's development, it warms my heart

authors: AkechiShiro fufexan unrooted

repo: redcode-labs/RedNixOS

license: ISC


text:
Appstudio update test-component-pac-msql

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI/test-component-pac-msql-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
8 seconds
init

✅ Succeeded
13 seconds
clone-repository

✅ Succeeded
25 seconds
build-container

✅ Succeeded
8 seconds
deprecated-base-image-check

✅ Succeeded
10 seconds
clair-scan

✅ Succeeded
9 seconds
inspect-image

✅ Succeeded
46 seconds
clamav-scan

✅ Succeeded
10 seconds
sbom-json-check

✅ Succeeded
9 seconds
label-check

✅ Succeeded
8 seconds
show-sbom

✅ Succeeded
5 seconds
show-summary


text:
Appstudio update test-custom-default-branch-qrjn

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-uqzm-on-pull-request-
creating pipelinerun test-simple-build-uqzm-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-dtnt-on-pull-request-
creating pipelinerun test-annotations-dtnt-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-gcoj-on-pull-request-
creating pipelinerun test-annotations-gcoj-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-nyrh-on-pull-request-
creating pipelinerun test-simple-build-nyrh-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-gcoj-on-pull-request-
creating pipelinerun test-annotations-gcoj-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-mijr-on-pull-request-
creating pipelinerun test-annotations-mijr-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-yrqk-on-pull-request-
creating pipelinerun test-annotations-yrqk-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-wadk-on-pull-request-
creating pipelinerun test-simple-build-wadk-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-yrqk-on-pull-request-
creating pipelinerun test-annotations-yrqk-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-mijr-on-pull-request-
creating pipelinerun test-annotations-mijr-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-ntht-on-pull-request-
creating pipelinerun test-annotations-ntht-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-uqzm-on-pull-request-
creating pipelinerun test-simple-build-uqzm-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-ufgi-on-pull-request-
creating pipelinerun test-simple-build-ufgi-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-mcmm-on-pull-request-
creating pipelinerun test-simple-build-mcmm-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-ufgi-on-pull-request-
creating pipelinerun test-simple-build-ufgi-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-vchz-on-pull-request-
creating pipelinerun test-annotations-vchz-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-lqle-on-pull-request-
creating pipelinerun test-simple-build-lqle-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-nwtb-on-pull-request-
creating pipelinerun test-simple-build-nwtb-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-nyrh-on-pull-request-
creating pipelinerun test-simple-build-nyrh-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-ntht-on-pull-request-
creating pipelinerun test-annotations-ntht-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-dtnt-on-pull-request-
creating pipelinerun test-annotations-dtnt-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-vchz-on-pull-request-
creating pipelinerun test-annotations-vchz-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-imul-on-pull-request-
creating pipelinerun test-simple-build-imul-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-custom-default-branch-qrjn-on-pull-request-
creating pipelinerun test-custom-default-branch-qrjn-on-pull-request- in namespace build-e2e-irrl-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-mcmm-on-pull-request-
creating pipelinerun test-simple-build-mcmm-on-pull-request- in namespace build-e2e-vpzy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request


text:
[DEVHAS-266] Don't return context as part of local DockerfileURI

What does this PR do?:
When we were returning local Dockerfile URIs in the status of CDQs, we were appending the context folder to the URI. Since the context is already returned separately as part of the CDQ result, this would result in an invalid Dockerfile path (e.g. frontend/frontend/Dockerfile).
This PR removes that, so that the context path is not appended to the Dockerfile URI.
Since a test case didn't exist that covered this, I've added one
Which issue(s)/story(ies) does this PR fixes:
https://issues.redhat.com/browse/DEVHAS-266
PR acceptance criteria:

[x] Unit/Functional tests

[ ] Documentation

[ ] Client Impact

How to test changes / Special notes to the reviewer:

Builded and tested but got an error in the pipeline.
apiVersion: appstudio.redhat.com/v1alpha1
kind: Component
metadata:
  annotations:
    applicationFailCounter: '0'
    appstudio.openshift.io/component-initial-build: processed
    skip-initial-checks: 'true'
  resourceVersion: '33836'
  name: frontend-quality-dashboard-jern
  namespace: multi-comp-e2e-xvrn-tenant
  finalizers:
    - component.appstudio.redhat.com/finalizer
spec:
  application: multi-component-application
  componentName: frontend-quality-dashboard-jern
  containerImage: >-
    quay.io/redhat-appstudio-qe/test-images-protected:mvAp7-frontend-quality-dashboard-jern
  resources: {}
  secret: e2e-github-secret
  source:
    git:
      context: frontend
      dockerfileUrl: Dockerfile
      url: 'https://github.com/redhat-appstudio/quality-dashboard.git'

@flacatus are you testing manually? What are the paramerers of pipelinerun?

Build-service is using Component.spec.source.git.context + Component.status.devfile.components[x].image.dockerfile.buildContext to compose final context for pipelinerun. We are expecting that generated .status.devfile is related to Component.spec.source.git.context.
https://redhat-internal.slack.com/archives/C02HZRGKDEY/p1675242002586259

@Michkov I think we uncovered another bug in HAS.
Per https://redhat-internal.slack.com/archives/C02HZRGKDEY/p1675242002586259, the buildContext in the devfile is relative to the folder that contains the devfile. For Components that don’t have a devfile, this would be the component’s root folder (e.g. frontend/)
HAS is setting the devfile's buildContext for Dockerfile components to be the git context that gets passed (e.g. frontend/). But since the buildcontext is supposed to be relative to the Component, we shouldn’t be setting it to the Git context in this case.

authors: Michkov flacatus johnmcollier

repo: redhat-appstudio/application-service


text:
Remove label-check task

The checks performed by the label-check Task are now performed by the Enterprise Contract. This is done by querying the OCI registry.
https://issues.redhat.com/browse/HACBS-2401

The updated template produces a few different Tekton Pipelines. Use the following to compare those:
diff -u \
  <(kustomize build https://github.com/redhat-appstudio/build-definitions/pipelines) \
  <(kustomize build https://github.com/lcarva/build-definitions/pipelines?ref=HACBS-2401)

Which produces the following:
--- /dev/fd/63	2023-07-31 14:04:40.506859191 -0400
+++ /dev/fd/62	2023-07-31 14:04:40.507859209 -0400
@@ -190,37 +190,6 @@
     workspaces:
     - name: source
       workspace: workspace
-  - name: label-check
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-checks)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
-  - name: optional-label-check
-    params:
-    - name: POLICY_NAMESPACE
-      value: optional_checks
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-optional)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
   - name: deprecated-base-image-check
     params:
     - name: BASE_IMAGES_DIGESTS
@@ -781,37 +750,6 @@
     workspaces:
     - name: source
       workspace: workspace
-  - name: label-check
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-checks)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
-  - name: fbc-label-check
-    params:
-    - name: POLICY_NAMESPACE
-      value: fbc_checks
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-optional)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
   - name: deprecated-base-image-check
     params:
     - name: BASE_IMAGES_DIGESTS
@@ -897,8 +835,6 @@
       value: $(tasks.build-container.results.IMAGE_DIGEST)
     - name: BASE_IMAGE
       value: $(tasks.inspect-image.results.BASE_IMAGE)
-    runAfter:
-    - fbc-label-check
     taskRef:
       name: fbc-validation
       version: "0.1"
@@ -1115,37 +1051,6 @@
     workspaces:
     - name: source
       workspace: workspace
-  - name: label-check
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-checks)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
-  - name: optional-label-check
-    params:
-    - name: POLICY_NAMESPACE
-      value: optional_checks
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-optional)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
   - name: deprecated-base-image-check
     params:
     - name: BASE_IMAGES_DIGESTS
@@ -1412,37 +1317,6 @@
     workspaces:
     - name: source
       workspace: workspace
-  - name: label-check
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-checks)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
-  - name: optional-label-check
-    params:
-    - name: POLICY_NAMESPACE
-      value: optional_checks
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-optional)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
   - name: deprecated-base-image-check
     params:
     - name: BASE_IMAGES_DIGESTS
@@ -1698,37 +1572,6 @@
     workspaces:
     - name: source
       workspace: workspace
-  - name: label-check
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-checks)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
-  - name: optional-label-check
-    params:
-    - name: POLICY_NAMESPACE
-      value: optional_checks
-    runAfter:
-    - inspect-image
-    taskRef:
-      name: label-check
-      version: "0.1"
-    when:
-    - input: $(params.skip-optional)
-      operator: in
-      values:
-      - "false"
-    workspaces:
-    - name: workspace
-      workspace: workspace
   - name: clair-scan
     params:
     - name: image-digest

@dirgim, @MartinBasti ptal

Looks like a change to the e2e tests is required. On it.

/retest

Just wanted to make sure the places after removing those label checks are correct. After checking it with kustomize, everything seems to be in the right place.

authors: jsztuka lcarva

repo: redhat-appstudio/build-definitions


text:
chore: remove checking container image id results

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Issue ticket number and link
Type of change

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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/retest

/retest

authors: kasemAlem theflockers


text:
chore: change new tests to push type tests

Stoneintg-468
Type of change

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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[x] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)
[x ] e2e test suite

/retest

/retest

/retest


text:
update ci to go 1.17

Signed-off-by: Stephanie yangcao@redhat.com
this PR updates ci to use go 1.17 image

/lgtm

repo: redhat-appstudio/infra-deployments


text:
Configuring Service Providers without OAuth

What does this PR do?
Makes oauth configuration of service provider optional. When oauth configuration is missing, oauthURL is not created at all.
There is lot of refactorings how we load configuration for service providers. User configs has always priority over global configs.
Even when there is no explicit configuration for service provider, we should still be able to do manual token upload and detect correct service provider type in case it uses default url value (SAAS host).
TODO:

tests!!
documentation (how to create user configuration without oauth)

NOTE:

quay currently does not work https://issues.redhat.com/browse/SVPI-298

Screenshot/screencast of this PR

What issues does this PR fix or reference?

https://issues.redhat.com/browse/SVPI-270
How to test this PR?

images:

quay.io/mvala/service-provider-integration-operator:svpi270-spWoOauth2
quay.io/mvala/service-provider-integration-oauth:svpi270-spWoOauth2

case 1

configure service providers in config.yaml so they have oauth
oauthurl must be generated

case 2

configure sp in config.yaml without oauth
oauthurl must not be generated

case 3

configure sp in user's secret with oauth
oauth url must be always generated, completely independent from what is in config.yaml

case 4

configure sp in user's secret without oauth:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  labels:
    spi.appstudio.redhat.com/service-provider-type: GitLab
  name: sp-config-gitlab
data:

oauth url must never be generated, completely independent from what is in config.yaml

case 5

in binding, use public saas repository that has no configuration in either config.yaml or user's SP
it must be possible to upload the token and sp type must be detected properly

usecases 1-3, 5 tested on github - it works. case 4. How to configure sp in user's secret without oauth? Do we need to document that?

@skabashnyuk I've updated 4 with example secret. I'll add it to docs as well


text:
Avoid jspm 0.16.32 which causes build failures

Jspm 0.16.32 causes build and run errors right now - workaround to revert to 0.16.31 until a proper solution is found.

Merged manually.


text:
docs: JR-572: Updates Service Registry 'Using Quarkus' with PM+QE fee…

…dback

@smccarthy-ie Made the changes in the RHOSAK+Quarkus doc now, while the changes are still fresh in my mind! Please review again to make sure I caught everything.
@AedinC Will you please review the changes in the RHOSAK+Quarkus doc too, to make sure you're happy with them?

repo: redhat-developer/app-services-guides


text:
fix: add duration dynamically

What this PR does / why we need it:
https://issues.redhat.com/browse/MGDSTRM-7914
Which issue(s) this PR fixes

Replace this comment with references to related issues.
e.g. fixes #<issue number>

Verification steps

Attach a screenshot of the output.
guidance on how to go the particular story.
e.g. point to the story with a text breadcrumb, something like "components > <component name> > <story name>”

Is there any work left / what's next :

Replace this comment with pending items that need to be covered in this PR or some pending items you are planning to do in the future PR.

Special notes for your reviewer:

@riccardo-forina pointed out how to access the preview. I was able to look at the UI examples and didn't see any issues.

@ajaypratap003 could you please fill out the template with the info we ask to provide? Leaving the defaults isn't that nice.

The storybook build appears to be not working lately. Without being able to see a preview, I think this PR updates the create modal to display the duration based on what information is provided by the API. If so, that all seems good.
As for the original jira, there should also be updates to the table view. But these are probably needed in the kas-ui repo. Just wanted to confirm that those updates were also in progress.

@jgiardino yes, this change for alert and table duration change will be in kas-ui

:tada: This PR is included in version 1.38.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: ajaypratap003 app-services-ci jgiardino riccardo-forina


text:
Update Kuttl tests for v1.9

What type of PR is this?
/kind enhancement
What does this PR do / why we need it:
We usually update all the testing related changes in operator-e2e repository. Now that we have started storing tests in gitops-operator repository, we need to make sure both of them are up to date.
Make a note of all the changes that went into release-1.9 branch in operator-e2e repository and update the same in gitops-operator repository's v1.9 branch.
Have you updated the necessary documentation?

[ ] Documentation update is required by this PR.
[ ] Documentation has been updated.

Which issue(s) this PR fixes:
Fixes https://issues.redhat.com/browse/GITOPS-2988
Test acceptance criteria:

[ ] Unit Test
[ ] E2E Test

How to test changes / Special notes to the reviewer:

/test v4.12-kuttl-sequential
/test v4.13-kuttl-parallel
/test v4.13-kuttl-sequential

/retest

/retest

/retest

/lgtm
Thanks!

/approve

/lgtm

repo: redhat-developer/gitops-operator


text:
update 1-031 to check for parallel component version fixes:2641

What type of PR is this?
/kind failing-test
What does this PR do / why we need it:
This PR updates and fixes ignored test 1-031 with updated version of argocd, helm and dex.
Have you updated the necessary documentation?

[ ] Documentation update is required by this PR.
[ ] Documentation has been updated.

Which issue(s) this PR fixes:
Fixes # GITOPS-2641
Test acceptance criteria:

[ ] Unit Test
[ ] E2E Test

How to test changes / Special notes to the reviewer:

~any cluster with  openshfit-gitops version installed~
run

kubectl kuttl test ./test/openshift/e2e/parallel   --config ./test/openshift/e2e/parallel/kuttl-test.yaml --test  1-031_validate_toolchain

As per discussion with Siddhesh, while building gitops-operator container for tests we are fetching dex Version and Redis version from argocd here, To make it close to release build we need to update component versions to the one we are using from midstream repos.
This also posses a problem for future, i.e. it will get out of sync and fail, once we update the version used in midstream.
WDYT? @iam-veeramalla, @varshab1210

IMO enabling this test is a good way to ensure that upstream and downstream versions are in sync. Whenever this test fails we know there is a mis-match somewhere in versions and we can update accordingly and won't go un-noticed.

IMO enabling this test is a good way to ensure that upstream and downstream versions are in sync. Whenever this test fails we know there is a mis-match somewhere in versions and we can update accordingly and won't go un-noticed.

But, shouldn't we start from making changes from argocd-operator repo instead of mid-strem repo? or do we have some reason due to which this is not possible?

For any versions related changes, usually it is upstream first so argocd->argocd-operator->gitops-operator. However I am not sure in this case, why downstream has different dex version. Maybe @varshab1210 or @iam-veeramalla knows the reason.
That being said version difference makes sense if we rely on base image in downstream for the package. For example, we install git via base image repos so most of the times it will differ from upstream as the base image is different. However in case of dex, we build the container so we are in full control of the version.

/test all

/retest

/retest

LGTM

/retest

/retest

/retest

/retest

/approve

authors: anandrkskd svghadi varshab1210


text:
Initial contribution

Initial contribution for vscode-microprofile. Starts up lsp4mp and supports contribution from external JARs. Also includes yaml support.
Not sure what I should do with version in package.json and the changelog.md file. Also did not touch the contributing.md so that will need to be updated.
Also wondering if we can remove the extension dependency on vscjava.vscode-java-debug

Initial contribution for vscode-microprofile. Starts up lsp4mp and supports contribution from external JARs. Also includes yaml support.

I tested (without quarkus stuff and yaml stuff) and it works well.

Not sure what I should do with version in package.json

0.1.0 must be used (preview version)

and the changelog.md file.

See my comments

Also did not touch the contributing.md so that will need to be updated.

Keep like this for the moment, I create an issue for that https://github.com/redhat-developer/vscode-microprofile/issues/2

Also wondering if we can remove the extension dependency on vscjava.vscode-java-debug

I think we need to keep those dependencies to debug Quarkus application. @xorye please correct me. Perhaps we can remove it for MicroProfile?
@rzgry please fix my comments and squash your commits in one commit, after that I'm good to merge it. The other update could be done in another PRs.

Removed dependency on vscode-java-debug and squashed my commits.

Thanks @rzgry !

authors: angelozerr rzgry

repo: redhat-developer/vscode-microprofile


text:
operator cert-utils-operator (1.3.11)

New Submissions

[ ] Has you operator nested directory structure?
[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Is your submission signed?

Updates to existing Operators

[x] Is your new CSV pointing to the previous version with the replaces property?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Submit operators to both upstream-community-operators and community-operators at once
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo
Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need
2 For more information see here

/merge possible

/merge possible

/merge possible

authors: framework-automation raffaelespazzoli


text:
operators flux (0.27.0)

Signed-off-by: Chanwit Kaewkasi chanwit@gmail.com
Thanks submitting your Operator. Please check below list before you create your Pull Request.
Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/merge possible

/test 4.6-deploy-operator-on-openshift

authors: chanwit framework-automation


text:
patches_ignore keyword not used by the new-version command

patches_ignore keyword not used by the new-version command, causing unwanted patches to be applied (or at least an attempt made to apply them) after a rebase.

Hmm, not sure why is that, new-version is using update-patches as a last step:
https://github.com/redhat-openstack/rdopkg/blob/master/rdopkg/actions.py#L89
@lyarwood can you show an example spec and repo where this was observed? Does rdopkg update-patches work?

@apevec Apologies, I was somehow using the 0.32.1 version of rdopkg so this isn't a bug at all, closing.

authors: apevec lyarwood

repo: redhat-openstack/rdopkg


text:
[CVP-1752] Support operator bundles in CPaaS Midstream

Changes by @samvarankashyap updating midstream image CI and tests:

Update the image to include dependencies like umoci , skopeo
Update the input for the CVP image for midstream to accept and process the IMAGE_TO_TEST env variable.
Run playbooks extract-operator-bundle.yml, validate-operator-bundle.yml as part of the midstream test
Adding tests in ci using bundles from public container image registry (one positive testcase and 2+ negative testcase)
Added output of the bundle validation to the validate_operator_bundle role

Fixed yamllint warnings

We should also ask midstream people to review changes.
They might prefer different reporting.
And it would be better to change it know rather than try to be backward compatible later.

@lslebodn please re-review

authors: dirgim lslebodn


text:
Fix issue in identifying day 2 nodes when not using dhcp

fixes: #20

@nocturnalastro This has been approved. Do you want to rebase and merge.

authors: arjuhe nocturnalastro

repo: redhat-partner-solutions/crucible


text:
Invalid OOM handling in async.c

Already fixed this and added features at https://github.com/redis/hiredis/pull/638
Opening a ticket to enable proper conversation about whether it is actually needed.

I don't know if the handling is invalid

Closing this issue since we fixed the UB via #754

@michael-grunder that didn't fix the issue since some functions like callbackValDup still use the value allocated without checking for NULL

hi_malloc and other variants call an OOM handler on failure (defaults to abort())

@michael-grunder ok then, seems legit enough.
Also, any idea if you want #638 in the code anytime soon (should I invest some time rebasing properly ?)

I'll take another look at the PR in the morning.
We may need to wait until after 1.0.0 though because we plan on releasing that soon.

authors: michael-grunder mnunberg oshamash

repo: redis/hiredis


text:
[Feature Request]: High integrity mode (already implemented in another client/s)

This is a client-library alternative suggestion to https://github.com/redis/redis/issues/13240, to address the issue of protocol desync going undetected for at least "some" commands and causing mayhem.
Full details of suggested resolution and implementation are here:
https://github.com/StackExchange/StackExchange.Redis/issues/2706

@avislavkin Could you share more details about the use-case and environment where you experienced RESP "desync" issues?

@uglide, I haven't come across those issues. You can find all the details I have here. The  might be able to share some use cases they've encountered.

The short version here would be "heck knows". This has been reported stupendously rarely; cause could be anything from a rare edge-case bug at any layer, including things like the client, the framework, TLS, the CPU/RAM, the NIC/FPGA, any intermediary gateway/proxy, or the server. I do know that on at least one occasion VeryBadThingsTM have been observed, and there is no intended finger-pointing at any layer, least of all Redis itself. The point of the feature in SE.Redis is as a defence-in-depth safeguard: "Impossible things happened? We should at least detect that there was a problem,and not propagate incorrect results". SE.Redis is arguably a lot more vulnerable to this problem because it makes much higher use of multiplexing than most other clients as the default and primary mechanism. If that isn't true for ioredis (you can't really desync on lease/request/response/return cycle): you might not need this.

@uglide, considering the problem statement that @mgravell mentioned earlier, could ioredis encounter the same issue? Does ioredis require this feature as well?

authors: avislavkin mgravell uglide

repo: redis/ioredis


text:
warnings coming from dependent library fst

Expected behavior
This is observed in JDK11 JVM. There should be no warnings, especially those that indicate that code may stop working in a future release.
Actual behavior
Warnings issued. See also (fst 295) Reporting here to make redisson committers aware.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.nustaq.serialization.FSTClazzInfo (file:/.../fst-2.57.jar) to field java.lang.String.value
WARNING: Please consider reporting this to the maintainers of org.nustaq.serialization.FSTClazzInfo
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Steps to reproduce or test case
Running the app that uses redisson
Redis version
N/A
Redisson version
3.12.2
Redisson configuration
N/A

As workaround use Kryo5Codec, JsonJacksonCodec or SerializationCodec

authors: mrniko xbranko

repo: redisson/redisson


text:
when use JDK 1.8.0_202 , commandExecutor cause CPU load high

cause:
commandExecutor.get(future)
return future.toCompletableFuture().get();
java.util.concurrent.CompletableFuture#get()
private Object waitingGet(boolean interruptible) {
spins = (Runtime.getRuntime().availableProcessors() > 1) ?
bug:
https://bugs.openjdk.org/browse/JDK-8227019
suggestion:
get(long timeout, TimeUnit unit)

get(long timeout, TimeUnit unit)

谢谢你的建议。不幸的是，它没有考虑阻止呼叫。它需要更多的努力来实现，而不是升级 JDK8 构建。

how about    get(Integer.MAX_VALUE, TimeUnit.MILLISECONDS)

Thank for suggestion. Unfortunately, it doesn't take in account blocking calls. It requires much more effort for implementation rather than upgrading JDK8 build.

how about get(Integer.MAX_VALUE, TimeUnit.MILLISECONDS)

Why do we need to adopt the project to this old JDK8 build?

authors: crossdawn mrniko


text:
Add RedisBusyException. In case of the watchdog logic exit during red…

Add RedisBusyException. In case of the watchdog logic exit during redis server busy.
Signed-off-by: wuqian30624 wuqian0808@me.com

One more question. I just tested out the redis server busy exception. But how to deal with other exceptions properly? Especially those unkown exceptions for which we should retry in watchdog logic ...

One more question. I just tested out the redis server busy exception. But how to deal with other exceptions properly? Especially those unkown exceptions for which we should retry in watchdog logic ...

Thanks for contribution!
I think not all unknown exceptions should cause another command execution attempt.

Thanks for contribution!
I think not all unknown exceptions should cause another command execution attempt.


text:
[Feature request] Flag to disable nop insertion after stop

This is virtually identical to rgbasm's -h for halt, and for the same reasons. With the flag enabled, stop would emit just a $10 byte.

Isn't the byte after STOP always ignored? What would be the point of removing that extra byte?

If it is always ignored, it can be used for data. I'm not sure if it is.
That being said, writing a test ROM to check that is yet another case where you wouldn't want automatic NOP insertion.

Are you sure that it is safe to do? I'd be worried to do that if the documentation explicitly says you need to add a $00.

The documentation may actually be wrong about that, it seems like the byte is skipped entirely. But documentation about it is fairly unclear...

Another option: stop $00 through stop $FF to specify the value of the skipped byte.

That seems like artificially inflating the opcode, since the $10 is all that gets executed.

I see it as paralleling brk on 6502: the CPU executes the brk but then skips the next byte.

authors: AntonioND ISSOtm aaaaaa123456789 pinobatch

repo: rednex/rgbds


text:
Add info about string expansions in error reports

This is especially useful when an EQUS expands to another one, to help track them.
This is done separately from the file stack as the EQUS stack is separate (which is itself because EQUS are managed way differently).

LGTM


text:
Documentation about headers is wrong

In the documentation, we can see an example of header set for all queries:
api.headers.token = 'secret authentication token'
Actually, it looks like it should be:
api.config.headers.token = 'secret authentication token'

This is correct. The docs are terribly outdated.
Will work on this.

I've created a new issue for this: #27

authors: redodo tracim

repo: redodo/tortilla


text:
fix Content-Type header and data composition

only when

content is actually sent (whatever the HTTP verb is used)
format is provided ('json' by default)

Coverage decreased (-0.84%) to 84.39% when pulling b25024e688a4368a3811cf4e921ab74f5842c4c5 on camomile-project:feature/fix_headers into 9ee3ee59ba491163ddf7b145e352917bbbc2ea83 on redodo:develop.

Much better!

authors: coveralls hbredin redodo


text:
Changes to move the offset commit behaviour

Changes to move the offset commit behaviour back closer to the default behaviour, but also to avoid flooding the Kafka client with async commits. At the very least this will only submit async requests once the previous async request has come back.
New behaviour:
We're only going to submit an async commit request if:

autoCommit is disabled AND
there are offsets to commit AND

offsetCommitLingerMs is zero (the default, so no waiting for async callbacks at all) OR
we've waited lingerMs milliseconds since the last callback completed (+ve or -ve)

Hi @travisdowns , I've updated per your comments.

repo: redpanda-data/openmessaging-benchmark


text:
Porting of useful JavaScript-based validators

Hello,
(This is mainly Japanese topic.)
Honestly I think it's good idea to have some common JavaScript-based validators ported and built-in.
Currently I'd like to have ones in "redpen-doc-ja" (the Japanese RedPen documentation,) for example:

doubled_no.js
japanese_anchor_expression.js
japanese_number_expression.js
japanese_spoken_expression.js
long_kanji_chain.js
redundant-ja-expression.js

If it's clear to take care of it, I will.
Thanks.
-t

Closing: split by topics.

repo: redpen-cc/redpen


text:
Yielding put effects in an external saga

Hi everyone,
I'm running a standalone saga inside a redux-connect decorator before rendering a page (server-side):
import { runSaga } from 'redux-saga';

@connectData(({ store }) => {
  return runSaga(store, loadPage).done;
})
class Page extends Component { ... }

and I'd like to yield some put effects inside it, but I get the following exception:
[server] stdout: redux-saga error: uncaught at loadPage
TypeError: Cannot read property '@@redux-saga/SAGA_ACTION' of undefined
    at Array.<anonymous> (/mypath/node_modules/redux-saga/lib/internal/channel.js:189:16)
    at dispatch (/mypath/node_modules/redux/lib/createStore.js:186:19)
    at /mypath/node_modules/react-router-redux/lib/middleware.js:22:18
    at /mypath/node_modules/redux-saga/lib/internal/middleware.js:72:22
    at /mypath/build/bm/server.js:64744:18
    at /mypath/node_modules/redux-saga/lib/internal/utils.js:265:12
    at /mypath/node_modules/redux-saga/lib/internal/proc.js:480:52
    at exec (/mypath/node_modules/redux-saga/lib/internal/scheduler.js:26:5)
    at flush (/mypath/node_modules/redux-saga/lib/internal/scheduler.js:67:5)
    at asap (/mypath/node_modules/redux-saga/lib/internal/scheduler.js:40:5)
    at runPutEffect (/mypath/node_modules/redux-saga/lib/internal/proc.js:477:25)
    at runEffect (/mypath/node_modules/redux-saga/lib/internal/proc.js:432:220)
    at next (/mypath/node_modules/redux-saga/lib/internal/proc.js:314:9)
    at currCb (/mypath/node_modules/redux-saga/lib/internal/proc.js:386:7)
    at runSelectEffect (/mypath/node_modules/redux-saga/lib/internal/proc.js:689:7)
    at runEffect (/mypath/node_modules/redux-saga/lib/internal/proc.js:432:941)
    at next (/mypath/node_modules/redux-saga/lib/internal/proc.js:314:9)
    at proc (/mypath/node_modules/redux-saga/lib/internal/proc.js:269:3)
    at runSaga (/mypath/node_modules/redux-saga/lib/internal/runSaga.js:59:33)

Again: this only happens when I yield put effects. Any idea of what's going on? Is it an expected behaviour?

Hm, according to this
    at /mypath/node_modules/redux-saga/lib/internal/middleware.js:72:22
the code is going through the middleware  somehow and reaching this with no input (action).
Aint sure how is it happening, would have to see more code - reproduced issue on something like  webpackbin would be very helpful

@Andarist my apologies. I had tried without middlewares before, and the error persisted. Here goes a demo: https://codesandbox.io/s/lYgzmnkNj

Ok, so I've looked into ur issue. Saga's subscribe option is not equivalent to the redux one. It was a surprise for me when I once have learnt about it too ;)
You can see what is passed as it in sagaMiddleware.run API here. And read more about its signature here
When you subscribe to the redux store its callback wont provide any arguments to you, it only notifies you that 'something happened'.
On the other hand redux-saga needs dispatched actions as input to its subscribe to resolve take effects. Therefore its signature is slightly different from redux one.
I hope this explanation shows what the problem is, if not - dont hesitate, ask more questions :)

Thanks for the investigation. If I understood it correctly, it means that I have these two alternatives:

Access the sagaMiddleware in my @connectData, then run it sagaMiddleware.run(mySaga)
Store the latest action in the Redux state and pass a modified subscribe function to runSaga:

runSaga({
  subscribe: cb => {
    return store.subscribe(() => {
      cb(store.getState().latestAction);
    });
  },
  dispatch: store.dispatch,
  getState: store.getState
}, mySaga)

Does that make sense?

Yeah, pretty much. I would advise ubti to for the first one. Its more reasonable to use sagaMiddleware.run anyway if you connect it to the actual store.
You can enhance ur store so its easier to access it. Somehow like:
const store = {
...createStore(...),
runSaga: sagaMiddleware.run,
}

Sweet! I appreciate the hep, @Andarist.

authors: Andarist eliseumds

repo: redux-saga/redux-saga


text:
[Tutorial Docs] Updating Initial state to account for expected changes in UI

name: :memo: Documentation Fix
about: Fixing a problem in an existing docs page
Checklist

[X] Is there an existing issue for this PR?

https://github.com/reduxjs/redux/issues/3967

[X] Have the files been linted and formatted?

What docs page needs to be fixed?

Section:
redux/docs/tutorials/essentials

Page:
part-4-using-data.md

What is the problem?
We change the UI to state that we will expect posts to have a reactions property in the ReactionButtons component, but we both don't check for null or update the initial state.
What changes does this PR make to fix the problem?
In my PR i follow the same process used earlier in the tutorial with both the user and the date property on posts, by making sure to update the initial state objects of posts to have a reactions object property.

Added issue - https://github.com/reduxjs/redux/issues/3967

Should be resolved by #4153 .

authors: markerikson tylerthedeveloper

repo: reduxjs/redux