Talk:Old Develop activity

Feedback on Translation of keywords

There is a drawback if keywords are translated to one's native language. People will want to share code snippets. Although translation is feasible in the IDE, it is not obvious online. Using custom translations are even more of an issue. The IDE could translate the snipped based on its original language but this would require extra effort by the user.

There are much less keywords than methods provided by the standard libraries. If people need to learn the meaning of 'httplib' etc., then learning the meaning of 'string' and 'if' is not much more extra effort. How many native English speaking people automatically associate the word 'string' to a bunch of characters? ;-)

I think learning some keywords initially is more valuable in the long term. Multi/dynamic language comments on the other hand is beneficial, especially in example code etc.

--WeBToR 05:10, 20 December 2006 (EST);

Translation is not just a find-and-replace activity. Many concepts do not translate into a concise word that fits into the target grammar. Traditional programming languages are a sub-set of tailored english, while retaining some sort of 'natural' association to the english language as a whole. It's rarely the case in other languages. IT generates new words or meanings in english that rarely translate in a natural way—believe me.

Unfortunately I don't have much to propose... both alternatives (meaningless regurgitation of tokens or misfit translations) are things to avoid... There must be some other way, alternative or solution... which? can't say... we should probably step out the box and ask a kid.. :) --Xavi 21:42, 29 December 2006 (EST)

WeBToR is right - sharing 'meaningless' tokens with people who speak any language at all is extremely useful. However, once you get into descriptions of how things work -- manuals, mouseover text, &c -- it makes sense to have. As for avoiding misfits -- once a few native language speakers from a new language start using the system, they will update the decriptions appropriately (not just in a find-and-replace way). Sj talk

I have to differ. Many kids will learn Python without learning English; but many others will be put off by something obviously foreign. Even if you literally translated the word "string" (and by the way, that would mean a different word here in Guatemala than in neighboring Mexico, even though they're both Spanish... so I should say, even if you translated it once per language, for Spanish lets take the worst case which would be Castilian) that would be more welcoming to the kids, and I would bet that it would have measurable effects in terms of adoption of programming. Homunq 17:41, 28 July 2007 (EDT)

ps. But "string" is not a keyword in python anyway, and I really can't quibble with __str().

Version Control

Hey, someone by the name of jpritikin changed the section about the vcs system, and I'd just like to clarify things a bit for him: originally, I actually intended to use git. It was actually Ivan (neuralis) who convinced me to consider bazaar instead thanks to the fact that it has python bindings (it *is* python), and thus wouldn't require me to fork git for every vcs operation. -- Andrew Clunis Orospakr

Forking is better. This isn't Windows or VMS or even Solaris. Forking is cheap. Forking protects you from many types of crashes and leaks... and no, Python is not immune to such problems. (garbage collectors fail if you have a forgotten reference to something) Forking gets you concurrency without the complexity of threading, which Python handles very poorly in any case. Concurrency is of value on any system because the OS can keep the GUI responsive while work goes on in the background. This is even without SMP or a normal disk; with those the concurrency matters a great deal more. Future generations (years from now) of the OLPC XO are likely to be SMP because that costs less power than increasing clock speed. AlbertCahalan 16:45, 25 February 2007 (EST)

Useful for non-XO developers, too

I'd just like to point out that this project would also be useful for people who do not have XO machines but would like to contribute to the OLPC project. It's currently much easier to run an OLPC image in an emulator than it is to set up a Sugar build environment. So having an emulator image with the Develop activity would make it easier for more people to contribute new activities (less to download, set up, etc.), even if they are not a target student or teacher. —Leejc 15:27, 15 February 2007 (EST)

I'd like to 2nd the idea of either a Sugar image with Develop built-in or at least git utilities included such that Develop could be easily added to a running image.

I would also like to identify that Eclipse already has a Python plugin called PyDev which might make for another place for non-XO device owners to build activities for Sugar besides Develop. Don't get me wrong, I believe that Sugar needs an activity for developing activities but I also believe that we should leverage existing development tools outside of Sugar when they provide a rich development environment. Having recently seen Adobe's Flex2 Builder plugin for Eclipse, and other Eclipse plugins, I believe that a Sugar plugin would be of great value. Much of the initial project creation and packaging overhead could be automated and the posibility of a design/GUI-builder is there too( as in the Flex Builder ). —dlarue 15:51 28 April 2007 (PST)

must use UUID

You need to be using a UUID to identify versions. Much terrible badness can happen if you don't. Git does OK, with a moderately secure hash to protect against most troublemakers. Bzr is weak. Ideally you'd use a secure 256-bit hash.

This hits app bundles as well. Apps need to be installed by UUID, so that two apps can have the exact same name. Though slightly confusing, it'll be far less bad than arbitrarily renaming, overwriting, or blocking. Users can tolerate "the Tam Tam on the left" and "the extra Tam Tam over there" if icons dont move around needlessly.

AlbertCahalan 16:57, 25 February 2007 (EST)

other (programming) languages

Suppose the view-source button is used during boot-up. As appropriate, the OpenFirmware or LinuxBIOS source should be loaded up in the editor. These are not written in Python. It is particularly important to handle C, sh, and make. For example, Tux Paint is in C and make. It would also be good to handle Java, JavaScript, and C++. AlbertCahalan 17:06, 25 February 2007 (EST)

Since Ruby (and notably Ruby on Rails) is becoming very popular on the web and has the (from an XO point of view) added benefit of having a syntax somewhat similar to Python, it couldn't be a bad idea to add support for that as well. RoR is quickly becoming a de-facto standard of creating solid web-apps, and I could imagine a great deal of good coming from the new breed of children-hackers. OskarLissheim-Boethius 21:34, 3 March 2007 (CET)

Hackety Hack seems worth watching. 'Make hacking easy again, like in C64 days'. Just starting; ruby; Windows-only so far :(; real apps in a paragraph; includes lessons; attempting high availability (Wii, etc). Hackety Hack Wiki; hacketyhack.net; Talkety Talk forums.

Abiword gadget?

What if somebody tries to do formatting on source code, or include an image? Homunq 15:04, 29 July 2007 (EDT)

using part of abiword does seem a little OTT since all you really need is colouring and possibly bold - no need for variable width characters, different fonts, images, embedded objects, central or justifyed, paragraph spacing or 101 other things it's probably got - seems to me using it would just bloat things unnecessaraly.Hello1024 18:39, 9 August 2007 (EDT)

Well, "bloat" is not exactly the word, since it's in the OS already - but I agree with the point. Homunq 20:10, 9 August 2007 (EDT)

Status Update?

Hey gang, So, what's the status of the Develop activity? It would be great if this article made that clear... the paragraphs at the top of the article use the present tense, "IS" when describing what Develop will do, but the rest of the article makes it sound like this is something that isn't quite available yet or part of the project yet. It appears that the most recent comments surrounding whether or not Develop is in the image were posted in August. Will I be able to easily install and use "beta" Develop when I (theoretically) get my XO next week? Or will it come pre-installed, somehow? I am planning to use the XO to learn Python, a return to programming after many years hiatus. I've seen a couple of early guides to setting up the directories and creating a new activity, but the Develop activity looks like it would make all of that MUCH easier. --Beagley 10:19, 5 December 2007 (EST)

Current status (Dec 2007): Dormant. I hope to work on this in January, it will be my top priority, and I hope to have something bare-bones but real-world-usable by February. Currently, there is Pippy, which lets you play with python, but it has no support for creating importable libraries, so you can't go much beyond toys. Homunq 21:19, 5 December 2007 (EST)

Okay, so my best option, for now, might be to spend some time LEARNING python with Pippy and on my own elsewhere, and then learning to port/wrap my python code into an XO activity? (I am new to this vocabulary, tell me if I misspeak!) I would welcome advice on resources for doing this... the Python article in this Wiki has some good leads, but I can't find a good, up-to-date tutorial for taking python code and compiling it/getting it to work on an XO and making it easily accessible from Sugar. Your thoughts? --Beagley 17:35, 6 December 2007 (EST)

absolutely. Develop itself would be a bit high-level for a first intro to python as well as activity-creation. Sj talk 17:41, 6 December 2007 (EST)

I'd love to get cracking on Develop after Christmas. I think it would be too useful a thing to not have on the XO (for anyone interested in development). Python's new to me but I don't think I'll have a hard time picking it up. --Bengl 16:49, 22 December 2007 (EST)

It's clearly not that important. Proof: none of the existing code was developed with it. (not even sugar, definitely not the underlying OS) 24.110.145.202

sketching out a road map

You hit 'view source' for the first time on an activity.

You get a copy of the activity's tree composed of hard links. Data and temp are not copied.

Three cases: you have source, you can download source, there is no source. For that last case, the 'view source' button needs to pop up a disassembler.

Consider something like the web browser. One may want the HTML, the Python activity wrapper, the Gecko rendering engine, or any of the numerous other components. Lots of activities are like this.

The UI presents a tree view of the project, which corresponds to the 'tree' toolbar. This toolbar has shortcut buttons to select the activity's main python file, the activity description, and the current-language translation. There are also export/reimport to journal buttons for files that prefer other editors (svg, etc.).

There may be no "main python file". Activities can be written in COBOL, Ada, PL/1, etc.

For many activities, the "main python file" is an uninteresting wrapper. Examples are numerous: the terminal, the web browser, the word processor, and so on. The 'view source' key is very shallow and superficial if it can not access the real meat of an activity. One must ask "Why bother?" if the core code is unavailable.

Internally, there are 2 editors. There's a code/text editor (IDLE or abisource?), and there's a translation editor (kbabel???). In version one the translation editor is just a subclass of IDLE but is kept distinct. These coexist in a tabbed main window. Switching tabs can change the toolbar. There's also the option to start at most one interactive shell, but to save memory this is not started by default.

Saving a file automatically breaks the hard link, makes a local copy, and puts it under Bazaar source control. Question: what to do when there's already a bazaar repository? Bazaar knows light checkouts, but not AFAIK partial light checkouts.

Bazaar checkins can be done manually (keep in journal, as with other activities) and also happen automatically every time the 'run' button is pressed. Every bazaar checkin stores a chit in the journal.

How to deal with checkin comments? Or even links with a bug tracker?

There is a 'run' button. Debug is not part of my first version.

Dream tools: bug tracker, UI designer, profiler, delinter, test suite tools, bazaar merge tools & UI... that last is probably the most urgent.

You need a remote debug ability. Without this, the development tool will strongly interfere with the activity that is being debugged. (only one screen with full-screen activities, a fight over the keyboard, etc.)

a working thing

I hacked together something that works based on Pippy: http://z3p.jot.com/DevelopActivity

All it does now is edit stuff in ~olpc/Activities, but I was using it to develop itself at the end of the evening so it does work in some small way.