unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Brian Woodcox <bw@InSkyData.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 36033@debbugs.gnu.org
Subject: [bug#36033] Add Smalltalk Pharo VM
Date: Sat, 1 Jun 2019 09:08:27 -0600	[thread overview]
Message-ID: <FE90B5E5-01E3-47C4-940C-774A23F74A19@InSkyData.com> (raw)
In-Reply-To: <877ea5fnih.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4640 bytes --]

Thanks Ludo,

My comments are below.

> On Jun 1, 2019, at 7:23 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> Hello,
> 
> Thanks for working on this, and congrats on your first package, which is
> not an easy one!  :-)
> 
> Some preliminary comments:
> 
> Brian Woodcox <bw@inskydata.com> skribis:
> 
>> From 49683e04e51cd904571008fa7979a3f58ae0134c Mon Sep 17 00:00:00 2001
>> From: "Brian C. Woodcox" <bw@InSkyData.com>
>> Date: Fri, 31 May 2019 13:14:54 -0600
>> Subject: [PATCH] Add pharo-vm package
> 
> [...]
> 
>> +(define %url "https://github.com/OpenSmalltalk/opensmalltalk-vm.git")
> 
> My understanding (but I’m no expert) is that this is a VM that can run
> Pharo bytecode, but it’s not “the” Pharo VM.  Is it correct?

More info —> https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result/PharoTour/PharoTour.html
“1. The virtual machine (VM) is the only component that is different for each operating system. The VM is the execution engine (similar to a JVM). It takes Pharo bytcode that is generated each time user compiles a piece of code, converts it to machine code and executes it. Pharo comes with the Cog VM a very fast JITing VM. The VM executable is named:”

> 
>> +(define-public pharo-vm
>> +  (package
>> +    (name "pharo-vm")
> 
> Consequently, it looks like this should be called ‘opensmalltalk-vm’,
> no?
> 
Not exactly —> https://github.com/pharo-project/pharo-vm

“Dear user, we have move PharoVM development to OpenSmalltalk-VM, please go there if you are looking for building a VM.”

In the OpenSmalltalk-VM repository they have build scripts for different vm’s such as squeak, pharo, etc..

So this is to distinguish the one we are packaging.

>> +    (arguments
>> +     `(#:tests? #f ;; no tests available
> 
> Or maybe there’s a special command to run them?
> 
>> +               ;; add symlinks
>> +               (symlink (string-append (assoc-ref %build-inputs "libgit2") "/lib/libgit2.so")
>> +                        (string-append out "/lib/pharo/" pharo-version "/libgit2.so"))
>> +               (symlink (string-append (assoc-ref %build-inputs "libssh2") "/lib/libssh2.so")
>> +                        (string-append out "/lib/pharo/" pharo-version "/libssh2.so"))
>> +               (symlink (string-append (assoc-ref %build-inputs "openssl") "/lib/libssl.so")
>> +                        (string-append out "/lib/pharo/" pharo-version "/libssl.so"))
>> +               (symlink (string-append (assoc-ref %build-inputs "freetype")"/lib/libfreetype.so.6")
>> +                        (string-append out "/lib/pharo/" pharo-version "/libfreetype.so.6")))
> 
> Those symlinks look somewhat inelegant to me.  :-)

Me too, unfortunately, Pharo won’t run without (most of) these.  I didn’t dig deep enough in the code, but if they made some changes, I am pretty sure the symlinks could be done away with.  I found in some cases that pharo found a couple of libraries in the store during the build process.

My hope is that other Pharo users might use Pharo in Guix and maybe this issue can be resolved over time.
> 
> Could we instead arrange so that the VM searches for those files in
> their right place?  Often that involves substituting things like
> “libfoo.so” in the code with the corresponding absolute file name (see
> for example how this is done for Racket.)

Possibly, I would have to look into it when I have some time.
> 
> Last question: does this Git checkout contain binaries, such as
> Smalltalk images?  IOW, is this being built entirely from source, or is
> it bootstrap from opaque binaries?  (I know that Pharo itself is or used
> to be bootstrap from very old Smalltalk images and that work was ongoing
> to get rid of them and have a nicer bootstrapping story.)

Everything in this vm is being built from source.

I skip this file —> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.linux64x64/pharo.cog.spur/build/mvm

And use the packages in Guix instead.

The images (which are separate from this) are definitely are built by bootstrapping which will be left to the user at this point.

I think if the developers and users were using Guix, they would enjoy it, as I have a script that will automatically populate the version and date values from any commit.  And it could be installed as a separate package.

P.S. I am very new to Smalltalk as well.  Just started using it a couple of months ago and thought it would be great if it was on Guix.
> 
> Thank you,
> Ludo’.

[-- Attachment #2: Type: text/html, Size: 8559 bytes --]

  reply	other threads:[~2019-06-01 15:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31 19:46 [bug#36033] Add Smalltalk Pharo VM Brian Woodcox
2019-05-31 23:30 ` Brian Woodcox
2019-05-31 23:33 ` Brian Woodcox
2019-06-01 13:23 ` Ludovic Courtès
2019-06-01 15:08   ` Brian Woodcox [this message]
2019-06-13  8:46     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FE90B5E5-01E3-47C4-940C-774A23F74A19@InSkyData.com \
    --to=bw@inskydata.com \
    --cc=36033@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).