[#4076] Ruby/DL — Jamis Buck <jamis_buck@...>

I recently used Ruby/DL to create bindings to the SQLite3 embedded

40 messages 2005/01/03
[#4096] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/04

On Tue, Jan 04, 2005 at 02:53:49AM +0900, Jamis Buck wrote:

[#4099] Re: Ruby/DL — ts <decoux@...> 2005/01/04

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4119] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Wed, Jan 05, 2005 at 03:05:48AM +0900, ts wrote:

[#4120] Re: Ruby/DL — ts <decoux@...> 2005/01/05

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4125] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Thu, Jan 06, 2005 at 01:10:34AM +0900, ts wrote:

[#4116] Test::Unit::Collector::Dir won't work with code that modifies $LOAD_PATH — Eric Hodel <drbrain@...7.net>

Any test code that depends upon modifications of $: fails when used

10 messages 2005/01/05

[#4146] The face of Unicode support in the future — Charles O Nutter <headius@...>

Hello Rubyists!

47 messages 2005/01/06
[#4152] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/07

Hi,

[#4167] Re: The face of Unicode support in the future — Christian Neukirchen <chneukirchen@...> 2005/01/09

Yukihiro Matsumoto <matz@ruby-lang.org> writes:

[#4175] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/10

Hi,

[#4186] Re: The face of Unicode support in the future — Paul Brannan <pbrannan@...> 2005/01/11

On Mon, Jan 10, 2005 at 11:53:48PM +0900, Yukihiro Matsumoto wrote:

[#4192] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/12

Hi,

[#4269] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...>

19 messages 2005/01/18
[#4270] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/18

Hi,

[#4275] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...> 2005/01/19

[#4323] test/unit doesn't rescue a Exception — Tanaka Akira <akr@...17n.org>

test/unit doesn't rescue a Exception in a test method, as follows.

14 messages 2005/01/27
[#8773] Re: test/unit doesn't rescue a Exception — Tanaka Akira <akr@...> 2006/09/02

In article <87is5jb46q.fsf@serein.a02.aist.go.jp>,

[#8776] Re: test/unit doesn't rescue a Exception — "Nathaniel Talbott" <ntalbott@...> 2006/09/03

On 9/1/06, Tanaka Akira <akr@fsij.org> wrote:

[#8777] Re: test/unit doesn't rescue a Exception — Eric Hodel <drbrain@...7.net> 2006/09/03

On Sep 2, 2006, at 6:34 PM, Nathaniel Talbott wrote:

Re: Ruby/DL

From: Mathieu Bouchard <matju@...>
Date: 2005-01-06 11:23:43 UTC
List: ruby-core #4134
On Thu, 6 Jan 2005, Paul Brannan wrote:
> On Wed, Jan 05, 2005 at 03:05:48AM +0900, ts wrote:
> > >>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:
> If it were possible to dynamically generate C functions, there would be
> no limitation, and the only way I know to get rid of the limitation is
> to dynamically generate C functions.

There's this sort of code in GridFlow (found in RAA) to detect the CPU
type (in this case, the code is for the Pentium family incl Cx6,K6,K7,K8):

#include <stdio.h>
char get_cpuid[]={
	96,49,192,15,162,139,124,36,36,137,31,
	137,87,4,137,79,8,137,71,12,97,195};
main() {
	char result[16];
	int code;
	((void(*)(char*))get_cpuid)(result);
	code = ((int*)result)[3];
	result[12]=0;
        fprintf(stderr,"cpuid: name=\"%12s\", flags=0x%08x\n",
		result,code);
	return 0;}

The current problems with this approach are:

1. Even though through daily life I am not convinced that there exist more
than four types of CPUs (Pentium/AMD, PPC, ARM, PIC), some people hint to
me that SPARC is still on respirator and that there are subcultures for
fans of Alpha and Amiga and PDP11 and such, who really want to use Ruby
;-) How many CPU types _really_ need to be supported to be considered
portable?

2. Are there any OS'es that block execution of data-segments? IIRC, the
i386-family supports such permission flags, but I don't know which OS'es
use it for real. (Linux doesn't...)

3. The above code was generated using NASM and then f.read.unpack.join.  
If done dynamically this means starting a new process. However if the
patterns to be generated are simple/focused enough, it can be done fully
within a C and/or Ruby program without essentially rewriting an assembler
from scratch...

_____________________________________________________________________
Mathieu Bouchard -=- Montr饌l QC Canada -=- http://artengine.ca/matju



In This Thread