Hi all,
So some time has passed, do you think we could reach an agreement on the
GSoC collaboration?
We have to submit our application by the end of this month but I would like
to set up a tentative schedule beforehand.
Can we work on this together?
Vittorio
Sent from my iPad Mini
On 21/feb/2013
On Mon, Feb 11, 2013 at 9:59 AM, Jonas Maebe wrote:
>
> On 10 Feb 2013, at 22:32, Vittorio Giovara wrote:
> > What about (d) is this project feasible? If not, is it can you split in
> > (parallel) sub projects so that more people can tackle it?
>
> I really don't know whether it is feasible. There
On Mon, February 11, 2013 10:04, Sven Barth wrote:
> On 11.02.2013 09:55, Jonas Maebe wrote:
>> On 11 Feb 2013, at 09:45, Sven Barth wrote:
>>> On 10.02.2013 23:04, Marco van de Voort wrote:
I never spent more than an evening on the test though, since I rather
get
rid of all the ming
Am 11.02.2013 11:47, schrieb Marco van de Voort:
In our previous episode, Jonas Maebe said:
Then we would still have the problem of the outdated tools. Maybe we could
write Pascal based substitutes for them that only need to handle the cases of
compiler/rtl compilation...
The only problem I'm
In our previous episode, Jonas Maebe said:
> > Then we would still have the problem of the outdated tools. Maybe we could
> > write Pascal based substitutes for them that only need to handle the cases
> > of compiler/rtl compilation...
>
> The only problem I'm aware of is cp copying the read-onl
In our previous episode, Jonas Maebe said:
> >> I never spent more than an evening on the test though, since I rather get
> >> rid of all the mingw parts instead (think fpmake here)
> >
> > This might be the best. Let's see that fpmake can handle all that and then
> > get rid of the remaining too
On 11 Feb 2013, at 10:04, Sven Barth wrote:
> On 11.02.2013 09:55, Jonas Maebe wrote:
>>
>>
>> As I've said before: I think the compiler and RTL should remain
>> Makefile-based (whether or not that is in addition to fpmake support for
>> them, doesn't matter to me), to make porting to new platf
On 11.02.2013 09:55, Jonas Maebe wrote:
On 11 Feb 2013, at 09:45, Sven Barth wrote:
On 10.02.2013 23:04, Marco van de Voort wrote:
I never spent more than an evening on the test though, since I rather get
rid of all the mingw parts instead (think fpmake here)
This might be the best. Let's s
On 10 Feb 2013, at 22:32, Vittorio Giovara wrote:
> On Sun, Feb 10, 2013 at 8:39 PM, Jonas Maebe wrote:
>
>> I don't remember ever hearing about this or seeing a bug report about
>> this. It's unlikely that this is related to FPC vs LLVM code or debug info
>> generation though. And adding suppor
On 11 Feb 2013, at 09:45, Sven Barth wrote:
> On 10.02.2013 23:04, Marco van de Voort wrote:
>> I never spent more than an evening on the test though, since I rather get
>> rid of all the mingw parts instead (think fpmake here)
>
> This might be the best. Let's see that fpmake can handle all tha
On 10.02.2013 23:04, Marco van de Voort wrote:
I never spent more than an evening on the test though, since I rather get
rid of all the mingw parts instead (think fpmake here)
This might be the best. Let's see that fpmake can handle all that and
then get rid of the remaining tool dependencies.
On Sun, Feb 10, 2013 at 11:04:59PM +0100, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> > > Sven already replied, but roughly in the coreutils package. (the former
> > > findutils and diffutils iirc)
> >
> > Sorry if this is a daft question, but can't you use the msys
In our previous episode, Henry Vermaak said:
> > Sven already replied, but roughly in the coreutils package. (the former
> > findutils and diffutils iirc)
>
> Sorry if this is a daft question, but can't you use the msys coreutils?
> Or do they have some limitation?
IIRC they were less adapted to
On Sun, Feb 10, 2013 at 8:39 PM, Jonas Maebe wrote:
>
> On 10 Feb 2013, at 20:12, Vittorio Giovara wrote:
>
> The iOS experience could be improved in many ways, for example in
> Xcode you cannot set a breakpoint and when you do so with gdb all you
> get is an assembly viewer
>
>
> I don't remember
On Sun, Feb 10, 2013 at 10:08:29PM +0100, Marco van de Voort wrote:
> In our previous episode, Jonas Maebe said:
> > > Note though that one of the reasons why FPC tools are old is because they
> > > are the most up to date mingw versions. Before they abandonned the tools
> > > we were using, and se
In our previous episode, Jonas Maebe said:
> > Note though that one of the reasons why FPC tools are old is because they
> > are the most up to date mingw versions. Before they abandonned the tools
> > we were using, and set up everything in MSYS.
>
> At least the mingw binutils are still maintain
On 10.02.2013 21:29, Jonas Maebe wrote:
On 10 Feb 2013, at 21:07, Marco van de Voort wrote:
Note though that one of the reasons why FPC tools are old is because they
are the most up to date mingw versions. Before they abandonned the tools
we were using, and set up everything in MSYS.
At leas
On 10 Feb 2013, at 21:07, Marco van de Voort wrote:
> Note though that one of the reasons why FPC tools are old is because they
> are the most up to date mingw versions. Before they abandonned the tools
> we were using, and set up everything in MSYS.
At least the mingw binutils are still maintai
In our previous episode, Vittorio Giovara said:
> Well the existence of external tools is what has allowed technology to
> foster and advance, eg have some common grounds and entry points...
> Your (limited) example is not exactly perfect, the tools that fpc
> bundle on windows are often outdated a
Am 10.02.2013 20:12, schrieb Vittorio Giovara:
>
> Well the existence of external tools is what has allowed technology
> to foster and advance,
In a perfect world, with unlimited cpu resources, yes.
> eg have some common grounds and entry
> points... Your (limited) example is not exactly perfec
On 10 Feb 2013, at 20:12, Vittorio Giovara wrote:
> The iOS experience could be improved in many ways, for example in
> Xcode you cannot set a breakpoint and when you do so with gdb all you
> get is an assembly viewer
I don't remember ever hearing about this or seeing a bug report about this.
I
On 10/feb/2013, at 15:58, Florian Klaempfl wrote:
> Am 10.02.2013 15:23, schrieb Vittorio Giovara:
>> Indeed, a fpc->js code generator would have a rather limited use. A
>> LLVM backend instead could be use on many more levels, and for example
>> could improve (or replace) the compilation process
Am 10.02.2013 15:23, schrieb Vittorio Giovara:
Indeed, a fpc->js code generator would have a rather limited use. A
LLVM backend instead could be use on many more levels, and for example
Not to mention that I estimate that full llvm support with debugging and
extending llvm to support everythin
Am 10.02.2013 15:23, schrieb Vittorio Giovara:
Indeed, a fpc->js code generator would have a rather limited use. A
LLVM backend instead could be use on many more levels, and for example
could improve (or replace) the compilation process on iOS.
Improve in which regard? Experience showed that th
Indeed, a fpc->js code generator would have a rather limited use. A
LLVM backend instead could be use on many more levels, and for example
could improve (or replace) the compilation process on iOS.
Plus I would like that this collaboration would be about something
that could be useful for many proj
Am 10.02.2013 11:09, schrieb Sven Barth:
Having a LLVM backend would not only benefit HedgeWar's JavaScript case,
but also all others that would like to use the LLVM backend for one
purpose or the other. And in my opinion a pure JS backend would be much
harder to implement than a LLVM backend as
On 09.02.2013 14:40, Florian Klämpfl wrote:
Am 09.02.2013 03:13, schrieb Vittorio Giovara:
To do that we are using a tool
named 'emscripten' which takes LLVM bytecode and generates Javascript,
without affecting performance too much. Yes, we had to write a horribly
hacked converter that took the
On Sat, Feb 9, 2013 at 1:13 PM, Vittorio Giovara
wrote:
> I think we could make this work thanks to the Google Summer of Code! This
> program (*if* they announce it) basically introduces students to the world
> of FOSS development by having them work on projects for an open source
> organization d
On Sat, 9 Feb 2013, Florian Klämpfl wrote:
Am 09.02.2013 03:13, schrieb Vittorio Giovara:
To do that we are using a tool
named 'emscripten' which takes LLVM bytecode and generates Javascript,
without affecting performance too much. Yes, we had to write a horribly
hacked converter that took th
Am 09.02.2013 03:13, schrieb Vittorio Giovara:
> To do that we are using a tool
> named 'emscripten' which takes LLVM bytecode and generates Javascript,
> without affecting performance too much. Yes, we had to write a horribly
> hacked converter that took the small subset of Pascal used by Hedgewar
On Sat, 9 Feb 2013, Vittorio Giovara wrote:
Hi all,
I'm one of the developer of Hedgewars, an open source video game all written
with FreePascal. Please see the full site at
http://www.hedgewars.org/
One of the Hedgewars project is to make a WebGL/Javascript version of the game
so that it c
Hi all,
I'm one of the developer of Hedgewars, an open source video game all
written with FreePascal. Please see the full site at
http://www.hedgewars.org/
One of the Hedgewars project is to make a WebGL/Javascript version of the
game so that it can run in a browser. To do that we are using a tool
32 matches
Mail list logo
