help understanding errors with macros until haxe restarted

[aheatedatom]

I have not created any macros myself, but am using libraries (such as spod and ufront) that use macros.

Currently testing with FlashDevelop on Windows, neko and php targets.

I am seeing behavior where functions getting defined as Macros seem to get added multiple times, again for each compilation.  I can fix this problem by closing and reopening FlashDevelop and compiling again.  I assume this clears some sort of progressive compilation cache.

Why? How?  What am I doing wrong and how do I fix it?

Thanks!

[Tom]

I have the same problem with FlashDevelop and golems. First compilation is working, but after that, just a restart can help.

Any idea how to fix it?

[Philippe Elsass]

Did you enable the Completion Server?

In this case the compiler will cache your compilations and you probably need to either disable it or find a way to remove the definitions previously generated using macros as they will be cached too. How and why is beyond my knowledge of macros.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Tom]

Hi Philippe!
Yes, the completion server is enabled, and on WinXP it is working well, every time.
But on Win7 64 bit, it compile, but the worker swf is not inculded in the main swf (it is smaller, too, that the first time) - I can run more tests, whene I will be home.

[aheatedatom]

Phillipe,

Thanks for your response!

This page describes the completion server:
http://old.haxe.org/manual/completion

And I assume flashDevelop implements this protocol. It warns about possible macro problems but points to a link that doesn't seem to actually outline the issues.

Perhaps someone who works on the haxe compiler can elaborate on the details so we can get FlashDevelop working with macros and completion? Or maybe fd just needs to close the socket on the completion server before each full compilation?

[aheatedatom]

Further research: the broken link is pointing to a haxe.org page anchor that doesn't exist,  but it's contents exists on the old.haxe.org page (shown below).  It seems to imply that these side effects could be avoided if the author of the macro implements the proper checks in the macro definitions.  Is that right?

--

Impact of Compiler Cache on Macros

Starting with Haxe 2.09, it is possible to run a compilation that will keep the modules in cache unless they have been modified or require being recompiled.

This of course affects macros as well; here's a few tips on how to deal with it :

• macros-in-macros : due to implementation difficulties, modules containing macros-in-macros are not cached and will then be recompiled everytime
• if your macro produces code based on other files that are not part of the compilation process, you can usehaxe.macro.Context.registerModuleDependency to inform the compiler that if that file is changed the corresponding module needs to be recompiled
• all modules loaded while executing a macro will add a dependency between the original module in which the macro is called and the target module
• if you are doing some class side effects such as adding metadata, make sure that it's not already applied (you might get errors such asDuplicate metadata xxx if it gets added twice)
• callbacks such as Context.onGenerate are not persistent between compilations unless they are registered again manually
• you can add a specific macro action to be made in case a given cached module is reused in later compilations by usingContext.registerModuleReuseCall : please note that the macro call is a string that can only contain constant data (it is executed in a similar way as --macro command line parameter)

Any other unexpected side effects can be reported on the Haxe google group for discussions.

[Jason O'Neil]

For completeness, I'm tracking this issue on Github:

https://github.com/ufront/ufront-orm/issues/11

I've added some unit tests and it seems the main broken functionality when using the compiler cache is that you get validation error messages multiple times. Turning off the compilation server is a valid workaround until it's fixed.

--