Test CI for PR #393

Following similar approach to #407, create a matching ci branch for the required gz-cmake branch

Upstream merged: https://github.com/gazebosim/gz-cmake/pull/291
Nightlies running
Focal
Jammy

I believe this PR can be folded into #393

Yap, thanks! Closing


Does the images in the folder “data” need to be pre-processed?

Does the images in the folder data need to be preprocessed?
Why is it not good to process images downloaded internet?
the image from internet

_in.png

_out.png

Hi. No pre-processing required. I would guess that the problem is that you used the weights trained without compression included, is that the case? The image probably experiences compression artifacts, which requires the weights trained with such artifacts included (the correct weights can be downloaded here).

Thank you for your reply, but the problem has not been resolved. Processing my own image, the effect is not very good (the use of weights is correct)

Are you sure about the weights? I tried using your image above, and get the exact same result when using the weights that do not include compression (hdrcnn_params.npz). Using the weights that are trained with compression (hdrcnn_params_compr.npz), the result looks like this:

The command for running the reconstruction:
$ python3 hdrcnn_predict.py --params hdrcnn_params_compr.npz --im_dir input.jpg --width 1280 --height 852

The input image is your input low dynamic range image for which you want to reconstruct HDR information. For the output images, please see the explanation in a previous issue comment.


Ρεκόρ meaning.

Fist of all can I just say that the project looks really interesting and I'm looking forward to playing around with it.

Mostly just FYI: The word Ρεκόρ in Greek translates to something like "previous conduct/performance/high value" or "track record", rather than what I assume you were going for in naming the project. And it would be used in terms such as "world record", "in record time", "set a new record". (https://www.wordreference.com/gren/ρεκόρ)
Still a cool name though :)

@geoah , we actually need to pivot to a new name, do you have any ideas on some other funky greek names that sound good / look good when spelled out in English?


Cryptic error message

