similar to: R File IO Slow?

Displaying 20 results from an estimated 2000 matches similar to: "R File IO Slow?"

2015 Nov 03
3
RFC: Supporting macros in LLVM debug info
> Do we really need to touch the AST? Or would it be reasonable to wire up the CGDebugInfo directly to the PPCallbacks, if it isn't already? (perhaps it is already wired up for other reasons?) This sound as a good idea, I will check that approach. PPCallbacks is only an interface, has nothing connected to it, but we will create a new class, which implement PPCallbacks, for macros. So we can
2015 Nov 05
2
RFC: Supporting macros in LLVM debug info
> Right - I was wondering if CGDebugInfo already implemented PPCallbacks or was otherwise being notified of PPCallback related things, possibly through a layer or two of indirection. I checked the approach of skipping representing macros in AST, and communicate them directly from Parser to CGDebugInfo. However, I could not find a way to initialize this communication. The only interface
2015 Nov 13
2
RFC: Supporting macros in LLVM debug info
On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> wrote: > I found a way to skip representing macros in AST and create them directly > in CGDebugInfo through PPCallbacks during preprocessing. > > To do that, I needed to extend ASTConsumer interface with this extra > method: > > > > /// If the consumer is interested in notifications from
2015 Nov 03
2
RFC: Supporting macros in LLVM debug info
> Not necessarily, if we kept the macros in order in the list of macros attached to the CU, which I imagine we would. OK, now I understand what you are aiming for. I really do not favor one on the other. But, can you explain what is the advantage of the parent approach over the children approach? If any, the children approach seems to be the one reduces the LLVM IR size, is not it? Regards,
2015 Nov 13
2
[cfe-dev] RFC: Supporting macros in LLVM debug info
On Fri, Nov 13, 2015 at 2:41 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Fri, Nov 13, 2015 at 10:21 AM, David Blaikie via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> >> wrote: >> >>> I found a way to skip representing macros in AST and create them
2015 Nov 04
2
RFC: Supporting macros in LLVM debug info
I'd like to jump in. I do not work on a preprocessor based language, but have the same code expansion problem to encode. Right now, we hack around the problem by appending some prefix after the file name and pretend it is a different file, which is not great. I understand you want to represent expansion by DIFileMacro ? I'm not how this is supposed to be used and it is not in the example.
2015 Oct 28
4
RFC: Supporting macros in LLVM debug info
Hi, I would like to implement macro debug info support in LLVM. Below you will find 4 parts: 1. Background on what does it mean to debug macros. 2. A brief explanation on how to represent macro debug info in DWARF 4.0. 3. The suggested design. 4. A full example: Source -> AST -> LLVM IR -> DWARF. Feel free to skip first two parts if you think you know the background.
2016 May 08
2
Debug info scope of explicit casting type does not seem correct
That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer
2004 Nov 09
1
email result as attachement
Hi, I??d like to know if it's possible to mail a file (image generated with R) in attachments a similar to bug.report Thanks in advance. TEMANNI Ramzi PhD Student Lim&Bio http://www.limbio-paris13.org UFR de Sant??, M??decine et Biologie Humaine (SMBH) L??onard de Vinci 74, rue Marcel Cachin 93017 Bobigny Cedex France. T??l : 01.48.38.73.07 T??l : 06.21.43.27.59 temanni.ramzi at free.fr
2016 May 07
2
Debug info scope of explicit casting type does not seem correct
Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (
2003 Apr 10
6
Transforming matrix
hi everybody, anyone knows how we can transform a binary matrix with TRUE and FALSE to 0 and 1 without looping? Thx --------------------------------- [[alternate HTML version deleted]]
2005 Mar 09
1
Support for SIP REFER message
Hi to all, I am sending a SIP REFER message to Asterisk from a VoiceXML application using the <Transfer> element to do a Transfer through Asterisk. I need to know if Asterisk supports the full features of the SIP REFER message because if i set 'bridge=true' in the <transfer> element of the VoiceXML application to supervise the call, Asterisk sends a NOTIFY message with
2002 Oct 10
2
Samba+MYOB
Hello all, We are experiencing problems using MYOB Premier V6.0.2 on Windows 2000 computers SP3, with the data file residing on shared drive on Linux (Redhat 7.2) file server running Samba Version 2.2.1a and kernel 2.4.9-34. The MYOB Tech support have told me that it is a problem with our network but could not give me any hints where the problem might be. The MYOB database has been corrupted
2011 Jul 07
2
How do I overlay two trellis plots of lme fitted lines produced by plot.augPred?
Hello, I want to use lme to fit two (or more) models, and then compare the fits on each individual. I know how to write my own code to do this (for each individual, plot the raw data, followed by lines() to plot each fitted curve) but I would like to use plot(augPred(... as it produces a nice trellis plot. I thought I could do this with par(new=T) but it does not seem to work.
2016 Apr 30
2
Debug info scope of explicit casting type does not seem correct
Hi, I am wondering if this behavior of creating debug info is correct. A type in compile unit entry is pointing to a type under subprogram entry?! This is the root cause of https://llvm.org/bugs/show_bug.cgi?id=27579 0x0000000b: DW_TAG_compile_unit [1] * 0x00000026: DW_TAG_pointer_type [2] DW_AT_type [DW_FORM_ref4] (cu + 0x002c => {0x0000002c})
2004 Aug 24
2
stem() bug?
Is the following a bug with stem() or is there something else that I am missing? I ran stem() on the vector x below and got stem(x-10) instead of stem(x). If I subtract 1 from x, I get a correct answer. If I add 1 to x, I still get a wrong answer. If I add 10 to x, I get a correct answer. I'm not sure what to make of this, other than to think it is a bug. Can anyone tell me if this is a bug?
2016 Mar 31
3
[cfe-dev] RFC: Up front type information generation in clang and llvm
Hi Mehdi, I understand the reasoning for supporting this proposal independently from CodeView support. However, I do not think that it is needed for supporting CodeView. When I say that my suggestion is more clean, I was pointing to CodeView support, assuming the changes in LLVM IR/Clang FE indicated in this proposal. Also, it is not that clear from the proposal what will be shared (generic)
2004 May 11
2
bilinear and non linear
Dear all, there are R packages able to simulate or estimate bilinear model for time series? I know it is an open problem, but do exist something for very simplified bilinear models? Alternatively, what kinfd of non linear time series models are performed in R? If R is not able, could someone suggest me for some commercial softwares to deal with bilinear models? i'm afraid of a negative
2018 Jan 12
4
application of R
Thank you very much this really helped me a lot . So actually why would people learn R(other than personal interests ) if you can't really build anything that can be sold ? I'm sorry if I'm asking bad questions > On 12 Jan 2018, at 4:43 AM, Marc Schwartz <marc_schwartz at me.com> wrote: > > > >> On Jan 11, 2018, at 2:15 PM, muhammad ramzi <mramzi43 at
2016 Mar 31
1
[cfe-dev] RFC: Up front type information generation in clang and llvm
The split between CodeView and DWARF will happen at the level of type information. So, DIVariable, DISubprogram, DILocation, DILocalScope, etc will all be shared, but records and composite types etc will not. On Thu, Mar 31, 2016 at 3:44 PM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Mehdi, > > I understand the reasoning for supporting this proposal