inst$macro$114  is already defined as value inst$macro$114

In 2.11.12, I'm seeing this compile error at calls to the Magnolia.gen macro, where deriving the instance requires some other implicit evidence instances to be materialized (which themselves may call some shapeless macros?)
I don't have an easy/minimal repro atm but wanted to mention in case it's clear what the problem / possible fix might be (e.g. is this a hard-coded instance-name string that is colliding with other macro-generated instances from shapeless?)

Here's a small repro:
import magnolia._
import org.hammerlab.test.Cmp

import scala.language.experimental.macros

trait TC[T]
object TC {
  type Typeclass[T] = TC[T]
  def  combine[T](ctx:   CaseClass[TC, T]): TC[T] = ???
  def dispatch[T](ctx: SealedTrait[TC, T]): TC[T] = ???
  implicit def gen[T]: TC[T] = macro Magnolia.gen[T]
}

case class A(value: Int)
case class B(ints: Array[A])

object Test {
  implicit def array[T](implicit cmp: Cmp[T]): TC[Array[T]] = ???
  TC.gen[B]  // 🚫: inst$macro$6  is already defined as value inst$macro$6
}

The problem occurs while searching for an instance of Cmp, which has a bunch of complicated shapeless-based derivations.
It would be interesting to whittle down the Cmp derivations to pinpoint the interactions more specifically, but again, I'm also hoping that the nature of the error might suggest a fix without resorting to that!

You should be able to use @debug to print the generated tree. That might help identify the problem.

Magnolia doesn't work on Scala 2.11 because of how lazy vals are ecnoded :/


Why can't I get the analysis results of this simple trace files?

At first I thought it was caused by floating-point numbers, but it's no use converting it to an integer.  I think I can at least get their minimum and maximum? And what does the output of the program mean by the way?
root@a42077a01f4b:/dig/src# time ~/miniconda3/bin/python3 -O dig.py /data/dig-1639641266712/grp0_line71.csv -log 3
settings:INFO:2021-12-16 08:29:58.863661: dig.py /data/dig-1639641266712/grp0_line71.csv -log 3
alg:INFO:analyzing '/data/dig-1639641266712/grp0_line71.csv'
alg:INFO:got 62 traces over 1 locs
infer.eqt:WARNING:NO EQTS RESULTS, reducing deg to 6
infer.eqt:WARNING:NO EQTS RESULTS, reducing deg to 5
infer.eqt:WARNING:NO EQTS RESULTS, reducing deg to 4
infer.eqt:WARNING:NO EQTS RESULTS, reducing deg to 3
infer.eqt:WARNING:NO EQTS RESULTS, reducing deg to 2
infer.eqt:WARNING:NO EQTS RESULTS, reducing deg to 1
infer.eqt:WARNING:NO EQTS RESULTS, reducing deg to 0

real    0m1.518s
user    0m1.616s
sys     0m0.047s

file content:
vtrace1; I back; I right
vtrace1; 1388.0; 220.0
vtrace1; 1419.0; 221.0
vtrace1; 1493.0; 223.0
vtrace1; 1551.0; 173.0
vtrace1; 1571.0; 173.0
vtrace1; 1650.0; 234.0
vtrace1; 1695.0; 238.0
vtrace1; 1769.0; 237.0
vtrace1; 1804.0; 236.0
vtrace1; 1842.0; 239.0
vtrace1; 1891.0; 237.0
vtrace1; 1936.0; 241.0
vtrace1; 1986.0; 239.0
vtrace1; 2037.0; 265.0
vtrace1; 2089.0; 729.0
vtrace1; 2159.0; 737.0
vtrace1; 2159.0; 737.0
vtrace1; 2253.0; 740.0
vtrace1; 2307.0; 743.0
vtrace1; 2321.0; 746.0
vtrace1; 2369.0; 746.0
vtrace1; 2390.0; 744.0
vtrace1; 2390.0; 745.0
vtrace1; 2422.0; 745.0
vtrace1; 2422.0; 745.0
vtrace1; 2446.0; 745.0
vtrace1; 2451.0; 747.0
vtrace1; 2449.0; 746.0
vtrace1; 2451.0; 752.0
vtrace1; 2451.0; 735.0
vtrace1; 2429.0; 735.0
vtrace1; 2279.0; 756.0
vtrace1; 2025.0; 766.0
vtrace1; 1623.0; 781.0
vtrace1; 1267.0; 300.0
vtrace1; 1303.0; 282.0
vtrace1; 1400.0; 238.0
vtrace1; 1465.0; 236.0
vtrace1; 1519.0; 235.0
vtrace1; 1548.0; 234.0
vtrace1; 1606.0; 231.0
vtrace1; 1606.0; 243.0
vtrace1; 1633.0; 238.0
vtrace1; 1785.0; 551.0
vtrace1; 1873.0; 539.0
vtrace1; 1905.0; 540.0
vtrace1; 1967.0; 539.0
vtrace1; 2026.0; 538.0
vtrace1; 2083.0; 536.0
vtrace1; 2169.0; 534.0
vtrace1; 2254.0; 532.0
vtrace1; 2254.0; 541.0
vtrace1; 2281.0; 541.0
vtrace1; 2302.0; 531.0
vtrace1; 2290.0; 529.0
vtrace1; 2242.0; 531.0
vtrace1; 2242.0; 530.0
vtrace1; 2242.0; 533.0
vtrace1; 2250.0; 533.0
vtrace1; 2159.0; 539.0
vtrace1; 1984.0; 545.0
vtrace1; 1743.0; 556.0
vtrace1; 1431.0; 563.0
vtrace1; 1431.0; 573.0

In short, add the flag --iupper 10000 to increase the upper/lower bound.
DIG uses 20 as the default upper/lowerbound value (in IUPPER in settings.py). This is because it is rare to have useful invariants with large and random values (e.g.,  x<= 1272).  So if you think you need much larger range, then just increase the range with the --iupper option as shown above.


Ensure ems workers are killed by their server/orchestrator pod

Fixes #20288
Previously, direct calls to ems#destroy would assume you're calling it local
to each of the ems's workers and would fail to find the pid if not local.  Additionally,
in pods, only the orchestrator pod of the worker has permissions to kill the pod
so this would fail with permission errors such as:
deployments.apps "1-xyz-event-catcher-1" is forbidden: User "abc" cannot patch resource "deployments" in API group "apps" in the namespace "123" for PATCH https:...]
The ems.destroy_queue method calls _queue_task from the AsyncDeleteMixin, which doesn't specify the server_guid or queue_name so a UI request to delete the ems COULD be initiated in a UI appliance and picked up by the same appliance, which isn't where the ems's worker processes are running, and would ultimately call kill on each workers that don't exist locally.
Now, we queue the worker's kill method for the queue_name 'miq_server' so it's handled by the server "process" in appliances or orchestrator in pods and server_guid of the worker's server as an ems's workers can be on different servers.

@carbonin I'll need help testing this in pods.  🤣
It works in appliances.

@agrare @carbonin I think this is ready to go.  I tested in an upstream appliance and in pods by monkey patching the queueing code in console, ensuring calling Ems#destroy queues a message that was targeted to and picked up successfully by the orchestrator and kills the workers with the problems mentioned above[1][2]
[1] event catchers for amazon are not killed immediately (seems like aws might be rescuing Exception or trapping signals)  [2] refresh worker for amazon with multiple ems queue names don't get killed immediately because we're only looking for a singular ems queue name.  These workers exit after the managers and ems is destroyed, so it's possible that a refresh puts the ems/managers back.

@agrare Look good to you?


Only alert to slots available once per appearance

In the event that slots are not taken within 5 minutes of an alert, another alert is sent for the same slots as they are available in the next scan.
Keeping the state of the previous scan slots can then be used to check for differences with the currently found slots to determine whether a new alert should be sent.
This would be easier to implement in the internal cron mode of my other PR without needing to maintain state outside of the application.

We could skip the login step after the initial log in if running from the internal scheduler - this would reduce the load on their servers, and make the checks quicker.

It might also help with the intermittency issue #8

sure, I was thinking that also, but will need to verify still logged in and re-login if not. Additionally the first page capturing the delivery date ranges is the first week as well, so can also reduce the number of calls there also


fix: update solution name

Description
References

Codecov Report

Merging #491 (62e7c7f) into main (21978a1) will decrease coverage by 27.15%.
Report is 177 commits behind head on main.
The diff coverage is 31.61%.

@@             Coverage Diff             @@
##             main     #491       +/-   ##
===========================================
- Coverage   83.07%   55.92%   -27.15%
===========================================
  Files         456      469       +13
  Lines       10418    10213      -205
===========================================
- Hits         8655     5712     -2943
- Misses       1438     4276     +2838
+ Partials      325      225      -100

Files
Coverage Δ

...ivedMessages/ArchivedMessageGetDocumentListener.cs
0.00% <ø> (ø)

source/Api/Common/HttpHeadersExtensions.cs
0.00% <ø> (ø)

...iddleware/Authentication/ActorForAuthentication.cs
0.00% <ø> (ø)

...ntication/Bearer/BearerAuthenticationMiddleware.cs
0.00% <ø> (ø)

...MarketActors/MarketActorAuthenticatorMiddleware.cs
0.00% <ø> (ø)

...ation/Middleware/Correlation/CorrelationContext.cs
66.66% <ø> (ø)

.../Middleware/Correlation/CorrelationIdMiddleware.cs
0.00% <ø> (ø)

...iguration/Middleware/Correlation/UserProperties.cs
0.00% <ø> (ø)

...figuration/Middleware/FunctionContextExtensions.cs
0.00% <ø> (ø)

...rce/Api/Configuration/ServiceBusMessageMetadata.cs
0.00% <ø> (ø)

... and 149 more

... and 362 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Bitfield support

Bitfield is an epic command that came out in Redis 3.2.0, and it looks like it's not supported here. Could this be added? It's incredibly useful. Here's the documentation for it.

Found out how, if anyone is interested, using client.send_command("bitfield", [arr of args]) does the trick.

This is now fixed in redis-commands. You just have to update the peer dependency.


Useless padding

Hi, thanks for the project it's really nice and feel super fast.
Whatever theme I use (tomorrow, base16) I got a padding all around my content. You can see it top and left of my prompt ❯:

Is there a way to remove it?

It's coming from the theme. But you can override the padding with the following CSS:
terminaltab > div { margin: 0 !important; }

Just paste that under Custom CSS in the settings.

It's coming from the app theme. But you can override the padding with the following CSS:
terminaltab > div { margin: 0 !important; }

Just paste that under Custom CSS in the settings.
By doing like this? It looks like doesn't work.

Hello,
In case it's still useful, I've removed these margins as follows in the last version:
tab-body div.content {
    margin: 0 !important;
}


fix: Splashscreen stretched on Android 21 & 22

Some XML tags are not supported on Android 21 and 22 (or Android 5.0 and 6.0).
Hence this stretched layout:

Thanks @g123k @M123-dev


in case if NCBI_Build column exist with missing values

This modif
is in case of the user maf file contain a NCBI_Build column but with all values missing   This is the case in Center column
for a reproducible example
maf=data.frame(Hugo_Symbol=c("TP53","EGFR","ERBB3","TP53"),
Tumor_Sample_Barcode=c("P01","P01","P02","P02"),
Chromosome=c(17,7,12,17),
Variant_Classification=rep("Missense_Mutation",4),
Variant_Type=rep("SNP",4),
Start_Position=c(3,5,8 ,9),
End_Position=c(3,5,8,9),
Reference_Allele=c("G","G","A","G"),
Tumor_Seq_Allele2=c("T","T","C","T"),
NCBI_Build=NA,
Center=NA
)
maf_obj=read.maf(maf) # note here a warning is pulled out by the data.table function : Warning: Item 2 has 5 rows but longest item has 6; recycled with remainder. maf_obj@summary  # note here the summary has false Sample number

@PoisonAlien Hello,
What do you think about it ?

@ShixiangWang @PoisonAlien  definitely yes it is the same issue

@ShixiangWang @PoisonAlien  any NEWS ?

@ZWael Sorry, I have no rights to merge PR.

@PoisonAlien Take a look at this?

Thank you @ShixiangWang and @ZWael for the fix.


scrcpy cant find adb although its installed

[x] I have read the FAQ.
[x] I have searched in existing issues.

Environment

OS: Windows 11
scrcpy version: 1.22
installation method: windows release
device model: Samsung Galaxy s21
Android version: 12

Describe the bug
this is the error i recieve when i try to run scrcpy after doing everything else. Im not sure where to go from here.
PS C:\Users(MyName)\Downloads\platform-tools_r32.0.0-windows\platform-tools\scrcpy-win64-v1.22> .\scrcpy
scrcpy 1.22 https://github.com/Genymobile/scrcpy
ERROR: CreateProcessW() error 2
ERROR: Command not found: [C:\Users(MyName)\adb-fastboot\platform-tools], [get-serialno]
ERROR: (make 'adb' accessible from your PATH or define its fullpath in the ADB environment variable)
INFO: You may download and install 'adb' from https://developer.android.com/studio/releases/platform-tools
ERROR: Could not execute "adb get-serialno"
ERROR: Could not get device serial
ERROR: Server connection failed

ERROR: Command not found: [C:\Users(MyName)\adb-fastboot\platform-tools], [get-serialno]

You set the ADB environment variable to a wrong value: it must point to the adb.exe executable itself, not its directory:
C:\Users(MyName)\adb-fastboot\platform-tools         # wrong
C:\Users(MyName)\adb-fastboot\platform-tools\adb.exe # correct

If you do not set this environment variable at all, it will just use the one bundled with the release.

ERROR: Command not found: [C:\Users(MyName)\adb-fastboot\platform-tools], [get-serialno]

You set the ADB environment variable to a wrong value: it must point to the adb.exe executable itself, not its directory:
C:\Users(MyName)\adb-fastboot\platform-tools         # wrong
C:\Users(MyName)\adb-fastboot\platform-tools\adb.exe # correct

If you do not set this environment variable at all, it will just use the one bundled with the release.

Where do I open the terminal From?

From the scrcpy folder.
Btw, from scrcpy v1.22, there is a file open_a_terminal_here.bat, double-click on it.

From the scrcpy folder.
Btw, from scrcpy v1.22, there is a file open_a_terminal_here.bat, double-click on it.

Thank you that fixed the adb issue. Now the only problem is after i run ./scrcpy it will freeze up and do nothing and not let me type anything either

Once scrcpy is started, why would you want to type something in the console? You may only pass arguments when you execute the command.

nothing pops up in terms of mirroring my phone screen. So i wasnt sure if it was running correctly or not

From the terminal, type scrcpy -Vdebug and post the whole output.

C:\Users(MyName)\Downloads\scrcpy-win64-v1.22>scrcpy -Vdebug
scrcpy 1.22 https://github.com/Genymobile/scrcpy
DEBUG: Screensaver enabled

Hmm, that's not normal at all. what is the content of your ADB environment variable?
echo %ADB℅
adb devices

Do you have the same problem with v1.21 and v1.20?

PS C:\Users\MyName\Downloads\scrcpy-win64-v1.21> .\adb get-serialno
error: more than one device/emulator
PS C:\Users\MyName\Downloads\scrcpy-win64-v1.21> .\adb get-serialno
<IP_ADDRESS>:5555
PS C:\Users\MyName\Downloads\scrcpy-win64-v1.21> .\adb devices
List of devices attached
<IP_ADDRESS>:5555 device
PS C:\Users\MyName\Downloads\scrcpy-win64-v1.21> .\scrcpy
scrcpy 1.21 https://github.com/Genymobile/scrcpy
< waiting for any device >

"C:\Users\MyName\Downloads\platform-tools_r32.0.0-windows\platform-tools\fastboot.exe""C:\Users\MyName\Downloads\scrcpy-win64-v1.22\scrcpy.exe""C:\Users\MyName\Downloads\scrcpy-win64-v1.22\adb.exe"

This is totally wrong.
Either set it to: C:\Users\MyName\Downloads\scrcpy-win64-v1.22\adb.exe
But better, just remove this environment variable.


Select next and previous problem

I've found a bug in VSCode. In first, I'm using MacOSX.
When I press Command+U to go back to the previous selection (or point of a snippet) and I press Command+D again to select the next match (or point of a snippet), the VSCode takes me to the point AFTER of what I expect.
IN EXAMPLE: we have the points 1, 2, 3, 4, 5 of a snippet. I'm currently in the 2. I press Command+U to back to the 1, so I press Command+D to match the next (and I expect to go to 2 again) and it takes me to the 3 (it continues increasing erroneous).
What we could do to solve that?

@pedrov-sh Can you provide more simple steps (reduce the level of abstraction) so I can try to reproduce ?


feat: add TaskID support to SourceStringsListOptions and update related tests

Closes #70

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 98.01%. Comparing base (a653f40) to head (ef3389a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #79      +/-   ##
==========================================
+ Coverage   98.01%   98.01%   +0.01%
==========================================
  Files          66       66
  Lines        3815     3818       +3
==========================================
+ Hits         3739     3742       +3
  Misses         52       52
  Partials       24       24

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


calendar() display with time OR without time

Sometimes I want to display the calendar date without the time, such as 'Today' instead of 'Today at 12:00 AM'
I realize you can edit the localization strings, but then this prevents the possibility of also occasionally using calendar() to display with the time
I think there should be an option, or a sibling function to be able to do this

So it had been implemented eventually?

Is this still not implemented?

Do we have a solution as of now?
It creates an inconsistency as it does show time for recent days and just gets rid of the time for distant past/future dates.
Has anybody found a flag that can be set for including the time for distant dates as well.

Found a fix for Ember here:
https://github.com/stefanpenner/ember-moment/issues/176
The PR for the same is:
https://github.com/stefanpenner/ember-moment/pull/179/commits/6d03b3f092a3f5d9aea16e83e56eaacc008b3b4c

I've created a custom wrapper function around the calendar() , for 37 languages that I use here. Hope it helps.


Fix deletion in Open Recent

Description
This PR is to fix bug mentioned in #404

Related Issue
#404
#246

Checklist

[x] I read and understood the contributing guide as well as the code of conduct
[x] My changes generate no new warnings
[x] My code builds and runs on my machine
[x] Review requested

Good work :)


False positive unused import when referencing extension function and import is only used in KDoc

Steps to Reproduce
Run ktlint on the following file (with coroutines on the classpath):
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.onStart

/**
 * [Flow.onStart]
 */
class Test

Expected Behavior
Ktlint should pass
Observed Behavior
Ktlint fails with Unused import

Your Environment

Version of ktlint used: 0.50.0 (I realise it's not the latest version, but detekt does not include later version and I don't see anything related in the changelog of the new versions)
Name and version (or code for custom task) of integration used (Gradle plugin, Maven plugin, command line, custom Gradle task): detekt 1.23.1
Version of Gradle used (if applicable): 8.4
Operating System and version: Linux 6.5.5-arch1-1

This appears to be a regression of the #1282 (I decided to create a new issue, because that one is very old)

Ktlint has to be conservative with removing imports. Sometimes there is just not enough information to decide whether imports can or can not be removed safely. Removing imports too eagerly results in code which can not be compiled.
In example above, it is clear that no compilation problem will occur when imports are removed. But after removal of the imports the links in the KDocs will no longer be resolved. See screenshots below.
With both imports, the links to Flow and onStart can be clicked in IntelliJ IDEA:

Removal of import onStart makes the onStart link not clickable:

Removal of import Flow makes both links not clickable:

So both imports in this example are needed for the KDoc (only).


Deprecated instanciate in favor of instantiation (correct grammatical…

Deprecated instanciate in favor of instantiation (correct grammatical form). Same for instanciation which needs to be replaced by instantiation.
This commit fixes #97

Waiting for https://github.com/pharo-project/pharo/issues/14697 analysis.

Deprecated methods should call directly the new methods. This is not useful to conserve each old implementation.
For example :

MolComponentImpl classSide >> instanciate

self deprecated: 'Use instantiate' transformWith: '`@receiver instanciate' -> '`@receiver instantiate'.

^ self instantiate

@Eliott-Guevel have you seen my review ?

I've just made the adapted modifications

Hum this PR is very strange because its appears that all the code of molecule have been modified !

I have the explanation :
I just wanted to let people who are using Pharo12 that they might notice some changes while exporting their code to github now.

We are introducing a TonelV3 format. The goals are to:
- Follow the spec that was agreed upon because currently we have symbols instead of strings in some places and that made it incompatible with Gemstone or Vast
- Add missing informations. This is because in Pharo we have packages and tags but the only thing exported is the category. So reading the categories was ambiguous and relied on some heuristic. Loading the same class in two pharo image could load the class in different packages depending on the state of the image.
- We want to add meta data for new features (not yet done). For example there is a new feature to rename a class and keep the old name as a deprecated alias for a while. We would like to be able to declare those info in the fluid class definition and in the Tonel format.

The new format still exports the category (but there is a setting to not export it) to stay backward compatible for now.
Using the Tonel paser to read classes that were exported before Pharo 12 can have some difficulties to manage the tags, but the TonelReader class that is used by Iceberg knows how to resolve all of those problem to ensure the classes are in the right packages and in the right classes!

So don't use Pharo 12 for this work. Can you re send your modifications with P11 ? Thanks.

I've made the modifications with Pharo 11, it should now only modify the relevant files


jQuery 3+ compatablility: Set instance.selector

In jQuery 3+, within yadcf.init() the DataTables instance, referenced by the local instance variable, doesn't have a selector property. It is undefined.
Recreating the selector property and setting it to the local tableSelector variable allows yadcf to be jQuery 3+ compatable.
Tested with jQuery 3.1.0

Thanks!


Top level harness for sample data generation

Use the interface SampleDataGenerator - example in EntityStatisticGenerator
Refer to DataGenerator as a starting point

Implemented some time ago, see waltz-jobs\...\LoadAll


Update to Gulp 4

Since we recently received some security warnings caused by gulp-iconfont related modules like this one, I updated this module to Gulp 4 and replaced some other outdated/deprecated npm modules by maintained alternatives.
Fixes #6

Any plan this will be merged soon?

Is there any problem to merge the code that @hangy has already made?


MultiBucketAggregate is missing

Elastic.Clients.Elasticsearch version: 8.11.0
Elasticsearch version: 8.2.2
.NET runtime version: net8.0
Operating system version: Windows 11
Description of the problem including expected versus actual behavior:
MultiBucketAggregate exists in NEST, but is missing in the new library. Is this replaced by something else? Or are you planning to bring it back? Is yes, are you planning to do that soon? If not, are there any guidelines on how to submit a PR for it?
Steps to reproduce:
Expected behavior
Provide ConnectionSettings (if relevant):
Provide DebugInformation (if relevant):

Hi @gpetrou ! Not all aggregations and aggregates are currently implemented in the v8.* client. The plan is to implement all missing  types and endpoints (including this aggregation) until end of Q1 2024 if everything goes fine. Most parts of the client are auto-generated from our elastic-specification, but the code generator is closed source for internal reasons which means you won't be able to create a PR.

Hi @matteocalisti! Thanks for the kind way of asking. Currently it's looking good that at least a big chunk of missing endpoints and features can be released around the end of Q1/2024 (+/-). My plan is to create an alpha/beta version first which will be publically available for testing. I expect it to take some additional time to get rid of some smaller bugs and rough edges, but that will definitely be an incremental process with a lot more frequent releases and not - like this time - a "all or nothing" situation.

@gpetrou I had the time to check what the MultiBucketAggregate in NEST is about. This is just a base class used for aggregates that return multiple buckets. In the v8 client, you can still access the Buckets property on the returned aggregates directly (check AdjacencyMatrixAggregate for example).


luarocks install loadcaffe:  Error: No results matching query were found

When trying to install loadcaffe I get the following error:
luarocks install loadcaffe

Error: No results matching query were found.

install torch http://torch.ch
same as https://github.com/szagoruyko/loadcaffe/issues/48 and many other issues, sigh

Sorry, I should have looked better.
But if there are so many having this issue, the readme should be updated…

@timpulver thanks for suggestion. I did that recently, the first 3 lines in readme say install torch7 in bold :)


Edit advisors

Coverage decreased (-0.003%) to 91.951% when pulling e074851e10cff82e5a030887420d26e8994bf640 on edit-advisors into 73d1764ee783b8dd113dd4defac5c32132b8c41b on staging.


[Automated] Upgrade to latest dependencies

Produced via:
./hack/update-deps.sh --upgrade
./hack/update-codegen.sh

/cc we don't use Prow
/assign we don't use Prow

Codecov Report

Merging #91 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #91   +/-   ##
=======================================
  Coverage   96.18%   96.18%
=======================================
  Files          16       16
  Lines         446      446
=======================================
  Hits          429      429
  Misses         15       15
  Partials        2        2

Continue to review full report at Codecov.

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


Can't sign in to google in app

My login timed out, so I tried to log back in. Error given is:

This browser or app may not be secure. Learn more
Try using a different browser. If you’re already using a supported browser, you can refresh your screen and try again to sign in."

I get the same thing after upgrading from 1.5.2 and clearing out my Application Support folder.  Message on signin after typing email is:

Only version 1.5.7 and 1.5.8-beta work right now.
Google changed part of the protocol which made all previous versions dead.


Rev'ed Grpc.Net.Client PackageReference version for Dapr dotnet-sdk

Description
Updated the version of Grpc.Net.Client used by Dapr dotnet SDK.
Issue reference
This is an aggregation of the following PRs already known to the Dapr dotnet SDK team:
https://github.com/dapr/dotnet-sdk/pull/1123
https://github.com/dapr/dotnet-sdk/pull/1122
https://github.com/dapr/dotnet-sdk/pull/1121
Please reference the issue this PR will close: #[issue number]
See above
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Extended the documentation

@MonkeyTennis - Can you fix your DCO? git commit --am -s should do it.

@halspang done I think although it is my first DCO!


Fix some creative spellings of container

As the title suggests.

Retest this please

merging as the same failing integration tests are failing on all PRs. We're looking into this right now.


Vim language literal quotes not highlighted correctly.

(Original issue 957 created by andyops on 2014-03-05T13:57:00.881804+00:00)
Vim language literal strings, which are strings defined using single quotes; do not allow for escaping using the \ character. Pygments is incorrectly interpreting the backslash as an escape character, which when adjacent to the closing quote, escapes the quotation mark and ruins syntax highlighting.
Example
http://pygments.org/demo/280627/
See Also
https://github.com/github/linguist/issues/977

(Original issue 957 last updated on 2014-03-17T06:42:21.566418+00:00)
(Issue automaticaly closed due to status in Bitbucket: resolved)

(Original comment by andyops on 2014-03-17T06:42:21.596874+00:00)
Resolved in pull request #298.


Create chat room for design discussion (etc)?

If you also think this might help cooperation. Communicating only through issues is not the best.
For example I just got a small idea I wanted to share.
Suggestion: Gitter or Zulip chat.

I'm not active on those, but if it helps, then I can create a new server in Discord (where I'm active).

Good for me!

Here's the invite link for the new server in Discord.
Hey @oli-cosmian @sfisol @aeroaks @hindenbug, apologies for spamming your inboxes, but y'all have contributed to paperclip multiple times. Thank you for your contributions. If you do wish to contribute at some point and want to discuss about some implementation, then feel free to poke me in this Discord server (where I'm mostly active).


Add http method to output

Great project :)
This PR prepends the http method to the requested URL.

Sweet, thanks!


Compiler segfault when using generics

trait X[A: X[A] box]
  fun apply[B: X[B] box](a: B) =>
    None

  fun f() =>
    apply[X[A]](this)

class C is X[C box]

I was looking at @Praetonus's F-Bounded Polymorphism issue and tweaked the input a bit and hit a segfault. I'm not sure if this is related to other bugs with generics that I can see on the issues list so thought I would raise it just in case.

This is an infinite loop in the subtyping code. The compiler is stuck trying to determine whether X[A] box is a subtype of X[A] ref. This happens when checking the generic constraints of the call to X.apply in X.f.

This looks like a duplicate of #2399. I'm going to leave both issues open since the code example here is simpler.


Touch Support on mobile devices - Zoom Option

The script work well to the most mobile devices, swipe it's ok, but when some one try to zoom the image the script recognizes the action as a swipe and not as a zoom....
Some one has any idea to implement this issue ?
cheers !

Hey @mod667, picturefill doesn't concern itself with gestures of any kind. Are you using another library that may be causing the issue?


Colorful histograms

Pull Request Description
Fixed coloring of histograms (now it is applied basing on y-axis, not x-axis) and added color legend to the side of histogram.
Resolves #2940
Before: see screenshot in #2940
After:

Important Notes
The position and size of the color legend might not be ideal. It was choosen because of easier implementation and no need to move other elements of the histogram.
Your suggestions are always welcome.
Checklist
Please include the following checklist in your PR:

[x] The documentation has been updated if necessary. (Not necessary)
[x] All code conforms to the Scala, Java, and Rust style guides.
[x] All documentation and configuration conforms to the markdown and YAML style guides.
[x] All code has been tested where possible.

The code and the implementation look good to me. Looking at the screenshots, I do wonder whether from an aesthetical and cleanliness standpoint we might still be better off to use a histogram without secondary colour and instead use a single colour for all bars. What do you think @vitvakatu @wdanilo ?

Colors might be more useful in a more complex diagrams, I think the ideal solution would be to allow user to change the colorscheme in a future (wouldn't be so hard to implement). Not sure what I like more.

TBH I realy like the fact that we are using colors here – it is way easier for the brain to consume it. I agree Michael, that the color palette may not be best here, but we will adjust it down the line when designing the GUI. I'd leave it.

I'm wondering why CI fails – the docs are changed, does anyone knows why it happens? @mwu-tow ?

I'm wondering why CI fails – the docs are changed, does anyone knows why it happens? @mwu-tow ?

CI fails because it can't access the organization secrets for signing the packages.
I think it is because this PR was created against an out-of-organization fork repository, rather than a local branch.

🤷🏻♂ I was following instructions: https://github.com/enso-org/enso/blob/develop/docs/CONTRIBUTING.md#pull-requests

Enso uses the 'fork-and-pull' model of development.

🤷🏻♂ I was following instructions: https://github.com/enso-org/enso/blob/develop/docs/CONTRIBUTING.md#pull-requests

Enso uses the 'fork-and-pull' model of development.

 GitHub**enso/CONTRIBUTING.md at develop · enso-org/enso**Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.

I think that guide is meant for outside contributors, not employees. Still, CI should be adjusted to just build unsigned packages when secrets.
Secrets being unavailable is apparently by-desing: https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow

I'll try to recreate PR using internal branch tomorrow then

Secrets being unavailable is apparently by-desing:

And intended from our side, as we don't want outside people to be able to build signed binaries. But you are right that there should be a fallback. Or maybe PRs should just not sign the builds at all to avoid this, and instead we do that only for release builds.

Superseded by https://github.com/enso-org/enso/pull/3153


Add red encoding for opus only publisher

With this PR, livekit can forward red encodings for opus upstream. For red encoding upstream to opus downstream, can detect packet loss and recover it from the red encoding blocks(not implement yet).

Awesome stuff @cnderrauber .
One thing I was thinking is not doing checks in 'forwardRTP' function. Can we start different goroutines in SFU.Receiver based on receiver type to avoid check in the per packet path.

Agree the type check and cast looks not good after we have more than one auxiliary receivers. But if we forwarding it at different goroutines, the forwardRTP still need to wait other forward goroutines complete packet spread to make forward to all downtracks synchronize. Maybe callback function is a way, will try that.


[Hugging Face Hub] All models to be loaded from Hugging Face Hub

Before submitting

[ ] Was this discussed/approved via a Github issue? (no need for typos, doc improvements)
[ ] Did you read the contributor guideline?
[ ] Did you make sure to update the docs?
[ ] Did you write any new necessary tests?

As discussed offline with @kahne this is a proposal of how an integration with the :hugs: Hub could look like.
The main purpose of this integration is to be able to better demo fairseq models on the :hugs: Hub for inference.
I.e. so that fairseqs speech synthesis models could be easily loaded from the :hugs: hub.
This is just a rough first draft and I would be very happy any suggestions how this PR could be improved :-)
PR review
@kahne

As an example:
from fairseq.checkpoint_utils import load_model_ensemble_and_task_from_hf

model = load_model_ensemble_and_task_from_hf("patrickvonplaten/fairseq-fastspeech2")

@kahne - this can be closed as it's already merged no? :-)


native-comp: Add magit/git-commit/orgit to blackl.

In their current state, the following packages result in a stuck doom
build "Waiting for N async jobs..." situation when using the feature/native-comp emacs branch:

magit
git-commit
orgit

This PR adds those packages to the native-comp blacklist until the issues are
resolved.
Signed-off-by: Steven Lang<EMAIL_ADDRESS>Resolves #4644, Resolves #4517, Resolves #4590

What commit of native-comp are you on? I am on the latest and do not see these issues. I'm hesitant to accept these until I am certain of the cause.

Woops, yeah I was using this Fedora copr repo which seems to be about 12 days behind. I've now built native-comp from source with the latest commit and the issue is gone. Thanks for double checking!

Which commit? 31416495ad9b2c84473f72ad99e2adc87dd66e5a is what I'm seeing as the latest and it fails on every bin/doom operation

I'm on 31416495ad as well. What do you mean by "it fails on every bin/doom operation"? What's the output?

FWIW this is what I had to add to finish compiling,
                (concat local-dir-re ".*/magit\\.el\\'")
                (concat local-dir-re ".*/forge.*\\.el\\'")
                (concat local-dir-re ".*/treemacs-magit\\.el\\'")
                (concat local-dir-re ".*/magit-gitflow\\.el\\'")
                (concat local-dir-re ".*/magit-todos\\.el\\'")
                (concat local-dir-re ".*/evil-collection-magit\\.el\\'")
                (concat local-dir-re ".*/git-commit\\.el\\'")
                (concat local-dir-re ".*/orgit\\.el\\'")
                (concat local-dir-re ".*/skewer-bower\\.el\\'")

Please report this upstream if this issue is resurfacing. This seems like a bug.

I'm having this issue with native-comp on macos too...

I too had this issue, running doom sync on an M1 macbook air with the native-comp version of emacs-plus@28 installed via homebrew
It got stuck on Natively compiling 2 files...
I grepped the output of ps for emacs processes running and got the following two entries:
<EMAIL_ADDRESS>--batch -l /var/folders/5x/hdl5xyqn48gbr0fwdp76n9fw0000gn/T/emacs-async-comp-evil-collection-vterm-T0tnU5.el
and
<EMAIL_ADDRESS>--batch -l /var/folders/5x/hdl5xyqn48gbr0fwdp76n9fw0000gn/T/emacs-async-comp-with-editor-ZZ5i6V.el
I added the packages recommended by @tecosaur to the native-comp blacklist in core.el and that seemed to fix things for me
Tested with doom-emacs commit 68bee5043ceae9f9715c87dba1f943b3b8388df9

@quarkw I am using the same commit and also added the lines recommended by @tecosaur to the blacklist, but I' still stuck with the same .el files:
/usr/local/bin/emacs --batch -l /tmp/emacs-async-comp-with-editor-JXdsM1.el   /usr/local/bin/emacs --batch -l /tmp/emacs-async-comp-evil-collection-vterm-A9XOdp.el
i'm running doom build after inserting the lines in ~/.emacs.d/core/core.el. Any ideas what I'm doing wrong?

@quarkw I am using the same commit and also added the lines recommended by @tecosaur to the blacklist, but I' still stuck with the same .el files:
/usr/local/bin/emacs --batch -l /tmp/emacs-async-comp-with-editor-JXdsM1.el /usr/local/bin/emacs --batch -l /tmp/emacs-async-comp-evil-collection-vterm-A9XOdp.el
i'm running doom build after inserting the lines in ~/.emacs.d/core/core.el. Any ideas what I'm doing wrong?

😮
Maybe I misdiagnosed my issue, and fixed my issue another way by accident.
To be sure, you placed the lines at the right place in core.el?

That's exactly where I placed it. I don't know how to troubleshoot further from here.

Did you try doom sync instead of doom build?

git diff:
diff --git a/core/core.el b/core/core.el
index 7d4b04f..43f561a 100644
--- a/core/core.el
+++ b/core/core.el
@@ -189,6 +189,18 @@ users).")
                 (concat local-dir-re ".*/evil-collection-vterm\\.el\\'")
                 (concat local-dir-re ".*/with-editor\\.el\\'")
                 ;; https://github.com/nnicandro/emacs-jupyter/issues/297
+
+               ;; custom
+                (concat local-dir-re ".*/magit\\.el\\'")
+                (concat local-dir-re ".*/forge.*\\.el\\'")
+                (concat local-dir-re ".*/treemacs-magit\\.el\\'")
+                (concat local-dir-re ".*/magit-gitflow\\.el\\'")
+                (concat local-dir-re ".*/magit-todos\\.el\\'")
+                (concat local-dir-re ".*/evil-collection-magit\\.el\\'")
+                (concat local-dir-re ".*/git-commit\\.el\\'")
+                (concat local-dir-re ".*/orgit\\.el\\'")
+                (concat local-dir-re ".*/skewer-bower\\.el\\'")
+
                 (concat local-dir-re ".*/jupyter-channel\\.el\\'")))))

I have to cancel doom build to do doom sync. doom sync works fine
> Executing 'doom sync' 2021-05-31 15:40:34
  > Synchronizing your config with Doom Emacs...
    > Regenerating envvars file at "~/.emacs.d/.local/env"
      ✓ Successfully generated "~/.emacs.d/.local/env"
    > Installing packages...
      - No packages need to be installed
    > (Re)building packages...
      - No packages need rebuilding
    > Purging orphaned packages (for the emperor)...
      - No builds to purge
      - Skipping elpa packages
      - Skipping repos
      - Skipping regrafting
      - Skipping native bytecode
    > (Re)generating autoloads file...
      > Generating autoloads file...
      > Byte-compiling autoloads file...
      ✓ Generated .local/autoloads.28.0.50.elc
    - Restart Emacs or use 'M-x doom/reload' for changes to take effect
  ✓ Finished in 2.5661s

