Release of RosAsm V.2.025a
in [ASM]
|
From: randyhyde@earthlink.net on 20 Sep 2005 13:41 Betov wrote: > > > > Why don't you answer the questions? This is the occasion to prove the > > superiority of the clip technology! > > Because there is nothing to be answered: IOW, the clip system is in no way shape or form superior to statically linked library modules. > > > > And other questions : How do you do concurrent work on a project with > > RosAsm if the project is one file? > > We depress [Ctrl]/[S] for saving the concerned TITLE, and > exchange the .asm File. For Resources exchanges, we also > have special Binary Formats, and all of these make the > exchanges as simple as a Click. IOW, it's all manual. The RosAsm team has no clue about modern software engineering techniques and how to manage team projects. > > > > Do you use a file revision system? > > Of course not. :-) > > > > Do you merge modifications by hand by copying blocks in the main RosAsm > > version? > > Of course not. He's lying. Of course they do. He just doesn't understand what you're asking. > > > > Do you have to wait somebody has finished working to begin modifying the > > project? > > Our rule is quite simple: Once a volunteer has been attributed > a TITLE, _he_, and only _he_ is allowed to touch _his_ TITLE. See the statement above. Yep. The RosAsm scheme truly supports team projects :-) :-) :-) > > In other words, we never have two volunteers writing the same > TITLE at the same time, The RosAsm team doesnt understand what a "team project" is all about. > and when two volunteers "work around" > a same TITLE (for example, actualy, Guga and me working both > at a time on the LibScanner), there is one doing one task > (example, searching for the Doc, preparing the developements, > controling the progresses,...), while the other one really > _writes_ the TITLE. They *really* don't understand what team project management is all about. > > When two volunteers really want to work (_write_) on the > same component, we divide the TITLE into two TITLEs. They *really, really* don't understand how team project management should be done. > Example, > recently Ludwig, who is in charge of the Debugger, wrote > something for the Assembler... in a _separated_ TITLE. It's really a completely separate project. Subject, of course, to the limitations that it cannot reuse label and variable names from the *other* separate applications that are merged into RosAsm. Such are the benefits of the "monolithic source file format" that RosAsm forces on its users. > > When finished, merging two TITLEs is just a matter of > deleting one Statement in the Source. And resolving things like conflicting names, merging duplicate code, and all those other things that plague this type of "monolithic" software development. The really sad thing is that the RosAsm team really doesn't know any better. > > > > I really suspect that multiple files is mandatory when working with a > > large team on the same project. > > Up to now, whatever number of volunteers working directly on > some part of RosAsm, we never had any problem, with the actual > methods, and, in my opinion, even though RosAsm has the most > important Team of Developpers for an Assembly Project, we could > even be 10 times more volunteers, that it would not make any > difference. HaHaHa! The leader of the RosAsm team demonstrates his software engineering competence with this last statement! Cheers, Randy Hyde
From: Guga on 20 Sep 2005 14:03 The only sad thing on your statements Randall is that you are the one who don´t know what you are talking about, and, by consequence, you are spreading lies again. Example: "And resolving things like conflicting names, merging duplicate code, and all those other things that plague this type of "monolithic" software development. The really sad thing is that the RosAsm team really doesn't know any better. " Just a lie .. Duplicated symbols or functions when merged the user is warned because it won ´t assemble the file due to the duplications. The error management is exactlyto prevent this sort of things. "> > Do you have to wait somebody has finished working to begin modifying the project? > Our rule is quite simple: Once a volunteer has been attributed a TITLE, _he_, and only _he_ is allowed to touch _his_ TITLE. See the statement above. Yep. The RosAsm scheme truly supports team projects :-) :-) :-) > In other words, we never have two volunteers writing the same TITLE at the same time, The RosAsm team doesnt understand what a "team project" is all about. " Maybe you didn´t read what i posted or you just disconsidered on your attacks on rene...but..on all you posted you really seems clueless on what it is all about, the clip features, the incinclude statements preparsers and the lib scanners. "They *really, really* don't understand how team project management should be done." So, pls enlight us with your "universal" knowledge. If that means disseminating arrogancy or flames on our team of co-workers...Sorry..this won´t happen :) A team work using different files and people thinking together of the whole project is what a team work is based on. The way it is developed is not different from other techniques of working in team you want to impose... Best Regards, Guga
From: randyhyde@earthlink.net on 20 Sep 2005 15:37 Guga wrote: > The only sad thing on your statements Randall is that you are the one > who don´t know what you are talking about, and, by consequence, you > are spreading lies again. > > Example: > > "And resolving things like conflicting names, merging duplicate code, > and all those other things that plague this type of "monolithic" > software development. The really sad thing is that the RosAsm team > really doesn't know any better. " > > Just a lie .. Duplicated symbols or functions when merged the user is > warned because it won ´t assemble the file due to the duplications. > The error management is exactlyto prevent this sort of things. You really do not understand why namespace pollution is a bad thing, do you? Then again, this should come as no surprise from a user of the assembler that encourages people to use label names like I0, I1, I2, I3, etc. > > > The RosAsm team doesnt understand what a "team project" is all about. " > > Maybe you didn´t read what i posted or you just disconsidered on your > attacks on rene...but..on all you posted you really seems clueless on > what it is all about, the clip features, the incinclude statements > preparsers and the lib scanners. How many professional developers, whose day jobs include work on large software systems (tens to hundreds of programmers) are involved with the development of RosAsm? I thought so. Does the phrase "the blind leading the blind" mean anything to you? I'm sure, in your state of ignorance, you think that what you're doing is "team programming." The truth is, you only think this because you don't know any better. Those who've actually done some *real* software engineering in their lifetimes are laughing at you behind your backs. > >> "They *really, really* don't understand how team project management >> should be done." > > So, pls enlight us with your "universal" knowledge. Pick up any decent book on software engineering and team project management. Read it. Practice what it preaches. You will quickly discover *much* better ways of doing team projects. And you'll quickly discover that RosAsm is somewhat under-featured for such a task. > > If that means disseminating arrogancy or flames on our team of > co-workers...Sorry..this won´t happen :) You're already doing that. Rene's approach of "I'm not providing libraries because I want to force people to code the way I do" is a perfect example of such arrogance. If you weren't forcing people to work the way *you* wanted them too, you'd provide the static linking capability and let *them* choose how to write their code. > > A team work using different files and people thinking together of the > whole project is what a team work is based on. The way it is developed > is not different from other techniques of working in team you want to > impose... You've got it backwards. RosAsm's current development scheme is the one *forcing* things onto people. Forcing naming conventions for separate components (which wouldn't be necessary if you supported static linking with file-scope naming). Think about it. How would allowing people to work on modules as separate object files *force* your users to do something they're doing now? Heck, if they *wanted* to do the monolithic thing, they *still* could. It's your current scheme that adds the restrictions that force people to work a certain way. Cheers, Randy Hyde
From: Guga on 20 Sep 2005 15:48 Hi bertrand "(The file revision systems refer to CVS, SVN, VSS and such... )" Oh..i understood now...a version control system...No, we don´t use it. It wasn´t necessary pointing out line-by-line, all the differences in each released version. We constantly work on the program (Due to the newer developments it is pratically from weekly a new dev version is released), so nowadays, releasing on every new version the lines where the previous one was changed would be killing to maintain. Sometimes we announces the fixes or modifications of the part of the code on the board. If a user is interested in see the new version and learn how something new was built comparing to the older version, all he need to do is use a comparition Ascii tool to compare the source...i guess CVS uses windiff (Or something like that), but there are other good tools like winmerge that shows the differents better (At least better for me...i like winmerge :) ). A tool able to made some reports showing the differences between the newer and the older version is not a bad idea. But for now it is not maintainable...maybe in future some volunteer can work on something similar to it. (Not similar to CVS, but basically a tool able to build a brief report with the new changes comparing older versions. A sort of summary builder that will only export News.txt for example.) Best Regards, Guga
From: randyhyde@earthlink.net on 20 Sep 2005 15:54
Betov wrote: > > Linking to or include a library would make sense if the libraries > > would contain really useful things only. > > I haven't found any real good code in any yet. > > In the team, everybody is in this opinion too. And that's why RosAsm has so few users. Outside the RosAsm development team, most people don't share that opinion. > The (demential) > work, we are actually doing on the LibScanner The amazing thing is how much work you keep investing in different ways (disassembler, "lib scanner", etc.) to *avoid* the task of supporting statically linked code. Even given RosAsm's fundamental design flaws (like buring source code in EXE files) that make support of object-module generation difficult, it would be *far* less work in the long run to just bite the bullet and provide library/object module support for RosAsm than run off on all these other bizarre tangents. > - that will take > all of this in charge, anyway... No, it won't solve the fundamental problem that people want to produce object modules that they can link with their RosAsm code and with other code. You put in all this effort and waste all of this time creating all these half-baked applications that nobody really wants (and nobody really wants to learn *how* to use). People already know how to use linkers. They don't want to have to learn how to use a disassembler (and learn how to clean up incorrectly disassembled code) or use a "lib scanner" or use "TITLEs" or anything else to do what they already know how to do with libraries. Therefore, they use another assembler and ignore RosAsm. > - is, first, designed to create > a complete D.I.S. system, for the Disassembler. The disassembler failed to ignite the "assembly rebirth" so now it needs a "D.I.S." system. Or the Lib Scanner. Or whatever. The sooner you admit to yourself that you are simply wrong about static linking, and add that facility to RosAsm, the sooner people will seriously consider your product. > Another story... Another Failure.... Cheers, Randy Hyde |