profile
viewpoint

Hello71/Dwarf-Therapist 15

ARCHIVED, NOW MAINTAINED AT https://github.com/Dwarf-Therapist/Dwarf-Therapist

Hello71/html5ks 3

A WIP HTML5 implementation of the visual novel Katawa Shoujo.

Hello71/asher 0

The asher website repo

Hello71/astroid 0

A graphical threads-with-tags style, lightweight and fast, e-mail client for Notmuch

Hello71/book 0

The Rust Programming Language

Hello71/bpftools 0

BPF Tools - packet analyst toolkit

Hello71/canimod.github.io 0

A collaborative GitHub pages website about modding Stardew Valley.

Hello71/caniuse 0

Raw browser/feature support data from caniuse.com

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 7e5a467f4823a16600a4a3dffc3c30b20bfd95f7

profiles: unmask {jre,jdk}-15

view details

push time in 2 hours

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha a14240e133a60c2a0b2dadcd5a6d7b27c0580f3c

dev-java/*openjdk*, virtual/{jdk,jre}: bump, rm old

view details

Alex Xu (Hello71)

commit sha a8b250c518f5efc89e4c2c85b289201ee1bea9e8

dev-java/openj9-openjdk: fixes

view details

push time in 2 hours

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 29ccc369a32396777aedf8600ae74c5543f2bec8

dev-qt/qtgui: sync

view details

push time in 7 days

pull request commenteclipse/omr

Use flexible array members, disable MSVC W4200

@keithc-ca can you take another look at this? I'm still confused about what's going on with MSVC here.

Hello71

comment created time in 8 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 4067bf0d7cf41767213fe99480fab64ec02c434b

dev-java/openj9-openjdk: 15.0.22.0

view details

push time in 10 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 306371270cfb97f28c31341109257ed680fd2df3

Revert "x11-apps/mesa-progs: drop, fixed upstream" This reverts commit ca1db4f63cea11f7894c726168175cdffe4638a6.

view details

Alex Xu (Hello71)

commit sha 0aaeeffcabad9f10fb6112b5486a7f0671107e16

x11-apps/mesa-progs: drop 9999, fixed upstream

view details

push time in 10 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha bdecc748349e5e7f3f381cc7eebb395c3199a1b5

dev-qt/qtgui: sync

view details

Alex Xu (Hello71)

commit sha 2781d516d8a8b8158bba75e19d73bc07535ca730

virtual/rust: sync

view details

Alex Xu (Hello71)

commit sha ca1db4f63cea11f7894c726168175cdffe4638a6

x11-apps/mesa-progs: drop, fixed upstream

view details

push time in 10 days

push eventHello71/sway

Alex Xu

commit sha 6d01001e7df6b139b195b37b3559fc7b0630e5ef

idle_inhibit: remove stray semicolon This doesn't (shouldn't) do anything, but it's unnecessarily confusing.

view details

push time in 13 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha f7daf68b959d20355fcd6d31714d92f372cbb79f

dev-qt/qtgui: sync

view details

push time in 13 days

issue commentInBetweenNames/gentooLTO

enable LTO for chromium

Always dies here for me when I try what @dallenwilson suggested (using gcc):

FAILED: pyproto/components/leveldb_proto/internal/proto/shared_db_metadata_pb2.py gen/components/leveldb_proto/internal/proto/shared_db_metadata.pb.h gen/components/leveldb_proto/internal/proto/shared_db_metadata.pb.cc
python ../../tools/protoc_wrapper/protoc_wrapper.py shared_db_metadata.proto --protoc ./protoc --proto-in-dir ../../compon          ents/leveldb_proto/internal/proto --cc-out-dir gen/components/leveldb_proto/internal/proto --py-out-dir pyproto/components          /leveldb_proto/internal/proto
terminate called after throwing an instance of 'std::system_error'

What's also weird is that it doesn't compile with clang anymore for me either, so something's changed in chromium-86.0.

you cropped out the important line of this error, but you might fix it by disabling --as-needed.

Hello71

comment created time in 14 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha f2ed86ca8abd9ce126a7d762cc492385ea92d502

dev-qt/qtgui: sync

view details

push time in 14 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 2b7a4a9646807ed507e7a7b9e1328ff5ca961d30

virtual/rust: sync

view details

Alex Xu (Hello71)

commit sha 58ca59c19f4424265998a86186d8dc1e26299b40

net-misc/gallery-dl: bump

view details

push time in 14 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 60cf76adf14169d8c3ddb3a541767231c70f8d06

virtual/rust: sync

view details

push time in 17 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 396540dc66507b131572c97ec7b171b943c747f4

app-emulation/dxvk-bin: bump

view details

push time in 18 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 4bc59a6c2de3a56c724992e463a25e6cbac4a825

virtual/rust: sync

view details

push time in 19 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 0627c5a3985108f468e25180abb6727ae0185cab

dev-util/android-udev-rules: bump

view details

Alex Xu (Hello71)

commit sha 120daad40c18c9e4a944fb4f8c0d6b30ff96b963

dev-python/fonttools: bump

view details

push time in 20 days

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 861ac5f1513fd47ded7d087b4526f7807a62e206

dev-qt/qtgui: sync

view details

push time in 25 days

issue commentSir-Kyle-Richardson/OSRS-Flipper

TradePersister: hardcoded path separator

or better, directory should be a Path, not an old-fashioned File, then use directory.resolve(filename) like it says in the documentation.

Hello71

comment created time in a month

issue commentSir-Kyle-Richardson/OSRS-Flipper

TradePersister: hardcoded path separator

forward slashes work on all (modern) platforms. there's File.separator, but that's mainly for printing or interfacing with poorly written programs. but really this should be Paths.get(directory, filename). https://docs.oracle.com/javase/7/docs/api/java/nio/file/Paths.html#get(java.lang.String,%20java.lang.String...)

Hello71

comment created time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 8ba71d5d66802c5d08c298ab302a4bdeb2e6f701

media-sound/qjackctl: sync

view details

Alex Xu (Hello71)

commit sha 3b7cada547e0b701f7491a8d644701e26ce3dd45

dev-python/fonttools: bump

view details

Alex Xu (Hello71)

commit sha c0aeebec40c384aeb2040f2e03d8632e4989bd3c

dev-libs/openssl: bump

view details

push time in a month

pull request commentmesonbuild/meson

WIP: Add native pkg-config implementation

  • It's faster. For me gst-build configuration goes from 20s to 17s, that's because we don't have to fork+exec and re-parse all pc files for each pkg-config invocation. I profiled that we used to spend 2.96s in total inside PkgConfigDependency._call_pkgbin and we now spend 0.053s in our custom parser.

it's not clear, did you test this with pkgconf or real pkgconfig? my understanding is that pkgconf is (usually) much faster.

  • Will allow fixing cases of mixing system/subproject deps. For example if we built glib subproject and do dependency('gstreamer-1.0') we could detect that gstreamer's pc file requires glib and either abort or replace it by the subproject dependency.

  • Will allow mixing multiple sysroots. pkg-config only allow setting a common PKG_CONFIG_SYSROOT_DIR path that will be prepended to all cflag/libs paths, but pc files coming from different locations needs a different SYSROOT_DIR. That's something easier to fix at meson level.

these parts seems to conflict with further discussion. then wouldn't this only work with meson version, so projects using them would be incompatible with system pkg-config?

xclaesse

comment created time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 3b5950892d6999a1b91443fe93865e627186ed5c

net-misc/gallery-dl: bump to 1.15.0

view details

push time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 90f7934cf66d5608d9b6fb1711324bebcbcf9e84

dev-java/*openjdk-bin: sync drop doc useflag

view details

Alex Xu (Hello71)

commit sha fdf57bac99a4a38c43655f070f4350c83b1d8ed1

dev-java/java-sdk-docs: sync

view details

push time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha ce89bb609a46ff9dc513919168bba7c9879d2af3

dev-python/fonttools: unsupport 3.9 until dev-python/fs

view details

push time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 5bbc6ac16bb764d2b984b0e7cc3be169af91efdc

x11-base/xorg-server: sync

view details

Alex Xu (Hello71)

commit sha 2886eeeb1b5cf96f075f79865a10698102cefb4e

dev-java/*openjdk*: metadata.xml: drop webstart

view details

push time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 27230aca68b0f6605a784cb3f98515f6702ab388

virtual/jre: sync

view details

Alex Xu (Hello71)

commit sha f4e348e30fddb21d08e39569b6ea249ad845e61a

virtual/jdk: sync

view details

push time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha b20fa2ec23fb51524cc3e04be3a5523a391a553a

media-sound/qjackctl: sync

view details

Alex Xu (Hello71)

commit sha 94b2307131d9ca37c1c7bfe5d19a16586cb8b95c

app-crypt/libsecret: bump

view details

push time in a month

issue openedsyncthing/syncthing

RFC: tiny databaseTuning

I have a very small database (~600 files+directories, ~2M ldb). The small databaseTuning preset is still somewhat large for me: syncthing uses over 40 MB RAM, and according to pprof, 16 MB is occupied by the write buffer. While I am quite unfamiliar with LevelDB, a 16 MB write buffer for a 2 MB database seems excessive. I set STDEBUG_WriteBuffer=262144, which did in fact lower memory usage by a significant amount: along with disabling the GUI and setting GOGC=20, the RAM usage was reduced to under 30 MB. While this doesn't sound like a huge amount, it is fairly significant on a small VPS sharing with other services.

I think it could be valuable to provide an explicit databaseTuning setting for this. However, it might be an issue to include it in "auto", since the parameters are only set once at start. So, if someone starts with an empty database and then adds a lot of files (probably fairly common for new users), database performance would be slow until restart. I'm not sure how useful it would be to have this setting but require users to set it manually though... maybe syncthing could keep track of the database size and suggest alternative settings if the database stays below a certain size?

created time in a month

PR closed openjdk/jdk

use gappinfo instead of gvfs for detecting actions awt oca

gtk_show_uri uses gappinfo, not gvfs. see https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2359

this fixes Desktop.browse for systems without gvfs installed. this doesn't accurately reflect systems which use libgnome gnome_url_show, but gtk_show_uri should be used on all modern GNOME systems anyways. <!-- Anything below this marker will be automatically updated, please do not edit manually! -->

Progress

  • [x] Change must not contain extraneous whitespace
  • [ ] Commit message must refer to an issue
  • [ ] Change must be properly reviewed

Error

 ⚠️ OCA signatory status must be verified

Download

$ git fetch https://git.openjdk.java.net/jdk pull/84/head:pull/84 $ git checkout pull/84

+16 -63

3 comments

4 changed files

Hello71

pr closed time in a month

pull request commentopenjdk/jdk

use gappinfo instead of gvfs for detecting actions

printing sucks.

Hello71

comment created time in a month

PR opened astroidmail/astroid

use std::placeholders everywhere

before this was silently relying on boost placeholders, but those default off now.

+19 -19

0 comment

4 changed files

pr created time in a month

create barnchHello71/astroid

branch : patch-2

created branch time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha e0a7a31c119b7fcde19cafbeacb3507288cd5fe6

dev-texlive/texlive-latexextra: drop

view details

push time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 795fa5158c331bf5a7da85eaa7034507674fb517

app-text/texlive-core: drop too much work to maintain since I don't use it anymore

view details

push time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 44804392a39e85c45e7c32e0c6538def036ea6f1

dev-python/fonttools: bump

view details

Alex Xu (Hello71)

commit sha 89a2be912919b05e234cb16569b47bfb12bd8e20

gui-apps/gammastep: bump

view details

push time in a month

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha ad6cc1d49ee00be20d14700972e0467695411f89

dev-qt/qtgui: sync

view details

push time in a month

PR opened openjdk/jdk

use gappinfo instead of gvfs for detecting actions

gtk_show_uri uses gappinfo, not gvfs. see https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2359

this fixes Desktop.browse for systems without gvfs installed. this doesn't accurately reflect systems which use libgnome gnome_url_show, but gtk_show_uri should be used on all modern GNOME systems anyways.

+16 -63

0 comment

4 changed files

pr created time in 2 months

create barnchHello71/jdk

branch : gappinfo

created branch time in 2 months

fork Hello71/jdk

JDK main-line development

https://openjdk.java.net/projects/jdk/

fork in 2 months

issue closedswaywm/sway

Java AWT does not focus on hover

  • Sway Version:

    • sway version v1.5, wlroots 0.11.0
  • Debug Log:

    • available upon request
  • Configuration File:

    • default
  • Stack Trace:

    • N/A
  • Description:

    • Run two copies of the below Java program. Focus one text box in one and one text box in the other. Move your cursor between the two windows, or use Mod4+h/l, then enter text.
    • Expected behavior: Upon mouse over of the inactive window, the text box most recently focused is re-focused and receives keyboard input.
    • Actual behavior: The text box is not focused and keyboard input is not registered until a click is performed anywhere in the window.

I assume this is caused by Java AWT trying to do its own focus management. With xwininfo, I can see that Java registers multiple X windows, including a "focus helper" in addition to the actual content windows. Using xev -id, I see that sway initially sends events to the content windows, but after a click, all input goes to the focus helper.

closed time in 2 months

Hello71

issue commentswaywm/sway

Java AWT does not focus on hover

I'm not sure that compositor stderr output is sufficiently visible.

The debug log will contain this so it should be visible enough for people that read the issue template (and thus their log) before posting.

Assuming that users actually read the log, put in the effort to file a complete bug report, and decide to read the entire log (of which this warning message would presumably be in the middle of, not at the start or end).

given that I clearly put in more than a token attempt at a bug report, I would appreciate more than a token response

You're mistaken. Even if you put some effort into a bug report it doesn't mean volunteers have a duty to put some effort into helpful replies.

Maybe, maybe not. I believe we have different opinions on that front, but I don't care to argue that here, beyond commenting that your general culture of hostility contributes to my next point.

The only way you can reliably expect your bug to be fixed is by sending a patch yourself to the appropriate project.

That's where you're wrong. I've sent in more than my share of ignored patches, on GitHub and elsewhere. Your premise is flawed, and your assumption of universality (all projects operate this way, therefore I am justified in assuming that everybody knows this already) and conclusion (hostility to those who do not start with a patch) I am certain drives away potential contributors. Regardless, I got what I needed, and you haven't bothered to respond to any of the substantive issues raised, so I guess we're done here.

Hello71

comment created time in 2 months

issue commentswaywm/sway

Java AWT does not focus on hover

neither of these comments are helpful, and it seems to me that no serious diagnosis was attempted

Please stay civil. People commenting on the bug tracker aren't paid to help you.

I'm just saying that a non-serious attempt at helping isn't really any better than no help at all, and that given that I clearly put in more than a token attempt at a bug report, I expect more than a token response. I appreciate the more serious attempts at help afterwards.

Maybe we should just hard-require xcb-icccm in wlroots.

As a Gentoo user, I do like things to be configurable, but I don't like them resulting in silent non-obvious missing functionality. I think it would be better to show some message in this case, but I'm not sure that compositor stderr output is sufficiently visible. Another option might be to simply enable it by default, and write in the option help that it is strongly recommended for full X operation.

Hello71

comment created time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha fc5e4e943c76eaf023cf204420b5b4d0a755a8d9

openjdk: sync

view details

Alex Xu (Hello71)

commit sha 23caf66e2d88c3107bd15f022e95bccf71a57866

openjdk-bin: sync

view details

Alex Xu (Hello71)

commit sha 60e29eafb5adfd61e53259ef09288d4d3564ce2c

openjdk-jre-bin: sync

view details

Alex Xu (Hello71)

commit sha eb603c477a007a5d8129b7b710dd623b4074ee59

openj9-openjdk: sync

view details

Alex Xu (Hello71)

commit sha efb228fac0fd2a2798162431dba8254992d0d502

openj9-openjdk-bin: sync

view details

Alex Xu (Hello71)

commit sha 0c9f1a5c6011b430f687660ddd3d038151ca43f8

openj9-openjdk-jre-bin: sync

view details

push time in 2 months

startedHello71/omr

started time in 2 months

issue commentswaywm/sway

Java AWT does not focus on hover

Upon closer investigation of the sway debug log, I noticed this message:

[DEBUG] [xwayland/xwm.c:1307] unhandled X11 event: 10

I recompiled wlroots with ICCCM support (off by default on Gentoo), and it resolved the filed issue, despite still showing that message. It also shows new messages about WM_HINTS, which I think is important. I guess this issue is partially user error, but I think it should be clearer that ICCCM support is important for certain clients and missing support may cause silent lack of features.

Hello71

comment created time in 2 months

issue commentswaywm/sway

Java AWT does not focus on hover

Java AWT is deprecated.

kinda, sorta, not exactly, but that's a worthless response either way. you may as well go around to every xwayland issue and comment "X is deprecated". it's a waste of everybody's time.

Have you tried running with _JAVA_AWT_WM_NONREPARENTING=1?

that applies mainly to output, not input.

neither of these comments are helpful, and it seems to me that no serious diagnosis was attempted, since otherwise the first comment should have been "where is the program". for what it's worth, here is the program, despite my skepticism that further comments will actually take it into consideration before dispensing generic criticism based solely on the issue title.

import java.awt.*;

class TextFieldExample {
    public static void main(String args[]) {
        Frame f = new Frame();
        TextField t1 = new TextField();
        t1.setBounds(50, 100, 200, 30);
        TextField t2 = new TextField();
        t2.setBounds(50, 150, 200, 30);
        f.add(t1);
        f.add(t2);
        f.setSize(300,300);
        f.setLayout(null);
        f.setVisible(true);
    }
}
Hello71

comment created time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha ebf75ea74c972091d1b2681957f2df6b8ba59d4b

net-libs/neatvnc: remove benchmarks they aren't installed

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 384fc45a551b660f5c376598c8136a5bf9a6b757

net-misc/wayvnc: fixes

view details

Alex Xu (Hello71)

commit sha 9a0e7ab1a5150f1d8ef74ad2b94330951aaf9d11

virtual/jdk: ~arm

view details

Alex Xu (Hello71)

commit sha d7054afeac7469baa6194a8eed03a3880acbb015

gui-apps/gammastep: add metadata.xml

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha da498b2728a65dfd6ec22282a34725bf4ee863d8

dev-libs/aml: 0.1.0 bump

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha ec7dd58ef8d513aaba2da05745049ef47559cc45

dev-libs/aml: 0.1.0 bump

view details

Alex Xu (Hello71)

commit sha 7190986bcd2c63cfa37781a8172b60fc129f3487

net-libs/neatvnc: 0.2.0 bump

view details

Alex Xu (Hello71)

commit sha 0d92a5b003e539c58ad526d6bffa37a16932aabf

net-misc/wayvnc: 0.2.0 bump

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 4da75e5d0e0af24c9c8495c2a8c3500a27b73d10

virtual/rust: sync

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 06cbb13462d848aab853a91d6a7838b02e980fec

dev-java/*openjdk: fixes

view details

push time in 2 months

issue openedswaywm/sway

Java AWT does not focus on hover

  • Sway Version:

    • sway version v1.5, wlroots 0.11.0
  • Debug Log:

    • available upon request
  • Configuration File:

    • default
  • Stack Trace:

    • N/A
  • Description:

    • Run two copies of the below Java program. Focus one text box in one and one text box in the other. Move your cursor between the two windows, or use Mod4+h/l, then enter text.
    • Expected behavior: Upon mouse over of the inactive window, the text box most recently focused is re-focused and receives keyboard input.
    • Actual behavior: The text box is not focused and keyboard input is not registered until a click is performed anywhere in the window.

I assume this is caused by Java AWT trying to do its own focus management. With xwininfo, I can see that Java registers multiple X windows, including a "focus helper" in addition to the actual content windows. Using xev -id, I see that sway initially sends events to the content windows, but after a click, all input goes to the focus helper.

created time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 4e5feb9f0844a76f33f9dc7b134dd14a8d9a107b

net-misc/gallery-dl: bump

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha b248f834d9767612c18a86ac2c2cc9e02f4c2130

x11-base/xorg-server: sync

view details

Alex Xu (Hello71)

commit sha fa97fe92af99eb44b95a2f5a0f41f4ca065441ad

virtual/rust: sync

view details

Alex Xu (Hello71)

commit sha 52c0a9a7377164b6488c3792e48859c848d248f6

virtual/rust: sync

view details

push time in 2 months

pull request commenteclipse/omr

Use flexible array members, disable MSVC W4200

I expect the test code isn't properly using the compile options; see fvtest/util/CMakeLists.txt.

yeah, that's the obvious conclusion, but I can see that /wd4200 is specified. for example, assuming I am reading the log correctly, 9>printerrorhelper.cpp is:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64\CL.exe /c /I"C:\jenkins\workspace\PullRequest-win_x86-64\Build\fvtest\util\." /I"C:\jenkins\workspace\PullRequest-win_x86-64\Build\include_core" /I"C:\jenkins\workspace\PullRequest-win_x86-64\Build\build" /Zi /nologo /W3 /WX /Od /Ob0 /D WIN32 /D _WINDOWS /D OMR_OS_WINDOWS /D _CRT_SECURE_NO_WARNINGS /D CRTAPI1=_cdecl /D CRTAPI2=_cdecl /D _MT /D _WINSOCKAPI_ /D _DLL /D _HAS_EXCEPTIONS=0 /D _VARIADIC_MAX=10 /D _WIN32_WINNT=0x0601 /D WINVER=0x0601 /D J9HAMMER /D _AMD64_ /D NOMINMAX /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /GR- /Fo"omrtestutil.dir\Debug\\" /Fd"omrtestutil.dir\Debug\vc110.pdb" /Gd /TP /wd4577 /wd4091 /wd4200 /errorReport:queue  /Zm400 "C:\jenkins\workspace\PullRequest-win_x86-64\Build\fvtest\util\printerrorhelper.cpp" "C:\jenkins\workspace\PullRequest-win_x86-64\Build\fvtest\util\testvmhelper.cpp"

I don't know what those other options do, but /wd4200 is clearly specified, yet it seems to fail for C4200.

Hello71

comment created time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha f652e3f28956298027e364e929edbb6beef328e2

dev-util/pmbootstrap: correctly disable tests

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 13e6161211941f75176e123e495d5c79b3295578

virtual/rust: sync

view details

push time in 2 months

pull request commenteclipse/omr

Use flexible array members, disable MSVC W4200

12:55:45  "/home/jenkins/workspace/Build/include_core/omrtrace.h", line 80.9: 1506-995 (W) An aggregate containing a flexible array member cannot be used as a member of a structure or as an array element.

Looks like it doesn't like using UtTraceRecord in OMR_TraceBuffer https://github.com/eclipse/omr/blob/master/include_core/omrtrace.h#L80

I think this is caused by XL being unfortunately picky. I think it's true that this is not strictly allowed by ISO C, so I guess we would either have to split the FAM into a separate structure, use a configuration macro, or go back to [1], none of which are really great.

Similar problem on Windows:

12:54:06       9>c:\jenkins\workspace\pullrequest-win_x86-64\build\include_core\ute_core.h(128): error C2220: warning treated as error - no 'object' file generated [C:\jenkins\workspace\PullRequest-win_x86-64\Build\build\fvtest\util\omrtestutil.vcxproj]
12:54:06       9>c:\jenkins\workspace\pullrequest-win_x86-64\build\include_core\ute_core.h(128): warning C4200: nonstandard extension used : zero-sized array in struct/union [C:\jenkins\workspace\PullRequest-win_x86-64\Build\build\fvtest\util\omrtestutil.vcxproj]
12:54:06                   Cannot generate copy-ctor or copy-assignment operator when UDT contains a zero-sized array
12:54:06       9>C:\jenkins\workspace\PullRequest-win_x86-64\Build\include_core\omragent.h(350): warning C4200: nonstandard extension used : zero-sized array in struct/union [C:\jenkins\workspace\PullRequest-win_x86-64\Build\build\fvtest\util\omrtestutil.vcxproj]
12:54:06                   Cannot generate copy-ctor or copy-assignment operator when UDT contains a zero-sized array

Not sure what's going on here. seems that /wd4200 is passed, but C4200 is triggering anyways. @keithc-ca do you have an idea?

Hello71

comment created time in 2 months

PR closed eclipse/omr

Reviewers
Fix omrstr_ftime definitions (#5471) comp:core comp:port
+4 -4

1 comment

3 changed files

Hello71

pr closed time in 2 months

pull request commenteclipse/omr

Fix omrstr_ftime definitions (#5471)

hm, this is more broken than I thought.

Hello71

comment created time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 8343e2d1a947ecf28861666bb4ec3525f81e2f70

dev-libs/rocm-opencl-runtime, sys-devel/llvm-roc: drop

view details

push time in 2 months

push eventHello71/omr

Alex Xu (Hello71)

commit sha fada0341ac4f824ee5b690d6a6f105489e0be05d

Fix omrstr_ftime definitions (#5471) Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha f9e1ca249f181a3cf02a78ee5f82d011a6a24553

dev-qt/qtgui: sync

view details

push time in 2 months

create barnchHello71/omr

branch : omrstr_ftime_rettype

created branch time in 2 months

PR opened eclipse/omr

Reviewers
Fix omrstr_ftime definitions (#5471)
+3 -3

0 comment

2 changed files

pr created time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha e80014a73b446b030c87462b2be82221a15da70c

dev-java/openj9-openjdk: fixes

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha e3ec57733d297c0c48bf6fd142e9928965e02706

media-sound/qjackctl: sync

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha b24b8ac92b59173729733344ff4a269184892cba

dev-java/openj9-openjdk-14*: add versionator

view details

Alex Xu (Hello71)

commit sha e386003636dd08be2c8f9868942580f6c0172843

dev-java/openj9-openjdk: add 11.9999

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 6bec8f2faec61b28e30f06b22b4ddd904491aba9

dev-java/openj9-openjdk: remove commented patch

view details

push time in 2 months

issue commenteclipse/openj9

Number of elements in nvvmOpCodeNames does not match the value of TR::NumIlOps

This will very likely be fixed after the next successful OMR Acceptance build. #10388 was just merged which I believe may be the source of the error.

I see that now, thanks!

Hello71

comment created time in 2 months

issue commenteclipse/openj9

Number of elements in nvvmOpCodeNames does not match the value of TR::NumIlOps

master is a direct mirror of OMR master - the openj9 branch is updated from master once the code has been verified through the builds.

right, I'm saying that I just went to https://github.com/eclipse/openj9-omr and assumed that that was the openj9 omr code (since I remembered that it is not at https://github.com/eclipse/omr), but in fact it is at https://github.com/eclipse/openj9-omr/tree/openj9. I'm suggesting that the default branch (HEAD) should be changed to openj9, to avoid some confusion for future users, even if minor. I think it will not affect developers, because as the repo description says, "PRs should be opened against the upstream OMR project whenever possible."

Hello71

comment created time in 2 months

issue commenteclipse/openj9

Number of elements in nvvmOpCodeNames does not match the value of TR::NumIlOps

ah, I was misled by the fact that openj9-omr's default branch is master, not openj9. maybe that should be changed?

Hello71

comment created time in 2 months

issue openedeclipse/openj9

Number of elements in nvvmOpCodeNames does not match the value of TR::NumIlOps

/tmp/portage/dev-java/openj9-openjdk-15.9999/work/openj9-openjdk-jdk15/build/linux-x86_64-server-release/vm/compiler/../compiler/codegen/CodeGenGPU.cpp:1284:39: error: static assertion failed: Number of elements in nvvmOpCodeNames does not match the value of TR::NumIlOps
 1284 | static_assert(sizeof(nvvmOpCodeNames) == (TR::NumIlOps*sizeof(char*)), "Number of elements in nvvmOpCodeNames does not match the value of TR::NumIlOps");
      |               ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I guess this was caused by https://github.com/eclipse/openj9-omr/commits/master/compiler/optimizer/OMRSimplifierTableEnum.hpp, but those changes were made 6 days ago, so I'm not sure why they haven't been caught by CI since then?

created time in 2 months

push eventHello71/omr

Alex Xu (Hello71)

commit sha 6b12b48765ae59b8b4d4e6abb98b62fdf6e5fbdb

Use flexible array members, disable MSVC W4200 Fixes several gcc 10 warnings, standardize FAMs across codebase. Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>

view details

push time in 2 months

push eventHello71/omr

Alex Xu (Hello71)

commit sha 18cf6b653285627d2cd85490d25e6ef234da2066

Use flexible array members, disable MSVC W4200 Fixes several gcc 10 warnings, standardize FAMs across codebase. Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>

view details

push time in 2 months

Pull request review commenteclipse/omr

Use flexible array members, disable MSVC W4200

 list(APPEND OMR_PLATFORM_COMPILE_OPTIONS 	/Zm400  # Precompiled header memory allocation limit 	/wd4577 # Disable warning: Specifying noexcept when exceptions are disabled 	/wd4091 # Disable warning: Caused by broken windows SDK, see also https://connect.microsoft.com/VisualStudio/feedback/details/1302025/warning-c4091-in-sdk-7-1a-shlobj-h-1051-dbghelp-h-1054-3056+	/wd4200 # Disable warning: FAM in struct/union is valid in C and widely supported in C++

hm, I don't understand why, or the difference between /Wx and -Wx, but I'll take your word for it.

Hello71

comment created time in 2 months

PullRequestReviewEvent

issue commenteclipse/openj9

J9UTF8 FAM?

I agree with @gacholio on this issue. I agree entirely that disabling warnings should be done cautiously, and have made a point to do so in exactly this case: I was and continue to be opposed to disabling the -Wstringop-overflow warning, since doing so potentially hides overly aggressive gcc optimization causing incorrect code generation. I am also opposed to globally disabling warnings that trigger on arguably-correct code, such as -Wimplicit-fallthrough, since those can potentially hide serious bugs. In this case, I think this warning is there mostly for historic reasons (Microsoft doesn't like C99), and partially for strict C++ compliance reasons (flexible array members are not technically allowed in C++), but in practice there are no useful implementations which forbid it, and no plausible future implementation would silently generate incorrect code for a FAM. Furthermore, I don't see any reason why FAMs would work in some contexts but not others in OpenJ9. Perhaps in some other projects, you might want to forbid them in header files (since other other projects may include them), but as far as I know, that's not the case here.

Hello71

comment created time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 4b577c393cc6d5f058cc0c3061591b67e2ee0e30

gui-apps/gammastep: import from sorrow

view details

Alex Xu (Hello71)

commit sha dc1db928c90baf0ca0bbad658938e739893fb1f8

x11-misc/redshift: remove wlroots patch crashes and leaks memory

view details

push time in 2 months

issue commenteclipse/openj9

J9UTF8 FAM?

I don't think we should use /wd4200 globally. I'd prefer to push/pop that warning only as necessary.

why is that? are there some contexts in which you want to keep pre-2015 MSVC compatibility?

Hello71

comment created time in 2 months

pull request commenteclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

Our convention is to put an r-value on the left of == and != to avoid some classes of coding errors, so it should be 0 != _key, but I won't insist.

ah yes, I meant to put a comment that I did it this way to match the rest of the file.

Hello71

comment created time in 2 months

push eventHello71/openj9

Alex Xu (Hello71)

commit sha 89ef4ff3c474b1f7e6690abf29808e3e28dcf95d

RuntimeAssumptions: fix NULL arithmetic warning Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 964c786f540fa9a7bef64e60883800ae7a0d3c1d

dev-java/openj9-openjdk: inherit versionator

view details

push time in 2 months

Pull request review commenteclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

 TR_PatchNOPedGuardSiteOnClassPreInitialize::hashCode(char *sig, uint32_t sigLen) void TR_PatchNOPedGuardSiteOnClassPreInitialize::reclaim()    {-   TR_ASSERT_FATAL(_key != NULL, "Attempt to reclaim an already freed _key");+   TR_ASSERT_FATAL((void*)_key != NULL, "Attempt to reclaim an already freed _key");

yeah, I think we can ignore (0 != (uintptr_t)NULL) for now. it would break a huge amount of existing code in other projects too, and AFAIK doesn't have any good optimization rationale. @dsouzai are you OK with 0 != _key here?

Hello71

comment created time in 2 months

issue commenteclipse/openj9

J9UTF8 FAM?

I didn't find any FAMs elsewhere in openj9, but if https://github.com/eclipse/omr/pull/5444 is accepted, I think it would make sense to use /wd4200 here too.

Hello71

comment created time in 2 months

pull request commenteclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

actually, after a brief search (I don't have a C++ IDE), it seems to me that _key should in fact be a void *, and instead TR_RuntimeAssumptionTable should use uintptr_t and size_t where appropriate. for example, TR_RuntimeAssumptionTable::getBucketPtr seems like it should take a size_t, not a uintptr_t.

Hello71

comment created time in 2 months

Pull request review commenteclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

 TR_PatchNOPedGuardSiteOnClassPreInitialize::hashCode(char *sig, uint32_t sigLen) void TR_PatchNOPedGuardSiteOnClassPreInitialize::reclaim()    {-   TR_ASSERT_FATAL(_key != NULL, "Attempt to reclaim an already freed _key");+   TR_ASSERT_FATAL((void*)_key != NULL, "Attempt to reclaim an already freed _key");     jitPersistentFree((void*)_key);-   _key = 0;+   _key = (uintptr_t)(void*)0;

But, again, as a practical matter, it's unlikely to make a difference.

Hello71

comment created time in 2 months

Pull request review commenteclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

 TR_PatchNOPedGuardSiteOnClassPreInitialize::hashCode(char *sig, uint32_t sigLen) void TR_PatchNOPedGuardSiteOnClassPreInitialize::reclaim()    {-   TR_ASSERT_FATAL(_key != NULL, "Attempt to reclaim an already freed _key");+   TR_ASSERT_FATAL((void*)_key != NULL, "Attempt to reclaim an already freed _key");     jitPersistentFree((void*)_key);-   _key = 0;+   _key = (uintptr_t)(void*)0;

See my other comment, but in brief, I believe this is not strictly correct according to the standard, similar to void *p; memset(&p, 0, sizeof(p)); being an incorrect way to initialize a null pointer to void.

Hello71

comment created time in 2 months

Pull request review commenteclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

 TR_PatchNOPedGuardSiteOnClassPreInitialize::hashCode(char *sig, uint32_t sigLen) void TR_PatchNOPedGuardSiteOnClassPreInitialize::reclaim()    {-   TR_ASSERT_FATAL(_key != NULL, "Attempt to reclaim an already freed _key");+   TR_ASSERT_FATAL((void*)_key != NULL, "Attempt to reclaim an already freed _key");

The ISO C++ standard defers to the ISO C standard, which gives no guarantees on the behavior of (u)intptr_t except that pointers to void may be converted to and from it. It is not guaranteed that all-zero pointers retain the same value when converted to (u)intptr_t. Furthermore, it is not guaranteed that null pointers are represented as all zeroes in the first place. However, as a practical matter, current implementations directly copy the byte representation as an integer, allow integer operations on them, represent null pointers as all zeroes, and are unlikely to change any of those behaviors or make optimization decisions based on them.

In conclusion, the cast is more correct, but any of these three alternatives are likely to be equivalent in practice.

Hello71

comment created time in 2 months

pull request commenteclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

also, for future reference, the initial driver of this PR was to fix a gcc warning.

Hello71

comment created time in 2 months

pull request commenteclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

not sure what's going on here exactly. _key doesn't seem to be read anywhere else, so shouldn't it be a bool?

_key is a member of the parent class OMR::RuntimeAssumption [1]. The reason it is set to NULL is because of a double free bug that was fixed about a year ago; you can read the details over at [2].

Ah, I see. I am used to C, so forgot to check class access.

Your change looks reasonable to me; however, you'll need to sign the Eclipse ECA in order for the change to get accepted into the project [3].

I have already signed the ECA, but it was not recognized because I committed using the web editor. I have now amended the commit.

Hello71

comment created time in 2 months

push eventHello71/openj9

Alex Xu (Hello71)

commit sha 156e26459cc9b7ea45f35f1e18f9a3b356a669ad

RuntimeAssumptions: fix NULL used in arithmetic ISO C11 section 7.20.1.4 only guarantees conversions to and from void pointer Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>

view details

push time in 2 months

issue commenteclipse/openj9

J9UTF8 FAM?

I've tried the FAM, but it doesn't work on the outdated windows compilers that we use.

That doesn't sound right, unless a different compiler is used for omr. As I point out in https://github.com/eclipse/omr/pull/5444, FAMs are already used in at least two places in omr. They're just hidden by #pragma warning(disable : 4200).

Hello71

comment created time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 9f3a96eb034a8bc53b515d047f3a8a3be98ce6a7

net-misc/gallery-dl: bump, add tests

view details

Alex Xu (Hello71)

commit sha b073757a6aa532eb8f4fbe6662fd31ac86be10b2

sys-devel/llvm-roc: sync Manifest

view details

Alex Xu (Hello71)

commit sha 039f0c0bed658e37dd17edf795a95bca492f62d4

app-text/texlive-core: sync Manifest

view details

Alex Xu (Hello71)

commit sha d10c1c2317891d3006e0b8e92aad17806d3225e2

dev-java/openj9-openjdk: repoman appeasement

view details

Alex Xu (Hello71)

commit sha ca55259160f92db253aa9eeb248d53733d0dcd40

virtual/{jdk,jre}: add 15

view details

Alex Xu (Hello71)

commit sha 3f14719ccd53c0ad66a62e8375c23c6578bcdcdc

dev-java/openj9-openjdk-bin: repoman appeasement

view details

Alex Xu (Hello71)

commit sha 8e3439aa57d344379ac3435cd9f78682c7002be2

profiles/package.mask: more repoman appeasement

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 9d766f69fd8df831c9d2e0e8f5171886d02d0540

dev-java/*openjdk*: fix escaping needed for adoptopenjdk-manifest

view details

Alex Xu (Hello71)

commit sha bb16cf08d6c76783e200d5f8e0c0607bbefafe71

tools/adoptopenjdk-manifest: fetch adoptopenjdk sums

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 13f707dd6b50322caa18641d3306bc5b1e451f9b

dev-java/openj9-openjdk-bin: add 11 debugimage, fixes

view details

push time in 2 months

push eventHello71/gentoo-overlay

Alex Xu (Hello71)

commit sha 139072db7ac4d30ba74a372a793bd78110a4e936

sys-devel/llvm-roc: sync

view details

Alex Xu (Hello71)

commit sha 7c302914f5b566df48488e3959552feae1c1cab1

dev-java/openj9-openjdk: add 9999, various fixes

view details

push time in 2 months

issue commenteclipse/openj9

J9UTF8 FAM?

@gacholio seems to work on 15 (14 master doesn't compile atm?). for some reason without the patch I only get a warning, not an error. I'm not really convinced that removing the member is a better option than just making it a flexible array, but I guess it's fine. the commit messages are a little funny, but functionally it seems to work alright. thanks!

Hello71

comment created time in 2 months

PR opened eclipse/openj9

RuntimeAssumptions: fix NULL used in arithmetic

ISO C11 section 7.20.1.4 only guarantees conversions to and from void pointer

not sure what's going on here exactly. _key doesn't seem to be read anywhere else, so shouldn't it be a bool?

+2 -2

0 comment

1 changed file

pr created time in 2 months

more