March 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] GSoC proposal: Naked Objects using Magritte

by StÃ©phane Ducasse

would be cool too :) On Mar 9, 2012, at 2:43 PM, Stephan Eggermont wrote: > After a discussion with Esteban, Nick challenged me to submit a proposal. > An alternative would be to start from Glamour instead of from Magritte 3. > > > Proposal: Extend Magritte 3 to create Naked Objects style interfaces > Level: Intermediate > Possible mentor: Stephan Eggermont > Possible second mentor: Esteban Lorenzano > > Description > > "What if you never had to write a user interface again? What if you could > simply expose your business objects directly to the end user? How would this > affect your productivity? The way you work? The flexibility of your > applications? Is this even possible? Sometimes, yes. This describes a > style of application development, Naked Objects, where you write just the > business objects, and a framework lets your users interact directly with > these objects." (Dave Thomas) > > Technical Details > > Using Magritte we can already build (web/glamour)components representing > attributes of domain objects. What should we add to enable a NO UI? > - (better descriptions of) relationships between domain objects; > - descriptions of actions, with and without parameters; > - build a canvas where multiple domain objects can be shown; > - make the domain objects identifiable with an icon and title; > - add drag-and drop to initiate actions and manage relationships; > - add buttons/drop down menus for actions; > (and a few other things, of which I'll think when these are finished :) > > Benefits to the student > > Learn to use and extend a high quality framework. > Learn and practice interaction design. > Learn about hexagonal architecture. > > Benefits to the community > > The Naked Objects UI enables a very short feedback loop when prototyping a > domain model. It provides a showcase for the superiority of smalltalk as a > rapid development environment. It allows scaling down the engineering effort > needed to create custom solutions. It fits very well with exploratory modeling. > In a mixed UI style it allows focusing effort on only the critical parts of the UI. > >

March 9, 2012

Re: [Pharo-project] Increase populatity of Pharo by doing some Killer-OpenSource-Tools

by StÃ©phane Ducasse

On Mar 9, 2012, at 1:05 PM, Stefan Krecher wrote: > Hi, > > i suspect, that the popularity of Pharo (or Smalltalk in general) > could be increased by developing some "Killer-OpenSource-Tools". > By "Killer-OpenSource-Tools" i think of Tools, e.g. for supporting the > Software-Development-Process in general. Moose of course could become > such a tool. > But i think of some standard Tools like Bug-Tracking/ Project Management. I agree > Let me explain by a short example. > In a lot of projects i needed to use Trac (http://trac.edgewall.org/) > as a Ticketing system. Trac is a "simple" Python script to manage > Tasks/ Tickets, it is customizable and can be enhanced. But it is very > very ugly, configuration is very unhandy. We like to print tickets to > pin them to a whiteboard for use in daily scrum meetings. This and > additional reports are made by BIRT-Reports. Everything feels very > unstable but a lot of companies prefer Trac because of licensing > issues (e.g. Jira is better but commercial). > A simple and good looking Ticketing-System for use in an agile team > would be a good thing - it's a CRUD-Application with some Reporting > and maybe some eye candy. Why don't you start based on experience to build a tool and share with us. > Another idea could be a Tool for organizing activities regarding > Softwaretests, e.g. generation of Testspecifications/ -plans and > reports on test-runs. I used TestLink (http://www.teamst.org/) but it > is ugly and unhandy too ... > > Pier CMS could be a good solution for Intranets or Websites, but the > lack of Documentation keeps people from using it. > > Is anyone interested in creating some OpenSource-Projects for use in a > wider range? Those Tools should look "sexy" and should be easy to try > (OneClick) or to install as a Service. Yes we are lot of people interested in that. Just quite busy. > > regards, > Stefan >

March 9, 2012

Re: [Pharo-project] GSoC proposal: Naked Objects using Magritte

by Tudor Girba

I could offer help here as well. Cheers, Doru On Fri, Mar 9, 2012 at 2:43 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > After a discussion with Esteban, Nick challenged me to submit a proposal. > An alternative would be to start from Glamour instead of from Magritte 3. > > > Proposal: Extend Magritte 3 to create Naked Objects style interfaces > Level: Intermediate > Possible mentor: Stephan Eggermont > Possible second mentor: Esteban Lorenzano > > Description > > "What if you never had to write a user interface again? What if you could > simply expose your business objects directly to the end user? How would this > affect your productivity? The way you work? The flexibility of your > applications? Is this even possible? Sometimes, yes. This describes a > style of application development, Naked Objects, where you write just the > business objects, and a framework lets your users interact directly with > these objects." (Dave Thomas) > > Technical Details > > Using Magritte we can already build (web/glamour)components representing > attributes of domain objects. What should we add to enable a NO UI? > - (better descriptions of) relationships between domain objects; > - descriptions of actions, with and without parameters; > - build a canvas where multiple domain objects can be shown; > - make the domain objects identifiable with an icon and title; > - add drag-and drop to initiate actions and manage relationships; > - add buttons/drop down menus for actions; > (and a few other things, of which I'll think when these are finished :) > > Benefits to the student > > Learn to use and extend a high quality framework. > Learn and practice interaction design. > Learn about hexagonal architecture. > > Benefits to the community > > The Naked Objects UI enables a very short feedback loop when prototyping a > domain model. It provides a showcase for the superiority of smalltalk as a > rapid development environment. It allows scaling down the engineering effort > needed to create custom solutions. It fits very well with exploratory modeling. > In a mixed UI style it allows focusing effort on only the critical parts of the UI. > > -- www.tudorgirba.com "Every thing has its own flow"

March 9, 2012

[Pharo-project] GsoC - Nautilus Hazelnut

by Benjamin

Project name : Nautilus Level (Beginner, Intermediate, Advanced) : Intermediate Possible Mentor : Stephane Ducasse ? Description : Nautilus is a new browser based on the latests system meta model tools like RPackage or Ring. The goal is to ensure this browser has the stability and all the features required to become the next standard browser. Technical Details : Nautilus may be improved on different levels: fixing last bugs, improve the way the UI widget are defined to be able to easily change the UI representation, create some plugins for metrics, better traits integration, better icons. Morphic may have to be improved Benefits to the Student : The student will learn and use the latests infrastructure tools, the different Morphic's layers. He will also participate to a tool which is used and will be. Benefits to the Community : The community will gain a more stable and up to date default browser. Project name : Hazelnut Level (Beginner, Intermediate, Advanced) : Advanced Possible Mentor : Stephane Ducasse ? Description : Hazelnut is part of the Seed project which goal is to bootstrap the system. Technical Details : Ensure the validity of the created kernel and also improved the serialization mechanism. The goal is to clarify and ensure a creation mechanism which can be applied to a dynamically generated kernel or to a statically describe kernel as well. Benefits to the Student : Deep understanding of the system layouts, of the kernel definition, of the meta model and the reflexivity of the system. The student will also learn the object format and the basic of the VM use. Benefits to the Community : The community will gain a way to bootstrap a new fresh kernel from an existing image or from a kernel description. It could also be used to generate minimal kernel used for embedded technology. Ben

March 9, 2012

[Pharo-project] GSoC proposal: Naked Objects using Magritte

by Stephan Eggermont

After a discussion with Esteban, Nick challenged me to submit a proposal. An alternative would be to start from Glamour instead of from Magritte 3. Proposal: Extend Magritte 3 to create Naked Objects style interfaces Level: Intermediate Possible mentor: Stephan Eggermont Possible second mentor: Esteban Lorenzano Description "What if you never had to write a user interface again? What if you could simply expose your business objects directly to the end user? How would this affect your productivity? The way you work? The flexibility of your applications? Is this even possible? Sometimes, yes. This describes a style of application development, Naked Objects, where you write just the business objects, and a framework lets your users interact directly with these objects." (Dave Thomas) Technical Details Using Magritte we can already build (web/glamour)components representing attributes of domain objects. What should we add to enable a NO UI? - (better descriptions of) relationships between domain objects; - descriptions of actions, with and without parameters; - build a canvas where multiple domain objects can be shown; - make the domain objects identifiable with an icon and title; - add drag-and drop to initiate actions and manage relationships; - add buttons/drop down menus for actions; (and a few other things, of which I'll think when these are finished :) Benefits to the student Learn to use and extend a high quality framework. Learn and practice interaction design. Learn about hexagonal architecture. Benefits to the community The Naked Objects UI enables a very short feedback loop when prototyping a domain model. It provides a showcase for the superiority of smalltalk as a rapid development environment. It allows scaling down the engineering effort needed to create custom solutions. It fits very well with exploratory modeling. In a mixed UI style it allows focusing effort on only the critical parts of the UI.

March 9, 2012

Re: [Pharo-project] more Nautilus feed back

by Benjamin

Interesting proposition, I will keep that on my desktop :) Thanks Ben On Mar 9, 2012, at 12:27 PM, Helene Bilbo wrote: > > Igor Stasenko wrote >> >> so then go finish arts and design schools (min 5 years each). and only >> then you may get back and continue working on nautilus! Hurry up. :) >> >> I can also easily tell what i don't like in Nautilus. Much harder is >> to propose alternative. >> > So after finishing art school i propose a better UI in the attached drawing. > It gets rid of all Toggle-Buttons except one for the comments: > > http://forum.world.st/file/n4459175/nautilusui.jpg > > Good Luck with the exams, Helene. > > > -- > View this message in context: http://forum.world.st/more-Nautilus-feed-back-tp4457416p4459175.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 9, 2012

[Pharo-project] new CI Job: Project Pharo Kernel Reload Tests-Unix

by Pavel Krivanek

Hi, I created a new Jenkins job named "Project Pharo Kernel Reload Tests-Unix". It is the same job as Pharo 1.4 Tests-Unix but with Pharo Kernel Reload as the base. In ideal case it should have the same set of failing tests as Pharo 1.4 Tests-Unix (zero would be nice ;-)). Currently it has one more failing job: Tests.Release.ReleaseTest.testUndeclared. But I think it is a big achievement in itself :-) Cheers, -- Pavel

March 9, 2012

[Pharo-project] Increase populatity of Pharo by doing some Killer-OpenSource-Tools

by Stefan Krecher

Hi, i suspect, that the popularity of Pharo (or Smalltalk in general) could be increased by developing some "Killer-OpenSource-Tools". By "Killer-OpenSource-Tools" i think of Tools, e.g. for supporting the Software-Development-Process in general. Moose of course could become such a tool. But i think of some standard Tools like Bug-Tracking/ Project Management. Let me explain by a short example. In a lot of projects i needed to use Trac (http://trac.edgewall.org/) as a Ticketing system. Trac is a "simple" Python script to manage Tasks/ Tickets, it is customizable and can be enhanced. But it is very very ugly, configuration is very unhandy. We like to print tickets to pin them to a whiteboard for use in daily scrum meetings. This and additional reports are made by BIRT-Reports. Everything feels very unstable but a lot of companies prefer Trac because of licensing issues (e.g. Jira is better but commercial). A simple and good looking Ticketing-System for use in an agile team would be a good thing - it's a CRUD-Application with some Reporting and maybe some eyecandy. Another idea could be a Tool for organizing activities regarding Softwaretests, e.g. generation of Testspecifications/ -plans and reports on test-runs. I used TestLink (http://www.teamst.org/) but it is ugly and unhandy too ... Pier CMS could be a good solution for Intranets or Websites, but the lack of Documentation keeps people from using it. Is anyone interested in creating some OpenSource-Projects for use in a wider range? Those Tools should look "sexy" and should be easy to try (OneClick) or to install as a Service. regards, Stefan

March 9, 2012

Re: [Pharo-project] more Nautilus feed back

by Helene Bilbo

Igor Stasenko wrote > > so then go finish arts and design schools (min 5 years each). and only > then you may get back and continue working on nautilus! Hurry up. :) > > I can also easily tell what i don't like in Nautilus. Much harder is > to propose alternative. > So after finishing art school i propose a better UI in the attached drawing. It gets rid of all Toggle-Buttons except one for the comments: http://forum.world.st/file/n4459175/nautilusui.jpg Good Luck with the exams, Helene. -- View this message in context: http://forum.world.st/more-Nautilus-feed-back-tp4457416p4459175.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 9, 2012

