More semant issues
Hi,
Ted2go is having a few problems semating this project:
https://github.com/blitz-research/monkey2/files/2239254/thrust_post_collided_change6.zip
If I lock 'superthrust.monkey2' as the build file and open rockey.monkey2 I get a number of odd semant errors (ie: little yellow triangles popup in the file), but the program still builds and runs OK.
If I then edit rocket.monkey2, eg: by putting a loop around 'New SmokeParticles' like this (line 245-ish):
For Local i:=0 Until 10
New SmokeParticle (Self)
Next
I get a ton of semant errors in rocket.monkey2.
This could well be mx2cc's fault I guess but can you narrow down what's hapening?
Bye! Mark
Looking into this a bit more closely, a can't 'force' the weird errors to happen via running mx2cc directly, eg:
mx2cc geninfo -semant D:\SuperThrusting\superthrust.monkey2
Works OK without any errors.
I have also tried with a fake 'tmp' rocket.monkey2 in the '.mx2' dir without any problems.
The errors themselves are very strange too, they are internal 'should not happen' style errors. Which in this case is quite correct as they should not happen!
I still actually most suspect mx2cc, but is there some way to see what cmds ted2go is trying to execute when it auto-semants or even just every time it creates a process? Perhaps add some #If _DEBUG stuff?
Ok, I did a dump of GetFullParseCommand and found ted2go was semanting the following 3 project files:
superthrust.monkey2 (locked+open) imports/rocket.monkey2 (open) imports/imports.monkey2 (open)
Of these, only superthrust.monkey2 actually needs to be semanted.
The others are dependancies that are giving semant errors because they can't be semanted in isolation. These errors make it look like the whole 'project' has errors in it but it doesn't.
IMO you should NEVER semant non-locked files because they will often generate lots of bogus errors like this, and I still don't quite get why you want to do it. But if you really have to, it'd be nice to see these 'false' errors somehow fixed.
It's also true that mx2cc is giving some really nasty errors here too when semanting the wrong file, esp. imports.monkey2...plenty of weird internal errors that really need to be cleaned up!
Hi! In your current version of ted2go always should be OK if you open that project in ted2go.
Ok, I did a dump of GetFullParseCommand and found ted2go was semanting the following 3 project files:
superthrust.monkey2 (locked+open)
imports/rocket.monkey2 (open)
imports/imports.monkey2 (open)
Of these, only superthrust.monkey2 actually needs to be semanted.
Just pushed fix into dev - it allow us don't open project.
IMO you should NEVER semant non-locked files because they will often generate lots of bogus errors like this, and I still don't quite get why you want to do it. But if you really have to, it'd be nice to see these 'false' errors somehow fixed.
The reason to parse non-locked files is that you can open any file while working on a project.
And what to do if that file is not a part of existing .mx2proj? Just don't semant it?
I can't resolve this case. Any ideas?
You can see GetMainFileOfDocument function of /Ted2Go/PathsProvider.monkey2 to understand what file IDE try to semant.
It's also true that mx2cc is giving some really nasty errors here too when semanting the wrong file, esp. imports.monkey2...
plenty of weird internal errors that really need to be cleaned up!
In a proper way user shouldn't to see that.
Can't read your reply very well, text has no newlines.
Are you saying the errors are expected?
Ohh.. where are my \n.
Errors are expected for me only.:) If you open that project in ted2go errors will go away.
And I pushed fix into dev allowing us don't open project if there is a locked file.
So I need to make a project just to get rid of false errors, even if there's a locked build file?
Why? I still don't really get it!
On Wed, Aug 1, 2018 at 1:33 PM Evgeniy Goroshkin [email protected] wrote:
Ohh.. where are my \n.
Errors are expected for me only.:) If you open that project in ted2go errors will go away.
And I pushed fix into dev allowing us don't open project if there is a locked file.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/engor/Ted2Go/issues/153#issuecomment-409419772, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QtLa7mBaz_wXNKGg9ZTAygsrk7rZks5uMQV0gaJpZM4Vphm6 .
You were need. Latest dev version works fine w/o project. Please build it and try your scenario again. 🙂
From my answer above:
The reason to parse non-locked files is that you can open any file while working on a project.
And what to do if that file is not a part of existing .mx2proj? Just don't semant it?
I can't resolve this case. Any ideas?
You can see GetMainFileOfDocument function of /Ted2Go/PathsProvider.monkey2 to understand what file IDE try to semant.
Will do if someone catch such kind of bug.
Latest version look at folders of current file and locked file. And if current folder is the same or nested in locked - then use locked.
But if you open file that is outside of locked file folder - than ide will still semant exactly that file. I'll fix that if someone mention that.
Ok, this is a bit better. I'm not getting false errors from rocket.monkey2 if I have superthrust.monkey2 locked.
However, if I don't have superthrust.monkey2 locked, I get errors again. Ditto if I just open any old source file in src/mx2cc (which I do often) I also still get errors. Unless I 'lock' mx2cc or create a project etc I can't open an file in mx2cc dir without getting a bunch of errors.
So IMO it's not quite really solved, although I can now see this is a lot harder than I was thinking!
Here's what I was thinking of doing:
-
Keep semanting the 'main file' over and over while user is editing - this is pretty much going on already. Eventually, I'd love to see full oyutput going into a 'type tree' view, a bit like realtime reflection info.
-
For all open source files, do -parse instead of -semant so you can at least get output for the 'source' view.
The problem with this is that -parse output will sometimes overwrite -semant output as the output files will have the same name. This is similar to the problem at the start of this issue, where semant of rocket.monkey2 was overwriting semant of superthrust.monkey2
To deal with this, we could perhaps use different output file name for -semant and -parse? eg: .semant and .parse.
Then, ted2go can use full '.mx2/blah.semant' if it finds one, or just '.mx2/blah.parse' if it doesn't.
Anyway, let's just leave things as they are for now and just have a bit of a think of what other options we may have.
Does source file must contain Main() to be semanting? I'm thinking about - is it possible to mx2cc automatically detect what it can semant and what it can't - to generate .parse or .semant with the only geninfo. I like idea to have both .parse and .semant files.
No, Main() can be in any file, not necessarily the 'root' or 'build' file, eg: ted2go's Main() could be moved to MainWindow.monkey2 but you'd still use mx2cc makeapp Ted2.monkey2 to build. Ted2.monkey2 is still the root file.
is it possible to mx2cc automatically detect what it can semant and what it can't
Well, the only files you can safely semant are root files, ie: the same files you pass to mx2cc makeapp.
Attempting to semant a non-root file (ie: a file that is #imported into a build so can't be built alone) can potentially give errors and probably will, just as if you'd tried to use it with makeapp.
Worse, if you try to semant a non-root file you can end up overwriting the semant output of the 'correct' root file semant if you're not careful, as above.
IMO, you can only safely semant a root file, but you can safely parse any root or non-root file (except for the same output .geninfo filename problem which could easily be fixed).
On Thu, Aug 2, 2018 at 12:06 PM Evgeniy Goroshkin [email protected] wrote:
Does source file must contain Main() to be semanting? I'm thinking about - is it possible to mx2cc automatically detect what it can semant and what it can't - to generate .parse or .semant with the only geninfo. I like idea to have both .parse and .semant files.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/engor/Ted2Go/issues/153#issuecomment-409763762, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QpeLqBIYl-OiHLMG-7TV8zQYNeKFks5uMkJ8gaJpZM4Vphm6 .
Thinking about this a bit more, I think you're reasonably safe assuming a file with Main() in it is probably a root file. It will be for all our stuff anyway, but there's probably something somewhere that this wont apply to!
And it doesn't help with false errors in files without a Main(). This is probably what I'm most concerned about right now.
I'm also thinking about not confusing users "why I don't see locals here but see them there". As solution: for parsed (not semanted) files we can show button under Source tree or special node inside tree with text "Want to see more..." - clicking on it will open help dialog "To see more items please lock main file or set this project as active. To lock file do .... To set project do ...."
Don't remember exactly, but seems I fixed that? :)