[Vm-dev] Re: [Pharo-dev] [Pharo-users] [gsoc-mentors] GSoC: call
eliot.miranda at gmail.com
Thu Feb 13 20:22:35 UTC 2014
On Thu, Feb 13, 2014 at 11:47 AM, Ronie Salgado <roniesalg at gmail.com> wrote:
> I am proposing the following as a student:
> Project idea
> Name: Unified Foreign Function Interface
> Skill level: Advanced
> Possible Mentors: Igor Stasenko / Esteban Lorenzano
> Name of the Student: Ronie Salgado
> Because NativeBoost has problems with portability and cannot be used
> anywhere(iOS), one proposal is making a modular unified foreign function
> interface. This UFFI should support multiples backends, a portable function
> calls specification, portable easy to use callbacks support, and portable
> foreign resources management.
> Full Description Document:
This is interesting but I take issue with a couple of things. First of all
"The old Squeak FFI has problems with portability, callbacks and speed."
I disagree that there are problems with callbacks. In fact, IIRC the only
callback facility we have is that which I implemented which is used both by
Alien and FFI and works well enough that the Newspeak system used it to
implement a native GUI on windows where callbacks are used to receive
Windows events. That counts as working in my book. Also, the architecture
I implemented is portable to other ABIs than x86.
But my major objection is to this:
"One interesting idea is to make a backend that uses LLVM compiler
infrastruc- ture, because it is designed for compiling optimized C function
and it already has multiples JIT backends. This small project is not to
make a full Pharo VM JIT based in LLVM, because LLVM is not designed for
that and it would require a lot of patching of LLVM."
IMO that's a very poor choice. LLVM is large, having a footprint of about
a couple of megabytes. The Cog JIT is in contrast about 330k at its
largest (Newspeak, support for two instruction sets, plus primitives, plus
GC interface, etc, etc). If we as a community put effort into extending
this we'll have a smaller footprint, a better JIT, and less dependencies.
There's insignificant opportunity for using LLVM's optimizer when
engineering call-outs and call-backs; they're too simple. So there's
nothing to be gained other than bloat and dependency. And not putting
effort into our own infrastructure is IMO a very bad idea.
Note the synergy with Clément and my work on speculative inlining which
will extend the Cog JIT.
2014-02-13 12:21 GMT-03:00 tesonep at gmail.com <tesonep at gmail.com>:
> Project idea
>> Description: Enhance refactorings with type information
>> Skill level: Advance
>> Possible Mentors: Guillermo Polito / Esteban Lorenzano / Santiago
>> Name of the Student: Pablo Tesone
>> Keywords: tools, refactoring, code completion, type inference.
>> During the development of a program in any programming language, the IDE
>> has a very important role. It will never replace the knowledge of the
>> programmer but it can make his life easier.
>> As Smalltalk doesn't have explicit type information, the IDE can not
>> perform the same mechanisms that are present in IDE like Eclipse or
>> Intellij IDEA. These mechanisms can be very useful.
>> The idea of this project is to add type inference mechanisms to try to
>> provide more information to the refactoring and code completion tools.
>> It is important to say that the idea is not to check types or correct the
>> program, but to allow the programmer to have more information.
>> On Thu, Feb 13, 2014 at 12:06 PM, Usman Bhatti <usman.bhatti at gmail.com>wrote:
>>> [Anne Etien could not post this msg on the mentors list I m forwarding
>>> it on her behalf].
>>> Level: advanced
>>> Possible mentor: Anne Etien
>>> Possible second mentor: Nicolas Anquetil or Yuriy Tymchuk
>>> For in depth source code analysis a support of abstract syntax trees is
>>> required. FAST is an abstract syntax tree extension for FAMIX meta-model
>>> that is used by Moose technology. The goal of this project is to create
>>> Technical Details:
>>> As programming languages are different, their AST representations are
>>> different too. FAST model aims for creation of as generic as possible
>>> core that can be extended for different languages. Also the structure of
>>> a model allows creation of generic algorithms like symbol resolution,
>>> metrics calculation and rule checking that will work for any language.
>>> Prototypes of FAST for Smalltalk and Java are already implemented.
>>> detailed information about FAST is provided in the Moose day
>>> presentation: http://youtu.be/dRr3WHOD3x4
>>> Benefits to the Student:
>>> abstract syntax tree model. He will also learn about PetitParser
>>> framework, and gain knowledge about software modeling and analysis.
>>> Benefits to the Community:
>>> software assessment with Moose. Also this model can be used later in PhD
>>> projects such as automation of source code translation. With this third
>>> model, the community will have raw material to real think and improve
>>> generic algorithms based on AST.
>>> On Tue, Feb 11, 2014 at 10:42 AM, Damien Cassou <damien.cassou at gmail.com
>>> > wrote:
>>>> Hi fellow Pharo hackers,
>>>> ESUG, the European Smalltalk User Group, is applying for this
>>>> year's Google Summer of Code. As you probably know, the Summer
>>>> of Code provides the opportunity to fund students to work during
>>>> the summer on Pharo. Please reply to this
>>>> email (be sure to use "Reply to all") if you have ideas you
>>>> would like to propose.
>>>> Please include a summary of the project and links to web pages
>>>> that can help prospective students to write their application.
>>>> Please also include the following information:
>>>> - if applicable, other dialects that you would be willing to
>>>> mentor this project for
>>>> - the skill level
>>>> - name of the mentor(s), email addresses, and possibly any IRC
>>>> network/channel/nickname where they can be found.
>>>> Thanks for contributing to ESUG's Summer of Code application!
>>>> Damien Cassou
>>>> "Success is the ability to go from one failure to another without
>>>> losing enthusiasm."
>>>> Winston Churchill
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Smalltalk GSoC mentors" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to smalltalk-gsoc-mentors+unsubscribe at googlegroups.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>> You received this message because you are subscribed to the Google
>>> Groups "Smalltalk GSoC mentors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to smalltalk-gsoc-mentors+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>> Pablo Tesone.
>> tesonep at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev