search for: readtable

Hi all, I have found what I think it is a bug in DFAPacketizer::ReadTable. When finding NextStateInTable to cache all transitions belonging to a state into CachedTable, ReadTable does not check bounds: unsigned ThisState = DFAStateEntryTable[state]; | unsigned NextStateInTable = DFAStateEntryTable[state+1]; which makes NextStateInTable get a random value when state ==...

...rm and fix. Is there a bug report open for this? -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation On 12/10/2012 4:48 AM, Carlos Sánchez de La Lama wrote: > Hi all, > > I have found what I think it is a bug in DFAPacketizer::ReadTable. > > When finding NextStateInTable to cache all transitions belonging to a > state into CachedTable, ReadTable does not check bounds: > > unsigned ThisState = DFAStateEntryTable[state]; | > unsigned NextStateInTable = DFAStateEntryTable[state+1]; > > which makes NextStateIn...

...during Hexagon CodeGen tests it happens silently and tests pass. I am working on another VLIW backend which uses DFAPacketizer and compiling llvm with gcc-4.4 makes it segfault, but with gcc-4.7 the bug gets hidden again (it still happens, but values after DFAStateEntryTable in memory are such that ReadTable does not break bad). If you find more info will help you track it down just let me know :) BR Carlos 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> > Hi Carlos, > > Thanks for identifying the bug. I'll confirm and fix. Is there a bug > report open for this? &...

...ests it happens silently and > tests pass. I am working on another VLIW backend which uses > DFAPacketizer and compiling llvm with gcc-4.4 makes it segfault, but > with gcc-4.7 the bug gets hidden again (it still happens, but values > after DFAStateEntryTable in memory are such that ReadTable does not > break bad). > > If you find more info will help you track it down just let me know :) > > BR > > Carlos > > > 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org > <mailto:adasgupt at codeaurora.org>> > > Hi Carlos, > >...

This commit adds a function parameter to readtable. The function is called for every column. The goal is to allow specific (non-standard) type conversions depending on the input. When the parameter is not given, or the function returns NULL, the legacy default applies. The colClasses parameter still takes precedence, i.e. the colConvertFn only appl...

...en tests it happens silently and tests > pass. I am working on another VLIW backend which uses DFAPacketizer and > compiling llvm with gcc-4.4 makes it segfault, but with gcc-4.7 the bug > gets hidden again (it still happens, but values after DFAStateEntryTable in > memory are such that ReadTable does not break bad). > > If you find more info will help you track it down just let me know :) > > BR > > Carlos > > > 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> > >> Hi Carlos, >> >> Thanks for identifying the bug. I'll...

...ens silently and tests >> pass. I am working on another VLIW backend which uses DFAPacketizer and >> compiling llvm with gcc-4.4 makes it segfault, but with gcc-4.7 the bug >> gets hidden again (it still happens, but values after DFAStateEntryTable in >> memory are such that ReadTable does not break bad). >> >> If you find more info will help you track it down just let me know :) >> >> BR >> >> Carlos >> >> >> 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> >> >>> Hi Carlos, >>> &g...

...r answers. I rather do not file a new bug, since what I coded isn't really a bug. The problem I (my colleagues) have today is very stupid: We read .csv files with a lot of columns, of which most contain date-time stamps, coded in DD/MM/YYYY HH:MM. This is not exotic, but the base library's readtable (and derivatives) only accept date-times in a limited number of possible formats (which I understand very well). We could specify a format in a rather complicated format, for each column individually, but this syntax is rather difficult to maintain. My solution to this specific problem became tri...

...what I coded isn't really a > bug. > The problem I (my colleagues) have today is very stupid: > We read .csv files with a lot of columns, of which most contain > date-time stamps, coded in DD/MM/YYYY HH:MM. > This is not exotic, but the base library's readtable (and > derivatives) > only accept date-times in a limited number of possible formats > (which I > understand very well). > We could specify a format in a rather complicated format, for each > column individually, but this syntax is rather difficult to...

