Posted by Nick Sieger
Mon, 23 Oct 2006 14:15:00 GMT
Koichi SASADA
Update: corrected performance numbers -- 20x, not 20%!
- Got a job developing YARV at the University of Tokyo! He’s now employed at Akhihabara, Otaku City.
- Member of Nihon-Ruby-no-Kai
- Present at RubyKaigi 2006 (200 tickets sold in 3 hours). RubyKaigi 2007 will be June 9-10 (Saturday and Sunday).
- Member of Nihon-Perl-no-Kai
- Co-author of Perl book on Parrot in Japanese
DEMO
- [Demo creating Rails app]
- Create app with YARV (
rails foobar)
- Edit config/boot.rb, add a
GC.disable line (there’s a bug to be fixed when he gets back to Japan).
- Start up WEBrick, and it works!
Glossary
- Rite: code name of Ruby 2.0 (a.k.a. vaporware!)
- YARV: Yet Another Ruby VM
YARV
- Supported by funds from IPA (now finished)
- Simple stack machine, with VM instructions, a compiler and interpreter
- Optimization techniques to improve performance
- Open source
Optimizations include compile-time optimization, native threading, specialized instructions, instruction unification, inline method cache, and stack caching. YARV can build with configure/make, but doesn’t work with AC 2.6 (maybe you know why?). It passes most of the Ruby tests, but misses a few due to implementation differences.
[Koichi showed a demo controlling iTunes on Windows with Win32/OLE with YARV, and a native-threaded scenario in IRB.]
Myths of YARV: YARV is great! YARV will solve all problems! It makes Ruby programs go 50 times faster! It solves character issues! It finds your girlfriend!
Truths: YARV is for running Ruby programs, fast. It provides up to a 20x speed up for some algorithm benchmarks (Ackermann, Fib), but not for others [graphs shown]. You assemble and disassemble YARV instruction sequences, or serialize and de-serialize them. They are just Ruby literals, so they can be packed in YAML or some other human-readable format.
require 'yasm'
require 'yaml'
iseq = YASM.toplevel([:a, :b]) {|ib|
ib.answer
ib.leave
}
p iseq.to_a.to_yaml
Threading
- Ruby thread is mapped 1:1 to a native thread
- Supports POSIX and Win32
- Many existing Ruby libraries are not synchronized at the C level, so many C libraries need synchronization added to them
- Thread model 2: 1:1 mapping, with a Giant Lock (GL). Only the thread that has the lock can run. No need for sync, but no parallelism
- Thread model 3: Ruby threads in parallel, but when thread-unsafe code is executing, GL needs to be obtained
- Mutex class will become builtin
- Thread.critical will vanish (not obsolete, but unsupported) [this was a controversial point for some -- the comment was that it’s a near impossibility to keep it with a native threading model though, the two are in compatible]
Matz: 1.9.1 in 2007 Christmas, but Ruby 1.9.1 is also to be merged with YARV, so Koichi hopes to complete the merge by spring or summer 2007. Thread model 2 will need to be used to begin with.
Future
set_trace_func hook functions -- what to do here? [It was suggested by Charles Nutter to remove it, to which Matz replied that we could as long as we have a good replacement debugging API.]- Catch up with Ruby 1.9
- JIT/AOT compiler (AOT compiler started but incomplete)
- Koichi also has a side project: high-performance Ruby, with the goal of making it easy to write performant code.
Links
More developers and testers are welcomed to the project!
Posted in ruby | Tags rubyconf, rubyconf2006 | no comments | no trackbacks
Posted by Nick Sieger
Sun, 22 Oct 2006 03:41:22 GMT
The Return of the Bikeshed
or Nuclear Plant in the Backyard
Ruby is
- Scripting (some people outside of Japan don’t like this one)
- Programming (sure, it is)
- Lightweight (see Takahashi-san’s history -- LL is a popular term in Japan)
- Dynamic
The agile manifesto claims 4 values. It encourages developers to act responsibly. What if these values were applied to programming languages?
- Individuals and interactions: language design should focus on users (i.e., developers).
- Working software: language should encourage readability
- Collaboration over contracts: expressive language, which helps communication.
- Responding to change: language should embrace change
Thus, Ruby is:
The Agile Language
The Good, Bad, Ugly of Ruby
Good
- Sweet language
- RoR
- Ruby people are nice (Martin Fowler -- “because Matz is nice”)
Ugly
Bad
- Ruby 2 vaporware -- close to longest in open source (Rite > Perl6)
Bikeshed
What is the bikeshed? (FreeBSD people hate the bikeshed.)
People tend to argue about little things that they know enough to do so. The amount of noise related to change is inversely proportional to the complexity of the change. Thus leaving important things behind.
The nuclear plant is too complex, so we leave it up to experts to think about it. As a result, we spend time on unimportant things.
- Symbol < String
- #lines
- removing private and protected
Thus leading to suggest that Ruby is a...
Fragile language
- Ruby 1.8 is good enough! We’re not in a hurry.
- Extreme arguing -- why not make everything easy enough to be argued by everyone?
Design game
- Gather wild ideas
- Try to make it the best language ever? (We feel good about Ruby, but I don’t know why.)
- Shed light on undefined corners of Ruby
- Document a specification
RCRchive so far hasn’t worked out, because a few people took it too seriously.
- Ruby will stay Ruby, but it shouldn’t be a vague idea. Rationale, analysis, discussion, with a prototype implementation
- I (Matz) will stay the benevolent dictator, but will promise to be as open as possible.
- 80-90% compatibility. It can break, but we have to keep the same philosophy that we love.
Hey, we need optional explicit typing in Ruby! So what!
Look at Python, it has a very organized (ahem, strict, something [laughter]) PEP system that seems to be working well. Mailing lists are more suitable for discussion. Use RCRchive as a starting point, but use a new system/channel for each proposal. Prototypes are needed. Running code accelerates the discussion.
Why should we start this game? I want to share language design with the community. I’m tired of the slow evolution of Ruby. We’re using 3-year-old technology. We need to catch up, so that people aren’t saying “Ruby, we had that language a long time ago!” Educating the developer community is a great venue for learning about language design.
I may be hit by a truck someday, in which case Ruby will be Ruby 1.8 forever! In that case you can do whatever you want with 1.9.
Considering a submission deadline -- 2007-04-30, but it might not be needed. Classify proposals under GBU (Good, bad ugly), plus version (1.9 or 2.0). Implement them. Merge them. If it doesn’t work out, we’ll try another thing. We lose nothing but time. See you next year, hopefully with good news! Ruby 1.9.1 stable (but bleeding edge) will be out Christmas 2007.
Q & A
Q. Following the Agile tenets, perhaps we should submit tests and specs that document the feature? [Missed the answer, perhaps it was agreement on the part of Matz?]
Q. Maybe you should leave 1.8 for others to maintain? I’ll stay on 1.8 and there will be contributors to help with the new features going forward.
Q. You mentioned parse.y as ugly -- how would the parser become more accessible? I have no concrete plan, but I’d like to create a simpler parser. Would you be open to non-BC parser changes? If someone raises their hand to make a new parser, I’ll discuss the compromises needed. What about participation of the VM design? (e.g., I like Smalltalk can I try that out?) I have no opposition to alternate implementations of 1.8 or 1.9, but it’s difficult to target 1.9 (moving target). Koichi took his role as chasing the moving target, and he suffers a lot. I’m sorry for him.
Q. With corporate support and alternative implementations, how worried are you about fragmentation? I don’t worry about it. I don’t have any trademark on Ruby or any business on it. It’s more like a competition -- may the best interpreter win. Some will be fast, some will be stable, we can compare them.
Q. I like the aesthetic in Ruby. Can you push forward the beauty of the language, or are you happy as it is? I’m not sure how much room we have left. 1.8 may be good enough. During the discussion, we’ll see.
Tags rubyconf, rubyconf2006 | no comments | no trackbacks
Posted by Nick Sieger
Sun, 22 Oct 2006 00:07:34 GMT
Speaker: Michael Granger
Michael’s talk was full of excellend pre-recorded video demos, and thus was difficult to note-take. Instead, here are links to most of the pieces of software he discussed for your perusal:
Tags rubyconf, rubyconf2006 | 1 comment | no trackbacks
Posted by Nick Sieger
Sun, 22 Oct 2006 00:06:00 GMT
Tim Bray is going to talk about characters and strings. He will gladly talk about text until your arm falls off, and buy half the beer.
Introduction
English is no longer the majority language on the web. It’s nonsensical to ignore i18n issues with new apps.
This is probably a bug:
Problems to solve to help us with i18n
- Identifying characters
- Byte-character mapping and storage
- A good string API
References
- Worlds writing systems
- Character model for the web (W3C)
- The Unicode 5.0 Standard (forthcoming book) (same as ISO 10646)
Unicode
- Numbers identified by code points (> 1,000,000)
- 17 Planes each with 64k
- Original characters (available in any computer anywhere before Unicode was invented) in Basic Multilingual Plane (BMP, first plane)
- Characters identified as U + (4 hex digits)
- Unicode character database
Benefits
- Repertoire
- Room for growth -- lots of space left in the middle planes
- Private use
- Sane process --
- Character database
- Ubiquitous standards and tools
Difficulties
- Combining forms -- need to normalize the characters for comparison (1/2 vs. ½) and this is not something you want to do in your
String#== method
- Awkward historical compromises with other encodings
- Han unification (note: Tim considers wikipedia article to be biased)-- characters that might mean something different were given one codepoint by asian linguistic specialists.
Storage
- Official: UTF-8, UTF-16, UTF-32
- Practical: ASCII, EBCDIC, Shift-JIS, Big5, EUC-JP, EUC-KR, MS code pages, ISO-8859-*, etc.
But with Video the largest bandwidth eater, does text size really matter?
Identification
How to identify what text is coming in over the wire?
- Guess -- browsers, python lib
- Charset headers, which are known to be wrong
- Trust -- two partners agree in advance for a pattern of exchange
- XML [this last one was quite obvious right]
Language approaches
- Java -- design flaw; characters are UTF-16, which is unfortunate. Implementation is sound and well tested, but Java is clunky.
- Perl 5 has excellent support in theory, but practically speaking, it’s difficult to round-trip text through a DB without some breakage.
- Python has byte arrays and strings, some string-like methods on byte arrays, binary or text data, glosses over issue of plaform file encoding
Ruby
- Some core string methods have i18n problems due to counting, regexp, equality and whitespace concerns.
String#each_char seems to be a missing method; string class maybe should be aware of its encoding.- Behavior of
String#[] seems ok for byte buffers but it probably doesn’t need to be efficient for characters. Most of the use-cases for String iteration should be for characters (exception: Expat)
- Case-changing methods -- avoid them at all costs in a mixed language environment!
- Regexps need unicode properties for safer matching (
p{L} for lower-case letters, p{N} for numbers)
- Does Ruby need a Character class or a Charset class?
What is next for Ruby? [Tune your divining rods toward ruby-talk for the rest of the story!] Matz has m17n; Julik, Manfred and crew now have ActiveSupport::MultiByte in Rails; JRuby is built on a platform that already has a Unicode string, so the discussion is heating up.
Update: slides available here.
Q & A
Q. What if I have a stream of bytes with no knowledge of encoding? Don’t try to impose an encoding lens above the level of a string, programmers want to treat a string as a string with associated methods.
Q. What if I need to change case of text? Get used to the fact that it won’t work reliably work. What about characterizing the finite amount of languages? Java does that, and it’s still not really possible. Shouldn’t the string class know the encoding? Couldn’t it optimize better? Couldn’t you raise an exception? Just don’t do it! Isn’t there a body of knowledge that could be acquired about case? Hmm, next question that isn’t about case!
Q. Is there a resource for edge cases of processing text in XML? Search for “xml test cases”. The decision is between ignoring the metadata provided, and choosing not to process it.
Q. What is the python library that can guess the charset? It’s in the feedvalidator suite.
Posted in ruby | Tags rubyconf, rubyconf2006, unicode | 3 comments | no trackbacks
Posted by Nick Sieger
Sat, 21 Oct 2006 19:01:35 GMT
Speaker: Glenn Vanderburg
Rinda is a distributed coordination system, by Masatoshi SEKI, based on work by David Gelernter (called Linda). It’s similar to JavaSpaces, but more in the Ruby spirit. It uses DRb for communication (also by Seki-san).
There are several existing tutorials on Rinda, but none with a broad, real-world applicability. As Glenn started to go deeper with Rinda, flaws began to be exposed.
Rinda Basics
- The TupleSpace is in the conceptual middle, as a bag of tuples “arrays”. Participants can write tuples into the space, or take them out (usually according to a set of conditions).
- Tuples are usually requests to do some work by some unknown requester, or responses to that work.
- A RingServer is a broadcast/multicast lookup service for finding Rinda tuplespaces.
- Templates are used to find tuples to take.
Template#match requires that the tuples have the same length, and that all the non-nil elements are triple-equal (===).
- In practice arrays are always used in the
#take and #write methods, and they’re implicitly converted to the appropriate object.
Protocol design
When you’re deciding what to store/read in the tuples, you’re essentially designing a communication protocol. So you need to take the extra precautions required as you would when designing any API or protocol, including documentation, evolution of changes, process workflow, etc.
- Parts of tuples: command/request, identifiers, and associated parameters/data. Usually templates will match on the command, sometimes on the ID, but never on the data.
- Strings work well in tuples, because you can use Regexps to select them.
- Numbers work well, because you can match them with Ranges
- Symbols don’t work so well (at least until
Symbol < String)
- Communication patterns -- synchronous communication is not a good fit for a Rinda architecture (e.g., a request for status)
Deployment
DRb does not marshal code/behavior (unlike Java and RMI). This is a limitation that forces you to consider how to use custom objects in the tuples, because the code must be shared (and thus jointly upgraded) across all participants.
Multiple processes are probably more reliable for the various components of the architecture (RingServer, TupleSpace, clients) rather than using green threads, although this is just a hypothesis.
The TupleSpace is the single point of failure -- if the process with it crashes, when it starts back up, it’s likely to have a new DRb URL, so it’s helpful to have a proxy around the tuple space in clients that can rediscover it if it crashes.
Be wary of multiple ring servers on the same subnet! Behavior may be unexpected. You may notbe using the tuple space that you wanted, and when the other ring server goes away, so does your tuple space.
DRb does not have any security built into it, such as unforgeable object IDs, encrypted transport, authentication, etc. This can be a problem in some situations.
There is no persistence by default, so consider adding some for crash resistance, or deal with occasional loss of tuples.
There are no transactions, so the requester will never know if it still processing or was lost.
As Ruby matures and gains exposure, some libraries that have been good enough for a while may need reconsideration. As a case in point, Rinda and DRb haven’t been updated since February of 2004.
Q & A
Q. Are write/take atomic? Yes, if you timeout, the tuple will still be there. Two workers cannot get the same tuple.
Q. Where would you use this instead of traditional message queues (reinvent the wheel)? There’s more flexibility in this architecture. (Justin Gehtland) In this particular case, they have a JMS backend, but the Ruby code could not assume connectivity to that backend.
Q. Is there a common correlator design pattern? Tie response types to request types to limit the pool of potential matches. In the situation where there is a single requester, it’s simple to just generate sequential numbers. In a P2P situation, you may need to use a hostname or PID to help distinguish. [Sounds like a GUID/UUID system to me.]
Q. Have you used expiry dates to grab abandoned tuples? No, sounds like an interesting possibility.
Tags rubyconf, rubyconf2006 | no comments | no trackbacks
Posted by Nick Sieger
Sat, 21 Oct 2006 18:58:33 GMT
Laurent Sansonetti, who works at Apple Computer, is now in charge of maintaining Ruby inside the OS.
History of Ruby in the OS
- 10.2 shipped with Ruby 1.6.7
- 10.3 shipped with Ruby 1.6.8
- 10.4 shipped with 1.8.4, and the latest software update has Ruby fixes to allow compilation of C extensions
Apple is actively looking to improve Ruby support in future versions of the OS in several areas:
- Ruby.framework
- 64 bit support
- Controlling scriptable applications
- Cocoa development
Framework
Why a framework? It’s easier for Mac development. It allows multiple versions, and lets you bundle Ruby inside your application. It’s also compatible with original layout /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Current/bin/ruby
Misc
- Include IRB support, RubyGems, plus important gems: Rake, Rails, libxml2 and sqlite3 bindings, DNSSD (Zeroconf)
Controlling scriptable applications
Traditionally applications are scripted by AppleScript. Apple Events are the IPC glue between the two.
RubyAEOSA is a Ruby wrapper for Apple events, that was started in 2001, but not active since 2003. The code required is unnecesarrily verbose. Instead, you could wrap and execute with AppleScript, but it’s slower and limited by knowledge of AppleScript.
RubyOSA is a new project created by Apple, intended to be a successor to RubyAEOSA, under active development and used today. It has a much more Rubyish API, generating Ruby code on the fly and sending events lazily. Apple events are completely hidden.
require 'rbosa'
itunes = OSA.app('itunes')
itunes.current_track
itunes.current_track.name
itunes.current_track.artist
itunes.current_track.size
itunes.play
itunes.pause
itunes.sound_volume = 0
100.times {|i| itunes.sound_volume = i; sleep 0.1 }
0.1.0 release is coming soon, gem install rubyosa.
Cocoa development
Mac development framework, mostly using Objective-C. RubyCocoa is a Ruby/Objective-C bridge, now under active development with support from Apple. It creates Obj-C classes to Ruby proxies and vice-versa. Messages and exceptions are forwarded, and types are converted.
It uses a message convention. ‘:’ are substituted with ‘_’ in the method name (selector). The final ‘_’ can be omitted, but can lead to ambiguities. It may be mandatory in a future release.
Some challenges remain in the Ruby/Obj-C bridge.
Problem: Speed of method invocation. Solution: libffi from gcc, allows invocation of arbitrary foreign function interfaces.
Problem: Maintenance. Currently RubyCocoa needs to be rebuilt to take into consideration new APIs, so to solve, a metadata framework is being built to allow the information to be more dynamic, and a metadata generator tool will help with creating a metadata file for new APIs
These latest developments are available from the apple-unstable branch in SVN from rubyforge.
Future
- “Toll free bridge” -- implement Ruby primitive types with CoreFoundation objects so that no type conversion is necessary
- Garbage collection -- Objective-C will be getting garbage collection in the future, and the idea is to implement the Obj-C garbage collector in Ruby through Obj-C APIs.
Tags macosx, rubyconf, rubyconf2006 | 5 comments | no trackbacks
Posted by Nick Sieger
Sat, 21 Oct 2006 18:54:00 GMT
Update: Full text of Nathaniel’s talk.
Nathaniel is honored to be speaking at RubyConf for the sixth year in a row. His basic premise for today is this: the language you’ve chosen has certain characteristics that reflect back on you. In turn we can reflect on those characteristics and how they relate to what we value in business as well.
Dynamism
Ruby’s typing system (contrast to static typing). I’m thinking about my program, not satisfying the type checker. Static typing sounds good in theory but I haven’t found it that helpful in practice.
How about dynamism in business? How about job titles. If you stick a person in a “box”, they pretty much stay in it. It’s easy for HR, but not good for the growth of the business. In Ruby we have duck-typing, but a fixed job title is kind of like static typing. It makes it harder for you to adapt to the situation at hand, or keeps you from growing into new roles you never thought you could do. Nathaniel mentions how he, as a programmer, never thought he could be good at sales, but now he likes it.
Interpretation
The behavior of the program is order-dependent (contextual). Once you embrace that Ruby interprets statements as it encounters them, you find power in it. It allows you to delay decisions until they’re necessary, a feature that supports dynamic business.
Succinctness
A stated design goal for ruby (by Matz) is succinctness, but not just brevity for brevity’s sake (e.g., extremely compact Perl), but in a read/write sense.
A succinct legal agreement is wise use of the limited time a client has to figure out what he’s signing up for. Legal agreements should have one purpose -- to set expectations so that no one is surprised.
Maybe your employment agreement is so long and full of legalese that you’ve inadvertently signed up as a corporate slave. Be wary; ask for a summary; consider how it might affect your ability to contribute to open source projects.
Reflection
Ruby the language permits and even encourages a high degree of introspection. Does your workplace reward introspection, or penalize it? Or is it a “fire and forget” environment?
Open classes
Ruby allows any code to open any class, add/remove code, muck with state. Could we break things everywhere? Yes. But Ruby values implementor power over safety or security through obscurity. This can be scary for some.
When people close to you know a lot about you, they can hurt you. You’re vulnerable. But the other side of this is that being open builds trust, which is an essential component of a successful business relationship.
Do you know what your peers are paid? Do you know what deals are in the pipeline? Can you look at the books?
Ruby’s open nature may seem naive, but it’s wonderfully naive.
Discussion
Q. Would these techniques work outside of a technical hub? My business is not driven by locale. I’m able to assign work in a distributed manner.
Q. You assume that your peers are trustworthy and honest. What about in a more cutthroat competitive environment? You either need to change your organization or “change your organization”, i.e., switch jobs or try to effect change to find a place that reflects your values.
Q. Transparency meets the real world. Crashing software and crashing companies are two different things -- perhaps the analogy can only be taken so far? The worst that could happen is that I get nothing for the time I invest other than the learning experience. It’s more a matter of limiting risk. I’m not saying I’m broadcasting every detail to every client.
Q. Do you scope clearly and bid, or do you do ongoing hourly work? I only do time and materials. RFPs make me gag. People spend time on the piece of paper and then give it more credence than my own opinion.
Q. How does testing play into this? One thing that Ruby values is constant feedback, which is also a big tenet of testing. Constant and short feedback cycles, “testing your customer” -- don’t get caught in a long-term agreement.
Q. How do you put that in a statement of work? I make sure the client knows that we’re building a trusting relationship. I also don’t claim to have this all figured out.
Q. Can you scale this (team of trustworthy people) to a larger model? This is in a way like the evergreen question about Ruby; “does it scale?” Partly, I don’t care because it’s working for me now. On the other hand, I’m thinking about it because I like the thought of bringing more people into the fold. [A comment from the audience brought up the subject of lifestyle companies as an example of why it wouldn’t.]
Q. There are two types of contracts -- the 2-page business agreements and the 50-page CYA edge cases. True, I have the luxury of working with clients that small enough that they are not likely to sue me.
Q. If everyone is a sub-contractor, there is no career path or “carrot”. Part of the goal of my business is to catapult people beyond it by allowing them enough free time to work on their own things.
Q. How do you balance work and life? I’m not always the best at it, but now I’m working out of my house and can be with my family when things come up. Some days I shut the door and get things done. Work/life balance is messy and I work on it on a daily basis.
Posted in ruby | Tags rubyconf, rubyconf2006 | 2 comments | no trackbacks
Posted by Nick Sieger
Sat, 21 Oct 2006 03:22:00 GMT
Ok, ok, so I’ve been caught redHanded. Yeah I know, Tufte hates bullets. You might feel a strange sensation if you stare at my transcriptions of today too long. If anyone is offended or would like to claim I’m a card-carrying NRA whipping boy, let me know and I’ll try to tone it down a bit. Thanks for the mirror of truth, _why!
Tags ruby | 1 comment | no trackbacks
Posted by Nick Sieger
Sat, 21 Oct 2006 02:59:38 GMT
An annual tradition at RubyConf is the “Roundtable”, where any member of the audience can come up and ask Matz any question. Transcript follows with partial paraphrasing.
Q. Will Ruby ever get the features of evil built in? Will we get become? No.
Q. If Symbol is a “frozen” String, why do we need Symbol? I don’t have a complete answer to that question -- following tradition.
Q. What’s the most unusual architecture Ruby has ever run on? Ruby...I can’t think of one...JRuby? Some guys ran compiled Ruby on the NECS supercomputer. [From the audience] Symbian.
Q. As Ruby gains acceptance, it becomes more resistance to change. How do you keep agile while gaining momentum? We have forked off 1.8, so if you want stable, use Ruby 1.8 forever.
Q. The array patch -- is there any chance of a backport for those of us who want 1.8 forever? Could be, but the current patch has a bug in 1.9.
Q. Why isn’t YARV the only VM for 1.9? [Comment about register-based VM] I’m not sure whether stack-based or register-based VMs are better...[THAT GUY!]...[Given the hook]
Q. It seems like momentum is based on strong metaprogramming facilities. With 1.9 there are more user-friendly features. Will code eventually be data, or are we just patching on techniques on a tool that is being used more heavily? An extreme way to do metaprogramming is to use Lisp, but for practicality we have to start somewhere. I’m not sure that s-expressions are the way to go. We’re not going to have macros. It will remain similar to what we have in 1.9. The ability to serialize code would be really powerful -- will that happen? Disclosing internal state is tricky because it changes. It could be a platform-specific feature.
Q. Recently for 1.9, there was a patch for Array and String to be in the object header. Was this profiled? It seems like it would be an incredible performance problem. It was done for slowness of malloc and gc. In some cases it could run slower, but it benchmarked at about 5% faster. It should be tested thoroughly.
Q. Ruby 2.0 will not have green threads or continuations, correct? Are there specific reasons for that decision? It is difficult to implement green threads in YARV.
Q. People want to see development move quickly, but may not be able to contribute code. Can you suggest ways for those programmers to contribute? Submit patches to the list. What is the obstacle to joining us? [Question restated] Submit testing, submit documentation. Contribute to RubyCentral? (looks at Chad Fowler)
Q. The CSV library is useful, but slow. Can we see FasterCSV in stdlib? It’s ok to replace the csv library with FasterCSV, as long as the compatibility issues are resolved.
Q. I want to thank you because I love writing in Ruby every day. I tried to write Python first. Recently an unrelated upgrade broke my Python apps. Will we be able to manage multiple versions of Ruby? You’ll have to have two versions, 1.8, and future ones.
Q. What would you say is the most important feature of your personality that has given you success? Endurance? Can you elaborate? It’s easy to design a language, many of them disappear in a year or two. I’ve been working on Ruby for 13 years.
Q. I wanted to see in IRB how the class was implemented at runtime. (He means an uneval feature) [Audience member (Eric Hodel?) mentioned ParseTree]
Q. If there wasn’t Ruby, what would you be programming in? Some language of my own not named Ruby.
Q. Do you still look at RCRchive? Yes. I’ll talk about it in the keynote.
Q. I would like a feature abstraction that would allow Ruby to fork itself rather than actually forking. Can you see this added to core? We have to define the behavior of that feature. We have to have a good name for the method. Then there will be no problem to add it to core.
Q. Why do you need to bind methods to an object of the same original module? If you bind a method taken from String class to Array class, it will crash, and we need to prevent it.
Q. What do you think of Ruby.NET? I’m pretty open to new implementations. Should there be a standard (language specs) that other projects should follow? Charles started work for a written 1.8 spec, and I’ll help him with that if I have time.
Tags rubyconf, rubyconf2006 | 2 comments | no trackbacks
Posted by Nick Sieger
Sat, 21 Oct 2006 02:54:00 GMT
What is Radiant?
- No-fluff, lightweight CMS for small teams
- Simplicity over features
- A little more than a blogging engine
- Made for designers and programmers (techies)
- Tag-based template language
- Total control over output
- Plugin extension mechanism under development
- Content sites, not portal software
Getting Started
- Install:
gem install radiant
- Generate a new application:
mkdir demo && cd demo && radiant .
- Configure database:
cp config/database.sqlite.yml config/database.yml
Installation types
- Instance mode vs. application mode (whether or not you have Rails source present). Instance mode also makes it possible to clone and
share customize Radiant applications.
- Base application includes an admin interface
Pages, Snippets and Layouts
- Hierarchical page management
- Create page in several states (draft, reviewed, published) in Textile or Markdown with slug, breadcrumb, and layout
- Snippets are small chunks of content that can be shared between pages (to DRY up your content)
- Layouts that can be broken down into components of the layout (sidebar, etc.)
Tags
- Radius
<r:title/>, <r:content part="sidebar" inherit="true"/>, <r:snippet name="footer"/>, <r:if_content part="extended">...</r:if_content>, <r:children:each limit="5" order="desc">...</r:children:each>- Tags can be embedded anywhere, not just in the layout
- Tags are contextual -- e.g.,
<r:title/> picks the correct title even if it is embedded within a snippet within multiple pages
- Custom tags possible with “behavior”
Text Filters
- Textile (RedCloth), Markdown (BlueCloth), SmartyPants
- Vanilla HTML (no filtering)
- Custom filters possible. [This is my own example below, not John’s.]
class MyFilter < TextFilter::Base
register 'profanity filter'
def filter(txt)
txt.gsub(/(damn|ass|shit)/i, '####')
end
end
Radiant is powering the new ruby-lang.org site. Overall, a slick, well-thought out, polished, extendable CMS done very much in the philosophy of Ruby and Rails. Check it out!
Posted in ruby, rails | Tags rubyconf, rubyconf2006 | no comments | no trackbacks
