I believe we had issues related to serializing maps with direct dispatch choices. I don't recall why or how we found the solution, but the solution was to map it with the identity. We do the following in ChoiceCombinator.scala:
val serializableMap: Map[String, (Parser, Boolean)] = dispatchBranchKeyMap.map(identity) Might be worth a shot. On 6/25/19 2:39 PM, Sloane, Brandon wrote: > Related to below "other issues", I appear to be having an issue wit > serializing typeCalcMap now: > > > java.lang.ClassCastException: cannot assign instance of > scala.collection.immutable.HashMap$SerializationProxy to field > org.apache.daffodil.dsom.DPathCompileInfo.typeCalcMap of type > scala.collection.immutable.Map in instance of > org.apache.daffodil.dsom.DPathCompileInfo > > Any idea of what the problem might be? I tried forcing typeCalcMap to be > HashMap, which did not resolve the issue (although did change the error > slightly in the way you would expect). > > The map is of type TypeCalcMap, defined by: type TypeCalcMap = > Map[GlobalQName, TypeCalculator[AnyRef, AnyRef]] > > --Brandon > > > ________________________________ > From: Sloane, Brandon <[email protected]> > Sent: Tuesday, June 25, 2019 1:37:11 PM > To: [email protected] > Subject: Re: Missing typecalc functions > > I picked up where I left off on my previous attempt. Instead of trying to > pass the full runtime state through (which I believe runs into the issue Mike > is talking about), I am restricting what I pass through to just the > typeCalcMap. This is where I abandoned the endevour last time. > > > It appears that the remaining circular dependency is of my own making. > Compiling an expression base typeCalc requires compiling the expressions > themselves. However, the change I am attempt to make is allowing expressions > to reference the typeCalc objects. making these compiled expression objects > lazy seems to have fixed the circular dependency, but caused some other > issues that I need to work through. > > > This approach involved a fair amount of boiler plate to pass the typeCalcMap > along. It would be nice if we could instead pass the full runtime state > along, that way we will not need to re-do the boilerplate if we find another > piece of state we need to include. > > ________________________________ > From: Beckerle, Mike <[email protected]> > Sent: Tuesday, June 25, 2019 1:28:19 PM > To: [email protected] > Subject: Re: Missing typecalc functions > > I'm hard at work on the whole "backpointers" problem and this could help > decouple the runtime data objects. > > > I think there is an invariant we're not taking advantage of. Everything that > goes onto a runtime data object (both the DPathCompileInfo object, and the > RuntimeData objects) should be available without reference to that object, > for use in the schema compiler, and should be accessed that way by the schema > compiler. > > > That will eliminate the coupling of things together that generates so many of > these circularity problems, if the schema compiler decides to conveniently > get some piece of data off the runtimeData objects that creates a dependency > on every other thing that goes into that runtime data object, and these are > what trip us up often. > > ________________________________ > From: Sloane, Brandon <[email protected]> > Sent: Tuesday, June 25, 2019 12:33:42 PM > To: [email protected] > Subject: Re: Missing typecalc functions > > I think I looked into that possibility previously. > > > During the initial design phases, I was concerned about the implication for > other implementations (since, this is a pretty substantial departure from how > the rest of the type system works). > > > More recently, I discovered that we were an implementation that would > actually have difficulty dong this. > > > https://issues.apache.org/jira/browse/DAFFODIL-2148?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=16858872#comment-16858872 > > > The issue for us is that we seperate out DPathCompileInfo from the main > compileInfo in order to prevent circular dependencies. Unfortunately, looking > up a typeCalc by QName involves getting it through the corresponding > simpleType's main runtime info (and possible others, depending on how much > the lookup-table forces evaluation), which re-introduces the circular > dependency. > > > I didn't push too hard on this at the time, since it was just a > quality-of-life error reporting improvement, so I can take another stab at it > and see if I can get it to work. > > > The recent work in cleaning up the factory/instance distinction in > simpleTypes might make this problem easier then it was in my prior attempt. > > ________________________________ > From: Steve Lawrence <[email protected]> > Sent: Tuesday, June 25, 2019 12:17:08 PM > To: [email protected] > Subject: Re: Missing typecalc functions > > I've always thought it seemed odd that we had typed functions. Instead > of adding more functions, it seems like it might be worth rethinking how > the functions work. For example, instead of taking a string, maybe they > could take a QName, and the return type is going to be the type of the > primitive type of the QName. This does provide less flexibility in that > you can't have dynamic type calculators, but maybe that flexibility > isn't necessary. > > On 6/25/19 12:02 PM, Beckerle, Mike wrote: >> Where Double is needed, one often finds that Decimal is needed. >> >> >> Anywhere that base-10 rounding semantics is required one tends to need >> Decimal. >> >> >> For date/time.... >> >> >> I know of one exception example that came up in the DFDL workgroup. They had >> time expressed in units of measure not supported by the existing DFDL >> properties. E.g., we support data in binary seconds and binary milliseconds. >> Because those are both commonplace. >> >> >> But what if you have time in hundredths of a second? An actual example of >> this came up as a use case. Data from older IBM AS400 machines I think. >> >> >> If typeCalc feature could cover this I'd definitely push back on yet more >> DFDL properties to specify the time scaling factor used when converting >> binary date/times. >> >> >> That said. I have exactly and only 1 use case. Not sufficient IMHO to >> motivate adding date/time support. >> >> ________________________________ >> From: Sloane, Brandon <[email protected]> >> Sent: Tuesday, June 25, 2019 11:44:03 AM >> To: [email protected] >> Subject: Missing typecalc functions >> >> The typeCalc functions are all specialized by their return type; and >> currently support only Integer and String. It appears that there is a need >> to at least add Double to this list. (My use-case here is VMF/Link-16 where, >> for example, "degrees" is specified in units of 360/2^n making an >> Int->Double mapping natural). >> >> >> A complete solution should provide functions for all the primitive types, >> but I struggle to think of a use-case where we would need, say, date >> functions. >> >> >> Does anyone have any opinions on if we need to support types beyond string, >> integer, and double for returning from typeCalc functions? >> >> >> Brandon T. Sloane >> >> Associate, Services >> >> [email protected] | tresys.com >> > >
