2.5 bug reports

Simulated dice for role playing games
kelvSYC
Honored
Posts: 73
Joined: Sat May 29, 2010 5:16 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by kelvSYC » Mon May 31, 2010 7:18 am

Dicenomicon appears to crash if you press the "f(" button while a die with a (custom?) roll macro is selected.

kelvSYC
Honored
Posts: 73
Joined: Sat May 29, 2010 5:16 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by kelvSYC » Mon May 31, 2010 5:58 pm

Apparently when making a global function, adding in an "elif" messes up the syntax. I go from "if 0 then 0 else 0 end" to "if 0 then elif elif 0 then". You can change the first elif to 0, but you seem to be unable to add back the else portion of the if at all.

jazzman
Honored
Posts: 63
Joined: Mon May 31, 2010 1:13 am
IQ Test: Orange

Re: 2.5 bug reports

Post by jazzman » Mon May 31, 2010 8:59 pm

I'm getting a crash when trying to an if statement after a sort command.
So sort(1d6,1d6), If $1>=3 then "Greater" else "Less" end.
Change sort to rsort and the system doesn't crash.


Additionally, when having multiple if statements, the text is shifting to the left for each statement. So after a couple statements things like the periods are off the screen.
Here's an example.
(Rd12, Gd12, Bd12). @1 <- low1($1, $2, $3). @2 <- high1($1, $2, $3). @L <- "Low: " + @1, if @1 = $1 then "Red" else "" end, if @1 = $2 then "Green" else "" end, if @1 = $3 then "Blue" else "" end
So basically, for the last if statement, the first letters of each line is not visible.

All on iPhone 3gs

gandreas
Immortal
Posts: 1464
Joined: Wed Feb 04, 2004 6:02 pm
Contact:

Re: 2.5 bug reports

Post by gandreas » Tue Jun 01, 2010 10:08 am

jazzman wrote:I'm getting a crash when trying to an if statement after a sort command.
So sort(1d6,1d6), If $1>=3 then "Greater" else "Less" end.
Change sort to rsort and the system doesn't crash.
Sweet! It crashes nicely, exactly as you describe!.

And trivial to fix as well. The problem was that sort() returned an immutable array, and using the "," operator tries to append the result of the if statement. Which is bad.
rsort correctly returns a mutable array, so no problem.
A quick work around is to do "reverse(rsort(1d6,1d6)), if ...."

Additionally, when having multiple if statements, the text is shifting to the left for each statement. So after a couple statements things like the periods are off the screen.
Here's an example.
(Rd12, Gd12, Bd12). @1 <- low1($1, $2, $3). @2 <- high1($1, $2, $3). @L <- "Low: " + @1, if @1 = $1 then "Red" else "" end, if @1 = $2 then "Green" else "" end, if @1 = $3 then "Blue" else "" end
So basically, for the last if statement, the first letters of each line is not visible.

All on iPhone 3gs
I just noticed this this morning when tracking down some other support issues, but it didn't register what I was seeing (since it was only shifted by a couple of pixels, so something looked "not quite right").

Hopefully this will be as easy to deal with as the sort vs rsort problem...

kelvSYC
Honored
Posts: 73
Joined: Sat May 29, 2010 5:16 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by kelvSYC » Tue Jun 01, 2010 3:14 pm

There seems to be a problem with entering a for loop on the iPhone keypad. It's only fine if it is blank. Even something like entering "1 + for ..." crashes the app, and on other occasions, I get this unparseable "0 @ I ..." stuff instead of the full for loop construct.

gandreas
Immortal
Posts: 1464
Joined: Wed Feb 04, 2004 6:02 pm
Contact:

Re: 2.5 bug reports

Post by gandreas » Tue Jun 01, 2010 5:34 pm

