Ren'Py Rare bug in text statment in RenPy

[anne O'nymous]

Since start I was telling you you just running your own code not mine.

Because, as I said, I test the bug you pretend to have found...

If the test codes I provide give the right result, and they do, then the issue isn't the text statement, but the value provided to it. What mean that the issue come from your code, whatever because it's structurally bugged, or because it don't follow the logical rules implied by the language you use.

But even if your explanations looks like logically at first glance - they are still dont explain everything, cos code like this one:

text synaptic + (" %3d %3d " % ( len(f22f) , len(f22f) )

working well without needs to use method copy() of f22f object declared in Python block.

And? What is surprising in this?

Like you don't starts by a string, Ren'Py treat the whole argument as an implicit expression. What mean that it will reevaluate it every time. This being done through a Python native function, the values are not took from Ren'Py constants cache, but from the current global scope, updated by the current local scope.

So i dont care what you call optimization rule or other way . Cos for me it acting like blatant bug.

And this is why there's peoples who believe that Earth is flat. Like they don't understand gravity, they reject the reality, whatever who explain them that they are wrong. It's easier for them than to admit the limits of their knowledge.

Ideas behind of Python were to free us of memory management like we had to bother in C or C++.

No. This was already achieved by all scripting languages derived from C, like Perl by example, while being purely absent from many compiled languages. Memory management was an improvement that C brought to us, not something one should get rid of.
The main idea behind Python was to have a language both simple to use and beautiful to look at. Then, with the project growing, it became a proof of concept for some paradigms like duck typing or none mutability.
By the way, Python come from ABC not from C.

And now you blatanly call such evident bug and weakness as an result of optimisation rule .

It's not more a bug than:

$a = 12;
change( $a );
print $a;

def change{ $_[0] = 42; }

showing that "$a" value have changed while never being explicitly assigned a second time.

Like it's not more a bug than a car not working anymore because you filled the tank with incompatible fuel.

It's how the language works and, for once for Ren'Py, this is explicitly covered by a dedicated part of the doc, period. Don't call bug the fact that you use a language without respecting its design constraints; mostly because you didn't cared to learn the said constraints.

Great very funny indeed.
You just should start with that your Majesty Experienced.

I prefer to finish with that:

Spoiler: Oh! Who would have thought?

You don't have permission to view the spoiler content. Log in or register now.

 

[peterppp]

Sorry my friend - I see you are trying to help but you dont understand the issue at all.
copy() method dont have any influence on f22f content.

It is interacting with BugPy in quite diffrent way - now even obvious for decades experienced AONs.

By invoking copy() method of f22f object BugPy is forced to check actual state of this variable which is in Python's domain.
BugPy dont using old content (not actual ) of f22f object in its code - it is using actual content without beeing forced by invoking copy() method. So there is no reason to check state of the content of f22f object.

What going wrong is the way BugPy wasteing its memory for keeping old atribute of old state of f22f variable. This atribute is just length - so BugPy is blatantly incoherent in treatment of len(f22f) expression.

In one instance syntax of text statement forcing BuPy to call Python to return of actual length of this object but in another instance it is using its bugged value from its own wasted this way memory location.

This mechanism has nothing common with content of f22f object. This content is always located in memory where BugPy have access by right interaction with Python at python's level of execution.
At this level Python is responsible of memory management so in every case it returning right actual values of all actual elements in f22f list object.

You dont understand - cos you are assuming I dont see what is the content of f22f object. But it is blatantly wrong assumption cos other part of my code just printing on the screen right values of content - all file names are displayed right without invoking copy() method at all , so i dont have any logical reason to check this condition once again !!!

I will tell you once again despite you are closed for logical thinking - enumeration working very well with pure f22f object old or actual.

But you are stubborn i need to check it again

You should ask not me but BugPy core progrmmers to check this condition if it is any logical reason to waste this way precious resorces . But even blatantly bugged BugPy dont have such kind of issues what is proved by code and displayed very correct.

grand autismo. you can't even test one line of code and instead writes an essay AGAIN. even if you are sure, you could still test the if comparison and then say that in fact f22f == f22f.copy() returns true, or see that it doesnt. instead you have to write another essay. you're wasting all of ours' time. i'm not reading any more of your essays.

 

[anne O'nymous]

this is so stupid

Even more stupid that I gave the solution four hours ago...

 

[ciaqoo]

grand autismo. you can't even test one line of code and instead writes an essay AGAIN. even if you are sure, you could still test the if comparison and then say that in fact f22f == f22f.copy() returns true, or see that it doesnt. instead you have to write another essay. you're wasting all of ours' time. i'm not reading any more of your essays.

OK you won
I've just checked and guess what i found !!!

You cant belive but I really wasted few pressings on my keyboard. The result is True.
Are you happy now ???

 

[peterppp]

OK you won
I've just checked and guess what i found !!!

You cant belive but I really wasted few pressings on my keyboard. The result is True.
Are you happy now ???

i'm mildly satisfied, but not happy because you had to write several essays when this was all you had to answer me... talking about wasted pressings. given your history, i dont trust that you checked in the correct place but whatever.

 

[ciaqoo]

i'm mildly satisfied, but not happy because you had to write several essays when this was all you had to answer me... talking about wasted pressings. given your history, i dont trust that you checked in the correct place but whatever.

You cant trust me but i even can send you the code:

if f22f -- f22f.copy():
  if (len(f22f))==len(f22f.copy()):
     text ("%110s %s" % (' ', str(len(f22f)) )):
         sixe 14
  else:
    text (""BugPy is fucked up %10s %s" % (' ', str(len(f22f.copy())) )):
         sixe 14
else:
    text synaptic + (""%110s %s" % (' ', str(len(f22f)) )):
         sixe 14

And guess what was its output ???

Despite both conditions are True it is sending me wrong value 94 instead of correct 75

If second condition was False so in this case it should admit BugPy is fucked up and write correct velue of 75


but its choice was to pretend that both len terms are egual to each other and proving in first text staement instance that it is blatant lie - cos 94 is not equal to 75 for obvious reason !!!

edit
Or maybe you dont agree with me and I should put "BugPy is fucked up" string into first text statement instance ???

 

[anne O'nymous]

And guess what was its output ???

You mean, the output once you fixed the three "sixe" that should be "size", then fixed the two "" that should be just one double quote, then fixed the "--" that should be a "==" ?
I wonder why you haven't just copy/pasted the code you actually used for the test.

This being said, even test code seem to be something too difficult for you, so here's another one, that don't limits to the condition, but also explicitly show the length for "f22f" and for its copy. After all, what you search to test is the, said, bugged behavior of text, so test it...

Spoiler: valid test code

You don't have permission to view the spoiler content. Log in or register now.

The second iteration will show this:


And there's no magic, nor is there a "rare bug" in the if statement too, one that would make it "fucked up". It's still the continuation of what I explained previously.

When text is provided a value seen as constant, the said value is only evaluated once. This while, for relatively obvious reasons, if condition is systematically evaluated.

And it's how you can have a condition telling you that "f22f" is equal to its copy, and in the same time have a length for "f22f" that appear to not be equal to the length of its copy.

There's no bug, just you that categorically refuse to admit that you are wrong.
You prefer to rage (as shown by the many errors in your code snippet), claim that there's a bug, discard everything I said, and insult Ren'Py, than to admit that you should have learned the rules and constraints of the language before you tried to use it; or at least take a look at the doc when you faced a result that wasn't the one you expected.


Let's hope that night brought you a bit of wisdom, because you're up to a lot of rage if you continue to try to adapt the language to your own logic, instead of adapting your code to its design.

 

[peterppp]

You mean, the output once you fixed the three "sixe" that should be "size", then fixed the two "" that should be just one double quote, then fixed the "--" that should be a "==" ?
I wonder why you haven't just copy/pasted the code you actually used for the test.

This being said, even test code seem to be something too difficult for you, so here's another one, that don't limits to the condition, but also explicitly show the length for "f22f" and for its copy. After all, what you search to test is the, said, bugged behavior of text, so test it...

Spoiler: valid test code

You don't have permission to view the spoiler content. Log in or register now.

The second iteration will show this:
View attachment 4199419

And there's no magic, nor is there a "rare bug" in the if statement too, one that would make it "fucked up". It's still the continuation of what I explained previously.

When text is provided a value seen as constant, the said value is only evaluated once. This while, for relatively obvious reasons, if condition is systematically evaluated.

And it's how you can have a condition telling you that "f22f" is equal to its copy, and in the same time have a length for "f22f" that appear to not be equal to the length of its copy.

There's no bug, just you that categorically refuse to admit that you are wrong.
You prefer to rage (as shown by the many errors in your code snippet), claim that there's a bug, discard everything I said, and insult Ren'Py, than to admit that you should have learned the rules and constraints of the language before you tried to use it; or at least take a look at the doc when you faced a result that wasn't the one you expected.


Let's hope that night brought you a bit of wisdom, because you're up to a lot of rage if you continue to try to adapt the language to your own logic, instead of adapting your code to its design.

this actually depends on the renpy version. i tested your code with 7.4.11 and saw the different lengths in the second iteration, but in 8.0.3, they both updated to the same value

 

[ciaqoo]

You mean, the output once you fixed the three "sixe" that should be "size", then fixed the two "" that should be just one double quote, then fixed the "--" that should be a "==" ?
I wonder why you haven't just copy/pasted the code you actually used for the test.

Its easy to explain. I have a another laptop - in fact couple of them which are cut of from the net and I'm to lazy to connect external drive for moving small chunks of code back and forth.

Yes I see you patched code in BugPy with copy() metod patches. Its not surpising me at all.
But look at what awfully and blatantly inconsistent output BugPy is generating now.

It is trying to pretend len(f22f) == len(f22f.copy()) is True but its inner deliberate mumbled and jubled "optimization" showing us blatantly otherwise.


No you dont understnd my point at all.
I would tell you which way should behave correctly optimized shell like this one called RenPy.

Names of variables shouldn't be overloaded by hidden rules. This is my point Her Majesty Experienced.

In C, C++ we have local and global variables and if i need access to global counterpart of my local variable with the same name i can use explicit way needed operator to point out i need to ccess to global one ineasd to local variable.
It is clear and easy as 1, 2, 3 ...

Here in BugPy we have hidden rules of what you calling "optimization" - it is bullshit - cos it is really missleading mechanism for generating obfuscated code when the same name of variable meaning quite different for if statement and quite different for text statement.

And as this is not enough yet we have different meanings even for the same text statement of BugPy but with sligtly different syntax option.

Run the code below - i've just added one more line for you - and compare what text statement of BugPy generated as an output.
It falsifying totally your explanation - the same text statement, the same f22f argument but still incoherent mumbling as an output - do you see ???

screen testMe1():

    default folder = "./"

    python:
        from os import walk
        f22f=[]
        for ( dirpath, dirnames,filenames )  in walk (folder) :
            f22f.extend(filenames)
            break

    vbox:
        if f22f == f22f.copy() and len(f22f) == len(f22f.copy()):
            text folder + ("f22f length: %s" % (str(len(f22f)) ))
            text ("f22f length: %s" % (str(len(f22f)) ))
            text ("f22f.copy() length %s" % (str(len(f22f.copy())) ))
        else:
            text "f22f is not equal to its copy"

        textbutton "CHANGE" action If( folder== "./", SetLocalVariable( "folder", ".\\renpy" ),SetLocalVariable( "folder", "./" ) )
        textbutton "CLOSE" action Return()

label start:

    call screen testMe1()
    "END"

 

[anne O'nymous]

this actually depends on the renpy version.

As many things with Ren'Py, especially between the 7.5.0 and the last update for the branch 7.x, including the 8.x equivalent.

PyTom decided to use the port to Python 3.x as base to refactor a lot of code. Not a bad idea since Ren'Py had code that sometimes were only due 5.x, and below, legacy. This permit to have a code more optimized and more efficient.
By example the way screens were designed was based on the old ui. approach, when there weren't even a language to describe the screens. What mean that for a long time screen statements where mostly just a proxy to the old ui. functions; something that obviously lack of optimization.

But in the same time his desire to keep a Python 2.x equivalent version in parallel didn't made this easy. It's like wanting to radically redesign a room by adding new objects and furniture, while still keeping everything it contain, but knowing that soon you'll get rid of all those oldies.
So there's a lot of small behavioral changes, and small side effects, that led Ren'Py to lack of its usual constancy.
But globally it was always in the good way, like in this case where constants values are proceeded as none constants; it make it possible for code that shouldn't works to work, but don't break code expected to works. Some of them are voluntary, others just side effect from the refactoring based on Python 3.x strengths and flaws, that aren't the same than Python 2.x.

i tested your code with 7.4.11 and saw the different lengths in the second iteration, but in 8.0.3, they both updated to the same value

You should witness the same behavior (the value being updated) with the 7.5.3. It's possible that it also apply to the 8.0.0 and 7.5.0.

 

[peterppp]

Run the code below - i've just added one more line for you - and compare what text statement of BugPy generated as an output.
It falsifying totally your explanation - the same text statement, the same f22f argument but still incoherent mumbling as an output - do you see ???

            text folder + ("f22f length: %s" % (str(len(f22f)) ))

maybe because the "+" operation forces the updated value like copy does?

 

[ciaqoo]

maybe because the "+" operation forces the updated value like copy does?

Too much maybies for my taste

Thats the reason why I'm calling it BugPy now

edit
BTW Every bug you can explain this way - some coincidence triggering hidden interpreter to use the same name in quite different manner. And as a result you get the bullshit on the screen.
We are living in 21 century now - such blatant incoherency is unaceptable now.
That was my point since I started this topic.

But Her Majesty Experienced by decades trying to convince me we all should accept such blatant incoherency as VALID way for optimization.
NO WAY , never !!

 

[peterppp]

Thats the reason why I'm calling it BugPy now

i think it's a cute name

 

[anne O'nymous]

I would tell you which way should behave correctly optimized shell like this one called RenPy.

Ren'Py is not a shell, it's a game engine that come with three dedicated scripting languages.

Names of variables shouldn't be overloaded by hidden rules.

This is a new concept: hidden rules that are in plain sight in the documentation.

In C, C++ we have local and global variables and if i need access to global counterpart of my local variable with the same name i can use explicit way needed operator to point out i need to ccess to global one ineasd to local variable.

Not just C and C++, globally all languages post 60's include the notion of scope.

But, since you talk about C and C++, they also have something, way more interesting here, the notion of constants...
You should interest yourself in the const C/C++ instruction, because it's precisely the behavior you encounter and qualify as "fucked up".

Here in BugPy we have hidden rules of what you calling "optimization" - it is bullshit -

And so is C/C++ const then, since it's strictly the same behavior, and both come from a optimization desire.

cos it is really missleading mechanism for generating obfuscated code when the same name of variable meaning quite different for if statement and quite different for text statement.

There's no obfuscated code.
It's a constant behavior in scripting languages. Conditions are necessarily evaluated in real time, while a lot of other values are processed differently for optimization purpose.

By the way, would you'd read the doc, and therefore learned the rules of the language you want to use, like any a bit serious programmer would do, you would have also know that even when it come to variable declarations, Ren'Py isn't this different from C/C++. It come with a var equivalent (default) and a const one (define).
Implicitly declaring a variable by assigning it a value is a bad practice. Something that any serious C/C++ user would frown at, and in fact don't even imagine because it goes so against his principles.

And as this is not enough yet we have different meanings even for the same text statement of BugPy but with sligtly different syntax option.

This too is in the doc...
see below.

Run the code below [...]

I don't need to run it to know what it will display. And this is precisely because that code behave like I'm explaining it since a long time now: text statement provided none constant values, explicit or implicit, will be evaluated every time, while text statement provided constant values will not.

maybe because the "+" operation forces the updated value like copy does?

It's easier than that. As the doc say:

Supplying a variable containing the text directly is generally not const:

$ t = "Hello, world."
text t

Side note: "generally" because one can still use renpy.const() to declare "t" as constant.

And it's precisely what he's doing both with his text synaptic + [...] and with his text folder + [...].

Like he's telling Ren'Py that the very first value is not a constant, he force Ren'Py to reevaluate the whole expression in real time. Something that also happen when he use text [...] str(len(f22f.copy())) [...] since here it use the result of an object method; something assumed as not being a constant, because PyTom wasn't crazy enough to discriminate all native objects methods between pure (providing a constant value) and none pure (providing a none necessarily constant value).
But also something that don't happen in all the other syntax he tried, because all imply a value that is implicitly declared as being a constant. Something that wouldn't have happened if he declared correctly the variable, through default f22f = [], and didn't tried to declare it again, in an inner scope this time, with the f22f = [], in the Python bloc embedded in the screen.

All this not being a bug, but a basic and rational behavior that any C/C++ user and Python user would recognize at first sight.
Constants are not reevaluated, while variables are. And Python variables (and therefore Ren'Py ones) being none mutable, any assignation is equivalent to the recreation of the variable if it happen in the same scope, or to the creation of a new variable if it happen in another scope; hence the f33f.clear() in my demonstration code yesterday.

Gurer'f ab zntvp, ab frperg naq ab oht urer, whfg fbzrbar jub vf natel orpnhfr jung ur gubhtug gb or n onol gbl vf va snpg n frg bs cebsrffvbany dhnyvgl ynathntrf, naq gbb cebhq (rira sbe zl fgnaqneq, jung vf na rkcybvg) gb nqzvg gung ur jnf jebat.