From dickjr at gmail.com Thu Nov 2 15:03:23 2006 From: dickjr at gmail.com (Richard Jones) Date: Thu Nov 2 15:04:22 2006 Subject: [pdp-discuss] interactive events and epochs Message-ID: <381eb1660611021403o41d23ecodda5a480cf099925@mail.gmail.com> Hi All, I'd like to use an InteractiveEpoch with an InteractiveScriptEnv. In the leabra demo example nav.proj.gz I see the "nav_env" environment, and that it's pointing to the script nav_env.css with 3 arguments. However, it's not clear how one gets from the environment->GetNextEvent() call in the InteractiveEpoch to the MakeEvent() function down in the css file. Is MakeEvent() the function that all such interactive css files should implement, or is there another level of specification that I'm missing somewhere that would allow me to name my own css functions? Also, how can I specify different arguments (numbers and types)? Many thanks. -- Richard Jones dickjr@gmail.com From Randy.OReilly at colorado.edu Fri Nov 3 13:06:04 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Fri Nov 3 13:06:09 2006 Subject: [pdp-discuss] interactive events and epochs In-Reply-To: <381eb1660611021403o41d23ecodda5a480cf099925@mail.gmail.com> References: <381eb1660611021403o41d23ecodda5a480cf099925@mail.gmail.com> Message-ID: <200611031306.04697.Randy.OReilly@colorado.edu> The GetNextEvent just runs the script code, so it is up to that code to determine what to do to make the next event. If you look at the bottom of the nav_env.css script, it has a call to MakeEvent.. - Randy On Thursday 02 November 2006 15:03, Richard Jones wrote: > Hi All, > > I'd like to use an InteractiveEpoch with an InteractiveScriptEnv. In > the leabra demo example nav.proj.gz I see the "nav_env" environment, > and that it's pointing to the script nav_env.css with 3 arguments. > However, it's not clear how one gets from the > environment->GetNextEvent() call in the InteractiveEpoch to the > MakeEvent() function down in the css file. > > Is MakeEvent() the function that all such interactive css files should > implement, or is there another level of specification that I'm missing > somewhere that would allow me to name my own css functions? Also, how > can I specify different arguments (numbers and types)? > > Many thanks. From dickjr at gmail.com Tue Nov 14 18:58:29 2006 From: dickjr at gmail.com (Richard Jones) Date: Tue Nov 14 18:58:34 2006 Subject: [pdp-discuss] TypeAccess question? Message-ID: <381eb1660611141758h25d03d22x97fa28d36a0162eb@mail.gmail.com> I've been having a recurring problem with my code. Every now and then I am getting core dumps while in executing in: String TypeDef::GetValStr(...) This will usually be when I want to open an edit dialog on a newly created object, such as a layer. It also happens if I try to save my project after newly creating an object. This latter is a disaster since it writes out a corrupt proj.gz file and work is lost. It doesn't happen under all circumstances, but I've got it boiled down to reproducibility. Consider the following class: class TestLayer : public Layer { public: MemberDef* var_md; void UpdateAfterEdit() {}; void Initialize() { var_md = NULL;}; void Destroy() { }; void InitLinks() {}; SIMPLE_COPY(TestLayer); COPY_FUNS(TestLayer, Layer); TA_BASEFUNS(TestLayer); }; If in NetViewer I create just one TestLayer and then try to edit it I have no problem. If I create two and try to edit the first, again no problem. But if I try to edit the second I get the dump. Creating one at a time doesn't seem to be a problem, most of the the time. The problem is related to my inclusion of pointers to taBase classes. For instance, if I remove the "MemberDef* var_md" above the problem goes away. There must be something I'm supposed to do but am missing. Any advice I could get would be greatly welcome. Many thanks. -- Richard Jones dickjr@gmail.com From Randy.OReilly at colorado.edu Tue Nov 14 20:54:23 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Tue Nov 14 20:54:33 2006 Subject: [pdp-discuss] TypeAccess question? In-Reply-To: <381eb1660611141758h25d03d22x97fa28d36a0162eb@mail.gmail.com> References: <381eb1660611141758h25d03d22x97fa28d36a0162eb@mail.gmail.com> Message-ID: <200611142054.24016.Randy.OReilly@colorado.edu> I bet the SIMPLE_COPY doesn't handle the memberdef* case correctly -- try getting rid of that to see if that is the source of the problem. if so, replace with: void Copy_(const TestLayer& cp) { var_md = cp.var_md; } - Randy On Tuesday 14 November 2006 18:58, Richard Jones wrote: > I've been having a recurring problem with my code. Every now and then > I am getting core dumps while in executing in: > > String TypeDef::GetValStr(...) > > This will usually be when I want to open an edit dialog on a newly > created object, such as a layer. It also happens if I try to save my > project after newly creating an object. This latter is a disaster > since it writes out a corrupt proj.gz file and work is lost. It > doesn't happen under all circumstances, but I've got it boiled down to > reproducibility. Consider the following class: > > class TestLayer : public Layer { > > public: > > MemberDef* var_md; > > void UpdateAfterEdit() {}; > void Initialize() { var_md = NULL;}; > void Destroy() { }; > void InitLinks() {}; > SIMPLE_COPY(TestLayer); > COPY_FUNS(TestLayer, Layer); > TA_BASEFUNS(TestLayer); > }; > > If in NetViewer I create just one TestLayer and then try to edit it I > have no problem. If I create two and try to edit the first, again no > problem. But if I try to edit the second I get the dump. Creating > one at a time doesn't seem to be a problem, most of the the time. > > The problem is related to my inclusion of pointers to taBase classes. > For instance, if I remove the "MemberDef* var_md" above the problem > goes away. There must be something I'm supposed to do but am > missing. Any advice I could get would be greatly welcome. > > Many thanks. From dickjr at gmail.com Wed Nov 15 09:02:39 2006 From: dickjr at gmail.com (Richard Jones) Date: Wed Nov 15 09:02:43 2006 Subject: [pdp-discuss] TypeAccess question? In-Reply-To: <200611142054.24016.Randy.OReilly@colorado.edu> References: <381eb1660611141758h25d03d22x97fa28d36a0162eb@mail.gmail.com> <200611142054.24016.Randy.OReilly@colorado.edu> Message-ID: <381eb1660611150802r7c179763i6a56353b3e3c2d6e@mail.gmail.com> Thanks for the reply. Unfortunately, it doesn't help. In the TypeDef::GetValStr(...) I'm still getting an EXC_BAD_ACCESS on the last of the following lines: ... if(DerivesFrom(TA_taBase)) { TAPtr rbase = *((TAPtr*)base); if((rbase != NULL) && ((rbase->GetOwner() != NULL) || (rbase == tabMisc::root))) { One thing I did try, based on the first sentences of section 18.12 in the help: "If a class contains a pointer to another object, it should typically refer to that object whenever the pointer is set. The interface assumes that this is the case, ..." was to put a dumb check for equality to NULL right after setting my pointer to NULL in my Initialize() function. This seems to fix the problem but I don't see why, and I haven't yet exhaustively verified this. Does this seem like it should work? On 11/14/06, Randall C. O'Reilly wrote: > I bet the SIMPLE_COPY doesn't handle the memberdef* case correctly -- try > getting rid of that to see if that is the source of the problem. if so, > replace with: > > void Copy_(const TestLayer& cp) { var_md = cp.var_md; } > > - Randy > > On Tuesday 14 November 2006 18:58, Richard Jones wrote: > > I've been having a recurring problem with my code. Every now and then > > I am getting core dumps while in executing in: > > > > String TypeDef::GetValStr(...) > > > > This will usually be when I want to open an edit dialog on a newly > > created object, such as a layer. It also happens if I try to save my > > project after newly creating an object. This latter is a disaster > > since it writes out a corrupt proj.gz file and work is lost. It > > doesn't happen under all circumstances, but I've got it boiled down to > > reproducibility. Consider the following class: > > > > class TestLayer : public Layer { > > > > public: > > > > MemberDef* var_md; > > > > void UpdateAfterEdit() {}; > > void Initialize() { var_md = NULL;}; > > void Destroy() { }; > > void InitLinks() {}; > > SIMPLE_COPY(TestLayer); > > COPY_FUNS(TestLayer, Layer); > > TA_BASEFUNS(TestLayer); > > }; > > > > If in NetViewer I create just one TestLayer and then try to edit it I > > have no problem. If I create two and try to edit the first, again no > > problem. But if I try to edit the second I get the dump. Creating > > one at a time doesn't seem to be a problem, most of the the time. > > > > The problem is related to my inclusion of pointers to taBase classes. > > For instance, if I remove the "MemberDef* var_md" above the problem > > goes away. There must be something I'm supposed to do but am > > missing. Any advice I could get would be greatly welcome. > > > > Many thanks. > -- Richard Jones dickjr@gmail.com From Randy.OReilly at colorado.edu Wed Nov 15 09:39:29 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Wed Nov 15 09:39:44 2006 Subject: [pdp-discuss] TypeAccess question? In-Reply-To: <381eb1660611150802r7c179763i6a56353b3e3c2d6e@mail.gmail.com> References: <381eb1660611141758h25d03d22x97fa28d36a0162eb@mail.gmail.com> <200611142054.24016.Randy.OReilly@colorado.edu> <381eb1660611150802r7c179763i6a56353b3e3c2d6e@mail.gmail.com> Message-ID: <200611150939.29929.Randy.OReilly@colorado.edu> Ok, now I see the problem: you define an InitLinks() function with nothing in it. InitLinks MUST call the parent class's initlinks (Layer::InitLinks()), and do any of its own functionality. In your case, you don't need it, so remove it. You are preventing the Layer Initlinks (and its parents) from operating... In version 4.0, we have a TA_SIMPLE_BASEFUNS macro that does all this housekeeping stuff automatically :). It should be available as a beta in a few weeks.. - Randy On Wednesday 15 November 2006 09:02, Richard Jones wrote: > Thanks for the reply. Unfortunately, it doesn't help. In the > TypeDef::GetValStr(...) I'm still getting an EXC_BAD_ACCESS on the > last of the following lines: > > ... > if(DerivesFrom(TA_taBase)) { > TAPtr rbase = *((TAPtr*)base); > if((rbase != NULL) && ((rbase->GetOwner() != NULL) || (rbase == > tabMisc::root))) { > > One thing I did try, based on the first sentences of section 18.12 in > the help: "If a class contains a pointer to another object, it should > typically refer to that object whenever the pointer is set. The > interface assumes that this is the case, ..." was to put a dumb check > for equality to NULL right after setting my pointer to NULL in my > Initialize() function. This seems to fix the problem but I don't see > why, and I haven't yet exhaustively verified this. > > Does this seem like it should work? > > On 11/14/06, Randall C. O'Reilly wrote: > > I bet the SIMPLE_COPY doesn't handle the memberdef* case correctly -- try > > getting rid of that to see if that is the source of the problem. if so, > > replace with: > > > > void Copy_(const TestLayer& cp) { var_md = cp.var_md; } > > > > - Randy > > > > On Tuesday 14 November 2006 18:58, Richard Jones wrote: > > > I've been having a recurring problem with my code. Every now and then > > > I am getting core dumps while in executing in: > > > > > > String TypeDef::GetValStr(...) > > > > > > This will usually be when I want to open an edit dialog on a newly > > > created object, such as a layer. It also happens if I try to save my > > > project after newly creating an object. This latter is a disaster > > > since it writes out a corrupt proj.gz file and work is lost. It > > > doesn't happen under all circumstances, but I've got it boiled down to > > > reproducibility. Consider the following class: > > > > > > class TestLayer : public Layer { > > > > > > public: > > > > > > MemberDef* var_md; > > > > > > void UpdateAfterEdit() {}; > > > void Initialize() { var_md = NULL;}; > > > void Destroy() { }; > > > void InitLinks() {}; > > > SIMPLE_COPY(TestLayer); > > > COPY_FUNS(TestLayer, Layer); > > > TA_BASEFUNS(TestLayer); > > > }; > > > > > > If in NetViewer I create just one TestLayer and then try to edit it I > > > have no problem. If I create two and try to edit the first, again no > > > problem. But if I try to edit the second I get the dump. Creating > > > one at a time doesn't seem to be a problem, most of the the time. > > > > > > The problem is related to my inclusion of pointers to taBase classes. > > > For instance, if I remove the "MemberDef* var_md" above the problem > > > goes away. There must be something I'm supposed to do but am > > > missing. Any advice I could get would be greatly welcome. > > > > > > Many thanks. From dickjr at gmail.com Thu Nov 16 09:57:23 2006 From: dickjr at gmail.com (Richard Jones) Date: Thu Nov 16 09:57:27 2006 Subject: [pdp-discuss] TypeAccess question? In-Reply-To: <200611150939.29929.Randy.OReilly@colorado.edu> References: <381eb1660611141758h25d03d22x97fa28d36a0162eb@mail.gmail.com> <200611142054.24016.Randy.OReilly@colorado.edu> <381eb1660611150802r7c179763i6a56353b3e3c2d6e@mail.gmail.com> <200611150939.29929.Randy.OReilly@colorado.edu> Message-ID: <381eb1660611160857n19f4074fne2bd2e5d0b8062bf@mail.gmail.com> Thanks for the info. I could have sworn I tried that earlier and still had the problem. In any case, the problem seems to be gone. On 11/15/06, Randall C. O'Reilly wrote: > Ok, now I see the problem: you define an InitLinks() function with nothing in > it. InitLinks MUST call the parent class's initlinks (Layer::InitLinks()), > and do any of its own functionality. In your case, you don't need it, so > remove it. You are preventing the Layer Initlinks (and its parents) from > operating... > > In version 4.0, we have a TA_SIMPLE_BASEFUNS macro that does all this > housekeeping stuff automatically :). It should be available as a beta in a > few weeks.. > > - Randy > > On Wednesday 15 November 2006 09:02, Richard Jones wrote: > > Thanks for the reply. Unfortunately, it doesn't help. In the > > TypeDef::GetValStr(...) I'm still getting an EXC_BAD_ACCESS on the > > last of the following lines: > > > > ... > > if(DerivesFrom(TA_taBase)) { > > TAPtr rbase = *((TAPtr*)base); > > if((rbase != NULL) && ((rbase->GetOwner() != NULL) || (rbase == > > tabMisc::root))) { > > > > One thing I did try, based on the first sentences of section 18.12 in > > the help: "If a class contains a pointer to another object, it should > > typically refer to that object whenever the pointer is set. The > > interface assumes that this is the case, ..." was to put a dumb check > > for equality to NULL right after setting my pointer to NULL in my > > Initialize() function. This seems to fix the problem but I don't see > > why, and I haven't yet exhaustively verified this. > > > > Does this seem like it should work? > > > > On 11/14/06, Randall C. O'Reilly wrote: > > > I bet the SIMPLE_COPY doesn't handle the memberdef* case correctly -- try > > > getting rid of that to see if that is the source of the problem. if so, > > > replace with: > > > > > > void Copy_(const TestLayer& cp) { var_md = cp.var_md; } > > > > > > - Randy > > > > > > On Tuesday 14 November 2006 18:58, Richard Jones wrote: > > > > I've been having a recurring problem with my code. Every now and then > > > > I am getting core dumps while in executing in: > > > > > > > > String TypeDef::GetValStr(...) > > > > > > > > This will usually be when I want to open an edit dialog on a newly > > > > created object, such as a layer. It also happens if I try to save my > > > > project after newly creating an object. This latter is a disaster > > > > since it writes out a corrupt proj.gz file and work is lost. It > > > > doesn't happen under all circumstances, but I've got it boiled down to > > > > reproducibility. Consider the following class: > > > > > > > > class TestLayer : public Layer { > > > > > > > > public: > > > > > > > > MemberDef* var_md; > > > > > > > > void UpdateAfterEdit() {}; > > > > void Initialize() { var_md = NULL;}; > > > > void Destroy() { }; > > > > void InitLinks() {}; > > > > SIMPLE_COPY(TestLayer); > > > > COPY_FUNS(TestLayer, Layer); > > > > TA_BASEFUNS(TestLayer); > > > > }; > > > > > > > > If in NetViewer I create just one TestLayer and then try to edit it I > > > > have no problem. If I create two and try to edit the first, again no > > > > problem. But if I try to edit the second I get the dump. Creating > > > > one at a time doesn't seem to be a problem, most of the the time. > > > > > > > > The problem is related to my inclusion of pointers to taBase classes. > > > > For instance, if I remove the "MemberDef* var_md" above the problem > > > > goes away. There must be something I'm supposed to do but am > > > > missing. Any advice I could get would be greatly welcome. > > > > > > > > Many thanks. > -- Richard Jones dickjr@gmail.com From dickjr at gmail.com Thu Nov 16 10:05:41 2006 From: dickjr at gmail.com (Richard Jones) Date: Thu Nov 16 10:05:45 2006 Subject: [pdp-discuss] ScriptPrjnSpec Message-ID: <381eb1660611160905p4a8fc870p737437e819b9e71f@mail.gmail.com> I've created a ScriptPrjnSpec and written a .css script for it. In the ScriptPrjnSpec editor I can point to the file, load the script, compile it, associate my projection with the 'prjn' variable, and run it in Interact mode. All my connection patterns and weights show up properly in my NetViewer. However, via Interact mode is the only way I've successfully gotten it to run. When I do a 'Connect All' from the NetViewer the connections disappear, and it doesn't look as if the script is run at all, even though in the debugger I see it dive into the RunScript() from ScriptPrjnSpec::Connect_impl(...). My script has the form: void MakeProjection() { ... } MakeProjection(); How do I get the script to run properly from 'Connect All'? Thanks. -- Richard Jones dickjr@gmail.com From Randy.OReilly at colorado.edu Fri Nov 17 09:10:31 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Fri Nov 17 09:10:26 2006 Subject: [pdp-discuss] ScriptPrjnSpec In-Reply-To: <381eb1660611160905p4a8fc870p737437e819b9e71f@mail.gmail.com> References: <381eb1660611160905p4a8fc870p737437e819b9e71f@mail.gmail.com> Message-ID: <200611170910.31321.Randy.OReilly@colorado.edu> very strange. I don't know what is happening. one thing you can do is go to interact mode, type "debug 1" and then do Connect all -- this will print out a trace of the css code that is being run -- hopefully that will provide some clue as to why it is not running. - Randy On Thursday 16 November 2006 10:05, Richard Jones wrote: > I've created a ScriptPrjnSpec and written a .css script for it. In > the ScriptPrjnSpec editor I can point to the file, load the script, > compile it, associate my projection with the 'prjn' variable, and run > it in Interact mode. All my connection patterns and weights show up > properly in my NetViewer. > > However, via Interact mode is the only way I've successfully gotten it > to run. When I do a 'Connect All' from the NetViewer the connections > disappear, and it doesn't look as if the script is run at all, even > though in the debugger I see it dive into the RunScript() from > ScriptPrjnSpec::Connect_impl(...). > > My script has the form: > > void MakeProjection() { > ... > } > > MakeProjection(); > > How do I get the script to run properly from 'Connect All'? Thanks. From dickjr at gmail.com Sat Nov 25 14:44:59 2006 From: dickjr at gmail.com (Richard Jones) Date: Sat Nov 25 14:45:03 2006 Subject: [pdp-discuss] weight init question Message-ID: <381eb1660611251344x7392ca91m93968f434acbb0a3@mail.gmail.com> In the book example chapter8/objrec.proj.gz, how is it that the weight values in the connections are specified? Specifically I'm wondering about the LGN->V1 projection, which uses a Tessel prjn with init_wts turned off. Many thanks. -- Richard Jones dickjr@gmail.com From Randy.OReilly at colorado.edu Mon Nov 27 20:59:51 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Mon Nov 27 21:00:08 2006 Subject: [pdp-discuss] weight init question In-Reply-To: <381eb1660611251344x7392ca91m93968f434acbb0a3@mail.gmail.com> References: <381eb1660611251344x7392ca91m93968f434acbb0a3@mail.gmail.com> Message-ID: <200611272059.51889.Randy.OReilly@colorado.edu> looks like it is the init_proc in the Train process: set_line_wts_enstopl.css -- i.e., a script run at the start of training. - Randy On Saturday 25 November 2006 14:44, Richard Jones wrote: > In the book example chapter8/objrec.proj.gz, how is it that the weight > values in the connections are specified? Specifically I'm wondering > about the LGN->V1 projection, which uses a Tessel prjn with init_wts > turned off. Many thanks.