Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 13 12:06
    agroce commented #448
  • Jun 13 11:37
    agroce opened #451
  • Jun 13 02:02
    mjobuda commented #439
  • Jun 12 23:34
    agroce commented #448
  • Jun 12 22:40
    cburgdorf synchronize #445
  • Jun 12 22:38

    cburgdorf on master

    Fix issue with system dependenc… (compare)

  • Jun 12 22:38
    cburgdorf closed #446
  • Jun 12 22:38
    codecov-commenter commented #446
  • Jun 12 22:33
    cburgdorf ready_for_review #446
  • Jun 12 22:33
    cburgdorf commented #446
  • Jun 12 22:32
    cburgdorf edited #446
  • Jun 12 22:32
    cburgdorf edited #446
  • Jun 12 22:31
    codecov-commenter commented #446
  • Jun 12 22:08
    cburgdorf synchronize #446
  • Jun 12 22:03
    cburgdorf synchronize #446
  • Jun 12 21:50
    codecov-commenter commented #446
  • Jun 12 21:46
    codecov-commenter commented #446
  • Jun 12 21:42
    cburgdorf synchronize #446
  • Jun 12 21:38
    cburgdorf synchronize #446
  • Jun 12 21:33
    codecov-commenter commented #446
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> just flipped thru it. lots of relevant stuff
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> We have first site up at: http://fe.ethereum.org/
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> Blogged: Fe Development Update No 1 https://snakecharmers.ethereum.org/fe-development-update-1/
chriseth
@chriseth
Congratulations on your first update! Does fe currently use Yul as the main target or does it also have its own assembler?
Grant Wuerker
@g-r-a-n-t
Thanks @chriseth . We only target Yul and are planning to keep it this way
chriseth
@chriseth
do you have any feedback already? any missing features?
we are planning to add some kind of memory management. This will mean that every opcode that accesses memory will need another parameter that is an opaque handle for an allocated object in memory. If the whole code follows that pattern, these objects can be moved around and allows more opportunities for optimization including moving stack elements to memory
We'll hopefully start implementing that in solidity soon, so we know how it will be working
it will be something like let x := allocate(length) mstore(x, 1, 5)
so in this mechanism, memory offsets will not be relative to the absolute zero but relative to the start of the memory object
the mechanism can be translated into regular evm by implemeting functions like function allocate(len) -> ptr { ptr := mload(0x40) mstore(0x40, add(ptr, length)) } function mstore(obj, offset, value) { mstore(add(obj, offset), value) } - optionally mstore can of course also do bounds checks
Grant Wuerker
@g-r-a-n-t
So far things have worked very well. Off the top of my head, I cant think of any feedback to give. But if we find something that could be improved, we’ll be sure to write an issue in Solidity.
It would definitely be nice have some memory management included in Yul. We’ve been writing lots of boilerplate code for this sort of thing.
chriseth
@chriseth
great, thanks!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> Thanks for stopping by @chriseth ! I don't have much feedback on YUL itself. I'm still a YUL noob but my interactions with the language so far were fruitful and I'm happy to see how fast we can make progress which I would also attribute to the fact that YUL is already quite expressive for an intermediate language that sits directly above the raw EVM opcodes. One thing that would be nice is to have a standalone YUL library. Currently we are invoking the solidity compiler directly which also means we are building the whole solidity compiler in our build pipeline. Would be nice to have a shortcut since we only depend on YUL.

Also, I'd be curious about your plans to default to YUL in the standard solidity processing pipeline. Do you have an estimate for when that might be achieved (I assume that is the end goal). And when that happens, are you planning to have audits for the YUL compiler? For us it is convenient that Fe and Solidity will eventually converge on YUL which also means there's a whole category of security concerns that Fe and Solidity will share simply by sharing the same IL. At the same time it means that we have a dependency against your roadmap and timeline. So, I'm just curious if you have something to share for us on that front 🙂

chriseth
@chriseth
building the solidity compiler: Have you considered using one of the pre-built binaries from https://binaries.soliditylang.org ? We support windows, macos, linux and wasm / emscripten
A standalone binary is also something we are considering, but not in the near future
We are already pretty far with compiling via yul. The latest compiler provides access to that from the commandline --experimental-via-ir
We will probably have an audit at some point, but there is no date set yet.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> Cool. Sounds good! Regarding the pre-built binaries: Yep, we considered it and should probably revisit. It's not a super high priority right now as we aren't distributing the compiler yet. I'm sure Q1 2021 we will have some sort of (premature) release though.
chriseth
@chriseth
are you planning to link against the compiler?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> I think we haven't yet formed a definitive stance on that. We are currently using https://github.com/axic/solc-rust (or better a fork of that) and I think our favourite solution would be to have similar rust bindings but to libyul directly.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> New dev update: https://snakecharmers.ethereum.org/fe-development-update-2/
indolering
@indolering:matrix.org
[m]
Is there discussion anywhere about why K Framework wasn't chosen for the primary implementation?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Grant Wuerker (g-r-a-n-t)> Hello @indolering:matrix.org . It's briefly mentioned on our github page:

A secondary goal to providing a specification document could be to also provide an executable specification via tools such as the K framework. Providing such an executable specification may become a primary goal if it can be achieved without too much effort and without hampering the achievement of other goals.

It's something that I need to look into more.

indolering
@indolering:matrix.org
[m]
Ahh, so it's not that you have tried to use the K Framework before and found it lacking.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> Not at all
indolering
@indolering:matrix.org
[m]
I guess I'm just surprised that you didn't take a formal-verification first approach, given the issues encountered in Solidity and Vyper development.
indolering
@indolering:matrix.org
[m]
... and given the many claims the K Framework makes about getting an efficient runtime and other infrastructure (like a debugger) "for free".
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Grant Wuerker (g-r-a-n-t)> You might be interested in checking out https://github.com/formalize/coq-vyper. It's similar to compcert c and implements a simplified version of Fe (formerly rust-vyper).

With the rust implementation, we're just focusing on getting basic language features working for now, but I'll start digging into the K framework since you've brought it up.

indolering
@indolering:matrix.org
[m]
I'd love a blogpost on how that goes!
wolflo
@wolflo
Hi! Exciting to see another smart contract language emerging. I wanted to say hello and potentially open up a line of communication between the Fe team and ConsenSys Diligence. If there's interest in that, could you let me know the best way to get in touch?
Grant Wuerker
@g-r-a-n-t
Hi @wolflo, thanks for reaching out. I think that would be great. Let me send you my email.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Piper Merriam> Fe binaries work on my machine. Linux, Ubuntu variant, PopOs
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> We just released Fe 0.2.0-apha https://github.com/ethereum/fe/releases/tag/v0.2.0-alpha
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> We've written another update on our development progress: https://snakecharmers.ethereum.org/fe-development-update-4/
Yoshitomo Nakanishi
@Y-Nak
HI! I'm a Rustacean and a compiler enthusiast.
I'm really excited to find this project. I'd like to contribute to fe.
Especially, I'm interested in wasm and gas-estimation.
But please assign any task to me, I'm glad to work on it.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> Hey @Y-Nak thanks for the contributions. We are super happy to have you join the effort to bring Fe to life! If you are interested in wasm it would be really cool if you could help us get a wasm-version of the compiler. I took a stab a few weeks back but was running into problems with the solidity backend. https://github.com/ethereum/fe/issues/70#issuecomment-724796985

I didn't follow up on it. But I know that solidity has a wasm build so it should be possible to bring this to live somehow. Once we have a wasm build of the compiler we could use it for an online playground on the (upcoming) Fe website. Would you be interested to help out with that?

Yoshitomo Nakanishi
@Y-Nak
Thanks, Christoph. Yeah, I'm interested in the task. I'll start to investigate it.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> That's awesome, thanks!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> Hey everyone, we just shipped our monthly Fe release. Spread the word: https://twitter.com/official_fe/status/1374691926201499651
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> Hello everyone, we haven't used this channel in the past much. As the team grows we want to ensure that all communication happens out in the open so that all contributors feel welcome and have the same opportunity to follow along discussions. Therefore, we have created our own open Discord server that everyone should be free to join. You can use this link to join it: https://discord.gg/ywpkAXFjZH

We will be closing this channel soon.

Christoph Burgdorf
@cburgdorf
@/all :point_up:
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Piper Merriam> That is one sexy website: https://fe.ethereum.org/
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> @PaulJ Now that Fe has its own discord, we can archive this channel.
chriseth
@chriseth
ah, I hear the melodic sound of a decentralized service being shut down ;)
Does the fe discord have a bridge to somewhere?