gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] Bug in class READABLE_STRING_8

[Wolfgang J. <wo....@ka...>]

Hi Eric,

I found an fatal error in routine READABLE_STRING_8.copy if the argument 
is a non-void but empty string. The origin text is as follows:

     copy (other: like Current)
             -- Reinitialize by copying the characters of `other'.
             -- (This is also used by `twin'.)
         local
             old_area: like area
         do
             if other /= Current then
                 old_area := area
                 standard_copy (other)
                     -- Note: <= is needed as all Eiffel string should 
have an
                     -- extra character to insert null character at the end.
                 if old_area = Void or else old_area = other.area or 
else old_area.count <= count then
                         -- Prevent copying of large `area' if only a 
few characters are actually used.
                     area := area.resized_area (count + 1)
                 else
                     old_area.copy_data (area, 0, 0, count)
                     area := old_area
                 end
                 internal_hash_code := 0
             end
         ensure then
             new_result_count: count = other.count
             -- same_characters: For every `i' in 1..`count', `item' 
(`i') = `other'.`item' (`i')
         end


If the string to copy is empty, i.e. `old_area=Void' then `area' is 
void, too,
after `standard_copy'. Then branch `if old_area=Void or else ...' leads 
to instruction `area := area.resized_area (count + 1)' that must crash. 
I propose the following modification (it works fine for me):


     copy (other: like Current)
             -- Reinitialize by copying the characters of `other'.
             -- (This is also used by `twin'.)
         local
             old_area: like area
         do
             if other /= Current then
                 old_area := area
                 standard_copy (other)
                     -- Note: <= is needed as all Eiffel string should 
have an
                     -- extra character to insert null character at the end.
                 if old_area = Void then
                 elseif old_area = other.area or else old_area.count <= 
count then
                         -- Prevent copying of large `area' if only a 
few characters are actually used.
                     area := area.resized_area (count + 1)
                 else
                     old_area.copy_data (area, 0, 0, count)
                     area := old_area
                 end
                 internal_hash_code := 0
             end
         ensure then
             new_result_count: count = other.count
             -- same_characters: For every `i' in 1..`count', `item' 
(`i') = `other'.`item' (`i')
         end


I do not know whether the bug is already in ISE's distribution of the 
class.

Best regards
Wolfgang

-- 
Dr. Wolfgang Jansen
Lauenburger Straße 40
D-12169 Berlin

Tel: (+49) 0172 40 86 916
e-mail: wo....@ka...

Re: [gobo-eiffel-develop] library.ecf for not void safe

[Berend de B. <be...@po...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> The reason why I put only one ECF file is that I don't want
    Eric> to have to maintain several ECF files. That's why we
    Eric> invented Xace in the first place: avoid having to maintain
    Eric> multiple files.

It seems your current .ecf files were hand-generated, so that's why I
mentioned this.

But isn't this only temporary? I.e. once we all move to void safe, I
think ecf is sufficient, isn't it?


So another solution would be a gexace patch then. Just changing the
version number solves most of the problems. It seems ISE Eiffel is
extremely finicky on having the same versions on all .ecf files,
mixing versions produces very odd results.


But does generating library ecf files work actually? I noticed you
have to repeat include a reference to every library that is used by a
library, so a completely different concept from xace.


But having gexace generate a single .ecf file with a single ecf
version number for a system sounds like a much simpler world than what
ecf is currently trying to achieve.

--
All the best,

Berend de Boer

Re: [gobo-eiffel-develop] library.ecf for not void safe

[Eric B. <er...@go...>]

On 5/25/2016 04:29, Berend de Boer wrote:
> As there is a library.ecf for void safe programs, how about adding a
> library-unsafe.ecf? I have a bunch ready in case this is a good idea.

The reason why I put only one ECF file is that I don't want to have
to maintain several ECF files. That's why we invented Xace in the
first place: avoid having to maintain multiple files. It's a shame
that with ECF we have to duplicate files just because we don't want
the same settings. This is a bad design in my opinion.
My plan is to improve Xace to be better at generating ECF files.
Then we would be able to maintain only one file (the Xace file) and
generate several ECF files depending on the options we want.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] library.ecf for not void safe

[Berend de B. <be...@po...>]

Hi All,

As there is a library.ecf for void safe programs, how about adding a
library-unsafe.ecf? I have a bunch ready in case this is a good idea.

Still haven't switched to void safe, but have decided to switch to ecf
(and the days of trouble getting things to compile for no gain in output).

--
All the best,

Berend de Boer

Re: [gobo-eiffel-develop] post condition violation with KL_CASE_INSENSITIVE_STRING_EQUALITY_TESTER

[Eric B. <er...@go...>]

On 1/13/2016 03:45, Berend de Boer wrote:
> Doesn't make much sense. to me, but in case something pops in your
> head, let me know, else I may try to come up with a program that
> repeats this.
>
> This is the code that creates the structure:
>
>       local
>         fields: DS_HASH_TABLE [EPX_MIME_FIELD, STRING]
>         equality_tester: KL_CASE_INSENSITIVE_STRING_EQUALITY_TESTER
>       do
>               create fields.make (64)
>               create equality_tester
>                fields.set_key_equality_tester (equality_tester)
>         ....
>         if fields.has ("ST) then
>           ...
>         end
>       end

When you change the key equality tester in a hash table, you should
also change the hash function accordingly. Otherwise you might end
up with two keys which are considered equal but which have two
different hash code.


      l_hash_function: KL_AGENT_HASH_FUNCTION [STRING]
      ...
      create l_hash_function.make (agent STRING_.case_insensitive_hash_code)
      ...
      fields.set_hash_function (l_hash_function)

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] post condition violation with KL_CASE_INSENSITIVE_STRING_EQUALITY_TESTER

[Berend de B. <be...@po...>]

>>>>> "Berend" == Berend de Boer <be...@po...> writes:

    Berend> if fields.has ("ST) then

Just noticed that there is a field with value "St" so should find
something, but doesn't.

--
All the best,

Berend de Boer

[gobo-eiffel-develop] post condition violation with KL_CASE_INSENSITIVE_STRING_EQUALITY_TESTER

[Berend de B. <be...@po...>]

Hi Eric,

I just switched a KL_STRING_EQUALITY_TESTER to
KL_CASE_INSENSITIVE_STRING_EQUALITY_TESTER and got a postcondition
violation.

Part of the stack trace:

DS_HASH_TABLE       search_position @35    slots_position_set:
<00007FF1A127DE08>  (From DS_SPARSE_CONTAINER)
                                           Postcondition violated.       Fail
-------------------------------------------------------------------------------
DS_HASH_TABLE       search_position @35
<00007FF1A127DE08>  (From DS_SPARSE_CONTAINER)
                                           Routine failure.              Fail
-------------------------------------------------------------------------------
DS_HASH_TABLE       has @1
<00007FF1A127DE08>  (From DS_SPARSE_TABLE) Routine failure.              Fail
-------------------------------------------------------------------------------
EPX_MIME_HEADER     has @2
<00007FF1A127DD48>                         Routine failure.              Fail
-------------------------------------------------------------------------------


Doesn't make much sense. to me, but in case something pops in your
head, let me know, else I may try to come up with a program that
repeats this.

This is the code that creates the structure:

      local
        fields: DS_HASH_TABLE [EPX_MIME_FIELD, STRING]
        equality_tester: KL_CASE_INSENSITIVE_STRING_EQUALITY_TESTER
      do
  			create fields.make (64)
  			create equality_tester
	  		fields.set_key_equality_tester (equality_tester)
        ....
        if fields.has ("ST) then
          ...
        end
      end

--
All the best,

Berend de Boer

Re: [gobo-eiffel-develop] Gobo Git repository

[Berend de B. <be...@po...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> As a consequence, we should now consider that the repository
    Eric> on GitHub is the official Gobo repository from which one
    Eric> needs to fork in order to contribute to the project. The
    Eric> repository on Sourceforge has been made read-only and is now
    Eric> a mirror of the one in GitHub.

Great!

--
All the best,

Berend de Boer

[gobo-eiffel-develop] Gobo Git repository

[Eric B. <er...@go...>]

Hello,

So far, the Git repository in Sourceforge was considered as
the "official" Gobo repository, and there was one on GitHub
as mirror. I noticed during the past couple of years that
people who wanted to contribute to Gobo were actually forking
the repository hosted on GitHub, and then were submitted
pull requests from their GitHub fork. I find this solution
more convenient than having to set permissions to the
Sourceforge repository when people ask for it, and then
have to "fix" what they pushed to the repository when they
broke something.

As a consequence, we should now consider that the repository
on GitHub is the official Gobo repository from which one needs
to fork in order to contribute to the project. The repository
on Sourceforge has been made read-only and is now a mirror
of the one in GitHub.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Compiling with void safe

[Eric B. <er...@go...>]

On 1/8/2016 23:54, Berend de Boer wrote:
> Hi All,
>
> I'm trying to convert a program to be void-safe. How do I enable that
> in system.xace?
>
> I've tried to set the option:
>
>   <option void_safety="complete"/>
>
> but doesn't appear to do anything.

Xace does not support void-safety yet.
I'll add it in the near future.
This task is not as easy as it seems, as you noticed below.

> I've also tried to grab a generated compile_ise.ecf and make that void
> safe by setting to conformance, and changing the libraries to the void
> safe versions, but that gives weird compilation errors like:
>
>   Error code: VDRD(2)
>
>   Type error: redeclaration has non-conforming signature.
>   What to do: make sure that redeclaration uses signature (number and
>     types of arguments and result) conforming to that of the original.
>
>   Class: UC_CHARACTER
>   Redefined feature: out: STRING_8 From: UC_CHARACTER
>   Precursor: out: STRING_8 From: ANY
>
> which doesn't make much sense to me, so perhaps an earlier error causing
> this.

I would assume that the version of `out' in ANY is considered
by the compiler as attached whereas the one in UC_CHARACTER is
considered as detachable. So I assume that you have a reference
to base-safe.ecf in your compile_ise.ecf, but this latter ECF file
does not specify the option 'is_attached_by_default'.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Compiling with void safe

[Berend de B. <be...@po...>]

Hi All,

I'm trying to convert a program to be void-safe. How do I enable that
in system.xace?

I've tried to set the option:

  <option void_safety="complete"/>

but doesn't appear to do anything.


I've also tried to grab a generated compile_ise.ecf and make that void
safe by setting to conformance, and changing the libraries to the void
safe versions, but that gives weird compilation errors like:

  Error code: VDRD(2)

  Type error: redeclaration has non-conforming signature.
  What to do: make sure that redeclaration uses signature (number and
    types of arguments and result) conforming to that of the original.

  Class: UC_CHARACTER
  Redefined feature: out: STRING_8 From: UC_CHARACTER
  Precursor: out: STRING_8 From: ANY

which doesn't make much sense to me, so perhaps an earlier error causing this.

--
All the best,

Berend de Boer

Re: [gobo-eiffel-develop] [POLL] Change Gobo bootstrap scripts to CMake

[Berend de B. <be...@po...>]

>>>>> "Bernd" == Bernd Schoeller <be...@fa...> writes:

    Bernd> CMake is a huge tool-chain that needs to be ported to all
    Bernd> the different platforms. I would only vote for adding this
    Bernd> if there would be a really hard problem that we have to
    Bernd> solve.

I agree with this assessment. Makefiles and shell scripts are pretty
portable across unix. Perhaps people on Windows are thinking that
cmake will solve the problem?


--
All the best,

Berend de Boer

Re: [gobo-eiffel-develop] [POLL] Change Gobo bootstrap scripts to CMake

[Wolfgang J. <wo....@ka...>]

On 12/23/2015 07:38 AM, Eric Bezault wrote:
> On 12/22/2015 19:42, CHAUVET Guillaume wrote:
>> I hope one day GOBO will generate *.c *.h files per classes. By this
>> way, we can enable ccache (natively supported by CMake 2.8.0) to detect
>> what content files really change after C generation.
> Note that it's not as easy as generating *.c and *.h files per classes.
> Currently the Gobo compiler tries to optimize the C code generation by
> performing a system level analysis of the Eiffel code. Which means that,
> unless you just change one character in one string, it is likely that
> every C file would change after each compile. In order to be truly
> incremental at the C level, the Gobo compiler should have another C
> code generation mode which is more focused on preserving the C code
> unmodified rather than on global optimization. This is the same thing
> as in ISE's EiffelStudio with workbench (frozen) and finalize modes.
> Currently the Gobo compiler only has the finalize mode.
>
Hi Eric, Guillaume,

excuse when i drop into your discussion.

Conceptually, splitting C code per class or type should not very hard:
writing a type's struct or routine had to be enclosed into file-open, 
file-close parentheses, one file per type.

I see the problem at another level. Consider a large Eiffel system, e.g. 
the GEC.
It consists of about 2000 alive types (i.e. types where C code is to be 
generated) from about 670 classes. Compilation may be per type or class 
but linkage needs all file names in the command line. The Unix command 
line allows after resolution of wildcards etc. for about 32000 
characters (I do not know which restrictions Windows applies, if any). 
So we have up to 16 characters for 2000 files, three charactersare 
reserved: the dot, the extension 'c', the separating blank. This means 
class or type names are in general too long and artificial file names 
are to be generated like "gec1234.c". This is the way, EiffelStudio 
tackles the problem: compilation of the many C files having cryptic 
names in manageable chunks to intermediary object files and then linkage 
of the much fewer objects. The problem for GEC would be to generate the 
same file names for unchanged types/classes across various compilations, 
since it was the intension to reuse all the unchanged C code. 
EiffelStudio is an IDE, comparison of system states between forthcoming 
compilations is duty of the project management, unchanged parts will be 
detected and can be reused. So, the GEC had first to be upgraded to an IDE.

Taking all together, it is worth thinking again about C code generation 
per type/class without turning GEC into an IDE. The true complication is 
organizing the make utilities for compilation in chunks. The risk for 
the user is to C-compile all the stuff if too many generated file names 
changed, the gain for the user is much less C-compilation time if file 
names were rather stable.

Wolfgang

-- 
Dr. Wolfgang Jansen
Lauenburger Straße 40
D-12169 Berlin

Tel: (+49) 0172 40 86 916
e-mail: wo....@ka...

Re: [gobo-eiffel-develop] [POLL] Change Gobo bootstrap scripts to CMake

[Eric B. <er...@go...>]

On 12/22/2015 19:42, CHAUVET Guillaume wrote:
> I hope one day GOBO will generate *.c *.h files per classes. By this
> way, we can enable ccache (natively supported by CMake 2.8.0) to detect
> what content files really change after C generation.

Note that it's not as easy as generating *.c and *.h files per classes.
Currently the Gobo compiler tries to optimize the C code generation by
performing a system level analysis of the Eiffel code. Which means that,
unless you just change one character in one string, it is likely that
every C file would change after each compile. In order to be truly
incremental at the C level, the Gobo compiler should have another C
code generation mode which is more focused on preserving the C code
unmodified rather than on global optimization. This is the same thing
as in ISE's EiffelStudio with workbench (frozen) and finalize modes. 
Currently the Gobo compiler only has the finalize mode.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] [POLL] Change Gobo bootstrap scripts to CMake

[CHAUVET G. <gch...@za...>]

Hi Bernd,

> I find it absolutely fantastic that you are contributing to GOBO. Every 
> help is welcome.

Thank you, I've worked with Eiffel 10 years ago on my spare time. I 
always like this
language for DbC and the strong typing. Unfortunately, my job required 
Javascript (Node.JS)
and PHP like languages...

> Perhaps things become clearer if you let us know why you thought the
> .sh/.bat scripts needed improvement and start from there. Did you have
> problems bootstrapping GOBO on some platform? Did you find it too
> complicated?

Well, my idea was to provide a single way to bootstrap GOBO 
independently of operating system. I've selected Makefile or CMake.
I retain CMake because he have a good abstraction of environment and 
create CMake scripts is pretty easy.

I've discussed with Eric, we will kept the current bootstrap mechanism 
and we will add CMake as a second choice (to be confirmed).

> PS: Where I could see a use for CMake would be in the portability of
> wrapped C libraries or similar. Because CMake has no idea about Eiffel,
> things like incremental compilation and dependency analysis are not
> supported with CMake and Eiffel.

I hope one day GOBO will generate *.c *.h files per classes. By this 
way, we can enable ccache (natively supported by CMake 2.8.0) to detect 
what content files really change after C generation.

Regards

Re: [gobo-eiffel-develop] [POLL] Change Gobo bootstrap scripts to CMake

[Bernd S. <be...@fa...>]

Hi Guillaume,

I find it absolutely fantastic that you are contributing to GOBO. Every 
help is welcome.

Still, I have participated in your vote, and expressed a 'NO'. The 
reason is that there are no real problems with the shell scripts. They 
are a 'super low tech' solution to the bootstrap problem. And until now, 
they have rarely failed me - even on OSs like BSDs or Solaris. If they 
fail, because they are so simple, they are normally easy to fix.

CMake is a huge tool-chain that needs to be ported to all the different 
platforms. I would only vote for adding this if there would be a really 
hard problem that we have to solve.

Perhaps things become clearer if you let us know why you thought the 
.sh/.bat scripts needed improvement and start from there. Did you have 
problems bootstrapping GOBO on some platform? Did you find it too 
complicated?

Regards,
Bernd

PS: Where I could see a use for CMake would be in the portability of 
wrapped C libraries or similar. Because CMake has no idea about Eiffel, 
things like incremental compilation and dependency analysis are not 
supported with CMake and Eiffel.

On 19/12/15 13:58, CHAUVET Guillaume wrote:
> Dear Gobo Eiffel users,
>
> I would like to discuss about an experimental patch for Gobo. Instead to
> use batch or sh scripts to bootstrap Gobo, I propose to use the CMake
> builder tool to manage this part (bootstrap only, not C code generated
> by GEC - for the moment -). Eric recommended me to asking to the Gobo
> Eiffel community/developpers what you think about this potential
> feature, by voting with a Doodle at this URL :
> http://doodle.com/poll/85tim76uttqbrzmx
>
> Best regards,
> Guillaume
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

[gobo-eiffel-develop] [POLL] Change Gobo bootstrap scripts to CMake

[CHAUVET G. <gch...@za...>]

Dear Gobo Eiffel users,

I would like to discuss about an experimental patch for Gobo. Instead to 
use batch or sh scripts to bootstrap Gobo, I propose to use the CMake 
builder tool to manage this part (bootstrap only, not C code generated 
by GEC - for the moment -). Eric recommended me to asking to the Gobo 
Eiffel community/developpers what you think about this potential 
feature, by voting with a Doodle at this URL :
http://doodle.com/poll/85tim76uttqbrzmx

Best regards,
Guillaume

[gobo-eiffel-develop] Subscribe

[Guillaume Ch <gch...@gm...>]

Subscribe

Re: [gobo-eiffel-develop] Bug in GEC time measurement

[Eric B. <er...@go...>]

Hi Wolfgang,
> today I found a minor bug (really, a milli or micro bug) in GEC
> concerning time measurement.

Thanks you for this bug report and the fix which comes with it.
It's now committed in the Git repository.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Bug in GEC time measurement

[Wolfgang J. <wo....@ka...>]

Hi Eric,

today I found a minor bug (really, a milli or micro bug) in GEC 
concerning time measurement.
File $GOBO/tool/gec/runtime/c/ge_time.h defines `GE_timebmillitm' in 
case of `HAS_GETTIMEOFDAY' as
"((struct timeval*)(p))->tv_usec".
But `timeval.tv_usec' is in microseconds, not in milliseconds. So the 
definition should be replaced by
"((struct timeval*)(p))->tv_usec/1000".

Maybe, the "u" in "usec" is to be understood as ASCII approximation to 
Greek "µ".

Best regards
Wolfgang

-- 
Dr. Wolfgang Jansen
Lauenburger Straße 40
D-12169 Berlin

Tel: (+49) 0172 40 86 916
e-mail: wo....@ka...

Re: [gobo-eiffel-develop] Bad C code generated for built-in macro

[Eric B. <er...@go...>]

Hi Wolfgang,

> the Eiffel compilation of the attached micro class by GEC
> works very well but C compilation fails because of imbalanced
> parentheses. In Eiffel, this is a built-in macro,
> other macro externals are treated correctly.

Thank you for this bug report. It's now fixed in github.

> BTW, macro 'GE_real_64_positive_infinity' is defined
> in $GOBO/tool/gec/runtime/c/ge_real.h as
> 'GE_real_64_from_bits(GE_nat64(0x7FF0000000000000))'.
> What about defining it as 'INFINITY' coming from math.h?

I'm using the same definition as in EiffelStudio.
This limits the risk for incompatibilities.

BTW, did you make an announcement of your Gobo debugger in Google+:
https://plus.google.com/communities/109001715580721282898

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Bad C code generated for built-in macro

[Wolfgang J. <wo....@ka...>]

Hi Eric,

the Eiffel compilation of the attached micro class by GEC
works very well but C compilation fails because of imbalanced
parentheses. In Eiffel, this is a built-in macro,
other macro externals are treated correctly.

BTW, macro 'GE_real_64_positive_infinity' is defined
in $GOBO/tool/gec/runtime/c/ge_real.h as
'GE_real_64_from_bits(GE_nat64(0x7FF0000000000000))'.
What about defining it as 'INFINITY' coming from math.h?

With best regards
Wolfgang

-- 
Dr. Wolfgang Jansen
Lauenburger Straße 40
D-12169 Berlin

Tel: (+49) 0172 40 86 916
e-mail: wo....@ka...

[gobo-eiffel-develop] Gedb -- A debugger for Gec generated Eiffel systems

[Wolfgang J. <wo....@ka...>]

Hi All,

a few years ago I announced a debugging tool for the Gec.
The response was very poor that time.
Here, I announce another one to be found at

"https://github.com/wjansen/GOBO-Eiffel-debugger" branch "extra".

While the first debugger had a CLUI, the current one has a GUI.
It seems to work well under OS of the UNIX family, so far I could not 
test it under Windows.
Details are described in file "doc/debugger/debug.pdf" of that distribution.

With regards
Wolfgang Jansen

-- 
Dr. Wolfgang Jansen
Lauenburger Straße 40
D-12169 Berlin

Tel: (+49) 0172 40 86 916
e-mail: wo....@ka...

Re: [gobo-eiffel-develop] Have a "gobo" tool

[Jocelyn F. <jf...@ei...>]

Hi
As part of EWF, we started a simple tool to generate .ecf, and Eiffel
classes for EWF application, but I think the principle could be extended to
any kind of Eiffel application since it is based on template.
If needed, I can refresh the tool for such need, or use any better tool
available (and written in Eiffel).

There is also a tool at
https://svn.eiffel.com/eiffelstudio/trunk/Src/tools/ecf_builder that helps
building application, library or testing ecf.

But yes, I think Eiffel users would need such tool.
I am wondering, is xace the recommended project file for Gobo, or ecf files
are now used primary?

However, I think if we have something based on template, we could have ecf,
xace or whatever.

-- Jocelyn


On Thu, Oct 23, 2014 at 9:11 AM, LIGOT Olivier <Oli...@gr...>
wrote:

> Hi,
>
> For this task, I'm using a scaffolding tool called yeoman[1].
> It comes with a set of generators[2] and you can (easily)
> write your own[3].
> Note that it's a Node.js[4] project, which means the generators
> are written in JavaScript...
>
> Regards,
>
> Olivier
>
> [1] http://yeoman.io/
> [2] http://yeoman.io/generators/
> [3] http://yeoman.io/authoring/
> [4] http://nodejs.org/
>
> ________________________________________
> De : Berend de Boer [be...@po...]
> Envoyé : mercredi 22 octobre 2014 22:29
> À : Gobo Developers Mailing List
> Objet : [gobo-eiffel-develop] Have a "gobo" tool
>
> Hi All,
>
> Would it be useful to have a gobo tool to make creating Eiffel
> applications from the command-line easier? Example:
>
>   gobo generate app "next-great-thing"
>
> Which would simply write a default system.xace and build.eant. Saves
> time, and makes writing "how to create an eiffel app" easier. Now I
> always copy these files from an existing project, and edit them.
>
> Tools like this have become quite common (I modelled the above example
> on sencha cmd).
>
> After we have step one working we can expand this with:
>
>   gobo generate app --description "Build it and they will come"
> "next-great-thing"
>
> It could perhaps start geant etc too (not sure why you want too):
>
>   gobo geant compile_ge
>
> i..e can become single entry point to run Gobo command-line tools.
>
> --
> All the best,
>
> Berend de Boer
>
> ----------------------------
> ***** Group S disclaimer *****
> Deze informatie wordt u gegeven onder voorbehoud van alle rechten en
> zonder enige nadelige erkentenis. Group S kan hiervoor geenszins
> aansprakelijk worden gesteld.
>
> Ces informations vous sont données sous toutes réserves, sans aucune
> reconnaissance préjudiciable et ne peuvent en aucun cas engager la
> responsabilité de Group S.
> http://www.groups.be/1_mail-disclaimer.htm
> ----------------------------
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>



-- 
Jocelyn
------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

Re: [gobo-eiffel-develop] Have a "gobo" tool

[LIGOT O. <Oli...@gr...>]

Hi,

For this task, I'm using a scaffolding tool called yeoman[1].
It comes with a set of generators[2] and you can (easily)
write your own[3].
Note that it's a Node.js[4] project, which means the generators
are written in JavaScript...

Regards,

Olivier

[1] http://yeoman.io/
[2] http://yeoman.io/generators/
[3] http://yeoman.io/authoring/
[4] http://nodejs.org/

________________________________________
De : Berend de Boer [be...@po...]
Envoyé : mercredi 22 octobre 2014 22:29
À : Gobo Developers Mailing List
Objet : [gobo-eiffel-develop] Have a "gobo" tool

Hi All,

Would it be useful to have a gobo tool to make creating Eiffel
applications from the command-line easier? Example:

  gobo generate app "next-great-thing"

Which would simply write a default system.xace and build.eant. Saves
time, and makes writing "how to create an eiffel app" easier. Now I
always copy these files from an existing project, and edit them.

Tools like this have become quite common (I modelled the above example
on sencha cmd).

After we have step one working we can expand this with:

  gobo generate app --description "Build it and they will come" "next-great-thing"

It could perhaps start geant etc too (not sure why you want too):

  gobo geant compile_ge

i..e can become single entry point to run Gobo command-line tools.

--
All the best,

Berend de Boer

----------------------------
***** Group S disclaimer *****
Deze informatie wordt u gegeven onder voorbehoud van alle rechten en zonder enige nadelige erkentenis. Group S kan hiervoor geenszins aansprakelijk worden gesteld.

Ces informations vous sont données sous toutes réserves, sans aucune reconnaissance préjudiciable et ne peuvent en aucun cas engager la responsabilité de Group S.
http://www.groups.be/1_mail-disclaimer.htm
----------------------------