Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Nick Dodson
    @SilentCicero
    Awesome! Yeah, this really shouldn't be too difficult, will take a look and potentially merge!

    I would say this, there could be a nice way to integrate non-standard abi's via the compiler settings.

    That way dType can slide in nicely with my non-standard tightPack abi.

    was thinking something like abi.dType"function...", as well you could have sig.dType""

    I could also have my abi.tight"" sig.tight"" topic.tight"" etc.

    We would specify the engine code in the compiler:

    compile(..., { plugins: [ { abi: .., sig: ..., topic: ... } ] });

    Nick Dodson
    @SilentCicero
    If I end up building that, we can re-package what you have to a plugin for Yulp, than you can support various abi encoding systems in the Yulp system.
    Loredana Cirstea
    @loredanacirstea
    We (will) have multiple abi encoding formats - we are basing dType on slots, preparing it for ewasm/wasm (32-bit, 64-bit), or 256-bit (like Solidity). All of them are tightly packed. We want dType to also encode Solidity types in version 2.
    I added the calldata function in the Remix plugin on master
    Nick Dodson
    @SilentCicero

    Okay, sounds like it fits with the encoding/decoding paradigm I'm thinking of for Yul+. This way we can have nice low-level encoding / decoding options available for devs.

    I think this notation is growing on me:

    abi.dType""
    sig.dType""
    topic.dType""

    abi.tight""
    sig.tight""
    topic.tight""

    abi""
    sig""
    topic""

    which would maybe access: plugins.dType, plugins.tight etc.
    Just a pass-through, than you can inject whatever you want / need
    Loredana Cirstea
    @loredanacirstea
    Yes, sounds good.
    Nick Dodson
    @SilentCicero
    Nice, on a real interface roll today.
    Loredana Cirstea
    @loredanacirstea
    I implemented named tuples/structs with nested components of any type on https://github.com/loredanacirstea/yulp/tree/taylor (based on dtype) - sample usage https://github.com/loredanacirstea/yulp/blob/taylor/examples/Complex.tay (still needs more tests/examples). I’m working on dtype abi encoding now. I may also look into how to decouple the code & have taylor as an extension to yul+ if I finish these experiments in time.
    Nick Dodson
    @SilentCicero
    Nice! Yeah, sounds like it all can fit nicely in a plugin
    Loredana Cirstea
    @loredanacirstea
    I pushed a first version of abi encoding methods per type - e.g. Calldata.balance.encodeTight(pos, newpos) on my branch. Now I can start on rewriting some dType contracts.
    Nick Dodson
    @SilentCicero
    Nice! Great to see this is flexible enough for these custom typing systems.
    Have you checked out cbor before? @loredanacirstea
    Was thinking it might be cool to have an implementation in Yul
    Loredana Cirstea
    @loredanacirstea
    We checked cbor, but not in detail. But we looked at flatbuffers and we may be able to define all their types with dtype. And that includes Union type (not existent in Solidity) and very important.
    Loredana Cirstea
    @loredanacirstea
    @SilentCicero , I see a mention of the Remix plugin appeared in Week in Ethereum - it would be great if you could update the online version from https://remix.fuel.sh to the last repo version on master. (I fixed the links to the 2 sample contracts, which were not included in the build & added that raw calldata function)
    Nick Dodson
    @SilentCicero
    @loredanacirstea thanks, will do!
    Nick Dodson
    @SilentCicero
    @loredanacirstea will try to do a pull / bug fix / feature add and push to remix.fuel for you
    today*
    Nick Dodson
    @SilentCicero
    @loredanacirstea you changes are added and in the latest v0.0.7 -- updating remix tonight, also added a few more nice build ins and features
    Will look at plugin system next for v8
    Nick Dodson
    @SilentCicero
    @loredanacirstea new version, pulled, I upped the yul version to v7.
    remix.fuel.sh -- is up, apologies for the long wait there.
    Loredana Cirstea
    @loredanacirstea
    I now have dType ver.2.0 (functional, recursive apply, runtime currying) & a prototype written in Yul+ (Taylor ver.1.0). And I will present it tomorrow at the Solidity Summit at 14:50 CEST (4 talks before yours, @SilentCicero). I will briefly mention Yul+ and our discussion about having support for multiple encoding formats (one of which I will present).
    Loredana Cirstea
    @loredanacirstea
    I wrote two introductory articles about two of the core concepts used to build the type interpreter engine: https://medium.com/@loredana.cirstea/from-stack-machine-to-functional-machine-step-2-currying-f26c7f8b7220, which I won't have time to explain in the actual talk.
    Nick Dodson
    @SilentCicero
    Really cool, yeah just getting ready for the presentation myself. Is there anything you need me to push re remix side?
    Loredana Cirstea
    @loredanacirstea
    No, I am using a local version of the plugin, modified with our initial extension for dtype. Success with the presentation!
    Nick Dodson
    @SilentCicero
    Sounds good, hope my presentation was okay. I didn't catch yours but I'm sure it was good! @loredanacirstea
    Let's get that plugin system going for dType
    Loredana Cirstea
    @loredanacirstea
    @SilentCicero , thank you for mentioning dType. The ENS example was cool. I was going to give you a link to my talk but I don’t see the recordings on YT at the moment. Starting Friday, we can talk about the Yul+ type plugin system.
    Loredana Cirstea
    @loredanacirstea
    The full recording is now available - my talk is only 20 min long: https://youtu.be/lhjo2FuU4v0?t=7320
    Nick Dodson
    @SilentCicero
    Nice! Will watch when I get the time
    John Adler
    @adlerjohn
    That was an inspiring talk, @loredanacirstea!
    Loredana Cirstea
    @loredanacirstea
    @adlerjohn , you are the first person to tell me this and probably the only one. I would love to know what you found inspiring.
    John Adler
    @adlerjohn
    @loredanacirstea how you described your motivations, and what those motivations were. It's clear that a significant amount of thought went into dType's architecture and that it must have been a huge amount of (uncompensated?) work. Additionally, the principle of the thing---building open-source tools that are public goods---is something exceedingly rare in this space.
    Loredana Cirstea
    @loredanacirstea
    @adlerjohn , I was more curious to know what idea(s) you found interesting from my talk, if any.
    John Adler
    @adlerjohn
    @loredanacirstea The most interesting thing from my perspective, as a compilers enthusiast rather than a dapp developer, was the part on dType (which was well-illustrated in the triangle/pyramid diagram you showed). Namely, composable types with safe operations. It looks like a more generalized version of native assets on Move, which is really promising, especially given the rather absurd difficulty currently in composing smart contracts together safely.
    Loredana Cirstea
    @loredanacirstea
    @adlerjohn , all you wrote is true to our intentions, but it is more than that and I asked the question here because it may become pertinent to FuelLabs. I am programming an on-chain interpreted language with runtime type-checking and dependent types. I already have HOFs implemented and demoed on-chain (if you saw the array-casting video). Would love to see how those will act with the optimistic rollups system (we have thought about some ideas, but they need more baking).
    Nick Dodson
    @SilentCicero

    @loredanacirstea if we had pluggable structs, what notation do you like:

    mstruct BlockHeader dType (
    ...
    )

    mstruct BlockHeader*dType (

    )

    mstruct dType BlockHeader (
    ....
    )

    mstruct as dType.mstruct

    Loredana Cirstea
    @loredanacirstea
    @SilentCicero mstruct as dType.mstruct. No preference regarding the others.
    Fyi, I have not returned to the Yul+ integration yet - I will after I finish a new dType version. But in the meantime, you might want to give a +1 for ethereum/remix-plugin#210 (Yul+ plugin would benefit). Also, the plugin could compile Yul+ directly to ewasm - I’ve been working on a JS VM: https://github.com/loredanacirstea/ewasm-jsvm for testing (already functional, helped me find some solc bugs).
    Nick Dodson
    @SilentCicero
    Nice!
    Will do
    Genysys
    @Genysys
    Hats off for the good work you guys are doing ; making my way through the code and was wondering why the same private keys are used here: https://github.com/FuelLabs/fuel-core/blob/master/nodes/sync.test.js#L119-L120
    Nick Dodson
    @SilentCicero
    @Genysys those are simply test keys, so keeping them the same allows us to better understand log data.
    Nick Dodson
    @SilentCicero
    Moved to discord.