[IAEP] IAEP Digest, Vol 14, Issue 7

[Jeff Elkner]

One of my students, David Cooper, worked on a Logic circuit simulator last
year using pygame:

http://launchpad.net/graphical-logic-circuits

I asked him to build a graphical tool to use with the logic circuit
simulation code that Chris Meyers did in Python for Fun:

http://openbookproject.net//py4fun/logic/logic.html
http://openbookproject.net//py4fun/logic2/logic2.html

Several years prior, another student, Peter Bui, began a tutorial on logic
circuits:

http://openbookproject.net/tutorials/getdown/logic_circuits

If there is more general interest in working on this, perhaps Sugar Labs DC
could make it a priority?

Thanks!

jeff


On Mon, May 4, 2009 at 4:44 AM, <iaep-request at lists.sugarlabs.org> wrote:

> Send IAEP mailing list submissions to
>        iaep at lists.sugarlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.sugarlabs.org/listinfo/iaep
> or, via email, send a message with subject or body 'help' to
>        iaep-request at lists.sugarlabs.org
>
> You can reach the person managing the list at
>        iaep-owner at lists.sugarlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of IAEP digest..."
>
>
> Today's Topics:
>
>   1. Re: Logic simulator (forster at ozonline.com.au)
>   2. Re: Sugar Digest 2009-05-03 (Maria Droujkova)
>   3. Re: The User experience/interface for Printing (Andr?s Ambrois)
>   4. Re: Logic simulator (Tomeu Vizoso)
>   5. Re: The User experience/interface for Printing (Albert Cahalan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 04 May 2009 08:48:10 +1000
> From: forster at ozonline.com.au
> Subject: Re: [IAEP] Logic simulator
> To: iaep at lists.sugarlabs.org
> Message-ID: <200905032248.n43MmAGN012930 at smtp.ozonline.com.au>
>
> > Noticed this Flash based logic simulator:
> >
> >       http://joshblog.net/projects/logic-gate-simulator/Logicly.html
> >
> > Would be quite a simple sandbox activity to make (python, gtk+,
> > ciaro); but before I burn time (well add to my future todos list), do
> > teachers on this list think it is more than just a geeky play-thing,
> > or does it have educational merit?
>
> Gary, thanks for the link, I love it.
>
> Yes, I think this simulator does have strong educational merit. It is more
> than a digital logic simulator, Boolean logic goes further than teaching
> electronics, it teaches kids to problem solve and to think mathematically.
>
> I tried it out on the XO and it works fine (except for the jumpy cursor
> making wiring tricky)
>
> I would question whether it would be worth remaking in Python, the Flash
> version works well and if internet connectivity was limited, couldn't it
> just run on a school server?
>
> Bill Kerr in his blog, makes the point that the future of educational
> computing is in thin client netbooks with the smarts at the server end. This
> idea is reinforced by list discussions on books and book readers, it makes
> more sense to tap into the world's resources of ebooks than to write books
> specifically for the sugar platform.
>
> Similarly, it makes more sense to tap into the world's resources of
> simulators and puzzles than to rewrite them for the Sugar platform.
>
> If all this is true, then perhaps the focus for Sugar should be on its
> browser and book reader, making it compatible with the widest range of
> ebooks and web based simulations as possible. Walter I think has mentioned
> an unzip activity as a priority, sounds like a good idea, it gives better
> access to the wealth of educational material already out there on the www.
>
> Some more web based simulators, I haven't tried them for Sugar
> compatibility:
>
> http://www.sodaplay.com/constructor/
>
> http://www.biologic.com.au/bugbrain/
>
> http://www.armadillorun.com/
>
> http://www.deviantart.com/deviation/40255643/
>
> http://www.kloonigames.com/crayon/
>
> http://www.acc.umu.se/~emilk/index.html<http://www.acc.umu.se/%7Eemilk/index.html>
>
> http://www.geogebra.org/cms/
>
> http://mathworld.wolfram.com/topics/AnimatedGIFs.html
>
> http://www.fi.uu.nl/wisweb/
>
> Tony
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 3 May 2009 19:11:14 -0400
> From: Maria Droujkova <droujkova at gmail.com>
> Subject: Re: [IAEP] Sugar Digest 2009-05-03
> To: Walter Bender <walter.bender at gmail.com>
> Cc: iaep <iaep at lists.sugarlabs.org>,    Sugar-dev Devel
>        <sugar-devel at lists.sugarlabs.org>,
> community-news at lists.sugarlabs.org
> Message-ID:
>        <a7f443b60905031611r7101f42bo7106cc71f14716f2 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, May 3, 2009 at 6:13 PM, Walter Bender <walter.bender at gmail.com>
> wrote:
> > ===Sugar Digest===
> >
> > I encourage you to join two threads on the Education List this week:
> > http://lists.sugarlabs.org/archive/iaep/2009-April/005382.html, which
> > has boiled down to an instruction vs construction debate; and
> > http://lists.sugarlabs.org/archive/iaep/2009-April/005342.html, which
> > has boiled down to a debate of catering to local culture vs the
> > Enlightenment. I encourage you to join these discussions.
> >
> > Rather than commenting here, I want to discuss a third, orthogonal
> > topic: creativity. I hosted a visit to Cambridge this week from Diego
> > Uribe, a Chilean researcher who is currently a Fulbright scholar at
> > the International Center for Studies in Creativity in Buffalo, NY.
> > Diego challenged me with two questions: Can we be more deliberate in
> > developing children's creativity skills and how can we use Sugar to
> > better disseminate creativity heuristics?
>
> >
> > Guidelines for divergent thinking
> >
> > * defer judgment
> > * go for quantity
> > * make connections
> > * seek novelty
> >
> >
> > Guidelines for convergent thinking
> >
> > * apply affirmative judgment
> > * keep novelty alive
> > * check your objectives
> > * stay focused
> >
>
> Walter,
>
> Thank you very much for this write-up. It is very, very interesting
> and quite helpful! Coincidentally, I am working on a proposal part
> about convergent and divergent actions, as applied to children's
> authoring in mathematics. As an aside, I find that using "creativity"
> or "creating" distracts people into a lot of tangents when I talk
> about math, so unless I have a lot of time to explain contexts, I go
> with "authoring."
>
> Metaphors and example spaces are two relevant parts of my framework
> here. A metaphor can start the divergent part of the cycle, allowing
> kids to quickly generate a number of mathematical objects. Then
> particular questions or goals help kids to sort through their objects,
> noticing properties and observing patterns. These generalities
> (properties and patterns) are convergent, and a pile of objects born
> of a metaphor gets structured into an example space. Now objects
> become examples OF something - namely, of observed generalities. At
> which point kids are tempted to generate more and better examples,
> which is the divergent part of the cycle at a new level, and so on.
>
> In practice, kids need ways to make math objects within a common
> metaphor and to collect, share and re-make those objects. With some
> kids, it's as simple as providing a graffiti wall and a verbal prompt,
> but typically you need heuristics and scaffolds to keep the thing
> going. In software, the challenge is to find a balance between
> providing enough scaffolds, yet leaving enough space for the divergent
> part of the cycle, allowing kids to actually, here goes - create.
>
> --
> Cheers,
> MariaD
>
> Make math your own, to make your own math.
>
> http://www.naturalmath.com social math site
> http://www.phenixsolutions.com empowering our innovations
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 4 May 2009 02:47:16 -0300
> From: Andr?s Ambrois <andresambrois at gmail.com>
> Subject: Re: [IAEP] The User experience/interface for Printing
> To: iaep at lists.sugarlabs.org, sugar-devel at lists.sugarlabs.org
> Cc: Albert Cahalan <acahalan at gmail.com>,        Vamsi Krishna Davuluri
>        <vamsi.davuluri at gmail.com>
> Message-ID: <200905040247.16744.andresambrois at gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sunday 03 May 2009 06:29:26 pm Albert Cahalan wrote:
> > Vamsi Krishna Davuluri writes:
> > > So, talking to Tomeu, we agreed that for Write and Read using
> > > the gtkprint would be best as both support it as a printing API.
> >
> > The focus on "Write and Read" is short sighted and may lead
> > to inflexible solutions.
>
> Read was selected to contain the "send to print" code because Tomeu
> expressed
> some concerns about the maintainability of that code in the Journal. Also,
> we
> agreed that going through read is good for reviewing the pdf output and
> saving
> paper on badly formatted docs.
>
> > > Now, the current plan is:
> > > 1) We do journal printing only, albeit, the respective
> > > activity opens the file.
> >
> > Eh, OK. Provide a script called /usr/bin/lpr which runs ps2pdf
> > or directly runs gs. This lets normal software, which is already
> > designed to output standard Postscript to lpr, work just fine.
> > After conversion, put the PDF into the journal.
> >
> > Better yet, just toss the file into the journal without conversion.
> >
> > BTW, this can also be implemented as a filter script that the
> > normal lpr program invokes for the default printer.
>
> The priority is on sending the docs to cups-pdf for conversion and then
> talking to Moodle for teacher review. It is a good idea to have the code
> that
> sends docs for printing (to Moodle, a local printer, or one discovered by
> avahi) in a reusable module that a /usr/bin/lpr script can use.
>
> > > Now here a cross road is presented:
> > >
> > > 1) Do we use a print dialog inside each activity that can save it as
> pdf,
> > > print or export a pdf to moodle
>
> If we are going to keep everything inside Read for now. It'll be best to
> have
> the print button only in Read. The use case we had discussed was like this:
> open the file in Read, if its not ps/pdf Read converts it using cups-pdf,
> displays it, and then you can use the print button in its toolbar.
>
> The converted file gets added as a journal entry right after conversion.
> The
> datastore already contains code to hard link identical files, so disk space
> usage in multiple conversions is kept to a minimum. Read could add a
> pointer
> to the pdf in the original entry's metadata as well.
>
> Adding a print dialog to every activity (e.g. Adding some gtkprint support
> in
> sugar-toolkit) should be optional for GSoC. First we should concentrate on
> getting entries printed, and getting teacher review right. Then we can move
> code around for legacy support and nice "print me" buttons.
>
> > > 2) Do we use separate buttons for each of these operations?
> > >
> > > What of the user experience?
>
> > Separate buttons provides a distinction that will be important
> > in some environments. Some places will want immediate printing.
> >
> > For now, the "print" button can be almost the same as the other,
> > but with the output PDF marked for near-term deletion.
> >
> > "Make PDF" and "Print now" seem like fine names.
> >
>
> I agree. Just a print button for now. The PDF will be generated on startup
> anyway. We can have the cups-pdf local printer in the printer selection
> dialog
> when we provide other printing methods.
>
> > > The initial plan was to make Read the global printing station,
> > > how do you find this idea?
> >
> > Starting up Read just to print something is not nice. Read may
> > even cause an out-of-memory condition. For sure, there is no need
> > to very slowly render a big document that doesn't even need to be
> > seen on the screen.
>
> This is to encourage review and to keep the code away from the Journal. The
> code can then be moved to Glucose. Also, distributing a modified Read for
> testing will be considerably easier than patching the Journal.
>
> > > the teacher checks his print page in moodle, views the file (either
> > > through fancy javascript or a download) and approves/disapproves
> > > for printing. Kennedy then logs into his moodle print page and
> > > checks if the job was success or not, and if he has a comment from
> > > his teacher.
> >
> > I can barely imagine that happening in a real classroom. Try this:
> >
> > The student brings his XO to the teacher's desk, with his work shown
> > on the screen. The teacher looks at the work, then lets the student
> > plug his XO into a printer which sits on the teacher's desk.
> >
> > > Printing resources can be very expensive for most schools, so
> > > the system should include a way for students to submit jobs to a
> > > queue and for an administrator to preview and approve or denie them.
> >
> > Tux Paint can rate limit a student's printing. For example, a setting
> > of 60 will be once per minute.
> >
> > Do not forget that this issue is more social than technical. In addition
> > to any discipline, the teacher can simply turn off the printer. This is
> > advisable in any case; many printers use excessive power in standby.
>
> I dont see a teacher having a printer on her desk. Most schools here in
> Uruguay (and I dare say in Per?) don't even have printers. If there is one,
> it
> will be where the server/administration is. And possibly locked in a cage
> (like we have the servers now). So that scenario is going to be priority
> one.
>
> Next will be of course provide local printing when a full-blown cups
> installation is present (which we dont want to have as a sugar dependency
> for
> now). As I also see many kids having printers in their homes.
>
> > _______________________________________________
> > IAEP -- It's An Education Project (not a laptop project!)
> > IAEP at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/iaep
>
> --
>  Andr?s
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.sugarlabs.org/archive/iaep/attachments/20090504/308ccc06/attachment-0001.htm
>
> ------------------------------
>
> Message: 4
> Date: Mon, 4 May 2009 10:36:02 +0200
> From: Tomeu Vizoso <tomeu at sugarlabs.org>
> Subject: Re: [IAEP] Logic simulator
> To: Maria Droujkova <droujkova at gmail.com>
> Cc: iaep SugarLabs <iaep at lists.sugarlabs.org>
> Message-ID:
>        <242851610905040136n22c341fdpa264bf0d51163578 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, May 3, 2009 at 23:58, Maria Droujkova <droujkova at gmail.com> wrote:
> > It's a very neat thing. From my point of view, its pedagogical value
> > would very much increase if you could save and share your diagrams. So
> > that one student could build something and give it to others to
> > improve, etc. Or make some classic diagrams, etc.
>
> For any activity that produces diagrams, I recommend looking at Gaphas
> [0]. It's the library used in Gaphor to draw UML diagrams and is very
> flexible.
>
> [0] http://gaphor.devjavu.com/wiki/Subprojects/Gaphas
>
> Regards,
>
> Tomeu
>
> > On Sun, May 3, 2009 at 5:09 PM, Gary C Martin <gary at garycmartin.com>
> wrote:
> >> Noticed this Flash based logic simulator:
> >>
> >> ? ? ? ?http://joshblog.net/projects/logic-gate-simulator/Logicly.html
> >>
> >> Would be quite a simple sandbox activity to make (python, gtk+,
> >> ciaro); but before I burn time (well add to my future todos list), do
> >> teachers on this list think it is more than just a geeky play-thing,
> >> or does it have educational merit?
> >>
> >> FWIW: it could do with a few more input/output and processing devices
> >> (sensors, buzzers, coloured leds, motors, counters). And, hey if time
> >> is no obstacle, perhaps make it a split screen view, holding a physics
> >> sandbox with the logic driving/animating simple little motorised
> >> constructions.
> >>
> >> Regards,
> >> --Gary
> >> _______________________________________________
> >> IAEP -- It's An Education Project (not a laptop project!)
> >> IAEP at lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/iaep
> >>
> >
> >
> >
> > --
> > Cheers,
> > MariaD
> >
> > Make math your own, to make your own math.
> >
> > http://www.naturalmath.com social math site
> > http://www.phenixsolutions.com empowering our innovations
> > _______________________________________________
> > IAEP -- It's An Education Project (not a laptop project!)
> > IAEP at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/iaep
> >
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 4 May 2009 04:44:33 -0400
> From: Albert Cahalan <acahalan at gmail.com>
> Subject: Re: [IAEP] The User experience/interface for Printing
> To: Andr?s Ambrois <andresambrois at gmail.com>
> Cc: iaep at lists.sugarlabs.org, sugar-devel at lists.sugarlabs.org,  Vamsi
>        Krishna Davuluri <vamsi.davuluri at gmail.com>
> Message-ID:
>        <787b0d920905040144t6b427e50x473e4ae723f87aa6 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, May 4, 2009 at 1:47 AM, Andr?s Ambrois <andresambrois at gmail.com>
> wrote:
> > On Sunday 03 May 2009 06:29:26 pm Albert Cahalan wrote:
> >> Vamsi Krishna Davuluri writes:
>
> > The priority is on sending the docs to cups-pdf for conversion and then
> > talking to Moodle for teacher review. It is a good idea to have the code
> > that sends docs for printing (to Moodle, a local printer, or one
> discovered
> > by avahi) in a reusable module that a /usr/bin/lpr script can use.
>
> Sending the docs to cups-pdf for conversion and then talking to Moodle
> for teacher review can be done via /usr/bin/lpr, eliminating the trouble
> of having multiple data paths.
>
> > Adding a print dialog to every activity (e.g. Adding some gtkprint
> support
> > in sugar-toolkit) should be optional for GSoC. First we should
> concentrate
> > on getting entries printed, and getting teacher review right. Then we can
> > move code around for legacy support and nice "print me" buttons.
>
> If you start with what you disdain as "legacy support", then you
> can trivially test "getting entries printed" from the command line.
> The same goes for "getting teacher review right".
>
> You could even test with the TuxPaint activity, using real kids.
>
> >> > the teacher checks his print page in moodle, views the file (either
> >> > through fancy javascript or a download) and approves/disapproves
> >> > for printing. Kennedy then logs into his moodle print page and
> >> > checks if the job was success or not, and if he has a comment from
> >> > his teacher.
> >>
> >> I can barely imagine that happening in a real classroom. Try this:
> >>
> >> The student brings his XO to the teacher's desk, with his work shown
> >> on the screen. The teacher looks at the work, then lets the student
> >> plug his XO into a printer which sits on the teacher's desk.
> >>
> >> > Printing resources can be very expensive for most schools, so
> >> > the system should include a way for students to submit jobs to a
> >> > queue and for an administrator to preview and approve or denie them.
> >>
> >> Tux Paint can rate limit a student's printing. For example, a setting
> >> of 60 will be once per minute.
> >>
> >> Do not forget that this issue is more social than technical. In addition
> >> to any discipline, the teacher can simply turn off the printer. This is
> >> advisable in any case; many printers use excessive power in standby.
> >
> > I dont see a teacher having a printer on her desk. Most schools here in
> > Uruguay (and I dare say in Per?) don't even have printers. If there is
> one,
> > it will be where the server/administration is. And possibly locked in a
> cage
> > (like we have the servers now). So that scenario is going to be priority
> > one.
>
> That sounds like a printer that students aren't allowed to use.
> Such a school might not need printing support at all.
>
> Teachers are unlikely to learn a complicated (probably slow too)
> interface for approving printer use. I just don't see it happening
> with regular normal everyday human teachers.
>
>
> ------------------------------
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
> End of IAEP Digest, Vol 14, Issue 7
> ***********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20090504/a193c787/attachment-0001.htm