You can, well almost, download the code and compile it yourself. You cannot expect to access individual devs computers as they are working? We are pushing hard to get public testnet(s) folk can use what we put out or create their own (easily). It’s the best we can do and the faster we push the more likely it is to crash, that is the real terms costs. How reliable will the testnet we are pushing before Xmas be? Well we don’t know, but I would say not very, but that’s the purpose of pushing fast releases (which I feel we have to do now)
tl;dr it’s coming you can get it now if you wish, but our devs are finding bugs and fixing those, you would need to be able to do that to run your own network right now and we are happy if you can, especially if you fix bugs.
It would not be an internal testnet then by definition. I know a smart arse answer but an important distinction.
If the testnet were suitable for us to play with then they would not call it an internal testnet. But as David said you can download the code and run it, just its not packaged for easy installation by us.
Now the reason includes, but not limited to,
Need to change variables/parameters many times during testing to
try and find a good balance, or
to try and break it, or
fix minor bugs that only become apparent during break testing
and a few other things
Need to control the environment for each of the internal tests done on the testnet, some that cannot be reproduced easily in the real world.
Most importantly it allows very fast (minutes to hours) turnaround on code changes when tests show those changes are needed.
Okay, so the sn_api/sn_cli master branch will be compileable during the testnet phase?
Because right now it’s impossible for me to compile it.
error: reached the type-length limit while instantiating `<&mut alloc::sync::ArcInner<[clo...::atomic::AtomicBool>]>>>>::into`
|
= note: consider adding a `#![type_length_limit="1968004"]` attribute to your crate
No it’s not telling me how to fix this.
This is a recursion error and it’s not saying where the recursion error is taking place.
All I know that is one isn’t supposed to add #![type_length_limit="1968004"]
to where ever it is supposed to be necessary,
as such problem usually is that a piece code is being called into an endless loop.
But the big problem is that the error does not say anything about where this attribute is instantiated.
There’s no mention of a line, a file, or even crate.
There’s no stacktrace, even the method call isn’t properly displayed as it’s generic type is cut off.
You won’t know until you try it. I’ve seen a similar message for macros that’s fixed by doing as the compiler suggests. I doubt the compiler would give this message if it was likely to mislead, the Rust team have put massive effort into this area and it’s one of Rust’s strengths.
Give it a go, if you get the same message with a bigger number you’ll confirm your hypothesis.
To create a website that other users can see.
To create apps that other users can use.
To able to develop websites and apps on the safe network and be able to run a node.
Currently, there’s no network, no community network, no testnet, there’s no master branch that can be compiled, so I can test. And there’s no node that can be run, except locally.
There is no fun in creating a website that cannot be seen by anyone.
People are talking about an ‘internal testnet’. I thought Alpha 2 was the ‘internal testnet’ and that team Maidsafe has gone past that.
Maidsafe is the only project I know of that has gone “backwards” in development.
Well, maybe Duniter as well because they decided to somewhat gatekeep their product and then was told they would close off the part I wanted to use forever, which is the creating a new network function, so I’m experiencing a bit of a deja-vu on that part.
And I keep seeing people praising dev updates as if it’s amazing.
I don’t understand why. There’s currently only localhost working at the moment,
so none of the updates have any impact on the current product.
Since I can’t compile the master branch and I assume it would be quite difficult to develop on a non-compiling branch, I have to wonder, what is going on?
[EDIT]
I’ll try looking into the error.
I have been very reluctant to do any safe network development, thinking I’d only get in the way.
And also that I should first focus on the things I want to create, but I can’t do anything right now and I’ve been spurred on by you guys, so I will look into it myself.
I am not dev. So I am waiting testnet with brower.Then, I can check the loading speed and transfer test tokens.
So, if you want to make a homepages. I think you should wait public test like me.
But if you want to do something more deeper things and see what is exaxtly going on github, you have to understand whole logic and code.
It looks bery simple for me. If you have skills and knowledge about Rust based code, you can do that now. But if you cant, you have to wait. That is all.
I don’t know what the team is doing exactly at what stage. It is not easy for me too. But I have saw this team’s attitude and dev updates over 2 years, and I bet on this team. Because I think this team don’t lie. But they are also human, so the delaying and unexpected troubles are essential things in the R&D. But the chief said “R&D is over and testnet will be released soon”. It is good sign for me.
But waiting is still very difficult thing. I want you to cheer up.
I get your frustration @folaht and I know David and the team understand this and always try to support everyone, users and developers. The project has been a wild ride and many have fallen off, but there are always things we can do. Whether non-technical people, or developers, either our own stuff or helping with the codebase, or docs, or answering questions with the knowledge we gather. And all of it can be rewarding, even if like me you would prefer to be using a live network and building on it.
But to be honest, while I didn’t want the long period we’ve had without a network to use, especially not this year, I’ve really benefited from and enjoyed what I’ve found to get up to instead. I happened on syncer and wondered if I could turn it into a FUSE filesystem for Safe and decided I better learn some Rust. Spent a couple of weeks working through the book and then tried to think of what I could build to help deepen the learning. So I made the vault dashboard and learned how to build stuff that displays in the terminal, as well as writing Rust. Got asked to help @danda with his Safe CRDT Tree and learned about CRDTs and more about some of the inerds of Safe (much of which then got ripped out!). And now I’m learning Go/wasm to see if I can build a decentralised git portal. Its been a brilliant year in terms of what I’ve created and the skills I’ve learned that will mean I can build more for Safe (or any other project) using a range of different things. I haven’t mentioned Svelte + Tauri, that’s fun too and means I know how to take almost any web app and turn it into a cross platform Rust desktop app easily.
Maybe I’m just lucky to enjoy learning so much, and to have the time to do so. But I recommend it, and when you finally get to build on Safe you’ll be able to do more and better, and can take this with you to other projects too.
So good luck with fixing stuff, but also think about what else you might like to learn that doesn’t need Safe yet. Although it may not be long - I suspect we’ll have a bit longer to wait for the APIs though. Might be wrong but that’s what I’m assuming. Still for now, I have a lot to do on the git portal, and updating vdash to work with the new node logfiles.
But it has gone forward in development. Alpha 2 can be seen as still technically clunky, if they’ve now made so many changes with much much faster/more efficient components. Better efficiency and speed and reduced code are not backward things.
They had internal test nets a few weeks ago too. There is nothing new about this process. They do a bunch of development, then pull it altogether into an internal test net, then fix bugs they find.
The news here is that they will be making details on how to join the test net public, so others can join. Understandably, they want this experience to be reasonably good or what is the point? An unusable test network, full of bugs, will just get slated and will not answer any fundamental questions.
Why don’t you check the history associated with that line of code? See what broke it and when. Maybe ping the dev if you think it is a bug that needs fixing. They may already have it sorted on another branch, perhaps even just locally while making other changes.
You have complained about the test network being internal, then complained there are bugs. Do you not see the connection between the two? It isn’t ready for prime time yet. They are hoping it will be before Christmas, even if a bit warty.
We all want it to work yesterday, but we have to be patient and trust the team to work through the issues (or help if we can).
But there is a lot of value in refining your ideas, seeing what works and what doesn’t and - important for some - you get to make the most awful mess of it and nobody needs to know but yourself - and hopefully you learn from that and the next time you get it really wrong its for a different reason - and you learn from that too.
But now sn_node on the master branch has the same issue.
After finding the sn_cli culprit, I now know the error message is absolutely unhelpful in locating the infinite loop. *sigh*
So here we go again…
Wish me luck.
P.S.
Why is there a seperate launch tool being made?
What can sn_launch_tool do that sn_node doesn’t?
