I also have this question. I do not see any bitwise operations for felt yet. What is the effort to implement this?

I also have this question. I do not see any bitwise operations for felt yet. What is the effort to implement this?

Hi @DrCapybara I think the reason is to motivate developers to use uN instead of felt252. You can also see that other basic operations (like comparisons >, <, ...) have been removed. As I remember one of the policies of this new Cairo1 is to move away from the use of felts so that could be it.

First of all - you can probably consider just stating the value of the gas-builtin counter - it would indicate the actual amount of used gas in the counter - if you are actually trying to consider the gas mechanism, instead of the actual used resources.
if you want the actual used resources - you should count it specifically - using the vm itself.

You need the data you requested only for the process of emulating the actual used resources using the gas mechanism.

to answer the questions specifically:

1. Pre cost is the cost of builtins that the amount of usage of them is not affected by ap-changes or gas fetching (which are all builtins but the RangeCheck builtin), Post cost are the steps, holes and RangeChecks costs. The separation is to solve the required gas taken and ap changes in stages: the pre-cost (which is independent), the ap-changes (which only depends on the pre-costs), and the post costs (dependent on both).
2. This are values of gas redeposits and withdraws and burns (happens at branch_align and withdraw_gas{_,all}).
3. This the cost per branch of the libfunc.

Thanks for the detailed answer @orizi. I'm currently building a solution that is based on the gas mechanism (if I understand it correctly) because I use Sierra and it's metadata in order to get the costs for specific functions/libfuncs and then while executing the program, to illustrate where and how much gas is consumed. If this is an acceptable approach, it could be really informative when it comes to illustrating how it works in Cairo in general.

Some new questions that came to my mind after thinking about your answer:

• from what I understand there are actually two ways to get the gas count. The "real" one is to use the resources consumed by the VM, which is the most accurate since the sequencers use it to actually charge the users. The Sierra-based approach is kind of an approximation (since you used the word emulation?) or is it supposed to be exactly the same? If I understand correctly, Sierra itself should already give the sequencer some info about the future gas consumption before running the program to be able to tell whether the user has enough gas to execute specific code?
• what is the definition of builtins exactly? Is this a name for some base operations (like Poseidon application etc.)?

• The gas mechanism is an approximation of the worst case of the actual consumed resources, so it would charge different costs of different actually taken paths, (e.g. adding two u128s and overflowing has a different actual code being run then when not overflowing). Currently, when different branches are merged - the given gas consumption is merged as well using the branch_align command which burns the extra unused gas from the cheap branch. in general, there could've been more usage of the redeposit_gas command which would make this approximation be more tight with the actual usage of resources, currently it is a very non-tight upper bound.
• Builtins are extensions of the Cairo CPU that enables more complex actions such as Pedersen, Poseidon, bitwise operations and so on.

the calldata is the serialization of all parameters for the constructor:

let mut calldata = array![];
(param0, param1, param2).serialize(ref calldata);
let (deployed_address, _) = deploy_syscall(
 class_hash, 0, calldata.span(), false
 )
 .unwrap_syscall();

@orizi so that's another way to serialize data for the constructor, awesome.

I used this approach in my own project and as soon as my tuple grows to 5+ elements, e.g.:

let mut constructor_calldata: Array::<felt252> = array![];
(caller, title, target, duration, this).serialize(ref constructor_calldata);

the compiler complains with:

Method `serialize` could not be called on type `(core::starknet::contract_address::ContractAddress, core::felt252, core::integer::u256, core::integer::u64, core::starknet::contract_address::ContractAddress)`.
Candidate `Serde::serialize` inference failed with: Trait has no implementation in context: core::serde::Serde::<(core::starknet::contract_address::ContractAddress, core::felt252, core::integer::u256, core::integer::u64, core::starknet::contract_address::ContractAddress)>.

But when I remove any of the tuple members, the compiler error disappears.

I even tried this with 5 elements of the same type, and got the same compiler error.

This seems to be some hard cap on the maximum number of elements in a tuple that can be serialized.

Is this expected behavior?

Yes, we have implementation for tuples of up to 4 elements.
You can solve this by multiple calls, or just a tuple of tuples (it would logically be flattened)

