Of course it's always just preference in the end. I also tend to annotate
all my arguments, but I think indexing is a bit of a unique case because
there are so many valid ways of doing it. Ideally you would like to
annotate it it as the union of all types that are valid for getindex but
clearly that would be more painful than just getting the rare getindex
MethodError when something strange gets passed.
The path annotation makes total sense to me though, mostly because that's
the only thing 'open' will accept as well.
On Wednesday, January 6, 2016 at 8:57:01 PM UTC-5, Ethan Anderes wrote:
>
> Yes, I usually follow that rule (avoid unnecessary type annotation in
> function definitions) and I probably should have added AbstractVector{T}
> for T<:Int, and also a method for a single Int, but I thought some
> annotation was appropriate (or at least Julian) to signal the user that the
> entries of lines has some restriction for getindex to work.
>
> How about the type annotation for path? That seems reasonable to me too,
> but maybe I’m mistaken?
>
> On Wednesday, January 6, 2016 at 3:53:09 PM UTC-8, Josh Langsfeld wrote:
>
> Just a quick note; it's quite limiting to put a type annotation of
> 'AbstractVector{Int64}' on 'lines', with nothing gained. This is a perfect
> example of a time when the programmer should just leave off the annotation
> and allow any expression that's valid for indexing to be used, including a
> single Int or an array of some custom Integer subtype.
>
> On Wednesday, January 6, 2016 at 5:03:15 PM UTC-5, Ethan Anderes wrote:
>
> Taylor: just for your reference, here is an implementation along the lines
> of what Tim suggested:
>
> function Base.include(path::AbstractString, lines::AbstractVector{Int64})
> lns = open(readlines, path)
> include_string(join(lns[lines]))
> end
>
> Now include("file.jl", 10:20) will evaluate lines 10 through 20. You can
> also do include("file.jl", [1:2;9:10]) to evaluate lines 1 through 2 and
> then 9 through 10.
>
> I’m going to put this is my .juliarc.jl :)
>
> On Tuesday, January 5, 2016 at 1:46:05 PM UTC-8, Taylor Maxwell wrote:
>
> Thanks, I will see if I can figure it out.
>
> On Tuesday, January 5, 2016 at 11:54:06 AM UTC-7, Tim Holy wrote:
>
> You should be able to write your own method
>
> include(filename, linerange)
>
> and specify 3:17 to load line numbers 3-17.
>
> Best,
> --Tim
>
> On Tuesday, January 05, 2016 09:25:40 AM Taylor Maxwell wrote:
> > Ordinarily that would work but my problem is that I need to do it from
> the
> > command line on a remote workstation (the data files cannot be moved
> from
> > that computer) and I can only have one terminal open in the vnc. I also
> > generally cannot install additional software such at atom (someone else
> has
> > to do it and it would be a giant hassle unless absolutely necessary).
> >
> > Thanks,
> > Taylor
> >
> > On Tuesday, January 5, 2016 at 10:08:47 AM UTC-7, Spencer Russell wrote:
> > > The Atom interface [1] works really well for that sort of thing. You
> can
> > > just highlight the lines you want to run and press ctrl+enter to
> execute
> > > them.
> > >
> > > -s
> > >
> > > [1]: https://github.com/JunoLab/atom-julia-client
> > >
> > >
> > > On Tue, Jan 5, 2016, at 11:54 AM, Taylor Maxwell wrote:
> > >
> > > I have looked around and haven't been able to find an answer (I am
> sure it
> > > is simple).
> > >
> > > Say I have a script.jl file with a bunch of commands that I want to
> work
> > > with interactively in the REPL but only want to do a few lines at a
> time
> > > and I am unable to copy/paste.
> > >
> > > Is there a way to load/import/include a specific set of lines of a
> > > script.jl file into the REPL without copy/paste or putting those lines
> > > into
> > > a new file?
> > >
> > > I can include("script.jl") to read in the whole file but I would like
> to
> > > do it piecemeal if possible.
> > >
> > > Thanks
>
>
>
>
>
>
>
>
>
> ...
