Hi,
I uploaded to the inbox a version of Skeleton with a few changes of mine that allows you to use a spreadsheet just as you would use mine to import/export data and iterate over its contents.
I also commited a version of the CSV package, which I use to do the importing. However, I didn't remember to look at the license of the package before clicking commit and now that I did, I see it doesn't specify MIT, so I'll ask the author about it (please forgive me and remove the commit if it can be a problem).
Anyway, if you can please tell me what you think.
Cheers, Richo
On Tue, Oct 11, 2011 at 7:28 PM, karl ramberg karlramberg@gmail.com wrote:
On Tue, Oct 11, 2011 at 6:59 PM, Randy Caton rcaton@cnu.edu wrote:
I like the spreadsheet that Ricardo created because it is simple and
basic
and allows I/O. It leaves more for learners to create. Couldn't the functions already in etoys be used in the cells? Does Skeleton allow
plots?
If so, then what about Ricardo's graphs? I'd like to see them in etoys also. Randy
Hi I think it is possible to make all these graphs out of skeleton. From what I see is Skeleton a extension to the way we script and visualize in Etoys, It seems to have a thought out model.
Only working with it and managing the code will tell if it something we find useful and worth while.
Karl
Randall Caton 41596 Bald Eagle Drive Bigfork, MN 56628 218-832-3490 http://www.pcs.cnu.edu/~rcaton Sent from my iPhone On Oct 11, 2011, at 11:41 AM, Ricardo Moran richi.moran@gmail.com
wrote:
On Tue, Oct 11, 2011 at 11:20 AM, Bert Freudenberg <bert@freudenbergs.de
wrote:
On 11.10.2011, at 14:34, Ricardo Moran wrote:
Hi,
The squeak list is currently discussing about a spreadsheet morph, and that just reminded me about how cool is Skeleton actually. So I'm
wondering
why it is not in Etoys? I found an old discussion stating that it
could be a
nice extension to Etoys but the biggest issue being the slow loading
of
external code. I have to agree with that being a problem but I think
we
might reconsider just include it in the image as with Dr Geo.
I know we already have a bloated image full of half finished projects but from what I briefly tested Skeleton seems to work out of the box.
And it
doesn't add a *huge* amount of new code. See this simple comparison
with
DrGeo:
(PackageInfo named: 'Skeleton') systemCategories size. 2 (PackageInfo named: 'Skeleton') classes size. 38 (PackageInfo named: 'Skeleton') methods size. 654 (PackageInfo named: 'Skeleton') linesOfCode. 4765
(PackageInfo named: 'DrGeoII') systemCategories size. 10 (PackageInfo named: 'DrGeoII') classes size. 214 (PackageInfo named: 'DrGeoII') methods size. 1863 (PackageInfo named: 'DrGeoII') linesOfCode. 17154
Another issue, I guess, is that if Skeleton gets included someone will have to maintain it, but from what I've seen the latest version dates
from
2006 and it still works today. So maybe it won't be that big of an
issue.
Anyway, if you want to test it: http://www.languagegame.org:8080/ggame/11.
Cheers, Richo
How does it compare to the data table thing you did in your GSoC
project?
My data table serves the only purpose of importing/exporting CSV files,
but
not much else, whereas Skeleton is a proper spreadsheet, it supports functions, and is well integrated with etoys via drag and drop of tiles.
Would be nice to have only one, not two table-like objects.
I agree, but since my table is not integrated anyway, I vote for
integrating
Skeleton which is much better than what I did. And if we want the I/O of
csv
files, I could find the way of adapting Skeleton. It shouldn't be that difficult, I suppose. Cheers, Richo
- Bert -
squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev