In our IDE we use compiler pod to read information about types from pods and there's a problem using compiler::FPod class. In compiler::Fpod.make we can pass null as a namespace, however compiler::FPod.read assumes that ns is not null. For now just to make things working, I made a patch like this:
I could not just add a null check, because field ns is not nullable (one more bug?), however I assume this should be fixed in another way, probably fpod introspection can be extraceted to a separate pod which allows independent usage?
KevinKelleyFri 7 May 2010
That does look like a bug -- the FPod constructor ought to fail to compile, since it may not initialize the (non-nullable) ns field.
I think ns has to be non-null, in all cases, for fantom to work. To manually load a fpod in a tool, you need to provide a custom CNamespace that knows where to look for external symbols -- by overriding resolvePod to pull in the dependent pod, probably. If you're not doing anything much with the fpod you're loading, a CNamespace that just fails on resolves by returning null, should work.
A pod can't stand alone -- at the very least it has an implied dependency on the sys pod; usually there's a transitive chain of dependencies that are required. Mainly this is important because parsing fantom source requires to know about "known types".
ivanFri 7 May 2010
The problem with providing custom namespace is that any namespace refers to compiler, which refers to compiler input. So the simple task of reading pod file requires the creation of several unnecessary objects. I disagree about dependencies - in many cases pod can be used alone (and Java classfile can stand alone too), everything depends on what we are going to do with it. In our case we just build model of all types/mixins/methods/fields in order to provide user assist in IDE
KevinKelleyFri 7 May 2010
Oh, I agree with you about setting up the compiler chain being difficult; even just to tokenize you have to set up the compiler support interdependencies. I'm just saying that the FPod class, as an abstraction that represents a compiled fantom pod, needs to know its namespace.
There probably needs to be some notion of lifecycle: load, start, stop, unload; to bring a pod from disk or the wire into the running fantom system; then a pod that hasn't been started wouldn't have resolved its external namespace references.
brianFri 7 May 2010
Ivan, I have a big backlog of things I need to tackle for you guys to get the OSGi and Eclipse stuff rolling. So lets get into this issue once I get into that since it looks to be related (hopefully starting next week).
ivan Fri 7 May 2010
In our IDE we use compiler pod to read information about types from pods and there's a problem using
compiler::FPodclass. In compiler::Fpod.make we can pass null as a namespace, howevercompiler::FPod.readassumes thatnsis not null. For now just to make things working, I made a patch like this:diff -r 2ce00341079c src/compiler/fan/fcode/FPod.fan --- a/src/compiler/fan/fcode/FPod.fan Fri Apr 30 14:42:27 2010 -0400 +++ b/src/compiler/fan/fcode/FPod.fan Fri May 07 16:46:17 2010 +0700 @@ -181,7 +181,7 @@ ftype := FType(this).readMeta(in) ftypes.add(ftype) ftypesByName[ftype.name] = ftype - ns.typeCache[ftype.qname] = ftype + try {ns.typeCache[ftype.qname] = ftype } catch(Err e) {} //TODO: make correct fix } in.closeI could not just add a null check, because field
nsis not nullable (one more bug?), however I assume this should be fixed in another way, probably fpod introspection can be extraceted to a separate pod which allows independent usage?KevinKelley Fri 7 May 2010
That does look like a bug -- the FPod constructor ought to fail to compile, since it may not initialize the (non-nullable)
nsfield.I think
nshas to be non-null, in all cases, for fantom to work. To manually load a fpod in a tool, you need to provide a custom CNamespace that knows where to look for external symbols -- by overridingresolvePodto pull in the dependent pod, probably. If you're not doing anything much with the fpod you're loading, a CNamespace that just fails on resolves by returning null, should work.A pod can't stand alone -- at the very least it has an implied dependency on the
syspod; usually there's a transitive chain of dependencies that are required. Mainly this is important because parsing fantom source requires to know about "known types".ivan Fri 7 May 2010
The problem with providing custom namespace is that any namespace refers to compiler, which refers to compiler input. So the simple task of reading pod file requires the creation of several unnecessary objects. I disagree about dependencies - in many cases pod can be used alone (and Java classfile can stand alone too), everything depends on what we are going to do with it. In our case we just build model of all types/mixins/methods/fields in order to provide user assist in IDE
KevinKelley Fri 7 May 2010
Oh, I agree with you about setting up the compiler chain being difficult; even just to tokenize you have to set up the compiler support interdependencies. I'm just saying that the
FPodclass, as an abstraction that represents a compiled fantom pod, needs to know its namespace.There probably needs to be some notion of lifecycle:
load,start,stop,unload; to bring a pod from disk or the wire into the running fantom system; then a pod that hasn't been started wouldn't have resolved its external namespace references.brian Fri 7 May 2010
Ivan, I have a big backlog of things I need to tackle for you guys to get the OSGi and Eclipse stuff rolling. So lets get into this issue once I get into that since it looks to be related (hopefully starting next week).