Nabble - Squeak - Spoon

Re: Spoon 2a13 release

2008-06-23T11:20:31Z

On Mon, Jun 23, 2008 at 11:06:09AM -0700, Craig Latta wrote:

>
> Hi Matthew--
>
> > when will [the next Spoon release] be ready for use? Solstice was 3
> > days ago, and Craig hasn't been on irc any lately. I hope he's ok.
>
> I'm fine, perhaps a little too much so. :) Summer, by way of band
> rehearsals and socializing, has invaded my routine for the last two
> weeks; it's going to be a bit longer. Having just missed a deadline, I'm
> not eager to name another date yet, I just want to push on and say "here
> it is". Unfortunately, I don't have time to talk on IRC in addition.

Cool. I'm glad you have some time to do music again. Have fun.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

re: Spoon 2a13 release

2008-06-23T11:06:09Z

Hi Matthew--

> when will [the next Spoon release] be ready for use? Solstice was 3
> days ago, and Craig hasn't been on irc any lately. I hope he's ok.

I'm fine, perhaps a little too much so. :) Summer, by way of band
rehearsals and socializing, has invaded my routine for the last two
weeks; it's going to be a bit longer. Having just missed a deadline, I'm
not eager to name another date yet, I just want to push on and say "here
it is". Unfortunately, I don't have time to talk on IRC in addition.

-C

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Spoon 2a13 release

2008-06-23T10:42:35Z

Hi. when will Spoon 2a13 be ready for use? Solstice was 3 days
ago, and Craig hasn't been on irc any lately. I hope he's ok.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Use Cases

2008-05-14T09:12:26Z

In my dev8.04.1 working image I had manually applied some fixes from a separate Workspace to make toggle-break-on-entry work again from the method pane contextual menu.
I forget at the moment which ones they were. As well i applied most of the stuff from installer.pbwiki.com. Plus a lot of other stuff.

When upgrading to dev8.05.1 I would like to be able to easily compare what is different from dev8.04.1 in order to know which fixes have already been included in the new release, and therefore I do not have to manually include anymore.

This also applies to the scripts on installer.pbwiki.com. Which of the fixes in the scripts have already been applied in the new dev release and I will no longer need to do.

Maybe this would be as simple as applying my complete list of fixes in the new release, but having the ones already there be flagged so I can remove them from the new installer script for fixes. A full status report of some sort would be handy to evaluate the 3-way diff between what's there in new, what's there in previous, and what you intend to install now.

Thx,
Ken G. Brown
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: request for use cases

2008-05-12T19:56:20Z

Thanks, Ken!

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: request for use cases

2008-05-09T13:55:32Z

I suspect these are well covered already however, here are some use cases I can see, not in pseudo-code form yet, just a brain dump:

- Of course start from absolute minimal image, scriptable loading of everything you want.

- Tools to automate remembering of things you add during day to day work, so that you can reload everything again by script eg. when migrating your working image contents to a new base version..

- When attempting to load a new package, I would like to be notified if the package already exists in the image and whether or not any parts of it have changes in the new. I don't want to just blindly reload a package on top of what was already there.

- When I attempt to load a new package, and something happens during the install, eg. a DNU appears, I would like to be able to be able to completely undo the install and be guaranteed that everything is restored to an identical state to before I started installing that particular package.

- When installing a new package that contains new versions of Classes or methods which are already existing in the image, I would like all previously installed software to continue to work with the previously existing Classes and methods as was the case before the install of the new package was attempted, unless explicitly desired to update previous senders to the new versions. There should be tools to allow study of the existence of multiple versions of the same named Classes and methods currently 'live' and selectively be able to move some or all incidences of using old versions to new. eg. if Flow could have been loaded even though it changed some core functionality, while maintaining use of all older versions at the same time, it would have been much easier to test out Flow for new development while having confidence everything existing would still work as before. Eventually when desired, migration to all new could be done with appropriate tools.
This would overcome the majority of fear people have of moving forward and breaking backward compatibility.

- Any previously installed version of a package should be completely unloadable to a previous state as though it was never loaded in the first place. If some other package had subsequently utilized some of the loaded package items since it was installed, this should be flagged at the time of attempted unload and the conflicting items could be moved to the package still requiring them. Other options may be needed here too such as creating another new package to hold the still required items that could not be unloaded. Loading and unloading should be guaranteeably undoable so that you can always have confidence there are no side effects.

- A facility for tracking certain ongoing modifications to the image would be beneficial, to be done in such a way that the current state of your working image could be reconstructed from a known starting point such as a new release version. Think taking a release 3.10, running a script to load all the additions to make it a dev image, then continuing on reloading all the stuff you had been working on since the last time you started from a fresh release image. This is currently possible with Installer scripts but it is a manual process to keep adding pertinent work to saved copies of Workspaces, your local Monticello Repository and your custom installer script.

- loading and unloading packages should work the same whether on not you have Internet connectivity as along as you have local copies of required items available. Tools might be required to verify that your image can be restored from local copies to facilitate working in offline mode. Synch tools may be required here. eg. you start working on a new package on your mobile computer while lounging at your mountain cabin or when at the campground in your RV. You have no Internet available there. You get home and you update/sync your more powerful desktop computer so you can do more work there more conveniently with your large screen real estate. You only have dial-up there so you continue working mostly offline but on the desktop system rather than the laptop. You need convenient way to keep the laptop and desktop systems in sync.
At some point you find a high speed connection (eg at Starbucks) so you post your current work from the laptop to an online server somewhere. Later you finally return to the office where you only have a desktop computer and you sync that as well so you can continue your development. This should all be easy and convenient to keep all sync'ed whether or not you have Internet connectivity. Of course the required synch paths will need to be there when needed. eg. laptop to online repository.

- A variation of this theme would be taking everything with you on a usb storage device to another computer altogether.

Thx,
Ken G. Brown

>Message: 1
>Date: Thu, 03 Apr 2008 13:42:35 -0700
>From: Craig Latta <craig@...>
>Subject: request for use cases
>To: spoon@...
>Message-ID: <47F5413B.7060100@...>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>Hi--
>
> Naiad, Spoon's module system, is starting to work. I'm working on
>a solstice release (2008-06-20). I'd like to collect desired use cases
>from interested folks. Please let me know of any that come to mind.
>Unwanted scenarios you've encountered with other change management
>systems would be useful, too. Please use the Spoon list for now, I'm
>sure we can come up with some wiki-ish place for them soon.
>
> I'll start with one:
>
> - Create a class.
> - Create a method for that class.
> - Create another method for that class.
> - Create a second version of the first method.
> - Remove the first method.
> - Add an instance variable to the class.
> - Create a third version of the first method.
> - Remove the class.
> - Reinstall the original version of the class. The class appears
>with its original original instance variables and the methods it had
>just before the new instance variable was added.
>
> It seems to be me that English descriptions of use cases could
>serve as pseudo-code versions of tests, developed into actual code later
>on. Also, most of these tests will probably be composed of several
>simpler tests (as above).
>
>
> thanks!
>
>-C
>
>--
>Craig Latta
>improvisational musical informaticist
>www.netjam.org
>Smalltalkers do: [:it | All with: Class, (And love: it)]

<>
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

the Spoon list is now carried by gmane

2008-04-03T14:01:25Z

Hi--

It appears the Spoon list is now carried by Gmane[1]. Thanks to
Ken Causey, Simon Michael, and the people at Gmane for making this
happen! (If I forgot anyone, please accept my apologies.)

thanks,

-C

[1] a handy way to read mailing lists with an NNTP news reader,
http://gmane.org

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

request for use cases

2008-04-03T13:42:35Z

Hi--

Naiad, Spoon's module system, is starting to work. I'm working on
a solstice release (2008-06-20). I'd like to collect desired use cases
from interested folks. Please let me know of any that come to mind.
Unwanted scenarios you've encountered with other change management
systems would be useful, too. Please use the Spoon list for now, I'm
sure we can come up with some wiki-ish place for them soon.

I'll start with one:

- Create a class.
- Create a method for that class.
- Create another method for that class.
- Create a second version of the first method.
- Remove the first method.
- Add an instance variable to the class.
- Create a third version of the first method.
- Remove the class.
- Reinstall the original version of the class. The class appears
with its original original instance variables and the methods it had
just before the new instance variable was added.

It seems to be me that English descriptions of use cases could
serve as pseudo-code versions of tests, developed into actual code later
on. Also, most of these tests will probably be composed of several
simpler tests (as above).

thanks!

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Naiad use case: issue tracking

2008-03-26T07:42:13Z

Based on my previous comment, I realized it seems that bug-fixes
will not look like they do today in a Naiad context. Due to the
non-use of files in naiad, it seems that an external issue
tracker may not even be an option! Therefore, we should consider
this in the design.

How would issue-tracking work in a system like naiad? First, we
should define what kind of issues we are interested in:
1. Bug reports (manual and/or automatic): an end-user finds a
problem, fills out a form with relevant info, and may or may
not follow-up to it. Walkbacks could make this
semi-automatic. There is already a button somewhere in squeak
to email a bug report to the mailing list, but I don't
remember where.
2. Code Requests: A developer encounters code exhibiting
ugliness, non-existence, or general lameness, and submits an
issue that said code should be cleaned up.
3. Meta-issues: Issues to keep track of other issues, such as
Mother-of-X issues, issues to be included in a release,
relationships/dependencies between issues, duplicate reports,
etc.

One way this could work is that an issue would be an item/module
in the history database, which would hold comments somehow. As
the issue marches toward completion, it would sprout
dependencies on new code modules which would be loaded when
someone syncs with the issue, the idea being that these
dependencies resolve the issue when loaded.

If the issue is not-trivial, multiple-passes at a fix would be
made. This would use whatever mechanism naiad already has in
place to keep track of old versions of stuff.

I don't know if naiad already supports relationships among
entities, but I suspect it does. Issues could:
- DEPEND on code modules, other issues, or anything
- DUPLICATE other issues, meaning that all comments/submissions
on one issue should be redirected to another, probably just by
convention
- RELATE to other entities. A way to mark relationships for the
benefit of future readers. No special meaning in code

It is not clear to me, being unfamiliar with naiad, whether this
scheme is necessary, overkill, or not already present. It is
also not clear whether this would be better-handled by something
already present but not naiad-aware, like Mantis or Gjallar. I
bring it up because all the issue trackers I have used expect
objects/patches to be files, which does not match with naiad at
all, and so are of lesser, if any, utility to naiad users.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Kettle use case: method alternatives

2008-03-25T14:07:10Z

Here is a use case that I think would be very useful when
porting code, especially small bug fixes, across forks. I have
wanted to add this to DeltaStreams.

You fix a bug in squeak.org, and it involves changing the #foo
method from:

foo
^ 1

to:

foo
self ensureWhizbangInitialized.
^ 1

Now, you realize that this bug needs to be fixed in Croquet as
well, where foo looks like:

foo
^ 2

So, you try loading the bug fix into Croquet, and, naturally, it
brings up a conflict that you must resolve, since the expected
previous method does not match the actual installed method. You
resolve it like:

foo
self ensureWhizbangInitialized.
^ 2

and forget about it, because the system has recorded this as an
alternative, and whoever fetches the bug fix in the future will
receive both versions and automatically choose the one that best
matches their fork and has the same previous method that you
had when you resolved the conflict.

I haven't really thought about how this would work if you needed
to specify alternative groups of methods, again dependent on
which fork you load code into.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Hydra/Spoon

2008-02-22T13:30:51Z

Hi--

I think there were some misconceptions about Spoon on the part of
both Igor and Andreas; I'll try to clarify.

Igor writes:

> ...i think, best would be to incorporate Spoon features to VM. As i
> understand (Craig, correct me if i'm wrong), a Spoon VM changes are
> incremental and not breaking any compatibility.

Andreas responds:

> I'm not sure which changes you mean. If it's about imprinting, I'm no
> fan of that. I don't want methods automatically transferred between
> images...

Imprinting is just the direct transfer of CompiledMethods from one
object memory to another (making source code, which in general is
ambiguous, an optional medium for behavior distribution). The scheme for
determining the content and timing of that transfer may vary.

One scheme is to transfer each method that a providing object
memory runs, immediately, to a consuming object memory (the case you
mention above, let's call it "session imprinting"). I see that as useful
in a presentation situation (at a conference, for example), where the
audience may want to receive the behavior the presenter is
demonstrating. Each recipient could then duplicate the demo later,
without having to spend any effort on installation. I think using this
facility, in coordination with *good unit tests* for the subsystem being
presented, would be very useful. But I wouldn't rely on it to organize a
system in normal development.

Another scheme, the one I'm working on now[1], is to organize all
the behavior of each system into clearly-delineated modules. Each module
can then imprint its methods onto a requesting system (nothing automatic
about it, necessarily). Each module can also describe its relationships
to other modules (dependency on other modules, containment of other
modules, etc.).

> ...I want tools that I can use in a remote image to load and edit code
> just like I do in the "main" image. With the end result being a
> well-defined set of packages that are designed to work together.

Right, this is what I intend.

Igor responds:

> I'm about marking oops while code running, to get a part of image
> which required to run your code and scrap the rest.

Andreas responds:

> Yes, and that's exactly what I'm no fan of ;-) In a realistic
> situation you'd really want to understand what is being used where -
> the fact that a particular method hasn't been touched during a
> particular run of the code is just as insignificant as the fact that
> during a debugging session you might touch code that isn't even in the
> product you're trying to design.

Again I think there's a misunderstanding here about the intended
purpose of a Spoon feature. Indeed, I never intended for "inert method
removal" (as I've been calling it) to be used frequently. I only
intended to use it once, to help derive the absolute minimal object
memory from which all other object memories would derive (there's still
some manual labor after that to get to the absolute minimal system).
After this has been done, and after there is a modularity mechanism to
enable the clear organization of larger systems, one shouldn't need this
facility anymore.

I suppose there will be a use for it whenever a system turns into
spaghetti (like Squeak is now :), but I think we can move past that.

Igor responds:

> Well, there is people who wish to see such capabilities, and if Spoon
> features orthogonal to your approach, then why not include them?

Andreas responds:

> ...I cannot see any situation in which someone would really want to
> rely on [inert method removal]. It seems to me that the approach is
> (as you said in an earlier email) a way to create smaller images
> "without much effort". I'm interested in the *hard* way of doing this
> (i.e., by going in and refactoring and removing things manually)
> because I think this is the only way in which it can be done in
> practice.

I think we're in agreement here. After creating a clearly minimal
object memory, and a module system for adding behavior while maintaining
clear organization, I'm interested in the hard work of deciding what the
content of those modules should be for the behavior we want to deploy. I
do think that session imprinting (defined above) could be useful for
finding a first approximation of what behavior is used by a subsystem
(e.g., Morphic).

> I just happen to think that the mechanism is fundamentally flawed and
> cannot possibly work the way in which people naively think it ought to
> work.

The mechanism, when used for its intended purpose, is sound. I
wholeheartedly agree that some have misunderstood its purpose.

> But be that as it may - the real question is this: Let's assume we
> have a tiny kernel image that is about 100k in size and that we can
> build up from. What good is the mechanism at this point? It seems to
> me that it is only useful to get to a small image but once this is
> achieved it's basically obsolete.

That is my fervent hope. :)

> And I'm definitely not in favor to modify the VM for something that
> will only have a very short window of usefulness.

Again, I think the changes do not increase the complexity of the
virtual machine in any meaningful way. These are minute changes to the
garbage collector, which is already so complicated that you can count
the number of people who even dare to look at it on one hand. :) (I'd
like to change that situation, by the way.) Furthermore, since the
usefulness of the changes during that short window is so high, and there
is the unfortunate possibility that the ability may be needed again in
the future, I think they would be justified even if they did impose some
significant increase in complexity.

Finally, the new garbage collector behavior is accessed through a
function interface which is separate from the normal one; the normal
garbage collection behavior is unaffected and the new behavior is
optional (one invokes fullGCDisardingInertMethods and
incrementalGCDiscardingStaleMethods instead of fullGC and incrementalGC.
In turn, these new functions invoke distinct mark phase behavior.

thanks!

-C

[1] This is "Naiad" (short for "Name and Identity Are Distinct"),
Spoon's module system. Naiad has been my prime motivation for Spoon
from the beginning; it's my attempt to resolve what I have always
seen as Smalltalk's biggest shortcoming: poor support for deployment
in general and modularity in particular.

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Workshop on Self-sustaining Systems (S3) 2008 -- Call for Papers

2007-12-13T04:39:51Z

[Call for Papers]

*** Workshop on Self-sustaining Systems (S3) 2008 ***

May 15-16, 2008
Potsdam, Germany
http://www.swa.hpi.uni-potsdam.de/s3/

-- Call for papers:

The Workshop on Self-sustaining Systems (S3) is a forum for discussion
of topics relating to computer systems and languages that are able to
bootstrap, implement, modify, and maintain themselves. One property of
these systems is that their implementation is based on small but
powerful abstractions; examples include (amongst others)
Squeak/Smalltalk, COLA, Klein/Self, PyPy/Python, Rubinius/Ruby, and
Lisp. Such systems are the engines of their own replacement, giving
researchers and developers great power to experiment with, and explore
future directions from within, their own small language kernels.

S3 will be take place May 15-16, 2008 at the Hasso-Plattner-Institute in
Potsdam, Germany. It is an exciting opportunity for researchers and
practitioners interested in self-sustaining systems to meet and share
their knowledge, experience, and ideas for future research and development.

-- Invited talk:

Ian Piumarta: Late-bound Object Lambda Architectures (Viewpoints
Research Institute, USA)

-- Submissions and proceedings:

S3 invites submissions of high-quality papers reporting original
research, or describing innovative contributions to, or experience with,
self-sustaining systems, their implementation, and their application.
Papers that depart significantly from established ideas and practices
are particularly welcome.

Submissions must not have been published previously and must not be
under review for any another refereed event or publication. The program
committee will evaluate each contributed paper based on its relevance,
significance, clarity, and originality. Revised papers will be published
as post-proceedings in the Springer LNCS series.

Papers should be submitted electronically via EasyChair at
http://www.easychair.org/conferences/?conf=s3 in PDF format. Submissions
must be written in English (the official language of the workshop) and
must not exceed 20 pages. They should use the LNCS format, templates for
which are available at http://www.springer.de/comp/lncs/authors.html.

-- Venue:

Hasso-Plattner-Institut (Potsdam, Germany)

-- Important dates:

Submission of papers: February 15, 2008
Author notification: April 11, 2008
Revised papers due: April 25, 2008

S3 workshop: May 15-16, 2008

Final papers for LNCS post-proceedings due: June 6, 2008

-- Chairs:

* Robert Hirschfeld (Hasso-Plattner-Institut Potsdam, Germany)
* Kim Rose (Viewpoints Research Institute, USA)

-- Program committee:

* Johan Brichau, Universite Catholique de Louvain, Belgium
* Pascal Costanza, Vrije Universiteit Brussel, Belgium
* Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium
* Stephane Ducasse, INRIA Lille, France
* Michael Haupt, Hasso-Plattner-Institut, Germany
* Robert Hirschfeld, Hasso-Plattner-Institut, Germany
* Dan Ingalls, Sun Microsystems Laboratories, USA
* Martin von Löwis, Hasso-Plattner-Institut, Germany
* Hidehiko Masuhara, University of Tokyo, Japan
* Ian Piumarta, Viewpoints Research Institute, USA
* David Ungar, IBM, USA

-- Registration fees:

Early (until April 18, 2008)
* Regular participants: EUR 160
* Students: EUR 80

Late (after April 18, 2008)
* Regular participants: EUR 170
* Students: EUR 90

--

Robert Hirschfeld
hirschfeld@...
www.hirschfeld.org
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: approaching Spoon

2007-11-19T12:16:09Z

On Mon, Nov 19, 2007 at 10:11:16AM +0100, Norbert Hartl wrote:

> Hi Matthew,
>
> today evening I decided to play once more with spoon.
> On the net I found your description about building a
> vm with naiad support.
>
> http://lists.squeakfoundation.org/pipermail/spoon/2007-July/000214.html
>
> I can't say I understand the whole spoon process. There are a lot
> of things floating around:
>
> 1. a modified image (spoon processor changes) to build a vm with naiad
> support
> 2. the naiad vm
> 3. minimal memory image
> 4. control image
>
> Maybe you are able to clarify some questions:
>
> - Is 1. needed after the vm is built?

I really have no idea what the right way to build the VM is. I
gave up trying spoon out of frustration with not being able to
build a VM for some purpose. I don't remember the details

> - What is the control image?

I believe this is a vanilla 3.9 image with naiad.st and naiad.pr
loaded. It's purpose was to try remotely browsing the contents
of the minimal memory image via its wormhole server. It needs a
VM that can run a 3.9 image and has the Flow plugin loaded.
Building such a VM made me crazy, and I never got it working.

> I thought it is sufficient to be able to run the memory.image in an
> interpreter simulator and to control the rest from the image of the
> interpreter simulator. Is that correct?

>From the interpreter simulator, you can do some debugging on the
low-level execution of the memory.image, like what process or context is
active, but not do anything high-level, like see smalltalk code
or execute smalltalk statements. The interface between the
interpreter simulator and the image is just the bytecodes and
the raw object format, so you can try to debug, but it is really
low-level.

The interpreter simulator really had nothing to do with the
problem I expressed in that email.

> However if I'm trying to run the memory image in the interpreter
> simulator the image eats my cpu and does nothing. All I can see
> is the "Relocating object pointers" Morph. My cpu goes on 100%
> and that's it.

That is all that is supposed to happen. The memory image has no
UI in it, so it does no screen drawing or anything. You should
be able to connect to the web server the minimal image is
running (don't remember what port; it's in the README)

> Did you make any progress since writing the post?

No, I haven't messed with spoon in a while. I am developing
DeltaStreams and plan on using that to make something cool with
spoon, naiad, and kettle when I have more code to fling around.

> thanks in advance,

Sure. Have fun

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: approaching Spoon (was "No webserver started when starting spoon")

2007-11-19T01:11:16Z

Hi Matthew,

today evening I decided to play once more with spoon.
On the net I found your description about building a
vm with naiad support.

http://lists.squeakfoundation.org/pipermail/spoon/2007-July/000214.html

I can't say I understand the whole spoon process. There are a lot
of things floating around:

1. a modified image (spoon processor changes) to build a vm with naiad
support
2. the naiad vm
3. minimal memory image
4. control image

Maybe you are able to clarify some questions:

- Is 1. needed after the vm is built?
- What is the control image?

I thought it is sufficient to be able to run the memory.image in an
interpreter simulator and to control the rest from the image of the
interpreter simulator. Is that correct?

However if I'm trying to run the memory image in the interpreter
simulator the image eats my cpu and does nothing. All I can see
is the "Relocating object pointers" Morph. My cpu goes on 100%
and that's it.

Did you make any progress since writing the post?

thanks in advance,

Norbert

On Fri, 2007-07-06 at 20:54 -0700, Matthew Fulmer wrote:

> On Fri, Jul 06, 2007 at 06:10:22PM -0700, Craig Latta wrote:
> >
> > Hi Norbert--
> >
> > > I saw videos where you showed a graphical browser for the memory of a
> > > remote image. That is pretty much of a functionality. I'd like to
> > > reproduce this as well. Aside from this I have absolutely no clue what
> > > is the status of spoon. Did I miss some important document? (I read
> > > the spoon book already and the netjam web site).
> >
> > I suspect so. The most important things to read are the Spoon
> > progress reports in the Spoon mailing list archives.
> >
> > > Btw. how do work with the spoon image? Do you bootstrap anything or
> > > are you running spoon in the simulator?
> >
> > Here's what I do:
> >
> > - I start the minimal Spoon memory.
>
> The memory.image distributed with spoon 2a12?
>
> > - I start a control memory (one with Naiad support in it).
>
> How do you make that? Which image version do you start with?
> Which VMMaker version do we need to make a vm with the proper
> support in it? How can we run an interpreter simulator using
> this VM? Do I need to go buy a mac? Which os?
>
> I know you have done more work in spoon than just a "Hello
> World" demo.
>
> Since there is nothing inside the memory.image distributed with
> 2a12, I need to run the interpreter simulator to see what it is
> doing and why it is halting. Here is what I tried on windows xp:
>
> - I downloaded http://damien.cassou.free.fr/squeak-dev/sq3.9-7067dev07.6.2.zip and ran it using naiad.exe distributed with spoon 2a12
> - I installed VMMaker-3.8b6.1 from universe
> - I downloaded http://squeakvm.org/win32/release/SqueakVM-Win32-3.10.4-src.zip and unzipped it
> - I filed in spoonProcessorChanges.st
> - I opened VMMakerTool, pointed it at SqueakVM-Win32-3.10.4\platforms
> - I set the platform to win32
> - I generated the source for the core and all plugins internally
> except for:
> - FileCopyPlugin
> - InternetConfigPlugin
> - LargeIntegersPlugin
> - LargeIntegersSimulator
> - MacMenubarPlugin
> - TestOSAPlugin
> - I tried running
> (InterpreterSimulatorLSB new openOn: '..\memory.image') test
> - It failed with MessageNotUnderstood: Bitmap>>swapBytesFrom:to:
>
> Should I be doing something differently? How do you do it?
>
> > - I establish a Wormhole connection from the control memory to the
> > minimal memory.
> > - I open a remote browser.
> > - I write code.
> >
> > (I suppose "NaiadPeer" or something like that would be a better
> > name than "Wormhole" and the like.)
> >
> >
> > thanks again,
> >
> > -C
> >
> > --
> > Craig Latta
> > www.netjam.org
> >
> >
> > _______________________________________________
> > Spoon mailing list
> > Spoon@...
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
>

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

SEGV during GC (was Re: Other>>module (was "Compiling Flow.so under linux"))

2007-09-14T03:03:08Z

I'm just about to walk out the door to work, but before I go I'll send
the stack trace I get running my spoon VM on my squeak-dev+naiad image,
just in case it provides a valuable clue. The VM dies in the GC. I'll
investigate further over the weekend, with luck.

(The location of the SEGV, gnu-interp.c:11796, corresponds to the first
occurrence of the line "header2 = longAt(oop1);" in the function
markAndTrace() in interp.c.)

Regards,
Tony

~/Squeak/spoon/building-from-scratch/sq3.9-7067dev07.09.1$ gdb /opt/spoon/bin/squeak
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
(gdb) run sq3.9-7067dev07.09.1.image
Starting program: /opt/spoon/bin/squeak sq3.9-7067dev07.09.1.image
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1210169680 (LWP 18218)]
Error while reading shared library symbols:
Cannot find new threads: generic error

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210169680 (LWP 18218)]
markAndTrace (oop=2022687948) at gnu-interp.c:11796
11796 header2 = longAt(oop1);
(gdb) bt
#0 markAndTrace (oop=2022687948) at gnu-interp.c:11796
#1 0x0805eddf in markAndTraceInterpreterOops () at gnu-interp.c:12250
#2 0x0805eedd in markPhase () at gnu-interp.c:12289
#3 0x0805f5d4 in fullGC () at gnu-interp.c:5101
#4 0x0805fa65 in sufficientSpaceAfterGC (minFree=2504) at gnu-interp.c:23434
#5 0x0806312c in primitiveNew () at gnu-interp.c:17703
#6 0x08054207 in dispatchFunctionPointer (aFunctionPointer=0x80630f0) at gnu-interp.c:4130
#7 0x08066cee in interpret () at gnu-interp.c:8104
#8 0x08052b0a in main (argc=Cannot access memory at address 0x1
) at /home/tonyg/Squeak/spoon/building-from-scratch/sq3.9-7067dev07.09.1/Squeak-3.9-8/platforms/unix/vm/sqUnixMain.c:1388
(gdb)
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Steps to a spoony VM

2007-09-14T02:37:34Z

Hi,

Craig Latta wrote:
> Yeah, looks like I left in a "3 halt" by mistake in
> Interpreter>>primitiveFail, which of course gets sent by a lot of other
> places. There's also a halt I was using during simulation in
> LargeIntegersPlugin>>noteMissingPrimitive:, which you noticed after
> translation to C (it should be removed before translation).
> [...]
> > - the call to cleanUpContexts [in
> That's a vestigial thing from 3.2 that I didn't catch, that line
> should just be removed.

Good to know. Thanks.

> > - the error generating LargeIntegersPlugin
> > - the nasty code in the generated LargeIntegersPlugin
> That happened because of the halt in LargeIntegersPlugin mentioned
> above, I assume.

It's possible - it didn't immediately seem to be related. I will try
generating the plugin in an image that doesn't have the spoon changes,
to see if it's an existing problem.

Regards,
Tony

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Other>>module (was "Compiling Flow.so under linux")

2007-09-14T02:35:17Z

Hi,

Craig Latta wrote:
> All messages to instances of Other are supposed to be forwarded by
> the virtual machine. Are you running with a VM that has remote messaging
> support (i.e., the Spoon VM you built)?

Ah, ok. I was actually running memory.image with my spoon VM, but the
control image with a stock-VM-plus-Flow.

I did try my spoon VM with the control image (Squeak-dev 3.9 + naiad),
but it loaded, gave a white screen with a smallish black rectangle in
the top left, and SEGVd. I guess my VM isn't yet quite correct. I'll try
finding out where it crashed, I suppose.

I'm glad to be making progress - it's quite exciting, getting closer to
being able to experiment with spoon!

Regards,
Tony

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

linking the pthreads library for Flow

2007-09-13T23:29:01Z

Hi Tony--

It's great that you were able to build a working Flow plugin for
yourself, but I'd like to be able to distribute pre-built Flow plugins
so that building it is optional. :) The one I included in the 2a12
release apparently loads the pthreads library dynamically, and
differences in the location of the pthreads library amongs different
Linux distributions was causing trouble.

