Not for me. If you need it, the IP address I get is 207.97.227.245, the same as for other GitHub Pages sites.
But I see how having just the IP address isn't going to help you, since it doesn't distinguish between GitHub Pages. XD Maybe you could temporarily add julialang.github.com to your hosts file or something.
The site at http://julialang.github.com/ 301-redirects to http://julialang.org/. I did mention julialang.github.com above, but I was reluctant to linkify it since it probably wasn't going to help on its own. :-p
Come to think of it, adding a hosts file entry for julialang.github.com probably won't help. Adding one for julialang.org might work though. (If I keep changing my mind, I'll be right sooner or later!)
I'm not sure what Semi-Arc requires as the minimum Android version, though it looks like 1.6 isn't it. Why don't you root/flash your phone and get a newer AOSP? I've done that on my older Tattoo, which came with v. 1.6 and was never upgraded by HTC. As old as it was, it runs like a champ with Android 2.3.7 (I'm using CyanogenMod) - the latest version of Android before ICS was released.
Unfortunately, there are only "safer" ways, no guaranteed safe ways. Still, it's really worth the small risk and the practically new phone you get at the end of the process.
xda-developers provide good how-tos and documentation.
Flashing methods vary by phone, so the method you'd need to follow for the G1 will be different from mine. These three links should get you on top of it quite quickly.
In my experience, the Titanium Backup app proved most useful in storing away all my data, and after rooting your phone, Koush's ROM Manager provided a way to back up my original firmware just in case I ever wanted to go back to it.
I'm not the person you're asking here, and I don't know the answer, lol, but the number one reason I'd install a custom ROM is to get rid of the bloatware that's taking up my phone's precious internal memory, and no doubt its battery life too. ^_^
Speaking of internal memory, that's an issue you're very likely to have on a G1, which only has 74MB. According to (http://androidandme.com/2009/08/news/t-mobile-g1-owners-dont...), that's the very reason there's no official upgrade to 2.2. Even if CyanogenMod somehow fits Android 2.2 on the G1, how much space does it leave for apps? O.o
Yes, there was a slight increase in battery consumption after the upgrade. However, this was more than made up by all the other functionality flashing gave me. Though I haven't tried it myself, you can customize the clock speed of your phone to optimize battery life, if that is crucial to you.
Getting rid of bloatware is one great reason to flash a custom ROM, and in this category I include Samsung's Touchwiz, Motorola's Motoblur and HTC's Sense themes. Though they look visually attractive (at first glance) they are the number one reason these companies don't upgrade the firmware - they are just unable to upgrade each version of the customization for each phone they release.
Regarding internal storage space limitations, the custom ROMs allow you to store your apps on your microSD card, thus removing the limits faced by the G1 under v. 1.6. Notwithstanding the link @rocketnia referenced, I'd say Gingerbread 2.3.7 should pose no problem for your G1. Why, because Koush (Koushik Dutta) wrote up the how to of flashing the G1, and Koush knows something about flashing ROMs (he's the author of ClockWorkMod and ROM Manager, both wildly successful Android apps).
The new ROM will also open up your phone to all the latest apps which just won't run on Android 1.5 or 1.6. Besides, CyanogenMod is really well designed and intuitive, far more so than HTC Sense or Samsung Touchwiz (I haven't had much experience with Motoblur).
"Yes, there was a slight increase in battery consumption after the upgrade."
Oh, drat. I stand corrected.
---
"I haven't had much experience with Motoblur"
Well, then maybe we make up for each other's inexperience a bit. You know way more about flashing ROMs than I do, and I've been getting by with Motoblur, lol.
---
"the custom ROMs allow you to store your apps on your microSD card"
Are you just referring to Android 2.2's "Move to SD card" or something more comprehensive than that?
Even if I could move the executable parts of an app to the SD card (as I can't do with 2.2), I might not want to if it causes the app to terminate when I mount the SD card from another computer over USB. Of course, for certain apps that might be more than okay (e.g. games).
'Are you just referring to Android 2.2's "Move to SD card"...?'
Yes. And you are right, mounting the SD Card via USB makes it unavailable to the phone, with all the consequences. However, you can avoid the need to mount it by using the Android Debug Bridge (adb) command line tool from the computer to push and pull files, etc. A small price to pay for a taste of the latest Android flavour, what? :)
Regarding the battery consumption, I have to say that I didn't scientifically benchmark the difference. I did tend to use the phone much more after flashing the new ROM so that itself was a contributing factor. My bias was completed by reports of others experiencing a quicker drain, but again, I have to say it has never been a deal breaking drain that ever made me consider reverting to the original firmware.
I just checked the Android API versions. The API 10 that suzuki mentioned corresponds to Android 2.3.3, so that would have some bearing on the minimum version you'd need though I'm not sure if it would be 2.3.3 itself.
I would guess it should be possible to create the repl in an older API, but I couldn't be sure.
Just download the apk, (push to your android phone if you download to your computer), and in your phone file manager, press the apk. It should offer to install, if you've allowed non-market apps on your phone. If not, enable non-market apps and it should then work.
Note: I've also added Semi-Arc to our Arc Lang Wiki.
Also, I've seen some languages which allow you to jump from a defined work to its definition and/or description. May be a lot of work but could be quite helpful.
I'm developing a programming language called Kernel. Kernel is a conservative, Scheme-like dialect of Lisp in which everything is a first-class object.
"But," you may ask, "aren't all objects first-class in Scheme?" (I'm glad you asked.) No, they aren't. Special-form combiners are second-class objects. To borrow a phrase from the original description of first- and second-class objects by Christopher Strachey, they have to appear in person under their own names. (There are also several other kinds of second-class objects in Scheme, but special-form combiners are the most commonplace.)
---
What is the theoretical significance of the kernel language? What is an example of a 2nd-class object in Scheme? What is the practical advantage of all objects being first class in Scheme? Does this sound like Smalltalk a bit?
"What is the theoretical significance of the kernel language?"
Fexprs have had a bad reputation thanks to the paper "The Theory of Fexprs is Trivial." However--and this is what I've gleaned just by reading John Shutt's more propaganda-ish statements, not hard math--that paper was based on a particular formulation of fexprs, which doesn't apply to Kernel.
I think Kernel's main contribution is the idea of passing the calling environment in each fexpr call, so that it can evaluate its parameters in the correct environment and preserve lexical scope. On top of that, Kernel has some nuances to its scoping/assignment rules that oughta make it possible in most cases to determine if a variable is a constant, even if we're passing environments around to fexprs all over the place. Once we know something's a constant, we can constant-fold it and (hopefully!) turn fexpr calls that use 'eval into eval-free code, just as if the fexpr were a macro.
I say "oughta" and "hopefully" because I haven't mulled over the details enough myself to be confident.
---
"What is an example of a 2nd-class object in Scheme?"
Special-form combiners? :-p
What that means is things like "if" and "set!". You can't pass the "if" operator as a parameter to a function in Scheme, but in Kernel there are no exceptions like that. The "$if" variable holds an fexpr, and you can pass that fexpr to other places.
Another example used by the Kernel R-1RK is infinite lists. In Scheme, you can pass a cyclic list around in variables, but you can't actually use it as a list because standard list utilities like 'map, 'length, and 'apply don't work with it. Even if you wrote a library that did handle infinite lists, other peoples' libraries would still lag behind. (I'm not really convinced that this makes infinite lists second-class in Scheme. IMO, it just makes them less useful than finite lists.)
Another example is register use. Do you manually pass machine registers to Scheme procedures so they know which ones they're allowed to clobber? No? Well, you don't do it in Kernel either. :)
---
"What is the practical advantage of all objects being first class in Scheme? Does this sound like Smalltalk a bit?"
I don't see an inherent advantage, so I'm probably the wrong person to ask, for Kernel's sake. :-p To me, "first-class object" is redundant, just emphasis to distinguish objects from other things that you might think are objects but aren't.
Given a choice between two languages, where the only practical difference is that one language doesn't let you do as much with certain values (objects), the other language has a clear practical advantage. But sometimes "practical difference" depends on your point of view. To another person, given the same pair of languages, they might say the only practical difference is that one language has features they don't want or need, that actually make it harder for the language and its community to evolve in the way they prefer.
For one particular example of first-class-ness being a good idea: An awful lot of languages allow any module to access certain implicit "global" utilities. If these modules instead took their "global" dependencies as a first-class parameter, that would make it possible (if not necessarily easy, depending on the rest of the language and its community habits) to build programs that securely ran dynamically loaded outside code, using an object-capability model approach.
Here's a followup to the talk. I listened to it, and aside from the main point, did not get much out of it. Of course, it may be because I was quite busy at the time and I don't work in the same kind of languages as Rich. Or not.
