I'm in doubt if RobboLito is a clone

[Titu]

I don't speculate. Zach has based a definitive conclusion based on the inconclusive. Even if he were right.......

What goes around comes around...

That does not make it right, to say the above statement. If he really feels that way, the victory of revenge is most often only piric.

Christopher

It's certainly not inconclusive to me. There is no question what took place to me, and several other people.

Vas has made what I would guess is quite a bit of money dishonestly by stealing from open source. Allowing open source to benefit from what he has done is only fair IMO. I suppose two wrongs don't make a right, but one wrong doesn't either.

I think this whole situation would be a bit different if the atmosphere in the community were different. Nobody, minus a very select few, listened to the concerns that were made about Rybka 1. I don't want Vas to quit, I just want everyone to acknowledge what actually happened, Vas included.

Vas has not made any money by Rybka 1.0, it was free.

The people who is gonna benefit most are the other commersial program makers. They will be able to close the gap and sell more of their programs.

[bob]

This is completely false. There is no need to have the sources from Rybka to confirm Ippolit/RobboLite are clones.

Nothing more is needed than a compile of either of the clone engines and Rybka loaded in a debugger/disassembler. (And someone who knows what he's doing)

You are absolutely right!

More correctly, he is "theoretically absolutely right". Practically right requires that someone actually be willing to do this task. "De-compiling" is beyond a PITA. Far from impossible, but not something one might undertake "just because". If someone were to offer me enough money so that I could take a year off, I'd tackle this in a minute. But it would have to be worth my time, as time is limited and we are currently busily making progress with Crafty daily. I'm not so interested in putting that on hold just to prove what happened in any of these copy/clone cases.

I'm not familiar with decompiling, hence this question:

Some folks wrote it would be easy to get C code from a (Rybka) binary with some clever tool (don't remember the name). If that is true then why do you think it will take a year to complete this proof task? The last sceptics should be convinced as soon as the decompiler generates *some* functions that are similar to those found in IPP/ROB (most probably with enumarated variable names) -- [Similar in the sense that they treat input variables and global variables in identical manner and produce the same output]?

If I had exactly the same "tool" as the cloners, assuming this is what happened, it would be easy. But taking asm code and "de-compiling it" is not a one-to-one process. It is a "one-to-many". That is, there are many C programs that could turn into the same optimized binary. If I use tool A and get source A1, and you use tool B and get source B1, A1 and B1 might be significantly different.

The way you actually have to do this is take a source program and ask, "Given this binary, can I use _every_ assembly language instruction, and conver those into C that looks like the C program we are trying to identify. That is as much "art" as it is "science". Compilers mangle the binary code badly during optimization, everything from in-lining functions to re-ordering instructions to reduce / eliminate memory latency delays or data/name/control dependencies.

It helps to have the target you are trying to reach (the C-source in question) but it it still quite a task to turn the binary into C at all, much less into C that looks similar or identical. And even if you do, there are those that will claim it is made up (as happened the last time this discussion erupted).

[Sven]

Do you realize how difficult it is to remove comments?

Given that C doesn't allow nesting them, I'd say it's trivial? Did I miss anything?

(I don't disagree on anything else you said - just nitpicking here)

The only way I know to do it is by hand. Going the pre-processor route is a pain in the ass if you want to release the code because macro expansions are done by the preprocessor and that would wreck the source if the macros depend on the target architecture which is not known until someone uses the source.

I did this a while back when fooling around with the nintendo DS guys. And it was somewhat painful. Edit 50+ files, remove the comments. Compile, get errors. Or something is broken, diff the files to see what I deleted by accident, etc.

I would not consider removing something that took so long to write in the first place.

Given that you are quite familiar with UNIX, may I assume that next time you will be forced to remove comments, you'll do it without using a text editor but instead with a script like this?

Code: Select all

#!/bin/sh

# works as a filter
# assumption: no TABs contained in the source
egrep -v '^ *//.*$' \
| sed \
-e 's? *//.*$??' \
-e 's?/\*.*\*/? ?g'

Sven

[tvrzsky]

Given that you are quite familiar with UNIX, may I assume that next time you will be forced to remove comments, you'll do it without using a text editor but instead with a script like this?

Code: Select all

#!/bin/sh

# works as a filter
# assumption: no TABs contained in the source
egrep -v '^ *//.*$' \
| sed \
-e 's? *//.*$??' \
-e 's?/\*.*\*/? ?g'

Sven

Exactly, I do not see reason to do it manually. And as I have mentioned early, if you compare ippolit.c source, ipp_eng.c source and Robbolito sources, you can see that IMHO all three of them stem from some other original source and are automatically translated so the code we have is not handwritten but generated.

[tvrzsky]

I always go for the simplest explanation. We have a few here that try explanations that are so incredibly convoluted they would defy any sort of rational approach to writing software.

I think that you overestimate rationality. Whoever he is the guy(s?) plays some crazy game with us. He has just different patterns of behavior than let's say you or me.

[bob]

Do you realize how difficult it is to remove comments?

Given that C doesn't allow nesting them, I'd say it's trivial? Did I miss anything?

(I don't disagree on anything else you said - just nitpicking here)

The only way I know to do it is by hand. Going the pre-processor route is a pain in the ass if you want to release the code because macro expansions are done by the preprocessor and that would wreck the source if the macros depend on the target architecture which is not known until someone uses the source.

I did this a while back when fooling around with the nintendo DS guys. And it was somewhat painful. Edit 50+ files, remove the comments. Compile, get errors. Or something is broken, diff the files to see what I deleted by accident, etc.

I would not consider removing something that took so long to write in the first place.

Given that you are quite familiar with UNIX, may I assume that next time you will be forced to remove comments, you'll do it without using a text editor but instead with a script like this?

Code: Select all

#!/bin/sh

# works as a filter
# assumption: no TABs contained in the source
egrep -v '^ *//.*$' \
| sed \
-e 's? *//.*$??' \
-e 's?/\*.*\*/? ?g'

Sven

Beyond dangerous, which is why I don't try that. What if I have "/*" in a string such as what one might pass to strtok()? Or "*/*. And some use // comments as well. That also makes assumptions about the location of the */ which is not always correct. Not all my comments are blocked either. so the /* and */ can appear anywhere in a line. Since I have never seen a reason to _remove_ comments that makes any sense, I've not taken the time to write an awk (easier than sed IMHO) to make this happen, and verify that it works for all code in Crafty, written by several people (including Eugene N).

Also, leaving a ton of blank lines is not exactly aesthetically pleasing either.

For the record, I tried the above on one function and it failed miserably. That's why I didn't try to write such a thing. Non-trivial to debug the script, then verify that it didn't remove an extra line here and there. Doing it by hand I can be much more certain.

[Ryan Benitez]

This is completely false. There is no need to have the sources from Rybka to confirm Ippolit/RobboLite are clones.

Nothing more is needed than a compile of either of the clone engines and Rybka loaded in a debugger/disassembler. (And someone who knows what he's doing)

You are absolutely right!

More correctly, he is "theoretically absolutely right". Practically right requires that someone actually be willing to do this task. "De-compiling" is beyond a PITA. Far from impossible, but not something one might undertake "just because". If someone were to offer me enough money so that I could take a year off, I'd tackle this in a minute. But it would have to be worth my time, as time is limited and we are currently busily making progress with Crafty daily. I'm not so interested in putting that on hold just to prove what happened in any of these copy/clone cases.

I'm not familiar with decompiling, hence this question:

Some folks wrote it would be easy to get C code from a (Rybka) binary with some clever tool (don't remember the name). If that is true then why do you think it will take a year to complete this proof task? The last sceptics should be convinced as soon as the decompiler generates *some* functions that are similar to those found in IPP/ROB (most probably with enumarated variable names) -- [Similar in the sense that they treat input variables and global variables in identical manner and produce the same output]?

I don't think it is true that there is a tool that will give you C code that you can recompile from Rybka. You can get asm in a debugger and reconstruct it though a hell of a lot of time and effort though.

[jwes]

Do you realize how difficult it is to remove comments?

Given that C doesn't allow nesting them, I'd say it's trivial? Did I miss anything?

Isn't there an emacs macro to do that?

[Michel]

I don't think it is true that there is a tool that will give you C code that you can recompile from Rybka. You can get asm in a debugger and reconstruct it though a hell of a lot of time and effort though.

There are tools that actually give you C code (http://en.wikipedia.org/wiki/Decompiler).

[jwes]

This is completely false. There is no need to have the sources from Rybka to confirm Ippolit/RobboLite are clones.

Nothing more is needed than a compile of either of the clone engines and Rybka loaded in a debugger/disassembler. (And someone who knows what he's doing)

You are absolutely right!

More correctly, he is "theoretically absolutely right". Practically right requires that someone actually be willing to do this task. "De-compiling" is beyond a PITA. Far from impossible, but not something one might undertake "just because". If someone were to offer me enough money so that I could take a year off, I'd tackle this in a minute. But it would have to be worth my time, as time is limited and we are currently busily making progress with Crafty daily. I'm not so interested in putting that on hold just to prove what happened in any of these copy/clone cases.

I'm not familiar with decompiling, hence this question:

Some folks wrote it would be easy to get C code from a (Rybka) binary with some clever tool (don't remember the name). If that is true then why do you think it will take a year to complete this proof task? The last sceptics should be convinced as soon as the decompiler generates *some* functions that are similar to those found in IPP/ROB (most probably with enumarated variable names) -- [Similar in the sense that they treat input variables and global variables in identical manner and produce the same output]?

If I had exactly the same "tool" as the cloners, assuming this is what happened, it would be easy. But taking asm code and "de-compiling it" is not a one-to-one process. It is a "one-to-many". That is, there are many C programs that could turn into the same optimized binary. If I use tool A and get source A1, and you use tool B and get source B1, A1 and B1 might be significantly different.

The way you actually have to do this is take a source program and ask, "Given this binary, can I use _every_ assembly language instruction, and conver those into C that looks like the C program we are trying to identify. That is as much "art" as it is "science". Compilers mangle the binary code badly during optimization, everything from in-lining functions to re-ordering instructions to reduce / eliminate memory latency delays or data/name/control dependencies.

It helps to have the target you are trying to reach (the C-source in question) but it it still quite a task to turn the binary into C at all, much less into C that looks similar or identical. And even if you do, there are those that will claim it is made up (as happened the last time this discussion erupted).

If I actually wanted to do this, I think I would go the other way. I would compile ippolit and see if I could find chunks of the binary that were similar, particularly the evaluation code and the pruning/extension code of the search.