Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    Teal has hit 700 stars on Github! 🌟
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    Let's schedule the March meetup for next week? I'd like to try announcing a date a week in advance this time!
    nico-ec
    @nico-ec
    @pdesaulniers:matrix.org Sorry late answer.. but how do you preload a module?
    Also ye someone else also told me that . are more used in lua. My lua is really rusty, excuse the horrible code ahah
    / is used in the language I usually use
    Also, is there a way to require the ffi module from luaJIT? The compiler is not happy about me trying to import it
    Hisham Muhammad
    @hishamhm
    you can preload modules using tlconfig.lua — see https://github.com/teal-language/tl/blob/master/docs/compiler_options.md for more details!
    as for ffi, for now you can treat it like any other module: you'll need a .d.tl definitions file for it; however, ffi does a lot of dynamic magic (new Lua functions simply appear in the ffi.C namespace), so you would probably have to do a lot of casting
    Most likely, it makes more sense to make a module with FFI bindings as an untyped foo.lua module and expose their types with a foo.d.tl file, which you then require as require("foo") from the rest of your application. foo.d.tl will be used by Teal to check the types of your application, and foo.lua will be used by LuaJIT to run it.
    nico-ec
    @nico-ec
    Okay I see, thanks a lot for the explanation! :>
    does preloading modules make them available for the whole project without having to specifically require in sub-modules?
    Hisham Muhammad
    @hishamhm
    @nico-ec yes and no. preload_modules is to be used to preload into the compiler type definitons for modules where are already preloaded into the Lua VM (such as the love global in Love2d applications). it is NOT a replacement for require, because it only affects compile-time checking, and not the execution.
    I guess we need to be add this warning in the documentation!
    (I'm just checking the documentation and it says "execute the equivalent to require("module"), which turns out to be misleading. I'm changing it!)
    Hisham Muhammad
    @hishamhm
    just pushed a new feature to master: now the compiler checks for redeclared keys in table literals, and produces an error. I was bitten by a bug like this earlier today, now the compiler will keep an eye for it, it won't happen again!
    Hisham Muhammad
    @hishamhm
    If you're on Twitter, quick poll about next week's meetup → https://twitter.com/hisham_hm/status/1367241858334806016
    Hisham Muhammad
    @hishamhm
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    euclidianace: is Cyan already at feature parity with tl? In particular, does it include support for build.tl? (someone asked me for that kind of functionality yesterday! couldn't find in a quick grep but I didn't scan the code thoroughly)
    euclidianace
    @euclidianace:matrix.org
    [m]
    hisham_hm its at parity except for the build.tl sadly, just need to figure out a clean way to only run it when needed
    But I've been wanting the feature myself recently so I need to get on that
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    I ask because I've been doing some cleanups in the tl.tl API (see the wip here: teal-language/tl@a56be54 — feedback welcome) and since that will require some refactoring in the tl script, I've been wondering if we could have cyan take over the build command and remove it from tl, but for that it would be best to have full feature parity first
    euclidianace
    @euclidianace:matrix.org
    [m]
    Yeah, I assumed that was the plan, something like next release deprecate/warn on tl build and make a cyan 0.1 release, next release remove it?
    speaking of releases, ive been playing around with using cyan's ability to build a dependency graph for a possible bundling tool (sort of in the vein of LuaPak) that could be used in a github action for packaging up releases of cyan https://github.com/euclidianAce/cyan-bundler
    (though it may just be easier to use LuaPak directly, i think its a neat showcase of the api 😄)
    hisham_hm
    @hisham_hm:matrix.org
    [m]

    Yeah, I assumed that was the plan, something like next release deprecate/warn on tl build and make a cyan 0.1 release, next release remove it?

    sounds like a plan! I don't think it would be too much more work to get the tl in that commit I linked above to work correctly, so I can keep tl build around for another release I guess. please take a look at the tl.tl API changes and let me know if anything there would make your life more difficult

    the biggest practical change (as of right now) is having to traverse the results inside the env to get all errors in required modules. which may or may not be a problem for you because each result also lists its dependencies?
    euclidianace
    @euclidianace:matrix.org
    [m]
    thats probably not a big issue, but id have to pull the code down to make sure. Overall from a quick glance these seem like nice improvements that i should just need some small tweaks to use
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    cool! I'll try to get that commit done into a PR tomorrow. it's pretty late here, I'm signing off for today! o/
    euclidianace
    @euclidianace:matrix.org
    [m]
    gn! o/
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    opened the PR with the tl.tl API changes + tl refactors needed to prepare the deprecation of tl build and the use of the new API - teal-language/tl#414
    michal
    @michal:kottman.xyz
    [m]
    I missed the original discussions, what's the TL;DR motivation for a separate build system? I enjoyed the self-contained nature of tl.tl
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    the core compiler continues self-contained, and even more so with the split, since that means the tl CLI won't even need to depend on lfs. the motivation is to split off the more complex part of tl (the tl build command) into a separate project
    if you use tl check, tl gen, tl run, nothing changes
    if you use tl build, then cyan build will be able to do everything that tl build does and more!
    Open Skies
    @aiverson
    I'm trying to use teal to develop some VR stuff in lovr. Like love2d, it injects a global table into the lua state containing its API and event handlers. I made a types/ subdirectory of my project, wrote a lovr.d.tl file into it, and modified tlconfig.lua to tell the compiler to preload the lovr module and that types/ should be included. tl check reports no errors in types/lovr.d.tl, but complains about an unknown variable lovr in main.tl. I don't see any mention of how to do this in the documentation, so I've been experimenting and haven't yet had success. Does anyone know what the correct way to set this up is?
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    @aiverson: welcome! does lovr.d.tl declare a global type lovr = record ... end variable? (edit: fixed for typo, missed type there!)
    Open Skies
    @aiverson
    So far I have tried making a local record that gets returned, a global record, global type = record...
    And while trying your initial typod syntax, I noticed that vscode somehow moved the files into the wrong folders, after fixing that it now works. And apparently trying to undo a change within a file will undo moving the file unexpectedly. Thanks!
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    a local record type that gets returned is typically what you'll want to do in a declaration file for a module that is used by being required
    zash
    @_xmpp_zash=40zash.se:matrix.org
    [m]
    Hey! Is this something I should expect to work or am I missing something?
    local record foo
      record bar
      end
      { bar } -- unknown type bar
    end
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    it should have! I think it's a bug where nested records are not being processed in arrayrecords. Can you try to change string to record in tl.tl:8749 and let us know if it fixes the issue?
    zash
    @_xmpp_zash=40zash.se:matrix.org
    [m]
    Yes, it does.
    tl$ ./tl check records-in-records.tl
    ========================================
    Type checked records-in-records.tl
    0 errors detected -- [snip]
    tl$ git stash
    Saved working directory and index state WIP on master: 182b6b5 catch redeclared keys in table literals
    tl$ ./tl check records-in-records.tl
    ========================================
    1 error:
    records-in-records.tl:4:4: unknown type bar
    zash
    @_xmpp_zash=40zash.se:matrix.org
    [m]
    Want an issue opened?
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    yes please! a PR would be even better 😄
    zash
    @_xmpp_zash=40zash.se:matrix.org
    [m]
    Perhaps, tho I'm not entirely sure what it was that I changed.
    Where should tests go? I'm sure I found a place when looking for if this was something covered by tests already, but it seems I've lost the tab.
    hisham_hm
    @hisham_hm:matrix.org
    [m]
    you can find a similar example in spec/declaration and add a util.check there that just runs the example you posted here
    I'm on the phone right now, but I think you can grep for "nested" or the like
    the change is that the arrayrecord type was using the same general visit_type callback as string, but it needs to use the one from record, because it needs to make nested records visible
    when traversing type declarations
    zash
    @_xmpp_zash=40zash.se:matrix.org
    [m]
    Found, thanks, I'll PR something in a bit.