Implement current_time Function

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
As we add more full featured date/time support for DataFusion users need to be able to use the current time to calculate things like "all data in the last 5 hours"
Describe the solution you'd like
Support the current_time postgres function https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
Note I think we should avoid the current_time(precision) variant initially -- we can implement it as a follow on PR.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
This is a feature request we got from an early (internal) user of InfluxDB IOx
I believe this is a good first issue as you can follow the existing implementation of  now()

[ ] Physical support: https://github.com/apache/arrow-datafusion/blob/f1322592046a7ea895820286a2ad16d934540d92/datafusion/physical-expr/src/functions.rs#L424-L429) and use the same query_execution_start_time field
[ ] Tests: https://github.com/apache/arrow-datafusion/blob/beeb631d0bb979e9b6826f6cd3eae2d0a24f471e/datafusion/core/tests/sql/timestamp.rs#L417

It would be a good exercise to add a new build in scalar function, physical planing support, and then tests
Note this the same ticket exists for the current_date function https://github.com/apache/arrow-datafusion/issues/3981

This sounds good start to me, could you please assign it to me or some extra advises?

@alamb postgresql's current_time returns TIMETZ
willy=# select pg_typeof(current_time);
      pg_typeof
---------------------
 time with time zone
(1 row)

what should we return here?

@waitingkuo  I was imagining it would return a https://docs.rs/arrow/latest/arrow/array/type.Time64NanosecondArray.html
But I have not thought as deeply as you about the timezone implications, so if you have a different suggestion I would love to hear it.

This sounds good start to me, could you please assign it to me or some extra advises?

Hi @naosense  -- thanks and done!

This sounds good start to me, could you please assign it to me or some extra advises?

Hi @naosense please follow the #4022 PR

@alamb i have no idea for timetz in arrow-rs for now as Time has not timezone (e.g. DataType::Time64(TimeUnit::Nanosecond) while Timestamp has (e.g. DataType::Timestamp(TimeUnit::Nanosecond, Some("UTC".to_string()))
i think we could either

follow postgresql's function signature that means we could implement LOCAL_TIME instead
keep it simple, return TIME directly for now and comment it

in the long run, we might consider make these function names explicitly like what was discussed in
https://github.com/apache/arrow-datafusion/issues/686#issuecomment-885171173

This sounds good start to me, could you please assign it to me or some extra advises?

Hi @naosense please follow the #4022 PR

That's nice, thanks!


added support for JS Object

Description
I added support to parse JS objects to an extension that could only format JSON objects.
It was a cool opportunity to improve the extension and make it more useful for people who work with JavaScript objects.
I looked at the code and made the necessary changes to handle different data types.
I'm happy I could contribute to a project that I find useful and that I think others will too!
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

I have trouble understanding what's possible now that wasn't possible before. From what I understand, this PR adds support for JS objects so things like comments, dates, regex, function should be possible, right?
So, I tested it with the string below but got an Invalid Input error.
{name:"John Doe",age:30,city:"New York",email:"johndoe@example.com",phone:"+1234567890",address:{street:"123 Main St",suite:"Apt 4B",city:"New York",state:"NY",zip:"10001"},hobbies:["reading","hiking","cooking"],occupation:"Software Developer",getFullAddress(){return`${this.address.street}, ${this.address.suite}, ${this.address.city}, ${this.address.state} ${this.address.zip}`;},birthdate:new Date(1993,4,15),phoneRegex:/^\+\d{11}$/}

Am I misunderstanding something?

It seems that you may have misunderstood the purpose of this tool. Allow me to clarify - the primary goal of this tool is indeed to prettify JSON. However, JSON does not support types like Dates, regex, functions, and so on.
Here is an example of a valid JS Object
{
	name: 'John Doe',
	age: 30,
	city: 'New York',
	email<EMAIL_ADDRESS>	phone: '+1234567890',
	address: { street: '123 Main St', suite: 'Apt 4B', city: 'New York', state: 'NY', zip: '10001' },
	hobbies: ['reading', 'hiking', 'cooking'],
	occupation: 'Software Developer'
}

That said, this feature can come in handy when you have a JavaScript object in a format like the one above. This format is not JSON, mainly because of the single quotes and the keys not being wrapped in double quotes. It's a common formatting you may find in your code editor.
The feature that this PR adds enables you to take an object in this format and format it into valid JSON. This can be useful when you need to copy an object from your code editor and paste it into an HTTP client or when you receive a response from an API but forget to stringify it.
So, the tool isn't meant to support Dates, regex, functions, etc. But it does make it easier to work with JavaScript objects that are not in valid JSON format.

@thomaslombart

@thomaslombart Done ✓


Enable MemberImportVisibility check on all targets

Enable MemberImportVisibility check on all targets. Use a standard string header and footer to bracket the new block for ease of updating in the future with scripts.

@rnro This here actually showed some missing imports


error in committees/CommitteeAgendaSearch: failed to get meetings for committee 27

This issue was automatically created, please do not modify the title or remove any labels
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

הבעיה היא גם בAPI וגם בscraping שלא דרך הApi (יש דברים שעוד לא נתמכים בו)
שאני מנסה מהמחשב שלי עובד curl למשל ל:
curl
http://online.knesset.gov.il/WsinternetSps/KnessetDataService/LawsData.svc
אבל אותה פקודה שאני מריץ אותך משרת באמזון
למשל כזה שיושב ב: <IP_ADDRESS>
פשוט נתקעת ולא חוזרת
On Fri, Aug 19, 2016 at 4:37 AM Ori Hoch<EMAIL_ADDRESS>wrote:

Encountered the error again
Unexpected exception received while trying to get meetings of committee
27:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hasadna/knesset-data/issues/105#issuecomment-240905387,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXlcFj3D3mJvl8p5Tu9mr7YLA1XnCA8ks5qhQjzgaJpZM4JaKPp
.

--
Alon Nisser
twitter:@alonisser https://twitter.com/alonisser
Facebook https://www.facebook.com/alonisser
Tech Blog: https://medium.com/@alonisser/
*Personal Blog:*degeladom.wordpress.com
Tel:972-54-6734469

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:

Encountered the error again
Unexpected exception received while trying to get meetings of committee 27:


fix(alerts) : Alert if there was no successful eth-watcher iterations for 5 minutes

We have this alert:
      no_eth_watch_iterations:
        promql: max(rate(server_eth_watch_eth_poll[30s]))
        compare: "=="
        thresholds:
          critical: 0
        duration: 5m
        annotations:
          description: "No ETH watch iterations for 5 minutes"
          summary: "No ETH watch iterations for 5 minutes"
          runbook_url: "https://www.notion.so/matterlabs/On-Call-1d597d29c9b64c08919bf53c952cd03e?pvs=4#78da3253ab3e41aa8175e72caf456c86"

But we reported this server_eth_watch_eth_poll metric on every iteration - even if it wasn't successful. This PR changes the logic so that it's only reported when successful - meaning that we will be alerted if there was no successful iterations for five minutes.
We may want to increase the threshold to something like 10 minutes to avoid being notified at transient L1 provider issues.

In this particular case, we actually polling ethereum, nothing has stuck and service is working.

I think there is much more value in knowing whether there were successful operations, not some operations. What's the usecase for the metric that currently exist? IMO we should replace it.


config file not generating in data directory

I am playing on fabric 1.21 and installed enchantment disable tag. I have started minecraft and entered the world several times, and then looked for a config file to edit inside my minecraft folder. No such file is generated. I have tried putting the .jar in both the mods folder and the datapacks folder of my world. I would greatly appreciate any help.

@MerchantPug

This mod does not use configs at all, it instead uses vanilla's datapack system, which will handle syncing and the sort for you. This also means that the mod can function serverside, without the client having anything other than the mod optionally.
To quote @UltrusBot from issue #1

This mod uses the vanilla tag system, so following the vanilla wiki on how to create a datapack which is here can be helpful.
The tag this mod adds functionality to is specifically would be data/enchantmentdisabletag/tags/enchantment/disabled.json

You would then place the datapack within your world's datapack folder, or if you are using a global datapack loading mod (recommended if you're making a modpack), you'd place it wherever that stores its datapacks.

I apologize, but I'm having trouble understanding how to add the tag to enchantments to disable them. After I have placed the datapack in [my world folder]/datapacks, what do I do? Is there a command to use it? Thanks for the help.

Hey, same issue here, can we get an example/template on how to use this? i just want to remove mending and unbreaking, how can i do that?

I spoke to the creator on Discord. I suggest you download the example datapack they have there. It didn't work for me, but my game was probably acting up. Put that in /datapacks/, then edit the disabled.json file. Reload the world and it should work (also make sure to enable the datapack)

I'll be doing two things:
Linking an example datapack on the mod page, and also explaining how you'd make the example pack.

Hello! I've written up a write-up that should explain how EDT's tag works and how to make one from zero knowledge.
https://github.com/GreenhouseTeam/enchantment-disable-tag/wiki


Rewrite for ST4

The Vue syntax is an extension of the core HTML syntax. Currently, this is implemented by vendoring the core HTML syntax and extending it using macros. Sublime Text 4 offers a new syntax extension feature that should remove the need to vendor the core syntax and may even remove the need for macros. In addition, it would stay up to date as the core syntax is improved.
Is there interest in this? I could probably write up a PR, but I figured I'd ask first before investing the time.

Hey @Thom1729
Thank you for proposing this. This sounds really exciting and I don't see any downside if we do it right. (@yyx990803 feel free to chime in if there are any potential issues with this)
I'd be happy to test and validate that it works well with all the standard cases. I have a few notes though:

We would need to preserve backward compatibility for ST3, I'm not sure how this would work.
Are there any examples of 3rd-party extensions already adopting this new syntax that you're aware of? (just so I understand it better)
Would it be possible to write a few simple syntax tests?

Syntax extensions are ST4-only and do not work in ST3. We would preserve backward compatibility by specifying in the channel entry that the new tags require ST4. Actually, the channel entry is already set up to limit the .sublime-syntax releases to build 3153 and newer.
I don't know of any third-party packages extending syntaxes this way, probably because ST4 is brand new. However, several of the core syntaxes already do this (including the core JSX, TypeScript, and TSX syntaxes) and others are being converted to do so (see https://github.com/sublimehq/Packages/pull/2789).
Syntax tests are definitely possible.

Hey @Thom1729
I apologize for the extended delay in replying. I was spending a bit of time trying to understand the new syntax option, and also refreshing my understanding of the syntax system. I think you can write the upgrades, it would be great to have them merged in!
I'm trying to understand how we would specify the sublime version in the repository JSON. We currently have it listed as:
			"releases": [
				{
					"sublime_text": "<3153",
					"tags": "oldsyntax-"
				},
				{
					"sublime_text": ">=3153",
					"tags": "newsyntax-"
				}
			]

How would the sublime_text conditions look for versions between 3153 and 4000? I couldn't find a specification for the operations supported by that field.

I'm actually not sure about that. The easiest approach would be dropping ST2 support.

I don't think it's feasible to drop ST2 support.
I spent some time digging through the Package Control source code. I found this: https://github.com/wbond/package_control/blob/8b947d227bfee2b514283e650c3f88c954ae1026/package_control/providers/release_selector.py#L62
It appears that there's a "Range" selector where we'll be able to set "sublime_text": "3153 - 4000" but this isn't something I have seen documented anywhere. Let me see if there's any existing package which uses this type of selector, and test it on ST2, ST3, ST4 and confirm this...

https://github.com/wbond/package_control_channel/blob/f398516826bc261bce41d37da3a9771ff9765926/repository/l.json#L521-L537 for example

#209

I think we can close this now.

Closing now. Thanks! But we are still waiting on package control accepting my PR to update to the new version :)
https://github.com/wbond/package_control_channel/pull/8362

Right. I've had st4 branch checked out manually so didn't notice.

@skyronic just a heads up that the st4-v4.0.0 tag is incorrectly tagging a commit from master branch rather than from the st4 branch.

@rchl Thank you so much for noticing! I've created a new tag!


Terminate app on release mode when subscribing channel

Dear pusher team,
release apk terminated when make subscribe pusher but working in debug mode
and this is an error in logcat from real device
2022-07-21 11:47:25.066 22028-22129/? E/AndroidRuntime: FATAL EXCEPTION: pusher-java-client eventQueue     Process: com.coappso.gym_system, PID: ***28     java.lang.NullPointerException: Parameter specified as non-null is null: method kotlin.jvm.internal.i.d, parameter e         at v4.c.a(Unknown Source:7)         at y4.d.w(Unknown Source:12)         at y4.d.i(Unknown Source:11)         at y4.b.h(Unknown Source:30)         at b5.b.w(Unknown Source:18)         at b5.b.q(Unknown Source:0)         at b5.b$f.run(Unknown Source:26)         at d5.b$a.run(Unknown Source:7)         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)         at java.lang.Thread.run(Thread.java:923)

FATAL EXCEPTION: pusher-java-client eventQueue
java.lang.NullPointerException: Parameter specified as non-null is null

Does anyone have a solution ???

Hi, can you paste your Pusher code here? Including your initialisation, connection and subscribe method calls

this Gradle version solves my problem
`dependencies {
classpath 'com.android.tools.build:gradle:4.1.0'
}`

the error happens with gradle:7.1.2

gradle:7.1.3
#Fri Jun 23 08:50:38 CEST 2017
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-7.4-all.zip

I'm having the same issue event with v2.0.1 :/ Any ideas?

Downgrade gradle version to 4.1.0

Unfortunately, this is not appropriate solution for me, as it clashes with other packages compatibility...

@KristupasKuras Same here, Pusher team we really need a better solution then this!!!

It worked like this for me:
android/gradle/wrapper/gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-7.1-all.zip
android/build.gradle
classpath 'com.android.tools.build:gradle:4.1.0'

Krispy145's comment https://github.com/pusher/pusher-channels-flutter/issues/53#issuecomment-1237245577 on setting -keep class com.pusher.client.** { *; } in proguard-rules.pro nudged me in the right direction. I'm convinced the issue is minifying (with R8 for example) our library is causing an issue likely related to https://github.com/pusher/pusher-websocket-java/issues/333.
Its strange, however, that setting android gradle plugin to 4.1.0 works around this. I think its affecting the minifying so it inadvertently works. Adding -keep class com.pusher.client.** { *; } also doesnt seem to fix it for me, instead it changes the error message to
FATAL EXCEPTION: pusher-java-client eventQueue
Process: com.awesomeproject2, PID: 8625
java.lang.UnsupportedOperationException: k
at a4.h.f(Unknown Source:10)
at com.pusher.client.channel.PusherEvent.fromJson(Unknown Source:83)
This might be a red herring though, so I'm still looking at this.

@Akellacom @KristupasKuras @mohamedsalah414 could you try adding the proguard setting file like Krispy145 suggested? I'm hesitant to close this issue since 3 of you reported it, but I haven't been able to reproduce this even though I'm sure I'm running a release build and subscribing to a private channel. I'm also using Flutter 3.3 with android gradle 7.1.2.

I'm going to close this due to the lack of responses. If this was caused by minifying, then our new 2.4.4 java websocket library  has narrower proguard keep rules to prevent this.

This resolved my issue

proguard-rules.pro


3.0 - Final Phase, stage continued #20

Improve checking of Entity's classPath in \Nova\Database\Engine\Base
Small but important change! Please merge it directly!

@LuckyCyborg Please update the phpdoc too, Base: 162 and 163 (line nr).

@tomvlk Thanks, I adjusted also those docs.
BTW, you like our BaseModel ? :smirk:

@LuckyCyborg Didn't saw it yet. Idea is good tho!

It is in \App\Core\BaseModel
And it is more advanced than the default one. :smirk:
BTW, if you like to have an insertBatch, how about to have also an updateBatch  in your Engines? :smile:
You are willing to write an updateBatch fast? :smirk:

@LuckyCyborg Let me first open pull for more tests.

@tomvlk Okay, but I hope that you do not touch in you Tests our BaseModel, because its API is not yet well defined.
In theory, it is for offering an API compatible with our in-house Components, and my colleagues are not decided yet completely what they need to sports this BaseModel as API...
In other hand, I hope you will love something like:

$data = $this->model
    ->where('color', 'black')
    ->limit(15, 0)
    ->fetchAll();

@LuckyCyborg But if you are not sure about the api, maybe a good idea for implementation in a later version? Or as a seperate component?
Tests doesn't do anything with the basemodel.

@tomvlk It is about days, as BaseModel's API decisions, do not worry, I have plenty of time... :smirk:
In other hand, I'm almost successful in my deadline, and they can start to build things on top of Nova Framework, on January. In the mean time, I have time to adjust the BaseModel about their needs.
Yet, for Nova, it is a shiny and very useful add-on, yet, an add-on.
Then, we will guarantee us that it will work right at the End of January, when Dave want Release, but it will work right on as we need...

@LuckyCyborg Then it's okay :dancers: .

@tomvlk Yep. :smile:

@LuckyCyborg I'm not going to implement the batch update today, I will look into it tomorrow (evening) (if it isn't already done by then).

Btw, Some of your commits are in my pull request too, thats because it was needed, and the 3.0-beta was broken before that.

@tomvlk In other hand, they asked for an updateBatch in BaseModel, then I need a similar method in Database Engines.
That's why I asked you. Like you seen, we respected you Design, even if we introduced major changes in Engines...

@tomvlk You talk about fixing Tests?

@LuckyCyborg Ye, the update batch is a good one, and I like it too. Going to implement that, but not today.
The 2 first commits in this pull request are in mine too: https://github.com/simple-mvc-framework/framework/pull/329.

@tomvlk How that?

@LuckyCyborg Because it wasn't working, the 3.0-beta (before those 2 commits) was broken, and you did a fix here :laughing: .
And I applied the patch file from github, thats why it's showing your name, pushed with me :laughing:
But it's no problem when merging!

@tomvlk Okay, then! :smirk:

@tomvlk BTW, the Url::templatePath utility is questionable today... :smirk:
Also, now templates can be customized per Controller.
AND, for a correct work of Routing Files Serving, there is need to use specific style paths, who are different from the real filesystem...
Then, I sugest you to not include it in tests.

@LuckyCyborg There are still some improvements for tests, and when it's going to be deleted just delete it from tests too. Please be gentle for the other tests.

@tomvlk Okay. :smirk:

@tomvlk There are the specifications wanted by my colleagues for future Engine's updateBatch
/**
     * Updates multiple records in the database at once.
     *
     * $data = array(
     *     array(
     *         'title'  => 'My title',
     *         'body'   => 'body 1'
     *     ),
     *     array(
     *         'title'  => 'Another Title',
     *         'body'   => 'body 2'
     *     )
     * );
     *
     * The $where_key should be the name of the column to match the record on.
     * If $where_key == 'title', then each record would be matched on that
     * 'title' value of the array. This does mean that the array key needs
     * to be provided with each row's data.
     *
     * @param  string $table The Table name.
     * @param  array $data An associate array of row data to update.
     * @param  string $where The column name to match on.
     * @return bool
     */

$result = $this->db->updateBatch($this->table(), $data, $where);

@LuckyCyborg Thats exactly how I was thinking too ;)

@tomvlk Okay, then. Waiting, I implemented already our BaseModel part, with shiny before/after Events.
BTW, you know that our BaseModel is Event driven, and it have its own Events Management? Well, a much simple one, but exists as standalone. :smile:


[stable/rabbitmq] Add release to pod selector

What this PR does / why we need it:
This PR adds release to pod selector in stable/rabbitmq chart. This allows deploying multiple releases to the same namespace without issues.

LGTM

/ok-to-test
/lgtm


Unable to format a columns header definition to be a date format.

🐛 Bug Report
Unable to format a columns header definition to be in date format. I can format it to a string that looks like a date, for example yyyy/mm/dd however, the cell type is a string and not a date so I cannot use the exported excel sheet as needed. My use case is creating pivot tables amongst other things based on the date that column is for.
Lib version: latest
Steps To Reproduce
const datedColumns = ['2024/02/02']

Create a workbook
Assign a column [{ header: '2024/02/02', key: '2024/02/02', width: 32 }] with worksheet.columns = columns;
Add a row [{ '2024/02/02': "Dummy Test" }]

    rows.forEach(async (row) => {
      worksheet.addRow(row);
    });

Attempt to format cells to date format

    dateColumns.forEach((column) => {
    // try 1
      worksheet.getRow(1).getCell(column).style = { numFmt: 'yyyy/mm/dd' };
    // try 2
      worksheet.getRow(1).numFmt = 'yyyy/mm/dd';
    // try 3, this formats the data in the rows below the column header to be dates
      worksheet.getColumn(column).numFmt = 'yyyy/mm/dd';
    });

I've also tried defining the format on the column definition like so:
``[{ header: '2024/02/02', key: '2024/02/02', width: 32, style: { numFmt: 'yyyy/dd/mm' } }]`
The expected behaviour:
I expect the resulting cell in my export to be formatted as a date cell, this would make the data in the cell right aligned too.
Possible solution (optional, but very helpful):
enable column header formatting

To add further:
I am able to format the dates in the subsequent rows to be the correct date format and display right aligned. However, not in the column headers.


Abstract sockets breaks A3C for mac osx

commit a46de3426250651c6b8fb993f1c27faac9533a2a breaks A3C on mac os specifically at https://github.com/ppwwyyxx/tensorpack/commit/a46de3426250651c6b8fb993f1c27faac9533a2a#diff-4689f70438745b5328b50f745da00d4e
The changes in examples/A3C-Gym/train-atari.py where:
PIPE_DIR = os.environ.get('TENSORPACK_PIPEDIR', '.').rstrip('/')
namec2s = 'ipc://{}/sim-c2s-{}'.format(PIPE_DIR, name_base)
names2c = 'ipc://{}/sim-s2c-{}'.format(PIPE_DIR, name_base)

Is changed to:
namec2s = 'ipc://@sim-c2s-{}'.format(name_base)
names2c = 'ipc://@sim-s2c-{}'.format(name_base)

And in examples/A3C-Gym/simulator.py where:
name = 'ipc://whatever'

is changed to:
name = 'ipc://@whatever'

Result in a zmd error:
Traceback (most recent call last):
  File "./train-atari.py", line 303, in <module>
    train()
  File "./train-atari.py", line 240, in train
    master = MySimulatorMaster(namec2s, names2c, predict_tower)
  File "./train-atari.py", line 140, in __init__
    super(MySimulatorMaster, self).__init__(pipe_c2s, pipe_s2c)
  File "/Users/Username/tensorpack/examples/A3C-Gym/simulator.py", line 117, in __init__
    self.c2s_socket.bind(pipe_c2s)
  File "zmq/backend/cython/socket.pyx", line 547, in zmq.backend.cython.socket.Socket.bind
  File "zmq/backend/cython/checkrc.pxd", line 25, in zmq.backend.cython.checkrc._check_rc
zmq.error.ZMQError: No such file or directory

Reverting the changes mentioned above allows A3C to run as expected on Mac OSX.

The training wasn't meant to run on osx at the beginning.
An easy fix would be to use different types of sockets conditioned on the OS.

Since the current version does not condition for the os, would it be reasonable to specify somewhere in the docs or readme that training isn't meant for osx?


Document values of Continue and Break

Users who are used to developing against other bindings might find useful to have in the documentation to which values each enum maps to.

ping?

@A6GibKm ping?

Sorry, I forgot about this! I will look into it later today!

I am not sure if having the doc aliases make sense, since they reference GDK.


Update readme to update architecture and make document easier to find.

Coverage remained the same at 22.945% when pulling 5795b17606497f99cc9bb10ec39901dc9ea0b2db on feature/new-architecture-graph into 96e0420ea8c524461a05a8186d5e1f33fd651eb6 on master.

Coverage remained the same at 22.945% when pulling 5795b17606497f99cc9bb10ec39901dc9ea0b2db on feature/new-architecture-graph into 96e0420ea8c524461a05a8186d5e1f33fd651eb6 on master.


Support global dependency query command

A nit, as you added layer parameter, you need the version check.

Got it, If the version is smaller than 10.0.0, we should ignore the layer parameter. I will update in this PR.


fix(dev-tools): Ignore .jar files in lint checks

This Jump Start Solution GitHub repo contains a .jar file.
I would like the lint check to ignore the .jar file. This seems appropriate since all .jar files are binary files (never read by a human) not worth linting.
Reason I committed that .jar file into the repo: it's part of the Maven wrapper. Maven (mvn) is Java's dependency management tool. The Maven wrapper ensures all developers use the same version of mvn. This article says it's "beneficial" to have the wrapper inside source control.
For the file changes in this PR, I took inspiration from https://github.com/GoogleCloudPlatform/cloud-foundation-toolkit/pull/1632/files.
See related Google-internal chat thread.

Aside: Do you know why this commit was reverted?

Aside: Do you know why this commit occurred?

Maybe I did something wrong when I originally set that EXCLUDE_LINT_DIRS variable in that lint.yaml file?

Hi @NimJay! - That file is automatically (and periodically re-) generated. As linked in the header (https://github.com/GoogleCloudPlatform/terraform-cloud-client-api/blob/main/.github/workflows/lint.yaml#L15) your custom config should be made to this lint_env so they are automatically included on generation: https://github.com/GoogleCloudPlatform/cloud-foundation-toolkit/blob/master/infra/terraform/test-org/org/locals.tf#L866.
Here is an example: https://github.com/GoogleCloudPlatform/cloud-foundation-toolkit/blob/master/infra/terraform/test-org/org/locals.tf#L151
That said, I agree it would be best to globally exclude jar files from the text based linters.  Thanks!

@apeabody, thank so the fast response. :)

Bumped the dev-tools version

@NimJay - dev-tools v1.20.4 image is now avaliable


Hook before is executed before the  background

Current behavior
Hook before is executed before the  background

Desired behavior
Hook before is executed after the background and before the scenario."

Test code to reproduce
I'm using the before hook as a tag @createthreeusers before the scenario, but it seems to be executing before the background instead of after it. I've searched everywhere for an answer but couldn't find one. Is there a solution to this? Thank you in advance for your help!"

Versions

Cypress version: 12.11.0
Preprocessor version: 16.0.3
Node version: 18.16.0

Checklist

[x] I've read the FAQ.
[x] I've read instructions for logging issues.
[x] I'm not using<EMAIL_ADDRESS>(package name has changed and it is no longer the most recent version, see #689).

This is the intended behaviour of hooks.

Это предполагаемое поведение хуков.

Thanks for the answer!


New Game Added - Rock Paper Scissor

PR Description 📜
Please include summary related to the issue you have fixed and describe your PR in brief over here by specifying the issue number on which you were working below
Fixes # 1905
Added a New Game to the Webpage names as Rock_Paper_Scissor

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[ ] I have performed a self-review of my own code or work.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[ ] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @Nitin1Sahu ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Hey @Nitin1Sahu,
Please make sure to link the relevant issue using the appropriate syntax, such as "#issueNumber" 👀.
Follow the proper guideline and make a new PR again 😀.
Happy Hacking 💗

Thank you  @Nitin1Sahu , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀

Issue is Closed but what about Merging PR?


divide tf and pr pruning test in CI to detect dependency issue

Type of Change
validation
Description
divide tf and pr pruning test in CI to detect dependency issue
Expected Behavior & Potential Risk
CI pass
How has this PR been tested?
CI
Dependency Change?
No

The failure of baseline is reasonable, because master doesn't have the new scripts.


oneOf not working as intended

Which package are you using?
jest-openapi
OpenAPI version
3
Describe the bug
oneOf does not work as intended. Even though the response object matches one of the schemas, it throws an error
To Reproduce
Steps to reproduce the behavior:
Using this trivial example below
  /application/test:
    get:
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  code:
                    type: string
                  data:
                    oneOf:
                      - type: object
                        properties:
                          hello:
                            type: string
                          world:
                            type: boolean
                          bye:
                            type: string
                          earth:
                            type: boolean
                      - type: object
                        properties:
                          hello:
                            type: string
                          world:
                            type: boolean

I generated an object with the following structure
{
  code: "OK",
  data: {
              hello: "123",
              world: true,
              bye: "123",
              earth: false
           }
}

I received the following error which states that data should match exactly one schema in oneOf

Expected behavior
No error should be thrown

Thanks for raising this :)
I think this is expected OpenAPI behaviour. Your res body is matching 2 schemas, rather than just oneOf them.
(oneOf is not oneOrMoreOf)
I will double check when I have time. Fyi this issue reminds me of an old issue where we were similarly confused about allOf, which I will link here when I'm on my laptop

omg yes you are right. It didnt dawn upon me that it was matching both schema until you mentioned it. I forgot that schemas can match objects with additional properties. Thank you good sir for pointing it out!
I know this probably isnt the place to ask but thought you might have an answer off the top of your head. In that case, should I be using 'anyOf' to describe this API, or is there a better way to work around it? It seems rather odd to be using 'anyOf' when I actually mean 'oneOf'.
Also thank you for your hard work on this library! Mad props to you!

You said it yourself, "schemas can match objects with additional properties", unless you specify additionalProperties: false on your schema :)
I can't find a nice summary of additionalProperties, but here's a starting point https://swagger.io/docs/specification/data-models/keywords/?sbsearch=additionalproperties

yes this works! thank you very much 👍


Problems using a single state step partition with multiworker

I've marked priority: low because single state step partitions are probably not a normal use case.  If we think we want that soon, then this should be changed to priority: high.

Related to #922 and #923 (in that those are both probably caused by this issue).
When running a single state step partition (via .to_stateful() or presumably if you manually created one), if you turn coalescing off when defining a pipeline and do either of the following sequences:
1:
.to(...)
.to(...)
.to_stateful(...)

2:
.to_stateful(...)
.to(...)

then initialization fails in a 2 worker setup.  The failure occurs on initializer in setup 1 and on worker 2 in setup 2.
The complex app creates both of these scenarios at once.
Discovered so far: initialization fails when trying to use the target_id for the PreStateData at the following:
let target_router = built_routers(tid)

This indicates that we have not built the router corresponding to the target in time.
I think the issue is triggered by the fact that some workers have fewer than one state step for the partition.
This problem does NOT happen when any of these are true:

Coalescing is on (i.e. it's not turned off in pipeline definition) and we're in scenario 1. This means all stateless computations and prestate runner are at the source.
The complex state step is replaced with a partition with two state steps (only applies to single state step partition). In this case, there is one state step per worker.
There is only one .to() before .to_stateful()

I too misread that point at first.  It's saying if coalescing is on and we're in scenario 1, implying that scenario 2 causes the problem even with coalescing on.

@SeanTAllen I've updated the text to clarify (and removed references to turning coalescing off)


Kotlin 1.4 automatic stdlib depency triggers some warnings

Using Kotlin 1.4, the kotlin plugin will add the stdlib automatically. If build scripts declare jvmTarget = "1.8", that will include kotlin-stdlib-jdk8 although most of it is used reflectively and this will show up as warnings in the output:
Unused dependencies which should be removed:
- api("org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.4.0")

Transitively used dependencies that should be declared directly as indicated:
- implementation("org.jetbrains.kotlin:kotlin-stdlib:1.4.0")

I'm not sure what can be done about this. Maybe an exception for kotlin-stdlib ?
Reproducer project: https://github.com/martinbonnin/reproducer-dependency-analysis-android-gradle-plugin-262

With this new 1.4 plugin behavior, I think I need to finally break down and whitelist it. Thanks for the report.
GitHub<EMAIL_ADDRESS>wrote:
“Using Kotlin 1.4, the kotlin plugin will add the stdlib automatically. If build scripts declare jvmTarget = "1.8", that will include kotlin-stdlib-jdk8 although most of it is used reflectively and this will show up as warnings in the output:
Unused dependencies which should be removed:

api("org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.4.0")

Transitively used dependencies that should be declared directly as indicated:

implementation("org.jetbrains.kotlin:kotlin-stdlib:1.4.0")

I'm not sure what can be done about this. Maybe an exception for kotlin-stdlib ?”
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I guess the goal of this project is to be explicit over implicit. Even if it means additional verbosity.
With this goal in mind projects should opt-out instead from implicit stdlib management by kotlin plugin with kotlin.stdlib.default.dependency=false property.

I try to balance clarity with ergonomics. In the case of the Kotlin plugin, this is far from the first time I've gotten a request to essentially "whitelist" it to conform to common practice. I think it makes sense to do so.
If you would like the ability to opt-out, please file a feature request and I'll be happy to consider it.


all: split zip out into subpackage

Building on the discussion in #180, this is a way for callers to be
able to use the zip package directly without importing the other
compression/decompression packages. It uses aliases to preserve
backwards compatibility.
The utility functions and types used by the zip package needed to
be split out into a subpackage as well (named "common") to avoid a
circular dependency issue.

I think this is a great change to make. Just want to give a friendly heads up that the tests seem to be failing on the PR.

Looking, thanks.

I can reproduce an test failure locally but just a heads up that I don't have permission to view the Azure build logs.

Tests fixed! And also made the PR up to date.

Please check it now

Please check it now

Thanks, I will review when I have a chance! Currently pretty focused on another project.

Thanks, I will review when I have a chance! Currently pretty focused on another project.

I will make sure to test this as well when I get some time to do so. Will be interesting to see how the binary size is affected.

I will make sure to test this as well when I get some time to do so. Will be interesting to see how the binary size is affected.

We should probably move all the different formats out to their own packages, but this is a great step on the way there :slightly_smiling_face:

Hey, thanks for this PR. I remember I just commented again on the related issue today. It's not a change I feel compelled to make quite yet, but if more compelling use cases / requests come in for it, I might be willing to consider it.
Closing, as this PR is obsoleted by #302, which has true "plugin" support for the formats. So if we do decide to do it, it should be a little easier.


Bazel install target

Let me start by thanking all the hard work supporting this build flow. Overall the experience is much better than I've had previously with cmake, particularly on windows where I'm using it atm.
I'm planning on using the OpenEXR library and headers outside of the bazel build toolchain, in concrete development of bindings for rust, and because of this I need some sort of install target, which afaik is not supported yet.
Having poked a bit at bazel seems like it would be possible to add a pkg_tar rule to export the build libs and headers.
@Vertexwahn slack directed me to raise this issue in the repo and to ask you if this would be the right course to take?
With the hard work already done seems possible to refactor BUILD.bazel to add this rule but I'd first like some confirmation this is the right path.

@tiago-lqt Feel free to add a pkg_tar target to the Bazel build.
You can easily add rules_pkg be adding bazel_dep(name = "rules_pkg", version = "0.10.1") to MODULE.bazel file. In the BUILD.bazel file you will need something like this:
load("@bazel_tools//tools/build_defs/pkg:pkg.bzl", "pkg_tar")

pkg_tar(
    name = "deploy",
    srcs = [
        ..., # add header here - maybe use glob
        ":OpenEXR",
    ],
    extension = "tar.gz",
)

I have no experience with Rust bindings. Put adding a pkg_tar should not be too difficult. Looking forward for your PR:

I've made some progress in setting up a new pkg_zip rule. Using zip for now just for convenience but can adapt to pkg_tar in the future. Should also add that the current effort is focused on exporting only the files required by OpenEXR Core.
Unfortunately I've hit a blocker with dependencies. include/Imath/ImathConfig.h is also required by OpenEXR Core and this file is build from a third party dependency, even if its in the same repo. This  causes the following error:
in pkg_files rule //:ImathFiles: target '@@imath~//:ImathConfig' is not visible from target '//:ImathFiles'.
Check the visibility declaration of the former target if you think the dependency is legitimate

Does this means we would have to update and publish a new Imath version that updates bazel\third_party\Imath.BUILD?

@tiago-lqt
ImathConfig.h is not part of the openexr repo. Some CMake magic fetches Imath if it is not on your system. Similar it is done on the Bazel side:
https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/imath/3.1.11/patches/add_build_file.patch.
src/Imath/ImathConfig.h is a public header of cc_library Imath. The file can be referenced with something like this: @imath//:src/Imath/ImathConfig.h

You're right. I've misread the build files. And thanks to your suggestion managed to get around the issue, but still believe there is a visibility issue.
For context the following comes from testing in the v3.2.4 tag at a1a00ffeecf627bbbc010d40700720bee48b2af7. I wrote half this comment and then went to test at head and noticed the files in question were removed. Which I've tracked for a commit after that release in ad9d698035efd9d0a18952c7c9e7cc24cbeeaa23.
If you see the patch file the action ImathConfig  doesn't have the visibility attribute. And this seems to be causing the visibility issue when using @imath//:src/Imath/ImathConfig.h.
To get around this I've commented out bazel_dep(name = "imath", version = "3.1.10", repo_name = "Imath") in MODULE.bazel. This seems to trigger the use of the local bazel\third_party\openexr_deps.bzl.
Then I updated the action ImathConfig in bazel\third_party\Imath.BUILD with visibility = ["//visibility:public"].
This finally worked and all the files show in the archive.
Of course the files in question are no longer in the repo, but this test might mean the file patch you've linked might have to be updated.

visibility = ["//visibility:public"] is set ->
https://github.com/bazelbuild/bazel-central-registry/blob/de00f8c4d582b105952c4ca687995e94decedbf8/modules/imath/3.1.11/patches/add_build_file.patch#L78
Maybe something like
exports_files([
    "some_heaer.h"
])

is needed.
Can you open a PR with your changes (e.g. in Draft Mode)? Then its easier for me to see the same error...

I've pushed a sample commit to my fork. https://github.com/tiago-lqt/openexr/commit/5965704f5d6aaf238456eaa0777341b79e89449a . Note that the commit is the one raising the error:
in pkg_files rule //:ImathHeaderFiles: target '@@imath~//:ImathConfig' is not visible from target '//:ImathHeaderFiles'.
Check the visibility declaration of the former target if you think the dependency is legitimate

and if I change the path being used to @imath//:src/Imath/ImathConfig.h it still errors with
in pkg_files rule //:ImathHeaderFiles: target '@@imath~//:src/Imath/ImathConfig.h' is not visible from target '//:ImathHeaderFiles'.
Check the visibility declaration of the former target if you think the dependency is legitimate

To clarify, the rule where I've added the public visibility is the ImathConfig, not Imath that you've linked to. https://github.com/bazelbuild/bazel-central-registry/blob/de00f8c4d582b105952c4ca687995e94decedbf8/modules/imath/3.1.11/patches/add_build_file.patch#L10
Referencing Imath only seems to output the compiled library, not the header files.
I'm guessing that adding this snippet around line 27 of that patch file would solve the issue.
    template = "config/ImathConfig.h.in",
    visibility = ["//visibility:public"]
)

@tiago-lqt

Must be imath not Imath

pkg_files(
    name = "ImathHeaderFiles",
    srcs = [
        "@imath//:ImathConfig"
    ],
    prefix = "include/Imath",
)

visiblity need to be changed -> PR is in place here -> https://github.com/bazelbuild/bazel-central-registry/pull/1953

For 1. its likely due to trying different options. Both were erroring out but I'll switch to imath for the next iteration.
PR looks good, thanks for setting it up!

@tiago-lqt https://github.com/bazelbuild/bazel-central-registry/pull/1953 is merged now.

This is now working locally. I'm able to create a zip with the library and headers with a single bazel command.
Thank you for all the help.


ci: introduces basic unit test job

In order to ensure healthy code base we can automate checks as GitHub actions. This way we can spot defects early and make sure all new changes are not breaking anything.
This change brings a simple job which for each PR or push to main branch will trigger unit tests and binary compilation (default target).

You can test it locally using act
act "on: push" -j unit-test -P ubuntu-latest=ghcr.io/catthehacker/ubuntu:act-latest


MongoDB, log in page not working

Need to implement MongoDB and finish the log in page for Athena

implemented via IPFS.


Update LAB_AK_02_Lab1_Ex3_DLP_reports.md

Module: 00
Lab/Demo: 00
Fixes # .
Changes proposed in this pull request:

Submitted by ParamRamki on behalf of MOC Labs Review

Submitted by ParamRamki on behalf of MOC Labs Review


GH-313: Configure group.id on @KafkaListener

Resolves: https://github.com/spring-projects/spring-kafka/issues/313
Allow configuration of the group.id property on the annotation.

Merged as https://github.com/spring-projects/spring-kafka/commit/2ca52091c100aeda0fc41cefb70b2954156f0f94


Finance: Missing Items In Inventory

Inventory updates necessary:

[ ] Missing DeWalt 37 piece driver bit set. Mfr Model "#DW2176"
[ ] Missing DeWalt 14 piece drill bit set. 1/16"-3/8". "#DW1162"
[ ] Update name of "Aluminum Refrigerator LED Fixture Holder" to "Aluminum Refrigerator LED Bracket" in inventory.
[ ] Missing variety of nuts and bolts.
[ ] Missing screws.
[ ] Missing Dremel Multi Pro Kit 3966
[ ] Missing other power tool: Bosch "#34614" Power Tool 14.4V

Updated inventory.


Support for ARM64 host systems

When running on an ARM64 host system running either Linux or macOS, BuildKit will default to building ARM64 container images unless the flags --platform linux/amd64 are explicitly specified. At the moment, ue4-docker does not include any logic to pass these flags, leading to failed attempts to build Linux images for ARM64 despite the fact that the Unreal Editor does not support being built for this architecture.
To correctly support ARM64 host systems, we should pass --platform linux/amd64 to BuildKit under Linux and macOS. In theory this could be gated behind a check that detects the host CPU architecture, but in practice we should be able to just pass this unconditionally for now. (If a future version of the Unreal Engine introduces support for building the Editor for ARM64 targets then I suspect we'll need to introduce separate logic to allow users to select the desired CPU architecture anyway.)
I don't have an ARM64 machine to test on myself, but I'll liaise with the community member who brought this issue to my attention to validate the fix.

The new logic has now been added in commit 7fb98d9, and initial testing on an AMD64 Linux machine confirms that passing the platform flags unconditionally doesn't cause any problems. I'll report back here once it's been tested on an ARM64 machine.

Update on the macOS side of things: it looks like ARM64 macOS might be incapable of building Unreal Engine container images when using x86 emulation, due to QEMU not supporting a CPU intrinsic that UE requires:

https://stackoverflow.com/questions/71162318/how-do-i-solve-amd64-is-imm32-disp-assertion-error-in-official-unreal-dev-co
https://discuss.eventstore.com/t/problem-of-running-eventstore-in-docker-on-apple-m1-arm64/3500

I still need to test on ARM64 Linux, but my understanding is that BuildKit uses QEMU for multi-arch support under Linux as well, so there's a very good chance that it suffers from the same limitation. If this proves to be the case, we might want to add logic to detect ARM64 host systems and error out with a message that tells the user why their host system can't be used to build container images with ue4-docker.

I was curious, and it looks like this was fixed in Mono 6.8: https://github.com/mono/mono/pull/16474. I don't immediately see a way to take advantage of that though.

Interesting, if the problem is specific to Mono then in theory it should only affect Unreal Engine 4.27 and older, since my understanding is that UE5 uses its bundled version .NET Core instead (although I do see that Mono is still bundled with the engine in addition to .NET Core as of 5.1.)


TypeError: Super expression must either be null or a function, not undefined

I get this error on the require statement:
TypeError: Super expression must either be null or a function, not undefined
    at _inherits (C:\Apps\workspace\betty.acdb.ui\node_modules\react-dnd-multi-backend\lib\Preview.js:26:113)
    at C:\Apps\workspace\betty.acdb.ui\node_modules\react-dnd-multi-backend\lib\Preview.js:33:3
    at Object.<anonymous> (C:\Apps\workspace\betty.acdb.ui\node_modules\react-dnd-multi-backend\lib\Preview.js:58:2)
    at Module._compile (module.js:435:26)

Hi @maxcc0,
Could you give me a bit more context about how you got this error? For example your usage of Preview, etc.
Thanks,

With the recent changes (notably #12), this may be fixed. If it isn't, please add more information on your browser, usage, example code, etc. Thanks!


Audio mix with other apps for iOS

This PR adds a feature to control how audio from video can mix with audios from others apps in iOS.
It's uses the options AVAudioSessionCategoryOptionMixWithOthers and AVAudioSessionCategoryOptionDuckOthers
It's helps https://github.com/react-native-community/react-native-video/issues/1103 and https://github.com/react-native-community/react-native-video/pull/959. It's also highly referenced by https://github.com/react-native-community/react-native-video/pull/403.
I'm not a iOS developer so please fells free to points to me any Obj-C error.
Sample:
<Video
  ...
  mixWithOthers="mix" // or "duck"
/>

This looks good to me @euharrison, I can see how this could be useful. Thanks for submitting it! Is there a similar property for Android we can implement?

I guess ignoreSilentSwitch is iOS only so then by that logic this can be added too :) Just make sure docs are clearly staging it's for iOS only.

Thanks that you appreciate @jenshandersson :)
I added the Platforms: iOS in the README. If you suggest to add it in another file, please let me know
https://github.com/react-native-community/react-native-video/pull/1978/files#diff-04c6e90faac2675aa89e2176d2eec7d8R541

Ah right, great. Can you add a line in the changelog as well @euharrison? Check other PRs to see how, basically a explanation and reference to PR

Done ✅


Add openSUSE to the list of distributions, update Ubuntu

Added openSUSE Tumbleweed (rolling release) and Leap 42.1
Updated Ubuntu by adding the 16,10 (Yakkety) release

Thank you so much!


Format SQL notebooks

Blackbricks is currently designed to only format Python notebooks (text files with a # Databricks notebook source header). I'd like to implement formatting of SQL notebooks (-- Databricks notebooks source header), as well. I will try to write some new tests and will definitely clarify this change in the docs.
What do you think? Does this align with your vision for Blackbricks?

Sorry for the somewhat late response.
In short, no, I don't think that belongs in blackbricks. It sounds like a different tool. I somewhat regret adding sql formatting to blackbricks at all, as it was done mostly as an afterthought, and it shows. The focus has always been Python notebook, as the name implies by being tied to black.
I'd instead lobby for Databricks to add this to dbx. Really, dbx should IMO get general formatting/linting of notebooks, and ideally make blackbricks obsolete. If you're going to make an effort and make a significant PR, I'd do it to https://github.com/databrickslabs/dbx 👍🏻


Implement latched topics on TCP

Transmitting a latched topic over the nimbro relay was not supported.
This PR adds several features:

The publisher on the receiving side will have the "latched" option set if the topic is marked as latched in the YAML config.
Each TCP sender provides a service (over nimbro) which, when called, republishes latched messages to all latched topics. This makes sure that receivers started after the sender will get even the first latched message.
The above mentioned service can be called automatically when the receiver is ready.

This PR almost surely breaks ABI, if take care about it. On the other hand, API changes are not breaking compatibility with previous versions.

Thanks for the PR!
If I understand correctly, your are supporting latching only for the TCP transport. In that case, I do not understand the need for the complex "latch helper" setup. I would suggest to re-send latched messages whenever TCPSender::connect() is successful, indicating a new receiver has started.

Oh man, could it be that simple? I admit I haven't understood the whole relay code, but it looked impossible to me to tell when the client has connected. But as you pointed me to the right direction, it now seems clear to me.
Few questions arise:

Isn't there a possible infinite loop if I resend the latched messages from connect, which is itself called from the send method? I mean in case the connection is very unreliable or so...
Now, when it's almost clear the whole cumbersome thing was not needed, is there a chance to make use of it on the UDP transport?

Isn't there a possible infinite loop if I resend the latched messages from connect, which is itself called from the send method? I mean in case the connection is very unreliable or so...

I guess so. At the very least we should prevent the inner send() routine (resending a latched message) from calling connect() again. Maybe an additional parameter reconnect with default value true?

Now, when it's almost clear the whole cumbersome thing was not needed, is there a chance to make use of it on the UDP transport?
I have never seen a use case for latched topics over UDP. Typically, UDP data is streaming data, where latching makes no sense. Or do you have an actual use case for that?

Ah, and there is one more issue: If there are no messages to transmit, send will never get called, and will never notice the dropped connection. So we should introduce a timer which checks whether the connection is still open, and if not, reconnects (and re-sends latched messages).

Ok, I'm trying to rewrite and will send a new PR in a while. Your anti-looping suggestion sounds good to me.
And regarding latched UDP topics - it probably really doesn't make sense to latch UDP topics... Should I add a warning to the UDP transport when it finds a topic which requires latching?

Well, now I think if this wasn't my original issue... I kind of get lost thinking about all the possible cases. Wouldn't periodical connection check be a problem? Either performance-wise, or just for the case that the receiver is stopped and is not mentioned to be re-run? (e.g. unsubscribing from all topics on the receiving side).

Wait, is the dropped connection really a problem?
The receiver also sets the "latched" flag at the publishers it creates. So even if the connection drops, the subscribers on the receiving side will get properly handled. Or do I miss some other important point?


update to 1.0.3

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Could you have a look at this, @alxsimon? (I can't request you as a reviewer for some reason.)

yes, that's good to go


Location hash vs none?

Any reason to enforce location: hash vs none as part of the Ember framework validations?
Let's just say in our experiments w stacked native routing, we ended up disabling URL changes entirely, and while it's not big hassle to re-enable hash routing, seems like we should just be able to leave it off, no?

Hash routing is causing me errors now. Did none work for you?


Comment on generics

Added a section on how to use generics.
While here, we also remove the comment on the model package
since 6.0 is already released and changes have been made to make
everything consistent.

Thanks @cwarnermm !


SSL certs should only be generated if enableLocalHTTPS: true

currently it looks like openslides setup will always generate local ssl certs for HTTPS.
It should instead respect the enableLocalHTTPS config, so systems that use their own HTTPS setup wont be unnecessarily cluttered.
I imagined this is just a matter of adding an appropriate if statement in setup.go.
However looking at it seems setup.go doesn't yet parse the config file (only config.go does).
So I think some refactoring would be in order to call newYmlConfig() from setup.go.

@peb-adr This issue should be solved, right?

yes


collects mesos tags during docker_daemon check

What does this PR do?
It adds mesos_task_id and marathon_app_id or chronos_job_name to docker daemon check tags.
Its based on https://github.com/DataDog/dd-agent/pull/2870 but adds the other 2 tags.
It does it by inspecting container and extracting environment variables set by mesos.
Motivation
With mesos the container_name is useless.
Testing Guidelines
No tests yet.

@maciekm Thanks for joining our community and contributing to the docker integration. We'd love to merge this. Have you had a chance to review Haissam's feedback? We'd be happy to discuss further if you have any thoughts.

sorry, completely forgot about this PR and somehow missed the comments.
Closing as I can see its already done and will be in 5.15 version


Driver for Scaleway

First Pull Request :
https://github.com/docker/machine/pull/947
Signed-off-by: Nicolas Lamirault<EMAIL_ADDRESS>

:+1:

Any updates on this ?

:+1:

:+1:

:+1:

Hi , thanks for your efforts and persistence in submitting this driver. We are extremely excited that there is so much interest in Docker Machine and we really appreciate your interest. However, at this time it is proving to be extremely difficult for us to keep up with reviewing and testing each of these drivers for inclusion in the Machine core. We really want to switch to a more pluggable model, as well as polish up a few things about the driver model which need to be changed to ensure a smooth and sustainable future.
Therefore, we will be moving to a plugin model for 0.5 and would love to have you involved in the design and development process. We are closing the outstanding driver PRs at this time, but please keep the code. We will stick closely to the current driver interface and you should be able to re-use a lot (if not all) of the existing driver along with the new plugin model. We will be moving all of the drivers which are merged directly into Machine today to the plugin model when it is available, so there will be no special treatment of those, and there will be documentation outlining the process of developing and using a Docker Machine driver plugin.
With all of that being said, we want to apologize for the lack of feedback on your pull request. As contributors ourselves, we understand that being left in limbo is no fun. We would have liked to address this sooner, and in the future we will be more responsive around these kinds of issues.
Once again, we thank you for the contribution and the tremendous support. Keep hacking strong!
If you want to contribute to the design of the plugin model, we'd love to get your input on this issue where we will be planning it:
https://github.com/docker/machine/issues/1626
@ehazlett & @nathanleclaire


Live subscribe/unsubscribe for Binance exchanges

Issue initially reported in PR #152.  Binance supports live subscribe/unsubscribe - https://github.com/binance-exchange/binance-official-api-docs/blob/master/web-socket-streams.md#live-subscribingunsubscribing-to-streams.  It is likely that the Binance Clients can be migrated to use the BasicClient instead of custom implementations.

Looks like a socket can be initialized without an attached stream:
const ws = new WebSocket("wss://stream.binance.com:9443/stream");
ws.onopen = function() {
    console.log("open");
}
ws.onmessage = function(msg) {
    const data = JSON.parse(msg.data);
    console.log(data.stream);
}

ws.send(JSON.stringify(
        {
          method: "SUBSCRIBE",
          params: ['btcusdt@aggTrade', 'ethbtc@aggTrade'],
          id: 1
        }
    ))

ws.send(JSON.stringify({
    method: "UNSUBSCRIBE",
    params: ['btcusdt@aggTrade'],
    id: 1
}))

It looks like there there is a limit to the number of sub/unsub operations that can be performed in a given time period. I've tested this with a 1-sub semaphore and it works decently with 500ms delays per sub.
For example, this will result in 0 subscriptions:
const ws = new WebSocket("wss://stream.binance.com:9443/stream");
ws.onopen = function() {
    console.log("open");
}
ws.onmessage = function(msg) {
    const data = JSON.parse(msg.data);
    console.log(data.stream ? data.stream : data);
}

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["ethbtc@aggTrade"],
  id: 0
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["ltcbtc@aggTrade"],
  id: 1
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["bnbbtc@aggTrade"],
  id: 2
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["neobtc@aggTrade"],
  id: 3
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["qtumeth@aggTrade"],
  id: 4
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["eoseth@aggTrade"],
  id: 5
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["snteth@aggTrade"],
  id: 6
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["bnteth@aggTrade"],
  id: 7
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["gasbtc@aggTrade"],
  id: 8
}))

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["bnbeth@aggTrade"],
  id: 9
}))

There is also a limit to the number of subscriptions that can be made at at time.  I'm getting a failure with 437 streams, though this could easily be param field size limit, binance silently fails without any additional information.
For example, this fails, but if you try again with 1 less stream it will work:
const ws = new WebSocket("wss://stream.binance.com:9443/stream");
ws.onopen = function() {
    console.log("open");
}
ws.onmessage = function(msg) {
    const data = JSON.parse(msg.data);
    console.log(data.stream ? data.stream : data);
}

ws.send(JSON.stringify({
  method: 'SUBSCRIBE',
  params: ["ethbtc@aggTrade","ltcbtc@aggTrade","bnbbtc@aggTrade","neobtc@aggTrade","qtumeth@aggTrade","eoseth@aggTrade","snteth@aggTrade","bnteth@aggTrade","gasbtc@aggTrade","bnbeth@aggTrade","btcusdt@aggTrade","ethusdt@aggTrade","mcoeth@aggTrade","mcobtc@aggTrade","wtcbtc@aggTrade","wtceth@aggTrade","lrcbtc@aggTrade","lrceth@aggTrade","qtumbtc@aggTrade","yoyobtc@aggTrade","omgbtc@aggTrade","omgeth@aggTrade","zrxbtc@aggTrade","zrxeth@aggTrade","stratbtc@aggTrade","strateth@aggTrade","snglsbtc@aggTrade","bqxbtc@aggTrade","bqxeth@aggTrade","kncbtc@aggTrade","knceth@aggTrade","funbtc@aggTrade","funeth@aggTrade","snmbtc@aggTrade","neoeth@aggTrade","iotabtc@aggTrade","iotaeth@aggTrade","linkbtc@aggTrade","linketh@aggTrade","xvgbtc@aggTrade","xvgeth@aggTrade","mdabtc@aggTrade","mdaeth@aggTrade","mtlbtc@aggTrade","mtleth@aggTrade","eosbtc@aggTrade","sntbtc@aggTrade","etceth@aggTrade","etcbtc@aggTrade","mthbtc@aggTrade","engbtc@aggTrade","engeth@aggTrade","dntbtc@aggTrade","zecbtc@aggTrade","zeceth@aggTrade","bntbtc@aggTrade","astbtc@aggTrade","dashbtc@aggTrade","dasheth@aggTrade","oaxbtc@aggTrade","btgbtc@aggTrade","evxbtc@aggTrade","evxeth@aggTrade","reqbtc@aggTrade","vibbtc@aggTrade","vibeth@aggTrade","trxbtc@aggTrade","trxeth@aggTrade","powrbtc@aggTrade","powreth@aggTrade","arkbtc@aggTrade","arketh@aggTrade","xrpbtc@aggTrade","xrpeth@aggTrade","enjbtc@aggTrade","enjeth@aggTrade","storjbtc@aggTrade","storjeth@aggTrade","bnbusdt@aggTrade","kmdbtc@aggTrade","kmdeth@aggTrade","rcnbtc@aggTrade","nulsbtc@aggTrade","nulseth@aggTrade","rdnbtc@aggTrade","rdneth@aggTrade","xmrbtc@aggTrade","xmreth@aggTrade","wtcbnb@aggTrade","dltbtc@aggTrade","ambbtc@aggTrade","batbtc@aggTrade","bateth@aggTrade","batbnb@aggTrade","bcptbtc@aggTrade","arnbtc@aggTrade","arneth@aggTrade","gvtbtc@aggTrade","cdtbtc@aggTrade","cdteth@aggTrade","gxsbtc@aggTrade","gxseth@aggTrade","neousdt@aggTrade","neobnb@aggTrade","poebtc@aggTrade","qspbtc@aggTrade","qspeth@aggTrade","btsbtc@aggTrade","xzcbtc@aggTrade","xzceth@aggTrade","xzcbnb@aggTrade","lskbtc@aggTrade","lsketh@aggTrade","tntbtc@aggTrade","tnteth@aggTrade","fuelbtc@aggTrade","manabtc@aggTrade","manaeth@aggTrade","bcdbtc@aggTrade","bcdeth@aggTrade","iotabnb@aggTrade","adxbtc@aggTrade","adxeth@aggTrade","adabtc@aggTrade","adaeth@aggTrade","pptbtc@aggTrade","cmtbtc@aggTrade","cmteth@aggTrade","xlmbtc@aggTrade","xlmeth@aggTrade","xlmbnb@aggTrade","cndbtc@aggTrade","lendbtc@aggTrade","lendeth@aggTrade","wabibtc@aggTrade","wabibnb@aggTrade","ltceth@aggTrade","ltcusdt@aggTrade","ltcbnb@aggTrade","tnbbtc@aggTrade","wavesbtc@aggTrade","waveseth@aggTrade","wavesbnb@aggTrade","gtobtc@aggTrade","gtoeth@aggTrade","icxbtc@aggTrade","icxeth@aggTrade","icxbnb@aggTrade","ostbtc@aggTrade","osteth@aggTrade","elfbtc@aggTrade","elfeth@aggTrade","aionbtc@aggTrade","aioneth@aggTrade","aionbnb@aggTrade","neblbtc@aggTrade","nebleth@aggTrade","neblbnb@aggTrade","brdbtc@aggTrade","brdeth@aggTrade","brdbnb@aggTrade","edobtc@aggTrade","edoeth@aggTrade","navbtc@aggTrade","lunbtc@aggTrade","appcbtc@aggTrade","vibebtc@aggTrade","rlcbtc@aggTrade","rlceth@aggTrade","rlcbnb@aggTrade","insbtc@aggTrade","pivxbtc@aggTrade","pivxeth@aggTrade","iostbtc@aggTrade","iosteth@aggTrade","steembtc@aggTrade","steemeth@aggTrade","steembnb@aggTrade","nanobtc@aggTrade","nanoeth@aggTrade","nanobnb@aggTrade","viabtc@aggTrade","blzbtc@aggTrade","blzeth@aggTrade","blzbnb@aggTrade","aebtc@aggTrade","aeeth@aggTrade","ncasheth@aggTrade","poabtc@aggTrade","zilbtc@aggTrade","zileth@aggTrade","zilbnb@aggTrade","ontbtc@aggTrade","onteth@aggTrade","ontbnb@aggTrade","stormbtc@aggTrade","stormeth@aggTrade","qtumusdt@aggTrade","xembtc@aggTrade","xemeth@aggTrade","wanbtc@aggTrade","waneth@aggTrade","wanbnb@aggTrade","wprbtc@aggTrade","qlcbtc@aggTrade","qlceth@aggTrade","sysbtc@aggTrade","grsbtc@aggTrade","grseth@aggTrade","adausdt@aggTrade","adabnb@aggTrade","gntbtc@aggTrade","gnteth@aggTrade","loombtc@aggTrade","loometh@aggTrade","xrpusdt@aggTrade","repbtc@aggTrade","repeth@aggTrade","btctusd@aggTrade","ethtusd@aggTrade","zenbtc@aggTrade","zeneth@aggTrade","zenbnb@aggTrade","skybtc@aggTrade","skyeth@aggTrade","eosusdt@aggTrade","eosbnb@aggTrade","cvcbtc@aggTrade","cvceth@aggTrade","thetabtc@aggTrade","thetaeth@aggTrade","thetabnb@aggTrade","xrpbnb@aggTrade","tusdusdt@aggTrade","iotausdt@aggTrade","xlmusdt@aggTrade","iotxbtc@aggTrade","iotxeth@aggTrade","qkcbtc@aggTrade","qkceth@aggTrade","agibtc@aggTrade","agieth@aggTrade","nxsbtc@aggTrade","enjbnb@aggTrade","databtc@aggTrade","dataeth@aggTrade","ontusdt@aggTrade","trxbnb@aggTrade","trxusdt@aggTrade","etcusdt@aggTrade","etcbnb@aggTrade","icxusdt@aggTrade","scbtc@aggTrade","sceth@aggTrade","scbnb@aggTrade","npxseth@aggTrade","keyeth@aggTrade","nasbtc@aggTrade","naseth@aggTrade","mfteth@aggTrade","mftbnb@aggTrade","denteth@aggTrade","ardrbtc@aggTrade","nulsusdt@aggTrade","hotbtc@aggTrade","hoteth@aggTrade","vetbtc@aggTrade","veteth@aggTrade","vetusdt@aggTrade","vetbnb@aggTrade","dockbtc@aggTrade","docketh@aggTrade","polybtc@aggTrade","hcbtc@aggTrade","gobtc@aggTrade","paxusdt@aggTrade","rvnbtc@aggTrade","rvnbnb@aggTrade","dcrbtc@aggTrade","mithbtc@aggTrade","mithbnb@aggTrade","bnbpax@aggTrade","btcpax@aggTrade","ethpax@aggTrade","xrppax@aggTrade","eospax@aggTrade","renbtc@aggTrade","bnbtusd@aggTrade","xrptusd@aggTrade","eostusd@aggTrade","xlmtusd@aggTrade","bnbusdc@aggTrade","btcusdc@aggTrade","ethusdc@aggTrade","xrpusdc@aggTrade","eosusdc@aggTrade","usdcusdt@aggTrade","adatusd@aggTrade","trxtusd@aggTrade","neotusd@aggTrade","trxxrp@aggTrade","paxtusd@aggTrade","usdctusd@aggTrade","usdcpax@aggTrade","linkusdt@aggTrade","linktusd@aggTrade","linkpax@aggTrade","linkusdc@aggTrade","wavesusdt@aggTrade","wavesusdc@aggTrade","ltctusd@aggTrade","ltcpax@aggTrade","ltcusdc@aggTrade","trxpax@aggTrade","trxusdc@aggTrade","bttbnb@aggTrade","bttusdt@aggTrade","usdsusdt@aggTrade","bttpax@aggTrade","btttusd@aggTrade","bttusdc@aggTrade","ongbtc@aggTrade","ongusdt@aggTrade","hotbnb@aggTrade","hotusdt@aggTrade","zilusdt@aggTrade","zrxbnb@aggTrade","zrxusdt@aggTrade","fetbnb@aggTrade","fetbtc@aggTrade","fetusdt@aggTrade","batusdt@aggTrade","xmrbnb@aggTrade","xmrusdt@aggTrade","zecbnb@aggTrade","zecusdt@aggTrade","zectusd@aggTrade","zecusdc@aggTrade","iostbnb@aggTrade","iostusdt@aggTrade","celrbnb@aggTrade","celrbtc@aggTrade","celrusdt@aggTrade","adausdc@aggTrade","neousdc@aggTrade","dashbnb@aggTrade","dashusdt@aggTrade","nanousdt@aggTrade","omgusdt@aggTrade","thetausdt@aggTrade","enjusdt@aggTrade","mithusdt@aggTrade","maticbnb@aggTrade","maticbtc@aggTrade","maticusdt@aggTrade","atombnb@aggTrade","atombtc@aggTrade","atomusdt@aggTrade","atomusdc@aggTrade","batusdc@aggTrade","phbbtc@aggTrade","phbtusd@aggTrade","tfuelbtc@aggTrade","tfuelusdt@aggTrade","onebnb@aggTrade","onebtc@aggTrade","oneusdt@aggTrade","oneusdc@aggTrade","ftmbnb@aggTrade","ftmbtc@aggTrade","ftmusdt@aggTrade","algobnb@aggTrade","algobtc@aggTrade","algousdt@aggTrade","algotusd@aggTrade","algopax@aggTrade","gtousdt@aggTrade","erdbnb@aggTrade","erdbtc@aggTrade","erdusdt@aggTrade","dogebnb@aggTrade","dogebtc@aggTrade","dogeusdt@aggTrade","duskbtc@aggTrade","duskusdt@aggTrade","bgbpusdc@aggTrade","ankrbnb@aggTrade","ankrbtc@aggTrade","ankrusdt@aggTrade","winbnb@aggTrade","winusdt@aggTrade","winusdc@aggTrade","cosbnb@aggTrade","cosbtc@aggTrade","cosusdt@aggTrade","npxsusdt@aggTrade","cocosbnb@aggTrade","cocosusdt@aggTrade","mtlusdt@aggTrade","tomobnb@aggTrade","tomobtc@aggTrade","tomousdt@aggTrade","perlbnb@aggTrade","perlbtc@aggTrade","perlusdt@aggTrade","dentusdt@aggTrade","mftusdt@aggTrade","keyusdt@aggTrade","stormusdt@aggTrade","dockusdt@aggTrade","wanusdt@aggTrade","funusdt@aggTrade","cvcusdt@aggTrade","btttrx@aggTrade","wintrx@aggTrade","chzbnb@aggTrade","chzbtc@aggTrade","chzusdt@aggTrade","bandbnb@aggTrade","bandbtc@aggTrade","bandusdt@aggTrade","bnbbusd@aggTrade","btcbusd@aggTrade","busdusdt@aggTrade","beambnb@aggTrade","beambtc@aggTrade","beamusdt@aggTrade","xtzbnb@aggTrade","xtzbtc@aggTrade","xtzusdt@aggTrade","renusdt@aggTrade","rvnusdt@aggTrade","hcusdt@aggTrade","hbarbnb@aggTrade","hbarbtc@aggTrade","hbarusdt@aggTrade","nknbnb@aggTrade","nknbtc@aggTrade"],
  id: 1
}))

I can confirm its a query length limit from testing. Binance throws a 414 when its unhappy way.
Error: Unexpected server response: 414

@FishTheOriginal thanks I added both throttling and batching which seems to stabilize things well

I would like to thank @bmancini55 and everyone who was involved in this issue. Now not to ruin the party there's an issue with handling errors.
Errors are not being handled:
TypeError: Cannot read property 'toLowerCase' of undefined     at BinanceClient._onMessage (/.../node_modules/ccxws/src/exchanges/binance-base.js:208:20)
What happens is that msg looks like this:
{ error: { code: 4, msg: 'Too many subscriptions' }, id: 6 }

@FishTheOriginal thanks the heads up!  Looks like an easy fix that I'll get in shortly.

Fixed in new release v0.34.1!

I'm putting some stress on Binance and the lib seems to be holding well. Thanks @bmancini55 .


chore(package): update react to version 0.14.6

http://greenkeeper.io/

Can one of the admins verify this patch?


How to style the markdown ?

How best to add styles to the tailwind css for blockquote quotes etc for the markdown sections  of hugo ?
Is this the right approach ?
https://github.com/iandinwoodie/github-markdown-tailwindcss

Do you mean syntax highlighting code blocks within your markdown written content, like this example?

Hi, this is a post with some sample code.

    ```go
    func main() {
        println("Hello, world!")
    }
    ```
Some other text for this blog post.

Best would be to use the build-in Hugo highlighter. It gives you standard themes for syntax highlighting. You then have to only style the <pre> block from within your main style sheet.

What I mean is is styling a quote, which in markdown is something like:-

This is a quotation.

In the resulting html it will be seen as

This is a quotation

By default tailwind 'preflight' aggressively removes lots of styling to create the 'level playing field' for consistency across browsers, e.g:-
https://tailwindcss.com/docs/preflight/
So on my new site has all the markdown content just looking like plain text:-
https://essentials.visitor.express/ Nice front page styled with tail wind - thank you
https://essentials.visitor.express/about/team/dave/  unstyled markdown, not looking so nice,
Really appreciate your help/guidance

Ok, I see. Yes, the approach you linked is basically correct. In the context of this package add styles which apply to markdown generated content of your hugo site to assets/css/site.css, e.g.
blockquote {
    @apply border-l-4 border-gray-500 pl-2;
}

This style applies to all <blockquote> elements for the whole site now.
If you want different styles for the same element type on different pages, you have to wrap the {{ .Content }} part within your hugo page templates into a page specific element identified by id="" or class="".
For example in your layout template for the about/team page:
<div class="about">
    {{ .Content }}
</div>

Within assets/css/site.css now add:
.about blockquote {
    @apply border-l-4 border-gray-500 pl-2;
}

See also https://tailwindcss.com/docs/extracting-components


Add missing config.DISABLE_PERFORMANCE_WARNINGS checks

Fix a few functions that raise a NumbaPerformanceWarningwithout checking whetherconfig.DISABLE_PERFORMANCE_WARNINGS` is set.
See the corresponding bug report and PR in Numba:

