Re: Team Development / Exporting stuff to text files
On Sun, Mar 9, 2008 at 7:49 AM, David Bovill <[EMAIL PROTECTED]> wrote: > and learn from them, and relatively quickly code your own thing. All that > is > great - but we miss out not being able to grab an open image browser > widget, altImageViewer at: http://www.altuit.com/webs/altuit2/altPluginDownload/Downloads.htm been free for anyone to use for a number of years now. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
On Sun, Mar 9, 2008 at 7:36 AM, David Bovill <[EMAIL PROTECTED]> wrote: > Well to bring out my 6 shooter - it means you don't talk about code you > supply a diff which does the talking for you. Just so I understand better, let me get this straight: A nice cvs system which supplies diffs will help us define a GUI for a property editor? Perhaps you have an example as I'm having a hard time grasping this new concept. Heck, if this works, then can we soon forgo all peace talks and let some Open Source version control system negotiate each countries 'diffs' for them? ;-) > 1) Rev's already verbose language pretty much negates the necessity of > > generic libraries. Can you state a library one would want which isn't > > already created? > > > Only around 20! To be concrete the libraries I've had to work on in the > past > due to a lack of community supplied libraries include: > > - Jabber > - Google Data > - Google spread sheets > - Google docs, calendar, picassa etc > - KML > - Flickr > - YouTube > - iCal > - vCal > - Blog XMLRPC api's > - del.icio.us > - RSS / ATOM > - JSON > - OPML > - Should I suppose the above are already Open Sourced and available to this community? If so, please point me to the documentation and source code for them, as I'd like to take a few for a spin. > It is in my opinion the main disadvantage of using Rev - and the main > reason > I dont use Rev for web based projects is precisely the lack of robust > tested > community provided libraries and applications. Perhaps it's because there just aren't enough Rev developers interested in the above libraries? That would be my best thinking on the subject. I wonder why. Those open source languages you mention started small with > only a few developers - Ruby? One of the differences was that those > developers worked together on code libraries that fed back into the > community - while Rev projects remain individualistic. It's not the only > factor - but Id argue it a factor. My point was there just isn't a large enough base of developers. Even though most of the Open Source projects I previously mentioned only started with a few programmers, there are literally millions of C programmers in the world. Rev has at least 2 orders of magnitude less to draw from...probably fewer. > Agreed. Though in my oppinion RunRev would be worth far more than it is > today if it had pursued an open source model along the lines of MySQL six > or > so years ago, or took a root similar to the one that FLEX / Adobe AIR have > taken recently - I suspect they missed the boat on that one. While you are certainly entitled to your own view, I disagree completely with it. Like it or not, Rev has succeeded where all other xtalk platforms have failed. They still have a valid business model which sustains their development. Their sales numbers increase each year and they continue to create a product, which by all measures is a significant engineering feat, without destroying their existing developer base in the process. My hat's off to Kevin and his team for not pursuing a doomsday scenario like the one you have described. To that list you could also add cgi/RevOnRockets based web applications, or > robust flexible widgets like trees, forms and form controls, image and > video > widgets, outliners, image browsers, remote file browsers... One step forward, two steps back. I thought we already had agreed, creating easy to use generic libraries for tree widgets, remote file browsers, was not really feasible currently without some sort of true object model. Also, most of us have some sort of our own versions of each of these, which we can 'tune' to whatever need we want fairly quickly. > And I'd argue that without a change in the current way stack based > community > development projects are supported there will be little in the way of > community contributed web applications for RevOnRockets. Which I think we > would both agree would be a pity. Frankly, what motivates me to contribute to RevOnRockets, isn't what others can or will build with it. It's what I can do with it. So, if there are no other spin-off projects, it won't really matter to me. I do agree there really isn't a market or any sort of ROI for these type of products in the Rev community, and mostly they are created by the goodwill and generosity of a few talented programmers. David, I understand you are an Open Source advocate. I, too, enjoy the fruits of Open Source, and here at Altuit we occasionally contribute to different Open Source initiatives as well. It's just that for a commercial developer, who has to pay rent at the end of the month, there is very little which a zealous Open Source strategy can do for us. You've touted Open Source many times on this list. Why don't you pick a subject and try and create and promote an Open Source project of your own? Perhaps you have and I just don't know about it. But, don't blame it on a lack of a decent Rev
Re: Team Development / Exporting stuff to text files
I don't even know where to start. Holy cow. On Mar 9, 2008, at 10:28 AM, David Bovill wrote: On 09/03/2008, Jerry Daniels <[EMAIL PROTECTED]> wrote: Guys I can't believe you fellows are talking about libraries at a time like this. Sir Paul McCartney is going through a messy divorce and will have to pimp out the Beatles to El Jobso / iTunes to make it happen. He needs our support (McCartney)! Wasn't it the Beetles who came up with Apple first? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
On 09/03/2008, Jerry Daniels <[EMAIL PROTECTED]> wrote: > > Guys > > I can't believe you fellows are talking about libraries at a time like > this. Sir Paul McCartney is going through a messy divorce and will > have to pimp out the Beatles to El Jobso / iTunes to make it happen. > He needs our support (McCartney)! Wasn't it the Beetles who came up with Apple first? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
Guys I can't believe you fellows are talking about libraries at a time like this. Sir Paul McCartney is going through a messy divorce and will have to pimp out the Beatles to El Jobso / iTunes to make it happen. He needs our support (McCartney)! Jerry Daniels & Mara, Inc. Makers of GLX2 http://www.daniels-mara.com/glx2 IF YOU JUST TURN AROUND WHILE YOU'RE REMINISCING, YOU CAN SEE INTO THE FUTURE. On Mar 9, 2008, at 7:36 AM, David Bovill wrote: On 09/03/2008, Chipp Walters <[EMAIL PROTECTED]> wrote: As Richard said, I find stacks the idea binary data storage container, too. In fact many of our customers apps have stack based document files, which have zero business logic and in fact are never seen by the user. Works great. And, if for some reason you need an intermediary format, one can quickly be written to convert a stack to whatever format is needed. OK XML is a bit problematic as a file format. It's much better as an intermediary storage format, but not necessarily a good idea as an application file format. Just look at Microsoft's Open XML format who's spec is several thousand pages long, and one can quickly see it's not a very efficient document format. While it might be great for exchanging data between programs, it's slower to load and more difficult to navigate. Yes I also agree with Richard regarding our joint property inspector project. The problem wasn't version control at all-- nor was it our ability to communicate with each other. It turned out it took more time to talk about the project, than just create the damn thing. So, now there are 3 different free property editors, one by each of us. Anyone can take their pick. That said, IMO, talking wasn't a waste of time. And I really don't know what "talking through improving shared code" means. Sounds like I may need to light some incense? Well to bring out my 6 shooter - it means you don't talk about code you supply a diff which does the talking for you. I don't think so. Frankly, I believe there are 4 main reasons for a lack of quality libs: 1) Rev's already verbose language pretty much negates the necessity of generic libraries. Can you state a library one would want which isn't already created? Only around 20! To be concrete the libraries I've had to work on in the past due to a lack of community supplied libraries include: - Jabber - Google Data - Google spread sheets - Google docs, calendar, picassa etc - KML - Flickr - YouTube - iCal - vCal - Blog XMLRPC api's - del.icio.us - RSS / ATOM - JSON - OPML - That is not to include more general stuff like outline, array, or specific stuff like wiki text parsers, or all the open source web based projects I would include in this bracket. Is there a reason why a wiki, or a blog is not available for me to customise written in Transcript??? Because the language is not suitable for the purpose? More suitable than php 4? When I take a look at the early web applications I think that would be pretty easy to write in Transcript, but its easier now to take an open source project and customise it than rewrite it in Transcript. So I would add to the above list all the web based projects that could be written in Transcript / RevOnRockets but haven't been. It is in my opinion the main disadvantage of using Rev - and the main reason I dont use Rev for web based projects is precisely the lack of robust tested community provided libraries and applications. 2) Adding commercial grade generic libs and objects, like a great grid object, currently isn't really feasible via scripting, and is also not possible using externals. Until there's a real object model in Rev, this continues to be a problem. No number of cvs or open source programmers can fix this. Agreed. 3) Small community of Rev experts willing to work on libraries. The number of Rev users is very very small. Even smaller is the number of Rev expert programmers, who could tackle difficult library chores. This isn't the case with most Open Source projects, like Gimp, Linux, etc.. I wonder why. Those open source languages you mention started small with only a few developers - Ruby? One of the differences was that those developers worked together on code libraries that fed back into the community - while Rev projects remain individualistic. It's not the only factor - but Id argue it a factor. 4) Very difficult financial model for even Open Source developers. I don't know of any company (like Sun, Google, IBM) who would consider sponsoring a Rev Open Source development project. Even for commercial Rev tools, the market is severely limited, and I'm not aware of a single developer who makes a living selling into the Rev Tools market. I suspect Jerry Daniels is probably the closest, and I know he has several ongoing gigs which keep him whole. Years ago, Altuit tried marketing products i
Re: Team Development / Exporting stuff to text files
Sorry the question was cut off What things - tools or actions would help produce more community produced > libraries? - Jabber - Google Data - Google spread sheets - Google docs, calendar, picassa etc - KML - Flickr - YouTube - iCal / vCal - Blog XMLRPC api's - del.icio.us - RSS / ATOM - JSON - OPML - To that list you could also add cgi/RevOnRockets based web applications, or robust flexible widgets like trees, forms and form controls, image and video widgets, outliners, image browsers, remote file browsers... In terms of the libraries listed above and there are many more the majority do not exist, in terms of the stack based projects or controls listed - you can in general after a bit of searching around find a lot of community provided stacks that do something like you want - you can take them apart and learn from them, and relatively quickly code your own thing. All that is great - but we miss out not being able to grab an open image browser widget, or customise a RevOnRockets Blog, or use a JSON library. What would help? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
On 09/03/2008, Chipp Walters <[EMAIL PROTECTED]> wrote: > > As Richard said, I find stacks the idea binary data storage container, > too. > In fact many of our customers apps have stack based document files, which > have zero business logic and in fact are never seen by the user. Works > great. And, if for some reason you need an intermediary format, one can > quickly be written to convert a stack to whatever format is needed. OK XML is a bit problematic as a file format. It's much better as an > intermediary storage format, but not necessarily a good idea as an > application file format. Just look at Microsoft's Open XML format who's > spec > is several thousand pages long, and one can quickly see it's not a very > efficient document format. While it might be great for exchanging data > between programs, it's slower to load and more difficult to navigate. Yes I also agree with Richard regarding our joint property inspector project. > The problem wasn't version control at all-- nor was it our ability to > communicate with each other. It turned out it took more time to talk about > the project, than just create the damn thing. So, now there are 3 > different > free property editors, one by each of us. Anyone can take their pick. That > said, IMO, talking wasn't a waste of time. And I really don't know what > "talking through improving shared code" means. Sounds like I may need to > light some incense? Well to bring out my 6 shooter - it means you don't talk about code you supply a diff which does the talking for you. I don't think so. Frankly, I believe there are 4 main reasons for a lack of > quality libs: > > 1) Rev's already verbose language pretty much negates the necessity of > generic libraries. Can you state a library one would want which isn't > already created? Only around 20! To be concrete the libraries I've had to work on in the past due to a lack of community supplied libraries include: - Jabber - Google Data - Google spread sheets - Google docs, calendar, picassa etc - KML - Flickr - YouTube - iCal - vCal - Blog XMLRPC api's - del.icio.us - RSS / ATOM - JSON - OPML - That is not to include more general stuff like outline, array, or specific stuff like wiki text parsers, or all the open source web based projects I would include in this bracket. Is there a reason why a wiki, or a blog is not available for me to customise written in Transcript??? Because the language is not suitable for the purpose? More suitable than php 4? When I take a look at the early web applications I think that would be pretty easy to write in Transcript, but its easier now to take an open source project and customise it than rewrite it in Transcript. So I would add to the above list all the web based projects that could be written in Transcript / RevOnRockets but haven't been. It is in my opinion the main disadvantage of using Rev - and the main reason I dont use Rev for web based projects is precisely the lack of robust tested community provided libraries and applications. 2) Adding commercial grade generic libs and objects, like a great grid > object, currently isn't really feasible via scripting, and is also not > possible using externals. Until there's a real object model in Rev, this > continues to be a problem. No number of cvs or open source programmers can > fix this. Agreed. 3) Small community of Rev experts willing to work on libraries. The number > of Rev users is very very small. Even smaller is the number of Rev expert > programmers, who could tackle difficult library chores. This isn't the > case > with most Open Source projects, like Gimp, Linux, etc.. I wonder why. Those open source languages you mention started small with only a few developers - Ruby? One of the differences was that those developers worked together on code libraries that fed back into the community - while Rev projects remain individualistic. It's not the only factor - but Id argue it a factor. 4) Very difficult financial model for even Open Source developers. I don't > know of any company (like Sun, Google, IBM) who would consider sponsoring > a > Rev Open Source development project. Even for commercial Rev tools, the > market is severely limited, and I'm not aware of a single developer who > makes a living selling into the Rev Tools market. I suspect Jerry Daniels > is > probably the closest, and I know he has several ongoing gigs which keep > him > whole. Years ago, Altuit tried marketing products in this field, and we > ended up selling all our tools to Rev as we didn't think the ROI for us > was > worthwhile. Agreed. Though in my oppinion RunRev would be worth far more than it is today if it had pursued an open source model along the lines of MySQL six or so years ago, or took a root similar to the one that FLEX / Adobe AIR have taken recently - I suspect they missed the boat on that one. I'm not sure Rev is the ideal Open Source collaborative application > e
Re: Team Development / Exporting stuff to text files
David, As Richard said, I find stacks the idea binary data storage container, too. In fact many of our customers apps have stack based document files, which have zero business logic and in fact are never seen by the user. Works great. And, if for some reason you need an intermediary format, one can quickly be written to convert a stack to whatever format is needed. XML is a bit problematic as a file format. It's much better as an intermediary storage format, but not necessarily a good idea as an application file format. Just look at Microsoft's Open XML format who's spec is several thousand pages long, and one can quickly see it's not a very efficient document format. While it might be great for exchanging data between programs, it's slower to load and more difficult to navigate. I also agree with Richard regarding our joint property inspector project. The problem wasn't version control at all-- nor was it our ability to communicate with each other. It turned out it took more time to talk about the project, than just create the damn thing. So, now there are 3 different free property editors, one by each of us. Anyone can take their pick. That said, IMO, talking wasn't a waste of time. And I really don't know what "talking through improving shared code" means. Sounds like I may need to light some incense? You also say, "Code written by an individual remains that - individualistic. Is this not one of the reasons why there are so few commercial quality community created libraries or components?" I don't think so. Frankly, I believe there are 4 main reasons for a lack of quality libs: 1) Rev's already verbose language pretty much negates the necessity of generic libraries. Can you state a library one would want which isn't already created? Many less verbose languages end up creating vast libraries to do things like string handling, media management, etc.. Most of this is already handled in Rev by the engine. 2) Adding commercial grade generic libs and objects, like a great grid object, currently isn't really feasible via scripting, and is also not possible using externals. Until there's a real object model in Rev, this continues to be a problem. No number of cvs or open source programmers can fix this. 3) Small community of Rev experts willing to work on libraries. The number of Rev users is very very small. Even smaller is the number of Rev expert programmers, who could tackle difficult library chores. This isn't the case with most Open Source projects, like Gimp, Linux, etc.. 4) Very difficult financial model for even Open Source developers. I don't know of any company (like Sun, Google, IBM) who would consider sponsoring a Rev Open Source development project. Even for commercial Rev tools, the market is severely limited, and I'm not aware of a single developer who makes a living selling into the Rev Tools market. I suspect Jerry Daniels is probably the closest, and I know he has several ongoing gigs which keep him whole. Years ago, Altuit tried marketing products in this field, and we ended up selling all our tools to Rev as we didn't think the ROI for us was worthwhile. I'm not sure Rev is the ideal Open Source collaborative application environment. That said, I do plan on releasing sometime soon "Rockets CGI Editor" which will work with the free version of RevOnRockets. Though neither are collaborative in the way you are thinking, they should be quality products and free to use. -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
On 08/03/2008, Richard Gaskin <[EMAIL PROTECTED]> wrote: > > > A stack can be used as a data store only, separate from other stacks > which can be used for the UI, separate still from stacks used as > libraries to drive it all. True. Quite flexible, the stack object. H - lets put it the other way around. When is it a good idea to store data in a format other than a stack? How about: 1. If there is a need for the data to be used by other non-rev software or tools 2. If using a database makes the data easier to organise, maintain, or faster to access. 3. If very frequent changes to the data are likely and a full history of these changes is needed => use svn /cvs to save space? 4. ? Actually, in that case it wasn't for the lack of collaborative tools. > > In fact, rather the opposite: it's just so easy to write stuff in Rev > that simply doing so took less time than even talking about it. > > That's the other side of the collaboration equation which may have > little opportunity for tools support but where the greatest loss of > per-person productivity lies: talking, getting other team members to > first understand your own ideas and then to adopt them as their own. Yes - thats the other side of the equation, and yes talking is nearly always a waist of time :) I'd only add that svn / cvs collaboration tools aim to support collaboration via "talking through improving shared code". Adding programmers is expensive, and more expensive the more closely > their work overlaps, as it requires more talking. > > Splitting work up into black boxes lets each programmer contribute with > the productivity of a solo effort, yet allow the project to benefit from > having multiple components developed simultaneously. Yes. But you are not mentioning the dangers of such an approach. What happens when you want to update the software and the original programmer is not around??? The reason for paired programmers or svn like collaborative process is to evolve a code base which you can change programmers on without having to start again from scratch. Code written by an individual remains that - individualistic. Is this not one of the reasons why there are so few commercial quality community created libraries or components? Stacks work well for organizing the work into black boxes. True. It does seem a slight waist though to lock up all that super easy to read code in a black box - I mean I can understand that with C++ - but one of the great strengths of xTalk languages is the common sense easy to read nature of the code. An interesting point that Ben brought up off list was the ongoing change to the Flash community caused by moving over to text based file formats - the most obvious for now being the adoption of svn for source code management. Companies are already using cvs / svn systems for their php/python/ruby/html/css/javascript/whatever development. I'd also expect to see a much more robust open source community developing around the new XML based file formats - at least Adobe are betting on that? Certainly when I looked at Adobe AIR I thought that's exactly what I'd recommend for future Rev based tool development (though maybe not pure XML). ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
David Bovill wrote: Seperating data from code is surely a good idea and not one encouraged by the stack metaphor? A stack can be used as a data store only, separate from other stacks which can be used for the UI, separate still from stacks used as libraries to drive it all. Quite flexible, the stack object. Many moons ago, Richard, Jacque and myself tried to create a 'team approach' to creating a new property editor-- I believe we ended up each rolling our own. And that I would say is a classic story for many such Rev based collaborative projects. My opinion is that the amount of effort it takes to develop sufficiently robust collaborative tools is on par with the amount of effort it took RunRev to develop their IDE, anything that fall much short of that will be discarded by individual developers on the basis that their own ROI. They will end up rolling there own. Actually, in that case it wasn't for the lack of collaborative tools. In fact, rather the opposite: it's just so easy to write stuff in Rev that simply doing so took less time than even talking about it. That's the other side of the collaboration equation which may have little opportunity for tools support but where the greatest loss of per-person productivity lies: talking, getting other team members to first understand your own ideas and then to adopt them as their own. Even with something as simple as a property sheet we encountered a wide variety of differences in the details of each of our designs. In the end I donated the one I've been shipping with devolution for so many years, and left it for RunRev to do with it what they will. Seems even internally within a single company working through such design details takes time. ;) Adding programmers is expensive, and more expensive the more closely their work overlaps, as it requires more talking. Splitting work up into black boxes lets each programmer contribute with the productivity of a solo effort, yet allow the project to benefit from having multiple components developed simultaneously. Stacks work well for organizing the work into black boxes. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
On 05/03/2008, Chipp Walters <[EMAIL PROTECTED]> wrote: > > David, another point to understand is the recompilation of a complete > stack from text files, is a very difficult, if not impossible task to > undertake. I should know. I worked with David Johnson for over a year > on a sharing toolkit (RevShare) which allowed users to update in > realtime each others projects over the internet. It was a complex > issue and one where I concluded it could not be done solely via text > data. > > In particular, IIRC, the following properties couldn't be trusted to > always convert exactly: > > "id" > "visited" > "layer" > "armed" > "htmlText" Interesting - I don't understand the issues with htmltext and armed, and particularly string the htmltext of a field should be unproblematic - can you remember the problems there? But yes - I agree that to try to create a robust text file format for collaborating on a "generic" stack is pretty well impossible. However to do so for very specific things which you design for multi-developer collaboration is possible. In articular if you are creating generic components which do not depend on ids or the layer I think it is possible - or at least I cant find a problem with it. Not to mention all of the images, movies, etc..which would need to be > managed as well. All in all, I doubt one will find a better > 'container' for managing such stuff than the stack itself. Agreed - but you'd have to add to that that it is good practice to not go too far with that. I for one got myself in a bunch of trouble a few years back storing everything in the stack - text and images ending up with large stacks that were hard to maintain. Seperating data from code is surely a good idea and not one encouraged by the stack metaphor? If you agree to that point I think you can see there is some room for structuring the way stacks are designed and stored to facilitate collaboration - this includes naming conventions, how to deal with "data" vs code type issues. I for one think a modified MVC approach and naming conventions enhance the stack based collaboration model here. Furthermore, if open source was such a grand concept for the Rev > community as a whole, why haven't we seen more of it? My view is that one factor is the lack of high quality collaborative tools, another major factor (perversely) is the ease of solo development. Combine these and the incentives for collaborative development are not there. My personal > opinion, is like many of my plugins, and other free Rev stuff, they > really only need a single person to code it. Definitely agree. Many moons ago, Richard, > Jacque and myself tried to create a 'team approach' to creating a new > property editor-- I believe we ended up each rolling our own. And that I would say is a classic story for many such Rev based collaborative projects. My opinion is that the amount of effort it takes to develop sufficiently robust collaborative tools is on par with the amount of effort it took RunRev to develop their IDE, anything that fall much short of that will be discarded by individual developers on the basis that their own ROI. They will end up rolling there own. That said, the MetaCard project, I suppose could be included as a > successful open source project, but it was pretty much well on it's > way BEFORE being open sourced. Yes - thanks to Scott insisting on it, and Richard et als dedication. To develop a collaborative framework for RunRev (svn style) takes a level of investment on par with the investment put into MC IDE, RunRevs IDE or Galaxy. I've got maybe 2-3 man-years investment in the environment I use, but I figure it would take another 3-6 months full time work to finish it. I also figure it would not be worth "my" while to do that based on ROI, Others I think have reached a similar conclusion for their own projects. It's classic "prisoners dilemma" stuff. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
Richard, thanks...couldn't have said it better..but I will add a footnote... David, another point to understand is the recompilation of a complete stack from text files, is a very difficult, if not impossible task to undertake. I should know. I worked with David Johnson for over a year on a sharing toolkit (RevShare) which allowed users to update in realtime each others projects over the internet. It was a complex issue and one where I concluded it could not be done solely via text data. In particular, IIRC, the following properties couldn't be trusted to always convert exactly: "id" "visited" "layer" "armed" "htmlText" Perhaps there were more. But creating a perfect copy of a control on one stack from a text string from another stack was difficult. I had an object checksum function, and I had to remove the above properties from it as I could not depend on accurate control management without. Not to mention all of the images, movies, etc..which would need to be managed as well. All in all, I doubt one will find a better 'container' for managing such stuff than the stack itself. Furthermore, if open source was such a grand concept for the Rev community as a whole, why haven't we seen more of it? My personal opinion, is like many of my plugins, and other free Rev stuff, they really only need a single person to code it. Many moons ago, Richard, Jacque and myself tried to create a 'team approach' to creating a new property editor-- I believe we ended up each rolling our own. That said, the MetaCard project, I suppose could be included as a successful open source project, but it was pretty much well on it's way BEFORE being open sourced. -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
On 05/03/2008, Richard Gaskin <[EMAIL PROTECTED]> wrote: > > David Bovill wrote: > > > That said, I suppose if we look at all possible scenarios we could find > circumstances for which a finer level of granularity may have a positive > ROI. We've found no significant limitations with stack-based > check-in/check-out thus far, but in the infinite range of all > possibilities I can't rule out that we might be able to lower our costs > even more with a different way of working. Richard - I don't think you got the point of what i was trying to say. I am agreeing with you. There is no ROI for finer granularity approaches - in any circumstance. 100% agreement on that. What I am trying to say is that the approach of open source development is not one of ROI - it is a loss to the developer, gained back if ever indirectly in terms of peer reputation. I am argueing for svn like tools not based on ROI for the developer but ROI at the community level. SVN like tools support the sacrifice in terms of productivity that a developer gives when engaging in open source development to make this sacrifice tolerable. I am saying that current stack based approaches are not succeeding over many many years in producing collaboratively evolved high quality libraries or tools. This is in stark contrast to projects that do use svn like tools - there is a reason to think that there may be a link between these factors. Though it is definitely not the only reason. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
David Bovill wrote: >> On Tue, Mar 4, 2008 at 11:58 AM, Richard Gaskin >> > I've thought about the type of scenarios described here, in >> > which two or more programmers may be assigned to work on the >> > same stack, but to be honest to me that seems less a technical >> > challenge than an architectural and human resources one >> > On 05/03/2008, Chipp Walters wrote: >> Agreed 100%. >> >> Key word in the below sentence is "architectural". IMO, a properly >> designed architecture can handle multiple programmers, each working >> on their own stacks. > > Agreed as well - but in the context of your own or a relatively small > groups productivity. That is it is not worth going down the path of > svn or finer granularity for your own productivity, unless perhaps > you and your team are already familiar with such tools and working > practices based on other languages. If you're bringing in developers familiar with other languages, the learning curve for something as simple as Magic Carpet is trivial compared to the time to learn how to use Rev itself effectively (not to mention the additional time needed to figure out a scheme for integrating Rev with something like SVN, and the day-to-day overhead inherent in using such a scheme). Rev isn't just another language. It's also an object model and file format, all bound together to create a unique way of working. I'm not sure tools designed for other languages can always be expected to integrate gracefully well a Rev workflow. Admittedly my own experience is perhaps limited, having managed xTalk-based projects with only 25 developers at most. But that's a fair number of developers, for a project whose budget was well over a million dollars. Projects of that scope are rare, but it's worth noting that it was done with a stack-based check-in/check-out, with significant cost savings to both our team and the client. That said, I suppose if we look at all possible scenarios we could find circumstances for which a finer level of granularity may have a positive ROI. We've found no significant limitations with stack-based check-in/check-out thus far, but in the infinite range of all possibilities I can't rule out that we might be able to lower our costs even more with a different way of working. Chipp's Magic Carpet is a very capable stack-level tool available now, and being such a with-the-grain way of working with Rev it's not too hard to craft on of your own if you need to. If tools supporting a finer level of granularity exist and are demonstrated to provide a higher ROI than the many projects delivered with stack-based tools, I'd certainly be interested in checking them out (if you'll pardon the pun). -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
Agreed as well - but in the context of your own or a relatively small groups productivity. That is it is not worth going down the path of svn or finer granularity for your own productivity, unless perhaps you and your team are already familiar with such tools and working practices based on other languages. However if you are to look at the picture at a different scale and ask - do the stack based working practices facilitate the creation of robust community resources and libraries? Then I would argue that open source tools and methodology / svn type tools have a track record in producing well tested libraries and tools which the stack based methods have singularly failed to do. A commercial market for components can work if the tool market is big enough, and open source communities can sometimes deliver such tools. It is an interesting question whether svn like tools would help create larger scale community collaborations in Rev, but I certainly agree that for the individual developer their is no productivity gain - for the community as a whole is another question. On 05/03/2008, Chipp Walters <[EMAIL PROTECTED]> wrote: > > Agreed 100%. > > Key word in the below sentence is "architectural". IMO, a properly > designed architecture can handle multiple programmers, each working on > their own stacks. After all, remember, one can insert 50 stack > libraries into the message path. > > best, > > > Chipp > > > On Tue, Mar 4, 2008 at 11:58 AM, Richard Gaskin > <[EMAIL PROTECTED]> wrote: > > > I've thought about the type of scenarios described here, in which two > or > > more programmers may be assigned to work on the same stack, but to be > > honest to me that seems less a technical challenge than an > architectural > > and human resources one: > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
Agreed 100%. Key word in the below sentence is "architectural". IMO, a properly designed architecture can handle multiple programmers, each working on their own stacks. After all, remember, one can insert 50 stack libraries into the message path. best, Chipp On Tue, Mar 4, 2008 at 11:58 AM, Richard Gaskin <[EMAIL PROTECTED]> wrote: > I've thought about the type of scenarios described here, in which two or > more programmers may be assigned to work on the same stack, but to be > honest to me that seems less a technical challenge than an architectural > and human resources one: ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Team Development / Exporting stuff to text files
what do u think u are doing i singned up yesterday> Date: Tue, 4 Mar 2008 09:07:39 +> From: [EMAIL PROTECTED]> To: use-revolution@lists.runrev.com> Subject: Team Development / Exporting stuff to text files> > I wrote (probably in a moment of fairly naive> euphoria):> > "it would be perfectly possible to write a> description in the text format and write a reader to> reimport that to make a stack!"> > Well, I suppose it would.> > BUT> > It would probably then be necessary to spit out> details of ALL properties for each object (472 last> time I looked) which would be both silly and involve a> lot of redundancy . . .> > feedback required . . .> > sincerely, Richmond> > > > A Thorn in the flesh is better than a failed Systems Development Life Cycle.> > > > __> Sent from Yahoo! Mail.> A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html> ___> use-revolution mailing list> use-revolution@lists.runrev.com> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:> http://lists.runrev.com/mailman/listinfo/use-revolution _ Overpaid or Underpaid? Check our comprehensive Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fcontent%2Emycareer%2Ecom%2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810&_t=766724125&_r=Hotmail_Email_Tagline_MyCareer_Oct07&_m=EXT___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
Stephen Barncard wrote: It would probably then be necessary to spit out details of ALL properties for each object (472 last time I looked) which would be both silly and involve a lot of redundancy . . . 1. who cares about redundancy? 2. The entire list of properties in an object can be made into an array (and saved as a single prop set) 3. Only non-stock differences in a created object need to be logged. True. I don't do much with textual descriptions of objects any more, but back in the days when I used to play with such things I stored only the deltas from the default state of template objects. If you reset the template objects after use this is a simple and efficient way to recreate objects from the smallest descriptions possible. But stepping back to look at the bigger picture, I've not yet understood the practical benefit of focusing on this fine level of granularity for team development in Rev. My own experiments with textual descriptions were to craft a 5GL for rapidly creating objects using an ultra-lightweight "markdown" syntax in the Message Box. Fun at the time, but I can't say I've been motivated to refine it in many years. :) For actually sharing objects among team members it's hard to beat the efficient, compact binary representation you get naturally in a stack file. I've thought about the type of scenarios described here, in which two or more programmers may be assigned to work on the same stack, but to be honest to me that seems less a technical challenge than an architectural and human resources one: If the code in a dialog is so complex that it takes two programmers to work on it, how did it become so complex? - Is there anything in it which might be useful elsewhere like a library so it could be used by other parts of the system, or perhaps even similar systems in the future? - How does that window interact with the rest of the system? - Were the gozintas and gozouttas (inputs and outputs) of the window clearly defined during the architecture phase? - Are the connections between this window and other parts of the system defined well enough to support both unit testing and extensibility? - If two programmers are each working on a different button in the same window, what do they do if they need to add something to the card or stack script for all buttons to use? - If they're working independently, how would they even discover such common needs? - Does the project management system support a level of granularity down to the handler level? - Down to the line of code? - Down to the token? As granularity increases, so do the questions about managing the workflow. In his book "Rapid Development", Steven McConnell cites stats from the ACM and elsewhere about the relationship between productivity and team size. The exact measurements will of course vary based on many factors, but he feels that a good general rule of thumb is that a second programmer will add only 50% more productivity to the effort, a third adds roughly 30%, etc. This is because of the high overhead involved in coordination and communication among team members (not to mention the dreaded weekly status reports, which he has a lot to say about also ). Of course there's much to be said for "Xtreme Programming" practices, but even then this rule of thumb generally holds true, with the difference being that the productivity unit being measured isn't a single programmer but a pair of programmers. The key to this measurement is people per module; even in an XP shop, you'll see lower per-person productivity as you add more human resource units (paired programmers) to a given module. Sometimes a module is simply big enough that it may need that. But more often, when it gets that complex it can be broken down into multiple modules even more easily, simplifying not only team management but also the code itself. McConnell's stats seem to reinforce the usefulness of architecting modules as "black boxes", so that each team member (or pair in XP) is essentially building a discrete subsystem, its own "mini-program" if you will, with well-defined gozintas and gozouttas. In Rev, this translates most naturally to stacks, whether UI windows or code libraries. With 50 libraries, 10 backscript, and 10 frontscripts available at runtime, there are many ways to divide functionality into discrete logical units. Chipp, Ken, and the others here who regularly employ multiple team members to deliver commercial products seem consistent in their use of stacks as work units. The correlation between their prolific output, ROI, product quality, and the use of stacks as the shared work unit may be more than coincidental. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists
Re: Team Development / Exporting stuff to text files
It would probably then be necessary to spit out details of ALL properties for each object (472 last time I looked) which would be both silly and involve a lot of redundancy . . . 1. who cares about redundancy? 2. The entire list of properties in an object can be made into an array (and saved as a single prop set) 3. Only non-stock differences in a created object need to be logged. feedback required . . . sincerely, Richmond -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
The way I've done it in the past is to have a "template" for each type of object that contains the default values. This gets stored once for each object type, then for each object just send the properties that have changed from the default. All the Best Dave On 4 Mar 2008, at 09:07, Richmond Mathewson wrote: I wrote (probably in a moment of fairly naive euphoria): "it would be perfectly possible to write a description in the text format and write a reader to reimport that to make a stack!" Well, I suppose it would. BUT It would probably then be necessary to spit out details of ALL properties for each object (472 last time I looked) which would be both silly and involve a lot of redundancy . . . feedback required . . . sincerely, Richmond A Thorn in the flesh is better than a failed Systems Development Life Cycle. __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
Perhaps the way to solve this would be to dump all the properties of the template objects of this stack and then dump only properties of the objects that are different than the templates. This buys you a couple of things: 1) You only dump what's different 2) If someone has modified their template objects for a particular project (say text font) and most of the objects in the stack used this new object instead of the one that comes with Rev out of the box, you'd have a smaller export file. 3) It would give you a fairly simple way to make wholesale changes to a stack by modifying the text file and reloading. For example, if you wanted to change the type face completely across an app, if you exported the stack as text, then changed the type face in the saved text file (only on the template object(s)), then reloaded, you'd end up changing all of the objects by changing one line! Handy. len morgan Richmond Mathewson wrote: I wrote (probably in a moment of fairly naive euphoria): "it would be perfectly possible to write a description in the text format and write a reader to reimport that to make a stack!" Well, I suppose it would. BUT It would probably then be necessary to spit out details of ALL properties for each object (472 last time I looked) which would be both silly and involve a lot of redundancy . . . feedback required . . . sincerely, Richmond A Thorn in the flesh is better than a failed Systems Development Life Cycle. __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
not necessarily all. Majority of them have default values that in many cases mean "empty" :-). All the best! Viktoras Richmond Mathewson wrote: I wrote (probably in a moment of fairly naive euphoria): "it would be perfectly possible to write a description in the text format and write a reader to reimport that to make a stack!" Well, I suppose it would. BUT It would probably then be necessary to spit out details of ALL properties for each object (472 last time I looked) which would be both silly and involve a lot of redundancy . . . feedback required . . . sincerely, Richmond A Thorn in the flesh is better than a failed Systems Development Life Cycle. __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Team Development / Exporting stuff to text files
I wrote (probably in a moment of fairly naive euphoria): "it would be perfectly possible to write a description in the text format and write a reader to reimport that to make a stack!" Well, I suppose it would. BUT It would probably then be necessary to spit out details of ALL properties for each object (472 last time I looked) which would be both silly and involve a lot of redundancy . . . feedback required . . . sincerely, Richmond A Thorn in the flesh is better than a failed Systems Development Life Cycle. __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Team Development / Exporting stuff to text files
Yes, Jim Lambert, you are quite right! Just uploaded new version of 'Textifier' with an answer dialog. sincerely, Richmond A Thorn in the flesh is better than a failed Systems Development Life Cycle. __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
Chipp & Richmond gave two nice handlers for exporting scripts to a text file. I offer one suggestion as someone who likes to avoid unnecessary work. When handlers like these have a lot of work to do, I generally prefer to put the 'ask file' right up front. That way, if a user cancels - no need for the handler to do all that unappreciated work. ;) Jim Lambert ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Team Development / Exporting stuff to text files
Removed my SS.rev stack from revOnline and replaced it with: wait for it . . . SS.rev !!! but now listed as 'Textifier'; this will now export a fairly comprehensive description of a stack and its substacks; such that it would be perfectly possible to write a description in the text format and write a reader to reimport that to make a stack! This could be useful for a collaborative effort where not all the developers feel financially secure enough to buy full-blown versions of Runtime Revolution. sincerely, Richmond Mathewson A Thorn in the flesh is better than a failed Systems Development Life Cycle. __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Team Development / Exporting stuff to text files
However; my stack is not much good as, if the stack has substacks SS.rev seems to forget about the mainstack . . . needsa bit more work! Love, Richmond A Thorn in the flesh is better than a failed Systems Development Life Cycle. __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Team Development / Exporting stuff to text files
Chipp wrote:
"You mean something like?
on mouseUp
repeat with x = 1 to the number of cds in this stack
put the long name of cd x &cr& the script of cd x
&cr&cr after tScripts
repeat with y=1 to the number of controls on cd x
put the long name of control y of cd x &cr& the
script of
control y of cd x &cr&cr after tScripts
end repeat
end repeat
answer file "Text file to export scripts to:"
if it is empty or the result is "cancel" then exit
to top
put tScripts into URL ("file:" & it)
end mouseUp"
no, not really:
on mouseUp
palette "SS"
--get the name of toplevel stack
put the topstack into fld "fTARGET"
put " " into PHPHSCRIPTS
put 1 into XXX
-- snatches scripts from main stack
--
put the num of cds of stack fld "fTARGET" into
CDNUMS
repeat with K= 1 to CDNUMS
put the num of controls of cd K of stack fld
"fTARGET" into KONTROLS
repeat with M= 1 to KONTROLS
put XXX into fld "Z"
put fld "fTARGET" && "CARD:" && K && the short
name of control M of cd K of stack fld "fTARGET" &&
the script of control M of cd K of stack fld "fTARGET"
into fld "fSCRIPTS"
put fld "fSCRIPTS" into PHSCRIPTS
put PHSCRIPTS && PHPHSCRIPTS into ADDER
PUT ADDER into PHPHSCRIPTS
put ADDER into fld "fADDER"
put XXX + 1 into YYY
put YYY into XXX
end repeat
end repeat
-- snatches scripts from sub-stacks
--
put the substacks of stack fld "fTARGET" into fld
"fSUBS"
repeat for each line I in fld "fSUBS"
put the num of cds of stack I into CDNUMS
repeat with K= 1 to CDNUMS
put the num of controls of cd K of stack I into
KONTROLS
repeat with M= 1 to KONTROLS
put XXX into fld "Z"
put I && "CARD:" && K && the short name of
control M of cd K of stack I && the script of control
M of cd K of stack I into fld "fSCRIPTS"
put fld "fSCRIPTS" into PHSCRIPTS
put PHSCRIPTS && PHPHSCRIPTS into ADDER
PUT ADDER into PHPHSCRIPTS
put ADDER into fld "fADDER"
put XXX + 1 into YYY
put YYY into XXX
end repeat
end repeat
end repeat
--- saves snatch scripts where you
want them ---
ask file "NAME SNATCHED SCRIPTS FILE:" with
"SSCRIPTS.txt"
if the result = "cancel" then exit mouseUp
put it into tFName
if char -4 to -1 of tFName is not ".txt" then put
".txt" after tFName
put field "fADDER" into url("file:" & tFName)
---
toplevel "SS"
end mouseUp
"Or..are you getting the scripts of substacks as
well?"
Yes:
here is an example of the output:
SubOne CARD: 1 Button on mouseUp
---eat my socks
end mouseUp
stack "/Users/jrm/Desktop/Fun/MainOne.rev" CARD: 1
Button on mouseUp
beep
end mouseUp
Download the stack and "give it a whirl".
Love, Richmond
A Thorn in the flesh is better than a failed Systems Development Life Cycle.
__
Sent from Yahoo! Mail.
A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Team Development / Exporting stuff to text files
You mean something like?
on mouseUp
repeat with x = 1 to the number of cds in this stack
put the long name of cd x &cr& the script of cd x &cr&cr after tScripts
repeat with y=1 to the number of controls on cd x
put the long name of control y of cd x &cr& the script of
control y of cd x &cr&cr after tScripts
end repeat
end repeat
answer file "Text file to export scripts to:"
if it is empty or the result is "cancel" then exit to top
put tScripts into URL ("file:" & it)
end mouseUp
Or..are you getting the scripts of substacks as well?
The real problem, is capturing all the controls and their properties
and exporting to text, then being able to import them back in. I
believe Geoff Canyon, a long time ago in a galaxy far far away did
something like that.
-Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Team Development / Exporting stuff to text files
For what it is worth . . . Have just uploaded "SS.rev" to revOnline (also available at my main Yahoo Group): it is the seed of a stack to export 'everything' to a text file: as it stands it exports all the scripts in a stack. If anybody can use it / modify it for use: it is there for them! Love, Richmond A Thorn in the flesh is better than a failed Systems Development Life Cycle. __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