Were you able to build the Flow plugin so that the pthreads
library is statically linked into it? How should I change my build tree
to make this happen? My current Unix build tree (the entire VM,
including the Flow plugin) is at [1].

thanks again!

-C

[1] http://tinyurl.com/2lqfxu (movedigital.com)

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

re: Steps to a spoony VM

2007-09-13T22:48:04Z

Hi Tony--

> Things that puzzle me:
>
> - the calls to halt ("halt(3)" appears a lot in interp.c)

Yeah, looks like I left in a "3 halt" by mistake in
Interpreter>>primitiveFail, which of course gets sent by a lot of other
places. There's also a halt I was using during simulation in
LargeIntegersPlugin>>noteMissingPrimitive:, which you noticed after
translation to C (it should be removed before translation).

> - the call to cleanUpContexts [in
> Interpreter>>primitiveSnapshotWithoutStaleMethods]

That's a vestigial thing from 3.2 that I didn't catch, that line
should just be removed.

> - the error generating LargeIntegersPlugin
> - the nasty code in the generated LargeIntegersPlugin

That happened because of the halt in LargeIntegersPlugin mentioned
above, I assume.

Thanks for going through the building process, and for taking notes!

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

re: Other>>module (was "Compiling Flow.so under linux")

2007-09-13T22:25:38Z

Hi Tony--

> I now run into the problem where
>
> Smalltalk
> at: #ExampleWormholeServer
> put: (WormholeServer atPort: 9999)
> succeeds,
>
> ExampleWormholeServer connectToPort: 7777 atHostNamed: 'localhost'
> succeeds,
>
> but
>
> OtherBrowser openOnWormhole: ExampleWormholeServer clients any
> fails, with an error
>
> MessageNotUnderstood: Other>>module

All messages to instances of Other are supposed to be forwarded by
the virtual machine. Are you running with a VM that has remote messaging
support (i.e., the Spoon VM you built)?

thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Steps to a spoony VM (was Re: Compiling Flow.so under linux)

2007-09-13T13:33:03Z

Below are my notes from building a VM capable of running memory.image.
Note that I ran VMMaker three times - the first two times are not
needed! I was just proceeding in small steps to do things like look at
diffs etc etc.

Things that puzzle me:

- the calls to halt ("halt(3)" appears a lot in interp.c)
- the call to cleanUpContexts
- the error generating LargeIntegersPlugin
- the nasty code in the generated LargeIntegersPlugin

Regards,
Tony

== COMPILATION NOTES ==

Get http://squeakvm.org/unix/release/Squeak-3.9-8.src.tar.gz
Get http://netjam.org/flow2a5.tar.gz
Get
http://www.netjam.org/flow/releases/current/bits/flow2aPrimitiveSources.zip
Get http://damien.cassou.free.fr/squeak-dev/sq3.9-7067dev07.09.1.zip

Unzip sq3.9-7067dev07.09.1.zip somewhere convenient.
- Untar Squeak-3.9-8.src.tar.gz into the resulting
sq3.9-7067dev07.09.1 directory.
- Unzip spoon.2a12.linux.zip as well
- Unzip flow2a5.tar.gz, and rename "flow/" to "flow2a5/"
- Unzip flow2aPrimitiveSources.zip, and rename "flow/" to "flow2a/"

Edit flow2a/platformSpecific/linux/Makefile.in, commenting out the "cp
Flow.so $(plgdir)" line.

Open the image in the sq3.9-7067dev07.09.1 directory.

Open Package Universe Browser
- Choose "--System--", "VMMaker", "3.8b6.1"
- Middle-click "3.8b6.1", choose "select this version"
- Click "install selection"

Much code downloading and installation happens.

Open VMMaker
- click "Find Path" at the end of the "Path to platforms code" line
- Choose your current working directory's subdirectory "Squeak-3.9-8".
- Click OK
- Click "Find platform" on the "Platform name" line.
- Choose "unix" from the menu that appears.
- Click "Core+Internal" on the "Generate" line
- When it's done, save and quit the image

Rename away the generated source directory:
$ mv src32 src32-without-patches

Reopen the Squeak-Dev image.
File in "./spoon/components/spoonProcessor Changes.st"
Click "Core+Internal" again.
Save and quit the image again.

Rename the generated source directory appropriately:
$ mv src32 src32-with-patches

If you like, examine the core changes to the interpreter:
$ diff -w -ru3 src32-without-patches/ src32-with-patches/

