Low Cost Easy to Use Conferencing

2002-01-07 Thread [EMAIL PROTECTED]

Long Distance Conference Calls 

Quality Service/Lowest rate in the industry


Click here to find out more:
http://www.geocities.com/site763/




If you wish to be removed from our list,
Follow the instructions at the bottom of 
the following page.

___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd



Translators in Ruby

2002-01-07 Thread Wolfgang Jährling

Hello, world!

I want to write translators in the Ruby programming language, so I thought
about what would need to be done to achive this. Probably I got several
things wrong, so please add your comments and thoughts.

First, one general issue with Ruby:

- Ruby is not threadsave. When using Ruby and POSIX threads, the Ruby
  interpreter crashs badly. It would be very surprising if it would work
  with cthreads, but afaik nobody actually tried this up to now. Ruby has
  its own threading model, which is working with select (). This means that
  if you want to write a multithreaded translator in Ruby at all, you will
  have no other choice than to use Rubys own implementation. So, would
  implementing a function which does essentially the same thing as libports'
  ports_manage_port_operations_multithread () does, but with Ruby threads,
  be a good idea (i.e. a solution for this problem)?

Then, there are basically two ways how one could connect the world of Ruby
with the translator world:

- The first one might be seen as a quick hack by some people, but it's the
  way one usually extends Ruby. One would write a wrapper for libtrivfs, one
  for libnetfs and so on. Interfacing Ruby and C is pretty simple. This is
  not a "generic" solution however, and one would need to modify the wrapper
  whenever the interface of the underlying library changes. In Ruby, it is
  common to write wrappers for libraries and I think one could get it
  working in a short time (see below). One would do the interface in Ruby
  different than in C, since Ruby is a 100% objectoriented language, like
  SmallTalk, so a C-like interface would not make much sense in Ruby, but
  nevertheless using the libraries should simplify the job by an order of
  magnitude. We also would end up with an interface that has much in common
  with the existing C interface, which means it would be easier for
  programmers to switch between languages. The Ruby hello translator at
   should demonstrate what I
  mean. Yes, I already wrote a Ruby module for libtrivfs, which you may find
  at . I did this for three
  reasons: a) I wanted to exercise using both libtrivfs and Ruby's nice C
  interface. b) I wanted so see if it is as easy to do as I thought (It
  turned out to be even easier!) c) Now we can claim that it's possible to
  write translators in Ruby. :) I did _not_ assume that this is the way it
  should be done and I have no problem with throwing away the code if the
  Hurd hackers think that this approach is wrong.

