sablevm-developer Mailing List for SableVM (Page 47)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer — SableVM developer mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(27) |
Aug
(22) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(30) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(69) |
Sep
(10) |
Oct
(31) |
Nov
(15) |
Dec
(58) |
| 2003 |
Jan
(33) |
Feb
(81) |
Mar
(85) |
Apr
(24) |
May
(15) |
Jun
(14) |
Jul
(6) |
Aug
(9) |
Sep
(101) |
Oct
(59) |
Nov
(142) |
Dec
(34) |
| 2004 |
Jan
(107) |
Feb
(164) |
Mar
(181) |
Apr
(96) |
May
(81) |
Jun
(71) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chris P. <chr...@ma...> - 2003-03-18 18:17:51
|
Prof. Etienne M. Gagnon wrote: >On Tue, Mar 18, 2003 at 11:27:19AM -0500, Chris Pickett wrote: > > >>I agree, CVS only allows for a few different models. However, other >>than the problem of creating a branch every time you want to release, I >>can't really see what's wrong with having short-lived branches. >> >> > >How much development experience do you have on moderately big software >projects? [I seriously want a detailed answer to this question. You >may answer privately, if you think it is more appropriate.] > > Not that much at all, save for 6 months in Japan where I set up a CVS repository / project management system for 100 students, and contributed to the E-Cell project (large-ish simulation project written in C++/python/domain-specific modelling language). I am not a programmer, the largest thing I have written is probably my WIG compiler in 520 at McGill (5000 lines of Java using SableCC, of which I wrote 80%). I didn't do my undergraduate degree in CS (it was biochemistry) and I only started really programming in C a couple of weeks ago. I know Java a lot more than I know C (obviously) and am somewhat familiar with design patterns. Hell, I don't even have Linux installed on my laptop (my only machine) and I do everything using ssh/tty and emacs. All in all, I sux0rz. > >Personally, I do see all kind of problems with short-lived branches >(specially for managing an automatically generated changelog file, >which is necessary to honor the requirements of the LGPL license, in >case you were not aware). > Okay, I did not know that. I have not read the LGPL license, I just know broadly what it entails. I'll read it. > >I don't have time to justify every single little decision of mine. >You will have to learn to live with some of my decisions, or you may >fork your own project. One of these decisions is that will live with >a single trunk, no branches. > > Hey, it's okay. I'm not pushing you for branches. It's a real pain, and I understand that. I'm essentially maintaining a branch in my local repository anyway. >The only thing I can do, if you want to put all sort of stuff into >CVS, is to start a "distinct module", sablevm-experimental, that could >live in parallel, where there would be, again, a single trunk, but >where all developers can check-in stuff freely (as long as the code is >licensed appropriately, no non-clean-room contribution as usual). > > > In fact, it would have 2 brances: Trunk & Vendor branch. The latter > would track changes in the sablevm module. > What do you, and others, think of this? I think that's fine, but what potential problems do you see w.r.t. synchronization? If someone fixes something in the experimental branch, do they submit a patch for it to be included in the non-experimental branch? I have no problem being restricted to not committing anything to the main development module unless explicitly asked. Maybe you want to send an email to the info-cvs list I gave a link to, explaining the current problems and the specifics of our project (# of developers, CVS version, code size, etc.), and see what they have to say about your solution. >>Can we have write access in the meantime then? >> >> > >Most other developers already have write access. You won't get write >access before: >1- You change your SF user account name to something more professional. > > I already did that ... immediately after you asked me ... it's cpickett now (look at the comment I just made in the bug tracker). you can even close those bugs and re-open them if you don't want ihatemcgill to show up in the bug tracker. >2- You ask me for it, and we make the mandatory agreement on legal issues. > > Ok, I'm asking you. I can sign whatever you want me to sign. As for a clean room, I can guarantee that much for sure. >[Personally, I was toying with the idea of moving to a "old" Linus >model where contributions would be submitted as patches (but using a >SF tracker, in stead of the mailing-list), just to make sure no hot >headed developer went and screwed up the CVS repository >inadvertently...] > > > >>are only a handful of developers. We could set up a cvs-commit mailer >>that automatically sends out all changes and who made them. >> >> > >You have to learn to RTFM (or I should say RTFWP [Web Page])... Have >you looked at the links at the top left of the www.sablevm.org web >page? > > sorry, I didn't know there was one. i read so many WP's all the time i forget where things are. my bad. there are so many M's for me to FR right now. >>I don't *desperately* need write access. >> >> > >Go say that to Linus Torvalds. Ha ha! :-))))) > > Okay, I don't need write access at all. It would just make things a bit easier for me. >Seriously, SableVM users expect me to make sure write access is given >carefully, so that the legal status and the technical stability of the >project are not jeopardized. So, first I need to know that whatever >you will check-in won't cause problems. There's nothing wrong with >setting your own private PRCS repository, which is what I do! PRCS is >fantastic for managing local CVS snapshots. Try it. It doesn't >create CVS subdirectories, so it doesn't conflict with CVS. :-)) > > Okay, I can do that. Or maybe I'll switch to using Subversion (since it sounds like you want to try it in the future) Basically, there are two reasons why I would like the sablevm-experimental module: 1) So I can more easily synchronize my changes with other people's changes while still keeping them under version control. The project I am working on is speculative multithreading, and should be fairly independent of other SableVM stuff, and will probably not really break anything except itself. 2) So I can contribute documentation to the source code, as well as to separate documentation files. This is more for the benefit of other developers of course ... if I spend the time to document / understand a file, chances are I don't need to read those comments so much -- but it should help others. Cheers, Chris P.S. I hate debates like this too. I hope we don't ending hating each *other* :-( Not good for collaboration . . . |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 18:13:38
|
Hi Andrea, As David said, SableVM finds it's own class libraries (if properly installed) without the need to specify them using --classpath. The --classpath is used to specify the search locations for "application" classes, and it defaults to "." (current directory). Classes on the classpath are loaded using a Java-based class loader which is able to read from .jar files. (See src/gnu/java/lang/SystemClassLoader.java in the sablevm-class-library). Unfortunatly the VM's internal "bootstrap" class loader cannot read =66rom .jar files, as the bootstrap class loader cannot be *easily* written in Java [it would cause lots of chicken-egg problems; benn there, tried that :-(]. It is my intention to eventually link sablevm against the zlib library to read .jar files natively. [Contributions are welcome. :-))] Etienne On Tue, Mar 18, 2003 at 04:16:02PM +0100, Paolino paperino wrote: > Hi people!!! > I've installed and compiled successfully the SableVM > sources, after i downloaded the library's tars and > then i followed the instruction in the INSTALL file in > the subdir docs in the native library package...all > work well but now i want ask how can i pass the > compiled framework classes to the SableVM, i can't > find any classes.zip or .jar after the installation > step of the native library. which path i should pass > in --classpath variable when i launch the SableVM. >=20 > I greeting anyone can help me > Thanks mullons (a typical italian slang) >=20 > Andrea >=20 > ______________________________________________________________________ > Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino > http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.ht= ml >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink?=20 > You could win a Tablet PC. Get a free Tablet PC hat just for playing.=20 > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David <db...@cs...> - 2003-03-18 17:59:33
|
On Tue, Mar 18, 2003 at 10:26:25AM -0500, Etienne M. Gagnon wrote: > On Tue, Mar 18, 2003 at 10:00:23AM -0500, Chris Pickett wrote: > > There are, however, many useful scripts people have written to make=20 > > working with CVS easier. Besides, it seems that we don't really have= a=20 > > choice but to work with CVS, and we want some kind of branch / trunk=20 > > scheme, so rather than debate the relative merits of CVS / PRCS /=20 > > Subversion, we should just work with what we have. >=20 >=20 > So, I'll simply add a /doc directory and you can put all your docs > there. By default, it won't be included in .tar.gz distributions. If > we think some of these should be included, eventually, we simply need > to update the auto* files appropriately. No CVS branch headaches, > just ChangeLog pollution (which can be painfully avoided by passing > the appropriate arguments to cvs2cl). >=20 > Is that fine with you? It is fine with me. I wasn't expecting my suggestion to turn into a deba= te about which version management system is best, I just wanted some space to put my document draft... :( David >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon eg...@j-... > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink?=20 > You could win a Tablet PC. Get a free Tablet PC hat just for playing.=20 > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 17:24:54
|
On Tue, Mar 18, 2003 at 12:05:24PM -0500, Prof. Etienne M. Gagnon wrote: > The only thing I can do, if you want to put all sort of stuff into > CVS, is to start a "distinct module", sablevm-experimental, that could > live in parallel, where there would be, again, a single trunk, but > where all developers can check-in stuff freely (as long as the code is > licensed appropriately, no non-clean-room contribution as usual). In fact, it would have 2 brances: Trunk & Vendor branch. The latter would track changes in the sablevm module. What do you, and others, think of this? Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 17:15:41
|
On Tue, Mar 18, 2003 at 11:27:19AM -0500, Chris Pickett wrote: > I agree, CVS only allows for a few different models. However, other > than the problem of creating a branch every time you want to release, I > can't really see what's wrong with having short-lived branches. How much development experience do you have on moderately big software projects? [I seriously want a detailed answer to this question. You may answer privately, if you think it is more appropriate.] Personally, I do see all kind of problems with short-lived branches (specially for managing an automatically generated changelog file, which is necessary to honor the requirements of the LGPL license, in case you were not aware). I don't have time to justify every single little decision of mine. You will have to learn to live with some of my decisions, or you may fork your own project. One of these decisions is that will live with a single trunk, no branches. The only thing I can do, if you want to put all sort of stuff into CVS, is to start a "distinct module", sablevm-experimental, that could live in parallel, where there would be, again, a single trunk, but where all developers can check-in stuff freely (as long as the code is licensed appropriately, no non-clean-room contribution as usual). > Can we have write access in the meantime then? Most other developers already have write access. You won't get write access before: 1- You change your SF user account name to something more professional. 2- You ask me for it, and we make the mandatory agreement on legal issues. [Personally, I was toying with the idea of moving to a "old" Linus model where contributions would be submitted as patches (but using a SF tracker, in stead of the mailing-list), just to make sure no hot headed developer went and screwed up the CVS repository inadvertently...] > are only a handful of developers. We could set up a cvs-commit mailer > that automatically sends out all changes and who made them. You have to learn to RTFM (or I should say RTFWP [Web Page])... Have you looked at the links at the top left of the www.sablevm.org web page? > I don't *desperately* need write access. Go say that to Linus Torvalds. Ha ha! :-))))) Seriously, SableVM users expect me to make sure write access is given carefully, so that the legal status and the technical stability of the project are not jeopardized. So, first I need to know that whatever you will check-in won't cause problems. There's nothing wrong with setting your own private PRCS repository, which is what I do! PRCS is fantastic for managing local CVS snapshots. Try it. It doesn't create CVS subdirectories, so it doesn't conflict with CVS. :-)) Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David <db...@cs...> - 2003-03-18 16:42:44
|
Hi, SableVM should be able to find the class library by itself (no need to specify location) Class library are in sablevm-class-library.tar.gz file. They should end up in the directory INSTALLDIR/sablevm/lib/classes-$VERSION. Do you get some error when running SableVM? David On Tue, Mar 18, 2003 at 04:16:02PM +0100, Paolino paperino wrote: > Hi people!!! > I've installed and compiled successfully the SableVM > sources, after i downloaded the library's tars and > then i followed the instruction in the INSTALL file in > the subdir docs in the native library package...all > work well but now i want ask how can i pass the > compiled framework classes to the SableVM, i can't > find any classes.zip or .jar after the installation > step of the native library. which path i should pass > in --classpath variable when i launch the SableVM. >=20 > I greeting anyone can help me > Thanks mullons (a typical italian slang) >=20 > Andrea >=20 > ______________________________________________________________________ > Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonin= o > http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.= html >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink?=20 > You could win a Tablet PC. Get a free Tablet PC hat just for playing.=20 > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Chris P. <chr...@ma...> - 2003-03-18 16:26:59
|
Prof. Etienne M. Gagnon wrote: >On Tue, Mar 18, 2003 at 09:28:08AM -0500, Chris Pickett wrote: > > >>... There is no maintenance of the branch ... >> >> > >That's the problem. CVS's technical weaknesses dictate that branches >should be short lived. Except for vendor branches, you can't really >think of maintaining *parallel* stable, experimental, and "private" >developer branches, where changes are merged from any of these to any >other. You can imagine fixing a bug in stable and wanting to merge >the fix in experimental, *and* the reverse. CVS is simply not >appropriate for such development model. > > I agree, CVS only allows for a few different models. However, other than the problem of creating a branch every time you want to release, I can't really see what's wrong with having short-lived branches. >I know, you are suggesting to use some other's project development >model (Mozilla). My reply is to say, we should in the short term >stick to the simplest model (single trunk) to avoid being bitten by >the shortcomings of our support tool (CVS). > Can we have write access in the meantime then? There's only 5 of us right now. It should be fairly easy to track responsibility for a broken trunk, and besides, it's under version control anyway. Primarily this makes it easier to keep up to date with the current repository. Right now David and I have separate CVS's in our accounts, and are continuously updating from the SF CVS using import and then merging. Certainly CVS was not intended to be used this way when there are only a handful of developers. We could set up a cvs-commit mailer that automatically sends out all changes and who made them. Also, although some documentation could go in sablevm/doc, when I'm reading a file, it's nice to put comments in so that I don't have to reread the source later. These comments can become immediately useful to other developers if I have write access, and it saves us both the headache of using patches (me making them, you applying them). I'd also like to set up and auto-generated doxygen documentation system, but this can wait until the summer. The only reason I was suggesting the Mozilla model was because it seems fairly straightforward and because it seems like the best CVS can offer (that and also Mozilla is one of the largest projects using CVS). But a single trunk is okay with me. > I have got money from >NSERC to buy a server to host our development. Once we have this >server, we can install on it whatever tool we think is more >appropriate. My quick reading of the subversion home page convinced >me that it would be a far more appropriate tool than CVS, allowing us >to use the Mozilla Development model or change it easily if we find it >is not an appropriate model, without being locked out of interesting >models because of the underlying tool. > >I do not plan to buy the server before the Summer, as I do not have >time to shop for it and install it before then. It also gives us the >time to determine our needs. > > Okay, I think switching to Subversion is a good idea and I'm happy you're getting that server. It is intended to replace CVS altogether. Hopefully one day, SourceForge will host Subversion-based projects... it just needs a certain critical mass before things pick up. I don't *desperately* need write access, but it would make life a little easier. What do other people working on the source think? David? Grzegorz? Archie? Cheers, Chris |
|
From: Etienne M. G. <eg...@j-...> - 2003-03-18 15:27:31
|
On Tue, Mar 18, 2003 at 10:00:23AM -0500, Chris Pickett wrote: > There are, however, many useful scripts people have written to make > working with CVS easier. Besides, it seems that we don't really have a > choice but to work with CVS, and we want some kind of branch / trunk > scheme, so rather than debate the relative merits of CVS / PRCS / > Subversion, we should just work with what we have. So, I'll simply add a /doc directory and you can put all your docs there. By default, it won't be included in .tar.gz distributions. If we think some of these should be included, eventually, we simply need to update the auto* files appropriately. No CVS branch headaches, just ChangeLog pollution (which can be painfully avoided by passing the appropriate arguments to cvs2cl). Is that fine with you? Etienne -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: <von...@ya...> - 2003-03-18 15:16:11
|
Hi people!!! I've installed and compiled successfully the SableVM sources, after i downloaded the library's tars and then i followed the instruction in the INSTALL file in the subdir docs in the native library package...all work well but now i want ask how can i pass the compiled framework classes to the SableVM, i can't find any classes.zip or .jar after the installation step of the native library. which path i should pass in --classpath variable when i launch the SableVM. I greeting anyone can help me Thanks mullons (a typical italian slang) Andrea ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 15:14:27
|
On Tue, Mar 18, 2003 at 09:28:08AM -0500, Chris Pickett wrote: >... There is no maintenance of the branch ... That's the problem. CVS's technical weaknesses dictate that branches should be short lived. Except for vendor branches, you can't really think of maintaining *parallel* stable, experimental, and "private" developer branches, where changes are merged from any of these to any other. You can imagine fixing a bug in stable and wanting to merge the fix in experimental, *and* the reverse. CVS is simply not appropriate for such development model. I know, you are suggesting to use some other's project development model (Mozilla). My reply is to say, we should in the short term stick to the simplest model (single trunk) to avoid being bitten by the shortcomings of our support tool (CVS). I have got money from NSERC to buy a server to host our development. Once we have this server, we can install on it whatever tool we think is more appropriate. My quick reading of the subversion home page convinced me that it would be a far more appropriate tool than CVS, allowing us to use the Mozilla Development model or change it easily if we find it is not an appropriate model, without being locked out of interesting models because of the underlying tool. I do not plan to buy the server before the Summer, as I do not have time to shop for it and install it before then. It also gives us the time to determine our needs. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2003-03-18 15:00:04
|
There's also extensive user-based support out there for CVS, and people can help you with most of the problems you encounter. http://mail.gnu.org/archive/html/info-cvs/2003-03/index.html As far as I am aware, the primary problems with CVS are directory deletions, renaming, and atomic commits. That and it restricts you to certain branching models if you don't want a big headache. There are, however, many useful scripts people have written to make working with CVS easier. Besides, it seems that we don't really have a choice but to work with CVS, and we want some kind of branch / trunk scheme, so rather than debate the relative merits of CVS / PRCS / Subversion, we should just work with what we have. Chris Chris Pickett wrote: > Prof. Etienne M. Gagnon wrote: > >>OK guys, you want a proof that CVS is broken. >> >>I'll eventually prepare an example for you, but not now; I don't have >>the time. The example goes along the lines of: You make 2 branches, >>you "cvs add ; cvs commit" distinct files with the same name on the >>respective branches, then CVS loses one of the two files without >>warning. >> >>Also, I encourage you to experiment maintaining a branch and trying to >>merge trunk updates into the branch. CVS is good at the reverse >>(e.g. merging branch modifs into the trunk), but it not very helpful >>at tracking trunk changes in a branch. >> >> > No ... the way Mozilla works is every once in a while, it takes a > snapshot of development on the trunk and creates a branch. There is a > new branch for every release. There is no maintenance of the branch > ... you simply take your trunk snapshot and keep working on the branch > until it is fixed. Then, when the release occurs, you merge the > branch changes into the trunk (which CVS is good at, as you said). > The whole point is that once the branch is made, trunk changes don't > affect the branch anymore -- and they shouldn't either ... it will > have to wait until the next release. > > http://www.mozilla.org/roadmap.html > >>FYI, you might want to learn about how robust merging works. PRCS >>identified 14 distinct situations: >> >>http://prcs.sourceforge.net/merge.html >> >>The interesting thing is that PRCS actually asks you before performing >>an action. >> >>Additional reading identifying some of CVS's problems & advantages: >>http://prcs.sourceforge.net/cvs-vs-prcs.html >>http://prcs.sourceforge.net/kingdon.html >> >> > I've read all the PRCS stuff before, but it has problems of its own > too (ask Ondrej). I don't know what SubVersion is like, I would be > open to trying it. But I don't know if SF supports it. > > Chris > >>On Tue, Mar 18, 2003 at 07:23:38AM -0500, Chris Pickett wrote: >> >> >>>Grzegorz B. Prokopski wrote: >>> >>> >>> >>>>W li?cie z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze: >>>> >>>> >>>> >>>> >>>>>On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>How about . . . we just have a development branch and the main trunk. >>>>>>Anyone can hack away on the development branch (obviously trying not to >>>>>>break things), and then once in a while Etienne merges changes into the >>>>>>main trunk. Or some other such multi-developer version control idiom. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>The problem, with CVS, is that when you add something new on a branch, >>>>>it is considered as head and thus shows up in the main trunk and in >>>>>the Changelog. >>>>> >>>>> >>>>> >>>>> >>>>Are you sure? CVS docs say sth. rather opposite, see >>>>http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 >>>> >>>>"CVS allows you to isolate changes onto a separate line of development, >>>>known as a branch. When you change files on a branch, those changes do >>>>not appear on the main trunk or other branches." >>>> >>>>Projects like Mozilla use CVS in the model of HEAD (unstable, >>>>development version) and branches (stable releases). If CVS weren't >>>>suitable for this - would they use it? >>>> >>>> >>>> >>>> >>>I kind of like the Mozilla model of development. I think it makes more >>>sense than having a development branch, actually. It says, "If you want >>>a stable release, don't check out from CVS but rather get a tarball. >>>And if you really want to check out the sources in the tarball from the >>>release branch, you can." >>> >>>CVS may have problems but then again 99% of projects use it so it can't >>>be that severely broken. >>> >>>Chris >>> >>> >> >> >> |
|
From: Chris P. <chr...@ma...> - 2003-03-18 14:27:48
|
Prof. Etienne M. Gagnon wrote: >OK guys, you want a proof that CVS is broken. > >I'll eventually prepare an example for you, but not now; I don't have >the time. The example goes along the lines of: You make 2 branches, >you "cvs add ; cvs commit" distinct files with the same name on the >respective branches, then CVS loses one of the two files without >warning. > >Also, I encourage you to experiment maintaining a branch and trying to >merge trunk updates into the branch. CVS is good at the reverse >(e.g. merging branch modifs into the trunk), but it not very helpful >at tracking trunk changes in a branch. > > No ... the way Mozilla works is every once in a while, it takes a snapshot of development on the trunk and creates a branch. There is a new branch for every release. There is no maintenance of the branch ... you simply take your trunk snapshot and keep working on the branch until it is fixed. Then, when the release occurs, you merge the branch changes into the trunk (which CVS is good at, as you said). The whole point is that once the branch is made, trunk changes don't affect the branch anymore -- and they shouldn't either ... it will have to wait until the next release. http://www.mozilla.org/roadmap.html >FYI, you might want to learn about how robust merging works. PRCS >identified 14 distinct situations: > >http://prcs.sourceforge.net/merge.html > >The interesting thing is that PRCS actually asks you before performing >an action. > >Additional reading identifying some of CVS's problems & advantages: >http://prcs.sourceforge.net/cvs-vs-prcs.html >http://prcs.sourceforge.net/kingdon.html > > I've read all the PRCS stuff before, but it has problems of its own too (ask Ondrej). I don't know what SubVersion is like, I would be open to trying it. But I don't know if SF supports it. Chris >On Tue, Mar 18, 2003 at 07:23:38AM -0500, Chris Pickett wrote: > > >>Grzegorz B. Prokopski wrote: >> >> >> >>>W li?cie z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze: >>> >>> >>> >>> >>>>On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: >>>> >>>> >>>> >>>> >>>>>How about . . . we just have a development branch and the main trunk. >>>>>Anyone can hack away on the development branch (obviously trying not to >>>>>break things), and then once in a while Etienne merges changes into the >>>>>main trunk. Or some other such multi-developer version control idiom. >>>>> >>>>> >>>>> >>>>> >>>>The problem, with CVS, is that when you add something new on a branch, >>>>it is considered as head and thus shows up in the main trunk and in >>>>the Changelog. >>>> >>>> >>>> >>>> >>>Are you sure? CVS docs say sth. rather opposite, see >>>http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 >>> >>>"CVS allows you to isolate changes onto a separate line of development, >>>known as a branch. When you change files on a branch, those changes do >>>not appear on the main trunk or other branches." >>> >>>Projects like Mozilla use CVS in the model of HEAD (unstable, >>>development version) and branches (stable releases). If CVS weren't >>>suitable for this - would they use it? >>> >>> >>> >>> >>I kind of like the Mozilla model of development. I think it makes more >>sense than having a development branch, actually. It says, "If you want >>a stable release, don't check out from CVS but rather get a tarball. >>And if you really want to check out the sources in the tarball from the >>release branch, you can." >> >>CVS may have problems but then again 99% of projects use it so it can't >>be that severely broken. >> >>Chris >> >> > > > |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 13:13:45
|
OK guys, you want a proof that CVS is broken. I'll eventually prepare an example for you, but not now; I don't have the time. The example goes along the lines of: You make 2 branches, you "cvs add ; cvs commit" distinct files with the same name on the respective branches, then CVS loses one of the two files without warning. Also, I encourage you to experiment maintaining a branch and trying to merge trunk updates into the branch. CVS is good at the reverse (e.g. merging branch modifs into the trunk), but it not very helpful at tracking trunk changes in a branch. FYI, you might want to learn about how robust merging works. PRCS identified 14 distinct situations: http://prcs.sourceforge.net/merge.html The interesting thing is that PRCS actually asks you before performing an action. Additional reading identifying some of CVS's problems & advantages: http://prcs.sourceforge.net/cvs-vs-prcs.html http://prcs.sourceforge.net/kingdon.html Almost all projects only use a single branch in CVS, so they don't suffer from the problems above. So, your argument does not hold. Do a serious search on the Internet to find about CVS's problems, you you'll see it has many more problems than you think. I di my own homework and tested CVS extensively before drawing my conclusions. Have you done yours? Etienne On Tue, Mar 18, 2003 at 07:23:38AM -0500, Chris Pickett wrote: > Grzegorz B. Prokopski wrote: > > >W li?cie z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze: > > > > > >>On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: > >> > >> > >>>How about . . . we just have a development branch and the main trunk. > >>>Anyone can hack away on the development branch (obviously trying not to > >>>break things), and then once in a while Etienne merges changes into the > >>>main trunk. Or some other such multi-developer version control idiom. > >>> > >>> > >>The problem, with CVS, is that when you add something new on a branch, > >>it is considered as head and thus shows up in the main trunk and in > >>the Changelog. > >> > >> > >Are you sure? CVS docs say sth. rather opposite, see > >http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 > > > >"CVS allows you to isolate changes onto a separate line of development, > >known as a branch. When you change files on a branch, those changes do > >not appear on the main trunk or other branches." > > > >Projects like Mozilla use CVS in the model of HEAD (unstable, > >development version) and branches (stable releases). If CVS weren't > >suitable for this - would they use it? > > > > > > I kind of like the Mozilla model of development. I think it makes more > sense than having a development branch, actually. It says, "If you want > a stable release, don't check out from CVS but rather get a tarball. > And if you really want to check out the sources in the tarball from the > release branch, you can." > > CVS may have problems but then again 99% of projects use it so it can't > be that severely broken. > > Chris -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2003-03-18 12:23:20
|
Grzegorz B. Prokopski wrote: >W li=B6cie z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze= :=20 > =20 > >>On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: >> =20 >> >>>How about . . . we just have a development branch and the main trunk. = >>>Anyone can hack away on the development branch (obviously trying not t= o=20 >>>break things), and then once in a while Etienne merges changes into th= e=20 >>>main trunk. Or some other such multi-developer version control idiom.= >>> =20 >>> >>The problem, with CVS, is that when you add something new on a branch, >>it is considered as head and thus shows up in the main trunk and in >>the Changelog. >> =20 >> >Are you sure? CVS docs say sth. rather opposite, see >http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 > >"CVS allows you to isolate changes onto a separate line of development, > known as a branch. When you change files on a branch, those changes do > not appear on the main trunk or other branches." > >Projects like Mozilla use CVS in the model of HEAD (unstable, >development version) and branches (stable releases). If CVS weren't >suitable for this - would they use it? > =20 > I kind of like the Mozilla model of development. I think it makes more=20 sense than having a development branch, actually. It says, "If you want = a stable release, don't check out from CVS but rather get a tarball. =20 And if you really want to check out the sources in the tarball from the=20 release branch, you can." CVS may have problems but then again 99% of projects use it so it can't=20 be that severely broken. Chris |
|
From: Grzegorz B. P. <ga...@de...> - 2003-03-18 11:56:42
|
W liście z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze: > On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: > > How about . . . we just have a development branch and the main trunk. > > Anyone can hack away on the development branch (obviously trying not to > > break things), and then once in a while Etienne merges changes into the > > main trunk. Or some other such multi-developer version control idiom. > The problem, with CVS, is that when you add something new on a branch, > it is considered as head and thus shows up in the main trunk and in > the Changelog. Are you sure? CVS docs say sth. rather opposite, see http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 "CVS allows you to isolate changes onto a separate line of development, known as a branch. When you change files on a branch, those changes do not appear on the main trunk or other branches." Projects like Mozilla use CVS in the model of HEAD (unstable, development version) and branches (stable releases). If CVS weren't suitable for this - would they use it? I looked at the Subversion status and bugs targetted for next releases. I haven't notoiced any bugs related to branches so there's a chance they're usable w/ SVN. Cheers, GBP -- Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 00:24:34
|
On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: > How about . . . we just have a development branch and the main trunk. > Anyone can hack away on the development branch (obviously trying not to > break things), and then once in a while Etienne merges changes into the > main trunk. Or some other such multi-developer version control idiom. The problem, with CVS, is that when you add something new on a branch, it is considered as head and thus shows up in the main trunk and in the Changelog. Branches *are* badly broken in CVS. This is why I usually use PRCS, but unfortunately it doesn't support remote opertions and isn't supported by SourceForge. Has anyone investigated the newer Subversion free project replacement for CVS? Does it support branches as well as PRCS? Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David <db...@cs...> - 2003-03-17 21:33:43
|
On Mon, Mar 17, 2003 at 09:23:31PM +0100, Grzegorz B. Prokopski wrote: > W li?cie z pon, 17-03-2003, godz. 20:07, David B=E9langer pisze:=20 > > Hi, > >=20 > > Concerning the sablevm documentation for developpers, here what I sug= gest: > >=20 > > Create a new module for the documentation. > > Have a 'draft' and a 'main' directory in that module. > >=20 > > 'draft' directory checkin policy: anyone can checkin their draft > > documentation, no need to wait for Etienne approval. Developpers > > could have their own subdirs. > > draft/chris > > draft/david > > etc. > >=20 > > 'main': This is the complete or almost complete doc that has been > > reviewed. We have control of what gets put there e.g. only Etienne > > checkin stuff there. > Hmm... I think I've been reading all recent emails and I haven't seen > such big documentation flood :-) >=20 > I don't know how much documentation we should expect to appear, but > I doubt it'd be THAT much of it and so soon that would mandate > separete module (and separate tarball). >=20 > I think I'd rather create 'doc' directory in sablevm module where all > approved docs should appear (even Etienne's PhD thesis if for ex. he > would like them to be distributed in debian packages). >=20 > As for the developers' directories. I've seen (for ex. in FireBird) > that developers usually have their own subdirs where they keep their > own stuff which, for some reason, is not included into the mainline [0]= . > Again - I think I'd put these dirs in sablevm module for the reason > similar to why I wouldn't create new module for docs. Actually, after reading your email I think developer directories would be more approriate. I was thinking too much about the doc I am writing right now. The reason I wrote the email in the first place is that I am currently documenting the java stack layout. I am completing it as I need the info. Rather than sending it (then later several updates) to the mailing list, it could be good if I could just put it somewhere. As it is right now, it could be quite useful for people who need that info even if it is still incomplete. David >=20 > KISS - we should not overengineer things. >=20 > Just my 0.03CAD :-) (about 0.08PLN currently) >=20 > Grzegorz B. Prokopski >=20 > [0] Firebird developers have their "home"/"own" dirs in 'firebird' > directory in 'firebird' module but I wouldn't go along this pattern. > Maybe dir like 'developers' for developers' own dirs would suffice? >=20 > --=20 > Grzegorz B. Prokopski <ga...@de...> > Debian http://www.debian.org/ --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Chris P. <chr...@ma...> - 2003-03-17 21:04:41
|
I agree also that the doc module/directory/whatever (CVS lets you=20 specify any directory as a "module") should be a subdirectory in the=20 already existing sablevm module. Like sablevm/doc. And I still think a = development branch would make the patching process easier. Also, this=20 way, the main trunk is less likely to ever be broken. Grzegorz B. Prokopski wrote: >W li=B6cie z pon, 17-03-2003, godz. 20:07, David B=E9langer pisze:=20 > =20 > >>Hi, >> >>Concerning the sablevm documentation for developpers, here what I sugge= st: >> >>Create a new module for the documentation. >>Have a 'draft' and a 'main' directory in that module. >> >>'draft' directory checkin policy: anyone can checkin their draft >>documentation, no need to wait for Etienne approval. Developpers >>could have their own subdirs. >>draft/chris >>draft/david >>etc. >> >>'main': This is the complete or almost complete doc that has been >>reviewed. We have control of what gets put there e.g. only Etienne >>checkin stuff there. >> =20 >> >Hmm... I think I've been reading all recent emails and I haven't seen >such big documentation flood :-) > >I don't know how much documentation we should expect to appear, but >I doubt it'd be THAT much of it and so soon that would mandate >separete module (and separate tarball). > >I think I'd rather create 'doc' directory in sablevm module where all >approved docs should appear (even Etienne's PhD thesis if for ex. he >would like them to be distributed in debian packages). > >As for the developers' directories. I've seen (for ex. in FireBird) >that developers usually have their own subdirs where they keep their >own stuff which, for some reason, is not included into the mainline [0].= >Again - I think I'd put these dirs in sablevm module for the reason >similar to why I wouldn't create new module for docs. > >KISS - we should not overengineer things. > >Just my 0.03CAD :-) (about 0.08PLN currently) > > Grzegorz B. Prokopski > >[0] Firebird developers have their "home"/"own" dirs in 'firebird' >directory in 'firebird' module but I wouldn't go along this pattern. >Maybe dir like 'developers' for developers' own dirs would suffice? > > =20 > |
|
From: Chris P. <chr...@ma...> - 2003-03-17 20:53:35
|
Hi, How about . . . we just have a development branch and the main trunk.=20 Anyone can hack away on the development branch (obviously trying not to=20 break things), and then once in a while Etienne merges changes into the=20 main trunk. Or some other such multi-developer version control idiom. This would include a doc module that we can all work on. Previously, I had experience setting up a doxygen automatically generated manual for a large, totally undocumented project, and it was not too difficult and actually quite successful (it gives you an html code browser for example). To generate the documentation, one simply=20 typed "make doc". I could do the same thing for SableVM, and then the=20 JavaDoc comments in files would automatically get included. Again, as I wrote before, documentation of actual source files needs to be in the sources themselves. Documentation of the bigger picture obviously can go in a separate file. Latex is fine for this I think (there's docbook, but everyone knows and loves latex already). Both=20 kinds of documentation could go in the doc directory. Cheers, Chris P.S. www.doxygen.org David B=E9langer wrote: >Hi, > >Concerning the sablevm documentation for developpers, here what I sugges= t: > >Create a new module for the documentation. >Have a 'draft' and a 'main' directory in that module. > >'draft' directory checkin policy: anyone can checkin their draft documen= tation, no need to wait for Etienne approval. Developpers could have the= ir own subdirs. >draft/chris >draft/david >etc. > >'main': This is the complete or almost complete doc that has been >reviewed. We have control of what gets put there e.g. only Etienne >checkin stuff there. > > >Comments are welcome. > > >David > >--- > >David B=E9langer >Graduate Student >School of Computer Science >McGill University >Office: MC226 > >Web page: http://www.cs.mcgill.ca/~dbelan2/ >Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt > > > >------------------------------------------------------- >This SF.net email is sponsored by:Crypto Challenge is now open!=20 >Get cracking and register here for some mind boggling fun and=20 >the chance of winning an Apple iPod: >http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en >_______________________________________________ >Sablevm-developer mailing list >Sab...@li... >https://lists.sourceforge.net/lists/listinfo/sablevm-developer > > =20 > |
|
From: Grzegorz B. P. <ga...@de...> - 2003-03-17 20:24:36
|
W li=B6cie z pon, 17-03-2003, godz. 20:07, David B=E9langer pisze:=20 > Hi, >=20 > Concerning the sablevm documentation for developpers, here what I suggest= : >=20 > Create a new module for the documentation. > Have a 'draft' and a 'main' directory in that module. >=20 > 'draft' directory checkin policy: anyone can checkin their draft > documentation, no need to wait for Etienne approval. Developpers > could have their own subdirs. > draft/chris > draft/david > etc. >=20 > 'main': This is the complete or almost complete doc that has been > reviewed. We have control of what gets put there e.g. only Etienne > checkin stuff there. Hmm... I think I've been reading all recent emails and I haven't seen such big documentation flood :-) I don't know how much documentation we should expect to appear, but I doubt it'd be THAT much of it and so soon that would mandate separete module (and separate tarball). I think I'd rather create 'doc' directory in sablevm module where all approved docs should appear (even Etienne's PhD thesis if for ex. he would like them to be distributed in debian packages). As for the developers' directories. I've seen (for ex. in FireBird) that developers usually have their own subdirs where they keep their own stuff which, for some reason, is not included into the mainline [0]. Again - I think I'd put these dirs in sablevm module for the reason similar to why I wouldn't create new module for docs. KISS - we should not overengineer things. Just my 0.03CAD :-) (about 0.08PLN currently) Grzegorz B. Prokopski [0] Firebird developers have their "home"/"own" dirs in 'firebird' directory in 'firebird' module but I wouldn't go along this pattern. Maybe dir like 'developers' for developers' own dirs would suffice? --=20 Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: David <db...@cs...> - 2003-03-17 19:07:18
|
Hi, Concerning the sablevm documentation for developpers, here what I suggest= : Create a new module for the documentation. Have a 'draft' and a 'main' directory in that module. 'draft' directory checkin policy: anyone can checkin their draft document= ation, no need to wait for Etienne approval. Developpers could have thei= r own subdirs. draft/chris draft/david etc. 'main': This is the complete or almost complete doc that has been reviewed. We have control of what gets put there e.g. only Etienne checkin stuff there. Comments are welcome. David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-16 23:01:28
|
On Sun, Mar 16, 2003 at 09:55:02AM -0500, Chris Pickett wrote: > Why are there SKIP and NOP instructions? What is the difference? Mainly semantic: NOP is part of the JVM instruction set. SKIP is added to the begginning of some sequences. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-16 18:12:28
|
On Sat, Mar 15, 2003 at 03:20:39PM -0500, Chris Pickett wrote:
> 1) it seems that everything in macros.c should go in cast.list, except
> for _svmf_is_same_object which should go in one of the util files. I'm
> not sure if macros.c is obsolete or not. It seems that macros.h is
> probably obsolete as well, and if not, should probably be targeted for
> replacement with m4 macros in the future.
You are mostly right. A couple of methods cannot be generated using
cast.list because of the additional conditional. Also, the name
"macros.[ch]" is not really intuitive. It is part of a few legacy
things from before the SableVM rearchitecturing to use m4...
> 2) all constants defined should go into constants.h and this should be a
> policy for anyone modifying the source. i'm not sure if there are
> constants defined elsewhere in the VM.
Except for system-specific things, of course.
> 3) I don't know why we need direct_threaded.m4, inlined_threaded.m4,
> switch_threaded.m4,
> instructions_preparation.m4, and instructions_switch.m4. In general, I
> think the very short files like these are unnecessary.
They are necessary. Look in src/libsablevm/Makefile.am. These file impact the
selection of the appropriate macro expansion.
> 4)
> error_bits.m4.h:
> error_classes.m4.h:
> error_init_methods.m4.h:
> error_instances.m4.h:
> very short multicallable macros to declare error types.
> not sure why all four of these files exist ... they are
> very similar and all declare macros of the same name.
That's the idea: They declare macros of the same name, yet expand
differenlty. Look into src/libsablevm/Makefile.am again.
>
> 5) gc_generational.c -- should be moved into libsablevm/dev or something
> until it is working.
Or maybe get rif of it, altogether. I will show up in CVS (attic
directory).
> 6) class_file_parser.h .... don't really think we need this to be a
> separate file. is it obsolete?
Maybe. :-)
>
> 7) I need a better explanation for global_refs.* and local_refs.*
The idea is that you get type-safe allocation and free functions. In
addition, the free function resets the pointer variable to NULL,
making sure any subsequent attempt to dereference the freed pointer
causes a segfault (instead of using an obsolete pointer value, which
can be very, very difficult to track).
Also, these functions do all the necessary to throw an exception in
case of out-of-memory situation.
Being type-safe, you know that the allocated memory is of the right
size. Once you'll have accumulated a lot C development experience,
you'll know how easy it is to make the following mistake, when you
copy/paste code:
sometype1 *var = malloc (sizeof(sometype2));
And how easy it is to forget to check whether var == NULL. You'll
also notice how it is annoying to retype the correct error handling
code.
The global_refs do all of the tedious work for you, so you get to
only write:
if (_svmm_gzalloc_gc_map_node (env, method->parameters_gc_map) != JNI_OK)
{
return JNI_ERR;
}
As for the ..._no_exception version, they do the same, but they do not
create and throw an OutOfMemoryError. They are necessary, because in
early bootstrapping, the VM has not yet created the heap, so it cannot
instantiate an Error object instance.
> 8) heap_manager.c: at least part or all of this file is obsolete i think
> (definitely the end)
Possible.
> 9) heap_manager.h .... don't need an essentially empty header
Probaby. :-)
> 10) I don't know why instructions_switch.m4.c exists, it seems similar
> to the content in instructions_preparation.m4.c and there are no files
> called instructions_inlined.m4.c, or instructions_direct.m4.c.
It is necessary. Unlike the direct/threaded threaded engines, the
switch-based interpreter has to provide a real "switch" statement of
bytecode implementations to be included in _svmf_interpreter()
[interpreter.c], yet it does need also a separate "switch" (like the
two other engines) to provide information about each bytecode (in
prevision of method preparation [prepare_code.c]).
The key to understand what is happening is to trace the execution of
_svmf_interpreter using a debugger (I suggest DDD) by setting
breakpoints at the appropriate locations. For this, you need to
compile the 3 engines, ideally with --enable debugging-features,
unless you want to be intrigued by the segfault used in the normal
control flow of the VM... ;-)
>
> 11) move the java_lang_* stuff into libsablevm/java and remove vmlib.*
> altogether.
No. The Auto* tools don't really support compilation of a single
library out of files in multiple directories.
If you want the C optimizer to do a good job, you want to compile a
single library in one shot. I never understood why people do a per
file compilation of C code to .o. It makes no sense; C wasn't
designed like that. An optimizing compiler cannot inline functions or
do any global optimization if you arbitrarily separate your
compilation unit in smaller units on a source file boundary.
It only makes snese to generate a .(s?)o if you plan to reuse the same
functionality across many executable/libraries, and dont want your
optimizer to do any cross function boundary optimization.
libsablevm.so should only export a restricted set of symbols: JNI_*
and Java_*. Using more than one compilation unit would cause the
exportation of additional (read: inteternal!) symbols.
So, unless you want to fix the GNU auto* tools, you'll have to live
with the current file structure. :-(
> 12)
> jnidefs.h:
> definitions of jobject, jarray, jfieldID, and jmethodID. why do
> these get their own special file, instead of being included in
> types.h or jni.h?
Because jni.h is installed on the users system and made available for
Java programmers to be able to write JNI libraries to link with the
VM. The types above are "opaque" types, from a Java programmer's
point of view, so that the same JNI library can wotk with *any* JVM
implementing the JNI interface. Of course, within SableVM itself,
these types should't be opaque, so there you have tjnidefs.h to
"enlighten" these types. :-)
> 13) not sure what lib_init.c does
You can invoke JNI_CreateJavaVM multiple times (concurrently) within a
single process (as long as each call is on a different thread).
lib_init serves to make sure some global libsablevm initialization
happens only once, using the standard POSIX pthread_once().
>
> 14) unclear about "specific" methods in method_invoke.list
The non-"specific" method invocations are invocation of method
decalred in classes which are automatically loaded by the bootstrap
class loader.
The "specific" method invocations are used to invoke a "specific"
version of a method signature selected at runtime. So, in the
"specific" case, you have an additional formal parameter for providing
a _svmt_method_info pointer.
For example, to invoke the <clinit> method of a class (part of class
initialization), the VM needs the _svmt_method_info which is specific
to that class. It cannot use a generic _svmt_method_info from
method/class loaded at bootstrap time.
If you don't like the "specific" name, (I'm starting to dislike it
quite a bit), I'm open to suggestions for a replacement.
>
> 15) do you need native_interface.h?
>
These are remnants of the old SableVM code base where I was using
separate sompilation units (as is most intuitive with auto* tools).
So, unless the "extern" needs a forward declaration, we could maybe
get rid of it.
[Order of inclusion in libsablevm.c can be a good technical reason to
keep a .h file. :-)]
> 16) all type declarations should go in types.h .... this should be a
> policy like for constants.h ... the stuff in system.h obviously
> shouldn't be in there though. % grep typedef * shows that only
> pthread_rec_svm.* violates this.
pthread_rec_svm.* should remain so. It is an implementation of
recusrive mutexes on top of POSIX non-recursive mutexes. These files
can easily be reused by other applications, with no dependency
whatsoever on other SableVM internal data structures & types.
This could go into a seprate directory, yet I prefer to keep more
opimization opportunities by leaving them as part of the same
compilation unit.
>
> 17) util.h, util.m4.c., util1.c, and util2.c need to be cleaned up (see
> my comments in the file). split
> the util functions into two categories: those for working with the C
> language, and those for
> working with Java data structures. furthermore, util.h could be built
> from an m4 file and a list file it
> seems.
Patches are welcome. The reason it is not all in a single file is
because of compile dependencies (order of #include's).
>
> 18) all #include directives should go in libsablevm.c
except for pthread_rec*, and some other ones like in
_svmf_interpreter().
OK. Enough for today. For the remaining of my answers, I'll give
them to you at our meeting next week and I'll assign to you the task
of writing them down and emailing them to this list for the benefit of
all other sablevm developers. :-))
Have fun!
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
|
From: Chris P. <chr...@ma...> - 2003-03-16 14:54:42
|
Why are there SKIP and NOP instructions? What is the difference? Chris |
|
From: Chris P. <chr...@ma...> - 2003-03-15 22:07:48
|
Furthermore ... I think it would help the syntax coloring if _svmt_* was replaced by _svmt_*_t ... emacs will color this green and the corresponding variable declaration yellow ... I find it greatly improves readability. Chris Pickett wrote: > Here is a very short coding standards file. I don't know where in > sablevm/src you want to put it. You might want to change the name, > you might want it as part of the README. It's up to you :) > > Cheers, > Chris > >------------------------------------------------------------------------ > >This document briefly describes coding standards in SableVM. > >1) Learn to use m4. The m4 manual (% info m4), >macros.m4, and examples throughout the >source code will help you with this. It makes the code easier to maintain. >Do not use the C preprocessor #define command for macros >(constants are an exception). > >2) All constants defined should go in constants.h > >3) All typedefs should go in types.h, or in system.h for system-specific stuff. > >4) All include directives should go in libsablevm.c > >5) If you change the source code, make sure you change appropriate comments >that relate to the code you have changed. > > |
6 messages has been excluded from this view by a project administrator.
