GSOC - Student Rondup

GSOC - Student Rondup

[Philip Herron]

Hey all,

I was talking on IRC the other day with others and we thought this
would be a nice idea, to ask all GSOC students how were all getting on
working within GCC. As i am sure you have noticed GCC is a pretty big
piece of code and it can be hard to get to grips with it all. I am
kind of lucky because i was on GSOC last year and spent most of the
summer if not all just getting comfortable with it.

So i thought we could use this as a thread to introduce us a students
to each other I'll go first!

My name is Philip Herron I'm from Ireland and i got inspired by Paul
Biggars work into PHC http://www.phpcompiler.org/ to implement a
python front-end to gcc. Its hard but just something i find
interesting more than anything. I'm am getting on quite well with my
project, spent last week after the GCC meet-up in London cleaning up
my IL and now i am implementing my own pass system as i have to
iterate several passes over my IL (for various reasons) before i
generate GENERIC.

As i was on GCC last year i thought i would share things i found to be
helpful when you encounter a problem:

1 - Work at it for max 1 day on your own but definitely try to join
our irc on irc.oftc.net #gcc and ask. If you still find no help send a
mail to gcc-help

2 - gcc -save-temps can be helpful now and again when working with
alot of macros

3 - ack-grep is very helpful: http://betterthangrep.com/ makes
searching though code much easier than learning to use grep properly
:P

4 - Don't be afraid to ask questions as often as possible on irc and
to your mentor I've bugged my mentor Ian with alot of really stupid
small things all the time :) but they don't bite.

And just finally i thought i would ask what aspects have you found
within gcc hard to get to grips with if at all, it could be
interesting to see if there is any correlation between areas.

Personally i found getting to grips with Makefiles properly was hard i
used to rely on automake for everything before. And learning to figure
out how to use the generic tree api was confusing but in the end its
very simple. We've found not all students are on irc its a really
great platform to ask questions very informally its worth getting used
to you can use web clients like mibbet irc or firefox extensions, i
use irssi but those clients are much more friendly.

Hope everyone's project is going well and your comfortable or getting
more comfortable with what your doing! :)

Happy Coding!

--Phil

PS: what do you think of the idea if we have a thread like this every
few weeks or sooner (maybe on irc)? Just to see if we can help each
other etc?

Re: GSOC - Student Roundup

[Dimitrios Apostolou]

Hi Philip,

thanks for writing your experiences, I found it very useful. I certainly 
like the idea of having such a thread every once in a while, just to keep 
everyone updated about our projects. I'm also curious to learn about the 
experiences of other students that are writing code for GCC for the first 
time. Here goes mine:

I am Dimitrios Apostolou (jimis on IRC) and I live in Heraklion-Crete, 
Greece. My project concerns making GCC leaner and faster.

Reading GCC codebase has been a hard exercise for me. In fact it's the 
only project I know of that becomes more and more difficult as time 
passes... I will try to describe some of the major hurdles I've faced so 
far.

I started by profiling the execution of cc1, the C compiler. In general I 
could find no big hot-spot, it was in good shape, but I could see 3-4 
areas that could make some difference if improved (for example hash 
tables, assembly output, C parser, bitmaps). But diving in and trying to 
change things is a completely different story.

Minor tweaks are easy to make, but usually have minor impact. If you want 
to see bigger speedup you have to break the interface of functions being 
used in hundreds of places, and that is hard. Sometimes it was impossible 
for me, I was getting crashes in places far away of code I had changed, 
so I ended up reverting to original versions.

Spending some time with a specific part of GCC's codebase gives you 
the ability to dive deeper and work more efficiently. But that is the 
point when I usually have achieved something and I must move on to some 
other part. And the whole GCC codebase is so huge, that understanding one 
part means nothing when you move to another. My advice here is that if 
your project permits that, touch as little code as possible in GCC, and 
be really proficient with that. Treat the rest as a black box, or you'll 
spend too much time trying to understand everything.

Another hurdle is the usage of too many macros. Even if they exist for 
making the code easier to read, I can't see how they achieve this in a few 
extreme cases. I have had gdb expand 20 full-lines macros on a wide 
screen. Plus the profiler can't actually profile code in macros, so the 
impact of some data structures in performance is hidden that way. My 
moments of greatest awe/horror so far have been while changing things in 
vectors (vec.[ch]), which is actually a fully templated structure 
implemented in CPP!

Finally I believe that some parts of the compiler should have a big 
NO-ENTRY flag for beginners. In my case, after having improved little 
stuff in assembly output and hash tables, I decided -driven by profiler's 
output- to try improving things in dataflow analysis part of GCC. It's 
true that there is much to be improved there but it requires a good 
understanding of this complex part. Three weeks later I am still striving 
to change simple stuff and jump to the next part, but regressions I've 
introduced don't allow me to do so yet. The level of my understanding of 
this part is still basic, I've now only scratched the surface of Dataflow 
Analysis. If I had this knowledge in the beginning I'd probably leave that 
part for the end of the summer, if at all. My plans included visiting IRA 
(register allocator) next, but I think I'll skip directly to the c-parser 
which I understand more.


These are my major difficulties with GCC, I'm curious to learn about other 
students experience so far. Of course don't get the wrong impression, my 
general feeling on GCC development is positive, the community is helpful 
and really friendly inspite of my daily spamming on the IRC. :-p

In the end I feel the fact that GCC is a multi-headed monster makes it 
even more exciting to try and tame it.


Good luck in everyone's project,
Dimitris

Re: GSOC - Student Roundup

[Daniel Carrera]

Hello Philip + Dimitrios

Thanks for your posts. I am another GSOC student. I am working on the 
Fortran front-end of GCC (gfortran). Like most GFortran developers, my 
background is more in the natural sciences (astrophysics in my case) 
rather than computer science.

My project is to help add coarray support for GFortran. Coarrays are a 
cool new feature in the Fortran 2008 standard that give Fortran native 
support for parallel programming (as opposed to using MPI or OpenMP). 
Scientific simulations (especially in parallel clusters) are the bread 
and butter of Fortran.


Learning how GCC works has been difficult but rewarding. My work is 
split between the libgfortran library, which is straight forward enough, 
and the Fortran front-end, which at first looked like gobbledygook. 
Today I can actually understand most front-end functions when I read 
them, but it took a long time to get to this point. GCC has a scary 
learning curve.

The libgfortran library is more forgiving for the beginner. We are using 
MPI as the backend to implement coarrays and I have very much enjoyed 
learning MPI.

So far my contributions have been modest, but now that I've crossed much 
of the learning curve, I feel optimistic. To an extent the progress has 
to be a bit slow because we are looking at the new Fortran standard and 
thinking about the best way to add features.

Cheers,
Daniel.
-- 
I'm not overweight, I'm undertall.

Re: GSOC - Student Roundup

[Pierre Vittet]

Hi,

I am Pierre Vittet, one of the GSOC students. I am writing a plugin 
which is a simple statical analysis tools. The idea is to write some 
tests (like testing that a function call is tested to return somethings 
(not) null, or testing that a call to a given function is followed by a 
call to another function.), that can be parametrized by the user (to be 
run on the functions he wants to check). I feel it can be a useful tool 
(however I am ready to fight with false positives).

