search for: 2606

...compilation mode. I don't yet understand this concern since these stubs are compile time only, and it seems that the pending function system inherently uses stubs. Anyway I'm sure my understanding will get fixed soon enough. :-) The new code is NOT commented. This patch was NOT attached to 2606. Rather I feel this patch is experimental in nature. As before I tried to use "GMV Mod" as comments to mark my modifications as long as they did not involve introducing new files. If one is interested and wants to use this patch, one should use the test cases found in 2606 and modify t...

https://bugzilla.mindrot.org/show_bug.cgi?id=2606 Bug ID: 2606 Summary: IPv6 bind address vs autoconfiguration privacy Product: Portable OpenSSH Version: -current Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5...

...> yet understand this concern since > these stubs are compile time only, and it seems that the pending function > system inherently uses stubs. Anyway > I'm sure my understanding will get fixed soon enough. :-) The new code is > NOT commented. > This patch was NOT attached to 2606. Rather I feel this patch > is experimental in nature. As before I tried to use "GMV Mod" > as comments to mark my modifications as long as they did not > involve introducing new files. If one is interested and wants > to use this patch, one should use the test cases found in...

This is the second version of a patch, which I recently attached to bug 2606, whose original version was modified to reflect the lists comments. Also please note the comment at the end of this email, which basically questions whether this bug is really a bug. 1) To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to directly a...

...erToNamedFunction) and easily resolved cross-module references. What do you think ? Anyone have an opinion on this ? Olivier. On Fri, Feb 19, 2010 at 5:21 PM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > This is the second version of a patch, which I recently attached to bug > 2606 <http://llvm.org/bugs/show_bug.cgi?id=2606>, whose original version > was > modified to reflect the lists comments. Also please note the comment at the > end of this email, which basically > questions whether this bug is really a bug. > > 1) To solve the foreign Module Globa...

...> yet understand this concern since > these stubs are compile time only, and it seems that the pending function > system inherently uses stubs. Anyway > I'm sure my understanding will get fixed soon enough. :-) The new code is > NOT commented. > This patch was NOT attached to 2606. Rather I feel this patch > is experimental in nature. As before I tried to use "GMV Mod" > as comments to mark my modifications as long as they did not > involve introducing new files. If one is interested and wants > to use this patch, one should use the test cases found in...

On Mon, Mar 1, 2010 at 4:52 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > I do have one question though. After having done the fix and the appropriate unit tests, > does one still need to add to the tests suite for the testing bots, and add to test for make > check (for this kind of bug fix)? Do the unittests somehow get invoked by make check? I > guess I don't

...urn this "cross module linkage" off, but I'm still in the process of understanding your previous comments on this. Thanks again for the help and time by the way. Garrison PS: I'm still studying your last detailed comments to thread: "2nd attempt for a working patch for bug 2606". I'll keep that one alive. On Feb 26, 2010, at 21:23, Jeffrey Yasskin wrote: > FWIW, I don't like the idea of adding a new JIT class to support > linking. I think you can do it without this. > > On Fri, Feb 26, 2010 at 5:44 PM, Garrison Venn <gvenn.cfe.dev at gmail...

CentOS Errata and Security Advisory 2019:2606 Important Upstream details at : https://access.redhat.com/errata/RHSA-2019:2606 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 5cb5251df550f50ccb605cf53a6a720f38ac6c7e77ccb34bd7a018a5b8b5ccd0 kdelibs-4.14.8-11.el7_7.i686...

CentOS Errata and Security Advisory 2019:2606 Important Upstream details at : https://access.redhat.com/errata/RHSA-2019:2606 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: f26332016bae035a69a37bdf44d35fc5fc12dbfe07473b0358bbf2b581b0d721 kde-settings-19-23.10.el7.ce...

...mmary(model1, split = list(group = list("1&3 vs 2"=1, "1 vs 3" = 2))) This gives me the printout summary table that I want. i.e. model2 Df Sum Sq Mean Sq F value Pr(>F) group 2 4090 2045 8.081 0.000682 *** group: 1&3 vs 2 1 1483 1484 5.863 0.017988 * group: 1 vs 3 1 2606 2606 10.300 0.001987 ** Residuals 72 18219 253 That's the summary table that I want, but I want to extract, for example the F value of 5.863. Looking at the structure of that object I get str(model2) List of 1 $ :Classes ?anova? and 'data.frame': 4 obs. of 5 variables: ..$ Df : Name...

...we would take a compile time hit here by using getPointerToFunctionOrStub(...) versus my forceEmitFunctionStub(...) since we know at that point in the call stack that we are already dealing with a declaration. I don't know if this is a viable concern, but if not I'd be happy to change the 2606 working patch to reflect use of getPointerToFunctionOrStub(...) in place of forceEmitFunctionStub(...). On the pro side, using getPointerToFunctionOrStub(...) does get rid of introducing a new method (forceEmitFunctionStub(...)), which will not have the same future design support as getPointerTo...

The patch I recently attached to bug 2606, reproduced here, is my first attempt to solve this issue as represented by the attached test cases. To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a found "external" GlobalVariable. To solve the foreign Module F...

...workaround is relatively easy, I wonder if it worth the change ? Anyway, thanks for asking opinion on this and for contributions you've made on code ! Olivier. On Tue, Feb 16, 2010 at 2:10 PM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > The patch I recently attached to bug 2606<http://llvm.org/bugs/show_bug.cgi?id=2606>, > reproduced here, is my first attempt to solve this issue > as represented by the attached test cases. To solve the foreign Module > GlobalVariable problem, > I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a &gt...

On Sat, Feb 27, 2010 at 2:25 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > No problem I'll drop this from our discussion as it really is only germane to my > learning path and imagination. :-) I do at this time still have this concern of > allowing a user (developer) the right to turn this "cross module linkage" off, but > I'm still in the process of

Full_Name: John Hendrickx Version: 1.6.2 OS: Windows XP Submission from: (NULL) (80.126.78.108) (This is not a bug report but a request to add a feature to future versions of R. Hope this is an appropriate place). I'd like to suggest adding an option to ftable to allow percentages. It would be easy to do and backwards compatible. Percentage tables are useful in educational contexts, whereas

...added >> to the class JIT. This is >> implemented in JITEmitter.cpp. > > This isn't quite the right name, but I think you can eliminate it > entirely (see above). Yup > >> Beyond any issues with the patch, there is a question, in my mind, as to >> whether 2606 is really a bug. > > I suspect it is. Cool, then we are moving forward. > >> Sure its resolution makes >> using the JIT simpler for cross module behavior, but current manual >> solutions may be more fined grained in their approach in >> deciding how to treat suc...

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

[sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take

...d* forceEmitFunctionStub(Function *F) was added > to the class JIT. This is > implemented in JITEmitter.cpp. This isn't quite the right name, but I think you can eliminate it entirely (see above). > Beyond any issues with the patch, there is a question, in my mind, as to > whether 2606 is really a bug. I suspect it is. > Sure its resolution makes > using the JIT simpler for cross module behavior, but current manual > solutions may be more fined grained in their approach in > deciding how to treat such functions. If true a fix to 2606 would circumvent > such handl...