Menu
▾
▴
gobo-eiffel-develop
|
From: Sven E. <sve...@we...> - 2008-02-02 17:51:42
|
Yes, I am still around :-) I would find it very useful to have local variables in geant. Note that I did not look into the the details of the patch. But what would you think about naming the task <local> instead of <setlocal> (just because of the similarity to Eiffel)? Also I could imagine that <unset> could be smart enough to find out itself if it is a local variable or a global one. Actually a long time ago I thought about implementing local variables myself but never took the time to do so. But the my feeling was the if local variables are supported all (or at least most) of the globals could be eliminated and be replaced by locals and parameters which should improve the scripts a lot. Eric Bezault wrote: > Hi Jocelyn, > > Somehow I didn't receive the original message that you sent on > January 31rst. I'm glad you copied it below. If Sven has no > objection about this addition to geant, then I'm fine with it. > Note that I didn't review your code below, but I guess that > you know the code of geant better than I do these days. > > It has been a long time since we didn't hear from Sven in the > Gobo mailing lists. Sven, are you still here? > |
|
From: Jocelyn <ei...@dj...> - 2008-02-02 18:06:57
|
I agree that <local ../> would be nicer than <setlocal ... />
but then .. do we consider <local ../> as local declaration, as
<argument ... />
and in this case <set /> and <unset /> would find itself, if they
apply to local or global ?
And if we use <local /> as declaration, do we allow unset variable ?
I mean ...
<local name="test" />
<echo message="$$test is not set" unless="$test" />
in this case I guess it is better to allow not set local variable.
we could even use <local name="test" value="foobar" /> to initialize
directly
If this is fill everyone's expectation, I can change my patch to have this.
and yes, local will bring better geant scripts :)
more than once, I got trapped by those awful global variable ;)
of course I would prefer to have <set .. /> by default for local
variables, and use a <global name="varname" />
but this would break existing code...
--Jocelyn
On 2/2/2008 18:51 PM, Sven Ehrke wrote:
> Yes, I am still around :-)
>
> I would find it very useful to have local variables in geant.
> Note that I did not look into the the details of the patch.
> But what would you think about naming the task <local> instead
> of <setlocal> (just because of the similarity to Eiffel)?
>
> Also I could imagine that <unset> could be
> smart enough to find out itself if it is a local variable or
> a global one.
>
> Actually a long time ago I thought about implementing local variables
> myself but never took the time to do so. But the my feeling was the
> if local variables are supported all (or at least most) of the globals
> could be
> eliminated and be replaced by locals and parameters which should
> improve the
> scripts a lot.
>
> Eric Bezault wrote:
>> Hi Jocelyn,
>>
>> Somehow I didn't receive the original message that you sent on
>> January 31rst. I'm glad you copied it below. If Sven has no
>> objection about this addition to geant, then I'm fine with it.
>> Note that I didn't review your code below, but I guess that
>> you know the code of geant better than I do these days.
>>
>> It has been a long time since we didn't hear from Sven in the
>> Gobo mailing lists. Sven, are you still here?
>>
>
>
>
|
|
From: Sven E. <sve...@we...> - 2008-02-02 19:28:33
|
Jocelyn wrote: > I agree that <local ../> would be nicer than <setlocal ... /> > > but then .. do we consider <local ../> as local declaration, as > <argument ... /> > and in this case <set /> and <unset /> would find itself, if they > apply to local or global ? I think so. > And if we use <local /> as declaration, do we allow unset variable ? > I mean ... I just did a grep on all build.eant files for '<unset' within gobo and only found two occurrences in 'example/geant/build.eant'. Maybe I forgot in the meanwhile but I do not see a lot of reasons at the moment for '<unset>'. If you can think of good use-cases for it please tell me. Otherwise I would prefer to remove it but since we would like to be backwards compatible I suggest to keep it (and it's current behavior) as it is now and not extend it for local variables. <set> on the other hand should check if there is a local variable and use it if present, other wise check for a global one. > we could even use <local name="test" value="foobar" /> to initialize > directly yes. > of course I would prefer to have <set .. /> by default for local > variables, and use a <global name="varname" /> but this would break > existing code... I suggest to first introduce the local support, then migrate the gobo build files to use locals and see how it goes. Probably there is still the need for some global variables and for those I think <global...> as you suggest makes sense because it makes things more clear. - Sven |
|
From: Sven E. <sve...@we...> - 2008-02-02 20:49:10
|
Sven Ehrke wrote:
> I just did a grep on all build.eant files for '<unset' within gobo and only found
> two occurrences in 'example/geant/build.eant'. Maybe I forgot in the meanwhile
I forgot to check other .eant files so I checked again. Gobo uses <unset> in
misc/eiffel.eant:
<unset name="xace_format" if="${ISE_5_7}"/>
for example. But I can imagine that it could be solved in a different way
if local variables are used for this.
- Sven
|
|
From: Jocelyn <ei...@dj...> - 2008-02-05 15:39:07
|
Hi all,
* About use of "unset"
I have a few scripts making big use of unset
mainly because local variables are not available, and also .. as
*dirty* trick to avoid creating too many fake targets.
In many place, I also prefer to "unset" variable just in case.
So .. if we have local variables .. and <group /> task
I guess I could stop using unset. But still, as you said, let's keep
it to avoid breaking existing scripts.
* Otherwise, I am working (when I find some time), to add <local/> and
<global/>, to change the <set /> to be smart enough to find out where to
set the values.
In my working copy, I also have
* support for <group /> element, which behave more or less as an inner
<target /> except it does not accept <local/>, <global/>, <argument/>.
* I change code to remove the long if elseif elseif ... end to create
TASK based on xml element name. Now it is using a hash_table of
GEANT_TASK_BUILDER [GEANT_TASK create make end]. This should improve
performance.
And finally, I was thinking of adding an element <option /> at the
<project/> level to be able to set option in the script such as
<option name="verbose" value="true" />
or even
<option name="default_variable_scope" value="global" /> <!-- Current
behavior, and should be the default -->
<option name="default_variable_scope" value="local" />
This brings the idea of introducing a way to say .. in this project, the
variables are local by default. This could be used for transition, in
the same way PHP did with "safe_globals" ... or similar.
I was wondering if this would make sense to create a branch for geant
source code, at least to share my change without breaking trunk
development ?
If not, I might post a patch soon about all those changes, mainly
- more efficient way to create GEANT_TASK given their names.
- locals (I haven't done anything on globals for now)
- group element
-- Jocelyn
On 2/2/2008 21:15 PM, Sven Ehrke wrote:
> Sven Ehrke wrote:
>
>> I just did a grep on all build.eant files for '<unset' within gobo and only found
>> two occurrences in 'example/geant/build.eant'. Maybe I forgot in the meanwhile
>>
>
> I forgot to check other .eant files so I checked again. Gobo uses <unset> in
> misc/eiffel.eant:
>
> <unset name="xace_format" if="${ISE_5_7}"/>
>
> for example. But I can imagine that it could be solved in a different way
> if local variables are used for this.
>
> - Sven
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>
|
|
From: Eric B. <er...@go...> - 2008-02-08 09:56:43
|
Jocelyn wrote: > I was wondering if this would make sense to create a branch for geant > source code, at least to share my change without breaking trunk > development ? So far we didn't use branches in Gobo. Personally I think that the best way to experiment with your changes and to find out whether they break something or not it to commit them in the trunk. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Sven E. <sve...@we...> - 2008-02-11 18:17:13
|
Jocelyn wrote: > Ok, in this case, a big commit is about to come. It seems to me that you forgot to add GEANT_LOCAL_ELEMENT and GEANT_GLOBAL_ELEMENT to svn. - Sven |
|
From: Jocelyn <li...@dj...> - 2008-02-11 19:02:55
|
You are right, there are now added and committed. Sorry for the inconvenience, Jocelyn ps: let me know if this is ok now ... On 2/11/2008 19:16 PM, Sven Ehrke wrote: > Jocelyn wrote: > >> Ok, in this case, a big commit is about to come. >> > > It seems to me that you forgot to add GEANT_LOCAL_ELEMENT and GEANT_GLOBAL_ELEMENT > to svn. > > - Sven > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gobo-eiffel-develop mailing list > gob...@li... > https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop > > > |
|
From: Jocelyn <ei...@dj...> - 2008-02-11 15:29:46
|
> So far we didn't use branches in Gobo. Personally I think that
> the best way to experiment with your changes and to find out
> whether they break something or not it to commit them in the
> trunk.
Ok, in this case, a big commit is about to come.
It includes
- internal changes to create TASK faster (no more huge if elseif
elseif ...on string comparison)
- <local /> to declare a variable as local
for instance: <local name="foo" /> or even by providing a
value right away <local name="foo" value="bar" />
- <global /> to declare a variable as global (this is currently the
default behavior)
for instance: <global name="foo" /> or even by providing a
value right away <global name="foo" value="bar" />
- <group /> to group set of tasks
for instance:
<target name="test" >
<available resource="$file" variable="file_available" />
<group if="$file_available=true">
<echo message="..." />
<copy file="$file" to_file="${file}.bak" />
<exec executable="echo > $file" />
</group>
</target>
You can use the if="..", unless=".." and even dir=".." attribute
on <group />
You can also have nested groups, and so on ...
<target name="test" >
<argument name="backup_dir" />
<argument name="file" />
<global variable="backup_enabled" /><!-- not necessary
for now -->
<local variable="file_available" />
<available resource="$file" variable="file_available" />
<group if="$file_available=true">
<group if="$backup_enabled=true" dir="$backup_dir">
<description>Backup file in $backup_dir
folder.</description>
<echo message="backup $file" />
<copy file="$file" to_file="${file}.bak" />
<echo message="Copied $file to ${file}.bak" />
</group>
<exec executable="echo new content > $file" />
</group>
<!-- no need to unset `file_available' since it is a
local -->
</target>
And this will make geant' scripts cleaner (I hope)
I started the work, to have "locals" as default instead of "globals",
but not yet complete.
Any feedback, comment, bug report will be welcome.
-- Jocelyn
|
|
From: Sven E. <sve...@we...> - 2008-02-11 16:22:37
|
I know it is a bit late now (just saw your commit) but I have mixed feelings about <group>.
What is again the advantage over calling another target?
Jocelyn wrote:
>> So far we didn't use branches in Gobo. Personally I think that
>> the best way to experiment with your changes and to find out
>> whether they break something or not it to commit them in the > trunk.
>
> Ok, in this case, a big commit is about to come.
> It includes - internal changes to create TASK faster (no more huge if
> elseif elseif ...on string comparison)
> - <local /> to declare a variable as local
> for instance: <local name="foo" /> or even by providing a value
> right away <local name="foo" value="bar" />
>
> - <global /> to declare a variable as global (this is currently the
> default behavior)
> for instance: <global name="foo" /> or even by providing aEric Bezault <er...@go...>
> value right away <global name="foo" value="bar" />
>
> - <group /> to group set of tasks
> for instance:
> <target name="test" >
> <available resource="$file" variable="file_available" />
> <group if="$file_available=true">
> <echo message="..." />
> <copy file="$file" to_file="${file}.bak" />
> <exec executable="echo > $file" />
> </group>
> </target>
> You can use the if="..", unless=".." and even dir=".." attribute
> on <group />
>
> You can also have nested groups, and so on ...
>
> <target name="test" >
> <argument name="backup_dir" />
> <argument name="file" />
> <global variable="backup_enabled" /><!-- not necessary
> for now -->
> <local variable="file_available" />
>
> <available resource="$file" variable="file_available" />
> <group if="$file_available=true">
> <group if="$backup_enabled=true" dir="$backup_dir">
> <description>Backup file in $backup_dir
> folder.</description>
> <echo message="backup $file" />
> <copy file="$file" to_file="${file}.bak" />
> <echo message="Copied $file to ${file}.bak" />
> </group>
> <exec executable="echo new content > $file" />
> </group>
> <!-- no need to unset `file_available' since it is a
> local -->
> </target>
>
>
> And this will make geant' scripts cleaner (I hope)
> I started the work, to have "locals" as default instead of "globals",
> but not yet complete.
>
> Any feedback, comment, bug report will be welcome.
> -- Jocelyn
>
>
>
>
|
|
From: Eric B. <er...@go...> - 2008-02-11 16:48:58
|
Sven Ehrke wrote: > I know it is a bit late now (just saw your commit) but I have mixed feelings about <group>. > What is again the advantage over calling another target? One advantage I could see is with local variables. With another target we would have to pass them as arguments, and they would be read-only I guess. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Sven E. <sve...@we...> - 2008-02-11 17:29:17
|
Eric Bezault wrote: > Sven Ehrke wrote: >> I know it is a bit late now (just saw your commit) but I have mixed feelings about <group>. >> What is again the advantage over calling another target? > > One advantage I could see is with local variables. With > another target we would have to pass them as arguments, Right. Especially when there are many which need to be accessed this would be annoying. > and they would be read-only I guess. Good point. I obviously did not think enough about this one. This means that the idea of slowly going away from globals to locals will not work since we cannot return values. So I make another suggestion which I had in mind since a long time. So far I thought it is overkill for geant but just to mention the idea: We could extend the OO view of geant scripts (similar to a Eiffel class) by providing the possibility to add attributes to a script so that it becomes stateful. This way targets (like features in Eiffel) could modify the values of these attributes. It would be necessary to able to create new "objects" of these "scripts" and pass them as arguments for example. This way we could get rid of the globals. But it is certainly some effort involved to implement this. - Sven |
|
From: Sven E. <sve...@we...> - 2008-02-11 17:12:03
|
Jocelyn wrote: > I would say avoid to have zillions of fake targets OK, I understand now. Thanks for the explanation. > I hope my commit is still welcome. Yes, very welcome. I am just checking out the diff. I am not finished yet but one thing which I thought could be done is to attach the local variables directly to it's target instead of having to maintain two stacks (one for the targets and the other one for the locals). Then only the target stack would be needed. What do you think? - Sven |
|
From: Jocelyn <li...@dj...> - 2008-02-11 17:27:52
|
I first did that, adding a field {GEANT_TARGET}.locals: GEANT_VARIABLES
but this doesn't work, since GEANT_TARGET holds static data, when we
need execution data.
I mean, if you call recursively the same target, then you'll have the
locals messed up, since you share the same list of locals for the 2
executions of the same target.
Do you see what I mean ?
for instance
<target name="loc">
<argument name="arg" />
<local name="foo" />
<set name="foo" value="$arg$arg" />
<echo message="1) foo=$foo" />
<geant name="loc" arguments="$foo" unless="$arg=aaaa"
<echo message="2) foo=$foo" />
</target>
doing the solution with locals attached to the instance of GEANT_TARGET,
you would get as output for:
<geant target="loc" arguments="a" />
1) foo=aa
1) foo=aaaa
2) foo=aaaa
2) foo=aaaa
when you expect
1) foo=aa
1) foo=aaaa
2) foo=aaaa
2) foo=aa
In fact, what would be nicer is to have a GEANT_TARGET_STACK .. which
would hold the arguments, and locals stacks.
-- Jocelyn.
On 2/11/2008 18:11 PM, Sven Ehrke wrote:
> Jocelyn wrote:
>
>> I would say avoid to have zillions of fake targets
>>
>
> OK, I understand now. Thanks for the explanation.
>
>
>> I hope my commit is still welcome.
>>
>
> Yes, very welcome. I am just checking out the diff. I am not
> finished yet but one thing which I thought could be done
> is to attach the local variables directly to it's target instead
> of having to maintain two stacks (one for the targets and the other
> one for the locals). Then only the target stack would be needed.
> What do you think?
>
> - Sven
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>
|
|
From: Sven E. <sve...@we...> - 2008-02-11 17:44:23
|
Jocelyn wrote:
> I first did that, adding a field {GEANT_TARGET}.locals: GEANT_VARIABLES
> but this doesn't work, since GEANT_TARGET holds static data, when we
> need execution data.
>
> I mean, if you call recursively the same target, then you'll have the
> locals messed up, since you share the same list of locals for the 2
> executions of the same target.
> Do you see what I mean ?
Right. Now I remember that I had the same issue when I implemented argument support.
Somehow I had the feeling that a new target object is created when <geant> calls
a target which is not the case and this causes the problem.
> In fact, what would be nicer is to have a GEANT_TARGET_STACK .. which
> would hold the arguments, and locals stacks.
I agree.
- Sven
|
|
From: Sven E. <sve...@we...> - 2008-02-11 19:44:25
|
Jocelyn wrote: > You are right, there are now added and committed. > > Sorry for the inconvenience, > Jocelyn > ps: let me know if this is ok now ... Yes. Compiles fine now. Thanks. - Sven |
|
From: Jocelyn <li...@dj...> - 2008-02-12 09:35:47
|
I added the following wiki page on sourceforge:
http://gobo-eiffel.wiki.sourceforge.net/Tool_Geant
Almost empty for now, but we could drop some idea on it to improve
collaboration on geant's source code.
-- Jocelyn
|
|
From: Eric B. <er...@go...> - 2008-02-14 11:07:13
|
Jocelyn wrote: > > So far we didn't use branches in Gobo. Personally I think that > > the best way to experiment with your changes and to find out > > whether they break something or not it to commit them in the > > trunk. > > Ok, in this case, a big commit is about to come. When committing new functionalities, you have to make sure to update the file $GOBO/History.txt as well. Thanks. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-02-08 10:02:32
|
Sven Ehrke wrote: > Yes, I am still around :-) ;-) In case you are not aware of them yet, there are some issues assigned to you in the Tracker: https://sourceforge.net/tracker/index.php?func=detail&aid=1837208&group_id=24591&atid=381937 https://sourceforge.net/tracker/index.php?func=detail&aid=1882794&group_id=24591&atid=381937 -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Sven E. <sve...@we...> - 2008-02-08 15:58:21
|
Eric Bezault wrote: > In case you are not aware of them yet, there are some issues > assigned to you in the Tracker: > > https://sourceforge.net/tracker/index.php?func=detail&aid=1837208&group_id=24591&atid=381937 > https://sourceforge.net/tracker/index.php?func=detail&aid=1882794&group_id=24591&atid=381937 > Hi Eric, I will have a look at them. Just one (different) question: When I was compiling geant for example just recently (on linux) using gcc and gec it took me about 5-6 minutes on my quite dated computer. Then I downloaded ISE Eiffel 6.1 but noticed that 1G of memory is recommended (I have only 512MB) and when I tried to install it I noticed that the space on my windows drive does not have enough free space anymore to complete the installation (although selected a different drive for the installation). I soon have to buy a new computer anyway and then these problems should be gone but do you have a recommendation on how to get a speed improvement for compilation in the meanwhile? My next try will be to download the linux version of ISE Eiffel and see how that works. - Sven |
|
From: Eric B. <er...@go...> - 2008-02-08 16:20:59
|
Sven Ehrke wrote: > I will have a look at them. Just one (different) question: When I was compiling geant for example > just recently (on linux) using gcc and gec it took me about 5-6 minutes on my quite dated > computer. Then I downloaded ISE Eiffel 6.1 but noticed that 1G of memory is recommended (I have > only 512MB) and when I tried to install it I noticed that the space on my windows drive does > not have enough free space anymore to complete the installation (although selected a different drive > for the installation). I soon have to buy a new computer > anyway and then these problems should be gone but do you have a recommendation on how to get a speed > improvement for compilation in the meanwhile? You can try to compile in non-finalized mode: geant compile_debug_ge It will compile the generated C code without the -O2 option, which might speed up the C compilation. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Sven E. <sve...@we...> - 2008-02-08 16:50:55
|
Eric Bezault wrote: > You can try to compile in non-finalized mode: > > geant compile_debug_ge > > It will compile the generated C code without the -O2 option, > which might speed up the C compilation. > That's much better. Thank you. - Sven |
|
From: Sven E. <sve...@we...> - 2008-02-09 09:34:01
|
Eric Bezault wrote: > In case you are not aware of them yet, there are some issues > assigned to you in the Tracker: > > https://sourceforge.net/tracker/index.php?func=detail&aid=1837208&group_id=24591&atid=381937 > https://sourceforge.net/tracker/index.php?func=detail&aid=1882794&group_id=24591&atid=381937 > The first one: https://sourceforge.net/tracker/index.php?func=detail&aid=1837208&group_id=24591&atid=381937 should be fixed now. I replaced the call to routine `string_tokens' with a `ST_SPLITTER.split_greedy' call. Although this is a bug fix it is possible that it break scripts which made use or worked around this behavior. I will add a note to History.txt. - Sven |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X