You need admin assistance, someone will probably see your request here and fulfill it. It might be helpful to read this question/answer on StackOverflow discussing the context of proposing patches to base R functionality ... https://stackoverflow.com/questions/8065835/proposing-feature-requests-to-the-r-core-team cheers Ben Bolker On 2019-03-26 4:20 p.m., Kurt Van Dijck wrote: > On

Please file a bug on bugzilla so we can discuss this further. On Tue, Mar 26, 2019 at 11:53 AM Kurt Van Dijck < dev.kurt at vandijck-laurijssen.be> wrote: > Hello, > > I want to find out if this patch is ok or not, and if not, what should > change. > > Kind regards, > Kurt > > ______________________________________________ > R-devel at r-project.org mailing

On wo, 27 mrt 2019 22:55:06 -0700, Gabriel Becker wrote: > Kurt, > Cool idea and great "seeing new faces" on here proposing things on here > and engaging with R-core on here. > Some comments on the issue of fallbacks below. > On Wed, Mar 27, 2019 at 10:33 PM Kurt Van Dijck > <[1]dev.kurt at vandijck-laurijssen.be> wrote: > > Hey, >

Hey, Does someone have comments on the v4 of the proposed patch? Kind regards, Kurt

...like you can use NULL values for argument 'what' in scan()? This would help quite a bit when reading large data files where only a few columns are of interest. I've modfied read.table() to so it calls scan(what=...) also with NULLs for the fields to be skipped. Here's the diff of readtable.R (from the R-1.9.1.tgz; 9,591,217 bytes): diff readtable.new.R readtable.R 117,123d116 < # Skip NULL columns in scan() < void <- sapply(colClasses, FUN=identical, "NULL") | < sapply(colClasses, FUN=is.null) < # If all (data) columns are NULL, retur...

Hi Anshu, the "test case" I referred to requires the compilation of our whole back-end. It segdaults when using gcc-4.4.3 under Ubuntu 10.04, with other combinations I have tested it still happens (before your patch) but is not noticeable unless using gdb. I have tried making valgrind catch it but no success... so I guess the only way to *see* it is using the debugger. I remember

...ot file a new bug, since what I coded isn't really a bug. > > The problem I (my colleagues) have today is very stupid: > We read .csv files with a lot of columns, of which most contain > date-time stamps, coded in DD/MM/YYYY HH:MM. > This is not exotic, but the base library's readtable (and derivatives) > only accept date-times in a limited number of possible formats (which I > understand very well). > > We could specify a format in a rather complicated format, for each > column individually, but this syntax is rather difficult to maintain. > > My solution to...

Great! Can you please check in that test case or better still, a reduced version of that test. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation On 12/11/2012 5:47 AM, Carlos Sánchez de La Lama wrote: > Hi again, > > I can confirm r169783 fixes the problem. My testbench segfaulted in > r169782 but works after your

Kurt, Cool idea and great "seeing new faces" on here proposing things on here and engaging with R-core on here. Some comments on the issue of fallbacks below. On Wed, Mar 27, 2019 at 10:33 PM Kurt Van Dijck < dev.kurt at vandijck-laurijssen.be> wrote: > Hey, > > In the meantime, I submitted a bug. Thanks for the assistence on that. > > > and I'm not

If read.csv's colClasses= argument is NOT used then read.csv accepts double quoted numerics: 1: > read.csv(stdin()) 0: A,B 1: "1",1 2: "2",2 3: A B 1 1 1 2 2 2 However, if colClasses is used then it seems that it does not: > read.csv(stdin(), colClasses = "numeric") 0: A,B 1: "1",1 2: "2",2 3: Error in scan(file, what, nmax, sep,

....show("test.txt") x 1 0 1 > read.table("test.txt", header = TRUE) x 1 1 2 0 3 1 This result is fine. > read.table("test.txt", header = TRUE, colClasses = "character") x 1 1 2 0 3 1 This one also. However, I think that this result is wrong: > readtable("test.txt", header = TRUE, colClasses = "logical") x 1 FALSE 2 FALSE 3 FALSE I would have expected: x 1 TRUE 2 FALSE 3 TRUE Is there a way to get what I expected? Alas, I can't quite make out what read.table is doing in this context. > R.version _...