Hi,
As some of you may know, I've proposed myself as a student for the "Squeakland Education Project" at this year Google Summer of Code. You can find the project description here: http://gsoc2010.esug.org/projects/squeakland-education.
Even though our project hasn't been accepted yet, I've been working already in one of the items of the proposal: the graphing of data. For that purpose I made a few tools that allow you to draw points and vectors in a cartesian plane using the Etoys scripting system. This is a work in progress and I need to clean a lot of stuff, but I wanted to show you my progress so far. My mentors, Randall and Markus, have helped me a lot to develop this stuff and, as Bert said, it would be good to show this to the entire community.
You can find the source code at squeaksource: http://www.squeaksource.com/GSoCSqueakland.html and some example projects at: http://www.pcs.cnu.edu/~rcaton/ESUG/ESUG.html
I would appreciate any comments or suggestions you may have to improve or extend these projects.
Thanks in advance! Richo
Looks very neat Ricardo. One tip: find quickly a teacher to test in real situation with his/her students. You can get valuable feedback.
Hilaire
Hilaire
2010/4/13 Ricardo Moran richi.moran@gmail.com
Hi,
As some of you may know, I've proposed myself as a student for the "Squeakland Education Project" at this year Google Summer of Code. You can find the project description here: http://gsoc2010.esug.org/projects/squeakland-education.
Even though our project hasn't been accepted yet, I've been working already in one of the items of the proposal: the graphing of data. For that purpose I made a few tools that allow you to draw points and vectors in a cartesian plane using the Etoys scripting system. This is a work in progress and I need to clean a lot of stuff, but I wanted to show you my progress so far. My mentors, Randall and Markus, have helped me a lot to develop this stuff and, as Bert said, it would be good to show this to the entire community.
You can find the source code at squeaksource: http://www.squeaksource.com/GSoCSqueakland.html and some example projects at: http://www.pcs.cnu.edu/~rcaton/ESUG/ESUG.htmlhttp://www.pcs.cnu.edu/%7Ercaton/ESUG/ESUG.html
I would appreciate any comments or suggestions you may have to improve or extend these projects.
Thanks in advance! Richo
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Thanks Hilaire! It would be great if we had a teacher testing our tools with his students. Now that they're public it is posible that some teacher could find them interesting :)
I must admit I'm very embarrased of not having looked at Dr. Geo until now (even though Markus told me to do it when we started this project... I should have listened to him). Anyway, what you did is amazing! Truly amazing! The thing that most embarrases me is that every geometric object in Dr. Geo is a separate morph (vectors, points, segments, and so on). This is so obvious I feel like an idiot, but I did it the other way: I made only one morph and I change its #drawOn: method. As a result it is somewhat difficult to change the atributes of a specific vector without affecting others. I will now have to fix my implementation because I didn't look at yours before :P
Richo
On Wed, Apr 14, 2010 at 2:45 AM, Hilaire Fernandes < hilaire.fernandes@edu.ge.ch> wrote:
Looks very neat Ricardo. One tip: find quickly a teacher to test in real situation with his/her students. You can get valuable feedback.
Hilaire
Hilaire
2010/4/13 Ricardo Moran richi.moran@gmail.com
Hi,
As some of you may know, I've proposed myself as a student for the "Squeakland Education Project" at this year Google Summer of Code. You can find the project description here: http://gsoc2010.esug.org/projects/squeakland-education.
Even though our project hasn't been accepted yet, I've been working already in one of the items of the proposal: the graphing of data. For that purpose I made a few tools that allow you to draw points and vectors in a cartesian plane using the Etoys scripting system. This is a work in progress and I need to clean a lot of stuff, but I wanted to show you my progress so far. My mentors, Randall and Markus, have helped me a lot to develop this stuff and, as Bert said, it would be good to show this to the entire community.
You can find the source code at squeaksource: http://www.squeaksource.com/GSoCSqueakland.html and some example projects at: http://www.pcs.cnu.edu/~rcaton/ESUG/ESUG.htmlhttp://www.pcs.cnu.edu/%7Ercaton/ESUG/ESUG.html
I would appreciate any comments or suggestions you may have to improve or extend these projects.
Thanks in advance! Richo
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
2010/4/15 Ricardo Moran richi.moran@gmail.com
Thanks Hilaire! It would be great if we had a teacher testing our tools with his students. Now that they're public it is posible that some teacher could find them interesting :)
I must admit I'm very embarrased of not having looked at Dr. Geo until now (even though Markus told me to do it when we started this project... I should have listened to him).
Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible to link plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo is the used tool. Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.
Anyway, what you did is amazing! Truly amazing! The thing that most embarrases me is that every geometric object in Dr. Geo is a separate morph (vectors, points, segments, and so on). This is so obvious I feel like an idiot, but I did it the other way: I made only one morph and I change its #drawOn: method. As a result it is somewhat difficult to change the atributes of a specific vector without affecting others. I will now have to fix my implementation because I didn't look at yours before :P
Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost free bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of CPU consumption. (in fact, I do have an additional level of abstraction with costume because at the time of implementation I was not sure about using Morphic or Tweak based canevas, but I will refactor that and remove this level)
Hilaire
Yes, they are different and also the scope of these tools is much more limited than Dr. Geo. Dr. Geo is a big project and I would like to take it's implementation as an example to develop my stuff, if that's okay with you. I also like the way Dr. Geo uses the WheelMorph, I may borrow it :)
Richo.
PD: The example you have there it's very cool! It's not easy to reproduce though.
On Thu, Apr 15, 2010 at 2:30 AM, Hilaire Fernandes < hilaire.fernandes@edu.ge.ch> wrote:
2010/4/15 Ricardo Moran richi.moran@gmail.com
Thanks Hilaire! It would be great if we had a teacher testing our tools
with his students. Now that they're public it is posible that some teacher could find them interesting :)
I must admit I'm very embarrased of not having looked at Dr. Geo until now (even though Markus told me to do it when we started this project... I should have listened to him).
Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible to link plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo is the used tool. Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.
Anyway, what you did is amazing! Truly amazing! The thing that most embarrases me is that every geometric object in Dr. Geo is a separate morph (vectors, points, segments, and so on). This is so obvious I feel like an idiot, but I did it the other way: I made only one morph and I change its #drawOn: method. As a result it is somewhat difficult to change the atributes of a specific vector without affecting others. I will now have to fix my implementation because I didn't look at yours before :P
Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost free bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of CPU consumption. (in fact, I do have an additional level of abstraction with costume because at the time of implementation I was not sure about using Morphic or Tweak based canevas, but I will refactor that and remove this level)
Hilaire
On Fri, Apr 16, 2010 at 10:24 PM, Ricardo Moran richi.moran@gmail.com wrote:
Yes, they are different and also the scope of these tools is much more limited than Dr. Geo. Dr. Geo is a big project and I would like to take it's implementation as an example to develop my stuff, if that's okay with you. I also like the way Dr. Geo uses the WheelMorph, I may borrow it :) Richo. PD: The example you have there it's very cool! It's not easy to reproduce though.
I wonder why you don't use PolygonMorph for vectors ?
Karl
On Thu, Apr 15, 2010 at 2:30 AM, Hilaire Fernandes hilaire.fernandes@edu.ge.ch wrote:
2010/4/15 Ricardo Moran richi.moran@gmail.com
Thanks Hilaire! It would be great if we had a teacher testing our tools with his students. Now that they're public it is posible that some teacher could find them interesting :) I must admit I'm very embarrased of not having looked at Dr. Geo until now (even though Markus told me to do it when we started this project... I should have listened to him).
Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible to link plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo is the used tool. Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.
Anyway, what you did is amazing! Truly amazing! The thing that most embarrases me is that every geometric object in Dr. Geo is a separate morph (vectors, points, segments, and so on). This is so obvious I feel like an idiot, but I did it the other way: I made only one morph and I change its #drawOn: method. As a result it is somewhat difficult to change the atributes of a specific vector without affecting others. I will now have to fix my implementation because I didn't look at yours before :P
Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost free bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of CPU consumption. (in fact, I do have an additional level of abstraction with costume because at the time of implementation I was not sure about using Morphic or Tweak based canevas, but I will refactor that and remove this level)
Hilaire
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Because I'm dumb :) No, actually, I started modifying the #drawOn: method to draw the grid, the axis, and all the background. It seemed to me like the right way to do it. Then I realized my code wasn't efficient enough so I move the drawing into a separate form and I redraw it only when it was necessary. This worked nice and I started to draw the data the same way. I didn't see the problem until I made the vector stuff. Anyway, this is fixed now. I tried uploading the project example to squeakland showcase but when I tried to login from etoys it throw me an error. I guess I'll try again later.
On Fri, Apr 16, 2010 at 6:28 PM, karl ramberg karlramberg@gmail.com wrote:
On Fri, Apr 16, 2010 at 10:24 PM, Ricardo Moran richi.moran@gmail.com wrote:
Yes, they are different and also the scope of these tools is much more limited than Dr. Geo. Dr. Geo is a big project and I would like to take it's implementation as
an
example to develop my stuff, if that's okay with you. I also like the way Dr. Geo uses the WheelMorph, I may borrow it :) Richo. PD: The example you have there it's very cool! It's not easy to reproduce though.
I wonder why you don't use PolygonMorph for vectors ?
Karl
On Thu, Apr 15, 2010 at 2:30 AM, Hilaire Fernandes hilaire.fernandes@edu.ge.ch wrote:
2010/4/15 Ricardo Moran richi.moran@gmail.com
Thanks Hilaire! It would be great if we had a teacher testing our tools with his students. Now that they're public it is posible that some
teacher
could find them interesting :) I must admit I'm very embarrased of not having looked at Dr. Geo until now (even though Markus told me to do it when we started this
project... I
should have listened to him).
Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible to
link
plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo is
the
used tool. Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.
Anyway, what you did is amazing! Truly amazing! The thing that most embarrases me is that every geometric object in Dr. Geo is a separate morph (vectors, points, segments, and so on). This is
so
obvious I feel like an idiot, but I did it the other way: I made only
one
morph and I change its #drawOn: method. As a result it is somewhat
difficult
to change the atributes of a specific vector without affecting others.
I
will now have to fix my implementation because I didn't look at yours
before
:P
Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost free bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of CPU consumption. (in fact, I do have an additional level of abstraction with costume because at the time of implementation I was not sure about using Morphic or Tweak based canevas, but I will refactor that and remove this level)
Hilaire
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
I think the projects I submited to the showcase can now be seen at: http://squeakland.org/showcase/project.jsp?id=9781 and http://squeakland.org/showcase/project.jsp?id=9782
On Sat, Apr 17, 2010 at 1:08 PM, Ricardo Moran richi.moran@gmail.comwrote:
Because I'm dumb :) No, actually, I started modifying the #drawOn: method to draw the grid, the axis, and all the background. It seemed to me like the right way to do it. Then I realized my code wasn't efficient enough so I move the drawing into a separate form and I redraw it only when it was necessary. This worked nice and I started to draw the data the same way. I didn't see the problem until I made the vector stuff. Anyway, this is fixed now. I tried uploading the project example to squeakland showcase but when I tried to login from etoys it throw me an error. I guess I'll try again later.
On Fri, Apr 16, 2010 at 6:28 PM, karl ramberg karlramberg@gmail.comwrote:
On Fri, Apr 16, 2010 at 10:24 PM, Ricardo Moran richi.moran@gmail.com wrote:
Yes, they are different and also the scope of these tools is much more limited than Dr. Geo. Dr. Geo is a big project and I would like to take it's implementation as
an
example to develop my stuff, if that's okay with you. I also like the
way
Dr. Geo uses the WheelMorph, I may borrow it :) Richo. PD: The example you have there it's very cool! It's not easy to
reproduce
though.
I wonder why you don't use PolygonMorph for vectors ?
Karl
On Thu, Apr 15, 2010 at 2:30 AM, Hilaire Fernandes hilaire.fernandes@edu.ge.ch wrote:
2010/4/15 Ricardo Moran richi.moran@gmail.com
Thanks Hilaire! It would be great if we had a teacher testing our
tools
with his students. Now that they're public it is posible that some
teacher
could find them interesting :) I must admit I'm very embarrased of not having looked at Dr. Geo until now (even though Markus told me to do it when we started this
project... I
should have listened to him).
Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible to
link
plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo is
the
used tool. Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.
Anyway, what you did is amazing! Truly amazing! The thing that most embarrases me is that every geometric object in
Dr.
Geo is a separate morph (vectors, points, segments, and so on). This
is so
obvious I feel like an idiot, but I did it the other way: I made only
one
morph and I change its #drawOn: method. As a result it is somewhat
difficult
to change the atributes of a specific vector without affecting others.
I
will now have to fix my implementation because I didn't look at yours
before
:P
Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost
free
bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of CPU consumption. (in fact, I do have an additional level of abstraction
with
costume because at the time of implementation I was not sure about
using
Morphic or Tweak based canevas, but I will refactor that and remove
this
level)
Hilaire
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Sat, Apr 17, 2010 at 7:09 PM, Ricardo Moran richi.moran@gmail.com wrote:
I think the projects I submited to the showcase can now be seen at: http://squeakland.org/showcase/project.jsp?id=9781%C2%A0and http://squeakland.org/showcase/project.jsp?id=9782
I think id=9782 is private, I can't access it .
The first one works great. I have to play with a little more before I can give more feedback.
Karl
On Sat, Apr 17, 2010 at 1:08 PM, Ricardo Moran richi.moran@gmail.com wrote:
Because I'm dumb :) No, actually, I started modifying the #drawOn: method to draw the grid, the axis, and all the background. It seemed to me like the right way to do it. Then I realized my code wasn't efficient enough so I move the drawing into a separate form and I redraw it only when it was necessary. This worked nice and I started to draw the data the same way. I didn't see the problem until I made the vector stuff. Anyway, this is fixed now. I tried uploading the project example to squeakland showcase but when I tried to login from etoys it throw me an error. I guess I'll try again later.
On Fri, Apr 16, 2010 at 6:28 PM, karl ramberg karlramberg@gmail.com wrote:
On Fri, Apr 16, 2010 at 10:24 PM, Ricardo Moran richi.moran@gmail.com wrote:
Yes, they are different and also the scope of these tools is much more limited than Dr. Geo. Dr. Geo is a big project and I would like to take it's implementation as an example to develop my stuff, if that's okay with you. I also like the way Dr. Geo uses the WheelMorph, I may borrow it :) Richo. PD: The example you have there it's very cool! It's not easy to reproduce though.
I wonder why you don't use PolygonMorph for vectors ?
Karl
On Thu, Apr 15, 2010 at 2:30 AM, Hilaire Fernandes hilaire.fernandes@edu.ge.ch wrote:
2010/4/15 Ricardo Moran richi.moran@gmail.com
Thanks Hilaire! It would be great if we had a teacher testing our tools with his students. Now that they're public it is posible that some teacher could find them interesting :) I must admit I'm very embarrased of not having looked at Dr. Geo until now (even though Markus told me to do it when we started this project... I should have listened to him).
Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible to link plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo is the used tool. Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.
Anyway, what you did is amazing! Truly amazing! The thing that most embarrases me is that every geometric object in Dr. Geo is a separate morph (vectors, points, segments, and so on). This is so obvious I feel like an idiot, but I did it the other way: I made only one morph and I change its #drawOn: method. As a result it is somewhat difficult to change the atributes of a specific vector without affecting others. I will now have to fix my implementation because I didn't look at yours before :P
Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost free bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of CPU consumption. (in fact, I do have an additional level of abstraction with costume because at the time of implementation I was not sure about using Morphic or Tweak based canevas, but I will refactor that and remove this level)
Hilaire
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Am 17.04.2010 um 19:17 schrieb karl ramberg:
On Sat, Apr 17, 2010 at 7:09 PM, Ricardo Moran richi.moran@gmail.com wrote:
I think the projects I submited to the showcase can now be seen at: http://squeakland.org/showcase/project.jsp?id=9781 and http://squeakland.org/showcase/project.jsp?id=9782
I think id=9782 is private, I can't access it .
It should work now.
Rita
The first one works great. I have to play with a little more before I can give more feedback.
Karl
On Sat, Apr 17, 2010 at 1:08 PM, Ricardo Moran richi.moran@gmail.com wrote:
Because I'm dumb :) No, actually, I started modifying the #drawOn: method to draw the grid, the axis, and all the background. It seemed to me like the right way to do it. Then I realized my code wasn't efficient enough so I move the drawing into a separate form and I redraw it only when it was necessary. This worked nice and I started to draw the data the same way. I didn't see the problem until I made the vector stuff. Anyway, this is fixed now. I tried uploading the project example to squeakland showcase but when I tried to login from etoys it throw me an error. I guess I'll try again later.
On Fri, Apr 16, 2010 at 6:28 PM, karl ramberg karlramberg@gmail.com wrote:
On Fri, Apr 16, 2010 at 10:24 PM, Ricardo Moran <richi.moran@gmail.com
wrote:
Yes, they are different and also the scope of these tools is much more limited than Dr. Geo. Dr. Geo is a big project and I would like to take it's implementation as an example to develop my stuff, if that's okay with you. I also like the way Dr. Geo uses the WheelMorph, I may borrow it :) Richo. PD: The example you have there it's very cool! It's not easy to reproduce though.
I wonder why you don't use PolygonMorph for vectors ?
Karl
On Thu, Apr 15, 2010 at 2:30 AM, Hilaire Fernandes hilaire.fernandes@edu.ge.ch wrote:
2010/4/15 Ricardo Moran richi.moran@gmail.com > > Thanks Hilaire! It would be great if we had a teacher testing > our > tools > with his students. Now that they're public it is posible that > some > teacher > could find them interesting :) > I must admit I'm very embarrased of not having looked at Dr. Geo > until > now (even though Markus told me to do it when we started this > project... I > should have listened to him).
Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible to link plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo is the used tool. Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.
> > Anyway, what you did is amazing! Truly amazing! > The thing that most embarrases me is that every geometric > object in > Dr. > Geo is a separate morph (vectors, points, segments, and so > on). This > is so > obvious I feel like an idiot, but I did it the other way: I > made only > one > morph and I change its #drawOn: method. As a result it is > somewhat > difficult > to change the atributes of a specific vector without affecting > others. I > will now have to fix my implementation because I didn't look > at yours > before > :P
Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost free bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of CPU consumption. (in fact, I do have an additional level of abstraction with costume because at the time of implementation I was not sure about using Morphic or Tweak based canevas, but I will refactor that and remove this level)
Hilaire
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Rita Freudenberg rita@isg.cs.uni-magdeburg.de
I think it's public now. Thanks!
On Sat, Apr 17, 2010 at 2:17 PM, karl ramberg karlramberg@gmail.com wrote:
On Sat, Apr 17, 2010 at 7:09 PM, Ricardo Moran richi.moran@gmail.com wrote:
I think the projects I submited to the showcase can now be seen at: http://squeakland.org/showcase/project.jsp?id=9781 and http://squeakland.org/showcase/project.jsp?id=9782
I think id=9782 is private, I can't access it .
The first one works great. I have to play with a little more before I can give more feedback.
Karl
On Sat, Apr 17, 2010 at 1:08 PM, Ricardo Moran richi.moran@gmail.com wrote:
Because I'm dumb :) No, actually, I started modifying the #drawOn: method to draw the grid, the axis, and all the background. It seemed to me like the right way to
do
it. Then I realized my code wasn't efficient enough so I move the
drawing
into a separate form and I redraw it only when it was necessary. This
worked
nice and I started to draw the data the same way. I didn't see the
problem
until I made the vector stuff. Anyway, this is fixed now. I tried uploading the project example to squeakland showcase but when I tried to login from etoys it throw me an error. I guess I'll try again later.
On Fri, Apr 16, 2010 at 6:28 PM, karl ramberg karlramberg@gmail.com wrote:
On Fri, Apr 16, 2010 at 10:24 PM, Ricardo Moran <richi.moran@gmail.com
wrote:
Yes, they are different and also the scope of these tools is much
more
limited than Dr. Geo. Dr. Geo is a big project and I would like to take it's implementation as an example to develop my stuff, if that's okay with you. I also like the way Dr. Geo uses the WheelMorph, I may borrow it :) Richo. PD: The example you have there it's very cool! It's not easy to reproduce though.
I wonder why you don't use PolygonMorph for vectors ?
Karl
On Thu, Apr 15, 2010 at 2:30 AM, Hilaire Fernandes hilaire.fernandes@edu.ge.ch wrote:
2010/4/15 Ricardo Moran richi.moran@gmail.com > > Thanks Hilaire! It would be great if we had a teacher testing our > tools > with his students. Now that they're public it is posible that some > teacher > could find them interesting :) > I must admit I'm very embarrased of not having looked at Dr. Geo > until > now (even though Markus told me to do it when we started this > project... I > should have listened to him).
Dont' worry about that, these two projects are different enought to justify different code base. However it is true it is very possible
to
link plotting and interactive geometry canvas. Several interactive geometric software out there do that. In that case, the locus object of DrGeo
is
the used tool. Btw, have you looked at this example for plotting and tangente http://blog.ofset.org/hilaire/index.php?post/script-drgeo (english translation link in a comment at the end of the article), it use the Smalltalk User scripting facility of DrGeo.
> > Anyway, what you did is amazing! Truly amazing! > The thing that most embarrases me is that every geometric object in > Dr. > Geo is a separate morph (vectors, points, segments, and so on).
This
> is so > obvious I feel like an idiot, but I did it the other way: I made
only
> one > morph and I change its #drawOn: method. As a result it is somewhat > difficult > to change the atributes of a specific vector without affecting > others. I > will now have to fix my implementation because I didn't look at
yours
> before > :P
Yes, implementation was carefully thought to follow accutely the object paradigm: having each geometric object to be a morph give an almost free bosus: Etoys scripting. This is what lead to this choice and not the drawOn:. In the other hand, drawnOn: should be cheaper in term of
CPU
consumption. (in fact, I do have an additional level of abstraction with costume because at the time of implementation I was not sure about using Morphic or Tweak based canevas, but I will refactor that and remove this level)
Hilaire
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Sat, Apr 17, 2010 at 6:08 PM, Ricardo Moran richi.moran@gmail.com wrote:
Because I'm dumb :)
No way ;-)
No, actually, I started modifying the #drawOn: method to draw the grid, the axis, and all the background. It seemed to me like the right way to do it. Then I realized my code wasn't efficient enough so I move the drawing into a separate form and I redraw it only when it was necessary. This worked nice and I started to draw the data the same way. I didn't see the problem until I made the vector stuff. Anyway, this is fixed now.
Well, I though it would make sense to use PolygonMorphs. But I thought you maybe had a reson not to use them :-)
Both project work now
karl
If using #drawOn:, not using PolymorphMorph could make sense: just to be at at one lower level of abstraction of Morph, thus lighter. This is what I will do in that case.
Hilaire
2010/4/17 karl ramberg karlramberg@gmail.com
Well, I though it would make sense to use PolygonMorphs. But I thought you maybe had a reson not to use them :-)
2010/4/16 Ricardo Moran richi.moran@gmail.com
Yes, they are different and also the scope of these tools is much more limited than Dr. Geo. Dr. Geo is a big project and I would like to take it's implementation as an example to develop my stuff, if that's okay with you. I also like the way Dr. Geo uses the WheelMorph, I may borrow it :)
Please learn from it and borrow what you want.
PD: The example you have there it's very cool! It's not easy to reproduce though.
It is hower Etoys project saveable. I am not sure I have one such project of it though
Hilaire
etoys-dev@lists.squeakfoundation.org
-
Hilaire Fernandes -
karl ramberg -
Ricardo Moran -
Rita Freudenberg