pkg> st fails second time around with ERROR: MethodError: no method matching Int64(::Dates.DateTime) #4017
Comments
|
Note segfault when trying similar (why not in my original report?), just opened another tab and Julia, again verbatim: |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
This doesn't happen in rc2, so I likely messed up rc3 with my Markdown change. Even if I undo that change of rc3, or try...,, it doesn't seem to take, i.e. I still get the error. I guess the Markdown precompile statements can't be undone? Precompilation is triggered when I added them, and I think should happen each time there's a change, but I'm using a stale pkgimage? Why isn't it updated if I change the source? |
|
@cdoris, are you doing something unusual in CondaPkg, with Julia's internals? You change Pkg, or the REPL mode, not sure if it's disallowed, or not guaranteed to work in later Julia versions. Note this works in my rc2 (where I've not changed Markdown). Also in rc3 works with Markdown alone (that I changed and may not have undone the right way, so can someone reproduce this error with an unchanged rc3), but not with otherwise unchanged CondaPkg: |
|
I think this is a TOML issue. Could Pkg being loaded via @topolarity given you worked on some of the TOML stuff here. |
|
yes, you can have any number of different TOML packages loaded, and unless you depend specifically upon a TOML package, you should not assume anything about it being present |
|
Ok. I've not followed the recent TOML changes in Pkg so I defer to @topolarity I think? |
|
Pkg does depend on both TOML and Dates, and makes sure to load the Dates-enabled TOML parser always. I'm a bit skeptical that we changed anything there - I think it's always been that way. We read As far as I can tell that's actually supposed to be hitting https://github.com/JuliaLang/julia/blob/1463c9991c4a75730e4d6822313180ca323241c0/stdlib/Dates/src/conversions.jl#L20 I'm not sure why it's not hitting that method - that doesn't seem related to TOML to me. |
|
My guess is that there must be two the first |
|
Oh my - so |
|
That seems terribly broken to me. How is Julia allowed to break the identity of a common dependency like that? |
|
I haven't confirmed my suspicion but that is the only way I can imagine hitting that dispatch... |
|
It is permitted, but only in certain configurations (e.g. where there is no dependencies between them, but only an assumption it will exist because of some transitive assumption of being in the other's project files) |
|
Is that defined precisely somewhere? It's not clear to me whether that would include this situation or not... |
|
@PallHaraldsson I'm having trouble reproducing this issue on my end. Can you try to come up with an MWE that works out-of-the-box with a fresh depot (i.e. using |
|
[Probably worth noting is I often do CTRL-C while precompiling packages to avoid OOM... so far always ok, or at best a segfualt and ok after a restart. I'm not sure I did CTRL-C in that case (I even think I didn't), but might have and very probably something got inconsistent in compiled code? I think CTRL-C is supported, or at least is should be... and if not I would like to know and how to then fix after such issues.] I haven't seen this again myself... And maybe CTRL-C is worse if you're deving packages? And deving further fixed things? I'm not sure I can do an MWE, I basically just added some precompiles and/or deleted stuff from PythonCall if I recall. This isn't supposed to happen, obviously, and even if I deved PythonCall to trigger this I've changed it since, but I do have some julias open where this happened, if there's anything helpful with knowing that, I could do there. The problem didn't go away there, I checked in one julia, nor did I expect that... all in RAM. I don't know about JULIA_DEPOT_PATH really, not something I've used, if you can tell me exactly what to do then maybe I can be helpful. This was just so strange to me, that I though opening an issue worthy... even if I can't do more. Though willing. |
|
@topolarity I think we want the trailing |
|
@PallHaraldsson The idea is that if you start Julia like this: $ export _JULIA_BUILTIN_DEPOT="$(dirname $(julia +1.10 -e "println(Sys.BINDIR)"))/local/share/julia:$(dirname $(julia +1.10 -e "println(Sys.BINDIR)"))/share/julia"
$ JULIA_DEPOT_PATH="./temp_depot:${_JULIA_BUILTIN_DEPOT}" julia +1.10That will force Julia to run using a "fresh" registry, compile cache, etc. in "./temp_depot" If you can show a how to create the problem (from start to finish) after starting Julia as above, that means that it isn't affected by any corrupted cache files, etc. and it should be easier for us to reproduce. After you're done, you can just |
This is a very strange bug to me, and likely has nothing to do with PythonCall, though seemingly the only thing triggering it, showing verbatim:
Yes, I'm deving the package (and Markdown its dependency, seemingly successfully, just added precompile statements there), but I didn't really change PythonCall, some very minor changes, besides they shouldn't make this happen?!
The text was updated successfully, but these errors were encountered: