librelist archives

« back to archive

Liberty - Infrastructure

Liberty - Infrastructure

From:
Raphael Mack
Date:
2013-02-14 @ 22:00
Hi there,

I was just away for a few days and you filled up my mailbox - cool!

Thanks for using the issue system more actively, I think this is going
to the right direction, as it helps to see who is working on what.

I wanted to suggest a mailinglist, but browsing github I found one.
Nice! I just subscribed. Maybe we should place the link at a more
prominent position.

When you started the work on Liberty, I registered the domain
http://liberty-eiffel.org/ and added just a link to the github project
page and the blog. Maybe we could use this domain for any kind of
interface. - I'm not very comfortable with the wiki on github. It seems
to be very useful for documentation but for an "official" website it
doesn't really fit. On the other hand, I do not clearly know what needs
to be on an official site. What do you think? Feel free to assign me
issues.

A bit more on infrastructure:
What do you think about testing? - How do you work on tests? When
working on the wrappers years ago (before they were merged into
Liberty), I setup some scripts which executed some automated tests
whenever a commit was made. I somehow like the eXtreme thinking about
features, that only tested features are considered implemented. So in
real (programming) life I often start writing a test, before
implementing anything. So, if you find it helpful to have automated
tests finding (and maybe notifying) the bugs a commit introduced I'd try
to resurrect ET (EiffelTester).

I'd also think it would be good to have an online HTML-view of the
classes (se doc). I could try to set this up, e.g. on
doc.liberty-eiffel.org, if you think this is helpful.

Reading through the wiki I saw the SCOOP page. This is cool (I guess I
can say that even without having read and understood it carefully) - is
it already implemented? I guess not, so we should add an issue for that
and document the state on the wiki page.

In the Liberty-plan
(https://github.com/LibertyEiffel/Liberty/wiki/Liberty-plan ) there is
some discussion about the license. Is this already fixed? (I think GPLv3
for tools, MIT-X11 for libs and for wrappers the license of the wrapped
lib would be very fine.) Oh, this page is long. Should we mode the
"things to do now and later" into issues? Or maybe we can move the
complete plan into issues?

Page Liberty-compiler-design-notes states "The Liberty parser uses a
general parsing library" this is not yet true, right? And if I remember
your discussions correctly it is not the near plan to change this. (as
Cyril once tried and somehow stopped this development, right?) -> is
this work/legacy/tools?

To gather some work: Cyril, I'd like to give #28 a try - it seem to be
not too hard and could be a good chance for me to dive a bit into the
kernel.

Regards,
Rapha

Re: [libertyeiffel] Liberty - Infrastructure

From:
Cyril Adrian
Date:
2013-02-15 @ 07:08
Hi Raphael,

Not a lot of time this morning - to be quick, I assigned #28 to you. I'll
answer fully to your mail today.

Cheers


 *Cyril A**DRIAN*

[image: Facebook] <https://www.facebook.com/cyril.adrian> [image:
Twitter]<https://twitter.com/cadbart> [image:
LinkedIn] <http://fr.linkedin.com/in/cadrian/> [image: Google
Plus]<https://plus.google.com/u/0/100388810006463519079>
Contact me: [image: Google Talk] cyril.adrian@gmail.com
   [image: Twitter] <http://twitter.com/cadbart>  Latest tweet:
https://t.co/1nnxLX2N better like that Follow
@cadbart<http://twitter.com/cadbart>

Reply<http://twitter.com/?status=@cadbart&in_reply_to=cadbart&in_reply_to_status_id=302168011236851700>
Retweet <http://twitter.com/?status=RT @cadbart: https://t.co/1nnxLX2N
better like that> 22:30
Feb-14<http://twitter.com/cadbart/statuses/302168011236851712>
  Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>

  Free signature tool.

<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>
CLICK
HERE TO GET 
IT.<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>



2013/2/14 Raphael Mack <ramack@raphael-mack.de>

> Hi there,
>
> I was just away for a few days and you filled up my mailbox - cool!
>
> Thanks for using the issue system more actively, I think this is going
> to the right direction, as it helps to see who is working on what.
>
> I wanted to suggest a mailinglist, but browsing github I found one.
> Nice! I just subscribed. Maybe we should place the link at a more
> prominent position.
>
> When you started the work on Liberty, I registered the domain
> http://liberty-eiffel.org/ and added just a link to the github project
> page and the blog. Maybe we could use this domain for any kind of
> interface. - I'm not very comfortable with the wiki on github. It seems
> to be very useful for documentation but for an "official" website it
> doesn't really fit. On the other hand, I do not clearly know what needs
> to be on an official site. What do you think? Feel free to assign me
> issues.
>
> A bit more on infrastructure:
> What do you think about testing? - How do you work on tests? When
> working on the wrappers years ago (before they were merged into
> Liberty), I setup some scripts which executed some automated tests
> whenever a commit was made. I somehow like the eXtreme thinking about
> features, that only tested features are considered implemented. So in
> real (programming) life I often start writing a test, before
> implementing anything. So, if you find it helpful to have automated
> tests finding (and maybe notifying) the bugs a commit introduced I'd try
> to resurrect ET (EiffelTester).
>
> I'd also think it would be good to have an online HTML-view of the
> classes (se doc). I could try to set this up, e.g. on
> doc.liberty-eiffel.org, if you think this is helpful.
>
> Reading through the wiki I saw the SCOOP page. This is cool (I guess I
> can say that even without having read and understood it carefully) - is
> it already implemented? I guess not, so we should add an issue for that
> and document the state on the wiki page.
>
> In the Liberty-plan
> (https://github.com/LibertyEiffel/Liberty/wiki/Liberty-plan ) there is
> some discussion about the license. Is this already fixed? (I think GPLv3
> for tools, MIT-X11 for libs and for wrappers the license of the wrapped
> lib would be very fine.) Oh, this page is long. Should we mode the
> "things to do now and later" into issues? Or maybe we can move the
> complete plan into issues?
>
> Page Liberty-compiler-design-notes states "The Liberty parser uses a
> general parsing library" this is not yet true, right? And if I remember
> your discussions correctly it is not the near plan to change this. (as
> Cyril once tried and somehow stopped this development, right?) -> is
> this work/legacy/tools?
>
> To gather some work: Cyril, I'd like to give #28 a try - it seem to be
> not too hard and could be a good chance for me to dive a bit into the
> kernel.
>
> Regards,
> Rapha
>
>

Re: [libertyeiffel] Liberty - Infrastructure

From:
Paolo Redaelli
Date:
2013-02-15 @ 07:28
Il 15/02/2013 08:08, Cyril ADRIAN ha scritto:
> Hi Raphael,
>
> Not a lot of time this morning - to be quick, I assigned #28 to you. 
> I'll answer fully to your mail today.
>
I got quite busy today instead .... yet a little note
>
> 2013/2/14 Raphael Mack <ramack@raphael-mack.de 
> <mailto:ramack@raphael-mack.de>>
>
>     ....
>
>     I'd also think it would be good to have an online HTML-view of the
>     classes (se doc). I could try to set this up, e.g. on
>     doc.liberty-eiffel.org <http://doc.liberty-eiffel.org>, if you
>     think this is helpful.
>
Last time I used it effeldoc produced a huge pile of HTML files from 
standard library. If I recall correctly more than 300 MB.
I shall also fix some errors in code I made that prevent it from 
producing any outout
More on this this evening, I got to go right now...

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Voglia di Puzzle? Su MisterCupido.com troverai i "Puzzle Clementoni High 
Quality" a partire da soli euro 8,30
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12676&d=15-2

Re: [libertyeiffel] Liberty - Infrastructure

From:
Cyril Adrian
Date:
2013-02-15 @ 10:19
Hi Raphael,

2013/2/14 Raphael Mack <ramack@raphael-mack.de>

> Thanks for using the issue system more actively, I think this is going
> to the right direction, as it helps to see who is working on what.
>

I'm just trying to do it a bit more like I would do at work ;-)


> I wanted to suggest a mailinglist, but browsing github I found one.
> Nice! I just subscribed. Maybe we should place the link at a more
> prominent position.
>

Sure, e.g. in the github readme (which needs some flesh anyway)


When you started the work on Liberty, I registered the domain
> http://liberty-eiffel.org/ and added just a link to the github project
> page and the blog.


Great!


 Maybe we could use this domain for any kind of
> interface. - I'm not very comfortable with the wiki on github. It seems
> to be very useful for documentation but for an "official" website it
> doesn't really fit. On the other hand, I do not clearly know what needs
> to be on an official site. What do you think? Feel free to assign me
> issues.
>

I don't know yet. Your links, for sure. And soon, a debian PPA :-)
(something like apt.liberty-eiffel.org)


A bit more on infrastructure:
> What do you think about testing? - How do you work on tests?


I try using eiffeltest as it is very simple and robust. And I just finished
adding a mock framework :-)

