search for: nextfile

...er to handle the input graph directly, for we don't want to implement the details of input graph control node behavior for --{start,end}-group, -z rescan{,-now}, or whatever you define as a new linker option. Implementing it to Resolver would make it messy. 2. We would instead add a new method nextFile() to LinkingContext, which returns a new file from which Resolver should try to resolve undefined symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver calls nextFile() repeatedly to link until nextFile() returns a null value. 3. Resolver will notify Linking Context when...

Hi Nick, On 9/20/2013 5:59 PM, Nick Kledzik wrote: > On Sep 20, 2013, at 3:42 PM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> nextFile could pass the current resolver state at the time when its called, the linkingcontext can return the next file to be processed as below :- >> >> nextFile(currentResolverState) :- >> >> a) Returns the next file if the current node is not a group node >> b) Returns the n...

...te: > On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > I like this in general, but have a few questions. > > On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: > >> 2. We would instead add a new method nextFile() to LinkingContext, which returns a new file from which Resolver should try to resolve undefined symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver calls nextFile() repeatedly to link until nextFile() returns a null value. >> >> 3. Resolver will notify Lin...

Shankar, I think your proposal and mine are pretty much the same. The difference is passing back info to the InputGraph as a parameter in nextFile() vs as a separate method call. My original draft email had a parameter in nextFile(), but it seemed a little confusing because the information was referring to the previous file. That is, if the current resolver state has newDefinedAtoms, that really means the last file (returned by nextFile()...

...mail client spoilt the whole email, will create a pdf and send it. On 9/20/2013 7:00 PM, Shankar Easwaran wrote: > Hi Nick, > > On 9/20/2013 5:59 PM, Nick Kledzik wrote: >> On Sep 20, 2013, at 3:42 PM, Shankar Easwaran >> <shankare at codeaurora.org> wrote: >>> nextFile could pass the current resolver state at the time when its >>> called, the linkingcontext can return the next file to be processed >>> as below :- >>> >>> nextFile(currentResolverState) :- >>> >>> a) Returns the next file if the current node i...

...l, will create a pdf and send it. > > On 9/20/2013 7:00 PM, Shankar Easwaran wrote: >> Hi Nick, >> >> On 9/20/2013 5:59 PM, Nick Kledzik wrote: >>> On Sep 20, 2013, at 3:42 PM, Shankar Easwaran >>> <shankare at codeaurora.org> wrote: >>>> nextFile could pass the current resolver state at the time when its >>>> called, the linkingcontext can return the next file to be processed >>>> as below :- >>>> >>>> nextFile(currentResolverState) :- >>>> >>>> a) Returns the next fi...

Hi Nick, On 9/20/2013 5:29 PM, Nick Kledzik wrote: > Rui, > > I like this in general, but have a few questions. > > On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: > >> 2. We would instead add a new method nextFile() to LinkingContext, which returns a new file from which Resolver should try to resolve undefined symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver calls nextFile() repeatedly to link until nextFile() returns a null value. >> >> 3. Resolver will notify Link...

.... >> >> On 9/20/2013 7:00 PM, Shankar Easwaran wrote: >>> Hi Nick, >>> >>> On 9/20/2013 5:59 PM, Nick Kledzik wrote: >>>> On Sep 20, 2013, at 3:42 PM, Shankar Easwaran >>>> <shankare at codeaurora.org> wrote: >>>>> nextFile could pass the current resolver state at the time when >>>>> its called, the linkingcontext can return the next file to be >>>>> processed as below :- >>>>> >>>>> nextFile(currentResolverState) :- >>>>> >>>>&gt...

Rui, I like this in general, but have a few questions. On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: > 2. We would instead add a new method nextFile() to LinkingContext, which returns a new file from which Resolver should try to resolve undefined symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver calls nextFile() repeatedly to link until nextFile() returns a null value. > > 3. Resolver will notify Linking Con...

...2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> Rui, >> >> I like this in general, but have a few questions. >> >> On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: >> >> 2. We would instead add a new method nextFile() to LinkingContext, which >> returns a new file from which Resolver should try to resolve undefined >> symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver >> calls nextFile() repeatedly to link until nextFile() returns a null value. >> >> 3...

Dear list I have managed to write a short program to evaluate data which is inputted from a csv file using the following x = read.csv("wms_results.csv", header=TRUE) All works fine but since I have a number of similar data files which have different names, I would like the program to allow me to input the file name, rather than having to edit the program. >From the documentation I

...egration but fixed m and sd. I hope you can help me. 2. I am working with textfiles with rows of measure data. read.table("file") works fine. Now I want R to read.table all files within a given directory and process them one by the other. for(all files in dir xy) { x <- read.table(nextfile) process x } Is that possible with R? I hope so. Can anyone give me a link to examples. Thanks for your help Nils

On Fri, Sep 20, 2013 at 04:39:04PM -0700, Rui Ueyama wrote: > I don't want to make Resolver to have a reference to input graph. The point > of this proposal is to separate input graph handling from Resolver and > instead making Linker Context to do that task. That was the part of the original proposal I didn't agree with and I still don't do. While the resolver shouldn't

I'd do that with the nextFile abstraction like this: On the first iteration, a Group would return its member every time getNextFile() is called (the same as the current behavior). On the second and further iterations, the Group should skip all the members whose type is not Archive. By doing this, the core linker sees dynamic li...

Hi Nick, --start-group/--end-group functionality with the Gnu flavor currently works only if the --start-group/--end-group contains archive files. If they contain dynamic libraries, the undefined atoms from the dynamic libraries are processed whenever the group is iterated again. I am trying to find out a way to make the resolver add undefined atoms from the shared library only *once*, when

...o --as-needed/--no-as-needed, where in a shared library is used only if its resolving symbols(the linker may need to handle undefined symbols/external symbols from shared library in any iteration). Thanks Shankar Easwaran On 11/19/2013 1:49 PM, Rui Ueyama wrote: > I'd do that with the nextFile abstraction like this: On the first > iteration, a Group would return its member every time getNextFile() is > called (the same as the current behavior). On the second and further > iterations, the Group should skip all the members whose type is not > Archive. By doing this, the core li...

Hi, I''m trying to delete a file system (<xml_26548975.xml>) File.delete("xml_26548975.xml") But I get this error: "Permission denied - ./script/../config/../uploads/xml_26548975.xml". Why? -- Cheers, ioana k&a http://boulangerie.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Joerg, I would love to have this behavior(solaris/hp-ux linkers used to do this). cat > main.c << \! int main() { fn(); fn1(); } ! cat > fn.c << \! int fn() { return 0; } ! cat > fn1.c << \! int fn1() { return 0; } ! gcc -c -fPIC main.c fn.c fn1.c ld -shared fn1.o -o libfn1.so ld -shared fn.o -o libfn.so -L. -lfn1 ld main.o libfn.so ld: warning:

...kernelbase: Add an OpenConsoleW() replacement wrapper. kernelbase: Add IsBadStringPtr() replacement functions. kernel32: Move timezone functions to kernelbase. server: Add status code for ELOOP error. ntdll: Add status code for ELOOP error. kernel32: Move FindFirst/NextFile functions to kernelbase. kernelbase: Avoid calling some kernel32 functions. kernelbase: Redirect heap allocation functions to ntdll. kernel32: Remove heap function replacements. kernelbase: Use exception handlers instead of IsBad* functions. kernelbase: Avoid using Ope...