search for: afaiui

I just detected, that det() is not working on complex matrices any more, due to the fix to the bug reports noted above. I am not happy with this, as determinants are perfectly usable on complex matrices. AFAIUI the bugs resulted from less than optimal behaviour of qr() in certain cases. IMHO this is due to the unhappy decision to use a default for parameter tol to decide whether the the decomposition is rank deficient. A better fix for (PR#1244) should be considered. I propose, using qr method with tol=0...

...2016, at 11:25 PM, Laurent Gautier <lgautier at gmail.com> wrote: > (...) > > Is this expected ? Shouldn't R rely on the definition in stdint.h > > But there need not be one in stdint.h, as the type is optional in C99/C11/C++11 and likely not present in C++98. > > AFAIUI stdin.h is part of C99: https://en.wikipedia.org/wiki/C_standard_library#Header_files > > While at it, it is not exactly like C99 is the latest thing in town. Wouldn't relying on it give an opportunity to simplify the code base ? > > > > > Laurent > > > &g...

...Stepping through the function, we stop on the call to 'ext', and can set the value of 'bar', but because there are two locations (and LiveDebugValues picked the long term register $ebp rather than $edi), you can set "bar" but it has no effect on the call to 'ext'. AFAIUI, this is never a problem at -O0 because there's only ever one location for a variable. With optimisations, and without a way to describe multiple locations for a variable in DWARF, I don't think it's generally solvable. Plus, if you had two variables that have been CSE'd into being...

Op 27-11-18 om 18:34 schreef Daniel Vetter: > KMS drivers really should all be able to restore their display state > on resume without fbcon helping out. So make this the default. > > Since I'm not entirely foolish, make it only a default, which drivers > can still override. That way when the inevitable regression report > happens I can fix things up with a one-liner plus

...it_pointer is designed for, it's a strict improvement in debug > experience because you're recovering information that couldn't be > expressed. However for PR37682 it's a trade-off between whether the > user might want to examine the pointer, or the pointed-at integer: > AFAIUI, we can only express one of the two, not both. Wheras for > mem2reg'd variables referred to by DIE, there is never a pointer to be > lost. > > I think my preference would always be to see temporarily-promoted > values as there's no other way of observing them, but others migh...

On 29/12/2016 15:55, Simon Urbanek wrote: > The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should be now fixed in R-devel - please check if that works for you. Rconfig.h would be appropriate if Rinterface.h is being included from C code using the same compiler as used for R. But as Rinterface.h

...; > > > Revert "drm/radeon: dont switch vt on suspend" > > > > Thanks to Michel Dänzer for pointing this one out. > > Maybe just reload the gamma lut on resume for radeon, instead of relying on fbcon? It also caused random sound issues and other fun. Also, afaiui radeon does load the lut. Except because of timing or bad luck, it doesn't work reliably, and the vt switch doing it a 2nd time helps out. -Daniel > Otherwise patch looks sane, would be nice if radeon was fixed instead of worked around. > > Reviewed-by: Maarten Lankhorst <maarten....

...<lgautier at gmail.com> wrote: >>> (...) >>> >>> Is this expected ? Shouldn't R rely on the definition in stdint.h >>> >> > But there need not be one in stdint.h, as the type is optional in > C99/C11/C++11 and likely not present in C++98. AFAIUI stdin.h is part of C99: https://en.wikipedia.org/wiki/C_standard_library#Header_files While at it, it is not exactly like C99 is the latest thing in town. Wouldn't relying on it give an opportunity to simplify the code base ? Laurent > > rather than define its own ? >>> &...

...ose phone that are not set to autorecord and set the corresponding CDR(userfield) so my web app can spot recorded calls. This again works well *if* the feature code is used on the calling channel. However, if it's on the *called* channel then the CDR(userfield) doesn't get updated because AFAIUI the CDR record is all in the calling thread. Can anyone tell me how I can set the userfield for the CDR record in the *called* thread? I've tried setting variables (__RECORDINGFILENAME) and setting CDR(userfield)=${RECORDINGFILENAME} in the hangup code but this again only works if the feature...

> I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable > DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt? Below

...ug >>>>> experience because you're recovering information that couldn't be >>>>> expressed. However for PR37682 it's a trade-off between whether the >>>>> user might want to examine the pointer, or the pointed-at integer: >>>>> AFAIUI, we can only express one of the two, not both. Wheras for >>>>> mem2reg'd variables referred to by DIE, there is never a pointer to be >>>>> lost. >>>>> >>>>> I think my preference would always be to see temporarily-promoted >>&g...

...39;s a strict improvement in debug >>> experience because you're recovering information that couldn't be >>> expressed. However for PR37682 it's a trade-off between whether the >>> user might want to examine the pointer, or the pointed-at integer: >>> AFAIUI, we can only express one of the two, not both. Wheras for >>> mem2reg'd variables referred to by DIE, there is never a pointer to be >>> lost. >>> >>> I think my preference would always be to see temporarily-promoted >>> values as there's no othe...

...not it's > + * already reached 0. This is only valid to use in scenarios where you are > + * already guaranteed to have at least one active topology reference to @mstb. > + * Otherwise, drm_dp_mst_topology_get_mstb() should be used. s/should/must/ (or my English understanding is off, afaiui "should" isn't a strict requirement per rfc2119) > + * > + * Any topology references acquired with this function must be released when > + * they are no longer being used by calling drm_dp_mst_topology_put_mstb(). > + * > + * See also: > + * drm_dp_mst_topology_get_...

Hi llvm-dev, I've uploaded a prototype patch at https://reviews.llvm.org/D70720 which adds a new feature to llvm-objdump: displaying the location (in registers/memory/etc) of source-level variables alongside the disassembly display. I've put a demo of the output at https://reviews.llvm.org/M2. I have two use-cases in mind for this: * Users reading the disassembly of compiled code. It

...scenarios where you > > > are > > > + * already guaranteed to have at least one active topology reference to > > > @mstb. > > > + * Otherwise, drm_dp_mst_topology_get_mstb() should be used. > > > > s/should/must/ (or my English understanding is off, afaiui "should" isn't > > a strict requirement per rfc2119) > > > > > + * > > > + * Any topology references acquired with this function must be released > > > when > > > + * they are no longer being used by calling > > > drm_dp_mst_to...

...This is only valid to use in scenarios where you > > are > > + * already guaranteed to have at least one active topology reference to > > @mstb. > > + * Otherwise, drm_dp_mst_topology_get_mstb() should be used. > > s/should/must/ (or my English understanding is off, afaiui "should" isn't > a strict requirement per rfc2119) > > > + * > > + * Any topology references acquired with this function must be released > > when > > + * they are no longer being used by calling > > drm_dp_mst_topology_put_mstb(). > > + * &g...

Hi all, Recently there''s been discussion [1] in the Linux community about how filesystems should deal with rename(2), particularly in the case of a crash. ext4 was found to truncate files after a crash, that had been written with open("foo.tmp"), write(), close() and then rename("foo.tmp", "foo"). This is because ext4 uses delayed allocation and may not

...;>>>>>>>>> expressed. However for PR37682 it's a trade-off between whether >>>>>>>>>> the >>>>>>>>>> user might want to examine the pointer, or the pointed-at integer: >>>>>>>>>> AFAIUI, we can only express one of the two, not both. Wheras for >>>>>>>>>> mem2reg'd variables referred to by DIE, there is never a pointer >>>>>>>>>> to be >>>>>>>>>> lost. >>>>>>>>>&...

...but is still about vcpu pinning (something that I forgot to change when working on NUMA-aware scheduling), as the first patch in the series itself. I really believe I addressed all of Ian's comments, although, no, I haven't converted the parsing to flex (which was not an hard requirement, AFAIUI), because I don't think it is worthwhile in this case. Let me know what you think about it. Thanks and Regards, Dario --- Dario Faggioli (5): xl: update the manpage about "cpus=" and NUMA node-affinity libxl: introduce libxl_node_to_cpumap xl: allow for node-wise...

Hi debuginfo-cabal, tl;dr: Let's please consider using a new implementation of LiveDebugValues that produces richer information, might be slightly faster, but mostly will support the instruction referencing and value tracking paradigm from my RFC [0] rather than the location tracking that LiveDebugValues does today. In that RFC, the main motivator is to treat variable locations a bit more