- Esug-list - lists.esug.org

Re: [Esug-list] GSoC Project Proposal: Morphic for Amber, Looking for mentor

by Igor Stasenko

On 29 April 2013 23:30, Matthias Springer <me(a)matthiasspringer.de> wrote: > Hi, > > I decided to write a proposal for both the Athens HTML5 Canvas project and > the Morphic for Amber project. The Athens project will be my primary > (favorite) project and in case it does not get accepted by Google hopefully > the Morphic project does. Does that make sense? Is there a way to > prioritize the Athens proposal? Everything comes at cost, if Athens will be selected, that will mean some other project will not. > Juan, would you like to be the primary mentor for the Morphic project? > > Either way, I plan to do the Morphic project now or after the GSoC (built > on top of Athens). What a spirit! :) > Thanks for your ideas and comments! > > > > Best regards, > Matthias > > -- > Matthias Springer * me(a)matthiasspringer.de * +49-1577-3814255 > Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) > Stahnsdorfer Straße 144c, 14482 Potsdam > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > -- Best regards, Igor Stasenko.

April 29, 2013

Re: [Esug-list] GSoC Project Proposal: Morphic for Amber, Looking for mentor

by Matthias Springer

Hi, I decided to write a proposal for both the Athens HTML5 Canvas project and the Morphic for Amber project. The Athens project will be my primary (favorite) project and in case it does not get accepted by Google hopefully the Morphic project does. Does that make sense? Is there a way to prioritize the Athens proposal? Juan, would you like to be the primary mentor for the Morphic project? Either way, I plan to do the Morphic project now or after the GSoC (built on top of Athens). Thanks for your ideas and comments! Best regards, Matthias -- Matthias Springer * me(a)matthiasspringer.de * +49-1577-3814255 Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) Stahnsdorfer Straße 144c, 14482 Potsdam

April 29, 2013

*important*: science needs you - we need your feedback on current integration tools.

by Stéphane Ducasse

Hi guys we got only 20 answers filled up and I cannot believe that you Smalltalkers do not integrate fixes when you work on multiple contributors, even Envy can be improved. Please consider spending 15 min to get information on your practices and problems. Please distribute this mail as you see it fit. Stef > Hi all, > > We are conducting an academic research to improve tools for software integration. If you maintain a project with multiple contributors, we will greatly appreciate your participation. > > Your answers will be used for research purposes and to support the development of new tools. You can later access the results of this study, make free use of our tools to support the integration of changes, and maybe receive a gift. > > https://sondages.inria.fr/index.php/667625/lang-en > > Best regards, > Martin Dias, Nicolas Anquetil, Veronica Isabel Uquillas, Stéphane Ducasse and the RMOD Inria team

April 29, 2013

JUnit structure

by Joseph Pelrine

I'm really happy that SUnit isn't this ugly. http://java.dzone.com/articles/your-code-structured Cheers -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine(a)metaprog.com Web: http://www.metaprog.com As soon as you introduce people, things become complex.

April 29, 2013

Re: [Esug-list] GSoC Project Proposal: Integrated Chat System

by Nicolás Paez

thanks, I will take a look at it. Saludos! NicoPaez <http://nicopaez.wordpress.com/> On Sun, Apr 28, 2013 at 9:56 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Nico, > > there is already an argentinian student who proposed a project to work on > a Jabber Client/Server. The project is here > http://gsoc2013.esug.org/projects#h-45 > But, this project does not have a mentor. Maybe you can join and both > projects merged? :) > > Guille > > > On Sun, Apr 28, 2013 at 2:53 PM, Nicolás Paez <nicopaez(a)gmail.com> wrote: > >> Hi everyone, >> >> I have an idea for a project. Let my explain it: >> >> *Context / Business need* >> I teach OOP at the university with Pharo. Every week our students have to >> solve some assignments programming with Pharo. We would like to have an >> integrated chat system into Pharo in order to be able to assist our >> students when they are working on the assignments. >> >> *Vision* >> I imagine this chat to allow the exchange of text but it should also >> allow to send "a class or a category" so the teacher (or other student) can >> analyse/reproduce a situation/error. Even more, it could use fuel to >> serialize the error and share it. >> From the implementation point of view I image this like a client-server >> system. Each subject/institution could have its own server, then the >> students/teacher, open Pharo, start the chat client and connect to the >> selected server. >> >> >> *What do you think? * >> >> If there is a student interested in this I could be the mentor. >> >> Regards, >> >> Saludos! >> NicoPaez <http://nicopaez.wordpress.com/> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> >

April 29, 2013

Re: [Esug-list] GSoC Project Proposal: Morphic for Amber, Looking for mentor

by Juan Vuletich (mail lists)

Quoting Matthias Springer <me(a)matthiasspringer.de>: > OK, I'm getting the feeling that it's probably best to implement a > proper HTML Canvas rendering engine (Athens) first and build a > Morphic(-like) framework (e.g. the morphs from Cuis) on top of that > afterwards. Having a good architecture is more important to me than > getting results as fast as possible. It doesn't really matter. Given that you are using HTML Canvas for drawing, the only thing you take from Athens or Morphic 3 is the api. And both are based on SVG, so they are essentially equivalent. As the rendering api is really close to the Canvas backend, it is rather easy to do. The interesting part of the project is to make a working Morphic world on top of that. > -- > Matthias Springer * me(a)matthiasspringer.de * +49-1577-3814255 > Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) > Stahnsdorfer Straße 144c, 14482 Potsdam Cheers, Juan Vuletich

April 28, 2013

Re: [Esug-list] GSoC Project Proposal: Morphic for Amber, Looking for mentor

by Juan Vuletich (mail lists)

Quoting Matthias Springer <me(a)matthiasspringer.de>: > Hi Juan, > >> >> Morphic 3 is a reimplementation of Squeak Morphic with these >> fundamental changes: >> - Drawing is vector graphics (like HTML5 Canvas and SVG) >> - Each morph defines a local coordinate system >> - Coordinates are float, and not tied to Display coordinates >> - Code is simplified and easier to understand >> The new drawing engine will be published this year (MIT license). >> The rest of the work is in the Morphs themselves, and is done >> incrementally in the Cuis project. This means that the latest Cuis >> default and only GUI is always the most current state of this work. >> Right now, in Cuis, all morphs are specified in local float >> coordinates, and the Morphic code is much smaller and easier to >> understand that in other Squeak variants. > So Morphic3 is the rendering/drawing engine and Cuis provides the > morphs on top of Morphic3? The difference doesn't really matter, but I'd rather say that Morphic 3 is the morphs + rendering engine, and that the Morphic variant is Cuis is called Morphic 3. >> If I understand this correctly, this means not using Canvas for >> drawing graphics (like LivelyKernel and morphic.js do), but using >> the html rendering in the browser (more like Seaside, Iliad and and >> Aida). This approach has pros and cons, but to me, it essencially >> means it is not a real Morphic. A fundamental feature of Morphic is >> that the look and behavior of morphs is completely done in >> Smalltalk, and therefore, only limited by what the Display can >> show. This means not using any external widgets library (like html >> widgets, or qt, or native OS widgets, etc). In Morphic, it is >> possible to do stuff like the EnvelopeEditorMorph, and what you see >> in LivelyKernel and morphic.js. In html, we are limited to what the >> browsers provide. > I talked with several people about this and I think it is indeed > better and cleaner to use an HTML canvas for drawing. Putting divs > together with position:absolute - that's what I'm currently doing - > is really ugly. My plans for the next days are to experiment with > HTML canvas and try to shift all rendering to the canvas. Good. >> This means that you want the real Morphic power and flexibility. >> Then the strategy would be to start by making a Morphic World that >> can host the most basic morphs, maybe not unlike what morphic.js is >> doing, but in Smalltalk (Amber). If you follow this path, the next >> question is whether to use global coordinates (like Squeak, Pharo >> and other derivatives, except Cuis, and like morphic.js) or local >> coordinates (like LivelyKernel, Self and Cuis). > Sounds like a plan. My initial motivation was to get an existing > Pharo application running in Amber without changing too much code. > But I'd also be willing to change that application in order to get a > better Morphic implementation. > > I didn't think about coordinate systems yet. In my current > implementation the top, left corner of a window is always 0@0 > regardless of where the window is located. That's the idea of local > coordinates, right? The idea of local coordinates is to make them local to the owner. For instance, if you add a button at 10@20 pixels from the topLeft corner of the window, and you later move the window to some position, the position ivar of the button doesn't change: the button is still 10@20 pixels from the topLeft of the window. With global coordinates, when moving the window around you need to also adjust the position ivar of every submorph down the tree. Inspect and browse a bit Cuis and Squeak/Pharo to see the difference. >> If you consider doing a remote, web based canvas for Cuis / Morphic >> 3 servers, I would be delighted to be your mentor, as your work >> would be closely related to mine. Besides, I believe this would be >> the easiest way to enable fully Morphic webapps in Smalltalk. > In my opinion, one of the biggest advantages of Amber is that you > don't need any particular web server or backend. A web browser is > everything you need and the whole Smalltalk VM is running in the web > browser (it's also much easier to set up). I'm also wondering > whether remote rendering is fast enough. You need to talk to the > server on every event (mouse click, mouse move (this is really > expensive), keyboard, ...) and every primitive you render must be > sent to the client. It is fast enough, as hundreds of multiplayer web based javascript games show. In any case, it's your call. Turning Amber into a full Morphic environment is a great project too. >> If you do a SVG Morphic for Amber, similar to morphic.js, I could >> also help. This would mean that a longer term project would be >> needed to bring it to the point of real compatibility with Squeak / >> Pharo / Cuis. > This is more or less what I had in mind, probably by drawing morphs > onto an HTML canvas. Maybe we can share code between Cuis and Amber > for the actual morphs, once I have implemented the drawing/rendering > component. It should be sufficient to implement the Morphic3 > interface that is used by Cuis and I can render all Cuis morphs from > then on, right? Yes. You'll also need to grab mouse / keyboard events from the user and feed them to the morphs, but you already knew that. You also need to handle screen damage to be repaired on the next cycle. > Best regards, > Matthias > > -- > Matthias Springer * me(a)matthiasspringer.de * +49-1577-3814255 > Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) > Stahnsdorfer Straße 144c, 14482 Potsdam Cheers, Juan Vuletich

