My mistake. On Tuesday, July 29, 2014, Jameson Nash <[email protected]> wrote:
> The array printing code writes #undef when an attempt to access an element > throws an error. Fix your array indexing code and it should work. I've > written two relatively complete and self-contained AbstractArray > derivatives in Gtk.jl if you want examples on the expected API for an > AbstractArray (one for implementing GLists, one for StridedArrays) > > If you want to override the code used in the repl, I think you need to > overload display(), not show(). But either way, you need to fix your > getindex function to meet the implicit AbstractArray interface. > > On Tuesday, July 29, 2014, Stefan Karpinski <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> That may or may not be the issue here – it's unclear to me. Even with >> appropriate imports and qualifications, it is not obvious how to change the >> way custom array types are shown. >> >> >> On Tue, Jul 29, 2014 at 12:31 PM, ggggg <[email protected]> wrote: >> >>> I'll quote another ongoing thread >>> "Yes; Base is *implicitly* imported, meaning that you can *use* any >>> function in Base without having to *explicitly* import it. However, in >>> order to *extend* the function with new methods, you do need to import >>> it *explicitly* (using a statement like import Base.start, Base.next, >>> Base.done or import Base: start, next, done). Otherwise, you’ll *shadow* the >>> function in Base instead." >>> >>> So you can either import import import Base.show first, or change the >>> method definition to Base.show(args...) =... >>> >>> I'm actually not sure how it will interact with your Array type vs >>> Base.Array >>> >>> I feel like this is one of the most frequently asked questions on the >>> list. That may be a sign that could use more discoverability. >>> >> >>
