Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support kimchi and string type in debugger API #219

Open
katat opened this issue Oct 30, 2024 · 5 comments
Open

Support kimchi and string type in debugger API #219

katat opened this issue Oct 30, 2024 · 5 comments
Labels

Comments

@katat
Copy link
Collaborator

katat commented Oct 30, 2024

The recent addition allows printing out variable values via log(var) builtin function.

However, it only supports the R1CS backend atm. Also, because noname doesn't support the string type variable yet, the log stdlib can't take a string argument to customize the message per logging output.

It would be very nice to have the following enhancements:

  1. Implement the log_var function for the kimchi backend. For reference, please check how the logging is implemented in R1CS backend.

  2. Support parsing strings in native code, so a customized logging message can be passed to the logging function. At this stage, we may just implement a builtin string type (read only) in order to pass to the log function. Later, we can extend this string type to be able to encoded in the circuit.

@katat katat added the easy label Oct 30, 2024
@mimoo
Copy link
Contributor

mimoo commented Oct 31, 2024

I think being able to write log("this is a {var} and this is another {var2}"); like in javascript would be cool

a third feature request would be to make it work with any types (array, structs, etc.) not just field types

@cwkang1998
Copy link

Would like to try this, although I might need some guidance.

Can I try taking this?

@mimoo
Copy link
Contributor

mimoo commented Nov 5, 2024

correct me if I'm wrong @katat but a first PR could just add support for string literals in the lexer/parser logic, so you can write things like let some_string = "some string!";

@katat
Copy link
Collaborator Author

katat commented Nov 5, 2024

correct me if I'm wrong @katat but a first PR could just add support for string literals in the lexer/parser logic, so you can write things like let some_string = "some string!";

It would also need to encode the string literal, so they can be passed around. I think it can be similar to how the literal boolean and ints are encoded.

ExprKind::BigUInt(b) => {
let ff = B::Field::try_from(b.to_owned()).map_err(|_| {
self.error(ErrorKind::CannotConvertToField(b.to_string()), expr.span)
})?;
let res = VarOrRef::Var(Var::new_constant(ff, expr.span));
Ok(Some(res))
}
ExprKind::Bool(b) => {
let value = if *b {
B::Field::one()
} else {
B::Field::zero()
};
let res = VarOrRef::Var(Var::new_constant(value, expr.span));
Ok(Some(res))
}

For both ints and booleans, they are represented by a single field. For string literals, they could be represented by an array of fields, each of which represent an ASCII code (a character of a string).

@katat
Copy link
Collaborator Author

katat commented Nov 5, 2024

Sounds good! @cwkang1998

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants