[etoys-dev] GSoC - Progress on the graphing tools

Ricardo Moran richi.moran at gmail.com
Sat Apr 17 13:23:08 EDT 2010


I think it's public now. Thanks!

On Sat, Apr 17, 2010 at 2:17 PM, karl ramberg <karlramberg at gmail.com> wrote:

> On Sat, Apr 17, 2010 at 7:09 PM, Ricardo Moran <richi.moran at 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 at 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 at gmail.com>
> >> wrote:
> >>>
> >>> On Fri, Apr 16, 2010 at 10:24 PM, Ricardo Moran <richi.moran at 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 at edu.ge.ch> wrote:
> >>> >>
> >>> >>
> >>> >> 2010/4/15 Ricardo Moran <richi.moran at 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 at squeakland.org
> >>> > http://lists.squeakland.org/mailman/listinfo/etoys-dev
> >>> >
> >>> >
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100417/aff3eeed/attachment.html


More information about the etoys-dev mailing list