Sorry, I'm a total beginner to lisp and elisp, so this may not even be correct, but it may be worth trying to change .*/evil-collection-vterm\\.el to .*/.*evil-collection-vterm\\.el and rerunning doom build
Same for any other packages that you're having build issues with

Same here. So thank you for your suggestion ;-) will report back

And maybe also adding .* right before \\.el

No difference. Also, reading through similar issues on here, the statements present in the file SHOULD already be sufficient.

Solved.
Buildings emacs:
$ ./autogen.sh
$ ./configure --with-native-compilation
$ make -j$(nproc)
# make distclean install

Installing doom
$ git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
$ ~/.emacs.d/bin/doom install

Now the build process gets stuck for the last two files...
Use output of "ps aux | grep emacs" to get something similar to the next line, and run it in your shell. It asks if vterm should be compiled. Compile it!
$ /usr/local/bin/emacs --batch -l /tmp/emacs-async-comp-with-editor-6r25Ly.el

Tried doom sync and doom build, but some files were missing, so used doom install again.
Done


space -> WSOD

Hi
archive-custom_type.php (my template file in theme):
<?php
$context = Timber::get_context();
Timber::render( [ 'archive-custom_type.twig ' ], $context );

Give ^^^ white screen error.
The error reason: see space after the twig template filename.

<?php
$context = Timber::get_context();
Timber::render( [ 'archive-custom_type.twig' ], $context );

Works!

I spend a lot of time to find the error. There was nothing in error log.
I suggest using trim() function in render function to remove space around template's filenames.
Thanks
Adam

Hi @arunaseva thanks for the heads-up on this. Like you said, seems like a pretty quick fix with a well-placed trim() — interested in submitting a PR and living on in infamy?


cmake:implement CMake build of xtensa arch

Summary
implement CMake build of xtensa arch
Impact
new features and forward compatibility
Testing
configure:cmake -B build -DBOARD_CONFIG=iss-hifi4:nsh
build:cmake --build build
run:xt-run build/nuttx

[Experimental Bot, please feedback here]
No, this PR description does not fully meet the NuttX requirements. While it provides some information, it lacks crucial details in almost every section.  Here's a breakdown of what's missing and how it can be improved:
Summary:

Missing:  The summary is far too brief. It states what was done, but not why.  What problem does this CMake build system solve?  Is the current build system broken, inadequate, or is this simply adding a more modern option?  How does the CMake build system work (at a high level)? Which parts of the code were modified to implement this (e.g., the configuration system, Makefiles replaced, etc.)?

Impact:

Insufficient Detail: Saying "new features and forward compatibility" is vague.  Specifically:

New Feature: Explicitly state that "CMake build support is added for the Xtensa architecture."
Forward Compatibility:  How does this improve forward compatibility?  With newer CMake versions? With other build systems? Explain clearly.

Missing Impact Assessments:  The PR description omits assessment for most impact categories. It needs to address each point explicitly, even if the answer is "NO." For example:

User Impact:  Will users need to change how they build NuttX for Xtensa?  If so, provide clear instructions.
Build Impact: The build process definitely changes. Describe how.  Are existing Makefiles affected? Are there new configuration options?
Hardware Impact:  Does this affect any specific Xtensa chips or boards?  If not, explicitly state "NO."
Documentation Impact:  Does documentation need updating?  If so, has it been updated in the PR, or is a separate documentation PR planned?
Security Impact:  Even if the answer is "NO," explicitly state it.
Backward Compatibility: Does this break the existing build system for Xtensa? If not, state "NO."
Anything else to consider: Are there any known limitations of the CMake build?

Testing:

Insufficient Detail: The provided commands are insufficient.

Build Host:  Specify the OS, CPU architecture, and compiler used for testing. (e.g., "Linux x86_64, GCC 12.2").
Target:  Be more specific. Instead of "xt-run," indicate the specific Xtensa target and configuration being tested (e.g., "Espressif ESP32 DevKitC, default configuration").

Missing Logs: The template clearly requests "Testing logs before change" and "Testing logs after change." These are essential for reviewers to understand what functionality was tested and verify that the changes work as intended.  Include relevant output showing successful builds and execution (even if it's just a simple "Hello, World").  If there were build errors before the change, show those too.

Example of an Improved Summary:
This PR implements CMake as an alternative build system for the Xtensa architecture. The current Makefile-based build system, while functional, can be complex and difficult to extend.  CMake offers a more modern, cross-platform build system that simplifies the build process, improves maintainability, and enables easier integration with other tools.  This implementation involves adding CMakeLists.txt files to the Xtensa architecture directory and modifying the configuration system to support CMake generation.  This addresses [NuttX Issue #123](replace with actual issue number if applicable).
By providing these missing details, the PR will be much easier for reviewers to understand, evaluate, and ultimately merge.  A complete and thorough PR description greatly improves the chances of a successful contribution.

@xuxin930 iss-hifi4 is not in mainline, please test in some board existing in mainline

let's add chip/board in the new pr.


updated form description field. added custom logic and styling

Updating App description text area. Limit to 200 characters, but allow the input of 200+. Disable Next button if more than 200 characters.
Reference Issues or PRs
https://gitlab.jatic.net/jatic/team-metrostar/t-e-platform/-/issues/523

What does this implement/fix?
Put a x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features not to work as expected)
[ ] Documentation Update
[X] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[X] Did you test the pull request locally?
[ ] Did you add new tests?

Documentation

Access-centered content checklist
Text styling

[X] The content is written with plain language (where relevant).
[] If there are headers, they use the proper header tags (with only one level-one header: H1 or # in markdown).
[ ] All links describe where they link to (for example, check the Nebari website).
[X] This content adheres to the Nebari style guides.

Non-text content

[ ] All content is represented as text (for example, images need alt text, and videos need captions or descriptive transcripts).
[ ] If there are emojis, there are not more than three in a row.
[ ] Don't use flashing GIFs or videos.
[ ] If the content were to be read as plain text, it still makes sense, and no information is missing.

Any other comments?

@kildre can you merge main and see if that fixes CI issues? I just merged a PR for the same.

@aktech I'll do that.

The test failures are genuine failures. The JupyterHub doesn't loads:

Console errors (Its unable to find static files, as you have moved them):


how to run mh after install

Hello, first of all thanks for this release!
I'm using Windows 10 x64 and I would like to know how to run the maphack after the install is done with node.js/yarn.

Howdy!
This repo is very much still a work in progress, The d2:r memory reader/map generator currently constantly crashes and needs a fair bit of setup to get working.
This codebase will currently only run under linux and will not run on windows computers. The memory reader part is currently using linux's /proc/$PID/mem  as a method of reading the memory of another process which doesnt exist in windows.


Issue with manifest file

There is some issue while adding this library to project.
I have multiple libraries added to my own project. Now, when I add this library, I show manifest merger error.
This might be because the library using some provider that conflict to existing providers (Not sure).
Please look at this issue and resolved it.
Thanks.

I can't seem to reproduce this issue. When I create a whole new project and include the library in it, everything works. Is there any error message you can provide me ?


Add-to-app on iOS: Error in PathProvider ( getApplicationDocumentsDirectory() )

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce

Build an add to app flutter module
Create a framework from that module for IOS
Add that framework to Native IOS application
Run the IOS application, object box will not working
It is creating the following error

Expected results
It should provide a valid document path for the objectbox to store files.
Actual results
unhandled Exception: PlatformException(channel-error, Unable to establish connection on channel., null, null)
#0      PathProviderApi.getDirectoryPath (package:path_provider_foundation/messages.g.dart:42)

#1      getApplicationDocumentsDirectory (package:path_provider/path_provider.dart:121)

#2      ObjectBox.create (package:flutter_lib/objectBox/ObjectBoxManager.dart:28)
Code sample
Code sample
  static Future<ObjectBox> create() async {
    if (_instance != null) return _instance!;

    /// store path
    /// Issue is here while getApplicationDocumentsDirectory.
    final docsDir = await getApplicationDocumentsDirectory();
    var storePath = p.join(docsDir.path, "some-db");

    /// instantiation of store
    if (Store.isOpen(storePath)) {
      final store = Store.attach(getObjectBoxModel(), storePath);
      _instance = ObjectBox._create(store);
    } else {
      final store = await openStore(directory: storePath);
      _instance = ObjectBox._create(store);
    }

    return _instance!;
  }

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
_2023-08-17 17:41:59.439466+0530 ***********[1927:1023140] flutter: ObjectBoxIssue: message: [0]
2023-08-17 17:41:59.442221+0530 ***********[1927:1023140] flutter: Flutter: setThemeMode-> Brightness.light
2023-08-17 17:41:59.446920+0530 ***********[1927:1023140] flutter: Flutter: setThemeMode-> Brightness.light
2023-08-17 17:41:59.447347+0530 ***********[1927:1023140] flutter: ObjectBoxIssue: getDirectoryPath: arg_type: DirectoryType.applicationDocuments
2023-08-17 17:41:59.447382+0530 ***********[1927:1023140] flutter: ObjectBoxIssue: message: [0]
2023-08-17 17:41:59.447824+0530 ***********[1927:1022736] Flutter : response ACTION_DEVICE_INFO - nil)
2023-08-17 17:41:59.448239+0530 ***********[1927:1023140] flutter: ObjectBoxIssue: getDirectoryPath: replyList: null
2023-08-17 17:41:59.449447+0530 ***********[1927:1023140] [VERBOSE-2:dart_vm_initializer.cc(41)] Unhandled Exception: PlatformException(channel-error, Unable to establish connection on channel., null, null)
#0      PathProviderApi.getDirectoryPath (package:path_provider_foundation/messages.g.dart:42)
<asynchronous suspension>
#1      getApplicationDocumentsDirectory (package:path_provider/path_provider.dart:121)
<asynchronous suspension>
#2      ObjectBox.create (package:flutter_lib/objectBox/ObjectBoxManager.dart:28)
<asynchronous suspension>
#3      initObjectBox (package:flutter_lib/main.dart:66)
<asynchronous suspension>
Push Token:579793f10d2722900611b45ba7ad8ae47712a9af907edbc08ad8402edfe47ae6
2023-08-17 17:41:59.452891+0530 ***********[1927:1023140] flutter: ObjectBoxIssue: getDirectoryPath: replyList: null
2023-08-17 17:41:59.453239+0530 ***********[1927:1023140] [VERBOSE-2:dart_vm_initializer.cc(41)] Unhandled Exception: PlatformException(channel-error, Unable to establish connection on channel., null, null)
#0      PathProviderApi.getDirectoryPath (package:path_provider_foundation/messages.g.dart:42)
<asynchronous suspension>
#1      getApplicationDocumentsDirectory (package:path_provider/path_provider.dart:121)
<asynchronous suspension>
#2      ObjectBox.create (package:flutter_lib/objectBox/ObjectBoxManager.dart:28)
<asynchronous suspension>
#3      initObjectBox (package:flutter_lib/main.dart:66)
<asynchronous suspension>
#4      getDlManager (package:flutter_lib/main.dart:52)
<asynchronous suspension>
#5      _ApplicationState.initEventManager (package:flutter_lib/main.dart:144)
<asynchronous suspension>_

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.13.0, on macOS 13.4.1 22F770820d darwin-arm64, locale en-IN)
• Flutter version 3.13.0 on channel stable at /Users/******/*****/FlutterDev/sdk/flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision efbf63d9c6 (35 hours ago), 2023-08-15 21:05:06 -0500
• Engine revision 1ac611c64e
• Dart version 3.1.0
• DevTools version 2.25.0

[!] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
• Android SDK at /Users/kundankumar/Library/Android/sdk
✗ cmdline-tools component is missing
Run path/to/sdkmanager --install "cmdline-tools;latest"
See https://developer.android.com/studio/command-line for more details.
✗ Android license status unknown.
Run flutter doctor --android-licenses to accept the SDK licenses.
See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Build 14E300c
• CocoaPods version 1.12.1

[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.1)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-8887301)

[✓] VS Code (version 1.80.1)
• VS Code at /Applications/Visual Studio Code.app/Contents
• Flutter extension version 3.70.0

[✓] Connected device (2 available)
• macOS (desktop) • macos • darwin-arm64 • macOS 13.4.1 22F770820d darwin-arm64
• Chrome (web) • chrome • web-javascript • Google Chrome 115.0.5790.170

[✓] Network resources
• All expected network resources are available.

! Doctor found issues in 1 category.

#132483 The same as my issue, still no solution/suggestion yet

Hi @kundankuldeep. Thanks for filing this. There seems to be an already open issue describing this exact case, kindly upvote, comment and follow up on the issue for updates from the team.
Closing this as a duplicate of https://github.com/flutter/flutter/issues/132483.
Thank you!

#132483 The same as my issue, still no solution/suggestion yet

Thanks @farhantandia, hope we get solution for this soon.


Installes as version 0.0.0? How to install correctly

I am installing trove-classifiers as dependency for poetry.
However: trove-classifiers is not found after installation (every other package I tried is found).
What puzzles me, is the version 0.0.0
This is python 3.12.2 for Linux x86_64 amd
ERROR: Could not find a version that satisfies the requirement trove-classifiers>=2022.5.19 (from poetry) (from versions: none)
ERROR: No matching distribution found for trove-classifiers>=2022.5.19

Processing /home/python/trove-classifiers/trove-classifiers-2023.11.29.tar.gz

Running command Preparing metadata (pyproject.toml)
  /pkg/python/x86_64-pc-linux-gnu/lib/python3.12/site-packages/setuptools/_distutils/dist.py:266: UserWarning: Unknown distribution option: 'use_calver'
    warnings.warn(msg)
  running dist_info
  creating /tmp/pip-modern-metadata-rw8t16dd/trove_classifiers.egg-info
  writing /tmp/pip-modern-metadata-rw8t16dd/trove_classifiers.egg-info/PKG-INFO
  writing dependency_links to /tmp/pip-modern-metadata-rw8t16dd/trove_classifiers.egg-info/dependency_links.txt
  writing top-level names to /tmp/pip-modern-metadata-rw8t16dd/trove_classifiers.egg-info/top_level.txt
  writing manifest file '/tmp/pip-modern-metadata-rw8t16dd/trove_classifiers.egg-info/SOURCES.txt'
  listing git files failed - pretending there aren't any
  reading manifest file '/tmp/pip-modern-metadata-rw8t16dd/trove_classifiers.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  adding license file 'LICENSE'
  writing manifest file '/tmp/pip-modern-metadata-rw8t16dd/trove_classifiers.egg-info/SOURCES.txt'
  creating '/tmp/pip-modern-metadata-rw8t16dd/trove_classifiers-0.0.0.dist-info'
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: trove-classifiers
  Running command Building wheel for trove-classifiers (pyproject.toml)
  /pkg/python/x86_64-pc-linux-gnu/lib/python3.12/site-packages/setuptools/_distutils/dist.py:266: UserWarning: Unknown distribution option: 'use_calver'
    warnings.warn(msg)
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib
  creating build/lib/trove_classifiers
  copying src/trove_classifiers/__main__.py -> build/lib/trove_classifiers
  copying src/trove_classifiers/__init__.py -> build/lib/trove_classifiers
  copying src/trove_classifiers/py.typed -> build/lib/trove_classifiers
  installing to build/bdist.linux-x86_64/wheel
  running install
  running install_lib
  creating build/bdist.linux-x86_64
  creating build/bdist.linux-x86_64/wheel
  creating build/bdist.linux-x86_64/wheel/trove_classifiers
  copying build/lib/trove_classifiers/__main__.py -> build/bdist.linux-x86_64/wheel/trove_classifiers
  copying build/lib/trove_classifiers/__init__.py -> build/bdist.linux-x86_64/wheel/trove_classifiers
  copying build/lib/trove_classifiers/py.typed -> build/bdist.linux-x86_64/wheel/trove_classifiers
  running install_egg_info
  running egg_info
  writing src/trove_classifiers.egg-info/PKG-INFO
  writing dependency_links to src/trove_classifiers.egg-info/dependency_links.txt
  writing top-level names to src/trove_classifiers.egg-info/top_level.txt
  listing git files failed - pretending there aren't any
  reading manifest file 'src/trove_classifiers.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  adding license file 'LICENSE'
  writing manifest file 'src/trove_classifiers.egg-info/SOURCES.txt'
  Copying src/trove_classifiers.egg-info to build/bdist.linux-x86_64/wheel/trove_classifiers-0.0.0-py3.12.egg-info
  running install_scripts
  creating build/bdist.linux-x86_64/wheel/trove_classifiers-0.0.0.dist-info/WHEEL
  creating '/tmp/pip-wheel-rwlj8w02/.tmp-ib17itev/trove_classifiers-0.0.0-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
  adding 'trove_classifiers/__init__.py'
  adding 'trove_classifiers/__main__.py'
  adding 'trove_classifiers/py.typed'
  adding 'trove_classifiers-0.0.0.dist-info/LICENSE'
  adding 'trove_classifiers-0.0.0.dist-info/METADATA'
  adding 'trove_classifiers-0.0.0.dist-info/WHEEL'
  adding 'trove_classifiers-0.0.0.dist-info/top_level.txt'
  adding 'trove_classifiers-0.0.0.dist-info/RECORD'
  removing build/bdist.linux-x86_64/wheel
  Building wheel for trove-classifiers (pyproject.toml) ... done
  Created wheel for trove-classifiers: filename=trove_classifiers-0.0.0-py3-none-any.whl size=13260 sha256=7e36aaf76a49bd05388a8cbf225cafe4766c145392c6024b4584cda74c505a2e

./x86_64-pc-linux-gnu/bin/python3 -m pip -v list|grep trove
trove-classifiers       0.0.0      /pkg/python/x86_64-pc-linux-gnu/lib/python3.12/site-packages pip

Installing https://pypi.org/project/calver/ before trove_classifiers fixess it.
trove-classifiers       2024.7.2   /pkg/python/x86_64-pc-linux-gnu/lib/python3.12/site-packages pip

My command was something like pip -v install --no-build-isolation python/trove-classifiers/trove_classifiers-2024.7.2.tar.gz
I don't have the shell-history anymore, but if you are saying that the dependencies are correct (and enforcing), then the best explanation would be, that some --no-deps has sneaked in from attempts to install other packages? I needed --no-deps for at least one (unrelated) package that day in the same shell.

https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-no-build-isolation says:

Disable isolation when building a modern source distribution. Build dependencies specified by PEP 518 must be already installed if this option is used.

Therefore, it would be expected that this would happen if build dependencies weren't already installed.


[XLA] tf.where not working with xla.compile

tf.where doesn't seem to be supported when using xla.compile. Are there any ways around the issue, or would it be possible to implement?
Example code:
import tensorflow as tf
import tensorflow.contrib.compiler.xla as xla

test_tensor = tf.constant([[1, 2, 3, 0.00004, 5], [6, 7, 8, 9, 10]], dtype=tf.float32)

def func():
    return tf.where(test_tensor < 1e-2)

with tf.device("/device:CPU:0"):
    compiled_func = xla.compile(func)

with tf.Session() as session:
    res = session.run(compiled_func)
    print(res)

