Brandon Van Every | 1 May 2007 04:10
Picon

Re: scheme, builds, and virtual appliances



On 4/21/07, bryan rasmussen <rasmussen.bryan <at> gmail.com> wrote:
hi,

I was reading the complaints of various luminaries over in the scheme
hackers list as to why would one want to choose Chicken? I guess I
would want to choose Chicken because I don't want to get dirty with C,
but I want the portability of C.

C is portably not just across platforms it is portable across
languages and applications as platforms. Many languages allow
interaction with C in some way, probably because the languages need to
drop down to the C level to do some things.

if you want to write a driver or extension module for python you may
have to use Swig or distutils to get it to work with Python, that is
to say there are a number of specialized applications you need to have
working together.

The same thing if you were to bind erlang to C libraries
http://www.erlang-projects.org/Public/news/erlang_driver_toolki/view

Now a virtual appliance is a prepackaged virtual machine that has
everything setup that one needs to get started running a particular
suite of applications, tools on an OS or similar things:
http://www.vmware.com/vmtn/appliances/

what about Virtual appliances that are setup up with not just Scheme,
Swig etc. but requisite tools and eggs to use Chicken for writing, say
as one example Erlang drivers? To do this for a good number of
scenarios, OS's etc. to demonstrate Chicken's portability as a tool
for writing C easily and efficiently?


I'm not understanding what you're getting at.  The VMWare page seems to be about shipping your choice of OS to enterprise customers.  If you're not doing enterprise development, I don't see how the concept applies, or has any kind of economy of scale. 

I've wondered if it would make sense to ship a game with its own OS to consumers, so that I wouldn't have to be enslaved to Windows issues or whatever.  But the reality is, I can't see consumers cranking up a DVD just to play a game on their PC.  That's very MS-DOS era usability, running 1 program on your PC at a time, and consumers aren't going back.  It would make more sense to do it on a console, where people are used to just plugging in a CD or DVD and having it work.  I worry though that the boot times might be completely unacceptable.  Modern console users just plug their game in and start playing, it's an instant entertainment sort of thing.

So the first question is, under what conditions does shipping an OS to a customer make any kind of sense?  I don't think you've really answered this in your musings above.  Perhaps you could elaborate.

The second question is, who's going to do all the support work for such a thing?  People doing enterprise development are investing big bucks in their undertakings.  Does such an effort make sense for you personally?  It definitely doesn't make sense for the Chicken community.  We are merely a small community of volunteers, working on whatever projects are of most benefit to us personally.  The community resources for pursuing very abstract "work everywhere" infrastructure simply don't exist.  I can't even get people to do modest amounts of bughunting for the Visual Studio 2005 Express compiler.


Cheers,
Brandon Van Every

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
John Cowan | 1 May 2007 07:10

Re: CMake build

Brandon Van Every scripsit:

> It suggests that CMake has bugs on Linux, and that people would have to
> resolve them by posting on the CMake mailing list.  There could be 2
> separate bugs here.  At least now we have confirmation that the "make
> install" bug isn't just on Felix's box.

Okay, I've done a whole bunch of Linux installs under various conditions,
and I've found that the problem arises if and only if the installation is
going to replace the EXTANT_CHICKEN it was configured to use.  If you keep
a private copy of chicken-static around and always use that, you never
have a problem with rebuilding on install.  What's more, when building
from a tarball, where EXTANT_CHICKEN is irrelevant, there is no problem.

Does *that* suggest anything to anyone?

--

-- 
John Cowan    cowan <at> ccil.org    http://ccil.org/~cowan
The present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature.  --The Catholic Encyclopedia, s.v. "telepathy" (1913)
John Cowan | 1 May 2007 07:26

Re: scheme, builds, and virtual appliances

Brandon Van Every scripsit:

> I've wondered if it would make sense to ship a game with its own OS to
> consumers, so that I wouldn't have to be enslaved to Windows issues
> or whatever.  But the reality is, I can't see consumers cranking up
> a DVD just to play a game on their PC.

That's not what VMWare is about.  The VMWare Player (which can be
installed on Linux or Windows, and is free as in beer) allows you
to execute a foreign operating system concurrently with the host one.
Thus one can run Windows on Linux or vice versa, or Windows XP on Windows
2000, or FreeBSD on Windows or Linux, etc. etc. etc.

The disk and memory of the guest OS are represented on the host by a set
of files which can be copied from one host to another by CD or DVD or FTP
or whatever.  So instead of porting a Linux program to Windows, one can
provide a stripped down version of Linux including the program as a VMWare
image, and then anybody can run it from Windows using the VMWare Player.
Guests can run in a window of the host or using the full screen.

In principle, you could do this the other way about, distributing Windows
guests, except that most people don't have Windows licenses to distribute
in this fashion, as you need a separate Windows license for every guest
copy of Windows.

--

-- 
They do not preach                              John Cowan
  that their God will rouse them                cowan <at> ccil.org
    A little before the nuts work loose.        http://www.ccil.org/~cowan
They do not teach
  that His Pity allows them                         --Rudyard Kipling,
    to drop their job when they damn-well choose.   "The Sons of Martha"
Alejandro Forero Cuervo | 1 May 2007 07:37

Fix for bug in url egg

Hey, Kon.

I just made a fix for a simple bug I found in the url egg that made
url-encode unusable when CHARLIST is specified.  This resulted in
revision 4013.

Alejo.
http://azul.freaks-unidos.net/
Alejandro Forero Cuervo | 1 May 2007 07:49

Re: Fix for bug in url egg


I realized there was a separate bug that also affected url-encode
(though the other bug was in uri-encode, this one is in url-encode
instead).  I fixed it, creating revision 4014.

Alejo.
http://azul.freaks-unidos.net/
bryan rasmussen | 1 May 2007 12:51
Picon
Gravatar

Re: scheme, builds, and virtual appliances

I just wanted to note that I didn't specify what OS I would want
chicken distributed on. One of my favorite (and one of the most
downloaded) Virtual Appliances is the virtual browser which comes with
Firefox on Ubuntu and some preset security configurations -
http://www.vmware.com/vmtn/appliances/directory/browserapp.html

However where Windows is concerned I thought it was the user that
installed the image that had to prove they had a Windows license? At
any rate whenever I make an image of Windows and then move it to a new
VMplayer it wants me to confirm that I have a license for running that
operating system. I may have drawn the wrong conclusion from this
however.

Cheers,
Bryan Rasmussen

On 5/1/07, John Cowan <cowan <at> ccil.org> wrote:
> Brandon Van Every scripsit:
>
> > I've wondered if it would make sense to ship a game with its own OS to
> > consumers, so that I wouldn't have to be enslaved to Windows issues
> > or whatever.  But the reality is, I can't see consumers cranking up
> > a DVD just to play a game on their PC.
>
> That's not what VMWare is about.  The VMWare Player (which can be
> installed on Linux or Windows, and is free as in beer) allows you
> to execute a foreign operating system concurrently with the host one.
> Thus one can run Windows on Linux or vice versa, or Windows XP on Windows
> 2000, or FreeBSD on Windows or Linux, etc. etc. etc.
>
> The disk and memory of the guest OS are represented on the host by a set
> of files which can be copied from one host to another by CD or DVD or FTP
> or whatever.  So instead of porting a Linux program to Windows, one can
> provide a stripped down version of Linux including the program as a VMWare
> image, and then anybody can run it from Windows using the VMWare Player.
> Guests can run in a window of the host or using the full screen.
>
> In principle, you could do this the other way about, distributing Windows
> guests, except that most people don't have Windows licenses to distribute
> in this fashion, as you need a separate Windows license for every guest
> copy of Windows.
>
> --
> They do not preach                              John Cowan
>  that their God will rouse them                cowan <at> ccil.org
>    A little before the nuts work loose.        http://www.ccil.org/~cowan
> They do not teach
>  that His Pity allows them                         --Rudyard Kipling,
>    to drop their job when they damn-well choose.   "The Sons of Martha"
>
>
> _______________________________________________
> Chicken-users mailing list
> Chicken-users <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>
John Cowan | 1 May 2007 15:50

