New discussion about dicts with mutable keys

[StephenVavasis]

Documentation includes description of proposed new function checkcorrectness, which is in a separate pull request.

[JeffBezanson]

I'd prefer to merge new code and its documentation together.

I also find the name checkcorrectness a bit too generic for this task, which is really specific to dictionaries with mutable keys. Maybe a name that suggests checking the integrity of a data structure. I could imagine that applying to other structures as well. Sort of a data structure fsck.

[StephenVavasis]

Jeff,

My knowledge of Github is limited: I don't know how to pack proposed
modifications to two different files into one pull request.

Your critique of the name is well taken, and any suggestion you have is
fine.

-- Steve

On Tue, 14 Oct 2014, Jeff Bezanson wrote:

I'd prefer to merge new code and its documentation together.

I also find the name checkcorrectness a bit too generic for this task, which is really specific to
dictionaries with mutable keys. Maybe a name that suggests checking the integrity of a data
structure. I could imagine that applying to other structures as well. Sort of a data structure
fsck.

—
Reply to this email directly or view it onGitHub.[7881863__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyODk2NTA4NCwiZGF0YSI6eyJpZCI6N
DU4MjExMjV9fQ==--9857172feae191f873a81b587927dced4b84f072.gif]

[StefanKarpinski]

Sort of a data structure fsck.

Great minds or something: #8687 (comment).

[tkelman]

@StephenVavasis judging by the branch names it looks like you're using the Github web interface to make these proposed modifications?

What you can do is go to your fork at https://github.com/StephenVavasis/julia, then navigate to the branch corresponding to a given pull request (patch-10 here for example), and make additional modifications to other files. The additional commits will show up in the same pull request.

Through the web interface you're limited to changing one file per commit, and you can't do more complicated git operations like rebasing, but those aren't always necessary.

[nalimilan]

But fs in fsck is supposed to mean file system. So maybe just checkstructure?

[StefanKarpinski]

I think that fsck has transcended file system in hacker nomenclature, but maybe that's just me.

[StefanKarpinski]

Indeed, urbandictionary does include this definition:

Sometimes used as general slang for to check/repair something.

Git also uses "fsck" as the term for checking it's object database, which is like a file system but not.

[nalimilan]

True. But I guess non-Unix users would be less familiar with this terminology (not that I really care :-).

[StefanKarpinski]

How about we call it repair! then? Nice and explicit.

[nalimilan]

Fine by me!

[StephenVavasis]

Tony, thanks-- I do need to understand git better for my SortedDict
project, and I am currently reading up on it.

Meanwhile, with regard to the 'checkcorrectness' function or whatever it
ends up being called, I suppose there should be test cases for it in some
set of regression tests, but I don't know how to do this either. (I can
write the tests, but I don't know where to upload them on git.)

In addition, I was not able to test checkcorrectness 'in situ'. When I
put the new checkcorrectness function in my copy of dict.jl (in
c:\Users\vavasis\AppData\Local\Julia-0.4.0-dev\share\julia\base), I did
not seem to have access to it (invoked as Base.checkcorrectness) the next
time I started Julia. Is dict.jl somehow precompiled and preloaded in
binary form when Julia starts? Do I have to build Julia from source in
order to test this function in situ?

Thanks,
Steve

On Tue, 14 Oct 2014, Tony Kelman wrote:

@StephenVavasis judging by the branch names it looks like you're using the Github web interface to make these proposed
modifications?

What you can do is go to your fork at https://github.com/StephenVavasis/julia, then navigate to the branch
corresponding to a given pull request (patch-10 here for example), and make additional modifications to other files.
The additional commits will show up in the same pull request.

Through the web interface you're limited to changing one file per commit, and you can't do more complicated git
operations like rebasing, but those aren't always necessary.

—
Reply to this email directly or view it onGitHub.[7881863__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyODk3MDQwMywiZGF0YSI6eyJpZCI6NDU4MjExMjV9fQ==--91
dc37c2a321b4504ba2625a62b9ca463359b5ad.gif]

[nalimilan]

Base is precompiled in $(libdir)/julia/sys.so. Just (re)move this file, and the modified files will be used.

[tkelman]

The contents of base do get precompiled into the system image at lib/julia/sys.ji, and for faster startup into a shared library lib/julia/sys.{so,dylib,dll} (the dll does not currently get installed in Windows binaries, it causes trouble with backtraces with our current version of LLVM). While it's easiest to recompile the system image from a source build, having a source build is not absolutely required. On Windows you can rebuild the system image from a binary installation by renaming or moving lib/julia/sys.ji, then running bin/prepare-julia-env.bat.

The tests are located in test/*.jl on Github, which gets installed to share/julia/test/*.jl in a binary installation. There is a test/collections.jl where there are some existing tests related to Dicts, you could add more there. To run the collections test in a binary installation you can call Base.runtests("collections").

[quinnj]

Was there another PR then that also included some code changes? I don't see it linked here at all.

[quinnj]

Ah, found it: #8687. Closing this in favor of having all changes/discussion on that PR.