Build fails with: could not determine kind of name for C.mrb_ary_len

[cromega]

Hi,

Building the library fails as follows:

go-mruby git:(master) go build
# github.com/mitchellh/go-mruby
./array.go:15:13: could not determine kind of name for C.mrb_ary_len

A commit to MRuby from 2017 (67e2dddb8254fbf4a4eb81c1241ec1963bc77627) seems to have introduced the following change:

    Remove `mrb_ary_len` function. Use `RARRAY_LEN` instead.

Wondering why it hasn't caused problems for anyone else. Am I doing something stupid?

Go: 1.11.5
Mruby: 2.0.0

[cromega]

I actually came up with a pretty simple workaround for this issue, sadly there are other errors so I couldn't run the tests yet.

Is it a case of the code not being compatible with more recent versions of mruby and it's probably not going to work?

[erikh]

Yes; as of 1.4 or so the build doesn't work with the mruby source anymore. There's an open ticket for it (not near github atm).

…

On Wed, Feb 6, 2019 at 9:32 AM Bence Monus ***@***.***> wrote: I actually came up with a pretty simple workaround for this issue, sadly there are other errors so I couldn't run the tests yet. Is it a case of the code not being compatible with more recent versions of mruby and it's probably not going to work? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#72 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABJ6xCgr-zKJM4gUv2TAXBwcXEK1EyOks5vKxHIgaJpZM4alr5o> .

[erikh]

If you leverage the 1.2.0 tag, it will all work.

…

On Wed, Feb 6, 2019 at 10:04 AM Erik Hollensbe ***@***.***> wrote: Yes; as of 1.4 or so the build doesn't work with the mruby source anymore. There's an open ticket for it (not near github atm). On Wed, Feb 6, 2019 at 9:32 AM Bence Monus ***@***.***> wrote: > I actually came up with a pretty simple workaround for this issue, sadly > there are other errors so I couldn't run the tests yet. > > Is it a case of the code not being compatible with more recent versions > of mruby and it's probably not going to work? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#72 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AABJ6xCgr-zKJM4gUv2TAXBwcXEK1EyOks5vKxHIgaJpZM4alr5o> > . >

[erikh]

see #66 for more information.

[wade-welles]

Still getting this for the last 6 months

[erikh]

The comment right above yours tells you how to resolve it. I'm genuinely sorry I haven't had time to completely rewrite the C layer (which is what is required), but you're welcome to send patches if it bothers you so.

…

On Tue, Mar 26, 2019 at 7:15 AM wade-welles ***@***.***> wrote: Still getting this for the last 6 months — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#72 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABJ65-tHVJZVQGKUNDVOOHcyNAieXo_ks5vaiuUgaJpZM4alr5o> .

[wade-welles]

I apologize if I struck a nerve, I should have clarified my situation more.

I have tried in that in the past without success unfortunately. I will build a new VM and try again. Id be happy to rewrite it, I'm juggling a few things so any pointers or notes you have that could help me get started quicker would be appreciated.

I was considering implementing a lexer and parser and finishing off GoRuby so the community has something, but obviously that's not the most ideal route since it is implementing it without a VM. The quickest solution seems obviously to carry on the embedding.

I have even begun experimenting with different ways of embedding the binary so that it will directly use the executable (i.e. /usr/bin/mruby or just ruby).

But obviously without the bindings its limited use as a scripting language, which I believe is what most of us are here for.