SmartEiffel comes with a huge base of automatic tests. They just take,
well, hours to pass.


When working on the wrappers years ago (before they were merged into
> Liberty), I setup some scripts which executed some automated tests
> whenever a commit was made.


Commit time is not the time to launch tests. It takes too damn long. But:
 - tests should have been run, at least partially (hence not
automatically), before commit :-)
 - we should have some continuous integration infrastructure


I somehow like the eXtreme thinking about
> features, that only tested features are considered implemented. So in
> real (programming) life I often start writing a test, before
> implementing anything. So, if you find it helpful to have automated
> tests finding (and maybe notifying) the bugs a commit introduced I'd try
> to resurrect ET (EiffelTester).
>

Is that a continuous integration system? If so, please do :-)


I'd also think it would be good to have an online HTML-view of the
> classes (se doc). I could try to set this up, e.g. on
> doc.liberty-eiffel.org, if you think this is helpful.
>

That would be great, yes.


Reading through the wiki I saw the SCOOP page. This is cool (I guess I
> can say that even without having read and understood it carefully) - is
> it already implemented? I guess not, so we should add an issue for that
> and document the state on the wiki page.
>

It is not. I totally forgot the wiki, which shows dreams instead of actual
code.


In the Liberty-plan
> (https://github.com/LibertyEiffel/Liberty/wiki/Liberty-plan ) there is
> some discussion about the license. Is this already fixed? (I think GPLv3
> for tools, MIT-X11 for libs and for wrappers the license of the wrapped
> lib would be very fine.)


GPLv3 (not "or later") for tools, X-MIT for libs, just like SmartEiffel.
But this is not mandatory. I planned to centralize copyrights in a
document, but it seems it is not a good idea. To each his copyright.


Oh, this page is long. Should we mode the
> "things to do now and later" into issues? Or maybe we can move the
> complete plan into issues?
>

Issues is a good pragmatic system for technical plan management. I like it.
On the other hand, github uses milestones and we should decide how to
manage those. It means deciding on how to name versions. I like having some
tag for the version development, and using a date-related version for the
public (a la ubuntu).


Page Liberty-compiler-design-notes states "The Liberty parser uses a
> general parsing library" this is not yet true, right?


Not anymore. It was true at the beginning when I wanted to rewrite
everything ;-)


And if I remember
> your discussions correctly it is not the near plan to change this. (as
> Cyril once tried and somehow stopped this development, right?) -> is
> this work/legacy/tools?
>

yes


To gather some work: Cyril, I'd like to give #28 a try - it seem to be
> not too hard and could be a good chance for me to dive a bit into the
> kernel.
>

I assigned it to you.

Cheers,



 *Cyril ADRIAN** (from office)*
 [image: Google Plus] <http://plus.google.com/100388810006463519079> My
latest G+: #golang 's mock framework is simple and beautiful — and powerful
:-) <http://plus.google.com/100388810006463519079/posts/Fr6n37mZLpP>
My G+ <http://plus.google.com/100388810006463519079> -
Posts<http://plus.google.com/100388810006463519079/posts/>- Add
to Circles <http://plus.google.com/100388810006463519079/about/> - 07:59
Jan-25 <http://plus.google.com/100388810006463519079>
  Get this email app!

<http://www.wisestamp.com/apps/plus?utm_source=extension&utm_medium=email&utm_term=plus&utm_campaign=apps>

  <http://fr.linkedin.com/in/cadrian/>
 Get a signature like this.

<http://r1.wisestamp.com/r/landing?promo=35&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_35>
CLICK

HERE.<http://r1.wisestamp.com/r/landing?promo=35&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_35>


  <http://twitter.com/cadbart> Latest tweet:
Follow @cadbart <http://twitter.com/cadbart> •https://t.co/EmOXMtkV Merge
branch 'master' of

http://t.co/SmdrEYJO:cadrian/Liberty<http://twitter.com/cadbart/statuses/302335534343266304>
• https://t.co/Z7NQqEfr nominal test of the mocker -- fix
#29<http://twitter.com/cadbart/statuses/302335532652957696>
• https://t.co/JZEklwSh nominal test of the
mocker<http://twitter.com/cadbart/statuses/302335111314157569> View
more <http://twitter.com/cadbart>
  Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>

Re: [libertyeiffel] Liberty - Infrastructure

From:
Raphael Mack
Date:
2013-02-15 @ 22:22
Hi,

Am Freitag, den 15.02.2013, 11:19 +0100 schrieb Cyril ADRIAN: 
> 2013/2/14 Raphael Mack <ramack@raphael-mack.de>
>         I wanted to suggest a mailinglist, but browsing github I found
>         one.
>         Nice! I just subscribed. Maybe we should place the link at a
>         more
>         prominent position. 
> 
> 
> Sure, e.g. in the github readme (which needs some flesh anyway)

Done in my branch. I'm trying to send a pull request but I'm not yet
familiar with git and github. - At work we use strange old programs
which are worse for versioning than just using the plain filesystem ;-( 

> 
> I don't know yet. Your links, for sure. And soon, a debian PPA :-)
> (something like apt.liberty-eiffel.org)

Everything is possible. I guess a debian repo is just a set of files
which are magically build by some scripts, right? 
>         A bit more on infrastructure:
>         What do you think about testing? - How do you work on tests? 
> I try using eiffeltest as it is very simple and robust. And I just
> finished adding a mock framework :-)
> SmartEiffel comes with a huge base of automatic tests. They just take,
> well, hours to pass.
> 
That's why I think that complete runs are not realistic locally... 
> 
> 
>         When working on the wrappers years ago (before they were
>         merged into
>         Liberty), I setup some scripts which executed some automated
>         tests
>         whenever a commit was made. 
> 
> 
> Commit time is not the time to launch tests. It takes too damn long.
> But:
>  - tests should have been run, at least partially (hence not
> automatically), before commit :-)
>  - we should have some continuous integration infrastructure

oh, I was not clear here. I didn't mean at commit time, but after
commiting the tests have been started automatically. I guess this is
exactly a continuous integration infrastructure.

I'll give it a try. #30

> 
>         doc.liberty-eiffel.org, if you think this is helpful. 

> That would be great, yes.

#31


>         Oh, this page is long. Should we mode the
>         "things to do now and later" into issues? Or maybe we can move
>         the
>         complete plan into issues? 

> 
> Issues is a good pragmatic system for technical plan management. I
> like it. On the other hand, github uses milestones and we should
> decide how to manage those. It means deciding on how to name versions.
> I like having some tag for the version development, and using a
> date-related version for the public (a la ubuntu).

This sounds good. Anyhow I don't know whether we should "force"
ourselves to release every 6 months. I could live with some definition
what we want to have in the next milestone and release it when all the
defined features/issues are in. For the first release I do not have high
requirements, but I think it should be released "soon" to show some
progress to the public.
> 
>         Page Liberty-compiler-design-notes states "The Liberty parser
>         uses a
>         general parsing library" this is not yet true, right? 

> Not anymore. It was true at the beginning when I wanted to rewrite
> everything ;-)

I added a note to the wiki page. - Feel free to improve, my English is
not the best ;-(


>         To gather some work: Cyril, I'd like to give #28 a try - it
>         seem to be
>         not too hard and could be a good chance for me to dive a bit
>         into the
>         kernel. 

> I assigned it to you.

I tried to fix it, but failed for the moment.

Cheers,
Rapha

Re: [libertyeiffel] Liberty - Infrastructure

From:
Cyril Adrian
Date:
2013-02-15 @ 23:06
Hi,

2013/2/15 Raphael Mack <ramack@raphael-mack.de>

> > I don't know yet. Your links, for sure. And soon, a debian PPA :-)
>
> (something like apt.liberty-eiffel.org)
>
> Everything is possible. I guess a debian repo is just a set of files
> which are magically build by some scripts, right?
>

I use reprepro. The package itself is built by debuild.


> Issues is a good pragmatic system for technical plan management. I
>
> like it. On the other hand, github uses milestones and we should
> > decide how to manage those. It means deciding on how to name versions.
> > I like having some tag for the version development, and using a
> > date-related version for the public (a la ubuntu).
>
> This sounds good. Anyhow I don't know whether we should "force"
> ourselves to release every 6 months.


You are right, I was not clear. I was not thinking about (and don't intend
to enforce) that 6-month stuff.

But dates are a really convenient way to tag releases. "Year.month" is
simple and easy to remember, but assigned only at (or near) release time.

As for the release names: I was thinking of using famous engineers names
starting by A for the first release, B for the second, and so on.

For example: (using http://en.wikipedia.org/wiki/Lists_of_engineers)
  1- Charles Adler, Jr. (short: "adler")
  2- Alexander Graham Bell (short: "bell")

We would use the short tags anywhere convenient, e.g. milestone names.

What do you think?


I could live with some definition
> what we want to have in the next milestone and release it when all the
> defined features/issues are in. For the first release I do not have high
> requirements, but I think it should be released "soon" to show some
> progress to the public.
>

Yes. We just need to put issues in milestones, hence the names.


I tried to fix it, but failed for the moment.
>

Should it help, it's somewhere in src/smarteiffel/ace/loadpath.e ;-)

Cheers


*Cyril A**DRIAN*

[image: Facebook] <https://www.facebook.com/cyril.adrian> [image:
Twitter]<https://twitter.com/cadbart> [image:
LinkedIn] <http://fr.linkedin.com/in/cadrian/> [image: Google
Plus]<https://plus.google.com/u/0/100388810006463519079>
Contact me: [image: Google Talk] cyril.adrian@gmail.com
   [image: Twitter] <http://twitter.com/cadbart>  Latest tweet:
https://t.co/z3ErhCaB allow for any gcc flavor Follow
@cadbart<http://twitter.com/cadbart>

Reply<http://twitter.com/?status=@cadbart&in_reply_to=cadbart&in_reply_to_status_id=302444617230594050>
Retweet <http://twitter.com/?status=RT @cadbart: https://t.co/z3ErhCaB
allow for any gcc flavor> 16:49
Feb-15<http://twitter.com/cadbart/statuses/302444617230594050>
  Get this email app!

<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>

  Free signature tool.

<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>
CLICK
HERE TO GET 
IT.<http://r1.wisestamp.com/r/landing?promo=32&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_32>

Re: [libertyeiffel] Liberty - Infrastructure

From:
Raphael Mack
Date:
2013-02-16 @ 18:47
Am Samstag, den 16.02.2013, 00:06 +0100 schrieb Cyril ADRIAN: 
>         This sounds good. Anyhow I don't know whether we should
>         "force"
>         ourselves to release every 6 months. 

>         
> You are right, I was not clear. I was not thinking about (and don't
> intend to enforce) that 6-month stuff.

> But dates are a really convenient way to tag releases. "Year.month" is
> simple and easy to remember, but assigned only at (or near) release
> time.

> As for the release names: I was thinking of using famous engineers
> names starting by A for the first release, B for the second, and so
> on.

> For example: (using http://en.wikipedia.org/wiki/Lists_of_engineers)
>   1- Charles Adler, Jr. (short: "adler")
>   2- Alexander Graham Bell (short: "bell")
> We would use the short tags anywhere convenient, e.g. milestone names.
> What do you think?

Let's go for it! - I saw you already tagged the issues, it's cool. 
>         I tried to fix it, but failed for the moment.
> 
> Should it help, it's somewhere in src/smarteiffel/ace/loadpath.e ;-)

Thanks, this is about where I am ;-) - I even have already a warning,
but just after it crashes. Have to take a look at the context.

Regards,
Rapha