From: Howard T. <how...@di...> - 2009-08-13 23:20:57
|
Hi Eric & Wolfgang, I would welcome a move to using Git as the SCM system for Gobo. I see that there is a useful page on wikipedia about git, with reference to Windows implementations: http://en.wikipedia.org/wiki/Git_(software)#Implementation There is also an excellent website detailing how to use git ... http://progit.org/ Regarding my own project: I have recently, I think [famous last words], reached stability with my GC when compiling with my modified 'gec', albeit that I have only so far tested it on Linux. A Win32 version should be a fairly trivial adaptation, as it should be no more than adaptation of a single, smallish, routine. I am also thinking of renaming my project as 'guide', the Gobo-eiffel Users' Integrated Development Environment, from 'edp', the Eiffel Developers' Project. Although there a few classes [from other sources] that are LGPL, nearly all code that does not already derive from gobo, is EFFLv2 or MIT. I am very interested to hear about the introspection and debugger code, as I need such facilities for my intended future coding. One of the areas of the code generator that I intend to alter is the polymorphic dispatch implementation, for two reasons: Firstly for rapid re-compilation, I want to be able to generate an initial code package as an executable stub with dynamic library, where libraries register their routine addresses with the runtime, with subsequent partial re-compilation code generated as an additional dynamic library whose routines override the registered routines of the initial library. This requires that routine dispatch be done using a tree data structure, of some sort ... Secondly, I envisage that it should be possible, as with Java and other languages [mostly interpreted ..], to dynamically add class libraries to an executable system, where such libraries have been packaged, [compiled or otherwise verified against] to be compatible with classes already in the current system. That would also require that the dispatch to reachable routines be dynamically extendable. I am adapting my work on the Eiffel GUI toolkit derived from the Fox-toolkit to use the Vision2 interface, providing an X11/Win32 all Eiffel GUI Toolkit, which has its advantages ... I am working toward using LLVM as the basis for code generation for native Eiffel routines, initially to emit LLVM assembler with llvm-as invocation, and with the possibility [much] later of emitting machine code directly. I think using Git would assist in cooperation between myself and other gobo-eiffel contributors and developers. Regards, Howard Thomson -- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein |
From: Jocelyn <ei...@dj...> - 2009-08-14 07:40:50
|
Note that, I first learn about git with this document: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Then for svn user, this doc can help http://git.or.cz/course/svn.html And of course the official git web site, with all its links http://git-scm.com/ including: http://book.git-scm.com/ -- Jocelyn |
From: Jocelyn <ei...@dj...> - 2009-08-14 08:01:09
|
In a previous post, Eric said the git tools for Windows were not very attractive. And I agree they are not yet at the same level as TortoiseSVN. However, personally I am using on Windows - msysGit http://code.google.com/p/msysgit/downloads/list - for the gui ... either git gui, or gitk which come with any git setup but most often, I use Git Extensions (http://sourceforge.net/projects/gitextensions/) which is good enough for my need. - I tried to use TortoiseGIT (http://code.google.com/p/tortoisegit/) but I was unable to make it work on my Win XP Pro 64bits (too bad, since I am a TortoiseSVN user, and I really like it) For my usage, the Git Extensions GUI is good enough, and when I need to do complicated operation (or even simple) I use (very often) git in command line (as I do with svn) Indeed git is much more powerful than svn, but it is also more complicated (in addition the command name are not always very intuitive), thus I find it often easier to use command line to do exactly what I want. Also the branching is great, but you have to get used to it, otherwise you waste time figuring out how to best deal with it (in final, I learnt that the best solution is to ALWAYS work on its own branch, and merge with the master/trunk when ready to commit) And at the end, I agree that git on Windows is much slower than git on linux (especially git svn), but it is ok There are other alternative to git, such as mercurial, but I don't really know them. It seems like git is the most popular (due to linux repo I guess). I heard there is a native client for Windows in development, but I don't know where to find it ... Maybe before going for git, Gobo's dev could use git-svn as following > mkdir gobo.git > cd gobo.git Initialize your local repository based on the gobo's subversion repo > git svn init https://gobo-eiffel.svn.sourceforge.net/svnroot/gobo-eiffel/gobo/trunk fetch the commits from revision 6555 (for instance this one which is the gobo 3.9 release) note, you can also git clone the entire gobo's repository .. but it is longer > git fetch -r6555 now, get sync with trunk@HEAD > git svn rebase If you want, to do some modification, I would recommend to work on your own branch (I use my login for that "jfiat") > git checkout -b jfiat Then you can work on your own branch ... as with any git repo, so check the git tutorials to know how to use git. This includes locally commits (that's such a great feature, I wish subversion implement it some day). And when ever you are ready to commit and "push" to the official gobo's svn repository, you switch back to the master (which represent the trunk in subversion) > git checkout master Eventually sync with head with: git svn rebase Merge the changes from your branch > git merge --squash jfiat The --squash is used to merge your branch to the master .. BUT without doing any commit, then you can commit your change in only one commit. I tried without the "--squash", and it re-creates all the commits done in my branch into the master. This could be useful, if you want to "replay" your work in the master for history... You can then commit your change > git commit -a -m "Merge jfiat's branch into the master branch to implement feature X" And finally, you push/send your changes to the svn repo > git svn dcommit Check the following links for use cases: - http://techbase.kde.org/Development/Tutorials/Git - http://live.gnome.org/GitForGnomeDevelopers So this way to do, can be a temporary solution to use git with Gobo. Then decide with gobo's developers, if git is the right tool for gobo's repo. (Note that using git with real git repositories, is easier and more fun, but .. git-svn is a solution to try, and even work) -- Jocelyn Howard Thomson wrote: > > > > Hi Eric & Wolfgang, > > > > I would welcome a move to using Git as the SCM system for Gobo. > > > > I see that there is a useful page on wikipedia about git, with > > reference to Windows implementations: > > > > http://en.wikipedia.org/wiki/Git_(software)#Implementation > > > > There is also an excellent website detailing how to use git ... > > > > http://progit.org/ > > > > <snip>....</snip> > > > > I think using Git would assist in cooperation between myself and other > > gobo-eiffel contributors and developers. > > > > Regards, > > > > Howard Thomson > > > |
From: Jocelyn <ei...@dj...> - 2009-08-14 09:01:31
|
This message is a side note about what Eric said about me, Jocelyn, using git for void-safe version of Gobo. This message has nothing to do with Gobo, and is focused on special usage of git and subversion. So yes, I am using git for void-safe version of Gobo (http://github.com/jocelyn/void-safe-gobo-eiffel/tree/master), but my use of git for this is unusual. I use it to have a double SCM control on gobo's and ise's classes related to Gobo. To be short, I use git AND svn on the same files to be able to local commit on the git repository (hosted on github), and also being able to diff using svn diff on the ise and gobo's svn repository. Indeed, when you svn checkout https://svn.eiffel.com/eiffelstudio/trunk/Src/library/gobo you end up with gobo/many files gobo/override gobo/src gobo/svn and gobo/* are parts of eiffelstudio's svn repository while gobo/svn/* are part of the gobo's svn repository (we use svn:externals for that purpose). And my git repository covers gobo/* AND gobo/svn/* files This can be seens as a little trick, but it is really nice to have local commits, and still be able to diff easily with gobo's subversion repository. However, this is possible, but this is not that convenient when there are big commits on the gobo's trunk. Since there are many conflict to resolve in order to keep synchronized with gobo's trunk@HEAD (probably, I could have used git svn, and git sub modules, but at that time, I was using git for the very first time) -- Jocelyn Jocelyn wrote: > In a previous post, Eric said the git tools for Windows were not very > attractive. > And I agree they are not yet at the same level as TortoiseSVN. > > However, personally I am using on Windows > - msysGit http://code.google.com/p/msysgit/downloads/list > - for the gui ... either git gui, or gitk which come with any git setup > but most often, I use Git Extensions > (http://sourceforge.net/projects/gitextensions/) which is good enough > for my need. > - I tried to use TortoiseGIT (http://code.google.com/p/tortoisegit/) > but I was unable to make it work on my Win XP Pro 64bits (too bad, since > I am a TortoiseSVN user, and I really like it) > > For my usage, the Git Extensions GUI is good enough, and when I need to > do complicated operation (or even simple) I use (very often) git in > command line (as I do with svn) > Indeed git is much more powerful than svn, but it is also more > complicated (in addition the command name are not always very > intuitive), thus I find it often easier to use command line to do > exactly what I want. > Also the branching is great, but you have to get used to it, otherwise > you waste time figuring out how to best deal with it (in final, I learnt > that the best solution is to ALWAYS work on its own branch, and merge > with the master/trunk when ready to commit) > > And at the end, I agree that git on Windows is much slower than git on > linux (especially git svn), but it is ok > > There are other alternative to git, such as mercurial, but I don't > really know them. It seems like git is the most popular (due to linux > repo I guess). > I heard there is a native client for Windows in development, but I don't > know where to find it ... > > Maybe before going for git, Gobo's dev could use git-svn as following > > mkdir gobo.git > > cd gobo.git > Initialize your local repository based on the gobo's subversion repo > > git svn init > https://gobo-eiffel.svn.sourceforge.net/svnroot/gobo-eiffel/gobo/trunk > fetch the commits from revision 6555 (for instance this one which is > the gobo 3.9 release) > note, you can also git clone the entire gobo's repository .. but it is > longer > > git fetch -r6555 > now, get sync with trunk@HEAD > > git svn rebase > > If you want, to do some modification, I would recommend to work on your > own branch (I use my login for that "jfiat") > > git checkout -b jfiat > > Then you can work on your own branch ... as with any git repo, so check > the git tutorials to know how to use git. This includes locally commits > (that's such a great feature, I wish subversion implement it some day). > > And when ever you are ready to commit and "push" to the official gobo's > svn repository, you switch back to the master (which represent the trunk > in subversion) > > git checkout master > Eventually sync with head with: git svn rebase > > Merge the changes from your branch > > git merge --squash jfiat > The --squash is used to merge your branch to the master .. BUT without > doing any commit, then you can commit your change in only one commit. > I tried without the "--squash", and it re-creates all the commits done > in my branch into the master. This could be useful, if you want to > "replay" your work in the master for history... > > You can then commit your change > > git commit -a -m "Merge jfiat's branch into the master branch > to implement feature X" > > And finally, you push/send your changes to the svn repo > > git svn dcommit > > Check the following links for use cases: > - http://techbase.kde.org/Development/Tutorials/Git > - http://live.gnome.org/GitForGnomeDevelopers > > So this way to do, can be a temporary solution to use git with Gobo. > Then decide with gobo's developers, if git is the right tool for gobo's > repo. > > (Note that using git with real git repositories, is easier and more fun, > but .. git-svn is a solution to try, and even work) > > -- Jocelyn > > Howard Thomson wrote: > > >>> Hi Eric & Wolfgang, >>> >>> I would welcome a move to using Git as the SCM system for Gobo. >>> >>> I see that there is a useful page on wikipedia about git, with >>> reference to Windows implementations: >>> >>> http://en.wikipedia.org/wiki/Git_(software)#Implementation >>> >>> There is also an excellent website detailing how to use git ... >>> >>> http://progit.org/ >>> >>> <snip>....</snip> >>> >>> I think using Git would assist in cooperation between myself and other >>> gobo-eiffel contributors and developers. >>> >>> Regards, >>> >>> Howard Thomson >>> >>> >> >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gobo-eiffel-develop mailing list > gob...@li... > https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop > > > |
From: Wolfgang J. <wj...@so...> - 2009-08-14 17:09:17
Attachments:
in_type.html
|
Hi Howard, Howard Thomson wrote: > > Hi Eric & Wolfgang, > > I would welcome a move to using Git as the SCM system for Gobo. > > I see that there is a useful page on wikipedia about git, with > reference to Windows implementations: > > http://en.wikipedia.org/wiki/Git_(software)#Implementation > > There is also an excellent website detailing how to use git ... > > http://progit.org/ > > Regarding my own project: > > I have recently, I think [famous last words], reached stability with my > > GC when compiling with my modified 'gec', albeit that I have only so > > far tested it on Linux. A Win32 version should be a fairly trivial > adaptation, > > as it should be no more than adaptation of a single, smallish, routine. > > I am also thinking of renaming my project as 'guide', > > the Gobo-eiffel Users' Integrated Development Environment, > > from 'edp', the Eiffel Developers' Project. Although there a few > > classes [from other sources] that are LGPL, nearly all code that does > > not already derive from gobo, is EFFLv2 or MIT. > > I am very interested to hear about the introspection and debugger code, as > > I need such facilities for my intended future coding. > Description of introspection and debugger code may be really large. Here, a short outline. Descendant classes of ET_C_GENERATOR (extending the work of that class) generate a description of the system to be compiled for use during runtime: they extract information from objects of types ET_DYNAMIC_SYSTEM, ET_DYNAMIC_TYPE etc. and puts the information into objects of types ET_IN_SYSTEM, ET_IN_TYPE etc. The resulting description is put onto C code (additional to the usual code) using a special output mode of the persistence closure classes. This code is C compiled, and the system description is available during runtime (after a few adaptations at startup) as Eiffel objects. More precisely, the root object of the description is provided by an external routine that fetches the object's address from C code, the other objects are then recursively available by Eiffel calls on the root object. The attachment contains the interface of an example class to show what kind of information is available during runtime. Introspection for persistence closure and debugging differs in the amount of information in the system description. For example, the debugger needs information about routines but the persistence closure does not. Moreover, in case of debugging many calls to the debugger have been inserted into the "normal" code. The debugger then decides whether switching into interactive mode (say a breakpoint has been reached) or returning immediately to the caller. Historically, the work started with the persistence closure. I soon realized the introspection is a necessary prerequisite. Then, having introspection, the idea was to utilize it also for other purposes, e.g. for the "print" command of a debugger. So, the debugger has been developed. The approach to implement the persistence closure etc. may be emphasized as follows: The Eiffel compiler is written in Eiffel. So, why not also implementing the Eiffel runtime system in Eiffel? BTW, does your GC mark/seep or move/compress? In the former case, object marking may also be interesting when building the persistence closure. Currently, the already seen objects are registered in a DS_HASH_TABLE[INTEGER,POINTER]. This is inconvenient because of the POINTER keys. Marking like the GC would be an interesting alternative. > One of the areas of the code generator that I intend to alter is the > polymorphic > > dispatch implementation, for two reasons: > > Firstly for rapid re-compilation, I want to be able to generate an > initial code package as > > an executable stub with dynamic library, where libraries register > their routine addresses > > with the runtime, with subsequent partial re-compilation code > generated as an additional > > dynamic library whose routines override the registered routines of the > initial library. This > > requires that routine dispatch be done using a tree data structure, of > some sort ... > > Secondly, I envisage that it should be possible, as with Java and > other languages [mostly interpreted ..], > > to dynamically add class libraries to an executable system, where such > libraries have been packaged, > > [compiled or otherwise verified against] to be compatible with classes > already in the current system. > > That would also require that the dispatch to reachable routines be > dynamically extendable. > This sounds very interesting. Extendibility of a program, dynamic linking etc. seems to be necessary for contemporary software (otherwise, Eiffel will never have a chance). > > I am adapting my work on the Eiffel GUI toolkit derived from the > Fox-toolkit to use the Vision2 interface, > > providing an X11/Win32 all Eiffel GUI Toolkit, which has its > advantages ... > > I am working toward using LLVM as the basis for code generation for > native Eiffel routines, initially to emit > > LLVM assembler with llvm-as invocation, and with the possibility > [much] later of emitting machine code directly. > > I think using Git would assist in cooperation between myself and other > gobo-eiffel contributors and developers. > > Regards, > > Howard Thomson > > -- > > "Only two things are infinite, the universe and human stupidity, > > and I'm not sure about the former." -- Albert Einstein > -- Dr. Wolfgang Jansen University of Potsdam, Germany Institute of Computer Science Tel: +49 331 / 977 3047 mailto: wj...@so... |
From: Howard T. <how...@di...> - 2009-08-14 19:45:00
|
Hi Wolfgang, On Friday 14 August 2009, you wrote: > > The approach to implement the persistence closure etc. > may be emphasized as follows: > The Eiffel compiler is written in Eiffel. > So, why not also implementing the Eiffel runtime system in Eiffel? > I considered writing the Eiffel GC substantially in Eiffel, and I may well transliterate much of the new GC code into Eiffel at some point, once we have [or I understand ... !] some means of either separately generating library code [with Gobo], or some means of ensuring that all of the GC classes are 'in' the system; actually not too difficult ... I think Gobo's ability to inline code needs to be enhanced before it makes sense to do that. > BTW, does your GC mark/seep or move/compress? In the former case, > object marking may also be interesting when building the persistence > closure. > Currently, the already seen objects are registered > in a DS_HASH_TABLE[INTEGER,POINTER]. This is inconvenient > because of the POINTER keys. Marking like the GC would be an > interesting alternative. It is currently a simple mark/sweep, non-moving, but precise collector, so the ability to move / compact could be added later. Correctness is much more important, and there are still some code generation changes that need to be made to ensure that all references are visible to the GC at any point where it may be invoked. > > > One of the areas of the code generator that I intend to alter is the > > polymorphic > > > > dispatch implementation, for two reasons: > > > > Firstly for rapid re-compilation, I want to be able to generate an > > initial code package as > > > > an executable stub with dynamic library, where libraries register > > their routine addresses > > > > with the runtime, with subsequent partial re-compilation code > > generated as an additional > > > > dynamic library whose routines override the registered routines of the > > initial library. This > > > > requires that routine dispatch be done using a tree data structure, of > > some sort ... > > > > Secondly, I envisage that it should be possible, as with Java and > > other languages [mostly interpreted ..], > > > > to dynamically add class libraries to an executable system, where such > > libraries have been packaged, > > > > [compiled or otherwise verified against] to be compatible with classes > > already in the current system. > > > > That would also require that the dispatch to reachable routines be > > dynamically extendable. > > > This sounds very interesting. Extendibility of a program, dynamic > linking etc. seems to be > necessary for contemporary software (otherwise, Eiffel will never have a > chance). > > I think it is essential ... Regards Howard -- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein |
From: Wolfgang J. <wj...@so...> - 2009-08-15 16:13:39
|
Howard Thomson wrote: > > Hi Wolfgang, > > On Friday 14 August 2009, you wrote: > > > > > > The approach to implement the persistence closure etc. > > > may be emphasized as follows: > > > The Eiffel compiler is written in Eiffel. > > > So, why not also implementing the Eiffel runtime system in Eiffel? > > > > > I considered writing the Eiffel GC substantially in Eiffel, and I may > well transliterate much > > of the new GC code into Eiffel at some point, once we have [or I > understand ... !] some means > > of either separately generating library code [with Gobo], or some > means of ensuring that all > > of the GC classes are 'in' the system; actually not too difficult ... > > I think Gobo's ability to inline code needs to be enhanced before it > makes sense to do that. > May it help you to re-use my introspection code? It sees all references on stack, all global references (i.e. values of once functions) and, starting on these references, all references on heap. The debugger uses this for checkpointing. A critical point in the GC case may be to make the things on stack visible. In case of the debugger, making stack variables visible is necessary for printing the variables, using their visibility for checkpointing is a by-product. But additional code is needed (run at most once per routine) to get the addresses. The additional code may be considered too heavy for every days work. -- Dr. Wolfgang Jansen University of Potsdam, Germany Institute of Computer Science Tel: +49 331 / 977 3047 mailto: wj...@so... |
From: Howard T. <how...@di...> - 2009-08-15 22:12:59
|
Hi Wolfgang, On Saturday 15 August 2009, you wrote: > May it help you to re-use my introspection code? > It sees all references on stack, all global references (i.e. values of > once functions) > and, starting on these references, all references on heap. Yes, it would be useful [necessary ...] to ensure that there is one way to make available, to both the GC and debugger, all relevant info. The specific code generation case that I was referring to is where C code is generated with two or more arguments to a routine [excluding Current], each of which is a memory-allocating funtion that returns a reference [where the return value is the only extant reference], and therefore the GC needs to have access to a value that is not a declared C variable. In C terms: void * f_allocate() { /* This routine allocates memory [create ...] and may instigate a GC collection */ return(GC_alloc_memory(...)); } void called_routine(void *a_Current, void *a1, void *a2) { /* do something [not relevant] with arguments */ xxx = a1; yyy = a2; } If the routine call: called_routine(Current, f_allocate(), f_allocate()); occurs in the generated C code then the GC, if invoked from the f_allocate call that occurs second, then the one and only reference to the memory returned by the first f_allocate call is only accessible via a C compiler unnamed temporary. Does your stack tracing code track, precisely, i.e. not conservatively, such compiler temporaries ? Do you develop on Windows or Linux ? If you want to look at [an earlier version of] my code, it is available at: www.ashford-ht.vm.bytemark.co.uk as a compressed tar download, admittedly more suitable for Linux developers ... Regards, Howard > The debugger uses this for checkpointing. > A critical point in the GC case may be to make the things on stack > visible. In case of the debugger, making stack variables visible > is necessary for printing the variables, using their visibility > for checkpointing is a by-product. But additional code is needed > (run at most once per routine) to get the addresses. The additional code > may be considered too heavy for every days work. > -- Howard Thomson -- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein |
From: Wolfgang J. <wj...@so...> - 2009-08-17 14:02:04
|
Hi Howard, > Hi Wolfgang, > > On Saturday 15 August 2009, you wrote: > > > May it help you to re-use my introspection code? > > > It sees all references on stack, all global references (i.e. values of > > > once functions) > > > and, starting on these references, all references on heap. > > Yes, it would be useful [necessary ...] to ensure that there is one > way to make > > available, to both the GC and debugger, all relevant info. > > The specific code generation case that I was referring to is where C > code is generated > > with two or more arguments to a routine [excluding Current], each of > which is a memory-allocating > > funtion that returns a reference [where the return value is the only > extant reference], and therefore > > the GC needs to have access to a value that is not a declared C variable. > > In C terms: > > void * f_allocate() { > > /* This routine allocates memory [create ...] and may instigate a GC > collection */ > > return(GC_alloc_memory(...)); > > } > > void called_routine(void *a_Current, void *a1, void *a2) { > > /* do something [not relevant] with arguments */ > > xxx = a1; > > yyy = a2; > > } > > If the routine call: > > called_routine(Current, f_allocate(), f_allocate()); > > occurs in the generated C code then the GC, if invoked from the > f_allocate call that occurs second, then > > the one and only reference to the memory returned by the first > f_allocate call is only accessible via a > > C compiler unnamed temporary. > > Does your stack tracing code track, precisely, i.e. not > conservatively, such compiler temporaries ? > No yet. Printing arguments and local variables does not need this and checkpointing not either since the call to the debugger happens, currently, always before an instruction, in particular before the temporaries are set to new values. In other words, in case of x := f(g(y)) there is one break at the beginning of the line but not before the calls to functions `f' and `g'. Things will be different if the debugger is called also before function calls (planned in future). The function arguments are often temporaries and need to be stored by checkpointing (or checkpointing must be allowed in front of instructions only). Anyway, I will think about the problem how to extract the information about temporaries from the compiler classes (putting the information to introspection classes and making it available during runtime is easy). > > Do you develop on Windows or Linux ? > On Sun Solaris, a Unix variant. > > If you want to look at [an earlier version of] my code, it is > available at: > > www.ashford-ht.vm.bytemark.co.uk as a compressed tar download, > admittedly more suitable for Linux developers ... > > Thanks, I got the sources and the Linux version. WJ PS: Below is the (slightly simplified) initial part of C code of STRING_8.append as generated for debugging. 1 void T17f42(GE_ZS* ac, T0* C, T0* a1) 2 { 3 GE_ZS tc = {0,0,ac}; 4 T1 t1; 5 T6 t2; 6 T0* t3; 7 T6 l1 = 0; 8 T6 l2 = 0; 9 T6 l3 = 0; 10 static T0* f = (T0*)0; 11 if (!f) { 12 T82f77(&tc, (T0*)GE_zrts, 17, 1) 13 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&C-(size_t)&tc, 0) 14 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&a1-(size_t)&tc, 1) 15 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l3-(size_t)&tc, 3) 16 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l2-(size_t)&tc, 4) 17 T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l1-(size_t)&tc, 5) 18 } 19 tc.routine = f; 20 GE_zpos(&tc, 655, 0); 21 l2 = (((T17*)(GE_void(a1)))->a2); 22 .... 23 } Line 1 : `ac' is the stack descriptor of the caller; type GE_ZS is a C struct, not Eiffel Line 3 : `tc' is the stack descriptor of the current routine (`ac', `tc' are re-used from GOBO's code tracing) Line 10: `f' is a pointer to an IN_ROUTINE object Line 12: `f' is set by the object describing the current routine; GE_zrts is the root introspection object (global variable) Line 13 .. 17: offsets of the local variables relative to `tc' are set in `f'; more lines are needed if temporary variables are of interest. Line 19: set `f' in stack descriptor Line 20: call debugger with stack descriptor, source line number 655 and reason of break Other uses of routine descriptors (say by GC) will need the additional code of lines 1, 3, 10, 12, 13 .. 17 (as many as needed), 19. After that `tc' is ready and detailed information may be extracted (as done by the debugger in line 20). Instead of the additional argument `ac' a global pointer to the top most stack descriptor might be used. -- Dr. Wolfgang Jansen University of Potsdam, Germany Institute of Computer Science Tel: +49 331 / 977 3047 mailto: wj...@so... |
From: Jann R. <roe...@et...> - 2009-08-28 14:11:44
|
Hello, I have two problems with the gobo XML library: 1. {XM_NAMESPACE}.make seems to miss the precondition a_prefix /= Void , or there is a bug in {XM_XMLNS_GENERATOR}.on_attribute line "elseif is_implicit (a_prefix)" since if a_prefix is Void a Void call will occur in is_implicit 2. How can I influence the output generated by the pretty printer? For example I'd like it not to add the prefix to every tag and attribute. <tag id="2"> instead of <prefix:tag prefix:id="2"> Also I'd like it to use the short form for tags when possible: <tag id="2"/> instead of <tag id="2"></tag> Is this possible somehow or will I have to write my own pretty printer? Thanks, Jann |
From: Colin P. A. <co...@co...> - 2009-08-28 14:19:35
|
>>>>> "Jann" == Jann Röder <roe...@et...> writes: Jann> Hello, I have two problems with the gobo XML library: Jann> 1. {XM_NAMESPACE}.make seems to miss the precondition Jann> a_prefix /= Void , or there is a bug in Jann> {XM_XMLNS_GENERATOR}.on_attribute line "elseif is_implicit Jann> (a_prefix)" since if a_prefix is Void a Void call will occur Jann> in is_implicit I'll leave that for Franck to answer. Jann> 2. How can I influence the output generated by the pretty Jann> printer? For example I'd like it not to add the prefix to Jann> every tag and attribute. Jann> <tag id="2"> instead of <prefix:tag prefix:id="2"> Jann> Also I'd like it to use the short form for tags when Jann> possible: Jann> <tag id="2"/> instead of <tag id="2"></tag> Jann> Is this possible somehow or will I have to write my own Jann> pretty printer? There is an XSLT-inspired (*) serializer that you can use if you want full control over the output. See http://www.gobosoft.com/eiffel/gobo/xml/xslt/xslt_serializer.html . It's actually the serializer used by the Gobo XSLT library, but you do not need to run an XSLT transformation to use it. -- Colin Adams Preston Lancashire |
From: Colin P. A. <co...@co...> - 2009-08-28 14:24:57
|
>>>>> "Jann" == Jann Röder <roe...@et...> writes: Jann> For example I'd like it not to add the prefix to Jann> every tag and attribute. Jann> <tag id="2"> instead of <prefix:tag prefix:id="2"> The two are not equivalent, as attributes are never in the default namespace. Instead they are in the per-element namespace. I.e. in the first case, id is in a different namespace from tag (assuming you have a default namespace declaration in scope). In the second case, they are both in the same namespace. -- Colin Adams Preston Lancashire |
From: Jann R. <roe...@et...> - 2009-08-28 15:01:00
|
Colin Paul Adams schrieb: >>>>>> "Jann" == Jann Röder <roe...@et...> writes: > > Jann> For example I'd like it not to add the prefix to > Jann> every tag and attribute. > > Jann> <tag id="2"> instead of <prefix:tag prefix:id="2"> > > The two are not equivalent, as attributes are never in the default > namespace. Instead they are in the per-element namespace. I.e. in the > first case, id is in a different namespace from tag (assuming you have > a default namespace declaration in scope). In the second case, they > are both in the same namespace. Ok got it. I just put everything in the same namespace, since the namespace argument must not be Void. Now I put everything except the root node in the default namespace and the prefixes disappeared. It would be nice if you could pass Void as the namespace argument if you want to put the element into the default namespace. Jann |
From: Jann R. <roe...@et...> - 2009-09-03 17:18:41
Attachments:
tags.patch
|
Hi, I wrote a patch for the XML pretty printer to make it use the short form for tags that don't have content or children, i.e. <tag/> instead of <tag></tag> . See attachment. I also noticed, that the pretty printer does not output the XML descriptor (this: <?xml version="1.0" ?>). I'm not sure what's the best way to fix this. Simply adding code in the on_xml_descriptor feature doesn't work because it is never called, or I don't know what to do to have it called. Anyway in the meantime I'd be glad about some feedback regarding my patch. Jann |
From: Eric B. <er...@go...> - 2009-09-03 17:34:35
|
Hi Jann, Jann Röder wrote: > I wrote a patch for the XML pretty printer to make it use the short form > for tags that don't have content or children, i.e. <tag/> instead of > <tag></tag> . > See attachment. > > I also noticed, that the pretty printer does not output the XML > descriptor (this: <?xml version="1.0" ?>). I'm not sure what's the best > way to fix this. Simply adding code in the on_xml_descriptor feature > doesn't work because it is never called, or I don't know what to do to > have it called. > > Anyway in the meantime I'd be glad about some feedback regarding my patch. It may take a few days before your patch makes it way in the repository because I'm currently converting the repository to Git. I'll let XML experts give feedback on your patch if they have something to say. But in the meantime, can you please add header comments to the features `last_call_was_start_tag_finish' and `close_tag_buffered'? Thanks. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Colin A. <col...@go...> - 2009-09-03 17:49:57
|
I would say this might break existing programs (if anyone is using this to write legacy xhtml, for instance, for sending to old browsers). Perhaps consult on gobo-users list first? 2009/9/3 Jann Röder <roe...@et...>: > Hi, > I wrote a patch for the XML pretty printer to make it use the short form for > tags that don't have content or children, i.e. <tag/> instead of <tag></tag> > . > See attachment. > > I also noticed, that the pretty printer does not output the XML descriptor > (this: <?xml version="1.0" ?>). I'm not sure what's the best way to fix > this. Simply adding code in the on_xml_descriptor feature doesn't work > because it is never called, or I don't know what to do to have it called. > > Anyway in the meantime I'd be glad about some feedback regarding my patch. > > Jann > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gobo-eiffel-develop mailing list > gob...@li... > https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop > > -- Colin Adams Preston, Lancashire, ENGLAND |
From: Jocelyn <ei...@dj...> - 2009-09-03 19:13:02
|
I haven't looked at the patch, but it might be easy to support both behavior with short tag <foo/> and <foo></foo> using a boolean attribute, or flag for the executable. This way, this won't break existing programs Colin Adams wrote: > I would say this might break existing programs (if anyone is using > this to write legacy xhtml, for instance, for sending to old > browsers). Perhaps consult on gobo-users list first? > > 2009/9/3 Jann Röder <roe...@et...>: > >> Hi, >> I wrote a patch for the XML pretty printer to make it use the short form for >> tags that don't have content or children, i.e. <tag/> instead of <tag></tag> >> . >> See attachment. >> >> I also noticed, that the pretty printer does not output the XML descriptor >> (this: <?xml version="1.0" ?>). I'm not sure what's the best way to fix >> this. Simply adding code in the on_xml_descriptor feature doesn't work >> because it is never called, or I don't know what to do to have it called. >> >> Anyway in the meantime I'd be glad about some feedback regarding my patch. >> >> Jann >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> gobo-eiffel-develop mailing list >> gob...@li... >> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop >> >> >> > > > > |
From: Eric B. <er...@go...> - 2009-09-03 21:10:55
|
Jocelyn wrote: > I haven't looked at the patch, but it might be easy to support both behavior > with short tag <foo/> and <foo></foo> using a boolean attribute, or > flag for the executable. > > This way, this won't break existing programs Either that, or write a descendant of the pretty-printer class and let dynamic binding use one or the other form. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Jann R. <roe...@et...> - 2009-09-03 21:52:54
Attachments:
tags.patch
|
Ok, I updated my patch with better feature names and comments and I made the use of "empty element tags" optional, disabled by default. Jann PS: Can anyone comment on the XML declaration issue? Eric Bezault schrieb: > Jocelyn wrote: >> I haven't looked at the patch, but it might be easy to support both behavior >> with short tag <foo/> and <foo></foo> using a boolean attribute, or >> flag for the executable. >> >> This way, this won't break existing programs > > Either that, or write a descendant of the pretty-printer class > and let dynamic binding use one or the other form. > |
From: Eric B. <er...@go...> - 2009-09-07 13:09:47
|
Hi Jann, > Ok, > I updated my patch with better feature names and comments and I made the > use of "empty element tags" optional, disabled by default. Your patch is now in the Gobo Git repository. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Colin A. <col...@go...> - 2009-09-04 06:08:49
|
2009/9/3 Jann Röder <roe...@et...>: > > PS: Can anyone comment on the XML declaration issue? > I discussed it with Franck yesterday. The issue is with the encoding. I was claiming that as he is writing STRINGs, then the XML declaration is required, because the encoding will be iso8859-1, but he said the actual serialization depends upon what XM_OUTPUT does down the line. Therefore the problem is difficult. The best way is not to use this pretty printer for serializing XML - really it's only a debug tool. The XSLT serializer should be used for serializing output (note this does not mean you have to run XSLT). -- Colin Adams Preston, Lancashire, ENGLAND |
From: Eric B. <er...@go...> - 2009-09-04 09:27:35
|
Jocelyn wrote: > In a previous post, Eric said the git tools for Windows were not very > attractive. > And I agree they are not yet at the same level as TortoiseSVN. > > However, personally I am using on Windows > - msysGit http://code.google.com/p/msysgit/downloads/list > - for the gui ... either git gui, or gitk which come with any git setup > but most often, I use Git Extensions > (http://sourceforge.net/projects/gitextensions/) which is good enough > for my need. > - I tried to use TortoiseGIT (http://code.google.com/p/tortoisegit/) > but I was unable to make it work on my Win XP Pro 64bits (too bad, since > I am a TortoiseSVN user, and I really like it) I tried TortoiseGIT (on Win XP Pro 32bits), and although not as full-fledged as TortoiseSVN, it works for me. I use it in combination with git gui, gitk and msysGit. I have currently disabled the write access to the SVN repository of Gobo while I'm converting it to Git. The more I play with it, the more I like the decentralized property of Git. I think that it makes it easier for people to contribute to projects. They can experiement on their own copy of the repository, and when they have something interesting to share, their whole file history can be merged into the official repository. Using decentralized SCM implies a new way of working, but I like it. I already see how I can take advantage of it for my own development. I'm also considering splitting the Gobo repository into smaller repositories, one per library and tool. That way people would not have to download everything if they are only interested in one or two libraries. The whole Gobo delivery would still gather everything using Git submodules (the equivalent of svn:external). But I will keep one big repository as a first step. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Eric B. <er...@go...> - 2009-09-06 14:29:25
|
Hello, The Gobo repository is now available under Git in SourceForge: https://sourceforge.net/scm/?type=git&group_id=24591 Despite what is said in the page above, the repository URL is: git://gobo-eiffel.git.sourceforge.net/gitroot/gobo-eiffel/gobo I also made a mirror available in github: http://github.com/gobo-eiffel This will make things easier for those who want to clone the repository in github. For example this is what I did to host my development of the support of ECF in the Gobo compiler while waiting for it to be ready to be integrated into the official repository: http://github.com/ebezault Note that the old SVN repository is still accessible in read-only mode for those who want to access its history. But this repository will not be kept up-to-date anymore. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Howard T. <how...@di...> - 2009-09-14 09:51:39
|
Hi Eric, I have just tried to clone the git repository, without success. Cloning from http://github.com/gobo-eiffel and http://github.com/ebezault results in a message: Initialized empty Git repository in /data/git/gobo-eiffel/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout. whereas cloning from git://gobo-eiffel.git.sourceforge.net/gitroot/gobo-eiffel/gobo results in: Initialized empty Git repository in /data/git/gobo-eiffel/.git/ fatal: The remote end hung up unexpectedly neither of which is useful ... ! This is using git version 1.5.6.3 on Linux. Any ideas ? Regards, Howard On Sunday 06 September 2009, Eric Bezault wrote: > Hello, > > The Gobo repository is now available under Git in SourceForge: > > https://sourceforge.net/scm/?type=git&group_id=24591 > > Despite what is said in the page above, the repository URL is: > > git://gobo-eiffel.git.sourceforge.net/gitroot/gobo-eiffel/gobo > > I also made a mirror available in github: > > http://github.com/gobo-eiffel > > This will make things easier for those who want to clone the > repository in github. For example this is what I did to host > my development of the support of ECF in the Gobo compiler > while waiting for it to be ready to be integrated into the > official repository: > > http://github.com/ebezault > > Note that the old SVN repository is still accessible in > read-only mode for those who want to access its history. > But this repository will not be kept up-to-date anymore. > -- Howard Thomson -- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein |
From: Colin P. A. <co...@co...> - 2009-09-14 09:55:25
|
>>>>> "Howard" == Howard Thomson <how...@di...> writes: Howard> Hi Eric, I have just tried to clone the git repository, Howard> without success. Howard> Cloning from http://github.com/gobo-eiffel and Howard> http://github.com/ebezault results in a message: Howard> Initialized empty Git repository in Howard> /data/git/gobo-eiffel/.git/ warning: remote HEAD refers to Howard> nonexistent ref, unable to checkout. Howard> This is using git version 1.5.6.3 on Linux. I have git 1.6.2.5 installed. When I try: git clone http://github.com/gobo-eiffel I get: Initialized empty Git repository in /home/colin/gobo-eiffel/.git/ fatal: http://github.com/gobo-eiffel/info/refs not found: did you run git update-server-info on the server? -- Colin Adams Preston Lancashire |