3 ms·

Even worse, it checks the git history to make sure that... - There are no changes since HEAD - The commit is signed by Robin himself ...and for those interes

Even worse, it checks the git history to make sure that... - There are no changes since HEAD - The commit is signed by Robin himself ...and for those interested in the code that does this https://github.com/gren-lang/compiler/blob/main/builder/src/Git.hs#L191 https://github.com/gren-lang/compiler/blob/main/builder/src/...

codetrotter 3y ago
Permalink https://github.com/gren-lang/compiler/blob/e665e521367eeedec016d70d167386c7cd145929/builder/src/Git.hs#L191 https://github.com/gren-lang/compiler/blob/e665e521367eeedec...
k__ 3y ago
lol, what did they smoke to think that's reasonable?!
- iampims 3y ago
  It’s their language, they can do as they wish.
  - hu3 3y ago
    That doesn't make it any more reasonable.
  - paulddraper 3y ago
    No one is contesting the physical ability, just the wisdom.
dopidopHN 3y ago
Wild. Do you know why is that code here?
adamrezich 3y ago
that stuff gets run on every compile (transpile?)? yet it seems that any would-be forker could easily remove it? surely this must all be an elaborate gag or something.
- Skinney 3y ago
  Only on the first compile. It doesn’t perform this check when loading a package from the build cache.
ArchieMaclean 3y ago
Correct me if I'm wrong, but that code seemingly only applies to kernel packages, i.e. packages which are made by the gren team [1] Seems more like a check to make sure the version of the JS is compatible with the version of gren than anything else. [1] https://github.com/gren-lang/compiler/blob/e665e521367eeedec016d70d167386c7cd145929/compiler/src/Gren/Package.hs#L79 https://github.com/gren-lang/compiler/blob/e665e521367eeedec...
- josephcsible 3y ago
  There are certain operations that only "kernel" packages are allowed to do. If that weren't the case, then this would indeed be little more than an obscure quirk.
  - ArchieMaclean 3y ago
    Ah I see. So non-kernel packages do not have access to native modules at all? I believe in Elm native modules were still possible, just not publishing them to the package database. But in this case I guess you wouldn't be able to put a native module in a GitHub repository and then pull this in as a dependency, which is equally rubbish. Edit: EdwardDiego's answer clarified this for me
    - Skinney 3y ago
      Elm doesn’t allow kernel code in externel packages. Gren is performing the exact same check, it’s just that Gren uses Git as a package manager and so has to do it in a different way.
EdwardDiego 3y ago
That's only for their "kernel code" though, right? Huh, yeah, looks like it bans non-Elm(Gren) code [0]. And found a great bug where it broke their own code. [1] [0]: https://github.com/gren-lang/compiler/blob/main/docs/kernel_code.md https://github.com/gren-lang/compiler/blob/main/docs/kernel_... [1]: https://github.com/gren-lang/compiler/issues/203 https://github.com/gren-lang/compiler/issues/203
brodo 3y ago
It baffles me why anyone would fork Elm just to recreate one of it’s greatest mistakes.
- girvo 3y ago
  Not even recreate, make the same mistake but even more intensely. It's impressive, in some ways.
  - tpaksoy 3y ago
    I think this is an unfair opinion of Gren. In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator itself, or from his inner circle of cool people. It seems like Gren is already ahead of this. Gren has community members actively working on the Websocket API to provide a typesafe core package with Kernel bindings. The question is: will Gren keep being open to contributors that can provide kernel code.
    - Skinney 3y ago
      That’s the plan
Lariscus 3y ago
Meet the new boss same as the old boss. Its a shame really. Elm seemed so promising a few years ago. I still like the ideas behind the project but the history of Elm is not confidence inspiring.

codetrotter 3y ago

Permalink https://github.com/gren-lang/compiler/blob/e665e521367eeedec016d70d167386c7cd145929/builder/src/Git.hs#L191 https://github.com/gren-lang/compiler/blob/e665e521367eeedec...

k__ 3y ago

lol, what did they smoke to think that's reasonable?!

iampims 3y ago
It’s their language, they can do as they wish.
- hu3 3y ago
  That doesn't make it any more reasonable.
- paulddraper 3y ago
  No one is contesting the physical ability, just the wisdom.

dopidopHN 3y ago

Wild. Do you know why is that code here?

adamrezich 3y ago

that stuff gets run on every compile (transpile?)? yet it seems that any would-be forker could easily remove it? surely this must all be an elaborate gag or something.

Skinney 3y ago
Only on the first compile. It doesn’t perform this check when loading a package from the build cache.

ArchieMaclean 3y ago

Correct me if I'm wrong, but that code seemingly only applies to kernel packages, i.e. packages which are made by the gren team [1] Seems more like a check to make sure the version of the JS is compatible with the version of gren than anything else. [1] https://github.com/gren-lang/compiler/blob/e665e521367eeedec016d70d167386c7cd145929/compiler/src/Gren/Package.hs#L79 https://github.com/gren-lang/compiler/blob/e665e521367eeedec...

josephcsible 3y ago
There are certain operations that only "kernel" packages are allowed to do. If that weren't the case, then this would indeed be little more than an obscure quirk.
- ArchieMaclean 3y ago
  Ah I see. So non-kernel packages do not have access to native modules at all? I believe in Elm native modules were still possible, just not publishing them to the package database. But in this case I guess you wouldn't be able to put a native module in a GitHub repository and then pull this in as a dependency, which is equally rubbish. Edit: EdwardDiego's answer clarified this for me
  - Skinney 3y ago
    Elm doesn’t allow kernel code in externel packages. Gren is performing the exact same check, it’s just that Gren uses Git as a package manager and so has to do it in a different way.

EdwardDiego 3y ago

That's only for their "kernel code" though, right? Huh, yeah, looks like it bans non-Elm(Gren) code [0]. And found a great bug where it broke their own code. [1] [0]: https://github.com/gren-lang/compiler/blob/main/docs/kernel_code.md https://github.com/gren-lang/compiler/blob/main/docs/kernel_... [1]: https://github.com/gren-lang/compiler/issues/203 https://github.com/gren-lang/compiler/issues/203

brodo 3y ago

It baffles me why anyone would fork Elm just to recreate one of it’s greatest mistakes.

girvo 3y ago
Not even recreate, make the same mistake but even more intensely. It's impressive, in some ways.
- tpaksoy 3y ago
  I think this is an unfair opinion of Gren. In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator itself, or from his inner circle of cool people. It seems like Gren is already ahead of this. Gren has community members actively working on the Websocket API to provide a typesafe core package with Kernel bindings. The question is: will Gren keep being open to contributors that can provide kernel code.
  - Skinney 3y ago
    That’s the plan

Lariscus 3y ago

Meet the new boss same as the old boss. Its a shame really. Elm seemed so promising a few years ago. I still like the ideas behind the project but the history of Elm is not confidence inspiring.