GSOC 2015 application
Locked
12
12
 
|
Dear all,
with Uko, we are considering submitting the Pharo project as a mentoring organization for GSOC 2015: http://www.google-melange.com/gsoc/homepage/google/gsoc2015 We will need your help in order to find ideas of projects. Stay tune for more information soon. Thank you. Cheers, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ |
Re: GSOC 2015 application
|
|
Some project ideas
1 Better support for cross-platform co-development Glorp is originally maintained in VisualWorks. We now have a version in Pharo that is forked. It would be nice if we could make sure that changes can be synchronized. The rewriting engine is available on both platforms, and Glorp has a large number of unit tests. If we can describe both migrations with refactorings, we should be able to create builds in ci for both that show when changes break things and otherwise synchronize two-way. This might also be beneficial for Roassal2 and Seaside, that currently use a compatibility layer. Another place where this rewriting can be useful would be in maintaining compatibility between Squeak and Pharo, and in making it easier keeping older code alive. Marcel Taeumel has written a number of interesting applications (UIBuilder, Widgets, XPForums) using a 'signals' style communication. In Pharo it would make sense to have them use Announcements. 2 Use code rewriting to help migrate projects forwards In https://pharo.fogbugz.com/default.asp?13754 cleaning strings API there are 3 method renames. These were included in build 40165. Projects source for pharo can be found on a number of repositories (smaltalkhub, squeaksource, ss3, etc). Upgrade scripts can be generated for these projects to help do these migrations. Stephan |
Re: GSOC 2015 application
|
|
+1
Can I brainstorm a wishlist? I could get wild on it :D > On Feb 11, 2015, at 9:19 AM, Stephan Eggermont <[hidden email]> wrote: > > Some project ideas > > 1 Better support for cross-platform co-development > > Glorp is originally maintained in VisualWorks. We now have a version > in Pharo that is forked. It would be nice if we could make sure that > changes can be synchronized. The rewriting engine is available > on both platforms, and Glorp has a large number of unit tests. > If we can describe both migrations with refactorings, > we should be able to create builds in ci for both that show > when changes break things and otherwise synchronize two-way. > > This might also be beneficial for Roassal2 and Seaside, that > currently use a compatibility layer. > > Another place where this rewriting can be useful would be > in maintaining compatibility between Squeak and Pharo, > and in making it easier keeping older code alive. > > Marcel Taeumel has written a number of interesting applications > (UIBuilder, Widgets, XPForums) using a 'signals' style > communication. In Pharo it would make sense to have them > use Announcements. > > 2 Use code rewriting to help migrate projects forwards > > In https://pharo.fogbugz.com/default.asp?13754 cleaning strings API > there are 3 method renames. These were included in build > 40165. Projects source for pharo can be found on a number of > repositories (smaltalkhub, squeaksource, ss3, etc). > Upgrade scripts can be generated for these projects to help do these > migrations. > > Stephan > > > > |
|
|
In reply to this post by SergeStinckwich
This is a fantastic news. Go go go!
Alexandre > Le 11 févr. 2015 à 06:02, Serge Stinckwich <[hidden email]> a écrit : > > Dear all, > > with Uko, we are considering submitting the Pharo project as a > mentoring organization for GSOC 2015: > http://www.google-melange.com/gsoc/homepage/google/gsoc2015 > > We will need your help in order to find ideas of projects. > > Stay tune for more information soon. > Thank you. > > Cheers, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > |
Re: GSOC 2015 application
|
|
In reply to this post by SergeStinckwich
Sebastian wrote:
>Can I brainstorm a wishlist? I could get wild on it :D Sure, as long as it is projects that you would be willing to mentor, and sized like they could fit. Stephan |
|
|
In reply to this post by SergeStinckwich
Excerpts from Serge Stinckwich's message of 2015-02-11 10:02:21 +0100:
> with Uko, we are considering submitting the Pharo project as a > mentoring organization for GSOC 2015: > > We will need your help in order to find ideas of projects. Is there any effort make a joint application under esug or some other umbrella? there are a few projects on labs.fossasia.org that might fit: Create a file editor and asset manager solution with smalltalk Create a smalltalk application for offline text search emulate a PostgreSQL server in Smalltalk Smalltalk SQL Parser & Evaluator i also discussed with craig the idea of doing something with his context work on pharo. essentially i'd like to use context as a tool to remote manage images. a gsoc project could be to work out how to set up context for that usecase (while helping to make sure context works with pharo) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
|
|
On Wed, Feb 11, 2015 at 3:07 PM, Martin Bähr
<[hidden email]> wrote: > Excerpts from Serge Stinckwich's message of 2015-02-11 10:02:21 +0100: >> with Uko, we are considering submitting the Pharo project as a >> mentoring organization for GSOC 2015: >> >> We will need your help in order to find ideas of projects. > > Is there any effort make a joint application under esug or some other umbrella? We are under the umbrella of the Pharo Consortium. > there are a few projects on labs.fossasia.org that might fit: > > Create a file editor and asset manager solution with smalltalk > Create a smalltalk application for offline text search > emulate a PostgreSQL server in Smalltalk > Smalltalk SQL Parser & Evaluator > > i also discussed with craig the idea of doing something with his context work on pharo. > essentially i'd like to use context as a tool to remote manage images. > a gsoc project could be to work out how to set up context for that usecase > (while helping to make sure context works with pharo) You are from FOSSASIA ? Didn't know you have some interests in Smalltalk ;-) If some of your projects are related to Pharo, we could post also your projects on our lists. We will send the link to list of ideas in a few hours. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ |
|
|
In reply to this post by Stephan Eggermont-3
Excerpts from Stephan Eggermont's message of 2015-02-11 15:05:14 +0100:
> Sebastian wrote: > >Can I brainstorm a wishlist? I could get wild on it :D > > Sure, as long as it is projects that you would be willing to mentor, > and sized like they could fit. well, someone else could be willing to mentor then, so i don't think it hurts to get wild on ideas, as long as accepted ideas come with a mentor. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
|
|
In reply to this post by sebastianconcept@gmail.co
On Wed, Feb 11, 2015 at 8:51 PM, Sebastian Sastre <[hidden email]> wrote: +1 Yes. Go wild! But it should be achievable in 12 weeks, in some cases by students with limited Pharo/Smalltalk experience. Anyway, a wild brainstorm list could carry over to a longer term ex-GSoC list. However there is only 8 or 9 days before the organisation application is due, and the ideas should come with some flesh. (http://en.flossmanuals.net/GSoCMentoring/making-your-ideas-page/) cheers -ben |
|
|
In reply to this post by SergeStinckwich
Excerpts from Serge Stinckwich's message of 2015-02-11 15:13:22 +0100:
> >> with Uko, we are considering submitting the Pharo project as a > >> mentoring organization for GSOC 2015: > >> We will need your help in order to find ideas of projects. > > Is there any effort make a joint application under esug or some other umbrella? > We are under the umbrella of the Pharo Consortium. i am aware of that. i was wondering if there are efforts beyond pharo that would allow squeak projects as well? i believe more projects and mentors would make a gsoc application more successful. > > there are a few projects on labs.fossasia.org that might fit: > > > > Create a file editor and asset manager solution with smalltalk > > Create a smalltalk application for offline text search > > emulate a PostgreSQL server in Smalltalk > > Smalltalk SQL Parser & Evaluator > > > > i also discussed with craig the idea of doing something with his context work on pharo. > > essentially i'd like to use context as a tool to remote manage images. > > a gsoc project could be to work out how to set up context for that usecase > > (while helping to make sure context works with pharo) > > You are from FOSSASIA ? Didn't know you have some interests in Smalltalk ;-) well, my interest in smalltalk (and pharo) is personal. FOSSASIA is promoting Free Software in asia and as such is supporting projects and developers in asia. since i got involved with FOSSASIA it just made sense to list all my projects there. > If some of your projects are related to Pharo, we could post also your > projects on our lists. the 4 projects listed above are based on pharo. the two SQL projects are not mine btw, but are the result of me inviting mentors on the pharo and squeak lists last month to VALS Semester of Code. VALS Semester of Code btw, is something pharo (and smalltalk) could participate in too in the next round. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
Re: GSOC 2015 application
|
|
In reply to this post by Ben Coman
That’s a great constraint! I’m starting to take notes to share |
|
|
In reply to this post by SergeStinckwich
On Wed, Feb 11, 2015 at 10:13 PM, Serge Stinckwich <[hidden email]> wrote: On Wed, Feb 11, 2015 at 3:07 PM, Martin Bähr Now google say... "Umbrella organizations get more slots. If an organization is acting as an umbrella for other projects, chances are we'll allocate more students to you simply because there's a great deal of different types of work to be done, and we're hoping our students will end up with something that appeals to them among this wide offering." [1] The Pharo Consortium might conceivably be considered an umbrella organisation, if a reasonable amount of selected projects relate to applications built on top of Pharo and not "just" improvements in the Pharo release. e.g. SciSmalltalk, PhaROS, Phratch. I guess that is a balance to be determined later. Google also provide some tips [2] for project topics : * Low-hanging fruit: These projects require minimal familiarity with the codebase and basic technical knowledge. They are relatively short, with clear goals. * Risky/Exploratory: These projects push the scope boundaries of your development effort. They might require expertise in an area not covered by your current development team. They might take advantage of a new technology. There is a reasonable chance that the project might be less successful, but the potential rewards make it worth the attempt. * Fun/Peripheral: These projects might not be related to the current core development focus, but create new innovations and new perspective for your project. * Core development: These projects derive from the ongoing work from the core of your development team. The list of features and bugs is never-ending, and help is always welcome. * Infrastructure/Automation: These projects are the code that your organization uses to get its development work done; for example, projects that improve the automation of releases, regression tests and automated builds. This is a category in which a GSoC student can be really helpful, doing work that the development team has been putting off while they focus on core development. * Don't Be That Guy!!! Don't propose projects that neither you nor anyone else wants to mentor. btw, Are all of these topics [http://topics.pharo.org/] still current (maybe some are too big for summer)? btw2, Where is our ideas page going to be hosted? [1] http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/studentallocations cheers -ben
|
Re: GSOC 2015 application
|
|
In reply to this post by Martin Bähr
Okay here comes some notes I’ve compiled:
VOSS for Pharo Implications: a completely object oriented database industry proven would have a legacy and a open sourced release empowering Pharo users and startups to stay object oriented even when persisting data. VOSS has dual license commercial and GPLv3, John, VOSS author already offered himself to mentor porters. SQLServer client for Pharo Implications: some applications that have this dependency needs to extend and modernize features are challenged by this dependency that Pharo cannot use in a production ready state. SQL Alchemy for Pharo Implications: Big-data is a growing market that is easy to mine with a tool like Python’s SQL Alchemy. A Pharo version of such powerful tool would open this market opportunity for people wanting to offer Pharo-based solutions in this segment. Smalltalk’s syntax and tooling superiority could provide a significant push forward in this technology competitiveness because they might empower Pharo users to deliver solutions faster. Remote Environments for Pharo Implications: being able to inspect, browse and debug reliably a server Pharo image from a client Pharo image would spark countless possibilities. Some of them: server maintenance; hot debug on GUI-less servers in production; live develop or debug remotely mobile devices that doesn’t have a server. Hot changes in Pharo powered drones and robots. Pharo on mobile Implications: Is not that mobile is a growing market, is more like mobile is going supernova: http://a16z.com/2014/10/28/mobile-is-eating-the-world/ The power of Pharo and its libraries on mobile devices is currently perhaps one of its biggest opportunities. Deep learning for Pharo Implications: Robotics, drones and the internet of things will gather data from sensors that will need interpretation and modelling. All sorts of AI will use deep learning techniques and Pharo would be a great orchestrator of that modelling. Pharo Hadoop client Implications: Apache Hadoop can scale from single server to thousands of servers. The explosion of sensors, drones and mobile devices and printed devices with sensors are going to generate incredible amounts of data to process and model. Hadoop is a good fit for that and Pharo can empower faster modelling and orchestration of what to do with all that information stored in this widely adopted Hadoop technology. Cross platform Native Widgets for Pharo Implications: The web is fantastic but at the same time there is a big pressure to create great native applications due to the improved User Experience that the native widgets can provide. Making Pharo to create them via things like wxWidgets (https://www.wxwidgets.org/about/screenshots/) would instantly create opportunities to develop fast applications with a great UX. Protips site for Pharo Implications: I might spark the beginning of a mentoring ecosystem. StackOverflow is great but at the same time for a niche like Smalltalk it might not be enough to show the problem-solving potential of the platform. A site dedicated to share pro tips centered on Pharo would slowly a steady show the platform’s value. The site has to be social friendly. Each tip should have an author that can set there StackOverflow, LinkedIn, facebook, twitter or any social profile she wants. Requires nice branding and UX/UI design. Optional variation of the same idea: make it for any Smalltalk dialect instead of only Pharo. REPL IDE for Pharo Implications: Smalltalkers are used to very powerful IDEs. What if we have to put Pharo in a really underpowered or monitorless device? Having a powerful REPL IDE that can evaluate expressions, inspect and debug, would empower users to still do things in mini-devices during the incoming tide wave of internet-of-things. A GUI builder for Pharo Implications: If whatever you are doing you cannot make it visual easily, people cannot perceive it easily. Due to evolutionary reasons, our brain has unfair bias towards visual processing. Lets make something that allows Pharo to create visual things easier. Something like PARTS or Dolphin Smalltalk GUI builder would be huge. best! o/
|
Re: GSOC 2015 application
|
|
2015-02-11 15:37 GMT-03:00 Sebastian Sastre <[hidden email]>:
> Okay here comes some notes I’ve compiled: > SQL Alchemy for Pharo > Implications: Big-data is a growing market that is easy to mine with a tool > like Python’s SQL Alchemy. A Pharo version of such powerful tool would open > this market opportunity for people wanting to offer Pharo-based solutions in > this segment. Smalltalk’s syntax and tooling superiority could provide a > significant push forward in this technology competitiveness because they > might empower Pharo users to deliver solutions faster. > http://www.sqlalchemy.org/ +1 GLORP is the closest we have to this. Also, something like jOOQ.org would be valuable in the (big)data front, where ORM falls short or is impractical due to the volume of data processed. > Remote Environments for Pharo > Implications: being able to inspect, browse and debug reliably a server > Pharo image from a client Pharo image would spark countless possibilities. > Some of them: server maintenance; hot debug on GUI-less servers in > production; live develop or debug remotely mobile devices that doesn’t have > a server. Hot changes in Pharo powered drones and robots. I would say "instrumentation", not only being able to plug remotely (and securely) to a remote image, but also being able to poll it for statistics, as you can do with JVM. Syntax extensions (pluggable?): I know we have many alternatives, which I used and are more than acceptable , but I'd like to write JSON as close as possible to its original syntax. |
Re: GSOC 2015 application
|
|
+1 except I would not say that "I want to write JSON as close as possible”. It’s either zero friction or it’s already good enough. In Amber, for example, you already can write a JSON object “as close as possible” to the original syntax and is o-kay but is not really great because you’re still being taxed when compared to JavaScript and that taxing might never payoff, that’s why I say that we are either currently okay or we move towards zero-JSON-friction. Amber: #{ ‘key1’-> value1. ‘key2 -> value2 } <— kind of okay, survivable JavaScript: {key1: value1, key2: value2} <— awesome, no friction to party with the rest of the world, it rocks! |
|
|
In reply to this post by sebastianconcept@gmail.co
Excerpts from Sebastian Sastre's message of 2015-02-11 19:37:07 +0100:
> Remote Environments for Pharo > Implications: being able to inspect, browse and debug reliably a server Pharo image from a client Pharo image would spark countless possibilities. Some of them: server maintenance; hot debug on GUI-less servers in production; live develop or debug remotely mobile devices that doesn’t have a server. Hot changes in Pharo powered drones and robots. this describes exactly what i believe can be done with craig's context. i am interested to support this as a co-mentor maybe together with craig or someone else more experienced than me. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
Re: GSOC 2015 application
|
|
In reply to this post by SergeStinckwich
Ben wrote:
>Now google say... "Umbrella organizations get more slots. > If an organization is acting as an umbrella for other projects, chances are >we'll allocate more students to you simply because there's a great deal of >different types of work to be done, and we're hoping our students will end >up with something that appeals to them among this wide offering." [1] >The Pharo Consortium might conceivably be considered an umbrella organization, >if a reasonable amount of selected projects relate to applications built on top of Pharo >and not "just" improvements in the Pharo release. e.g. SciSmalltalk, PhaROS, Phratch. > I guess that is a balance to be determined later. New organizations get a low number of slots. Marginalizing other smalltalks is not in our best interest. I think it would be sad not to run as Esug this year. Running as Esug shows we can overcome last years trouble, and start healing the pain. I totally understand Stef doesn't want to be involved, considering the amount of accusations and abuse it has brought, not just last year. Stephan |
|
|
In reply to this post by Martin Bähr
Context would be nice to see how it might work with Pharo. On Thu, Feb 12, 2015 at 3:51 AM, Martin Bähr <[hidden email]> wrote: Excerpts from Sebastian Sastre's message of 2015-02-11 19:37:07 +0100: |
Re: GSOC 2015 application
|
|
In reply to this post by sebastianconcept@gmail.co
> On 11 Feb 2015, at 20:33, Sebastian Sastre <[hidden email]> wrote: > > >> On Feb 11, 2015, at 5:08 PM, Esteban A. Maringolo <[hidden email]> wrote: >> >> Syntax extensions (pluggable?): >> I know we have many alternatives, which I used and are more than >> acceptable , but I'd like to write JSON as close as possible to its >> original syntax. > > +1 except I would not say that "I want to write JSON as close as possible”. > > It’s either zero friction or it’s already good enough. > > In Amber, for example, you already can write a JSON object “as close as possible” to the original syntax and is o-kay but is not really great because you’re still being taxed when compared to JavaScript and that taxing might never payoff, that’s why I say that we are either currently okay or we move towards zero-JSON-friction. > > Amber: > #{ ‘key1’-> value1. ‘key2 -> value2 } <— kind of okay, survivable And we have { #key1->value1. #key2->value2 } asDictionary which is acceptable to me (you can auto complete asDi-). You want interpolation anyway, this construct gives you that. > JavaScript: > {key1: value1, key2: value2} <— awesome, no friction to party with the rest of the world, it rocks! Seriously, JSON is JavaScript's native format, of course it's easy to use, duh. Every language can use its own literal format with 'no friction'. And the fact that the rest of the world is compatible with JSON is not their doing, but ours ! Sven BTW: technically, JSON is not completely identical to JavaScript and not using a proper parser is a security risk. |
|
|
In reply to this post by sebastianconcept@gmail.co
Sebastian
we maintain one single list for pharo topics (related or not to GSOC) I will not edit your item but you can do a pull request :) https://github.com/pharo-project/pharo-project-proposals Stef Le 11/2/15 19:37, Sebastian Sastre a
écrit :
Okay here comes some notes I’ve compiled: |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |