Another Lead Special!!

2001-01-05 Thread leads4yourgroup44


Lead Special!! After Christmas Prices!!  Pre-Qualified Prospect For Your Business!!


http://www.geocities.com/lgbleads4ever/redirect1.htm



Re: A decouvrir

2001-01-05 Thread regis rampnoux


On 05-Jan-01 jirong wrote:
> Sorry, I am linux.tnfsh.tn.edu.tw server administer.
> There is no [EMAIL PROTECTED] here.
> I don't know why he can send mail use this.

No it is a french company.
I have send an email to his provider. (was rapidsite)



-- 
   [EMAIL PROTECTED] http://regisr.regix.com/
Le mag: http://www.regix.com/



Re: perl script in gimp for Windows : is it possible ?

2001-01-05 Thread Marc Lehmann

On Fri, Jan 05, 2001 at 11:13:00AM +0200, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> of people who don't care building GLib or GTK+, but do want to build
> *other* GTK+ applications. They are the the ones that sometimes ask
> "where is gtk-config?".
> 
> > (c:\gnu\gtk+ required ;)
> 
> If it only was so easy... I can easily imagine that a potential GTK+

But wouldn't it be possible to make a gtk-config.bat? Given the
estristcion to use the same compiler as used to build gtk+ this should be
easily doable.

> > yes, but msvc isn't and when you pick, e.g. activestate as your perl then
> 
> Umm, huh? Gcc-produced code (from C source) is binary compatible with
> MSVC-produced. (As long as you use the -fnative-struct switch to gcc.)

The problem is that the compilers themselves are not compatible:

- msvc lacks good C support (long long), so perl might define I64 as __long or
  something which gcc might glady ignore :(
- gcc uses different commandline syntax, so whatever gtk-config outputs might
  not be soemthing that the compiler likes.
   
> OK, great. I will first try to get Gimp-Perl running without Gtk-Perl
> then.

Just hammer bugs on me and I'll (try to) fix them ;) Thanks!

> configure, and libtool on Win32. At least it's much faster. You can
> imagine how slowly auto* and libtool run on Win98, or cygwin hosted on
> Win98 even.

No, I can't, although I heard that the fork-emulation would be slow.
However, running configure for gimp on unix takes too long, so but
usually my machine is too slow ;)

> (PS. When I considered using a Perl running under cygwin, I was on the
> wrong track. Cygwin is its own operating system in a way, so using
> cygwin-hosted tools to build for Win32 is a cross-compilation. It
> isn't possible to cross-compile Perl modules, is it?)

Well, perl modules use whatever they are told by ExtUtils::MakeMaker,
which could be abused to do cross-compiling. But just like configure, most
modules will want to run the resulting exectables, which is not possible
with a cross compile, so it WILL be easier to not even try it.

But mingw32 + cygwin (for the shell utils only) should work, no?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: perl script in gimp for Windows : is it possible ?

2001-01-05 Thread Paolo Molaro

On 01/05/01 Marc Lehmann wrote:
> [Note: I CC:'ied this as well as tor's original mail to the current gtk
> maintainer, which is Paolo Molaro <[EMAIL PROTECTED]>]

I didn't get the original mail from Tori, but I got it from the
archive anyway...

> The most difficult one would indeed be activestate (the dominant perl),
> since activestate is ported closely to windows (it is the "better" port in
> that sense) and all of the extension problems (e.g.) get real, although
> the makefiles that perl itself generates should be fine.

Using the same compiler for perl, gtk+ and gtk/perl is the first step
to narrow down the possible compilation problems

> > - Makefile.PL wants to use gtk-config. No such on Win32. (How could
> >   there be one? On Win32, people typically don't build GTK+
> >   themselves, but fetch the headers and libraries
> 
> The same, of course, is true for the gimp. most people who build gimp
> would be able to build gtk as well ;)
> 
> In any case, gtk-perl does, indeed, use a lot of unix functionality so
> building that one without cygwin will require !CHANGES!.

Yep, cygwin should be the easiest route, though I don't know if it has
other issues (I don't use windows and don't plan to to try it out:-).
That said, I'll integrate the patches needed to make it work, just
make them against cvs HEAD (module gnome-perl in the gnome cvs).

> > - ActiveState's Perl is built with MSVC. Its MakeMaker thus produces a
> >   Makefile for nmake, that uses cl to compile and link to link. Oh
> >   well, that is not so bad in itself, I have MSVC available at work,
> >   and, ehh, I might have a copy at home also.
> 
> This is, of course, not solvable in any case. Changing the compiler means
> that all the autodetected stuff goes wrong. This also means that the
> compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the
> same. We have a lot of problems with this (obvious for me but not others
> it seems), e.g. on IRIX where the preinstalled perl is compiled with the
> commercial sgi compiler but most people only have access to gcc (which is
> not compatible).

Most of the command line options and command names can be changed
using makefile variables, but it's a pain neverless.

> >   #defines and stuff to hide the GLib versions. Unfortunately there
> >   are lots of those .xs files that need to have the same stuff
> >   inserted. Oh well, just manual work.
> 
> The better option IMHO would be to make glib (source available!)
> compilable against perl, as a compatibility measure on win32. I am not

Seconded: maybe check if perl on win32 includes a #define for opendir
or something like that and conditionally #define the symbols in glib.h.

> sure qwether sources for activestate's port are available and even if, it
> requires a non-free compiler.
> 
> > - Some X11-backend specific stuff present in Gtk-Perl. Have to #ifdef
> >   those out, but in a way that is still compatible with GTK+ 1.2,
> >   which didn't have several backends, and doesn't define
> >   GDK_WINDOWING_X11. Gtk-Perl also uses some GDK functions that don't
> >   exist any longer.
> > 
> > At this point I bailed out again... I have better things to do, like,
> > eh, sleep?
> 
> If you have patches, I am quite sure the gtk-perl people will be very
> intereste din them, even if they only partially solve the problem by
> making it compile for example.

Yep, please send me the patches you have. I have been requested
several times about gtk-perl for windows, but no one ever sends patches:-)
I don't use windows, but I'd love gtk-perl working on win32!

> > (I am not promising that I will hack any more on Gtk-Perl on Win32
> > anytime soon...)

Every step brings us closer to the target:-)
Please do contribute your changes so that someone else
doesn't have to redo them if you don't have time to continue
working on it.
Thanks!
lupus

-- 
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED]  Monkeys do it better



Re: the Gimp 1.2.0 for windows ?

2001-01-05 Thread Peter Kirchgessner

Hi Bennet,

maybe you did not pick up the right file. You need the file
gimp-setup-20001226.zip. This will unzip to a single file
gimp-setup-20001226.exe . Start this file to start the installation.

--Peter

[EMAIL PROTECTED] wrote:
> 
> On  5 Jan, Bennett Keith Portnet wrote:
> 
> > Sorry to bug you, I found you name and email address in the GIMP files !
> 
> > I downloaded the GIMP 1.2.0 (for Windows ?!) from Tucows.
> > It has been uncompressed into a file on my hard drive.
> > (I am running Windows NT)
> > NOW WHAT DO I DO TO GET IT RUNNING ?
> > I can't find a file that runs it !
> 
>  No idea, I have no Windows. I'll forward this mail to the
>  developpers mailinglist. Maybe someone knows an answer
> 
> --
> 
> Servus,
>Daniel

-- 
Peter Kirchgessner
http://www.kirchgessner.net
mailto:[EMAIL PROTECTED]




Re: A decouvrir

2001-01-05 Thread Andreas Jaekel

Hi Chris,

> I got the same message with my domain name attached to the end. Very
> strange.

The sender didn't give a domain name at all and so yours is automatically
inserted by your mail transfer agent.

Greetings,
 Andy
-- 
Andreas Jaekel, CableCats - Foest, Jaekel, Tegethoff GbR
http://www.cablecats.de  Tel.: 030 - 916 11 77 3



Re: A decouvrir

2001-01-05 Thread Chris Brown

I got the same message with my domain name attached to the end. Very
strange.

chris

-- 
Chris the Christianfreak
http://christianfreak.com

BE ALERT (The world needs more lerts...)





Re: perl script in gimp for Windows : is it possible ?

2001-01-05 Thread Hans Breuer

At 01:07 05.01.01 +0100, Marc Lehmann wrote:
>
>> - ActiveState's Perl is built with MSVC. Its MakeMaker thus produces a
>>   Makefile for nmake, that uses cl to compile and link to link. Oh
>>   well, that is not so bad in itself, I have MSVC available at work,
>>   and, ehh, I might have a copy at home also.
>
>This is, of course, not solvable in any case. Changing the compiler means
>that all the autodetected stuff goes wrong. This also means that the
>compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the
>same. We have a lot of problems with this (obvious for me but not others
>it seems), e.g. on IRIX where the preinstalled perl is compiled with the
>commercial sgi compiler but most people only have access to gcc (which is
>not compatible).
>
At least the win32 "C" compilers are exchangeable quite well (even gcc has
learned to use -fnative-struct). Though there probably will arise problems
with different posix emulations. Mixing allocators between binaries from
different compiler (c-runtimes) does no good as well ...

The common case to build gtk+, etc. on win32 are hand-written makefiles.

>>   #defines and stuff to hide the GLib versions. Unfortunately there
>>   are lots of those .xs files that need to have the same stuff
>>   inserted. Oh well, just manual work.
>
>The better option IMHO would be to make glib (source available!)
>compilable against perl, as a compatibility measure on win32. I am not
>sure qwether sources for activestate's port are available and even if, it
>requires a non-free compiler.
>
Although Perl may rule the world, I would rather appreciate to not make
glib and all Perl compatible, but go the other way around, if any.

>> [...]
>> Maybe it would be better to use a Perl running on cygwin? That would
>> help a couple of the issues above.
>
>Certainly. Also not concentrating on gtk-perl but instead on gimp-perl
>would also help.
>
But wouldn't gimp-perl without gtk-perl loose most of it's charme ?

>> [...]
>OTOH, the main gimp makefile also uses test and a lot of unix-things. Is
>gimp not build using autoconf on win32?
>
Nope. See above.

>> and make sure I am not duplicating somebody else's work in progress,
>> and to ask if he has done any more work on Gtk-Perl since 0.6123. (This
>
>There was, however, I am quite sure nobody ever tried to port it to
>win32. At least not to a non-unix-like target (mingw32 or msvc).
>
I have tried, but it's so long ago, that I would need to search my 
backups to see what problems finally stopped it. If I recall correctly:
I got that far, that the main problem was a crashing MSVC compiler. 

At that point I decide to port pygtk and pygimp instead. BTW: They are 
available at http://hans.breuer.org/ports

>> (I am not promising that I will hack any more on Gtk-Perl on Win32
>> anytime soon...)
>
> [...]

At the moment the most promising approach appears to write a generic
perl to python translator :-)

Hans
 Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to 
get along without it.-- Dilbert



Re: how to use *.pfb-fonts?

2001-01-05 Thread Max Moritz Sievers

On Thursday 01 January 1970 01:00, Miles O'Neal wrote:
> Did you read through the FAQ, and follow the directions
> there for getting the fonts to work?
>
>http://www.rru.com/~meo/gimp/

I can't find the information there. However it seems now that I can use 
most of them. 

Max Moritz Sievers



Re: the Gimp 1.2.0 for windows ?

2001-01-05 Thread egger

On  5 Jan, Bennett Keith Portnet wrote:

> Sorry to bug you, I found you name and email address in the GIMP files !
 
> I downloaded the GIMP 1.2.0 (for Windows ?!) from Tucows.
> It has been uncompressed into a file on my hard drive.
> (I am running Windows NT)
> NOW WHAT DO I DO TO GET IT RUNNING ?
> I can't find a file that runs it !

 No idea, I have no Windows. I'll forward this mail to the
 developpers mailinglist. Maybe someone knows an answer

-- 

Servus,
   Daniel




Re: A decouvrir

2001-01-05 Thread jirong

Sorry, I am linux.tnfsh.tn.edu.tw server administer.
There is no [EMAIL PROTECTED] here.
I don't know why he can send mail use this.

 Jirong.
 




Re: perl script in gimp for Windows : is it possible ?

2001-01-05 Thread Tor Lillqvist

(See the end of message for Perl-relevant stuff, mostly digression first...)

On Fri, Jan 05, 2001 at 02:44:42AM +0200, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
>> producing a glib-config or gtk-config for people who download the
>> headers and prebuilt libs (in a zipfile), and install them in some
>> random place, and then would like to build some application.

Marc writes:
> Well, I thought that people capable of building gimp (in win32 this is not
> common ;) could build gtk+ as well, but in general (when gimp for win32 is
> being built by millions of users wordlwide) this is a hindrance.

Umm, I didn't mean that there were more people building GIMP
themselves that people building GLib or GTK+. But there are a number
of people who don't care building GLib or GTK+, but do want to build
*other* GTK+ applications. They are the the ones that sometimes ask
"where is gtk-config?".

> However, when it is possible to create downloadable binary distributions
> for linux it should not be that difficult to do so for windows as well
> (c:\gnu\gtk+ required ;)

If it only was so easy... I can easily imagine that a potential GTK+
developer which uses different workstations each day doesn't want to
put anything on any C: drive, but instead in his home directory, which
could be something simple like H:\, or complex like
\\redmond42\lusers\b\billgates.

>> and MSVC. (One difference is that gcc uses long long and the LL suffix
>> for long long literals, MSVC uses __int64 and the i64 suffix. The

Of course, in GLib- and GTK+-using code one should use G_GINT64_CONSTANT, 
so the point is moot anyway.

> It's just a matter of time for msvc to support C, though, so even this
> difference will soon vanish (or so).

You mean "to support C99"? Probably. I should check the (free beer)
beta of the next MSVC that is said to be included with the .NET
(sheesh) SDK.

>> On Win32, the mingw gcc *is* compatible with MSVC (for C; C++ is

> yes, but msvc isn't and when you pick, e.g. activestate as your perl then

Umm, huh? Gcc-produced code (from C source) is binary compatible with
MSVC-produced. (As long as you use the -fnative-struct switch to gcc.)

>> I haven't looked at Gimp-Perl yet, I kinda assumed a working Gtk-Perl
>> is a prerequisite.

> No. gimp-perl will detect (not using autoconf this time) wether Gtk is
> installed and will not try to do anything graphically if it isn't. This means
> thast many scripts will run with default values (somewhat useful) and the
> ones depending on Gtk will not be instaled, but scriptability is still 100%.

OK, great. I will first try to get Gimp-Perl running without Gtk-Perl
then.

> >  > OTOH, the main gimp makefile also uses test and a lot of unix-things. Is
> >  > gimp not build using autoconf on win32?
> > Nope.

> Now that's cool! Is that an art form? ;)

More like a form of masochism. Actually, it is easier in a way to keep
manually written makefiles up-to date than struggling with auto*,
configure, and libtool on Win32. At least it's much faster. You can
imagine how slowly auto* and libtool run on Win98, or cygwin hosted on
Win98 even. All those sed, awk, test etc invocations do slow it
down. (It is especially irritating to wait for a configure run to
finish when you consider that one already *knows* what the result of
all the frigging checks configure is running will be. It is not like
the features in Win32 and MS's C runtime would change under you
between configure runs.)

But anyway, I do realise that the Right Thing is to use the normal
configuration mechanism, and will move to it, eventually.

> As I understand it, mingw is just a gcc that threw away POSIX and
> gives you a "standard" win32 build environment.

It is a bit debatable what mingw is. Personally I would define it as
simply gcc and binutils running on Win32, producing code for Win32,
with no cygwin or other POSIX emulation in sight. Some people talk
about a "mingw runtime" but I don't like that, mingw-produced apps
should and do work just like MSVC-produced ones, they don't use any
"mingw runtime".

> I looked at the "standard" README.win32
> and it seems to be a truely native port, it works with borland, msvc AND:

> Mingw32 with GCC  version 2.95.2 or better

>   The last of these is a high quality freeware compiler.  Support for it
>   is still experimental.  (Older versions of GCC are known not to work.)

> I think this sounds like the right perl to use.

Indeed. I will switch...

(PS. When I considered using a Perl running under cygwin, I was on the
wrong track. Cygwin is its own operating system in a way, so using
cygwin-hosted tools to build for Win32 is a cross-compilation. It
isn't possible to cross-compile Perl modules, is it?)

--tml



GIMP 1.2.0 RPM files

2001-01-05 Thread Kevin Cozens

Greetings, all!

I have uploaded the GIMP 1.2.0 RPM files to
http://fantasia.galaxynet.com/~casey/gimp/v1.2/

You will find both .src.rpm files and .i386.rpm files. These files were
created using the original 1.2.0 tar.gz file. The binary RPM files were
built on a Redhat 6.2 machine. At the above site is a .tar.gz file which
has the update spec file and two patch files for those who like to roll
their own.

Cheers!

Kevin.  (http://www.interlog.com/~kcozens/)

Internet:kcozens at interlog.com   |"What are we going to do today, Borg?"
  or:ve3syb at rac.ca  |"Same thing we always do, Pinkutus:
Packet:ve3syb@va3bbs.#scon.on.ca.na|  Try to assimilate the world!"
#include |  -Pinkutus & the Borg