I am using MELT (http://gcc-melt.org/) for this, I know that is quite a 
hot topic in the community and it is not much considered. MELT aims at 
abstracting GCC internal with a higher level language. I think that it 
can be a good way to enter into GCC, because it permits to parse quite 
quikly the GCC internal, gimple especially. The major feature of MELT is 
his pattern matching on tree ability.

Part of my work is to improve MELT (as I need some features which were 
not implemented), such as having handling pragma in MELT plugins or 
gluing some GCC dominance functions (from gcc/dominance.c)

However, like the others students which answered to this thread, the 
main difficulty is understanding and eventually modifying GCC itself. 
That is quite time consumming, as you can have, even to write a simple 
patch, to know well several parts of GCC (I am often grepping for a 
given struct or function). I also thing that each pass could be more 
detailled. Sometimes, it is hard to find a pass in the code from it's 
dump file name.

I had to write a patch for the trunk, to add a data field to pragma 
handlers, this was quite a simple patch, however, I had to make it 
compatible with the fact that one of the function I was modifying was 
used many times in differents parts of GCC.

Currently, I need to understand how works C++ mangling if I want my 
plugin to work with C++ (I am going to write a new mail about this), as 
I need to convert the string given by the user into the function(s) that 
it represents.

About the state of my plugin, I have written the core of the module.
It can use user's input from different entries (I have already written 
an entrie using the pragma, and an entrie using direct argument (given 
when invoking GCC), searchs if it matchs a corresponding test and 
generate a new GCC Pass from this. This new pass is inserted after ssa 
pass, as I got a representation which suits to me (I can find the 
information my tests need). But the choice of inserting here is quite 
empirical (would have you choice another pass?). The plugin is mainly 
tested for C code, even if I would like to have C++ working too.

I have started implementing tests, for the moment I use a test which 
checks that there is a test checking for a NULL pointer (if resCall == 
NULL for exemple) after a given function call, and return a warning if 
there is no test.

I have also started implementing a test checking that a given is 
immediatly followed by another given function. I would also try to add a 
test checking that a call to a given function is followed by a call to 
another function in the same function bodies, I know that I will have to 
handle the basic block hierarchie, that why I glued dominance functions 
into MELT.

I think, I am in time, however, this is sometimes hard to evaluate: for 
exemple, I don't know really how much time, I will take to manage C++ 
function in my plugin.

I feel sad, not being able to use IRC from my web access (in my 
school)... and so only communicating by mail with the GCC community. 
However, I thanks the community for their answer and support. The point 
to improve, I guess, is having more people reviewing patchs (even if, I 
understand that it requires a lot of time and skills).

Thanks

Pierre Vittet


On 05/07/2011 21:08, Daniel Carrera wrote:
> Hello Philip + Dimitrios
>
> Thanks for your posts. I am another GSOC student. I am working on the
> Fortran front-end of GCC (gfortran). Like most GFortran developers, my
> background is more in the natural sciences (astrophysics in my case)
> rather than computer science.
>
> My project is to help add coarray support for GFortran. Coarrays are a
> cool new feature in the Fortran 2008 standard that give Fortran native
> support for parallel programming (as opposed to using MPI or OpenMP).
> Scientific simulations (especially in parallel clusters) are the bread
> and butter of Fortran.
>
>
> Learning how GCC works has been difficult but rewarding. My work is
> split between the libgfortran library, which is straight forward enough,
> and the Fortran front-end, which at first looked like gobbledygook.
> Today I can actually understand most front-end functions when I read
> them, but it took a long time to get to this point. GCC has a scary
> learning curve.
>
> The libgfortran library is more forgiving for the beginner. We are using
> MPI as the backend to implement coarrays and I have very much enjoyed
> learning MPI.
>
> So far my contributions have been modest, but now that I've crossed much
> of the learning curve, I feel optimistic. To an extent the progress has
> to be a bit slow because we are looking at the new Fortran standard and
> thinking about the best way to add features.
>
> Cheers,
> Daniel.

Re: GSOC - Student Roundup

[Dimitrios Apostolou]

Hi Pierre,

regarding your IRC problems, try a web-based client, for example 
http://chat.mibbit.com


Dimitris

Re: GSOC - Student Roundup

[Ismail]

On 06.07.2011 11:39, Pierre Vittet wrote:
> Hi,
>
> I am Pierre Vittet, one of the GSOC students. I am writing a plugin 
> which is a simple statical analysis tools. The idea is to write some 
> tests (like testing that a function call is tested to return 
> somethings (not) null, or testing that a call to a given function is 
> followed by a call to another function.), that can be parametrized by 
> the user (to be run on the functions he wants to check). I feel it can 
> be a useful tool (however I am ready to fight with false positives).
>
> I am using MELT (http://gcc-melt.org/) for this, I know that is quite 
> a hot topic in the community and it is not much considered. MELT aims 
> at abstracting GCC internal with a higher level language. I think that 
> it can be a good way to enter into GCC, because it permits to parse 
> quite quikly the GCC internal, gimple especially. The major feature of 
> MELT is his pattern matching on tree ability.
>
> Part of my work is to improve MELT (as I need some features which were 
> not implemented), such as having handling pragma in MELT plugins or 
> gluing some GCC dominance functions (from gcc/dominance.c)
>
> However, like the others students which answered to this thread, the 
> main difficulty is understanding and eventually modifying GCC itself. 
> That is quite time consumming, as you can have, even to write a simple 
> patch, to know well several parts of GCC (I am often grepping for a 
> given struct or function). I also thing that each pass could be more 
> detailled. Sometimes, it is hard to find a pass in the code from it's 
> dump file name.
>
> I had to write a patch for the trunk, to add a data field to pragma 
> handlers, this was quite a simple patch, however, I had to make it 
> compatible with the fact that one of the function I was modifying was 
> used many times in differents parts of GCC.
>
> Currently, I need to understand how works C++ mangling if I want my 
> plugin to work with C++ (I am going to write a new mail about this), 
> as I need to convert the string given by the user into the function(s) 
> that it represents.
>
> About the state of my plugin, I have written the core of the module.
> It can use user's input from different entries (I have already written 
> an entrie using the pragma, and an entrie using direct argument (given 
> when invoking GCC), searchs if it matchs a corresponding test and 
> generate a new GCC Pass from this. This new pass is inserted after ssa 
> pass, as I got a representation which suits to me (I can find the 
> information my tests need). But the choice of inserting here is quite 
> empirical (would have you choice another pass?). The plugin is mainly 
> tested for C code, even if I would like to have C++ working too.
>
> I have started implementing tests, for the moment I use a test which 
> checks that there is a test checking for a NULL pointer (if resCall == 
> NULL for exemple) after a given function call, and return a warning if 
> there is no test.
>
> I have also started implementing a test checking that a given is 
> immediatly followed by another given function. I would also try to add 
> a test checking that a call to a given function is followed by a call 
> to another function in the same function bodies, I know that I will 
> have to handle the basic block hierarchie, that why I glued dominance 
> functions into MELT.
>
> I think, I am in time, however, this is sometimes hard to evaluate: 
> for exemple, I don't know really how much time, I will take to manage 
> C++ function in my plugin.
>
> I feel sad, not being able to use IRC from my web access (in my 
> school)... and so only communicating by mail with the GCC community. 
> However, I thanks the community for their answer and support. The 
> point to improve, I guess, is having more people reviewing patchs 
> (even if, I understand that it requires a lot of time and skills).
>
> Thanks
>
> Pierre Vittet
>
>
> On 05/07/2011 21:08, Daniel Carrera wrote:
>> Hello Philip + Dimitrios
>>
>> Thanks for your posts. I am another GSOC student. I am working on the
>> Fortran front-end of GCC (gfortran). Like most GFortran developers, my
>> background is more in the natural sciences (astrophysics in my case)
>> rather than computer science.
>>
>> My project is to help add coarray support for GFortran. Coarrays are a
>> cool new feature in the Fortran 2008 standard that give Fortran native
>> support for parallel programming (as opposed to using MPI or OpenMP).
>> Scientific simulations (especially in parallel clusters) are the bread
>> and butter of Fortran.
>>
>>
>> Learning how GCC works has been difficult but rewarding. My work is
>> split between the libgfortran library, which is straight forward enough,
>> and the Fortran front-end, which at first looked like gobbledygook.
>> Today I can actually understand most front-end functions when I read
>> them, but it took a long time to get to this point. GCC has a scary
>> learning curve.
>>
>> The libgfortran library is more forgiving for the beginner. We are using
>> MPI as the backend to implement coarrays and I have very much enjoyed
>> learning MPI.
>>
>> So far my contributions have been modest, but now that I've crossed much
>> of the learning curve, I feel optimistic. To an extent the progress has
>> to be a bit slow because we are looking at the new Fortran standard and
>> thinking about the best way to add features.
>>
>> Cheers,
>> Daniel.

Hi all,

I am one of GSOC students. We have started the project with doing some 
experiments for checking the compatibility of OpenMP threads with 
[trans-mem] branch of GCC.

We made a presentation 
(http://www.gsd.inesc-id.pt/~mcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf 
<http://www.gsd.inesc-id.pt/%7Emcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf>) 
at EuroTM meeting at Paris 
(http://www.eurotm.org/1st-plenary-meeting-in-paris/program). It was 
very useful for project's future perspective.

However, I got accepted as a PhD and I have lots of urgent 
organizational and administrative  issues and pre-requisite exams for 
PhD program to completed before the mid of August so  I have no chance 
to go on with project until mid of August.

But I am optimistic for the project and contribution to  GCC even if I 
do not have an overlapping time-schedule with GSOC.

Best Regards

Ismail KURU

Re: GSOC - Student Roundup

[Gerald Pfeifer]

Pierre,

On Wed, 6 Jul 2011, Pierre Vittet wrote:
> I feel sad, not being able to use IRC from my web access (in my 
> school)... and so only communicating by mail with the GCC community. 

are you aware of http://www.mibbit.com/ and similar clients, that just
use plain http, or are you saying that, too, is being blocked by your
school?  (I just tried the above, and it works fine for me.)
 
Gerald

Re: GSOC - Student Roundup

[Paolo Bonzini]

On 07/05/2011 06:58 PM, Dimitrios Apostolou wrote:
> The level of my understanding of this part is still basic, I've now only
> scratched the surface of Dataflow Analysis.

Well you're not looking at df proper, which is mostly a textbook 
implementation with some quirks; you're looking at RTL operand scanning, 
which should indeed have a big "here be dragons" sign on it.  But you're 
doing fine. :)

Paolo

Re: GSOC - Student Roundup

[Philip Herron]

On 10 July 2011 22:42, ismail kuru <aptaliso@gmail.com> wrote:
> Hi all,
> I am one of GSOC students. We have started the project with doing some
> experiments for checking the compatibility of
> OpenMP threads with [trans-mem] branch of GCC.
>  We made a presentation
> (http://www.gsd.inesc-id.pt/~mcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf)
> at EuroTM meeting at Paris
> (http://www.eurotm.org/1st-plenary-meeting-in-paris/program). It was very
> useful for project's future perspective.
> However, I got accepted as a PhD and I have lots of urgent organizational
> and administrative  issues to complete before the mid of August so  I have
> no chance to go on with project until mid of August.
> But I am optimistic for the project even if I do not have a overlapping
> time-schedule with GSOC.
>

Yeah my last years Gsoc time management i found hard mostly because i
had a really bad sleeping pattern and i would grind out and work way
too much for like 2 weeks then spend 2 days sleeping and then same
thing again.

It was kind of stupid but this year i treat it like 9-5 but i can seem
myself working on a lot more once i get to parts when its mostly a
grind at the moment i am filling in and fixing lots of awkward pieces
which takes time.

But Gsoc is very flexible so i wouldn't worry about having to do
things in RL if you feel your are on track in your own time frame then
your ok.

--Phil

Re: GSOC - Student Roundup

[Franck Z]

Hello!

Technically, I'm not a GSOC Student, but I've also started delving recently 
into the depths of gcc's source code.

Would you mind I if joined your IRC Chat in case I'm stuck somewhere in my 
understanding of the source ?

There are indeed occasional questions that I don't dare to ask here, given 
that I'm not as an accomplished programmer as any one of you is.

I hope you'll indulge me if I here introduce myself to you, although I 
surely wouldn't meet GSOC's application criteria.

My name is Franck (Z is not my last name initial, I keep using a pseudo 
because I've been using it on other social websites, where it is advocated 
not to give any personal information, mainly Yahoo Answers). For now, it 
doesn't hurt, as I'm far from proposing any patch! I'll meet FSF 
requirements whenever I'm asked to.

I'm French. I graduated in the 90's and have been keeping occasional links 
with computer sciences, following my curiosity, but never really tackled on 
an industrial programming project on my own.

The fact is that, a few months ago, I eventually dared to download gcc's 
source and subscribe to the gcc list, again out of curiosity, after reading 
a post from Walt Brian about C/C++ compilers being much slower than 
compilers for other programming languages.

I skimmed up was I'm leaning toward in a former message here: 
http://gcc.gnu.org/ml/gcc/2011-06/msg00141.html

In fact, I may opt for another way of doing, using event programming 
techniques between "make" and "gcc". Namely, instead of having "make" call 
"gcc" through several jobs, I consider having "gcc" being launched only once 
by "make" and then ask "make" about the tasks he should do, up to the 
numbers of jobs allowed when "make -j..." was invoked.

It seems to me that this would allow, besides the original aspect of how 
disk is accessed throughout a compilation session, to include a 
task-oriented parallelism in compilation tasks, with Intel's TBB library, 
based on the "natural" organisation of a compilation around *.c (or such) 
files.

Actually, my main issue with respect to understanding gcc's source, is that 
my knowledge of C isn't precise enough to meet gcc's writing standards, for 
instance what I suspect to be workarounds to silent out some spurious 
warning messages in the compilation.

I keep to the front-end part, so it's easier for now. Still, I'm *slightly* 
overwhelmed by the numerous tools and libraries I need to get precisely 
acquainted with, before I'm able to hack in (git, autogen, ...). Don't mock 
me, but, as a matter of fact, gcc's source being gigantic is part of my 
pleasure! I've enjoyed browsing similarly wide and intricated sources in the 
past years (for instance OCaml or TBB) and I relished learning from these.

I hope I don't put too much hope in what I can do and that one day, I'll 
help a little teeny bit. :-)

Franck Z 

Re: GSOC - Student Roundup

[Philip Herron]

On 17 July 2011 13:21, Franck Z <franck.z.gcc@orange.fr> wrote:
> Hello!
>
> Technically, I'm not a GSOC Student, but I've also started delving recently
> into the depths of gcc's source code.
>
> Would you mind I if joined your IRC Chat in case I'm stuck somewhere in my
> understanding of the source ?
Yeah of course its very friendly. The gcc-help or this list is also
great for help where maybe someone wasn't able to help in the irc
channel.

>
> There are indeed occasional questions that I don't dare to ask here, given
> that I'm not as an accomplished programmer as any one of you is.
>
> I hope you'll indulge me if I here introduce myself to you, although I
> surely wouldn't meet GSOC's application criteria.
Dont worry.

>
> My name is Franck (Z is not my last name initial, I keep using a pseudo
> because I've been using it on other social websites, where it is advocated
> not to give any personal information, mainly Yahoo Answers). For now, it
> doesn't hurt, as I'm far from proposing any patch! I'll meet FSF
> requirements whenever I'm asked to.
>
> I'm French. I graduated in the 90's and have been keeping occasional links
> with computer sciences, following my curiosity, but never really tackled on
> an industrial programming project on my own.
>
> The fact is that, a few months ago, I eventually dared to download gcc's
> source and subscribe to the gcc list, again out of curiosity, after reading
> a post from Walt Brian about C/C++ compilers being much slower than
> compilers for other programming languages.
>
> I skimmed up was I'm leaning toward in a former message here:
> http://gcc.gnu.org/ml/gcc/2011-06/msg00141.html
>
> In fact, I may opt for another way of doing, using event programming
> techniques between "make" and "gcc". Namely, instead of having "make" call
> "gcc" through several jobs, I consider having "gcc" being launched only once
> by "make" and then ask "make" about the tasks he should do, up to the
> numbers of jobs allowed when "make -j..." was invoked.

Interesting idea i have a feeling i read something about this recently
I'm not really sure how it could work in how you could query make to
get the next source, but at the same time sounds like it could be a
niche piece of tech although you could maybe just have it as a switch
in the front-end. It could possibly be handled at compiler driver
level.

> It seems to me that this would allow, besides the original aspect of how
> disk is accessed throughout a compilation session, to include a
> task-oriented parallelism in compilation tasks, with Intel's TBB library,
> based on the "natural" organisation of a compilation around *.c (or such)
> files.
>
> Actually, my main issue with respect to understanding gcc's source, is that
> my knowledge of C isn't precise enough to meet gcc's writing standards, for
> instance what I suspect to be workarounds to silent out some spurious
> warning messages in the compilation.
>
> I keep to the front-end part, so it's easier for now. Still, I'm *slightly*
> overwhelmed by the numerous tools and libraries I need to get precisely
> acquainted with, before I'm able to hack in (git, autogen, ...). Don't mock
> me, but, as a matter of fact, gcc's source being gigantic is part of my
> pleasure! I've enjoyed browsing similarly wide and intricated sources in the
> past years (for instance OCaml or TBB) and I relished learning from these.
>
> I hope I don't put too much hope in what I can do and that one day, I'll
> help a little teeny bit. :-)

Cool, happy hacking

--Phil

Re: GSOC - Student Roundup

[Franck Z]

> Cool, happy hacking
>
> --Phil

Thank you very much!
Apparently, it's best to communicate&contribute here with one's real name. 
So, here it is: Franck Louarn.

I'm trying to update my e-mail accounts so that I'm no longer identified 
here as Franck Z. If I fail, I'll start again with another address.

Cheers.