-
|
Hi folks 👋🏽 , I'm following the microblogging tutorial more or less, and I'm yet to become comfortable with Unison's way of managing functions on a DB as opposed to a file, so I may be something completely wrong, but I have a simple use case 😄 I have a v1.UserRow type and I'm trying to add However, Loading changes detected in ~/workspace/unison-playground/src/cloud/miniblog/db.u.
This case would be ignored because it's already covered by the preceding case(s):
7 | avatar : Optional URI }Ideally, I would like to avoid the Another scenario I'm having trouble with is the following: Unison gives me the following error and suggestions: Loading changes detected in ~/workspace/unison-playground/src/cloud/miniblog/db-layer.u.
❓
I couldn't resolve any of these symbols:
19 | createAppStorage : '{Exception, Cloud} AppStorage
.
33 | createPost : AppStorage -> UserHandle -> Text ->{Exception, Storage, Random, Remote} PostRow
.
45 | createUser : AppStorage -> UserHandle -> UserName -> Optional URI -> '{Exception, Storage, Random, Remote} ()
Symbol Suggestions
AppStorage com.gvolpe.miniblog.db.AppStorage
com.gvolpe.miniblog.db.v1.AppStorage
com.gvolpe.miniblog.db.v2.AppStorageShouldn't Unison just pick up the definition from the same namespace by default if I don't write the full namespace? I would appreciate any help, just getting started and love a lot of the features, but the editing experience has been challenging. |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments · 6 replies
-
|
I'm not sure what's going on with the first error. Do you get that even if that is the only thing in your file? On the second one, at the moment, a And then you should be able to refer to One other note, as a style thing, I would not put things in cc @rlmark |
Beta Was this translation helpful? Give feedback.
-
Yes, I deleted everything and type Awesome, thanks a lot for the other tips, will definitely put that to practice 🙏🏽 |
Beta Was this translation helpful? Give feedback.
-
|
Hey @gvolpe! Thank you for mentioning this. I see you linked your code example in the ticket, do you want to set your project to |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot @rlmark ! I just made it public, didn't realize it was private by default 👍🏽 |
Beta Was this translation helpful? Give feedback.
-
|
One thing that can help is to remove as much of the deep name nesting as possible, (what Paul mentioned earlier), since the Based on that project you shared, here's how you can move stuff to a less nested format with a few commands. Hopefully that way, the 0.) Optional - do this on a branch (recommended)
You'll be prompted to run it twice, since things that overwrite the root of the project are more complicated for the UCM. Then remove the extra
resolve any issues, run |
Beta Was this translation helpful? Give feedback.
-
|
@rlmark thanks a lot for digging into this, I'll give this a try later this afternoon and report back. |
Beta Was this translation helpful? Give feedback.
-
|
I managed to follow all these steps and got things sorted, thank you once again! 🙏🏽 |
Beta Was this translation helpful? Give feedback.
-
|
Oh, for your first issue, the mysterious error "This case would be ignored because it's already covered by the preceding case(s)", that is a really rough error message... apologies for that. I'll check if there's an issue already filed for it, and if not, I'll file a ticket. It looks like the UCM reports that in a record-type definition when one of the preceding field types is ambiguous. As copied, this fails for me in the same way: But if you fully prefix the versioned type names, this resolves for me (against the current main branch of your project) Our record types are on the roadmap for a big change in the future. Thank you for surfacing this. |
Beta Was this translation helpful? Give feedback.
-
|
Oh! Additionally, I see you were iterating on v2 of the Creating a type whose constructor expects a nullary type (zero type constructors) is probably the root of the issue (obfuscated by our error message). It looks like this is a minified structure of your type: I think the V4 nullary type from the UUID library is just meant as a phantom type to tag other types. |
Beta Was this translation helpful? Give feedback.
-
|
Oh thanks, this was the source of the issue then, it was driving me crazy 😄 |
Beta Was this translation helpful? Give feedback.
-
|
The issue about the confusing error message when nullary types are referenced in record types has been captured here: #5671 |
Beta Was this translation helpful? Give feedback.
One thing that can help is to remove as much of the deep name nesting as possible, (what Paul mentioned earlier), since the
namespacefile directive has some pretty finicky interactions with theeditworkflow..Based on that project you shared, here's how you can move stuff to a less nested format with a few commands. Hopefully that way, the
namespacefile directive is less needed.0.) Optional - do this on a branch (recommended)
libto the expected place near your application code - we'll remove the deep nesting next