Smalltalk › Squeak › Squeak VM

coordination between the olpc and official svn branches

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

José "L. Redrejo" Rodríguez

coordination between the olpc and official svn branches

Hi, I'm trying to maintain the squeak-vm in Debian, but everyday is
being harder. I was using the trunk branch, but finally I have almost
decided to give it up and I'm going to use the olpc branch.
Changes from the olpc branch to trunk are being passed in a poor way:
some directories are forgotten (Gstreamer or Ogg don't compile as the
unix directories have been passed, but not the Cross ones), fixes are
not passed (pango support is broken in the trunk branch, etc)

So, please, I'd like to know if this is going to change, or if I just
should give up, use the olpc branch and forgot about the "official"
squeak-vm branch.

Regards.
José L.

signature.asc (204 bytes) Download Attachment

Igor Stasenko

Re: coordination between the olpc and official svn branches

2008/11/10 José L. Redrejo Rodríguez <[hidden email]>:

>
> Hi, I'm trying to maintain the squeak-vm in Debian, but everyday is
> being harder. I was using the trunk branch, but finally I have almost
> decided to give it up and I'm going to use the olpc branch.
> Changes from the olpc branch to trunk are being passed in a poor way:
> some directories are forgotten (Gstreamer or Ogg don't compile as the
> unix directories have been passed, but not the Cross ones), fixes are
> not passed (pango support is broken in the trunk branch, etc)
>
> So, please, I'd like to know if this is going to change, or if I just
> should give up, use the olpc branch and forgot about the "official"
> squeak-vm branch.
>

You raised a good question. I'd like to know the fate of squeak-vm as well.
There is an activity around squeak vm (including my humble person :)),
but there is little or no coordination between different ports.

> Regards.
> José L.
>

--
Best regards,
Igor Stasenko AKA sig.

David T. Lewis

Re: coordination between the olpc and official svn branches

In reply to this post by José "L. Redrejo" Rodríguez

On Mon, Nov 10, 2008 at 10:14:03AM +0100, Jos? L. Redrejo Rodr?guez wrote:

Slightly off topic, but just to check:

If there are any OLPC changes that belong in the base VMMaker package,
I would like to harvest them in VMMaker on SqueakSource. My understanding
is that the OLPC plugins are being maintained elsewhere, which is a good
thing, but if there are any supporting change sets that should be
collected please let me know.

Dave

Bert Freudenberg

Re: coordination between the olpc and official svn branches

In reply to this post by José "L. Redrejo" Rodríguez

On 10.11.2008, at 10:14, José L. Redrejo Rodríguez wrote:

> Hi, I'm trying to maintain the squeak-vm in Debian, but everyday is
> being harder. I was using the trunk branch, but finally I have almost
> decided to give it up and I'm going to use the olpc branch.
> Changes from the olpc branch to trunk are being passed in a poor way:
> some directories are forgotten (Gstreamer or Ogg don't compile as the
> unix directories have been passed, but not the Cross ones),

The very latest in svn should compile, it has the missing files
(although in unic/src not Cross). Make sure you reconfigure to pick up
the new files after updating.

> fixes are not passed (pango support is broken in the trunk branch,
> etc)

What exactly is broken with Pango? If so it's indeed my fault to not
having passed on the fixes (I sent patches to Ian last week but I may
have missed something).

> So, please, I'd like to know if this is going to change, or if I just
> should give up, use the olpc branch and forgot about the "official"
> squeak-vm branch.

The olpc branch is about to be retired - it has served us as a faster-
paced development playground, but now that we switch from invention
mode to maintenance mode, the trunk is the better place for things to
live on.

- Bert -

José "L. Redrejo" Rodríguez

Re: coordination between the olpc and official svn branches

El lun, 10-11-2008 a las 18:08 +0100, Bert Freudenberg escribió:

> On 10.11.2008, at 10:14, José L. Redrejo Rodríguez wrote:
>
> > Hi, I'm trying to maintain the squeak-vm in Debian, but everyday is
> > being harder. I was using the trunk branch, but finally I have almost
> > decided to give it up and I'm going to use the olpc branch.
> > Changes from the olpc branch to trunk are being passed in a poor way:
> > some directories are forgotten (Gstreamer or Ogg don't compile as the
> > unix directories have been passed, but not the Cross ones),
>
> The very latest in svn should compile, it has the missing files
> (although in unic/src not Cross). Make sure you reconfigure to pick up
> the new files after updating.
>
> > fixes are not passed (pango support is broken in the trunk branch,
> > etc)
>
> What exactly is broken with Pango? If so it's indeed my fault to not
> having passed on the fixes (I sent patches to Ian last week but I may
> have missed something).
>

I haven't checked the code yet, I just can say that reconfiguring and
compiling the vm from squeak-svn , the image from
http://tinlizzie.org/olpc/etoys-dev-4.0.zip segfaults. When
reconfiguring and compiling the vm from the olpc branch it starts and
pango improvements are perfectly seen. Anyway, in 64 bits the olpc vm
also segfaults.

> > So, please, I'd like to know if this is going to change, or if I just
> > should give up, use the olpc branch and forgot about the "official"
> > squeak-vm branch.
>
>
> The olpc branch is about to be retired - it has served us as a faster-
> paced development playground, but now that we switch from invention
> mode to maintenance mode, the trunk is the better place for things to
> live on.
>

It's good to know it. I'm looking forward to see the mainteinance mode
working, specially for 64 bits support where there are a lot of open
bugs[1], and now we can add a new bug in pango. With the huge amounts of
memory in the newest pc, amd64 is becoming a very common architecture.
In my case I'm deploying 3200 ltsp servers with 8 gb of memory for the
Extremadura schools where 64 bits are a need, and I'm afraid I'll have
to spend a lot of time chrooting Squeak to see it working in a 32 bits
environment.

Best regards
José L.

[1]
http://lists.squeakfoundation.org/pipermail/vm-dev/2008-August/001988.html

signature.asc (204 bytes) Download Attachment

Bert Freudenberg

Re: coordination between the olpc and official svn branches

In reply to this post by David T. Lewis

On 10.11.2008, at 14:35, David T. Lewis wrote:

>
> On Mon, Nov 10, 2008 at 10:14:03AM +0100, Jos? L. Redrejo Rodr?guez
> wrote:
>>
>> Hi, I'm trying to maintain the squeak-vm in Debian, but everyday is
>> being harder. I was using the trunk branch, but finally I have almost
>> decided to give it up and I'm going to use the olpc branch.
>> Changes from the olpc branch to trunk are being passed in a poor way:
>> some directories are forgotten (Gstreamer or Ogg don't compile as the
>> unix directories have been passed, but not the Cross ones), fixes are
>> not passed (pango support is broken in the trunk branch, etc)
>>
>> So, please, I'd like to know if this is going to change, or if I just
>> should give up, use the olpc branch and forgot about the "official"
>> squeak-vm branch.
>
> Slightly off topic, but just to check:
>
> If there are any OLPC changes that belong in the base VMMaker package,
> I would like to harvest them in VMMaker on SqueakSource. My
> understanding
> is that the OLPC plugins are being maintained elsewhere, which is a
> good
> thing, but if there are any supporting change sets that should be
> collected please let me know.

Hi David,

I'm attaching a snapshot of the VMMaker we were using in the OLPC
branch. Our full VMMaker image is at

http://etoys.laptop.org/svn/trunk/vmm/

This started out with some version of Tim's and had various changesets
applied ...

ClipboardExtendedPlugin is new, DropPlugin allows drag out of Squeak,
SocketPlugin grew IPv6 support (or rather, arbitrary address
families), SoundPlugin allows access to device parameters.

Of the Interpreter changes, I think only #primitiveBeCursor is still
relevant (adds ARGB support), the rest of the differences should come
from the sqUInt cleanups.

The other plugins used for OLPC (GStreamer, Kedama2, Ogg, Rome,
ImmX11, DBus) are not actually OLPC specific, and some don't even have
a real home, so maybe we should move them into VMMaker?

- Bert -

VMMaker-olpc.59(tpr.58).mcd (169K) Download Attachment

David T. Lewis

Re: coordination between the olpc and official svn branches

On Tue, Nov 11, 2008 at 03:06:24PM +0100, Bert Freudenberg wrote:

>
> On 10.11.2008, at 14:35, David T. Lewis wrote:
> >
> >If there are any OLPC changes that belong in the base VMMaker package,
> >I would like to harvest them in VMMaker on SqueakSource.
>
> I'm attaching a snapshot of the VMMaker we were using in the OLPC
> branch. Our full VMMaker image is at
>
> http://etoys.laptop.org/svn/trunk/vmm/
>
> This started out with some version of Tim's and had various changesets
> applied ...

Thanks Bert,

I'll spend some time sorting through it this weekend. Serves me right
for asking ;-)

Dave

David T. Lewis

Re: coordination between the olpc and official svn branches

On Tue, Nov 11, 2008 at 07:25:57PM -0500, David T. Lewis wrote:

> On Tue, Nov 11, 2008 at 03:06:24PM +0100, Bert Freudenberg wrote:
> >
> > I'm attaching a snapshot of the VMMaker we were using in the OLPC
> > branch. Our full VMMaker image is at
> >
> > http://etoys.laptop.org/svn/trunk/vmm/
> >
> > This started out with some version of Tim's and had various changesets
> > applied ...
>
> I'll spend some time sorting through it this weekend. Serves me right
> for asking ;-)

Bert, I also took the liberty of adding you as a developer to the VMMaker
project on SqueakSource. You can add directly to that project if you like
(MIT only of course).

Dave

David T. Lewis

Merge big cursor support (was: coordination between the olpc and official svn branches)

In reply to this post by Bert Freudenberg

On Tue, Nov 11, 2008 at 03:06:24PM +0100, Bert Freudenberg wrote:

Hi Bert,

Your starting point was VMMaker-tpr.58.mcz, which is VMMaker 3.8b6 on
SqueakMap/Universes.

> Of the Interpreter changes, I think only #primitiveBeCursor is still
> relevant (adds ARGB support), the rest of the differences should come
> from the sqUInt cleanups.

That looks right, so I'll focus on #primitiveBeCursor first.

I am attaching an update to your bigCursor-bf change set with two
modifications that I think should be made to merge back into newer VMMaker
versions:

1) Changed #fetchWord:ofObject: to #fetchLong32:ofObject: in two places.
The #fetchWord:ofObject: method is deprecated in recent VMMaker versions.

2) Restored check for 64 bit object word size. This makes the primitive
into a no-op for 64 bit images, and is flagged for a fix when bitmap
conversion is implemented. I presume that this has not yet been done,
so I think the check should remain for now.

If you agree with these changes, I will apply them to the *-dtl thread
of updates in SqueakSource VMMaker. The remaining to-do item will be to
implement ioSetCursorARGB() in the win32 and RiscOS platform sources.
These can presumably be no-ops for starters.

I also opened a Mantis issue to track this and provide a record of what
we're doing (http://bugs.squeak.org/view.php?id=7224).

Thanks,
Dave

bigCursor-bf-dtl.2.cs (4K) Download Attachment

Bert Freudenberg

Re: Merge big cursor support (was: coordination between the olpc and official svn branches)

On 16.11.2008, at 20:00, David T. Lewis wrote:

> On Tue, Nov 11, 2008 at 03:06:24PM +0100, Bert Freudenberg wrote:
>>
>> On 10.11.2008, at 14:35, David T. Lewis wrote:
>>>
>>> If there are any OLPC changes that belong in the base VMMaker
>>> package,
>>> I would like to harvest them in VMMaker on SqueakSource.
>>
>> I'm attaching a snapshot of the VMMaker we were using in the OLPC
>> branch. Our full VMMaker image is at
>>
>> http://etoys.laptop.org/svn/trunk/vmm/
>>
>> This started out with some version of Tim's and had various
>> changesets
>> applied ...
>
> Hi Bert,
>
> Your starting point was VMMaker-tpr.58.mcz, which is VMMaker 3.8b6 on
> SqueakMap/Universes.
>
>> Of the Interpreter changes, I think only #primitiveBeCursor is still
>> relevant (adds ARGB support), the rest of the differences should come
>> from the sqUInt cleanups.
>
> That looks right, so I'll focus on #primitiveBeCursor first.
>
> I am attaching an update to your bigCursor-bf change set with two
> modifications that I think should be made to merge back into newer
> VMMaker
> versions:
>
> 1) Changed #fetchWord:ofObject: to #fetchLong32:ofObject: in two
> places.
> The #fetchWord:ofObject: method is deprecated in recent VMMaker
> versions.
>
> 2) Restored check for 64 bit object word size. This makes the
> primitive
> into a no-op for 64 bit images, and is flagged for a fix when bitmap
> conversion is implemented. I presume that this has not yet been done,
> so I think the check should remain for now.
>
> If you agree with these changes, I will apply them to the *-dtl thread
> of updates in SqueakSource VMMaker. The remaining to-do item will be
> to
> implement ioSetCursorARGB() in the win32 and RiscOS platform sources.
> These can presumably be no-ops for starters.
>
> I also opened a Mantis issue to track this and provide a record of
> what
> we're doing (http://bugs.squeak.org/view.php?id=7224).
>
> Thanks,
> Dave
>
> <bigCursor-bf-dtl.2.cs>

Looks good :)

- Bert -

David T. Lewis

Re: Merge big cursor support (was: coordination between the olpc and official svn branches)

On Sun, Nov 16, 2008 at 08:15:01PM +0100, Bert Freudenberg wrote:

> On 16.11.2008, at 20:00, David T. Lewis wrote:
> >On Tue, Nov 11, 2008 at 03:06:24PM +0100, Bert Freudenberg wrote:
> >>Of the Interpreter changes, I think only #primitiveBeCursor is still
> >>relevant (adds ARGB support), the rest of the differences should come
> >>from the sqUInt cleanups.
> >
> >That looks right, so I'll focus on #primitiveBeCursor first.
> >
> >I am attaching an update to your bigCursor-bf change set with two
> >modifications that I think should be made to merge back into newer
> >VMMaker
> >versions:
> >
> >1) Changed #fetchWord:ofObject: to #fetchLong32:ofObject: in two
> >places.
> >The #fetchWord:ofObject: method is deprecated in recent VMMaker
> >versions.
> >
> >2) Restored check for 64 bit object word size. This makes the
> >primitive
> >into a no-op for 64 bit images, and is flagged for a fix when bitmap
> >conversion is implemented. I presume that this has not yet been done,
> >so I think the check should remain for now.
> >
> >If you agree with these changes, I will apply them to the *-dtl thread
> >of updates in SqueakSource VMMaker. The remaining to-do item will be
> >to
> >implement ioSetCursorARGB() in the win32 and RiscOS platform sources.
> >These can presumably be no-ops for starters.
> >
> >I also opened a Mantis issue to track this and provide a record of
> >what
> >we're doing (http://bugs.squeak.org/view.php?id=7224).
> >
> >Thanks,
> >Dave
> >
> ><bigCursor-bf-dtl.2.cs>
>
> Looks good :)

Thanks, the changes are included in VMMaker-dtl.108 and VMMaker-dtl.107 (same
as 108 but with SlangBrowser and MemoryAccess included) on SqueakSource VMMaker.

Dave

David T. Lewis

Need ioSetCursorARGB() for win32 (was: Merge big cursor support)

Hi Andreas,

The big cursor support from OLPC requires a ioSetCursorARGB() in the platform
sources, which for win32 would probably go into win32/vm/sqWin32Window.c.

If you have an implementation of this, could you please add it to the win32
platform sources on Subversion; or if not could you add a stub implementation
that might look something like this:

sqInt ioSetCursorARGB(sqInt cursorBitsIndex, sqInt extentX, sqInt extentY, sqInt offsetX, sqInt offsetY)
{
return 0;
}

I have added the Interpreter>>primitiveBeCursor patch to VMMaker on SqueakSource.
The change sets are on http://bugs.squeak.org/view.php?id=7224, and can be
used to update the various other VMMaker branches.

For completeness, we should probably also have a function prototype in Cross/vm/sq.h:
sqInt ioSetCursorARGB(sqInt cursorBitsIndex, sqInt extentX, sqInt extentY, sqInt offsetX, sqInt offsetY);

Cheers,

Dave