Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the code generator emit proper line numbers and positions from .vugu files #38

Open
bradleypeabody opened this issue Apr 7, 2019 · 10 comments

Comments

@bradleypeabody
Copy link
Contributor

Looks like the Go compiler supports line directives, allowing us to explicitly indicate an alternate file name and line number of where to look for an error. The code generator should be changed to use the htmlx package now available after #9 to extract and report these line numbers. When #17 is being done, we should make sure you can click on an error in the console and it opens to the correct .vugu file line and col.

Also might be useful: https://dave.cheney.net/2018/01/08/gos-hidden-pragmas

@bradleypeabody bradleypeabody added this to In progress in Old Vugu Dev Apr 7, 2019
@bradleypeabody
Copy link
Contributor Author

@erinpentecost I'm going to try adding in parse.go and the related files so that Parse() works in htmlx. Wish me luck! :) (And let me know if you have any feedback or comments on this.)

@erinpentecost
Copy link
Contributor

I split out some of the requirements into other files, so you'll probably spot some duplicates if you add in everything I removed. I'm slowly working on an io.Reader wrapper that should let us use the normal module.

@bradleypeabody
Copy link
Contributor Author

Okay awesome, thanks for the info!

@erinpentecost
Copy link
Contributor

erinpentecost commented Jul 28, 2019

Ok, I finally finished a writer/reader middleware that can convert between byte offsets and lines/columns. Columns won't be accurate if you use runes that encode to more than one byte. Here's the thing: byteline

I'm working on an edit to vugufmt that uses it. Hopefully it works out.

@bradleypeabody
Copy link
Contributor Author

Awesome! Yeah looks like that could work well. I guess golang/go#31312 never got any further response, bummer.

I'm using your fork of x/net/html for line numbers in some new code I'm writing. If this byteline thing ends up working well, I could switch over to doing that instead.

@bradleypeabody
Copy link
Contributor Author

Note to self on this:

code generator emit proper line numbers

I actually tried this and it was a disaster for this use case. Trouble is generated Go code has lots of code generated stuff in it that doesn't correspond directly to anything in the vugu file (and it's not uncommon for the error to be at this part). And the //line directive does not provide a way "unset" the line back to the original value.

Possibly just the <script> part could be done - if it's place at the bottom of the output .go file and has a line directive, that could, should be tried.

@bradleypeabody bradleypeabody moved this from In progress to To do in Old Vugu Dev Sep 16, 2019
@morpheus747
Copy link

Maybe the best solution is the easy one and just remove the code from inside html and put in a file with a name.
index.html
index_code.go

mymodule.html
mymodule_code.go

So when compiled the errors are in place.

@bradleypeabody
Copy link
Contributor Author

@morpheus747 You can achieve something close to this right now by having myfile.vugu and myfile.go right along side each other. The component struct definition and methods, etc. can be in myfile.go and that works well and handles most of the issue. However you still end up with things like vg-if attributes that can have expressions in myfile.vugu. So far my only idea of how to provide line numbers for that case is in a regular comment in the generated code. So if vg-if="x" appeared in myfile.vugu on line 100, the generated code could be:

// myfile.vugu:100
if x {

That would probably be better than nothing.

@morpheus747
Copy link

two thinks came to mi mind.
1st i don't see that myfile.vugu and myfile.go in the documentation, maybe is a good idea to add that more clearly, i can do that.
2nd if i understand the problem correctly, the vg-if inside the .vugu files are "extracted" converted to "gocode" and inyected in one file. after that, the file is compiled?
In that case maybe a good "start point" is to just leave the temporal pre-assembled file somewhere so you can see it.

Let me understad this more by checking the code so i can add to this problem, because i face this. And can't found the error in the code and was so frustrating.

Can you give me some orientation about where is the code generator or where start to read the code ?

@bradleypeabody
Copy link
Contributor Author

The generated code (from running vugugen or using tooling that calls it) goes into a file that ends with _vgen.go. Depending on the options used, this can be in a file with the same prefix as the input e.g. myfile.vugu -> myfile_vgen.go or it can be combined into 0_components_vgen.go.

You should be able to see the emitted if statement(s) that correspond to vg-if and so on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Old Vugu Dev
  
To do
Development

No branches or pull requests

3 participants