- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

On 04/24/2012 12:57 PM, StÃ©phane Ducasse wrote: > Ok I will have a look. Because it would solve our problem. I just added first stab at supporting literal arrays, the following works: (TiradeParser parse: 'keyword: #(1 3.4 ''asd'' #jupp 2).') last value first print it => #(1 3.4 'asd' #jupp 2) The "last value first" is just because the result from TiradeParser contains Associations between the keyword and an array of arguments. It could in fact return instances of Message, that might be nice :) ...but nesting needs a bit more thought since one can ommit the # when nesting literal arrays inside literal arrays. regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by H. Hirzel

In this sense I agree with you, Igor, and I actually had your position in the discussion on the 11th and 12 April on the metacello list (I made a small example as you, and I added XML as a third option) As I am not going to implement neither JSON, nor XML nor a Smalltalk solution I have to say that anything is fine for me. However the discussion is about Cypress and the project is moving on. See https://github.com/CampSmalltalk/Cypress/wiki --Hannes =========================================================== For ease of Reference here the full email of Dale from April 12th, 2012 See my emphasis with +++++++++++++++++ =========================================================== Guys, Guys, Guys... this is my last post on this topic ... I have not read any of the overnight posts ... I am not interested in talking about what format the property files should use. I made the decision (weeks ago) and no amount of arguing on this list will change the current implementation and the only thing that will change a future implementation is CODE. I have stated that whatever format you want to invent it should include a "literal dictionary format", because the existing code is expecting to work with Dictionaries. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I have also stated that any code produced be portable to all of the dialects participating in the project. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you meet these two requirements, it is likely that the project maintainers will just fold it in ... if it takes too much work to use your format, then you'll have to do it yourself. 1) FileTree/Cypress is using JSON 2) the current implementation is functioning just fine 3) FileTree/Cypress is designed to be flexible in terms of format, at some future date, you will be free to fork the projects and introduce your own favorite format and you are free to make the changes that are necessary in the source code for all of the dialects or use your own custom package structure on just your own projects. We are all programmers. We all understand that the data can be represented in an infinite number of formats. We all understand that it is just a small matter of writing code to implement readers and writers for this infinite number of formats. We all understand that the data is much more important than the disk format .... We should all understand that there is no right answer to the format question ... every conceivable format will work (with the appropriate amount of supporting software) ... We all have an opinion and I understand that each of you has your own opinion about what the format should be and I understand that the folks who are continuing to argue over this are not happy with my decision... That's just too bad. If you are interested in being able to use git and github and are excited at the prospect of being able to not only share code across dialects, but to collaborate on cross dialect projects, then stop worrying about the format of the file and put your energy into writing code in support of this goal (see point 3 and read it 5 times in a row). If you are arguing on these points, you are showing that you have passion ... I don't fault you for having strong opinions ... I just ask you to channel your energy into writing code on this issue or focussing on some of the harder problems that do exist... I do not intend to read any responses to this mail as far as I am concerned I am moving on to some of the much more important issues that need attention ... Dale On 4/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > you know, it is like C and their makefiles.. > in C world they cannot express the project metadata using C syntax.. > that's why they using this weird > makefiles (and many other .project formats) to glue things together.. > But hey, we can express things in smalltalk. So, why adding extra tool > to the toolchain? > > My point is not about whether it is better to use JSON over another > format. My point is that we can use smalltalk all the way down. > Because it means less dependencies and simpler tool chain (you need to > have only smalltalk parser to handle everything stored in your files, > and no extra stuff). > Because tomorrow, other guy could say: hey i love xml and i want to > store this in xml.. and provide same arguments: > it is used worldwide, and can be used for interoperability with other > languages... and so on, so on. > And he will be totally right, except from the fact that we don't need it. > > My argument is purely pragmatic: it is better having just one parser > to parse all data than two or more. > More formats, more syntax(es) means more things to worry about, and > maintain. > > > On 24 April 2012 13:02, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 24 April 2012 12:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >>>> Hi Igor, >>>> >>>> It is pretty clear that JSON is slowly replacing even XML elsewhere and >>>> if I for instance have to chose between XML and JSON, I'd certainly >>>> choose later. Our chunk format is, well, ours only. VW is using XML, >>>> others are using anything else. >>> >>> In a really really bad way. Because the tags are used in a non sense way. >>> You still have to parse method to get the selector :) So VW is far from >>> an example. And we are not talking about the method format, just method >>> metadata. >>> >>>> Something as neutral and as simple as >>>> JSON-based format can therefore become a bridge even between us. >>>> >>>> JSON is now becoming defacto standard for any interoperability scenario >>>> in cloud world, so IMO Dale did a right decision to choose it. We will >>>> be much closer to other words with Smalltalk that way >>> >>> Not at all. Do you really think that somebody will be interested by >>> Smalltalk just because >>> metadata of methods are stored in JSON :) >>> Come on. >> >> yeah. lets store our metadata in SQL syntax.. so we are closer to SQL >> databases.. >> LOL :) >> >>> >>>> and even more by >>>> using GitHub for code repository. >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. > >

April 24, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Juan Vuletich (mail lists)

Hi Dale, Quoting Dale Henrichs <dhenrich(a)vmware.com>: > Bernhard and Juan, > > I was curious enough about Cypress and Cuis to start a Cypress port > to Cuis[1]. Loaded code and started working through tests: > > 19 run, 6 passed, 3 failed, 10 errors > > We'll see if I get any farther tonight:) > > Dale > > [1] https://github.com/CampSmalltalk/cuis-cypress This is great, thank you! I took a look at your format when thinking on how to do Cuis package format, and I think that for a Cuis specific package format, a single file per package will be easier to diff / merge by Git. But I really welcome and thank you for this format for cross-dialect packages! Cheers, Juan Vuletich > ----- Original Message ----- > | From: "Dale Henrichs" <dhenrich(a)vmware.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Monday, April 23, 2012 1:57:57 PM > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 > Smalltalk > | > | Bernhard, > | > | With regards to sharing code between dialects, I'd like to recommend > | that you look into porting Cypress to Cuis (I'm willing to help as > | much as I can). > | > | The Cypress project is aimed from the get go to enable sharing of > | packages between Smalltalk dialects with a recognition that possibly > | the most important aspect is a shared VCS (git/github). > | > | If you look at the current code base in Cypress, you will see a > | reference implementation written against Pharo. The reference > | implementation is a work in progress and the initial implementation > | was done for Amber[2]. > | > | Cypress has Monticello-like packages, but other than taking a few > | ideas from Monticello (definitions, packages and snapshots ... more > | than a few:)) the code base is independent of Monticello. The fact > | that Cypress runs on top of Amber (sans file system access) speaks > | volumes for it's portability. > | > | To paraphrase a point from my STIC talk[3] on this subject: > | > | Cypress is not intended to be the primary version control > | system for any dialect, however, if you want to share code > | between dialects you should allow your developers to import > | and export code using the Cypress package format. > | > | If you are interested, there are bits and pieces of code in a few > | other projects that I would want to pull into the Cypress project > | and couple other things that I'd like to move out of the Cypress > | project before tackling another port ... > | > | We can correspond via private email if you'd like to take me up on > | the offer of help:) > | > | Dale > | > | [1] https://github.com/CampSmalltalk/Cypress > | [2] https://github.com/CampSmalltalk/amber-cypress > | [3] > | http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk > | > | ----- Original Message ----- > | | From: "Bernhard Pieber" <bernhard(a)pieber.com> > | | To: Pharo-project(a)lists.gforge.inria.fr > | | Sent: Monday, April 23, 2012 9:53:35 AM > | | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 > | | Smalltalk > | | > | | Hi GÃ¶ran, > | | > | | Thanks for your question! I have posted the announcement of the > | | Styled Text Editor to the Pharo list as well because I still have > | | not given up on the idea to port it to Squeak and Pharo. It is not > | | straightforward but I consider it possible. > | | > | | Currently the Styled Text Editor is an external package which is > | | loaded on top of Cuis 4.0. The API it uses is quite specific to > | | Cuis > | | so to port it alone is probably too much effort. What I think can > | | be > | | done is the following: > | | Split Cuis into three parts, > | | a) the parts which are not needed for Styled Text Editor, like the > | | Cuis tools > | | b) the parts of Cuis Morphic the Styled Text Editor depends on ? > | | this > | | is in my opinion the most valuable part of Cuis because Juan spent > | | years cleaning it > | | c) the Smalltalk kernel below > | | > | | The idea is to port only part b) and the Styled Text Editor. And it > | | has to be done automatically by a tool which creates packages for > | | Squeak and Pharo, always from the latest code base. In addition you > | | will probably need small Cuis portability packages done manually, > | | one for Squeak and one for Pharo. > | | > | | Being able to always load the latest code base of Styled Text > | | Editor > | | and Cuis Morphic as an external package in Pharo is a prerequisite > | | to look into possibilities of sharing more of the code. > | | > | | I plan to write a more detailed proposal and then to approach ESUG > | | and ask for support for the funding. Any ideas for other sources of > | | funding are highly welcome and could speed things up considerably, > | | of course! ;-) > | | > | | I for one have not given up on the idea that it might be possible > | | to > | | develop substantial components as you called it ? thank you for > | | that > | | as well ? in a more Squeak-dialect-independent way. ;-) > | | > | | Finally, I would like to take the opportunity and kindly ask > | | everyone > | | who has not done so yet: Please check out Cuis 4.0 and the Styled > | | Text Editor and give us feedback, even if it does not (yet) run on > | | your favourite Squeak dialect! Thank you! > | | > | | Peace, > | | Bernhard > | | > | | P.S. Thanks to GÃ¶ran and Janko for trying to establish different > | | threads for the rather off-topic discussions that my announcement > | | posting has caused. > | | > | | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: > | | > Hi! > | | > > | | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: > | | >>> Just cloning it off into Pharo and forking seems... less > | | >>> optimal. > | | >>> Any ideas or thoughts? > | | >> > | | >> I do not get what you mean. I just want to work on our roadmap > | | >> and > | | >> make it getting real. > | | >> It is hard enough to get some momentum and to deliver for real. > | | >> So can you help us to get focused? > | | >> People can do what they want. I wrote a vision document. We have > | | >> a > | | >> roadmap > | | >> and we will do it. > | | > > | | > Ok, let me clarify. I was just wondering how the Pharo community > | | > wants to handle a case where a substantial component (in this > | | > case, this new editor) is not *primarily* developed in Pharo (in > | | > this case Cuis). > | | > > | | > The simple route is to just copy and fork. But IMHO this doesn't > | | > leverage the team already around this editor, right? We (Pharo) > | | > can't just go around and forking everything and maintaining > | | > everything for ourselves, right? > | | > > | | > I just got interested in that problem - now, later replies > | | > indicated that it would still need a substantial rewrite for > | | > Pharo, so perhaps the situation I am describing is not really > | | > applicable in this case. > | | > > | | > regards, GÃ¶ran > | | > > | | > | | > | | > | > >

April 24, 2012

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

On 04/24/2012 01:06 PM, H. Hirzel wrote: > On 4/24/12, Igor Stasenko<siguctua(a)gmail.com> wrote: >> can you name just one which can be useful in this context??? >> what tools, except written in smalltalk and used by smalltalkers you >> are expecting to use >> with smalltalk source code stored in source code repositories? > > JavaScript :-) in connection with Amber. And couchDB. I do notice that Igor mentions a specific use case here, but let me ignore that and just reflect on JSON in general: And Riak. And quite a few other NoSQL dbs use JSON. And lots of RESTful RPC backends tend to use JSON, we do in our C# backend here at my customer. And almost all web APIs on the net use JSON. And JSON pops up everywhere in fact. So personally, while I did actually implement Tirade, JSON is still a very nice format due to its ubiquity. The main reason I made Tirade was because JSON didn't handle linefeeds in strings so I couldn't store source code in JSON in a reasonably readable way. At least not per true JSON spec. Also, Tirade supports more atomic Smalltalk datatypes. And since it encodes keyword messages it simply offers more structure than JSON does. And it is streamable. And perhaps one or two more things. But in summary - JSON is generally a very good choice and IMHO Pharo should be *great* at handling JSON. It's not going away :) regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by Igor Stasenko

you know, it is like C and their makefiles.. in C world they cannot express the project metadata using C syntax.. that's why they using this weird makefiles (and many other .project formats) to glue things together.. But hey, we can express things in smalltalk. So, why adding extra tool to the toolchain? My point is not about whether it is better to use JSON over another format. My point is that we can use smalltalk all the way down. Because it means less dependencies and simpler tool chain (you need to have only smalltalk parser to handle everything stored in your files, and no extra stuff). Because tomorrow, other guy could say: hey i love xml and i want to store this in xml.. and provide same arguments: it is used worldwide, and can be used for interoperability with other languages... and so on, so on. And he will be totally right, except from the fact that we don't need it. My argument is purely pragmatic: it is better having just one parser to parse all data than two or more. More formats, more syntax(es) means more things to worry about, and maintain. On 24 April 2012 13:02, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 April 2012 12:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi Igor, >>> >>> It is pretty clear that JSON is slowly replacing even XML elsewhere and >>> if I for instance have to chose between XML and JSON, I'd certainly >>> choose later. Our chunk format is, well, ours only. VW is using XML, >>> others are using anything else. >> >> In a really really bad way. Because the tags are used in a non sense way. >> You still have to parse method to get the selector :) So VW is far from >> an example. And we are not talking about the method format, just method metadata. >> >>> Something as neutral and as simple as >>> JSON-based format can therefore become a bridge even between us. >>> >>> JSON is now becoming defacto standard for any interoperability scenario >>> in cloud world, so IMO Dale did a right decision to choose it. We will >>> be much closer to other words with Smalltalk that way >> >> Not at all. Do you really think that somebody will be interested by Smalltalk just because >> metadata of methods are stored in JSON :) >> Come on. > > yeah. lets store our metadata in SQL syntax.. so we are closer to SQL > databases.. > LOL :) > >> >>> and even more by >>> using GitHub for code repository. >> >> >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

