Cobra Forums

The bug preventing installation of the MonoDevelop addin on Windows XP has been fixed. If anyone encounters any more issues you can post here on the forums or on the addin's issues list on GitHub.

Also, I'm still looking for someone with a Mac to provide the information I need to try and fix this bug: https://github.com/ramon-rocha/MonoDeve ... g/issues/9

hi nerdzero,
just writing to confirm: your fix worked for me, and monodevelop now recognizes cobra.

I would also like to ask what is involved in implementing the intellisense completion addin?
maybe I could help with that? (subject to real-life circumstances obviously)

I'm on GMT+2, so emails are probably best.
(kobi2187 at gmail dot com)

Glad to hear it's working, kobi.

I am planning to release a new version of the addin either this weekend or the next with the beginnings of autocompletion and some other features I have been working on. Time is the limiting factor for me as well. Between work, my studies, hunting season, and life in general, I only get a couple of hours a week to make progress on this.

I will announce on the forums when it's ready and include a write-up of what work still needs to be done. If you cannot wait and want to start peeking at stuff, you can take a look at the 'parser' branch of the addin on GitHub. It creates the folding regions and generates an untyped AST which is to be used by the completion extension.

https://github.com/ramon-rocha/MonoDeve ... rser.cobra

You may also gain some insight by looking at the C# binding addin. It's been my primary source of information. It seems quite complex at first but is actually pretty impressive once you spend some time studying the code. Okay, once you spend A LOT of time studying the code.

C# type system parser: https://github.com/mono/monodevelop/blo ... rovider.cs

C# completion extension: https://github.com/mono/monodevelop/blo ... tension.cs

And like I said, I will also be including a more detailed explanation of the state of auto-completion in the addin and a todo list when I publish the next version.

Unrelated, but something that would be awesome is if someone added syntax highlighting for Cobra files to GitHub.

U mean color scheme for cobra files? The one from main page with blue background?

I meant so that when you click on a .cobra file in GitHub, it is recognized as a Cobra file and has proper syntax highlighting. See here: https://github.com/blog/881-linguist

hi nerdzero, any updates on the MD addin intellisense?

Yes, I will probably not finish by this weekend. I have a final exam on Wednesday and need to finish a project for another class by Thursday (the class project is much harder than I initially thought). However, I will still push the code that I have so far to GitHub on Saturday and explain where I need help. The code is pretty crappy but it will illustrate the main concepts. And hey, crappy code is easier to improve on than non-existant code, right? Yeah, yeah, I know...depends how crappy it is

Right now, there is support for completion of some keywords and I am hoping to crank out local field and method completion on Friday. I will not have <identifier><dot> completion done by this time unfortunately. I hit a pretty big stumbling block trying to make use of multiple instances of the Cobra compiler in different threads. Curse you, Node.reset!!! *shakes fist at sky*

Running the Cobra compiler in multiple threads is largely unchartered waters. There's at least a couple of shared vars which would need to be thread local. Can you live without this for the time being?

Yes, and I got bit by a shark when I went into those waters

Do we need it? I am not sure. It may have been just my module caching implementation. Remember in that email when I said it should be relatively straight forward? HA! The problem is there are gaps in my knowledge of a lot of this stuff. Here's what I tried...

The parsing service in MonoDevelop runs in a different thread than the completion extension does. You need a compiler instance to parse the code and you need access to the fully-bound AST from within the completion extension if you want to do proper completion. I guess technically you don't "need" them but I didn't feel like writing a new parser. We might need to anyways but more on that Saturday.

What I did was create a CobraModuleCache class with multiple shared dictionaries that mapped fileNames to modules. There was one dictionary for unbound modules and another for bound modules.

The parser would add an entry to the unbound module map after it parsed a file. When the cache saw a new unbound module arrive, it would determine if there were enough modules to try and run the binding phases and if so, add those bound modules (do you only need one?) to the bound map.

Meanwhile, the completion extension says "Hey, cache, give me the module for filename Foo.cobra cause the user just typed the letter 'C'" The cache would check if a bound module was available, if not, it would check to see if there were enough unbound modules to try and run the binding phases, if not it would return the unbound module, and if there was no unbound module, it would ask the parser to create one. If the parser couldn't generate one, then it tells the completion extension, "Sorry, instead of an ast you get nil".

I was locking on the dictionaries correctly, but the problem, as you pointed out, was that there are some shared vars that clobbered the different phases as they were running concurrently. Also, any time a new compiler instance is created Node.reset gets called which screws up any phases that were being run by a different compiler instance. I tried to workaround this by having both threads share the same compiler instance and "reset it manually" when necessary but this seemed to open some kind of vortex of SourceExceptions from which there was no escape.

I ended up scrapping that code and am just providing some Cobra keywords and using (or will be by Friday) unbound ASTs, aka parse trees, for local member and method completion because without type information, that's about all that can be done.

Did any of that make sense?

Seriously, the reason I ended up working out the SharpDevelop text editor component from my version of Naja was because of how complicated the wiring for everything was.

So yes -- what you said makes sense

To quote Scotty: The more they overtake the plumbing, the easier it is to stop up the drain.