- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [vwnc] image overload
by Eliot Miranda March 12, 2010

March 12, 2010

On Fri, Mar 12, 2010 at 10:51 AM, Bruce Boyer <bruce.boyer(a)alumni.uci.edu>wrote: > This is rather a sensitive area with me at the moment, as I'm working on > indexing docs. I've had to resort to using "image" and "graphical image" to > try to distinguish these two, but "image" remains unclear to anyone who > doesn't already know. > > I could guess that the term "snapshot" came first, as a methaphorical > attempt to describe what saving that thing is, and "image" is what snapshots > give (or pictures or something even worse for that thing). But, it's only a > guess. > Right. That's why I don't like either snapshot or image. What are these snapshots or images of? They are intentionally abstract terms and are unhelpful. Yes, snapshot is much better, but still hopelessly abstract. > If a really good term were proferred, the documentation cost will be > amortized over a long period of time, so not a worry. Getting it accepted > by smalltalkers will be the harder problem. > > I'm not sure, though, that "system file" is right. The file part is just > an artifact of saving the state of the system, providing a way to preserving > it for a restart. > But I see a snapshot file are more than just a memory dump. It /is/ the entire Smalltalk system, class library, potentially compiler, debugger, tools. It is in a format that requires the virtual machine to run it, but it is in fact the Smalltalk system in quiescent form. It is not a memory dump. It is only a dump of the Smalltalk object heap, not the entire memory space. It is more than just a way of saving the state. It is also a way of moving that state and resuming it on a different system. Once you have the virtual machine key you can unlock the image, uh, system, but everything you need to program the system (beyond execution display and input devices) is there. Is there a recognizable term for the state of memory at a moment? > Cognitive scientists might have something, though I'm sure it would be > hugely debated whether there is any such thing. > I forget... > > Waste of time? Perhaps. But, beats indexing :) > > Bruce > > ----- Original Message ----- > *From:* Eliot Miranda <eliot.miranda(a)gmail.com> > *To:* The general-purpose Squeak developers list<squeak-dev(a)lists.squeakfoundation.org>; Pharo > Development <pharo-project(a)lists.gforge.inria.fr> ; vwnc NC<vwnc(a)cs.uiuc.edu> > *Sent:* Friday, March 12, 2010 9:59 AM > *Subject:* [vwnc] image overload > > Hi All, > > I'm sure Im opening an old topic but anyway, as I was riding the train > to work today I saw a shop called "Audio Images" and it struck me how > overloaded the term image is, and how poor a term for the contents of the > image file Smalltalk image is. What's in the image is a snapshot of... > almost the entire system (minus platform-specific virtual machine and > possibly minus sources). So Smalltalk system file would be a far better > term and stsys a more unique file extension (and according to Wikipedia STS > is unused too). I can imagine that changing form image would be hugely > expensive in documentation terms (docs, websites, workspaces, etc, etc). > But I can at least dream of a better term. > > P.S. I know, wasting one's time worrying about names. Almost as bad as > worrying about colours > > "And the wheel," said the Captain, "What about this wheel thingy? It sounds > a terribly interesting project." > "Ah," said the marketing girl, "Well, we're having a little difficulty > there." > "Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? > It's the single simplest machine in the entire Universe!" > The marketing girl soured him with a look. > "Alright, Mr. Wiseguy," she said, "if you're so clever, you tell us what > colour it should be." > > ------------------------------ > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >

1 0

Re: [Pharo-project] [Esug-list] Smalltalk app demo for GSoC
by Mariano Martinez Peck March 12, 2010

March 12, 2010