April 24, 2012

[Pharo-project] SimpleLiteralArray Spec

by Sven Van Caekenberghe

OK, just to get started, let try to write a spec for SimpleLiteralArray, this is based on JSON (and my own STON, not ready for public consumption). It will soon become clear that this is slightly harder than expected, IMO a writer is needed as well. S y n t a x value primitive-value list nil primitive-value number true false symbol string classname list #() #( elements ) elements value value , elements string '' ' chars ' chars char char chars char any-printable-ASCII-character- except-"-or-\ \" \\ \/ \b \f \n \r \t \u four-hex-digits symbol # chars-limited # ' chars ' chars-limited char-limited char-limited chars-limited char-limited a-z A-Z 0-9 - _ . / classname uppercase-alpha-char alphanumeric-char number int int frac int exp int frac exp int digit digit1-9 digits - digit - digit1-9 digits frac . digits exp e digits digits digit digit digits e e e+ e- E E+ E- Questions remain: - is the escaping OK ? - what about symbols without a leading # ? - what should be allowed in unquoted symbols ? - what should be allowed for classnames ? - what about namespaces ? - do we allow infinite precision integers ? - maybe the toplevel should always be an array ? Now: shoot! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 24, 2012

Re: [Pharo-project] [ANN] PharoLauncher for Mac users

by Peter Hugosson-Miller

Bookmarking this for when I get Lion on my personal MBP. It's still stuck on Snow Leopard for now :-( But this looks _really_ interesting, great job! /Peter On Tue, Apr 24, 2012 at 12:29 PM, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > Simple. > > I want to use Autolayout feature, which requires Lion(Mac OS X 10.7). :-) > It is such a magic. Morphic may be great with it. > > HwaJong Oh > > -- > View this message in context: > http://forum.world.st/ANN-PharoLauncher-for-Mac-users-tp4580756p4582996.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 24, 2012

Re: [Pharo-project] Tirade! (was: Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk])

by H. Hirzel

On 4/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 April 2012 12:50, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> On 4/24/12, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >>> >>> On 24 Apr 2012, at 11:10, StÃ©phane Ducasse wrote: >>> >>>>>> And yet again I point to Tirade :) >>>>>> >>>>>> http://goran.krampe.se/blog/Squeak/Tirade.rdoc >>>>>> http://goran.krampe.se/blog/Squeak/Tirade2.rdoc >>>>>> http://goran.krampe.se/blog/Squeak/Tirade3.rdoc >>>>>> >>>>>> Especially Tirade2 above shows a bit about size (4 classes, 500 loc) >>>>>> speed and portability. Tirade is basically a parser for Smalltalk >>>>>> messages that only are allowed to use literals as arguments (although >>>>>> arbitrarily nested literals). >>>>>> >>>>>> Which is exactly what Stef describes + a bit more. :) >>>>> >>>>> Yeah, I remember reading that a long time ago. It is indeed a cool >>>>> idea, >>>>> GÃ¶ran. Reminds me of the Erlang related UBF >>>>> (http://www.sics.se/~joe/ubf/site/home.html) >>>>> >>>>> I think the JSON choise is not bad: it is simple and universally >>>>> accepted. >>>> >>>> But you can express **EXACTLY** the same with >>>> #( >>>> >>>> >>>> ) >>>> >>>> So what is the point? >>>> >>>> Stef >>> >>> Yes, you are right, they are technically mostly equivalent. (JSON has >>> simpler primitive types, clear escapes, lists/arrays and >>> maps/dictionaries). >>> >>> But the point is, there are so many formats out there, and everybody >>> likes >>> to make there own. >>> >>> If you pick JSON, the discussion ends. It is an RFC standard. >> > > If you pick smalltalk , it is ansi standard.. so.. what the point? > >> +1 There is already a documentation of the format. No additional work needed. >> >>> If you pick something that looks suspiciously like some (for most people) >>> weird programming language you will get discussions, always. >>> >>> Dale said so: it is a pragmatic choice. >> >> +1 >> >>> Now, given the fact that the domain here is Smalltalk anyway, there is >>> something to say for using a Smalltalk based representation. >>> >>> But then you need to write a clear spec and a non-compiler based parser. >>> >>> With the JSON meta data, you could envision other non-Smalltalk tools >>> using >>> it more easily. >> >> +1 > > this is killer argument ;) > > can you name just one which can be useful in this context??? > what tools, except written in smalltalk and used by smalltalkers you > are expecting to use > with smalltalk source code stored in source code repositories? JavaScript :-) in connection with Amber. And couchDB. > > Sorry, the only valid and understandable argument here to me, is that > it is purely pragmatic choice :) And as Dale writes. It is already implemented in different dialects of Smalltalk. Thank you for asking Hannes > -- > Best regards, > Igor Stasenko. > >

April 24, 2012

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by Igor Stasenko

On 24 April 2012 12:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi Igor, >> >> It is pretty clear that JSON is slowly replacing even XML elsewhere and >> if I for instance have to chose between XML and JSON, I'd certainly >> choose later. Our chunk format is, well, ours only. VW is using XML, >> others are using anything else. > > In a really really bad way. Because the tags are used in a non sense way. > You still have to parse method to get the selector :) So VW is far from > an example. And we are not talking about the method format, just method metadata. > >> Something as neutral and as simple as >> JSON-based format can therefore become a bridge even between us. >> >> JSON is now becoming defacto standard for any interoperability scenario >> in cloud world, so IMO Dale did a right decision to choose it. We will >> be much closer to other words with Smalltalk that way > > Not at all. Do you really think that somebody will be interested by Smalltalk just because > metadata of methods are stored in JSON :) > Come on. yeah. lets store our metadata in SQL syntax.. so we are closer to SQL databases.. LOL :) > >> and even more by >> using GitHub for code repository. > > > -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] Tirade! (was: Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk])

by Igor Stasenko

On 24 April 2012 12:50, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > On 4/24/12, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 24 Apr 2012, at 11:10, StÃ©phane Ducasse wrote: >> >>>>> And yet again I point to Tirade :) >>>>> >>>>> http://goran.krampe.se/blog/Squeak/Tirade.rdoc >>>>> http://goran.krampe.se/blog/Squeak/Tirade2.rdoc >>>>> http://goran.krampe.se/blog/Squeak/Tirade3.rdoc >>>>> >>>>> Especially Tirade2 above shows a bit about size (4 classes, 500 loc) >>>>> speed and portability. Tirade is basically a parser for Smalltalk >>>>> messages that only are allowed to use literals as arguments (although >>>>> arbitrarily nested literals). >>>>> >>>>> Which is exactly what Stef describes + a bit more. :) >>>> >>>> Yeah, I remember reading that a long time ago. It is indeed a cool idea, >>>> GÃ¶ran. Reminds me of the Erlang related UBF >>>> (http://www.sics.se/~joe/ubf/site/home.html) >>>> >>>> I think the JSON choise is not bad: it is simple and universally >>>> accepted. >>> >>> But you can express **EXACTLY** the same with >>> Â Â Â #( >>> >>> >>> Â Â Â Â Â Â Â ) >>> >>> So what is the point? >>> >>> Stef >> >> Yes, you are right, they are technically mostly equivalent. (JSON has >> simpler primitive types, clear escapes, lists/arrays and maps/dictionaries). >> >> But the point is, there are so many formats out there, and everybody likes >> to make there own. >> >> If you pick JSON, the discussion ends. It is an RFC standard. > If you pick smalltalk , it is ansi standard.. so.. what the point? > +1 > >> If you pick something that looks suspiciously like some (for most people) >> weird programming language you will get discussions, always. >> >> Dale said so: it is a pragmatic choice. > > +1 > >> Now, given the fact that the domain here is Smalltalk anyway, there is >> something to say for using a Smalltalk based representation. >> >> But then you need to write a clear spec and a non-compiler based parser. >> >> With the JSON meta data, you could envision other non-Smalltalk tools using >> it more easily. > > +1 this is killer argument ;) can you name just one which can be useful in this context??? what tools, except written in smalltalk and used by smalltalkers you are expecting to use with smalltalk source code stored in source code repositories? Sorry, the only valid and understandable argument here to me, is that it is purely pragmatic choice :) -- Best regards, Igor Stasenko.

April 24, 2012