Hi Joe, > (lintAll) > > output: > > (((revise> . +Date) (def datStr expDat)) > ((print> . +Date) (def datStr)) > (section (def Func) (bnd X Subview Model Func)) > (testRender (def Section NonSection Name) (bnd Names Model Tree)) > (addCell (bnd Cur RootPtr CurType)) > (update (def set!>)) > (select (def goal)) > (testParse (def Section Name) (bnd Names Model Expected Template Html)) > (_update (def put!> mis>)) > (context (def Func) (bnd Model Func)) > (parse (bnd Cur RootPtr Root)))
I think you have some unnecessary items. If I do this here $ pil picostache.l + : (more (lintAll)) (parse (bnd Cur RootPtr Root)) (addCell (bnd Cur RootPtr CurType)) (section (def Func) (bnd X Subview Model Func)) (context (def Func) (bnd Model Func)) (testRender (def Section NonSection Name) (bnd Names Model Tree)) (testParse (def Section Name) (bnd Names Model Expected Template Html)) -> NIL Your messages about the undefined date functions in 'revise>' etc. indicate that you haven't loaded "lib/misc.l", which would be done by 'pil'. > It looks like it's suggesting that I have a bunch of unbound variables. Yes, all items with 'bnd' indicate unbound variables. > Probably because I don't have my globals prefixed with * which is against > the naming convention. Yes. Or (at least in some cases like 'Root' in 'parse') you could bind it locally with 'let'. The same holds with the 'def' issues, where 'lint' believes these are undefined functions. > Is that a correct high level interpretation? I tested it by replacing Model Yes, correct. > with *Model and those warnings went away. Good :) > I think I understand the warnings on the test* functions too. Definitely a > good idea to run before publishing a library for others. thanks! True. Also for application programs or anything else. I must confess that I often forget to run 'lint' or 'lintAll' periodically. It helps to detect some nasty errors. ♪♫ - Alex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
