And as a tip, start creating a new package with Pkg.generate("Modifyfield",
"MIT") (or whatever license you choose)---it will initialize a very nice
"skeleton" for you. See more at
http://docs.julialang.org/en/latest/manual/packages/#package-development
--Tim
On Tuesday, June 02, 2015 01:34:11 PM Simon Byrne wrote:
> On Tuesday, 2 June 2015 20:02:00 UTC+1, [email protected] wrote:
> > Simon,
> >
> > I have deleted my old implementation of modifyField! and have now switched
> > over to your implementation, which is really nice. Please view the latest
> > commit:
> >
> > https://github.com/StephenVavasis/Modifyfield.jl
>
> Looks good!
>
> > It is not quite working yet, and perhaps you can help. The issue is that
> > the macros @modify_field! and @modify_tuple_entry! are not being exported
> > by the package even though they are declared for export. Here is the
> > error
> > message.
> >
> > julia> include(Pkg.dir("Modifyfield") * "/test_modifyfield.jl")
> > ERROR: LoadError: UndefVarError: @modify_field! not defined
> >
> > in include at boot.jl:252
> > in include_from_node1 at loading.jl:133
> >
> > while loading
> > c:\Users\vavasis\Documents\.julia\v0.4\Modifyfield\test_modifyfiel
> > d.jl, in expression starting on line 11
> >
> > Oddly, the exporting works fine when I load the package manually (i.e.,
> > include("c:/.../Modifyfield.jl")) instead of automatically (i.e.,
> > Pkg.clone("https://github.com/StephenVavasis./Modifyfield.jl";)) . I have
> > never written a package with macros before, so perhaps I am making some
> > foolish mistake?
>
> If you move the file Modifyfield.jl into /src subdirectory, it should work
> when you type "using Modifyfield"
>
> > Beyond this, I have a few comments/questions:
> >
> > (1) Although I didn't use it, regarding your suggestion of "eltype" to
> > determine the base type of an array: Unfortunately, this does not work in
> > general because eltype in general returns the type that comes out of a
> > start/done/next loop rather than a getindex call. For example,
> > eltype(Dict{K,V}()) == (K,V)
>
> True, but the implementation of eltype is fairly simple, so you could write
> a function that does what you need.
>
> > (2) I did not understand the use of symbol in :call, symbol(x) in the code
> > that you provided. In fact, :call, x works fine because in Julia you can
> > call a type to get the constructor. Am I missing something?
>
> No, you're right: when I was writing this I couldn't get it to work, but
> the problem must have been elsewhere.
>
> > (3) I also did not understand why you put esc around argument x but not v
> > in your code snippet. Based on my (possibly incorrect) understanding of
> > esc, it seems like both x and v should be escaped, which is what I have
> > implemented. Perhaps you can clarify this.
>
> Honestly, I still don't quite understand the escaping rules: what I usually
> do is write something that seems close, then call macroexpand on a quoted
> macro call, e.g.
>
> macroexpand(:(@modify_field! y.isadded = false))
>
> > (4) Finally, building upon your ingenious code, I also added a
> > @modify_tuple_entry! macro to the package. I'd appreciate your comments
> > on
> > that as well.
> >
> > On Tuesday, June 2, 2015 at 8:16:29 AM UTC-4, Simon Byrne wrote:
> >> On 2 June 2015 at 13:00, David Gold <[email protected]> wrote:
> >> > @Simon: why safer? Rather, what is unsafe about calling symbol within
> >>
> >> the Expr constructor?
> >>
> >> I wasn't quite sure how the scoping worked (i.e. what would happen if
> >> the type had not been exported?), but it does seem to be safe.
