How to visualize basic-multiple-line-chart in HiGlass?

Commit:
I am working on adding a track to my HiGlass session where I can view both a and b allele frequencies in the same track. According to the document, the track type I want is basic-multiple-line-chart. My issue is that I cannot get the data to visualize as a multiple line chart, it only will visualize as a horizontal-multivec. I have tried a variety of different file types ingested into HiGlass to get the visualization I desire; however, I am not having success.
Steps to reproduce

Start with a sorted .bed file that is binned to 100Kb and has 5 columns separated by tabs with no header. Here is an example:
chr10	100000	200000	0.4556	0.5444
chr10	200000	300000	0.3040	0.6960
chr10	300000	400000	0.4202	0.5798
chr10	400000	500000	0.5160	0.4840

The first column is chr name, second column is start, third column is end, fourth column is a allele frequency, and fifth column is b allele frequency.

Convert the .bed file to a .h5 file using this python script:

import numpy as np
import h5py
import pandas as pd
# Load your data
data = pd.read_csv('temp_3.bed', sep='\t', header=None)
data.columns = ['chr', 'start', 'end', 'value1', 'value2']  # Adjust column names based on your actual data
# Create the HDF5 file
with h5py.File('output_3.h5', 'w') as f:
    # Iterate over each chromosome present in your data
    for chromosome in data['chr'].unique():
        # Filter data for the current chromosome
        chr_data = data[data['chr'] == chromosome]
        # Assuming you want to create a dataset for each chromosome
        # and each row in your dataset corresponds to a genomic position (this may need adjusting depending on your data resolution and needs)
        num_positions = chr_data.shape[0]
        num_values_per_position = 2  # change this based on how many metrics you have (e.g., 'value1', 'value2')
        # Create a dataset for this chromosome
        d = f.create_dataset(chromosome, (num_positions, num_values_per_position), compression='gzip')
        # Fill the dataset with values from your DataFrame
        d[:] = chr_data[['value1', 'value2']].values
# Close the file
f.close()

Then use clodius to generate the multivec file:

clodius aggregate multivec \
    --chromsizes-filename hg38.chrom.sizes \
    --output-file alleles_3.multivec \
    --starting-resolution 100000 \
    --row-infos-filename sampled_info.txt \
output_3.h5

Ingest into HiGlass:

higlass-manage ingest ~/PGScratch/higlass/alleles_3.multivec --filetype multivec --datatype multivec --assembly hg38

From my local Docker container, I open up the HiGlass session in a browser and add to the top track the file I ingested. It auto selects the multivec track type. I am also able to select the horizontal-stacked-bar track type. When I try to select the basic-multiple-line-chart, the track appears empty and in red text says "Unknown track type: basic-multiple-line-chart".

In the event it is useful, here is the config JSON file:
{
  "editable": true,
  "zoomFixed": false,
  "trackSourceServers": [
    "/api/v1",
    "http://higlass.io/api/v1"
  ],
  "exportViewUrl": "/api/v1/viewconfs/",
  "views": [
    {
      "tracks": {
        "top": [
          {
            "type": "multivec",
            "uid": "BLEAV2xBQJayStcH6Erh9A",
            "tilesetUid": "ZCcOywRETdKHDbgwFIJFdg",
            "server": "http://localhost:8989/api/v1",
            "options": {
              "labelPosition": "topLeft",
              "labelColor": "black",
              "labelTextOpacity": 0.4,
              "valueScaling": "linear",
              "trackBorderWidth": 0,
              "trackBorderColor": "black",
              "name": "alleles_final.multivec",
              "lineStrokeWidth": 2,
              "height": 140,
              "linePlot": true,
              "showMousePosition": true,
              "mousePositionColor": "#000000",
              "showTooltip": true,
              "colorRange": [
                "red",
                "blue"
              ],
              "labelLeftMargin": 0,
              "labelRightMargin": 0,
              "labelTopMargin": 0,
              "labelBottomMargin": 0,
              "labelShowResolution": true,
              "labelShowAssembly": true,
              "minHeight": 100,
              "heatmapValueScaling": "log",
              "selectRows": null,
              "selectRowsAggregationMode": "mean",
              "selectRowsAggregationWithRelativeHeight": true,
              "selectRowsAggregationMethod": "client",
              "colorbarBackgroundColor": "#ffffff",
              "colorbarPosition": "topRight",
              "zeroValueColor": null,
              "scaleStartPercent": "0.00000",
              "scaleEndPercent": "1.00000",
              "colorScale": [
                "#FF0000",
                "#FF4500",
                "#32CD32",
                "#008000",
                "#006400",
                "#C2E105",
                "#FFFF00",
                "#66CDAA",
                "#8A91D0",
                "#CD5C5C",
                "#E9967A",
                "#BDB76B",
                "#808080",
                "#C0C0C0",
                "#FFFFFF"
              ]
            },
            "width": 1864,
            "height": 140
          }
        ],
        "left": [],
        "center": [],
        "right": [],
        "bottom": [],
        "whole": [],
        "gallery": []
      },
      "initialXDomain": [
        570195360.320572,
<PHONE_NUMBER>.0462747
      ],
      "initialYDomain": [
        960113469.7621747,
<PHONE_NUMBER>.8796444
      ],
      "layout": {
        "w": 12,
        "h": 12,
        "x": 0,
        "y": 0,
        "moved": false,
        "static": false
      },
      "uid": "V5KbQEqGTmmnYS3K70EtYQ"
    }
  ],
  "zoomLocks": {
    "locksByViewUid": {},
    "locksDict": {}
  },
  "locationLocks": {
    "locksByViewUid": {},
    "locksDict": {}
  },
  "valueScaleLocks": {
    "locksByViewUid": {},
    "locksDict": {}
  }
}

Observed behavior

The observed behavior is a multivec file ingested to HiGlass only offering me a view of either multivec or horizontal stacked bar.

Expected behavior

I am expecting see something similar to this:

which is the image included to the side of the Multiple Lines in the Docs. Any advice or perhaps an example of the JSON config file and or test data to visualize the track as I am trying to do would be great.

Best!

Thanks for the detailed writeup! I can reproduce the issue here:
http://higlass.io/l/?d=LwnRPeHhT0GNp48p240o5g
It looks like it's a bug in the higlass-multivec track. I tried to look further into it but ran into issues compiling the package. I'll spend a bit more time on it. Please poke here or on Slack if you don't get a response in the next few days.

Spent a bit of time looking at it. I think the implementation is painfully outdated. I'll work on bringing it up to date.


Add: Factorial Trailing Zeroes

Codecov Report

Merging #396 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #396   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files         144    145    +1
  Lines        1440   1444    +4
=====================================
+ Hits         1440   1444    +4

Impacted Files
Coverage Δ

...orial-trailing-zeroes/factorial_trailing_zeroes.go
100% <100%> (ø)

Continue to review full report at Codecov.

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


Test the github Pages published token timeliness

There's a token being published in https://sigstore-conformance.github.io/extremely-dangerous-public-oidc-beacon/oidc-token.txt now. Before we use it in sigstore-conformance, let's test it a bit (as @tnytown mentioned in PR comment Pages might have its own issues with publishing timeliness).
I tested this for a while in my own fork before th PR and it seemed to update pretty well, but the token in this projects Pages right now seems funky: I will investigate.
More specific notes:

current token remained the same for 4 hours in github pages (with request header "Cache-Control: no-cache") but is now updating fine again
the workflows claim the Pages publish worked fine all that time
based on response headers this comes from Fastly CDN

A couple of options:

I used a broken CDN endpoint (but somehow only for this specific project?)
GitHub claims that Pages upload limits do not apply to uploads from GH Actions... they still might. I've tested for several hours at a time before, but maybe the limit only comes up after a longer time (looks like token publishing may have stopped after ~13 hours of publishing here). Would be very annoying if the workflow succeeds but they still cancel the upload...

maybe the limit only comes up after a longer time

I think this may be true. I've enabled workflows on my fork again and am testing both this project and my fork:

my forks Pages has consistently served fresh or almost fresh tokens: 5 mins 32 secs is the oldest token so far today
this project has had multiple "outages" when the Pages token is not updated  for an hour or more

I'll take another look tomorrow when my fork should also have hit whatever limits there may be

There's definitely something weird going on. After two days of testing (running a script that checks the token every 10 seconds):

My fork has had fresh tokens available on GitHub Pages almost 100% consistently: The oldest token I've seen has been 6 minutes old
This repository has had several multihour "outages" where the token on GitHub Pages has not been updated even though the workflows have run successfully

I'll investigate this later but the Pages published token is definitely not usable for sigstore-conformance at the moment.

This is a dead end: Pages publishing is not reliable for this. I will file a new issue for the git commit approach


HARP-5782: Fix labels rendering distance constraints, improve scaling.

This presents new approach for distance scaling based on camera focus
point distance in opposite to near/far planes relation. Because new
camera clip planes evaluators may change near/far positions dynamically
the old approach does not apply and may provide unacceptable user
experience.
Moreover distance based rendering constraints (limits) are now improved
by providing different constraint (still far plane based) for text and
POI labels. Hardcoded values are now removed.
Signed-off-by: Krystian Kostecki<EMAIL_ADDRESS>Thank you for contributing to harp.gl!
Before requesting a pull request, please remember to check the following documents:

contribution guidelines
coding style

If you are adding new functionality we would highly appreciate if you can describe what is the capability you are adding and even better if you can add some examples. Please also remember to add tests for it.
CI Check
Our bots will check whether your PR can be directly integrated into the mainline. We have some internal integration tests running on the background, our bots will inform you of the next steps and someone from our team will take a look and help if needed!
And please do not forget to sign-off your commit! You can read more about DCO here. But, in short, you just need to use git commit -s or append --signoff when you are committing to the repo.
Happy contributing!

@heremaps-bot retest this please


Fix off-by-one in current thread waker refcount

We just merged https://github.com/async-rs/futures-timer/pull/53; could you perhaps rebase against that? Thanks!

Rebased.


[Fix][Sample-Yaml] Increase ray head CPU resource for pytorch minst

Why are these changes needed?
There is a breaking change from ray:2.9 to ray:2.34.0, the reserved resources for CPUs increased to 3. So the CPU resource for the head pod needs to be increased to reflect this change.
See https://github.com/ray-project/ray/issues/47316 for details.
Related issue number
Closes: ray-project/kuberay#2329
Checks

[x] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[x] Manual tests
[ ] This PR is not tested :(

@kevin85421 @andrewsykim PTAL


如何回滚已发布的应用

您有什么需求，是否与某个功能或问题相关? 请描述
发布后出现生产Bug，需要应急回滚，该如何处理
你想要的解决方案是什么
支持回滚

请你通过留下👍 表情为此issue投票，帮助社区和维护者优先考虑这个请求；

请不要留下 "+1 "或 "me too"的评论，它们会给问题订阅者带来额外的噪音，并且无助于优先处理请求。

如果你有兴趣在这个问题上工作，或者已经提交了pull request，请留下评论.

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request

Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request

If you are interested in working on this issue or have submitted a pull request, please leave a comment.

#143

Notes: This is the proposal type of issue, If you like work on that, please update the design docs and key implementation logic in this issue thread.


add explicit order to doctest to be deterministic

I prefer a semicolon at the end of the SQL statement (and we could make it consistent at some point), but ack!


Update template, rerender

We need a py36  build! This should get us one.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Improve testing

We currently sit around 50% code coverage, we should look to try and bolster our test suite. Some areas that need to be improved but not the only areas to target:

[ ] Github Auth
[ ] Kubernetes Auth
[ ] cmd/utils
[x] cmd/generate

I can take this one too. Or at least update some of the tests.

@jhoover4 go ahead! We could always use improved testing


Rocket animation and dev guide

implement the "rocket" lets get started animation on both web + native
need to set default json asset folder
need to handle svg assets for react-native
need to put assets in correct folder for web, ios, android (use per animation folder structure)
write guide for devs for above process

DOD:

[x] the animation should have 2 segments
[x] the first segment should play only once, second - infinity loop

Checked on the dev env. (v0.16.0)
Look as per requirement.


Provides web northbound API

A request to add a http interface to the northbound interface has been addressed.

https://github.com/nttcom/kuesta/pull/218


Addressed api definition review comments

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


✨ Do not install dagger CLI on runner if already present in PATH unless version: specified and different from installed version

What are you trying to do?
If a GHA runner has dagger CLI pre-installed, the action does not need to install it and should not do so unless the user asks for a particular version like with version: "0.13.7" AND that requested version is different from the already-installed version.
Why is this important to you?

How are you currently working around this?

We actually do this already in dagger/dagger: https://github.com/dagger/dagger/blob/9e0f6aa9eadc90da9f8646726ac4d3ce16b43b69/.github/actions/call/action.yml#L43-L60
We should just be able to grab this logic from there.

LGTM!


Error on running Hugo

Hi nice theme, I get the following error on running with this theme in the console output:

ERROR: 2016/04/23 reflect: call of reflect.Value.Type on zero Value in theme/post/footer-category.html

The error is possibly because your content folder (in your base Hugo folder) has something other than blog and about.md. It seems to me that you have a post folder inside the content folder. Please see the exampleSite folder, your content folder can only have blog and about.md.

Yeah your right, although I do have some markdown consistencies between hugo and hexo, where hexo did not require a --- initial front matter which resulted in no posts being show.  Somehow they are all displayed if I used a different folder than the theme.
I had a folder named post with all my *.md's I then modified the menu sections to point to the new location and all my posts were show, that was when I noticed the errors in the log.
Anyway, Ill follow the correct instructions and fix the front matter, thanks!

Hi Dave, thanks! As for the error, I was able to reproduce it and it turns out the reason you got this error was because the categories variable was not set in the front matter. I'm guessing you may have manually created the Hugo section directory as well as the content markdown files. If you run the hugo new command then the archetype will be used to set the default configuration properties. For example, if you run:
hugo new blog/my-first-post.md

The blog archetype from the theme will be used and set the default variables in the front matter.
If you run this command then the default archetype will be used.
hugo new post/my-first-post.md

I'll be updating the footer-category html file so that the error no longer happens. Thank you for reporting it.


Method to apply the light map to the scene

Add logic to apply the light map and other texture atlas to the whole scene objects.
GVRTexture may be a texture atlas.
This pull request is result of this following comment:
https://github.com/gearvrf/GearVRf-Demos/pull/15#discussion_r54613966
To test it, I have updated the solar system at:
https://github.com/gearvrf/GearVRf-Demos/pull/15
GearVRf-DCO-1.0-Signed-off-by: Ragner Magalhaes<EMAIL_ADDRESS>

code looks good.  works as advertised.


'sudo startxfce4' causes reboot

On the Acer c720 Version 41.0.2272.89 (64-bit), the most recent update to chrome os, I have trusty installed(my chroot is up to date as well).  When I run the command 'sudo startxfce4' the chromebook restarts.

I have the same issue after I switched from the xiwi integration back to x11.

Just updated crouton and having this issue.
crouton: version 1-20150304145447~master:550afdb3
release: trusty
architecture: amd64
xmethod: xorg
targets: x11,keyboard,audio,cli-extra,xiwi,extension,touch,xfce
host: version 6680.64.0 (Official Build) stable-channel link

By scanning down a few, my issue seems to be the same as #1474 with the same version of crouton, and there's a link to #1278 hopefully containing a workaround that I'm trying to catch. @javel , you should check it if you are in the same version.

I tried to roll back to crouton version (1-20150127081428~master:e1bcac2b) which had been used without rebooting until I updated few hours ago, but still it reboots when I run "startxfce4".
Now I wonder it is closely related to previous issue I mentioned above... #1474 seems to be more close to VirtualBox which I don't use. I guess recent update v41 having module_locking removed causing this problem. But still don't understand why didn't I faced this problem at the time of updating chromeos but experiencing reboot after updating crouton.
I'm very cautious in this because it's my working machine although I have backup (which I cannot trust fully) and I cannot try any solution that I don't understand what actually it does. I need some help. Please.

OMG... what's going on here!
chronos@localhost / $ sudo enter-chroot
Enter encryption passphrase for trusty:
Entering /mnt/stateful_partition/crouton/chroots/trusty...
A chroot setup script still exists inside the chroot.
The chroot may not be fully set up.
However, it appears the setup script is invalid.
Removing the chroot setup script. You may want to update your chroot again.
-su: 1: /etc/profile.d/crouton-pulseaudio-cras.sh: kd��:u�: not found
-su: 1: /etc/profile.d/crouton-pulseaudio-cras.sh: hTC?�,�H���D: not found
-su: 1: /etc/profile.d/crouton-pulseaudio-cras.sh: kd��:u�: not found
-su: 1: /etc/profile.d/crouton-pulseaudio-cras.sh: hTC?�,�H���D: not found
-su: 1: /etc/profile.d/crouton-pulseaudio-cras.sh: kd��:u�: not found
-su: 1: /etc/profile.d/crouton-pulseaudio-cras.sh: hTC?�,�H���D: not found
-su: $'kd\026\205\221:u\372': command not found
-su: $'hTC\032\240\024,\024\362H\343\356\300D': command not found
(trusty)lyle@localhost:~$ croutonversion
crouton: version 1-20150127081428~master:e1bcac2b
release: trusty
architecture: amd64
targets: ��Pl�c߸C]y���␋ۼA�┤┼2�.·⎺⎺�\+���)���4�£��S�Q ˔�>
␤⎺⎽├: ┴␊⎼⎽␋⎺┼ 6680.64.0 (O°°␋␌␋▒┌ B┤␋┌␍) ⎽├▒␉┌␊-␌␤▒┼┼␊┌ ┌␋┼┐
(├⎼┤⎽├≤)┌≤┌␊@┌⎺␌▒┌␤⎺⎽├:·$
(├⎼┤⎽├≤)┌≤┌␊@┌⎺␌▒┌␤⎺⎽├:·$

Is the tool you are using to output your version info. 3 posts up edit-chroot? If so, and I doubt this is the cause of your reboot issue, I think that just specifying xfce,xiwi would bring in the dependencies, and leave your defined target list smaller.
Have you tried setting xmethods to xiwi?
Are you prompted to continue running the script or does it just continue?
Since Chrome OS updates can happen automatically, I would keep your data offline on removable media (USB 3 flash drives are very fast), so you can just rebuild your chroots when needed, as there is no simple way to revert.

#1474 is indeed related to virtualbox and has nothing to do with the issue mentioned here. Also the issue mentioned here is in no way related to the removal of the sysfs module_locking. Like @tedm mentioned, try xiwi and see if it is not rebooting anymore. Just to narrow down the cause of the reboot.
Also posting the output of /dev/pstore/console-ramoops could be useful.

@tedm The version info from "croutonversion". And I was not using xiwi but X11. I had tried xiwi but put X11 at the front since X11 gives better usage to me. I don't know what xmethods is but I'll try as soon as xiwi becomes available again. Lastly, I'm sad about my Pixel(1st) does not have USB3.0 interface.
@divx118 I was trying with xiwi an hour ago, but faced another failure with a following error and cannot narrow down.
Fatal server error:
(EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

@midnightradio since it appears you have xiwi as a target, try:
appending -X xiwi to your start* line or set env exec XMETHODS=xiwi
I don't think the order that your targets are in the file have any effect on what starts.
If offline, you can use ~/Downloads and access that data from outside the chroot, but it's not recommended, as it may not always be permanent storage.

@tedm In practice, when x11 positioned before xiwi, desktop environment run in classic way and vice versa. I just tried your advice and confirmed that it is the same as I wrote above by updating the target "xiwi". (Anyway, good to know that there's a simple way to run X11 without updating the target.) As you see, xiwi cannot be a workaround due to another error, "Cannot open /dev/tty0"). Of course I'm trying to solve it but I think the new problem on xiwi is irrelevant this. Thanks for your help.

@midnightradio Thanks for this info. I hope you get running soon.
Can you clarify what you mean by the target position in the front position having priority or running by default?
I just put xiwi in front of my xephyr target in /etc/crouton/targets and my default xmethod is still xephyr:
chronos@localhost /etc $ sudo edit-chroot -al
name: precise
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/precise...
crouton: version 1-20150301132939~master:80da699e
release: precise
architecture: armhf
xmethod: xephyr
targets: xiwi,xephyr,xfce
host: version 6457.107.0 (Official Build) stable-channel daisy
Unmounting /mnt/stateful_partition/crouton/chroots/precise...

@midnightradio OK, this is a long shot, but have you tried removing/purging any/all screensavers in your chroot?

@tedm I've never edited the file /etc/crouton/targets but only put the target prior to others by running command "crouton" with -u and -t. For example, when you run "crouton -u -t x11 -n name" you will get x11 at the front. Also, I've never used any screensaver which has been notorious for something bad. Thanks for developing the issue. I really need a solution...

@midnightradio OK, I answered my own question above about the ordering, after updating -t xfce -u, (all targets in /etc/crouton/targets get updated with -u), the order now has xiwi ahead of xephyr, and xiwi as xmethod (though I can override with -X xephyr on start* command line).
Have you tried creating a chroot with just xfce, letting crouton pick the fastest xmethod and letting crouton install x11? (and xiwi if you want), all of your targets will still be there when you're done, just look at /.crouton-targets when done, or if encrypted, from outside the chroot.
By doubling up on manually specifying each of these, and then crouton having to figure out what is already installed vs what it needs to install as a dependency, could be borking your system.
chronos@localhost / $ sudo edit-chroot -al
name: precise
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/precise...
crouton: version 1-20150304145447~master:550afdb3
release: precise
architecture: armhf
xmethod: xiwi
targets: xfce,xiwi,xephyr
host: version 6680.64.0 (Official Build) stable-channel daisy
Unmounting /mnt/stateful_partition/crouton/chroots/precise...

I also see the 'instant reboot when starting X' - I think this is the relevant part of /dev/pstore/console-ramoops, taken on my (original) Pixel:
$ croutonversion
crouton: version 1-20150304145447~master:550afdb3
release: trusty
architecture: amd64
xmethod: xorg
targets: keyboard,unity,touch,chrome
host: version 6680.64.0 (Official Build) stable-channel link

[   84.996044] BUG: unable to handle kernel NULL pointer dereference at<PHONE_NUMBER>000074
[   84.996089] IP: [<ffffffffb66c8206>] intel_crtc_page_flip+0x33/0x315
[   84.996129] PGD 0
[   84.996157] Oops: 0000 [#1] SMP
[   84.999991] gsmi: Log Shutdown Reason 0x03
[   84.999999] Modules linked in: i2c_dev uinput snd_hda_codec_hdmi aesni_intel xts memconsole snd_hda_codec_ca0132 aes_x86_64 lrw gf128mul ablk_helper cryptd snd_hda_intel snd_hda_codec zram(C) snd_hwdep snd_pcm lzo_compress snd_page_alloc isl29018(C) zsmalloc(C) fuse snd_timer nm10_gpio industrialio nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ath9k_btcoex ath9k_common_btcoex ath9k_hw_btcoex ath mac80211 cfg80211 ath3k uvcvideo btusb videobuf2_vmalloc bluetooth videobuf2_memops videobuf2_core videodev joydev ppp_async ppp_generic slhc tun
[   85.000256] CPU 2
[   85.000267] Pid: 18164, comm: Xorg Tainted: G         C   3.8.11 #1
[   85.000282] RIP: 0010:[<ffffffffb66c8206>]  [<ffffffffb66c8206>] intel_crtc_page_flip+0x33/0x315
[   85.000304] RSP: 0018:ffff8801414f3cb8  EFLAGS: 00010286
[   85.000316] RAX: ffff88014518aa00 RBX: ffff880147bc3200 RCX:<PHONE_NUMBER>000201
[   85.000329] RDX: ffff8800a7968660 RSI: ffff88008fd77240 RDI: ffff88014aab6000
[   85.000340] RBP: ffff8801414f3d00 R08: ffff88008fd77240 R09:<PHONE_NUMBER>000030
[   85.000352] R10:<PHONE_NUMBER>000000 R11: ffffffffb6690ced R12: ffff88014aab5000
[   85.000364] R13: ffff88014aab6000 R14:<PHONE_NUMBER>000000 R15: ffff88014a2c0000
[   85.000378] FS:  00007f05b131e9c0(0000) GS:ffff88014f300000(0000) knlGS:0000000000000000
[   85.000391] CS:  0010 DS: 0000 ES: 0000 CR0:<PHONE_NUMBER>050033
[   85.000403] CR2:<PHONE_NUMBER>000074 CR3: 000000011d2c9000 CR4:<PHONE_NUMBER>1407e0
[   85.000415] DR0:<PHONE_NUMBER>000000 DR1:<PHONE_NUMBER>000000 DR2:<PHONE_NUMBER>000000
[   85.000427] DR3:<PHONE_NUMBER>000000 DR6: 00000000ffff0ff0 DR7:<PHONE_NUMBER>000400
[   85.000442] Process Xorg (pid: 18164, threadinfo ffff8801414f2000, task ffff88012e077080)
[   85.000454] Stack:
[   85.000462]  ffffffffb669d776 ffff88008fd77240<PHONE_NUMBER>000030 ffff88008fd77240
[   85.000489]  ffff880147bc3200 ffff88014a26e600 ffff88014aab6000 ffff880147bc3e00
[   85.000514]  ffff880147bc3400 ffff8801414f3d48 ffffffffb669dcef<PHONE_NUMBER>000000
[   85.000540] Call Trace:
[   85.000554]  [<ffffffffb669d776>] ? commit_crtc_state+0x3e/0x21c
[   85.000579]  [<ffffffffb669dcef>] commit_plane_state+0x215/0x280
[   85.000591]  [<ffffffffb669d482>] atomic_commit.isra.3+0x93/0xb4
[   85.000601]  [<ffffffffb669d4b4>] drm_atomic_commit+0x11/0x13
[   85.000611]  [<ffffffffb66963e2>] drm_mode_page_flip_ioctl+0x1bd/0x230
[   85.000621]  [<ffffffffb6686006>] drm_ioctl+0x2f5/0x3d2
[   85.000629]  [<ffffffffb6696225>] ? drm_mode_gamma_get_ioctl+0xc7/0xc7
[   85.000640]  [<ffffffffb65de5ae>] ? timerqueue_del+0x52/0x5a
[   85.000650]  [<ffffffffb6453171>] ? __remove_hrtimer+0x34/0x8d
[   85.000660]  [<ffffffffb64536fe>] ? hrtimer_try_to_cancel+0x95/0xb5
[   85.000669]  [<ffffffffb64f7eeb>] do_vfs_ioctl+0x362/0x425
[   85.000678]  [<ffffffffb64f88e7>] ? poll_select_copy_remaining+0xf5/0x120
[   85.000686]  [<ffffffffb64f801b>] sys_ioctl+0x6d/0xa5
[   85.000696]  [<ffffffffb68ba502>] system_call_fastpath+0x16/0x1b
[   85.000703] Code: e5 41 57 41 56 41 55 41 54 53 48 83 ec 20 48 8b 87 b8 00 00 00 4c 8b 27 4c 8b 70 50 48 8b 86 90 00 00 00 4d 8b bc 24 f0 03 00 00 <41> 8b 5e 74 39 5e 74 48 89 45 d0 b8 ea ff ff ff 0f 85 bd 02 00
[   85.000883] RIP  [<ffffffffb66c8206>] intel_crtc_page_flip+0x33/0x315
[   85.000895]  RSP <ffff8801414f3cb8>
[   85.000901] CR2:<PHONE_NUMBER>000074
[   85.000941] ---[ end trace 08cbcbe56779f4ed ]---
[   85.006069] Kernel panic - not syncing: Fatal exception
[   85.006084] Kernel Offset: 0x35400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[   85.006227] gsmi: Log Shutdown Reason 0x02
[   85.011367] ACPI MEMORY or I/O RESET_REG.

I'm about to file a kernel bug for this, but if you're experiencing this issue can you check whether or not you're using freon (the new X-less way of running Chrome)?
The easiest way to check is to open VT2 (CTRL + ALT + Forward/F2). If you see the text "Welcome to frecon!" at the top, you're using freon. You can return to Chrome with CTRL + ALT + Previous/F1.

@smibarber I am experiencing the issue, and I don't see that text on VT2.

Thanks! Upstream bug filed: https://code.google.com/p/chromium/issues/detail?id=466774
As always, if you want to follow the issue feel free to star it, but please keep commentary and discussion on Github.

I got the same issue with sudo startlxde (causing reboot) after updating crouton.
I'm running trusty with LXDE on a HP Chromebook 14. Everything is fine after updating ChromeOS and before updating crouton.
Someone at https://plus.google.com/102016847086903746448/posts/JfYjzwwr5TT?cfem=1 said that xiwi might help. I installed the extention and tried to add xiwi, yet I got the following error:

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
xserver-xorg-dev : Depends: mesa-common-dev
E: Unable to correct problems, you have held broken packages.
Failed to complete chroot setup.

I had tried using xiwi with the extension, no luck
what fixed the issue for me was found here
https://github.com/dnschneid/crouton/issues/1265
specifically i used the command
sudo CROUTON_BRANCH=x11_freon sh ~/Downloads/crouton -t xfce -n trusty -u
this switched the branch and updated my chroot and works with chrome os Version 41.0.2272.89 (64-bit)

Please leave this open until the root cause is identified. x11_freon is a dead branch that's been merged into master, so you'll want to move off of it once this is fixed. It's a good data point that it works though, should help with finding the root cause.

How do I run : sudo CROUTON_BRANCH=x11_freon sh ~/Downloads/crouton -t xfce
-n trusty -u ?
I get : /tmp/crouton-installer-cache/crouton-x11_freon: 1: {error:Not
Found}: not found
On Fri, Mar 13, 2015 at 4:49 AM, Stephen Barber<EMAIL_ADDRESS>wrote:

Please leave this open until the root cause is identified. x11_freon is a
dead branch that's been merged into master, so you'll want to move off of
it once this is fixed. It's a good data point that it works though, should
help with finding the root cause.
—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/1490#issuecomment-78686970.

@tedm Regarding to your suggestion, I installed another chroot with just xfce, and could successfully ran startxfce4 on that chroot. chroot named "trusty" is the one making me sad and the later "trusty-xfce" is the new.
chronos@localhost / $ sudo edit-chroot -al
name: trusty
encrypted: yes, unlocked
Enter encryption passphrase for trusty:
Entering /mnt/stateful_partition/crouton/chroots/trusty...
crouton: version 1-20150304145447~master:550afdb3
release: trusty
architecture: amd64
xmethod: xorg
targets: x11,xiwi,keyboard,audio,cli-extra,extension,touch,xfce
host: version 6680.64.0 (Official Build) stable-channel link
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
name: trusty-xfce
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/trusty-xfce...
crouton: version 1-20150304145447~master:550afdb3
release: trusty
architecture: amd64
xmethod: xorg
targets: xfce
host: version 6680.64.0 (Official Build) stable-channel link
Unmounting /mnt/stateful_partition/crouton/chroots/trusty-xfce...
chronos@localhost / $

@midnightradio interesting. I am not really sure what's going on here, but your new chroot seems to have been installed in a cleaner manner, in that you only specified xfce, and let Crouton bring in the dependent targets.
Are you able to enter-chroot to recover your data from your first chroot, and move it to the newly created one?

@tedm Thanks again for responding. I cannot think of moving only data from first chroot to the other because it's almost impossible to move all environmental dependencies that I have had for my work, such like compiler libraries and other preferences.
Anyway, with the other chroot newly installed only with a target xfce, I could successfully run startxfce4 on xorg as a default, as I mentioned earlier. After that, I became curious about what happens on "xiwi" with the new chroot as I had trouble with old chroot getting an error "Cannot open /dev/tty0". So I added the target "xiwi" on the new chroot and there was no problem running xfce on xiwi either. Then I just added one more target "unity" with no reason but just for fun and "xiwi" on new chroot started to show the same error, "Cannot open /dev/tty0", but startunity/startxfce are still available with xorg.
This odd happenings may not be relevant to the rebooting issue, but there must be some conflicts between targets. I wonder if I can remove every targets at once and start to add one by one again.

@midnightradio I hope that your testing can help the developers in some way. There have been a couple of requests to have a frozen stable "crouton" but those feature requests got closed, either due to design or resource issues, or the fact that if ChromeOS has a rolling release that is difficult to downgrade, then you can't just tarball one part, you basically have to image your drive. I used to use Arch a lot, and still occasionally use it either stand alone or with Manjaro, but the rolling releases (Pacman -Syu) will kill me about 5% of the time and cause a lot of reverting. Crouton, fortunately has a larger testing base, but as we can see, it still doesn't eliminate all needs to revert, since the ChromeOS updates are frequent, and sometimes quirky... I also wish ChromeOS would provide an option (even if in dev mode only) where one could select when to update, so if things were working fine, and the updates weren't security or data loss related, I could wait for a long weekend... I hope you can get your chroot running, but I don't know of a way to selectively just remove unity or specific targets from an existing chroot,.

@midnightradio You may want to ask Maurice @divx118 @drinkcat or @DennisLfromGA if editing the /etc/crouton/targets and/or the /.crouton-targets and then doing an update will sort of remove or change priority of a target associated with a chroot after doing an -u upgrade. Or if your 2nd chroot is just a test chroot, maybe just give it a try...

@midnightradio another couple of long shots you might want to try - have you tried plugging a 2nd display into your system? What happens if you try to start your chroot with xephyr (might have to add it first), then startxfce4 -n [chrootnamethatwontopen] -X xephyr ?

@tedm I feel guilty for bothering others by commenting irrelevant things, but I think I found something presumably help people.
The error, "Cannot open /dev/tty0", on running xiwi was not caused by a conflict between targets but caused by a configuration file, /usr/share/X11/xorg.conf.d/10-monitor.conf which I have kept for customizing screen resolution. I found that xiwi refers to /etc/X11/xorg-dummy.conf while other XMETHODs don't. So I simply removed the file and I could run both startxfce4 and startunity over xiwi.
Now I can continue with my work. Thanks!

@midnightradio Wow, glad you got it running!! That's odd, since I thought xorg and xiwi were working on your test chroot, until you added the unity target? I think the xorg-dummy.conf file was needed to keep updates from breaking, and the ARM systems never ran xorg, only xephyr, soon to be freon.

Try running sudo apt-get install --reinstall xserver-xorg-core in your affected chroots. I think the fix for #1450 is at fault, but weirdly only for upgraded chroots.

@smibarber That worked! Thanks.

@smibarber reinstalling xserver-xorg-core confirmed working here too - thanks.

how do I 'sudo apt-get install --reinstall xserver-xorg-core'? I get 'sudo: apt-get: command not found'. I have the same problem when I type sudo startxfce4 my chromebook restarts. I have the C720 and I have upgraded from precise to trusty.

@tromso -
It should be done from inside your chroot -
1st - Enter sudo enter-chroot
2nd - Enter sudo apt-get install --reinstall xserver-xorg-core

@DennisLfromGA that fixed it, thank you so much, I was about to powerwash when you wrote.

Cool! Glad I could help. ;)

@smibarber @DennisLfromGA: `sudo apt-get install --reinstall xserver-xorg-core' worked. Thank you!

Thanx for the fix @smibarber, it looks like a winner.

Thank you @smibarber, the startxfce4 back to work! But I am no longer able to switch between ChromeOS and xfce via Ctrl+Alt+Shift+Back/Forward. How to fix this,  any idea?

Hi, Folks.   A Crouton update hosed my Trusty.  Hopefully this topic is the right place to post.  First, my specs:

ASUS Chromebox
Version 41.0.2272.76 (64-bit)
Platform 6680.58.0 (Official Build) stable-channel panther
Firmware Google_Panther.4920.24.26
My chroot: NOTE: this is from a backup subsequently restored after my attempted update earlier today, which resulted in the same startxfce-reboot behaviour described at the top of this topic.
name: trusty
encrypted: no
Entering /media/removable/chroots2/main/chroots/trusty...
crouton: version 1-20150127081428~master:e1bcac2b
release: trusty
architecture: amd64
targets: xfce
host: version 6680.58.0 (Official Build) stable-channel panther
I received the ChromeOS 41 update about a week ago, maybe more, and I expected it to break crouton (thanks to the Freon changes) but it didn't.  Everything continued to work fine without requiring me to update Crouton or do any maintenance.
Today I decided to update Crouton.  Crouton ran its update without issue.  Then when attempting to boot into Trusty I got the dreaded hard crash/reboot issue.
I immediately restored from a backup taken yesterday.  I can now boot into Trusty, but the graphics are busted: I get to the desktop but then everything is almost entirely frozen or at least hugely laggy other than the mouse cursor which is unaffected.  So I'm unable to run what might be the fix of "sudo apt-get install --reinstall xserver-xorg-core" because I can't paste that into a terminal, due to the extreme graphical lag.
What I would like to do is run an old Crouton update rather that the current one that breaks my Trusty, e.g. go back to "version 1-20150127081428~master:e1bcac2b" which I know worked just fine.  I'm happy to do a powerwash if need be.
Can I get instructions on how to revert to an earlier version of Crouton, thanks!

Hi @belzecue , is your graphics problem looks like following? I had captured this when I was having the problem and fortunately got recovered.

chronos@localhost / $ sudo sh ~/Downloads/crouton -u -n trusty
Password:
/usr/local/chroots/trusty already exists; updating it...
Preparing chroot environment...Previously installed target
'ï¿1⁄2ï¿1⁄2Plï¿1⁄2cß ̧C]yï¿1⁄2ï¿1⁄2ï¿1⁄2â�‹Û1⁄4Aï¿1⁄2â”¤â”1⁄42ï¿1⁄2.Â·âŽoâŽoï¿1⁄2\+ï¿1⁄2ï¿1⁄24ï¿1⁄2Â£ï¿1⁄2ï¿1⁄2Sï¿1⁄2Q Ë”ï¿1⁄2>' â”1⁄4âŽo â”ŒâŽoâ”1⁄4Â±â�ŠâŽ1⁄4 â�Šâ”‚â�‹âNâŽo â”œâ–’âŽ1⁄4Â±â�Šâ”œ â”Œâ�‹âŽ1⁄2â”œ Â°âŽoâ”¤â”1⁄4â�� (â‰¤âŽoâ�Œâ�¤âŽ1⁄4âŽoâŽoâ”œ â””â–’â‰¤ â�‰â�Š â” ́â�ŠâŽ1⁄4â‰¤ âŽoâ”ŒâPâ”Œâ�Šâ–’âŽ1⁄2â�Š âŽ1⁄2âŽ»â�Šâ�Œâ�‹Â°â‰¤ â”œâ–’âŽ1⁄4Â±â�Šâ”œâ”¬â�‹â”œâ�¤ -â”œ.
â�Œâ�¤âŽ1⁄4âŽoâ”1⁄4âŽoâŽ1⁄2@â”ŒâŽoâ�Œâ–’â”Œâ�¤âŽoâŽ1⁄2â”œ /

@midnightradio No, the Crouton update I performed earlier today completed normally and without issue.  There was no corruption/garbage in the command window like what you posted.

@belzecue can you sudo enter-chroot and run:
sudo apt-get install --reinstall xserver-xorg-core
from a crosh shell terminal without bringing up a graphical desktop of your chroot?

@tedm  Just now I was able to log in to terminal via enter-chroot and run the reinstall, which completed without issue.  But when I boot into Trusty (xfce) it exhibits the same issue: top half of screen paints, then bottom half paints half a second later, and I see my usual desktop.  Mouse is working normally.  However, clicking on any graphical element causes a long delay before it appears, and then everything basically freezes other than the mouse.  All I can do is switch back to ChromeOS.

@belzecue what is your xmethod? edit-chroot -al will show it. Have you tried adding the xiwi target? Updating the chroot?

Based on discussion in: https://plus.google.com/+FrancoisBeaufort/posts/JDVkXALPcNq
I ran:
sudo sh ~/Downloads/crouton -u -r trusty -t xiwi,xfce
which updated my Trusty chroot.
Now, typing: sudo startxfce4 -c /media/removable/chroots2/main/chroots
gives...

Entering /media/removable/chroots2/main/chroots/trusty...
/usr/bin/startxfce4: Starting X server
X.Org X Server 1.15.1
Release Date: 2014-04-13
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-76-generic x86_64 Ubuntu
Current Operating System: Linux localhost 3.8.11 #1 SMP Mon Mar 2 06:44:29 PST 2015 x86_64
Kernel command line: cros_secure console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2506752 verity payload=PARTUUID=88f8160b-af43-3a47-9f41-4619d12b570f/PARTNROFF=1 hashtree=PARTUUID=88f8160b-af43-3a47-9f41-4619d12b570f/PARTNROFF=1 hashstart=2506752 alg=sha1 root_hexdigest=741ce042d3b8474b67d4a226473443a361c9ad05 salt=a5244d04421135d9c9dcaa10bc5213664528aaf0c8743b167039eabaad46a108" noinitrd vt.global_cursor_default=0 kern_guid=88f8160b-af43-3a47-9f41-4619d12b570f add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic
Build Date: 12 February 2015  02:49:29PM
xorg-server 2:1.15.1-0ubuntu2.7 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.30.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/Xorg.crouton.1.log", Time: Sun Mar 15 15:24:08 2015
(++) Using config file: "/etc/X11/xorg-dummy.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension SECURITY
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension Present
Initializing built-in extension DRI3
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
Initializing built-in extension SELinux
Initializing built-in extension XFree86-VidModeExtension
Initializing built-in extension XFree86-DGA
Initializing built-in extension XFree86-DRI
Initializing built-in extension DRI2
Loading extension GLX
Unable to set master
xf86: found device 0
/usr/bin/xinit: XFree86_VT property unexpectedly has 0 items instead of 1
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Unable to start display, make sure the crouton extension is installed
and enabled, and up to date. (download from http://goo.gl/OVQOEt)
Running exit commands...
/usr/bin/xinit: connection to X server lost
waiting for X server to shut down Hangup
Hangup
Hangup
(EE) Server terminated successfully (0). Closing log file.
Unmounting /media/removable/chroots2/main/chroots/trusty...
Sending SIGTERM to processes under /media/removable/chroots2/main/chroots/trusty...

@belzecue do you have the chrome Crouton extension installed from the web store?

@belzecue , I can see that you provided another chroot information while you put log messages for startxfce4 running on the chroot stored in removable disk. Option "-a" show only chroot stored in "/mnt/.../chroots", so you may specify the removable disk by giving option "-c" to edit-chroot or first enter-chroot than run croutonversion. Ah, but your only option is edit-chroot since your current state does not effectively allow you to enter-chroot,..
But I also can see that you have up-to-date version of crouton. Actually, what you have done with restoring the backup was different from what I did, which turned out not resolving the rebooting issue but at least it was enough to give normal usage after entering chroot. What I actually did was downloading old crouton (https://github.com/dnschneid/crouton/commits/releases/crouton) and running the update without restoring my backup chroot. Maybe you can try in the same way. You may experience the rebooting issue again, but at least you can run some command after entering chroot. And this time, better not to follow #1474 but just reinstall "xserver-xorg-core".

Ah, I did not have the chrome Crouton extension installed.  https://chrome.google.com/webstore/detail/crouton-integration/gcpneefbbnfalgjniomfjknbcgkbijom
To recap today's events:

updated Crouton, which broke my Trusty chroot with the hard-crash/reboot upon entering chroot
restored chroot from a backup
entered chroot terminal then: sudo apt-get install --reinstall xserver-xorg-core
added 'xiwi' target to my chroot: sudo sh ~/Downloads/crouton -u -r trusty -t xiwi,xfce
installed Crouton extension from Chrome web store
chroot now successfully runs in a Chrome tab: sudo startxfce4 -b -c /media/removable/chroots2/main/chroots

That's great -- to at least have it up and running again.  But does this mean I can't run it in its own x11 session any more?  Running it in a Chrome tab feels a bit sluggish.

@belzecue have you tried adding -X xorg at the end of your start-up command?

@Watney
chronos@localhost / $ sudo startxfce4 -b -c /media/removable/chroots2/main/chroots -X xorg
/media/removable/chroots2/main/chroots/trusty does not contain XMETHOD 'xorg'
name: trusty
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/trusty...
crouton: version 1-20150304145447~master:550afdb3
release: trusty
architecture: amd64
xmethod: xiwi
targets: xiwi,xfce
host: version 6680.58.0 (Official Build) stable-channel panther
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
I'm guessing I have to get 'xmethod' back to xorg.  I read in the topic above, I can do that with 'set env exec XMETHODS=xorg' ??

@belzecue No, just update your chroot with -t xorg

@Watney @divx118 Same problem: crash/reboot on chroot startup.  Here's what I tried:

sudo sh ~/Downloads/crouton -u -r trusty -t xiwi,xfce,xorg
sudo startxfce4 -c /media/removable/chroots2/main/chroots -X xorg

So, with the current Crouton installer, it appears xorg is no longer working for ASUS Chromeboxes.  Only xiwi target works.
How do I specifically run an older Crouton installer, e.g. 'version 1-20150127081428~master:e1bcac2b' ?  I think if I do a powerwash then run that older version, my Trusty chroot (restored from backup) should will continue to work, seeing how it was all working yesterday prior to me running the latest Crouton script today.

@belzecue sudo startxfce4 -c /media/removable/chroots2/main/chroots -X xorg should work. What doesn't work for you with this command? Error messages? An older installer of crouton will do you no good. It is updates from chromeos that occasionally can brake crouton.

@divx118 I have the same issue as @javel @qvanwu @midnightradio : when trying to startxfce with xorg as target, ChromeOS immediately hard-crashes (power cycle) and reboots.
The only difference between yesterday when everything wasy working and today with the crashing is that today I updated Crouton for the first time in a couple months.  Note that I received Chrome OS v41 (with new Freon) a week or two ago, and it did not adversly affect my ability to chroot into Trusty.

How do I specifically run an older Crouton installer, e.g. 'version 1-20150127081428~master:e1bcac2b'

Is this not possible?

@belzecue - See https://github.com/dnschneid/crouton/issues/1490#issuecomment-80719906

@DennisLfromGA That worked, thank you!

sudo sh ~/Downloads/crouton -u -r trusty -t xfce,xorg
sudo enter-chroot
sudo apt-get install --reinstall xserver-xorg-core
sudo startxfce4 -c /media/removable/chroots2/main/chroots

That great news!
I'm a little surprised crouton doesn't complain when you use '-r trusty' on an update.
Once a chroot is installed, you should replace '-r trusty' with '-n trusty'.

Will do.  That's what my notes say too.  Not sure how the -r crept in there.

All's well that ends well ;)

I've prepared a patch to (hopefully) fix this; brave testers can get the code at https://github.com/smibarber/crouton/tree/undo-vgem-hack
Give it a try and let me know if anything goes wrong.

Stephen,
I'm unclear when this bug/problem appears.
Is it on certain hardware or on a particular Chrome OS version and does the crouton version play in to it?
Sorry for the dumb questions, I was just wondering when & if I might run into it, right now I'm at:
Google Chrome	41.0.2272.74 (Official Build) beta
Revision	0eca4017e2b6ec81e748ff9b136f5f89567367cf
Platform	6680.52.0 (Official Build) beta-channel falco

CrOS 42 (currently dev channel) enabled the vgem module in the kernel for x86 machines, which shows up as a card under /dev/dri/ and causes Xorg to segfault. @dnschneid's workaround fixed Xorg on R42, but appears to cause issues on upgraded (not fresh) chroots on R41 (and maybe R42, but haven't gotten any reports on that front yet).
With the patch I'm about to push, you might run into problems when R42 is promoted from dev to beta. You'll definitely need to crouton -u after updating to R42, since the workaround is necessary on that release. But it may still have issues with upgraded chroots, so do please report back when that update rolls out.

@smibarber,
Thanx for the detailed explanation, I don't think I yet understand all the implications but I'm closer.

but appears to cause issues on upgraded (not fresh) chroots

The above is one point that's still confusing...

I have no idea why that's the case either :( There's probably some state saved somewhere in the chroot that sends Xorg on the path to destruction. I need to figure out what that is before R42 rolls out to beta.
Anyway, latest crouton has been released with a hack workaround for the hack workaround.

@smibarber - Thanx again ;)
What's kind'a strange (although it's happened before), is my HP Chromebook 14 is on a beta channel version which is behind the stable channel version...

@DennisLfromGA That happens sometimes. dev is also sometimes behind beta.

You'll definitely need to crouton -u after updating to R42, since the workaround is necessary on that release.

Well I finally got R42 on my HP Chromebook 14 beta channel and my chroot broke - with the seg fault error. I tried to update it but it kept bailing out 'cause I've got 'xephyr' installed. Once I removed the 'xephyr' target it updated and all is well again.
Would it be advisable to maybe check if, when just doing an update, the xmethod targets would warn instead of exit?

Why did your chroot fail to update with xephyr? That seems problematic...

@smibarber,
The 'xephyr' target checks for frecon and exits if found:
if [ "${TARGETNOINSTALL:-c}" = 'c' -a -f /sbin/frecon ]; then
    error 1 'xephyr target does not work with Freon. Use xiwi instead.'
fi

Yeah we should probably retire targets that are no longer needed. host-x11 is another one that will be dead with freon.

I agree, rather than changing the exit to a warning, maybe just retiring it would be best.

Or we could just ignore invalid targets when updating.

Sounds like a plan...


build_visit restarts don't detect core 3rd party libs

Whenver I want to build Silo against a VisIt installation, I do something like... ./svn_bin/build_visit console novisit silo thirdpartypath /usr/gapps/visit/thirdparty_shared_2_6_0 group visit makeflags -j8 However, this fails in a couple of ways. First, although an HDF5 installation exists at the specified path, build_visit doesn't properly detect that and use it to configure Silo. Likewise for szip. Now, if you add hdf5 and szip to the build_visit command, it will indeed go ahead and find those libs and configure silo with them. Worse, however, it won't work at all with qt to trigger the build of silo's silex tool.
-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.
Ticket number: 1387
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: build_visit restarts don't detect core 3rd party libs
Assigned to: -
Category: -
Target version: -
Author: Mark Miller
Start: 03/19/2013
Due date:
% Done: 0%
Estimated time:
Created: 03/19/2013 01:22 am
Updated: 03/26/2013 01:24 pm
Likelihood: 3 - Occasional
Severity: 2 - Minor Irritation
Found in version: 2.6.1
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
Whenver I want to build Silo against a VisIt installation, I do something like... ./svn_bin/build_visit console novisit silo thirdpartypath /usr/gapps/visit/thirdparty_shared_2_6_0 group visit makeflags -j8 However, this fails in a couple of ways. First, although an HDF5 installation exists at the specified path, build_visit doesn't properly detect that and use it to configure Silo. Likewise for szip. Now, if you add hdf5 and szip to the build_visit command, it will indeed go ahead and find those libs and configure silo with them. Worse, however, it won't work at all with qt to trigger the build of silo's silex tool.
Comments:

@markcmiller86 I haven't run into this issue. Is this still a problem?


insertHTML fix: don't purge user-generated SPANs

A while back, this was written in insert-html.js: "FIXME: what if the user actually wants to use SPANs? This could cause conflicts."
Turns out that user was me. This updated patch is more targeted, removing only SPANs that are truly superfluous. In addition, it also covers more than one SPAN, where the original code would only cover the first child SPAN.
I've only tested this fix on my own code.

At first glance this looks good, second opinion @hmgibson23 ? I'd be happy to see if it passes our test suite and if so merge it.

Makes sense to me.

Tests work on chrome - can't run firefox locally because of the Webdriver bug. Can anyone else? @cutandpastey @robinedman @rrees

Just to clarify, this won't stop us from stripping SPANs in our HTML (eg when pasted in, etc)?

Hey @theefer , it should still remove SPANs, but double-check my logic to make sure it's going to match what you need.
Original version: Remove the first  child at any level
PR version: Remove all s where the only attribute is style and the only CSS selector in style is line-height.
I've only had line-height selectors in my test pastes, but that might not be universally true. The other simple option is to get rid of any  where the only attribute is style. The worry would be if styled text was pasted into the editor pane and it was pasted as a , e.g. . Since I only saw line-height, I kept the criteria for deletion narrow.

@christopherliu I think we'll need some more tests around what we think the behaviour should be, if you can expand the PR to include the behaviour you've observed and the new behaviour that would help us a lot in progressing the change

@rrees Sounds good. I'll write it out here. I could probably do something on the test side as well but I'd need a little direction since I haven't looked at that code.
Original version:
(Input -> Output)

123

->

123

1234

->

1234

1

->

1

New version:
(Input -> Output)

123

->

123

1234

->

1234

1

->

1

This is at least the idealized version of what I had in mind, which may perhaps make it all the better to test against.

#385


Cannot install pyansys

when i use pip install pyansys
it shows an error: command 'cl.exe' failed: No such file or directory
what happend?
Thank you

Sorry, you’re just missing cython.  I’ll have to add a check for this build dependency.
Curious, what is your OS and architecture?   Wheels are being built for Python 3.5-3.7 for all three major OSes (with 3.8 coming soon).

Thanks for your help.
my OS is win10 x64

Added Python 3.8 support, and ansys_corba will be updated for Python3.8 tomorrow.  You'll be able to read binary result files but not able to interactively control MAPDL just yet.  Look for an update for ansys_corba tomorrow.

Hello,
I'm pinging you on this closed issue because GitHub doesn't have an email address for you.
ANSYS is busy improving and extending pyansys.  As an existing user, we are interested in learning about your experience and opinions using this package.  Most notably:

What is your application?
How does pyansys facilitate your work?
What new pyansys features or improvements would you find valuable?
Your feedback will help us prioritize our investments and make pyansys even better.

On behalf of the pyansys development team, I look forward to hearing any feedback from you as it will be used to improve and advance pyansys.
Feel free to respond here to this issue, or email me at<EMAIL_ADDRESS>Alex Kaszynski


How can I profile the results of purine.

As the picture shows in paper, which tool was used to draw this figure?

The NVVP tool of NVIDIA. It's easy to use.

I get it , thx!


Markdown: Webview: Cannot load resource outside of protocol root

VSCode 1.35.0

File: New Untitled File
![avatar](/Users/xx/Documents/1.png)
Change Language Mode to Markdown
Markdown: Open Preview

Webview: Cannot load resource outside of protocol root

This is done by-design for security reasons. Markdown previews use webviews to render the preview, and webviews should not be able to read arbitrary files on your computer


Update dependencies to latest (command line args)

Update dependencies to latest (command line args)
Update cobra and pflag :

[ ] Update cobra and pflag to latest stable version
[ ] Add tests that verify the update did not break functionality

Ref:
Projects dependencies was last updates on Mar 2020:
https://github.com/yaacov/kubectl-sql/blob/master/go.mod

Hello, take a look at pull request please

Thank you for submitting the pull request :+1: I've left a few comments on the GitHub PR page for your reference.


more unit test and model tests

solve model errors
add more unit test (use fitted do determine whether pass)
add regression build test

Codecov Report

Merging #6 (05d4c15) into master (b3f45d5) will increase coverage by 0.06%.
The diff coverage is 13.88%.

@@            Coverage Diff             @@
##           master       #6      +/-   ##
==========================================
+ Coverage   12.82%   12.88%   +0.06%
==========================================
  Files          55       55
  Lines        5255     5370     +115
==========================================
+ Hits          674      692      +18
- Misses       4581     4678      +97

Flag
Coverage Δ

unittests
12.88% <13.88%> (+0.06%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

My_AutoML/_balancing/_mixed_sampling.py
16.66% <0.00%> (-0.99%)
:arrow_down:

My_AutoML/_balancing/_over_sampling.py
14.00% <0.00%> (-0.59%)
:arrow_down:

My_AutoML/_balancing/_under_sampling.py
10.44% <0.00%> (-0.49%)
:arrow_down:

My_AutoML/_encoding/_encoding.py
12.62% <0.00%> (-0.51%)
:arrow_down:

...hyperparameters/_ray/_classifier_hyperparameter.py
100.00% <ø> (ø)

..._hyperparameters/_ray/_regressor_hyperparameter.py
100.00% <ø> (ø)

My_AutoML/_imputation/__init__.py
80.00% <ø> (ø)

My_AutoML/_imputation/_base.py
16.85% <0.00%> (-1.22%)
:arrow_down:

My_AutoML/_imputation/_clustering.py
10.30% <0.00%> (ø)

My_AutoML/_imputation/_nn.py
11.07% <0.00%> (ø)

... and 6 more

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


WebDriverIO Helper _failed not called

Hello, i'm currently running some tests with the webdriverIO helper at crossbrowsertesting.com. I got the problem, that the _failed method within WebDricverIO.js isn't called. I played around a little bit inside the codeceptjs code and it looks like there is a problem with calling the _failed hooks in general. In listeners/helper.js line 36 the runAsyncHelpersHook doesn't call the hook within the helper. It tried to use runHelpersHook instead of runAsyncHelpersHook and it worked - but i don't know whether this is a good solution or not.
Besides this error i also noticed that there might be another problem within WebDriverIO.js, it looks like there should be test.title used instead of test.name for the filename creation (for my test run test.name isn't defined).
Beside these problem i also got some other problems:
saveScreenshot doesn't create any screenshots, but currently i assume that this is a problem with my configuration and/or using crossbrowsertesting.com via webdriverIO.
After a test failed, the remotely running test/instance via webdriverIO at crossbrowsertesting.com isn't stopped - i haven't found the reason yet and keep on looking for the solution, but maybe you have already heard of any similar problems.
thank you in advance & best regards

Thanks for detailed report. You really helped in posting and examining this issue. It was about managing the asynchronousity and it didn't do job well on failures. Now it does. Thanks


Dora Fine-tuning added to examples

In this PR a dir named "dora finetuning" is added to the examples dir. The content of it includes a notebook teaching how to use Dora technique along with an script of fine-tuning using Dora. Hope this helps the community!

Thanks for all the changes, this PR is almost ready to be merged. I found a few minor things that need yet to be changed, please check my comments.
After the changes to the notebook, did you re-run it? If not, could you please do that.
Yes, I just did and all is perfectly working! The newly-ran notebook is added!

Furthermore, could you please run make style? Otherwise, CI won't pass.
Just ran successfully! Here is the output;
(llm) [yamani.shirin@mg6 peft]$ make style ruff check --fix src tests examples docs scripts docker All checks passed! ruff format src tests examples docs scripts docker 165 files left unchanged doc-builder style src/peft tests docs/source --max_len 119

I got surprised since according to this torch.compile document on HF torch.compile() should perfectly work for the Lora + Dora adapter setup. So, would it mean that the changes (according to your provided example) should be applied to the tokenization?

Honestly, I'm not 100% sure what's going on but there is an issue with max token length when using torch.compile, which requires extra care with handling tokenization, as shown in the test that I linked. This issue is not directly PEFT related.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Thanks for the updates. Now we only need to make the code style checks pass and we should be good.
So something must have gone wrong with make style. Let's solve this step by step:

ensure that you're in the project root (not in the examples directory)
ensure that the correct Python virtual env is active
check that the ruff version is correct: ruff --version => 0.4.10
run make style
there should be changes now, which should be committed and pushed to the PR.

If make style doesn't work for some reason, you can also call the commands explicitly:
ruff check --fix examples
ruff format examples

Thanks for the updates. Now we only need to make the code style checks pass and we should be good.
So something must have gone wrong with make style. Let's solve this step by step:

ensure that you're in the project root (not in the examples directory)
ensure that the correct Python virtual env is active
check that the ruff version is correct: ruff --version => 0.4.10
run make style
there should be changes now, which should be committed and pushed to the PR.

If make style doesn't work for some reason, you can also call the commands explicitly:
ruff check --fix examples
ruff format examples

I am really grateful for your hint! I just pushed the changes after the ruff shell commands. I appreciate if you let me know it get passed!

For reference, this is the diff for the change:
modified   examples/dora_finetuning/dora_finetuning.py
@@ -6,7 +6,7 @@ from transformers import (
     AutoModelForCausalLM,
     AutoTokenizer,
     BitsAndBytesConfig,
-    DataCollatorWithPadding,
+    DataCollatorForLanguageModeling,
     Trainer,
     TrainingArguments,
 )
@@ -95,7 +95,7 @@ def train_model(
     tokenized_datasets = dataset.map(tokenize_function, batched=True, remove_columns=dataset["train"].column_names)

     # Data collator to dynamically pad the batched examples
-    data_collator = DataCollatorWithPadding(tokenizer)
+    data_collator = DataCollatorForLanguageModeling(tokenizer, mlm=False)

     # Define training arguments
     training_args = TrainingArguments(

I agree with you, just reviewed the code. Do I need to fork and update the changes ?  @BenjaminBossan

Thanks for checking. If you want to fix this, create a new PR based off the current main branch of PEFT. You don't need to create a new fork, as you already have a PEFT fork, you just need to refresh it so that it is up-to-date with PEFT main. There should be a button when you visit the link:

Did you have time to check this @shirinyamani? If you don't have time, let me know and I can work on a fix myself.

Just updated!  Now updated with the DataCollatorForLanguageModeling


spa license fixes

As discussed in #9, this PR:

Removes NRELS's spa.c, spa.h, and spatester.c files.
Updates setup.py so that it works with or without the spa files. I tested this, but see below.
Updates test_solarposition.py to skip the spa tests if the files are missing. @bmu probably won't like the copy/paste test code, but I think that it can be fixed in 0.2.

(Now resolved) Major issue: NREL made a few minor changes to the SPA code that will require modifying the cython code. From the most recent spa.c file:

// Revised 10-JUL-2014 Andreas
//         Change second in spa_data structure from an integer to double to allow fractional second
// Revised 08-SEP-2014 Andreas
//         Corrected description of azm_rotation in header file
//         Limited azimuth180 to range of 0 to 360 deg (instead of -180 to 180) for tech report consistency
//         Changed all variables names from azimuth180 to azimuth_astro
//         Renamed 2 "utility" function names for consistency

This PR currently works with the 01-APR-2013 version of the spa code. It should probably be updated to work with the latest version. I'm guessing that it would be a hassle to make it work with both versions.
This PR currently works with the 08-SEP-2014 version of the spa code. It does not work with the older code.

I think this is ready, but it should definitely be tested in full by somebody else.

I checked out your branch locally and tested it. Everything seems to be ok (the only difference to your install instructions was the use of python setup.py install --inplace instead of pip install . (see my comment above). All tests were ok.
However I'm not sure about a Windows install, which could be a problem in gereneral because of the compilation of the c code (but this is not a problem introduced by this pull request).

I did testing on @wholmgren's branch. I think the confusion is coming from running the install from the local pvlib-python folder vs site-packages. When doing a pip install, the spa_c_files directory isn't created in site-packages when installing, so it isn't possible to go back and do a python setup.py install --inplace and have it apply globally. That will only work on the pvlib-python folder (the one that isn't in the site-packages directory).
So, I think the only way to propagate this into the site-packages directory properly is using pip, and so I'd reccomend updating the README.md with this:

I updated the readme with @Calama-Consulting's suggestion and rebased on the numerous master changes.


Extension structs can't be chained

When a struct has a p_next member, there may be a set of structs that can be pointed to with it to access extended functionality. This is currently gracefully supported by builders. However, those structs can be chained: If Foo and Bar both extend Baz, then a Baz -> Foo -> Bar chain of p_next references is legal, even though Bar does not extend Foo. We should find a way to support this.
My first idea was to replace FooNext and BarNext with BazNext, but some extension structs (e.g. VkPhysicalDeviceVariablePointerFeatures) extend multiple structs, so there would be no correct single trait to replace their extension traits with. Another approach is to compute the union of legal extensions for every extended struct type, but this would cause a quadratic increase in generated code for every new extension struct.
Worst-case scenario, we can fall back on fn next<T>(self, &'a T) without any typechecking at all. Validation layers should do a decent job of checking these, after all.

I have an alternative idead for the next function which, however, may introduce a run-time penalty. The next function would be the same for every struct with p_next and It would simply iterate through p_next linked list to the end and append:
pub fn next<T>(mut self, append: &'a mut T) {
  current = self.inner.p_next;
  while(current.p_next != null) { current = current.p_next }
  current.p_next = append;
}

This has been fixed for a while now. We decided on fn next<T>(self, &'a T) without any type checking.

Oops you are right my bad, I did not notice the where bounds in docs.rs. I might find time to implement it next week, at the latest in two weeks.

I just had a quick look at it.
We can't just iterate over the chains and update them. pNext is usually *const. Unless I am mistaken if we want to update the last pointer, it has to be *mut.
Maybe it is okay to just cast if we always borrow as &mut T. It might be okay because we have an explicit lifetime on that borrow.

If fn next always takes &mut T then that should be correct, yeah. I think your idea of prepending instead of appending is a great one anyway, since it skips the loop. I don't think order usually matters, though it might for cases where T extends U and U extends V but T does not extend V, but prepending supports those cases fine, docs will just need to be clear.

I now have some time to address this issue. I had another look at it and I think we should tackle it differently.
As you said there can be multiple extends.
        <type category="struct" name="VkPhysicalDeviceVariablePointerFeatures" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
            <member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTER_FEATURES"><type>VkStructureType</type> <name>sType</name></member>
            <member><type>void</type>*                            <name>pNext</name></member>
            <member><type>VkBool32</type>                         <name>variablePointersStorageBuffer</name></member>
            <member><type>VkBool32</type>                         <name>variablePointers</name></member>
        </type>

structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo"
While it is true that it can extend multiple things, in this case VkPhysicalDeviceFeatures2 also extends VkDeviceCreateInfo.
I think we only should create and implement traits for create infos like VkDeviceCreateInfo and so next for VkPhysicalDeviceFeatures2 would look like fn next<T: ExtendDeviceCreateInfo>(..).
It is just a bit harder to implement as we would have to find the out most create info, but even that shouldn't be too complicated.

Are we certain that there are no, and never will be, cases where A extends B extends C, but A does not extend C?

A extends B extends C, but A does not extend C

If that would be the case then C can't be used at all right? If A is the "root" create info from a function and if A points to B and the points to C, then surely C must be valid also valid for A. If that is not the case C could never be used.
The point chain is linear at one point you have to append another pointer chain.
A -> B -> D
A -> C -> E

A -> B -> D -> C -> E
or
A -> C -> E -> B -> D

The vulkan spec is a bit vague with pnext.
I could only imagine
A extends B
A1 extends B extends C

And so C and only be used with A1 and not A, but I don't think we could encode this because we verify that for B and B can extend C it just can't be passed to a function that takes an A. Although I would be surprised if that would be in the API.

If that would be the case then C can't be used at all right? If A is the "root" create info from a function and if A points to B and the points to C, then surely C must be valid also valid for A. If that is not the case C could never be used.

You've got it backwards; in that example, C is the root.

You've got it backwards; in that example, C is the root.

Oops sorry, but the comment is still valid. You just have to swap A and C.

I don't follow, then. If A extends B, then by definition B's pNext field can legally point to A, regardless of what B extends. That dosn't mean that A makes sense on its own as an extension for everything that B extends.

I also had a look at how VulkanHpp does it
https://github.com/KhronosGroup/Vulkan-Hpp/blob/master/VulkanHppGenerator.cpp#L3946
  template <> struct isStructureChainValid<PhysicalDeviceFeatures2, PhysicalDeviceVariablePointerFeatures>{ enum { value = true }; };
  template <> struct isStructureChainValid<DeviceCreateInfo, PhysicalDeviceVariablePointerFeatures>{ enum { value = true }; };

And they validate it with
  template <typename List, typename X>
  struct extendCheck
  {
    static const bool valid = isStructureChainValid<typename List::last, X>::value || extendCheck<typename List::list,X>::valid;
  };

  template <typename T, typename X>
  struct extendCheck<TypeList<void,T>,X>
  {
    static const bool valid = isStructureChainValid<T, X>::value;
  };

  template <typename X>
  struct extendCheck<void,X>
  {
    static const bool valid = true;
  };

Are we certain that there are no, and never will be, cases where A extends B extends C, but A does not extend C?

Going back to you first comment
C -> B -> A would be valid, but C -> A -> B would not be. This is what you meant right?
The latter also doesn't compile with vulkan.hpp.
I just don't understand one aspect of it.
If
C extends B extends A
D extends A

Why would this then be valid? A -> B -> C -> D
I assume the rules are from right to left, (or down to up) I sort of expected that the order doesn't matter.
So A -> B -> C -> D would be valid because A can be reached from D.
Afaik the spec doesn't really say anything about this at all.

I also had a look at how VulkanHpp does it

What is the contents of the type list in this example?

C -> B -> A would be valid, but C -> A -> B would not be. This is what you meant right?

I was hypothesizing a case where C -> B -> A is valid, but C -> A is not.

Why would this then be valid? A -> B -> C -> D

The rule that seems most obvious/natural to me is "extension structs must be preceded in a pNext chain by a struct that they extend". @MatusT's approach implements these semantics.

The rule that seems most obvious/natural to me is "extension structs must be preceded in a pNext chain by a struct that they extend". @MatusT's approach implements these semantics.

I think I will just finish up #183 as it currently is. I'll also open an issue on the Vulkan docs, would be nice if this would be defined by the spec.

https://github.com/KhronosGroup/Vulkan-Docs/issues/929
The order doesn't matter, and A extends B extends C, but A does not extend C can not happen. There might be something if B is used then C can't be used, but we can not easily express it like this. We could do something similar like vulkanhpp Chain<(Foo, Bar, Baz)> but I am not a big fan on this.
I think my previous proposal is the best implementation, we don't have to iterate the chain and it is the most vulkan like implementation.
Invalid cases (which should be rare) can be caught by the validation layers.

Nice research!
I think we should proceed with @MatusT's approach, modified to prepend rather than append so iteration is unneeded. If order explicitly doesn't matter this is fine, it avoids having to do any aggregation, and it gracefully handles the case where one struct can be used to extend two different root structs that do not share all their extensions. We can then disable generating ExtendsFoo traits for extension structs entirely.


Feat/logging

A nice logging factory thanks to none-ls
work in progress, not working currently

I'm not sure I understand what this is supposed to do but the strategy I'm opting for is to use vim.notify and then let the users them self choose a message handler! Unless this is super awesome so looking forward to seeing a screenshot :D.
On another note, I don't want to add plenary as a dependency, I don't really like it, lots of issues and not super well maintained.
Lots of the things it offered are now easy to do just using neovim +10, such as jobs and async stuff. I predict people will move away from it.


Add NUL character at the end of copied error message

C++ error message returned by what must be NUL-terminated. However, the current copy function only copied the characters, but didn't add the NUL. Allocate one more byte and set it to NUL.

BTW, here is the issue fixed by this (from Valgrind):
==21911== Thread 2 test_c_call_r:
==21911== Invalid read of size 1
==21911==    at 0x4E0C934: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21911==    by 0x18FE27: cxx_run_test (tests.cc:812)
==21911==    by 0x13781C: test::test_c_call_r::cxx_run_test (test.rs:240)
==21911==    by 0x1377E1: test::test_c_call_r (test.rs:246)
==21911==    by 0x13CD56: test::test_c_call_r::{{closure}} (test.rs:235)
==21911==    by 0x127364: core::ops::function::FnOnce::call_once (function.rs:507)
==21911==    by 0x171B9E: test::__rust_begin_short_backtrace (function.rs:507)
==21911==    by 0x14326B: core::ops::function::FnOnce::call_once{{vtable.shim}} (lib.rs:648)
==21911==    by 0x170B29: test::run_test::run_test_inner::{{closure}} (boxed.rs:2000)
==21911==    by 0x13DB60: std::sys_common::backtrace::__rust_begin_short_backtrace (lib.rs:601)
==21911==    by 0x14349A: core::ops::function::FnOnce::call_once{{vtable.shim}} (mod.rs:550)
==21911==    by 0x1D0AD2: std::sys::unix::thread::Thread::new::thread_start (boxed.rs:2000)
==21911==  Address 0x527240a is 0 bytes after a block of size 10 alloc'd
==21911==    at 0x4E0713F: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21911==    by 0x1A38A0: rust::cxxbridge1::errorCopy(char const*, unsigned long) (cxx.cc:452)
==21911==    by 0x1A399B: rust::cxxbridge1::Error::Error(rust::cxxbridge1::Error const&) (cxx.cc:472)
==21911==    by 0x1A4216: std::__exception_ptr::exception_ptr std::make_exception_ptr<rust::cxxbridge1::Error>(rust::cxxbridge1::Error) (exception_ptr.h:250)
==21911==    by 0x1A3AAA: cxxbridge1$default_exception (cxx.cc:555)
==21911==    by 0x19FDDD: cxx::result::CxxException::new_default (result.rs:66)
==21911==    by 0x18308F: <&T as cxx::result::ToCxxExceptionDefault>::to_cxx_exception (result.rs:214)
==21911==    by 0x1769A6: cxx_test_suite::ffi::_::__r_fail_return_primitive::__r_fail_return_primitive::{{closure}} (lib.rs:304)
==21911==    by 0x183E4A: core::result::Result<T,E>::map_err (result.rs:861)
==21911==    by 0x17B000: cxx_test_suite::ffi::_::__r_fail_return_primitive::__r_fail_return_primitive (lib.rs:304)
==21911==    by 0x1769D7: cxx_test_suite::ffi::_::__r_fail_return_primitive::{{closure}} (lib.rs:23)
==21911==    by 0x180CA8: cxx::unwind::prevent_unwind (unwind.rs:23)

@dtolnay Maybe Valgrind tests should be added in the CI? No idea how hard that is.

@dtolnay

I think this is correct as currently implemented.

Hm, well, OK, let's assume you get the message "test" from Rust. That is, pointer to 4 characters "test" + len = 4. You allocate 4 bytes and copy the 4 characters "test" into those 4 bytes.
Now, the exception is thrown and caught in the C++ code (via catch(rust::Error &e). The C++ code calls e.what() and receives the pointer to the 4 characters "test" (but no len - how? It's a const char*!). Now it wants to print it to an ostream for diagnosis purposes. OK, the operator<<(const char*) now starts iterating characters starting at the pointer and it receives 't', 'e', 's', 't', ... and then? Missing NUL terminator! So it happily starts printing the garbage afterwards, potentially running into an unmapped page and crashing the process.
Care to reconsider? 🙂

For "test", the len passed into this function is 5, not 4, so the memcpy already includes the original \0 byte.

@dtolnay
Sorry for making a fool of myself. You are right, the NUL byte is pushed in to_c_error() (well, it is inefficient as hell, but hey, we are on the error path; and yes, it is correct).
The valgrind output was from the change required for handling C++ exceptions via std::exception_ptr, which I pushed in PR https://github.com/dtolnay/cxx/pull/1180 (and which is in turn prerequisite for a few other things - like transparent exception passing through Rust). There, the default error is constructed from a Rust &str, which in turn is constructed by using formatting functions to format the error into a buffer, which then for most use cases saves all but 2 allocations which are strictly necessary to construct the exception (only the allocation of the string and the exception proper remains).
The original code allocated at least once extra for the to_string() (and depending on the error's Display trait implementation, likely one or two times more).
Anyway, the changes in the other PR are self-contained and valgrind-verified, so this change is indeed not needed.


is rempl based redux devtools public available?

No yet. It would be cool if somebody try to port redux devtools to rempl.

thank you


Error messages are difficult to parse when class incorrectly implements an interface

If a class incorrectly implements an interface which it explicitly claims to implement, the compiler produces "Argument of type '' is not assignable to parameter of type ''" at all the locations where an instance of the class is assigned to a variable or function parameter of the interface type.
This results in a lot of redundant error messages which obscure the root issue - the error message explaining why the class doesn't implement the interface.
I would suggest that if a class explicitly claims to implement an interface, that call-sites shouldn't issue errors about type incompatibilities.
eg. With this code:
interface WebServiceClient {
	getData(): string;
}

class WebServiceImpl implements WebServiceClient {
	getData(): number { // incorrect implementation
		return 0;
	}
}

function doSomethingWithWebService(client: WebServiceClient): void {
}

var webService = new WebServiceImpl();
doSomethingWithWebService(webService);

Don't produce the "Argument of type 'WebServiceImpl' is not assignable to parameter of type 'WebServiceClient'" error at the doSomethingWithWebService() call, only the error for the WebServiceImpl implementation.

This would reduce some noise. I'm not sure the cost of doing it is worth what's gained. Are there other languages that do this sort of thing?

There's just not a clean way to implement this in the compiler today (relative the gain in error quality)


huge ram issue when changing models

most of the time when you want to change a model, the max RAM memory is reached. even if loading a 2gb model. Why is there so much loaded in ra?
This is a huge issue

It's a known bug that the google colab team hasn't been able to fix yet https://github.com/googlecolab/colabtools/issues/3363

Man, hope they fix it soon.

same here, 100% crash on model load :(

uff they closed the colab issue 😭

try with the latest colab, hopefully this commit will fix it https://github.com/TheLastBen/fast-stable-diffusion/commit/67145d8e54c9128f3981ddc763282f6485ab47e9

It works now, no more RAM problem when changing models. but
To load, it takes 60sec for a 2GB model and 256 sec for a 7GB model.

the long loading is caused in colab by extensions, if you have many of them installed they cause a delay

I don't know because I just tested it without login my google drive so it was a fresh new install on the google colab kernel without extension installed.

I have no extensions and loading is super slow now. Anything I can do?

for a 2GB model ?

Yes, 187 seconds

Still got RAM issues/crashed too, basically after every merge it will ^C after trying to load the new model :(

Actually, it came back to normal loading time for me (using google drive).

Soon there will be alternative notebooks for different cloud providers.

Kaggle? :)

I've only just come up with this (Honestly repulsive) workaround, which involves rolling back a few specific dependancies. It's not pretty, at all, but if you add the following cell to the notebook, and run it at least once (Preferably first), the memory usage seems to go back to how it used to be.
!wget http://launchpadlibrarian.net/367274644/libgoogle-perftools-dev_2.5-2.2ubuntu3_amd64.deb
!wget https://launchpad.net/ubuntu/+source/google-perftools/2.5-2.2ubuntu3/+build/14795286/+files/google-perftools_2.5-2.2ubuntu3_all.deb
!wget https://launchpad.net/ubuntu/+source/google-perftools/2.5-2.2ubuntu3/+build/14795286/+files/libtcmalloc-minimal4_2.5-2.2ubuntu3_amd64.deb
!wget https://launchpad.net/ubuntu/+source/google-perftools/2.5-2.2ubuntu3/+build/14795286/+files/libgoogle-perftools4_2.5-2.2ubuntu3_amd64.deb
!apt install -qq libunwind8-dev
!dpkg -i *.deb
%env LD_PRELOAD=libtcmalloc.so

I'll try that thanks


Annotations in embeds are showing Times font over Google Maps

In the embed_map annotations are being shown with Times font:

In public_map, they're appearing as set in the viz.json

While testing with cartodb.uncompressed.js, the fontFamily variable (line of code here) is storing undefined, although other properties as the boxColor are set up correctly:

cc @javisantana @javierarce

This should be fixed now!


Upgrade setup-azd in azure-dev.yaml

Purpose
This will remove security warning re Node version.
Does this introduce a breaking change?
When developers merge from main and run the server, azd up, or azd deploy, will this produce an error?
If you're not sure, try it out on an old environment.
[ ] Yes
[X] No

Does this require changes to learn.microsoft.com docs?
This repository is referenced by this tutorial
which includes deployment, settings and usage instructions. If text or screenshot need to change in the tutorial,
check the box below and notify the tutorial author. A Microsoft employee can do this for you if you're an external contributor.
[ ] Yes
[X] No

Type of change
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[X] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

Code quality checklist
N/A

Need approval from maintainer, can you stamp @tonybaloney ?

Oh wait, I'll just merge the dependabot PR. Carry on!


icingaweb2: 2.11.1 -> 2.11.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/Icinga/icingaweb2/releases.
meta.description for icingaweb2 is: "Webinterface for Icinga 2"
meta.homepage for icingaweb2 is: "https://www.icinga.com/products/icinga-web-2/"
meta.changelog for icingaweb2 is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.11.1 with grep in /nix/store/ppr6xp3pmzgwdnsss5g058izqc75jvhw-icingaweb2-2.11.1
found 2.11.1 in filename of file in /nix/store/ppr6xp3pmzgwdnsss5g058izqc75jvhw-icingaweb2-2.11.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
icingaweb2

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ppr6xp3pmzgwdnsss5g058izqc75jvhw-icingaweb2-2.11.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A icingaweb2 https://github.com/r-ryantm/nixpkgs/archive/635a0f2a31a9e33b1f0ab16aa340baa6c3937ffc.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ppr6xp3pmzgwdnsss5g058izqc75jvhw-icingaweb2-2.11.1
ls -la /nix/store/ppr6xp3pmzgwdnsss5g058izqc75jvhw-icingaweb2-2.11.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

icingaweb2

Maintainer pings
cc @dasJ for testing.

@dasJ At least the binary included in this web package is broken
[nix-shell:~/.cache/nixpkgs-review/pr-183358]$ ./results/icingaweb2/bin/icingacli

Fatal error: Uncaught Error: Class "ipl\I18n\GettextTranslator" not found in /nix/store/862v81lbyjh0b5v4sczjvzyxph746zdw-icingaweb2-2.11.1/library/Icinga/Application/ApplicationBootstrap.php:699
Stack trace:
#0 /nix/store/862v81lbyjh0b5v4sczjvzyxph746zdw-icingaweb2-2.11.1/library/Icinga/Application/Cli.php(44): Icinga\Application\ApplicationBootstrap->prepareInternationalization()
#1 /nix/store/862v81lbyjh0b5v4sczjvzyxph746zdw-icingaweb2-2.11.1/library/Icinga/Application/ApplicationBootstrap.php(416): Icinga\Application\Cli->bootstrap()
#2 /nix/store/862v81lbyjh0b5v4sczjvzyxph746zdw-icingaweb2-2.11.1/bin/.icingacli-wrapped(7): Icinga\Application\ApplicationBootstrap::start()
#3 {main}
  thrown in /nix/store/862v81lbyjh0b5v4sczjvzyxph746zdw-icingaweb2-2.11.1/library/Icinga/Application/ApplicationBootstrap.php on line 699

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/Icinga/icingaweb2/releases.
meta.description for icingaweb2 is: "Webinterface for Icinga 2"
meta.homepage for icingaweb2 is: "https://www.icinga.com/products/icinga-web-2/"
meta.changelog for icingaweb2 is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.11.2 with grep in /nix/store/6s276s3y4sair6059x9c817msmjj0p25-icingaweb2-2.11.2
found 2.11.2 in filename of file in /nix/store/6s276s3y4sair6059x9c817msmjj0p25-icingaweb2-2.11.2

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
icingaweb2

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/6s276s3y4sair6059x9c817msmjj0p25-icingaweb2-2.11.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A icingaweb2 https://github.com/r-ryantm/nixpkgs/archive/326197104136e50c467227cd18ccb8a1031a8c4e.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/6s276s3y4sair6059x9c817msmjj0p25-icingaweb2-2.11.2
ls -la /nix/store/6s276s3y4sair6059x9c817msmjj0p25-icingaweb2-2.11.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

icingaweb2

Maintainer pings
cc @dasJ for testing.