Regenerate the VM one more time, with as many plugins as possible
external, and the rest internal.
- open the image
- middle click "Plugins not built" in the VMMaker
- choose "make all external"
- drag "LargeIntegersSimulator" out of the "External Plugins" panel
into the "Plugins not built" panel
- click "Entire"
- You get an error during LargeIntegersPlugin! Click "proceed".
Save and quit the image.

Edit src32/vm/interp.c
- add the line "#define halt(x)" to the top
- search for the line "cleanUpContexts();" and comment it out

Now apply the changes to the VM sources and build the VM.
$ rm -rf Squeak-3.9-8/platforms/unix/src
$ rm -rf Squeak-3.9-8/platforms/unix/src32
$ rm -rf Squeak-3.9-8/platforms/unix/src64
$ mv src32 Squeak-3.9-8/platforms/unix/src
$ mv Squeak-3.9-8/platforms/unix/src/plugins/Flow/
Flow-plugin-as-generated
$ cp -r flow2a5 Squeak-3.9-8/platforms/unix/plugins/Flow
$ cp flow2a/platformSpecific/linux/Makefile.in
Squeak-3.9-8/platforms/unix/plugins/Flow/
$ mkdir Squeak-3.9-8/build
$ (cd Squeak-3.9-8/platforms/unix/config/; make)
$ (cd Squeak-3.9-8/build/; ../platforms/unix/config/configure
--prefix=/opt/spoon)

Fix LargeIntegers.c line 1370 - comment out the line
halt(,("missing primitive: ", primitiveName));

$ (cd Squeak-3.9-8/build/; make)
$ (cd Squeak-3.9-8/build/; make install)

Now /opt/spoon/bin/squeak memory.image should work.

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Compiling Flow.so under linux

2007-09-13T13:28:55Z

Hi Matthew, hi list,

I've finally got around to trying to build a spoon VM of my own, and
I've met with some success (!).

* I've managed to build a VM that can load and run "memory.image"
* I get a page at http://localhost:8090/3
* I've build a separate Flow plugin that works with a stock VM well
enough to allow the naiad components to load and partially run

I now run into the problem where

Smalltalk
at: #ExampleWormholeServer
put: (WormholeServer atPort: 9999)
succeeds,

ExampleWormholeServer connectToPort: 7777 atHostNamed: 'localhost'
succeeds,

but

OtherBrowser openOnWormhole: ExampleWormholeServer clients any
fails, with an error

MessageNotUnderstood: Other>>module

The next message will contain the steps I took to build a spoonable VM.

Regards,
Tony

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Compiling Flow.so under linux

2007-09-07T14:16:36Z

OK, OK, I got out my Linux box and had a go at this for a while. Used
the new 2a5 sources, but I think they're still in need of work to get
Spoon running under Linux. But here are the steps. Sorry I can't pin
down some of this exactly:

On Thu, 06 Sep 2007 00:43:00 -0700, Matthew Fulmer wrote:

>> 1. Download the 3.9-8 VM source code:
>> http://squeakvm.org/unix/release/Squeak-3.9-8.src.tar.gz

>> 5. Download and run squeak-dev:
>> http://damien.cassou.free.fr/squeak-dev/sq3.9-7067dev07.08.1.zip

So now you have a working "vanilla" Squeak.

. . .

Get the entire VM SVN:

svn co http://squeakvm.org/svn/squeak/trunk squeak-svn

>> http://netjam.org/flow2a5.tar.gz
>> 4. Unzip it to
>> ~/platforms/Cross/plugins/FlowPlugin/

OK, but be sure that your folders across "platforms" are named either
Flow or FlowPlugin, ie named consistently. Craig named them "Flow", so
beware!

> 4.1. Download the Flow build files:
> http://netjam.org/flow2aPrimitiveSources.zip
> 4.2. Extract
> flow2aPrimitiveSources.zip/flow/platformSpecific/linux/Makefile.in
> to ~/platforms/unix/plugins/FlowPlugin/

Extract
flow2aPrimitiveSources.zip/flow/platformSpecific/linux/plugins.ext
to ~/platforms/unix/src/

I should say I also removed config.h from
~/platforms/Cross/plugins/FlowPlugin/ as it looked like a MacOS
include...

So now you have your sources set up.

. . .

I'm not convinced the following is necessary just to build Flow.so.
(You might want it for other reasons though):

>> 6. Install VMMaker-3.8b6.1 from Universes (Category: System)

>> 8. Open VMMaker Tool and configure:
>> 8.1. Interpreter Class Name: Interpreter
>> 8.2. Path to Platform Code: ~/platforms
>> 8.3. Platform Name: unix
>> 8.4. Path to Generated Sources: ~/platform/unix/src
>> 8.5. Internal Plugins: None
>> 8.6. External Plugins: Flow

. . .

All that VMMaker is being used for is to generate the plugins.ext file
which doesn't have to say anything more than:

EXTERNAL_PLUGINS = FlowPlugin

...which you have already courtesy Craig. If this file doesn't say
that, the make process will still chug foward, stumble and generate a
Flow.la because ./configure found it, but the Makefiles weren't built
correctly. I found that fiddling with VMMakerTool merely erased what
was in plugins.ext. (Not sure why)

So the final part is to switch to ~/platforms/unix/ and run make. This
will go through and run many ./configures, build the requisite
Makefiles, and should leave Flow.so in ~/platforms/unix/bld/FlowPlugin/

But as I said, I believe there are still problems with it, but not the
same as on my previous tries...

:-)

I'll follow this email with with my typescript of the make process. It
has a bunch of warnings that I don't know right now whether they are
serious or not...

Best, vatic

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Compiling Flow.so under linux

2007-09-06T01:43:00Z

After some help from vatic and Craig on IRC, I am able to build
something broken

On Sun, Aug 26, 2007 at 03:18:39PM -0700, Matthew Fulmer wrote:

> I have been unable to deduce the steps required to build Flow.so
> under linux. There are guides [1] [2], but ran into problems
> following each one, such as configure barfing on an empty build
> directory, where to put the source, whether VMMaker is needed,
> and whether generated or raw source is required to build
> Flow.so. So, here is what I am doing. It does not work:
>
> 1. Download the 3.9-8 VM source code:
> http://squeakvm.org/unix/release/Squeak-3.9-8.src.tar.gz
> 2. Unzip it to /home/tapple/squeak/vm
> 3. Download the 2a5 Flow source code:
> http://netjam.org/flow2a5.tar.gz
> 4. Unzip it to
> /home/tapple/squeak/vm/platforms/Cross/plugins/FlowPlugin

4.1. Download the Flow build files:
http://netjam.org/flow2aPrimitiveSources.zip
4.2. Extract
flow2aPrimitiveSources.zip/flow/platformSpecific/linux/Makefile.in
to /home/tapple/squeak/vm/platforms/unix/plugins/FlowPlugin