I got the following error message which didn't say what the actual error was
Pipeline aborted due to error {:exception=>"RuntimeError", :backtrace=>["/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-output-redis-2.0.5/lib/logstash/outputs/redis.rb:115:in register'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/output_delegator.rb:75:in register'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:181:in start_workers'", "org/jruby/RubyArray.java:1613:in each'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:181:in start_workers'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/pipeline.rb:136:in run'", "/opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-core-2.4.0-java/lib/logstash/agent.rb:491:in start_pipeline'"], :level=>:error}
`
Looking at the line of code the actual error is: "Must define queue, or key and data_type parameters"

this is fixed in https://github.com/elastic/logstash/commit/b5643820172d53fbaef822740a8b3ae6590066b3, which will be included in logstash 2.4.1


PEFILE out of sync with current plaso version 1.4

sansforensics@siftworkstation:/cases/win7-32-nromanoff-c-drive$ log2timeline.py plaso.dump c-drive.E01
Checking availability and versions of plaso dependencies.
[FAILURE]	pefile version: 1.2.10-114 is too old, 1.2.10-139 or later required.

I'll have to grab the c-drive.E01 to test, but look at the latest packages available if you do a update-sift or sudo apt-get install python-pefile should resolve it.

I've run into this issue as well. I think that it's because pefile is installed in both /usr/local/lib/python2.7/dist-packages and /usr/lib/python2.7/dist-packages. The first directory is earlier on the path and has the older version installed.
sansforensics@siftworkstation:~$ dpkg -l | grep python-pefile
ii  python-pefile 1.2.10-139-1ppa1~trusty all          Python module to read  with PE (Portable Executable) files.

Removing pefile from /usr/local/lib/python2.7/dist-packages/ resolved the issue for me.

That dpkg version is 1.2.10-139, so that doesn't make much sense.

1.2.10-139 was installed by apt-get in /usr/lib/python2.7/dist-packages. However, 1.2.10-114 was present in /usr/local/lib/python2.7/dist-packages. I included the output from dpkg to illustrate that I had the latest version available.
Just FYI I was running this from a VM provided in a FOR508 class, so it might not be an issue if the bootstrap doesn't install modules into /usr/local/lib/python2.7

ah, probably just need to pip remove then maybe ... let me see if I have both on my system.

I ran into this same issue after upgrading my SIFT workstation today. As @lautriv mentioned, removing pefile from  /usr/local/lib/python2.7/dist-packages/ resolved the issue.

@NoahJaehnert thanks for the information

Out of date and stale, closing.


docs: update arguments for useSignal/useStore

What is it?

[ ] Feature / enhancement
[ ] Bug
[x] Docs / tests

Description
useSignal should have a value argument whereas useStore should be an object argument.
Use cases and why

Checklist:

[ ] My code follows the developer guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] Added new tests to cover the fix / functionality

Hi @mforncro 👋
Thanks a lot for creating this PR 🎉  IMO the changes on the useSignal is accurate. For useStore there is a mismatch with the referenced page where the param is also named initialState. Guess we should also update the referenced docs to initialStateObject.
Would you mind to add them as well?
Thanks a lot in advance 🙏

I've adjusted the naming on https://github.com/BuilderIO/qwik/pull/3261. So this can be merged. Thanks again for your time to create this PR 🙏


Support for Equijoins

Hello, thank you for the great project :)
In how far are equijoins exactly supported?
Given that I have the following NetworkX graph:
G = nx.DiGraph()
G.add_node("x")
G.add_node("y")
G.add_node("z")
G.add_edge("x", "y")
G.add_edge("y", "x")
G.add_edge("x", "x")
G.add_edge("z", "x")

When I execute the following query:
MATCH (n)-->(n)
RETURN n

I get the result:
{Token('CNAME', 'n'): ['x', 'y']}

However, if I execute the same query on the equivalent graph in neo4j, I only get the node x as result - which to my understanding of Cypher would be the correct result.
Therefore, to my understanding, equijoins are currently only supported in the project when they are distributed over multiple match clauses and do not recognizes self cycles on nodes. Is that correct?
For instances, the following query correctly recognizes two loops in the graph:
MATCH (n)-->(m)
MATCH (m)-->(n)
RETURN n, m

While neo4j additionally returns n=x and m=x as a result.
Many regards,
Felix

Uh oh! Looks like a bug to me. Your intuition is totally right, we should only be returning x in your first example. Thank you for reporting!!

@khoale88 sorry to bug you, wondering if you have thoughts on this one — I think the issue is here:
https://github.com/aplbrain/grand-cypher/blob/31001b7c54d9ac35325042fc59673d2a99271acf/grandcypher/__init__.py#L434-L463
On line 470, self._matches is [{'n': 'x'}, {'n': 'y'}] — so the issue is happening I guess at the pathwise where filtering... wondering if you encountered anything like this while testing. I'm still poking at it and I'll report back here as I learn more!

Right, let me spend some time on this!

No pressure, but it would be super appreciated if you have time!! :)

I think there is an unexpected behavior in grandiso. After debugging, it drills down to grandiso.find_motif_iter  yielding both x and y, Here is the test snippet.
def test_equijoins(self):
    host = nx.DiGraph()
    host.add_node("x")
    host.add_node("y")
    host.add_node("z")
    host.add_edge("x", "y")
    host.add_edge("y", "x")
    host.add_edge("x", "x")
    host.add_edge("z", "x")

    motif = nx.DiGraph()
    motif.add_edge("n", "n")

    res = find_motifs(motif, host)
    assert res == [{"n": "x"}]

The test fails with result
>       assert res == [{"n": "x"}]
E       AssertionError: assert [{'n': 'x'}, {'n': 'y'}] == [{'n': 'x'}]
E         Left contains one more item: {'n': 'y'}
E         Full diff:
E         - [{'n': 'x'}]
E         + [{'n': 'x'}, {'n': 'y'}]

What do you think?


🐛 [firebase_auth] Email identifier of User overwritten when linking with Email-link

Bug report
Describe the bug
When I try to link accounts in Firebase I have noticed something weird. I'm not sure if it's specific to firebase_auth plugin and Flutter or is a general Firebase problem, but anyways.
When I'm signed in with Google as provider with email<EMAIL_ADDRESS>and try to link the EmailAuthProvider or as it's id called "password" (I don't why it's called like that), like this:
final authCredential = EmailAuthProvider.credentialWithLink(email: email, emailLink: emailLink);
await FirebaseAuth.instance.currentUser?.linkWithCredential(authCredential);

I get a weird outcome. The linking has been completed successfully but the email identifier in Firebase console has been replaced from<EMAIL_ADDRESS>to the email that I provider in  credentialWithLink(email: email, emailLink: emailLink) method.
It's kind of weird because no other provider Linking does that. Also the opposite won't have the same weird outcome. So for example if I'm already signed in with Email-link sign in or Email/password and then try to link a google account, the identifier email in Firebase console will still be the old one. The one that was used from the first provider! Which is the expected.
Steps to reproduce
Steps to reproduce the behavior:

Sign in with Google account
Go to console.firebase.google.com in your project and see the Identifier email that is tied to that account
Link Email provider with

await FirebaseAuth.instance.currentUser?.linkWithCredential( EmailAuthProvider.credentialWithLink(email: email, emailLink: emailLink) )

Go to console.firebase.google.com again and check the Identifier email that has been changed with the new one.The one of the Email Auth provider

Expected behavior
The Identifier email should have not been changed in Firebase console (and in User object of course).  It should have been stayed the same. It should have been stayed the one of the first provider used to create the account ! As it is when Linking other providers!
Sample project
Sample code provided above.
Additional context
I used the official docs from google here but I think there are false written on that page specifically. Where as another page describes the Account-Linking better here

Flutter doctor
Run flutter doctor and paste the output below:
Click To Expand
[✓] Flutter (Channel stable, 2.10.4, on Garuda Linux 5.18.1-zen1-1-zen, locale en_US.UTF-8)
[!] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/linux#android-setup for more details.
[✗] Chrome - develop for the web (Cannot find Chrome executable at google-chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.
[!] Android Studio (not installed)
[✓] IntelliJ IDEA Ultimate Edition (version 2022.1)
[✓] Connected device (1 available)
[✓] HTTP Host Availability

Flutter dependencies
Run flutter pub deps -- --style=compact and paste the output below:
Click To Expand
Dart SDK 2.16.2
Flutter SDK 2.10.4
govhack_p 1.0.0+1

dependencies:
- animated_splash_screen 1.2.0 [flutter page_transition]
- convert 3.0.1 [typed_data]
- crypto 3.0.2 [typed_data]
- cupertino_icons 1.0.4
- firebase_auth 3.3.15 [firebase_auth_platform_interface firebase_auth_web firebase_core firebase_core_platform_interface flutter meta]
- firebase_core 1.15.0 [firebase_core_platform_interface firebase_core_web flutter meta]
- firebase_dynamic_links 4.2.0 [firebase_core firebase_core_platform_interface firebase_dynamic_links_platform_interface flutter meta plugin_platform_interface]
- firebase_messaging 11.2.14 [firebase_core firebase_core_platform_interface firebase_messaging_platform_interface firebase_messaging_web flutter meta]
- flutter 0.0.0 [characters collection material_color_utilities meta typed_data vector_math sky_engine]
- flutter_datetime_picker 1.5.1 [flutter]
- flutter_facebook_auth 4.3.0 [flutter flutter_facebook_auth_platform_interface flutter_facebook_auth_web]
- flutter_launcher_icons 0.9.2 [args image path yaml]
- flutter_local_notifications 9.4.1 [clock flutter flutter_local_notifications_linux flutter_local_notifications_platform_interface timezone]
- flutter_native_splash 2.1.6 [args flutter flutter_web_plugins image js lint meta path universal_io xml yaml]
- flutter_snake_navigationbar 0.6.1 [flutter]
- fluttertoast 8.0.9 [flutter flutter_web_plugins]
- google_sign_in 5.3.0 [flutter google_sign_in_android google_sign_in_ios google_sign_in_platform_interface google_sign_in_web]
- hex 0.2.0
- http 0.13.4 [async http_parser meta path]
- image_picker 0.8.5+3 [flutter image_picker_android image_picker_for_web image_picker_ios image_picker_platform_interface]
- md5_file_checksum 1.0.3 [flutter]
- navigation_history_observer 1.1.0 [flutter built_collection]
- overlay_support 1.2.1 [flutter async]
- page_transition 2.0.5 [flutter]
- path_provider 2.0.10 [flutter path_provider_android path_provider_ios path_provider_linux path_provider_macos path_provider_platform_interface path_provider_windows]
- provider 6.0.3 [collection flutter nested]
- shared_preferences 2.0.13 [flutter shared_preferences_android shared_preferences_ios shared_preferences_linux shared_preferences_macos shared_preferences_platform_interface shared_preferences_web shared_preferences_windows]
- sign_in_with_apple 4.0.0 [flutter meta sign_in_with_apple_platform_interface sign_in_with_apple_web]
- twitter_login 4.2.2 [flutter crypto http]
- ubuntu_font_flutter 0.0.1 [flutter]
- url_launcher 6.1.0 [flutter url_launcher_android url_launcher_ios url_launcher_linux url_launcher_macos url_launcher_platform_interface url_launcher_web url_launcher_windows]

dev dependencies:
- flutter_lints 1.0.4 [lints]
- flutter_test 0.0.0 [flutter test_api path fake_async clock stack_trace vector_math async boolean_selector characters charcode collection matcher material_color_utilities meta source_span stream_channel string_scanner term_glyph typed_data]

transitive dependencies:
- archive 3.3.0 [crypto path]
- args 2.3.0
- async 2.8.2 [collection meta]
- boolean_selector 2.1.0 [source_span string_scanner]
- built_collection 5.1.1
- characters 1.2.0
- charcode 1.3.1
- clock 1.1.0
- collection 1.15.0
- cross_file 0.3.3+1 [js meta]
- dbus 0.7.3 [args ffi meta xml]
- fake_async 1.2.0 [clock collection]
- ffi 1.1.2
- file 6.1.2 [meta path]
- firebase_auth_platform_interface 6.2.4 [firebase_core flutter meta plugin_platform_interface]
- firebase_auth_web 3.3.13 [firebase_auth_platform_interface firebase_core firebase_core_web flutter flutter_web_plugins http_parser intl js meta]
- firebase_core_platform_interface 4.2.5 [collection flutter meta plugin_platform_interface]
- firebase_core_web 1.6.2 [firebase_core_platform_interface flutter flutter_web_plugins js meta]
- firebase_dynamic_links_platform_interface 0.2.3 [firebase_core flutter meta plugin_platform_interface]
- firebase_messaging_platform_interface 3.3.0 [firebase_core flutter meta plugin_platform_interface]
- firebase_messaging_web 2.2.12 [firebase_core firebase_core_web firebase_messaging_platform_interface flutter flutter_web_plugins js meta]
- flutter_facebook_auth_platform_interface 3.1.0 [flutter plugin_platform_interface]
- flutter_facebook_auth_web 3.1.0 [flutter flutter_web_plugins js flutter_facebook_auth_platform_interface]
- flutter_local_notifications_linux 0.4.2 [flutter flutter_local_notifications_platform_interface dbus path xdg_directories]
- flutter_local_notifications_platform_interface 5.0.0 [flutter plugin_platform_interface]
- flutter_plugin_android_lifecycle 2.0.6 [flutter]
- flutter_web_plugins 0.0.0 [flutter js characters collection material_color_utilities meta typed_data vector_math]
- google_sign_in_android 5.2.5 [flutter google_sign_in_platform_interface]
- google_sign_in_ios 5.2.5 [flutter google_sign_in_platform_interface]
- google_sign_in_platform_interface 2.1.2 [flutter quiver]
- google_sign_in_web 0.10.1 [flutter flutter_web_plugins google_sign_in_platform_interface js]
- http_parser 4.0.0 [charcode collection source_span string_scanner typed_data]
- image 3.1.3 [archive meta xml]
- image_picker_android 0.8.4+13 [flutter flutter_plugin_android_lifecycle image_picker_platform_interface]
- image_picker_for_web 2.1.8 [flutter flutter_web_plugins image_picker_platform_interface]
- image_picker_ios 0.8.5+5 [flutter image_picker_platform_interface]
- image_picker_platform_interface 2.5.0 [cross_file flutter http plugin_platform_interface]
- intl 0.17.0 [clock path]
- js 0.6.3
- lint 1.8.2
- lints 1.0.1
- matcher 0.12.11 [stack_trace]
- material_color_utilities 0.1.3
- meta 1.7.0
- nested 1.0.0 [flutter]
- path 1.8.0
- path_provider_android 2.0.14 [flutter path_provider_platform_interface]
- path_provider_ios 2.0.9 [flutter path_provider_platform_interface]
- path_provider_linux 2.1.5 [ffi flutter path path_provider_platform_interface xdg_directories]
- path_provider_macos 2.0.6 [flutter path_provider_platform_interface]
- path_provider_platform_interface 2.0.3 [flutter platform plugin_platform_interface]
- path_provider_windows 2.0.5 [ffi flutter path path_provider_platform_interface win32]
- petitparser 4.4.0 [meta]
- platform 3.1.0
- plugin_platform_interface 2.1.2 [meta]
- process 4.2.4 [file path platform]
- quiver 3.0.1+1 [matcher]
- shared_preferences_android 2.0.11 [flutter shared_preferences_platform_interface]
- shared_preferences_ios 2.1.0 [flutter shared_preferences_platform_interface]
- shared_preferences_linux 2.1.0 [file flutter path path_provider_linux path_provider_platform_interface shared_preferences_platform_interface]
- shared_preferences_macos 2.0.3 [flutter shared_preferences_platform_interface]
- shared_preferences_platform_interface 2.0.0 [flutter]
- shared_preferences_web 2.0.3 [flutter flutter_web_plugins shared_preferences_platform_interface]
- shared_preferences_windows 2.1.0 [file flutter path path_provider_platform_interface path_provider_windows shared_preferences_platform_interface]
- sign_in_with_apple_platform_interface 1.0.0 [flutter plugin_platform_interface meta]
- sign_in_with_apple_web 1.0.1 [flutter flutter_web_plugins sign_in_with_apple_platform_interface js]
- sky_engine 0.0.99
- source_span 1.8.1 [collection path term_glyph]
- stack_trace 1.10.0 [path]
- stream_channel 2.1.0 [async]
- string_scanner 1.1.0 [charcode source_span]
- term_glyph 1.2.0
- test_api 0.4.8 [async boolean_selector collection meta source_span stack_trace stream_channel string_scanner term_glyph matcher]
- timezone 0.8.0 [path]
- typed_data 1.3.0 [collection]
- universal_io 2.0.4 [collection crypto meta typed_data]
- url_launcher_android 6.0.15 [flutter url_launcher_platform_interface]
- url_launcher_ios 6.0.15 [flutter url_launcher_platform_interface]
- url_launcher_linux 3.0.0 [flutter url_launcher_platform_interface]
- url_launcher_macos 3.0.0 [flutter url_launcher_platform_interface]
- url_launcher_platform_interface 2.0.5 [flutter plugin_platform_interface]
- url_launcher_web 2.0.9 [flutter flutter_web_plugins url_launcher_platform_interface]
- url_launcher_windows 3.0.0 [flutter url_launcher_platform_interface]
- vector_math 2.1.1
- win32 2.5.2 [ffi]
- xdg_directories 0.2.0+1 [meta path process]
- xml 5.3.1 [collection meta petitparser]
- yaml 3.1.0 [collection source_span string_scanner]

Thanks for the detailed report @Panagiss.
Looking at the use case you shared, it seems that the linking part at Flutter side works properly as you mentioned The linking has been completed successfully, but when the data goes to firebase, it gets updated / overwritten and the vice-versa doesn't seem to be the case, which makes me think that this could be a behavior to reported to firebase support and see what they say about, because it doesn't seem to be flutterfire / client side issue.
I'll keep this issue open for now until you get any resolution from them on this case.

I have reached out to Firebase support. Don't have any update myself though

Thanks for the update. Please share their feedback once you get it.


Could you add to Readme where icon stored?

I noticed that you use method of NSWorkspace, but, it would be nice if this icon can be saved somehow. So, could add a an option to save icon locally via updating Readme or adding "Extract icon" button?

Good idea! I implemented it and released a new version: https://github.com/DerLobi/XcoatOfPaint/releases/tag/1.3
Just press ⌘ + S 🥳


bug: ion-select doesn't work inside a ion-item tag

Bug Report
Current behavior:
Implementing a ion-select inside a ion-item tag, but upon clicking, nothing happens.
If I remove the ion-item tag, the ion-select works as expected.
It's confusing because the Docs shows that you  can use a ion-select under a ion-item tag.
Expected behavior:
I would expect the ion-select to work inside a ion-item tag according to the docs.
Related code:
Works:
<!-- <ion-item> -->
      <ion-label>Gender</ion-label>
      <ion-select placeholder="Select One">
        <ion-select-option value="f">Female</ion-select-option>
        <ion-select-option value="m">Male</ion-select-option>
      </ion-select>
    <!-- </ion-item> -->

    <!-- <ion-item> -->
      <ion-label>Hair Color</ion-label>
      <ion-select value="brown" okText="Okay" cancelText="Dismiss">
        <ion-select-option value="brown">Brown</ion-select-option>
        <ion-select-option value="blonde">Blonde</ion-select-option>
        <ion-select-option value="black">Black</ion-select-option>
        <ion-select-option value="red">Red</ion-select-option>
      </ion-select>
    <!-- </ion-item> -->

Doesn't work:
<ion-item>
      <ion-label>Gender</ion-label>
      <ion-select placeholder="Select One">
        <ion-select-option value="f">Female</ion-select-option>
        <ion-select-option value="m">Male</ion-select-option>
      </ion-select>
    </ion-item>

    <ion-item>
      <ion-label>Hair Color</ion-label>
      <ion-select value="brown" okText="Okay" cancelText="Dismiss">
        <ion-select-option value="brown">Brown</ion-select-option>
        <ion-select-option value="blonde">Blonde</ion-select-option>
        <ion-select-option value="black">Black</ion-select-option>
        <ion-select-option value="red">Red</ion-select-option>
      </ion-select>
    </ion-item>

Other information:

Ionic info:
Ionic:

   Ionic CLI                     : 5.4.13 (/usr/local/lib/node_modules/ionic)
   Ionic Framework               : @ionic/angular 4.11.7
   @angular-devkit/build-angular : 0.801.3
   @angular-devkit/schematics    : 8.1.3
   @angular/cli                  : 8.1.3
   @ionic/angular-toolkit        : 2.1.1

Utility:

   cordova-res                          : not installed
   native-run (update available: 0.3.0) : 0.2.9

System:

   NodeJS : v12.13.0
   npm    : 6.13.4
   OS     : macOS Mojave

Thanks for the issue. Can you provide a repo with the code required to reproduce this issue?

@liamdebeasi So, I did some digging and found out that it's an issue with Firefox Developer Edition v73.0b2 (64-bit). With Chrome works fine.

Can you try on v73.0b3? I just tried it on my end, and it works fine.

@liamdebeasi ok, updated and found out that it doesn't work on my end if "touch simulation" is activated in the dev tools.
I'm emulating Pixel 2 XL

Thanks for the follow up. I created a reproduction of the same issue without using any Ionic components: https://codepen.io/liamdebeasi/pen/zYxjvdw
It looks like it has something to do with particular CSS being applied to interactive elements in the Shadow DOM. I am going to close this as this does not appear to be a bug in Ionic Framework; however, we will look into reporting this issue to the Firefox team. Thanks!

Hey there, I filed a bug with the Firefox team: https://bugzilla.mozilla.org/show_bug.cgi?id=1640189. Looks like this has been fixed in Firefox 78, so a fix should be available whenever that ships.


update repository url

Using https link address so that the Extension Market could recognize.

The old link shows like this, which is a wrong link.

Thanks!


It broke for browserify

Browserify does not check the existence of the "browser-field" in the npm package.json. Even with babelify, it does not work.

There already exists a test case for browserify with babelify and it seems
to be working. Can you share some extra info about your configuration?
On Mon, Aug 3, 2015, 13:55 Bob Hamblok<EMAIL_ADDRESS>wrote:

Browserify does not check the existence of the "browser-field" in the npm
package.json. Even with babelify, it does not work.
—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/localForage/issues/412.

--
Thodoris Greasidis
Computer, Networking &
Communications Engineer

Looks like there's definitely a browersify issue: #413 reports it as well.

I have the same issue at https://github.com/Turbo87/open-flight-planner
I worked fine with localforage v1.2.4, but breaks with v1.2.6.

I will take a look at it as soon as I'm home. It's nice to have a reference
repo to work on this.
On Mon, Aug 3, 2015, 14:37 Tobias Bieniek<EMAIL_ADDRESS>wrote:

I have the same issue at https://github.com/Turbo87/open-flight-planner
I worked fine with localforage v1.2.4, but breaks with v1.2.6.
—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/localForage/issues/412#issuecomment-127203420
.

--
Thodoris Greasidis
Computer, Networking &
Communications Engineer

I think I know what it is. In the other example it’s someone loading src/localforage.js, not the fully built version. I never advertised this as supported but it’s worked in the past.
I’m going to push a version 1.2.7 as a fix that supports the including from src version, then a 1.3 that explicitly doesn’t in the changelog.
Sorry for forgetting we’d be breaking this.

tofumatt

On Mon, Aug 3, 2015 at 12:52 PM, Thodoris Greasidis
<EMAIL_ADDRESS>wrote:

I will take a look at it as soon as I'm home. It's nice to have a reference
repo to work on this.
On Mon, Aug 3, 2015, 14:37 Tobias Bieniek<EMAIL_ADDRESS>wrote:

I have the same issue at https://github.com/Turbo87/open-flight-planner
I worked fine with localforage v1.2.4, but breaks with v1.2.6.
—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/localForage/issues/412#issuecomment-127203420
.

--
Thodoris Greasidis
Computer, Networking &
Communications Engineer
Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-127207425

Uploaded a new release to GitHub and npm. This should be fixed now, but there will be a new release later today: 1.3 that will not support loading src/localforage and will only work with the dist/localforage.js version.

@tofumatt I am not explicitly loading anything, I am just installing the package via npm and using browserify + babel to compile my script that imports from localforage. (see repo mentioned above)

Yeah, we were pointing to the src/ version in the package too :-(
I’ve pushed a new version 1.2.7 that fixes it and I think I’m going to push the new es6 version as a new release entirely, because it will break compatibility with a lot of other things.
Sorry about all this. I messed up! But it should be fixed now.

tofumatt

On Mon, Aug 3, 2015 at 1:12 PM, Tobias Bieniek<EMAIL_ADDRESS>wrote:

@tofumatt I am not explicitly loading anything, I am just installing the package via npm and using browserify + babel to compile my script that imports from localforage. (see repo mentioned above)
Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-127214078

@tofumatt no worries, thanks for the quick fix!

While testing with open-flight-planner got some interesting findings:

browserify does not like "browser": "dist/localforage.js"

it gives: Error: Cannot find module './../utils/serializer'

it works fine with "browser": "build/es5src/localforage.js",

if it is included of course. The whole point of this is to leave all the project-specific babel configurations away from our users

Seems like we need some better/new browserify tests.

tofumatt

On Mon, Aug 3, 2015 at 6:23 PM, Thodoris Greasidis
<EMAIL_ADDRESS>wrote:

While testing with open-flight-planner got some interesting findings:

browserify does not like "browser": "dist/localforage.js"

it gives: Error: Cannot find module './../utils/serializer'

it works fine with "browser": "build/es5src/localforage.js",

if it is included of course. The whole point of this is to leave all the project-specific babel configurations away from our users

Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-127336708

It looks like that with browserify we can't just concat the files.
We

either need to actually use browserify to generate our build (I'm not a fan of this),
or add the es5 sources and point browserify to them.

I like the second more (obviously just personal opinion), since my point of view while refactoring to es6 was to have minimal +-diff on the dist files.
I never actually got the old dist files to work with browserify and that is visible from our browserify test code. So I think that our build system never actually supported browserify users, or at least not without extra configuration. It seems that all this time it worked just because we were pointing them to src/. (On the other hand I'm not a browserify expert.)

I like the idea of a minimal difference on the output, but I'd really prefer just to have one supported build file, and I'd rather not include even more built files. And I really think it would be easier to support.
I think we should just use it as our built file unless it makes a huuuge difference... what does the output of the browserify version look like compared to the just es6+concat version?

tofumatt

On Mon, Aug 3, 2015 at 6:35 PM, Thodoris Greasidis
<EMAIL_ADDRESS>wrote:

It looks like that with browserify we can't just concat the files.
We

either need to actually use browserify to generate our build (I'm not a fan of this),
or add the es5 sources and point browserify to them.
I like the second more (obviously just personal opinion), since my point of view while refactoring to es6 was to have minimal +-diff on the dist files.
I never actually got the old dist files to work with browserify and that is visible from our browserify test code. So I think that our build system never actually supported browserify users, or at least not without extra configuration. It seems that all this time it worked just because we were pointing them to src/. (On the other hand I'm not a browserify expert.)

Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-127340202

A browserify build is generated at test/localforage.browserify.js after a run of grunt test (for the browserify tests). I'm not sure how(/if) this would work for requirejs users, but we currently include runner.browserify.js (an 1line file) in order to make localforage available to the global namespace.

It looks like that it removes the UMD pattern.

I've done some research on this during this week and this seems to be a general problem for libs that need transformations to build.
I will probably open a PR tonight that will introduce some changes to package.json, so that browserify users will be able to use the src in their build chain (like in older versions).
The PR will basically disclose our babel(ify) configuration options and transformations so that browserify-enabled apps will know how to build & require localforage module.
In a later PR (hopefully in a week) I will try to direct browserify users to the dist sources.
The are some issues there, with browserify trying to reanalyze the require calls of the already bundled dist file.
Such a move will probably only allow us to export the localforage namespace, encapsulating/hiding the drivers and the serializer namespaces. Any suggestion about how to expose them for plugins? Maybe something like localforage.serializer or localforage.getSerializer() ?

I’m okay with localforage.serializer, I think even exposing that in general isn’t bad. Maybe someone wants to use the serializer directly for something and I don’t mind exposing that as an API.

tofumatt

On 6 August 2015 at 08:48:43, Thodoris Greasidis<EMAIL_ADDRESS>wrote:
I've done some research on this during this week and this seems to be a general problem for libs that need transformations to build.
I will probably open a PR tonight that will introduce some changes to package.json, so that browserify users will be able to use the src in their build chain (like in older versions).
The PR will basically disclose our babel(ify) configuration options and transformations so that browserify-enabled apps will know how to build & require localforage module.
In a later PR (hopefully in a week) I will try to direct browserify users to the dist sources.
The are some issues there, with browserify trying to reanalyze the require calls of the already bundled dist file.
Such a move will probably only allow us to export the localforage namespace, encapsulating/hiding the drivers and the serializer namespaces. Any suggestion about how to expose them for plugins? Maybe something like localforage.serializer or localforage.getSerializer() ?
—
Reply to this email directly or view it on GitHub.

I would also like to suggest a localforage.getDrivet(driverName) method that will be used by setDriver internally.
Such a method would allow:

the creation of custom drivers that extend a base driver and only override some of the methods (eg: Cordova sqlite driver(s) actually only need to override the _initStorage methods)
the user to check whether a driver is defined

That would be awesome. It would return the entire driver module, right?

tofumatt

On Thu, Aug 6, 2015 at 4:51 PM, Thodoris Greasidis
<EMAIL_ADDRESS>wrote:

I would also like to suggest a localforage.getDrivet(driverName) method that will be used by setDriver internally.
Such a method would allow:

the creation of custom drivers that extend a base driver and only override some of the methods (eg: Cordova sqlite driver(s) actually only need to override the _initStorage methods)
the user to check whether a driver is defined

Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-128416633

Glad to hear it.
Yes, I guess so. It would be exactly what set Driver imports and uses.
My only extra concern, would be whether it should return a promise. With the current implementation, it should. On the other hand, since, as you said, we are dropping dynamic driver loading, it could also return a plain driver object.

On the other hand, we all love promises and localforage at the moment has very few not promise-based APIs...

Good point. It should return a promise that would eventually resolve to the driver, not the driver object itself :-)

tofumatt

On Thu, Aug 6, 2015 at 6:33 PM, Thodoris Greasidis
<EMAIL_ADDRESS>wrote:

On the other hand, we all love promises and localforage at the moment has very few not promise-based APIs...
Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-128452416

Hi!

Are the localforage.serializer and the rest exposed (while encapsulated) methods available for v1.3? (or will be?)

I believe that these are definitely needed because our browserify project used the module system, so we have no global objects. Therefore, there are problems with the serializer, etc.

I would also like to create a custom driver and use it when all other 3 drivers are not supported. Do you expose any methods to check which driver is to be used? (like driverSupport but exposed)
I could use this method and if this returns null then I would know that all 3 drivers cannot be supported so that I then apply our custom driver (but will this work in this sequence?).

Hi @af7, could you file these both as separate issues? Happy to help but we need to keep these discussions separated :smile:
If you could try installing the latest localForage from master in your project and let me know how it works with browserify that would be great. I could publish 1.3 as a beta/pre-release on npm, if that works.

Sure, I''ll transfer the 2nd bullet to a separate discussion.
1st bullet is related to this thread (browserify) and basically for when custom drivers are to be implemented. When using the module type (like browserify does) we do not have the serializer exposed, so how can we use it on our (browserify-based) project code for a custom driver that we want to develop? Unless I miss something here. So, I believe that the suggestions of @thgreasi are very valid (and actually needed in my case). I hope these methods can be exposed to the localForage instance (not on global) in the upcoming v1.3 so that we can use them now.
Thanks.

Using the code from the current master, you can still require the serializer on its own.
I will use localForage-cordovaSQLiteDriver as an example. In that project I assume that the custom driver will be next to localforage module (like a peer dependency) and as a result the relative path (from localforage-cordovasqlitedriver.js to the serialzier.js) that is used by the require statement is './../../localforage/src/utils/serializer'.
The "expose the serializer on the localforage namespace" is not required by the current master.
It will be a nice to have after we start using a bundler (instead of just concatenating the files), since the bundler (eg: browserify) will only expose the 'localforage' namespace.
On the other hand, if you are using browserify you will always be allowed to just require the serializer from the src folder, even after we change the source bundling mechanism. For example, require('node_modules/localforage/src/utils/serializer').

About point 2.
There is a localforage.supports() method but it looks like it is not documented. It should be visible from your browser's dev tools console though.

Good point, I filed #423 for that.

tofumatt

On Sun, Aug 16, 2015 at 12:44 PM, Thodoris Greasidis
<EMAIL_ADDRESS>wrote:

About point 2.
There is a localforage.supports() method but it looks like it is not documented. It should be visible from your browser's dev tools console though.
Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-131530704

I"m experiencing the same issue (https://github.com/mozilla/localForage/issues/412#issuecomment-127336708) grabbing localstorage with browserify in split bundles.
I'm on:
npm v2.14.0
browserify v11.0.1
localforage v1.2.8 (the latest available on npm)
I have a "browser" section in my package.json pointing to the actual dist file.
package.json
  "browser": {
    "localforage": "./node_modules/localforage/dist/localforage.js"
  },

I'm grabbing all things from this "browser" property and requiring them on my vendor bundle:
gulpfile.js
var browserify    = require('browserify');
var source        = require('vinyl-source-stream');
var buffer        = require('vinyl-buffer');
var vendorBundle  = browserify({ debug: false });

// grab dependencies to be bundled as a separate file `vendor.js`
var dependencies = Object.keys(require('package.json').browser).map(function(module) {
    var resolvedPath = require.resolve(module);
    vendorBundle.require(resolvedPath, { expose: module });
    return resolvedPath;
});

gulp.task('vendor-bundle', function() {
    vendorBundle.bundle()
        .pipe(source('vendor.js'))
        .pipe(buffer())
        .pipe(gulp.dest('./public/js');
});

I have an app.js that also gets browserified with babelify using:
app.js
import localforage from 'localforage';

the build results in:
Error: Cannot find module './../utils/serializer' from './node_modules/localforage/dist'
Error: Cannot find module './drivers/indexeddb' from './node_modules/localforage/dist'
Error: Cannot find module './drivers/localstorage' from './node_modules/localforage/dist'
Error: Cannot find module './drivers/websql' from './node_modules/localforage/dist'

To follow up, import and require output no errors if I include localforage in the main app.js bundle.
It only fails with error output when specifically grabbing the ./node_modules/localforage/dist/localforage.js or .min.js variants and putting them in a separate bundle (note, this is the only package that is having any issues).

@mshwery I think that you should not manually point to the dist file and use whatever the library points in its package.json.
The whole point of the browser field, is to allow the package maintainer handle the appropriate entry point for browserify users.

I checked those out but their setup really isn't different than my use case...

Such an override is considered a setup difference.

Agreed; we point users to a specific file as it’s the only thing we have a test case for. Other uses of localForage are unsupported, and possibly won’t work by design.

tofumatt

On Wed, Aug 26, 2015 at 5:40 PM, Thodoris Greasidis
<EMAIL_ADDRESS>wrote:

@mshwery I think that you should not manually point to the dist file and use whatever the library points in its package.json.
The whole point of the browser field, is to allow the package maintainer handle the appropriate entry point for browserify users.

I checked those out but their setup really isn't different than my use case...
Such an override is considered a setup difference.

Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-135101530

@tofumatt @thgreasi you are probably right that I should just specify a list of modules, but in my case if the package provides .min versions I would rather bundle those than do minification unnecessarily myself. Whatever is in the dist directory should all be fully working packages without any build step (at least, for client-side packages that should be the expectation).
Regardless, I'm pointing to the exact same file as localforage's package.json: https://github.com/mozilla/localForage/blob/master/package.json#L49

That's our target for v1.3 by the way.
We will drop all the module system specific fields from package.json and
point everyone to the dist file, using only the 'main' package.json field.
In any case, just trust the package.json and you will not face any problem,
even after upgrading to v1.3 (when released).
On Wed, Aug 26, 2015, 20:21 Matt Shwery<EMAIL_ADDRESS>wrote:

@tofumatt https://github.com/tofumatt @thgreasi
https://github.com/thgreasi you are probably right that I should just
specify a list of modules, but in my case if the package provides .min
versions I would rather bundle those than do minification unnecessarily
myself. Whatever is in the dist directory should all be fully working
packages without any build step (at least, for client-side packages that
should be the expectation).
Regardless, I'm pointing to the exact same file as localforage's
package.json:
https://github.com/mozilla/localForage/blob/master/package.json#L49
—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/localForage/issues/412#issuecomment-135113249
.

--
Thodoris Greasidis
Computer, Networking &
Communications Engineer

Also, the sources and package.json in the master branch are not the same
found in the latest release v1.2.8 (if I can remember correctly). The
master branch currently holds the sources of what will be v1.3 .
On Wed, Aug 26, 2015, 20:33 Thodoris Greasidis<EMAIL_ADDRESS>wrote:

That's our target for v1.3 by the way.
We will drop all the module system specific fields from package.json and
point everyone to the dist file, using only the 'main' package.json field.
In any case, just trust the package.json and you will not face any
problem, even after upgrading to v1.3 (when released).
On Wed, Aug 26, 2015, 20:21 Matt Shwery<EMAIL_ADDRESS>wrote:

@tofumatt https://github.com/tofumatt @thgreasi
https://github.com/thgreasi you are probably right that I should just
specify a list of modules, but in my case if the package provides .min
versions I would rather bundle those than do minification unnecessarily
myself. Whatever is in the dist directory should all be fully working
packages without any build step (at least, for client-side packages that
should be the expectation).
Regardless, I'm pointing to the exact same file as localforage's
package.json:
https://github.com/mozilla/localForage/blob/master/package.json#L49
—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/localForage/issues/412#issuecomment-135113249
.

--
Thodoris Greasidis
Computer, Networking &
Communications Engineer

--
Thodoris Greasidis
Computer, Networking &
Communications Engineer

Yup, the pre-es6-refactor branch has the code for the 1.2 branch from 1.2.7 onward (1.2.7-1.2.8).
https://github.com/mozilla/localForage/tree/pre-es6-refactor

tofumatt

On Wed, Aug 26, 2015 at 6:38 PM, Thodoris Greasidis
<EMAIL_ADDRESS>wrote:

Also, the sources and package.json in the master branch are not the same
found in the latest release v1.2.8 (if I can remember correctly). The
master branch currently holds the sources of what will be v1.3 .
On Wed, Aug 26, 2015, 20:33 Thodoris Greasidis<EMAIL_ADDRESS>wrote:

That's our target for v1.3 by the way.
We will drop all the module system specific fields from package.json and
point everyone to the dist file, using only the 'main' package.json field.
In any case, just trust the package.json and you will not face any
problem, even after upgrading to v1.3 (when released).
On Wed, Aug 26, 2015, 20:21 Matt Shwery<EMAIL_ADDRESS>wrote:

@tofumatt https://github.com/tofumatt @thgreasi
https://github.com/thgreasi you are probably right that I should just
specify a list of modules, but in my case if the package provides .min
versions I would rather bundle those than do minification unnecessarily
myself. Whatever is in the dist directory should all be fully working
packages without any build step (at least, for client-side packages that
should be the expectation).
Regardless, I'm pointing to the exact same file as localforage's
package.json:
https://github.com/mozilla/localForage/blob/master/package.json#L49
—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/localForage/issues/412#issuecomment-135113249
.

--
Thodoris Greasidis
Computer, Networking &
Communications Engineer

--
Thodoris Greasidis
Computer, Networking &
Communications Engineer
Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-135119285

ah, gotcha. thanks for all the help guys!

No worries, hope it helps 👍

tofumatt

On Wed, Aug 26, 2015 at 6:58 PM, Matt Shwery<EMAIL_ADDRESS>wrote:

ah, gotcha. thanks for all the help guys!
Reply to this email directly or view it on GitHub:
https://github.com/mozilla/localForage/issues/412#issuecomment-135124208


README: Please add details of pairing & GATT support

A few additional things need to be explained:

The README says very little about pairing/security of the BLE connections. I assume that the DS configures itself to indicate no keyboard/no display, so the only pairing supported would be "Just Works". I also assume the DS always acts as a BLE client, and will initiate pairing during discovery if a device is found that's listed in the configuration, correct? Does the device always have to be put into discovery mode, or if it's been paired once, will it autoconnect the next time?

Although the README mentions that the DS only supports the GATT profile, it doesn't say to what extent. Is there any discovery of services and characteristics, or is everything just statically configured in the device profile? Does someone just define a set of device resources that map to specific service/characteristics? Are notifications or indications supported?  An example might be helpful.

@tonyespy

The README says very little about pairing/security of the BLE connections. I assume that the DS configures itself to indicate no keyboard/no display, so the only pairing supported would be "Just Works". I also assume the DS always acts as a BLE client, and will initiate pairing during discovery if a device is found that's listed in the configuration, correct? Does the device always have to be put into discovery mode, or if it's been paired once, will it autoconnect the next time?

This device service doesn’t pair with devices. The discovery uses BlueZ to look for any bluetooth devices around and logs their details. Once the discovery has completed and the device service initialisation is complete any read and write commands that come in will use the device's MAC address to perform a connection to the specified device. If this device was not logged by BlueZ during discovery then BlueZ will not be able to perform a connection to the device. If it does have the device logged then it will connect, perform the reading/writing and then disconnect again.
I have added an extra paragraph that explains the need for discovery.

Although the README mentions that the DS only supports the GATT profile, it doesn't say to what extent. Is there any discovery of services and characteristics, or is everything just statically configured in the device profile? Does someone just define a set of device resources that map to specific service/characteristics? Are notifications or indications supported? An example might be helpful.

BLE GATT device resources are statically configured in the device profile. These resources map their GATT characteristic UUID’s to read/write specific values.
Some GATT characteristics are vendor specific though, meaning they don't follow standard data types. Some Vendor-specific devices still return data in a final readable format, such as an Integer or a Float. However, some of these characteristics don't. In order to convert the data into a readable format that can be used within EdgeX, conversion options are available, these are very specific to each manufacturer however, more can be registered in conversion.c.
I have updated the README explaining this, giving examples.
Changes have been made in PR: https://github.com/edgexfoundry-holding/device-bluetooth-c/pull/26

The discovery uses BlueZ to look for any bluetooth devices around and logs their details.

Does this mean that I should see some info printed on screen if devices are found during discovery? What would they look like?
I'm checking with blmon during the discovery and I can see that my GATT server is found but I don't have any confirmation from the ds.


[2.x] fix scripted

@eed3si9n This is ready to review. There are a few more scripted tests to fix but I'll do it in separate PRs.

I should stop to modify this now. @eed3si9n feel free to review when you have time.
I think we should merge this sooner rather than later not to keep pending tests for too long. Also I would like to start merging changes from 1.x into 2.x soon.

Thanks! I am still curious about your opinion on https://github.com/sbt/sbt/pull/7522#discussion_r1555559083, https://github.com/sbt/sbt/pull/7522#discussion_r1559447732 and https://github.com/sbt/sbt/pull/7522#discussion_r1559455960


Multi datasets

Adds support for using data from multiple datasets, and also combining hidden states from multiple layers

Okay, eval, elicit and extract work now.
However, I am wondering why imdb performs a bit worse (AUROC) than on main with the default seed... (Especially the last layer is just a bit over random

No idea, but we shouldn't merge until we figure out why. What is the exact command you're running to get that result?

No idea, but we shouldn't merge until we figure out why.
Alrght, let's merge!

What is the exact command you're running to get that result?
Simply, something like:

elicit gpt2 imdb --num_gpus 2
eval <run_name> gpt2 imdb --num_gpus 2

Of course, it's just gpt2, but yeah let's figure that out later...

Sorry, I misread Noras previous message, somehow. Will revert the pull-request for now, and we might want to look better into a possible performance regression first.


Updates event for equal objects

Update events trigger when object don't updated. It's look normally?

For now yes this is the expected behavior if you set a path to the exact same. However, I am thinking to change this but I'm still wondering whether I should add a pure option to the tree or make this new behavior default. I cannot remember now but I think I found some cases where the tree does not update were a bit too magical for the user.

Yes, i think option or event with different name best way for realize it.

Option is now default on v2.


Automated project structure updation using github workflows, python scripts and action bot

Closes: #129
Screenshots:

@yuvrajsinghgmx Please check now. Let me know in case u want to change the time of cron. It's set for every hour once


Folders not being created...

Hello, for some reason I'm seeing this error now when I deploy:
public_html/stage/domain.com/releases/20161216201859/bootstrap/cache/services.php)): failed to open stream: No such file or directory
capistrano/laravel isn't checking to see if those directories exist. Here's my deploy.rb
# Laravel Stuff
set :laravel_roles, :all
set :laravel_version, 5.2
set :laravel_5_acl_paths, [
  'bootstrap/cache',
  'storage',
  'storage/app',
  'storage/app/public',
  'storage/framework',
  'storage/framework/cache',
  'storage/framework/sessions',
  'storage/framework/views',
  'storage/logs'
]
set :laravel_ensure_acl_paths_exist, true

I didnt have set :laravel_5_acl_paths or set :laravel_ensure_acl_paths_exist in there before because it was default, but I added it just to be sure and still failing.
Thank you for writing this!

So just to give a quick update, I've done literally everything I can think of including re-creating the configs based on one that is working. No matter what I do, it won't run the task that makes the folders. I even have in the logs where during the last successful deploy the task ran, but then all of a sudden it stopped.


Make cmp argument optional in tablex.count_map

The documentation and code suggests that the comparison function, cmp, should be optional, but it currently crashes because of a call to utils.function_arg with cmp = nil.

Thanks man. These little things matter a lot.


Add support for Ollama

Overview
Add support for Ollama to enable users to run open source models locally.
This feature is required for privacy focused users who do not want to share their code with LLM providers.
Requirements

Integration with Ollama API using langchain
Support for multiple open source models available through Ollama
Seamless switching between cloud and local models using the providers API

Technical Details

Implement Ollama API client
Add configuration options for Ollama endpoint and model selection
Ensure compatibility with existing application interfaces

Success Criteria

Users can run local models through Ollama
Successful Knowledge graph creation and agent execution.

@dhirenmathur I would like to work on this, can you assign it to me.

@waveywaves are you working on this or can I assign it to someone else?

@dhirenmathur hey Dhiren ! continuing work on this... shall post an update in the next day


Vertical Path

Hey there,
Is there an easy way to turn a line bar so it is vertical instead of horizontal, and not using a CSS transform to do so? I need a simple vertical bar that fills from bottom to top.
I could use an SVG, but it seems odd that we'd have a horizontal bar and not a vertical bar. I assumed maybe there's just an easy way to rotate it or access a different type of line.
Thanks!
-S

This could be part of the progressbar API. I'm open for a PR to implement this bar.

I also wish this was a thing!

Closing due to inactivity – will accept a PR for this. Should be a simple addition.


[RFC] Ensure display name uniqueness across the entire platform

I see three major ways forward:

Allow duplicate display name text and use a tag to differentiate between duplicates in the client. Discord does this. Looks like Jason#1234.

Do not allow duplicate display name text and make display names first-come-first-serve. Using this strategy, we can still allow users to have a custom display name per game they are a member of. A complication with this strategy is that we would also have to consider allowing users to have a custom photo to accompany each username, which I do not think would scale well.

Just allow duplicate display names.

I'm looking forward to comments and further ideas.

For scalability, I think #1.
Works well on Discord, avoids potential issues arising from confusion etc.

I agree that will scale well. I also like that it allows duplicate display names without issue, meaning nobody doesn't get the name they want because it's held by another account.


Re #24 Update the in-memory deployment to stateful set with emptyDir

This PR should address #24 - it changes the kafka-inmemory deployment to work exactly as the persisitent stateful set only with emptyDir storage. This means we have just a single image and the YMAL files are more similar and easier to update.
Note: This new PR replaces #28, where I incorrectly rebased to master and added some undesired commits.

lgtm


Feat/scroll responsive fixed nav bar

added the responsive nav bar.
FFIXES:- #295

Hey @Rushikesh0107 can you create a demo video of the changes you made in action and share it ?
Use loom  (https://www.loom.com/) if you want

Sure

Hey @Rushikesh0107, can you try implementing this without any extra packages. Please do the same for desktop site too.
Join us on Discord for any help.


Fuji testnet tx links incorrectly directed to mainnet explorer

When using the wallet with the Fuji testnet, transactions listed are incorrectly directed to the mainnet explorer rather than the testnet explorer.

Yes noticed too. Will fix soon!

Fixed.


autoaccept never worked

autoaccept never worked for me wondering why

Works just fine, the 'Accept' button stays unpressed but match is accepted.


Hello,I want to know how can  I update the ico of the packaged .exe file for the electron package

I want to change this default ico for the .exe file,please tell me wher to change this ico file,thankyou

It depends on your packager, I think. For example, with electron builder, see https://www.electron.build/icons

Thank you for the ideas.
------------------ 原始邮件 ------------------
发件人:                                                                                "csepulv/electron-with-create-react-app"                                                                                @.>;
发送时间: 2021年6月3日(星期四) 晚上11:26
@.>;
抄送: "2207326681"<2207326681@@.***>;
主题: Re: [csepulv/electron-with-create-react-app] Hello,I want to know how can  I update the ico of the packaged .exe file for the electron package (#41)
It depends on your packager, I think. For example, with electron builder, see https://www.electron.build/icons
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Not able to translate the not-found.tsx page

Describe the bug
The not-found.tsx page (404) has to be a direct child of the app directory. This is above the [locale] so does not receive the current locale data. Therefore, the 404 page is only available in the default language, not the current UI language.
To Reproduce

Using Next.js app router setup with multiple languages, place a not-found.tsx as a child of the app dir (sibling to [locale] dir).
Ensure some text is output on the 404 page using getI18n.
Change UI language from the default language to another language.
Visit a non-existent page.
See how the text is still in the default language.

Expected behavior
Text should show in the currently-selected language.
About

next-international version 1.2.4
Next.js version 14.1.0

Just fixed it with NotFoundCatchAll() and [...not_found] router.
Idea from https://liruifengv.com/posts/nextjs-404-in-i18n/

@xiguaakako I've implemented your suggestion and I can confirm it works. Thanks for the workaround!


compatible for browser environment

Background
has-symbols is widely referenced in both node and browser environment, weeks ago got below error in browser's console:

ReferenceError: global is not defined

So the PR is to add type defense for browser environment.

Duplicate of #4. Duplicate of #6. Duplicate of #11.


More scarfs

About the PR
Adds 12 new scarfs, you can find the list in media. Its from the light orange scarf down. I opted to put them in the winterdrobe since thats where the rest of the scarfs are, but I'm more than willing to move them to quick threads.
Why / Balance
More clothing for player and character representation
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes
Nothing currently, since they are in the winterdrobe they may cause merge conflicts later but I tried to label them decently well.
Changelog
Various scarfs have been added, you can find them in the winterdrobe. These are namely pride related scarfs.

Starting to think at this point we should just add the pridevend tbh


Highlighting text a little difficult to read

First of all, awesome theme and also contrib statement!
I like to code outside where glare can be an issue.  This theme is prefect for that (high contrast/white background to easily see cursor).  The one thing I'm having trouble with is that there is no highlight of text when you select it (line numbers becomes bold instead).
Would you be interested in a pr that adds highlighting?  I was thinking than on select, the highlight would be black and all underlying text white.

Hey thanks!!
I use this theme every day myself, I really need to give it more attention. What language are you using it with?
The black may be a little harsh but another option might be a solid black outline.

I'm using atom for general front-end stuff mostly.  html/less/js (we use angular), occasionally make.
I have discovered some things:

The ui theme I was using was causing no highlight to show up.  After trying to hack this theme and realizing I couldn't see any changes (and seeing you actually were changing the highlight background color in the source), I tried the default atom theme and I think the grey highlight you have looks nice and definitely works for me.  I'll explore the source of the ui theme I was using to see if there is a fix possible on that side of things. https://atom.io/themes/atomic-ui if you are curious.
The way that atom highlights text is pretty interesting.  It actually places highlight divs under the text and the background is able to be set on those.  The text that is highlighted itself is not given any contextual .select classes in the dom.  There's a great thread about that here https://github.com/atom/atom/issues/2886

In short, this issue seems like it should be closed.  I'll let you know if I notice anything else, but it seems like I haven't found anything I don't like with this theme so far. :)
As an aside, I'm really impressed with how thorough your readme's installation and contrib guidelines are.  They were definitely helpful to me, and also seem like they would be very helpful to people not super familiar with git.  You're definitely helping to make the open source community more open!

@jlmitch5 Interesting stuff, I'll give that UI theme a whirl. I'm using the built in light UI theme but I do want to create a high contrast complementary UI theme to pair with focus-white.
Thanks for the kind words, yeah I'm trying to make OSS a bit more friendly and easy for people who are new to it :D


docs: fix examples links in README

Already fixed in #110. Thanks for your contribution. Keep in mind it's still work in progress and we are working heavily on it.


Allow w2ui grid to use an external array for the records property

Referencing #1060, but making the title more meaningful. I'd like to not have to call add() for each record (or set of records) I want to add. It would be great if I could just assign an arbitrary array to grid.records and call refresh() to have the grid display these records.
The use case for this is getting data over websockets, which w2ui doesn't support. (This is most definitely not a request to support websockets!).
As it is now, I can do something like this:
grid.w2grid({ name: 'foo', recid: 'bar', columns: [ {...}, ...] );
var data = w2ui.foo.records;
data.push({...});
w2ui.foo.refresh();

However if I do this, selection breaks in the grid. Brief investigation showed this in the HTML:
<tr id="grid_grid-testmodel_rec_undefined"  ...   recid="undefined">

I'm not entirely sure if this is a bug report or feature quest. Thanks in advance for your attention to this matter.

I make a demo for your reference, hope I understood what you meaning.
You must use recid in your data record, ingore the recid property of w2grid.
http://plnkr.co/edit/zpxYvvkR974FLpo9rkOP?p=preview

Thank you for the demo and the clarification.  Your demo illustrates the problem I am talking about, if you remove adding any "recid" manually.
I'm must admit I am confused looking at the source. The add function (line 338 of  w2ui/src/w2grid.js) doesn't appear to add this recid or do anything special. It does check for a recid as far as I can see, but that's about it.
If I am adding to an existing grid dataset, I would hesitate to add a manual recid. Still, at least now I know how to do it this way.

if you are interested in "recid", you can search "recid" in source code, you can seen that a few place used "recid", for example, delete record.
btw, I'm a user, not developer of w2ui. I also confused why the grid dependent on "recid", but all I known is that I must manually add a "recid" for every record, that's it.

Let me try to explain what recid is. Recid is a unique field that should be present for each record. Think of it as a primary key of the table in the database that you are trying to edit. See http://w2ui.com/web/docs/w2grid.records for explanation.
Internally, recid is used in many methods. For example grid.get(recid), grid.select(recid), grid.click(recid), etc. Recid is also added into generated HTML. Grid will not add any id for the record, but would use recid for identification. If you do not care about recid, just generate one based on some unique generator.
As for grid.recid, it is used to remap some other unique property. If you defined it, then when records are loaded from server it will take field you specified in grid.recid and create recid with same value. It is just for convenience.
As I mentioned before, once the grid created you can grab reference to the grid.records array and use it elsewhere, adding and removing records.
If this explains the issue, please close the bug as I strive to keep issues resolved as they pile up.

I think I understand what you wrote. :)
Do you understand what I wrote?
This does not work:
var foo = grid.w2grid({ name: 'foo', recid: 'bar', columns: [ {...}, ...] );
var data = [];
data.push({bar: <some value>, ..});
foo.refresh();

You can see the records but you cannot select them. I tried to write a jsfiddle, but you don't appear to have https: enabled for w2ui.com so I can't.

@davehayes I created a demo for your reference, please see this: http://plnkr.co/edit/FEp0IgflZp6D14hF4YE5?p=preview

Thank you. I've now identified that the issue is 1.4.3. http://plnkr.co/edit/FEp0IgflZp6D14hF4YE5?p=preview


whitespace cleanup

Putting more against #4779. I accidentally pushed to my own, master, still need to get Magit down :joy: :joy:

Sure. I cleaned up a few more files, so I'll push those too. Is there any particular way you want me to batch them together? Just everything in a folder or something?


Fix PUDL Kaggle dataset updates

The PUDL Kaggle dataset last updated on August 24th, but it's supposed to pull new data every Monday from the S3 bucket, so something is broken.
I attempted a manual update and it failed with an error, but I can't actually see the error.  I made a forum post reporting the issue.
I'm worried that we might have run up against some kind of quota, and searching around the support forums it sounds like it may be impossible to delete old versions of a dataset, meaning the only way to continue with updates would be to create an entirely new dataset, which would be lousy for continuity.

Ah okay, with some help from the document source inspector, I was able to see the full error, which seems addressable. For some reason, the census DP1 database is no longer getting zipped in the nightly builds, and so it's not showing up at the expected URL:
Failed - Error during creation: Accessing URL failed (Response status code does not indicate success: 404 (Not Found).):
https://s3.us-west-2.amazonaws.com/pudl.catalyst.coop/nightly/censusdp1tract.sqlite.zip

Looking at last night's build logs, there's a weird error for only the compression of the Census DP1 database, which is confusing. Why would it run out of space on this one relatively small database, but not on pudl.sqlite which is much larger?
Compressing censusdp1tract.sqlite
  adding: censusdp1tract.sqlite
zip I/O error: No space left on device
zip error: Output file write failure (write error on zip file)
Compressing ferc1_dbf.sqlite
  adding: ferc1_dbf.sqlite (deflated 65%)
Compressing ferc1_xbrl.sqlite
  adding: ferc1_xbrl.sqlite (deflated 89%)
Compressing ferc2_dbf.sqlite
  adding: ferc2_dbf.sqlite (deflated 75%)
Compressing ferc2_xbrl.sqlite
  adding: ferc2_xbrl.sqlite (deflated 85%)
Compressing ferc60_dbf.sqlite
  adding: ferc60_dbf.sqlite (deflated 67%)
Compressing ferc60_xbrl.sqlite
  adding: ferc60_xbrl.sqlite (deflated 89%)
Compressing ferc6_dbf.sqlite
  adding: ferc6_dbf.sqlite (deflated 73%)
Compressing ferc6_xbrl.sqlite
  adding: ferc6_xbrl.sqlite (deflated 83%)
Compressing ferc714_xbrl.sqlite
  adding: ferc714_xbrl.sqlite (deflated 89%)
Compressing pudl.sqlite
  adding: pudl.sqlite (deflated 83%)

This should also probably qualify as a build failure, but the way the error codes are combined in the nightly build script means this doesn't happen:
function clean_up_outputs_for_distribution() {
    # Compress the SQLite DBs for easier distribution
    pushd "$PUDL_OUTPUT" && \
    for file in *.sqlite; do
        echo "Compressing $file" && \
        zip "$file.zip" "$file" && \
        rm "$file"
    done
    popd && \
    # Create a zip file of all the parquet outputs for distribution on Kaggle
    # Don't try to compress the already compressed Parquet files with Zip.
    pushd "$PUDL_OUTPUT/parquet" && \
    zip -0 "$PUDL_OUTPUT/pudl_parquet.zip" ./*.parquet && \
    # Move the individual parquet outputs to the output directory for direct access
    mv ./*.parquet "$PUDL_OUTPUT" && \
    popd && \
    # Remove any remaiining files and directories we don't want to distribute
    rm -rf "$PUDL_OUTPUT/parquet" && \
    rm -f "$PUDL_OUTPUT/metadata.yml"
}

It seems a little bit unlikely that we're actually running out space on the device though, since all of the other databases seem to have no trouble getting zipped.

Searching for background on this error message, the only posts I'm finding are related to actually running out of disk space. So even though all the nightly build outputs together are only ~25GB before they get compressed for distribution, with all the raw input data and interim outputs from Dagster, maybe it really is exceeding 80GB of space total. I'm inclined to try bumping it to 100GB just to see.

I'm going to hold off on closing this until I can verify that the builds worked and I can update the Kaggle dataset tomorrow.

@zaneselvans I think we've resolved this, can I close this issue?


Mixed data types for select options behaving wrong

Describe the feature
It's possible I'm just doing something wrong but I played around with it and couldn't figure it out.
When doing a select dropdown, we can provide an array of strings, or use objects to define each option in the dropdown, like so:
<FormKit type="select" name="Country" :options="countries" placeholder="Select Country" />

The countries variable is just an array of strings. So far so good. The placeholder gives us a typical placeholder.
Now I want to add a disabled option to act as a kind of separator between certain options, how do I do this?
countries = [
    "United States",
    "Canada",
    "Mexico",
// Want to insert a separator here
    "Afghanistan",
    "Aland Islands",
]

According to the docs, we can do alternate layouts only by using the default slot. https://formkit.com/inputs/select
However, I thought that I could just mix-n-match the different data forms, like this:
countries = [
    "United States",
    "Canada",
    "Mexico",
    { label: '───', value: '', attrs: {disabled: true}},
    "Afghanistan",
    "Aland Islands",
]

The thing is, this actually works, and it creates a disabled option after the first three countries as expected. The problem is, it kills the placeholder and instead the line I've added actually becomes the new placeholder!

You can see in this screenshot that the line really does appear in the correct spot and looks just like I want it to.

The question is, why does the placeholder get stripped out just because I added some other disabled option? And can I do what I'm trying to do here with a normal placeholder still intact?
I just want the box to say "Select Country" and then have my line separate the first three.
I don't want to use the default slot idea because then I have to figure out how to cram the entire countries list into the HTML template instead of just binding it simply with the array.

👋 @guyinpv — the "placeholder" is just a disabled option with a value of "", when you created your divider line the value was also "" so the select didn’t know which to pick and it just picked the last one — your placeholder. In this example I just changed the value to true — since its disabled it wont be selectable either way: https://formkit.link/8b9378534eb448c35802cfb1266316ee

Thanks, I had figured out the "selecting the last one" logic as I continued to play with it.
In your example you actually set the value to false, not true as mentioned in your comment.
By setting value to false the HTML actually became value="__mask_1". I don't know if that matters.
I kind of feel like, since the select box is choosing the "last" option with empty value as the placeholder, maybe FK should be putting its own placeholder as the last option by default? Or to say another way, is there some way to help force FK's placeholder to always win?

Yeah good question. FormKit is actually not selecting the empty ("") value — native inputs by default "select" the first item in a select — but not if that item is disabled, so the value of that list item is never actually selected. We could force FormKit to select a different value, but that would end up in the form values which wouldn't be intuative really.
Oh, and the __mask_1 thing — select lists only support string values natively so when a different type is provided (boolean in this case) we set the raw value in HTML to a mask value and re-map the value to the original type in javascript. So yes it is intentional, but you should never see a mask value in your actual form or input values, only in the HTML.

Thanks again for expanding on this. It all feels a bit random, lol.
Perhaps the only thing to do is update the documentation because it really tripped me up and I couldn't find out why anything was behaving the way it was. The docs should explain:

That we can mix-n-match the list definition array with plain text and objects for various needs.
That the placeholder functionality of FK (set in attributes) will be overwritten if we add our own disabled fields manually.
How the true/false/masking stuff works.

Thanks! I suppose this issue could be closed up unless there is something to do.

Agreed @guyinpv. That masking effect has messed me up more times than I can count in our current project.

Agreed @guyinpv. That masking effect has messed me up more times than I can count in our current project.

@tominal we haven’t gotten any other feedback about users having trouble with this so I'd love to know more about how you were getting tripped up.


License missing

Hi @jkroepke
Was looking to use your plugin but noticed there is no license. Can you please confirm how you planned to license this?

Thanks for the hint! Added in 1fbb34d

Awesome. Thank you!


Reply in PR comments

There are 2 buttons to Reply in PR comments. The one in the alert action doesn't do anything.
Should I remove it? @rnystrom

@jdisho that’s the reply button you added that quotes right? Maybe we wire it up in PR threads too so it works?
Sent with GitHawk

Yep, that's the one.
Okay than, I will make it work. :)
However we still keep the two Reply buttons, right?

Ya, the main reply button is required to simply reply to the thread. The ... menu is to quote. If we only had the ... reply it’d be pretty buried.
Sent with GitHawk

I will take care of this together with #1167 :)
Sent with GitHawk


Added canopy prognostic energy

Purpose
Prognostic energy for the canopy
To-do
Content
Review checklist
I have:

followed the codebase contribution guide: https://clima.github.io/ClimateMachine.jl/latest/Contributing/
followed the style guide: https://clima.github.io/ClimateMachine.jl/latest/DevDocs/CodeStyle/
followed the documentation policy: https://github.com/CliMA/policies/wiki/Documentation-Policy
checked that this PR does not duplicate an open PR.

In the Content, I have included

relevant unit tests, and integration tests,
appropriate docstrings on all functions, structs, and modules, and included relevant documentation.

[] I have read and checked the items on the review checklist.

I've added a few extra tests with Latent heat (looks good) and fixing some mismatches with the energy budget.

bors r+


docs for customer compilers + prevent (or cleanly address) vueify escaping angle brackets

So thank you so much @yyx990803 for your help figuring out how to do lang="ejs"!
I've got it working almost perfectly now, however two things:

The EJS compiler requires a filepath for the file being compiled if include is used. It took me a while to figure out how to get vueify to tell me this, but after digging through the code I saw that indeed the custom compiler callback is passed the filepath as the fourth argument, but this wasn't documented in the README, so maybe it could be to save other folks some headaches?
Vueify (or more accurately, parse5) escapes angle-brackets in the template. However, it's super common for the delimiters <% and %> or <? ?> to be used in template languages, so I have to do a hackish search & replace to fix that:

vueify.compiler.applyConfig({
  customCompilers: {
    // WARNING: EJS in .vue files is EJS 2.0!
    //          In .ejs files it's 1.0 until we fork ejsify and update it
    ejs: function (content, cb, compiler, filepath) {
      content = content.replace(/<%/g, '<%')
      content = content.replace(/%>/g, '%>') // hack
      cb(null, ejs.render(content, {filename: filepath}))
    }
  }
})

It'd be nice if there was a cleaner way to address that (for example, if vueify added a method to register common delimiters or custom tags).

Fixed in 8.3.7.

Awesome! Thanks so much for the quick fix @yyx990803! I can confirm this works. :)
In case anyone finds it useful, here's how we're supporting EJS via both ejsify (as a simple function, not the package) and .vue:
var through = require('through2')

// per: https://github.com/vuejs/vue-loader/issues/197#issuecomment-205617193
vueify.compiler.applyConfig({
  customCompilers: {
    ejs: function (content, cb, compiler, filepath) {
      cb(null, loadEJS(filepath, content)())
    }
  }
})
// TODO: see comment in simple/js/utils.js
function loadEJS (path, str) {
  return require('ejs').compile(str, {
    filename: path,
    compileDebug: process.env.NODE_ENV === 'development',
    client: true // haven't figured out how to do ejsify without this
  })
}
// with inspiration from the ejsify package
function ejsify (file) {
  return !S(file).endsWith('.ejs')
  ? through()
  : through(function (buf, encoding, cb) {
    cb(null, `module.exports = (${loadEJS(file, buf.toString('utf8'))})`)
  })
}

It took me a surprisingly long time to figure out how to write that ejsify function as I thought you could just pass a string to the callback with the resulting transformation, but I couldn't figure out how to do that. Instead, going off of the ejsify package, it passes in an exported function as a string, and then you have to use it like so:
require('path/to/file.ejs')()

Note the extra () at the end. Kinda ugly/weird but whatev's, didn't have time to dive deeper than that.

 The things you can do on a fresh head. :P
Just inserting a () into the module.exports string works:
cb(null, `module.exports = (${loadEJS(file, buf.toString('utf8'))})()`)

Now you can just require('path/to/file.ejs'). :smile:


Inaccurate of eosc documentation

It isn't clear where take information about activate public key in creation account process
./eosc account tester -> ./eosc get account tester, for eos also
Probably one step was skipped in insufficient funds case

status_code == 200: Error
: 13 N5boost16exception_detail10clone_implINS0_19error_info_injectorISt12out_of_rangeEEEE: unknown key
unknown key:
    {"authorizer_account":"eos","code_account":"eos","type":"transfer","what":"unknown key"}
    thread-0  chain_controller.cpp:776 lookup_minimum_permission

unknown option setcode for eosc

I hope it's not entirely useless information :)

This was resolved elsewhere. See latest version of this file.


Grid List demo not displaying correctly in Angular docs and Plunker

Bug, feature request, or proposal:
Bug
What is the expected behavior?
A background color should be applied to the items in the inline grid list demo and the related Plunker
What is the current behavior?
No background color is applied to the items in the inline grid list demo or Plunker example
What are the steps to reproduce?

Navigate to https://material.angular.io/components/component/grid-list
The inline example for Basic grid-list doesn't show the background color on the divs in the basic grid layout.
Opening the Plunker example doesn't have any CSS in the example resulting in no background color being applied to the div's.

What is the use-case or motivation for changing an existing behavior?
An example of the feature that displays correctly.
Which versions of Angular, Material, OS, browsers are affected?
Browser: Chrome 57.0.2987.133
Is there anything else we should know?
Nope.

This should be fixed now


Remove busy wait

Remove the busy wait from AtomicSafeInitializer.get().
Also ensure waiting threads do not wait indefinitely after initialize() throws an exception, instead throwing the same exception, re-wrapped, for each requester.
Brought the unit tests up to 100% coverage on AtomicSafeInitializer.  Eliminated race condition on verifying at least one thread waiting for initialize() to complete in another thread.

Placeholder ticket is https://issues.apache.org/jira/browse/LANG-1086

Your fix has been applied in svn revision 1661762. Please tell me your full name if you want it to be included in changes.xml.

Thank you.  My full name is Arthur Naseef.  If you have the opportunity,
please pass on my thanks to James Carman for his help on this as well.
Art
On Mon, Feb 23, 2015 at 1:17 PM, Benedikt Ritter<EMAIL_ADDRESS>wrote:

Your fix has been applied in svn revision 1661762. Please tell me your
full name if you want it to be included in changes.xml.
—
Reply to this email directly or view it on GitHub
https://github.com/apache/commons-lang/pull/46#issuecomment-75622835.

We're currently discussing whether it was correct to include this fix and it looks like we will revert it: http://markmail.org/message/ecusyua74pi66cej feel free to join the discussion.


Does Bakeneko65 support RGB?

RGB strip at least
Thanks in advance

Sorry for delayed response. Unfortunately, it does not at the moment. But I'll consider it in a future version


added CDS-79356 to RN

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66030e90c736c30dde937b28--harness-developer.netlify.app


Make Taxon pages indexable by govuk-index

For: https://trello.com/c/M5sF6vyc/93-2-renamed-worldwide-taxonomy-pages-not-showing-correctly-in-search
Why
Following on the work done previously to rename a certain subset of taxons ("world location") from <location name> and the UK to UK help and services in <location name>, we discovered that after republishing them they do not show up in search results https://www.gov.uk/api/search.json?filter_link=/world/spain. That's because taxons have not been migrated to be indexed using the govuk-index in rummager.
We're now publishing taxons from content-tagger directly to publishing-api, which is not automatically picked up by rummager and indexed accordingly.
What
Finishes the migration of taxon pages by adding the last remaining bit: making them indexable in the govuk-index.
There are docs in rummager for doing this type of migration: https://github.com/alphagov/rummager/blob/master/doc/new-indexing-process.md
We also have these previous migration PRs as a starting point:
https://github.com/alphagov/rummager/pull/1114
https://github.com/alphagov/rummager/pull/1014
https://github.com/alphagov/rummager/pull/1077
However, these three PRs were slightly different because they had extra fields that meant rummager had to be adjusted to include these special fields when returning results.
For taxons, we're settling for just the basic fields returned for an edition. In order to see what representation publishing-api has of taxons, as well as for a type of edition (aaib_report) we used a rake task to give us a preview of the document structure.
Rake task is here: https://github.com/alphagov/publishing-api/blob/master/lib/tasks/queue.rake#L51
Previews for

taxon: https://deploy.integration.publishing.service.gov.uk/job/run-rake-task/263/consoleFull
aaib_report: https://deploy.integration.publishing.service.gov.uk/job/run-rake-task/266/console
external_content: https://deploy.integration.publishing.service.gov.uk/job/run-rake-task/265/console

I've discussed with the Taxonomy team, who are not intending to add indexing for taxons in the near future, so the search was never expected to offer these world taxons as a result, which was the original purpose of this PR. I'm closing it for now and letting the requester in the Zendesk ticket know this is not a feature that's planned.

We have a solution (and the taxonomy team is okay with this).
@MatMoore explained that we can selectively index the taxons by adding a whitelist like the one that exists for special_routes.
From this list I gather that it should look like:
taxon:
  - /world/afghanistan
  - /world/albania
  - /world/algeria
  - /world/angola
  - /world/anguilla
  - /world/argentina
  - /world/armenia
  - /world/australia
  - /world/austria
  - /world/azerbaijan
  - /world/bahrain
  - /world/bangladesh
  - /world/barbados
  - /world/belarus
  - /world/belgium
  - /world/belize
  - /world/bolivia
  - /world/bosnia-and-herzegovina
  - /world/botswana
  - /world/brazil
  - /world/british-antarctic-territory
  - /world/british-virgin-islands
  - /world/brunei
  - /world/bulgaria
  - /world/burma
  - /world/cambodia
  - /world/cameroon
  - /world/canada
  - /world/cayman-islands
  - /world/chile
  - /world/china
  - /world/colombia
  - /world/costa-rica
  - /world/croatia
  - /world/cuba
  - /world/cyprus
  - /world/czech-republic
  - /world/democratic-republic-of-the-congo
  - /world/denmark
  - /world/dominican-republic
  - /world/ecuador
  - /world/egypt
  - /world/eritrea
  - /world/estonia
  - /world/ethiopia
  - /world/fiji
  - /world/finland
  - /world/france
  - /world/gambia
  - /world/georgia
  - /world/germany
  - /world/ghana
  - /world/greece
  - /world/guatemala
  - /world/guyana
  - /world/holy-see
  - /world/honduras
  - /world/hong-kong
  - /world/hungary
  - /world/iceland
  - /world/india
  - /world/indonesia
  - /world/iran
  - /world/iraq
  - /world/ireland
  - /world/israel
  - /world/italy
  - /world/jamaica
  - /world/japan
  - /world/jordan
  - /world/kazakhstan
  - /world/kenya
  - /world/kosovo
  - /world/kuwait
  - /world/laos
  - /world/latvia
  - /world/lebanon
  - /world/libya
  - /world/lithuania
  - /world/luxembourg
  - /world/macedonia
  - /world/madagascar
  - /world/malawi
  - /world/malaysia
  - /world/maldives
  - /world/mali
  - /world/malta
  - /world/mauritius
  - /world/mexico
  - /world/moldova
  - /world/mongolia
  - /world/montenegro
  - /world/montserrat
  - /world/morocco
  - /world/mozambique
  - /world/namibia
  - /world/nepal
  - /world/netherlands
  - /world/new-zealand
  - /world/nigeria
  - /world/north-korea
  - /world/norway
  - /world/oman
  - /world/pakistan
  - /world/panama
  - /world/papua-new-guinea
  - /world/peru
  - /world/philippines
  - /world/poland
  - /world/portugal
  - /world/qatar
  - /world/romania
  - /world/russia
  - /world/rwanda
  - /world/saudi-arabia
  - /world/senegal
  - /world/serbia
  - /world/seychelles
  - /world/sierra-leone
  - /world/singapore
  - /world/slovakia
  - /world/slovenia
  - /world/solomon-islands
  - /world/somalia
  - /world/south-africa
  - /world/south-korea
  - /world/south-sudan
  - /world/spain
  - /world/sri-lanka
  - /world/sudan
  - /world/sweden
  - /world/switzerland
  - /world/syria
  - /world/taiwan
  - /world/tajikistan
  - /world/tanzania
  - /world/thailand
  - /world/timor-leste
  - /world/trinidad-and-tobago
  - /world/tunisia
  - /world/turkey
  - /world/turkmenistan
  - /world/turks-and-caicos-islands
  - /world/uganda
  - /world/ukraine
  - /world/united-arab-emirates
  - /world/uruguay
  - /world/usa
  - /world/uzbekistan
  - /world/venezuela
  - /world/vietnam
  - /world/yemen
  - /world/zambia
  - /world/zimbabwe
  - /world/andorra
  - /world/antigua-and-barbuda
  - /world/bahamas
  - /world/benin
  - /world/bhutan
  - /world/burkina-faso
  - /world/cape-verde
  - /world/comoros
  - /world/congo
  - /world/cote-d-ivoire
  - /world/djibouti
  - /world/dominica
  - /world/equatorial-guinea
  - /world/grenada
  - /world/guinea-bissau
  - /world/haiti
  - /world/kiribati
  - /world/lesotho
  - /world/liberia
  - /world/liechtenstein
  - /world/macao
  - /world/marshall-islands
  - /world/micronesia
  - /world/nauru
  - /world/nicaragua
  - /world/niger
  - /world/the-occupied-palestinian-territories
  - /world/palau
  - /world/paraguay
  - /world/samoa
  - /world/sao-tome-and-principe
  - /world/st-kitts-and-nevis
  - /world/st-vincent-and-the-grenadines
  - /world/suriname
  - /world/swaziland
  - /world/togo
  - /world/tuvalu
  - /world/vanuatu
  - /world/bermuda
  - /world/burundi
  - /world/el-salvador
  - /world/falkland-islands
  - /world/guinea
  - /world/st-helena-ascension-and-tristan-da-cunha
  - /world/st-lucia
  - /world/kyrgyzstan
  - /world/pitcairn-island
  - /world/chad
  - /world/mauritania
  - /world/american-samoa
  - /world/aruba
  - /world/bonaire-st-eustatius-saba
  - /world/central-african-republic
  - /world/curacao
  - /world/french-guiana
  - /world/french-polynesia
  - /world/gabon
  - /world/gibraltar
  - /world/guadeloupe
  - /world/martinique
  - /world/mayotte
  - /world/monaco
  - /world/new-caledonia
  - /world/reunion
  - /world/san-marino
  - /world/south-georgia-and-south-sandwich-islands
  - /world/st-maarten
  - /world/st-pierre-and-miquelon
  - /world/tonga
  - /world/wallis-and-futuna
  - /world/western-sahara
  - /world/st-martin

We have a solution (and the taxonomy team is okay with this).
@MatMoore explained that we can selectively index the taxons by adding a whitelist like the one that exists for special_routes.

Interesting, this sounds ok to me. The other option I was considering suggesting was somehow getting Content Tagger to update the titles of the search items (for the non-existent world location pages) in Rummager when it publishes the taxons, but this seems a bit neater than that.
I'm also guessing that the content sent by the Publishing API for the taxons will somehow replace or supersede the old content in Rummager for the now non-existent world location pages?

Yup I think @tijmenb's change will work, if the intent is to completely exclude regular topic pages from search. This should be revisited at some point because topic pages are important and should be findable.
If we get to the point where we're happy indexing all live taxons we could revert back to @elenatanasoiu's commit and just add in some code to filter anything with document_type = taxon and phase != live.

(Note that I didn't actually make a change to this PR, just the comment)

@tijmenb @cbaines Is this still something Taxonomy wants?

@tijmenb @cbaines Is this still something Taxonomy wants?

The approach that Tijmen suggested won't impact the Taxonomy teams work. In terms of "wants" from a product perspective, I don't think the Worldwide pages are within the scope of the Taxonomy teams work.


Hyperion blue color is green and green clor is blue

Hi,
I'm a big fan off the raspberry pi with hyperion.
But i have a little problem with it. When i select or test my color i see that the blue color is green and the green color is blue. The red color is good.
Is it possible to calibrate the colors or something like that?
I'm using a raspbery 1 model b
Thanks a lot!

Hi,
On the top of your Hyperion config (hyperion.config.json) you can re-arrange the colors, it's in this section and called colorOrder:
"device" :
	{
		"name"       : "yourdevice",
		"type"       : "APA120",
		"output"     : "/dev/spidev0.0",
		"rate"       : 1000000,
		"colorOrder" : "bgr"
	},

Also available in the HyperCon tool and named the same there, depending on your device type the default order varies (BGR for APA102 as in example).

I had the same issue. Setting the type RBG in hyperon solved it for me (default is RGB)

That works for me, thanks!

@jelmert24
Glad that this worked for you.
Could you please close this issue yourself? We can´t.
thank you

Awesome, the color order worked for me. later to realize, it can be selected in the hypercon tool as well.


Installation instructions

Hi.
I probably do not understand something from the instructions... So if it is easy for more clarification.

More detailed installation instructions
Add .env.example to the repository
Which versions of Laravel is it compatible with

Thnx

PHP 7.4 / Laravel 7.2 or higher.
This repo contains just the Eloquent models, how to use these can be found in the repo.
This package does not contain any UI.


Add [FlakyTheory]

Is your feature request related to a problem? Please describe.
Right now only [FlakyFact] is supported.  Sometimes my [Theory] is flaky too!
Describe the solution you'd like
I'd like support for [FlakyTheory] as an accompaniment to the existing [FlakyFact]
Describe alternatives you've considered
Having each data part to a theory, as individual [FlakyFacts] isn't great.

I'm dumb, opened this on the wrong repo


fix bug in send elements default implementation

Proposed changes:

fixed parenthesis in the wrong place
fixes https://rasa-hq.slack.com/archives/C36SS4N8M/p1566817084007700

Status (please check what you already did):

[x] made PR ready for code review
[ ] added some tests for the functionality
[ ] updated the documentation
[ ] updated the changelog
[ ] reformat files using black (please check Readme for instructions)

@akelad ok properly tested now, sorry about that 😅

@erohmensing you can merge!


Music stops during resize

Can we make it still play during game window resize?

This issue linked with original Raylib library. Is doesent support drawing during resize or move window (Event processing (PollEvents) stalls whenever the window is resized). It would be possible to solve this problem, but current version of Raylib_CsLo does not support risize callback. Issue

I wonder if we could start playing music in a separate thread (or even dispatcher) then.


changes - ruby - raise gem version

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


Extends with new styles

Hi !
First of all thanks for you work, it's a very nice and useful open source project.
I wanted to know if you have planned to extends the library with some new hairs, hats or shirts style ?
I know i could do it myself but it won't be as good as your work.

Hi, I don't have a plan to extend the style sorry :(
The original design file can be found here https://www.figma.com/community/file/829741575478342595 , might be helpful if you wanna extend yourself


[JENKINS-51574]  - POM Input support PoC

https://issues.jenkins-ci.org/browse/JENKINS-51574
@reviewbybees @raul-arabaolaza

Also CC @kuisathaverat

I am going to start some work based on this code, mostly related to being sure all dependencies are present in the war when you use a pom file

Superseded by #35


update create swarm and add nodes to use the auto-generated join command

Tutorial should use the command output by docker swarm init because it is the easiest way to join nodes.

I'm kinda missing a reminder where the --ca-cert value came from, but otherwise :)

@sfsmithcha needs rebase :)

@aaronlehmann , @SvenDowideit thanks for the great feedback PTAL

@aaronlehmann , @thaJeztah , thanks for all your help with this. can you let me know what remains to get this merged? thanks.

LGTM

LGTM, thanks again, @sfsmithcha !