ReactOffice

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

ThePhysicist
Developer
Posts: 509
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist »

oiaohm wrote: Ok not knowing C I will forgive this. I really will forgive this. The outputed Basic to C Transaltor is the worst optmised C code I have ever seen. Also some of the worst code I ever had to read as well.
Small section of defect in it there is a lot more other problems BCX has.

Code: Select all

printf("%s%s%s\n","constantstring ",var," constant string");
printf("%s\n","string with more info");
How it should look

Code: Select all

printf("constantstring %s constant string\n"
          "string with more info\n",var);
One function lot faster less processing required. Difference come more displayed the more unreqired functions there are.
Sorry, but "less code and fewer functions = more speed" is in most cases C-Coder's misbelief. (like some people believe that i++ is faster than i=i+1)
The 1st function 1 only about 1% slower. In fact the following function would be the fastest:

Code: Select all

	printf("constantstring ");
	printf(var);
	printf("constant string\nstring with more info\n");
IMHO the printf function is horribly implemented and that it gets slow and ugly is not a fault of the translator, but the fault of the person who developed that function.
Still faster than normal bytecode. BCX really does not get the best out of C. BCX really needs a rewrite. Compliers can optimise code but they normally don't optimise function calls like printf. BCX really need to optmize the code it forms a lot more. Yes the outputed code would be less basic like and a little harder to debug but that would be worth it.
I wouldn't agree here. The translator should produce clean C code, not ugly optimized shit. Then you could also use asm, that's probably the best optimization.
Personal clean up of a BCX program C source I have seen runtimes in places cut to about 10 percent of what it was taking that is a lot faster.
I would doubt that it would get 10 times faster, but of course optimization is something that has to be done after translation.
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

Ok please look at BCX ThePhysicist.

Ok my code was not perfectly optmised. Still readable.

ThePhysicist code broke good practice. Never pass a var straight into printf. Not good at all as it allows a exploit.

puts should have been used instead of printf in ThePhysicist code to be safe. No exploit and faster. I was not trying to optimise it to best to at least something clean.

The processing I was refering to was the number of %s the first function had to do. A call had been removed as well. ThePhysicist had avoid all processing at all in printf. Yes this is slightly faster than my example but how readable is it. printf Internal processing is not that great. 2 lines fair simple code geting a 1 percent boast stuff produced from BCX gets alot more complex than that.

First function is only about 1% slower. I said at times I got 10 times some sections that BCX produces are down right nasty.

Code: Select all

PRINT CHR$(10),"This is the help on how to use X program",CHR$(10)
Notice CHR$(10) are constant never changing.
Output form memory

Code: Select all

printf("%s%s%s\n",chr$(10),"This is the help on how to use X program",chr$(10));
Now really this does need the optimisation to be readable let alone anything else.

Code: Select all

printf("\nThis is the help on how to use X program\n\n");
That is far more readable faster and neater.

It needs to be optimised into clean C not badly formed mess. BCX is not producing what I call clean C.

Little faster would be using puts instead of printf. Since no var work is performed.

Other problem is.

Code: Select all

PRINT "stuff"
PRINT "stuff"
....
Becoming

Code: Select all

printf("%s\n","stuff");
printf("%s\n","stuff");
...
Merging into a single puts or printf when suitable can save a lot of time. And be less messy.

Code: Select all

puts("stuff\n"
       "stuff\n"
...
 );
I only did a simple example first of the problems get verry complex.

As I said at times up to 10 times faster in places.
A printf or string operation with a lot of static chr$ and other $ ending functions calls is slow.
Same funciton with the static calls canceled out can end up as a simple puts or printf function.

Only reason why it would be harder to debug is because the BASIC code and the C code would no longer have a one to one releation ship. I have never understood way BCX demard this.

Note these faults also extend to string operations and the like. BCX has lots and lots of problems. It needs some optimisation to produce what I would call simple human readable code.

Also i++ is faster than i=i+1 on some C compliers.
Thinking that in asm on some compliers i++ gets replaced with a INC and
i=i+1 gets replaced with ADD function INC does not need to get two values and is also smaller in size than a ADD at asm..
Only if your complier optimises correctly are they the same speed. i=i+1 will be swaped for a INC if INC is faster on the processor chip or i++ will be swaped for a ADD if that is faster on the processor chip.

Learnt that one the hardway coding for avr chips. First complier I had was shoddy almost no optimization. Direct one to one conversion type from C to asm in places.

Note on some avr chips i++;i++ is faster than i=i+2 let alone i=i+1;i=i+1;. Number processing is bad on some of them yet inc works at a perfect good speed.

I guess another teacher is around some where not knowing the resaults of optmisation corrections on produce on code. And the fact that not all compliers do them. Because my teacher told me the same thing that they were the same no difference. It would have saved me hours knowing the truth of the matter. Why some code I was looking at had no i++ and all i=i+1 and other code had all i++ and no i=i+1. This was because the programmer was doing the opimisation instead of the complier.
michael79

Anyway...

Post by michael79 »

Anyway I'm building a GUI application. So, I will not
use printf.
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

Sorry to say you will most likely be using printf releations with the same defective processing.
FPRINT stream "stuff"
fprintf(stream,"%\n","stuff");
Ie string to file. I guess you will be using this.
var="stuff"+"stuff"
sprintf(var,"%s%s","stuff","stuff");
Processing into strings and the like joining.
This is worse because there are special functions that do string joining and copying a lot faster than sprintf even could.

