Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    soc
    @soc
    @dinfuehr do you have some time to discuss dinfuehr/dora#269 ?
    soc
    @soc
    specifically, I'm wondering what's the nicest way to hoist the condition out of the if at a pretty early stage, i. e. at the latest before the branches get typechecked
    soc
    @soc
    @dinfuehr hey, could you have a look at any of dinfuehr/dora#242, dinfuehr/dora#213, dinfuehr/dora#272 ?
    Dominik Inführ
    @dinfuehr
    hi @soc, just to keep you in the loop: the recent refactorings in Dora are necessary to split off the language-directory (the old semck directory) from the runtime. I would like to get in a state where the runtime only gets bytecode as input. Right now the VM structure still stores the AST node for classes and functions and the language front-end uses the VM structure which should be private to the runtime. So runtime and language are quite entangled. My first goal is to use SemAnalysis instead of VM in the language front-end (right now SemAnalysis in the front-end is still a type alias for VM). If I reach that goal, I would like to eventually move that language directory into a separate crate.
    soc
    @soc
    sounds good!
    @dinfuehr hey, I was just trying to figure out the problem with dinfuehr/dora#205 and looked at the generated assembly and saw that surprisingly legacy shifts instructions were used.
    I dug a bit deeper and found that flag-free shifts were removed in https://github.com/dinfuehr/dora/commit/2c568082#diff-95acd3757de6494ec975b07ccffdc9bd88bcd13845cf37b0b9895d0b71c74f9bL465.
    the commit message was "cpu: Move x64-related code into cpu/x64.rs" – was this intentional?
    soc
    @soc
    I suspect this is the reason why the code is broken: the old instructions require things in a fixed register (ecx), so code is emitted before that moves stuff into it, which in turn clobbers the value of the ecx register.
    soc
    @soc
    welp. that's exactly the reason. :-(
    Dominik Inführ
    @dinfuehr
    I think this was intentional when I moved the assembler into a separate crate. I believe this shows that we should limit the number of different configurations as much as possible: not sure what's exactly broken but most likely this would have affected a small subset of machines and we might have never found this issue.
    Dominik Inführ
    @dinfuehr
    Judging from the PR I suspect that looking at the disassembly (e.g. with --emit-asm=<fct>) or stepping through the instruction's assembly code with the debugger just once should have made this clear as well.
    Dominik Inführ
    @dinfuehr
    I don't see how having both configurations would have helped investigation here, it might have locally worked on your machine but would be broken on other machines with us having a MUCH harder time to figure out what's wrong.
    Dominik Inführ
    @dinfuehr
    I would also advise to update float_srt to invoke the assembler directly instead of the more coarse-grained macro assembler methods (like you did for arm64). IIRC macro assembler methods might clobber registers in general (see e.g. int_add for x64 which clobbers lhs). This might work for the methods you used there at this moment but that might change.
    Dominik Inführ
    @dinfuehr
    masm methods might also use the scratch registers which overlap with the registers you used in float_src. Depending on whether this registers need to be alive across masm method invocations or not, this could be problematic. In general this seems quite fragile and as I mentioned already, it would be better to use assembler methods directly.
    soc
    @soc

    hey, the code seems to be failing with

    Error:   --> dora/src/os/perf.rs:15:27
       |
    15 |     let code_start = code.ptr_start().to_usize();
       |                           ^^^^^^^^^ method not found in `&Code`
    
    error[E0599]: no method named `ptr_end` found for reference `&Code` in the current scope

    currently

    soc
    @soc
    I commented it out for now, so not a big deal, just wanted to let you know!
    Matt Hornung
    @hmatt1
    Hey! I might be interested in implementing an IntelliJ Plug-in to add language support for Dora. (Heard through Reddit this could be a fun project to work on). Also wondering, is there a website/landing page about the language?
    soc
    @soc
    hey matt, yes that was me!
    soc
    @soc
    I have some rough sketch of a homepage, but Dominik suggested not putting things out there too early.
    so the homepage is not up-to-date and only reflects my particular view of the language :-)
    dora.png
    dora-about.png
    dora-manifesto.png
    repo is https://github.com/dora-lang/website, but it's not published anywhere currently.
    Dominik Inführ
    @dinfuehr
    @soc argh, sorry... I saw the failing CI notification and wanted to fix it the next day... but then forgot... Should be fixed now.
    soc
    @soc
    Hey dominik, I found @hmatt1 on the internet mentioning that he had some interest in finding a small language to learn writing an intellij plugin.
    I invited him to look at dora and see if the language is a good fit for his interests.
    hope that's fine for you?
    Matt Hornung
    @hmatt1
    Hey Simon, I think I probably won’t start on the plug-in yet, but I might be interested in doing it when the language is released/gets a bit more traction.
    soc
    @soc
    @hmatt1 sure, no problem!
    soc
    @soc
    @dinfuehr hey, regarding your suggestion to put the initialization of modifiers from annotations into its own phase – just t be sure that I understood it correctly: this would mean moving the creation of the constructors, methods, fields etc. from classdeck, structdefck to globaldefck right?
    because the annotation needs to happen before the *defck phases, but globaldef currently does not create members, only classes/structs themselves and global functions.
    do I understand this correctly?
    soc
    @soc
    the problem I see with this is that we also only build the nested symbol table in e. g. ClassDefCheck, so that would also need to move to globaldef.
    soc
    @soc
    we could of course put the symtable into the Class but I don't know if that's really desirable
    Dominik Inführ
    @dinfuehr
    We already create the "empty" annotation (like class/function/etc.) in globaldef and then right afterwards resolve builtin annotations. Let's pick Class::is_pub as an example. Right now we set that field during globaldef, IIRC what I meant was that we always set it to false in GlobalDef and then during clsdefck iterate the annotations on the class and if we find @pub set it to true here.
    Basically would move initialization of Class::is_pub from globaldef to clsdefck.
    soc
    @soc
    ok, will try it that way then, not sure this will work with @internal though
    btw, could you have a look at the open PRs? there are few that are ready to merge or are waiting for reply since weeks.
    mhh, basically all open ones, I closed the big annotation PR.
    Dominik Inführ
    @dinfuehr
    could definitely be the case that I missed something why this wouldn't work. I don't see the problem with @internal atm, what are you thinking of?
    soc
    @soc
    I think when the internal classes are entered, it is checked that they have clazz.internal == true
    could probably move/remove this check ...
    could you have a look at dinfuehr/dora#205 and dinfuehr/dora#279 ? both should be able to be merged.
    dinfuehr/dora#213 has one question
    soc
    @soc
    dinfuehr/dora#272 's biggest point is understanding how/what works in regard to namespaces.
    soc
    @soc
    @dinfuehr what do you think about moving the checks into the various Field::new methods?
    (at least for those structs that aren't created in globaldef)
    oh, well ... looks like there isn't much that isn't created in globaldef, except maybe Field :-/
    soc
    @soc

    We already create the "empty" annotation (like class/function/etc.) in globaldef and then right afterwards resolve builtin annotations. Let's pick Class::is_pub as an example. Right now we set that field during globaldef, IIRC what I meant was that we always set it to false in GlobalDef and then during clsdefck iterate the annotations on the class and if we find @pub set it to true here.

    @dinfuehr I hit an issue with that: access checks – see dinfuehr/dora#285

    soc
    @soc
    @dinfuehr everything ok? could you have a look at the open PRs?
    Dominik Inführ
    @dinfuehr
    sorry, will do in the next few days