error building purescript-dotlang about purescript-native HOT 16 CLOSED

I'm using version 2, which the following in my packages.dhall:

  let additions =
      { dotlang =
          { dependencies =
              [ "colors"
              , "console"
              , "effect"
              , "generics-rep"
              , "prelude"
              , "psci-support"
              , "strings"
              , "test-unit"
              ]
          , repo = "https://github.com/csicar/purescript-dotlang.git"
          , version = "v2.0.0"
          }
      }

  in  upstream // overrides // additions

from purescript-native.

I looked at it a bit more. The two issues are unrelated. The second one comes from the standard javascript transcompilation behavior: javascript tolerates multiple var s declarations but go doesn't. I have a fix that just needs some testing.

The first issue is also related to behavior inherited from the javascript backend, where a collision with the Color identifier is handled by appending "_1". However, the javascript backend is still doing the importing (require) correctly with the unmodified name. So I need to fix the go backend to either do the same, or change the renaming scheme a bit to handle it.

from purescript-native.

I'm guessing it has something to do with this section

from purescript-native.

There seems to be a related issue with functions with multiple definitions:

# project.localhost/purescript-native/output/Color
output/Color/Color.go:259:25: s redeclared in this block
	previous declaration at output/Color/Color.go:251:25
output/Color/Color.go:469:13: s redeclared in this block
	previous declaration at output/Color/Color.go:454:13

The original function:

hsva :: Number → Number → Number → Number → Color
hsva h s   0.0 a = hsla h (s / (2.0 - s)) 0.0 a
hsva h 0.0 1.0 a = hsla h 0.0 1.0 a
hsva h s'  v'  a = hsla h s l a
  where
    tmp = (2.0 - s') * v'
    s = s' * v' / (if tmp < 1.0 then tmp else 2.0 - tmp)
    l = tmp / 2.0

The generated code with the lines with variable re-declarations marked:

 func PS__hsva() Any {
      return func(h Any) Any {
          return func(v Any) Any {
              return func(v1 Any) Any {
                  return func(a Any) Any {
>>                    var s Any = v
                      if v1 == 0.0 {
                          return Apply(PS__hsla(), h, s.(float64) / (2.0 - s.(float64)), 0.0, a)
                      }
                      if v == 0.0 && v1 == 1.0 {
                          return Apply(PS__hsla(), h, 0.0, 1.0, a)
                      }
                      var tmp Any = (2.0 - v.(float64)) * v1.(float64)
>>                    var s Any = (v.(float64) * v1.(float64)) / Run(func() Any {
                          var ᵗ25 Any = tmp.(float64) < 1.0
                          if ᵗ25 == true {
                              return tmp
                          }
                          return 2.0 - tmp.(float64)
                      }).(float64)
                      var l Any = tmp.(float64) / 2.0
                      return Apply(PS__hsla(), h, s, l, a)
                  }
              }
          }
      }
  }

from purescript-native.

I found the second issue – it's caused by an inliner function provided directly by the main purescript compiler, which is surprising.

For the first issue, which version of dotlang are you using? It's not in the standard package set, and isn't obvious from the releases page which version one would typically use. Any other info you can provide on what you're building would help too.

from purescript-native.

I ran the same test with the cpp backend and hit the same duplicate definition issue. I see the golang label you added, so wanted to make sure the change could encompass both backends. I'm not sure how much of the code is common between them.

from purescript-native.

Good point, thanks

from purescript-native.

Out of mostly curiosity, do you plan on using the C++ backend as well as the golang one? Go gets a bit more attention these days, and tbh I'm generally recommending it to people who don't have specific C++ interop needs. Its garbage collector generally works better (faster) than std::shared_ptr reference counting (and has no concerns with retain cycles), and golang compilation is really fast.

from purescript-native.

I was experimenting with each based on specific libraries that I wanted to wrap. I could try to use only the go backend, as there are probably go wrappers for most cpp projects that I would intend to wrap with purescript, but I have heard that go's ffi is slow, and having two layers of indirection would make debugging and analyzing performance more difficult.

As for the issues with shared ptr, have you considered using a gc like boehm?

I've also seen a suggestion somewhere to alloc without freeing, in short lived programs, where the assumption is that the os will free the memory on completion and the total memory used is small enough that reclaiming it is not necessary and might even be unnecessary overhead.

from purescript-native.

Ok, thanks for the info, and for the bug reports.

Yes, I used to officially support Boehm as a build option when it was pure11. I stopped supporting it for a few reasons, but once in a while I look to see if any new GCs come out that would be interesting options.

Yeah, alloc without freeing is also something that could be explored for the C++ backend, and can already be done with golang because they support turning off the gc (though I haven't tried it). I've also played around a bit with alternative allocators like jemalloc and saw some interesting results.

from purescript-native.

I tried your branch and a dotlang example to compile! I just had to add one more function to the ffi:

 mathExports := Foreign("Math")
 mathExports["round"] = func(x_ Any) Any {
   x, _ := x_.(float64)
   return math.Round(x)
 }

Should I pr it to that project?

from purescript-native.

Sure, thanks!

from purescript-native.

Pr up here andyarvanitis/purescript-native-go-ffi#14

Interesting, I'll play around with the go flags and jemalloc as well. Do you have any notes on the difference between the cpp and go branches? Would it just be a matter of tedious work to merge the two so changes that apply to both are easier to get merged, or is there some reason they have to be separate?

from purescript-native.

Merged, thanks.

I don't have any such notes, unfortunately. I had (re)structured the code a while back to be able to start reusing as much as possible between the two, but just didn't have the time to actually get there. I do at least try to maintain as similar a structure between them as possible, to keep the option open.

from purescript-native.

I could spend some time on that if you can give me some pointers.

from purescript-native.

Closing, since I believe this has been fully addressed, but feel free to reopen if you find any problems with it.

from purescript-native.