Re: scheme, builds, and virtual appliances

bryan rasmussen scripsit:

> However where Windows is concerned I thought it was the user that
> installed the image that had to prove they had a Windows license? At
> any rate whenever I make an image of Windows and then move it to a new
> VMplayer it wants me to confirm that I have a license for running that
> operating system. I may have drawn the wrong conclusion from this
> however.

No, it sounds like you are right.  However, in an economic sense it
doesn't matter whether the seller or the buyer pays the Microsoft
tariff; the bottom line is that Windows images cost a lot more.

--

-- 
The first thing you learn in a lawin' family    John Cowan
is that there ain't no definite answers         cowan <at> ccil.org
to anything.  --Calpurnia in To Kill A Mockingbird
bryan rasmussen | 1 May 2007 17:01
Picon
Gravatar

Re: scheme, builds, and virtual appliances

yeah, but in a distributing images sense it does make a difference, at
least for someone that does have rights to use multiple Windows
installations.

Anyway I was just thinking it would make an easy testing halfway point
for people.

Cheers,
Bryan Rasmussen

On 5/1/07, John Cowan <cowan <at> ccil.org> wrote:
> bryan rasmussen scripsit:
>
> > However where Windows is concerned I thought it was the user that
> > installed the image that had to prove they had a Windows license? At
> > any rate whenever I make an image of Windows and then move it to a new
> > VMplayer it wants me to confirm that I have a license for running that
> > operating system. I may have drawn the wrong conclusion from this
> > however.
>
> No, it sounds like you are right.  However, in an economic sense it
> doesn't matter whether the seller or the buyer pays the Microsoft
> tariff; the bottom line is that Windows images cost a lot more.
>
> --
> The first thing you learn in a lawin' family    John Cowan
> is that there ain't no definite answers         cowan <at> ccil.org
> to anything.  --Calpurnia in To Kill A Mockingbird
>
Brandon Van Every | 1 May 2007 21:16
Picon

Re: CMake build



On 5/1/07, John Cowan <cowan <at> ccil.org> wrote:
Brandon Van Every scripsit:

> It suggests that CMake has bugs on Linux, and that people would have to
> resolve them by posting on the CMake mailing list.  There could be 2
> separate bugs here.  At least now we have confirmation that the "make
> install" bug isn't just on Felix's box.

Okay, I've done a whole bunch of Linux installs under various conditions,
and I've found that the problem arises if and only if the installation is
going to replace the EXTANT_CHICKEN it was configured to use.  If you keep
a private copy of chicken-static around and always use that, you never
have a problem with rebuilding on install.  What's more, when building
from a tarball, where EXTANT_CHICKEN is irrelevant, there is no problem.

Does *that* suggest anything to anyone?


Ew.  Not a case use I remember thinking about, so wouldn't shock me if there's something wrong.  I'll look into it.


Cheers,
Brandon Van Every


_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
John Cowan | 1 May 2007 21:27

Re: CMake build

Brandon Van Every scripsit:

> Ew.  Not a case use I remember thinking about, so wouldn't shock me if
> there's something wrong.  I'll look into it.

It's actually a pretty common circumstance when you are updating
your Chicken regularly from the darcs head.  In my case,
Chicken is in /usr/local, so the EXTANT_CHICKEN winds up being
/usr/local/bin/chicken-static.  Then I darcs pull, ccmake, make, and
make install, so the new version of chicken-static winds up overwriting
the old.  That's where the Linux version can't cope.

A straightforward fix would be to always copy EXTANT_CHICKEN to /tmp (or
C:\windows\temp) and run it from there.

--

-- 
John Cowan  http://ccil.org/~cowan  cowan <at> ccil.org
All "isms" should be "wasms".   --Abbie

Gmane