Ralf Hemmecke wrote: > > On 01/11/2015 12:15 AM, Waldek Hebisch wrote: > > Ralf Hemmecke wrote: > >> > >> This script > >> > >> https://github.com/fricas/fricas/blob/master/src/scripts/unpack_file > >> > >> is obviously buggy by design. Oh, undocumented? Again wasted time. :-( > >> > >> It splits a .spad file at the )abbrev lines and completely ignores > >> global definitions. > > > > Yes, that is by design. 'unpack_file' just cuts consequtive lines > > from ')abbrev' to next ')abbrev' or end of file. In the future > > I would like to switch to compiling whole file. During transitional > > period global macros are undesirable because they may have different > > effect depending on file beeing split or not. > > 1) How long will this transitional period last?
Somebody must do the work to finish transition. Currently my priorities are on integration... > 2) I've just read about ")compile file.spad )constructor Foo". Wouldn't > it be an option. To just copy the *whole* file from foo.spad to > CONSTR1.spad, CONSTR2.spad, etc. and I do not like this copy idea. One motivation to start trasition was to limit amount of copy or near copy operations. > then have those files compiled via > > )compile CONSTR1.spad )constructor CONSTR1 > )compile CONSTR2.spad )constructor CONSTR2 > > in other words, making the "unpack_file" simply a > identical-copy-function, but change the respective (generated) > komp_all.input to include the ")constructor CONSTR1" option? > > https://github.com/fricas/fricas/blob/master/src/algebra/Makefile.in#L414 > I suspect that currently the ')constructor' option is broken, so first we would need to make sure it works. Using this option is one possibility, but that would require parsing algebra multiple times. We have 361 Spad files but more than 1000 constructors, so on average given file would be compiled 3 times or more (large files tend to contain several constructors). Parsing algebra takies something like 12 sec, parsing it 3 more times would add about 36 sec to build time. If there were no other way we would have to live with this increase in build time. But I am thinking of better approaches. One could be to option to compile all categories (skipping domains and packages) in given file plus option to compile all domains and packages (skipping categories). That would complicate makesfiles but would save on re-parsing. > Same for boot_doms.input. > > https://github.com/fricas/fricas/blob/master/src/algebra/Makefile.in#L418 > Actually, this is easier: in my private tree this stage works from source .spad files -- during this stage we want to compile everyting without distingushing between domains and categories (actually we make such distinction, but we first swallow whole algebra and later compiler examines all constructors). > Wouldn't that be an easy fix for that buggy behaviour. Or doesn't that > work for some bootstrap reason? Current behaviour is no more buggy than it was before transition. Namely, if you put macros after ')abbrev' and before constructor proper they will work for given constructor. The same happended before: macros only worked inside given part. The difference is that now parts are delimited by ')abbrev'. Currently I think that we do not have any global macros in algebra, I removed then preparing to whole file scheme. -- Waldek Hebisch [email protected] -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
