Array to Buffer in Motoko

What’s the correct way to convert an Array to Buffer in Motoko for both immutable and mutable?


1 Like

There are currently module-level functions (not class-level methods) that do each of these:

Doing it more directly would require changing the Buffer class’s constructor, so that it takes an array, but that is not planned for any near-term revision to the API, as far as I know.

Related (but doesn’t change the answer IIUC) – @kentosugama has focused a lot of recent attention on improving the Buffer API – See this Buffer Class Extension by kentosugama · Pull Request #416 · dfinity/motoko-base · GitHub

2 Likes

Dittoing Matthew’s response. You just have to call it as a static library function.

There will be a slight optimization to these functions in the new version, but they will be backwards compatible/under-the-hood, so you should be able to freely use these right now, with no problem.

As a note though, the current buffer to array conversions (the reverse direction) that exist as class methods will be deprecated in the new buffer, and users will be encouraged to use new static versions.

Thanks for the answer @matthewhammer and @kentosugama. I think I get it but I am to dumb to intepret it code wise. Do you have a concrete example somewhere?

Sorry for asking even it’s probably pretty clear for most people.

1 Like

No prob! Check out this example: Motoko Playground - DFINITY

Let me know if that helps.

Also, we’ll be adding examples to the library documentation in the future, so hopefully that also helps.

2 Likes

Thanks a lot, really appreciated!

So, turns out I’m maybe not that dumb, just a bit.

In VS code, your snippet works fine in one project but not in another sample repo. I ask myself if I don’t have a conflict with Vessel or something (which I don’t use in first project).

I would guess it’s a vessel configuration issue, but I’m pretty clueless with IDEs.

Gonna tag @rvanasa who works on the VSCode extension.

1 Like

Which dfx versions are you using in each of these projects (from your dfx.json file)?

You could also try deleting the .vessel directory and/or checking the package-set.dhall file in case something is out of date for your Vessel project.

Dfx v0.11.2

Vessel is most probably clean, I literally installed for the first time on my machine and added Vessel to the sample repo this morning :man_shrugging:

I ran into this same issue and the way I got around it was to point my vessel configuration to one of the recent moc-xxx tags on the Motoko-Base repo. Probably not the wisest thing to do but it did fix my problem and I’ve been able to call Buffer.fromArray() ever since.

Oh interesting! Do you mind sharing the configuration you changed in vessel?

Not at all. Apologies for the delay. Here is what I put in my package-set.dhall file

  { name = "base"
  , repo = "https://github.com/dfinity/motoko-base"
  , version = "moc-0.7.0"
  , dependencies = [] : List Text
  },
2 Likes

Awesome! You are right, that solves it for me too. Thanks a lot.

@rvanasa is that a Vessel feature or issue? should I open one on Github?

2 Likes

We’re in the process of updating the official Vessel package-set, so this will be fixed soon!

3 Likes

@rvanasa it isn’t just Vessel, the issue happens in a blank sample repo too with dfx v0.11.2

=> error

/Users/daviddalbusco/projects/lab/motokobuffer/src/motokobuffer_backend/main.mo:11.18-11.24: type error [M0072], field fromArray does not exist in type
module {
type Buffer =
{
add : X → ();
append : Buffer → ();
clear : () → ();
clone : () → Buffer;
get : Nat → X;
getOpt : Nat → ?X;
put : (Nat, X) → ();
removeLast : () → ?X;
size : () → Nat;
toArray : () → ;
toVarArray : () → [var X];
vals : () → {next : () → ?X}
};
Buffer : Nat → Buffer
}

The key distinction here is probably Vessel package set which I’m guessing is installed with dfx.

https://dfinity.github.io/vessel-package-set/

You mean installed on the machine? Because in the sample repo I just created and in which I get the issue there is no single trace of Vessel

But is the package set there? Perhaps in a location alongside wherever dfx installs moc and the Motoko base package?

That would probably help narrow down if this is just an issue with the base package.

Probably whatever path dfx cache show says.

It looks like only the motoko-base package is installed, which suggests to me that the issue lies there.

1 Like