April 28, 2013

Re: [Esug-list] GSoC Project Proposal: Morphic for Amber, Looking for mentor

by Matthias Springer

>> In my opinion, one of the biggest advantages of Amber is that you don't need >> any particular web server or backend. A web browser is everything you need >> and the whole Smalltalk VM is running in the web browser (it's also much >> easier to set up). I'm also wondering whether remote rendering is fast >> enough. You need to talk to the server on every event (mouse click, mouse >> move (this is really expensive), keyboard, ...) and every primitive you >> render must be sent to the client. > yes, and in that regard, http://gsoc2013.esug.org/projects/athens-html5-canvas > is way better alternative. > > OK, I'm getting the feeling that it's probably best to implement a proper HTML Canvas rendering engine (Athens) first and build a Morphic(-like) framework (e.g. the morphs from Cuis) on top of that afterwards. Having a good architecture is more important to me than getting results as fast as possible. -- Matthias Springer * me(a)matthiasspringer.de * +49-1577-3814255 Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) Stahnsdorfer Straße 144c, 14482 Potsdam

April 28, 2013

Re: [Esug-list] GSoC Project Proposal: Morphic for Amber, Looking for mentor

by Igor Stasenko

On 28 April 2013 16:50, Matthias Springer <me(a)matthiasspringer.de> wrote: > Hi Juan, > > >> >> Morphic 3 is a reimplementation of Squeak Morphic with these fundamental >> changes: >> - Drawing is vector graphics (like HTML5 Canvas and SVG) >> - Each morph defines a local coordinate system >> - Coordinates are float, and not tied to Display coordinates >> - Code is simplified and easier to understand >> The new drawing engine will be published this year (MIT license). The rest >> of the work is in the Morphs themselves, and is done incrementally in the >> Cuis project. This means that the latest Cuis default and only GUI is always >> the most current state of this work. Right now, in Cuis, all morphs are >> specified in local float coordinates, and the Morphic code is much smaller >> and easier to understand that in other Squeak variants. > > So Morphic3 is the rendering/drawing engine and Cuis provides the morphs on > top of Morphic3? > > >> >> If I understand this correctly, this means not using Canvas for drawing >> graphics (like LivelyKernel and morphic.js do), but using the html rendering >> in the browser (more like Seaside, Iliad and and Aida). This approach has >> pros and cons, but to me, it essencially means it is not a real Morphic. A >> fundamental feature of Morphic is that the look and behavior of morphs is >> completely done in Smalltalk, and therefore, only limited by what the >> Display can show. This means not using any external widgets library (like >> html widgets, or qt, or native OS widgets, etc). In Morphic, it is possible >> to do stuff like the EnvelopeEditorMorph, and what you see in LivelyKernel >> and morphic.js. In html, we are limited to what the browsers provide. > > I talked with several people about this and I think it is indeed better and > cleaner to use an HTML canvas for drawing. Putting divs together with > position:absolute - that's what I'm currently doing - is really ugly. My > plans for the next days are to experiment with HTML canvas and try to shift > all rendering to the canvas. > >> >> This means that you want the real Morphic power and flexibility. Then the >> strategy would be to start by making a Morphic World that can host the most >> basic morphs, maybe not unlike what morphic.js is doing, but in Smalltalk >> (Amber). If you follow this path, the next question is whether to use global >> coordinates (like Squeak, Pharo and other derivatives, except Cuis, and like >> morphic.js) or local coordinates (like LivelyKernel, Self and Cuis). > > Sounds like a plan. My initial motivation was to get an existing Pharo > application running in Amber without changing too much code. But I'd also be > willing to change that application in order to get a better Morphic > implementation. > > I didn't think about coordinate systems yet. In my current implementation > the top, left corner of a window is always 0@0 regardless of where the > window is located. That's the idea of local coordinates, right? > > >> If you consider doing a remote, web based canvas for Cuis / Morphic 3 >> servers, I would be delighted to be your mentor, as your work would be >> closely related to mine. Besides, I believe this would be the easiest way to >> enable fully Morphic webapps in Smalltalk. > > In my opinion, one of the biggest advantages of Amber is that you don't need > any particular web server or backend. A web browser is everything you need > and the whole Smalltalk VM is running in the web browser (it's also much > easier to set up). I'm also wondering whether remote rendering is fast > enough. You need to talk to the server on every event (mouse click, mouse > move (this is really expensive), keyboard, ...) and every primitive you > render must be sent to the client. yes, and in that regard, http://gsoc2013.esug.org/projects/athens-html5-canvas is way better alternative. > >> >> If you do a SVG Morphic for Amber, similar to morphic.js, I could also >> help. This would mean that a longer term project would be needed to bring it >> to the point of real compatibility with Squeak / Pharo / Cuis. > > This is more or less what I had in mind, probably by drawing morphs onto an > HTML canvas. Maybe we can share code between Cuis and Amber for the actual > morphs, once I have implemented the drawing/rendering component. It should > be sufficient to implement the Morphic3 interface that is used by Cuis and I > can render all Cuis morphs from then on, right? > > Best regards, > Matthias > > > -- > Matthias Springer * me(a)matthiasspringer.de * +49-1577-3814255 > Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) > Stahnsdorfer Straße 144c, 14482 Potsdam > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- Best regards, Igor Stasenko.

April 28, 2013

Re: [Esug-list] GSoC Project Proposal: Morphic for Amber, Looking for mentor

by Matthias Springer

Hi Juan, > > Morphic 3 is a reimplementation of Squeak Morphic with these > fundamental changes: > - Drawing is vector graphics (like HTML5 Canvas and SVG) > - Each morph defines a local coordinate system > - Coordinates are float, and not tied to Display coordinates > - Code is simplified and easier to understand > The new drawing engine will be published this year (MIT license). The > rest of the work is in the Morphs themselves, and is done > incrementally in the Cuis project. This means that the latest Cuis > default and only GUI is always the most current state of this work. > Right now, in Cuis, all morphs are specified in local float > coordinates, and the Morphic code is much smaller and easier to > understand that in other Squeak variants. So Morphic3 is the rendering/drawing engine and Cuis provides the morphs on top of Morphic3? > > If I understand this correctly, this means not using Canvas for > drawing graphics (like LivelyKernel and morphic.js do), but using the > html rendering in the browser (more like Seaside, Iliad and and Aida). > This approach has pros and cons, but to me, it essencially means it is > not a real Morphic. A fundamental feature of Morphic is that the look > and behavior of morphs is completely done in Smalltalk, and therefore, > only limited by what the Display can show. This means not using any > external widgets library (like html widgets, or qt, or native OS > widgets, etc). In Morphic, it is possible to do stuff like the > EnvelopeEditorMorph, and what you see in LivelyKernel and morphic.js. > In html, we are limited to what the browsers provide. I talked with several people about this and I think it is indeed better and cleaner to use an HTML canvas for drawing. Putting divs together with position:absolute - that's what I'm currently doing - is really ugly. My plans for the next days are to experiment with HTML canvas and try to shift all rendering to the canvas. > > This means that you want the real Morphic power and flexibility. Then > the strategy would be to start by making a Morphic World that can host > the most basic morphs, maybe not unlike what morphic.js is doing, but > in Smalltalk (Amber). If you follow this path, the next question is > whether to use global coordinates (like Squeak, Pharo and other > derivatives, except Cuis, and like morphic.js) or local coordinates > (like LivelyKernel, Self and Cuis). Sounds like a plan. My initial motivation was to get an existing Pharo application running in Amber without changing too much code. But I'd also be willing to change that application in order to get a better Morphic implementation. I didn't think about coordinate systems yet. In my current implementation the top, left corner of a window is always 0@0 regardless of where the window is located. That's the idea of local coordinates, right? > If you consider doing a remote, web based canvas for Cuis / Morphic 3 > servers, I would be delighted to be your mentor, as your work would be > closely related to mine. Besides, I believe this would be the easiest > way to enable fully Morphic webapps in Smalltalk. In my opinion, one of the biggest advantages of Amber is that you don't need any particular web server or backend. A web browser is everything you need and the whole Smalltalk VM is running in the web browser (it's also much easier to set up). I'm also wondering whether remote rendering is fast enough. You need to talk to the server on every event (mouse click, mouse move (this is really expensive), keyboard, ...) and every primitive you render must be sent to the client. > > If you do a SVG Morphic for Amber, similar to morphic.js, I could also > help. This would mean that a longer term project would be needed to > bring it to the point of real compatibility with Squeak / Pharo / Cuis. This is more or less what I had in mind, probably by drawing morphs onto an HTML canvas. Maybe we can share code between Cuis and Amber for the actual morphs, once I have implemented the drawing/rendering component. It should be sufficient to implement the Morphic3 interface that is used by Cuis and I can render all Cuis morphs from then on, right? Best regards, Matthias -- Matthias Springer * me(a)matthiasspringer.de * +49-1577-3814255 Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) Stahnsdorfer Straße 144c, 14482 Potsdam

April 28, 2013