Skip to content
Snippets Groups Projects
  1. Aug 29, 2019
  2. Jan 14, 2016
  3. Jun 26, 2014
  4. May 17, 2013
  5. Apr 12, 2013
    • Erwan Jahier's avatar
      lus2lic is now working from ldbg and ltop. · fa71e77c
      Erwan Jahier authored
      As far as ldbg is concerned, it only traces the toplevel node, at
      call event.
      
      Note that I needed to rename quite a lot of modules to avoid name clashes
      between lus2lic.a and ltop.
      
      I've also merged the Verbose module with the one of Lutin so that
      they can be shared (there were sharing 95% already).
      fa71e77c
  6. Mar 29, 2013
  7. Mar 27, 2013
    • Erwan Jahier's avatar
      Rework the type of Lic expressions w.r.t. predef expressions. · 28f47082
      Erwan Jahier authored
      1) At the Lic level, there's no reason to distinguish betwenn node
      calls, and predef node calls. Indeed it makes things simpler and more
      homogeneous afterwards.
      
      2) int strings are only converted when necessary (constant evaluation).
      
      3) const are handled directly under Lic.by_pos_op instead of being under
         PREDEF_CALL, which make things easier and more logical.
      28f47082
  8. Mar 25, 2013
  9. Feb 20, 2013
  10. Feb 06, 2013
  11. Feb 04, 2013
  12. Feb 01, 2013
  13. Jan 31, 2013
  14. Jan 18, 2013
  15. Dec 20, 2012
  16. Dec 18, 2012
  17. Dec 13, 2012
    • Erwan Jahier's avatar
      Documentation et renommage des modules. · 65dfa567
      Erwan Jahier authored
      nb: les tests ne passent toujours bien sur.
      
      * Partie lus -> AST
      
      predef.ml -> srcPredef.ml
      syntaxTreeCore.ml -> astCore.ml
      syntaxTree.ml     -> astV6.ml
      syntaxTreeDump.mli-> astV6Dump.mli
      
      * Partie Ast -> Ast
      
      solveIdent.mli -> astRecognizePredef.mli
      syntaxTab.mli -> astTab.mli
      symbolTab.mli -> astTabSymbol.mli
      
      * Partie  AST -> lic (static evaluation)
      
      eff.ml  -> lic.ml
      getEff.mli -> ast2lic.mli
      lazyCompiler.mli -> licTab.mli
      builtIn.ml -> licMetaOp.ml
      predefEval*.ml -> licEval*.ml
      name.mli -> licName.mli
      
      * Partie Lic -> Lic
      
      uniqueOutput.mli      -> l2lCheckOutputs.mli
      structArrayExpand.mli -> l2lExpandArrays.mli
      nodesExpand.mli       -> l2lExpandNodes.mli
      doNoPoly.ml           -> l2lRmPoly.ml
      doAliasTypes.ml       -> l2lAliasType.ml
      doSplit.ml            -> l2lSplit.ml
      65dfa567
  18. Dec 11, 2012
    • Erwan Jahier's avatar
      Un petit bilan des changements effectués par Pascal · dce00f59
      Erwan Jahier authored
      + remise en place du souk qu'il a mis dans le repertoire test.
      
      - il a commencé à rajouter le CondAct (tout est parti de la en fait...)
      - il a coupé le LazyCompiler en morceaux
      
      Pour cela, il a créé un nouveau module LicPrg qui définit la
      structure de données (SDD) en sortie du LazyCompiler. Ensuite, les
      diverses tranformations src2src sont faites à partir de cette SDD.
      
      - il a débranché (temporairement) l'expansion de noeud et de array/structure
      
      - il a débranché ma pseudo inférence de type et a mis à la place une
      vérification de types.
      
      - Le traitement du polymorphisme est effectué via une transfo src2src
      dans DoNoPoly (que je vais renommer en RmPoly)
      
      --------------------------------------------------------------------------
      Par ailleurs,
      
      J'ai créé un todo.org et un README.org que je vais essayer de tenir à jour.
      
      nb: les tests ne passent toujours bien sur.
      dce00f59
  19. Aug 08, 2012
  20. Aug 07, 2012
  21. Aug 06, 2012
  22. Jul 14, 2012
  23. Jul 13, 2012
    • Pascal Raymond's avatar
      Menage dans les val_exp : · 0934086d
      Pascal Raymond authored
      IDENT remplacé par VAR_REF/CONST_REF
      - plus de node_exp dans les CALL, juste une ref (node_key)
      - reste a faire pareil pour les NodeStaticArgEff
      0934086d
  24. Jul 12, 2012
  25. Jul 11, 2012
    • Pascal Raymond's avatar
      Debut de DoNoPoly, qui necessite une modif assez · 4e1418a0
      Pascal Raymond authored
      importante du mecanisme de UnifyType :
      - fait :
        * definition de Eff.poly_match
        * TypeVar type_var au lieu de Any/Overload
          avec type_var = Any | AnyNum
          (pour l'instant et pour longtemps ?!)
      - à faire :
        * revoir UnifyType pour qu'il rende un poly_match
        * stocker là où c'est nécessaire les poly_match
          calculés lors du type check
          (pour les CALL et peut-être les sargs ?)
      4e1418a0
Loading