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

Rita Freudenberg rita at isg.cs.uni-magdeburg.de
Sat Apr 17 13:22:05 EDT 2010


Am 17.04.2010 um 19:17 schrieb karl ramberg:

> 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 .

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 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
>>>>>
>>>>>
>>>
>>
>>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>

Rita Freudenberg
rita at isg.cs.uni-magdeburg.de





More information about the etoys-dev mailing list