RexxLA Vice President wrote: > As Rick hasn't addressed your points about SlickEdit, let me add my two > cents... > > Most (all?) of the developers of ooRexx are long time users of SlickEdit > and many of us that just write Rexx scripts are too. There is a long > history of communication between the SlickEdit developers and the RexxLA > and we have had several presentations by them at past Symposia, the > latest being this year's in Raleigh. There has been an effort by the > members, principally Rony Flatscher and Michael Lueck, to add "support" > for ooRexx to the editor, which is in use by many of us but not all of > it has been "folded back" into the editor so it must be "re-done" for > each new release. We'd like to move this forward but the "business > case" on their part is pretty weak. And then there is the work that > needs to be done to keep that "support" is sync with the changes being > made to ooRexx which we, as owners of the project, need to do. > > I am very pleased to hear that. I am long time user of SlickEdit and feel compelled to give them a testimony whenever I get the opportunity. For a company that deals with the cutting edge they have never forgotten the mainframe! > Not sure what the reference to the "list" of editors is all about; can > you expand on that? There is a list of Rexx friendly editors on your SourceForge site, with no mention of SlickEdit.
http://oorexx.wiki.sourceforge.net/REXX+Friendly+Editors > And before you tackle any enhancements to > SlickEdit, let's share what has already been done. No sense > re-inventing the wheel! > > David Crayford wrote: > >> Rick McGuire wrote: >> >> >>> On Mon, Jul 21, 2008 at 7:50 AM, David Crayford <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>>> Thanks Rick, comments below... >>>> >>>> Rick McGuire wrote: >>>> >>>> >>>> >>>>> Standard library objects need to be used with care because of storage >>>>> management issues. Much of the internals of the interpreter is >>>>> implemented using objects that are allocated from the Rexx-managed >>>>> heap. These objects need to be constructed such that they are >>>>> compatible with that memory management system, which the standard >>>>> library objects are not. >>>>> >>>>> >>>> STL objects have associated allocator policies. I've seen this used to >>>> create STL >>>> containers using UNIX shared memory. It's tricky, best left in the "too >>>> hard" basket. I take it >>>> it's ok to use STL algortihms? >>>> >>>> >>> There are issues beyond just where the memory is allocated from. Any >>> Rexx object >>> allocated from the Rexx heap needs to be a subclass of RexxInternalObject >>> and >>> participate in the mark-and-sweep operations by implementing the >>> live() and liveGeneral() >>> methods. I think it's closer to the "not possible" basket than just >>> merely being "too hard". >>> >>> >>> >> The lightbulb has just lit up and is shining brightly! I noticed the >> live marking methods and presumed it was a >> mark-and-sweep garbage collection scheme similar to Java. I would love >> to understand the high level details >> of how it works, scopes etc. In the C++ programming I do it's quite >> common to use a smart pointer >> like shared_ptr. I don't fully understand mark-and-sweep but I want to! >> >> >>> I'm not sure I understand what you mean by STL algorithms. >>> >>> >>> >> A simple use case is the min and max template functions. >> >> >>>>> As far as coding standards, a lot of the code is in transition from >>>>> the coding standard I used in 1995 and the coding standard I prefer >>>>> now. I don't like to get involved with the curly brace argument on >>>>> placement and other stuff, but there are probably 3 "rules" I'd like >>>>> to see followed: >>>>> >>>>> 1) Code indentation should be 4 spaces (the older code uses 2) >>>>> 2) All if, for, while, etc. constructs should have curly braces >>>>> (i.e., no "if (a = b) c = d;". The older code did not use that style, >>>>> and I've been making a point of correcting this whenever I happen to >>>>> be making changes in code that hasn't been converted yet. I will >>>>> never object to anybody doing the same. >>>>> 3) No had tabs. indentation should be done with spaces. >>>>> >>>>> >>>>> >>>> Great, perfectly suits my style. I use the SlickEdit editor which >>>> introduced adaptive formatting in the >>>> latest release. It adapts code assists to the convention it detects when >>>> it opens the file. Brace style, indentation etc. >>>> SlickEdit has very good support for classic REXX, including basic >>>> context assist. Can I suggest that you add it your >>>> list of editors that support REXX on your website. SlickEdit have >>>> recently started to release instructions on >>>> how to create user extensions to support proprietary languages. I'll put >>>> this on my todo list for ooRexx. >>>> >>>> >>>> >>>>> Other than that, I'm pretty flexible. Back in 1995, we tended to use >>>>> line comments that had the /* and */ in specific columns. I prefer >>>>> using the // form now. I don't see any need for changing the style >>>>> that is there, nor should you make much of an attempt to try to keep >>>>> the alignment. >>>>> >>>>> >>>>> >>>> On Mon, Jul 21, 2008 at 5:39 AM, David Crayford <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>>>> I've been familiarising myself with the code and have noticed that >>>>>> ooRexx does not use: >>>>>> >>>>>> * The standard C++ library, iostreams, STL etc. >>>>>> * Exceptions >>>>>> * Generic programming (templates) >>>>>> * namespaces >>>>>> >>>>>> I assume that this is due to history (ooRexx older than ISO C++), >>>>>> performance and portability reasons. Are there any coding standards >>>>>> or rules that I should know about? >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>>> challenge >>>>>> Build the coolest Linux based applications with Moblin SDK & win great >>>>>> prizes >>>>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>>>> world >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>> _______________________________________________ >>>>>> Oorexx-devel mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>> challenge >>>>> Build the coolest Linux based applications with Moblin SDK & win great >>>>> prizes >>>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>>> world >>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>> _______________________________________________ >>>>> Oorexx-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>> challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great >>>> prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Oorexx-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