Error output:
tensorflow.python.framework.errors_impl.InvalidArgumentError: Detected unsupported operations when trying to compile graph cluster_5308246905621824101[] on XLA_CPU_JIT: Where (No registered 'Where' OpKernel for XLA_CPU_JIT devices compatible with node node Where
.  Registered:  device='CPU'; T in [DT_BOOL]
device='CPU'; T in [DT_COMPLEX128]
device='CPU'; T in [DT_COMPLEX64]
device='CPU'; T in [DT_DOUBLE]
device='CPU'; T in [DT_FLOAT]
device='CPU'; T in [DT_BFLOAT16]
device='CPU'; T in [DT_HALF]
device='CPU'; T in [DT_INT8]
device='CPU'; T in [DT_UINT8]
device='CPU'; T in [DT_INT16]
device='CPU'; T in [DT_UINT16]
device='CPU'; T in [DT_INT32]
device='CPU'; T in [DT_INT64]

tf.where doesn't seem to be supported when using xla.compile.

Correct, this is due to a fundamental design choice in XLA, see https://medium.com/tensorflow/pushing-the-limits-of-gpu-performance-with-xla-53559db8e473.  We are currently working on relaxing this, but it is a lot of work.

Are there any ways around the issue

Not that I know of today with xla.compile.
You could try using autoclustering instead of xla.compile, by setting the TF_XLA_FLAGS environment variable to include --tf_xla_auto_jit=2.  Or you could try moving the where out of xla.compile.
Since this is working as intended (but not necessarily desired) I'm going to close this, but I don't mean to end the conversation if you have other questions.


How about vamo access to 2 identical byte offset values

Is it allowed there are more than two identical offset in vector atomic instruction?
For example:
vs2 = [0x0, 0x0, 0x0, 0x0] that means 4 operations try to write the same address(rs1+0x0) at the same time or in some kind of order.
But the Vector AMOs  provide no ordering guarantee between element operations.  Does that mean the result is randomized by the implementation?

Correct.
However, I wonder if we should strengthen this to impose locally sequential semantics when the wd bit is set. (AMOs to disjoint addresses could still be reordered in the global memory ordering in this case.)

Zvamos have been removed from v1.0 draft.  This issue being labelled as post v1.0.


Visual Bug with Mekanism and gas conduits

The gas conduit appears to not connect to the Chemical Oxidizer , but in reality it is connected .
Using EnderIO version <IP_ADDRESS>3 . I have tried re-logging , and still the same thing .
https://imgur.com/7KnN9Ge

Also i want to say i do not have/use optifine.

Then Mekanism is breaking its own API and not providing an IGasHandler from that block. Therefore EIO has no idea it exists. Our code does work, see the other blocks it is connecting to.


[RFC] Intel GPU integration

This RFC is from Intel, following XLA GPU roadmap to integrate Intel GPU as in-tree device in OpenXLA. Hope to get your suggestion for this proposal, thanks!

Hi all, thanks for all of your discussion, I'm glad to see so many suggestions!
Here are some updates/plans for future work after simple talked with Google:

We agree to eliminate the #ifdef in code and upstream the common changes first, since it's very simple and can help to parameterize pass API to support more pluggable device in future
Still need more discussion for runtime part. We can continue to discuss it in this RFC, or wait to see if the maintainer can give more info
We have set public CI demo in public repo Intel® Extension for OpenXLA*, and plan to hook it to OpenXLA CI for any possible testing. Welcome to check it!

Hi all,
Sorry for the delayed response! I somehow missed that the RFC was opened until now. Below is what I understood from the discussion:
Intel's motivations for upstreaming some parts of the Intel GPU PJRT plug-in:

Integrating at PJRT level has no easy way to reuse XLA HLO optimization passes.

Intel has to hard-copy 90% of the code into the plug-in's repo and periodically resync. The actual changes to the passes are minor and are not worth this much maintenance effort.

Some code isn't specific to Intel GPU. Upstreaming them would benefit more devices, i.e., SYCL and SPIR-V devices.
Out of sight, out of mind. According to Intel:

Users may be more aware of Intel GPU support if it is in-tree.

I think this is orthogonal. We could reach similar user-awareness if Intel GPU support is listed in XLA's main page/documentations/blogs, etc.

In-tree developers may be more likely to factor in Intel GPU programming model in their new feature development/design if the code is in-tree.

This seems addressable with a good shared interface, which is orthogonal to where the code lives.

On the other hand, it's also easy for plug-in code to develop things that don't align to in-tree code in a long-term in favor of faster development velocity.

So far, we seem to all agree that:

#ifdefs interspersed in code is bad and should be avoided as much as possible.

As @stellaraccident pointed out, it's also detrimental to motivation 3.2, as it makes the code diverge and has nothing to enforce developers to think of the shared infrastructure. Having a good shared abstraction/interface is beneficial to motivation 3.2.

XLA:GPU needs to be more modularized and have more integration points.
It makes sense to upstream device-generic code.

There are also different levels of in-tree-ness/modularity that should be distinguished:

T1: In-tree, code interspersed with #ifdefs: A resounding no from everyone.
T2: In-tree, mostly modularized backend code:

Separate files implementing/extending a shared interface, with the module registration happening when build with some Bazel config flag.

T3: Out-of-tree as a separate repo, still a single binary:

XLA depends on this repo as a Bazel http_repository.
Builds as a single XLA binary with some Bazel config flag.

T4: Out-of-tree as a separate repo, separate plug-in binary to be installed alongside XLA:

This is what the current Intel GPU PJRT plug-in does.

If I understand correctly, Intel proposes upstreaming 3 separate components T2-style, and will have fast-moving, Intel-specific features (not mentioned in this RFC) remain in the plug-in (T4). @joker-eph initially proposed the 3 components should be done T3-style, but later on seemed to be okay with T2 as well, did I get this right?
Let's decide on each component separately?

LLVM IR changes

Integrate SPIR-V translator: I think this should be upstreamed since it benefits any SPIR-V-supported devices.

@jpienaar do you have a requirement for it to be a pluggable pass at the end?

The rest of the changes seem specific to Intel GPU and we'll likely need to look at the code to see how we can make it more parameterized/modularized.

Lib call: The lib call rewrites happen in HLO optimization passes.

As mentioned in our CPU Strategy, we are defining a formal integration point for 3rd-party HLO/MLIR-based graph rewrite/optmization passes. The same work applies to XLA:GPU. We would also like to learn what improvements we can make to existing passes to make them more reusable, and if we need to add more extension points (and where).
@Zantares Could you please give some code pointers to the changes you made to the existing HLO passes in your plug-in repo? We could schedule a public meeting call to walk through the code as well if it's easier.

XLA:GPU Runtime: For calling SYCL-supported devices.

Based on the device-generic principle, it seems like it should be upstreamed, so other devices and build upon this interface.
3,000 lines of code is nontrivial, but if it is in a separate backend folder that should be modular enough.
One concern is about maintenance, as Google doesn't have the expertise to maintain it. TensorFlow used to have SYCL support but we deleted it [issue, commit] because we weren't aware of users, and there was no activities on that code in a while.
I don't have a preference between out-of-tree (T3/T4) vs in-tree (T2) and delete if things are inactive -- I'm assuming Intel will help maintain the backend. What do people think?

Thanks for the great summary @penpornk!

@joker-eph initially proposed the 3 components should be done T3-style, but later on seemed to be okay with T2 as well, did I get this right?

I think there is a nuance :)
To me all the shared components / library probably makes sense in-tree: that is T2 (even though: things could also be modular enough to be their own repo as well: imagine the SPIRV runtime in its own repo, with clean enough API that any SPIRV platform could just reuse it directly? The drawback is that a constellation of small components can become harder to manage/integrate/evolve).
On the other hand for the "non shared components", it's not clear to me why T2 is the best, it seems worth evaluating more closely if every platform could have its own repo for the non-shared code (without duplicating code: that would defeat the point of course), that is T4 I think? (which is how the TPU compiler is setup somehow).
Now: it is possible that 90% of what Intel has here is in the "T2" category and the T4 part is very small, or it is possible that it's the opposite, or anywhere in the middle. I haven't tried to make an assessment of this. What seemed valuable was to start upstreaming the things that are clearly "T2 component" cleanly, and then see where we are?

I don't have a preference between out-of-tree (T3/T4) vs in-tree (T2) and delete if things are inactive -- I'm assuming Intel will help maintain the backend. What do people think?

I think that for non NVIDIA GPU targets, it is a very non abstract (and primarily, non technically driven) desire to be in tree: in my experience, core developers for this kind of system -- which has grown in a non modular fashion against one target, benefit from a tangible itch to scratch. Putting the burden on those who come second or third to take the step to live outside of the peripheral vision of the primary authors is unfair and will not produce a good result with the style of development that the core authors do on this component. Case in point: it was three weeks before someone affiliated with primary stewardship of the project commented (and thank you for doing so, Penporn -- much appreciated). With that kind of dynamic, code locality is the only lever available to bias towards equal access to the platform.
I think that the GPU vendors should be colocated at this point: if one is in tree, then they all should be as a matter of policy. That can be reevaluated if the primary authors publish a more detailed plan and level of support track record for this kind of situation. It would be different if this were the fourth or fifth implementation and/or there was a strong track record of multi targeting for the GPU component specifically. But in effect, this is the second. The only way to evolve the situation from this point is colocation, imo.

Thanks for the summary @penpornk ! We will have some internal discussion first and give the feedback later.

Thank you all for the quick replies! :)
The tally so far:

Proposal
Shared code (multi-vendor)
Vendor-specific code

Intel
T2
T2

@joker-eph
T2 (T3 if/when makes sense)
T4

@stellaraccident
T2
T2

I also got feedback from JAX/PJRT. The code structure underneath doesn't matter to them, they only require that the device support for JAX still be built and packaged as a separate PJRT plug-in (even if the code lives in the same XLA tree).
Our team will look more into the Intel GPU plug-in code before making per-component suggestions too. The goal is to still keep XLA in good health with reasonable work scopes that fits each party's high-level goals and timelines.
Re: @joker-eph:

Now: it is possible that 90% of what Intel has here is in the "T2" category and the T4 part is very small, or it is possible that it's the opposite, or anywhere in the middle. I haven't tried to make an assessment of this. What seemed valuable was to start upstreaming the things that are clearly "T2 component" cleanly, and then see where we are?

Great question. @Zantares, do you have a quick answer here?
Starting with clearly-T2 things makes sense to me. Maybe we can start with the LLVM-SPIRV translator PR?
@joker-eph Do you consider the SYCL runtime support "clearly T2"?
Re: @stellaraccident:

Putting the burden on those who come second or third to take the step to live outside of the peripheral vision of the primary authors is unfair and will not produce a good result with the style of development that the core authors do on this component.

I agree. Device vendors may help with core code however they can out of goodwill / necessity to make things happen, but it's not their responsibility to do so. Core maintainers need to be actively involved.
Also +1 to @Jianhui-Li's point:

From the PluggableDevice experience, I actually think that we need a modular maintainer's guidance on the technical direction. It is not practical to propose any structural changes if the modular maintainer is planning something else.

While Intel contributed most of the PluggableDevice design and implementation, it was done in close collaboration with TF core maintainers (Google). Some examples:

Google suggested targeting classic TF runtime instead of TFRT because of time constraints and code maturity.
Google decided not to rush a new, generic device C API and proposed the StreamExecutor C API RFC as a short-term solution.
Google implemented the StreamExecutor C API [1, 2, 3, etc.] which enabled Intel to start prototyping PluggableDevice.
Google consistently made design suggestions for Intel's PluggableDevice and Grappler C API RFCs.
Google refactored sharable accelerator code from //tensorflow/core/common_runtime/gpu to a generic //tensorflow/core/common_runtime/device [1, 2, 3, 4, etc] for the new pluggable device type to use.
etc.

We apologize for the delay in responding to this RFC and aim to have better response times from now on.
Re: @stellaraccident:

With that kind of dynamic, code locality is the only lever available to bias towards equal access to the platform, and the option to develop in tree should be retained.
I think that the GPU vendors should be colocated at this point: if one is in tree, then they all should be as a matter of policy. That can be reevaluated if the primary authors publish a more detailed plan and level of support track record for this kind of situation. It would be different if this were the fourth or fifth implementation and/or there was a strong track record of multi targeting for the GPU component specifically. But in effect, this is the second. The only way to evolve the situation from this point is colocation, imo.

Great point here! I'll bring this up to the team.

@joker-eph Do you consider the SYCL runtime support "clearly T2"?

Seems like something that other SYCL vendors would want instead of being a specific component of the IntelGPU backend right? If so I would say yes here.

While Intel contributed most of the PluggableDevice design and implementation, it was done in close collaboration with TF core maintainers (Google).

Absolutely, and actually I alluded to this work (without the links you have!) before in my one of my comments as an example of a "success story". It has to be collaborative, but it still implies "work" from the "new platforms" to help build their extension points.

@penpornk @joker-eph Quick answer for your question:

Now: it is possible that 90% of what Intel has here is in the "T2" category and the T4 part is very small, or it is possible that it's the opposite, or anywhere in the middle. I haven't tried to make an assessment of this. What seemed valuable was to start upstreaming the things that are clearly "T2 component" cleanly, and then see where we are?

It belongs to the previous situation for SPIRV target part. We only have a few code changes here (~250 LoC).

LLVM IR changes
i. Integrate SPIR-V translator: I think this should be upstreamed since it benefits any SPIR-V-supported devices.
@jpienaar do you have a requirement for it to be a pluggable pass at the end?
ii. The rest of the changes seem specific to Intel GPU and we'll likely need to look at the code to see how we can make it more parameterized/modularized.

In addition, there's chance to be parameterized for the rest changes in my thought:

Use generic SPIRV instrinsic instead
Add device check (or new PJRT API) to distinguish address index for different device instead of hard code if possible

We can discuss it after preparing the code example, thanks!

@Zantares There is a number of backend-specific contributions Intel could provide, is it possible to elaborate on planned changes?
There are the following areas which might require changes:

Outlining sections of HLO instructions into Intel library calls, and plumbing Intel library calls into SE
Modifying pre-Triton codegen to support Intel intrinsics
Modifying Triton itself/Triton tiling logic to support Intel GPUs
Modifying set of fusion heuristics, to perform different logic for Intel if necessary.

Is the set of planned changes mainly based around (1)? Is it possible to see the preview of features-to-land?

Lib call: The lib call rewrites happen in HLO optimization passes.

As mentioned in our CPU Strategy, we are defining a formal integration point for 3rd-party HLO/MLIR-based graph rewrite/optmization passes. The same work applies to XLA:GPU. We would also like to learn what improvements we can make to existing passes to make them more reusable, and if we need to add more extension points (and where).
@Zantares Could you please give some code pointers to the changes you made to the existing HLO passes in your plug-in repo? We could schedule a public meeting call to walk through the code as well if it's easier.

To @penpornk , sorry I have missed this point before. Please check below link to see how we use oneDNN lib call in plug-in. We also started to check CPU RFC to see how to reuse the 3rd-party passes to complete this work.

Modify Thunk to run oneDNN Conv: https://github.com/intel/intel-extension-for-openxla/blob/0.2.0/third_party/openxla.patch#L376-L450
Modify Rewriter to support specific fusion: https://github.com/intel/intel-extension-for-openxla/blob/0.2.0/third_party/openxla.patch#L451-L496
Custom compiler to call Rewriter: https://github.com/intel/intel-extension-for-openxla/blob/0.2.0/xla/service/gpu/spir_compiler.cc#L111-L112

There are the following areas which might require changes:

Outlining sections of HLO instructions into Intel library calls, and plumbing Intel library calls into SE
Modifying pre-Triton codegen to support Intel intrinsics
Modifying Triton itself/Triton tiling logic to support Intel GPUs
Modifying set of fusion heuristics, to perform different logic for Intel if necessary.

Is the set of planned changes mainly based around (1)? Is it possible to see the preview of features-to-land?

To @cheshire , I assume Q1 is already answered above. For Q2 & Q3, we have already made some experiments to support Triton in our plug-in, it still needs lots of work. For Q4, right now in plug-in we reused most of public code and use macro to add specific fusion, in future we want to combine this work with new proposed Global Cost feature in OpenXLA.
In general, Q1 & Q4 are based around (1), you can check plug-in first to see the preview: https://github.com/intel/intel-extension-for-openxla. The Triton related part is another story which is not covered in this RFC, but I can say we really have plan to support Triton for Intel GPU.

Regarding Intel GPU support in StreamExecutor, I'd love it to be in tree as stream_executor/sycl (in addition to cuda and rocm) with minimal #ifdefs for Intel specific parts. Today we don't run any tests for rocm platform, and rely on AMD to run them and send patches, we can use the same approach for sycl (until we figure out how to do CI as a part of OpenXLA checks)

Hi @ezhulenev , does it mean that OpenXLA repo will send the PR patch to AMD CI and get its feedback? Is this detail available in public? We also want to provide similar check here.

No, currently it works as a post-submit, CI jobs runs periodically with latest commit and then we accept patches. @ddunl might know if we have any plans for pre-submit CI jobs for AMD, and do we have plans for supporting other CI jobs. I'd love to have an options to include backend-specific CI jobs optionally for a PR. Not sure about enabling it by default, as even with current set of jobs it takes a long time to get back results.

No, currently it works as a post-submit, CI jobs runs periodically with latest commit and then we accept patches. @ddunl might know if we have any plans for pre-submit CI jobs for AMD, and do we have plans for supporting other CI jobs. I'd love to have an options to include backend-specific CI jobs optionally for a PR. Not sure about enabling it by default, as even with current set of jobs it takes a long time to get back results.

Thanks for the feedback! It's a good idea that take backend-specific CI as post-submit to avoid possible blocking situations. We'll start from this. And we agree that not enabling backend-specific CI jobs by default. Maybe a better way is to trigger it by GitHub label/specific comment on demand.

I think for now we don't have specific plans for supporting external CI in general, just that we know we want to do it. Definitely backend-specific CI with the ability to trigger on demand is great though, and would be very helpful

Hi all, the 1st PR of SPRI-V target is submitted: https://github.com/openxla/xla/pull/7940.

The SYCL runtime is submitted: https://github.com/openxla/xla/pull/9042
Note this big PR is for preview and CI test, we will continue to split it into small PRs and welcome your suggestions for this PR.


Add new changes

I've created a branch, created a file and made a commit, and opened a pull request

It was very informative course


x/lint: golint does not recognize Unwrap methods

golint does not complain if a method implementing know interfaces is not documented.
However when I define the Unwrap method, it complains:
exported method Error.Unwrap should have comment or be unexported

By the way, how I'm supposed to document the method?
// Unwrap implements support for error unwrapping.

or
// Unwrap implements the Unwrapper interface.

?

Could you provide more information for this issue? Could you provide an example of the code that produced the error, preferably as a Go playground link?

Sure, sorry.
https://play.golang.org/p/8Zy-WTR7J9B
golint will report:
test/unwrap.go:17:1: exported method Error.Unwrap should have comment or be unexported

Note how there is no warning about the Error method not having a comment since it is a well know interface.

Here is the code that should be updated:
https://github.com/golang/lint/blob/master/lint.go#L836
Thanks

Thank you for the clarification.

/cc @ianthehat @matloob

Lint is really noisy and my preference is to keep its behavior fixed. If you want to send a CL to add Unwrap to the list of known methods I'd be okay with it.