- The second way would be to extend MiG (or flick or something else). One
  could for example add an option to flick/MiG which causes it to produce
  two additional C source files. The first would provide wrapper functions
  that first convert Ruby types to C types and then call the C
  implementation that is normaly produced by flick/MiG; this would be the
  client part. The second file would implement the S_* (server) functions.
  This automatically produced implementation would convert the C types to
  Ruby types and call a Ruby method with an identical name, passing it the
  converted arguments. A Ruby script would then load such a module and
  implement those functions and we would be able to use a Ruby script as a
  Mach server. Of course, nobody would like to use this interface directly
  in Ruby, so we also need a wrapper here, but in this case it could be
  written in Ruby and it would only depend on the interface definitions in
  $(HURD)/hurd/*.defs, which probably won't change often, if at all. A huge
  disadvantage in my eyes is that one would end up reimplementing large
  parts of the existing libraries in Ruby. Maybe this would be even harder
  to maintain than a thin C layer, maybe not, I don't know.

What would you suggest?

Cheers,
GNU/Wolfgang

-- 
Wolfgang Jährling <[EMAIL PROTECTED]> `-:._ "Omnis enim res, quae dando
Debian GNU/Linux user && Debian GNU/Hurd user  `-:. non deficit, dum habetur
Hurd Hacking Guide - http://stdio.cjb.net/hhg.html )  et non datur, nondum
www.debian.org || www.gnu.org || hurd.gnu.org _,-:' habetur, quomodo habenda
["Accelerate your PC - with 9.81 m/s^2."] ,-:'   est." --> fsfeurope.org <--

___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd



¸»ÇÏ´Â ½ºÄµ Ææ ¿µ¾î»çÀüÀÔ´Ï´Ù. ^^ (±¤°í)

2002-01-07 Thread juna26
Title: Á¦¸ñ¾øÀ½

















  
»õÇØ º¹ ¸¹ÀÌ ¹ÞÀ¸¼¼¿ä  ´õ ºü¸£°í, ´õ ÆíÇÏ°Ô,
native ¸ñ¼Ò¸®¿Í ÇÔ²² ¶æÀÌ 1-2ÃÊ ¸¸¿¡ È­¸é¿¡ ¶ß´Â ¿µ¾î»çÀüÀ̶ø´Ï´Ù. 
ÅäÀÍ, ÅäÇÃ
½ÃÇè ÁغñÇÒ ¶§, ¿µ½Å¹®À̳ª ¿ø¼­ ÀÐÀ» ¶§
ÀÌÁ¦ ¿µ¾î½ÃÇèÁغñ ...ÃֽŠ½ºÄµ »çÀüÀ¸·Î ´õ È¿°úÀûÀ¸·Î Áñ±â¼¼¿ä 
 ½ºÄµ »çÀü Äü¼Å³Ê¸®°¡ º¸À̽º2·Î ¸¶Áö¸· ¾þ±×·¹ÀÌµå µÇ¾ú½À´Ï´Ù. 
¼Óµµ°¡ ¾ÆÁÖ »¡¶óÁ³½À´Ï´Ù. Á¤È®ÇÕ´Ï´Ù. »ý»ýÇÑ ¹ßÀ½À¸·Î µé·ÁÁÝ´Ï´Ù.
¿µÇÑ »çÀüÀº ±âº»ÀÌ°í ¿µ¿µ»çÀü , ¿µ¾î ÈÞ´ë¿ë ½ºÄ³³Ê·Îµµ È®ÀåÇÒ ¼ö ÀÖ½À´Ï´Ù. 
  

  
À̽º¶ó¿¤ À§ÁîÄÞ ½ºÄµÇü ÀüÀÚ»çÀü 
Äü¼Å³Ê¸® º¸À̽º 2
  ±ÛÀ» Àдٰ¡ 
³ª¿À´Â ¸ð¸£´Â ¿µ¾î ´Ü¾î
»çÀü µÚÁö°Å³ª ÀÚÆÇ µÎµå¸®´Ùº¸¸é ¹ú½á ¹®¸ÆÀº ²÷¾îÁöÁÒ
 ´Ü¾îÀ§¿¡ Çü±¤Ææó·³ ±×¾îÁÖ¸é 1-2Ãʸ¸¿¡ »çÀü ¶æÀÌ
¶ß°í,,
¿ø¾î¹Î ¸ñ¼Ò¸®·Î ´Ü¾î¸¦ Àоî ÁÖ´Â ½ºÄµÆæÇü ÀüÀÚ »çÀüÀÔ´Ï´Ù.

µè±â ½ÃÇè Áغñ¿¡µµ ÁÁ°í..±¹³» ÃÖÀú°¡ÀÔ´Ï´Ù. 

 
more... 














±¹³» À¯Åë
: À§ÁîÄÚ¾Æ 
http://qq.co.kr,

 
[EMAIL PROTECTED]  
¼­¿ï½Ã °­³²±¸ »ï¼ºµ¿ ¹«¿ª¼¾ÅÍ 3304È£  02-551-3099(tel)
02-551-3100(fax) ¡Ø ÀÎÅͳݻ󿡼­ ÁÖ¼Ò¸¦
º¸°í µµ¿ò µÉ±îÇÏ¿©
º¸³»µå¸³´Ï´Ù

.









 



___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd


Re: Architectual questions on storeio and libstore

2002-01-07 Thread Marcus Brinkmann

On Mon, Jan 07, 2002 at 02:48:37PM -0800, Galchin Vasili wrote:
> 
> Hello,
> 
> I have been reading (with great joy!!!) the storeio and libstore
> 
> code. I do have some questions. What is the best venue to
> 
> ask.

If it's more a user question, here.  If it is more development stuff,
[EMAIL PROTECTED]  See you there?

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd



Architectual questions on storeio and libstore

2002-01-07 Thread Galchin Vasili
Hello,
    I have been reading (with great joy!!!) the storeio and libstore
code. I do have some questions. What is the best venue to
ask.
Regards, Vasili
 Do You Yahoo!?
Send FREE video emails in Yahoo! Mail.

Re: RUNPATH. (Was: Shared libraries. How are they found?)

2002-01-07 Thread Marcus Brinkmann

On Mon, Jan 07, 2002 at 01:57:37PM +0100, "Wikström, Mårten" wrote:
> Sorry for not paying enough attention to the FAQ. (although it is under the X 
>section).
> But, the question remains. What good does the RUNPATH bring, that can't be done with 
>LD_LIBRARY_PATH?

The solution to shared libraries in non-standard places is RPATH.  RPATH has
the disadvantage that it can not be overridden by a user.  So you can only
use a different library by recompiling the program with a different rpath or
replacing the file path.

RUNPATH in the upcoming standard will be overridable and thus the right
thing to do.  It is compiled into the binary, so no environment setting is
needed.  This is important because LD_LIBRARY_PATH must be ignored for suid
programs like xterm.  So xterm only works correctly with RPATH or RUNPATH.

ld.so.conf was never part of the ELF standard, as far as I know.  It is a
GNU/Linux specific extension.

The other solution btw is to have all Debian GNU/Hurd libraries in /lib.
This can be achieved either by giving all programs an empty prefix (or
linking the prefix to /, like it is done with /usr), or to shadow all lib
directories to the system lib directory.

> > BTW, how does ld.so relate to the exec server? Who is 
> > responsible of what?

As far as I can see, the exec server just loads and runs the binary.  The
code to fire up the linker and bring into the shared libraries is compiled
into each executables:

$ strings /bin/ls | grep ld.so
/lib/ld.so

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd



THIS IS NOT A SALES AD: IT IS A BID ANOUNCEMENT FOR WEB HOSTS.

2002-01-07 Thread Manager

THIS IS NOT A SALES AD:  IT IS A BID ANOUNCEMENT FOR WEB HOSTS.  
We procured your contact information from your website to request information on 
potential website hosting.
(We apologize if this bid notice reached you in error!) 
To be removed from our mailing list please hit reply and put REMOVE in the subject 
line!


ATTENTION: Accepting HOSTING bids through 1-7-2002.

We need a partner for our sites (1000s to go global) and our clients (to be offered as 
a service 
from our design & solutions site.
 
We will need to be able to offer a full range of features such as:
SQL server Database support.(Microsoft Technologies to be supported)
Should be able to execute ASP pages.
1 mg to 200 MB package Drive Space 
Unlimited FTP Updates MTS Access needs to be provided
Real Time Statistics on the site activity to be available online
MS Front Page 2000 Visual InterDev 6.0 CONNECTIVITY access
SSL Aliased Certificate for security for use of credit cards.
SQL 7.0 Access ADO Access
SMTP, IMAP4, POP3, APOP E-Mail protocol Support
Fax server to be installed on IIS
COM Components working in conjunction with fax server to be registered & installed.
Telephone line for fax server line connectivity to be provided.
T1 or better a perk.  
Shopping cart or onsite shopping compatibility:  or in existence is better.
Network and Unix available
99.?%  Uptime
tech assistance
co-brandable
Front Page extension availability for our clients
full support for streaming recorded Audio or Video
CGI-Support
Security pages
Email accounts
Fully e-commerce
Backup Support 


We plan a very large global business and will be able to expand your services to other 
countries through our local office locations.  We will consider offering some of your 
other 
services such as domain registration or fax services. 

Our decision of a partner will be based upon services offered, reliability and package 
prices.We will 
consider bids for individual sites or dedicated servers.

Please send any sales offers to our staff at: [EMAIL PROTECTED] call 
1-877-473-2141 with 
questions (M-F 9-5 eastern) 

Note bid “hosting bid” and list packages, features, your uptime rate in the past, # of 
years in business, 
phone, email, contact name, prices, and alternative services and options.  We will 
consider multiple 
companies if bids for partial services are equitable.

We are:  Heera Industries International, NetMateWorld, New Jersey and worldwide. We 
will get back with 
you AFTER we have had time to compare packages, please quote your lowest price.  You 
will not be 
given a chance to re-quote unless we receive matching low offers.

___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd



{dir,file}_notice_changes wrapper in libshouldbeinlibc?

2002-01-07 Thread Moritz Schulte

Hi there,

wouldn't it be a good idea to put libc-level wrappers around the
{dir,file}_notice_changes interfaces into libshouldbeinlibc?

That way it would be easy for programs to make use of these Hurd
features without having to use the Hurd RPCs themselves.

I'm thinking about for example something like:

error_t
request_dir_change_notifications ((void) (*callback) (dir_changed_type_t change_type,
  char *name),
   char *dirname);

Which would request dir notifications for DIRNAME and call *CALLBACK
with the according information whenever a notification message arives.

Is something like that the right way[tm]?

I just don't know how such a function would be implemented correctly
in libshouldbeinlibc, since it would have to wait for incoming
messages on a port.

Just an idea.

moritz
-- 
[EMAIL PROTECTED] - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06  B501 0841 2D7B 6F98 4199

___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd



RUNPATH. (Was: Shared libraries. How are they found?)

2002-01-07 Thread "Wikström, Mårten"

Sorry for not paying enough attention to the FAQ. (although it is under the X section).
But, the question remains. What good does the RUNPATH bring, that can't be done with 
LD_LIBRARY_PATH?

/Mårten

> -Original Message-
> From: Wikström, Mårten 
> Sent: Monday, January 07, 2002 1:14 PM
> To: [EMAIL PROTECTED]
> Subject: Shared libraries. How are they found?
> 
> 
> How do you tell ld where the shared libraries can be found? 
> Under linux you can use ldconfig, but it says it is obsolete 
> under Hurd. I had to set LD_LIBRARY_PATH, but I doubt this is 
> the _right_ way to do it.
> 
> BTW, how does ld.so relate to the exec server? Who is 
> responsible of what?
> 
> thanks,
> 
> Mårten

___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd



Shared libraries. How are they found?

2002-01-07 Thread "Wikström, Mårten"

How do you tell ld where the shared libraries can be found? Under linux you can use 
ldconfig, but it says it is obsolete under Hurd. I had to set LD_LIBRARY_PATH, but I 
doubt this is the _right_ way to do it.

BTW, how does ld.so relate to the exec server? Who is responsible of what?

thanks,

Mårten

___
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd