From: Jean-Louis F. <jfa...@cs...> - 2009-01-04 02:07:39
|
Under Windows, the current version of BSF4Rexx (2008-09-12) does not work with ooRexx 4.0. BSF4Rexx.dll is not loaded because it depends on these functions which are no longer exported by rexx.dll : RexxWaitForTermination RexxDidRexxTerminate I recompiled BSF4Rexx without these dependencies (is it safe to do that ?) An other problem occurred : call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BsfLoadFuncs" fails, because ooRexx 4.0 searches for "BsfLoadFuncs" and does not find it (it's "BSFLOADFUNCS" which is exported). Easy to fix, use call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BSFLOADFUNCS" (4.0 is more strict than 3.2, other external packages may need this kind of adjustment) Now, infoBSF.rex and infoBSF-oo.rex works. During my trials and errors, I had several times the script infoBSF.rex frozen during initialization. Maybe the problem comes from rxapi.exe. RegistrationData::findSessionReference in RegistrationManager.cpp, I think this line is missing : cookie = cookie->next Here are the changes I made to BSF.cc (all are fixes for compilation errors due to changes in rexx.h) : ------------------------------------------- 315a316,320 > #define TID thread_id_t > #define APIRET RexxReturnCode > #define PFN REXXPFN > APIRET APIENTRY RexxDidRexxTerminate(void) {return 1;} > 2666c2671 < const char *str=JNU_GetStringNativeChars(a_JRST, ReturnValue); // rgf, 2006-01-22 --- > char *str=JNU_GetStringNativeChars(a_JRST, ReturnValue); // rgf, 2006-01-22 2903c2908 < RexxWaitForTermination(); // wait for Object Rexx to re-synch ... (2003-02-25, ---rgf: doesn't really have any effect --- > // RexxWaitForTermination(); // wait for Object Rexx to re-synch ... (2003-02-25, ---rgf: doesn't really have any effect 3198c3203 < const char *tmpString=JNU_GetStringNativeChars(a_JRST, javaStr); // rgf, 2006-01-28 --- > char *tmpString=JNU_GetStringNativeChars(a_JRST, javaStr); // rgf, 2006-01-28 3244c3249 < (PUCHAR) rsbarr // user data for this exit instance --- > (const char *) rsbarr // user data for this exit instance 3280c3285 < (PRXSTRING) argList, // PRXSTRING ArgList --- > (PCONSTRXSTRING) argList, // PRXSTRING ArgList 3318c3323 < RexxWaitForTermination(); // wait for ooRexx to terminate (may have threads concurrently running) --- > // RexxWaitForTermination(); // wait for ooRexx to terminate (may have threads concurrently running) 3670c3675 < (PUCHAR) user_info); --- > (char *) user_info); ------------------------------------------- |
From: Mark M. <mie...@gm...> - 2009-01-04 03:02:54
|
On Sat, Jan 3, 2009 at 6:05 PM, Jean-Louis Faucher <jfa...@cs...> wrote: Jean-Louis, > Under Windows, the current version of BSF4Rexx (2008-09-12) does not work > with ooRexx 4.0. > BSF4Rexx.dll is not loaded because it depends on these functions which are > no longer exported by rexx.dll : > RexxWaitForTermination > RexxDidRexxTerminate You should probably take up the BSF4Rexx issues directly with Rony. I know he will be working on a version that is compatible with ooRexx 4.0.0. He may be waiting until 4.0.0 goes into beta. He's got a SourceForge id, you can surely contact him using that: https://sourceforge.net/users/orexx/ Or, he has opened a SourceForge project: https://sourceforge.net/projects/bsf4rexx/ > During my trials and errors, I had several times the script infoBSF.rex > frozen during initialization. > Maybe the problem comes from rxapi.exe. > RegistrationData::findSessionReference in RegistrationManager.cpp, I think > this line is missing : > cookie = cookie->next We've shook out some bugs in rxapi, there could we;; be others. I'll take a look a that. -- Mark Miesfeld |
From: Mark M. <mie...@gm...> - 2009-01-04 03:33:26
|
On Sat, Jan 3, 2009 at 7:02 PM, Mark Miesfeld <mie...@gm...> wrote: > On Sat, Jan 3, 2009 at 6:05 PM, Jean-Louis Faucher <jfa...@cs...> wrote: >> During my trials and errors, I had several times the script infoBSF.rex >> frozen during initialization. >> Maybe the problem comes from rxapi.exe. >> RegistrationData::findSessionReference in RegistrationManager.cpp, I think >> this line is missing : >> cookie = cookie->next > > We've shook out some bugs in rxapi, there could we;; be others. I'll > take a look a that. Jean-Louis, Looks like there were two spots in RegistrationManager where things weren't advancing to next. Thanks, again, for finding this. -- Mark Miesfeld |
From: Rony G. F. <Ron...@wu...> - 2009-01-04 11:13:25
|
Bonjour Jean-Louis, great that you are tackling BSF4Rexx on ooRexx 4.0 already! > Under Windows, the current version of BSF4Rexx (2008-09-12) does not > work with ooRexx 4.0. > BSF4Rexx.dll is not loaded because it depends on these functions which > are no longer exported by rexx.dll : > RexxWaitForTermination > RexxDidRexxTerminate > > I recompiled BSF4Rexx without these dependencies (is it safe to do > that ?) Under pre 4.0 ooRexx it is mandatory to have these available. The reason: if ooRexx programs run multithreaded then the threads need to be able to continue, even if the main thread has finished already. Not sure how 4.0 behaves. So I would at least do a conditional include, i.e. do not include them if compiled for ooRexx 4.0, until Rick can clarify the behaviour on 4.0. > An other problem occurred : > call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BsfLoadFuncs" > fails, because ooRexx 4.0 searches for "BsfLoadFuncs" and does not > find it (it's "BSFLOADFUNCS" which is exported). > Easy to fix, use > call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BSFLOADFUNCS" > (4.0 is more strict than 3.2, other external packages may need this > kind of adjustment) Interesting. > Now, infoBSF.rex and infoBSF-oo.rex works. Super! > During my trials and errors, I had several times the script > infoBSF.rex frozen during initialization. > Maybe the problem comes from rxapi.exe. > RegistrationData::findSessionReference in RegistrationManager.cpp, I > think this line is missing : > cookie = cookie->next > > > Here are the changes I made to BSF.cc (all are fixes for compilation > errors due to changes in rexx.h) : If you can supply a unified diff, I would apply it to the original source (license is <http://www.apache.org/licenses/LICENSE-2.0>). Regards, ---rony |
From: Rick M. <obj...@gm...> - 2009-01-04 12:54:39
|
Neither of those APIs should be necessary in 4.0. RexxStart will now behave the way it should always have behaved and wait for all threads started by the executed program to terminate. I hadn't realized those APIs had actually been documented. I think I'll need to add back in some stubbed replacements that just return immediately and document them as deprecated. Rick On Sun, Jan 4, 2009 at 6:13 AM, Rony G. Flatscher <Ron...@wu...> wrote: > Bonjour Jean-Louis, > > great that you are tackling BSF4Rexx on ooRexx 4.0 already! > > Under Windows, the current version of BSF4Rexx (2008-09-12) does not work > with ooRexx 4.0. > BSF4Rexx.dll is not loaded because it depends on these functions which are > no longer exported by rexx.dll : > RexxWaitForTermination > RexxDidRexxTerminate > > I recompiled BSF4Rexx without these dependencies (is it safe to do that ?) > > Under pre 4.0 ooRexx it is mandatory to have these available. The reason: if > ooRexx programs run multithreaded then the threads need to be able to > continue, even if the main thread has finished already. > > Not sure how 4.0 behaves. So I would at least do a conditional include, i.e. > do not include them if compiled for ooRexx 4.0, until Rick can clarify the > behaviour on 4.0. > > An other problem occurred : > call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BsfLoadFuncs" > fails, because ooRexx 4.0 searches for "BsfLoadFuncs" and does not find it > (it's "BSFLOADFUNCS" which is exported). > Easy to fix, use > call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BSFLOADFUNCS" > (4.0 is more strict than 3.2, other external packages may need this kind of > adjustment) > > Interesting. > > Now, infoBSF.rex and infoBSF-oo.rex works. > > Super! > > During my trials and errors, I had several times the script infoBSF.rex > frozen during initialization. > Maybe the problem comes from rxapi.exe. > RegistrationData::findSessionReference in RegistrationManager.cpp, I think > this line is missing : > cookie = cookie->next > > > Here are the changes I made to BSF.cc (all are fixes for compilation errors > due to changes in rexx.h) : > > If you can supply a unified diff, I would apply it to the original source > (license is <http://www.apache.org/licenses/LICENSE-2.0>). > > Regards, > > ---rony > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Rony G. F. <Ron...@wu...> - 2009-01-04 19:22:32
|
Rick McGuire wrote: > Neither of those APIs should be necessary in 4.0. RexxStart will now > behave the way it should always have behaved and wait for all threads > started by the executed program to terminate. I hadn't realized those > APIs had actually been documented. I think I'll need to add back in > some stubbed replacements that just return immediately and document > them as deprecated. > Thank you, just saw that you already took care of it in today's rev 3861 which is great. ---rony > On Sun, Jan 4, 2009 at 6:13 AM, Rony G. Flatscher > <Ron...@wu...> wrote: > >> Bonjour Jean-Louis, >> >> great that you are tackling BSF4Rexx on ooRexx 4.0 already! >> >> Under Windows, the current version of BSF4Rexx (2008-09-12) does not work >> with ooRexx 4.0. >> BSF4Rexx.dll is not loaded because it depends on these functions which are >> no longer exported by rexx.dll : >> RexxWaitForTermination >> RexxDidRexxTerminate >> >> I recompiled BSF4Rexx without these dependencies (is it safe to do that ?) >> >> Under pre 4.0 ooRexx it is mandatory to have these available. The reason: if >> ooRexx programs run multithreaded then the threads need to be able to >> continue, even if the main thread has finished already. >> >> Not sure how 4.0 behaves. So I would at least do a conditional include, i.e. >> do not include them if compiled for ooRexx 4.0, until Rick can clarify the >> behaviour on 4.0. >> >> An other problem occurred : >> call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BsfLoadFuncs" >> fails, because ooRexx 4.0 searches for "BsfLoadFuncs" and does not find it >> (it's "BSFLOADFUNCS" which is exported). >> Easy to fix, use >> call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BSFLOADFUNCS" >> (4.0 is more strict than 3.2, other external packages may need this kind of >> adjustment) >> >> Interesting. >> >> Now, infoBSF.rex and infoBSF-oo.rex works. >> >> Super! >> >> During my trials and errors, I had several times the script infoBSF.rex >> frozen during initialization. >> Maybe the problem comes from rxapi.exe. >> RegistrationData::findSessionReference in RegistrationManager.cpp, I think >> this line is missing : >> cookie = cookie->next >> >> >> Here are the changes I made to BSF.cc (all are fixes for compilation errors >> due to changes in rexx.h) : >> >> If you can supply a unified diff, I would apply it to the original source >> (license is <http://www.apache.org/licenses/LICENSE-2.0>). >> >> Regards, >> >> ---rony >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Jean-Louis F. <jfa...@cs...> - 2009-01-04 21:14:14
|
Rony, I uploaded the changes to the "patches tracker" for BSF4Rexx. There is a new target oorexx4 in the makefile (for Window only). It defines the variable USE_OOREXX4 which is used for conditional compilation (I leave you decide if that's the good way) I use Visual C++ 2008 Express Edition, and I had to remove INITINSTANCE from BSF4Rexx.def (syntax error). No longer needed to modify the call RxFuncLoad, thanks to Rick. It's really impressive to see BSF4Rexx working like a breeze with ooRexx 4, without no change at all ! Tested with jre1.6.0_11 Jean-Louis "Rony G. Flatscher" <Ron...@wu...> 04/01/2009 20:02 Please respond to Open Object Rexx Developer Mailing List <oor...@li...> To Open Object Rexx Developer Mailing List <oor...@li...> cc Subject Re: [Oorexx-devel] BSF4Rexx and ooRexx 4.0 : (tiny) adjustments needed - and a bug in rxapi.exe ? Rick McGuire wrote: Neither of those APIs should be necessary in 4.0. RexxStart will now behave the way it should always have behaved and wait for all threads started by the executed program to terminate. I hadn't realized those APIs had actually been documented. I think I'll need to add back in some stubbed replacements that just return immediately and document them as deprecated. Thank you, just saw that you already took care of it in today's rev 3861 which is great. ---rony On Sun, Jan 4, 2009 at 6:13 AM, Rony G. Flatscher <Ron...@wu...> wrote: Bonjour Jean-Louis, great that you are tackling BSF4Rexx on ooRexx 4.0 already! Under Windows, the current version of BSF4Rexx (2008-09-12) does not work with ooRexx 4.0. BSF4Rexx.dll is not loaded because it depends on these functions which are no longer exported by rexx.dll : RexxWaitForTermination RexxDidRexxTerminate I recompiled BSF4Rexx without these dependencies (is it safe to do that ?) Under pre 4.0 ooRexx it is mandatory to have these available. The reason: if ooRexx programs run multithreaded then the threads need to be able to continue, even if the main thread has finished already. Not sure how 4.0 behaves. So I would at least do a conditional include, i.e. do not include them if compiled for ooRexx 4.0, until Rick can clarify the behaviour on 4.0. An other problem occurred : call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BsfLoadFuncs" fails, because ooRexx 4.0 searches for "BsfLoadFuncs" and does not find it (it's "BSFLOADFUNCS" which is exported). Easy to fix, use call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BSFLOADFUNCS" (4.0 is more strict than 3.2, other external packages may need this kind of adjustment) Interesting. Now, infoBSF.rex and infoBSF-oo.rex works. Super! During my trials and errors, I had several times the script infoBSF.rex frozen during initialization. Maybe the problem comes from rxapi.exe. RegistrationData::findSessionReference in RegistrationManager.cpp, I think this line is missing : cookie = cookie->next Here are the changes I made to BSF.cc (all are fixes for compilation errors due to changes in rexx.h) : If you can supply a unified diff, I would apply it to the original source (license is <http://www.apache.org/licenses/LICENSE-2.0>). Regards, ---rony ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oor...@li... https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oor...@li... https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oor...@li... https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: Rony G. F. <Ron...@wu...> - 2009-01-04 22:22:07
|
Bonjour Jean-Louis, > I uploaded the changes to the "patches tracker" for BSF4Rexx. Great, thank you very much! > There is a new target oorexx4 in the makefile (for Window only). > It defines the variable USE_OOREXX4 which is used for conditional > compilation (I leave you decide if that's the good way) > I use Visual C++ 2008 Express Edition, and I had to remove > INITINSTANCE from BSF4Rexx.def (syntax error). Yes, that stems from the OS/2 days. > No longer needed to modify the call RxFuncLoad, thanks to Rick. > It's really impressive to see BSF4Rexx working like a breeze with > ooRexx 4, without no change at all ! > Tested with jre1.6.0_11 Great, again thank you very much for your work and information/feedback! --- Did you by any chance try a BSF4Rexx.dll which was compiled against ooRexx 3.2, i.e. the one from the distribution that can be found at <http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/>? (Just curious, whether it would work with the latest drop of ooRexx 4.0 too.) Regards, ---rony |
From: Jean-Louis F. <jfa...@cs...> - 2009-01-04 23:17:44
|
Roni, I confirm that the current distribution built with ooRexx 3.2 works well with ooRexx 4, after the changes made by Rick today. All the scripts in samples run without problem, from rexx or from java. Only Snippet108.rex is not running, I suppose I don't have SWT. Even not a little bug to shake out :-) or maybe a potential one, not in relation with BSF : in RegistrationManager.cpp, RegistrationData::removeSessionReference : when the cookie is found in the loop, then it's deleted twice. Jean-Louis "Rony G. Flatscher" <Ron...@wu...> 04/01/2009 23:21 Please respond to Open Object Rexx Developer Mailing List <oor...@li...> To Open Object Rexx Developer Mailing List <oor...@li...> cc Subject Re: [Oorexx-devel] BSF4Rexx and ooRexx 4.0 : (tiny) adjustments needed - and a bug in rxapi.exe ? Bonjour Jean-Louis, I uploaded the changes to the "patches tracker" for BSF4Rexx. Great, thank you very much! There is a new target oorexx4 in the makefile (for Window only). It defines the variable USE_OOREXX4 which is used for conditional compilation (I leave you decide if that's the good way) I use Visual C++ 2008 Express Edition, and I had to remove INITINSTANCE from BSF4Rexx.def (syntax error). Yes, that stems from the OS/2 days. No longer needed to modify the call RxFuncLoad, thanks to Rick. It's really impressive to see BSF4Rexx working like a breeze with ooRexx 4, without no change at all ! Tested with jre1.6.0_11 Great, again thank you very much for your work and information/feedback! --- Did you by any chance try a BSF4Rexx.dll which was compiled against ooRexx 3.2, i.e. the one from the distribution that can be found at <http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/>? (Just curious, whether it would work with the latest drop of ooRexx 4.0 too.) Regards, ---rony ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oor...@li... https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: Rick M. <obj...@gm...> - 2009-01-04 23:24:43
|
On Sun, Jan 4, 2009 at 6:15 PM, Jean-Louis Faucher <jfa...@cs...> wrote: > > Roni, > > I confirm that the current distribution built with ooRexx 3.2 works well > with ooRexx 4, after the changes made by Rick today. > All the scripts in samples run without problem, from rexx or from java. > Only Snippet108.rex is not running, I suppose I don't have SWT. > > Even not a little bug to shake out :-) > or maybe a potential one, not in relation with BSF : > in RegistrationManager.cpp, RegistrationData::removeSessionReference : when > the cookie is found in the loop, then it's deleted twice. Not any more :-) Thanks for reporting this! Rick > > Jean-Louis > > > > "Rony G. Flatscher" <Ron...@wu...> > > 04/01/2009 23:21 > > Please respond to > Open Object Rexx Developer Mailing List > <oor...@li...> > To > Open Object Rexx Developer Mailing List <oor...@li...> > cc > Subject > Re: [Oorexx-devel] BSF4Rexx and ooRexx 4.0 : (tiny) adjustments > needed - and a bug in rxapi.exe ? > > > > > Bonjour Jean-Louis, > I uploaded the changes to the "patches tracker" for BSF4Rexx. > Great, thank you very much! > > There is a new target oorexx4 in the makefile (for Window only). > It defines the variable USE_OOREXX4 which is used for conditional > compilation (I leave you decide if that's the good way) > I use Visual C++ 2008 Express Edition, and I had to remove INITINSTANCE from > BSF4Rexx.def (syntax error). > Yes, that stems from the OS/2 days. > > No longer needed to modify the call RxFuncLoad, thanks to Rick. > It's really impressive to see BSF4Rexx working like a breeze with ooRexx 4, > without no change at all ! > Tested with jre1.6.0_11 > Great, again thank you very much for your work and information/feedback! > > --- > > Did you by any chance try a BSF4Rexx.dll which was compiled against ooRexx > 3.2, i.e. the one from the distribution that can be found at > <http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/>? (Just curious, whether > it would work with the latest drop of ooRexx 4.0 too.) > > Regards, > > ---rony > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Rony G. F. <Ron...@wu...> - 2009-01-04 23:33:23
|
Bonjour Jean-Louis, > I confirm that the current distribution built with ooRexx 3.2 works > well with ooRexx 4, after the changes made by Rick today. > All the scripts in samples run without problem, from rexx or from java. That's really great news! > Only Snippet108.rex is not running, I suppose I don't have SWT. Yes, you would need to get it from <http://www.eclipse.org/swt/>. After that, all of Eclipse's swt-gadgets are available to you (and transcribing the Java snippets to ooRexx using BSF4Rexx is quite straight-forward) ... > Even not a little bug to shake out :-) :-) Nevertheless, your work on making BSF4Rexx compile with ooRexx 4.0 is highly appreciated as it will get incorporated (after the ski-seminar which starts this week, our winter term goes on until the end of January over here), before starting one long-outstanding/planned enhancement to BSF4Rexx which is only possible with ooRexx 4.0, which will allow for call backs. [For that I will have to study the addressing of specific running ooRexx interpreter instances as well as ooRexx threads and addressing ooRexx objects therein.] Regards, ---rony |
From: Rick M. <obj...@gm...> - 2009-01-04 23:36:15
|
On Sun, Jan 4, 2009 at 6:33 PM, Rony G. Flatscher <Ron...@wu...> wrote: > Bonjour Jean-Louis, > > I confirm that the current distribution built with ooRexx 3.2 works well > with ooRexx 4, after the changes made by Rick today. > All the scripts in samples run without problem, from rexx or from java. > > That's really great news! > > Only Snippet108.rex is not running, I suppose I don't have SWT. > > Yes, you would need to get it from <http://www.eclipse.org/swt/>. After > that, all of Eclipse's swt-gadgets are available to you (and transcribing > the Java snippets to ooRexx using BSF4Rexx is quite straight-forward) ... > > Even not a little bug to shake out :-) > > :-) > > Nevertheless, your work on making BSF4Rexx compile with ooRexx 4.0 is highly > appreciated as it will get incorporated (after the ski-seminar which starts > this week, our winter term goes on until the end of January over here), > before starting one long-outstanding/planned enhancement to BSF4Rexx which > is only possible with ooRexx 4.0, which will allow for call backs. [For that > I will have to study the addressing of specific running ooRexx interpreter > instances as well as ooRexx threads and addressing ooRexx objects therein.] And all questions about this can be asked here. Rick > > Regards, > > ---rony > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Rony G. F. <Ron...@wu...> - 2009-01-04 23:41:27
|
Rick McGuire wrote: > On Sun, Jan 4, 2009 at 6:33 PM, Rony G. Flatscher > <Ron...@wu...> wrote: > >> Bonjour Jean-Louis, >> >> I confirm that the current distribution built with ooRexx 3.2 works well >> with ooRexx 4, after the changes made by Rick today. >> All the scripts in samples run without problem, from rexx or from java. >> >> That's really great news! >> >> Only Snippet108.rex is not running, I suppose I don't have SWT. >> >> Yes, you would need to get it from <http://www.eclipse.org/swt/>. After >> that, all of Eclipse's swt-gadgets are available to you (and transcribing >> the Java snippets to ooRexx using BSF4Rexx is quite straight-forward) ... >> >> Even not a little bug to shake out :-) >> >> :-) >> >> Nevertheless, your work on making BSF4Rexx compile with ooRexx 4.0 is highly >> appreciated as it will get incorporated (after the ski-seminar which starts >> this week, our winter term goes on until the end of January over here), >> before starting one long-outstanding/planned enhancement to BSF4Rexx which >> is only possible with ooRexx 4.0, which will allow for call backs. [For that >> I will have to study the addressing of specific running ooRexx interpreter >> instances as well as ooRexx threads and addressing ooRexx objects therein.] >> > > And all questions about this can be asked here. > Thanks (will take until February though, before I would get a few days in a row to become able to dig into it as there will be a few ends on different soils to tackle in order to do it). ---rony |
From: Rony G. F. <Ron...@wu...> - 2009-03-09 17:39:00
Attachments:
nutshell2.txt
|
Purpose: demonstrate how to start interpreter instance(s), load and run Rexx programs, and change .local entries from the different interpreter instances, and also create an instance of a (non public) class to run concurrently to the Rexx program's ones In order to be easily understood it would be probably very helpful, if the following (as short as possible) documented nutshell programs would be created: a) Nutshell program 1a) - demonstrate how to create an interpreter instance: -> create an interpreter instance - demonstrate how to load and run a multithreaded Rexx program: -> load and run a multithreaded Rexx program (enclosed, see bottom) b) Nutshell program 1b): use the code from 1a) add the following features to it - demonstrate changing the value of an entry in .local (which is interpreter instance dependent) : -> change the entry named "INTERPRETER.INFO" stored in .local to "[# 1]" to reflect that that program is running for the interpreter instance # 1 - demonstrate how to retrieve a (non-public) class object, create an instance of it and send it a message; demonstrate how to retrieve an object from .local to supply it as one of the arguments to the message: -> create an instance of the class "Worker", retrieve the object referenced by ".BUFFER" (stored in .local), invoke the "write" method on the worker object supplying arguments, this should be the C++ equivalent of ooRexx': .worker~new~write(.buffer, "from_C++_1", 7) c) Nutshell program 1c): use the code from 1b) add the following features to it - demonstrate how one can create two instances of the interpreter in the same process, run the same Rexx program (see below), changing infos in .local accordingly - demonstrate changing the value of an entry in .local (which is interpreter instance dependent) : -> change the entry named "INTERPRETER.INFO" stored in .local to "[# 1]" ("[# 2") to reflect that that program is running for the interpreter instance # 1 (# 2) - demonstrate how to retrieve a (non-public) class object, create an instance of it and send it a message; demonstrate how to retrieve an object from .local to supply it as one of the arguments to the message, do this for each interpreter instance: -> create an instance of the class "Worker", retrieve the object referenced by ".BUFFER" (stored in .local), invoke the "write" method on the worker object supplying arguments, this should be the C++ equivalent of ooRexx': .worker~new~write(.buffer, "from_C++_?", 7) -> "?" in the above should be replaced by "1" or "2", depending on the interpreter instance that is addressed. --- Multithreaded Rexx program, which should be used by the aforementioned C++ nutshell examples to execute and to interact with: ------------------ cut here ------------------ -- info of interpreter instance running, maybe changed by C++ nutshell .local~interpreter.info="[# 0]" a=.worker~new -- used to read & write messages to buffer b=.worker~new -- used to write messages to buffer .local~buffer=.fifo~new -- buffer that gets shared a~write(.buffer, "from_a", 5) -- write 5 messages b~write(.buffer, "FROM_B", 6) -- write 6 messages -- how much got written asynchroneously so far? say .interpreter.info "... 'a' has written" a~i "messages so far" say .interpreter.info "... 'b' has written" b~i "messages so far" -- let the main program sleep a little bit sleepTime=.001 say .interpreter.info "sleeping" sleepTime "seconds" call sysSleep sleepTime -- how much got written asynchroneously so far? say .interpreter.info "... 'a' has written" a~i "messages so far" say .interpreter.info "... 'b' has written" b~i "messages so far" -- now read asynchroneously from the buffer say .interpreter.info "... now starting to read from buffer" a~read(.buffer) -- read all messages from buffer say .interpreter.info "--> main program finished @" .DateTime~new~string /* Read and write messages from/to given buffer asynchroneously */ ::class Worker ::method init class expose activeWriter activeWriter=0 -- number of active writers ::attribute activeWriter class ::method init expose i i=0 -- initialize variable ::attribute i get unguarded ::method write expose i use arg buffer, msg, repetitions self~class~activeWriter+=1 -- increase counter REPLY -- start asynchroneous execution do i=1 to repetitions buffer~write(i msg "@" .DateTime~new~string) call sysSleep random(1, 9)/1000 end buffer~write("--> writing message ["msg"] finished @" .DateTime~new~string) self~class~activeWriter-=1 -- decrease counter ::method read use arg buffer REPLY -- start asynchroneous execution call sysSleep .1 -- wait a bit before starting to read do while buffer~items>0 | self~class~activeWriter>0 for 50 msg=buffer~read say .interpreter.info "just read from buffer: ["|| buffer~identityHash"] message: ["msg"]" end say .interpreter.info "--> read(): finished @" .DateTime~new~string /* FIFO buffer, backed by a Rexx .Queue */ ::class FIFO ::method init expose buffer buffer=.queue~new ::method write expose buffer use arg tmp buffer~queue(tmp) ::method read expose buffer return buffer~pull ::method items expose buffer return buffer~items ------------------ cut here ------------------ |
From: Rick M. <obj...@gm...> - 2009-03-09 17:48:49
|
Well, it your expectation is a complete running program, then this will have to wait a while until I finish up some other things (many of which happen to be different sample programs). If all you want is answers to some of these questions, then I probably give you a reply with the code snippets involved later this evening. Rick On Mon, Mar 9, 2009 at 12:38 PM, Rony G. Flatscher <Ron...@wu...> wrote: > Hi there, > > returning to an offer at the beginning of January w.r.t asking questions > about the new 4.0 APIs (attached). > > Having gone through the new C++ APIs maybe the best way to express questions > would be to ask for commented nutshell (= very short programs) API examples. > Possible solutions would mostlikely help clarify a *lot* of questions right > away. Therefore I enclosed two requests for nutshell API examples, which I > think would help understand quite a few of the APIs and how they play > together. > > In the context of the requested nutshell examples I tried to supply at least > the ooRexx part of the question, by creating two small multithreaded > nutshell ooRexx programs with which or from which the interfacing should > occur. > > Regards, > > ---rony > > > Rick McGuire wrote: > > On Sun, Jan 4, 2009 at 6:33 PM, Rony G. Flatscher > <Ron...@wu...> wrote: > > > Bonjour Jean-Louis, > > I confirm that the current distribution built with ooRexx 3.2 works well > with ooRexx 4, after the changes made by Rick today. > All the scripts in samples run without problem, from rexx or from java. > > That's really great news! > > Only Snippet108.rex is not running, I suppose I don't have SWT. > > Yes, you would need to get it from <http://www.eclipse.org/swt/>. After > that, all of Eclipse's swt-gadgets are available to you (and transcribing > the Java snippets to ooRexx using BSF4Rexx is quite straight-forward) ... > > Even not a little bug to shake out :-) > > :-) > > Nevertheless, your work on making BSF4Rexx compile with ooRexx 4.0 is highly > appreciated as it will get incorporated (after the ski-seminar which starts > this week, our winter term goes on until the end of January over here), > before starting one long-outstanding/planned enhancement to BSF4Rexx which > is only possible with ooRexx 4.0, which will allow for call backs. [For that > I will have to study the addressing of specific running ooRexx interpreter > instances as well as ooRexx threads and addressing ooRexx objects therein.] > > > And all questions about this can be asked here. > > Rick > > > > Regards, > > ---rony > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > > > > Purpose: demonstrate how to start interpreter instance(s), load and run Rexx > programs, > and change .local entries from the different interpreter instances, > and also > create an instance of a (non public) class to run concurrently to > the Rexx > program's ones > > In order to be easily understood it would be probably very helpful, if the > following > (as short as possible) documented nutshell programs would be created: > > > a) Nutshell program 1a) > > - demonstrate how to create an interpreter instance: > > -> create an interpreter instance > > - demonstrate how to load and run a multithreaded Rexx program: > > -> load and run a multithreaded Rexx program (enclosed, see bottom) > > > b) Nutshell program 1b): use the code from 1a) add the following features to > it > > - demonstrate changing the value of an entry in .local (which is > interpreter > instance dependent) : > > -> change the entry named "INTERPRETER.INFO" stored in .local to > "[# 1]" to > reflect that that program is running for the interpreter > instance # 1 > > - demonstrate how to retrieve a (non-public) class object, create an > instance > of it and send it a message; demonstrate how to retrieve an object > from .local > to supply it as one of the arguments to the message: > > -> create an instance of the class "Worker", retrieve the object > referenced > by ".BUFFER" (stored in .local), invoke the "write" method on > the worker > object supplying arguments, this should be the C++ equivalent of > ooRexx': > > .worker~new~write(.buffer, "from_C++_1", 7) > > > c) Nutshell program 1c): use the code from 1b) add the following features to > it > > - demonstrate how one can create two instances of the interpreter in > the > same process, run the same Rexx program (see below), changing infos > in > .local accordingly > > > - demonstrate changing the value of an entry in .local (which is > interpreter > instance dependent) : > > -> change the entry named "INTERPRETER.INFO" stored in .local to > "[# 1]" > ("[# 2") to reflect that that program is running for the > interpreter > instance # 1 (# 2) > > - demonstrate how to retrieve a (non-public) class object, create an > instance > of it and send it a message; demonstrate how to retrieve an object > from .local > to supply it as one of the arguments to the message, do this for > each > interpreter instance: > > -> create an instance of the class "Worker", retrieve the object > referenced > by ".BUFFER" (stored in .local), invoke the "write" method on > the worker > object supplying arguments, this should be the C++ equivalent of > ooRexx': > > .worker~new~write(.buffer, "from_C++_?", 7) > > -> "?" in the above should be replaced by "1" or "2", depending on > the > interpreter instance that is addressed. > > > --- > > Multithreaded Rexx program, which should be used by the aforementioned C++ > nutshell > examples to execute and to interact with: > > ------------------ cut here ------------------ > -- info of interpreter instance running, maybe changed by C++ nutshell > .local~interpreter.info="[# 0]" > > a=.worker~new -- used to read & write messages to buffer > b=.worker~new -- used to write messages to buffer > > .local~buffer=.fifo~new -- buffer that gets shared > > a~write(.buffer, "from_a", 5) -- write 5 messages > b~write(.buffer, "FROM_B", 6) -- write 6 messages > > -- how much got written asynchroneously so far? > say .interpreter.info "... 'a' has written" a~i "messages so far" > say .interpreter.info "... 'b' has written" b~i "messages so far" > > -- let the main program sleep a little bit > sleepTime=.001 > say .interpreter.info "sleeping" sleepTime "seconds" > call sysSleep sleepTime > > -- how much got written asynchroneously so far? > say .interpreter.info "... 'a' has written" a~i "messages so far" > say .interpreter.info "... 'b' has written" b~i "messages so far" > > -- now read asynchroneously from the buffer > say .interpreter.info "... now starting to read from buffer" > a~read(.buffer) -- read all messages from buffer > say .interpreter.info "--> main program finished @" .DateTime~new~string > > > /* Read and write messages from/to given buffer asynchroneously */ > ::class Worker > ::method init class > expose activeWriter > activeWriter=0 -- number of active writers > > ::attribute activeWriter class > > ::method init > expose i > i=0 -- initialize variable > > ::attribute i get unguarded > > ::method write > expose i > use arg buffer, msg, repetitions > self~class~activeWriter+=1 -- increase counter > REPLY -- start asynchroneous execution > do i=1 to repetitions > buffer~write(i msg "@" .DateTime~new~string) > call sysSleep random(1, 9)/1000 > end > > buffer~write("--> writing message ["msg"] finished @" .DateTime~new~string) > self~class~activeWriter-=1 -- decrease counter > > ::method read > use arg buffer > REPLY -- start asynchroneous execution > call sysSleep .1 -- wait a bit before starting to read > do while buffer~items>0 | self~class~activeWriter>0 for 50 > msg=buffer~read > say .interpreter.info "just read from buffer: ["|| buffer~identityHash"] > message: ["msg"]" > end > say .interpreter.info "--> read(): finished @" .DateTime~new~string > > > > /* FIFO buffer, backed by a Rexx .Queue */ > ::class FIFO > > ::method init > expose buffer > buffer=.queue~new > > ::method write > expose buffer > use arg tmp > buffer~queue(tmp) > > ::method read > expose buffer > return buffer~pull > > ::method items > expose buffer > return buffer~items > > ------------------ cut here ------------------ > > > > > Purpose: demonstrate how to create an external function that is able to > interact > with the method's variable pool (displaying all variable names) and > with the object's attributes (displaying all object variable names, > changing the value of one object variable); if possible, the > function > should also display the hashid of the object for which the method > got > invoked, as well as the name of the invoked method > > > Nutshell program: > > - demonstrate how to create an interpreter instance: > > -> create an interpreter instance > > - demonstrate how to load and run a multithreaded Rexx program: > > -> load and run a multithreaded Rexx program (enclosed, see bottom) > > - demonstrate how to define an external routine named > "externalRoutine" > > -> define the external routine in the nutshell code > > - demonstrate how to interact with the variable pool, if possible > > -> get the variable pool of the running method and display the > names (maybe "SLEEPTIME" ?) > > - demonstrate how to interact with the object variable pool, if > possible > > -> get the object variable pool of the running method and display > the > names (maybe "NAME", "MYDATA"?) > > - demonstrate how to change an object variable's value, if possible > > -> get the object variable "MYDATA", add the string " from C++ @ " > and > the string value of a newly created instance of .DateTime and > save it > > - demonstrate how to get at the object for which the method runs and > also how to invoke a method on that object, if possible > > -> get a reference to the object and display its "identityHash", by > invoking this method and display its result > > - demonstrate how to get at the method's name, if possible > > -> get the method's name and display it > > > --- > > Multithreaded Rexx program, which should be used by the aforementioned C++ > nutshell > examples to execute and to interact with (of course the ::requires-directive > needs to > be adjusted): > > ------------------ cut here ------------------ > > do i=1 to 5 > o=.worker~new("object #" i) > o~doSomething > end > > -- ::requires --> require external library which contains "externalRoutine" > > ::class worker > ::method init > expose mydata name > parse arg name > mydata=.DateTime~new~string > > ::method doSomething > expose mydata name > reply > myData=.dateTime~new~string > sleepTime=random(1,10, time("f")~right(12)~left(9))/1000 > say name": myData=["myData"] before, sleeping:" sleepTime "seconds" > call sysSleep sleepTime > call externalRoutine -- <== call into an external routine > say name": myData=["myData"] after calling 'externalRoutine'" > ------------------ cut here ------------------ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Rony G. F. <Ron...@wu...> - 2009-03-09 17:59:57
|
Rick McGuire wrote: > Well, it your expectation is a complete running program, then this > will have to wait a while until I finish up some other things (many of > which happen to be different sample programs). If all you want is > answers to some of these questions, then I probably give you a reply > with the code snippets involved later this evening. > It would not be urgent at the moment (being tied down with University matters, start of semester, classes, meetings), if you can come up with complete running programs eventually, that would be fine enough. But maybe one question, not addressed by the suggested nutshell examples: would it be possible to have different sets of external APIs loaded, depending on the use-case (e.g. for BSF4Rexx the external functions BSFLoadJava() and BSFUnloadJava() should not be available, if invoked via Java). This seems to be implied via the "RexxPackageLoader loader; // the package loader" entry in the RexxPackageEntry structure; however, it would be very helpful to learn what would be necessary to implement a RexxPackageLoader on the own, and what responsibilities one would have to fulfill. But maybe there is an alternative means of indicating which routines should be made available and which ones should not at runtime. Again, there is no urgent need for this, just curiosity (and a need once starting to adapt BSF4Rexx to the new APIs, before extending it). ---rony |
From: Rick M. <obj...@gm...> - 2009-03-09 18:07:58
|
A package is self-contained and completely defined by the table within the package. There's no way to dynamically change those tables, so the best solution for that level of control is to use a different dll stub for ones you don't wish to have loaded for an environment. The "loader" entry you refer to is just an initialization routine that Rexx will call when your package is loaded. It doesn't control the registration of any of the package entries. Rick On Mon, Mar 9, 2009 at 12:59 PM, Rony G. Flatscher <Ron...@wu...> wrote: > > Rick McGuire wrote: >> Well, it your expectation is a complete running program, then this >> will have to wait a while until I finish up some other things (many of >> which happen to be different sample programs). If all you want is >> answers to some of these questions, then I probably give you a reply >> with the code snippets involved later this evening. >> > It would not be urgent at the moment (being tied down with University > matters, start of semester, classes, meetings), if you can come up with > complete running programs eventually, that would be fine enough. > > But maybe one question, not addressed by the suggested nutshell > examples: would it be possible to have different sets of external APIs > loaded, depending on the use-case (e.g. for BSF4Rexx the external > functions BSFLoadJava() and BSFUnloadJava() should not be available, if > invoked via Java). This seems to be implied via the "RexxPackageLoader > loader; // the package loader" entry in the RexxPackageEntry structure; > however, it would be very helpful to learn what would be necessary to > implement a RexxPackageLoader on the own, and what responsibilities one > would have to fulfill. But maybe there is an alternative means of > indicating which routines should be made available and which ones should > not at runtime. Again, there is no urgent need for this, just curiosity > (and a need once starting to adapt BSF4Rexx to the new APIs, before > extending it). > > ---rony > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Rony G. F. <Ron...@wu...> - 2009-03-09 18:10:34
|
Rick McGuire wrote: > A package is self-contained and completely defined by the table within > the package. There's no way to dynamically change those tables, so > the best solution for that level of control is to use a different dll > stub for ones you don't wish to have loaded for an environment. > > The "loader" entry you refer to is just an initialization routine that > Rexx will call when your package is loaded. It doesn't control the > registration of any of the package entries. > Thanks! ---rony |
From: Dan C. <gwc...@ez...> - 2009-03-09 18:02:28
|
Thanks, Rony. This will help me. _____ From: Rony G. Flatscher [mailto:Ron...@wu...] Sent: Monday, March 09, 2009 11:39 To: Open Object Rexx Developer Mailing List Subject: [Oorexx-devel] Request for nutshell API examples ... (Re: BSF4Rexx and ooRexx 4.0 : (tiny) adjustments needed - and a bug in rxapi.exe ? Hi there, returning to an offer at the beginning of January w.r.t asking questions about the new 4.0 APIs (attached). Having gone through the new C++ APIs maybe the best way to express questions would be to ask for commented nutshell (= very short programs) API examples. Possible solutions would mostlikely help clarify a *lot* of questions right away. Therefore I enclosed two requests for nutshell API examples, which I think would help understand quite a few of the APIs and how they play together. In the context of the requested nutshell examples I tried to supply at least the ooRexx part of the question, by creating two small multithreaded nutshell ooRexx programs with which or from which the interfacing should occur. Regards, ---rony Rick McGuire wrote: On Sun, Jan 4, 2009 at 6:33 PM, Rony G. Flatscher <mailto:Ron...@wu...> <Ron...@wu...> wrote: Bonjour Jean-Louis, I confirm that the current distribution built with ooRexx 3.2 works well with ooRexx 4, after the changes made by Rick today. All the scripts in samples run without problem, from rexx or from java. That's really great news! Only Snippet108.rex is not running, I suppose I don't have SWT. Yes, you would need to get it from <http://www.eclipse.org/swt/> <http://www.eclipse.org/swt/>. After that, all of Eclipse's swt-gadgets are available to you (and transcribing the Java snippets to ooRexx using BSF4Rexx is quite straight-forward) ... Even not a little bug to shake out :-) :-) Nevertheless, your work on making BSF4Rexx compile with ooRexx 4.0 is highly appreciated as it will get incorporated (after the ski-seminar which starts this week, our winter term goes on until the end of January over here), before starting one long-outstanding/planned enhancement to BSF4Rexx which is only possible with ooRexx 4.0, which will allow for call backs. [For that I will have to study the addressing of specific running ooRexx interpreter instances as well as ooRexx threads and addressing ooRexx objects therein.] And all questions about this can be asked here. Rick Regards, ---rony ------------------------------------------------------------------------ ------ _______________________________________________ Oorexx-devel mailing list Oor...@li... https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------ ------ _______________________________________________ Oorexx-devel mailing list Oor...@li... https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: Rick M. <obj...@gm...> - 2009-03-09 18:10:13
|
btw, I should also point out, I'm not promising to write a working program for you....and if this does get written, it's likely to be some time. I'd really prefer to answer specific questions, not large task like write a working program that requires a lot of effort on my part beyond just providing the information. Rick On Mon, Mar 9, 2009 at 12:59 PM, Rony G. Flatscher <Ron...@wu...> wrote: > > Rick McGuire wrote: >> Well, it your expectation is a complete running program, then this >> will have to wait a while until I finish up some other things (many of >> which happen to be different sample programs). If all you want is >> answers to some of these questions, then I probably give you a reply >> with the code snippets involved later this evening. >> > It would not be urgent at the moment (being tied down with University > matters, start of semester, classes, meetings), if you can come up with > complete running programs eventually, that would be fine enough. > > But maybe one question, not addressed by the suggested nutshell > examples: would it be possible to have different sets of external APIs > loaded, depending on the use-case (e.g. for BSF4Rexx the external > functions BSFLoadJava() and BSFUnloadJava() should not be available, if > invoked via Java). This seems to be implied via the "RexxPackageLoader > loader; // the package loader" entry in the RexxPackageEntry structure; > however, it would be very helpful to learn what would be necessary to > implement a RexxPackageLoader on the own, and what responsibilities one > would have to fulfill. But maybe there is an alternative means of > indicating which routines should be made available and which ones should > not at runtime. Again, there is no urgent need for this, just curiosity > (and a need once starting to adapt BSF4Rexx to the new APIs, before > extending it). > > ---rony > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Mark M. <mie...@gm...> - 2009-03-09 18:40:01
|
On Mon, Mar 9, 2009 at 10:09 AM, Rick McGuire <obj...@gm...> wrote: > btw, I should also point out, I'm not promising to write a working > program for you....and if this does get written, it's likely to be > some time. I'd really prefer to answer specific questions, not large > task like write a working program that requires a lot of effort on my > part beyond just providing the information. In addition to the above, both Rick and I (and I'm sure David too,) would like to get the 4.0.0 release out the door. I'd also prefer that Rick not work on anything that "requires a lot of effort" on his part - until we have 4.0.0 on the way out of the door and he doesn't have anything to do. <grin> The area Rony is talking about is one I'd like to learn more about. I propose that we do this: I'll work with Rony to try and write the examples he'd like to see. Then when I get stuck I can ask my questions here. Right now, I don't know enough to even know what questions to ask. The complete running examples won't make it into this release, I don't think. But they will be on the way to making it into the next release. Of course if Rony can get what he needs by just asking specific questions, then fine. -- Mark Miesfeld |
From: Rick M. <obj...@gm...> - 2009-03-09 18:46:08
|
Mark, For a good headstart on creating an interpreter instance, you might want to start with the API test suite... Rick On Mon, Mar 9, 2009 at 2:39 PM, Mark Miesfeld <mie...@gm...> wrote: > On Mon, Mar 9, 2009 at 10:09 AM, Rick McGuire <obj...@gm...> wrote: > >> btw, I should also point out, I'm not promising to write a working >> program for you....and if this does get written, it's likely to be >> some time. I'd really prefer to answer specific questions, not large >> task like write a working program that requires a lot of effort on my >> part beyond just providing the information. > > In addition to the above, both Rick and I (and I'm sure David too,) > would like to get the 4.0.0 release out the door. I'd also prefer > that Rick not work on anything that "requires a lot of effort" on his > part - until we have 4.0.0 on the way out of the door and he doesn't > have anything to do. <grin> > > The area Rony is talking about is one I'd like to learn more about. I > propose that we do this: I'll work with Rony to try and write the > examples he'd like to see. Then when I get stuck I can ask my > questions here. Right now, I don't know enough to even know what > questions to ask. > > The complete running examples won't make it into this release, I don't > think. But they will be on the way to making it into the next > release. > > Of course if Rony can get what he needs by just asking specific > questions, then fine. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Mark M. <mie...@gm...> - 2009-03-09 18:52:19
|
On Mon, Mar 9, 2009 at 10:45 AM, Rick McGuire <obj...@gm...> wrote: > For a good headstart on creating an interpreter instance, you might > want to start with the API test suite... Thanks Rick, that was my thought too. So far I have only skimmed through the external backing programs for the API test suite. -- Mark Miesfeld |
From: Rick M. <obj...@gm...> - 2009-03-09 18:56:33
|
In that case, let me narrow the search further. Checkout invokeProgram() in orxinstance.cpp. Rick On Mon, Mar 9, 2009 at 1:51 PM, Mark Miesfeld <mie...@gm...> wrote: > On Mon, Mar 9, 2009 at 10:45 AM, Rick McGuire <obj...@gm...> wrote: > >> For a good headstart on creating an interpreter instance, you might >> want to start with the API test suite... > > Thanks Rick, that was my thought too. So far I have only skimmed > through the external backing programs for the API test suite. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |