I ran into many programmers who acted more like "experts" - that is, using their status to put down others. Like making a big deal about terminology. Some programmers are like that.
I've run into one CEO who acted like an "expert" - that is, using his status to put down others. Like making a big deal about missed deadline after missed deadline over a tiny 1500 or so days late being no big deal. One CEO I know is like that.
Don't worry, the above is for the LULZ only. Carry on. Half a month to go (unless it falls on a Friday which could push things out a few millennia to 20,222).
> thus his rambling opinions on the notions of Waytools 'freeing up space in firmware' and so forth are just nonsense.
Well, maybe you can explain what is nonsense about it? Or is one of the things experts do is fail to explain things? I don't think I need to be an expert in how teams work together to figure out that if your available memory is full, it makes it much harder to fix problems!
You have written many comments remarking upon the rationale for the firmware rewrite, as if you were the leader of the Textblade dev team who devised the idea and is explaining it to everyone else. In reality you are just a fool parroting a tiny little blurb of misleading if not outright false information which was communicated by Mark as an excuse for the latest round of delays.
I do not believe the 'we are refactoring firmware to free up memory' story one bit. At best it is accidentally tangentially 1% true. It is not the real reason for the latest holdup. I could write a full page of technical explanations regarding why its not true, but its pointless. I am not dealing with rational or logical people here who will respond in good faith.
You rambled about how expanding jumps from 6 to 12 may or may not be considered a new feature. Not only was that statement ridiculous, but the implications of it are so insulting to anyone who has waited in good faith. You feigned expertise on the question of defining what a code freeze actually is, but you know nothing about the topic. Do you know how many times Waytools (Mark Knighton) has written that features were frozen, and then either he or you followed that months/years later with BS that 'because we are fixing one thing or another, we might as well add this other feature', as if there is no potential for that to cause further harm or additional delays, which is just another slap in face of anybody who believed the initial statement that they were going to lock it down and finally give people what they paid for?
To any serious professional on the outside looking in, all of these statements and behaviors and actions taken together amount to a total charade. Mark Knighton and Kahuna appear to be the core of a small group of people who are either raving mad lying crackpots, or blithering idiots, or all of the above. And every time Mark changes his story, you whistle by and parrot his BS. Its just disgusting behavior.
Nobody is going to make a logical argument that convinces you or Mark how awful you are behaving. Its futile.
The truth is, Mark Knighton has tricked a lot of people into giving him money in exchange for nothing, and then holding onto that money for 4+ years with a series of lies that exploited peoples good will, so in that one regard, he is pretty smart.
He is a good liar, and you are his parrot. Its not something you should be proud of.
oh, come on guys. I started coding for fun in the 80s on Ataris (400/800/520st in that sequence), then moved to PCs and much later had my first Mac in the 90s as they were impossibly expensive. Later I programmed my different Palm Pilots, and the last decade or so been focussed on mobile (iOS & Android) which reminded me of the constraints of the early days. Always for fun, never as a career.
Going back to the topic at hand, I coded all of this time with different levels of intensity. I can talk about different projects more than others. In the earliest days I sometimes copied code from a magazine & adapted it creating a Frankenstein, later when I understood what I was doing I recreated a v2 from scratch. Learnt a lot in the process.
I can fondly remember one failed crazy project. Remember that later magazines came with a kind of checksum code for each line that if it matched then you had no typos ? We (my older brother and I) tried to create a program that if you typed the checksums it would spit the lines for you. It obviously did not work.
But I do not think I can speak on the details without looking at the code.
Another example: I did write code to convert binary to decimal and hex and vice versa, but I can't remember the details. Now, looking at the code I remember what I did, or in this case I just took note of the posts that helped me create something that worked (even in different languages these algorithms once understood they are very easy to adapt). ie: http://www.mkyong.com/java/how-to-convert-hex-to-ascii-in-java/
In essence you are giving DBK a hard time because you guys Ericpeets & TBD (correctly) find gaps in the explanations. I admit I cannot still understand what he did (and I did use peeking and poking to read and write registers in the Ataris). If I had to vote it would have been this TBD idea later shot down:
he could be slightly misremembering or mis-stating what he did. If you stored data as binary values in registers, which he claims he was doing, then you might want to write those registers out to tape or disk, so you might set up a loop in BASIC to PEEK through all the memory addresses to obtain the values and then write them as a 'file' (in the loosest sense of that word - a data stream with some bytes to indicate end of stream) to tape or disk. This kind of task was fairly common and trivial, so I could envision him having written a simple BASIC program where he poked some data into a sequence of memory addresses, and then peeked through those addresses to store the data on tape.
The point is, what he is describing might be wrong in terms of misremembering, but he does NOT need to be an expert developer to give his idea / opinion of why the firmware rewrite is needed.
I also suspect that freeing the memory is only partially true (and it is the line given to everybody), and highly likely they have a jungle of hacks on top of hacks they need to clean up.
Later job experience managing a team developing business mobile apps taught me a lot more. Feature freeze is critical if not they will chase their tails forever and never finish.
The point is, what he is describing might be wrong in terms of misremembering, but he does NOT need to be an expert developer to give his idea / opinion of why the firmware rewrite is needed.
I could care less what Kahunas silly programming exploits were in the 1980s. Its just another thread hijack. And yeah, nobody has to be an 'expert' to give an opinion on anything, but that doesnt mean I have to be receptive to their ignorant rambling.
I also suspect that freeing the memory is only partially true (and it is the line given to everybody), and highly likely they have a jungle of hacks on top of hacks they need to clean up.
Its not about memory constraints. Jungle of hacks is probably closer to the truth, closer still would be developer turnover, loss of a developer, and/or issues with development tools due to nearly half-decade old hardware and IDE. Biggest issue is undoubtedly money. They cannot afford to finish the job - they cannot afford the developers they need - so development is nearly or entirely stalled. Hence the lie - customer orders not funding development - but Mark Knighton wants to keep all the money and so he contradicts what he told the journalist by saying that customer money is expediting or facilitating the product release. Once you tell a lie, its all lies and nobody knows what the truth is anymore.
Later job experience managing a team developing business mobile apps taught me a lot more. Feature freeze is critical if not they will chase their tails forever and never finish.
Indeed, feature freeze is extremely critical, and this is the issue that pisses me off the most. You can find 4+ years of posts from Mark Knighton claiming feature freeze at one point or another, and then followup posts after lengthy delays where Kahuna and Mark tag team on the hypothesis that a feature here or there is of no consequence because they are already busy fixing some other screwup. These people do not have a clue what they are doing. The do not have a clue what they are talking about. It is negligent and unethical behavior.
> You have written many comments remarking upon the rationale for the firmware rewrite, as if you were the leader of the Textblade dev team who devised the idea and is explaining it to everyone else. In reality you are just a fool parroting a tiny little blurb of misleading if not outright false information which was communicated by Mark as an excuse for the latest round of delays.
Wrong again. I just point out what we know - that they are rewriting to save memory. They MAY be doing any number of other things but we don't know about those yet and I've even said their statements about this or that capability being added are not clear about whether they are before or after GR.
What you do is write like you are on the dev team since you make statements that you do not have actually facts for, yet you present them as facts!
> You rambled about how expanding jumps from 6 to 12 may or may not be considered a new feature.
Yep. Depends on how they have to do it. Oh, some can say no matter what, even if it only involved changing a for/next loop to cycle from 1-6 to be 1-12 and nothing else was affected, people can fairly say it is a new feature. But I can see the alternative view.
> You feigned expertise on the question of defining what a code freeze actually is, but you know nothing about the topic.
I claimed to be an expert on this? When? BTW, if we are going to be precise, there most definitely is not a "code freeze". They gave a pretty good hint about that when they said they were REWRITING the code! I pretty sure you can do that if you've frozen the code. Now, "feature freeze" you can do, though, as I've said, it would be silly to not write an improvement at the same time they are saving space. They said jumps are now twice as fast. Is that a new feature? Could be viewed that way, but I would say it is just a happy benefit of cleaning up code.
> Nobody is going to make a logical argument that convinces you or Mark how awful you are behaving.
If you are going to make stuff up, it is best not to do it about something which is so obviously wrong. I've publicly posted about things I disagree with what they've done. That doesn't even count the private comments I've sent.
In essence you are giving DBK a hard time because you guys Ericpeets & TBD (correctly) find gaps in the explanations. I admit I cannot still understand what he did (and I did use peeking and poking to read and write registers in the Ataris).
The point is, what he is describing might be wrong in terms of misremembering, but he does NOT need to be an expert developer to give his idea / opinion of why the firmware rewrite is needed.
I also suspect that freeing the memory is only partially true (and it is the line given to everybody), and highly likely they have a jungle of hacks on top of hacks they need to clean up.
1. Let's see if I can explain just that one part in isolation to make it clearer.
There were registers that held values which would show what address a Basic program started with. There were registers that showed what address was the start of the variables which held all the data.
The Save command in Basic would automatically use that info to save the program and its data. But usually I didn't want both save. It took extra time to both save and to restore.
So I would peek into the register for where the data started and poke them into the registers which said where the basic program started (after saving the original values).
At this point, simply activating an ordinary Save would cause the program to think the start of the program was actually where the variables were and that's all it would save. When done, it would restore the original values.
2. Certainly agree with the second paragraph!
3. And the third paragraph is also possible.
One other thing, while I certainly can't remember any details about how I did the math in my program, I am pretty sure there were things I did which would make a call to a specific area of Basic. This would be done to bypass extra stuff I simply didn't need, so it would be faster. Can't think of a specific example, but if a Basic command would go through multiple options for one written command and based on other things decide where to go to next, I could bypass that initial determination by making a call directly to the part it would have ended up choosing anyway.
It's like how some languages come with a lot of baggage in libraries to cover many possibilities. That's nice if you have the space and enough power in your computer, but if you don't need most of them, by writing in MC you can leave them out which certainly saves memory, but also likely speeds things up.
> I could care less what Kahunas silly programming exploits were in the 1980s. Its just another thread hijack
Just answering questions I was asked, as best I can.
> Its not about memory constraints.
Wow, you must be on their dev team to know such things as fact! Especially after all the other things you followed that with, which would require you actually work at WT to know about.
> he contradicts what he told the journalist by saying that customer money is expediting or facilitating the product release. For someone who pretends to know what is going on, it is interesting that you have yet to figure out how this can easily work. Even though there is at least some hint of it in the article.
Vinicabrera - primarily category 1 - just a lot of migration tasks to check off, to establish feature parity. Majority are already operational now, but still a list of details to work through. Not any category 2 - No new science projects have arisen, nor any fundamental conflicts as a result of the firmware infrastructure advances. Just steadily working through it, and we do each validation as we complete each section. That stepwise process is quite important to assure we’re on solid footing. We confirm good performance of each part, so we avoid causing unexpected interactions with overall integration, so progress is reliable and efficient. You don’t want to have to backtrack and iterate, so it’s important to do the unit and integration tests right after each migration step. Because we do that testing along the way, we also get good data about performance advances. That’s how we know jumps are now about 2X faster for example. To date, it has worked out that each new section we complete has been outperforming its predecessor, while also being more optimally organized and simpler to maintain, so we are very encouraged with the results.
Vinicabrera - primarily category 1 - just a lot of migration tasks to check off, to establish feature parity. Majority are already operational now, but still a list of details to work through. Not any category 2 - No new science projects have arisen, nor any fundamental conflicts as a result of the firmware infrastructure advances. Just steadily working through it, and we do each validation as we complete each section. That stepwise process is quite important to assure we’re on solid footing. We confirm good performance of each part, so we avoid causing unexpected interactions with overall integration, so progress is reliable and efficient. You don’t want to have to backtrack and iterate, so it’s important to do the unit and integration tests right after each migration step. Because we do that testing along the way, we also get good data about performance advances. That’s how we know jumps are now about 2X faster for example. To date, it has worked out that each new section we complete has been outperforming its predecessor, while also being more optimally organized and simpler to maintain, so we are very encouraged with the results.
annnnnnnnd discuss.
R
It is reasonable, logical and good practice to implement unit testing, but just "steadily working through it" does not explain why it is taking so long. A logical question on what resources are behind the effort comes up. I could not quickly find when it was that they first announced they were starting to work on the firmware update, but it has been more than 6 / 7 months, right ?
Edit to add: POLL: Who will finish and launch first ? GRRM with his final 2 books or WT with the TB ?
I just point out what we know - that they are rewriting to save memory.
But you dont 'know' that. You only know what Mark Knighton said. Why is it when Mark says something about a release date, or a deadline for an update, or a year when the product will be released (2019? 'Yes'), you 'know' nothing for certain, but if Mark feeds you BS about his firmware, you 'know' it to be true? How do you manage that trick?
You are just full of it. You have no direct knowledge. You are parroting what Mark says. You 'know': Nothing.
dabigkahuna said: > You rambled about how expanding jumps from 6 to 12 may or may not be considered a new feature.
Yep. Depends on how they have to do it. Oh, some can say no matter what, even if it only involved changing a for/next loop to cycle from 1-6 to be 1-12 and nothing else was affected, people can fairly say it is a new feature. But I can see the alternative view.
You have practically zero knowledge about programming or modern software design, regardless of what you may have done in the 80s. When you say you can 'see the alternative view', when in fact there is not any alternative view, you are just acting like a stubborn idiot.
If some functionality does not exist in a program (12 jumps), and then you add that functionality, that is a feature. Your reference to a for/next loop - your notion of what constitutes a program in your view - is so primitive it is absurd. In modern software, one new line of code could be creating a new instance of a class which encapsulates hundreds of other lines of code, or it could be a new function that triggers a chain of callbacks, or a million other things, any one of which could introduce memory leaks or race conditions or business logic bugs or a million other problems depending on how poorly the code is designed.
A feature freeze is a feature freeze. You do not enhance or expand a feature when features are frozen. You fix necessary bugs. Nothing else. That is how thousands of successful software projects get completed on time and under budget every day. Why do you want to defend the methodology of a totally unsuccessful company like Waytools against the methodology that has made thousands of other companies successful?
> You feigned expertise on the question of defining what a code freeze actually is, but you know nothing about the topic. I claimed to be an expert on this? When?
>Kahuna post 836: >Yes, but I'm pointing out that feature freeze isn't a rock solid concept.
I said you feigned expertise. When you say 'I am pointing out [some made up fact]' you are staking a claim on some knowledge or expertise which happens to be provably false. You possess no relevant knowledge on the subject. You are just mouthing off. It is all you know how to do.
A feature freeze is a rock solid concept.
dabigkahuna said: as I've said, it would be silly to not write an improvement at the same time they are saving space.
That right there: 'it would be silly to not write an improvement...' Actually, yes it would be extremely silly when you are already 4+ years past your original deadline. You have absolutely no idea how stupid you sound when you write things like that. You have no idea what you are talking about. But you say it anyway, which again, makes me think you must be the head of the dev team at Waytools, and thus the reason why the project cannot be completed.
dabigkahuna said: They said jumps are now twice as fast. Is that a new feature?
That could have been a bug fix. You dont know. You know nothing.
It's 10 months as far a I could track it back It's tricky because a ton of WTF threads are carrying incorrect timestamps/dates now. For example this 9 month old reddit link links to a WTF post that is now only 2 months old. I know that the Reddit post is in it's correct place, and Maggie did not link to a post 7 months in the future.
In fact 2018-08-06 is when the commentary dates from and this is partly why there is a commentary at all. To externally fix dates and times of announcements so they don't slide about on on WTF. in fact on another thread on 2018-08-20 I think I riff on an original announcement for 'wired mode.'
> But you dont 'know' that. You only know what Mark Knighton said. Why is it when Mark says something about a release date, or a deadline for an update, or a year when the product will be released (2019? 'Yes'), you 'know' nothing for certain, but if Mark feeds you BS about his firmware, you 'know' it to be true? How do you manage that trick?
First, you know no more than I do yet you keep claiming your assumptions are facts!
Second, you don't see the obvious difference between the two things ("rewriting code" vs "when will it be released". It's really simple. One would reflect the present - thus no estimating. They either are or are not rewriting code. The other is about the future, which is never certain. It is the difference between someone talking on the phone while driving to meet someone who says, "I'm driving to pick you up right now. I'll be there in 20 minutes". The first part of that sentence is absolute. The second part is an expectation which may or may not happen.
> If some functionality does not exist in a program (12 jumps), and then you add that functionality, that is a feature.
And I said it can be viewed that way. But there are alternatives. To show you how you reveal it isn't so simple we have this:
dabigkahuna said: They said jumps are now twice as fast. Is that a new feature?
And you responded > That could have been a bug fix. You dont know.
What you show here is that during the rewrite, something can be improved besides the bug or other issue with the code. Which is what I've been saying. I would fully expect lots of things to be faster because of a major rewrite, even if only because to make more space, you are going to eliminate crud. So how do you say the concept of feature freeze is a "rock solid concept"? If they change the code for no other purpose but to make something faster, does that make it a new "feature"? But if you rewrite the code for some other reason, but more speed is a side benefit, that isn't? The result can be exactly the same so it sure looks like the concept is not so rock solid after all. Sure, it is convenient to think of it that way, but it doesn't seem to be the case every time, even when the resulting change is identical.
> Your reference to a for/next loop - your notion of what constitutes a program in your view - is so primitive it is absurd. In modern software, one new line of code could be creating a new instance of a class which encapsulates hundreds of other lines of code, or it could be a new function that triggers a chain of callbacks, or a million other things, any one of which could introduce memory leaks or race conditions or business logic bugs or a million other problems
My example was just to show an easily understood example.
Then you go into lots of "coulds", but even in modern software, not everything is going to lead to new problems. Nevertheless, you also just revealed a very good reason they needed to do the rewrite. Because every fix, by your standards, could lead to a host of other problems. And it would be particularly bad when you have no free memory to make the fix. That means you have to not only rewrite that portion, but other portions to make room for it. Thus doubling (or more) the chance for all those "coulds" to happen! Thanks. Good to have common ground.
> I said you feigned expertise. When you say 'I am pointing out [some made up fact]' you are staking a claim on some knowledge or expertise which happens to be provably false.
But I didn't feign anything. I just showed how it isn't as simple as you claim - and your own statements I referred to above show how it isn't so simple.
> That right there: 'it would be silly to not write an improvement...' Actually, yes it would be extremely silly when you are already 4+ years past your original deadline.
Already covered with the improved speed example. What would you say they should do when a rewrite results in faster response? Are you going to say they should throw in an artificial delay? I'm not saying they may do things which would, indeed, be feature creep. I am saying - and have said before - we don't know yet because they haven't said when some of the improvements will be included. So if they post an update saying they added mind-reading to the TB, I'd say that was feature creep - and it won't contradict anything I've said before.
> I could care less what Kahunas silly programming exploits were in the 1980s. Its just another thread hijack.
But it was none other than TBD who made my programming an issue in post 835:
> I was doing the same thing that Kahuna often proudly claims as his primary programming experience.
Of course, I was simply giving an example of how rewriting code can make things better - I wasn't "proudly proclaiming" anything, and I was not saying it was my primary programming experience. He made it up. And he followed with post 839:
> Post some of your old 'BASIC AND machine code' on Github so we can check it out.
Strange statement from someone who says he could care less!
And then I got a series of questions about my programming from another poster, which I endeavored to answer as best I could. I didn't hijack anything.
But you remember it was faster, used less memory, knew how many students it could hold at one time, and on and on. Yet you do not remember any of the details on why -- rather, you'd not say. That would make anyone wonder.
Not remembering how I did something well over 3 decades ago isn't doing something "out of the blue".
It's not me who's making it out to be "out of the blue" or even trivial:
My math was done by MC routines. At the touch of a key you could get the averages of each student in a class either with every grade counting the same or using the weighted grades if you created those. I do not recall the details now, but it seemed like a simple enough matter at the time to calculate the grades either way. Certainly no errors ever showed up when I finished. The MC also printed most of the stuff to the screen (with BASIC back then, you could see the lines being drawn one by one when you had a lot of data to display, especially if there were calculations going on at the same time).
and:
It was 8-bit. I make light of it because it didn't seem like a big deal to me. And I know it worked. Maybe the computer did some stuff I wasn't aware of. Maybe I'm taking a simpler approach than you are imagining. At this point, I have no idea what the code actually was or the Basic part either! But it worked.
Yet, you say:
I worked hard at it, figuring things out for myself, getting people to tell me how they did stuff and copying what they offered. It was a long process, first doing it in Basic and then replacing the slow parts with MC
But you gave detailed (glowing) examples of its usage (none of which I asked for), yet you can't share any details on how you programmed the thing, either because you can't remember or you won't say. What I asked for (after crossing off all the things you apparently don't want to talk about) is how you did binary calculations (even just addition) and displayed the result, to which you flippantly replied "As numbers..."
I gave benefit of doubt that you weren't trying to trivialize or deflect the question. You simply didn't understand it. So I took pains to explain why that's not as simple as your reply suggests -- that you have to do everything from scratch at ML level, that doing decimal math at binary level is not trivial (at all) and gave plenty of examples as to why. I even simplified the question to ask whether it leaned toward method A or method B. Even that you failed to answer.
I dealt with many people who made claims. A small subset of them couldn't even understand my questions asking for details, so I had to educate them, which took more time and words than I would have liked. About 100% of the times, it turns out they made false claims. You know, I even ran into a person who said, in effect, stars aligned in his favor. How is anyone supposed to believe that BS?
Okay, let's more details:
How did you enter machine code? by hand and by using an app?
I told you I used an app. The app simply let you enter the MC hex number or use the assembly code, which I also told you. I did it both ways because some of the instructions were used so much that I found it easier to use the number that, by then, I had memorized. So your "question" is bogus.
Entering by hand and using assembly are completely different approaches. One is punching in hex (might as well be flipping dip switches) not only for opcodes (which you say you memorized) but also memory locations of where you put things and addresses of your routines, hardware registers, value -- all in hex. If you had to modify your code or move it to another location, unless you had some magical app, you'd have to re-punch all the hex. You'd have to memorize not just opcodes but all the memory locations. You had great memory then. Why does it fail you now?
Working with assembly, you're working with mnemonics, names for mem locations, etc. From the computer POV, there's almost no difference. But for the human programmer, it's a completely different experience. So much so that they could not confuse one with another. Definitely not mix and match.
What else did this magical "app" do? Compiling? Profiling? Syntax highlighting? Linting? Debugging? Break points? Watch variables in real time? Can you say the name of this app, or will that reveal too much?
It used less memory, but don't remember how
I told you how. I believe I gave 3 major reasons. So why did you fib about this?
It ran faster than others, but don't remember how
Yet I told you many times. Machine code to replace the slower parts of Basic. So you fibbed again.
You said you limited the range of numbers to 0-254 with 255 being NG (no grade?), so you can use just 1 byte. Why is NG 254? If you really memorized the opcodes, you should know that there are many instructions that checks 0th bit quickly and easily. Putting NG at the end would waste cycles to check for and possibly waste memory. Too specific to remember? Then how about this: how does this save memory and/or run faster, when there's sure to be a waste down the line?
And you never said which parts of BASIC you replaced to make faster with ML. I mean, your system (tho unnamed) was a rice car that goes fast simply because you put a sticker with Chinese characters on it. Besides, I did not ask about them. I only asked about how the math routines operated in ML, but you threw out all these claims as answers (or justifications). And I ask for clarifications because you won't answer my main question.
I think your call for "proof" is really just a way to find out who I am - since there is no way to present the proof without also revealing my name and where I've lived because it is all on the net and if you find part, you find it all. Considering all the things you listed that were flat out false, I wouldn't trust you or anyone like you with my personal information.
LOL. What a wild assumption, even for you. I don't care who you are. Most of the times I ignore you, even though you inject yourself into every conversation and cry out for MY attention. I said multiple times I advocate anonymity and anonymous ID usage. Even then, you should not say things with impunity, nor make wild claims (and make attacks with it) and then cry about when someone questions them. You're not that important. And I have no idea how revealing your system would reveal your name(?). Well, that's a first.
This just seems like a way to cover your tracks, and deflect the question. It sounds like a desperate measure straight out of Waytools playbook. What's next? Make up some wild conspiracy theory?
POLL: Who will finish and launch first ? GRRM with his final 2 books or WT with the TB ?
DBK /= Jon Snow.
Poll answer:
Possible answer: Neither.
HBO was worried GRRM might never finish due to age and health.
With WT the worry seems to be financial, patent ownership issues, executive and developer mental health, legal action over related company issues, ability to complete final hardware and then produce at scale (which ties into the first one, financial).
In a world of infinite possibility, the imaginary Oppo-PR campaign might also be real, and this is also a potential factor in the ultimate success or otherwise of WT and the TB.
The above is what has been reported, discussed, linked to, despite seeing links to the NextEngine stuff, I know nothing else for certain, which could well be Snow-like in its nothing-ness, but it does appear that it’s not a nothing-burger situation but a something-burger.
Hoped for answer: WT with the TB will handily beat GRRM.
Sadly though, MK’s WT and the GR of the TB will not beat the televised series finale of GoT.
* Edit to add in the imaginary Oppo-PR campaign, I’d forgotten about it and then I remembered that MK thinks it is part of his reality, so I included it.
> Yet you do not remember any of the details on why -- rather, you'd not say. That would make anyone wonder.
False. I gave many details. Those I could remember, which isn't all, but there were many.
BTW, it also isn't contradictory for me to say I worked hard at it and also say it wasn't a big deal. Because once I figured out how to do it, it didn't strike me a big deal. It would be much like saying I worked hard to learn to ride a bicycle, but once I learned, I sure wouldn't say it was a big deal that I achieved it. After all, many millions of people do it.
> Entering by hand and using assembly are completely different approaches. One is punching in hex (might as well be flipping dip switches) not only for opcodes (which you say you memorized) but also memory locations of where you put things and addresses of your routines, hardware registers, value -- all in hex.
Nope. The app simply let you do it either way, and switch with a simple keystroke. Everything was in two columns: Hex codes on one side and the assembly language instruction on the other. If I entered the hex code, it also showed up on the assembly side and vice versa. The resulting code would be exactly the same.
> Putting NG at the end would waste cycles to check for and possibly waste memory. Too specific to remember? Then how about this: how does this save memory and/or run faster, when there's sure to be a waste down the line?
Noted that you now don't claim I said I didn't know how I saved memory!
Maybe putting NG at the end did waste cycles. But you can do something less than the "ideal" way and still be faster than known alternatives available at the time.
> And I have no idea how revealing your system would reveal your name(?). Well, that's a first
If they change the code for no other purpose but to make something faster, does that make it a new "feature"? But if you rewrite the code for some other reason, but more speed is a side benefit, that isn't?
Making it go faster is certainly a "new feature". Let me give you a simple example you can understand. On my 6502 emulator, I was able to run "One on One" -- a Larry Bird + Doctor J basketball game -- popular game for the Apple II. As I slowly increased the emulator speed, there was jerks in the graphics, their stamina would drain too quickly, making it almost unplayable. When I removed the speed limit all together, not only did the game not even load, the whole system went haywire.
Even a small speed increase throws a monkey wrench into an Apple II emulator, which is much simpler than the more "complex Textblade". Just because you made something go faster doesn't necessarily result in benefit, more on the contrary. This is not a 'programming' concept, it's common sense.
The result can be exactly the same so it sure looks like the concept is not so rock solid after all.
The result CANNOT be the same, think about it. They'd have to change several hardware parts, change timings, etc. It's far safer to add features than to try to make it go faster, since former would result in bloat vs potentially complete dysfunction. Again, just think.
"Feature freeze" is a concept and phrase agreed upon by "professional programmers" and "experts" who's thought about these things and is used to combat unnecessary mucking with code. Nobody cares whether you don't like the term, or you don't find it rock solid, or any such misguided interpretation on your part. It's there for a reason, and is oft-practiced. If you want to play semantics games, like this:
My example was just to show an easily understood example.
Then you go into lots of "coulds", but even in modern software, not everything is going to lead to new problems. Nevertheless, you also just revealed a very good reason they needed to do the rewrite. Because every fix, by your standards, could lead to a host of other problems. And it would be particularly bad when you have no free memory to make the fix. That means you have to not only rewrite that portion, but other portions to make room for it. Thus doubling (or more) the chance for all those "coulds" to happen! << Removed snide remarks >>
go elsewhere and do it.
And regarding memory (WT's efforts to clear up memory and your advocacy of that), let's clear some things up.
Memory is probably the most precious resource on a computing device (Textblade being such a device). At any given moment, a computer should be using ALL available memory. If you look at how FreeBSD or Linux uses memory, every bit of it is in use at any given time. It's used for caching, paging, or any other specific tasks. On a well-designed system, once garbage collection is done, it's used immediately, meaning there should be a plan for any free memory that's been cleared up. Anything free can be put to use one way or another.
The dumbest thing to do is to clear up memory, just because... Is it for additional features, stability, speed increase, what? Doing it for some unknown future fixes(?) or possible updates is probably the second dumbest reason. Is there a demand for the free memory? If so, what are they planning, or what needs it? If not, it's just waste of time.
> I said you feigned expertise. When you say 'I am pointing out [some made up fact]' you are staking a claim on some knowledge or expertise which happens to be provably false.
But I didn't feign anything. I just showed how it isn't as simple as you claim - and your own statements I referred to above show how it isn't so simple.
You feign "expertise" because you advocate Waytools actions without knowing anything more than the rest of us. And you throw out a lot of technical-sounding buzzwords (which you don't understand) or by poo-poo'ing other tried-and-true terms (which again you don't understand). When someone tries to correct you, or even educate you on those terms, you brush them away as being "experts" or "critics", proceed to attack, and when you lose even that, you feign "victimization". This is the entirety of your for...next loop.
> Post some of your old 'BASIC AND machine code' on Github so we can check it out.
Strange statement from someone who says he could care less!
Kahuna, that's not meant as an attack. It's common practice amongst programmers to tell someone to throw the code onto github for review. It can even mean he shows greater interest than before.
Because there are many who just talks and talks about how great their programs (and programming skill) are. It's easier for programmers to gauge other's skill level by reading their code instead. Actual code tells you a lot about the person, sometimes more than any talk.
Comments
Don't worry, the above is for the LULZ only. Carry on. Half a month to go (unless it falls on a Friday which could push things out a few millennia to 20,222).
I do not believe the 'we are refactoring firmware to free up memory' story one bit. At best it is accidentally tangentially 1% true. It is not the real reason for the latest holdup. I could write a full page of technical explanations regarding why its not true, but its pointless. I am not dealing with rational or logical people here who will respond in good faith.
You rambled about how expanding jumps from 6 to 12 may or may not be considered a new feature. Not only was that statement ridiculous, but the implications of it are so insulting to anyone who has waited in good faith. You feigned expertise on the question of defining what a code freeze actually is, but you know nothing about the topic. Do you know how many times Waytools (Mark Knighton) has written that features were frozen, and then either he or you followed that months/years later with BS that 'because we are fixing one thing or another, we might as well add this other feature', as if there is no potential for that to cause further harm or additional delays, which is just another slap in face of anybody who believed the initial statement that they were going to lock it down and finally give people what they paid for?
To any serious professional on the outside looking in, all of these statements and behaviors and actions taken together amount to a total charade. Mark Knighton and Kahuna appear to be the core of a small group of people who are either raving mad lying crackpots, or blithering idiots, or all of the above. And every time Mark changes his story, you whistle by and parrot his BS. Its just disgusting behavior.
Nobody is going to make a logical argument that convinces you or Mark how awful you are behaving. Its futile.
The truth is, Mark Knighton has tricked a lot of people into giving him money in exchange for nothing, and then holding onto that money for 4+ years with a series of lies that exploited peoples good will, so in that one regard, he is pretty smart.
He is a good liar, and you are his parrot. Its not something you should be proud of.
Going back to the topic at hand, I coded all of this time with different levels of intensity. I can talk about different projects more than others.
In the earliest days I sometimes copied code from a magazine & adapted it creating a Frankenstein, later when I understood what I was doing I recreated a v2 from scratch. Learnt a lot in the process.
I can fondly remember one failed crazy project. Remember that later magazines came with a kind of checksum code for each line that if it matched then you had no typos ? We (my older brother and I) tried to create a program that if you typed the checksums it would spit the lines for you. It obviously did not work.
But I do not think I can speak on the details without looking at the code.
Another example: I did write code to convert binary to decimal and hex and vice versa, but I can't remember the details. Now, looking at the code I remember what I did, or in this case I just took note of the posts that helped me create something that worked (even in different languages these algorithms once understood they are very easy to adapt). ie:
http://www.mkyong.com/java/how-to-convert-hex-to-ascii-in-java/
http://stackoverflow.com/questions/934790/how-can-i-convert-hex-number-to-integers-and-strings-in-objective-c
http://stackoverflow.com/questions/2832729/how-to-convert-ascii-value-to-a-character-in-objective-c
In essence you are giving DBK a hard time because you guys Ericpeets & TBD (correctly) find gaps in the explanations. I admit I cannot still understand what he did (and I did use peeking and poking to read and write registers in the Ataris). If I had to vote it would have been this TBD idea later shot down:
The point is, what he is describing might be wrong in terms of misremembering, but he does NOT need to be an expert developer to give his idea / opinion of why the firmware rewrite is needed.
I also suspect that freeing the memory is only partially true (and it is the line given to everybody), and highly likely they have a jungle of hacks on top of hacks they need to clean up.
Later job experience managing a team developing business mobile apps taught me a lot more. Feature freeze is critical if not they will chase their tails forever and never finish.
Its not about memory constraints. Jungle of hacks is probably closer to the truth, closer still would be developer turnover, loss of a developer, and/or issues with development tools due to nearly half-decade old hardware and IDE. Biggest issue is undoubtedly money. They cannot afford to finish the job - they cannot afford the developers they need - so development is nearly or entirely stalled. Hence the lie - customer orders not funding development - but Mark Knighton wants to keep all the money and so he contradicts what he told the journalist by saying that customer money is expediting or facilitating the product release. Once you tell a lie, its all lies and nobody knows what the truth is anymore.
Indeed, feature freeze is extremely critical, and this is the issue that pisses me off the most. You can find 4+ years of posts from Mark Knighton claiming feature freeze at one point or another, and then followup posts after lengthy delays where Kahuna and Mark tag team on the hypothesis that a feature here or there is of no consequence because they are already busy fixing some other screwup. These people do not have a clue what they are doing. The do not have a clue what they are talking about. It is negligent and unethical behavior.
Wrong again. I just point out what we know - that they are rewriting to save memory. They MAY be doing any number of other things but we don't know about those yet and I've even said their statements about this or that capability being added are not clear about whether they are before or after GR.
What you do is write like you are on the dev team since you make statements that you do not have actually facts for, yet you present them as facts!
> You rambled about how expanding jumps from 6 to 12 may or may not be considered a new feature.
Yep. Depends on how they have to do it. Oh, some can say no matter what, even if it only involved changing a for/next loop to cycle from 1-6 to be 1-12 and nothing else was affected, people can fairly say it is a new feature. But I can see the alternative view.
> You feigned expertise on the question of defining what a code freeze actually is, but you know nothing about the topic.
I claimed to be an expert on this? When? BTW, if we are going to be precise, there most definitely is not a "code freeze". They gave a pretty good hint about that when they said they were REWRITING the code! I pretty sure you can do that if you've frozen the code. Now, "feature freeze" you can do, though, as I've said, it would be silly to not write an improvement at the same time they are saving space. They said jumps are now twice as fast. Is that a new feature? Could be viewed that way, but I would say it is just a happy benefit of cleaning up code.
> Nobody is going to make a logical argument that convinces you or Mark how awful you are behaving.
If you are going to make stuff up, it is best not to do it about something which is so obviously wrong. I've publicly posted about things I disagree with what they've done. That doesn't even count the private comments I've sent.
There were registers that held values which would show what address a Basic program started with. There were registers that showed what address was the start of the variables which held all the data.
The Save command in Basic would automatically use that info to save the program and its data. But usually I didn't want both save. It took extra time to both save and to restore.
So I would peek into the register for where the data started and poke them into the registers which said where the basic program started (after saving the original values).
At this point, simply activating an ordinary Save would cause the program to think the start of the program was actually where the variables were and that's all it would save. When done, it would restore the original values.
2. Certainly agree with the second paragraph!
3. And the third paragraph is also possible.
One other thing, while I certainly can't remember any details about how I did the math in my program, I am pretty sure there were things I did which would make a call to a specific area of Basic. This would be done to bypass extra stuff I simply didn't need, so it would be faster. Can't think of a specific example, but if a Basic command would go through multiple options for one written command and based on other things decide where to go to next, I could bypass that initial determination by making a call directly to the part it would have ended up choosing anyway.
It's like how some languages come with a lot of baggage in libraries to cover many possibilities. That's nice if you have the space and enough power in your computer, but if you don't need most of them, by writing in MC you can leave them out which certainly saves memory, but also likely speeds things up.
Just answering questions I was asked, as best I can.
> Its not about memory constraints.
Wow, you must be on their dev team to know such things as fact! Especially after all the other things you followed that with, which would require you actually work at WT to know about.
> he contradicts what he told the journalist by saying that customer money is expediting or facilitating the product release.
For someone who pretends to know what is going on, it is interesting that you have yet to figure out how this can easily work. Even though there is at least some hint of it in the article.
https://forum.waytools.com/t/summary-of-what-the-new-infrastructure-code-fork-is-about/5578/26
annnnnnnnd discuss.
R
I could not quickly find when it was that they first announced they were starting to work on the firmware update, but it has been more than 6 / 7 months, right ?
Edit to add:
POLL: Who will finish and launch first ? GRRM with his final 2 books or WT with the TB ?
You are just full of it. You have no direct knowledge. You are parroting what Mark says. You 'know': Nothing.
You have practically zero knowledge about programming or modern software design, regardless of what you may have done in the 80s. When you say you can 'see the alternative view', when in fact there is not any alternative view, you are just acting like a stubborn idiot.
If some functionality does not exist in a program (12 jumps), and then you add that functionality, that is a feature. Your reference to a for/next loop - your notion of what constitutes a program in your view - is so primitive it is absurd. In modern software, one new line of code could be creating a new instance of a class which encapsulates hundreds of other lines of code, or it could be a new function that triggers a chain of callbacks, or a million other things, any one of which could introduce memory leaks or race conditions or business logic bugs or a million other problems depending on how poorly the code is designed.
A feature freeze is a feature freeze. You do not enhance or expand a feature when features are frozen. You fix necessary bugs. Nothing else. That is how thousands of successful software projects get completed on time and under budget every day. Why do you want to defend the methodology of a totally unsuccessful company like Waytools against the methodology that has made thousands of other companies successful?
>Kahuna post 836:
>Yes, but I'm pointing out that feature freeze isn't a rock solid concept.
I said you feigned expertise. When you say 'I am pointing out [some made up fact]' you are staking a claim on some knowledge or expertise which happens to be provably false. You possess no relevant knowledge on the subject. You are just mouthing off. It is all you know how to do.
A feature freeze is a rock solid concept.
That right there: 'it would be silly to not write an improvement...' Actually, yes it would be extremely silly when you are already 4+ years past your original deadline. You have absolutely no idea how stupid you sound when you write things like that. You have no idea what you are talking about. But you say it anyway, which again, makes me think you must be the head of the dev team at Waytools, and thus the reason why the project cannot be completed.
That could have been a bug fix. You dont know. You know nothing.
In fact 2018-08-06 is when the commentary dates from and this is partly why there is a commentary at all. To externally fix dates and times of announcements so they don't slide about on on WTF. in fact on another thread on 2018-08-20 I think I riff on an original announcement for 'wired mode.'
It's all getting so very murky.
R
First, you know no more than I do yet you keep claiming your assumptions are facts!
Second, you don't see the obvious difference between the two things ("rewriting code" vs "when will it be released". It's really simple. One would reflect the present - thus no estimating. They either are or are not rewriting code. The other is about the future, which is never certain. It is the difference between someone talking on the phone while driving to meet someone who says, "I'm driving to pick you up right now. I'll be there in 20 minutes". The first part of that sentence is absolute. The second part is an expectation which may or may not happen.
> If some functionality does not exist in a program (12 jumps), and then you add that functionality, that is a feature.
And I said it can be viewed that way. But there are alternatives. To show you how you reveal it isn't so simple we have this:
And you responded > That could have been a bug fix. You dont know.
What you show here is that during the rewrite, something can be improved besides the bug or other issue with the code. Which is what I've been saying. I would fully expect lots of things to be faster because of a major rewrite, even if only because to make more space, you are going to eliminate crud. So how do you say the concept of feature freeze is a "rock solid concept"? If they change the code for no other purpose but to make something faster, does that make it a new "feature"? But if you rewrite the code for some other reason, but more speed is a side benefit, that isn't? The result can be exactly the same so it sure looks like the concept is not so rock solid after all. Sure, it is convenient to think of it that way, but it doesn't seem to be the case every time, even when the resulting change is identical.
> Your reference to a for/next loop - your notion of what constitutes a program in your view - is so primitive it is absurd. In modern software, one new line of code could be creating a new instance of a class which encapsulates hundreds of other lines of code, or it could be a new function that triggers a chain of callbacks, or a million other things, any one of which could introduce memory leaks or race conditions or business logic bugs or a million other problems
My example was just to show an easily understood example.
Then you go into lots of "coulds", but even in modern software, not everything is going to lead to new problems. Nevertheless, you also just revealed a very good reason they needed to do the rewrite. Because every fix, by your standards, could lead to a host of other problems. And it would be particularly bad when you have no free memory to make the fix. That means you have to not only rewrite that portion, but other portions to make room for it. Thus doubling (or more) the chance for all those "coulds" to happen! Thanks. Good to have common ground.
> I said you feigned expertise. When you say 'I am pointing out [some made up fact]' you are staking a claim on some knowledge or expertise which happens to be provably false.
But I didn't feign anything. I just showed how it isn't as simple as you claim - and your own statements I referred to above show how it isn't so simple.
> That right there: 'it would be silly to not write an improvement...' Actually, yes it would be extremely silly when you are already 4+ years past your original deadline.
Already covered with the improved speed example. What would you say they should do when a rewrite results in faster response? Are you going to say they should throw in an artificial delay? I'm not saying they may do things which would, indeed, be feature creep. I am saying - and have said before - we don't know yet because they haven't said when some of the improvements will be included. So if they post an update saying they added mind-reading to the TB, I'd say that was feature creep - and it won't contradict anything I've said before.
It's not me who's making it out to be "out of the blue" or even trivial:
and:
Yet, you say:
But you gave detailed (glowing) examples of its usage (none of which I asked for), yet you can't share any details on how you programmed the thing, either because you can't remember or you won't say. What I asked for (after crossing off all the things you apparently don't want to talk about) is how you did binary calculations (even just addition) and displayed the result, to which you flippantly replied "As numbers..."
I gave benefit of doubt that you weren't trying to trivialize or deflect the question. You simply didn't understand it. So I took pains to explain why that's not as simple as your reply suggests -- that you have to do everything from scratch at ML level, that doing decimal math at binary level is not trivial (at all) and gave plenty of examples as to why. I even simplified the question to ask whether it leaned toward method A or method B. Even that you failed to answer.
I dealt with many people who made claims. A small subset of them couldn't even understand my questions asking for details, so I had to educate them, which took more time and words than I would have liked. About 100% of the times, it turns out they made false claims. You know, I even ran into a person who said, in effect, stars aligned in his favor. How is anyone supposed to believe that BS?
Okay, let's more details:
Entering by hand and using assembly are completely different approaches. One is punching in hex (might as well be flipping dip switches) not only for opcodes (which you say you memorized) but also memory locations of where you put things and addresses of your routines, hardware registers, value -- all in hex. If you had to modify your code or move it to another location, unless you had some magical app, you'd have to re-punch all the hex. You'd have to memorize not just opcodes but all the memory locations. You had great memory then. Why does it fail you now?
Working with assembly, you're working with mnemonics, names for mem locations, etc. From the computer POV, there's almost no difference. But for the human programmer, it's a completely different experience. So much so that they could not confuse one with another. Definitely not mix and match.
What else did this magical "app" do? Compiling? Profiling? Syntax highlighting? Linting? Debugging? Break points? Watch variables in real time? Can you say the name of this app, or will that reveal too much?
You said you limited the range of numbers to 0-254 with 255 being NG (no grade?), so you can use just 1 byte. Why is NG 254? If you really memorized the opcodes, you should know that there are many instructions that checks 0th bit quickly and easily. Putting NG at the end would waste cycles to check for and possibly waste memory. Too specific to remember? Then how about this: how does this save memory and/or run faster, when there's sure to be a waste down the line?
And you never said which parts of BASIC you replaced to make faster with ML. I mean, your system (tho unnamed) was a rice car that goes fast simply because you put a sticker with Chinese characters on it. Besides, I did not ask about them. I only asked about how the math routines operated in ML, but you threw out all these claims as answers (or justifications). And I ask for clarifications because you won't answer my main question.
LOL. What a wild assumption, even for you. I don't care who you are. Most of the times I ignore you, even though you inject yourself into every conversation and cry out for MY attention. I said multiple times I advocate anonymity and anonymous ID usage. Even then, you should not say things with impunity, nor make wild claims (and make attacks with it) and then cry about when someone questions them. You're not that important. And I have no idea how revealing your system would reveal your name(?). Well, that's a first.
This just seems like a way to cover your tracks, and deflect the question. It sounds like a desperate measure straight out of Waytools playbook. What's next? Make up some wild conspiracy theory?
Poll answer:
Possible answer: Neither.
HBO was worried GRRM might never finish due to age and health.
With WT the worry seems to be financial, patent ownership issues, executive and developer mental health, legal action over related company issues, ability to complete final hardware and then produce at scale (which ties into the first one, financial).
In a world of infinite possibility, the imaginary Oppo-PR campaign might also be real, and this is also a potential factor in the ultimate success or otherwise of WT and the TB.
The above is what has been reported, discussed, linked to, despite seeing links to the NextEngine stuff, I know nothing else for certain, which could well be Snow-like in its nothing-ness, but it does appear that it’s not a nothing-burger situation but a something-burger.
Hoped for answer: WT with the TB will handily beat GRRM.
Sadly though, MK’s WT and the GR of the TB will not beat the televised series finale of GoT.
* Edit to add in the imaginary Oppo-PR campaign, I’d forgotten about it and then I remembered that MK thinks it is part of his reality, so I included it.
I hope GRRM is not waiting to receive his TB to continue typing...
I guess it is a strategy that could be successfully re-used again and again, after all, as they say, if it ain’t fixed, break it.
+++
/s as in try the /salmon, I’m here all week :-) :-)
False. I gave many details. Those I could remember, which isn't all, but there were many.
BTW, it also isn't contradictory for me to say I worked hard at it and also say it wasn't a big deal. Because once I figured out how to do it, it didn't strike me a big deal. It would be much like saying I worked hard to learn to ride a bicycle, but once I learned, I sure wouldn't say it was a big deal that I achieved it. After all, many millions of people do it.
> Entering by hand and using assembly are completely different approaches. One is punching in hex (might as well be flipping dip switches) not only for opcodes (which you say you memorized) but also memory locations of where you put things and addresses of your routines, hardware registers, value -- all in hex.
Nope. The app simply let you do it either way, and switch with a simple keystroke. Everything was in two columns: Hex codes on one side and the assembly language instruction on the other. If I entered the hex code, it also showed up on the assembly side and vice versa. The resulting code would be exactly the same.
> Putting NG at the end would waste cycles to check for and possibly waste memory. Too specific to remember? Then how about this: how does this save memory and/or run faster, when there's sure to be a waste down the line?
Noted that you now don't claim I said I didn't know how I saved memory!
Maybe putting NG at the end did waste cycles. But you can do something less than the "ideal" way and still be faster than known alternatives available at the time.
> And I have no idea how revealing your system would reveal your name(?). Well, that's a first
But I do, and that's all that matters.
Making it go faster is certainly a "new feature". Let me give you a simple example you can understand. On my 6502 emulator, I was able to run "One on One" -- a Larry Bird + Doctor J basketball game -- popular game for the Apple II. As I slowly increased the emulator speed, there was jerks in the graphics, their stamina would drain too quickly, making it almost unplayable. When I removed the speed limit all together, not only did the game not even load, the whole system went haywire.
Even a small speed increase throws a monkey wrench into an Apple II emulator, which is much simpler than the more "complex Textblade". Just because you made something go faster doesn't necessarily result in benefit, more on the contrary. This is not a 'programming' concept, it's common sense.
The result CANNOT be the same, think about it. They'd have to change several hardware parts, change timings, etc. It's far safer to add features than to try to make it go faster, since former would result in bloat vs potentially complete dysfunction. Again, just think.
"Feature freeze" is a concept and phrase agreed upon by "professional programmers" and "experts" who's thought about these things and is used to combat unnecessary mucking with code. Nobody cares whether you don't like the term, or you don't find it rock solid, or any such misguided interpretation on your part. It's there for a reason, and is oft-practiced. If you want to play semantics games, like this:
go elsewhere and do it.
And regarding memory (WT's efforts to clear up memory and your advocacy of that), let's clear some things up.
Memory is probably the most precious resource on a computing device (Textblade being such a device). At any given moment, a computer should be using ALL available memory. If you look at how FreeBSD or Linux uses memory, every bit of it is in use at any given time. It's used for caching, paging, or any other specific tasks. On a well-designed system, once garbage collection is done, it's used immediately, meaning there should be a plan for any free memory that's been cleared up. Anything free can be put to use one way or another.
The dumbest thing to do is to clear up memory, just because... Is it for additional features, stability, speed increase, what? Doing it for some unknown future fixes(?) or possible updates is probably the second dumbest reason. Is there a demand for the free memory? If so, what are they planning, or what needs it? If not, it's just waste of time.
You feign "expertise" because you advocate Waytools actions without knowing anything more than the rest of us. And you throw out a lot of technical-sounding buzzwords (which you don't understand) or by poo-poo'ing other tried-and-true terms (which again you don't understand). When someone tries to correct you, or even educate you on those terms, you brush them away as being "experts" or "critics", proceed to attack, and when you lose even that, you feign "victimization". This is the entirety of your for...next loop.
Because there are many who just talks and talks about how great their programs (and programming skill) are. It's easier for programmers to gauge other's skill level by reading their code instead. Actual code tells you a lot about the person, sometimes more than any talk.
edit: removed extra spacings