Also, += and such were created to make it easier to convert C code.  If
you change this to +:= you do essentially two things:

1) Break existing code
2) Destroy any of the original purpose and usefulness of the thing in question.

No, of course they're using it because Microsoft said so ;)

Exactly! Thanks for brining this up. If you just want more people to use Pascal, just

1) Make it simple
2) Have lots of nice tools
3) And most of all, have lots of units to do different thing

It's the libraries, functions, objects, etc. that really attract people. Why do you think Java got so popular? It certainly wasn't because it was lightning fast or easy to write. It was because the "standard" libraries that come with Java (despite Sun's insistance to try to talk about the two synonomously) were so extensive. Ever since C and its concept of including libraries, it's been obvious that this is the main attraction for people.

Okay, agreed. But what is there that can be done? I mean, yes -- there are many things that can be done by Pascal guru's, but is there anything to be done by a typical Pascal programmer? (without the knowledge of similar C libraries) I'm a FreePascal programmer that would really like to contribute to the project (for all it has given me) -- but with the lack of compiler/linux related skills I don't see much I could do.

- create good container classes (map, hash, trees etc.)
- write a bcd classes
- extend e.g. the convutils stuff
- look at your own work which could be abstracted and being interesting for fpc
- write docs for the already existing packages

Just a few ideas :)

That could be done... but it needs some common FPC standard -- via interfaces? Like ITreeElement, I HashElement? Anyway, I'm not good at "one cycle less" stuff, so such units would still need a lot of optimizing by someone else... I think I'd pass up on this one.

- write a bcd classes

BCD?

- extend e.g. the convutils stuff

Havn't seen that one yet.

- look at your own work which could be abstracted and being interesting for fpc

Oh my... I've got a huge library of my own things, usualy needing a lot of optimization, but mostly roguelike-games related :-/. I also have a few "libraries" written using Jedi-SDL.

- write docs for the already existing packages

This could work. But I guess the set standard for that documentation would be fpcdoc? Still need to figure out how to use that one... :-/

Binary Coded Decimal. We urgently need a bcdfmt unit as in delphi.

> - extend e.g. the convutils stuff > Havn't seen that one yet.

Lots of work there.

Michael.

Florian Klaempfl wrote

- write docs for the already existing packages

You mean that writing a fpcdoc for the opengl headers for example would be useful for somebody? Myself, I always was uncontent with the fact that there was no opengl section in the rtl docs...

Well, OpenGL is only an API interface unit I'm more thinking about units containing real stuff written in FPC.

We document only units that are written in FPC itself, not import units for system or third-party libraries.

Otherwise I'd have to document the whole Win32 API, X, C library etc.

Michael.

Michael, maybe you can write a short description (wiki?) how to create documentation for units not yet documented.

Maybe this page can help too:
http://lazarus-ccr.sourceforge.net/kb/index.php/Lazarus_Documentation_Editor

Vincent.

I couldn't do it better myself :-)

Michael.

A list of undocumented units that need to be documented would also be nice...

| Kornel Kisielewicz wrote:
|
| > Angelo Bertolli wrote:
| >
| >>> What makes python interesting are the many classes it offers by default | >>> to perform standard tasks, especially in the text treatment department; | >>> regular expression stuff etc.

There's already a completely working regex unit for freepascal which I needed badly ;-). It was already written by someone else (I believe the lazarus/synedit for freepascal group), I just took the existing work and turned it into a contributed unit.

Some of the contributions are just a matter of taking existing work and polishing them up a bit to turn them into a "contributed unit" for freepascal.

Sometimes I create examples or programs for my own needs, but really they also could be posted up on the net for other people to use also. So now all the work I do is geared toward making a zip or gzip file for others.

Some of the contributions will have to be completely original, but really we also have a lot already: mysql, CGI, regex, etc.
I think if freepascal is to be used in greater quantity right now, people should use it for internet applications, servers, clients. I mean if lazarus isn't ready for GUI's as small as Delphi ones, freepascal has to excel at something, right?

Since freepascal started out as being for Dos/linux commandline, it's really already ready for command line programs as it is.. and has been for a while. The thing about servers and web programs, is they basically are command line programs.

But as lazarus matures and people have more time to contribute to it, then freepascal can also excel in GUI's.

Lars

Have a look at Fundamentals (http://fundementals.sourceforge.net/). It has libraries for strings, data structures, unicode, xml, etc. It's was written for Delphi, but I've gotten some way to compile under FreePascal.

Neat, I haven't come across these yet.

If you -have- got some working under FPC you should upload them to "contributed units" section. Because if other people convert the units which have already been done by someone else, we would be doing double work ;-) Plus it gets code into a central repository this way, again so that people don't do double the work.

Have a look at Fundamentals (http://fundementals.sourceforge.net/). It has libraries for strings, data structures, unicode, xml, etc. It's was written for Delphi, but I've gotten some way to compile under FreePascal.

Object pascal is a mature language. Some languages even adopt the concept, such as C# or Java, with different syntaxes and styles. Do not listen to people who said pascal is a toy language, they just don't know what they're talking about.

Then, if we are talking about the object pascal compilers... we must admit that Delphi/Kylix is the most popular pascal compiler. In fact, it becomes some kind of industry standard for pascal based software engineering.

But, now we have another pascal compiler alternative. The open source and free one, it's FreePascal aka FPC. Since it released the v.2.0, it got more popularity. Some people even think that it's gonna replace Delphi domination. But, I think it's not that easy as it said. Delphi has more experiences, more developers and community, more library supports, more products, and many more.

If we want to make FPC as popular as Delphi and more developers interested to use it, then we have 2 ways to do it:

1. Make FPC 100% compatible with latest Delphi release (I think at least D7). Automatically, FPC will get all Delphi resources, including the codes and the developers! There's no need to write new specific libraries for FPC.

2. Make FPC own environment and community. We don't need to keep up with Delphi compatibility, make our own syntaxes and styles, build our own libraries, have our own dignity and destiny. :)

Which way we gonna choose? The first one? Which I think we only need to more concentrate on the compiler development, but with ability to share the code and community with current Delphi code and community. This will make FPC = Delphi, or even FPC >= Delphi. :)

Or the second one? Which I think requires more works, keep up with some "selected" Delphi compatibility, build our own libraries, but with freedom to have our own "special" pascal. This will make FPC > Delphi, or FPC < Delphi, or even FPC Delphi.

So... which one? :)

-Bee-

has Bee.ography at:
http://beeography.modblog.com

Why not both? Delphi is windows-only, so even if FPC became 100% compatible with D7, the libraries already available for Delphi are usually windows specific, and FPC libraries are cross-platform.

----- Original Message -----

Why not both? Delphi is windows-only, so even if FPC became 100% compatible with D7, the libraries already available for Delphi are usually windows specific, and FPC libraries are cross-platform.

I believe you know about Kylix, which is Delphi clone on linux. Delphi IDE is windows only, as Kylix IDE is linux only as well, but not the code. As long as we don't use OS specific API (windows or linux), Delphi code is cross platform (windows and linux). :)

This is also applied on FPC, not all FPC libraries are cross platform, though most of them are. This is also applied on every compiler and language, except Java maybe. It depends on your code, is it targetting a specific platform or for all platforms?

-Bee-

has Bee.ography at:
http://beeography.modblog.com

Indeed :)

If you don't want to use the form designer, Lazarus is a capable code editor with good support for include files for KOL/freepascal projects too. Just use a program or custom program in Lazarus.

Vincent.

Vincent.

Some of the incompatibilities first need to be brought about through experimentation. So start figuring out what -specific- delphi units that you actually need to get working now. If you have a specific unit or source code that needs to be working -today-, then at least you can submit the exact incompatibility issue to the mailing list or wherever.

Otherwise, isn't the incompatibility just low priority, until proven guilty? i.e. it's great that c++ has ways to do neat tricks with all sorts of templates and preprocessing, but does any of your code that you want working today, right now, rely on it? If so, then it's a higher priority.. but if it's something you haven't used in 5-10 years and would be "nice to have some day" then it's just more of a "wish" than a need.
I definitely agree that it would be nice to have all delphi code compile in FPC (then maybe Borland might sadly go out of business and we all might be eating free food soon too).. but there are other alternatives in the mean time, which may only take 5 minutes to get working.
Such as getting KOL working, which is a complete GUI toolkit for windows! I thought it would take me longer
to get this working today.

Well I've just got a KOL application working with FPC 2.0.0, just the date/time functions and KOL assembly version define isn't working properly yet.

Since Vladimir offers us pure Pascal $define or an assembly $define, I turned $define_pas mode on and got a simple KOL app working after about 1 hour of commenting out date/time functions and changing a few things.

I will submit a crumby KOL hello world zip asap. (next goal is to try an MCK app working, and a linux app working, but I"m not sure how far linux is supported with kol)

Listen, 26KB for complete a hello world windows GUI program is not we'll get around to making IDE for KOL/freepascal, or Lazarus could be hacked to use KOL.

People might be able to cheat in the mean time by building their KOL/MCK applications inside delphi, then compiling with freepascal (since KOL does not use DFM files, rather pure on the fly component creation code just hidden inside include files).

Lars

| > | Why not both? Delphi is windows-only, so even if FPC became 100% | > | compatible with D7, the libraries already available for Delphi are | > | usually windows specific, and FPC libraries are cross-platform. | >
| > And we all know they are already doing just that. What is needed is more help, action,
| > and contribution.
| >
| > In fact many libraries out there already are working with FPC. We just haven't done
| > anything about them (i.e. submitted them). It's the man work. We can talk all we want
| > but when it comes time to code...
|
| Indeed :)
|
| _______________________________________________
| fpc-devel maillist -
| http://lists.freepascal.org/mailman/listinfo/fpc-devel

Some of the incompatibilities first need to be brought about through experimentation. So start figuring out what -specific- delphi units that you actually need to get working now. If you have a specific unit or source code that needs to be working -today-, then at least you can submit the exact incompatibility issue to the mailing list or wherever.

I see that it would be nice to have all delphi code compile in FPC (then maybe Borland might sadly go out of business and we all might be eating free food soon too).. but there are other alternatives in the mean time, which may take less resources too.

Such as getting KOL working, which is a complete GUI toolkit for windows! I thought it would take me longer to get this working today.

Well I've just got a KOL application working with FPC 2.0.0.

Since Vladimir offers us pure Pascal $define or an assembly $define, I turned $define pascal on and got a simple KOL app working after about 1 hour of commenting out date/time functions and changing a few things.

I will submit a crumby KOL hello world zip asap. (next goal is to try an MCK app working, and a linux app working, but I"m not sure how far linux is supported with kol)

Listen, 26KB for complete a hello world windows GUI program is not I see a big problem is lazarus not offering small EXE sizes.. since a lot of people do judge an exe by it's size.
(not so much worry in GnuLinux... I don't mind shipping a 1MB linux app...since most Linux apps are usually KDE Python bloatware anyway) So until the LCL is smartlinked better or placed into a library file, I think if KOL was avail in the mean time as a temporary solution.. this would solve a lot of problems temporarily... in a quick and dirty manner (took me only 1 hour to get KOL working today...whereas LCL linked smart may take us a year).

Maybe we'll get around to making IDE for KOL/freepascal, or Lazarus could be hacked to use KOL as an option. People might be able to cheat in the mean time by building their KOL/MCK applications
inside delphi, then compiling with freepascal (since KOL does not use DFM files, rather pure "on the fly" component creation code just hidden inside include files).

Lars

| > | Why not both? Delphi is windows-only, so even if FPC became 100% | > | compatible with D7, the libraries already available for Delphi are | > | usually windows specific, and FPC libraries are cross-platform. | >
| > And we all know they are already doing just that. What is needed is more help, action,
| > and contribution.
| >
| > In fact many libraries out there already are working with FPC. We just haven't done
| > anything about them (i.e. submitted them). It's the man work. We can talk all we want
| > but when it comes time to code...
|
| Indeed :)
|
| _______________________________________________
| fpc-devel maillist -
| http://lists.freepascal.org/mailman/listinfo/fpc-devel

| If you don't want to use the form designer, Lazarus is a capable code | editor with good support for include files for KOL/freepascal projects | too. Just use a program or custom program in Lazarus. |
| Vincent.

I use Lazarus all the time.. but form editor would be nice in the future.

Creating components on the fly with KOL is not so bad, but it also takes time, and it's not as good for beginners who want to try freepascal quickly with no hassles.

I'll see if MCK works with FPC 2.0.0.. if so, people could build applications in Delphi but compile in freepascal/lazarus. That would just be evil and nasty.

While converting the KOL libraries and getting a hello world application running, I realized I did not have to do this! Someone has already done it already: http://members.chello.nl/t.koning8/fpc_in_kol_proper.htm

So we at least have two people working on KOL for freepascal so far!

Lars

Maybe we should:
1. Put an entry in the FPC contributed units.
2. Provide a link on the FPC links page ?
3. Add an entry in lazarus-ccr ?

Michael.

He won't. I already talk to him from time to time.

I also still have a list of problems from Thaddy that he had to do for 2.0:

1)

procedure x(p:array of pchar);
begin
end;
x(['a','b']);

IOW some autoconversion problem

2)
constructs like

MOV EAX, [ECX].TRect.Bottom

Fail with: Trying to push memory location

3)

Works:

procedure TObj.Free;
begin
  if @Self  nil then
    DoDestroy;
end;

doesn't work (while it apparantly should):

procedure TObj.Free;
begin
  if Self  nil then
    DoDestroy;
end;

4)

procedure x (const str: string);
begin
  filewrite (filedescriptor,pchar(str+#13#10)^,length(str)+2);
end;

Marco van de Voort wrote

procedure x (const str: string); begin filewrite (filedescriptor,pchar(str+#13#10)^,length(str)+2); end;

I do not think this should work. You can't pass the address of a temp like this.

Jonas

Fixed for delphi mode only

| Maybe we should:
| 1. Put an entry in the FPC contributed units.
| 2. Provide a link on the FPC links page ?
| 3. Add an entry in lazarus-ccr ?
|
| Michael.

We could put a link in the FPC wiki too.

Yes I'm sure Thaddy will not mind at all..

I'm making some freepascal KOL demo programs that I will also add to contributed units section as I get them done. Thaddy already has some KOL exe demo's in his package too.

I've put a link up on PasWiki and will be journaling some of what I'm doing. http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=KOL-for-Freepascal

I'm ready to throw my delphi compiler in the garbage almost. Lots of my apps I have been working on for years are KOL based ;-)

And now that they compile with FPC, and probably would have been compiling ever since FPC 1.9.0 era....(I just didn't try)

Lars

| I'll see if MCK works with FPC 2.0.0.. if so, people could build applications in | Delphi but compile in freepascal/lazarus. That would just be evil and nasty.

Well I tried it. MCK works first try on one of my projects I built with Delphi over a year ago. Therefore, I'm happy to announce that you can <BIG FONT> create applications in the Delphi IDE visually, and then compile them with FPC!</BIG FONT> using KOL/MCK.

I'll upload a flash video of my PC and show you what I mean - when I get a chance (.swf format).

So basically using MCK/KOL one can
- visually create applications with Delphi
- open lazarus or any other IDE, compile the application that you built with Delphi
- or compile the application with some other IDE, or command line FPC
- someone may build a plug in for the Delphi IDE to compile the application with FPC directly from Delphi IDE
- have an exe application who is only 50KB in size or so!!

All I had to do was open an old MCK application I built a few months ago and add the following lines to the code in each KOL/MCK source file:

{$MODE Delphi}
{$DEFINE KOL_MCK

What does this mean for us as FPC developers?
For Windows development, MCK/KOL applications can be created visually by RAD. Exe size is 40KB for a simple application. Lazarus is 1MB currently. People can use KOL/MCK for visual RAD on small-medium projects until lazarus is more mature with regards to exe size.

This is very big news.. because all my KOL/MCK applications right now will compile inside Lazarus with no modifications..and they were all built in Delphi months/years ago.

I will have to check to see if all the MCK components will compile though.. hopefully things like KOL synedit and KOL synapse may even compile.

It is even slow. Splitting it in 2 lines is faster since it removes the implicit string concattenation

filewrite (filedescriptor,pchar(str)^,length(str));
filewrite (filedescriptor,#13#10,2);

filewrite is not buffered, so I think the concatenation is in general faster than two system calls.

Jonas

Yes. I would recommend doing it like this; It'll work in Delphi and in FPC, and is faster in both. For small writes, the difference is not really harmful, but for a stress-load system (a server log for example, or a data generator) it's really noticeable. I did some tests both in Delphi and FPC with this...

Michael.

Yes I had to convert some constants to var's (and initialize them) in one procedure.. and I noticed Thaddy did this too. I assume delphi is a bit less strict in that it let's you get away with the below... but I'm not sure if it's good to be less strict in this case.. (poor style?) What do you think..

|
| On 7 jun 2005, at 14:15, Marco van de Voort wrote: |
| > procedure x (const str: string);
| > begin
| > filewrite (filedescriptor,pchar(str+#13#10)^,length(str)+2); | > end;
|
| I do not think this should work. You can't pass the address of a temp | like this.
|
|
| Jonas
|
|
| _______________________________________________
| fpc-devel maillist -
| http://lists.freepascal.org/mailman/listinfo/fpc-devel

| >> procedure x (const str: string);
| >> begin
| >> filewrite (filedescriptor,pchar(str+#13#10)^,length(str)+2); | >> end;
| >
| > I do not think this should work. You can't pass the address of a temp | > like this.
|
| Fixed for delphi mode only

{$MODE slacker}
Good idea, only for slacker mode.. real coders using real object pascal will not abuse this delphi slack-off style code ;-)

[...]

Hi
I did not find any usable info about the bcdfmt.

What is the required interface for the TBCD objects? Are they normal BCD (0-9) or Telephony BCD (0-9,a-c,*,#,filler) ? (Google on TBCD took me to ASN.1)

A page for info about bcdfmt was started on wiki
http://www.freepascal.org/wiki/index.php/BcdUnit

Sorry I don't have a Delphi and I run on OS X.

Jan

Searching for "Delphi precision tbcd" on google yields:

http://64.233.183.104/search?q=cache:97hnmm3AhNEJ:www.delphikingdom.com/asp/useranswers.asp%3Fid%3D47518+tbcd+delphi+precision&hl=en

which yields the type.

type
  TBcd  = packed record
    Precision: Byte;
    SignSpecialPlaces: Byte;
    Fraction: packed array [0..31] of Byte;
  end;

What is the required interface for the TBCD objects? Are they normal BCD (0-9) or Telephony BCD (0-9,a-c,*,#,filler) ? (Google on TBCD took me to ASN.1)

Normal I guess.

A page for info about bcdfmt was started on wiki http://www.freepascal.org/wiki/index.php/BcdUnit Sorry I don't have a Delphi and I run on OS X.

Do not look at delphi copyrighted source, but get info from public sources like helpfiles for download on Borlands FTP etc.

This should be enough to reconstruct a rough interface, details will then later be found by testing real delphi code.

The FreeCLX contains also an implementation though it's GPL while FPC libraries are modified LGPL.

This is only interesting for Kylix licensees, and products requiring this.

I'd like to keep FPC core libs free of GPL.

Well..
I had spent a lot of time thinking about how to contribute to FPC. I thought about contributing with a string phonetizer algoritm i made, but its works only for the portuguese language, so i thought i wouldnt be much usefull for most of the FPC community.
Some days ago i contributed to FPC with a stringcomparator unit based on the Jaro, Winkler McLachlan and Lynch algorithms, known as the best ones to compare strings, giving them a grade between 0 and 1 (0 being no similarity between them and 1 being exactly the same). So, here goes my questions... I had no feedback for the string comparison unit so far... Was that a good contribution? Would it be a good idea to contribute with the phonetic algorithm even knowing that it works only for the portuguese language?

Cheers!
André Cipriani Bandarra

Did it go through the mailing list already? I guess because it contains an attachement it is held for approval.

Any contribution is good :-)

Currently, there is a soundex() algorithm in strutils; the soundex algorithm is geared towards the english language. Having one for the portugese language is definitely good. It would even be better if we could somehow unite the algorithms witha suitable parametrization; I'm unfortunately not enough of an expert to be able to carry this out...

Michael.

Yes.

I'm not saying that you could distribute the sources, but you could compile it with FPC? Or is that not legal?

It is legal, as long as you don't distribute the sources.

For example.. one could try compiling the Delphi VCL as a Delphi product owner, but not distribute the VCL sources themselves, just what was compiled?

This is possible, what is more, it is being done.

Michael.

| Do not look at delphi copyrighted source, but get info from public sources | like helpfiles for download on Borlands FTP etc. |
| This should be enough to reconstruct a rough interface, details will then | later be found by testing real delphi code.
|

I was just wondering, are there any source code files that Borland company offers which doesn't have copyright and is public?

|
| | Do not look at delphi copyrighted source, but get info from public sources | | like helpfiles for download on Borlands FTP etc. | |
| | This should be enough to reconstruct a rough interface, details will then | | later be found by testing real delphi code.
| |
|
| I was just wondering, are there any source code files that Borland company offers | which doesn't have copyright and is public?
|

Another question: if someone already owns Delphi, they could compile any source code from their Delphi CD with freepascal? Is this legal? I'm not saying that you could distribute the sources, but you could compile it with FPC? Or is that not legal?
For example.. one could try compiling the Delphi VCL as a Delphi product owner, but not distribute the VCL sources themselves, just what was compiled?

I have several old books, with source code, covering TP6 in my library. The most interesting one to me covers generic programming; eg. arrays, lists, collections etc. These units are mainly implemented using objects and manipulating data pointers. Will any of these be of interest to the list.

I will have to rework them to compile cleanly using FPC.

Regards

John

Every source code is subject to copyright. A special notice in such a file should indicate the copyright holder, and how freely the code can be used.

Another question: if someone already owns Delphi, they could compile any source code from their Delphi CD with freepascal? Is this legal?

Compilation for private use is legal. Borland disallows to distribute their library source code, also in compiled (object) form unless as part of applications. The exact license terms are part of every Delphi distribution.

Copyright is based on licenses, i.e. the author must allow everything that one can do with his work (sorce code...). If in doubt, you are not allowed anything. That's why there exist a lot of license models (GPL...) for free software, which not only grant the (more or less restricted) use of the source code, but also disallow any further restriction of the granted rights.

Contributions to FPC, like to every other public project or library, should be free from any special restrictions, so that a redistribution can not conflict with the rights of the authors of the respective code etc.

DoDi

|
| > Another question: if someone already owns Delphi, they could compile any source code
| > from their Delphi CD with freepascal? Is this legal? |
| Compilation for private use is legal. Borland disallows to distribute | their library source code, also in compiled (object) form unless as part | of applications. The exact license terms are part of every Delphi | distribution.

But compiled with delphi compiler, or freepascal? I wonder if they have a specific restriction where you can only compile the code on their compilers... Not that I know of but.. I thought maybe you guys had come across something like that

| Contributions to FPC, like to every other public project or library, | should be free from any special restrictions, so that a redistribution | can not conflict with the rights of the authors of the respective code | etc.

I realize that the FPC should contain code free from restriction.. And we have to be careful with some people because some of us have copy/pasted code from the VCL and not marked it as so.

I was more interested in discussing those who already have a copy of delphi and who are "thinking" about using freepascal.. then if say they could reuse all their delphi code in emergency, they could at least have that "safety" feeling in the back of their mind, when thinking about starting to use FPC.

So the specific question I have is whether borland might have some restriction in the area that their source codes can only be compiled on a borland compiler... if sold commercially, or if used in freeware even.

So far it seems this is not the case.. but I still don't know, there might be some little tiny wording we have missed somewhere.

L505 wrote:
...

But compiled with delphi compiler, or freepascal? I wonder if they have a specific restriction where you can only compile the code on their compilers... Not that I know of but.. I thought maybe you guys had come across something like that

The System.pas unit is special. In older Delphi version it cannot be compiled at all, in newer versions I never tested it. The problem here are syntax errors, the implied type declarations for the standard types, and possibly the multiple use of System.pas, which is implicitly used by every unit. No intentional or expressed limitation to use an Delphi compiler, only sloppyness ;-)

DoDi

Hi

are you interested in FMTBcd unit for FPC ?

I would appreciate information needed for clean implementation. Page used for collecting information is:
http://www.freepascal.org/wiki/index.php/BcdUnit

At this moment most valuable are test cases for different functions. Also more explanation about different functions would be nice.

Please don't contribute any implementation code.
This is to insure that no code was copied from a copyrighted source.

Thanks
Jan

Yes, i've already seen it in the list. Anyway, the link to the units is here

http://www.bandarra.org/pascal/stringcomparison/

Hello again!
If i am not mistaken, the soundex() algorithm has a main difference from the one in portuguese - while the soundex() generates a number for the string, the phonetic one generates a phonetized string. Anyway... I will prepare the unit to be posted as a contribution, with comments with PasDoc and all!!

Eg:" Michael Van Canneyt" would be transformed to "MIXAEL KANEITI"