To future readers: if you're still seeing this, make sure you have the
file `/sys/kernel/mm/lru_gen/enabled` and its value is `0x0007` (it's
just the one I tested). AFAIK kernel doesn't enable MLRU by default; but
at the same time AFAIK all major distros enable it in their kernels.
--
You receive
(In reply to Konstantin Kharlamov from comment #70)
> Also, these days the Multi-LRU patchset should pretty much resolve the
> problem. It is not yet upstream, but is used in downstream kernels such as
> linux-zen and liquorix-kernel. There is hope it will be merged by 5.19¹
MLRU patches were merg
To future readers: if you're still seeing this, make sure you have the
file `/sys/kernel/mm/lru_gen/enabled` and its value is `0x0007` (it's
just the one I tested). AFAIK kernel doesn't enable MLRU by default; but
at the same time AFAIK all major distros enable it in their kernels.
--
You receive
(In reply to Konstantin Kharlamov from comment #70)
> Also, these days the Multi-LRU patchset should pretty much resolve the
> problem. It is not yet upstream, but is used in downstream kernels such as
> linux-zen and liquorix-kernel. There is hope it will be merged by 5.19¹
MLRU patches were merg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #10 from Konstantin Kharlamov ---
(In reply to Alejandro Colomar from comment #7)
> (In reply to Konstantin Kharlamov from comment #5)
> > So basically -Wc++-compat warns about every heap memory allocation, of which
> > there are doz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > It is included in -Wc++-compat .
>
> Cool, thanks! I'll add the warning to the list we compile the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115684
--- Comment #1 from Konstantin Kharlamov ---
FWIW, IRL these cases happen during refactoring, when you factor out a code to
a smaller function, and some variables from the original function become
pointers. I honestly never even check the parame
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
Comparing an enum field with a pointer produces no warnings (while comparing an
int to a pointer produces them). We just had a regression due to this missing
check, such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Andrew Pinski from comment #2)
> It is included in -Wc++-compat .
Cool, thanks! I'll add the warning to the list we compile the project with,
thank you!
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
It's a common pattern to have some `enum Foo { one, two, three }`, and then
some 2-dimensinal array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
--- Comment #12 from Konstantin Kharlamov ---
(In reply to Martin Uecker from comment #11)
> A conforming C compiler has to diagnose all violations of constraints with
> the same correct type of x in all branches (not the type it would have in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
--- Comment #10 from Konstantin Kharlamov ---
(In reply to uecker from comment #9)
> Some warnings are then even required to be standard compliant.
I just searched through the C standard and no warnings seem to be required by
it. The only place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
--- Comment #8 from Konstantin Kharlamov ---
(In reply to uecker from comment #7)
> Fundamentally, the program is that _Generic is not ideally designed for this
> use case.
Why?
> One could consider an extension
>
> _Generic(x, int i: f(i), l
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When a switch-case has a "fallthrough" case that is surrounded by an `#ifdef`
and is not compiled in, GCC does not rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
On Fri, 25 Nov 2022 at 09:40, LIU Hao via Gcc wrote:
> One annoying thing about GCC is that, for x86 if I need to write I piece of
> inline assembly then I
> have to do it twice: one in AT&T syntax and one in Intel syntax.
Why? A default is merely a default. I don't really see why changing
that
Modern kernels handle SWAPPING situations much better.
Also, these days the Multi-LRU patchset should pretty much resolve the
problem. It is not yet upstream, but is used in downstream kernels such
as linux-zen and liquorix-kernel. There is hope it will be merged by
5.19¹
1: https://www.phoronix.
Modern kernels handle SWAPPING situations much better.
Also, these days the Multi-LRU patchset should pretty much resolve the
problem. It is not yet upstream, but is used in downstream kernels such
as linux-zen and liquorix-kernel. There is hope it will be merged by
5.19¹
1: https://www.phoronix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92559
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #4)
> By the way, FTR: I don't have the code anymore, but initially the problem
> came from a real-life algorithm involving lots of state, which looked ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92559
--- Comment #4 from Konstantin Kharlamov ---
By the way, FTR: I don't have the code anymore, but initially the problem came
from a real-life algorithm involving lots of state, which looked barely
readable when implemented in iterative way (i.e. a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92559
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Andrew Pinski from comment #2)
> I don't think this can ever be optimized. Mainly because there are copies
> happening due to passing via value and returning by value.
Please correct me
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
Created attachment 51176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51176&action=edit
preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718
--- Comment #9 from Konstantin Kharlamov ---
Omg, I am sorry, please ignore my comment. For some incomprehensible reason
bugzilla circles through bug entries upon sending a comment. My comment here
was supposed for another report, but then appare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93437
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
Hello! I don't know all the details, and it surprises me nobody is
asking for them. Let me be the first.
On Fri, 26 Mar 2021 at 23:03, Nathan Sidwell wrote:
> I’m a white dude with a British accent.
> /Of course/ I have white male privilege.
So, this text makes me feel sorry for the author, but
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
The following code, exploiting tail-recursion, does not get optimized into a
loop with -O3 option, so it crashes if you try to run it.
#include
using MyMap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48363
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
--- Comment #6 from Konstantin Kharlamov ---
Thanks, okay, so, for the record: comment #3 seems no longer relevant, since
the function `find_tail_calls()`, when analyzing g(), gets executed till its
end. No early returns anywhere. Tested with: GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91515
--- Comment #2 from Konstantin Kharlamov ---
I think this is a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92474
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Jakub Jelinek from comment #1)
> Note, starting with r273603, the trunk doesn't tail call optimize this
> either even without -fsanitize=, unless -fno-tree-sra.
Is there a report for this
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #7 from Konstantin Kharlamov ---
@Jonathan Wakely I think you accidentally closed the report, would you mind to
reopen it (I'm not seeing why would it be "invalid", people even confirmed that
more support for std containers is being a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #6 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #5)
> No, that's not how undefined behaviour works. You are wrong to expect a crash
No, in context of the report I'm not. You're correct this is not how UB w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #4 from Konstantin Kharlamov ---
(In reply to Marc Glisse from comment #3)
> -D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it
> detects this.
Oh, cool, I'll make use of it, thanks for the hint!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #1 from Konstantin Kharlamov ---
Btw, worth noting that clang 8.0.1 does not handle it either.
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Martin Liška from comment #4)
> (In reply to Konstantin Kharlamov from comment #3)
> > (In reply to Martin Liška from comment #2)
> > > I can see a ASAN error:
> >
> > Correct. You set th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Martin Liška from comment #2)
> I can see a ASAN error:
Correct. You set the report status to WAITING: do you expect some answer from
me, or was it accidental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
--- Comment #1 from Konstantin Kharlamov ---
FTR, on IRC was referenced the following paper that may be interesting for
implementors
https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
The testcase below would've worked if instead of `return {l,…` was used `return
{move(l),…`. But it wasn't, and due to lack of borrow-semantics in C++ language
such mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91751
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #2)
> The advantage of showing the location of the constructor is that you can see
> which object is being destroyed. If the location was shown as the end of t
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
As the title says. I'm not aware of a way to get backtrace with gcc builtins,
so I'm using gdb in testcas
On Wed, 11 Sep 2019 at 12:50, Hi-Angel wrote:
>
> On Wed, 11 Sep 2019 at 09:55, Nicholas Krause wrote:
> >
> >
> > On 9/11/19 2:30 AM, Andreas Schwab wrote:
> > > On Sep 11 2019, Nicholas Krause wrote:
> > >
> > >> I was wondering what is
On Wed, 11 Sep 2019 at 09:55, Nicholas Krause wrote:
>
>
> On 9/11/19 2:30 AM, Andreas Schwab wrote:
> > On Sep 11 2019, Nicholas Krause wrote:
> >
> >> I was wondering what is the easiest way to allow source tree wide
> >> ctags.
> > There is make TAGS, which uses etags.
Note: over time on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91436
--- Comment #6 from Konstantin Kharlamov ---
Thank you!
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When the reason for an undefined function is too low c++ standard, g++ still
suggests to include the header where it's supposed to be. As a result, when in
a project you're not fam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311
Konstantin Kharlamov changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311
--- Comment #1 from Konstantin Kharlamov ---
Created attachment 46652
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46652&action=edit
rr record for the testcase, results in stack-use-after-scope
I'm also attaching the `rr` record for the
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86050
--- Comment #7 from Konstantin Kharlamov ---
(In reply to Aso Renji from comment #6)
> (In reply to Konstantin Kharlamov from comment #5)
> > Just tested with 8.3.0 version on the other PC, same there, i.e. stack space
> > does not increase when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86071
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Alexander Monakov from comment #1)
> In GCC there's no way to selectively enable a few optimizations with their
> -f flags at -O0 level: -O0 means that optimizations are completely disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86050
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #4)
> Works for me on gcc 9.1.0. I compile it as:
>
> $ g++ test.cpp -o a -O2
>
> And then running `./a` results in a bunch of:
>
> Consumed 80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86050
--- Comment #4 from Konstantin Kharlamov ---
Works for me on gcc 9.1.0. I compile it as:
$ g++ test.cpp -o a -O2
And then running `./a` results in a bunch of:
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77433
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
I see, thanks!
On Пн, Feb 18, 2019 at 6:18 PM, Duy Nguyen wrote:
On Mon, Feb 18, 2019 at 10:09 PM wrote:
On Пн, Feb 18, 2019 at 6:02 PM, Duy Nguyen
wrote:
> On Mon, Feb 18, 2019 at 9:44 PM wrote:
>>
>> # Steps to reproduce (in terms of terminal commands)
>>
>> $ mkdir foo
On Пн, Feb 18, 2019 at 6:02 PM, Duy Nguyen wrote:
On Mon, Feb 18, 2019 at 9:44 PM wrote:
# Steps to reproduce (in terms of terminal commands)
$ mkdir foo
$ cd foo
$ git init
Initialized empty Git repository in /tmp/foo/.git/
$ echo hello > testfile
$ git add
# Steps to reproduce (in terms of terminal commands)
$ mkdir foo
$ cd foo
$ git init
Initialized empty Git repository in /tmp/foo/.git/
$ echo hello > testfile
$ git add testfile && git commit -m "my commit1"
[master (root-commit) d5f0b47] my commit1
1 file changed, 1 inse
I never could understand, why field reordering was removed from GCC? I
mean, I know that it's prohibited in C and C++, but, sure, GCC can
detect whether it possibly can influence application behavior, and if
not, just do the reorder.
The veto is important to C/C++ as programming languages, but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89326
--- Comment #2 from Konstantin Kharlamov ---
Btw, I just occasionally noted: godbolt site adds their own highlight to GCC
output, in particular they highlight the whole line with "required from here"
with blue. Maybe something can be borrowed fro
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
Compile-errors of constructors and templates can give a lot of output. Usually
the first thing in debugging is to figure out where the
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
# Steps to reproduce (in terms of terminal commands):
$ cat test.cpp
#include
struct MyS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89147
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Andrew Pinski from comment #1)
> >Possible workarounds are welcome.
>
> Use -ffat-lto-objects or use a .s file.
Thank you for reply!
Adding a `-ffat-lto-objects` to the command above di
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This came up while researching why -flto build of Mesa fails with linking
errors. The asm snippet below is from an auto-generated code
erity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
In most projects a definite pattern that's unlikely to be executed is a
PRINT_ERR macro which is basically a wrap
> Has anyone run *BSD or FreeDOS or something else which would allow a Ryzen to
> get bored for hours/days?
Yes, FreeBSD is affected too
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-BSD-Lock-
Ups-2018
--
You received this bug notification because you are a member of Kernel
Packages,
> Has anyone run *BSD or FreeDOS or something else which would allow a Ryzen to
> get bored for hours/days?
Yes, FreeBSD is affected too
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-BSD-Lock-
Ups-2018
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #6 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Konstantin Kharlamov from comment #2)
> > As far as such trivial optimizations concerned, I'd prefer to rely on the
> > compiler figuring th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #2)
> Thanks, I prefer the `{x}` to just `x` because in the latter I'm being
*"in the former", sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #1)
> That would require a lot of special-casing just for std::variant.
Well, I think, in place of std::variant there could be any struct-wrapper; but
I get i
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When, in a code, a copy-constructor deleted but used, GCC issues an absolutely
unhelpful message that it couldn't convert the arg
onent: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
# Steps to reproduce:
$ cat test.cpp
struct Node {
Node* chi
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
Steps to reproduce:
$ cat test.cpp
int ret_int() { return -1; }
int main() {
unsigned foo = ret_int();
(void)foo
On 7 December 2017 at 19:22, Ewen Chan wrote:
> Pros (for Linux): It's faster when it is running at runlevel 3.
Oh, by the way, I forgot to mention — just a tiny detail you might be
curious of. I'm pretty sure you're running some old kernel, however in
every kernel release there's a bunch of impr
-- Forwarded message --
From: Hi-Angel
Date: 7 December 2017 at 21:12
Subject: Re: X is consuming ~100 GiB of RAM(!)
To: Ewen Chan
On 7 December 2017 at 19:22, Ewen Chan wrote:
>> That's one more of beauties of open source
>
> The thing that I can think of t
open source :) That said, I don't know how hard it might
be on SuSe. On Archlinux here we have ᴬᵁᴿ repository, and building
e.g. mesa from source is as easy as a command "yaourt -S mesa-git".
On 7 December 2017 at 18:36, Ewen Chan wrote:
> Hi-Angel:
>
> I'm just askin
ecember 2017 at 18:18, Ewen Chan wrote:
> Hi-Angel:
>
>> Have you rebuild initramfs after blacklisting by the way?
>
> So...I did what that thread (and the thread that it points to within that
> thread) says to do.
>
> Created blacklist.conf and then put in there:
>
[disabled]
> Capabilities: [dc] Power Management version 1
> Kernel modules: mgag200
>
> Is there another way to confirm that the blacklisting did what it was
> supposed to?
>
> Thanks.
>
> On Wed, Dec 6, 2017 at 11:39 PM, Hi-Angel wrote:
>>
On 7 December 2017 at 06:19, Hi-Angel wrote:
> On 7 December 2017 at 06:05, Ewen Chan wrote:
>> Hi-Angel:
>>
>> Thank you for that!!!
>>
>> Two questions:
>>
>> 1) Will the commands from the CentOS distro work with SuSE?
>
> Well, the linke
On 7 December 2017 at 06:05, Ewen Chan wrote:
> Hi-Angel:
>
> Thank you for that!!!
>
> Two questions:
>
> 1) Will the commands from the CentOS distro work with SuSE?
Well, the linked post doesn't show how to blacklist because it was
created after the fact (author fo
On 7 December 2017 at 05:45, Hi-Angel wrote:
> On 6 December 2017 at 15:25, Vladimir Dergachev
> wrote:
>>
>> Keep in mind that Xorg will show memory usage from mapping graphics memory..
>> which could be large on your card.
>>
>> Also, are you using CUDA
On 6 December 2017 at 15:25, Vladimir Dergachev wrote:
>
> Keep in mind that Xorg will show memory usage from mapping graphics memory..
> which could be large on your card.
>
> Also, are you using CUDA ?
I don't think Matrox provides CUDA functional.
@Ewen, by the way, this mail pushed me to ano
On 6 December 2017 at 02:36, Vladimir Dergachev wrote:
>
> Also, given the the high usage does not happen outside of gnome session,
> perhaps this is connected to compositing..
There're 2 mails which didn't get yet into the ML because they contain
a screenshot, and mailman complained about a susp
The troubleshooting link you provided states that the high memory
usage typically belongs to some other application. Sorry, I am just an
occasional bystander here, and can't tell much of technical details,
but I imagine it works like this(I hope someone will correct me on
details): an app requests,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83161
--- Comment #1 from Constantine Kharlamov ---
Just another data point I forgot to mention:
https://stackoverflow.com/questions/3311182/linux-c-easy-pretty-dump-printout-of-structs-like-in-gdb-from-source-co
7k views. Author of this one went as fa
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
It's very useful for debugging to pretty-print an entire struct. Typically
people firing up gdb for this, but sometimes it's
I am a bit confused if you're talking of modern toolkits, or older
ones, or in general. If in general, than this is untrue — QtCreator
allows you to design GUI pretty much like Borland Delphi or Visual
Studio. For GTK alike thing is Glade — it's not so good as "design"
tab in QtCreator by virtue of
To me it looks like something with Intel DDX driver. To check if it's
true try creating a file /etc/X11/xorg.conf.d/20-modesetting.conf with
content like:
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
Option "Backlight" "intel_backlight"
EndSection
On 13 October 2017 at 17:02, David Edelsohn wrote:
> On Fri, Oct 13, 2017 at 3:06 AM, Sebastian Huber
> wrote:
>> Hello,
>>
>> I would like to update the documentation of these compiler flags and have
>> some questions. The -ffunction-sections and -fdata-sections documentation
>> is currently:
>
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
This code used to work prior to gcc-7.1 (it worked on 4.x, and — I just tested
— 6.3 works too, with a warning though):
struct DataPacket
I just started hacking, and ATM I'm trying to fix visual map in Yi *(it
have to be in Operators.hs, and to work on text objects)*, and I even did
the actual code, but I'm stuck on removing the previous keybinding. I feel
silly, but I seem to removed everything which could cause it, still, after
Same here, horribly want to migrate from the combination Emacs+Evil :D
I'd say that Emacs is the worst implementation of the greatest idea. Yi
definitely doesn't seem to be as mature in the sense of addons, but still,
if I'd put as much efforts in it as I put in my Emacs config/debugging back
t
Is there a way to disallow QEMU an interception of certain keys?
I recently moved here from VirtualBox, and there was a great upside
that it didn't intercept hotkeys of my WM *(it's AwesomeWM)*. However
QEMU does intercepts them, so e.g. to switch somewhere from QEMU
window I need to press first a
ey not in d2", "\n"
> else:
> if type(d1[k]) is dict:
> if path == "":
> path = k
> else:
> path = path + "->" + k
> findDiff(d1[k],d2[k]
ument it
produced 1gb of output. I think the problem is that most elements
still appears in output many times — the check that in backtrace
wasn't the current element is ensures only that it wouldn't fall in an
infinite cycle.
2015-08-21 7:28 GMT+03:00 Hi-Angel :
>>What is the pur
>What is the purpose of comma separated machine data in a word processor
>document?
That is to save in file. The more newlines, the easier differ the text
with vimdiff. Because if'd left these thousands symbols lines as is,
it would be really hard to see what just changed.
>Why don't you save th
Yay, that's actually cool :з So, I modified the code a bit to make it
Pythonish. It doesn't print all existing properties though, but I
modified it to print also at least every paragraph property. It is:
doc = desktop.loadComponentFromURL("file:///tmp/output.odt" ,"_blank", 0, ())
file = open('/tm
Okay, I reported an enhancement request; let's if it could be done
https://bugs.documentfoundation.org/show_bug.cgi?id=93516
2015-08-17 7:46 GMT+03:00 Hi-Angel :
> Well, I think at some level that all comes to a simple objects.
>
> Anyway, how do you compare properties? E.g. I was r
cName» just did changed?
2015-08-17 4:28 GMT+03:00 Andrew Douglas Pitonyak :
> On 08/16/2015 03:53 PM, Hi-Angel wrote:
>>
>> Often it is really hard to figure out for how to do something in UNO
>> unless someone already did it, and left a description on the Internet.
>
1 - 100 of 120 matches
Mail list logo
