/robowaifu/ - DIY Robot Wives

Advancing robotics to a point where anime catgrill meidos in tiny miniskirts are a reality.

The Mongolian Tugrik has recovered its original value thanks to clever trade agreements facilitated by Ukhnaagiin Khürelsükh throat singing at Xi Jinping.

The website will stay a LynxChan instance. Thanks for flying AlogSpace! --robi

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

More

(used to delete files and postings)


Knowing more than 100% of what we knew the moment before! Go beyond! Plus! Ultra!


The Sumomo Project Chobitsu Board owner 11/24/2021 (Wed) 17:27:18 No.14409
So I've been working for a while at devising an integrated approach to help manage some of the software complexity we are surely going to encounter when creating working robowaifus. I went down many different bunny trails and (often) fruitless paths of exploration. In the end I've finally hit on a relatively simplistic approach that AFAICT will actually allow us to both have the great flexibility we'll be needing, and without adding undue overhead and complexity. I call this the RW Foundations library, and I believe it's going to help us all out a lot with creating workable & efficient software that (very hopefully) will allow us to do many things for our robowaifus using only low-end, commodity hardware like the various single-board computers (SBCs) and microcontrollers. Devices like the Beaglebone Blue and Arduino Nano for example. Of course, we likely will also need more powerful machines for some tasks as well. But again, hopefully, the RW Foundations approach will integrate smoothly with that need as well and allow our robowaifus to smoothly interoperate with external computing and other resources. I suppose time will tell. So, to commemorate /robowaifu/'s 5th birthday this weekend, I've prepared a little demonstration project called Sumomo. The near-term goal for the project is simply to create a cute little animated avatar system that allows the characters Sumomo and Kotoko (from the Chobits anime series) to run around having fun and interacting with Anon. But this is also a serious effort, and the intent is to begin fleshing out the real-world robotics needs during the development of this project. Think of it kind of like a kickstarter for real-world robowaifus in the end, but one that's a very gradual effort toward that goal and a little fun along the way. I'll use this thread as a devblog and perhaps also a bit of a debate and training forum for the many issues we all encounter, and how a cute little fairybot/moebot pair can help us all solve a few of them. Anyway, happy birthday /robowaifu/ I love you guys! Here is my little birthday present to you. === >rw_sumomo-v211124.tar.xz.sha256sum 8fceec2958ee75d3c7a33742af134670d0a7349e5da4d83487eb34a2c9f1d4ac *rw_sumomo-v211124.tar.xz >backup drop https://files.catbox.moe/n2cffh.7z === >"We witness Sumomo performing the wakey wakey exercises." (>>14459) === >RW Foundations Caturday drop : latest cut edition (>>16329) You can go here if you want to see where we're currently at with progress on the overall super-project, Anon. -Mini-tutorial on downloading & building RW Foundations code. (>>15074) >=== -add post subject -minor grammar edit -minor prose edit -add 'we witness' crosslink -add/edit 'latest cut' crosslink -add mini-tutorial crosslink
Edited last time by Chobitsu on 05/20/2022 (Fri) 20:36:38.
RW Foundations Caturday drop : v220226 edition Anime Catgrill Meidos. The reality will be worth it all Anon! :^) So, one of the oddities about imageboard's APIs (at least we find it so) is that a thread's human-oriented information (subject, message, post ID) is contained in the catalog JSON, while the posts themselves are a sub-array contained in the thread JSON. Not only is this an awkward approach for any anon actually programming against such an API, but it's also pretty inefficient computationally-speaking. Within Bumpmaster at least, we'll be setting about to fix this. Basically the first order of business then is to combine all these elements together into a more appropriate data structure. Here's the basic (and rather simple) idea so far (BTW, please pardon me if you're already conversant with C++ programming, my goal with this explanation is to familiarize those a little new to it here) : >bumpmaster.hpp snippets /** A simple data struct to help with catalog's thread's information */ struct Thrd_data { // Lynxchan's JSON tag names: string msg; // message string subj; // subject unsigned id; // threadId vector<Post_data> posts; }; ... /** A simple data struct to help with thread's post's information */ struct Post_data { // Lynxchan's JSON tag names: string date; // creation string msg; // message unsigned id; // postId }; These are a pair data structures we've created to hold the information we're actually interested in for Bumpmaster (we touched on a similar one last drop). We can talk about that std::vector member in the first one later, but for now just think of it as an open-ended container for the second type of struct, Post_data. Basically, we have one data struct that's about the threads, and another one that's about the posts. We collect up all the post's data into that data container in the first struct. After these data sets are combined together this way, it's a much easier task to iterate over them -- and also more efficient too. That's really all there is to it Anon. We can talk more later about how we process this new data structure with our algorithms. If you have any questions in the meantime please don't hesitate to ask ITT. Well, we hope you're coming up with some cool new ideas for your robowaifu-building adventures Anon. Please share them here with us all when you do! :^) Cheers === >version.log v.220226 --------------- -add top_bump_thrds(); bumpmaster -add bump_thrd_dats(); bumpmaster -add from_json(), to_json() utility funcs; bumpmaster for Thrd_data, Post_data -add Thrd_data struct; bumpmaster -s/Postdata/Post_data/; bumpmaster -s/parse_cat_uri/parse_ib_uri/; bumpmaster -rm rd_thread_id(), uneeded; bumpmaster >rw_bumpmaster-v220226.tar.xz.sha256sum 33a4ac51ee14a64de0b09247db5e5a9de75b4e839cd330ee00dc9c20d994fcfa *rw_bumpmaster-v220226.tar.xz >backup drop https://files.catbox.moe/00juix.7z
>>15324 Is the bumpmaster project supposed to be board integrated ai or a new imageboard api? It can be kindve confusing at times with the maidu pictures but your data structure explanation makes more sense than any college professors lectures, programming forums, or books I’ve read. Would be neat to ask bumpmaster catgirl maidus to find a post or thread. Have you thought about getting the sumomo ai to celebrate holidays and anniversaries? Its been done before through various other apps and projects.
>>15324 Bumpmaster isn't working for me. page_uri: https://alogs.space/robowaifu/catalog.json req made 0.4s Json::parse_error '[json.exception.parse_error.101] parse error at line 1, column 1: syntax error while parsing value - unexpected end of input; expected '[', '{', or a literal' caught in fstream_2_json() I tried to debug it and it seems it's trying to parse the json before chkd_pull_g finishes downloading the file. Then it segfaults. ==845051== Invalid read of size 8 ==845051== at 0x4A58268: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29) ==845051== by 0x12AC77: rw::curator::bumpmaster::Bumpmaster::top_bump_thrds(nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > > const&, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (bumpmaster.cpp:247) ==845051== by 0x111482: main (main_bumpmaster.cpp:52) ==845051== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==845051== ==845051== ==845051== Process terminating with default action of signal 11 (SIGSEGV) ==845051== Access not within mapped region at address 0x8 ==845051== at 0x4A58268: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29) ==845051== by 0x12AC77: rw::curator::bumpmaster::Bumpmaster::top_bump_thrds(nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > > const&, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (bumpmaster.cpp:247) ==845051== by 0x111482: main (main_bumpmaster.cpp:52)
>>15332 >Is the bumpmaster project supposed to be board integrated ai or a new imageboard api? Either are possible. But for now, the design goal for it is simply A) to be a better, more capable version of BUMP, and B) to have a real-world project to get our feet wet developing within the RW Foundations suite of libraries. This second aspect in particular is pretty important here at the beginning of things. >It can be kindve confusing at times with the maidu pictures can there ever be enough anime catgrill meido pics Anon? :^) SEND MORE RUNNING SHORT >but your data structure explanation makes more sense than any college professors lectures, programming forums, or books I’ve read. Thanks! >Would be neat to ask bumpmaster catgirl maidus to find a post or thread. The plan is to integrated Waifusearch into both Foundations & Bumpmaster next. We'll see how it goes >Have you thought about getting the sumomo ai to celebrate holidays and anniversaries? Its been done before through various other apps and projects. Sure, PDA-like abilities are definitely a goal for our robowaifus, and it's a foundational trope for the field. Not sure exactly where our version of such capabilities will fit yet. Probably a complex from RW Atashi, RW Meido, and RW Sempai (possibly others) would be my initial take on the matter Anon. >>15334 Sorry about that Anon. We'll try to reproduce the error on this end and see if we can get to the heart of the issue. Excellent feedback BTW! :^)
>>15307 Thanks Anon! I shall be stealing re-posting these ITT before long. >Aye, we must work til all Anons can have their waifu meidos. You encourage me Kiwi. For me this is a spiritual quest as much or more than a hobbyist->professional effort with incredibly neat tech. Men around the world really need groups like us to succeed!
>>15334 Quick update without much depth yet Anon. We were able to produce a similar effect by building the code in debug mode, rather than the specified release mode. This setting is specified in the project options in meson.build : # basic & default project arguments project('rw_bumpmaster', 'cpp', version : 'v220226', license : 'MIT', default_options : [ 'cpp_std=c++17', 'buildtype=release', 'warning_level=3', 'werror=true' ]) As a quick test, I'd suggest you set execute this command from the project's base directory: cd build && meson configure -Dbuildtype=release && cd .. Then rebuild & try again. Let us know your results ITT please, thanks. We'll spend some time soon to understand the dynamics of what the compiler optimizations are doing under-the-table to order sequence timings that led to this bug. We'll patch it ofc as we do so, and will make note of that in the version.log entries. Cheers.
>>15343 Yeah, same problem. I had the issue with the release build then rebuilt it in debug to find where it was coming from. The problem persists with different optimization levels on my machine too.
>>15347 Ah I see. Well, again we'll try to track this issue down soon. Out of curiosity have you been able to build/run any of the previous versions of drops made ITT? Also, have you been able to build BUMP or Waifusearch? These answers might help us track down machine-dependent issues that might be involved. Thanks again for the feedback Anon! :^)
>>15347 OK, looks like we've tracked the issue down to the most obvious one which I neglected to check first thing : the downloaded file is itself the issue. That is, the server only sent partial data. Currently this isn't being caught by Dollnet, so we'll work on that. In the meantime, simply deleting the files and retrying should do it. (Just use the release build, that was purely coincidental timing of getting a bad file during that test. It's unrelated). rm ./dolldrops/* build/bumpmaster Please give that a go Anon and let us know how it goes for you.
>>15369 There weren't any partial files in dolldrops but this solved the issue. The problem occurs trying to run bumpmaster from the build folder.
>>15372 And if I make the dolldrops folder in the build folder it works fine, so I'm guessing it's not checking if that directory exists and then tries to parse a non-existent file after it fails to open it for writing, strangely before it finishes downloading. I'm a bit confused why the download wouldn't fail if it opened it for writing first or if it's opened for writing after, why it tries to parse the non-existent file before downloading finishes.
>>15372 >>15378 Glad to hear you got it working Anon. Again, thanks for the excellent feedback. >The problem occurs trying to run bumpmaster from the build folder. So, we've introduced some new code to address this. After the upcoming Caturday drop, you'll be able to move the executable binary out of the build/ directory and run it wherever you want to. The system will create the needed ./dolldrops/ directory for you before downloads begin. >I'm a bit confused why the download wouldn't fail if it opened it for writing first or if it's opened for writing after, why it tries to parse the non-existent file before downloading finishes. There are two things going on there. One is that the handle mechanism for files is short-circuiting processing when the filepath is invalid AFAICT. The other is that I haven't implemented sufficiently robust file checking yet. The plan is definitely to have fairly good file/data introspection later on (well before we have working robowaifus up with this system), but for now we're fairly confident about the source JSON data. So basically it's been a bit of a timing toss-up between over-engineering things at this early stage of the systems, or moving on to usable functionality with the two preliminary utility programs. We've tended to favor the latter when it seems reasonable. However, we'll improve basic checking soonish, to at least avoid segfaults and report the errors better.
RW Foundations Caturday drop : v220305 edition Cute robowaifu anime catgrill meidos. I wonder if Pygmalion would approve today? :^) So, we talked last drop about data structures for threads. But how to we use them? The first order of business is to load them up with data. We use the IB JSON files provided by the site's servers for this. There are two steps for this in the higher-level sense. First, we iterate the JSON data and pull out the thread's details (the OP's details, really) from the catalog JSON: >bumpmaster.cpp snippets auto Bumpmaster_b::bump_thrd_dats(Json const& cat_json) -> std::vector<Thrd_data> { stamp("bump_thrd_dats()"); vector<Thrd_data> res; res.reserve(cat_json.size()); for (auto const& [nindx, cat_thrd] : cat_json.items()) { res.emplace_back(cat_thrd); // ctors Thrd_data struct in-place } return res; } This function gets called from another function actually. This one both downloads each thread's JSON, and then also loads it's 'posts' JSON into the thread structure (remember that open-ended container in this structure from last time? yeah, that one). auto Bumpmaster::top_bump_thrds(Json const& cat_json, const int thrd_lim, std::string const& site, std::string const& board) -> std::vector<Thrd_data> { stamp("top_bump_thrds()"); vector<Thrd_data> res; // store all thread's data (msg, subj, ID) from the catalog; in bump-order auto thrd_dats = bump_thrd_dats(cat_json); // assemble each thread's JSON page URI; in bump-order auto const thrd_uris = bump_thrd_uris(cat_json, site, board); for (auto t_idx{0}; t_idx < thrd_lim; ++t_idx) { // for all Page 1 threads auto const thrd_uri = thrd_uris[t_idx]; // index to uri // pull thread's dolldrop cout << " page_uri: " << thrd_uri << '\n'; auto const thrd_json = pull_json_drop(thrd_uri); // DESIGN: DEBUG: address invalid JSON data here // copy the current thread's data into the results container auto& thrd_dat = thrd_dats[t_idx]; thrd_dat.posts = thrd_posts(thrd_json); // res.push_back(thrd_dat); } return res; } We're all set now. Each thread structure is now populated, and has all it's data needed from the catalog and all the post's data as well. All that's left now is to output this information to the console. We can talk about that step later, as this is more than enough code for this time! We also began a new sub-library RW Cleaner, as part of the RW Meido library. I think all of us would appreciate having our cute anime catgrill meidos clean up after us, right? :^) It will actually be a big challenge but a fun one to figure out these kinds of tasks for our robowaifus to perform. For example, washing dishes is literally filled with hundreds of 'judgement call' actions to perform for just this one type of chore alone. Well, we hope you are doing well Anon. We appreciate all the hard work everyone puts in exploring these frontiers of robowaifu development and look forward to seeing your fine achievements. Keep moving forward! Cheers. === >version.log v.220305 --------------- -add wrt_tailme() non-member utility func; mailstop.cpp -add preflight(), mk_dropdir() utility funcs; mailstop -add exists_fs() utility func; rw::sys -add 'dropdir' filepath const; dolldrop -begin Cleaner; rw::meido >rw_bumpmaster-v220305.tar.xz.sha256sum d5fcc066e70b8e11f05fe971aecdf92919df89106732d93c1c46951192e7046d *rw_bumpmaster-v220305.tar.xz >backup drop https://files.catbox.moe/1wql8r.7z
>>15372 OK, please give the new cut a try and see if it suits Anon. (>>15405)
Open file (218.45 KB 850x1149 CinnaCatMaid.jpg)
>>15405 Your progress continues to inspire Chobitsu. Considering the boards sudden shift towards favoring Reploids, thought you may enjoy a cat grill Reploid meido to cheer you on!
>>15415 Thank you for your kind words Anon. I hope we can have real progress with the Sumomo's World project sometime this year. How would you feel about us creating an exporter for scenes into Blender? Would that be any help to you? > thought you may enjoy a cat grill Reploid meido to cheer you on! Indeed I do! I'd like to see her become real someday tbh. Super cute!
RW Foundations Caturday drop : v220312 edition Anime Catgrill Meidos will surely be wildly popular once they become real Anon and we must all diligently strive forward towards that day!! :^) We made changes in this drop that have some improvements to error-detection with the dolldrops process. And, for the first time, a bit of error-correction too. A new function for RW Bumpmaster in this drop is pull_json_retry(). It will actually make another go of it, if the dolldrop turns out invalid for some reason. This size-checks enhancement serves a dual-purpose; a) be more efficient with bandwidth resources, and b) perform general due-diligence to help avoid unintentional misuse issues. In our testing things seem to be working pretty well so far with it. === So, last drop we were talking about the functions that load up the structure for holding a thread's info. Namely, both it's OP data, as well as all post's data for that thread -- and into just a single object (which now can easily be passed around and processed). We load up a container-full of these things, and return that back to the caller. Now it's time to take a spin at printing all this lovely text out to the console. As you recall, we last left off at the top_bump_thrds() function. And so we pick back up with it again; but this time on the other side, and calling it from the Bumpmaster demo's main(): >main_bumpmaster.cpp snippet // load a new container with catalog's Page 1 threads + posts; in bump-order auto const top_thrds = bump.top_bump_thrds(cat_json, thrd_lim, site, board); // cycle the top threads (& print their data) size_t t_idx{0}; // for (auto const& t : top_thrds) { // puts("\n\n --=^=--\n"); cout << " Bump " << ++t_idx // prt thrd's data << "\n =======================================\n" // << setw(8) << setfill(' ') << t.id << " : " // << t.subj << "\n\n' " << t.msg << " '\n"; // // calc starting post's thread index auto const sz = static_cast<int>(t.posts.size()); // cast avoids overflow auto const start{sz - post_lim}; // for this subtraction // cycle the latest posts (& print their data) for (auto p_idx{(start >= 0 ? start : 0)}; // ensure we have valid index, p_idx < sz; ++p_idx) { // (as sz might be < post_lim) auto const& p = t.posts[p_idx]; // index to post, cout << '\n' // prt post's data << setw(33) << setfill(' ') << "r " << (p_idx + 1) << "\n ------------------------------------\n" << setw(8) << setfill(' ') << p.id << " : " << p.date << "\n' " << p.msg << " '\n"; } } This code takes that container object (we named top_thrds since it's about the Page One threads) and traverses each element in it, one-by-one, via that C++ range-for loop (each of these elements happen to be one of those Thread Structures we talked about). We name these simply as t (for thread). Such a terse name is OK for this context, since it's a small scope inside the loop, and it's also a good symmetry with p (for post, which we'll name later). First thing we do is print out the thread struct's first 3 fields, id, subj, & msg along with a few little formatting tweaks. Next, we calculate the starting printout-post's index inside the thread. We do this b/c we just want to print the latest 5 posts to the terminal, not all of them. You might recognize that this is pretty much how a standard IB index page works. Anyway, to get the correct starting index for post printouts, we just subtract the post-limit count (5), from size() of the posts container field in the thread struct (that 'open-ended' one). Remember that in C and most other programming languages, array indices start at 0. So, say there were 20 posts altogether, we'd begin printouts with index 15 (post #16), then index 16 (post #17), and so on to index 19 (post #20). Finally, we just print out the 5 post's 3 fields, id, date, & msg, again with some little formatting tweaks. That's it, we're done with that thread printout. Lather, rinse, repeat for the next 9 threads. Then repeat the whole cycle for all the board listed in this 'open-ended' container of URI strings: // container of various IB URI strings // -try other boards you like, Anon! :^) // clang-format off vector<string> const board_uris{ // NOTE: currently supporting only Lynxchan sites (for v220312) "https://alogs.space/robowaifu/", "https://alogs.space/pdfs/", "https://prolikewoah.com/geimu/", "https://late.city/late/", "https://anon.cafe/christian/", }; Congrats Anon! Over the past three drops, we've created a handy multi-board offline text reader for IBs. It's both lightweight on resources and fast. BTW, you may need to increase your terminal's output buffer size, since this could easily grow to thousands of lines of text if you add lots of boards into your list. Later we'll add what BUMP does to allow other, non-Lynxchan boards as well. Well we hope you're getting lots of bright ideas and clever robowaifu-making insights, and are moving forward day-by-day towards your goals with her. Keep your dreams alive Anon! :^) Cheers. === >version.log v.220312 --------------- -check Json validity on pull_json_retry() calls; bumpmaster -add pull_json_retry(); bumpmaster -mv to tuple<bool, Json> ret, pull_json_drop(); bumpmaster -add do_catalog() member funcs; bumpmaster, dolldrop -begin checking dolldrop sizes chkd_pull_g(); dolldrop pull_json_drop(); bumpmaster -add sz_match(); bumpmaster -add chk_dropsizes(); mailstop_util -add set_sz(), get_sz() wrappers; mailstop_util -add 'sz' field, Dropdata; mailstop_util -mv to fs::path filenames; general >rw_bumpmaster-v220312.tar.xz.sha256sum 57018697c25c6f137505e71aed2fe4f7d88169e8e1fa02fc487713ab6316cee6 *rw_bumpmaster-v220312.tar.xz >backup drop https://files.catbox.moe/9rrvst.7z
Open file (74.36 KB 600x471 Chii.600.761218.jpg)
>>15448 I'm still learning Blender but I think it's a good idea. >>15514 Nice update Chobitsu!
>>15516 >but I think it's a good idea. I do too. While we can probably manage a reasonable degree of good outcome with enough effort put into the RW Action! set of libraries, the simple fact is that Blender is over 25 years of focused effort now, and also has an annual budget of millions. It's just good sense IMO. >Nice update Chobitsu! Thanks! Yes, I feel like we have reached up and over and have scaled onto another plateau with this one. Feels good. Hopefully, we'll be able to move on from Bumpmaster after not too many more Caturday drops tbh. Cheers.
RW Foundations Caturday drop : v220319 edition Can we all just agree that Catgrill Meidos make the best servers!? This spin we did a little cleanup on the console's output text display, and gave error-detection on the curl library's connections a bit of a think. We also began a new sub-library RW Cooker for the rw::meido namespace. Robowaifus doing our Cooking and Cleaning for us goes together right well don't you think Anon? :^) === So, we have a new function in RW Bumpmaster for this drop fmt_msg(). Till now, we've simply let the terminal handle text wrapping (with predictable results.) If you look at a terminal all day this kind of thing is just par for the course and no big deal; you get used to it. But even so, it still would be nice to have slightly better formatted output. Therefore: >bumpmaster.cpp snippet auto Bumpmaster_b::fmt_msg(std::string const& msg) -> std::string { stringstream iss{msg}, oss{}; for (string line; getline(iss, line);) { // read lines in one at a time // if (line.length() > msg_width_lim) { // this line needs linebreaks // transfer line string to a sstream stringstream liness{line}; line.clear(); // parse sstream into multi-lines // string word{}, curr_line{}; while (liness >> word) { // one whitespace-delim'd word at a time if (curr_line.length() >= msg_width_lim) { // we have a linefull, save line += (curr_line + '\n'); curr_line.clear(); } curr_line += (word + ' '); } curr_line = curr_line.substr(0, curr_line.size() - 1); // rm final space line += curr_line; // final line pickup for the multi-line } oss << (line + '\n'); } // rm final newline auto res = oss.str(); res = res.substr(0, res.size() - 1); return res; } This code first reads the JSON source message text passed in by the caller, then line-by-line reassembles it for the function's output. 'Why do this' you ask Anon? Good question! :^) For any lines that are under the width limit, they are just appended right back over to the result string. But for the lines that are over the width, they get some attention to wrap them around to fit. First we convert that line over to a stringstream liness. Now, C++'s std::stringstream 's have a nice overload on the 'get from' operator >> thanks for the name Bjarne! such that it will parse on any white space when the target type is a std::string. It will also return a bool indicating if any content was in fact parsed out. Putting all that together allows us to write this rather elegant statement: while (liness >> word) { ... }. Hard to get much cleaner than that tbh. We check if the working scratch string curr_line is at or past the width limit, and save it out if so then reset it for the next go-round. Otherwise, we append the next word onto it, adding that space char back in along the way as well. And so it goes; word-by-word, line-by-line, till the entire input message string is reassembled into a new output message string. Seems tedious? Indeed it might be for you or me, but the strings library doesn't care lol. Our only concern as engineers is correctness & efficiency. Since these stringstream overloads are based on STL template classes, our optimizing compilers will munge together all these operations down into a quite efficient set of machine instructions. And a very nice thing about the C++ strings library -- and particularly it's streams libraries -- is that they just werk. That is, they have sane defaults by, well, default. Always use std::string first and foremost for character array work when allowable on your system's platform. You can thank me later Anon. BTW, that msg_width_lim variable is a const for the class (set at 100 currently, but you can change it to w/e you want.) >bumpmaster.hpp snippet inline const unsigned msg_width_lim{100}; OK, so we have this handy new formatting function and now here's what the post data printout statement looks like: >main_bumpmaster.cpp snippet cout << '\n' << setw(33) << setfill(' ') // prt posts data << "r " << (p_idx + 1) << "\n ------------------------------------\n" << setw(8) << setfill(' ') << p.id << " : " << p.date << "\n' " << bump.fmt_msg(p.msg) << " '\n"; You might notice that new function call wrapping the p.msg 's output. Yep, that's the one. Well, it looks like some big project things are afoot here on /robowaifu/, lads. I hope you're all well-secured & ready for the ride! :^) Cheers. === >version.log v.220319 --------------- -enable all try/catch blocks, 'try_X()' funcs; mailstop -add disp_err() utility func; dollnet -add msg_width_lim const var; bumpmaster -add fmt_msg(); bumpmaster -begin Cooker; rw::meido >rw_bumpmaster-v220319.tar.xz.sha256sum 0b3cb26b114d967162b75588b926a6f40daf384d3d39f01cc6a26e3d63245804 *rw_bumpmaster-v220319.tar.xz >backup drop https://files.catbox.moe/p1qnqj.7z
>>15516 BTW I meant to thank you earlier for that excellent Chii Anon, but I just forgot. Thanks! :^)
>>15658 An exporter plugin for blender would be very helpful since most robotics software does have some kind of model simulation feature these days for testing programming instructions. You would have to be capable of automatically generating a target armature for the robot model you are testing with the program.
Open file (607.36 KB 2340x3500 Chii.full.400120.jpg)
>>15656 >Can we all just agree that Catgrill Meidos make the best servers!? I have to agree! I like how you're handling strings Chobitsu, I don't really get C++ but, it seems like it'll help with legibility of retreived text. Thanks for your detailed write up. Thanks for your continued work.
>>15660 >An exporter plugin for blender would be very helpful since most robotics software does have some kind of model simulation feature these days for testing programming instructions. It's a great platform today for everything 3D basically. Surely it can be a help for things like our project's visualizations etc. >You would have to be capable of automatically generating a target armature for the robot model you are testing with the program. It's actually rather more complex tbh. 'Automatic weight-painting' would also be needed as well, and some form of rigging system too. That is if an Anon was going for an entirely automated, turn-key exporter system. Something you could sell for a few thousand a pop, for example. We're going for something much simpler to start off with ofc. >>15661 >I have to agree! Heh. I like the fact they give a subtle nod to Chii in fact, being a cute animu catgrill. :^) > >I don't really get C++ Well, as we mentioned IIT's OP: < "...I'll use this thread as a devblog and perhaps also a bit of a debate and training forum for the many issues we all encounter, and how a cute little fairybot/moebot pair can help us all solve a few of them." I'm happy (eager even) to help Anons learn the language. AFAICT, this is a critical-skills issue for us all, and we shouldn't allow just one anon to be skilled in it. Many of us should be, if possible. In this case I think it's definitely possible. If you want to learn the language itself, then I simply can't recommend a better resource than Stroustrup's college freshman textbook PPP2. There literally isn't a better programming leanring textbook for the serious student in existence anywhere (regardless of language) (>>4895) If you actually care to learn, then I myself am probably a good resource. I can explain in as much detail as necessary probably just about anything with the language you might be wondering about. We can start simply by going through every.single.thing. for the code contained in this post (>>15656) until you (or anyone else who cares to ask for that matter) understand it clearly. For example, just to start at the beginning, is there anything in this line of code that you're even a little unclear about? auto Bumpmaster_b::fmt_msg(std::string const& msg) -> std::string { ... } If so, just ask. Remember, we all need to try and find ways to encourage others to step up to be able to take over our roles at the drop of a hat. We owe that as leaders to the community at large. Cheers, Anons.
Catgrills. Meidos. Delivery trucks. Imagine the possibilities Anon. :^) Please send catgrill meido pics Anon, running short! :^) Starting with this drop we'll be supporting multiple projects simultaneously, therefore it seems misguided to keep calling these drops 'Bumpmaster WIP'. Accordingly, we're moving to the generic Caturday drop as the subject, and the super-project's name will now simply be RW Foundations'. An important benefit of rolling out the projects together like this is that it significantly decreases the likelihood of any library incompatibilities across them. It's not perfect, but it'll do for now. RW Pandora So, the big splash for this drop is the addition of RW Pandora to the lineup. For now it's simply the basic skeleton, but it's already the straight beneficiary of all the work that has gone before and is immediately up to speed with the current stable, with full access to everything available so far. Here's the program's current diagnostic output on my box: build/pandora entering main()... Pandora checks out A-OK! - Pandora.0 addr: 0x7ffd7f1bd328 pandora.animeyes() - arigato_animeyes.1 addr: 0x562e7861b440 pandora.atashi() - arigato_atashi.2 addr: 0x562e7861b5d0 pandora.bones() - arigato_bones.3 addr: 0x562e7861b730 pandora.curator() - arigato_curator.4 addr: 0x562e7861b860 pandora.dollhouse() - arigato_dollhouse.5 addr: 0x562e7861b9e0 pandora.electro() - arigato_electro.6 addr: 0x562e7861bb50 pandora.face() - arigato_face.7 addr: 0x562e7861bc80 pandora.gears() - arigato_gears.8 addr: 0x562e7861bdb0 pandora.hand() - arigato_hand.9 addr: 0x562e7861bf70 pandora.hearsay() - arigato_hearsay.10 addr: 0x562e7861c0a0 pandora.meido() - arigato_meido.11 addr: 0x562e7861c1d0 pandora.shell() - arigato_shell.12 addr: 0x562e7861c300 pandora.graphicom() - pandora_graphicom.13 addr: 0x562e7861c5c0 ...leaving main() This is exactly as predicted for this stage of development, so yep good to go. === For anons who may be wondering where these things come from, let's dip into C++ class hierarchies a bit again, be patient if you already know this stuff. RW Pandora is an RW Arigato-class robowaifu, so it's part of that namespace and directly inherits from that class too: >pandora.hpp snippet namespace rw::arigato { class Pandora_b : public Arigato { public: Pandora_b(); // default ctor explicit Pandora_b(std::string const& handle); // tag-parm'd ctor }; ... } // namespace rw::arigato That ': public Arigato' bit is what does the trick. Here's a portion of RW Arigato's code: >arigato.hpp snippet class Arigato : public Arigato_b { public: ... inline auto animeyes() const -> Animeyes& { return animeyes_; } inline auto atashi() const -> Atashi& { return atashi_; } inline auto bones() const -> Bones& { return bones_; } inline auto curator() const -> Curator& { return curator_; } inline auto dollhouse() const -> Dollhouse& { return dollhouse_; } inline auto electro() const -> Electro& { return electro_; } inline auto face() const -> Face& { return face_; } inline auto gears() const -> Gears& { return gears_; } inline auto hand() const -> Hand& { return hand_; } inline auto hearsay() const -> Hearsay& { return hearsay_; } inline auto meido() const -> Meido& { return meido_; } inline auto shell() const -> Shell& { return shell_; } ... }; Hopefully you spot the similarity of these member field's names for RW Arigato, to the diagnostic above for RW Pandora. Yep, that's where they all come from; pandora inherits them from arigato. To pickup that RW Graphicom member, here's the declaration in the derived RW Pandora code: class Pandora : public Pandora_b { public: ... inline auto graphicom() const -> Graphicom& { return graphicom_; } ... }; That's it. Anon, that accounts for each item that currently is part of RW Pandora's declaration. This will naturally grow as development begins in earnest for it. Please explore the codebase, and ask any questions about things ITT, we'll be happy to respond. Notice: We'll be putting Caturday drops on hold through the month of April. All things being equal, the plan is to pick everything back up on May 7th, and we'll dive back into things full-charge with some code cleanups and reorganizations for RW Bumpmaster as we press in towards our first GUI code for the Foundations. I hope things are going well for you Anon. Stay encouraged, and keep your eyes on the prize. We'll all get there, just keep moving forward. :^) Cheers. === >version.log v.220326 --------------- -pandora gets member; graphicom -add 'pandora' decl/defn files; rw::arigato -add pandora build configs; meson.build -add 'main_pandora.cpp' -begin Pandora demo project >rw_foundations-v220326.tar.xz.sha256sum 8441a9dc9a67406767cf504a496d5a090e8ecd04b0c45495c14e223b85f152c0 *rw_foundations-v220326.tar.xz >backup drop https://files.catbox.moe/smc6ey.7z
Catgrills and Meidos and /comfy/ warm cabins 🎶 These are a few of my favorite things 🎶 :^) Well well, here we are, and it turns out that May has finally arrived! Hope you had a good April Anon. So, we've been doing a few demo tests here and there over the course of the overarching project so far. Mostly these are meant as 'throwaways'; little design sketches meant to explore different coding concepts. The project demo work we left off with a month ago here was thus. However turns out it's been such a regular part of our daily-driver routine since, that we decided just to keep it! Announcing that RW Pageone will now be a permanent part of the RW Foundations stable of projects. RW Bumpmaster is still very much on the table, but it's a more expansive project with fairly different goals. Pageone has proven handy as a low-impact way simply to read the text of different IBs. Crude as it is, little-by-little it's gotten better with time. Maybe our robowaifus will also be reading Page 1's along with us some day soon Anon! The intention is the project will remain as a terminal-only application. In fact it's likely to change only little outwardly from it's current incarnation this drop (with the exception of better error-handling on bad connections/missing data). A user-editable 'IB URI listing' text input file should also be available at some point (hopefully soon). Additionally, once Bumpmaster's IB JSON field abstractions are on par with BUMP's (basically allowing us to archive any major IB software) the plan is to also add that into Pageone as well. We hope you'll find this little utility useful too Anon. === The biggest change this drop is we are finally saving out the various JSON dolldrops (catalogs + threads) into their own, named, sub-directories within the ./dolldrops/ folder. This is better organized, and will also make RW Waifusearch integration simpler when it's time comes along too. Also, we pieced together what we think is a reasonably-functional mechanism to manage the networking library curl's (so-called) 'easy objects'; for connection-reuse out to any given IB server. This should make the load on remote servers somewhat less, and the bandwidth usage slightly more efficient for both parties. >"But, how did you manage this?" you might ask? Well stay tuned Anon. :^) So, the 'software star' of the day for this particular Caturday drop is the C++ standard library container std::map<> . https://en.cppreference.com/w/cpp/container/map map 's provide access to sorted, key:value pairs (kind of like JSON fields). You can use any type for the key, but strings generally are best. The value field can also be any type at all; and in this case we're interested in storing an associated curl easy object so that we can get connection-reuse across different dolldrop/dollnet pull requests. But we need a way to locate it repeatedly, and that's where the string comes in: it's simply the IB's site name itself (eg, "alogs.space"), and works quite well as a map key. Therefore, within the base class Dolldrop_b we've added a map-type member field: >dolldrop.hpp snippet map<string, curl_easy> site_conns_; Notice the two items in those angle brackets: string, and curl_easy ? The string type is the key, and the curl_easy type is the value for this specific map. Since we always know the site's name for any dolldrop pull, we just use it in the search and get back a reference to the stored curl connection itself. We created a simple function that goes and finds that curl object inside the map (or makes a new one if needed) and returns it: >dolldrop.cpp snippet auto Dolldrop::get_ib_curl(std::string const& uri) -> curl_easy { auto const& [site_nm, board_nm] = parse_ib_uri(uri); // obtain the previous curl_easy obj for this site if found, else create new curl_easy conn; try { conn = site_conns_.at(site_nm); } catch (out_of_range const& e) { conn = get_curl(); site_conns_[site_nm] = conn; } return conn; } This code first parses out the site name to be used for the map lookup. The .at() member function is range-checked (safety, etc.) and throws if the element isn't in the map. We use this approach for the first phase of the lookup, b/c we don't want to actually instantiate a new curl_easy object until we need to. If the element isn't found inside the map, then a new one is created, and the [] member operator is used to insert it into the map (for the next time around). The function then returns the retrieved/created curl_easy object specified to that URI. That's all there is to it, and it's handy to use from wherever needed inside Dolldrop. Well, we hope you are making steady progress towards your robowaifu goals Anon. Keep the faith and work your butt off! Together, we'll all make it. :^) Cheers. === >version.log v.220507 --------------- -add curl connection-specified pull call-chains; dolldrop/dollnet -add get_curl() call-chain; dolldrop/dollnet -begin mv to curl connection reuse out to IB servers; dolldrop/dollnet -add 'droppath'-specified dolldrop pull call-chains; dolldrop/dollnet -add preflight_boards(); bumpmaster -begin mv to named dolldrops within site/board directories; bumpmaster -migrate mailstop features over to dolldrop; dolldrop -migrate mailstop_util features over to dolldrop_util; dolldrop -begin mv of Mailstop elsewhere and out of rw::dollhouse namespace -add 'dolldrop_util' decl/defn files; dolldrop -add complement of dolldrop wrappers; bumpmaster -mv parse_ib_uri() over; rw::util -mv to fs::path parms, rd_json_file(), wrt_json_file(); rw::json -tmp clear main_bumpmaster.cpp code; using pageone as it's current dev focus -add 'main_pageone.cpp' -add pageone build configs; meson.build -begin Pageone demo project >rw_foundations-v220507.tar.xz.sha256sum 72dc81265529fe19e229e07baec4f3c64707fc41aaa92404eeb01c3e67036220 *rw_foundations-v220507.tar.xz >backup drop https://files.catbox.moe/siytza.7z
Edited last time by Chobitsu on 05/08/2022 (Sun) 17:39:22.
>>16119 Having waifus reading Page 1's with us sounds like a nice idea! The map function is pretty cool, I like how you're using it.
Open file (1.97 MB 2322x4000 98180595_p0.jpg)
>>16119 Kek, I had too many chars in my droppost to even add my traditional edit comment exactly 6144 heh :^), so I'll do it here instead. >=== -minor fmt edit -minor tech edit >>16122 >pic LOL. How did you get into my secret lab Anon!? :^) >Having waifus reading Page 1's with us sounds like a nice idea! Yes, it will be a glorious day when we can all regularly shitpost along with our waifus Kywy. Onward! >The map function is pretty cool, I like how you're using it. Thanks! I try to consolidate functional abstraction into simple little modules when I can. Makes maintenance much easier later on. The C++ map 's flow-control approach isn't that great IMHO, but I understand why it's being done that way. OTOH, it's efficiency as a logarithmic Red-Black tree is nearly optimal. Very close to the metal. >tl;dr You play the hand you're dealt. And in this case (both with C++ and with map<>) it's well worth it! >>16130 >In the readme, say what programs are included in the repo and what they do. Great idea ChartTard! I'll plan to add that in as a permanent part of the readme's during the next Caturday drop. Also, welcome aboard Anon! :^) >=== -add missing quote -fmt edit -add add'l cmnt cmnt
Edited last time by Chobitsu on 05/08/2022 (Sun) 17:06:22.
>>16139 I don't do much C++ programming so I haven't looked too much at RW Foundations beyond using Bumpmaster to archive the board but I look forward to seeing Sumomo's World. I dabbled before with making a 2D visual waifu in Godot >>9025 which would be pretty easy to reimplement in C++ with raylib-cpp. Raylib has much better support for skeletal animations now than it did a year ago so you can animate stuff in Blender, export and play it. Raylib can also be compiled to WebAssembly for webpage waifus. There's also Live2D but their library is closed source and their editor is software as a service that doesn't support Linux. I plan to port my TTS systems to C later this year which could be plugged into Sumomo and of course GPT-2 is in the works if you're interested in playing with that. I'm not really sure how else I could contribute to the project. Possibly next year I plan to port RoBERTa too and that could be plugged into Waifusearch so searching for something like 'chatbot' would also bring up similar posts talking about 'conversational AI' and 'natural language processing'. Something else I use a lot are WebSockets to communicate between the web browser, Python, Godot and other applications. It would be desirable to have a library in RW Foundations for easily sending and receiving various types of data across the net and between programs. My visual waifu for example connects to three different WebSocket servers, one for text generation, one for TTS and another for translation using selenium to access DeepL. It makes it much easier to test different code and models without having to unnecessarily reload GBs of data each time I make a change and the visual waifu continues to work even while any of these functions go down.
I threw this together from example code over a couple days. It combines python TTS, Speech recognition and Chatbot libraries into a talking, speech-activated chatbot. It's not very good out of the box (Sphinx is pretty jank and I haven't tried training the chatbot), but it "works" with minimal effort and we may be able to improve upon it.
>Hopefully something by next week edition. So, we are taking a hard look at dropping one of the dependencies for RW Foundations. Namely the curlcpp library. While the library is pretty nice, it's a bit over-sized for our simple needs in Dollnet/Dolldrop currently. During the effort to improve our error-handling/correction it became apparent that often just dropping straight down to the curl C itself help get around some limitations with curlcpp. This realization naturally led on to >"Well, can't we create our own wrapper for continued/improved safety+security using curl?" Accordingly, we're taking a serious look at doing just that. I'd estimate we're ~1/2 of the way through that, so probably not too unlikely we could have something by next Caturday, stay tuned. === Also, we'll probably drop back to a 2-week(ish) cycle for Caturday drops. This will help with my own personal schedule, and is more likely to result in better code in general I think.
>>16194 >raylib-cpp Thanks! I had looked into it a good while back, but it didn't seem right for me then. I'll have a look at the newer versions. From my initial glance at the github, it looks to be quite nice. >I plan to port my TTS systems to C later this year which could be plugged into Sumomo and of course GPT-2 is in the works if you're interested in playing with that. Absolutely. We certainly will need both these needs with the Sumomo's World! demo project, and I can't think of systems I'd rather use. >I'm not really sure how else I could contribute to the project. I'm just glad you're sharing your hard work with the /robowaifu/ community itself, RobowaifuDev. If you'll allow us to simply integrate your systems into our own, then that would be a tremendous help. We'll follow your lead on this, since our licenses differ so significantly. As I've made very obvious to everyone on the board, I mean to support small-businesses trying to succeed at creating waifus. I see the permissive license as the literal key to success for these thousands of private Anons. >Possibly next year I plan to port RoBERTa too Neat. That certainly would be a big improvement over Waifusearch as it stands. >WebSocket servers I can't make any predictions on the timeframe, but we've decided to look at a prototype effort using WebSockets. It will need to be provably safe/secure according to the offlined, sneaker-netted basics in this area we're already working towards. But if it does prove so, then even the IPCnet effort may benefit in some ways from it. Very nice to have you stop by the thread Anon! :^) Cheers.
>>16230 Thanks Ricardo! As we discussed elsewhere, having a simple-to-use Python API for our robowaifus is a great idea. I'll make the attempt sometime soonish to build your project and see if I can get it working. Cheers.
>>16230 >>16238 I used pipenv to get the virtual environment for this set up, here's the pipfile (specifies dependencies)
>>16248 Thanks! That's exactly the kind of thing a relative neophyte with Python needs to manage the process Anon. I hope to have a machine ready to use sometime in the next week or so. Cheers.
>Python also has a serial library https://devtut.github.io/python/python-serial-communication-pyserial.html#initialize-serial-device We could use this to send commands from a PC to an arduino. That way, we won't have to use a raspberry pi for GPIO.
>>16296 Yep. Particularly during these early prototyping phase years, using a USB-based comms buss network might prove feasible, as another Anon mentioned. Long-term however, we'll need something more secure. The issue is that USB hardware typically performs DMA buss-mastering. Ostensibly, this is to optimize the efficiency of the data transfers, and in particular the latency. However, any component that does DMA represent a pretty severe potential security and stability threat. The reason is obvious from the very acronym itself: >Direct Memory Access To wit: the device can conceivably take over unauthorized sections of memory, roughly by design. But thanks for the suggestion Anon, I think it's a good one to try and reduce component counts and costs! :^) >=== -add the single word 'potential' -add greeting
Edited last time by Chobitsu on 05/18/2022 (Wed) 04:36:30.
Catgrills & Meidos, first choice of refinement and taste everywhere! :^) Well good news Anon, our mini-project to eliminate the curlcpp library dependency for RW Foundations is proceeding apace. For the RW Pageone project, we were able to rm its necessity. We're leaving the curlcpp lib in place for now, but this should be the last version to include it. In addition we also managed to get the basics of parallel downloads using a single thread kickstarted and working for this drop too. So-called curl-multi was always on the agenda, but we've begun working with it at last. If you ever use any explicit download tools regularly, then you know how important simultaneous connections can be for efficiency's sake. And curl can actually scale far beyond our likely-scenario needs for our robowaifu's RW Dollhouse systems, etc. But for now it's rather a nice improvement for this Caturday's drop. I think you'll find that Pageone is pretty snappy now. :^) === So, one of the nice things about using C is that you're quite close to the hardware. OTOH, one of the bad things about using C is that you're quite close to the hardware. :^) Plainly, the benefits outweigh the detriments here, but you have to pay close attention to a) what you're actually doing not what you think you are, and b) stuff you're not even thinking about as a developer that may be involved some way or other. I like the language a lot, though it can be very tricky. I'm not particularly-skilled as a C dev tbh. In fact I much prefer C++; we can still get 95%+75%+ of the general efficiency of C, and don't have to give up on the many benefits of abstraction the language affords us. Some circumstances even allow C++ code to run significantly faster than similar C code -- particularly if developer time is taken into the cost consideration. One of the initial hurdles a beginning programmer faces with C is understanding that so-called 'variables' are in fact just fixed blocks of sequential RAM addresses. That's it. No special sekrit sauce Anon. Just you and those 8 bits of 1's & 0's or billions of 1's & 0's, as the case may be. They don't move around. They don't know that they are in essence nothing more than just a glorified set of lightbulbs & switches. OTOH this also means you can do some pretty weird and cool things that you might not expect to be able to if you learned another programming language first. Now the close relationship between the two languages, and in particular Bjarne Stroustrup's adamant insistence that C++ remain backwards compatible with C (at some cost), allows us to write code like this: >dolldrop.cpp snippet /** Append a @c curl -specified memory block to a target string * * Writes an array of @a num_elems count of elements, each one @a elem_sz in * size, from the block of memory pointed to by @a addr, out to the current * position in the @a o_strm stream (the end of a @c std::string, in this case). * * @param[in] addr pointer to memory array of elements to be written out * @param[in] elem_sz size in bytes of each element * @param[in] num_elems number of elements * @param[out] o_strm pointer to output stream * @return number of bytes written * @note: this is intended as a callback function for a curl handle's use */ auto wrt_str_cb(Address const addr, size_t const elem_sz, size_t const num_elems, std::string* const o_strm) -> size_t { // auto const mem_blk_sz{elem_sz * num_elems}; try { o_strm->append(static_cast<const char*>(addr), mem_blk_sz); } catch (exception const&) { // -"If an exception is thrown for any reason, this function has no effect // (strong exception guarantee). (since C++11)" return 0; } return mem_blk_sz; // https://en.cppreference.com/w/cpp/string/basic_string/append } I imagine a Pure C Anon shudders in utter disgust at such horrors. C++ strings! Lol please bear with us. :^) So w/o going too much into it, one of those 'weird' things you can do is write data incrementally out to a std::string variable, rather than a FILE stream. Pointers are literally the greatest invention of nerds. Remember those immovable 8 bits? Yep, cheap pointer tricks are ways to have fun and profit using nothing but bits. curl 'chunks' up data, and then calls an attached, user-definable, so-called 'callback' periodically to let you do w/e you want with that data. In this case, we're storing it into a string (which just so happens to be inside one of those 'open-ended containers' [std::vector] we spoke of earlier ITT). This allows us to read out the data from curl networking facility with safety and security that's rather more tricky when using straight C. Particularly with exceptional states (see that try/catch block?) Anyway, that's enough for now. But this code is very much a part of our parallel downloads improvements for this drop. Please have a look at the actual codebase itself; just ask if you want to know more. Well, I hope you are doing well Anon. Keep pressing in towards the prize. Together we're all gonna make it Anon! :^) Until next time then, cheers. === >version.log v.220521 --------------- -optimize thread reads via 'pulled cats' find_if() filter; pageone, bumpmaster -add 'chk_thrds' flag, to optimize on thread checks; pageone, bumpmaster -add wrt_str_cb(), cfg_hdr_hdl() utility funcs; dolldrop -add pull_hdrs_multi_g() member func; dolldrop -add chk_hdrs() member funcs call-chain; dolldrop -add chk_pull_cats_sh() member func; bumpmaster -add top_bump_thrds_sh() member func; bumpmaster -begin mv to parallel curl transfers, w/ partial error corrections -begin mv to rm 'curlcpp' library dependency -add 'show_prog' flag parm, various; dolldrop/dollnet -disable dolldrop() public member func, external access unneeded; bumpmaster >rw_foundations-v220521.tar.xz.sha256sum 65105c5804b89edd01bf92aaa0c7865c480aec4c1cf415b5637c335d0dba8b55 *rw_foundations-v220521.tar.xz >backup drop https://files.catbox.moe/mugvk3.7z
>>16329 Thanks Chobitsu, your work continues to be great!
>>16329 >So, one of the nice things about using C is that you're quite close to the hardware. OTOH, one of the bad things about using C is that you're quite close to the hardware. :^) Plainly, the benefits outweigh the detriments here, That's because C was made as an alternative to machine code, which was the language that directly ran most ancient machines before the dawn of the personal computer. It looks like matrix code to any human being and C is far less scary overall. Its supposedly not uncommon to have some programmers mix C and C++ or C++ and C#. I was still not any closer to finding out what the hell any of this is supposed to do from the thread itself and found a way around the whole "orbital space docking procedure" as described and narrated in the readme. I am just putting a sense of humor to my frustration here :) Extracts tar.gz: https://extract.me/ If you want to run it as intended and get the code to run, THEN follow the readme he includes in every drop. It irritated me to no end how they put so much effort towards these but make them impossible to even look at without going through so many extra hoops.
Edited last time by AllieDev on 05/21/2022 (Sat) 00:18:55.
>>16331 Thanks! It's actually better than I planned for at this stage (performance-wise). Sadly, this is all taking much longer than originally hoped. Que Sera, Sera. Just keep moving forward. >>16332 Heh, truly apologize about that AllieDev. It's not generally my intent to 'complexify' things, they just sort of turn out that way all by themselves in this life. :^) Obviously, you being the team leader for one of the included projects in RW Foundations means it's a high priority for you to be able to closely follow along with things. Have you been able to actually build+run the project yet? Pandora or Pageone, say? One thing I think would greatly help you along with our current dev track would be to get comfortable with a Linux distro. Might I suggest Ubuntu 22.04 LTS? https://ubuntu.com/download/desktop Cheers.
>>16329 Do you have a git repo on some git hosting site for sending patches to? I looked at the meson.build and the most obvious things I see are: - `cpp_.find_library('curl')` should be `dependency('libcurl')` so meson's full dependency search features are put to use. The same might true for the others, but they don't provide a pkg-config file, and I haven't looked at the details yet. Most immediately, using find_library() is breaking the build on any system where the base directory for packages isn't / (MinGW, BSD) right now. - You could enable LTO for a free small performance/filesize/memory usage improvement. Although I see you have .cpp files #including more .cpp files, which has the side effect of doing the same thing as LTO, but is probably a bad idea. - the add_project_arguments() call should probably be removed, users can add compile flags by setting `cpp_args` with meson's -D flag from the command line. - `meson setup build && meson compile -C build` is the modern way to build a project in Meson. The main difference being that it works with all Meson backends, not just Ninja. That whole block of comments at the tail of the file should probably be moved to a README.md. Those are simple enough to be communicated, but there's more. It shouldn't be too hard to rework the meson.build to allow specifying which commands to build through meson options, and then only ask for the required dependencies of whatever is to be built. srcs_all should probably be a library and then the library should be depended on by the commands, possibly the commands could be split into separate projects, and any parts of srcs_all that are only used by one project could go into the relevant project. Also, from skimming the C++, I see that you unnecessarily add newlines to puts() calls. puts() is defined to print a newline after the string it receives. Additionally, the proper way to print a newline is putchar('\n') not puts(""). Windows' libcs actually translate that \n into a \r\n.
>>16407 >Do you have a git repo on some git hosting site for sending patches to? No. I'm generally opposed to the Globohomo Big-Tech/Gov in general, and pretty adamantly opposed the FANGS groups and their financiers. OTOH, I truly like using git all day, erry day. Kywy asked me as much in your query, and I suggested that he himself could manage our repo for RW Foundations if he cared to, as he was already developing one for the MaidCom project (>>14530). >tl;dr I'm actually more comfortable using tarballs and using /robowaifu/ to distribute our work at this stage. OTOH, it's a good idea. Everything we're doing with this project is permissively-licensed. Just to spitball the idea, might I suggest you create your own version of the project, put it on w/e git hosting site you'd care to, and (re)write anything/everything in any fashion you care to whatsoever? A) I've always, always promoted the idea of numerous robowaifu projects going, and B) You can do as you see fit at your own probably lightning-fast compared to me pace. I won't slow you down for your own work, and I can learn from everything you do. Seem reasonable Nagisa? BTW, I'll look into your other points as well. I simply wanted to drop you a reply while I was still here today. Cheers.
>>16408 There are many of those git hosting sites. gitlab, gitgud, bitbucket, sr.ht, one of them is bound to be good enough. Version control and some medium for collaborating are important.
>>16407 >- `cpp_.find_library('curl')` should be `dependency('libcurl')` Done. As you suggest, attempting it with both others gave me an error (eg): ../meson.build:39:0: ERROR: Dependency "fltk" not found, tried pkgconfig and cmake >- You could enable LTO for a free small performance/filesize/memory usage improvement. Done. >- the add_project_arguments() call should probably be removed, Yep, it will be on any production-release. It's there ATM simply to give me quick-access during dev work. >- `meson setup build && meson compile -C build` is the modern way to build a project in Meson. Both done. >- That whole block of comments at the tail of the file should probably be moved to a README.md. Done. >srcs_all should probably be a library and then the library should be depended on by the commands, possibly the commands could be split into separate projects, and any parts of srcs_all that are only used by one project could go into the relevant project. Probably a good idea, but tbh I don't see a clear way to approach it that won't make things harder to reason about for us ATM. Any specific concrete examples to offer Nagisa? >Also, from skimming the C++, I see that you unnecessarily add newlines to puts() calls. Actually, every one of the 'extra' newlines is intentional; for output display formatting. >Additionally, the proper way to print a newline is putchar('\n') not puts(""). Done. >>16427 >There are many of those git hosting sites. gitlab, gitgud, bitbucket, sr.ht, one of them is bound to be good enough. No doubt, Kywy has chosen Gitlab (and I have an account there too). >Version control and some medium for collaborating are important. I use both: -Git -/robowaifu/ Won't you please consider taking my suggestion for your own repo? Just use my latest drop ITT, make your own repo, then I can both send you PR for any new work I have, you'll have strict control to do w/e you know to be better approaches, and I can clone your work and diff them to learn step-by-step at my own pace. >=== -fix missing crosslink -edit LTO resp cmnt -edit 'putchar('\n')' resp cmnt
Edited last time by Chobitsu on 05/24/2022 (Tue) 13:00:40.
Open file (716.84 KB 500x281 shaking.gif)
Hello, newfag here. I have been lurking here for a bit. I am new to programming and C++ in general, so an experienced programmer would probably get a stroke looking at my code, but it seems to work and that is all I am looking for at this point. Today I finally got back propagation working on neural network library in C++ that I was working on. So far I have created a CSV file parsing, as well as matrix operations library using std::vector. The neural nets use matrix algebra to compute the outputs. It can initialize a random neural network with weight between -1 and 1 using 2 vectors, 1st to determine how many neurons in each layer, 2nd to determine the type of neuron in each layer(different activation functions), as well as Nx the number of input variables. There are also functions to scale input and output data between 0 and 1 for faster input. It I have finally got the 1st order training method of Gradient descent to work, with OK results, the training dataset isn't too large and IDK if I am using the correct network layouts, but the outputs seem somewhat on the mark. I need to learn a lot more about layouts of neural nets. The next step is a lot more testing, and adding the more efficient 2nd order methods, which will involve computing the hessian and jacobian matrices. (RIP my brain) After I get these 2 methods working, and then get into actual chatbot learning to utilize these neuralnets for my waifubot. I will post updates if that is OK. My test folder: https://anonfiles.com/[redacted]/test.tar_gz === Note: It's bad form generally (and especially on IBs) to include anonymous precompiled binary executables inside a drop, Anon. Give it a shot making another drop that's just the source code, build files, and dataset files. Please post that instead, and I'll fix up your post here with the new droplink. Cheers. >t. Chobitsu >=== -add/edit admonition cmnt
Edited last time by Chobitsu on 05/24/2022 (Tue) 22:42:37.
>>16408 Sorry, but it's better if you create the repository, you're the author, and I'm not looking for more responsibilities.
>>16451 Understood. Well, as I indicated ATM /robowaifu/ is my 'repository'. It certainly affords us a reasonable degree of communication. If you can find some way to dist + push patches up to catbox or some other file service, I'm sure we can get by.
>>16455 Should be doable with any of a git hook, gitlab action, or meson target. I've done tangentially related stuff but not this in particular. Either way, I'm already working with 2 dependencies /robowaifu/ uses to fix a bug and add a way to use Meson's dependency() so I already found something to work on.
>>16489 Excellent. Thanks Nagisa, your help will be very welcome! Cheers.

Report/Delete/Moderation Forms
Delete
Report