In the other thread, Stan Shepherd, proposed the following proposal: what do you think ??? for me is ok. Don't worry for the technology. It can be decided after, by the mentors and student. Now...we need a mentor...volunteer??? ........Stan mail: Hi, I had a first pass at a proposal. Feel free to improve upon it. The major question is whether we should bite the bullet and nominate what technologies we would use to build the reference implementation. It would also make it easier to nominate the mentors, if they are to be experts in the particular technologies. I think we had some volunteers previously for Seaside/Grease related projects? Smalltalk is enjoying a resurgence in its development, with a great deal of development going into building out its abilities to underpin a web framework. Auctomatic was a recent startup built in Smalltalk, that received seed funding from Y-Combinator and was acquired by Live Current Media. People who build in Smalltalk know that it lends itself to fast development, and that web aplications can be upgraded on the fly, without the need to take down the server. The goal of this project is to spread the use of Smalltalk to a wider audience. The scope is to produce a reference implementation of a Smalltalk stack, in the form of a working e-commerce site. The participants will select and integrate the preferred technologies, and build on existing demonstration systems. The result will make it much easier for potential new Smalltalkers to evaluate the technology, by seeing a fully working example, and then to get started on their own application by downloading that same example as a working template. The Smalltalk community, and in particular the open source Smalltalk community, will benefit as follows: improved quality and documentation of the technology stack at its interfaces Availability of a one stop solution as the basis for new projects better ability to attract new participants and projects to Smalltalk. The student participant will gain experience of implementation of a real world Smalltalk project, and of the practicalities of e-commerce development. The student would be well positioned to participate in a startup using the technology stack. 2010/3/11 Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <tallman(a)inbox.ru> > > "...to show the rest of the world what kind of things can be done in > Smalltalk nowadays" > > Yes. I really hate strange situation, when people "likes" smalltalk. > Sometimes they even make some cryptic tools for smalltalk. But, when some > end-user application needed, they don't choose smalltalk for it. Even if > they have a choice. Don't know about ESUG, but in RSUG (Russian Smalltalk > Users Group) it's a common situation. > > Generally, I hate the situation, when it's "cool" to make system tools, > tools for developing, tools for tools for developing, fremeworks, sometimes > really very cool and usefull...but somewhy it's "not cool" to use all this > staff to make real applications to solve real problems. What all this cool > stuff for then, huh? > > > The idea is to present potential newcomers to Smalltalk with a viable > stack that could be picked up as is, to give a > > starting point for developing web applications. > > I working for SmallPOS (http://squeaksource.com/SmallPOS.html) project for > some time. And it's very close to what you talking about. Even more, it > tends to be real application, with real shop using it for trading. I made it > opensource for exactly same reason - to show possibilities, to give an > example can be used to learn, to give a starting point to not start new > application from scratch and finally - fight this strange situation with > rarely practical application of smalltalk. > > > edit > > copy > > search > > display in list > > display in report > > a stuff or a list of stuff. > > Yes, all this and lot of details. I trying to use > Magritte+GLORP+Seaside+Scriptaculous enviroment. It was a good (and > unexpectedly painfull) practical experience. So, you can find: > - generating of lists and tree-like lists from magritte descriptions > - list filters and list fast searches based on magritte descriports, too > - custom magritte descriptors, components and memento, custom magritte > renderers and, generally, how to use Magritte descriptions for something > new, not-yet-implemented > - using both full-generated, full-customized and _partially-customized_ > (you don't touch component's structure, and you uses magrittes field > editors, but you can fully control when they situated) web-forms > - using web-forms with table parts inside them > - nested editing (to add Order you need add person, to add person, you need > to add City it lives at, to add a City you need to add a Country and so on) > - using GLORP with sometimes not-trivial mappings (not VERY untrivial I'm > sorry) > - using (custom magritte) mementos to fight the absence of nested > UnitOfWorks in GLORP, so nested editing becomes possible > - using AJAX to make interactive - and painless - webforms. You just added > list of affected fields in metadescriptor of given field - and they will be > updated via AJAX when form will be generated. > - using KomHttpServer to host files like icons and CSS-styles. > > I beleive this list will be expanded 'till GSoC will begins. So, maybe it > will help to solve problem > > > The only thing I am concerned a bit is the scope of the project. It seems > quite big. > > Maybe using SmallPOS as a basis will make things easier and faster, and > avoid some already-made efforts. Well, SmallPOS is not "web shop", it's POS, > but it should be quite posible - and even not too hard - to convert it into > webshop. I especially tried to keep it as modular as possible. I want to > try to use another persistence level and another GUI one day. > > Another problem necessary to solve is: I try to keep code more or less > clean, but due to time restrictins I can't totally avoid fast dirty tricks. > I just trying to mark them for future fixes :) > > Next, I absolutely do not worried about internationalisation. Taking into > account SmallPOS practically (maybe even totally) have no hardcoded labels > (they all comes from magritte descriptors or from domain-specific webforms) > it's not a conceptual problem, but it makes fast education virtually > impossible for non-russians. > > Finaly, PayPal prohibits receiving money for russian users, so I can't make > a paypal connector for e-business...I just can't test it ;) > > So there are still a lot of work for a student, but, utilising ready > results it may make things much easier - or, as an option, it make possible > to reach much more shining results with great efforts ;) > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/listinfo/esug-list >

4 11

[Pharo-project] URGENT!! Please help for GSoC
by Mariano Martinez Peck March 12, 2010

March 12, 2010

There was a new question in the submission to GSoC which says: "If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006." Does someone understand this ? is this acceptance projects (google slots) over the total proposed projects ? If true, I know in 2008 were selected 5 projects over 18, but I have no idea about 2007. Please, we are almost in deadline :( Thanks Mariano

4 4

Re: [Pharo-project] [squeak-dev] Re: LAST CHANCE Foreing Function Interface GSOC [WAS] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
by Mariano Martinez Peck March 12, 2010

March 12, 2010

Ok...I added a description Eliot send me. You can check if you want. Cheers Mariano On Fri, Mar 12, 2010 at 7:24 AM, Gilad Bracha <gbracha(a)gmail.com> wrote: > > On Thu, Mar 11, 2010 at 9:44 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > >> Hi! Recently I discovered that there is a parser project called SmaCC. I >> don't know if it works, but I think it includes parsers for C, Java and >> Smalltalk, do you know/did you try it? >> > > Thanks, but no thanks :-) > > I know SmaCC exists, but I never use parser generators. In Newspeak we use > parser combinators, which is a much nicer approach. There is a Smalltalk > version of the parser combinator library as well as a Newspeak one. > Making parsers is easy if you have the correct grammar. > > There is of course something to be said for a ready made parser if it > exists - but you have to be confident it is correct, and you become > dependent on the framework it uses. > > > >> >> Regards, >> Javier. >> >> 2010/3/11 John M McIntosh <johnmci(a)smalltalkconsulting.com> >> >>> Ah, well I can also help eliot on this, sometimes he gets too busy... >>> plus I want to ensure the objective-c binding happens. >>> >>> On 2010-03-11, at 11:26 AM, Gilad Bracha wrote: >>> >>> Hi Mariano, >>> >>> I'm pretty sure you mean to list Eliot as the co-mentor or mentor on this >>> one. If anyone got stuck and asked my help, I would end up bugging Eliot >>> anyway. And he did agree. >>> >>> >>> >>> On Thu, Mar 11, 2010 at 10:18 AM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> Tomorrow morning we will be submitting...so, for this project, we only >>>> have this proposal: >>>> >>>> Work on a cross-dialect foreign function call interface and implement it >>>> in at least two dialects. Candidates include Alien and GNU Smalltalk's >>>> CObject (using existing implementation has the advantage of having to >>>> implement in only _one_ other dialect!). Bonus points for implementing a C >>>> parser that would be able to construct bindings. GNU Smalltalk already >>>> contains a C preprocessor implementation. >>>> There is some support for parsing C headers in the Newspeak system. >>>> Aliens have been ported to Strongtalk as well as Squeak. >>>> >>>> The mentor will be John McIntosh and Gilad Brancha co-mentor. >>>> >>>> Can this proposal be more complete and have similar structure to the >>>> rest ? If true, send me the proposal. >>>> >>>> Check http://gsoc2010.esug.org/ideas.html >>>> >>>> Cheers >>>> >>>> Mariano >>> >>> >>> -- >>> Cheers, Gilad >>> >>> >>> -- >>> >>> =========================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> >>> =========================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > > > -- > Cheers, Gilad > > > >

1 0

Re: [Pharo-project] GSoC Idea: GLORP & Magritte integration/refactoring
by Mariano Martinez Peck March 12, 2010

March 12, 2010

Ok...Done. I put you as Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ as mentor (BTW, which is your name with this alphabet ?) and DiÃ³genes Moreira as co-mentor. Which difficult we should put ? beginner, intermediate or advanced ? Thanks Mariano 2010/3/12 Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <tallman(a)inbox.ru> > Glorp and Magritte both map between model-layer objects and other domains; > in Glorp's case, the relational database, in Magritte's case, the web. The > truth is that Magritte is a meta-description framework for all kind of > descriptions. However, it is mostly used for web applications. > > There are many similarities in how each framework manage model-layer class > - accessing model's fields, mapping those fields to it's representation, > caching/commiting/rollbacking, condition checking/validation and so on. Lot > of business applications are RDS-based, CRUD-like systems, with GUI > structure close to model structure, and model structure close to database > structure. So, developers sometimes feel they are repeating themselves when > they code first the Glorp descriptors and then the Magritte descriptors, or > vice versa. > > The goals of this project are: > Detect common aspects of both frameworks > Compare implementation of those common aspects in both frameworks, and > choose/compile "best" one > Detect any limitations of one framework revealed by comparison with the > other > Refactor the stuff, splitting it to three groups: "common metamodeling", > "Generic ORM" and "GLORP-related" > Cleanup GLORP from "common metamodeling" and "Generic ORM" stuff. > > The output is both a refactored codeset with three level of abstractness, > and an analysis of why functionality was splitted in this exactly way. > > Technical Details > =========== > Glorp and Magritte have good test suites. XP development to ensure existing > facilities remain functional will protect the student from breaking some > facilities as they experiment with refactorings. Maintaining, where > possible, deprecated methods that call new API in terms of old API may be > appropriate in the project, and may also assist introduction of the results > to the community. > > There are at least two projects to observe, one is for magritte-based SQL > mapping without GLORP, another one - generator of simple GLORP mappings with > Magritte descriptors. > > Maybe it will be necessary to make some tools for describing > domain-specific Magritte things. For example, something like "with this > domain-specific descriptor you should use this domain-specific memento for > caching". > > Benefits to the Student > =============== > Glorp and Magritte are two meta-modelling/mapping frameworks with > impressive capabilities solving real problems: the student who does this > project will acquire significant practical knowledge of this kind of > meta-modelling. Glorp and Magritte are also important parts of one way of > writing web applications: the student who does this project will have skills > that can be turned to practical account in web development. > > Benefits to the Community > =============== > Decreasing complexity and entry level for projects with both Magritte and > GLORP inside (a lot of enduser applications really). > Increasing quality of both Magritte and GLORP. Decreasing complexity of > GLORP, which is very complex now becouse of all the stuff for > meta-describing inside. > And avoiding double-efforts in future, so when we'll upgrade Magritte, > we'll upgrade GLORP simultaneously. > >

2 1

[Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial.
by George Herolyants March 12, 2010

March 12, 2010

Hi, guys! Here is a project idea for GSoC. Something that, I think, one day came into everyone's mind. I've just written it: --------------------------- ++ Pharo/Squeak integration with git/mercurial. Source code management is highly important aspect of every software project. Currently in Squeak/Pharo world developer has very limited choice of such tools. The only available full-featured SCM tool is Monticello. Other alternatives such as changesets lack in some areas. Monticello in its own turn has some disadvantages: it can only handle Smalltalk code while typical software project has many other artefacts (represented primarily as files) such as documentation, scripts, diagrams and so on, which would be nice to have in the same repository. This project aims to get round these disadvantages by creating a possibility for developers to use modern distributed source code management tools, which are popular outside of the Smalltalk community. The most recognized are git and mercurial. **Technical details** This project may go different ways towards it's goal, depending on decisions being made during it. Initial steps will be: * Examining git/mercurial and choose one of them considering simplicity of API and it's ease of use, supported operating systems on and other important factors. * Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk. * Studying how Squeak/Pharo handles system changes (changes of classes, methods). Then implement handlers for such changes to translate them to working copy using the mapping or through SCM API. * (optional but desirable) Implementing Smalltalk interface to the chosen SCM. It can be based on the SCM's command line interface or on it's API. These will require using OSProcess or FFI (or writing a plugin) respectively. Additional steps may include: * Implementing import/export tool for Monticello repositories. * Implementing simple user interface for the chosen SCM so that programmer can work with it from within the Smalltalk environment. Integration with widely used OmniBrowser would be even better. In addition to this a local git/mercurial repository can be used instead of sources/changes files. This will require: * Exploring the current mechanism used in Pharo/Squeak to maintain method version history. * Replacing it with the developed system which will write changes to the local git/mercurial repository. **Benefits to the student** The student will: * learn about modern source code management systems; * study their interfaces, both command line and API; * study Pharo/Squeak internal mechanisms related to handling of classes and methods changes and storing of method versions. * get experience in usage of FFI or writing plugins for Smalltalk VM; * get experience with making GUI in Pharo/Squeak; * enjoy writing programs in Smalltalk :) **Benefits to the community** Developers will be able to choose SCM system grounding this choice on their own preferences. The community will gain access to some famous source code hosting services such as GitHub or Bitbucket. Among other benefits it will increase visibility of the community and the Smalltalk language in whole. It also will lower the entry barriers to newcomers and as a consequence will help community grow. Getting rid of sources/changes files offers potentially unlimited method version history and avoids so called "condensing changes". And using local git/mercurial repository for this purpose will make managing changes more natural and uniform in small (every method accepting) and in large (changes at the project level). ---------------------------- I would like to be a mentor (if no one agrees to mentor) or co-mentor, if you guys don't mind. Hope it's not too late :) George

4 10

Re: [Pharo-project] GSOC 2010: Extensible parsing and persistency for Pier
by Mariano Martinez Peck March 12, 2010

March 12, 2010

Excellent. Which difficult you think it should have ? beginner, intermediate or advanced ? thanks Mariano On Fri, Mar 12, 2010 at 8:43 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Here is the description for a project related to Pier. > > Cheers, > Doru > > > > ---------- > > Extensible parsing and persistency for Pier > > > Mentors: Tudor Girba, Lukas Renggli > > Pier is an open-source content management system that aims at allowing > users to manage their content from the browser. It is based on a highly > object-oriented model dealing with multiple issues: multiple types of > structures that are meta-described, security management, user management, or > persistency. The preferred way to define content is through an wiki-like > syntax. Using this syntax, the user can specify multiple types of links, can > choose to embed entire structures, and it can even access external services > (like YouTube). > > This project will tackle two important problems related to extending Pier: > 1. While the Pier model is extensible the parser of the Pier syntax is not > easily extensible. The first job will be to rewrite the Pier parser to offer > hooks for syntax extensions. A possible path towards this implementation is > the use of the PetitParser framework. > 2. The main persistency mechanism in Pier is image-based. While the Pier > model is meta-described for most parts, there are still parts that are > accessed directly without the use of meta-descriptions. This poses a problem > for a generic persistency mechanism. The second part of the project will > focus on providing a mechanism for allowing each structure to specify a > persistency strategy. > > Benefits for the student: > - learn about meta-modeling and parsing. > - learn Seaside and work on a platform that has a wide acceptance already. > > Benefits for the community: > - a better content management system > > >

1 0

[Pharo-project] Fwd: GSOC 2010: Extensible parsing and persistency for Pier
by Tudor Girba March 12, 2010

March 12, 2010

Hi Mariano, Here is the description for a project related to Pier. Cheers, Doru ---------- Extensible parsing and persistency for Pier Mentors: Tudor Girba, Lukas Renggli Pier is an open-source content management system that aims at allowing users to manage their content from the browser. It is based on a highly object-oriented model dealing with multiple issues: multiple types of structures that are meta-described, security management, user management, or persistency. The preferred way to define content is through an wiki-like syntax. Using this syntax, the user can specify multiple types of links, can choose to embed entire structures, and it can even access external services (like YouTube). This project will tackle two important problems related to extending Pier: 1. While the Pier model is extensible the parser of the Pier syntax is not easily extensible. The first job will be to rewrite the Pier parser to offer hooks for syntax extensions. A possible path towards this implementation is the use of the PetitParser framework. 2. The main persistency mechanism in Pier is image-based. While the Pier model is meta-described for most parts, there are still parts that are accessed directly without the use of meta-descriptions. This poses a problem for a generic persistency mechanism. The second part of the project will focus on providing a mechanism for allowing each structure to specify a persistency strategy. Benefits for the student: - learn about meta-modeling and parsing. - learn Seaside and work on a platform that has a wide acceptance already. Benefits for the community: - a better content management system -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

1 0

March 12, 2010

The kind of stuff I would have love to see people experimenting with Squeak. We failed to be sexy on the UI level. Stef > > > Ideas for IDE UIs > http://www.cs.brown.edu/people/acb/codebubbles_site.htm > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > > > _______________________________________________ > Lsehub-staff mailing list > Lsehub-staff(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/lsehub-staff

5 5

Re: [Pharo-project] LAST CHANCE Foreing Function Interface GSOC [WAS] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
by John M McIntosh March 12, 2010

March 12, 2010

Ah, well I can also help eliot on this, sometimes he gets too busy... plus I want to ensure the objective-c binding happens. On 2010-03-11, at 11:26 AM, Gilad Bracha wrote: > Hi Mariano, > > I'm pretty sure you mean to list Eliot as the co-mentor or mentor on this one. If anyone got stuck and asked my help, I would end up bugging Eliot anyway. And he did agree. > > > > On Thu, Mar 11, 2010 at 10:18 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Tomorrow morning we will be submitting...so, for this project, we only have this proposal: > > Work on a cross-dialect foreign function call interface and implement it in at least two dialects. Candidates include Alien and GNU Smalltalk's CObject (using existing implementation has the advantage of having to implement in only _one_ other dialect!). Bonus points for implementing a C parser that would be able to construct bindings. GNU Smalltalk already contains a C preprocessor implementation. > There is some support for parsing C headers in the Newspeak system. Aliens have been ported to Strongtalk as well as Squeak. > > The mentor will be John McIntosh and Gilad Brancha co-mentor. > > Can this proposal be more complete and have similar structure to the rest ? If true, send me the proposal. > > Check http://gsoc2010.esug.org/ideas.html > > Cheers > > Mariano > > -- > Cheers, Gilad -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

2 1