> 5. Download and run squeak-dev:
> http://damien.cassou.free.fr/squeak-dev/sq3.9-7067dev07.08.1.zip
> 6. Install VMMaker-3.8b6.1 from Universes (Category: System)

Don't do step 7:

> 7. Load "spoonProcessor Changes.st" from the components
> directory of
> http://www.movedigital.com/go/netjam/63004/spoon.2a12.linux.zip

This step should not be done, and seems to be the cause of the
spurious Flow.c I found last time (see step 9 below). It seems
VMMaker is generating bad source for the Flow simulator support

> 8. Open VMMaker Tool and configure:
> 8.1. Interpreter Class Name: Interpreter
> 8.2. Path to Platform Code: /home/tapple/squeak/vm/platforms
> 8.3. Platform Name: unix
> 8.4. Path to Generated Sources: /home/tapple/squeak/vm/src
> 8.5. Internal Plugins: None
> 8.6. External Plugins: Flow

8.7 should be: External Plugins: None

> 9. Generate Entire. This generates, among other things, a
> single file containing the generated Flow source:
> /home/tapple/squeak/vm/src/plugins/Flow/Flow.c

Flow.c is no longer generated, as it shouldn't be

9.1. add B3DAccelleratorPlugin UnixOSProcessPlugin Flow to the
list in plugins.ext

> 10. In shell:
> 10.1. cd /home/tapple/squeak/vm/src
> 10.2. ../platforms/unix/config/configure
> 10.3. make

I get, in the source directory, an executable named squeak and a
Flow.la in Flow. I try running the squeak vm with the spoon
image, and I get the following error:

Recursive not understood error encountered

Segmentation fault

I try moving Flow and B3DAcceleratorPlugin to plugins.int. I
also notice that I have no plugin named UnixOSProcessPlugin in
either my platforms/unix/plugins or platforms/Cross/plugins
directories. I look at the size of the compiled UnixOSProcess.la and it
seems empty (only 758 bytes). So I delete it from the list of
compiled plugins. No matter whether I use UnixProcessorPlugin,
or whether plugins are internal or external, I still get the
same error whenever I try running the compiled squeak
executable.

Also, no .so files are ever compiled, only .la and .a files (for
external and internal plugins, respectively)

I may yet figure this out. Thanks for the help

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Porting spoon's VM support

2007-09-04T05:03:52Z

Thanks, Craig!

I've managed to get a Flow plugin building and running now (hooray!) so
the remaining thing for me to pin down the details of is the interp.c
regeneration process.

I'll take a stab at that this evening or tomorrow.

Regards,
Tony

Craig Latta wrote:

>
> Hi Tony--
>
>> Could someone confirm for me that I will *not* be able to use a stock
>> Unix Squeak VM, say 3.9-8, with Spoon and an appropriate Flow plugin?
>> That is, are there mandatory changes to the core VM that need to be
>> applied?
>
> That's right, you need to apply "spoonProcessorChanges.st" before
> generating interp.c, to get remote messaging support. Also, Squeak seems
> to have trouble on some Linux hosts with loading the released Flow
> shared library, due to differences in the pthreads shared library
> location. I'd be happy to help you with this.
>
>
> thanks,
>
> -C
>
> --
> Craig Latta
> improvisational musical informaticist
> www.netjam.org
> Smalltalkers do: [:it | All with: Class, (And love: it)]
>
>

--
[][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211
[][] LShift Ltd | Tel: +44 (0)20 7729 7060
[] [] http://www.lshift.net/ | Email: tonyg@...
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Porting spoon's VM support

2007-09-04T00:08:51Z

Hi Tony--

> Could someone confirm for me that I will *not* be able to use a stock
> Unix Squeak VM, say 3.9-8, with Spoon and an appropriate Flow plugin?
> That is, are there mandatory changes to the core VM that need to be
> applied?

That's right, you need to apply "spoonProcessorChanges.st" before
generating interp.c, to get remote messaging support. Also, Squeak seems
to have trouble on some Linux hosts with loading the released Flow
shared library, due to differences in the pthreads shared library
location. I'd be happy to help you with this.

thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Compiling Flow.so under linux

2007-08-27T09:03:22Z

On Sun, Aug 26, 2007 at 03:18:39PM -0700, Matthew Fulmer wrote:

> I have been unable to deduce the steps required to build Flow.so
> under Linux. There are guides [1] [2], but ran into problems
> following each one, such as configure barfing on an empty build
> directory, where to put the source, whether VMMaker is needed,
> and whether generated or raw source is required to build
> Flow.so. So, here is what I am doing. It does not work:
>
> 1. Download the 3.9-8 VM source code:
> http://squeakvm.org/unix/release/Squeak-3.9-8.src.tar.gz
> 2. Unzip it to /home/tapple/squeak/vm
> 3. Download the 2a5 Flow source code:
> http://netjam.org/flow2a5.tar.gz
> 4. Unzip it to
> /home/tapple/squeak/vm/platforms/Cross/plugins/FlowPlugin
> 5. Download and run squeak-dev:
> http://damien.cassou.free.fr/squeak-dev/sq3.9-7067dev07.08.1.zip
> 6. Install VMMaker-3.8b6.1 from Universes (Category: System)
> 7. Load "spoonProcessor Changes.st" from the components
> directory of
> http://www.movedigital.com/go/netjam/63004/spoon.2a12.linux.zip
> 8. Open VMMaker Tool and configure:
> 8.1. Interpreter Class Name: Interpreter
> 8.2. Path to Platform Code: /home/tapple/squeak/vm/platforms
> 8.3. Platform Name: unix
> 8.4. Path to Generated Sources: /home/tapple/squeak/vm/src
> 8.5. Internal Plugins: None
> 8.6. External Plugins: Flow
> 9. Generate Entire. This generates, among other things, a
> single file containing the generated Flow source:
> /home/tapple/squeak/vm/src/plugins/Flow/Flow.c
> 10. In shell:
> 10.1. cd /home/tapple/squeak/vm/src
> 10.2. ../platforms/unix/config/configure
> 10.3. make
> 11. Lots of undefined refs to halt in gnu-interp.c
> 12. Try just compiling plugins: make plugins
> 13. Lots of syntax errors in the generated Flow.c file
>
> I have a feeling that the generated Flow.c file is the problem,
> since the source is distributed as a set of files, but only one
> is generated

I am having several simultaneous uncertainties about the build
process that are not addressed in any walk through I found:

- are 'spoonProcessor Changes.st' and 'flow2a5.tar.gz' meant to
be used together? 'spoonProcessor Changes.st' adds a flow
plugin to VMMaker, and 'flow2a5.tar.gz' is the source code.
Both seem necessary to me, but I have no idea how to tell if
both are working together or not
- How to you generate the Makefile to build Flow.so? is that the
job of VMMaker, or of configure?
- Should configure be run before or after running VMMaker?
- should there be a generated Flow.c file, or should the source
just be copied from platforms/Cross/FlowPlugin?
- is platforms/Cross/FlowPlugin even the right place to extract
flow2a5.tar.gz?

Thanks; sorry I have so many questions

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Compiling Flow.so under linux

2007-08-26T16:18:39Z

I have been unable to deduce the steps required to build Flow.so
under linux. There are guides [1] [2], but ran into problems
following each one, such as configure barfing on an empty build
directory, where to put the source, whether VMMaker is needed,
and whether generated or raw source is required to build
Flow.so. So, here is what I am doing. It does not work:

1. Download the 3.9-8 VM source code:
http://squeakvm.org/unix/release/Squeak-3.9-8.src.tar.gz
2. Unzip it to /home/tapple/squeak/vm
3. Download the 2a5 Flow source code:
http://netjam.org/flow2a5.tar.gz
4. Unzip it to
/home/tapple/squeak/vm/platforms/Cross/plugins/FlowPlugin
5. Download and run squeak-dev:
http://damien.cassou.free.fr/squeak-dev/sq3.9-7067dev07.08.1.zip
6. Install VMMaker-3.8b6.1 from Universes (Category: System)
7. Load "spoonProcessor Changes.st" from the components
directory of
http://www.movedigital.com/go/netjam/63004/spoon.2a12.linux.zip
8. Open VMMaker Tool and configure:
8.1. Interpreter Class Name: Interpreter
8.2. Path to Platform Code: /home/tapple/squeak/vm/platforms
8.3. Platform Name: unix
8.4. Path to Generated Sources: /home/tapple/squeak/vm/src
8.5. Internal Plugins: None
8.6. External Plugins: Flow
9. Generate Entire. This generates, among other things, a
single file containing the generated Flow source:
/home/tapple/squeak/vm/src/plugins/Flow/Flow.c
10. In shell:
10.1. cd /home/tapple/squeak/vm/src
10.2. ../platforms/unix/config/configure
10.3. make
11. Lots of undefined refs to halt in gnu-interp.c
12. Try just compiling plugins: make plugins
13. Lots of syntax errors in the generated Flow.c file

I have a feeling that the generated Flow.c file is the problem,
since the source is distributed as a set of files, but only one
is generated

[1]: http://wiki.squeak.org/squeak/2105
[2]: http://squeakvm.org/unix/devel.html

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Porting spoon's VM support

2007-08-26T15:34:14Z

mike clemow wrote:
> Tony, do you have a smalltalk API built around the hardware on that
> platform? For instance the GPS device, etc? So that squeak apps can
> be built to interface with the hardware?

I'm building one. The kernel programmers have done a smooth job of the
interface between the kernel and the userland. For instance, the
touchscreen is available by reading /dev/input/event2, and the GSM chip
is available through a few control files in /sys/ and by writing
Hayes-style AT commands to /dev/ttySAC0.

> I'm more of a lurker on this list, but that's a very interesting
> project. Where do you normally post about your progress?

So far, just one post to LShift's blog:
http://www.lshift.net/blog/2007/08/23/squeak-and-openembedded

Regards,
Tony

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Porting spoon's VM support

2007-08-26T10:00:29Z

WOW!

Tony, do you have a smalltalk API built around the hardware on that
platform? For instance the GPS device, etc? So that squeak apps can
be built to interface with the hardware?

I'm more of a lurker on this list, but that's a very interesting
project. Where do you normally post about your progress?

Cheers,
Mike

On 8/26/07, Tony Garnock-Jones <tonyg@...> wrote:

> Hi all,
>
> I've just finished getting Squeak running on the Neo1973 [1], an
> OpenMoko [2] open-source GSM cellphone. So far, I have the stock VM able
> to run stock images. In order to develop for the phone, I'd like to try
> out a spoonish approach, so I thought I'd try to get spoon running.
>
> I'm having trouble in two areas: cross-compiling an appropriate Flow
> plugin (I need the latest primitive sources) and building an appropriate VM.
>
> Could someone confirm for me that I will *not* be able to use a stock
> Unix Squeak VM, say 3.9-8, with Spoon and an appropriate Flow plugin?
> That is, are there mandatory changes to the core VM that need to be applied?
>
> Thank you,
> Tony
>
> [1] http://www.openmoko.com/products-index.html
> [2] http://www.openmoko.org/
> _______________________________________________
> Spoon mailing list
> Spoon@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
>

--
http://shadowofaculture.blogspot.com
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Porting spoon's VM support

2007-08-26T03:36:48Z

Hi all,

I've just finished getting Squeak running on the Neo1973 [1], an
OpenMoko [2] open-source GSM cellphone. So far, I have the stock VM able
to run stock images. In order to develop for the phone, I'd like to try
out a spoonish approach, so I thought I'd try to get spoon running.

I'm having trouble in two areas: cross-compiling an appropriate Flow
plugin (I need the latest primitive sources) and building an appropriate VM.

Could someone confirm for me that I will *not* be able to use a stock
Unix Squeak VM, say 3.9-8, with Spoon and an appropriate Flow plugin?
That is, are there mandatory changes to the core VM that need to be applied?

Thank you,
Tony

[1] http://www.openmoko.com/products-index.html
[2] http://www.openmoko.org/
_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

Re: Spoon planning (was "Contributors Agreement signature status?")

2007-07-09T21:14:28Z

I'd like to start with a very minimal image, a 3.8 or 3.9 "master"
image, and see if Magma's test suite can run in the minimal, having
pulled over methods dynamically. (And very curious as to the final
size and contents of that minimal image!).

On 7/4/07, Craig Latta <craig@...> wrote:

>
> Hi Janko--
>
> > When Spoon will be ready and proven on few battlefields, then will be
> > a time for a switch.
>
> Can you be more specific? I'd like to know how you (all) define
> success, in terms concrete enough for planning. I suspect "I'll know it
> when I see it" doesn't suffice. :)
>
>
> thanks,
>
> -C
>
> --
> Craig Latta
> improvisational musical informaticist
> www.netjam.org
> Smalltalkers do: [:it | All with: Class, (And love: it)]
>
> _______________________________________________
> Spoon mailing list
> Spoon@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon
>

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

start script

2007-07-07T03:57:41Z

Hi,

I did a little start script for my spoon. It starts
the memory image (spoon) and another squeak image
to work with.

I'll attach it just in case somebody is interested in.
The archive contains three files:

spoon.sh the start script
bootstrap.sh is a symlink to spoon.sh
bootstrap.st three lines bootstrapping the working image

The script always starts the spoon image in the background
and another image in the foreground. If you stop the fore-
ground image the spoon image is also stopped.

Invoked as bootstrap.sh the script invokes the bootstrap.st
init script. This loads the naiad.st code and loads the
naiad.pr project.

The script is invoked as:

- if you have both, a squeak 3.9 final image and the spoon
installation in the current directory

#> sh bootstrap.sh Squeak3.9-final-7067

If your spoon installation is somewhere else just give the path as
a second argument to the script.

Any feedback is welcomed.

Norbert

_______________________________________________
Spoon mailing list
Spoon@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

spoon-script.tar.gz (1K) Download Attachment