I have reinstalled my computer and have now a new version of the sun jdk, which causes the js script to be put together in a different other, because it probably uses a different hash algorithm.
Classes are only ordered by the fantom compiler according to the sub classing decencies. It makes sure that the parent classes always comes first, but the rest is just more or less random.
I had 2 problems in the sys pod, which I fixed by shuffling some code to a different place
StrBufOutStream extends OutStream, but which was not defined yet in my case, so i put it in behind of OutStream.
Further more I encountered a problem in the fwt pod. The static initialization code depends on the other classes, some mechanism must be made to make sure this goes in a predefined and correct order. Java it self has a system to first init the statics of class before it can be used by another class.
Yuri StrotWed 10 Aug 2011
Yeah, order issue is really annoying. We already have few issues opened (for example #1478).
Ok, yeah that stuff should be initialized in the ctor to avoid those issues. I'll open a new topic for that. If you find other problems tack them on there.
jessevdam Wed 10 Aug 2011
I have reinstalled my computer and have now a new version of the sun jdk, which causes the js script to be put together in a different other, because it probably uses a different hash algorithm.
Classes are only ordered by the fantom compiler according to the sub classing decencies. It makes sure that the parent classes always comes first, but the rest is just more or less random.
I had 2 problems in the sys pod, which I fixed by shuffling some code to a different place
I shuffled the 2 following peaces of code
StrBufOutStream extends OutStream, but which was not defined yet in my case, so i put it in behind of OutStream.
Further more I encountered a problem in the fwt pod. The static initialization code depends on the other classes, some mechanism must be made to make sure this goes in a predefined and correct order. Java it self has a system to first init the statics of class before it can be used by another class.
Yuri Strot Wed 10 Aug 2011
Yeah, order issue is really annoying. We already have few issues opened (for example #1478).
There is patch we used in our team:
diff -r 7401f5f23327 src/compiler/fan/steps/Parse.fan --- a/src/compiler/fan/steps/Parse.fan Fri Jun 17 15:42:35 2011 -0400 +++ b/src/compiler/fan/steps/Parse.fan Wed Aug 10 17:34:15 2011 +0700 @@ -41,6 +41,7 @@ types := TypeDef[,] closures := ClosureExpr[,] + units.sort units.each |CompilationUnit unit| { p := Parser(compiler, unit, closures) diff -r 7401f5f23327 src/compilerJs/fan/ast/JsPod.fan --- a/src/compilerJs/fan/ast/JsPod.fan Fri Jun 17 15:42:35 2011 -0400 +++ b/src/compilerJs/fan/ast/JsPod.fan Wed Aug 10 17:34:15 2011 +0700 @@ -81,7 +81,9 @@ types.each |t| { t.writeStatic(out) } // write remaining natives - natives.each |f| + vals := natives.vals() + vals.sort() |File f1, File f2->Int| { f1.name <=> f2.name } + vals.each |f| { in := f.in out.minify(in)It's not a correct solution, but makes compilation predictable and independent from the environment. And it works for
sysandfwt!andy Wed 10 Aug 2011
As Yuri noted, we have a ticket open for sys.
I was unaware this effected other pods though. Can you describe that issue more?
jessevdam Fri 12 Aug 2011
I had to do the following thing
-fan.fwt.TextWidget.prototype.m_font = fan.fwt.Desktop.sysFont(); +fan.fwt.TextWidget.prototype.m_font = fan.gfx.Font.fromStr("13pt Lucida Grande, Tahoma, Arial");//fan.fwt.Desktop.sysFont();because fan.fwt.Desktop was not yet defined
andy Fri 12 Aug 2011
Ok, yeah that stuff should be initialized in the ctor to avoid those issues. I'll open a new topic for that. If you find other problems tack them on there.