[#3741] Re: Why it's quiet -- standard distribution issues — Aleksi Niemel<aleksi.niemela@...>
I think it's the feature of the mailing list archive to create a threads of
[#3756] RE: XMP on comments — Aleksi Niemel<aleksi.niemela@...>
> require "xmp"
[#3766] modulo and remainder — Dave Thomas <Dave@...>
[#3776] Kernel.rand — Aleksi Niemel<aleksi.niemela@...>
How about defining:
[#3781] Widening out discussions — Dave Thomas <Dave@...>
[#3795] Re: Array.uniq! returning nil — Aleksi Niemel<aleksi.niemela@...>
> As matz said in [ruby-talk:3785] and Dave said in [ruby-talk:1229],
Hi, Aleksi,
[#3823] Re: Array.pick — Aleksi Niemel<aleksi.niemela@...>
> > Just a general comment--a brief statement of purpose and using
[#3827] JRuby? — Aleksi Niemel<aleksi.niemela@...>
Is there or will there be Ruby equivalent of JPython?
[#3882] Re: Array.uniq! returning nil — Aleksi Niemel<aleksi.niemela@...>
> |look too strange, confusing, or cryptic. Maybe just @, $, %, &.
Hi,
[#3918] A question about variable names... — Dave Thomas <Dave@...>
[#3935] If your company uses Pallets, Skids, Boxes, Lumber, etc. — pallets2@...
[#3956] Tk PhotoImage options — andy@... (Andrew Hunt)
Hi all,
[#3971] Thread and File do not work together — "Michael Neumann" <neumann@...>
following example do not work correctly with my ruby
[#3986] Re: Principle of least effort -- another Ruby virtue. — Andrew Hunt <andy@...>
> Principle of Least Effort.
Hi,
[#4005] Re: Pluggable functions and blocks — Aleksi Niemel<aleksi.niemela@...>
Aleksi makes a question:
[#4008] Ruby installation instructions for Windows — Aleksi Niemel<aleksi.niemela@...>
I had to write these instructions for my friends. I thought it might be nice
[#4043] What are you using Ruby for? — Dave Thomas <Dave@...>
On 15 Jul 2000 22:08:50 -0500,
Hi,
[#4057] Re: What are you using Ruby for? — Aleksi Niemel<aleksi.niemela@...>
Johann:
[#4082] Re: What are you using Ruby for? — Aleksi Niemel<aleksi.niemela@...>
[#4091] 'each' and 'in' — hal9000@...
I just recently realized why the default
[#4107] Re: 'each' and 'in' -- special char problem? — schneik@...
[#4114] Method signature - a question for the group — Dave Thomas <Dave@...>
[#4139] Facilitating Ruby self-propagation with the rig-it autopolymorph application. — Conrad Schneiker <schneik@...>
Hi,
[#4158] Getting Tk to work on Windows — "Michael Neumann" <neumann@...>
Hi....
[#4178] Partly converted English Ruby/Tk widget demo working. — Conrad Schneiker <schneik@...>
Hi,
[#4234] @ variables not updated within method? — Hugh Sasse Staff Elec Eng <hgs@...>
Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
On 27 Jul 2000, Dave Thomas wrote:
[#4267] Ruby.next, Perl6, Python 3000, Tcl++, etc. -- Any opportunities for common implementation code? — "Conrad Schneiker" <schneiker@...>
Hi,
"Conrad Schneiker" wrote:
[ruby-talk:04267] Ruby.next, Perl6, Python 3000, Tcl++, etc. -- Any opportunities for common implementation code?
Hi, While listening to a performance of List's piano transcription of Beethoven's 6 symphony, I thought of combining the following themes of (1) open source, (2) "there's more than one way to do it", (3) a suggestion that Perl6 consider supporting multiple syntaxes, and (4) the MS .net idea of common multi-language-friendly support libraries. Given that Perl6 looks like it will be the next big rewrite to occur in the Perl, Ruby, Python, Tcl, etc., range of languages, would it be possible to do this in such a way that there could be a common core of libraries that could be used by the next generation of all of these languages? Would a common Unicode regular expression processing library be possible? I think everyone who isn't using mark and sweep garbage collection will want to eventually do so, so maybe there is something here that could also be factored out into a common implementation library. Maybe likewise for bytecode generation and packaging programs into single self-contained executables. Would a common generalized interface for doing C-extensions be feasible to do in a way that would be mutually satisfactory to Perl6, Ruby.next, and Python 3000? This would further make possible for language-specific modules to share their underlying C code Such a development might have other interesting synergies. For example, Tk development seems to have preceeded at a snail's pace for the last several year. If Tk provided an interface following a new standard common extension mechanism, perhaps more of the effort that has previously gone into <whatever>/Tk or <whatever>/<non-Tk-portable-GUIs> would go into Tk itself, to everyone's mutual benefit. I'm not sure if any of the above ideas are feasible and desirable, but if anyone can think of some way to render them such, we have a brief window of opportunity that may not reoccur for many years. For convenience of reference, we might call such a system "osl.net" (for open source languages). Some organizations such as O'Reilly and ActiveState already have overlapping interests in Perl and Python, and so might have some natural interest in promoting osl.net, if it were feasible. Conrad