Re: [fonc] Evolutionary Debugging :.
On 01/16/2014 10:58 AM, John Carlson wrote: What I was thinking was evolving space travel. If it is a physics engine, could it evolve warp drive? Rockets? It'd be fun to see rockets evolve. Should be possible; we understand the physics involved. Warp drive -- well, if we simulate a universe in which this works, it should be able to evolve. Or teleportation, etc... There was a science fiction story I read years ago which involved plants which had evolved teleportation. This proved so advantageous in spreading their seeds to optimum locations, or having one part of the plant located where it got sun and another part of the same plant located at a good source of water , and so on, that most of the plant life on this fictional planet ended up with some kind of ability to teleport. (If anyone recognizes this story, and knows the title and author, let me know -- I've long forgotten both) Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] hashes as names
On 09/26/2013 05:50 PM, Wolfgang Eder wrote: hi, in recent discussions on this list, the idea of using hashes to identify or even name things is often mentioned. in this context, hashes are treated as being unique; albeit unlikely, it *is* possible that hashes are equal for two distinct things. are there ideas about how to handle such a situation? If what you want is unique identifiers, you basically have two choices: 1) Have a single central authority that hands out identifiers. 2) Settle for a very small probability that identifiers will not be unique. The central authority model works in some scenarios, but for widely distributed systems the reliability problems (the central authority may be down or unreachable) or scalability problems make it unworkable. Whenever you generate identifiers concurrently in multiple places there is some chance that you will generate duplicates. There have been schemes to generate globally unique identifiers. These all turned out to be flawed, so that just using a good random number generator and generating enough bits is more reliable. So a random number generator is a pretty good solution if all you want is unique identifiers. Where a hash comes in is if you want the identifiers generated in different places to be the *same* if the content being identified is the same -- you hash the content, and the resulting hash is the identifier. If the identifiers must also be unique, it's important to use a strong cryptographic hash. These are designed so that you can't get collisions even if you know how they work and try really hard, so they have good uniqueness properties. The probability of duplicate hashes is still non-zero, but it's pretty tiny. This is why, for instance, git uses the SHA-1 hash as a unique identifier. You *could* get two non-equal objects with the same hash, but it's so unlikely that this case is not handled, AFAIK. To even detect the case you'd probably have to introduce a central authority, and re-introduce all those much worse problems. Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future
On 03/27/2012 10:03 AM, Craig Latta wrote: Hi-- Was the talk recorded? Hi Craig, As far as I know, the talk itself was not recorded. 'Twas a good talk, though. Among other things, Dave brilliantly and entertainingly illustrated race conditions using the plot of Romeo and Juliet. There is, however, a video interview with Dave about the talk, recorded at Splash: http://my-inner-voice.blogspot.com/2012/01/many-core-processors-everything-you.html Sam Adams also gave a rather different keynote talk about the same project at the Smalltalk Industry Conference last week. That talk was taped, and the video should appear online at some point. The abstract is here: http://www.stic.st/conferences/stic12/stic12-abstracts/massive-parallelism-object-oriented-programming/ Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Talking Typwriter [was: Barbarians at the gate! (Project Nell)]
On 03/14/2012 09:54 AM, Alan Kay wrote: 1. Psychologist O.K. Moore in the early 60s at Yale and elsewhere pioneered the idea of a talking typewriter to help children learn how to read via learning to write. This was first a grad student in a closet with a microphone simulating a smart machine -- but later the Edison division of McGraw-Hill made a technology that did some of these things. Now that reference brings back some memories! As an undergrad I had a student job in the Computer Assisted Instruction lab. One day, a large pile of old parts arrived from somewhere, with no accompanying documentation, and I was told, Put them together. It turned out to be two Edison talking typewriters. I got one fully functional; the other had a couple of minor parts missing. This was in late '77 or early '78, about the same time I was attempting (unsuccessfully) to learn something about Smalltalk. Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Physics and Types
On 08/03/2011 08:10 PM, Simon Forman wrote: On the other hand, there's a story (I believe it's in one of the VPRI documents but I couldn't locate it just now) about children using their machines to take pictures of a falling object and then analyzing the pictures and deducing for themselves the constant-acceleration rule for gravity. IIRC, this is one of the things on the Squeakers DVD. http://squeakland.org/resources/audioVisual/#cat547 Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] x86_64...
Michael Haupt wrote: Hi, today I migrated to a new machine at work, a nice and fast dual-core 64 bit box. Building COLA works fine as long as only idc is concerned; building jolt blows up (obviously): - cp: cannot stat 'CodeGenerator-x86_64.st': No such file or directory - I found an e-mail from Martin McClure saying that he was working on code generation support for x86_64 (in August). Has there been some progress? Is there *any* way for me to make it work (32 bit chroots aside)? Please don't say I have to implement the code generation myself, I don't quite feel competent. ;-) Hi Michael, So far, I've made very small progress on the x86-64 code generator (limited mostly by lack of time to work on it). I'm still interested in moving forward with this. Since all of my machines are x86_64, when not working on the code generator I've been working in 32-bit chroots, which seems to work well in general. The exception is jolt. It ran into problems with execution permission not being set on the memory into which it was placing the generated code. I got jolt2 to work using the patch I posted in the Fix for CPUs with execution protection thread on November 3. There are also other suggested fixes in that thread. Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Fix for CPUs with execution protection [was: Jolt2 code generation: what works?]
Gerardo Richarte wrote: Martin McClure wrote: There doesn't seem to be a way to malloc memory that's executable in this kind of system, so I fixed it by using mmap/munmap instead of malloc/free. As far as I know there is no way, unless you either globally turn non-executable heap off, or, on some systems, turn it off per process (it depends on the operating system, on windows, for example, it's a legal library call, on other unixes there are tricks). However, on most unixes (unless they use PaX, for example), you can first malloc() and then mprotect() the returned address so it is rwx, on some others you can't have W+X, so you have to first make it write+non-exec, and then, non-write+exec. I'll see if I can find the call that will disable it in linux (for example, mprotect(0,...,0x,READ | WRITE | EXEC) should turn all memory rwx (constants and arguments are probably wrong, just use them as guide). However, it does depend on the kernel you are using. On some systems (PaX) W+X it's absolutely forbiden unless you disable that feature for the executable ELF (using chpax) Thanks. It looks like this would work on Linux, but according to the man page the combo of malloc() and mprotect() isn't POSIX-legal. Maybe in practice there's no problem, I don't know. Ian pointed me to the execstack utility and linker flag, which set a flag in the ELF binary saying that the binary expects to execute from its stack pages. On Linux, this seems to also also set X permission on malloced memory, and so solves the problem. Regards, -Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