https://github.com/numba/numba/issues/9762
https://github.com/numba/numba/pull/9794

I've manually confirmed that this disables both performance warnings locally.

Just waiting for CI now.

Many thanks @maxkapur!


doc(table): add demo about rowScope

[中文版模板 / Chinese template]
🤔 This is a ...

[ ] New feature
[ ] Bug fix
[ ] Site / documentation update
[x] Demo update
[ ] Component style update
[ ] TypeScript definition update
[ ] Bundle size optimization
[ ] Performance optimization
[ ] Enhancement feature
[ ] Internationalization
[ ] Refactoring
[ ] Code style optimization
[ ] Test Case
[ ] Branch merge
[ ] Workflow
[ ] Other (about what?)

🔗 Related issue link

💡 Background and solution

📝 Changelog

Language
Changelog

🇺🇸 English
add demo about rowScope

🇨🇳 Chinese
添加关于 rowScope 的 demo

☑ Self-Check before Merge
⚠ Please check all items below before requesting a reviewing. ⚠

[x] Doc is updated/provided or not needed
[x] Demo is updated/provided or not needed
[x] TypeScript definition is updated/provided or not needed
[x] Changelog is provided or not needed

LGTM


Help: Unity not responding while restoring package

Expected behavior
When clearing cached Library folder and reopen project, Unity's UPM will restore packages, includes Newtonsoft.Json-for-Unity.
Actual behavior
Unity is stucking in splash screen.

Task manager says one or more thread are wait for finishing Network I/O.

Steps to reproduce

New project
Import jillejr.newtonsoft.json-for-unity via UPM
Close project
Delete Library folder in project folder
Reopen project
Unity will stuck in splash screen.
When removes package info in manifest.json then Unity will successfully open project.

Details
OS : Windows 10 Pro RS5 (1909) 64bit
Unity : 2019.3.3f1
Package version : 12.0.301
Checklist

[x] Shutdown Unity, deleted the /Library folder, opened project again in Unity, and problem still remains.
[x] Checked to be using latest version of the package.

Hey thanks for reporting this issue! It's really helpful!
This is the first time I've ever seen anything like it and sadly I can't make any educated assumptions from this. Some further questions:

On first import, does UPM download the package, or has it never succeeded?

Can you access npm.cloudsmith.io? Like try pinging
ping npm.cloudsmith.io

Could you also post the log file from when this occurs? The log file can be found at:
%LOCALAPPDATA%\Unity\Editor\Editor.log

Upload it here or at https://pastebin.com and paste the link here. Or if your logs contains confidential information you can email the pastebin link to me.

Hmm I can't reproduce this now, it's maybe this issue has fixed in Unity side host or something, I think...
Question 1 was fine if already opened project.
But adding package before open project, Unity was stucked.
And question 2 is yes, it's able to connect to package host!
When I got this situation again then I'll answer to you 3rd question!
Because it's seems issued part was discarded by Unity editor...
I'll temporary close this issue, and thanks to attention for my issue!

So, I got again this situation.
Heres excluding json.net package info in manifest.json before and after Editor.log, I checked it with diff it seems AssetDatabase doesn't appears in log.
Editor.log (before excluding json.net package info in manifest)
Editor.log (after excluding json.net package info in manifest)
If you have vscode, open new two file, and paste them each side then right click files to check diff.

Big hmm. Still can't make any conclusions. As you said only when excluding the package it does a script compilation (as seen in the - Starting script compilation section)
To try track it down more, what about:

Are you doing any DllImport in your project?

Are both logs from launching with a deleted Library folder? Since only one log shows recompilation.

What are your projects scripting backend and API compatability level?

What's the content of the %LOCALAPPDATA%\Unity\Editor\upm.log file on a failed launch? (usually never find anything there of interest but I'm shooting in the dark right now)

If you grab the content of the package and toss it into the Assets folder instead of having it added as an UPM package, does it still freeze at startup?

Sorry for late reply, I was busy on my works 🙏

Yes, my project uses nuget packages. (Markdig, AngleSharp, ColorCode)

That's my all logs started with Library folder!

Project uses .NET Framework 4.x compatability.

Seems there's noting to found useful information...

[2020-03-03T05:11:25.259Z][INFO] Starting Server
[2020-03-03T05:11:25.265Z][INFO] Server started on port [50812]
[2020-03-03T05:11:25.319Z][INFO] Health Request received

Yes, it's happen again! this is meaning that problem is compiler side or something?

Additional info about question 5, my project uses Unity's *.asmdef that simulates codes into different assembly or dll.

Editor script : *nothing
Asset script : referenceing TextMeshPro only

{
    "name": "ProblemSetScripts",
    "references": [
        "Unity.TextMeshPro"
    ]
}

Unit test script : referencing asset script and test library

{
    "name": "Problems",
    "references": [
        "UnityEngine.TestRunner",
        "UnityEditor.TestRunner",
        "ProblemSetScripts"
    ],
    "includePlatforms": [],
    "excludePlatforms": [],
    "allowUnsafeCode": false,
    "overrideReferences": true,
    "precompiledReferences": [
        "nunit.framework.dll"
    ],
    "autoReferenced": true,
    "defineConstraints": [
        "UNITY_INCLUDE_TESTS"
    ],
    "versionDefines": [],
    "noEngineReferences": false
}

It's so weird that the compilation fails. At least we can exclude UPM from the equation.
I know you wrote in the "reproduce" that it's based off of a new project, but to confirm: Does this happen on a fresh project (No other code/asmdef in the Assets or other Unity packages)?
Sorry that this issue takes times to resolve.

And to confirm the "works on my machine", would it be possible if you sent me a copy of your project?

Sure, this issue is difficult to reproduce in new projects.
My project is not ready, but I considering it will be releases on GitHub with an MIT license, So I can share to my project file to you!
Here's temporary link.
Download
Project version : 2019.3.3f1
Step to reproduce

Open project
Select Window/UnityPSForBeginners

Follow instruction until reaching Space and Vector part page.
When click Space and Vector part, Part 1_VectorAndDirection scene will open.
If you reach Space and Vector page, close project.
Reopen project then Unity will stuck in splash screen.
Even reopen project after delete Library folder still stuck in splash screen.
If force close Unity and remove package info in manifest.json then open project will open successfully.

Sorry to get back to you at such a delayed time. 18 days later...
I don't really know the context here. Are you trying to get past a beginners guide or are you developing a beginners guide?
To progress this issue you're experiencing, here are my findings from my debugging session:

Good repro, was able to experience the issue on my local computer. Huge boost.

It's not stuck compiling. I was able to track it down to a call to UnityEditor.EditorSceneManager.OpenScene in SpaceAndVector.cs. That's where it's freezing when loading the Part 1_VectorAndDirection.unity scene (as we even could tell from the logs). It does not get past the OpenScene call at all.

What seems to be the issue is because you're loading the same scene as you already have open. Look at the struct returned from SceneManager.GetActiveScene() just before getting frozen by the OpenScene call:
.buildIndex: -1
.handle: -1216
.isDirty: False
.isLoaded: True
.isSubScene: False
.name: Part 1_VectorAndDirection
.path: Assets/ProblemAssets/Main/SpaceAndVector/Part 1_VectorAndDirection.unity
.rootCount: 5

I assume that the script can work from where it is if the scene is already loaded. Haven't tested it thoroughly. Adding something like this to SpaceAndVector.OnNavigateFrom() would suffice:
var activeScene = SceneManager.GetActiveScene();
if (activeScene.path == $"{Utils.PROBLEM_ASSETS_PATH}/Main/SpaceAndVector/Part 1_VectorAndDirection.unity") {
    OnSceneOpened(activeScene, OpenSceneMode.Single);
    return;
}

To recap: the issue seems to be that Unity freezes when calling EditorSceneManager.OpenScene on a scene that is already loaded. Certainly a bug at Unity's end, but can be easily worked around.

Why did removing the jillejr.newtonsoft.json-for-unity package help?
When you removed the Newtonsoft.Json package by removing the Packages/manifest.json file, you made the scripts UnityTutorialPS.DisplayStrings & UnityTutorialPS.ProgressData fail to compile as they now tried to reference a missing Newtonsoft.Json namespace.
They made the entire AssemblyCSharpEditor.dll assembly fail to compile and then there was no call to the EditorSceneManager.OpenScene method.

Silver lining: The Newtonsoft.Json package worked exactly as intended :P
I'm closing this as I consider this closed.

Ohh... thanks to discover my project and explain about this, even solution!
If you fine, can I put your name in this project as contributor?

Good luck with your project! It looked really good!

Thanks, I tried it and works well!
I just put your credit in my project, thanks again!


Httpx specification tests

Original PR https://github.com/kaazing/gateway/pull/237

This is not needed anymore as my PR will include the correct changes.


Fix smoothscroll cursor calculations bugs when 'number' is set

The 'smoothscroll' feature currently doesn't work well when 'number' (or signs) is set. If you scroll using <C-E> when the cursor is on the first line, the cursor would end up at a wrong position, and there's also a disconnect between the window column calculation (wincol()) and the actual buffer position (col('.')). Commands like g0 and g$ would also start to behave incorrectly.
This was a regression caused by v9.0.0746 (856c5d2bc7). That commit actually fixed this issue for Vi compatibility mode set cpo+=n, but broke the normal nocompatible case. Fixed the logic to work in both case by correctly subtracting from width2 instead of the entire window's width. This makes the calculation consistent with how the "long line wrapping" code below calculates the overflow wcol calculation.
For tests, fixed up an existing screen dump test (the old dump was actually demonstrating the incorrect behavior, but it is quite hard to tell IMO, because term_dumpload does not show the cursor position and therefore it's hard to visually inspect). Also, add new tests to confirm that the cursor position is calculated correctly and we don't have a desync between col('.') and wincol(). Don't use screen dump tests for these because they are testing specific logic instead of an end-to-end tests like screen dumps, and asserts are clearer and easier to specify this way.

If you want to reproduce the bug, simply do the following:

Make a file test.txt that have a long line, enough to wrap 4-5 screen lines.
vim --clean -c "set scrolloff=0" -c "set smoothscroll" -c "set wrap" -c "set number" test.txt
Do <C-E>, note that the cursor position is wrong.
Do g0 and g$ and note that those commands are also wrong.

See this clip for demo:

Seems like the Windows gVim tests are failing in the channel tests, but I didn't touch that part at all, so I'm not sure whether this is just some existing flake or not.


update macro to add doc comments to all api structs

update macro to add OuterAttribute - doc comment to api structs with optional attribute MetaSeq to specify exact pokeapi reference id
structs' doc comment should look like:
/// NamedAPIResource type.
///
/// [Reference](https://pokeapi.co/docs/v2#namedapiresource)

for the struct
#[pokeapi_struct]
struct NamedAPIResource<T> {
    description: String,
    url: String,
    #[serde(skip)]
    _resource_type: PhantomData<*const T>,
}

terrible idea, how did I even think of this


Add appDirectory, routes, and ignoredRouteFiles

This builds off of #1 so it looks like there's a lot more changes than there actually are.
I needed a few extra remix config options, mainly the ability to programmatically configure routes. While I was there I added ignoredRouteFiles and also converted appDir to appDirectory. I know that last one wasn't really necessary, but I figure the closer the plugin config is to remix's actual config/behavior the better off we are.

Hi @zephraph
Thanks again! This looks great too.
Let's wait for #1 to be merged and then this PR can be rebased so it's easier to see the exact changes.

Okay, I think it's in a pretty good spot. I updated the changelog too, I recommending releasing under 0.2.0. Let me know if there's anything else you'd like me to update.

@zephraph Last thing: Could you change [0.2.0] in the changelog to [Unreleased]? That way I can make a commit to bump to 0.2 together with the change in package.json and tag it.
Also, I'm having trouble running the example with "vite-plugin-remix-routes": "../.." but "vite-plugin-remix-routes": "*" (as it is currently on main) works fine.
Maybe latest will be the best alternative and will always work.
Could you update that too?
After that I'll be happy to merge :)

That would indeed be the best-case scenario. The issue is when I run the example and open localhost.
It gives me Error: useLocation() may be used only in the context of a <Router> component., which makes me believe it's a mismatch somehow between react-router versions as I don't get tthis when using */latest/etc.
It's only an issue when using the EagerLoader component so it's not in the lib but still strange.
Does this not happen at your end?

It doesn't. I don't really have the time to dig into it at the moment, so I'll just update it as you suggested.

Okay. I can always take a look at it later to use the local version again.
Let's merge. I'll release it under 0.2.0.


QueryMultiple clarification

Hello, first thanks for the great lib !!!!
At https://github.com/projectdiscovery/retryabledns/blob/87dba758f6ee52762c6a332193d073a286bb2dab/client.go#L199 it looks like we break out of QueryMultiple as soon as we have a valid answer, not merging the other answers in the final reply.
Did I miss something or is it expected behavior ?

@gboddin Nice catch! This is definitely not the expected behavior, apparently this line was erroneously added within the loop, thanks for reporting it!

Nice thanks !!! I wasn't sure or I would've made the PR.
That's gonna help ipv4/6 resolving :)


Add logging functionality for ceph

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

LGTM. :+1:

ok to test

This needs a rebase now that the ports PR has merged.

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

have to reopen the PR because I ran into some git issues. otherwise, code's been rebased and changes to ceph-audit has been made

ok to test


tonic::transport::Channel struct is not as safe to clone for parallel use

Bug Report
It seems the tonic::transport::Channel struct is not as safe to clone as advertised. I use a static to store one channel after it is established, and then for every interested user, I return a clone of the Channel. But in doing this, my several tests almost always have one or more "transport error" failures. Simply removing the sharing by clone and forcing every client to establish their own novel channel totally fixes the tests, making them super reliable.
Version
tonic 0.11.0
tonic-build v0.11.0
Platform
x64 Windows
x64 Linux
x64 macOS
Description
I have a multi-threaded application that makes a lot of gRPC calls, which tend to all go to just one or two servers. I understand that establishing a gRPC connection is expensive, so I'd rather reuse just one connection per server from many threads than to establish n connections, if that makes sense.
So as a very new rust programmer, I wrote the following grpc.rs file to make acquiring a Channel from any thread super-easy.
The problem is that my tests reveal a great deal of instability. I frequently get test failures with "transport error" even though the server is on the same machine as the gRPC client testing. Suspecting that the bug may be in the gRPC being shared for parallel use, I commented out the code in the file below related to sharing of Channel values, instead giving each client its own new one. All the test failures went away. So surely, I'm doing something wrong. Can someone identify it?
use http::Uri;
use std::{cell::RefCell, collections::HashMap, sync::Mutex};
use tonic::transport::{Channel, ClientTlsConfig};
use zcash_client_backend::proto::service::compact_tx_streamer_client::CompactTxStreamerClient;

// We'll use a MUTEX to store the shareable gRPC channels, indexed by server URI.
// gRPC channels are expensive to create, cannot be used concurrently, but cheap to clone for each user.
lazy_static! {
    static ref CHANNELS: Mutex<HashMap<Uri, RefCell<Channel>>> = Mutex::new(HashMap::new());
}

/// Return a gRPC channel for the given URI, creating one if necessary.
pub(crate) async fn get_grpc_channel(uri: Uri) -> Result<Channel, tonic::transport::Error> {
    {
        let clients = CHANNELS.lock().unwrap();
        if let Some(client) = clients.get(&uri) {
            let channel = &*client.borrow();
            return Ok(channel.clone());
        }
    }

    let tls = ClientTlsConfig::new().domain_name(uri.host().unwrap());
    let channel = Channel::builder(uri.clone())
        .tls_config(tls)?
        .connect()
        .await?;

    let mut clients = CHANNELS.lock().unwrap();
    clients.insert(uri, RefCell::new(channel.clone()));
    Ok(channel)
}

/// Gets the CompactTxStreamerClient for the given URI for use with communicating with the lightwalletd server.
pub async fn get_client(
    uri: Uri,
) -> Result<CompactTxStreamerClient<Channel>, tonic::transport::Error> {
    let channel = get_grpc_channel(uri).await?;
    Ok(CompactTxStreamerClient::new(channel))
}

Does this only fail when running tests? And are you using the tokio::test attribute on your tests? IIRC there is a limitation with sharing statics across runtimes. By default, tokio will create a new runtime for each test.

Does this only fail when running tests?

I'm not sure. I haven't recorded any failure in normal application operation, but the 9 tests I have that all call into gRPC nearly at once is probably a more controlled concurrent environment than the random access used by the application itself.
Yes, I'm using tokio::test attributes on my tests. Maybe it's relevant that I notice a far better pass rate when using cargo nextest than cargo test.

By default, tokio will create a new runtime for each test.

How does a unique runtime for each test impact this? Is the static value shared improperly in those conditions somehow?
I studied the issue you linked to and while I don't fully understand it, I applied one of the fixes proposed by the community and it appears to have worked: https://github.com/nerdcash/Nerdbank.Cryptocurrencies/pull/352
I'd love to understand it better though.