You can solve this by... a tuple of tuples (it would logically be flattened)

🤯

So simple, yet magical. Thanks for the great and timely help!

ATM you can't. We want to add two small syscalls that will address this (you only need the first but listing both anyway):

• get_class_hash_at(contract_address: ContractAddress)
• is_declared(class_hash: ClassHash)

This is coupled with Starknet support, and can only make it to Starknet >= 0.13.3, hence it won't be present in the next few months.

Thanks.

I have a very specific use-case - I'm creating a Cairo track on Exercism. One of the exercises I'm implementing requires the learner to concatenate a string a bunch of times to create the famous "99 Bottles of Beer" song. The exercise is supposed to help the learner practice using loops, if-statements and strings.

Oh, so efficiency isn't an issue? If so, the loop it totally fine, as it is just an example.

Yeah, in retrospect, I should've included this in my original message, it would have added some important context.

I was wondering whether there exists some function or trait (or approach) that does this string concatenation more efficiently, so that I can include it in the solution explanation as a fun tip for the learner.
Is there by any chance anything like that in Cairo?

if you are extending an existing string, this is basically the best you can do for the time being.

Ok, thanks for being patient with me!

TBH I think we could use a category on discussions and post each question as separate post. Kinda Stack-overflow like

only .span() is actually fully allowed on them for the time being.
your case seems like an old version case - after the next release .span() would definitely work.

It's kind of confusing to be using a regular release (so not "nightly") and not have full features for a feature.
So fixed-size arrays basically cannot be used in code for the time being (other then just declaring them)?

and destructuring.

let [e0, e1] = arr;

it was partially useful for some specific instances - just wasn't for the usage as array case.

Thanks for finding this bug - will be fixed with the next release.
the issue is that since Option::None is a path - it was considered a variable - when it should have been considered an expression.
this is a bug in the assert_eq! macro suite.

Glad to be of help! Will open an issue

you can - but was already solved on main - and should be released soon.

Oh, didn't realize that. Will close it then

1. There was no associated type at the time.
2. Yes - but it would probably require some major high level changes (since we would want these traits to have a relation with the original into traits.

Is there anything like a list of (Rust-like) features that are planned to be implemented for Cairo?

I found the Cairo 0 parity roadmap, but that's not what I'm referring to; I'm talking about new traits, new syntax, new structs etc.

Your file is named hello_world.cairo. Do you have a module with the same name defined in your /src/lib.cairo file?
If not, open your /src/lib.cairo and paste the line mod hello_world anywhere inside it.

You need this for the compiler to know that hello_world.cairo is part of your project. This will also enable syntax highlighting.

Yes I have. I found that the language server seems not working properly.
image
But I have already installed scrab.

please install VSCode extension manually from main and then follow these steps to debug your problem: https://github.com/starkware-libs/cairo/tree/main/vscode-cairo#troubleshooting

on main I have added a bunch of trace logs that are telling what the extension sees when looking for scarb

The initial issue with this approach is the fact that Cairo's memory is immutable.
Since it is immutable - if you try to edit any node, the updated nodes address has to be different, so any pointed node must be changed.
So in the case of a doubly liked list, all nodes points to all other nodes, so you cannot change it.
A simple linked list, and editing of only its head would be fine (as the tail nodes don't point to head nodes).

Thanks for the clarification! I figured it had something to do with memory immutability.
I'll try to think of another way to accomplish the doubly-linked list, maybe there is a way.

For anyone facing a similar issue, I used the following structure to simulate a doubly linked list:

use core::dict::Felt252Dict;
type Index = Option<felt252>;
struct DoublyLinkedList<T> {
 dict: Felt252Dict<Nullable<Node<T>>>,
 head: Index,
 tail: Index,
 len: usize,
 next_index: felt252,
}
#[derive(Drop, Copy)]
struct Node<T> {
 station: T,
 next: Index,
 previous: Index
}

This would be a nice-to-have feature, nothing too important

if you use no dependencies (so scarb isn't used):
The cairo-run crate can be used with:
cairo-run --single-file /path/to/your/main.cairo - it will run the main fn in that file.