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.
2008/11/10 José L. Redrejo Rodríguez jredrejo@edu.juntaextremadura.net:
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.
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.
Dave
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 -
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
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
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
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:
- Changed #fetchWord:ofObject: to #fetchLong32:ofObject: in two
places. The #fetchWord:ofObject: method is deprecated in recent VMMaker versions.
- 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 -
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:
- Changed #fetchWord:ofObject: to #fetchLong32:ofObject: in two
places. The #fetchWord:ofObject: method is deprecated in recent VMMaker versions.
- 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
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
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 -
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
vm-dev@lists.squeakfoundation.org