BCX complete string processing system is shot. It needs work. If you are going to use BCX you will have to learn C to clean it up. Might find it simpler to do it in C first. No double handling.

This is a tip of the ice. I really do mean tip.

Just process the BC.bas source into .C and then look at the mess. Ask yourself would you ever want to read that. Its also not very effective in any way. Small understanding of C can tweek BC.bas outputed programs speed far more than what most people would expect.
avryhof
Posts: 35
Joined: Sat Dec 18, 2004 7:56 am
Location: Brewerton, NY
Contact:

SIAG

Post by avryhof »

I would like to see something to SIAG (Scheme In A Grid) Office under ReactOS...

It has it's own unique features, and it's very lightweight.

OTOH, it might not matter soon with Writely, Google Spreadsheet, Google Page Builder and Gmail.... who needs Word, Excel, PWS, Frontpage and Exchange anymore?
temarez
Posts: 117
Joined: Sat Dec 10, 2005 10:52 pm
Location: Ukraine
Contact:

Re: ReactOffice

Post by temarez »

michael79 wrote:It should have a bit more features than Wordpad but a lot less than Word or Writer. I will also start a Word/Calc, Powerpoint/Impress, Publisher/Draw and Access/Base clone.
BTW, there is already good tiny spreadsheet with Excel files support and it
works quite good in ReactOS. But it is shareware :-(
avryhof
Posts: 35
Joined: Sat Dec 18, 2004 7:56 am
Location: Brewerton, NY
Contact:

Re: ReactOffice

Post by avryhof »

temarez wrote:
michael79 wrote:It should have a bit more features than Wordpad but a lot less than Word or Writer. I will also start a Word/Calc, Powerpoint/Impress, Publisher/Draw and Access/Base clone.
BTW, there is already good tiny spreadsheet with Excel files support and it
works quite good in ReactOS. But it is shareware :-(
There is also Sphygmic Software Spreadsheet which is freeware...

Of course it's not very up-to-date either...
michael79

Re: ReactOffice

Post by michael79 »

avryhof wrote:
temarez wrote:
michael79 wrote:It should have a bit more features than Wordpad but a lot less than Word or Writer. I will also start a Word/Calc, Powerpoint/Impress, Publisher/Draw and Access/Base clone.
BTW, there is already good tiny spreadsheet with Excel files support and it
works quite good in ReactOS. But it is shareware :-(
There is also Sphygmic Software Spreadsheet which is freeware...

Of course it's not very up-to-date either...
Yes, I know. But it's not OpenSource.
MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

michael79 wrote:
MadRat wrote:rospad is a catchy name for something like that.
A pad has no rich text capabilities. There will also be a Calc, Impress,
Draw and Base equivalant. I might only rename ReactOffice Writer
As ReactPad or RosPad.

Thanks for the name idea. :wink:
You do realise that there is the ever famous wordpad that does have rtf capabilities. :)
*************************************
Go Huskers!
Ged
Developer
Posts: 925
Joined: Thu Sep 29, 2005 3:00 pm
Location: UK

Post by Ged »

MadRat wrote: You do realise that there is the ever famous wordpad that does have rtf capabilities. :)
I started implementing the ReactOS wordpad a while back.
Maybe I'll finish it one day ;)
charlieg
Posts: 6
Joined: Fri Jul 14, 2006 2:58 pm

Post by charlieg »

Ged wrote:I started implementing the ReactOS wordpad a while back.
Maybe I'll finish it one day ;)
ReactOS should just adopt Notepad++ and be done with the rest of the mess of notepad/wordpad clones. Notepad++ is awesome and lightweight despite having a ton of great features.
Coviti
Posts: 300
Joined: Wed Mar 01, 2006 4:26 am

Post by Coviti »

charlieg wrote:ReactOS should just adopt Notepad++ and be done with the rest of the mess of notepad/wordpad clones. Notepad++ is awesome and lightweight despite having a ton of great features.
Hmm... no. See my response to your thread.
Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Re: SIAG

Post by Matthias »

avryhof wrote:I would like to see something to SIAG (Scheme In A Grid) Office under ReactOS...
OMG, an Office suite written in Scheme :shock:. That is soooo cool i can't believe it. What a pitty that there are no debian packages :(
Ratteler
Posts: 28
Joined: Sun Oct 09, 2005 4:31 pm

Post by Ratteler »

Ussually the cut down Generic Office suit is called "Works".

MicrosoftWorks
ClarisWorks
AppleWorks

How bout ReactWorks?

As for making it worth while. I would rather see it as an AJAX project. A RoS Distro will most likely ship with the latest OO pre-installed, and I doubt a VBasic app would ever be lean enough to make it worth using istead of OO.

However, an basic Office suite that ran in a Browser could be useful to everyone.

Just my opinion though.
Floyd
Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd »

why even bother YATE (yet another text editor). there are like 5 billion word editing programs and several free office type programs. the best known one, of course, is openoffice (OOo). personally, i'd rather have reactOS ship with a notepad (like notepad++) and wordpad replacement and then either have 1) distros come with OOo or 2) just have it as part of the "package"/MSI installer interface (unless this is just a coding excercise--in that case, cool, include it)
pax mei amici amorque et Iesus sacret omnia
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 46 guests