Generate a unique font name for non-cached fonts

Fixes #7402
@Snuffleupagus Can you take a look? You introduced the previous auto-generated name in #3997, but it appears to be insufficient. I've locally verified that this PR fixes the problem for the PDF in the linked bug.

/botio test

@Rob--W There's actually a couple of issues with this code, which is why I've already submitted PR #7347, which incidentally fixes issue #7402 as well. In my opinion, that's a more complete solution, since it also an issue related to cleanup, so I'd prefer if that one is landed instead!

sgtm


md5 hash is incorrect: 8f6c62320cd30f8017af530cbb099536 while 8f6c62320cd30f8017af530cbb099536  file_versions.tsv expected

Hi,
I installed compleasm using conda. It run into error message:
md5 hash is incorrect: 8f6c62320cd30f8017af530cbb099536 while 8f6c62320cd30f8017af530cbb099536  file_versions.tsv expected
deleting corrupted file mb_downloads/file_versions.tsv
Unable to download necessary files
Any suggestions please?

@dukecomeback Hi,
Recently the BUSCO file formats have changed which caused this problem. I have solved the problem in the latest version of compleasm. Please reinstall compleasm using conda.

The new version works! Thank you.


Standard frame id is more than 11 bits

I used cantools python package to decode canbus message. I used a dbc file created by me for testing. I copied a sample file. When I use can id like 419358976, I get error. But for smaller can ids like 350, it works. Does cantools fail for extended frame ids? how do I get this working? How do I specify to use extended can ids?
my code which is failing for extended id's is as follows:
db = cantools.database.load_file('.\\src\\test\\resources\\j1939.dbc')
print(db.decode_message(419358976,b'\xff\xff\xff\xc0\x0c\xff\xff\xff'))

error:
cantools.database.errors.Error: Standard frame id 0x18fee900 is more than 11 bits in message EEC1.
Can you show how this record should look like in the .dbc file? (for an extended id)
This number is 29 bits. 419358976 = 1 1000 1111 1110 1110 1001 0000 0000
if I use<PHONE_NUMBER> in the .dbc file, it works fine, but it is a 32 bit number. I thought it has to be a 29-bit number.

The dbc format has no dedicated field for indicating an id is extended. It uses bit 0x8000000 of the id field for that purpose.

The dbc format has no dedicated field for indicating an id is extended. It uses bit 0x8000000 of the id field for that purpose.

Hi Jueq,
Ok, but still this doesn't answer my question. Why cantools can not decode my message for can id 419358976?

Well. It actually does. You enter an ill formatted id field when passing id 419358976 in a dbc. It is missing the 32th bit, which should have been set because the id is extended. cantools does notice that you have passed an id as standard that does not fit in 11 bits, so it rightfully complains.

419358976

Hi, I really appreciate your help. Do you mean this can id 419358976 is invalid? I get that id by reading a CAN0 device. It is he actual can id I receive from the device.

The id itself is perfectly valid. Unfortunately, the author of the dbc file format chose to "misuse" a bit in the id field to indicate if it is extended (instead of adding an atomic boolean field to do that.
cantools uses a dedicated field to represent the std/ext information internally.
So the same id does look different in the dbc file: In the dbc file it is formatted as decimal and 0x80000000 is added if the id is extended.

look

ah...so he dbc file needs to be fixed. Could you please show me a sample and valid entry for this extended id in the dbc file? what is the valid entry should look like in the dbc file?

If on Windows: Open calc and switch to programmers view. Select dec. Paste 419358976. Select hex. Add 80000000. Select dec. The numer you see now is what needs to be entered in the text of the dbs file if edited by hand.

80000000

Oh... I understood what you meant now. That is really helpful. I will try this on Monday as I don't have access to this now. Thanks a lot. I will update you on Monday :-) I didn't find this information any where. This must be really documented. Where did you find this information?

Unfortunately Vector Informatik does not publish a dbc file format spec, but you can find a few resources across the internet that detail the format of these files. But I just checked a few and they all did not contain this bit of information :).
The usual way to edit dbc files and check if their syntax is correct is to use Vectors CANdb++ program. That does get shipped with various of their other products and maybe there is also a demo available. Using CANdb++ is also the way for me to know how extended is encoded: You can just change it back and forth and see what it is doing to the id field in the file.
I also like editing dbcs by hand or using generators, doing all via UI can be tedious. But using CANdb++ to check every now and then is helpful.

 IT WORKED!
I think this has to be documented properly somewhere

@juleq: It would be great if you could make a fix for this quirk of the DBC format. (If you prefer, I can do it for you if you tell me how to test it.)

@andlaus There is nothing wrong with cantools. It properly parses correctly formatted dbc files. Issue here was that hand-editing dbc files requires some "more esoteric" knowledge of the dbc file format details (the borrowed bit in the id field).

ah, good to know. I'm frequently surprised how many file format are/started out just internal formats of some proprietary products -- not just in the automotive industry. IMO "open" formats are not always better, though. (err, I'm looking at you ARXML...)

Yes. I like Kayak but its tough to go against something as well established across the industry as dbc. And one could argue ingesting the compact text of a dbc is quicker than these verbose xml files :).

As I understood that we need to buy this dbc file from Vector Informatik. Is there a better way to decode CAN messages without using their dbc file? like a open standard?

You can use the dbc file format. If you want their tooling, you pay. Kayak (kcd) is open source.

as @juleq said above: you may use the DBC file format however you like, you only need to pay if you want to use Vector Informatik's tools (they are the canonical reference, but as you have noticed they are quite pricey), or -- depending on the licensing conditions of the DBC file -- you need to pay to get access to the file itself.  The situation is exactly like for less exotic file formats like PDF: In order to use a PDF document, you don't need to pay Adobe for an Acrobat license, but you might have to pay the publisher to obtain a PDF copy of e.g. Harry Potter...


Question about npz and fbx

Hi there,
I save joint positions 'j3d_smpl24' from npz as an obj file, and then export fbx from the same npz.
I find that the joint positions of same frame in these two files can't match as below:

Could you please tell me how to fit  'j3d_smpl24' to fbx ?
And I also wonder the meaning of 'cam_trans' in model' s output.
Thank you very much!!!

They are mis-aligned due to adding the translation. To avoid this, you can delete this part (L170-L189) .


IssueID:1901:LittleFS switches to new flash API

[Detail]
LittleFS switches to new flash API.
[Verified Cases]
Build Pass: helloworld_demo@haaseduk1
Test Pass: helloworld_demo@haaseduk1

感谢提交 Pull Requests！
Thanks for submitting a pull request.


<EMAIL_ADDRESS>hash check failed

Checking hash of MEGAsyncSetup.exe ... ERROR Hash check failed!
App:         extras/megasync
URL:         https://mega.nz/MEGAsyncSetup.exe#/dl.7z
First bytes: 4D 5A 90 00 03 00 00 00
Expected:    58aed4162478a9dbbea69efbe48d577783a93e63c23e3e3829d6a698e79c1743
Actual:      3c11390bee870d3900f170f88996d27e88f64516ae0c74808cccd72196142657

Looks like just a connection issue.
You can run scoop update megasync -f --no-cache to re-install without using the (possibly corrupted) local cache file.

Closing as this issue is stale. Please reopen if this is still an issue.


Add SAS_URL config to rclone-s3-syncer component

What this PR does / why we need it:
Enables configuration of rclone-s3-syncer with Azure SAS Urls

/approve


Global properties, eg @flash

Hi, I think this is a simple yes or no proposal. Should Surface support "globals", eg @flash? I can see there is some stub support for a property called "flash" (and this prevents any component creating a :flash property), however, it doesn't seem to be wired up?
So, a) is there any use case for a global property? b) Is there any desire for a preset top level context that gets initialised with certain params such as @flash ?
I have no idea what other frameworks do. I think this is easily shut down with a no and close the issue though? (However, a few thoughts on clever ways to handle global type concerns such as @flash would be useful in the docs I think?  Thanks)

@ewildgoose Thank you for creating this issue!

Hi, I think this is a simple yes or no proposal. Should Surface support "globals", eg @flash? I can see there is some stub support for a property called "flash" (and this prevents any component creating a :flash property), however, it doesn't seem to be wired up?

What do you mean be "is not wired up" ? Do you mean that you are able to create a flash property in one of your components or something else?

So, a) is there any use case for a global property? b) Is there any desire for a preset top level context that gets initialised with certain params such as @flash ?

There is the notion of Context. It allows you to initialize some kind of context before using a component. Does it answer your questions?
May I ask you if you have a concrete example to share with us that will help us to have a global view of what you have in mind ?

Hi, yes, in component.ex and live_component.ex we have:
      @doc "Built-in assign"
      data flash, :map

And in helpers.ex we have
  @builtin_common_assigns [
    :socket,
    :flash,
    :__context__,
    :__surface__
  ]

This prevents you making a property in any custom component called "flash".
However, at least in the version of surface I'm using (which I concede isn't the very latest), it does not pull from the top level assigns either, ie if you want to see the global @assigns.flash, then you need to:
a) create a custom property, or add code to stash it in a context
b) that custom property CANNOT be called flash (as this is reserved by the data stanza shown above)
It looks almost as though someone original wanted there to be a magic property called "flash" that gets passed to all components, but didn't quite finish the coding? Is this the desire?
I've phrased the question in the more general sense: Do we want there to be a way to create "magic properties" that apply to all components? Whether this is via some way to pre-initialise the top level context of all components, or through some ability to set properties that apply to all components, globally? Or should we go the other way and remove the "data properties()" and demand that components handle this themselves? Both seem fine directions to me - I can definitely see a use for "magic global properties" though?

To the more general question: We previously played around with a slightly different version of Context that was similar; however, settled on the current approach as there are fewer edge cases. I /think/ that should be able to handle most cases of magic/global properties (though I haven't played with them too much lately). The context stuff (as well as any global variable type thing) also has implications for change tracking
The :flash assign is referencing phoenix's flash assign, we haven't tried to implement anything specific for the flash assign. However, since that's only automatically added in a LiveView, we shouldn't be preventing assigns named flash in components.

@ewildgoose is right. We shouldn't have flash in  Component nor LiveComponent. It's up to the user how to send the parent flash to the component. You may want to pass it as a prop or using the context or even use another name for it as mentioned here. The only value that is automatically handled is the one in the LiveView so I think it's ok to keep it.

I don't want to re-open this and create noise, but I wanted to note one other use-case for "globals". Sometimes due to the structure of HTML it can be difficult to do a "modal" effect through a single component. For example as implemented in bootstrap you need one component at the top level to darken the background and another (likely elsewhere in the html structure) to actually show the modal itself.  Usually js is used to toggle the background from the "component" implementing the modal, but this does feel like a hack to cross boundaries. It could be rather complicated to implement this only using surface features and no js?
I can't think of many other use cases (other than flash), but I wonder if other technologies have some kind of "global" context that could be used to cleanup such implementations?


Removed all rounding causing inaccuracy in calculations

#34
I think rounding should be removed completely for two reasons:

The way you've patched it makes all downstream projects very verbose, i.e. you always have to add the decimals parameter in your calls
It may mess up people's calculations inadvertently, if they don't know that rounding is happening.

Can you separate the two commits into two different pull requests? The linting + python best practices commit edits the name of GalvanicCell, so there needs to be a update in documentation as well. I can make the change to the docs, but it would be better for organization purposes if you had a separate pull request for the linting commit.

Due to the incompatibility of the linting commit, and the extensive reviewing and documentation changes that it entails, it's best not to merge this pull request. We can perhaps revisit the linting commit when sufficient unit tests have been written. For now, thanks for the idea to remove rounding from Issue #34. I have implemented that in the core and electrochemistry submodules and will merge changes into master soon.

Rounding has been removed in Pull Request 46. Thanks for your suggestion to remove rounding!
A commit for linting + python best practices will be considered if a separate pull request is made.


Webpack 5! Is svg-sprite-loader compatible with Webpack 5?

Webpack 5! Is svg-sprite-loader compatible with Webpack 5?
I update my application from 4 to 5 webpack and seems sprite stop working properly.
svg-sprite-loader is not generated symbol anymore, instead I got this data data:image/svg+xml;base64
Current behavior
I receive this as output:

Expected behavior
With webpack 4 I have this:

This is a part of my webpack config

environment:

Node.js version: 12.17.0
React version: 17.0.2
webpack version: 5.66.0
svg-sprite-loader version: 6.0.11
OS type & version: Ubuntu

I tried many cases and config changes...but with no success. I don't know even to what I should pay attention, because there are no visible errors while building the app.
also there is no info in readme regarding webpack5.
I would really appreciate any help. Thanks.

Here #470 I posted diff that also adds webpack@5 support.

Hi @chrisands. Thanks. I will check it out.

Any news about releasing this fix?

Set Rule.type to javascript/auto works for me.

Set Rule.type to javascript/auto works for me.

seems work for me too

This needs to be added to the documentation. I searched for this solution almost an entire day. Is it a webpack or a loader specific config? In my case, i was doing a require.context for the svgs and importing them all from a folder. Before i upgraded webpack, i was getting actual modules but after the upgrade i was just getting strings
const requireContext = require.context('./assets/svg', true, /\.svg$/)
requireContext.keys().forEach(requireContext)


Display one less component on blank lines

First of all thanks for the plugin.
I would love an option to display one less component on blank lines.
That is how indentation guides work in IntelliJ and VSCode. And I honestly think it makes more sense.
Especially with use_treesitter enabled the trailing component feels out of place (See first image).
Currently:

Expected:

I just added a -1 so it isn't in shape for a PR.
When I have some time I might try to get a grip of the config options and actually implement this.

This is already an option :help g:indent_blankline_show_trailing_blankline_indent

Oops, sorry for bothering you


Resolves console unicode issue #177

@adamralph Done

@adamralph You can just squash merge this to master instead.

@adamralph squashed and force pushed.


Mention the need for Encoder in certain cases in documentation

Trying to implement defmt for a custom board/serial line was a little bit of a headache just reading through the documentation. Maybe some improvements to the docs can be made.

At first, it wasn't clear that defmt was sending indices of strings to a host program to decode. I realize it's trivial now given the "deferred" part of "defmt" but just reading the getting started docs didn't really make that clear. It definitely wasn't clear you need a host program to decode them for you. It took all the way to defmt-print --help to finally realize how defmt works. It's also right there at the bottom of the introduction page, but that's not what search engines are pointing to when googling around for how to integrate defmt.
After getting defmt integrated and sending bytes over the serial line, installing defmt-print and trying to use it, I spent a good hour tinkering with my system's serial config thinking the bytes weren't coming in correctly or something, because all of the frames were malformed. I looked at the encoding docs and thought raw meant "no fancy encoding", but that didn't work.
Nowhere in the global_logger nor the "Encoding" page does it mention that in order to send frames over the wire, you must use an Encoder to get them working.

I'm sure to people who use defmt often this is all trivial but as a complete newcomer to defmt (having previously stored all logging strings directly in the firmware itself), it wasn't obvious what was happening or how this was supposed to work, especially trying to implement my own wire debugging.
Perhaps some of the docs could mention these sorts of cases on the relevant pages? I actually didn't get to the "introduction" page from google, but rather the "Setup" page. A "Guide for Implementors" page (which really is the global_logger page, more or less) could have a lot more information about this, I think.

Hi @Qix- 👋🏾
Thank you for your message! Making our documentation more beginner-friendly is definitely something we have to work on.
Would you be interested in proposing changes to the docs to make it more clear? Since you just went through the process you probably know quite well what would have helped you. If yes, please just send a PR. If not we can totally also work on it.
🥂

Sure thing! I'll try to get some time sometime this week to do it :) Thanks for the response.


Szeliga doc updates

Removed a link to Google Group

After discussing with Steven, this work is now superseded by work that Pete has recently done. Closing the PR.


Problem with EventHubClient.createFromConnectionString(connStr.toString()

Hello,
I'm experiencing below error when trying to run the script: SendTweetsToEventHub from https://docs.microsoft.com/en-us/azure/databricks/scenarios/databricks-stream-from-eventhubs:
    _command-2682908066933071:19: error: value createFromConnectionString is not a member of object com.microsoft.azure.eventhubs.EventHubClient
    val eventHubClient = EventHubClient.createFromConnectionString(connStr.toString(), pool)_

Libraries used:
com.microsoft.azure:azure-eventhubs-spark_2.11:2.3.12
org.twitter4j:twitter4j-core:4.0.7
Can you kindly advise how to overcome the error?
Jozef
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fd4b0492-b73e-881d-92ef-a9e9d841cd05
Version Independent ID: 3ca1bc50-7003-0766-b14e-a96b100516da
Content: Tutorial: Stream data into Azure Databricks using Event Hubs
Content Source: databricks/scenarios/databricks-stream-from-eventhubs.md
Service: azure-databricks
GitHub Login: @lenadroid
Microsoft Alias: alehall

@JozefMelichar  Thanks for reaching out on this. Just wanted to check if you have tried using com.microsoft.azure:azure-eventhubs-spark_2.11:<IP_ADDRESS> by changing EventHubClient.create(connStr.toString(), pool) to EventHubClient.createFromConnectionString(connStr.toString(), pool).
Hope this helps.

Thank you. That helped. Problem was probably in older library.
I have one more error in ReadTweetsFromEventHub. Could you kindly advise also here?
      command-2682908066933073:10: error: reference to ConnectionStringBuilder is ambiguous;
      it is imported twice in the same scope by
      import com.microsoft.azure.eventhubs._
      and import org.apache.spark.eventhubs._
      val connStr = ConnectionStringBuilder()
                    ^

@JozefMelichar Unfortunately, I could not find  val connStr = ConnectionStringBuilder() from Read tweets from Event Hubs  - section.
I would suggest you to follow the code in the document.
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Subscription error in OTA library, triggers loop of MQTT disconnect and connect and OTA job fails.

Hi Team,
I am using AWS FreeRTOS version 202007 and ESP32.
ESP32 is connected to the corporate network Wi-Fi. Very High speed network. No chance of unstable network.
Also ESP does not loose ping at all. Ping is very stable.
Some times OTA library shows subscription error in OTA.  After the keep alive time out, MQTT disconnect happens and reconnects again. After the MQTT reconnect again,  OTA library shows subscription error. After the keep alive time out, MQTT disconnect happens and reconnects again.
The above pattern continues as a loop and OTA job does not go through.
Remember this does not happen all the time, this happens only some times.
This is stopping the production again.
Kindly help in this as soon as possible.
Thanks, Regards,
Kumar.

Hello @kumarfirmware ,
Can you please share the logs when this issue happens as this is not reproducible in our tests on AWS FreeRTOS version 202007 and ESP32?

This issue has been idle for a long while, so I'll close it. If there's still a problem, please open a new issue.


feat: support api key use case for CP4D authenticator

Adds support for API key and password support in the CP4D authenticator and updated authorization URL.

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


suggest to change component name

stripe-payment-sheet → stripe-payment
stripe-payment-modal → stripe-sheet
stripe-payment-sheet-modal → stripe-payment-sheet

I'm not sure about the Stencil build specification, so I worried about the renaming effect.
@rdlabo
Should we replace the name in its entirety files? (directory name / file name / component / name etc..)
or just replace the component name?

@hideokamoto You should change only tag in Components Decorator. Thanks.

Breaking change/component name #17


Add missing default labels with @ i18N

Is your feature request related to a problem? Please describe.
Some components are ready for I18N and others not,  for instance:

Cart component: https://github.com/adobe/asset-share-commons/blob/develop/ui.apps/src/main/content/jcr_root/apps/asset-share-commons/components/modals/cart/cart.html#L87
Downloads component: https://github.com/adobe/asset-share-commons/blob/develop/ui.apps/src/main/content/jcr_root/apps/asset-share-commons/components/modals/downloads/downloads.html#L88

We can see that both components have the same "Close" button but one has the I18N feature ${properties.closeButton || 'Close' @ i18n} and the other not ${properties['closeButton']}
Describe the solution you'd like
The solution would be to apply the same solution that is already implemented for the Downloads component.
Describe alternatives you've considered
The alternative is to create copies for each language and introduce the translations using the provided dialogs

Hey @gquintillan Can I do this please? But as I can see  @ i18n in both.

@NaincyKumariKnoldus that would be great! Well probably try to cut a release sometime this week - so if you can get a PR in, we should be able to merge for release!

But as I can see @ i18n in both. then what to change?

Hi! I'm already working on a PR for this :)


Searching

Hey guys, im having a little trouble here, so i have 100 data, and the limit of my data is 10 per page. And when i enter keyword to search, it's just searching through that 10 data on the page, but what i want is to search for all the 100 data. anyone can help ? thank you ! ^ ^

hey @fabiokounang can you show me how you're using it?

hey, sorry for the late reply, i already figured it out^ ^, i wasnt get to database when i search it, but now i do, so it is solved ^ ^.oh by the way,  the new problem is, the vue warning about props, how can i solve it ? the warning is "avoid mutating direct props" blablabla

Sounds like you're mutating props in your component which vue frowns upon. If you look it up online, you'll see some alternative patterns that are more in line with Vue's best practices.
Since this isn't related to vue-good-table, I will close this.


[tool_crash] FileSystemException: Cannot open file, OS Error: Operation not supported, errno = 45

Command
flutter build ios-framework --xcframework --no-universal --output=/Dev/flutter/innovea-pdt-008-flutter-2

Steps to Reproduce

...
...
...

Logs
FileSystemException: Cannot open file, OS Error: Operation not supported, errno = 45
#0      _File.throwIfError (dart:io/file_impl.dart:635:7)
#1      _File.openSync (dart:io/file_impl.dart:479:5)
#2      _File.writeAsBytesSync (dart:io/file_impl.dart:604:31)
#3      ForwardingFile.writeAsBytesSync (package:file/src/forwarding/forwarding_file.dart:124:16)
#4      FileSystemUtils.copyDirectorySync (package:flutter_tools/src/base/file_system.dart:81:17)
#5      FileSystemUtils.copyDirectorySync (package:flutter_tools/src/base/file_system.dart:84:9)
#6      FileSystemUtils.copyDirectorySync (package:flutter_tools/src/base/file_system.dart:84:9)
#7      BuildIOSFrameworkCommand._produceFlutterFramework (package:flutter_tools/src/commands/build_ios_framework.dart:324:23)
#8      BuildIOSFrameworkCommand.runCommand (package:flutter_tools/src/commands/build_ios_framework.dart:194:15)
<asynchronous suspension>
#9      FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:1157:12)
<asynchronous suspension>
#10     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:1009:27)
<asynchronous suspension>
#11     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#12     AppContext.run (package:flutter_tools/src/base/context.dart:149:12)
<asynchronous suspension>
#13     CommandRunner.runCommand (package:args/command_runner.dart:197:13)
<asynchronous suspension>
#14     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:278:9)
<asynchronous suspension>
#15     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#16     AppContext.run (package:flutter_tools/src/base/context.dart:149:12)

[✓] Flutter (Channel stable, 2.0.4, on Mac OS X 10.15.6 19G73 darwin-x64, locale pt-BR)
    • Flutter version 2.0.4 at /Users/Axel/development/flutter
    • Framework revision b1395592de (4 days ago), 2021-04-01 14:25:01 -0700
    • Engine revision 2dce47073a
    • Dart version 2.12.2

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/Axel/Library/Android/sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[!] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.4, Build version 12D4e
    ✗ CocoaPods installed but not working.
        You appear to have CocoaPods installed but it is not working.
        This can happen if the version of Ruby that CocoaPods was installed with is different from the one being used to
        invoke it.
        This can usually be fixed by re-installing CocoaPods.
      To re-install see https://guides.cocoapods.org/using/getting-started.html#installation for instructions.

[✗] Chrome - develop for the web (Cannot find Chrome executable at /Applications/Google Chrome.app/Contents/MacOS/Google
    Chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[✓] Android Studio (version 4.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 1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.55.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension can be installed from:
      🔨 https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[!] Connected device
    ! No devices available

! Doctor found issues in 3 categories.

Flutter Application Metadata
Type: app
Version: 1.0.0+1
Material: true
Android X: false
Module: false
Plugin: false
Android package: null
iOS bundle identifier: null
Creation channel: stable
Creation framework version: 2783f8e2e14efec8b7e08f668dde61c40d128c24
Plugins
flutter_plugin_android_lifecycle-1.0.11
flutter_sms-2.1.1
flutter_user_agent-1.2.2
image_picker-0.6.7+14
path_provider-1.6.24
path_provider_linux-0.0.1+2
path_provider_macos-0.0.4+6
path_provider_windows-0.0.4+3
share-0.6.5+4
shared_preferences-0.5.12+4
shared_preferences_linux-0.0.2+4
shared_preferences_macos-0.0.1+11
shared_preferences_web-0.1.2+7
shared_preferences_windows-0.0.1+3
url_launcher-5.7.10
url_launcher_linux-0.0.1+4
url_launcher_macos-0.0.1+9
url_launcher_web-0.1.5+1
url_launcher_windows-0.0.1+3
video_player-0.10.12+5
video_player_web-0.1.4+1
wakelock-0.1.4+2

I found similar error message in https://github.com/flutter/flutter/issues/31111.

"in many cases the downgrade or migrate does not work"
I solved the problem by downloading version 1.24 from the Dev channel
export PATH = "$ PATH: / Users / axel / development / flutter_1_24 / bin"
flutter clean
flutter run


Any plans to integrate the Tabs module?

We have not yet plannified to wrap this component.
If you have free time you could do a pull request with this wrapped component and we will review it.
You can look at the dropdown component if you want an example


IndentationError

I am having an issue running snippets with indentations. I changed the config to call py instead of python3, which allows some snippets to run. But in the following example, I get this error, even when using different numbers of spaces or tabs.
for i in [0,1,2]:
    print(i)

Error: Command failed: py -c "for i in [0,1,2]:
    print(i)"
  File "<string>", line 1
    for i in [0,1,2]:
                     ^
IndentationError: expected an indented block

But when I run the snippet as follows, it works.
for i in [1,2,3]: print(i)

1
2
3

Is this unavoidable at the moment, or am I doing something wrong?

Are you running the snippet on Windows 10? If so, I had the same issue. The problem is that node child_process.exec uses cmd.exe as the default exec shell on Windows. Apparently, cmd.exe doesn't handle the line endings well. Node uses process.env.ComSpec to configure the shell. I changed this (in devtools) to the PowerShell path on my system and the multiline snippets worked fine.
This plugin should probably add a setting for process.env.ComSpec when running on Windows.

Hello all!, thank you for the issue and commit.
I've added the 'options' property to the latest version, where you can specify the shell to use.


layers/meta-opentrons: add boot script runner

This is on the OT-2 and we forgot about it up to now - provide a way for people to run stuff on the system if they want. They have to install manually, but by dropping executable scripts in
/var/user-packages/etc/boot.d/ the scripts should be run at boot.

ooo thank you thank you @sfoster1. Just upgraded our fleet. We were missing this badly

ooo thank you thank you @sfoster1. Just upgraded our fleet. We were missing this badly

Glad it helped! And sorry we missed it.


npm: No matching version found for @mui/lab@next in CRA styled-components demo

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
npm fails when installing the example for styled components with CreateReactApp (https://github.com/mui-org/material-ui/tree/master/examples/create-react-app-with-styled-components)
npm ERR! notarget No matching version found for @mui/lab@next.
Expected Behavior 🤔
package should be installable/resolve
Steps to Reproduce 🕹
Follow the instructions in the readme in the link above
Context 🔦
Demo is not
Your Environment 🌎

  System:
    OS: macOS 11.5.2
  Binaries:
    Node: 14.17.3 - /var/folders/hd/jkczj0nx7zb6xywcm3x9hbn80000gn/T/fnm_multishells/99329_1632422775630/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.23.0 - /var/folders/hd/jkczj0nx7zb6xywcm3x9hbn80000gn/T/fnm_multishells/99329_1632422775630/bin/npm
  Browsers:
    Chrome: 94.0.4606.54
    Edge: Not Found
    Firefox: 91.0.2
    Safari: 14.1.2

Can you try with @mui/lab@latest. I think all the examples should use @latest.

This is a consequence of https://github.com/mui-org/material-ui/pull/28530#issuecomment-925624543 :)


Initial commit of jax2iree

This is awesome! ❤

Drive by :)

Thanks - most of these items will go away as part of finishing this PR and flipping it out of Draft :)

This work prompted me to finally get IREE publishing a first class C/Python API to its compiler (we were previously doing a hoaky, shell out to a compiler executable thing, which isn't the best for JIT/in-process): https://github.com/google/iree/pull/6683
I'll combine that with the existing IREE runtime API early next week and should be able to land this POC spike in a couple of days. It'd be good to chat then about next steps.

Ok, the most recent push pulls in our new in-process compiler API and demonstrates basic runtime integration for e2e execution. Still plenty to do, but this represents a complete POC.

Thanks for getting this started!
I was expecting that an IREE integration will be more lightweight from a JAX point of view: export the HLO module, invoke the IREE compiler, plus some runtime integration to run the executables. The current PR seems to use a custom trace to convert each JAX primitive separately. I think that this is very costly: a lot of conversion rules some of which will be very tricky. We do follow this strategy for jax2tf, but there the target language is very far from HLO. Do we really need to do the same for IREE?

Also, I'm about to go out on vacation for a few weeks, and I'm in no hurry to move this forward right this minute. What's here is literally a few hours of coding and if it serves to solidify a plan that I/someone can pick up and start working on in September, it will have done its job, from my perspective.

On Tue, Aug 10, 2021 at 9:05 AM Stella Laurenzo @.***>
wrote:

Assuming that such a converter table API existed (or could graduate out of
this work), this is a pretty lightweight PR and what is left is most likely
needed. IREE's IR has more features than XLA, especially for things related
to deployment, and we will want to introduce new primitives for python
defined kernels, control the way the function boundaries are emitted,
handle access to globals, etc. All of those reasons are why we find the
existing HLO proto path unsuitable and I think are worth the extra code.

However what you could do is bootstrap your translation rules from the
existing translation rules. For every primitive, at least for those not
parameterized by other computations, you can create a translation rule that
calls the existing HLO translation rule and translate its output. You can
then replace the rules one-by-one as you need.
Some of the translation rules aren't trivial. Not all JAX primitives are
one-to-one with HLO constructs. You can find the most interesting examples
of this by searching for xla.lower_fun() which allows you to call back into
the tracing machinery in a translation rule: no-one wants to write
non-trivial code in the builder API so the non-trivial code typically uses
this facility to embed JAX code in a translation rule.  For an example of
this, see, for example, how cumsum is implemented:
https://github.com/google/jax/blob/a93eaf3c9ef7db7bfaf419953adcd37e81a7b5f7/jax/_src/lax/control_flow.py#L2644
Now admittedly that one probably should have an HLO primitive but it
doesn't.
I mention this because you'd get this for free by calling into the existing
translation rules but you'd have to do some work to make it work without
that.

I don't relish building out the primitive conversion tables, but if that is
the price of a high quality implementation, it's not that hard. It would
be nice to share most of it, though.

Another suggestion:
I'd suggest actually implementing the JAX runtime API so IREE can
transparently integrate with the rest of JAX. (e.g., things like jit(f)
will just work but backed by IREE instead of XLA).
You can either implement something that duck-types as the Python API:
https://github.com/tensorflow/tensorflow/blob/76d68c3f2ce78168ffb59f43c39e1ee718c24be1/tensorflow/compiler/xla/python/xla_extension/__init__.pyi#L295
or implement its C++ version:
https://github.com/tensorflow/tensorflow/blob/76d68c3f2ce78168ffb59f43c39e1ee718c24be1/tensorflow/compiler/xla/pjrt/pjrt_client.h
You can implement either, although I'd probably recommend the C++ version
so you can get access to low-latency JIT dispatch. In essence you would
need to implement four classes (Client, Device, Buffer, Executable). Many
methods don't need to be implemented (e.g., infeed/outfeed, channels,
cross-device transfers, etc.) so don't get dissuaded by the fact some APIs
look awfully TPU-specific.
There are a few places where the API may be a little too XLA-specific.
That's fine, we can fix that. The most notable one is that Compile() takes
an XLA computation, but we could, say, make that some sort of opaque object
or add an overload that takes mHLO.
Peter

On Tue, Aug 10, 2021, 3:42 AM George Necula @.***>
wrote:

Thanks for getting this started!
I was expecting that an IREE integration will be more lightweight from a
JAX point of view: export the HLO module, invoke the IREE compiler, plus
some runtime integration to run the executables. The current PR seems to
use a custom trace to convert each JAX primitive separately. I think that
this is very costly: a lot of conversion rules some of which will be very
tricky. We do follow this strategy for jax2tf, but there the target
language is very far from HLO. Do we really need to do the same for IREE?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/jax/pull/7425#issuecomment-895923751, or
unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AADYVADWWUM4AITSZ5HMW7TT4D7BRANCNFSM5BJLY6HA
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/jax/pull/7425#issuecomment-896010288, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACVGBG5Y2AJHJ2RY5HSWBLT4EPYNANCNFSM5BJLY6HA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

On Tue, Aug 10, 2021 at 9:05 AM Stella Laurenzo @.***> wrote:
Assuming that such a converter table API existed (or could graduate out of this work), this is a pretty lightweight PR and what is left is most likely needed. IREE's IR has more features than XLA, especially for things related to deployment, and we will want to introduce new primitives for python defined kernels, control the way the function boundaries are emitted, handle access to globals, etc. All of those reasons are why we find the existing HLO proto path unsuitable and I think are worth the extra code.
However what you could do is bootstrap your translation rules from the existing translation rules. For every primitive, at least for those not parameterized by other computations, you can create a translation rule that calls the existing HLO translation rule and translate its output. You can then replace the rules one-by-one as you need.  Some of the translation rules aren't trivial.

Were you thinking of literally calling the existing machinery, producing an XlaComputation and then converting that to  equivalent MHLO ops? Some of that code does exist but it is quite far in terms of build systems and deps (and is old/brittle in other ways that add tax)... and then we are in the space of evaluating how much to invest in bootstrap paths, etc (esp. for OSS builds where dependency boundaries are strict and high cost). One possible simplification: we implement a duck-typed implementation of XlaBuilder in the MHLO repo and have a way to inject that JAX-side. There'd still be typing involved but it would probably be pretty formulaic and relatively easy to rip through and/or meta-program. We could either implement that in Python or as a pybind module against the C-API.

Not all JAX primitives are one-to-one with HLO constructs. You can find the most interesting examples of this by searching for xla.lower_fun() which allows you to call back into the tracing machinery in a translation rule: no-one wants to write non-trivial code in the builder API so the non-trivial code typically uses this facility to embed JAX code in a translation rule. For an example of this, see, for example, how cumsum is implemented: https://github.com/google/jax/blob/a93eaf3c9ef7db7bfaf419953adcd37e81a7b5f7/jax/_src/lax/control_flow.py#L2644 Now admittedly that one probably should have an HLO primitive but it doesn't. I mention this because you'd get this for free by calling into the existing translation rules but you'd have to do some work to make it work without that.

Nice - that is how it should be (imo).

I don't relish building out the primitive conversion tables, but if that is the price of a high quality implementation, it's not that hard. It would be nice to share most of it, though.
Another suggestion: I'd suggest actually implementing the JAX runtime API so IREE can transparently integrate with the rest of JAX. (e.g., things like jit(f) will just work but backed by IREE instead of XLA). You can either implement something that duck-types as the Python API: https://github.com/tensorflow/tensorflow/blob/76d68c3f2ce78168ffb59f43c39e1ee718c24be1/tensorflow/compiler/xla/python/xla_extension/init.pyi#L295 or implement its C++ version: https://github.com/tensorflow/tensorflow/blob/76d68c3f2ce78168ffb59f43c39e1ee718c24be1/tensorflow/compiler/xla/pjrt/pjrt_client.h You can implement either, although I'd probably recommend the C++ version so you can get access to low-latency JIT dispatch. In essence you would need to implement four classes (Client, Device, Buffer, Executable).

Thanks for these references. A C++ implementation is likely where we need to land, but I'm tempted to start with an iteration in pure Python just for the value of seeing something connect a bit more easily (to my eyes). IREE's Python runtime API is really just a toy for functional evaluation, not for a serious integration with a production stack (it takes shortcuts with its modeling of host/device memory, has limited support for multi-device, doesn't expose most of the concurrency/synchronization primitives, etc) -- however, it makes up for that with a lot of convenience :)  IREE's C-API models everything but is, of course, harder to use. There are also real design questions that come up when looking at bridging IREE-C+PJRT in the most efficient way possible, and I would feel better about having something/anything working to compare against while working those out.
Conversely, the IREE/MLIR-based compilers are easier to integrate with from Python if you are already largely homed in Python (as JAX is). There is also a C-API, and we did take that approach with PyTorch, although, in that case, it is because PyTorch's IR is implemented in C++ and that is where you get the most unfettered access to it. The complexity and code cost is high, however. For JAX, I think we can largely stay at the Python level for the main compiler and then just use that from the runtime APIs related to compilation. That also makes it easier to do some more interesting things. Do you see any issues with that path?

Many methods don't need to be implemented (e.g., infeed/outfeed, channels, cross-device transfers, etc.) so don't get dissuaded by the fact some APIs look awfully TPU-specific. There are a few places where the API may be a little too XLA-specific. That's fine, we can fix that. The most notable one is that Compile() takes an XLA computation, but we could, say, make that some sort of opaque object or add an overload that takes mHLO. Peter
…

Since I'm new to your codebase, could you provide some code pointers to what on the JAX side invokes this runtime layer? Reading that code would help my mental model and maybe make me useful in offering concrete suggestions for generalizing.

On Tue, Aug 10, 2021, 08:06 Stella Laurenzo @.***>
wrote:

On Tue, Aug 10, 2021 at 9:05 AM Stella Laurenzo @.***> wrote:
Assuming that such a converter table API existed (or could graduate out of
this work), this is a pretty lightweight PR and what is left is most likely
needed. IREE's IR has more features than XLA, especially for things related
to deployment, and we will want to introduce new primitives for python
defined kernels, control the way the function boundaries are emitted,
handle access to globals, etc. All of those reasons are why we find the
existing HLO proto path unsuitable and I think are worth the extra code.
However what you could do is bootstrap your translation rules from the
existing translation rules. For every primitive, at least for those not
parameterized by other computations, you can create a translation rule that
calls the existing HLO translation rule and translate its output. You can
then replace the rules one-by-one as you need.  Some of the translation
rules aren't trivial.
Were you thinking of literally calling the existing machinery, producing
an XlaComputation and then converting that to equivalent MHLO ops? Some of
that code does exist but it is quite far in terms of build systems and deps
(and is old/brittle in other ways that add tax)... and then we are in the
space of evaluating how much to invest in bootstrap paths, etc (esp. for
OSS builds where dependency boundaries are strict and high cost). One
possible simplification: we implement a duck-typed implementation of
XlaBuilder in the MHLO repo and have a way to inject that JAX-side.

Not sure if this is what you mean, but we have an XlaBuilder variant that
produces MHLO already. I think it is just a change in constructor of the
builder (of course there may be a caveat with nested builders as we haven't
used that much, but easy to add). We could effectively move that variant
into MHLO side, it could get tricky with helper functions (but not too
bad/those should perhaps be MHLOs and can expand later, sort of as Peter
mentioned some of them should be ops).

There'd still be typing involved but it would probably be pretty formulaic
and relatively easy to rip through and/or meta-program. We could either
implement that in Python or as a pybind module against the C-API.
Not all JAX primitives are one-to-one with HLO constructs. You can find
the most interesting examples of this by searching for xla.lower_fun()
which allows you to call back into the tracing machinery in a translation
rule: no-one wants to write non-trivial code in the builder API so the
non-trivial code typically uses this facility to embed JAX code in a
translation rule. For an example of this, see, for example, how cumsum is
implemented:
https://github.com/google/jax/blob/a93eaf3c9ef7db7bfaf419953adcd37e81a7b5f7/jax/_src/lax/control_flow.py#L2644
Now admittedly that one probably should have an HLO primitive but it
doesn't. I mention this because you'd get this for free by calling into the
existing translation rules but you'd have to do some work to make it work
without that.
Nice - that is how it should be (imo).
I don't relish building out the primitive conversion tables, but if that
is the price of a high quality implementation, it's not that hard. It
would be nice to share most of it, though.
Another suggestion: I'd suggest actually implementing the JAX runtime API
so IREE can transparently integrate with the rest of JAX. (e.g., things
like jit(f) will just work but backed by IREE instead of XLA). You can
either implement something that duck-types as the Python API:
https://github.com/tensorflow/tensorflow/blob/76d68c3f2ce78168ffb59f43c39e1ee718c24be1/tensorflow/compiler/xla/python/xla_extension/__init__.pyi#L295
or implement its C++ version:
https://github.com/tensorflow/tensorflow/blob/76d68c3f2ce78168ffb59f43c39e1ee718c24be1/tensorflow/compiler/xla/pjrt/pjrt_client.h
You can implement either, although I'd probably recommend the C++ version
so you can get access to low-latency JIT dispatch. In essence you would
need to implement four classes (Client, Device, Buffer, Executable).
Thanks for these references. A C++ implementation is likely where we need
to land, but I'm tempted to start with an iteration in pure Python just for
the value of seeing something connect a bit more easily (to my eyes).
IREE's Python runtime API is really just a toy for functional evaluation,
not for a serious integration with a production stack (it takes shortcuts
with its modeling of host/device memory, has limited support for
multi-device, doesn't expose most of the concurrency/synchronization
primitives, etc) -- however, it makes up for that with a lot of convenience
:) IREE's C-API models everything but is, of course, harder to use. There
are also real design questions that come up when looking at bridging
IREE-C+PJRT in the most efficient way possible, and I would feel better
about having something/anything working to compare against while working
those out.
Conversely, the IREE/MLIR-based compilers are easier to integrate with
from Python if you are already largely homed in Python (as JAX is). There
is also a C-API, and we did take that approach with PyTorch
https://github.com/llvm/mlir-npcomp/tree/main/frontends/pytorch/csrc/builder,
although, in that case, it is because PyTorch's IR is implemented in C++
and that is where you get the most unfettered access to it. The complexity
and code cost is high, however. For JAX, I think we can largely stay at the
Python level for the main compiler and then just use that from the runtime
APIs related to compilation. That also makes it easier to do some more
interesting things. Do you see any issues with that path?
Many methods don't need to be implemented (e.g., infeed/outfeed, channels,
cross-device transfers, etc.) so don't get dissuaded by the fact some APIs
look awfully TPU-specific. There are a few places where the API may be a
little too XLA-specific. That's fine, we can fix that. The most notable one
is that Compile() takes an XLA computation, but we could, say, make that
some sort of opaque object or add an overload that takes mHLO. Peter
… <#m_-3189520145904455374_>
Since I'm new to your codebase, could you provide some code pointers to
what on the JAX side invokes this runtime layer? Reading that code would
help my mental model and maybe make me useful in offering concrete
suggestions for generalizing.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/jax/pull/7425#issuecomment-896110089, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFMRTV3PVFNAMOUKD4TS5DT4E6ATANCNFSM5BJLY6HA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

On Tue, Aug 10, 2021, 08:06 Stella Laurenzo @.> wrote:
On Tue, Aug 10, 2021 at 9:05 AM Stella Laurenzo @.> wrote: Assuming that such a converter table API existed (or could graduate out of this work), this is a pretty lightweight PR and what is left is most likely needed. IREE's IR has more features than XLA, especially for things related to deployment, and we will want to introduce new primitives for python defined kernels, control the way the function boundaries are emitted, handle access to globals, etc. All of those reasons are why we find the existing HLO proto path unsuitable and I think are worth the extra code. However what you could do is bootstrap your translation rules from the existing translation rules. For every primitive, at least for those not parameterized by other computations, you can create a translation rule that calls the existing HLO translation rule and translate its output. You can then replace the rules one-by-one as you need.  Some of the translation rules aren't trivial. Were you thinking of literally calling the existing machinery, producing an XlaComputation and then converting that to equivalent MHLO ops? Some of that code does exist but it is quite far in terms of build systems and deps (and is old/brittle in other ways that add tax)... and then we are in the space of evaluating how much to invest in bootstrap paths, etc (esp. for OSS builds where dependency boundaries are strict and high cost). One possible simplification: we implement a duck-typed implementation of XlaBuilder in the MHLO repo and have a way to inject that JAX-side.
Not sure if this is what you mean, but we have an XlaBuilder variant that produces MHLO already. I think it is just a change in constructor of the builder (of course there may be a caveat with nested builders as we haven't used that much, but easy to add). We could effectively move that variant into MHLO side, it could get tricky with helper functions (but not too bad/those should perhaps be MHLOs and can expand later, sort of as Peter mentioned some of them should be ops).

Ah, I didn't know we'd made progress on that (I know it had been discussed for a long time). I'll ping you and see if some code organization could make it easier/possible to leverage.

…
There'd still be typing involved but it would probably be pretty formulaic and relatively easy to rip through and/or meta-program. We could either implement that in Python or as a pybind module against the C-API. Not all JAX primitives are one-to-one with HLO constructs. You can find the most interesting examples of this by searching for xla.lower_fun() which allows you to call back into the tracing machinery in a translation rule: no-one wants to write non-trivial code in the builder API so the non-trivial code typically uses this facility to embed JAX code in a translation rule. For an example of this, see, for example, how cumsum is implemented: https://github.com/google/jax/blob/a93eaf3c9ef7db7bfaf419953adcd37e81a7b5f7/jax/src/lax/control_flow.py#L2644 Now admittedly that one probably should have an HLO primitive but it doesn't. I mention this because you'd get this for free by calling into the existing translation rules but you'd have to do some work to make it work without that. Nice - that is how it should be (imo). I don't relish building out the primitive conversion tables, but if that is the price of a high quality implementation, it's not that hard. It would be nice to share most of it, though. Another suggestion: I'd suggest actually implementing the JAX runtime API so IREE can transparently integrate with the rest of JAX. (e.g., things like jit(f) will just work but backed by IREE instead of XLA). You can either implement something that duck-types as the Python API: https://github.com/tensorflow/tensorflow/blob/76d68c3f2ce78168ffb59f43c39e1ee718c24be1/tensorflow/compiler/xla/python/xla_extension/init.pyi#L295 or implement its C++ version: https://github.com/tensorflow/tensorflow/blob/76d68c3f2ce78168ffb59f43c39e1ee718c24be1/tensorflow/compiler/xla/pjrt/pjrt_client.h You can implement either, although I'd probably recommend the C++ version so you can get access to low-latency JIT dispatch. In essence you would need to implement four classes (Client, Device, Buffer, Executable). Thanks for these references. A C++ implementation is likely where we need to land, but I'm tempted to start with an iteration in pure Python just for the value of seeing something connect a bit more easily (to my eyes). IREE's Python runtime API is really just a toy for functional evaluation, not for a serious integration with a production stack (it takes shortcuts with its modeling of host/device memory, has limited support for multi-device, doesn't expose most of the concurrency/synchronization primitives, etc) -- however, it makes up for that with a lot of convenience :) IREE's C-API models everything but is, of course, harder to use. There are also real design questions that come up when looking at bridging IREE-C+PJRT in the most efficient way possible, and I would feel better about having something/anything working to compare against while working those out. Conversely, the IREE/MLIR-based compilers are easier to integrate with from Python if you are already largely homed in Python (as JAX is). There is also a C-API, and we did take that approach with PyTorch https://github.com/llvm/mlir-npcomp/tree/main/frontends/pytorch/csrc/builder, although, in that case, it is because PyTorch's IR is implemented in C++ and that is where you get the most unfettered access to it. The complexity and code cost is high, however. For JAX, I think we can largely stay at the Python level for the main compiler and then just use that from the runtime APIs related to compilation. That also makes it easier to do some more interesting things. Do you see any issues with that path? Many methods don't need to be implemented (e.g., infeed/outfeed, channels, cross-device transfers, etc.) so don't get dissuaded by the fact some APIs look awfully TPU-specific. There are a few places where the API may be a little too XLA-specific. That's fine, we can fix that. The most notable one is that Compile() takes an XLA computation, but we could, say, make that some sort of opaque object or add an overload that takes mHLO. Peter … <#m-3189520145904455374_> Since I'm new to your codebase, could you provide some code pointers to what on the JAX side invokes this runtime layer? Reading that code would help my mental model and maybe make me useful in offering concrete suggestions for generalizing. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7425 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMRTV3PVFNAMOUKD4TS5DT4E6ATANCNFSM5BJLY6HA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

Since I'm new to your codebase, could you provide some code pointers to what on the JAX side invokes this runtime layer? Reading that code would help my mental model and maybe make me useful in offering concrete suggestions for generalizing.

This may help: https://gist.github.com/hawkinsp/bcbd8375177a5249f2bf8de6a7ef0cda
This is a toy backend that doesn't actually compile anything but instead hardwires in a particular computation. However it shows you how to register a backend and use it to run a trivial computation. If you have a utility to convert an XLA HLO proto into IREE, you could probably use this to plug in IREE without too much further complication as a first step.
(This is mostly orthogonal to what you have done in this PR, which is about avoiding the HLO step.)

Thanks, this is the piece I was missing! Let me give this a shot with our
current mechanisms for bridging HLO and see where we go.
On Tue, Aug 10, 2021, 11:17 AM Peter Hawkins @.***>
wrote:

Since I'm new to your codebase, could you provide some code pointers to
what on the JAX side invokes this runtime layer? Reading that code would
help my mental model and maybe make me useful in offering concrete
suggestions for generalizing.
This may help:
https://gist.github.com/hawkinsp/bcbd8375177a5249f2bf8de6a7ef0cda
This is a toy backend that doesn't actually compile anything but instead
hardwires in a particular computation. However it shows you how to register
a backend and use it to run a trivial computation. If you have a utility to
convert an XLA HLO proto into IREE, you could probably use this to plug in
IREE without too much further complication as a first step.
(This is mostly orthogonal to what you have done in this PR, which is
about avoiding the HLO step.)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/jax/pull/7425#issuecomment-896210821, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADYVAAC6WS7AYMKFJCFXQTT4FUM5ANCNFSM5BJLY6HA
.

FYI - I'll be on vacation for a couple of weeks and will pick this up when back.

I'm back from vacation and am getting caught back up on this. I've gone ahead and landed what is here so far into IREE's samples repository so I can iterate on it a bit more: https://github.com/google/iree-samples/tree/main/pre-release/python
I'll rework it now to add the discussed runtime interop and a JAXPR interpreter, then we can discuss where to take it.

Since I'm new to your codebase, could you provide some code pointers to what on the JAX side invokes this runtime layer? Reading that code would help my mental model and maybe make me useful in offering concrete suggestions for generalizing.

This may help: https://gist.github.com/hawkinsp/bcbd8375177a5249f2bf8de6a7ef0cda
This is a toy backend that doesn't actually compile anything but instead hardwires in a particular computation. However it shows you how to register a backend and use it to run a trivial computation. If you have a utility to convert an XLA HLO proto into IREE, you could probably use this to plug in IREE without too much further complication as a first step.
(This is mostly orthogonal to what you have done in this PR, which is about avoiding the HLO step.)

Thanks for this sample. Here is our iree-samples commit with it working: https://github.com/google/iree-samples/commit/d0f266a2bf0432e4ea71302c8c3b03b43c72cc9d
This is a toy implementation for a few reasons:

Just marshalling through numpy ndarray vs using lower level buffers and avoiding copies.
Uses our HLO->MLIR utility which involves a lot of ASM munging and a process jump.
Hard-codes device setup and such (just for a single CPU).
Uses the synchronous Python API vs the lower level C-API, which allows for async dispatch and corresponding buffer lifetime, etc: If ever making this more than a quick way to evaluate IREE, probably want to drop down to C.

I need to dive in and see how to redirect this away from its reliance on an XlaComputation. Maybe some kind of higher level hook that delegates to the normal Xla way (haven't grok'd the code at all).

Closing this PR because I think the IREE and MHLO integration that are checked in replace it (e.g,.  https://github.com/google/jax/pull/8529 )


[WIP] fix for #4956 (TP error reporting)

issue #4956: Make Type Provider troubleshooting easier with better error reporting
Let the full exception details surface when a type provider fail at design / compile time.
Looking at the CI to get an idea of tests that need adjusting.

I'm checking the test output, the issue is that now the output contains the file path where the code was compiled from in the stacktrace, it looks like the tests are comparing the output for exact match.
For example:
neg1.fsx(3,18,3,70): typecheck error FS0001: This expression was expected to have type
    'string'
but here has type
    'int'

neg1.fsx(9,38,9,64): typecheck error FS3021: Unexpected exception from provided type 'FSharp.EvilProvider.IsArrayTypeRaisesException' member 'IsArray': The type provider 'Provider.EvilProvider' reported an error: System.Exception: deliberate error for testing purposes

   at <StartupCode$provider>.$Provider$fsx.Microsoft-FSharp-Core-CompilerServices-IProvidedNamespace-ResolveTypeName@130.Invoke(Unit _arg1)

   at System.Type.get_IsArray()

   at Microsoft.FSharp.Compiler.Tainted`1.Protect[a](FSharpFunc`2 f, range range) in C:\dev\projects\github.com\microsoft\visualfsharp4\src\fsharp\tainted.fs:line 94

notice C:\dev\projects\github.com\microsoft\visualfsharp4\src\fsharp\tainted.fs is part of the output.
How should I go about adjusting the tests with baseline?

@smoothdeveloper I suppose you'll need to modify the code that compares the output of the test andd the baseline

Somewhere around here I suppose: https://github.com/Microsoft/visualfsharp/blob/master/tests/fsharp/test-framework.fs#L448
So you should first update the baselines:

run the tests on your local machine
delete the *.bsl and *.vsbsl files for the failing tests and replace them by *.err and *.vserr)

There is already code these to diff out the current directory so perhaps you might not need to change anything
The actual call to the diffing routing is made here: https://github.com/Microsoft/visualfsharp/blob/master/tests/fsharp/single-test.fs#L215
Note you can run the tests from F# interactive

build net40
send the top 28 lines from https://github.com/Microsoft/visualfsharp/blob/master/tests/fsharp/tests.fs to F# Interactive
Run test fragments like ``singleNegTest (testConfig "typecheck/sigs") "neg1"`

This is now passing, one drawback I see is for maintaining the tests in the future:

they assume windows path, I've kept the existing substitution logic (.bslpp), if that becomes an issue, we will need to improve that part a bit
if some of the fsharp code present in the stackframe changes, those tests will show the diff

I've gathered some information into a readme.md file that we should improve with more description and tips.
https://github.com/smoothdeveloper/visualfsharp/blob/a30a8da6a5c474f18f262f693f6726a979b464ab/tests/fsharp/readme.md
This comment gives an example of actual stacktrace: https://github.com/Microsoft/visualfsharp/issues/4956#issuecomment-391221802 it will help type provider developers to set break points in the type provider SDK and figure out what is the problem they are facing.

This shouldn't be merged for now: https://github.com/Microsoft/visualfsharp/issues/4956#issuecomment-393243040

Can I get back to you on this ...

Can I get back to you on this ...

Yes, absolutely no rush

Something along these lines would be amazing. For TPs I work on I usually end up having a debug function that spams logs and catches/dumps stacktraces before rethrowing while I'm doing active development. Anything we can do to surface TP errors to TP developers would help demystify the whole process.

this is impacting https://github.com/fsprojects/FSharp.Data.SqlClient/issues/262
I tend to agree that surfacing the whole stack trace is too crude and will freak out end users while this is, in essence, a library bug.
Anybody has idea how we could still get the full trace in DEBUG builds of provider? maybe a specifc define symbol that the compiler uses for TP design time assemblies, and make fsc/fsi pick the verbose message (corresponding to my PR)?
This will definitely help TP authoring, but we want to avoid kilometer long error by any means in release builds for TP consumers.

In general we don't want to show stack traces in error messages. But we do need to improve the diagnostics form TP developers and TP early adopters so they can see stack traces if they want.

Can we ease such decision by enabling the compiler to show stacktraces behind a flag like --surface-internal-errors?
this won't change anything for existing use of the compiler but provide easy escape hatch when this would really help diagnosis in various circumstances (mainly TP, compiler and tooling internal errors).

@dsyme , @smoothdeveloper , hey guys, is this PR going anywhere, I am trying to reduce the orphaned PR's in our repo.

This is @dsyme comment:

exceptions are how TPs currently raise diagnostics, and we can't attach stack traces to those diagnostics.

@dsyme , @smoothdeveloper , hey guys, is this PR going anywhere, I am trying to reduce the orphaned PR's in our repo.
Kevin

@dsyme , @smoothdeveloper , hey guys, is this PR going anywhere, I am trying to reduce the orphaned PR's in our repo.
Kevin

I discussed this with @cartermp and we decided to close it, we should address stack merging of inner exceptions somehow, but probably not this way.

I discussed this with @cartermp and we decided to close it, we should address stack merging of inner exceptions somehow, but probably not this way.


signinRedirect response_type

hi there, one more question :)
when making the call userManager.signinRedirect({ scope: 'pv', response_type: 'token' }); everythig woks fine.
Unfortunately if i add openid to the scope and/or id_token to the request_type i get invalid scope/response type errors.
I have full control of both UI and server.
am i missing something?
Thanks

sorted :)


add a callback if Network isAvailable again?

In my current project I am displaying Snackbar when network is unavailable.
Can we somehow get a callback if the Network comes back again, so that I can remove Snackbar. I am not showing Snackbar for few seconds, but using Snackbar.LENGTH_INDEFINITE

Based on the design of the library we don't currently support that feature. What you could do is simply use a broadcast receiver that listens for changes in connectivity and remove the snackbar afterwards.

You would have to handle that scenario yourself; it's not within the scope of this library.


Distributed Tests for MPI

In this PR we migrate the remote transport layer used in MPI to use the existing PTP broker. This fixes some bugs that had appeared in MPI in the last months, and also allows for multi-tenant MPI.
The design of the PTP broker made it impossible to keep using our hacked distributed MPI tests, so I also take the opportunity in this PR to migrate the rotten mpi-native stuff to proper distributed tests.
I am aware that including both changes (PTP broker, and MPI distributed tests) makes it harder to review the PR, but there was a chicken and egg problem:

MPI (w/out the PTP broker) is broken atm, so we can not port the mpi-native stuff to distributed tests.
We can not test the migration to the PTP broker w/out distributed tests.

On the bright side, this PR includes:

Working distributed tests for all MPI test-cases (in Faasm, mpi-native, and mocked distributed tests)
Working distributed test for MPI migration
Working distributed test for multi-tenant MPI execution (including one test with migration)

To get the distributed test for MPI migration I have slightly changed the way migration works. Now, migrated functions do have a special return value, and we can iterate the execution graph and infer which functions were migrated and where. In addition, these tests rely (a bit) on the timing of both hosts (as they try to reproduce a real migration) so they may be risky to have in GHA.
This PR is blocked by #261. But given its size, I think it is ready for review. At the moment, I change the number of threads in the PTP server to 1 to check that the distributed tests run succesfully.
Closes #62

@Shillaker i am not sure i can see your review comments :/


fix: prevent flaky byzantine events test, dirty

Workaround for #1031, but not a fix to the root cause yet.
Overview
Sleeping a while makes it pass rather reliably, but I'm leaving up to #1031 to investigate why.
Note the intention here is just to allow us to CI reliably for the time being. Proper fix is still required.
Changes
Allows the dust to settle after the watcher having been synchronized using a Process.sleep
Testing
mix test --only integration test/omg_performance/integration/byzantine_event_test.exs

many times

Coverage remained the same at ?% when pulling a296b23d193e27ab0cd6b7f28642f3e94f0c949a on dirty_fix_flaky_byzantine_test into 2d9e88a5512f651289bb3cf03db46db671027fae on master.


Change npm to yarn to improve speed, security and reliability of asset install.

https://yarnpkg.com/lang/en/ gives a good summary of why it is better than npm. From my experience this is true.
This pull request changes all npm commands to yarn commands.
It also remove the npm caching code since yarn has resonable caching built in.

Automated message from Dropbox CLA bot
@pweaver, it looks like you've already signed the Dropbox CLA. Thanks!

LGTM

(s/Changes/Change/)

I rerun the test again: https://travis-ci.org/rht/zulip/builds/235479401

@timabbott Poke about merging this once PyCon is done.

Tested this on production. It works. Is the last commit the right way to do this?

@timabbott seems to work in my local production install. Travis failure is currently spurious. Worked in my repo's travis instance.

I had this error on the first try:
+ /home/vagrant/.yarn/bin/yarn install --non-interactive --prefer-offline --modules-folder /srv/zulip-npm-cache/1224a3b4a411a6654fecbc679c0b53a0cbe8b949/node_modules
yarn install v0.24.6
[1/4] Resolving packages...
error Couldn't find package "expose-loader" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Error running a subcommand of lib/provision.py: /home/vagrant/.yarn/bin/yarn install --non-interactive --prefer-offline --modules-folder /srv/zulip-npm-cache/1224a3b4a411a6654fecbc679c0b53a0cbe8b949/node_modules
Actual error output for the subcommand is just above this.

`yarn install` failed; retrying...

However, on the retry, it worked 🎉

Hmm, it's possible since it was using --prefer-offline that it was checking a local out of date registry. Otherwise could be a network failure. That is the sort of error the fallback is suppose to catch though. If it is a consequence of --prefer-offline, that is a bug in yarn.

@pweaver based on Travis CI, it looks like this breaks building a production tarball.  You should be able to reproduce with tools/build-release-tarball.  Error seems to be the same thing that @lonerz mentioned.

@timabbott The yarn.lock file got out of date. Rebased on master and fixed.

@timabbott Thanks for testing the changes. I fixes or commented on what you found.

@pweaver sorry for the delay in reviewing this again -- I was out backpacking and sick for most of the delay.   Aside from a quick rebase, the main thing we need to figure out is where to call install-yarn.

Changed the install directory of yarn. Some of the changes are substantial so someone should review the most recent commit. If the commit is cool, it could be squashed into the first commit.

Tested with upgrade-zulip-from-git from 1.6.0 (when node/nvm is not messed up).
2017-07-19 21:47:35,223 upgrade-zulip-stage-2: Upgrade complete!
2017-07-19 21:47:35,256 purge-deployments: No old deployment directories to purge

(will provide a hashed install log next time, tho there is /home/zulip/deployments/current/var/log/update-prod-static.log)

@timabbott Another test, also more merge conflicts were resolved.

I posted a couple comments, and also am working on a split-out version of the easily incrementally merged pieces of this in timabbott/tabbott-yarn-prep and timabbott/tabbott-yarn.  The goal of the prep branch is to make the functional changes much more readable by separating them out from the renaming of variables and more syntactic code reorganization.
My hope is the merge the former soon, after debugging the one bug I'm aware of in the latter.  Please work off the latter if you're doing new revisions to this.  A review of my prep branch would be much appreciated.

Merged, thanks @pweaver!!  Thanks for getting us through this big migration.


fix start server with nlu model for user guide

Proposed changes:

...

Status (please check what you already did):

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

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for submitting a pull request 🚀 @alwx will take a look at it as soon as possible ✨


Add CIFAR10 dataset

Based off MNIST, uses data that can currently be obtained through Pylearn2's download_cifar10.sh script.

Tests are just failing right now because the data is missing on Travis. I think we can add that as with MNIST (we can store it in the cache in Travis's new container environment so that it doesn't need to be redownloaded each time).
I'll make a ticket though, because I feel that there is a lot of code duplication between this and MNIST, and there's a variety of things that could be factored out for use by future datasets as well.

@bartvm Even though I think I've properly added the CIFAR10 files to cache, the tests fail. I'm not very Travis-savvy, is there something I left out?

On my phone, but the log says:
tar: Old option f' requires an argument. Try tar --help' or `tar --usage' for more information.
Maybe there's something wrong with the Tar command so that it doesn't actually unpack?

On my phone, but the log says:
tar: Old option f' requires an argument. Try tar --help' or `tar --usage' for more information.
Maybe there's something wrong with the Tar command so that it doesn't actually unpack?

I think I found what the issue was, but I can't fix it since I don't think I can clear the cache by myself.

I think the bash command still doesn't fully work. The problem is that curl -O doesn't write to stdout, but to a file instead. Also, tar f requires you to give a filename to read from, but in this case you want to read from stdin for which you need to pass -. I think the final command should look like this:
curl http://www.cs.utoronto.ca/~kriz/cifar-10-python.tar.gz | tar xzf -

Yes, I think you're right. I gleaned the command from the Pylearn2 script, but I missed the dash at the end of the tar command. There's also apparently a way to use the same trick with curl -O which is present in the original command:
curl -O http://www.cs.utoronto.ca/~kriz/cifar-10-python.tar.gz - | tar xvzf -

I'll try to push a commit to force resetting the cache properly, and if it works I'll squash all commits related to fixing my mistake.

@bartvm I wasn't able to repair my cache mistake. I put the right curl command and cleaned up the commits, but I think removing cifar10 from the cache will require manual intervention.
Sorry about that!

No problem! I cleared the cache manually and restarted the build

Python 2 passes now, but you should use from six.moves import cPickle for Python 3 compatibility.

@bartvm Yes! For xrange as well. I'm on it.

Try opening it with mode 'rb', for Python 3 refuses to cast automatically between string- and byte-encoded data.

Sorry, my bad, I only just realised you were trying to unpickle the file that you downloaded, which I guess was pickled with Python 2... They use different encoding schemes, but this could work:
cPickle.load(f, encoding='latin1')

That will fail under Python 2, since cPickle doesn't accept the encoding argument.

One option would be this:
try:
    data = cPickle.load(f, encoding='latin1')
except TypeError:
    data = cPickle.load(f)

but it isn't very readable in my opinion.

I agree, but you can use if six.PY3: which is okay I think.

@bartvm Thanks for the tip. The tests now pass.


Reduce block time to 1sec on proto-testnet

The proto-testnet was originally running with 4 validators in the same GCP region and its average block time was ~1sec. When we added 6 more validators running in 2 other regions, i.e. altogether 10 validators in 3 regions (SG, UK, BE), the block time increased to ~2sec. This might be due to network latency and also due to the number of BLS signature verifications the leader has to perform before it can aggregate the votes into a QC (7 out of 10 needed for supermajority). We should figure out what causes the longer block times and try to reduce them back to 1sec before the launch of Jasper.
Note that longer block times are not due to heavy transaction processing - the blocks we're talking about here are empty.

Fixed by #1334


Refactored ededup with own dpk_ededup namespace

Why are these changes needed?
First pass at restructuring the transform built as its own module (e.g. dpk_ededup) with a ray submodule (dpk_ededup.ray ).
Removed python and ray folders and refactor Dockerfile.python and Dockerfile.ray
remove pyproject.toml and Makefiles
move python code under dpk_ededup
move ray code under dpk_ededup/ray
change import statement to include module name
replace recursive Makefile and use targets from .make.cicd.targets
adapt kfp_ray/Makefile and other make target
Related issue number (if any).
https://github.com/IBM/data-prep-kit/issues/774

@revit13 I moved the branch to the main repo in case this makes it easier to debut the issues. I am still not able to find out why it is failing. Please let me know if you can work your magic! Thanks


Feature request: Integrate to automatically populate values

Feature request:
Integrate to automatically populate:

Current Branch
Date/Time
Add functionality to insure that every commit message is unique

Hi!
What is the format expected for the branch / date? (it's not part of the "classic" template here)
Regarding the message, that may indeed be interesting (along with the ability to reuse existing scopes), but it involves being able to parse the result of the git log command, which is a bit more complex than what is done today.
Note: the sources of that plugin may be useful.

I was thinking about this as a default commit message :
<type>(<scope>): <subject> Commit to {BRANCH_NAME} at {DATE_IN_READABLE_FORMAT}
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

I would also request that {DATE_IN_READABLE_FORMAT} includes seconds to ensure (mostly) a unique commit message.  {DATE_IN_READABLE_FORMAT} should be in a sortable format (YYYY-MM:DD:SS for example.

Does this have a status???

The branch an datetime is already present in the commit logs. Why do you need to also add it to the comment ? I think most people would not want this as it's redundant.
Maybe there could be a default subject that's configurable with variables like branch and date. This way you could configure yours like you want but others could leave it empty and keep the current behavior.

As said before, we'd like to keep the format used by the Angular team: https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits
The template could become configurable with user-defined fields, but I'm afraid it's out of the scope of this plugin (at least for now). Closing now, please reopen if needed.


LineStyle alignment default value in document

PixiJS API Documentation：
https://pixijs.download/dev/docs/PIXI.LineStyle.html

Src：
https://github.com/pixijs/pixi.js/blob/dev/packages/graphics/src/styles/LineStyle.ts

@default:0
public alignment: 0.5;

Test from JSFiddle:

"outter",,,  ok
Wanna make a PR? Default has to be 0.5

OK, but i don't know what should i do...
create an branch and push update?
commit message like 'Document update #6553' ?

Thanks @ivanpopelyshev, i made a PR  :)


Missing jupyter commands still show up in the command pallet

while testing https://github.com/microsoft/vscode-jupyter/issues/9767
A few unimplemented commands show up in the command pallet, and just throw a "not found" error when clicked

only "specify jupyter server for connections" remains, but that already has an issue for it


EXPLORER keybindings don't work

VSCode Version: 1.36.0
OS Version: win10

Steps to Reproduce:

Select a folder in EXPLORER
Shift + Alt + R
Just like this

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

If you want to filter the tree, try "workbench.list.keyboardNavigation": "filter" in you settings

Merging into #76369


Rename to "OpenFF Evaluator"

This issue tracks the progress of renaming this repo from "PropertyEstimator" to "(OpenFF)Evaluator"

Sounds great. It'd be good to screenshare while we do this, so Monday or Tuesday next week would be great (I'm flying/at a conference W-F).

Working on this now - I'll make a post this in Slack likely early next week once the migration is fully finished and stable.

Things seem to have gone mostly smoothly. There were ~31 alerts introduced due to a bug on LGTM's end, but these should be resolved soon. I'm working through some of my slower integration tests now, but if they finish ok then I'll be aiming for a openff-evaluator ==0.1.0 release next Monday.
I'll also I'm to have a ForceBalance PR ready by then to accommodate the changes.

Closing this issue as the migration is now complete.


Document where users can get support

Motivation
Zebra is going to have its first release candidates and active users. We should document, ideally in the README, where users can get support for Zebra.

Is this already decided or should we open up a discussion about it?

I think the only two official places will be the zebra-support channel on Discord and GitHub Issues. We agreed that this should be mentioned in the README.

We aren't doing user support yet.


Limit Update Frequency for Heading?

Is there some way to limit the frequency (number of seconds) for how often heading gets updated?
Thank you!

The same problem here... I'm waiting and waiting...

@misterXavier  -  I'm working on a fork with a fix. Stand by. :)

This feature was added in v2.0.0 beta 1.


add devrel careers to devrel jobs resource list

I'd like to add DevRel Careers to the DevRel Jobs. It would be a valuable addition to the list and help others in the DevRel community find new job opportunities. Thank you!

Hey @paulaxisabel 👋
Thank you for the contribution. The merge is blocked because your commit is not signed.
Here is a quick fix: https://endjin.com/blog/2022/12/how-to-sign-your-git-commits


Minor fixup

Remove the exit message
Dont unnecessarily call the get unit file state function twice.

Now everything works great. Even when I create a new service, the program responds immediately. Very impressive! You did a really good job here and I learned a lot from it. Thank you. Since everything is working so well now I will publish a new release. Let's call it version 1.3...


Bug Report: cupy.repeat triggers an error with ()-shape array

Description
Hi! I use cupy.repeat function but trigger an error with ()-shape array. numpy.repeat runs without errors. This issue is similar with a previous one about cupy.prod
To Reproduce
>>> import numpy as np
>>> import cupy as cp
>>> np.repeat(np.array(1), 1, axis=0)
array([1])
>>> cp.repeat(cp.array(1), 1, axis=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/root/miniconda3/lib/python3.12/site-packages/cupy/_manipulation/tiling.py", line 70, in repeat
    return a.repeat(repeats, axis)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "cupy/_core/core.pyx", line 846, in cupy._core.core._ndarray_base.repeat
  File "cupy/_core/core.pyx", line 854, in cupy._core.core._ndarray_base.repeat
  File "cupy/_core/_routines_manipulation.pyx", line 256, in cupy._core._routines_manipulation._ndarray_repeat
  File "cupy/_core/_routines_manipulation.pyx", line 560, in cupy._core._routines_manipulation._repeat
  File "cupy/_core/internal.pyx", line 438, in cupy._core.internal._normalize_axis_index
numpy.exceptions.AxisError: axis 0 is out of bounds for array of dimension 0

Installation
Wheel (pip install cupy-***)
Environment
OS                           : Linux-5.15.0-94-generic-x86_64-with-glibc2.35
Python Version               : 3.12.3
CuPy Version                 : 13.3.0
CuPy Platform                : NVIDIA CUDA
NumPy Version                : 2.1.3
SciPy Version                : None
Cython Build Version         : 0.29.36
Cython Runtime Version       : None
CUDA Root                    : /usr/local/cuda
nvcc PATH                    : /usr/local/cuda/bin/nvcc
CUDA Build Version           : 12060
CUDA Driver Version          : 12040
CUDA Runtime Version         : 12060 (linked to CuPy) / 12010 (locally installed)
CUDA Extra Include Dirs      : []
cuBLAS Version               : 120100
cuFFT Version                : 11002
cuRAND Version               : 10302
cuSOLVER Version             : (11, 4, 5)
cuSPARSE Version             : 12002
NVRTC Version                : (12, 1)
Thrust Version               : 200600
CUB Build Version            : 200600
Jitify Build Version         : <unknown>
cuDNN Build Version          : 8801
cuDNN Version                : 8900
NCCL Build Version           : 21602
NCCL Runtime Version         : 21701
cuTENSOR Version             : None
cuSPARSELt Build Version     : None
Device 0 Name                : NVIDIA GeForce RTX 4090 D
Device 0 Compute Capability  : 89
Device 0 PCI Bus ID          : 0000:A8:00.0

Additional Information
No response

Let's discuss this one altogether in #8748.


Decompress .lzo file for access to raw data

I work on a windows machine. I am unable to decompress the .lzo file. 7-zip's error message is "Cant open file as archive".
I am able to open the .yml files though.

yes, Windows does not have great support for LZO, I don't know what others are using, worst case, you could install WSL (https://learn.microsoft.com/en-us/windows/wsl/about) and use the Linux tools (which are native) to get access to the data.

Good day,
Probably the problem was already solved. I found this software for Windows you can run from cmd to extra the raw data from lzo files: http://www.lzop.org/
Just type on CMD:
lzop -d filename.lzo
If you found a better solution please let me know.

Thanks for this clarification.
I have another question.
I see only one .raw file when I acquire in OA mode.
Is only OA image saved. Is the US image not saved when I save in OA mode.
Regards,
Viji

From: Julian Rene Cuellar Buritica @.>
Sent: Friday, March 1, 2024 13:03
To: clariusdev/raw @.>
Cc: Periyasamy, Vijitha [E CPE] @.>; Author @.>
Subject: Re: [clariusdev/raw] Decompress .lzo file for access to raw data (Issue #22)
Good day,
Probably the problem was already solved. I found this software for Windows you can run from cmd to extra the raw data from lzo files: http://www.lzop.org/
Just type on CMD:
lzop -d filename.lzo
If you found a better solution please let me know.
—
Reply to this email directly, view it on GitHubhttps://github.com/clariusdev/raw/issues/22#issuecomment-1973760318, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFUG5EXYBZI53LYQQWJARA3YWDGILAVCNFSM6AAAAABCMSQ356VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZTG43DAMZRHA.
You are receiving this because you authored the thread.Message ID: @.***>

B-images are not included in the raw file archives. Get the b-images from cloud or export from app.

How l do have access to raw data.
In OAmode adter extraction, I see only one data. I assume it is for OA. Is US not saved.

From: Julien Lemaitre @.>
Sent: Monday, March 4, 2024 5:49:18 PM
To: clariusdev/raw @.>
Cc: Periyasamy, Vijitha [E CPE] @.>; Author @.>
Subject: Re: [clariusdev/raw] Decompress .lzo file for access to raw data (Issue #22)
B-images are not included in the raw file archives. Get the b-images from cloud or export from app.
—
Reply to this email directly, view it on GitHubhttps://github.com/clariusdev/raw/issues/22#issuecomment-1977677076, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFUG5EVDR44XDXYTTI7NXITYWUB75AVCNFSM6AAAAABCMSQ356VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXGY3TOMBXGY.
You are receiving this because you authored the thread.Message ID: @.***>

i just tested, seems okay, you should see 2 raw data types in the .tar file


[Metric][Http Interface] Aggregate metric for any metric label

Proposed changes
Tablet has 5 metrics to record read/write statistic data.
IntCounter* query_scan_bytes;
IntCounter* query_scan_rows;
IntCounter* query_scan_count;
IntCounter* flush_bytes;
IntCounter* flush_count;
It is meaningful to get these read/write data to find zero-read/write or hot-read/write table and partition. But in these metrics, it has tablet id information, but no table id/partition id information. Therefore this PR add table id/partition id for these 5 metrics. On the other side, there are maybe hundred thousands of tablet. It is difficult to get these metrics directly by http interface. There this patch provide a aggregate http interface. It can aggregate metric data according to metric label.
It is diffcult to write some unit tests to test this patch. Therefore, it is only be tested in offline running system.
Usage:
http://localshot:8040/metrics?type=aggregate&entity_type=tablet&metric_name=query_scan_bytes&aggregate_label=table_id
type: json/prometheus/aggregate
entity_type: tablet/server
metric_name: the name of one metric, like flush_count
aggregate_lable: aggregate metric by  which metric label
Types of changes
What types of changes does your code introduce to Doris?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)
[ ] Code refactor (Modify the code structure, format the code, etc...)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] I have created an issue on (Fix #ISSUE) and described the bug/feature there in detail
[ ] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If these changes need document changes, I have updated the document
[ ] Any dependent changes have been merged

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

Usage:
http://localshot:8040/metrics?type=aggregate&entity_type=tablet&metric_name=query_scan_bytes&aggregate_label=table_id

If I want to collect all the 5 metrics, I have to request 5 times?

Usage:
http://localshot:8040/metrics?type=aggregate&entity_type=tablet&metric_name=query_scan_bytes&aggregate_label=table_id

If I want to collect all the 5 metrics, I have to request 5 times?

Yes, this http interface supports to aggregate the label of one metric, not the metric self.

Usage:
http://localshot:8040/metrics?type=aggregate&entity_type=tablet&metric_name=query_scan_bytes&aggregate_label=table_id

If I want to collect all the 5 metrics, I have to request 5 times?

Yes, this http interface supports to aggregate the label of one metric, not the metric self.

Why not aggreate all metrics whose entity is type of 'entity_type' and contains 'aggregate_label', it would be more general.


Sql to post

Fixes #234
kindly review it and let me know if something needs to be included :)

If mysql is not longer supported I think database.mysql.example.yml can be safely removed.

ya --pg is not necessaery and i renamed the database.mysql.example.yml to database.example.yml

Amansingla97:sql_to_posT

Amansingla97:sql_to_post

Amansingla97:sql_to_post

@tachyons kindly see and merge :)
let me know if something needs my attention

Remove sample pg database config file as it is no longer relevant

Also docker

@tachyons Done


Segfault on invoke of interface methods

During testing of the _jcollection classes, retainAll resulted in a hard crash on windows.   Unable to get a core dump as of yet.

It was a repeat of the bug that I thought I was testing against a few days back.  JPype used CallNonvirtual* methods of JNI.  This is fine if the method actually exists.  But if the method is abstract well down goes the JVM.  It took forever to debug because most of the crashes went down so hard that error log was dying in some place like the garabage collector or the interrupt handler.  Finally got one attempt to crash with a meaningful backtrace and ran it to ground.