Hi,

We just spoke about the freedesktop.org directory standards in another message thread and this made me think. ?Why isn't Lazarus using the GetAppConfigDir(False) as it's default location for all the IDE config files. It's hard-coded to $HOME/.lazarus/ directory for Linux (and probably other unix type OS's as well)?

I believe Lazarus IDE uses GetAppConfigDir(False) under Windows now, but why not for all platforms?

Also GetAppConfigDir(False) does not mean hard-coded $HOME/.config/ directory. The GetAppConfigDir() adheres to the freedesktop.org directory standards (for unix type
environments) that means $HOME/.config/ is simply the default directory if $XDG_CONFIG_HOME environment variable has NOT been set. The user can simply set the $XDG_CONFIG_HOME to point to another location if they please and GetAppConfigDir(False) will use that directory instead.

Regards,
?- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I think that

a) .lazarus was a logical choice for unix.

b) It is now historically so. Changing this now would mean that the current configuration breaks.

But if it bothers you, you can do the following:

ln -s ~/.lazarus ~/.config/lazarus

or even

mv ~/.lazarus ~/.config/lazarus
ln -s ~/.config/lazarus ~/.lazarus

:-)

Michael.

If it isn't broken, don't fix it.

> > I believe Lazarus IDE uses GetAppConfigDir(False) under Windows now, > but why > not for all platforms?

Correct. The change was needed, because more and more the executable directory was off limits for writing by ordinary users.

So what should it be set to keep the current config directory? If $XDG_CONFIG_HOME contains the same as $HOME, the result of GetAppConfigDir(False) will be ~/lazarus instead of ~/.lazarus.

Or use some alias, which adds --pcp=~/.config/lazarus to the command to start lazarus.

Vincent

Not necessarily. (breaking historical location). Lazarus could check the old location, for loading, import old config, and write to the new location (removing the old)
Once one or 2 releases have done this, and it can be assumed that the majority of people got updated, the check for the old location can go.

On the other hand it's a lot of work, for (imho) little gain. Anyway if the idea as such would found to be acceptable, and someone would judge the gain worth the effort, then this someone surely could provide a patch?

So question is, is the idea as such acceptable?

Martin

2009/6/3 Vincent Snijders :

If it isn't broken, don't fix it.

:-) Crappy answer.

Correct. The change was needed, because more and more the executable directory was off limits for writing by ordinary users.

So why not change all platforms to use the GetAppConfigDir(False) result? I'm a consistency freak. ;-)

So what should it be set to keep the current config directory? If $XDG_CONFIG_HOME contains the same as $HOME, the result of GetAppConfigDir(False) will be ~/lazarus instead of ~/.lazarus.

I know, but you can use OnGetAppName to inject a '.' as a prefix to the 'lazarus' name, but that's not the solution either. The point is, why does one platform use GetAppConfigDir() and other platforms don't. For a better answer, see my next comment below...

Even better would be, if Lazarus starts up (this code could be placed in the startlazarus application to keep Lazarus clean) and it sees the old profile location (~/.lazarus), prompt the user with a one time dialog, if they would like to migrate the settings to the new location. If yes, startlazarus could simply move ~/.lazarus to ~/.config/lazarus

Simple and clean. Also no fuss for the user.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/6/3 Martin Friebe :

So question is, is the idea as such acceptable?

I hope so. It promotes consistency with the freedesktop.org and it promotes consistency in Lazarus IDE itself so that ALL platforms use the GetAppConfigDir() location.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I used this before there was function GetUserDir: String.

Otherwise I would have chosen AppendPathDelimeter(GetUserDir)+'.lazarus';
:-)

That would be consistent across platforms without breaking older configuration files.

Vincent

En/na Graeme Geldenhuys ha escrit:

Which is (partially) broken under windows

Bye

Why can not define where we like to put our config dir, for example make a lazarus.ini lazarus.config in same Lazarus dir and then read the path from it.
I know i can use
--pcp=x:\workdir\lazarus
But that mean i must call lazarus from command prompt or make a shortcut for it.

2009/6/3 Zaher Dirkey :

Why can not define where we like to put our config dir, for example make a lazarus.ini lazarus.config in same Lazarus dir and then read the path from it.

Because the installation directory in not necessarily writable by users. Plus one install of Lazarus IDE could be used by many users, so a single profile location via lazarus.ini will not work. For example, we have a shared 64bit Linux server with Lazarus IDE installed. Many developer connect to that machine and use the same copy of Lazarus IDE, but the lazarus profile (user custom settings) are different for each user, in their home directories.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/6/3 Luca Olivetti :

Which is (partially) broken under windows

Did you file a bug report for this? If not, please do so. Also, is it a bug in GetAppConfigDir(False) function which means it's a FPC bug report, or is it Lazarus specific.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

That true, but if we leave empty "lazarus.ini" or not exist (for default), Lazarus will take the default path from the GetAppConfigDir.

En/na Graeme Geldenhuys ha escrit:

I /think/ it's a bug in GetAppConfigFile(false), but I cannot tell if it is a bug or a design decision.
I asked on the fpc-devel list

http:/msg12383.html

Bye

No, only too condensed. ;)

Well, looking at my home, it would be more "consistent" to keep it ~/.lazarus.

I think Linux is closer to BSD and OS X.
Does BSD and OS X follow the freedesktop "standard"?

And add the warning that this move means that older lazarus version won't find the configs anymore, that they will recreate the configs at startup and you will end up with two independent config directories.

Simple and clean. Also no fuss for the user.

Mattias

2009/6/3 Mattias Gaertner :

I'm not talking about consistency with other applications. I'm talking about consistency in the Lazarus IDE alone and it's various supported platforms. GetAppConfigDir(False) should return the correct location for each platform, be that Windows 95-2000, WinXP, Win Vista, Linux, *BSD, OS X. The Lazarus IDE should simply call GetAppConfigDir(False) and use the resulting location.

Otherwise the IDE is going to end up with a mess of.... if platformX then ... else if platfromY then .... etc... The whole point of FPC is remove that mess for the developer. "write once, compile everywhere" (tm)

I think Linux is closer to BSD and OS X. Does BSD and OS X follow the freedesktop "standard"?

I got no idea, I only use Linux. But I can tell you that BSD and OS X don't adhere to the same standards either, so you can't even compare those to together - what still against Linux. Then Win95 can't be compared to XP or Vista either, because there preferred profile directory is also in different locations. Hence the reason I say, GetAppConfigDir() should return the correct location for each platform. Lazarus IDE or any application written with Free Pascal should not care where that location is, they should simply use the directory returned by GetAppConfigDir().

And add the warning that this move means that older lazarus version won't find the configs anymore, that they will recreate the configs at startup and you will end up with two independent config directories.

A new version of the IDE is just that, a new version. It's meant to replace an old version. The newer version having improved features. Why would you want to go back to an old version. There are many things that change between released versions. They same thing happens in FPC. Many times a new version breaks my code, and I'm 100% sure I'm not alone.

Also any sane developer would know that if he is "evaluating" a new version first, backup your data or use a separate profile directory. When I test the beta version of Firefox 3.5, I do NOT use my existing Firefox v3.0 profile, I use a new test profile. They same applies for Lazarus.

Your statement is flawed. Even if the profiles stayed in the same location, if the developer opened their projects with a newer version of Lazarus, the .lpi file, .lfm files etc all get upgraded to the new properties and features of the newer Lazarus IDE and LCL. Then switching back to an old version will ALWAYS cause problems anyway. A moved profile directory is the least of there problems at that point.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

It does not *simply* call GetAppConfigDir. For example it considers the command line parameters.

Otherwise the IDE is going to end up with a mess of.... if platformX then ... else if platfromY then .... etc... The whole point of FPC is remove that mess for the developer. "write once, compile everywhere" (tm)

IDE code and add-ons use the GetPrimaryConfigPath, which do more than a simple GetAppConfigDir.

The breaks are caused by such changes.
Strange that you use that as argument.

You misunderstood me.
I said the IDE should show a warning and explain what will happen. That is not an argument against it.

My only arguments are:
Consistency: I don't see why this is more consistent Change: It is not compatible and will give some users some extra headache and it will give developers extra work to test and consider all cases.

Mattias

2009/6/4 Mattias Gaertner :

It does not *simply* call GetAppConfigDir. For example it considers the command line parameters.

Well that is hardly and issue... considering the following pseudocode:

if pcpParam then
  profiledir := pcpParamStr
else
  profiledir := GetAppConfigDir(False);

IDE code and add-ons use the GetPrimaryConfigPath, which do more than a simple GetAppConfigDir.

The end result is the same, no matter what you call the function. It returns a profile directory location.

My only arguments are: Consistency: I don't see why this is more consistent

Instead of having different behaviors (code) for different platforms, the GetAppConfigDir() could be used which makes the lazarus ide code simpler and consistent between supported platforms. The same code gets used for all supported platforms.

Change: It is not compatible and will give some users some extra headache and it will give developers extra work to test and consider all cases.

The developers shouldn't notice anything different. If they upgrade to the new version of lazarus, the 'startlazarus' program could notify the user that the profile directory moved, and then simply move it for them, and then continue loading the ide. If the user specific a --pcp parameter, that takes preference anyway, so no moving of profile directories will occur.

What the cause of the headache? The startlazarus program does everything for the developer.

As a quick test I applied the following patch which changed the hard-coded profile directory location to use GetAppConfigDir(False). I then moved my ~/.lazarus directory to ~/.config/lazarus and then ran lazarus as normal. Everything worked as expected, all my custom settings was detected.

============== profiledir.patch ===============
diff --git a/ide/include/unix/lazbaseconf.inc b/ide/include/unix/lazbaseconf.inc
index fd2cab1..0cef80b 100644
--- a/ide/include/unix/lazbaseconf.inc
+++ b/ide/include/unix/lazbaseconf.inc
@@ -141,7 +141,7 @@ end;
  ---------------------------------------------------------------------------}
 procedure InternalInit;
 begin
-  PrimaryConfigPath:=ExpandFileNameUTF8('~/.lazarus');
+  PrimaryConfigPath:=SysToUTF8(GetAppConfigDir(False));
   SecondaryConfigPath:='/etc/lazarus';
 end;

================= end ===================

I even started lazarus by running 'startlazarus' and 'lazarus' and in both cases, it worked perfectly. No headaches. :-)

========== console output ==============
$ ./startlazarus
TLazarusManager.Run starting /opt/git/lazarus_argon/lazarus ... TMainIDE.ParseCmdLineOptions:
PrimaryConfigPath="/home/graemeg/.config/lazarus/" SecondaryConfigPath="/etc/lazarus"
LAZARUS END - cleaning up ...
[TMainIDE.Destroy] A
[TMainIDE.Destroy] B -> inherited Destroy... TMainIDE [TMainIDE.Destroy] END

$ ./lazarus
TMainIDE.ParseCmdLineOptions:
PrimaryConfigPath="/home/graemeg/.config/lazarus/" SecondaryConfigPath="/etc/lazarus"
LAZARUS END - cleaning up ...
[TMainIDE.Destroy] A
[TMainIDE.Destroy] B -> inherited Destroy... TMainIDE [TMainIDE.Destroy] END

============== end ==================

So setting PrimaryConfigPath variable used in the various platform specific include files can now be moved to a common location. And now GetAppConfigDir(False) is used as it's original purpose intended.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Zitat von Graeme Geldenhuys :

It's a little bit more complicated. See below.

It seems what is not as obvious as I thought it is. I will try again: All code that needs the lazarus config directory uses the GetPrimaryConfigPath function. For this code it does not matter where the profile directory is and if the location changed. They already work on all platforms.
Of course some users have written some shell scripts using fixed path. And some users have written external pascal programs. They probably didn't use GetAppConfigDir either. Because it didn't exist at that time and because these programs are used for special lazarus setups. Conclusion:
All platform independent code don't need GetAppConfigDir. All platform dependent code must be changed when the profile location will change.
So no gain in consistency for existing code.

Please give an example.

A 'move' is not simple.
For example when you install a package, the IDE executable lies in the config directory. You can not move this under windows while the IDE runs.
startlazarus can do that.
What if the move fails for other reasons?

What the cause of the headache? The startlazarus program does everything for the developer.

Not everyone uses startlazarus.

It will work in many cases. And about all others the developers must think and find a solution. It's not a simple boolean flag change.

Yes, that's what I meant: all IDE code and add-ons don't care about the location. They already work platform independent - since years.

[...]

Mattias

2009/6/4 Mattias G?rtner :

Of course some users have written some shell scripts using fixed path. And some users have written external pascal programs. They probably didn't use GetAppConfigDir either.

When that is not really our concern is it? Whatever custom applications developer have created is there worry. Surely the core Lazarus developers don't dictate the future of lazarus development based on "what if somebody wrote a custom tool" case. It's there custom tool, which they need to maintain based on there version of Lazarus IDE.

Please give an example.

I thought I already did. Setting the variable PrimaryConfigPath can be move out of platform specific InternalInit() procedure to a common location, seeing that using GetAppConfigDir() would be common to all platforms.

A 'move' is not simple. For example when you install a package, the IDE executable lies in the config directory. You can not move this under windows while the IDE runs. startlazarus can do that.

A 'move' is not required under Windows, because Windows version of Lazarus IDE already use GetAppConfigDir() result. It's only needed for unix based OSes.

I even think ~/.lazarus/ is incorrect for OS X. What path does GetAppConfigDir(False) return under OS X? Doesn't OS X use different directory hierarchy standards compared to Linux, or does OS X applications also use the hidden "dot" directories? Knowing Mac users, I would guess not. Sorry, I don't own OS X so I cannot confirm this - I'm only going with what I have heard or read on the internet about Mac's.

The other point I made before, is that the lazarus executable doesn't contain the "checking profile location" and "move" code, only 'startlazarus' does. This mean moving the lazarus executable living in the profile directory would not be a problem because it occurs before lazarus is run, so no file locking occurred yet.

What if the move fails for other reasons?

I can't think how or why. You *will* have write access, because GetAppConfigDir(False) should return a directory that the current user has write access to. That's the whole point of GetAppConfigDir(False)
- ever changing config files live in that directory.

Not everyone uses startlazarus.

Then we should educate the users, or the icon and menu creation scripts should be improved to do so. The lazarus developers did not include the 'startlazarus' application for their good health - they included it for a reason. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Maybe we should create a GetAppConfigDir branche for Graeme and let him develop all the needed changes.

I for me, see little gain and am happy to support the logic of determining the PrimaryConfig dir in 3 locations, rather than debugging startlazarus and moving primary config paths to paths with spaces and special (non-ascii) characters.

That is the less concise version of "if it isn't broken, then don't fix it".

Vincent

2009/6/4 Vincent Snijders :

Maybe we should create a GetAppConfigDir branche for Graeme and let him develop all the needed changes.

My custom branch is available on GitHub, including the upstream (untouched clean) branch. Note though, that I have not pushed my custom changes to GitHub in a few weeks.

moving primary config paths to paths with spaces and special (non-ascii) characters.

And here I thought Lazarus with utf-8 support can handle something as simple as that without blinking an eye. Was I wrong in that assumption? If I was, then I would seriously start worrying if I was a LCL user.

That is the less concise version of "if it isn't broken, then don't fix it".

Well it just amazes me that some poor developer went through all the trouble in removing the hard-code "c:\lazarus" primary config directory to use GetAppConfigDir(false), yet the other platforms are still stuck with the old behavior. That might be an indicator to the Lazarus core developers, that the right hand doesn't know what the left hand is going, and that the various platforms might get even more fragmented and fragile over time.

But that's just me thinking crazy thoughts again. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

How can I extract the patch with diff that I can apply to create snapshots for people to test and find bugs? After all I think this code is too dangerous to keep it in trunk. A patch must be reverted quickly if it turns out to break too many things.

Lazarus yes, the win32 RTL unfortunately not so easily.

No, the poor programmer replaces ExtractFilePath(ParamStr(0)) with GetAppConfigDir(false) and then found out, that that doesn't work correctly. LazConf is used by Lazarus and LazBuild and StartLazarus, so GetAppConfigDir doesn't really work out of the box. I bet you didn't think about that when you just proposed to make things easier.

Anyway, I rather work on something more useful than reducing the code in lazbaseconf.inc and debugging it.

Vincent

2009/6/4 Vincent Snijders :

To save you the trouble of treating custom snapshots, they can simply use git to pull in the lazarus repository - instead of using SVN. They way they can switch in seconds between my custom branch or the clean upstream branch (which is exactly the same as SubVersion trunk).

Alternatively one can rut the following against the git repository

 $  git format-patch remotes/origin/upstream

This will generate patch files for all custom changes. The patch files will start with a four digit number, which is the order in which they need to be applied.

Anything I change and that I think is remotely useful to others, I normally submit to Mantis anyway. So extracting those patches is probably not that useful to others.

Lazarus yes, the win32 RTL unfortunately not so easily.

But isn't that what the FileUtil.pas unit and all the xxxxUTF8() functions and procedures are for? Wrappers for the non-unicode RTL.

No, the poor programmer replaces ExtractFilePath(ParamStr(0)) with GetAppConfigDir(false) and then found out, that that doesn't work correctly.

Considering that most OS's do not allow write access in the application install directory, there first attempt was flawed anyway. Using the GetAppConfigDir(false) is a step in the write direction for them.

LazConf is used by Lazarus and LazBuild and StartLazarus, so GetAppConfigDir doesn't really work out of the box. I bet you didn't think about that when you just proposed to make things easier.

I did not claim that I know the internals of the IDE, but as a developer I do tend to test things before I make claims. I can always look into the "potential" issues, but so far I have not found any. With the small patch I showed earlier (which uses GetAppConfigDir() under unix environments), 'lazarus' and 'startlazarus' works just like they did before - passing in parameters on not.

BTW:
Did you know that startlazarus already contains exceptions to the rule and a potential bug. For OS X, it uses an ifdef to launch a different executable. That code looks flawed though. It checks for 'LCLCarbon', but what about 'LCLCocoa', which as far as I understand also uses application bundles (a mac thing). Shouldn't that ifdef change to 'darwin' instead which is then generic to OS X and not to a specific GUI toolkit?

Anyway, I rather work on something more useful than reducing the code in lazbaseconf.inc and debugging it.

The word you are looking for is called "refactoring", and it is actually a vital part in software development. ;-) The alternative in a few years (if that long) would be bloated and unmanageable spaghetti code.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

But what patches are for this change?

Vincent

2009/6/4 Graeme Geldenhuys :

Sorry for all the spelling and grammar mistakes. My spell-checker was asleep! :-(

-------- the new and improved version ------------------- To save you the trouble of creating custom snapshots, they can simply use git to pull in the lazarus repository - instead of using SVN. That way they can switch in seconds between my custom branch or the clean upstream branch (which is exactly the same as SubVersion trunk).

Alternatively one can run the following against the git repository ---------------------------------- end ------------------------------------

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

When I am talking about snapshots, they are binary installers not for a released version. I thought Git contains only the sources, not the compiled installers (Mac OS X two cpu, linux two cpus, win32 and win64).

How can using Git avoid that trouble?

Vincent

2009/6/4 Vincent Snijders :

But what patches are for this change?

The only change I have make regarding this thread, is the one I posted before. A simple one line change. If you want me to continue with the changes in 'startlazarus' to prompt and move the profile directory, I can do so and post those changes here as well. Currently no changes have been made to 'startlazarus' yet. Refactoring of LazConf could happen after that.

============== profiledir.patch ===============
diff --git a/ide/include/unix/lazbaseconf.inc b/ide/include/unix/lazbaseconf.inc
index fd2cab1..0cef80b 100644
--- a/ide/include/unix/lazbaseconf.inc
+++ b/ide/include/unix/lazbaseconf.inc
@@ -141,7 +141,7 @@ end;
 ---------------------------------------------------------------------------}
 procedure InternalInit;
 begin
-  PrimaryConfigPath:=ExpandFileNameUTF8('~/.lazarus');
+  PrimaryConfigPath:=SysToUTF8(GetAppConfigDir(False));
  SecondaryConfigPath:='/etc/lazarus';
 end;

================= end ===================

What did you guys to when the profile directory was moved under Windows? I have not found any "automatically move/migrate the profile directory" code anywhere. Did you just leave it up to the developer to move his/her own profile directory?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

No, please don't, there are more important things to do, for example more progress with the LCL interface for fpgui.

We were lucky, the secondary config directory is still the application directory on windows. So, when we started to use the new config directory, the templates for the new files were loaded from the old directory automatically.

Vincent

2009/6/4 Vincent Snijders :

When I am talking about snapshots, they are binary installers not for ?a released version.

I know, that is what I was referring to. Currently there are binary snapshots available (I don't know who creates them). I just thought it a waist of time to create even more binary snapshots which contain the "profile directory moved" patches. Why not simply give them the patch files and say: apply these in order and then recompile lazarus.

Much less effort and much smaller to download.

I thought Git contains only the sources, not the compiled installers (Mac OS X two cpu, linux two cpus, win32 and win64). How can using Git avoid that trouble?

I don't think I understand? The Git repository only contains source code (just like SubVersion).

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

And a much less real life test. So you won't find the trouble cases. That is why you can give the patches to the lazarus developer and maybe 10% of the Lazarus users, but you cannot assume that this is enough testing, certainly because the circumstance of people who compile from source are different.

I understand now, you meant something else and that the trouble cannot be avoided.

Vincent

2009/6/4 Vincent Snijders :

... there are more important things to do, for example more progress with the LCL interface for fpgui.

That task has already been scheduled (and approved) for later this year. As soon as our new product is launched (any week now), I can continue with fpgui and lcl-fpgui.

directory on windows. So, when we started to use the new config directory, the templates for the new files were loaded from the old directory automatically.

Doesn't that leave profile information in two locations? Or was there some cleanup code after the first load as well?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Good, I prefer you start a week earlier than that the Lazarus config directory is moved to ~/config/lazarus.

No, that profile information has been promoted to defaults for a new user. That was something that not really worked on windows, it was a single user (setting) installation.

Vincent

Sorry for my silly posts :) ,
What if i like to share between Windows and Linux config path?

Zaher

2009/6/4 Zaher Dirkey :

Sorry for my silly posts :) , What if i like to share between Windows and Linux config path?

Use --pcp=<path_to_shared_profile>

That should work (I think). I will try next time I load my Windows VM session.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I knew about --pcp=<path_to_shared_profile> and if i always used it, me and some other developers that make Lazarus work as portable, then work on to get the default config dir not be very useful (Yes bad english :) )

I have old application on sourceforge "Light PHP Edit" first time you lauch it, it ask you where you to put the config path (the workspace), i hope Lazarus can do.

----------
I am writing my words as like writing a code, for that i am sorry that i seem as silly.

Zaher