While there is probably a bug in there (I'll check into it), you'll want to have things that combine if and for expressions with other things by putting them inside parenthesis:

Code: Select all

1 + for ...
= wrong

Code: Select all

1 + (for ...)
= right

It has to do with some weird precedence rules ("if" and "for" expressions are right up at the very top, just below "," and "." when they should be somewhere much less important due to their pre+in+post fix syntax, but changing this may have negative impact on existing formulas).

kelvSYC
Honored
Posts: 73
Joined: Sat May 29, 2010 5:16 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by kelvSYC » Tue Jun 01, 2010 9:56 pm

It appears that you can't use $1 with textual dice. At least, the iPhone keypad doesn't allow it. I've had to use something real kludgy like

Code: Select all

@1 <- KtZod12.
"Swap"+@1+"with"+@ZODOP(@1)
where one line would have sufficed. I'm not sure if it's a bug or a feature, but it is of note to me.

(ZODOP is a function that returns the "bottom face" of the zodiac die given the top face)

kelvSYC
Honored
Posts: 73
Joined: Sat May 29, 2010 5:16 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by kelvSYC » Tue Jun 01, 2010 9:58 pm

Another bug: the syntax highlight in the web interface apparently does not support the highlighting or indentation of for expressions. (Having said that, for expressions weren't documented at all, so...)

jazzman
Honored
Posts: 63
Joined: Mon May 31, 2010 1:13 am
IQ Test: Orange

Re: 2.5 bug reports

Post by jazzman » Wed Jun 02, 2010 7:55 pm

Hitting the login button in the app for the forum takes me to a page with Register and Login at the top and the bottom is blank. I can not log into the forum.

I also when trying to copy from the forum in the app, It seems to have problems pasting all of the data, most of the time it seems it has issues when the selected text does it as a "block" of lines, it will not paste everything.

jazzman
Honored
Posts: 63
Joined: Mon May 31, 2010 1:13 am
IQ Test: Orange

Re: 2.5 bug reports

Post by jazzman » Thu Jun 03, 2010 5:07 pm

Got another here.

When Rolling open ended die, if you hit the min/max number, all other dice will lock in the position while the others explode.

The issue I found is that if you shake the device while those die are exploding, it re-rolls those few dice. The dice that were "locked" will not re-roll. Additionally, because it re-rolls those few, It looses the fact that they were exploding and will take them at the new face value.

Could see someone accidently loosing the exploded die.

kelvSYC
Honored
Posts: 73
Joined: Sat May 29, 2010 5:16 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by kelvSYC » Tue Jun 08, 2010 5:23 pm

I can consistently reproduce the bug where calling a recursive function or anything relying on a recursive function crashes the app. (Note that this is functions only. Anything relying on a recursive :next: call isn't affected).

Consider this function, SEQ2:

Code: Select all

if #2 > length(#1) then #4
elif #1[#2] = #1[#2 - 1] + 1 then
	if #3 < #4 then @SEQ2(#1, #2 + 1, #3 + 1, #4)
	else @SEQ2(#1, #2 + 1, #3 + 1, #4 + 1) end
else @SEQ2(#1, #2 + 1, 0, #4) end
You can enter it in the web editor, and it will validate, but it will crash the app if you use it. If you select the function from the iPhone interface, it will crash the app. If you create a function that calls this function and use it, it will crash the app.

BTW, this is probably the function that you would use if you wanted to find the length of the longest sequence in a list - good for games where you have to detect runs of varying length in dice rolls.

gandreas
Immortal
Posts: 1464
Joined: Wed Feb 04, 2004 6:02 pm
Contact:

Re: 2.5 bug reports

Post by gandreas » Tue Jun 08, 2010 6:04 pm

Recursive functions are flat out not going to work. Due to the underlying "evaluate everything" model, this requires infinite evaluation, and generally won't work.

However, if you have a list of numbers and want to find the longest "run", take advantage of the list powers:

Code: Select all

@1 <- (0,3,5,3,2,5,4,6,9).
@1 <- unique(@1).
@1 <- sort(@1).
This gives us a sorted list of unique values (with the same data set, we get (0,2,3,4,5,6,9)

Now go through the list, and if the current element is the last element + 1, then were doing good, and potentially update the best seen so far:

Code: Select all

@next <- 99999.
@start <- 99999.
@len <- 0.
@bestLen <- 0.
@bestStart <- 0.
for @I in @1 do
  @len <- (if @next = @I then @len+1 else 0 end).
  @start <- (if @len then @start else @i end).
  @bestStart <- (if @len > @bestLen then @start else @bestStart end).
  @bestLen <- @len \/ @bestLen.
  @next <- @l + 1.
end.
"From", @bestStart, "to", @bestStart + @bestLen+1.
(this is all typed while waiting for Xcode to install, so I haven't had a chance to try it out)

kelvSYC
Honored
Posts: 73
Joined: Sat May 29, 2010 5:16 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by kelvSYC » Tue Jun 08, 2010 6:43 pm

I don't get why, for a functional language, a key functional language concept like recursion would break so badly. Yes, I could probably reimplement everything with iteration, but what I don't get is what you mean by "evaluate everything" means: is it the evaluation strategy (strict vs lazy)? Is it the fact that nearly everything is precomputed? Or is it just the fact that you enforce some kind of compile-time constraint (the program precomputes the evaluation of the function as you are changing it, which it cannot do for recursive functions)?

Curious but odd. Still, it's still a valid bug, in the sense that if you are to ban recursion, then you shouldn't be able to have it validate on the web interface either. (Right now, I have that exact same function, and trying to access the function in order to delete it crashes the app. Go figure.)

kelvSYC
Honored
Posts: 73
Joined: Sat May 29, 2010 5:16 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by kelvSYC » Wed Jun 09, 2010 5:16 pm

In a global function, you are unable to use for loops, though you are able to enter it. Apparently, anything in a for loop call is zeroed out.

Test case:

Code: Select all

@1 <- 0.
for @I in #1 do @I end.
1
When you save (or validate on the Dicenomicon server), you get this instead:

Code: Select all

@1 <- 0.
0

Gramg
Posts: 13
Joined: Fri Oct 09, 2009 10:57 pm
IQ Test: Orange

Re: 2.5 bug reports

Post by Gramg » Wed Jun 09, 2010 7:45 pm

Editing a formula via web server empties parameter definition. As well, web editor set parameters do not get saved.

Post Reply