Re: [Pharo-project] GSoC: ARM jitter for Squeak VM

by S Krish

Thx, I hope I would do justice to this in terms of time...! .. Let me just dive into this and look in.. PS: Wish a day had 48 hrs to it.. with rest 24 to your own pursuit.. not for work or home. On 3/9/12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Krish, Hi Esteban, > > On Thu, Mar 8, 2012 at 9:17 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> > wrote: > >> Let me know if I can help in any way.. on this.. > > > On Thu, Mar 8, 2012 at 9:22 AM, Esteban Lorenzano > <estebanlm(a)gmail.com>wrote: > >> I would really like to co-mentor something like this... but I presume I >> have more things to learn than to teach :) >> >> anyway, if there is a place to help, count me in. >> >> Esteban >> > > you are both most welcome. i will definitely involve you. > > If you want something to do now, the first thing to do is to produce an ARM > simulator plugin, analogous to the Bochs simulator. The first thing to do > is go out and find a suitable software simulator, written in either C or > C++ (cuz these suit the plugin compilation system) and play with it, > configuring an ARM and running some simple assembler on it. Once that's > working you can write a plugin, and an Alien interface a la BochsIA32Plugin > and BochsIA32Alien. You can find tests you could use as a model in > source.squeak.org/VMMaker/Cog-Processors-Tests BochsIA32AlienTests. e.g. > testNFib16 runs machine code that implements NFib (same as benchFib). > > > this is exciting! > > cheers! > > >> El 08/03/2012, a las 8:07a.m., Nick Ager escribiÃ³: >> >> Here's hoping that in a similar way to Yanni and the ePUB proposal and >> someone will jump in and say that they are already working on this. >> >> Quoting Eliot: >> >> It's not overambitious for someone good. And I'd love to see it happen. >>> But finding time to be a mentor has proven difficult for me in the past. >>> I'd happily be part-mentor, but I need someone to at least help in the >>> GSoC process... >> >> >> >> so if there is anyone out there that can help Eliot and Igor with >> mentoring or the GSoC process, jump in and offer support. >> >> The proposal: >> >> ----- >> >> Name: ARM jitter for Squeak VM >> Level: Advanced >> Possible mentor: Eliot Miranda >> Possible second mentor: Igor Stasenko >> >> Description >> The Squeak VM is the dynamic virtual machine used for many open-source >> software projects such as Scratch [1], eToys [2], Pharo [3], the Newspeak >> language [4], the innovative web framework Seaside [5] and many others. >> CogVM [6] is a development of the Squeak VM which adds a powerful Intel >> x86 >> JITer [7]. The CogVM JIT has significantly improved the performance of the >> open-source Smalltalk projects which have adapted to use it. >> Increasingly low cost highly capable ARM hardware such as the Raspberry Pi >> [8] and the Beagle Board [9] have become widely available. In addition the >> new version of the one-laptop-per-child is based on the ARM platform [10]. >> The Squeak VM compiles for ARM platforms, but currently there is no JIT on >> ARM platforms, significantly decreasing the performance of popular >> software >> on ARM. The goal of this project is to add simple ARM JITTing capability >> to >> the CogVM. >> >> [1] http://scratch.mit.edu/ >> [2] http://www.squeakland.org/about/intro/ >> [3] http://www.pharo-project.org >> [4] http://newspeaklanguage.org/ >> [5] http://seaside.st/ >> [6] http://gitorious.org/cogvm >> [7] http://en.wikipedia.org/wiki/Just-in-time_compilation >> [8] http://www.raspberrypi.org/ >> [9] http://beagleboard.org/bone >> [10] http://one.laptop.org/about/xo-3 >> >> Technical Details >> The work would require a interest in virtual machine optimisation, some >> knowledge of Intel x86 and ARM assembler and knowledge of C and dynamic >> languages. >> The Squeak and Cog VM are written in a simplified subset of Smalltalk >> known as slang [11] - which then generates C output and forms the basis of >> the VM. >> As the Squeak VM is a Smalltalk program, it is developed in Smalltalk, and >> the Cog JIT is no exception. The VM, including the JIT, is written in >> Smalltalk and run in the context of the Smalltalk IDE, but the JIT still >> generates machine-code that must be evaluated within the Smalltalk >> environment. On x86 is done by interfacing to an x86 simulator library >> derived from the Bochs x86/x86-64 PC simulator, written in C++. >> Implementing the ARM port should be no different. The first task will be >> to choose and interface to a suitable ARM simualtor/emulator. Once this >> is >> working, the ARM code generator can be incrementally developed within >> Smalltalk. Finally once the simulator is fully functional one can get >> down >> and dirty with an actual physical ARM machine - such as the Raspberry Pi >> or >> Beagle Board. >> [11] http://wiki.squeak.org/squeak/2267 >> >> >> Benefits to the Student >> The student will gain an in-depth knowledge of virtual machine >> optimisation, working in a productive innovative environment - it's >> great fun to be able to implement a JIT in a safe high-level dynamic >> language, instead of the traditional route of developing in C/C++ and >> debugging in GDB. >> The student will have the satisfaction of seeing performance gains for a >> range of high-profile projects which use the Squeak VM on ARM. >> >> Benefits to the Community >> The Smalltalk community will gain an initial implementation of an ARM >> Jitter which can then be further developed along-side the x86 dynamic >> translation work. An ARM Jitter for the CogVM will improve the performance >> of many notable open-source projects on low-cost ARM hardware, bringing >> innovative software and development environments to wider community. >> >> ---- >> >> Cheers >> >> Nick >> >> >> > > > -- > best, > Eliot >

March 9, 2012