No worries, I imagine thats not automated as of yet, I just wasn’t sure if the new version would be available at the time the website is updated, or immediately after the recipe update is merged into the git repo
Apologies for the delayed update – this is now automated!
The 25.2 compatible patch is now available on MAX Builds Emberjson Package | MAX Builds
I got this error when parsing a string whose size is 1.8 MB:
var json = parse(string)
Error:
#0 0x00007f69885c793b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/mnt/Archive/Documents/Programming/Mojo/life/.pixi/envs/default/lib/libKGENCompilerRTShared.so+0x3c793b)
#1 0x00007f69885c5246 llvm::sys::RunSignalHandlers() (/mnt/Archive/Documents/Programming/Mojo/life/.pixi/envs/default/lib/libKGENCompilerRTShared.so+0x3c5246)
#2 0x00007f69885c8547 SignalHandler(int, siginfo_t*, void*) (/mnt/Archive/Documents/Programming/Mojo/life/.pixi/envs/default/lib/libKGENCompilerRTShared.so+0x3c8547)
#3 0x00007f69a3c49df0 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0)
#4 0x00007f68d4026610
@notooth Could you provide the complete input in a file?
Does Emberjson support jsonl file? or is there any mojo library to read jsonl file?
Not at this time, but from the looks of it, it would be easy to add in. Could you describe your use case for it?
I am trying to read a dataset stored as jsonl file (many datasets are stored in jsonl format).
Ok yeah I think it makes sense to support that. Could you write a formal feature request on github and I’ll try to get to that soon.
ok thanks, will do
btw, how can I use emberjson? I run following, but get error message:
$ pixi add emberjson
Error: × failed to solve requirements of environment 'default' for platform 'linux-64'
├─▶ × failed to solve the environment
│
╰─▶ Cannot solve the request because of: No candidates were found for emberjson *.
Do you have the modular community channel added to your project? (https://repo.prefix.dev/modular-community). Though note that it currently only support stable releases. There has been some work done to support adding dependencies via github repo links like Go does, but I haven’t gotten around to making that possible in the emberjson repo, which I should do while I’m taking a look at this.
I already added the link to the channel in pixi.toml:
channels = [“https://conda.modular.com/max-nightly”, “conda-forge”, “https://repo.prefix.dev/modular-community”], is it correct?
But it didn’t work
this is the full pixi.toml:
[workspace]
authors = ["Cahya <My email>"]
channels = ["https://conda.modular.com/max-nightly", "conda-forge", "https://repo.prefix.dev/modular-community"]
name = "trie"
platforms = ["linux-64"]
version = "0.1.0"
[tasks]
[dependencies]
mojo = ">=25.6.0.dev2025090305,<26"
And the error message:
$ pixi add emberjson
Error: × failed to solve requirements of environment 'default' for platform 'linux-64'
├─▶ × failed to solve the environment
│
╰─▶ Cannot solve the request because of: No candidates were found for mojo
>=25.6.0.dev2025090305,<26.
It seems it can’t find emberjson in mojo 25.6.0.dev, so I changed the mojo dependency from “>=25.6.0.dev2025090305,<26” to “>=25,<26”, now it works.
Have you fixed the issue?
I don’t appear to have access to the link that you provided
I have just changed the file permission. Please access it again.
Looks like a particularly large string in that input was causing an issue in the vectorized fast-path string parsing since it was implemented using recursion. Seems to work fine now, thank you for reporting this!
EmberJSON 0.3.0
EmberJSON 0.3.0 is now available from the modular community package channel.
This is one of the most significant releases in quite a while.
Reflection based structured parsing
With the exciting addition of struct reflection in Mojo 0.26.1 we have unlocked
the power to serialize and deserialize Mojo structs into JSON WITHOUT the
need for trait conformances on every type that needs or might need to be
used as a JSON value. Structured parsing also often offers a massive performance
increase over unstructured parsing.
from emberjson import serialize, deserialize
@fieldwise_init
struct Foo(Movable):
var a: Int
var b: Bool
def main():
var f = Foo(234, False)
print(serialize(f)) # prints {"a":234,"b":false}
f = deserialize[Foo]('{"a":45,"b":false}')
print(f.a) # prints 45
Any plain struct will currently be handled as a JSON object, with each field
name becoming the object key to its value. If you wish to customize the
behaviour, you can add conformance to the JSONSerializable and/or
JSONDeserializable traits. Further customization will be available in later
releases as Mojo’s reflection capabilities mature.
from emberjson import (
serialize,
deserialize,
JsonDeserializable,
JsonSerializable,
Parser,
)
@fieldwise_init
struct Foo(JsonDeserializable, JsonSerializable):
var a: Int
var b: Bool
fn write_json(self, mut writer: Some[Writer]):
# serialize as an array
writer.write("[")
writer.write(self.a)
writer.write(",")
writer.write(self.b)
writer.write("]")
@staticmethod
fn from_json(mut p: Parser, out s: Self) raises:
s = Foo(0, False)
# deserialize as an array
p.expect(UInt8(ord("[")))
s.a = Int(p.expect_integer())
p.expect(UInt8(ord(",")))
s.b = p.expect_bool()
p.expect(UInt8(ord("]")))
def main():
var f = Foo(234, False)
print(serialize(f)) # prints "[234,false]"
f = deserialize[Foo]("[45,false]")
print(f.a) # prints 45
As a bonus, Ember now supports more ergonomic access patterns to Value, including
JSON pointer syntax.
from emberjson import Value
def main():
var v: Value = {
"a": [
1,
2,
3,
],
"b": {
"c": 4,
"d": 5,
},
}
print(v.get("/b/d")) # JSON pointer access
print(v.a) # object key as field access
print(v.`/b/c`) # JSON pointer using backtick identifier
v.a[0] = 100 # nested access and mutation
print(v.a[0])
Consolidation of JSON and Value types
In previous versions Ember included two distinct types: JSON and Value.
JSON was used to represent a JSON document that was either an Object
or an Array. Value was used to represent a JSON document that could be
any valid JSON value. In this release I have consolidated these two types
into a single type, Value. This was done to simplify the API and implementation,
and to better align with the JSON standard which actually allows any top-level
JSON value.
JSON is now an alias for Value for backwards compatibility purposes.