I was told false would at least allow a typeof() check for failure. I get the feeling there's too many layers of indirection here, in terms of work being requested. I'm happy to write the code, but I should probably get in direct touch with the people requesting it.
On Fri, Sep 4, 2009 at 5:57 PM, Christian Plesner Hansen < [email protected]> wrote: > Why false, do any of the other implementations do that? > > On Fri, Sep 4, 2009 at 2:36 AM, Abdulla Kamar<[email protected]> > wrote: > > I've modified readline() to return false on failure and to not strip new > > lines. I'll create another patch to modify the behaviour of write/print > so > > null bytes are properly processed. > > > > Christian, this should be good to go. > > > > On Thu, Sep 3, 2009 at 2:51 PM, Matthew Wilson <[email protected]> > wrote: > >> > >> Maybe return boolean:false...? so the coder can do a typeof() check if > >> they really want... > >> or... allow an optional argument to readline() that specifies its > >> behavior.... > >> or... add a readline_something() builtin that doesn't strip the > >> newlines.... esp. for files that have more than one type of newline > char. > >> But regarding the language shootout, I'm more annoyed that print() > >> truncates its output on "\0" (aka "\u0000")... so the mandelbrot.v8 will > >> never ever succeed (since it needs to output NULs to stdout to emit the > >> bitmap). And yes, the ES3 spec does allow NULs in string literals... > I'm > >> gunning for a printRaw() builtin for that one. > >> -Matthew > >> On Wed, Sep 2, 2009 at 11:41 PM, Abdulla Kamar <[email protected] > > > >> wrote: > >>> > >>> What would you suggest the correct behaviour should be? > >>> > >>> On Thu, Sep 3, 2009 at 2:37 PM, Matthew Wilson <[email protected]> > >>> wrote: > >>>> > >>>> I should've specified: I agree with you; yes, throwing on EOF is > >>>> incorrect... but returning an empty string is also incorrect (since > it's > >>>> also stripping the newlines). If it weren't stripping the newlines, > >>>> returning an empty string would be okay... > >>>> > >>>> On Wed, Sep 2, 2009 at 11:36 PM, Abdulla Kamar < > [email protected]> > >>>> wrote: > >>>>> > >>>>> I'd still argue that throwing on EOF is incorrect behaviour. > >>>>> > >>>>> On Thu, Sep 3, 2009 at 2:24 PM, Matthew Wilson <[email protected]> > >>>>> wrote: > >>>>>> > >>>>>> You'd think that, but > >>>>>> try{ do{ i += readline()+"\n" }while(true) }catch(e){}; > >>>>>> is a few % slower every time for me (2,500,000 line input to stdin) > >>>>>> than > >>>>>> do{ try{ i += readline() + "\n" }catch(e){ break }}while(true) > >>>>>> > >>>>>> On Wed, Sep 2, 2009 at 10:53 PM, Abdulla Kamar > >>>>>> <[email protected]> wrote: > >>>>>>> > >>>>>>> Well in terms of semantics, it's not the correct thing to do (throw > >>>>>>> when reaching the end of file). Other than that, Isaac was saying > that it's > >>>>>>> incorrect for the benchmarks - and I would add that it could also > cause the > >>>>>>> benchmarks to show incorrect timings due to exception handling > overhead. > >>>>>>> > >>>>>>> On Thu, Sep 3, 2009 at 1:46 PM, <[email protected]> wrote: > >>>>>>>> > >>>>>>>> I disagree.. how is it holding it up? What's wrong with wrapping > >>>>>>>> readline() in try/catch, as I did in > >>>>>>>> > >>>>>>>> > http://shootout.alioth.debian.org/u32/benchmark.php?test=regexdna&lang=all > >>>>>>>> > >>>>>>>> (where, incidentally, JavaScript V8 beats all other > implementations) > >>>>>>>> > >>>>>>>> http://codereview.chromium.org/173262 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Thank you > >>>>>>> Abdulla > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Thank you > >>>>> Abdulla > >>>> > >>> > >>> > >>> > >>> -- > >>> Thank you > >>> Abdulla > >> > > > > > > > > -- > > Thank you > > Abdulla > > > -- Thank you Abdulla --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
