Juno/Atom having problems after update today

General Usage
,
1

Hi all,

I’ve just started getting the below error message when using Juno/Atom with Julia v0.5 on Ubuntu 16.04. Worked fine yesterday, I ran a Pkg.update() today and have been having this problem ever since. I’m guessing either I’ve stuffed something up on my local machine, or else an update occured in CodeTools recently that broke things. Is anyone else seeing this problem?

Cheers and thanks, -Colin

MethodError: no method matching completions(::String, ::Type{IO}; default=false)
Closest candidates are:
completions(::AbstractString) at /home/colin/.julia/v0.5/CodeTools/src/completions.jl:181 got unsupported keyword argument "default"
completions(::AbstractString, !Matched::Module; default) at /home/colin/.julia/v0.5/CodeTools/src/completions.jl:181

2

Are you on CodeTools master? Also, does this happen everytime when looking for completions or only on specific lines? It the latter, can you share those?

The latest CodeToole release that touched that code is pretty old btw, so this probably is either a bug that’s been there for quite some time or a messed up local setup.

3

Thanks for responding. Sorry for the delay - I didn’t open a computer all weekend.

I’ve tracked down the problem, and am not sure whether it qualifies as a bug or not…

I was working on a module which I was tentatively naming “IO”. So I had a file “…/IO/src/IO.jl”, and the first line of that file was module IO. If I open that file in Atom/Juno and then try to execute any basic line (using Ctrl+Enter in Atom), then I would immediately get an error message that didn’t seem to make much sense, but always contained Type{IO} in it somewhere.

The Type{IO} thing leapt out at me this morning and so I tried changing module name (and file-name) and now everything works just fine.

So I’m not really sure if this qualifies as a bug? Is “IO” some sort of protected combination of letters that shouldn’t be used by users, or is this indeed a bug? I’m happy to file an issue if its the latter, although would appreciate any indication as to which package github page to file the issue on.

Cheers and thanks,

Colin

4

IO is a built-in abstract type for streams (read more here).

5

Understood. So the rule is “don’t use it” :slight_smile:

Cheers,

Colin

6

It could cause no troubles in a stream-less environment, so the rule is “use it at own peril”. But as a “rule of thumb”, modules should have more specific names and, if someone wants to minimize future name conflicts, can even use a short prefix (e.g. ModIO).

7

Right, I’d say this is in fact a bug with Juno – when you define some module with a name that is already bound to something (the abstract type IO in your case), we’ll try to get completions for everything in that module. That works, but only when the module has been evaluated once and the binding has been overwritten, so that IO is a Module.

This case should be fixed with this though – thanks for reporting it!

8

No probs. I’ve changed the module name anyway, as it was obviously an ill-advised choice :slight_smile:

Cheers and thanks for your help.

Colin

9

As a rule I would call something like this a bug regardless of best practices – because even if the error is fundamental to what a user is doing, it’s still Juno’s job to be a bit more helpful about what’s going wrong. That doesn’t change anything in this specific situation, but just a general FYI that it’s ok to make bug reports for things that are confusing.