Re: Re?: Re: unexpected behaviour of bb's arithmetic ternary operator
[email protected] wrote in <612664271.16313594.1760439377633.javamail.r...@zimbra33-e6.priv.proxad.\ net>: |Denys Vlasenko |Steffen Nurpmeso | |@Steffen : | as far as algos are concerned and from what can be observed with \ | the "tri" script's outputs, | it works fine ... [.] | preferably though :-). Hm. I have not looked since back then, and indeed, if i trim the test script a bit due to >>>, yes, in fact output of bb equals bash! Fascinating! I will have to look how he did it, it totally escaped me. I only see one remaining difference in between my own code and plain busybox / bash, and that is # make this work with (ba)sh \ command -v shopt && shopt -s expand_aliases;\ alias p=printf;alias e=echo;alias s=export s I1=10 I2=20;p "<$((I1+=I2+=I1+=I2))>";e "<$I1><$I2>" s I1=10 I2=20;p "<$((I1+=I2+=I1+=I1))>";e "<$I1><$I2>" which gives for my code #?0|kent:tmp$ busybox.static sh t2.sh <80><80><50> <60><60><40> and for bash and plain bb #?0|kent:tmp$ bash t2.sh shopt <60><60><50> <50><50><40> ...$ busybox sh t2.sh <60><60><50> <50><50><40> Where a C proof (what i want) gives $ cat t.c; tcc -run t.c #include int main(void){ int I1=10, I2=20; I1+=I2+=I1+=I2; printf("<%d><%d>\n", I1,I2); I1=10, I2=20; I1+=I2+=I1+=I1; printf("<%d><%d>\n", I1,I2); return 0; } <80><50> <60><40> But that is only a nit! Wow -- he really did get the "several times recursed" conditionals right with the current code!?!?!? I really will have to look. Thank you. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re?: Re: Re?: Re: unexpected behaviour of bb's arithmetic ternary operator
> And it really is only that > > 6a0ba673820cb6880e2f93f739de7d16d45d2b26 > .. > - expr1->val = top_of_stack->val; > - expr1->var_name = NULL; > - return NULL; > + rez = top_of_stack->val; > + top_of_stack = expr1; > + goto ret_rez; > > thing? Pfff that hurts, really. I will have to look more > thoroughly when i have time for *that*! So this stacking/unstacking (and a forced null value, loss of name if i understand the semantics of this), where are they located? if at the interface user-space and inner bb it helps, somewhat, understanding the big-names difficulty (which should be globally transparent, not just for the arithmtic thing (told you about the '[] && ||' similar behavior). Eventhough, does it take care of the non systematic outcomes (remamber that returning 0 and then 1 for the same expression/values, in the same, simple script(?). > Thank you. I will go cycling into the darkness.. Thanks for the exmple. Like you, i really should move out more this body of mine -sigh-. Noch einmal, vielen Danke JClu 202510142 ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re?: Re: Re?: Re: Re?: Re: unexpected behaviour of bb's arithmetic ternary operator
@Steffen > not at all, it was all only in respect to posting my (stupid, fat > and wrong) own variant of the Dijkstra two-stack arithmetic > evaluator in 2022. If that Dijkstra guy happens to be the same as the one of the simplex algo then i really bow respectfully to such a genius for feed us so well. As for the 2-stack juggling, no worries, i'm sure you learnt some sparring with it (i keep doing, eventhough i left C, Forth,Java, mind you, VBA! and stopped counting the years after 50 too!). Though i prefer to fiddle with the shell and occasionaly JS and consorts, I do appreciate the power of the others (maybe less JAVA for betraying as a (supposedly) light client "they" promissed 1st and now being everywhere!). > Merci beaucoup indeed. I did not realize it was fixed, and now > that i look, i find my own thing broken even. (Vielen Dank.) Well, i don't know much about the actual fixed state as i don't have an official static binary to test. Nonethless, if i undertand what Denys wrote earlier, I'm suspicious on that matter : > I tested both cases in current git and both work > correctly (the results are the same as in bash). since bash also had the inconsistent behaviour for starters... An extra layer of mine pro bins (not excluding the stone written source code obvioujsly!) : 1. "Real men do it themselves!" This rather conservative reasoning from the beardies of 60s-70s (though i only shave once in a while, so no reproch here :-) goes against many modern precepts : 1. ecolo : less synergy, inefficiently wasting energy and brains 2. ignoring the encapsulation/mudularisaation strategy of the blackbox in other words : lack of "trust" then there goes down the drain all the crypto, the socialwhaever-stuff... 2. "re-inventing the wheel" (the french have something for the 'fil a couper le beurre' but since i never used one (butter always comes prepacked nowadays) but yes repeating same tasks againand again with no gain but the satisfaction of having done something (well documented by Goldratt in his TOC). This would mean, following that philosophy that all should be adquired in kits to be mounted (compiled) by ourselves be it cars, bikes, drills, hovens, monitors... I got to the baker and asked for bread and she handed me a bag of flour, some salt and some yeast : "that's how we do things from now on, feel gratefull the flour is already ground!" when she saw my surprised face. Obviously not the world we live in... so... I'll stop here because there would be much to add and i's go further than just code but more to the core of our current social world (hopefully, i'm running my last miles, gotta leave the troubleshooting to the next generations) At least, in the bb's community, devted to optimisation and capability of fitting anywhere (à la swissknife) i'd expect this train of though to resonate right and lead to some kindhearted dev to rpovide the necessary bin to lower the barrier of entry to those lioke me, living in the user world but still ready to test and report if nothing more. On this and much more, whish you all seet dreams or lines of code, JClu 202510164 ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re?: Re: Re?: Re: unexpected behaviour of bb's arithmetic ternary operator
So... > # make this work with (ba)sh \ > command -v shopt && shopt -s expand_aliases;\ > alias p=printf;alias e=echo;alias s=export > s I1=10 I2=20;p "<$((I1+=I2+=I1+=I2))>";e "<$I1><$I2>" > s I1=10 I2=20;p "<$((I1+=I2+=I1+=I1))>";e "<$I1><$I2>" > > which gives for my code > #?0|kent:tmp$ busybox.static sh t2.sh > <80><80><50> > <60><60><40> > > and for bash and plain bb > > #?0|kent:tmp$ bash t2.sh > shopt > <60><60><50> > <50><50><40> > ...$ busybox sh t2.sh > <60><60><50> > <50><50><40> > > Where a C proof (what i want) gives > ... > <80><50> > <60><40> more simply for a weak mind like mine a=1 b=2; echo $((a+=b+=a+=b)) parsing it from right to left : a=a+b=1+2=3 then b=b+a=2+3=5 and finally a=a+b=3+5=8 BUT, indeed, bAsh returns 6 however bb 1.37 gave me the expected 8 my question will then be, with all due respect for the demonstration you given, Was ist das? more precisely, how is it related to the ternary operator (construct 'a?b:c') ? You end up writting about "recursed conditionals" but though i can imagine a form of stack recursion to parse the above cascade of "+=", i pain to witness the conditional side of it. Sorry for not seeing what might be ovious for you so maybe can you help me connecting the dots? Be the night a good friend to us all, Jclu 202510142 ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re?: Re: unexpected behaviour of bb's arithmetic ternary operator
Denys Vlasenko Steffen Nurpmeso @Steffen : as far as algos are concerned and from what can be observed with the "tri" script's outputs, it works fine ... at least with args with small names (1character preferably though :-). So the trouble seems to rather reside in the stage where the args are adquired and the probably stored with some generic token stcked to them in some stack area... BTW, i did sthg similar to circumvent the tri-problem in my own script : [code] # #!# 202510131 : submitted bug report to bb's mailing list # crtLine="$(( pnHeight old way still fails ! : # [ "$pnHeight" -lt "$crtFNum" ] \ # && crtLine=$((crtFNum-pgStart+1)) \ # || crtLine=crtFNum # also failed! # #!# quick dirty fix x=$crtFnum y=$pnHeight z=$pgStart crtLine="$(( y == 2 xx yy 888 <44 -2 555> -- == bash == 1 888 <44 10 333> == 2 xx yy 888 <44 10 77> -- ((i admit not having pushed any further like, the way i lke, adding command expansion in the RHS of the construct : simple and reprocutible for the report purpose)) BUT, both bb AND bash lose consistence with the tri-script also discussed above with Steffen. See : ((same versions as above)) + crtFnum=1 + pnHeight=48 + pgStart=1 + echo '1 48 1' 1 48 1 + echo 0 0 + a=1 + b=48 + c=1 + echo '1 48 1' 1 48 1 + echo 1 1 + crtFnum=1 + b=48 + c=1 + echo '1 48 1' 1 48 1 + echo 1 1 + crtFnum=1 + pnHeight=48 + pgStart=1 + echo '1 48 1' 1 48 1 + echo 1 1 + crtFnum=1 + pnHeight=48 + pgStart=1 + echo '1 48 1' 1 48 1 + echo 1 1 I onoly pasted one's results since they are identical... which i don't understand. And what puzzles me the most, again, it's not the initial error (0) but the fact it becomes *correct* (1) after a few script lines. (both scripts were attached to my 1st submission) I would greatly appreciate if you could make a static binary of the version you mentionned preferably within "https://busybox.net/downloads/binaries/";. This way i can proceed with some more tests to confirm (and selfishly use it for my own purpose of course). allow me, here, a little rant on : "why do i insist on "official" static builds?" static bins are immediatly usable (off the shelves) with no dependencies, install and often confusing steps before being able to do anything with the targeted app. Sadly this kills the joy of accessing real jewels out there and rebuke most potential users. Do i reject sources and compilation and so on? not at all but quite the contrary, they go hand in hand and help each other side of the usage spectrum. with the source you can, as a user, fine tune the compilation to your need and platform|context and as a developper, in the language of the source of the bound ones if any, add/remove/mod its *mechanics*. In short Statics are ready yo use, test, deploy, share with whoever without worrying about their CS literacy (just like live distros vs install distros... BTW i'm on TCL 10, been years) official (as in found in official repositories, and even signed)? well i can see at least a couple reasons : - the reference when discussing bugs for instance : we'll know that the bug is not due to some user's local particularities (HW, compile options, other libs or even previous versions in $PATH...). - Another reason : trust from all users (techies or normies :-) that know they can go and just grab, no malicious content (as far as history follows) ... which does't mean there won't be bugs and other unforseen situations (like now). But we no better (working) alternative i'd call this the ideal deal. So yeah, give me the baby and i'll torture it the proper way till it screams truth (or dare?). Meanwhile, thank you both for your kind attention and i hope to hear good news.. sooner than later JClu 202510142 ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re: Re?: Re: Re?: Re: unexpected behaviour of bb's arithmetic ternary operator
[email protected] wrote in <149260832.19127213.1760476357139.javamail.r...@zimbra33-e6.priv.proxad.\ net>: |So... ... |my question will then be, with all due respect for the demonstration \ |you given, | Was ist das? |more precisely, how is it related to the ternary operator (construct \ |'a?b:c') ? not at all, it was all only in respect to posting my (stupid, fat and wrong) own variant of the Dijkstra two-stack arithmetic evaluator in 2022. ... |Be the night a good friend to us all, ... --End of <[email protected]\ v.proxad.net> [email protected] wrote in <334885832.19175664.1760477434919.javamail.r...@zimbra33-e6.priv.proxad.\ net>: |> And it really is only that ... |Noch einmal, vielen Danke Merci beaucoup indeed. I did not realize it was fixed, and now that i look, i find my own thing broken even. (Vielen Dank.) |JClu |202510142 --End of <[email protected]\ v.proxad.net> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re: Re?: Re: unexpected behaviour of bb's arithmetic ternary operator
Steffen Nurpmeso wrote in <20251014150506.266_CLHJ@steffen%sdaoden.eu>: |[email protected] wrote in | <612664271.16313594.1760439377633.javamail.r...@zimbra33-e6.priv.proxad.\ | net>: ||Denys Vlasenko ... |Wow -- he really did get the "several times recursed" conditionals |right with the current code!?!?!? I really will have to look. And it really is only that 6a0ba673820cb6880e2f93f739de7d16d45d2b26 .. - expr1->val = top_of_stack->val; - expr1->var_name = NULL; - return NULL; + rez = top_of_stack->val; + top_of_stack = expr1; + goto ret_rez; thing? Pfff that hurts, really. I will have to look more thoroughly when i have time for *that*! Thank you. I will go cycling into the darkness.. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
