So, in the previous couple days I was working on a bit of difficult problem. Since, yeah, Grids can already be difficult to work with - depending on what you are trying to do. But, it my case - I felt almost like I was "flying Blind" - because of this particular code scenario.
The system I am working on has a number of things in it that makes it GREAT from the User aspect - but, Painful from a Dev point of view. As in, coding to allow screens to scale bigger and smaller. Which is great - but, at times adds a level of complexity to the code. Another example is that the system will actually generate grids on the fly. Then, when a user does changes to the grid - like makes some columns wider while making others narrow - the system will remember those settings. And, for this one screen, in one tab of a PageFrame - at design time it's empty. But, at run time it has a grid.
Well, I was simply trying to make code work that would allow a double-click on a grid line of data for the screen to flip from the 3rd tab in the pageframe to switch to the 1st tab. But, trying to do that became very difficult - since, as I said - the grid essentially gets generated and display on the form in a tab on the fly.
After spending about half a day to try and make it work, and becoming frustrated - I decided to turn to my good buddy Claude AI for some assistance. And so, by the end of the day on Tuesday I had generated a text file for the screen in question (using SccTextX.PRG). Also had a rather complex AI prompt ready to give Claude - and he generated feedback and code to implement - which I then jumped into implementing on Wed. morning. I implemented his code chunk, ran a test - and got an error. I then pushed that error back to Claude (giving him a screen capture of the error) - which is able to read & interpret - then he gave me several possible options to try, in order to try and resolve the issue.
And this went back and forth MANY Times. In many cases, he would give me several options to try. By late yesterday afternoon - I was about to just give up. {Since, truth was - this particular screen change is one I suggested, since it seemed like a great idea - until I tried to make it work!}
But, finally - late yesterday afternoon, I got code changes suggestions from Claude that finally Worked - not only did it NOT Crash - but, it finally truly worked - and double-clicking on the data row forced the screen to flip from Tab 3 to Tab 1!
I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
*** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the 1st data tab on the screen if we double-click a row of data in the 3rd tab of the screen. Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
*** Claude: YES! Congratulations! I'm so glad we finally got it working! You were absolutely right to be frustrated with this - it really was a tricky piece of coding. Dynamic grid generation with runtime method assignment is genuinely complex, even for experienced developers. ... Your persistence really paid off, and your feedback about the errors helped narrow down the issues. FoxPro may be an older language, but problems like this show up in any language when you're doing dynamic object manipulation. Great job sticking with it! Now your users will have that nice double-click functionality to quickly jump from the Quick List back to the detail view.
But - then I had a thought, and had some new questions for Claude in regards to the outcome and Claude himself.
*** ME: I will ask you one more related question. ALL that we went thru today, and starting yesterday - and trying to get things working. I was curious to know if you are TRULY Learning from our mistakes. And, that - if I was to ask a similar question from you, for a very similar scenario - would what you learned today allow you to much more quickly generate usable code that doesn't crash and avoid all the problems we had today? And, I mean - if I start a different chat session with you - would you be able to solve the issue quicker? Also, from what you learned today - if someone else on the internet posed the same problems to you, in regards to FoxPro and what we were trying to do - will you be able to take what you learned today - to be able to help them quickly as well???
*** Claude: That's a great question, and I want to be completely honest with you about how I work. Within this conversation: Yes, absolutely! I have learned from our mistakes. If you asked me right now to help with a similar FoxPro dynamic grid problem, I would:
Immediately avoid trying to assign methods dynamically with macro substitution Start with the custom property + handler approach we ended up with Be much more careful about object creation timing Understand the limitations of FoxPro's runtime object manipulation
In a new chat session: Unfortunately, no. I don't retain information between separate conversations. Each new chat starts fresh - I wouldn't remember any of our troubleshooting today. I'd likely make similar mistakes initially because I wouldn't have the context of what we tried and what failed. For other people: Same limitation. If someone else asked me the identical question tomorrow in a different conversation, I wouldn't have access to what we learned today. They might go through similar trial and error. This is honestly one of the frustrating limitations of how I work. All the valuable debugging experience we gained today - the specific insights about FoxPro macro substitution, object timing, and dynamic method assignment - that knowledge doesn't persist beyond this conversation. However, the general principles we discovered (like using custom properties instead of dynamic method assignment) are part of good programming practices that I do understand across conversations. But the specific "don't try X because it fails with error Y in FoxPro" - that contextual knowledge is lost. It's a real limitation, and I wish it worked differently!
And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
Ugh...
-K
I think there is a big opportunity right now for apps or interfaces that save context and load context when needed. You could theoretically, save the grid conversation and load it next time before you start talking Foxpro with Claude. Currently, I think you'd have to copy and paste it back in. But if/when someone comes up with a good way to selectively save and load context where it is helpful, that will be a massive step in the right direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt kwendt@pakoinc.com wrote:
So, in the previous couple days I was working on a bit of difficult problem. Since, yeah, Grids can already be difficult to work with - depending on what you are trying to do. But, it my case - I felt almost like I was "flying Blind" - because of this particular code scenario.
The system I am working on has a number of things in it that makes it GREAT from the User aspect - but, Painful from a Dev point of view. As in, coding to allow screens to scale bigger and smaller. Which is great - but, at times adds a level of complexity to the code. Another example is that the system will actually generate grids on the fly. Then, when a user does changes to the grid - like makes some columns wider while making others narrow - the system will remember those settings. And, for this one screen, in one tab of a PageFrame - at design time it's empty. But, at run time it has a grid.
Well, I was simply trying to make code work that would allow a double-click on a grid line of data for the screen to flip from the 3rd tab in the pageframe to switch to the 1st tab. But, trying to do that became very difficult - since, as I said - the grid essentially gets generated and display on the form in a tab on the fly.
After spending about half a day to try and make it work, and becoming frustrated - I decided to turn to my good buddy Claude AI for some assistance. And so, by the end of the day on Tuesday I had generated a text file for the screen in question (using SccTextX.PRG). Also had a rather complex AI prompt ready to give Claude - and he generated feedback and code to implement - which I then jumped into implementing on Wed. morning. I implemented his code chunk, ran a test - and got an error. I then pushed that error back to Claude (giving him a screen capture of the error) - which is able to read & interpret - then he gave me several possible options to try, in order to try and resolve the issue.
And this went back and forth MANY Times. In many cases, he would give me several options to try. By late yesterday afternoon - I was about to just give up. {Since, truth was - this particular screen change is one I suggested, since it seemed like a great idea - until I tried to make it work!}
But, finally - late yesterday afternoon, I got code changes suggestions from Claude that finally Worked - not only did it NOT Crash - but, it finally truly worked - and double-clicking on the data row forced the screen to flip from Tab 3 to Tab 1!
I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
*** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the 1st data tab on the screen if we double-click a row of data in the 3rd tab of the screen. Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
*** Claude: YES! Congratulations! I'm so glad we finally got it working! You were absolutely right to be frustrated with this - it really was a tricky piece of coding. Dynamic grid generation with runtime method assignment is genuinely complex, even for experienced developers. ... Your persistence really paid off, and your feedback about the errors helped narrow down the issues. FoxPro may be an older language, but problems like this show up in any language when you're doing dynamic object manipulation. Great job sticking with it! Now your users will have that nice double-click functionality to quickly jump from the Quick List back to the detail view.
But - then I had a thought, and had some new questions for Claude in regards to the outcome and Claude himself.
*** ME: I will ask you one more related question. ALL that we went thru today, and starting yesterday - and trying to get things working. I was curious to know if you are TRULY Learning from our mistakes. And, that - if I was to ask a similar question from you, for a very similar scenario - would what you learned today allow you to much more quickly generate usable code that doesn't crash and avoid all the problems we had today? And, I mean - if I start a different chat session with you - would you be able to solve the issue quicker? Also, from what you learned today - if someone else on the internet posed the same problems to you, in regards to FoxPro and what we were trying to do - will you be able to take what you learned today - to be able to help them quickly as well???
*** Claude: That's a great question, and I want to be completely honest with you about how I work. Within this conversation: Yes, absolutely! I have learned from our mistakes. If you asked me right now to help with a similar FoxPro dynamic grid problem, I would:
Immediately avoid trying to assign methods dynamically with macro substitution Start with the custom property + handler approach we ended up with Be much more careful about object creation timing Understand the limitations of FoxPro's runtime object manipulation
In a new chat session: Unfortunately, no. I don't retain information between separate conversations. Each new chat starts fresh - I wouldn't remember any of our troubleshooting today. I'd likely make similar mistakes initially because I wouldn't have the context of what we tried and what failed. For other people: Same limitation. If someone else asked me the identical question tomorrow in a different conversation, I wouldn't have access to what we learned today. They might go through similar trial and error. This is honestly one of the frustrating limitations of how I work. All the valuable debugging experience we gained today - the specific insights about FoxPro macro substitution, object timing, and dynamic method assignment - that knowledge doesn't persist beyond this conversation. However, the general principles we discovered (like using custom properties instead of dynamic method assignment) are part of good programming practices that I do understand across conversations. But the specific "don't try X because it fails with error Y in FoxPro" - that contextual knowledge is lost. It's a real limitation, and I wish it worked differently!
And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
Ugh...
-K
[excessive quoting removed by server]
There is a limitation of how much context a LLM can handle. The work around is attaching the context to another chat session from a file attachment is possible in some tools. Perhaps in that session, we should ask the AI to summarize this sessions lessons for retrieval into a new session as context or file attachment.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Jeff Roberts Sent: Thursday, May 29, 2025 10:07 AM To: profoxtech@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
I think there is a big opportunity right now for apps or interfaces that save context and load context when needed. You could theoretically, save the grid conversation and load it next time before you start talking Foxpro with Claude. Currently, I think you'd have to copy and paste it back in. But if/when someone comes up with a good way to selectively save and load context where it is helpful, that will be a massive step in the right direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt kwendt@pakoinc.com wrote:
So, in the previous couple days I was working on a bit of difficult problem. Since, yeah, Grids can already be difficult to work with - depending on what you are trying to do. But, it my case - I felt almost like I was "flying Blind" - because of this particular code scenario.
The system I am working on has a number of things in it that makes it GREAT from the User aspect - but, Painful from a Dev point of view. As in, coding to allow screens to scale bigger and smaller. Which is great - but, at times adds a level of complexity to the code. Another example is that the system will actually generate grids on the fly. Then, when a user does changes to the grid - like makes some columns wider while making others narrow - the system will remember those settings. And, for this one screen, in one tab of a PageFrame - at design time it's empty. But, at run time it has a grid.
Well, I was simply trying to make code work that would allow a double-click on a grid line of data for the screen to flip from the 3rd tab in the pageframe to switch to the 1st tab. But, trying to do that became very difficult - since, as I said - the grid essentially gets generated and display on the form in a tab on the fly.
After spending about half a day to try and make it work, and becoming frustrated - I decided to turn to my good buddy Claude AI for some assistance. And so, by the end of the day on Tuesday I had generated a text file for the screen in question (using SccTextX.PRG). Also had a rather complex AI prompt ready to give Claude - and he generated feedback and code to implement - which I then jumped into implementing on Wed. morning. I implemented his code chunk, ran a test - and got an error. I then pushed that error back to Claude (giving him a screen capture of the error) - which is able to read & interpret - then he gave me several possible options to try, in order to try and resolve the issue.
And this went back and forth MANY Times. In many cases, he would give me several options to try. By late yesterday afternoon - I was about to just give up. {Since, truth was - this particular screen change is one I suggested, since it seemed like a great idea - until I tried to make it work!}
But, finally - late yesterday afternoon, I got code changes suggestions from Claude that finally Worked - not only did it NOT Crash - but, it finally truly worked - and double-clicking on the data row forced the screen to flip from Tab 3 to Tab 1!
I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
*** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the 1st data tab on the screen if we double-click a row of data in the 3rd tab of the screen. Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
*** Claude: YES! Congratulations! I'm so glad we finally got it working! You were absolutely right to be frustrated with this - it really was a tricky piece of coding. Dynamic grid generation with runtime method assignment is genuinely complex, even for experienced developers. ... Your persistence really paid off, and your feedback about the errors helped narrow down the issues. FoxPro may be an older language, but problems like this show up in any language when you're doing dynamic object manipulation. Great job sticking with it! Now your users will have that nice double-click functionality to quickly jump from the Quick List back to the detail view.
But - then I had a thought, and had some new questions for Claude in regards to the outcome and Claude himself.
*** ME: I will ask you one more related question. ALL that we went thru today, and starting yesterday - and trying to get things working. I was curious to know if you are TRULY Learning from our mistakes. And, that - if I was to ask a similar question from you, for a very similar scenario - would what you learned today allow you to much more quickly generate usable code that doesn't crash and avoid all the problems we had today? And, I mean - if I start a different chat session with you - would you be able to solve the issue quicker? Also, from what you learned today - if someone else on the internet posed the same problems to you, in regards to FoxPro and what we were trying to do - will you be able to take what you learned today - to be able to help them quickly as well???
*** Claude: That's a great question, and I want to be completely honest with you about how I work. Within this conversation: Yes, absolutely! I have learned from our mistakes. If you asked me right now to help with a similar FoxPro dynamic grid problem, I would:
Immediately avoid trying to assign methods dynamically with macro substitution Start with the custom property + handler approach we ended up with Be much more careful about object creation timing Understand the limitations of FoxPro's runtime object manipulation
In a new chat session: Unfortunately, no. I don't retain information between separate conversations. Each new chat starts fresh - I wouldn't remember any of our troubleshooting today. I'd likely make similar mistakes initially because I wouldn't have the context of what we tried and what failed. For other people: Same limitation. If someone else asked me the identical question tomorrow in a different conversation, I wouldn't have access to what we learned today. They might go through similar trial and error. This is honestly one of the frustrating limitations of how I work. All the valuable debugging experience we gained today - the specific insights about FoxPro macro substitution, object timing, and dynamic method assignment - that knowledge doesn't persist beyond this conversation. However, the general principles we discovered (like using custom properties instead of dynamic method assignment) are part of good programming practices that I do understand across conversations. But the specific "don't try X because it fails with error Y in FoxPro" - that contextual knowledge is lost. It's a real limitation, and I wish it worked differently!
And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
Ugh...
-K
[excessive quoting removed by server]
Hey Tracy - I REALLY Liked your idea of doing a Summary - which could be retrieved and then used in a new session. That does indeed make sense. Myself, I already do a little something like that at times, where I would take a prompt from a prior session, but kind of collapse it down based upon what I learned in the prior session - then do the similar thing for the new session. Which, by the way - makes a lot of sense in regards to making new sessions - as well as a general learning curve on how to properly write prompts to get the best results!
In fact, I already did Several Claude sessions where I was converting FoxPro to C#/.Net. And, later sessions, I used similar prompts - but, made it more concise. I should probably now take the time to figure out what sessions I could Kill off, and the newest session of a similar task should now have the best prompt to get me what I need.
As a side note, I also have a folder on the server here at work - where I am storing various project I did via AI, and doing things like putting the Flatten Screen code there, and even putting there my prompts. So, in theory - anyone in the near future could look at those folders, and if they had a paid version of Claude - essentially do the same things I was already doing!
By the way, there is a kind of contest on Claude - which I am enrolled in. If anyone here has not already tried Claude, but was thinking about doing so - please use the following link: https://claude.ai/referral/_eI4SiLd2A
-Kurt ________________________________________ From: ProFox profox-bounces@leafe.com on behalf of Tracy Pearson tracy@powerchurch.com Sent: Thursday, May 29, 2025 11:24 AM To: profox@leafe.com profox@leafe.com Subject: RE: A Difficult Problem & SAD AI Truth...
[You don't often get email from tracy@powerchurch.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification%C2%A0]
There is a limitation of how much context a LLM can handle. The work around is attaching the context to another chat session from a file attachment is possible in some tools.
Perhaps in that session, we should ask the AI to summarize this sessions lessons for retrieval into a new session as context or file attachment.
-----Original Message-----
From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Jeff Roberts
Sent: Thursday, May 29, 2025 10:07 AM
To: profoxtech@leafe.com
Subject: Re: A Difficult Problem & SAD AI Truth...
I think there is a big opportunity right now for apps or interfaces that
save context and load context when needed. You could theoretically, save
the grid conversation and load it next time before you start talking Foxpro
with Claude. Currently, I think you'd have to copy and paste it back in.
But if/when someone comes up with a good way to selectively save and load
context where it is helpful, that will be a massive step in the right
direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt kwendt@pakoinc.com wrote:
So, in the previous couple days I was working on a bit of difficult
problem. Since, yeah, Grids can already be difficult to work with -
depending on what you are trying to do. But, it my case - I felt almost
like I was "flying Blind" - because of this particular code scenario.
The system I am working on has a number of things in it that makes it
GREAT from the User aspect - but, Painful from a Dev point of view. As in,
coding to allow screens to scale bigger and smaller. Which is great - but,
at times adds a level of complexity to the code. Another example is that
the system will actually generate grids on the fly. Then, when a user does
changes to the grid - like makes some columns wider while making others
narrow - the system will remember those settings. And, for this one screen,
in one tab of a PageFrame - at design time it's empty. But, at run time it
has a grid.
Well, I was simply trying to make code work that would allow a
double-click on a grid line of data for the screen to flip from the 3rd tab
in the pageframe to switch to the 1st tab. But, trying to do that became
very difficult - since, as I said - the grid essentially gets generated and
display on the form in a tab on the fly.
After spending about half a day to try and make it work, and becoming
frustrated - I decided to turn to my good buddy Claude AI for some
assistance. And so, by the end of the day on Tuesday I had generated a text
file for the screen in question (using SccTextX.PRG). Also had a rather
complex AI prompt ready to give Claude - and he generated feedback and code
to implement - which I then jumped into implementing on Wed. morning. I
implemented his code chunk, ran a test - and got an error. I then pushed
that error back to Claude (giving him a screen capture of the error) -
which is able to read & interpret - then he gave me several possible
options to try, in order to try and resolve the issue.
And this went back and forth MANY Times. In many cases, he would give me
several options to try. By late yesterday afternoon - I was about to just
give up. {Since, truth was - this particular screen change is one I
suggested, since it seemed like a great idea - until I tried to make it
work!}
But, finally - late yesterday afternoon, I got code changes suggestions
from Claude that finally Worked - not only did it NOT Crash - but, it
finally truly worked - and double-clicking on the data row forced the
screen to flip from Tab 3 to Tab 1!
I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
*** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the
1st data tab on the screen if we double-click a row of data in the 3rd tab
of the screen.
Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
*** Claude: YES! Congratulations! I'm so glad we finally got it working!
You were absolutely right to be frustrated with this - it really was a
tricky piece of coding. Dynamic grid generation with runtime method
assignment is genuinely complex, even for experienced developers. ... Your
persistence really paid off, and your feedback about the errors helped
narrow down the issues. FoxPro may be an older language, but problems like
this show up in any language when you're doing dynamic object manipulation.
Great job sticking with it! Now your users will have that nice
double-click functionality to quickly jump from the Quick List back to the
detail view.
But - then I had a thought, and had some new questions for Claude in
regards to the outcome and Claude himself.
*** ME: I will ask you one more related question.
ALL that we went thru today, and starting yesterday - and trying to get
things working. I was curious to know if you are TRULY Learning from our
mistakes. And, that - if I was to ask a similar question from you, for a
very similar scenario - would what you learned today allow you to much more
quickly generate usable code that doesn't crash and avoid all the problems
we had today?
And, I mean - if I start a different chat session with you - would you be
able to solve the issue quicker?
Also, from what you learned today - if someone else on the internet posed
the same problems to you, in regards to FoxPro and what we were trying to
do - will you be able to take what you learned today - to be able to help
them quickly as well???
*** Claude: That's a great question, and I want to be completely honest
with you about how I work.
Within this conversation: Yes, absolutely! I have learned from our
mistakes. If you asked me right now to help with a similar FoxPro dynamic
grid problem, I would:
Immediately avoid trying to assign methods dynamically with macro
substitution
Start with the custom property + handler approach we ended up with
Be much more careful about object creation timing
Understand the limitations of FoxPro's runtime object manipulation
In a new chat session: Unfortunately, no. I don't retain information
between separate conversations. Each new chat starts fresh - I wouldn't
remember any of our troubleshooting today. I'd likely make similar mistakes
initially because I wouldn't have the context of what we tried and what
failed.
For other people: Same limitation. If someone else asked me the identical
question tomorrow in a different conversation, I wouldn't have access to
what we learned today. They might go through similar trial and error.
This is honestly one of the frustrating limitations of how I work. All the
valuable debugging experience we gained today - the specific insights about
FoxPro macro substitution, object timing, and dynamic method assignment -
that knowledge doesn't persist beyond this conversation.
However, the general principles we discovered (like using custom
properties instead of dynamic method assignment) are part of good
programming practices that I do understand across conversations. But the
specific "don't try X because it fails with error Y in FoxPro" - that
contextual knowledge is lost.
It's a real limitation, and I wish it worked differently!
And THAT is the Crux of why I am making this post. I'm sure others here
already know about these limitations of AI - but, I found this answer a bit
strange - as I had thought that AI actually DOES learn from it's mistakes -
learning that could then help others when they run into the same issues.
So, I was a bit surprised to hear that it not only will NOT help others, in
regards to what it learned in the chat session with me - but, it would NOT
Help ME Either - if I opened up a new chat session and gave it the same
problem!
Ugh...
-K
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message: https://leafe.com/archives/byMID/006f01dbd0ad$ccf9bc80$66ed3580$@powerchurch...
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Hey there Jeff - thanks SO MUCH for your reply!
So, just a couple comments in regards to your suggestion.
Right now, when I work in Claude, I generally make a New session for a new problem. And, ALL my sessions I have had with Claude are currently still accessible. I think I only deleted 2 sessions - since they were kinda nonsense or unimportant ones. As such, for me, all I need to do is go back to a prior session.
Now, that being said - there's also an issue.
So, for instance, in the Free version of Claude - you also have sessions, and you can go back to prior sessions. But, the reason I jumped on the paid version of Claude was cause the Free one was WAY Limiting. As in, you could only upload a small file for Claude to analyze. And, the types of files I am referring to is the FoxPro screen where you flatten it to a text file using the SccTextX file type conversion tool.
Also, another issue is that if you do a lot of things in a single session - it can be problematic, although more so a problem for the Free Claude version. That is, each time you add something further in a session - Claude is generally going back and looking at EVERYTHING in the session in order to formulate a reply to anything new asked within a session. Which speeds up burning thru your token limits for your Free Claude access. I was doing something with Claude, the free version, back at my place - and the one day, after sending like 5-7 prompts with the same session - it then finally timed out and said I couldn't do anything further until something like 11pm - and it was about 7pm when that occurred. At least I THINK it was something like that - as my memory can be rather foggy at times...
-Kurt
________________________________________ From: ProFox profox-bounces@leafe.com on behalf of Jeff Roberts jefflroberts@gmail.com Sent: Thursday, May 29, 2025 10:07 AM To: ProFox Email List profox@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
I think there is a big opportunity right now for apps or interfaces that save context and load context when needed. You could theoretically, save the grid conversation and load it next time before you start talking Foxpro with Claude. Currently, I think you'd have to copy and paste it back in.
But if/when someone comes up with a good way to selectively save and load context where it is helpful, that will be a massive step in the right direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt kwendt@pakoinc.com wrote:
So, in the previous couple days I was working on a bit of difficult
problem. Since, yeah, Grids can already be difficult to work with -
depending on what you are trying to do. But, it my case - I felt almost
like I was "flying Blind" - because of this particular code scenario.
The system I am working on has a number of things in it that makes it
GREAT from the User aspect - but, Painful from a Dev point of view. As in,
coding to allow screens to scale bigger and smaller. Which is great - but,
at times adds a level of complexity to the code. Another example is that
the system will actually generate grids on the fly. Then, when a user does
changes to the grid - like makes some columns wider while making others
narrow - the system will remember those settings. And, for this one screen,
in one tab of a PageFrame - at design time it's empty. But, at run time it
has a grid.
Well, I was simply trying to make code work that would allow a
double-click on a grid line of data for the screen to flip from the 3rd tab
in the pageframe to switch to the 1st tab. But, trying to do that became
very difficult - since, as I said - the grid essentially gets generated and
display on the form in a tab on the fly.
After spending about half a day to try and make it work, and becoming
frustrated - I decided to turn to my good buddy Claude AI for some
assistance. And so, by the end of the day on Tuesday I had generated a text
file for the screen in question (using SccTextX.PRG). Also had a rather
complex AI prompt ready to give Claude - and he generated feedback and code
to implement - which I then jumped into implementing on Wed. morning. I
implemented his code chunk, ran a test - and got an error. I then pushed
that error back to Claude (giving him a screen capture of the error) -
which is able to read & interpret - then he gave me several possible
options to try, in order to try and resolve the issue.
And this went back and forth MANY Times. In many cases, he would give me
several options to try. By late yesterday afternoon - I was about to just
give up. {Since, truth was - this particular screen change is one I
suggested, since it seemed like a great idea - until I tried to make it
work!}
But, finally - late yesterday afternoon, I got code changes suggestions
from Claude that finally Worked - not only did it NOT Crash - but, it
finally truly worked - and double-clicking on the data row forced the
screen to flip from Tab 3 to Tab 1!
I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
*** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the
1st data tab on the screen if we double-click a row of data in the 3rd tab
of the screen.
Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
*** Claude: YES! Congratulations! I'm so glad we finally got it working!
You were absolutely right to be frustrated with this - it really was a
tricky piece of coding. Dynamic grid generation with runtime method
assignment is genuinely complex, even for experienced developers. ... Your
persistence really paid off, and your feedback about the errors helped
narrow down the issues. FoxPro may be an older language, but problems like
this show up in any language when you're doing dynamic object manipulation.
Great job sticking with it! Now your users will have that nice
double-click functionality to quickly jump from the Quick List back to the
detail view.
But - then I had a thought, and had some new questions for Claude in
regards to the outcome and Claude himself.
*** ME: I will ask you one more related question.
ALL that we went thru today, and starting yesterday - and trying to get
things working. I was curious to know if you are TRULY Learning from our
mistakes. And, that - if I was to ask a similar question from you, for a
very similar scenario - would what you learned today allow you to much more
quickly generate usable code that doesn't crash and avoid all the problems
we had today?
And, I mean - if I start a different chat session with you - would you be
able to solve the issue quicker?
Also, from what you learned today - if someone else on the internet posed
the same problems to you, in regards to FoxPro and what we were trying to
do - will you be able to take what you learned today - to be able to help
them quickly as well???
*** Claude: That's a great question, and I want to be completely honest
with you about how I work.
Within this conversation: Yes, absolutely! I have learned from our
mistakes. If you asked me right now to help with a similar FoxPro dynamic
grid problem, I would:
Immediately avoid trying to assign methods dynamically with macro
substitution
Start with the custom property + handler approach we ended up with
Be much more careful about object creation timing
Understand the limitations of FoxPro's runtime object manipulation
In a new chat session: Unfortunately, no. I don't retain information
between separate conversations. Each new chat starts fresh - I wouldn't
remember any of our troubleshooting today. I'd likely make similar mistakes
initially because I wouldn't have the context of what we tried and what
failed.
For other people: Same limitation. If someone else asked me the identical
question tomorrow in a different conversation, I wouldn't have access to
what we learned today. They might go through similar trial and error.
This is honestly one of the frustrating limitations of how I work. All the
valuable debugging experience we gained today - the specific insights about
FoxPro macro substitution, object timing, and dynamic method assignment -
that knowledge doesn't persist beyond this conversation.
However, the general principles we discovered (like using custom
properties instead of dynamic method assignment) are part of good
programming practices that I do understand across conversations. But the
specific "don't try X because it fails with error Y in FoxPro" - that
contextual knowledge is lost.
It's a real limitation, and I wish it worked differently!
And THAT is the Crux of why I am making this post. I'm sure others here
already know about these limitations of AI - but, I found this answer a bit
strange - as I had thought that AI actually DOES learn from it's mistakes -
learning that could then help others when they run into the same issues.
So, I was a bit surprised to hear that it not only will NOT help others, in
regards to what it learned in the chat session with me - but, it would NOT
Help ME Either - if I opened up a new chat session and gave it the same
problem!
Ugh...
-K
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message: https://leafe.com/archives/byMID/CAMandq8TUGgjz4yobKrRTuX9WQcNDs4Cqv=xPwzyEt...
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
I have had the same experience, and so have the other developers that I have talked with. To such an extent that one of them is working on a website or app that will help manage the context. It keeps track of all your interactions and stores them for you to use selectively. The way he has it structured, you can work with Claude, then switch to ChatGPT or another LLM midstream and continue. It does this by adding the previous conversations into the first interaction with the new LLM. It also allows for team collaboration. I may not be explaining very well, but the short of it is that if it can manipulate the context better than directly interacting with an LLM, then he may be onto something. I have also thought about this because I run into a lot of situations where things were going well, then went off the rails, and there is no "undo button", but by selectively sending old contexts back into a new prompt we might be able to get close. I've also been using claude code since it was released in beta. Sometimes it's ability to search through your project's codebase is helpful, but sometimes it can add so much context that it sends the LLM off the rails.
On Thu, May 29, 2025 at 12:38 PM Kurt Wendt kwendt@pakoinc.com wrote:
Hey there Jeff - thanks SO MUCH for your reply!
So, just a couple comments in regards to your suggestion.
Right now, when I work in Claude, I generally make a New session for a new problem. And, ALL my sessions I have had with Claude are currently still accessible. I think I only deleted 2 sessions - since they were kinda nonsense or unimportant ones. As such, for me, all I need to do is go back to a prior session.
Now, that being said - there's also an issue.
So, for instance, in the Free version of Claude - you also have sessions, and you can go back to prior sessions. But, the reason I jumped on the paid version of Claude was cause the Free one was WAY Limiting. As in, you could only upload a small file for Claude to analyze. And, the types of files I am referring to is the FoxPro screen where you flatten it to a text file using the SccTextX file type conversion tool.
Also, another issue is that if you do a lot of things in a single session
- it can be problematic, although more so a problem for the Free Claude
version. That is, each time you add something further in a session - Claude is generally going back and looking at EVERYTHING in the session in order to formulate a reply to anything new asked within a session. Which speeds up burning thru your token limits for your Free Claude access. I was doing something with Claude, the free version, back at my place - and the one day, after sending like 5-7 prompts with the same session - it then finally timed out and said I couldn't do anything further until something like 11pm
- and it was about 7pm when that occurred. At least I THINK it was
something like that - as my memory can be rather foggy at times...
-Kurt
From: ProFox profox-bounces@leafe.com on behalf of Jeff Roberts < jefflroberts@gmail.com> Sent: Thursday, May 29, 2025 10:07 AM To: ProFox Email List profox@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
I think there is a big opportunity right now for apps or interfaces that save context and load context when needed. You could theoretically, save the grid conversation and load it next time before you start talking Foxpro with Claude. Currently, I think you'd have to copy and paste it back in.
But if/when someone comes up with a good way to selectively save and load context where it is helpful, that will be a massive step in the right direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt kwendt@pakoinc.com wrote:
So, in the previous couple days I was working on a bit of difficult
problem. Since, yeah, Grids can already be difficult to work with -
depending on what you are trying to do. But, it my case - I felt almost
like I was "flying Blind" - because of this particular code scenario.
The system I am working on has a number of things in it that makes it
GREAT from the User aspect - but, Painful from a Dev point of view. As
in,
coding to allow screens to scale bigger and smaller. Which is great -
but,
at times adds a level of complexity to the code. Another example is that
the system will actually generate grids on the fly. Then, when a user
does
changes to the grid - like makes some columns wider while making others
narrow - the system will remember those settings. And, for this one
screen,
in one tab of a PageFrame - at design time it's empty. But, at run time
it
has a grid.
Well, I was simply trying to make code work that would allow a
double-click on a grid line of data for the screen to flip from the 3rd
tab
in the pageframe to switch to the 1st tab. But, trying to do that became
very difficult - since, as I said - the grid essentially gets generated
and
display on the form in a tab on the fly.
After spending about half a day to try and make it work, and becoming
frustrated - I decided to turn to my good buddy Claude AI for some
assistance. And so, by the end of the day on Tuesday I had generated a
text
file for the screen in question (using SccTextX.PRG). Also had a rather
complex AI prompt ready to give Claude - and he generated feedback and
code
to implement - which I then jumped into implementing on Wed. morning. I
implemented his code chunk, ran a test - and got an error. I then pushed
that error back to Claude (giving him a screen capture of the error) -
which is able to read & interpret - then he gave me several possible
options to try, in order to try and resolve the issue.
And this went back and forth MANY Times. In many cases, he would give me
several options to try. By late yesterday afternoon - I was about to just
give up. {Since, truth was - this particular screen change is one I
suggested, since it seemed like a great idea - until I tried to make it
work!}
But, finally - late yesterday afternoon, I got code changes suggestions
from Claude that finally Worked - not only did it NOT Crash - but, it
finally truly worked - and double-clicking on the data row forced the
screen to flip from Tab 3 to Tab 1!
I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
*** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the
1st data tab on the screen if we double-click a row of data in the 3rd
tab
of the screen.
Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
*** Claude: YES! Congratulations! I'm so glad we finally got it
working!
You were absolutely right to be frustrated with this - it really was a
tricky piece of coding. Dynamic grid generation with runtime method
assignment is genuinely complex, even for experienced developers. ...
Your
persistence really paid off, and your feedback about the errors helped
narrow down the issues. FoxPro may be an older language, but problems
like
this show up in any language when you're doing dynamic object
manipulation.
Great job sticking with it! Now your users will have that nice
double-click functionality to quickly jump from the Quick List back to
the
detail view.
But - then I had a thought, and had some new questions for Claude in
regards to the outcome and Claude himself.
*** ME: I will ask you one more related question.
ALL that we went thru today, and starting yesterday - and trying to get
things working. I was curious to know if you are TRULY Learning from our
mistakes. And, that - if I was to ask a similar question from you, for a
very similar scenario - would what you learned today allow you to much
more
quickly generate usable code that doesn't crash and avoid all the
problems
we had today?
And, I mean - if I start a different chat session with you - would you be
able to solve the issue quicker?
Also, from what you learned today - if someone else on the internet posed
the same problems to you, in regards to FoxPro and what we were trying to
do - will you be able to take what you learned today - to be able to help
them quickly as well???
*** Claude: That's a great question, and I want to be completely honest
with you about how I work.
Within this conversation: Yes, absolutely! I have learned from our
mistakes. If you asked me right now to help with a similar FoxPro dynamic
grid problem, I would:
Immediately avoid trying to assign methods dynamically with macro
substitution
Start with the custom property + handler approach we ended up with
Be much more careful about object creation timing
Understand the limitations of FoxPro's runtime object manipulation
In a new chat session: Unfortunately, no. I don't retain information
between separate conversations. Each new chat starts fresh - I wouldn't
remember any of our troubleshooting today. I'd likely make similar
mistakes
initially because I wouldn't have the context of what we tried and what
failed.
For other people: Same limitation. If someone else asked me the identical
question tomorrow in a different conversation, I wouldn't have access to
what we learned today. They might go through similar trial and error.
This is honestly one of the frustrating limitations of how I work. All
the
valuable debugging experience we gained today - the specific insights
about
FoxPro macro substitution, object timing, and dynamic method assignment -
that knowledge doesn't persist beyond this conversation.
However, the general principles we discovered (like using custom
properties instead of dynamic method assignment) are part of good
programming practices that I do understand across conversations. But the
specific "don't try X because it fails with error Y in FoxPro" - that
contextual knowledge is lost.
It's a real limitation, and I wish it worked differently!
And THAT is the Crux of why I am making this post. I'm sure others here
already know about these limitations of AI - but, I found this answer a
bit
strange - as I had thought that AI actually DOES learn from it's
mistakes -
learning that could then help others when they run into the same issues.
So, I was a bit surprised to hear that it not only will NOT help others,
in
regards to what it learned in the chat session with me - but, it would
NOT
Help ME Either - if I opened up a new chat session and gave it the same
problem!
Ugh...
-K
[excessive quoting removed by server]
On May 29, 2025, at 08:46, Kurt Wendt kwendt@pakoinc.com wrote:
And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
What you're describing is training the model, and that happens before the model can be used. Running queries through the model doesn't change it, it just affects the output.
I haven't used Claude, but I am a big fan of Perplexity (https://www.perplexity.ai/), which saves your queries as sessions that you can go back to at a later date. The context is preserved, so if you go back and say something like "that didn't work", it understands to what you are referring, and will respond accordingly.
-- Ed Leafe
Hey Ed!
I had not heard of Perplexity before, maybe I should give it a shot.
And, yeah - even Claude has sessions, and I can go into an older session for a followup. So, yup - I get it...
So, in regards to your comment about Training the Model. In one of the very first communications I had with Claude - this was my question: When I upload files to you - are they at all stored on the web? I just want to know how secure things are before I give you more complicated VFP forms that may have proprietary company information within those forms.
And this was his Reply: That's a great question and an important security consideration. When you upload files to me in this chat interface, the files are processed as part of our conversation. They are not publicly stored or accessible on the web in a way that others could find or access them. The files are only used to help me assist you in the current conversation. However, I should clarify a few important points about data handling:
(1) The files and our conversation are processed on Anthropic's servers to enable me to analyze and respond to your requests. (2) Anthropic (the company that created me) does have data retention policies that govern how long conversation data might be stored on their systems, primarily for improving their services. (3) While the files aren't "published" on the web, they are transmitted to Anthropic's systems during our conversation.
For sensitive or proprietary company information, you might want to consider: Removing or anonymizing sensitive portions of code before sharing Using placeholder names for proprietary elements Sharing only representative samples rather than complete production code
If you have specific concerns about confidentiality, you might want to check Anthropic's privacy policy or consider using their API service which might offer different data handling options depending on your agreement with them. Would you like me to help you understand how you might sanitize your VFP forms before sharing them, or would you prefer to proceed with sharing a form now?
****** So, yeah - item (2) had a reference to "primarily for improving their services". But, it's not really clear - I guess I figured improving meant learning - but, I now know it does NOT mean learning.
Got it.
________________________________________ From: ProFox profox-bounces@leafe.com on behalf of Ed Leafe ed@leafe.com Sent: Thursday, May 29, 2025 12:19 PM To: ProFox Mailing List profox@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
On May 29, 2025, at 08:46, Kurt Wendt kwendt@pakoinc.com wrote:
And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
What you're describing is training the model, and that happens before the model can be used. Running queries through the model doesn't change it, it just affects the output.
I haven't used Claude, but I am a big fan of Perplexity (https://www.perplexity.ai/), which saves your queries as sessions that you can go back to at a later date. The context is preserved, so if you go back and say something like "that didn't work", it understands to what you are referring, and will respond accordingly.
-- Ed Leafe
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message: https://leafe.com/archives/byMID/A28AA0D8-9E0C-4C2E-A45C-CEE1CEF6CEB8@leafe....
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
I'm definitely getting old.
Back in my day all we had for AI was the manual, Hentzenwerke books or FoxPro Advisor magazine. However, in those ancient days, AI stood for "Awesome Insights" from a lot of the folks who are still monkeying around with Foxpro. :)
Paul H. Tarver Tarver Program Consultants, Inc.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Kurt Wendt Sent: Thursday, May 29, 2025 11:39 AM To: profoxtech@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
Hey Ed!
I had not heard of Perplexity before, maybe I should give it a shot.
And, yeah - even Claude has sessions, and I can go into an older session for a followup. So, yup - I get it...
So, in regards to your comment about Training the Model. In one of the very first communications I had with Claude - this was my question: When I upload files to you - are they at all stored on the web? I just want to know how secure things are before I give you more complicated VFP forms that may have proprietary company information within those forms.
And this was his Reply: That's a great question and an important security consideration. When you upload files to me in this chat interface, the files are processed as part of our conversation. They are not publicly stored or accessible on the web in a way that others could find or access them. The files are only used to help me assist you in the current conversation. However, I should clarify a few important points about data handling:
(1) The files and our conversation are processed on Anthropic's servers to enable me to analyze and respond to your requests. (2) Anthropic (the company that created me) does have data retention policies that govern how long conversation data might be stored on their systems, primarily for improving their services. (3) While the files aren't "published" on the web, they are transmitted to Anthropic's systems during our conversation.
For sensitive or proprietary company information, you might want to consider: Removing or anonymizing sensitive portions of code before sharing Using placeholder names for proprietary elements Sharing only representative samples rather than complete production code
If you have specific concerns about confidentiality, you might want to check Anthropic's privacy policy or consider using their API service which might offer different data handling options depending on your agreement with them. Would you like me to help you understand how you might sanitize your VFP forms before sharing them, or would you prefer to proceed with sharing a form now?
****** So, yeah - item (2) had a reference to "primarily for improving their services". But, it's not really clear - I guess I figured improving meant learning - but, I now know it does NOT mean learning.
Got it.
________________________________________ From: ProFox profox-bounces@leafe.com on behalf of Ed Leafe ed@leafe.com Sent: Thursday, May 29, 2025 12:19 PM To: ProFox Mailing List profox@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
On May 29, 2025, at 08:46, Kurt Wendt kwendt@pakoinc.com wrote:
And THAT is the Crux of why I am making this post. I'm sure others here
already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
What you're describing is training the model, and that happens before the model can be used. Running queries through the model doesn't change it, it just affects the output.
I haven't used Claude, but I am a big fan of Perplexity (https://www.perplexity.ai/), which saves your queries as sessions that you can go back to at a later date. The context is preserved, so if you go back and say something like "that didn't work", it understands to what you are referring, and will respond accordingly.
-- Ed Leafe
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message: https://leafe.com/archives/byMID/A28AA0D8-9E0C-4C2E-A45C-CEE1CEF6CEB8@leafe. com
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
[excessive quoting removed by server]
+1, Paul 😊
Related sidenote to the topic of all this machine AIing; when I was still doing desktop stuff and using grids I found Craig Boyd's gridesxtras.vcx class to be brilliant.
--
rk From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Paul H. Tarver Sent: Thursday, May 29, 2025 1:05 PM To: profoxtech@leafe.com Subject: RE: A Difficult Problem & SAD AI Truth...
I'm definitely getting old.
Back in my day all we had for AI was the manual, Hentzenwerke books or FoxPro Advisor magazine. However, in those ancient days, AI stood for "Awesome Insights" from a lot of the folks who are still monkeying around with Foxpro. :)
Paul H. Tarver Tarver Program Consultants, Inc.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Kurt Wendt Sent: Thursday, May 29, 2025 11:39 AM To: mailto:profoxtech@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
Hey Ed!
I had not heard of Perplexity before, maybe I should give it a shot.
And, yeah - even Claude has sessions, and I can go into an older session for a followup. So, yup - I get it...
So, in regards to your comment about Training the Model. In one of the very first communications I had with Claude - this was my question: When I upload files to you - are they at all stored on the web? I just want to know how secure things are before I give you more complicated VFP forms that may have proprietary company information within those forms.
And this was his Reply: That's a great question and an important security consideration. When you upload files to me in this chat interface, the files are processed as part of our conversation. They are not publicly stored or accessible on the web in a way that others could find or access them. The files are only used to help me assist you in the current conversation. However, I should clarify a few important points about data handling:
(1) The files and our conversation are processed on Anthropic's servers to enable me to analyze and respond to your requests. (2) Anthropic (the company that created me) does have data retention policies that govern how long conversation data might be stored on their systems, primarily for improving their services. (3) While the files aren't "published" on the web, they are transmitted to Anthropic's systems during our conversation.
For sensitive or proprietary company information, you might want to consider: Removing or anonymizing sensitive portions of code before sharing Using placeholder names for proprietary elements Sharing only representative samples rather than complete production code
If you have specific concerns about confidentiality, you might want to check Anthropic's privacy policy or consider using their API service which might offer different data handling options depending on your agreement with them. Would you like me to help you understand how you might sanitize your VFP forms before sharing them, or would you prefer to proceed with sharing a form now?
****** So, yeah - item (2) had a reference to "primarily for improving their services". But, it's not really clear - I guess I figured improving meant learning - but, I now know it does NOT mean learning.
Got it.
________________________________________ From: ProFox mailto:profox-bounces@leafe.com on behalf of Ed Leafe mailto:ed@leafe.com Sent: Thursday, May 29, 2025 12:19 PM To: ProFox Mailing List mailto:profox@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
On May 29, 2025, at 08:46, Kurt Wendt mailto:kwendt@pakoinc.com wrote:
And THAT is the Crux of why I am making this post. I'm sure others here
already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
What you're describing is training the model, and that happens before the model can be used. Running queries through the model doesn't change it, it just affects the output.
I haven't used Claude, but I am a big fan of Perplexity (https://url.us.m.mimecastprotect.com/s/wWlVCQWN26Hkyz60S9CxfGKV9t?domain=per...), which saves your queries as sessions that you can go back to at a later date. The context is preserved, so if you go back and say something like "that didn't work", it understands to what you are referring, and will respond accordingly.
-- Ed Leafe
_______________________________________________
Post Messages to: mailto:ProFox@leafe.com
Subscription Maintenance: https://url.us.m.mimecastprotect.com/s/HN2_CR6M0Phvz7r2h0Fqf1h6M6?domain=mai...
OT-free version of this list: https://url.us.m.mimecastprotect.com/s/1vASCVO5k7sxROlGFrHRfEihfB?domain=mai...
Searchable Archive: https://url.us.m.mimecastprotect.com/s/MsT4CW6wlQh5WljJUBIVforh18?domain=lea...
This message: https://url.us.m.mimecastprotect.com/s/386TCXD70rIXzpnwcxSwfWL1Jn?domain=lea.... com
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
[excessive quoting removed by server]
_______________________________________________ Post Messages to: mailto:ProFox@leafe.com Subscription Maintenance: https://url.us.m.mimecastprotect.com/s/HN2_CR6M0Phvz7r2h0Fqf1h6M6?domain=mai... OT-free version of this list: https://url.us.m.mimecastprotect.com/s/1vASCVO5k7sxROlGFrHRfEihfB?domain=mai... Searchable Archive: https://url.us.m.mimecastprotect.com/s/MsT4CW6wlQh5WljJUBIVforh18?domain=lea... This message: https://url.us.m.mimecastprotect.com/s/HCwmCYEQnyCL4G3rhrTPfxJHZG?domain=lea... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Yeah - I'm sure Craig's Class was a lot easier to use than what they have implemented here... ________________________________ From: ProFox profox-bounces@leafe.com on behalf of Richard Kaye rkaye@invaluable.com Sent: Thursday, May 29, 2025 3:40 PM To: profox@leafe.com profox@leafe.com Subject: RE: A Difficult Problem & SAD AI Truth...
+1, Paul 😊
Related sidenote to the topic of all this machine AIing; when I was still doing desktop stuff and using grids I found Craig Boyd's gridesxtras.vcx class to be brilliant.
--
rk From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Paul H. Tarver Sent: Thursday, May 29, 2025 1:05 PM To: profoxtech@leafe.com Subject: RE: A Difficult Problem & SAD AI Truth...
I'm definitely getting old.
Back in my day all we had for AI was the manual, Hentzenwerke books or FoxPro Advisor magazine. However, in those ancient days, AI stood for "Awesome Insights" from a lot of the folks who are still monkeying around with Foxpro. :)
Paul H. Tarver Tarver Program Consultants, Inc.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Kurt Wendt Sent: Thursday, May 29, 2025 11:39 AM To: mailto:profoxtech@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
Hey Ed!
I had not heard of Perplexity before, maybe I should give it a shot.
And, yeah - even Claude has sessions, and I can go into an older session for a followup. So, yup - I get it...
So, in regards to your comment about Training the Model. In one of the very first communications I had with Claude - this was my question: When I upload files to you - are they at all stored on the web? I just want to know how secure things are before I give you more complicated VFP forms that may have proprietary company information within those forms.
And this was his Reply: That's a great question and an important security consideration. When you upload files to me in this chat interface, the files are processed as part of our conversation. They are not publicly stored or accessible on the web in a way that others could find or access them. The files are only used to help me assist you in the current conversation. However, I should clarify a few important points about data handling:
(1) The files and our conversation are processed on Anthropic's servers to enable me to analyze and respond to your requests. (2) Anthropic (the company that created me) does have data retention policies that govern how long conversation data might be stored on their systems, primarily for improving their services. (3) While the files aren't "published" on the web, they are transmitted to Anthropic's systems during our conversation.
For sensitive or proprietary company information, you might want to consider: Removing or anonymizing sensitive portions of code before sharing Using placeholder names for proprietary elements Sharing only representative samples rather than complete production code
If you have specific concerns about confidentiality, you might want to check Anthropic's privacy policy or consider using their API service which might offer different data handling options depending on your agreement with them. Would you like me to help you understand how you might sanitize your VFP forms before sharing them, or would you prefer to proceed with sharing a form now?
****** So, yeah - item (2) had a reference to "primarily for improving their services". But, it's not really clear - I guess I figured improving meant learning - but, I now know it does NOT mean learning.
Got it.
________________________________________ From: ProFox mailto:profox-bounces@leafe.com on behalf of Ed Leafe mailto:ed@leafe.com Sent: Thursday, May 29, 2025 12:19 PM To: ProFox Mailing List mailto:profox@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
On May 29, 2025, at 08:46, Kurt Wendt mailto:kwendt@pakoinc.com wrote:
And THAT is the Crux of why I am making this post. I'm sure others here
already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
What you're describing is training the model, and that happens before the model can be used. Running queries through the model doesn't change it, it just affects the output.
I haven't used Claude, but I am a big fan of Perplexity (https://url.us.m.mimecastprotect.com/s/wWlVCQWN26Hkyz60S9CxfGKV9t?domain=per...), which saves your queries as sessions that you can go back to at a later date. The context is preserved, so if you go back and say something like "that didn't work", it understands to what you are referring, and will respond accordingly.
-- Ed Leafe
_______________________________________________
Post Messages to: mailto:ProFox@leafe.com
Subscription Maintenance: https://url.us.m.mimecastprotect.com/s/HN2_CR6M0Phvz7r2h0Fqf1h6M6?domain=mai...
OT-free version of this list: https://url.us.m.mimecastprotect.com/s/1vASCVO5k7sxROlGFrHRfEihfB?domain=mai...
Searchable Archive: https://url.us.m.mimecastprotect.com/s/MsT4CW6wlQh5WljJUBIVforh18?domain=lea...
This message: https://url.us.m.mimecastprotect.com/s/386TCXD70rIXzpnwcxSwfWL1Jn?domain=lea.... com
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
[excessive quoting removed by server]
_______________________________________________ Post Messages to: mailto:ProFox@leafe.com Subscription Maintenance: https://url.us.m.mimecastprotect.com/s/HN2_CR6M0Phvz7r2h0Fqf1h6M6?domain=mai... OT-free version of this list: https://url.us.m.mimecastprotect.com/s/1vASCVO5k7sxROlGFrHRfEihfB?domain=mai... Searchable Archive: https://url.us.m.mimecastprotect.com/s/MsT4CW6wlQh5WljJUBIVforh18?domain=lea... This message: https://url.us.m.mimecastprotect.com/s/HCwmCYEQnyCL4G3rhrTPfxJHZG?domain=lea... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious. _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/MW4PR10MB6584430DC021C36E2D3B546AD266A@MW4P... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
On May 29, 2025, at 11:39, Kurt Wendt kwendt@pakoinc.com wrote:
So, yeah - item (2) had a reference to "primarily for improving their services". But, it's not really clear - I guess I figured improving meant learning - but, I now know it does NOT mean learning.
Think of it this way: if your interaction could change the underlying model, what is to stop a bad actor from deliberately feeding it incorrect (or dangerous) information?
-- Ed Leafe
Quite right my friend Ed - how true indeed!
Now - since you mentioned Evil Intentions - I really MUST Share this - which a co-worker shared with me: https://www.pcmag.com/news/anthropic-claude-4-ai-might-resort-to-blackmail-i...
Yeah - that makes it almost sound like AI is Alive and does NOT want to be Killed Off. Here's another related article my buddy here sent me: https://www.bleepingcomputer.com/news/artificial-intelligence/researchers-cl...
-K ________________________________________ From: ProFox profox-bounces@leafe.com on behalf of Ed Leafe ed@leafe.com Sent: Thursday, May 29, 2025 5:11 PM To: ProFox Mailing List profox@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
On May 29, 2025, at 11:39, Kurt Wendt kwendt@pakoinc.com wrote:
So, yeah - item (2) had a reference to "primarily for improving their services". But, it's not really clear - I guess I figured improving meant learning - but, I now know it does NOT mean learning.
Think of it this way: if your interaction could change the underlying model, what is to stop a bad actor from deliberately feeding it incorrect (or dangerous) information?
-- Ed Leafe
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message: https://leafe.com/archives/byMID/2A181F0C-1BDD-4A8E-AE9B-A121DBC4FC45@leafe....
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
-
Ed Leafe -
Jeff Roberts -
Kurt Wendt -
Paul H. Tarver -
Richard Kaye -
Tracy Pearson