[#1215] Tk widget demo; English Tk docs?; Java 1.2 Swing — "Conrad Schneiker" <schneiker@...>
Hi,
[#1218] Trivial FAQ bug — Dave Thomas <Dave@...>
[#1229] A vote for old behavior — Dave Thomas <Dave@...>
[#1232] Any FAQ requests, updates, ... — Dave Thomas <Dave@...>
[#1233] Singleton classes — Dave Thomas <Dave@...>
[#1263] Draft of the updated Ruby FAQ — Dave Thomas <Dave@...>
[#1307] Ruby/GTK 0.23 released — Hiroshi IGARASHI <igarashi@...>
Hi all,
From: Hiroshi IGARASHI <igarashi@ueda.info.waseda.ac.jp>
From: "Conrad Schneiker" <schneiker@jump.net>
On Fri, Feb 18, 2000 at 09:37:27PM -0500, Yasushi Shoji wrote:
[#1322] FAQ: Ruby acronyms — "Conrad Schneiker" <schneiker@...>
In the spirit of TABWTDI (there are better ways to do it), I'd like to
[#1341] Vim syntax file — Mirko Nasato <mirko.nasato@...>
Hi,
On Mon, Feb 14, 2000 at 05:44:39PM +0100, Mirko Nasato wrote:
[#1354] Say hi (bis) — Pixel <pixel_@...>
hi all,
[#1355] nice sample for functional stuff — Pixel <pixel_@...>
what about having map in standard (and map_index too)?
[#1373] Ruby Language Reference Manual--Glossary — "Conrad Schneiker" <schneiker@...>
I was going to print the Ruby Language Reference Manual when I noticed that
[#1376] Re: Scripting versus programming — Andrew Hunt <andy@...>
Conrad writes:
[#1379] Re: Yield — Andrew Hunt <andy@...>
>From: "Conrad Schneiker" <schneiker@jump.net>
[#1384] Re: Say Hi — mengx@...
My suggestion was to try to find a more comfortable method name (to me, and
[#1392] Re: Some Questions - Parameterised Types / Invariants — Andrew Hunt <andy@...>
>1. Parameterised Types / Template Classes
[#1398] Bignum aset — Andrew Hunt <Andy@...>
[#1488] Discussion happens on news.groups — Clemens Hintze <c.hintze@...>
Hi,
[#1508] Ruby/GTK and the mainloop — Ian Main <imain@...>
Hello Ian,
On Wed, Feb 23, 2000 at 02:56:10AM -0500, Yasushi Shoji wrote:
[#1516] Ruby: PLEASE use comp.lang.misc for all Ruby programming/technical questions/discussions!!!! — "Conrad Schneiker" <schneiker@...>
((FYI: This was sent to the Ruby mail list.))
From: "Conrad Schneiker" <schneiker@jump.net>
[#1528] ruby <=> python — Quinn Dunkan <quinn@...>
Hello! I'm new to ruby-talk, and mostly new to ruby. I'm making a document
[#1551] Ruby thread scheduling buglet — Ian Main <imain@...>
[#1569] Re: Ruby: constructors, new and initialise — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1591] Certain char's not recognized by "." in regex? — Wes Nakamura <wknaka@...>
[#1592] Race condition in Singleton — Dave Thomas <Dave@...>
[ruby-talk:01564] Re: Ruby supported/distributed libraries--can all be used together?
The following message is a courtesy copy of an article that has been posted to comp.lang.misc as well. "Conrad Schneiker" <schneiker@jump.net> writes: > Let's say you have a really grandiose Ruby application that tries to > function as a general purpose assistant with respect to all the things that > the modules in the supported Ruby distribution can do. Let's say you have a > very fast file system and many 100s of megabytes of RAM. For purposes of > minimizing startup time, could _all_ the modules first be imported, then > initialized, and finally, could the process execution image at that point be > saved for subsequent restarting, at which point the main program would > proceed? Are there problems with dynamic linking of Ruby extensions and such > that would thwart any substantial time savings? Are there any modules that > set global variables in incompatible ways upon initialization? Well, Ruby modules are often not like this. Unlike (say) Perl, they often contain code that is meaningless in isolation, but that has to be mixed-n the other code. These modules do not have initialization per-se, they encapsulate abstract behavior. Now I guess to fit this scheme, you could pre-compile them all, and then save out the Ruby image that contained the symbol table and parse tree, making them instantly accessible to subsequent programs. But, I'm not sure this would be a major win. Two problems spring to mind: 1. The scheme relies on the OS caching an in-memory image of the mega-Ruby, so that start-up times are not compromised. On OSes that don;t do this, the scheme slows Ruby down, as all the unused stuff is loaded in each time. 2. You're adding a heap of unused stuff to the tables of global constants and variables. I don't know, but I'm guessing this will slow down name lookup to some extent. This overhead will apply to _all_ programs, from "Hello World" on up, regardless of whether they use the features. However, I *do* see merit in the scheme. If you want to bundle a Ruby application that uses a lot of library functionality, it would be easier to be able to ship one file, not twenty. Maybe having some kind of dump mechanism, a la TeX, would be useful in those circumstances. Dave -- Thomas Consulting. Innovative and successful developments with Unix, Java, C, and C++. Now in bookstores: The Pragmatic Programmer. www.pragmaticprogrammer.com/ppbook/